Skip to main content

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

Yes

(Sean Turner)

No Objection

(Adrian Farrel)
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Stewart Bryant)

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

(Sean Turner; former steering group member) Yes

Yes (for -04)

                            

(Stephen Farrell; former steering group member) (was Discuss) Yes

Yes (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.

(Adrian Farrel; former steering group member) No Objection

No Objection (for -06)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (for -05)

                            

(Benoît Claise; former steering group member) No Objection

No Objection (for -06)

                            

(Brian Haberman; former steering group member) No Objection

No Objection (for -06)

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection (for -07)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -06)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -07)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -06)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (for -06)

                            

(Richard Barnes; former steering group member) (was Discuss) No Objection

No Objection (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; former steering group member) No Objection

No Objection (for -06)

                            

(Ted Lemon; former steering group member) No Objection

No Objection (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.