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

From: [email-masked]
Date: Wed, 21 Jan 2004 16:26:57 -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-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

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-08.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-08.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: "Jim Schaad" <[email-masked]>
Date: Wed, 21 Jan 2004 18:22:38 -0800

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.
> 
> http://www.ietf.org/internet-drafts/draft-> ietf-pkix-pi-08.txt
> 
> 
> 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

Send a message to:
	[email-masked].
In the body type:
	
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 22 Jan 2004 20:50:50 +0100

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.

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.

I find this "obsession" with permanence wrong, because if a CA disappears,
its regitered DNS name is taken by somebody else, 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.

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.

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.

jim

Send a message to:
[email-masked].
In the body type:

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 23 Jan 2004 14:14:21 +0100

Jim,

Thank you for your document quality checking.

> security considerations section.

This point is already covered. Here is the text :

    The permanent identifier allows organizations to create links
    between different certificates associated with an entity issued
    with or without overlapping validity periods.  This ability to link
    different certificates may conflict with privacy.  It is therefore
    important that a CA clearly disclose any plans to issue certificates
    which include a permanent identifier to potential subjects of those
    certificates.

> name.  Has been removed from the syntax.

You were so fast by replying to the publication, that I had not the time to 
advertise the main reason for issuing this new draft.

It is because the IESG objected to include URI in the document and that we 
(i.e. Tom and myself) have been unable to find a compromise with the IESG. 
So we have removed the URI option. You are correct: this sentence should 
have been deleted.

Done.

> relate to type choice of IdentifierValue as well.)

"identityType" is not used. "identifierType" is used instead.
The ASN.1 for identifierType is :

     identifierType         OBJECT IDENTIFIER      OPTIONAL

The current text is:

    "When two certificates from different CA's contain both the same
    permanent identifier value and the same type of permanent
    identifier from a given Assigner Authority, then these
    certificates relate to the same entity, whatever the content of
    the DN or other subjectAltName components may be."

Changing "same type of permanent identifier" by "Authority Identifer Value" 
would not be appropriate. The identifierType does not simply identify the 
Authority, but also the type of identifier being used.

I would propose the following text:

    When two certificates from the same CA or from different CA's
    contain both the same permanent identifier value and the same
    identifier type value, then these certificates relate to the
    same entity, whatever the content of the DN or other subjectAltName
    components may be.

> 4.  Section 2:  What is the criteria for use of iA5String vs uTF8String?

Good question. No good answer ! I thus propose to simplify and just have the 
following:

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

Here is the new text for UTF8.

    The IdentifierValue supports one syntax: UTF8String. UTF8String is
    variable length data of octets. The UTF8String syntax is used to
    express a string of characters from the Universal Character Set
    - UCS [ISO10646] (a superset of [Unicode]), encoded following the
    [UTF-8] algorithm. The UCS allows support of most of the world's
    writing systems using a single character set.

    Note that Unicode characters U+0000 through U+007F are the same as
    ASCII 0 through 127, respectively, and have the same single octet
    UTF-8 encoding.  Other Unicode characters have a multiple octet
    UTF-8 encoding.

> two different value items?

Added the following:

    The following matching rule SHALL be used for the identifierValue:
    the rule evaluates to TRUE if and only if the code points [Unicode]
    of each of the characters is equal.

Also added the following references:

    [Unicode] The Unicode Consortium, "The Unicode Standard, Version
    3.2.0" is defined by "The Unicode Standard, Version 3.0"
    (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), as amended
    by the "Unicode Standard Annex #27: Unicode 3.1"
    (http://www.unicode.org/reports/tr27/) and by the "Unicode Standard
    Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).

    [ISO10646] Universal Multiple-Octet Coded Character Set (UCS) -
    Architecture and Basic Multilingual Plane, ISO/IEC 10646-1: 1993.

    [UTF-8] RFC 2279. F. Yergeau. UTF-8, a transformation format of
    ISO 10646, January 1998.

> 6.  Section 2: The statement 'It is an OID.' is redundant and can be

OK. Forgotten.

> re-written to state what the one and only matching rule is.

