Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update Verification Method Revocation section. #742

Merged
merged 2 commits into from
May 29, 2021
Merged

Update Verification Method Revocation section. #742

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
39c64dc
Update Verification Method Revocation section.
msporny May 16, 2021
365e0b3
Apply suggestions to Verification Method Revocation section.
msporny May 29, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
242 changes: 135 additions & 107 deletions index.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4671,140 +4671,168 @@ <h2>Verification Method Rotation</h2>
</section>

<section>

<h2>Verification Method Revocation</h2>

<p>
Verification method revocation is a reactive security measure.
Revocation is a management process that enables the secret cryptographic
material associated with an existing <a>verification method</a> to be
deactivated such that it ceases to be a valid form of creating new
proofs of digital signatures.
</p>
<p>
Revocation is a useful mechanism for reacting to a verification method
compromise. 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>
Verification method revocation applies only to the current or latest
version of a DID Document.
Compromise of the secrets associated with a <a>verification method</a> allows
the attacker to use them according to the <a>verification relationship</a>
expressed by <a>controller</a> in the <a>DID document</a>, for example, for
authentication. The attacker's use of the secrets might be indistinguishable
from the legitimate <a href="#did-controller">controller's</a> use starting from the
time the <a>verification method</a> was registered, to the time it was revoked.
</p>


<p>
If a verification method is no longer exclusively accessible to the
controller or parties trusted to act on behalf of the controller, it
is expected to be revoked immediately to reduce the risk of masquerading, theft,
and fraud.
The following considerations might be of use when contemplating the use of
<a>verification method</a> revocation:
</p>

<p class="advisement">
<ul>
<li>
<a>Verification method</a> revocation is a reactive security measure.
</li>

<li>
It is considered a best practice to support key revocation.
</p>
</li>

<p class="advisement">
A controller is expected to immediately revoke any verification method that is believed to
be compromised.
</p>
<li>
A <a>controller</a> is expected to immediately revoke any <a>verification
method</a> that is believed to be compromised.
msporny marked this conversation as resolved.
Show resolved Hide resolved
</li>

<p class="advisement">
Revocation is expected to be understood as a controller expressing
that proofs or signatures associated with a revoked verification method
might have been created by an attacker. Verifiers, however, might
still choose to accept or reject such proofs or signatures at their
own discretion.
</p>
<li>
<a>Verification method</a> revocation applies only to the latest version of a
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe I understand the intent of this sentence, and agree 100% with it. However, I think this sentence is very hard to parse, because of ambiguity in the phrase "applies only to the latest version." I suggest this be reworded to something along the lines of "Verification method revocation can only be embodied in changes to the latest version of a DID document; it cannot retroactively adjust previous versions."

<a>DID Document</a>.
msporny marked this conversation as resolved.
Show resolved Hide resolved
</li>

<p class="note">
As described in <a href="#verification-material"></a>,
absence of a verification method is the only form of revocation that
applies to all DID Methods.
</p>
<li>
As described in <a href="#verification-material"></a>, absence of a verification
method is the only form of revocation that applies to all DID Methods.
msporny marked this conversation as resolved.
Show resolved Hide resolved
</li>

<p>
<a href="#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> and <a href="#method-operations">
deactivate</a> which might be used to remove verification method from a DID
Document.
</p>
<li>
If a <a>verification method</a> is no longer exclusively accessible to the
<a>controller</a> or parties trusted to act on behalf of the <a>controller</a>,
it is expected to be revoked immediately to reduce the risk of
compromises such as masquerading, theft, and fraud.
</li>

<p>
Not all DID Methods support verification method revocation.
</p>
<li>
Revocation is expected to be understood as a <a>controller</a> expressing that
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree with this summary of the semantics of revocation. Previous text in this same section says that revocation can take place immediately after a key rotation to prevent the rotated key from a future compromise. This is at odds with the sentence here, which claims that revocation is understood as communicating doubt about the current security of the method.

