Subject: RE: Biometrics in Qualified Certificates

From: Stefan Santesson <[email-masked]>
Date: Mon, 22 Mar 1999 15:55:04 +0100

Let me just sum up Anders proposal:

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

    photo;                           
    handWrittenSignature;            

These attributes should contain:

        mime-type PrintableString, 
        body      OctetString

(Complete definition of attributes has to be done)

Since this is not my field of expertise I would like opinions from the list
whether this is a good approach or not. Please also comment if this should
be addressed at all. 

Will anyone out there use this in your products and services?
Can attributes be defined with a structured body according to the proposal?

/Stefan

At 02:16 PM 3/22/99 +0100, Anders Rundgren wrote:
>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
>
>
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
Accurata Systemsäkerhet AB      http://www.accurata.se
Slagthuset                      Tel. +46-40 108497              
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: Stephen Kent <[email-masked]>
Date: Tue, 23 Mar 1999 10:56:03 -0500

Stefan,
>whether this is a good approach or not. Please also comment if this should

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