Subject: [Emu] Multiple Peer-IDs and Server-IDs

From: gabriel montenegro <[email-masked]>
Date: Fri, 15 Jun 2007 00:18:11 -0700 (PDT)

Looking at http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-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-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 19 Jun 2007 11:33:08 -0700

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-masked]] 
> Sent: Friday, June 15, 2007 12:18 AM
> To: [email-masked]
> 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’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:
> 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
>  
>