Subject: Re: QC's - for human eyes only?

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 5 Dec 1999 22:55:26 -0000

Eric,

>There's nothing preventing one from sending the biometric outside the
>certificate to be machine verified.  The hash is there to tie that into
>the cert.

The point by Ilan was that the QC draft explicitly calls for HUMAN verification

<snip>

>However putting a biometric in a certificate is like putting your Social
>Security Number and mother's maiden name in a certificate- it would
>allow anyone who receives the certificate to be able to use those
>irrevocable identifiers to impersonate you.

If you steal somebody's private keys, the inclusion of biometric data
in the certificate will on the contrary REDUCE the possibilities to
impersonate the true owner.  Privacy is another thing.

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 6 Dec 1999 11:46:33 +0100

Just some more info for those who still believe finger-prints is marginal technology

----------
From:  Calum Bunney [SMTP:[email-masked]]
Sent:  Monday, December 06, 1999 10:47
To:  'SEIS-List'
Subject:  SEIS: Re: QC's - for human eyes only?

--- Message on the SEIS mailing list ([email-masked])
Can I add to the comments below?
The biometric industry community is moving towards some sort of standardisation in this area, albeit in a piecemeal way.
The National Security Agency in the USA has long been investigating the use of X509 v3 certification for storage of biometric data.  The ANSI X9F4 standards working group is developing a certificate based standard for the secure and responsible management of biometric data, initially for the financial services community.  The Biometric Consortium (www.biometrics.org) is sponsoring a Biometric Common File Exchange Format to find a way of storing biometric data that can invite different biometrics (iris, finger, face etc) and different vendors' solutions to participate in a quasi-universal storage mechanism such as certificates.
There is some recognition of the overlap in biometric standardisation with certificate operation, and this is increasingly recognised as a future technical issue for the emerging biometric standard (www.bioapi.org)
There are indeed at least ten vendors with selling fingerprint technologies.  There are more than fify actual technologies on the market. Among these there are a good number with fingerprint data stored in files between 100 and 400 bytes. Is the general opinion that this is still too large for feasible verification off the certificate, without reliance on a network? I am interested to know the general view on this?
with all good wishes
Calum Bunney
International Biometric & Authentication Consulting

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 6 Dec 1999 13:44:55 +0100

Denis

>Stephen gave the right answer. We should not re-open that
>discussion. We are not "shutting the door on options that technology
>will soon make available". The Version 3 of X.509 certificates
>allows to define other extensions. The one you are requesting could
>be defined later, when it becomes appropriate.

It was appropriate already a year ago.  I don't think it has gotten less interesting.
The problem was (and probably is) that information in certificates cause
self-made "politicians" to destroy a debate that really only concerns a "file-format".

If you look on ID2's home-page you can see that they brag about being number
one in PKI and that they DO combine PKI and finger-prints.  So it is HERE TODAY!

And regarding file-sizes: Extremely depending on the implementation environment
(global Internet consumer, vs corporate intranets) so it is inappropriate of PKIX to decide
here and now what is suitable.

I.e. QC does not and should not recommend any particular solution.  It
should offer a "smorgasbord" of generally useful options in a standardized way.

The suggested items are known and using the MIME-type of definition that
I proposed earlier, they can proliferate on their own merits and pace .

How, when and why certificate information is to be used can surely be discussed forever,
but if we need consensus on that part as well, we can simply terminate the whole thing.

BTW, we just seem to have finally gotten the unique identifier concept through the door
although there were originally many, many opponents to such things...

Anders

---

From: [email-masked]
Date: Mon, 6 Dec 1999 17:54:51 -0500

Consider the distinction between *identification* and *authentication*.
Something makes a good identifier if it points uniquely to what it identifies.
Something makes a good authenticator if it is hard for the wrong entity to
generate it.   If a "secret" authenticator is shared between too many parties
(e.g., SSN, mother's maiden name) it no longer makes a very good authenticator.

What is the nature of a biometric?  A problem for biometrics is that if multiple
systems know and authenticate me by a my fingerprint data, is that data still a
good authenticator?  If the comparison is static, the answer would be "no" for
the same reason as SSNs, etc. are poor.  But if they also use an effective
"liveness" test against static reference data, then the reference fingerprint
data really serves as an identifier and the "liveness" test mechanism really
serves as the authenticator.  In that case what's the problem with including my
fingerprint data in a certificate?

I think the real worry about including a biometric in a certificate is the
potential for privacy invasion, because the biometric in effect becomes an
unchangeable universal identifier - exactly the same concern now about SSNs
being attached to all your records, permitting easy dossier compilation.

A static hash doesn't solve the privacy problem because that hash itself just
serves as the universal identifier.

IMO, the best thing to do with a biometric in connection with PKI is to put it
into a hardware token that protects one's private key corresponding to the
public key in a certificate.  Then it serves as a private user-to-key-device
authenticator which is not shared outside that environment.  No reference to the
biometric content is needed in the certificate for this use.  This use of
biometrics is (1)highly secure (assuming a trusted channel between biometrics
reader and key device) and (2) not a threat to privacy.

-Gene Hilborn

[email-masked] on 12/06/99 03:17:57 PM

To:   [email-masked]
cc:    (bcc: Gene Hilborn/DEF/CSC)
Subject:  Re: QC's - for human eyes only?

If putting biometric data in a certificate is "bad," what about putting a
hash of it?

Or should this type of information be more appropriately stored in a
directory?
----- Original Message -----
From: Tony Bartoletti <[email-masked]>
To: Eric Murray <[email-masked]>; Ilan Shacham <[email-masked]>
Cc: Ietf-Pkix (E-mail) <[email-masked]>
Sent: Monday, December 06, 1999 11:05 AM
Subject: Re: QC's - for human eyes only?

> At 09:00 AM 12/05/1999 -0800, Eric Murray wrote:
>
> >irrevocable identifiers to impersonate you.  So biometric data should
> >only be sent encrypted in a session key, if it's ever sent at all.
>
> This is why "irrevocables" should never be relied upon as identifiers.
>
> I intend to publish my own photographs, fingerprints, retinal scans and
> DNA traces to public fora, precisely to diminish reliance upon them as
> evidence of "me"!  I hope to start a global movement...
>
> Seriously, my philosophic problem with biometrics is that, while the
> "body" is somewhat of a constant, the "person" is not, especially with
> respect to time and circumstance.  Yet (undo) reliance upon biometrics
> tends to reinforce the notion of "once an X, always an X".  That is,
> it will encourage the limitation of "trust" calculations to constants.
>
> ___tony___
>
> Tony Bartoletti                                             LL
> IOWA Center                                              LL LL
> Lawrence Livermore National Laboratory                LL LL LL
> PO Box 808, L - 089                                   LL LL LL
> Livermore, CA 94551-9900                              LL LL LLLLLLLL
> phone: 925-422-3881   fax: 925-423-8081               LL LLLLLLLL
> email: [email-masked]                                   LLLLLLLL
>