Subject: New proposed solution to the QC biometric issue

From: Stefan Santesson <[email-masked]>
Date: Wed, 14 Apr 1999 12:57:35 +0200

All,

The long debate regarding biometric data in Qualified certificates ended
with the conclusion:

"For bio-metric data to be included in the QC, the list has to provide an
agreeable solution that can enhance interoperability in some meaningful
way. Until then this issue will not be addressed in the profile."

Well, since then I have had a lot of off list discussions ending up in a
new conclusion:

1) It could be valuable to include support for biometric data aimed for
human verification (not machine verification), e.g. human verification of
picture image or signature image. In fact face recognition and signature
recognition are regarded as the two major implementations which justify
this proposed expansion of the draft. 

2) The supported solution should only address storage of a hash value of
biometric data. This would provide all necessary functionality for
authenticating bio-data without loading the certificates to much.

3) Storage of bio-data-hash should NOT be done in the PersonalData field
since this data is conceptually different from id-attributes. Further,
since bio-data need storage of 2 parameters (OID + hash), those values
can't be stored in a single predefined attribute. Instead a new optional
extension should be defined for this purpose.

Petra Glöckner has prepared a proposal for this new extension in QC as
follows:

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  OBJECT IDENTIFIER
  biometricDataHash    OCTET STRING }

So with this concrete proposal I would like to reopen the issue for
comments on this.
Consequently I will move this issue to the unsettled topics on the QC web (
http://www.accurata.se/QC/ ) 

/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, 14 Apr 1999 17:16:45 +0200

Stefan,

I welcome and support your proposal in general.

> this proposed expansion of the draft.

I would propose that we limit our goal, for the time being, to these two
biometric features which seem indeed enough.

> authenticating bio-data without loading the certificates to much.

Correct.

> extension should be defined for this purpose.

I agree.

> Petra Glöckner has prepared a proposal for this new extension in QC as

I have several minor concerns with this following ASN1  proposal, but I will
wait a little bit to see other responses before commenting any further.

Thanks again for your efforts for trying to find a consensus,

Regards,

Denis

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Apr 1999 16:42:05 +0100

Stefan,

Haven't followed this but a couple of thoughts occur:

- if you're only storing a hash, how do I find the 
original - maybe a URI is needed in addition

- if you buy into the above, couldn't the URI replace
the OID (since e.g. a HTTP response has a MIME type
which identififes at least the syntax and also 
identifies the transfer encoding of the actual data)

- you'll need an algo id somewhere or you can't recalc. the
hash

- you'll need to specify how the actual data is to be
flattened before hash calculation (e.g. strip CR/LF or
whatever), this could be incorporated with the
algo id (so use a transform id)

Regards,
Stephen.

---

From: Petra Gloeckner <[email-masked]>
Date: Thu, 15 Apr 1999 11:49:56 +0200

Hi Stephen,

> - you'll need an algo id somewhere or you can't recalc. the

yes, I agree. So I correct my ASN.1 definition of the BiometricData:

BiometricData ::= SEQUENCE { 
         typeOfBiometricData  OBJECT IDENTIFIER 
	 hashalgorithm	      AlgorithmIdentifier
         biometricDataHash    OCTET STRING }
 
> algo id (so use a transform id)

As I understood the whole discussion the reference data has been 
provided before, i.e. it is already existing and pre-stored. 
There is no new verification data which needs to be transformed 
and compared against the reference data. The purpose of the 
biometrics extension is just to verify by a signed message that 
the provided reference data belongs to the certificate holder.

Correct me, if I'm wrong!

Petra

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 15 Apr 1999 12:42:30 +0200

Petra,

It has been requested on the list to indicate the usage of such
data.While this kind of information does not belong to the core
document, it would nevertheless be interresting to place it in an
informative annex. Hereafter is a first stone to build that section.
This is not the single way to use the extension, but one way. From this,
you can see the implications on the ASN1.

Proposed text:

" In some cases the subject name that is contained in a public key
certificate may not be meaningful enough. This may happen because of the
existence of synonyms or because of the use of pseudonyms. A distinction
could be made if more attributes were present. However, adding more
attributes to a public key certificate placed in a public repository
would be going against privacy protection. In order to achieve a balance
between these two opposite requirements the hash values of some
additional attributes can be placed in a public key certificate. When
these additional attributes are provided by the certificate owner, then
they can be verified. Using biometric attributes may allow to
unambiguously identify a person. There are two kinds of biometric
attributes that can be used : a picture or a manual signature from the
certificate owner.

A picture can be used if the verifier once met the person and later on
wants to verify that the certificate that he got is relative to the
person which was met. In such a case, at the first exchange the picture
is sent and the hash contained in the certificate may be used by the
verifier to verify that it is the right person. At the next exchange the
picture does not need to be sent again.

A manual signatuere may be used if a signed document has been received
before hand. In such a case, at the first exchange the drawing of the
manual signature is sent and the hash contained in the certificate may
be used by the verifier to verify that it is the right manual signature.
At the next exchange the manual signature does not need to be sent
again."

From these examples, it can be seen that a URI is not mandatory, but the
name of the corresponding file would be usefull as well as the type of
biometric information. As far as the typeOfBiometricData is concerned I
would prefer an integer instead of an OID: it is shorter (when
certificates are stored in smart cards) and we could expand the list of
integers as needed. At the time being, two integers seem sufficient
(picture or manual signature).

Regards,

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 15 Apr 1999 13:22:07 +0200

In the attached message, I would guess that everyone would have noticed that
I wrote "synonyms", but I meant "homonyms".  :-)

