Re: [pkix] An alternative proposal Was: Fwd: New Version

[Martin Rex <[e-mail]>]

Rob Stradling wrote:
> 
> > He said:
> > > So we pay like $100/200 for the SSL certificate, and then we pay again
> > > server and bandwidth fees to answer OSCP ?
> > 
> > That sounds like he thought that you were requiring him to do OCSP
> > responding, not OCSP stapling.
> 
> I took "pay...bandwidth fees to answer OCSP" to be referring to the extra 
> ~1-2K he would need to serve for each TLS handshake that contains a stapled 
> OCSP Response.
> 
> I understood his complaint to be: Clients can fetch this data from the CA,
> so why should he be required to serve it?  The CA already received money
> for the cert, so the CA should foot the bill for serving the revocation
> information. (IMHO, this complaint is not entirely unreasonable).


I checked the current proposal for an TLS extension for stapling
multiple OCSP responses:
  http://tools.ietf.org/html/draft-pettersen-tls-ext-multiple-ocsp-02

and single-OCSP response:
  http://tools.ietf.org/html/rfc6066#section-8

and I consider both pretty disappointing and useless for the purpose
of more efficient OCSP processing.

The idea to require the server stalling the TLS handshake to obtain an OCSP
response from some arbitrary client-specified OCSP responder with
some arbitrary OCSP request attributes is IMHO a very bad idea for
the general use case; I would never want my servers to perform such
requests and can understand other server operaters who do not want
this either.


A generally useful TLS extension for OCSP response stapling should be a 
"take it or leave it approach", i.e.  the server provides OCSP stapling
for exactly the (first) OCSP responder in the OCSP AIA resources of the
certificate(s) of the server certificate chain and both server and client
can cache these responses for a few hours, and the client can indicate
whether it still has cached OCSP-responses available and for which
server certificate chain, which would obviate the sending of the
stapled OCSP responses with each and every handshake (such as
abbreviated TLS handshakes, aka session resumes) and still work
successfully/transparently for credentials updates on the server.


-Martin