Entity vs key based granting of authority

[cwebber]

I'm going to elaborate on this further in the thread, and indeed much conversation on this has recently happened on the cap-talk mailing list. But first a high level summary...

Capability granting/delegating certificates must be signed, so must invoking certificates. What do we grant authority to?

• The traditional ocap lore tends to be that we should link an ocap certificate to a specific key (in fact, it is even better/safer to include the key entirely in the certificate rather than link to it). This prevents ambient authority risks, etc, which is good. And embedding the key very explicitly probably adds a significant degree of safety. But what to do when the key associated with the certificate should be rotated? (Eg, weakening of the cryptographic suite, etc.)
• Another route, which is very DID'ish, is to grant to an entity that has a layer of indirection between it and the actual key. We grant to this entity that has properties for granting/delegating capabilities and invoking them, but the values of these properties can be changed over time. Any of these keys can be used. This has the advantage that we can rotate the key in one place and (in theory) our ocaps will continue to work. (But this might not be true for delegation, as I will explain before.) This might add nontrivial ambient authority problems. It also requires that the entity be able to be "hosted" somewhere, and that the hosting of this entity be reliable and not easily compromised.

[msporny]

Another route, which is very DID'ish, is to grant to an entity that has a layer of indirection between it and the actual key.

I'm not sure that this is the right way to frame this particular item. You can look at it more generally as just another layer of indirection. So, the question becomes "is it okay to use indirection when specifying which keys are allowed?".

I think there is general agreement that embedding and linking to a very specific key is the best. The downsides are, of course, that you can't rotate the key... and if you care about rotating keys, there are two ways to get there: 1) accept indirection as a reasonable compromise, or 2) insist that ocaps should be short lived and rotated when the key is rotated.

[cwebber]

I'm not sure that this is the right way to frame this particular item.

Fair, what I meant to say was that DIDs are actively solving the indirection-for-key-rotation problem, so may be the most interesting approach there... but they are definitely far from exclusive.

[cwebber]

I think there is general agreement that embedding and linking to a very specific key is the best. The downsides are, of course, that you can't rotate the key... and if you care about rotating keys, there are two ways to get there: 1) accept indirection as a reasonable compromise

which probably has the convenience too in that it matches a little bit closer to world expectations about how keys are deployed, despite the other downsides

or 2) insist that ocaps should be short lived and rotated when the key is rotated.

Right, either we're rotating the keys, or rotating the ocaps. @alanhkarp has laid out a way to do the rotation; per my understanding we would have a specific key embedded, and then before that key expires one could submit a request (signed by that specific key) with a type of Reissue or Refresh or etc to exchange that capability (straightforward if to the target itself; if further down the delegation chain, participants will have to cooperate recursively). This requires that participants remember to refresh their ocaps though.

Putting aside whether it's a good idea or not, a question might be: how feasible is it for ocap-ld to support both workflows? I'd like to say that it would be possible to support both but my fear is that we won't be guiding users to implement things consistently, then.

[alanhkarp]

I just want to clarify. You say "to exchange that key." I am proposing getting a new capability issued to the new key, not exchanging it. The word "exchange" has the connotation that the old one is no longer valid. I believe that whether or not to revoke the original capability is a policy decision best left up to the delegator.

I am not a great fan of short-lived capabilities. Recall that OAuth started with 5 minute expirations, quickly went to an hour and then to 24. If there is a timeout policy, just code a daemon to revoke at the appropriate time. The only exception is when the capability is part of a limited-time contract, e.g., "Your ticket to Disneyland is good for 3 days", in which case you have a natural expiration time.

OK. I admit that a timeout can save you if you can't reach the object when you want to revoke, but, as with most heuristics, you'll rarely get it right.

---

Alan Karp

On Thu, Aug 2, 2018 at 12:44 PM Christopher Lemmer Webber < notifications@github.com> wrote:

I think there is general agreement that embedding and linking to a very specific key is the best. The downsides are, of course, that you can't rotate the key... and if you care about rotating keys, there are two ways to get there: 1) accept indirection as a reasonable compromise

which probably has the convenience too in that it matches a little bit closer to world expectations about how keys are deployed, despite the other downsides

or 2) insist that ocaps should be short lived and rotated when the key is rotated.

Right, either we're rotating the keys, or rotating the ocaps. @alanhkarp https://github.com/alanhkarp has laid out a way to do the rotation https://groups.google.com/d/msg/cap-talk/e48rvAc1t9A/R7CpbuEiCgAJ; per my understanding we would have a specific key embedded, and then before that key expires one could submit a request (signed by that specific key) with a type of Reissue or Refresh or etc to exchange that key (straightforward if to the target itself; if further down the delegation chain, participants will have to cooperate recursively). This requires that participants remember to refresh their ocaps though.

Putting aside whether it's a good idea or not, a question might be: how feasible is it for ocap-ld to support both use cases? I'd like to say that it would be possible to support both but my fear is that we won't be guiding users to implement things consistently, then.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c-ccg/ocap-ld/issues/15#issuecomment-410045324, or mute the thread https://github.com/notifications/unsubscribe-auth/AIoJ88ytdgxf6wP_cYdjoRwcx5r8RAFIks5uM1aLgaJpZM4Vs2fH .

[cwebber]

I just want to clarify. You say "to exchange that key." I am proposing getting a new capability issued to the new key, not exchanging it.

Yes that was a typo, oops. I fixed it.

[cwebber]

So there's another reason to consider favoring granting to keys + re-issuing ocap over granting to entities + rotating keys linked to entities, which was discussed on the cap-talk thread, which is the problem of delegation surviving key rotation. The problem goes like this:

Say we have this example from the spec: Car grants authority to Alyssa which grants authority to Ben. But what if Alyssa rotates her key after Ben gets his delegated capability? Alyssa's capability will probably still hold up since the pointer to Alyssa as an entity with indirection is "updated", but the fact that Alyssa signed the key she delegated to Ben means that Ben's probably won't... it had to be signed with a specific key of Alyssa's anyway, one that is no longer valid. So even in the entity case we will probably need the re-issue of the capability workflow... key rotation through an entity supporting indirection does not seem to be enough.

More on this on the cap-talk list here and here.