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

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Jun 2007 07:40:11 -0700

RFC 3280 says:

"  In addition, legacy implementations exist where an RFC 822 name is
   embedded in the subject distinguished name as an EmailAddress
   attribute.  The attribute value for EmailAddress is of type IA5String
   to permit inclusion of the character '@', which is not part of the
   PrintableString character set.  EmailAddress attribute values are not
   case sensitive (e.g., "[email-masked]" is the same as
   "[email-masked]").

   Conforming implementations generating new certificates with
   electronic mail addresses MUST use the rfc822Name in the subject
   alternative name field (section 4.2.1.7) to describe such identities.
   Simultaneous inclusion of the EmailAddress attribute in the subject
   distinguished name to support legacy implementations is deprecated
   but permitted."

Based on this, if the certificate is encoding an NAI as a name, then the subject alternative name field MUST be used.  Simultaneous inclusion of the NAI within an EmailAddress attribute in the subject distinguished name is deprecated, but permitted. 

So in the case where an NAI is encoded in the subjectAltName field, the subject DN would be a duplicate, no?  

----------------------------------------
> Subject: RE: [Emu] Proposed Resolution to multiple Peer-Id/Server-Id Issue
> Date: Wed, 6 Jun 2007 16:37:08 -0700
> From: [email-masked]
> To: [email-masked]; [email-masked]; [email-masked]
> CC: 
> 
> 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
> 
> > -----Original Message-----
> > 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
> > 
> > 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,
> > 
> > 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.
> > > 
> > > 
> > 
> > _______________________________________________
> > Emu mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/emu
> > 
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/emu

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

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Thu, 7 Jun 2007 08:52:27 -0700

> Sent: Thursday, June 07, 2007 7:40 AM
> To: Joseph Salowey (jsalowey); [email-masked]
> Cc: [email-masked]
> Based on this, if the certificate is encoding an NAI as a 
> name, then the subject alternative name field MUST be used.  
> Simultaneous inclusion of the NAI within an EmailAddress 
> attribute in the subject distinguished name is deprecated, 
> but permitted. 
> 
> So in the case where an NAI is encoded in the subjectAltName 
> field, the subject DN would be a duplicate, no?  
> 
[Joe] No, the EmailAddress RDN may not be included in the Subject DN. 

> Peer-Id/Server-Id 
> > Issue
> > "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 
> > 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
> > 
> 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
> > > 
> > > 
> Peer-Id/Server-Id 
> > > Issue
> > > 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
> > >