Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt

Samuel Erdtman <samuel@erdtman.se> Tue, 15 November 2016 17:02 UTC

Return-Path: <samuel@erdtman.se>
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 946EA12950A for <oauth@ietfa.amsl.com>; Tue, 15 Nov 2016 09:02:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=erdtman-se.20150623.gappssmtp.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 NRHmQMrnZmnB for <oauth@ietfa.amsl.com>; Tue, 15 Nov 2016 09:02:05 -0800 (PST)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 CE81512943E for <oauth@ietf.org>; Tue, 15 Nov 2016 09:02:04 -0800 (PST)
Received: by mail-wm0-x22b.google.com with SMTP id g23so179694977wme.1 for <oauth@ietf.org>; Tue, 15 Nov 2016 09:02:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erdtman-se.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rHpWX3yC8D7ALuAoXMwopxWYv9wJhwi8UkyaAdO4lns=; b=0wSkdH0Z1BcB+xRFyC87ir5bwKwrB0Vu50t0NmG3/mvFbcTGJtofLq2HQ7PcAgFMF+ KXfGh4Mt4MEjqAokvXOE1iSNW7E+01H0cenoqU/ft8QyuEiQ4MU4hX9tPb1x/cZJ44Gj Vvcx5IYPq03gSpKQ1rc4I3/gccvkVvmhyWX+oWA77eBJI/bf50ZNVI1d7/oIGHTpTZrs xJRmN+3fxlXnp9ZlL/wfm30mVY3V0wRRt7ohyeO1zHuXoMK2kluMrUmqfgwS8X6C75W2 U97diNYyjPMfAuD3QCo+tod8FVSrtPf8lSge/nlPrqgt20MXOemx5bzp3t7FTCxVPY+v e9Kw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rHpWX3yC8D7ALuAoXMwopxWYv9wJhwi8UkyaAdO4lns=; b=FqRPNGGZ/iG82DN12g8NllaKDKJH34XO9Ai/kokwDMnDIR6hnw9pvufrvLU53qLJQq hHWPfaO1NgEdVlS0kAwapjP3jNkQ1AjY7KM3cMytmfOMclZRMnJb9dd2tHWyV+YD3yqY dJVMz3ubzLfWmKzOtP6EWgAcx2aE/v8hpGzXsvh7IQfhyX/laeT2tnYPUJXgkNKZsywP Ru8FaGK7MXlHvsU69fZVncC09mBIUVNShpzIoHsUqMBF9QlIkSLJyFnKRBGVok3tMdug Ng6FPIxZuvRTYxv96bClIol1K+fcNolUq1jxzQoIbQYBV6zpMKphM6scuNiXmGmuq12/ Bo8w==
X-Gm-Message-State: ABUngvc4py5nCWq6Rx18cBfeknvsaB6oCkSNk1+tw2RbtJrcGMdWH/+VyGL5XERDA/CurzugBu75oO50AVVvuw==
X-Received: by 10.194.222.202 with SMTP id qo10mr24761986wjc.115.1479229322517; Tue, 15 Nov 2016 09:02:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.117.103 with HTTP; Tue, 15 Nov 2016 09:02:01 -0800 (PST)
In-Reply-To: <CA+k3eCRKa+DEEffxTYyJr62ipNsVYdCwmYAkJqHYov49odLbfw@mail.gmail.com>
References: <147613227959.31428.2920748721017165266.idtracker@ietfa.amsl.com> <9CDE07EB-E5B4-43B2-B3C1-F12569CAB458@ve7jtb.com> <26838e0e-1aee-04ca-4f7e-f6cff8dcfacf@connect2id.com> <CA+k3eCQaWm+O8VMNGGJG41j=dW2vqa4n6QZgKmVM9=d0HxgnCA@mail.gmail.com> <853d5445-72e4-a1fb-b89c-919864f051f6@connect2id.com> <CAF2hCbYn5_qBTmYkeJVCtJ-0=zWdRcFfu+0cHHb4ygo6as_V6w@mail.gmail.com> <CA+k3eCRXss-4_Cxmi41YAcXHh0VKeHogGT=xNkAo1mU6e5WG1w@mail.gmail.com> <CAF2hCbaEi4ntDwbWpTJ4-7_uwunK5WhpsoVLKds87r_s4K7n1w@mail.gmail.com> <CA+k3eCRq=P=0wqBx7O3C--fJYTEsuP1WH+1of53_oWb=bxfssw@mail.gmail.com> <41668b29-ba11-3bab-c77d-6b98bcb60280@mit.edu> <CAF2hCbZBaNWygUQo+nkC-KM=1NY4nYKJTwwioHN3G_FvFUKLqA@mail.gmail.com> <CA+k3eCSXpjzpEZUF8YUeEb4U90idVbGPLc1gzeL59PdaP+5qBg@mail.gmail.com> <CAF2hCbYxMLcXaFLHwzM=XTb9ZoTf2V4cW7vNnWhM3nqdbq+DMg@mail.gmail.com> <CA+k3eCRKa+DEEffxTYyJr62ipNsVYdCwmYAkJqHYov49odLbfw@mail.gmail.com>
From: Samuel Erdtman <samuel@erdtman.se>
Date: Tue, 15 Nov 2016 18:02:01 +0100
Message-ID: <CAF2hCbZ1OH60OJtagmmFOzDB-0XeG8kTAuz7-iLgrpD7ZWV-_g@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Content-Type: multipart/alternative; boundary="001a11c3ba624fdbfb054159eaf4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/vFjmupqWytdPp6aTgc1okFluEWk>
Cc: Nat Sakimura via Openid-specs-fapi <openid-specs-fapi@lists.openid.net>, OAuth WG <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-campbell-oauth-tls-client-auth-00.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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, 15 Nov 2016 17:02:08 -0000

