> 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
