[cap-talk] the "flaw" of separating designation from authority

[David Hopwood]

Fred Spiessens wrote:
> OK, I see, thanks for the explanation.
> Yes, loosing the connection between the origin of the designation and  
> the origin of the authority will result in confused deputies. When  
> programming deputies, the ultimate advantage of capabilities is: that  
> you don't have to keep track of this connection yourself.   
> Programmers tend to keep track only of the designation (functionality- 
> minded as they are), which is probably the reason why, in Client  
> Utility, they thought they could get away with combining  
> certificates, when they could not be sure that these certificates had  
> the same origin (certificates provided in the same invocation may be  
> of different origin).
> 
> The flaw is not "separating designation from authority" but "losing  
> track of the connection between the origin of the designation and the  
> origin of the authority".

The point is that losing track of this connection can only happen if and
when the designation and the authority are separated.

> The former would have indicated a flaw in  
> the system, while the latter is a programming error.

I disagree. It's not sufficient just to make it possible for applications
to avoid security vulnerabilities. Since a system consists of a large
amount of code, the risk of an exploitable vulnerability per unit of code
has to be very low indeed in order to yield a secure system. Just making
it possible to avoid vulnerabilities (given a great deal of attention to
detail and exhaustive security review), will not achieve this. The only
approach that has a realistic chance of success is to make
authorities-bundled-with designations (i.e. capabilities) the simplest
and most obvious way of specifying any resource.

-- 
David Hopwood <david.nospam.hopwood at blueyonder.co.uk>