Subject: [pkix] I-D Action: draft-ietf-pkix-rfc2560bis-18.txt

From: [email-masked]
Date: Thu, 11 Apr 2013 21:57:11 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title           : X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
	Author(s)       : Stefan Santesson
                          Michael Myers
                          Rich Ankney
                          Ambarish Malpani
                          Slava Galperin
                          Carlisle Adams
	Filename        : draft-ietf-pkix-rfc2560bis-18.txt
	Pages           : 44
	Date            : 2013-04-11

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pkix-rfc2560bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-18

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pkix-rfc2560bis-18

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: [email-masked] (Martin Rex)
Date: Sat, 13 Apr 2013 00:29:35 +0200 (CEST)

> http://tools.ietf.org/html/draft-ietf-pkix-rfc2560bis-18
 
I find the most recent -18 change to section 4.4.8 confusing.

_unchanged_ since -15 is the 3rd paragraph of section 4.4.8:

   This extension MUST be included in the OCSP response when that
   response contains a "revoked" status for a non-issued certificate.
   This extension MAY be present in other responses to signal that the
   responder implements the extended revoked definition in section 2.2.

what changed from -17 to -18 is the first paragraph of section 4.4.8:

-17:
   This extension indicates that the responder supports the extended
   definition of the "revoked" status to also include non-issued
   certificates according to section 2.2. Presence of this extension
   indicates that this responder MAY respond with a "revoked" status
   value to a status request for non-issued certificates. When present,
   this extension MUST be included as one of the responseExtensions in a
   response.

-18:
   This extension indicates that the responder supports the extended
   definition of the "revoked" status to also include non-issued
   certificates according to section 2.2. If this extension is absent,
   the responder MUST NOT respond "revoked" to a status request for a
   non-issued certificate. When present, this extension MUST be included
   as one of the responseExtensions in a response.

First of all, there was NOTHING wrong with -17!  But there is duplication
of information between the 1st and 3rd paragraph.  Duplication of a MAY
is mostly harmless, however.

Now the -18 change to the 1st paragraph removes the repetition of the
second sentence MAY of graf 3 from graf 1 and replaces it with the
inverse of the first sentence of graf 3 (MUST -> MUST NOT).

(1) To me, it looks silly to duplicate a statement:

  When condition A you MUST do B

into

  When not condition A you MUST NOT do B
  When condition A you MUST do B

as is done with the -18 change.

(2) the 3rd sentence of graf 1 looks like a non-sequitur:
                                                           When present,
   this extension MUST be included as one of the responseExtensions in a
   response.

"When present" is only meaningful to the receiver of an OCSPResponse.
How could this extension be "present" if it was not conveyed as a
responseExtensions?

If this is meant to say, "this extension must be conveyed as a
resonseExtension, it MUST NOT appear in a singleResponseExtension.",

Suggested replacement for the first 3 paragraphs of section 4.4.8:

   4.4.8 Extended Revoked Definition

   This extension indicates that the responder supports the extended
   definition of the "revoked" status to also include non-issued
   certificates according to section 2.2.  One of its main purposes
   is to allow audits to determine the responder's type of operation.
   Clients will perform the desired behaviour of rejecting the
   certificate from the "revoked" status alone, they do not need to
   recognize or parse this extension.

   This extension MUST be included in the OCSP response when that
   response contains a "revoked" status for a non-issued certificate.
   This extension MAY be present in other responses to signal that the
   responder implements the extended revoked definition.  When used,
   this extension MUST be placed in responseExtensions, and it MUST
   NOT appear in singleExtensions.

I'll note, however, that the "MUST" requirement for using this extension
is actually a backwards-incompatible change to rfc2560 (prohibiting what
would be allowed by rfc2560), and since there is no rationale for the MUST,
this is in conflict with rfc2119 section 6 and really ought to use
a SHOULD NOT instead.

The responses that rfc2560 allows for "not issued" certs is:

   "good" status -- this is obviously a very undesirable response,
          although it is unavoidable if the OCSP responder has no info
          about certificate issuance and feeds on CRLs alone -- ending
          up making a bold inference from the "notRevoked" CRL check result
          rfc2560 "good" has an explicit caveat about this problem

   "unknown" response -- which is a viable alternative for an OCSP responder
          who has access to information about certificate issuance, but may
          cause a client to fallback to CRL checking -- and such a fallback
          will unavoidably cause the client to infer "good" from notRevoked,
          which can hardly be desired behaviour.

   "revoked (reason=certificateHold)" -- while not being explicitly
          described in rfc2560, this behaviour is certainly permitted by
          rfc2560 and seems to have been used after the DigiNotar CA breakin.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 13 Apr 2013 19:54:04 +0200

Martin,

I agree with most of what you say here.

The change was made in response to a discuss, but I think your proposal to
a major part address that discuss in a better way.
And avoids that MUST NOT respond "revoked"Š Which could be questioned in
terms of backwards compatibility.

This is what I'm proposing to put in:

   This extension indicates that the responder supports the extended
   definition of the "revoked" status to also include non-issued
   certificates according to section 2.2.  One of its main purposes is
   to allow audits to determine the responder's type of operation.
   Clients do not have to parse this extension in order to determine the
   status of certificates in responses.

   This extension MUST be included in the OCSP response when that
   response contains a "revoked" status for a non-issued certificate.
   This extension MAY be present in other responses to signal that the
   responder implements the extended revoked definition.  When included,
   this extension MUST be placed in responseExtensions, and it MUST NOT
   appear in singleExtensions.

/Stefan

On 4/13/13 12:29 AM, "Martin Rex" <[email-masked]> wrote:

>_______________________________________________
>pkix mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pkix

---

From: [email-masked] (Martin Rex)
Date: Mon, 15 Apr 2013 15:55:30 +0200 (CEST)

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

Works for me.

-Martin