Re: [lamps] Discussion on KEM RecipientInfos

[Russ Housley <[e-mail]>]

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

     KEMRecipientInfo ::= SEQUENCE {
        version CMSVersion,  -- always set to 0
        rid RecipientIdentifier,
        ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
        kem AlgorithmIdentifier,
        kdf AlgorithmIdentifier,
        wrap AlgorithmIdentifier,
        encryptedKey EncryptedKey }


Russ

> On Nov 8, 2021, at 3:16 PM, Mike Ounsworth <Mike.Ounsworth=[e-mail]> wrote:
> 
> 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 <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. _______________________________________________
> Spasm mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>