Subject: Re: Biometrics in Qualified Certificates

From: Stefan Santesson <[email-masked]>
Date: Tue, 23 Mar 1999 17:33:45 +0100

Steve,

Agree to all.

What I mean is: Whatever is used as the approximation data of a biometric
property of the subject, this can be hashed and signed in the certificate.
The hashed data has then to be supplied separate from the cert.

This will work. Desired? I don't know. But it has it's pros and cons.

The example of a hashed static picture can be used if I want you as a
recipient to se my face and to know that this static image shows the face
of the owner of the certified key.

Desired? I don't know, but it would work and it has its pros and cons as well.

/Stefan 

At 11:06 AM 3/23/99 -0500, Stephen Kent wrote:
>Stefan,
>
>>A hash would work just fine given that you provide the complete biometric
>>data apart from the certificate. You could send a Jpeg picture attached to
>>your document and have a hash of the picture in the cert.
>
>Yes, one coud do this if the hash was created from the JPEG picture you are
>sending, but that picture could not be one that was just captured by a
>camera as  part of verifying who is currently present at some location.
>This is because that captured image will certainly differ from the one used
>to generate the hash, and so there will always be a mismatch.
>
>So, if what is happening here is sending a static picture and having a
>recipient match it against a hash in a cert, what's the purpose?  This is
>not the aplication that usually comes to mind when one talks about
>biometric user authentication.
>
>If the goal is to provide a certified photo image of a user for visual
>inspection by another person, I agree with David Kemp, i.e., make this a
>separate object, signed by whomever is appropriate, which may not be a CA!
>After all, a CA ought not include the hash in the cert without having the
>picture in gand and matching the picture to the user.  But our standards
>for user or RA interaction with a CA don't necessarily require such
>physical presence.
>
>In general, I would suggest putting images, to be used in human-verified,
>in-person authentication systems, into separate objects.  Otherwise the
>result would be a very big cert, and a raft of privacy issues that have
>been discussed previously.  There is a natural tendency to try to put more
>stuff into certs, because certs are extensible, signed data objects, and
>have a raft of associated protocols for transmission, storage, etc.
>
>Remember the words of a former (in)famous U.S. Attorney General, "we could
>do it, but it would wrong."
>
>Steve
>
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. +46-40 108497              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------

---

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

Stefan,

>Desired? I don't know, but it would work and it has its pros and cons as well.

I'm not sure I understand your example here; let me try to describe what i
think you might have meant.

The template against which a captured biometric is compared must be
available in unhased form for processing.  The goal is to know that this
template is correctly associated with the user in question. So, yes, one
could store the template somewhere and then bind it to the user via a hash
of the template embedded in a public key or attribute cert. This is a
different strategy from what was originally proposed, namely inclusion of
the template itself in a certificate. The question then arises as to
whether it is preferable to bind the template to the user in this fashion.

Let me know if this is what you had in mind.

Steve