Re: [TLS] OCSP must staple

[Kurt Roeckx <[e-mail]>]

On Sat, Jun 07, 2014 at 05:06:19PM +0000, Viktor Dukhovni wrote:
> On Sat, Jun 07, 2014 at 06:49:45PM +0200, Kurt Roeckx wrote:
> 
> > > Once revocation is a scalable working process, then we can benefit
> > > from insisting on OCSP stapling, provided we figure out what to do
> > > with servers that don't have any way to reach out and refresh OCSP
> > > responses for stapling, nor support interface for an agent to
> > > obtain the response on the server's behalf and push it into the
> > > server's configuration.
> > 
> > I do not understand what you're really trying to say here.
> > 
> > I think we all agree that we want everybody to do OCSP.  I think
> > we also want everybody to do OCSP stapling by default when
> > possible.  But that doesn't mean we want everybody be forced to
> > do OCSP stapling.
> 
> If CAs start issuing "must staple" certificates, isn't that "forced"?

This will only add the posibility to do so.  And CAs may wish to
enforce this on some (high traffic) sites.  But it's not because
you make this posibile that they will do this for all
certificates.

> > I fail to see how this relates to revocation process.  If there is
> > a problem in the revocation process having CRL, OCSP, OCSP
> > stapling, or OCSP must staple will all have the same effect.
> 
> I don't see much value in (especially) CRLs or (even) OCSP stapling
> without a scalable effective revocation process.

So are you saying that if a CA wants to use "must staple" it must
also do something about it's revocation process?

I think that if you think there is something wrong with the
revocation process you should try to address that problem
independant of how we check the revocation status.

> > I am curious about your use case for servers that can't refresh
> > the OCSP response.  And is this any different in the case of CRLs?
> > Or are you just happy to ignore the non-existence of the CRLs?
> 
> CRLs don't scale, client initiated OCSP to CA leaks too much
> sensitive data to the CA, and and fails open.  OCSP stapling is
> the only revocation mechanism left standing, but some servers
> will have difficulty supporting it.

What is the difficulty in supporting it?

> Not all servers are HTTP
> servers, and servers may lack "HTTP client" capabilities to
> connect to the CA's OCSP responder.

If it can already to TLS, I would think that being an HTTP client
to get an OCSP response can't be that hard.  An HTTP server isn't
special in being able to act as HTTP client.

> Servers may be on networks
> where they have to traverse various firewalls, proxies, ...
> to get to the OCSP responder, the burden may be too high.

If it's too high for the server, it's most likely to high
for the clients to and you should consider using an internal
CA instead.


Kurt