Re: Inclusion Lists for Hypercardus Clonus

[Michael McClary <michael>]

Synopsis: - Long.

          - Endorsement-hints of the form: "
	      A-believes:
	      B-claims-B-believes:
              C-claims-C-believes:
	    ..." can be stored efficiently.  Perhaps they can
	    also be filtered efficiently.

	  - They're needed for multiple-compeeting-vendor products.
	    (Since frontends for the first product are such, they're
	    needed for first product.)

	  - I suspect adding an endorsement-hint-hook later will break
	    everything and/or that not providing it will eventually
	    lead to antitrust exposure.  (Asserted, not argued.)

          - Oops!  Maybe we DO run arbitrary user-written code.

(I composed a LOT of this before finding that part of the problem
 was definitions.  I've tried to use the MarkM/tribble definitions.)

> From tribble Sun Feb 18 01:06:32 1990 []
> 
> I'm starting to remember the current design...  This would be an
> endorsement of the form "Machine A believes that User endorses
> Document".  Machine A would sign that endorsements and a hash of the
> Document.  It would only send this representation of an endorsement if
> it didn't actually have a real endorsment.  Since all machines on down
                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^
> the line have an authenticated endorsement-belief, we don't need
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> endorsement-beliefs of the form:  A believes B believes C endorsed X..
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You have just stated the reason we DO need endorsements of that form.
The receiver of the message from A only has an authenticated endorsement
from A, not from User.  Similarly, A never had an endorsement from User,
but only one from B.

NONE of the organizations, down- or up-the-line (except the one that
actually talked to User), has an authenticated endorsement belief,
because, to have one, its neighbors would have to STORE an authenticated
endorsement.  An authenticated endorsement belief must be one of the
following:

 1) Organization A has proved to itself that User endorsed X.  This
    means the organization next to A on the way to User gave A the
    signed-by-User hash of the endorsed material (or was within A's
    trust boundary).  This implies that all the machines between A
    and User stored the User-signed hash.

 2) Organization A has proved to itself something less.  This means it
    can't say "I know it was endorsed by User", but only something less.

If the "something less" of 2) is a pointer to a shared-with-all-other-
orgls-similarly-endorsed description of the route of the endorsement
through trust boundaries, it drops right into the endorsement-belief
storage-conserving mechanism.  "I believe AMIX claims Autodesk claims
Ted said" is just another endorsement-belief, with no more overhead
than "I believe Ted said".

If the information arrives again by another route, it can acquire another
endorsement.  Similarly, if a hash signed by a machine closer to the user
arrives, the information can acquire another endorsement.  If an
authenticated hash signed by User himself arrives, the "User" endorsement
can be added.

This also presents users (and frontend designers) with the necessary
hook for defining their own trust boundaries.  I, for instance, might
accept as "is" (for Xanadu business) data with endorsement-chains that
had only XOC, AMIX, and Autodesk links, and treat others as "claimed-
to-be".  The CIA might accept endorsement-chains passing through the
NSA and the FBI, but apply additional tests to endorsement-chains
passing through the KGB, and so on.

(Remember, these claims correspond to trust boundaries, which are
closely related to responsibility boundaries.  AMIX, for instance,
might store an endorsement-belief arriving over secure communication
from any of its U.S. machines or archive servers, but might downgrade
something from its Mainland China branch as "AMIX-China claims...".
A title-insurance company might say "we claim" on any land-records it
insures, even if entered by a subcontractor.  {DO title-insurance
companies have subcontractors?})

To see why 1) requires all the organizations (except the last) to store
the authenticated data, consider a situation where "User" publishes a
document on an AT&T-XIS backend, it is requested a week later by a
GTE-XIS backend, from GTE two months later by a backend in the
University of Michigan Graduate Library, and so on through the Church
of Later-Day Saints Geneology Archive, the Church of Scientology, and
the Stanford library, to AMIX, for "Subscriber", who is preparing a
lawsuit to break the will on the Miller Millions while Markm is on ice.
Does AMIX sign a hash of a message claiming "User" endorsed the original
document without checking User's hash for itself?  Or does it sign a
hash of a claim that "Stanford Library claims ..."?

> []  I'm not sure what filtering
> behavior to use for beliefs vs. authenticated endorsements.  Most
> endorsement recordings will be beliefs of endorsement by the backend
> to which you are communicating.  You must then decide whether you
> trust your backend to correctly represent endorsement information
> authenticated to it.

