Review of draft-ietf-sip-eku
"Bernard Aboba" <Bernard_Aboba@hotmail.com> Tue, 14 July 2009 23:45 UTC
Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 795DC3A6B22; Tue, 14 Jul 2009 16:45:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.053
X-Spam-Level:
X-Spam-Status: No, score=-1.053 tagged_above=-999 required=5 tests=[AWL=-1.034, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_SORBS_WEB=0.619]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muXGvWpECWsx; Tue, 14 Jul 2009 16:45:46 -0700 (PDT)
Received: from blu0-omc2-s11.blu0.hotmail.com (blu0-omc2-s11.blu0.hotmail.com [65.55.111.86]) by core3.amsl.com (Postfix) with ESMTP id CE1403A6868; Tue, 14 Jul 2009 16:45:45 -0700 (PDT)
Received: from BLU137-DS7 ([65.55.111.71]) by blu0-omc2-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 16:45:25 -0700
X-Originating-IP: [12.197.88.101]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BLU137-DS78DA1F25BA898F411C2E693230@phx.gbl>
From: Bernard Aboba <Bernard_Aboba@hotmail.com>
To: ietf@ietf.org
Subject: Review of draft-ietf-sip-eku
Date: Tue, 14 Jul 2009 16:45:23 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001D_01CA04A2.7B88B3D0"
X-Mailer: Microsoft Office Outlook 12.0
thread-index: AcoE3PthYvzYJO5/S5mhvIDP4b6duQAABbLw
Content-Language: en-us
X-OriginalArrivalTime: 14 Jul 2009 23:45:25.0397 (UTC) FILETIME=[28E6AC50:01CA04DD]
Cc: ops-dir@ietf.org, vkg@alcatel-lucent.com
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jul 2009 23:45:47 -0000
I reviewed the document draft-ietf-sip-eku in general and for its operational impact. Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones. Improving the documents is important, but clearly a secondary purpose. A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF. Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents. -- Review Summary: Intended status: Proposed Standard This specification documents an extended key usage (EKU) X.509 certificate extension for restricting the applicability of a certificate to use with SIP. 1. Is the document readable? Yes. 2. Does it contain nits? 3. Is the document class appropriate? Previous EKU extensions (such as [RFC 4334]) have not been widely deployed, due to the additional operational complexity they would have introduced, and the limited benefits. Given this, and the potential interoperability impact of this document, the Experimental classification would probably be more appropriate. 4. Does the document consider existing solutions? I don't believe that the document adequately discusses transition issues, or existing practices. See below for detailed comments. 5. Does the solution break existing technology? In situations where there are pre-existing certificates without the EKU extensions, this specification could result in interoperability problems if the "local policy" is not carefully implemented. One concern is that the language on "local policy" could be used by implementers to justify refusing to support existing certificate formats. I do not think that the document adequately addresses how to manage the transition. For example, during an interim period, it would be necessary for implementations to support both legacy certificates as well as certificates with the new extensions. At some point, once the legacy certificates have expired, "local policy" could be changed to require only certificates with extensions. At various points in the document, I was unsure whether the term "implementations" was referring to implementations of this specification, or pre-existing implementations. See below for detailed comments. 6. Does the solution preclude future activity? Adding this EKU extension on the Standards Track is likely to create a need for backward compatibility in the future. 7. Is the solution sufficiently configurable? The document does not discuss what kinds of "local policy" are appropriate in various situations or how the "local policy" can be configured or managed. Some additional discussion in this area would be helpful. 8. Can performance be measured? The document does not address performance measurement. 9. Does the solution scale well? Introducing this extension into an existing large scale certificate deployments would require a lot of care, to avoid interoperability problems. 10. Is Security Management discussed? The document does not discuss how certificate interoperability issues can be dealt with, or how operational problems could be diagnosed. ------------------------------------------------ Detailed comments Section 3 " A Certificate Authority issuing a certificate whose purpose is to bind a SIP domain identity without binding other non-SIP identities MUST include an id-kp-SIPdomain attribute in the Extended Key Usage extension value (see Section 3.1). [BA] Question: What is the definition of "SIP domain identity"? This is not included in the terminology section. Section 4 " Section 7.1 of Domain Certificates in the Session Initiation Protocol [8] contains the steps for finding an identity (or a set of identities) in an X.509 certificate for SIP. In order to determine whether the usage of a certificate is restricted to serve as a SIP certificate only, implementations MUST perform the step given below as a part of the certificate validation: " [BA] Not sure how the first sentence relates to the rest of the paragraph. Is the intent to suggest that the process for finding the identity needs to be carried out in order to make the determination? If so, then [8] would be a normative reference. " o If the certificate does not contain any EKU values (the Extended Key Usage extension does not exist), it is a matter of local policy whether or not to accept the certificate for use as a SIP certificate. " [BA] There are a large number of existing certificates issued without these EKUs. In situations in which these existing certificates are expected, leaving their acceptance up to "local policy" would seem likely to create an interoperability problem. " o If the certificate contains the id-kp-sipDomain EKU extension, then implementations MUST consider the certificate acceptable for use as a SIP certificate. " [BA] I presume that this means "implementations of this specification", correct? Pre-existing implementations don't know about these EKU extensions, and so will make their determination based on other factors. " o If EKU extension exists but does not contain any of the id-kp- sipDomain, id-kp-anyExtendedKeyUsage, id-kp-serverAuth, or id-kp- clientAuth EKU values, then implementations MUST NOT consider the certificate as acceptable for use as a SIP certificate. " [BA] Here I think you're referring to pre-existing implementations as well, correct?
- Review of draft-ietf-sip-eku Bernard Aboba
- Review of draft-ietf-sip-eku Bernard Aboba