Yes, probably, but for EAP-TLS what we are talking about are names for the same entity which are the peer or the server.
I think new definitions are needed for these other concepts, which are not currently part of EAP-TLS. Joe > -----Original Message----- > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 09, 2007 9:11 AM > To: Joseph Salowey (jsalowey); emu@ietf.org > Subject: RE: [Emu] Multiple identity issue > > I think we may need a way to distinguish multiple names for > the same entity (e.g. mutiple subjectAltName/subject fields > in a single certificate) from multiple names that may not > refer to the same entity (e.g. Server-Id(s) provided within a > tunnel method whose Phase 1 and Phase 2 terminate on > different entities). Also, there is a need to distinguish > the identities that define the key scope (e.g. Phase 1 > identities from EAP-TTLSv0) from those that did not > contribute to key generation (e.g. Phase 2 identities from > EAP-TTLSv0). > > Joe Salowey said: > > > I think it would be more consistent with RFC 3280 if we report a > > non-empty subject name as well as the subjectAltNames since > they all > > are valid identities within the certificate. > > > > > -----Original Message----- > > > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > > > Sent: Tuesday, May 08, 2007 3:55 PM > > > To: Joseph Salowey (jsalowey); emu@ietf.org > > > Subject: RE: [Emu] Multiple identity issue > > > > > > The 3rd paragraph of Section 5.2 says: > > > > > > 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. If subject naming information is > present only in > > > the subjectAltName extension of a peer or server > certificate, then > > > the subject field MUST be an empty sequence and the > subjectAltName > > > extension MUST be critical. > > > > > > Therefore it would seem that presence of both a single > subject and > > > single subjectAltName would not result in export of multiple > > > Peer-Id(s) or Server-Id(s). This can only happen if there are > > > multiple subjectAltName fields. > > > > > > So how about: > > > > > > "It is possible for more than one subjectAltName field to > be present > > > in a peer or server certificate; similarly, it is possible for a > > > non-empty subject name field to also be present in a peer > or server > > > certificate. Where more than one subjectAltName field is > present in > > > a certificate, EAP-TLS may export more than one Peer-Id > or more than > > > one Server-Id; all of the exported Peer-Id(s) and > Server-Id(s) are > > > considered valid. " > > > > > > > > > Joe Salowey said: > > > > > > > looks good, except I think that there can be only one > Subject Name > > > > field in a valid certificate. How about something like: > > > > > > > > "It is possible for more than one subjectAltName field to > > > be present > > > > in a peer or server certificate; similarly, it is > possible for a > > > > non-empty subject name field to also be present in a peer or > > > > server certificate. In this case, EAP-TLS may export > more than one > > > Peer-Id or > > > > more than one Server-Id; all of the exported Peer-Id(s) and > > > > Server-Id(s) are considered > > > > valid. " > > > > > > > > > > > > ________________________________ > > > > > > > > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > > > > Sent: Tuesday, May 08, 2007 2:54 PM > > > > To: emu@ietf.org > > > > Subject: [Emu] Multiple identity issue > > > > > > > > > > > > At the EMU WG meeting, we discussed the situation where > > > more than one > > > > altsubjectName or subject field are present in a certificate. > > > > Here is some text which can be added to the end of > Section 5.2 to > > > > address this issue: > > > > > > > > "It is possible for more than one subjectAltName field to > > > be present > > > > in a peer or server certificate; similarly, it is possible for > > > > more than one subject name field to be present in a > peer or server > > > > certificate. In this case, EAP-TLS may export more than one > > > Peer-Id or > > > > more than one Server-Id; all of the exported Peer-Id(s) and > > > > Server-Id(s) are considered > > > > valid. " > > > > > > > > > > > > _______________________________________________ > > > > 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
