Subject: Accessing/selecting biometrics was: Stray Poll: Finger-prints in QCs

From: "Anders Rundgren" <[email-masked]>
Date: Tue, 7 Dec 1999 06:30:07 -0000

Tony, 

Slight comment on a thing of importance that you mention 

<snip> 

>Someone mentioned that the hash is sufficient, since the actual
>data could just "tag along" with the cert, if required. But there
>needs to be a standard even for this kind of operation. Is there?

This was the original QC solution. As you noted (and I have told the 
authors several times) this is a half-made solution. A genuine example 
of poor engineering! 

Then somebody sad: Why not add an URI (option) to hold the actual data. 
Hooray!  Problem solved!   Is it? The idea behind this and the first suggestion 
is probably that the user in some mysterious way is supposed to select 
if he/she is going to give his/her biometrics away. Q: How do you do that 
with the URI-solution? I have never received an answer this! 

So I proposed that you include biometrics in a "biometric cert" and use the 
mechanism already featured in browsers (although biometrics will seldom be used 
in that environment) - certificate selection. The same solution can be applied 
to any "privacy-depriving" certificate. 

         http://www.mobilephones-tng.com/papers/idcards.html 

My bet is: Only really stupid QC implementers will use the current QC scheme for 
biometrics as they are unlikely to be supported by the large SW manufacturers 
as this part is currently simply not ready for use. But of course there is a market 
for proprietary solutions where this fits very nicely... 

Anders

---

From: Stephen Kent <[email-masked]>
Date: Tue, 7 Dec 1999 08:47:18 -0500

Anders,

>authors several times) this is a half-made solution. A genuine example

PKIX creates infrastructure standards.  Specifying a means of binding 
biometric data to a cert is within scope.  specifying a means of 
carrying this data in a wide range of application environments is out 
of scope.  For example, we don't tell IPsec, SSL/TLS, or S/MIME how 
to transport certificates or CRLs in those applications; we just 
define the certificate and CRL formats.  The same principle applies 
here. Having defined a means of binding biometric data to a cert, 
while not putting it in the cert and thus mitigating privacy 
problems, we have done the part of the job that is appropriate for 
this WG.

What aspect of this argument do you not understand?

Steve