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

[[e-mail] (Martin Rex)]

[e-mail] wrote:
> 
> There's also a htmlized version available at:
> 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