Split up rotation, revocation and recovery

[OR13]

This PR attempts to address the mega thread on #386

---

Preview | Diff

[dhh1128]

I cannot sign off on a characterization of revocation as undoing the past. Revocation means stopping the use of something in the future, and cannot be used to repudiate past actions.

It is FINE for DID methods to not support revocation. It is not FINE for us to define out of existence a feature that's important for some of them.

[dhh1128]

We don't constrain an id to always point to an item of the same type, let along the same verification method. That is, #key1 could be a service endpoint in one version of a DID doc, a signing key in another version, and an encryption key in another version. What you mean here, I think, is that we change only the value of a key, but none of its associated semantics/role/purpose.

[dlongley]

Yeah, I'm not a fan of this approach either -- and it's not really what I consider "rotation" either. Rather, I'd expect rotation to involve adding new verification methods to the DID Document without removing existing ones (and thus, their proofs continue to be valid). Internally/privately, the private key material/access to it is changed such that it is either made inactive or destroyed (but this is the private aspect of rotation, having nothing to do with the DID Document). I don't think we should encourage swapping key materials while keeping IDs the same -- I think that's a recipe for confusion.

[OR13]

I agree with both your comments, perhaps I should remove this section on rotation... its telling that the word "rotation" does not appear once here: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html

[OR13]

However what I wrote is in line with

• https://developer.okta.com/docs/concepts/key-rotation/
• https://dltlabs.medium.com/a-closer-look-at-key-rotation-policies-oidc-297361a9e3a7

[dhh1128]

I don't agree that key rotation invalidates old verifications. That is not the case with passwords or SSH keys; why should we claim it is true of DID keys? You are wanting to use verification methods to produce ephemeral tokens and are claiming that is a general property of the entire DID ecosystem. I disagree.

[OR13]

removing an ssh key or a jwk from the associated collection does cause a verifier to reject them... perhaps you can propose some alternate language that applies equally to SSH / GPG / OIDC?

GitHub will not accept commits from "rotated" ssh keys.

[dhh1128]

I could possibly live with the following rewording:

Cryptographic verifications associated with a revoked verification method are not valid. However, knowing whether a verification was made with a revoked verification method is trickier than it may seem.

Some DID methods provide the ability to look back at the state of a DID at a point in time, or at a particular version of the DID document. When such a feature is combined with a reliable way to determin the time or DID version that existed when a cryptographically verifiable statement was made, then revocation does not undo that statement. This can be the basis for using DIDs to make binding commitments (e.g., to sign a mortgage). If these conditions are met, revocation is not retroactive; it only nullifies future use of the method.

But in order for such semantics to be safe, the second condition -- an ability to know what the state of the DID document was at the time the assertion was made -- MUST apply. Without that guarantee, someone could discover a revoked key and use it to make cryptographically verifiable statements with a simulated date in the past.

Some DID methods only allow the retrieval of the current state of a DID. When this is true, or when the state of a DID at the time of cryptographically verifiable statement cannot be reliably determined, then the only safe interpretation of revocation is to make it apply both forward and backward in time. DID ecosystems that take this approach essentially provide cryptographically verifiable statements as ephemeral tokens that can be invalidated at any time by the DID controller.

[dlongley]

@dhh1128, I agree with your reword. I think it's a little strange to talk about the "state of a DID" (which is just an identifier), so we should perhaps instead talk about DID Documents or resolution. That's just an editorial quibble though. A slightly more important suggestion, I think, would be such that we don't so strongly state that if a DID method only allows retrieval of the current state of a DID that there are no alternative solutions to preventing undesirable "retroactive revocation". We shouldn't be so prescriptive -- instead of saying:

Some DID methods only allow the retrieval of the current state of a DID.

We can say:

In some cases, it may only be possible to obtain a current DID Document.

That way, future clever solutions that layer on top of DID methods that do not support versioning directly are not needlessly discouraged.

[dhh1128]

Good point about "state of a DID." I once poked a colleague about that very error, so I'm being inconsistent to get sloppy now. :-)

