Subject: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

From: Ryan Hurst <[email-masked]>
Date: Mon, 5 Feb 2007 13:03:36 -0800

Joe - For some reason I didn't get your email, I found it on the
archives; bellow are the questions from that mail and my answers:

        Where the subjectAltName field is present in the peer or

        Server certificate, the Peer-Id or Server-Id MUST be set

        to the contents of the subjectAltName as per Section 5.3.  

        [Joe] Why subjectAltName and not Subject?  

        [rmh] The use of the subject name was intended to represent a
directory location, directory locations may or

              may not include the a value that would reasonable map to
the subject id (eg a E rdn).

              its bad form to require people to change their directory
layout to deploy a application, therefore

              standards that take a dependency on a specific name form
being present in a certificate should do so

              by specifying that name form exist in the subjectAltName.

           If subject naming information is present in only in the

           subject name field then the Subject Field of the peer

           certificate SHOULD contain a E RDN containing the Peer-Id.

        [Joe] What is E RDN?  

        [rmh] RDN is a relative distinguished name, DNs are made up of
these;

              There is a RDN is for the email address, I don't have the
X.500

              documents handy but its defined in there. I remember the
name being

              just E; however I did some googling and looks like I was
wrong its

              emailAddress.

           Although the use of  the subject field is existing practice,

           its use in EAP-TLS is deprecated and Certification
Authorities

           are encouraged to use the subjectAltName field instead.

        [Joe] Are there other standards that are deprecating the use of
subject

        field as well?  (This is related to my first question above.)

        [rmh] uid is the only other RDN that a peer-id like value that
might be used in

        [rmh] however in practice I have never seen this used; see my
other comment as

        [rmh] to why. This is one of the reasons other rfcs like TLS
deprecate use of the

        [rmh] subject dn for subjectAltName instead (see 3.1 of
http://www.ietf.org/rfc/rfc2818.txt)

        Where the peer identity represents a host, a subjectAltName

        of type dNSName SHOULD be present in the peer certificate.
Where the

        peer identity represents a user and not a resource, a
subjectAltName of type

        rfc822Name SHOULD be used, conforming to the grammar for the

        Network Access Identifier (NAI) defined in [RFC4282] Section
2.1. 

        If the peer identity represents neither a host nor a user,

        another field type (for example a subjectAltName of type
iPAddress

        or uniformResourceIdentifier) MAY be used. 

        [Joe] There may be hosts which do not have a DNSName or
Ipaddress (L2

         entities), so I think we need to clarify the above text.

        [rmh] This text does not preclude the inclusion of other name
forms 

        [rmh] it even allows for it by saying other types can be
included.

        [rmh] It is important to encourage a name form be included for
interop sake

        [rmh] dnsName and rfc822 is clearly the most common in existing
deployments 

        [rmh] so including it seems appropriate.

        [rmh] There should be some text in the security consideration
section

        [rmh] about the MITM risks associated with making a trust
decision

        [rmh] on unauthenticated values you have at L2.

        A server identity will typically represent a host, not a user

        Or a resource.  As a result, a subjectAltName of type dNSName

        SHOULD be present in the server certificate.  A subjectAltName
of

        Type iPAdress MAY be used in the server certificate. 

        [Joe] We probably need to allow various name types for the
server as

        well.  I think there still needs to be some discussion on how

        subjectAltNames map to peer and server names in the case where
there are

        multiple subjectAltNames.

        [rmh] How about we change "A subjectAltName of type iPAdress MAY
be used

        [rmh] in the server certificate." To "If a dnsName is not
available other

        [rmh] field types (for example a subjectAltName of type iPAdress
or

        [rmh] uniformResourceIdentifier) MAY be used.

        5.4.  Certificate revocation

           Certificates are long lived assertions of identity. 

           Therefore it is important for EAP-TLS implementations to 

           be capable of checking whether these assertions have been 

           revoked. 

           EAP-TLS peer and server implementations MUST support the 

           use of Certificate Revocation Lists (CRLs); for details,

           see [RFC3280] section 3.3.  EAP-TLS peer and server 

           implementations SHOULD also support the Online 

           Certificate Status Protocol (OCSP), described in [RFC2560].

           OCSP messages are typically much smaller than CRLs which can

           shorten connection times especially in bandwidth constrained

           environments.

           While EAP-TLS servers are typically connected to the Internet

           during the EAP conversation, an EAP-TLS peer may not have

           Internet connectivity until authentication completes. 

        [Joe]  This is somewhat different than what the current draft
has

        specified up until now.   I am a little uneasy with OCSP as a
SHOULD,

        are there other specifications which have such a strong
recommendation

        for OCSP?

        [rmh] I know of no other RFC that uses SHOULD for OCSP, however
I know of

        [rmh] no other protocol in which its primary use case prevents a
client from

        [rmh] checking the revocation status of the server. The use of
OCSP and TLS

        [rmh] extensions enables this client to do this check.

        [rmh] The SHOULD is a response to this security risk, weaker
wording would be

        [rmh] the same as saying MAY choose to be vulnerable to these
attacks, SHOULD

        [rmh] allows vendors to choose not to do so while encouraging
them to address

        [rmh] these risks.

        [rmh] There are also the latency and timing issues associated
with network connections

        [rmh] make the download of 800k CRLs before a connect can happen
is a deal breaker,

        [rmh] a few K (as little as 400 bytes) for a OCSP response is a
much better deal.

        [rmh] I feel strongly the RFC needs to provide guidance on how
to use certificates

        [rmh] securely and in a deployable way.

        [rmh] I appreciate that not all implementations do this but that
is why its

        [rmh] not a MUST.

        For this reason EAP-TLS peers and servers SHOULD implement 

        Certificate Status Request messages, as described in [RFC3546] 

        section 3.6.  To enable revocation checking in situations 

        where servers do not support Certificate

        Status Request messages and network connectivity is not

        available prior to authentication completion,  peer 

        implementations SHOULD also support checking for certificate 

        revocation after authentication completes and network
connectivity 

        is available, and SHOULD utilize this capability. 

        [Joe] A strong recommendation for TLS extensions is somewhat
counter to

        some of the discussions we have had in the past about keeping
EAP-TLS as

        bare bones as possible.   I would like to hear other's opinion
on this. 

        [rmh] See my earlier comment on the security risks associated
with the use

        [rmh] scenarios for this protocol, its dependency on
certificates at layer 2,

        [rmh] and the clients inability to perform revocation checking.

        [rmh] The use of OCSP and the TLS extension addresses this risk.

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

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 6 Feb 2007 08:34:56 -0800

Hi Ryan,

I understand the deprecation of subjectName in favor of SubjectAltName,
this makes sense to me now.  
 
I'm still struggling a little with mapping subjectAltName and
subjectName certificate fields to peer and server identities.  I think
the text you suggested for the server name subjectAltName mapping is
good:

I think we should have similar text for the peer name.  There are cases
where either or both the EAP peer and EAP server may be devices that do
not have an RFC822 name or dnsName.  

I am a bit concerned with the text for the subject DN.  Why not use the
same field for both server and peer certificates?  In my experience the
email address in a certificate subject DN is not always the best
identifier. Could CN be used instead of email address?  

With regard to usage of OCSP, I understand the concern you raise.
However, the current practice of retrieving a CRL when attached to the
network and validating the accepted certificate seems to provide decent
protection.  The OCSP in TLS approach is a better approach, but how much
better is it?  A SHOULD is a fairly strong requirement and its use here
may affect how quickly this document can move through the standards
track.  I want to make sure we are getting significant benefit from this
added requirement. 

Joe

________________________________

	From: Ryan Hurst [mailto:[email-masked]] 
	Sent: Monday, February 05, 2007 1:04 PM
	To: [email-masked]
	Subject: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

	        to the contents of the subjectAltName as per Section
5.3.  

	        [rmh] The use of the subject name was intended to
represent a directory location, directory locations may or

	              may not include the a value that would reasonable
map to the subject id (eg a E rdn).

	              its bad form to require people to change their
directory layout to deploy a application, therefore

	              standards that take a dependency on a specific
name form being present in a certificate should do so

	              by specifying that name form exist in the
subjectAltName.

	           If subject naming information is present in only in
the

	           certificate SHOULD contain a E RDN containing the
Peer-Id.

	        [Joe] What is E RDN?  

	        [rmh] RDN is a relative distinguished name, DNs are made
up of these;

	              There is a RDN is for the email address, I don't
have the X.500

	              documents handy but its defined in there. I
remember the name being

	              just E; however I did some googling and looks like
I was wrong its

	              emailAddress.

	           Although the use of  the subject field is existing
practice,

	           are encouraged to use the subjectAltName field
instead.

	        [Joe] Are there other standards that are deprecating the
use of subject

	        field as well?  (This is related to my first question
above.)

	        [rmh] uid is the only other RDN that a peer-id like
value that might be used in

	        [rmh] however in practice I have never seen this used;
see my other comment as

	        [rmh] to why. This is one of the reasons other rfcs like
TLS deprecate use of the

	 

	        Where the peer identity represents a host, a
subjectAltName

	        of type dNSName SHOULD be present in the peer
certificate.  Where the

	        rfc822Name SHOULD be used, conforming to the grammar for
the

	        Network Access Identifier (NAI) defined in [RFC4282]
Section 2.1. 

	        If the peer identity represents neither a host nor a
user,

	         entities), so I think we need to clarify the above
text.

	        [rmh] This text does not preclude the inclusion of other
name forms 

	        [rmh] It is important to encourage a name form be
included for interop sake

	        [rmh] dnsName and rfc822 is clearly the most common in
existing deployments 

	        [rmh] There should be some text in the security
consideration section

	        [rmh] about the MITM risks associated with making a
trust decision

	        A server identity will typically represent a host, not a
user

	        Or a resource.  As a result, a subjectAltName of type
dNSName

	        SHOULD be present in the server certificate.  A
subjectAltName of

	        [Joe] We probably need to allow various name types for
the server as

	        well.  I think there still needs to be some discussion
on how

	        subjectAltNames map to peer and server names in the case
where there are

	        [rmh] How about we change "A subjectAltName of type
iPAdress MAY be used

	        [rmh] in the server certificate." To "If a dnsName is
not available other

	        [rmh] field types (for example a subjectAltName of type
iPAdress or

	           Therefore it is important for EAP-TLS implementations
to 

	           be capable of checking whether these assertions have
been 

	           revoked. 

	           EAP-TLS peer and server implementations MUST support
the 

	           use of Certificate Revocation Lists (CRLs); for
details,

	           Certificate Status Protocol (OCSP), described in
[RFC2560].

	           OCSP messages are typically much smaller than CRLs
which can

	           shorten connection times especially in bandwidth
constrained

	           environments.

	           While EAP-TLS servers are typically connected to the
Internet

	           during the EAP conversation, an EAP-TLS peer may not
have

	         

	        [Joe]  This is somewhat different than what the current
draft has

	        specified up until now.   I am a little uneasy with OCSP
as a SHOULD,

	        for OCSP?

	        [rmh] I know of no other RFC that uses SHOULD for OCSP,
however I know of

	        [rmh] no other protocol in which its primary use case
prevents a client from

	        [rmh] checking the revocation status of the server. The
use of OCSP and TLS

	        [rmh] The SHOULD is a response to this security risk,
weaker wording would be

	        [rmh] the same as saying MAY choose to be vulnerable to
these attacks, SHOULD

	        [rmh] allows vendors to choose not to do so while
encouraging them to address

	        [rmh] these risks.

	        [rmh] There are also the latency and timing issues
associated with network connections

	        [rmh] make the download of 800k CRLs before a connect
can happen is a deal breaker,

	        [rmh] a few K (as little as 400 bytes) for a OCSP
response is a much better deal.

	        [rmh] I feel strongly the RFC needs to provide guidance
on how to use certificates

	        [rmh] I appreciate that not all implementations do this
but that is why its

	        [rmh] not a MUST.

	        For this reason EAP-TLS peers and servers SHOULD
implement 

	        Certificate Status Request messages, as described in
[RFC3546] 

	        section 3.6.  To enable revocation checking in
situations 

	        implementations SHOULD also support checking for
certificate 

	        [Joe] A strong recommendation for TLS extensions is
somewhat counter to

	        some of the discussions we have had in the past about
keeping EAP-TLS as

	        bare bones as possible.   I would like to hear other's
opinion on this. 

	        [rmh] See my earlier comment on the security risks
associated with the use

	        [rmh] and the clients inability to perform revocation
checking.

	        [rmh] The use of OCSP and the TLS extension addresses
this risk.

---

From: Ryan Hurst <[email-masked]>
Date: Tue, 13 Feb 2007 10:35:24 -0800

Comments in-line

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Tuesday, February 06, 2007 8:35 AM
To: Ryan Hurst; [email-masked]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

Hi Ryan,

 

	[rmh] Could you propose some text that would address your
concern?
	[rmh] It was my hope that the following (from the original
proposal)
	[rmh] would address this concern:
 
		If the peer identity represents neither a host nor a
user, another field
		type (for example a subjectAltName of type iPAddress
		or uniformResourceIdentifier) MAY be used.

	[rmh] CNs contain common names, for example my CN in the
directory is Ryan Hurst,
	[rmh] this is the appropriate use of CN and as you can see this
is not non-ambiguous
	[rmh] (there is a actor with the same name BTW).

	[rmh] Since servers do not have "common names" it is has become
standard to put the
	[rmh] DNS name in the common name field instead of using a
dNSName RDN (I am not even sure
	[rmh] one exists). 

	[rmh] In the case of user certificates clearly users have common
names, and applications almost
	[rmh] universally expect this field to be present for display
purposes. It's this reason the eMail 
	[rmh] address (when present in a DN) is put into its own RDN.

	[rmh] The proposed text is consistent with all certificate
mapping implementations I have ever encountered,
	[rmh] and it should also be consistent with the HTTP over SSL
RFC that prescribes much of the same.

	[rmh] In the end applications have one of two choices when doing
mapping, map on the full subject DN or
	[rmh] map on the email address and we should not specify
anything inconsistent with that as it will lead
	[rmh] to problems.

[rmh] I understand the concern, and it's certainly a tricky balance
trying to
[rmh] do what is right for security and keeping the process streamlined
but I would
[rmh] think it would be best for us to lean towards security vs. process
when crafting.
[rmh] documents like this. OCSP is nearly a decade old, there are a
dozen interoperable
[rmh] implementations out there TLS 1.1 (also several years old now)
which this document
[rmh] takes a normative reference to supports the exchange of OCSP
messages for this 
[rmh] exact case. 

[rmh] As for the OCSP stapling approach vs the post connect revocation
(CRL or OCSP) 
[rmh] check approach, the difference is that with the OCSP approach you
get to know if
[rmh] your at risk before you present your credentials, etc but with the
post check approach
[rmh] you only know once the damage is done.

Joe

	        [Joe] What is E RDN?  

	              emailAddress.

	 

	           revoked. 

	           environments.

	         

	        for OCSP?

	        [rmh] these risks.

	        [rmh] not a MUST.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 13 Feb 2007 10:58:51 -0800

Question:

What about a device that has a MAC address as a name?  Use of EAP-TLS with 
MAC certificates is being discussed in WiMAX Forum and IEEE 802.1AR.  Where 
should the MAC address be placed (subject vs. subjectAltName) and what field 
type should it have?  Is there a reference that defines the formatting of 
field types? Is there guidance on how to format the MAC address 
consistently? (e.g. 00037B5FCE73 in WiMAX vs. 00:03:7B:5F:CE:73 in IEEE 
802.1AR).

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 13 Feb 2007 12:17:55 -0800

802.1AR is not specifying that a device identity within a certificate
has to be a MAC address.  It can be any identifier that is unique within
a manufacturer's domain.  The current thinking is that the identity
would go in the common name of the subject name. 

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Tuesday, February 13, 2007 10:59 AM
> To: [email-masked]
> What about a device that has a MAC address as a name?  Use of 
> EAP-TLS with MAC certificates is being discussed in WiMAX 
> Forum and IEEE 802.1AR.  Where should the MAC address be 
> placed (subject vs. subjectAltName) and what field type 
> should it have?  Is there a reference that defines the 
> formatting of field types? Is there guidance on how to format 
> the MAC address consistently? (e.g. 00037B5FCE73 in WiMAX vs. 
> 00:03:7B:5F:CE:73 in IEEE 802.1AR).
> 
> 
>

---

From: Ryan Hurst <[email-masked]>
Date: Tue, 13 Feb 2007 13:38:02 -0800

I am not sure the MAC address is directly relevant to this effort, as
long as we allow for alternate bindings to be used (I think the text I
proposed does this) then these problems can be dealt with in other
documents.

As for the MAC address as a identifier, I actually am not a fan; from
what I can tell it has been added to facilitate better certificate
selection but there are much better ways to achieve that; I have been
tempted to write a informational on how proper certificate selection is
done but have not had the time.

The problem with a MAC address is that certificates normally contain
bindings of entitlements or constraints, these are all assertions that
the CA can stand behind (I have verified that the holder of this key has
the rights to this fqdn, I have verified he is entitled to represent
that FQDN for server TLS transactions, etc.).

You just can't do that with a MAC address, not in any reasonable way;
now device identity is a SUPER important thing without it we will
continue to take dependencies on weak identifiers like MAC addresses to
perform exceptions and entitlements (which essentially throw out any
security value modern isolation solutions provide) so the work being
done by AR is important.

As for where AR puts the identity, generally speaking you should be able
to tell what is in a RDN given a certificate usage; so if AR has a EKU
for Device Authentication I suppose its fine for it to say when this EKU
is present the RDN CN has special meaning, otherwise it should go
elsewhere.

Actually now that I think about it I would suggest that they go in
subjectAltName; again the general thinking about Subject DNs is they map
to a directory entity; this isn't always the case and its likely not the
case with a device certificate (many assumptions in this statement so be
kind), in such cases its probably more appropriate to have a empty
Subject DN and use a existing name form (urn, etc.) in subjectAltName or
define a new name form for the subjectAltName extension.

Ryan

---

From: "Ray Bell" <[email-masked]>
Date: Tue, 13 Feb 2007 14:31:42 -0800

The CableLabs Device PKI process should be considered...

http://www.cablelabs.com/certqual/security/

Ray

-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]] 
Sent: Tuesday, February 13, 2007 1:38 PM
To: Joseph Salowey (jsalowey); Bernard Aboba; [email-masked]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

