Revokeability by default

[cwebber]

In the Zebra Copy ocap system, on which ocap-ld is largely based, a revocation could be sent even if there is no caveat/attenuation specifically added to the capability permitting revocation. This is presumably because revocation is so common that it would be added in nearly every case, and because not being able to revoke is going to generally be regrettable in a certificate-based ocap system (I think it's probably fine, in general, in a PL based ocap-system). Presumably this is done by delivering a revocation certificate to the same location where invocations are likewise delivered.

We could add this to ocap-ld... there may be some question about whether this is an application-specific implied caveat or whether we'd want all applications to have this. Perhaps the former is better, since, as said, in general it's likely to be highly desirable in a certificate based ocap system.

[cwebber]

This does possibly add the additional cost of having to store revocations on part of a recipient. However since invocation handlers will presumably also need to keep track of nonces, it's not as if this would be unusual to ask to store another thing.

One question is whether or not one can know when they can discard revocations though. It may be easier if we also had a common property for expiration datetime caveats on capabilities. That comes with the downside of moving two common caveats out of the caveat field, however (both revocation and expiry).

[alanhkarp]

In an ocap language, such as E, it is common to give the same reference to many objects. If any of them revokes, all are revoked. In that situation, you almost certainly want an explicit revoke capability that can be closely held.

The situation is different with a certificate-based system, such as Zebra Copy and ld-caps. Each capability certificate is issued to a different public key, so you're giving out copies. Revoking one only affects that delegation and any delegated from it. Another reason to allow any holder to revoke is for self-protection. Once I revoke a capability you delegated to me, I can't accidentally invoke it, and you can't hold me responsible for subsequent uses.

As far as state management goes, yes, the resource must remember the IDs of revoked capabilities but only until they expire. The ability to explicitly revoke means you can use long expiration times. For example, Alice could set the cert to expire when Ben's lease is up. (I'm a big company guy, so I always relate such decisions to contracts between companies.) Barring any other criterion, the cert can expire after a reasonable lifetime for a private key.

[ghost]

I've discussed this with @nklomp and we see the inability to revoke delegation as a security vulnerability. We understand that capacity can be sent to another id, which can use that capacity forever. What happens if the original id that delegated the capacity no longer wishes for them to act on their behalf?

Looking forward to your thoughts.

[alanhkarp]

If the power to revoke is expressed as a capability, then you can revoke the revoke capability. In some systems I've built, the power to revoke is implicit in the delegation chain. (Anyone on the chain can revoke downstream delegations.) In that case, you can't revoke the revoke capability without revoking the capability the revoke capability has the power to revoke. (Try saying that three times fast.) However, in that case, you can't delegate only the power to revoke.

The ability to revoke is important, but it's absence is not necessarily a security vulnerability. Short lifetimes can be used as a proxy for revocation.

---

Alan Karp

On Wed, May 19, 2021 at 5:07 AM gimly-jack @.***> wrote:

I've discussed this with @nklomp https://github.com/nklomp and we see the inability to revoke delegation as a security vulnerability. We understand that capacity can be sent to another id, which can use that capacity forever. What happens if the original id that delegated the capacity no longer wishes for them to act on their behalf?

Looking forward to your thoughts.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/zcap-ld/issues/9#issuecomment-844039875, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACFAT462TDPYI2QREMZJTI3TOOSZLANCNFSM4FBZBY2Q .