From nobody Mon Mar 8 05:19:59 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 142763A29D0 for ; Mon, 8 Mar 2021 05:19:57 -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, 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 WiN1XAWNzdSB for ; Mon, 8 Mar 2021 05:19:55 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 CEA5A3A29CE for ; Mon, 8 Mar 2021 05:19:54 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id y124-20020a1c32820000b029010c93864955so3787677wmy.5 for ; Mon, 08 Mar 2021 05:19:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forgerock.com; s=google; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=YYNmOAx+oTgmSwyjUDXvq0qrEdf38uHgl8NI5+hGvyA=; b=OY4bgYpdbcB8PQjtNI7Yh075BiVdkfzjmuO+ufuHDJLX2TBxY/pFvPwaRgGuD4R0Mg /1bFoD9p3C3E/jz3w2WagF9335lPKM7XoGmLm1Tx9LHudyVwjNng7CEPGco9oPpQcA9W OOc1yRe7saUGRxbp4f6BYRSTyLtGDFZfAV2ik= 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:date:references:to :in-reply-to:message-id; bh=YYNmOAx+oTgmSwyjUDXvq0qrEdf38uHgl8NI5+hGvyA=; b=l9PJlVYkheyWpvdeTyPheih4SfLORJo+Qr5Z8qF85D4dFeFwiD5GOGulkzX/7ceGv3 E02GZni3cbYtoEn6mA7s987YnYZ1shu2Tv08g2SiQ7xoxmneMXbPCgPftzhdYfOiKpIm u8O7GyLVTv3iKbVir2awwFs64IjCaxDql+D01fO9e8WXxR0MDsf5vclN2/jC23pu03WX nkISHHQJ5PtJ4eBuzF03Rd7k8vJU/3GCOUmBuzi6TSd54krsWpaj85wo5+HqN4FGoKZq 30w6tLu/FpyfE/IyYYqy40diLVwU5YRrbWaRsz6r03YqH3HYv4NG7JHiA7DZ831fa1jZ FEjg== X-Gm-Message-State: AOAM532FzHOMKwgEIgtUEltNVoHk6aA5gyxlHIwvHoB5zma2A9lThMLx l1ypS97OGYTGdfX+DpEFU2jC2PjfeQZNzyUg1Lshhdt13nxSHDIZHKxT1nYoNw7QcYfJZWBuZlF icyurvprvssHsZ7hu7elV4hf3Na7oOdZGADOlB7UDkO7xt6mAojEw1/gR89Kzu2MWdcy2 X-Google-Smtp-Source: ABdhPJwU/OCm031j2HRk96/I13Mb9zzSsQHp5LyeqxbIDoHyX/Zxvsp78F6uHYdonp2DAa74kOvhHg== X-Received: by 2002:a05:600c:4fd0:: with SMTP id o16mr15073197wmq.123.1615209587913; Mon, 08 Mar 2021 05:19:47 -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 f14sm18641406wmf.7.2021.03.08.05.19.47 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Mar 2021 05:19:47 -0800 (PST) From: Neil Madden Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 8 Mar 2021 13:19:46 +0000 References: To: oauth In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.120.23.2.4) Content-Type: multipart/alternative; boundary="Apple-Mail=_D926CEB7-65BB-46DF-8A79-9C49FBE488EE" Archived-At: Subject: Re: [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 13:19:57 -0000 --Apple-Mail=_D926CEB7-65BB-46DF-8A79-9C49FBE488EE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" > On 8 Mar 2021, at 12:50, Neil Madden wrote: >=20 > An interesting question was raised by our developers around the interpret= ation of JWK =E2=80=9Cuse=E2=80=9D and =E2=80=9Ckey_ops=E2=80=9D constraint= s when publishing a self-signed certificate for mTLS client authentication.= In X.509 the KeyUsage extension distinguishes between keys intended for us= e for verifying general signatures (digitalSignature) and those used for ve= rifying signatures on certificates (keyCertSign). The JWK spec doesn=E2=80= =99t 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 pu= blishing an X.509 certificate (x5c claim) that asserts KeyUsage keyCertSign= ? >=20 > It seems plausible that an application might also choose to consume CA ce= rtificates from a central certificate management service that publishes the= m in JWK format on an internal HTTPS endpoint. So this question is potentia= lly broader than just self-signed certs, although that is the only case dis= cussed in RFC 8705. >=20 > In the course of trying to answer this question, I came across https://gi= thub.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= =E2=80=99t want self-signed certs to assert the keyCertSign bit, because th= is 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 t= rust anchor, whether self-signed or not. I have this part backwards - RFC 5280 path validation skips the KeyUsage ch= eck for the end-entity certificate, not the trust anchor cert. This makes m= ore sense. The rest of my comments/questions still apply though. >=20 > RFC 8705 is silent on how to interpret use/key_ops in this case, 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/key_ops cons= traints - 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 u= se not specified=E2=80=9D). In general, RFC 7517 is silent about how constr= aints on any X.509 certificate interact with constraints specified in the J= WK itself. >=20 > 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?) >=20 > =E2=80=94 Neil --=20 ForgeRock values your Privacy --Apple-Mail=_D926CEB7-65BB-46DF-8A79-9C49FBE488EE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"

On= 8 Mar 2021, at 12:50, Neil Madden <neil.madden@forgerock.com> wrote:

An interesting question was 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-signed certificate for mTLS client authe= ntication. In X.509 the KeyUsage extension distinguishes between keys inten= ded for use for verifying general signatures (digitalSignature) and those u= sed for verifying signatures on certificates (keyCertSign). The JWK spec do= esn=E2=80=99t make this distinction, so there is only the generic =E2=80=9C= use=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]) compati= ble with publishing an X.509 certificate (x5c claim) that asserts KeyUsage = keyCertSign?

It seems p= lausible that an application might also choose to consume CA certificates f= rom a central certificate management service that publishes them in JWK for= mat on an internal HTTPS endpoint. So this question is potentially broader = than just self-signed certs, although that is the only case discussed in RF= C 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 rele= vant RFCs in the discussion. The conclusion appears to be that when process= ing self-signed certificates the KeyUsage check should be skipped. The reas= oning 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, the language from RFC 5280 suggests this ch= eck should be skipped for any trust anchor, whether self-signed or not.

I have this= part backwards - RFC 5280 path validation skips the KeyUsage check for the= end-entity certificate, not the trust anchor cert. This makes more sense. = The rest of my comments/questions still apply though.

<= blockquote type=3D"cite" class=3D"">

RFC 8705 is silent on how to interpret use/key_ops in this case, 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/key_ops cons= traints - 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 u= se not specified=E2=80=9D). In general, RFC 7517 is silent about how constr= aints on any X.509 certificate interact with constraints specified in the J= WK itself.

My fee= ling is that =E2=80=9Cuse=E2=80=9D:=E2=80=9Dsig=E2=80=9D and =E2=80=9Ckey_o= ps=E2=80=9D:[=E2=80=9Cverify=E2=80=9D] probably shouldn=E2=80=99t imply tha= t the key can be used to verify certificate signatures (danger lies that wa= y), and that when processing a JWK specifically as a self-signed trust anch= or we should follow the lead of RFC 5280 and instruct applications to ignor= e any use/key_ops constraints on the JWK. What do others think? (And how wo= uld we go about clarifying this? As an errata?)

=E2=80=94 Neil


ForgeRock values your Privacy --Apple-Mail=_D926CEB7-65BB-46DF-8A79-9C49FBE488EE--