[cap-talk] "Same" key

[Norman Hardy]

On Feb 15, 2007, at 2:26 PM, David Hopwood wrote:

> Norman Hardy wrote:
>> On Feb 6, 2007, at 8:47 PM, Mark S. Miller wrote:
>>
>>> Regarding the KeyKOS literature, I'm confused about what they  
>>> mean by
>>> "object". The KeySAFE paper in particular is careful to distinguish
>>> "TCSEC object" from "KeyKOS object" and to always use the  
>>> prefixed form
>>> for the latter. Can any of the KeyKOS crowd/community clarify  
>>> what the KeyKOS
>>> literature meant by "object"? Is the KeySAFE paper consistent  
>>> with your usage
>>> elsewhere?
>>
>> The page from the Gnosis manual written circa 1980 is what I meant  
>> then:
>> http://agorics.com/Library/KeyKos/Gnosis/2.html
>> It still feels comfortable to me now.
>
> It seems to make some statements about what it calls "objects",  
> that are not
> true of composites/abstractions. For example:
>
> # Consider the concept of an object and the data that represents  
> the state of
> # the object. We say that a system supports objects if the  
> following rules are
> # obeyed, whether enforced by programming discipline, compiler  
> design or operating
> # system structure.
> #
> # The code that accesses the object representation is fixed and  
> known to the
> # system as a single unit and that code is the only code that  
> accesses the object
> # representation.
>
> This ("known to the system as a single unit") is not true of a  
> composite.
>
> # Objects sharing the same code are said to be of the same type.

You  have a point.
For instance if the object (in our sense) had the only key to another  
mutable object, the system (kernel in our case) would not connect the  
two. The only connection is that the first holds a key to the second.
Facet logic, by contrast, was built into the kernel and a facet was  
not known to the kernel as a separate object.

>
> A composite does not have an overall type; its objects have types.  
> (Any
> classification of composites is relative to a specific analysis of the
> system.)

Our use of 'type' was evidently slightly different.
You are right about key types being relative to analysis; in  
particular one key might call some key a 'start key' or a 'space bank  
key' depending on vantage point.
Our use of 'type' here referred to objects and that usage did not  
have much to do with correctness and security.
We did have the conventional 'alleged key type' call by which objects  
could say what it purported to be.
We had also had a kernel supported brand mechanism whereby a program  
could call on other more authoritative objects to vouch that some key  
had indeed been created by some known source.

None of these three notions is probably quote what you have in mind  
by type.

>
> # Any method of accessing the object is by some mechanism that we call
> # here an "object name". The object name effectively designates  
> both the
> # object representation and the unit of code that has sole access  
> to that
> # data. {An obvious general idea is to have a pointer to the code  
> stored
> # in the data.}
>
> This also seems to be talking about single/atomic objects.

Agreed. That statement is somewhat at odds with statements later in  
the manual such as
"There are four keys to a factory: the builder's key, requestor's  
key, fetcher key and copy key." which is in
http://agorics.com/Library/KeyKos/Gnosis/68.html .
In modern jargon these four were four facets to the factory and  
neither implemented nor conceived of as separate objects.
"Factory" above is in our sense of type of object.
The alleged key type call on the four keys would reply with 4  
distinct values.
They were 4 facets, in the kernel sense.
Any of the four could be recognized by the factory creator which  
would vouch for their authenticity.
What is important to convey, whatever terminology, is that there is  
one set of state for these four keys.
We used 'object' for this connotation when we said there was just one  
object for the 4 keys.

Type is indeed useful but also a flexible concept.
It will stay put if you work at it.
I think the Keykos type concepts were good for dynamic types, but  
perhaps not in a statically typed language.

>> It might be less specific than what we need now as it was meant to
>> convey a style of software design, and not to support precise
>> categories.
>
> Indeed.
>
> -- 
> David Hopwood <david.nospam.hopwood at blueyonder.co.uk>
>
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk