From nobody Mon Nov 8 12:27:46 2021 Return-Path: X-Original-To: spasm@ietfa.amsl.com Delivered-To: spasm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D0E3A1081 for ; Mon, 8 Nov 2021 12:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wsp-vGZMwket for ; Mon, 8 Nov 2021 12:27:40 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7835D3A107F for ; Mon, 8 Nov 2021 12:27:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 1FB35300BDC for ; Mon, 8 Nov 2021 15:27:42 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lBYQESowkRzd for ; Mon, 8 Nov 2021 15:27:39 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 86033300B8C; Mon, 8 Nov 2021 15:27:39 -0500 (EST) From: Russ Housley Message-Id: <3C977062-006C-497F-B100-6CAC4EB89875@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F32AA4F8-56AB-44E9-864D-05B5345CF133" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Mon, 8 Nov 2021 15:27:36 -0500 In-Reply-To: Cc: LAMPS WG To: Mike Ounsworth References: X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [lamps] Discussion on KEM RecipientInfos X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2021 20:27:45 -0000 --Apple-Mail=_F32AA4F8-56AB-44E9-864D-05B5345CF133 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This looks good, except there is no reason to have anything other than = version 0 because there are no backward compatibility issues (yet) KEMRecipientInfo ::=3D 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 = wrote: >=20 > Hi LAMPS! > =20 > 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. > =20 > 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 =E2=80=9Cone-size-fits-all=E2=80=9D= key establishment interface of the future. So, we need to find a way to = support in CMS crypto primitives that expose a KEM interface. > =20 > =20 > 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. > =20 > =20 > Common to all: > The behaviour of all three is the same; it=E2=80=99s just a question = of how we transport the params {KEM, KDF, WRAP} on the wire in CMS > =20 > Params: KEM, KDF, WRAP > Input: recipPubKey, cek > =20 > ss, ct =3D KEM.encaps(rPK) > kek =3D KDF(ss) > wk =3D WRAP(kek, cek) > ek =3D ct || wk > =20 > =20 > =20 > =20 > Option 1: use KeyTransRecipientInfo > =20 > Use KeyTransRecipientInfo with a KeyEncryptionAlgorithmIdentifier like = ke-kyber512WithPbkdf2-512-SHA512-100000WithAESGCM-256 (god that=E2=80=99s = ugly; Russ you _really_ want to unroll everything into the OID?). > =20 > =20 > =20 > Option 2: use OtherRecipientInfo > =20 > Content is similar to 1, but it=E2=80=99s semantically clear that = it=E2=80=99s not a KeyTrans primitive, and you can keep the = UserKeyingMaterial that is useful in KeyAgreeRecpientInfo. > =20 > =20 > =20 > Option 3: define a new KEMRecipientInfo > =20 > Add an item to the RecipientInfo ::=3D CHOICE { .. } list.=20 > =20 > Something like this: > =20 > KEMRecipientInfo ::=3D SEQUENCE { > version CMSVersion, -- always set to 0 or 2 > rid RecipientIdentifier, > ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL, > kem AlgorithmIdentifier, > kdf AlgorithmIdentifier, > wrap AlgorithmIdentifier, > encryptedKey EncryptedKey } > =20 > The semantics of this are super clear and you don=E2=80=99t need = hideous OIDs, but we need a human ASN.1 compiler to tell us whether = appending to a CHOICE list is a breaking change. > =20 > =20 > Discussion, GO! > =20 > =20 > =20 > Footnote 1: = https://csrc.nist.gov/CSRC/media/Projects/Post-Quantum-Cryptography/docume= nts/example-files/api-notes.pdf = > =20 > --- > Mike Ounsworth > Software Security Architect, Entrust > =20 > 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 > https://www.ietf.org/mailman/listinfo/spasm = --Apple-Mail=_F32AA4F8-56AB-44E9-864D-05B5345CF133 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
This looks good, except there is no reason to = have anything other than version 0 because there are no backward = compatibility issues (yet)

    =  KEMRecipientInfo ::=3D 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=3D40entrust.com@dmarc.ietf.org> = 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 =E2=80=9Cone-size-fits-all=E2=80=9D 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=E2=80=99s 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 =3D = KEM.encaps(rPK)
kek =3D = KDF(ss)
wk =3D WRAP(kek, = cek)
ek =3D ct || wk
 
 
 
 
Option 1: use = KeyTransRecipientInfo
 
Use KeyTransRecipientInfo = with a KeyEncryptionAlgorithmIdentifier like = ke-kyber512WithPbkdf2-512-SHA512-100000WithAESGCM-256 (god that=E2=80=99s = ugly; Russ you _really_ want to unroll everything into = the OID?).
 
 
 
Option 2: use = OtherRecipientInfo
 
Content is similar to 1, = but it=E2=80=99s semantically clear that it=E2=80=99s 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 ::=3D CHOICE { .. } list. 
 
Something like this:
 
KEMRecipientInfo ::=3D = 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=E2=80=99t 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-Cryptogr= aphy/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
https://www.ietf.org/mailman/listinfo/spasm

= --Apple-Mail=_F32AA4F8-56AB-44E9-864D-05B5345CF133--