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

From: The IESG <[email-masked]>
Date: Wed, 13 Mar 2013 13:08:38 -0700

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
[email-masked] mailing lists by 2013-03-27. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document specifies a protocol useful in determining the current
   status of a digital certificate without requiring CRLs. Additional
   mechanisms addressing PKIX operational requirements are specified in
   separate documents. This document obsoletes RFC 2560 and RFC 6277,
   and updates RFC 5912.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: [email-masked] (Martin Rex)
Date: Sat, 23 Mar 2013 07:52:08 +0100 (CET)

The IESG wrote:
> [email-masked] 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

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 26 Mar 2013 03:35:44 +0100

Martin,

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?

/Stefan

---

From: [email-masked] (Martin Rex)
Date: Tue, 26 Mar 2013 06:28:53 +0100 (CET)

> 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

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 26 Mar 2013 09:47:27 +0100

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

---

From: [email-masked] (Martin Rex)
Date: Tue, 26 Mar 2013 12:13:11 +0100 (CET)

Stefan Santesson wrote:
> Unfortunately what you suggest would not be backwards compatible,
> and can't be done within the present effort.

I'm sorry, I can not follow your arguments.

Adding 3 more OCSPResponseStatus error codes { no_authoritative_data(7),
single_requests_only(8), unsupported_extension(8) } with well-defined and
conflict-free semantics to the existing enum would be perfectly backwards
compatible.

Whether and when implementations of rfc5019 or its successor can make
use of additional error codes with well-defined semantics is a seperate
issue.

Sending multiple entries in a requestList is a perfectly valid client
option in rfc2560.  rfc5019 has a requirement for single entries.
What response does rfc5019 define in case that it receives an OCSP request
with multiple entries in requestList.

Keep in mind that OCSP responders are typically located through
Authority Identifier Access "id-ad-ocsp", and that cert extension is
specified to provide for the conventions of rfc2560 -- *NOT* the subset
of rfc5019:

http://tools.ietf.org/html/rfc5280#page-51

   The id-ad-ocsp OID is used when revocation information for the
   certificate containing this extension is available using the Online
   Certificate Status Protocol (OCSP) [RFC2560].

   When id-ad-ocsp appears as accessMethod, the accessLocation field is
   the location of the OCSP responder, using the conventions defined in
   [RFC2560].

> "unauthorized" in the present manner was a reasonable tradeoff.

Could you point me to any kind of discussion of this "tradeoff"?
I'm having difficulties finding that information.

The first draft that became rfc5019 seems to have appeared here:

  http://www.ietf.org/mail-archive/web/pkix/current/msg17432.html

and it already contained the abuse of the "unauthorized(7)" error code.

I see a first complaint on the mailing list about the error code abuse here
on 02-Nov-2004:

  http://www.ietf.org/mail-archive/web/pkix/current/msg17270.html

but the reponse is -crickets-.

In what way is the client going to treat "unauthorized(6)" special and
different from other error codes, such as "internalError(2)" or
"malformedRequest(3)", and where in rfc5019 is that special behaviour
defined?

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 26 Mar 2013 12:41:04 +0100

>conflict-free semantics to the existing enum would be perfectly backwards

Of course it is backwards compatible with the standard, but not with the
installed base.

What would happen to the installed base of clients if OCSP responders
would change from current "unauthorized" to one of your new error codes?

/Stefan

---

From: [email-masked] (Martin Rex)
Date: Tue, 26 Mar 2013 13:03:04 +0100 (CET)

Following up to myself:

The real discussion seemed to have started in 2006...
Some folks had a pretty reasonable opinion at some point of the discussion,
e.g. Russ Houseley:
  http://www.ietf.org/mail-archive/web/pkix/current/msg03570.html

and then there is lots of real dirty horse-trading in the PKIX discussion.

Oh, here is a message from the Security AD back then (Sam Hartman),
commenting on requirements for rfc2560bis (the I-D under last call right now!):

  http://www.ietf.org/mail-archive/web/pkix/current/msg03515.html

What I don't understand:  during the PKIX discussion there seemed to
be some consensus that a prerequisite to abuse the "unauthorized(6)"
would an update of rfc2560 would be required.

But rfc5019 *NEVER* updated rfc2560!!

But what puzzles me most is why is there a problem with defining new
error codes in the first place?

In order to NEVER EVER have such a problem again in any future IETF
spec, there should be a requirement for error code partioning upfront
into good, temporary and final, and there should be reserved error code
points that clients will have to handle gracefully and well-behaved
when they receive it.

I find it most difficult to believe that there are OCSP clients out there
that would crash and burn if they received an OCSPResponseStatus (7),(8)
or (9), rather than an "unauthorized(6)", undefined or a different undefined
return code for the underspecified error situations created by rfc5019
(and rfc2560, as Sam correctly points out).

Should there be such broken clients, then you really do not want to use
them in the first place, because *EVERYONE* can feed those OCSP clients
arbitrary error codes in unsigned OCSPResponses.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Tue, 26 Mar 2013 13:09:50 +0100 (CET)

> would change from current "unauthorized" to one of your new error codes?

