Subject: [pkix] PKIX review on draft-ietf-hip-cert-11

From: Samu Varjonen <[email-masked]>
Date: Wed, 09 Mar 2011 14:26:59 +0200

Hi,

We, the authors of the HIP certificate document, sincerely ask the PKIX to 
review draft-ietf-hip-cert-11 as we believe that the PKIX group is the adequate 
group within the IETF to provide valuable feedback on the document.

http://tools.ietf.org/html/draft-ietf-hip-cert-11

The document is currently on the IESG agenda.

BR,
Samu and Tobias

---

From: Tom Gindin <[email-masked]>
Date: Wed, 9 Mar 2011 09:31:42 -0500

Samu:

        The wording of the last paragraph of section 2 should probably 
start "Distinguished name (DN) encodings (7 and 8) are represented by the 
string representation of the certificate's subject DN as defined ...". 
However, the use of such a name requires caution.  This group stated in 
RFC 5280, section 4.1.2.6, that the "DN MUST be unique for each subject 
entity certified by the one CA as defined by the issuer field" and that a 
CA "MAY issue more than one certificate with the same DN to the same 
subject entity".  Thus, the subject DN does NOT uniquely identify a 
subject across CA's, let alone a certificate.  It doesn't even uniquely 
identify a certificate within a CA.  This wording has changed in only 
trivial ways since RFC 2459, twelve years ago.
        Also, I don't actually see the encoding corresponding to "Hash and 
URL" in RFC 5996 section 3.6, which may be my fault.  I realize that the 
data consists of the 20-byte SHA-1 digest in binary (of either Certificate 
or CertificateBundle in DER), followed by the URL, but I'm not sure 
whether there's any framing of these two components or if the payload 
consists of 20 bytes of binary followed by the first character of the URL.

                Tom Gindin

From:
Samu Varjonen <[email-masked]>
To:
pkix <[email-masked]>
Date:
03/09/2011 07:27 AM
Subject:
[pkix] PKIX review on draft-ietf-hip-cert-11
Sent by:
[email-masked]

Hi,

review draft-ietf-hip-cert-11 as we believe that the PKIX group is the 
adequate 
group within the IETF to provide valuable feedback on the document.

BR,
Samu and Tobias
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 09 Mar 2011 14:39:07 -0500

On 03/09/2011 09:31 AM, Tom Gindin wrote:

This group stated in
subject across CA's, let alone a certificate.

This is a misrepresentation of what RFC 5280 says.  As Section 3.1 of
RFC 5280 says "certificates ... are data structures that bind public
key values to subjects."  The subjects in certificates are identified
by name (in the subject field and/or the subjectAltName extension).  If
different entities in a PKI may have the same name, then what meaning
do the names in the certificates have, and in what way do certificates
"bind" public key values to subjects?

PKIX even has an attribute certificate profile (RFC 5755) that
recommends identifying the holder of the attribute certificate by
providing the issuer name and serial number of the holder's public key
certificate.  So, if an issuer name did not unambiguously identify a
single CA within a PKI there would be ambiguity as to which entity was
being specified in an attribute certificate.

As to the specific text in RFC 5280, the following appears in the
Security Considerations section:

While X.509 mandates that names be unambiguous, there is a risk that

two unrelated authorities will issue certificates and/or CRLs under

the same issuer name.  As a means of reducing problems and security

issues related to issuer name collisions, CA and CRL issuer names

SHOULD be formed in a way that reduces the likelihood of name

collisions.  Implementers should take into account the possible

existence of multiple unrelated CAs and CRL issuers with the same

name.  At a minimum, implementations validating CRLs MUST ensure that

the certification path of a certificate and the CRL issuer

certification path used to validate the certificate terminate at the

same trust anchor.

Below is some text from  X.509 and X.501 (DNs are defined in X.501)
that notes the requirement for names to unambiguously identify a single
entity.

So, while it is true that a DN does not identify a single certificate,
since more than one certificate may be issued to the same entity, there
is a requirement for a DN to unambiguously identify a single entity
across CAs.  [Some people may claim that while X.509 requires names to
be unambiguous, things don't work that way in practice.  However, this
is an incorrect statement based on a theoretical concern about the
possibility of name "collisions", as no one has been able to show an
example of two different CAs (actual CAs in production use that issue
certificates that are trusted by real relying parties) that issue
certificates under the same name.  In practice, even though there is no
central naming authority, CAs use DNs that identity themselves and
their subjects in meaningful ways, and using naming schemes that do not
result in the creation of name "collisions".  This is fortunately,
since X.509 was designed based on an assumption that names are
unambiguous and so if name "collisions" did exist they would cause real
problems.]

Dave

----------------------------------------------------------------------

X.501 says:

9.1.4 (directory) name: A construct that
singles out a particular
object from all other objects. A name shall be unambiguous (that is,
denote just one object); however, it need not be unique (that is, be
the only name which unambiguously denotes the object).

9.1.5 (entry) name: A construct that singles out a particular
entry from all other entries.

9.2 Names in general

A (directory) name is a construct that identifies a particular
object from among the set of all objects. A name shall be unambiguous,
that is, denotes just one object.

An object can be assigned a distinguished name without being
represented by an entry in the Directory, but this name is then the
name its object entry would have had were it represented in the
Directory.

and X.509 says:

NOTE 1 – Although the CAs are unambiguously
defined by a distinguished name in the DIT, this does not imply that
there is any relationship between the organization of the CAs and the
DIT.

For every name form used in the GeneralName type, there shall
be a name
registration system that ensures that any name used unambiguously
identifies one entity to both certificate issuer and certificate users.

---

From: "Denis Pinkas"<[email-masked]>
Date: Wed, 9 Mar 2011 22:51:38 +0100

Dave,
RFC 5280 states: "the DN MUST be unique for each subject entity certified by the one CA". 
This means that two CAs can choose the same subject DN, while each one denotes a different entity.
You wrote: "there is a requirement for a DN to unambiguously identify a single entity across CAs".
I disagree. 
A distinguished name in the DIT may have this property, but not a DN in general, for example,
when it is a subject DN which may be build with any set attributes as long as at the end the DN is unique.
In practice, name collisions for CAs have not been observed (yet), but may happen for end-users (i.e. human beings). 
Denis
----- Message reçu ----- 
De : pkix-bounces 
À : Samu Varjonen 
Date : 2011-03-09, 20:39:07
Sujet : Re: [pkix] PKIX review on draft-ietf-hip-cert-11

This is a misrepresentation of what RFC 5280 says.  As Section 3.1 of RFC 5280 says "certificates ... are data structures that bind public key values to subjects."  The subjects in certificates are identified by name (in the subject field and/or the subjectAltName extension).  If different entities in a PKI may have the same name, then what meaning do the names in the certificates have, and in what way do certificates "bind" public key values to subjects?

PKIX even has an attribute certificate profile (RFC 5755) that recommends identifying the holder of the attribute certificate by providing the issuer name and serial number of the holder's public key certificate.  So, if an issuer name did not unambiguously identify a single CA within a PKI there would be ambiguity as to which entity was being specified in an attribute certificate.

As to the specific text in RFC 5280, the following appears in the Security Considerations section:

Below is some text from  X.509 and X.501 (DNs are defined in X.501) that notes the requirement for names to unambiguously identify a single entity.

So, while it is true that a DN does not identify a single certificate, since more than one certificate may be issued to the same entity, there is a requirement for a DN to unambiguously identify a single entity across CAs.  [Some people may claim that while X.509 requires names to be unambiguous, things don't work that way in practice.  However, this is an incorrect statement based on a theoretical concern about the possibility of name "collisions", as no one has been able to show an example of two different CAs (actual CAs in production use that issue certificates that are trusted by real relying parties) that issue certificates under the same name.  In practice, even though there is no central naming authority, CAs use DNs that identity themselves and their subjects in meaningful ways, and using naming schemes that do not result in the creation of name "collisions".  This is fortunately, since X.509 was designed based on an assumption that names are unambiguous and so if name "collisions" did exist they would cause real problems.]

Dave

9.1.4 (directory) name: A construct that singles out a particular object from all other objects. A name shall be unambiguous (that is, denote just one object); however, it need not be unique (that is, be the only name which unambiguously denotes the object).

9.1.5 (entry) name: A construct that singles out a particular entry from all other entries.

9.2 Names in general

A (directory) name is a construct that identifies a particular object from among the set of all objects. A name shall be unambiguous, that is, denotes just one object.

An object can be assigned a distinguished name without being represented by an entry in the Directory, but this name is then the name its object entry would have had were it represented in the Directory.

and X.509 says:

NOTE 1 – Although the CAs are unambiguously defined by a distinguished name in the DIT, this does not imply that there is any relationship between the organization of the CAs and the DIT.

For every name form used in the GeneralName type, there shall be a name registration system that ensures that any name used unambiguously identifies one entity to both certificate issuer and certificate users.

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 09 Mar 2011 17:12:54 -0500

Denis,

You are merely quoting one sentence in RFC 5280 that does not impose a
requirement for names to be unambiguous and then incorrectly claiming
that this proves that there is no such requirement.  I have provided
quotes from both RFC 5280 and from X.501 and X.509 that clearly
demonstrate that two different CAs cannot legitimately assign the same
subject DN to different entities.  You have also been told countless
times over the course of many years by the people who developed these
standards that the names must be unambiguous across the entire PKI, not
just with respect to the certificates issued by a single CA.

If you are going to continue to insist that the only requirement is
that a single CA cannot issue certificates with the same subject DN to
two different entities (and by implication that the people who wrote
X.509 fundamentally misunderstand the text they that themselves wrote),
then you need to specific text from these documents that supports your
assertion.  Below you simply make assertions about what the standards
say without quoting text to support your claims.  Other times you have
said that the text in the standard needs to be "interpreted" in a
certain way because it doesn't really mean what it says.  So, if I am
wrong, please quote specific text from the standards that clearly
supports your claims.

Dave

On 03/09/2011 04:51 PM, Denis Pinkas wrote:

Dave,

RFC 5280 states: "the DN MUST be unique for each subject entity
certified by the one CA".

This means that two CAs can choose the same subject DN, while each
one denotes a different entity.

You wrote: "there is a requirement for a DN to unambiguously
identify a single entity across CAs".

I disagree.

A distinguished name in the DIT may have this property,
but not a DN in general, for example,

when it is a subject DN which may be build with any set attributes as
long as at the end the DN is unique.

In practice, name collisions for CAs have not been observed (yet),
but may happen for end-users (i.e. human beings).

Denis

----- Message reçu -----

De
: pkix-bounces

À
: Samu
Varjonen

Date
: 2011-03-09, 20:39:07

Sujet
: Re: [pkix] PKIX review on draft-ietf-hip-cert-11

This group stated in

same trust anchor.

Dave

X.501 says:

9.1.4 (directory) name: A construct
that singles out a particular object from all other objects. A name
shall be unambiguous (that is, denote just one object); however, it
need not be unique (that is, be the only name which unambiguously
denotes the object).

9.1.5 (entry) name: A construct that singles out a
particular entry from all other entries.

9.2 Names in general

and X.509 says:

For every name form used in the GeneralName type, there shall
be a name registration system that ensures that any name used
unambiguously identifies one entity to both certificate issuer and
certificate users.

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 9 Mar 2011 17:45:23 -0500

David,

The name of X.509 is "Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks" - the key element being "The Directory".

If there were a global directory that all X.509 CAs were a part of, there would be a mechanism to ensure global uniqueness.

In the absence of a global directory, if every X.509 CA in the world assigned subject names in a manner that allowed name constraints to be consistently applied, there would be a mechanism to ensure global uniqueness.

In the absence of either a Directory or prefix coordination, all we have left are unenforceable requirements.  When "the people who developed these standards [say] that the names must be unambiguous across the entire PKI", what they mean is that the standards were defined *assuming* global uniqueness (i.e., in the context of The Directory), and were therefore designed without mechanisms to deal with cases when that assumption is violated either unintentionally or deliberately.

Personally, I would prefer failsafe mechanisms to deal with potential non-uniqueness, just as I prefer my hair dryer to have a GFI even though there is a requirement not to use it in water.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David A. Cooper
Sent: Wednesday, March 09, 2011 5:13 PM
To: [email-masked]
Cc: pkix
Subject: Re: [pkix] PKIX review on draft-ietf-hip-cert-11

Denis,

You are merely quoting one sentence in RFC 5280 that does not impose a requirement for names to be unambiguous and then incorrectly claiming that this proves that there is no such requirement.  I have provided quotes from both RFC 5280 and from X.501 and X.509 that clearly demonstrate that two different CAs cannot legitimately assign the same subject DN to different entities.  You have also been told countless times over the course of many years by the people who developed these standards that the names must be unambiguous across the entire PKI, not just with respect to the certificates issued by a single CA.

If you are going to continue to insist that the only requirement is that a single CA cannot issue certificates with the same subject DN to two different entities (and by implication that the people who wrote X.509 fundamentally misunderstand the text they that themselves wrote), then you need to specific text from these documents that supports your assertion.  Below you simply make assertions about what the standards say without quoting text to support your claims.  Other times you have said that the text in the standard needs to be "interpreted" in a certain way because it doesn't really mean what it says.  So, if I am wrong, please quote specific text from the standards that clearly supports your claims.

Dave

	Dave,

	I disagree. 

	Denis

	----- Message reçu ----- 

		De : pkix-bounces 
		À : Samu Varjonen 

			This group stated in 

		

		
		
		Dave

			
			
			9.2 Names in general

		and X.509 says:

			NOTE 1 - Although the CAs are unambiguously defined by a distinguished name in the DIT, this does not imply that there is any relationship between the organization of the CAs and the DIT.

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 10 Mar 2011 09:20:50 +0100

Dave,

You are omitting a fundamental point. 
X.509 is part of the X.500 series of documents and was a solution designed to bring a security 
to the Directory (with a capital D) better than IDs and passwords.

Basically your assertion is true as long as X.509 is used in the context of a DIT.

However, many people found X.509 useful outside of the context of the DIT.

X.500 as a whole has not been very successful, but X.509 has been successful.

PKIX is using X.509 outside the context of the DIT. The uniqueness of the DIT structure does not apply anymore, 
hence why I am keeping the same language. 

If you are still inconvinced take a look at RFC 3739 section 2.4.
 
2.4.  Uniqueness of names
 
   Distinguished name is originally defined in X.501 [X.501] as a
   representation of a directory name, defined as a construct that
   identifies a particular object from among a set of all objects.  The
   distinguished name MUST be unique for each subject entity certified
   by the one CA as defined by the issuer name field, for the whole life
   time of the CA.

Denis
----- Message reçu ----- 
De : pkix-bounces 
À : [email-masked] 
Date : 2011-03-09, 23:12:54
Sujet : Re: [pkix] PKIX review on draft-ietf-hip-cert-11

Denis,

Dave

----- Message reçu ----- 
De : pkix-bounces 
À : Samu Varjonen 
Date : 2011-03-09, 20:39:07
Sujet : Re: [pkix] PKIX review on draft-ietf-hip-cert-11

Dave

9.2 Names in general

and X.509 says:

---

From: Tom Gindin <[email-masked]>
Date: Thu, 10 Mar 2011 08:41:27 -0500

Dave:

        The RFC 5280 text you cited declares that issuer names (not all 
subject names) must be globally unique.  I am not sure whether the text 
from X.509, in particular the phrase "under the same name", refers to 
subjects or to issuers.  Nothing I said suggested that issuer names would 
fail to be globally unique, simply that two separately operated issuers 
with distinct names might separately issue certificates with the same DN 
to two distinct entities.
        To answer Dave Kemp's point, there are two widely used mechanisms 
which seem to make most certificate DN's unique.  The first is the use of 
organization specifications which are unique to the issuer, and the second 
is the use of a globally unique address such as a DNSName or an e-mail 
address as the value of an attribute within the DN.  I will concede that 
those commercial certificates I have found in a brief search which use the 
subject's own organization rather than the CA's are server certificates in 
which the CN attribute is globally unique.  Collisions would become likely 
if two issuers used Residential Person DN's without a streetAddress, which 
I would regard as a bad practice but is permitted by X.521.  Any 
commercial issuer who used a subject's employer as organization and a 
personal CN would also run this risk.  Does anyone have examples of 
certificates from commercial CA's with either a residential DN with no 
streetAddress, or an organizational DN with a person's CN and a value in 
the organization field specified by the subject rather than by the issuer?

        In any case, my other reason for criticizing the use of subject DN 
as a certificate identifier was that a subject DN does not uniquely 
identify a certificate.  The X.509 citation you gave says that it doesn't 
do so.

                Tom Gindin

From:
"David A. Cooper" <[email-masked]>
To:
Samu Varjonen <[email-masked]>
Cc:
pkix <[email-masked]>
Date:
03/09/2011 02:39 PM
Subject:
Re: [pkix] PKIX review on draft-ietf-hip-cert-11
Sent by:
[email-masked]

This is a misrepresentation of what RFC 5280 says.  As Section 3.1 of RFC 
5280 says "certificates ... are data structures that bind public key 
values to subjects."  The subjects in certificates are identified by name 
(in the subject field and/or the subjectAltName extension).  If different 
entities in a PKI may have the same name, then what meaning do the names 
in the certificates have, and in what way do certificates "bind" public 
key values to subjects?

PKIX even has an attribute certificate profile (RFC 5755) that recommends 
identifying the holder of the attribute certificate by providing the 
issuer name and serial number of the holder's public key certificate.  So, 
if an issuer name did not unambiguously identify a single CA within a PKI 
there would be ambiguity as to which entity was being specified in an 
attribute certificate.

As to the specific text in RFC 5280, the following appears in the Security 
Considerations section:

Below is some text from  X.509 and X.501 (DNs are defined in X.501) that 
notes the requirement for names to unambiguously identify a single entity.

So, while it is true that a DN does not identify a single certificate, 
since more than one certificate may be issued to the same entity, there is 
a requirement for a DN to unambiguously identify a single entity across 
CAs.  [Some people may claim that while X.509 requires names to be 
unambiguous, things don't work that way in practice.  However, this is an 
incorrect statement based on a theoretical concern about the possibility 
of name "collisions", as no one has been able to show an example of two 
different CAs (actual CAs in production use that issue certificates that 
are trusted by real relying parties) that issue certificates under the 
same name.  In practice, even though there is no central naming authority, 
CAs use DNs that identity themselves and their subjects in meaningful 
ways, and using naming schemes that do not result in the creation of name 
"collisions".  This is fortunately, since X.509 was designed based on an 
assumption that names are unambiguous and so if name "collisions" did 
exist they would cause real problems.]

Dave

----------------------------------------------------------------------
X.501 says:
9.1.4 (directory) name: A construct that singles out a particular object 
from all other objects. A name shall be unambiguous (that is, denote just 
one object); however, it need not be unique (that is, be the only name 
which unambiguously denotes the object).

9.1.5 (entry) name: A construct that singles out a particular entry from 
all other entries.

9.2 Names in general

A (directory) name is a construct that identifies a particular object from 
among the set of all objects. A name shall be unambiguous, that is, 
denotes just one object.

An object can be assigned a distinguished name without being represented 
by an entry in the Directory, but this name is then the name its object 
entry would have had were it represented in the Directory.

and X.509 says:
NOTE 1 ? Although the CAs are unambiguously defined by a distinguished 
name in the DIT, this does not imply that there is any relationship 
between the organization of the CAs and the DIT.

For every name form used in the GeneralName type, there shall be a name

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 10 Mar 2011 08:52:34 -0500

Denis,

X.501 is pretty clear on this:

An object can be assigned a distinguished name
without being represented by an entry in the Directory, but this name
is then the name its object entry would have had were it represented in
the Directory.

There is nothing in X.501 or X.509 that says that the requirement for
names to be unambiguous only applies if a Directory is present.

And yes, even without a Directory, people have found X.509 useful as a
means of binding public keys to identities.  But they have found it
useful in an environment in which names are unambiguous.  If names were
ambiguous, then what would be the point of the PKI?

If PKIX was designed based on an assumption that names may be
ambiguous, then why does RFC 5755 recommend identifying the holder of
an attribute certificate using the issuer name and serial number of the
holder's public key certificate (a method that would not work if names
were ambiguous) rather than recommending that the holder be identified
by the hash of the holder's public key?

Dave

On 03/10/2011 03:20 AM, Denis Pinkas wrote:

Dave,

X.509 is part of the X.500 series of documents and was a solution
designed to bring a security

Basically your assertion is true as long as X.509 is used in the
context of a DIT.

However, many people found X.509 useful outside of the context
of the DIT.

X.500 as a whole has not been very successful, but X.509 has
been successful.

PKIX is using X.509 outside the context of the DIT. The
uniqueness of the DIT structure does not apply anymore,

X.501 says:

9.1.4 (directory) name: A
construct that singles out a particular object from all other objects.
A name shall be unambiguous (that is, denote just one object); however,
it need not be unique (that is, be the only name which unambiguously
denotes the object).

9.2 Names in general

and X.509 says:

NOTE 1 – Although the CAs are
unambiguously defined by a distinguished name in the DIT, this does not
imply that there is any relationship between the organization of the
CAs and the DIT.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 10 Mar 2011 09:34:39 -0500

So are you saying that X.509 is fundamentally broken because it was 
designed based on an assumption (that names will be unambiguous) that 
you believe that may not hold in practice and was "designed without 
mechanisms to deal with cases when that assumption is violated either 
unintentionally or deliberately"?  If that were the case, then the 
solution wouldn't be to continue to use X.509 as it is currently 
designed but without imposing a name uniqueness requirement, the 
solution would be to develop a new standard for PKI that does not rely 
on this assumption.

