[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
> > >
>