Subject: RE: Unmistakable identity

From: Stefan Santesson <[email-masked]>
Date: Fri, 12 May 2000 12:12:57 +0200

Denis and others,

I could spend my and your time by going into detailed argument with Denis,
but I won't.
Let me instead try to clear the table and state the case in few words.

There are some main functional requirements that limits the scope of the QC
profile:
1) The certificate is aimed to support electronic signatures.
2) The certificate is issued to a human person.
3) The profile is based on RFC 2459

To reflect this, there are two requirements on name/identity information of
the subject.
1) The DN in the subject field must be unique (at least within the issuer
domain).
2) It must be possible to determine (possibly with assistance from external
authorities) who the certificate subject is (the physical person). At least
in case of a dispute.

In the QC profile the first aspect is defined as a "distinguished name" and
the second aspect is defined as an "unmistakable identity". 
These functional/technical requirements are present ONLY because if they are
not met, the profile is no longer within it's scope.

Finally. 
This concept has been in the profile, unchallenged, since the very
beginning. It's relevant and forms the base of the scope of the profile.
To change this now at this final state would be devastating.

I think it's more appropriate to ship this now to RFC and continue this
"philosophic" discussion on the road from "proposed" to "draft".

/Stefan

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Thursday, May 11, 2000 12:55 PM
> To: Stefan Santesson
> Cc: 'Russ Housley'; 'Stephen Kent'; [email-masked]'
> Subject: Re: Unmistakable identity
> 
> 
> Stefan,
> 
> Since I have been travelling quite a lot, here is my (late) answer
> while showing very quickly in my office.
> 
> > 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.
> 
> So why the DN must be kept "user friendly". :-)
> 
> > 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).
> 
> I would prefer to consider the case of "Bob Smith" because there are
> probably more than 1.000 "Bob Smith" around the world but only one
> "Denis Pinkas". :-)
> 
> 
> > Actually the definition of unmistakable identity says it all, and is
> > relevant.
> 
> Sorry. The definition is not relevant and cannot not apply when you
> consider homonyms, which is a real life case.
> 
> > 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.
> 
> Besides the fact that the notion is not in the Directive, I would
> like that you consider the following example, and, if you really
> think that the notion is relevant, explain how you can solve the
> case. Otherwise ...
> 
> I will thus repost one of my previous message that has been
> augmented with an example. Notice that I am providing a text change
> proposal to update the draft.
> 
> Denis
> 
> ================================================
> 
> The term "Unmistakable identity" is not used anywhere in the
> Directive on Electronic Signatures, so this is not a requirement
> from the Directive. Furthermore, the Directive explicit asks for the
> support of pseudonyms, for which the concept of unmistakable
> identity cannot apply.
> 
> This term is defined under section 2.4 which is called Uniqueness of
> Names. It should be noticed that the subject name, which is mandated
> by the QC-03 specification, shall already be unique as this is
> mandated by RFC 2459. It should be noticed that X.509 does not
> mandate uniqueness of names, but that RFC 2459 does. This means that
> once a name has been given it must never be re-used for another
> individual within the life time of the CA. The definition of
> unmistakable identity is thus not needed. 
> 
> Forgetting for a while, the argument of uniqueness, the concept
> could possibly be understood as providing sufficient information so
> that a human being may figure out without any ambiguity who the
> person is. One problem is that the attributes for leaving out any
> ambiguity may be scattered everywhere in the certificate, even as
> attribute extensions, so that it is impossible for a relying party
> to know which of them *must* be used to build the unmistakable
> identity. In other words there is no distinction between attributes
> that make the name unmistakable and just "useful" attributes.
> 
> The second problem is that it is only possible to solve ambiguities
> if the relying party is informed of such a possibility. Let us
> illustrate this using an example: Some one knows Bob Smith working
> in the Sales department from the Delta company. Another Bob Smith
> later on enters the company. He will be named Bob Smith 2 also
> working in the Sales department from the Delta company. How can a
> relying party know make the difference between the two persons ?
> They have different (unique) names indeed, but who is who ? 
> 
> If some one want to verify a signed message from Bob Smith 2 working
> in the sales department from the Delta company, he will know that
> there is/was another Bob Smith working in the sales department from
> the Delta company. Since he does not necessarily have access to a
> Directory to see the certificate from Bob Smith (1), he cannot make
> the difference.
> 
> It should also be noticed that the attributes registered in the
> certificate from Bob Smith were perfectly unambiguous when Bob Smith
> was registered but may not be sufficient any more when another Bob
> Smith comes in. One way to solve the problem would be to revoke the
> certificate from Bob Smith to include more distinctive attributes.
> However, it does not seem adequate to perform a revocation for such
> a case.
> 
> If someone gets a signed messages from Bob Smith working in the
> sales department from the Delta company, he does not even know that
> there exists another Bob Smith 2 working in the sales department
> from the Delta company and that the normal signatory of the message
> should be Bob Smith 2 instead of Bob Smith. 
> 
> This problem could, in theory, be solved with an access to all the
> certificates issued by the CA. Since there is no requirement to make
> all these certificates accessible (in particular for privacy reasons
> and to avoid spamming) this problem cannot be solved in such a way.
> 
> This problem could also, possibly, be solved as indicated before by
> identifying all the attributes that make the name unmistakable and
> by revoking previously issued certificates in case there would be an
> ambiguity with a formerly issued certificate. The problem is that we
> are also dealing with long term validity of electronic signatures
> and that expired certificates cannot be revoked anymore. 
> 
> As a conclusion:
> 
> The concept of unmistakable identity should be dropped from the
> QC-03 document.
> 
> 
> Proposed rewording for section 3.1.2 of QC-03:
> 
> 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)
> 
> 
>  
> > /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: Stephen Kent <[email-masked]>
Date: Fri, 12 May 2000 11:37:28 -0400

Folks,

	- The WG last call will begin on the Attribute Certificate ID 
<draft-ietf-pkix-ac509prof-03.txt> and end on May 26.

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 15 May 2000 10:20:30 +0200

Stefan,

My comments along your text.

> I could spend my and your time by going into detailed argument with Denis,

Answering to the issues that have been raised could spare much of
your time, *my* time and ... also the time of the WG. 

> authorities) who the certificate subject is (the physical person). At least

I fully agree with these statements. The problem is that this is not
what the current draft reflects.

In particular the second requirement can be met, as you recognize
just above, without placing any specific/additional information in
the certificate. In the case of a dispute, the certificate serial
number which designates unambiguously the certificate allows to know
who the human person is using the identification information that
was presented at the time of registration.

> the second aspect is defined as an "unmistakable identity".

No. This is not what the document says.

> "philosophic" discussion on the road from "proposed" to "draft".

This is obviously not my opinion. I have provided an example (see
the "Bob Smith" example below) and I still would like to read your
response to that example. Not responding could be interpreted that
you do have have an appropriate response.

Denis