Stray Poll: SerialNumber definition

[Anders Rundgren <anders.rundgren@xxxxxxxxxx>]

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