Subject: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue

From: Bernard Aboba <[email-masked]>
Date: Tue, 5 Jun 2007 22:04:56 -0700

It has been pointed out that an EAP-TLS certificate can contain multiple subject or subjectAltName fields.  To address this, I propose that we add the following text to Section 5.2:It is possible for more than one subjectAltName field to be presentin a peer or server certificate.  Where more than one subjectAltNamefield is present in a certificate, EAP-TLS implementations SHOULDexport all the subjectAltName fields within Peer-Ids orServer-Ids; all of the exported Peer-Ids and     Server-Ids are considered valid.  Similarly, if more than one subject field is present in a peer orserver certificate, and no subjectAltName field is present, thenEAP-TLS implementations SHOULD export all of the subject fieldswithin Peer-Ids and Server-Ids;   all of the exported Peer-Ids and Server-Ids are considered valid.

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Wed, 6 Jun 2007 15:52:48 -0700

Hi Bernard,

I don't think a valid certificate can have multiple subject
distinguished names. I think it would be more in line with RFC 3280 to
treat the subject distinguished name as part of the valid name set if it
is non-empty.  

"It is possible for more than one subjectAltName field to be present in
a peer or server certificate in addition to a non-empty subject
distinguished name.  EAP-TLS implementations SHOULD export a non-empty
Subject distinguished name along with  all the subjectAltName fields
within Peer-Ids or Server-Ids; all of the exported Peer-Ids and
Server-Ids are considered valid. "

Joe 

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Tuesday, June 05, 2007 10:05 PM
> To: [email-masked]
> Subject: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue
> 
> It has been pointed out that an EAP-TLS certificate can 
> contain multiple subject or subjectAltName fields.  
> 
> To address this, I propose that we add the following text to 
> Section 5.2:
> 
> It is possible for more than one subjectAltName field to be 
> present in a peer or server certificate.  Where more than one 
> subjectAltName field is present in a certificate, EAP-TLS 
> implementations SHOULD export all the subjectAltName fields 
> within Peer-Ids or
> Server-Ids; all of the exported Peer-Ids and     
> Server-Ids are considered valid.  
> 
> Similarly, if more than one subject field is present in a 
> peer or server certificate, and no subjectAltName field is 
> present, then EAP-TLS implementations SHOULD export all of 
> the subject fields
> within Peer-Ids and Server-Ids;   all of the exported Peer-Ids and 
> Server-Ids are considered valid.
> 
>

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 6 Jun 2007 16:16:33 -0700

Your right, there can be only one distinguished name.

However there are also cases where there are more than one
subjectAltName may be present with a empty DN also; I don't think
mandating a DN is a good idea since 3280 doesn't do that.

Ryan

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Wednesday, June 06, 2007 3:53 PM
To: Bernard Aboba; [email-masked]
Subject: RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id
Issue

Hi Bernard,

Joe

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Wed, 6 Jun 2007 16:37:08 -0700

I agree, my intent wasn't to mandate a DN, my text needs to be improved.

Does this help?

"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. "
 
Thanks,

Joe

> From: Ryan Hurst [mailto:[email-masked]] 
> Sent: Wednesday, June 06, 2007 4:17 PM
> To: Joseph Salowey (jsalowey); Bernard Aboba; [email-masked]
> Subject: RE: [Emu] Proposed Resolution to multiple 
> Peer-Id/Server-Id Issue
> 
> subjectAltName may be present with a empty DN also; I don't 
> think mandating a DN is a good idea since 3280 doesn't do that.
> 
> Ryan
> 
> 
> Subject: RE: [Emu] Proposed Resolution to multiple 
> Peer-Id/Server-Id Issue
> 
> Hi Bernard,
> 
> distinguished names. I think it would be more in line with 
> RFC 3280 to treat the subject distinguished name as part of 
> the valid name set if it is non-empty.  
> 
> "It is possible for more than one subjectAltName field to be 
> present in a peer or server certificate in addition to a 
> non-empty subject distinguished name.  EAP-TLS 
> implementations SHOULD export a non-empty Subject 
> distinguished name along with  all the subjectAltName fields 
> within Peer-Ids or Server-Ids; all of the exported Peer-Ids 
> and Server-Ids are considered valid. "
> 
> Joe 
> 
> > It has been pointed out that an EAP-TLS certificate can contain 
> > multiple subject or subjectAltName fields.
> > 
> > To address this, I propose that we add the following text 
> to Section 
> > 5.2:
> > 
> present in 
> > a peer or server certificate.  Where more than one subjectAltName 
> > field is present in a certificate, EAP-TLS implementations SHOULD 
> > export all the subjectAltName fields within Peer-Ids or
> > Similarly, if more than one subject field is present in a peer or 
> > server certificate, and no subjectAltName field is present, then 
> > EAP-TLS implementations SHOULD export all of the subject fields