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
Gerv, I just re-read your plan, and maybe point 6 is too restrictive -- allowing only 90 days for these emergency SHA-1 replacement certs. Remember, through Dec. 2015, these same financial service companies COULD have purchased SHA-1 certificates that would have been valid through 12/31/2016 - a full year. Those SHA-1 certs would NOT have been subject to ANY of the restrictions in your plan - and so they would not have been as secure for users as the emergency SHA-1 certs being issued under your plan. So why not allow these emergency SHA-1 certs that are subject to your safeguards expire as late as 12/31/2016? (As I have said, there are already many of these machines with SHA-1 certs that expire 12/31/2016 that are NOT subject to your safeguards, so this is only an improvement...) _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy