Subject: Re: Biometrics in Qualified Certificates

From: "Peter Williams" <[email-masked]>
Date: Fri, 23 Apr 1999 12:11:46 -0500

-----Original Message-----
From: Stephen Kent <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: [email-masked]' <[email-masked]>
Date: Tuesday, March 23, 1999 1:14 PM
Subject: RE: Biometrics in Qualified Certificates

>Stefan,
>>
>>Add new supported attributes to the list in the PersonalData field:
>>
>>    photo;
>>    handWrittenSignature;
>>
>>These attributes should contain:
>>
>>        mime-type PrintableString,
>>        body      OctetString
>>
>>(Complete definition of attributes has to be done)
>>
>>Since this is not my field of expertise I would like opinions from the
list
>>whether this is a good approach or not. Please also comment if this should
>>be addressed at all.
>
>As I mentioned in another message, this is still bad syntax, i.e., there is
>no justification for using a MIME type for these images.  You certainly
>would need more realistic proposed syntax before proceeding.

You may wish to define a name form for the alternative subject name
extension, as permitted by X509 and PKIX. Its form can be
a MIME-encoded name, an SMTP-extended address field, etc.

My reading of PKIX-1 is that implementations receving such
a field should not balk at its mere inclusion, unless the security
policy (or CertPolicyId or KeyUsageRestriction) they are enforcing
is more strict than RFC 2459 regarding the extension and
extension-value schema rules.

As for your
>second query, my position is that it is a bad idea to put such information
>into a public key certificate.

X.509 supports the idea that an opaque data field created by
the Naming Authority be conveyed in a public-key certificate,
to engender assurances relevant to uniqueness of
(subject) naming (vs key certification) quality.

"A certification authority produces the certificate of a user by signing
(see clause 9)
a collection of information, including the user’s distinguished name and
public key, as well
as an optional unique identifier containing additional information about the
user. The exact
form of the unique identifier contents is unspecified here and left to the
certification
authority and might be, for example, an object identifier, a certificate, a
date, or some
other form of certification on the validity of the distinguished name. "

>Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 24 Mar 1999 04:50:31 -0500

Peter,

>extension-value schema rules.

Yes, one could do what you say, Peter, but it seems to make no sense to use
any MIME encoding here, given the binary nature of certificates.  Thus, the
WG co-chair would not view such a proposal as appropriate, unless you can
provide some good rationale for it.  Extensible syntax is not a license to
do silly things; we always need a good rationale for adding extensions,
name forms, etc.

>other form of certification on the validity of the distinguished name. "

But the argument that has been made here is not the use of this data for
further qualification of a user DN; it is "let's find a place in a cert to
put some data we think might be useful in some application contexts."

Steve