[apps-discuss] APPSDIR review of draft-ietf-tls-multiple-cert-status-extension-05

[Peter Saint-Andre <[e-mail]>]

Bert Greevenbosch and I have been selected as the joint Applications
Area Directorate reviewers for this draft (for background on AppsDir,
please see ​
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments
you may receive. Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-tls-multiple-cert-status-extension-05
Title: The TLS Multiple Certificate Status Request Extension
Reviewers: Bert Greevenbosch and Peter Saint-Andre
Review Date: 10 April 2013
IESG Telechat Date: 2013-04-11
Summary: This draft is almost ready for publication; comments raised
here are for the WG's consideration.

Major Issues:

none

Minor Issues:

(1) Maybe a server can maintain cached OCSP responses, e.g. until after
the "nextUpdate" time has expired. Then the server would be able to use
these cached responses instead of acquiring a new response from the
OCSP-responders. (This mechanism is e.g. defined in [OCSP-MP]). With the
new extension, multiple OCSP-responses from probably different OCSP
servers could be cached. The client needs to verify that each of the
OCSP response is still valid, e.g. that none of the OCSP-responses are
too old.

[OCSP-MP]: OMA Online Certificate Status Protocol (profile of [OCSP]) V
1.0, Open Mobile Alliance, URL:http://www.openmobilealliance.org/

Would some text about cached OCSP responses be appropriate? (Of course
nonces would make caching impossible, as each OCSP responder would need
to sign the new nonce.)

(2) Section 2.2, p.5:

   A zero-length "request_extensions" value means that there are no
   extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not
   valid for the "Extensions" type).

This text was copied from RFC 6066. It seems a bit cryptic, but I
suppose it means that the "request_extensions" field does not exist at
all, e.g. the "OCSPStatusRequest" struct only contains the
"responder_id_list<0..2^16-1>"?

(3) Section 2.2, p.6:

   Note that a server MAY also choose not to send a "CertificateStatus"
   message, even if it has received a "status_request_v2" extension in
   the client hello message and has sent a "status_request_v2" extension
   in the server hello message.

In essence, this says that it is optional for the server to send the
"CertificateStatus" message. What are the types of conditions under
which it is reasonable to not send the "CertificateStatus" message?

(4) Section 2.2, p.7:

   If the client receives a
   "ocsp_response_list" that does not contain a response for one or more
   of the certificates in the completed certificate chain, the client
   SHOULD attempt to validate the certificate using an alternative
   retrieval method, such as downloading the relevant CRL;

Would this allow an attacker to downgrade the security of the
certificate, e.g. by disabling the OCSP response and using a stale CRL?

Maybe a "SHOULD" is not appropriate, but better leave it to the
particular trust model?

(5) Section 3. IANA Considerations. This section mentions a new registry
called "TLS Certificate Status Types", where CertificateStatusType
values should be registered. New values are assigned via IETF Review as
defined in RFC5226.

Should there be specific guidelines/required info for acceptance of new
values for this particular field? If so, state these guidelines/required
info.

Nits:

In Section 2:

   In the OCSPStatusRequest (originally defined by [RFC6066]), the
   "ResponderIDs" provides a list of OCSP responders that the client
   trusts.

- It seems that "ResponderIDs" should be "ResponderID".

Peter & Bert