Deprecating bearer-based sturdyrefs or no?
9 views
Skip to first unread message
Christopher Lemmer Webber
Jun 7, 2021, 11:57:33 AM6/7/21
to cap-...@googlegroups.com
Producing a tuple of a certificate-based-ocap plus its
invocation/delegation key can produce the equivalent of a bearer token,
albeit at greater verbosity (this will always be larger and more
expensive). Given this, is it time to deprecate the bearer-based
sturdyref in favor of the "unionized certificate" version?
The mention that this is a *possibility* has been discussed several
times. Currently in the ocapn URI types, I do allow for both of these
approaches, and currently I do provide the bearer-based approach. Is it
worth it?
Let's make some arguments in both directions. Let's assume Alice on A
has a reference to Bob on B, either via the "bearer-sturdyref" or
"certunion-sturdyref" (it strikes me that this is still effectively a
sturdyref) approach:
- Consider if A is compromised by M (Mallet). In either the
certunion or bearer apparoach, sturdyrefs have been leaked.
(It is of course true that A could store the keys to actually invoke
these "separately", but that's also true for the bearer refs too...
A could encrypt each bearer sturdyref with an external key to reduce
risks of machine compromise just as well.) So in the A-compromise
case, we see no benefit.
- Consider if B is compromised by M. Well, in the most basic
implementation where B stores a map of {bearer-token: ref}, B is in a
much tougher spot because B has to re-issue sturdyrefs all over the
place for these ocaps... basically *all incoming* sturdyrefs are
screwed. In that case, certificates appear to do better since B does
not need to re-issue. There is a well-known solution to this: B
instead stores just the hashes of the bearer tokens. This is still a
*little* more dangerous: if Mallet sits undiscovered for a longer
period of time, Mallet can "sniff" the unhashed solutions for each
incoming invoked bearer token. (Mallet also may be able to do the
same, watching for any outgoing unions of keys-and-certificates made
during compromise-time... Mallet simply cannot access *older* issued
certunion pairs.) So the certunion has a bit of a benefit, but not
as large of a benefit as it may appear.
We can't realistically get rid of sturdyrefs; the convenience of eg
copying and pasting a link to my blogpost is too significant without
having to issue to a derived key of yours. Given that the certunion
approach only provides marginal benefit, I wonder if we shouldn't still
keep the bearer cert stuff... at least we *know* what risks we're facing
there.
Thoughts?
- Chris
invocation/delegation key can produce the equivalent of a bearer token,
albeit at greater verbosity (this will always be larger and more
expensive). Given this, is it time to deprecate the bearer-based
sturdyref in favor of the "unionized certificate" version?
The mention that this is a *possibility* has been discussed several
times. Currently in the ocapn URI types, I do allow for both of these
approaches, and currently I do provide the bearer-based approach. Is it
worth it?
Let's make some arguments in both directions. Let's assume Alice on A
has a reference to Bob on B, either via the "bearer-sturdyref" or
"certunion-sturdyref" (it strikes me that this is still effectively a
sturdyref) approach:
- Consider if A is compromised by M (Mallet). In either the
certunion or bearer apparoach, sturdyrefs have been leaked.
(It is of course true that A could store the keys to actually invoke
these "separately", but that's also true for the bearer refs too...
A could encrypt each bearer sturdyref with an external key to reduce
risks of machine compromise just as well.) So in the A-compromise
case, we see no benefit.
- Consider if B is compromised by M. Well, in the most basic
implementation where B stores a map of {bearer-token: ref}, B is in a
much tougher spot because B has to re-issue sturdyrefs all over the
place for these ocaps... basically *all incoming* sturdyrefs are
screwed. In that case, certificates appear to do better since B does
not need to re-issue. There is a well-known solution to this: B
instead stores just the hashes of the bearer tokens. This is still a
*little* more dangerous: if Mallet sits undiscovered for a longer
period of time, Mallet can "sniff" the unhashed solutions for each
incoming invoked bearer token. (Mallet also may be able to do the
same, watching for any outgoing unions of keys-and-certificates made
during compromise-time... Mallet simply cannot access *older* issued
certunion pairs.) So the certunion has a bit of a benefit, but not
as large of a benefit as it may appear.
We can't realistically get rid of sturdyrefs; the convenience of eg
copying and pasting a link to my blogpost is too significant without
having to issue to a derived key of yours. Given that the certunion
approach only provides marginal benefit, I wonder if we shouldn't still
keep the bearer cert stuff... at least we *know* what risks we're facing
there.
Thoughts?
- Chris
Christopher Lemmer Webber
Jun 7, 2021, 2:17:19 PM6/7/21
to cap-...@googlegroups.com
Christopher Lemmer Webber writes:
> Producing a tuple of a certificate-based-ocap plus its
> invocation/delegation key can produce the equivalent of a bearer token,
> albeit at greater verbosity (this will always be larger and more
> expensive). Given this, is it time to deprecate the bearer-based
> sturdyref in favor of the "unionized certificate" version?
DanC points out this is a product, not a union. Math terminology is
> Producing a tuple of a certificate-based-ocap plus its
> invocation/delegation key can produce the equivalent of a bearer token,
> albeit at greater verbosity (this will always be larger and more
> expensive). Given this, is it time to deprecate the bearer-based
> sturdyref in favor of the "unionized certificate" version?
where I tend to make mistakes a lot, sorry!
which are significant:
- Delegation
- Attenuation
Both of those can done on certificates without intermediaries, which is
a significant benefit of certificate approaches.
> Thoughts?
> - Chris
Mike Stay
Jun 7, 2021, 2:53:42 PM6/7/21
to cap-...@googlegroups.com
On Mon, Jun 7, 2021 at 12:17 PM Christopher Lemmer Webber <cwe...@dustycloud.org> wrote:
Christopher Lemmer Webber writes:
> Producing a tuple of a certificate-based-ocap plus its
> invocation/delegation key can produce the equivalent of a bearer token,
> albeit at greater verbosity (this will always be larger and more
> expensive). Given this, is it time to deprecate the bearer-based
> sturdyref in favor of the "unionized certificate" version?
DanC points out this is a product, not a union. Math terminology is
where I tend to make mistakes a lot, sorry!
That's a pretty small mistake: union is the product in the category of sets and inclusions, as opposed to tuples, the product in the category of sets and functions. Also, if multiple copies of the same certificate don't matter and if the order of the certificates doesn't matter, then the semantics is closer to union than to tuple.
Reply all
Reply to author
Forward
0 new messages