[cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

[kirk_hall at trendmicro.com]

I think Eddy, Rich, and Rick all are on the right track.  Take the simplest case - a CA issues a short lived cert, and within an hour realizes it's been punked by an imposter.  What to do next - no ability to revoke?  Just say, "oh well, it will all be over in a week."  Contact every browser and application in the world and say "Will you issue a patch to un-trust this bad cert I just issued with no ability to revoke?"  (Sounds a little like Diginotar...  no ability to revoke.)

We as an industry should not let the perfect be the enemy of the very, very good.  With revocation checking in place for *every* cert, a bad short-lived cert that is revoked should return a negative response ("revoked") for very many users - maybe not everyone, but many.  That's a good thing.  In my mind, it is not responsible for CAs and browsers to say "If we can't convey a message of "revoked" to 100% of users during the 7 or 10 day validity period of the short-lived cert, it's not work conveying that message to *any* user."

Caching, stapling, failure of browsers to bother checking for revocation, etc. etc. should not change this, in my opinion.  If a CA is to be trusted by the world in issuing a cert (short or long lived) that is deemed "good" to the world because the CA's roots are in the browser or application, I believe the CA has a duty to be alert and diligent at all times, and to revoke that cert for a problem, even if it only has 7 or 10 days to go until expiration.  If others don't want to check for revocation, that's their decision, but we CAs shouldn't enable that kind of practice by turning off revocation.  (And shortening the next update time to 24-48 hours is a great idea - let's do it.)

Finally, I'm guessing that any short lived cert issuance process is going to be totally automatic - machine to machine from CA to customer - repeated constantly unless turned off - without human intervention unless something goes wrong.  I don't trust automatic processes like that - how will the new short lived certs get through the customer's firewalls to be installed, and how will the customer be sure the new cert is automatically installed correctly on the right servers - so I see potential new vectors for attack (or simple screw up).

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Rick Andrews
Sent: Friday, March 22, 2013 6:00 PM
To: Ryan Sleevi
Cc: CABFPub
Subject: Re: [cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

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.

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130323/6656fbd8/attachment-0003.html>