> -----Original Message----- > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > Sent: Sunday, October 22, 2006 9:39 AM > To: Joseph Salowey (jsalowey); [email protected] > Subject: RE: [Emu] Review requested: draft-simon-emu-rfc2716bis-03.txt > > Joe Salowey said: > > >Currently the section states that the peer identity is obtained from > >the subjectAltName in the certificate. Is this text meant to be > >normative? > >Currently there are implementations > >that use elements of the subject distinguished name and do > not provide > >a subjectAltName. > > > >Perhaps it would be better to say the subjectAltName is used > if it is > >present and if it is not then the subject distinguished name is used. > >However it seems that RFC3280 might indicate that it would > be better to > >use subject distinguished name if it is present and subjectAltName if > >not. This section should reference RFC3280. Also is there > any reason > >why mapping using a directory service is called out, isn't > just mapping > >to a Peer-ID or Server-ID sufficient? > > > >It would may also be good to say that an EAP-TLS implementation MAY > >make other certificate fields available to the lower layer. > > I've added some text in Section 4.2 that hopefully will clear this up: > > 4.2. Certificate Usage > > The EAP-TLS peer name (Peer-Id) represents the Network Access > Identifier (NAI) [RFC4282] to be used for authorization and > accounting purposes. The Peer-Id is determined from the subject or > altSubjectName fields in the peer certificate. As noted > in [RFC3280] > Section 4.1.2.6: > > The subject field identifies the entity associated with > the public > key stored in the subject public key field. The > subject name MAY > be carried in the subject field and/or the subjectAltName > extension... If subject naming information is present > only in the > subjectAltName extension (e.g., a key bound only to an email > address or URI), then the subject name MUST be an empty sequence > and the subjectAltName extension MUST be critical. > > Where it is non-empty, the subject field MUST contain an X.500 > distinguished name (DN). > > Where the subject field is not empty, the Peer-Id and Server-Id are > obtained from the Common Name (CN) field of the DN. Where subject > naming information is present only in the subjectAltName extension, > the Peer-Id and Server-Id are obtained from the subjectAltName. > [Joe] OK
> A valid EAP-TLS client certificate SHOULD contain an > extendedKeyUsage > value indicating support for Client Authentication > (1.3.6.1.5.5.7.3.2). A valid EAP-TLS server certificate SHOULD > contain an extendedKeyUsage value indicating support for Server > Authentication (1.3.6.1.5.5.7.3.1). > [Joe] I think I remember that some protocols specify the presence of a specific EKU or the ANY EKU. > As discussed in [He], the security of EAP-TLS can be compromised if > the same credentials are used for authentication within multiple > applications. [Joe] I haven't looked at [He] in a while, but I thought that it wasn't applications in general, but applications that use a protocol that bindly signs arbitrary data. Perhaps this should be a bit clearer. > Certificate extensions for use with EAP-TLS are > discussed in "Certificate Extensions and Attributes Supporting > Authentication in Point-to-Point Protocol (PPP) and Wireless Local > Area Networks (WLAN)" [RFC4334]. These extensions enable > certificate > usage to be restricted to use with lower layers such as > PPP or IEEE 802.11. > An EAP-TLS implementation MAY make these and other > certificate fields > available to the lower layer. > [Joe] OK _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
