Re: Straw Poll: SerialNumber definition

[Stephen Kent <kent@xxxxxxx>]

Anders,
<snip>

> 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 DN is a directory distinguished name, not just an arbitrary sequence of sets of attributes. 

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

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>

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

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>

> Unfortunately NON-STANDARD policy OIDs create much more problems than
> 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.

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

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>

> 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

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