It is not clear to me what the purpose of such a PKI would be.  If names 
are unambiguous, then what useful information do I get from the PKI?  If 
more than one subject in a PKI may be assigned the same name then I 
can't use the names in certificates as the basis for making 
authorization decisions.  Do I then have to make authorization decisions 
based on the key (and then update all of my access control lists 
whenever the subject is issued a new certificate with a new key?  There 
are already PKIs developed around the idea that "the key is the name" 
and they are not widely used.

In the meantime, the purpose of the PKIX working group was established 
to develop "Internet standards to support X.509-based Public Key 
Infrastructures (PKIs)" and to "track the evolution of ITU-T X.509 
documents, and [to] maintain compatibility between these documents and 
IETF PKI standards".

I think a more appropriate analogy would be a car.  Over the years many 
safety features have been added to cars (seat belts, airbags, anti-lock 
brakes, etc.) that help to reduce the risk of injury in the case of a 
crash, and I don't think anyone would argue that this is a bad thing to 
do.  But, no matter how many safety features are added to the cars, we 
still don't tell people that there is no longer a requirement to avoid 
driving into walls or into other cars.

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 10 Mar 2011 18:07:48 +0100

David,

It is surprising that you are omitting to mention your own original request which was:
"So, if I am wrong, please quote specific text from the standards that clearly supports your claims".

It is quite surprising that you are quoting my text but with a deliberate truncation. 
So I re-establish the text below:

"If you are still inconvinced take a look at RFC 3739 section 2.4.
 
2.4.  Uniqueness of names
 
   time of the CA."

You got the specific text. If I understand you correctly, you disagree with RFC 3739.
Sorry, but RFC 3739 has been adopted by the PKIX WG and you were a member of it at this time.

Now, your arguments are perfectly valid as long as you only use X.509 in the context of the Directory.
The PKIX WG does not address that specific case.

Denis

----- Message reçu ----- 
De : David A. Cooper 
À : [email-masked] 
Date : 2011-03-10, 14:52:34
Sujet : Re: [pkix] PKIX review on draft-ietf-hip-cert-11

Denis,

There is nothing in X.501 or X.509 that says that the requirement for names to be unambiguous only applies if a Directory is present.

And yes, even without a Directory, people have found X.509 useful as a means of binding public keys to identities.  But they have found it useful in an environment in which names are unambiguous.  If names were ambiguous, then what would be the point of the PKI?

If PKIX was designed based on an assumption that names may be ambiguous, then why does RFC 5755 recommend identifying the holder of an attribute certificate using the issuer name and serial number of the holder's public key certificate (a method that would not work if names were ambiguous) rather than recommending that the holder be identified by the hash of the holder's public key?

Dave

9.2 Names in general

and X.509 says:

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 10 Mar 2011 13:54:31 -0500

Denis,

Nowhere in the text that you quoted does it state that different CAs
may issue certificates with the same subject name to different entities.

Nowhere is it stated that the requirement for names to be unambiguous
only applies in the context of the Directory.  In fact, X.501 and X.509
clearly state otherwise.

The charter for the PKIX WG states that "PKIX will continue to track
the evolution of ITU-T X.509 documents, and will maintain compatibility
between these documents and IETF PKI standards".  X.509 requires names
to be unambiguous, whether or not there is a Directory.  Thus PKIX
would not be maintaining compatibility with X.509 if it said that names
did not have to be unambiguous.

On 03/10/2011 12:07 PM, Denis Pinkas wrote:

David,

It is surprising that you are omitting to mention your own
original request which was:

"So, if I am wrong, please quote specific text from the
standards that clearly supports your claims".

It is quite surprising that you are quoting my text but with a
deliberate truncation.

"If you are still inconvinced take a look at RFC 3739 section
2.4.

2.4.  Uniqueness of names

Distinguished name is originally defined in X.501 [X.501]
as a

representation
of a directory name, defined as a construct that

identifies
a particular object from among a set of all objects.  The

distinguished
name MUST be unique for each subject entity certified

by the
one CA as defined by the issuer name field, for the whole life

time
of the CA."

You got the specific text. If I understand you correctly, you
disagree with RFC 3739.

Sorry, but RFC 3739 has been adopted by the PKIX WG and you were a
member of it at this time.

Now, your arguments are perfectly valid as long as you only use
X.509 in the context of the Directory.

Denis

-----
Message reçu -----

De
: David
A. Cooper

À
: [email-masked]

Date
: 2011-03-10, 14:52:34

Sujet

Denis,

An object can be assigned a distinguished
name without being represented by an entry in the Directory, but this
name is then the name its object entry would have had were it
represented in the Directory.

Dave

Dave,

Basically your assertion is true as long as X.509 is used in
the context of a DIT.

However, many people found X.509 useful outside of the
context of the DIT.

X.501 says:

9.2 Names in general

and X.509 says:

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 10 Mar 2011 14:42:26 -0500

I am not saying that there should be no MUST requirement for end entity
names to be globally unique.  But even though there is such a
requirement, (just as there is a mandatory legal requirement not to
crash your car into someone else's), sometimes stuff happens.  So given
a choice such as identifying certs by subject name or by issuer/serial,
I would rather use the method least susceptible to subject name
collisions.
  
Since you mention key-based naming, constraining an authority's range of
action does not require abandoning an authority-based PKI.  Just off the
top of my head, a CA could create an "EE-signed" cert binding the EE
key-name to an authority, then destroy the private key so the EE name
never has to change.  Nothing about PKIX path validation would change
except an additional step to ensure that the path to that EE name goes
through the specified authority.  And no other part of the global PKI
could ever steal or collide with that name.

The public Internet is used by "us" and "them" (for any value of "us"),
and although I can assume that my part of the PKI is perfect, I'm not
willing make the same assumption about everyone else.  PKIX should allow
us to talk to strangers without requiring us to unquestioningly accept
what they say.

Dave

-----Original Message-----
From: David A. Cooper [mailto:[email-masked]] 
Sent: Thursday, March 10, 2011 9:35 AM
To: Kemp, David P.
Cc: pkix
Subject: Re: [pkix] PKIX review on draft-ietf-hip-cert-11

On 03/09/2011 05:45 PM, Kemp, David P. wrote:
> David,
>
> The name of X.509 is "Information technology - Open Systems
Interconnection - The Directory: Public-key and attribute certificate
frameworks" - the key element being "The Directory".
>
> If there were a global directory that all X.509 CAs were a part of,
there would be a mechanism to ensure global uniqueness.
>
> In the absence of a global directory, if every X.509 CA in the world
assigned subject names in a manner that allowed name constraints to be
consistently applied, there would be a mechanism to ensure global
uniqueness.
>
> In the absence of either a Directory or prefix coordination, all we
have left are unenforceable requirements.  When "the people who
developed these standards [say] that the names must be unambiguous
across the entire PKI", what they mean is that the standards were
defined *assuming* global uniqueness (i.e., in the context of The
Directory), and were therefore designed without mechanisms to deal with
cases when that assumption is violated either unintentionally or
deliberately.
>
> Personally, I would prefer failsafe mechanisms to deal with potential
non-uniqueness, just as I prefer my hair dryer to have a GFI even though
there is a requirement not to use it in water.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 10 Mar 2011 16:00:49 -0500

> solution would be to develop a new standard for PKI that does not rely 

X.500 is fundamentally broken because it was designed without taking into account the political reality that "One DIT to Rule Them All" wasn't every going to happen.

X.509 can function just fine without it X.500--so long as any given PKI maintains uniqueness of names within that PKI's scope *and* understands that name collisions *between PKIs* is a risk to be mitigated (through, e.g., Name Constraints when using cross-certification or through trust anchor management when not).

If you *really* want uniqueness, you already have it:  The public key itself is globally unique (for all practical purposes).

-- Tim

---

From: "Ed Gerck, Ph.D." <[email-masked]>
Date: Thu, 10 Mar 2011 13:01:51 -0800

David C. and all,

Even though X.509 requires names to be unambiguous, whether or not there is a 
Directory, it does not provide a way to do so. Further, there are many reasons 
why compliant CAs may collectively (although not individually)  violate this 
rule (*).

Thus, this is a critical, sine qua non functionality where X.509 falls short.  
Hence, PKIX also falls short (even though,  PKIX could address this issue as 
long as it does not conflict with X.509) .

And that is, as I see it, the basis for the good points that Denis and Dave K. 
are mentioning. It will not happen by magic.

Cheers,
Ed Gerck

(*)  I think we all agree that different CAs are independent entities under 
ITU-T X.509. And that there is no global RA (or Directory) that different CAs 
MUST  (or even MAY) comply with, or consult,  for anything, before issuing a 
certificate. Also, a CA's CPS is out of scope of X.509.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 10 Mar 2011 16:07:03 -0500

On Mar 10, 2011, at 3:01 PM, Ed Gerck, Ph.D. wrote:

> Directory, it does not provide a way to do so.

Between PKIs, of course not, but so long as this is understood there's no concern.

Within a PKI, this is an issuance requirement, and therefore an issue for the CP and/or CPS, not the standard.

-- T

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 10 Mar 2011 13:32:21 -0800

I hope nobody takes this personally, but I find it very disheartening that there is so much disagreement among presumed experts about the degree of uniqueness of EE certs.  

Does this argue for the creation of a document to resolve the issue?  (I'm not volunteering!)  Is it be possible to articulate a simple set of rules that are "safe" in the sense that a cert which is unique according to those rules is actually guaranteed to be unique?

I do have an ulterior motive.  A certain major vendor's smart card support identifies the user account for a card based solely on the subject key identifier, and whether the cert can be validated against one of the ~100 well known CAs.  I would like to augment my bug report with something much more explicit and authoritative than the RFC 5280 references which I used.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 10 Mar 2011 13:35:28 -0800

> Within a PKI, this is an issuance requirement, and therefore an issue for the CP and/or CPS, not the standard.

and presumably easy to enforce.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Mar 2011 21:43:29 +0000

> I hope nobody takes this personally, but I find it very disheartening that there is so much disagreement among presumed experts about the degree of uniqueness of EE certs.

I doubt anyone will take it personally since its an argument
that's been had (pointlessly, basically) quite a few times.
It'll fizzle in a bit.

I wonder are the hip folks finding it very helpful;-)

S.

---

From: "Denis Pinkas"<[email-masked]>
Date: Thu, 10 Mar 2011 23:03:20 +0100

David,

Please read again the sentence: 

The distinguished name MUST be unique for each subject entity certified
by the one CA as defined by the issuer name field, for the whole life
time of the CA."

The sentence does not say: 

"The distinguished name MUST be unique for each subject entity certified
by any CA over the world as defined by the issuer name field, for the whole life
time of the CA."
 
Then look again at RFC 3739 and you will see that any subset of attributes ansd values as indicated 
in 3.1.1 and in 3.1.2 is appropriate. This subset is unable to support DN uniqueness.

Note: RFC 3739 (as well as all other RFCs from the PKIX WG) does not address the use of X.509 certificates with the Directory.

Denis

----- Message reçu ----- 
De : David A. Cooper 
À : [email-masked] 
Date : 2011-03-10, 19:54:31
Sujet : Re: [pkix] PKIX review on draft-ietf-hip-cert-11

Denis,

Nowhere in the text that you quoted does it state that different CAs may issue certificates with the same subject name to different entities.

Nowhere is it stated that the requirement for names to be unambiguous only applies in the context of the Directory.  In fact, X.501 and X.509 clearly state otherwise.

The charter for the PKIX WG states that "PKIX will continue to track the evolution of ITU-T X.509 documents, and will maintain compatibility between these documents and IETF PKI standards".  X.509 requires names to be unambiguous, whether or not there is a Directory.  Thus PKIX would not be maintaining compatibility with X.509 if it said that names did not have to be unambiguous.

2.4.  Uniqueness of names

Denis

----- Message reçu ----- 
De : David A. Cooper 
À : [email-masked] 
Date : 2011-03-10, 14:52:34
Sujet : Re: [pkix] PKIX review on draft-ietf-hip-cert-11

Denis,

Dave

9.2 Names in general

and X.509 says:

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 10 Mar 2011 17:08:19 -0500

On 03/10/2011 04:32 PM, Henry B. Hotz wrote:
> A certain major vendor's smart card support identifies the user account for a card based solely on the subject key identifier

Are you sure it is the subject key identifier and not a name in the 
subjectAltName extension?  There is no requirement that the subject key 
identifier unambiguously identity a subject or a key.  X.509 only 
requires that "A key identifier shall be unique with respect to all key 
identifiers for the subject with which it is used."  RFC 5280 simply 
says that the key identifier SHOULD be derived using a method that 
generates unique values.  (Granted, the most common method for 
generating key identifiers is to use the SHA-1 hash of the key, which 
should ensure globally unique values.)

> and whether the cert can be validated against one of the ~100 well known CAs.  I would like to augment my bug report with something much more explicit and authoritative than the RFC 5280 references which I used.
>    

Assuming that the identification is based on a name in the 
subjectAltName extension, I believe this is the real problem.  Do you 
really trust every one of those ~100 well known CAs to the users who 
have accounts on your system?  The system should allow you to configure 
the set of CAs that you trust for this purpose.

---

From: Sean Turner <[email-masked]>
Date: Thu, 10 Mar 2011 18:42:18 -0500

> trivial ways since RFC 2459, twelve years ago.

I think the suggested change to disambiguate which DN is used is a good 
suggestion.  As to the concerns about using DNs, this draft normatively 
points to 5280 for structure and for security considerations so I think 
there's nothing new that needs to be added about that in this draft.

> consists of 20 bytes of binary followed by the first character of the URL.

I think the hip folks are just going to take whatever they get from 
their IKEv2 stack.  I'll check with the IPsec folks to make sure it's 
clear what the format is, but checking with them shouldn't hold up 
progressing this draft.

spt

>                  Tom Gindin
>
>
>
> From:
> Samu Varjonen<[email-masked]>
> To:
> pkix<[email-masked]>
> Date:
> 03/09/2011 07:27 AM
> Subject:

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 10 Mar 2011 15:48:51 -0800

> should ensure globally unique values.)

Yes, I'm sure.  That's why it's a bug.

> the set of CAs that you trust for this purpose.

I'm told they were shown a demonstration of the "wrong-CA" issue.  If they provided a way to restrict the CAs allowed for login, that would be an enormous improvement.

Don't shoot the messenger.  ;-)  (I really hope there is someone from that vender reading this list and that they are suitably embarrassed.)

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Mar 2011 19:51:38 -0500

At 1:32 PM -0800 3/10/11, Henry B. Hotz wrote:
>I hope nobody takes this personally, but I find it very 
>disheartening that there is so much disagreement among presumed 
>experts about the degree of uniqueness of EE certs.

There is not widespread disagreement on this topic. It's just David :-).

>Does this argue for the creation of a document to resolve the issue? 
>(I'm not volunteering!)  Is it be possible to articulate a simple 
>set of rules that are "safe" in the sense that a cert which is 
>unique according to those rules is actually guaranteed to be unique?

It calls for an errata that explains why RPs ought not rely on global 
name uniqueness, as a practical security matter.  We've discussed 
this with David, perviously, when he began objecting to the fact that 
the RPKI explicitly notes that global name uniqueness ought not be 
relied upon.

>I do have an ulterior motive.  A certain major vendor's smart card 
>support identifies the user account for a card based solely on the 
>subject key identifier, and whether the cert can be validated 
>against one of the ~100 well known CAs.  I would like to augment my 
>bug report with something much more explicit and authoritative than 
>the RFC 5280 references which I used.

I'm not sure this discussion is relevant to the issue you cite. if the SKI is
a (hash) function of the public key associated with the subject, it 
is not likely to result in an accidental collision. A CA could issue 
a cert to another entity with the same SKI and public key, but that 
entity would not know the private key, unless there was collusion or 
a security breach, or a procedural failure (e.g., no PoP).  Of 
course, if the SKI is not a hash, this is completely broken!

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Mar 2011 19:56:55 -0500

David,

I have refrained from entering this discussion, but ...

There is no indication that one can associate a globally unique name
that is also globally meaningful for an entity, irrespective of X.509
DNs. I refer you to an NRC report on this general topic:

"Who Goes there? Authentication Through the Lens of Privacy," Edited 
by Stephen Kent and Lynette Millet, Committee on Authentication 
Technologies and Their Privacy Implications of the Computer Science 
and Telecommunications Board of the National Research Council, 
published by National Academy Press,  September, 2003.

As others have noted, X.509 should be interpreted in the context in which it
was developed, i.e., the X.500 directory model, the DIT, etc. To ignore this
context is inappropriate.

Steve

---

From: "Henry B. Hotz" <[email-masked]>
Date: Thu, 10 Mar 2011 17:13:30 -0800

> the RPKI explicitly notes that global name uniqueness ought not be 

'K

> course, if the SKI is not a hash, this is completely broken!

Not specifically relevant, no.  However I wish I could more specifically/authoritatively tell the vender what information they *should* use to uniquely identify users.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Mar 2011 20:18:40 -0500

Sean,

I agree that the WG comments on the HIP cert doc have gone astray.

Stefan noted issues re the name form specified and how this should
be represented in a cert. I think the questions he raised are still
relevant, and ought to be addressed.

The HIP cert doc calls for putting the HIT in a IAN and an SAN.  It 
is not clear why this is a good idea. The spec does not seem to 
explain why an issuer should be identified by an HIT. if there is no 
good reason for this, then it can go away, and avoid the need for an 
IAN extension in these certs.  It would make life simpler if the HIT 
appeared only in an EE cert, where the Subject Dn could be omitted, 
and the HIT be encoded as an IPv6 address SAN.

I wrote the PAD text for 4301 to address the question of where one
finds the name to use for SPD matching and IKE validation, because 
this topic was omitted in the first version of the specs.  I think it 
best if we provide some guidance here, re this issue, and stop 
discussing name uniqueness.

Steve

P.S.  It also would be nice if the doc was edited to reflect the fact that
a CA is a Certification Authority, not a Certificate Authority.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Mar 2011 20:46:40 -0500

At 5:13 PM -0800 3/10/11, Henry B. Hotz wrote:
>...
>Not specifically relevant, no.  However I wish I could more 
>specifically/authoritatively tell the vender what information they 
>*should* use to uniquely identify users.
>

The question of how to uniquely identify a user is a context-specific
issue.  In the physical world, most entitles that act like CAs assign a number
to each user: SSN, passport number, credit card account number, 
driver license number, loyalty program member number, ...  These are 
great choices, so long as they are interpreted by the issuer, or an 
entity that can ask the issuer for help if needed.  As I told David, 
there are no identifiers that are both globally unique and globally 
meaningful.

Steve

---

From: Tom Gindin <[email-masked]>
Date: Thu, 10 Mar 2011 21:03:21 -0500

Would it help resolve this discussion if I could use a set of 
naming conventions used by at least one major CA, to construct a scenario 
leading to a subject DN collision in a case I will specify below?  This 
does require that that same set of naming conventions be used by more than 
one CA.
        First, the naming convention.  I have seen several certificates 
from this CA (call it I-0) whose DN's contain the following attributes, 
all of them accurate for that certificate: CN=hostname.domain, 
OU=(Specified by domain), O=(Friendly name of domain), L=(HQ of domain), 
ST=(State of L), C=US.  These values are all verified by the issuer, but 
none of them are specified by it.
        Second, an employee of "domain" creates a certificate request for 
an SSL server which receives HTTPS traffic through a load balancer, but 
another SSL-using application protocol through a direct interface.  The 
request specifies CN=balancer.domain, with all other DN attributes as 
above.  It also specifies two different DNS names in the Subject 
Alternative Name extension: balancer.domain and server1.site.domain (the 
address of the actual server where the key resides).  This is a perfectly 
accurate request, and I-0 approves it and issues the appropriate 
certificate.  Remember, most SSL connections are sent to this server using 
balancer.domain and others use server1.site.domain.
        Third, the employee in the second paragraph goes on vacation while 
another member server for this load balancing group is brought up, and his 
boss decides to switch issuers to another CA called I-1, which permits the 
same names as I-0.  The vacation substitute looks at the notes of the last 
request, and creates a request which specifies CN=balancer.domain, with 
all other DN attributes as above, and two different DNS names in the 
Subject Alternative Name extension: balancer.domain and 
server2.altsite.domain (the name of the server where this new key 
resides).  I-1 approves this request, having no way to know that it's a 
duplicate name, and issues the certificate which violates X.500's 
constraint that you cite.  Remember, most SSL connections are sent to this 
server using balancer.domain and others use server2.altsite.domain.

                Tom Gindin

From:
"David A. Cooper" <[email-masked]>
To:
"[email-masked]" <[email-masked]>
Cc:
pkix <[email-masked]>
Date:
03/10/2011 01:55 PM
Subject:
Re: [pkix] PKIX review on draft-ietf-hip-cert-11
Sent by:
[email-masked]

Denis,

Nowhere in the text that you quoted does it state that different CAs may 
issue certificates with the same subject name to different entities.

Nowhere is it stated that the requirement for names to be unambiguous only 
applies in the context of the Directory.  In fact, X.501 and X.509 clearly 
state otherwise.

The charter for the PKIX WG states that "PKIX will continue to track the 
evolution of ITU-T X.509 documents, and will maintain compatibility 
between these documents and IETF PKI standards".  X.509 requires names to 
be unambiguous, whether or not there is a Directory.  Thus PKIX would not 
be maintaining compatibility with X.509 if it said that names did not have 
to be unambiguous.

It is surprising that you are omitting to mention your own original 
request which was:
"So, if I am wrong, please quote specific text from the standards that 
clearly supports your claims".
 
It is quite surprising that you are quoting my text but with a deliberate 
truncation. 
So I re-establish the text below:

2.4.  Uniqueness of names

You got the specific text. If I understand you correctly, you disagree 
with RFC 3739.
Sorry, but RFC 3739 has been adopted by the PKIX WG and you were a member 
of it at this time.
 
Now, your arguments are perfectly valid as long as you only use X.509 in 
the context of the Directory.
The PKIX WG does not address that specific case.
 
Denis
 
----- Message reçu ----- 
De : David A. Cooper 
À : [email-masked] 
Date : 2011-03-10, 14:52:34
Sujet : Re: [pkix] PKIX review on draft-ietf-hip-cert-11

Denis,

And yes, even without a Directory, people have found X.509 useful as a 
means of binding public keys to identities.  But they have found it useful 
in an environment in which names are unambiguous.  If names were 
ambiguous, then what would be the point of the PKI?

If PKIX was designed based on an assumption that names may be ambiguous, 
then why does RFC 5755 recommend identifying the holder of an attribute 
certificate using the issuer name and serial number of the holder's public 
key certificate (a method that would not work if names were ambiguous) 
rather than recommending that the holder be identified by the hash of the 
holder's public key?

Dave

You are omitting a fundamental point. 
X.509 is part of the X.500 series of documents and was a solution designed 
to bring a security 
to the Directory (with a capital D) better than IDs and passwords.
 
Basically your assertion is true as long as X.509 is used in the context 
of a DIT.

X.500 as a whole has not been very successful, but X.509 has been 
successful.
 
PKIX is using X.509 outside the context of the DIT. The uniqueness of the 
DIT structure does not apply anymore, 
hence why I am keeping the same language. 

9.2 Names in general

and X.509 says:

---

From: Sean Turner <[email-masked]>
Date: Thu, 10 Mar 2011 21:32:27 -0500

> relevant, and ought to be addressed.

Thanks for reminding me about Stefan comments.

The -11 version made some changes like addressing which of the 
GeneralName choices to use, but now it's silent on the subject/issuer 
field.  It still shows them in the appendix though.

> The HIP cert doc calls for putting the HIT in a IAN and an SAN. It is
> not clear why this is a good idea. The spec does not seem to explain why
> an issuer should be identified by an HIT. if there is no good reason for
> this, then it can go away, and avoid the need for an IAN extension in
> these certs. It would make life simpler if the HIT appeared only in an
> EE cert, where the Subject Dn could be omitted, and the HIT be encoded
> as an IPv6 address SAN.

I'm not following their new text.  It now says "When Host Identifier 
(HI) is used to sign ..." so now the address is the key.  I don't think 
that's right, but I'll track it down.

It sounds like they want to only use certificates from Host that use 
HITs as their names, but I need to confirm.

> finds the name to use for SPD matching and IKE validation, because this
> topic was omitted in the first version of the specs. I think it best if
> we provide some guidance here, re this issue, and stop discussing name
> uniqueness.

Great.

> a CA is a Certification Authority, not a Certificate Authority.

I'll note this.  It's surprising how many people make this mistake.

---

From: "Manger, James H" <[email-masked]>
Date: Fri, 11 Mar 2011 15:56:34 +1100

Steve Kent is right that unambiguously identifying a user is a context-specific issue. However, a lot of software (particularly libraries) has to be written fairly generically -- without hardwiring a specific context.

There are a few approaches generic software could take to identity entities:

1) Use the subject DN[+SAN]

2) Use the chain of DNs: subject[+SAN]/issuer/intermediate-CA/.../root

3) Be highly configurable to accept: 1); 2); one attribute from the subject DN or SAN; the whole certificate; ...

