Subject: Re: dnQualifier

From: "David P. Kemp" <[email-masked]>
Date: Mon, 15 Nov 1999 10:37:10 -0500 (EST)

> Date: Wed, 10 Nov 1999 13:36:52 -0500
> From: schaen <[email-masked]>
> 
> The DoD has been issuing certs with a UID concatenated to the CN for the
> past 9 months.  We recognized the kludge at the time, but needed a way to
> provide unique identifiers for a very large organization in a highly
> distributed manner.  At the time, we found that many applications could
> not handle multi-attribute RDNs, and so went with the kludge.  The DoD
> will consider migrating when the standards solidify and applications
> support a standard approach.

And likewise the TRW and NIH technique of using a Static Identifier in
one RDN followed by Common Name in the terminal RDN is a kludge to work
around the non-availability of support for multi-attribute RDNs.

For current applications I think the TRW kludge is better than the DoD
kludge.

> Date: Fri, 12 Nov 1999 16:41:19 -0500
> From: "Ella P. Gardner" <[email-masked]>
> 
> I've been following with interest the discussion of the use of
> dnQualifier and was happy to see that the group had agreed to use that
> to disambiguate entities. I was also was glad to see that others support
> the use of multiple attributes to form an RDN.
> 
> In the Allied Communication Publication 133 Task Force, the group that
> makes agreements for directory support with our allies, we decided to
> use dnQualifier. We realized that the meaning in X.521 is not exactly
> what we need, but we preferred to use a standard attribute. We did not
> want to use the unique identifier for the same reason others don't - the
> bit string syntax.
> 
> So far we've been able to coordinate between PKIX documents and X.509 to
> use standard attributes. Let's use dnQualifier. If that threatens world
> peace, let's get a new definition into the X.509 FPDAM. 

For future applications with support for multi-attribute RDNs, we need
a standard way to represent the Static Identifier, an attribute such as
employee number which does *not* just disambiguate a name, it
identifies the same individual even when that individual's name
changes.  Three approaches have been suggested:

1) Use dnQualifier {id-at 46} in conjunction with a QC properties
   extension which says that in this instance the dnQualifier is a
   Static Identifier.

2) Modify the X.520 definition of dnQualifier to say that it always
   uniquely identifies a component (as opposed to the current
   definition which says only that the combination of dnQualifier and
   another attribute is unique).

3) Use a different attribute such as serialNumber {id-at 5} for the
   Static Identifier, modifying X.520 to say that serial number may
   refer to any object, not to just a "device".

Approach 3) is the cleanest because 1) applies only to QCs and requires
the presence of a certificate extension, and 2) modifies the definition
of dnQualifier in a manner that is neither backwards-compatible nor
consistent with the name "dnQualifier".

PKIX, X.520, and ACP 133 should be modified to use the RDN

  dnQualifier+commonName

in the case where only the combination of dnQualifier and commonName
uniquely identifies an entity, and to use the RDN

  serialNumber+commonName

in cases where serialNumber uniquely identifies an entity and commonName
is additional information provided for human convenience.