Sealer/unsealer with capability certificates

[Alan Karp]

Someone on the UCAN list is asking how to let someone delegate a capability without being able to use it.  One possible solution is rights amplification.  Another is sealer/unsealer.  Has anyone heard of an implementation of the latter using capability certificates?

--------------
Alan Karp

[Mark S. Miller]

Does not answer your question, but to clarify

sealer/unsealer is itself a form of rights amplification.

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3H3qRdhPjZctjhiLg-f170anKH5vimc9NxfT-JLMWX%2Bw%40mail.gmail.com.

--

  Cheers,
  --MarkM

[David Nicol]

Hello all

As usual I've got insufficient credentials and don't know all the jargon, but here are my two satoris:

the request is, client wishes to be able to arrange for users to delegate capabilities they do not hold.

This request implies a separation between capacity to use a capability and capacity to delegate it, which seems counter to general POLA practice, must be re-examined.

Why are capacity to execute and capacity to delegate combined? We imply that we trust the holders not to recklessly delegate: to fulfill the client's request we have to stop doing that. Trusting a holder not to recklessly delegate may make sense in operating system kinds of things like handles to file system objects, but then again maybe it doesn't and there has been a CD vulnerability there all along.

Let's say we're designing a security policy for who controls the thermostat in a warehouse. The thermostat is part of the facilities package from Karp Industrial Products which the company purchased as an optional addition to the general enterprise package from Karp Security, of which Karp Industrial is a wholly owned subsidiary.

Who gets to control the thermostat (i.e. they hold a thermostat control capability) is set by the people who set up the org chart, by instructing to the help desk. Neither the executives nor the helpdesk, generally, would control the thermostat , so POLA indicates they shouldn't be able to.

Warehouse managers who hold the thermostat control capability may or may not be able to delegate/rescind it to staff on their teams, or to anyone else, depending. For simplicity let's give these trusted humans general delegation ability instead of making the situation more complicated than it has to be, unless it has to be that complicated.

for shorter words, I think "grant" is a good verb for delegation. "grant" and "use" get separated.

I might have just described either "sealer/unsealer" or "rights amplification" I'm not sure.

What I think I'm suggesting is separation of grant ability from use ability, in a universe where capabilities are strongly tied to authenticated identities. Access Control Lists are not the enemy: as I understand it, the difference between ACLs and Capabilities is who owns the policy: with an ACL the central system owns the policy, with Capabilities they are distributed; outside of that the available semantics should be the same.

Hopefully I've described a scenario where the request under discussion makes sense.

How do I invest in Karp Security?

David "tipjar" Nicol

--

You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3H3qRdhPjZctjhiLg-f170anKH5vimc9NxfT-JLMWX%2Bw%40mail.gmail.com.

--

"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash

[Alan Karp]

On Wed, Nov 8, 2023 at 4:56 PM David Nicol <david...@gmail.com> wrote:

Hello all

As usual I've got insufficient credentials and don't know all the jargon, but here are my two satoris:

the request is, client wishes to be able to arrange for users to delegate capabilities they do not hold.

This request implies a separation between capacity to use a capability and capacity to delegate it, which seems counter to general POLA practice, must be re-examined.

Why are capacity to execute and capacity to delegate combined? We imply that we trust the holders not to recklessly delegate: to fulfill the client's request we have to stop doing that. Trusting a holder not to recklessly delegate may make sense in operating system kinds of things like handles to file system objects, but then again maybe it doesn't and there has been a CD vulnerability there all along.

Let's say we're designing a security policy for who controls the thermostat in a warehouse. The thermostat is part of the facilities package from Karp Industrial Products which the company purchased as an optional addition to the general enterprise package from Karp Security, of which Karp Industrial is a wholly owned subsidiary.

Who gets to control the thermostat (i.e. they hold a thermostat control capability) is set by the people who set up the org chart, by instructing to the help desk. Neither the executives nor the helpdesk, generally, would control the thermostat , so POLA indicates they shouldn't be able to.

Warehouse managers who hold the thermostat control capability may or may not be able to delegate/rescind it to staff on their teams, or to anyone else, depending. For simplicity let's give these trusted humans general delegation ability instead of making the situation more complicated than it has to be, unless it has to be that complicated.

