Subject: Closure of the QC biometric issue

From: Stefan Santesson <[email-masked]>
Date: Mon, 26 Apr 1999 11:08:43 +0200

All,

I've tried my best to interpret the consensus, as far possible, regarding
inclusion of biometric data in Qualified Certificates.

The final (I hope) solution to this issue are definition of a new optional
extension with the structure below.

I know that this is not what everybody would like, but I hope that
everybody can live with this as an acceptable solution, at this stage of
evolution.

Some final comments follow in the end.

PLEASE REVIEW THE FOLLOWING ASN.1 STRUCTURE AND COMMENT IN CASE OF ERRORS:
--------------------------------------------------------------------------

Extension	::=	SEQUENCE {
  extnId		  OBJECT IDENTIFIER,
  critical		  BOOLEAN DEFAULT FALSE,
  extnValue		  OCTET STRING }

biometric 	EXTENSION ::= {
  SYNTAX		BiometricSyntax
  IDENTIFIED BY		id-qext-biometric }

id-qext-biometric    OBJECT IDENTIFIER	::= {id-qext xx}

BiometricSyntax	::=	SEQUENCE OF BiometricData

BiometricData ::= SEQUENCE {
    typeOfBiometricData  TypeOfBiometricData,
    hashAlgorithm        AlgorithmIdentifier,
    biometricDataHash    OCTET STRING,
    sourceDataUri        IA5String  OPTIONAL  }

TypeOfBiometricData ::== CHOICE {
     predefinedBiometricType    [0] INTEGER,
     biometricDataOid           [1] OBJECT IDENTIFIER } 

with the following predefinedBiometricType defined:
	0    picture
	1    image of handwritten signature

Minor comments:

-Fingerprint has not been included due to the fact that fingerprint
templates are used in machine verification, using a verification algorithm,
while biometrics in this extension are aimed for human recognition.

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

-No storage of the source data itself has been included since this is not
the way we want certificates to be used (according to consensus). The
source data are never needed for security reasons, only for convenience,
and we don't want to encourage overloading the certificate with data for
convenience. Especially not when there are other ways to solve the same
problem (such as using the sourceDataURI)

If there are no serious objections to this (which has not already been
discussed), I would like to bury this issue and move on.

/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: Wed, 28 Apr 1999 08:59:57 +0200

Stephan,

I can live with it.  :-)

Denis