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

From: Peter Williams <[email-masked]>
Date: Fri, 10 Dec 1999 16:37:36 -0800

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:[email-masked]]
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

---

From: Ed Gerck <[email-masked]>
Date: Fri, 10 Dec 1999 20:32:27 -0800

Peter Williams wrote:

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

Yes.  I think that Peter is quite correct to point out the value of
diversity. And, that is why interoperation is more important than seeking
the futile goal of perfect standardization -- because markets are local.

However,  there are evident problems of publishing private information,
from harmless impersonation to outright fraud. So, even though anyone
may feel free to promote unsafe standards in the private and even public
sector, at the end it is interoperation that suffers when one badly designed
protocol threatens to become the back-door of another, otherwise secure,
protocol.

The first goal is security not privacy, some may say -- but, what is it that
security secures? That which is private or at least secret. So, if a bit of
privacy is tossed out in order to obtain a bit of security then the means are
denying the end.  Security would thus be decreased -- e.g., by
impersonation attacks, by information leak  from unwanted recipients, etc.,
not increased.

So, notwithstanding the needs of local markets, and the the fact that we
should have here no particular opinion or demand on the local decisions
of others, it is possible to be a bit more forward-looking and point out that
quarantine may be the only solution to cope with a privacy-leaking protocol.
To isolate or deprecate a protocol is a valid tool to provide security by
confinement.  I  believe however that security cannot be based on
confinement only, especially on an open network such as the Internet.
We need to base security on understanding.

That is why encouragement or discouragement of certain identification
practices in regards to privacy and security (when based on technical
reasoning and understanding,  not on subjective biases and influence of
lobbyists or catcalls of 'politics") is thus a specifically appropriate position
HERE and NOW, I venture in contraposition to Peter, given the *explicit*
need for *global*  interoperation specified in current AND expected
versions of PKIX-1.

> attributes are local in scope; PKIX can similarly oblige.

I agree.  And, likewise it is appropriate for anyone in an IETF WG to point
out to such groups the overreaching problems which may be caused by
certain approaches when they extrapolate their parochial realm.  If, however,
they intend to remain parochial then, I venture, there is no need for
interoperation and no need for help from an IETF WG -- though such help
may be offered and taken at what it is worth.

However, to *demand* help for what seems to be from the start an  ill-fated
and ill-designed intrusion into privacy, and hence a security risk, is not
justified. Not even in the good name of local market need.  Because such need
cannot help the interoperation goal, lest we want to subvert from the outset
what we are designing.

> 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

---

From: Stephen Kent <[email-masked]>
Date: Tue, 14 Dec 1999 17:21:26 -0500

Peter,

>concerning the subjectDirectoryAttributes field. (See quote, below.)

I'm not sure what document you're referring to, Peter.  A search for 
"prioritization" in 2459 yields no matches.

>to change or refine the profile, as they see fit, furthermore.

I interpret the phrase "not recommended", reproduced in your quite 
below, as advising against use of this extension.  We don't prohibit 
its use, but we suggest that people not use it.  If we were neutral 
or wished to encourage its use, we have appropriate language for 
expressing those values, and that is not the language used here.

>beyond ensuring interoperability in maintained.

Yes, one can make such decisions and be compliant. However, for 
reasons we have already discussed on the list and documented 
elsewhere, there are good reasons to not incorporate the data in 
question in certs directly.  That is the crux of this argument.
>    ments.  This extension MUST be non-critical."

We disagree about the applicability of the explicit "not recommended' 
phrase in this case.  Obviously, it is not a prohibition, and your 
view is that it is not applicable.  My view is otherwise, and is 
based on the specific language cited above.  We are each entitled to 
our views. Good judgement cannot be legislated.

>attributes are local in scope; PKIX can similarly oblige.

I don't know what criteria the LDAP WG uses in deciding what to 
include in standard attributes. They need not be the same ones used 
by this WG re the contents of certificates.
>subjectDirectoryAttributes?

You may ask, but it's not relevant to the discussion since, as I 
noted earlier, the sensitivity of disclosure of authorization data 
and of personal authentication data are distinct concerns.  One 
cannot infer that a decision by one group to include one type of data 
that it is generally, or specifically appropriate to include another 
type of data.

Steve