Here's what I told the DWN people

[Alan Karp]

Comments appreciated.

----------------------

Revoking a public key is harder than revoking a certificate capability. You don't know who will be relying on a public key, so you need some sort of widely accessible list of the revoked public keys. For a capability, you know that only the verifier for the resource the capability designates needs to know that the capability has been revoked. While simpler, any capability revocation scheme must have a way to know if a revocation request is authorized. You also need a way to tell the resource server to stop honoring a specific capability and any delegations from it. That could be a problem if you've replaced parts of the delegation chain with proofs that the delegation is legal. There's also the complication of a distributed system. Is the revocation effective when received by the first node? The last? A quorum?

There are a number of options when deciding how to do revocation, some of which are in conflict. The design will have to make choices based on requirements specific to the system. The key difference among these choices is who is authorized to revoke a capability.

1. No revocation; rely on short-lived capabilities.

This is the approach taken by Simple Public Key Infrastructure (SKPI, pronounced spooky), RFC 2693, 1999. One problem with this approach is the need to continually reissue capabilities that are needed beyond the expiration time. Another is picking the lifetime. Too long, and there's too much opportunity for abuse; too short and the refresh overhead is too high. One example of the problem is OAuth 2. They originally recommended a 5 minute lifetime for bearer tokens, which later was increased to hours and then days.

2. Revocation is a specific permission.

You might want a specific revoke capability that you can delegate to someone else. For example, Alice delegates a capability to Bob and delegates the revoke permission to HR. When Bob changes jobs or leaves the company, HR can revoke all capabilities delegated to Bob without needing to be in the delegation chain.

3. The holder of a capability can revoke it.

It seems unnecessary for the holder of a capability to revoke it. You could just stop using it. However, explicitly revoking a capability you hold prevents accidental use of it or use by a successful hack.

4. The delegator of a capability can revoke direct delegations.

This choice is the most natural. In fact, it's necessary, but there are cases, discussed below, where it is not sufficient.

5. The delegator of a capability can revoke any delegation deeper in the chain.

There are enterprise use cases in which #4 can cause problems. Imagine Alice, a director, delegates a capability to Bob , a department manager, who subsequently delegates that capability to Carol, David, and perhaps many more. Alice finds out that David should not have been given the permission, but Bob is unavailable to revoke David's capability. With #4, Alice can revoke Bob's capability, but then Carol and the other can't do their jobs. With #5 Alice can revoke the capability given to David. This use case presumes that Alice knows David got a delegation, but such auditing is necessary in an enterprise.

6. Revoke the public key the certificate capability is issued to.

Telling the resource server that the public key a capability was issued to is revoked effectively revokes the capability, but you need a separate mechanism to know who has permission to revoke that public key. If the public key was used for more than one capability, you might inadvertently revoke that capability as well. Consider the case where Alice is a contractor for Bob, who gives her a capability to some resource. Alice is also a contractor for Carol, who gives Alice a different capability to the same resource, a common situation in the enterprise. A problem arises if Alice uses the same public key for both capabilities. Bob will revoke the public key when his contract with Alice ends, but that will also revoke the capability Alice got from Carol, whose contract is still active. If the intent is to revoke all capabilities issued to Alice by revoking one key, then you need a widely accessible place to list revoked public keys so that all capability verifiers can find them. However, you lose the privacy that comes from using different public key for each capability.

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

[Rob Meijer]

Number 3 had me confused at first, untill I realized #3 and others that follow imply "individual" delegation of revocable capabilities (basically one caretaker per object delegated to). While this is a valid and solid (though sometimes complicating) concept, it might help making it explicit.

If the revocable delegation isn't individual, for example when scaling horizontally, the question arises if an instance having the authority to revoke in the name of the service would constitute least authority, and use-only caps will make sense.

I think in order to make the case against use-only caps, you should probably explicitly make the case for individual delegation of revocable caps.

Hope I'm making sense,

Rob

--
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/CANpA1Z155CKv5eaowj%3Dd2aqOFdo%3DrmnDaU96-8P_4%2Bk62iGEsg%40mail.gmail.com.

[Mark S. Miller]

What's "DWN"?

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAMpet1VYsF%2B%3DXqUN2fhaO3LdZH0LoxNVDaH39E4kV1HYhB%2BDag%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Alan Karp]