I agree that the rewording you suggested improves the text.

[OR13]

I don't believe the proposed language is an improvement.

However, I hope I have captured its spirit in my latest change set, by stating that revocation and rotation only apply to the latest version of a did document.... and clarifying how revoked material is commonly treated by other software systems.

[dhh1128]

I suggest removing this paragraph in favor of the wording I provided in a previous comment.

[OR13]

I have made changes attempting to address your concern with this paragraph.

[OR13]

@dhh1128 thanks for your comments, I intend to address them, I am hoping to see more comments from others before a try (hopefully this weekend).... one area of concern I have is aligning 'revocation' in did core, with TLS and PGP revocation... because if we do things differently I worry we may make things more confusing (its possible my PR is making this worse).

• https://www.digicert.com/kb/util/utility-test-ocsp-and-crl-access-from-a-server.htm
• http://www.spywarewarrior.com/uiuc/ss/revoke/pgp-revoke.htm

^ these are from google, I would welcome better links to add to did core for informative references.

As I understand TLS and PGP, revocation destroys verification. I think you have said you don't want that to be true of DIDs... This is the primary issue we need to address in this PR.

Perhaps we should use Solar Winds as an example:

https://www.solarwinds.com/trust-center/new-digital-certificate

As part of our response to the SUNBURST vulnerability, the code-signing certificate used by SolarWinds to sign the affected software versions will be revoked on March 8, 2021. This is industry-standard best practice for software that has been compromised.

Regretfully, the same digital code-signing certificate used to sign our Orion Platform software affected by the SUNBURST vulnerability was also used to sign additional SolarWinds products not known to be affected by SUNBURST. While this does not mean all products are compromised, it does mean the day-to-day operation of any software signed by the compromised digital code-signing certificate may be impacted by a user’s operating system, antivirus, or endpoint protection software when the certificate is publicly revoked on March 8, 2021.

[OR13]

since I am. not a git wizard, and this branch has git issued beyond my skill I will be reimplementing it.

[OR13]

Originally this branch was meant to replace:

 <section>
      <h2>
Key Revocation and Recovery
      </h2>

      <p>
It is up to <a>DID methods</a> to define how revocation of cryptographic keys
might occur. <a>DID method</a> specifications are also expected
to enable support for a quorum of trusted parties to enable key recovery. Some
of the facilities to do so are suggested in Section
<a href="#did-controller"></a>. Not all <a>DID method</a>
specifications will recognize control from <a>DIDs</a> registered using other
<a>DID methods</a> and they might restrict third-party control to <a>DIDs</a>
that use the same method. Access control and key recovery in a
<a>DID method</a> specification can also include a time lock feature to
protect against key compromise by maintaining a second track of control for
recovery.
</p>
    </section>

