didcomm-messaging
didcomm-messaging copied to clipboard
decentralized-identity
Be able to encypt the message for multiple target keys of different types
Use case Let's assume Bob have multiple keys of different types. Alice also have multiple keys of different types (let's assume she has keys of same types for simplicity). When Alice sends a message to Bob, it must be encrypted to all (or maximum number) of Bob's keys using multiplex encryption (see discussions in #218).
Problem in DIDComm spec
- For a given Bob's key type Alice can use only a key of the same type for key agreement.
- So, if Alice wants to encrypt the message to multiple Bob's keys of multiple types, she need to use multiple sender keys (one Alice's key per Bob's key type).
- The current DIDComm as well as discussion in #218 assumes that Alice can use only 1 sender KID (skid), and hence can encrypt the message to the keys of one type only (matching the sender's key type)
ECDH-1PU doesn't forbid to use multiple sender keys, and even has the following sentence in ecdh-1pu-04#appendix-B:
Because Bob and Charlie are using the same curve (X25519), Alice reuses the same ephemeral key-pair for both recipients and includes it in the JWE Protected Header. If this was not the case, Alice should generate a separate ephemeral key-pair for each recipient and include it in each per-recipient header instead.
However, ECDH-1PU doesn't provide any other details/examples how multiple sender keys can be used. There is an issue The multiple recipients case is underdefined created in jose-ecdh-1pu repo to add these details to ECDH-1PU spec.
Potential Solution Wait until The multiple recipients case is underdefined is solved, and reflect the decision and sender key choice strategy in the DIDComm spec.
Even though creating 1 epk per recipient as per the standard JWE recipients using ECDH-ES is doable, this doesn't negate the fact that the epk, recipient and sender keys must be on the same curve. This means one cannot do ECDH (kdf) with say recipient key as X25519 and sender key as P-256. In fact some Jose libraries won't even allow ECDH/KDF with the use of keys of different curves/types.
If we want to support multi sender keys <-> multi recipient keys, the only option we have is creating distinct jwe envelopes per set of same curve keys for recipient, sender and epk.
The spec already includes the following text: "It MUST be of the same type and curve as all recipient keys since kdf with the sender key must be on the same curve."
Are other changes needed to reflect the requirement that the recipient and sender keys must be the same?
Discussed WG 20220131. Decided that multiple key types among participants will not be included in v2 of the spec.
When reading through the DIDComm spec I just came across the problem discussed here in this issue as well as in others (#238). I think it's important and should hopefully be resolved rather soon, otherwise DIDComm would break when someone has keys of different types in their DID document's keyAgreement section. Assuming that all keyAgreement keys are of same type is not realistic to me, especially because you also need to consider that other protocols could require users to put keys in the keyAgreement section of their DID document.
Would it work to reference a list of keyAgreement keys in the DIDComm service endpoint section? There, it would be totally ok if DIDComm requires you to only have keys of the same type.
Has there been any progress on resolving the issue in the meantime?
