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

From: Peter Williams <[email-masked]>
Date: Tue, 7 Dec 1999 15:04:00 -0800

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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 10 Dec 1999 14:06:31 -0500

Peter,

>the PKIX flexible, subjectDirectoryAttributes field.

you mean the field that 2459 discourages use of?

>can transport similar bio-info, in other subjectDirectoryAttributes

certainly you understand the difference between authorization and 
authentication info, so the analogy looks rather weak on that basis 
alone.

>is no more sensitive than the level of my (non-existing) US

no, it is not. the two concerns are incomparable, in general. people 
holding clearances have opted into a system which requires abandoning 
some privacy concerns, and adopting new ones imposed by the clearance 
issuer.  a private citizen who makes use of biometric data for 
authentication in a QC is operating under a different set of privacy 
assumption, constraints, etc.

>well known to all those who decide what goes into PKIX

several of the authors of 2459 are aware of the SDN706 work, but they 
did not skew the document to endorse that NSA spec.  today, we would 
encourage putting that info into an AC.

>so it is aligned with the bio-data rationale.

if your analogy were valid, and if we did not disparage use of the 
directory attributes extension, this argument might make sense, 
however, ...

>also hold for embeddeding 100 bytes of bio-data.

we're not talking about backward compatibility here, so again the 
analogy is flawed.

Steve