See the response to the issue number 5.

> explicit reference to them.

Added:

-- from [RFC 3280]

Before I update the document and place it on the web server, I would be 
grateful to get your response on these proposals.

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 23 Jan 2004 10:49:54 -0500

Denis and Tom:

Section 3, Security Considerations, Page 4, paragraph 6 for the Section, of
the RFC contains description of how to match PI when identifier type is
absent.

One of the comparison is that of public keys.  While being a good
comparison, it can give you false results in case of CA key roll-over.  Do
you think it is worth mentioning.  The other match described in the same
epigraph for CA names may have problems also if there are any self-issued
certificates for key roll-over. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Denis Pinkas
Sent: Friday, January 23, 2004 8:14 AM
To: [email-masked]
Cc: 'Tom Gindin'; [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt

Jim,

> Comments on draft -08.
> 
> 1.  Privacy concerns should be additionally outlined and covered in 
> the security considerations section.

Done.

> (I find the use of identityType to be confusing since I consider this 
> to relate to type choice of IdentifierValue as well.)

"identityType" is not used. "identifierType" is used instead. The ASN.1 for
identifierType is :

The current text is:

following:

> 5.  Section 2:  When doing comparisons do I need to cross compare 
> these two different value items?

Added the following:

OK. Forgotten.

> 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.

Added:

-- from [RFC 3280]

Denis

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 23 Jan 2004 08:30:44 -0800

Denis,

Thank you -- this addresses all of my concerns.

jim

> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Friday, January 23, 2004 5:14 AM
> To: [email-masked]

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 27 Jan 2004 14:08:02 +0100

Santosh,

> certificates for key roll-over. 

First of all, your remark is fully correct.

The current text is as follows:

     Since a name is only unique towards its superior CA, unless some
     naming constraints are being used, a name would only be guaranteed
     to be globally unique when considered to include a sequence of all
     the names of the superior CAs.  Thus, two certificates which contain
     a permanent identifier extension without a identifierType may have
     their permanent identifier extensions compared for equality either
     by comparing the public key values of the two CAs which have issued
     these two certificates or by comparing the sequence of CA names in
     the certification path from the trust anchor to the CA, inclusive.

I would propose to replace it with the following text:

     Since a name is only unique towards its superior CA, unless some
     naming constraints are being used, a name would only be guaranteed
     to be globally unique when considered to include a sequence of all
     the names of the superior CAs.  Thus, two certificates that are
     issued under the same issuer DN and which contain the same
     permanent identifier extension without a identifierType do not
     necessarily refer to the same entity.

     Additional checks need to be done, e.g. to check if the public key
     values of the two CAs which have issued the certificates to be
     compared are identical or if the sequence of CA names in the
     certification path from the trust anchor to the CA are identical.
     When the above checks fail, the permanents identifiers may still
     match if there has been a CA key rollover. In such a case the
     checking is more complicated.

Denis

---

From: "Santosh Chokhani" <[email-masked]>
Date: Tue, 27 Jan 2004 08:11:35 -0500

Denis:

Sounds good to me.  Thanks.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]] 
Sent: Tuesday, January 27, 2004 8:08 AM
To: Santosh Chokhani
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-pi-08.txt

Santosh,

> Section 3, Security Considerations, Page 4, paragraph 6 for the 
> Section, of the RFC contains description of how to match PI when 
> identifier type is absent.

> comparison, it can give you false results in case of CA key roll-over.  
> Do you think it is worth mentioning.  The other match described in the 
> same epigraph for CA names may have problems also if there are any 
> self-issued certificates for key roll-over.

Denis

> [mailto:[email-masked]] On Behalf Of Denis Pinkas

> "identityType" is not used. "identifierType" is used instead. The 
> ASN.1 for identifierType is :
> 
>>>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.
>>>
>>>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.
>>>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

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 28 Jan 2004 15:38:27 +0100

Anders,

> OIDs, probably due to the authors' belief that OIDs are more permanent.

It was not exactly the author's belief, but the IESG belief.

> 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.

> 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

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.

> 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