Subject: Re: Straw Poll: SerialNumber definition

From: [email-masked]
Date: Sun, 20 Feb 2000 22:11:34 -0500

This question may be split into several separate ones.  First, should
there exist standard attributes with the following characteristics: 1)
affiliation ID, typically an employee ID, a membership ID, or a customer
number, assigned by either the organization in the DN containing it or one
of the organizational units in that DN and must be unique at the time of
its assignment (not necessarily for all time); 2) DN Disambiguator, added
to at least one of two otherwise identical DN's by a directory
administrator or a CA for the purpose of breaking an ambiguity; 3) national
ID, which is similar to affiliation ID but assigned by the country in the
DN?  Second, if defined should they be permitted in DN's?  Third, should
any existing standard X.520 attributes be mapped onto any of these three,
which would require some amendments to their definitions in X.520?  Fourth,
for any attributes permitted in DN's, are they permitted to appear in the
same RDN with a CN or Surname attribute?    The suggestions which have been
made which involve "yes" for the third question are that serial number be
interpreted for persons (for which it is currently undefined) as
affiliation ID or national ID above, and that the clause requiring that DN
Qualifier have the same value for all entries in a single DSA be repealed,
and then DN Qualifier be used as one of the three possibilities above.

      I know of no real argument that either affiliation ID or DN
Disambiguator is an inappropriate or undesirable attribute, and the only
question about national ID is whether it is desirable from a privacy
standpoint.  National policy might well ban its use in some countries, and
ban its use as a naming attribute in others.  I am one of those who have
suggested that serial number's definition be amended and that it be used
for affiliation ID.  I also think that any of these attributes should be
permitted in the same RDN as personal name attributes if they are permitted
in names at all.  Some of the responses in this poll have left me unsure as
to how a relying party could tell whether the proposed use of serial number
or DN Qualifier was expected to be unique on a country basis or on an
organization basis.
     There are two further questions which arise if one or both of the ID's
above are defined as attributes or mapped to existing ones.  Should there
be separate attributes for variants of either or both of the ID's above
which imply that the ID is expected to be unique over very long periods of
time (multiple centuries for national ID), so that a DN containing the ID
but no personal name is a long-lived identity?  Also, should affiliation ID
above be further subdivided according to the nature of the affiliation
(employee, member, customer, etc.)?

          Tom Gindin

P.S. The opinions above are mine, and not necessarily those of my employer.

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 21 Feb 2000 10:49:27 +0100

As David Kemp noticed it there are two ways to use additional RDN
attributes:

1) as a disambiguator,

Originally the idea was to add a disambiguator only in the case
where two certificates, without the disambiguator, would contain
identical DNs.

2) as a static identifier.

Originally the idea was to use the static identifier without using
the other DN components, which meant that the static identifier was
sufficient to identify an individual.

The first case means that *all* the components of the DN are used in
conjunction with the dnq (DN Qualifier), while the second means that
*none* of the components of the DN are used in conjunction with the
dnq (DN Qualifier).

In addition to these two extremes (all versus none), there is a
number of variations where the dnq (DN Qualifier) does not apply to
all or none, but to *some* of the components of the DN. This would
solve other concerns raised on that thread.

All concepts could nicely co-exist if we could find a way to say on
*which* components of the DN the dnq (DN Qualifier) would apply.
Rather than leaving the interpretation to an (unprocessable)
Certificate Policy OID, we should define a way to express which
components of the RDN should be associated with the dnq to make the
name unmistakable and *permanently* unique. 

In this way RPs could use this minimum structure in their ACLs. Note
that at the same time this would define the rule to compare two
certificates, i.e. know whether they bear the same minimum permanent
structure and hence refer to the same individual or not.

Let me make a proposal to explain the idea a little bit more. A DN
is an ordered sequence of RDN Attributes. If we added a new
attribute, it could say which components of the ordered sequence of
RDN Attributes shall be used with the dnq to make the name not only
"unmistakable" bu also permanently unique. This could be, for
example, a bit string. If bit 3 is on, this means that the third
component of the DN has to be used with the dnq to make the whole DN
unmistakable and unique *over time* for a given CA. 

This allows to know how the dnq and other DN components are to be
interpreted during the decoding of the unmistakable identity, in a
fully processable way. The big advantage is that we then have a way
to automatically process names, rather than to rely on unprocessable
Policy OIDs.

