Re: New proposed solution to the QC biometric issue

["Peter Williams" <peterw@xxxxxxxxxxxx>]

-----Original Message-----
From: Stephen Kent <kent@po1.bbn.com>
To: ietf-pkix@imc.org <ietf-pkix@imc.org>
Date: Friday, April 16, 1999 7:12 PM
Subject: Re: New proposed solution to the QC biometric issue


>Folks,
>
>We discussed the biometric issue at length and the current proposal to
>include a hash of a biometric template, for some well-defined set of human
>verifiable biometrics, is the compromise we have reached.
>
>We are not putting a biometrioc template in the cert because it might be
>very big and we generally discourage inclusion of very large data items in
>certs.
>
>We are not putting a URI in because, under different assumptions, the
>matching templame might be stored somewhere for reference, or might be
>passed as part of an application protocol.  If the template is not passed
>with the cert, then the application protocol may chose to include a URI.
>The only thing that does need to be in the cert, for secruity, is the hash
>of the template, and the management data to know what hash algorithm was
>employed, and what sort of template the hash refers to, e.g., facial image
>or handwriting.


Steve,

I fail to see how one can rationalize the need of putting a CRL iDP (with
http reference) into a cert, but one cannot point to user information
in similar form, on similar grounds. And similarly for the PKIX
CPS-reference - where additional CA-related information is
bound to the certificate via a PKIX-standarized https reference.

If one were to accept the argument presented, then PKIX
should require SSL  and  S/MIME protocols to convey iDP
addressing signals, and ban CRL locating information from PKIX certs.

Similarly, the CPS http reference put into 2459 by one of the WG
chairs should be presumably immediately  banned  - as bad practice. If
its technically inappropriate to convey  legalistic user references, it is
technically
inappropriate to convey rather similar authority references which further
 (legally) describe that PKI party!

There is another side to this story, however. Based on the language
and intent of PKIX 2459, those deploying Internet CAs already
have all the freedom they need to do as some on the list are describing :-

- One  can note that PKIX  users may already name themselves using a
URI  name-form - and in a manner wholly consistent with RFC  2459.

- Should they name themselves with an https URI which happens to point
to their  biometric profile, then I can only conclude that 2459 already
allows
what is  being argued here in policy-regimes which establish their own
operating rules - as contemplated and facilitiated by PKIX 2459.

- The URI name form plus the QC hash value can seeming
work together fine to accomplish what some people on the mailing list want.

- Those relying parties who respect a policy id which binds the URI name and
hash  fields at cert-processing time can now implement the desired
application
of  PKIX certs.  They can even now use certs to signal
specific biometric template data - as incorporated via a hash-based secure
URI reference - into their policy-based cert issuing and handling
procedures.

Peter

--------


2459 quotes:

"   The CPS Pointer qualifier contains a pointer to a Certification
   Practice Statement (CPS) published by the CA.  The pointer is in the
   form of a URI."


"   The subject alternative names extension allows additional identities
   to be bound to the subject of the certificate.  Defined options
   include an Internet electronic mail address, a DNS name, an IP
   address, and a uniform resource identifier (URI).  Other options
   exist, including completely local definitions.  Multiple name forms,
   and multiple instances of each name form, may be included. "

  "   Further, if the only subject identity included in the certificate is
   an alternative name form (e.g., an electronic mail address), then the
   subject distinguished name MUST be empty (an empty sequence), and the
   subjectAltName extension MUST be present. "



>Steve
>
>