Subject: [TLS] comments on draft-ietf-tls-multiple-cert-status-extension-01

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 30 Sep 2012 07:29:22 +0200

* Section 2.2:
The document says:
"In the OCSPStatusRequest and SCVPStatusRequest structures, the
   "ResponderIDs" provide a list of OCSP and SCVP responders
   (respectively) that the client trusts.  A zero-length
   "responder_id_list" sequence has the special meaning that the
   responders are implicitly known to the server, e.g., by prior
   arrangement, or are identfied by the certificates used by the server."

This is from RFC6066, but I think this text is only applicable to
original intent of the ocsp extension, as an extension for constrained
embedded clients. This is not valid generally, as most (if not all)
browsers always send a zero-length responder_id_list irrespective of any
prior arrangement with the server (there is none). The empty
responder_id_list indicates that the client would accept the preferred
by the server OCSP responder.

* same section:
'"Extensions" is a DER encoding of OCSP request extensions.'

I cannot understand the intent of the extensions. Is this field really
required, or the draft could be simplified by removing it? My guess is
that this is a relic of the original intention of the extension which
assumed that the server would poll the ocsp server at the moment the
client connected at his request. Are there any actual clients that use
this field on the current RFC6066 extension?

* same section:
     struct {
       OCSPResponse ocsp_response_list<1..2^24-1>
     } OCSPResponseList

there is a missing ';'

* same section:
   "Clients requesting a certificate response and receiving either one or
   more OCSP responses or a SCVP response in a "CertificateStatus"
   message MUST check the response(s) and abort the handshake, if the
   response is a revoked status or is otherwise not satisfactory with a
   bad_certificate_status_response(113) alert.  This alert is always
   fatal."

This text doesn't seem to belong in this section. There should be in a
verification section or so. However my question is whether this text is
applicable to this document at all. Is this document the proper place to
define what to do when OCSP verification fails? If there is some TLS
verification profile later that would like to set some verification
rules, it risks violating the OCSP extension draft.

I'd suggest, if you want to keep this text, to keep it pure
informational without MUSTs or SHOULDs.

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 30 Sep 2012 07:37:16 +0200

btw. There are no suggested values for XX, YY, and AA. There cannot be
interoperable implementation without some hint on these values.

regards,
Nikos