Re: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute

["Anders Rundgren" <[e-mail]>]

Denis,
James is probably right regarding multiple serialNumbers.

But why didn't you rather showed him that you actually can handle multiple
PI's by using the subjectAltName-only variant for the company ID?

However, that James put a DUNS 554433 "sort-of-PI" in the subject
DN, again illustrates the obvious:  It is non-intuitive to put names
in other places than in DNs.  This includes assigners as well.

That X.520 does not support assigners is hardly an argument as
the X.500 people apparently didn't understood the importance of
permanent identifier concepts, so we are now actually "patching"
X.500.   Patches usually "look" ugly but they may "work" completely
OK anyway.

We may ignore this fact, but it will most likely just show up again in
homebrewed constructs like the one James (accidentally?) created.

To further complicate things: That the "subject" is John Doe
is only valid from a strict X.500 point of view.  If this certificate
is actually associated with a signed purchase order that a relying
party (supplier) has just received, they hardly regard John Doe
(who they may never ever have heard of) as the "important" thing
but rather "Acme Ltd" and "DUNS 554433".  Well, I actually
lied here because they will not bother with the certificate DN
at all as this name scheme is entirely different to the name
schemes used in business messages.  Only X.500 experts can
on case-per-case basis, manually and only occasionally do this 
name matching.  That PIs insist on using OIDs for authorities,
thereby avoiding intelligible expressions like "DUNS" or
http://www.dnb.com/duns, will postpone this for security
reasons highly wanted name matching for yet another decade.
e-Business folks generally have no idea what an OID is, and
before PIs they had no reason to know it either.

============================================
 A properly designed PI OTOH, could be the bridge between
 identities in certificates and business messages that X.500
 as it stands today never achieved, and never will either!
============================================

But if the only goal is to get PI out now, I guess we might as well
support things like James' "sort-of-PI" scheme by keeping focus on
the "deepest" serialNumber.

That was deep :-)

Anders

----- Original Message ----- 
From: "Manger, James H" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>; <[e-mail]>
Sent: Wednesday, July 21, 2004 03:15
Subject: RE: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute



That is wrong.

A DN names an object by describing a path to it through a hierarchy of
other objects.  Each RDN consists of attributes of one of those *other*
objects.  Only the last RDN has attributes of the actual named object.
A serialNumber attribute (like any other attribute) can appear multiple
times -- once for each level of the hierarchy (ie once for each RDN).

RDN = *Relative* Distinguished Name.

[Note. No attribute type can appear multiple times within a single RDN.]

In my sample DN:
cn="John Doe" serialNumber=12345, o="Acme Ltd" serialNumber="DUNS
554433", c=US
there are 3 objects: a country, a company and a person.  The person only
has one serialNumber.  The company is an object in its own right so it
can have its own serialNumber.

So please reconsider my suggestion (1) that when identifierValue is
absent the deepest serialNumber value is used.

[Theoretically, the PI draft could require the serialNumber be in the
deepest RDN.  This would ensure the serialNumber is an attribute of the
named object, not of some parent object.  However, I would not recommend
that.  It is not unusual for DNs (particularly in certificates) to only
use 1 attribute per RDN, even if some of the attributes all relate to
the same logical object.]


----------
From: Denis Pinkas [mailto:[e-mail]]
Sent: Wednesday, 21 July 2004 12:01 AM

Section 5.2.9 from X520 defines the serial Number attribute as follows:

"The serial Number attribute type specifies an identifier, the serial
number 
of an objet."

The serial Number attribute applies to the object, not to a RDN
component.
Thus, unless it is an error, there can't be multiple serial Number 
attributes in a DN.