The Transport Layer Security (TLS) Multiple Certificate Status Request Extension
RFC 6961

Note: This ballot was opened for revision 04 and is now closed.

(Stephen Farrell) (was Discuss) Yes

Comment (2013-04-11 for -07)
No email
send info
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.

(Sean Turner) Yes

(Jari Arkko) No Objection

(Richard Barnes) (was Discuss) No Objection

Comment (2013-04-09 for -07)
No email
send info
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

(Benoît 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)
No email
send info
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.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection