Subject: RE: Closure of the QC biometric issue

From: Anders Rundgren <[email-masked]>
Date: Mon, 26 Apr 1999 17:32:56 +0200

Congratulations Stefan!
But before you cast it in stone, could you for us morons who do not fully understand the implicit infrastructure that the QC-editors apparently work with, explain a little bit on how "sourceDataUri" is to be used?  E.g. WHO fetches the bio-data?  Authenticated by WHAT?

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

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 27 Apr 1999 09:04:53 +0200

Certainly,

1) URI are defined by RFC 2396.
2) The source data is authenticated by the signed hash of the bio data,
held in the new certificate extension.

/Stefan

At 05:32 PM 4/26/99 +0200, Anders Rundgren wrote:
>Congratulations Stefan!
>But before you cast it in stone, could you for us morons who do not fully
understand the implicit infrastructure that the QC-editors apparently work
with, explain a little bit on how "sourceDataUri" is to be used?  E.g. WHO
fetches the bio-data?  Authenticated by WHAT?
>http://www.mobilephones-tng.com/papers/idcards.html
-------------------------------------------------------------------
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: Anders Rundgren <[email-masked]>
Date: Tue, 27 Apr 1999 10:00:37 +0200

Stefan,
Thanx for a prompt response but my two questions regarding the access to
the bio-data-template-server are still unanswered.
Anders

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 28 Apr 1999 11:21:07 +0200

----- Begin Included Message -----

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 29 Apr 1999 10:48:28 (NZST)

>PLEASE REVIEW THE FOLLOWING ASN.1 STRUCTURE AND COMMENT IN CASE OF ERRORS:
>--------------------------------------------------------------------------
>[...]
>
>TypeOfBiometricData ::== CHOICE {
>     predefinedBiometricType    [0] INTEGER,
>     biometricDataOid           [1] OBJECT IDENTIFIER }

Not really an error but a style and ease-of-use issue: the tags are already
distinct so there's no need to tag these items, which also means you don't hide
ASN.1 type information behind opaque implicit tags.

Peter.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 29 Apr 1999 13:15:14 +0200

Thanks Peter,

I have also got a note from Magnus Nyström, RSA labs, pointing this out.

He proposed that this part should be changed into:

TypeOfBiometricData ::= CHOICE {
     predefinedBiometricType    PredefinedBiometricType,
     biometricDataOid           OBJECT IDENTIFIER } 

PredefinedBiometricType ::= INTEGER {
     picture(0),handwritten-signature(1)}
     (picture|handwritten-signature,...)

Is that OK to you?

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 29 Apr 1999 12:22:43 +0200

Peter,

At 11:21 AM 4/28/99 +0200, Peter Sylvester wrote:
>>From [email-masked] Wed Apr 28 11:05:38 1999
>Date: Wed, 28 Apr 1999 08:59:57 +0200
>> -Source data format information has NOT been included by several reasons.
>> If the sourceDataURI are used then this information is already covered. If
>> sourceDataURI is NOT included then the source data issue have to be handled
>> outside of the certificate anyway, thus making a source data declaration in
>> the certificate of dubious value.
>>
>> -SourceDataUri has been included (as OPTIONAL) since it can be shown that
>> some PKI:s could benefit from this value without causing troubles for other
>> PKI:s.
>>
>How do you calculate the hash of source data starting from an SourceDataUri? 
>Do you take the data, a bitmap, the mime encapsulated data? Do you include
the
>mime type in the hash? Are there other attributes, creation date of the
document,
>etc.

Yes, this is typically something that we have to adress in the text (not
written yet).

If you have a text proposal, I would be very happy to receive it.

My opinion is that the hash should be calculated on the actual data. E.g.
If you have a JPEG image you calculate the hash on the file content, but
not on the filename etc. I'm not sure how to put this in writing so I
welcome suggestions on suitable text wordings.

/Stefan