Re: New proposed solution to the QC biometric issue

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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


> Hi Stephen,
>
> Stephen Farrell wrote:
> >
> > - you'll need an algo id somewhere or you can't recalc. the
> > hash
>
> yes, I agree. So I correct my ASN.1 definition of the BiometricData:
>
> BiometricData ::= SEQUENCE {
>          typeOfBiometricData  OBJECT IDENTIFIER
>          hashalgorithm        AlgorithmIdentifier
>          biometricDataHash    OCTET STRING }
>
> > - 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)
>
> 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