[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: OCSP Algorithm Agility




At 1:38 PM -0700 9/21/07, Paul Hoffman wrote:
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

Paul,

You are correct that to impose a total ordering on what may be more appropriately described as a lattice implies a value judgement, and the responder and client might have different perspective. However, the responder, by publishing the list has expressed its total ordering, and has defined the set of algs that it supports. That allows the client to:

- if the client wants to rely on the responder's total ordering value judgement, the extension offers a verifiable reference for that.

- if the client wants to use his own total ordering, he knows what set he can chose from, and thus can avoid offering a subset of his capabilities that will not overlap with that of the responder.

Lookng at your example, the CA should revoke the OCSP responder's cert with the newly compromised, bad algs, and issue a new one. yes, this is imperfect because we an encounter a circular revocation status problem for a responder. but I think this can be managed in a practical way by establishing a reasonable re-issue frequency for the responder's cert.

Steve