Comments inline below. > -----Original Message----- > From: Ryan Hurst [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 13, 2007 10:35 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > Comments in-line > > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 06, 2007 8:35 AM > To: Ryan Hurst; emu@ietf.org > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > Hi Ryan, > > I understand the deprecation of subjectName in favor of > SubjectAltName, > this makes sense to me now. > > I'm still struggling a little with mapping subjectAltName and > subjectName certificate fields to peer and server identities. I think > the text you suggested for the server name subjectAltName mapping is > good: > > [rmh] How about we change "A subjectAltName of type > iPAdress MAY > be used > [rmh] in the server certificate." To "If a dnsName is not > available other > [rmh] field types (for example a subjectAltName of > type iPAdress > or > [rmh] uniformResourceIdentifier) MAY be used. > > I think we should have similar text for the peer name. There > are cases > where either or both the EAP peer and EAP server may be > devices that do > not have an RFC822 name or dnsName. > > [rmh] Could you propose some text that would address your > concern? > [rmh] It was my hope that the following (from the original > proposal) > [rmh] would address this concern: > > If the peer identity represents neither a host nor a > user, another field > type (for example a subjectAltName of type iPAddress > or uniformResourceIdentifier) MAY be used. > [Joe] OK, I think it does. Here is what I have for the text around SubjectAltName
"Although the use of the subject field is existing practice, its use in EAP-TLS is deprecated and Certification Authorities are encouraged to use the subjectAltName field instead. Where the peer identity represents a host, a subjectAltName of type dNSName SHOULD be present in the peer certificate. Where the peer identity represents a user and not a resource, a subjectAltName of type rfc822Name SHOULD be used, conforming to the grammar for the Network Access Identifier (NAI) defined in [RFC4282] Section 2.1. If the peer identity represents neither a host nor a user, another field type (for example a subjectAltName of type iPAddress or uniformResourceIdentifier) MAY be used. A server identity will typically represent a host, not a user or a resource. As a result, a subjectAltName of type dNSName SHOULD be present in the server certificate. If a dnsName is not available other field types (for example a subjectAltName of type iPAdress or uniformResourceIdentifier) MAY be used." > > I am a bit concerned with the text for the subject DN. Why > not use the > same field for both server and peer certificates? In my > experience the > email address in a certificate subject DN is not always the best > identifier. Could CN be used instead of email address? > > [rmh] CNs contain common names, for example my CN in the > directory is Ryan Hurst, > [rmh] this is the appropriate use of CN and as you can see this > is not non-ambiguous > [rmh] (there is a actor with the same name BTW). > > [rmh] Since servers do not have "common names" it is has become > standard to put the > [rmh] DNS name in the common name field instead of using a > dNSName RDN (I am not even sure > [rmh] one exists). > > [rmh] In the case of user certificates clearly users have common > names, and applications almost > [rmh] universally expect this field to be present for display > purposes. It's this reason the eMail > [rmh] address (when present in a DN) is put into its own RDN. > > [rmh] The proposed text is consistent with all certificate > mapping implementations I have ever encountered, > [rmh] and it should also be consistent with the HTTP over SSL > RFC that prescribes much of the same. > [Joe] With certificates embedded in device the email address portion of the DN is not used so consistently, it does not typically refer to the email address of the device but rather of an organization. > [rmh] In the end applications have one of two choices when doing > mapping, map on the full subject DN or > [rmh] map on the email address and we should not specify > anything inconsistent with that as it will lead > [rmh] to problems. > [Joe] It seems that mapping on the full subject DN may be more appropriate in this case since the processor may not know if the peer cert represents a device or user identity. > > With regard to usage of OCSP, I understand the concern you raise. > However, the current practice of retrieving a CRL when attached to the > network and validating the accepted certificate seems to > provide decent > protection. The OCSP in TLS approach is a better approach, > but how much > better is it? A SHOULD is a fairly strong requirement and > its use here > may affect how quickly this document can move through the standards > track. I want to make sure we are getting significant > benefit from this > added requirement. > > [rmh] I understand the concern, and it's certainly a tricky balance > trying to > [rmh] do what is right for security and keeping the process > streamlined > but I would > [rmh] think it would be best for us to lean towards security > vs. process > when crafting. > [rmh] documents like this. OCSP is nearly a decade old, there are a > dozen interoperable > [rmh] implementations out there TLS 1.1 (also several years old now) > which this document > [rmh] takes a normative reference to supports the exchange of OCSP > messages for this > [rmh] exact case. > > [rmh] As for the OCSP stapling approach vs the post connect revocation > (CRL or OCSP) > [rmh] check approach, the difference is that with the OCSP > approach you > get to know if > [rmh] your at risk before you present your credentials, etc > but with the > post check approach > [rmh] you only know once the damage is done. > [Joe] With EAP-TLS the peer credentials are certificate based credentials, I don't see much risk in using these. With EAP-TLS you can defer presenting other credentials or performing operations that are a higher risk until after you have obtained the latest CRL. This is different than something like PEAP or TTLS which presents weak credentials before the network connection is available. I don't think we should bring in new requirements into EAP-TLS unless they are absolutely necessary. I think it may be appropriate to have a stronger requirement for an enhanced TLS method or a password based method that uses TLS. I think we probably need to start a separate thread on this topic. > > Joe > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
