Hey all, Thanks to everyone for the robust discussion here. Gerv, Kathleen and I have discussed and decided that Mozilla will allow a qualification due to issuance of SHA-1 certificates, subject to the following conditions:
1. SHA-1 certificates MUST NOT be issued for any name other than the seven names requested by Symantec (tptrans.lynksystems.com, tptrans-l.lynksystems.com, tpdev.lynksystems.com, tframe1.rbslynk.com, tframe2.rbslynk.com, tf.lynk-systems.com, and qac.tf.rbslynk.com) 2. On issuance of any such certificate(s), the issuer MUST take the following actions: 2.a. Submit the certificates to one or more Certificate Transparency logs. (There is no requirement for the certificates to contain a Signed Certificate Timestamp.) 2.b. Send email to the cabfpub and dev.security.policy mailing lists announcing this event, including references to the CT entries. 3. The lifetime of the issued SHA-1 certificates MUST be no more than 90 days, and MUST NOT extend beyond 2016-12-31. Reissuance is permitted, but must be requested at least two weeks in advance on the dev.security.policy mailing list. Mozilla reserves the right to decide in the future that the conditions for further issuance of such certificates may vary, including deeming them unacceptable under any circumstances. 4. The serial numbers of issued SHA-1 certificates MUST contain at least 80 bits of entropy. 5. The auditor's qualification MUST actively attest that the extent of SHA-1 issuance is no greater than that disclosed in CT. (Otherwise the qualification will be deemed unacceptable.) 6. This allowance applies only to the Worldpay names above; allowance for any other cases MUST be requested on this mailing list at least two weeks in advance of any further allowance being made. While we are disappointed that a critical part of the Internet infrastructure is holding back an increase in security, we believe that this allowance strikes an acceptable compromise between minimizing disruption and risk and encouraging migration away from SHA-1 as fast as possible. Thanks, --Richard On Tuesday, February 23, 2016 at 10:58:19 AM UTC-8, 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. This equipment does not support > SHA-256 and cannot be replaced in time. The data travels over the public > internet but the servers are not accessed by browsers. Due to the short > timelines involved, a change in the BRs by the CAB Forum is also not > possible. Therefore, they are seeking to get browser acknowledgement > that a qualified audit, qualified by the existence of these certs, will > be acceptable. > > The payment industry is moving towards SHA-256 but their timeline does > not line up with the CAB Forum one. Our understanding is that Worldpay > is not the only payment processor in this position. (We are not sure how > to match this information with Worldpay's assertion that this was an > oversight on their part, unless such oversights are unusually common at > payment processors.) > > Our proposal, which we have sent to Symantec, Worldpay and the other > browsers, is as follows: > > Symantec may issue certificates to Worldpay if the following things are > true: > > 1. You immediately give copies to Mozilla (and other vendors who desire > them) for us to immediately add them to OneCRL, as if they had been > mis-issued. > > 2. Symantec's OCSP server MUST present a response of Revoked to any > request for these certificates from, at a minimum, Firefox (based on > User-Agent). Other browsers may wish to be added to this list. Sending > Revoked to everyone would be easiest, but that depends on your testing > as to whether it will break the intended clients. > > 3. Certificates issued under this exception MUST be logged to CT, and > Symantec MUST disclose which logs they will be published in. > > 4. On issuance of any such certificate(s), the issuer MUST send mail to > cabfpub announcing the event, including references to the CT entries. > > 5. The auditor's qualification MUST actively attest that the extent of > SHA-1 issuance is no greater than that disclosed in CT. (Otherwise the > qualification will be deemed unacceptable.) > > 6. The lifetime of the issued SHA-1 certificates MUST be no more than 90 > days. Reissuance is permitted, but Mozilla reserves the right to decide > in the future that the conditions for further issuance of such > certificates may vary, including deeming them unacceptable under any > circumstances. Mozilla is very likely to not permit validity to extend > beyond the SHA-1 deadline of 31st December 2016. > > 7. This exception applies to Worldpay only; you need to come back and > ask, presenting the circumstances, for other cases. If the impact is > similar, similar terms may be extended. > > > Mozilla is very keen to see SHA-1 eliminated, but understands that for > historical reasons poor decisions were made in private PKIs about which > roots to trust, and such decisions are not easily remedied. > > Please comment on whether this proposal seems reasonable, being aware of > the short timelines involved. > > Gerv _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
