[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: KeyNote draft available
Bill Frantz writes:
> At 10:56 AM -0800 3/14/98, E. Gerck wrote:
> >You recognize of course that this "argument" is seriously deceptive:
> >if we cooperate with a security flaw because it is inevitable for
> >set = A and make it the freely avaliable for set = Universe then
> >unless A = Universe we have effectively reduced the security level.
> Is it better to deliver systems which claim to enforce things they can not
> enforce, or to deliver systems that do not make those claims?
> IMHO, In the former case, people will trust the claims and field insecure
> systems. In the latter case, people will understand the limits of
> technology and include non-technological controls.
Certificates are machine-readable statements and deal with claims
which can either be proved or disproved by Turing machines. To that
precise technical constraint we must add the social use (or, abuse) of
certificates. However, to claim that the social (ab)use negates the
usefulness of strong technical barriers in certificates is an
exaggeration. "Law is no substitute for engineering" applies here also
and it is a common high-school experience that a cheap $1.00 lock that
anyone could break affords much more privacy than a "DO NOT OPEN" sign,
in a locker-room.
For example, X.509v3 uses the critical bit construct for
several purposes but also in order to achieve delegation control, in a
meaningful way, which shows that it is not only possible but also
Regarding enforceable or unforceable things, I disagree that such can
have the absolute measure explict in your statement "systems which
claim to enforce things". Clearly, "enforcing something" is not only
a matter of degree but also depends on the proposition's environment,
goals, actors, time, etc.
Rather, it would be better to say "system S with memory C, which
enforces X under assumption Y regarding inputs from A and outputs to
B during time T".
Of course, correct specifications for S, C, X, Y, A, B and T are
needed, as evaluated by self-consistency metrics to a set of
policies and ab initio requirements such as cost, speed of response,
reliabillty, fault-tolerance, hardware, software, algorithms, etc.
This is not an overly-variable problem, although complex, and is
certainly within technology's limits.
Further, regarding the control of information and the unfaithful
proxy problem, law and custom allows proxies to have time-limited,
assignment-limited and delegation-limited mandates for good reasons
and I see no reason for a cryptographic protocol to control the first
two (eg, time and assignment) limits while entirely neglecting to
control the third.
Thus, the lack of control of delegation depth is a direct design
*limitation* regarding security -- not a design freedom, and can
seriously impact the security design in other areas apparently
unrrelated, by vicious synergy.
If you want that design limitation to be present, fine. However,
please do not claim that it is present because technology could do
no better or because technology can be bypassed. After all, a good
security design is like onion shells -- not like an egg shell.
Dr.rer.nat. E. Gerck firstname.lastname@example.org
--- Visit the Meta-Certificate Group at http://www.mcg.org.br ---