Multiple keys of different types and Keys negotiation

[ashcherbakov]

Use Case

Consider the following situation:

• Alice has multiple keyAgreement keys of different types (X25519, P-256, P-384, etc.) in her DID DOC, possibly including some types (curves) that are not supported by DID Comm (Supported curves and algorithms).
• Alice has multiple keys (keyAgreement entries) on her devices, so this is not always 1 to 1 relationship between a device and a key.
• The same situation for receivers (Bob and Carol): multiple keyAgreement keys of different types; multiple keys per device.

Now Alice wants to encrypt a message for Bob (and possibly Carol).

DID Comm spec says (or at least must say, there is an issue there: #218: Need info about multiple recipients) that Alice must do encryption for every recipient key. As the key types must be equal (same curves), Alice should probably do encryption for every recipient key of the same type as her key.

Potential issues and unresolved questions

DID Comm spec doesn't discuss or specify the use case above. It's not 100% clear how Alice should choose the keys in case of multiple keys of different types. One of the simple proposals here is the following:

• Alice chooses a key: either explicitly (by key ID), or implicitly by her DID. In the latter case a possible logic is the following: Alice chooses the first key associated with the given (her) DID available on that device (that is in her secure wallet).

• Alice takes all recipient keys that have the same type as her chosen key and does encryption for every such key.

• Can this simple strategy lead to significant issues?

• Should there be a formal protocol for keys negotiation?

• What if half of devices have keyTypeA and the other half have keyTypeB. Alice used keyTypeA for encryption (the message was sent from a device with keyTypeA). But all Bob's devices that have keyTypeA are offline or switched off, and only devices with keyTypeB are online. So, Bob can not read the message.

• Are there any attacks related to this?

• Can it lead to security or usability issues?

This case is closely related to #218 and #224 as it's related to Multiple recipients case and backward compatibility discussions (both are not defined in the DID Comm spec explicitly now).

[TelegramSam]

Fantastic Question. I'll raise this in the DIDComm WG on Monday.

[kdenhartog]

Yeah agree with @TelegramSam this is a great question. My initial take is that we should probably make this an implementation detail rather than a normative requirement (if it is one). This brings up an interesting question for me. Imagine I knew the sender's implementation encrypts for all messages, then I could choose to have the messenger encrypt the message for all 1000 keys this effectively becomes a DoS attack of sorts. I think we'll want to consider that impact.

[AnomalRoil]

Notice that a lot of the conversation in #218 is actually concerned about this very topic here.

[TelegramSam]

Discussed in WG 20211213. The DIDComm spec will only manage messages between two parties. Multi-party coordination is a concern for a higher level construct.

[AnomalRoil]

@TelegramSam this isn't about the number of party, two parties can each have multiple devices with different keys...

In general nothing prevents one DID to have multiple keys in it, 1 DID = 1 party, no? Notice the current spec says:

Unless previously coordinated in a layer above DIDComm, the default recipients of the envelope MUST include all the KeyAgreement entries, representing Bob.

And also:

All keys declared in the DID Document’s keyAgreement section should be used as recipients when encrypting a message.

So this question about how to handle different key types for the same DID remains open. Notice that ECDH-1PU is compatible with the notion of encrypting for different key types at once using the key wrapping, but it's currently underspecified in the ECDH-1PU spec: https://github.com/NeilMadden/jose-ecdh-1pu/issues/4