Option 1 implies that an RP needs to be quite careful when choosing a set of roots to trust so that no two roots could inadvertently certify the same subject DN against different entities.

Option 2 is more fail-safe, but at the likely cost of more failures.
Access will fail when a entity gets a cert from a different CA, or even when renewing a cert with the same CA company but under a different root name (eg "Thawte Server CA" vs "Thawte Premium Server CA").
Access may also fail when an RP trusted a new CA, which might be an intermediate CA in some chains. I hate to think how this works with a Bridge CA. It may also break when new-with-old CA key change certs are in the path?

Option 3 punts the issue elsewhere (as standards often do).

In many common situations the RP requires a specific attribute (eg domain name, IP address, email address) that is typically globally-unambiguous. The RP will (fairly sensibly) treat any cert with a particular attribute value as identifying the same entity, as long as it chains to a configured trusted root. Any "names-are-only-unambiguous-per-CA" rule is ignored.

Option 1 introduces more risks. Plenty of people are concerned that 100's of CAs they have never heard of (but are trusted by browsers) can masquerade as their secure website. Unfortunately Option 2 wouldn't help here -- but draft-hallambaker-donotissue might [DNS CA Authorization (CAA) Resource Record; http://tools.ietf.org/html/draft-hallambaker-donotissue].

RFC 3739 "Qualified Certs" adopts option 2, which is sort of ok for this specific context. However, I expect most software implements option 1 (easier; shorter ids;...). It would be better if standards matched what is implemented, with appropriate security warnings.

--
James Manger

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 11 Mar 2011 20:51:26 +1300

"Miller, Timothy J." <[email-masked]> writes:

>X.500 is fundamentally broken because it was designed without taking into
>account the political reality that "One DIT to Rule Them All" wasn't every
>going to happen.
>
>X.509 can function just fine without it X.500--so long as any given PKI
>maintains uniqueness of names within that PKI's scope *and* understands that
>name collisions *between PKIs* is a risk to be mitigated (through, e.g., Name
>Constraints when using cross-certification or through trust anchor management
>when not).

Actually we do have a form of unique/unambiguous ID (other than the public
key) in each cert, which is the bit that matters, either a URL/FQDN or email
address.  The random noise that gets dumped in the DN
("SomeCountry/SomeState/SomeOrganization" (literally, from some certs)) just
turns it into a complex not-quite-GUID, but we do have a global ID in the bit
where it matters.

Peter.

---

From: Tobias Heer <[email-masked]>
Date: Fri, 11 Mar 2011 10:27:21 +0100

Hello Stephen,

> I wonder are the hip folks finding it very helpful;-)
Right now we are still following the discussion (with amazement ;-) ) and try to derive changes that would make the text in the draft less controversial.

We would be very open for actual reviews or concrete suggestion. I guess the HIP cert draft is not the place to solve the deeper issues regarding the uniqueness of the DN, right?

Thanks in advance.

Tobias

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://www.comsys.rwth-aachen.de/team/tobias-heer/
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi
pgp id: AEECA5BF

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 11 Mar 2011 09:00:20 -0500

On Mar 10, 2011, at 7:46 PM, Stephen Kent wrote:

> 											As I told David, 

I suppose that depends on what you mean by "globally meaningful."  You you mean "everyone agrees on the authorizations assigned to it" then yes, I'd agree, but that seems like stating the obvious.

Within a given system, however, globally unique identifiers can have plenty of meaning, but that's certainly not global (and may vary from system to system for the same identifier).

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 11 Mar 2011 09:02:06 -0500

So what?  What's the impact?  If the client's trust control is adequate, nothing happens.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 11 Mar 2011 09:05:37 -0500

> turns it into a complex not-quite-GUID, but we do have a global ID in the bit

Only for certain classes of entities, i.e., those that map to unique DNS, IP, or RFC822 names.

I have entities in my PKI that don't, won't, or can't.

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 11 Mar 2011 09:10:18 -0500

On Mar 10, 2011, at 4:08 PM, David A. Cooper wrote:

> subjectAltName extension?  

The implementation is, indeed, using the SKID.  The problem is the vendor in question *assumes* that the SKID is formed in a specific way that's cryptographically bound to the cert (i.e., that SKID == SHA1(pubkey))  *but* doesn't actually bother to check this.  As a result this specific configuration is unsafe; since the standard makes no requirement on SKID binding, my CA can shove any damn value I care to into any cert and no-one can say boo about it.

-- T

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 11 Mar 2011 09:11:09 -0500

You can assign DNS based names to humans also with prefix being DNS based DC components representing the Enterprise and with the CN component being unique for the organization (e.g., using Employee ID).making the whole DN unique and meaningful.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miller, Timothy J.
Sent: Friday, March 11, 2011 9:06 AM
To: Peter Gutmann
Cc: [email-masked]; [email-masked]
Subject: Re: [pkix] PKIX review on draft-ietf-hip-cert-11

On Mar 11, 2011, at 1:51 AM, Peter Gutmann wrote:

> key) in each cert, which is the bit that matters, either a URL/FQDN or 
> email address.  The random noise that gets dumped in the DN 
> ("SomeCountry/SomeState/SomeOrganization" (literally, from some 
> certs)) just turns it into a complex not-quite-GUID, but we do have a 
> global ID in the bit where it matters.

-- T

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 11 Mar 2011 09:11:34 -0500

(Subject changed to respect Steve's request to stay on topic)

It would be nice to have a verifiably-global-unique ID, not requiring
you to believe that 100s of CAs all have your best interests at heart.

I could send you a signed email from [email-masked] using a cert
from my CA, which you might just click OK to trust.  Or I could mess
with mail servers or MX records to intercept and respond to a legitimate
CA's email verification, so you would trust the cert automatically.
Email is globally unique, but it is not verifiable by the RP.

The same is true of SKID, even if 5280 said it MUST be a SHA-1 hash,
because there is no requirement for RPs to verify that the SKID in a
cert actually is the hash.  The correct approach would be to leave the
SKID extension out of the cert entirely and require applications to
compute it from subject public key.

-----Original Message-----
From: Peter Gutmann [mailto:[email-masked]] 
Sent: Friday, March 11, 2011 2:51 AM
To: [email-masked]; [email-masked]
Cc: Kemp, David P.; [email-masked]
Subject: Re: [pkix] PKIX review on draft-ietf-hip-cert-11

>Constraints when using cross-certification or through trust anchor
management

Actually we do have a form of unique/unambiguous ID (other than the
public
key) in each cert, which is the bit that matters, either a URL/FQDN or
email
address.  The random noise that gets dumped in the DN
("SomeCountry/SomeState/SomeOrganization" (literally, from some certs))
just
turns it into a complex not-quite-GUID, but we do have a global ID in
the bit
where it matters.

Peter.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 11 Mar 2011 09:13:09 -0500

> and presumably easy to enforce.

One would hope it's at least enforceable; 'easy' is a matter of perspective.

I've found that for whatever reason non-PKI people seem to have the hardest time grasping is that the "trust" part of PKI arises not from the technology, the name, or the chain, but in the rigor of the issuance ceremony.

-- Tim

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 11 Mar 2011 09:21:10 -0500

> Email is globally unique, but it is not verifiable by the RP.

So this is a key introduction attack.  If I ever were to get a signed email from the "real" [email-masked], my mail client can at least detect that *something* has happened.  It would be then up to me to figure out what that was through alternative means.

Shall I post a link to Garfinkel & Miller's "Johnny 2: A User Test of Key Continuity Management with S/MIME and Outlook Express"?  Oh, why not--it's my hobby horse, so why not take the opportunity to ride it?  :)

http://cups.cs.cmu.edu/soups/2005/2005proceedings/p13-garfinkel.pdf

-- T

---

From: Tom Gindin <[email-masked]>
Date: Fri, 11 Mar 2011 10:13:08 -0500

The good news is that the everyone involved was acting in a way 
that does not violate the client's trust, and the client gets the service 
he wants.  Every attribute certified was accurate, and no combination of 
them was misleading.  The bad news is only from an X.500 standpoint - 
X.501 name uniqueness did get violated without doing anything wrong 
(unless you count using the load balancer name instead of the server name 
as the CN).

Tom Gindin

From:
"Miller, Timothy J." <[email-masked]>
To:
Tom Gindin/Watson/IBM@IBMUS
Cc:
"David A. Cooper" <[email-masked]>, pkix <[email-masked]>, 
"[email-masked]" <[email-masked]>
Date:
03/11/2011 09:02 AM
Subject:
Re: [pkix] DN Collision - was  PKIX review on draft-ietf-hip-cert-11

So what?  What's the impact?  If the client's trust control is adequate, 
nothing happens.

-- T

> Nowhere is it stated that the requirement for names to be unambiguous 
only 

> between these documents and IETF PKI standards".  X.509 requires names 
to 
> It is quite surprising that you are quoting my text but with a 
deliberate 
> Sorry, but RFC 3739 has been adopted by the PKIX WG and you were a 
member 

> means of binding public keys to identities.  But they have found it 
useful 

> X.509 is part of the X.500 series of documents and was a solution 
designed

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 11 Mar 2011 10:14:44 -0500

> There is not widespread disagreement on this topic. It's just David :-).

Then why I am the only one who can quote text from X.509 that 
demonstrates that my position is correct?  Why is no one able to answer 
my question about the design of the attribute certificate profile in RFC 
5755?  What about all of the other security vulnerabilities that would 
be created if an X.509 path validation library were to be used in an 
environment in which multiple trusted entities operate under the same name?

> the RPKI explicitly notes that global name uniqueness ought not be

This is completely untrue! I never objected to such a thing.  On 
numerous occasions I recommended that the RPKI documents be written to 
require that names be created in a manner that would ensure that names 
would be unambiguous, but to also write the certificate validation rules 
for the RPKI in such a way that name collisions would not lead to 
security problems.  Yet for some reason you insisted that the developers 
of the RPKI had to be explicitly told that there was no need for names 
to be unambiguous.  In fact, I was the one who encouraged adding text to 
the RPKI path validation section explicitly imposing a requirement to 
only use a CRL to determine the status of a certificate if that CRL were 
signed using the same key as the corresponding certificate.  Yet, you 
argued against adding that text, even though you agreed with the 
requirement.  My objection was to RPKI documents explicitly telling 
issuers that there was no such requirement, not to encouraging relying 
parties to protect against the risk that the requirement would not be 
satisfied.  Perhaps you were too busy disagreeing with me to read what I 
actually wrote.

I have never said that relying parties are required to be designed to 
ignore the possibility (no matter how remote) that a name collision 
could occur.  But, I am adamantly against deceiving issuers into 
believing that no such requirement exists.

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 11 Mar 2011 10:45:49 -0500

Tom,

It is not clear to me that this hypothetical scenario would be a 
violation of X.501 or X.509 naming requirements.  The requirement is 
that a name unambiguously identify a single entity.

So, in your scenario there are two different certificates that include 
the name "balancer.domain", but it is the same entity (the load 
balancer) that is being identified in both certificates.  If the idea 
that clients connect to balancer.domain and are then redirected to 
either server1.site.domain or server2.altsite.domain.  If so, then it 
would seem that it is the organization's intention for it to appear to 
clients that they are connecting to the same entity when they connect to 
balancer.domain whether they are redirected to server1.site.domain or 
server2.altsite.domain.  So, this doesn't seem to be a case of two 
different entities being assigned the same name, but of a (logically) 
single entity being assigned two certificates with the same name.

Dave

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 11 Mar 2011 14:59:16 -0500

Detection after the fact is good (thanks for the pointer), but
prevention is better.  And although we have been discussing whether
X.509 requires global name uniqueness, the real issue is naming
accountability.

E-mail names have a user-part and a host-part.  The SAML Persistent
Identifier has the NameQualifier attribute that "MUST contain the unique
identifier of the identity provider that generated the identifier".  The
RFC 4043 Permanent Identifier has an assigner field that identifies the
Assigner Authority responsible for the identifierValue.  The authority
part of any qualified name (host-part, NameQualifier, assigner, etc) is
what enables accountability.  It also happens to support global
uniqueness.

When X.509 moved from v1 to v3 it decoupled certification authorities
from naming authorities, but the replacement accountability mechanism
(name constraints) was made optional.  So it is not just the ABCD.com
organization that can create a usable certificate with a [email-masked]
email address; any CA on the giant browser trust list can do so.  This
allows "forum shopping" (finding a weak issuer out of hundreds of
possibilities) instead of being required to compromise the specific
issuer responsible for a particular domain.

X.509 needs to enable relying parties to reliably determine whether a
certificate for a subject in a particular domain is in fact
authoritative for that domain.

-----Original Message-----
From: Miller, Timothy J. [mailto:[email-masked]] 
Sent: Friday, March 11, 2011 9:21 AM
To: Kemp, David P.
Cc: Peter Gutmann; [email-masked]; [email-masked]
Subject: Re: Unique IDs (NOT: [pkix] PKIX review on
draft-ietf-hip-cert-11)

> Email is globally unique, but it is not verifiable by the RP.

So this is a key introduction attack.  If I ever were to get a signed
email from the "real" [email-masked], my mail client can at
least detect that *something* has happened.  It would be then up to me
to figure out what that was through alternative means.

Shall I post a link to Garfinkel & Miller's "Johnny 2: A User Test of
Key Continuity Management with S/MIME and Outlook Express"?  Oh, why
not--it's my hobby horse, so why not take the opportunity to ride it?
:)

-- T

---

From: Stephen Wilson <[email-masked]>
Date: Sat, 12 Mar 2011 07:08:10 +1100

Wow, this thread has become an exemplar of technology-in-a-bubble.  It 
shows perfectly what has ailed PKI for 15 years -- technologists imbuing 
their work with idiosyncratic models of how the world works, either 
innocently, or sometimes striving to change the world.

How did we get to wishing for a globally unique identity, from the 
starting point of binding public keys to names?

PKI should have nothing to say about how names are assigned to 
Subjects.  If there is ambiguity in my name, why on earth should PKI 
care?  It's not a technology problem.  What is a technology problem is 
when standards get so biassed by arbitrary pernickity world views that 
perfectly good software is rendered "non compliant" and non-interoperable.

I'm sure everyone in PKIX cares passionately that PKI should succeed. So 
let's learn from its success stories.  PKI works well in closed domains, 
and it's intractable in open domains.  I have argued that, 
counterintuitively, "open" IdM is a special case, and "closed" is the 
general case.  In general, we can describe any IdM domain in terms of 
the rules that govern how actors are known (named if you will) on that 
domain.  "Open PKI" is a very special case where a utopian widely unique 
(if not globally unique) name is used.  It's not even a useful model in 
practice; so what if Alice in Albania has a certificate containing the 
absolutely unique name of Bob in Botswana?  She invariably needs more 
information anyways!  The story of Big PKI is an obsecene amount of 
effort going into an arcane infrastructure that isn't even useful for 
real world transactions.

See 
http://middleware.internet2.edu/idtrust/2008/papers/07-wilson-public-key-superstructure.pdf

We all know the old saw: such-and-such a problem is 10% technology and 
90% 'business'.  It's a real mystery to me why PKI technologists just 
can't help but roam ambitiously into non-tech issues like naming, thus 
consigning what could be elegant computing problems to a morass of 
corporate policy, law and regulations, sociology and philosophy.

PKI proponents and technologists need to move away from the issue of names!

