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

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 2 Jun 2004 07:24:44 +0200

>It is my hope that PI will become an RFC in the near future, so
>that certificates (from an un-named large PKI :-) that currently
>handle PIs by munging them into Common Name (e.g.,
>CN="Kemp.David.P.0514101404") will have a saner alternative.

Since you apparently plan to put PI through the litmus test, may I
repeat my request for a brief description of how you see that likely
DN name clashes should be handled when the current identifier
is removed from CN?  Among possible alternatives I note:

1. Ignoring subject DN name clashes [1]

2. Having the CA issue and keep a specific registry [2] of "nonsense"
    name disambiguers.  Putting such disambiguers in serialNumber

3. Inserting the existing permanent identifier in serialNumber.  This
   is more or less a duplication of the PI object

4. Other?

best
Anders R

1] violates RFC3039

2] is effectively an RFC3039 requirement as DNs must never be
    reassigned

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 02 Jun 2004 13:57:57 -0400

The problem isn't ambiguity, the problem is permanence and
signalling.

It would be wonderful if a new subject distinguished name
structure could be established along the lines you suggest:

   A. CN=David Kemp; SN=1234567; DC=megabank; DC=com

or even using a new Account Assigning Authority RDN attribute:

   B. CN=David Kemp; SN=1234567; AA=megabank.com

But I'm enough of a pragmatist to believe that Country-based
kitchen-sink DNs will not go away in my lifetime no matter
how ugly they are.  Closed PKIs can choose to use clean
account-based DNs, but as long as some PKIs might use DNs
with nonce disambiguators, general purpose applications
will need custom configuration and multiple logic paths to
know if and where an account number / PI can be found,
unless a PI standard is adopted.

So to answer your question starting with the DN example
from RFC3280, the original (#1 below) is invalid in
general because it might clash, (2a and 2b) contain a
nonce disambiguator, and (3a/3b/3c) contain a larger
disambiguator that may or may not be a permanent identifier.
If (3) is a PI, then it might be assigned by the issuing
CA, by the subject's organization nist.gov.US, or by
a third party such as DEERS for DoD users.

   1.  CN=Tim Polk; OU=nist; O=gov; C=US

   2a. CN=Tim Polk.3; OU=nist; O=gov; C=US
   2b. CN=Tim Polk; SN=3; OU=nist; O=gov; C=US

   3a. CN=Tim Polk.1234567; OU=nist; O=gov; C=US
   3b. CN=Tim Polk; SN=1234567; OU=nist; O=gov; C=US
   3c. CN=Tim Polk; SN=1234567; E=[email-masked]; OU=nist; O=gov; C=US

The problem that a PI standard needs to solve is allowing
an application to examine a certificate following one of
many pre-existing DN schemas and determine if that
certificate contains a PI.  So your alternative 3 would
be "inserting the existing serialNumber in the permanent
identifier", not the other way around.  It would be nice
to be able to avoid duplication, so alternative 4 would
be for the PI altname to contain only the account assigner
and for the DN serialNumber to contain the account number.
Alternatives 2, 3, and 4 are all OK, 1 is not.

------------------------------

My preferred syntax for the PI otherName form would be:

PermanentIdentifier ::= SEQUENCE {
    identifierValue     UTF8String  OPTIONAL,
    identifierAssigner  UTF8String  OPTIONAL
}

If the identifierValue field is omitted, the value MUST be
contained in the last serialNumber RDN of the subject field
of the certificate.

The identifierAssigner field, if present, MUST contain a Domain
Name System (DNS) name in the "preferred name syntax" as specified
in RFC 1034.  If the identifierAssigner field is omitted, the
identifier assigner is the issuer of the certificate.

Dave

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 2 Jun 2004 20:45:23 +0200

<snip>

>identifier assigner is the issuer of the certificate.

C'mon Dave, this PI scheme would be compatible with RFC3039
and much existing PI practice!  I thought this was out of question?

:-) :-)

A margin comment:  Although my ASN.1 surely sucks, shouldn't
there be a [] or two to properly spice this up?

best
Anders

---

From: "David P. Kemp" <[email-masked]>
Date: Wed, 02 Jun 2004 15:22:28 -0400

Ahh, I had fancied that my ASN.1 did not suck, but you have
shattered that illusion.  It does need a [] or two:

PermanentIdentifier ::= SEQUENCE {
     identifierValue     [0] UTF8String  OPTIONAL,
     identifierAssigner  [1] UTF8String  OPTIONAL }

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 03 Jun 2004 20:05:32 +1200

"David P. Kemp" <[email-masked]> writes:

>Ahh, I had fancied that my ASN.1 did not suck, but you have shattered that
>illusion.  It does need a [] or two:

I wasn't sure of Anders was being sarcastic or not (that is, commenting on the
massive overuse of redundant tags in most PKIX standards).  Since it was a
serious comment, it only needs one tag, on the second UTF8String.

Peter.