Re: OCSP response pre-production

["Florian Oelmaier" <oelmaier@xxxxxxxxxxx>]

> David Engberg wrote:
> > I would prefer a signalling mechanism that does not require two 
> > round-trip communications to establish nonce support, 
> 
> May I say we should *NOT* aim to fullfill this ?

Seeing that it is rather easy to do it (as shown in both proposals), I would vote for fullfilling this requirement.

> My opinion is :
> - 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. 

A lot of clients use AIA to find the OCSP-URL and use the OCSP-signing certificate extension to trust the OCSP Responder. The case of contacting an "unknown" OCSP-Responder will even become more important the more PKIs we find our there.

> - The global security brought by trying to get a fresh response, but 
> being ready to accept a non-fresh one, can hardly be said to be any 
> different from directly accepting a non-fresh one. If the system was 
> audited, I'm doubtful auditors would think it brings any real difference.

With our proposals this depends on the responder. If your responder supports nonces, the described client WILL use it. If your responder does not, the client will not. The client will NOT accept a nonce-less response from a responder being able to support nonces. 

Thus an auditor will see a real difference regarding certificates from some CAs - as for certain CAs a client will not accept nonce-less OCSP responses. This is a very common thing for every auditor out there: having CAs with different trust levels.

Additionally when an OCSP client (for example an SCVP server) detects multiple paths for a given certificate, the "freshness" of a validation may be used in a policy to establish a certain "trust level".

-- 
Florian Oelmaier
SyTrust