As it was already mentinoned here:
  http://www.ietf.org/mail-archive/web/pkix/current/msg04489.html

I would no longer get a popup from my OCSP client that tells my
that I'm unauthorized to submit OCSPRequests to that server, and that
the server has been moved to a blacklist, and that I will have to
manually enable this server after obtaining proper authorization
before my client will send any further requests that OCSP server.

No longer being interactively bothered about this error seems like a
very valuable improvement!

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 26 Mar 2013 13:25:05 +0100

What OCSP client are you using that behaves like this?

On 3/26/13 1:09 PM, "Martin Rex" <[email-masked]> wrote:

>the server has been moved to a blacklist

---

From: [email-masked] (Martin Rex)
Date: Tue, 26 Mar 2013 13:39:47 +0100 (CET)

> >the server has been moved to a blacklist

Every sensible implementation of rfc2560 that does not happen to
be based on rfc5019.

I knew about rfc2560 for several years, but I only learned about the
existence of rfc5019 a few weeks ago -- because of the bogus change
to the "unauthorized" semantics in the rfc2560bis I-D.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 26 Mar 2013 13:54:40 +0100

I take it that the answer to my question is none.

Which is what I suspected. The semantics of "unauthorized" does not give
you the basis for such functionality.
And 5019 is very widely deployed.

I'm going to sep down from this discussion and see how it goes.
It is not me you have to convince. It's the community of implementers.

/Stefan

---

From: [email-masked] (Martin Rex)
Date: Tue, 26 Mar 2013 15:01:39 +0100 (CET)

> I take it that the answer to my question is none.

Why would an rfc5019 client have a problem with a (7) instead of (6)
OCSPResponseStatus?

And what about an error code for "only a single request" that rfc5019
fails to specify.

> And 5019 is very widely deployed.

The way I read this message from the security AD back then:
  http://www.ietf.org/mail-archive/web/pkix/current/msg03515.html

rfc5019 was only passed on the promise from PKIX that it would
clean up rfc2560bis -- the I-D under last call here.

So the IESG should return this I-D to PKIX and have them
provide the updates that they agreed to do.

-Martin

---

From: Sam Hartman <[email-masked]>
Date: Tue, 26 Mar 2013 10:07:45 -0400

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Oh, here is a message from the Security AD back then (Sam
    Martin> Hartman), commenting on requirements for rfc2560bis (the I-D
    Martin> under last call right now!):

    Martin>   http://www.ietf.org/mail-archive/web/pkix/current/msg03515.html

To be clear, I didn't comment on which error codes were overloaded to do
what.  My point was simply that there needs to be a minimal set of
client behavior that is guaranteed to work (if permitted by responder
policy) with any responder.  That's the level of interoperability we
generally require from our specs.

It sounds like Martin would like to be able to distinguish three client
behaviors:

1) Use less of the spec and send me a simpler request

2) I can't help you with this particular request

3) Please go away and never come back

That's a fine desire.  In my opinion, it's also fine for us to decide
for interoperability, simplicity or other reasons that we're combining
all that into one error and clients don't get to make this distinction.

---

From: [email-masked] (Martin Rex)
Date: Tue, 26 Mar 2013 15:30:05 +0100 (CET)

Sam Hartman wrote:
> Martin Rex <[email-masked]> writes:

When the rfc2560 semantics of "unauthorized(6)" and the rfc5019 semantics
of "unauthorized(6)" are merged into one, then this error code ought
to be renamed to "whatever(6)", because it will be impossible for a
client to know what a server really meant!  Whether an OCSP responder
is rfc2560 compliant or whether it adheres to rfc5019 subset can neither
be determined from the id-ad-ocsp AIA information of an X.509v3 certificate
nor from an OCSPResponse that conveys a responseStatus (6).

Why don't we add sensible, well-defined OCSPResponseStatus error code
now during rfc2560bis, and see how and when we can make appropriate
use of those in clients.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Wed, 27 Mar 2013 15:14:37 +0100 (CET)

Stefan Santesson wrote:
> "Martin Rex" <[email-masked]> wrote:
> 

Actually, please look at the I-D text again.  Even if the Servers would
change their response to a new error code for the "I can not respond
authoritatively", it will be 100% backwards compatible with the clients.

That is at least what proposed change implies!

So lets assign new error codes and have Server change their response!

"Backwards compatibility" is relevant in the same fashion as interoperability
-- interoperability among independent implementations as well as interop
between new implementations and the installed base.

Since the current change only "conveys" information, and does that in
an extremely ambiguous fashion, moving to a new error code is provably
NOT going to be any problem to interop,  The desired client behaviour
is completely unspecified, so *ANY* client behaviour will be acceptable.

Based on the current text, your claim must be bogus, that assignment of
new error codes for this purpose would be backwards incompatible.

What I can not yet completely rule out, though, is that there are some
currently unstated expectations / desired behaviour that you would
want to retain, and which is currently undocumented.  Should that be
the case, then it is paramount that any such expectation about desired
behaviour is ADDED to the document, in order to enable interop with
independent implementations.

