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

[Peter Williams <peterw@xxxxxxxxxxxx>]

Steve's argument really does not make sense, in a wider context.

NSA defines, in SDN706, clearance and privilege attributes to
instrument authorization regimes including NOFORN,
RELUK, etc, and PKIX faciliates their transport & carriage in 
the PKIX flexible, subjectDirectoryAttributes field. 

If PKIX id-certs transport such authorization info, they
can transport similar bio-info, in other subjectDirectoryAttributes
fields.

The privacy argument concerning bio info is mostly the same 
as authorization info. A 100 byte compressed picture of me
is no more sensitive than the level of my (non-existing) US 
security clearance.

Given the seeming synchronization of PKIX work and NSA work, I 
have no doubt that knowledge of this authorization case is
well known to all those who decide what goes into PKIX
draft standards.

If my argument does not hold, then authorization info
in PKIX-compliant certs should be restricted to a hash-reference,
so it is aligned with the bio-data rationale.

This would of course make a large swath of NSA certs
today PKIX non-complying. I doubt PKIX WG would make that
decision, somehow: so PKIX stds should allow the same logic as 
enabled 100 bytes of authorization information to now
also hold for embeddeding 100 bytes of bio-data.

-----Original Message-----
From: Stephen Kent
To: Anders Rundgren
Cc: 'SEIS-List'; PKIX-List; Tony Bartoletti
Sent: 12/7/99 5:47 AM
Subject: Re: Accessing/selecting biometrics was: Stray Poll: Finger-prints
in QCs

Anders,

>Tony,
>
>Slight comment on a thing of importance that you mention
>
><snip>
>
>  >Someone mentioned that the hash is sufficient, since the actual
>  >data could just "tag along" with the cert, if required. But there
>  >needs to be a standard even for this kind of operation. Is there?
>
>
>This was the original QC solution. As you noted (and I have told the
>authors several times) this is a half-made solution. A genuine example
>of poor engineering!

PKIX creates infrastructure standards.  Specifying a means of binding 
biometric data to a cert is within scope.  specifying a means of 
carrying this data in a wide range of application environments is out 
of scope.  For example, we don't tell IPsec, SSL/TLS, or S/MIME how 
to transport certificates or CRLs in those applications; we just 
define the certificate and CRL formats.  The same principle applies 
here. Having defined a means of binding biometric data to a cert, 
while not putting it in the cert and thus mitigating privacy 
problems, we have done the part of the job that is appropriate for 
this WG.

What aspect of this argument do you not understand?

Steve