[proposal] compute X25519 encryption keys automatically for Ed25519 key entries

Is your feature request related to a problem? Please describe. Ed25519/X25519 keys have a special relationship, where the public X25519 key usable for keyAgreement can be computed from the public Ed25519 key usable for signing. did:key already uses this relationship to express X25519 keyAgreement relationships automatically from Ed25519 keys.

Describe the solution you’d like When a Ed25519 signing key is added to one of the “signing” verification relationships, or to the verificationMethod array the resolver should automatically add a derived X25519 key to the verificationMethods and reference it under the keyAgreement relationship.

Describe alternatives you’ve considered The alternative is to manually compute the X25519 key and add it using a new transaction, but any new transaction implies additional gas costs.

Additional context

• did:key example
• On using the same key pair for Ed25519 and an X25519 based KEM
• conversion implementation using libsodium

[mirceanis]

I like the implicit keyAgreement entry based on an already existing Ed25519 key. Would there be a way to remove this implicit key? Could you target a revokeAttribute at this to make the resolver ignore it/ not do the derivation?

Good point, I was also trying to figure that out, and I suppose that could be done. But I don’t really see the benefit in revoking only the derived encryption key. This paper says it should be safe to use the derived encryption key, and since that key can’t be used for signing, it doesn’t grant anyone extra power, except if they were able to intercept messages encrypted to that key as well, but to do that they’d need the private key. And if the private Ed25519 key is compromised, then it doesn’t make sense to keep that one and revoke the X25519.

Am I missing something?

[mirceanis]

This is also coming out oulf our didcomm experiments 😃

If the user rotates the Ed25519 key, the X25519 derived key would be rotated too.