RE: Certificate profile for Biometrics information.

["Ebbe Hansen" <e_hansen@xxxxxxxxxxx>]

Russ, Sam,

Yes - a hash of the template would suffice in cases where the template (and
other bio-parameters) can be obtained (securely) by other means. However, in
cases where such secure infrastructure is not available (or difficult to
manage), I think the encrypted Attribute extension as defined in RFC-3281
could be helpful.

One of the problems that may arise using encrypted Attribute extensions is a
possible need to add "recipients" to the list of trusted recipients already
included in a previously issued AC (holding an encrypted Attribute
extension).  One might consider issuing an additional AC (linking to the
previous AC, or the original PKC?) that will be used primarily to
"distribute" decryption tokens to the additional recipients?

Is their any immediate limitation on how many ACs that may be "linked" to a
previously issued PKC or AC?

Ebbe.

-----Original Message-----
From: Housley, Russ [mailto:rhousley@xxxxxxxxxxxxxxx]
Sent: Monday, November 04, 2002 1:17 PM
To: Sam Schaen
Cc: Stephen Kent; Ebbe Hansen; ietf-pkix@xxxxxxx
Subject: Re: Certificate profile for Biometrics information.

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