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

[Peter Williams <peterw@xxxxxxxxxxxx>]

Steve,

In response to your comments, I venture that my suggestion is wholly
reasonable, I assert again. Concerning the factual basis of your 
counter-argument, the "latest" version  of 2459 merely advises a MODEL 
OF "prioritization and scope  -  for implementers (not operators)" 
concerning the subjectDirectoryAttributes field. (See quote, below.)

In no sense do I read from the normative text that use of the disputed
field is/was "discouraged". Now we have 2 local uses for subjectAttributes 
- NSA's and the biometric application  - and given we are revising 2459 
for bugs and timeliness of options and important processing steps, it is NOW

appropriate to revise even this language so that X.509's design and intent 
can be realized in the Internet environment. Nothing in the "Internet
environment" suggests that this quite properly standardized field is
in someway fundamentally tainted. 2459 specifically encourages operators
to change or refine the profile, as they see fit, furthermore.

Ander's bio-vendors group, like NSA/DoD, have a quite appropriate home 
for their  "local material" which binds to the subject. As the material 
is "local" and non-critical (per 2459), the authors/WGs opinion on
suitability 
of any such local information in an operational id-cert infrastructure is, 
by definition, irrelevant. Local means we here have no particular opinion,
beyond ensuring interoperability in maintained.

Encouragement or discouragement (at best a non-normative and
political element of a standards process, subject to subjective 
biases and influence of lobbyists) is perhaps a specifically inappropriate 
position HERE, I venture, given the *explicit* local
delegation specified in current AND expected versions of PKIX-1.

"The subject directory attributes extension is not recommended as an
   essential part of this profile, but it may be used in local environ-
   ments.  This extension MUST be non-critical."

I do suggest that it is quite appropriate for IETF to assist 
interworking-oriented and PKIX-cert conforming groups formulate standard 
syntaxes to represent information in cert which is designed
for local, or "card-present/signature-device present" type, 
security enforcement processes. Many existing IETF-blessed LDAP 
attributes are local in scope; PKIX can similarly oblige. 
 
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?

Peter.
 
-----Original Message-----
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Friday, December 10, 1999 11:07 AM
To: Peter Williams
Cc: 'PKIX-List '
Subject: RE: Accessing/selecting biometrics was: Stray Poll:
Finger-prints in QCs


Peter,

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

you mean the field that 2459 discourages use of?

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

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

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

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.

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

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.

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

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

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


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

Steve