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

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

At 01:37 PM 4/19/99 -0400, Stephen Kent wrote:

<<snip> 

<excerpt>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.

</excerpt>

Steve,

I have given this quite a thought the last days and I must say that I
would favor an OPTIONAL URI pointer.

The rationale is mainly:

1) It doesn't matter from which source the relying party gets the source
data (e.g. picture) as long as it does match the hash. So the optional
URI are not THE place to get the information, but rather A place to find
it. What I mean by this is that there is no conflict if the source data
is provided by several means.

2) The authentication process could then be carried out independent of
the transaction. I.e. the relying party could verify and display the
picture regardless of which protocol the certificate was used and/or
presented.

So, what I see before me with a hash AND an optional URI of a picture, is
standard clients that automatically displays the picture of the subject
when they get hold of a certificate, without having to integrate that
process with the corresponding transaction protocol where the certificate
is used.

Because if the URI is not allowed, then the process of obtaining the
source data will have to be solved by locally defined standards,
integrated with some protocol. And that will never be a general standard
solution.

Further, since we clearly focus on two types of bio-data (picture and
signature image) I would also favor that these types are associated wit a
predefined integer value (not needing an OID).

By the reasons above I propose this ASN.1 structure for a bio-data
record:

   BiometricData ::= SEQUENCE {

         typeOfBiometricData  TypeOfBioDataSyntax,

         hashAlgorithm        AlgorithmIdentifier,

         biometricDataHash    OCTET STRING,

         sourceDataUri        IA5String  OPTIONAL}

   TypeOfBioDataSyntax ::== CHOICE {

         predefinedBioType    [0] INTEGER,

         bioDataOid           [1] OBJECT IDENTIFIER } 

with the following predefinedBioType defined (so far):

	0    picture

	1    handwritten signature

Concerning source data format I don't believe that has to be addressed
any further. 

If an URI are used, then this is solved automatically. If not, this will
have to be defined by local conventions. In extreme cases, the OID choice
of TypeOfBioDataSyntax should be used to define both type and format.

/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: Denis Pinkas <[email-masked]>
Date: Thu, 22 Apr 1999 15:14:34 +0200

Stefan,

My comments are along the lines.

>  Stephen wrote:
> <snip>
>
>      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.
>
> Steve,
>
> I have given this quite a thought the last days and I must say that I would favor an OPTIONAL URI pointer.

Also I do not feel strong on this issue, I would favor the opposite. :-(

The rational is as follows:

1) This data is private and may be released onbly if the subject wishes it. So it is very unlikely that you will find it in an URL free of access.
2) If the indication to fetch the information points to one of out several places, some people are going to argue that a sequence of such info is needed.

The basic question is whether the certificate should refer to the location of the biometric data or whether the biometric data should refer to the information in the certificate. I would think that the opposite is more meaningful.

> The rationale is mainly:
>
> 1) It doesn't matter from which source the relying party gets the source data (e.g. picture) as long as it does match the hash. So the optional URI are not THE place to get the information, but rather A place to find it. What I mean by this is that there is no conflict if the source data is provided by several means.
>
> 2) The authentication process could then be carried out independent of the transaction. I.e. the relying party could verify and display the picture regardless of which protocol the certificate was used and/or presented.
>
> So, what I see before me with a hash AND an optional URI of a picture, is standard clients that automatically displays the picture of the subject when they get hold of a certificate, without having to integrate that process with the corresponding transaction protocol where the certificate is used.
>
> Because if the URI is not allowed, then the process of obtaining the source data will have to be solved by locally defined standards, integrated with some protocol. And that will never be a general standard solution.

Beware. You mean that the standard solution will be to use the OPTIONAL field. :-)

> Further, since we clearly focus on two types of bio-data (picture and signature image)

maybe 3 three: add "fingerprint" whether it is coded as a bit-map or whatever.

> I would also favor that these types are associated wit a predefined integer value (not needing an OID).

Agreed.

> By the reasons above I propose this ASN.1 structure for a bio-data record:
>
> Concerning source data format I don't believe that has to be addressed any further.
> If an URI are used, then this is solved automatically. If not, this will have to be defined by local conventions. In extreme cases, the OID choice of TypeOfBioDataSyntax should be used to define both type and format.

No. there are multiple ways to encode a picture, so the type of encoding cannot be derived from the type of biometrics information. It may be useful to know in advance the encoding, to know if it can be processed.

I got a proposal from Anders Rundgren which solves the problem. He suggested to use mime-types
that allow to represent picture, sound. movie, text-file, xml-file, java-object etc. We could thus add a mime type defined as:

    mime_type   PRINTABLE STRING,

i.e. the string contains a text-string like "image/jpeg" . The advantage to using this scheme is that there already are many types defined.

As a conclusion I would favor:

mime_type   PRINTABLE STRING,
}

Regards,

Denis

> Stefan Santesson <[email-masked]>

---

From: Ben Laurie <[email-masked]>
Date: Thu, 22 Apr 1999 15:11:32 +0100

> 1) This data is private and may be released onbly if the subject wishes it. So it is very unlikely that you will find it in an URL free of access.

What has this got to do with anything? Or are you suggesting that not
revealing the URL will secure it?

> 2) If the indication to fetch the information points to one of out several places, some people are going to argue that a sequence of such info is needed.

So give them a sequence! Is there a shortage or something?

> The basic question is whether the certificate should refer to the location of the biometric data or whether the biometric data should refer to the information in the certificate. I would think that…

Which one is the opposite? If you mean that the biometric data should
refer to the cert, how do I find it when all I have in my hand is a
cert?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi