Re: Straw Poll: SerialNumber definition

["Anders Rundgren" <anders.rundgren@xxxxxxxxxx>]

Steve,

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

Not abandon, a DN would still be a DN.  Heritage is of less interest.
The solution is a technical way to solve something that is already performed using
"local knowledge and manual settings" by a lot of current RP software.

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

As compatibility with existing SW is crucial, some purity will have to be sacrificed.
For radical changes like GNs it may be better to look on XML-certs but that is another story.

<snip>  

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

As Denis nicely points out, the suggested solution allows arbitrary uses
of DN attributes including various combinations with serialNumber and
lets say organizationUnit.   But for the RP it looks like a singular solution
as it just requires a call to the (anticipated) API function "getQCUnmistakableIdenitity()"
to get the optional subset of of DN that holds the unmistakable identity.
That is what I call GENERIC SOLUTION and is what standards need.

SubjectUniqueID is a SPECIAL CASE of no general interest.

<snip>

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

Unfortunately NON-STANDARD policy OIDs create much more problems than
they solve.  I have already elaborated on that in this list.

What is missing from the current suggestion is a Naming Domain definition.
I can just find two variants: Either the naming domain is marked as internal/CA
and does not have to be known outside, or the CA issues certificates to
an external naming domain like "registered Citizen of XYZ".   The latter should
require an officially registered value of some kind to be interoperable among
competing CAs,

Conclusion: the maintenance and setup of QC RP SW  can be really greatly simplified!

OK, it does not solve the actual meaning of OU, CN, and SN etc. but somewhere you
have to stop!

Anders

PS Steve, do you prefer that a solution according to my and Denis lines are
taken to PKI-FORUM rather than developed here?  I don't care where as
long as it gets done.  DS