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