[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Trust and Transitivity
Whether trust is, as Ed Gerck argues, non-transitive, and whether
it is a leap of faith to delegate, depends on who we are trusting
with what. "Public key X is bound to Alice" is clearly different
than "I trust Alice to certify public key Y is bound to Bob", not
to mention trusting Alice to certify anybody, much less trusting
Alice generally with anything. The lack of specificity in discussions
about "trust" often ends up implying far more trust than is really
needed to solve a problem, as well as far more than can be realistically
expected on the global Internet.
But "I trust Alice to use authorization for service X only once" can be
the same as "I trust Bob to use authorization service X only once", since
the server can enforce the use-once policy regardless of who the user is,
via maintaing an issued-but-unused certificates list. Whether trust is
transitive depends only sometimes on who or what the person or object
authorized is, but always on what we are trusting the person or object with.
For many, but by no means all, of the proposed uses of certificates,
Ed is correct that trust is not transitive. But these proposed uses are
problematic for just this reason. As Bill Frantz well observes, non-delegation
is difficult to enforce. Keeping track of who is using an authorization, and for
what purpose, is not strongly enforceable and doesn't scale. On the other hand, if
we worry only about whether or not an authorization gets used, how many times, and
other factors controllable locally by the service provider, issuer, and/or verifier,
these policies are strongly enforceable and scale well.
In commercial terminology, delegable authorization certificates
act like bearer certificates. They authorize whatever object holds
the certificate, regardless of that object's identity. I think this proactive method
is a great way to go, but observe that we are not used to solving problems this way.
We are used to solving problems in a reactive manner, by blacklisting, or hunting
down and punishing, the perpetrator. Blacklisting is still a very useful
technique with software; witness virus scanning and firewall blockading by
port number. But as Bill Frantz points out, punishing software is silly.
I suggest a Byzantine, contract based paradigm. Instead of giving "permission"
to delegate, (which makes the mighty assumption that no one in the
world is going to do anything unless I give them my permission!) assume
that any entity (and, in particular, the beneficiary of an authorization)
will do whatever it likes unless (a) it promises not to (or the specification
promises that it won't), and (b) this promise is enforceable by the
verifier, or at least non-performance on this promise is verifiable (there is an
auditing scheme such that breaches of promise will become known).
Policy management becomes agreement management. Agreements may be with
bearer, in which case delegation-agnostic authorization certificates
are fine, or with particular entities, in which case we also need
identity certificates. Assume as well that third parties will do whatever
they like unless prevented. This is the pessimistic "Byzantine generals"
assumption used in general distributed computation theory; it applies
all the more when dealing in the security of distributed systems.
I will argue for this secure contractual paradigm and discuss combining
authorization certificates with identity certificates in a subsequent
post. Meanwhile, if you're interested check out my web page for related