Did-core: Issue with using `version-id` and key revocation

[oed]

I've discovered a quite severe issue that can occur when you use the version-id (or the version-time) query parameters for DID documents.

Problem

In the example below we use JWS and assume that kid in the header is set to did?version-id<id>#fragment. The same issue is however present if you use other signature systems, and if you use version-time.

Consider the following scenario:

d1 <- t1 <- d2 <- t3
      /           /
Blockchain---------------> time
          \           \
    c1 <- t2 <- c2 <- t4

• t<n> - blockchain timestamp
• d1 - DID document created
• d2 - DID document updated (key revocation)
• c1 - JWS signature with content
• c2 - JWS signature with content

With timestamps from a blockchain we should be able to determine which signatures was made in which order, and thus invalidate any signature that was made by a revoked key. However there is a problem.

Let's assume that

• c1 was signed by did?version-id=t1#key1
• c2 was also signed with did?version-id=t1#key1

Here c1 should be a valid signature when we combine it with the information from t2. However, c2 should not be valid when combined with t4 because the key #key1 was revoked at t3. This is problematic because we don't get any information about when the DID document was updated when resolving it. The only information we get about updates are from the DID Document Metadata, but only includes created and updated. In this case this information is irrelevant.

Mitigation

A possible solution would be to introduce some new properties to the DID Document Metadata:

• version-id - the version id of the document that was resolved
• version-time - the time the document version that was resolved
• next-version-id - the version-id of the next update of the document
• next-version-time - the version-time of the next update to the document.

Adding these properties would allow us to pinpoint when in time a particular version-id of a document was valid and thus we would be able to invalidate update c2 from our example above.

---

Happy to hear other thoughts and possible solutions!

cc @OR13 @awoie @kdenhartog

[peacekeeper]

@oed interesting, thanks for bringing this up and for the very good explanation and diagram!

If I understand correctly, the Issuer of c2 is malicious, because they signed with a key that wasn't in their DID document anymore at the time c2 was issued. Couldn't this be detected by a Verifier by dereferencing did?version-id=t4#key1 instead of did?version-id=t1#key1, since the Verifier must know that c2 was issued at t4, not t1 ?

Nevertheless, I agree additional DID document metadata can help to make this more secure.

A possible solution would be to introduce some new properties to the DID Document Metadata:

version-id - the version id of the document that was resolved

I think we can add this as an additional DID document metadata property. We already had this idea in item 1 of https://github.com/w3c-ccg/did-resolution/issues/12, but haven't defined anything.

version-time - the time the document version that was resolved

I think this is unnecessary since you can already get this information from the created and updated DID document metadata properties. What extra value would this one add?

next-version-id - the version-id of the next update of the document

+1 I think we can add this.

next-version-time - the version-time of the next update to the document.

+1 I think we can add this, but I would probably call it next-update, to be more aligned with the existing update.

Final note.. We would potentially add additional properties in the DID Resolution spec rather than DID Core (which is in feature freeze now).

[oed]

Thanks for your reply @peacekeeper.

If I understand correctly, the Issuer of c2 is malicious, because they signed with a key that wasn't in their DID document anymore at the time c2 was issued.

Yep, that's exactly right.

Couldn't this be detected by a Verifier by dereferencing did?version-id=t4#key1 instead of did?version-id=t1#key1, since the Verifier must know that c2 was issued at t4, not t1 ?

Well in the example the JWS contains the kid -> did?version-id=t1#key1. There isn't necessarily a way to know what the next version-id is, thus there is a need to have additional information in the DID document metadata.

I think this is unnecessary since you can already get this information from the created and updated DID document metadata properties. What extra value would this one add?

As I understand it created tells you when the DID document was first created and updated tells you when the document had its most recent update. version-time would tell you when the resolved update was created.

but I would probably call it next-update, to be more aligned with the existing update.

Fine by me.

Final note.. We would potentially add additional properties in the DID Resolution spec rather than DID Core (which is in feature freeze now).

Happy to add this there as well. Seems still relevant to add this as a security fix to DID Core?

[OR13]

+1 for better did document metadata for versions

[peacekeeper]

As I understand it created tells you when the DID document was first created and updated tells you when the document had its most recent update. version-time would tell you when the resolved update was created.

The updated DID document metadata property tells you when the resolved DID document was last updated, not when the DID itself hat its most recent update, at least this has always been my understanding. So I think this is what you want. We could probably do a better job explaining this in the spec and adding some examples...

[oed]

Great if that's the case @peacekeeper! I was just readong 8.1.3.2 updated which says:

DID document metadata SHOULD include an updated property to indicate the timestamp of the last Update operation.

So new suggestion is to add these properties to the DID Document Metadata:

• version-id - the version id of the document that was resolved
• next-version-id - the version-id of the next update of the document
• next-update - the time of the next update to the document

[awoie]

+1 (as well) for better did document metadata for versions or better wording

[oed]

It might also make sense to include the following two properties:

• hl - hash link of the resolved document
• next-hl - the hash link of the next update of the document

Just like version-id, hl is a url param used to resolve a specific version of a document.

[msporny]

PR #508 has been merged. Closing.