Subject: RE: Biometrics in Qualified Certificates

From: Anders Rundgren <[email-masked]>
Date: Mon, 22 Mar 1999 14:16:07 +0100

Stefan,
You would save some list-bandwidth by reading my posts more carefully.  So the
following is a compilation of previous posts.

>Anders Rundgren wrote:
>>2. Hash of biometric data?  Biometrics are analog (inexact) objects that
require
>>complicated pattern matching algorithms to be verified.  Regardless if it
is a machine
>>or human that is doing the pattern matching they must be in clear.

>A hash would work just fine given that you provide the complete biometric
>data apart from the certificate. You could send a Jpeg picture attached to
>your document and have a hash of the picture in the cert.
>This also have the advantage that the cert don't reveal the biometrics.

Although QCs is about the use of digital signatures, the QC spec. will affect (or it
will simply be just IGNORED) the format of authentication certificates as well.  Therefore
I think that the example you gave is not entirely valid (apart from the introduction of a non-
standard and awkward way to transfer identity information).  So may I ask:

Does your local bank clerk read hashed pictures?  Or the police?  Or the passport control?

And for those who are Directory Aficionados:  Who and when would have access to the
TRUE biometrics?   It seems awfully much simpler to let the user handle
this (how have I already described zillions of times so I won't repeat it) but actually
- this decision is outside the scope of the QC draft.

>A hash further would serve very well as a distinguisher stored in the
>dNQualifier.

This is as far from an SSN you can get as every new photo will generate
a new hash value.  But as I said earlier: if the deployer wants to do something that
you (or in this case I) consider stupid we should only comment on it as long
as the feature does not jeopardize or affect the "good", "sensible" and "politically
correct" usage.

As an analogy,  we will obviously never agree on the use of SSNs (or rather static bindings)
and we don't have to either.  I like them, you don't.  No problems!  Let the market decide!

>If you have any concrete suggestions on how to store biometrics in QC:s
>please write a proposal

Has already been posted. Tom Gindin / IBM "ASN.1-ized" my crude sample

DisplayableImage ::= SEQUENCE
    {
      mime-type PrintableString, 
      body      OctetString
  }

Note: According to Peter Gutman there already are OIDs for various multimedia types
so the above may be overkill.

My proposal is to add a few commonly used (since 50 years back or so) biometrics to
the list of standard QC attribute types.  From the draft:

Complying applications SHALL expect any subset of the following defined attribute types 
within a PersonalDataRecord:

countryName;
givenName;
surname;
pseudonym;
dNQualifier;
dateOfBirth;
placeOfBirth;
gender;
postalAddress; 
countryOfCitizenship; 
countryOfResidence;

 +

photo;                               (DisplayableImage)
handWrittenSignature;             (DisplayableImage)

 +

maybe a few other biometrics like fingerprints that are more or less standardized.

Your QC-colleague Tim Polk should be able to supply you with this information since NIST
has indeed standardized fingerprint data.

>and we will see if there is enough support within
>the community to include it. But I have my doubts.

If you by "community" refer to the IETF and the PKIX-list you are definitely off-track.
QCs are of concern far outside the scope of TLS to name an other example.

If you care to read a document in early alpha-stage on why I think it is fairly easily
to find powerful supporters for biometric data in certs, please read this:

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

which I have prepared in great haste (pardon the grammatical errors) in order to also
give our non-ASN.1 readers a chance to see what this is all about.

BTW, has the QC task-force actually talked to FBI and immigration authorities?

Regards

Anders Rundgren
Senior Internet e-commerce Architect
http://www.mobilephones-tng.com

---

From: Anders Rundgren <[email-masked]>
Date: Mon, 22 Mar 1999 16:46:19 +0100

Short reply,
>Let me just sum up Anders proposal:

>Add new supported attributes to the list in the PersonalData field:

>    photo;                           
>    handWrittenSignature;            

>These attributes should contain:

>(Complete definition of attributes has to be done)

Tom Gindins code looked OK to me.  But my ASN.1 sucks so I may be wrong!

>Since this is not my field of expertise I would like opinions from the list
>whether this is a good approach or not. 

ID-card forging becomes much harder.  That should IMO be a sufficient
reason to add support for biometrics. see:
http://www.mobilephones-tng.com/papers/idcards.html#READ_AND_WEEP

>Please also comment if this should
>be addressed at all. 

Assume that only 2% need this.  Would you then say it should not be there?
I would at least not stop these 2% from doing something that the other 98% are
completely unaffected by.  In analogy with SSNs that will not generate consensus.
The only reason that SSNs in QCs are not controversial is that you named
them dnQualifiers :-)