There are wonderous applications for PKI in presenting anonymous 
assertions ... such as "Over 18, so says the DMV [as certificate 
Issuer]" tp pick a simple example.  A most elegant proof-of-age solution 
would be for the DMV when issuing smartcard driver licences to issue 
X.509 certificates with CN (sic) = "Over 18".  The Policy OID would 
uniquely specify that the meaning of such a certificate is nothing more 
and nothing less than the fact that the private key has been issued by 
the DMV in a certain type of smartcard to someone they know to be 18 
years old.  That would be an exact (nay, improved) X.509 representation 
of the regular plastic proof of age card.  Why use the CN field for 
this? Purists would say it's a hack, but it's elegant: you'd hope that 
CN is one of the most trouble-free fields to parse, it avoids customised 
certificate profiles, it means no change at all to CA and Card Mgt 
System templates, and replacing the Subject name with an non-identifying 
attribute is consistent with privacy principles.

If certificates were issued like this, I would like to think that a 
software developer could pull out any PKI library module, parse the 
certificate, retrieve "CN=Over 18", check the Policy OID, and then know 
what to do with the information.  But an obsession with names means that 
X.509 certificates and libraries are so rigid and so brittle that they 
cannot always be easily pressed into service for more flexible ways of 
doing IAM.

Can anyone point to a tangible benefit to the PKI cause of obsessing as 
we do over issues like naming?

Phew! Feeling better now ...

Cheers,

Steve W.

Stephen Wilson
Managing Director
Lockstep Group

Phone +61 (0)414 488 851

www.lockstep.com.au <http://www.lockstep.com.au>
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy.Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.

On 12/03/2011 1:11 AM, Kemp, David P. wrote:
> "Miller, Timothy J."<[email-masked]>  writes:
>

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 11 Mar 2011 15:29:18 -0500

Stephen,

"Name" is not restricted to personal/common names or email addresses; a
name is just as easily (in fact preferably) an opaque number such as a
UUID to which the attribute "age over 18" can be attached.

You can say that users should have a different (non-identity)
authentication credential for each attribute of interest, but that is
going to the opposite extreme from having a single identity to which
every attribute is attached.

As soon as you admit the possibility of a hybrid solution (more than one
identity, but more than one attribute per identity) then you need an
identity (name) to which attributes are attached.  And that name must be
unique, otherwise the attributes can be misused.

Dave

-----Original Message-----
From: Stephen Wilson [mailto:[email-masked]] 
Sent: Friday, March 11, 2011 3:08 PM
To: Kemp, David P.; [email-masked]
Cc: Peter Gutmann; [email-masked]; [email-masked]
Subject: Re: [pkix] Unique IDs (NOT: PKIX review on
draft-ietf-hip-cert-11)

PKI should have nothing to say about how names are assigned to Subjects.
If there is ambiguity in my name, why on earth should PKI care?  It's
not a technology problem.  What is a technology problem is when
standards get so biassed by arbitrary pernickity world views that
perfectly good software is rendered "non compliant" and
non-interoperable. 

See
http://middleware.internet2.edu/idtrust/2008/papers/07-wilson-public-key
-superstructure.pdf

PKI proponents and technologists need to move away from the issue of
names!  

Cheers, 

Steve W.

Stephen Wilson
Managing Director
Lockstep Group

Phone +61 (0)414 488 851

www.lockstep.com.au
Lockstep Consulting provides independent specialist advice and analysis 
on digital identity and privacy.  Lockstep Technologies develops unique 
new smart ID solutions that enhance privacy and prevent identity theft.

	
	It would be nice to have a verifiably-global-unique ID, not
requiring
	you to believe that 100s of CAs all have your best interests at
heart.
	
	I could send you a signed email from [email-masked]
using a cert
	from my CA, which you might just click OK to trust.  Or I could
mess
	with mail servers or MX records to intercept and respond to a
legitimate
	CA's email verification, so you would trust the cert
automatically.
	Email is globally unique, but it is not verifiable by the RP.
	
	The same is true of SKID, even if 5280 said it MUST be a SHA-1
hash,
	because there is no requirement for RPs to verify that the SKID
in a
	cert actually is the hash.  The correct approach would be to
leave the
	SKID extension out of the cert entirely and require applications
to
	compute it from subject public key.

	-----Original Message-----
	From: Peter Gutmann [mailto:[email-masked]] 
	Sent: Friday, March 11, 2011 2:51 AM
	To: [email-masked]; [email-masked]
	Cc: Kemp, David P.; [email-masked]
	Subject: Re: [pkix] PKIX review on draft-ietf-hip-cert-11
	
	"Miller, Timothy J." <[email-masked]>
<mailto:[email-masked]>  writes:

		X.500 is fundamentally broken because it was designed
without taking

	into

		account the political reality that "One DIT to Rule Them
All" wasn't

	every

		going to happen.
		
		X.509 can function just fine without it X.500--so long
as any given PKI
		maintains uniqueness of names within that PKI's scope
*and* understands

	that

		name collisions *between PKIs* is a risk to be mitigated
(through,

	e.g., Name

		Constraints when using cross-certification or through
trust anchor

	management

		when not).

	Actually we do have a form of unique/unambiguous ID (other than
the
	public
	key) in each cert, which is the bit that matters, either a
URL/FQDN or
	email
	address.  The random noise that gets dumped in the DN
	("SomeCountry/SomeState/SomeOrganization" (literally, from some
certs))
	just
	turns it into a complex not-quite-GUID, but we do have a global
ID in
	the bit
	where it matters.
	
	Peter.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Fri, 11 Mar 2011 15:49:37 -0500

> UUID to which the attribute "age over 18" can be attached.

This is why I prefer 'identifier' to 'name.'  'Name' connotes human-readable meaning, 'identifier' does not.

-- Tim

---

From: Tom Gindin <[email-masked]>
Date: Fri, 11 Mar 2011 16:44:35 -0500

The second paragraph acquires a certificate to reside on server1, 
and the third acquires a certificate to reside on server2.  The load 
balancer does NOT possess either certificate, and the objects which do 
possess them are distinct servers.  While both of the servers are sent 
HTTPS traffic by the load balancer, for other protocols they act as 
independently addressable servers.  I will say that I have actually seen 
multiple servers in an HTTPS load balancer group which use other 
application protocols, and that some of those protocols which address the 
individual servers independently can use SSL or TLS as a transport.
        If the two servers didn't have independent host names in the SAN 
extension, they could plausibly be considered as part of the same logical 
entity.  As it is, I don't see how they can.  This is a clear example of 
the SAN being more meaningful than the DN.  However, the meaning of the 
DNSName fields in the SAN here is not "here's the name of this entity" but 
rather "this entity is authorized to receive traffic under this name".
        Having read Steve Wilson's post since starting this, I'd just like 
to point out that the exact definition of a name is a problem which I do 
not hope to solve here.  The fact that a DN is assigned to two distinct 
although cooperating entities does not appear to pose any serious 
problems.  The major problem with doing the same for e-mail signers seems 
to me to be that e-mail certificates are also used for asynchronous key 
encryption, so that the other members of a group of signers won't be able 
to read the encrypted e-mail response.
        Of course, the original point of my comment on HIP was to suggest 
that Subject DN was an imprecise way to specify a certificate.  I like 
philosophical discussions well enough, but there's a practical point under 
all this.

                Tom Gindin

From:
"David A. Cooper" <[email-masked]>
To:
Tom Gindin/Watson/IBM@IBMUS
Cc:
pkix <[email-masked]>
Date:
03/11/2011 10:46 AM
Subject:
Re: DN Collision - was [pkix] PKIX review on draft-ietf-hip-cert-11

Tom,

Dave

---

From: Stephen Wilson <[email-masked]>
Date: Sat, 12 Mar 2011 16:56:45 +1100

Dave,

> UUID to which the attribute "age over 18" can be attached.
If I want an anonymous assertion of age, why would I risk 
re-identification by adding a unique ID?
> every attribute is attached.
What's "extreme" about removing identifying information from attributes 
that I want to assert anonymously?
> unique, otherwise the attributes can be misused.
I don't see such hybrids as necessary.  The most elegant solution for 
anonymous proof of age is to have a digital certificate issued by an 
authority already authorised to assert age, and to have the Subject  
sign some nonce using that certificate and send it back to the Relying 
Party. Why can't we use off-the-shelf PKI tech and tools to do that?

Cheers,

Steve.

> 	"Miller, Timothy J."<[email-masked]>

---

From: Tomas Gustavsson <[email-masked]>
Date: Sun, 13 Mar 2011 12:38:37 +0100

Well put Stephen,

We need to realize that PKI is great technology when used correctly, and
it is only the implementor that knows what "correctly" means in his
specific domain. In some case it calls for unique identifiers, in some
not. The technology (should) support both cases just fine and it's a
business decision which road to go down with regards to policy.

I have seen lots of exotic uses of PKI, and I acknowledge there are
plenty that I can't even imagine.
There are even PKIs that don't (shudder ;-)) care about revocation,
allows the same public key to be used for several entities etc, etc.

I'm all for keeping domain specific standards apart from technology
standards.

Cheers,
Tomas

---

From: Samu Varjonen <[email-masked]>
Date: Mon, 14 Mar 2011 11:25:41 +0200

> On 3/9/11 9:31 AM, Tom Gindin wrote:

Thank you for your feedback.

> suggestion. As to the concerns about using DNs, this draft normatively points to
> 5280 for structure and for security considerations so I think there's nothing
> new that needs to be added about that in this draft.
>

The last paragraph of section 2 is now:

"  Distinguished name (DN) encodings (7 and 8) are represented by the
    string representation of the certificate's subject DN as defined in
    [RFC4514].  Using the DN encoding results in smaller HIP control
    packets, but requires the receiver to retrieve the certificate or
    check a local cache against the DN.
"

> I think the hip folks are just going to take whatever they get from their IKEv2
> stack. I'll check with the IPsec folks to make sure it's clear what the format
> is, but checking with them shouldn't hold up progressing this draft.
>

Sounds OK to me.

---

From: Samu Varjonen <[email-masked]>
Date: Mon, 14 Mar 2011 11:28:18 +0200

On 14/03/11 11:26, Samu Varjonen wrote:
> Hi,
>
> Thank you for your comments.
> On 11/03/11 01:55, Sean Turner wrote:
>> If this is the only comment you get the upshot is that at this point only a
>> minor tweak is necessary. If you can't get a new draft in by Monday, Ralph can
>> add an RFC editor's note (there's no submission deadline on RFC editor notes).
>>
>> Note that I also noted that in Section 2, the draft indicates that the encodings
>> for types 3-8 are smaller. Smaller than what? Including the certificates? It
>> might be helpful to indicate this in the draft. Maybe something like (3x):
>>
>> OLD:
>>
>> in smaller HIP control packets is smaller
>>
>> NEW:
>>
>> in smaller HIP control packets is smaller than including the certificate
>>
>
> OK, changed.
>

Sorry, forgot to send this answer to the mailing list.

> BR,
> Samu
>
>> spt
>>
>> On 3/10/11 6:42 PM, Sean Turner wrote:

---

From: Samu Varjonen <[email-masked]>
Date: Mon, 14 Mar 2011 11:32:06 +0200

> The -11 version made some changes like addressing which of the GeneralName
> choices to use, but now it's silent on the subject/issuer field. It still shows
> them in the appendix though.
>

We have a new version of the appendix (post version 11)

Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number: 0 (0x0)
         Signature Algorithm: sha1WithRSAEncryption
         Issuer: CN=Example issuing host, DC=example, DC=com
         Validity
             Not Before: Mar 11 09:01:39 2011 GMT
             Not After : Mar 21 09:01:39 2011 GMT
         Subject: CN=Example subject host, DC=example, DC=com
         Subject Public Key Info:
             Public Key Algorithm: rsaEncryption
             RSA Public Key: (1024 bit)
                 Modulus (1024 bit):
                     00:c0:db:38:50:8e:63:ed:96:ea:c6:c4:ec:a3:36:
                     62:e2:28:e9:74:9c:f5:2f:cb:58:0e:52:54:60:b5:
                     fa:98:87:0d:22:ab:d8:6a:61:74:a9:ee:0b:ae:cd:
                     18:6f:05:ab:69:66:42:46:00:a2:c0:0c:3a:28:67:
                     09:cc:52:27:da:79:3e:67:d7:d8:d0:7c:f1:a1:26:
                     fa:38:8f:73:f5:b0:20:c6:f2:0b:7d:77:43:aa:c7:
                     98:91:7e:1e:04:31:0d:ca:94:55:20:c4:4f:ba:b1:
                     df:d4:61:9d:dd:b9:b5:47:94:6c:06:91:69:30:42:
                     9c:0a:8b:e3:00:ce:49:ab:e3
                 Exponent: 65537 (0x10001)
         X509v3 extensions:
             X509v3 Issuer Alternative Name:
                 IP Address:2001:13:8D83:41C5:DC9F:38ED:E742:7281
             X509v3 Subject Alternative Name:
                 IP Address:2001:1C:6E02:D3E0:9B90:8417:673E:99DB
     Signature Algorithm: sha1WithRSAEncryption
         83:68:b4:38:63:a6:ae:57:68:e2:4d:73:5d:8f:11:e4:ba:30:
         a0:19:ca:86:22:e9:6b:e9:36:96:af:95:bd:e8:02:b9:72:2f:
         30:a2:62:ac:b2:fa:3d:25:c5:24:fd:8d:32:aa:01:4f:a5:8a:
         f5:06:52:56:0a:86:55:39:2b:ee:7a:7b:46:14:d7:5d:15:82:
         4d:74:06:ca:b7:8c:54:c1:6b:33:7f:77:82:d8:95:e1:05:ca:
         e2:0d:22:1d:86:fc:1c:c4:a4:cf:c6:bc:ab:ec:b8:2a:1e:4b:
         04:7e:49:9c:8f:9d:98:58:9c:63:c5:97:b5:41:94:f7:ef:93:
         57:29

> I'm not following their new text. It now says "When Host Identifier (HI) is used
> to sign ..." so now the address is the key. I don't think that's right, but I'll
> track it down.
>

Host Identifier (HI) is the public key (RSA or DSA) of the host. Host Identity 
Tag (HIT) is a 128-bit representation of the HI that follows the RFC 4843.

> It sounds like they want to only use certificates from Host that use HITs as
> their names, but I need to confirm.
>

OK, this needs to be clarified. We do not restrict the usage to certificates 
from hosts that use HITs.

BR,
Samu

---

From: Samu Varjonen <[email-masked]>
Date: Mon, 14 Mar 2011 12:03:45 +0200

> I'll note this. It's surprising how many people make this mistake.

Missed this one. Corrected.

BR,
Samu

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 14 Mar 2011 08:40:27 -0400

> [Tomas G]: In some case it calls for unique identifiers, in some not. 
> ...  I'm all for keeping domain specific standards
> apart from technology standards.

I agree completely!

> [Stephen W]: What's "extreme" about removing identifying
> information from attributes that I want to assert anonymously?

Nothing whatsoever.

The point is that for the common case where unique names/identifiers are
required, PKIX should provide mechanisms that increase the assurance of
uniqueness rather than falling back on an assumption that they are
unique simply because X.509 declares that they MUST be.  Most MUSTs in
X.509 are easily verified; this one is not.

I don't view that as a domain-specific requirement - all standards have
optional features that MUST be done in a standard way IF they are done
at all.  Not every cert needs a Key Usage extension, but X.509 defines
the extension for when it is needed.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Mar 2011 11:41:19 -0400

At 9:00 AM -0500 3/11/11, Miller, Timothy J. wrote:
>I suppose that depends on what you mean by "globally meaningful." 
>You you mean "everyone agrees on the authorizations assigned to it" 
>then yes, I'd agree, but that seems like stating the obvious.

no, I don't mean anything quite that narrow. I mean is the ID one 
that other people would consider a way to identify the individual. My 
friends don't relate to me based on my SSN or passport number, for 
exmaple.

>Within a given system, however, globally unique identifiers can have 
>plenty of meaning, but that's certainly not global (and may vary 
>from system to system for the same identifier).

