[OAUTH-WG] draft-ietf-oauth-mtls-03: jwk / x5c sanity checks when registering for pub_key_tls_client_auth
Vladimir Dzhuvinov <vladimir@connect2id.com> Tue, 29 August 2017 07:29 UTC
Return-Path: <vladimir@connect2id.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 E2B6613293A for <oauth@ietfa.amsl.com>; Tue, 29 Aug 2017 00:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level:
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8] autolearn=ham autolearn_force=no
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 bQu4ZEDuSHNq for <oauth@ietfa.amsl.com>; Tue, 29 Aug 2017 00:29:26 -0700 (PDT)
Received: from p3plsmtpa12-06.prod.phx3.secureserver.net (p3plsmtpa12-06.prod.phx3.secureserver.net [68.178.252.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 480C81326DF for <oauth@ietf.org>; Tue, 29 Aug 2017 00:29:26 -0700 (PDT)
Received: from [192.168.0.103] ([78.130.190.73]) by :SMTPAUTH: with SMTP id maxCdUlF9RZBrmaxCdmOPi; Tue, 29 Aug 2017 00:28:55 -0700
To: IETF oauth WG <oauth@ietf.org>
From: Vladimir Dzhuvinov <vladimir@connect2id.com>
Organization: Connect2id Ltd.
Message-ID: <c8393341-18fe-df74-4d3f-26a444e65679@connect2id.com>
Date: Tue, 29 Aug 2017 10:28:53 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms080901070502090603030108"
X-CMAE-Envelope: MS4wfIawBgV7laX1krsP1zNK8zXqEok6s99m5+1wV5fJF+gE2aKZ96uj3nssSW5cWx6RVq5Tnq2ti3bwasrgbzpc/GRwWRollHBVJ2dd7PNcc6wrTUnmnWyk NUmQIYROii90taTugIN3trvlfsvFMpAqmPH8NM5kZHU9YZOrdfuEnVlI
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/lgjaQqVwP6EgLv1wpHlRXPdW50M>
Subject: [OAUTH-WG] draft-ietf-oauth-mtls-03: jwk / x5c sanity checks when registering for pub_key_tls_client_auth
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 29 Aug 2017 07:29:28 -0000
Aspects of this were previously discussed, on and off list. According to section 2.3, clients registering for public key bound mTLS auth must register their public keys as JWKs, or client X.509 certificate (as x5c parameter in RSA and EC JWK). In the latter case, are there any security implications if there is mismatch between the registered x5c and the top-level public key JWK parameters? Should the AS perform some sanity checks on the JWK parameters? A client could for instance register a JWK where the top-level JWK public key doesn't match the public key in the x5c (as key type, or public key value). Thanks, Vladimir
- [OAUTH-WG] draft-ietf-oauth-mtls-03: jwk / x5c sa… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-ietf-oauth-mtls-03: jwk / x5… Brian Campbell
- Re: [OAUTH-WG] draft-ietf-oauth-mtls-03: jwk / x5… Vladimir Dzhuvinov
- Re: [OAUTH-WG] draft-ietf-oauth-mtls-03: jwk / x5… Brian Campbell