Subject: RE: New proposed solution to the QC biometric issue

From: Anders Rundgren <[email-masked]>
Date: Wed, 14 Apr 1999 17:12:14 +0200

<snip>

Stefan,

This is a little bit like the DS issue.  Without any specified infrastructure the
inclusion of hashed biometrics in QCs becomes too theoretical.

Being the originator of the request for biometric data in QCs I feel bad about
the idea of hash of biometrics since this is very inconvenient (my guess) compared to
store the real thing in "signed, certified, structured, container" that a certificate
is.  If this is "all we get" you could IMO equally well drop it entirely as all serious
implementers will probably use other measures to achieve the functionality required. 

For an almost complete down-to-earth ASN.1-free solution trying solve today's problems
with current technology, please look into:

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

This solution is (mainly) intended for use locally in banks, security controls etc. where you want
to know that the bearer of a card is the person it was issued for.  Not exactly rocket-science
(application-wise) but pretty useful anyway.  And unlike current photo-cards impossible to forge.

But I do believe that fully automatic fingerprint verification as a COMPLEMENT to the ID-cert
and PIN-code would work wonders in entrance controls.   To steal both a person's card, PIN-code
AND forge a "finger emulator" seems pretty hard.  Actually there is a much bigger risk associated
with persons you trust which no digital signature, biometric or whatever has a cure for!

The presented solution works fine with current smart-card technology which I also find
important since most QCs will probably be stored in such.

Regards
Anders Rundgren
Senior Internet e-commerce Architect
+46   70 - 627 74 37

PS If you insist on the hash scheme I think that it makes sense to write a simple spec.
on how you meant that it should work as well.   There is a bit more to biometrics than
just ASN.1-code... DS

>Well, since then I have had a lot of off list discussions ending up in a
>new conclusion:

>1) It could be valuable to include support for biometric data aimed for
>human verification (not machine verification), e.g. human verification of
>picture image or signature image. In fact face recognition and signature
>recognition are regarded as the two major implementations which justify
>this proposed expansion of the draft. 

>2) The supported solution should only address storage of a hash value of
>biometric data. This would provide all necessary functionality for
>authenticating bio-data without loading the certificates to much.

>3) Storage of bio-data-hash should NOT be done in the PersonalData field
>since this data is conceptually different from id-attributes. Further,
>since bio-data need storage of 2 parameters (OID + hash), those values
>can't be stored in a single predefined attribute. Instead a new optional
>extension should be defined for this purpose.

>Petra Glöckner has prepared a proposal for this new extension in QC as
>follows:

>Extension ::=  SEQUENCE {
  >extnId              OBJECT IDENTIFIER,
  >critical            BOOLEAN DEFAULT FALSE,
  >extnValue           OCTET STRING }

>biometric 	EXTENSION ::= {
  >SYNTAX            BiometricSyntax
  >IDENTIFIED BY     id-qext-biometric }

>id-qext-biometric    OBJECT IDENTIFIER  ::= {id-qext xx}

>BiometricSyntax  ::=  SEQUENCE OF BiometricData

>BiometricData	::=	SEQUENCE {
  >typeOfBiometricData  OBJECT IDENTIFIER
  >biometricDataHash    OCTET STRING }

>So with this concrete proposal I would like to reopen the issue for
>comments on this.

Thanx!

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 15 Apr 1999 09:39:22 +0200

Good idea Stephen,

I like the idea to include an URI, Im not so sure that the OID should be
excluded though. But maybe the best thing would be to make both OID and URI
optional.

/Stefan

At 04:42 PM 4/14/99 +0100, Stephen Farrell wrote:
>
>Stefan,
>
>Haven't followed this but a couple of thoughts occur:
>
>- if you're only storing a hash, how do I find the 
>original - maybe a URI is needed in addition
>
>- if you buy into the above, couldn't the URI replace
>the OID (since e.g. a HTTP response has a MIME type
>which identififes at least the syntax and also 
>identifies the transfer encoding of the actual data)
>
>- you'll need an algo id somewhere or you can't recalc. the
>hash
>
>- you'll need to specify how the actual data is to be
>flattened before hash calculation (e.g. strip CR/LF or
>whatever), this could be incorporated with the
>algo id (so use a transform id)
>
>Regards,
>Stephen.
>
>
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

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

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 15 Apr 1999 15:32:02 +0200

