Subject: RE: 3280bis: CRL validation

From: "Stefan Santesson" <[email-masked]>
Date: Wed, 22 Jun 2005 16:08:09 +0100

Sharon,

Thank you very much for the insights from all of those meetings where I
certainly didn't appear.

I also appreciate that you acknowledge the reality of life.

I can only refer to what I find in what became the standard, and to me
this is not clearly spelled out unambiguously in X.501 but I gratefully
accept input on my interpretation from those who can find better
references.

I agree that X.501 sets up its structure so that a DN is formed with the
intention to provide a globally unique name.

But that is not the same as mandating that it actually happens.

But preserving this intent of globally unambiguous naming is a good
thing.

So I don't think we are talking about changing the standard in its
concept of DNs. At least I'm not proposing that.

What I think we must do is to recognize the fact that the X.501 concept
is insufficient to guarantee implementers, who do their best to
implement the standards, that name reuse won't happen.

A consequence of this, and probably the only consequence of this, is
that security should not ONLY rely on name comparison of loosely related
entities.

The only place this is allowed, to my knowledge, is for indirect CRLs
where we today might accept any CRL with a matching CRL issuer name as
long as it can be supported by a trusted path.

Recognition of this fact is to me part of good security design.

Stefan Santesson 
Program Manager, Standards Liaison 
Windows Security 

________________________________

From: Sharon Boeyen [mailto:[email-masked]] 
Sent: den 22 juni 2005 16:04
To: Stefan Santesson; Sharon Boeyen; Denis Pinkas; David A. Cooper
Cc: pkix
Subject: RE: 3280bis: CRL validation

Hi Stefan,

The "of interest" type wording is, I believe, meant to indicate that not
all objects will end up being in the Directory. That doesn't mean that
their DNs don't still need to be unambiguous. 

My firm belief, and this is from sitting in X.500 meetings from 1987
until about 2003 (many discussions I chaired), and listening to the
heated debates and the conclusions of those meetings, is that the intent
of DNs is that they unambiguously name objects regardless of whether or
not those objects ever appear in "the" Directory. As mentioned by David,
there have been several attempts, primarily by Denis, to have X.509/501
change this intent to make DNs unambiguous within the namespace that a
single CA issues certificates. Those attempts have consistently failed. 

One thing we did try to do in X.509 in the 4th editions was to try to
make it a standalone document and reduce its dependencies on the other
parts of the X.500 series so that people who wanted to implement X.509
but not the directory would not have to use the whole set of documents.
We succeeded in some cases (e.g. moved attributes and object classes
from X.520 and X.521 for example) but the successes were limited to
topics that affected X.509 and not general directory implementations.
The concept of DNs and that of matching for DNs is one that is very
central to BOTH X.509 and general X.500 directory services and therefore
it had to stay in X.501. We considered duplicating text and removing the
directory references for X.509 but that would have been too difficult to
do and to maintain. So we're left with X.501 which needs to include the
directory wording for those implementers. However I (and many others in
those meetings)I thought the text was clear enough to separate the two.
Obviously others feel differently.

However, regardless of that, it is true that the corresponding standards
for name registration that ITU and ISO approved have not been
universally adopted. Had they been, we'd have had a solid integrated
registration system that would have ensured DNs were exactly that
(globally unambiguous names for objects). A few countries did set up
registration authorities but the fees were at least one reason they
didn't get a lot of business. Note that in Canada the service is free
and is still not getting a lot of business. dc-based DNs are another way
to drive the unambiguous requirement, but they are not universally
adopted either. So regardless of whether or not one believes X.509
assumes unambiguous DNs (again as ex-editor and chair of the X.509
debates from 1993 - 2003 I'd like to assure you that was the intent),
there is a real world possibility that two entities may end up using the
same DN, primarily because of the failure to set up comprehensive and
effective registration authorities for DNs as well as use by rogue
entitles. Understanding that such an unintended situation might occur
accidentally or through the efforts of a rogue entity, is certainly very
different from rewriting a standard to allow it to occur as a normal
situation. 

Cheers,

Sharon

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, June 21, 2005 8:59 PM
To: Sharon Boeyen; Denis Pinkas; David A. Cooper
Cc: pkix
Subject: RE: 3280bis: CRL validation

	Sharon,

	I fairness I don't think anything has been shown until my last
comments and quotes from X.501 has been responded to.

	Let me therefore expand on this (hopefully for the last time).

	What seems to cause confusion is in particular the following
quote:

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

	What we need to understand is what the context is, in which the
term "object" is to be understood.

	Does this refer to objects in a defined context (such as objects
of a directory) or does this mean all possible objects in the world we
know?

	X.501 in my reading suggests the former and I would like to
suggest 3 quotes to support that:

	1) The introduction of X.501 which sets the context of the
standard and defines "the directory"

	"This Recommendation | International Standard, together with the
other Recommendations | International Standards, has been produced to
facilitate the interconnection of information processing systems to
provide directory services. A set of such systems, together with the
directory information that they hold, can be viewed as an integrated
whole, called the Directory."

	This sets the context of the standard and states that "the
