Subject: Biometrics in Qualified Certificates

From: Stefan Santesson <[email-masked]>
Date: Mon, 22 Mar 1999 11:43:50 +0100

Anders,

At 09:17 AM 3/19/99 +0100, Anders Rundgren wrote:
>2. Hash of biometric data?  Biometrics are analog (inexact) objects that
require
>complicated pattern matching algorithms to be verified.  Regardless if it
is a machine
>or human that is doing the pattern matching they must be in clear.

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.

This also have the advantage that the cert don't reveal the biometrics.
A hash further would serve very well as a distinguisher stored in the
dNQualifier.

If you have any concrete suggestions on how to store biometrics in QC:s
please write a proposal and we will see if there is enough support within
the community to include it. But I have my doubts.

/Stefan 

-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB     
Lotsgatan 27 D                  Tel. +46-40 152211              
216 42  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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

---

From: Michael Sierchio <[email-masked]>
Date: Mon, 22 Mar 1999 08:18:34 -0800

Stefan Santesson wrote:

> >2. Hash of biometric data?  Biometrics are analog (inexact) objects

> data apart from the certificate....

Anders is right.  A hash that is not repeatable or verifiable is
useless.  Biometric data are often never the same twice, even from
the same equipment.  You can have a hash of a *reference* object, 
which of necessity is held by a trusted third party, in which case
there is no point in having it in any form in the cert.  The binding
of the identity to the object is all that matters.

And unless there is complete trust in the device providing biometric
data, and in the channel, you might as well be using cleartext
passwords -- it's subject to replay, man-in-the-middle, etc.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 23 Mar 1999 11:06:56 -0500

Stefan,

>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