Denis

---

From: Petra Gloeckner <[email-masked]>
Date: Thu, 15 Apr 1999 17:54:36 +0200

> (picture or manual signature).

Denis,

why would you like to include the name of the corresponding file in
the certificate as well? 

Without this name I'd suggest the following structure considering the
comments of Stephen and you:

   BiometricData ::= SEQUENCE {
         URIorOID	      URIorOIDsyntax,
         hashalgorithm        AlgorithmIdentifier,
         biometricDataHash    OCTET STRING }

   URIorOIDsyntax ::== CHOICE {
	 uri		      [0] IA5String 
         typeOfBiometricData  [1] INTEGER }

with the following types of biometric data defined so far:
	0    picture
	1    manual signature

Best regards - Petra

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 16 Apr 1999 12:17:41 +0200

Petra,

My comments are along the lines.

> I originally thought to have the name of the file to point to the right
> attached file and the extension of the file to select the right viewer.

The name of the file is not  needed if there is some "other ways" to
differentiate (in the case when there are multiple attachments) between an
attached picture, a manual signature and, maybe, a fingerprint (that was not in
my original list).

I am however still wondering if there might be some interrest to have
nevertheless the extension of the file, for exemple: GIF, TIF, BMP, MPG, MP3,
etc ... to know, only when looking at the certificate, what kind of viewer will
be necessary. I do not feel strong on this issue, I am trying to find the pros
and cons before taking a decision. Other thoughts ?

Regards,

Denis

---

From: Stephen Kent <[email-masked]>
Date: Thu, 15 Apr 1999 11:46:33 -0400

Stephen,

>original - maybe a URI is needed in addition

maybe, but not always.  the template can be passed as part of a
transaction, or be stored in a file, or whatever.  because there are
multiple, legitimate ways to provide the template, and nthey may differ for
the same cert user in different contexts, I think it inappropriate to
incorporate any one in the cert itself.

>identifies the transfer encoding of the actual data)

I'm not in favor of the above, and anyway, HTTP is but one possible
transport medium ...

>algo id (so use a transform id)

do you mean canonicalize the template?  these templates are typically
binary, not ASCII, I think.  Any canonicalization rules should be specified
in the ID we use to specify the template type, maybe as a sub-type.

Steve