Re: Evaluation: draft-ietf-pkix-pi - Internet X.509 Public Key

[Ted Hardie <hardie@qualcomm.com>]

Ted Hardie          [   ]     [   ]       [ x ]      [   ]

Discuss comments:

"An Assigner authority maybe 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"

"representable as a URI" is not particularly strong, and the rest of 
the document's
view of a "permanent  URI" isn't a lot better.  I *think* what they 
mean here
is that the Assigner Authority must have either an IANA-assigned URN 
NID,
or be sub-delegated space under such an assignment.  In other words,
I think they are making a parallel between the URN NID space and the
OIDs assigned for ASN.1/enterprise numbers assigned by IANA.  If that
is the case, this needs to be spelled out; if that is not the case, and 
they
really do mean that any URI should be usable for this purpose, then they
need a _lot_ more text on how.

It also strikes me that the mechanisms for using a Permanent Identifier
cross-CA don't handle some pretty likely issues.  If an attacker can 
read the Permanent
Identifier for some entity out of its certificate, the attacker can then
create a CA and certificate that purports to be about the same
entity.  Of course, no one should trust that certificate just because 
it contains
data supposedly also about the same entity, but given that, it's not 
clear
what the utility is supposed to be to knowing that the two assertions 
are
about the same entity.  If you're supposed to evaluate them 
independently,
what is the win?





o: Internet Engineering Steering Group <iesg@ietf.org>
From: IESG Secretary <iesg-secretary@ietf.org>
Reply-To: IESG Secretary <iesg-secretary@ietf.org>
Subject: Evaluation: draft-ietf-pkix-pi - Internet X.509 Public Key
           Infrastructure Permanent Identifier to Proposed Standard
--------

Last Call to expire on: 2002-12-9

        Please return the full line with your position.

                    Yes    No-Objection  Discuss *  Abstain


Harald Alvestrand   [   ]     [   ]       [   ]      [   ]
Steve Bellovin      [   ]     [   ]       [   ]      [   ]
Randy Bush          [   ]     [   ]       [   ]      [   ]
Bill Fenner         [   ]     [   ]       [   ]      [   ]
Ned Freed           [   ]     [   ]       [   ]      [   ]
Ted Hardie          [   ]     [   ]       [   ]      [   ]
Russ Housley        [ X ]     [   ]       [   ]      [   ]
Allison Mankin      [   ]     [   ]       [   ]      [   ]
Thomas Narten       [   ]     [   ]       [   ]      [   ]
Erik Nordmark       [   ]     [   ]       [   ]      [   ]
Jon Peterson        [   ]     [   ]       [   ]      [   ]
Bert Wijnen         [   ]     [   ]       [   ]      [   ]
Alex Zinin          [   ]     [   ]       [   ]      [   ]



 2/3 (9) Yes or No-Objection opinions needed to pass.

 * Indicate reason if 'Discuss'.

^L
To: IETF-Announce:;
Dcc: *******
Cc: RFC Editor <rfc-editor@isi.edu>,
 Internet Architecture Board <iab@iab.org>, ietf-pkix@imc.org
From: The IESG <iesg-secretary@ietf.org>
Subject: Protocol Action: Internet X.509 Public Key Infrastructure
           Permanent Identifier to Proposed Standard
-------------


The IESG has approved the Internet-Draft 'Internet X.509 Public Key
Infrastructure - Permanent Identifier' <draft-ietf-pkix-pi-06.txt> as
a Proposed Standard. This document is the product of the PKIX Working
Group.  The IESG contact persons are Russ Housley and Steve Bellovin.

Technical Summary

This document define a new form of name, called permanent identifier,
that may be included in the subjectAltName extension of an X.509
version 3 public key certificate. The permanent identifier is an
optional feature that may be used by a Certification Authority (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 identified 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.

Working Group Summary

The Working Group came to consensus on this document.

Protocol Quality

This document was reviewed by Jeffrey I. Schiller for the IESG.