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

[Sean Turner <[e-mail]>]

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
>> [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix
>