[cabfpub] OCSP Stapling and Short-Lived Certificates Proposal

[Ryan Sleevi]

On Fri, Mar 22, 2013 at 5:59 PM, Rick Andrews <Rick_Andrews at symantec.com>wrote:

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

No. I'm saying that an AIA pointer is meaningless (because it's ignored) in
the presence of stapling.


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

This is orthogonal - but the OCSP must-staple use case explores the
staple-or-hard-fail scenario. Ryan Hurst has discussed at length the "can't
be cryptographically validated" case.

These are separate from short-lived certs, but I did want to make sure you
were aware that conversations are going on.


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

As stated before, the AIA is pointless if the attacker can return a
cryptographically valid, un-expired response. Which they can, and since the
whole point of stapling to begin with is to avoid the need to chase down
the response, the AIA provides no added security value for the client.


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

No, that's not a fair assumption. We're not proposing psychic browsers -
we're just showing how, by very design of the protocol itself, it can be
exploited by an attacker for a certain period of time - the same time
period being proposed for short-lived certs.


> Since I already know the answer, I don’t have to ask the question.
>

That's not something that has been proposed by anyone on this list - that's
why I objected.

We're not proposing not asking the question - but we have demonstrated that
when you do ask the question, IF you got a valid answer within the validity
period, then from a security perspective, there is no added security from
repeatedly asking the question - because even if the answer changes, you
can be repeatedly lied to.


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

If we accept the effective security is identical, then the only effect such
a proposal would have would be to unnecessarily increase the barriers to
entry.


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