On Tue, Feb 23, 2016 at 1:57 PM, Gervase Markham <ge...@mozilla.org
> 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:
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
Symantec may issue certificates to Worldpay if the following things are
> 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
> 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
> Please comment on whether this proposal seems reasonable, being aware of
> the short timelines involved.
| @konklone <https://twitter.com/konklone