I think Rob's questions are great and should be answered before deciding. Many CAs have roots and can issue certs that browsers will simply reject. There may be a simple way to provide them certs without issuing a ton of SHA1s that are placed on OneCRL.
-----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Rob Stradling Sent: Wednesday, February 24, 2016 3:16 AM To: Gervase Markham; mozilla-dev-security-pol...@lists.mozilla.org Cc: Kathleen Wilson; Richard Barnes Subject: Re: Proposed limited exception to SHA-1 issuance On 23/02/16 18:57, Gervase Markham wrote: > Mozilla and other browsers have been approached by Worldpay, a large > payment processor, via Symantec, their CA. They have been > transitioning to SHA-2 but due to an oversight have failed to do so in > time for a portion of their infrastructure, and failed to renew some > SHA-1 server certificates before the issuance deadline of 31st December 2015. > > They now need 9 SHA-1 certificates issued before 28th February 2015, > or approximately 10,000+ payment terminals around the world will stop > working. This equipment was created some time ago, and unfortunately > only supports publicly-trusted roots. Using roots removed from browser > root programs is also not a complete solution to the program; these > 10,000 do not trust any of those roots. Gerv, I would really like to see more technical details about the PKI software in WorldPay's terminals before offering an opinion on whether or not an limited exception should be granted. Perhaps we can find an alternative technical solution for WorldPay that would have less (or even no) impact on the Web PKI. With that in mind, some questions... Which roots do these WorldPay terminals trust? Do these terminals support signature hash algorithms that are even less secure than sha1WithRSAEncryption (i.e. md5WithRSAEncryption, md4WithRSAEncryption, md2WithRSAEncryption) that modern browsers will reject? (If so, perhaps Symantec could be permitted to issue new MD5 certs to WorldPay from a publicly trusted root). Do these terminals support key sizes that modern browsers will reject? (If so, perhaps Symantec could be permitted to issue new (for example) 1024-bit RSA certs to WorldPay from a publicly trusted root). Do these terminals have any certificate path building/verification bugs that could be exploited? For example: - Has anyone actually checked that these terminals will reject an expired certificate? (If not, then WorldPay could merrily continue to use the very-soon-to-expire SHA-1 certs that they already have). - Do these terminals correctly handle the Basic Constraints extension? (If not, then Symantec could issue new SHA-1 end-entity certs from a non-CA cert). - Do these terminals barf if they encounter an unrecognized critical extension? (If not, then perhaps Symantec could be permitted to issue new SHA-1 end-entity certs that contain a random critical extension, which modern browsers should reject). What software do these terminals use to build and verify certificate chains? If it's proprietary code developed by WorldPay, then the community probably wouldn't be able to help find an exploitable bug. But if it's an old version of NSS or OpenSSL, then the community could help find an exploitable bug. <snip> -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
