[cabfpub] Revised document for Ballot 89 - Adopt Guidelines...EV SSL Certificates - All Else
Rick_Andrews at symantec.com
Thu Nov 8 02:26:12 UTC 2012
> -----Original Message-----
> From: Brian Smith [mailto:bsmith at mozilla.com]
> Sent: Wednesday, November 07, 2012 2:01 AM
> To: Rick Andrews
> Cc: public at cabforum.org
> Subject: Re: [cabfpub] Revised document for Ballot 89 - Adopt
> Guidelines...EV SSL Certificates - All Else
> Rick Andrews wrote:
> > IMO, your proposal raises another issue: what if the later OCSP fetch
> > fails because the attacker is in the middle or has otherwise changed
> > the certificate to a different one? The browser would have to be
> > careful to only continue showing the EV treatment if the same
> > certificate was returned. I think it would be simpler to take down
> > the EV treatment if the browser can't verify that the cert is valid,
> > whenever it does a new handshake, rather than come up with more
> > rules about when it's ok to continue in the case of an OCSP failure.
> I don't understand your question. Any cache of revocation information
> would be keyed on serial number and issuer or equivalent, so
> effectively we would always do the "same cert" check. And, though I
> agree your suggested method is simpler, it is a horrible UX, and that
> horrible UX is what I'm trying to avoid.
OK, now that I understand how you're doing it, I agree that my scenario isn't realistic.
> > I'm not understanding something. The cached revocation information,
> > whether CRL or OCSP, can't be valid longer than 10 days (according
> > to the BR). Why would FF cache it for longer than that?
> The BR define requirements on the information that CAs publish, not on
> browser's interpretation of that information. I think it is important
> to have latitude in how long we accept a stale OCSP response. I know
> others at Mozilla have suggested that we should never cache revocation
> information longer than 24 hours (regardless of the dates in the OCSP
> response). I actually think that it may be more reasonable to make the
> length of time we trust cached revocation information a function of the
> length of time the certificate has been "alive," and perhaps that
> caching could even extend beyond the nextUpdate date in the OCSP
I'm surprised by this. We, and probably most other CAs, are very diligent about updating CRLs and OCSP responses before they expire, so there's no gap but more importantly so end-users are notified of a status change sooner rather than later. We won't serve up any expired revocation status. Why do you think it may be reasonable to cache status information after a CA has said it's expired? That may improve the browser's performance but at the expense of security, IMO.
> > I cite an example below where Firefox, for non-EV certs, violates RFC
> > 5280 Section 6.1.3 by not checking the status of intermediates.
> That is not true and I clarified this in an earlier message. Notice
> that RFC 5280 says "At the current time, the certificate is not
> revoked. This may be determined by [...] out-of-band mechanisms." We
> provide all of our CAs with an out-of-band mechanism for notifying us
> about security incidents, including in particular mis-issuances and key
> compromises of intermediate certificates. You just have to email us a
> description of the security incident along with the technical
> information about the affected certificates. When we are notified about
> a mis-issuance or a key compromise we will ensure that our product dis-
> trusts the certificate and related certificates from other CAs
> (assuming those other CAs cooperate). Usually that distrust will become
> effective well within the time period suggested by the "nextUpdate"
> time in an OCSP response, and also this distrust is more comprehensive
> than an OCSP check would be, because we distrust related certificates
> from other CAs after being notified of such security incidents.
I will concede that according to the letter of the RFC, you comply because you have an out-of-band means. But I'm definitely not in favor of using that means, for several reasons:
- "You just have to email us" How secure is that? How do you know it's me? The email isn't signed, but an OCSP response and a CRL are.
- It's quite a burden for a CA to have to locate contact info for each and every browser to notify them. AFAIK, it's not collected together somewhere. Do I just email CABF members?
- We (and probably other CAs) have invested a lot of money into our CRL and OCSP infrastructures. We don't want to use a different out-of-band means to convey information that we already have a system for.
Is this Mozilla policy posted somewhere? Do all the CAs who have roots in Mozilla's trust store know that if they revoke an end-entity, they just have to publish a CRL and/or OCSP response, but if they revoke an intermediate, they have to contact Mozilla?
> Also, like I said in my previous message, I am very open to the idea of
> automating this. However, the current OCSP/CRL mechanism does not seem
> like an appropriate automation because we receive both too much
> information (revocations that aren't security incidents) and too little
> information (e.g. CRLs and OCSP do not include the DER-encoded X.509
> certificate being revoked, the CA's description of the security
> incident, contact information for the CA and the customer involved, and
> information about cross-signings of the certificate). But, this is
> something that we can definitely fix by working together.
> Also, I think that our proposed CA inclusion policy changes go a long
> way towards *preventing* security incidents, which is even better than
> responding to those incidents after they occur. In fact, based on
> feedback we've received from CAs and some of their customers, those
> proposed policy changes have likely already reduced risk to our users
> before they've even been incorporated into our policy.
> > It isn't asserting any new requirements beyond RFC 5280 Section
> > 6.1.3, however I wanted to make it more visible precisely because
> > some browsers (at least Firefox, maybe others) don't check
> > revocation of intermediates for non-EV certs. IMO, the CABF wanted
> > to assert that EV Certificates represented a higher level of
> > security, and this (mandatory checking of intermediates) could be an
> > example of why that is so.
> This mis-understanding is exactly why I want to be precise here. I
> think we can all agree, based on what I've said above, that not only is
> Mozilla complying with RFC 5280 to the letter, but we're in fact going
> above and beyond its requirements and doing things that aren't even
> possible with OCSP and CRL fetching. And, I hope we can work together
> to improve upon what Mozilla is already doing.
No, I don't agree that Mozilla is going above and beyond its requirements. From my perspective, Mozilla doesn't fetch CRLs unless the end-user has pre-loaded them, it doesn't check OCSP responses for intermediates, and it ignores signals from CAs on how long revocation status should be cached.
More information about the Public