Hi Joe, even more comments in-line: -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 14, 2007 7:38 AM To: Ryan Hurst; [email protected] Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
Comments inline below. > -----Original Message----- > From: Ryan Hurst [mailto:[EMAIL PROTECTED] > Sent: Tuesday, February 13, 2007 10:35 AM > To: Joseph Salowey (jsalowey); [email protected] > 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; [email protected] > 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." [rmh] OK, after this mail I will create a revised block of text that incorporates all the changes we have discussed up until this point and send it to the list. > > 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] this should be fine since it is not MUST and the text explicitly allows for alternate name forms to be used; you just can't have interoperability in the mainline case without recommending at least one name form per role; we clearly don't want to exclude other scenarios but we want to encourage interoperability. > [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. [rmh] It actually depends on the scenario, but both the full dn and email model are legitimate (as are a few others, for example we have a UPN and a SPN we can plausibly do mapping on also) we shouldn't prevent other models from being used; I would just trying to explain why a different model is used for server vs client. > > 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. [rmh] First the text does not mandate it only suggests (SHOULD vs MUST); to your point about client certificates somehow mitigating this issue it's not true, the 3280 hierarchical PKI trust model presumes that revocation checking is done by the relying party before trust decisions are made about the credential, this is due to the fact that these certificates are long lived and are subject to compromise post issuance (the older a cert is the less trust that should be placed in it); not doing this check so or doing post checking exposes you this risk while checking before you believe the credential does not. [rmh] I would agree that as a bis it would be inappropriate for us to mandate something new like this (for interop reasons) but providing a strong recommendation seems to be appropriate. I think we probably need to start a separate thread on this topic. > > Joe > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
