Subject: Re: Use of dnQualifier in the QC profile

From: [email-masked]
Date: Thu, 11 Nov 1999 18:02:45 -0500

Should we encourage the use of the UniqueIdentifier attribute from
X.520 section 5.2.7 (OID 2.5.4.45) instead of DNQualifier for closer
conformance to X.520?  Unfortunately it is a bit string, and its definition
is not ideal for this purpose, as follows:   "The Unique Identifier
attribute type specifies an identifier which may be used to distinguish
between object references when a distinguished name has been reused. It may
be, for example, an encoded object identifier, certificate, date,
timestamp, or some other form of certification on the validity of the
distinguished name."  It's the only attribute I can find whose definition
is closer to the desired one than the dnQualifier definition - if anybody
else knows of a better alternative (not necessarily from the ITU series),
please say so.

          Tom Gindin

---

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

Tom,

The fact that the UID is a bit string is the reason it can't be used with
success.

What we want to store here is a displayable identifier. The fact that UID is a
bit string makes it impossible for a client to know how to display this
information unless additional information re character encoding is provided by
other means.

We originally tried to implement this in Scandinavia, carrying an ISO 8859-1
coded identifier. This proved to be a really nasty solution that we had to
abandon after encountering problems in almost every possible way.

So I really would argue against the UID.

Our next step in the SEIS project was to use the serial number. This works
technically well but the use of this attribute does definitely expand the
originally intent behind the attribute (serial number on a DEVICE). In addition
serial number is not supported by RFC 2459.

So this made us choose the dnQualifier for the QC profile.

So I hope that we can agree on this, or otherwise we will have to consider
inventing a new attribute :-(

/Stefan