Subject: Re: Permanent identifiers in QC

From: Russ Housley <[email-masked]>
Date: Sat, 01 Apr 2000 02:51:46 -0500

I cannot see any reason for PKIX to specify a permanent identifier.

In my view, it is the job of PKIX (in the son-of-RFC2459 document and the 
companion QC document) to specify the means to bind an identity to a public 
key.  This does not include specifying new methods of specifying an 
identity.  If some Internet application needs a permanent identifier, then 
the needy application should specify it.  Once it is specified, it can be 
used in certificates, just like all of the other name forms that are 
already supported.

Russ

At 04:19 PM 03/30/2000 +0930, Stefan Santesson wrote:
>The PKIX meeting in Adelaide raised only 1 issue related to the QC draft.
>
>This issue is whether we should include a new name form in the
>subjectAltName extension holding  a permanent identifier.
>
>The permanent identifier would then be a name of the subject, unique within
>the issuers domain, that is not reused over time for another subject.
>
>The reason to include such a name form would be that the use of serialNumber
>in DN, or directoryName in subjectAltName extension, does not explicitly
>define this property by itself, unless seen in the light of a defined policy
>etc.
>
>Chair Stephen Kent decided that the decision whether or not to include this
>name form in QC should be taken to the list.
>
>My observation in regards to this is:
>
>1) Adding this name form would add confusion to the QC specification since
>it would overlap use of serialNumber in the DN.
>
>2) Use of DN attributes covers all needs related to identification of the
>subject, and that's all we need to support electronic signatures, at least
>as seen from the EU-directive. And as far I know, this goes for any other
>legal system.
>
>3) Use of DN in combination with either implicit knowledge, use of Directory
>name in the subjectAltname ext, use of a related policy identifier or use of
>information in the qcStatements extension also provide support for use of
>permanent identifiers identified as such.
>
>4) In each and every case raised in favor of this new name form, the benefit
>relates to access control rather than electronic signatures.
>
>5) This is a new input to the discussion, which before adoption must be
>reviewed by the community over some time.
>
>Observation 4 makes this whole discussion outside the scope of QC and in
>combination with the other observations, I would request that the QC is
>moved forward to proposed standard without this new name form.
>
>If PKIX at a later stage would find that a permanent identifier solution, as
>discussed here, is of general value, then this can be moved forward as a
>separate item. At that time we would also know if it should be merged with
>RFC 2459 or the QC profile, if merged at all.
>
>
>
>/Stefan

---

From: Stephen Kent <[email-masked]>
Date: Fri, 7 Apr 2000 17:16:48 -0400

Folks,

I have worked my way through most of the 1600+ messages that arrived 
during the two weeks I was in vacation in NZ prior to the IETF 
meetings (when I chose not to read mail), plus a week in Australia 
w/o e-mail access (where I was, for various reasons, not able to read 
mail).

Looking over this thread, and recalling Denis's presentation in 
Adelaide, I agree with Stefan that IF we were to adopt a permanent ID 
name type in PKIX, the motivations cited by Denis for his proposal 
are access control based and thus NOT suitable for inclusion in the 
QC document.  Also, since there is still disagreement over other 
motivations for such identifiers, and their form in QCs, I think it 
unwise to incluide them in the QC document at this late date. Thus I 
believe that we are ready to proceed with the QC document.

Mike and Russ argue that the creation of new name forms based on a 
perceived semantic requirement is outside the scope of PKIX, i.e., it 
should be an application-specific profile created by the appropriate 
WG. I am sympathetic to these observations, but I also agree that if 
there is a need for such forms of IDs, and if they span multiple 
applications, then we could reasonably define them in PKIX.  It's 
clear that there is not general agreement on this point for now, and 
that leads me to say that we ought not put a new name form into the 
updated 2459 that is now in progress. However, i do not object to 
Denis writing a brief I-D describing the proposed new name form, and 
the motivations for it, and having that progress as a separate work 
item.  If it turns out that there is substantial support for this, 
both in the WG and in implementations, then we could merge it into 
2459 at a future date.

Comments?

Steve