It is conceivable that such "desired/expected" behaviour consists of some
kind of "blacklisting" that had been previously implemented for the
"unauthorized(7)" error code, and that the inventors of the rfc5019
profile (VeriSign and Microsoft) wanted to take advantage of.

Should that be the case, then I would really be curious what kind of
blacklisting that is that implementors are thinking of when they
express their concern a move to a newly assigned error code would
be "backwards incompatible".  Is it about the caching of that responses
on clients?  Is there any "negative response caching"?  Are negative
responses cached "per server" or per (requested) certificate status?

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 27 Mar 2013 16:32:49 +0100

It is risky to assume that existing clients would work appropriately if
you send them a new never seen before error code.

I'm not willing to assume that unless a big pile of current implementers
assures me that this is the case.

/Stefan

---

From: [email-masked] (Martin Rex)
Date: Wed, 27 Mar 2013 16:59:23 +0100 (CET)

Stefan Santesson wrote:
>
> It is risky to assume that existing clients would work appropriately
> if you send them a new never seen before error code.
> 

As I wrote: As long as the spec is _entirely_silent_ about expected/desirable
behaviour of the client on receipt of a repurposed "unauthorized(7)"
OCSPResponseStatus, the new error code with be provable "backwards
compatible" within the definition of the specification, because
*ANY* client behaviour will formally provable meet the spec and therefore
"be interoperable".

How indiviual OCSP clients behave in particular, and whether all
implementors appreciate the behaviour of their own implementation
will then be _irrelevant_.

... which is why I believe that leaving client behaviour for the receipt
of OCSPResponseStatus error code entirely unspecified is a bad idea,
and for the repurposed "unauthorized(7)" it's a really bad idea.

rfc5019 only talks about caching of signed OCSP responses:
  http://tools.ietf.org/html/rfc5019#section-6.1

-Martin

---

From: [email-masked] (Martin Rex)
Date: Wed, 27 Mar 2013 22:11:53 +0100 (CET)

Sam Hartman wrote:
> Martin Rex wrote:
>> Oh, here is a message from the Security AD back then (Sam
>> Hartman), commenting on requirements for rfc2560bis (the I-D
>> under last call right now!):
>> 

True.  It was the Security co-AD Russ Housley who indicated _early_ during
the discussion of that draft (2.5 years after it had been adopted
as a WG item) that he considered some of the suggested abuses of
existing error codes "unacceptable":

So far, I haven't found any arguments that could reasonably invalidate
Russ' initial assessment on the "unacceptable" the error code abuse,
i.e. any kind of transparent trade-off and the facts it could be
based on.

Looking as Russ' comment again, I check the documents again on the
exact behaviour required from an rfc5019 server when receiving an
OCSP request with a requestList.  Myself, I'm surprised and confused
by the answer:  the rfc5019 server is prohibited from returning an error!

rfc2560 neither provides and option nor an error code to refuse
a response based on the presence of multiple entries in request list.

The limit of a single entry in the requestList ist *CLEARLY* limited
to clients conforming to the rfc5019 profile, it is neither limited to
the requests sent to rfc5019 servers, nor does it apply to rfc5019
servers themselves -> "this profile ensures interoperability with
a fully conformant OCSP 2560 client":

   http://tools.ietf.org/html/rfc5019#page-4

   End of Section 1:

                                                        In the case
   where out-of-band mechanisms may not be available, this profile
   ensures that interoperability will still occur between a fully
   conformant OCSP 2560 client and a responder that is operating in a
   mode as described in this specification.

   2.1.1. OCSPRequest Structure

   OCSPRequests conformant to this profile MUST include only one Request
   in the OCSPRequest.RequestList structure.

Other than what I had assumed from Russ' message about unacceptable
error code abuse, rfc5019 does not define what kind or error code
to (ab)use if a request contains more than one entry in requestList,
and contains this explicit guidance:

  http://tools.ietf.org/html/rfc5019#section-2.2.1

   2.2.1. OCSPResponse Structure

   In the case where a responder does not have the ability to respond to
   an OCSP request containing a option not supported by the server, it
   SHOULD return the most complete response it can.  For example, in the
   case where a responder only supports pre-produced responses and does
   not have the ability to respond to an OCSP request containing a
   nonce, it SHOULD return a response that does not include a nonce.

But when there are multiple entries received in a requestList from
a "fully conformant OCSP 2560 client", to which rfc5019 allegedly ensures
interoperability, then the option to return "unauthorized" to indicate
inability to obtain authoritative information, and results in
self-contraditory design.

I strongly believe this stuff needs some housekeeping applied.
The currently proposed minimal change of the description for the
"unauthorized" error code in rfc2560bis is only going to make
the mess worse, this is neither a solution, nor an improvement to
anything.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 28 Mar 2013 16:51:10 +0100

On 3/27/13 10:11 PM, "Martin Rex" <[email-masked]> wrote:

>It was the Security co-AD Russ Housley who indicated _early_ during
>existing error codes "unacceptable"

For the record. Russ comment was:

"I find the use of "unauthorized" to indicate that a client cannot make a
multi-certificate request unacceptable."

Which is completely different from your raised concern.

/Stefan