Subject: Re: QC UID support must depart from RFC2459

From: "David P. Kemp" <[email-masked]>
Date: Wed, 10 Nov 1999 09:03:22 -0500 (EST)

Steve,

There seems to be more heat here than what would be generated by actual
differences in requirements.  It may be useful to restate the
requirements in an effort to obtain a useful agreed-to profile.

The QC profile lists the attributes that MAY be used in the subject
field of a certificate - the QC list differs from the RFC 2459 list:

QC atttribute  RFC245 MUST/SHOULD
-----------   -----------------
countryName          M
commonName           M
surname              S
givenName            S
dnQualifier          M
orgName              M
orgUnitName          M
title                S
localityName         S

The QC profile lists two attributes not included in RFC2459:

pseudonym            -
postalAddress        -

RFC2459 includes four attributes not listed in QC:

stateOrProvinceName  M
domainComponent      M
initials             S
generationQualifier  S

No X.520 attributes appear to have the semantics of "employee number",
"student number", "payroll number", etc that Anders is requesting.

X.520:
    "The Unique Identifier attribute type specifies an identifier
    which may be used to distinguish between object references when
    a distinguished name has been reused."
    
    "The DN Qualifier attribute type specifies disambiguating information
    to add to the relative distinguished name of an entry."
    
    "The Serial Number attribute type specifies an identifier, the
    serial number of a device."

The DN Qualifier is suitable for use as you describe in the
second paragraph, as part of a multi-value terminal RDN.  But what
attribute should be used for the function you describe in the first
paragraph: a permanent unique identifier that is suitable for use
as a single-value RDN?

TRW has described their corporate naming scheme to the Federal PKI
technical working group - it looks something like:

    C=US, O=TRW.COM, OU=Employees, UID=123456, CN=Fred Smith

where UID is (I believe) 0.9.2342.19200300.100.1.1 defined in
draft-smith-ldap-inetorgperson-03.txt.  This naming scheme allows
the UID employee number to be used in comparisons (for example in
access control lists) while the CN can change during an employee's
tenure without affecting the comparisons.

This scheme is IMHO eminently sensible (and much more sensible than the
DoD's current plan to concatenate a common name and a UID in the CN
attribute!).  How will son-of-2459 or the next QC draft profile the TRW
naming scheme?

Dave Kemp

> Date: Mon, 8 Nov 1999 11:13:37 -0500
> To: "Anders Rundgren" <[email-masked]>
> From: Stephen Kent <[email-masked]>
> 
> Anders,
> 
> If QCs deviate from 2459 (in its future, revised version), then there will
> be no QC profile as an IETF standard.  I assume this is obvious, but just
> wanted to inject a little reality check here.
> 

    ... and ...

>
> Yes, many organizations do qualify individuals by employee, student,
> payroll, or other numeric IDs.  The preferred way to make use of this
> qualification is as one element of a two element set for the terminal RDN.
> After all, this qualifying number is needed to uniquely identify two
> individuals who would otherwise have the same DN, so it belongs in the DN.
>
> Steve
>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 10 Nov 1999 10:50:21 -0500

David,

The discussions and consensus reached during the Washington IETF has
changed some of the issues raised here. This includes a solution for
"static identifiers".

First of all I would like to say that X.520 UID is a bad attribute of one
particular reason. It is represented by a bit string. This is bad for all
situations where you wish to display this information in any uniform way.
(Your referenced OID is also wrong I believe)

So seen from this perspective I believe that the dnQualifier is the most
suitable attribute for this type of identifier. And one good reason is that
it is supported by RFC 2459.

The differences in supported attributes in the subject field will be fixed.
The current proposal is to make the following changes:

RFC 2459 will add support for pseudonym in the next update (son of RFC 2459)
The QC profile will add stateAndProvinceName and delete postalAddress.

This will make these profiles in harmony.

The personalData will further be updated in order to support more dynamic
use of the attributes there.

I will come back later with more detailed information about the changes in
the personalData structure but the main changes are:

- Attributes for country of citizenship and residence, gender, date and
place of birth will be moved to subjectDirectoryAttributes extension so
that they may be utilized independently without including a complete
personal record.

- Attributes for expressing a private identity (commonName, pseudonym,
givenName, surname, localityName, StateOrProvinceName, postalAddress and
dnQualifier) may be stored as a Directory name in the subjectAltName
extension. Here the use of dnQualifier will be constrained to hold a unique
identifier of the subject within the set of all certificates issued by a CA. 

- Parameters defining attribute semantics and name registration authority
are moved to the qcStatements extension as parameters the defined statement
defining conformance with syntax and semantics of the QC profile. 

With these changes I hope that we have satisfied some real issues that has
been raised lately.

/Stefan

What you say

---

From: Stephen Kent <[email-masked]>
Date: Wed, 10 Nov 1999 11:14:07 -0500

Dave,

Thanks for the detailed and very thoughtful note.

First, 2459 is being revised to add the pseudonym attribute, so that 
disconnect will be eliminated.  The QC design is being revised to 
restructure the fields and that may eliminate the postaladdress 
conflict, but I'll defer to Stefan on that issue.  2459 attributes 
that must be supported need not be included in QC certs, since QC is 
a profile of 2459 and thus sub-setting is fine. These changes were 
announced at the PKIX meeting yesterday, so anyone who did not attend 
would not be expected to know of them until the minutes are sent out 
later this week (after our second meeting, this afternoon).

I think the TRW scheme may be a bad example.  A DN is a directory 
name.  In the example you cite, I believe that the DN Qualifier makes 
more sense as a component of a terminal RDN, at least from the 
standpoint of directory schema. I would also suggest that this is the 
most appropriate attribute as a means of expressing employee ID, 
payroll number, etc.  After all, these numbers were assigned in the 
pre-X.500 world to achieve the analogous effect, i.e., to 
disambiguate among database entries that might otherwise be identical.

When one uses an attribute that, by itself, is sufficient to uniquely 
identify a directory entry, then it really has no place in the middle 
of a DN.  Just drawing the tree for the directory would make that 
apparent, I think. So I am leery of the TRW use of UID.

What we have here is a conflict among multiple criteria for DN and 
cert design. Some people would like to use a simple UID for ACLs, so 
that changes in DN forms don't wreak havoc with their ACLs. All 
people need to be able to assign DNs that are unique, even when their 
nominal schema would produce collisions. (The X.520 of a UID 
attribute, a relatively new one I believe, is an escape for people 
who did a bad schema design, right?)

Whenever we start moving into the details of access control and how 
to use certs, we encounter a lot of confusion.  This arises from the 
fact that folks faced with these problems have not always had much 
experience in the security arena, may not be familiar with the 
literature on access control and naming from the last 25 years, and 
are anxious to create a solution that meets their local needs with 
the products they have at hand. This is not a good prescription for 
how to create standards to support customer requirements.

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

---

From: schaen <[email-masked]>
Date: Wed, 10 Nov 1999 13:36:52 -0500

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:

> [snip]