[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Unmistakable identity
Stefan,
This proposal does not solve the issue. See my longer mail on that
topic.
> 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.
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
> /Stefan
>
> > -----Original Message-----
> > From: Stefan Santesson
> > Sent: Thursday, May 04, 2000 12:04 PM
> > To: 'Denis Pinkas'
> > Cc: 'Russ Housley'; 'Stephen Kent'; 'ietf-pkix@imc.org'
> > 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:Denis.Pinkas@bull.net]
> > > Sent: Wednesday, April 26, 2000 10:27 AM
> > > To: Stefan Santesson
> > > Cc: Russ Housley; 'Stephen Kent'; 'ietf-pkix@imc.org'
> > > 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:housley@spyrus.com]
> > > > > Sent: Friday, April 14, 2000 4:36 PM
> > > > > To: Stephen Kent
> > > > > Cc: tgindin@us.ibm.com; ietf-pkix@imc.org
> > > > > 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
> > > > >
> > >
> >