> > [rmh] As I understand it the peer ID always (essentially) > looks like a > > email address so host or otherwise it seems appropriate to use the > > emailAddress RDN; this also (based on my experience) represents > > current practice with the Subject DN being deprecated any new > > name-forms should be proposed in the subjectAltName shouldn't it? > > > [Joe] The peer name often takes the form of [EMAIL PROTECTED], but > it does not necessarily have to. Another problem is that > some existing device implementations use the email address > RDN, but it does not have a unique identifier in it. > [rmh] Could you provide me a example? Is it a "unique" device > ID of some sort?
[Joe] Manufacturing installed certificates will not have a realm since the realm will not be known at manufacturing time. I have seen manufacturing installed certificates where the email address field of the DN contains a contact address such as "[EMAIL PROTECTED]". I do see your point about email address having a similar form to NAI. Perhaps something like the following would be better text? " If subject naming information is present in only in the subject name field then the Subject Field of the peer certificate SHOULD contain a emailAddress RDN containing the Peer-Id and the Subject Field of the server certificate SHOULD contain the CN RDN containing the Server-ID. The peer and server ID MAY appear in a different field such as the serialNumber RDN, especially in the case where the deployment realm or domain of the certificate is not known at the time the certificate is issued (for example at manufacturing time). If subject naming information is present only in the subjectAltName extension then the subject field MUST be an empty sequence and the subjectAltName extension MUST be critical. " > > > > If subject naming > > > information is present only in the subjectAltName > extension then > > > the subject > > > field MUST be an empty sequence and the subjectAltName > extension > > > MUST be critical. > > > > > > > <snip> > > > > > However, in the case where the EAP-TLS peer is > > attempting to obtain > > > network > > > access, it will not have network connectivity and is > > therefore not > > > capable of checking for certificate revocation until after > > > authentication completes and network connectivity is > available. > > > For this reason EAP-TLS peers and servers SHOULD implement > > > Certificate Status Request messages, as described in [RFC3546] > > > section 3.6. To enable revocation checking in situations > > > where servers do not support Certificate > > > Status Request messages and network connectivity is not > > > available prior to authentication completion, peer > > > implementations SHOULD also support checking for certificate > > > revocation after authentication completes and network > > connectivity > > > is available, and SHOULD utilize this capability. > > > > [Joe] OK, if we go with OCSP as a SHOULD then I think checking for > > certificate revocation after network authentication > completes should > > be MUST to implement for the peer since there is a possibility that > > OCSP will not be available in the server implementation. > > [rmh] Well this should always be a matter of policy (maybe I have > > other ways to mitigate this risk in my environment), this > is the core > > issue with the requirement being a MUST. In such situations > most specs > > leave these sorts of requirements as a SHOULD, we could put > a MUST in > > there with some words that still let you choose though; what do you > > want to do? > > > [Joe] Right there is a difference between required to > implement and required to deploy. In most cases the MUSTs, > SHOULDs, etc are required to implement. A particular > deployment can often disable a particular feature if it does > not work in their environment. > > I think in this version of the text we have a MUST > requirement for certificate revocation checks which is > different than the SHOULD in RFC2716. If the peer must be > able to perform certificate validation then it needs to have > a mechanism to do this. Since OCSP in TLS (RFC > 4366) is a SHOULD it may not be implemented in a server the > peer is talking to, in which case the peer must be able to > fall back to post connection checks. It seems the first > SHOULD in the text refers to support in an implementation and > the second refers to deployment. It seems inconsistent to > have a MUST for revocation and no mandatory way to do it, but > perhaps the MUST for CRL support covers it. > > [rmh] OK, I buy this. I am OK with changing the SHOULD to a MUST. > > > > > " > > > > > > -----Original Message----- > > > From: Ryan Hurst [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, February 14, 2007 1:12 PM > > > To: Bernard Aboba; [email protected] > > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > > > > > I will do this before I go home today. > > > > > > -----Original Message----- > > > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, February 14, 2007 12:27 PM > > > To: [email protected] > > > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > > > > > If possible, I'd like to include text arising from this > > thread in the > > > -08 > > > version of the document, submitted by the IETF 68 deadline. > > > > > > To make it easier for me to figure out what that text is, > > it would be > > > helpful for someone to post the suggested changes in their > > entirety, > > > with modifications agreed to during the discussion. > > Further comments > > > can then refer to that text, suggesting specific changes. > > > > > > Having that record on the mailing list will make it a lot > > easier for > > > me to figure out what changes to make to the document. > > > > > > Thanks in advance, > > > > > > Bernard > > > > > > > > > > > > _______________________________________________ > > > Emu mailing list > > > [email protected] > > > https://www1.ietf.org/mailman/listinfo/emu > > > > > > _______________________________________________ > > > Emu mailing list > > > [email protected] > > > https://www1.ietf.org/mailman/listinfo/emu > > > > > > _______________________________________________ > > > Emu mailing list > > > [email protected] > > > https://www1.ietf.org/mailman/listinfo/emu > > > > > > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