The reason I think it is a workaround to use the jwks or jwks_uri is that
you would then wrap the x5u, x5c and/or x5t in a jwk object that you do not
really need. So the implementation needs to be aware of how to create and
read jwk even though it will not use any of the jwk data.

With that said, lets see what others think.



On Fri, Nov 11, 2016 at 10:54 PM, Brian Campbell <bcampbell@pingidentity.com
> wrote:

> From my point of view, the cleaner solution is using existing fields for
> what they are well suited rather than inventing new ones.
>
> On Fri, Nov 11, 2016 at 1:21 PM, Samuel Erdtman <samuel@erdtman.se> wrote:
>
>> You are right one could absolutely use the jwks or jwks_uri attribute,
>> but from my point of view that would be a workaround.
>> I would prefer that x5u, x5c and/or x5t was directly available in the
>> client registration request not via jwks. This would be a cleaner solution.
>>
>> Best Regards
>> Samuel
>>
>> On Fri, 11 Nov 2016 at 19:13, Brian Campbell <bcampbell@pingidentity.com>
>> wrote:
>>
>>> Wouldn't the existing jwks/jwks_uri client metadata parameters suffice?
>>> Perhaps some guidance in this document about that is warranted. But I don't
>>> believe anything new is needed for that case.
>>>
>>> On Nov 11, 2016 9:41 AM, "Samuel Erdtman" <samuel@erdtman.se> wrote:
>>>
>>> Just a quick comment, see inline
>>>
>>> On Thu, Nov 3, 2016 at 1:41 PM, Justin Richer <jricher@mit.edu> wrote:
>>>
>>> I agree that the client_id is unlikely to be found inside the
>>> certificate itself. The client_id is issued by the authorization server for
>>> the client to use at that single AS. The certificate is issued by the CA
>>> for the client to use on any connection. The AS and CA are not likely to be
>>> the same system in most deployments. The client will use the same cert
>>> across multiple connections, possibly multiple AS's, but the same isn't
>>> true of the client_id.
>>>
>>> Additionally, I think we want to allow for a binding of a self-signed
>>> certificate using dynamic registration, much the way that we already allow
>>> binding of a client-generated JWK today.
>>>
>>> Should this specification then extend the dynamic registration
>>> specification (https://tools.ietf.org/html/rfc7591) with the
>>> certificate parameter to actually do the registration or is that another
>>> document?
>>>
>>>
>>> I do think that more examples and guidance are warranted, though, to
>>> help AS developers.
>>>
>>>  -- Justin
>>>
>>> On 11/2/2016 5:03 PM, Brian Campbell wrote:
>>>
>>>
>>> On Sun, Oct 30, 2016 at 9:27 AM, Samuel Erdtman <samuel@erdtman.se>
>>> wrote:
>>>
>>>
>>> I agree it is written so that the connection to the certificate is
>>> implicitly required but I think it would be better if it was explicit
>>> written since the lack of a connection would result in a potential security
>>> hole.
>>>
>>>
>>> That's fair. I agree it can be made more explicit and that it be good to
>>> do so.
>>>
>>>
>>>
>>> When it comes to the client_id I think subject common name or maybe
>>> subject serial numbers will be the common location, and I think an example
>>> would be valuable.
>>>
>>>
>>>
>>> In my experience and the way we built support for mutual TLS OAuth
>>> client auth the client_id value does not appear in the certificate
>>> anywhere. I'm not saying it can't happen but don't think it's particularly
>>> common.
>>>
>>> I can look at adding some examples, if there's some consensus that
>>> they'd be useful and this document moves forward.
>>>
>>>
>>>
>>>
>>> I´m not saying it is a bad Idea just that I would prefer if it was not a
>>> MUST.
>>> With very limited addition of code it is just as easy to get the
>>> certificate attribute for client id as it is to get it from the HTTP
>>> request data (at least in java). I also think that with the requirement to
>>> match the incoming certificate in some way one has to read out the
>>> certificate that was used to establish the connection to do some kind of
>>> matching.
>>>
>>>
>>> Getting data out of the certificate isn't a concern. I just believe that
>>> the constancy of having the client id parameter is worth the potential
>>> small amount duplicate data in some cases. It's just a -00 draft though and
>>> if the WG wants to proceed with this document, we seek further input and
>>> work towards some consensus.
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>>
>>>
>