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