Note that you said "Within a given system, ..."  which means that the 
IDs are not globally unique, only unique relative to the system. It's 
easy to create IDs that are unique on a per-system basis. Within that 
system, the IDs are also meaningful, at least to the manager of the 
system, and maybe to other members (thought not always).

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Mar 2011 11:41:19 -0400

At 10:14 AM -0500 3/11/11, David A. Cooper wrote:
>demonstrates that my position is correct?  Why is no one able to 
>answer my question about the design of the attribute certificate 
>profile in RFC 5755?  What about all of the other security 
>vulnerabilities that would be created if an X.509 path validation 
>library were to be used in an environment in which multiple trusted 
>entities operate under the same name?

Firt, you appear to be the only one in this discussion who thinks hat 
the cited text is sufficient to make your point. Second, you appear 
to be the only one who thinks that the text in question is more 
important that common sense security practice.

>This is completely untrue! ...

The truth is that you railed against the RPKI documents asserting 
that we would not assume that names are globally unique; you wanted 
the text to assert global uniqueness as a requirement, as though that 
would magically solve the problem.
We agreed to note how a (non-rogue) CA might generate names in a 
fashion that makes collisions very unlikely.

One of my favorite quotes from you (your message of 7/22/10) in the 
context of that discussion was:

"X.509 was not, in general, designed with the consideration that a 
PKI might include "malicious CAs".  CAs are considered to be trusted 
entities."

So, because CAs are trusted entities, all we need to do is to state 
as a requirement that they MUST generate unique Subject DNs, and 
we'll be safe!

I think we're done with this discussion.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 14 Mar 2011 15:23:50 -0400

On 03/14/2011 11:41 AM, Stephen Kent wrote:

If I am the only person who believes that X.509 requires names to be
unambiguous, then why did you previously acknowledge that X.509 does
impose that requirement, even though you believe it was a bad design
decision:

On 12/10/2010 11:10 AM, Stephen Kent wrote:

- my criticism of your argument has nothing to do with
whether you are accurately cites X.509; it is a criticism of someone
who seems to believe that some standards are written in stone by
divine inspiration, and who seem
to belive that adherence to them is more important than the underlying security
principles that these standards are meant to support.

If I am the only person who believes this, then why has Sharon Boeyen,
who served for many years as the editor for X.509, repeatedly stated
that X.509 imposes a requirement for names to be unambiguous?

If the text that I quote doesn't support the idea that X.509 requires
names to be unambiguous, how else could one interpret the following:

For every name form used in the GeneralName
type, there shall
be a name registration system that ensures that any name used
unambiguously identifies one entity to both certificate issuer and
certificate users.

Why does RFC 5280 say that "X.509 mandates that names be unambiguous"?
Why does RFC 5755 recommend identifying attribute certificate holder's
by issuer name and serial number, even though that scheme relies on
issuer names to be unambiguous?  Why does the X.509 path validation
algorithm use issuer names as the basis for determining whether a CRL
provides status information for a certificate, yet another scheme that
would not work if a relying party might encounter two trusted entities
that issue under the same name?

You may argue that despite the requirement for names to be unambiguous
that one cannot guarantee with 100% certainly that name collisions
won't happen, and (despite your insinuations to the contrary) I have
always spoken in favor of having relying parties take reasonable
precautions against the (remote) possibility of name collisions.  As I
have repeatedly stated there are steps that relying parties can take
that will improve the efficiency of path discovery without imposing
unnecessary and burdensome requirements on issuers that have the
side-effect of also mitigating the risks if by some chance a name
collision would occur.  I even volunteered to write a best practices
document along these lines.

However, if you mislead issuers into believing that X.509 doesn't
require names to be unambiguous and they don't need to assign names in
a manner that would make it unlikely that name collisions would occur,
then you are setting the stage for a disaster.  If name collisions are
rare (and today they are so rare that no one has been able to present
any evidence of even a single name collision) then one can safely make
use of the names in certificates for such things as populating access
control lists.  If issuers mistakenly believe that there is no reason
that two different entities in a PKI cannot have the same name (as long
as they aren't issued certificates by the same CA) then name collisions
may become common and suddenly PKI will become significantly less
useful.  You could no longer use names for such things as access
control lists, one would have to place the entire certificate, or at
least the public key in the certificate in the ACL, and then update the
ACL each time someone on the ACL was issued a new certificate.  This
would be expensive, time consuming, and prone to mistakes.  The odds of
a mistake occurring in such an environment would be far greater than
the risk that a name collision might occur (that would go unnoticed) if
issuers were aware of X.509's naming requirements.

You also seem to inappropriately equate unambiguous with "globally
meaningful".  No one has ever suggested that there is a requirement for
names to be "meaningful".  A name only needs to be meaningful within
the context of the application(s) that make use of the name.  For
S/MIME that may mean that the name needs to correspond to a particular
mailbox on a mail server.  For other applications it may be acceptable
to use a name that may seem meaningless unless one has access to
external information (e.g., the PKI in Canada that assigns meaningless
but unique numbers (MBUN)).

Yet again you are blatantly misrepresenting what I said.  I did not say
X.509 was designed based on the assumption that CAs are trusted
entities so all is well.  I said that X.509 was designed based on the
assumption that CAs are trusted entities, so one must be extra careful
if one is attempting to use X.509 in an environment where that
assumption may not hold.

I specifically stated in that email that even though the X.509 path
validation algorithm was designed based on an assumption that names
would be unambiguous "that does not mean that the SIDR documents cannot
encourage the use of path validation software that takes a more
restrictive approach to path validation than is allowed by X.509.
Adding a requirement in the path validation section of
draft-ietf-sidr-res-certs to only use a CRL that was signed using the
same key as the corresponding certificate would fall into this
category.  This would be a new requirement, and not an unreasonable one
given that it is consistent with the way that CAs are required to issue
CRLs."

I also never said "because CAs are trust entities, ...."  What I
actually said in that email was:

If the SIDR WG believes that the RPKI may
include "malicious CAs" that cannot be excluded from the PKI, then that
is really something that needs to be covered in the Security
Considerations section.  If there is a serious risk that "malicious
CAs" that cannot be excluded from the PKI will issue certificates to
subordinate CAs under the same name as a "non-malicious CA", then the
Security Considerations section needs to say that and explain the
implications.  In particular, it needs to point out that:

1) X.509 does not require the CRL used to determine the status of a
certificate be signed using the same key as the corresponding
certificate, and there are many path validation libraries available
that will use a CRL signed to one key to determine the status of a
certificate signed using a different key.

2) A "malicious CA" could create a subordinate CA with the same name as
a "non-malicious CA" and then have that subordinate CA issue CRLs that
either make it appear that revoked certificates have not been revoked
or that valid certificates have been revoked.

3) Clients can protect against being tricked by such CA into using the
wrong CRL by only using a CRL to determine the status of a certificate
if the CRL and certificate were signed using the same key.

Without warnings such as this being prominently placed within the SIDR
documents, even someone who carefully reads through the SIDR documents
may not understand that the RPKI is "different" from other X.509 PKIs,
and that there may be security risks to using just any X.509 path
validation library that implements the RFC 3779 certificate
extensions.  Of course, not everyone validating paths within the RPKI
will carefully read these documents, which is why it is important for
the profile to not encourage "non-malicious CAs" to assign names in a
manner that would unintentionally create the same problems that some
are worried that "malicious CA" will intentionally create.

Yes, I also wanted to SIDR WG to indicate to issuers that X.509
required names to be unambiguous (i.e., that no two entities in the
RPKI have the same name), but despite your misrepresentations to the
contrary I repeated encouraged the SIDR WG to prominently warn relying
parties that they needed to ensure that their software would work in
the RPKI even if name collisions did occur.  Before I got involved in
the SIDR WG, the documents told issuers that there was no requirement
for names to be unambiguous (except that a single CA couldn't assign
the same subject DN to two different entities) but provided no warning
to relying parties about the special steps they needed to take to
protect against the possibility that name collisions would occur.

Why are you trying to mislead people about what I recommended to the
SIDR WG?

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 14 Mar 2011 14:48:00 -0700

This tangent is beginning to acquire some of the flavor of a flame war.  I trust that's not actually the intent.

Speaking for myself only, I'm relatively willing to believe that in the real world the proverbial 100 pre-trusted CAs will cooperate sufficiently to prevent creation of duplicate-name sub-CAs ("issuers" in the below discussion).  I actually know of some deliberately-duplicated commercial EE certs that we have purchased, so I know EE subject names are not unique.

My use case is protecting against malicious customers of the 100+ commercial CAs purchasing an EE cert which is intended to resemble a legitimate one.  If an RP is configured to only accept certs from a handful of CAs, and it also checks some attribute which shouldn't (MUST NOT?) be assigned by the customer like the serial number, is that good enough for any realistic deployment?  To me the interesting question is not what ought to be sufficient, but what set of checks really is sufficient with the current standards, and in the real world as it exists.

Re-reading, I seem to be drifting in the direction of the argument that organizational PKI is the generally-reliable case, and the global PKI implied by the proverbial 100 pre-trusted CAs is a special case.  Is looking for some plausibly elegant middle ground really a Quixotic goal?

On Mar 14, 2011, at 12:23 PM, David A. Cooper wrote:

