The Transport Layer Security (TLS) Multiple Certificate Status Request Extension
Summary: Needs 3 more YES or NO OBJECTION positions to pass.
Note: This ballot was opened for revision 04 and is now closed.
Stephen Farrell (was Discuss) Yes
Comment (2013-04-11 for -07)
Thanks for quickly handling my discuss points! I note the 2560/2560bis issue still needs fixing and am ok that that'll be done. If the answer is that 2560bis becomes the normative reference then that's fine, but in that case I do think it'd be good to retain the text that clarifies how to handle id-pkix-ocsp-nonce if you're coding this based on a 2560 and not a 2560bis implementation, since that will be the case for a while yet. And that'd mean keeping 2560 as an informative ref too.
( spt ) Yes
Jari Arkko No Objection
( Richard Barnes ) (was Discuss) No Objection
Comment (2013-04-09 for -07)
In the Abstract, this phrase seems unclear: "multiple certificate status methods (commonly referred to as OCSP stapling)". Suggest: "multiple certificate status methods. (The use of the Certificate Status extension is commonly referred to as "OCSP stapling".)" In Section 2.2., it would be helpful if you could clarify which parts are new, and which are restated from RFC 6066. In Section 2.2., "see also" should be "as defined in"
( Stewart Bryant ) No Objection
( Gonzalo Camarillo ) No Objection
Benoit Claise No Objection
( Adrian Farrel ) No Objection
Brian Haberman No Objection
Joel Jaeggli No Objection
Barry Leiba No Objection
( Ted Lemon ) No Objection
Comment (2013-04-10 for -06)
If this document were updated to reference 2560bis instead of 2560, I think this text could simply be removed, since the correction is present in 2560bis: In the case of the "id-pkix-ocsp-nonce" OCSP extension, [RFC2560] is unclear about its encoding; for clarification, the nonce MUST be a DER-encoded OCTET STRING, which is encapsulated as another OCTET STRING (note that implementations based on an existing OCSP client will need to be checked for conformance to this requirement). If the authors do not want to reference 2560bis for some reason, then the above language seems to me to update 2560. The items in the list of CertificateStatusRequestItemV2 entries are in order of the client's preference (favorite choice first). Does the idea of "favorite choice first" really make sense? Either an OCSP responder is trusted or not, right? I'm not so clear on the architecture here that I can be sure this question makes sense, but I wonder if randomizing the list doesn't make just as much or more sense than ordering it according to some unspecified notion of favorites.