Subject: Re: Straw Poll: SerialNumber definition

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 23 Feb 2000 08:59:57 -0000

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

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Feb 2000 17:37:35 -0500

Anders,
	<snip>

>"local knowledge and manual settings" by a lot of current RP software.

A DN is a directory distinguished name, not just an arbitrary 
sequence of sets of attributes.

>but that is another story.

It's not surprising that you are willing to make that tradeoff, but 
that does not constitute a rationale for doing so.  GNs are NOT a 
radical change.  2459 mandates support for several GNs already.  if 
one defined a new GN that used the same set of attributes as a DN, 
then this would be a clean solution that would allow reuse of the 
software that knows how to parse DNs, without muddying the semantics 
of DNs.

	<snip>

>That is what I call GENERIC SOLUTION and is what standards need.

Yes, the proposal allows arbitrary use of DN attributes, which is why 
the result is not longer a DN, and does not belong warrant being 
tagged as a DN.

	<snip>

>they solve.  I have already elaborated on that in this list.

"non-standard" policy OIDs?  This implies that there is a standard 
set, but I'm not sure where that standard set has been defined.  One 
school of thought assumes that a small set of policy OIDs will come 
into existence, hence the desire for policy qualifiers.  However, 
that is not the only model for use of policy OIDs, so I think your 
reference here is premature, and narrow.

>require an officially registered value of some kind to be interoperable among

I think that your suggestion for a name domain definition is further 
evidence that the identifiers that you are referring to are not 
really DNs!

	<snip>

>taken to PKI-FORUM rather than developed here?  I don't care where as

Is this a trick question?  Is it really an offer for you to move your 
campaign for changes to ITU and IETF standards to an industry 
consortium? How can I say no?

Steve