Ryan

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Wed, 14 Feb 2007 07:37:47 -0800

Comments inline below.

> Sent: Tuesday, February 13, 2007 10:35 AM
> To: Joseph Salowey (jsalowey); [email-masked]
> iPAdress MAY
[Joe] OK, I think it does.  Here is what I have for the text around
SubjectAltName

   "Although the use of  the subject field is existing practice, its use
in EAP-TLS
   is deprecated and Certification Authorities are encouraged to use 
   the subjectAltName field instead.

   Where the peer identity represents a host, a subjectAltName of type 
   dNSName SHOULD be present in the peer certificate.  Where the peer 
   identity represents a user and not a resource, a subjectAltName of
type
   rfc822Name SHOULD be used, conforming to the grammar for the
   Network Access Identifier (NAI) defined in [RFC4282] Section 2.1. 
   If the peer identity represents neither a host nor a user, another
field
   type (for example a subjectAltName of type iPAddress
   or uniformResourceIdentifier) MAY be used. 

   A server identity will typically represent a host, not a user or
   a resource.  As a result, a subjectAltName of type dNSName SHOULD be
   present in the server certificate.  If a dnsName is not available
other
   field types (for example a subjectAltName of type iPAdress or
   uniformResourceIdentifier) MAY be used."

> RFC that prescribes much of the same.
[Joe] With certificates embedded in device the email address portion of
the DN is not used so consistently, it does not typically refer to the
email address of the device but rather of an organization. 

> anything inconsistent with that as it will lead
[Joe] It seems that mapping on the full subject DN may be more
appropriate in this case since the processor may not know if the peer
cert represents a device or user identity. 
  
> [rmh] you only know once the damage is done.
[Joe] With EAP-TLS the peer credentials are certificate based
credentials, I don't see much risk in using these.  With EAP-TLS you can
defer presenting other credentials or performing operations that are a
higher risk until after you have obtained the latest CRL.  This is
different than something like PEAP or TTLS which presents weak
credentials before the network connection is available.  I don't think
we should bring in new requirements into EAP-TLS unless they are
absolutely necessary. I think it may be appropriate to have a stronger
requirement for an enhanced TLS method or a password based method that
uses TLS. 

I think we probably need to start a separate thread on this topic.

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 14 Feb 2007 10:46:28 -0800

Hi Joe, even more comments in-line:

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 7:38 AM
To: Ryan Hurst; [email-masked]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

Comments inline below.

[rmh] OK, after this mail I will create a revised block of text that
incorporates all the changes we have discussed up until this point and
send it to the list.

[rmh] this should be fine since it is not MUST and the text explicitly
allows for alternate name forms to be used; you just can't have
interoperability in the mainline case without recommending at least one
name form per role; we clearly don't want to exclude other scenarios but
we want to encourage interoperability.

[rmh] It actually depends on the scenario, but both the full dn and
email model are legitimate (as are a few others, for example we have a
UPN and a SPN we can plausibly do mapping on also) we shouldn't prevent
other models from being used; I would just trying to explain why a
different model is used for server vs client.

[rmh] First the text does not mandate it only suggests (SHOULD vs MUST);
to your point about client certificates somehow mitigating this issue
it's not true, the 3280 hierarchical PKI trust model presumes that
revocation checking is done by the relying party before trust decisions
are made about the credential, this is due to the fact that these
certificates are long lived and are subject to compromise post issuance
(the older a cert is the less trust that should be placed in it); not
doing this check so or doing post checking exposes you this risk while
checking before you believe the credential does not.

[rmh] I would agree that as a bis it would be inappropriate for us to
mandate something new like this (for interop reasons) but providing a
strong recommendation seems to be appropriate.

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 14 Feb 2007 12:27:11 -0800

If possible, I'd like to include text arising from this thread in the -08 
version of the document, submitted by the IETF 68 deadline.

To make it easier for me to figure out what that text is, it would be 
helpful for someone to post the suggested changes in their entirety, with 
modifications agreed to during the discussion.  Further comments can then 
refer to that text, suggesting specific changes.

Having that record on the mailing list will make it a lot easier for me to 
figure out what changes to make to the document.

Thanks in advance,

Bernard

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 14 Feb 2007 13:11:36 -0800

I will do this before I go home today.

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 12:27 PM
To: [email-masked]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

If possible, I'd like to include text arising from this thread in the
-08 
version of the document, submitted by the IETF 68 deadline.

To make it easier for me to figure out what that text is, it would be 
helpful for someone to post the suggested changes in their entirety,
with 
modifications agreed to during the discussion.  Further comments can
then 
refer to that text, suggesting specific changes.

Having that record on the mailing list will make it a lot easier for me
to 
figure out what changes to make to the document.

Thanks in advance,

Bernard

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 14 Feb 2007 15:00:15 -0800

Bernard - I believe this block of text represents the changes we have
discussed in the thread, I would use it in your next release.

"5.2 Peer and Server Identities
 
   The EAP-TLS peer name (Peer-Id) represents the identity to be 
   used for access control and accounting purposes.  The Server-Id 
   represents the identity of the EAP server.
 
   In EAP-TLS, the Peer-Id and Server-Id are determined from the subject
   or subjectAltName fields in the peer and server certificates.  As
   noted in [RFC3280] Section 4.1.2.6.
  
   Where the subjectAltName field is present in the peer or server 
   certificate, the Peer-Id or Server-Id MUST be set to the contents 
   of the subjectAltName as per Section 5.3.  
 
   If subject naming information is present in only in the subject name
field
   then the Subject Field of the peer certificate SHOULD contain a
emailAddress RDN
   containing the Peer-Id and the Subject Field of the server
certificate MUST
   contain the CN RDN containing the Server-ID.  If subject naming
   information is present only in the subjectAltName extension then the
subject
   field MUST be an empty sequence and the subjectAltName extension
   MUST be critical. 
 
   Although the use of  the subject field is existing practice, its use
in EAP-TLS
   is deprecated and Certification Authorities are encouraged to use 
   the subjectAltName field instead.
 
   Where the peer identity represents a host, a subjectAltName of type 
   dNSName SHOULD be present in the peer certificate.  Where the peer 
   identity represents a user and not a resource, a subjectAltName of
type
   rfc822Name SHOULD be used, conforming to the grammar for the
   Network Access Identifier (NAI) defined in [RFC4282] Section 2.1. 
   If a dnsName or rfc822Name are not available other field types
   (for example a subjectAltName of type iPAdress or
uniformResourceIdentifier)
   MAY be used.

   A server identity will typically represent a host, not a user or
   a resource.  As a result, a subjectAltName of type dNSName SHOULD be
   present in the server certificate.  If a dnsName is not available
   other field types (for example a subjectAltName of type iPAdress or
   uniformResourceIdentifier) MAY be used. 

5.3.  Certificate Validation
 
   Since the EAP-TLS server is typically connected to the Internet,
   it SHOULD support validating the  peer certificate using 
   RFC 3280 [RFC3280] conformant path validation, including the 
   ability to retrieve intermediate certificates that may be
   necessary to validate the peer certificate. For details, 
   see [RFC3280] Section 4.2.2.1.
 
   Where the EAP-TLS server is unable to retrieve intermediate
   certificates, it must be pre-configured with the necessary 
   intermediate certificates to complete path validation or 
   rely on the EAP-TLS peer to provide this information as 
   part of the TLS Handshake (see [RFC4346] section 7.4.6).
   
   In contrast to the EAP-TLS server, the EAP-TLS peer may
   not have Internet connectivity. Therefore the EAP-TLS server 
   SHOULD provide its entire certificate chain minus the root to 
   facilitate certificate validation by the peer.
 
   Once a TLS session is established EAP-TLS peer and server 
   implementations MUST validate that the identities represented 
   in the certificate are appropriate and authorized for 
   use with EAP-TLS.  The authorization process makes 
   use of the contents of the certificates as well 
   as other contextual information.  While authorization 
   requirements will vary from deployment to deployment 
   it is RECOMMENDED that implementations be able to 
   authorize based on the EAP-TLS Peer-Id and Server-Id 
   determined as described in Section 5.2. 
 
   In the case of the EAP-TLS peer this involves ensuring 
   that the certificate presented by the EAP-TLS server was 
   intended to be used as a server certificate.
   Implementations SHOULD use the Extended Key 
   Usage (see [RFC3280] section 4.2.1.13) 
   extension and ensure that at least one of the 
   following is true:
 
   1) The certificate issuer included no Extended Key Usage 
        identifiers in the certificate.
   2) The issuer included the anyExtendedKeyUsage identifier 
       in the certificate (see [RFC3280] section 4.2.1.13).
   3) The issuer included the id-kp-serverAuth identifier 
       in the certificate (See [RFC3280] section 4.2.1.13).

   When performing this comparison implementations MUST follow the 
   validation rules specified in [RFC2818] Section 3.1.
   In the case of the server this involves ensuring the certificate 
   presented by the EAP-TLS peer was intended to be used as a 
   client certificate. Implementations SHOULD use the Extended 
   Key Usage (see [RFC3280] Section 4.2.1.13) extension and 
   ensure that at least one of the following is true:
 
   1) The certificate issuer included no Extended Key Usage identifiers
