[cabfpub] Revised document for Ballot 89 - Adopt Guidelines...EV SSL Certificates - All Else

Brian Smith bsmith at mozilla.com
Thu Nov 8 07:23:31 UTC 2012

Rick Andrews wrote:
> Brian Smith wrote:
> > The BR define requirements on the information that CAs publish,
> > not on browser's interpretation of that information. I think it
> > 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
> > response.
> 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.

A lot of CAs are publishing revocation information that is valid for 7+ days. That means there's a 7+ day attack window. I understand why some CAs might think that a 7+ day attack window is the best trade-off. But, that doesn't mean that the browser has to agree to that. IMO, it is still an open question as to what size attack window is reasonable.

Note that RFC 2560 is very clear that the time fields in an OCSP response imply a recommended, not mandatory, validity interval:

   The thisUpdate and nextUpdate fields define a recommended validity
   interval. This interval corresponds to the {thisUpdate, nextUpdate}
   interval in CRLs. Responses whose nextUpdate value is earlier than
   the local system time value SHOULD be considered unreliable.
   Responses whose thisUpdate time is later than the local system time
   SHOULD be considered unreliable.

And, also note that nextUpdate is optional, which means that browsers must have a caching policy that can be implemented without any recommended validity interval.

In general, though, my goal is to narrow the attack window as close to zero as is practical. 

> 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?

I think these concerns sound worse in theory than they actually are in practice, based on our experience. I think the main concern is shortening the response time. Regardless, I think we (Mozilla) can address these concerns relatively easily and I'm expecting that we'll do so soon.

>  - 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.

Likewise, I want to improve the existing system we (Mozilla) have, rather than switching to a different system that has severely negative side-effects for our users. I hope that we can find some common ground so that we both get what we want. But, the idea that our browser is going to block connections on OCSP or CRL fetching for intermediates from roots in our CA program is a complete non-starter. Like I said on this list several weeks ago, it's already been decided at Mozilla that we're not going to do OCSP/CRL requests for intermediates that chain to roots in our program.

> 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?

In general, security incidents that affect Mozilla should be reported as described here:

The other browser vendors have similar reporting mechanisms. I do think it is a good idea to also publish this information from your OCSP responders and CRL distribution points, and I also think it is a good idea to issue a CVE for every such incident.

I will work with Kathleen to update our CA inclusion policy to make the requirements on notifying us about security incidents clearer, since multiple people have now said that the requirements are unclear. Also, I think that we may be able to make a new reporting mechanism that is better than using email and which addresses some of your concerns above directly.

> > 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.

Currently (but perhaps not in the future), we do follow the suggested validity interval in OCSP responses. In fact, as others have noted, we are usually much more careful about getting fresh revocation information than the nextUpdate date suggests we should be, since we don't have a persistent OCSP cache. Regarding the other two points, you are right that we don't (and won't) do those things, at least for CAs in our root program. We will implement better solutions.


More information about the Public mailing list