Denis,

In general good suggestions but I oppose to the following general approach:

At 12:42 PM 4/15/99 +0200, Denis Pinkas wrote:
<snip>
>"In order to achieve a balance
>between these two opposite requirements the hash values of some
>additional attributes can be placed in a public key certificate."

As a general approach this would be a bad thing to do.

Most name attributes doesn't have enough name space for a hash to provide
any protection against exhaustive search for the originating data.

Say for example that you provide hash on names. It would not be to hard to
make an exhaustive search on frequent names and thereby find most of the
names through their hash.

The same with a social security number or a birth date. The name space are
in these cases tiny compared to the computing power of a single workstation.

So providing additional "hidden" attributes by providing their hash will
generally require some additional construct algorithm which prevents
exhaustive search (e.g. adding random data and/or combining several
attributes), and such logic is well beyond the scope of the QC work (As I
see it now).

/Stefan

---

From: [email-masked]
Date: Thu, 15 Apr 1999 13:07:20 -0400

Wouldn't a better syntax for URIorOIDsyntax be

   URIorOIDsyntax ::== CHOICE {
      uri            IA5String,
       biometricType    [0] IMPLICIT OBJECT IDENTIFIER
   } ?

     You could add a third choice value as:
      stdBiometricType [1] IMPLICIT StdBiometricType
   StdBiometricType ::= INTEGER {
     PICTURE_GIF (0), HANDWRITTEN_SIGNATURE_GIF(1)      -- more to follow
   }
     I think you have to specify both the format and the interpretation of
a graphic for pictures and manual signatures.

          Tom Gindin

Petra Gloeckner <[email-masked]> on 04/15/99 11:54:36 AM

To:   Denis Pinkas <[email-masked]>
cc:   [email-masked] (bcc: Tom Gindin/Watson/IBM)
Subject:  Re: New proposed solution to the QC biometric issue

Denis Pinkas wrote:
>
> >From these examples, it can be seen that a URI is not mandatory, but the
> name of the corresponding file would be usefull as well as the type of
> biometric information. As far as the typeOfBiometricData is concerned I
> would prefer an integer instead of an OID: it is shorter (when
> certificates are stored in smart cards) and we could expand the list of
> integers as needed. At the time being, two integers seem sufficient
> (picture or manual signature).
>

Denis,

why would you like to include the name of the corresponding file in
the certificate as well?

Without this name I'd suggest the following structure considering the
comments of Stephen and you:

   BiometricData ::= SEQUENCE {
         URIorOID         URIorOIDsyntax,
         hashalgorithm        AlgorithmIdentifier,
         biometricDataHash    OCTET STRING }

   URIorOIDsyntax ::== CHOICE {
      uri            [0] IA5String
         typeOfBiometricData  [1] INTEGER }

with the following types of biometric data defined so far:
     0    picture
     1    manual signature

Best regards - Petra

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 15 Apr 1999 21:52:12 +0100

Stephen,

>original - maybe a URI is needed in addition

Absolutely!  Although I am more into calling them URLs...

Unfortunately this scheme has a few inherent problems that some of the
other proposed schemes do not exibit:

1) Who has access to these URIs?  Assuming they are networked this
is a problem.

2) The exclusion of the "real thing" from QCs makes it impossible to sign
in a STANDARD way (PKCS #7) and retaining biodata as the URIs do
not have to be accessible for anyone and they may also die after the
cert has expired. 

3) One (networked) fetch for each biometric attribute slows down the process a bit.

Regards
Anders
http://www.mobilephones-tng.com

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 16 Apr 1999 08:37:36 +0100

Paul,
<snip>>

>I'm puzzled.  A week or two ago it sounded like this whole topic had
>been talked to death and was being set aside entirely.  Now it seems
>all to be coming back again.  Do we have to debate the entire thing
>all over?

Paul,
I understand that you are puzzled.  The problem is that the IETF have grossly
underestimated the task of making a QC profile that will get the importance it should.

