Subject: RE: 3280bis: CRL validation

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 17 Jun 2005 21:18:37 +0100

David,

Show me the paragraph in X.509 or RFC 3280 that says that the subject of
a compliant certificate MUST have a name that corresponds to a globally
unique entry in the DIT.

/Stefan

> -----Original Message-----
> From: David Chadwick [mailto:[email-masked]]
> Sent: den 17 juni 2005 17:56
> To: Stefan Santesson
> Cc: Manger, James H; pkix
> Subject: Re: 3280bis: CRL validation
> 
> Stefan
> 
> Stefan Santesson wrote:
> > X.509 is just a technical standard and not a legal directive.
> > Any CA can use the X.509 standard to practically choose any way it
wants
> > to name its subjects.
> >
> 
> I hate to say it, but this sounds like Microsoft's typical cavalier
> attitude to standards.
> 
> A conformant CA can choose any way it wants to name its subjects as
long
> as this way is conformant to the X.509 (and by reference to X.501)
> standard.
> 
> Many CA's today do not conform to X.509 naming rules.
> 
> regards
> 
> David
>

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 20 Jun 2005 16:59:00 -0400

> a compliant certificate MUST have a name that corresponds to a globally

I really don't want to get involved in a discussion about whether it was 
a wise or unwise decision for X.509 to be designed around the assumption 
that name collisions will not occur, but here are some quotes from X.509 
and X.501:

X.509, Clause 3.2 (Directory model definitions): The following terms are 
defined in ITU-T Rec. X.501 | ISO/IEC 9594-2: f) distinguished name;

X.509, Section 7 (Public-keys and public-key certificates): 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.

X.509, Clause 8.3.2.1 (Subject alternative name extension):
* The values in the alternatives of the GeneralName type are names of 
various forms as follows:
directoryName is a directory name defined in accordance with ITU-T Rec. 
X.501 | ISO/IEC 9594-2;

* 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.

* It is recommended that, provided the subject field of the certificate 
contains a directory name that
unambiguously identifies the subject, this field be flagged non-critical.

X.509, Clause 8.3.2.2 (Issuer alternative name extension): It is 
recommended that, provided the issuer field of the certificate or CRL 
contains a directory name that unambiguously identifies the issuing 
authority, this field be flagged non-critical.

X.501, Clause 9.1.4 (definitions): (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).

X.509, Clause 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. However, 
a name need not be unique,
that is, be the only name that unambiguously denotes the object. A 
(directory) name also identifies an
entry. This entry is either an object entry that represents the object 
or an alias entry which contains
information that helps the Directory to locate the entry that represents 
the object.

NOTE 1  The set of names of an object thus comprises the set of alias 
names for the object, together
with the distinguished names of the 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.

Syntactically, each name for an object or entry is an ordered sequence 
of relative distinguished names (see 9.3).

Name ::= CHOICE { -- only one possibility for now -- rdnSequence 
RDNSequence }

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

DistinguishedName ::= RDNSequence

---

From: David Chadwick <[email-masked]>
Date: Mon, 20 Jun 2005 23:53:18 +0100

David

thankyou for answering Stefan on my behalf. You have (to my mind) 
conclusively shown Stefan that X.509 distinguished names must be 
globally unambiguous.

regards

David

-- 

*****************************************************************
David W. Chadwick, BSc PhD
Professor of Information Systems Security
The Computing Laboratory, University of Kent, Canterbury, CT2 7NF
Tel: +44 1227 82 3221
Fax +44 1227 762 811
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page: http://www.cs.kent.ac.uk/people/staff/dwc8/index.html
Research Web site: http://sec.cs.kent.ac.uk
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 21 Jun 2005 07:25:10 -0400

David Chadwick,

And is that really the case when the relying party has multiple trust
anchors in its trust store?  Who is making sure of that for all the relying
parties on this world?  You? (Now, it is my turn!!!!!)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of David Chadwick
Sent: Monday, June 20, 2005 6:53 PM
To: David A. Cooper
Cc: Stefan Santesson; pkix
Subject: Re: 3280bis: CRL validation

David

