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 96C4C132AA5 for ; Tue, 29 Aug 2017 08:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=pingidentity.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 v8cdtks2P4y5 for ; Tue, 29 Aug 2017 08:14:37 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 E186F132968 for ; Tue, 29 Aug 2017 08:14:36 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id 81so21237318ioj.5 for ; Tue, 29 Aug 2017 08:14:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6tKu/tc/l4xJs9prCeni14Xi8PHMfEU1V4/ztc8N5hM=; b=h8mF+E2o86nwzquuAO5srcNJ+yiUdGYtqwcvyNtRceDjdYb9ASVp4qeqcIW8MvSDnf +qX4fUAm+Ca22Xy0UMULpx9/OE7VKRMtYpO4adRdLpLklAOJDNDO/3xqXlwvFgbtY5WU FmVCZpEMF+xbKDXZWaKVT4OGeUlMA9HTaZ+sU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6tKu/tc/l4xJs9prCeni14Xi8PHMfEU1V4/ztc8N5hM=; b=HyvNdSFu6w28RbhbYRJUCLiT/y3B9G3URydbeQkripNizWziZs0z410DKjUh/2MRCx g+LQ4I2SzG7s/MSzn9SNRorPfo03EG3gNl40bQare4hZhNdMr5TbS5rQnACBV2Hx5Fl9 2fKMAixMGbbH5N8zmKnz0BXs2yarxwWj3wE4pbb2szgoVIly1UY4s+t5G0nGkkd6w2UQ pekcNEq8XVzdJh8G10UVSEhICGd1EE+/U/vgpZwg/PcEp3gQvMnIDMPWjvOhXhtYDJ1B NMfYoTrxmwtlQS6pJkhRYErzNZZSYeVELUozQYEiB/IlEgRQXkTHWmtwAa8MVBLGaZ6u p5cw== X-Gm-Message-State: AHYfb5jqQrHDi6+/qOg+my0m3OLW8mEhDEkTx6enqTTL2eFhKtnuUOpH L6PAc8R0UzyZ+dD0p48gIuxFvHvwpbWrBTVq2N9OqZggeSeQR2B9+wN5p1Vl+fc16t/4sTFv1x5 ASNyq X-Received: by 10.36.26.16 with SMTP id 16mr2869790iti.83.1504019676099; Tue, 29 Aug 2017 08:14:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.2.67.134 with HTTP; Tue, 29 Aug 2017 08:14:05 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Tue, 29 Aug 2017 09:14:05 -0600 Message-ID: To: Vladimir Dzhuvinov Cc: IETF oauth WG Content-Type: multipart/alternative; boundary="001a114444d887d6780557e5de0a" Archived-At: Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 15:14:39 -0000 --001a114444d887d6780557e5de0a Content-Type: text/plain; charset="UTF-8" Sec 4.7 of RFC 7517 , which defines "x5c" for JWK, says that the "key in the first certificate MUST match the public key represented by other members of the JWK." Thus, how I read it anyway, the check you mention is already a requirement of the JWK layer. On Tue, Aug 29, 2017 at 1:28 AM, Vladimir Dzhuvinov wrote: > 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 mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- *CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.* --001a114444d887d6780557e5de0a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sec 4.7 of RFC 7517, which defines "x5c" = for JWK, says that the "key in the first certificate MUST match the pu= blic key represented by other members of the JWK." Thus, how I read it= anyway, the check you mention is already a requirement of the JWK layer.

On Tu= e, Aug 29, 2017 at 1:28 AM, Vladimir Dzhuvinov <vladimir@connect2id.= com> wrote:
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 mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth



<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --001a114444d887d6780557e5de0a--