Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt

From: "David P. Kemp" <[email-masked]>
Date: Wed, 12 May 2004 11:45:17 -0400

Denis and Tom,

It is my hope that PI will become an RFC in the near future, so
that certificates (from an un-named large PKI :-) that currently
handle PIs by munging them into Common Name (e.g.,
CN="Kemp.David.P.0514101404") will have a saner alternative.

Comments:

"Assigner Authority and Type" could and should be better explained,
in the I-D / RFC, but it is also clear what it means without such
an explanation.  See www.acq.osd.mil/uid/policy.html,
"Guide to Uniquely Identifying Items" for an example.  The
guide defines five "Issuing Agencies" (assigner authorities)
where each issuing agency defines the type of identifier it
assigns.  The issuing agencies (and types) are:

   1. EAN-International (EAN.UCC company prefix that goes on the
barcode of everything you buy in the supermarket)

   2. Telcordia Technologies (ANSI T1.220 numbers)

   3. Dun & Bradstreet (DUNS number)

   4. Allied Committee 135 (CAGE code - look up your favorite
company's number at www.dlis.dla.mil/cage_welcome.asp)

   5. European Health Industry Business Communications Council
(EHIBCC number)

There should not be a large number of PI assigner authorities,
but there will be more than five and the list will grow, so they
can't be enumerated within the RFC itself.   It is reasonable
to identify them by IANA-assigned value, or by OID.  It is not
completely unreasonable to identify them by URI, but there is
an impedance mismatch between the goals of PI (physical
organizations with stable business processes to establish
reliable identifiers) and the mechanism of URI (put up a
document/resource somewhere in cyberspace).  Not that a URI
couldn't point to a substantial, permanent organization, or
that the target of an OID couldn't be ephemeral, but OIDs
do have a more substantial "flavor" than URIs.

More to the point, an OID tells a machine implementation what
to do with a PI, whereas a URI is presumably intended to cause
the implementation to make an online access to find out what
to do.  That is an unreasonable burden.

I believe that the syntax of PI-08 is fine as is, and that with
Jim Schaad's corrections and perhaps some more explanatory text
the draft is ready to become an RFC.

Dave

Denis Pinkas wrote:
> 
> Anders,
> 
>> Well Jim,
>> The PI-draft is certainly an odd creature that has been in PKIX's
>> "custody" for now close to four(!) years.
>>
>> A few comments to PI in general and some draft-08 specific.
>>
>> Draft-08: identifierType    "The IdentifierType field, when present, 
>> is an OID which identifies    both the Assigner Authority and the type 
>> of that field. It is an OID"
>>
>> The words "type of that field" has never been explained.  But we all
>> know exactly what the authors' mean don't we?  :-|
>>
>> Draft-08: identifierType has, as you noted been reduced to only support
>> OIDs, probably due to the authors' belief that OIDs are more permanent.
> 
> 
> It was not exactly the author's belief, but the IESG belief.
> 
>> However, the rest of the computer industry have no problems using URIs
>> making PI "incompatible" and "deviating".  A URI also have the
>> big advantage that it may point to a document.
> 
> 
>  ... that has then disappeared, or even worse, pointing to a document 
> that is different from the original one.
> 
>> I find this "obsession" with permanence wrong, because if a CA 
>> disappears,
>> its regitered DNS name is taken by somebody else, 
> 
> 
> The URI was to designate an object defined by an Assigner Authority, not 
> by a CA.
> 
>> the certificates are
>> anaway no longer usable and names may indeed be reused. That is, OID 
>> or URI is a
>> deployment issue.  At best you can RECOMMEND the "serious"
>> implementer to use an OID.
>>
>> PI-General: During the PI development serialNumber has become
>> the de-facto standard for keeping a permanent (or static which is
>> really more what we are talking about) identifier.
> 
> 
> You have already made this comment in the past. serialNumber serves a 
> different purpose. Please take a look at RFC 3039 :
> 
>    The serialNumber attribute type SHALL, when present, be used to
>    differentiate between names where the subject field would otherwise
>    be identical.  This attribute has no defined semantics beyond
>    ensuring uniqueness of subject names.
> 
>> Anyway, PI-using relying party software have little reason to
>> bother about PI as the existing systems I know of simply does
>> not "decipher" certificates looking for the most "attractive"
>> name form(?), they just _assume_ that things are as the CP says. Most 
>> of these CAs also obey to Anders' nowadays (in)famous
>>  "best practice CA formula":
>>
>>                    CA <=> Policy
>>
>> which makes identifierType redundant and also eliminating the
>> need for additional Subject name forms like PI.
> 
> 
> If you do not have a need for the PI, then that's fine; but other people 
> may wish to use it, as soon/long as it is defined.
> 
> Denis
> 
> 
> 
>> Anders
>>
>> ----- Original Message ----- From: "Jim Schaad" <[email-masked]>
>> To: "'Denis Pinkas'" <[email-masked]>; "'Tom Gindin'" 
>> <[email-masked]>
>> Cc: <[email-masked]>
>> Sent: Thursday, January 22, 2004 03:22
>> Subject: RE: I-D ACTION:draft-ietf-pkix-pi-08.txt
>>
>>
>>
>> Comments on draft -08.
>>
>> 1.  Privacy concerns should be additionally outlined and covered in the
>> security considerations section.
>>
>> 2.  Section 1, para 9: Text here allows for an AA to have a unique URI
>> name.  Has been removed from the syntax.
>>
>> 3.  Section 1, para 14:  Suggested text "both the same permanent
>> identifier value and the same Authority Identifer Value, then these".
>> (I find the use of identityType to be confusing since I consider this to
>> relate to type choice of IdentifierValue as well.)
>>
>> 4.  Section 2:  What is the criteria for use of iA5String vs uTF8String?
>>
>>
>> 5.  Section 2:  When doing comparisons do I need to cross compare these
>> two different value items?
>>
>> 6.  Section 2: The statement 'It is an OID.' is redundant and can be
>> removed.
>>
>> 7.  Section 3: Contains a paragraph dealing with matching rules.  Since
>> this is no longer a field in the structure the paragraph should be
>> re-written to state what the one and only matching rule is.
>>
>> 8.  Appendix A.1:  New request, please put a reference to the document
>> containing the pkix module into the pkix document (i.e. something like
>> "-- found in [RFC 3280]".  This prevents documents from importing
>> modules that are lower in the standards process without having any
>> explicit reference to them.
>>
>> jim
>>
>>
>>
>>> -----Original Message-----
>>> From: [email-masked] 
>>> [mailto:[email-masked]] On Behalf Of 
>>> [email-masked]
>>> Sent: Wednesday, January 21, 2004 1:27 PM
>>> To: IETF-Announce:
>>> Cc: [email-masked]
>>> Subject: I-D ACTION:draft-ietf-pkix-pi-08.txt
>>>
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts 
>>> directories. This draft is a work item of the Public-Key 
>>> Infrastructure (X.509) Working Group of the IETF.
>>>
>>> Title : Internet X.509 Public Key Infrastructure Permanent Identifier
>>> Author(s) : D. Pinkas, T. Gindin
>>> Filename : draft-ietf-pkix-pi-08.txt
>>> Pages : 12
>>> Date : 2004-1-21
>>>
>>> This document define a new form of name, called permanent identifier, 
>>> that may be included in the subjectAltName extension of a public key 
>>> certificate issued to an entity.
>>> The permanent identifier is an optional feature that may be used by a 
>>> CA to indicate that the certificate relates to the same entity even 
>>> if the name or the affiliation of that entity stored in the subject 
>>> or another name form in the subjectAltName extension has changed.
>>> The subject name, carried in the subject field, is only unique for 
>>> each subject entity certified by the one CA as defined by the issuer 
>>> name field. Also, the new name form can carry a name that is unique 
>>> for each subject entity certified by a CA.
>>>
>>> A URL for this Internet-Draft is: 
>>> http://www.ietf.org/internet-drafts/draft-> ietf-pkix-pi-08.txt

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 12 May 2004 23:01:23 +0200

>CN="Kemp.David.P.0514101404") will have a saner alternative.

The de-facto standard, already engraved in *millions* of certs is
putting 0514101404 in serialNumber. 

This is almost as de-facto standard as putting e-mail addresses in DNs
which in turn is almost as de-facto standard as using URIs for naming
globally unique objects.

C:\Internet-Drafts>del draft-ietf-pkix-pi-*.txt

:-)