in the certificate.
   2) The issuer included the anyExtendedKeyUsage identifier in the
certificate 
       (see [RFC3280] section 4.2.1.13).
   3) The issuer included the id-kp-clientAuth identifier in the
certificate 
      (see [RFC3280] section 4.2.1.13).

 
   EAP-TLS peer and server implementations MUST support the 
   use of Certificate Revocation Lists (CRLs); for details,
   see [RFC3280] section 3.3.  EAP-TLS peer and server 
   implementations SHOULD also support the Online 
   Certificate Status Protocol (OCSP), described in [RFC2560].
   OCSP messages are typically much smaller than CRLs which can shorten 
   connection times especially in bandwidth constrained environments.
   While EAP-TLS servers are typically connected to the Internet during
   the EAP conversation, an EAP-TLS peer may not have Internet
   connectivity until authentication completes. 

   In the case where the peer is initiating a voluntary Layer 2 tunnel
   using PPTP [RFC2637] or L2TP [RFC2661], the peer will typically
   already have a PPP interface and Internet connectivity established at
   the time of tunnel initiation.
 
   However, in the case where the EAP-TLS peer is attempting to obtain
network
   access, it will not have network connectivity and is therefore not
   capable of checking for certificate revocation until after
   authentication completes and network connectivity is available.  
   For this reason EAP-TLS peers and servers SHOULD implement 
   Certificate Status Request messages, as described in [RFC3546] 
   section 3.6.  To enable revocation checking in situations 
   where servers do not support Certificate
   Status Request messages and network connectivity is not
   available prior to authentication completion,  peer 
   implementations SHOULD also support checking for certificate 
   revocation after authentication completes and network connectivity 
   is available, and SHOULD utilize this capability.
"

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 12:27 PM
To: [email-masked]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

Thanks in advance,

Bernard

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Wed, 14 Feb 2007 17:53:10 -0800

Hi Ryan,

Looks pretty good, two comments inline below.

Joe 

> Sent: Wednesday, February 14, 2007 3:00 PM
> To: Ryan Hurst; Bernard Aboba; [email-masked]
> Bernard - I believe this block of text represents the changes 
> we have discussed in the thread, I would use it in your next release.
> 
> subject name field
>    then the Subject Field of the peer certificate SHOULD 
> contain a emailAddress RDN
>    containing the Peer-Id 

[Joe] Can we qualify this with user and device as we did with
subjectAltName?

"If subject naming information is present in only in the subject name
field then the Subject Field of and the peer identity represents a user
the certificate SHOULD contain a emailAddress RDN.  If the peer identity
represents a host or device the certificate SHOULD contain a CN RDN or
Serial Number RDN. The Subject Field of the server certificate MUST
contain the CN RDN or Serial Number RDN containing the Server-ID.  

> If subject naming
>    information is present only in the subjectAltName 
> extension then the subject

<snip>

>    However, in the case where the EAP-TLS peer is attempting 
> to obtain network

[Joe] OK, if we go with OCSP as a SHOULD then I think checking for
certificate revocation after network authentication completes should be
MUST to implement for the peer since there is a possibility that OCSP
will not be available in the server implementation. 

> To make it easier for me to figure out what that text is, it 
> would be helpful for someone to post the suggested changes in 
> their entirety, with modifications agreed to during the 
> discussion.  Further comments can then refer to that text, 
> suggesting specific changes.
> 
> Having that record on the mailing list will make it a lot 
> easier for me to figure out what changes to make to the document.
> 
> Thanks in advance,
> 
> Bernard
> 
> 
>

---

From: Ryan Hurst <[email-masked]>
Date: Fri, 16 Feb 2007 10:22:44 -0800

Ray - I am familiar with the cable labs stuff, they put the MAC in the
CN although if I recall they don't specify how the value should be
represented which really limits its value IMHO.

I have looked at 802.1ar and from what I can tell they have not decided
where the value should go in their certificate profile, from the various
revisions it looks like they have considered many locations from the CN,
certificate Serial Number, subject serial number to a SAN othernames.

I have spoken to Bernard off-line and he has convinced me that it would
be useful for there to be a appendix discussing how one would include
this value in a certificate if it's to be used within EAP-TLS. 

I want to ping a few people for their opinions on location, my initial
take is that specifying a consistent format to represent the value as
and putting it in the CN or the subjectAltName:OtherName:PI are probably
the best bests but I need to think about it more.

Ryan

-----Original Message-----
From: Ray Bell [mailto:[email-masked]] 
Sent: Tuesday, February 13, 2007 2:32 PM
To: Ryan Hurst; 'Joseph Salowey (jsalowey)'; 'Bernard Aboba';
[email-masked]

Ray

-----Original Message-----
From: Ryan Hurst [mailto:[email-masked]] 
Sent: Tuesday, February 13, 2007 1:38 PM
To: Joseph Salowey (jsalowey); Bernard Aboba; [email-masked]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

Ryan

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Fri, 16 Feb 2007 10:42:12 -0800

> Sent: Friday, February 16, 2007 10:23 AM
> To: Ray Bell; Joseph Salowey (jsalowey); Bernard Aboba; [email-masked]
> Ray - I am familiar with the cable labs stuff, they put the 
> MAC in the CN although if I recall they don't specify how the 
> value should be represented which really limits its value IMHO.
> 
> I have looked at 802.1ar and from what I can tell they have 
> not decided where the value should go in their certificate 
> profile, from the various revisions it looks like they have 
> considered many locations from the CN, certificate Serial 
> Number, subject serial number to a SAN othernames.
> 
[Joe] The identifier in AR is not necessarily a MAC address. The
identifier format is determined by the manufacturuer. 

> I have spoken to Bernard off-line and he has convinced me 
> that it would be useful for there to be a appendix discussing 
> how one would include this value in a certificate if it's to 
> be used within EAP-TLS. 
> 
[Joe] What value?

> I want to ping a few people for their opinions on location, 
> my initial take is that specifying a consistent format to 
> represent the value as and putting it in the CN or the 
> subjectAltName:OtherName:PI are probably the best bests but I 
> need to think about it more.
> 
[Joe] I'm not quite sure what value you are talking about, but if it is
a device identity then why not the SN RDN.  

> I am not sure the MAC address is directly relevant to this 
> effort, as long as we allow for alternate bindings to be used 
> (I think the text I proposed does this) then these problems 
> can be dealt with in other documents.
> 
> As for the MAC address as a identifier, I actually am not a 
> fan; from what I can tell it has been added to facilitate 
> better certificate selection but there are much better ways 
> to achieve that; I have been tempted to write a informational 
> on how proper certificate selection is done but have not had the time.
> 
> The problem with a MAC address is that certificates normally 
> contain bindings of entitlements or constraints, these are 
> all assertions that the CA can stand behind (I have verified 
> that the holder of this key has the rights to this fqdn, I 
> have verified he is entitled to represent that FQDN for 
> server TLS transactions, etc.).
> 
> You just can't do that with a MAC address, not in any 
> reasonable way; now device identity is a SUPER important 
> thing without it we will continue to take dependencies on 
> weak identifiers like MAC addresses to perform exceptions and 
> entitlements (which essentially throw out any security value 
> modern isolation solutions provide) so the work being done by 
> AR is important.
> 
> As for where AR puts the identity, generally speaking you 
> should be able to tell what is in a RDN given a certificate 
> usage; so if AR has a EKU for Device Authentication I suppose 
> its fine for it to say when this EKU is present the RDN CN 
> has special meaning, otherwise it should go elsewhere.
> 
> Actually now that I think about it I would suggest that they 
> go in subjectAltName; again the general thinking about 
> Subject DNs is they map to a directory entity; this isn't 
> always the case and its likely not the case with a device 
> certificate (many assumptions in this statement so be kind), 
> in such cases its probably more appropriate to have a empty 
> Subject DN and use a existing name form (urn, etc.) in 
> subjectAltName or define a new name form for the 
> subjectAltName extension.
> 
> Ryan
> 802.1AR is not specifying that a device identity within a 
> certificate has to be a MAC address.  It can be any 
> identifier that is unique within a manufacturer's domain.  
> The current thinking is that the identity would go in the 
> common name of the subject name. 
> 
> > What about a device that has a MAC address as a name?  Use 
> of EAP-TLS 
> > with MAC certificates is being discussed in WiMAX Forum and IEEE 
> > 802.1AR.  Where should the MAC address be placed (subject vs. 
> > subjectAltName) and what field type should it have?  Is there a 
> > reference that defines the formatting of field types? Is there 
> > guidance on how to format the MAC address consistently? (e.g. 
> > 00037B5FCE73 in WiMAX vs.

---

From: Ryan Hurst <[email-masked]>
Date: Fri, 16 Feb 2007 10:51:51 -0800

In-line

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Friday, February 16, 2007 10:42 AM
To: Ryan Hurst; Ray Bell; Bernard Aboba; [email-masked]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joe] The identifier in AR is not necessarily a MAC address. The
identifier format is determined by the manufacturuer. 
[rmh] Your right, in the early versions of the document it read as if it
were a MAC, later revisions generalized it to a permanent identifier;
yet it still uses the MAC as a example but doesn't provide guidance on
format or limit its usage to a generalized identifier where format
wouldn't be relevant.

