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

Re: KeyNote draft available

Bill Frantz:
> 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?

The distinction has been made between 
"admonition" policies and policies  enforced by 
engineered security.   Policies based on the no-delegation
assumption fall into the admonition category.

I wonder if SPKI or KeyNote could better clarify which
components of policies are based on self-enforcing security, 
and which on admonition.  A policy or authorization expression 
could specify which policies fall into strongly enforced, 
admonition, or some intermediate strength of security.    

Examples: a freely delegable, or bearer, certificate, good for 
a limited amount of encapsulated service.   Here, by canceling 
the certificate (putting it on a "spent" list), the usage limit 
is made self-enforcing.  On the other hand, a certificate 
issued to a particular entity, and an expected usage limit 
based on punishment (reputational, legal, or otherwise) of 
entities that misuse the resource, is policy based 
on admonition: both in terms of the assumption of non-delegation,
and the expected deterrence effect of the punishment.  For a
particular application it may be a quite sufficient admonition -- people
usually don't swap their IDs, for a variety of reasons,
and in many cases reputational or legal deterrents are 
effective -- but in terms of engineered security it
remains a policy of admonition, not a policy fully 
secured by the protocol.

In the first case we are trusting a self-enforcing protocol, and 
in the second case social incentives which probably cannot 
be fully specified.  Whether the admonition will be followed
depends on the nature of the relationship between the 
authorizor, authorizee, and any third parties that might
be invoked. 

(A more sophisticated specification might include an
economic analysis of exposures, breach costs, incentives,
etc., but that is probably well beyond the scope of 
these policy languages). 

I don't think SPKI or KeyNote can or should prevent insecure 
constructs -- the world is full of them and they are often 
necessary -- but we should allow and encourage them to 
be distinguished from self-enforcing constructs when 
possible.   Certain components of an admonition
system (such as the authentication protocol assuming
non-delegation) are secure while other components
are admonition.  It would be interesting if conclusions 
could be drawn about the security of a policy by analyzing
the specified security of its components.   

Bill Frantz (in another post):
> since you
> can not prevent "informal" delegation by technical means, it is better to
> design the technology to provide an audit trail of the actual delegations,
> so you can control delegation by social means.

Such an audit remains an admonition system, in some cases effective
and in some cases not.  The audit can be spoofed by delegating
via key-sharing rather than via the audited mechanism the
user is admonished to use.  Economically speaking, the audit does 
not deter anti-admonition behaviors whose benefits outweigh the cost 
of key sharing.

PGP D4B9 8A17 9B90 BDFF 9699  500F 1068 E27F 6E49 C4A2