[E-Lang] Re: Hash Chaining & Capabilities, Proposal #2d: Deputizing Remote Vats

[Mark S. Miller]

At 03:06 PM 11/13/00, Nikita Borisov wrote:
>"Mark S. Miller" writes:
>>... Is there a compelling 
>>need for off-line certificates?  Do they address a real problem?)
>
>While I cannot offer as much experience, I have my own personal
>motivations for offline certificates, which are scalability and
>vulnerability to attack.  In the context of vats and capabilities, an
>online protocol requires VatA to participate in every exercise of the
>capability; this may be impractical if Alice hands a capability to Bob
>to a large number of people.  The vulnerability argument says that since
>VatA has the power P, an attack on VatA results in compromise of P.  If
>P is highly sensitive, Alice might want to ensure that VatA is always
>under her physical control (eg. laptop), which precludes it from being
>always online.  Offline certificates allow Alice to create an online
>agent and give it a *restriction* of P.  In some systems, a "vat" with
>the power P *never* has to be online (e.g. in DNSSEC, the signature key
>can be kept in a vault, and the signatures it generates can be
>transferred to an online server on a flopppy), although I'm not sure
>whether the same is true in the context of capabilities.

I like these reasons why off-line certificates are important, as well as 
Bill's and David's.  (Though I'll be posting a quibble with one of David's 
reasons.) In fact, I find them sufficiently convincing I bought the domain 
names: capcert.com & capcert.org.  I'm going to leave capcert.com a 
placeholder for now, but I will turn capcert.org into a site devoted to 
off-line capability-based active invocation certificates, along the lines of 
the endless series of messages I've been sending out on this thread.  I will 
complete the proposal on this thread here first, but then I will tie it all 
together into a proposal to be posted at capcert.org.

A CapCert will be expressed in CapML -- the XML encoding of Kernel-E 
enhanced with extra tags for certificate signatures and such, probably based 
on XML-Signature http://www.w3.org/TR/xmldsig-core/ translated into 
Minimal-XML.   I have yet to say anything concrete here, but I did also grab 
capml.com and capml.org.

The following question cannot be answered until I complete the proposal, but 
here's advance notice:

We derived CapCert from SPKI by removing everything that wasn't 
capabilities, and adding the (yet to be explained) mobile-code-based 
"active" feature instead. Legacy support aside, is CapCert *strictly* better 
than SPKI?  I believe it is.  Although x509 has taken over the world, I also 
believe everyone thinks SPKI is strictly superior to it, and (PGP aside) 
there don't currently seem to be any other contenders.  In other words, I 
believe that none of the non-capability stuff in SPKI was adding any value, 
and that pure capability invocation certificates with an appropriate 
arrangement for active mobile code provides everything achievable anyone 
knows to want from a PKI.  If this bold claim remains standing after y'all 
shoot at it, CapCert could be important.  When the time comes, please fire 
away.

Jonathan, could you set up a capcert mailing list?  When the proposal is 
complete, let's have the argument on that list.  Bill & Alan, when the time 
comes, could you invite the SPKI & E-Speak3 folks to participate?


        Cheers,
        --MarkM