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

From: "Tom Gindin" <[email-masked]>
Date: Thu, 20 Jun 2002 10:52:04 -0400

Bill:

      Thanks for your comments.  Responses below.

            Tom Gindin

Bill Middleton <[email-masked]>@mail.imc.org on 06/20/2002 10:10:04
AM

Sent by:    [email-masked]

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    [email-masked], [email-masked]
Subject:    Re: I-D ACTION:draft-ietf-pkix-pi-05.txt

On Thu, 2002-06-20 at 14:09, Tom Gindin wrote:
>       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.

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?

[TG] I see your point about clarity, since the abstract and the first half
of the introduction make the field sound as if it were intended solely for
use within SubjectAltName.  Section 2 does define it within the GeneralName
structure, but the second sentence of the second paragraph might be better
worded (by replacing "in SubjectAltName" by something more like "whose most
common use is in SubjectAltName").  The abstract could also include a
reference to use of PI in other uses of GeneralName, if it's worthwhile.
The difficulty of getting a new extension accepted is not an issue - get a
new OTHER-NAME form accepted is roughly as difficult.  I don't know why
using a dedicated extension would lead to better interoperability between
CA's than using OTHER-NAME.  The only interoperability advantage which I
can see to a dedicated extension is that it would have its own criticality
flag, but this should be balanced against losing the use of the field for
access control.

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

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.

[TG] A CA could put an RFC-2253 compliant LDAP form of a DN in a value as
easily as an e-mail address.  That is equally far from our recommended use.
Perhaps we should have given examples of appropriate uses within the draft.

Thanks for your reply, Tom.

Bill