[E-Lang] Hash Chaining & Capabilities, Proposal #2b:
Off-Line Invocation Certificates
Mark S. Miller
markm@caplet.com
Sun, 22 Oct 2000 00:56:57 -0700
--=====================_471980==_.ALT
Content-Type: text/plain; charset="us-ascii"
At 03:50 PM 10/18/00, Bill Frantz wrote:
>For some reason, this paragraph made me think about the issues of running
>the e-protocol thru email. If we use signed, encrypted PGP email, I think
>the only thing we lose is perfect forward security.
>
>But this thought leaves me very confused about what online/offline really
>mean. Is offline one way messaging? (But email is multi-way as any flame
>war will demonstrate.) Is it slow? (But we could send the PGP encrypted
>data via OCR snail mail, or FedExed Zip disks.) Or does it mean no
>computer mediation?
Great question -- it had me sleepless for many hours. In the end, I don't
think I mean any one coherent thing by "on-line" vs "off-line". Rather,
there are a bunch of correlated distinctions. Pluribus represents one
extreme -- in which all the choices are in the "on-line" direction, and PKI
certificates (including my invocation certificate proposal) represents the
other "off-line" extreme. If I understand your proposal, I'd say your email
example is off-line as well, but maybe not at the extreme of the space.
In contrasting these two, in both cases I will restrict myself to unicast
communications, as multicast takes us into a whole different dimension of
variation, and both of our extreme examples are unicast, even if for
radically different reasons. (PKI Certificates are unicast, since they are
specific to a Recipient/Subject.)
1) There are the logical differences in the transport medium. Pluribus
builds on reliable TCP/SSL-like byte streams, and shares their nature of
reliable fail-stop order-preserving at-most-once message delivery. By
contrast, IP, UDP, email, PGP email, snail-mail, sneakernet, and PKI
Certificates are all send and pray, and have none of these characteristics.
All except IP are at least supposed to have integrity -- no message should
be received that wasn't sent. Orthogonally, the crypto versions of each
side of this dichotomy (Pluribus, SSL, PGP email, PKI Certificates) exhibit
the claimed properties under adversarial conditions, whereas the non-crypto
versions only guard against accident. Because PKI Certificates are so
undemanding of their transport medium, the transport medium is typically
left unspecified, since "it doesn't matter" how the message gets there.
Of course, as TCP/IP demonstrates, one can build more reliable forms from
less reliable ones. The issue is how much reliability is provided prior to
application-specific logic.
2) Closely related is stateful vs stateless. When communicating over a
TCP-like medium, once may as well use a stateful protocol, in which case
each message is only to be understood in the context of the other messages
it may be depending on. When using a UDP-like medium, one should use a
stateless protocol, since the temporal context in which each message is to be
interpreted is much less predictable. Such stateless messages must have a
more context-free or self-explanatory reading. I'd say this is the most
important of these distinctions.
3) Record keeping. Certificates and email are assumed to have a long-lived
record keeping value significantly in excess of their storage costs. With
record keeping comes the desire for auditing and non-repudiation. IP, UDP,
TCP, and Pluribus messages are normally considered ephemeral, and as network
bandwidth increases faster than disk bandwidth, we hope to generate more
traffic than we can store.
4) Speed differences, as you suggest. IP, UDP, TCP, SSL, and Pluribus are
all fast -- an individual communication must be much cheaper than a network
round trip or a PK calculation. Hence Pluribus uses long lived connections
and message pipelining to amortize these costs over many messages. Pluribus
is E's IPC mechanism, and experience with other systems indicates that IPC
performance is critical to overall system performance.
By contrast, consider all the steps and time delays in signing, encrypting,
sending, forwarding, receiving, decrypting, and verifying PGP email. Since
PGP is intended for uses where each individual email is human significant,
these vastly greater costs are fine. (The computer's perspective on Moore's
Law: Humans are becoming more expensive at an exponential rate!)
Certificates are normally assumed to be in this same "slow" category, which
I think is fine.
5) I'm not sure what you mean by "computer mediation", but let me take a
guess. In Pluribus, avoiding round trips is a performance issue, nothing
more. In a certificate system, it's a correctness issue. The certificate
must typically be interpretable by the machine that needs to interpret it
without having to ask other machines for help. I'm not saying this well,
but an example should explain what I'm getting at:
In Pluribus, when Alice passes to Bob a live reference to Carol, the
protocol assumes that all three vats can talk to each other to bring this
about. If a network partition happens between any of the parties before the
protocol is complete, it is acceptable for the introduction to fail. By
contrast, when Alice passes to Bob either a SturdyRef for Carol, or (in the
current proposal) a certificate authorizing Bob to access Carol, VatC
*necessarily* isn't involved, VatA only needs to successfully emit the
message, and can be inaccessible afterwards, and VatB only needs to receive
the message.
The "protocol" to bring about this transfer of rights is a single one-way
transmission between VatA and VatB -- not to economize on communications for
performance reasons, but because our notion of a certificate is that it's
meaningful without further communications. This is strongly related to
being stateless.
If I had to define on-line vs off-line in terms of any one issue, it'd be this one.
6...) I'm sure I'm missing some other dimensions of this space.
--=====================_471980==_.ALT
Content-Type: text/html; charset="us-ascii"
At 03:50 PM 10/18/00, Bill Frantz wrote:
For some reason, this paragraph
made me think about the issues of running
the e-protocol thru email. If we use signed, encrypted PGP email, I
think
the only thing we lose is perfect forward security.
But this thought leaves me very confused about what online/offline
really
mean. Is offline one way messaging? (But email is multi-way
as any flame
war will demonstrate.) Is it slow? (But we could send the PGP
encrypted
data via OCR snail mail, or FedExed Zip disks.) Or does it mean
no
computer mediation?
Great question -- it had me sleepless for many hours. In the end, I
don't
think I mean any one coherent thing by "on-line" vs
"off-line". Rather,
there are a bunch of correlated distinctions. Pluribus represents
one
extreme -- in which all the choices are in the "on-line"
direction, and PKI
certificates (including my invocation certificate proposal) represents
the
other "off-line" extreme. If I understand your proposal,
I'd say your email
example is off-line as well, but maybe not at the extreme of the
space.
In contrasting these two, in both cases I will restrict myself to unicast
communications, as multicast takes us into a whole different dimension of
variation, and both of our extreme examples are unicast, even if for
radically different reasons. (PKI Certificates are unicast, since
they are
specific to a Recipient/Subject.)
1) There are the logical differences in the transport medium.
Pluribus
builds on reliable TCP/SSL-like byte streams, and shares their nature of
reliable fail-stop order-preserving at-most-once message delivery.
By
contrast, IP, UDP, email, PGP email, snail-mail, sneakernet, and PKI
Certificates are all send and pray, and have none of these
characteristics.
All except IP are at least supposed to have integrity -- no message
should
be received that wasn't sent. Orthogonally, the crypto versions of
each
side of this dichotomy (Pluribus, SSL, PGP email, PKI Certificates)
exhibit
the claimed properties under adversarial conditions, whereas the
non-crypto
versions only guard against accident. Because PKI Certificates are
so
undemanding of their transport medium, the transport medium is typically
left unspecified, since "it doesn't matter" how the message
gets there.
Of course, as TCP/IP demonstrates, one can build more reliable forms from
less reliable ones. The issue is how much reliability is provided
prior to
application-specific logic.
2) Closely related is stateful vs stateless. When communicating
over a
TCP-like medium, once may as well use a stateful protocol, in which case
each message is only to be understood in the context of the other
messages
it may be depending on. When using a UDP-like medium, one should
use a
stateless protocol, since the temporal context in which each message is
to be
interpreted is much less predictable. Such stateless messages must
have a
more context-free or self-explanatory reading. I'd say this is the
most
important of these distinctions.
3) Record keeping. Certificates and email are assumed to have a
long-lived
record keeping value significantly in excess of their storage
costs. With
record keeping comes the desire for auditing and non-repudiation.
IP, UDP,
TCP, and Pluribus messages are normally considered ephemeral, and as
network
bandwidth increases faster than disk bandwidth, we hope to generate more
traffic than we can store.
4) Speed differences, as you suggest. IP, UDP, TCP, SSL, and
Pluribus are
all fast -- an individual communication must be much cheaper than a
network
round trip or a PK calculation. Hence Pluribus uses long lived
connections
and message pipelining to amortize these costs over many messages.
Pluribus
is E's IPC mechanism, and experience with other systems indicates that
IPC
performance is critical to overall system performance.
By contrast, consider all the steps and time delays in signing,
encrypting,
sending, forwarding, receiving, decrypting, and verifying PGP
email. Since
PGP is intended for uses where each individual email is human
significant,
these vastly greater costs are fine. (The computer's perspective on
Moore's
Law: Humans are becoming more expensive at an exponential
rate!)
Certificates are normally assumed to be in this same "slow"
category, which
I think is fine.
5) I'm not sure what you mean by "computer mediation", but let
me take a
guess. In Pluribus, avoiding round trips is a performance issue,
nothing
more. In a certificate system, it's a correctness issue. The
certificate
must typically be interpretable by the machine that needs to interpret it
without having to ask other machines for help. I'm not saying this
well,
but an example should explain what I'm getting at:
In Pluribus, when Alice passes to Bob a live reference to Carol, the
protocol assumes that all three vats can talk to each other to bring this
about. If a network partition happens between any of the parties
before the
protocol is complete, it is acceptable for the introduction to
fail. By
contrast, when Alice passes to Bob either a SturdyRef for Carol, or (in
the
current proposal) a certificate authorizing Bob to access Carol, VatC
*necessarily* isn't involved, VatA only needs to successfully emit the
message, and can be inaccessible afterwards, and VatB only needs to
receive
the message.
The "protocol" to bring about this transfer of rights is a
single one-way
transmission between VatA and VatB -- not to economize on communications
for
performance reasons, but because our notion of a certificate is that it's
meaningful without further communications. This is strongly related
to
being stateless.
If I had to define on-line vs off-line in terms of any one issue, it'd be
this one.
6...) I'm sure I'm missing some other dimensions of this space.
--=====================_471980==_.ALT--