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