Distributed Web Nodes, a project of the Distributed Identity Foundation.  It's basically a storage system where each logical node consists of 3 physical nodes.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK5yZYga-OW92rR9XAF9KXqep%3D9Ra9rFSParb6C1Wn6us%3Dh%3DZg%40mail.gmail.com.

[Mark S. Miller]

2/3 +1 of 3 is 3

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z2MpBmNAaycFs6wNn%3D5Bx8KzzjA0abLU6vuVDNTE%3DrVwA%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Alan Karp]

The nodes are trusted, so Byzantine failures aren't a consideration.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK5yZYjTBr6prRDHABwapy4QNKNm9y0ZkaSgenrh%2Bz_iew-m7Q%40mail.gmail.com.

[Mark S. Miller]

So what's the point of having 3?

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z2M44O9JZurf3w-ynLXoVmO4-8xZbOMNQbdLkoR7AVoyg%40mail.gmail.com.

--

  Cheers,
  --MarkM

[Mike Stay]

Redundancy in case one fails.

> To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK5yZYgJFuQOAFOu38m%2BNL5SM_Rdnv5L4y68ZxstF%3DG-ag6qXg%40mail.gmail.com.



--
Mike Stay - meta...@gmail.com
https://math.ucr.edu/~mike
https://reperiendi.wordpress.com

[Jonathan Frederickson]

And to expand on the possible failures a bit, it's the smallest number of nodes that can still form a quorum in the event of a network partition.

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAKQgqTYkc0BWVpMFW4nuRPi%2BgePOPy5K5Pgp9F9wBzKMz1-rUw%40mail.gmail.com.

[Alan Karp]

Three reasons.

1. To revoke all delegations from that capability without having to track them individually.
2. To prevent accidental use (a Least Privilege argument).
3. To prevent use in a subsequent hack.

As I recall, Marc Stiegler found this choice useful in our SCoopFS and Everyware work.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK5yZYgJFuQOAFOu38m%2BNL5SM_Rdnv5L4y68ZxstF%3DG-ag6qXg%40mail.gmail.com.

[Alan Karp]

On Thu, May 18, 2023 at 11:15 PM Rob Meijer <pib...@gmail.com> wrote:

Number 3 had me confused at first, untill I realized #3 and others that follow imply "individual" delegation of revocable capabilities (basically one caretaker per object delegated to). While this is a valid and solid (though sometimes complicating) concept, it might help making it explicit.

Although you can implement #3 with object references as capabilities, and Marc Stiegler has, I think it is more natural with certificates as capabilities, where you can tell the server of the designated object not to honor this certificate or any delegations from it.

If the revocable delegation isn't individual, for example when scaling horizontally, the question arises if an instance having the authority to revoke in the name of the service would constitute least authority, and use-only caps will make sense.

I believe it is useful to be able to revoke all delegations from a capability you hold without having to track them individually.  Revoking object references as capabilities could be done by delegating them all through a common caretaker, but that option is less convenient for certificates as capabilities. 

I think in order to make the case against use-only caps, you should probably explicitly make the case for individual delegation of revocable caps.

I don't understand this point. 

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

[Rob Meijer]

Consider that Bob is horizontally scaled, and Bob[0..7] are delegated a revokable capability to Carol by Alice.

Alice could create revocation proxies (caretakers or whatever the certificate equivalent is) that are each individually revocable. In this case giving the "revocation" cap to the Bob instances together "invoke" or "use" cap, it's clear that there is no excess authority there. Individual delegation makes it a good idea to bundle the two caps in delegation.

Alternatively, Alice could just create a single revocation proxy and delegate it to all Bob instances. In this case revocation of the Carol cap by any of the Bob instances would intervene with the operations of all off the other Bob instances. Something that doesn't seem desirable from a least authority perspective. So without individual delegation of revocable caps, delegation by Alice of a use-only (invoke-only, no revoke) cap would make sense.

From this perspective I think that in order to advocate always delegating the revoke cap together with the invoke cap, you should also explicitly advocate individual delegation of revocable cap. So a different delegation proxy for each of the Bob instances.

Hope my point makes a bit more sense now.

Rob

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

--
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/CANpA1Z0JQwokbJuRF5pAL5GvY49xuC7HFUctzNm5w1Jn-0Xm8Q%40mail.gmail.com.

[Alan Karp]

Yes it does.  Thanks for explaining so clearly. 

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

To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAMpet1UO%2BAnoXeFSM5HODV7YaeDL8vTL_xaAPeAp681QoPz-CA%40mail.gmail.com.