Re: Inclusion Lists for Hypercardus Clonus

[Michael McClary <michael>]

> Return-Path: <tribble>
> []
> 
> Right now we only implement de-registration.  We really do need
> re-registration (confirmance testing and type upgrades) to fully use
> our Waldos.  [examples]  I expect such
> examples to arise almost immediately, too.  I also consider it
> sufficiently important that third party Waldo types have conformance
> checking that it should really be part of the protocol.

You're right.

>[me]  It MAY arise if we, in some future release, integrate a third-party
>    waldo (say, "WordAStra") into the backend.  At that point, we may want
>    to make it automagically endorse with "Xanadu WordAStra" any "WordAStra"
>    data it retrieves that conforms.  (Since the backend would be endorsing
>    the data as conforming to our idea of the spec, it wouldn't rubberstamp
>    the endorsements from (potentially-broken) frontends, but would check
>    for itself.)
> 
> This strikes me as a bad idea for lots of reasons, most unrelated to
> possible implementations.  Eventually, Waldos will encapsulate their
> doc-type endoresement capability, so only documents created with the
> original "WordAStra" Waldo will have that type (regardless of broken
> frontends).  The doc-type should be incorporated (if at all) by
> licensing the endorsment used by the original Waldo.  I think we'd
> consider doing this only very rarely.

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.

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

>    It may also arise if we decide to check the data that arrives over BEBE.
>    We should do that starting with the first release where backend-users
>    will be running BEBE with a competitor's machine, to prevent a hacked
>    backend feeding them "poisoned" data.
> 
> 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.

What we can store efficiently is the statemtent: "When the user entered
this, he convinced us it was endorsed.  Trust us."  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.

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

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.

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.

This should CYA on the common-carrier case, too.  Better, perhaps,
is a set of endorsements corresponding to:
 - "Claimed to be 'foo' by someone we know is bar."
 - "Claimed to be 'claimed to be "foo" by someone bar knows is baz'
    by someone we know is bar"
etc.  (The endorsement mechanism is so efficient that this is a
negligable storage load.  We need only store the route-endorsement-def.
once for each route actually taken by one or more currently-stored data.)

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.

	michael