RE: Accessing/selecting biometrics was: Stray Poll: Finger-printsin QCs

[Peter Williams <peterw@xxxxxxxxxxxx>]

David,

Please do not take any real exception to my language concerning
the synchronization of an acceptable use of the PKIX
subjectDirectoryAttributes field and the use made by a given
user community (NSA's various DoD-related customers.) That
field is suitably generic; DoD/NSA is to be commended for
arriving at its availability, and making use of it for
purposes critical to US national security interests.

Our own QC is written in an interesting & revealing manner - it expects 
to be sub-profiled, so "QC+local-extensions" meet the needs of
particular user communities.  Each of these include a subset of 
the internet community who are bound to one or more public or
private legal systems, depending upon context.

Should one such community, which will *by definition* fail to
be interoperable at the intended legal level with the entire
Internet community, choose  to mandate a particular biometric
inline data requirement tuned to the choice of biometric
protection afforded a particular national id smartcard,
then the architects have the perfect place to put such, non-naming,
but subject-oriented information in the PKIX-conforming cert, using
the sub-profiling authority provided by, and required by, 
QC. X.509 is pretty explicit about allowing use of such as
photo material in certs. An "animated gif", consisting of a 
facial profile base image using inline data, with more detail 
arriving from the net could  be a sensible data size compromise.

I assume those the US folk who wrote PKIX were aware of NSA 
requirements, and accommodated those needs. Just as MISSI designers chose
to then utilize the field for local-community authorization purposes,
so can other now use the field for biometric authorization,
or using biometrics to increase the confidence in user identification, 
as they see fit, as standardized by X.509.  

If nothing else, PKIX could assist such sub-profiling by
providing an OID arc, for registering attribute definitions
tuned to PKIX purposes. User organizations can of course
define their own attributes, for non-PKIX purposes,
pursuant to their sub-profiling responsibilities.

 


-----Original Message-----
From: David P. Kemp [mailto:dpkemp@missi.ncsc.mil]
Sent: Monday, December 13, 1999 8:43 AM
To: ietf-pkix@imc.org
Subject: Re: Accessing/selecting biometrics was: Stray Poll:
Finger-printsin QCs



MISSI/Fortezza documentation is available, as always, from
http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html

That includes the latest (12 May) versions of SDN.706: "X.509
Certificate and Certificate Revocation List Profiles and Certification
Path Processing Rules for MISSI" and SDN.801: "MISSI Access Control
Concept and Mechanisms".

I take mild exception to Peter's characterization that the
subjectDirectoryAttributes extension is somehow slanted toward MISSI's
use of the extension as a container for the "prbacInfo",
"sigOrKMPrivileges", and "commPrivileges" data structures.  Those data
structures are oriented toward a particular user community, but it is
silly to imply that the extension itself is anything other than
absolutely generic.

I agree with Steve that the place to define biometric interoperability
specifications is within a biometric interest group (open/closed
consortium or IETF BOF/WG), not within PKIX.  PKIX should provide a
container (sDA or hash+URL, neither of which are specific to biometric
data) but no more.

Dave Kemp



> From: Ed Gerck <egerck@nma.com>
> 
> Peter Williams wrote:
> 
> > May I ask a Booz-Allen or DoD party to post a URL here to the excellent
> > and current version of SDN706 before we sensibly discuss further
> > the use of labels and the authorization issue, re 
subjectDirectoryAttributes?
> 
> I second that. I can host a public copy, if needed.  This helps the 
interoperation
> goal.
> 
> Cheers,
> 
> Ed Gerck
>