In-line -----Original Message----- From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED] Sent: Friday, February 16, 2007 4:15 PM To: Ryan Hurst; Bernard Aboba; emu@ietf.org Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt
> > 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 > > [Joe] Can we qualify this with user and device as we did with > subjectAltName? > > "If subject naming information is present in only in the > subject name field then the Subject Field of and the peer > identity represents a user the certificate SHOULD contain a > emailAddress RDN. If the peer identity represents a host or > device the certificate SHOULD contain a CN RDN or Serial > Number RDN. The Subject Field of the server certificate MUST > contain the CN RDN or Serial Number RDN containing the Server-ID. > > [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? > > 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; emu@ietf.org > > 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: emu@ietf.org > > 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 > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > > > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www1.ietf.org/mailman/listinfo/emu > > > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