Revocation does not always imply a belief that existing proofs or signatures might have been created by an attacker. Rather, it always implies an intention that future proofs or signatures shall not be creatable by an attacker, and it may or may not also imply a concern that existing proofs or signatures are suspect.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was dealt with by a set of changes that @dlongley put forward, which were then agreed to by @dhh1128 and then merged.

proofs or signatures associated with a revoked <a>verification method</a> might
have been created by an attacker. Verifiers, however, might still choose to
accept or reject such proofs or signatures at their own discretion.
msporny marked this conversation as resolved.
Show resolved Hide resolved
</li>

<p>
Even if a verification method is present in a DID Document, additional
information, such as a public key revocation certificate, or an external
allow or deny list, might be used to determine whether a verification
method has been revoked.
</p>
<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> and <a
href="#method-operations"> deactivate</a>, which might be used to remove
msporny marked this conversation as resolved.
Show resolved Hide resolved
<a>verification method</a> from a <a>DID document</a>.
msporny marked this conversation as resolved.
Show resolved Hide resolved
</li>

<p class="note">
Compromise of the secrets associated with a verification method
allows the attacker to use them according to the verification
relationship expressed by controller in the DID Document, for
example, for authentication. The attacker's use of the secrets might
be indistinguishable from the legitimate controller's use starting
from the time the verification method was registered, to the time it
was revoked.
</p>
<li>
Not all <a>DID methods</a> support <a>verification method</a> revocation.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is at odds with the sentence that says that all DID methods support removing a method from a DID document as a form of revocation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suggested a few words to remedy this above.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the suggestion.

</li>

<p class="note">
The day-to-day operation of any software relying on a compromised verification
method, such as an individual's operating system, antivirus, or endpoint protection
software, might be impacted when the verification method is publicly revoked.
</p>
<li>
Even if a <a>verification method</a> is present in a <a>DID document</a>,
additional information, such as a public key revocation certificate, or an
external allow or deny list, could be used to determine whether a
<a>verification method</a> has been revoked.
</li>

<p class="note">
Although verifiers might choose not to accept proofs or signatures from a revoked verification method,
knowing whether a verification was made with a revoked verification method is trickier than it might 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 determine 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).
<br><br>
If these conditions are met, revocation is not retroactive; it only nullifies future use of the method.
<br/><br/>
However, in order for such semantics to be safe, the second condition &mdash;
an ability to know what the state of the DID document was at the time the
<li>
The day-to-day operation of any software relying on a compromised
<a>verification method</a>, such as an individual's operating system, antivirus,
or endpoint protection software, could be impacted when the <a>verification
method</a> is publicly revoked.
</li>

<section class="notoc">
<h3>Revocation Semantics</h3>

<p>
Although verifiers might choose not to accept proofs or signatures from a
revoked verification method, knowing whether a verification was made with a
revoked <a>verification method</a> is trickier than it might seem. Some <a>DID
msporny marked this conversation as resolved.
Show resolved Hide resolved
methods</a> provide the ability to look back at the state of a <a>DID</a> at a
point in time, or at a particular version of the <a>DID document</a>. When such
a feature is combined with a reliable way to determine the time or <a>DID</a>
version that existed when a cryptographically verifiable statement was made,
then revocation does not undo that statement. This can be the basis for using
<a>DIDs</a> to make binding commitments; for example, to sign a mortgage.
</p>
<p>
If these conditions are met, revocation is not retroactive; it only nullifies
future use of the method.
</p>
<p>
However, in order for such semantics to be safe, the second condition &mdash; an
ability to know what the state of the <a>DID document</a> was at the time the
assertion was made &mdash; is expected to 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.
<br/><br/>
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.
</p>
</section>
could discover a revoked key and use it to make cryptographically verifiable
statements with a simulated date in the past.
</p>
<p>
Some <a>DID methods</a> only allow the retrieval of the current state of a
<a>DID</a>. When this is true, or when the state of a <a>DID</a> 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
Copy link
Contributor