with:

 <section>
      <h2>Verification Method Rotation</h2>
  
      <p>Verification method rotation is a proactive security measure.</p>
  
      <p>
        Verification method rotation applies only to the current or latest
        verison of a DID Document.
      </p>
  
      <p>
        When a verification method has been active for a long time, or used
        for many operations, a controller might wish to perform a rotation.
      </p>
  
      <p class="advisement">
        It is considered a best practice to perform verification method
        rotation on a regular basis.
      </p>

      <p class="advisement">
        Proofs or signatures that rely on verification methods that are not
        present in the latest version of a DID Document are not impacted by
        rotation, and may require additional information to mitigate compromise.
      </p>
  
      <p>
        Section <a href="#method-operations"></a> specifies the
        <a>DID</a> operations to be supported by a
        <a>DID method</a> specification, including
        <a href="#update">update</a>
        which MUST be used to perform a verification method rotation.
      </p>
  
      <p>
        A controller performs a rotation when they add a new verification
        method that is meant to replace an existing verification method after
        some time.
      </p>
  
      <p>Not all DID Methods support verification method rotation.</p>
  
      <p>
        Unlike revocation, rotation allows for new verifications associated
        with the <code>id</code>, to be valid, while invalidating older
        verifications once the older verification method is removed.
      </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 compromised verification method
        to an attacker.
      </p>
  
      <p class="note">
        Higher security environments tend to employ more frequent verification
        method rotation.
      </p>
  
      <p class="note">
        Frequent rotation of a verification method might be frustrating for
        parties that are forced to continiously renew or refresh associated
        credentials.
      </p>
    </section>
  
    <section>
      <h2>Verification Method Revocation</h2>
  
      <p>Verification method revocation is a reactive security measure.</p>

      <p>
        Verification method revocation applies only to the current or latest
        verison of a DID Document.
      </p>
  
      <p>
        If a verification method is no longer exclusivley accessible to the
        controller or parties trusted to act on behalf of the controller, it
        should be revoked immediatly to reduce the risk of masquerading, theft
        and fraud.
      </p>
  
      <p class="advisement">
        It is considered a best practice to support key revocation.
      </p>
  
      <p class="advisement">
        A controller should revoke any verification method that is believed to
        be compromised immediatly.
      </p>
  
      <p class="advisement">
        Cryptographic verifications associated with revoked verification
        methods should be considered invalid regardless of when revocation
        occurs.
      </p>
  
      <p class="note">
        As described in Section <a href="#verification-method-types"></a>,
        absence of a verification method is the only form of revocation that
        applies to all DID Methods.
      </p>
  
      <p>
        Section <a href="#method-operations"></a> specifies the
        <a>DID</a> operations to be supported by a
        <a>DID method</a> specification, including
        <a href="#update">update</a> and <a href="#deactivate">deactivate</a>
        which MAY be used to remove verification method from a DID Document.
      </p>

      <p>Not all DID Methods support verification method revocation.</p>
  
      <p>
        Even if a verification method is present in a DID Document, additional
        information such as a public key revocation certificate, or external
        allow or deny list might be used to determine if a verification method
        has been revoked.
      </p>
  
      <p class="note">
        Compromise of a verification method allows the attacker access to the verification 
        relationship of the controller, for example authentication.
        The attacker is indistinguishable from the legitimate controller from the 
        time the compromised verification method was registered, to the time it was revoked.
      </p>

      <p class="note">
        The day-to-day operation of any software relying on a compromised verification method 
        might be impacted by a user’s operating system, antivirus, or endpoint protection software 
        when the verification method is publicly revoked.
      </p>

    </section>
  
    <section>
      <h2>DID Recovery</h2>
  
      <p>
        Recovery is a reactive security measure, whereby a controller is able
        to regain the ability to perform DID operations.
      </p>
  
      <p class="advisement">
        Recovery is advised when a controller or services trusted to act on
        their behalf no longer has the exclusive ability to perform DID
        operations as described in <a href="#method-operations"></a>.
      </p>
  
      <p class="advisement">
        It is considered a best practice to never reuse a verification method
        or key material associated with recovery for any other purposes.
      </p>
  
      <p>
        Recovery is commonly performed in conjunction with
        <a href="#verification-method-rotation"
          >verification method rotation</a
        >
        and
        <a href="#verification-method-revocation"
          >verification method revocation</a
        >.
      </p>
  
      <p>
        There are no common recovery mechanisms that apply to all DID Methods.
      </p>
  
      <p>
        <a>DID method</a> specifications might choose to enable support for a
        quorum of trusted parties to faciliate recovery. Some of the
        facilities to do so are suggested in Section
        <a href="#did-controller"></a>.
      </p>
  
      <p>
        Not all <a>DID method</a> specifications will recognize control from
        <a>DIDs</a> registered using other <a>DID methods</a> and they might
        restrict third-party control to <a>DIDs</a> that use the same method.
      </p>
  
      <p>
        Access control and recovery in a <a>DID method</a>
        specification can also include a time lock feature to protect against
        key compromise by maintaining a second track of control for recovery.
      </p>
  
      <p class="note">
        Performing recovery proactively on an infrequent but regular basis,
        can help to ensure that control has not been lost.
      </p>
    </section>