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 presentin a peer
or server certificate in addition to an empty or non-emptysubject distinguished
name.
EAP-TLS implementations supporting export of the Peer-Id and Server-Id SHOULD
exportall the subjectAltName fields within Peer-Ids or Server-Ids, and SHOULD
alsoexport 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
exportPeer-Ids and Server-Ids in the same order in which they appear within the
certificate.Such canonical ordering would aid in comparison operationsand would
enable using those IDs for key derivation if thatis deemed useful. However,
the ordering of fields withinthe certificate SHOULD NOT be used for access
control."
Subject: RE: [Emu] Multiple Peer-IDs and Server-IDsDate: Tue, 19 Jun 2007
14:07:28 -0700From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]: [EMAIL PROTECTED]
I think these changes are good.
From: Joseph Salowey (jsalowey) [mailto:[EMAIL PROTECTED]: Tue 6/19/2007 1:20
PMTo: Bernard Aboba; gabriel montenegro; [EMAIL PROTECTED]: Bernard
AbobaSubject: 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 [EMAIL PROTECTED]://www1.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
