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

From: "Tom Gindin" <[email-masked]>
Date: Thu, 20 Jun 2002 08:09:47 -0400

Bill:

      We are actually adding permanent identifier to GeneralName rather
than to SubjectAlternativeName, although the expected major use is within
SubjectAlternativeName.  If any field in a certificate changes, the
certificate as a whole is considered invalid, so moving this field to a
separate extension would not make it any more useful.  In the current
draft, we try to point out several uses.  The non-repudiation and audit
uses are essentially similar, and would probably work equally well no
matter where a PI was put in the certificate.  The access control use uses
this field to represent a user, and putting PI into GeneralName permits an
access control subsystem to use GeneralName to represent a user, using PI
when desired and some other GeneralName form such as DN or E-mail when PI
is not desired.
      Also, the syntax of PI does not permit an e-mail address to be used.
Of course, it is legal to put an e-mail address into the value field while
giving an identifier type, but it would be more natural to use the e-mail
variant of GeneralName. Our expectation for typical PI's not issued by the
CA is that the most common values will be ID's already assigned to a user
by the organization responsible for the value in IdentifierType such as
account ID's, employee ID's, citizen ID's (a large fraction of the
discussion centered on these), and the like.

            Tom Gindin

Bill Middleton <[email-masked]>@mail.imc.org on 06/19/2002 09:19:49
PM

Sent by:    [email-masked]

To:    [email-masked]
cc:    [email-masked]
Subject:    Re: I-D ACTION:draft-ietf-pkix-pi-05.txt

Hello list members.  I join your company as a X.509 neophyte,
but with high hopes to learn more, and possibly say something
sensible, eventually.

To that end, in this reply, I'd like to raise a couple
of issues with the announcement/proposal below, partially edited:

On Tue, 2002-06-18 at 13:27, [email-masked] wrote:
> 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.

I can see a certain motivation for this, of course, especially
in the case of a marriage-related name-change.  However, I
submit that this proposal will ambiguate (or be ambiguated by)
the currently acceptable and practiced subjectAltName
values.  What if, for example, the permanent
identifier is to be an email address?  Perhaps thats not the
best argument against it, but the currently-defined uses
and intents for subjectAltName seem to me to
preclude its use as a perpetual entity.

If the CA wishes to give the possibility of perpetuity in the
face of altering the Subject DN, then the CA should
encode the  identifier in a DN component which they
will not allow to be changed, yes?

Regards,

Bill Middleton
[email-masked]

---

From: Bill Middleton <[email-masked]>
Date: 20 Jun 2002 16:10:04 +0200

On Thu, 2002-06-20 at 14:09, Tom Gindin wrote:
> separate extension would not make it any more useful.

I'm not convinced that this is the case yet.  It wasn't clear that your 
proposal regarded GeneralName from reading it, but even so, what you
propose is quite significant.  A "perennial" or perpetual field in the
certificate _will_ be quite useful, I believe, but perhaps it 
does justify it's own extension.  I believe a dedicated extension
would also lend to better interoperability between
CAs, as well, once it's accepted.  I can imagine, however, that 
getting a new extension accepted is more challenging, yes?

> variant of GeneralName. 

If it is legal, then confusion could, and probably will, occur.  That
was my only contention.  That said, the authentication possibilities of 
this proposal (embedding permanent username or employee ID numbers) is 
especially tantalizing, and I do like the concept, even if a new
extension is not the way to go with it.

Thanks for your reply, Tom.

Bill