[cabfpub] FW: Short lived OCSP signing certificate

[Ryan Sleevi]

On Tue, Sep 18, 2012 at 9:05 AM, Rich Smith <richard.smith at comodo.com>wrote:

> I am still opposed to issuance of any certificate without revocation
> information.  Yes, the BRs allow a signed OCSP response to be good for 10
> days.  My understanding for the reasoning behind that is that it is
> extremely time consuming to resign hundreds of thousands of "Good" OCSP
> responses for all of the valid certificates which a CA may have issued and
> some large CAs require nearly that whole time to cycle their responses.  It
> does not mean that the CA is going to wait 10 days to publish a "Revoked"
> response if they revoke the certificate even minutes after signing an OCSP
> "Good" response.  I can't speak for other CAs, but at Comodo, that
> "Revoked" OCSP response replaces the previous "Good" response almost
> immediately no matter how much time is theoretically left on the "Good"
> response.  I suspect that other CAs behave in a similar fashion.  The
> disconnect here seems to be that the relying parties take that 10 day
> lifespan to mean that they can leave off checking to 10 day intervals and
> that is faulty reasoning.  IMO, that 10 day timeframe SHOULD NOT be used in
> caching OCSP responses in browsers, nor should it be used in stapling.
> Browsers and servers using stapling do not have to resign hundreds of
> thousands of responses, they just have to retrieve responses periodically.
> As such, IMO, they should be doing that at least every 24 hours, not every
> 10 days.
>

Is there any browser that implements the behaviour you've described?

Every cryptographic stack I've looked at has treated the validity time of
the response as just that - that the response is still valid until such a
time as it is not valid.

While different clients, most notably CryptoAPI, provide some buffer around
expiration to prevent stampeding herd situations upon response expiration,
I'm not aware of any client that aggressively checks such responses.
Considering the discussions had just a few weeks ago regarding the caching
behaviour of clients, which expressed just such a concern, it seems this is
well understood and acknowledged.

If we accept that clients today do exactly what the spec says they can do,
and which you suggest they should not do, what about the security model can
we discover? Well, if a malicious party can obtain a valid CRL at such a
point in time where its validity covered the time in question, or if they
can obtain an OCSP response when the request was valid and with a validity
period that eclipses the certificate, then an attacker can fraudulently
"un-revoke" a certificate - by masking the revocation.

One terribly easy way to do this, for many clients, would be to simply
staple the OCSP response as part of the SSL handshake. No terrible special
network hijinks necessary - the client will accept that (signed) OCSP
response, with a validity period that is suitable, and merrily go on its
way.

For those reaspons, I'd contend that, again, as the vast majority (all?)
browsers are implemented today, short-lived expiration does not have a
meaningful security difference for those users.

Now, that's not to say there aren't any differences, but none so tangible
as to provide benefit to users in at-risk situations, ergo, the differences
are academic more than practical.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20120918/66d2463a/attachment-0004.html>