regards

David

David A. Cooper wrote:
> 
> Stefan Santesson wrote:
> 
>> Show me the paragraph in X.509 or RFC 3280 that says that the subject 
>> of a compliant certificate MUST have a name that corresponds to a 
>> globally unique entry in the DIT.
> 
> 
> 
> X.509, Section 7 (Public-keys and public-key certificates): NOTE 1 -
> NOTE 1 - The set of names of an object thus comprises the set of alias

--

---

From: "Julien Stern" <[email-masked]>
Date: Tue, 21 Jun 2005 14:30:17 +0200

> parties on this world?  You? (Now, it is my turn!!!!!)

I agree with Santosh on that aspect.

And I would like to add that email adresses or IP addresses must indeed
by unique for the system to work, but the MINIMAL equivalent in X.509
would be to require that the TRUST ANCHORS DNs are unique, not the CA DNs
themselves.

Then, two paths can be taken: either the "legal" one, which is trying to
enforce the uniqueness of CA DNs by non technical means, one the
"technical" one, which would be to try to distinguish between two
identical DNs by looking at the "context" where they are used
(essentially their hierarchy).

While I humbly disagree with Santosh proposal and would more be in favor
of an OCSP style delegation as soon as the same key is not used to
certificate and CRL signing, I believe it is definitely POSSIBLE to have
a secure system with a much smaller assumption than the uniqueness of CA
DNs, namely the assumptions of

- Uniqueness of TRUST ANCHORS DNs
- Local uniquess of CA DNs

Sincerely,

--
Julien Stern

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 21 Jun 2005 12:57:58 -0400

Julien,

My proposal does not require the CA names to be unique.

Rather than disagreeing, please provide how you will solve the problem.

Last time we had this debate, you wanted to deal with "Rogue CA" problem
which not something we can fully solve.

I have identified a problem and provided a solution.  You need to either
demonstrate that the problem does not exist or there is a simpler or more
secure solution.

-----Original Message-----
From: Julien Stern [mailto:[email-masked]] 
Sent: Tuesday, June 21, 2005 8:30 AM
To: Santosh Chokhani
Cc: 'pkix'
Subject: Re: 3280bis: CRL validation

On Tue, Jun 21, 2005 at 07:25:10AM -0400, Santosh Chokhani wrote:
> anchors in its trust store?  Who is making sure of that for all the 
> relying parties on this world?  You? (Now, it is my turn!!!!!)

And I would like to add that email adresses or IP addresses must indeed by
unique for the system to work, but the MINIMAL equivalent in X.509 would be
to require that the TRUST ANCHORS DNs are unique, not the CA DNs themselves.

Then, two paths can be taken: either the "legal" one, which is trying to
enforce the uniqueness of CA DNs by non technical means, one the "technical"
one, which would be to try to distinguish between two identical DNs by
looking at the "context" where they are used (essentially their hierarchy).

While I humbly disagree with Santosh proposal and would more be in favor of
an OCSP style delegation as soon as the same key is not used to certificate
and CRL signing, I believe it is definitely POSSIBLE to have a secure system
with a much smaller assumption than the uniqueness of CA DNs, namely the
assumptions of

Sincerely,

--
Julien Stern

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David Chadwick

> > 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.
> > 
> > * The values in the alternatives of the GeneralName type are names 
> > of various forms as follows: directoryName is a directory name 
> > defined in accordance with ITU-T Rec. X.501 | ISO/IEC 9594-2;
> > 
> > name registration system that ensures that any name used 
> > unambiguously identifies one entity to both certificate issuer and 
> > certificate users.
> > 
> > recommended that, provided the issuer field of the certificate or 
> > CRL contains a directory name that unambiguously identifies the 
> > issuing authority, this field be flagged non-critical.
> > 
> > 
> > 
> > X.501, Clause 9.1.4 (definitions): (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).
> > 
> > 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. However, a name need 
> > not be unique, that is, be the only name that unambiguously denotes 
> > the object. A

