Inclusion Lists for Hypercardus Clonus

[Eric Dean Tribble <tribble>]

Abstract:  I finally remembered details about the distributed
endorsement scheme MarkM and I designed.  It's actually the design my
mind has been working from.  This was originally in the context of a
mail reply, so the other reactions are at the end.

   What we can store efficiently is the statemtent: "When the user entered
   this, he convinced us it was endorsed.  Trust us."

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..

   If the user wants
   to store a hash in addition, and thus PAY ($ / consumption of his disk
   space) to do so, it's his option.  Given this understanding, the user
   can make his own judgement of what information to endorse in a way
   that can be trusted even if the backend operator can not.  We can expect
   he will only do it for things where it's really important.

Paying separately to store a hash is interesting.  I expect users to
only hash things that they intend to Publish.  An alternative to
maintaining a hash is to compute a hash for documents that have been
sent to other machines.  The machine initially sends out an
endorsements belief.  When the endorsing user next talks to the
machine, he can actually sign a hash of the contents and broadcast
that to the parties that see the document that was endorsed.

   > Your "claimed-to-be-Foo" endorsements suggest another solution to the
   > BEBE case.  When non-authenticated endorsements gets transmitted to an
   > untrusted backend, they become endorsement hints.

I forgot that we already designed much of this.

   These would
   > particularly be used for work-types and link-types.  A frontend that
   > recognizes a particular endorsement-hint would then check conformance
   > on the endorsement and then confirm for that backend that the document
   > actually had that type.  

This still makes sense for WorkTypes and such.  It doesn't mean
anything for other endorsements or even link-types.

   Right.  We would distinguish trusted backends (other sites operated
   by the same company, in-house backup servers) from untrusted backends,
   and automatically downgrade the endorsements we store.

endorsement-beliefs deal with this.  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.

   Thus the "Is foo" endorsement means an unbroken path exists within our
   own responsibility boundary between the place where WE checked the
   authentication (and then forgot it, but remembered that we'd seen it)
   and the point where we generated our own authentication on the way
   to the reader.  The "Claimed-to-be foo" endorsement corresponds to
   recording that it may be a foo, but nobody proved it to US.  This
   may have happened because it was generated by a foo-maker-clone, or
   because it passed through a foreign carrier.

Just to clarify, your "Is Foo" is an authenticated endorsement, and
your "claimed-to-be-Foo" is an endorsement belief.  The scheme MarkM
and I worked out is slightly different than what you describe here:
an endorsement on Doc by Ed is a the ID of Doc and a hash of its
contents signed by Ed (with the info that this is an endorsement).
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.n

   If we differentiate things in this way, a vendor may chose to accept
   (without checking) data claimed-to-be-endorsed-by-his-product by a set
   of carriers, or to give his customer this option.  Then, if somebody
   hands him a data-bomb, he has an audit trail, and it's also his fault,
   not ours, because we TOLD him we hadn't seen the endorsement ourselves.

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.

dean

Appendix: Other responses:

   This is one thing "claimed-to-be-foo" is for.  On those rare (almost
   nonexistent) occasions where we integrate someone else's waldo into
   the backend, we will most likely be using different code than they
   did.  If we endorse it with "WordAStra", and we made an error that
   breaks the WordAStra product, it's OUR fault.  If we endorse it with
   "Xanadu-WordAStra" and "Claims-to-be-WordAStra", old releases of
   WordAStra will treat it as a foreign document type, and do extra
   checking.  If they don't catch an error that breaks their product,
   it's THEIR fault.  Once they're convinced the Waldo works correctly,
   they may trust it without checking in future releases of WordAStra.
   If if breaks after that, it's STILL THEIR fault.

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.  Let's discuss this in person, if you want to continue it.

   > []  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.  This would be appropriate for a site that wanted to run lots
of a particular Waldo.  I'm actually imagining a meta-level service in
which a frontend could download a filter process (with only a
connection to the frontend and the backend) that runs separate from
the backend, but on the backend's machine.  This cuts out most
communication delays (unless stubble is really slow) without
compromising the backend.  This is why I call them mid-ends:
frontends impose them on themselves, not any other frontend.

   > Bing!  You've hit the problem that's nagged me for awhile about
   > Waldos.  Waldos encapsulate an endorsement which represents their
   > type.  They endorse any Stamp made using them.  Since endorsements
   > really correspond to digital signatures in the distributed system,
   > this would require having every user defined waldo sign the
   > cryptographic hash of the contents of every orgl it makes - an
   > expensive proposition.  MarkM and I just discussed optimizing this for
   > all Waldos within a trust boundary, but it still looks expensive.  For
   > the normal use of endorsements (as endorsements), this would only need
   > to be done to stamps generated by the highest level Bert (that
   > actually carries endorsements).  This endorsed Bert would only get
   > hopped on Saves.  

   It also burns down the canopy.  We store endorsements efficiently by
   combining them.  Doing that to a secure hash corresponds to cracking
   the hash, which is a contradiction of the assumptions.  Therefore
   it is impossible to efficiently store the endorsement itself.

The canopy does not store endorsements.  It stores an abstraction of
them for filtered backfollow.  The backend sees an endorsement,
decides to believe it (because it came from a trusted source, had a
cryptographic hash, or whatever), and adds a purely internal
annotation to the canopy so that it can efficiently backfollow.