On Tuesday, February 23, 2016 at 6:58:19 PM UTC, 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
I wonder if Worldpay are making their customers who are using those payment terminals aware of this issue so that they can make contingency plans themselves. In any case this exception should probably go ahead as there doesn't seem to be a security risk here for trust store users, just a risk of setting a bad precedent if organisations are allowed to make mistakes, and then use the scale of their mistakes to force Mozilla to bail them out. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
