>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.