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

From: "Manger, James H" <[email-masked]>
Date: Wed, 21 Jul 2004 11:15:50 +1000

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:[email-masked]]
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.

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 21 Jul 2004 15:54:27 +0200

James,

> can have its own serialNumber.

OK.

> absent the deepest serialNumber value is used.

I understand what you mean, but the proposed formulation is wrong.

Suppose a certificate with:
cn="John Doe" , o="Acme Ltd" serialNumber="DUNS554433", c=US

then there would be thousands of certificates with the same PI and refering 
to differents persons. :-(

> named object, not of some parent object. However, I would not recommend that.
> It is not unusual for DNs (particularly in certificates) to only

This remark is correct, but we need a way to prevent the case mentionned above.

There would be two cases to consider:

1 - if there is one serialNumber attribute alone in a RDN (i.e. no
     other attribute is present in that RDN), then the value contained
     in that serialNumber shall be used as the identifierValue;

2 - if there is no serialNumber attribute alone in a RDN, then the
     deepest RDN shall include a serialNumber attribute and the
     value contained in that serialNumber shall be used as the
     identifierValue.

Is this formulation correct ?

Denis

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 21 Jul 2004 17:23:14 +0200

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" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 21, 2004 03:15
Subject: RE: PI: 10: draft-ietf-pkix-pi-10.txt - single serialNumber attribute

That is wrong.

In my sample DN:

----------

---

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 27 Jul 2004 17:43:17 +0200

As far as I can see the PI extension adds nothing to existing single-
assigner (name space) PKIs like DoD's and various Citizen schemes.

In these PKIs a static RFC 3739-compliant assignment of serialNumber
as PI value suffices.  This is how it is done today and nobody has
expressed that something is really "missing".

Therefore, the PI extension should IMHO be (re)targeted at PKI networks
that at least _plan_ to accept multiple assigners.  This BTW means a
_lot_ more than adding some PI crypto-software with respect to RPs.

However, this also makes the specification of the assigner-part much
more important than has been expressed in some off-list messages like
"assigner is only read by machines", which does not tell the whole story.
Assigners will in multi-assigner PKIs be stored in user or customer
databases and will definitely be read and communicated by humans.
VAT and DUNS are example of two common assigners that are important
to distinguish both for legal and technical reasons.

With this I mean, that OIDs should not be the _only_ assigner choice as
this would probably put a "stigma" on the PI scheme as the world outside
of the IETF is fairly ignorant of OIDs.  Neither do I believe that a true
multi-assigner PI scheme would gain by putting assigner values in
special places, disconnected from their closely associated value parts.

That is, a *genuine* PI is a two-dimensional name, similar to an e-mail address.

For historical reasons (X.520) we must accept a compromise but this
compromise can still be more or less tasty.

================================================
  It is important to note that there currently probably does not exist
  a single multi-assigner PKI-based network.
================================================

/Anders