RE: OCSP Algorithm Agility

["Hallam-Baker, Phillip" <[e-mail]>]

From: [e-mail] on behalf of Stefan Santesson

>Security:
>None of the presented threats is not a great concern for me. 
>Downgrade attacks is only useful if we use algorithms that can be broken.
>I would expect an organization to only allow algorithms that provide adequate security.
>The stolen OCSP key is neither a problem for me from a protocol perspective. We have revocation.

Agreed, the issue here is not security, it is interoperability. 


>Practical matters:
>I can only find one practical matter that concerns me. I have an OCSP server and of 
>some reason I want to gradually transition responses to be based on say ECC with 
>SHA 256. Some clients can only verify RSA with SHA-1. The reason for doing this 
>transition may be entirely policy oriented. Now I would like to know which clients 
>that can actually verify my upgraded responses.

That is the concern that led to the proposal. 
 
The assumption that the OCSP client supports the same set of algorithms as the 
certificate relying application does not hold 
 

>What can I do today:
>The server can draw a number of conclusions today.

>1) Looking at the hashAlgorithm of the CertID
>2) Looking at the signatureAlgorithm used by the client to sign the response
>3) Looking at the certificate actually being validated

>None of these are 100% bulletproof to cover all corner cases. But are they 
>good enough and is the remaining gap big enough to motivate a protocol update?
 
As a design principle I prefer a protocol where the client can specify
what it wants over one where the only option is for the server to guess.
 
I find that approach is much more likely to lead to reliable interoperation.
 
 
The solution proposed is 100% backwards compatible, the old approach being:
1 Server guesses what algorithms the client supports
 
The new approach is:
1 Server looks to see if the client specified what algorithms are supported by the client
2 If none specified server guesses what algorithms the client supports as before

If either the client or the server does not support the proposed extension 
the other party simply downgrades to the status quo.