The Transport Layer Security (TLS) Multiple Certificate Status Request Extension
draft-ietf-tls-multiple-cert-status-extension-08
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 IESG member
Yes
Yes
(for -04)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
Yes
Yes
(2013-04-11 for -07)
Unknown
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 IESG member
No Objection
No Objection
(for -06)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -05)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -06)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -06)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -07)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -06)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -07)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -06)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -06)
Unknown
Richard Barnes Former IESG member
(was Discuss)
No Objection
No Objection
(2013-04-09 for -07)
Unknown
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 IESG member
No Objection
No Objection
(for -06)
Unknown
Ted Lemon Former IESG member
No Objection
No Objection
(2013-04-10 for -06)
Unknown
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.