>Will anyone out there use this in your products and services?

Wrong forum Stefan!

(Although I obviously does not count I will use photos in remote certs in CyberPhone)

>Can attributes be defined with a structured body according to the proposal?

Do you also have a problem with ASN.1  :-)

Anders

---

From: Mike Smith <[email-masked]>
Date: Mon, 22 Mar 1999 07:52:08 -0700

Just an observation concerning signed biometric representations.  Biometrics are based on "good enough" data.  Digital signatures (including signed certs) are based on exactness.

If using the best image, most complete scan, etc. and then signing that, then everything else will fail up to that same level of "exactness" contained in the cert.  I doubt that any biometric data that is less exact enough to "always" be captured in the biometric device will have any authentication value on its own.

It seems that encoding a "master" or most exact biometric in the certificate would still have some value for disseminating the biometric data between biometric systems without alteration enroute, but I do not see a real use for using signed biometric data outside these specialized systems at this time.

I do think that the PKIX certificate profiles and naming should support biometric data encoded into the subject alt name, I just see its use way off in the future.

michael

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 23 Mar 1999 20:45:32 +0100

Just to clarify this,

THIS IS NOT MY PROPOSAL!!!!!

I was just summing up Anders proposal in order to get reactions on it.
And personally I don't like it either of several reasons besides the ASN.1.
So we agree on that point.

Read my reasons below.

At 10:56 AM 3/23/99 -0500, Stephen Kent wrote:
>>whether this is a good approach or not. Please also comment if this should
>>be addressed at all.
>
>As I mentioned in another message, this is still bad syntax, i.e., there is
>no justification for using a MIME type for these images.  You certainly
>would need more realistic proposed syntax before proceeding. As for your
>second query, my position is that it is a bad idea to put such information
>into a public key certificate.
>
>Steve
>

Here are my primary reasons for not liking this:

1) There is a conceptual difference between biometric data and ID-reference
attributes. ID-attributes are used as index for identity searches in a
direct and well understood way, while biometric data have a much more
unclear usage when included in a certificate.

2) The concept of data storage is different. With ID-attributes, the data
is a direct and exact representation of the attribute value, while
biometrics are an approximation of the original information object. This
requires further agreements in order to successfully understand and use the
information.

3) While use of ID-attributes is well understood and can relate to existing
products and widely adopted procedures, biometrics are not (to my
understanding).

4) The set of supported attributes SHALL form an unmistakable identity,
even if other information, such as biometric data, are included. If
bio-metrics are included in the set of supported attributes, we then say
indirectly that it's OK to form an unmistakable identity ONLY based on
these bio-metrics. And I don't like that at all. This is to me another
reason to handle bio-metrics as a different type of descriptive information
(If handled at all at this stage).

/Stefan

-------------------------------------------------------------------
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, 25 Mar 1999 11:50:58 +0100

Yes this is pretty much what I had in mind.

We all agree that the complete template has to be processed by the
comparing algorithm. Inclusion of just a hash of the templace in a
certificate enables authentication of the template when the pre stored
template itself is retreived from another source, e.g. an unsecure
directory, or supplied as part of a message.

Still, I don't say that this is the preferred way, but it could be in some
cases. At least it may provide necessary functionality without displaying
the template in the certificate.

/Stefan

At 04:32 AM 3/24/99 -0500, Stephen Kent wrote:
>Stefan,
>
>>Agree to all.
>>
>>What I mean is: Whatever is used as the approximation data of a biometric
>>property of the subject, this can be hashed and signed in the certificate.
>>The hashed data has then to be supplied separate from the cert.
>>
>>This will work. Desired? I don't know. But it has it's pros and cons.
>>
>>The example of a hashed static picture can be used if I want you as a
>>recipient to se my face and to know that this static image shows the face
>>of the owner of the certified key.
>>
>>Desired? I don't know, but it would work and it has its pros and cons as
well.
>
>I'm not sure I understand your example here; let me try to describe what i
>think you might have meant.
>
>The template against which a captured biometric is compared must be
>available in unhased form for processing.  The goal is to know that this
>template is correctly associated with the user in question. So, yes, one
>could store the template somewhere and then bind it to the user via a hash
>of the template embedded in a public key or attribute cert. This is a
>different strategy from what was originally proposed, namely inclusion of
>the template itself in a certificate. The question then arises as to
>whether it is preferable to bind the template to the user in this fashion.
>
>Let me know if this is what you had in mind.
>
>Steve
>