Denis

---

From: Paul Koning <[email-masked]>
Date: Mon, 21 Feb 2000 10:43:16 -0500

>>>>> "Denis" == Denis Pinkas <[email-masked]> writes:

 Denis> As David Kemp noticed it there are two ways to use additional
 Denis> RDN attributes:

 Denis> 1) as a disambiguator,

 Denis> Originally the idea was to add a disambiguator only in the
 Denis> case where two certificates, without the disambiguator, would
 Denis> contain identical DNs.

 Denis> 2) as a static identifier.

 Denis> Originally the idea was to use the static identifier without
 Denis> using the other DN components, which meant that the static
 Denis> identifier was sufficient to identify an individual.

 Denis> The first case means that *all* the components of the DN are
 Denis> used in conjunction with the dnq (DN Qualifier), while the
 Denis> second means that *none* of the components of the DN are used
 Denis> in conjunction with the dnq (DN Qualifier).

 Denis> In addition to these two extremes (all versus none), there is
 Denis> a number of variations where the dnq (DN Qualifier) does not
 Denis> apply to all or none, but to *some* of the components of the
 Denis> DN. This would solve other concerns raised on that thread.

Ouch.

The situation we started from is that there were two ways of
interpreting a particular attribute.  The new situation you're
pointing to is to increase that number from 2 to N.  I think that's a
large step in the wrong direction.

The problem with many standards is that they have too many options,
not too few.  Adding more stuff for the purpose of adding N-2 new
options is not a good thing at all, in my view.

	paul

---

From: Tony Bartoletti <[email-masked]>
Date: Tue, 22 Feb 2000 11:49:03 -0800

>options is not a good thing at all, in my view.

In retrospect, had a value been built-in to the spec, indicating
which subset of DN/RDN attributes constitute "unique-id" from an
issuing CAs perspective, it could be seen as reducing 2 ways to 1.
I.E., ALWAYS rely on the given subset specification.  While this
would make processing mechanical, it would not help in promoting
a "common uniqueness profile" if that is the real concern.

___tony___

___tony___
Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: Stephen Kent <[email-masked]>
Date: Tue, 22 Feb 2000 19:56:52 -0500

Denis,

>...

I'm opposed to adding a notion of selective marking of RDNs to 
indicate which ones, in concert, really qualify as a DN, remembering 
the definition of a DN.  This was the subject of a private message 
exchange between Anders and me last week, so I'm happy to share my 
thoughts on this topic.

The notion underlying this proposal seems to be that DNs are 
convenient ways to express human readable names, but that in using 
them we should abandon all notions of the DIT context from which they 
emanated.  A purer way to address this need would be to define a new 
name type under general names (we have a couple of options for this 
in GNs), but this would not be backward compatible with existing apps 
that already have some ability to parse DNs, but not all forms of 
GNs, much less a new form.  But RFC 2459 already rejects the notion 
of misusing DNs to express other name forms, despite historical 
precedents, e.g., we disparage sticking RCC 822 names or IP addresses 
in DNs (typically in the guise of the common name attribute).  So, if 
we have insisted on using appropriate name forms for these other name 
types, despite possible backward compatibility problems, why should 
we backtrack when it comes to the notion of creating a new form of 
name, i.e., a DN in which only some RDNS are meaningful?

I think a better approach to the base problem that motivated this 
debate is to use an extension that claims to be a unique ID for the 
subject, relative to the Issuer.  But, we already have such a value, 
in the form of the SubjectUniqueID, if we really want this feature!

Finally, I question the assertion that there is a problem to be fixed 
here, at least in the base spec (2459).   With the current plans to 
use serialNumber as a disambiguator everyone agrees that we have 
addressed the first of the two possible uses.  However, if one wants 
to have this value be unique, relative to the Issuer, that seems 
consistent with the definition now proposed, even though it is 
overkill, i.e., it is still a disambiguator.  How should a CA express 
the notion that this RDN uniquely identifies the subject, even if two 
certs contain subject DNs that differ in other attributes?  Well, 
since all the other proposals for selective RDN use require some 
means of signalling RP software, why not use a cert policy OID?  It's 
just as valid a means of signalling this non-standard interpretation, 
for the set of RP software that will need to make use of this fact.

Steve