Piyush, > 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 :
[ ... snip ...] > The above explanation at the minimum indicates the author's intent that > clients should treat such certificates as "revoked" and not "non-issued". This may be where we're talking past each other, because what matters is the text in the draft. I understand Stefan's intent, and believe that the use of lower case "should" in the text quoted above is a fair summary of what's in the current draft. That's not an absolute prohibition on or requirement for client behavior, although it's certainly the client behavior that responders should expect (again, lower case "should"). > 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". I think the mechanics of the response validation checks are fine - is the concern that use of "that issued" for items 2 and 3 may be incorrect wrt known non-issued certificates? It may be useful to keep in mind that the CA may have issued the "non-issued" certificate, but no longer has any record of having done so, so I disagree with the statement that the later two models cannot be used to communicate "non-issued", as the CA's signature on such a certificate may be valid. Thanks, --David > -----Original Message----- > From: Piyush Jain [mailto:piy...@ditenity.com] > Sent: Tuesday, April 09, 2013 11:14 AM > To: Black, David; 'Sean Turner' > Cc: ambar...@gmail.com; slava.galpe...@gmail.com; cad...@eecs.uottawa.ca; > 'Stefan Santesson'; s...@aaa-sec.com; p...@ietf.org; gen-art@ietf.org; 'Henry > B. Hotz' > Subject: RE: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15 > > > 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 Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
