RE: OCSP Algorithm Agility

["Andrews, Rick" <[e-mail]>]

Santosh,

Sorry for the long delay in responding - travel and vacation.
 
Not all OCSP responders work from CRLs, so they won't take their cue
from the CRL. Nor should they take their cue from the signature on the
cert in question, I believe. Let me try to restate my argument in a
different way.
 
With SCVP delegated path validation, the client requesting a cert's
status from an OCSP responder will be different from the client at the
other end of the SSL connection. Those two clients may have very
different capabilities in terms of supported signature and hash
algorithms. It's not realistic to expect that all SSL clients, all SCVP
servers, and all CAs will be able to upgrade in lockstep to new
algorithms as they are developed. Allowing the OCSP client and server to
negotiate a mutually-acceptable set of algorithms is essential to the
deployment of newer, stronger algorithms.
 
Likewise, companies that run large OCSP responders may wish to gradually
move to ECC-based signatures for all their OCSP responses, even those
for certs with RSA or DSA keys, because ECC signatures are cheaper to
produce. If algorithm agility is added to OCSP, those companies can
gradually achieve the move to ECC without disrupting the installed base
of OCSP clients that don't support ECC.
 
-Rick Andrews 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Santosh Chokhani
> Sent: Friday, September 21, 2007 2:45 PM
> To: Paul Hoffman; Stephen Kent; [e-mail]
> Subject: RE: OCSP Algorithm Agility
> 
> 
> Paul,
> 
> Here are my views on this.
> 
> The client should be first asking for the algorithm suite 
> that signed the certificate in question.  There is no need 
> for the client to ask for anything stronger.  The client can 
> ask for stronger suites as secondary, if client has them.
> 
> In the scenario you cite, the Responder certificate will not 
> include RSA with SHA 1 any longer.  So, client will know that 
> Responder only supported his second choice and he should be 
> ok with it.
> 
> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]]
> On Behalf Of Paul Hoffman
> Sent: Friday, September 21, 2007 4:39 PM
> To: Stephen Kent; [e-mail]
> Subject: RE: OCSP Algorithm Agility
> 
> 
> At 2:07 PM -0400 9/21/07, Stephen Kent wrote:
> >How about defining an extension to be included in the cert 
> issued to an 
> >OCSP responder by a CA.  The extension would have an ordered list of 
> >algorithms (hash and signature if we want to address more 
> than the hash 
> >agility issue) accepted by the OCSP responder.  An OCSP 
> client can use 
> >this info to determine what is the "best" algorithm (or alg 
> pair) that 
> >it and the responder share. The combination of this extension and an 
> >OCSP negotiation procedure will allow the client to detect MITM 
> >downgrade attacks. In fact, if the client acquires the 
> responder's cert 
> >prior to making a request, there would not even be a need for real 
> >negotiation, since the client would know what alg to request in a 
> >response.
> 
> Imagine the list of algorithms is RSA-with-SHA1 first and
> DSA-with-SHA1 second. How does your negotiation work? The 
> client asks for this message to be signed with RSA-with-SHA1. 
> But the server knows that RSA-with-SHA1 has been compromised 
> since it got that certificate from the CA. What does the 
> server say to the client to indicate that it only wants to 
> sign with DSA-with-SHA1? What prevents Mallory from saying 
> the same thing to the client?
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
> 
>