Subject: WG Last Call: Permanent Identifier

From: Tim Polk <[email-masked]>
Date: Fri, 24 May 2002 15:55:36 -0400

Folks,

The current version of the Permanent Identifier is ready for Working Group 
Last Call; Last Call will close on or after June 7, 2001.

The draft is named draft-ietf-pkix-pi-03.txt.  The text has been posted and 
is available from the usual repositories, including: 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-03.txt

The current thinking is to progress the document as a standards track document.

Thanks,

Tim Polk

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 24 May 2002 17:04:39 -0400

All PKIX Members:

DO NOT USE THE OBJECT IDENTIFIER IN draft-ietf-pkix-pi-03.txt!  THE OBJECT 
IDENTIFER WAS ASSIGNED BY THE AUTHORS, NOT BY THE REGISTRAR.  THE VALUE IN 
QUESTION HAS ALREADY BEEN ASSIGNED FOR ANOTHER PURPOSE.

Please send mail to [email-masked] if you need to get an object 
identifier assigned by the PKIX Registrar.  I assume I will be hearing from 
the authors of draft-ietf-pkix-pi-03.txt soon ...

Thanks for your cooperation,
   Russ

At 03:55 PM 5/24/2002 -0400, Tim Polk wrote:

>The draft is named draft-ietf-pkix-pi-03.txt.  The text has been posted 
>and is available from the usual repositories, including:

---

From: "Housley, Russ" <[email-masked]>
Date: Fri, 24 May 2002 17:31:03 -0400

I have several comments on the Permanent Identifier Draft.  I have divided 
them between technical and editorial.

TECHNICAL

1.  The OID value { id-on 2 } has already been assigned for another 
purpose.  Please get fresh one.

2.  It is my understanding that international URIs can be encoded as 
IA5String.  This was one of the last issues raised in the development of 
RFC 3280.

3.  I do not understand how the identifierType can be optional.  The whole 
point of this draft is that distinguished names are not sufficiently 
unique.  (I am not trying to reopen this debate; it has been debated at too 
great a length already.)  If this is the case, then it would follow that 
two CAs could have the same distinguished name.  If two such CAs both 
include the proposed extension, then there will be undetectable 
collisions.  The resolution seem to be clear.  Make the identifierType 
mandatory.

4.  The Security Considerations section is pretty weak.  It mostly restated 
the purpose of the extension.  I think that it should contain advice for 
implementors that will make use of the identifier as well as advice for the 
Assigner Authority.  For example, the Social Security Administration would 
be such an authority in the US, and they assign nine digit 
indentifiers.  Are 123-45-6789 and 123456789 the same?

EDITORIAL

5.  Please move the reference to RFC 2119 out of the Abstract.  I think it 
belongs in the Introduction.

6.  Please reference RFC 3280 instead of RFC 2459.

7.  In the second paragraph of the Introduction, the word "it" is 
ambiguous.  I think that it is referring to the subject field.  Please reword.

8.  The document contains many non-ASCII characters.  Please replace the 
"smart" apostrophe and quote characters.

9.  Please change "non repudiation" to "non-repudiation"

10.  Please change "optional" to "OPTIONAL" in the second paragraph of 
section 2.

11.  Please divide the references into two groups: normative and informative.

Thanks,
   Russ