Unfortunately what you suggest would not be backwards compatible, and can't be done within the present effort. 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. Unless you can convince the community of your course of action, I don't see this happening. /Stefan On 3/26/13 6:28 AM, "Martin Rex" <mrex@xxxxxxx> wrote: >Stefan Santesson wrote: >> >> Whether we like it or not. This is the legacy. >> There is no way for a client to know whether the OCSP responder >>implements >> RFC 2560 only or in combination with RFC 5019. >> >> So therefore, the update that was introduced in 5019 must be expected by >> all clients from all responders. Therefore it is included in 2560bis. >> >> What in your mind, would be a better solution? > >Simply listing two mutually exclusive semantics for a single error code >looks like a very bad idea. The correct solution would be to assign >a new error code for the semantics desirec by rfc5019 and fix rfc5019 >and its implementiations. And then mention the rfc5019 semantics for >the error code "unauthorized" in rfc2560bis as defective and deprecated. > >rfc5019 is hardwired to SHA1 for the cert hashing algorithm, so >it will need to get updated at some point already. > >The second issue is to explain that the errorcode response for "can not >produce an authoritative response" is not applicable to OCSPRequests >that contain more than one element in the requestList, because the >OCSP client will not know to which elements in the request the error >code response applies. > >Actually, it would be sensible to define two more new error codes, >one that indicates that the OCSP server does not support multiple >requestList entries, and one that indicates to the client that the >server does not support one of the OCSP protocol extensions requested >by the client (multiple requests is not a protocol extension). > > >-Martin > >> On 3/23/13 7:52 AM, "Martin Rex" <mrex@xxxxxxx> wrote: >> >> >The IESG wrote: >> >> >> >> The IESG has received a request from the Public-Key Infrastructure >> >> (X.509) WG (pkix) to consider the following document: >> >> - 'X.509 Internet Public Key Infrastructure Online Certificate Status >> >> Protocol - OCSP' >> >> <draft-ietf-pkix-rfc2560bis-15.txt> as Proposed Standard >> >> >> >> The IESG plans to make a decision in the next few weeks, and solicits >> >> final comments on this action. Please send substantive comments to >>the >> >> ietf@xxxxxxxx mailing lists by 2013-03-27. >> > >> >I'm having an issue with a subtle, backwards-incompatible change >> >of the semantics of the exception case with the error code >> >"unauthorized", which tries to rewrite history 13 years into the >> >without actually fitting the OCSP spec. >> > >> >It's about the second change from the introduction: >> > >> > o Section 2.3 extends the use of the "unauthorized" error >> > response, as specified in [RFC5019]. >> > >> >While it is true that the error code abuse originally first appeared >> >in rfc5019, the change was never declared as an update to rfc2560, >> >nor filed as an errata to rfc2560. >> > >> >The original Exception cases in rfc2560 define the following semantics: >> > >> > http://tools.ietf.org/html/rfc2560#section-2.3 >> > >> > 2.3 Exception Cases >> > >> > In case of errors, the OCSP Responder may return an error message. >> > These messages are not signed. Errors can be of the following types: >> > >> > -- malformedRequest >> > -- internalError >> > -- tryLater >> > -- sigRequired >> > -- unauthorized >> > >> > [...] >> > >> > The response "sigRequired" is returned in cases where the server >> > requires the client sign the request in order to construct a >> > response. >> > >> > The response "unauthorized" is returned in cases where the client is >> > not authorized to make this query to this server. >> > >> > >> >The proposed "extended" semantics from the rfc2560bis draft: >> > >> > http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-15#page-9 >> > >> > The response "unauthorized" is returned in cases where the client is >> > not authorized to make this query to this server or the server is >>not >> > capable of responding authoritatively (cf. [RFC5019], Section >>2.2.3). >> > >> >The rfc5019 semantics "The server can not provide an authoritative >> >response >> >to this specific request" is incompatible with the semantics "you are >>not >> >authorized to sumbit OCSP requests to this service". >> > >> >There is another serious conflict with the rfc5019 repurposed error >>code >> >semantics and rfc2560. While rfc5019 is limited to a single status >> >request, >> >rfc2560 and rfc2560bis both allow a list of several Requests to >> >be sent in a single OCSPRequest PDU. An OCSP response, however, is >> >not allowed to contain responseBytes when an error code is returned >> >inthe response status: >> > >> > >>http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-15#section-4.2.1 >> > >> > 4.2.1 ASN.1 Specification of the OCSP Response >> > >> > An OCSP response at a minimum consists of a responseStatus field >> > indicating the processing status of the prior request. If the value >> > of responseStatus is one of the error conditions, responseBytes are >> > not set. >> > >> > OCSPResponse ::= SEQUENCE { >> > responseStatus OCSPResponseStatus, >> > responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } >> > >> > >> >So it is impossible to convey "OCSP responder is not capable of >> >responding authoritatively" for a subset of Requests in the requestList >> >and regular status for the remaining Requests in the List by using >> >a repurposed "unauthorized" error code. >> > >> >The current draft neither mention this contradiction, nor does it >> >provide any guidance how an implementation should behave in this >> >situation. >> > >> > >> >I would appreciate if this problem of draft-*-rfc2560bis could be fixed >> >prior to making it a successor for rfc2560. >> > >> > >> >-Martin >> >>