Re: New proposed solution to the QC biometric issue

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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

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:

BiometricData ::= SEQUENCE {
typeOfBiometricData TypeOfBioDataSyntax,
mime_type   PRINTABLE STRING,
hashAlgorithm AlgorithmIdentifier,
biometricDataHash OCTET STRING,
}

Regards,

Denis


> /Stefan
> -------------------------------------------------------------------
> Stefan Santesson <stefan@accurata.se>
> 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
> -------------------------------------------------------------------