Pardon my complaints, let there be an RFC!  But don't expect
this scheme to become the trend.

There is a slight problem with the whole idea.  Either RPs require
and act upon the PI-data or they don't care about it.  This in my
opinion makes the extension redundant or is just another way
to screw up validation.

If you on top of this add policy extensions I believe a real disaster
is in the making.

Anders

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 12 May 2004 18:12:04 -0400

It is certainly technically possible to put any attribute
into the subject name syntax.  An unfortunate side effect
of an infinitely-flexible syntax is that de-facto standards
such as those you cite can arise.

DNS (and by extension, email address) is a namespace rooted
in the TLDs (.com, .edu, ...).  PIs are another
namespace rooted either in some CA-specific environment
(policy=CA) or in an independent manner (by assigning agency)
that allows multiple CAs to issue certificates to one
identifiable user.  Subject Distinguished Names are
intended to be a third namespace, typically rooted by Country.

When you say "just stuff an email address in the middle of
a DN", that is equivalent to saying "just stuff a DN in
the middle of an email address:
"dpkemp@missi.(C=US,O=DoD,CN=Dave).ncsc.mil"  Fortunately,
RFC822 prohibits such foolishness in a way that cannot be
circumvented by fools.  Unfortunately, X.509 DN syntax does
not prohibit anything, and it is up to system architects
to establish rules that enable DNs to form a namespace
rather than a cloaca for miscellaneous unrelated data.
It is as easy for CAs to ignore those rules as it is
for Harry Homeowners to ignore electrical codes and wire
their basements without grounding and with hot and neutral
lines connected randomly.  The fact that something can be
done and is in fact done millions of times does not make
it a good idea.

