RE: OCSP Algorithm Agility

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

Steve,

Another way to do this securely is to let the client signal in the hash
algorithm field of the certID.  This will not be vulnerable to MITM
attack since the client can check the hashing algorithm used to sign the
response matches the hashing algorithm in the certID field.

It also provides security since if an hashing algorithm is good enough
for certificate, it is good enough for OCSP response.

It provides interoperability for the client since the client has to have
the hashing algorithm for certificate signature verification.
 
-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On Behalf Of Stephen Kent
Sent: Friday, September 21, 2007 2:08 PM
To: ietf-pkix@xxxxxxx
Subject: RE: OCSP Algorithm Agility


Folks,

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.

Steve