Subject: Re: [TLS] Call for acceptance on multi-stapling

From: Yingxian Wang <[email-masked]>
Date: Tue, 10 Jul 2012 23:18:21 +0000 (UTC)

Eric Rescorla <ekr <at> rtfm.com> writes:

> 
> On Thu, Apr 19, 2012 at 1:48 PM, Martin Rex <mrex <at> sap.com> wrote:
> > Eric Rescorla wrote:
> >>
> >> >  - the real issue is about the management operation itself on the server.
> >> >   obtaining a new certificate from the CA typically requires mutual
> >> >   authentication, whereas obtaining a fresh OCSP staple can be
> >> >   performed over an insecure channel (followed by a validation that
> >> >   the info is valid).
> >>
> >> The assumption behind short-lived certiifcates is that they will be
> >> provided over a public channel without authentication, precisely
> >> as new OCSP responses can be. Certificates are public information
> >> so as long as nothing has changed, you just reissue with the
> >> same key.
> >
> > Sounds like an additional, brand-new enrollment protocol.
> 
> There's no additional enrollment involved. You just HTTP fetch the
> certificate from a specified location in the cert.
> 
> -Ekr
> 

Can anyone explain why OCSP stapling is never defined for the client 
certificate/chain?

I can understand that the resource and performance gains that are 
brought with server caching and reusing the certificate status check 
against many clients. However, if we are doing mutual
authentication, the client providing OCSP stapling on it's own 
certificate/chain can also result in resource and performance gains.

It just seems to me to be a small extension to the one already defined
 for server OCSP stapling in order to support client OCSP stapling.

Thanks,
Yingxian Wang
Principal Engineer,
Mocana Corp.