I think that QCs as a whole should haven been discussed in an own list by people
who have interests in this and have a wider background than just PKI. 
Now the PKIX-list is filled with (for many people) annoying, and largely uninteresting posts.
In the case of bio-metrics it is IMO as an initial step enough to find out:

1) What kind of bio-metric data that should be supported and why

2) How the infrastructure is supposed to work (in particular access to the original bio-data template).
There could be a few variants here are otherwise consensus may not be reached

When the requirements are known - then it is time for the ASN.1 - people
to make a TECHNICAL solution.  Of course there must be technical discussions
going on from the start to see that the end-result is useful.  

But this wish is probably MUCH too late to be realized.

Anders

---

From: "Peter Williams" <[email-masked]>
Date: Fri, 16 Apr 1999 17:08:23 -0500

Some biometric primers:

http://www.dss.state.ct.us/digital.htm

http://www.biometrics.org/
 
The PKIX QC project may not solve the probably
unsolvable Internet-name problem; but it may enable 
PKIX  to properly address biometrics!

Peter.

---

From: "Peter Williams" <[email-masked]>
Date: Tue, 20 Apr 1999 11:00:30 -0500

Specifying an "Optional" QC-extension-based URI name/locator to
subject's bio-template data is fine.

Peter.

    -----Original Message-----
    From: Stephen Kent <[email-masked]>
    To: Peter Williams <[email-masked]>
    Cc: [email-masked] <[email-masked]>
    Date: Monday, April 19, 1999 9:52 PM
    Subject: Re: New proposed solution to the QC biometric issue

    Peter,

    >I fail to see how one can rationalize the need of putting a CRL iDP
(with
    >http reference) into a cert, but one cannot point to user information
    >in similar form, on similar grounds. And similarly for the PKIX
    >CPS-reference - where additional CA-related information is
    >bound to the certificate via a PKIX-standarized https reference.

    I disagree with the analogy. The examples you cite involve pointers to
information that in intrinsic to the management of a PKI, and we have
reasonably well-described architectures that calls for inclusion of these
values in certs. the biometric data is anciliary, employed for user
authentication, not certificate validation, and we have no corresponding
architecture for use of the biometric data. I might be persuaded to provide
an OPTIONAL pointer field if more evidence accumulates in favor of such, but
it is not in the same category as the other pointers you cite.

    >If one were to accept the argument presented, then PKIX
    >should require SSL and S/MIME protocols to convey iDP
    >addressing signals, and ban CRL locating information from PKIX certs.

    see comments above.

    >Similarly, the CPS http reference put into 2459 by one of the WG
    >chairs should be presumably immediately banned - as bad practice. If
    >its technically inappropriate to convey legalistic user references, it
is
    >technically
    >inappropriate to convey rather similar authority references which
further
    > (legally) describe that PKI party!

    see comments above.

    >There is another side to this story, however. Based on the language
    >and intent of PKIX 2459, those deploying Internet CAs already
    >have all the freedom they need to do as some on the list are describing
:-
    >
    >- One can note that PKIX users may already name themselves using a
    >URI name-form - and in a manner wholly consistent with RFC 2459.
    >
    >- Should they name themselves with an https URI which happens to point
    >to their biometric profile, then I can only conclude that 2459 already
    >allows
    >what is being argued here in policy-regimes which establish their own
    >operating rules - as contemplated and facilitiated by PKIX 2459.
    >
    >- The URI name form plus the QC hash value can seeming
    >work together fine to accomplish what some people on the mailing list
want.
    >
    >- Those relying parties who respect a policy id which binds the URI
name and
    >hash fields at cert-processing time can now implement the desired
    >application
    >of PKIX certs. They can even now use certs to signal
    >specific biometric template data - as incorporated via a hash-based
secure
    >URI reference - into their policy-based cert issuing and handling
    >procedures.

    Very creative Peter, and syntactically valid, but I think it violates
the semantics of the subjectAltName field. 2459 says "The subject
alternative names extension allows additional identities to be bound to the
subject of the certificate." The URI you propose including is not the
identity of the subject; but is a blob of bits used to help authenticate the
subject's identity.

    Steve