Re: [pkix] [x500standard] Re: Unclear public-key certificate definition in X.509

["Erik Andersen" <[e-mail]>]

Hi Denis

Thanks for your comments. 

 

There has been several suggestions to remove the concept of alternative
distinguished name (name with context). I have produced a proposal for the
necessary text changes to remove that concept. I have for a long time been
aware that alterative distinguished names do fit well into the X.509
concepts.

 

The note, to which you are referring, should just be deleted. 

 

Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: [phone]

e-amail: [e-mail]

Skype: andersen-erik

 <http://www.x500.eu/> http://www.x500.eu/

 <http://www.x500standard.com/> http://www.x500standard.com/

 <http://dk.linkedin.com/in/andersenerik>
http://dk.linkedin.com/in/andersenerik

 

Fra: [e-mail]
[mailto:[e-mail]] På vegne af [e-mail]
Sendt: 1. december 2011 16:55
Til: Erik Andersen
Cc: 'PKIX'; [e-mail]; SG17-Q11; Directory list
Emne: [x500standard] Re: [pkix] Unclear public-key certificate definition in
X.509

 

Erik and Kyle, 

Erik, you said: 

" I am completely aware that X.509 has a life outside directory, (...) 
as to distinguished name, it seems too late to change that ". 

It is never too late. 

X.509 does not define what a DN is. 

ITU-T Rec. X.501 (11/2008), alias  ISO/IEC 9594-2:2008, defines it only in
the context of a DIT 

9.1.3 distinguished name (of an entry): Every object entry, alias entry, and
subentry has at least one distinguished name. 
If any RDN for the entry or any superior entry includes an attribute for
which there exist multiple distinguished 
values differentiated by context (as described in 9.3), then the entry shall
have multiple distinguished names 
differentiated by context. The  primary distinguished name is that
distinguished name in which each RDN has the 
primary distinguished value of each contributing attribute as the main value
in the RDN construct. 

Furthermore, X.509 includes inappropriate sentences like: 
"Although the CAs are unambiguously defined by a distinguished name in the
DIT, .." 

It is the time to allow the existence of X.509 without using a Directory. 

----------------------------------------------------------------------------
----------------------------------------------------------------------------
- 
Kyle, you said: : 

"Unfortunately, the original designers appear to have not thought about what
would happen if you had a DN collision with multiple certificates and keys".


I would rather say: "The original designers appear to have not given
sufficient information about what
would happen if you had a DN collision". 

The reality as that a DN name is only unique for the CA which has issued it.

This statement is valid for the next upper the CA, and until a root CA is
reached. 
This means that only the sequence of DN is unique for a given trust anchor. 

In order to avoid any name collision when DN are used for access control
purposes, in the most general case
the structure of name placed in an ACL should start with a trust anchor and
be followed by a sequence of DNs. 

When  there is a single trust anchor, the first element may be omitted, 
... but only as long as there is not a second trust anchor later on. 

When there is a single certification path under that single trust anchor,
the intermediate DNs of the CAs may be omitted, 
... but only as long as there is not a second certification path below that
trust anchor. 

This guidance is not given anywhere. 

Denis 

============================================================================
============= 
Hi Kyle,

This is an important discussion.

I am completely aware that X.509 has a life outside directory, although
directories, especially LDAP systems, are often used for holding the
different PKI components. In my effort to modernize X.509, I am trying to
remove references to directory where it is not necessary. The main directory
content is the schema information (attribute types, object classes and
matching rules) for holding and accessing PKI/PMI components.

As to distinguished name, it seems too late to change that. It is part of
many profiles and also of RFC 5280.

I do not believe that it would be wise to separate the content of X.509 into
two different documents. X.509 is well established and well known. Putting
the non-directory stuff into a separate document will cause confusion and
many references will have to changed.

(ASN.1 was never part of X.500, but of X.400 (1984), and it was separated
quite early.)

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: [phone]
e-amail: [e-mail]
Skype: andersen-erik
 <http://www.x500.eu/> http://www.x500.eu/
 <http://www.x500standard.com/> http://www.x500standard.com/
 <http://dk.linkedin.com/in/andersenerik>
http://dk.linkedin.com/in/andersenerik

-----Oprindelig meddelelse-----
Fra: Kyle Hamilton [ <mailto:[e-mail]> mailto:[e-mail]] 
Sendt: 1. december 2011 03:43
Til: Tom Gindin
Cc: Erik Andersen; PKIX
Emne: Re: [pkix] Unclear public-key certificate definition in X.509



On Fri, Nov 12, 2010 at 4:38 PM, Tom Gindin <[e-mail]> wrote: 

>        It no longer has the problem which it had before.  Of course, it's
> a little odd to describe a certificate as a function of specifically the
> DN of the issuer, since the critical functional dependency is on the
> issuer's key pair.

The original X.509 use-case was that the Directory was everything, that
everything could be Distinguishably Named, and that the Distinguished Name
was the correct indexing system.  The problem is that the original designers
hadn't had the experience of a decade of nearly universal worldwide
deployment, with the format being extended into realms it was never intended
to go.

Perhaps X.509 could be formally decoupled from X.500, or (much like ASN.1)
the data format and semantics could be moved to a different standard while
the DIT bindings remain in X.509.

> The CA(A) expression just confuses me, because it suggests that the CA is
> a function of the subject name.

Unfortunately, the original designers appear to have not thought about what
would happen if you had a DN collision with multiple certificates and keys.

The key to the lock is unique, which means that it also meets the
requirement to be a database key.  The key is the key; the binding and all
the rest is just metadata.

-Kyle H