Re: [TLS] Status of X.509v3 TLS Feature Extension?

[Nico Williams <[e-mail]>]

On Tue, Apr 29, 2014 at 4:25 PM, Adam Langley <[e-mail]> wrote:
> On Tue, Apr 29, 2014 at 2:22 PM, Nico Williams <[e-mail]> wrote:
>> Why couldn't that work?  There'd be a need to cache OCSP Responses for
>> intermediates, sure.  What else?
>
> That's totally viable, I'm just suggesting that revocations of
> intermediates are very rare and generally involve browser pushes in
> any case. So the effort of getting a server that does multi-stapling
> over just stapling, and of shipping the extra OCSP responses in every
> handshake, might well win out. I think it would be quiet reasonable
> for a site to have Must Staple just for the leaf certificate.

I suspect that for intermediates closer to the server it'll be best to
staple responses.  For intermediates closer to the root issuer it'll
be best to deal with pushing.

We have to consider environments where long cert paths are involved,
and where network connectivity isn't universal.

Of course, in bridged PKIs the RPs have to handle revocation checking
for part of the cert path anyways.

I think the right thing to do may well be to implement full stapling
but configure partial stapling as appropriate:

a) stapled OCSP checking on the client side
b) CRL checking / push on the client side
c) full _and_ partial OCSP stapling on server sides

d) server admins need to configure stapling (and refreshing) of
whatever length of the server cert chains is appropriate, from the
leaf towards the root.

Nico
--