From nobody Mon Mar 8 04:51:42 2021 Return-Path: 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 ; 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 ; 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 ; Mon, 8 Mar 2021 04:51:04 -0800 (PST) Received: by mail-wr1-x42b.google.com with SMTP id d15so11335506wrv.5 for ; 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 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Mar 2021 04:51:01 -0800 (PST) From: Neil Madden Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Mon, 8 Mar 2021 12:50:59 +0000 To: oauth X-Mailer: Apple Mail (2.3608.120.23.2.4) Content-Type: multipart/alternative; boundary="Apple-Mail=_41B3B37D-35F5-4FB5-9509-5A81A234517B" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 12:51:41 -0000 --Apple-Mail=_41B3B37D-35F5-4FB5-9509-5A81A234517B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" An interesting question was raised by our developers around the interpretat= ion of JWK =E2=80=9Cuse=E2=80=9D and =E2=80=9Ckey_ops=E2=80=9D constraints = when publishing a self-signed certificate for mTLS client authentication. I= n X.509 the KeyUsage extension distinguishes between keys intended for use = for verifying general signatures (digitalSignature) and those used for veri= fying signatures on certificates (keyCertSign). The JWK spec doesn=E2=80=99= t make this distinction, so there is only the generic =E2=80=9Cuse=E2=80=9D= :=E2=80=9Dsig=E2=80=9D and =E2=80=9Ckey_ops=E2=80=9D: [=E2=80=9Cverify=E2= =80=9D] indicators. So, is =E2=80=9Cuse=E2=80=9D:=E2=80=9Dsig=E2=80=9D (or = =E2=80=9Ckey_ops=E2=80=9D:[=E2=80=9Cverify=E2=80=9D]) compatible with publi= shing an X.509 certificate (x5c claim) that asserts KeyUsage keyCertSign? It seems plausible that an application might also choose to consume CA cert= ificates from a central certificate management service that publishes them = in JWK format on an internal HTTPS endpoint. So this question is potentiall= y broader than just self-signed certs, although that is the only case discu= ssed in RFC 8705. In the course of trying to answer this question, I came across https://gith= ub.com/openssl/openssl/issues/1418 which has links to various relevant RFCs in the discussion. The co= nclusion appears to be that when processing self-signed certificates the Ke= yUsage check should be skipped. The reasoning appears to be that we don=E2= =80=99t want self-signed certs to assert the keyCertSign bit, because this = increases the risk of them being mistaken for genuine CA certs. In fact, th= e language from RFC 5280 suggests this check should be skipped for any trus= t anchor, whether self-signed or not. RFC 8705 is silent on how to interpret use/key_ops in this case, and RFC 75= 17 doesn=E2=80=99t discuss whether the signature-related use/key_ops are in= tended to cover certificate signatures or not. RFC 7517 also doesn=E2=80=99= t say whether applications are even required to enforce use/key_ops constra= ints - it seems left to the discretion of the application. (There=E2=80=99s= no language like =E2=80=9Cthe application MUST NOT use the key for a use n= ot specified=E2=80=9D). In general, RFC 7517 is silent about how constraint= s on any X.509 certificate interact with constraints specified in the JWK i= tself. My feeling is that =E2=80=9Cuse=E2=80=9D:=E2=80=9Dsig=E2=80=9D and =E2=80= =9Ckey_ops=E2=80=9D:[=E2=80=9Cverify=E2=80=9D] probably shouldn=E2=80=99t i= mply 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 tr= ust 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? (An= d how would we go about clarifying this? As an errata?) =E2=80=94 Neil --=20 ForgeRock values your Privacy --Apple-Mail=_41B3B37D-35F5-4FB5-9509-5A81A234517B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" An interesting question wa= s raised by our developers around the interpretation of JWK =E2=80=9Cuse=E2= =80=9D and =E2=80=9Ckey_ops=E2=80=9D constraints when publishing a self-sig= ned certificate for mTLS client authentication. In X.509 the KeyUsage exten= sion distinguishes between keys intended for use for verifying general sign= atures (digitalSignature) and those used for verifying signatures on certif= icates (keyCertSign). The JWK spec doesn=E2=80=99t make this distinction, s= o there is only the generic =E2=80=9Cuse=E2=80=9D:=E2=80=9Dsig=E2=80=9D and= =E2=80=9Ckey_ops=E2=80=9D: [=E2=80=9Cverify=E2=80=9D] indicators. So, is = =E2=80=9Cuse=E2=80=9D:=E2=80=9Dsig=E2=80=9D (or =E2=80=9Ckey_ops=E2=80=9D:[= =E2=80=9Cverify=E2=80=9D]) compatible with publishing an X.509 certificate = (x5c claim) that asserts KeyUsage keyCertSign?

It seems plausible that an application might also c= hoose to consume CA certificates from a central certificate management serv= ice that publishes them in JWK format on an internal HTTPS endpoint. So thi= s question is potentially broader than just self-signed certs, although tha= t is the only case discussed in RFC 8705.
In the course of trying to answer this qu= estion, I came across https://github.com/openssl/openssl/issues/1418&nb= sp;which has links to various relevant RFCs in the discussion. The conclusi= on appears to be that when processing self-signed certificates the KeyUsage= check should be skipped. The reasoning appears to be that we don=E2=80=99t= want self-signed certs to assert the keyCertSign bit, because this increas= es the risk of them being mistaken for genuine CA certs. In fact, the langu= age from RFC 5280 suggests this check should be skipped for any trust ancho= r, whether self-signed or not.

RFC 8705 is silent on how to interpret use/key_ops in this ca= se, and RFC 7517 doesn=E2=80=99t discuss whether the signature-related use/= key_ops are intended to cover certificate signatures or not. RFC 7517 also = doesn=E2=80=99t say whether applications are even required to enforce use/k= ey_ops constraints - it seems left to the discretion of the application. (T= here=E2=80=99s no language like =E2=80=9Cthe application MUST NOT use the k= ey for a use not specified=E2=80=9D). In general, RFC 7517 is silent about = how constraints on any X.509 certificate interact with constraints specifie= d in the JWK itself.

My feeling is that =E2=80=9Cuse=E2=80=9D:=E2=80=9Dsig=E2=80=9D and = =E2=80=9Ckey_ops=E2=80=9D:[=E2=80=9Cverify=E2=80=9D] probably shouldn=E2=80= =99t imply that the key can be used to verify certificate signatures (dange= r lies that way), and that when processing a JWK specifically as a self-sig= ned trust anchor we should follow the lead of RFC 5280 and instruct applica= tions to ignore any use/key_ops constraints on the JWK. What do others thin= k? (And how would we go about clarifying this? As an errata?)

=E2=80=94 Neil

ForgeRock values your Privacy --Apple-Mail=_41B3B37D-35F5-4FB5-9509-5A81A234517B--