[cap-talk] Implementing a crypto brand: What are the security requirements?

[Kevin Reid]

On Mar 22, 2007, at 22:29, Tyler Close wrote:
> On 3/22/07, Kevin Reid <kpreid at mac.com> wrote:
>>>>> Integrity
>>>>>     The content of a Box A cannot be mutated.
>>>>
>>>> This is not a property of the sealing system provided by E. The box
>>>> cannot be mutated, but its contents do not lose mutability.
>>>
>>> E-on-Java does implement Integrity as I've defined it. Your second
>>> sentence above is the crucial one needed to understand the precise
>>> meaning. You can seal a reference to a mutable object in a Box, but
>>> you can't change which reference is in the Box once sealed. Using  
>>> your
>>> example below, you can seal a mutable list in a box, but you can't
>>> make a box point to a different mutable list.
>>
>> In the terminology I was using, making the box point to a different
>> object is "mutating the box", or "replacing the content of the box".
>> "mutating the content of the box" is mutating that mutable list.
>
> So it seems the word 'content' is confusing. We need some word for the
> part of the object graph that is actually represented inside the
> crypto box, rather than referred to by that part of the object graph.

I was speaking of non-crypto boxes, since I understood your list of  
requirements to be intended to be applicable to all types. If you  
were referring to crypto boxes only, and the assumption that live  
refs to mutable objects could be somehow included, then we do not  
disagree on the terminology used. I think. I've lost track of the  
possibilities.

I request that, for current discussion purposes, we make the  
assumption that it is not possible to incorporate live eventual refs  
in a crypto box. This is both the simpler case, easy to understand  
for an E programmer, and definitely implementable (the serialization  
involved follows similar rules to that for persistence).

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>