> how one would include this value in a certificate if it's to 
[Joe] What value?
[rmh] MAC.

[Joe] I'm not quite sure what value you are talking about, but if it is
a device identity then why not the SN RDN.  
[rmh] The problem with just saying SN RDN is that you can have many RDNs
in a given DN, plus by putting in the DN you potentially require
directory schemas to change to accommodate; the PI RFC
(http://www.ietf.org/rfc/rfc4043.txt) documents how one handles the
multiple RDN situation and specifies a othername name-form for
subjectAltName which allows you to specify the value without the
directory hit.
[rmh] Problem with PI is its intended for people not devices, however
from my read it has all the right properties to deal with a device id
such as a MAC address.

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Fri, 16 Feb 2007 11:25:02 -0800

> my initial 
> > and putting it in the CN or the subjectAltName:OtherName:PI are 
> > probably the best bests but I need to think about it more.
> > 
> [Joe] I'm not quite sure what value you are talking about, 
> but if it is a device identity then why not the SN RDN.  
> [rmh] The problem with just saying SN RDN is that you can 
> have many RDNs in a given DN, plus by putting in the DN you 
> potentially require directory schemas to change to 
> accommodate; the PI RFC
> (http://www.ietf.org/rfc/rfc4043.txt) documents how one 
> handles the multiple RDN situation and specifies a othername 
> name-form for subjectAltName which allows you to specify the 
> value without the directory hit.
> [rmh] Problem with PI is its intended for people not devices, 
> however from my read it has all the right properties to deal 
> with a device id such as a MAC address.
> 
[Joe] OK, got it. A consistent place to find a MAC address in a cert.
If this is the case I don't think CN is appropriate since it is used for
all sorts of random stuff.  I agree that  subjectAltName:OtherName:PI
looks promising.  I support we could also define a MAC address OID. 

> effort, as 
> fan; from 
> > tempted to write a informational on how proper certificate 
> selection 
> > is done but have not had the time.
> > 
> > the CA can stand behind (I have verified that the holder of 
> this key 
> > has the rights to this fqdn, I have verified he is entitled to 
> > represent that FQDN for server TLS transactions, etc.).
> > 
> reasonable way; 
> > continue to take dependencies on weak identifiers like MAC 
> addresses 
> > to perform exceptions and entitlements (which essentially throw out 
> > any security value modern isolation solutions provide) so the work 
> > being done by AR is important.
> > 
> > As for where AR puts the identity, generally speaking you should be 
> > able to tell what is in a RDN given a certificate usage; so 
> if AR has 
> > a EKU for Device Authentication I suppose its fine for it 
> to say when 
> > this EKU is present the RDN CN has special meaning, otherwise it 
> > should go elsewhere.
> > 
> > subjectAltName; again the general thinking about Subject 
> DNs is they 
> > map to a directory entity; this isn't always the case and 
> its likely 
> > not the case with a device certificate (many assumptions in this 
> > statement so be kind), in such cases its probably more 
> appropriate to 
> > have a empty Subject DN and use a existing name form (urn, etc.) in 
> > subjectAltName or define a new name form for the subjectAltName 
> > extension.
> > 
> > Ryan
> > has to be a MAC address.  It can be any identifier that is unique 
> > within a manufacturer's domain.

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Fri, 16 Feb 2007 11:32:02 -0800

> From: Joseph Salowey (jsalowey) 
> Sent: Friday, February 16, 2007 11:25 AM
> but if it 
> > is a device identity then why not the SN RDN.
> > [rmh] The problem with just saying SN RDN is that you can have many 
> > RDNs in a given DN, plus by putting in the DN you 
> potentially require 
> If this is the case I don't think CN is appropriate since it 
> is used for all sorts of random stuff.  I agree that  
> subjectAltName:OtherName:PI looks promising.  I support we 
> could also define a MAC address OID. 

[Joe] Should be "I suppose" instead of "I support" 

> should be

---

From: Ryan Hurst <[email-masked]>
Date: Fri, 16 Feb 2007 15:34:23 -0800

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Wednesday, February 14, 2007 5:53 PM
To: Ryan Hurst; Bernard Aboba; [email-masked]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

Hi Ryan,

Joe 

[rmh] As I understand it the peer ID always (essentially) looks like a
email address so host or otherwise it seems appropriate to use the
emailAddress RDN; this also (based on my experience) represents current
practice with the Subject DN being deprecated any new name-forms should
be proposed in the subjectAltName shouldn't it?

<snip>

[Joe] OK, if we go with OCSP as a SHOULD then I think checking for
certificate revocation after network authentication completes should be
MUST to implement for the peer since there is a possibility that OCSP
will not be available in the server implementation. 
[rmh] Well this should always be a matter of policy (maybe I have other
ways to mitigate this risk in my environment), this is the core issue
with the requirement being a MUST. In such situations most specs leave
these sorts of requirements as a SHOULD, we could put a MUST in there
with some words that still let you choose though; what do you want to
do?

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Fri, 16 Feb 2007 16:15:02 -0800

> >    If subject naming information is present in only in the subject 
> > name field
> "If subject naming information is present in only in the 
> subject name field then the Subject Field of and the peer 
> identity represents a user the certificate SHOULD contain a 
> emailAddress RDN.  If the peer identity represents a host or 
> device the certificate SHOULD contain a CN RDN or Serial 
> Number RDN. The Subject Field of the server certificate MUST 
> [rmh] As I understand it the peer ID always (essentially) 
> looks like a email address so host or otherwise it seems 
> appropriate to use the emailAddress RDN; this also (based on 
> my experience) represents current practice with the Subject 
> DN being deprecated any new name-forms should be proposed in 
> the subjectAltName shouldn't it?
>
[Joe] The peer name often takes the form of name@realm, but it does not
necessarily have to.  Another problem is that some existing device
implementations use the email address RDN, but it does not have a unique
identifier in it. 

> > If subject naming
> >    information is present only in the subjectAltName extension then 
> > the subject
> [Joe] OK, if we go with OCSP as a SHOULD then I think 
> checking for certificate revocation after network 
> authentication completes should be MUST to implement for the 
> peer since there is a possibility that OCSP will not be 
> available in the server implementation. 
> [rmh] Well this should always be a matter of policy (maybe I 
> have other ways to mitigate this risk in my environment), 
> this is the core issue with the requirement being a MUST. In 
> such situations most specs leave these sorts of requirements 
> as a SHOULD, we could put a MUST in there with some words 
> that still let you choose though; what do you want to do?
> 
[Joe] Right there is a difference between required to implement and
required to deploy.  In most cases the MUSTs, SHOULDs, etc are required
to implement.  A particular deployment can often disable a particular
feature if it does not work in their environment. 
I think in this version of the text we have a MUST requirement for
certificate revocation checks which is different than the SHOULD in
RFC2716.  If the peer must be able to perform certificate validation
then it needs to have a mechanism to do this.  Since OCSP in TLS (RFC
4366) is a SHOULD it may not be implemented in a server the peer is
talking to, in which case the peer must be able to fall back to post
connection checks.  It seems the first SHOULD in the text refers to
support in an implementation and the second refers to deployment.  It
seems inconsistent to have a MUST for revocation and no mandatory way to
do it, but perhaps the MUST for CRL support covers it.  

> > with modifications agreed to during the discussion.  
> Further comments 
> > can then refer to that text, suggesting specific changes.
> > 
> easier for 
> > me to figure out what changes to make to the document.
> > 
> > Thanks in advance,
> > 
> > Bernard
> > 
> > 
> >

---

From: Ryan Hurst <[email-masked]>
Date: Fri, 16 Feb 2007 16:26:59 -0800

In-line

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Friday, February 16, 2007 4:15 PM
To: Ryan Hurst; Bernard Aboba; [email-masked]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joe] The peer name often takes the form of name@realm, but it does not
necessarily have to.  Another problem is that some existing device
implementations use the email address RDN, but it does not have a unique
identifier in it. 
[rmh] Could you provide me a example? Is it a "unique" device ID of some
sort?

[rmh] OK, I buy this. I am OK with changing the SHOULD to a MUST.

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Sun, 18 Feb 2007 09:33:28 -0800

> looks like a 
> > emailAddress RDN; this also (based on my experience) represents 
> > current practice with the Subject DN being deprecated any new 
> > name-forms should be proposed in the subjectAltName shouldn't it?
> >
> [Joe] The peer name often takes the form of name@realm, but 
> it does not necessarily have to.  Another problem is that 
> some existing device implementations use the email address 
> RDN, but it does not have a unique identifier in it. 
> [rmh] Could you provide me a example? Is it a "unique" device 
> ID of some sort?

[Joe] Manufacturing installed certificates will not have a realm since
the realm will not be known at manufacturing time.  I have seen
manufacturing installed certificates where the email address field of
the DN contains a contact address such as "[email-masked]".  I do
see your point about email address having a similar form to NAI.
Perhaps something like the following would be better text?

" If subject naming information is present in only in the subject name
field
then the Subject Field of the peer certificate SHOULD contain a
emailAddress RDN
containing the Peer-Id and the Subject Field of the server certificate
SHOULD
contain the CN RDN containing the Server-ID.  The peer and server ID MAY
appear in a different field such as the serialNumber RDN, especially in
the case where the deployment realm or domain of the certificate is not
known at the time the certificate is issued (for example at
manufacturing time). If subject naming information is present only in
the subjectAltName extension then the subject
field MUST be an empty sequence and the subjectAltName extension
MUST be critical. "

> > certificate revocation after network authentication 
> completes should 
> > be MUST to implement for the peer since there is a possibility that 
> > OCSP will not be available in the server implementation.
> > [rmh] Well this should always be a matter of policy (maybe I have 
> > other ways to mitigate this risk in my environment), this 
> is the core 
> > issue with the requirement being a MUST. In such situations 
> most specs 
> > leave these sorts of requirements as a SHOULD, we could put 
> a MUST in 
> > there with some words that still let you choose though; what do you 
> > want to do?
> > 
> [Joe] Right there is a difference between required to 
> implement and required to deploy.  In most cases the MUSTs, 
> SHOULDs, etc are required to implement.  A particular 
> deployment can often disable a particular feature if it does 
> not work in their environment. 
> 
> I think in this version of the text we have a MUST 
> requirement for certificate revocation checks which is 
> different than the SHOULD in RFC2716.  If the peer must be 
> able to perform certificate validation then it needs to have 
> a mechanism to do this.  Since OCSP in TLS (RFC
> 4366) is a SHOULD it may not be implemented in a server the 
> peer is talking to, in which case the peer must be able to 
> fall back to post connection checks.  It seems the first 
> SHOULD in the text refers to support in an implementation and 
> the second refers to deployment.  It seems inconsistent to 
> have a MUST for revocation and no mandatory way to do it, but 
> perhaps the MUST for CRL support covers it.  
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 19 Feb 2007 22:02:50 -0800

>From the discussion it seems that if OCSP is a SHOULD implement, then we 
need a MUST for revocation checking after authentication, since some servers 
might not implement OCSP, right? I don't think we can add "MUST use" text 
for something that is a "SHOULD implement".

In terms of usage, it is possible for the Peer-Id to represent a machine 
name.  For example, with EAP-TLS the peer could use a machine certificate 
for authentication. So I think that the text on subjectAltName as well as 
the subject name field needs to reflect this.

BTW, I'm not entirely clear that the NAI syntax is completely compatible 
with that of an email address, although they are pretty close.  For example, 
RFC 4282 defines internationalization of the username field in the NAI, but 
for email addresses we aren't there yet.  This has come up in other contexts 
too (e.g. IKEv2 Identity Payload) where it turned out not to be a big deal, 
but I thought it was worth pointing out, just in case someone knows 
otherwise.

On the server side, I don't think that the Server-Id is likely to be an NAI, 
although I'm not sure we can prohibit that.

Based on the comments and my own cleanup, here is where I think we are at 
the moment.

Comments welcome.

=====================================================
5.2.  Peer and Server Identities

   The EAP-TLS peer name (Peer-Id) represents the identity to be used
   for access control and accounting purposes.  The Server-Id represents
   the identity of the EAP server.

   In EAP-TLS, the Peer-Id and Server-Id are determined from the subject
   or subjectAltName fields in the peer and server certificates.  As
   noted in [RFC3280] Section 4.1.2.6:

      The subject field identifies the entity associated with the public
      key stored in the subject public key field.  The subject name MAY
      be carried in the subject field and/or the subjectAltName
      extension...  If subject naming information is present only in the
      subjectAltName extension (e.g., a key bound only to an email
      address or URI), then the subject name MUST be an empty sequence
      and the subjectAltName extension MUST be critical.

      Where it is non-empty, the subject field MUST contain an X.500
      distinguished name (DN).

   Where the subjectAltName field is present in the peer or server
   certificate, the Peer-Id or Server-Id MUST be set to the contents of
   the subjectAltName as per Section 5.3.  If subject naming information
   is present only in the subjectAltName extension of a peer or server
   certificate, then the subject field MUST be an empty sequence and the
   subjectAltName extension MUST be critical.  Although the use of  the
   subject field is existing practice, its use in EAP-TLS is deprecated
   and Certification Authorities are encouraged to use the
   subjectAltName field instead.

   Where the peer identity represents a host, a subjectAltName of type
   dNSName SHOULD be present in the peer certificate.  Where the peer
   identity represents a user and not a resource, a subjectAltName of
   type rfc822Name SHOULD be used, conforming to the grammar for the
   Network Access Identifier (NAI) defined in [RFC4282] Section 2.1.  If
   a dnsName or rfc822Name are not available other field types (for
   example a subjectAltName of type iPAdress or
   uniformResourceIdentifier) MAY be used.

   A server identity will typically represent a host, not a user or a
   resource.  As a result, a subjectAltName of type dNSName SHOULD be
   present in the server certificate.  If a dnsName is not available
   other field types (for example a subjectAltName of type iPAdress or
   uniformResourceIdentifier) MAY be used.

   If subject naming information is present only in the subject name
   field and the peer identity represents a user, then the subject name
   field SHOULD contain an emailAddress RDN.  If the peer identity
   represents a host or device the subject name field SHOULD contain a
   CN RDN or Serial Number RDN.

   If subject naming information is present only in the subject name
   field of a server certificate, then the subject name field MUST
   contain a CN RDN or Serial Number RDN.

   Since the EAP-TLS server is typically connected to the Internet, it
   SHOULD support validating the  peer certificate using RFC 3280
   [RFC3280] conformant path validation, including the ability to
   retrieve intermediate certificates that may be necessary to validate
   the peer certificate. For details, see [RFC3280] Section 4.2.2.1.

   Where the EAP-TLS server is unable to retrieve intermediate
   certificates, it must be pre-configured with the necessary
   intermediate certificates to complete path validation or rely on the
   EAP-TLS peer to provide this information as part of the TLS Handshake
   (see [RFC4346] section 7.4.6).

   In contrast to the EAP-TLS server, the EAP-TLS peer may not have
   Internet connectivity.  Therefore the EAP-TLS server SHOULD provide
   its entire certificate chain minus the root to facilitate certificate
   validation by the peer.

   Once a TLS session is established EAP-TLS peer and server
   implementations MUST validate that the identities represented in the
   certificate are appropriate and authorized for use with EAP-TLS.  The
   authorization process makes use of the contents of the certificates
   as well as other contextual information.  While authorization
   requirements will vary from deployment to deployment it is
   RECOMMENDED that implementations be able to authorize based on the
   EAP-TLS Peer-Id and Server-Id determined as described in Section 5.2.

   In the case of the EAP-TLS peer this involves ensuring that the
   certificate presented by the EAP-TLS server was intended to be used
   as a server certificate.  Implementations SHOULD use the Extended Key
   Usage (see [RFC3280] section 4.2.1.13) extension and ensure that at
   least one of the following is true:

   When performing this comparison implementations MUST follow the
   validation rules specified in [RFC2818] Section 3.1.  In the case of
   the server this involves ensuring the certificate presented by the
   EAP-TLS peer was intended to be used as a client certificate.
   Implementations SHOULD use the Extended Key Usage (see [RFC3280]
   Section 4.2.1.13) extension and ensure that at least one of the
   following is true:

   1) The certificate issuer included no Extended Key Usage
      identifiers in the certificate.
   2) The issuer included the anyExtendedKeyUsage identifier in
      the certificate (see [RFC3280] section 4.2.1.13).
   3) The issuer included the id-kp-clientAuth identifier in
      the certificate (see [RFC3280] section 4.2.1.13).

