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:
"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 SHOULD exportall the subjectAltName fields within
Peer-Ids or Server-Ids in the same order in which they appear within the
certificate. If theSubject distinguished name is non-empty then it SHOULD be
exportedwithin the Peer-Ids or Server-Ids. All of the exported Peer-Ids
andServer-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."
> 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
