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

[Stefan Santesson <[e-mail]>]

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" <[e-mail]> wrote:

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