> I guess it would be okay if you and David make the determination that this > issue is not worth debating anymore but I would surely have appreciated > hearing the opinions of a few others.
I'm not sure how much of a say I have in that determination - Sean (as AD) is absolutely free to acknowledge my input and ignore it ;-). > The deviation from that consensus is that in such cases, the current draft > prohibits clients to interpret the certificate as non-issued, and requires > them to interpret it as issued and revoked by the CA. And this is necessary > to circumvent the responder trust issue for CA delegated responders if they > return extended revoked indicating non-issuance. > Please see http://www.ietf.org/mail-archive/web/pkix/current/msg32336.html. 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. Speaking for myself, I would have no problem w/client code that inferred that any "revoked" response with revocation reason certificateHold (6) and revocationTime January 1, 1970 most likely indicates a non-issued certificate. OTOH, such a client *cannot* rely on always receiving that form of response for a known non-issued certificate for the reasons discussed in the new text (e.g., responder not updated to use that response, responder uses only pre produced responses). Again speaking for myself, I think the current text in -16 is ok, in that I don't see the prohibition that Piyush is concerned about there. OTOH, I'd also be ok with a couple of sentences added to say that (new) clients could use that response format to infer that the certificate is a known non-issued certificate, but that clients cannot rely on getting that form of response for all known non-issued certificate (i.e., may get an "unknown" response). Thanks, --David > -----Original Message----- > From: Piyush Jain [mailto:[email protected]] > Sent: Tuesday, April 09, 2013 2:03 AM > To: 'Sean Turner' > Cc: [email protected]; [email protected]; [email protected]; > 'Stefan Santesson'; Black, David; [email protected]; [email protected]; gen- > [email protected]; 'Henry B. Hotz' > Subject: RE: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15 > > > I went back and looked at the WG poll about this issue that you and lot of > > other people participated in (https://www.ietf.org/mail- > > archive/web/pkix/current/msg31906.html). The WG's rough consensus was > > to allow "revoked" to be used for non-issued certificates with the caveat > > thrown in by Paul Hoffman that the meaning of "revoked" be clear about > > what it now means. I've not seen anything that would make me want to > > throw this draft back to the WG to revisit that consensus. > > > > I believe that the straw poll consensus was that revoked will be overloaded > to convey non-issued status to the clients. > The deviation from that consensus is that in such cases, the current draft > prohibits clients to interpret the certificate as non-issued, and requires > them to interpret it as issued and revoked by the CA. And this is necessary > to circumvent the responder trust issue for CA delegated responders if they > return extended revoked indicating non-issuance. > Please see http://www.ietf.org/mail-archive/web/pkix/current/msg32336.html. > > This is an important distinction because from client's point of view > non-issued response for a CA signed certificate is much more severe than a > revoked response and is indicative of a CA/RA compromise. > The reason I'm raising this at LC is because there were a few WG members who > acknowledged this issue and there was no consensus (other than Stefan's > response in the post linked above) on how this should be handled. > > I guess it would be okay if you and David make the determination that this > issue is not worth debating anymore but I would surely have appreciated > hearing the opinions of a few others. > > Best > Piyush > > > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