5.4.  Certificate Revocation

   Certificates are long lived assertions of identity.  Therefore it is
   important for EAP-TLS implementations to be capable of checking
   whether these assertions have been revoked.

   EAP-TLS peer and server implementations MUST support the use of
   Certificate Revocation Lists (CRLs); for details, see [RFC3280]
   section 3.3.  EAP-TLS peer and server implementations SHOULD also
   support the Online Certificate Status Protocol (OCSP), described in
   [RFC2560].  OCSP messages are typically much smaller than CRLs which
   can shorten connection times especially in bandwidth constrained
   environments.  While EAP-TLS servers are typically connected to the
   Internet during the EAP conversation, an EAP-TLS peer may not have
   Internet connectivity until authentication completes.

   However, in the case where the EAP-TLS peer is attempting to obtain
   network access, it will not have network connectivity and is
   therefore not capable of checking for certificate revocation until
   after authentication completes and network connectivity is available.
   For this reason EAP-TLS peers and servers SHOULD implement
   Certificate Status Request messages, as described in [RFC3546]
   section 3.6.  To enable revocation checking in situations where
   servers do not support Certificate Status Request messages and
   network connectivity is not available prior to authentication
   completion,  peer implementations MUST also support checking for
   certificate revocation after authentication completes and network
   connectivity is available, and they SHOULD utilize this capability by
   default.

