Re: QC UID support must depart from RFC2459

[Stefan Santesson <[e-mail]>]

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 

At 09:03 1999-11-10 -0500, David P. Kemp wrote:
>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
>>