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

From: [email-masked]
Date: Thu, 05 Dec 2002 09:26:10 -0500

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-06.txt
	Pages		: 12
	Date		: 2002-12-4
	
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-06.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-06.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-06.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, 05 Dec 2002 16:21:51 +0100

Some additional information about: draft-ietf-pkix-pi-06.txt

The editors have received a request from the security area Director,
Jeff Schiller to add some clarifications.

"This document appears to introduce the notion of an Assigner Authority, but 
never really defines it. Is it a government, a corporation, an enterprise, 
all of the above? There should be a section that discusses this. Note: If it 
is defined elsewhere, then an appropriate normative reference should be made."

We have added text on page 2, section 1, to define it:

    A permanent identifier consists of an identifier value assigned
    within a given naming space by the organization which is
    authoritative for that naming space.  Such an organization is known
    as an Assigner Authority.

    An Assigner Authority may be a government, a government agency, a
    corporation, or any other sort of organization.  It MUST have a
    unique identifier to distinguish it from any other such authority.
    In this standard, that identifier MUST be an object identifier or
    be representable as a URI.

"An important consideration is missing from the Security Considerations. 
Namely, that there is nothing that prevents a CA from issuing a certificate 
with a globally unique permanent identifier that belongs to an entity 
different then the entity that is controlling that certificates private key. 
I.e., there is no technical enforcement mechanism to ensure that only global 
identifiers approved of by the correct Assigner Authority are placed in a 
certificate."

There is no enforcement, but the CA is responsible for all the information 
present in the certificate. We have added text in section 3:

    It is the responsibility of the CA to verify that
    the permanent identifier being included in the certificate refers
    to the subject being certified.

During the last IETF Last call (not to be confused with the WG last call) 
the editors have received a request to add some more material in the 
informative annex.

We also have added a new section B3 and the authors have indicated to us 
that they were satisfied with the addition.

For all these reasons a new draft has been submitted and placed on the web 
server.

Denis