Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

["Piyush Jain" <[e-mail]>]

> I do not see that prohibition in the new text in -16.  In the cited email
> message, I do see a disagreement between you and Stefan about what
> implementations are likely to do, but I don't see any text in the draft
that
> dictates that implementations must or must not make that interpretation.

I think I failed to clarify this in my last message. Let me try again. I
based my interpretation on the following response from Stefan :

BEGIN QUOTE
~~~~~~~~~~~
" The draft does NOT define a "not-issued" response. It allows the "revoked"
response if a certificate serial number has never been issued. That is two
entirely different things. If you ask how to deal with the response, then
the client will not get a non- issued response. It will get a "revoked"
status."
END QUOTE
~~~~~~~~

The above explanation at the minimum indicates the author's intent that
clients should treat such certificates as "revoked" and not "non-issued".
However, if readers of the draft do not think that the draft explicitly
mandates it, we have a bigger problem w.r.t. to establishing trust in such
responses. Please see the text from section 4.2.2.2 bullet 2 and 3(page 15)

Begin TEXT
~~~~~~~~~
Clients MUST reject the   response if the certificate required to validate
the signature on the response fails to meet at least one of the following
criteria:
   1. Matches a local configuration of OCSP signing authority for the
certificate in question; or
   2. Is the certificate of the CA that issued the certificate in
question; or
   3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage extension
and is issued by the CA that issued the certificate in question as stated
above."
End Text
~~~~~~~

Based on above the responder trust models referred to by "2." and "3."
cannot be used to communicate "non-issued". 

-Piyush