See above.

> Just to clarify, your "Is Foo" is an authenticated endorsement, and
> your "claimed-to-be-Foo" is an endorsement belief.  [definition of
> authenticated endorsement ala MarkM/tribble]
> Trust boundaries have nothing to do with it.  If you don't have a true
> endorsement, then all you have is an endorsement belief.  If it
> happens to be by someone you trust, then you believe the endorsement
> also, and your machine just represents the fact that you believe the
> endorsement.  The endorsement belief is also an authenticated message,
> so it doesn't matter if it passed through trust boundaries to get to you.

Not quite.  By your scheme, all of my terms are "belief"s:

 - My "Is Foo" is an endorsement belief:  The belief that the backend
   (or another entitiy within its trust boundary) had actually checked
   the endorsement of "Foo" (either by testing a signed hash or generating
   the endorsement in one of its own waldoes).  The endorsement itself
   is not returned, typically because it was discarded.

 - My "claimed-to-be-Foo" in the earlier letter is the belief that
   it may be interesting to try to treat it as "Foo", but no
   authenticated path to a genuine endorsement of "Foo" is known.
   (This may be because the claim is false.)  Thus, "claimed-to-be-Foo"
   is a Foo-hint.  The latter is a better term, because it doesn't
   imply that the claimant has seen an authenticated "Foo" endorsement.

 - "A claims that B claims..." is the belief (within trust boundary A)
   that the data arrived with a B-authenticated hash of a claim of the
   belief within trust boundary B...

Within your definition, I'm proposing that backends only store endorsement
beliefs (unless paid to store endorsements themselves), and transmit
self-endorsed endorsement-beliefs.

> It doesn't matter whether the backend has seen the actual endorsement.
> If the frontend doesn't check the signature and hash for itself (the typical
> case), then all it has 'seen' is an *endorsement-belief* by our
> backend which it trusts because it considers our backend to be within
> its trust boundary.

Oh, glah.  Now we're using different definitions of "trust boundary".
I point out that a trust boundary may be different for different
purposes:

 - As the author or a user of a WordAStra frontend, I might accept
   endorsement-beliefs with endorsement-chains through common-carriers
   for the purpose of keeping a data-bomb out of my frontend terminal.
   Thus the trust-boundary would include the set of common-carriers and
   anyone who could hand them data their WordAStra-clone waldoes would
   accept, or signed with WordAStra's frontend-waldo-signature.
   
 - As a common-carrier storing endorsement-beliefs in my database, I
   might take on fath only the beliefs of a set of my own backend and
   archive servers.  For this purpose, my trust boundary might include
   only a subset of my own machines.

I've been using "trust boundary" in the second sense, you just used it
in the first.

> Since we won't have any 'claimed-to-be' types in the initial release,
> to a first approximation, frontends won't deal with it in any
> reasonable way.

When was this decided?  I believe this is a necessary component if
we are to provide any endorsement mechanism at all.  (Unless, of
course, we store the endorsements themselves, which would KILL us as
an efficient storage engine.)

None of this mechainism is necessary in a system that is not, and never
will be, connected to other systems outside the company's trust boundary,
and will only be connected to frontends written by cooperating companies.
If the Xanadu early products are not delivered with an endorsement-hint
hook, however, it becomes a CanOWorms to add the hook later.

-----------------------------------------

>    > []  I would rather facilitate
>    > pushing arbitrary Waldos into the mid-end so that any user can get
>    > efficiency for any Waldo.
> 
>    No.  We do not run arbitrary user-written code.  Running user-written
>    code in the server makes it susceptable to denial-of-service attacks.
> 
> If they want to link their own code to our backend, That's their
> problem.

OK.  If the backend customer wants to link in his own code, or let his
own employees dynamically load executable stuff, that's fine.  I thought
you were talking about execution of subscriber-provided code by an online
service, as a default function of the Xanadu backend product.

> [uploaded filters in separate processes, too]

Oh, you were.  Well, doing it that way is fine, too.  (It is just
as secure as remote code, and if it infinite-loops they can limit
its slice so it won't crunch the backend, and send the user an
astronomical bill.  B-) )

> Let's discuss this in person, if you want to continue it.

Sure.

	michael