---

From: Ryan Hurst <[email-masked]>
Date: Tue, 20 Feb 2007 11:07:08 -0800

In-line

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Monday, February 19, 2007 10:03 PM
To: [email-masked]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

>From the discussion it seems that if OCSP is a SHOULD implement, then
we 
need a MUST for revocation checking after authentication, since some
servers 
might not implement OCSP, right? I don't think we can add "MUST use"
text 
for something that is a "SHOULD implement".

name.  For example, with EAP-TLS the peer could use a machine
certificate 
for authentication. So I think that the text on subjectAltName as well
as 
the subject name field needs to reflect this.

with that of an email address, although they are pretty close.  For
example, 
RFC 4282 defines internationalization of the username field in the NAI,
but 
for email addresses we aren't there yet.  This has come up in other
contexts 
too (e.g. IKEv2 Identity Payload) where it turned out not to be a big
deal, 
but I thought it was worth pointing out, just in case someone knows 
otherwise.

On the server side, I don't think that the Server-Id is likely to be an
NAI, 
although I'm not sure we can prohibit that.

Based on the comments and my own cleanup, here is where I think we are
at 
the moment.

Comments welcome.

[rmh] We do not universally quote deep references in this document, what
criteria are being applied to determine which references will warrant a
reference + quote vs. just a reference?

   If subject naming information is present only in the subject name
   field and the peer identity represents a user, then the subject name
   field SHOULD contain an emailAddress RDN.  If the peer identity
   represents a host or device the subject name field SHOULD contain a
   CN RDN or Serial Number RDN.
[rmh] If you say they can include a serialNumber (not Serial Number) RDN
then you have to specify processing symantics when more than one are
present, and discuss what sort of value is used here, etc.
[rmh] I suggest dropping the " or Serial Number RDN" portion of this
text, we can if appropriate work on a appendix or other RFC that
discusses these issues; I suspect the right answer will be to reference
the Permanent Identifier RFC from the PKIX working group which already
deals with these problems.

   If subject naming information is present only in the subject name
   field of a server certificate, then the subject name field MUST
   contain a CN RDN or Serial Number RDN.
[rmh] See my prior statements on serialNumber RDN.

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 20 Feb 2007 20:54:28 -0800

> [rmh] If you say they can include a serialNumber (not Serial 
> Number) RDN then you have to specify processing symantics 
> when more than one are present, and discuss what sort of 
> value is used here, etc.
> [rmh] I suggest dropping the " or Serial Number RDN" portion 
> of this text, we can if appropriate work on a appendix or 
> other RFC that discusses these issues; I suspect the right 
> answer will be to reference the Permanent Identifier RFC from 
> the PKIX working group which already deals with these problems.
> 

[Joe] Would you not have to do the same with email address or CN?  It
seems it would be possible for multiple of these to be present.  There
should not be any semantics associated with a serial number other than
it is an identifier.  It should not be interpreted as a MAC address or
some other value without additional knowledge outside this
specification.  I agree that this would not be the place to consistently
find a MAC address. I would prefer to keep Serial Number as a
possibility as it is at least as relevant as the other fields.  I would
be fine with the previous text I posted with a MAY.

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 20 Feb 2007 20:55:19 -0800

This text looks fine to me. 

> >From the discussion it seems that if OCSP is a SHOULD 
> implement, then 
> >we
> need a MUST for revocation checking after authentication, 
> since some servers might not implement OCSP, right? I don't 
> think we can add "MUST use" text for something that is a 
> "SHOULD implement".
> 
> In terms of usage, it is possible for the Peer-Id to 
> represent a machine name.  For example, with EAP-TLS the peer 
> could use a machine certificate for authentication. So I 
> think that the text on subjectAltName as well as the subject 
> name field needs to reflect this.
> 
> BTW, I'm not entirely clear that the NAI syntax is completely 
> compatible with that of an email address, although they are 
> pretty close.  For example, RFC 4282 defines 
> internationalization of the username field in the NAI, but 
> for email addresses we aren't there yet.  This has come up in 
> other contexts too (e.g. IKEv2 Identity Payload) where it 
> turned out not to be a big deal, but I thought it was worth 
> pointing out, just in case someone knows otherwise.
> 
> On the server side, I don't think that the Server-Id is 
> likely to be an NAI, although I'm not sure we can prohibit that.
> 
> Based on the comments and my own cleanup, here is where I 
> think we are at the moment.
> 
> Comments welcome.
> 
> Section 2.1.  If
> rely on the
> Therefore it is

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 20 Feb 2007 21:53:31 -0800

>reference + quote vs. just a reference?

[BA] I just realized that the last sentence of the first paragraph is 
already in the document.  I think the quote can be eliminated if we add the 
sentence "where it is non-empty..." into the text as well.

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 21 Feb 2007 08:48:48 -0800

Sounds like a good compromise.

From: Bernard Aboba [mailto:[email-masked]]
Sent: Tue 2/20/2007 9:53 PM
To: Ryan Hurst; [email-masked]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 21 Feb 2007 08:50:21 -0800

in-line

From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
Sent: Tue 2/20/2007 8:54 PM
To: Ryan Hurst; Bernard Aboba; [email-masked]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[rmh] Although your right that the fact that multiple RDNs can be used to make up a DN universally other RDNs are non-ambiguous while serialNumber conceptually is not,

[rmh] As for the value, EAP is not 802.11 only therefore a device id should not be a MAC, also a MAC has locally administered and globally adminstered versions, you would probably want to restrict the use to the globally issued ones, then there are the privacy issues since the MAC is used as a source address a attacker can presume if a EAP authentication is succesfull the MAC used in the source address was authenticated. I think there are other issues related to it being a MAC address that should be thought through before it is added; especially if its not even common practice today which it doesnt apear to be.

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Wed, 21 Feb 2007 09:04:04 -0800

> the PKIX working group which already deals with these
problems.
	
	[Joe] Would you not have to do the same with email address or
CN?  It
	seems it would be possible for multiple of these to be present.
There
	should not be any semantics associated with a serial number
other than
	it is an identifier.  It should not be interpreted as a MAC
address or
	some other value without additional knowledge outside this
	specification.  I agree that this would not be the place to
consistently
	find a MAC address. I would prefer to keep Serial Number as a
	possibility as it is at least as relevant as the other fields.
I would
	be fine with the previous text I posted with a MAY.

	[rmh] Although your right that the fact that multiple RDNs can
be used to make up a DN universally other RDNs are non-ambiguous while
serialNumber conceptually is not, 

	[Joe] Can you expand upon this? Why is SerialNumber different
than other RDNs? 

	[rmh] As for the value, EAP is not 802.11 only therefore a
device id should not be a MAC, also a MAC has locally administered and
globally adminstered versions, you would probably want to restrict the
use to the globally issued ones, then there are the privacy issues since
the MAC is used as a source address a attacker can presume if a EAP
authentication is succesfull the MAC used in the source address was
authenticated. I think there are other issues related to it being a MAC
address that should be thought through before it is added; especially if
its not even common practice today which it doesnt apear to be.

	[Joe]  I think we are in agreement here.

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 21 Feb 2007 09:15:22 -0800

in-line

