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