SubjectAltName brings some syntax-enforced discipline
to certificate naming.  Feel free to ignore it, and even
to urge others to ignore it, but at least feel a twinge
of shame when you do so.

---

From: "Al Arsenault" <[email-masked]>
Date: Wed, 12 May 2004 21:30:37 -0400

> [mailto:[email-masked]]On Behalf Of Anders Rundgren
> Sent: Wednesday, May 12, 2004 5:01 PM
> To: David P. Kemp; [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt
> 
> 
> 

The problem with that is that "0514101404" is not expected to change; it's a number which stays with you as long as you're an employee of the company, or as long as you're a customer, or even all of your life.

The serialNumber is expected to change every time the certificate changes - commonly, when a certificate expires once a year, the new certificate has a new serialNumber.  It's considered seriously bad form to issue a "renewed" certificate with a different validity period and the same serialNumber.

Thus, those who put 0514101404 in "serialNumber" are just setting themselves up for trouble later on down the road.

(And as I've pointed out numerous times before, I know of organizations that put the equivalent of "0514101404" in subjectAltName, as a DNS Name!  It's certainly possible, but that doesn't make it the "right thing" to do.

			Al Arsenault

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 14 May 2004 02:36:43 +1200

"Al Arsenault" <[email-masked]> writes:

>(And as I've pointed out numerous times before, I know of organizations that
> put the equivalent of "0514101404" in subjectAltName, as a DNS Name!  It's
> certainly possible, but that doesn't make it the "right thing" to do.

I've seen 'em in uniqueIDs, from a couple of European CAs.

Peter.

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 13 May 2004 21:59:41 +0200

David,
I don't know if you really care, but there are reasons behind
my arguments, beyond just "opinions" or personal taste.

>to urge others to ignore it, 

*I* don't have to do this.  Putting RFC822 names in subject
DNs is the default behavior of every major CA software
package there is.

In fact 9 out of 10 certificates used for signing messages
to the PKIX-list(!) follow this standard, in spite of being
deprecated by S/MIME and RFC3280.

>but at least feel a twinge of shame when you do so.

Well, I believe the RFC3280 should in the coming revision
refrain from calling the industry standard "legacy".

Harry the PKI amateur
--------------------------

In quite a number of RP applications the subject DN is
the *only* identity information used, as most folks actually
believed that the "subject distinguished name" really is
the name of the subject.  After looking at a number of
commercial certs this looked like a fact.  That DNs are
created to suit the needs of a directory is not an absolute
truth anymore.  In particular as many RPs don't store
certificates in directories but in "flat" databases. 
In most cases external certificates are not stored at all,
except by CAs for revocation services etc!

Encrypted mail is a microscopic application which
makes the whole DIT-story of marginal interest.
That's was an "opinon" though :-)

The "art discussion"
---------------------

Now assume that you don't have an e-mail address
to stuff into the DN but you do have some kind of
unique identifier.  Why put this somewhere else than
in the DN?  An example shows how ugly it gets:

Denis' world:
DN: CN=John Smith, serialNumber=3, O=ACME, C=US
PI: OID.6.4.3.5.6.6.6.43.3, 05725277

The real world:
DN: CN=John Smith, serialNumber=05725277, O=ACME, C=US
The name space is given by the CA policy. Implicit or explicit.

Although esthetics is maybe not priority #1, I believe that
"inventing" arbitrary disambiguing numbers when there is
a perfectly valid number to use is a *very* hard sale. 
However, most of the PI motivation goes away if the unique
identifier is used as disambiguer and that's the problem in
a nutshell.  Can you fix this dilemma, please tell us how!

A solution for DoD
----------------------

Not that I believe you want my advice but here is a suggestion
for DoD:

CN=David Kemp, serialNumber=05725277, DC=staffregistry1, DC=dod, DC=mil

Using this scheme you get globally unique identifiers (GUIDs)
which is a much more needed and popular thing than finding
new ways to complicate RP applications.  Why would a
certificate ever contain more "name" info than this (+ S/MIME
support in applicable cases)?

rgds
Anders

---

From: "David P. Kemp" <[email-masked]>
Date: Fri, 14 May 2004 11:01:22 -0400

The problem is that most PKIs do not support SN attributes
managed as in your "real world" example, they support
SN as disambiguator, as cited (not invented) by Denis.

Some tightly-managed PKIs (government and commercial) do
support SN attributes that are permanent references to a
user; in fact some do not even populate commonName and
use SN as the only user identifier.  In an ideal world,
all PKIs that populated the SN naming attribute would
put a Permanent Identifier in it.  This would be in
partial alignment with the wording of X.520, which
says:
   "The Serial Number attribute type specifies an
    identifier, the serial number of an object."

If you regard people as objects, then it is pretty clear
that the "serial number" of a person is something equivalent
to DNA; it doesn't change when the person changes names,
and it doesn't change depending on which CA issues the
person a certificate.  However, there are strong privacy
reasons for not putting a DNA equivalent into certificates,
and that's never going to happen.  So an alternative
like the PI RFC is required.  The requirements are:

1) mechanical applications must be able to tell reliably
and unambiguously (i.e., without installation-time
configuration) if a cert contains a PI, and if so, how
to extract it.

2) the PI doesn't change over the "functional lifetime"
of the person (the time the person has an account at
an institution, which can range up to most of a person's
natural lifetime).

3) the PI is assigned by a naming authority that is not
in general a CA.  One CA must be able to issue certs for
multiple institutions that create user accounts, and
multiple CAs must be able to issue certs for an account
at a single such institution (and are recognized as all
referring to the same account by the applications of
requirement #1).

If you can come up with a specification that uses the
SN attribute and satisfies each of these three requirements,
I will happily favor it over the Pinkas/Gindin proposal.
But I don't believe such a specification is possible.

Dave