ietf
[Top] [All Lists]

Re: [pkix] Last Call: <draft-ietf-pkix-rfc2560bis-15.txt> (X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP) to Proposed Standard

2013-03-26 00:28:50
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(_at_)sap(_dot_)com> 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(_at_)ietf(_dot_)org 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



<Prev in Thread] Current Thread [Next in Thread>