Hi Ryan, Looks pretty good, two comments inline below.
Joe > -----Original Message----- > From: Ryan Hurst [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 14, 2007 3:00 PM > To: Ryan Hurst; Bernard Aboba; [email protected] > Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt > > Bernard - I believe this block of text represents the changes > we have discussed in the thread, I would use it in your next release. > > "5.2 Peer and Server Identities > > The EAP-TLS peer name (Peer-Id) represents the identity to be > used for access control and accounting purposes. The Server-Id > represents the identity of the EAP server. > > In EAP-TLS, the Peer-Id and Server-Id are determined from > the subject > or subjectAltName fields in the peer and server certificates. As > noted in [RFC3280] Section 4.1.2.6. > > Where the subjectAltName field is present in the peer or server > certificate, the Peer-Id or Server-Id MUST be set to the contents > of the subjectAltName as per Section 5.3. > > 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. > 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. > " > > -----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
