[apps-discuss] APPSDIR review of draft-ietf-tls-multiple-cert-status-extension-05
Peter Saint-Andre <stpeter@stpeter.im> Wed, 10 April 2013 12:54 UTC
Return-Path: <stpeter@stpeter.im>
X-Original-To: apps-discuss@ietfa.amsl.com
Delivered-To: apps-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B17621F905C; Wed, 10 Apr 2013 05:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3dD26WSCtlU; Wed, 10 Apr 2013 05:54:44 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB7E21F9733; Wed, 10 Apr 2013 05:54:44 -0700 (PDT)
Received: from [192.168.1.8] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5591940E4B; Wed, 10 Apr 2013 07:04:44 -0600 (MDT)
Message-ID: <5165610C.1020803@stpeter.im>
Date: Wed, 10 Apr 2013 06:54:36 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org>, draft-ietf-tls-multiple-cert-status-extension.all@tools.ietf.org
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Cc: The IESG <iesg@ietf.org>
Subject: [apps-discuss] APPSDIR review of draft-ietf-tls-multiple-cert-status-extension-05
X-BeenThere: apps-discuss@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <apps-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/apps-discuss>
List-Post: <mailto:apps-discuss@ietf.org>
List-Help: <mailto:apps-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apps-discuss>, <mailto:apps-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 Apr 2013 12:54:47 -0000
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
- [apps-discuss] APPSDIR review of draft-ietf-tls-m… Peter Saint-Andre
- Re: [apps-discuss] APPSDIR review of draft-ietf-t… Yngve N. Pettersen
- Re: [apps-discuss] APPSDIR review of draft-ietf-t… Peter Saint-Andre
- Re: [apps-discuss] APPSDIR review of draft-ietf-t… Yngve N. Pettersen