Re: Certificate profile for Biometrics information.

["Housley, Russ" <rhousley@xxxxxxxxxxxxxxx>]

Sam:

That would allow someone who validated the certificate to determine whether 
a particular biometric template was known to the CA at the time the 
certificate was signed.  The relying party would need to obtain the 
template and an input form other sources.

I do not know the problem that Ebbe is trying to solve, so I do not know if 
this meets his needs.

Russ

At 03:42 PM 11/4/2002 -0500, Sam Schaen wrote:

> Would an acceptable approach be to create a one-way function between the
> biometric data and the digest?  Similar to the hash algorithm used for
> signatures, the objective would be to make it virtually unlikely that two
> biometric captures could lead to the same digest but that having the 
> digest, it
> would not be feasible to obtain the biometric.  Certainly a hash meeting those
> characteristics could be included in a certificate without violating privacy
> concerns and without making imperonation of the biometric characteristics 
> easier
> than they currently are.
>
> -Sam
>
> Stephen Kent wrote:
>
> > At 11:12 AM -0800 11/4/02, Ebbe Hansen wrote:
> > >Steve,
> > >
> > >I would consider storing of a biometrics "digest" (sometimes also called a
> > >template) to be the minimum biometrics information that could be 
> included in
> > >a certificate (possible in an Attribute Certificate). Type of biometrics
> > >(finger, iris, facial, etc), "digest/template" algorithm, etc. could 
> also be
> > >useful. I just learned the XML working group already has a draft out (Ref.
> > >http://www.oasis-open.org/committees/xcbf/#documents).
> > >
> > >For individuals and/or organizations that are concerned about privacy
> > >issues, one could consider support of an encryption option where selected
> > >"trusted readers" could be enabled using specific session-key tokens,
> > >possibly included (under user or organization control) on the same
> > >smart-card that holds the certificate(s) with the biometrics extension(s).
> > >
> > >Ebbe
> > >
> >
> > Ebbe,
> >
> > I suspected that templates were what you envisioned putting in certs.
> > The problem is that unless these values are encrypted, exposing
> > templates makes them available for the sort of off line guessing
> > attacks I mentioned.  This is not only a "privacy" issue, but very
> > much a security issue. Certs are generally viewed as being
> > transmitted over insecure channels and stored in repositories that
> > are not necessarily confidentiality-secure.
> >
> > If it is necessary to encrypt these values for security, as suggested
> > above, then I would want to see a proposed solution that provides
> > confidentiality in a fashion consistent with some credible example
> > scenarios. Note that if the template in the extension is encrypted
> > prior to inclusion in the cert (as I would expect), then the key
> > management process for disclosing this data to a "trusted reader" is
> > a lot more complex than typical "session key" management schemes of
> > the sort I think you alluded to above.
> >
> > Steve