@dhh1128 dhh1128 May 18, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree with the phrase "only safe interpretation" -- because it implies that retroactive cancellation is safe. It isn't. Just like unwise use of revocation when the two constraining safety conditions (knowing when the cryptographic statement was made, and knowing what the state of the DID doc at that instant were) rewrites history, interpreting revocation to apply backward in time ALSO REWRITES HISTORY; the difference is that it rewrites that history to maximize protections for the controller instead of rewriting it to maximize protections for the recipients of cryptographically signed assertions. Either way, there's still a winner and a loser -- a protected party and a party treated cavalierly.

I do agree (strongly) with the third sentence, "DID ecosystems that take this approach..." What I would suggest as a revision would be to say, "When this is true, or when the state of a DID at the time of a cryptographically verifiable statement cannot be reliably determined, then the only safe course is to disallow any consideration DID state with respect to time, except the present moment. DID ecosystems that take this approach..."

What I am trying to do with this revision is to remove the phrase "apply both forward and backward in time" in its link to safety -- because I think describing it that way is problematic.

backward in time. <a>DID</a> ecosystems that take this approach essentially
provide cryptographically verifiable statements as ephemeral tokens that can be
invalidated at any time by the <a>DID controller</a>.
msporny marked this conversation as resolved.
Show resolved Hide resolved
</p>
</section>

<section class="notoc">
<h3>Revocation in Trustless Systems</h3>

<div class="note">
<p>
<p>
Trustless systems are those where all trust is derived from cryptographically
provable assertions, and more specifically, where no metadata outside of the
cryptographic system is factored into the determination of trust in the system.
To verify a signature of proof for a verification method which has been revoked
in a trustless system, a DID method needs to support either or both of the
`versionId` or `versionTime`, as well as both the `updated` and `nextUpdate`,
DID document metadata properties. A verifier can validate a signature or proof
of a revoked key if and only if all of the following are true:
</p>
<ul>
<li>
The proof or signature includes the `versionId` or `versionTime` of the DID
document that was used at the point the signature or proof was created.
</li>
<li>
The verifier can determine the point in time at which the signature or proof
was made, e.g., it was anchored on a blockchain.
</li>
<li>
For the resolved DID document metadata, the `updated` timestamp is before, and
the `nextUpdate` timestamp is after, the point in time at which the signature or
proof was made.
</li>
</ul>
</div>
To verify a signature of proof for a <a>verification method</a> which has been
revoked in a trustless system, a <a>DID method</a> needs to support either or
both of the `versionId` or `versionTime`, as well as both the `updated` and
`nextUpdate`, <a>DID document</a> metadata properties. A verifier can validate a
signature or proof of a revoked key if and only if all of the following are
true:
</p>

<ul>
<li>
The proof or signature includes the `versionId` or `versionTime` of the <a>DID
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with this content in its narrow sense, but I don't like how it gives the impression (by focusing only on trustless systems) that the only way to achieve trust is to provide all these properties as part of the cryptographic inputs. The date that a mortgage was signed may not be part of the cryptographic inputs to a verifiable statement, and yet it may be possible to achieve full trust, by deciding that metadata about the event from some other source (e.g., banking records, independent witnesses) is also reliable. In fact, this is likely to happen in a courtroom in many scenarios: metadata from many sources will be evaluated and accepted/rejected.

My suggestion is to add an extra paragraph right after the </ul> that says something like: "In systems that are willing to admit metadata other than those constituting cryptographic input, similar trust may be achieved -- but always on the same basis (making a careful judgment about whether a DID document's content at the moment of a signing event authorized the verification method)."

Copy link
Member Author

@msporny msporny May 29, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a minor variation of your language to the specification here: https://github.com/w3c/did-core/pull/742/files#diff-0eb547304658805aad788d320f10bf1f292797b5e6d745a3bf617584da017051R4839

document</a> that was used at the point the signature or proof was created.
</li>
<li>
The verifier can determine the point in time at which the signature or proof was
made; for example, it was anchored on a blockchain.
</li>
<li>
For the resolved <a>DID document</a> metadata, the `updated` timestamp is
before, and the `nextUpdate` timestamp is after, the point in time at which the
signature or proof was made.
</li>
</ul>
</section>
msporny marked this conversation as resolved.
Show resolved Hide resolved
</section>

<section>
<h2>DID Recovery</h2>
Expand Down