+1 ----- Original Message ---- From: Joseph Salowey (jsalowey) <[EMAIL PROTECTED]> To: Bernard Aboba <[EMAIL PROTECTED]>; Ryan Hurst <[EMAIL PROTECTED]>; gabriel montenegro <[EMAIL PROTECTED]>; [email protected] Cc: Bernard Aboba <[EMAIL PROTECTED]> Sent: Wednesday, June 20, 2007 8:34:25 PM Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs
This looks good. Joe > -----Original Message----- > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 20, 2007 10:26 AM > To: Ryan Hurst; Joseph Salowey (jsalowey); gabriel > montenegro; [email protected] > Cc: Bernard Aboba > Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs > > Here is the modified text. I also made it clear that these > requirements only apply to implementations exporting the > Peer-Id or Server-Id. > > "It is possible for more than one subjectAltName field to be > present in a peer or server certificate in addition to an > empty or non-empty subject distinguished name. > > EAP-TLS implementations supporting export of the Peer-Id and > Server-Id SHOULD export all the subjectAltName fields within > Peer-Ids or Server-Ids, and SHOULD also export a non-empty > subject distinguished name field within the Peer-Ids or Server-Ids. > All of the exported Peer-Ids and Server-Ids are considered valid. > > EAP-TLS implementations supporting export of the Peer-Id and > Server-Id SHOULD export Peer-Ids and Server-Ids in the same > order in which they appear within the certificate. > Such canonical ordering would aid in comparison operations > and would enable using those IDs for key derivation if that > is deemed useful. However, the ordering of fields within the > certificate SHOULD NOT be used for access control." > > > > > > ________________________________ > > Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs > Date: Tue, 19 Jun 2007 14:07:28 -0700 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [email protected] > CC: [EMAIL PROTECTED] > > > I think these changes are good. > > ________________________________ > > From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED] > Sent: Tue 6/19/2007 1:20 PM > To: Bernard Aboba; gabriel montenegro; [email protected] > Cc: Bernard Aboba > Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs > > > > > > -----Original Message----- > > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, June 19, 2007 12:02 PM > > To: Joseph Salowey (jsalowey); gabriel montenegro; > [email protected] > > Cc: Bernard Aboba > > Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs > > > > I'm not sure about defining the location of the subject name > > field, beyond what is covered in RFC 3280. I agree about the > > caution on utilizing ordering for access control. How about: > > > [Joe] OK, but in the text below the ordering seems to > apply to the subjectAltNames and is ambiguous as to whether > it applies to SubjectAltName. Maybe the bit about the order > should be at the end of the paragraph: > > "Peer and Server IDs SHOULD be exported in the same > order in which they appear in the certificate." > > > "It is possible for more than one subjectAltName field to be > > present in a peer or server certificate in addition to an > > empty or non-empty subject distinguished name. EAP-TLS > > implementations SHOULD export all the subjectAltName fields > > within Peer-Ids or Server-Ids in the same order in which they > > appear within the certificate. If the Subject distinguished > > name is non-empty then it SHOULD be exported within the > > Peer-Ids or Server-Ids. All of the exported Peer-Ids and > > Server-Ids are considered valid. > > > > Such canonical ordering would aid in comparison operations > > and would enable using those IDs for key derivation if that > > is deemed useful later on. However, the ordering of fields > > within the certificate SHOULD NOT be used for access control." > > > [Joe] sounds good. > > > > > > > > > > Subject: RE: [Emu] Multiple Peer-IDs and Server-IDs > > > Date: Tue, 19 Jun 2007 11:33:08 -0700 > > > From: [EMAIL PROTECTED] > > > To: [EMAIL PROTECTED]; [email protected] > > > CC: [EMAIL PROTECTED] > > > > > > I'm not so sure that it is a good idea to rely upon the > > order of attributes in a cert. The default behavior is that > > all names are valid. If you are looking for different > > behavior then you need more information than ordering to > > account for cases where an expected name is missing or the CA > > does not impose a particular order. > > > > > > I agree that order may be useful if you are using this > > information in key derivation. > > > > > > If we include this text we should explicitly define where > > the subject name goes in the list (at the end?) and caution > > against depending on order for access control. > > > > > > Cheers, > > > > > > Joe > > > > > > > -----Original Message----- > > > > From: gabriel montenegro [mailto:[EMAIL PROTECTED] > > > > Sent: Friday, June 15, 2007 12:18 AM > > > > To: [email protected] > > > > Cc: Bernard Aboba > > > > Subject: [Emu] Multiple Peer-IDs and Server-IDs > > > > > > > > Looking at > > > > > http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-1 > > > > 0.txt > > > > > <http://www.drizzle.com/%7Eaboba/EMU/draft-simon-emu-rfc2716bi > > > > s-10.txt> > > > > I have some comments. > > > > > > > > I think that the whole discussion about multiple Peer and > > > > Server-IDs could be reflected better in section 5.2 (last > > paragraph): > > > > > > > > OLD: > > > > It is possible for more than one subjectAltName field to > > be present > > > > in a peer or server certificate in addition to an empty or > > > > non-empty > > > > subject distinguished name. EAP-TLS > implementations SHOULD export > > > > all the subjectAltName fields within Peer-Ids or > > > > Server-Ids. If the > > > > Subject distinguished name is non-empty then it > SHOULD be exported > > > > within the Peer-Ids or Server-Ids. All of the exported > > > > Peer-Ids and > > > > Server-Ids are considered valid. > > > > > > > > It’s good that all available the IDs are being > exported, but > > > > perhaps we should impose a canonical ordering of those > > > > multiple identities. For example by adding "...in the same > > > > order in which they appear within the certificate": > > > > > > > > NEW: > > > > It is possible for more than one subjectAltName field to > > be present > > > > in a peer or server certificate in addition to an empty or > > > > non-empty > > > > subject distinguished name. EAP-TLS > implementations SHOULD export > > > > all the subjectAltName fields within Peer-Ids or > > > > Server-Ids in the same > > > > order in which they appear within the certificate. If the > > > > Subject distinguished name is non-empty then it > SHOULD be exported > > > > within the Peer-Ids or Server-Ids. All of the exported > > > > Peer-Ids and > > > > Server-Ids are considered valid. > > > > > > > > Such canonical ordering would aid in comparison operations > > > > and would enable using those IDs for key > derivation if that > > > > is deemed useful later on. > > > > > > > > -gabriel > > > > > > > > > > > > > > _______________________________________________ > > > 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
