On Tue, Feb 23, 2016 at 6:26 PM, Eric Mill <[email protected]> wrote:
> 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. > I got some feedback privately that encouraging "split-horizon" OCSP is really architecturally a bad idea, and I have to say I agree. I think we got caught up in the technical aspects of simulating a revocation for the web as faithfully as possible, but on further thought, it's important that a certificate's status have a single, global value that is reflected in OCSP. However, Symantec and WorldPay say that the affected devices do check OCSP, so a globally uniform revocation would not allow these devices to continue to operate. So we would have to rely on OneCRL. I can probably live with this; OneCRL has been in Firefox for long enough (since 37) that the base of old browsers that don't get OneCRL information should be fairly small. --Richard >> 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
