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

Benjamin Kaduk <> Tue, 16 March 2021 02:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1714F3A17D7 for <>; Mon, 15 Mar 2021 19:31:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ECiJ4keqKDZt for <>; Mon, 15 Mar 2021 19:31:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8B603A17D5 for <>; Mon, 15 Mar 2021 19:31:09 -0700 (PDT)
Received: from ([]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.14.7/8.12.4) with ESMTP id 12G2V27p013574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Mar 2021 22:31:07 -0400
Date: Mon, 15 Mar 2021 19:31:02 -0700
From: Benjamin Kaduk <>
To: Neil Madden <>
Cc: oauth <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
Archived-At: <>
Subject: Re: [OAUTH-WG] OAuth mTLS and JWK use/key_ops
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: Tue, 16 Mar 2021 02:31:12 -0000

On Mon, Mar 08, 2021 at 01:19:46PM +0000, Neil Madden wrote:
> > On 8 Mar 2021, at 12:50, Neil Madden <> wrote:
> > 
> > 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 <> 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.
> 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.

You do still want to use keyUsage/extendedKeyUsage checks for the
end-entity certificate; it's just that that's part of the application's
verification logic rather than path validation.  (E.g.,
draft-ietf-dtn-tcpclv4-26 provides for a id-kp-bundleSecurity EKU that
gives more authorization than just id-kp-serverAuth.)

My understanding is that JWK was attempting to be much simpler and lighter
weight than PKIX and thus didn't really envision JWKs signing X.509 objects
at all (if I am understanding the questions properly).

Generally, if you are trusting a self-signed certificate, the act of
trusting it would also cover whatever purpose you plan to put it towards,
so any asserted authorizations such as key usage values in the self-signed
certificate object itself are superfluous, so 

We could also pull in the PKIX experts for another opinion, if you want.
Typically we reach out to the LAMPS WG for that (spasm@) at this point.