Stefan Santesson wrote:
Unfortunately what you suggest would not be backwards compatible,
and can't be done within the present effort.
I'm sorry, I can not follow your arguments.
Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7),
single_requests_only(8), unsupported_extension(8) } with well-defined and
conflict-free semantics to the existing enum would be perfectly backwards
compatible.
Whether and when implementations of rfc5019 or its successor can make
use of additional error codes with well-defined semantics is a seperate
issue.
Sending multiple entries in a requestList is a perfectly valid client
option in rfc2560. rfc5019 has a requirement for single entries.
What response does rfc5019 define in case that it receives an OCSP request
with multiple entries in requestList.
Keep in mind that OCSP responders are typically located through
Authority Identifier Access "id-ad-ocsp", and that cert extension is
specified to provide for the conventions of rfc2560 -- *NOT* the subset
of rfc5019:
http://tools.ietf.org/html/rfc5280#page-51
The id-ad-ocsp OID is used when revocation information for the
certificate containing this extension is available using the Online
Certificate Status Protocol (OCSP) [RFC2560].
When id-ad-ocsp appears as accessMethod, the accessLocation field is
the location of the OCSP responder, using the conventions defined in
[RFC2560].
Responders using 5019 need to work in foreseeable time with legacy clients
that knows nothing about the update you suggest.
This group and the IETF made a decision when publishing 5019, that using
"unauthorized" in the present manner was a reasonable tradeoff.
I still think it is.
Could you point me to any kind of discussion of this "tradeoff"?
I'm having difficulties finding that information.
The first draft that became rfc5019 seems to have appeared here:
http://www.ietf.org/mail-archive/web/pkix/current/msg17432.html
and it already contained the abuse of the "unauthorized(7)" error code.
I see a first complaint on the mailing list about the error code abuse here
on 02-Nov-2004:
http://www.ietf.org/mail-archive/web/pkix/current/msg17270.html
but the reponse is -crickets-.
In what way is the client going to treat "unauthorized(6)" special and
different from other error codes, such as "internalError(2)" or
"malformedRequest(3)", and where in rfc5019 is that special behaviour
defined?
-Martin