[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Peter,


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.)
I'm not sure what document you're referring to, Peter. A search for "prioritization" in 2459 yields no matches.

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

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

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