ADR 0019: Key Manager Policy Improvements #10
Conversation
|
|
||
| Submitting a `PolicyRevokeKey` transaction, will invalidate the signing key | ||
| for the purpose of ratifying key manager policies. Note that revocations | ||
| are expected to take effect the next time various nodes re-attest (the light |
There was a problem hiding this comment.
Probably the enclave should fetch the latest revocation list each time before accepting any policy update (similar to how policy publication is checked) instead of on re-attestation?
Obviously the consensus layer will also enforce the revocation policy before accepting PolicyVotes so verifying publication is implicitly verifying the revocation list.
I guess the question is what happens with existing policies signed by the revoked key? Could they become invalid retroactively? I think this would be bad.
There was a problem hiding this comment.
I was thinking of allowing for revoking existing policies, but in retrospect that probably isn't the best of ideas. I am not entirely convinced that revocation is actually useful either. I would say "Surely people store their keys properly, and we use a large/disjoint enough committee size", but this industry is full of morons like those involved in the Ronin Bridge stupidity, so that's probably not realistic.
|
|
||
| On the consensus side, votes: | ||
| - Must be for an open (not expired) `PolicyProposal` | ||
| - Must be signed by a public key that is part of `Status.BaseSigners` |
There was a problem hiding this comment.
Also the key must not be revoked?
There was a problem hiding this comment.
If we do revocation, yeah. Like I said, I'm not convinced it's worth the complexity.
No description provided.