Update Verification Method Rotation section. #741
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -4596,78 +4596,80 @@ <h2>Key and Signature Expiration</h2> | |
| </section> | ||
|
|
||
| <section> | ||
| <h2>Verification Method Rotation</h2> | ||
|
|
||
| <p> | ||
| Rotation is a management process that enables the secret cryptographic material | ||
| associated with an existing <a>verification method</a> to be deactivated or | ||
| destroyed once a new <a>verification method</a> has been added to the <a>DID | ||
| document</a>. Going forward, any new proofs that a <a>controller</a> would have | ||
| generated using the old secret cryptographic material can now instead be | ||
| generated using the new cryptographic material and can be verified using the | ||
| new <a>verification method</a>. | ||
| </p> | ||
|
|
||
| <p> | ||
| Rotation is a useful mechanism for protecting against verification method | ||
| compromise, since frequent rotation of a verification method by the controller | ||
| reduces the value of a single compromised verification method to an attacker. | ||
| Performing revocation immediately after rotation is useful for verification | ||
| methods that a controller designates for short-lived verifications, such as | ||
| those involved in encrypting messages and authentication. | ||
| </p> | ||
|
|
||
| <p> | ||
| The following considerations might be of use when contemplating the use of | ||
| <a>verification method</a> rotation: | ||
| </p> | ||
|
|
||
| <ul> | ||
| <li> | ||
| <a>Verification method</a> rotation is a proactive security measure. | ||
| </li> | ||
| <li> | ||
| It is generally considered a best practice to perform <a>verification method</a> rotation | ||
| on a regular basis. | ||
| </li> | ||
| <li> | ||
| Higher security environments tend to employ more frequent verification method | ||
| rotation. | ||
| </li> | ||
| <li> | ||
| <a>Verification method</a> rotation manifests only as changes to the current or latest | ||
| version of a <a>DID document</a>. | ||
| </li> | ||
| <li> | ||
| When a <a>verification method</a> has been active for a long time, or used for | ||
| many operations, a controller might wish to perform a rotation. | ||
| </li> | ||
| <li> | ||
| Frequent rotation of a <a>verification method</a> might be frustrating for | ||
| parties that are forced to continuously renew or refresh associated credentials. | ||
| </li> | ||
| <li> | ||
| Proofs or signatures that rely on <a>verification methods</a> that are not | ||
| present in the latest version of a <a>DID document</a> are not impacted by | ||
| rotation. In these cases, verification software might require additional | ||
| information, such as when a particular <a>verification method</a> was | ||
| expected to be valid as well as access to a <a>verifiable data registry</a> | ||
| containing a historical record, to determine the validity of the proof or | ||
| signature. This option might not be available in all <a>DID methods</a>. | ||
| </li> | ||
| <li> | ||
| The section on <a href="#method-operations">DID method operations</a> specifies | ||
| the <a>DID</a> operations to be supported by a <a>DID method</a> specification, | ||
| including <a href="#method-operations">update</a> which is expected to be used | ||
| to perform a <a>verification method</a> rotation. | ||
| </li> | ||
| <li> | ||
| A <a>controller</a> performs a rotation when they add a new <a>verification | ||
| method</a> that is meant to replace an existing <a>verification method</a> after | ||
| some time. | ||
|
There was a problem hiding this comment. Is rotation meant to communicate an intention to replace exactly at the moment of the rotation -- or at some indefinite point in the future? If the former interpretation is canonical, then isn't revocation of the old method automatic? If the latter, then how is the future moment determined -- when a separate revocation step is taken on the old method? There was a problem hiding this comment. My expectation is that it's "at some indefinite point in the future"... which might be within microseconds of each other. The process, as I understand it might be:
So, it can't be considered automatic all of the time (but perhaps, sometimes). Yes, the future moment could be thought of as when the old key is revoked. @dhh1128 please take a shot at some concrete spec text, or @OR13 if you have any suggestions here, that would be great. We need that text before I can merge. There was a problem hiding this comment. If I understand correctly, under the definition you're advocating here, the only difference between "inserting" a new key and "rotating" a key is intention; there is no observable difference in DID doc state when the two operations complete. That is, only step 1 in your process is "rotation"; step 2 is "revocation" -- right? This feels weird to me. I thought "rotation" was the combination of adding a new key and removing an old one, as an atomic operation. There was a problem hiding this comment. The reason I'm not suggesting spec text here is because I think the definition is either confused or fundamentally wrong. If rotation is defined to mean "insert a key with the intention to revoke its older counterpart" -- but the actual revoking isn't part of rotation, only a difference of intention, then most of the benefits of "rotation" vanish, since it is the fulfilled intention of revocation, not the initial intention of rotating, that decreases the attack surface. If, on the other hand, we define rotation to mean "insert a key AND revoke its older counterpart", then saying the revocation is separable makes no sense, and most of the security benefits should appear in the revocation section, with only a note here about how rotation picks up those benefits since it includes revocation. The introductory text "Rotation...enables the secret cryptographic material associated with an existing verification method to be deactivated or destroyed once a new verification method has been added to the DIDdocument" is trying to combine the semantics of the insertion and the revocation. This seems at odds with "it can't be considered automatic all of the time." There was a problem hiding this comment. I don't have strong opinions wrt. this PR. I was merely cleaning up text that was already there when I stepped on this landmine. I believe other people submitted this text initially and I would like them to work through the details here. I remember it being @dhh1128 and @OR13 working on the initial PR here, but can't remember exactly. I don't necessarily care about the outcome here as long as it's consistent. I do think @dhh1128 is raising good points, so I expect that anything that makes it in would address those concerns. To avoid a "too many cooks in the kitchen" scenario, I'm recusing myself from providing input. If it helps, I can try to hunt down who initially worked on and refined this section of the specification. There was a problem hiding this comment. Did a quick lookup to save you the time @msporny The original text was merged via PR #569 with an alternative originally proposed by @OR13 in #548 which was ultimately closed in favor of #569. This was originally intended to address issue #386 It looks like @dhh1128 and @OR13 were able to come to agreement after some back and forth on the editing of this. Hopefully the discussion between those two will provide some additional context on what allowed the current text to be satisfying to all parties at that time. |
||
| </li> | ||
| <li> | ||
| Not all <a>DID methods</a> support <a>verification method</a> rotation. | ||
| </li> | ||
| </ul> | ||
| </section> | ||
|
|
||
| <section> | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels at odds with verbiage in the revised revocation section, which says that omitting a verification method from a DID doc is the only universally supported method of revoking something. How do we square the two statements?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see how it's at odds. It feels aligned. Can you provide some concrete specification text that we could change this to?
Any suggestions @OR13, since it's your language, IIRC?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I'm trying to point out here is that "verification methods that are not present in the latest version of a DID document" are required, in the revocation section, to be interpreted as revoked methods (if they ever existed at all). Thus, this sentence could be reworded to "Verification methods that are already revoked cannot be rotated."