datatracker.ietf.org
Sign in
Version 5.7.1.p2, 2014-10-29
Report a bug

The Transport Layer Security (TLS) Multiple Certificate Status Request Extension
draft-ietf-tls-multiple-cert-status-extension-08

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

Summary: Has enough positions to pass.

Richard Barnes

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"

Stephen Farrell

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.

Ted Lemon

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.