RE: OCSP Algorithm Agility

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

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: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On Behalf Of Paul Hoffman
Sent: Friday, September 21, 2007 4:39 PM
To: Stephen Kent; ietf-pkix@xxxxxxx
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