Martin,
I went all the way to Sam's original message about his discuss on the
draft that became RFC 5019:
https://www.ietf.org/mail-archive/web/pkix/current/msg03627.html
and reviewed the 60 or so messages in the thread.
Aside: I think when you're referring to "updating" RFC 5019 you're
referring to the updates header. I'd not put a lot of weight in the
presence or absence of the updates header. The IESG has waffled
including it, authors forgetting about including it, etc. What's clear
in the thread was that there was a WGLC issued with the understanding
that pre-RFC 5109 was going update the semantics of the error code in
RFC 2560. I can't find any objections and the WG consensus was to
proceed. Should the header have been added - maybe, but I don't
actually find any messages asking for it to be added and push back on
it. What the text in 5019 says is that "this profile extends the RFC
2560 [OCSP] definition of "unauthorized" as follows:"
Your issue, at least to me, seems to be that you'd prefer that new error
codes be defined instead of double-upping on unauthorized error. I've
been letting this exchange go to see if anybody else rallies to your
flag (i.e., joins your cause, gets on your bandwagon, etc). I've not
seen that and I think you're in the rough here.
But, as one of my fellow ADs constantly reminds everyone, one person can
blow up consensus if they're right. So...
I think all of this is based on your message to PKIX in late January:
"
The "unauthorized" response of rfc2560 means
"this is not a public service, and your OCSP request is outside of
our terms-of-service. Go away."
"
I think you're reading a whole lot in to definition from RFC 2560:
The response "unauthorized" is returned in cases where the client is
not authorized to make this query to this server.
I find it really hard to make the leap to if client sends a request to a
non-public server and continues to request status information that it
means they've violated the terms of use of the private server and by
doing so the client has committed a crime.
If we're about interoperability, then I'm waiting for those that think
this change breaks things. To date I've not see folks say that it does.
Yes, this is all an odd way to use an error code for application
specific reasons. However, there really is no point is us moving away
from that (again, admittedly odd) behavior if there's no sign that any
client will be updated for this. The lack of implementers backing
your point seems to put you even deeper in the rough.
Unless I've misconstrued something, that's the rough consensus.
spt
On 3/23/13 2:52 AM, Martin Rex 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
_______________________________________________
pkix mailing list
pkix(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/pkix