Subject: Re: QC UID support must depart from RFC2459

From: "Bill Brice (listserv)" <[email-masked]>
Date: Wed, 10 Nov 1999 13:37:16 -0600

All,

As the new kid on the block, I'd like to share with you the
design tensions we, as a CA, had to deal with quite recently
in designing UID support for our certificates. AlphaTrust
specializes in certificates which are used in legally binding
transactions (irrespective of the state of dig-sig law).

Since our members must be unambiguously identified from a
user universe of everyone on the planet, we had little choice
but to use some form of UID. After all, what's to differentiate
between one Fred Smith, (an individual with no O= or OU=) from 
the next Fred Smith.

Our original choice was to use a DN Qualifier with a CN, as Steve Kent
suggests as the correct approach. The market reality, and therefore
the tension, is that most cert using applications available
to the public (which is our market) do not process DN Qualifiers.
In fact, most user interfaces present only the CN to the user
when reporting on a certificate or asking the user to select one.
Multiple certs with the same CN are very confusing to an
average user.

So we made the same choice as the DoD and added the UID (
and two other items the user needs) into the CN field. The UID
also appears in the OU field (as many of our users do not
have an OU to report).

I agree this is not the correct approach and we welcome better
user interfaces and support of standards by the major software
suppliers. But its also important to remember that if a product
is not easy for a user to understand and use, all the standards
in the world won't help it.

Bill Brice, CEO
http://alphatrust.com

-----Original Message-----
From: schaen [mailto:[email-masked]]
Sent: Wednesday, November 10, 1999 12:37 PM
To: Stephen Kent
Cc: David P. Kemp; [email-masked]
Subject: DOD Plans [was: Re: QC UID support must depart from RFC2459]

A quick clarification of the DoD plans.

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.

Sam Schaen
MITRE

Stephen Kent wrote:

> Dave,
> [snip]

> Is it really true that the DoD is going to concatenate a CN and a UID
> and represent the result as a CN?  I agree that this would be a very
> bad idea!  It is not at all the same as making the terminal RDN be a
> 2-element set consisting of a CN and a DN Qualifier, which would be
> consistent with PKIX and X.509. As for your closing question, I don't
> think that the TRW example is a good one, for the reasons cited
> above, and so I don't know that it will be consistent with the PKIX
> or QC profiles.
>
> Steve