From nobody Thu Dec 22 12:06:06 2022 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 A833BC14F720 for ; Thu, 22 Dec 2022 12:06:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hGZr-Ru7E2U for ; Thu, 22 Dec 2022 12:05:55 -0800 (PST) Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7DC5C14F718 for ; Thu, 22 Dec 2022 12:05:55 -0800 (PST) Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id AC95A15C05E; Thu, 22 Dec 2022 15:05:54 -0500 (EST) Received: from a860b60074bd.fios-router.home (unknown [96.241.2.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 7AB0015C184; Thu, 22 Dec 2022 15:05:54 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_96568A80-09A3-43FD-A8AF-DA197F776B80" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Thu, 22 Dec 2022 15:05:53 -0500 In-Reply-To: Cc: LAMPS , "Brockhaus, Hendrik" To: "von Oheimb, David" References: X-Mailer: Apple Mail (2.3445.104.21) X-Scanned-By: mailmunge 3.10 on 66.39.134.11 Archived-At: Subject: Re: [lamps] CMS: selection of key management technique to use for EnvelopedData X-BeenThere: spasm@ietf.org X-Mailman-Version: 2.1.39 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: Thu, 22 Dec 2022 20:06:04 -0000 --Apple-Mail=_96568A80-09A3-43FD-A8AF-DA197F776B80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii David: Based on guidance from the CA/Browser forum, most certificates include a = key usage extension. When it is missing, I guess one needs to figure out whether it is a key = agreement key or a key transport key based on the algorithm identifier. There is some advice about keyUsage extensions for particular algorithms = is available in RFC3279, RFC4055, and RFC4491. I probably missed = some... Russ > On Dec 22, 2022, at 2:55 PM, von Oheimb, David = wrote: >=20 > Russ et al., >=20 > when doing extended tests on central (i.e., server-side) key = generation with CMP Updates, where CMS is used for sending the newly = generated private key encrypted to the client, > we stumbled over potential differences between the key management = techniques allowed by the client certificate and those techniques = actually supported by the key type in that cert. >=20 > Sorting this out, we tried to find in RFC 5652 = , in particular section 6 = on EnvelopedData, some guidance how to select the key management = technique to use for a given recipient cert. > Yet it looks like this is kind of implicit. For instance, if the = public key in the recipient cert is of type RSA, only key transport = makes sense, while for EC keys only key agreement makes sense. > Is there any specification that makes the (intended) selection of the = key management technique explicit, or has this been deliberately left = open? >=20 > ( > Side note: > The only explicit hint in this direction may be the key usage = extension that can optionally be contained in the recipient cert - as = written in RFC 5652: >=20 > 6.2.1 . = KeyTransRecipientInfo Type >=20 > =20 > The recipient's certificate must contain a key transport public > key. Therefore, a recipient X.509 version 3 certificate that > contains a key usage extension MUST assert the keyEncipherment > bit. =20 >=20 > and in >=20 > 6.2.2 . = KeyAgreeRecipientInfo Type >=20 > The recipient's certificate must > contain a key agreement public key. Therefore, a recipient = X.509 > version 3 certificate that contains a key usage extension MUST > assert the keyAgreement bit. >=20 > Yet this does not help if the cert does not contain a key usage = extension, or if the key usage extension is present and its bits allow = for more than one choice. > Moreover, the key usage extension may even exclude, by intention or by = mistake, the use of all algorithmically suitable techniques. > ) >=20 > AFAIK, so far there are no key types/algorithms that support more than = one key management technique (such as, both key transport and key = agreement). > Thus the concern may be just hypothetical because at least for the = well-known key types (RSA, EC, and DH) it should be clear which = technique to use. > Still we'd be interested in learning about explicit = specification/guidance, maybe in some accompanying RFC, that we could = provide to implementers. >=20 > David and Hendrik >=20 --Apple-Mail=_96568A80-09A3-43FD-A8AF-DA197F776B80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii David:

Based on guidance from the CA/Browser forum, most = certificates include a key usage extension.

When it is missing, I guess one needs = to figure out whether it is a key agreement key or a key transport key = based on the algorithm identifier.

There is some advice about keyUsage = extensions for particular algorithms is available in RFC3279, RFC4055, = and RFC4491.  I probably missed some...

Russ


On Dec 22, 2022, at 2:55 PM, von Oheimb, David <david.von.oheimb@siemens.com> wrote:

Russ et al.,

when doing extended tests on central (i.e., server-side) = key generation with CMP Updates, where CMS is used for sending the newly = generated private key encrypted to the client,
we stumbled over potential differences between the key management = techniques allowed by the client certificate and those techniques = actually supported by the key type in that cert.

Sorting this out, we tried to find in RFC = 5652, in particular section 6 on EnvelopedData, some guidance how to = select the key management technique to use for a given recipient = cert.
Yet it looks like this is kind of implicit. For = instance, if the public key in the recipient cert is of type RSA, only = key transport makes sense, while for EC keys only key agreement makes = sense.
Is there any specification that makes the (intended) selection of the = key management technique explicit, or has this been deliberately left = open?

(
Side note:
The only explicit hint in this direction may be the key usage extension = that can optionally be contained in the recipient cert - as written in = RFC 5652:

6.2.1.  KeyTransRecipientInfo =
Type

  =20
      The recipient's certificate must contain a key transport public
      key.  Therefore, a recipient X.509 version 3 certificate that
      contains a key usage extension MUST assert the =
keyEncipherment
      bit.

and in

6.2.2.  KeyAgreeRecipientInfo =
Type

      The=
 recipient's certificate must
      =
contain a key agreement public key.  Therefore, a recipient X.509
      version 3 certificate that contains a key usage extension =
MUST
      assert =
the keyAgreement =
bit.

Yet this does not help if the cert does not contain a = key usage extension, or if the key usage extension is present and its = bits allow for more than one choice.
Moreover, the key usage extension may even exclude, by intention or by = mistake, the use of all algorithmically suitable techniques.
)

AFAIK, so far there are no key types/algorithms that = support more than one key management technique (such as, both key = transport and key agreement).
Thus the concern may be just hypothetical because at least for the = well-known key types (RSA, EC, and DH) it should be clear which = technique to use.
Still we'd be interested in learning about explicit = specification/guidance, maybe in some accompanying RFC, that we could = provide to implementers.

David and Hendrik


= --Apple-Mail=_96568A80-09A3-43FD-A8AF-DA197F776B80--