> If I am the only person who believes that X.509 requires names to be unambiguous, then why did you previously acknowledge that X.509 does impose that requirement, even though you believe it was a bad design decision:
> 
> If I am the only person who believes this, then why has Sharon Boeyen, who served for many years as the editor for X.509, repeatedly stated that X.509 imposes a requirement for names to be unambiguous?
> 
> If the text that I quote doesn't support the idea that X.509 requires names to be unambiguous, how else could one interpret the following:
> Why does RFC 5280 say that "X.509 mandates that names be unambiguous"?  Why does RFC 5755 recommend identifying attribute certificate holder's by issuer name and serial number, even though that scheme relies on issuer names to be unambiguous?  Why does the X.509 path validation algorithm use issuer names as the basis for determining whether a CRL provides status information for a certificate, yet another scheme that would not work if a relying party might encounter two trusted entities that issue under the same name?
> 
> You may argue that despite the requirement for names to be unambiguous that one cannot guarantee with 100% certainly that name collisions won't happen, and (despite your insinuations to the contrary) I have always spoken in favor of having relying parties take reasonable precautions against the (remote) possibility of name collisions.  As I have repeatedly stated there are steps that relying parties can take that will improve the efficiency of path discovery without imposing unnecessary and burdensome requirements on issuers that have the side-effect of also mitigating the risks if by some chance a name collision would occur.  I even volunteered to write a best practices document along these lines.
> 
> However, if you mislead issuers into believing that X.509 doesn't require names to be unambiguous and they don't need to assign names in a manner that would make it unlikely that name collisions would occur, then you are setting the stage for a disaster.  If name collisions are rare (and today they are so rare that no one has been able to present any evidence of even a single name collision) then one can safely make use of the names in certificates for such things as populating access control lists.  If issuers mistakenly believe that there is no reason that two different entities in a PKI cannot have the same name (as long as they aren't issued certificates by the same CA) then name collisions may become common and suddenly PKI will become significantly less useful.  You could no longer use names for such things as access control lists, one would have to place the entire certificate, or at least the public key in the certificate in the ACL, and then update the ACL each time someone on the ACL was issued a new certificate.  This would be expensive, time consuming, and prone to mistakes.  The odds of a mistake occurring in such an environment would be far greater than the risk that a name collision might occur (that would go unnoticed) if issuers were aware of X.509's naming requirements.
> 
> You also seem to inappropriately equate unambiguous with "globally meaningful".  No one has ever suggested that there is a requirement for names to be "meaningful".  A name only needs to be meaningful within the context of the application(s) that make use of the name.  For S/MIME that may mean that the name needs to correspond to a particular mailbox on a mail server.  For other applications it may be acceptable to use a name that may seem meaningless unless one has access to external information (e.g., the PKI in Canada that assigns meaningless but unique numbers (MBUN)).
> 
> Yet again you are blatantly misrepresenting what I said.  I did not say X.509 was designed based on the assumption that CAs are trusted entities so all is well.  I said that X.509 was designed based on the assumption that CAs are trusted entities, so one must be extra careful if one is attempting to use X.509 in an environment where that assumption may not hold.
> 
> I specifically stated in that email that even though the X.509 path validation algorithm was designed based on an assumption that names would be unambiguous "that does not mean that the SIDR documents cannot encourage the use of path validation software that takes a more restrictive approach to path validation than is allowed by X.509.  Adding a requirement in the path validation section of draft-ietf-sidr-res-certs to only use a CRL that was signed using the same key as the corresponding certificate would fall into this category.  This would be a new requirement, and not an unreasonable one given that it is consistent with the way that CAs are required to issue CRLs."
> 
> I also never said "because CAs are trust entities, ...."  What I actually said in that email was:
>> If the SIDR WG believes that the RPKI may include "malicious CAs" that cannot be excluded from the PKI, then that is really something that needs to be covered in the Security Considerations section.  If there is a serious risk that "malicious CAs" that cannot be excluded from the PKI will issue certificates to subordinate CAs under the same name as a "non-malicious CA", then the Security Considerations section needs to say that and explain the implications.  In particular, it needs to point out that:
>> 
>> 1) X.509 does not require the CRL used to determine the status of a certificate be signed using the same key as the corresponding certificate, and there are many path validation libraries available that will use a CRL signed to one key to determine the status of a certificate signed using a different key.
>> 
>> 2) A "malicious CA" could create a subordinate CA with the same name as a "non-malicious CA" and then have that subordinate CA issue CRLs that either make it appear that revoked certificates have not been revoked or that valid certificates have been revoked.
>> 
>> 3) Clients can protect against being tricked by such CA into using the wrong CRL by only using a CRL to determine the status of a certificate if the CRL and certificate were signed using the same key.
>> 
>> Without warnings such as this being prominently placed within the SIDR documents, even someone who carefully reads through the SIDR documents may not understand that the RPKI is "different" from other X.509 PKIs, and that there may be security risks to using just any X.509 path validation library that implements the RFC 3779 certificate extensions.  Of course, not everyone validating paths within the RPKI will carefully read these documents, which is why it is important for the profile to not encourage "non-malicious CAs" to assign names in a manner that would unintentionally create the same problems that some are worried that "malicious CA" will intentionally create.
> 
> Yes, I also wanted to SIDR WG to indicate to issuers that X.509 required names to be unambiguous (i.e., that no two entities in the RPKI have the same name), but despite your misrepresentations to the contrary I repeated encouraged the SIDR WG to prominently warn relying parties that they needed to ensure that their software would work in the RPKI even if name collisions did occur.  Before I got involved in the SIDR WG, the documents told issuers that there was no requirement for names to be unambiguous (except that a single CA couldn't assign the same subject DN to two different entities) but provided no warning to relying parties about the special steps they needed to take to protect against the possibility that name collisions would occur.
> 
> Why are you trying to mislead people about what I recommended to the SIDR WG?

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 15 Mar 2011 08:33:27 -0400

> friends don't relate to me based on my SSN or passport number, for 

Nor do they have to.  Ideal global identifiers are context-free (not tied to a namespace, even temporally) and bound to their holders (unforgeable or at least provable; "This is my identifier and I can prove it.").

There are surprisingly few (well, surprising to me, anyway) ways to do this.

> IDs are not globally unique, only unique relative to the system.

Not quite.  Only within a given system does the identifier have meaning; i.e., only then can it be tied to authorizations, which is generally what you're after in the first place (if you don't care about authZ, then you probably don't care about authN or identification either).

However, that does not imply that the identifier is not globally unique.  

-- Tim

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 15 Mar 2011 08:38:31 -0400

> If I am the only person who believes this, then why has Sharon Boeyen, who served for many years as the editor for X.509, repeatedly stated that X.509 imposes a requirement for names to be unambigu…

All this requirement *means* is that two identical RDN sequences represent the same entity in an X.500 directory.

If your *application* doesn't rely on an X.500 directory (note: LDAP != X.500), then this requirement is meaningless *to you*.

Further, if your application is relying on an X.500 directory (or an X.500 concept of naming) and is *not* aware of trust path issues, your application has a bug (or a design flaw, take your pick).

-- Tim

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 15 Mar 2011 08:51:58 -0400

Tim,

David is saying X.509 names as they appear in issuer and subject DN.

Also, what do you mean by phrases "not aware" and "trust path issues"?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Miller, Timothy J.
Sent: Tuesday, March 15, 2011 8:39 AM
To: David A. Cooper
Cc: pkix
Subject: Re: [pkix] PKIX review on draft-ietf-hip-cert-11

-- Tim

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 15 Mar 2011 09:10:11 -0400

> David is saying X.509 names as they appear in issuer and subject DN.

I'm not sure how this clarification modifies my point.

> Also, what do you mean by phrases "not aware" and "trust path issues"?

The point is the DNs alone are insufficient for an authorization decision.  At least the chain and the trust anchor must be included in the calculation (ideally the policy too).  As a result, PK-enabled applications must implement trust lists of one sort or another.  This is the only way to properly constrain namespaces in *all* use cases and resolve David's objection--which I currently understand as "the intentional collision of DNs between different PKIs."

-- T

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 15 Mar 2011 09:54:28 -0400

Tim,

Can you please quote text from X.509 that supports your assertion that
the requirement for names to be unambiguous only applies if the
certificates are being used with an application that relies on an X.500
directory?

As I have pointed out, X.509 notes that the requirement for names to be
unambiguous applies to all name forms that may appear in a certificate,
not just to distinguished names:

For every name form used in the GeneralName
type, there shall be a name
registration system that ensures that any name used unambiguously
identifies one entity to both certificate issuer and certificate users.

You also haven't responded to any of the points that I made about
things that would not work correctly if names were not unambiguous that
have nothing do with with directories.

On 03/15/2011 08:38 AM, Miller, Timothy J. wrote:

-- Tim

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 15 Mar 2011 10:10:44 -0400

Tim,

The lack of ambiguity in DN could also impose the requirement to properly
consider how SET is encoded in DER.

As to the other point, now that you have explained what you mean,
authentication and authorization decisions are two sequential decisions.
You authenticate an identity.  If you are using public key technology,
ideally subject identity from the certificate (after using a secure
authentication protocol, e..g, client authentication aspect of TLS) is used
for access control decision.  That could be DN, something in SAN, hash of
certificate or public key.  I do not want come across as lecturing you and
bore others, each of these have their pros and cons.

Now, certification path validation is to be done per Section 10 of X.509 or
per Section 6 of 5280.  That starts with trust anchor(s) and takes policies
and name constraints etc. into consideration.

We have known all of this since mid-90's modulo the RFC number.

We have lately refined the concept of constraining the trust anchor as well.

Now to authorization.  It would be better to base authorization decision on
the certificate or certificate hash as opposed to series of names in a trust
path.  It is more agile and flexible.

-----Original Message-----
From: Miller, Timothy J. [mailto:[email-masked]] 
Sent: Tuesday, March 15, 2011 9:10 AM
To: Santosh Chokhani
Cc: David A. Cooper; pkix
Subject: Re: [pkix] PKIX review on draft-ietf-hip-cert-11

> Also, what do you mean by phrases "not aware" and "trust path issues"?

The point is the DNs alone are insufficient for an authorization decision.
At least the chain and the trust anchor must be included in the calculation
(ideally the policy too).  As a result, PK-enabled applications must
implement trust lists of one sort or another.  This is the only way to
properly constrain namespaces in *all* use cases and resolve David's
objection--which I currently understand as "the intentional collision of DNs
between different PKIs."

-- T

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 15 Mar 2011 10:36:31 -0400

> Speaking for myself only, I'm relatively willing to believe that in the real world the proverbial 100 pre-trusted CAs will cooperate sufficiently to prevent creation of duplicate-name sub-CAs ("iss…

There is nothing that says that there can not be two certificates with 
the same subject name as long as the same entity is being identified in 
both certificates.

> My use case is protecting against malicious customers of the 100+ commercial CAs purchasing an EE cert which is intended to resemble a legitimate one.  If an RP is configured to only accept certs f…

I think this is really the main issue.  In X.509, CAs are generally 
considered to be trusted entities, but there are no perfect guarantees.  
CAs differ in the stringency of their identity proofing processes and 
differ in the level of controls that they apply to prevent an insider or 
outsider from getting the CA to create an improperly issued 
certificate.  So, you can't simply decide which CAs you are going to 
trust and then assume that none of these CAs could ever issue a "bad" 
certificate.  There are only shades of gray with different CAs providing 
differing levels of assurance.  So, you have to decide what level of 
assurance your application needs and then use that information to decide 
whether to include a CA in list of trust anchors for that application.  
If the certificates being issued are being used to authenticate people 
so that they can log into their accounts on your computer system, then 
you would probably seek a higher level of assurance (i.e., be more 
restrictive in the set of CAs that you are willing to accept as trust 
anchors) than if you were simply configuring your browser for TLS 
authentication of web sites, where you may consider the consequences of 
being connected to a misidentified site are lower.

X.509 does allow for the use of constraints, such that the decision to 
include a CA in trust list doesn't need to be an all-or-nothing decision 
to trust that CA, although in many applications it will have to be an 
all-or-nothing decision.

So, I would not concentrate on the question of whether X.509 requires 
names to be unambiguous.  It clearly does, and it is safe to assume that 
names are unambiguous in practice as long as you can reasonably trust 
the set of CAs that you use as trust anchors.  If you are using a 
product that forces you to trust certificates issued by CAs that you 
believe are susceptible to being tricked into issuing certificates with 
incorrect information by "malicious customers", then you have a 
significant problem that has nothing to do with whether there might be 
two different entities that have been certified as having the same name.

Dave

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 15 Mar 2011 10:36:53 -0400

On Mar 15, 2011, at 8:54 AM, David A. Cooper wrote:

> As I have pointed out, X.509 notes that the requirement for names to be unambiguous applies to all name forms that may appear in a certificate, not just to distinguished names:

> For every name form used in the GeneralName type, there shall be a name registration system that ensures that any name used unambiguously identifies one entity to both certificate issuer and certif…

Ok, once more with feeling:

An EE cert exists in the context of a chain, terminating at a trust anchor.  All are required to properly evaluate the identity carried by the EE certificate.  

*Given a specific trust anchor or CA,* if two different EE certs carry the same identifier(s), then both EE certs carry the same identity.  A given CA and/or trust anchor has a policy and/or a practices statement that tells you how it's verifying, constructing, and/or resolving conflicts of these identifiers prior to issuance.  You can accept these policy and practice statements, or not, at your discretion; or you can pay for an audit.

The fact that *two different trust anchors* can issue EE certs with the same identifier(s) is irrelevant.  *Your* application may treat these certs as the same identity, or not.  That's your problem.

AFAICT, that's pretty much the end of the discussion.  

> You also haven't responded to any of the points that I made about things that would not work correctly if names were not unambiguous that have nothing do with with directories.

Name something that won't work correctly.

-- T

---

From: Tom Gindin <[email-masked]>
Date: Tue, 15 Mar 2011 22:52:18 -0400

One major problem with that text is that while such registration 
authorities exist for IPAddress, DNSName, registeredID, and RFC822Name, no 
such authority exists for directoryName.  While no such authority exists 
for URI's either, the fact that most actual URI's are URN's (with such an 
authority) or else contain a DNSName or IPAddress makes the issue moot.  I 
believe that X400Address is subject to many of the same issues as 
directoryName if you omit both Domain names.  It's true that if ADMD or 
PRMD is specified in an ORAddress you get the sort of protection against 
collisions that you have by using a directory organization under the 
issuer's control.
        I must say that I'd have more respect for statements like that one 
in X.509 if the authors of the standard had noted the absence of any 
collision detecting system for directoryName, and the dangers of using 
EDIPartyName without nameAssigner.  Instead, they issued a directive which 
implies that while one should use directoryName for the primary subject 
name, it's illegitimate to use it in GeneralName despite the syntactical 
provision for it.  The standard does not, however, make a clear statement 
to that effect.
        Do you plan to propose a defect report against X.509 for this 
requirement, whose weaknesses have been abundantly shown in this 
discussion?  A requirement which cannot be fulfilled should be revoked.  I 
think it would be far more helpful to list of practices to help issuers 
minimize the number of DN collisions than to say that they must avoid them 
and not tell them how.

                Tom Gindin

From:
"David A. Cooper" <[email-masked]>
To:
"Miller, Timothy J." <[email-masked]>
Cc:
pkix <[email-masked]>
Date:
03/15/2011 09:54 AM
Subject:
[pkix] Does X.509 say one thing but mean another? (was Re: PKIX review on 
draft-ietf-hip-cert-11)
Sent by:
[email-masked]

Tim,

Can you please quote text from X.509 that supports your assertion that the 
requirement for names to be unambiguous only applies if the certificates 
are being used with an application that relies on an X.500 directory?

You also haven't responded to any of the points that I made about things 
that would not work correctly if names were not unambiguous that have 
nothing do with with directories.

If I am the only person who believes this, then why has Sharon Boeyen, who 
served for many years as the editor for X.509, repeatedly stated that 
X.509 imposes a requirement for names to be unambiguous?

All this requirement *means* is that two identical RDN sequences represent 
the same entity in an X.500 directory.

If your *application* doesn't rely on an X.500 directory (note: LDAP != 
X.500), then this requirement is meaningless *to you*.

Further, if your application is relying on an X.500 directory (or an X.500 
concept of naming) and is *not* aware of trust path issues, your 
application has a bug (or a design flaw, take your pick).

-- Tim

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 16 Mar 2011 08:54:38 -0400

Santosh,

If everything about authentication works as designed, then authorization
works as intended.  "Everything" includes:

1) DNs and otherNames are globally unique - I agree with David Cooper
that X.509 and 5280 say that they MUST be so, regardless of any quotes
that, taken out of context, might seem to indicate otherwise.

2) No CA on the Internet makes a DER mistake (thanks, hadn't thought of
that), since most RP applications do blob comparison

3) None of the "gang of 100" trust anchors have yet been observed
issuing a DN or other name that had previously been issued by a
different CA to a different organizational entity.  But with sufficient
monetary or other motivation, this might not always hold true in the
future.

4) All RP applications on the Internet appropriately manage their trust
anchors

5) All cross-certificates on the Internet include comprehensive name
constraints

6) ... yada yada yada

BUT:
> ideally subject identity from the certificate is used for access
control decision.
  --- and ---
> It would be better to base authorization decision on the certificate
or certificate hash as opposed to series of names in a trust path.  It
is more agile and flexible.

That is precisely my point (and Tim's, if I may be so bold).

* Using subject names requires everything to work perfectly, and the
mitigation for some potential errors is to base authorization on a full
path of names - absurdly cumbersome.

* Using cert or cert hash for authorization requires all subject
attributes and RP access lists/rules to be rebuilt every time a cert is
reissued.  Also cumbersome.

If there were no alternatives, this whole discussion would just be
noise. But both of these problems can be avoided by using
cryptographically-unique static-across-reissue subject names bound to a
specific PKI/trust anchor.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Santosh Chokhani
Sent: Tuesday, March 15, 2011 10:11 AM
To: Miller, Timothy J.
Cc: pkix
Subject: Re: [pkix] PKIX review on draft-ietf-hip-cert-11

Tim,

The lack of ambiguity in DN could also impose the requirement to
properly consider how SET is encoded in DER.

As to the other point, now that you have explained what you mean,
authentication and authorization decisions are two sequential decisions.
You authenticate an identity.  If you are using public key technology,
ideally subject identity from the certificate (after using a secure
authentication protocol, e..g, client authentication aspect of TLS) is
used for access control decision.  That could be DN, something in SAN,
hash of certificate or public key.  I do not want come across as
lecturing you and bore others, each of these have their pros and cons.

Now, certification path validation is to be done per Section 10 of X.509
or per Section 6 of 5280.  That starts with trust anchor(s) and takes
policies and name constraints etc. into consideration.

We have lately refined the concept of constraining the trust anchor as
well.

Now to authorization.  It would be better to base authorization decision
on the certificate or certificate hash as opposed to series of names in
a trust path.  It is more agile and flexible.

-----Original Message-----
From: Miller, Timothy J. [mailto:[email-masked]]
Sent: Tuesday, March 15, 2011 9:10 AM
To: Santosh Chokhani
Cc: David A. Cooper; pkix
Subject: Re: [pkix] PKIX review on draft-ietf-hip-cert-11

> Also, what do you mean by phrases "not aware" and "trust path issues"?

The point is the DNs alone are insufficient for an authorization
decision.
At least the chain and the trust anchor must be included in the
calculation (ideally the policy too).  As a result, PK-enabled
applications must implement trust lists of one sort or another.  This is
the only way to properly constrain namespaces in *all* use cases and
resolve David's objection--which I currently understand as "the
intentional collision of DNs between different PKIs."

-- T

---

From: "Miller, Timothy J." <[email-masked]>
Date: Wed, 16 Mar 2011 09:43:14 -0400

> That is precisely my point (and Tim's, if I may be so bold).

You may.  :)

> specific PKI/trust anchor.

There are other alternatives.  Key hierarchies with delegation would remove much of the cumbersomeness (is that a word?) of maintaining a strictly key-based identity system.  In such schemes, users hold a long-lived key that is *only* used to sign delegation certifications (and revocations) for other, shorter-lived keys; these shorter-lived keys are used for authentication purposes.  SPKI/SDSI (explicitly) and RFC3820 proxy certs (implicitly) implement this kind of scheme.

Alternatively, key-based identity management challenges can be addressed through the use of a trusted third party model.  A TTP model leverages centralized management of key-based identities, reducing the number of places where a user would have to register a key-rollover event.  Obviously this applies best in closed environments, but there are possibilities in the open systems world too.  Web-based systems are headed this way through the various Federation standards.

No scheme is without challenges, however.   Key hierarchies with delegation have the problems of trying to find paths through the morass of delegation and revocation certs that inevitably accrue--or more fundamentally, just *finding* all the necessary delegation statements can be a challenge--and then there's the problem of expressing and constraining delegated authorizations in a universally safe way.  OTOH, TTPs (like Kerberos KDCs before them) are high-value targets and will be expensive to build, secure, and maintain over the long term, and present challenges such as securely binding the TTP attestation to the authenticated client so as to prevent attestation theft and/or replay attacks.

-- Tim

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 16 Mar 2011 14:35:35 -0400

Dave,

How you propose to do it?

-----Original Message-----
From: Kemp, David P. [mailto:[email-masked]] 
Sent: Wednesday, March 16, 2011 8:55 AM
To: Santosh Chokhani; Miller, Timothy J.
Cc: pkix
Subject: Unique IDs (RE: [pkix] PKIX review on draft-ietf-hip-cert-11)

Santosh,

6) ... yada yada yada

control decision.
  --- and ---

Dave

-----Original Message-----

Tim,

-----Original Message-----
From: Miller, Timothy J. [mailto:[email-masked]]
Sent: Tuesday, March 15, 2011 9:10 AM
To: Santosh Chokhani
Cc: David A. Cooper; pkix
Subject: Re: [pkix] PKIX review on draft-ietf-hip-cert-11

-- T

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Mar 2011 16:14:51 -0400

Henry,

