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


Nick Szabo
szabo@best.com
http://www.best.com/~szabo/
Follow-Ups: References: