[cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

[Rick Andrews]

I'm not sure I'm following you, Ryan. Are you saying that short-lived certs don't need an AIA pointer as long as the OCSP response is stapled? I buy that, but what happens when the stapled response has expired or can't be cryptographically validated or doesn't get returned at all? If the client hard-blocks, I buy that too. But I doubt browsers would do that, and I'd prefer that there was a fallback method. That's why I'd like to see AIA extensions even in short lived certs.

My logic was this: I see a 2-year cert that was issued one day ago; the CA must have thought it was valid or it wouldn't have issued it; the CA very likely also issued an OCSP response that says the cert is good for the first 7 days; even without fetching the OCSP response I can conclude that even if I fetched one or got one via stapling, it would say that the cert was valid. Since I already know the answer, I don't have to ask the question.

Orthogonal idea: If CAs feel they want to experiment with short-lived certs and they must be signed under public roots, would it make sense to spin up new roots just for that, perhaps with a meta-data bit that browsers would use to expect that only such roots would sign short-lived certs?
-Rick

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Friday, March 22, 2013 5:44 PM
To: Rick Andrews
Cc: ben at digicert.com; CABFPub
Subject: Re: [cabfpub] OCSP Stapling and Short-Lived Certificates Proposal



On Fri, Mar 22, 2013 at 5:38 PM, Rick Andrews <Rick_Andrews at symantec.com<mailto:Rick_Andrews at symantec.com>> wrote:
I'm very much in agreement with Eddy on this.

Consider this: If I take the basic argument that you don't need to check revocation on a short lived cert (say, valid for 7 days) because the CA's OCSP responses are also good for 7 days, then I would claim that when SSL clients (browsers) see a long-lived SSL certificate, they can skip revocation checking if the cert is less than 7 days old. I certainly wouldn't want browsers to do that.

-Rick

I'm not sure I follow your logic, Rick.

If the browser has obtained a valid OCSP response (eg: via OCSP stapling), they can skip obtaining fresh revocation information - because to every compliant implementation, it IS fresh revocation information.

If there's NO revocation information, I don't think the same argument applies.

The point of the discussion here is not about what the exact behaviour is - but what the effective security is. And in the case of short-lived certs, the effective security is identical.

It's certainly reasonable to discuss whether the effective security is IDEAL, but that's a separate discussion than the one we're having - which is establishing whether or not the effective security of a short-lived cert is the same effective security as providing revocation information.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20130322/ff3da8a8/attachment.html