for shorter words, I think "grant" is a good verb for delegation. "grant" and "use" get separated.

I might have just described either "sealer/unsealer" or "rights amplification" I'm not sure.

Your thermostat example is just a little too simple unless we require that you pass a training course in order to operate one.  Managers decide who will operate the thermostats in their departments, but never get trained.  Hence, department heads would like to delegate permission to delegate without delegating permission to use.  This pattern can be handled with rights amplification (I know I proposed a better term, but I don't remember what it is.)  Managers can be given one of the capabilities needed to operate the thermostat, and those who pass the training course can be given the other one.  No ACLs needed.  As MarkM noted, you can implement this pattern with sealer/unsealer.

 

What I think I'm suggesting is separation of grant ability from use ability, in a universe where capabilities are strongly tied to authenticated identities. Access Control Lists are not the enemy: as I understand it, the difference between ACLs and Capabilities is who owns the policy: with an ACL the central system owns the policy, with Capabilities they are distributed; outside of that the available semantics should be the same.

There's more to the difference between ACLs and capabilities than just who owns the policy.  In fact, you can use an ACL to decide who gets which capabilities, as done with Linux file handles. The essential difference is how you decide whether a request is authorized.  Checking an ACL to see if any of the requester's permissions authorizes the request is the root cause of the confused deputy vulnerability.  That doesn't happen when using a capability is sufficient to prove authorization.

If you tie a capability to an authenticated identity (As I recall, that's what Li Gong was proposing in the early 1980s.), you've made attenuated delegation impractical.  People will then share credentials making both security and usability worse.  

 

Hopefully I've described a scenario where the request under discussion makes sense.

How do I invest in Karp Security?

Karp Security will be listed as KAR on the Nasdaq at some point in the distant future.

--------------
Alan Karp

[Chris Hibbert]

On 11/8/23 4:55 PM, David Nicol wrote:
>
> What I think I'm suggesting is separation of grant ability from use
> ability, in a universe where capabilities are strongly tied to
> authenticated identities. Access Control Lists are not the enemy: as I
> understand it, the difference between ACLs and Capabilities is who owns
> the policy: with an ACL the central system owns the policy, with
> Capabilities they are distributed; outside of that the available
> semantics should be the same.

At Agoric, we've been talking for a while about "use" capabilities vs.
"transfer" capabilities. (We all agree that these names are bad; MarkM
may have settled on a better term this week.)

Our intent is not to separate (holding) the ability to transfer from the
ability to use, it's to convert an oCap that conveys the ability to use
into an oCap that can be transferred.

We've noticed that many "use" capabilities can't be transferred easily,
and we'd like most capabilities to be generally transferable. The theory
is that we'd build a generic utility that would take a useful
capability, and freeze the underlying object and add a wrapper. The
wrapper would be transferable (which means the recipient can get
exclusive access to it), and easily converted back to a use object.

In our system, it's also important that the transferrable capability be
legible--that is that it has a description that our contracts will
recognize and enforce equality on, so that someone can make an offer for
that particular capabilty, and be sure that their offer will only be
honored if the cap they get matches the description.

I like "grant" for the transferable part. It the use-able part that
we've had trouble coming up with a good name for.

Chris
--
C. J. Cherryh, "Invader", on why we visit very old buildings:
"A sense of age, of profound truths. Respect for something
hands made, that's stood through storms and wars and time.
It persuades us that things we do may last and matter."

Chris Hibbert
hib...@mydruthers.com
Blog: http://www.pancrit.org
http://mydruthers.com

[Mark S. Miller]

Ownable

https://github.com/Agoric/agoric-sdk/pull/8517 VERY DRAFTY. Should not be expected to work at all yet.

Enjoy!

--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/770899e4-0bf5-4870-94d5-9284cd3a3184%40mydruthers.com.

--

  Cheers,
  --MarkM

[Matt Rice]

Given the comparison to "ownership types", which generally have some
subset of the substructural rules e.g. Weakening, Exchange,
Contraction.
It might be interesting to try and fit these within the framework of
substructural rules/logic, I don't have a great understanding of your
Ownables having just read your PR description.
But if I squint hard enough, I somewhat wonder if it couldn't be more
related to the relatively rare "ordered type" which discards all the
substructural rules.
I personally think they are interesting from a capability perspective.
At this point I must ask whether there is any resemblance of this
two-phase lifecycle that resembles a stack?
E.g. is the notion of two-phase representing a particularly small
stack of bounded size (1?)? Anyhow these are the things I wonder
about, I don't expect there are any particularly easily obtained
answers for them, but I still feel they are worth wondering about.

might as well mention a typo while i'm here.

The lifecycle of an ownable objects.
^^ either drop the 'an', or depluralize objects?

> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK5yZYj3s3NCvVZk9PAZOat%3DboBD_jif3x47DpAun0gL6%3DkBTA%40mail.gmail.com.

[Mark S. Miller]

On Thu, Nov 9, 2023 at 12:10 AM Matt Rice <rat...@gmail.com> wrote:

Given the comparison to "ownership types", which generally have some
subset of the substructural rules e.g. Weakening, Exchange,
Contraction.
It might be interesting to try and fit these within the framework of
substructural rules/logic, I don't have a great understanding of your
Ownables having just read your PR description.
But if I squint hard enough, I somewhat wonder if it couldn't be more
related to the relatively rare "ordered type" which discards all the
substructural rules.
I personally think they are interesting from a capability perspective.
At this point I must ask whether there is any resemblance of this
two-phase lifecycle that resembles a stack?
E.g. is the notion of two-phase representing a particularly small
stack of bounded size (1?)?  Anyhow these are the things I wonder
about, I don't expect there are any particularly easily obtained
answers for them, but I still feel they are worth wondering about.

Frankly I did not follow most of that. I'm still an amateur on fancy static type systems. ELI5 ? 

The most fundamental reason for alternating between the phases is that the invitation form is the one to offer for sale or try to buy. It must have a description of the right in a quiescent state, so the right must not be exercisable while a redeemable invitation for that right continues to be unredeemed.

A comparison I like is the difference (normally) between a house as lived in and a house as offered for sale. If the house remains quiescent between inspections and purchase, then the buyer is more likely to be willing to rely on the inspection. This also emphasizes the difference between use-value vs transferable-value. While I'm living in the house, part of its value to me rests in having all my stuff scattered around in ways adapted to my habits. When I put the house up for sale, I first remove all those things, move out, and let the inspectors in. I remove the subsidiary my stuff typically not to deny their value to the buyer, but because their value is besides the point of what the buyer is normally interested in.

Likewise, when the ownable object is in the exercisable state, my exercise of it may build up a bunch of subsidiary data structures peculiar to what I'm doing with it. Those may lose their utility to me once the ownable object is made into an invitation, but neither is the utility of those designed to be transferred. Rather, the recipient, after redeeming the invitation for a new ownable object, would then rebuild their own idiosyncratic data structures adapted to what they're interested in doing.

Those familiar with E will see echoes of the distinction between fragile liveRef vs sturdyRef. But the purpose of the distinction is completely different here.

might as well mention a typo while i'm here.

The lifecycle of an ownable objects.
^^ either drop the 'an', or depluralize objects?

Fixed, thanks!

 

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CACTLOFryVYETBLm-fBVQHYBB%3DOo9z8deAJe%2Bd8zj-aJuBu0zuQ%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Matt Rice]

On Thu, Nov 9, 2023 at 9:41 AM Mark S. Miller <eri...@gmail.com> wrote:
>
>
>
> On Thu, Nov 9, 2023 at 12:10 AM Matt Rice <rat...@gmail.com> wrote:
>>
>> Given the comparison to "ownership types", which generally have some
>> subset of the substructural rules e.g. Weakening, Exchange,
>> Contraction.
>> It might be interesting to try and fit these within the framework of
>> substructural rules/logic, I don't have a great understanding of your
>> Ownables having just read your PR description.
>> But if I squint hard enough, I somewhat wonder if it couldn't be more
>> related to the relatively rare "ordered type" which discards all the
>> substructural rules.
>> I personally think they are interesting from a capability perspective.
>> At this point I must ask whether there is any resemblance of this
>> two-phase lifecycle that resembles a stack?
>> E.g. is the notion of two-phase representing a particularly small
>> stack of bounded size (1?)? Anyhow these are the things I wonder
>> about, I don't expect there are any particularly easily obtained
>> answers for them, but I still feel they are worth wondering about.
>
>
> Frankly I did not follow most of that. I'm still an amateur on fancy static type systems. ELI5 ?

I will try, however I'm particularly terrible at explaining much of anything.
let me refer to the rules themselves:
https://en.wikipedia.org/wiki/Structural_rule
and the table of type systems systems built upon them...
https://en.wikipedia.org/wiki/Substructural_type_system

>
> The most fundamental reason for alternating between the phases is that the invitation form is the one to offer for sale or try to buy. It must have a description of the right in a quiescent state, so the right must not be exercisable while a redeemable invitation for that right continues to be unredeemed.

This resource based analogy is apt, part of my question (the pure
speculation part about ordered systems) is largely curiosity I think
it is probably not the case (however from the table there aren't that
many substructural systems for those following the common rules and
you had eliminated half the others, hence my curiosity.)
The general analogy for substructure type systems is also that of
resource usage where the.

Ordered correlates to a stack, that is in a stack only ever access the
top of the stack.
Linear correlates to a heap (you can access any variable on the heap)
these are the common resource analogies for substructural systems, I
will
try and relate your house analogy back to these.

> A comparison I like is the difference (normally) between a house as lived in and a house as offered for sale. If the house remains quiescent between inspections and purchase, then the buyer is more likely to be willing to rely on the inspection. This also emphasizes the difference between use-value vs transferable-value. While I'm living in the house, part of its value to me rests in having all my stuff scattered around in ways adapted to my habits. When I put the house up for sale, I first remove all those things, move out, and let the inspectors in. I remove the subsidiary my stuff typically not to deny their value to the buyer, but because their value is besides the point of what the buyer is normally interested in.

This in particular sounds to me like perhaps like switching between
the presence and absence of the weaking (first link) rule. With the
weakening rule present in the case of a use-value. And absent in the
case of a transferable-value. This rule in particular describes
whether it is a valid rule of inference such that if we consider your
house to be gamma.
let epilon imply it being either a use-value or transferable-value
and your stuff A. In the case of a use-value we are saying that being
a use-value still holds if we add your stuff to the environment.
In the case of a transferable-value, adding your stuff to the
environment is not a valid rule for epsilon to still hold.

Presumably contraction does not hold for transferable-values. Say your
house is made of bricks, the contraction rule when given 2 bricks,
would allow you to remove one.
Because well they are both bricks, and there is still one left.

The Exchange rule we haven't really discussed in any way I can tell.
It is the rule that distinguishes an Ordered from the Linear type,
where it is allowed in a linear type
but disallowed in an ordered one. Its absence in an ordered type
system is what creates the stack-like use in order.
Without it you cannot reorder elements A, B -> B, A. Thus the head of
the stack must be used first.
In an actual physical real-estate analogy exchange certainly matters,
reordering the roof with the floor is likely to void any inspection
that made it tranferable.
But I'm uncertain whether this is a property of the analogy that
translates directly to a property of your owned objects.

> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK5yZYjnu7SXE-DB9mk%2BE85YohQfbDbjF9WQbci5k8qXp%3DK9GQ%40mail.gmail.com.

[Matt Rice]

Apologies, instead of epsilon that should be sigma.

[David Nicol]

Is everyone on this list an insomniac? The scenario I had in mind with the thermostat was not a really complicated thermostat, but rather keeping the workers from adjusting it because the company cares more about its power bill than about worker comfort, and they have had trouble in the past with different workers resetting the thermostat back and forth because of different temperature preferences and things got ugly. Oddly, I was imagining warehouse workers, not the office workers at the U I used to work for, who often had legitimate grievances about the unified heating and cooling system, especially during the transitional periods when they would switch the radiators from circulating steam to circulating super-cooled liquids. But yeah that's immaterial.

On Wed, Nov 8, 2023 at 7:27 PM Alan Karp <alan...@gmail.com> wrote:

If you tie a capability to an authenticated identity (As I recall, that's what Li Gong was proposing in the early 1980s.), you've made attenuated delegation impractical.  People will then share credentials making both security and usability worse.  

how about when tieing a capability to an authenticated identity is optional when coining it? For instance Google Drive links: they can be tied to a known Google user account or they can be "anyone with the link." I don't think that service offers re-sharing shared documents though, additional share links have to come from the document owner. Could this be fixed, and, before asking that, should it?

[Alan Karp]

On Wed, Nov 8, 2023 at 7:27 PM Alan Karp <alan...@gmail.com> wrote:

If you tie a capability to an authenticated identity (As I recall, that's what Li Gong was proposing in the early 1980s.), you've made attenuated delegation impractical.  People will then share credentials making both security and usability worse.  

how about when tieing a capability to an authenticated identity is optional when coining it? For instance Google Drive links: they can be tied to a known Google user account or they can be "anyone with the link." I don't think that service offers re-sharing shared documents though, additional share links have to come from the document owner. Could this be fixed, and, before asking that, should it?

Implementing this idea always weakens security and harms usability while giving no benefit.  The problem is credential sharing.  If you try to prevent me from delegating a capability by tying it to my identity, I will simply share whatever I need to so that the other person can use the capability as me.  In other words, I've had to do extra work, and I've given away a lot more than just the permission of the capability.  Even if you can prevent credential sharing, I can alway proxy uses of the capability.  As before, I've had to do extra work, and you've lost the audit trail of who actually used the capability.

--------------
Alan Karp

[Matt Rice]

On Thu, Nov 9, 2023 at 9:41 AM Mark S. Miller <eri...@gmail.com> wrote:
>
> A comparison I like is the difference (normally) between a house as lived in and a house as offered for sale. If the house remains quiescent between inspections and purchase, then the buyer is more likely to be willing to rely on the inspection. This also emphasizes the difference between use-value vs transferable-value. While I'm living in the house, part of its value to me rests in having all my stuff scattered around in ways adapted to my habits. When I put the house up for sale, I first remove all those things, move out, and let the inspectors in. I remove the subsidiary my stuff typically not to deny their value to the buyer, but because their value is besides the point of what the buyer is normally interested in.
>
> Likewise, when the ownable object is in the exercisable state, my exercise of it may build up a bunch of subsidiary data structures peculiar to what I'm doing with it. Those may lose their utility to me once the ownable object is made into an invitation, but neither is the utility of those designed to be transferred. Rather, the recipient, after redeeming the invitation for a new ownable object, would then rebuild their own idiosyncratic data structures adapted to what they're interested in doing.

In my previous email I (tried) to explain the structure rules of
inference, but I wanted to follow up on the 'use-value'
'transferable-value' modalities affecting the structural rules
admitted/discarded,
as that is what these appear to be to me... I don't know much of
anything about modal substructrual logics, and didn't find a whole lot
that seemed relevant due to the unfortunately named (linear time
temporal logic).
But reading one paper [1] on a fibrational framework for substructural
and modal logics.
It had a reference to a 1994 paper to "A mixed linear and non-linear
logic", which has a very in depth account of the "of course" modality
from linear logic

"This paper attempts to explain the connection between
ILL(Intuitionistic linear logic) and IL(intuitionistic logic) more
directly
and symmetrically by giving a logic, term calculus and categorical
model for a system
in which the linear and non-linear worlds exist on an equal footing,
with operations
allowing one to pass in both directions".

"As is well-known, linear logic does not contain the structural rules
of weakening and
contraction, but these are reintroduced in a controlled way via a
unary operator"

The "of course" modality was present in Girard's original linear
logic, anyhow to me it does have the same feeling as your two-phase
lifecycle.
Hope it helps.

[1]: https://dlicata.wescreates.wesleyan.edu/pubs/lsr17multi/lsr17multi.pdf
[2]: https://nickbenton.name/mixed3.pdf (I love that this paper
contains 2 sections, the first wrong way, and the second wrong way).