Re: [lamps] Key Usage for KEM keys

From my perspective, keyEncryption is the best fit for the KEM algorithm.

As a reminder, the choices are:

   KeyUsage ::= BIT STRING {
     digitalSignature        (0),
     nonRepudiation          (1),
     keyEncipherment         (2),
     dataEncipherment        (3),
     keyAgreement            (4),
     keyCertSign             (5),
     cRLSign                 (6),
     encipherOnly            (7),
     decipherOnly            (8) }

Russ

> On Nov 8, 2021, at 3:33 PM, Mike Ounsworth <Mike.Ounsworth=40entrust.com@dmarc.ietf.org> wrote:
> 
> Hi LAMPS,
>  
> Another discussion from today’s meeting.
>  
> 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 KEM public keys in X.509 certificates.
>  
>  
>  
> Our options are keyEncipherment, keyAgreement, or some new KU (yuck, really?).
>  
>  
> Is there any reason not to allow both / either. If you get a pk-kyber512, is there any reason to be picky about whether it’s marked keyEncipherment or keyAgreement?
>  
> One thing I can think of is that a protocol seeing a KEM marked keyEncipherment might expect that to be wrapped with AES to transport a pre-established CEK, whereas a KEM marked keyAgreement might be expected to be used directly to derive a shared secret. So maybe KEM-keyEncipherment and KEM-keyAgreement are actually semantically different and a cert issuer may want to allow one but not the other? This would need to be standardized very carefully …
>  
>  
> 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
> Spasm@ietf.org <mailto:Spasm@ietf.org>
> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>