[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Unmistakable identity
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'; '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
> > > >
> >
>