[OAUTH-WG] OAuth mTLS and JWK use/key_ops

Neil Madden <neil.madden@forgerock.com> Mon, 08 March 2021 12:51 UTC

Return-Path: <neil.madden@forgerock.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124273A0E77 for <oauth@ietfa.amsl.com>; Mon, 8 Mar 2021 04:51:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forgerock.com
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 CgXAyzCJYrdM for <oauth@ietfa.amsl.com>; Mon, 8 Mar 2021 04:51:38 -0800 (PST)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0043A2AFE for <oauth@ietf.org>; Mon, 8 Mar 2021 04:51:04 -0800 (PST)
Received: by mail-wr1-x42b.google.com with SMTP id d15so11335506wrv.5 for <oauth@ietf.org>; Mon, 08 Mar 2021 04:51:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=+0HcKsIMN+FSuYrM02W9J4J7hBoer9URY929UYdrPws=; b=TBM5m/rhRn961v3vGKtmEgtzU82uT9pjahRT1PiVfYBDQF6h/4h2cRvloArbFkRFzb 0SQ8DwigrZy1E+uizFwW8/vvUWBYvnojTbyfoBZUpeKw1DIt63OL5lyWkgmhDiF6orio gPvtPHBnIameDhS2U6zwBmQZ5dORuzF271r2s=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=+0HcKsIMN+FSuYrM02W9J4J7hBoer9URY929UYdrPws=; b=Eme0gHbKYXIeKMbN9We9/quD6Ag+ygfF0ZZshXV7z/N3Yg7m540IcEqaoMNIty5uj8 VrTWWYIfy0eXDKam3wTbPFVDyJM7P+wkQqxb9nT/weTumzL2iLooLKCmggBrTqwzjMeI gm5BJh3Yent/ZDxJI2rmE9K4WOmCmT5/MizHtjkEyEDdki6S8hqKJxpQoZR8R5fez24J jlhSth/nFjBKcndBVLpkwmSgOxE2UVsJctJLr02GwX7bN+PWpt7GTAYPsO4M/B8V3Bve qWm1lkW/grD1MbdfPIuAuHfgqKpzKKkuPnQc27ycVtDXbtf1iNE7d9BBYH7CDk/TLQPp LXyQ==
X-Gm-Message-State: AOAM531LVS0o/up3DO4FNHNsdY8nfQHKigzq3xMcvHH2K41Xp4h8yxR9 qQVqgyGgC+NhJXtemJNHf2D3+8NVG8BMLX+qUm1JB9br5zaUgaGhHEuTdQts2BMd7/8HQTiNEXJ 5xw5InD8TEuWkIPcpGmpYWq7CEnwlKuj7IehQ1AEjHfjT+sx4r/SkHKuZCduJ8yhmXJ5j
X-Google-Smtp-Source: ABdhPJyeILJm0v8F9bIh9esZ7p//dPSuE+0bt8QDDb5rBDpmHCKifBXYIi36Tvg3YjRgI8+NmUehag==
X-Received: by 2002:adf:ef4c:: with SMTP id c12mr23200682wrp.112.1615207861566; Mon, 08 Mar 2021 04:51:01 -0800 (PST)
Received: from [10.0.0.6] (252.207.159.143.dyn.plus.net. [143.159.207.252]) by smtp.gmail.com with ESMTPSA id w131sm18237733wmb.8.2021.03.08.04.51.01 for <oauth@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Mar 2021 04:51:01 -0800 (PST)
From: Neil Madden <neil.madden@forgerock.com>
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Message-Id: <F8D17A80-E4BC-48F8-A4DD-55C5DC45B20E@forgerock.com>
Date: Mon, 08 Mar 2021 12:50:59 +0000
To: oauth <oauth@ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Content-Type: multipart/alternative; boundary="Apple-Mail=_41B3B37D-35F5-4FB5-9509-5A81A234517B"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Qg6eYx2_crJrga5L2_UdPevpJ2w>
Subject: [OAUTH-WG] OAuth mTLS and JWK use/key_ops
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Mar 2021 12:51:41 -0000

An interesting question was raised by our developers around the interpretation of JWK “use” and “key_ops” constraints when publishing a self-signed certificate for mTLS client authentication. In X.509 the KeyUsage extension distinguishes between keys intended for use for verifying general signatures (digitalSignature) and those used for verifying signatures on certificates (keyCertSign). The JWK spec doesn’t make this distinction, so there is only the generic “use”:”sig” and “key_ops”: [“verify”] indicators. So, is “use”:”sig” (or “key_ops”:[“verify”]) compatible with publishing an X.509 certificate (x5c claim) that asserts KeyUsage keyCertSign?

It seems plausible that an application might also choose to consume CA certificates from a central certificate management service that publishes them in JWK format on an internal HTTPS endpoint. So this question is potentially broader than just self-signed certs, although that is the only case discussed in RFC 8705.

In the course of trying to answer this question, I came across https://github.com/openssl/openssl/issues/1418 <https://github.com/openssl/openssl/issues/1418> which has links to various relevant RFCs in the discussion. The conclusion appears to be that when processing self-signed certificates the KeyUsage check should be skipped. The reasoning appears to be that we don’t want self-signed certs to assert the keyCertSign bit, because this increases the risk of them being mistaken for genuine CA certs. In fact, the language from RFC 5280 suggests this check should be skipped for any trust anchor, whether self-signed or not.

RFC 8705 is silent on how to interpret use/key_ops in this case, and RFC 7517 doesn’t discuss whether the signature-related use/key_ops are intended to cover certificate signatures or not. RFC 7517 also doesn’t say whether applications are even required to enforce use/key_ops constraints - it seems left to the discretion of the application. (There’s no language like “the application MUST NOT use the key for a use not specified”). In general, RFC 7517 is silent about how constraints on any X.509 certificate interact with constraints specified in the JWK itself.

My feeling is that “use”:”sig” and “key_ops”:[“verify”] probably shouldn’t imply that the key can be used to verify certificate signatures (danger lies that way), and that when processing a JWK specifically as a self-signed trust anchor we should follow the lead of RFC 5280 and instruct applications to ignore any use/key_ops constraints on the JWK. What do others think? (And how would we go about clarifying this? As an errata?)

— Neil
-- 
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>