If one trusts the embedded TAs in browsers to do a good job, then there
are many ways of reducing the likelihood of a Subject name collision. Your
comment re the cert serial number seems relevant only if the goal is 
to have an RP cache some info from a cert and use it to verify some 
for of continuity, not
as a basic authentication/identification mechanism.

You have not provided a threat model against which to evaluate a specific
proposal, so it's hard to say what is good enough.

Steve

---

From: "Henry B. Hotz" <[email-masked]>
Date: Sun, 20 Mar 2011 19:21:05 -0700

On Mar 17, 2011, at 1:14 PM, Stephen Kent wrote:

> Henry,
> 
> If one trusts the embedded TAs in browsers to do a good job, then there are many ways of reducing the likelihood of a Subject name collision. Your comment re the cert serial number seems relevant only if the goal is to have an RP cache some info from a cert and use it to verify some for of continuity, not as a basic authentication/identification mechanism.
> 
> You have not provided a threat model against which to evaluate a specific proposal, so it's hard to say what is good enough.

Well, I thought I was striking the right balance of specificity and generality, but obviously not.  If you go back a few posts, I was relatively specific about it being a bad idea to use the entire global list of CAs when validating the EE cert on a smart card for workstation login.

Taking that cert-on-a-card example, there's probably only 1 or 2 CAs that can legitimately sign such a cert for a given workstation.  The EE cert-on-a-card for a specific account could be safely identified by the Subject Name, serial number, and the entire trust chain.  Identifying the EE cert-on-a-card with only the Subject Name and serial number is unsafe.  (I don't need to explain why I believe that, do I?)

What I was trying to poke at was whether there exists any middle ground that didn't need the entire trust chain, but was still "secure" for some middle ground of "secure" that's usefully better than the default web site verification.

Still too fuzzy?  Or do I really need to specify the exact intended application and threat model to have a useful discussion?  (It's OK to say "yes".)

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Mar 2011 15:09:29 -0400

At 7:21 PM -0700 3/20/11, Henry B. Hotz wrote:
>>  If one trusts the embedded TAs in browsers to do a good job, then 
>>there are many ways of reducing the likelihood of a Subject name 
>>collision. Your comment re the cert serial number seems relevant 
>>only if the goal is to have an RP cache some info from a cert and 
>>use it to verify some for of continuity, not as a basic 
>>authentication/identification mechanism.
>>
>>  You have not provided a threat model against which to evaluate a 
>>specific proposal, so it's hard to say what is good enough.
>
>Well, I thought I was striking the right balance of specificity and 
>generality, but obviously not.  If you go back a few posts, I was 
>relatively specific about it being a bad idea to use the entire 
>global list of CAs when validating the EE cert on a smart card for 
>workstation login.

I agree with that observation.

>Taking that cert-on-a-card example, there's probably only 1 or 2 CAs 
>that can legitimately sign such a cert for a given workstation.  The 
>EE cert-on-a-card for a specific account could be safely identified 
>by the Subject Name, serial number, and the entire trust chain. 
>Identifying the EE cert-on-a-card with only the Subject Name and 
>serial number is unsafe.  (I don't need to explain why I believe 
>that, do I?)

no need to explain.

>What I was trying to poke at was whether there exists any middle 
>ground that didn't need the entire trust chain, but was still 
>"secure" for some middle ground of "secure" that's usefully better 
>than the default web site verification.
>
>Still too fuzzy?  Or do I really need to specify the exact intended 
>application and threat model to have a useful discussion?  (It's OK 
>to say "yes".)

the problem is that IF you believe that one or more of the implicitly trusted
TAs in a browser MAY be malicious, or that a CA under one of the TAs 
(one or more tiers down) MAY be malicious, then no choice of name for 
the EE (or its CA), protects you from these attackers. Only if you 
nail down the entire path to a specific TA (or set of TAs) can you be 
secure.

Steve

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 21 Mar 2011 13:39:48 -0700

> nail down the entire path to a specific TA (or set of TAs) can you be 

Fundamental difference between trusting a well-defined chain and trusting a chain that ends in a professional/legal certification.  OK.  

I'm willing to trust certifications to varying degrees depending on the specific application, but I think that makes the issue off-topic for this list.  (I can still say I'm frustrated, right?)

---

From: Stephen Kent <[email-masked]>
Date: Mon, 21 Mar 2011 17:03:06 -0400

>...
>
>Fundamental difference between trusting a well-defined chain and 
>trusting a chain that ends in a professional/legal certification. 
>OK.

unfortunately, the qualifiers "professional" and "legal" are not 
synonymous with "trustworthy." If Lybia controlled a TA configured in 
your browser, I'm sure it
would be considered a legal representative of the sovereign 
government at the time it was installed, and might even be operated 
in a professional manner, yet ...

>I'm willing to trust certifications to varying degrees depending on 
>the specific application, but I think that makes the issue off-topic 
>for this list.  (I can still say I'm frustrated, right?)

yes, you may :-).

Steve

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 22 Mar 2011 15:28:27 +1100

Henry,

> Taking that cert-on-a-card example, there's probably only 1 or 2 CAs that can legitimately sign such a cert for a given workstation.  The EE cert-on-a-card for a specific account could be safely id…

Please do explain.
If you have already limited the roots that are trusted in this context to 1 or 2 CAs then identifying the account using only the subject name sounds great (as long as the subject name isn't simply unverified user input).

> safely identified by the Subject Name, serial number, and the entire trust chain

Subject Name does not add anything here. (Certificate) serial number and (issuer DNs of) the entire trust chain is unambiguous without Subject Name.
Subject Name will certainly be more user-friendly for administrators looking at lists of account ids -- but if Subject Name alone is unsafe you better exclude it otherwise admins will rely on it alone since the rest of the list (eg certificate serial numbers) are meaningless to people.

--
James Manger

---

From: "David A. Cooper" <[email-masked]>
Date: Tue, 22 Mar 2011 11:08:31 -0400

Henry,

I agree with James that there is some information missing.  One cannot 
reasonably make a blanket statement that identifying the EE with only 
the subject name is unsafe.  When you connect to a TLS protected web 
site, after validating that the server's EE certificate validates to one 
of your trusted roots, don't you simply verify that the subject name in 
the EE certificate corresponds to the DNS name in the server's URL?  I 
don't think there are many people who would insist that the server could 
only be identified by specifying the name of every CA in the 
certification path used to validate the EE certificate.  Would it be 
safer to identify the server by not only the subject name but also the 
issuer DN in every certificate in the path?  Only if you had some 
out-of-band means of knowing from which CA the server obtained its TLS 
certificate and only if this out-of-band knowledge were more reliable 
than the identification processes that the CAs in your trusted 
certificate store used to identity site owners.

So, the first question is how are you going to identify account 
holders?  If you were relying on the CAs to perform their job of 
identifying certificate subjects, then subject name would be sufficient 
(just as people typically do with TLS).  Since it appears that you don't 
trust the CAs that are issuing the certificates, I assume that you 
intend to identify and authenticate the account holders by some other 
means and then link their certificates to their accounts so that they 
can subsequently perform certificate-based authentication.  The next 
question then is do you expect to re-authenticate account holders each 
time they obtain a new certificate (perhaps every 1 to 3 years) or do 
you expect the certificate renewal process to be relatively seamless 
with your system being able to recognize that a newly issued certificate 
was issued to the same individual as a previously issued certificate 
that is currently linked to an account?

If you are going to your own identification and authentication of an 
account holder each time that account holder obtains a new certificate, 
then you might as well just link the account to a hash of the account 
holder's EE certificate.  If your goal if for certificate renewal to be 
a seamless process, then the approach that you are taking may not work 
as well as you are hoping.  To explain why, I'll use a couple of 
examples from the Federal PKI to illustrate.

In order to avoid performing identification and authentication all over 
again each time an account holder obtains a new certificate, there needs 
to be a stable identifier (one that remains unchanged across certificate 
issuances) that you are willing to trust.  The subject name in the 
certificate is quite likely to be a stable identifier, but it appears 
that you don't want to use this since you don't have any trust in the 
CAs that issue the certificates that you wish to accept.  The problem is 
that the subject name may be the only available stable identifier.

Even in a relatively simple PKI, you can't rely on "the entire trust 
chain" to be a stable identifier.  For example, if you look at one part 
of the DoD PKI in isolation, it is a simple two-level hierarchical PKI, 
with a root CA and several subordinate CAs that issue the end entity 
certificates.  The "problem" is that new subordinate CAs are constantly 
being introduced and old subordinate CAs are being taken out of service 
as they reach the ends of their lifetimes.  So, when a card holder is 
issued a new certificate, there is a near guarantee that the new 
certificate will be issued by a different subordinate CA than the card 
holder's previously issued certificate.  So, if you insisted on 
identifying the card holder by the subject name AND "the issuer DNs of 
every CA in the trust chain", then you couldn't easily link the new 
certificate to the account unless you applied domain-specific knowledge 
in order to perform a "fuzzy" matching of issuer DNs in the validated 
certification path to the issuer DNs linked to the account.  My guess is 
that this is not DoD specific and that with commercial providers as well 
one cannot simply assume that every time an individual obtains a new 
certificate that the certificate will be issued by the same CA as the 
previous certificate.

In a more complicated environment, the problems would only get worse.  
For example, the Federal PKI is in the middle of a reorganization at the 
moment.  A new root CA (the U.S. Federal Common Policy Root CA) and a 
new Federal Bridge CA are being established and the old root and bridge 
CAs are going to be retired.  Many other CAs are also being updated 
during this reorganization.  I won't go into the details of the 
reorganization, but the point is that while any EE certificate that was 
valid before the reorganization began will continue to be valid after 
the reorganization (modulo any certificates that happen to expire or are 
revoked during while the reorganization is happening) the certification 
paths used to validate the certificates will change.  So, if a system 
insisted on identifying subscribers within the Federal PKI using "the 
entire trust chain" and not just the EE certificate, then the entry for 
every subscriber would need to be changed to account for the sudden 
change in the certification path needed to validate the certificates.

So, there are definitely some unanswered questions.  You say that you 
are willing to trust the certifications to some degree, but it's not 
clear what information in the certificates you are willing to trust and 
what information you intend to independently verify or what you consider 
to be a reasonable trade-off between the risks of accepting the 
information provided by the CAs versus the costs associated with having 
to independently verify (and periodically re-verify) that information.

Dave

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 22 Mar 2011 09:41:24 -0700

> If you have already limited the roots that are trusted in this context to 1 or 2 CAs then identifying the account using only the subject name sounds great (as long as the subject name isn't simply…

The example I chose was specifically intended to be an opposite extreme from the usual "alien" web site which the whole certification process is intended to address.  For my example, first the EE cert is a client (not a server), and second the EE cert and the workstation are both under the control of the same enterprise.  In this case, if a presented EE cert matches the identity of a legitimate user of the workstation, but traces to a top-level CA other than the enterprise's own it does not mean the cert is valid for login.  Rather it means that the non-enterprise CA is violating their CPS, is supporting a hostile breakin attempt, and their certification should be revoked!

Since CAs may be subject to legal coercion by their host governments, this is not a far-fetched scenario. (Though I hope NASA is less of a target than DoD.)  In any case it would be foolish to allow that attack on a workstation.

> Subject Name will certainly be more user-friendly for administrators looking at lists of account ids -- but if Subject Name alone is unsafe you better exclude it otherwise admins will rely on it al…

Given a way for an admin to look up what Subject Name that a serial number has, I generally agree.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 22 Mar 2011 09:55:38 -0700

On Mar 22, 2011, at 8:08 AM, David A. Cooper wrote:

> the subject name is unsafe

I hope I didn't say anything so blanket as that.

I agree with Stephen's observation that there is a fundamental difference between tracing to an actually-known and known-valid-for-the-application CA on the one hand, and tracing to a generally-certified-and-trusted CA.

I absolutely agree that there are a lot of headaches associated with administering the former vice the latter case.  It happens to be necessary for some applications, not for others, and the real world has a lot of intermediate cases as well.

---

From: Piyush <[email-masked]>
Date: Tue, 22 Mar 2011 10:30:16 -0700

> Well, I thought I was striking the right balance of specificity and
generality,
> but obviously not.  If you go back a few posts, I was relatively specific
about it
> being a bad idea to use the entire global list of CAs when validating the
EE
> cert on a smart card for workstation login.
> 
True. And I doubt that any domain controllers out there trust the global
list of CAs to validate a cert used for desktop logon.

> Taking that cert-on-a-card example, there's probably only 1 or 2 CAs that
can
> legitimately sign such a cert for a given workstation.  The EE
cert-on-a-card
> for a specific account could be safely identified by the Subject Name,
serial
> number, and the entire trust chain.  Identifying the EE cert-on-a-card
with
> only the Subject Name and serial number is unsafe.  (I don't need to
explain
> why I believe that, do I?)

Not necessarily true. The chain can change, as long as it ends at a TA that
you trust for this purpose. 
> 
> What I was trying to poke at was whether there exists any middle ground
> that didn't need the entire trust chain, but was still "secure" for some
middle
> ground of "secure" that's usefully better than the default web site
> verification.
> 

There are quite a few commercial applications that allow you to trust an EE
certificate directly. There are others where you can specify an intermediate
CA as your trust anchor. However, more often than not, this leads to
unforeseen operational, manageability and interoperability issues. 

The 'middle ground' that you talk about would still need a TA. It'll
probably help if you can categorize the purposes for certificates can be
used.
For example you can say that the applications that will be enabled for
certificate access are desktop logon, server authorization (for http
servers) and signed emails. Now you can define your validation policies for
each of these categories of application. 
-Desktop logon certificate should chain up to TA1 and TA2 and hardware cert
policy should be enforced on the chain by inhibiting policy mapping
-web server certs can chain to any global root CAs (default browser CA list)
and must have the server authentication key usage
-Email certs should chain up to TA3 and the email address in the cert must
be a nasa.gov address.

While evaluating each of these policies you would still need to build a
chain to a trust anchor that is approved for that purpose.
 
> Still too fuzzy?  Or do I really need to specify the exact intended
application
> and threat model to have a useful discussion?  (It's OK to say "yes".)

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 22 Mar 2011 10:51:05 -0700

On Mar 22, 2011, at 10:30 AM, Piyush wrote:

>> Well, I thought I was striking the right balance of specificity and generality,
>> but obviously not.  If you go back a few posts, I was relatively specific about it
>> being a bad idea to use the entire global list of CAs when validating the EE

While Microsoft may get it right, there is at least one vendor that gets it wrong.  This list is about standards and interoperability, so the on-topic question is what the standards do or should say on the subject.  

I think we've covered what they do say.  I also think there is room for proposals about what else they should say and if you can use your (other) comments as a starting point for that I wish you well.

---

From: "Miller, Timothy J." <[email-masked]>
Date: Tue, 22 Mar 2011 15:30:13 -0400

On Mar 22, 2011, at 10:08 AM, David A. Cooper wrote:

> the EE certificate corresponds to the DNS name in the server's URL?  

Yes your browser does, but this blinds you to site certificate changes.  Cert change is potentially a security critical event.  E.g., if Paypal's site cert changes from an EV-issuer (currently they're using Verisign's EV issuer) to a non-EV-issuer (say, Bob's Certificate Shoppe), I *certainly* want to know it.  Because the the TLS name consistency check is insufficient in this case, EV-compliant browsers are required to indicate this kind of change to the user.

Note that Marlinspike's attacks against browser PKI implementations all revolve about *fooling* the TLS name consistency check (inserting \0 into the Subject CN was particularly inspired, IMHO).  

> 											Would it be 

Not necessarily.  We tend to forget that *consistency over time* is a security input.  The longer an EE uses a particular cert, the more sure of that identity I can be.

-- Tim