Subject: RE: Unmistakable identity

From: Stefan Santesson <[email-masked]>
Date: Thu, 4 May 2000 12:34:46 +0200

Going through the definition in the QC profile, I would suggest this minor
change in section 2.4

And change:

 2.4  Uniqueness of names

   Requirements on name uniqueness are described in this standard
   through the terms "distinguished name" and "unmistakable identity",
   having the following meaning:

To:

 2.4  Uniqueness of names

   Functional and uniqueness requirements on names are described in 
   this standard through the terms "distinguished name" and 
   "unmistakable identity", having the following meaning:

This would then clarify the concept of functional requirement related to the
term unmistakable identity.

Since this is just a minor fix. I will see through that this is added to the
next draft for the IESG process that will be submitted on Friday.

/Stefan

> -----Original Message-----
> From: Stefan Santesson 
> Sent: Thursday, May 04, 2000 12:04 PM
> To: 'Denis Pinkas'
> Cc: 'Russ Housley'; 'Stephen Kent'; [email-masked]'
> Subject: Unmistakable identity
> 
> 
> Denis,
> 
> Some comments regarding DN and Unmistakable identity.
> 
> DN is a technical requirement.
> Unmistakable identity is a functional requirement.
> 
> The DN requirement is fullfilled if the CA assignes you a 
> unique number, e.g. "123456931", but destroys any useful 
> information regarding who is the person behind that number.
> 
> For this identity to also serve the purpose of being an 
> unmistakable identity, the CA MUST provide the nessecary 
> framework to ensure that this identity also can be used to 
> identify the person "Denis Pinkas" (at least in case of a dispute).
> 
> Actually the definition of unmistakable identity says it all, 
> and is relevant.
> 
> With respect to the EU directive, the PKIX document is an 
> international document, not only driven by the EU directive. 
> Eventhough, the concept of unmistakable identity applies also 
> EU even if this term is not explicitly defined in the directive.
> 
> /Stefan
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Wednesday, April 26, 2000 10:27 AM
> > To: Stefan Santesson
> > Cc: Russ Housley; 'Stephen Kent'; [email-masked]'
> > Subject: Re: Permanent identifiers in QC
> > 
> > 
> >  
> > > Folks, I've been sort of off-line the last days.
> >  
> > > So as caching up with this thread I think we need to decide 
> > the progress of
> > > this issue.
> >  
> > > I would just want to add an observation regarding NR and 
> > Authentication.
> > > The issue is NOT whether permanent identifiers are of value for
> > > Authentication or NR. What IS an issue is whether it is 
> > relevant for NR to
> > > be able to compare 2 names in 2 different certificates and 
> > ensure that these
> > > certificates identifies the same person EVEN if some parts 
> > of the DN is not
> > > matching.
> > 
> > For non-repudiation, the permanent identifier may be used to link
> > different transactions to the same individual, even when the subject
> > name of the individual changes. So it is relevant.
> > 
> > > This particular aspect is only raised as a feature for 
> > access control (when
> > > an entity changes his certificate, or possesses several 
> > certificates with
> > > different DN). In the case of NR and legal signatures, the 
> > only issue is to
> > > establish the relation between a certificate and the 
> > individual key holder
> > > (regardless of other certificates). Here the current 
> > profile provides the
> > > necessary means.
> > 
> > No. See above.
> > 
> > > But....
> > 
> > Following the discussion on the serial Number and the Permanent
> > Identifier that took place on the PKIX mailing list and at the last
> > IETF meeting in Adelaïde, I am paying more and more attention to the
> > QC draft.
> > 
> > The document is defining the concept of "unmistakable identity". Now
> > that we have introduced the use of serialNumber, I wonder why such a
> > concept is still needed.
> > 
> > First, the wording "unmistakable identity" is not used in the
> > Directive, so this is the first reason why I wonder it is needed.
> > 
> > Second, let us recall, what RFC 2459 says:
> > 
> >    The subject field from a public key certificate identifies the 
> >    entity associated with the public key stored in the subject
> > public 
> >    key field.  The subject name may be carried in the subject field 
> >    and/or the subjectAltName extension.
> > 
> >    Where it is non-empty, the subject field MUST contain an X.500
> >    distinguished name (DN). The DN MUST be unique for each subject
> >    entity certified by the one CA as defined by the issuer name
> > field.
> > 
> > The current specification (QC-03) mandates the use of the subject
> > field. In such a case, as defined *in RFC 2459*, the name is unique.
> > Moreover, it is unique not only at an instant of time, but during
> > the whole life of the CA. Note that ISO/ITU X.509 does not mandate
> > this and I guess this is where the problem comes from. The current
> > QC-03 document references *X.501* while it should reference RFC
> > 2459. If we were *only* using the subjectAltName extension then such
> > a concept could be useful. But at the present time, we don't.
> > 
> > The chapter 2.4, called Uniqueness of names, should be deleted.
> > 
> > I would also propose the following rewording for section 3.1.2:
> > 
> > 3.1.2 Subject
> > 
> >    The subject field MUST contain an X.500 distinguished name (DN).
> >    The subject field from a public key certificate identifies the 
> >    entity associated with the public key stored in the subject
> > public 
> >    key field. The DN MUST be unique for each subject entity
> > certified 
> >    by the one CA as defined by the issuer name field. 
> > 
> >    The subject field SHALL contain an appropriate subset of the
> >    following attributes:
> > 
> >       countryName;
> >       commonName;
> >       surname;
> >       givenName;
> >       pseudonym;
> >       serialNumber;
> >       organizationName;
> >       organizationalUnitName;
> >       stateOrProvinceName
> >       localityName and
> >       postalAddress.
> > 
> >    Of these attributes, the subject field SHALL include at least one
> > of
> >    the following:
> > 
> >       Choice   I:  commonName
> >       Choice  II:  givenName
> >       Choice III:  pseudonym
> > 
> >    The subject field MAY contain other attributes.
> > 
> >    Any other attributes that MAY be present in either the subject 
> >    alternative name extension or the subject directory attributes 
> >    extension MAY help to give a better human understanding of who 
> >    the individual really is, but uniqueness of the name is achieved 
> >    singly by the subject field. 
> > 
> > The countryName attribute value (... then continue with the current
> > text)
> > 
> > As a result of this, the wording "unmistakable identity" should be
> > deleted from the whole document. In this way, we will be able to
> > suppress ambiguous sentences, like in 3.1.2 :
> > 
> > "  Certificates compliant with this profile SHALL at the same time 
> >    specify a distinguished name and an unmistakable identity of the 
> >    subject (see 2.4 for definition of distinguished name and 
> >    unmistakable identity).
> > 
> >    Attributes stored in the subject field SHALL at least form a
> >    distinguished name of the subject, but they MAY also specify a
> >    complete unmistakable identity."
> > 
> > 
> > I reproduced below an extract from Annex I from the European
> > Directive on Electronic Signatures:
> > 
> > " Requirements for qualified certificates
> > 
> > Qualified certificates must contain:
> > 
> > (...)
> > 
> > (c)	the name of the signatory or a pseudonym, which shall be
> > identified as such;"
> > 
> > 
> > > Regardless of this I agree with Steve that this issue 
> > should be advanced on
> > > it's own and merged later if it's found relevant to do so.
> > 
> > Anyway, I am preparing some text to describe what a permanent
> > identifier is and in which OID arc it should be located. This should
> > be ready at the end of this week. In this way we will be able to
> > discuss whether the permanent identifier should be, for the time
> > being, an independent RFC that the QC draft could reference, or
> > whether it should be an RFC of its own.
> > 
> > Regards,
> > 
> > Denis
> > 
> >  
> > > I would therefore request the QC profile to be advanced in 
> > it's current
> > > shape (except for a minor noted update in the reference list).
> > > 
> > > Steve:
> > > How do we proceed.
> > > 
> > > /Stefan
> > > 
> > > > -----Original Message-----
> > > > From: Russ Housley [mailto:[email-masked]]
> > > > Sent: Friday, April 14, 2000 4:36 PM
> > > > To: Stephen Kent
> > > > Cc: [email-masked]; [email-masked]
> > > > Subject: Re: Permanent identifiers in QC
> > > >
> > > >
> > > > I agree with Steve.  Note that the CAT Working Group has 
> > defined an
> > > > OTHER-NAME for Kerberos names.
> > > >
> > > > Russ
> > > >
> > > >
> > > > At 02:02 PM 04/13/2000 -0400, Stephen Kent wrote:
> > > > >Tom,
> > > > >
> > > > >I have no problems with the sorts of IDs you proposed 
> in your ASN
> > > > >GeneralName Other-Name examples. They seem to be 
> > consistent with the
> > > > >arguments that Denis has made for such constructs. However,
> > > > before we add
> > > > >these to the updated part 1, I think we need more time to
> > > > explore the
> > > > >utility for these name forms.  The debate on the list shows
> > > > that there are
> > > > >widely diverse opinions about what such IDs are good for,
> > > > what scope is
> > > > >feasible/appropriate, etc.  I'd hesitant to hold up 
> > progress on the
> > > > >revision to 2459 to add this sort of facility which has been
> > > > proposed only
> > > > >recently.  That's why several folks have suggested a 
> > separate, small
> > > > >document whoch can be advanced separately, and merged into
> > > > 2459 if there
> > > > >is sufficient, consistent support.
> > > > >
> > > > >Steve
> > > >
> > 
>

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 11 May 2000 13:00:41 +0200

Stefan,

This proposal does not solve the issue. See my longer mail on that
topic.

> next draft for the IESG process that will be submitted on Friday.

We need a MAJOR fix. I do not think it is appropriate to submit the
draft to the IESG at the time being. We need to solve this issue
first.
Denis