Re: OCSP response pre-production

[David Engberg <dave@xxxxxxxxxxxxxx>]

Jean-Marc Desperrier wrote:
> Clients that requires freshest response send a nonce, and get back an 
> error if it's not possible to give freshest response.
> Client that don't require it, send no nonce.
>
> Client that would like it, but don't require it, make a round trip, and 
> cache the fact the server can't supply freshest response, so they do the 
> round trip only once.

I could live with a two-trip solution as an alternative as long as the 
error is contained in a signed message which can be pre-generated for 
that responder.  If the error is in the unsigned portion of the 
protocol, a client can't really tell a nonceUnsupported server from an 
attacker on the network, which means its only realistic option is to 
reject the response and quit.

An extra round-trip communication is unfortunate, but not a show-stopper 
if it conveys some other fundamental advantage that I'm missing.



> - in real life implementations, it's not so common to both trust an OCSP 
> responder, and not know in advance if it can supply fresh responses or 
> not. Even if it's the case, there won't be so many different OCSP 
> responders, and it won't take long to discover they don't provide fresh 
> answers.

You may be only thinking of closed internal PKIs with one or two CAs and 
hard-coded clients.  I'm thinking of the broader case where I may want 
to accept signed emails from everyone that chains or bridges to one of 
my trusted roots.  I may accept signed emails from employees of Acme 
Novelties because their CA chains to a Verisign root, and their AIA OCSP 
responder was properly delegated by their CA (OCSP Signing).  I 
certainly have no idea whether Acme's responder keys are online 
(nonce-supporting) or off (nonceUnsupported) before my first request, 
even though I'm prepared to accept whichever security policy the CA chooses.

I think it is a valid and secure _option_ for a client to say "accept 
the revocation security policies chosen by trusted CAs and/or 
responders."  If a CA only publishes CRLs every 24 hours, its OCSP 
infrastructure should be able to signal to interested clients that they 
shouldn't waste everyone's time and CPU cycles by sending nonces just to 
get "fresh" views of the same cached CRL.