Subject: Re: SerialNumber consensus in QC 03

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 15 Mar 2000 19:33:11 -0000

Denis,

<snip>

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

What good is a DN if the REAL stuff is somewhere else?

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

I liked your original suggestion

   http://www.imc.org/ietf-pkix/mail-archive/msg04094.html

more as it keeps DN unmistakable,   Re-use of DNs in QCs does not sound
too attractive IMO.

You original suggestion could also easily be expanded to include support for
"Preferred Display DN components" and the Naming Domain issue which so far
has beem totally neglected.

Both your solutions require a new OID to flag "enhanced" sematic interpretation.

Anders

<snip>

---

From: [email-masked]
Date: Wed, 15 Mar 2000 20:47:10 -0500

Denis:

     This sounds like a fine idea to me.  However, I have one suggestion
for the interpretation of the DN in permanentIdentifier.  This is quite
similar to the one which was vetoed as applied to DN's in subjectAltName
containing serialNumber, but it causes permanentIdentifier to be
interpreted as (name space) + (id).  Was that consistent with your intent
in proposing it?

          Tom Gindin

Denis Pinkas <[email-masked]> on 03/15/2000 12:14:01 PM

To:   Stefan Santesson <[email-masked]>
cc:   [email-masked]
Subject:  Re: SerialNumber consensus in QC 03

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

(snip)

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

[Tom Gindin] Here is my variant proposal.  "A serial Number attribute may
be used in a permanentIdentifier in an otherName from a SubjectAltName. In
that case, the serial number and any other components (and there need not
be any) of its RDN define a permanent identifier assigned uniquely to the
certificate owner within a name space whose DN is given by the combination
of all RDN's preceding the RDN containing the serial number.  Two different
entities must never be assigned the same permanent identifier."

(snip)

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 21 Mar 2000 00:40:58 +0100

Denis, Stephen and all,

This serial number beast is a hard kill :-)

I've been thinking through this and have come to the conclusion that the
final issue that Denis raises, should not be a QC issue.
The QC specification is meant to support use of electronic signatures
according to applicable law. And this does only require that the actual
person behind the certificate can be determined with sufficient accuracy. It
does not explicitly require use of "non-reusable" identifiers.

The concept of specifying static identifiers that can never be reused among
entities when seen alone OR when seen in combination with some other
attribute(s), seams to be a general problem for authentication schemes more
than for recognition of advanced electronic signatures.

So to me Denis proposal address a general concern which is not necessary for
QC, but which may be relevant for general applications related to X.509
certificates.

I could argue against Denis proposal here but I will limit to the conclusion
that:

1) It is incomplete as presented, and;
2) There are other legitimate alternatives (such as use of
subjectUniqueIdentifier)

With this I suggest that the issue is taken of the PKIX QC work item.
Instead I suggest that the discussion, if relevant, will be related to son
of RFC 2459 instead.

Steve, could you give your opinion as the keeper of order between work
items?

/Stefan

-----Ursprungligt meddelande-----
Från: Denis Pinkas [mailto:[email-masked]]
Skickat: den 15 mars 2000 18:14
Till: Stefan Santesson
Kopia: [email-masked]
Ämne: Re: SerialNumber consensus in QC 03

Stefan,

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

      GeneralName ::= CHOICE {
           otherName                       [0]     OtherName,

      OtherName ::= SEQUENCE {

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

> 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