Re: AD Review for draft-ietf-pkix-rfc3770bis
Russ Housley <housley@vigilsec.com> Tue, 24 May 2005 16:29 UTC
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16390 for <pkix-archive@lists.ietf.org>; Tue, 24 May 2005 12:29:45 -0400 (EDT)
Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4OFZSNW003740; Tue, 24 May 2005 08:35:28 -0700 (PDT) (envelope-from owner-ietf-pkix@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j4OFZS61003739; Tue, 24 May 2005 08:35:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-pkix@mail.imc.org using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j4OFZRxF003733 for <ietf-pkix@imc.org>; Tue, 24 May 2005 08:35:28 -0700 (PDT) (envelope-from housley@vigilsec.com)
Received: (qmail 26223 invoked by uid 0); 24 May 2005 15:35:22 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.170.22) by woodstock.binhost.com with SMTP; 24 May 2005 15:35:22 -0000
Message-Id: <6.2.1.2.2.20050524104606.03fab960@mail.binhost.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2
Date: Tue, 24 May 2005 11:35:10 -0400
To: Sam Hartman <hartmans-ietf@mit.edu>
From: Russ Housley <housley@vigilsec.com>
Subject: Re: AD Review for draft-ietf-pkix-rfc3770bis
Cc: timmoore@microsoft.com, ietf-pkix@imc.org
In-Reply-To: <tsl3bsdin0y.fsf@cz.mit.edu>
References: <tsl3bsdin0y.fsf@cz.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-ietf-pkix@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:ietf-pkix-request@imc.org?body=unsubscribe>
Sam: Thanks for the AD review. It has improved the document. Here is how I addressed each of your comments. I have CCed the PKIX mail list to stan any WG member can raise the alarm if they do not like the way that any comment was resolved. >The document sites RFC 2284, not RFC 3748 which supersedes 2284. In >addition the document's terminology is inconsistent with RFC 3748. >EAP defines an exchange between a peer and an EAP server. The term >client is not typically used. My preference is that you fix the >terminology but this is not a requirement. The reference does need to >be updated. Also, I wonder whether it should be normative. [EAP] changed to normative, and it references RFC 3748. The terminology was updated to use "supplicant" when talking about 802.1X and "peer" when talking about EAP. The term "EAP server" is also used. >section 1: >There are two places in an EAP protocol where it seems obvious you >might want to use a certificate: the peer might want a certificate to >prove its identity to the EAP server and a EAP server might want a >certificate to prove its identity to the peer. This document deals >with the first case but does not make that clear. >The following change helps. > >s/for/by/ >old: > Automated selection of certificates for PPP and IEEE 802.1X clients > is highly desirable. By using certificate extensions to identify the >new: > Automated selection of certificates by PPP and IEEE 802.1X clients > is highly desirable. By using certificate extensions to identify the The "client" in this sentence causes problems with your earlier comment. How about: "Automated selection of client certificates for use with PPP and IEEE 802.1X is highly desirable." >I'd like to see text like the following worked into section 1 >though to make things completely clear. > > This document defines key usage values and certificate extensions to > be used in certificates issued to clients of PPP and wireless > networks. How about a new paragraph at the end of section 1: "This document defines extended key usage values and a WLAN-specific certificate extension for use in certificates issued to clients of PPP and WLANs." >section 2: > >Do these key purpose IDs apply to EAP server certificates or to client >certificates or to both? The intent was peer certificates. I do not recall any discussion of EAP server certificates using them. Proposed revision: "Inclusion of the EAP over PPP value indicates that the certified public key is appropriate for use by a peer with EAP in the PPP environment. The inclusion of the EAPOL value indicates that the certified public key is appropriate for use by a peer with the EAP in the LAN environment. Inclusion of both values indicates that the certified public key is appropriate for use by a peer in either of the environments." >The text quotes the description of extend key usages from RFC 3280 and >points out that an application can require extended key usage and a >particular KeyPurposeId. Is the intent for this to be defined by the >EAP method, the EAP method implementation, site policy, or something >else? How should implementers handle the situation where the EAP >implementation does not know what environment it is being used in? >(I'm not sure whether this situation is actually common.) I do not think there is a problem here. EAP methods that use certificates can require the presence of a particular KeyPurposeId, but I do not think that any have done so. >The extended key usage should presumably be checked both by the EAP peer >and the EAP server. The text should probably make this more clear. I see it more as a selection criteria when more than one certificate is available. >Section 3: > >The following text seems to be trying to imply that the ssid extension >can only be used with the extended key usage extension. If that's >true the requirement needs to be stated more clearly. However I don't >understand why you would want that requirement--it seems reasonable to >use the ssid extension with an application (EAP method) that does not >require extended key usage. > > When more than one certificate includes an extended key usage > extension indicating that the certified public key is appropriate for > use with the EAP in the LAN environment, then the list of SSIDs MAY > be used to select the correct certificate for authentication in a > particular WLAN. It is not a requirement. It is trying to say that the KeyPurposeId could narrow the certificate selection, and then this extension could provide further assistance. It is perfectly fine for only one of the extensions to be used. I suggest replacing the first paragraph of setcion 3 with: The Wireless LAN (WLAN) System Service identifiers (SSIDs) public key certificate extension is always non-critical. It contains a list of SSIDs. The list of SSIDs MAY be used to select the correct certificate for authentication in a particular WLAN. If the extended key usage extension appears in the same certificate as the SSID extension, then the extended key usage extension MUST indicate that the certified public key is appropriate for use with the EAP in the LAN environment by including the id-kp-eapOverLAN KeyPurposeId value. -- Russ
- Re: AD Review for draft-ietf-pkix-rfc3770bis Russ Housley
- Re: AD Review for draft-ietf-pkix-rfc3770bis Sam Hartman