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

Re: Accessing/selecting biometrics was: Stray Poll: Finger-printsin QCs




Peter Williams wrote:

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

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

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

I second that. I can host a public copy, if needed.  This helps the interoperation
goal.

Cheers,

Ed Gerck