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

From: [email-masked]
Date: Tue, 13 Jul 2004 16:04:46 -0400

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-10.txt
	Pages		: 13
	Date		: 2004-7-13
	
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-10.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-pi-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-pi-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 15 Jul 2004 10:05:47 +0200

Some information about the major changes done to this draft.

After side discussions initiated by Anders Rundgren and followed by Peter 
Gutmann, I have discussed with my co-editor, the PKIX chairs and the 
security Area Director.

As the result of this, the definition of the PI has been changed to allow to 
use the serialNumber attribute from the subject DN.

In the previous draft, there were 2 options or variants for the PI which was 
defined as:

   PermanentIdentifier ::=     SEQUENCE {
      identifierValue              UTF8String,
      identifierType               OBJECT IDENTIFIER      OPTIONAL
   }

In draft 10, there are now 3 options or variants for the PI which has been 
redefined as:

   PermanentIdentifier ::=     SEQUENCE {
      identifierValue    UTF8String             OPTIONAL,
                      -- if absent, use the serialNumber attribute
                         if there is a single such attribute present
                         in the subject DN
      assigner           OBJECT IDENTIFIER      OPTIONAL
                      -- if absent, the assigner is
                         the certificate issuer
    }

For further details, please take a look at the draft.

(and if you take a close look, you will find a "typo" ASN.1 error,
that will need to be corrected by re-issuing a new draft). :-(

Denis

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 18 Jul 2004 10:42:35 +0200

Denis,
It is good to see that the PI draft is doing progress!

May I comment a bit on this last revision?

>After side discussions initiated by Anders Rundgren and followed
>by Peter Gutmann, I have discussed with my co-editor, the PKIX
>chairs and the security Area Director.

I would like to mention that David Kemp, in his quest for a more
"sane" (Dave's wording) solution for DoD, also posted a scheme
that eliminated the data redundancy or alien CA registry requirements
that my "real world, paper example" :-) showed.  Dave's suggestion
was BTW pretty close to the proposed revision.

Talking about DoD's use of PIs, I do not believe that their current scheme
is "insane" but maybe a tiny, tiny bit "ugly".  A simple RFC3739 "filtering"
process would be enough to make it "beautiful", in X.500 terms.

It is not over until it is over
====================

However, when I performed another "real world, paper example"
on a PI-augmented DoD scheme, I did note a rather significant
loss of "sanity" that I believe the list could comment on as it should
be fairly applicable to most enterprise PKIs.

Assume that a DoD certificate after the PI upgrade contains the following:

Subject DN: CN=John Smith, serialNumber=123456, OU=Army, O=DoD, C=US
PI assigner: 1.23.67.355.23.6.7        (A "sample" OID for the DEERS registry)

The question I tried to answer was simply: How is automated relying
party software supposed to use the enhanced identity information?
Here follows three possible alternatives:

1. X.500-only
==========
ID: CN=John Smith, serialNumber=123456, OU=Army, O=DoD, C=US

This scheme becomes (at least principally) dubious, the moment you start
to deal with multiple assigners (=independent name spaces).   And if you
only intend to use one assigner, the PI extension becomes redundant.

2. X.500 + PI
==========
ID: 1.23.67.355.23.6.7 + CN=John Smith, serialNumber=123456, OU=Army, O=DoD, C=US

This scheme is not exploiting the primary motive for using permanent
identifiers, attribute independence (=being able to change name, location
etc. without getting a "new" identity).

3. PI-only
=======
ID: 1.23.67.355.23.6.7 + 123456

This scheme makes all but one DN attribute redundant.  But the
unused attributes still contribute to shortening the life-time of the
certificate, as well as limiting usage to a single assignment (you will
need a separate certificate for each assignment within the enterprise).

As far as I can see, PI extensions when applied to a large class of
X.500-based systems[1] will probably only add more confusion to
an already complex situation, rather than solving a problem.

Sincerely
Anders Rundgren

1] it is worth noting that PKIs that were designed from scratch to use
PIs (there are several large such), do not suffer from these problems.
However, these PKIs do not follow the X.500 methodology where
an identity is the combination of a set of hierarchical attributes, qualifying
the subject.  In my opinion, the idea that an LDAP entry for an employee
should be linked to a certificate containing a [redundant] copy of the
directory path, is an off-line world relic.  In an on-line world, subject
attributes like location, phone number, bank account, job function etc.
should be dynamically acquired, as well as adapted for the actual
situation and relation.

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 20 Jul 2004 16:02:33 +0200

Anders,

> May I comment a bit on this last revision?

(text deleted)

> PI assigner: 1.23.67.355.23.6.7        (A "sample" OID for the DEERS registry)

This is the fourth case suggested to be supported by James.

> party software supposed to use the enhanced identity information?

This is a good question.

> Here follows three possible alternatives:

The full DN may be used, if the certificate relates through a valid 
certification path to a trusted root key according to some validation policy.

> only intend to use one assigner, the PI extension becomes redundant.

This combination is a not a possible solution.

> ID: 1.23.67.355.23.6.7 + 123456

The PI composed of the two elements mentionned on the above line may be 
used, if the certificate relates through a valid certification path to a 
trusted root key according to some validation policy.

Denis