Re: Straw Poll: SerialNumber definition

[Stephen Kent <kent@xxxxxxx>]

Denis,

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