Re: New proposed solution to the QC biometric issue

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

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

Denis

> 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