Key History

[jorritspee]

Hi, First of all big thanks for your work so far. DDIP wil surely help speed up solving interop issues.

Paragraph 5.2.1 states "did:web supports key rotation, but not key history". Does this mean it is impossible to verify a signature made a couple of months/keys ago? If so this is quite a problem for real life use cases.

Do you already have ideas on standards for implementing key history? I think people like https://github.com/woutslakhorst and https://github.com/stevenvegt from https://github.com/nuts-foundation and https://github.com/rolandgroen already have some ideas on this. Maybe we could exchange some ideas?

Kind regards, Jorrit

[k00ij]

Hi Jorrit, sorry for the late response (holidays). Very good/valid question. You are right that key (rotation) history is crucial and needed for many real life use cases. We realise that DID:Web (currently) is lacking this functionality, while some other DID methods do support key history. Would be good to further discuss this topic and indeed also look at how for instance NUTS addresses this. @nklomp, @TimoGlastra or any others want to comment on this?

Next Wednesday we are organising a second DDIP meetup. See https://www.meetup.com/ddip-dutch-decentralized-identity-profile/events/294370400/ Are you and/or people from NUTS able to join? If so, we can add this to the agenda. If you can't join next week we can also plan something separate or continue the discussion in here. You can contact me at harmen.vanderkooij@dutchblockchaincoalition.org

[reinkrul]

The challenge with history-less DID methods (i.e. did:web) you can't revoke/deactivate individual keys, without invalidating past signatures. You'd want to do this in case of;

• key rotation, a common security practice of adding a new key and marking the previous one invalid (like expiring API tokens). It's based on the idea that the longer a secret is used, the larger the chance it was leaked at some point, thus you want to have a new secret every X time.
• when a private key got leaked

You could mitigate the impact by;

• Making the issuance/signing process as much automated as possible, to make stolen private keys less disastrous.
• Limit the lifespan of signatures/credentials, so key rotation can occur on a scheduled basis.

[eklaver]

In my opinion if a private key got leaked, all signatures based on that private key should be invalidated. Because it is no longer possible to verify the issuer of the certificate based on that signature.

With did:web it is possible to add another verification key to the DID document. So you can easily rotate the private key without invalidating all existing credentials as long as the old public key is still in the DID document. When a private key got leaked you need to remove the corresponding public key from the DID document. The main problem that remains is that you have to remove the rotated public key at some point. Otherwise the DID document will only grow. You could set an expiration time for rotated public keys. If VC's issued by the DID are only valid for a certain amount of time, this could be your expiration time for rotated public keys.