[cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

[Ryan Sleevi]

On Fri, Mar 22, 2013 at 10:14 PM, kirk_hall at trendmicro.com <
kirk_hall at trendmicro.com> wrote:

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

Kirk,

If the CA has issued a valid, signed OCSP response, then they have no
ability to revoke that certificate for any client that supports stapling,
until that OCSP response expires.

That's the reality of today's deployed market and the Web PKI. As such,
short lived certs do not change the threats here.


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

As explained by several others, the "very many" is an intentionally
shrinking number, as more and more relying parties support techniques like
OCSP stapling.

This is a GOOD thing - as OCSP stapling can improve performance AND the
reliability of revocation information - and this makes SSL a better, more
secure solution.

The only way to address the "revocation issue", as you present it, would be
to encourage clients NOT to support OCSP stapling. And that would be an
enemy of the quite good indeed.


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

Well, despite opinions to the contrary, the facts and deployment is that it
does. Which is the point :-)


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

CAs enable this practice today, by providing OCSP responses.


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

While understandable that there are technical complexities, the CA/Browser
Forum should not attempt to prevent new markets or new techniques that can
improve security - especially when they are demonstrably no worse than the
existing security guarantees provided to relying parties by forum members.


> ****
>
> ** **
>
> *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>
> 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.****
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130322/d94a7df6/attachment-0003.html>