Re: Straw Poll: SerialNumber definition

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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