Re: Stray Poll: SerialNumber definition

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Anders,

I have followed some of the exchanges.

> 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.

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. 
 
> 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.  

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 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

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

> Anders Rundgren