Subject: [lamps] Discussion on KEM RecipientInfos

From: Mike Ounsworth <[email-masked]>
Date: Mon, 8 Nov 2021 20:16:51 +0000

Hi LAMPS!

Background: refresher on KEMs
A KEM, as per the NIST API (footnote 1) takes in a recip public key and produces a shared secret and a ciphertext.

This does not fit into interfaces that expect either a KeyTrans (takes in a recip pub key and a CEK) or a KeyAgree (takes in a recip pub key, sender priv key, and produces a shared secret and a ciphertext). You can trivially make a KeyTrans or a KeyAgree fit into a KEM interface, but not the other way around; making KEM the "one-size-fits-all" key establishment interface of the future. So, we need to find a way to support in CMS crypto primitives that expose a KEM interface.

We have come up with three different ways to do this. During the LAMPS meeting, people voiced support for all three, so I think this is worth hashing out on the list.

Common to all:
The behaviour of all three is the same; it's just a question of how we transport the params {KEM, KDF, WRAP} on the wire in CMS

Params: KEM, KDF, WRAP
Input: recipPubKey, cek

ss, ct = KEM.encaps(rPK)
kek = KDF(ss)
wk = WRAP(kek, cek)
ek = ct || wk

Option 1: use KeyTransRecipientInfo

Use KeyTransRecipientInfo with a KeyEncryptionAlgorithmIdentifier like ke-kyber512WithPbkdf2-512-SHA512-100000WithAESGCM-256 (god that's ugly; Russ you _really_ want to unroll everything into the OID?).

Option 2: use OtherRecipientInfo

Content is similar to 1, but it's semantically clear that it's not a KeyTrans primitive, and you can keep the UserKeyingMaterial that is useful in KeyAgreeRecpientInfo.

Option 3: define a new KEMRecipientInfo

Add an item to the RecipientInfo ::= CHOICE { .. } list.

Something like this:

KEMRecipientInfo ::= SEQUENCE {
        version CMSVersion,  -- always set to 0 or 2
        rid RecipientIdentifier,

        ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
        kem AlgorithmIdentifier,
        kdf AlgorithmIdentifier,
        wrap AlgorithmIdentifier,
        encryptedKey EncryptedKey }

The semantics of this are super clear and you don't need hideous OIDs, but we need a human ASN.1 compiler to tell us whether appending to a CHOICE list is a breaking change.

Discussion, GO!

Footnote 1: https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf

---
Mike Ounsworth
Software Security Architect, Entrust

Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system.

---

From: Russ Housley <[email-masked]>
Date: Mon, 8 Nov 2021 15:27:36 -0500

This looks good, except there is no reason to have anything other than version 0 because there are no backward compatibility issues (yet)

        version CMSVersion,  -- always set to 0

Russ

> On Nov 8, 2021, at 3:16 PM, Mike Ounsworth <Mike.Ounsworth=[email-masked]> wrote:
> 
> Hi LAMPS!
>  
> This does not fit into interfaces that expect either a KeyTrans (takes in a recip pub key and a CEK) or a KeyAgree (takes in a recip pub key, sender priv key, and produces a shared secret and a ciphertext). You can trivially make a KeyTrans or a KeyAgree fit into a KEM interface, but not the other way around; making KEM the “one-size-fits-all” key establishment interface of the future. So, we need to find a way to support in CMS crypto primitives that expose a KEM interface.
>  
>  
> The behaviour of all three is the same; it’s just a question of how we transport the params {KEM, KDF, WRAP} on the wire in CMS
>  
> Params: KEM, KDF, WRAP
> Input: recipPubKey, cek
>  
> ss, ct = KEM.encaps(rPK)
> kek = KDF(ss)
> wk = WRAP(kek, cek)
> ek = ct || wk
>  
>  
>  
>  
> Use KeyTransRecipientInfo with a KeyEncryptionAlgorithmIdentifier like ke-kyber512WithPbkdf2-512-SHA512-100000WithAESGCM-256 (god that’s ugly; Russ you _really_ want to unroll everything into the OID?).
>  
>  
>  
> Content is similar to 1, but it’s semantically clear that it’s not a KeyTrans primitive, and you can keep the UserKeyingMaterial that is useful in KeyAgreeRecpientInfo.
>  
>  
>  
> The semantics of this are super clear and you don’t need hideous OIDs, but we need a human ASN.1 compiler to tell us whether appending to a CHOICE list is a breaking change.
>  
>  
> Discussion, GO!
>  
>  
>  
> Footnote 1: https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf <https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/documents/example-files/api-notes.pdf>
>  
> ---
> Mike Ounsworth
> Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the information it contains. Please notify Entrust immediately and delete the message from your system. _______________________________________________
> Spasm mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>