Subject: Use of dnQualifier in the QC profile

From: Stefan Santesson <[email-masked]>
Date: Thu, 11 Nov 1999 17:13:18 -0500

Here is the latest conclusions regarding use of dnQualifier and support for
"unique/static identifiers"

There are three issues.

1) Can dnQualifier be used as proposed (to hold a disambiguating value, which
MAY be a unique identifier for the subject) ?

2) Should we define that dnQualifier, when used, shall contain a unique value
for each subject subscribing to the CA. ?

3) Should we define any new attribute or extension for static/unique
identifiers.

In issue 1, the answer i YES. dnQualifier can be used in this way. James Manger
suggest another view, but no person here in Washington who I have spoken to,
who have had a clear opinion on this, agrees with James. I assume that there
will be a discussion on the list regarding this, but until that concludes into
any other result, I will assume that we are compatible with X.520

In issue 2 the answer is NO. We have to allow the standard X.520 use of this
attribute, as in RFC2459. This does however not mean that the dnQualifier can't
be used to hold a unique value for each subject, since this provides the
required disambiguating function. 

And if this is the case and a CA want to indicate this in the certificate, then
the way to do it is to assign an attribute semantics OID in the qcStatements
extension, defining this semantic property.

This is not different from the way a CA can indicate the type of value hold in
this or any other attribute (i.e. locally defined number, SSN, drivers licence,
civic registration number, etc).

Issue 3 is a clear NO. We already have dnQualifier covering this as stated
above. Assigning new attributes is not a desired path.

These solutions reflects the consensus I have experienced from many discussions
this week, including discussions with the authors of RFC 2459.

/Stefan

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 12 Nov 1999 11:44:01 -0500 (EST)

Stefan,

  I agree that these are the questions that need to be answered, and
would add a fourth:

  4) Should the unique/static identifier require directory and application
support for multi-value RDNs or can it be used in a single-value RDN?

I don't believe that consensus has yet been reached on the answers.

We do have consensus that the unique/static identifier should
have syntax PrintableString (not BITSTRING or NumericString), so
X.520 uniqueIdentifier {id-at 45} is excluded from consideration.

I agree that the answer to 1) is YES.

I agree that the answer to 2) is NO, because that would be a
redefinition (not just a profiling) of the X.520 semantics.

If we cannot require dnQualifier to contain a unique value, then I
believe that it cannot satisfy the requirement for a permanent/unique
"employee/student/customer identifier", because such an identifier is
by definition independent of the entity's Common Name and must continue
to be valid when a given entity's Common Name changes.  Saying that the
chosen attribute MAY be a unique identifier for the subject is not
sufficient, because applications then have no choice but to assume that
it also MIGHT NOT be a unique identifier for the subject.  Having this
uniqueness and staticness property depend on a property semantics OID
and the existence of a qcStatements extension is ridiculously complex
compared to just profiling an attribute which has the desired
semantics.

Thus the answer to 3) is a clear YES :-).

I don't have any particular preference for which attribute should be
used, although I believe a strong case can be made for serialNumber
{id-at 5}.  X.520 uses the word "object" for entities:

  "Unique Identifier ... used to distingush between object references ..."
  
  "... geographical positions or regions with which objects are associated."
  
  etc.

Thus little violence would be done to the spirit of X.520 if the
definition were changed from "the serial number of a device" to
"the serial number of an object".  Serial number is a PrintableString,
and it has, unlike dnQualifier, an upper bound.  A case could also be
made to define the name "staticIdentifier" as a synonym for {id-at 5},
to refer to identifiers which are not numbers issued in a series.

Alternatively, we could use "uniqueIdentifier"
{0 9 2342 19200300 100 1 44} defined in RFC 1274, which predates but
is not superseded by RFC 2459.  Disadvantages are: 1) the OID is bigger,
and 2) the name could be confused with {id-at 45}.

With regard to question 4, the directory experts will have to answer
whether a certificate with the DN

   "C=US, O=Foo.com, SID=123456, CN=Fred Smith"
   
MUST be stored in a directory entry 4 levels deep, or whether it MAY
legitimately be stored in a directory having only 3 levels.

The answer to that question will determine whether support for
multi-valued RDNs (SID+CN) is needed, or whether single-valued RDNs
(SID, CN) are acceptable.  I don't care either way, as long as
application developers can count on the fact that the SID attribute is
required to be static and unique.

Dave Kemp

> Date: Thu, 11 Nov 1999 17:13:18 -0500
> To: <[email-masked]>
> From: Stefan Santesson <[email-masked]>
> Subject: Use of dnQualifier in the QC profile
>