Re: QC UID support must depart from RFC2459

["David P. Kemp" <[e-mail]>]

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" <[e-mail]>
> From: Stephen Kent <[e-mail]>
> 
> 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
>