> > the object.
> > 
> > NOTE 1 - The set of names of an object thus comprises the set of 
> > alias names for the object, together with the distinguished names of 
> > the object.
> > 
> > Syntactically, each name for an object or entry is an ordered 
> > sequence of relative distinguished names (see 9.3).
> >

---

From: "Julien Stern" <[email-masked]>
Date: Tue, 21 Jun 2005 19:44:25 +0200

> My proposal does not require the CA names to be unique.

Santosh,

I understand this. Your proposal indeed only requires the two
assumptions that I stated below, that is:

- Uniqueness of TRUST ANCHORS DNs
- Local uniquess of CA DNs (a given CA does not give the same DN
  to two different entities)

> Rather than disagreeing, please provide how you will solve the problem.

In short, if the same KEY is not used for CRL and certificate signing,
I would recommend that the CA creates a special CRL signer
certificate, most likely with a specific extension, exactly in the same
spirit as what is done in OCSP.

> which not something we can fully solve.

I believe we can fully solve the "Rogue CA" problem. To be more
specific, I believe we can limit the scope of action of the "Rogue CA"
to certificates and CRL is has itself emmited and not to certificate
and CRL emitted by other.

However, it seemed that the global consensus today is that "Rogue CA"
should be handled with "legal" matters more than scientific ones... So,
I stopped arguing on the subject... But I'll be sure to nag again if
this consensus ever changes, for example if the growing number of trust
anchors in browser makes rogue CA a reality ... :)

> demonstrate that the problem does not exist or there is a simpler or more

The problem definitely exist. And again, I believe your solution is
technically correct. However, I also believe it only prevents again
"honest mistakes" by CAs and not against "carefully crafted name
collisions to bypass security"... which actually may be enough if
one assumes that all CAs in the world are always honest and never
compromised...

Sincerely,

--
Julien

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 21 Jun 2005 15:08:39 -0400

Julien,

Thanks.  Please see responses in-line in [Santosh:].  I have deleted the
text where we agree.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Stern
Sent: Tuesday, June 21, 2005 1:44 PM
To: 'pkix'
Subject: Re: 3280bis: CRL validation

In short, if the same KEY is not used for CRL and certificate signing, I
would recommend that the CA creates a special CRL signer certificate, most
likely with a specific extension, exactly in the same spirit as what is done
in OCSP.

[Santosh: For direct CRL Signer, the above approach will require the same
logic as I have proposed for comparing the two paths or using the old path
-- which is one way of implementing my algorithm.  It will also get into the
circular problem of how to check the status of the CRL Signer Certificate.
You will not get around the problem of different paths due to key rollover.
And of course this is not backward compatible with existing
implementations.]

[Santosh: For indirect CRL, I agree and have proposed that the trust should
be limited to a  trust anchor, trust anchor delegated authority, or CA
delegation with no-check.] 

> Last time we had this debate, you wanted to deal with "Rogue CA" 
> problem which not something we can fully solve.

I believe we can fully solve the "Rogue CA" problem. To be more specific, I
believe we can limit the scope of action of the "Rogue CA" to certificates
and CRL is has itself emmited and not to certificate and CRL emitted by
other.

[Santosh: How do you do that without requiring the same key for certificate
and CRL?]

However, it seemed that the global consensus today is that "Rogue CA" should
be handled with "legal" matters more than scientific ones... So, I stopped
arguing on the subject... But I'll be sure to nag again if this consensus
ever changes, for example if the growing number of trust anchors in browser
makes rogue CA a reality ... :)

> I have identified a problem and provided a solution.  You need to 
> either demonstrate that the problem does not exist or there is a 
> simpler or more secure solution.

The problem definitely exist. And again, I believe your solution is
technically correct. However, I also believe it only prevents again "honest
mistakes" by CAs and not against "carefully crafted name collisions to
bypass security"... which actually may be enough if one assumes that all CAs
in the world are always honest and never compromised...

[Santosh: The only problem I do not solve is that of a Rogue CA that you
continue to trust.  But, that CA can cause other damage.  Also, if you have
a way of solving that problem (which not the primary concern in the first
place since if a CA goes Rogue and you trust it, it can cause variety of
harm) without requiring the same key for certificate and CRL signing, I am
all ears.]

Sincerely,

--
Julien

> And I would like to add that email adresses or IP addresses must 
> indeed by unique for the system to work, but the MINIMAL equivalent in 
> X.509 would be to require that the TRUST ANCHORS DNs are unique, not 
> the CA DNs themselves.
> 
> Then, two paths can be taken: either the "legal" one, which is trying 
> to enforce the uniqueness of CA DNs by non technical means, one the 
> While I humbly disagree with Santosh proposal and would more be in 
> favor of an OCSP style delegation as soon as the same key is not used 
> to certificate and CRL signing, I believe it is definitely POSSIBLE to 
> have a secure system with a much smaller assumption than the 
> uniqueness of CA DNs, namely the assumptions of
> 
> > > I really don't want to get involved in a discussion about whether 
> > > it was a wise or unwise decision for X.509 to be designed around 
> > > the assumption
> 
> > > X.509, Clause 3.2 (Directory model definitions): The following 
> > > terms are defined in ITU-T Rec. X.501 | ISO/IEC 9594-2: f) 
> > > distinguished name;
> > > 
> > > * It is recommended that, provided the subject field of the 
> > > certificate contains a directory name that
> > > An object can be assigned a distinguished name without being 
> > > represented by an entry in the Directory,

---

From: "Julien Stern" <[email-masked]>
Date: Wed, 22 Jun 2005 15:19:07 +0200

Santosh,

please see responses in-line in [Julien:].

Sincerely,

--
Julien

> And of course this is not backward compatible with existing

[Julien: Well, my point of view is that if the SAME entity (same
DN) signs CRL and certificates with DIFFERENT keys, that should be
considered an indirect CRL. Otherwise, we have many other problems.]

> [Santosh: How do you do that without requiring the same key for certificate

[Julien: by requiring that the CA emits a specific certificate for his
CRL signer as soon as the key is different. A CA could possibly emit a
"CRL signing certificate" to itself if it wishes to use a different key.
Revocation checking would then require that the CRL issuer certificate
is indeed emitted by the CA that emitted the certificate to be checked.]

> harm) without requiring the same key for certificate and CRL signing, I am

[Julien: We are soon to complete a short paper on how to do that. I'll
be happy to send it as soon as it is done. The rough picture is above.

However, I really think the fitness of a solution is a matter of assumptions:

Assumption 1: DN are globally unique and CA and always honest and never
              compromised

	=> The current status is OK

Assumption 2: DN are NOT globally unique and CA and always honest and never
              compromised

	=> Your solution is OK (at least for direct CRL, I have not
	   seen the details for indirect ones)

Assumption 3: DN are NOT globally unique and CA are NOT always honest
              and can be compromised

	=> We need a stronger cryptographic binding between the keys
	   in order to limit the scope of damage of a rogue CA

Assumption 4: etc, etc, etc. We can give arbitrarily high powers to
              the adversary. Usually, the weaker the assumptions are
	      the better is it, but then, I'm certainly not the one
	      who will decide of the best tradeoffs between simplifying
	      assumptions and additionnal complexity.]

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 22 Jun 2005 11:02:32 -0400

Julien,

> [Santosh: For direct CRL Signer, the above approach will require the 
> same logic as I have proposed for comparing the two paths or using the 
> old path

[Santosh2: That is not an indirect CRL.  We do not get to define our own
terms.]

[Julien: by requiring that the CA emits a specific certificate for his CRL
signer as soon as the key is different. A CA could possibly emit a "CRL
signing certificate" to itself if it wishes to use a different key.
Revocation checking would then require that the CRL issuer certificate is
indeed emitted by the CA that emitted the certificate to be checked.]

[Santosh2: You lost me. For direct CRL, can you show how rogue problem
arises?]

	=> We need a stronger cryptographic binding between the keys
	   in order to limit the scope of damage of a rogue CA
[Santosh: Do we need this for direct CRL?  Can you share your scenario with
us?]

[Santosh2: Once I see your proposal, I will be able to judge its security,
its compliance with X.509 standard, and backward compatibility.]