Subject: SerialNumber consensus in QC 03

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 10 Mar 2000 01:44:07 +0100

All,

I'd like to summarize and propose a consensus solution to the serialNumber
Issue in QC 03.

First of all I would like to point out that this is not at debate of whether
to use serialNumber or any other attribute (that issue was settled last
year). This is a debate regarding:

1) to define the semantics for information hold in the serial Number
attribute
2) how to indicate the applied semantics and characteristics of the
serialNumber attribute use in a particular certificate.

The proposed text regarding issue 1 is:

    "The serialNumber attribute type SHALL, when present, be used
    to differentiate between names where the subject field might
    otherwise be identical.  This attribute has no defined semantics
    beyond ensuring uniqueness of subject names."

This covers a number of usages from codes that may be reused among entities
to globally unique identifiers. Just as long as they provide uniqueness of
subject names.

Issue 2 have several valid solution which all are supported by the current
text:

1) Implicit knowledge
2) Through information defined by a certificate policy OID (contained in the
referred policy or the associated CPS).
3) Through semantics information defined by an OID in the qcStatements
extension.
4) Through repeating information into the subjectAltName extension as a
directory name.

Solution 4 was the last solution discussed on the list and could easily
handle the case where a subset of the attributes in the subject field have
the capacity to identify a person. By duplicating these attributes as a
directoryName in the subjectAltName extension, The CA also indicates that
this set of attributes provide a complete DN.

We can conclude that all options above are valid. We can also conclude that
this solution is already supported  by X.509 and thus, doesn't need further
profiling.

I would personally avoid inclusion/recommendations of this solution in QC
03) since that may imply that this solution is more valid than any other
solution mentioned above.

The conclusion is that QC 03 should remain unchanged with respect to this
topic.

/Stefan

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 15 Mar 2000 18:14:01 +0100

Stefan,

The SerialNumber is a way to solve several problems. Before defining
its semantics, it is important to define what the problems are.
There are two different problems that can be both solved by using a
SerialNumber :

a) making two names different when otherwise the name of two or more
entities would not be different. An example of the first case, is
"Mary White 3" and "Mary White 22".
 
b) allowing the use of a permanent identifier for an entity, even if
the name of the entity changes. An example of that case is "C = US ;
OU = Delta ; OU1= Corporate ; CN= Mary White" while the permanent
identifier would be "C = US ; OU = Delta ; SN= 12345" where 12345 is
an employee number assigned by the Delta company. In that case Mary
White gets married with Mr Green and becomes "Mary Green". Her
permanent identifier does not change. Another example is that she
moves from "Corporate" to "Marketing". Her permanent identifier does
not change. 

Note that the last case also allows to solve the problem of re-use
of DN names and directory names. A DN or a directory name that has
been used in a certificate can be re-used after the certificate that
contained it has expired, as long as a permanent identifier, instead
of the DN or the directory name, can be used by a relying party,
e.g. in an ACL.

A sub-goal is to be able to know what are the components of a
permanent identifier without the need to make any look up. This
means that the certificate must contain all the information to
interpret directly the semantics of the serial number. Proposals 1,
2, and 3 to the issue 2 do not solve this concern.

However, the proposal 4 would fit that concern with some changes. It
is suggested to repeat information into the directory name. 

However a directory name is defined in X.501 as: "A construct that
singles out a particular object from all other objects. A name shall
be unambiguous (that is, denote just one object), however it need
not be unique (that is, be the only name which unambiguously denotes
the object)."

The semantics of a directory name does not allow to play the role of
a permanent identifier. We thus need a new form for this. From RFC
2459 we have: 

SubjectAltName ::= GeneralNames

      GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

      GeneralName ::= CHOICE {
           otherName                       [0]     OtherName,
           rfc822Name                      [1]     IA5String,
           dNSName                         [2]     IA5String,
           x400Address                     [3]     ORAddress,
           directoryName                   [4]     Name,
           ediPartyName                    [5]     EDIPartyName,
           uniformResourceIdentifier       [6]     IA5String,
           iPAddress                       [7]     OCTET STRING,
           registeredID                    [8]     OBJECT
IDENTIFIER}

      OtherName ::= SEQUENCE {
           type-id    OBJECT IDENTIFIER,
           value      [0] EXPLICIT ANY DEFINED BY type-id }

We could define under OtherName a "permanentIdentifier". We would
then need to get/obtain an OID for it. We would define the
permanentIdentifier as a Name.

If the name of the certificate owner changes, the
permanentIdentifier does not change. The content of the
permanentIdentifier can be used in an ACL.

In order to fit with the approach above, since the serial number
solves two different issues, we need two different statements to
cover both cases a) and b).

For case a), here is the proposal :

"A serial Number attribute may be used either in a DN or a
SubjectAltName to differentiate between two names (for two different
individuals) that otherwise would not be different."

For case b), here is the proposal :

"A serial Number attribute may be used in a permanentIdentifier in
an otherName from a SubjectAltName. In that case, when used in
combination with the other components of the permanentIdentifier, it
defines a permanent identifier for the certificate owner for the
issuing CA (that is, two different entities will never get the same
permanent identifier)."

In the security consideration section we can now have the following
text :

"A given physical entity may have at an instant of time or at
different instant of time multiple forms of unmistakable identity.
If two certificates contain two identical permanentIdentifiers in an
otherName from a SubjectAltName, then it is possible to determine by
examination if two qualified certificates refer to the same physical
entity."

Regards,

Denis