On Tue, Feb 23, 2016 at 1:57 PM, Gervase Markham <[email protected]> wrote:
> > Our proposal, which we have sent to Symantec, Worldpay and the other > browsers, is as follows: > Thank you for bringing this to the list for public input, even with a tight timeline and under immense pressure. It really speaks to how sincerely Mozilla and its root program are rooted in public review and participation. I agree fully with Andrew Ayer's comments, and don't believe Mozilla should allow this exception. While it would certainly cause pain and a loss of business for some of WorldPay's customers, WorldPay should take alternative drastic action, such as buying all of their affected customers a new terminal, paying the shipping costs, and providing human on-site support wherever possibly practical. If this is expensive to them, fine -- it's more expensive to the web PKI to establish this kind of precedent. It would also be worth learning what segment of the market these 10,000 terminals would affect. I've seen these terminals before: https://www.google.com/search?q=worldpay&espv=2&biw=1168&bih=783&site=webhp&source=lnms&tbm=isch&sa=X&ved=0ahUKEwj91arSqo_LAhUBOSYKHZ4_AtYQ_AUICCgD#tbm=isch&q=worldpay+terminal Many of them are used by small businesses and sole proprietors. Many of them are used by large businesses. Which kind of customer is being affected should factor into Mozilla's decision. All that said, if Mozilla does decide to proceed, some suggestions inline below. 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. > Has testing of whether it will break the intended clients been done yet? Or, will it be done before the certificates are issued? If tests show that the intended clients will not affected by Symantec's OCSP responder generically returning Revoked for all user agents, then the proposal should not allow an exception for the Firefox user agent. While Mozilla can't speak for what other browsers want, neither the Baseline Requirements or the Mozilla root program allow CAs to only comply with requirements insofar as they affect Firefox user agents. If the testing can't be completed in time, then the proposal should include a conditional that only allows user agent discretion if testing shows, after the fact, that the terminals will not work if Symantec's OCSP responders show them a Revoked response. Further, if testing shows that the terminals won't work, that testing should produce a fingerprint that can identify the machines to Symantec's OCSP responders. So, if user agent testing is allowed, the preferred approach should be for Worldpay to only produce non-revoked OCSP responses to those terminals, rather than whitelisting Firefox. > 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. > This seems much too vague. WorldPay should commit to a date by which their systems will be updated to support SHA-256 certificates, and publish this date to cabfpub. Mozilla should not permit issuance of certificates with notAfter dates after that date. If the committed-to timeline is > 90 days, Mozilla and Symantec should encourage WorldPay to beat their deadline. Mozilla can do that by notifying this list (or requiring Symantec or WorldPay to do so) in advance of a renewal taking place, in case there is relevant public input. If WorldPay turns out to need an extension to their committed date, the process we're doing right now should repeat in full (with more notice), and the extension should be treated as a newly proposed exception. > > 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. > I would add a requirement that further applicants for exceptions do so here, on the mozilla.dev.security.policy list, and that they must provide more than a few days' notice. This would ensure that neither Mozilla nor the community get jammed like this again. 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. > As Andrew Ayer said, the biggest danger here is allowing a poor precedent. Anyone getting an exception should have dire needs that affect the general public, and the experience of getting that exception should not be pleasant. This seems quite fair, in the face of the rather audacious security exception they are asking the web PKI to create for them, and Mozilla is asking the community to accept, especially after so many others with dire use cases have been turned down. And again, some questions Mozilla should get prompt answers to (and share with this list) if at all possible before making a decision include: * What customer segment is affected by this issue? * Will a universal Revoked response from Symantec's OCSP servers result in the terminals failing to operate correctly? * What date is WorldPay willing to commit to, by which they will have fixed these terminals? -- Eric > > Please comment on whether this proposal seems reasonable, being aware of > the short timelines involved. > > Gerv > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
