[E-Lang] draft statement of consensus

[Marc Stiegler]

Goodness--I take 2 days off from reading this list, and there is a huge
batch of interesting new stuff crying out for me to respond :-) Well, today
I am keeping focus on the Statement of Consensus.

At the bottom please find the second draft of a Statement of Consensus,
incorporating changes as identified in email responses to the first draft.
This draft is designed to eventually be a standalone document: if I do not
get any disagreements in a 4 day period, I will publish this as "final" on
e-lang to make it a part of the archive.

If someone has a great idea for a wordsmithing change, or another point of
possible consensus, I urge holding back until this one is published: if I
have to change any of these statements, I will feel obligated to start the
4-day quiet period from scratch again :-)

Unless someone objects to the following policy, I would consider it
acceptable to delete a statement without restarting the quiet period. I
would do this of course only if the statement stimulates criticisms.

I have included a list of names of participants. If someone desires their
name removed or added to the list, please let me know. Zooko, because of the
disclaimer at the end of the statement, you may desire to have your name
added, your choice. Changing the list of participant names will also not
make me feel obligated to start the clock again, I will just change it for
the final.

Finally, I have left the numbering of the statements the same so that if
someone wants to compare the old to the new, point 7 is still point 7. I
will renumber for the final.

--marcs

----Change notes----

Statements 1-3: I have left the substantive statements exactly as they were,
and deleted the justifications I had written that explained why I thought
these were good candidates for consensus. Statement 3 had a long qualifier
which is now subsumed by the Disclaimer at the end.

Statement 4: Deleted. This is the one about extensibility with capabilities
and ACLs. I believe there are some powerful statements to be made in this
realm, but they need to be worked through for a future summary. Soon I will
post email demonstrating the flexibility of capabilities with hopes of
finding an interesting consensus. Not today :-)

Statement 5: Edited for readability, but I do not believe the change was
substantive.

Statement 6(a-c): Now based on Jonathan's critique, ending with the
assertion about E and EROS from the original to which no one objected. In
the original there was a big caveat about disparity of knowledge of E and
EROS, now subsumed by the Disclaimer at the end.

Statement 7: Excerpted from Tyler's critique of the original statement 7,
based on elements that were not disputed later by David and Markm. There is
probably a stronger statement that can be made here, but I believe it should
be postponed for a future summary.

As repeatedly noted above, I have added a Disclaimer at the end which states
the limits of the claims based on the knowledge of the participants. On the
one hand, the disclaimer is saying something that is necessarily so, and
anyone could deduce that it is true. On the other hand, it probably deserves
to be said explicitly.


--------------DRAFT------------------

Statements Of Consensus as of February 9, 2001

1. We all agree that currently available ACL systems are too broken to be
serious contenders for general-purpose effective security.

2. We all agree there is at least one security relationship that
capabilities cannot create, even in theory. This is the one Ralph Hartley
identified that Mark Miller agrees with. We also agree that this one is not
of practical importance. We also agree that there may be others that might
be of practical importance, though there is no agreement that others have
been found.

3. We all agree that capabilities systems as embodied in EROS and E seem
architecturally sound enough to be serious contenders for providing
general-purpose effective security.


5. We all agree that the Principle of Least Authority (POLA) is an important
element in security design, and is indeed a sensible best-practice.

6a) We all agree that capabilities inherently convey "narrow" authorities,
in the sense that they name only one object at a time (in contrast to user
ids as basis for protection, which name multiple objects at a time).

6b) We all agree that explicitly designating authority at the locus of use
imposes a style of use that simultaneously tends to reduce the number of
authority misuse errors and renders them easier to locate, identify, and
repair. We agree that capability systems (via C-list indices) lend
themselves to such explicit designation. We deduce that capability systems
lend themselves to the application of POLA, though one can build non-POLA
capability systems.

6c) Finally, we recognize that POLA is a part of both E and EROS as actual
implementations.

7. We all agree that each authority should have its own protection,
according to the POLA. Compromising one protection should not yield
the ability to compromise others.



Disclaimer: The participants in this discussion have a wide disparity of
knowledge about different aspects of these discussions. Consequently, the
necessarily more correct way of stating this consensus is that everyone
agrees within the constraints of their knowledge: For any one aspect of
these statements of consensus, those with a weaker knowledge of that aspect
know of no fault in the statement, and are necessarily trusting those with a
stronger knowledge of that aspect to have highlighted a fault if there is
one. Equally of course, if new evidence or insights become available, people
may have a different opinion at a later date, making this document obsolete.

Participants in this discussion, alphabetical by first name, include:

Alan Karp            (alan_karp@hp.com)
Ben Laurie           (ben@algroup.co.uk)
Bill Frantz           (frantz@communities.com)
David Wagner      (daw@mozart.cs.berkeley.edu)
Hal Finney           (hal@finney.org)
Jonathan Shapiro (shap@cs.jhu.edu)
Ka-Ping Yee        (ping@lfw.org)
Marc Stiegler       (marcs@skyhunter.com)
Mark Miller          (markm@caplet.com)
Norm Hardy         (norm@cap-lore.com)
Nikita Borisov      (nikitab@cs.berkeley.edu)
Ralph Hartley      (hartley@aic.nrl.navy.mil)
Tyler Close         (tclose@oilspace.com)