Directory" is just "a set of such systems", which not at all is the same
as the whole world.

	2) The section defining the concept of objects (section 7.2)
starts:

	"The purpose of the Directory is to hold, and provide access to,
information about objects of interest (objects) which exist in some
'world'. An object can be anything in that world which is identifiable
(can be named)."

	This clearly states that objects in the context of this standard
is limited to "objects of interest" that reflect "some 'world'", not all
possible objects and not the entire world.

	3)  Section 9.2 finally sets naming of objects to be tied to the
context of the directory.

	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.

	Conclusion:

	If we recognize "the directory" as one of many possible
directory systems, and recognize that each directory system (reflected
in a real directory or just as a virtual DIT) can be served by one or
more valid CAs who issues certificates in support of that system, then
all quotes presented so far are compatible with the fact that 2
unrelated and compliant CAs may assign the same DN to different subjects

	Neither X.509, nor RFC 3280 states that all CAs in the world
MUST support a common directory (a common DIT).

	This is also in line with how in fact the real world works and
that is hard to neglect.

	Stefan Santesson 
	Program Manager, Standards Liaison 
	Windows Security 

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sharon Boeyen
	Sent: den 21 juni 2005 19:59
	To: 'Denis Pinkas'; David A. Cooper
	Cc: pkix
	Subject: RE: 3280bis: CRL validation

	Denis that is definitely a misinterpretation of X.509 - Full
Stop. 

	I think Dave Cooper has shown sufficient quotes to prove this
fact. What I think is true is that there does not exist a single
authority globally to ensure that DNs are unambiguous. That does not
mean the assumption isn't there in X.509 - it most definitely is. What
it does mean is that, depending on the type of DNs used and how they are
structured, it may/may not be more difficult to ensure uniqueness. It
does NOT mean name collisions should be expected.

	Cheers, 
	Sharon 

	-----Original Message----- 
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Denis Pinkas 
	Sent: Tuesday, June 21, 2005 5:33 AM 
	To: David A. Cooper 
	Cc: pkix 
	Subject: Re: 3280bis: CRL validation 

	David, 

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

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

	In X.500 there is a single "DIT", whereas in X.509 there is a
DIT per CA. Full stop. 

	Denis 

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

	Regards, 

	Denis Pinkas

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 22 Jun 2005 21:51:01 -0400

And relying on name matching for indirect CRL is part of an oversight as
opposed to a well-thought out design.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Wednesday, June 22, 2005 11:08 AM
To: Sharon Boeyen; Denis Pinkas; David A. Cooper
Cc: pkix
Subject: RE: 3280bis: CRL validation

Sharon,

I can only refer to what I find in what became the standard, and to me this
is not clearly spelled out unambiguously in X.501 but I gratefully accept
input on my interpretation from those who can find better references.

But preserving this intent of globally unambiguous naming is a good thing.

So I don't think we are talking about changing the standard in its concept
of DNs. At least I'm not proposing that.

What I think we must do is to recognize the fact that the X.501 concept is
insufficient to guarantee implementers, who do their best to implement the
standards, that name reuse won't happen.

A consequence of this, and probably the only consequence of this, is that
security should not ONLY rely on name comparison of loosely related
entities.

The only place this is allowed, to my knowledge, is for indirect CRLs where
we today might accept any CRL with a matching CRL issuer name as long as it
can be supported by a trusted path.

Stefan Santesson 

  _____  

Hi Stefan,

The "of interest" type wording is, I believe, meant to indicate that not all
objects will end up being in the Directory. That doesn't mean that their DNs
don't still need to be unambiguous. 

My firm belief, and this is from sitting in X.500 meetings from 1987 until
about 2003 (many discussions I chaired), and listening to the heated debates
and the conclusions of those meetings, is that the intent of DNs is that
they unambiguously name objects regardless of whether or not those objects
ever appear in "the" Directory. As mentioned by David, there have been
several attempts, primarily by Denis, to have X.509/501 change this intent
to make DNs unambiguous within the namespace that a single CA issues
certificates. Those attempts have consistently failed. 

One thing we did try to do in X.509 in the 4th editions was to try to make
it a standalone document and reduce its dependencies on the other parts of
the X.500 series so that people who wanted to implement X.509 but not the
directory would not have to use the whole set of documents. We succeeded in
some cases (e.g. moved attributes and object classes from X.520 and X.521
for example) but the successes were limited to topics that affected X.509
and not general directory implementations. The concept of DNs and that of
matching for DNs is one that is very central to BOTH X.509 and general X.500
directory services and therefore it had to stay in X.501. We considered
duplicating text and removing the directory references for X.509 but that
would have been too difficult to do and to maintain. So we're left with
X.501 which needs to include the directory wording for those implementers.
However I (and many others in those meetings)I thought the text was clear
enough to separate the two. Obviously others feel differently.

However, regardless of that, it is true that the corresponding standards for
name registration that ITU and ISO approved have not been universally
adopted. Had they been, we'd have had a solid integrated registration system
that would have ensured DNs were exactly that (globally unambiguous names
for objects). A few countries did set up registration authorities but the
fees were at least one reason they didn't get a lot of business. Note that
in Canada the service is free and is still not getting a lot of business.
dc-based DNs are another way to drive the unambiguous requirement, but they
are not universally adopted either. So regardless of whether or not one
believes X.509 assumes unambiguous DNs (again as ex-editor and chair of the
X.509 debates from 1993 - 2003 I'd like to assure you that was the intent),
there is a real world possibility that two entities may end up using the
same DN, primarily because of the failure to set up comprehensive and
effective registration authorities for DNs as well as use by rogue entitles.
Understanding that such an unintended situation might occur accidentally or
through the efforts of a rogue entity, is certainly very different from
rewriting a standard to allow it to occur as a normal situation. 

Cheers,

Sharon

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, June 21, 2005 8:59 PM
To: Sharon Boeyen; Denis Pinkas; David A. Cooper
Cc: pkix
Subject: RE: 3280bis: CRL validation

Sharon,

I fairness I don't think anything has been shown until my last comments and
quotes from X.501 has been responded to.

What seems to cause confusion is in particular the following quote:

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

What we need to understand is what the context is, in which the term
"object" is to be understood.

Does this refer to objects in a defined context (such as objects of a
directory) or does this mean all possible objects in the world we know?

X.501 in my reading suggests the former and I would like to suggest 3 quotes
to support that:

1) The introduction of X.501 which sets the context of the standard and
defines "the directory"

"This Recommendation | International Standard, together with the other
Recommendations | International Standards, has been produced to facilitate
the interconnection of information processing systems to provide directory
services. A set of such systems, together with the directory information
that they hold, can be viewed as an integrated whole, called the Directory."

This sets the context of the standard and states that "the Directory" is
just "a set of such systems", which not at all is the same as the whole
world.

2) The section defining the concept of objects (section 7.2) starts:

"The purpose of the Directory is to hold, and provide access to, information
about objects of interest (objects) which exist in some 'world'. An object
can be anything in that world which is identifiable (can be named)."

This clearly states that objects in the context of this standard is limited
to "objects of interest" that reflect "some 'world'", not all possible
objects and not the entire world.

3)  Section 9.2 finally sets naming of objects to be tied to the context of
the directory.

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.

Conclusion:

If we recognize "the directory" as one of many possible directory systems,
and recognize that each directory system (reflected in a real directory or
just as a virtual DIT) can be served by one or more valid CAs who issues
certificates in support of that system, then all quotes presented so far are
compatible with the fact that 2 unrelated and compliant CAs may assign the
same DN to different subjects

Neither X.509, nor RFC 3280 states that all CAs in the world MUST support a
common directory (a common DIT).

This is also in line with how in fact the real world works and that is hard
to neglect.

Stefan Santesson 

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sharon Boeyen
Sent: den 21 juni 2005 19:59
To: 'Denis Pinkas'; David A. Cooper
Cc: pkix
Subject: RE: 3280bis: CRL validation

Denis that is definitely a misinterpretation of X.509 - Full Stop. 

I think Dave Cooper has shown sufficient quotes to prove this fact. What I
think is true is that there does not exist a single authority globally to
ensure that DNs are unambiguous. That does not mean the assumption isn't
there in X.509 - it most definitely is. What it does mean is that, depending
on the type of DNs used and how they are structured, it may/may not be more
difficult to ensure uniqueness. It does NOT mean name collisions should be
expected.

Cheers, 
Sharon 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas 
Sent: Tuesday, June 21, 2005 5:33 AM 
To: David A. Cooper 
Cc: pkix 
Subject: Re: 3280bis: CRL validation 

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 

>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 

In X.500 there is a single "DIT", whereas in X.509 there is a DIT per CA.
Full stop. 

Denis 

>* The values in the alternatives of the GeneralName type are names of 
>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 
>ensures that any name used unambiguously identifies one entity to both 
>* It is recommended that, provided the subject field of the certificate 
>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 
>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 
>A name shall be unambiguous, that is, denotes just one object. However, 
>that is, be the only name that unambiguously denotes the object. A 
>entry. This entry is either an object entry that represents the object 
>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 
>but this name is then the name its object entry would have had were it 
>Syntactically, each name for an object or entry is an ordered sequence 
>Name ::= CHOICE { -- only one possibility for now -- rdnSequence 
>RDNSequence } 
> 

Regards, 

Denis Pinkas

---

From: "Laudon Williams" <[email-masked]>
Date: Wed, 22 Jun 2005 22:04:29 -0700

Well said.

Although, I would point out most sane people will design around the use of
indirect CRLs for the reasons that permeate this overly long thread.

-Laudon

  _____  

Sent: Wednesday, June 22, 2005 8:08 AM

Sharon,

Stefan Santesson 

  _____  

Hi Stefan,

Cheers,

Sharon

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: Tuesday, June 21, 2005 8:59 PM
To: Sharon Boeyen; Denis Pinkas; David A. Cooper
Cc: pkix
Subject: RE: 3280bis: CRL validation

Sharon,

 

 

 

Conclusion:

Stefan Santesson 

  _____  

Cheers, 
Sharon 

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

David, 

Denis 

Regards, 

Denis Pinkas