From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
Sent: Wed 2/21/2007 9:04 AM
To: Ryan Hurst; Bernard Aboba; [email-masked]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

	

	[Joe] Can you expand upon this? Why is SerialNumber different than other RDNs? 

	[rmh] Conceptually a serial number is a exact match to a entity, for example no two tivos share the same serial number but they could all share the same common name of Tivo Series 2.

	[rmh] In my case case there is a actor who also shares the name Ryan Hurst (http://www.imdb.com/name/nm0403652/) but we both have unique ssns.

	[rmh] Since its CN is not intended to be non-ambiguous its reasonable for me to have multiple CNs in a certificate all of which are appropriate as a common name of me; for example I could have one that is just Ryan, another that is Ryan Hurst, another that is Ryan M Hurst.

	[rmh]  Since a serial number is a exact match, what does it mean if you have multiple serial numbers?

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 21 Feb 2007 09:52:57 -0800

I started work on some but it will take me a few days to get to finishing it, I sugest we leave it out here and include text in a appendix to cover it.
 
Ryan

From: Bernard Aboba [mailto:[email-masked]]
Sent: Wed 2/21/2007 9:51 AM
To: [email-masked]; Ryan Hurst; [email-masked]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

>authentication is successful the MAC used in the source address was

Use of the MAC address as an EAP-TLS identity is not yet common practice.  
Yet both IEEE 802.1AR and WiMAX documents talk about use of MAC addresses in
certificates (using different formats), so it could be used more widely in
the future.

I agree that using a locally administered MAC address as an identity in
EAP-TLS does not make sense.

Do we have proposed text to deal with this issue?

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Wed, 21 Feb 2007 09:56:49 -0800

> Sent: Wednesday, February 21, 2007 9:52 AM
> To: Joseph Salowey (jsalowey); [email-masked]; [email-masked]
> >	[rmh] As for the value, EAP is not 802.11 only 
> therefore a device id 
> >should not be a MAC, also a MAC has locally administered and 
> globally 
> >adminstered versions, you would probably want to restrict the use to 
> >the globally issued ones, then there are the privacy issues 
> since the 
> >MAC is used as a source address a attacker can presume if a EAP 
> >address that should be thought through before it is added; 
> especially 
> >if its not even common practice today which it doesnt apear to be.
> >
> Yet both IEEE 802.1AR and WiMAX documents talk about use of 
> MAC addresses in certificates (using different formats), so 
> it could be used more widely in the future.
> 
[Joe] IEEE802.1AR is going down a different path then using MAC address
in certificates.  I don't know about WiMAX.  

> I agree that using a locally administered MAC address as an 
> identity in EAP-TLS does not make sense.
> 

[Joe] What is the issue?

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 21 Feb 2007 09:57:57 -0800

>[Joe] What is the issue?

I'm not sure.  That's why I asked about text :)

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 21 Feb 2007 10:01:17 -0800

I beleive that 802.11AR still allows for the device ID to be a MAC address, atleast the last version I read did although they have gone from that being the ID to the ID being one that could be a MAC address.
 
I think the issue is the same one you have been calling out, if I have a device where should the device identity go.
 
And to that end, if that identity is a MAC address what are the security concerns.
 
Ryan

From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
Sent: Wed 2/21/2007 9:56 AM
To: Bernard Aboba; Ryan Hurst; [email-masked]
Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

[Joe] What is the issue?

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 21 Feb 2007 09:51:59 -0800

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Wed, 21 Feb 2007 11:57:35 -0800

In 802.11AR what comprises an identity is up to the manufacturer.  They
can put whatever they want in their as long as it is unique within their
namespace.  Right now it is unclear where the device identity will go.
Currently, if the identity is placed in the subject name  I don't think
it will use the email address RDN.  It is fairly common practice to use
CN and there is some existence of serialNumber since, as you pointed
out, CN may contain different less unique information.   I don't know of
any devices currently that place device identity in subjectAltName
fields. 
 
Off hand there may be some privacy concerns with using MAC address
(although this would probably be true of any "permanent" identifier).  I
don't think we want EAP-TLS to depend upon knowing about MAC addresses.
The security implications of MAC addresses will vary with deployment
scenarios.  I think these are largely out of scope for EAP-TLS.  
 
 Joe

	From: Ryan Hurst [mailto:[email-masked]] 
	Sent: Wednesday, February 21, 2007 10:01 AM
	To: Joseph Salowey (jsalowey); Bernard Aboba; [email-masked]
	Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

	I beleive that 802.11AR still allows for the device ID to be a
MAC address, atleast the last version I read did although they have gone
from that being the ID to the ID being one that could be a MAC address.
	 
	I think the issue is the same one you have been calling out, if
I have a device where should the device identity go.
	 
	And to that end, if that identity is a MAC address what are the
security concerns.
	 
	Ryan

	
	
	> it could be used more widely in the future.
	[Joe] IEEE802.1AR is going down a different path then using MAC
address
	in certificates.  I don't know about WiMAX. 

	[Joe] What is the issue?

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Wed, 21 Feb 2007 12:02:43 -0800

From: Ryan Hurst [mailto:[email-masked]] 
	Sent: Wednesday, February 21, 2007 9:15 AM
	To: Joseph Salowey (jsalowey); Bernard Aboba; [email-masked]
	Subject: RE: [Emu] RE: draft-simon-emu-rfc2716bis-07.txt

	in-line

	 

		>    field and the peer identity represents a user, then
the
		> subject name
		
		[Joe] Would you not have to do the same with email
address or CN?  It
		seems it would be possible for multiple of these to be
present.  There
		should not be any semantics associated with a serial
number other than
		it is an identifier.  It should not be interpreted as a
MAC address or
		some other value without additional knowledge outside
this
		specification.  I agree that this would not be the place
to consistently
		find a MAC address. I would prefer to keep Serial Number
as a
		possibility as it is at least as relevant as the other
fields.  I would
		be fine with the previous text I posted with a MAY.

		[rmh] Although your right that the fact that multiple
RDNs can be used to make up a DN universally other RDNs are
non-ambiguous while serialNumber conceptually is not, 

		[Joe] Can you expand upon this? Why is SerialNumber
different than other RDNs? 

		[rmh] Conceptually a serial number is a exact match to a
entity, for example no two tivos share the same serial number but they
could all share the same common name of Tivo Series 2. 

		[Joe] OK. 

		[rmh] In my case case there is a actor who also shares
the name Ryan Hurst (http://www.imdb.com/name/nm0403652/) but we both
have unique ssns.

		[Joe] OK 

		 [rmh] Since its CN is not intended to be non-ambiguous
its reasonable for me to have multiple CNs in a certificate all of which
are appropriate as a common name of me; for example I could have one
that is just Ryan, another that is Ryan Hurst, another that is Ryan M
Hurst.

		 [Joe] A device could be composed of multiple parts
(such as line cards) each with its own serial number.  There can also be
various formats and representations of a serial number.

		 [rmh]  Since a serial number is a exact match, what
does it mean if you have multiple serial numbers? 

		[Joe] I don't see any more confusion over having
multiple serial numbers than having multiples of any other attribute.  

		[rmh] As for the value, EAP is not 802.11 only therefore
a device id should not be a MAC, also a MAC has locally administered and
globally adminstered versions, you would probably want to restrict the
use to the globally issued ones, then there are the privacy issues since
the MAC is used as a source address a attacker can presume if a EAP
authentication is succesfull the MAC used in the source address was
authenticated. I think there are other issues related to it being a MAC
address that should be thought through before it is added; especially if
its not even common practice today which it doesnt apear to be.

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 21 Feb 2007 13:49:36 -0800

[rmh] The point I have been failing to make is that
these other ids are not expected to match a explicit entity, they are
really not much more than a friendly name therefore it's not as
important if you don't specify the semantics of how to process them.

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 21 Feb 2007 21:43:13 -0800

[Joe] I don't see any more confusion over having multiple serial numbers 
than having multiples of any other attribute.

Placing multiple identities into a peer certificate represents an assertion 
that the identities are equivalent.  If they are not equivalent, then they 
should be placed into separate certificates.  If the identities are 
equivalent, then you could put "[email-masked]"  and 
"[email-masked]" into a peer certificate,  and the server would be free 
to pick one (e.g. the first one), and use that to obtain the authorizations, 
assuming that the peer proved possession of the private key.

With a serial number or MAC address, I don't think this logic holds.  
Multiple serial numbers or MAC addresses are not equivalent.  For example, 
the server might take the first MAC address as the peer identity, but then 
it might expect this to match the Called-Station-Id attribute, and it won't, 
because that MAC address was the second one.  So the server may need to do 
something different, like check all of the potential identities.  That 
implies that identities really aren't equivalent, and probably belong in 
separate certificates.

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Thu, 22 Feb 2007 11:09:00 -0800

> Sent: Wednesday, February 21, 2007 9:43 PM
> To: [email-masked]
> [Joe] I don't see any more confusion over having multiple 
> serial numbers than having multiples of any other attribute.
> 
> Placing multiple identities into a peer certificate 
> represents an assertion that the identities are equivalent.  
> If they are not equivalent, then they should be placed into 
> separate certificates.  If the identities are equivalent, 
> then you could put "[email-masked]"  and 
> "[email-masked]" into a peer certificate,  and the server 
> would be free to pick one (e.g. the first one), and use that 
> to obtain the authorizations, assuming that the peer proved 
> possession of the private key.
> 
[Joe] I don't see why this doesn't hold for serial numbers as well.

> Multiple serial numbers or MAC addresses are not equivalent.  
> For example, the server might take the first MAC address as 
> the peer identity, but then it might expect this to match the 
> Called-Station-Id attribute, and it won't, because that MAC 
> address was the second one.  So the server may need to do 
> something different, like check all of the potential 
> identities.  That implies that identities really aren't 
> equivalent, and probably belong in separate certificates.
> 
[Joe] The same thing can happing with multiple CN or multiple email
addresses.  One of the values in the certificate may not match an
authorization entry while another one may.  Just to reiterate, I am not
suggesting that serial number have MAC address semantics.