Context input to KDF

[HBrock]

The current draft of cms-kemri specified ukm as a field in KEMRecipientInfo. I must be used in CMSORIforKEMOtherInfo as input for the KDF. Section 3 of cms-kemri writes: "ukm is optional user keying material. When the ukm value is provided, it is used as part of the info structure described in Section 5 to provide a context input to the key-derivation function. For example, the ukm value could include a nonce, application-specific context information, or an identifier for the originator. A KEM algorithm may place requirements on the ukm value. Implementations that do not support the ukm field SHOULD gracefully discontinue processing when the ukm field is present. Note that this requirement expands the original purpose of the ukm described in Section 10.2.6 of [RFC5652]; it is not limited to being used with key agreement algorithms."

Currently we specify KemOtherInfo as CMP alternative to ukm. It contains a static string "CMP-KEM", the transactionID and an optional kemContext. The kemContext is supposed to contain additional algorithm specific context information.

• I think we need to describe the use of KemOtherInfo and kemContext more specific, as for ukm above.
• Do we also need to offer the transferring the kemContext as part of the delivering the kemct, potentially as part of KemCiphertextInfo structure?

@johngray-dev @ounsworth What do think?

[HBrock]

Additionally, the CMSORIforKEMOtherInfo also contains the algorithm the derived key will be used for as well as its keylength. I think we discussed this before and we decided that the sender of the kemct should not decide on this, but it should leave this to the holder of the kem private key. This just to make sure, that we think it is safe to stick to this approach.

[HBrock]

while discussing with Kiron, I decided to add kemContext also to the KemCiphertextInfo structure to be in line with the definition in cms-kemri.

@johngray-dev @ounsworth What do you think?

[HBrock]

conclusion 26.02.2024 see #39