Subject: Stray Poll: SerialNumber definition

From: Anders Rundgren <[email-masked]>
Date: Fri, 18 Feb 2000 14:20:24 +0100

Hi,
The current QC-03 definition of serialNumber is ambiguous.  This
posting is trying to find out the support for such a solution in a standard-to-be,
targeting legally binding signatures.  The two uses of serialNumber
are pictured by the following tables with subject DNs from three different
certificates coming from a single CA.

serialNumber DN Disambiguer usage:

	cn=John Doe, sn=456
	cn=John Doe, sn=200
	cn=Pamela Anderson, sn=200

Anticipated ID algorithm: The DN as a whole is used as an unmistakable identity
The three certificates MAY (or may not) denote different persons.

serialNumber UID usage:

	cn=John Doe, sn=456
	cn=John Doe, sn=200
	cn=Pamela Anderson, sn=200

Anticipated ID algorithm: Only SN is used to identify the subject.  CN is used a "Friendly Name", "Information" etc.
The two last certificates denote the same person.  John had a successful transsexual operation :-).
Huge PKI systems are currently being deployed using this scheme.

The QC-03 draft does neither specify how serialNumber is to be interpreted, nor specify
how a CA should could inform an RP about its use of serialNumber.

The alternatives are

1. Keep the current definition
2. Require that a QC-conformant CPS contains information about DN/SN interpretation as well as DN uniqueness over time.
3. Separate these uses by either reinstating dnQualifier or creating a new DN disambiguer attribute
4. Other...

Anders Rundgren

---

From: [email-masked]
Date: 18 Feb 2000 14:03:31 Z

Reinstate dnQualifier!
It is more "user friendly" when discussing certificate contents with non-technical people. In 
the wake of the EU-directive this will definitively be the case that a much larger community 
than PKIX will address digital certificate format and content. Nobody wants to think of 
themselves as "serial number". Besides, as A. Rudgren points out, the dnQualifier has been 
(mis)used for unique number by many (us in Norway, e.g.).
Best regards,
Katarina de Brisis
____________________________________________________________________
Katarina de Brisis, senior adviser, Royal Ministry of Labour and Government 
Administration, P.O. Box 8004 Dep., 0030 Oslo
Phone + 47 22 24 46 46 Fax + 47 22 24 95 17
Internet e-mail [email-masked]

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 18 Feb 2000 16:59:55 +0100

Anders,

I have followed some of the exchanges.

> The three certificates MAY (or may not) denote different persons.

This seems simple but does not work. :-(  In a DN, some AVAs are
long term invariants while some others are not. What would be needed
is to qualify a subset of the AVAs that is an invariant. For
example, an OU in some cases may change over time and there is no
wish to re-issue a certificate when the change occurs. So it would
be nice to keep e.g. cn=John Doe, sn=200, even if the OU has
changed. We could say that in the CP. However, AFAIK, CP are not
machine processable and we have currently no way to say this. Should
we invent one ? Not sure. See the next argument. 
 
> Anticipated ID algorithm: Only SN is used to identify the subject.  

Ah ! Ah! It seems that we are reinventing the wheel. :-)

Once upon a time, ... there used to be an X.509 v2 certificate with
an optional field called: "SubjectUnique Identifier". Its use has
been deprecated. However what is described here matches with the
intended usage of that field. 

Why don't we use it, instead of using something else that is not
very well named anyway (serialNumber has always been confusing with
the serialNumber from the certificate itself) ?

The SubjectUniqueIdentifier is mainly useful if the content of the
certificate is used for access control purposes. This fixed size
information can be placed in an ACL. It has to be unique for the
issuing CA, not universally unique.

This field can certainly be useful but must remain optional (all
certificates are not used for access control purposes).

> CN is used a "Friendly Name", "Information" etc.

The name is a problem anyway.

> 2. Require that a QC-conformant CPS contains information about DN/SN interpretation as well as DN uniqueness over time.

CPs are not machine processable, so this does not work. However, we
shall continue to mandate the uniqueness of the DN as a whole (or of
the alternate name as a whole).

> 3. Separate these uses by either reinstating dnQualifier or creating a new DN disambiguer attribute

dnQualifier would certainly be a better name, but in the absence of
the knowledge of invariant AVAs, the benefits are minimum. The new
DN disambiguer attribute is in fact the SubjectUniqueIdentifier.

> 4. Other...

Introduce the optional field SubjectUniqueIdentifier and make it
part of QC-04.

Denis