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

[Mark Miller]

On 3/22/07, Tyler Close <tyler.close at gmail.com> wrote:
> Ah, and even though SealedBox is not declared final, it doesn't have a
> constructor a subclass could use.

Tyler, Alan, Chip, Bill Frantz, Norm, and I discussed this today. I
have just made SealedBox in the E-on-Java implementation final. I am
not recording this as a bug fix, however, because E-on-Java assumes
that non-TCB code cannot subclass TCB Java code. Should E-on-Java ever
become E-on-Joe-E, we will have to revisit this assumption in general
then.


> I guess this also means the E
> implementation does not allow for the implementation of a crypto brand
> that is polymorphic with the existing E brand API.

Depends what you mean by "polymorphic". For a piece of code like:

    def foo1(box) {
        ... myUnsealer.unseal(box) ...
    }

then it will be polymorphic. But for code like

    def foo2(box :SealedBox) {
        ... myUnsealer.unseal(box) ...
    }

it isn't. This is analogous to the difference between

    def foo3(i) {
        ... (i + 77) ...
    }

vs

    def foo4(i :int) {
        ... (i + 77) ...
    }

Regarding foo3, other objects can be polymorphic with the built-in
integers. Regarding foo4, no other objects can be polymorphic with the
built-in integers.

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM