RE: X.509 certificate and its subject name field

[Hal Lockhart <hal@xxxxxxxxxxx>]

At 10:13 AM 6/5/97 -0400, Sharon Boeyen wrote:

>Next issue I'd like to clarify is the requirement for uniqueness of
>names, regardless of certificates or access control. X.501 states that a
>name is a construct that identifies a particular 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 an object.  As an example of what is meant
>here, my work name might be c=CA; o=Entrust Technologies; cn=Sharon
>Boeyen while my name as part of a different group (e.g. if I was a
>student taking evening courses) would be very different, however both
>identify me.  These names are supposed to be unambiguous among the set
>of ALL objects and therefore meet any requirements I've seen discussed
>on this list for what is being called "uniqueness".  It is up to the
>naming authority (not necessarily the same entity as the CA) to ensure
>this unambiguous property. 

This is the notion I was trying to get at. I think the spec should say this
explicitly.

>When you tie the requirement for unambiguous names to that which a PKI
>has  for the non-reuse of a name, adding a numeric identifier as part of
>the terminal RDN can satisfy both requirements as well as addressing any
>concerns over rogue CAs or naming authorities duplicating names.

I don't see how any scheme can prevent a rogue CA from creating a
certificate containing arbitrary contents and signing it.  I think this
problem can only be dealt with by market and legal mechanisms (don't honor
their certificates, sue them) and should be dropped from this discussion.
Inadvertent duplication is another matter.

>I still see this as a simpler way to address the problem that by
>combining any two fields together. I see a trend in companies toward DNs
>which have fewer rather than more RDNs in them. This reduces the
>frequency of DN changes due to organizational changes and also appears
>to make directory and database searching more efficient. Multi-valued
>RDNs support this 'short DN' approach and, with a serial number type
>component, can ensure that DNs (the full DN) are never re-used. All this
>can be accomplished in a single structure (the DN) and surely this is
>easier to match against than using multiple fields of a certificate. 

Well, in Peter Gutmann's excellent X.509 Style Guide, he specifically says
multi-value RDNs should *not* be used, citing LDAP support and encoding
issues as reasons. However, at the end of the section he does say
"Everything will probably break when you move to LDAP anyway."

Comments from Peter? others?

>I've seen nothing to convince me that use of the subjectUID or issuerUID
>fields provide any added value and to the contrary I think their use
>overcomplicates matters when matching on a single piece of data (the DN)
>can achieve the same thing.

It depends on whether you just want to unambigiously identify the subject,
or you would like extra semantics, such as stability over time.

If you want the latter, then you must either use an additional field or
precisely define what element(s) in the name carries this semantic.  As I
understand the pro-subjectUID view, the additional field is prefered because
a) it is not related to the DIT and b) specifying naming schemes is the
"third rail" of standardization efforts. (Touch it and you die. ;-)

Hal
=================================================================
Harold W. Lockhart Jr.            PLATINUM technology, Inc.
Chief Technical Architect         8 New England Executive Park
Email: hal@platsol.com            Burlington, MA 01803 USA
Voice: (617)273-6406              Fax: (617)229-2969
=================================================================