Re: New proposed solution to the QC biometric issue

["Peter Williams" <peterw@xxxxxxxxxxxx>]

Specifying an "Optional" QC-extension-based URI name/locator to
subject's bio-template data is fine.


Peter.

    -----Original Message-----
    From: Stephen Kent <kent@po1.bbn.com>
    To: Peter Williams <peterw@valicert.com>
    Cc: ietf-pkix@imc.org <ietf-pkix@imc.org>
    Date: Monday, April 19, 1999 9:52 PM
    Subject: Re: New proposed solution to the QC biometric issue


    Peter,

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

    I disagree with the analogy. The examples you cite involve pointers to
information that in intrinsic to the management of a PKI, and we have
reasonably well-described architectures that calls for inclusion of these
values in certs. the biometric data is anciliary, employed for user
authentication, not certificate validation, and we have no corresponding
architecture for use of the biometric data. I might be persuaded to provide
an OPTIONAL pointer field if more evidence accumulates in favor of such, but
it is not in the same category as the other pointers you cite.

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

    see comments above.

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

    see comments above.

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

    Very creative Peter, and syntactically valid, but I think it violates
the semantics of the subjectAltName field. 2459 says "The subject
alternative names extension allows additional identities to be bound to the
subject of the certificate." The URI you propose including is not the
identity of the subject; but is a blob of bits used to help authenticate the
subject's identity.

    Steve