Following up to myself:
The real discussion seemed to have started in 2006...
Some folks had a pretty reasonable opinion at some point of the discussion,
e.g. Russ Houseley:
http://www.ietf.org/mail-archive/web/pkix/current/msg03570.html
and then there is lots of real dirty horse-trading in the PKIX discussion.
Oh, here is a message from the Security AD back then (Sam Hartman),
commenting on requirements for rfc2560bis (the I-D under last call right now!):
http://www.ietf.org/mail-archive/web/pkix/current/msg03515.html
What I don't understand: during the PKIX discussion there seemed to
be some consensus that a prerequisite to abuse the "unauthorized(6)"
would an update of rfc2560 would be required.
But rfc5019 *NEVER* updated rfc2560!!
But what puzzles me most is why is there a problem with defining new
error codes in the first place?
In order to NEVER EVER have such a problem again in any future IETF
spec, there should be a requirement for error code partioning upfront
into good, temporary and final, and there should be reserved error code
points that clients will have to handle gracefully and well-behaved
when they receive it.
I find it most difficult to believe that there are OCSP clients out there
that would crash and burn if they received an OCSPResponseStatus (7),(8)
or (9), rather than an "unauthorized(6)", undefined or a different undefined
return code for the underspecified error situations created by rfc5019
(and rfc2560, as Sam correctly points out).
Should there be such broken clients, then you really do not want to use
them in the first place, because *EVERYONE* can feed those OCSP clients
arbitrary error codes in unsigned OCSPResponses.
-Martin
Martin Rex wrote:
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