From nobody Mon Jan 12 18:56:33 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2532E1A89EF for ; Mon, 12 Jan 2015 18:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 jBaCmACV_vDm for ; Mon, 12 Jan 2015 18:56:29 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id CD6BA1A89B5 for ; Mon, 12 Jan 2015 18:56:29 -0800 (PST) Received: (qmail 18561 invoked by uid 0); 13 Jan 2015 02:56:22 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy9.mail.unifiedlayer.com with SMTP; 13 Jan 2015 02:56:22 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id fEwJ1p00N2UhLwi01EwMjo; Mon, 12 Jan 2015 19:56:22 -0700 X-Authority-Analysis: v=2.1 cv=BvIOn+n5 c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=DrNGYBpgUcYA:10 a=IkcTkHD0fZMA:10 a=ieNpE_y6AAAA:8 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=YNv0rlydsVwA:10 a=nS36O97Bj3wUElCrIrAA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=g3zLYH4xKxcPrHOD18z9YfpQcnk/GaJedfustWU5uGs=; b=xIZc/M25bwnYQe6lWjWd9e2iCB2W9bZ4XO3olC5uHcaUtJvcz8l37p+z0+B8pL+Bj3ZobjhPhommv/g+H0ZwUyk8WvY7KqP1pfbVw6Qd4q5GbCpWXYmJsl+nwz5GnYz8; Received: from [73.202.80.238] (port=52134 helo=[192.168.11.17]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YAreU-0001e7-Dt for unbearable@ietf.org; Mon, 12 Jan 2015 19:56:18 -0700 Message-ID: <54B4894F.7030709@KingsMountain.com> Date: Mon, 12 Jan 2015 18:56:15 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: unbearable@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [Unbearable] test pls ignore X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jan 2015 02:56:31 -0000 test From nobody Wed Jan 14 16:15:03 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5ACB1B2A81 for ; Wed, 14 Jan 2015 16:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 1lx_Ks49UjD4 for ; Wed, 14 Jan 2015 16:14:58 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0101.outbound.protection.outlook.com [65.55.169.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C83A41B2A72 for ; Wed, 14 Jan 2015 16:14:57 -0800 (PST) Received: from BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) by BN3PR0301MB1171.namprd03.prod.outlook.com (25.160.156.145) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 15 Jan 2015 00:14:56 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) with Microsoft SMTP Server (TLS) id 15.1.53.17; Thu, 15 Jan 2015 00:14:55 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0053.000; Thu, 15 Jan 2015 00:14:55 +0000 From: Andrei Popov To: "unbearable@ietf.org" Thread-Topic: Updated Charter Proposal Thread-Index: AdAwVoQybrCT+HkuTniRvdMsDdHeWg== Date: Thu, 15 Jan 2015 00:14:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:BN3PR0301MB1251; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251; x-forefront-prvs: 0457F11EAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(164054003)(199003)(19580395003)(92566002)(19300405004)(2501002)(64706001)(68736005)(16236675004)(105586002)(229853001)(2900100001)(2351001)(106356001)(2420400003)(101416001)(122556002)(102836002)(40100003)(54356999)(97736003)(46102003)(74316001)(33656002)(15975445007)(50986999)(107886001)(99286002)(87936001)(2656002)(450100001)(62966003)(77156002)(86612001)(86362001)(76576001)(19625215002)(110136001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1250BBBFD41DF30B7356F93A8C4E0BN3PR0301MB1250_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2015 00:14:54.9328 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1251 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1171; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: Subject: [Unbearable] Updated Charter Proposal X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 00:15:00 -0000 --_000_BN3PR0301MB1250BBBFD41DF30B7356F93A8C4E0BN3PR0301MB1250_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The discussion on this mailing list has subsided over the holidays, so I lo= oked through the messages for feedback regarding the proposed charter and i= ncorporated a couple of changes suggested so far: 1. A new design goal: the solution must work for Web browsers. E.g. this me= ans that security tokens must be presentable over multiple TLS sessions and= connections. 2. Removed specific milestone dates. Looking forward to more discussion of the charter, Thanks, Andrei _____________________________________________________ Token Binding (TB) Charter for Working Group Web services generate various security tokens (e.g. HTTP cookies, OAuth to= kens, etc.) for web applications to access protected resources. Currently t= hese are bearer tokens, i.e. any party in possession of such token gains ac= cess to the protected resource. Attackers export bearer tokens from client = machines or from compromised network connections, present these bearer toke= ns to Web services, and impersonate authenticated users. The idea of Token = Binding is to enable defense against such attacks by cryptographically bind= ing security tokens to the TLS layer. The tasks of this working group are as follows: 1. Specify the Token Binding protocol v1.0. 2. Specify the use of the Token Binding protocol in combination = with HTTPS. It is a goal of this working group to enable defense against attacks that i= nvolve unauthorized replay of security tokens, but other issues associated = with the use of security tokens are out of scope. It is a goal of this work= ing group to design the Token Binding protocol such that it would be also u= seable with application protocols other than HTTPS, however specifying such= uses is not a primary goal. Some of the main design goals for the Token Binding protocol, in no particu= lar order: 1. Prevent export and replay of security tokens. 2. Allow strong key protection, e.g. using hardware-bound keys. 3. Support both first-party and federation scenarios. 4. Preserve user privacy. 5. Make the Token Binding protocol useable in combination with a= variety of application protocols. 6. Allow the negotiation of the Token Binding protocol without a= dditional round-trips. 7. Allow the use of multiple cryptographic algorithms, so that a= variety of secure hardware modules with different cryptographic capabiliti= es could be used with Token Binding. 8. Propose Token Binding spec that can be implemented in Web bro= wsers (but is not limited to them). E.g. Web browsers require that the same= bound security token must be presentable over multiple TLS sessions and co= nnections. The working group will use the following documents as a starting point for = its work: - draft-popov-token-binding-00; - draft-balfanz-https-token-binding-00. This WG will collaborate with other IETF WGs, in particular with the TLS, H= TTPbis and Oauth WGs. Milestones: - WG document for the Token Binding Protocol v1.0. - WG document for HTTPS Token Binding. - Token Binding Protocol v1.0 to IESG. - HTTPS Token Binding to IESG. --_000_BN3PR0301MB1250BBBFD41DF30B7356F93A8C4E0BN3PR0301MB1250_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The discussion on this mailing list has subsided ove= r the holidays, so I looked through the messages for feedback regarding the= proposed charter and incorporated a couple of changes suggested so far:

1. A new design goal: the solution must work for = Web browsers. E.g. this means that security tokens must be presentable over= multiple TLS sessions and connections.

2. Removed specific milestone dates.

 

Looking forward to more discussion of the charter,

 

Thanks,

 

Andrei

 

____________________________________________________= _

Token Binding (TB)

 

Charter for Working Group

 

Web services generate various security tokens (e.g.&= nbsp; HTTP cookies, OAuth tokens, etc.) for web applications to access prot= ected resources. Currently these are bearer tokens, i.e. any party in posse= ssion of such token gains access to the protected resource. Attackers export bearer tokens from client machines or= from compromised network connections, present these bearer tokens to Web s= ervices, and impersonate authenticated users. The idea of Token Binding is = to enable defense against such attacks by cryptographically binding security tokens to the TLS layer.<= /p>

 

The tasks of this working group are as follows:=

1.        &n= bsp;   Specify the Token Binding protocol v1.0.

2.        &n= bsp;   Specify the use of the Token Binding protocol in combinati= on with HTTPS.

 

It is a goal of this working group to enable defense= against attacks that involve unauthorized replay of security tokens, but o= ther issues associated with the use of security tokens are out of scope. It= is a goal of this working group to design the Token Binding protocol such that it would be also useable with = application protocols other than HTTPS, however specifying such uses is not= a primary goal.

 

Some of the main design goals for the Token Binding = protocol, in no particular order:

1.        &n= bsp;   Prevent export and replay of security tokens.

2.        &n= bsp;   Allow strong key protection, e.g. using hardware-bound key= s.

3.        &n= bsp;   Support both first-party and federation scenarios.

4.        &n= bsp;   Preserve user privacy.

5.        &n= bsp;   Make the Token Binding protocol useable in combination wit= h a variety of application protocols.

6.        &n= bsp;   Allow the negotiation of the Token Binding protocol withou= t additional round-trips.

7.        &n= bsp;   Allow the use of multiple cryptographic algorithms, so tha= t a variety of secure hardware modules with different cryptographic capabil= ities could be used with Token Binding.

8.        &n= bsp;   Propose Token Binding spec that can be implemented in Web = browsers (but is not limited to them). E.g. Web browsers require that the s= ame bound security token must be presentable over multiple TLS sessions and= connections.

 

The working group will use the following documents a= s a starting point for its work:

-        &nb= sp;    draft-popov-token-binding-00;

-        &nb= sp;    draft-balfanz-https-token-binding-00.

 

This WG will collaborate with other IETF WGs, in par= ticular with the TLS, HTTPbis and Oauth WGs.

 

Milestones:

-        &nb= sp;   WG document for the Token Binding Protocol v1.0.=

-        &nb= sp;   WG document for HTTPS Token Binding.

-        &nb= sp;   Token Binding Protocol v1.0 to IESG.

-        &nb= sp;   HTTPS Token Binding to IESG.

--_000_BN3PR0301MB1250BBBFD41DF30B7356F93A8C4E0BN3PR0301MB1250_-- From nobody Thu Jan 15 00:27:04 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 451CA1B2BB2 for ; Thu, 15 Jan 2015 00:27:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.79 X-Spam-Level: X-Spam-Status: No, score=0.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 WucEYSEE-CME for ; Thu, 15 Jan 2015 00:27:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CB601B2BB0 for ; Thu, 15 Jan 2015 00:27:00 -0800 (PST) Received: from [192.168.131.148] ([80.92.123.55]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LbMmA-1XVQCS2v7a-00kyo1; Thu, 15 Jan 2015 09:26:55 +0100 Message-ID: <54B779CC.9040201@gmx.net> Date: Thu, 15 Jan 2015 09:26:52 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Andrei Popov , "unbearable@ietf.org" References: In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="k0Q3f0uINwtiXqKwEk5HCIn7BTup2I0qX" X-Provags-ID: V03:K0:CP9PlE4C+6W2/0mrHbiNLjddszbA6WPu4YAlIzoNZbBOPIgtRWR +fw6o6PnT7kzt8N/muvZuY+z+NausJl2mJrJB699A0trXUHNuCxgZq0qu0BOAaFHWkjFtXe uGWSh3hTqls/3NjIZB7cCgUTmHeH5H9Ll/Zca5T+b+m6yBZTXj8m5LPU3s4zsxouLHpxIuz nH4gSP4BI9/BFdLCHsbyg== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [Unbearable] Updated Charter Proposal X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 08:27:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --k0Q3f0uINwtiXqKwEk5HCIn7BTup2I0qX Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Andrei, the questions regarding the charter I have are the following. Why does the charter need to say already that your specific solution will be the one worked on. There are other solution approaches possible. For example, there are various ways in which the proof of possession could be demonstrated in TLS (and proposals have been made in the past). There also have been suggestions on alternative ways to obtain the token as well, which are better integrated with existing protocols. I also don't know whether you had a chance to look at draft-ietf-oauth-pop-architecture-00 since in earlier discussions there were concerns that the the token binding in TLS is insufficient for a number of scenarios. For example, when you want to provide end-to-end security where TLS is terminated at load balancers. Ciao Hannes On 01/15/2015 01:14 AM, Andrei Popov wrote: > The discussion on this mailing list has subsided over the holidays, so = I > looked through the messages for feedback regarding the proposed charter= > and incorporated a couple of changes suggested so far: >=20 > 1. A new design goal: the solution must work for Web browsers. E.g. thi= s > means that security tokens must be presentable over multiple TLS > sessions and connections. >=20 > 2. Removed specific milestone dates. >=20 > =20 >=20 > Looking forward to more discussion of the charter, >=20 > =20 >=20 > Thanks, >=20 > =20 >=20 > Andrei >=20 > =20 >=20 > _____________________________________________________ >=20 > Token Binding (TB) >=20 > =20 >=20 > Charter for Working Group >=20 > =20 >=20 > Web services generate various security tokens (e.g. HTTP cookies, OAut= h > tokens, etc.) for web applications to access protected resources. > Currently these are bearer tokens, i.e. any party in possession of such= > token gains access to the protected resource. Attackers export bearer > tokens from client machines or from compromised network connections, > present these bearer tokens to Web services, and impersonate > authenticated users. The idea of Token Binding is to enable defense > against such attacks by cryptographically binding security tokens to th= e > TLS layer. >=20 > =20 >=20 > The tasks of this working group are as follows: >=20 > 1. Specify the Token Binding protocol v1.0. >=20 > 2. Specify the use of the Token Binding protocol in > combination with HTTPS. >=20 > =20 >=20 > It is a goal of this working group to enable defense against attacks > that involve unauthorized replay of security tokens, but other issues > associated with the use of security tokens are out of scope. It is a > goal of this working group to design the Token Binding protocol such > that it would be also useable with application protocols other than > HTTPS, however specifying such uses is not a primary goal. >=20 > =20 >=20 > Some of the main design goals for the Token Binding protocol, in no > particular order: >=20 > 1. Prevent export and replay of security tokens. >=20 > 2. Allow strong key protection, e.g. using hardware-bound ke= ys. >=20 > 3. Support both first-party and federation scenarios. >=20 > 4. Preserve user privacy. >=20 > 5. Make the Token Binding protocol useable in combination > with a variety of application protocols. >=20 > 6. Allow the negotiation of the Token Binding protocol > without additional round-trips. >=20 > 7. Allow the use of multiple cryptographic algorithms, so > that a variety of secure hardware modules with different cryptographic > capabilities could be used with Token Binding. >=20 > 8. Propose Token Binding spec that can be implemented in Web= > browsers (but is not limited to them). E.g. Web browsers require that > the same bound security token must be presentable over multiple TLS > sessions and connections. >=20 > =20 >=20 > The working group will use the following documents as a starting point > for its work: >=20 > - draft-popov-token-binding-00; >=20 > - draft-balfanz-https-token-binding-00. >=20 > =20 >=20 > This WG will collaborate with other IETF WGs, in particular with the > TLS, HTTPbis and Oauth WGs. >=20 > =20 >=20 > Milestones: >=20 > - WG document for the Token Binding Protocol v1.0. >=20 > - WG document for HTTPS Token Binding. >=20 > - Token Binding Protocol v1.0 to IESG. >=20 > - HTTPS Token Binding to IESG. >=20 >=20 >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable >=20 --k0Q3f0uINwtiXqKwEk5HCIn7BTup2I0qX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUt3nMAAoJEGhJURNOOiAtGQUIAID2eQZ402LksumM2tbOWSF9 68s+x3PR3lqTlhx+Ex+1Cqe3Rup3Rd0djrHKsGQZZnqShEybHPT7TzKjhd9jbhwV jgutDH6Ty/4SavPIeoDAZDafo8JVQGfJbZVR3dVR2Sm22/wDcPgMIVvFOwHwAnNg rHCBXyp0iuZRxBX1hrX3WNNd5Ow3OCW/W6rPW73taypGrRv5DYywmDG1k/zQ15TC gzNonFCvqJTlH4LeOqrRHlEXMYxlRXQ+j1GCTONuBGk9e/T3CRciwrjrrNSt4S/Z eGTQadQzlUrIGg4MD5P/pDBYMnGOHpcFZ6p4frgpwNiU1wkVW5h9j/Do3ALZGrQ= =XZuV -----END PGP SIGNATURE----- --k0Q3f0uINwtiXqKwEk5HCIn7BTup2I0qX-- From nobody Thu Jan 15 06:44:40 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CD11B2C02 for ; Thu, 15 Jan 2015 06:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 DmzeCWd1zpSs for ; Thu, 15 Jan 2015 06:44:36 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 569191B2BFF for ; Thu, 15 Jan 2015 06:44:36 -0800 (PST) Received: from [79.195.189.209] by 3capp-gmx-bs23.server.lan (via HTTP); Thu, 15 Jan 2015 15:44:34 +0100 MIME-Version: 1.0 Message-ID: From: D.Rogers@gmx.net To: "Andrei Popov" Content-Type: text/html; charset=UTF-8 Date: Thu, 15 Jan 2015 15:44:34 +0100 Importance: normal Sensitivity: Normal In-Reply-To: References: X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:d1FVJJls1DwjGRba/ZcpNV9YMXHn9rLGCpTsQoatcoj 6evX9wZOs2t5+7E36FM7HBMvAZOPi3Kv0qgjqINJ/QLdMIh3wS pJpJ/lCHlicNx814XL8u1R/FMx+GdLCekV9p2I707q0aFYSOo1 2YSW6RcIxUv89Mid++L7MZotApcLsVPG+9dOAI1VrYs5CZGM5U UiZmbLTO+M3/HNSNfTqRHDIWrpDgtA5bInlJXuemHzyhIV0ikn rQ6J9KpndGVoIvRBs9Q9ULQV5/Oeg5eYN8HdLPriBqPcTpsyR+ Uszkz0= X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] Updated Charter Proposal X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 14:44:38 -0000
Hi Andrei,
 
indeed, discussion went so quite over the holiday period that I check I was still listed in the group.
 
regarding your proposals.
 
1. design goals to facilitate multiple TLS connections for browser based application.
Fully Agree. Although I am a fan of security connections at lower stack levels, ie IPSec, I realise this is not always convenient, so TLS is the way to go.
 
2. remove milestones.
Fully agree. Since the remit of te group is still developing, setting milestones at this stage seems premature.
 
best wishes
Dean
Gesendet: Donnerstag, 15. Januar 2015 um 01:14 Uhr
Von: "Andrei Popov" <Andrei.Popov@microsoft.com>
An: "unbearable@ietf.org" <unbearable@ietf.org>
Betreff: [Unbearable] Updated Charter Proposal

The discussion on this mailing list has subsided over the holidays, so I looked through the messages for feedback regarding the proposed charter and incorporated a couple of changes suggested so far:

1. A new design goal: the solution must work for Web browsers. E.g. this means that security tokens must be presentable over multiple TLS sessions and connections.

2. Removed specific milestone dates.

 

Looking forward to more discussion of the charter,

 

Thanks,

 

Andrei

 

_____________________________________________________

Token Binding (TB)

 

Charter for Working Group

 

Web services generate various security tokens (e.g.  HTTP cookies, OAuth tokens, etc.) for web applications to access protected resources. Currently these are bearer tokens, i.e. any party in possession of such token gains access to the protected resource. Attackers export bearer tokens from client machines or from compromised network connections, present these bearer tokens to Web services, and impersonate authenticated users. The idea of Token Binding is to enable defense against such attacks by cryptographically binding security tokens to the TLS layer.

 

The tasks of this working group are as follows:

1.            Specify the Token Binding protocol v1.0.

2.            Specify the use of the Token Binding protocol in combination with HTTPS.

 

It is a goal of this working group to enable defense against attacks that involve unauthorized replay of security tokens, but other issues associated with the use of security tokens are out of scope. It is a goal of this working group to design the Token Binding protocol such that it would be also useable with application protocols other than HTTPS, however specifying such uses is not a primary goal.

 

Some of the main design goals for the Token Binding protocol, in no particular order:

1.            Prevent export and replay of security tokens.

2.            Allow strong key protection, e.g. using hardware-bound keys.

3.            Support both first-party and federation scenarios.

4.            Preserve user privacy.

5.            Make the Token Binding protocol useable in combination with a variety of application protocols.

6.            Allow the negotiation of the Token Binding protocol without additional round-trips.

7.            Allow the use of multiple cryptographic algorithms, so that a variety of secure hardware modules with different cryptographic capabilities could be used with Token Binding.

8.            Propose Token Binding spec that can be implemented in Web browsers (but is not limited to them). E.g. Web browsers require that the same bound security token must be presentable over multiple TLS sessions and connections.

 

The working group will use the following documents as a starting point for its work:

-             draft-popov-token-binding-00;

-             draft-balfanz-https-token-binding-00.

 

This WG will collaborate with other IETF WGs, in particular with the TLS, HTTPbis and Oauth WGs.

 

Milestones:

-            WG document for the Token Binding Protocol v1.0.

-            WG document for HTTPS Token Binding.

-            Token Binding Protocol v1.0 to IESG.

-            HTTPS Token Binding to IESG.

_______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable
From nobody Thu Jan 15 09:24:42 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D8C1B2E6F for ; Thu, 15 Jan 2015 09:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 J09hsCYBquwI for ; Thu, 15 Jan 2015 09:24:38 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C20D1B2E57 for ; Thu, 15 Jan 2015 09:24:38 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id w8so11195680qac.13 for ; Thu, 15 Jan 2015 09:24:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=qZVjHlZ1iTQVQaMOBwfYqOFkuLggMk7kceYHarIp+0g=; b=K989ekwMpt1SRdeZVyt81LO+QiYH7nRk8y9itep82NpWap+2sXaa+xreUPoPMA8cS4 ROTQ6US6Naog3iLKUuyFDx6bZpW26P+HTmQ5AjUqE74M0lhDWiMIe2Ou3bUze0glqUWe HBQ5FnjezicP6lutiLHLfdOvBELAyWalero6gS/7122cZFtNB7CYzSPGTNXKJNS0swNH MQND5oQowHXd3PYO+tZ+6oKAQZUvV1Oq1IqIZ4oJBVjDh1TcIrmq9etMuV/l8t/iPuoT eVWBi2MPzFwqYvtBOW0ZQdwufacyVIBgRo5ziPmgTNKKPHFBPvNFop8+u2hwijElJwDA m3WA== X-Gm-Message-State: ALoCoQn5BCwk1QHwOpw84oF2T+RnvSrqdCwzIgT4DLVhRfGPhXM6N4t8OC/E9spB1t1HM5ERcYv9 X-Received: by 10.140.17.70 with SMTP id 64mr16798775qgc.53.1421342677151; Thu, 15 Jan 2015 09:24:37 -0800 (PST) Received: from [192.168.8.100] ([186.65.149.253]) by mx.google.com with ESMTPSA id y2sm1837686qaj.3.2015.01.15.09.24.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Jan 2015 09:24:36 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_CD4A48C1-A29E-4B9B-8878-C260D13E85F7"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: John Bradley In-Reply-To: Date: Thu, 15 Jan 2015 14:24:30 -0300 Message-Id: References: To: Andrei Popov X-Mailer: Apple Mail (2.1993) Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] Updated Charter Proposal X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 17:24:41 -0000 --Apple-Mail=_CD4A48C1-A29E-4B9B-8878-C260D13E85F7 Content-Type: multipart/alternative; boundary="Apple-Mail=_762064BA-0C91-4ACB-AFA3-0212BFAE1286" --Apple-Mail=_762064BA-0C91-4ACB-AFA3-0212BFAE1286 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am generally in agrement. A couple of points. Under design goals change 1 to. 1. Allow applications to prevent the export and replay of security = tokens. You could make that applications and protocols if you like as some = people may see things like OAuth as a protocol vs an application.=20 The point being that the goal is to provide the hooks for things a layer = above these specifications to make security decisions, not the token = binding protocol itself. In 3 you use the term federation. That may be larger in scope than what = I think you intend from the two drafts. Federation is a much larger topic than allowing the public key from one = connection to be exposed in a connection to a second party via some sort = of express consent from the first party. Shrinking the scope to how public keys may be shared with permission to = third parties may make some people more comfortable, if they are = concerned that this is trying to be a new federation protocol to compete = with SAML or OAuth. Regards John B. > On Jan 14, 2015, at 9:14 PM, Andrei Popov = wrote: >=20 > The discussion on this mailing list has subsided over the holidays, so = I looked through the messages for feedback regarding the proposed = charter and incorporated a couple of changes suggested so far: > 1. A new design goal: the solution must work for Web browsers. E.g. = this means that security tokens must be presentable over multiple TLS = sessions and connections. > 2. Removed specific milestone dates. > =20 > Looking forward to more discussion of the charter, > =20 > Thanks, > =20 > Andrei > =20 > _____________________________________________________ > Token Binding (TB) > =20 > Charter for Working Group > =20 > Web services generate various security tokens (e.g. HTTP cookies, = OAuth tokens, etc.) for web applications to access protected resources. = Currently these are bearer tokens, i.e. any party in possession of such = token gains access to the protected resource. Attackers export bearer = tokens from client machines or from compromised network connections, = present these bearer tokens to Web services, and impersonate = authenticated users. The idea of Token Binding is to enable defense = against such attacks by cryptographically binding security tokens to the = TLS layer. > =20 > The tasks of this working group are as follows: > 1. Specify the Token Binding protocol v1.0. > 2. Specify the use of the Token Binding protocol in = combination with HTTPS. > =20 > It is a goal of this working group to enable defense against attacks = that involve unauthorized replay of security tokens, but other issues = associated with the use of security tokens are out of scope. It is a = goal of this working group to design the Token Binding protocol such = that it would be also useable with application protocols other than = HTTPS, however specifying such uses is not a primary goal. > =20 > Some of the main design goals for the Token Binding protocol, in no = particular order: > 1. Prevent export and replay of security tokens. > 2. Allow strong key protection, e.g. using hardware-bound = keys. > 3. Support both first-party and federation scenarios. > 4. Preserve user privacy. > 5. Make the Token Binding protocol useable in combination = with a variety of application protocols. > 6. Allow the negotiation of the Token Binding protocol = without additional round-trips. > 7. Allow the use of multiple cryptographic algorithms, so = that a variety of secure hardware modules with different cryptographic = capabilities could be used with Token Binding. > 8. Propose Token Binding spec that can be implemented in = Web browsers (but is not limited to them). E.g. Web browsers require = that the same bound security token must be presentable over multiple TLS = sessions and connections. > =20 > The working group will use the following documents as a starting point = for its work: > - draft-popov-token-binding-00; > - draft-balfanz-https-token-binding-00. > =20 > This WG will collaborate with other IETF WGs, in particular with the = TLS, HTTPbis and Oauth WGs. > =20 > Milestones: > - WG document for the Token Binding Protocol v1.0. > - WG document for HTTPS Token Binding. > - Token Binding Protocol v1.0 to IESG. > - HTTPS Token Binding to IESG. > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable = --Apple-Mail=_762064BA-0C91-4ACB-AFA3-0212BFAE1286 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I am generally in agrement.

A couple of points.

Under design goals = change 1 to.

1. =   Allow applications to prevent the export and replay of security = tokens.

You = could make that applications and protocols if you like as some people = may see things like OAuth as a protocol vs an = application. 
The point being that the goal is = to provide the hooks for things a layer above these specifications to = make security decisions, not the token binding protocol = itself.


In 3 you use the term federation. =  That may be larger in scope than what I think you intend from the = two drafts.
Federation is a much larger topic than = allowing the public key from one connection to be exposed in a = connection to a second party via some sort of express consent from the = first party.

Shrinking the scope to how public keys may be shared with = permission to third parties may make some people more comfortable, if = they are concerned that this is trying to be a new federation protocol = to compete with SAML or OAuth.

Regards
John = B.

On = Jan 14, 2015, at 9:14 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

The = discussion on this mailing list has subsided over the holidays, so I = looked through the messages for feedback regarding the proposed charter = and incorporated a couple of changes suggested so far:
1. A new = design goal: the solution must work for Web browsers. E.g. this means = that security tokens must be presentable over multiple TLS sessions and = connections.
2. Removed specific milestone dates.
 
Looking = forward to more discussion of the charter,
 
Thanks,
 
Andrei
 
_____________________________________________________
Token = Binding (TB)
 
Charter for Working Group
 
Web services generate various security = tokens (e.g.  HTTP cookies, OAuth tokens, etc.) for web = applications to access protected resources. Currently these are bearer = tokens, i.e. any party in possession of such token gains access to the = protected resource. Attackers export bearer tokens from client machines = or from compromised network connections, present these bearer tokens to = Web services, and impersonate authenticated users. The idea of Token = Binding is to enable defense against such attacks by cryptographically = binding security tokens to the TLS layer.
 
The tasks of this working group are as = follows:
1.          &= nbsp; Specify the Token Binding protocol v1.0.
2.          &= nbsp; Specify the use of the Token Binding protocol in combination with = HTTPS.
 
It is a goal of this working group to enable defense against = attacks that involve unauthorized replay of security tokens, but other = issues associated with the use of security tokens are out of scope. It = is a goal of this working group to design the Token Binding protocol = such that it would be also useable with application protocols other than = HTTPS, however specifying such uses is not a primary goal.
 
Some of = the main design goals for the Token Binding protocol, in no particular = order:
1.          &= nbsp; Prevent export and replay of security tokens.
2.          &= nbsp; Allow strong key protection, e.g. using hardware-bound keys.
3.          &= nbsp; Support both first-party and federation scenarios.
4.          &= nbsp; Preserve user privacy.
5.          &= nbsp; Make the Token Binding protocol useable in combination with a = variety of application protocols.
6.          &= nbsp; Allow the negotiation of the Token Binding protocol without = additional round-trips.
7.          &= nbsp; Allow the use of multiple cryptographic algorithms, so that a = variety of secure hardware modules with different cryptographic = capabilities could be used with Token Binding.
8.          &= nbsp; Propose Token Binding spec that can be implemented in Web browsers = (but is not limited to them). E.g. Web browsers require that the same = bound security token must be presentable over multiple TLS sessions and = connections.
 
The working group will use the following documents as a = starting point for its work:
-          &n= bsp;  draft-popov-token-binding-00;
-          &n= bsp;  draft-balfanz-https-token-binding-00.
 
This WG = will collaborate with other IETF WGs, in particular with the TLS, = HTTPbis and Oauth WGs.
 
Milestones:
-          &n= bsp; WG document for the Token Binding Protocol v1.0.
-          &n= bsp; WG document for HTTPS Token Binding.
-          &n= bsp; Token Binding Protocol v1.0 to IESG.
-          &n= bsp; HTTPS Token Binding to IESG.
_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable

= --Apple-Mail=_762064BA-0C91-4ACB-AFA3-0212BFAE1286-- --Apple-Mail=_CD4A48C1-A29E-4B9B-8878-C260D13E85F7 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2 F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w 4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3 BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+ VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt 1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNTAxMTUxNzI0MzJaMCMGCSqGSIb3DQEJBDEWBBTh1F1xkiV3j/mEgUKsigf1 sHJy/jCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN BgkqhkiG9w0BAQEFAASCAQBYNfSkdwD43csXDoYkMb6wrxgNgQKHezyCC4aM3A/lfgvOoUCFri2R BgMsmwRAzapiUaLNHj29ouqGHgN3tPm3VRUn2rAWXKkbV/R3S/iwM6MfwFXijhvvtU07/di8ET34 xC9VMaVy0e3eafyvOdtZpNuBZa5dyv1zJcTgjIg1YNHsU07Y1TV1UrMqeOutuueu5/n6emRT+pVl LFqhAUo8Ewsxi+q4tcjEB5tO0e4XHWJuCK0UFDsOccJHZk+w8XMuMLPzRTFqLFqU3Qnb6qGOxwVB ESemOdPTbfdgg/C5gRB6ezhSXAOoRWHBed6gLVm/aI+e8S+A4Gmoc7cCnF+5AAAAAAAA --Apple-Mail=_CD4A48C1-A29E-4B9B-8878-C260D13E85F7-- From nobody Thu Jan 15 09:39:44 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6F51B2EEA for ; Thu, 15 Jan 2015 09:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yN_jN2wsu6pr for ; Thu, 15 Jan 2015 09:39:33 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF12B1B2F06 for ; Thu, 15 Jan 2015 09:39:27 -0800 (PST) Received: from [192.168.131.148] ([80.92.123.55]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MCtql-1Y29M62X2p-009j6I; Thu, 15 Jan 2015 18:39:25 +0100 Message-ID: <54B7FB4C.5050909@gmx.net> Date: Thu, 15 Jan 2015 18:39:24 +0100 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Andrei Popov References: In-Reply-To: OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LJsSMNKgfHN8dGuW5DCPdjjQh8J2VOctR" X-Provags-ID: V03:K0:n5JRlWFfY3rDQ69v8CcRaBwX9K69e1CnVeAH18hatc57PoKNk1h ly9wSCjeRrp03UlJ1+O80fYUSanhX54buTK2NFT0CYxgyGLHyyE7frvacWIruB8ou+CFw0c XWmlZ7FA82uxOHSZlPR9H9J6Qe4JYaacYIf9R0f/VVMxZwWWyKE+Z5JLRiBnuhwiI3AYm0x AGNtYGnJuKpQaPolLlkzQ== X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] Updated Charter Proposal X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 17:39:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --LJsSMNKgfHN8dGuW5DCPdjjQh8J2VOctR Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Andrei, > A new design goal: the solution must work for Web browsers. E.g. this > means that security tokens must be presentable over multiple TLS > sessions and connections. Could you explain what motivated this design goal? What would prevent you from using tokens over more than one TLS exchange? Is there a specific use case you have in mind? Ciao Hannes --LJsSMNKgfHN8dGuW5DCPdjjQh8J2VOctR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJUt/tMAAoJEGhJURNOOiAtWvsH/2SS9bhl/x2NiFM7FELZgkJ2 hwsy80L3x6a1n8pKA0Td5V99ZLSoQSBUuiGZOWOE7Yhcj9eWc4Fh/LUHXa9MWb7g wUC1dkkFUIwHqDr0lNlkXm53VU6geoi8QOVSKV3/nv1DyB/juOtyENYbArpEBNY7 WhCAAiWY23ShGEtP1vEMkNNAGXOBMmWIC44f9Gb9GHbB5uI5duTfEkJygfmE6/hN qtOOvlYYfFX2ZEBsYZ0kzgHM27SspibT3VCZiU8yhwpohSa8xx1vh15JC6bhJLRl R5crTp9M3+jstPc4j+Z2Y43Y7ylIn48j1hjz6VVi7D+RzFlR/t7jLGDazvCCd94= =DI3Y -----END PGP SIGNATURE----- --LJsSMNKgfHN8dGuW5DCPdjjQh8J2VOctR-- From nobody Thu Jan 15 10:53:03 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74EE71B2F88 for ; Thu, 15 Jan 2015 10:53:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 0l1CwFXLq8rx for ; Thu, 15 Jan 2015 10:52:59 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0133.outbound.protection.outlook.com [65.55.169.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F9D1B3000 for ; Thu, 15 Jan 2015 10:52:58 -0800 (PST) Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 15 Jan 2015 18:52:55 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0059.007; Thu, 15 Jan 2015 18:52:55 +0000 From: Andrei Popov To: John Bradley Thread-Topic: [Unbearable] Updated Charter Proposal Thread-Index: AdAwVoQybrCT+HkuTniRvdMsDdHeWgAkZqIAAAL3ZlA= Date: Thu, 15 Jan 2015 18:52:55 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN3PR0301MB1250; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1250; x-forefront-prvs: 0457F11EAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(199003)(24454002)(189002)(377454003)(122556002)(101416001)(54206007)(2420400003)(2950100001)(76576001)(54606007)(19625215002)(19300405004)(33656002)(19580395003)(561944003)(19580405001)(68736005)(62966003)(77156002)(40100003)(19617315012)(2900100001)(15975445007)(102836002)(50986999)(99286002)(46102003)(105586002)(110136001)(106356001)(64706001)(54356999)(76176999)(86612001)(2656002)(86362001)(87936001)(92566002)(19609705001)(16236675004)(74316001)(97736003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1250; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1250604C8F185D3A080A416D8C4E0BN3PR0301MB1250_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2015 18:52:55.8639 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1250 Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] Updated Charter Proposal X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 18:53:02 -0000 --_000_BN3PR0301MB1250604C8F185D3A080A416D8C4E0BN3PR0301MB1250_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks John; both suggestions make sense to me; will rephrase in the next r= evision. Cheers, Andrei From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Thursday, January 15, 2015 9:25 AM To: Andrei Popov Cc: unbearable@ietf.org Subject: Re: [Unbearable] Updated Charter Proposal I am generally in agrement. A couple of points. Under design goals change 1 to. 1. Allow applications to prevent the export and replay of security tokens= . You could make that applications and protocols if you like as some people m= ay see things like OAuth as a protocol vs an application. The point being that the goal is to provide the hooks for things a layer ab= ove these specifications to make security decisions, not the token binding = protocol itself. In 3 you use the term federation. That may be larger in scope than what I = think you intend from the two drafts. Federation is a much larger topic than allowing the public key from one con= nection to be exposed in a connection to a second party via some sort of ex= press consent from the first party. Shrinking the scope to how public keys may be shared with permission to thi= rd parties may make some people more comfortable, if they are concerned tha= t this is trying to be a new federation protocol to compete with SAML or OA= uth. Regards John B. On Jan 14, 2015, at 9:14 PM, Andrei Popov > wrote: The discussion on this mailing list has subsided over the holidays, so I lo= oked through the messages for feedback regarding the proposed charter and i= ncorporated a couple of changes suggested so far: 1. A new design goal: the solution must work for Web browsers. E.g. this me= ans that security tokens must be presentable over multiple TLS sessions and= connections. 2. Removed specific milestone dates. Looking forward to more discussion of the charter, Thanks, Andrei _____________________________________________________ Token Binding (TB) Charter for Working Group Web services generate various security tokens (e.g. HTTP cookies, OAuth to= kens, etc.) for web applications to access protected resources. Currently t= hese are bearer tokens, i.e. any party in possession of such token gains ac= cess to the protected resource. Attackers export bearer tokens from client = machines or from compromised network connections, present these bearer toke= ns to Web services, and impersonate authenticated users. The idea of Token = Binding is to enable defense against such attacks by cryptographically bind= ing security tokens to the TLS layer. The tasks of this working group are as follows: 1. Specify the Token Binding protocol v1.0. 2. Specify the use of the Token Binding protocol in combination = with HTTPS. It is a goal of this working group to enable defense against attacks that i= nvolve unauthorized replay of security tokens, but other issues associated = with the use of security tokens are out of scope. It is a goal of this work= ing group to design the Token Binding protocol such that it would be also u= seable with application protocols other than HTTPS, however specifying such= uses is not a primary goal. Some of the main design goals for the Token Binding protocol, in no particu= lar order: 1. Prevent export and replay of security tokens. 2. Allow strong key protection, e.g. using hardware-bound keys. 3. Support both first-party and federation scenarios. 4. Preserve user privacy. 5. Make the Token Binding protocol useable in combination with a= variety of application protocols. 6. Allow the negotiation of the Token Binding protocol without a= dditional round-trips. 7. Allow the use of multiple cryptographic algorithms, so that a= variety of secure hardware modules with different cryptographic capabiliti= es could be used with Token Binding. 8. Propose Token Binding spec that can be implemented in Web bro= wsers (but is not limited to them). E.g. Web browsers require that the same= bound security token must be presentable over multiple TLS sessions and co= nnections. The working group will use the following documents as a starting point for = its work: - draft-popov-token-binding-00; - draft-balfanz-https-token-binding-00. This WG will collaborate with other IETF WGs, in particular with the TLS, H= TTPbis and Oauth WGs. Milestones: - WG document for the Token Binding Protocol v1.0. - WG document for HTTPS Token Binding. - Token Binding Protocol v1.0 to IESG. - HTTPS Token Binding to IESG. _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable --_000_BN3PR0301MB1250604C8F185D3A080A416D8C4E0BN3PR0301MB1250_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks John; both suggestions make se= nse to me; will rephrase in the next revision.

 

Cheers,

 

Andrei

 

From: John Bradley [mailto:ve7jtb@ve= 7jtb.com]
Sent: Thursday, January 15, 2015 9:25 AM
To: Andrei Popov
Cc: unbearable@ietf.org
Subject: Re: [Unbearable] Updated Charter Proposal=

 

I am generally in agrement.

 

A couple of points.

 

Under design goals change 1 to.

 

1.   Allow applications to prevent the export a= nd replay of security tokens.

 

You could make that applications and protocols if yo= u like as some people may see things like OAuth as a protocol vs an applica= tion. 

The point being that the goal is to provide the hook= s for things a layer above these specifications to make security decisions,= not the token binding protocol itself.

 

 

In 3 you use the term federation.  That may be = larger in scope than what I think you intend from the two drafts.

Federation is a much larger topic than allowing the = public key from one connection to be exposed in a connection to a second pa= rty via some sort of express consent from the first party.

 

Shrinking the scope to how public keys may be shared= with permission to third parties may make some people more comfortable, if= they are concerned that this is trying to be a new federation protocol to = compete with SAML or OAuth.

 

Regards

John B.

 

On Jan 14, 2015, at 9:14 PM, Andrei Popov <Andrei.Popov@microsoft.com> = wrote:

 

The discussion on this mailing list has subsided ov= er the holidays, so I looked through the messages for feedback regarding th= e proposed charter and incorporated a couple of changes suggested so far:

1. A new design goal: the solution must work for We= b browsers. E.g. this means that security tokens must be presentable over m= ultiple TLS sessions and connections.

2. Removed specific milestone dates.

 

Looking forward to more discussion of the charter,<= o:p>

 

Thanks,

 

Andrei

 

___________________________________________________= __

Token Binding (TB)

 

Charter for Working Group

 

Web services generate various security tokens (e.g.=   HTTP cookies, OAuth tokens, etc.) for web applications to access pro= tected resources. Currently these are bearer tokens, i.e. any party in possession of such token gains access to the protected r= esource. Attackers export bearer tokens from client machines or from compro= mised network connections, present these bearer tokens to Web services, and= impersonate authenticated users. The idea of Token Binding is to enable defense against such attacks by cry= ptographically binding security tokens to the TLS layer.<= /p>

 

The tasks of this working group are as follows:

1.        &= nbsp;   Specify the Token Binding protocol v1.0.

2.        &= nbsp;   Specify the use of the Token Binding protocol in combinat= ion with HTTPS.

 

It is a goal of this working group to enable defens= e against attacks that involve unauthorized replay of security tokens, but = other issues associated with the use of security tokens are out of scope. It is a goal of this working group to design the = Token Binding protocol such that it would be also useable with application = protocols other than HTTPS, however specifying such uses is not a primary g= oal.

 

Some of the main design goals for the Token Binding= protocol, in no particular order:

1.        &= nbsp;   Prevent export and replay of security tokens.<= /span>

2.        &= nbsp;   Allow strong key protection, e.g. using hardware-bound ke= ys.

3.        &= nbsp;   Support both first-party and federation scenarios.

4.        &= nbsp;   Preserve user privacy.

5.        &= nbsp;   Make the Token Binding protocol useable in combination wi= th a variety of application protocols.

6.        &= nbsp;   Allow the negotiation of the Token Binding protocol witho= ut additional round-trips.

7.        &= nbsp;   Allow the use of multiple cryptographic algorithms, so th= at a variety of secure hardware modules with different cryptographic capabi= lities could be used with Token Binding.

8.        &= nbsp;   Propose Token Binding spec that can be implemented in Web= browsers (but is not limited to them). E.g. Web browsers require that the = same bound security token must be presentable over multiple TLS sessions and connections.=

 

The working group will use the following documents = as a starting point for its work:

-        &n= bsp;    draft-popov-token-binding-00;

-        &n= bsp;    draft-balfanz-https-token-binding-00.

 

This WG will collaborate with other IETF WGs, in pa= rticular with the TLS, HTTPbis and Oauth WGs.

 

Milestones:

-        &n= bsp;   WG document for the Token Binding Protocol v1.0.

-        &n= bsp;   WG document for HTTPS Token Binding.

-        &n= bsp;   Token Binding Protocol v1.0 to IESG.

-        &n= bsp;   HTTPS Token Binding to IESG.

_______________________________________________ Unbearable mailing list
Unbearable@ie= tf.org
https://www.ietf.org/mailman/listinfo/unbearable

 

--_000_BN3PR0301MB1250604C8F185D3A080A416D8C4E0BN3PR0301MB1250_-- From nobody Thu Jan 15 11:02:30 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9696C1B3099 for ; Thu, 15 Jan 2015 11:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 IvioDGqST4iw for ; Thu, 15 Jan 2015 11:02:23 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0736.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4631B30B2 for ; Thu, 15 Jan 2015 11:02:22 -0800 (PST) Received: from BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) by BN3PR0301MB1203.namprd03.prod.outlook.com (25.161.207.156) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 15 Jan 2015 19:02:00 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) with Microsoft SMTP Server (TLS) id 15.1.53.17; Thu, 15 Jan 2015 19:01:59 +0000 Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0059.007; Thu, 15 Jan 2015 19:01:59 +0000 From: Andrei Popov To: Hannes Tschofenig Thread-Topic: [Unbearable] Updated Charter Proposal Thread-Index: AdAwVoQybrCT+HkuTniRvdMsDdHeWgAkZqIAAACFOAAAApJ+AA== Date: Thu, 15 Jan 2015 19:01:58 +0000 Message-ID: References: <54B7FB4C.5050909@gmx.net> In-Reply-To: <54B7FB4C.5050909@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::3] authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-dmarcaction-test: None x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:BN3PR0301MB1251; UriScan:; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251; x-forefront-prvs: 0457F11EAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(13464003)(199003)(68736005)(76176999)(46102003)(97736003)(64706001)(54206007)(19580405001)(106356001)(2900100001)(2950100001)(92566002)(19580395003)(102836002)(122556002)(101416001)(561944003)(40100003)(54356999)(74316001)(33656002)(50986999)(99286002)(87936001)(2656002)(62966003)(77156002)(86612001)(86362001)(76576001)(110136001)(54606007)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2015 19:01:58.9506 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1251 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1203; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] Updated Charter Proposal X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 19:02:28 -0000 Hi Hannes, The idea here is that Web browsers impose additional requirements. One exam= ple is that browsers tend to open multiple TLS sessions and connections to = the target server, and the same security token can be transmitted over any = of these sessions/connections. So the token binding solution has to accommo= date such usage, i.e. the binding must be verifiable regardless of which of= the TLS connections was used to transmit the token. Cheers, Andrei -----Original Message----- From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20 Sent: Thursday, January 15, 2015 9:39 AM To: Andrei Popov Cc: unbearable@ietf.org Subject: Re: [Unbearable] Updated Charter Proposal Andrei, > A new design goal: the solution must work for Web browsers. E.g. this=20 > means that security tokens must be presentable over multiple TLS=20 > sessions and connections. Could you explain what motivated this design goal? What would prevent you f= rom using tokens over more than one TLS exchange? Is there a specific use c= ase you have in mind? Ciao Hannes From nobody Thu Jan 15 11:14:49 2015 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687651B3107 for ; Thu, 15 Jan 2015 11:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MqQqyQbvuDfL for ; Thu, 15 Jan 2015 11:14:43 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0561B30FF for ; Thu, 15 Jan 2015 11:14:38 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t0FJEZV9023844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Jan 2015 19:14:36 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0FJEXW2005010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Jan 2015 19:14:34 GMT Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0FJEX4T027521; Thu, 15 Jan 2015 19:14:33 GMT Received: from [130.35.50.79] (/130.35.50.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 15 Jan 2015 11:14:33 -0800 Message-ID: <54B81198.7030000@oracle.com> Date: Thu, 15 Jan 2015 11:14:32 -0800 From: Prateek Mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Hannes Tschofenig , Andrei Popov , "unbearable@ietf.org" References: <54B779CC.9040201@gmx.net> In-Reply-To: <54B779CC.9040201@gmx.net> Content-Type: multipart/alternative; boundary="------------050402080709010901020002" X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: Subject: Re: [Unbearable] Updated Charter Proposal X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 19:14:47 -0000 This is a multi-part message in MIME format. --------------050402080709010901020002 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit +1 on Hanne's Comments on TLS termination and draft-ietf-oauth-pop-architecture-00 Now, I understand that there are 3-4 ginormous website operators who completely control their stacks all the way from wiring to applications. These folks can handle TLS termination in different and innovative ways. But for most of the rest of the world, we are (politically/administratively) dependent on network architectures where TLS termination is a network hop away from applications. We should include support or at least a framework for these architectures in this work. > Andrei, > > the questions regarding the charter I have are the following. > > Why does the charter need to say already that your specific solution > will be the one worked on. There are other solution approaches possible. > > For example, there are various ways in which the proof of possession > could be demonstrated in TLS (and proposals have been made in the past). > > There also have been suggestions on alternative ways to obtain the token > as well, which are better integrated with existing protocols. > > I also don't know whether you had a chance to look at > draft-ietf-oauth-pop-architecture-00 since in earlier discussions there > were concerns that the the token binding in TLS is insufficient for a > number of scenarios. For example, when you want to provide end-to-end > security where TLS is terminated at load balancers. > > Ciao > Hannes > > On 01/15/2015 01:14 AM, Andrei Popov wrote: >> The discussion on this mailing list has subsided over the holidays, so I >> looked through the messages for feedback regarding the proposed charter >> and incorporated a couple of changes suggested so far: >> >> 1. A new design goal: the solution must work for Web browsers. E.g. this >> means that security tokens must be presentable over multiple TLS >> sessions and connections. >> >> 2. Removed specific milestone dates. >> >> >> >> Looking forward to more discussion of the charter, >> >> >> >> Thanks, >> >> >> >> Andrei >> >> >> >> _____________________________________________________ >> >> Token Binding (TB) >> >> >> >> Charter for Working Group >> >> >> >> Web services generate various security tokens (e.g. HTTP cookies, OAuth >> tokens, etc.) for web applications to access protected resources. >> Currently these are bearer tokens, i.e. any party in possession of such >> token gains access to the protected resource. Attackers export bearer >> tokens from client machines or from compromised network connections, >> present these bearer tokens to Web services, and impersonate >> authenticated users. The idea of Token Binding is to enable defense >> against such attacks by cryptographically binding security tokens to the >> TLS layer. >> >> >> >> The tasks of this working group are as follows: >> >> 1. Specify the Token Binding protocol v1.0. >> >> 2. Specify the use of the Token Binding protocol in >> combination with HTTPS. >> >> >> >> It is a goal of this working group to enable defense against attacks >> that involve unauthorized replay of security tokens, but other issues >> associated with the use of security tokens are out of scope. It is a >> goal of this working group to design the Token Binding protocol such >> that it would be also useable with application protocols other than >> HTTPS, however specifying such uses is not a primary goal. >> >> >> >> Some of the main design goals for the Token Binding protocol, in no >> particular order: >> >> 1. Prevent export and replay of security tokens. >> >> 2. Allow strong key protection, e.g. using hardware-bound keys. >> >> 3. Support both first-party and federation scenarios. >> >> 4. Preserve user privacy. >> >> 5. Make the Token Binding protocol useable in combination >> with a variety of application protocols. >> >> 6. Allow the negotiation of the Token Binding protocol >> without additional round-trips. >> >> 7. Allow the use of multiple cryptographic algorithms, so >> that a variety of secure hardware modules with different cryptographic >> capabilities could be used with Token Binding. >> >> 8. Propose Token Binding spec that can be implemented in Web >> browsers (but is not limited to them). E.g. Web browsers require that >> the same bound security token must be presentable over multiple TLS >> sessions and connections. >> >> >> >> The working group will use the following documents as a starting point >> for its work: >> >> - draft-popov-token-binding-00; >> >> - draft-balfanz-https-token-binding-00. >> >> >> >> This WG will collaborate with other IETF WGs, in particular with the >> TLS, HTTPbis and Oauth WGs. >> >> >> >> Milestones: >> >> - WG document for the Token Binding Protocol v1.0. >> >> - WG document for HTTPS Token Binding. >> >> - Token Binding Protocol v1.0 to IESG. >> >> - HTTPS Token Binding to IESG. >> >> >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >> > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --------------050402080709010901020002 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit +1 on Hanne's Comments on TLS termination and draft-ietf-oauth-pop-architecture-00

Now, I understand that there are 3-4 ginormous website operators who completely control their
stacks all the way from wiring to applications. These folks can handle TLS termination in different
and innovative ways.

But for most of the rest of the world, we are (politically/administratively) dependent
on network architectures where TLS termination is a network hop away from applications.
We should include support or at least a framework for these architectures in this work.
Andrei,

the questions regarding the charter I have are the following.

Why does the charter need to say already that your specific solution
will be the one worked on. There are other solution approaches possible.

For example, there are various ways in which the proof of possession
could be demonstrated in TLS (and proposals have been made in the past).

There also have been suggestions on alternative ways to obtain the token
as well, which are better integrated with existing protocols.

I also don't know whether you had a chance to look at
draft-ietf-oauth-pop-architecture-00 since in earlier discussions there
were concerns that the the token binding in TLS is insufficient for a
number of scenarios. For example, when you want to provide end-to-end
security where TLS is terminated at load balancers.

Ciao
Hannes

On 01/15/2015 01:14 AM, Andrei Popov wrote:

The discussion on this mailing list has subsided over the holidays, so I
looked through the messages for feedback regarding the proposed charter
and incorporated a couple of changes suggested so far:

1. A new design goal: the solution must work for Web browsers. E.g. this
means that security tokens must be presentable over multiple TLS
sessions and connections.

2. Removed specific milestone dates.

 

Looking forward to more discussion of the charter,

 

Thanks,

 

Andrei

 

_____________________________________________________

Token Binding (TB)

 

Charter for Working Group

 

Web services generate various security tokens (e.g.  HTTP cookies, OAuth
tokens, etc.) for web applications to access protected resources.
Currently these are bearer tokens, i.e. any party in possession of such
token gains access to the protected resource. Attackers export bearer
tokens from client machines or from compromised network connections,
present these bearer tokens to Web services, and impersonate
authenticated users. The idea of Token Binding is to enable defense
against such attacks by cryptographically binding security tokens to the
TLS layer.

 

The tasks of this working group are as follows:

1.            Specify the Token Binding protocol v1.0.

2.            Specify the use of the Token Binding protocol in
combination with HTTPS.

 

It is a goal of this working group to enable defense against attacks
that involve unauthorized replay of security tokens, but other issues
associated with the use of security tokens are out of scope. It is a
goal of this working group to design the Token Binding protocol such
that it would be also useable with application protocols other than
HTTPS, however specifying such uses is not a primary goal.

 

Some of the main design goals for the Token Binding protocol, in no
particular order:

1.            Prevent export and replay of security tokens.

2.            Allow strong key protection, e.g. using hardware-bound keys.

3.            Support both first-party and federation scenarios.

4.            Preserve user privacy.

5.            Make the Token Binding protocol useable in combination
with a variety of application protocols.

6.            Allow the negotiation of the Token Binding protocol
without additional round-trips.

7.            Allow the use of multiple cryptographic algorithms, so
that a variety of secure hardware modules with different cryptographic
capabilities could be used with Token Binding.

8.            Propose Token Binding spec that can be implemented in Web
browsers (but is not limited to them). E.g. Web browsers require that
the same bound security token must be presentable over multiple TLS
sessions and connections.

 

The working group will use the following documents as a starting point
for its work:

-             draft-popov-token-binding-00;

-             draft-balfanz-https-token-binding-00.

 

This WG will collaborate with other IETF WGs, in particular with the
TLS, HTTPbis and Oauth WGs.

 

Milestones:

-            WG document for the Token Binding Protocol v1.0.

-            WG document for HTTPS Token Binding.

-            Token Binding Protocol v1.0 to IESG.

-            HTTPS Token Binding to IESG.



_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable



      

      

      

      
_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable


    

    

  


--------------050402080709010901020002--


From nobody Thu Jan 15 11:54:10 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BEE1B32C4 for ; Thu, 15 Jan 2015 11:54:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 QjvHyfhem1Kx for ; Thu, 15 Jan 2015 11:53:54 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0132.outbound.protection.outlook.com [65.55.169.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 597BF1B32BE for ; Thu, 15 Jan 2015 11:53:36 -0800 (PST)
Received: from BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) by BN3PR0301MB1265.namprd03.prod.outlook.com (25.161.209.145) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 15 Jan 2015 19:53:34 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) with Microsoft SMTP Server (TLS) id 15.1.53.17; Thu, 15 Jan 2015 19:53:33 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0059.007; Thu, 15 Jan 2015 19:53:33 +0000
From: Andrei Popov 
To: Hannes Tschofenig , "unbearable@ietf.org" 
Thread-Topic: [Unbearable] Updated Charter Proposal
Thread-Index: AdAwVoQybrCT+HkuTniRvdMsDdHeWgARn9EAABY4s2A=
Date: Thu, 15 Jan 2015 19:53:32 +0000
Message-ID: 
References:  <54B779CC.9040201@gmx.net>
In-Reply-To: <54B779CC.9040201@gmx.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::3]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; 
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:BN3PR0301MB1251; UriScan:; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251; 
x-forefront-prvs: 0457F11EAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(479174004)(199003)(13464003)(51704005)(189002)(164054003)(86362001)(86612001)(76576001)(2656002)(62966003)(77156002)(54606007)(106356001)(54206007)(19580405001)(2900100001)(92566002)(19580395003)(2950100001)(2501002)(68736005)(76176999)(46102003)(64706001)(97736003)(54356999)(74316001)(15975445007)(40100003)(33656002)(561944003)(99286002)(107886001)(87936001)(50986999)(102836002)(101416001)(122556002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2015 19:53:32.1974 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1251
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1265;
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: 
Subject: Re: [Unbearable] Updated Charter Proposal
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jan 2015 19:54:02 -0000

> Why does the charter need to say already that your specific solution will=
 be the one worked on. There are other solution approaches possible.
A lot of TLS WG charters specify some starting-point document(s); this give=
s a good idea of what problems are being solved by the WG. In my opinion, i=
t does not mean that the WG is locked into a specific solution, because Int=
ernet-Drafts are expected to change as the discussion progresses.

> There also have been suggestions on alternative ways to obtain the token =
as well, which are better integrated with existing protocols.
I would suggest that we discuss these alternatives in the new WG, and integ=
rate them into the draft(s), if it makes sense.

> I also don't know whether you had a chance to look at draft-ietf-oauth-po=
p-architecture-00 since in earlier discussions there were concerns that the=
 the token binding in TLS is insufficient for a number of scenarios.=20
Yes, I read draft-ietf-oauth-pop-architecture-00; it appears to embrace bot=
h TLS (optionally) and asymmetric client-generated keys (also as an option)=
, so I don't think there is any conflict here.

> For example, when you want to provide end-to-end security where TLS is te=
rminated at load balancers.
I agree that it is common for TLS to be terminated at load balancers, and t=
hat this case should be discussed in the I-Ds. It's one of the gaps we'll n=
eed to close in the drafts, after all they are offered as a starting point,=
 not finished product.

Cheers,

Andrei

-----Original Message-----
From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20
Sent: Thursday, January 15, 2015 12:27 AM
To: Andrei Popov; unbearable@ietf.org
Subject: Re: [Unbearable] Updated Charter Proposal

Andrei,

the questions regarding the charter I have are the following.

Why does the charter need to say already that your specific solution will b=
e the one worked on. There are other solution approaches possible.

For example, there are various ways in which the proof of possession could =
be demonstrated in TLS (and proposals have been made in the past).

There also have been suggestions on alternative ways to obtain the token as=
 well, which are better integrated with existing protocols.

I also don't know whether you had a chance to look at
draft-ietf-oauth-pop-architecture-00 since in earlier discussions there wer=
e concerns that the the token binding in TLS is insufficient for a number o=
f scenarios. For example, when you want to provide end-to-end security wher=
e TLS is terminated at load balancers.

Ciao
Hannes

On 01/15/2015 01:14 AM, Andrei Popov wrote:
> The discussion on this mailing list has subsided over the holidays, so=20
> I looked through the messages for feedback regarding the proposed=20
> charter and incorporated a couple of changes suggested so far:
>=20
> 1. A new design goal: the solution must work for Web browsers. E.g.=20
> this means that security tokens must be presentable over multiple TLS=20
> sessions and connections.
>=20
> 2. Removed specific milestone dates.
>=20
> =20
>=20
> Looking forward to more discussion of the charter,
>=20
> =20
>=20
> Thanks,
>=20
> =20
>=20
> Andrei
>=20
> =20
>=20
> _____________________________________________________
>=20
> Token Binding (TB)
>=20
> =20
>=20
> Charter for Working Group
>=20
> =20
>=20
> Web services generate various security tokens (e.g.  HTTP cookies,=20
> OAuth tokens, etc.) for web applications to access protected resources.
> Currently these are bearer tokens, i.e. any party in possession of=20
> such token gains access to the protected resource. Attackers export=20
> bearer tokens from client machines or from compromised network=20
> connections, present these bearer tokens to Web services, and=20
> impersonate authenticated users. The idea of Token Binding is to=20
> enable defense against such attacks by cryptographically binding=20
> security tokens to the TLS layer.
>=20
> =20
>=20
> The tasks of this working group are as follows:
>=20
> 1.            Specify the Token Binding protocol v1.0.
>=20
> 2.            Specify the use of the Token Binding protocol in
> combination with HTTPS.
>=20
> =20
>=20
> It is a goal of this working group to enable defense against attacks=20
> that involve unauthorized replay of security tokens, but other issues=20
> associated with the use of security tokens are out of scope. It is a=20
> goal of this working group to design the Token Binding protocol such=20
> that it would be also useable with application protocols other than=20
> HTTPS, however specifying such uses is not a primary goal.
>=20
> =20
>=20
> Some of the main design goals for the Token Binding protocol, in no=20
> particular order:
>=20
> 1.            Prevent export and replay of security tokens.
>=20
> 2.            Allow strong key protection, e.g. using hardware-bound keys=
.
>=20
> 3.            Support both first-party and federation scenarios.
>=20
> 4.            Preserve user privacy.
>=20
> 5.            Make the Token Binding protocol useable in combination
> with a variety of application protocols.
>=20
> 6.            Allow the negotiation of the Token Binding protocol
> without additional round-trips.
>=20
> 7.            Allow the use of multiple cryptographic algorithms, so
> that a variety of secure hardware modules with different cryptographic=20
> capabilities could be used with Token Binding.
>=20
> 8.            Propose Token Binding spec that can be implemented in Web
> browsers (but is not limited to them). E.g. Web browsers require that=20
> the same bound security token must be presentable over multiple TLS=20
> sessions and connections.
>=20
> =20
>=20
> The working group will use the following documents as a starting point=20
> for its work:
>=20
> -             draft-popov-token-binding-00;
>=20
> -             draft-balfanz-https-token-binding-00.
>=20
> =20
>=20
> This WG will collaborate with other IETF WGs, in particular with the=20
> TLS, HTTPbis and Oauth WGs.
>=20
> =20
>=20
> Milestones:
>=20
> -            WG document for the Token Binding Protocol v1.0.
>=20
> -            WG document for HTTPS Token Binding.
>=20
> -            Token Binding Protocol v1.0 to IESG.
>=20
> -            HTTPS Token Binding to IESG.
>=20
>=20
>=20
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable
>=20


From nobody Thu Jan 15 11:59:24 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975F11B321A for ; Thu, 15 Jan 2015 11:59:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.191
X-Spam-Level: *
X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 8QcBd_e9_cin for ; Thu, 15 Jan 2015 11:59:20 -0800 (PST)
Received: from nm27-vm1.bullet.mail.bf1.yahoo.com (nm27-vm1.bullet.mail.bf1.yahoo.com [98.139.213.148]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B5E11B3226 for ; Thu, 15 Jan 2015 11:59:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1421351959; bh=sZjxdmxry6ltMRhPVHRHvTuUyJ9HbzTA+srzidYNRYo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=swFWL5U1uXNHFAc1qePHj4GjNRAqov7CinUR36P1JadtbTiKqBMzhf7fJyEgywb4O4/+diYnKyLeieXFJaLoJD2PHjPEa7KCQmO8xE7FtZ2r0LQhk8dfIat8QbAdDtXIBF5vF/w+DC1tivFr2zh11ejNfY1MOttdLr4jdvmaqS6k0H6TRGCK/XZTu1Dzycewa543j/HzkoYcUWKV0YcRNhf1UyXyHPtsIPGv5LAo1HMqab2nMzFgjs6Uhzdgr+cdeWmTOqkiZc8PviWSIYR0aPN2DBIgppC59SX4nl2/QCuvOwQ4etAYzvTncvXOJ5t1mJTcx3yLZr3CxaUp8TVy2g==
Received: from [66.196.81.174] by nm27.bullet.mail.bf1.yahoo.com with NNFMP; 15 Jan 2015 19:59:19 -0000
Received: from [98.139.212.219] by tm20.bullet.mail.bf1.yahoo.com with NNFMP;  15 Jan 2015 19:59:19 -0000
Received: from [127.0.0.1] by omp1028.mail.bf1.yahoo.com with NNFMP; 15 Jan 2015 19:59:19 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 279815.69631.bm@omp1028.mail.bf1.yahoo.com
X-YMail-OSG: 6WHvB04VM1nYgwPRNZBmIyb_DFYYFXekoyxuxs3Xs76UYxOLck7.PSCBSwIHA8t .5Rk.w3iGEBvYWosFhYsbd5vXKyLM8kxxqtBC9bP7914SA9gAeZ6xTdqu_ZIDhGu_tNz612aDUXL 0mp9_R3JUJEKw3GRyKEweKDFR5XKuYIILqtEdq2HPEJFRUUZE1q7fB_aOqqw9UqB7I.PxSCJsJf5 HUk2mWNLSHG3IxPLErACwXJkF.jLU1t4qx1YZyqtUBQbxhHdPcGd5ePrvkOqvWDSjGUwzRlYaVYD UOqlmH0GUEJdBsWOOuxzVYPs4Pxfbe29XY1roIDlrDJhm2k7JJExcwxBIxLIS0txza6vvdmQuD2Y yEKxBwNLBOY2sYoSCaWlmr096IPAYPjDn2rZCxgRL6xKRMC1GHSPaDdPxrVc9BTux4j.49PEfq1Z ZE3Lgl3SNhRXiUWUumkBj7QSQpwkTdcUSDJNowjrT.UbvcFeyWrPNjMzqaVrJbCUY_DmHi1N0xFL BGlV.mw_mkFE-
Received: by 76.13.26.198; Thu, 15 Jan 2015 19:59:18 +0000 
Date: Thu, 15 Jan 2015 19:59:18 +0000 (UTC)
From: Bill Mills 
To: Andrei Popov ,  Hannes Tschofenig 
Message-ID: <1652729867.1797350.1421351958565.JavaMail.yahoo@jws10656.mail.bf1.yahoo.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_1797349_363621310.1421351958561"
Archived-At: 
Cc: "unbearable@ietf.org" 
Subject: Re: [Unbearable] Updated Charter Proposal
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jan 2015 19:59:21 -0000

------=_Part_1797349_363621310.1421351958561
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I'm still trying to get my head around what the "elevator pitch" is for thi=
s, I don't think it's been adequately expressed yet. =C2=A0Is it close to s=
ay this is all about "Clients (browsers) being able to tie credentials to l=
ocally generated and managed keys and assert that key to the auth service."=
?=20

     On Thursday, January 15, 2015 11:02 AM, Andrei Popov  wrote:
  =20

 Hi Hannes,

The idea here is that Web browsers impose additional requirements. One exam=
ple is that browsers tend to open multiple TLS sessions and connections to =
the target server, and the same security token can be transmitted over any =
of these sessions/connections. So the token binding solution has to accommo=
date such usage, i.e. the binding must be verifiable regardless of which of=
 the TLS connections was used to transmit the token.

Cheers,

Andrei

-----Original Message-----
From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]=20
Sent: Thursday, January 15, 2015 9:39 AM
To: Andrei Popov
Cc: unbearable@ietf.org
Subject: Re: [Unbearable] Updated Charter Proposal

Andrei,

> A new design goal: the solution must work for Web browsers. E.g. this=20
> means that security tokens must be presentable over multiple TLS=20
> sessions and connections.

Could you explain what motivated this design goal? What would prevent you f=
rom using tokens over more than one TLS exchange? Is there a specific use c=
ase you have in mind?

Ciao
Hannes



_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable


   
------=_Part_1797349_363621310.1421351958561
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I'm=
 still trying to get my head around what the "elevator pitch" is for this, =
I don't think it's been adequately expressed yet.  Is it close to say =
this is all about "Clients (browsers) being able to tie credentials to loca=
lly generated and managed keys and assert that key to the auth service."? 


 
 =

 
  On Thursday, January 15, 2015 11:02 AM, Andrei Popov=
 <Andrei.Popov@microsoft.com> wrote:
  
  

 Hi Hannes,

The idea here is that Web browsers impose additional requirements. One exa=
mple is that browsers tend to open multiple TLS sessions and connections to=
 the target server, and the same security token can be transmitted over any=
 of these sessions/connections. So the token binding solution has to accomm=
odate such usage, i.e. the binding must be verifiable regardless of which o=
f the TLS connections was used to transmit the token.
Cheers,

Andrei

-----Original Message-----
From: Hannes Tschofenig [mai=
lto:hannes.tschofenig@gmx.net] 
Sent: Thursday, January 15, 2015 9:39 AM
To: An=
drei Popov
Cc: unbearable@ietf.org<=
br clear=3D"none">Subject: Re: [Unbearable] Updated Charter Proposal

Andrei,

> A new design goal: the solution must work for Web browsers. E.g. this=
 
> means that security tokens must be presentable ove=
r multiple TLS 
> sessions and connections.

Could you explain what motivated this design g=
oal? What would prevent you from using tokens over more than one TLS exchan=
ge? Is there a specific use case you have in mind?

Ciao
Hannes



________________________________=
_______________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable


  
 
  
 

------=_Part_1797349_363621310.1421351958561--


From nobody Thu Jan 15 12:16:24 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3571B32C3 for ; Thu, 15 Jan 2015 12:16:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 QJu-3p_9rulc for ; Thu, 15 Jan 2015 12:16:07 -0800 (PST)
Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDDFD1B2E0F for ; Thu, 15 Jan 2015 12:16:06 -0800 (PST)
Received: by mail-qc0-f169.google.com with SMTP id w7so13974262qcr.0 for ; Thu, 15 Jan 2015 12:16:06 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=zGJEhMyHRUZQon67xWpYK4QSaq7rt9n5FJdCDs1wuqU=; b=XrmO2VDPY8H5sPq5awlXKEk92ymj6o78u/glgajla3IF07LFRz8W0nCeFnJS58ubEE eZ7RrjQUpZha0ka3/GPjRSK5pjLHa3pL0qSmRQv00R2WN5ROedxtJCQNy3BjjwdC9qsi nbhwDy1b944zkZyKMEd7qUNs2NWVBJF1I05S1sQi012EBg9r8sh8ZaThg+OWX+dMxhnm w06j4t+/QNEHcVqi0XHFO7H+e7ijZ7q5K8cka0DLjLYZ5SSwJZHFeUt6cS8N1kQ6BJ1l +ixZeXK37NyA2fwWpyqhzeX3Yy4MduhY2Gq/iSRa2SYC0LJr23JsTn6Clm9eyjgkM/VC lQ8Q==
X-Gm-Message-State: ALoCoQnr50FVMzsIOazJEHUKam/l/P7xoHpR2RHgOme7qTnd5JshxRAHg14P7D1HqbzTRIucleIV
X-Received: by 10.140.20.50 with SMTP id 47mr9392008qgi.61.1421352966161; Thu, 15 Jan 2015 12:16:06 -0800 (PST)
Received: from [192.168.8.100] ([186.65.149.253]) by mx.google.com with ESMTPSA id r16sm2199409qay.10.2015.01.15.12.16.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Jan 2015 12:16:04 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_4AFDD099-D233-4C36-8887-B231EA507F10"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: John Bradley 
In-Reply-To: 
Date: Thu, 15 Jan 2015 17:16:00 -0300
Message-Id: 
References:   
To: Andrei Popov 
X-Mailer: Apple Mail (2.1993)
Archived-At: 
Cc: "unbearable@ietf.org" 
Subject: Re: [Unbearable] Updated Charter Proposal
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jan 2015 20:16:13 -0000

--Apple-Mail=_4AFDD099-D233-4C36-8887-B231EA507F10
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_05CBE381-7830-4FC7-BE89-526E3141C198"


--Apple-Mail=_05CBE381-7830-4FC7-BE89-526E3141C198
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

A couple more possible clarifications.



> 2.            Specify the use of the Token Binding protocol in =
combination with HTTPS.

HTTPS is probably intended to be shorthand for a http binding for TLS + =
token Binding as is defined in "Token Binding over HTTP"  =
[https://tools.ietf.org/html/draft-balfanz-https-token-binding-00].

This is a binding to HTTP (via a new header) and to HTML  (via XML HTTP =
request). =20

If we also say that possible future binding may be a SASSL/GSS-API =
binding for TLS + token binding   (The sassl-oauth spec =
https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 might use =
such a thing.)


One other thing I note in the drafts, is that at no point are  tokens =
defined or even really discussed other than as something that =
applications can bind to the exposed public key.
The applications will bind tokens to the keys exposed by the specs via =
the bindings.   The naming may slightly misdirect people, but there have =
already been too many names for this so I won't push the point.

I think keeping this down close to the TLS layer and defining bindings =
to HTTP and other protocols is in scope.
Encouraging applications that use protocols like HTTP + TLS to use the =
bindings to bind there security tokens/cookies is in scope.

I think defining the extensions for those applications to use the =
bindings is should be up to the applications themselves where there is =
active participation.

Trying to extend this to cover end to end message signing outside of a =
TLS session should be expressly out of scope.

We may however want to say something about how a TLS session terminated =
on a TLS device can have the Token Binding ID for the session passed in =
a HTTP header.
That and possibly some other TLS appliance issues are in scope for =
"Token Binding over HTTP"

Regards
John B.


=20
> On Jan 15, 2015, at 3:52 PM, Andrei Popov  =
wrote:
>=20
> Thanks John; both suggestions make sense to me; will rephrase in the =
next revision.
> =20
> Cheers,
> =20
> Andrei
> =20
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20
> Sent: Thursday, January 15, 2015 9:25 AM
> To: Andrei Popov
> Cc: unbearable@ietf.org
> Subject: Re: [Unbearable] Updated Charter Proposal
> =20
> I am generally in agrement.
> =20
> A couple of points.
> =20
> Under design goals change 1 to.
> =20
> 1.   Allow applications to prevent the export and replay of security =
tokens.
> =20
> You could make that applications and protocols if you like as some =
people may see things like OAuth as a protocol vs an application.=20
> The point being that the goal is to provide the hooks for things a =
layer above these specifications to make security decisions, not the =
token binding protocol itself.
> =20
> =20
> In 3 you use the term federation.  That may be larger in scope than =
what I think you intend from the two drafts.
> Federation is a much larger topic than allowing the public key from =
one connection to be exposed in a connection to a second party via some =
sort of express consent from the first party.
> =20
> Shrinking the scope to how public keys may be shared with permission =
to third parties may make some people more comfortable, if they are =
concerned that this is trying to be a new federation protocol to compete =
with SAML or OAuth.
> =20
> Regards
> John B.
> =20
> On Jan 14, 2015, at 9:14 PM, Andrei Popov > wrote:
> =20
> The discussion on this mailing list has subsided over the holidays, so =
I looked through the messages for feedback regarding the proposed =
charter and incorporated a couple of changes suggested so far:
> 1. A new design goal: the solution must work for Web browsers. E.g. =
this means that security tokens must be presentable over multiple TLS =
sessions and connections.
> 2. Removed specific milestone dates.
> =20
> Looking forward to more discussion of the charter,
> =20
> Thanks,
> =20
> Andrei
> =20
> _____________________________________________________
> Token Binding (TB)
> =20
> Charter for Working Group
> =20
> Web services generate various security tokens (e.g.  HTTP cookies, =
OAuth tokens, etc.) for web applications to access protected resources. =
Currently these are bearer tokens, i.e. any party in possession of such =
token gains access to the protected resource. Attackers export bearer =
tokens from client machines or from compromised network connections, =
present these bearer tokens to Web services, and impersonate =
authenticated users. The idea of Token Binding is to enable defense =
against such attacks by cryptographically binding security tokens to the =
TLS layer.
> =20
> The tasks of this working group are as follows:
> 1.            Specify the Token Binding protocol v1.0.
> 2.            Specify the use of the Token Binding protocol in =
combination with HTTPS.
> =20
> It is a goal of this working group to enable defense against attacks =
that involve unauthorized replay of security tokens, but other issues =
associated with the use of security tokens are out of scope. It is a =
goal of this working group to design the Token Binding protocol such =
that it would be also useable with application protocols other than =
HTTPS, however specifying such uses is not a primary goal.
> =20
> Some of the main design goals for the Token Binding protocol, in no =
particular order:
> 1.            Prevent export and replay of security tokens.
> 2.            Allow strong key protection, e.g. using hardware-bound =
keys.
> 3.            Support both first-party and federation scenarios.
> 4.            Preserve user privacy.
> 5.            Make the Token Binding protocol useable in combination =
with a variety of application protocols.
> 6.            Allow the negotiation of the Token Binding protocol =
without additional round-trips.
> 7.            Allow the use of multiple cryptographic algorithms, so =
that a variety of secure hardware modules with different cryptographic =
capabilities could be used with Token Binding.
> 8.            Propose Token Binding spec that can be implemented in =
Web browsers (but is not limited to them). E.g. Web browsers require =
that the same bound security token must be presentable over multiple TLS =
sessions and connections.
> =20
> The working group will use the following documents as a starting point =
for its work:
> -             draft-popov-token-binding-00;
> -             draft-balfanz-https-token-binding-00.
> =20
> This WG will collaborate with other IETF WGs, in particular with the =
TLS, HTTPbis and Oauth WGs.
> =20
> Milestones:
> -            WG document for the Token Binding Protocol v1.0.
> -            WG document for HTTPS Token Binding.
> -            Token Binding Protocol v1.0 to IESG.
> -            HTTPS Token Binding to IESG.
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org 
> https://www.ietf.org/mailman/listinfo/unbearable =


--Apple-Mail=_05CBE381-7830-4FC7-BE89-526E3141C198
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

A couple more possible clarifications.



2.          =
;  Specify the use of the Token Binding protocol in combination =
with =
HTTPS.

HTTPS is probably intended to be =
shorthand for a http binding for TLS + token Binding as is defined in =
"Token Binding over HTTP"  [https://tools.ietf.org/html/draft-balfanz-https-token-binding-0=
0].

This =
is a binding to HTTP (via a new header) and to HTML  (via XML HTTP =
request).  

If we also say that possible future binding may be a =
SASSL/GSS-API binding for TLS + token binding   (The sassl-oauth =
spec https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18=
 might use such a thing.)


One =
other thing I note in the drafts, is that at no point are  tokens =
defined or even really discussed other than as something that =
applications can bind to the exposed public key.
The =
applications will bind tokens to the keys exposed by the specs via the =
bindings.   The naming may slightly misdirect people, but there =
have already been too many names for this so I won't push the =
point.

I think =
keeping this down close to the TLS layer and defining bindings to HTTP =
and other protocols is in scope.
Encouraging =
applications that use protocols like HTTP + TLS to use the bindings to =
bind there security tokens/cookies is in scope.

I think defining the extensions for =
those applications to use the bindings is should be up to the =
applications themselves where there is active participation.

Trying to extend this to =
cover end to end message signing outside of a TLS session should be =
expressly out of scope.

We may however want to say something about how a TLS session =
terminated on a TLS device can have the Token Binding ID for the session =
passed in a HTTP header.
That and possibly some =
other TLS appliance issues are in scope for "Token Binding over =
HTTP"

Regards
John B.


 
On Jan 15, 2015, at 3:52 PM, Andrei Popov =
<Andrei.Popov@microsoft.com> wrote:

Thanks John; both suggestions make sense =
to me; will rephrase in the next revision.
 
Cheers,
 
Andrei
 
From: John =
Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Thursday, January 15, 2015 =
9:25 AM
To: Andrei Popov
Cc: unbearable@ietf.org
Subject: Re: [Unbearable] Updated =
Charter Proposal
 
I am generally in agrement.
 
A couple of points.
 
Under design goals change 1 to.
 
1.   Allow applications to prevent =
the export and replay of security tokens.
 
You could make that applications and =
protocols if you like as some people may see things like OAuth as a =
protocol vs an application. 
The point being that =
the goal is to provide the hooks for things a layer above these =
specifications to make security decisions, not the token binding =
protocol itself.
 
 
In 3 you use the term =
federation.  That may be larger in scope than what I think you =
intend from the two drafts.
Federation is a much =
larger topic than allowing the public key from one connection to be =
exposed in a connection to a second party via some sort of express =
consent from the first party.
 
Shrinking the scope to how public keys may be shared =
with permission to third parties may make some people more comfortable, =
if they are concerned that this is trying to be a new federation =
protocol to compete with SAML or OAuth.
 
Regards
John B.
 
On =
Jan 14, 2015, at 9:14 PM, Andrei Popov <Andrei.Popov@microsoft.com>=
 wrote:
 
The discussion on this mailing list has subsided over the =
holidays, so I looked through the messages for feedback regarding the =
proposed charter and incorporated a couple of changes suggested so =
far:
1. A new design goal: the =
solution must work for Web browsers. E.g. this means that security =
tokens must be presentable over multiple TLS sessions and =
connections.
2. Removed specific =
milestone dates.
 
Looking forward to more discussion of the charter,
 
Thanks,
 
Andrei
 
_____________________________________________________
Token Binding (TB)
 
Charter for Working Group
 
Web services generate various security tokens =
(e.g.  HTTP cookies, OAuth tokens, etc.) for web applications to =
access protected resources. Currently these are bearer tokens, i.e. any =
party in possession of such token gains access to the protected =
resource. Attackers export bearer tokens from client machines or from =
compromised network connections, present these bearer tokens to Web =
services, and impersonate authenticated users. The idea of Token Binding =
is to enable defense against such attacks by cryptographically binding =
security tokens to the TLS layer.
 
The tasks of this working group are as =
follows:
1.          &=
nbsp; Specify the Token Binding protocol v1.0.
2.          &=
nbsp; Specify the use of the Token Binding protocol in combination with =
HTTPS.
 
It is a goal of this working group to enable =
defense against attacks that involve unauthorized replay of security =
tokens, but other issues associated with the use of security tokens are =
out of scope. It is a goal of this working group to design the Token =
Binding protocol such that it would be also useable with application =
protocols other than HTTPS, however specifying such uses is not a =
primary goal.
 
Some of the main design goals for the Token =
Binding protocol, in no particular order:
1.          &=
nbsp; Prevent export and replay of security tokens.
2.          &=
nbsp; Allow strong key protection, e.g. using hardware-bound keys.
3.          &=
nbsp; Support both first-party and federation scenarios.
4.          &=
nbsp; Preserve user privacy.
5.          &=
nbsp; Make the Token Binding protocol useable in combination with a =
variety of application protocols.
6.          &=
nbsp; Allow the negotiation of the Token Binding protocol without =
additional round-trips.
7.          &=
nbsp; Allow the use of multiple cryptographic algorithms, so that a =
variety of secure hardware modules with different cryptographic =
capabilities could be used with Token Binding.
8.          &=
nbsp; Propose Token Binding spec that can be implemented in Web browsers =
(but is not limited to them). E.g. Web browsers require that the same =
bound security token must be presentable over multiple TLS sessions and =
connections.
 
The working group will use the following =
documents as a starting point for its work:
-          &n=
bsp;  draft-popov-token-binding-00;
-          &n=
bsp;  draft-balfanz-https-token-binding-00.
 
This WG will collaborate with other IETF WGs, in =
particular with the TLS, HTTPbis and Oauth WGs.
 
Milestones:
-          &n=
bsp; WG document for the Token Binding Protocol v1.0.
-          &n=
bsp; WG document for HTTPS Token Binding.
-          &n=
bsp; Token Binding Protocol v1.0 to IESG.
-          &n=
bsp; HTTPS Token Binding to IESG.
_______________________________________________Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable

=

--Apple-Mail=_05CBE381-7830-4FC7-BE89-526E3141C198--

--Apple-Mail=_4AFDD099-D233-4C36-8887-B231EA507F10
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAxMTUyMDE2MDFaMCMGCSqGSIb3DQEJBDEWBBTXJby1AcD/SOcedNNkIQ+v
Brq0gzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCOBqx2SBAXEC6eZW1Nd6YtoOBs5PFxla5Uzekl0Gs3GLSCRg4bRqEY
lCIT6tjkWViohwbPbeFJ2ryQrQOPg+VyDNEhEGfL0N/Hb7KHFTsZl8VpY0MXM9VJyi95k8QtjJTq
L8Odh7+NLhw1BRBT+mHZtmsNzA7BHnsYxGZB/emKw6LiDqNRhuv2pA5arhga2RoL7vYJegFXLXQD
gLHqruRnrSAlCWbpKxiuuPW3Njs36o/cc8xRNkPE+59I3AFioa3bF0vlx7OEbBhD3hWJecV/aTWM
44kp6XhTuYRY2ZhA/pc40RdIknfRlGxLUG0QsDBOL5el3s43qUAyctscGoUvAAAAAAAA
--Apple-Mail=_4AFDD099-D233-4C36-8887-B231EA507F10--


From nobody Thu Jan 15 12:43:13 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9951B32F5 for ; Thu, 15 Jan 2015 12:43:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 i3QytJxdIrLF for ; Thu, 15 Jan 2015 12:43:09 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0103.outbound.protection.outlook.com [65.55.169.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5BA1B32F4 for ; Thu, 15 Jan 2015 12:43:09 -0800 (PST)
Received: from BN3PR0301MB1252.namprd03.prod.outlook.com (25.161.207.28) by BN3PR0301MB1297.namprd03.prod.outlook.com (25.161.210.152) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 15 Jan 2015 20:43:08 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1252.namprd03.prod.outlook.com (25.161.207.28) with Microsoft SMTP Server (TLS) id 15.1.59.20; Thu, 15 Jan 2015 20:43:06 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0059.007; Thu, 15 Jan 2015 20:43:06 +0000
From: Andrei Popov 
To: Bill Mills , Hannes Tschofenig 
Thread-Topic: [Unbearable] Updated Charter Proposal
Thread-Index: AdAwVoQybrCT+HkuTniRvdMsDdHeWgAkZqIAAACFOAAAApJ+AAACUE8AAAFUHfA=
Date: Thu, 15 Jan 2015 20:43:06 +0000
Message-ID: 
References:  <1652729867.1797350.1421351958565.JavaMail.yahoo@jws10656.mail.bf1.yahoo.com>
In-Reply-To: <1652729867.1797350.1421351958565.JavaMail.yahoo@jws10656.mail.bf1.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::3]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; 
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:BN3PR0301MB1252; UriScan:; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1252; 
x-forefront-prvs: 0457F11EAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(13464003)(24454002)(189002)(377454003)(19609705001)(86612001)(19580405001)(19580395003)(99286002)(54606007)(54356999)(76176999)(16236675004)(50986999)(92566002)(77156002)(62966003)(40100003)(122556002)(19300405004)(76576001)(106356001)(54206007)(86362001)(19625215002)(74316001)(64706001)(19617315012)(101416001)(97736003)(46102003)(87936001)(2656002)(2950100001)(2900100001)(15975445007)(102836002)(68736005)(33656002)(561944003)(2420400003)(2521001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1252; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB1250DF6F834382D70B50B0BB8C4E0BN3PR0301MB1250_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2015 20:43:06.7263 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1252
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1297;
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: 
Cc: "unbearable@ietf.org" 
Subject: Re: [Unbearable] Updated Charter Proposal
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jan 2015 20:43:12 -0000

--_000_BN3PR0301MB1250DF6F834382D70B50B0BB8C4E0BN3PR0301MB1250_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

VGhpcyBpcyBpbmRlZWQgcGFydCBvZiB3aGF0IHRoZSBjdXJyZW50IC0wMCBJLURzIG9mZmVyLg0K
DQpXZSBzaG91bGQgbm90IGVxdWF0ZSBjbGllbnRzIHdpdGggV2ViIGJyb3dzZXJzLCBidXQgdGhl
IGJyb3dzZXIgdXNlIGNhc2UgaXMgc29tZXdoYXQgc3BlY2lhbCBhbmQgaW1wb3J0YW50IHRvIGFk
ZHJlc3MsIHRoZXJlZm9yZSBJIHRoaW5rIGl0IGRlc2VydmVzIG1lbnRpb24gYW1vbmcgdGhlIGdv
YWxzLg0KDQpGcm9tOiBCaWxsIE1pbGxzIFttYWlsdG86d21pbGxzXzkyMTA1QHlhaG9vLmNvbV0N
ClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDE1LCAyMDE1IDExOjU5IEFNDQpUbzogQW5kcmVpIFBv
cG92OyBIYW5uZXMgVHNjaG9mZW5pZw0KQ2M6IHVuYmVhcmFibGVAaWV0Zi5vcmcNClN1YmplY3Q6
IFJlOiBbVW5iZWFyYWJsZV0gVXBkYXRlZCBDaGFydGVyIFByb3Bvc2FsDQoNCkknbSBzdGlsbCB0
cnlpbmcgdG8gZ2V0IG15IGhlYWQgYXJvdW5kIHdoYXQgdGhlICJlbGV2YXRvciBwaXRjaCIgaXMg
Zm9yIHRoaXMsIEkgZG9uJ3QgdGhpbmsgaXQncyBiZWVuIGFkZXF1YXRlbHkgZXhwcmVzc2VkIHll
dC4gIElzIGl0IGNsb3NlIHRvIHNheSB0aGlzIGlzIGFsbCBhYm91dCAiQ2xpZW50cyAoYnJvd3Nl
cnMpIGJlaW5nIGFibGUgdG8gdGllIGNyZWRlbnRpYWxzIHRvIGxvY2FsbHkgZ2VuZXJhdGVkIGFu
ZCBtYW5hZ2VkIGtleXMgYW5kIGFzc2VydCB0aGF0IGtleSB0byB0aGUgYXV0aCBzZXJ2aWNlLiI/
DQoNCk9uIFRodXJzZGF5LCBKYW51YXJ5IDE1LCAyMDE1IDExOjAyIEFNLCBBbmRyZWkgUG9wb3Yg
PEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0
LmNvbT4+IHdyb3RlOg0KDQpIaSBIYW5uZXMsDQoNClRoZSBpZGVhIGhlcmUgaXMgdGhhdCBXZWIg
YnJvd3NlcnMgaW1wb3NlIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzLiBPbmUgZXhhbXBsZSBpcyB0
aGF0IGJyb3dzZXJzIHRlbmQgdG8gb3BlbiBtdWx0aXBsZSBUTFMgc2Vzc2lvbnMgYW5kIGNvbm5l
Y3Rpb25zIHRvIHRoZSB0YXJnZXQgc2VydmVyLCBhbmQgdGhlIHNhbWUgc2VjdXJpdHkgdG9rZW4g
Y2FuIGJlIHRyYW5zbWl0dGVkIG92ZXIgYW55IG9mIHRoZXNlIHNlc3Npb25zL2Nvbm5lY3Rpb25z
LiBTbyB0aGUgdG9rZW4gYmluZGluZyBzb2x1dGlvbiBoYXMgdG8gYWNjb21tb2RhdGUgc3VjaCB1
c2FnZSwgaS5lLiB0aGUgYmluZGluZyBtdXN0IGJlIHZlcmlmaWFibGUgcmVnYXJkbGVzcyBvZiB3
aGljaCBvZiB0aGUgVExTIGNvbm5lY3Rpb25zIHdhcyB1c2VkIHRvIHRyYW5zbWl0IHRoZSB0b2tl
bi4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy
b206IEhhbm5lcyBUc2Nob2ZlbmlnIFttYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldDxt
YWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD5dDQpTZW50OiBUaHVyc2RheSwgSmFudWFy
eSAxNSwgMjAxNSA5OjM5IEFNDQpUbzogQW5kcmVpIFBvcG92DQpDYzogdW5iZWFyYWJsZUBpZXRm
Lm9yZzxtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJs
ZV0gVXBkYXRlZCBDaGFydGVyIFByb3Bvc2FsDQoNCkFuZHJlaSwNCg0KPiBBIG5ldyBkZXNpZ24g
Z29hbDogdGhlIHNvbHV0aW9uIG11c3Qgd29yayBmb3IgV2ViIGJyb3dzZXJzLiBFLmcuIHRoaXMN
Cj4gbWVhbnMgdGhhdCBzZWN1cml0eSB0b2tlbnMgbXVzdCBiZSBwcmVzZW50YWJsZSBvdmVyIG11
bHRpcGxlIFRMUw0KPiBzZXNzaW9ucyBhbmQgY29ubmVjdGlvbnMuDQoNCkNvdWxkIHlvdSBleHBs
YWluIHdoYXQgbW90aXZhdGVkIHRoaXMgZGVzaWduIGdvYWw/IFdoYXQgd291bGQgcHJldmVudCB5
b3UgZnJvbSB1c2luZyB0b2tlbnMgb3ZlciBtb3JlIHRoYW4gb25lIFRMUyBleGNoYW5nZT8gSXMg
dGhlcmUgYSBzcGVjaWZpYyB1c2UgY2FzZSB5b3UgaGF2ZSBpbiBtaW5kPw0KDQpDaWFvDQpIYW5u
ZXMNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KVW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5i
ZWFyYWJsZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
dW5iZWFyYWJsZQ0KDQo=

--_000_BN3PR0301MB1250DF6F834382D70B50B0BB8C4E0BN3PR0301MB1250_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs
LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu
LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh
dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBpbmRlZWQgcGFydCBvZiB3aGF0
IHRoZSBjdXJyZW50IC0wMCBJLURzIG9mZmVyLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj5XZSBzaG91bGQgbm90IGVxdWF0ZSBjbGllbnRzIHdpdGggV2ViIGJy
b3dzZXJzLCBidXQgdGhlIGJyb3dzZXIgdXNlIGNhc2UgaXMgc29tZXdoYXQgc3BlY2lhbCBhbmQg
aW1wb3J0YW50IHRvIGFkZHJlc3MsIHRoZXJlZm9yZSBJIHRoaW5rIGl0IGRlc2VydmVzIG1lbnRp
b24gYW1vbmcNCiB0aGUgZ29hbHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv
bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWYiPiBCaWxsIE1pbGxzIFttYWlsdG86d21pbGxzXzkyMTA1QHlhaG9vLmNvbV0NCjxicj4N
CjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFyeSAxNSwgMjAxNSAxMTo1OSBBTTxicj4NCjxi
PlRvOjwvYj4gQW5kcmVpIFBvcG92OyBIYW5uZXMgVHNjaG9mZW5pZzxicj4NCjxiPkNjOjwvYj4g
dW5iZWFyYWJsZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVd
IFVwZGF0ZWQgQ2hhcnRlciBQcm9wb3NhbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+
DQo8ZGl2IGlkPSJ5dWlfM18xNl8wXzFfMTQyMTI4MjY0NDc0MV8xMDAzMDciPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6YmxhY2siPkknbSBzdGlsbCB0cnlpbmcgdG8gZ2V0IG15IGhlYWQgYXJvdW5kIHdoYXQgdGhl
ICZxdW90O2VsZXZhdG9yIHBpdGNoJnF1b3Q7IGlzIGZvciB0aGlzLCBJIGRvbid0IHRoaW5rIGl0
J3MgYmVlbiBhZGVxdWF0ZWx5IGV4cHJlc3NlZCB5ZXQuICZuYnNwO0lzIGl0DQogY2xvc2UgdG8g
c2F5IHRoaXMgaXMgYWxsIGFib3V0ICZxdW90O0NsaWVudHMgKGJyb3dzZXJzKSBiZWluZyBhYmxl
IHRvIHRpZSBjcmVkZW50aWFscyB0byBsb2NhbGx5IGdlbmVyYXRlZCBhbmQgbWFuYWdlZCBrZXlz
IGFuZCBhc3NlcnQgdGhhdCBrZXkgdG8gdGhlIGF1dGggc2VydmljZS4mcXVvdDs/PG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv
dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PbiBUaHVyc2RheSwgSmFudWFy
eSAxNSwgMjAxNSAxMTowMiBBTSwgQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5k
cmVpLlBvcG92QG1pY3Jvc29mdC5jb20iPkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZn
dDsgd3JvdGU6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFj
a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjpibGFjayI+SGkgSGFubmVzLDxicj4NCjxicj4NClRoZSBpZGVhIGhlcmUgaXMgdGhhdCBX
ZWIgYnJvd3NlcnMgaW1wb3NlIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzLiBPbmUgZXhhbXBsZSBp
cyB0aGF0IGJyb3dzZXJzIHRlbmQgdG8gb3BlbiBtdWx0aXBsZSBUTFMgc2Vzc2lvbnMgYW5kIGNv
bm5lY3Rpb25zIHRvIHRoZSB0YXJnZXQgc2VydmVyLCBhbmQgdGhlIHNhbWUgc2VjdXJpdHkgdG9r
ZW4gY2FuIGJlIHRyYW5zbWl0dGVkIG92ZXIgYW55IG9mIHRoZXNlIHNlc3Npb25zL2Nvbm5lY3Rp
b25zLiBTbw0KIHRoZSB0b2tlbiBiaW5kaW5nIHNvbHV0aW9uIGhhcyB0byBhY2NvbW1vZGF0ZSBz
dWNoIHVzYWdlLCBpLmUuIHRoZSBiaW5kaW5nIG11c3QgYmUgdmVyaWZpYWJsZSByZWdhcmRsZXNz
IG9mIHdoaWNoIG9mIHRoZSBUTFMgY29ubmVjdGlvbnMgd2FzIHVzZWQgdG8gdHJhbnNtaXQgdGhl
IHRva2VuLjxicj4NCjxicj4NCkNoZWVycyw8YnI+DQo8YnI+DQpBbmRyZWk8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8ZGl2IGlkPSJ5cXRmZDYyNjIzIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxicj4NCi0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogSGFubmVzIFRzY2hvZmVuaWcgW21haWx0bzo8YSBocmVm
PSJtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldCI+aGFubmVzLnRzY2hvZmVuaWdAZ214
Lm5ldDwvYT5dDQo8YnI+DQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAxNSwgMjAxNSA5OjM5IEFN
PGJyPg0KVG86IEFuZHJlaSBQb3Bvdjxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86dW5iZWFyYWJs
ZUBpZXRmLm9yZyI+dW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTogW1Vu
YmVhcmFibGVdIFVwZGF0ZWQgQ2hhcnRlciBQcm9wb3NhbDxicj4NCjxicj4NCkFuZHJlaSw8YnI+
DQo8YnI+DQomZ3Q7IEEgbmV3IGRlc2lnbiBnb2FsOiB0aGUgc29sdXRpb24gbXVzdCB3b3JrIGZv
ciBXZWIgYnJvd3NlcnMuIEUuZy4gdGhpcyA8YnI+DQomZ3Q7IG1lYW5zIHRoYXQgc2VjdXJpdHkg
dG9rZW5zIG11c3QgYmUgcHJlc2VudGFibGUgb3ZlciBtdWx0aXBsZSBUTFMgPGJyPg0KJmd0OyBz
ZXNzaW9ucyBhbmQgY29ubmVjdGlvbnMuPGJyPg0KPGJyPg0KQ291bGQgeW91IGV4cGxhaW4gd2hh
dCBtb3RpdmF0ZWQgdGhpcyBkZXNpZ24gZ29hbD8gV2hhdCB3b3VsZCBwcmV2ZW50IHlvdSBmcm9t
IHVzaW5nIHRva2VucyBvdmVyIG1vcmUgdGhhbiBvbmUgVExTIGV4Y2hhbmdlPyBJcyB0aGVyZSBh
IHNwZWNpZmljIHVzZSBjYXNlIHlvdSBoYXZlIGluIG1pbmQ/PGJyPg0KPGJyPg0KQ2lhbzxicj4N
Ckhhbm5lczxicj4NCjxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyPg0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3Q8YnI+DQo8
YSBocmVmPSJtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZyI+VW5iZWFyYWJsZUBpZXRmLm9yZzwv
YT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Vu
YmVhcmFibGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3VuYmVhcmFibGU8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3
aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z
LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+
DQo=

--_000_BN3PR0301MB1250DF6F834382D70B50B0BB8C4E0BN3PR0301MB1250_--


From nobody Thu Jan 15 13:26:42 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED30A1A90C4 for ; Thu, 15 Jan 2015 13:26:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.191
X-Spam-Level: *
X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 PxltNrpK34un for ; Thu, 15 Jan 2015 13:26:38 -0800 (PST)
Received: from nm5-vm0.bullet.mail.bf1.yahoo.com (nm5-vm0.bullet.mail.bf1.yahoo.com [98.139.213.150]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428121A90C2 for ; Thu, 15 Jan 2015 13:26:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1421357197; bh=FVlixlPyxJp/ER64n9pYkmGZW0pVB+zuml2H2Lyw/TE=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=PgcG1fJnYfo81PngexZQiLDehqH5n1dPJ9zD1aSDS7H8JVjRHy8hzGOkDR7THsBoXElOJOhStSmcsKarSV70+S5idFGPukNFxiH79uu68BO0xx3wIAqOfvBNwfBi1yTPnuFfZzShH9sHBkUkUz1GVETcRLgAwJYpn08lKjBZRMOLe+ZawqkywHoAFfN1pUCDn1zWnJEHnD8zz8FifSEsF96qZ4z+xERqYYM/r4UH2Jheusbm7uk6V6y74Oz9lf+ueK9g9L6AGHHCTpIO7Kx8jG99qp+ZSahUc7Au/BDUqRr8Y8BloGPiaVDkxRI7NmlGCl5ptzPgE+pGDTRJC4fzaw==
Received: from [66.196.81.172] by nm5.bullet.mail.bf1.yahoo.com with NNFMP; 15 Jan 2015 21:26:37 -0000
Received: from [98.139.212.233] by tm18.bullet.mail.bf1.yahoo.com with NNFMP;  15 Jan 2015 21:26:37 -0000
Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 15 Jan 2015 21:26:37 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 527143.7062.bm@omp1042.mail.bf1.yahoo.com
X-YMail-OSG: _2tYlZIVM1lWbl7T1FW4.WjwWDJGbSAk37aCgyAzv3S0OFiFQGx9V0b.33Ll3uq 6Wkd2xJxNUZe61yq2AnVluSeWBq1AV_xJ.QS2u2ORKhEdMuduH7irN8PziW23F1eKeyVeivWnqL4 Z.kRZtvQBAqdog6C4m5WdWPJL9EYfhQq2FTT6l9GTcKj4nh9LszFElKfxvGX5h9DwLXMLVWKgO6E sfURKSlmHTMvgC4hBgPYYBASQGgy2lqz87z3cRWkhsFFIT_iIOl0Cpc8.H.dEgnQ.uybdMBzA_1_ WGHMGxIghM40WBBwem_ROojQCuzI7OJcio97fD4yTYBMch8HdYgNw4kYBJX7u0xZRMix9bfb8MSC 4LGQDuqanFeH.5e_k0Tt0JsmN.BDSAccmGoGbF97NemvCZU0u.jxLv9wj7cMs2TGULVPf8xXfzR8 xmMU_mIepIYSbWKvwIoixImU0laJNMtdM89PoeQlyKIFWspcf1BOnCRuNzuieX1caGaltkIwn6bx pp_fExMwS6Mw-
Received: by 66.196.80.151; Thu, 15 Jan 2015 21:26:37 +0000 
Date: Thu, 15 Jan 2015 21:26:36 +0000 (UTC)
From: Bill Mills 
To: Andrei Popov ,  Hannes Tschofenig 
Message-ID: <558984605.1823640.1421357196673.JavaMail.yahoo@jws10688.mail.bf1.yahoo.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_1823639_1627547287.1421357196658"
Archived-At: 
Cc: "unbearable@ietf.org" 
Subject: Re: [Unbearable] Updated Charter Proposal
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Jan 2015 21:26:40 -0000

------=_Part_1823639_1627547287.1421357196658
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Agreed that browsers are a special and very popular case of clients and nee=
d specific considerations.=20

     On Thursday, January 15, 2015 12:43 PM, Andrei Popov  wrote:
  =20

 #yiv8300964038 #yiv8300964038 -- _filtered #yiv8300964038 {font-family:Hel=
vetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv8300964038 {panose-1:2=
 4 5 3 5 4 6 3 2 4;} _filtered #yiv8300964038 {font-family:Calibri;panose-1=
:2 15 5 2 2 2 4 3 2 4;}#yiv8300964038 #yiv8300964038 p.yiv8300964038MsoNorm=
al, #yiv8300964038 li.yiv8300964038MsoNormal, #yiv8300964038 div.yiv8300964=
038MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv830096=
4038 a:link, #yiv8300964038 span.yiv8300964038MsoHyperlink {color:blue;text=
-decoration:underline;}#yiv8300964038 a:visited, #yiv8300964038 span.yiv830=
0964038MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv83=
00964038 span.yiv8300964038EmailStyle17 {color:#1F497D;}#yiv8300964038 .yiv=
8300964038MsoChpDefault {font-size:10.0pt;} _filtered #yiv8300964038 {margi=
n:1.0in 1.0in 1.0in 1.0in;}#yiv8300964038 div.yiv8300964038WordSection1 {}#=
yiv8300964038 This is indeed part of what the current -00 I-Ds offer.  =C2=
=A0 We should not equate clients with Web browsers, but the browser use cas=
e is somewhat special and important to address, therefore I think it deserv=
es mention among the goals.  =C2=A0 From: Bill Mills [mailto:wmills_92105@y=
ahoo.com]
Sent: Thursday, January 15, 2015 11:59 AM
To: Andrei Popov; Hannes Tschofenig
Cc: unbearable@ietf.org
Subject: Re: [Unbearable] Updated Charter Proposal  =C2=A0 I'm still trying=
 to get my head around what the "elevator pitch" is for this, I don't think=
 it's been adequately expressed yet. =C2=A0Is it close to say this is all a=
bout "Clients (browsers) being able to tie credentials to locally generated=
 and managed keys and assert that key to the auth service."?  =C2=A0 On Thu=
rsday, January 15, 2015 11:02 AM, Andrei Popov =
 wrote:  =C2=A0 Hi Hannes,

The idea here is that Web browsers impose additional requirements. One exam=
ple is that browsers tend to open multiple TLS sessions and connections to =
the target server, and the same security token can be transmitted over any =
of these sessions/connections. So the token binding solution has to accommo=
date such usage, i.e. the binding must be verifiable regardless of which of=
 the TLS connections was used to transmit the token.

Cheers,

Andrei=20
-----Original Message-----
From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]
Sent: Thursday, January 15, 2015 9:39 AM
To: Andrei Popov
Cc: unbearable@ietf.org
Subject: Re: [Unbearable] Updated Charter Proposal

Andrei,

> A new design goal: the solution must work for Web browsers. E.g. this=20
> means that security tokens must be presentable over multiple TLS=20
> sessions and connections.

Could you explain what motivated this design goal? What would prevent you f=
rom using tokens over more than one TLS exchange? Is there a specific use c=
ase you have in mind?

Ciao
Hannes



_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable  =C2=A0=20
_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable


   
------=_Part_1823639_1627547287.1421357196658
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


Agreed that browsers are a special and very popular case of clients and need specific considerations.
 


 
 
 
  On Thursday, January 15, 2015 12:43 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
  
  

 




This is indeed part of what the current -00 I-Ds offer.

 

  
 

We should not equate clients with Web browsers, but the browser use case is somewhat special and important to address, therefore I think it deserves mention among
 the goals.
 

  
 





From: Bill Mills [mailto:wmills_92105@yahoo.com]


Sent: Thursday, January 15, 2015 11:59 AM

To: Andrei Popov; Hannes Tschofenig

Cc: unbearable@ietf.org

Subject: Re: [Unbearable] Updated Charter Proposal
 





  
 





I'm still trying to get my head around what the "elevator pitch" is for this, I don't think it's been adequately expressed yet.  Is it
 close to say this is all about "Clients (browsers) being able to tie credentials to locally generated and managed keys and assert that key to the auth service."?
 





  
 











On Thursday, January 15, 2015 11:02 AM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
 



  
 



Hi Hannes,



The idea here is that Web browsers impose additional requirements. One example is that browsers tend to open multiple TLS sessions and connections to the target server, and the same security token can be transmitted over any of these sessions/connections. So
 the token binding solution has to accommodate such usage, i.e. the binding must be verifiable regardless of which of the TLS connections was used to transmit the token.



Cheers,



Andrei
 





-----Original Message-----

From: Hannes Tschofenig [mailto:hannes.tschofenig@gmx.net]


Sent: Thursday, January 15, 2015 9:39 AM

To: Andrei Popov

Cc: unbearable@ietf.org

Subject: Re: [Unbearable] Updated Charter Proposal



Andrei,



> A new design goal: the solution must work for Web browsers. E.g. this 

> means that security tokens must be presentable over multiple TLS 

> sessions and connections.



Could you explain what motivated this design goal? What would prevent you from using tokens over more than one TLS exchange? Is there a specific use case you have in mind?



Ciao

Hannes







_______________________________________________

Unbearable mailing list

Unbearable@ietf.org

https://www.ietf.org/mailman/listinfo/unbearable
 



  
 














_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable


  
 
  
 

------=_Part_1823639_1627547287.1421357196658--


From nobody Tue Jan 20 16:07:22 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A639D1A00B6 for ; Tue, 20 Jan 2015 16:07:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 2gYxBPr-dK_0 for ; Tue, 20 Jan 2015 16:07:13 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0123.outbound.protection.outlook.com [65.55.169.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E0E71A00BF for ; Tue, 20 Jan 2015 16:07:13 -0800 (PST)
Received: from BN3PR0301MB1252.namprd03.prod.outlook.com (25.161.207.28) by BN3PR0301MB1204.namprd03.prod.outlook.com (25.161.207.16) with Microsoft SMTP Server (TLS) id 15.1.59.20; Wed, 21 Jan 2015 00:07:12 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1252.namprd03.prod.outlook.com (25.161.207.28) with Microsoft SMTP Server (TLS) id 15.1.59.20; Wed, 21 Jan 2015 00:07:10 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0059.007; Wed, 21 Jan 2015 00:07:10 +0000
From: Andrei Popov 
To: John Bradley , "unbearable@ietf.org" 
Thread-Topic: [Unbearable] Updated Charter Proposal
Thread-Index: AdAwVoQybrCT+HkuTniRvdMsDdHeWgAkZqIAAAL3ZlAAAwXvAAEDcGvA
Date: Wed, 21 Jan 2015 00:07:09 +0000
Message-ID: 
References:    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::3]
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; 
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(3005004); SRVR:BN3PR0301MB1252; UriScan:; 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1252; 
x-forefront-prvs: 04631F8F77
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(199003)(164054003)(377454003)(189002)(54356999)(561944003)(2420400003)(64706001)(2950100001)(74316001)(102836002)(97736003)(87936001)(2656002)(46102003)(2900100001)(93886004)(68736005)(33656002)(15975445007)(2501002)(76176999)(19580405001)(101416001)(19580395003)(86612001)(99286002)(77156002)(16236675004)(40100003)(54606007)(106356001)(86362001)(54206007)(62966003)(92566002)(105586002)(19609705001)(50986999)(76576001)(107886001)(19625215002)(122556002)(19300405004)(19617315012)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1252; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB12507F9EAC36237984E69B3A8C480BN3PR0301MB1250_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2015 00:07:10.0461 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1252
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1204;
X-OriginatorOrg: microsoft.onmicrosoft.com
Archived-At: 
Subject: Re: [Unbearable] Updated Charter Proposal
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Jan 2015 00:07:19 -0000

--_000_BN3PR0301MB12507F9EAC36237984E69B3A8C480BN3PR0301MB1250_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I believe I've addressed the feedback received so far; the updated charter =
draft is on GitHub for easy authoring:
https://github.com/TokenBinding/WG-Charter

Pull requests are welcome,

Thanks,

Andrei

From: John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Thursday, January 15, 2015 12:16 PM
To: Andrei Popov
Cc: unbearable@ietf.org
Subject: Re: [Unbearable] Updated Charter Proposal

A couple more possible clarifications.



2.            Specify the use of the Token Binding protocol in combination =
with HTTPS.

HTTPS is probably intended to be shorthand for a http binding for TLS + tok=
en Binding as is defined in "Token Binding over HTTP"  [https://tools.ietf.=
org/html/draft-balfanz-https-token-binding-00].

This is a binding to HTTP (via a new header) and to HTML  (via XML HTTP req=
uest).

If we also say that possible future binding may be a SASSL/GSS-API binding =
for TLS + token binding   (The sassl-oauth spec https://tools.ietf.org/html=
/draft-ietf-kitten-sasl-oauth-18 might use such a thing.)


One other thing I note in the drafts, is that at no point are  tokens defin=
ed or even really discussed other than as something that applications can b=
ind to the exposed public key.
The applications will bind tokens to the keys exposed by the specs via the =
bindings.   The naming may slightly misdirect people, but there have alread=
y been too many names for this so I won't push the point.

I think keeping this down close to the TLS layer and defining bindings to H=
TTP and other protocols is in scope.
Encouraging applications that use protocols like HTTP + TLS to use the bind=
ings to bind there security tokens/cookies is in scope.

I think defining the extensions for those applications to use the bindings =
is should be up to the applications themselves where there is active partic=
ipation.

Trying to extend this to cover end to end message signing outside of a TLS =
session should be expressly out of scope.

We may however want to say something about how a TLS session terminated on =
a TLS device can have the Token Binding ID for the session passed in a HTTP=
 header.
That and possibly some other TLS appliance issues are in scope for "Token B=
inding over HTTP"

Regards
John B.



On Jan 15, 2015, at 3:52 PM, Andrei Popov > wrote:

Thanks John; both suggestions make sense to me; will rephrase in the next r=
evision.

Cheers,

Andrei

From: John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Thursday, January 15, 2015 9:25 AM
To: Andrei Popov
Cc: unbearable@ietf.org
Subject: Re: [Unbearable] Updated Charter Proposal

I am generally in agrement.

A couple of points.

Under design goals change 1 to.

1.   Allow applications to prevent the export and replay of security tokens=
.

You could make that applications and protocols if you like as some people m=
ay see things like OAuth as a protocol vs an application.
The point being that the goal is to provide the hooks for things a layer ab=
ove these specifications to make security decisions, not the token binding =
protocol itself.


In 3 you use the term federation.  That may be larger in scope than what I =
think you intend from the two drafts.
Federation is a much larger topic than allowing the public key from one con=
nection to be exposed in a connection to a second party via some sort of ex=
press consent from the first party.

Shrinking the scope to how public keys may be shared with permission to thi=
rd parties may make some people more comfortable, if they are concerned tha=
t this is trying to be a new federation protocol to compete with SAML or OA=
uth.

Regards
John B.

On Jan 14, 2015, at 9:14 PM, Andrei Popov > wrote:

The discussion on this mailing list has subsided over the holidays, so I lo=
oked through the messages for feedback regarding the proposed charter and i=
ncorporated a couple of changes suggested so far:
1. A new design goal: the solution must work for Web browsers. E.g. this me=
ans that security tokens must be presentable over multiple TLS sessions and=
 connections.
2. Removed specific milestone dates.

Looking forward to more discussion of the charter,

Thanks,

Andrei

_____________________________________________________
Token Binding (TB)

Charter for Working Group

Web services generate various security tokens (e.g.  HTTP cookies, OAuth to=
kens, etc.) for web applications to access protected resources. Currently t=
hese are bearer tokens, i.e. any party in possession of such token gains ac=
cess to the protected resource. Attackers export bearer tokens from client =
machines or from compromised network connections, present these bearer toke=
ns to Web services, and impersonate authenticated users. The idea of Token =
Binding is to enable defense against such attacks by cryptographically bind=
ing security tokens to the TLS layer.

The tasks of this working group are as follows:
1.            Specify the Token Binding protocol v1.0.
2.            Specify the use of the Token Binding protocol in combination =
with HTTPS.

It is a goal of this working group to enable defense against attacks that i=
nvolve unauthorized replay of security tokens, but other issues associated =
with the use of security tokens are out of scope. It is a goal of this work=
ing group to design the Token Binding protocol such that it would be also u=
seable with application protocols other than HTTPS, however specifying such=
 uses is not a primary goal.

Some of the main design goals for the Token Binding protocol, in no particu=
lar order:
1.            Prevent export and replay of security tokens.
2.            Allow strong key protection, e.g. using hardware-bound keys.
3.            Support both first-party and federation scenarios.
4.            Preserve user privacy.
5.            Make the Token Binding protocol useable in combination with a=
 variety of application protocols.
6.            Allow the negotiation of the Token Binding protocol without a=
dditional round-trips.
7.            Allow the use of multiple cryptographic algorithms, so that a=
 variety of secure hardware modules with different cryptographic capabiliti=
es could be used with Token Binding.
8.            Propose Token Binding spec that can be implemented in Web bro=
wsers (but is not limited to them). E.g. Web browsers require that the same=
 bound security token must be presentable over multiple TLS sessions and co=
nnections.

The working group will use the following documents as a starting point for =
its work:
-             draft-popov-token-binding-00;
-             draft-balfanz-https-token-binding-00.

This WG will collaborate with other IETF WGs, in particular with the TLS, H=
TTPbis and Oauth WGs.

Milestones:
-            WG document for the Token Binding Protocol v1.0.
-            WG document for HTTPS Token Binding.
-            Token Binding Protocol v1.0 to IESG.
-            HTTPS Token Binding to IESG.
_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable


--_000_BN3PR0301MB12507F9EAC36237984E69B3A8C480BN3PR0301MB1250_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I believe I’ve addressed the fe=
edback received so far; the updated charter draft is on GitHub for easy aut=
horing:


https://github.com/TokenBinding/WG-Charter=



 


Pull requests are welcome,=



 


Thanks,


 


Andrei


 






From: John Bradley [mailto:ve7jtb@ve=
7jtb.com]


Sent: Thursday, January 15, 2015 12:16 PM

To: Andrei Popov

Cc: unbearable@ietf.org

Subject: Re: [Unbearable] Updated Charter Proposal=







 


A couple more possible clarifications.



 






 




 




















2.        &=
nbsp;   Specify the use of the Token Binding protocol in combinat=
ion with HTTPS.
















 






HTTPS is probably intended to be shorthand for a htt=
p binding for TLS + token Binding as is defined in "Token Binding =
over HTTP"  [https://tools.ietf.org/html/draft-balfanz-https-to=
ken-binding-00].






 






This is a binding to HTTP (via a new header) and to =
HTML  (via XML HTTP request).  






 






If we also say that possible future binding may be a=
 SASSL/GSS-API binding for TLS + token binding   (The sassl-oauth =
spec
htt=
ps://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 might use=
 such a thing.)






 






 






One other thing I note in the drafts, is that at no =
point are  tokens defined or even really discussed other than as somet=
hing that applications can bind to the exposed public key.






The applications will bind tokens to the keys expose=
d by the specs via the bindings.   The naming may slightly misdirect p=
eople, but there have already been too many names for this so I won't push =
the point.






 






I think keeping this down close to the TLS layer and=
 defining bindings to HTTP and other protocols is in scope.






Encouraging applications that use protocols like HTT=
P + TLS to use the bindings to bind there security tokens/cookies is in=
 scope.






 






I think defining the extensions for those applicatio=
ns to use the bindings is should be up to the applications themselves where=
 there is active participation.






 






Trying to extend this to cover end to end message si=
gning outside of a TLS session should be expressly out of scope.=







 






We may however want to say something about how a TLS=
 session terminated on a TLS device can have the Token Binding ID for the s=
ession passed in a HTTP header.






That and possibly some other TLS appliance issues ar=
e in scope for "Token Binding over HTTP"






 






Regards






John B.






 






 






 












On Jan 15, 2015, at 3:52 PM, Andrei Popov <Andrei.Popov@microsoft.com> =
wrote:




 






Thanks John; both suggestions make se=
nse to me; will rephrase in the next revision.






 






Cheers,






 






Andrei






 










From: John
 Bradley [mailto:ve7jtb@ve7jtb.com=
] 

Sent: Thursday, Ja=
nuary 15, 2015 9:25 AM

To: Andrei Popov
Cc: unbearable@ietf.org

Subject: Re: [Unbe=
arable] Updated Charter Proposal










 






I am generally in agrement.








 










A couple of points.










 










Under design goals change 1 to.










 










1.   Allow applications to prevent the export a=
nd replay of security tokens.










 










You could make that applications and protocols if yo=
u like as some people may see things like OAuth as a protocol vs an applica=
tion. 










The point being that the goal is to provide the hook=
s for things a layer above these specifications to make security decisions,=
 not the token binding protocol itself.










 










 










In 3 you use the term federation.  That may be =
larger in scope than what I think you intend from the two drafts.










Federation is a much larger topic than allowing the =
public key from one connection to be exposed in a connection to a second pa=
rty via some sort of express consent from the first party.










 










Shrinking the scope to how public keys may be shared=
 with permission to third parties may make some people more comfortable, if=
 they are concerned that this is trying to be a new federation protocol to =
compete with SAML or OAuth.










 










Regards










John B.










 
















On Jan 14, 2015, at 9:14 PM, Andrei Popov <Andrei=
.Popov@microsoft.com> wrote:








 










The discussion on this mailing list has subsided ov=
er the holidays, so I looked through the messages for feedback regarding th=
e proposed charter and incorporated a couple of
 changes suggested so far:










1. A new design goal: the solution must work for We=
b browsers. E.g. this means that security tokens must be presentable over m=
ultiple TLS sessions and connections.










2. Removed specific milestone dates.










 










Looking forward to more discussion of the charter,<=
/span>










 










Thanks,










 










Andrei










 










___________________________________________________=
__










Token Binding (TB)










 










Charter for Working Group










 










Web services generate various security tokens (e.g.=
  HTTP cookies, OAuth tokens, etc.) for web applications to access pro=
tected resources. Currently these are bearer tokens,
 i.e. any party in possession of such token gains access to the protected r=
esource. Attackers export bearer tokens from client machines or from compro=
mised network connections, present these bearer tokens to Web services, and=
 impersonate authenticated users.
 The idea of Token Binding is to enable defense against such attacks by cry=
ptographically binding security tokens to the TLS layer.<=
/p>









 










The tasks of this working group are as follows:










1.        &=
nbsp;   Specify the Token Binding protocol v1.0.










2.        &=
nbsp;   Specify the use of the Token Binding protocol in combinat=
ion with HTTPS.










 










It is a goal of this working group to enable defens=
e against attacks that involve unauthorized replay of security tokens, but =
other issues associated with the use of security
 tokens are out of scope. It is a goal of this working group to design the =
Token Binding protocol such that it would be also useable with application =
protocols other than HTTPS, however specifying such uses is not a primary g=
oal.










 










Some of the main design goals for the Token Binding=
 protocol, in no particular order:










1.        &=
nbsp;   Prevent export and replay of security tokens.=











2.        &=
nbsp;   Allow strong key protection, e.g. using hardware-bound ke=
ys.










3.        &=
nbsp;   Support both first-party and federation scenarios.=











4.        &=
nbsp;   Preserve user privacy.










5.        &=
nbsp;   Make the Token Binding protocol useable in combination wi=
th a variety of application protocols.










6.        &=
nbsp;   Allow the negotiation of the Token Binding protocol witho=
ut additional round-trips.










7.        &=
nbsp;   Allow the use of multiple cryptographic algorithms, so th=
at a variety of secure hardware modules with different cryptographic capabi=
lities could be used with
 Token Binding.










8.        &=
nbsp;   Propose Token Binding spec that can be implemented in Web=
 browsers (but is not limited to them). E.g. Web browsers require that the =
same bound security token
 must be presentable over multiple TLS sessions and connections.










 










The working group will use the following documents =
as a starting point for its work:










-        &n=
bsp;    draft-popov-token-binding-00;










-        &n=
bsp;    draft-balfanz-https-token-binding-00.










 










This WG will collaborate with other IETF WGs, in pa=
rticular with the TLS, HTTPbis and Oauth WGs.










 










Milestones:










-        &n=
bsp;   WG document for the Token Binding Protocol v1.0.










-        &n=
bsp;   WG document for HTTPS Token Binding.










-        &n=
bsp;   Token Binding Protocol v1.0 to IESG.










-        &n=
bsp;   HTTPS Token Binding to IESG.








_______________________________________________
Unbearable mailing list

Unbearable@ie=
tf.org

https://www.ietf.org/mailman/listinfo/unbearable


















 










--_000_BN3PR0301MB12507F9EAC36237984E69B3A8C480BN3PR0301MB1250_--


From nobody Sat Jan 24 15:34:26 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD451A1B77 for ; Sat, 24 Jan 2015 15:34:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 8voIoGlOxAG0 for ; Sat, 24 Jan 2015 15:34:24 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E931A1B76 for ; Sat, 24 Jan 2015 15:34:23 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 65BDABEE4 for ; Sat, 24 Jan 2015 23:34:22 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2V-lXj_4JjAH for ; Sat, 24 Jan 2015 23:34:20 +0000 (GMT)
Received: from [10.87.48.73] (unknown [86.42.27.85]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 68B33BED1 for ; Sat, 24 Jan 2015 23:34:20 +0000 (GMT)
Message-ID: <54C42BFB.4040300@cs.tcd.ie>
Date: Sat, 24 Jan 2015 23:34:19 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "unbearable@ietf.org" 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Unbearable] moving ahead
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Jan 2015 23:34:25 -0000

Hiya,

Andrei has asked me about next steps for this work, based on the
draft charter text at [1].

I think that text is pretty good, but before I start the formal
WG chartering process I wanted to check here that there aren't
major problems with it.

Two things I noted myself were that it'd be good to see some
support from server implementers who are not also browser makers.
And secondly, we probably need to talk to W3C about this too,
as [2] seems to need changes to XHR, which is their spec. [3]
Both of those could however be taken care of as we go forward.

I did see Hannes' issue about TLS endpoint location and OAuth
and those are issues that need to be addressed but that I think
should be done in a WG.

So can folks who have new argument as to why this work is wrong,
or definitely needs a BoF or with other new substantive comments
please post those in the next few days. Or if you previously
posted a substantive comment that was not addressed (noting that
addressed != accepted) please post a link to that thread.

I'll look at what comes up and if there is nothing new I'll
probably start the WG chartering process around mid-week.
(To be clear: at present I don't think this one needs a BoF
in March, but could be a chartered WG before then.)

Cheers,
S.

PS: As a process thing, if we're moving ahead here, this will
appear as a place-holder in the BoF list for March so we can
schedule a session for the WG, if that is formed, or else use
that session for a BoF if one turns out to be needed.


[1]
https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Charter-Draft.txt
[2] https://tools.ietf.org/html/draft-balfanz-https-token-binding
[3] http://www.w3.org/TR/XMLHttpRequest/


From nobody Sat Jan 24 17:02:55 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15761A1BDE for ; Sat, 24 Jan 2015 17:02:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.509
X-Spam-Level: 
X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 MsITYf4rhzHe for ; Sat, 24 Jan 2015 17:02:52 -0800 (PST)
Received: from nm20.bullet.mail.bf1.yahoo.com (nm20.bullet.mail.bf1.yahoo.com [98.139.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11A701A1B7F for ; Sat, 24 Jan 2015 17:02:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1422147771; bh=/rlkhHfkjLy8eRzMB/L3ijl2RR5RlmvfdzbzEJL88+g=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=XIyT0kWe40p28kgnjUPrsgLflSjXrZbKxQijTGVz2c5s6H9k417wgRT/JkOuS6CZQldk2DReDXWk0b3U9LVaxw8MAajz+/d7xsDMUBgGNxPa7/DswT9o6eY0zUAHQ0jjKg9vo+HGRXOuxCWvUBA/Bk+UPkuZjeB7OcewytRLOyDaK0rihvFPhC7Edsdt05Wtq4/qcnQLxbTRhjmWUOMYezymofD4cCIFzAXS4oxr/Ahed3MEollW+FttJUP8rKNzQSrIHRI1tGnL73Ds691++6czP5TwHJyI57X2oHE2jsRqLgllXD8LPAuT3JK6CtJaAQAJEv8I+KX9+LtAutnLYw==
Received: from [98.139.215.142] by nm20.bullet.mail.bf1.yahoo.com with NNFMP;  25 Jan 2015 01:02:51 -0000
Received: from [98.139.212.222] by tm13.bullet.mail.bf1.yahoo.com with NNFMP;  25 Jan 2015 01:02:51 -0000
Received: from [127.0.0.1] by omp1031.mail.bf1.yahoo.com with NNFMP; 25 Jan 2015 01:02:51 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 317659.78000.bm@omp1031.mail.bf1.yahoo.com
X-YMail-OSG: KTbPhiQVM1lkScJIIwFgNgPmYLBWvUFdZl7j9KUDh73yYY.bqjJHfYhArMT1_QZ Ab59IC2TuX_nnJQ_bjlfhDobHWxtOmxNYDC8R7oQ.5fVXufYVFB6yqpkUkDh3cfrKoGORqOcx0fC d7V6I1axwuLVy9NRD1SahLKmTLygbUUWjMIoR9MSX2VE1Y7CsWFfAgfwpLPttueFv.xONi0D1xk1 xETHgGJjYzWXyun8jArNcytWr6M7WSOvwYlenuAKnNZaB3vo.KCpPMbAGP1WBWRH0W46.7M3V0zV GKwIzmhXpUQbra8r.RPNuLjdppWhkfjCaQZIG9fFRzXB5sW3zXAdbIBfTFr_iN7R6KR_gQOQ6VzZ ipJaJb83CY9boA.990g_Qlziq1y2GhusGqZvJMox9w_zmFd6hZyh6ywIDnNyjJz3kNeuFtjQwiOI 1Il0G3TQN23f3EFZVoDybvttJVXOSSMYsT7psux2.sc8ymBEpynLaQBzqBtNFxkq1LPUMOagsDYa WQU71cKZ4ZWXkMv1rFv8nJeFKxLkm3qNw6mrEfpYnA7xdAEppY_qxwqqyp5jt22NmrQVfbo3YoYc kidvoSJgQO0zLGfupyt4sylamHAmE49f0X9PgovxhF6mWXFH8W.W8s1TpnMpEoNgN5j6DhyqxtT4 K_K0htcDrr_PcojPTiXKaBu0fgr74z7jq7tcXxe5KtqwCk6L_aPnwXNbHiTbjJls-
Received: by 66.196.81.110; Sun, 25 Jan 2015 01:02:50 +0000 
Date: Sun, 25 Jan 2015 01:02:50 +0000 (UTC)
From: Bill Mills 
To: Stephen Farrell ,  "unbearable@ietf.org" 
Message-ID: <876072316.1451.1422147770584.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <54C42BFB.4040300@cs.tcd.ie>
References: <54C42BFB.4040300@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_1450_76638064.1422147770581"
Archived-At: 
Subject: Re: [Unbearable] moving ahead
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Jan 2015 01:02:55 -0000

------=_Part_1450_76638064.1422147770581
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think the current text of the charter is not descriptive of what this WG =
is really trying to solve. =C2=A0It reads as though this is about TLS chann=
el binding which is wrong. =C2=A0I'd like to see that fixed in the language=
 of the charter to be clearer.
There was a thread recently on what the elevator pitch for this is, and I t=
hink language similar to that shoudl be in the first paragraph.=20

     On Saturday, January 24, 2015 3:34 PM, Stephen Farrell  wrote:
  =20

=20
Hiya,

Andrei has asked me about next steps for this work, based on the
draft charter text at [1].

I think that text is pretty good, but before I start the formal
WG chartering process I wanted to check here that there aren't
major problems with it.

Two things I noted myself were that it'd be good to see some
support from server implementers who are not also browser makers.
And secondly, we probably need to talk to W3C about this too,
as [2] seems to need changes to XHR, which is their spec. [3]
Both of those could however be taken care of as we go forward.

I did see Hannes' issue about TLS endpoint location and OAuth
and those are issues that need to be addressed but that I think
should be done in a WG.

So can folks who have new argument as to why this work is wrong,
or definitely needs a BoF or with other new substantive comments
please post those in the next few days. Or if you previously
posted a substantive comment that was not addressed (noting that
addressed !=3D accepted) please post a link to that thread.

I'll look at what comes up and if there is nothing new I'll
probably start the WG chartering process around mid-week.
(To be clear: at present I don't think this one needs a BoF
in March, but could be a chartered WG before then.)

Cheers,
S.

PS: As a process thing, if we're moving ahead here, this will
appear as a place-holder in the BoF list for March so we can
schedule a session for the WG, if that is formed, or else use
that session for a BoF if one turns out to be needed.


[1]
https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Char=
ter-Draft.txt
[2] https://tools.ietf.org/html/draft-balfanz-https-token-binding
[3] http://www.w3.org/TR/XMLHttpRequest/

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable


   
------=_Part_1450_76638064.1422147770581
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I think the current text of the charte=
r is not descriptive of what this WG is really trying to solve.  It re=
ads as though this is about TLS channel binding which is wrong.  I'd l=
ike to see that fixed in the language of the charter to be clearer.<=
/div>

There w=
as a thread recently on what the elevator pitch for this is, and I think la=
nguage similar to that shoudl be in the first paragraph.
 


 
 
 
  On Saturday, January 24, 2015 3:34 PM, Stephen Farrell <ste=
phen.farrell@cs.tcd.ie> wrote:
  
  

 

Hiya,

Andrei has asked me about next steps =
for this work, based on the
draft charter text at [1].

I think th=
at text is pretty good, but before I start the formal
WG chartering proc=
ess I wanted to check here that there aren't
major problems with it.
=

Two things I noted myself were that it'd be good to see some
support=
 from server implementers who are not also browser makers.
And secondly,=
 we probably need to talk to W3C about this too,
as [2] seems to need ch=
anges to XHR, which is their spec. [3]
Both of those could however be ta=
ken care of as we go forward.

I did see Hannes' issue about TLS endp=
oint location and OAuth
and those are issues that need to be addressed b=
ut that I think
should be done in a WG.

So can folks who have new=
 argument as to why this work is wrong,
or definitely needs a BoF or wit=
h other new substantive comments
please post those in the next few days.=
 Or if you previously
posted a substantive comment that was not addresse=
d (noting that
addressed !=3D accepted) please post a link to that threa=
d.

I'll look at what comes up and if there is nothing new I'll
pr=
obably start the WG chartering process around mid-week.
(To be clear: at=
 present I don't think this one needs a BoF
in March, but could be a cha=
rtered WG before then.)

Cheers,
S.

PS: As a process thing,=
 if we're moving ahead here, this will
appear as a place-holder in the B=
oF list for March so we can
schedule a session for the WG, if that is fo=
rmed, or else use
that session for a BoF if one turns out to be needed.<=
br>

[1]
https://githu=
b.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Charter-Draft.txt=

[2] https://tools.ietf.org/html/draft-balfanz-http=
s-token-binding
[3] http://www.w3.org/TR/XMLHttpRequest/

________=
_______________________________________
Unbearable mailing list
Un=
bearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearab=
le


  
 
  
 

------=_Part_1450_76638064.1422147770581--


From nobody Sat Jan 24 17:30:16 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCCD21A0393 for ; Sat, 24 Jan 2015 17:30:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 Rnev6HJlkdKO for ; Sat, 24 Jan 2015 17:30:10 -0800 (PST)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A979D1A007C for ; Sat, 24 Jan 2015 17:30:09 -0800 (PST)
Received: by mail-la0-f47.google.com with SMTP id hz20so3026083lab.6 for ; Sat, 24 Jan 2015 17:30:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3I8QKCiFKPY2VnD9rYiyO2gF6BQRT2Q+1uaSTM7yiHw=; b=GcDFWOQqKG6VmBHgwZ3FFq41OgxrhQx+nB5rAiKoOVnzNxfHG/fV8+9Z9PDanWw2ZL rgmql95kB9uoTMGNewdGWGSaVX8Jw0bTv55TMOLztnUK9ECu2dBZs4p+TIRUM5sUgjXb ZorPVACe5IGELD9pixGnHwvZfTWorK9A6RnqCbs+Wjv8xtQMprtY5xzyUjEafbJwMsQi NF7YtFxu+o87eJsPgvlvZRorhrEpEq5DD3azORdMFTLqduSS78nF87sOSX/MgFsvYzvC NEsTwwrEgPbS8gJe2FpjSDcvJYdf6Fk4lzw4/y/d+BPr5B9gLB859CK/+C+C5ZoDq0HC ES8Q==
MIME-Version: 1.0
X-Received: by 10.112.158.200 with SMTP id ww8mr13418252lbb.89.1422149408111;  Sat, 24 Jan 2015 17:30:08 -0800 (PST)
Received: by 10.112.145.102 with HTTP; Sat, 24 Jan 2015 17:30:07 -0800 (PST)
In-Reply-To: 
References:     
Date: Sat, 24 Jan 2015 20:30:07 -0500
Message-ID: 
From: Kathleen Moriarty 
To: Andrei Popov 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: John Bradley , "unbearable@ietf.org" 
Subject: Re: [Unbearable] Updated Charter Proposal
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Jan 2015 01:30:13 -0000

Hi,

The charter looks like it is shaping up.  I just have some editorial
suggestions as the discussion continues, take them or leave them, not
a big deal.

Suggest changing from:
The idea of Token Binding is to enable defense against such attacks by
cryptographically binding
security tokens to the TLS layer.

To:
Token Binding enables defense against such attacks by cryptographically bin=
ding
security tokens to the TLS layer.

The word goal is used a bit much, but this is a personal preference -
take or leave the suggestions.  I suggest removing "Some" in the last
sentence listed as this only says the "main" goals/objectives, so
there is wiggle room still.

From:
It is a goal of this working group to enable defense against attacks
that involve unauthorized replay of
security tokens, but other issues associated with the use of security
tokens are out of scope. It is a goal
of this working group to design the Token Binding protocol such that
it would be also useable with
application protocols other than HTTPS, however specifying such uses
is not a primary goal.

Some of the main design goals for the Token Binding protocol, in no
particular order:

To:
It is a goal of this working group to enable defense against attacks
that involve unauthorized replay of
security tokens.  Other issues associated with the use of security
tokens are out of scope. Another goal
of this working group is to design the Token Binding protocol such
that it would be also useable with
application protocols other than HTTPS.  Specifying alternate
application protocols is not a primary goal.

The main design objectives for the Token Binding protocol, in no
particular order:

#8 - spec should probably be spelled out as specification.

Thanks,
Kathleen


On Tue, Jan 20, 2015 at 7:07 PM, Andrei Popov
 wrote:
> I believe I=E2=80=99ve addressed the feedback received so far; the update=
d charter
> draft is on GitHub for easy authoring:
>
> https://github.com/TokenBinding/WG-Charter
>
>
>
> Pull requests are welcome,
>
>
>
> Thanks,
>
>
>
> Andrei
>
>
>
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> Sent: Thursday, January 15, 2015 12:16 PM
>
>
> To: Andrei Popov
> Cc: unbearable@ietf.org
> Subject: Re: [Unbearable] Updated Charter Proposal
>
>
>
> A couple more possible clarifications.
>
>
>
>
>
>
>
> 2.            Specify the use of the Token Binding protocol in combinatio=
n
> with HTTPS.
>
>
>
> HTTPS is probably intended to be shorthand for a http binding for TLS +
> token Binding as is defined in "Token Binding over HTTP"
> [https://tools.ietf.org/html/draft-balfanz-https-token-binding-00].
>
>
>
> This is a binding to HTTP (via a new header) and to HTML  (via XML HTTP
> request).
>
>
>
> If we also say that possible future binding may be a SASSL/GSS-API bindin=
g
> for TLS + token binding   (The sassl-oauth spec
> https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 might use suc=
h a
> thing.)
>
>
>
>
>
> One other thing I note in the drafts, is that at no point are  tokens
> defined or even really discussed other than as something that application=
s
> can bind to the exposed public key.
>
> The applications will bind tokens to the keys exposed by the specs via th=
e
> bindings.   The naming may slightly misdirect people, but there have alre=
ady
> been too many names for this so I won't push the point.
>
>
>
> I think keeping this down close to the TLS layer and defining bindings to
> HTTP and other protocols is in scope.
>
> Encouraging applications that use protocols like HTTP + TLS to use the
> bindings to bind there security tokens/cookies is in scope.
>
>
>
> I think defining the extensions for those applications to use the binding=
s
> is should be up to the applications themselves where there is active
> participation.
>
>
>
> Trying to extend this to cover end to end message signing outside of a TL=
S
> session should be expressly out of scope.
>
>
>
> We may however want to say something about how a TLS session terminated o=
n a
> TLS device can have the Token Binding ID for the session passed in a HTTP
> header.
>
> That and possibly some other TLS appliance issues are in scope for "Token
> Binding over HTTP"
>
>
>
> Regards
>
> John B.
>
>
>
>
>
>
>
> On Jan 15, 2015, at 3:52 PM, Andrei Popov 
> wrote:
>
>
>
> Thanks John; both suggestions make sense to me; will rephrase in the next
> revision.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
> Sent: Thursday, January 15, 2015 9:25 AM
> To: Andrei Popov
> Cc: unbearable@ietf.org
> Subject: Re: [Unbearable] Updated Charter Proposal
>
>
>
> I am generally in agrement.
>
>
>
> A couple of points.
>
>
>
> Under design goals change 1 to.
>
>
>
> 1.   Allow applications to prevent the export and replay of security toke=
ns.
>
>
>
> You could make that applications and protocols if you like as some people
> may see things like OAuth as a protocol vs an application.
>
> The point being that the goal is to provide the hooks for things a layer
> above these specifications to make security decisions, not the token bind=
ing
> protocol itself.
>
>
>
>
>
> In 3 you use the term federation.  That may be larger in scope than what =
I
> think you intend from the two drafts.
>
> Federation is a much larger topic than allowing the public key from one
> connection to be exposed in a connection to a second party via some sort =
of
> express consent from the first party.
>
>
>
> Shrinking the scope to how public keys may be shared with permission to
> third parties may make some people more comfortable, if they are concerne=
d
> that this is trying to be a new federation protocol to compete with SAML =
or
> OAuth.
>
>
>
> Regards
>
> John B.
>
>
>
> On Jan 14, 2015, at 9:14 PM, Andrei Popov 
> wrote:
>
>
>
> The discussion on this mailing list has subsided over the holidays, so I
> looked through the messages for feedback regarding the proposed charter a=
nd
> incorporated a couple of changes suggested so far:
>
> 1. A new design goal: the solution must work for Web browsers. E.g. this
> means that security tokens must be presentable over multiple TLS sessions
> and connections.
>
> 2. Removed specific milestone dates.
>
>
>
> Looking forward to more discussion of the charter,
>
>
>
> Thanks,
>
>
>
> Andrei
>
>
>
> _____________________________________________________
>
> Token Binding (TB)
>
>
>
> Charter for Working Group
>
>
>
> Web services generate various security tokens (e.g.  HTTP cookies, OAuth
> tokens, etc.) for web applications to access protected resources. Current=
ly
> these are bearer tokens, i.e. any party in possession of such token gains
> access to the protected resource. Attackers export bearer tokens from cli=
ent
> machines or from compromised network connections, present these bearer
> tokens to Web services, and impersonate authenticated users. The idea of
> Token Binding is to enable defense against such attacks by cryptographica=
lly
> binding security tokens to the TLS layer.
>
>
>
> The tasks of this working group are as follows:
>
> 1.            Specify the Token Binding protocol v1.0.
>
> 2.            Specify the use of the Token Binding protocol in combinatio=
n
> with HTTPS.
>
>
>
> It is a goal of this working group to enable defense against attacks that
> involve unauthorized replay of security tokens, but other issues associat=
ed
> with the use of security tokens are out of scope. It is a goal of this
> working group to design the Token Binding protocol such that it would be
> also useable with application protocols other than HTTPS, however specify=
ing
> such uses is not a primary goal.
>
>
>
> Some of the main design goals for the Token Binding protocol, in no
> particular order:
>
> 1.            Prevent export and replay of security tokens.
>
> 2.            Allow strong key protection, e.g. using hardware-bound keys=
.
>
> 3.            Support both first-party and federation scenarios.
>
> 4.            Preserve user privacy.
>
> 5.            Make the Token Binding protocol useable in combination with=
 a
> variety of application protocols.
>
> 6.            Allow the negotiation of the Token Binding protocol without
> additional round-trips.
>
> 7.            Allow the use of multiple cryptographic algorithms, so that=
 a
> variety of secure hardware modules with different cryptographic capabilit=
ies
> could be used with Token Binding.
>
> 8.            Propose Token Binding spec that can be implemented in Web
> browsers (but is not limited to them). E.g. Web browsers require that the
> same bound security token must be presentable over multiple TLS sessions =
and
> connections.
>
>
>
> The working group will use the following documents as a starting point fo=
r
> its work:
>
> -             draft-popov-token-binding-00;
>
> -             draft-balfanz-https-token-binding-00.
>
>
>
> This WG will collaborate with other IETF WGs, in particular with the TLS,
> HTTPbis and Oauth WGs.
>
>
>
> Milestones:
>
> -            WG document for the Token Binding Protocol v1.0.
>
> -            WG document for HTTPS Token Binding.
>
> -            Token Binding Protocol v1.0 to IESG.
>
> -            HTTPS Token Binding to IESG.
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable
>
>
>
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable
>



--=20

Best regards,
Kathleen


From nobody Sat Jan 24 17:48:26 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354C01A1C02 for ; Sat, 24 Jan 2015 17:48:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 uEKE_zr4Na3Y for ; Sat, 24 Jan 2015 17:48:21 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961AD1A1BFE for ; Sat, 24 Jan 2015 17:48:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AFF69BEE5; Sun, 25 Jan 2015 01:48:19 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HnCAAVyiuyS; Sun, 25 Jan 2015 01:48:18 +0000 (GMT)
Received: from [10.87.48.73] (unknown [86.42.27.85]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2266FBE14; Sun, 25 Jan 2015 01:48:18 +0000 (GMT)
Message-ID: <54C44B61.9070207@cs.tcd.ie>
Date: Sun, 25 Jan 2015 01:48:17 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Bill Mills ,  "unbearable@ietf.org" 
References: <54C42BFB.4040300@cs.tcd.ie> <876072316.1451.1422147770584.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <876072316.1451.1422147770584.JavaMail.yahoo@mail.yahoo.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Unbearable] moving ahead
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Jan 2015 01:48:24 -0000

Hi Bill,

If you can send proposed text that'd be great. Absent that,
to be honest, I'm not sure what change you'd like,

Cheers,
S.

On 25/01/15 01:02, Bill Mills wrote:
> I think the current text of the charter is not descriptive of what
> this WG is really trying to solve.  It reads as though this is about
> TLS channel binding which is wrong.  I'd like to see that fixed in
> the language of the charter to be clearer. There was a thread
> recently on what the elevator pitch for this is, and I think language
> similar to that shoudl be in the first paragraph.
> 
> On Saturday, January 24, 2015 3:34 PM, Stephen Farrell
>  wrote:
> 
> 
> 
> Hiya,
> 
> Andrei has asked me about next steps for this work, based on the 
> draft charter text at [1].
> 
> I think that text is pretty good, but before I start the formal WG
> chartering process I wanted to check here that there aren't major
> problems with it.
> 
> Two things I noted myself were that it'd be good to see some support
> from server implementers who are not also browser makers. And
> secondly, we probably need to talk to W3C about this too, as [2]
> seems to need changes to XHR, which is their spec. [3] Both of those
> could however be taken care of as we go forward.
> 
> I did see Hannes' issue about TLS endpoint location and OAuth and
> those are issues that need to be addressed but that I think should be
> done in a WG.
> 
> So can folks who have new argument as to why this work is wrong, or
> definitely needs a BoF or with other new substantive comments please
> post those in the next few days. Or if you previously posted a
> substantive comment that was not addressed (noting that addressed !=
> accepted) please post a link to that thread.
> 
> I'll look at what comes up and if there is nothing new I'll probably
> start the WG chartering process around mid-week. (To be clear: at
> present I don't think this one needs a BoF in March, but could be a
> chartered WG before then.)
> 
> Cheers, S.
> 
> PS: As a process thing, if we're moving ahead here, this will appear
> as a place-holder in the BoF list for March so we can schedule a
> session for the WG, if that is formed, or else use that session for a
> BoF if one turns out to be needed.
> 
> 
> [1] 
> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Charter-Draft.txt
>
> 
[2] https://tools.ietf.org/html/draft-balfanz-https-token-binding
> [3] http://www.w3.org/TR/XMLHttpRequest/
> 
> _______________________________________________ Unbearable mailing
> list Unbearable@ietf.org 
> https://www.ietf.org/mailman/listinfo/unbearable
> 
> 
> 
> 
> 
> 
> _______________________________________________ Unbearable mailing
> list Unbearable@ietf.org 
> https://www.ietf.org/mailman/listinfo/unbearable
> 


From nobody Sat Jan 24 17:50:26 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 688571A1C06 for ; Sat, 24 Jan 2015 17:50:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Csqv2kn3nqHK for ; Sat, 24 Jan 2015 17:50:22 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1AAC1A1C02 for ; Sat, 24 Jan 2015 17:50:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6A0BDBE14; Sun, 25 Jan 2015 01:50:20 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZjG2JOJhZSj; Sun, 25 Jan 2015 01:50:18 +0000 (GMT)
Received: from [10.87.48.73] (unknown [86.42.27.85]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B4A5EBDF7; Sun, 25 Jan 2015 01:50:17 +0000 (GMT)
Message-ID: <54C44BD9.6010507@cs.tcd.ie>
Date: Sun, 25 Jan 2015 01:50:17 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Kathleen Moriarty ,  Andrei Popov 
References:      
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: John Bradley , "unbearable@ietf.org" 
Subject: Re: [Unbearable] Updated Charter Proposal
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Jan 2015 01:50:24 -0000

Cheers,

Editing will ensue:-)

S

On 25/01/15 01:30, Kathleen Moriarty wrote:
> Hi,
> 
> The charter looks like it is shaping up.  I just have some editorial
> suggestions as the discussion continues, take them or leave them, not
> a big deal.
> 
> Suggest changing from:
> The idea of Token Binding is to enable defense against such attacks by
> cryptographically binding
> security tokens to the TLS layer.
> 
> To:
> Token Binding enables defense against such attacks by cryptographically binding
> security tokens to the TLS layer.
> 
> The word goal is used a bit much, but this is a personal preference -
> take or leave the suggestions.  I suggest removing "Some" in the last
> sentence listed as this only says the "main" goals/objectives, so
> there is wiggle room still.
> 
> From:
> It is a goal of this working group to enable defense against attacks
> that involve unauthorized replay of
> security tokens, but other issues associated with the use of security
> tokens are out of scope. It is a goal
> of this working group to design the Token Binding protocol such that
> it would be also useable with
> application protocols other than HTTPS, however specifying such uses
> is not a primary goal.
> 
> Some of the main design goals for the Token Binding protocol, in no
> particular order:
> 
> To:
> It is a goal of this working group to enable defense against attacks
> that involve unauthorized replay of
> security tokens.  Other issues associated with the use of security
> tokens are out of scope. Another goal
> of this working group is to design the Token Binding protocol such
> that it would be also useable with
> application protocols other than HTTPS.  Specifying alternate
> application protocols is not a primary goal.
> 
> The main design objectives for the Token Binding protocol, in no
> particular order:
> 
> #8 - spec should probably be spelled out as specification.
> 
> Thanks,
> Kathleen
> 
> 
> On Tue, Jan 20, 2015 at 7:07 PM, Andrei Popov
>  wrote:
>> I believe I’ve addressed the feedback received so far; the updated charter
>> draft is on GitHub for easy authoring:
>>
>> https://github.com/TokenBinding/WG-Charter
>>
>>
>>
>> Pull requests are welcome,
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Andrei
>>
>>
>>
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>> Sent: Thursday, January 15, 2015 12:16 PM
>>
>>
>> To: Andrei Popov
>> Cc: unbearable@ietf.org
>> Subject: Re: [Unbearable] Updated Charter Proposal
>>
>>
>>
>> A couple more possible clarifications.
>>
>>
>>
>>
>>
>>
>>
>> 2.            Specify the use of the Token Binding protocol in combination
>> with HTTPS.
>>
>>
>>
>> HTTPS is probably intended to be shorthand for a http binding for TLS +
>> token Binding as is defined in "Token Binding over HTTP"
>> [https://tools.ietf.org/html/draft-balfanz-https-token-binding-00].
>>
>>
>>
>> This is a binding to HTTP (via a new header) and to HTML  (via XML HTTP
>> request).
>>
>>
>>
>> If we also say that possible future binding may be a SASSL/GSS-API binding
>> for TLS + token binding   (The sassl-oauth spec
>> https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 might use such a
>> thing.)
>>
>>
>>
>>
>>
>> One other thing I note in the drafts, is that at no point are  tokens
>> defined or even really discussed other than as something that applications
>> can bind to the exposed public key.
>>
>> The applications will bind tokens to the keys exposed by the specs via the
>> bindings.   The naming may slightly misdirect people, but there have already
>> been too many names for this so I won't push the point.
>>
>>
>>
>> I think keeping this down close to the TLS layer and defining bindings to
>> HTTP and other protocols is in scope.
>>
>> Encouraging applications that use protocols like HTTP + TLS to use the
>> bindings to bind there security tokens/cookies is in scope.
>>
>>
>>
>> I think defining the extensions for those applications to use the bindings
>> is should be up to the applications themselves where there is active
>> participation.
>>
>>
>>
>> Trying to extend this to cover end to end message signing outside of a TLS
>> session should be expressly out of scope.
>>
>>
>>
>> We may however want to say something about how a TLS session terminated on a
>> TLS device can have the Token Binding ID for the session passed in a HTTP
>> header.
>>
>> That and possibly some other TLS appliance issues are in scope for "Token
>> Binding over HTTP"
>>
>>
>>
>> Regards
>>
>> John B.
>>
>>
>>
>>
>>
>>
>>
>> On Jan 15, 2015, at 3:52 PM, Andrei Popov 
>> wrote:
>>
>>
>>
>> Thanks John; both suggestions make sense to me; will rephrase in the next
>> revision.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Andrei
>>
>>
>>
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>> Sent: Thursday, January 15, 2015 9:25 AM
>> To: Andrei Popov
>> Cc: unbearable@ietf.org
>> Subject: Re: [Unbearable] Updated Charter Proposal
>>
>>
>>
>> I am generally in agrement.
>>
>>
>>
>> A couple of points.
>>
>>
>>
>> Under design goals change 1 to.
>>
>>
>>
>> 1.   Allow applications to prevent the export and replay of security tokens.
>>
>>
>>
>> You could make that applications and protocols if you like as some people
>> may see things like OAuth as a protocol vs an application.
>>
>> The point being that the goal is to provide the hooks for things a layer
>> above these specifications to make security decisions, not the token binding
>> protocol itself.
>>
>>
>>
>>
>>
>> In 3 you use the term federation.  That may be larger in scope than what I
>> think you intend from the two drafts.
>>
>> Federation is a much larger topic than allowing the public key from one
>> connection to be exposed in a connection to a second party via some sort of
>> express consent from the first party.
>>
>>
>>
>> Shrinking the scope to how public keys may be shared with permission to
>> third parties may make some people more comfortable, if they are concerned
>> that this is trying to be a new federation protocol to compete with SAML or
>> OAuth.
>>
>>
>>
>> Regards
>>
>> John B.
>>
>>
>>
>> On Jan 14, 2015, at 9:14 PM, Andrei Popov 
>> wrote:
>>
>>
>>
>> The discussion on this mailing list has subsided over the holidays, so I
>> looked through the messages for feedback regarding the proposed charter and
>> incorporated a couple of changes suggested so far:
>>
>> 1. A new design goal: the solution must work for Web browsers. E.g. this
>> means that security tokens must be presentable over multiple TLS sessions
>> and connections.
>>
>> 2. Removed specific milestone dates.
>>
>>
>>
>> Looking forward to more discussion of the charter,
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Andrei
>>
>>
>>
>> _____________________________________________________
>>
>> Token Binding (TB)
>>
>>
>>
>> Charter for Working Group
>>
>>
>>
>> Web services generate various security tokens (e.g.  HTTP cookies, OAuth
>> tokens, etc.) for web applications to access protected resources. Currently
>> these are bearer tokens, i.e. any party in possession of such token gains
>> access to the protected resource. Attackers export bearer tokens from client
>> machines or from compromised network connections, present these bearer
>> tokens to Web services, and impersonate authenticated users. The idea of
>> Token Binding is to enable defense against such attacks by cryptographically
>> binding security tokens to the TLS layer.
>>
>>
>>
>> The tasks of this working group are as follows:
>>
>> 1.            Specify the Token Binding protocol v1.0.
>>
>> 2.            Specify the use of the Token Binding protocol in combination
>> with HTTPS.
>>
>>
>>
>> It is a goal of this working group to enable defense against attacks that
>> involve unauthorized replay of security tokens, but other issues associated
>> with the use of security tokens are out of scope. It is a goal of this
>> working group to design the Token Binding protocol such that it would be
>> also useable with application protocols other than HTTPS, however specifying
>> such uses is not a primary goal.
>>
>>
>>
>> Some of the main design goals for the Token Binding protocol, in no
>> particular order:
>>
>> 1.            Prevent export and replay of security tokens.
>>
>> 2.            Allow strong key protection, e.g. using hardware-bound keys.
>>
>> 3.            Support both first-party and federation scenarios.
>>
>> 4.            Preserve user privacy.
>>
>> 5.            Make the Token Binding protocol useable in combination with a
>> variety of application protocols.
>>
>> 6.            Allow the negotiation of the Token Binding protocol without
>> additional round-trips.
>>
>> 7.            Allow the use of multiple cryptographic algorithms, so that a
>> variety of secure hardware modules with different cryptographic capabilities
>> could be used with Token Binding.
>>
>> 8.            Propose Token Binding spec that can be implemented in Web
>> browsers (but is not limited to them). E.g. Web browsers require that the
>> same bound security token must be presentable over multiple TLS sessions and
>> connections.
>>
>>
>>
>> The working group will use the following documents as a starting point for
>> its work:
>>
>> -             draft-popov-token-binding-00;
>>
>> -             draft-balfanz-https-token-binding-00.
>>
>>
>>
>> This WG will collaborate with other IETF WGs, in particular with the TLS,
>> HTTPbis and Oauth WGs.
>>
>>
>>
>> Milestones:
>>
>> -            WG document for the Token Binding Protocol v1.0.
>>
>> -            WG document for HTTPS Token Binding.
>>
>> -            Token Binding Protocol v1.0 to IESG.
>>
>> -            HTTPS Token Binding to IESG.
>>
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.org/mailman/listinfo/unbearable
>>
>>
>>
>>
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.org/mailman/listinfo/unbearable
>>
> 
> 
> 


From nobody Sat Jan 24 18:07:58 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F83F1A1BFE for ; Sat, 24 Jan 2015 18:07:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.509
X-Spam-Level: 
X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 mt3nDXSNb3XF for ; Sat, 24 Jan 2015 18:07:52 -0800 (PST)
Received: from nm41-vm3.bullet.mail.bf1.yahoo.com (nm41-vm3.bullet.mail.bf1.yahoo.com [216.109.114.158]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 440671A1DE2 for ; Sat, 24 Jan 2015 18:07:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1422151671; bh=p+HmoDKVi/VWmUFMGipfQbSc9XN/y1I3GiKmUtQ2n9k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=nU95OOjJTmHt4ulfBe4tGj5RqFWfc7kO4eCXrHXGE8rwXunx1YW5EH476AOLRGEz45duz29ObcFZ+LHDYwUPDr3GaVgxXs8ZR1z1yvW2MqnTBKdw5spF3D1op8vOOY1bQIkreuAdTGYqpPuOd69y/WVCJWJNyGYeaac8GkkzbhA6XrCgmZErt9DxokuXYqWtd+N0WeDNxHG6FZy8gW64/CiYiv2WrefBmougI/3NFo+nOpgk0AATvKLcZ0wVXcBUcq5qfKXDr94gzMIK6veEXeYbdwNqYvxuDEzrQUE602vH1JUmXt8FHSejEvcdlha6K+r916BZN+QcHyJRlNMfgw==
Received: from [98.139.212.151] by nm41.bullet.mail.bf1.yahoo.com with NNFMP;  25 Jan 2015 02:07:51 -0000
Received: from [98.139.212.233] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jan 2015 02:07:51 -0000
Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 25 Jan 2015 02:07:51 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 251015.35384.bm@omp1042.mail.bf1.yahoo.com
X-YMail-OSG: LOeu78wVM1l2Qa6y8Z8JZBaLjykaPQjdlvAks6w4YF9UI7HZ.MYPQE0D8qNDSIK 8JqTnzvBkEHPepUjJaAxIL6Kesqp5afeJz8CXxF0MgJoF5x.UfMhT1LJvaqImfjtwxdG8JXyJiSE CvFdmXswlNb9N8BIyZ2yHL4_hIOd8NaZXWGLo_RU_5vxVGWTPk5UvGVCvAM7699Php9fNr95la6F U4akJdvH1HD3Sf70MJGbRXBEHUH3ajFTuYYMLu1xmLCKEiEKKEwYKbsxtRiLuoKll.DzjpgXaajM i2pCFCN9R6QrGH4.tPwjN4pd25znGJTsSkqbFUhJ77UbXxGxXlamXamLmex9GTuq7XRlWhRVfG7j V3LptekRnC9eJ3Iqfcl8obh0MTh7.VBhGl3U8jP3SH3qs8d.ULidQyFDyUwAHFx3Whh5GKeDw_yu GYApXlzSurFgCDv2jMszG2yFL81SefSCsVhoHWVuD8Q6yjsR_.UYjZKTIVH1aP6xLNjClmtdp.Ti 2QvrwPlYUpoJm5BJxVEe8ojp_yHapbOoswvtKerQOH4iKHctEOKImaUXj.f.uEEZK._2hKi2AYsv Cbgy.ViQAir9D..X8wVA-
Received: by 66.196.81.111; Sun, 25 Jan 2015 02:07:50 +0000 
Date: Sun, 25 Jan 2015 02:07:50 +0000 (UTC)
From: Bill Mills 
To: Stephen Farrell ,  Kathleen Moriarty ,  Andrei Popov 
Message-ID: <1028652913.19992.1422151670194.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <54C44BD9.6010507@cs.tcd.ie>
References: <54C44BD9.6010507@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_19991_1927653774.1422151670185"
Archived-At: 
Cc: John Bradley , "unbearable@ietf.org" 
Subject: Re: [Unbearable] Updated Charter Proposal
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Jan 2015 02:07:57 -0000

------=_Part_19991_1927653774.1422151670185
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

My issue is again with the text "binding to the TLS layer", that's channel =
binding.=20

     On Saturday, January 24, 2015 5:50 PM, Stephen Farrell  wrote:
  =20

=20
Cheers,

Editing will ensue:-)

S

On 25/01/15 01:30, Kathleen Moriarty wrote:
> Hi,
>=20
> The charter looks like it is shaping up.=C2=A0 I just have some editorial
> suggestions as the discussion continues, take them or leave them, not
> a big deal.
>=20
> Suggest changing from:
> The idea of Token Binding is to enable defense against such attacks by
> cryptographically binding
> security tokens to the TLS layer.
>=20
> To:
> Token Binding enables defense against such attacks by cryptographically b=
inding
> security tokens to the TLS layer.
>=20
> The word goal is used a bit much, but this is a personal preference -
> take or leave the suggestions.=C2=A0 I suggest removing "Some" in the las=
t
> sentence listed as this only says the "main" goals/objectives, so
> there is wiggle room still.
>=20
> From:
> It is a goal of this working group to enable defense against attacks
> that involve unauthorized replay of
> security tokens, but other issues associated with the use of security
> tokens are out of scope. It is a goal
> of this working group to design the Token Binding protocol such that
> it would be also useable with
> application protocols other than HTTPS, however specifying such uses
> is not a primary goal.
>=20
> Some of the main design goals for the Token Binding protocol, in no
> particular order:
>=20
> To:
> It is a goal of this working group to enable defense against attacks
> that involve unauthorized replay of
> security tokens.=C2=A0 Other issues associated with the use of security
> tokens are out of scope. Another goal
> of this working group is to design the Token Binding protocol such
> that it would be also useable with
> application protocols other than HTTPS.=C2=A0 Specifying alternate
> application protocols is not a primary goal.
>=20
> The main design objectives for the Token Binding protocol, in no
> particular order:
>=20
> #8 - spec should probably be spelled out as specification.
>=20
> Thanks,
> Kathleen
>=20
>=20
> On Tue, Jan 20, 2015 at 7:07 PM, Andrei Popov
>  wrote:
>> I believe I=E2=80=99ve addressed the feedback received so far; the updat=
ed charter
>> draft is on GitHub for easy authoring:
>>
>> https://github.com/TokenBinding/WG-Charter
>>
>>
>>
>> Pull requests are welcome,
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Andrei
>>
>>
>>
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>> Sent: Thursday, January 15, 2015 12:16 PM
>>
>>
>> To: Andrei Popov
>> Cc: unbearable@ietf.org
>> Subject: Re: [Unbearable] Updated Charter Proposal
>>
>>
>>
>> A couple more possible clarifications.
>>
>>
>>
>>
>>
>>
>>
>> 2.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Specify the use of the Token=
 Binding protocol in combination
>> with HTTPS.
>>
>>
>>
>> HTTPS is probably intended to be shorthand for a http binding for TLS +
>> token Binding as is defined in "Token Binding over HTTP"
>> [https://tools.ietf.org/html/draft-balfanz-https-token-binding-00].
>>
>>
>>
>> This is a binding to HTTP (via a new header) and to HTML=C2=A0 (via XML =
HTTP
>> request).
>>
>>
>>
>> If we also say that possible future binding may be a SASSL/GSS-API bindi=
ng
>> for TLS + token binding=C2=A0 (The sassl-oauth spec
>> https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 might use su=
ch a
>> thing.)
>>
>>
>>
>>
>>
>> One other thing I note in the drafts, is that at no point are=C2=A0 toke=
ns
>> defined or even really discussed other than as something that applicatio=
ns
>> can bind to the exposed public key.
>>
>> The applications will bind tokens to the keys exposed by the specs via t=
he
>> bindings.=C2=A0 The naming may slightly misdirect people, but there have=
 already
>> been too many names for this so I won't push the point.
>>
>>
>>
>> I think keeping this down close to the TLS layer and defining bindings t=
o
>> HTTP and other protocols is in scope.
>>
>> Encouraging applications that use protocols like HTTP + TLS to use the
>> bindings to bind there security tokens/cookies is in scope.
>>
>>
>>
>> I think defining the extensions for those applications to use the bindin=
gs
>> is should be up to the applications themselves where there is active
>> participation.
>>
>>
>>
>> Trying to extend this to cover end to end message signing outside of a T=
LS
>> session should be expressly out of scope.
>>
>>
>>
>> We may however want to say something about how a TLS session terminated =
on a
>> TLS device can have the Token Binding ID for the session passed in a HTT=
P
>> header.
>>
>> That and possibly some other TLS appliance issues are in scope for "Toke=
n
>> Binding over HTTP"
>>
>>
>>
>> Regards
>>
>> John B.
>>
>>
>>
>>
>>
>>
>>
>> On Jan 15, 2015, at 3:52 PM, Andrei Popov 
>> wrote:
>>
>>
>>
>> Thanks John; both suggestions make sense to me; will rephrase in the nex=
t
>> revision.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Andrei
>>
>>
>>
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>> Sent: Thursday, January 15, 2015 9:25 AM
>> To: Andrei Popov
>> Cc: unbearable@ietf.org
>> Subject: Re: [Unbearable] Updated Charter Proposal
>>
>>
>>
>> I am generally in agrement.
>>
>>
>>
>> A couple of points.
>>
>>
>>
>> Under design goals change 1 to.
>>
>>
>>
>> 1.=C2=A0 Allow applications to prevent the export and replay of security=
 tokens.
>>
>>
>>
>> You could make that applications and protocols if you like as some peopl=
e
>> may see things like OAuth as a protocol vs an application.
>>
>> The point being that the goal is to provide the hooks for things a layer
>> above these specifications to make security decisions, not the token bin=
ding
>> protocol itself.
>>
>>
>>
>>
>>
>> In 3 you use the term federation.=C2=A0 That may be larger in scope than=
 what I
>> think you intend from the two drafts.
>>
>> Federation is a much larger topic than allowing the public key from one
>> connection to be exposed in a connection to a second party via some sort=
 of
>> express consent from the first party.
>>
>>
>>
>> Shrinking the scope to how public keys may be shared with permission to
>> third parties may make some people more comfortable, if they are concern=
ed
>> that this is trying to be a new federation protocol to compete with SAML=
 or
>> OAuth.
>>
>>
>>
>> Regards
>>
>> John B.
>>
>>
>>
>> On Jan 14, 2015, at 9:14 PM, Andrei Popov 
>> wrote:
>>
>>
>>
>> The discussion on this mailing list has subsided over the holidays, so I
>> looked through the messages for feedback regarding the proposed charter =
and
>> incorporated a couple of changes suggested so far:
>>
>> 1. A new design goal: the solution must work for Web browsers. E.g. this
>> means that security tokens must be presentable over multiple TLS session=
s
>> and connections.
>>
>> 2. Removed specific milestone dates.
>>
>>
>>
>> Looking forward to more discussion of the charter,
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Andrei
>>
>>
>>
>> _____________________________________________________
>>
>> Token Binding (TB)
>>
>>
>>
>> Charter for Working Group
>>
>>
>>
>> Web services generate various security tokens (e.g.=C2=A0 HTTP cookies, =
OAuth
>> tokens, etc.) for web applications to access protected resources. Curren=
tly
>> these are bearer tokens, i.e. any party in possession of such token gain=
s
>> access to the protected resource. Attackers export bearer tokens from cl=
ient
>> machines or from compromised network connections, present these bearer
>> tokens to Web services, and impersonate authenticated users. The idea of
>> Token Binding is to enable defense against such attacks by cryptographic=
ally
>> binding security tokens to the TLS layer.
>>
>>
>>
>> The tasks of this working group are as follows:
>>
>> 1.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Specify the Token Binding pr=
otocol v1.0.
>>
>> 2.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Specify the use of the Token=
 Binding protocol in combination
>> with HTTPS.
>>
>>
>>
>> It is a goal of this working group to enable defense against attacks tha=
t
>> involve unauthorized replay of security tokens, but other issues associa=
ted
>> with the use of security tokens are out of scope. It is a goal of this
>> working group to design the Token Binding protocol such that it would be
>> also useable with application protocols other than HTTPS, however specif=
ying
>> such uses is not a primary goal.
>>
>>
>>
>> Some of the main design goals for the Token Binding protocol, in no
>> particular order:
>>
>> 1.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Prevent export and replay of=
 security tokens.
>>
>> 2.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Allow strong key protection,=
 e.g. using hardware-bound keys.
>>
>> 3.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Support both first-party and=
 federation scenarios.
>>
>> 4.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Preserve user privacy.
>>
>> 5.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Make the Token Binding proto=
col useable in combination with a
>> variety of application protocols.
>>
>> 6.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Allow the negotiation of the=
 Token Binding protocol without
>> additional round-trips.
>>
>> 7.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Allow the use of multiple cr=
yptographic algorithms, so that a
>> variety of secure hardware modules with different cryptographic capabili=
ties
>> could be used with Token Binding.
>>
>> 8.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Propose Token Binding spec t=
hat can be implemented in Web
>> browsers (but is not limited to them). E.g. Web browsers require that th=
e
>> same bound security token must be presentable over multiple TLS sessions=
 and
>> connections.
>>
>>
>>
>> The working group will use the following documents as a starting point f=
or
>> its work:
>>
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-popov-token-binding-00;
>>
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-balfanz-https-token-bin=
ding-00.
>>
>>
>>
>> This WG will collaborate with other IETF WGs, in particular with the TLS=
,
>> HTTPbis and Oauth WGs.
>>
>>
>>
>> Milestones:
>>
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 WG document for the Token Bin=
ding Protocol v1.0.
>>
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 WG document for HTTPS Token B=
inding.
>>
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Token Binding Protocol v1.0 t=
o IESG.
>>
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 HTTPS Token Binding to IESG.
>>
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.org/mailman/listinfo/unbearable
>>
>>
>>
>>
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.org/mailman/listinfo/unbearable
>>
>=20
>=20
>=20

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable


   
------=_Part_19991_1927653774.1422151670185
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


My issue is again with the text "bindi=
ng to the TLS layer", that's channel binding.
 


 
 
 
  On Saturday, January 24, 2015 5:50 PM, Stephen Farrell <stephen.farrel=
l@cs.tcd.ie> wrote:
  
  

 

Cheers,

Edi=
ting will ensue:-)

S

On 25/01=
/15 01:30, Kathleen Moriarty wrote:
> Hi,
> 
> The charter looks like it is shaping up.=
  I just have some editorial
> suggestions as the=
 discussion continues, take them or leave them, not
> =
a big deal.
> 
> Suggest changing=
 from:
> The idea of Token Binding is to enable defens=
e against such attacks by
> cryptographically binding<=
br clear=3D"none">> security tokens to the TLS layer.
=
> 
> To:
> Token Binding enabl=
es defense against such attacks by cryptographically binding
> security tokens to the TLS layer.
> 
> The word goal is used a bit much, but this is a personal pre=
ference -
> take or leave the suggestions.  I sug=
gest removing "Some" in the last
> sentence listed as =
this only says the "main" goals/objectives, so
> there=
 is wiggle room still.
> 
> From:=

> It is a goal of this working group to enable defens=
e against attacks
> that involve unauthorized replay o=
f
> security tokens, but other issues associated with =
the use of security
> tokens are out of scope. It is a=
 goal
> of this working group to design the Token Bind=
ing protocol such that
> it would be also useable with=

> application protocols other than HTTPS, however spe=
cifying such uses
> is not a primary goal.
> 
> Some of the main design goals for the T=
oken Binding protocol, in no
> particular order:
> 
> To:
> It is =
a goal of this working group to enable defense against attacks
> that involve unauthorized replay of
> secur=
ity tokens.  Other issues associated with the use of security
> tokens are out of scope. Another goal
>=
 of this working group is to design the Token Binding protocol such
> that it would be also useable with
> a=
pplication protocols other than HTTPS.  Specifying alternate
> application protocols is not a primary goal.
> 
> The main design objectives for the Token Bi=
nding protocol, in no
> particular order:
> 
> #8 - spec should probably be spelled out=
 as specification.
> 
> Thanks,> Kathleen
> 
&g=
t; 
> On Tue, Jan 20, 2015 at 7:07 PM, Andrei Popov> <Andrei.Popov@micro=
soft.com> wrote:
>> I believe I=E2=80=99ve a=
ddressed the feedback received so far; the updated charter
>> draft is on GitHub for easy authoring:
>>=
;
>> https://github.com/TokenBinding/W=
G-Charter
>>
>>
>>
>> Pull requests are welcome,>>
>>
>=
>
>> Thanks,
>>
>>
>>
>> An=
drei
>>
>>
>>
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>> Sent: Thursday, Jan=
uary 15, 2015 12:16 PM
>>
>>=
;
>> To: Andrei Popov
>> Cc=
: unbearable@ietf.org
>> Subj=
ect: Re: [Unbearable] Updated Charter Proposal
>>>>
>>
>=
> A couple more possible clarifications.
>>
>>
>>
>>=
;
>>
>>
&=
gt;>
>> 2.          &nb=
sp; Specify the use of the Token Binding protocol in combination
>> with HTTPS.
>>
>>
>>
>> HTTPS is pr=
obably intended to be shorthand for a http binding for TLS +
>> token Binding as is defined in "Token Binding over HTTP"
>> [https://tools.iet=
f.org/html/draft-balfanz-https-token-binding-00].
>=
;>
>>
>>
>> This is a binding to HTTP (via a new header) and to HTML  =
(via XML HTTP
>> request).
>&g=
t;
>>
>>
=
>> If we also say that possible future binding may be a SASSL/GSS-API=
 binding
>> for TLS + token binding   (The sas=
sl-oauth spec
>> http=
s://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-18 might use such =
a
>> thing.)
>>
>>
>>
>>
>>
>> One other thing I note in =
the drafts, is that at no point are  tokens
>>=
 defined or even really discussed other than as something that applications=

>> can bind to the exposed public key.
>>
>> The applications will bind token=
s to the keys exposed by the specs via the
>> bindi=
ngs.   The naming may slightly misdirect people, but there have alread=
y
>> been too many names for this so I won't push t=
he point.
>>
>>
>>
>> I think keeping this down close =
to the TLS layer and defining bindings to
>> HTTP a=
nd other protocols is in scope.
>>
>> Encouraging applications that use protocols like HTTP + TLS to u=
se the
>> bindings to bind there security tokens/co=
okies is in scope.
>>
>>>>
>> I think defining the ex=
tensions for those applications to use the bindings
>&=
gt; is should be up to the applications themselves where there is active>> participation.
>>
>>
>>
>> Tr=
ying to extend this to cover end to end message signing outside of a TLS>> session should be expressly out of scope.
>>
>>
>>>> We may however want to say something about how a T=
LS session terminated on a
>> TLS device can have t=
he Token Binding ID for the session passed in a HTTP
>=
> header.
>>
>> That and=
 possibly some other TLS appliance issues are in scope for "Token
>> Binding over HTTP"
>>
>>
>>
>> Re=
gards
>>
>> John B.
>>
>>
>>>>
>>
>=
>
>>
>> On Jan 15, 2015,=
 at 3:52 PM, Andrei Popov <Andrei.Popov@=
microsoft.com>
>> wrote:
&=
gt;>
>>
>>
>> Thanks John; both suggestions make sense to me; will rephrase=
 in the next
>> revision.
>>=
;
>>
>>
&=
gt;> Cheers,
>>
>>
>>
>> Andrei
&=
gt;>
>>
>>
>> From: John Bradley [mailto:ve7jtb@ve7jtb.com]
>> Sent: Thursday, January 15, 2015 9:25 AM
>> To: Andrei Popov
>> Cc: unbearable@ietf.org
>> Subject: R=
e: [Unbearable] Updated Charter Proposal
>>
>>
>>
>> I=
 am generally in agrement.
>>
>=
;>
>>
>> A couple of poi=
nts.
>>
>>
>>
>> Under design goals change 1 to.
>>
>>
>>=

>> 1.   Allow applications to prevent the exp=
ort and replay of security tokens.
>>
>>
>>
>> You cou=
ld make that applications and protocols if you like as some people
>> may see things like OAuth as a protocol vs an applicatio=
n.
>>
>> The point being th=
at the goal is to provide the hooks for things a layer
&g=
t;> above these specifications to make security decisions, not the token=
 binding
>> protocol itself.
>=
>
>>
>>
>>
>>
>> In 3 you u=
se the term federation.  That may be larger in scope than what I
>> think you intend from the two drafts.
>>
>> Federation is a much larger topic th=
an allowing the public key from one
>> connection t=
o be exposed in a connection to a second party via some sort of
>> express consent from the first party.
>=
;>
>>
>>
>> Shrinking the scope to how public keys may be shared with permi=
ssion to
>> third parties may make some people more=
 comfortable, if they are concerned
>> that this is=
 trying to be a new federation protocol to compete with SAML or
>> OAuth.
>>
>>=
;
>>
>> Regards
>>
>> John B.
>&g=
t;
>>
>>
=
>> On Jan 14, 2015, at 9:14 PM, Andrei Popov <Andrei.Popov@microsoft.com>
>> w=
rote:
>>
>>
>>
>> The discussion on this mailing list =
has subsided over the holidays, so I
>> looked thro=
ugh the messages for feedback regarding the proposed charter and
>> incorporated a couple of changes suggested so far:
>>
>> 1. A new design goal: the =
solution must work for Web browsers. E.g. this
>> m=
eans that security tokens must be presentable over multiple TLS sessions>> and connections.
>>
>> 2. Removed specific milestone dates.
>>
>>
>>
>> Looking forward to more discussion of the charter,
>>
>>
>>>> Thanks,
>>
>>
>>
>> Andrei>>
>>
>&=
gt;
>> ____________________________________________=
_________
>>
>> Token Bindi=
ng (TB)
>>
>>
>>
>> Charter for Working Group
>>
>>
>>>> Web services generate various security tokens (e.g=
.  HTTP cookies, OAuth
>> tokens, etc.) for we=
b applications to access protected resources. Currently
&=
gt;> these are bearer tokens, i.e. any party in possession of such token=
 gains
>> access to the protected resource. Attacke=
rs export bearer tokens from client
>> machines or =
from compromised network connections, present these bearer
>> tokens to Web services, and impersonate authenticated users. The=
 idea of
>> Token Binding is to enable defense agai=
nst such attacks by cryptographically
>> binding se=
curity tokens to the TLS layer.
>>
>>
>>
>> The tasks =
of this working group are as follows:
>>
>> 1.            Specify the =
Token Binding protocol v1.0.
>>
&=
gt;> 2.            Specify the use of the =
Token Binding protocol in combination
>> with HTTPS=
.
>>
>>
&=
gt;>
>> It is a goal of this working group to en=
able defense against attacks that
>> involve unauth=
orized replay of security tokens, but other issues associated
>> with the use of security tokens are out of scope. It is a goa=
l of this
>> working group to design the Token Bind=
ing protocol such that it would be
>> also useable =
with application protocols other than HTTPS, however specifying
>> such uses is not a primary goal.
>>=

>>
>>
&g=
t;> Some of the main design goals for the Token Binding protocol, in no<=
br clear=3D"none">>> particular order:
>>
>> 1.            Prevent=
 export and replay of security tokens.
>>
>> 2.            Allow strong=
 key protection, e.g. using hardware-bound keys.
>>=

>> 3.            Sup=
port both first-party and federation scenarios.
>><=
br clear=3D"none">>> 4.            Pres=
erve user privacy.
>>
>> 5.=
            Make the Token Binding protocol u=
seable in combination with a
>> variety of applicat=
ion protocols.
>>
>> 6.&nbs=
p;           Allow the negotiation of the Token Bi=
nding protocol without
>> additional round-trips.>>
>> 7.     =
       Allow the use of multiple cryptographic algorithms, s=
o that a
>> variety of secure hardware modules with=
 different cryptographic capabilities
>> could be u=
sed with Token Binding.
>>
>&g=
t; 8.            Propose Token Binding spec t=
hat can be implemented in Web
>> browsers (but is n=
ot limited to them). E.g. Web browsers require that the
&=
gt;> same bound security token must be presentable over multiple TLS ses=
sions and
>> connections.
>>=
;
>>
>>
&=
gt;> The working group will use the following documents as a starting po=
int for
>> its work:
>>
>> -             draft-p=
opov-token-binding-00;
>>
>>=
; -             draft-balfanz-https-token-bin=
ding-00.
>>
>>
>>
>> This WG will collaborate with oth=
er IETF WGs, in particular with the TLS,
>> HTTPbis=
 and Oauth WGs.
>>
>>
>>
>> Milestones:
>>
>> -         =
   WG document for the Token Binding Protocol v1.0.
=
>>
>> -          &nb=
sp; WG document for HTTPS Token Binding.
>>
>> -            Token Bindin=
g Protocol v1.0 to IESG.
>>
>&=
gt; -            HTTPS Token Binding to IESG.=

>>
>> ____________________=
___________________________
>> Unbearable mailing l=
ist
>> Unbearable@ietf.org>> https://www.ietf.org/mailman/li=
stinfo/unbearable
>>
>>=

>>
>>
&g=
t;> _______________________________________________
&g=
t;> Unbearable mailing list
>> Unbearable@ietf.org
>> htt=
ps://www.ietf.org/mailman/listinfo/unbearable
>>=
;
> 
> 
> 
_______________________________________=
________
Unbearable mailing list
Unbearable@ietf.org
ht=
tps://www.ietf.org/mailman/listinfo/unbearable
=


  
 
  
 

------=_Part_19991_1927653774.1422151670185--


From nobody Sat Jan 24 18:16:02 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD9E1A1E0B for ; Sat, 24 Jan 2015 18:16:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.509
X-Spam-Level: 
X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 G2W9rrSjQDOp for ; Sat, 24 Jan 2015 18:15:59 -0800 (PST)
Received: from nm35-vm0.bullet.mail.bf1.yahoo.com (nm35-vm0.bullet.mail.bf1.yahoo.com [72.30.238.72]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF0DD1A1DE1 for ; Sat, 24 Jan 2015 18:15:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1422152158; bh=mPWzJv0EQpHHgx5O/6WJYxDEA8xyD6QYhpC7AA+P2fI=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=Degt1/3MAjxP2FAeBkvXPoNwmHYb0rAW99Q1T6HMnTHA3zIVhsxnUpw5Cu1aYE4yn+iFME2LS+Bv8oEB4ezOuUn8IasBkzdFCLUt26+uQZBq0ldrADdFSzPJ3S7X+OI+2YShaYQ4adidtMx0RaLIOznmigbmIO8uzIojX0gZTJPLM8th6uZ1tyIQ780eHZ+xgUHmCq4IQPUhLIRV9mjvZjdOBh0bkJjEyucPOPBrw3+eXsuJqcDGrTl4e44zbhfgE5Yxx/jWIJ9emZMYZyua3abLXNEWeDRInxoCvkzrq7xH3Lzt2KGdVtPs7OR7QgDjYBGiBq2jsJXk/5ivpVEXzQ==
Received: from [98.139.212.151] by nm35.bullet.mail.bf1.yahoo.com with NNFMP;  25 Jan 2015 02:15:58 -0000
Received: from [98.139.212.242] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jan 2015 02:15:58 -0000
Received: from [127.0.0.1] by omp1051.mail.bf1.yahoo.com with NNFMP; 25 Jan 2015 02:15:58 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 34167.81027.bm@omp1051.mail.bf1.yahoo.com
X-YMail-OSG: xe.SpIQVM1lCqw.6hUNAIVKtXyG_DbJHdJz8UGxE0s_4gknKEHK_IGm9_Vhu1qT XULlXHV.n5Pc7JsheyDzVK7t0MwcH0IPmu3Z5WztRJJfFhBByo4GnyXhcfuq_2AQJujR2G.3j4xm xcziFDkTJ5gU3RI_IIFFK5jH4TB1HVjC2s6tB7bgLXTZn5hp1AkYVBJtYoNcD00Os9CemXUBuYq0 syC.VT5A0S1SwHzIRzgOvHX8qizYlRSuJgpRaUsWMDFTP4BYbWsnFWV7Q6BGqK63zbrm0DvrTvSW jZNruMeMlzrCilAytqMjCVywZftPVyaqPNkqzGeU9Mp0IIUZ8px1YpG_.OfxfLPBwpdFHrVpw9O0 IYYL4wsBowIBQYK1d.6SGSMW48NiRUXAwuA7UXRtlqZaL8j5trEtIr.CBD3C_LC5WeKE9xeWhhsx 1NcyP6etljew5En2ay.cJlHG3B7w826ck3334MMcG7nEsy.DWY_xlSZrCjzX8Ebnx17oY3_yqW6C JqCV7eLhGGPgZiuWo2lBL4Hjb9beSZNOsLK0oNRkjPvOx8tXLpuG3g9T8MA5C5Eln8ZMNGLtrFtk 2JQ6ZWvLUP2Jh7iTfXccX4n1Pm1LdRmC4YudwnAGSe4vHIMjK6yQcZbv6xzRoabPRGfIx1RuGu8b yFOjUJBiQvaJw09Q3Qvs6mKAiNoE6H3s9IWNhTk_ZOY9nnwyltzRehaWAIjH_byg-
Received: by 76.13.26.127; Sun, 25 Jan 2015 02:15:57 +0000 
Date: Sun, 25 Jan 2015 02:15:57 +0000 (UTC)
From: Bill Mills 
To: Stephen Farrell ,  "unbearable@ietf.org" 
Message-ID: <570442397.10635.1422152157315.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <54C44B61.9070207@cs.tcd.ie>
References: <54C44B61.9070207@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_10634_1208163606.1422152157311"
Archived-At: 
Subject: Re: [Unbearable] moving ahead
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Jan 2015 02:16:01 -0000

------=_Part_10634_1208163606.1422152157311
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

>From my "elevator pitch" question in the other thread,=C2=A0"Clients (brows=
ers) being able to tie credentials to locally generated and managed keys an=
d assert that key to the auth service.". =C2=A0To extend that I think it sh=
ould be something like:
"Clients (browsers) being able to tie credentials to locally generated and =
managed keys and assert that key to the auth service. =C2=A0Those keys are =
used for signing transaction when accessing a protected resource via TLS.".=
=C2=A0=20

     On Saturday, January 24, 2015 5:48 PM, Stephen Farrell  wrote:
  =20

=20
Hi Bill,

If you can send proposed text that'd be great. Absent that,
to be honest, I'm not sure what change you'd like,

Cheers,
S.

On 25/01/15 01:02, Bill Mills wrote:
> I think the current text of the charter is not descriptive of what
> this WG is really trying to solve.=C2=A0 It reads as though this is about
> TLS channel binding which is wrong.=C2=A0 I'd like to see that fixed in
> the language of the charter to be clearer. There was a thread
> recently on what the elevator pitch for this is, and I think language
> similar to that shoudl be in the first paragraph.
>=20
> On Saturday, January 24, 2015 3:34 PM, Stephen Farrell
>  wrote:
>=20
>=20
>=20
> Hiya,
>=20
> Andrei has asked me about next steps for this work, based on the=20
> draft charter text at [1].
>=20
> I think that text is pretty good, but before I start the formal WG
> chartering process I wanted to check here that there aren't major
> problems with it.
>=20
> Two things I noted myself were that it'd be good to see some support
> from server implementers who are not also browser makers. And
> secondly, we probably need to talk to W3C about this too, as [2]
> seems to need changes to XHR, which is their spec. [3] Both of those
> could however be taken care of as we go forward.
>=20
> I did see Hannes' issue about TLS endpoint location and OAuth and
> those are issues that need to be addressed but that I think should be
> done in a WG.
>=20
> So can folks who have new argument as to why this work is wrong, or
> definitely needs a BoF or with other new substantive comments please
> post those in the next few days. Or if you previously posted a
> substantive comment that was not addressed (noting that addressed !=3D
> accepted) please post a link to that thread.
>=20
> I'll look at what comes up and if there is nothing new I'll probably
> start the WG chartering process around mid-week. (To be clear: at
> present I don't think this one needs a BoF in March, but could be a
> chartered WG before then.)
>=20
> Cheers, S.
>=20
> PS: As a process thing, if we're moving ahead here, this will appear
> as a place-holder in the BoF list for March so we can schedule a
> session for the WG, if that is formed, or else use that session for a
> BoF if one turns out to be needed.
>=20
>=20
> [1]=20
> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Ch=
arter-Draft.txt
>
>=20
[2] https://tools.ietf.org/html/draft-balfanz-https-token-binding
> [3] http://www.w3.org/TR/XMLHttpRequest/
>=20
> _______________________________________________ Unbearable mailing
> list Unbearable@ietf.org=20
> https://www.ietf.org/mailman/listinfo/unbearable
>=20
>=20
>=20
>=20
>=20
>=20
> _______________________________________________ Unbearable mailing
> list Unbearable@ietf.org=20
> https://www.ietf.org/mailman/listinfo/unbearable
>=20

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable


   
------=_Part_10634_1208163606.1422152157311
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


From my "elevator pitch" q=
uestion in the other thread, "Clients (browser=
s) being able to tie credentials to locally generated and managed keys and =
assert that key to the auth service.".  To extend that I think it shou=
ld be something like:

=
"Clients (browsers) being able to tie credentials t=
o locally generated and managed keys and assert that key to the auth servic=
e.  Those keys are used for signing transaction when accessing a prote=
cted resource via TLS.". 
 


 <=
div style=3D"font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, =
Lucida Grande, sans-serif; font-size: 12px;"> 
 
  On Sat=
urday, January 24, 2015 5:48 PM, Stephen Farrell <stephen.farrell@cs.tcd=
.ie> wrote:
  
  

 
=

Hi Bill,

If you can=
 send proposed text that'd be great. Absent that,
to be h=
onest, I'm not sure what change you'd like,

Cheers,
S.

On =
25/01/15 01:02, Bill Mills wrote:
> I think the curren=
t text of the charter is not descriptive of what
> thi=
s WG is really trying to solve.  It reads as though this is about
> TLS channel binding which is wrong.  I'd like to se=
e that fixed in
> the language of the charter to be cl=
earer. There was a thread
> recently on what the eleva=
tor pitch for this is, and I think language
> similar =
to that shoudl be in the first paragraph.
> 
> On Saturday, January 24, 2015 3:34 PM, Stephen Farrell
> <stephen.farrell@cs.tcd.=
ie> wrote:
> 
> 
> 
> Hiya,
> 
> Andrei has asked me about next steps for this work, based =
on the 
> draft charter text at [1].
> 
> I think that text is pretty good, but before =
I start the formal WG
> chartering process I wanted to=
 check here that there aren't major
> problems with it=
.
> 
> Two things I noted myself =
were that it'd be good to see some support
> from serv=
er implementers who are not also browser makers. And
>=
 secondly, we probably need to talk to W3C about this too, as [2]
> seems to need changes to XHR, which is their spec. [3] Both =
of those
> could however be taken care of as we go for=
ward.
> 
> I did see Hannes' issu=
e about TLS endpoint location and OAuth and
> those ar=
e issues that need to be addressed but that I think should be
> done in a WG.
> 
> So c=
an folks who have new argument as to why this work is wrong, or
> definitely needs a BoF or with other new substantive comments p=
lease
> post those in the next few days. Or if you pre=
viously posted a
> substantive comment that was not ad=
dressed (noting that addressed !=3D
> accepted) please=
 post a link to that thread.
> 
>=
 I'll look at what comes up and if there is nothing new I'll probably
> start the WG chartering process around mid-week. (To be c=
lear: at
> present I don't think this one needs a BoF =
in March, but could be a
> chartered WG before then.)<=
br clear=3D"none">> 
> Cheers, S.
> 
> PS: As a process thing, if we're moving ahead=
 here, this will appear
> as a place-holder in the BoF=
 list for March so we can schedule a
> session for the=
 WG, if that is formed, or else use that session for a
&g=
t; BoF if one turns out to be needed.
> 
> 
> [1] 
> https://github.com/TokenBindi=
ng/WG-Charter/blob/master/TokenBinding-WG-Charter-Draft.txt
>
> 
[2] https://tools.ietf.org/html/draft-balfanz-https-token-bindin=
g
> [3] http://www.w3.org/TR/XMLHttpRequest=
/
> 
> ______________________=
_________________________ Unbearable mailing
> list Unbearable@ietf.org 
> https://www.ietf.org/mailman/listinfo/unbearable

> 
=
> 
> 
> 
>=
; 
> 
> _________________________=
______________________ Unbearable mailing
> list Unbearable@ietf.org 
> https://www.ietf.org/mailman/listinfo/unbearable
> 

_______________________________=
________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable


  
 
  
 

------=_Part_10634_1208163606.1422152157311--


From nobody Mon Jan 26 08:53:41 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B49711ACCDE for ; Mon, 26 Jan 2015 08:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 YW06ERFcIDaV for ; Mon, 26 Jan 2015 08:53:36 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BDFC1ACCE1 for ; Mon, 26 Jan 2015 08:53:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8A87CBEFB; Mon, 26 Jan 2015 16:53:34 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apk_6gspHzac; Mon, 26 Jan 2015 16:53:34 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 60E75BE9F; Mon, 26 Jan 2015 16:53:34 +0000 (GMT)
Message-ID: <54C6710F.1090909@cs.tcd.ie>
Date: Mon, 26 Jan 2015 16:53:35 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Bill Mills ,  "unbearable@ietf.org" 
References: <54C44B61.9070207@cs.tcd.ie> <570442397.10635.1422152157315.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <570442397.10635.1422152157315.JavaMail.yahoo@mail.yahoo.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Unbearable] moving ahead
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 16:53:40 -0000

Hi Bill,

Ok, so now I get the addition you're requesting.

On 25/01/15 02:15, Bill Mills wrote:
> From my "elevator pitch" question in the other thread, "Clients
> (browsers) being able to tie credentials to locally generated and
> managed keys and assert that key to the auth service.".  #

I note that that text does not occur in the current draft. [1]
But I also know what you mean so moving on...

> To extend that I think it should be something like:

> "Clients (browsers) being able to tie credentials to locally
> generated and managed keys and assert that key to the auth service.
> Those keys are used for signing transaction when accessing a
> protected resource via TLS.".

Are you asking that this work be extended so as to define
a general method for producing digital signatures on application
layer objects with the private key that is needed for moving
away from bearer tokens? (Assuming a digital signature based
way of doing better than bearer tokens, which is a reasonable
assumption.)

If so, that seems like a major extension of scope and I'd be
interested in whether or not folks support that idea. And I'd
be opposed myself FWIW - too many pitfalls. A general thing
like that might be a good follow on but in a separate WG I'd
argue.

If not, and you mean something less broad, then I think it'd
be better if you could try again and please provide a specific
charter language suggestion that only covers the narrower
scope of work you mean. And then we can see if folks like
the idea. In that case, please use OLD/NEW form to describe
the changes to [1] that you propose.

Thanks,
S.

[1]
https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Charter-Draft.txt


Thanks,
S.


> 
> On Saturday, January 24, 2015 5:48 PM, Stephen Farrell
>  wrote:
> 
> 
> 
> Hi Bill,
> 
> If you can send proposed text that'd be great. Absent that, to be
> honest, I'm not sure what change you'd like,
> 
> Cheers, S.
> 
> On 25/01/15 01:02, Bill Mills wrote:
>> I think the current text of the charter is not descriptive of what 
>> this WG is really trying to solve.  It reads as though this is
>> about TLS channel binding which is wrong.  I'd like to see that
>> fixed in the language of the charter to be clearer. There was a
>> thread recently on what the elevator pitch for this is, and I think
>> language similar to that shoudl be in the first paragraph.
>> 
>> On Saturday, January 24, 2015 3:34 PM, Stephen Farrell 
>>  wrote:
>> 
>> 
>> 
>> Hiya,
>> 
>> Andrei has asked me about next steps for this work, based on the 
>> draft charter text at [1].
>> 
>> I think that text is pretty good, but before I start the formal WG 
>> chartering process I wanted to check here that there aren't major 
>> problems with it.
>> 
>> Two things I noted myself were that it'd be good to see some
>> support from server implementers who are not also browser makers.
>> And secondly, we probably need to talk to W3C about this too, as
>> [2] seems to need changes to XHR, which is their spec. [3] Both of
>> those could however be taken care of as we go forward.
>> 
>> I did see Hannes' issue about TLS endpoint location and OAuth and 
>> those are issues that need to be addressed but that I think should
>> be done in a WG.
>> 
>> So can folks who have new argument as to why this work is wrong,
>> or definitely needs a BoF or with other new substantive comments
>> please post those in the next few days. Or if you previously posted
>> a substantive comment that was not addressed (noting that addressed
>> != accepted) please post a link to that thread.
>> 
>> I'll look at what comes up and if there is nothing new I'll
>> probably start the WG chartering process around mid-week. (To be
>> clear: at present I don't think this one needs a BoF in March, but
>> could be a chartered WG before then.)
>> 
>> Cheers, S.
>> 
>> PS: As a process thing, if we're moving ahead here, this will
>> appear as a place-holder in the BoF list for March so we can
>> schedule a session for the WG, if that is formed, or else use that
>> session for a BoF if one turns out to be needed.
>> 
>> 
>> [1] 
>> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Charter-Draft.txt
>>
>>
>
>> 
[2] https://tools.ietf.org/html/draft-balfanz-https-token-binding
>> [3] http://www.w3.org/TR/XMLHttpRequest/
>> 
>> _______________________________________________ Unbearable mailing 
>> list Unbearable@ietf.org 
>> https://www.ietf.org/mailman/listinfo/unbearable
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________ Unbearable mailing 
>> list Unbearable@ietf.org 
>> https://www.ietf.org/mailman/listinfo/unbearable
>> 
> 
> _______________________________________________ Unbearable mailing
> list Unbearable@ietf.org 
> https://www.ietf.org/mailman/listinfo/unbearable
> 
> 
> 
> 


From nobody Mon Jan 26 08:54:23 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905C11ACCE6 for ; Mon, 26 Jan 2015 08:54:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 I23tAWwQpzqT for ; Mon, 26 Jan 2015 08:54:18 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DF3C1ACCDE for ; Mon, 26 Jan 2015 08:54:18 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 02CBCBE39 for ; Mon, 26 Jan 2015 16:54:17 +0000 (GMT)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX_LyEFPqkkf for ; Mon, 26 Jan 2015 16:54:16 +0000 (GMT)
Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DFDB9BE64 for ; Mon, 26 Jan 2015 16:54:15 +0000 (GMT)
Message-ID: <54C67139.8000404@cs.tcd.ie>
Date: Mon, 26 Jan 2015 16:54:17 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "unbearable@ietf.org" 
References: <54C42BFB.4040300@cs.tcd.ie>
In-Reply-To: <54C42BFB.4040300@cs.tcd.ie>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Unbearable] moving ahead
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 16:54:20 -0000

Hiya,

I forwarded this to the IESG as a heads-up and got a
good question. That and my answer below just for
checking. Not sure if clarifying this in the charter
would be good or not.

The question was:
>> Is it reasonable to consider whether the token binding protocol
>> could be used with other security protocols other than TLS?

And I said:

> Good question. I'd say the answer is, yes in theory and other
> client-server protocols should be able to follow the design
> pattern, (arguably HOBA does in HTTP:-) but no in practice,
> the protocol specifics would be quite likely tied to TLS for
> security reasons (e.g. bind to a (pre-)master secret, though
> that could be generalised) but more likely simply for the
> convenience of using ALPN and TLS extensions and the TLS style
> of specifying PDUs, etc."

Cheers,
S.





On 24/01/15 23:34, Stephen Farrell wrote:
> 
> Hiya,
> 
> Andrei has asked me about next steps for this work, based on the
> draft charter text at [1].
> 
> I think that text is pretty good, but before I start the formal
> WG chartering process I wanted to check here that there aren't
> major problems with it.
> 
> Two things I noted myself were that it'd be good to see some
> support from server implementers who are not also browser makers.
> And secondly, we probably need to talk to W3C about this too,
> as [2] seems to need changes to XHR, which is their spec. [3]
> Both of those could however be taken care of as we go forward.
> 
> I did see Hannes' issue about TLS endpoint location and OAuth
> and those are issues that need to be addressed but that I think
> should be done in a WG.
> 
> So can folks who have new argument as to why this work is wrong,
> or definitely needs a BoF or with other new substantive comments
> please post those in the next few days. Or if you previously
> posted a substantive comment that was not addressed (noting that
> addressed != accepted) please post a link to that thread.
> 
> I'll look at what comes up and if there is nothing new I'll
> probably start the WG chartering process around mid-week.
> (To be clear: at present I don't think this one needs a BoF
> in March, but could be a chartered WG before then.)
> 
> Cheers,
> S.
> 
> PS: As a process thing, if we're moving ahead here, this will
> appear as a place-holder in the BoF list for March so we can
> schedule a session for the WG, if that is formed, or else use
> that session for a BoF if one turns out to be needed.
> 
> 
> [1]
> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Charter-Draft.txt
> [2] https://tools.ietf.org/html/draft-balfanz-https-token-binding
> [3] http://www.w3.org/TR/XMLHttpRequest/
> 
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable
> 
> 


From nobody Mon Jan 26 09:10:01 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D82A1A1EF8 for ; Mon, 26 Jan 2015 09:09:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 0TYhZ0d3ovnn for ; Mon, 26 Jan 2015 09:09:55 -0800 (PST)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDAA51ACCF0 for ; Mon, 26 Jan 2015 09:09:54 -0800 (PST)
Received: by mail-qc0-f172.google.com with SMTP id i8so7906776qcq.3 for ; Mon, 26 Jan 2015 09:09:54 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=dL/rJxFMShp+PoivfuydITq5TF29oMr+bXC4Bb3GAMg=; b=Q87HGE50rysCqW1dB50n0TqECz15CXOIXFeK6j588hX5bsdVB8IPnMWNYmMCidyf+7 b67H6zLTDPSVbPypm+J5YJ3J9R7cWjRreSd38qNCtCHrRkEvBE38H0tnPWEBKu+vxxiv q1C6wwRRjwmAZSRnN1SjHrYUo3MIotSogfjmRCLRqKFCXp05JWPj2Q9QRdbs5imk1FCc f4XRitETNqGcaY4dk4slIKN6sgIdPAH13RWS466B0g23xE4NwppLFnBFS0p3y2gYI6f9 yFnPTcStO9STfDVsKaMGjR705J74V9CCZF6BJFPAaadD78QM5QrvOBlk5yXey1apYI5C A+cg==
X-Gm-Message-State: ALoCoQmazriHNqjKBAQJ6MQ1/t+QNTK1bolI7POZ2lYQ0taFsiAwDXE7mZXce2regm9+97P+cPEm
X-Received: by 10.140.90.112 with SMTP id w103mr40402511qgd.65.1422292194016;  Mon, 26 Jan 2015 09:09:54 -0800 (PST)
Received: from [192.168.1.42] (186-106-135-17.baf.movistar.cl. [186.106.135.17]) by mx.google.com with ESMTPSA id f7sm10474219qaq.42.2015.01.26.09.09.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Jan 2015 09:09:52 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_BC0C2AB2-A9C6-49B6-BF8D-ADE3B02B2710"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: John Bradley 
In-Reply-To: <54C6710F.1090909@cs.tcd.ie>
Date: Mon, 26 Jan 2015 14:04:45 -0300
Message-Id: <7EA9BE5B-9084-428E-8798-95258CF74A91@ve7jtb.com>
References: <54C44B61.9070207@cs.tcd.ie> <570442397.10635.1422152157315.JavaMail.yahoo@mail.yahoo.com> <54C6710F.1090909@cs.tcd.ie>
To: Stephen Farrell 
X-Mailer: Apple Mail (2.1993)
Archived-At: 
Cc: "unbearable@ietf.org" , Bill Mills 
Subject: Re: [Unbearable] moving ahead
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 17:09:58 -0000

--Apple-Mail=_BC0C2AB2-A9C6-49B6-BF8D-ADE3B02B2710
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Last week I did a blog post on how token binding fits with a number of =
the other related specs.
=
http://www.thread-safe.com/2015/01/proof-of-possession-putting-pieces.html=


Based on feedback from one of the token binding authors, I didn't =
butcher it too much.

I think the use of the key established by token binding is best left to =
the protocols that want to use it.

Trying to cover the application layer is too broad a scope for this WG.

John B.

> On Jan 26, 2015, at 1:53 PM, Stephen Farrell =
 wrote:
>=20
>=20
> Hi Bill,
>=20
> Ok, so now I get the addition you're requesting.
>=20
> On 25/01/15 02:15, Bill Mills wrote:
>> =46rom my "elevator pitch" question in the other thread, "Clients
>> (browsers) being able to tie credentials to locally generated and
>> managed keys and assert that key to the auth service.".  #
>=20
> I note that that text does not occur in the current draft. [1]
> But I also know what you mean so moving on...
>=20
>> To extend that I think it should be something like:
>=20
>> "Clients (browsers) being able to tie credentials to locally
>> generated and managed keys and assert that key to the auth service.
>> Those keys are used for signing transaction when accessing a
>> protected resource via TLS.".
>=20
> Are you asking that this work be extended so as to define
> a general method for producing digital signatures on application
> layer objects with the private key that is needed for moving
> away from bearer tokens? (Assuming a digital signature based
> way of doing better than bearer tokens, which is a reasonable
> assumption.)
>=20
> If so, that seems like a major extension of scope and I'd be
> interested in whether or not folks support that idea. And I'd
> be opposed myself FWIW - too many pitfalls. A general thing
> like that might be a good follow on but in a separate WG I'd
> argue.
>=20
> If not, and you mean something less broad, then I think it'd
> be better if you could try again and please provide a specific
> charter language suggestion that only covers the narrower
> scope of work you mean. And then we can see if folks like
> the idea. In that case, please use OLD/NEW form to describe
> the changes to [1] that you propose.
>=20
> Thanks,
> S.
>=20
> [1]
> =
https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Cha=
rter-Draft.txt
>=20
>=20
> Thanks,
> S.
>=20
>=20
>>=20
>> On Saturday, January 24, 2015 5:48 PM, Stephen Farrell
>>  wrote:
>>=20
>>=20
>>=20
>> Hi Bill,
>>=20
>> If you can send proposed text that'd be great. Absent that, to be
>> honest, I'm not sure what change you'd like,
>>=20
>> Cheers, S.
>>=20
>> On 25/01/15 01:02, Bill Mills wrote:
>>> I think the current text of the charter is not descriptive of what=20=

>>> this WG is really trying to solve.  It reads as though this is
>>> about TLS channel binding which is wrong.  I'd like to see that
>>> fixed in the language of the charter to be clearer. There was a
>>> thread recently on what the elevator pitch for this is, and I think
>>> language similar to that shoudl be in the first paragraph.
>>>=20
>>> On Saturday, January 24, 2015 3:34 PM, Stephen Farrell=20
>>>  wrote:
>>>=20
>>>=20
>>>=20
>>> Hiya,
>>>=20
>>> Andrei has asked me about next steps for this work, based on the=20
>>> draft charter text at [1].
>>>=20
>>> I think that text is pretty good, but before I start the formal WG=20=

>>> chartering process I wanted to check here that there aren't major=20
>>> problems with it.
>>>=20
>>> Two things I noted myself were that it'd be good to see some
>>> support from server implementers who are not also browser makers.
>>> And secondly, we probably need to talk to W3C about this too, as
>>> [2] seems to need changes to XHR, which is their spec. [3] Both of
>>> those could however be taken care of as we go forward.
>>>=20
>>> I did see Hannes' issue about TLS endpoint location and OAuth and=20
>>> those are issues that need to be addressed but that I think should
>>> be done in a WG.
>>>=20
>>> So can folks who have new argument as to why this work is wrong,
>>> or definitely needs a BoF or with other new substantive comments
>>> please post those in the next few days. Or if you previously posted
>>> a substantive comment that was not addressed (noting that addressed
>>> !=3D accepted) please post a link to that thread.
>>>=20
>>> I'll look at what comes up and if there is nothing new I'll
>>> probably start the WG chartering process around mid-week. (To be
>>> clear: at present I don't think this one needs a BoF in March, but
>>> could be a chartered WG before then.)
>>>=20
>>> Cheers, S.
>>>=20
>>> PS: As a process thing, if we're moving ahead here, this will
>>> appear as a place-holder in the BoF list for March so we can
>>> schedule a session for the WG, if that is formed, or else use that
>>> session for a BoF if one turns out to be needed.
>>>=20
>>>=20
>>> [1]=20
>>> =
https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Cha=
rter-Draft.txt
>>>=20
>>>=20
>>=20
>>>=20
> [2] https://tools.ietf.org/html/draft-balfanz-https-token-binding
>>> [3] http://www.w3.org/TR/XMLHttpRequest/
>>>=20
>>> _______________________________________________ Unbearable mailing=20=

>>> list Unbearable@ietf.org=20
>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________ Unbearable mailing=20=

>>> list Unbearable@ietf.org=20
>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>=20
>>=20
>> _______________________________________________ Unbearable mailing
>> list Unbearable@ietf.org=20
>> https://www.ietf.org/mailman/listinfo/unbearable
>>=20
>>=20
>>=20
>>=20
>=20
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable


--Apple-Mail=_BC0C2AB2-A9C6-49B6-BF8D-ADE3B02B2710
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAxMjYxNzA0NDZaMCMGCSqGSIb3DQEJBDEWBBRrcwa7G57kYNNgwBfBVE9k
wscoOzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQAMisyXpvqImsD7HA4TxhrSpn/dsW0bCgB9gsxlRvW7WQ8tlKcdX5hD
12NyW4aKIdI7gmXz3T4BXPaxP4LpZhoJ0vxc5JAzRPBw+iyUz52rvYSLb2wVczTaDSDgL7RrmSmw
dWoKOpAxNbpdb7l4ZH++zNy8ulmqfH4QF2AV/CGV2ayKn2EV3tSEhyNhLVgHuzQFy6agVvpbMsCW
EGrmw7aguNo/a/nB3pOl88edJn6yQRfiRZLD/biHZYJr7Mm+GALi9FQoPuBIua2RZUi+nFu8FV1M
HWV9EaL0aKvqStMu+97ytxkKVfkL+JYaxjFva9RVaELj+WTaiQIVyFDmD8ZmAAAAAAAA
--Apple-Mail=_BC0C2AB2-A9C6-49B6-BF8D-ADE3B02B2710--


From nobody Mon Jan 26 09:23:11 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1B61ACD37 for ; Mon, 26 Jan 2015 09:23:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level: 
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 x9qGCkpspV2d for ; Mon, 26 Jan 2015 09:22:59 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E7FB1ACCE4 for ; Mon, 26 Jan 2015 09:22:54 -0800 (PST)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t0QHMj5h020981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Jan 2015 17:22:45 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0QHMivT008102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Jan 2015 17:22:45 GMT
Received: from abhmp0015.oracle.com (abhmp0015.oracle.com [141.146.116.21]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0QHMhHa021676; Mon, 26 Jan 2015 17:22:44 GMT
Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Jan 2015 09:22:43 -0800
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Phil Hunt 
In-Reply-To: <7EA9BE5B-9084-428E-8798-95258CF74A91@ve7jtb.com>
Date: Mon, 26 Jan 2015 09:22:41 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <54C44B61.9070207@cs.tcd.ie> <570442397.10635.1422152157315.JavaMail.yahoo@mail.yahoo.com> <54C6710F.1090909@cs.tcd.ie> <7EA9BE5B-9084-428E-8798-95258CF74A91@ve7jtb.com>
To: John Bradley 
X-Mailer: Apple Mail (2.1993)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Archived-At: 
Cc: "unbearable@ietf.org" , William Mills , Stephen Farrell 
Subject: Re: [Unbearable] moving ahead
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 17:23:03 -0000

re your last point.  My concern is the OAuth WG proceeding with a =
largely duplicative solution in the app layer.

If the unbearable drafts can address the TLS not being end-to-end (e.g. =
ending at a load-balancer scenario), then I=E2=80=99m not sure the OAuth =
work would be needed in its current scope.

I am concerned about keeping these separate WGs coordinated to avoid =
overlap and/or perceived/actual complexity in any resulting solution.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

> On Jan 26, 2015, at 9:04 AM, John Bradley  wrote:
>=20
> Last week I did a blog post on how token binding fits with a number of =
the other related specs.
> =
http://www.thread-safe.com/2015/01/proof-of-possession-putting-pieces.html=

>=20
> Based on feedback from one of the token binding authors, I didn't =
butcher it too much.
>=20
> I think the use of the key established by token binding is best left =
to the protocols that want to use it.
>=20
> Trying to cover the application layer is too broad a scope for this =
WG.
>=20
> John B.
>=20
>> On Jan 26, 2015, at 1:53 PM, Stephen Farrell =
 wrote:
>>=20
>>=20
>> Hi Bill,
>>=20
>> Ok, so now I get the addition you're requesting.
>>=20
>> On 25/01/15 02:15, Bill Mills wrote:
>>> =46rom my "elevator pitch" question in the other thread, "Clients
>>> (browsers) being able to tie credentials to locally generated and
>>> managed keys and assert that key to the auth service.".  #
>>=20
>> I note that that text does not occur in the current draft. [1]
>> But I also know what you mean so moving on...
>>=20
>>> To extend that I think it should be something like:
>>=20
>>> "Clients (browsers) being able to tie credentials to locally
>>> generated and managed keys and assert that key to the auth service.
>>> Those keys are used for signing transaction when accessing a
>>> protected resource via TLS.".
>>=20
>> Are you asking that this work be extended so as to define
>> a general method for producing digital signatures on application
>> layer objects with the private key that is needed for moving
>> away from bearer tokens? (Assuming a digital signature based
>> way of doing better than bearer tokens, which is a reasonable
>> assumption.)
>>=20
>> If so, that seems like a major extension of scope and I'd be
>> interested in whether or not folks support that idea. And I'd
>> be opposed myself FWIW - too many pitfalls. A general thing
>> like that might be a good follow on but in a separate WG I'd
>> argue.
>>=20
>> If not, and you mean something less broad, then I think it'd
>> be better if you could try again and please provide a specific
>> charter language suggestion that only covers the narrower
>> scope of work you mean. And then we can see if folks like
>> the idea. In that case, please use OLD/NEW form to describe
>> the changes to [1] that you propose.
>>=20
>> Thanks,
>> S.
>>=20
>> [1]
>> =
https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Cha=
rter-Draft.txt
>>=20
>>=20
>> Thanks,
>> S.
>>=20
>>=20
>>>=20
>>> On Saturday, January 24, 2015 5:48 PM, Stephen Farrell
>>>  wrote:
>>>=20
>>>=20
>>>=20
>>> Hi Bill,
>>>=20
>>> If you can send proposed text that'd be great. Absent that, to be
>>> honest, I'm not sure what change you'd like,
>>>=20
>>> Cheers, S.
>>>=20
>>> On 25/01/15 01:02, Bill Mills wrote:
>>>> I think the current text of the charter is not descriptive of what=20=

>>>> this WG is really trying to solve.  It reads as though this is
>>>> about TLS channel binding which is wrong.  I'd like to see that
>>>> fixed in the language of the charter to be clearer. There was a
>>>> thread recently on what the elevator pitch for this is, and I think
>>>> language similar to that shoudl be in the first paragraph.
>>>>=20
>>>> On Saturday, January 24, 2015 3:34 PM, Stephen Farrell=20
>>>>  wrote:
>>>>=20
>>>>=20
>>>>=20
>>>> Hiya,
>>>>=20
>>>> Andrei has asked me about next steps for this work, based on the=20
>>>> draft charter text at [1].
>>>>=20
>>>> I think that text is pretty good, but before I start the formal WG=20=

>>>> chartering process I wanted to check here that there aren't major=20=

>>>> problems with it.
>>>>=20
>>>> Two things I noted myself were that it'd be good to see some
>>>> support from server implementers who are not also browser makers.
>>>> And secondly, we probably need to talk to W3C about this too, as
>>>> [2] seems to need changes to XHR, which is their spec. [3] Both of
>>>> those could however be taken care of as we go forward.
>>>>=20
>>>> I did see Hannes' issue about TLS endpoint location and OAuth and=20=

>>>> those are issues that need to be addressed but that I think should
>>>> be done in a WG.
>>>>=20
>>>> So can folks who have new argument as to why this work is wrong,
>>>> or definitely needs a BoF or with other new substantive comments
>>>> please post those in the next few days. Or if you previously posted
>>>> a substantive comment that was not addressed (noting that addressed
>>>> !=3D accepted) please post a link to that thread.
>>>>=20
>>>> I'll look at what comes up and if there is nothing new I'll
>>>> probably start the WG chartering process around mid-week. (To be
>>>> clear: at present I don't think this one needs a BoF in March, but
>>>> could be a chartered WG before then.)
>>>>=20
>>>> Cheers, S.
>>>>=20
>>>> PS: As a process thing, if we're moving ahead here, this will
>>>> appear as a place-holder in the BoF list for March so we can
>>>> schedule a session for the WG, if that is formed, or else use that
>>>> session for a BoF if one turns out to be needed.
>>>>=20
>>>>=20
>>>> [1]=20
>>>> =
https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Cha=
rter-Draft.txt
>>>>=20
>>>>=20
>>>=20
>>>>=20
>> [2] https://tools.ietf.org/html/draft-balfanz-https-token-binding
>>>> [3] http://www.w3.org/TR/XMLHttpRequest/
>>>>=20
>>>> _______________________________________________ Unbearable mailing=20=

>>>> list Unbearable@ietf.org=20
>>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________ Unbearable mailing=20=

>>>> list Unbearable@ietf.org=20
>>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>>=20
>>>=20
>>> _______________________________________________ Unbearable mailing
>>> list Unbearable@ietf.org=20
>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>=20
>>>=20
>>>=20
>>>=20
>>=20
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.org/mailman/listinfo/unbearable
>=20
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable


From nobody Mon Jan 26 09:42:12 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC3B1A2130 for ; Mon, 26 Jan 2015 09:42:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.509
X-Spam-Level: 
X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 4hNZ-TPvucpK for ; Mon, 26 Jan 2015 09:42:08 -0800 (PST)
Received: from nm27-vm1.bullet.mail.bf1.yahoo.com (nm27-vm1.bullet.mail.bf1.yahoo.com [98.139.213.148]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BAB21A1C05 for ; Mon, 26 Jan 2015 09:42:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1422294127; bh=TuO+p9l4L1ffmlbiqc38OgcKWWAi5ls44IheJJlW5Nw=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=MAazCY0/fRrRzDJH2iuST4sFnPjw45DdFVaH6Rj3VOzxQRejxy9o3RVSCrHS+n0XikGCeAZ7Yzf1uqt+SZWOQnLsOJqrAGrpLwaY55Jcl72WMkKe7Djr5MuxwoYMeMkN27/FOJDRdpDTrvBrpIeTktjATKMgqGRvIpykz2qsEmNT3JHdiTND6oyCIm3c/NI7Ni7cZvkkUI2yLVr8BMYQNp0heXtmpu1j1q07f9Ro+up7K2JIF3qkRX1S7gyERpG2M9e4xC2GREONGV5r5KOqe+4S1ln8G6y/87QJysIZOfERJ172MH7aawO2RQvSeHUxJTm/zZfTuxh5TTeIxibSNQ==
Received: from [98.139.215.141] by nm27.bullet.mail.bf1.yahoo.com with NNFMP;  26 Jan 2015 17:42:07 -0000
Received: from [98.139.212.201] by tm12.bullet.mail.bf1.yahoo.com with NNFMP;  26 Jan 2015 17:42:07 -0000
Received: from [127.0.0.1] by omp1010.mail.bf1.yahoo.com with NNFMP; 26 Jan 2015 17:42:07 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 826838.41396.bm@omp1010.mail.bf1.yahoo.com
X-YMail-OSG: DM3Rn4YLUzuy2vOsY6Utjt4C3x4USB89ZPumJCro1Ae1Sg--
Received: by 76.13.26.109; Mon, 26 Jan 2015 17:42:07 +0000 
Date: Mon, 26 Jan 2015 17:42:06 +0000 (UTC)
From: Bill Mills 
To: Stephen Farrell ,  "unbearable@ietf.org" 
Message-ID: <404474198.673987.1422294126678.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <54C6710F.1090909@cs.tcd.ie>
References: <54C6710F.1090909@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_673986_348463173.1422294126672"
Archived-At: 
Subject: Re: [Unbearable] moving ahead
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 17:42:11 -0000

------=_Part_673986_348463173.1422294126672
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I don't think it's an extension of scope, this is talking about how to hand=
le arbitrary security tokens like cookies and OAuth tokens which are presen=
ted differently enough that we're talking about generic HTTP signing.
As an aside this is very reminiscent of Eran's MAC cookies concept.
=20
One of the foundation documents for this=C2=A0
     On Monday, January 26, 2015 8:53 AM, Stephen Farrell  wrote:
  =20

=20
Hi Bill,

Ok, so now I get the addition you're requesting.

On 25/01/15 02:15, Bill Mills wrote:
> From my "elevator pitch" question in the other thread, "Clients
> (browsers) being able to tie credentials to locally generated and
> managed keys and assert that key to the auth service.".=C2=A0 #

I note that that text does not occur in the current draft. [1]
But I also know what you mean so moving on...

> To extend that I think it should be something like:

> "Clients (browsers) being able to tie credentials to locally
> generated and managed keys and assert that key to the auth service.
> Those keys are used for signing transaction when accessing a
> protected resource via TLS.".

Are you asking that this work be extended so as to define
a general method for producing digital signatures on application
layer objects with the private key that is needed for moving
away from bearer tokens? (Assuming a digital signature based
way of doing better than bearer tokens, which is a reasonable
assumption.)

If so, that seems like a major extension of scope and I'd be
interested in whether or not folks support that idea. And I'd
be opposed myself FWIW - too many pitfalls. A general thing
like that might be a good follow on but in a separate WG I'd
argue.

If not, and you mean something less broad, then I think it'd
be better if you could try again and please provide a specific
charter language suggestion that only covers the narrower
scope of work you mean. And then we can see if folks like
the idea. In that case, please use OLD/NEW form to describe
the changes to [1] that you propose.

Thanks,
S.

[1]
https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Char=
ter-Draft.txt


Thanks,
S.


>=20
> On Saturday, January 24, 2015 5:48 PM, Stephen Farrell
>  wrote:
>=20
>=20
>=20
> Hi Bill,
>=20
> If you can send proposed text that'd be great. Absent that, to be
> honest, I'm not sure what change you'd like,
>=20
> Cheers, S.
>=20
> On 25/01/15 01:02, Bill Mills wrote:
>> I think the current text of the charter is not descriptive of what=20
>> this WG is really trying to solve.=C2=A0 It reads as though this is
>> about TLS channel binding which is wrong.=C2=A0 I'd like to see that
>> fixed in the language of the charter to be clearer. There was a
>> thread recently on what the elevator pitch for this is, and I think
>> language similar to that shoudl be in the first paragraph.
>>=20
>> On Saturday, January 24, 2015 3:34 PM, Stephen Farrell=20
>>  wrote:
>>=20
>>=20
>>=20
>> Hiya,
>>=20
>> Andrei has asked me about next steps for this work, based on the=20
>> draft charter text at [1].
>>=20
>> I think that text is pretty good, but before I start the formal WG=20
>> chartering process I wanted to check here that there aren't major=20
>> problems with it.
>>=20
>> Two things I noted myself were that it'd be good to see some
>> support from server implementers who are not also browser makers.
>> And secondly, we probably need to talk to W3C about this too, as
>> [2] seems to need changes to XHR, which is their spec. [3] Both of
>> those could however be taken care of as we go forward.
>>=20
>> I did see Hannes' issue about TLS endpoint location and OAuth and=20
>> those are issues that need to be addressed but that I think should
>> be done in a WG.
>>=20
>> So can folks who have new argument as to why this work is wrong,
>> or definitely needs a BoF or with other new substantive comments
>> please post those in the next few days. Or if you previously posted
>> a substantive comment that was not addressed (noting that addressed
>> !=3D accepted) please post a link to that thread.
>>=20
>> I'll look at what comes up and if there is nothing new I'll
>> probably start the WG chartering process around mid-week. (To be
>> clear: at present I don't think this one needs a BoF in March, but
>> could be a chartered WG before then.)
>>=20
>> Cheers, S.
>>=20
>> PS: As a process thing, if we're moving ahead here, this will
>> appear as a place-holder in the BoF list for March so we can
>> schedule a session for the WG, if that is formed, or else use that
>> session for a BoF if one turns out to be needed.
>>=20
>>=20
>> [1]=20
>> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-C=
harter-Draft.txt
>>
>>
>
>>=20
[2] https://tools.ietf.org/html/draft-balfanz-https-token-binding
>> [3] http://www.w3.org/TR/XMLHttpRequest/
>>=20
>> _______________________________________________ Unbearable mailing=20
>> list Unbearable@ietf.org=20
>> https://www.ietf.org/mailman/listinfo/unbearable
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________ Unbearable mailing=20
>> list Unbearable@ietf.org=20
>> https://www.ietf.org/mailman/listinfo/unbearable
>>=20
>=20
> _______________________________________________ Unbearable mailing
> list Unbearable@ietf.org=20
> https://www.ietf.org/mailman/listinfo/unbearable
>=20
>=20
>=20
>=20


   
------=_Part_673986_348463173.1422294126672
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I d=
on't think it's an extension of scope, this is talking about how to handle =
arbitrary security tokens like cookies and OAuth tokens which are presented=
 differently enough that we're talking about generic HTTP signing.

As an aside this is very =
reminiscent of Eran's MAC cookies concept.

 

One of the foundati=
on documents for this 

 
  
  On Mond=
ay, January 26, 2015 8:53 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie=
> wrote:
  
  

 

Hi Bill,

Ok, so now I get the addition you're requestin=
g.

On 25/01/15 02:15, Bill Mills wrote=
:
> From my "elevator pitch" question in the other thr=
ead, "Clients
> (browsers) being able to tie credentia=
ls to locally generated and
> managed keys and assert =
that key to the auth service.".  #

I note that that text does not occur in the current draft. [1]
But I also know what you mean so moving on...
<=
br clear=3D"none">> To extend that I think it should be something like:<=
br clear=3D"none">
> "Clients (browsers) being able to=
 tie credentials to locally
> generated and managed ke=
ys and assert that key to the auth service.
> Those ke=
ys are used for signing transaction when accessing a
>=
 protected resource via TLS.".

Are you=
 asking that this work be extended so as to define
a gene=
ral method for producing digital signatures on application
layer objects with the private key that is needed for moving
away from bearer tokens? (Assuming a digital signature based
way of doing better than bearer tokens, which is a reasonable
assumption.)

If so, tha=
t seems like a major extension of scope and I'd be
intere=
sted in whether or not folks support that idea. And I'd
b=
e opposed myself FWIW - too many pitfalls. A general thing
like that might be a good follow on but in a separate WG I'd
argue.

If not, and you mean some=
thing less broad, then I think it'd
be better if you coul=
d try again and please provide a specific
charter languag=
e suggestion that only covers the narrower
scope of work =
you mean. And then we can see if folks like
the idea. In =
that case, please use OLD/NEW form to describe
the change=
s to [1] that you propose.

Thanks,
S.

[1]
https://github=
.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Charter-Draft.txt<=
/a>


Thanks,

S.


> 
> On S=
aturday, January 24, 2015 5:48 PM, Stephen Farrell
> &=
lt;stephen.farrell@cs.tcd.ie> wrote:> 
> 
> 
> Hi Bill,
> 
> =
If you can send proposed text that'd be great. Absent that, to be
> honest, I'm not sure what change you'd like,
> 
> Cheers, S.
> 
> On 25/01/15 01:02, Bill Mills wrote:
>&=
gt; I think the current text of the charter is not descriptive of what 
>> this WG is really trying to solve.  It reads a=
s though this is
>> about TLS channel binding which=
 is wrong.  I'd like to see that
>> fixed in t=
he language of the charter to be clearer. There was a
>=
;> thread recently on what the elevator pitch for this is, and I think>> language similar to that shoudl be in the first p=
aragraph.
>> 
>> On Saturda=
y, January 24, 2015 3:34 PM, Stephen Farrell 
>> &l=
t;stephen.farrell@cs.tcd.ie> wrote:>> 
>> 
>=
;> 
>> Hiya,
>> 
>> Andrei has asked me about next steps for this work, bas=
ed on the 
>> draft charter text at [1].
>> 
>> I think that text is pretty =
good, but before I start the formal WG 
>> charteri=
ng process I wanted to check here that there aren't major 
>> problems with it.
>> 
=
>> Two things I noted myself were that it'd be good to see some
>> support from server implementers who are not also bro=
wser makers.
>> And secondly, we probably need to t=
alk to W3C about this too, as
>> [2] seems to need =
changes to XHR, which is their spec. [3] Both of
>>=
 those could however be taken care of as we go forward.
&=
gt;> 
>> I did see Hannes' issue about TLS endpo=
int location and OAuth and 
>> those are issues tha=
t need to be addressed but that I think should
>> b=
e done in a WG.
>> 
>> So c=
an folks who have new argument as to why this work is wrong,
>> or definitely needs a BoF or with other new substantive commen=
ts
>> please post those in the next few days. Or if=
 you previously posted
>> a substantive comment tha=
t was not addressed (noting that addressed
>> !=3D =
accepted) please post a link to that thread.
>> >> I'll look at what comes up and if there is nothing=
 new I'll
>> probably start the WG chartering proce=
ss around mid-week. (To be
>> clear: at present I d=
on't think this one needs a BoF in March, but
>> co=
uld be a chartered WG before then.)
>> 
>> Cheers, S.
>> 
&g=
t;> PS: As a process thing, if we're moving ahead here, this will
>> appear as a place-holder in the BoF list for March so =
we can
>> schedule a session for the WG, if that is=
 formed, or else use that
>> session for a BoF if o=
ne turns out to be needed.
>> 
&g=
t;> 
>> [1] 
>> https://github.com/TokenBinding/WG-Charter/blob/master/Tok=
enBinding-WG-Charter-Draft.txt
>>
>>
>
>> 
[2] https://tools.ietf.org/html/d=
raft-balfanz-https-token-binding
>> [3] =
http://www.w3.org/TR/XMLHttpRequest/
>> 
>> _______________________________________________ Unbear=
able mailing 
>> list Unbearable@=
ietf.org 
>> https://www.iet=
f.org/mailman/listinfo/unbearable
>> 
>> 
>> 
>> =

>> 
>> 
=
>> _______________________________________________ Unbearable mailing=
 
>> list Unbearable@ietf.org=
 
>> https://www.ietf.org/mailma=
n/listinfo/unbearable
>> 
>=
; 
> _______________________________________________ U=
nbearable mailing
> list Unbearable@=
ietf.org 
> https://www.ietf.or=
g/mailman/listinfo/unbearable
> 
> 
> 
> 


  
 
  
 
------=_Part_673986_348463173.1422294126672--


From nobody Mon Jan 26 09:43:55 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC5C1A3BA6 for ; Mon, 26 Jan 2015 09:43:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 5dJaUfAhiAFg for ; Mon, 26 Jan 2015 09:43:51 -0800 (PST)
Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ABBD1A6F03 for ; Mon, 26 Jan 2015 09:43:51 -0800 (PST)
Received: by mail-qg0-f48.google.com with SMTP id z60so7921117qgd.7 for ; Mon, 26 Jan 2015 09:43:50 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=hltJR83rxpsxn1YH46IBIC/8uvISSZI5rWQiD5nsD9s=; b=RxJpvNSyXaFNwqwEiI6MthrP7Yv+ooeuyreaBZD0LgqDAdrPowkllUGJ24JjJIeLnG dXRglrrtpxfh4Z6D4feToQYX3sYYdGMrT0OnD/8iUmbCiZQxEdmHZwUdaLc0puyDgPub 5UB9qaXXr/10dvqOtDKyUPxOKJGlOl3jOYLF333RqYpLLkHCGehHzpl5UgzAvukwlPPQ vjRPrvisU5zVsz2mJvNLELSJ0HnfzNpxl9YXQjji02ZsQgeLlBGBq/w6AVfdDoCF5VpE kIaTSyjEw4K1YAHOHg2LuS1YtOc74ESKUcS78UUHlxTbUolcuQPW0OClCKIjFs1Yy63T 5r8g==
X-Gm-Message-State: ALoCoQkbqFRWaklymlgUS+TDSpN3hAzARc7cRVZBkVopgSzUYW07yt2jlQkMuerXD0MeAfsk9Cn7
X-Received: by 10.224.112.9 with SMTP id u9mr37387781qap.18.1422294230165; Mon, 26 Jan 2015 09:43:50 -0800 (PST)
Received: from [192.168.1.42] (186-106-135-17.baf.movistar.cl. [186.106.135.17]) by mx.google.com with ESMTPSA id c3sm10566777qan.45.2015.01.26.09.43.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Jan 2015 09:43:49 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_F72963DB-5808-4260-BA68-AA82F14C79FE"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: John Bradley 
In-Reply-To: 
Date: Mon, 26 Jan 2015 14:43:41 -0300
Message-Id: 
References: <54C44B61.9070207@cs.tcd.ie> <570442397.10635.1422152157315.JavaMail.yahoo@mail.yahoo.com> <54C6710F.1090909@cs.tcd.ie> <7EA9BE5B-9084-428E-8798-95258CF74A91@ve7jtb.com> 
To: Phil Hunt 
X-Mailer: Apple Mail (2.1993)
Archived-At: 
Cc: "unbearable@ietf.org" , William Mills , Stephen Farrell 
Subject: Re: [Unbearable] moving ahead
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 17:43:54 -0000

--Apple-Mail=_F72963DB-5808-4260-BA68-AA82F14C79FE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I don't think the OAuth work is duplicative, mostly because I don't =
think that Token binding adds much to native/server applications that we =
don't already have with mutual TLS (perhaps some slightly nicer ways to =
do the same thing)

Token binding will be useful for OAuth clients that are in the browser =
and in securing the authorization request/response flow via the browser.

I don't think that Token binding doing end to end message level =
authentication over non TLS connections is in scope for this WG.

John B.

> On Jan 26, 2015, at 2:22 PM, Phil Hunt  wrote:
>=20
> re your last point.  My concern is the OAuth WG proceeding with a =
largely duplicative solution in the app layer.
>=20
> If the unbearable drafts can address the TLS not being end-to-end =
(e.g. ending at a load-balancer scenario), then I=E2=80=99m not sure the =
OAuth work would be needed in its current scope.
>=20
> I am concerned about keeping these separate WGs coordinated to avoid =
overlap and/or perceived/actual complexity in any resulting solution.
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
>> On Jan 26, 2015, at 9:04 AM, John Bradley  wrote:
>>=20
>> Last week I did a blog post on how token binding fits with a number =
of the other related specs.
>> =
http://www.thread-safe.com/2015/01/proof-of-possession-putting-pieces.html=

>>=20
>> Based on feedback from one of the token binding authors, I didn't =
butcher it too much.
>>=20
>> I think the use of the key established by token binding is best left =
to the protocols that want to use it.
>>=20
>> Trying to cover the application layer is too broad a scope for this =
WG.
>>=20
>> John B.
>>=20
>>> On Jan 26, 2015, at 1:53 PM, Stephen Farrell =
 wrote:
>>>=20
>>>=20
>>> Hi Bill,
>>>=20
>>> Ok, so now I get the addition you're requesting.
>>>=20
>>> On 25/01/15 02:15, Bill Mills wrote:
>>>> =46rom my "elevator pitch" question in the other thread, "Clients
>>>> (browsers) being able to tie credentials to locally generated and
>>>> managed keys and assert that key to the auth service.".  #
>>>=20
>>> I note that that text does not occur in the current draft. [1]
>>> But I also know what you mean so moving on...
>>>=20
>>>> To extend that I think it should be something like:
>>>=20
>>>> "Clients (browsers) being able to tie credentials to locally
>>>> generated and managed keys and assert that key to the auth service.
>>>> Those keys are used for signing transaction when accessing a
>>>> protected resource via TLS.".
>>>=20
>>> Are you asking that this work be extended so as to define
>>> a general method for producing digital signatures on application
>>> layer objects with the private key that is needed for moving
>>> away from bearer tokens? (Assuming a digital signature based
>>> way of doing better than bearer tokens, which is a reasonable
>>> assumption.)
>>>=20
>>> If so, that seems like a major extension of scope and I'd be
>>> interested in whether or not folks support that idea. And I'd
>>> be opposed myself FWIW - too many pitfalls. A general thing
>>> like that might be a good follow on but in a separate WG I'd
>>> argue.
>>>=20
>>> If not, and you mean something less broad, then I think it'd
>>> be better if you could try again and please provide a specific
>>> charter language suggestion that only covers the narrower
>>> scope of work you mean. And then we can see if folks like
>>> the idea. In that case, please use OLD/NEW form to describe
>>> the changes to [1] that you propose.
>>>=20
>>> Thanks,
>>> S.
>>>=20
>>> [1]
>>> =
https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Cha=
rter-Draft.txt
>>>=20
>>>=20
>>> Thanks,
>>> S.
>>>=20
>>>=20
>>>>=20
>>>> On Saturday, January 24, 2015 5:48 PM, Stephen Farrell
>>>>  wrote:
>>>>=20
>>>>=20
>>>>=20
>>>> Hi Bill,
>>>>=20
>>>> If you can send proposed text that'd be great. Absent that, to be
>>>> honest, I'm not sure what change you'd like,
>>>>=20
>>>> Cheers, S.
>>>>=20
>>>> On 25/01/15 01:02, Bill Mills wrote:
>>>>> I think the current text of the charter is not descriptive of what=20=

>>>>> this WG is really trying to solve.  It reads as though this is
>>>>> about TLS channel binding which is wrong.  I'd like to see that
>>>>> fixed in the language of the charter to be clearer. There was a
>>>>> thread recently on what the elevator pitch for this is, and I =
think
>>>>> language similar to that shoudl be in the first paragraph.
>>>>>=20
>>>>> On Saturday, January 24, 2015 3:34 PM, Stephen Farrell=20
>>>>>  wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Hiya,
>>>>>=20
>>>>> Andrei has asked me about next steps for this work, based on the=20=

>>>>> draft charter text at [1].
>>>>>=20
>>>>> I think that text is pretty good, but before I start the formal WG=20=

>>>>> chartering process I wanted to check here that there aren't major=20=

>>>>> problems with it.
>>>>>=20
>>>>> Two things I noted myself were that it'd be good to see some
>>>>> support from server implementers who are not also browser makers.
>>>>> And secondly, we probably need to talk to W3C about this too, as
>>>>> [2] seems to need changes to XHR, which is their spec. [3] Both of
>>>>> those could however be taken care of as we go forward.
>>>>>=20
>>>>> I did see Hannes' issue about TLS endpoint location and OAuth and=20=

>>>>> those are issues that need to be addressed but that I think should
>>>>> be done in a WG.
>>>>>=20
>>>>> So can folks who have new argument as to why this work is wrong,
>>>>> or definitely needs a BoF or with other new substantive comments
>>>>> please post those in the next few days. Or if you previously =
posted
>>>>> a substantive comment that was not addressed (noting that =
addressed
>>>>> !=3D accepted) please post a link to that thread.
>>>>>=20
>>>>> I'll look at what comes up and if there is nothing new I'll
>>>>> probably start the WG chartering process around mid-week. (To be
>>>>> clear: at present I don't think this one needs a BoF in March, but
>>>>> could be a chartered WG before then.)
>>>>>=20
>>>>> Cheers, S.
>>>>>=20
>>>>> PS: As a process thing, if we're moving ahead here, this will
>>>>> appear as a place-holder in the BoF list for March so we can
>>>>> schedule a session for the WG, if that is formed, or else use that
>>>>> session for a BoF if one turns out to be needed.
>>>>>=20
>>>>>=20
>>>>> [1]=20
>>>>> =
https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Cha=
rter-Draft.txt
>>>>>=20
>>>>>=20
>>>>=20
>>>>>=20
>>> [2] https://tools.ietf.org/html/draft-balfanz-https-token-binding
>>>>> [3] http://www.w3.org/TR/XMLHttpRequest/
>>>>>=20
>>>>> _______________________________________________ Unbearable mailing=20=

>>>>> list Unbearable@ietf.org=20
>>>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________ Unbearable mailing=20=

>>>>> list Unbearable@ietf.org=20
>>>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>>>=20
>>>>=20
>>>> _______________________________________________ Unbearable mailing
>>>> list Unbearable@ietf.org=20
>>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>> _______________________________________________
>>> Unbearable mailing list
>>> Unbearable@ietf.org
>>> https://www.ietf.org/mailman/listinfo/unbearable
>>=20
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.org/mailman/listinfo/unbearable
>=20


--Apple-Mail=_F72963DB-5808-4260-BA68-AA82F14C79FE
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAxMjYxNzQzNDFaMCMGCSqGSIb3DQEJBDEWBBQ4Mek83x4pvdNobkfZFZwy
VKY9ZTCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQCRbj4eNzLUeCrSd9zO5CP4SbQofwt3ffqVh1Fq/EL/MR4pC6fDTAjA
TcpBfvkVu425xzVpjMvpMBV2EqhK03mEZcQM+Xzua7OWPGKuPdSsLjsJRr9J6AvDUc8GHh+kE8gk
PSsGApZRLNkokPxy/9Tvk8SmfMuoqXQKiDSgBPccp+D4q81pUWUnBYjMZw5IONs08BqP9pG+mUn4
AihJvL22Lg7VeFFKjMbfFhOjsFS+uGhKY8atRwIOwyKvJMKN0gCeVVmOzIc6lWDBdspXq4MlBZpD
CYSnCQAq3biyhvcbgWmD4PixKFrsybuaqTI3lvZqGazC+GHi1ZBqI3+wD2c+AAAAAAAA
--Apple-Mail=_F72963DB-5808-4260-BA68-AA82F14C79FE--


From nobody Mon Jan 26 09:48:00 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4811E1A0399 for ; Mon, 26 Jan 2015 09:47:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.509
X-Spam-Level: 
X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Z2mcQm1o7n29 for ; Mon, 26 Jan 2015 09:47:56 -0800 (PST)
Received: from nm19-vm0.bullet.mail.bf1.yahoo.com (nm19-vm0.bullet.mail.bf1.yahoo.com [98.139.213.162]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FEF91A1BE5 for ; Mon, 26 Jan 2015 09:47:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1422294475; bh=9XHPfELV63O9N+iy5p5LOrtjArTxGTlrA4n3KQvUv9k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=VXWMZNhvgNWiQCYU/QkTFe3PHElNsWioDazWtOgc2OHw48Maj+wFW54FT2UQ/B9aXNbF9kwP85uUUXd1qH8C16ZTTIGcF5jHE9XMNYO0a0+TuJKtR6fMe0W6lIxFwrQ/ZG3zcvPjAFFW8aOaNIbl0SBwNu/zURv8MBxKRC4jaSk0tD9Q8rAukgSD8kPnXthOXsMH4lp/hD2qEi2zxdz6/E2JtjVsa7OkYfZF4PkPFBPgiK3ocskkWdisfts+DoeeLROrmAmpH95ykW/5sSAJLegjtwe0p6Fhn+uxU7Avfqlt8/k+SJ0KQEFKbyJ2ncZzN1sgWAy38oNEVjvC2WFQig==
Received: from [98.139.214.32] by nm19.bullet.mail.bf1.yahoo.com with NNFMP; 26 Jan 2015 17:47:55 -0000
Received: from [98.139.212.233] by tm15.bullet.mail.bf1.yahoo.com with NNFMP;  26 Jan 2015 17:47:55 -0000
Received: from [127.0.0.1] by omp1042.mail.bf1.yahoo.com with NNFMP; 26 Jan 2015 17:47:55 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 397315.22670.bm@omp1042.mail.bf1.yahoo.com
X-YMail-OSG: 5c_Mt_sVM1kVVwvFSKdjkhoK5JmfS.qwBMD2XbrbntWiLauLHWt7T6KMplrXRUQ OwZlMfnuYNwNIkxMFxKkj9IQMb1uUyuA6OBmYpvoMxtW_ZS4hyYF6VTPalaNe_U6CurkSkzHD8MC qHatoP57om5WsluQ5C_2xJGwN3J62BD69Tyt9AMXERbx2kvxRey9816PzhiJOojMXEJiB.xOBBuv ScM_4f0cXdsMIWSV849cEKpcdSqH9RV3Gdq3zgntJropvP1BmRrs08NsA7IQ96bowhy9.inEaOZD GU0s.M7n6fKIP7NoVio9YQ8Zz..vedokhprWj9wtbW3Iyqx9i6BtsgJ3pObANkKeWVt8D99EPEO3 wXyzHjbAPaiFYLWcyvASYbVtpCzdbwT6Aw3.GyczcmCfmOFmv1p1gSP2up2DG2nfZOMfIdzS55Ed Z9tIG14czZgRqEpv1GRQ3DqALCXCXveMAUHG5w0aXXtCqyP3Hn1aIcs4hrXA2mkuz21UE6bE3o0l c_uihJb7uDO9dl7D7HZEIj9U2ObLTDHSU2A.R9lEBCARgXcLwdyerb9.w6Y7z2Jl.W7mY3YfKKZ9 7nETz_HLAflVywvRaEmZDiE.4j2_i4nCE7Ey0S91aQiTTobAAWUJtrd2S0vKdImbTHKYrTspmxi_ OMIiUFqjrQZX4fpDOjMLiEtvgTY6rQDG3i.nSUEnNsJ0GCf9bd65l5TSqzELAv7.GONOfZH24JtQ lNS1iZpP0cMsHV8VqpwTBUnzl6L964TLmsSkyoO8I__9llUjSqYE1noRXgX9InzzkFmgSGjcn2ny V9iAIW6FLBOIgjXvreCIGlhpZz3iBLeHO80gzHyJiCoYIerPggjDOarhGtYS6Z6tokhIJdUe02Zb .WjoDlfwD6.E8.X6iuCI5G8EA572ALhD0OY1CFAJZmrpR
Received: by 66.196.81.110; Mon, 26 Jan 2015 17:47:54 +0000 
Date: Mon, 26 Jan 2015 17:47:54 +0000 (UTC)
From: Bill Mills 
To: John Bradley , Phil Hunt 
Message-ID: <339123303.662625.1422294474487.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_662621_22268132.1422294474445"
Archived-At: 
Cc: "unbearable@ietf.org" , Stephen Farrell 
Subject: Re: [Unbearable] moving ahead
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 17:47:59 -0000

------=_Part_662621_22268132.1422294474445
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In some ways this fits right in to POP if I understand it right. =C2=A0Some=
 of this is a way for a key pair to be negotiated that could be used for an=
 OAuth POP token, and that would be very useful.=20

     On Monday, January 26, 2015 9:43 AM, John Bradley  =
wrote:
  =20

 I don't think the OAuth work is duplicative, mostly because I don't think =
that Token binding adds much to native/server applications that we don't al=
ready have with mutual TLS (perhaps some slightly nicer ways to do the same=
 thing)

Token binding will be useful for OAuth clients that are in the browser and =
in securing the authorization request/response flow via the browser.

I don't think that Token binding doing end to end message level authenticat=
ion over non TLS connections is in scope for this WG.

John B.

> On Jan 26, 2015, at 2:22 PM, Phil Hunt  wrote:
>=20
> re your last point.=C2=A0 My concern is the OAuth WG proceeding with a la=
rgely duplicative solution in the app layer.
>=20
> If the unbearable drafts can address the TLS not being end-to-end (e.g. e=
nding at a load-balancer scenario), then I=E2=80=99m not sure the OAuth wor=
k would be needed in its current scope.
>=20
> I am concerned about keeping these separate WGs coordinated to avoid over=
lap and/or perceived/actual complexity in any resulting solution.
>=20
> Phil
>=20
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>=20
>> On Jan 26, 2015, at 9:04 AM, John Bradley  wrote:
>>=20
>> Last week I did a blog post on how token binding fits with a number of t=
he other related specs.
>> http://www.thread-safe.com/2015/01/proof-of-possession-putting-pieces.ht=
ml
>>=20
>> Based on feedback from one of the token binding authors, I didn't butche=
r it too much.
>>=20
>> I think the use of the key established by token binding is best left to =
the protocols that want to use it.
>>=20
>> Trying to cover the application layer is too broad a scope for this WG.
>>=20
>> John B.
>>=20
>>> On Jan 26, 2015, at 1:53 PM, Stephen Farrell  wrote:
>>>=20
>>>=20
>>> Hi Bill,
>>>=20
>>> Ok, so now I get the addition you're requesting.
>>>=20
>>> On 25/01/15 02:15, Bill Mills wrote:
>>>> From my "elevator pitch" question in the other thread, "Clients
>>>> (browsers) being able to tie credentials to locally generated and
>>>> managed keys and assert that key to the auth service.".=C2=A0 #
>>>=20
>>> I note that that text does not occur in the current draft. [1]
>>> But I also know what you mean so moving on...
>>>=20
>>>> To extend that I think it should be something like:
>>>=20
>>>> "Clients (browsers) being able to tie credentials to locally
>>>> generated and managed keys and assert that key to the auth service.
>>>> Those keys are used for signing transaction when accessing a
>>>> protected resource via TLS.".
>>>=20
>>> Are you asking that this work be extended so as to define
>>> a general method for producing digital signatures on application
>>> layer objects with the private key that is needed for moving
>>> away from bearer tokens? (Assuming a digital signature based
>>> way of doing better than bearer tokens, which is a reasonable
>>> assumption.)
>>>=20
>>> If so, that seems like a major extension of scope and I'd be
>>> interested in whether or not folks support that idea. And I'd
>>> be opposed myself FWIW - too many pitfalls. A general thing
>>> like that might be a good follow on but in a separate WG I'd
>>> argue.
>>>=20
>>> If not, and you mean something less broad, then I think it'd
>>> be better if you could try again and please provide a specific
>>> charter language suggestion that only covers the narrower
>>> scope of work you mean. And then we can see if folks like
>>> the idea. In that case, please use OLD/NEW form to describe
>>> the changes to [1] that you propose.
>>>=20
>>> Thanks,
>>> S.
>>>=20
>>> [1]
>>> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-=
Charter-Draft.txt
>>>=20
>>>=20
>>> Thanks,
>>> S.
>>>=20
>>>=20
>>>>=20
>>>> On Saturday, January 24, 2015 5:48 PM, Stephen Farrell
>>>>  wrote:
>>>>=20
>>>>=20
>>>>=20
>>>> Hi Bill,
>>>>=20
>>>> If you can send proposed text that'd be great. Absent that, to be
>>>> honest, I'm not sure what change you'd like,
>>>>=20
>>>> Cheers, S.
>>>>=20
>>>> On 25/01/15 01:02, Bill Mills wrote:
>>>>> I think the current text of the charter is not descriptive of what=20
>>>>> this WG is really trying to solve.=C2=A0 It reads as though this is
>>>>> about TLS channel binding which is wrong.=C2=A0 I'd like to see that
>>>>> fixed in the language of the charter to be clearer. There was a
>>>>> thread recently on what the elevator pitch for this is, and I think
>>>>> language similar to that shoudl be in the first paragraph.
>>>>>=20
>>>>> On Saturday, January 24, 2015 3:34 PM, Stephen Farrell=20
>>>>>  wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> Hiya,
>>>>>=20
>>>>> Andrei has asked me about next steps for this work, based on the=20
>>>>> draft charter text at [1].
>>>>>=20
>>>>> I think that text is pretty good, but before I start the formal WG=20
>>>>> chartering process I wanted to check here that there aren't major=20
>>>>> problems with it.
>>>>>=20
>>>>> Two things I noted myself were that it'd be good to see some
>>>>> support from server implementers who are not also browser makers.
>>>>> And secondly, we probably need to talk to W3C about this too, as
>>>>> [2] seems to need changes to XHR, which is their spec. [3] Both of
>>>>> those could however be taken care of as we go forward.
>>>>>=20
>>>>> I did see Hannes' issue about TLS endpoint location and OAuth and=20
>>>>> those are issues that need to be addressed but that I think should
>>>>> be done in a WG.
>>>>>=20
>>>>> So can folks who have new argument as to why this work is wrong,
>>>>> or definitely needs a BoF or with other new substantive comments
>>>>> please post those in the next few days. Or if you previously posted
>>>>> a substantive comment that was not addressed (noting that addressed
>>>>> !=3D accepted) please post a link to that thread.
>>>>>=20
>>>>> I'll look at what comes up and if there is nothing new I'll
>>>>> probably start the WG chartering process around mid-week. (To be
>>>>> clear: at present I don't think this one needs a BoF in March, but
>>>>> could be a chartered WG before then.)
>>>>>=20
>>>>> Cheers, S.
>>>>>=20
>>>>> PS: As a process thing, if we're moving ahead here, this will
>>>>> appear as a place-holder in the BoF list for March so we can
>>>>> schedule a session for the WG, if that is formed, or else use that
>>>>> session for a BoF if one turns out to be needed.
>>>>>=20
>>>>>=20
>>>>> [1]=20
>>>>> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-W=
G-Charter-Draft.txt
>>>>>=20
>>>>>=20
>>>>=20
>>>>>=20
>>> [2] https://tools.ietf.org/html/draft-balfanz-https-token-binding
>>>>> [3] http://www.w3.org/TR/XMLHttpRequest/
>>>>>=20
>>>>> _______________________________________________ Unbearable mailing=20
>>>>> list Unbearable@ietf.org=20
>>>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________ Unbearable mailing=20
>>>>> list Unbearable@ietf.org=20
>>>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>>>=20
>>>>=20
>>>> _______________________________________________ Unbearable mailing
>>>> list Unbearable@ietf.org=20
>>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>> _______________________________________________
>>> Unbearable mailing list
>>> Unbearable@ietf.org
>>> https://www.ietf.org/mailman/listinfo/unbearable
>>=20
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.org/mailman/listinfo/unbearable
>=20


   
------=_Part_662621_22268132.1422294474445
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


In some ways this fits right in to POP=
 if I understand it right.  Some of this is a way for a key pair to be=
 negotiated that could be used for an OAuth POP token, and that would be ve=
ry useful.
 


 
 
 
  On Monday, January 26, 2015 9:43=
 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
  
  
=

 
I don't think the OAuth work is duplica=
tive, mostly because I don't think that Token binding adds much to native/s=
erver applications that we don't already have with mutual TLS (perhaps some=
 slightly nicer ways to do the same thing)

Token binding will be useful for OAuth clients that are in the browser=
 and in securing the authorization request/response flow via the browser.
I don't think that Token binding doing =
end to end message level authentication over non TLS connections is in scop=
e for this WG.

John B.

> O=
n Jan 26, 2015, at 2:22 PM, Phil Hunt <phil.hunt@ora=
cle.com> wrote:
> 
> re yo=
ur last point.  My concern is the OAuth WG proceeding with a largely d=
uplicative solution in the app layer.
> 
> If the unbearable drafts can address the TLS not being end-to-end=
 (e.g. ending at a load-balancer scenario), then I=E2=80=99m not sure the O=
Auth work would be needed in its current scope.
> 
> I am concerned about keeping these separate WGs coordin=
ated to avoid overlap and/or perceived/actual complexity in any resulting s=
olution.
> 
> Phil
> 
> @independentid
> www.=
independentid.com
> phil.hunt@orac=
le.com
> 
>> On Jan 26, 20=
15, at 9:04 AM, John Bradley <ve7jtb@ve7jtb.com> wr=
ote:
>> 
>> Last week I did=
 a blog post on how token binding fits with a number of the other related s=
pecs.
>> http://www.thread-safe.com/2015/01/proof-of-possession-putting-pieces.ht=
ml
>> 
>> Based on feed=
back from one of the token binding authors, I didn't butcher it too much.>> 
>> I think the use of th=
e key established by token binding is best left to the protocols that want =
to use it.
>> 
>> Trying to=
 cover the application layer is too broad a scope for this WG.
>> 
>> John B.
>&g=
t; 
>>> On Jan 26, 2015, at 1:53 PM, Stephen Far=
rell <stephen.farrell@cs.tcd.ie> wr=
ote:
>>> 
>>> 
>>> Hi Bill,
>>> 
>>> Ok, so now I get the addition you're requesting.
>>> 
>>> On 25/01/15 02:=
15, Bill Mills wrote:
>>>> From my "elevator =
pitch" question in the other thread, "Clients
>>>=
;> (browsers) being able to tie credentials to locally generated and
>>>> managed keys and assert that key to the aut=
h service.".  #
>>> 
>=
>> I note that that text does not occur in the current draft. [1]
>>> But I also know what you mean so moving on...>>> 
>>>> To extend=
 that I think it should be something like:
>>> <=
br clear=3D"none">>>>> "Clients (browsers) being able to tie cr=
edentials to locally
>>>> generated and manag=
ed keys and assert that key to the auth service.
>>=
>> Those keys are used for signing transaction when accessing a
>>>> protected resource via TLS.".
>>> 
>>> Are you asking that this wo=
rk be extended so as to define
>>> a general met=
hod for producing digital signatures on application
>&=
gt;> layer objects with the private key that is needed for moving
>>> away from bearer tokens? (Assuming a digital signa=
ture based
>>> way of doing better than bearer t=
okens, which is a reasonable
>>> assumption.)>>> 
>>> If so, that se=
ems like a major extension of scope and I'd be
>>&g=
t; interested in whether or not folks support that idea. And I'd
>>> be opposed myself FWIW - too many pitfalls. A genera=
l thing
>>> like that might be a good follow on =
but in a separate WG I'd
>>> argue.
>>> 
>>> If not, and you mean som=
ething less broad, then I think it'd
>>> be bett=
er if you could try again and please provide a specific
&=
gt;>> charter language suggestion that only covers the narrower
>>> scope of work you mean. And then we can see if fo=
lks like
>>> the idea. In that case, please use =
OLD/NEW form to describe
>>> the changes to [1] =
that you propose.
>>> 
>>=
;> Thanks,
>>> S.
>>&=
gt; 
>>> [1]
>>> https://github.com/T=
okenBinding/WG-Charter/blob/master/TokenBinding-WG-Charter-Draft.txt>>> 
>>> 
>>> Thanks,
>>> S.
>>> 
>>> 
>>=
>> 
>>>> On Saturday, January 24, 2015 =
5:48 PM, Stephen Farrell
>>>> <stephen.farrell@cs.tcd.ie> wrote:
>>>> 
>>>> 
=
>>>> 
>>>> Hi Bill,
>>>> 
>>>> If you can send p=
roposed text that'd be great. Absent that, to be
>>=
>> honest, I'm not sure what change you'd like,
>=
;>>> 
>>>> Cheers, S.
>>>> 
>>>> On 25/01/15 01:02,=
 Bill Mills wrote:
>>>>> I think the curre=
nt text of the charter is not descriptive of what 
>&g=
t;>>> this WG is really trying to solve.  It reads as though =
this is
>>>>> about TLS channel binding wh=
ich is wrong.  I'd like to see that
>>>>=
> fixed in the language of the charter to be clearer. There was a
>>>>> thread recently on what the elevator pitch=
 for this is, and I think
>>>>> language s=
imilar to that shoudl be in the first paragraph.
>>=
>>> 
>>>>> On Saturday, January 2=
4, 2015 3:34 PM, Stephen Farrell 
>>>>> &l=
t;stephen.farrell@cs.tcd.ie> wrote:>>>>> 
>>>>>=
; 
>>>>> 
>>>&g=
t;> Hiya,
>>>>> 
>=
>>>> Andrei has asked me about next steps for this work, based =
on the 
>>>>> draft charter text at [1].>>>>> 
>>>>&g=
t; I think that text is pretty good, but before I start the formal WG 
>>>>> chartering process I wanted to check her=
e that there aren't major 
>>>>> problems =
with it.
>>>>> 
>>=
>>> Two things I noted myself were that it'd be good to see some>>>>> support from server implementers who =
are not also browser makers.
>>>>> And sec=
ondly, we probably need to talk to W3C about this too, as
>>>>> [2] seems to need changes to XHR, which is their spec=
. [3] Both of
>>>>> those could however be=
 taken care of as we go forward.
>>>>> >>>>> I did see Hannes' issue about TLS endp=
oint location and OAuth and 
>>>>> those a=
re issues that need to be addressed but that I think should
>>>>> be done in a WG.
>>>>=
> 
>>>>> So can folks who have new argu=
ment as to why this work is wrong,
>>>>> o=
r definitely needs a BoF or with other new substantive comments
>>>>> please post those in the next few days. Or if y=
ou previously posted
>>>>> a substantive c=
omment that was not addressed (noting that addressed
>=
>>>> !=3D accepted) please post a link to that thread.
>>>>> 
>>>>> I'll=
 look at what comes up and if there is nothing new I'll
&=
gt;>>>> probably start the WG chartering process around mid-wee=
k. (To be
>>>>> clear: at present I don't =
think this one needs a BoF in March, but
>>>>=
> could be a chartered WG before then.)
>>>&g=
t;> 
>>>>> Cheers, S.
>>>>> 
>>>>> PS: As a proc=
ess thing, if we're moving ahead here, this will
>>=
>>> appear as a place-holder in the BoF list for March so we can>>>>> schedule a session for the WG, if tha=
t is formed, or else use that
>>>>> sessio=
n for a BoF if one turns out to be needed.
>>>&g=
t;> 
>>>>> 
>>&=
gt;>> [1] 
>>>>> https://github.com/TokenBinding/WG-=
Charter/blob/master/TokenBinding-WG-Charter-Draft.txt
>>>>> 
>>>>> 
>>>> 
>>>>> 
>>> [2] https://tools.ietf.=
org/html/draft-balfanz-https-token-binding
>>&g=
t;>> [3] http://www.w3.org/TR/XMLHttpRequest/
>>>>> 
>>>>> ________=
_______________________________________ Unbearable mailing 
>>>>> list Unbearable@ietf.org 
>>>>> https://www.ietf.org=
/mailman/listinfo/unbearable
>>>>> >>>>> 
>>>>>=
; 
>>>>> 
>>>&g=
t;> 
>>>>> 
>>&=
gt;>> _______________________________________________ Unbearable mail=
ing 
>>>>> list Unbeara=
ble@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/unbearable
>=
;>>>> 
>>>> 
&g=
t;>>> _______________________________________________ Unbearable m=
ailing
>>>> list Unbearable=
@ietf.org 
>>>> https:=
//www.ietf.org/mailman/listinfo/unbearable
>>&g=
t;> 
>>>> 
>>>&=
gt; 
>>>> 
>>> >>> ______________________________________________=
_
>>> Unbearable mailing list
=
>>> Unbearable@ietf.org
&=
gt;>> https://www.ietf.org/mailman/listinfo/unbear=
able
>> 
>> ___________=
____________________________________
>> Unbearable =
mailing list
>> Unbearable@ietf.o=
rg
>> https://www.ietf.org/m=
ailman/listinfo/unbearable
> 


  
 
  
 

------=_Part_662621_22268132.1422294474445--


From nobody Mon Jan 26 10:03:15 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626231A8700 for ; Mon, 26 Jan 2015 10:03:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 wRB-uZ3Q1Jai for ; Mon, 26 Jan 2015 10:03:08 -0800 (PST)
Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F150C1A86E5 for ; Mon, 26 Jan 2015 10:03:07 -0800 (PST)
Received: by mail-qc0-f176.google.com with SMTP id c9so8208354qcz.7 for ; Mon, 26 Jan 2015 10:03:07 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=rAxqDkmiJ1ikR/rcgtiV/LJUv3fxoGJDa/iNYRSyoP0=; b=fe27NCkDV+VG4IIvYUMc5CTHaDkYSAdwHjjOQ7uIA6tMxS3j/udnf4AXGkMYaAcqGe euYLRAkkj6vN89sId25CK8xk0h5HHaybFWDdsHZFV1VvD9Gt7bERwDsrt9memwbd907N dKUXWyE+N+K1YvpRnXb0gazGth2tZhSJ26hOvzGMiF2wHy8dWDs16MyJje5/02c11Aqv rFaq4Da2tyihk0AM51KYI+D0V4xxt7mUSX2ymwGpPSzqGR6VFWCjVyYqC1DUeK6C6VaD re/JPP0yutqkzM3PClXIxtR/dQU58UaG3qRNTTr0D54y7ewtT9XeO7rxjm4NXEHdK2Wu fxfA==
X-Gm-Message-State: ALoCoQlazPavXZoNd5r6mkoyOiQvxSGbDUuYa7hVuj0hLWE9y1jTgBkia3d3mI6g4PfKt0SJtARU
X-Received: by 10.140.108.9 with SMTP id i9mr40923122qgf.73.1422295387014; Mon, 26 Jan 2015 10:03:07 -0800 (PST)
Received: from [192.168.1.42] (186-106-135-17.baf.movistar.cl. [186.106.135.17]) by mx.google.com with ESMTPSA id q5sm10639882qan.24.2015.01.26.10.02.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Jan 2015 10:03:06 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_FBEB574F-06F3-41B6-B3B7-8CEF7A405F99"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: John Bradley 
In-Reply-To: <339123303.662625.1422294474487.JavaMail.yahoo@mail.yahoo.com>
Date: Mon, 26 Jan 2015 15:02:50 -0300
Message-Id: <4B97C960-06B5-49BC-93E9-729EF218430A@ve7jtb.com>
References:  <339123303.662625.1422294474487.JavaMail.yahoo@mail.yahoo.com>
To: Bill Mills 
X-Mailer: Apple Mail (2.1993)
Archived-At: 
Cc: "unbearable@ietf.org" , Stephen Farrell , Phil Hunt 
Subject: Re: [Unbearable] moving ahead
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 18:03:12 -0000

--Apple-Mail=_FBEB574F-06F3-41B6-B3B7-8CEF7A405F99
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_FC08055B-EDF3-4DD8-A0AD-ACC6AB87C710"


--Apple-Mail=_FC08055B-EDF3-4DD8-A0AD-ACC6AB87C710
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I think it will help to make OAuth browser based flows PoP enabled.

However the flows for server/native will probably benefit less.  In a =
native app you can now use a single client key across multiple sessions. =
 Using token binding likely will prevent the same key from being used =
both with the RS and token endpoint for privacy reasons.   By design the =
private key would also not be available to the application for signing =
messages (perhaps a web crypto API might be developed in the browser).

If you have a =E2=80=9Csmart=E2=80=9D client that can manage keys/certs =
then token binding is probably not a huge advancement.  =20
It is huge for browsers where that ability to manage keys doesn=E2=80=99t =
currently exist.

Just my opinion.
John B.

> On Jan 26, 2015, at 2:47 PM, Bill Mills  =
wrote:
>=20
> In some ways this fits right in to POP if I understand it right.  Some =
of this is a way for a key pair to be negotiated that could be used for =
an OAuth POP token, and that would be very useful.
>=20
>=20
> On Monday, January 26, 2015 9:43 AM, John Bradley  =
wrote:
>=20
>=20
> I don't think the OAuth work is duplicative, mostly because I don't =
think that Token binding adds much to native/server applications that we =
don't already have with mutual TLS (perhaps some slightly nicer ways to =
do the same thing)
>=20
> Token binding will be useful for OAuth clients that are in the browser =
and in securing the authorization request/response flow via the browser.
>=20
> I don't think that Token binding doing end to end message level =
authentication over non TLS connections is in scope for this WG.
>=20
> John B.
>=20
> > On Jan 26, 2015, at 2:22 PM, Phil Hunt > wrote:
> >=20
> > re your last point.  My concern is the OAuth WG proceeding with a =
largely duplicative solution in the app layer.
> >=20
> > If the unbearable drafts can address the TLS not being end-to-end =
(e.g. ending at a load-balancer scenario), then I=E2=80=99m not sure the =
OAuth work would be needed in its current scope.
> >=20
> > I am concerned about keeping these separate WGs coordinated to avoid =
overlap and/or perceived/actual complexity in any resulting solution.
> >=20
> > Phil
> >=20
> > @independentid
> > www.independentid.com
> > phil.hunt@oracle.com 
> >=20
> >> On Jan 26, 2015, at 9:04 AM, John Bradley > wrote:
> >>=20
> >> Last week I did a blog post on how token binding fits with a number =
of the other related specs.
> >> =
http://www.thread-safe.com/2015/01/proof-of-possession-putting-pieces.html=
 =

> >>=20
> >> Based on feedback from one of the token binding authors, I didn't =
butcher it too much.
> >>=20
> >> I think the use of the key established by token binding is best =
left to the protocols that want to use it.
> >>=20
> >> Trying to cover the application layer is too broad a scope for this =
WG.
> >>=20
> >> John B.
> >>=20
> >>> On Jan 26, 2015, at 1:53 PM, Stephen Farrell =
> wrote:
> >>>=20
> >>>=20
> >>> Hi Bill,
> >>>=20
> >>> Ok, so now I get the addition you're requesting.
> >>>=20
> >>> On 25/01/15 02:15, Bill Mills wrote:
> >>>> =46rom my "elevator pitch" question in the other thread, "Clients
> >>>> (browsers) being able to tie credentials to locally generated and
> >>>> managed keys and assert that key to the auth service.".  #
> >>>=20
> >>> I note that that text does not occur in the current draft. [1]
> >>> But I also know what you mean so moving on...
> >>>=20
> >>>> To extend that I think it should be something like:
> >>>=20
> >>>> "Clients (browsers) being able to tie credentials to locally
> >>>> generated and managed keys and assert that key to the auth =
service.
> >>>> Those keys are used for signing transaction when accessing a
> >>>> protected resource via TLS.".
> >>>=20
> >>> Are you asking that this work be extended so as to define
> >>> a general method for producing digital signatures on application
> >>> layer objects with the private key that is needed for moving
> >>> away from bearer tokens? (Assuming a digital signature based
> >>> way of doing better than bearer tokens, which is a reasonable
> >>> assumption.)
> >>>=20
> >>> If so, that seems like a major extension of scope and I'd be
> >>> interested in whether or not folks support that idea. And I'd
> >>> be opposed myself FWIW - too many pitfalls. A general thing
> >>> like that might be a good follow on but in a separate WG I'd
> >>> argue.
> >>>=20
> >>> If not, and you mean something less broad, then I think it'd
> >>> be better if you could try again and please provide a specific
> >>> charter language suggestion that only covers the narrower
> >>> scope of work you mean. And then we can see if folks like
> >>> the idea. In that case, please use OLD/NEW form to describe
> >>> the changes to [1] that you propose.
> >>>=20
> >>> Thanks,
> >>> S.
> >>>=20
> >>> [1]
> >>> =
https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Cha=
rter-Draft.txt =

> >>>=20
> >>>=20
> >>> Thanks,
> >>> S.
> >>>=20
> >>>=20
> >>>>=20
> >>>> On Saturday, January 24, 2015 5:48 PM, Stephen Farrell
> >>>> > =
wrote:
> >>>>=20
> >>>>=20
> >>>>=20
> >>>> Hi Bill,
> >>>>=20
> >>>> If you can send proposed text that'd be great. Absent that, to be
> >>>> honest, I'm not sure what change you'd like,
> >>>>=20
> >>>> Cheers, S.
> >>>>=20
> >>>> On 25/01/15 01:02, Bill Mills wrote:
> >>>>> I think the current text of the charter is not descriptive of =
what=20
> >>>>> this WG is really trying to solve.  It reads as though this is
> >>>>> about TLS channel binding which is wrong.  I'd like to see that
> >>>>> fixed in the language of the charter to be clearer. There was a
> >>>>> thread recently on what the elevator pitch for this is, and I =
think
> >>>>> language similar to that shoudl be in the first paragraph.
> >>>>>=20
> >>>>> On Saturday, January 24, 2015 3:34 PM, Stephen Farrell=20
> >>>>> > =
wrote:
> >>>>>=20
> >>>>>=20
> >>>>>=20
> >>>>> Hiya,
> >>>>>=20
> >>>>> Andrei has asked me about next steps for this work, based on the=20=

> >>>>> draft charter text at [1].
> >>>>>=20
> >>>>> I think that text is pretty good, but before I start the formal =
WG=20
> >>>>> chartering process I wanted to check here that there aren't =
major=20
> >>>>> problems with it.
> >>>>>=20
> >>>>> Two things I noted myself were that it'd be good to see some
> >>>>> support from server implementers who are not also browser =
makers.
> >>>>> And secondly, we probably need to talk to W3C about this too, as
> >>>>> [2] seems to need changes to XHR, which is their spec. [3] Both =
of
> >>>>> those could however be taken care of as we go forward.
> >>>>>=20
> >>>>> I did see Hannes' issue about TLS endpoint location and OAuth =
and=20
> >>>>> those are issues that need to be addressed but that I think =
should
> >>>>> be done in a WG.
> >>>>>=20
> >>>>> So can folks who have new argument as to why this work is wrong,
> >>>>> or definitely needs a BoF or with other new substantive comments
> >>>>> please post those in the next few days. Or if you previously =
posted
> >>>>> a substantive comment that was not addressed (noting that =
addressed
> >>>>> !=3D accepted) please post a link to that thread.
> >>>>>=20
> >>>>> I'll look at what comes up and if there is nothing new I'll
> >>>>> probably start the WG chartering process around mid-week. (To be
> >>>>> clear: at present I don't think this one needs a BoF in March, =
but
> >>>>> could be a chartered WG before then.)
> >>>>>=20
> >>>>> Cheers, S.
> >>>>>=20
> >>>>> PS: As a process thing, if we're moving ahead here, this will
> >>>>> appear as a place-holder in the BoF list for March so we can
> >>>>> schedule a session for the WG, if that is formed, or else use =
that
> >>>>> session for a BoF if one turns out to be needed.
> >>>>>=20
> >>>>>=20
> >>>>> [1]=20
> >>>>> =
https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Cha=
rter-Draft.txt =

> >>>>>=20
> >>>>>=20
> >>>>=20
> >>>>>=20
> >>> [2] https://tools.ietf.org/html/draft-balfanz-https-token-binding =

> >>>>> [3] http://www.w3.org/TR/XMLHttpRequest/ =

> >>>>>=20
> >>>>> _______________________________________________ Unbearable =
mailing=20
> >>>>> list Unbearable@ietf.org =20
> >>>>> https://www.ietf.org/mailman/listinfo/unbearable =

> >>>>>=20
> >>>>>=20
> >>>>>=20
> >>>>>=20
> >>>>>=20
> >>>>>=20
> >>>>> _______________________________________________ Unbearable =
mailing=20
> >>>>> list Unbearable@ietf.org =20
> >>>>> https://www.ietf.org/mailman/listinfo/unbearable =

> >>>>>=20
> >>>>=20
> >>>> _______________________________________________ Unbearable =
mailing
> >>>> list Unbearable@ietf.org =20
> >>>> https://www.ietf.org/mailman/listinfo/unbearable =

> >>>>=20
> >>>>=20
> >>>>=20
> >>>>=20
> >>>=20
> >>> _______________________________________________
> >>> Unbearable mailing list
> >>> Unbearable@ietf.org 
> >>> https://www.ietf.org/mailman/listinfo/unbearable =

> >>=20
> >> _______________________________________________
> >> Unbearable mailing list
> >> Unbearable@ietf.org 
> >> https://www.ietf.org/mailman/listinfo/unbearable =

> >=20
>=20
>=20


--Apple-Mail=_FC08055B-EDF3-4DD8-A0AD-ACC6AB87C710
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I think it will help to make OAuth browser based flows PoP =
enabled.

However the =
flows for server/native will probably benefit less.  In a native =
app you can now use a single client key across multiple sessions. =
 Using token binding likely will prevent the same key from being =
used both with the RS and token endpoint for privacy reasons.   By =
design the private key would also not be available to the application =
for signing messages (perhaps a web crypto API might be developed in the =
browser).

If =
you have a =E2=80=9Csmart=E2=80=9D client that can manage keys/certs =
then token binding is probably not a huge advancement. =
  
It is huge for browsers where that =
ability to manage keys doesn=E2=80=99t currently exist.

Just my =
opinion.
John B.

On =
Jan 26, 2015, at 2:47 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

In some ways this fits right in to POP if I understand it =
right.  Some of this is a way for a key pair to be negotiated that =
could be used for an OAuth POP token, and that would be very =
useful.
 


 =

 
 
  On Monday, =
January 26, 2015 9:43 AM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:
  
  

 =

I don't think the OAuth work is =
duplicative, mostly because I don't think that Token binding adds much =
to native/server applications that we don't already have with mutual TLS =
(perhaps some slightly nicer ways to do the same thing)

Token binding will be useful =
for OAuth clients that are in the browser and in securing the =
authorization request/response flow via the browser.

I don't think that Token =
binding doing end to end message level authentication over non TLS =
connections is in scope for this WG.

John B.

> On Jan 26, 2015, at 2:22 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> 
> re your last =
point.  My concern is the OAuth WG proceeding with a largely =
duplicative solution in the app layer.
> =

> If the unbearable drafts can address =
the TLS not being end-to-end (e.g. ending at a load-balancer scenario), =
then I=E2=80=99m not sure the OAuth work would be needed in its current =
scope.
> 
> I am concerned about keeping these separate WGs =
coordinated to avoid overlap and/or perceived/actual complexity in any =
resulting solution.
> 
> Phil
> 
> @independentid
> www.independentid.com
> =
phil.hunt@oracle.com
> =

>> On Jan 26, 2015, at 9:04 AM, John =
Bradley <ve7jtb@ve7jtb.com> =
wrote:
>> 
>> Last week I did a blog post on how token binding =
fits with a number of the other related specs.
>> http://www.thread-safe.com/2015/01/proof-of-possession-putting-=
pieces.html
>> 
>> Based on feedback from one of the token binding =
authors, I didn't butcher it too much.
>> 
>> I think the =
use of the key established by token binding is best left to the =
protocols that want to use it.
>> 
>> Trying to cover the application layer =
is too broad a scope for this WG.
>> =

>> John B.
>> 
>>> On Jan =
26, 2015, at 1:53 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>>> 
>>> 
>>> Hi Bill,
>>> 
>>> Ok, =
so now I get the addition you're requesting.
>>> 
>>> On =
25/01/15 02:15, Bill Mills wrote:
>>>> =46rom my "elevator pitch" question in the =
other thread, "Clients
>>>> =
(browsers) being able to tie credentials to locally generated and
>>>> managed keys and assert that =
key to the auth service.".  #
>>> 
>>> I =
note that that text does not occur in the current draft. [1]
>>> But I also know what you mean so =
moving on...
>>> 
>>>> To extend that I think it should be =
something like:
>>> 
>>>> "Clients (browsers) being =
able to tie credentials to locally
>>>> generated and managed keys and assert that =
key to the auth service.
>>>> =
Those keys are used for signing transaction when accessing a
>>>> protected resource via =
TLS.".
>>> 
>>> Are you asking that this work be extended so as =
to define
>>> a general method for =
producing digital signatures on application
>>> layer objects with the private key that is =
needed for moving
>>> away from =
bearer tokens? (Assuming a digital signature based
>>> way of doing better than bearer tokens, which is =
a reasonable
>>> assumption.)
>>> 
>>> If so, that seems like a major extension of =
scope and I'd be
>>> interested in =
whether or not folks support that idea. And I'd
>>> be opposed myself FWIW - too many pitfalls. A =
general thing
>>> like that might =
be a good follow on but in a separate WG I'd
>>> argue.
>>> =

>>> If not, and you mean =
something less broad, then I think it'd
>>> be better if you could try again and please =
provide a specific
>>> charter =
language suggestion that only covers the narrower
>>> scope of work you mean. And then we can see if =
folks like
>>> the idea. In that =
case, please use OLD/NEW form to describe
>>> the changes to [1] that you propose.
>>> 
>>> Thanks,
>>> =
S.
>>> 
>>> [1]
>>> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBin=
ding-WG-Charter-Draft.txt
>>> =

>>> 
>>> Thanks,
>>> =
S.
>>> 
>>> 
>>>> =

>>>> On Saturday, January 24, =
2015 5:48 PM, Stephen Farrell
>>>> <stephen.farrell@cs.tcd.ie> wrote:
>>>> 
>>>>=
 
>>>> 
>>>> Hi Bill,
>>>> 
>>>>=
 If you can send proposed text that'd be great. Absent that, to be
>>>> honest, I'm not sure what =
change you'd like,
>>>> 
>>>> Cheers, S.
>>>> 
>>>>=
 On 25/01/15 01:02, Bill Mills wrote:
>>>>> I think the current text of the charter =
is not descriptive of what 
>>>>> this WG is really trying to solve.  =
It reads as though this is
>>>>> about TLS channel binding which is =
wrong.  I'd like to see that
>>>>> fixed in the language of the charter to =
be clearer. There was a
>>>>> =
thread recently on what the elevator pitch for this is, and I think
>>>>> language similar to that =
shoudl be in the first paragraph.
>>>>> 
>>>>> On Saturday, January 24, 2015 3:34 PM, =
Stephen Farrell 
>>>>> =
<stephen.farrell@cs.tcd.ie> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> Hiya,
>>>>> 
>>>>> Andrei has asked me about next steps for =
this work, based on the 
>>>>>=
 draft charter text at [1].
>>>>> 
>>>>> I think that text is pretty good, but =
before I start the formal WG 
>>>>> chartering process I wanted to check =
here that there aren't major 
>>>>> problems with it.
>>>>> 
>>>>> Two things I noted myself were that it'd =
be good to see some
>>>>> =
support from server implementers who are not also browser makers.
>>>>> And secondly, we probably =
need to talk to W3C about this too, as
>>>>> [2] seems to need changes to XHR, which =
is their spec. [3] Both of
>>>>> those could however be taken care of as =
we go forward.
>>>>> 
>>>>> I did see Hannes' issue =
about TLS endpoint location and OAuth and 
>>>>> those are issues that need to be =
addressed but that I think should
>>>>> be done in a WG.
>>>>> 
>>>>> So can folks who have new argument as to =
why this work is wrong,
>>>>> =
or definitely needs a BoF or with other new substantive comments
>>>>> please post those in the =
next few days. Or if you previously posted
>>>>> a substantive comment that was not =
addressed (noting that addressed
>>>>> !=3D accepted) please post a link to =
that thread.
>>>>> 
>>>>> I'll look at what comes =
up and if there is nothing new I'll
>>>>> probably start the WG chartering process =
around mid-week. (To be
>>>>> =
clear: at present I don't think this one needs a BoF in March, but
>>>>> could be a chartered WG =
before then.)
>>>>> 
>>>>> Cheers, S.
>>>>> 
>>>>> PS: As a process thing, if we're moving =
ahead here, this will
>>>>> =
appear as a place-holder in the BoF list for March so we can
>>>>> schedule a session for =
the WG, if that is formed, or else use that
>>>>> session for a BoF if one turns out to be =
needed.
>>>>> 
>>>>> 
>>>>> [1] 
>>>>> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBin=
ding-WG-Charter-Draft.txt
>>>>> 
>>>>> 
>>>> 
>>>>> 
>>>=
 [2] https://tools.ietf.org/html/draft-balfanz-https-token-binding
>>>>> [3] http://www.w3.org/TR/XMLHttpRequest/
>>>>> 
>>>>> =
_______________________________________________ Unbearable mailing 
>>>>> list Unbearable@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> =
_______________________________________________ Unbearable mailing 
>>>>> list Unbearable@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>>> 
>>>> 
>>>>=
 _______________________________________________ Unbearable mailing
>>>> list Unbearable@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>> 
>>>> 
>>>>=
 
>>>> 
>>> 
>>> =
_______________________________________________
>>> Unbearable mailing list
>>> Unbearable@ietf.org
>>> https://www.ietf.org/mailman/listinfo/unbearable
>> 
>> =
_______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> =
https://www.ietf.org/mailman/listinfo/unbearable
> 


  
 
  
 =


=

--Apple-Mail=_FC08055B-EDF3-4DD8-A0AD-ACC6AB87C710--

--Apple-Mail=_FBEB574F-06F3-41B6-B3B7-8CEF7A405F99
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAxMjYxODAyNTBaMCMGCSqGSIb3DQEJBDEWBBSjpFgRHOvVXQgyKXN/wnT9
EdC4CDCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQBqm4vRZJOBY8oHWCmms8XXg9sYuDrodCwF1R0gJPtbUPdXv7sQf1Ty
YUj8JkLcZP+L9Fg2Or9Mk0p6WyBTuz4ttp5gtULFM144a7MuiXT52Z94QmMysOoq0APceEwE/HMG
4BGfIgEv/wd+rG9CLQ5kkGrLw0rdiPq3lFSaMFI0Odlj/coum7oMi1wk4qG288njdSz9DYeXqSDQ
gVUPOVmdBkErIdlomI2Ue/EwP+vGJqbshwA8wwcX7zEesThjVhZ2hfJnJf/8HbMQJpiGn3Tnt/pS
yy/wCNstpJgQDgr81+l/IWJ7w9KoV+Q2dxm6VIn/qW9A9Brqo5RJ47Ry/gBDAAAAAAAA
--Apple-Mail=_FBEB574F-06F3-41B6-B3B7-8CEF7A405F99--


From nobody Mon Jan 26 10:24:49 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB381ACD30 for ; Mon, 26 Jan 2015 10:24:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 EaDAa6BGazgf for ; Mon, 26 Jan 2015 10:24:43 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965A61A90CA for ; Mon, 26 Jan 2015 10:24:43 -0800 (PST)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t0QIOd1Q032567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Jan 2015 18:24:39 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id t0QIOc9s022286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Jan 2015 18:24:38 GMT
Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0QIObRK010816; Mon, 26 Jan 2015 18:24:38 GMT
Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Jan 2015 10:24:37 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_3C8ACB78-948C-4580-9EB3-3C1304749389"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Phil Hunt 
In-Reply-To: <4B97C960-06B5-49BC-93E9-729EF218430A@ve7jtb.com>
Date: Mon, 26 Jan 2015 10:24:35 -0800
Message-Id: <8449BE8E-6416-4C35-80ED-8BC7CBF7ADB0@oracle.com>
References:  <339123303.662625.1422294474487.JavaMail.yahoo@mail.yahoo.com> <4B97C960-06B5-49BC-93E9-729EF218430A@ve7jtb.com>
To: John Bradley 
X-Mailer: Apple Mail (2.1993)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Archived-At: 
Cc: "unbearable@ietf.org" , William Mills , Stephen Farrell 
Subject: Re: [Unbearable] moving ahead
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 18:24:48 -0000

--Apple-Mail=_3C8ACB78-948C-4580-9EB3-3C1304749389
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I agree with part of what you are saying.

The browser flows are new.  The rest is duplicative. It is the overlap =
with the rest of the POP work that is problematic.

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

> On Jan 26, 2015, at 10:02 AM, John Bradley  wrote:
>=20
> I think it will help to make OAuth browser based flows PoP enabled.
>=20
> However the flows for server/native will probably benefit less.  In a =
native app you can now use a single client key across multiple sessions. =
 Using token binding likely will prevent the same key from being used =
both with the RS and token endpoint for privacy reasons.   By design the =
private key would also not be available to the application for signing =
messages (perhaps a web crypto API might be developed in the browser).
>=20
> If you have a =E2=80=9Csmart=E2=80=9D client that can manage =
keys/certs then token binding is probably not a huge advancement.  =20
> It is huge for browsers where that ability to manage keys doesn=E2=80=99=
t currently exist.
>=20
> Just my opinion.
> John B.
>=20
>> On Jan 26, 2015, at 2:47 PM, Bill Mills > wrote:
>>=20
>> In some ways this fits right in to POP if I understand it right.  =
Some of this is a way for a key pair to be negotiated that could be used =
for an OAuth POP token, and that would be very useful.
>>=20
>>=20
>> On Monday, January 26, 2015 9:43 AM, John Bradley > wrote:
>>=20
>>=20
>> I don't think the OAuth work is duplicative, mostly because I don't =
think that Token binding adds much to native/server applications that we =
don't already have with mutual TLS (perhaps some slightly nicer ways to =
do the same thing)
>>=20
>> Token binding will be useful for OAuth clients that are in the =
browser and in securing the authorization request/response flow via the =
browser.
>>=20
>> I don't think that Token binding doing end to end message level =
authentication over non TLS connections is in scope for this WG.
>>=20
>> John B.
>>=20
>> > On Jan 26, 2015, at 2:22 PM, Phil Hunt > wrote:
>> >=20
>> > re your last point.  My concern is the OAuth WG proceeding with a =
largely duplicative solution in the app layer.
>> >=20
>> > If the unbearable drafts can address the TLS not being end-to-end =
(e.g. ending at a load-balancer scenario), then I=E2=80=99m not sure the =
OAuth work would be needed in its current scope.
>> >=20
>> > I am concerned about keeping these separate WGs coordinated to =
avoid overlap and/or perceived/actual complexity in any resulting =
solution.
>> >=20
>> > Phil
>> >=20
>> > @independentid
>> > www.independentid.com 
>> > phil.hunt@oracle.com 
>> >=20
>> >> On Jan 26, 2015, at 9:04 AM, John Bradley > wrote:
>> >>=20
>> >> Last week I did a blog post on how token binding fits with a =
number of the other related specs.
>> >> =
http://www.thread-safe.com/2015/01/proof-of-possession-putting-pieces.html=
 =

>> >>=20
>> >> Based on feedback from one of the token binding authors, I didn't =
butcher it too much.
>> >>=20
>> >> I think the use of the key established by token binding is best =
left to the protocols that want to use it.
>> >>=20
>> >> Trying to cover the application layer is too broad a scope for =
this WG.
>> >>=20
>> >> John B.
>> >>=20
>> >>> On Jan 26, 2015, at 1:53 PM, Stephen Farrell =
> wrote:
>> >>>=20
>> >>>=20
>> >>> Hi Bill,
>> >>>=20
>> >>> Ok, so now I get the addition you're requesting.
>> >>>=20
>> >>> On 25/01/15 02:15, Bill Mills wrote:
>> >>>> =46rom my "elevator pitch" question in the other thread, =
"Clients
>> >>>> (browsers) being able to tie credentials to locally generated =
and
>> >>>> managed keys and assert that key to the auth service.".  #
>> >>>=20
>> >>> I note that that text does not occur in the current draft. [1]
>> >>> But I also know what you mean so moving on...
>> >>>=20
>> >>>> To extend that I think it should be something like:
>> >>>=20
>> >>>> "Clients (browsers) being able to tie credentials to locally
>> >>>> generated and managed keys and assert that key to the auth =
service.
>> >>>> Those keys are used for signing transaction when accessing a
>> >>>> protected resource via TLS.".
>> >>>=20
>> >>> Are you asking that this work be extended so as to define
>> >>> a general method for producing digital signatures on application
>> >>> layer objects with the private key that is needed for moving
>> >>> away from bearer tokens? (Assuming a digital signature based
>> >>> way of doing better than bearer tokens, which is a reasonable
>> >>> assumption.)
>> >>>=20
>> >>> If so, that seems like a major extension of scope and I'd be
>> >>> interested in whether or not folks support that idea. And I'd
>> >>> be opposed myself FWIW - too many pitfalls. A general thing
>> >>> like that might be a good follow on but in a separate WG I'd
>> >>> argue.
>> >>>=20
>> >>> If not, and you mean something less broad, then I think it'd
>> >>> be better if you could try again and please provide a specific
>> >>> charter language suggestion that only covers the narrower
>> >>> scope of work you mean. And then we can see if folks like
>> >>> the idea. In that case, please use OLD/NEW form to describe
>> >>> the changes to [1] that you propose.
>> >>>=20
>> >>> Thanks,
>> >>> S.
>> >>>=20
>> >>> [1]
>> >>> =
https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Cha=
rter-Draft.txt =

>> >>>=20
>> >>>=20
>> >>> Thanks,
>> >>> S.
>> >>>=20
>> >>>=20
>> >>>>=20
>> >>>> On Saturday, January 24, 2015 5:48 PM, Stephen Farrell
>> >>>> > =
wrote:
>> >>>>=20
>> >>>>=20
>> >>>>=20
>> >>>> Hi Bill,
>> >>>>=20
>> >>>> If you can send proposed text that'd be great. Absent that, to =
be
>> >>>> honest, I'm not sure what change you'd like,
>> >>>>=20
>> >>>> Cheers, S.
>> >>>>=20
>> >>>> On 25/01/15 01:02, Bill Mills wrote:
>> >>>>> I think the current text of the charter is not descriptive of =
what=20
>> >>>>> this WG is really trying to solve.  It reads as though this is
>> >>>>> about TLS channel binding which is wrong.  I'd like to see that
>> >>>>> fixed in the language of the charter to be clearer. There was a
>> >>>>> thread recently on what the elevator pitch for this is, and I =
think
>> >>>>> language similar to that shoudl be in the first paragraph.
>> >>>>>=20
>> >>>>> On Saturday, January 24, 2015 3:34 PM, Stephen Farrell=20
>> >>>>> > =
wrote:
>> >>>>>=20
>> >>>>>=20
>> >>>>>=20
>> >>>>> Hiya,
>> >>>>>=20
>> >>>>> Andrei has asked me about next steps for this work, based on =
the=20
>> >>>>> draft charter text at [1].
>> >>>>>=20
>> >>>>> I think that text is pretty good, but before I start the formal =
WG=20
>> >>>>> chartering process I wanted to check here that there aren't =
major=20
>> >>>>> problems with it.
>> >>>>>=20
>> >>>>> Two things I noted myself were that it'd be good to see some
>> >>>>> support from server implementers who are not also browser =
makers.
>> >>>>> And secondly, we probably need to talk to W3C about this too, =
as
>> >>>>> [2] seems to need changes to XHR, which is their spec. [3] Both =
of
>> >>>>> those could however be taken care of as we go forward.
>> >>>>>=20
>> >>>>> I did see Hannes' issue about TLS endpoint location and OAuth =
and=20
>> >>>>> those are issues that need to be addressed but that I think =
should
>> >>>>> be done in a WG.
>> >>>>>=20
>> >>>>> So can folks who have new argument as to why this work is =
wrong,
>> >>>>> or definitely needs a BoF or with other new substantive =
comments
>> >>>>> please post those in the next few days. Or if you previously =
posted
>> >>>>> a substantive comment that was not addressed (noting that =
addressed
>> >>>>> !=3D accepted) please post a link to that thread.
>> >>>>>=20
>> >>>>> I'll look at what comes up and if there is nothing new I'll
>> >>>>> probably start the WG chartering process around mid-week. (To =
be
>> >>>>> clear: at present I don't think this one needs a BoF in March, =
but
>> >>>>> could be a chartered WG before then.)
>> >>>>>=20
>> >>>>> Cheers, S.
>> >>>>>=20
>> >>>>> PS: As a process thing, if we're moving ahead here, this will
>> >>>>> appear as a place-holder in the BoF list for March so we can
>> >>>>> schedule a session for the WG, if that is formed, or else use =
that
>> >>>>> session for a BoF if one turns out to be needed.
>> >>>>>=20
>> >>>>>=20
>> >>>>> [1]=20
>> >>>>> =
https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Cha=
rter-Draft.txt =

>> >>>>>=20
>> >>>>>=20
>> >>>>=20
>> >>>>>=20
>> >>> [2] https://tools.ietf.org/html/draft-balfanz-https-token-binding =

>> >>>>> [3] http://www.w3.org/TR/XMLHttpRequest/ =

>> >>>>>=20
>> >>>>> _______________________________________________ Unbearable =
mailing=20
>> >>>>> list Unbearable@ietf.org =20
>> >>>>> https://www.ietf.org/mailman/listinfo/unbearable =

>> >>>>>=20
>> >>>>>=20
>> >>>>>=20
>> >>>>>=20
>> >>>>>=20
>> >>>>>=20
>> >>>>> _______________________________________________ Unbearable =
mailing=20
>> >>>>> list Unbearable@ietf.org =20
>> >>>>> https://www.ietf.org/mailman/listinfo/unbearable =

>> >>>>>=20
>> >>>>=20
>> >>>> _______________________________________________ Unbearable =
mailing
>> >>>> list Unbearable@ietf.org =20
>> >>>> https://www.ietf.org/mailman/listinfo/unbearable =

>> >>>>=20
>> >>>>=20
>> >>>>=20
>> >>>>=20
>> >>>=20
>> >>> _______________________________________________
>> >>> Unbearable mailing list
>> >>> Unbearable@ietf.org 
>> >>> https://www.ietf.org/mailman/listinfo/unbearable =

>> >>=20
>> >> _______________________________________________
>> >> Unbearable mailing list
>> >> Unbearable@ietf.org 
>> >> https://www.ietf.org/mailman/listinfo/unbearable =

>> >=20
>>=20
>>=20
>=20


--Apple-Mail=_3C8ACB78-948C-4580-9EB3-3C1304749389
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I agree with part of what you are saying.

The browser flows are new.  The =
rest is duplicative. It is the overlap with the rest of the POP work =
that is problematic.






On Jan 26, 2015, at 10:02 AM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:

I think it =
will help to make OAuth browser based flows PoP enabled.

However the flows for =
server/native will probably benefit less.  In a native app you can =
now use a single client key across multiple sessions.  Using token =
binding likely will prevent the same key from being used both with the =
RS and token endpoint for privacy reasons.   By design the private =
key would also not be available to the application for signing messages =
(perhaps a web crypto API might be developed in the browser).

If you have a =
=E2=80=9Csmart=E2=80=9D client that can manage keys/certs then token =
binding is probably not a huge advancement.   
It is huge for browsers where that ability to manage keys =
doesn=E2=80=99t currently exist.

Just my opinion.
John B.

On Jan =
26, 2015, at 2:47 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

In some ways this fits right in to POP if I understand it =
right.  Some of this is a way for a key pair to be negotiated that =
could be used for an OAuth POP token, and that would be very =
useful.
 


 =

 
 
  On Monday, =
January 26, 2015 9:43 AM, John Bradley <ve7jtb@ve7jtb.com> =
wrote:
  
  

 =

I don't think the OAuth work is =
duplicative, mostly because I don't think that Token binding adds much =
to native/server applications that we don't already have with mutual TLS =
(perhaps some slightly nicer ways to do the same thing)

Token binding will be useful =
for OAuth clients that are in the browser and in securing the =
authorization request/response flow via the browser.

I don't think that Token =
binding doing end to end message level authentication over non TLS =
connections is in scope for this WG.

John B.

> On Jan 26, 2015, at 2:22 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> 
> re your last =
point.  My concern is the OAuth WG proceeding with a largely =
duplicative solution in the app layer.
> =

> If the unbearable drafts can address =
the TLS not being end-to-end (e.g. ending at a load-balancer scenario), =
then I=E2=80=99m not sure the OAuth work would be needed in its current =
scope.
> 
> I am concerned about keeping these separate WGs =
coordinated to avoid overlap and/or perceived/actual complexity in any =
resulting solution.
> 
> Phil
> 
> @independentid
> www.independentid.com
> =
phil.hunt@oracle.com
> =

>> On Jan 26, 2015, at 9:04 AM, John =
Bradley <ve7jtb@ve7jtb.com> =
wrote:
>> 
>> Last week I did a blog post on how token binding =
fits with a number of the other related specs.
>> http://www.thread-safe.com/2015/01/proof-of-possession-putting-=
pieces.html
>> 
>> Based on feedback from one of the token binding =
authors, I didn't butcher it too much.
>> 
>> I think the =
use of the key established by token binding is best left to the =
protocols that want to use it.
>> 
>> Trying to cover the application layer =
is too broad a scope for this WG.
>> =

>> John B.
>> 
>>> On Jan =
26, 2015, at 1:53 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>>> 
>>> 
>>> Hi Bill,
>>> 
>>> Ok, =
so now I get the addition you're requesting.
>>> 
>>> On =
25/01/15 02:15, Bill Mills wrote:
>>>> =46rom my "elevator pitch" question in the =
other thread, "Clients
>>>> =
(browsers) being able to tie credentials to locally generated and
>>>> managed keys and assert that =
key to the auth service.".  #
>>> 
>>> I =
note that that text does not occur in the current draft. [1]
>>> But I also know what you mean so =
moving on...
>>> 
>>>> To extend that I think it should be =
something like:
>>> 
>>>> "Clients (browsers) being =
able to tie credentials to locally
>>>> generated and managed keys and assert that =
key to the auth service.
>>>> =
Those keys are used for signing transaction when accessing a
>>>> protected resource via =
TLS.".
>>> 
>>> Are you asking that this work be extended so as =
to define
>>> a general method for =
producing digital signatures on application
>>> layer objects with the private key that is =
needed for moving
>>> away from =
bearer tokens? (Assuming a digital signature based
>>> way of doing better than bearer tokens, which is =
a reasonable
>>> assumption.)
>>> 
>>> If so, that seems like a major extension of =
scope and I'd be
>>> interested in =
whether or not folks support that idea. And I'd
>>> be opposed myself FWIW - too many pitfalls. A =
general thing
>>> like that might =
be a good follow on but in a separate WG I'd
>>> argue.
>>> =

>>> If not, and you mean =
something less broad, then I think it'd
>>> be better if you could try again and please =
provide a specific
>>> charter =
language suggestion that only covers the narrower
>>> scope of work you mean. And then we can see if =
folks like
>>> the idea. In that =
case, please use OLD/NEW form to describe
>>> the changes to [1] that you propose.
>>> 
>>> Thanks,
>>> =
S.
>>> 
>>> [1]
>>> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBin=
ding-WG-Charter-Draft.txt
>>> =

>>> 
>>> Thanks,
>>> =
S.
>>> 
>>> 
>>>> =

>>>> On Saturday, January 24, =
2015 5:48 PM, Stephen Farrell
>>>> <stephen.farrell@cs.tcd.ie> wrote:
>>>> 
>>>>=
 
>>>> 
>>>> Hi Bill,
>>>> 
>>>>=
 If you can send proposed text that'd be great. Absent that, to be
>>>> honest, I'm not sure what =
change you'd like,
>>>> 
>>>> Cheers, S.
>>>> 
>>>>=
 On 25/01/15 01:02, Bill Mills wrote:
>>>>> I think the current text of the charter =
is not descriptive of what 
>>>>> this WG is really trying to solve.  =
It reads as though this is
>>>>> about TLS channel binding which is =
wrong.  I'd like to see that
>>>>> fixed in the language of the charter to =
be clearer. There was a
>>>>> =
thread recently on what the elevator pitch for this is, and I think
>>>>> language similar to that =
shoudl be in the first paragraph.
>>>>> 
>>>>> On Saturday, January 24, 2015 3:34 PM, =
Stephen Farrell 
>>>>> =
<stephen.farrell@cs.tcd.ie> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> Hiya,
>>>>> 
>>>>> Andrei has asked me about next steps for =
this work, based on the 
>>>>>=
 draft charter text at [1].
>>>>> 
>>>>> I think that text is pretty good, but =
before I start the formal WG 
>>>>> chartering process I wanted to check =
here that there aren't major 
>>>>> problems with it.
>>>>> 
>>>>> Two things I noted myself were that it'd =
be good to see some
>>>>> =
support from server implementers who are not also browser makers.
>>>>> And secondly, we probably =
need to talk to W3C about this too, as
>>>>> [2] seems to need changes to XHR, which =
is their spec. [3] Both of
>>>>> those could however be taken care of as =
we go forward.
>>>>> 
>>>>> I did see Hannes' issue =
about TLS endpoint location and OAuth and 
>>>>> those are issues that need to be =
addressed but that I think should
>>>>> be done in a WG.
>>>>> 
>>>>> So can folks who have new argument as to =
why this work is wrong,
>>>>> =
or definitely needs a BoF or with other new substantive comments
>>>>> please post those in the =
next few days. Or if you previously posted
>>>>> a substantive comment that was not =
addressed (noting that addressed
>>>>> !=3D accepted) please post a link to =
that thread.
>>>>> 
>>>>> I'll look at what comes =
up and if there is nothing new I'll
>>>>> probably start the WG chartering process =
around mid-week. (To be
>>>>> =
clear: at present I don't think this one needs a BoF in March, but
>>>>> could be a chartered WG =
before then.)
>>>>> 
>>>>> Cheers, S.
>>>>> 
>>>>> PS: As a process thing, if we're moving =
ahead here, this will
>>>>> =
appear as a place-holder in the BoF list for March so we can
>>>>> schedule a session for =
the WG, if that is formed, or else use that
>>>>> session for a BoF if one turns out to be =
needed.
>>>>> 
>>>>> 
>>>>> [1] 
>>>>> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBin=
ding-WG-Charter-Draft.txt
>>>>> 
>>>>> 
>>>> 
>>>>> 
>>>=
 [2] https://tools.ietf.org/html/draft-balfanz-https-token-binding
>>>>> [3] http://www.w3.org/TR/XMLHttpRequest/
>>>>> 
>>>>> =
_______________________________________________ Unbearable mailing 
>>>>> list Unbearable@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> =
_______________________________________________ Unbearable mailing 
>>>>> list Unbearable@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>>> 
>>>> 
>>>>=
 _______________________________________________ Unbearable mailing
>>>> list Unbearable@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>> 
>>>> 
>>>>=
 
>>>> 
>>> 
>>> =
_______________________________________________
>>> Unbearable mailing list
>>> Unbearable@ietf.org
>>> https://www.ietf.org/mailman/listinfo/unbearable
>> 
>> =
_______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> =
https://www.ietf.org/mailman/listinfo/unbearable
> 


  
 
  
 =



=

--Apple-Mail=_3C8ACB78-948C-4580-9EB3-3C1304749389--


From nobody Mon Jan 26 10:34:08 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E27911A711A for ; Mon, 26 Jan 2015 10:34:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 3xMBC3Riv7FV for ; Mon, 26 Jan 2015 10:34:00 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0129.outbound.protection.outlook.com [65.55.169.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85DC01ACD88 for ; Mon, 26 Jan 2015 10:33:59 -0800 (PST)
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.65.19; Mon, 26 Jan 2015 18:33:57 +0000
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0065.013; Mon, 26 Jan 2015 18:33:57 +0000
From: Anthony Nadalin 
To: John Bradley , Bill Mills 
Thread-Topic: [Unbearable] moving ahead
Thread-Index: AQHQOC5Ng+USYZpZ70iUI2dZrIhPmZzQBOoAgAAMs4CAAAe7gIACh4qAgAADH4CAAAUDgIAABd6AgAABLQCAAAQsAIAAB3IA
Date: Mon, 26 Jan 2015 18:33:57 +0000
Message-ID: 
References:  <339123303.662625.1422294474487.JavaMail.yahoo@mail.yahoo.com> <4B97C960-06B5-49BC-93E9-729EF218430A@ve7jtb.com>
In-Reply-To: <4B97C960-06B5-49BC-93E9-729EF218430A@ve7jtb.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::3]
authentication-results: ve7jtb.com; dkim=none (message not signed) header.d=none;ve7jtb.com; dmarc=none action=none header.from=microsoft.com;
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN3PR0301MB1234;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; 
x-forefront-prvs: 0468FE4A2B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(377454003)(164054003)(51444003)(51704005)(50986999)(76176999)(2900100001)(74316001)(2950100001)(19300405004)(19625215002)(551934003)(92566002)(122556002)(40100003)(54356999)(54206007)(54606007)(2521001)(19609705001)(2656002)(19617315012)(76576001)(16601075003)(46102003)(16236675004)(15975445007)(19580395003)(77156002)(102836002)(62966003)(87936001)(99286002)(86612001)(106116001)(86362001)(19580405001)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB123417B909372A0D19FA1E80A6350BN3PR0301MB1234_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2015 18:33:57.2304 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1234
Archived-At: 
Cc: "unbearable@ietf.org" , Phil Hunt , Stephen Farrell 
Subject: Re: [Unbearable] moving ahead
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 18:34:05 -0000

--_000_BN3PR0301MB123417B909372A0D19FA1E80A6350BN3PR0301MB1234_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SeKAmW0gbm90IHNlZWluZyBvdmVybGFwIGhlcmUgd2l0aCBPQVVUSCwgSk9TRSBhbmQgdGhlIHBy
b3Bvc2VkIG5ldyBXRywgSSBzZWUgYmVuZWZpdHMgdG8gT0FVVEggdG8gYWxsb3cgdXNhZ2Ugb2Yg
T0FVVEggYW5kIEpPU0UgZGVmaW5lZCB0b2tlbnMgYW5kIGtleXMsIEkgYWxzbyBzZWUgc29tZSBw
b3RlbnRpYWwgcHJpdmFjeSBlbmhhbmNlbWVudHMgdGhhdCB0aGUgbmV3IFdHIHByb3Bvc2FsIGNh
biBhZGQgYWxvbmcgd2l0aCBzb21lIGZlZGVyYXRpb24gaW1wcm92ZW1lbnRzIHRoYXQgd291bGQg
aGVscCBuYXRpdmUvc2VydmVyLg0KDQpGcm9tOiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJs
ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9obiBCcmFkbGV5DQpTZW50OiBNb25k
YXksIEphbnVhcnkgMjYsIDIwMTUgMTA6MDMgQU0NClRvOiBCaWxsIE1pbGxzDQpDYzogdW5iZWFy
YWJsZUBpZXRmLm9yZzsgU3RlcGhlbiBGYXJyZWxsOyBQaGlsIEh1bnQNClN1YmplY3Q6IFJlOiBb
VW5iZWFyYWJsZV0gbW92aW5nIGFoZWFkDQoNCkkgdGhpbmsgaXQgd2lsbCBoZWxwIHRvIG1ha2Ug
T0F1dGggYnJvd3NlciBiYXNlZCBmbG93cyBQb1AgZW5hYmxlZC4NCg0KSG93ZXZlciB0aGUgZmxv
d3MgZm9yIHNlcnZlci9uYXRpdmUgd2lsbCBwcm9iYWJseSBiZW5lZml0IGxlc3MuICBJbiBhIG5h
dGl2ZSBhcHAgeW91IGNhbiBub3cgdXNlIGEgc2luZ2xlIGNsaWVudCBrZXkgYWNyb3NzIG11bHRp
cGxlIHNlc3Npb25zLiAgVXNpbmcgdG9rZW4gYmluZGluZyBsaWtlbHkgd2lsbCBwcmV2ZW50IHRo
ZSBzYW1lIGtleSBmcm9tIGJlaW5nIHVzZWQgYm90aCB3aXRoIHRoZSBSUyBhbmQgdG9rZW4gZW5k
cG9pbnQgZm9yIHByaXZhY3kgcmVhc29ucy4gICBCeSBkZXNpZ24gdGhlIHByaXZhdGUga2V5IHdv
dWxkIGFsc28gbm90IGJlIGF2YWlsYWJsZSB0byB0aGUgYXBwbGljYXRpb24gZm9yIHNpZ25pbmcg
bWVzc2FnZXMgKHBlcmhhcHMgYSB3ZWIgY3J5cHRvIEFQSSBtaWdodCBiZSBkZXZlbG9wZWQgaW4g
dGhlIGJyb3dzZXIpLg0KDQpJZiB5b3UgaGF2ZSBhIOKAnHNtYXJ04oCdIGNsaWVudCB0aGF0IGNh
biBtYW5hZ2Uga2V5cy9jZXJ0cyB0aGVuIHRva2VuIGJpbmRpbmcgaXMgcHJvYmFibHkgbm90IGEg
aHVnZSBhZHZhbmNlbWVudC4NCkl0IGlzIGh1Z2UgZm9yIGJyb3dzZXJzIHdoZXJlIHRoYXQgYWJp
bGl0eSB0byBtYW5hZ2Uga2V5cyBkb2VzbuKAmXQgY3VycmVudGx5IGV4aXN0Lg0KDQpKdXN0IG15
IG9waW5pb24uDQpKb2huIEIuDQoNCk9uIEphbiAyNiwgMjAxNSwgYXQgMjo0NyBQTSwgQmlsbCBN
aWxscyA8d21pbGxzXzkyMTA1QHlhaG9vLmNvbTxtYWlsdG86d21pbGxzXzkyMTA1QHlhaG9vLmNv
bT4+IHdyb3RlOg0KDQpJbiBzb21lIHdheXMgdGhpcyBmaXRzIHJpZ2h0IGluIHRvIFBPUCBpZiBJ
IHVuZGVyc3RhbmQgaXQgcmlnaHQuICBTb21lIG9mIHRoaXMgaXMgYSB3YXkgZm9yIGEga2V5IHBh
aXIgdG8gYmUgbmVnb3RpYXRlZCB0aGF0IGNvdWxkIGJlIHVzZWQgZm9yIGFuIE9BdXRoIFBPUCB0
b2tlbiwgYW5kIHRoYXQgd291bGQgYmUgdmVyeSB1c2VmdWwuDQoNCk9uIE1vbmRheSwgSmFudWFy
eSAyNiwgMjAxNSA5OjQzIEFNLCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0
bzp2ZTdqdGJAdmU3anRiLmNvbT4+IHdyb3RlOg0KDQpJIGRvbid0IHRoaW5rIHRoZSBPQXV0aCB3
b3JrIGlzIGR1cGxpY2F0aXZlLCBtb3N0bHkgYmVjYXVzZSBJIGRvbid0IHRoaW5rIHRoYXQgVG9r
ZW4gYmluZGluZyBhZGRzIG11Y2ggdG8gbmF0aXZlL3NlcnZlciBhcHBsaWNhdGlvbnMgdGhhdCB3
ZSBkb24ndCBhbHJlYWR5IGhhdmUgd2l0aCBtdXR1YWwgVExTIChwZXJoYXBzIHNvbWUgc2xpZ2h0
bHkgbmljZXIgd2F5cyB0byBkbyB0aGUgc2FtZSB0aGluZykNCg0KVG9rZW4gYmluZGluZyB3aWxs
IGJlIHVzZWZ1bCBmb3IgT0F1dGggY2xpZW50cyB0aGF0IGFyZSBpbiB0aGUgYnJvd3NlciBhbmQg
aW4gc2VjdXJpbmcgdGhlIGF1dGhvcml6YXRpb24gcmVxdWVzdC9yZXNwb25zZSBmbG93IHZpYSB0
aGUgYnJvd3Nlci4NCg0KSSBkb24ndCB0aGluayB0aGF0IFRva2VuIGJpbmRpbmcgZG9pbmcgZW5k
IHRvIGVuZCBtZXNzYWdlIGxldmVsIGF1dGhlbnRpY2F0aW9uIG92ZXIgbm9uIFRMUyBjb25uZWN0
aW9ucyBpcyBpbiBzY29wZSBmb3IgdGhpcyBXRy4NCg0KSm9obiBCLg0KDQo+IE9uIEphbiAyNiwg
MjAxNSwgYXQgMjoyMiBQTSwgUGhpbCBIdW50IDxwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86
cGhpbC5odW50QG9yYWNsZS5jb20+PiB3cm90ZToNCj4NCj4gcmUgeW91ciBsYXN0IHBvaW50LiAg
TXkgY29uY2VybiBpcyB0aGUgT0F1dGggV0cgcHJvY2VlZGluZyB3aXRoIGEgbGFyZ2VseSBkdXBs
aWNhdGl2ZSBzb2x1dGlvbiBpbiB0aGUgYXBwIGxheWVyLg0KPg0KPiBJZiB0aGUgdW5iZWFyYWJs
ZSBkcmFmdHMgY2FuIGFkZHJlc3MgdGhlIFRMUyBub3QgYmVpbmcgZW5kLXRvLWVuZCAoZS5nLiBl
bmRpbmcgYXQgYSBsb2FkLWJhbGFuY2VyIHNjZW5hcmlvKSwgdGhlbiBJ4oCZbSBub3Qgc3VyZSB0
aGUgT0F1dGggd29yayB3b3VsZCBiZSBuZWVkZWQgaW4gaXRzIGN1cnJlbnQgc2NvcGUuDQo+DQo+
IEkgYW0gY29uY2VybmVkIGFib3V0IGtlZXBpbmcgdGhlc2Ugc2VwYXJhdGUgV0dzIGNvb3JkaW5h
dGVkIHRvIGF2b2lkIG92ZXJsYXAgYW5kL29yIHBlcmNlaXZlZC9hY3R1YWwgY29tcGxleGl0eSBp
biBhbnkgcmVzdWx0aW5nIHNvbHV0aW9uLg0KPg0KPiBQaGlsDQo+DQo+IEBpbmRlcGVuZGVudGlk
DQo+IHd3dy5pbmRlcGVuZGVudGlkLmNvbTxodHRwOi8vd3d3LmluZGVwZW5kZW50aWQuY29tPg0K
PiBwaGlsLmh1bnRAb3JhY2xlLmNvbTxtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20+DQo+DQo+
PiBPbiBKYW4gMjYsIDIwMTUsIGF0IDk6MDQgQU0sIEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0
Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQo+Pg0KPj4gTGFzdCB3ZWVr
IEkgZGlkIGEgYmxvZyBwb3N0IG9uIGhvdyB0b2tlbiBiaW5kaW5nIGZpdHMgd2l0aCBhIG51bWJl
ciBvZiB0aGUgb3RoZXIgcmVsYXRlZCBzcGVjcy4NCj4+IGh0dHA6Ly93d3cudGhyZWFkLXNhZmUu
Y29tLzIwMTUvMDEvcHJvb2Ytb2YtcG9zc2Vzc2lvbi1wdXR0aW5nLXBpZWNlcy5odG1sDQo+Pg0K
Pj4gQmFzZWQgb24gZmVlZGJhY2sgZnJvbSBvbmUgb2YgdGhlIHRva2VuIGJpbmRpbmcgYXV0aG9y
cywgSSBkaWRuJ3QgYnV0Y2hlciBpdCB0b28gbXVjaC4NCj4+DQo+PiBJIHRoaW5rIHRoZSB1c2Ug
b2YgdGhlIGtleSBlc3RhYmxpc2hlZCBieSB0b2tlbiBiaW5kaW5nIGlzIGJlc3QgbGVmdCB0byB0
aGUgcHJvdG9jb2xzIHRoYXQgd2FudCB0byB1c2UgaXQuDQo+Pg0KPj4gVHJ5aW5nIHRvIGNvdmVy
IHRoZSBhcHBsaWNhdGlvbiBsYXllciBpcyB0b28gYnJvYWQgYSBzY29wZSBmb3IgdGhpcyBXRy4N
Cj4+DQo+PiBKb2huIEIuDQo+Pg0KPj4+IE9uIEphbiAyNiwgMjAxNSwgYXQgMTo1MyBQTSwgU3Rl
cGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPG1haWx0bzpzdGVwaGVuLmZh
cnJlbGxAY3MudGNkLmllPj4gd3JvdGU6DQo+Pj4NCj4+Pg0KPj4+IEhpIEJpbGwsDQo+Pj4NCj4+
PiBPaywgc28gbm93IEkgZ2V0IHRoZSBhZGRpdGlvbiB5b3UncmUgcmVxdWVzdGluZy4NCj4+Pg0K
Pj4+IE9uIDI1LzAxLzE1IDAyOjE1LCBCaWxsIE1pbGxzIHdyb3RlOg0KPj4+PiBGcm9tIG15ICJl
bGV2YXRvciBwaXRjaCIgcXVlc3Rpb24gaW4gdGhlIG90aGVyIHRocmVhZCwgIkNsaWVudHMNCj4+
Pj4gKGJyb3dzZXJzKSBiZWluZyBhYmxlIHRvIHRpZSBjcmVkZW50aWFscyB0byBsb2NhbGx5IGdl
bmVyYXRlZCBhbmQNCj4+Pj4gbWFuYWdlZCBrZXlzIGFuZCBhc3NlcnQgdGhhdCBrZXkgdG8gdGhl
IGF1dGggc2VydmljZS4iLiAgIw0KPj4+DQo+Pj4gSSBub3RlIHRoYXQgdGhhdCB0ZXh0IGRvZXMg
bm90IG9jY3VyIGluIHRoZSBjdXJyZW50IGRyYWZ0LiBbMV0NCj4+PiBCdXQgSSBhbHNvIGtub3cg
d2hhdCB5b3UgbWVhbiBzbyBtb3Zpbmcgb24uLi4NCj4+Pg0KPj4+PiBUbyBleHRlbmQgdGhhdCBJ
IHRoaW5rIGl0IHNob3VsZCBiZSBzb21ldGhpbmcgbGlrZToNCj4+Pg0KPj4+PiAiQ2xpZW50cyAo
YnJvd3NlcnMpIGJlaW5nIGFibGUgdG8gdGllIGNyZWRlbnRpYWxzIHRvIGxvY2FsbHkNCj4+Pj4g
Z2VuZXJhdGVkIGFuZCBtYW5hZ2VkIGtleXMgYW5kIGFzc2VydCB0aGF0IGtleSB0byB0aGUgYXV0
aCBzZXJ2aWNlLg0KPj4+PiBUaG9zZSBrZXlzIGFyZSB1c2VkIGZvciBzaWduaW5nIHRyYW5zYWN0
aW9uIHdoZW4gYWNjZXNzaW5nIGENCj4+Pj4gcHJvdGVjdGVkIHJlc291cmNlIHZpYSBUTFMuIi4N
Cj4+Pg0KPj4+IEFyZSB5b3UgYXNraW5nIHRoYXQgdGhpcyB3b3JrIGJlIGV4dGVuZGVkIHNvIGFz
IHRvIGRlZmluZQ0KPj4+IGEgZ2VuZXJhbCBtZXRob2QgZm9yIHByb2R1Y2luZyBkaWdpdGFsIHNp
Z25hdHVyZXMgb24gYXBwbGljYXRpb24NCj4+PiBsYXllciBvYmplY3RzIHdpdGggdGhlIHByaXZh
dGUga2V5IHRoYXQgaXMgbmVlZGVkIGZvciBtb3ZpbmcNCj4+PiBhd2F5IGZyb20gYmVhcmVyIHRv
a2Vucz8gKEFzc3VtaW5nIGEgZGlnaXRhbCBzaWduYXR1cmUgYmFzZWQNCj4+PiB3YXkgb2YgZG9p
bmcgYmV0dGVyIHRoYW4gYmVhcmVyIHRva2Vucywgd2hpY2ggaXMgYSByZWFzb25hYmxlDQo+Pj4g
YXNzdW1wdGlvbi4pDQo+Pj4NCj4+PiBJZiBzbywgdGhhdCBzZWVtcyBsaWtlIGEgbWFqb3IgZXh0
ZW5zaW9uIG9mIHNjb3BlIGFuZCBJJ2QgYmUNCj4+PiBpbnRlcmVzdGVkIGluIHdoZXRoZXIgb3Ig
bm90IGZvbGtzIHN1cHBvcnQgdGhhdCBpZGVhLiBBbmQgSSdkDQo+Pj4gYmUgb3Bwb3NlZCBteXNl
bGYgRldJVyAtIHRvbyBtYW55IHBpdGZhbGxzLiBBIGdlbmVyYWwgdGhpbmcNCj4+PiBsaWtlIHRo
YXQgbWlnaHQgYmUgYSBnb29kIGZvbGxvdyBvbiBidXQgaW4gYSBzZXBhcmF0ZSBXRyBJJ2QNCj4+
PiBhcmd1ZS4NCj4+Pg0KPj4+IElmIG5vdCwgYW5kIHlvdSBtZWFuIHNvbWV0aGluZyBsZXNzIGJy
b2FkLCB0aGVuIEkgdGhpbmsgaXQnZA0KPj4+IGJlIGJldHRlciBpZiB5b3UgY291bGQgdHJ5IGFn
YWluIGFuZCBwbGVhc2UgcHJvdmlkZSBhIHNwZWNpZmljDQo+Pj4gY2hhcnRlciBsYW5ndWFnZSBz
dWdnZXN0aW9uIHRoYXQgb25seSBjb3ZlcnMgdGhlIG5hcnJvd2VyDQo+Pj4gc2NvcGUgb2Ygd29y
ayB5b3UgbWVhbi4gQW5kIHRoZW4gd2UgY2FuIHNlZSBpZiBmb2xrcyBsaWtlDQo+Pj4gdGhlIGlk
ZWEuIEluIHRoYXQgY2FzZSwgcGxlYXNlIHVzZSBPTEQvTkVXIGZvcm0gdG8gZGVzY3JpYmUNCj4+
PiB0aGUgY2hhbmdlcyB0byBbMV0gdGhhdCB5b3UgcHJvcG9zZS4NCj4+Pg0KPj4+IFRoYW5rcywN
Cj4+PiBTLg0KPj4+DQo+Pj4gWzFdDQo+Pj4gaHR0cHM6Ly9naXRodWIuY29tL1Rva2VuQmluZGlu
Zy9XRy1DaGFydGVyL2Jsb2IvbWFzdGVyL1Rva2VuQmluZGluZy1XRy1DaGFydGVyLURyYWZ0LnR4
dA0KPj4+DQo+Pj4NCj4+PiBUaGFua3MsDQo+Pj4gUy4NCj4+Pg0KPj4+DQo+Pj4+DQo+Pj4+IE9u
IFNhdHVyZGF5LCBKYW51YXJ5IDI0LCAyMDE1IDU6NDggUE0sIFN0ZXBoZW4gRmFycmVsbA0KPj4+
PiA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZTxtYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRj
ZC5pZT4+IHdyb3RlOg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBIaSBCaWxsLA0KPj4+Pg0KPj4+
PiBJZiB5b3UgY2FuIHNlbmQgcHJvcG9zZWQgdGV4dCB0aGF0J2QgYmUgZ3JlYXQuIEFic2VudCB0
aGF0LCB0byBiZQ0KPj4+PiBob25lc3QsIEknbSBub3Qgc3VyZSB3aGF0IGNoYW5nZSB5b3UnZCBs
aWtlLA0KPj4+Pg0KPj4+PiBDaGVlcnMsIFMuDQo+Pj4+DQo+Pj4+IE9uIDI1LzAxLzE1IDAxOjAy
LCBCaWxsIE1pbGxzIHdyb3RlOg0KPj4+Pj4gSSB0aGluayB0aGUgY3VycmVudCB0ZXh0IG9mIHRo
ZSBjaGFydGVyIGlzIG5vdCBkZXNjcmlwdGl2ZSBvZiB3aGF0DQo+Pj4+PiB0aGlzIFdHIGlzIHJl
YWxseSB0cnlpbmcgdG8gc29sdmUuICBJdCByZWFkcyBhcyB0aG91Z2ggdGhpcyBpcw0KPj4+Pj4g
YWJvdXQgVExTIGNoYW5uZWwgYmluZGluZyB3aGljaCBpcyB3cm9uZy4gIEknZCBsaWtlIHRvIHNl
ZSB0aGF0DQo+Pj4+PiBmaXhlZCBpbiB0aGUgbGFuZ3VhZ2Ugb2YgdGhlIGNoYXJ0ZXIgdG8gYmUg
Y2xlYXJlci4gVGhlcmUgd2FzIGENCj4+Pj4+IHRocmVhZCByZWNlbnRseSBvbiB3aGF0IHRoZSBl
bGV2YXRvciBwaXRjaCBmb3IgdGhpcyBpcywgYW5kIEkgdGhpbmsNCj4+Pj4+IGxhbmd1YWdlIHNp
bWlsYXIgdG8gdGhhdCBzaG91ZGwgYmUgaW4gdGhlIGZpcnN0IHBhcmFncmFwaC4NCj4+Pj4+DQo+
Pj4+PiBPbiBTYXR1cmRheSwgSmFudWFyeSAyNCwgMjAxNSAzOjM0IFBNLCBTdGVwaGVuIEZhcnJl
bGwNCj4+Pj4+IDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPG1haWx0bzpzdGVwaGVuLmZhcnJl
bGxAY3MudGNkLmllPj4gd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBIaXlhLA0K
Pj4+Pj4NCj4+Pj4+IEFuZHJlaSBoYXMgYXNrZWQgbWUgYWJvdXQgbmV4dCBzdGVwcyBmb3IgdGhp
cyB3b3JrLCBiYXNlZCBvbiB0aGUNCj4+Pj4+IGRyYWZ0IGNoYXJ0ZXIgdGV4dCBhdCBbMV0uDQo+
Pj4+Pg0KPj4+Pj4gSSB0aGluayB0aGF0IHRleHQgaXMgcHJldHR5IGdvb2QsIGJ1dCBiZWZvcmUg
SSBzdGFydCB0aGUgZm9ybWFsIFdHDQo+Pj4+PiBjaGFydGVyaW5nIHByb2Nlc3MgSSB3YW50ZWQg
dG8gY2hlY2sgaGVyZSB0aGF0IHRoZXJlIGFyZW4ndCBtYWpvcg0KPj4+Pj4gcHJvYmxlbXMgd2l0
aCBpdC4NCj4+Pj4+DQo+Pj4+PiBUd28gdGhpbmdzIEkgbm90ZWQgbXlzZWxmIHdlcmUgdGhhdCBp
dCdkIGJlIGdvb2QgdG8gc2VlIHNvbWUNCj4+Pj4+IHN1cHBvcnQgZnJvbSBzZXJ2ZXIgaW1wbGVt
ZW50ZXJzIHdobyBhcmUgbm90IGFsc28gYnJvd3NlciBtYWtlcnMuDQo+Pj4+PiBBbmQgc2Vjb25k
bHksIHdlIHByb2JhYmx5IG5lZWQgdG8gdGFsayB0byBXM0MgYWJvdXQgdGhpcyB0b28sIGFzDQo+
Pj4+PiBbMl0gc2VlbXMgdG8gbmVlZCBjaGFuZ2VzIHRvIFhIUiwgd2hpY2ggaXMgdGhlaXIgc3Bl
Yy4gWzNdIEJvdGggb2YNCj4+Pj4+IHRob3NlIGNvdWxkIGhvd2V2ZXIgYmUgdGFrZW4gY2FyZSBv
ZiBhcyB3ZSBnbyBmb3J3YXJkLg0KPj4+Pj4NCj4+Pj4+IEkgZGlkIHNlZSBIYW5uZXMnIGlzc3Vl
IGFib3V0IFRMUyBlbmRwb2ludCBsb2NhdGlvbiBhbmQgT0F1dGggYW5kDQo+Pj4+PiB0aG9zZSBh
cmUgaXNzdWVzIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQgYnV0IHRoYXQgSSB0aGluayBzaG91
bGQNCj4+Pj4+IGJlIGRvbmUgaW4gYSBXRy4NCj4+Pj4+DQo+Pj4+PiBTbyBjYW4gZm9sa3Mgd2hv
IGhhdmUgbmV3IGFyZ3VtZW50IGFzIHRvIHdoeSB0aGlzIHdvcmsgaXMgd3JvbmcsDQo+Pj4+PiBv
ciBkZWZpbml0ZWx5IG5lZWRzIGEgQm9GIG9yIHdpdGggb3RoZXIgbmV3IHN1YnN0YW50aXZlIGNv
bW1lbnRzDQo+Pj4+PiBwbGVhc2UgcG9zdCB0aG9zZSBpbiB0aGUgbmV4dCBmZXcgZGF5cy4gT3Ig
aWYgeW91IHByZXZpb3VzbHkgcG9zdGVkDQo+Pj4+PiBhIHN1YnN0YW50aXZlIGNvbW1lbnQgdGhh
dCB3YXMgbm90IGFkZHJlc3NlZCAobm90aW5nIHRoYXQgYWRkcmVzc2VkDQo+Pj4+PiAhPSBhY2Nl
cHRlZCkgcGxlYXNlIHBvc3QgYSBsaW5rIHRvIHRoYXQgdGhyZWFkLg0KPj4+Pj4NCj4+Pj4+IEkn
bGwgbG9vayBhdCB3aGF0IGNvbWVzIHVwIGFuZCBpZiB0aGVyZSBpcyBub3RoaW5nIG5ldyBJJ2xs
DQo+Pj4+PiBwcm9iYWJseSBzdGFydCB0aGUgV0cgY2hhcnRlcmluZyBwcm9jZXNzIGFyb3VuZCBt
aWQtd2Vlay4gKFRvIGJlDQo+Pj4+PiBjbGVhcjogYXQgcHJlc2VudCBJIGRvbid0IHRoaW5rIHRo
aXMgb25lIG5lZWRzIGEgQm9GIGluIE1hcmNoLCBidXQNCj4+Pj4+IGNvdWxkIGJlIGEgY2hhcnRl
cmVkIFdHIGJlZm9yZSB0aGVuLikNCj4+Pj4+DQo+Pj4+PiBDaGVlcnMsIFMuDQo+Pj4+Pg0KPj4+
Pj4gUFM6IEFzIGEgcHJvY2VzcyB0aGluZywgaWYgd2UncmUgbW92aW5nIGFoZWFkIGhlcmUsIHRo
aXMgd2lsbA0KPj4+Pj4gYXBwZWFyIGFzIGEgcGxhY2UtaG9sZGVyIGluIHRoZSBCb0YgbGlzdCBm
b3IgTWFyY2ggc28gd2UgY2FuDQo+Pj4+PiBzY2hlZHVsZSBhIHNlc3Npb24gZm9yIHRoZSBXRywg
aWYgdGhhdCBpcyBmb3JtZWQsIG9yIGVsc2UgdXNlIHRoYXQNCj4+Pj4+IHNlc3Npb24gZm9yIGEg
Qm9GIGlmIG9uZSB0dXJucyBvdXQgdG8gYmUgbmVlZGVkLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBb
MV0NCj4+Pj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9Ub2tlbkJpbmRpbmcvV0ctQ2hhcnRlci9ibG9i
L21hc3Rlci9Ub2tlbkJpbmRpbmctV0ctQ2hhcnRlci1EcmFmdC50eHQNCj4+Pj4+DQo+Pj4+Pg0K
Pj4+Pg0KPj4+Pj4NCj4+PiBbMl0gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJh
bGZhbnotaHR0cHMtdG9rZW4tYmluZGluZw0KPj4+Pj4gWzNdIGh0dHA6Ly93d3cudzMub3JnL1RS
L1hNTEh0dHBSZXF1ZXN0Lw0KPj4+Pj4NCj4+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fIFVuYmVhcmFibGUgbWFpbGluZw0KPj4+Pj4gbGlzdCBVbmJl
YXJhYmxlQGlldGYub3JnPG1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnPg0KPj4+Pj4gaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQo+Pj4+Pg0KPj4+Pj4N
Cj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXyBVbmJlYXJhYmxlIG1haWxpbmcNCj4+Pj4+IGxpc3Qg
VW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZz4NCj4+Pj4+IGh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZQ0KPj4+Pj4NCj4+
Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18g
VW5iZWFyYWJsZSBtYWlsaW5nDQo+Pj4+IGxpc3QgVW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86
VW5iZWFyYWJsZUBpZXRmLm9yZz4NCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby91bmJlYXJhYmxlDQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+DQo+Pj4NCj4+PiBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IFVuYmVhcmFi
bGUgbWFpbGluZyBsaXN0DQo+Pj4gVW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5iZWFyYWJs
ZUBpZXRmLm9yZz4NCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Vu
YmVhcmFibGUNCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPj4gVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QNCj4+IFVuYmVhcmFibGVAaWV0Zi5v
cmc8bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCj4NCg0KDQo=

--_000_BN3PR0301MB123417B909372A0D19FA1E80A6350BN3PR0301MB1234_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs
LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu
LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh
dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SeKAmW0gbm90IHNlZWluZyBvdmVybGFwIGhl
cmUgd2l0aCBPQVVUSCwgSk9TRSBhbmQgdGhlIHByb3Bvc2VkIG5ldyBXRywgSSBzZWUgYmVuZWZp
dHMgdG8gT0FVVEggdG8gYWxsb3cgdXNhZ2Ugb2YgT0FVVEggYW5kIEpPU0UgZGVmaW5lZCB0b2tl
bnMgYW5kIGtleXMsIEkgYWxzbw0KIHNlZSBzb21lIHBvdGVudGlhbCBwcml2YWN5IGVuaGFuY2Vt
ZW50cyB0aGF0IHRoZSBuZXcgV0cgcHJvcG9zYWwgY2FuIGFkZCBhbG9uZyB3aXRoIHNvbWUgZmVk
ZXJhdGlvbiBpbXByb3ZlbWVudHMgdGhhdCB3b3VsZCBoZWxwIG5hdGl2ZS9zZXJ2ZXIuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRD
b21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD
YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48
L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w
OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWYiPiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3Jn
XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Kb2huIEJyYWRsZXk8YnI+DQo8Yj5TZW50OjwvYj4gTW9u
ZGF5LCBKYW51YXJ5IDI2LCAyMDE1IDEwOjAzIEFNPGJyPg0KPGI+VG86PC9iPiBCaWxsIE1pbGxz
PGJyPg0KPGI+Q2M6PC9iPiB1bmJlYXJhYmxlQGlldGYub3JnOyBTdGVwaGVuIEZhcnJlbGw7IFBo
aWwgSHVudDxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIG1vdmluZyBhaGVh
ZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsg
aXQgd2lsbCBoZWxwIHRvIG1ha2UgT0F1dGggYnJvd3NlciBiYXNlZCBmbG93cyBQb1AgZW5hYmxl
ZC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIg
dGhlIGZsb3dzIGZvciBzZXJ2ZXIvbmF0aXZlIHdpbGwgcHJvYmFibHkgYmVuZWZpdCBsZXNzLiAm
bmJzcDtJbiBhIG5hdGl2ZSBhcHAgeW91IGNhbiBub3cgdXNlIGEgc2luZ2xlIGNsaWVudCBrZXkg
YWNyb3NzIG11bHRpcGxlIHNlc3Npb25zLiAmbmJzcDtVc2luZyB0b2tlbiBiaW5kaW5nIGxpa2Vs
eSB3aWxsIHByZXZlbnQgdGhlIHNhbWUga2V5IGZyb20gYmVpbmcgdXNlZCBib3RoIHdpdGggdGhl
IFJTIGFuZCB0b2tlbg0KIGVuZHBvaW50IGZvciBwcml2YWN5IHJlYXNvbnMuICZuYnNwOyBCeSBk
ZXNpZ24gdGhlIHByaXZhdGUga2V5IHdvdWxkIGFsc28gbm90IGJlIGF2YWlsYWJsZSB0byB0aGUg
YXBwbGljYXRpb24gZm9yIHNpZ25pbmcgbWVzc2FnZXMgKHBlcmhhcHMgYSB3ZWIgY3J5cHRvIEFQ
SSBtaWdodCBiZSBkZXZlbG9wZWQgaW4gdGhlIGJyb3dzZXIpLjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3UgaGF2ZSBhIOKAnHNtYXJ0
4oCdIGNsaWVudCB0aGF0IGNhbiBtYW5hZ2Uga2V5cy9jZXJ0cyB0aGVuIHRva2VuIGJpbmRpbmcg
aXMgcHJvYmFibHkgbm90IGEgaHVnZSBhZHZhbmNlbWVudC4gJm5ic3A7Jm5ic3A7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBodWdlIGZv
ciBicm93c2VycyB3aGVyZSB0aGF0IGFiaWxpdHkgdG8gbWFuYWdlIGtleXMgZG9lc27igJl0IGN1
cnJlbnRseSBleGlzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SnVzdCBteSBvcGluaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K
PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gSmFuIDI2LCAyMDE1LCBhdCAyOjQ3IFBN
LCBCaWxsIE1pbGxzICZsdDs8YSBocmVmPSJtYWlsdG86d21pbGxzXzkyMTA1QHlhaG9vLmNvbSI+
d21pbGxzXzkyMTA1QHlhaG9vLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu
ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtI
ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SW4gc29tZSB3YXlzIHRoaXMgZml0cyByaWdodCBp
biB0byBQT1AgaWYgSSB1bmRlcnN0YW5kIGl0IHJpZ2h0LiAmbmJzcDtTb21lIG9mIHRoaXMgaXMg
YSB3YXkgZm9yIGEga2V5IHBhaXIgdG8gYmUgbmVnb3RpYXRlZCB0aGF0IGNvdWxkIGJlIHVzZWQg
Zm9yIGFuDQogT0F1dGggUE9QIHRva2VuLCBhbmQgdGhhdCB3b3VsZCBiZSB2ZXJ5IHVzZWZ1bC48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6
d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy
aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIE1vbmRheSwgSmFudWFyeSAyNiwgMjAxNSA5OjQzIEFN
LCBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSI+dmU3
anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy
LjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs
dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g
c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIGRv
bid0IHRoaW5rIHRoZSBPQXV0aCB3b3JrIGlzIGR1cGxpY2F0aXZlLCBtb3N0bHkgYmVjYXVzZSBJ
IGRvbid0IHRoaW5rIHRoYXQgVG9rZW4gYmluZGluZyBhZGRzIG11Y2ggdG8gbmF0aXZlL3NlcnZl
ciBhcHBsaWNhdGlvbnMgdGhhdCB3ZSBkb24ndCBhbHJlYWR5IGhhdmUgd2l0aA0KIG11dHVhbCBU
TFMgKHBlcmhhcHMgc29tZSBzbGlnaHRseSBuaWNlciB3YXlzIHRvIGRvIHRoZSBzYW1lIHRoaW5n
KTxicj4NCjxicj4NClRva2VuIGJpbmRpbmcgd2lsbCBiZSB1c2VmdWwgZm9yIE9BdXRoIGNsaWVu
dHMgdGhhdCBhcmUgaW4gdGhlIGJyb3dzZXIgYW5kIGluIHNlY3VyaW5nIHRoZSBhdXRob3JpemF0
aW9uIHJlcXVlc3QvcmVzcG9uc2UgZmxvdyB2aWEgdGhlIGJyb3dzZXIuPGJyPg0KPGJyPg0KSSBk
b24ndCB0aGluayB0aGF0IFRva2VuIGJpbmRpbmcgZG9pbmcgZW5kIHRvIGVuZCBtZXNzYWdlIGxl
dmVsIGF1dGhlbnRpY2F0aW9uIG92ZXIgbm9uIFRMUyBjb25uZWN0aW9ucyBpcyBpbiBzY29wZSBm
b3IgdGhpcyBXRy48YnI+DQo8YnI+DQpKb2huIEIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp
diBpZD0ieXF0ZmQzMTQzOSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu
ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmIj48YnI+DQomZ3Q7IE9uIEphbiAyNiwgMjAxNSwgYXQgMjoyMiBQTSwgUGhpbCBI
dW50ICZsdDs8YSBocmVmPSJtYWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBv
cmFjbGUuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IHJlIHlvdXIgbGFz
dCBwb2ludC4mbmJzcDsgTXkgY29uY2VybiBpcyB0aGUgT0F1dGggV0cgcHJvY2VlZGluZyB3aXRo
IGEgbGFyZ2VseSBkdXBsaWNhdGl2ZSBzb2x1dGlvbiBpbiB0aGUgYXBwIGxheWVyLjxicj4NCiZn
dDsgPGJyPg0KJmd0OyBJZiB0aGUgdW5iZWFyYWJsZSBkcmFmdHMgY2FuIGFkZHJlc3MgdGhlIFRM
UyBub3QgYmVpbmcgZW5kLXRvLWVuZCAoZS5nLiBlbmRpbmcgYXQgYSBsb2FkLWJhbGFuY2VyIHNj
ZW5hcmlvKSwgdGhlbiBJ4oCZbSBub3Qgc3VyZSB0aGUgT0F1dGggd29yayB3b3VsZCBiZSBuZWVk
ZWQgaW4gaXRzIGN1cnJlbnQgc2NvcGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgYW0gY29uY2Vy
bmVkIGFib3V0IGtlZXBpbmcgdGhlc2Ugc2VwYXJhdGUgV0dzIGNvb3JkaW5hdGVkIHRvIGF2b2lk
IG92ZXJsYXAgYW5kL29yIHBlcmNlaXZlZC9hY3R1YWwgY29tcGxleGl0eSBpbiBhbnkgcmVzdWx0
aW5nIHNvbHV0aW9uLjxicj4NCiZndDsgPGJyPg0KJmd0OyBQaGlsPGJyPg0KJmd0OyA8YnI+DQom
Z3Q7IEBpbmRlcGVuZGVudGlkPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmluZGVwZW5k
ZW50aWQuY29tIj53d3cuaW5kZXBlbmRlbnRpZC5jb208L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJt
YWlsdG86cGhpbC5odW50QG9yYWNsZS5jb20iPnBoaWwuaHVudEBvcmFjbGUuY29tPC9hPjxicj4N
CiZndDsgPGJyPg0KJmd0OyZndDsgT24gSmFuIDI2LCAyMDE1LCBhdCA5OjA0IEFNLCBKb2huIEJy
YWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSI+dmU3anRiQHZlN2p0
Yi5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBMYXN0IHdl
ZWsgSSBkaWQgYSBibG9nIHBvc3Qgb24gaG93IHRva2VuIGJpbmRpbmcgZml0cyB3aXRoIGEgbnVt
YmVyIG9mIHRoZSBvdGhlciByZWxhdGVkIHNwZWNzLjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0
dHA6Ly93d3cudGhyZWFkLXNhZmUuY29tLzIwMTUvMDEvcHJvb2Ytb2YtcG9zc2Vzc2lvbi1wdXR0
aW5nLXBpZWNlcy5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwOi8vd3d3LnRocmVhZC1zYWZl
LmNvbS8yMDE1LzAxL3Byb29mLW9mLXBvc3Nlc3Npb24tcHV0dGluZy1waWVjZXMuaHRtbDwvYT48
YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBCYXNlZCBvbiBmZWVkYmFjayBmcm9tIG9uZSBv
ZiB0aGUgdG9rZW4gYmluZGluZyBhdXRob3JzLCBJIGRpZG4ndCBidXRjaGVyIGl0IHRvbyBtdWNo
Ljxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEkgdGhpbmsgdGhlIHVzZSBvZiB0aGUga2V5
IGVzdGFibGlzaGVkIGJ5IHRva2VuIGJpbmRpbmcgaXMgYmVzdCBsZWZ0IHRvIHRoZSBwcm90b2Nv
bHMgdGhhdCB3YW50IHRvIHVzZSBpdC48YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBUcnlp
bmcgdG8gY292ZXIgdGhlIGFwcGxpY2F0aW9uIGxheWVyIGlzIHRvbyBicm9hZCBhIHNjb3BlIGZv
ciB0aGlzIFdHLjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IEpvaG4gQi48YnI+DQomZ3Q7
Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgT24gSmFuIDI2LCAyMDE1LCBhdCAxOjUzIFBNLCBTdGVw
aGVuIEZhcnJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmll
Ij5zdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsm
Z3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgSGkgQmlsbCw8YnI+DQom
Z3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IE9rLCBzbyBub3cgSSBnZXQgdGhlIGFkZGl0
aW9uIHlvdSdyZSByZXF1ZXN0aW5nLjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZn
dDsgT24gMjUvMDEvMTUgMDI6MTUsIEJpbGwgTWlsbHMgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0OyBGcm9tIG15ICZxdW90O2VsZXZhdG9yIHBpdGNoJnF1b3Q7IHF1ZXN0aW9uIGluIHRoZSBv
dGhlciB0aHJlYWQsICZxdW90O0NsaWVudHM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IChicm93c2Vy
cykgYmVpbmcgYWJsZSB0byB0aWUgY3JlZGVudGlhbHMgdG8gbG9jYWxseSBnZW5lcmF0ZWQgYW5k
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBtYW5hZ2VkIGtleXMgYW5kIGFzc2VydCB0aGF0IGtleSB0
byB0aGUgYXV0aCBzZXJ2aWNlLiZxdW90Oy4mbmJzcDsgIzxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+
DQomZ3Q7Jmd0OyZndDsgSSBub3RlIHRoYXQgdGhhdCB0ZXh0IGRvZXMgbm90IG9jY3VyIGluIHRo
ZSBjdXJyZW50IGRyYWZ0LiBbMV08YnI+DQomZ3Q7Jmd0OyZndDsgQnV0IEkgYWxzbyBrbm93IHdo
YXQgeW91IG1lYW4gc28gbW92aW5nIG9uLi4uPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsm
Z3Q7Jmd0OyZndDsgVG8gZXh0ZW5kIHRoYXQgSSB0aGluayBpdCBzaG91bGQgYmUgc29tZXRoaW5n
IGxpa2U6PGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJnF1b3Q7Q2xp
ZW50cyAoYnJvd3NlcnMpIGJlaW5nIGFibGUgdG8gdGllIGNyZWRlbnRpYWxzIHRvIGxvY2FsbHk8
YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGdlbmVyYXRlZCBhbmQgbWFuYWdlZCBrZXlzIGFuZCBhc3Nl
cnQgdGhhdCBrZXkgdG8gdGhlIGF1dGggc2VydmljZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRo
b3NlIGtleXMgYXJlIHVzZWQgZm9yIHNpZ25pbmcgdHJhbnNhY3Rpb24gd2hlbiBhY2Nlc3Npbmcg
YTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgcHJvdGVjdGVkIHJlc291cmNlIHZpYSBUTFMuJnF1b3Q7
Ljxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgQXJlIHlvdSBhc2tpbmcgdGhh
dCB0aGlzIHdvcmsgYmUgZXh0ZW5kZWQgc28gYXMgdG8gZGVmaW5lPGJyPg0KJmd0OyZndDsmZ3Q7
IGEgZ2VuZXJhbCBtZXRob2QgZm9yIHByb2R1Y2luZyBkaWdpdGFsIHNpZ25hdHVyZXMgb24gYXBw
bGljYXRpb248YnI+DQomZ3Q7Jmd0OyZndDsgbGF5ZXIgb2JqZWN0cyB3aXRoIHRoZSBwcml2YXRl
IGtleSB0aGF0IGlzIG5lZWRlZCBmb3IgbW92aW5nPGJyPg0KJmd0OyZndDsmZ3Q7IGF3YXkgZnJv
bSBiZWFyZXIgdG9rZW5zPyAoQXNzdW1pbmcgYSBkaWdpdGFsIHNpZ25hdHVyZSBiYXNlZDxicj4N
CiZndDsmZ3Q7Jmd0OyB3YXkgb2YgZG9pbmcgYmV0dGVyIHRoYW4gYmVhcmVyIHRva2Vucywgd2hp
Y2ggaXMgYSByZWFzb25hYmxlPGJyPg0KJmd0OyZndDsmZ3Q7IGFzc3VtcHRpb24uKTxicj4NCiZn
dDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgSWYgc28sIHRoYXQgc2VlbXMgbGlrZSBhIG1h
am9yIGV4dGVuc2lvbiBvZiBzY29wZSBhbmQgSSdkIGJlPGJyPg0KJmd0OyZndDsmZ3Q7IGludGVy
ZXN0ZWQgaW4gd2hldGhlciBvciBub3QgZm9sa3Mgc3VwcG9ydCB0aGF0IGlkZWEuIEFuZCBJJ2Q8
YnI+DQomZ3Q7Jmd0OyZndDsgYmUgb3Bwb3NlZCBteXNlbGYgRldJVyAtIHRvbyBtYW55IHBpdGZh
bGxzLiBBIGdlbmVyYWwgdGhpbmc8YnI+DQomZ3Q7Jmd0OyZndDsgbGlrZSB0aGF0IG1pZ2h0IGJl
IGEgZ29vZCBmb2xsb3cgb24gYnV0IGluIGEgc2VwYXJhdGUgV0cgSSdkPGJyPg0KJmd0OyZndDsm
Z3Q7IGFyZ3VlLjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgSWYgbm90LCBh
bmQgeW91IG1lYW4gc29tZXRoaW5nIGxlc3MgYnJvYWQsIHRoZW4gSSB0aGluayBpdCdkPGJyPg0K
Jmd0OyZndDsmZ3Q7IGJlIGJldHRlciBpZiB5b3UgY291bGQgdHJ5IGFnYWluIGFuZCBwbGVhc2Ug
cHJvdmlkZSBhIHNwZWNpZmljPGJyPg0KJmd0OyZndDsmZ3Q7IGNoYXJ0ZXIgbGFuZ3VhZ2Ugc3Vn
Z2VzdGlvbiB0aGF0IG9ubHkgY292ZXJzIHRoZSBuYXJyb3dlcjxicj4NCiZndDsmZ3Q7Jmd0OyBz
Y29wZSBvZiB3b3JrIHlvdSBtZWFuLiBBbmQgdGhlbiB3ZSBjYW4gc2VlIGlmIGZvbGtzIGxpa2U8
YnI+DQomZ3Q7Jmd0OyZndDsgdGhlIGlkZWEuIEluIHRoYXQgY2FzZSwgcGxlYXNlIHVzZSBPTEQv
TkVXIGZvcm0gdG8gZGVzY3JpYmU8YnI+DQomZ3Q7Jmd0OyZndDsgdGhlIGNoYW5nZXMgdG8gWzFd
IHRoYXQgeW91IHByb3Bvc2UuPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBU
aGFua3MsPGJyPg0KJmd0OyZndDsmZ3Q7IFMuPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsm
Z3Q7Jmd0OyBbMV08YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29t
L1Rva2VuQmluZGluZy9XRy1DaGFydGVyL2Jsb2IvbWFzdGVyL1Rva2VuQmluZGluZy1XRy1DaGFy
dGVyLURyYWZ0LnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9naXRodWIuY29tL1Rva2Vu
QmluZGluZy9XRy1DaGFydGVyL2Jsb2IvbWFzdGVyL1Rva2VuQmluZGluZy1XRy1DaGFydGVyLURy
YWZ0LnR4dDwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZn
dDsmZ3Q7Jmd0OyBUaGFua3MsPGJyPg0KJmd0OyZndDsmZ3Q7IFMuPGJyPg0KJmd0OyZndDsmZ3Q7
IDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7
Jmd0OyZndDsgT24gU2F0dXJkYXksIEphbnVhcnkgMjQsIDIwMTUgNTo0OCBQTSwgU3RlcGhlbiBG
YXJyZWxsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXBoZW4u
ZmFycmVsbEBjcy50Y2QuaWUiPnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8L2E+Jmd0OyB3cm90
ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEhpIEJpbGwsPGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IElmIHlvdSBjYW4gc2VuZCBwcm9wb3Nl
ZCB0ZXh0IHRoYXQnZCBiZSBncmVhdC4gQWJzZW50IHRoYXQsIHRvIGJlPGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyBob25lc3QsIEknbSBub3Qgc3VyZSB3aGF0IGNoYW5nZSB5b3UnZCBsaWtlLDxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBDaGVlcnMsIFMuPGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE9uIDI1LzAxLzE1IDAxOjAy
LCBCaWxsIE1pbGxzIHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgdGhpbmsgdGhl
IGN1cnJlbnQgdGV4dCBvZiB0aGUgY2hhcnRlciBpcyBub3QgZGVzY3JpcHRpdmUgb2Ygd2hhdCA8
YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGlzIFdHIGlzIHJlYWxseSB0cnlpbmcgdG8gc29s
dmUuJm5ic3A7IEl0IHJlYWRzIGFzIHRob3VnaCB0aGlzIGlzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyZndDsgYWJvdXQgVExTIGNoYW5uZWwgYmluZGluZyB3aGljaCBpcyB3cm9uZy4mbmJzcDsgSSdk
IGxpa2UgdG8gc2VlIHRoYXQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBmaXhlZCBpbiB0aGUg
bGFuZ3VhZ2Ugb2YgdGhlIGNoYXJ0ZXIgdG8gYmUgY2xlYXJlci4gVGhlcmUgd2FzIGE8YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aHJlYWQgcmVjZW50bHkgb24gd2hhdCB0aGUgZWxldmF0b3Ig
cGl0Y2ggZm9yIHRoaXMgaXMsIGFuZCBJIHRoaW5rPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg
bGFuZ3VhZ2Ugc2ltaWxhciB0byB0aGF0IHNob3VkbCBiZSBpbiB0aGUgZmlyc3QgcGFyYWdyYXBo
Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9u
IFNhdHVyZGF5LCBKYW51YXJ5IDI0LCAyMDE1IDM6MzQgUE0sIFN0ZXBoZW4gRmFycmVsbCA8YnI+
DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXBoZW4uZmFycmVs
bEBjcy50Y2QuaWUiPnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8L2E+Jmd0OyB3cm90ZTo8YnI+
DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIaXlhLDxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFuZHJlaSBo
YXMgYXNrZWQgbWUgYWJvdXQgbmV4dCBzdGVwcyBmb3IgdGhpcyB3b3JrLCBiYXNlZCBvbiB0aGUg
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZHJhZnQgY2hhcnRlciB0ZXh0IGF0IFsxXS48YnI+
DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIHRoaW5r
IHRoYXQgdGV4dCBpcyBwcmV0dHkgZ29vZCwgYnV0IGJlZm9yZSBJIHN0YXJ0IHRoZSBmb3JtYWwg
V0cgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2hhcnRlcmluZyBwcm9jZXNzIEkgd2FudGVk
IHRvIGNoZWNrIGhlcmUgdGhhdCB0aGVyZSBhcmVuJ3QgbWFqb3IgPGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0OyZndDsgcHJvYmxlbXMgd2l0aCBpdC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+
DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUd28gdGhpbmdzIEkgbm90ZWQgbXlzZWxmIHdlcmUgdGhh
dCBpdCdkIGJlIGdvb2QgdG8gc2VlIHNvbWU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzdXBw
b3J0IGZyb20gc2VydmVyIGltcGxlbWVudGVycyB3aG8gYXJlIG5vdCBhbHNvIGJyb3dzZXIgbWFr
ZXJzLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEFuZCBzZWNvbmRseSwgd2UgcHJvYmFibHkg
bmVlZCB0byB0YWxrIHRvIFczQyBhYm91dCB0aGlzIHRvbywgYXM8YnI+DQomZ3Q7Jmd0OyZndDsm
Z3Q7Jmd0OyBbMl0gc2VlbXMgdG8gbmVlZCBjaGFuZ2VzIHRvIFhIUiwgd2hpY2ggaXMgdGhlaXIg
c3BlYy4gWzNdIEJvdGggb2Y8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aG9zZSBjb3VsZCBo
b3dldmVyIGJlIHRha2VuIGNhcmUgb2YgYXMgd2UgZ28gZm9yd2FyZC48YnI+DQomZ3Q7Jmd0OyZn
dDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGRpZCBzZWUgSGFubmVzJyBp
c3N1ZSBhYm91dCBUTFMgZW5kcG9pbnQgbG9jYXRpb24gYW5kIE9BdXRoIGFuZCA8YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyB0aG9zZSBhcmUgaXNzdWVzIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNz
ZWQgYnV0IHRoYXQgSSB0aGluayBzaG91bGQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZSBk
b25lIGluIGEgV0cuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0OyZndDsgU28gY2FuIGZvbGtzIHdobyBoYXZlIG5ldyBhcmd1bWVudCBhcyB0byB3aHkgdGhp
cyB3b3JrIGlzIHdyb25nLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9yIGRlZmluaXRlbHkg
bmVlZHMgYSBCb0Ygb3Igd2l0aCBvdGhlciBuZXcgc3Vic3RhbnRpdmUgY29tbWVudHM8YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwbGVhc2UgcG9zdCB0aG9zZSBpbiB0aGUgbmV4dCBmZXcgZGF5
cy4gT3IgaWYgeW91IHByZXZpb3VzbHkgcG9zdGVkPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg
YSBzdWJzdGFudGl2ZSBjb21tZW50IHRoYXQgd2FzIG5vdCBhZGRyZXNzZWQgKG5vdGluZyB0aGF0
IGFkZHJlc3NlZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICE9IGFjY2VwdGVkKSBwbGVhc2Ug
cG9zdCBhIGxpbmsgdG8gdGhhdCB0aHJlYWQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSdsbCBsb29rIGF0IHdoYXQgY29tZXMgdXAgYW5kIGlm
IHRoZXJlIGlzIG5vdGhpbmcgbmV3IEknbGw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBwcm9i
YWJseSBzdGFydCB0aGUgV0cgY2hhcnRlcmluZyBwcm9jZXNzIGFyb3VuZCBtaWQtd2Vlay4gKFRv
IGJlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2xlYXI6IGF0IHByZXNlbnQgSSBkb24ndCB0
aGluayB0aGlzIG9uZSBuZWVkcyBhIEJvRiBpbiBNYXJjaCwgYnV0PGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0OyZndDsgY291bGQgYmUgYSBjaGFydGVyZWQgV0cgYmVmb3JlIHRoZW4uKTxicj4NCiZndDsm
Z3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENoZWVycywgUy48YnI+
DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQUzogQXMg
YSBwcm9jZXNzIHRoaW5nLCBpZiB3ZSdyZSBtb3ZpbmcgYWhlYWQgaGVyZSwgdGhpcyB3aWxsPGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYXBwZWFyIGFzIGEgcGxhY2UtaG9sZGVyIGluIHRoZSBC
b0YgbGlzdCBmb3IgTWFyY2ggc28gd2UgY2FuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2No
ZWR1bGUgYSBzZXNzaW9uIGZvciB0aGUgV0csIGlmIHRoYXQgaXMgZm9ybWVkLCBvciBlbHNlIHVz
ZSB0aGF0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2Vzc2lvbiBmb3IgYSBCb0YgaWYgb25l
IHR1cm5zIG91dCB0byBiZSBuZWVkZWQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgWzFdIDxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9Ub2tlbkJp
bmRpbmcvV0ctQ2hhcnRlci9ibG9iL21hc3Rlci9Ub2tlbkJpbmRpbmctV0ctQ2hhcnRlci1EcmFm
dC50eHQiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZ2l0aHViLmNvbS9Ub2tlbkJpbmRpbmcv
V0ctQ2hhcnRlci9ibG9iL21hc3Rlci9Ub2tlbkJpbmRpbmctV0ctQ2hhcnRlci1EcmFmdC50eHQ8
L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQom
Z3Q7Jmd0OyZndDsgWzJdIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm
dC1iYWxmYW56LWh0dHBzLXRva2VuLWJpbmRpbmciIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iYWxmYW56LWh0dHBzLXRva2VuLWJpbmRpbmc8L2E+
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgWzNdIDxhIGhyZWY9Imh0dHA6Ly93d3cudzMub3Jn
L1RSL1hNTEh0dHBSZXF1ZXN0LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cudzMub3JnL1RS
L1hNTEh0dHBSZXF1ZXN0LzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7
Jmd0OyZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXyBVbmJlYXJhYmxlIG1haWxpbmcgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGlz
dCA8YSBocmVmPSJtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZyI+VW5iZWFyYWJsZUBpZXRmLm9y
ZzwvYT4gPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGU8L2E+PGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18g
VW5iZWFyYWJsZSBtYWlsaW5nIDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxpc3QgPGEgaHJl
Zj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmciPlVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+IDxi
cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlPC9hPjxicj4NCiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyBVbmJlYXJhYmxl
IG1haWxpbmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGxpc3QgPGEgaHJlZj0ibWFpbHRvOlVuYmVh
cmFibGVAaWV0Zi5vcmciPlVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+IDxicj4NCiZndDsmZ3Q7Jmd0
OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJl
YXJhYmxlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby91bmJlYXJhYmxlPC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgPGJy
Pg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyBVbmJlYXJhYmxlIG1h
aWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86VW5iZWFyYWJsZUBp
ZXRmLm9yZyI+VW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlIiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJh
YmxlPC9hPjxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyZndDsgVW5iZWFyYWJsZSBtYWls
aW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9y
ZyI+VW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUiIHRhcmdldD0iX2JsYW5r
Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGU8L2E+PGJy
Pg0KJmd0OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+
DQo8L2h0bWw+DQo=

--_000_BN3PR0301MB123417B909372A0D19FA1E80A6350BN3PR0301MB1234_--


From nobody Mon Jan 26 10:39:11 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D709D1A885F for ; Mon, 26 Jan 2015 10:39:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 ZBSnzJgrToWh for ; Mon, 26 Jan 2015 10:38:58 -0800 (PST)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05CEB1ACD32 for ; Mon, 26 Jan 2015 10:38:58 -0800 (PST)
Received: by mail-qg0-f49.google.com with SMTP id i50so8209597qgf.8 for ; Mon, 26 Jan 2015 10:38:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LdOM45QW3HRu3LK/4pkZ7TK0S8vF2FyjPv2uaw+6IcU=; b=Q8LHbqL1CxYDThlyjiCr/KBlxaDnNmuKLdkLgpQb+yr7AufwjcZ1kCD0RVrzJCCNuo uDuI6Vr46oNtK7M+tCHtAy2Q4NAOhleXTnmwc8g9aWLUBWh8Nh6c+mxNhus0/eFeH4VM 8h/nVpa6hzjamTAxEqSjkenVKBwVxdqhtv5xMKFTRwhWbmqWVvAjUtao2pV4HKXiqNfH q4sph2UlcU1hpsj4lIkwB2/eE76yL1njKse2mYH+yaxi5dLx/9wUAT/wFIG0JYwcs5Ai 5nWecACiqV+6xjiWisAlSfGqnCsCPPpa2xR69NQGJ5xdySlF1E3fZ0Kl7Q6yT+hRjZIp nJCw==
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:date :message-id:subject:from:to:cc:content-type; bh=LdOM45QW3HRu3LK/4pkZ7TK0S8vF2FyjPv2uaw+6IcU=; b=Wl/21xDD9FnyKDudOWI7tBTnnJ8KEM3dA1QEMtr2KNrzRu9nlzhbBaoUMsQzTEhudh R8HBeDp2rvT8KOmSRnsS+FCK004hqXhghap2dB52eit3WMmqVabRSYSwfFo2ybctQMWg tUuPFqhM3locNzN1WvpFUo51EoQj7tPCdfEOo2l6GviDmgn72zSQpDsMTMMSJWj1DAHb pS71/zstz3r//jgcFAvjRoX61OvfbwYqcfnC7FMNrDgYeIWIlMZFZWiG6S80f7nZPtO8 qJUGvw/DzAJtxXzCMbqZsvy28LV4zTjkOpNdt6JTRLj97uSfKwV+7DVweBvWMtWrWcIE vv3Q==
X-Gm-Message-State: ALoCoQkvF2y1C5hl+NbOixKp6VnthFAVjN/Css7fZXLzmz3xV0lxIBs2hiv9liSKnFo7mJwUUNdT
MIME-Version: 1.0
X-Received: by 10.140.109.164 with SMTP id l33mr7716495qgf.91.1422297536934; Mon, 26 Jan 2015 10:38:56 -0800 (PST)
Received: by 10.229.183.73 with HTTP; Mon, 26 Jan 2015 10:38:56 -0800 (PST)
In-Reply-To: <8449BE8E-6416-4C35-80ED-8BC7CBF7ADB0@oracle.com>
References:  <339123303.662625.1422294474487.JavaMail.yahoo@mail.yahoo.com> <4B97C960-06B5-49BC-93E9-729EF218430A@ve7jtb.com> <8449BE8E-6416-4C35-80ED-8BC7CBF7ADB0@oracle.com>
Date: Mon, 26 Jan 2015 10:38:56 -0800
Message-ID: 
From: Vinod Anupam 
To: Phil Hunt 
Content-Type: multipart/alternative; boundary=001a113a304e745e57050d927344
Archived-At: 
Cc: John Bradley , "unbearable@ietf.org" , William Mills , Stephen Farrell 
Subject: Re: [Unbearable] moving ahead
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 18:39:02 -0000

--001a113a304e745e57050d927344
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

At a very high level, the current drafts propose:

(1) how a client can agree with a server about using token binding over a
(resumable) TLS connection
(1a) the recommendation that clients should use different "keys" for
different eTLD+1
(2) how a browser and server can exchange "bound" information over HTTP
(3) how, over HTTP, an RP can ask a browser to get, from an IdP,
information that is bound for use with the RP

Is the duplication that you are referring to in (1) ?


On Mon, Jan 26, 2015 at 10:24 AM, Phil Hunt  wrote:

> I agree with part of what you are saying.
>
> The browser flows are new.  The rest is duplicative. It is the overlap
> with the rest of the POP work that is problematic.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
> On Jan 26, 2015, at 10:02 AM, John Bradley  wrote:
>
> I think it will help to make OAuth browser based flows PoP enabled.
>
> However the flows for server/native will probably benefit less.  In a
> native app you can now use a single client key across multiple sessions.
> Using token binding likely will prevent the same key from being used both
> with the RS and token endpoint for privacy reasons.   By design the priva=
te
> key would also not be available to the application for signing messages
> (perhaps a web crypto API might be developed in the browser).
>
> If you have a =E2=80=9Csmart=E2=80=9D client that can manage keys/certs t=
hen token binding
> is probably not a huge advancement.
> It is huge for browsers where that ability to manage keys doesn=E2=80=99t
> currently exist.
>
> Just my opinion.
> John B.
>
> On Jan 26, 2015, at 2:47 PM, Bill Mills  wrote:
>
> In some ways this fits right in to POP if I understand it right.  Some of
> this is a way for a key pair to be negotiated that could be used for an
> OAuth POP token, and that would be very useful.
>
>
>   On Monday, January 26, 2015 9:43 AM, John Bradley 
> wrote:
>
>
> I don't think the OAuth work is duplicative, mostly because I don't think
> that Token binding adds much to native/server applications that we don't
> already have with mutual TLS (perhaps some slightly nicer ways to do the
> same thing)
>
> Token binding will be useful for OAuth clients that are in the browser an=
d
> in securing the authorization request/response flow via the browser.
>
> I don't think that Token binding doing end to end message level
> authentication over non TLS connections is in scope for this WG.
>
> John B.
>
> > On Jan 26, 2015, at 2:22 PM, Phil Hunt  wrote:
> >
> > re your last point.  My concern is the OAuth WG proceeding with a
> largely duplicative solution in the app layer.
> >
> > If the unbearable drafts can address the TLS not being end-to-end (e.g.
> ending at a load-balancer scenario), then I=E2=80=99m not sure the OAuth =
work would
> be needed in its current scope.
> >
> > I am concerned about keeping these separate WGs coordinated to avoid
> overlap and/or perceived/actual complexity in any resulting solution.
> >
> > Phil
> >
> > @independentid
> > www.independentid.com
> > phil.hunt@oracle.com
> >
> >> On Jan 26, 2015, at 9:04 AM, John Bradley  wrote:
> >>
> >> Last week I did a blog post on how token binding fits with a number of
> the other related specs.
> >>
> http://www.thread-safe.com/2015/01/proof-of-possession-putting-pieces.htm=
l
> >>
> >> Based on feedback from one of the token binding authors, I didn't
> butcher it too much.
> >>
> >> I think the use of the key established by token binding is best left t=
o
> the protocols that want to use it.
> >>
> >> Trying to cover the application layer is too broad a scope for this WG=
.
> >>
> >> John B.
> >>
> >>> On Jan 26, 2015, at 1:53 PM, Stephen Farrell <
> stephen.farrell@cs.tcd.ie> wrote:
> >>>
> >>>
> >>> Hi Bill,
> >>>
> >>> Ok, so now I get the addition you're requesting.
> >>>
> >>> On 25/01/15 02:15, Bill Mills wrote:
> >>>> From my "elevator pitch" question in the other thread, "Clients
> >>>> (browsers) being able to tie credentials to locally generated and
> >>>> managed keys and assert that key to the auth service.".  #
> >>>
> >>> I note that that text does not occur in the current draft. [1]
> >>> But I also know what you mean so moving on...
> >>>
> >>>> To extend that I think it should be something like:
> >>>
> >>>> "Clients (browsers) being able to tie credentials to locally
> >>>> generated and managed keys and assert that key to the auth service.
> >>>> Those keys are used for signing transaction when accessing a
> >>>> protected resource via TLS.".
> >>>
> >>> Are you asking that this work be extended so as to define
> >>> a general method for producing digital signatures on application
> >>> layer objects with the private key that is needed for moving
> >>> away from bearer tokens? (Assuming a digital signature based
> >>> way of doing better than bearer tokens, which is a reasonable
> >>> assumption.)
> >>>
> >>> If so, that seems like a major extension of scope and I'd be
> >>> interested in whether or not folks support that idea. And I'd
> >>> be opposed myself FWIW - too many pitfalls. A general thing
> >>> like that might be a good follow on but in a separate WG I'd
> >>> argue.
> >>>
> >>> If not, and you mean something less broad, then I think it'd
> >>> be better if you could try again and please provide a specific
> >>> charter language suggestion that only covers the narrower
> >>> scope of work you mean. And then we can see if folks like
> >>> the idea. In that case, please use OLD/NEW form to describe
> >>> the changes to [1] that you propose.
> >>>
> >>> Thanks,
> >>> S.
> >>>
> >>> [1]
> >>>
> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Ch=
arter-Draft.txt
> >>>
> >>>
> >>> Thanks,
> >>> S.
> >>>
> >>>
> >>>>
> >>>> On Saturday, January 24, 2015 5:48 PM, Stephen Farrell
> >>>>  wrote:
> >>>>
> >>>>
> >>>>
> >>>> Hi Bill,
> >>>>
> >>>> If you can send proposed text that'd be great. Absent that, to be
> >>>> honest, I'm not sure what change you'd like,
> >>>>
> >>>> Cheers, S.
> >>>>
> >>>> On 25/01/15 01:02, Bill Mills wrote:
> >>>>> I think the current text of the charter is not descriptive of what
> >>>>> this WG is really trying to solve.  It reads as though this is
> >>>>> about TLS channel binding which is wrong.  I'd like to see that
> >>>>> fixed in the language of the charter to be clearer. There was a
> >>>>> thread recently on what the elevator pitch for this is, and I think
> >>>>> language similar to that shoudl be in the first paragraph.
> >>>>>
> >>>>> On Saturday, January 24, 2015 3:34 PM, Stephen Farrell
> >>>>>  wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> Hiya,
> >>>>>
> >>>>> Andrei has asked me about next steps for this work, based on the
> >>>>> draft charter text at [1].
> >>>>>
> >>>>> I think that text is pretty good, but before I start the formal WG
> >>>>> chartering process I wanted to check here that there aren't major
> >>>>> problems with it.
> >>>>>
> >>>>> Two things I noted myself were that it'd be good to see some
> >>>>> support from server implementers who are not also browser makers.
> >>>>> And secondly, we probably need to talk to W3C about this too, as
> >>>>> [2] seems to need changes to XHR, which is their spec. [3] Both of
> >>>>> those could however be taken care of as we go forward.
> >>>>>
> >>>>> I did see Hannes' issue about TLS endpoint location and OAuth and
> >>>>> those are issues that need to be addressed but that I think should
> >>>>> be done in a WG.
> >>>>>
> >>>>> So can folks who have new argument as to why this work is wrong,
> >>>>> or definitely needs a BoF or with other new substantive comments
> >>>>> please post those in the next few days. Or if you previously posted
> >>>>> a substantive comment that was not addressed (noting that addressed
> >>>>> !=3D accepted) please post a link to that thread.
> >>>>>
> >>>>> I'll look at what comes up and if there is nothing new I'll
> >>>>> probably start the WG chartering process around mid-week. (To be
> >>>>> clear: at present I don't think this one needs a BoF in March, but
> >>>>> could be a chartered WG before then.)
> >>>>>
> >>>>> Cheers, S.
> >>>>>
> >>>>> PS: As a process thing, if we're moving ahead here, this will
> >>>>> appear as a place-holder in the BoF list for March so we can
> >>>>> schedule a session for the WG, if that is formed, or else use that
> >>>>> session for a BoF if one turns out to be needed.
> >>>>>
> >>>>>
> >>>>> [1]
> >>>>>
> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Ch=
arter-Draft.txt
> >>>>>
> >>>>>
> >>>>
> >>>>>
> >>> [2] https://tools.ietf.org/html/draft-balfanz-https-token-binding
> >>>>> [3] http://www.w3.org/TR/XMLHttpRequest/
> >>>>>
> >>>>> _______________________________________________ Unbearable mailing
> >>>>> list Unbearable@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/unbearable
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________ Unbearable mailing
> >>>>> list Unbearable@ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/unbearable
> >>>>>
> >>>>
> >>>> _______________________________________________ Unbearable mailing
> >>>> list Unbearable@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/unbearable
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> Unbearable mailing list
> >>> Unbearable@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/unbearable
> >>
> >> _______________________________________________
> >> Unbearable mailing list
> >> Unbearable@ietf.org
> >> https://www.ietf.org/mailman/listinfo/unbearable
> >
>
>
>
>
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable
>
>

--001a113a304e745e57050d927344
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


At a very high level, the current drafts propose:

(1) how a client can agree with a server about using =
token binding over a (resumable) TLS connection
(1a) the recommen=
dation that clients should use different "keys" for different eTL=
D+1
(2) how a browser and server can exchange "bound" i=
nformation over HTTP
(3) how, over HTTP, an RP can ask a browser =
to get, from an IdP, information that is bound for use with the RP

Is the duplication that you are referring to in (1) ?


On Mon, Jan 26, 2015 at 10:24 AM, Phil Hunt <phil.hunt@oracle.com<=
/a>> wrote:
I agree with part of what you are saying.

The browser flows are new.=C2=A0 The rest is duplicative. It is the over=
lap with the rest of the POP work that is problematic.



On Jan 26, 2015, at 10:02 AM, John =
Bradley <ve7jtb@v=
e7jtb.com> wrote:

=
I think it will help to make OAuth browser based flows PoP enabled.
However the flows for server/native will probably benefit less.=
=C2=A0 In a native app you can now use a single client key across multiple =
sessions.=C2=A0 Using token binding likely will prevent the same key from b=
eing used both with the RS and token endpoint for privacy reasons. =C2=A0 B=
y design the private key would also not be available to the application for=
 signing messages (perhaps a web crypto API might be developed in the brows=
er).

If you have a =E2=80=9Csmart=E2=80=9D client =
that can manage keys/certs then token binding is probably not a huge advanc=
ement. =C2=A0=C2=A0
It is huge for browsers where that ability to=
 manage keys doesn=E2=80=99t currently exist.

Just=
 my opinion.
John B.

On Jan 26, 2015, at 2:47 PM, Bill Mills <wmills_92105@yahoo.com> wrote:
In some ways this f=
its right in to POP if I understand it right.=C2=A0 Some of this is a way f=
or a key pair to be negotiated that could be used for an OAuth POP token, a=
nd that would be very useful.
 


 
 
 
  On Monday, Januar=
y 26, 2015 9:43 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
  
  
<=
br> 
I don't think the OAuth work is duplicative, mostly because I =
don't think that Token binding adds much to native/server applications =
that we don't already have with mutual TLS (perhaps some slightly nicer=
 ways to do the same thing)

Token bind=
ing will be useful for OAuth clients that are in the browser and in securin=
g the authorization request/response flow via the browser.

I don't think that Token binding doing end to end =
message level authentication over non TLS connections is in scope for this =
WG.

John B.
> On Jan 26, 2015, at 2:22 PM, Phil Hunt <phil.hunt@ora=
cle.com> wrote:
> 
> re yo=
ur last point.=C2=A0 My concern is the OAuth WG proceeding with a largely d=
uplicative solution in the app layer.
> 
> If the unbearable drafts can address the TLS not being end-to-end=
 (e.g. ending at a load-balancer scenario), then I=E2=80=99m not sure the O=
Auth work would be needed in its current scope.
> 
> I am concerned about keeping these separate WGs coordin=
ated to avoid overlap and/or perceived/actual complexity in any resulting s=
olution.
> 
> Phil
> 
> @independentid
> www.independentid.c=
om
> phil.hunt@oracle.com
>=
 
>> On Jan 26, 2015, at 9:04 AM, John Bradley <=
ve7jt=
b@ve7jtb.com> wrote:
>> 
&=
gt;> Last week I did a blog post on how token binding fits with a number=
 of the other related specs.
>> http://www.thread-safe.com/2015/01/proof-of-posse=
ssion-putting-pieces.html
>> 
>> Based on feedback from one of the token binding authors, I didn&#=
39;t butcher it too much.
>> 
>=
;> I think the use of the key established by token binding is best left =
to the protocols that want to use it.
>> 
>> Trying to cover the application layer is too broad a sco=
pe for this WG.
>> 
>> John=
 B.
>> 
>>> On Jan 26, 2=
015, at 1:53 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> w=
rote:
>>> 
>>> 
>>> Hi Bill,
>>> 
>>> Ok, so now I get the addition you're requesting.=

>>> 
>>> On 25/01/15=
 02:15, Bill Mills wrote:
>>>> From my "=
elevator pitch" question in the other thread, "Clients
>>>> (browsers) being able to tie credentials to loca=
lly generated and
>>>> managed keys and asser=
t that key to the auth service.".=C2=A0 #
>>&g=
t; 
>>> I note that that text does not occur in =
the current draft. [1]
>>> But I also know what =
you mean so moving on...
>>> 
=
>>>> To extend that I think it should be something like:
>>> 
>>>> "Clients =
(browsers) being able to tie credentials to locally
>&=
gt;>> generated and managed keys and assert that key to the auth serv=
ice.
>>>> Those keys are used for signing tra=
nsaction when accessing a
>>>> protected reso=
urce via TLS.".
>>> 
>=
>> Are you asking that this work be extended so as to define
>>> a general method for producing digital signatures on=
 application
>>> layer objects with the private =
key that is needed for moving
>>> away from bear=
er tokens? (Assuming a digital signature based
>>&g=
t; way of doing better than bearer tokens, which is a reasonable
>>> assumption.)
>>> 
>>> If so, that seems like a major extension of scope a=
nd I'd be
>>> interested in whether or not f=
olks support that idea. And I'd
>>> be oppos=
ed myself FWIW - too many pitfalls. A general thing
>&=
gt;> like that might be a good follow on but in a separate WG I'd>>> argue.
>>> 
>>> If not, and you mean something less broad, then I t=
hink it'd
>>> be better if you could try aga=
in and please provide a specific
>>> charter lan=
guage suggestion that only covers the narrower
>>&g=
t; scope of work you mean. And then we can see if folks like
>>> the idea. In that case, please use OLD/NEW form to describ=
e
>>> the changes to [1] that you propose.
>>> 
>>> Thanks,
>>> S.
>>> 
>>> [1]
>>> https://github.com/TokenBinding/WG-Charter=
/blob/master/TokenBinding-WG-Charter-Draft.txt
>&g=
t;> 
>>> 
>>> Than=
ks,
>>> S.
>>> 
>>> 
>>>> 
>>>> On Saturday, January 24, 2015 5:48 PM, Stephen Farre=
ll
>>>> <stephen.farrell@cs.tcd.ie&=
gt; wrote:
>>>> 
>>&g=
t;> 
>>>> 
>>>&=
gt; Hi Bill,
>>>> 
>>=
>> If you can send proposed text that'd be great. Absent that, to=
 be
>>>> honest, I'm not sure what change=
 you'd like,
>>>> 
>=
>>> Cheers, S.
>>>> 
>>>> On 25/01/15 01:02, Bill Mills wrote:
=
>>>>> I think the current text of the charter is not descrip=
tive of what 
>>>>> this WG is really tryi=
ng to solve.=C2=A0 It reads as though this is
>>>=
;>> about TLS channel binding which is wrong.=C2=A0 I'd like to s=
ee that
>>>>> fixed in the language of the=
 charter to be clearer. There was a
>>>>> =
thread recently on what the elevator pitch for this is, and I think
>>>>> language similar to that shoudl be in the f=
irst paragraph.
>>>>> 
&=
gt;>>>> On Saturday, January 24, 2015 3:34 PM, Stephen Farrell =

>>>>> <stephen.farrell@cs.tcd.ie> wrote:
>>>>> 
>=
>>>> 
>>>>> 
>>>>> Hiya,
>>>>> 
>>>>> Andrei has asked me about next steps for th=
is work, based on the 
>>>>> draft charter=
 text at [1].
>>>>> 
>=
;>>>> I think that text is pretty good, but before I start the =
formal WG 
>>>>> chartering process I want=
ed to check here that there aren't major 
>>>=
;>> problems with it.
>>>>> 
>>>>> Two things I noted myself were that it'=
d be good to see some
>>>>> support from s=
erver implementers who are not also browser makers.
>&=
gt;>>> And secondly, we probably need to talk to W3C about this to=
o, as
>>>>> [2] seems to need changes to X=
HR, which is their spec. [3] Both of
>>>>>=
 those could however be taken care of as we go forward.
&=
gt;>>>> 
>>>>> I did see Hanne=
s' issue about TLS endpoint location and OAuth and 
&=
gt;>>>> those are issues that need to be addressed but that I t=
hink should
>>>>> be done in a WG.
>>>>> 
>>>>> So =
can folks who have new argument as to why this work is wrong,
>>>>> or definitely needs a BoF or with other new subst=
antive comments
>>>>> please post those in=
 the next few days. Or if you previously posted
>>&=
gt;>> a substantive comment that was not addressed (noting that addre=
ssed
>>>>> !=3D accepted) please post a li=
nk to that thread.
>>>>> 
>>>>> I'll look at what comes up and if there is nothi=
ng new I'll
>>>>> probably start the W=
G chartering process around mid-week. (To be
>>>=
>> clear: at present I don't think this one needs a BoF in March,=
 but
>>>>> could be a chartered WG before =
then.)
>>>>> 
>>&g=
t;>> Cheers, S.
>>>>> 
>>>>> PS: As a process thing, if we're moving ahead=
 here, this will
>>>>> appear as a place-h=
older in the BoF list for March so we can
>>>>=
;> schedule a session for the WG, if that is formed, or else use that>>>>> session for a BoF if one turns out to =
be needed.
>>>>> 
>&g=
t;>>> 
>>>>> [1] 
>>>>> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding=
-WG-Charter-Draft.txt
>>>>> 
>>>>> 
>>>> 
>>>>> 
>>> [2] https://tools.ietf.org/html/draft-balfanz-https-to=
ken-binding
>>>>> [3] http://ww=
w.w3.org/TR/XMLHttpRequest/
>>>>> 
>>>>> _______________________________________=
________ Unbearable mailing 
>>>>> list Unbea=
rable@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/unbearable
&=
gt;>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________=
________ Unbearable mailing 
>>>>> list Unbea=
rable@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/unbearable
&=
gt;>>>> 
>>>> 
=
>>>> _______________________________________________ Unbearable=
 mailing
>>>> list Unbearable@ietf.org 
>>>> https://www.ietf.org/mail=
man/listinfo/unbearable
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>=
;>> _______________________________________________
>>> Unbearable mailing list
>>> Unbearabl=
e@ietf.org
>>> https://ww=
w.ietf.org/mailman/listinfo/unbearable
>> 
>> _______________________________________________
>> Unbearable mailing list
>> <=
a shape=3D"rect" href=3D"mailto:Unbearable@ietf.org" target=3D"_blank">Unbe=
arable@ietf.org
>> https://w=
ww.ietf.org/mailman/listinfo/unbearable
> 


  
 
  
 


<=
/div>

_______________________________________________

Unbearable mailing list

Unbearable@ietf.org

https://www.ietf.org/mailman/listinfo/unbearable





--001a113a304e745e57050d927344--


From nobody Mon Jan 26 11:00:41 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE1011ACE3C for ; Mon, 26 Jan 2015 11:00:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 USYUbDJ3inuF for ; Mon, 26 Jan 2015 11:00:36 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3815F1ACE35 for ; Mon, 26 Jan 2015 11:00:36 -0800 (PST)
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) with Microsoft SMTP Server (TLS) id 15.1.65.19; Mon, 26 Jan 2015 19:00:34 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0065.013; Mon, 26 Jan 2015 19:00:34 +0000
From: Andrei Popov 
To: Stephen Farrell , "unbearable@ietf.org" 
Thread-Topic: [Unbearable] moving ahead
Thread-Index: AQHQOC5M76bwfurn402VuGq+DLEuC5zSoRSAgAAfhqA=
Date: Mon, 26 Jan 2015 19:00:34 +0000
Message-ID: 
References: <54C42BFB.4040300@cs.tcd.ie> <54C67139.8000404@cs.tcd.ie>
In-Reply-To: <54C67139.8000404@cs.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::3]
authentication-results: cs.tcd.ie; dkim=none (message not signed) header.d=none;cs.tcd.ie; dmarc=none action=none header.from=microsoft.com;
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN3PR0301MB1251;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251; 
x-forefront-prvs: 0468FE4A2B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(51704005)(479174004)(51444003)(54356999)(76176999)(15975445007)(54206007)(106116001)(102836002)(2900100001)(86362001)(92566002)(74316001)(2656002)(2950100001)(19580405001)(19580395003)(2501002)(86612001)(107886001)(40100003)(87936001)(76576001)(122556002)(50986999)(99286002)(46102003)(54606007)(62966003)(77156002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2015 19:00:34.3930 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1251
Archived-At: 
Subject: Re: [Unbearable] moving ahead
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 19:00:40 -0000

Hi Stephen,

Correct: as currently described, TB uses TLS-UNIQUE and ALPN. A security pr=
otocol other than TLS may be able to provide similar facilities, in which c=
ase it will work with TB just as well as TLS.

It is true that TB can be adapted for use with security protocols other tha=
n TLS, but my preference would be to avoid expanding the scope of the chart=
er, so that we can make progress in a reasonable amount of time.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Stephen =
Farrell
Sent: Monday, January 26, 2015 8:54 AM
To: unbearable@ietf.org
Subject: Re: [Unbearable] moving ahead


Hiya,

I forwarded this to the IESG as a heads-up and got a good question. That an=
d my answer below just for checking. Not sure if clarifying this in the cha=
rter would be good or not.

The question was:
>> Is it reasonable to consider whether the token binding protocol could=20
>> be used with other security protocols other than TLS?

And I said:

> Good question. I'd say the answer is, yes in theory and other=20
> client-server protocols should be able to follow the design pattern,=20
> (arguably HOBA does in HTTP:-) but no in practice, the protocol=20
> specifics would be quite likely tied to TLS for security reasons (e.g.=20
> bind to a (pre-)master secret, though that could be generalised) but=20
> more likely simply for the convenience of using ALPN and TLS=20
> extensions and the TLS style of specifying PDUs, etc."

Cheers,
S.





On 24/01/15 23:34, Stephen Farrell wrote:
>=20
> Hiya,
>=20
> Andrei has asked me about next steps for this work, based on the draft=20
> charter text at [1].
>=20
> I think that text is pretty good, but before I start the formal WG=20
> chartering process I wanted to check here that there aren't major=20
> problems with it.
>=20
> Two things I noted myself were that it'd be good to see some support=20
> from server implementers who are not also browser makers.
> And secondly, we probably need to talk to W3C about this too, as [2]=20
> seems to need changes to XHR, which is their spec. [3] Both of those=20
> could however be taken care of as we go forward.
>=20
> I did see Hannes' issue about TLS endpoint location and OAuth and=20
> those are issues that need to be addressed but that I think should be=20
> done in a WG.
>=20
> So can folks who have new argument as to why this work is wrong, or=20
> definitely needs a BoF or with other new substantive comments please=20
> post those in the next few days. Or if you previously posted a=20
> substantive comment that was not addressed (noting that addressed !=3D=20
> accepted) please post a link to that thread.
>=20
> I'll look at what comes up and if there is nothing new I'll probably=20
> start the WG chartering process around mid-week.
> (To be clear: at present I don't think this one needs a BoF in March,=20
> but could be a chartered WG before then.)
>=20
> Cheers,
> S.
>=20
> PS: As a process thing, if we're moving ahead here, this will appear=20
> as a place-holder in the BoF list for March so we can schedule a=20
> session for the WG, if that is formed, or else use that session for a=20
> BoF if one turns out to be needed.
>=20
>=20
> [1]
> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG
> -Charter-Draft.txt [2]=20
> https://tools.ietf.org/html/draft-balfanz-https-token-binding
> [3] http://www.w3.org/TR/XMLHttpRequest/
>=20
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable
>=20
>=20

_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable


From nobody Mon Jan 26 12:26:10 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAC01B2A25 for ; Mon, 26 Jan 2015 12:26:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level: 
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 DSKR2anR6eDK for ; Mon, 26 Jan 2015 12:25:58 -0800 (PST)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D5FC1A1A8F for ; Mon, 26 Jan 2015 12:25:58 -0800 (PST)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t0QKPg1X005530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Jan 2015 20:25:43 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0QKPeB1025292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Jan 2015 20:25:40 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id t0QKPdUX017001; Mon, 26 Jan 2015 20:25:39 GMT
Received: from [10.0.1.7] (/24.86.216.17) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 26 Jan 2015 12:25:39 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_F0BE7103-48B9-4E1B-9053-8BFA353E745C"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
From: Phil Hunt 
In-Reply-To: 
Date: Mon, 26 Jan 2015 12:25:37 -0800
Message-Id: <8D5D0214-D38F-42A1-AB9D-7D1FE7CAA74C@oracle.com>
References:  <339123303.662625.1422294474487.JavaMail.yahoo@mail.yahoo.com> <4B97C960-06B5-49BC-93E9-729EF218430A@ve7jtb.com> <8449BE8E-6416-4C35-80ED-8BC7CBF7ADB0@oracle.com> 
To: Vinod Anupam 
X-Mailer: Apple Mail (2.1993)
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Archived-At: 
Cc: John Bradley , "unbearable@ietf.org" , William Mills , Stephen Farrell 
Subject: Re: [Unbearable] moving ahead
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 20:26:09 -0000

--Apple-Mail=_F0BE7103-48B9-4E1B-9053-8BFA353E745C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

While the solutions between unbearable and OAuth POP are different (one =
is mixed layer, the other is pure app layer), the objectives are the =
same - proof of possession.  Why not fold the OAuth POP work into this =
WG? =20

If the work needs to be separate, then should the OAuth POP scope of =
work be reduced to cover what the unbearable drafts do not cover?

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com

> On Jan 26, 2015, at 10:38 AM, Vinod Anupam  wrote:
>=20
> At a very high level, the current drafts propose:
>=20
> (1) how a client can agree with a server about using token binding =
over a (resumable) TLS connection
> (1a) the recommendation that clients should use different "keys" for =
different eTLD+1
> (2) how a browser and server can exchange "bound" information over =
HTTP
> (3) how, over HTTP, an RP can ask a browser to get, from an IdP, =
information that is bound for use with the RP
>=20
> Is the duplication that you are referring to in (1) ?
>=20
>=20
> On Mon, Jan 26, 2015 at 10:24 AM, Phil Hunt > wrote:
> I agree with part of what you are saying.
>=20
> The browser flows are new.  The rest is duplicative. It is the overlap =
with the rest of the POP work that is problematic.
>=20
> Phil
>=20
> @independentid
> www.independentid.com =
phil.hunt@oracle.com =

>=20
>> On Jan 26, 2015, at 10:02 AM, John Bradley > wrote:
>>=20
>> I think it will help to make OAuth browser based flows PoP enabled.
>>=20
>> However the flows for server/native will probably benefit less.  In a =
native app you can now use a single client key across multiple sessions. =
 Using token binding likely will prevent the same key from being used =
both with the RS and token endpoint for privacy reasons.   By design the =
private key would also not be available to the application for signing =
messages (perhaps a web crypto API might be developed in the browser).
>>=20
>> If you have a =E2=80=9Csmart=E2=80=9D client that can manage =
keys/certs then token binding is probably not a huge advancement.  =20
>> It is huge for browsers where that ability to manage keys doesn=E2=80=99=
t currently exist.
>>=20
>> Just my opinion.
>> John B.
>>=20
>>> On Jan 26, 2015, at 2:47 PM, Bill Mills > wrote:
>>>=20
>>> In some ways this fits right in to POP if I understand it right.  =
Some of this is a way for a key pair to be negotiated that could be used =
for an OAuth POP token, and that would be very useful.
>>>=20
>>>=20
>>> On Monday, January 26, 2015 9:43 AM, John Bradley > wrote:
>>>=20
>>>=20
>>> I don't think the OAuth work is duplicative, mostly because I don't =
think that Token binding adds much to native/server applications that we =
don't already have with mutual TLS (perhaps some slightly nicer ways to =
do the same thing)
>>>=20
>>> Token binding will be useful for OAuth clients that are in the =
browser and in securing the authorization request/response flow via the =
browser.
>>>=20
>>> I don't think that Token binding doing end to end message level =
authentication over non TLS connections is in scope for this WG.
>>>=20
>>> John B.
>>>=20
>>> > On Jan 26, 2015, at 2:22 PM, Phil Hunt > wrote:
>>> >=20
>>> > re your last point.  My concern is the OAuth WG proceeding with a =
largely duplicative solution in the app layer.
>>> >=20
>>> > If the unbearable drafts can address the TLS not being end-to-end =
(e.g. ending at a load-balancer scenario), then I=E2=80=99m not sure the =
OAuth work would be needed in its current scope.
>>> >=20
>>> > I am concerned about keeping these separate WGs coordinated to =
avoid overlap and/or perceived/actual complexity in any resulting =
solution.
>>> >=20
>>> > Phil
>>> >=20
>>> > @independentid
>>> > www.independentid.com 
>>> > phil.hunt@oracle.com 
>>> >=20
>>> >> On Jan 26, 2015, at 9:04 AM, John Bradley > wrote:
>>> >>=20
>>> >> Last week I did a blog post on how token binding fits with a =
number of the other related specs.
>>> >> =
http://www.thread-safe.com/2015/01/proof-of-possession-putting-pieces.html=
 =

>>> >>=20
>>> >> Based on feedback from one of the token binding authors, I didn't =
butcher it too much.
>>> >>=20
>>> >> I think the use of the key established by token binding is best =
left to the protocols that want to use it.
>>> >>=20
>>> >> Trying to cover the application layer is too broad a scope for =
this WG.
>>> >>=20
>>> >> John B.
>>> >>=20
>>> >>> On Jan 26, 2015, at 1:53 PM, Stephen Farrell =
> wrote:
>>> >>>=20
>>> >>>=20
>>> >>> Hi Bill,
>>> >>>=20
>>> >>> Ok, so now I get the addition you're requesting.
>>> >>>=20
>>> >>> On 25/01/15 02:15, Bill Mills wrote:
>>> >>>> =46rom my "elevator pitch" question in the other thread, =
"Clients
>>> >>>> (browsers) being able to tie credentials to locally generated =
and
>>> >>>> managed keys and assert that key to the auth service.".  #
>>> >>>=20
>>> >>> I note that that text does not occur in the current draft. [1]
>>> >>> But I also know what you mean so moving on...
>>> >>>=20
>>> >>>> To extend that I think it should be something like:
>>> >>>=20
>>> >>>> "Clients (browsers) being able to tie credentials to locally
>>> >>>> generated and managed keys and assert that key to the auth =
service.
>>> >>>> Those keys are used for signing transaction when accessing a
>>> >>>> protected resource via TLS.".
>>> >>>=20
>>> >>> Are you asking that this work be extended so as to define
>>> >>> a general method for producing digital signatures on application
>>> >>> layer objects with the private key that is needed for moving
>>> >>> away from bearer tokens? (Assuming a digital signature based
>>> >>> way of doing better than bearer tokens, which is a reasonable
>>> >>> assumption.)
>>> >>>=20
>>> >>> If so, that seems like a major extension of scope and I'd be
>>> >>> interested in whether or not folks support that idea. And I'd
>>> >>> be opposed myself FWIW - too many pitfalls. A general thing
>>> >>> like that might be a good follow on but in a separate WG I'd
>>> >>> argue.
>>> >>>=20
>>> >>> If not, and you mean something less broad, then I think it'd
>>> >>> be better if you could try again and please provide a specific
>>> >>> charter language suggestion that only covers the narrower
>>> >>> scope of work you mean. And then we can see if folks like
>>> >>> the idea. In that case, please use OLD/NEW form to describe
>>> >>> the changes to [1] that you propose.
>>> >>>=20
>>> >>> Thanks,
>>> >>> S.
>>> >>>=20
>>> >>> [1]
>>> >>> =
https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Cha=
rter-Draft.txt =

>>> >>>=20
>>> >>>=20
>>> >>> Thanks,
>>> >>> S.
>>> >>>=20
>>> >>>=20
>>> >>>>=20
>>> >>>> On Saturday, January 24, 2015 5:48 PM, Stephen Farrell
>>> >>>> > =
wrote:
>>> >>>>=20
>>> >>>>=20
>>> >>>>=20
>>> >>>> Hi Bill,
>>> >>>>=20
>>> >>>> If you can send proposed text that'd be great. Absent that, to =
be
>>> >>>> honest, I'm not sure what change you'd like,
>>> >>>>=20
>>> >>>> Cheers, S.
>>> >>>>=20
>>> >>>> On 25/01/15 01:02, Bill Mills wrote:
>>> >>>>> I think the current text of the charter is not descriptive of =
what=20
>>> >>>>> this WG is really trying to solve.  It reads as though this is
>>> >>>>> about TLS channel binding which is wrong.  I'd like to see =
that
>>> >>>>> fixed in the language of the charter to be clearer. There was =
a
>>> >>>>> thread recently on what the elevator pitch for this is, and I =
think
>>> >>>>> language similar to that shoudl be in the first paragraph.
>>> >>>>>=20
>>> >>>>> On Saturday, January 24, 2015 3:34 PM, Stephen Farrell=20
>>> >>>>> > =
wrote:
>>> >>>>>=20
>>> >>>>>=20
>>> >>>>>=20
>>> >>>>> Hiya,
>>> >>>>>=20
>>> >>>>> Andrei has asked me about next steps for this work, based on =
the=20
>>> >>>>> draft charter text at [1].
>>> >>>>>=20
>>> >>>>> I think that text is pretty good, but before I start the =
formal WG=20
>>> >>>>> chartering process I wanted to check here that there aren't =
major=20
>>> >>>>> problems with it.
>>> >>>>>=20
>>> >>>>> Two things I noted myself were that it'd be good to see some
>>> >>>>> support from server implementers who are not also browser =
makers.
>>> >>>>> And secondly, we probably need to talk to W3C about this too, =
as
>>> >>>>> [2] seems to need changes to XHR, which is their spec. [3] =
Both of
>>> >>>>> those could however be taken care of as we go forward.
>>> >>>>>=20
>>> >>>>> I did see Hannes' issue about TLS endpoint location and OAuth =
and=20
>>> >>>>> those are issues that need to be addressed but that I think =
should
>>> >>>>> be done in a WG.
>>> >>>>>=20
>>> >>>>> So can folks who have new argument as to why this work is =
wrong,
>>> >>>>> or definitely needs a BoF or with other new substantive =
comments
>>> >>>>> please post those in the next few days. Or if you previously =
posted
>>> >>>>> a substantive comment that was not addressed (noting that =
addressed
>>> >>>>> !=3D accepted) please post a link to that thread.
>>> >>>>>=20
>>> >>>>> I'll look at what comes up and if there is nothing new I'll
>>> >>>>> probably start the WG chartering process around mid-week. (To =
be
>>> >>>>> clear: at present I don't think this one needs a BoF in March, =
but
>>> >>>>> could be a chartered WG before then.)
>>> >>>>>=20
>>> >>>>> Cheers, S.
>>> >>>>>=20
>>> >>>>> PS: As a process thing, if we're moving ahead here, this will
>>> >>>>> appear as a place-holder in the BoF list for March so we can
>>> >>>>> schedule a session for the WG, if that is formed, or else use =
that
>>> >>>>> session for a BoF if one turns out to be needed.
>>> >>>>>=20
>>> >>>>>=20
>>> >>>>> [1]=20
>>> >>>>> =
https://github.com/TokenBinding/WG-Charter/blob/master/TokenBinding-WG-Cha=
rter-Draft.txt =

>>> >>>>>=20
>>> >>>>>=20
>>> >>>>=20
>>> >>>>>=20
>>> >>> [2] =
https://tools.ietf.org/html/draft-balfanz-https-token-binding =

>>> >>>>> [3] http://www.w3.org/TR/XMLHttpRequest/ =

>>> >>>>>=20
>>> >>>>> _______________________________________________ Unbearable =
mailing=20
>>> >>>>> list Unbearable@ietf.org =20
>>> >>>>> https://www.ietf.org/mailman/listinfo/unbearable =

>>> >>>>>=20
>>> >>>>>=20
>>> >>>>>=20
>>> >>>>>=20
>>> >>>>>=20
>>> >>>>>=20
>>> >>>>> _______________________________________________ Unbearable =
mailing=20
>>> >>>>> list Unbearable@ietf.org =20
>>> >>>>> https://www.ietf.org/mailman/listinfo/unbearable =

>>> >>>>>=20
>>> >>>>=20
>>> >>>> _______________________________________________ Unbearable =
mailing
>>> >>>> list Unbearable@ietf.org =20
>>> >>>> https://www.ietf.org/mailman/listinfo/unbearable =

>>> >>>>=20
>>> >>>>=20
>>> >>>>=20
>>> >>>>=20
>>> >>>=20
>>> >>> _______________________________________________
>>> >>> Unbearable mailing list
>>> >>> Unbearable@ietf.org 
>>> >>> https://www.ietf.org/mailman/listinfo/unbearable =

>>> >>=20
>>> >> _______________________________________________
>>> >> Unbearable mailing list
>>> >> Unbearable@ietf.org 
>>> >> https://www.ietf.org/mailman/listinfo/unbearable =

>>> >=20
>>>=20
>>>=20
>>=20
>=20
>=20
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org 
> https://www.ietf.org/mailman/listinfo/unbearable =

>=20
>=20
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable


--Apple-Mail=_F0BE7103-48B9-4E1B-9053-8BFA353E745C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


While the solutions between unbearable and =
OAuth POP are different (one is mixed layer, the other is pure app =
layer), the objectives are the same - proof of possession.  Why not =
fold the OAuth POP work into this WG?  

If the work needs to be separate, then =
should the OAuth POP scope of work be reduced to cover what the =
unbearable drafts do not cover?






On Jan 26, 2015, at 10:38 AM, Vinod Anupam <vanupam@google.com> =
wrote:

At a very high level, the current =
drafts propose:

(1) how a client can agree with a server about using token =
binding over a (resumable) TLS connection
(1a) the =
recommendation that clients should use different "keys" for different =
eTLD+1
(2) how a browser and server can exchange =
"bound" information over HTTP
(3) how, over HTTP, =
an RP can ask a browser to get, from an IdP, information that is bound =
for use with the RP

Is the duplication that you are referring to in (1) =
?


On Mon, =
Jan 26, 2015 at 10:24 AM, Phil Hunt <phil.hunt@oracle.com> wrote:
I agree with part of what you =
are saying.

The =
browser flows are new.  The rest is duplicative. It is the overlap =
with the rest of the POP work that is problematic.







On Jan 26, 2015, at 10:02 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

I think it =
will help to make OAuth browser based flows PoP enabled.

However the flows for =
server/native will probably benefit less.  In a native app you can =
now use a single client key across multiple sessions.  Using token =
binding likely will prevent the same key from being used both with the =
RS and token endpoint for privacy reasons.   By design the private =
key would also not be available to the application for signing messages =
(perhaps a web crypto API might be developed in the browser).

If you have a =
=E2=80=9Csmart=E2=80=9D client that can manage keys/certs then token =
binding is probably not a huge advancement.   
It is huge for browsers where that ability to manage keys =
doesn=E2=80=99t currently exist.

Just my opinion.
John B.

On Jan =
26, 2015, at 2:47 PM, Bill Mills <wmills_92105@yahoo.com> wrote:

In some ways =
this fits right in to POP if I understand it right.  Some of this =
is a way for a key pair to be negotiated that could be used for an OAuth =
POP token, and that would be very useful.
 

 =

 =

 =

  On Monday, =
January 26, 2015 9:43 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
  =

  

 
I don't think the =
OAuth work is duplicative, mostly because I don't think that Token =
binding adds much to native/server applications that we don't already =
have with mutual TLS (perhaps some slightly nicer ways to do the same =
thing)

Token =
binding will be useful for OAuth clients that are in the browser and in =
securing the authorization request/response flow via the browser.

I don't think =
that Token binding doing end to end message level authentication over =
non TLS connections is in scope for this WG.

John B.

> On Jan 26, =
2015, at 2:22 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
> 
> re your last =
point.  My concern is the OAuth WG proceeding with a largely =
duplicative solution in the app layer.
> =

> If the unbearable drafts can address =
the TLS not being end-to-end (e.g. ending at a load-balancer scenario), =
then I=E2=80=99m not sure the OAuth work would be needed in its current =
scope.
> 
> I am concerned about keeping these separate WGs =
coordinated to avoid overlap and/or perceived/actual complexity in any =
resulting solution.
> 
> Phil
> 
> @independentid
> www.independentid.com
> =
phil.hunt@oracle.com
> =

>> On Jan 26, 2015, at 9:04 AM, John =
Bradley <ve7jtb@ve7jtb.com> wrote:
>> 
>> =
Last week I did a blog post on how token binding fits with a number of =
the other related specs.
>> http://www.thread-safe.com/2015/01/proof-of-possession-putting-=
pieces.html
>> 
>> Based on feedback from one of the token binding =
authors, I didn't butcher it too much.
>> 
>> I think the =
use of the key established by token binding is best left to the =
protocols that want to use it.
>> 
>> Trying to cover the application layer =
is too broad a scope for this WG.
>> =

>> John B.
>> 
>>> On Jan =
26, 2015, at 1:53 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>>> 
>>> 
>>> Hi Bill,
>>> 
>>> Ok, =
so now I get the addition you're requesting.
>>> 
>>> On =
25/01/15 02:15, Bill Mills wrote:
>>>> =46rom my "elevator pitch" question in the =
other thread, "Clients
>>>> =
(browsers) being able to tie credentials to locally generated and
>>>> managed keys and assert that =
key to the auth service.".  #
>>> 
>>> I =
note that that text does not occur in the current draft. [1]
>>> But I also know what you mean so =
moving on...
>>> 
>>>> To extend that I think it should be =
something like:
>>> 
>>>> "Clients (browsers) being =
able to tie credentials to locally
>>>> generated and managed keys and assert that =
key to the auth service.
>>>> =
Those keys are used for signing transaction when accessing a
>>>> protected resource via =
TLS.".
>>> 
>>> Are you asking that this work be extended so as =
to define
>>> a general method for =
producing digital signatures on application
>>> layer objects with the private key that is =
needed for moving
>>> away from =
bearer tokens? (Assuming a digital signature based
>>> way of doing better than bearer tokens, which is =
a reasonable
>>> assumption.)
>>> 
>>> If so, that seems like a major extension of =
scope and I'd be
>>> interested in =
whether or not folks support that idea. And I'd
>>> be opposed myself FWIW - too many pitfalls. A =
general thing
>>> like that might =
be a good follow on but in a separate WG I'd
>>> argue.
>>> =

>>> If not, and you mean =
something less broad, then I think it'd
>>> be better if you could try again and please =
provide a specific
>>> charter =
language suggestion that only covers the narrower
>>> scope of work you mean. And then we can see if =
folks like
>>> the idea. In that =
case, please use OLD/NEW form to describe
>>> the changes to [1] that you propose.
>>> 
>>> Thanks,
>>> =
S.
>>> 
>>> [1]
>>> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBin=
ding-WG-Charter-Draft.txt
>>> =

>>> 
>>> Thanks,
>>> =
S.
>>> 
>>> 
>>>> =

>>>> On Saturday, January 24, =
2015 5:48 PM, Stephen Farrell
>>>> <stephen.farrell@cs.tcd.ie> wrote:
>>>> 
>>>>=
 
>>>> 
>>>> Hi Bill,
>>>> 
>>>>=
 If you can send proposed text that'd be great. Absent that, to be
>>>> honest, I'm not sure what =
change you'd like,
>>>> 
>>>> Cheers, S.
>>>> 
>>>>=
 On 25/01/15 01:02, Bill Mills wrote:
>>>>> I think the current text of the charter =
is not descriptive of what 
>>>>> this WG is really trying to solve.  =
It reads as though this is
>>>>> about TLS channel binding which is =
wrong.  I'd like to see that
>>>>> fixed in the language of the charter to =
be clearer. There was a
>>>>> =
thread recently on what the elevator pitch for this is, and I think
>>>>> language similar to that =
shoudl be in the first paragraph.
>>>>> 
>>>>> On Saturday, January 24, 2015 3:34 PM, =
Stephen Farrell 
>>>>> =
<stephen.farrell@cs.tcd.ie> wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>> Hiya,
>>>>> 
>>>>> Andrei has asked me about next steps for =
this work, based on the 
>>>>>=
 draft charter text at [1].
>>>>> 
>>>>> I think that text is pretty good, but =
before I start the formal WG 
>>>>> chartering process I wanted to check =
here that there aren't major 
>>>>> problems with it.
>>>>> 
>>>>> Two things I noted myself were that it'd =
be good to see some
>>>>> =
support from server implementers who are not also browser makers.
>>>>> And secondly, we probably =
need to talk to W3C about this too, as
>>>>> [2] seems to need changes to XHR, which =
is their spec. [3] Both of
>>>>> those could however be taken care of as =
we go forward.
>>>>> 
>>>>> I did see Hannes' issue =
about TLS endpoint location and OAuth and 
>>>>> those are issues that need to be =
addressed but that I think should
>>>>> be done in a WG.
>>>>> 
>>>>> So can folks who have new argument as to =
why this work is wrong,
>>>>> =
or definitely needs a BoF or with other new substantive comments
>>>>> please post those in the =
next few days. Or if you previously posted
>>>>> a substantive comment that was not =
addressed (noting that addressed
>>>>> !=3D accepted) please post a link to =
that thread.
>>>>> 
>>>>> I'll look at what comes =
up and if there is nothing new I'll
>>>>> probably start the WG chartering process =
around mid-week. (To be
>>>>> =
clear: at present I don't think this one needs a BoF in March, but
>>>>> could be a chartered WG =
before then.)
>>>>> 
>>>>> Cheers, S.
>>>>> 
>>>>> PS: As a process thing, if we're moving =
ahead here, this will
>>>>> =
appear as a place-holder in the BoF list for March so we can
>>>>> schedule a session for =
the WG, if that is formed, or else use that
>>>>> session for a BoF if one turns out to be =
needed.
>>>>> 
>>>>> 
>>>>> [1] 
>>>>> https://github.com/TokenBinding/WG-Charter/blob/master/TokenBin=
ding-WG-Charter-Draft.txt
>>>>> 
>>>>> 
>>>> 
>>>>> 
>>>=
 [2] https://tools.ietf.org/html/draft-balfanz-https-token-binding
>>>>> [3] http://www.w3.org/TR/XMLHttpRequest/
>>>>> 
>>>>> =
_______________________________________________ Unbearable mailing 
>>>>> list Unbearable@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> =
_______________________________________________ Unbearable mailing 
>>>>> list Unbearable@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>>> 
>>>> 
>>>>=
 _______________________________________________ Unbearable mailing
>>>> list Unbearable@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/unbearable
>>>> 
>>>> 
>>>>=
 
>>>> 
>>> 
>>> =
_______________________________________________
>>> Unbearable mailing list
>>> Unbearable@ietf.org
>>> https://www.ietf.org/mailman/listinfo/unbearable
>> 
>> =
_______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.org/mailman/listinfo/unbearable
> 


  
 
  
 =




_______________________________________________

Unbearable mailing list

Unbearable@ietf.org

https://www.ietf.org/mailman/listinfo/unbearable




_______________________________________________
Unbearable =
mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable

=

--Apple-Mail=_F0BE7103-48B9-4E1B-9053-8BFA353E745C--


From nobody Mon Jan 26 12:51:09 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40841A1B5D for ; Mon, 26 Jan 2015 12:51:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 095DR3Yutf1j for ; Mon, 26 Jan 2015 12:51:00 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0787.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:787]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866281A01F0 for ; Mon, 26 Jan 2015 12:51:00 -0800 (PST)
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1249.namprd03.prod.outlook.com (25.161.207.25) with Microsoft SMTP Server (TLS) id 15.1.65.19; Mon, 26 Jan 2015 20:50:36 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0065.013; Mon, 26 Jan 2015 20:50:36 +0000
From: Andrei Popov 
To: Kathleen Moriarty 
Thread-Topic: [Unbearable] Updated Charter Proposal
Thread-Index: AdAwVoQybrCT+HkuTniRvdMsDdHeWgAkZqIAAAL3ZlAAAwXvAAEDcGvAAMwnb4AAWrGZIA==
Date: Mon, 26 Jan 2015 20:50:36 +0000
Message-ID: 
References:      
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::2]
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com;
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN3PR0301MB1249;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1249; 
x-forefront-prvs: 0468FE4A2B
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(24454002)(164054003)(51704005)(19580405001)(86612001)(122556002)(93886004)(76576001)(50986999)(77156002)(19580395003)(62966003)(2950100001)(2900100001)(99286002)(40100003)(54356999)(86362001)(15975445007)(102836002)(76176999)(87936001)(2656002)(46102003)(74316001)(92566002)(110136001)(561944003)(33656002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1249; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jan 2015 20:50:36.7544 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1249
Archived-At: 
Cc: John Bradley , "unbearable@ietf.org" 
Subject: Re: [Unbearable] Updated Charter Proposal
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Jan 2015 20:51:05 -0000

VGhhbmtzIEthdGhsZWVuIGZvciBoZWxwaW5nIGltcHJvdmUgdGhlIGNoYXJ0ZXIgZHJhZnQuDQoN
CkVkaXRvcmlhbCBjaGFuZ2VzIGhhdmUgYmVlbiBpbmNvcnBvcmF0ZWQ6IGh0dHBzOi8vZ2l0aHVi
LmNvbS9Ub2tlbkJpbmRpbmcvV0ctQ2hhcnRlcg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQotLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogS2F0aGxlZW4gTW9yaWFydHkgW21haWx0bzpr
YXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbV0gDQpTZW50OiBTYXR1cmRheSwgSmFudWFy
eSAyNCwgMjAxNSA1OjMwIFBNDQpUbzogQW5kcmVpIFBvcG92DQpDYzogSm9obiBCcmFkbGV5OyB1
bmJlYXJhYmxlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFVwZGF0ZWQgQ2hh
cnRlciBQcm9wb3NhbA0KDQpIaSwNCg0KVGhlIGNoYXJ0ZXIgbG9va3MgbGlrZSBpdCBpcyBzaGFw
aW5nIHVwLiAgSSBqdXN0IGhhdmUgc29tZSBlZGl0b3JpYWwgc3VnZ2VzdGlvbnMgYXMgdGhlIGRp
c2N1c3Npb24gY29udGludWVzLCB0YWtlIHRoZW0gb3IgbGVhdmUgdGhlbSwgbm90IGEgYmlnIGRl
YWwuDQoNClN1Z2dlc3QgY2hhbmdpbmcgZnJvbToNClRoZSBpZGVhIG9mIFRva2VuIEJpbmRpbmcg
aXMgdG8gZW5hYmxlIGRlZmVuc2UgYWdhaW5zdCBzdWNoIGF0dGFja3MgYnkgY3J5cHRvZ3JhcGhp
Y2FsbHkgYmluZGluZyBzZWN1cml0eSB0b2tlbnMgdG8gdGhlIFRMUyBsYXllci4NCg0KVG86DQpU
b2tlbiBCaW5kaW5nIGVuYWJsZXMgZGVmZW5zZSBhZ2FpbnN0IHN1Y2ggYXR0YWNrcyBieSBjcnlw
dG9ncmFwaGljYWxseSBiaW5kaW5nIHNlY3VyaXR5IHRva2VucyB0byB0aGUgVExTIGxheWVyLg0K
DQpUaGUgd29yZCBnb2FsIGlzIHVzZWQgYSBiaXQgbXVjaCwgYnV0IHRoaXMgaXMgYSBwZXJzb25h
bCBwcmVmZXJlbmNlIC0gdGFrZSBvciBsZWF2ZSB0aGUgc3VnZ2VzdGlvbnMuICBJIHN1Z2dlc3Qg
cmVtb3ZpbmcgIlNvbWUiIGluIHRoZSBsYXN0IHNlbnRlbmNlIGxpc3RlZCBhcyB0aGlzIG9ubHkg
c2F5cyB0aGUgIm1haW4iIGdvYWxzL29iamVjdGl2ZXMsIHNvIHRoZXJlIGlzIHdpZ2dsZSByb29t
IHN0aWxsLg0KDQpGcm9tOg0KSXQgaXMgYSBnb2FsIG9mIHRoaXMgd29ya2luZyBncm91cCB0byBl
bmFibGUgZGVmZW5zZSBhZ2FpbnN0IGF0dGFja3MgdGhhdCBpbnZvbHZlIHVuYXV0aG9yaXplZCBy
ZXBsYXkgb2Ygc2VjdXJpdHkgdG9rZW5zLCBidXQgb3RoZXIgaXNzdWVzIGFzc29jaWF0ZWQgd2l0
aCB0aGUgdXNlIG9mIHNlY3VyaXR5IHRva2VucyBhcmUgb3V0IG9mIHNjb3BlLiBJdCBpcyBhIGdv
YWwgb2YgdGhpcyB3b3JraW5nIGdyb3VwIHRvIGRlc2lnbiB0aGUgVG9rZW4gQmluZGluZyBwcm90
b2NvbCBzdWNoIHRoYXQgaXQgd291bGQgYmUgYWxzbyB1c2VhYmxlIHdpdGggYXBwbGljYXRpb24g
cHJvdG9jb2xzIG90aGVyIHRoYW4gSFRUUFMsIGhvd2V2ZXIgc3BlY2lmeWluZyBzdWNoIHVzZXMg
aXMgbm90IGEgcHJpbWFyeSBnb2FsLg0KDQpTb21lIG9mIHRoZSBtYWluIGRlc2lnbiBnb2FscyBm
b3IgdGhlIFRva2VuIEJpbmRpbmcgcHJvdG9jb2wsIGluIG5vIHBhcnRpY3VsYXIgb3JkZXI6DQoN
ClRvOg0KSXQgaXMgYSBnb2FsIG9mIHRoaXMgd29ya2luZyBncm91cCB0byBlbmFibGUgZGVmZW5z
ZSBhZ2FpbnN0IGF0dGFja3MgdGhhdCBpbnZvbHZlIHVuYXV0aG9yaXplZCByZXBsYXkgb2Ygc2Vj
dXJpdHkgdG9rZW5zLiAgT3RoZXIgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgdXNlIG9mIHNl
Y3VyaXR5IHRva2VucyBhcmUgb3V0IG9mIHNjb3BlLiBBbm90aGVyIGdvYWwgb2YgdGhpcyB3b3Jr
aW5nIGdyb3VwIGlzIHRvIGRlc2lnbiB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCBzdWNoIHRo
YXQgaXQgd291bGQgYmUgYWxzbyB1c2VhYmxlIHdpdGggYXBwbGljYXRpb24gcHJvdG9jb2xzIG90
aGVyIHRoYW4gSFRUUFMuICBTcGVjaWZ5aW5nIGFsdGVybmF0ZSBhcHBsaWNhdGlvbiBwcm90b2Nv
bHMgaXMgbm90IGEgcHJpbWFyeSBnb2FsLg0KDQpUaGUgbWFpbiBkZXNpZ24gb2JqZWN0aXZlcyBm
b3IgdGhlIFRva2VuIEJpbmRpbmcgcHJvdG9jb2wsIGluIG5vIHBhcnRpY3VsYXIgb3JkZXI6DQoN
CiM4IC0gc3BlYyBzaG91bGQgcHJvYmFibHkgYmUgc3BlbGxlZCBvdXQgYXMgc3BlY2lmaWNhdGlv
bi4NCg0KVGhhbmtzLA0KS2F0aGxlZW4NCg0KDQpPbiBUdWUsIEphbiAyMCwgMjAxNSBhdCA3OjA3
IFBNLCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4g
SSBiZWxpZXZlIEnigJl2ZSBhZGRyZXNzZWQgdGhlIGZlZWRiYWNrIHJlY2VpdmVkIHNvIGZhcjsg
dGhlIHVwZGF0ZWQgDQo+IGNoYXJ0ZXIgZHJhZnQgaXMgb24gR2l0SHViIGZvciBlYXN5IGF1dGhv
cmluZzoNCj4NCj4gaHR0cHM6Ly9naXRodWIuY29tL1Rva2VuQmluZGluZy9XRy1DaGFydGVyDQo+
DQo+DQo+DQo+IFB1bGwgcmVxdWVzdHMgYXJlIHdlbGNvbWUsDQo+DQo+DQo+DQo+IFRoYW5rcywN
Cj4NCj4NCj4NCj4gQW5kcmVpDQo+DQo+DQo+DQo+IEZyb206IEpvaG4gQnJhZGxleSBbbWFpbHRv
OnZlN2p0YkB2ZTdqdGIuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAxNSwgMjAxNSAx
MjoxNiBQTQ0KPg0KPg0KPiBUbzogQW5kcmVpIFBvcG92DQo+IENjOiB1bmJlYXJhYmxlQGlldGYu
b3JnDQo+IFN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gVXBkYXRlZCBDaGFydGVyIFByb3Bvc2Fs
DQo+DQo+DQo+DQo+IEEgY291cGxlIG1vcmUgcG9zc2libGUgY2xhcmlmaWNhdGlvbnMuDQo+DQo+
DQo+DQo+DQo+DQo+DQo+DQo+IDIuICAgICAgICAgICAgU3BlY2lmeSB0aGUgdXNlIG9mIHRoZSBU
b2tlbiBCaW5kaW5nIHByb3RvY29sIGluIGNvbWJpbmF0aW9uDQo+IHdpdGggSFRUUFMuDQo+DQo+
DQo+DQo+IEhUVFBTIGlzIHByb2JhYmx5IGludGVuZGVkIHRvIGJlIHNob3J0aGFuZCBmb3IgYSBo
dHRwIGJpbmRpbmcgZm9yIFRMUyANCj4gKyB0b2tlbiBCaW5kaW5nIGFzIGlzIGRlZmluZWQgaW4g
IlRva2VuIEJpbmRpbmcgb3ZlciBIVFRQIg0KPiBbaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LWJhbGZhbnotaHR0cHMtdG9rZW4tYmluZGluZy0wMF0uDQo+DQo+DQo+DQo+IFRoaXMg
aXMgYSBiaW5kaW5nIHRvIEhUVFAgKHZpYSBhIG5ldyBoZWFkZXIpIGFuZCB0byBIVE1MICAodmlh
IFhNTCANCj4gSFRUUCByZXF1ZXN0KS4NCj4NCj4NCj4NCj4gSWYgd2UgYWxzbyBzYXkgdGhhdCBw
b3NzaWJsZSBmdXR1cmUgYmluZGluZyBtYXkgYmUgYSBTQVNTTC9HU1MtQVBJIGJpbmRpbmcNCj4g
Zm9yIFRMUyArIHRva2VuIGJpbmRpbmcgICAoVGhlIHNhc3NsLW9hdXRoIHNwZWMNCj4gaHR0cHM6
Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYta2l0dGVuLXNhc2wtb2F1dGgtMTggbWln
aHQgdXNlIA0KPiBzdWNoIGENCj4gdGhpbmcuKQ0KPg0KPg0KPg0KPg0KPg0KPiBPbmUgb3RoZXIg
dGhpbmcgSSBub3RlIGluIHRoZSBkcmFmdHMsIGlzIHRoYXQgYXQgbm8gcG9pbnQgYXJlICB0b2tl
bnMgDQo+IGRlZmluZWQgb3IgZXZlbiByZWFsbHkgZGlzY3Vzc2VkIG90aGVyIHRoYW4gYXMgc29t
ZXRoaW5nIHRoYXQgDQo+IGFwcGxpY2F0aW9ucyBjYW4gYmluZCB0byB0aGUgZXhwb3NlZCBwdWJs
aWMga2V5Lg0KPg0KPiBUaGUgYXBwbGljYXRpb25zIHdpbGwgYmluZCB0b2tlbnMgdG8gdGhlIGtl
eXMgZXhwb3NlZCBieSB0aGUgc3BlY3MgdmlhIHRoZQ0KPiBiaW5kaW5ncy4gICBUaGUgbmFtaW5n
IG1heSBzbGlnaHRseSBtaXNkaXJlY3QgcGVvcGxlLCBidXQgdGhlcmUgaGF2ZSBhbHJlYWR5DQo+
IGJlZW4gdG9vIG1hbnkgbmFtZXMgZm9yIHRoaXMgc28gSSB3b24ndCBwdXNoIHRoZSBwb2ludC4N
Cj4NCj4NCj4NCj4gSSB0aGluayBrZWVwaW5nIHRoaXMgZG93biBjbG9zZSB0byB0aGUgVExTIGxh
eWVyIGFuZCBkZWZpbmluZyBiaW5kaW5ncyANCj4gdG8gSFRUUCBhbmQgb3RoZXIgcHJvdG9jb2xz
IGlzIGluIHNjb3BlLg0KPg0KPiBFbmNvdXJhZ2luZyBhcHBsaWNhdGlvbnMgdGhhdCB1c2UgcHJv
dG9jb2xzIGxpa2UgSFRUUCArIFRMUyB0byB1c2UgdGhlIA0KPiBiaW5kaW5ncyB0byBiaW5kIHRo
ZXJlIHNlY3VyaXR5IHRva2Vucy9jb29raWVzIGlzIGluIHNjb3BlLg0KPg0KPg0KPg0KPiBJIHRo
aW5rIGRlZmluaW5nIHRoZSBleHRlbnNpb25zIGZvciB0aG9zZSBhcHBsaWNhdGlvbnMgdG8gdXNl
IHRoZSANCj4gYmluZGluZ3MgaXMgc2hvdWxkIGJlIHVwIHRvIHRoZSBhcHBsaWNhdGlvbnMgdGhl
bXNlbHZlcyB3aGVyZSB0aGVyZSBpcyANCj4gYWN0aXZlIHBhcnRpY2lwYXRpb24uDQo+DQo+DQo+
DQo+IFRyeWluZyB0byBleHRlbmQgdGhpcyB0byBjb3ZlciBlbmQgdG8gZW5kIG1lc3NhZ2Ugc2ln
bmluZyBvdXRzaWRlIG9mIGEgDQo+IFRMUyBzZXNzaW9uIHNob3VsZCBiZSBleHByZXNzbHkgb3V0
IG9mIHNjb3BlLg0KPg0KPg0KPg0KPiBXZSBtYXkgaG93ZXZlciB3YW50IHRvIHNheSBzb21ldGhp
bmcgYWJvdXQgaG93IGEgVExTIHNlc3Npb24gDQo+IHRlcm1pbmF0ZWQgb24gYSBUTFMgZGV2aWNl
IGNhbiBoYXZlIHRoZSBUb2tlbiBCaW5kaW5nIElEIGZvciB0aGUgDQo+IHNlc3Npb24gcGFzc2Vk
IGluIGEgSFRUUCBoZWFkZXIuDQo+DQo+IFRoYXQgYW5kIHBvc3NpYmx5IHNvbWUgb3RoZXIgVExT
IGFwcGxpYW5jZSBpc3N1ZXMgYXJlIGluIHNjb3BlIGZvciANCj4gIlRva2VuIEJpbmRpbmcgb3Zl
ciBIVFRQIg0KPg0KPg0KPg0KPiBSZWdhcmRzDQo+DQo+IEpvaG4gQi4NCj4NCj4NCj4NCj4NCj4N
Cj4NCj4NCj4gT24gSmFuIDE1LCAyMDE1LCBhdCAzOjUyIFBNLCBBbmRyZWkgUG9wb3YgPEFuZHJl
aS5Qb3BvdkBtaWNyb3NvZnQuY29tPg0KPiB3cm90ZToNCj4NCj4NCj4NCj4gVGhhbmtzIEpvaG47
IGJvdGggc3VnZ2VzdGlvbnMgbWFrZSBzZW5zZSB0byBtZTsgd2lsbCByZXBocmFzZSBpbiB0aGUg
DQo+IG5leHQgcmV2aXNpb24uDQo+DQo+DQo+DQo+IENoZWVycywNCj4NCj4NCj4NCj4gQW5kcmVp
DQo+DQo+DQo+DQo+IEZyb206IEpvaG4gQnJhZGxleSBbbWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29t
XQ0KPiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAxNSwgMjAxNSA5OjI1IEFNDQo+IFRvOiBBbmRy
ZWkgUG9wb3YNCj4gQ2M6IHVuYmVhcmFibGVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtVbmJl
YXJhYmxlXSBVcGRhdGVkIENoYXJ0ZXIgUHJvcG9zYWwNCj4NCj4NCj4NCj4gSSBhbSBnZW5lcmFs
bHkgaW4gYWdyZW1lbnQuDQo+DQo+DQo+DQo+IEEgY291cGxlIG9mIHBvaW50cy4NCj4NCj4NCj4N
Cj4gVW5kZXIgZGVzaWduIGdvYWxzIGNoYW5nZSAxIHRvLg0KPg0KPg0KPg0KPiAxLiAgIEFsbG93
IGFwcGxpY2F0aW9ucyB0byBwcmV2ZW50IHRoZSBleHBvcnQgYW5kIHJlcGxheSBvZiBzZWN1cml0
eSB0b2tlbnMuDQo+DQo+DQo+DQo+IFlvdSBjb3VsZCBtYWtlIHRoYXQgYXBwbGljYXRpb25zIGFu
ZCBwcm90b2NvbHMgaWYgeW91IGxpa2UgYXMgc29tZSANCj4gcGVvcGxlIG1heSBzZWUgdGhpbmdz
IGxpa2UgT0F1dGggYXMgYSBwcm90b2NvbCB2cyBhbiBhcHBsaWNhdGlvbi4NCj4NCj4gVGhlIHBv
aW50IGJlaW5nIHRoYXQgdGhlIGdvYWwgaXMgdG8gcHJvdmlkZSB0aGUgaG9va3MgZm9yIHRoaW5n
cyBhIA0KPiBsYXllciBhYm92ZSB0aGVzZSBzcGVjaWZpY2F0aW9ucyB0byBtYWtlIHNlY3VyaXR5
IGRlY2lzaW9ucywgbm90IHRoZSANCj4gdG9rZW4gYmluZGluZyBwcm90b2NvbCBpdHNlbGYuDQo+
DQo+DQo+DQo+DQo+DQo+IEluIDMgeW91IHVzZSB0aGUgdGVybSBmZWRlcmF0aW9uLiAgVGhhdCBt
YXkgYmUgbGFyZ2VyIGluIHNjb3BlIHRoYW4gDQo+IHdoYXQgSSB0aGluayB5b3UgaW50ZW5kIGZy
b20gdGhlIHR3byBkcmFmdHMuDQo+DQo+IEZlZGVyYXRpb24gaXMgYSBtdWNoIGxhcmdlciB0b3Bp
YyB0aGFuIGFsbG93aW5nIHRoZSBwdWJsaWMga2V5IGZyb20gDQo+IG9uZSBjb25uZWN0aW9uIHRv
IGJlIGV4cG9zZWQgaW4gYSBjb25uZWN0aW9uIHRvIGEgc2Vjb25kIHBhcnR5IHZpYSANCj4gc29t
ZSBzb3J0IG9mIGV4cHJlc3MgY29uc2VudCBmcm9tIHRoZSBmaXJzdCBwYXJ0eS4NCj4NCj4NCj4N
Cj4gU2hyaW5raW5nIHRoZSBzY29wZSB0byBob3cgcHVibGljIGtleXMgbWF5IGJlIHNoYXJlZCB3
aXRoIHBlcm1pc3Npb24gDQo+IHRvIHRoaXJkIHBhcnRpZXMgbWF5IG1ha2Ugc29tZSBwZW9wbGUg
bW9yZSBjb21mb3J0YWJsZSwgaWYgdGhleSBhcmUgDQo+IGNvbmNlcm5lZCB0aGF0IHRoaXMgaXMg
dHJ5aW5nIHRvIGJlIGEgbmV3IGZlZGVyYXRpb24gcHJvdG9jb2wgdG8gDQo+IGNvbXBldGUgd2l0
aCBTQU1MIG9yIE9BdXRoLg0KPg0KPg0KPg0KPiBSZWdhcmRzDQo+DQo+IEpvaG4gQi4NCj4NCj4N
Cj4NCj4gT24gSmFuIDE0LCAyMDE1LCBhdCA5OjE0IFBNLCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Q
b3BvdkBtaWNyb3NvZnQuY29tPg0KPiB3cm90ZToNCj4NCj4NCj4NCj4gVGhlIGRpc2N1c3Npb24g
b24gdGhpcyBtYWlsaW5nIGxpc3QgaGFzIHN1YnNpZGVkIG92ZXIgdGhlIGhvbGlkYXlzLCBzbyAN
Cj4gSSBsb29rZWQgdGhyb3VnaCB0aGUgbWVzc2FnZXMgZm9yIGZlZWRiYWNrIHJlZ2FyZGluZyB0
aGUgcHJvcG9zZWQgDQo+IGNoYXJ0ZXIgYW5kIGluY29ycG9yYXRlZCBhIGNvdXBsZSBvZiBjaGFu
Z2VzIHN1Z2dlc3RlZCBzbyBmYXI6DQo+DQo+IDEuIEEgbmV3IGRlc2lnbiBnb2FsOiB0aGUgc29s
dXRpb24gbXVzdCB3b3JrIGZvciBXZWIgYnJvd3NlcnMuIEUuZy4gDQo+IHRoaXMgbWVhbnMgdGhh
dCBzZWN1cml0eSB0b2tlbnMgbXVzdCBiZSBwcmVzZW50YWJsZSBvdmVyIG11bHRpcGxlIFRMUyAN
Cj4gc2Vzc2lvbnMgYW5kIGNvbm5lY3Rpb25zLg0KPg0KPiAyLiBSZW1vdmVkIHNwZWNpZmljIG1p
bGVzdG9uZSBkYXRlcy4NCj4NCj4NCj4NCj4gTG9va2luZyBmb3J3YXJkIHRvIG1vcmUgZGlzY3Vz
c2lvbiBvZiB0aGUgY2hhcnRlciwNCj4NCj4NCj4NCj4gVGhhbmtzLA0KPg0KPg0KPg0KPiBBbmRy
ZWkNCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCj4NCj4gVG9rZW4gQmluZGluZyAoVEIpDQo+DQo+DQo+DQo+IENoYXJ0ZXIg
Zm9yIFdvcmtpbmcgR3JvdXANCj4NCj4NCj4NCj4gV2ViIHNlcnZpY2VzIGdlbmVyYXRlIHZhcmlv
dXMgc2VjdXJpdHkgdG9rZW5zIChlLmcuICBIVFRQIGNvb2tpZXMsIA0KPiBPQXV0aCB0b2tlbnMs
IGV0Yy4pIGZvciB3ZWIgYXBwbGljYXRpb25zIHRvIGFjY2VzcyBwcm90ZWN0ZWQgDQo+IHJlc291
cmNlcy4gQ3VycmVudGx5IHRoZXNlIGFyZSBiZWFyZXIgdG9rZW5zLCBpLmUuIGFueSBwYXJ0eSBp
biANCj4gcG9zc2Vzc2lvbiBvZiBzdWNoIHRva2VuIGdhaW5zIGFjY2VzcyB0byB0aGUgcHJvdGVj
dGVkIHJlc291cmNlLiANCj4gQXR0YWNrZXJzIGV4cG9ydCBiZWFyZXIgdG9rZW5zIGZyb20gY2xp
ZW50IG1hY2hpbmVzIG9yIGZyb20gDQo+IGNvbXByb21pc2VkIG5ldHdvcmsgY29ubmVjdGlvbnMs
IHByZXNlbnQgdGhlc2UgYmVhcmVyIHRva2VucyB0byBXZWIgDQo+IHNlcnZpY2VzLCBhbmQgaW1w
ZXJzb25hdGUgYXV0aGVudGljYXRlZCB1c2Vycy4gVGhlIGlkZWEgb2YgVG9rZW4gDQo+IEJpbmRp
bmcgaXMgdG8gZW5hYmxlIGRlZmVuc2UgYWdhaW5zdCBzdWNoIGF0dGFja3MgYnkgY3J5cHRvZ3Jh
cGhpY2FsbHkgYmluZGluZyBzZWN1cml0eSB0b2tlbnMgdG8gdGhlIFRMUyBsYXllci4NCj4NCj4N
Cj4NCj4gVGhlIHRhc2tzIG9mIHRoaXMgd29ya2luZyBncm91cCBhcmUgYXMgZm9sbG93czoNCj4N
Cj4gMS4gICAgICAgICAgICBTcGVjaWZ5IHRoZSBUb2tlbiBCaW5kaW5nIHByb3RvY29sIHYxLjAu
DQo+DQo+IDIuICAgICAgICAgICAgU3BlY2lmeSB0aGUgdXNlIG9mIHRoZSBUb2tlbiBCaW5kaW5n
IHByb3RvY29sIGluIGNvbWJpbmF0aW9uDQo+IHdpdGggSFRUUFMuDQo+DQo+DQo+DQo+IEl0IGlz
IGEgZ29hbCBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAgdG8gZW5hYmxlIGRlZmVuc2UgYWdhaW5zdCBh
dHRhY2tzIA0KPiB0aGF0IGludm9sdmUgdW5hdXRob3JpemVkIHJlcGxheSBvZiBzZWN1cml0eSB0
b2tlbnMsIGJ1dCBvdGhlciBpc3N1ZXMgDQo+IGFzc29jaWF0ZWQgd2l0aCB0aGUgdXNlIG9mIHNl
Y3VyaXR5IHRva2VucyBhcmUgb3V0IG9mIHNjb3BlLiBJdCBpcyBhIA0KPiBnb2FsIG9mIHRoaXMg
d29ya2luZyBncm91cCB0byBkZXNpZ24gdGhlIFRva2VuIEJpbmRpbmcgcHJvdG9jb2wgc3VjaCAN
Cj4gdGhhdCBpdCB3b3VsZCBiZSBhbHNvIHVzZWFibGUgd2l0aCBhcHBsaWNhdGlvbiBwcm90b2Nv
bHMgb3RoZXIgdGhhbiANCj4gSFRUUFMsIGhvd2V2ZXIgc3BlY2lmeWluZyBzdWNoIHVzZXMgaXMg
bm90IGEgcHJpbWFyeSBnb2FsLg0KPg0KPg0KPg0KPiBTb21lIG9mIHRoZSBtYWluIGRlc2lnbiBn
b2FscyBmb3IgdGhlIFRva2VuIEJpbmRpbmcgcHJvdG9jb2wsIGluIG5vIA0KPiBwYXJ0aWN1bGFy
IG9yZGVyOg0KPg0KPiAxLiAgICAgICAgICAgIFByZXZlbnQgZXhwb3J0IGFuZCByZXBsYXkgb2Yg
c2VjdXJpdHkgdG9rZW5zLg0KPg0KPiAyLiAgICAgICAgICAgIEFsbG93IHN0cm9uZyBrZXkgcHJv
dGVjdGlvbiwgZS5nLiB1c2luZyBoYXJkd2FyZS1ib3VuZCBrZXlzLg0KPg0KPiAzLiAgICAgICAg
ICAgIFN1cHBvcnQgYm90aCBmaXJzdC1wYXJ0eSBhbmQgZmVkZXJhdGlvbiBzY2VuYXJpb3MuDQo+
DQo+IDQuICAgICAgICAgICAgUHJlc2VydmUgdXNlciBwcml2YWN5Lg0KPg0KPiA1LiAgICAgICAg
ICAgIE1ha2UgdGhlIFRva2VuIEJpbmRpbmcgcHJvdG9jb2wgdXNlYWJsZSBpbiBjb21iaW5hdGlv
biB3aXRoIGENCj4gdmFyaWV0eSBvZiBhcHBsaWNhdGlvbiBwcm90b2NvbHMuDQo+DQo+IDYuICAg
ICAgICAgICAgQWxsb3cgdGhlIG5lZ290aWF0aW9uIG9mIHRoZSBUb2tlbiBCaW5kaW5nIHByb3Rv
Y29sIHdpdGhvdXQNCj4gYWRkaXRpb25hbCByb3VuZC10cmlwcy4NCj4NCj4gNy4gICAgICAgICAg
ICBBbGxvdyB0aGUgdXNlIG9mIG11bHRpcGxlIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcywgc28g
dGhhdCBhDQo+IHZhcmlldHkgb2Ygc2VjdXJlIGhhcmR3YXJlIG1vZHVsZXMgd2l0aCBkaWZmZXJl
bnQgY3J5cHRvZ3JhcGhpYyANCj4gY2FwYWJpbGl0aWVzIGNvdWxkIGJlIHVzZWQgd2l0aCBUb2tl
biBCaW5kaW5nLg0KPg0KPiA4LiAgICAgICAgICAgIFByb3Bvc2UgVG9rZW4gQmluZGluZyBzcGVj
IHRoYXQgY2FuIGJlIGltcGxlbWVudGVkIGluIFdlYg0KPiBicm93c2VycyAoYnV0IGlzIG5vdCBs
aW1pdGVkIHRvIHRoZW0pLiBFLmcuIFdlYiBicm93c2VycyByZXF1aXJlIHRoYXQgDQo+IHRoZSBz
YW1lIGJvdW5kIHNlY3VyaXR5IHRva2VuIG11c3QgYmUgcHJlc2VudGFibGUgb3ZlciBtdWx0aXBs
ZSBUTFMgDQo+IHNlc3Npb25zIGFuZCBjb25uZWN0aW9ucy4NCj4NCj4NCj4NCj4gVGhlIHdvcmtp
bmcgZ3JvdXAgd2lsbCB1c2UgdGhlIGZvbGxvd2luZyBkb2N1bWVudHMgYXMgYSBzdGFydGluZyBw
b2ludCANCj4gZm9yIGl0cyB3b3JrOg0KPg0KPiAtICAgICAgICAgICAgIGRyYWZ0LXBvcG92LXRv
a2VuLWJpbmRpbmctMDA7DQo+DQo+IC0gICAgICAgICAgICAgZHJhZnQtYmFsZmFuei1odHRwcy10
b2tlbi1iaW5kaW5nLTAwLg0KPg0KPg0KPg0KPiBUaGlzIFdHIHdpbGwgY29sbGFib3JhdGUgd2l0
aCBvdGhlciBJRVRGIFdHcywgaW4gcGFydGljdWxhciB3aXRoIHRoZSANCj4gVExTLCBIVFRQYmlz
IGFuZCBPYXV0aCBXR3MuDQo+DQo+DQo+DQo+IE1pbGVzdG9uZXM6DQo+DQo+IC0gICAgICAgICAg
ICBXRyBkb2N1bWVudCBmb3IgdGhlIFRva2VuIEJpbmRpbmcgUHJvdG9jb2wgdjEuMC4NCj4NCj4g
LSAgICAgICAgICAgIFdHIGRvY3VtZW50IGZvciBIVFRQUyBUb2tlbiBCaW5kaW5nLg0KPg0KPiAt
ICAgICAgICAgICAgVG9rZW4gQmluZGluZyBQcm90b2NvbCB2MS4wIHRvIElFU0cuDQo+DQo+IC0g
ICAgICAgICAgICBIVFRQUyBUb2tlbiBCaW5kaW5nIHRvIElFU0cuDQo+DQo+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFVuYmVhcmFibGUgbWFpbGlu
ZyBsaXN0DQo+IFVuYmVhcmFibGVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQo+DQo+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFVuYmVhcmFibGUgbWFpbGluZyBsaXN0
DQo+IFVuYmVhcmFibGVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby91bmJlYXJhYmxlDQo+DQoNCg0KDQotLSANCg0KQmVzdCByZWdhcmRzLA0KS2F0aGxl
ZW4NCg==


From nobody Mon Jan 26 17:08:35 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889201A1AB1 for ; Mon, 26 Jan 2015 17:08:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 iZN7spiKeMuL for ; Mon, 26 Jan 2015 17:08:29 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0143.outbound.protection.outlook.com [65.55.169.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94C531A1A82 for ; Mon, 26 Jan 2015 17:08:28 -0800 (PST)
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1251.namprd03.prod.outlook.com (25.161.207.27) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 01:08:26 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0065.013; Tue, 27 Jan 2015 01:08:26 +0000
From: Andrei Popov 
To: Bill Mills , Stephen Farrell , Kathleen Moriarty 
Thread-Topic: [Unbearable] Updated Charter Proposal
Thread-Index: AdAwVoQybrCT+HkuTniRvdMsDdHeWgAkZqIAAAL3ZlAAAwXvAAEDcGvAAMwnb4AAALRNgAAAnOkAAGI6TVA=
Date: Tue, 27 Jan 2015 01:08:26 +0000
Message-ID: 
References: <54C44BD9.6010507@cs.tcd.ie> <1028652913.19992.1422151670194.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <1028652913.19992.1422151670194.JavaMail.yahoo@mail.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::3]
authentication-results: yahoo.com; dkim=none (message not signed) header.d=none;yahoo.com; dmarc=none action=none header.from=microsoft.com;
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN3PR0301MB1251;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1251; 
x-forefront-prvs: 046985391D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(51704005)(479174004)(164054003)(54356999)(76176999)(2420400003)(15975445007)(54206007)(19609705001)(102836002)(2900100001)(86362001)(2656002)(92566002)(74316001)(19300405004)(2950100001)(19580405001)(19580395003)(19617315012)(33656002)(19625215002)(86612001)(561944003)(40100003)(87936001)(76576001)(122556002)(99286002)(50986999)(2521001)(16236675004)(46102003)(54606007)(62966003)(77156002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1251; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB12508BBF5AD6AEE7AFA34ADB8C320BN3PR0301MB1250_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2015 01:08:26.3551 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1251
Archived-At: 
Cc: John Bradley , "unbearable@ietf.org" 
Subject: Re: [Unbearable] Updated Charter Proposal
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 01:08:34 -0000

--_000_BN3PR0301MB12508BBF5AD6AEE7AFA34ADB8C320BN3PR0301MB1250_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QWZ0ZXIgY2hhdHRpbmcgd2l0aCBCaWxsIG9mZi1saXN0LCBoZXJlIGlzIHRoZSBzcGVjaWZpYyBj
aGFuZ2UgcHJvcG9zZWQuDQoNClRoZSBjaGFydGVyIGRyYWZ0IGN1cnJlbnRseSBzYXlzOg0K4oCc
VG9rZW4gQmluZGluZyBlbmFibGVzIGRlZmVuc2UgYWdhaW5zdCBzdWNoIGF0dGFja3MgYnkgY3J5
cHRvZ3JhcGhpY2FsbHkgYmluZGluZyBzZWN1cml0eSB0b2tlbnMgdG8gdGhlIFRMUyBsYXllci7i
gJwNCg0KVGhlIHByb3Bvc2VkIHRleHQ6DQrigJxUb2tlbiBCaW5kaW5nIGVuYWJsZXMgZGVmZW5z
ZSBhZ2FpbnN0IHN1Y2ggYXR0YWNrcyBieSBjcnlwdG9ncmFwaGljYWxseSBiaW5kaW5nIHNlY3Vy
aXR5IHRva2VucyB0byBhIHNlY3JldCBoZWxkIGJ5IHRoZSBjbGllbnQu4oCcDQoNCklmIHRoZSBt
YWlsaW5nIGxpc3QgaXMgT0sgd2l0aCB0aGlzIGNoYW5nZSwgSeKAmWxsIGdvIGFoZWFkIGFuZCB1
cGRhdGUgdGhlIGNoYXJ0ZXIgZHJhZnQuDQoNClRoYW5rcywNCg0KQW5kcmVpDQoNCkZyb206IEJp
bGwgTWlsbHMgW21haWx0bzp3bWlsbHNfOTIxMDVAeWFob28uY29tXQ0KU2VudDogU2F0dXJkYXks
IEphbnVhcnkgMjQsIDIwMTUgNjowOCBQTQ0KVG86IFN0ZXBoZW4gRmFycmVsbDsgS2F0aGxlZW4g
TW9yaWFydHk7IEFuZHJlaSBQb3Bvdg0KQ2M6IEpvaG4gQnJhZGxleTsgdW5iZWFyYWJsZUBpZXRm
Lm9yZw0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBVcGRhdGVkIENoYXJ0ZXIgUHJvcG9zYWwN
Cg0KTXkgaXNzdWUgaXMgYWdhaW4gd2l0aCB0aGUgdGV4dCAiYmluZGluZyB0byB0aGUgVExTIGxh
eWVyIiwgdGhhdCdzIGNoYW5uZWwgYmluZGluZy4NCg0KT24gU2F0dXJkYXksIEphbnVhcnkgMjQs
IDIwMTUgNTo1MCBQTSwgU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmll
PG1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPj4gd3JvdGU6DQoNCg0KQ2hlZXJzLA0K
DQpFZGl0aW5nIHdpbGwgZW5zdWU6LSkNCg0KUw0KDQpPbiAyNS8wMS8xNSAwMTozMCwgS2F0aGxl
ZW4gTW9yaWFydHkgd3JvdGU6DQo+IEhpLA0KPg0KPiBUaGUgY2hhcnRlciBsb29rcyBsaWtlIGl0
IGlzIHNoYXBpbmcgdXAuICBJIGp1c3QgaGF2ZSBzb21lIGVkaXRvcmlhbA0KPiBzdWdnZXN0aW9u
cyBhcyB0aGUgZGlzY3Vzc2lvbiBjb250aW51ZXMsIHRha2UgdGhlbSBvciBsZWF2ZSB0aGVtLCBu
b3QNCj4gYSBiaWcgZGVhbC4NCj4NCj4gU3VnZ2VzdCBjaGFuZ2luZyBmcm9tOg0KPiBUaGUgaWRl
YSBvZiBUb2tlbiBCaW5kaW5nIGlzIHRvIGVuYWJsZSBkZWZlbnNlIGFnYWluc3Qgc3VjaCBhdHRh
Y2tzIGJ5DQo+IGNyeXB0b2dyYXBoaWNhbGx5IGJpbmRpbmcNCj4gc2VjdXJpdHkgdG9rZW5zIHRv
IHRoZSBUTFMgbGF5ZXIuDQo+DQo+IFRvOg0KPiBUb2tlbiBCaW5kaW5nIGVuYWJsZXMgZGVmZW5z
ZSBhZ2FpbnN0IHN1Y2ggYXR0YWNrcyBieSBjcnlwdG9ncmFwaGljYWxseSBiaW5kaW5nDQo+IHNl
Y3VyaXR5IHRva2VucyB0byB0aGUgVExTIGxheWVyLg0KPg0KPiBUaGUgd29yZCBnb2FsIGlzIHVz
ZWQgYSBiaXQgbXVjaCwgYnV0IHRoaXMgaXMgYSBwZXJzb25hbCBwcmVmZXJlbmNlIC0NCj4gdGFr
ZSBvciBsZWF2ZSB0aGUgc3VnZ2VzdGlvbnMuICBJIHN1Z2dlc3QgcmVtb3ZpbmcgIlNvbWUiIGlu
IHRoZSBsYXN0DQo+IHNlbnRlbmNlIGxpc3RlZCBhcyB0aGlzIG9ubHkgc2F5cyB0aGUgIm1haW4i
IGdvYWxzL29iamVjdGl2ZXMsIHNvDQo+IHRoZXJlIGlzIHdpZ2dsZSByb29tIHN0aWxsLg0KPg0K
PiBGcm9tOg0KPiBJdCBpcyBhIGdvYWwgb2YgdGhpcyB3b3JraW5nIGdyb3VwIHRvIGVuYWJsZSBk
ZWZlbnNlIGFnYWluc3QgYXR0YWNrcw0KPiB0aGF0IGludm9sdmUgdW5hdXRob3JpemVkIHJlcGxh
eSBvZg0KPiBzZWN1cml0eSB0b2tlbnMsIGJ1dCBvdGhlciBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRo
IHRoZSB1c2Ugb2Ygc2VjdXJpdHkNCj4gdG9rZW5zIGFyZSBvdXQgb2Ygc2NvcGUuIEl0IGlzIGEg
Z29hbA0KPiBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAgdG8gZGVzaWduIHRoZSBUb2tlbiBCaW5kaW5n
IHByb3RvY29sIHN1Y2ggdGhhdA0KPiBpdCB3b3VsZCBiZSBhbHNvIHVzZWFibGUgd2l0aA0KPiBh
cHBsaWNhdGlvbiBwcm90b2NvbHMgb3RoZXIgdGhhbiBIVFRQUywgaG93ZXZlciBzcGVjaWZ5aW5n
IHN1Y2ggdXNlcw0KPiBpcyBub3QgYSBwcmltYXJ5IGdvYWwuDQo+DQo+IFNvbWUgb2YgdGhlIG1h
aW4gZGVzaWduIGdvYWxzIGZvciB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCwgaW4gbm8NCj4g
cGFydGljdWxhciBvcmRlcjoNCj4NCj4gVG86DQo+IEl0IGlzIGEgZ29hbCBvZiB0aGlzIHdvcmtp
bmcgZ3JvdXAgdG8gZW5hYmxlIGRlZmVuc2UgYWdhaW5zdCBhdHRhY2tzDQo+IHRoYXQgaW52b2x2
ZSB1bmF1dGhvcml6ZWQgcmVwbGF5IG9mDQo+IHNlY3VyaXR5IHRva2Vucy4gIE90aGVyIGlzc3Vl
cyBhc3NvY2lhdGVkIHdpdGggdGhlIHVzZSBvZiBzZWN1cml0eQ0KPiB0b2tlbnMgYXJlIG91dCBv
ZiBzY29wZS4gQW5vdGhlciBnb2FsDQo+IG9mIHRoaXMgd29ya2luZyBncm91cCBpcyB0byBkZXNp
Z24gdGhlIFRva2VuIEJpbmRpbmcgcHJvdG9jb2wgc3VjaA0KPiB0aGF0IGl0IHdvdWxkIGJlIGFs
c28gdXNlYWJsZSB3aXRoDQo+IGFwcGxpY2F0aW9uIHByb3RvY29scyBvdGhlciB0aGFuIEhUVFBT
LiAgU3BlY2lmeWluZyBhbHRlcm5hdGUNCj4gYXBwbGljYXRpb24gcHJvdG9jb2xzIGlzIG5vdCBh
IHByaW1hcnkgZ29hbC4NCj4NCj4gVGhlIG1haW4gZGVzaWduIG9iamVjdGl2ZXMgZm9yIHRoZSBU
b2tlbiBCaW5kaW5nIHByb3RvY29sLCBpbiBubw0KPiBwYXJ0aWN1bGFyIG9yZGVyOg0KPg0KPiAj
OCAtIHNwZWMgc2hvdWxkIHByb2JhYmx5IGJlIHNwZWxsZWQgb3V0IGFzIHNwZWNpZmljYXRpb24u
DQo+DQo+IFRoYW5rcywNCj4gS2F0aGxlZW4NCj4NCj4NCj4gT24gVHVlLCBKYW4gMjAsIDIwMTUg
YXQgNzowNyBQTSwgQW5kcmVpIFBvcG92DQo+IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxt
YWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCj4+IEkgYmVsaWV2ZSBJ
4oCZdmUgYWRkcmVzc2VkIHRoZSBmZWVkYmFjayByZWNlaXZlZCBzbyBmYXI7IHRoZSB1cGRhdGVk
IGNoYXJ0ZXINCj4+IGRyYWZ0IGlzIG9uIEdpdEh1YiBmb3IgZWFzeSBhdXRob3Jpbmc6DQo+Pg0K
Pj4gaHR0cHM6Ly9naXRodWIuY29tL1Rva2VuQmluZGluZy9XRy1DaGFydGVyDQo+Pg0KPj4NCj4+
DQo+PiBQdWxsIHJlcXVlc3RzIGFyZSB3ZWxjb21lLA0KPj4NCj4+DQo+Pg0KPj4gVGhhbmtzLA0K
Pj4NCj4+DQo+Pg0KPj4gQW5kcmVpDQo+Pg0KPj4NCj4+DQo+PiBGcm9tOiBKb2huIEJyYWRsZXkg
W21haWx0bzp2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20+XQ0KPj4g
U2VudDogVGh1cnNkYXksIEphbnVhcnkgMTUsIDIwMTUgMTI6MTYgUE0NCj4+DQo+Pg0KPj4gVG86
IEFuZHJlaSBQb3Bvdg0KPj4gQ2M6IHVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOnVuYmVhcmFi
bGVAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFVwZGF0ZWQgQ2hhcnRl
ciBQcm9wb3NhbA0KPj4NCj4+DQo+Pg0KPj4gQSBjb3VwbGUgbW9yZSBwb3NzaWJsZSBjbGFyaWZp
Y2F0aW9ucy4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PiAyLiAgICAgICAgICAgIFNw
ZWNpZnkgdGhlIHVzZSBvZiB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCBpbiBjb21iaW5hdGlv
bg0KPj4gd2l0aCBIVFRQUy4NCj4+DQo+Pg0KPj4NCj4+IEhUVFBTIGlzIHByb2JhYmx5IGludGVu
ZGVkIHRvIGJlIHNob3J0aGFuZCBmb3IgYSBodHRwIGJpbmRpbmcgZm9yIFRMUyArDQo+PiB0b2tl
biBCaW5kaW5nIGFzIGlzIGRlZmluZWQgaW4gIlRva2VuIEJpbmRpbmcgb3ZlciBIVFRQIg0KPj4g
W2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iYWxmYW56LWh0dHBzLXRva2VuLWJp
bmRpbmctMDBdLg0KPj4NCj4+DQo+Pg0KPj4gVGhpcyBpcyBhIGJpbmRpbmcgdG8gSFRUUCAodmlh
IGEgbmV3IGhlYWRlcikgYW5kIHRvIEhUTUwgICh2aWEgWE1MIEhUVFANCj4+IHJlcXVlc3QpLg0K
Pj4NCj4+DQo+Pg0KPj4gSWYgd2UgYWxzbyBzYXkgdGhhdCBwb3NzaWJsZSBmdXR1cmUgYmluZGlu
ZyBtYXkgYmUgYSBTQVNTTC9HU1MtQVBJIGJpbmRpbmcNCj4+IGZvciBUTFMgKyB0b2tlbiBiaW5k
aW5nICAoVGhlIHNhc3NsLW9hdXRoIHNwZWMNCj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1pZXRmLWtpdHRlbi1zYXNsLW9hdXRoLTE4IG1pZ2h0IHVzZSBzdWNoIGENCj4+IHRo
aW5nLikNCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gT25lIG90aGVyIHRoaW5nIEkgbm90ZSBpbiB0
aGUgZHJhZnRzLCBpcyB0aGF0IGF0IG5vIHBvaW50IGFyZSAgdG9rZW5zDQo+PiBkZWZpbmVkIG9y
IGV2ZW4gcmVhbGx5IGRpc2N1c3NlZCBvdGhlciB0aGFuIGFzIHNvbWV0aGluZyB0aGF0IGFwcGxp
Y2F0aW9ucw0KPj4gY2FuIGJpbmQgdG8gdGhlIGV4cG9zZWQgcHVibGljIGtleS4NCj4+DQo+PiBU
aGUgYXBwbGljYXRpb25zIHdpbGwgYmluZCB0b2tlbnMgdG8gdGhlIGtleXMgZXhwb3NlZCBieSB0
aGUgc3BlY3MgdmlhIHRoZQ0KPj4gYmluZGluZ3MuICBUaGUgbmFtaW5nIG1heSBzbGlnaHRseSBt
aXNkaXJlY3QgcGVvcGxlLCBidXQgdGhlcmUgaGF2ZSBhbHJlYWR5DQo+PiBiZWVuIHRvbyBtYW55
IG5hbWVzIGZvciB0aGlzIHNvIEkgd29uJ3QgcHVzaCB0aGUgcG9pbnQuDQo+Pg0KPj4NCj4+DQo+
PiBJIHRoaW5rIGtlZXBpbmcgdGhpcyBkb3duIGNsb3NlIHRvIHRoZSBUTFMgbGF5ZXIgYW5kIGRl
ZmluaW5nIGJpbmRpbmdzIHRvDQo+PiBIVFRQIGFuZCBvdGhlciBwcm90b2NvbHMgaXMgaW4gc2Nv
cGUuDQo+Pg0KPj4gRW5jb3VyYWdpbmcgYXBwbGljYXRpb25zIHRoYXQgdXNlIHByb3RvY29scyBs
aWtlIEhUVFAgKyBUTFMgdG8gdXNlIHRoZQ0KPj4gYmluZGluZ3MgdG8gYmluZCB0aGVyZSBzZWN1
cml0eSB0b2tlbnMvY29va2llcyBpcyBpbiBzY29wZS4NCj4+DQo+Pg0KPj4NCj4+IEkgdGhpbmsg
ZGVmaW5pbmcgdGhlIGV4dGVuc2lvbnMgZm9yIHRob3NlIGFwcGxpY2F0aW9ucyB0byB1c2UgdGhl
IGJpbmRpbmdzDQo+PiBpcyBzaG91bGQgYmUgdXAgdG8gdGhlIGFwcGxpY2F0aW9ucyB0aGVtc2Vs
dmVzIHdoZXJlIHRoZXJlIGlzIGFjdGl2ZQ0KPj4gcGFydGljaXBhdGlvbi4NCj4+DQo+Pg0KPj4N
Cj4+IFRyeWluZyB0byBleHRlbmQgdGhpcyB0byBjb3ZlciBlbmQgdG8gZW5kIG1lc3NhZ2Ugc2ln
bmluZyBvdXRzaWRlIG9mIGEgVExTDQo+PiBzZXNzaW9uIHNob3VsZCBiZSBleHByZXNzbHkgb3V0
IG9mIHNjb3BlLg0KPj4NCj4+DQo+Pg0KPj4gV2UgbWF5IGhvd2V2ZXIgd2FudCB0byBzYXkgc29t
ZXRoaW5nIGFib3V0IGhvdyBhIFRMUyBzZXNzaW9uIHRlcm1pbmF0ZWQgb24gYQ0KPj4gVExTIGRl
dmljZSBjYW4gaGF2ZSB0aGUgVG9rZW4gQmluZGluZyBJRCBmb3IgdGhlIHNlc3Npb24gcGFzc2Vk
IGluIGEgSFRUUA0KPj4gaGVhZGVyLg0KPj4NCj4+IFRoYXQgYW5kIHBvc3NpYmx5IHNvbWUgb3Ro
ZXIgVExTIGFwcGxpYW5jZSBpc3N1ZXMgYXJlIGluIHNjb3BlIGZvciAiVG9rZW4NCj4+IEJpbmRp
bmcgb3ZlciBIVFRQIg0KPj4NCj4+DQo+Pg0KPj4gUmVnYXJkcw0KPj4NCj4+IEpvaG4gQi4NCj4+
DQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+PiBPbiBKYW4gMTUsIDIwMTUsIGF0IDM6NTIgUE0s
IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Q
b3BvdkBtaWNyb3NvZnQuY29tPj4NCj4+IHdyb3RlOg0KPj4NCj4+DQo+Pg0KPj4gVGhhbmtzIEpv
aG47IGJvdGggc3VnZ2VzdGlvbnMgbWFrZSBzZW5zZSB0byBtZTsgd2lsbCByZXBocmFzZSBpbiB0
aGUgbmV4dA0KPj4gcmV2aXNpb24uDQo+Pg0KPj4NCj4+DQo+PiBDaGVlcnMsDQo+Pg0KPj4NCj4+
DQo+PiBBbmRyZWkNCj4+DQo+Pg0KPj4NCj4+IEZyb206IEpvaG4gQnJhZGxleSBbbWFpbHRvOnZl
N2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT5dDQo+PiBTZW50OiBUaHVy
c2RheSwgSmFudWFyeSAxNSwgMjAxNSA5OjI1IEFNDQo+PiBUbzogQW5kcmVpIFBvcG92DQo+PiBD
YzogdW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZz4NCj4+IFN1
YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gVXBkYXRlZCBDaGFydGVyIFByb3Bvc2FsDQo+Pg0KPj4N
Cj4+DQo+PiBJIGFtIGdlbmVyYWxseSBpbiBhZ3JlbWVudC4NCj4+DQo+Pg0KPj4NCj4+IEEgY291
cGxlIG9mIHBvaW50cy4NCj4+DQo+Pg0KPj4NCj4+IFVuZGVyIGRlc2lnbiBnb2FscyBjaGFuZ2Ug
MSB0by4NCj4+DQo+Pg0KPj4NCj4+IDEuICBBbGxvdyBhcHBsaWNhdGlvbnMgdG8gcHJldmVudCB0
aGUgZXhwb3J0IGFuZCByZXBsYXkgb2Ygc2VjdXJpdHkgdG9rZW5zLg0KPj4NCj4+DQo+Pg0KPj4g
WW91IGNvdWxkIG1ha2UgdGhhdCBhcHBsaWNhdGlvbnMgYW5kIHByb3RvY29scyBpZiB5b3UgbGlr
ZSBhcyBzb21lIHBlb3BsZQ0KPj4gbWF5IHNlZSB0aGluZ3MgbGlrZSBPQXV0aCBhcyBhIHByb3Rv
Y29sIHZzIGFuIGFwcGxpY2F0aW9uLg0KPj4NCj4+IFRoZSBwb2ludCBiZWluZyB0aGF0IHRoZSBn
b2FsIGlzIHRvIHByb3ZpZGUgdGhlIGhvb2tzIGZvciB0aGluZ3MgYSBsYXllcg0KPj4gYWJvdmUg
dGhlc2Ugc3BlY2lmaWNhdGlvbnMgdG8gbWFrZSBzZWN1cml0eSBkZWNpc2lvbnMsIG5vdCB0aGUg
dG9rZW4gYmluZGluZw0KPj4gcHJvdG9jb2wgaXRzZWxmLg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+
PiBJbiAzIHlvdSB1c2UgdGhlIHRlcm0gZmVkZXJhdGlvbi4gIFRoYXQgbWF5IGJlIGxhcmdlciBp
biBzY29wZSB0aGFuIHdoYXQgSQ0KPj4gdGhpbmsgeW91IGludGVuZCBmcm9tIHRoZSB0d28gZHJh
ZnRzLg0KPj4NCj4+IEZlZGVyYXRpb24gaXMgYSBtdWNoIGxhcmdlciB0b3BpYyB0aGFuIGFsbG93
aW5nIHRoZSBwdWJsaWMga2V5IGZyb20gb25lDQo+PiBjb25uZWN0aW9uIHRvIGJlIGV4cG9zZWQg
aW4gYSBjb25uZWN0aW9uIHRvIGEgc2Vjb25kIHBhcnR5IHZpYSBzb21lIHNvcnQgb2YNCj4+IGV4
cHJlc3MgY29uc2VudCBmcm9tIHRoZSBmaXJzdCBwYXJ0eS4NCj4+DQo+Pg0KPj4NCj4+IFNocmlu
a2luZyB0aGUgc2NvcGUgdG8gaG93IHB1YmxpYyBrZXlzIG1heSBiZSBzaGFyZWQgd2l0aCBwZXJt
aXNzaW9uIHRvDQo+PiB0aGlyZCBwYXJ0aWVzIG1heSBtYWtlIHNvbWUgcGVvcGxlIG1vcmUgY29t
Zm9ydGFibGUsIGlmIHRoZXkgYXJlIGNvbmNlcm5lZA0KPj4gdGhhdCB0aGlzIGlzIHRyeWluZyB0
byBiZSBhIG5ldyBmZWRlcmF0aW9uIHByb3RvY29sIHRvIGNvbXBldGUgd2l0aCBTQU1MIG9yDQo+
PiBPQXV0aC4NCj4+DQo+Pg0KPj4NCj4+IFJlZ2FyZHMNCj4+DQo+PiBKb2huIEIuDQo+Pg0KPj4N
Cj4+DQo+PiBPbiBKYW4gMTQsIDIwMTUsIGF0IDk6MTQgUE0sIEFuZHJlaSBQb3BvdiA8QW5kcmVp
LlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4N
Cj4+IHdyb3RlOg0KPj4NCj4+DQo+Pg0KPj4gVGhlIGRpc2N1c3Npb24gb24gdGhpcyBtYWlsaW5n
IGxpc3QgaGFzIHN1YnNpZGVkIG92ZXIgdGhlIGhvbGlkYXlzLCBzbyBJDQo+PiBsb29rZWQgdGhy
b3VnaCB0aGUgbWVzc2FnZXMgZm9yIGZlZWRiYWNrIHJlZ2FyZGluZyB0aGUgcHJvcG9zZWQgY2hh
cnRlciBhbmQNCj4+IGluY29ycG9yYXRlZCBhIGNvdXBsZSBvZiBjaGFuZ2VzIHN1Z2dlc3RlZCBz
byBmYXI6DQo+Pg0KPj4gMS4gQSBuZXcgZGVzaWduIGdvYWw6IHRoZSBzb2x1dGlvbiBtdXN0IHdv
cmsgZm9yIFdlYiBicm93c2Vycy4gRS5nLiB0aGlzDQo+PiBtZWFucyB0aGF0IHNlY3VyaXR5IHRv
a2VucyBtdXN0IGJlIHByZXNlbnRhYmxlIG92ZXIgbXVsdGlwbGUgVExTIHNlc3Npb25zDQo+PiBh
bmQgY29ubmVjdGlvbnMuDQo+Pg0KPj4gMi4gUmVtb3ZlZCBzcGVjaWZpYyBtaWxlc3RvbmUgZGF0
ZXMuDQo+Pg0KPj4NCj4+DQo+PiBMb29raW5nIGZvcndhcmQgdG8gbW9yZSBkaXNjdXNzaW9uIG9m
IHRoZSBjaGFydGVyLA0KPj4NCj4+DQo+Pg0KPj4gVGhhbmtzLA0KPj4NCj4+DQo+Pg0KPj4gQW5k
cmVpDQo+Pg0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPj4NCj4+IFRva2VuIEJpbmRpbmcgKFRCKQ0KPj4NCj4+DQo+Pg0K
Pj4gQ2hhcnRlciBmb3IgV29ya2luZyBHcm91cA0KPj4NCj4+DQo+Pg0KPj4gV2ViIHNlcnZpY2Vz
IGdlbmVyYXRlIHZhcmlvdXMgc2VjdXJpdHkgdG9rZW5zIChlLmcuICBIVFRQIGNvb2tpZXMsIE9B
dXRoDQo+PiB0b2tlbnMsIGV0Yy4pIGZvciB3ZWIgYXBwbGljYXRpb25zIHRvIGFjY2VzcyBwcm90
ZWN0ZWQgcmVzb3VyY2VzLiBDdXJyZW50bHkNCj4+IHRoZXNlIGFyZSBiZWFyZXIgdG9rZW5zLCBp
LmUuIGFueSBwYXJ0eSBpbiBwb3NzZXNzaW9uIG9mIHN1Y2ggdG9rZW4gZ2FpbnMNCj4+IGFjY2Vz
cyB0byB0aGUgcHJvdGVjdGVkIHJlc291cmNlLiBBdHRhY2tlcnMgZXhwb3J0IGJlYXJlciB0b2tl
bnMgZnJvbSBjbGllbnQNCj4+IG1hY2hpbmVzIG9yIGZyb20gY29tcHJvbWlzZWQgbmV0d29yayBj
b25uZWN0aW9ucywgcHJlc2VudCB0aGVzZSBiZWFyZXINCj4+IHRva2VucyB0byBXZWIgc2Vydmlj
ZXMsIGFuZCBpbXBlcnNvbmF0ZSBhdXRoZW50aWNhdGVkIHVzZXJzLiBUaGUgaWRlYSBvZg0KPj4g
VG9rZW4gQmluZGluZyBpcyB0byBlbmFibGUgZGVmZW5zZSBhZ2FpbnN0IHN1Y2ggYXR0YWNrcyBi
eSBjcnlwdG9ncmFwaGljYWxseQ0KPj4gYmluZGluZyBzZWN1cml0eSB0b2tlbnMgdG8gdGhlIFRM
UyBsYXllci4NCj4+DQo+Pg0KPj4NCj4+IFRoZSB0YXNrcyBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAg
YXJlIGFzIGZvbGxvd3M6DQo+Pg0KPj4gMS4gICAgICAgICAgICBTcGVjaWZ5IHRoZSBUb2tlbiBC
aW5kaW5nIHByb3RvY29sIHYxLjAuDQo+Pg0KPj4gMi4gICAgICAgICAgICBTcGVjaWZ5IHRoZSB1
c2Ugb2YgdGhlIFRva2VuIEJpbmRpbmcgcHJvdG9jb2wgaW4gY29tYmluYXRpb24NCj4+IHdpdGgg
SFRUUFMuDQo+Pg0KPj4NCj4+DQo+PiBJdCBpcyBhIGdvYWwgb2YgdGhpcyB3b3JraW5nIGdyb3Vw
IHRvIGVuYWJsZSBkZWZlbnNlIGFnYWluc3QgYXR0YWNrcyB0aGF0DQo+PiBpbnZvbHZlIHVuYXV0
aG9yaXplZCByZXBsYXkgb2Ygc2VjdXJpdHkgdG9rZW5zLCBidXQgb3RoZXIgaXNzdWVzIGFzc29j
aWF0ZWQNCj4+IHdpdGggdGhlIHVzZSBvZiBzZWN1cml0eSB0b2tlbnMgYXJlIG91dCBvZiBzY29w
ZS4gSXQgaXMgYSBnb2FsIG9mIHRoaXMNCj4+IHdvcmtpbmcgZ3JvdXAgdG8gZGVzaWduIHRoZSBU
b2tlbiBCaW5kaW5nIHByb3RvY29sIHN1Y2ggdGhhdCBpdCB3b3VsZCBiZQ0KPj4gYWxzbyB1c2Vh
YmxlIHdpdGggYXBwbGljYXRpb24gcHJvdG9jb2xzIG90aGVyIHRoYW4gSFRUUFMsIGhvd2V2ZXIg
c3BlY2lmeWluZw0KPj4gc3VjaCB1c2VzIGlzIG5vdCBhIHByaW1hcnkgZ29hbC4NCj4+DQo+Pg0K
Pj4NCj4+IFNvbWUgb2YgdGhlIG1haW4gZGVzaWduIGdvYWxzIGZvciB0aGUgVG9rZW4gQmluZGlu
ZyBwcm90b2NvbCwgaW4gbm8NCj4+IHBhcnRpY3VsYXIgb3JkZXI6DQo+Pg0KPj4gMS4gICAgICAg
ICAgICBQcmV2ZW50IGV4cG9ydCBhbmQgcmVwbGF5IG9mIHNlY3VyaXR5IHRva2Vucy4NCj4+DQo+
PiAyLiAgICAgICAgICAgIEFsbG93IHN0cm9uZyBrZXkgcHJvdGVjdGlvbiwgZS5nLiB1c2luZyBo
YXJkd2FyZS1ib3VuZCBrZXlzLg0KPj4NCj4+IDMuICAgICAgICAgICAgU3VwcG9ydCBib3RoIGZp
cnN0LXBhcnR5IGFuZCBmZWRlcmF0aW9uIHNjZW5hcmlvcy4NCj4+DQo+PiA0LiAgICAgICAgICAg
IFByZXNlcnZlIHVzZXIgcHJpdmFjeS4NCj4+DQo+PiA1LiAgICAgICAgICAgIE1ha2UgdGhlIFRv
a2VuIEJpbmRpbmcgcHJvdG9jb2wgdXNlYWJsZSBpbiBjb21iaW5hdGlvbiB3aXRoIGENCj4+IHZh
cmlldHkgb2YgYXBwbGljYXRpb24gcHJvdG9jb2xzLg0KPj4NCj4+IDYuICAgICAgICAgICAgQWxs
b3cgdGhlIG5lZ290aWF0aW9uIG9mIHRoZSBUb2tlbiBCaW5kaW5nIHByb3RvY29sIHdpdGhvdXQN
Cj4+IGFkZGl0aW9uYWwgcm91bmQtdHJpcHMuDQo+Pg0KPj4gNy4gICAgICAgICAgICBBbGxvdyB0
aGUgdXNlIG9mIG11bHRpcGxlIGNyeXB0b2dyYXBoaWMgYWxnb3JpdGhtcywgc28gdGhhdCBhDQo+
PiB2YXJpZXR5IG9mIHNlY3VyZSBoYXJkd2FyZSBtb2R1bGVzIHdpdGggZGlmZmVyZW50IGNyeXB0
b2dyYXBoaWMgY2FwYWJpbGl0aWVzDQo+PiBjb3VsZCBiZSB1c2VkIHdpdGggVG9rZW4gQmluZGlu
Zy4NCj4+DQo+PiA4LiAgICAgICAgICAgIFByb3Bvc2UgVG9rZW4gQmluZGluZyBzcGVjIHRoYXQg
Y2FuIGJlIGltcGxlbWVudGVkIGluIFdlYg0KPj4gYnJvd3NlcnMgKGJ1dCBpcyBub3QgbGltaXRl
ZCB0byB0aGVtKS4gRS5nLiBXZWIgYnJvd3NlcnMgcmVxdWlyZSB0aGF0IHRoZQ0KPj4gc2FtZSBi
b3VuZCBzZWN1cml0eSB0b2tlbiBtdXN0IGJlIHByZXNlbnRhYmxlIG92ZXIgbXVsdGlwbGUgVExT
IHNlc3Npb25zIGFuZA0KPj4gY29ubmVjdGlvbnMuDQo+Pg0KPj4NCj4+DQo+PiBUaGUgd29ya2lu
ZyBncm91cCB3aWxsIHVzZSB0aGUgZm9sbG93aW5nIGRvY3VtZW50cyBhcyBhIHN0YXJ0aW5nIHBv
aW50IGZvcg0KPj4gaXRzIHdvcms6DQo+Pg0KPj4gLSAgICAgICAgICAgIGRyYWZ0LXBvcG92LXRv
a2VuLWJpbmRpbmctMDA7DQo+Pg0KPj4gLSAgICAgICAgICAgIGRyYWZ0LWJhbGZhbnotaHR0cHMt
dG9rZW4tYmluZGluZy0wMC4NCj4+DQo+Pg0KPj4NCj4+IFRoaXMgV0cgd2lsbCBjb2xsYWJvcmF0
ZSB3aXRoIG90aGVyIElFVEYgV0dzLCBpbiBwYXJ0aWN1bGFyIHdpdGggdGhlIFRMUywNCj4+IEhU
VFBiaXMgYW5kIE9hdXRoIFdHcy4NCj4+DQo+Pg0KPj4NCj4+IE1pbGVzdG9uZXM6DQo+Pg0KPj4g
LSAgICAgICAgICAgIFdHIGRvY3VtZW50IGZvciB0aGUgVG9rZW4gQmluZGluZyBQcm90b2NvbCB2
MS4wLg0KPj4NCj4+IC0gICAgICAgICAgICBXRyBkb2N1bWVudCBmb3IgSFRUUFMgVG9rZW4gQmlu
ZGluZy4NCj4+DQo+PiAtICAgICAgICAgICAgVG9rZW4gQmluZGluZyBQcm90b2NvbCB2MS4wIHRv
IElFU0cuDQo+Pg0KPj4gLSAgICAgICAgICAgIEhUVFBTIFRva2VuIEJpbmRpbmcgdG8gSUVTRy4N
Cj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
Pj4gVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QNCj4+IFVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRv
OlVuYmVhcmFibGVAaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3VuYmVhcmFibGUNCj4+DQo+Pg0KPj4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QN
Cj4+IFVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmc+DQo+PiBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCj4+DQo+DQo+
DQo+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpV
bmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KVW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5iZWFy
YWJsZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5i
ZWFyYWJsZQ0KDQo=

--_000_BN3PR0301MB12508BBF5AD6AEE7AFA34ADB8C320BN3PR0301MB1250_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN
CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq
Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7
fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z
aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ
bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn
ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv
OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl
bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl
ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0
PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs
dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BZnRlciBjaGF0dGlu
ZyB3aXRoIEJpbGwgb2ZmLWxpc3QsIGhlcmUgaXMgdGhlIHNwZWNpZmljIGNoYW5nZSBwcm9wb3Nl
ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt
c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBjaGFydGVy
IGRyYWZ0IGN1cnJlbnRseSBzYXlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj7igJw8L3NwYW4+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMzMzMzMzO2Jh
Y2tncm91bmQ6d2hpdGUiPlRva2VuIEJpbmRpbmcgZW5hYmxlcyBkZWZlbnNlIGFnYWluc3Qgc3Vj
aCBhdHRhY2tzIGJ5IGNyeXB0b2dyYXBoaWNhbGx5IGJpbmRpbmcgc2VjdXJpdHkgdG9rZW5zIHRv
IHRoZSBUTFMgbGF5ZXIuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj7igJw8bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7
Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBwcm9wb3NlZCB0ZXh0
OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJjb2xvcjojMUY0OTdEIj7igJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTpDb25zb2xhcztjb2xvcjojMzMzMzMzO2JhY2tncm91bmQ6d2hpdGUiPlRva2Vu
IEJpbmRpbmcgZW5hYmxlcyBkZWZlbnNlIGFnYWluc3Qgc3VjaCBhdHRhY2tzIGJ5IGNyeXB0b2dy
YXBoaWNhbGx5IGJpbmRpbmcgc2VjdXJpdHkgdG9rZW5zIHRvIGEgc2VjcmV0IGhlbGQgYnkgdGhl
DQogY2xpZW50Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+4oCcPC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPklmIHRoZSBtYWlsaW5nIGxpc3QgaXMgT0sgd2l0aCB0aGlzIGNoYW5n
ZSwgSeKAmWxsIGdvIGFoZWFkIGFuZCB1cGRhdGUgdGhlIGNoYXJ0ZXIgZHJhZnQuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y
OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5
N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZiI+IEJpbGwgTWlsbHMgW21haWx0bzp3bWlsbHNfOTIxMDVAeWFo
b28uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5LCBKYW51YXJ5IDI0LCAyMDE1IDY6
MDggUE08YnI+DQo8Yj5Ubzo8L2I+IFN0ZXBoZW4gRmFycmVsbDsgS2F0aGxlZW4gTW9yaWFydHk7
IEFuZHJlaSBQb3Bvdjxicj4NCjxiPkNjOjwvYj4gSm9obiBCcmFkbGV5OyB1bmJlYXJhYmxlQGll
dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gVXBkYXRlZCBDaGFy
dGVyIFByb3Bvc2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjpibGFjayI+TXkgaXNzdWUgaXMgYWdhaW4gd2l0aCB0aGUgdGV4dCAmcXVvdDtiaW5k
aW5nIHRvIHRoZSBUTFMgbGF5ZXImcXVvdDssIHRoYXQncyBjaGFubmVsIGJpbmRpbmcuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5
bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy
aWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNr
Z3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom
cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PbiBTYXR1cmRheSwgSmFu
dWFyeSAyNCwgMjAxNSA1OjUwIFBNLCBTdGVwaGVuIEZhcnJlbGwgJmx0OzxhIGhyZWY9Im1haWx0
bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllIj5zdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPC9h
PiZndDsgd3JvdGU6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp
Y2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7
YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj
YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUi
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjpibGFjayI+PGJyPg0KQ2hlZXJzLDxicj4NCjxicj4NCkVkaXRpbmcgd2lsbCBlbnN1
ZTotKTxicj4NCjxicj4NClM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJ5cXRmZDQy
OTkzIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s
b3I6YmxhY2siPjxicj4NCk9uIDI1LzAxLzE1IDAxOjMwLCBLYXRobGVlbiBNb3JpYXJ0eSB3cm90
ZTo8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgY2hhcnRlciBsb29rcyBs
aWtlIGl0IGlzIHNoYXBpbmcgdXAuJm5ic3A7IEkganVzdCBoYXZlIHNvbWUgZWRpdG9yaWFsPGJy
Pg0KJmd0OyBzdWdnZXN0aW9ucyBhcyB0aGUgZGlzY3Vzc2lvbiBjb250aW51ZXMsIHRha2UgdGhl
bSBvciBsZWF2ZSB0aGVtLCBub3Q8YnI+DQomZ3Q7IGEgYmlnIGRlYWwuPGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IFN1Z2dlc3QgY2hhbmdpbmcgZnJvbTo8YnI+DQomZ3Q7IFRoZSBpZGVhIG9mIFRva2Vu
IEJpbmRpbmcgaXMgdG8gZW5hYmxlIGRlZmVuc2UgYWdhaW5zdCBzdWNoIGF0dGFja3MgYnk8YnI+
DQomZ3Q7IGNyeXB0b2dyYXBoaWNhbGx5IGJpbmRpbmc8YnI+DQomZ3Q7IHNlY3VyaXR5IHRva2Vu
cyB0byB0aGUgVExTIGxheWVyLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUbzo8YnI+DQomZ3Q7IFRv
a2VuIEJpbmRpbmcgZW5hYmxlcyBkZWZlbnNlIGFnYWluc3Qgc3VjaCBhdHRhY2tzIGJ5IGNyeXB0
b2dyYXBoaWNhbGx5IGJpbmRpbmc8YnI+DQomZ3Q7IHNlY3VyaXR5IHRva2VucyB0byB0aGUgVExT
IGxheWVyLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgd29yZCBnb2FsIGlzIHVzZWQgYSBiaXQg
bXVjaCwgYnV0IHRoaXMgaXMgYSBwZXJzb25hbCBwcmVmZXJlbmNlIC08YnI+DQomZ3Q7IHRha2Ug
b3IgbGVhdmUgdGhlIHN1Z2dlc3Rpb25zLiZuYnNwOyBJIHN1Z2dlc3QgcmVtb3ZpbmcgJnF1b3Q7
U29tZSZxdW90OyBpbiB0aGUgbGFzdDxicj4NCiZndDsgc2VudGVuY2UgbGlzdGVkIGFzIHRoaXMg
b25seSBzYXlzIHRoZSAmcXVvdDttYWluJnF1b3Q7IGdvYWxzL29iamVjdGl2ZXMsIHNvPGJyPg0K
Jmd0OyB0aGVyZSBpcyB3aWdnbGUgcm9vbSBzdGlsbC48YnI+DQomZ3Q7IDxicj4NCiZndDsgRnJv
bTo8YnI+DQomZ3Q7IEl0IGlzIGEgZ29hbCBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAgdG8gZW5hYmxl
IGRlZmVuc2UgYWdhaW5zdCBhdHRhY2tzPGJyPg0KJmd0OyB0aGF0IGludm9sdmUgdW5hdXRob3Jp
emVkIHJlcGxheSBvZjxicj4NCiZndDsgc2VjdXJpdHkgdG9rZW5zLCBidXQgb3RoZXIgaXNzdWVz
IGFzc29jaWF0ZWQgd2l0aCB0aGUgdXNlIG9mIHNlY3VyaXR5PGJyPg0KJmd0OyB0b2tlbnMgYXJl
IG91dCBvZiBzY29wZS4gSXQgaXMgYSBnb2FsPGJyPg0KJmd0OyBvZiB0aGlzIHdvcmtpbmcgZ3Jv
dXAgdG8gZGVzaWduIHRoZSBUb2tlbiBCaW5kaW5nIHByb3RvY29sIHN1Y2ggdGhhdDxicj4NCiZn
dDsgaXQgd291bGQgYmUgYWxzbyB1c2VhYmxlIHdpdGg8YnI+DQomZ3Q7IGFwcGxpY2F0aW9uIHBy
b3RvY29scyBvdGhlciB0aGFuIEhUVFBTLCBob3dldmVyIHNwZWNpZnlpbmcgc3VjaCB1c2VzPGJy
Pg0KJmd0OyBpcyBub3QgYSBwcmltYXJ5IGdvYWwuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNvbWUg
b2YgdGhlIG1haW4gZGVzaWduIGdvYWxzIGZvciB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCwg
aW4gbm88YnI+DQomZ3Q7IHBhcnRpY3VsYXIgb3JkZXI6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRv
Ojxicj4NCiZndDsgSXQgaXMgYSBnb2FsIG9mIHRoaXMgd29ya2luZyBncm91cCB0byBlbmFibGUg
ZGVmZW5zZSBhZ2FpbnN0IGF0dGFja3M8YnI+DQomZ3Q7IHRoYXQgaW52b2x2ZSB1bmF1dGhvcml6
ZWQgcmVwbGF5IG9mPGJyPg0KJmd0OyBzZWN1cml0eSB0b2tlbnMuJm5ic3A7IE90aGVyIGlzc3Vl
cyBhc3NvY2lhdGVkIHdpdGggdGhlIHVzZSBvZiBzZWN1cml0eTxicj4NCiZndDsgdG9rZW5zIGFy
ZSBvdXQgb2Ygc2NvcGUuIEFub3RoZXIgZ29hbDxicj4NCiZndDsgb2YgdGhpcyB3b3JraW5nIGdy
b3VwIGlzIHRvIGRlc2lnbiB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCBzdWNoPGJyPg0KJmd0
OyB0aGF0IGl0IHdvdWxkIGJlIGFsc28gdXNlYWJsZSB3aXRoPGJyPg0KJmd0OyBhcHBsaWNhdGlv
biBwcm90b2NvbHMgb3RoZXIgdGhhbiBIVFRQUy4mbmJzcDsgU3BlY2lmeWluZyBhbHRlcm5hdGU8
YnI+DQomZ3Q7IGFwcGxpY2F0aW9uIHByb3RvY29scyBpcyBub3QgYSBwcmltYXJ5IGdvYWwuPGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBtYWluIGRlc2lnbiBvYmplY3RpdmVzIGZvciB0aGUgVG9r
ZW4gQmluZGluZyBwcm90b2NvbCwgaW4gbm88YnI+DQomZ3Q7IHBhcnRpY3VsYXIgb3JkZXI6PGJy
Pg0KJmd0OyA8YnI+DQomZ3Q7ICM4IC0gc3BlYyBzaG91bGQgcHJvYmFibHkgYmUgc3BlbGxlZCBv
dXQgYXMgc3BlY2lmaWNhdGlvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZn
dDsgS2F0aGxlZW48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBUdWUsIEphbiAy
MCwgMjAxNSBhdCA3OjA3IFBNLCBBbmRyZWkgUG9wb3Y8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJt
YWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20iPkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQu
Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgSSBiZWxpZXZlIEnigJl2ZSBhZGRyZXNz
ZWQgdGhlIGZlZWRiYWNrIHJlY2VpdmVkIHNvIGZhcjsgdGhlIHVwZGF0ZWQgY2hhcnRlcjxicj4N
CiZndDsmZ3Q7IGRyYWZ0IGlzIG9uIEdpdEh1YiBmb3IgZWFzeSBhdXRob3Jpbmc6PGJyPg0KJmd0
OyZndDs8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vVG9rZW5CaW5k
aW5nL1dHLUNoYXJ0ZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vVG9rZW5C
aW5kaW5nL1dHLUNoYXJ0ZXI8L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7PGJyPg0KJmd0OyZndDsgUHVsbCByZXF1ZXN0cyBhcmUgd2VsY29tZSw8YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGFua3MsPGJy
Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQW5k
cmVpPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn
dDsgRnJvbTogSm9obiBCcmFkbGV5IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdq
dGIuY29tIj52ZTdqdGJAdmU3anRiLmNvbTwvYT5dPGJyPg0KJmd0OyZndDsgU2VudDogVGh1cnNk
YXksIEphbnVhcnkgMTUsIDIwMTUgMTI6MTYgUE08YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7
PGJyPg0KJmd0OyZndDsgVG86IEFuZHJlaSBQb3Bvdjxicj4NCiZndDsmZ3Q7IENjOiA8YSBocmVm
PSJtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZyI+dW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+
DQomZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFVwZGF0ZWQgQ2hhcnRlciBQcm9w
b3NhbDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7IEEgY291cGxlIG1vcmUgcG9zc2libGUgY2xhcmlmaWNhdGlvbnMuPGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi
cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAyLiZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNwZWNpZnkgdGhlIHVzZSBvZiB0aGUgVG9rZW4g
QmluZGluZyBwcm90b2NvbCBpbiBjb21iaW5hdGlvbjxicj4NCiZndDsmZ3Q7IHdpdGggSFRUUFMu
PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg
SFRUUFMgaXMgcHJvYmFibHkgaW50ZW5kZWQgdG8gYmUgc2hvcnRoYW5kIGZvciBhIGh0dHAgYmlu
ZGluZyBmb3IgVExTICYjNDM7PGJyPg0KJmd0OyZndDsgdG9rZW4gQmluZGluZyBhcyBpcyBkZWZp
bmVkIGluICZxdW90O1Rva2VuIEJpbmRpbmcgb3ZlciBIVFRQJnF1b3Q7PGJyPg0KJmd0OyZndDsg
WzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iYWxmYW56LWh0dHBz
LXRva2VuLWJpbmRpbmctMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtYmFsZmFuei1odHRwcy10b2tlbi1iaW5kaW5nLTAwPC9hPl0uPGJyPg0KJmd0
OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhpcyBpcyBh
IGJpbmRpbmcgdG8gSFRUUCAodmlhIGEgbmV3IGhlYWRlcikgYW5kIHRvIEhUTUwmbmJzcDsgKHZp
YSBYTUwgSFRUUDxicj4NCiZndDsmZ3Q7IHJlcXVlc3QpLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0
OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IElmIHdlIGFsc28gc2F5IHRoYXQgcG9z
c2libGUgZnV0dXJlIGJpbmRpbmcgbWF5IGJlIGEgU0FTU0wvR1NTLUFQSSBiaW5kaW5nPGJyPg0K
Jmd0OyZndDsgZm9yIFRMUyAmIzQzOyB0b2tlbiBiaW5kaW5nJm5ic3A7IChUaGUgc2Fzc2wtb2F1
dGggc3BlYzxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1pZXRmLWtpdHRlbi1zYXNsLW9hdXRoLTE4IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw
czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1raXR0ZW4tc2FzbC1vYXV0aC0xOCA8
L2E+bWlnaHQgdXNlIHN1Y2ggYTxicj4NCiZndDsmZ3Q7IHRoaW5nLik8YnI+DQomZ3Q7Jmd0Ozxi
cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsgT25lIG90aGVyIHRoaW5nIEkgbm90ZSBpbiB0aGUgZHJhZnRzLCBpcyB0aGF0
IGF0IG5vIHBvaW50IGFyZSZuYnNwOyB0b2tlbnM8YnI+DQomZ3Q7Jmd0OyBkZWZpbmVkIG9yIGV2
ZW4gcmVhbGx5IGRpc2N1c3NlZCBvdGhlciB0aGFuIGFzIHNvbWV0aGluZyB0aGF0IGFwcGxpY2F0
aW9uczxicj4NCiZndDsmZ3Q7IGNhbiBiaW5kIHRvIHRoZSBleHBvc2VkIHB1YmxpYyBrZXkuPGJy
Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgYXBwbGljYXRpb25zIHdpbGwgYmluZCB0b2tl
bnMgdG8gdGhlIGtleXMgZXhwb3NlZCBieSB0aGUgc3BlY3MgdmlhIHRoZTxicj4NCiZndDsmZ3Q7
IGJpbmRpbmdzLiZuYnNwOyBUaGUgbmFtaW5nIG1heSBzbGlnaHRseSBtaXNkaXJlY3QgcGVvcGxl
LCBidXQgdGhlcmUgaGF2ZSBhbHJlYWR5PGJyPg0KJmd0OyZndDsgYmVlbiB0b28gbWFueSBuYW1l
cyBmb3IgdGhpcyBzbyBJIHdvbid0IHB1c2ggdGhlIHBvaW50Ljxicj4NCiZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEkgdGhpbmsga2VlcGluZyB0aGlz
IGRvd24gY2xvc2UgdG8gdGhlIFRMUyBsYXllciBhbmQgZGVmaW5pbmcgYmluZGluZ3MgdG88YnI+
DQomZ3Q7Jmd0OyBIVFRQIGFuZCBvdGhlciBwcm90b2NvbHMgaXMgaW4gc2NvcGUuPGJyPg0KJmd0
OyZndDs8YnI+DQomZ3Q7Jmd0OyBFbmNvdXJhZ2luZyBhcHBsaWNhdGlvbnMgdGhhdCB1c2UgcHJv
dG9jb2xzIGxpa2UgSFRUUCAmIzQzOyBUTFMgdG8gdXNlIHRoZTxicj4NCiZndDsmZ3Q7IGJpbmRp
bmdzIHRvIGJpbmQgdGhlcmUgc2VjdXJpdHkgdG9rZW5zL2Nvb2tpZXMgaXMgaW4gc2NvcGUuPGJy
Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSB0
aGluayBkZWZpbmluZyB0aGUgZXh0ZW5zaW9ucyBmb3IgdGhvc2UgYXBwbGljYXRpb25zIHRvIHVz
ZSB0aGUgYmluZGluZ3M8YnI+DQomZ3Q7Jmd0OyBpcyBzaG91bGQgYmUgdXAgdG8gdGhlIGFwcGxp
Y2F0aW9ucyB0aGVtc2VsdmVzIHdoZXJlIHRoZXJlIGlzIGFjdGl2ZTxicj4NCiZndDsmZ3Q7IHBh
cnRpY2lwYXRpb24uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsgVHJ5aW5nIHRvIGV4dGVuZCB0aGlzIHRvIGNvdmVyIGVuZCB0byBlbmQgbWVz
c2FnZSBzaWduaW5nIG91dHNpZGUgb2YgYSBUTFM8YnI+DQomZ3Q7Jmd0OyBzZXNzaW9uIHNob3Vs
ZCBiZSBleHByZXNzbHkgb3V0IG9mIHNjb3BlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFdlIG1heSBob3dldmVyIHdhbnQgdG8gc2F5IHNv
bWV0aGluZyBhYm91dCBob3cgYSBUTFMgc2Vzc2lvbiB0ZXJtaW5hdGVkIG9uIGE8YnI+DQomZ3Q7
Jmd0OyBUTFMgZGV2aWNlIGNhbiBoYXZlIHRoZSBUb2tlbiBCaW5kaW5nIElEIGZvciB0aGUgc2Vz
c2lvbiBwYXNzZWQgaW4gYSBIVFRQPGJyPg0KJmd0OyZndDsgaGVhZGVyLjxicj4NCiZndDsmZ3Q7
PGJyPg0KJmd0OyZndDsgVGhhdCBhbmQgcG9zc2libHkgc29tZSBvdGhlciBUTFMgYXBwbGlhbmNl
IGlzc3VlcyBhcmUgaW4gc2NvcGUgZm9yICZxdW90O1Rva2VuPGJyPg0KJmd0OyZndDsgQmluZGlu
ZyBvdmVyIEhUVFAmcXVvdDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0OyBSZWdhcmRzPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBKb2hu
IEIuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0
OyBPbiBKYW4gMTUsIDIwMTUsIGF0IDM6NTIgUE0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0i
bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0
LmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhhbmtzIEpvaG47IGJvdGggc3VnZ2Vz
dGlvbnMgbWFrZSBzZW5zZSB0byBtZTsgd2lsbCByZXBocmFzZSBpbiB0aGUgbmV4dDxicj4NCiZn
dDsmZ3Q7IHJldmlzaW9uLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0
Ozxicj4NCiZndDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBbmRyZWk8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7
PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBGcm9tOiBKb2huIEJyYWRsZXkgW21haWx0bzo8
YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29tPC9hPl08
YnI+DQomZ3Q7Jmd0OyBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAxNSwgMjAxNSA5OjI1IEFNPGJy
Pg0KJmd0OyZndDsgVG86IEFuZHJlaSBQb3Bvdjxicj4NCiZndDsmZ3Q7IENjOiA8YSBocmVmPSJt
YWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZyI+dW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+DQom
Z3Q7Jmd0OyBTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFVwZGF0ZWQgQ2hhcnRlciBQcm9wb3Nh
bDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7
IEkgYW0gZ2VuZXJhbGx5IGluIGFncmVtZW50Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEEgY291cGxlIG9mIHBvaW50cy48YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBVbmRlciBkZXNp
Z24gZ29hbHMgY2hhbmdlIDEgdG8uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7PGJyPg0KJmd0OyZndDsgMS4mbmJzcDsgQWxsb3cgYXBwbGljYXRpb25zIHRvIHByZXZl
bnQgdGhlIGV4cG9ydCBhbmQgcmVwbGF5IG9mIHNlY3VyaXR5IHRva2Vucy48YnI+DQomZ3Q7Jmd0
Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBZb3UgY291bGQgbWFr
ZSB0aGF0IGFwcGxpY2F0aW9ucyBhbmQgcHJvdG9jb2xzIGlmIHlvdSBsaWtlIGFzIHNvbWUgcGVv
cGxlPGJyPg0KJmd0OyZndDsgbWF5IHNlZSB0aGluZ3MgbGlrZSBPQXV0aCBhcyBhIHByb3RvY29s
IHZzIGFuIGFwcGxpY2F0aW9uLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIHBvaW50
IGJlaW5nIHRoYXQgdGhlIGdvYWwgaXMgdG8gcHJvdmlkZSB0aGUgaG9va3MgZm9yIHRoaW5ncyBh
IGxheWVyPGJyPg0KJmd0OyZndDsgYWJvdmUgdGhlc2Ugc3BlY2lmaWNhdGlvbnMgdG8gbWFrZSBz
ZWN1cml0eSBkZWNpc2lvbnMsIG5vdCB0aGUgdG9rZW4gYmluZGluZzxicj4NCiZndDsmZ3Q7IHBy
b3RvY29sIGl0c2VsZi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSW4gMyB5b3UgdXNlIHRo
ZSB0ZXJtIGZlZGVyYXRpb24uJm5ic3A7IFRoYXQgbWF5IGJlIGxhcmdlciBpbiBzY29wZSB0aGFu
IHdoYXQgSTxicj4NCiZndDsmZ3Q7IHRoaW5rIHlvdSBpbnRlbmQgZnJvbSB0aGUgdHdvIGRyYWZ0
cy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZlZGVyYXRpb24gaXMgYSBtdWNoIGxhcmdl
ciB0b3BpYyB0aGFuIGFsbG93aW5nIHRoZSBwdWJsaWMga2V5IGZyb20gb25lPGJyPg0KJmd0OyZn
dDsgY29ubmVjdGlvbiB0byBiZSBleHBvc2VkIGluIGEgY29ubmVjdGlvbiB0byBhIHNlY29uZCBw
YXJ0eSB2aWEgc29tZSBzb3J0IG9mPGJyPg0KJmd0OyZndDsgZXhwcmVzcyBjb25zZW50IGZyb20g
dGhlIGZpcnN0IHBhcnR5Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0
Ozxicj4NCiZndDsmZ3Q7IFNocmlua2luZyB0aGUgc2NvcGUgdG8gaG93IHB1YmxpYyBrZXlzIG1h
eSBiZSBzaGFyZWQgd2l0aCBwZXJtaXNzaW9uIHRvPGJyPg0KJmd0OyZndDsgdGhpcmQgcGFydGll
cyBtYXkgbWFrZSBzb21lIHBlb3BsZSBtb3JlIGNvbWZvcnRhYmxlLCBpZiB0aGV5IGFyZSBjb25j
ZXJuZWQ8YnI+DQomZ3Q7Jmd0OyB0aGF0IHRoaXMgaXMgdHJ5aW5nIHRvIGJlIGEgbmV3IGZlZGVy
YXRpb24gcHJvdG9jb2wgdG8gY29tcGV0ZSB3aXRoIFNBTUwgb3I8YnI+DQomZ3Q7Jmd0OyBPQXV0
aC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0
OyBSZWdhcmRzPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBKb2huIEIuPGJyPg0KJmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgT24gSmFuIDE0LCAy
MDE1LCBhdCA5OjE0IFBNLCBBbmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZWku
UG9wb3ZAbWljcm9zb2Z0LmNvbSI+QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxi
cj4NCiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoZSBkaXNjdXNzaW9uIG9uIHRoaXMgbWFpbGluZyBsaXN0IGhh
cyBzdWJzaWRlZCBvdmVyIHRoZSBob2xpZGF5cywgc28gSTxicj4NCiZndDsmZ3Q7IGxvb2tlZCB0
aHJvdWdoIHRoZSBtZXNzYWdlcyBmb3IgZmVlZGJhY2sgcmVnYXJkaW5nIHRoZSBwcm9wb3NlZCBj
aGFydGVyIGFuZDxicj4NCiZndDsmZ3Q7IGluY29ycG9yYXRlZCBhIGNvdXBsZSBvZiBjaGFuZ2Vz
IHN1Z2dlc3RlZCBzbyBmYXI6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAxLiBBIG5ldyBk
ZXNpZ24gZ29hbDogdGhlIHNvbHV0aW9uIG11c3Qgd29yayBmb3IgV2ViIGJyb3dzZXJzLiBFLmcu
IHRoaXM8YnI+DQomZ3Q7Jmd0OyBtZWFucyB0aGF0IHNlY3VyaXR5IHRva2VucyBtdXN0IGJlIHBy
ZXNlbnRhYmxlIG92ZXIgbXVsdGlwbGUgVExTIHNlc3Npb25zPGJyPg0KJmd0OyZndDsgYW5kIGNv
bm5lY3Rpb25zLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgMi4gUmVtb3ZlZCBzcGVjaWZp
YyBtaWxlc3RvbmUgZGF0ZXMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7PGJyPg0KJmd0OyZndDsgTG9va2luZyBmb3J3YXJkIHRvIG1vcmUgZGlzY3Vzc2lvbiBvZiB0
aGUgY2hhcnRlciw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+
DQomZ3Q7Jmd0OyBUaGFua3MsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7PGJyPg0KJmd0OyZndDsgQW5kcmVpPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N
CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRva2VuIEJp
bmRpbmcgKFRCKTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N
CiZndDsmZ3Q7IENoYXJ0ZXIgZm9yIFdvcmtpbmcgR3JvdXA8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBXZWIgc2VydmljZXMgZ2VuZXJhdGUg
dmFyaW91cyBzZWN1cml0eSB0b2tlbnMgKGUuZy4mbmJzcDsgSFRUUCBjb29raWVzLCBPQXV0aDxi
cj4NCiZndDsmZ3Q7IHRva2VucywgZXRjLikgZm9yIHdlYiBhcHBsaWNhdGlvbnMgdG8gYWNjZXNz
IHByb3RlY3RlZCByZXNvdXJjZXMuIEN1cnJlbnRseTxicj4NCiZndDsmZ3Q7IHRoZXNlIGFyZSBi
ZWFyZXIgdG9rZW5zLCBpLmUuIGFueSBwYXJ0eSBpbiBwb3NzZXNzaW9uIG9mIHN1Y2ggdG9rZW4g
Z2FpbnM8YnI+DQomZ3Q7Jmd0OyBhY2Nlc3MgdG8gdGhlIHByb3RlY3RlZCByZXNvdXJjZS4gQXR0
YWNrZXJzIGV4cG9ydCBiZWFyZXIgdG9rZW5zIGZyb20gY2xpZW50PGJyPg0KJmd0OyZndDsgbWFj
aGluZXMgb3IgZnJvbSBjb21wcm9taXNlZCBuZXR3b3JrIGNvbm5lY3Rpb25zLCBwcmVzZW50IHRo
ZXNlIGJlYXJlcjxicj4NCiZndDsmZ3Q7IHRva2VucyB0byBXZWIgc2VydmljZXMsIGFuZCBpbXBl
cnNvbmF0ZSBhdXRoZW50aWNhdGVkIHVzZXJzLiBUaGUgaWRlYSBvZjxicj4NCiZndDsmZ3Q7IFRv
a2VuIEJpbmRpbmcgaXMgdG8gZW5hYmxlIGRlZmVuc2UgYWdhaW5zdCBzdWNoIGF0dGFja3MgYnkg
Y3J5cHRvZ3JhcGhpY2FsbHk8YnI+DQomZ3Q7Jmd0OyBiaW5kaW5nIHNlY3VyaXR5IHRva2VucyB0
byB0aGUgVExTIGxheWVyLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0
Ozxicj4NCiZndDsmZ3Q7IFRoZSB0YXNrcyBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAgYXJlIGFzIGZv
bGxvd3M6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAxLiZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNwZWNpZnkgdGhlIFRva2VuIEJpbmRpbmcgcHJvdG9jb2wg
djEuMC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDIuJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgU3BlY2lmeSB0aGUgdXNlIG9mIHRoZSBUb2tlbiBCaW5kaW5n
IHByb3RvY29sIGluIGNvbWJpbmF0aW9uPGJyPg0KJmd0OyZndDsgd2l0aCBIVFRQUy48YnI+DQom
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJdCBpcyBh
IGdvYWwgb2YgdGhpcyB3b3JraW5nIGdyb3VwIHRvIGVuYWJsZSBkZWZlbnNlIGFnYWluc3QgYXR0
YWNrcyB0aGF0PGJyPg0KJmd0OyZndDsgaW52b2x2ZSB1bmF1dGhvcml6ZWQgcmVwbGF5IG9mIHNl
Y3VyaXR5IHRva2VucywgYnV0IG90aGVyIGlzc3VlcyBhc3NvY2lhdGVkPGJyPg0KJmd0OyZndDsg
d2l0aCB0aGUgdXNlIG9mIHNlY3VyaXR5IHRva2VucyBhcmUgb3V0IG9mIHNjb3BlLiBJdCBpcyBh
IGdvYWwgb2YgdGhpczxicj4NCiZndDsmZ3Q7IHdvcmtpbmcgZ3JvdXAgdG8gZGVzaWduIHRoZSBU
b2tlbiBCaW5kaW5nIHByb3RvY29sIHN1Y2ggdGhhdCBpdCB3b3VsZCBiZTxicj4NCiZndDsmZ3Q7
IGFsc28gdXNlYWJsZSB3aXRoIGFwcGxpY2F0aW9uIHByb3RvY29scyBvdGhlciB0aGFuIEhUVFBT
LCBob3dldmVyIHNwZWNpZnlpbmc8YnI+DQomZ3Q7Jmd0OyBzdWNoIHVzZXMgaXMgbm90IGEgcHJp
bWFyeSBnb2FsLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N
CiZndDsmZ3Q7IFNvbWUgb2YgdGhlIG1haW4gZGVzaWduIGdvYWxzIGZvciB0aGUgVG9rZW4gQmlu
ZGluZyBwcm90b2NvbCwgaW4gbm88YnI+DQomZ3Q7Jmd0OyBwYXJ0aWN1bGFyIG9yZGVyOjxicj4N
CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgMS4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyBQcmV2ZW50IGV4cG9ydCBhbmQgcmVwbGF5IG9mIHNlY3VyaXR5IHRva2Vucy48
YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDIuJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgQWxsb3cgc3Ryb25nIGtleSBwcm90ZWN0aW9uLCBlLmcuIHVzaW5nIGhh
cmR3YXJlLWJvdW5kIGtleXMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAzLiZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFN1cHBvcnQgYm90aCBmaXJzdC1wYXJ0
eSBhbmQgZmVkZXJhdGlvbiBzY2VuYXJpb3MuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA0
LiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFByZXNlcnZlIHVzZXIg
cHJpdmFjeS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDUuJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTWFrZSB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCB1
c2VhYmxlIGluIGNvbWJpbmF0aW9uIHdpdGggYTxicj4NCiZndDsmZ3Q7IHZhcmlldHkgb2YgYXBw
bGljYXRpb24gcHJvdG9jb2xzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgNi4mbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBbGxvdyB0aGUgbmVnb3RpYXRpb24g
b2YgdGhlIFRva2VuIEJpbmRpbmcgcHJvdG9jb2wgd2l0aG91dDxicj4NCiZndDsmZ3Q7IGFkZGl0
aW9uYWwgcm91bmQtdHJpcHMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA3LiZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFsbG93IHRoZSB1c2Ugb2YgbXVsdGlw
bGUgY3J5cHRvZ3JhcGhpYyBhbGdvcml0aG1zLCBzbyB0aGF0IGE8YnI+DQomZ3Q7Jmd0OyB2YXJp
ZXR5IG9mIHNlY3VyZSBoYXJkd2FyZSBtb2R1bGVzIHdpdGggZGlmZmVyZW50IGNyeXB0b2dyYXBo
aWMgY2FwYWJpbGl0aWVzPGJyPg0KJmd0OyZndDsgY291bGQgYmUgdXNlZCB3aXRoIFRva2VuIEJp
bmRpbmcuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA4LiZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFByb3Bvc2UgVG9rZW4gQmluZGluZyBzcGVjIHRoYXQgY2Fu
IGJlIGltcGxlbWVudGVkIGluIFdlYjxicj4NCiZndDsmZ3Q7IGJyb3dzZXJzIChidXQgaXMgbm90
IGxpbWl0ZWQgdG8gdGhlbSkuIEUuZy4gV2ViIGJyb3dzZXJzIHJlcXVpcmUgdGhhdCB0aGU8YnI+
DQomZ3Q7Jmd0OyBzYW1lIGJvdW5kIHNlY3VyaXR5IHRva2VuIG11c3QgYmUgcHJlc2VudGFibGUg
b3ZlciBtdWx0aXBsZSBUTFMgc2Vzc2lvbnMgYW5kPGJyPg0KJmd0OyZndDsgY29ubmVjdGlvbnMu
PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg
VGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCB1c2UgdGhlIGZvbGxvd2luZyBkb2N1bWVudHMgYXMgYSBz
dGFydGluZyBwb2ludCBmb3I8YnI+DQomZ3Q7Jmd0OyBpdHMgd29yazo8YnI+DQomZ3Q7Jmd0Ozxi
cj4NCiZndDsmZ3Q7IC0mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBk
cmFmdC1wb3Bvdi10b2tlbi1iaW5kaW5nLTAwOzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsg
LSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRyYWZ0LWJhbGZhbnot
aHR0cHMtdG9rZW4tYmluZGluZy0wMC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGlzIFdHIHdpbGwgY29sbGFib3JhdGUgd2l0aCBvdGhl
ciBJRVRGIFdHcywgaW4gcGFydGljdWxhciB3aXRoIHRoZSBUTFMsPGJyPg0KJmd0OyZndDsgSFRU
UGJpcyBhbmQgT2F1dGggV0dzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7IE1pbGVzdG9uZXM6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0
OyAtJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgV0cgZG9jdW1lbnQg
Zm9yIHRoZSBUb2tlbiBCaW5kaW5nIFByb3RvY29sIHYxLjAuPGJyPg0KJmd0OyZndDs8YnI+DQom
Z3Q7Jmd0OyAtJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgV0cgZG9j
dW1lbnQgZm9yIEhUVFBTIFRva2VuIEJpbmRpbmcuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0
OyAtJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVG9rZW4gQmluZGlu
ZyBQcm90b2NvbCB2MS4wIHRvIElFU0cuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSFRUUFMgVG9rZW4gQmluZGlu
ZyB0byBJRVNHLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBVbmJlYXJhYmxlIG1h
aWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpVbmJlYXJhYmxlQGlldGYu
b3JnIj5VbmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZSIgdGFyZ2V0PSJfYmxh
bmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZTwvYT48
YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi
cj4NCiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPGJyPg0KJmd0OyZndDsgVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8
YSBocmVmPSJtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZyI+VW5iZWFyYWJsZUBpZXRmLm9yZzwv
YT48YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3VuYmVhcmFibGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGU8L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7IDxi
cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxicj4NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0PGJyPg0K
PGEgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmciPlVuYmVhcmFibGVAaWV0Zi5vcmc8
L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91
bmJlYXJhYmxlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby91bmJlYXJhYmxlPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6
d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu
cy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_BN3PR0301MB12508BBF5AD6AEE7AFA34ADB8C320BN3PR0301MB1250_--


From nobody Tue Jan 27 12:13:37 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4051A8A4C for ; Tue, 27 Jan 2015 12:13:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.892
X-Spam-Level: *
X-Spam-Status: No, score=1.892 tagged_above=-999 required=5 tests=[BAYES_60=1.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 OCQcRTyeCKqs for ; Tue, 27 Jan 2015 12:13:31 -0800 (PST)
Received: from nm29-vm1.bullet.mail.bf1.yahoo.com (nm29-vm1.bullet.mail.bf1.yahoo.com [98.139.213.144]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7151A8763 for ; Tue, 27 Jan 2015 12:13:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1422389610; bh=aGfV+s0gArBkpzANRmQp8PL6NCIf2g5JGwkDK71xAv8=; h=Date:From:Reply-To:To:Subject:From:Subject; b=cdCmFHpelRN6LIgrJIuToTxZGlZSHROPnG4+zj4UTV+DdTToe2tH57uXhhIbe8xrURzwuuKwdVNn61c4/qcL/ScR8ooC5ICnQb0QIjKWkhZa5kOtSGepOqQ5zWKYDaZw+tW25rQogYm421f7W6hxqgc1QLLgoDKhhsqD0tNKZhoxWH0ljfa3Bbl3zSZttN7IHlKdhkeFGQmthhdfM+MZg4WXmdXB4Vm1PwzMc6EYHIoeTuA57piBmLBD1o2M8e5Se+WjZMLWonxb16b95V4RGI3EoUv5FIeQDeD5EE5udE+N4JYBumapJybDymWNDlr7+VPO25/KRFAllWczJb77zg==
Received: from [66.196.81.174] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 27 Jan 2015 20:13:30 -0000
Received: from [98.139.212.199] by tm20.bullet.mail.bf1.yahoo.com with NNFMP;  27 Jan 2015 20:13:30 -0000
Received: from [127.0.0.1] by omp1008.mail.bf1.yahoo.com with NNFMP; 27 Jan 2015 20:13:30 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 365326.990.bm@omp1008.mail.bf1.yahoo.com
X-YMail-OSG: LsX.0LcVM1k86Mxm4wSkAf0Zu.6ZF9FsVVAW8wiiLtLcNUBcpZCrM8btLWlWVj3 ..D6979kcG0dNOL2UdqrLZujNQS565FS_K0JUOMNyJfXWRQ47W08ydeJQ66hQwFgxABwAuvxMRxV UGK_uEBVJdXHiaI386a1fanHe_tH02GbKyWEgzIqidk7S4NF82vNvx8IGNQFbd5Dg.yc0Qt6PM.B FG2fofDPnhp_M6WMjSfH8JF_ZQfGAcN79VJzbRH4ifE8ITqd03u1m39IRtFko2tJMCsGUVfkZ1c5 yNG71vdYX4HqJ3L_vOvdr95NqgEOgGlECWJpMHvCm_ZJWvmj0FzHcjOdBPT_ilFGNAhcwQh_G2h2 WJHMMI9Dz6ayCLUXyDi3bhxBk90gHC4XjRAQ9GxUGHuD1QTc7AJkOIU70idSQszDkZUZr9ZWnMpS rHRn3Dk46P7snZIemwHdvlCKCAhleMbCD_mZjFQQmK8aj3ERPQ7omxa.5apvCOZZct_VftbBaeEe j9fmzedD91dKS2F9mQwWk3XEy4QNWzLZFvcM.OdTufg.BYMpIvaG..EB0h.YvK0tGRsbQsYvaUa0 geihuUHO2B8kyqovJyY7wEcUs8JQk
Received: by 76.13.27.48; Tue, 27 Jan 2015 20:13:29 +0000 
Date: Tue, 27 Jan 2015 20:13:29 +0000 (UTC)
From: Bill Mills 
To: "unbearable@ietf.org" 
Message-ID: <818287466.1381395.1422389609617.JavaMail.yahoo@mail.yahoo.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_1381394_5146590.1422389609615"
Archived-At: 
Subject: [Unbearable] similarities....
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 20:13:33 -0000

------=_Part_1381394_5146590.1422389609615
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

As an aside=C2=A0http://tools.ietf.org/html/draft-ietf-oauth-spop-06=C2=A0f=
alls right into this space.


------=_Part_1381394_5146590.1422389609615
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit


As an aside http://tools.ietf.org/html/draft-ietf-oauth-spop-06 falls right into this space.


------=_Part_1381394_5146590.1422389609615--


From nobody Tue Jan 27 13:59:35 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF33A1A9051 for ; Tue, 27 Jan 2015 13:59:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 E7fg3Q4321av for ; Tue, 27 Jan 2015 13:59:31 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0785.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::785]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22EE41A1B2C for ; Tue, 27 Jan 2015 13:59:31 -0800 (PST)
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) by BN3PR0301MB1234.namprd03.prod.outlook.com (25.161.207.22) with Microsoft SMTP Server (TLS) id 15.1.65.19; Tue, 27 Jan 2015 21:59:08 +0000
Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([25.161.207.22]) with mapi id 15.01.0065.013; Tue, 27 Jan 2015 21:59:08 +0000
From: Anthony Nadalin 
To: Bill Mills , "unbearable@ietf.org" 
Thread-Topic: [Unbearable] similarities....
Thread-Index: AQHQOm2+MlUzpAN5B0irS1BOjA/TGZzUg8Vw
Date: Tue, 27 Jan 2015 21:59:08 +0000
Message-ID: 
References: <818287466.1381395.1422389609617.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: <818287466.1381395.1422389609617.JavaMail.yahoo@mail.yahoo.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::2]
authentication-results: yahoo.com; dkim=none (message not signed) header.d=none;yahoo.com; dmarc=none action=none header.from=microsoft.com;
x-dmarcaction-test: None
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(3005004);SRVR:BN3PR0301MB1234;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1234; 
x-forefront-prvs: 046985391D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(102836002)(19300405004)(86362001)(15975445007)(77156002)(19609705001)(19617315012)(86612001)(46102003)(33656002)(19580395003)(19580405001)(2521001)(2501002)(62966003)(19625215002)(74316001)(2656002)(50986999)(106116001)(76176999)(54356999)(40100003)(122556002)(92566002)(99286002)(87936001)(2900100001)(107886001)(76576001)(16236675004)(2950100001)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1234; H:BN3PR0301MB1234.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB123425FDAD0AE25E18AAA68FA6320BN3PR0301MB1234_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2015 21:59:08.2950 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1234
Archived-At: 
Subject: Re: [Unbearable] similarities....
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 21:59:34 -0000

--_000_BN3PR0301MB123425FDAD0AE25E18AAA68FA6320BN3PR0301MB1234_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SSBiZWxpZXZlIHRoYXQgb25lIGNvdWxkIHVzZSB3aGF0IGlzIGJlaW5nIHByb3Bvc2VkIGhlcmUg
YW5kIG5vdCBoYXZlIGEgT0FVVEggc3BlY2lmaWMgc29sdXRpb24gYXMgU1BPUCBwcm92aWRlcw0K
DQpGcm9tOiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnXSBP
biBCZWhhbGYgT2YgQmlsbCBNaWxscw0KU2VudDogVHVlc2RheSwgSmFudWFyeSAyNywgMjAxNSAx
MjoxMyBQTQ0KVG86IHVuYmVhcmFibGVAaWV0Zi5vcmcNClN1YmplY3Q6IFtVbmJlYXJhYmxlXSBz
aW1pbGFyaXRpZXMuLi4uDQoNCkFzIGFuIGFzaWRlIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LWlldGYtb2F1dGgtc3BvcC0wNiBmYWxscyByaWdodCBpbnRvIHRoaXMgc3BhY2UuDQoN
Cg==

--_000_BN3PR0301MB123425FDAD0AE25E18AAA68FA6320BN3PR0301MB1234_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs
LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90
dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3
IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K
YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu
LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh
dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K
QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx
LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x
O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz
IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp
ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h
cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp
Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBiZWxpZXZlIHRoYXQgb25lIGNvdWxkIHVz
ZSB3aGF0IGlzIGJlaW5nIHByb3Bvc2VkIGhlcmUgYW5kIG5vdCBoYXZlIGEgT0FVVEggc3BlY2lm
aWMgc29sdXRpb24gYXMgU1BPUCBwcm92aWRlczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm
O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0K
PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh
ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz
YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVW5iZWFyYWJsZSBb
bWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+
QmlsbCBNaWxsczxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDI3LCAyMDE1IDEy
OjEzIFBNPGJyPg0KPGI+VG86PC9iPiB1bmJlYXJhYmxlQGlldGYub3JnPGJyPg0KPGI+U3ViamVj
dDo8L2I+IFtVbmJlYXJhYmxlXSBzaW1pbGFyaXRpZXMuLi4uPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGRpdj4NCjxkaXYgaWQ9Inl1aV8zXzE2XzBfMV8xNDIyMTQwMTY4NTUzXzgyNzU2NSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QXMgYW4gYXNpZGUmbmJzcDs8YSBocmVmPSJodHRwOi8v
dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLXNwb3AtMDYiIGlkPSJ5dWlfM18x
Nl8wXzFfMTQyMjE0MDE2ODU1M184Mjc1NjIiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LWlldGYtb2F1dGgtc3BvcC0wNjwvYT4mbmJzcDtmYWxscw0KIHJpZ2h0IGludG8gdGhpcyBz
cGFjZS48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ieXVpXzNfMTZfMF8xXzE0MjIxNDAxNjg1NTNf
ODI3NTk0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_BN3PR0301MB123425FDAD0AE25E18AAA68FA6320BN3PR0301MB1234_--


From nobody Tue Jan 27 14:17:31 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6021A907F for ; Tue, 27 Jan 2015 14:17:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 rmroP3q3xQbS for ; Tue, 27 Jan 2015 14:17:21 -0800 (PST)
Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D5B1A6F24 for ; Tue, 27 Jan 2015 14:17:20 -0800 (PST)
Received: by mail-qg0-f46.google.com with SMTP id i50so13981113qgf.5 for ; Tue, 27 Jan 2015 14:17:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=5vFcTSOYRO+cYzhz6JPmmgZOiuilz88K3gXUegXAQPc=; b=C1szQN5MdyBKPSJxfOpjska+VFOmuKNb77KOBRP07YNRlUNpvAxVRAz/dyklKwrQ+L wo5em54yA/nooeguTGvP4Ia4NN+ruji+25x8w63GL9R8yNgAiMmGCDsCIJK/UASA0efw WH4ySkW8Tg+da2kjeQHMhI2SOCdh0a4KcWN0YMuifsYkVwIMxBFreKjyuOEDw8XpLewT bkhMiteQn+rTXUnkss972iPeHYy5ivjnRLnQ+kYyvFviIZgWauznQXFWqRckJHqg3iea iPIL75RpplpoX2MWa66gcpPO3UAk8nJ8duMzyF8KIbC8ASr+WX2o5eNWnZ3CtEIS3qEb NfpQ==
X-Gm-Message-State: ALoCoQkr0ncy7E65JXOagrjbdMksNzbDUkqkOTWvVpe4tzaSwc6vLKPVOvYRhnKjN6ageEa70qW3
X-Received: by 10.140.16.50 with SMTP id 47mr6266159qga.105.1422397039543; Tue, 27 Jan 2015 14:17:19 -0800 (PST)
Received: from [192.168.8.100] ([181.202.161.119]) by mx.google.com with ESMTPSA id i51sm2284070qgf.37.2015.01.27.14.17.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Jan 2015 14:17:18 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_0511597A-46CF-45C5-B491-31C5B9834651"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley 
In-Reply-To: 
Date: Tue, 27 Jan 2015 19:17:13 -0300
Message-Id: <22BE9680-A1F2-4B93-A5BD-7BB1B6F4A0DF@ve7jtb.com>
References: <818287466.1381395.1422389609617.JavaMail.yahoo@mail.yahoo.com> 
To: Anthony Nadalin 
X-Mailer: Apple Mail (2.2070.6)
Archived-At: 
Cc: "unbearable@ietf.org" , Bill Mills 
Subject: Re: [Unbearable] similarities....
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 22:17:23 -0000

--Apple-Mail=_0511597A-46CF-45C5-B491-31C5B9834651
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_DCFE7A07-5C1C-47E3-8CBB-B5E71D85D1EB"


--Apple-Mail=_DCFE7A07-5C1C-47E3-8CBB-B5E71D85D1EB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

SPOP now PKCE solves a issue now without changes to the browser/TLS.

In the future Token binding might be able to address the same issue (I =
hope).

However there would be the question of non browser applications like =
native OAuth apps sharing the same Token binding key store. =20
On some platforms currently apps need to provide there own TLS stack.  =20=

I am guessing that having Token binding at the OS level with a common =
TLS stack sharing keys may take a while.
It is defiantly worth exploring.

The browser and native apps not sharing the same TLS keys will slow down =
a number of possible use cases for Token binding.

John B.


> On Jan 27, 2015, at 6:59 PM, Anthony Nadalin  =
wrote:
>=20
> I believe that one could use what is being proposed here and not have =
a OAUTH specific solution as SPOP provides
> =C2=A0 <>
> From: Unbearable [mailto:unbearable-bounces@ietf.org =
] On Behalf Of Bill Mills
> Sent: Tuesday, January 27, 2015 12:13 PM
> To: unbearable@ietf.org 
> Subject: [Unbearable] similarities....
> =20
> As an aside http://tools.ietf.org/html/draft-ietf-oauth-spop-06 =
 falls right into =
this space.
> =20
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org 
> https://www.ietf.org/mailman/listinfo/unbearable =


--Apple-Mail=_DCFE7A07-5C1C-47E3-8CBB-B5E71D85D1EB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

SPOP now PKCE solves a issue now without changes to the =
browser/TLS.

In the =
future Token binding might be able to address the same issue (I =
hope).

However =
there would be the question of non browser applications like native =
OAuth apps sharing the same Token binding key store.  
On some platforms currently apps need to provide there own =
TLS stack.   
I am guessing that having =
Token binding at the OS level with a common TLS stack sharing keys may =
take a while.
It is defiantly worth =
exploring.

The =
browser and native apps not sharing the same TLS keys will slow down a =
number of possible use cases for Token binding.

John B.


On =
Jan 27, 2015, at 6:59 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:

I believe that one could use what is being =
proposed here and not have a OAUTH specific solution as SPOP =
provides
From: Unbearable =
[mailto:unbearable-bounces@ietf.org] On Behalf =
Of Bill Mills
Sent: Tuesday, January 27, 2015 =
12:13 PM
To: unbearable@ietf.org
Subject: [Unbearable] =
similarities....
 
As an aside http://tools.ietf.org/html/draft-ietf-oauth-spop-06 fa=
lls right into this space.
 
_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearable

=

--Apple-Mail=_DCFE7A07-5C1C-47E3-8CBB-B5E71D85D1EB--

--Apple-Mail=_0511597A-46CF-45C5-B491-31C5B9834651
Content-Disposition: attachment;
	filename=smime.p7s
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINPDCCBjQw
ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn
BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX
DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw
KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy
dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+
fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke
/s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk
sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH
tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w
ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd
+q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa
MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh
aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j
b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW
ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd
n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ
HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv
JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A
7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r
KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma
xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3
fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H
75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHADCCBeig
AwIBAgICSAcwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv
bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD
VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x
NDAzMjQyMzU2MjNaFw0xNjAzMjUwOTM5MzFaMIGfMRkwFwYDVQQNExBxekYwMVhZQ1pNTDM4N2hE
MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE
BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MSIwIAYJKoZIhvcNAQkBFhNq
YnJhZGxleUBpY2xvdWQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTL0o4QG
WC+jnmYa7xEjcBTAeIOt7ILy40qsnJHNedVaTH0EU5yHzoaEOGHuOuwJUz/C7r2TvXpJ/Ud4w6VO
HdOUGnnKUiH5MV/kIysZ7DpN5D1f+yEast00oKsEbf/D6flzfex2JFV9rT7AQ+FQaTdf3S9K7gM2
F5kODFg805BMYTGT+haw9VOMXju5s93VEjUQcnGrLy0RtoN76GM6ItxqNnEt/Ln+2GNq8JvPyUKe
JsAxfIlTyqIbw32VlusKXL4+jmgFi+LY6bsfg3VHLvy58QsQnCwHg15uARvy5X6owyGcG7xHwNml
fNWtBZ3DHNPh37HC9lmAy4iqw4PvNwIDAQABo4IDVTCCA1EwCQYDVR0TBAIwADALBgNVHQ8EBAMC
BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSUDb6BlJD7FIYgWj1w
4z+GsOXs7zAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzCBmQYDVR0RBIGRMIGOgRNq
YnJhZGxleUBpY2xvdWQuY29tgRNqYnJhZGxleUBpY2xvdWQuY29tgRdqb2huLmJyYWRsZXlAd2lu
Z2FhLmNvbYERdmU3anRiQHZlN2p0Yi5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFj
LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYLKwYBBAGBtTcB
AgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3
BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgEBGoG+
VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0byB0aGUgQ2xhc3MgMiBWYWxp
ZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20gQ0EgcG9saWN5LCByZWxpYW5jZSBv
bmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBjb21wbGlhbmNlIG9mIHRoZSByZWx5aW5n
IHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3Ns
LmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8v
b2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6
Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBALscEldbrgeF
B1WC/hMdYxFT4Lc8ALtErgJryRozTdeMlzpsncIKyy8M54HhxQAMOqFe2HR+R9H7WeIzmkV95yJn
JY3bd4bxnnemhLrDyi1VlNjEjkK5kgegI8JavahFXl4FwJHHv8TOh71Wf3fiy0Do7d7TQmVDRrzt
1k/2w4CXKweQ2mdFw7fskiYoPGEK7pFiicGMFBzLiKRm61CqojS4IYShiP0nCZZWPwNJYs5lstxD
SSMaD+KccZVxkL7X2Qj9PJ+PCAQ6dMhvwTXrdcnrE7fI8PhFvHWrERjg7yIu1WI4Fgviy0u7437v
WzufSnfqMwbfz20fucO0chYq+tkxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp
ZW50IENBAgJIBzAJBgUrDgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG
SIb3DQEJBTEPFw0xNTAxMjcyMjE3MTRaMCMGCSqGSIb3DQEJBDEWBBSec3KsfMRn41yt+PlLez54
IfiazzCBpAYJKwYBBAGCNxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD
b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYG
A1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAkgH
MIGmBgsqhkiG9w0BCRACCzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgJIBzAN
BgkqhkiG9w0BAQEFAASCAQB5Zz0WcEUuZQp8qeNStDZlWT30N4Lvr0JigwQvcpuzctsgaE4KTDh+
TDbxuz2PXCDeFjT7ITT4NRHI5ZN24bNb8NuzOfnG+lDXFkydFt/2ZXDu5Wqf7qp/YTrKUirPOyMN
3y01oyzjsnarfIsLO8GgYUOHsIiWe6PYjz9Kr5bOyqkyMDa3H8O1QWsOQoQDALzqPA+6V15erz4/
OJtidJpgGhgzC8C+CdWylnC9z6/6G9q5RhMTylrPXVTDEj+z7rZiReNWngbgzB7e8gdEO8xLOd5u
ckZF55hqVDJtAoR27fA6p//rcTp6zLtSvyv5n3D2CCavO3XXukJvz84Hg2IQAAAAAAAA
--Apple-Mail=_0511597A-46CF-45C5-B491-31C5B9834651--


From nobody Tue Jan 27 14:19:24 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65B661A907C for ; Tue, 27 Jan 2015 14:19:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.191
X-Spam-Level: *
X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 9_qjX9HhUFOV for ; Tue, 27 Jan 2015 14:19:16 -0800 (PST)
Received: from nm36-vm8.bullet.mail.bf1.yahoo.com (nm36-vm8.bullet.mail.bf1.yahoo.com [72.30.239.70]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13DB81A9046 for ; Tue, 27 Jan 2015 14:19:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1422397155; bh=gIqGaET0IWhvwp/6Y9G7gN6Aq7hWvzsb6efF8AfXkmU=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=qsC/Wtyv4HQ3HG7sPJigPK7kp9q8tepWDwvflASmlGxKJXqAAl7qP8VgEF/pTu6g+5HBvnsBy/6/9pzPajv5JOP+akdHkQ26+4iIXbZODYLBL5XZZeyiLPtT26pzpa8i8rFzq/ok/MqRtNK/eSLn/etcF5dBQ4B9A2UaUMW3xQs81qr90P98IuNTDnZDSI1SIE62d9s2QhzSzaxbcVioaHMjRO5iHxQvwoxfT0L6s+TmBZtbZnUIxoBbAAC94C4DuXxcuvJKdSKVralK0iHdS3B4V9rhnOULk2ESdDRDfJwej5kuFPSnoLA/6GdUs9ZNG3bbpW7J7VyJXKzHDQTWNQ==
Received: from [98.139.215.140] by nm36.bullet.mail.bf1.yahoo.com with NNFMP;  27 Jan 2015 22:19:15 -0000
Received: from [98.139.212.215] by tm11.bullet.mail.bf1.yahoo.com with NNFMP;  27 Jan 2015 22:19:15 -0000
Received: from [127.0.0.1] by omp1024.mail.bf1.yahoo.com with NNFMP; 27 Jan 2015 22:19:15 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 216656.71735.bm@omp1024.mail.bf1.yahoo.com
X-YMail-OSG: pkncT8YVM1mHqpuq.gwMdzG9EkeXchQrLFboouV0gfTAfdGuxoaHYuJahojbH1i b.0JhxlH2UfWDm9QEiZAPalgxmDBOeay9VOt6XrfTfJ6.wfV0WJPcVX7SdPZ0G5YoHVA41eh4gN8 k_tTcRe0AKMmr46dkLl2SWcSpFqOm.kyyEDE9PUgpBVjZB7ikr63CEPM0VpGOOYI8n8mswmkVI16 ntuIzWdOUtgZsgZmDt4w17Rk1eI6TohSIS61HKOJ8cHQSFPOrXUTPRZAwTtom0hr4hsxBS6tqs8I XwFgeV.E2g72CfnFQOzC7zaSeWIqKzNHwSnuSIy7PLqsTsIUZOvZ.lYU3ZZ_chZ26WHZ8.wvldCM JT0kZaSdXaSplHDVRNs4QKm5Aj8bNjKiIo7fDC_B8S8B2_eqaQAiKdbCW6MwZvufQ8sac787f9Bm 1sbu8kriBoj7UYUZq3CYNKtN0oBFZVjTw_7LyJaeeb15hmIadLKMw1okOwdTFryvT.sI5NSX75ls 59eLcFF7tzWc-
Received: by 66.196.80.193; Tue, 27 Jan 2015 22:19:14 +0000 
Date: Tue, 27 Jan 2015 22:19:14 +0000 (UTC)
From: Bill Mills 
To: Anthony Nadalin ,  "unbearable@ietf.org" 
Message-ID: <1267799882.1455180.1422397154420.JavaMail.yahoo@mail.yahoo.com>
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: multipart/alternative;  boundary="----=_Part_1455179_1501525598.1422397154416"
Archived-At: 
Subject: Re: [Unbearable] similarities....
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Bill Mills 
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Jan 2015 22:19:18 -0000

------=_Part_1455179_1501525598.1422397154416
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


 Yes. =C2=A0There are some design choices to think about. =C2=A0SPOP is usi=
ng a relatively cheap hash and disposable one-use secrets which is a bit di=
fferent, so there is an interesting practical question of whether a PK sign=
ature check would be acceptable. =C2=A0You could certainly assert a public =
key instead of the hashed code verifier and send a signature of the code an=
d the public key as the verifier to get the same result SPOP does.

     On Tuesday, January 27, 2015 1:59 PM, Anthony Nadalin  wrote:
  =20

 #yiv6702337357 -- filtered {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 =
2 2 4;}#yiv6702337357 filtered {panose-1:2 4 5 3 5 4 6 3 2 4;}#yiv670233735=
7 filtered {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv67023373=
57 p.yiv6702337357MsoNormal, #yiv6702337357 li.yiv6702337357MsoNormal, #yiv=
6702337357 div.yiv6702337357MsoNormal {margin:0in;margin-bottom:.0001pt;fon=
t-size:12.0pt;}#yiv6702337357 a:link, #yiv6702337357 span.yiv6702337357MsoH=
yperlink {color:blue;text-decoration:underline;}#yiv6702337357 a:visited, #=
yiv6702337357 span.yiv6702337357MsoHyperlinkFollowed {color:purple;text-dec=
oration:underline;}#yiv6702337357 span.yiv6702337357EmailStyle17 {color:#1F=
497D;}#yiv6702337357 .yiv6702337357MsoChpDefault {font-size:10.0pt;}#yiv670=
2337357 filtered {margin:1.0in 1.0in 1.0in 1.0in;}#yiv6702337357 div.yiv670=
2337357WordSection1 {}#yiv6702337357 I believe that one could use what is b=
eing proposed here and not have a OAUTH specific solution as SPOP provides =
 =C2=A0 From: Unbearable [mailto:unbearable-bounces@ietf.org]On Behalf Of B=
ill Mills
Sent: Tuesday, January 27, 2015 12:13 PM
To: unbearable@ietf.org
Subject: [Unbearable] similarities....  =C2=A0 As an aside=C2=A0http://tool=
s.ietf.org/html/draft-ietf-oauth-spop-06=C2=A0falls right into this space. =
 =C2=A0=20

   
------=_Part_1455179_1501525598.1422397154416
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



 =

Yes.  There are some design choices to think about=
.  SPOP is using a relatively cheap hash and disposable one-use secret=
s which is a bit different, so there is an interesting practical question o=
f whether a PK signature check would be acceptable.  You could certain=
ly assert a public key instead of the hashed code verifier and send a signa=
ture of the code and the public key as the verifier to get the same result =
SPOP does.


 
 
  On Tuesday, January 2=
7, 2015 1:59 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:
  
  

 




I b=
elieve that one could use what is being proposed here and not have a OAUTH =
specific solution as SPOP provides
=20

  <=
/span>
=20





=
From: Unbearable [mailto:unbea=
rable-bounces@ietf.org]
On Behalf Of Bill Mills

Sent: Tuesday, January 27, 2015 12:13 PM

To: unbearable@ietf.org

Subject: [Unbearable] similarities....
=20





  
=20





As an aside http://tools.=
ietf.org/html/draft-ietf-oauth-spop-06 falls
 right into this space.<=
/div>=20





  
=20









  
 
  
 

------=_Part_1455179_1501525598.1422397154416--


From nobody Fri Jan 30 14:59:01 2015
Return-Path: 
X-Original-To: unbearable@ietfa.amsl.com
Delivered-To: unbearable@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9BD31A8763 for ; Fri, 30 Jan 2015 14:58:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level: 
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 1GXBiWDPeKyE for ; Fri, 30 Jan 2015 14:58:52 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0771.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::771]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7941A873A for ; Fri, 30 Jan 2015 14:58:51 -0800 (PST)
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) by BN3PR0301MB1250.namprd03.prod.outlook.com (25.161.207.26) with Microsoft SMTP Server (TLS) id 15.1.65.19; Fri, 30 Jan 2015 22:58:28 +0000
Received: from BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) by BN3PR0301MB1250.namprd03.prod.outlook.com ([25.161.207.26]) with mapi id 15.01.0065.013; Fri, 30 Jan 2015 22:58:28 +0000
From: Andrei Popov 
To: Andrei Popov , Bill Mills , Stephen Farrell , Kathleen Moriarty 
Thread-Topic: [Unbearable] Updated Charter Proposal
Thread-Index: AdAwVoQybrCT+HkuTniRvdMsDdHeWgAkZqIAAAL3ZlAAAwXvAAEDcGvAAMwnb4AAALRNgAAAnOkAAGI6TVAAxMzo0A==
Date: Fri, 30 Jan 2015 22:58:28 +0000
Message-ID: 
References: <54C44BD9.6010507@cs.tcd.ie> <1028652913.19992.1422151670194.JavaMail.yahoo@mail.yahoo.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [2001:4898:80e8:ed31::3]
authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB1250;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB1250; 
x-forefront-prvs: 04724A515E
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(479174004)(24454002)(51704005)(377454003)(164054003)(19625215002)(33656002)(40100003)(54606007)(1511001)(86612001)(46102003)(19580405001)(19617315012)(2521001)(76176999)(86362001)(50986999)(92566002)(74316001)(122556002)(2561002)(2421001)(54356999)(19609705001)(76576001)(16236675004)(62966003)(77156002)(2656002)(87936001)(2900100001)(54206007)(561944003)(19300405004)(19580395003)(2950100001)(102836002)(15975445007)(2420400003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB1250; H:BN3PR0301MB1250.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; 
Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB12503B0B51D3D03E37036A2A8C310BN3PR0301MB1250_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.onmicrosoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2015 22:58:28.5058 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB1250
Archived-At: 
Cc: John Bradley , "unbearable@ietf.org" 
Subject: Re: [Unbearable] Updated Charter Proposal
X-BeenThere: unbearable@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"This list is for discussion of proposals for doing better than bearer tokens \(e.g. HTTP cookies, OAuth tokens etc.\) for web applications. The specific goal is chartering a WG focused on preventing security token export and replay attacks.\"" 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Jan 2015 22:58:59 -0000

--_000_BN3PR0301MB12503B0B51D3D03E37036A2A8C310BN3PR0301MB1250_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U2luY2Ugbm9ib2R5IHNlZW1zIHRvIG9iamVjdCwgSeKAmXZlIHB1c2hlZCBCaWxs4oCZcyBjaGFu
Z2UgdG8gR2l0SHViPGh0dHBzOi8vZ2l0aHViLmNvbS9Ub2tlbkJpbmRpbmcvV0ctQ2hhcnRlcj4u
DQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJh
YmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmRyZWkgUG9wb3YNClNlbnQ6IE1v
bmRheSwgSmFudWFyeSAyNiwgMjAxNSA1OjA4IFBNDQpUbzogQmlsbCBNaWxsczsgU3RlcGhlbiBG
YXJyZWxsOyBLYXRobGVlbiBNb3JpYXJ0eQ0KQ2M6IEpvaG4gQnJhZGxleTsgdW5iZWFyYWJsZUBp
ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBVcGRhdGVkIENoYXJ0ZXIgUHJvcG9z
YWwNCg0KQWZ0ZXIgY2hhdHRpbmcgd2l0aCBCaWxsIG9mZi1saXN0LCBoZXJlIGlzIHRoZSBzcGVj
aWZpYyBjaGFuZ2UgcHJvcG9zZWQuDQoNClRoZSBjaGFydGVyIGRyYWZ0IGN1cnJlbnRseSBzYXlz
Og0K4oCcVG9rZW4gQmluZGluZyBlbmFibGVzIGRlZmVuc2UgYWdhaW5zdCBzdWNoIGF0dGFja3Mg
YnkgY3J5cHRvZ3JhcGhpY2FsbHkgYmluZGluZyBzZWN1cml0eSB0b2tlbnMgdG8gdGhlIFRMUyBs
YXllci7igJwNCg0KVGhlIHByb3Bvc2VkIHRleHQ6DQrigJxUb2tlbiBCaW5kaW5nIGVuYWJsZXMg
ZGVmZW5zZSBhZ2FpbnN0IHN1Y2ggYXR0YWNrcyBieSBjcnlwdG9ncmFwaGljYWxseSBiaW5kaW5n
IHNlY3VyaXR5IHRva2VucyB0byBhIHNlY3JldCBoZWxkIGJ5IHRoZSBjbGllbnQu4oCcDQoNCklm
IHRoZSBtYWlsaW5nIGxpc3QgaXMgT0sgd2l0aCB0aGlzIGNoYW5nZSwgSeKAmWxsIGdvIGFoZWFk
IGFuZCB1cGRhdGUgdGhlIGNoYXJ0ZXIgZHJhZnQuDQoNClRoYW5rcywNCg0KQW5kcmVpDQoNCkZy
b206IEJpbGwgTWlsbHMgW21haWx0bzp3bWlsbHNfOTIxMDVAeWFob28uY29tXQ0KU2VudDogU2F0
dXJkYXksIEphbnVhcnkgMjQsIDIwMTUgNjowOCBQTQ0KVG86IFN0ZXBoZW4gRmFycmVsbDsgS2F0
aGxlZW4gTW9yaWFydHk7IEFuZHJlaSBQb3Bvdg0KQ2M6IEpvaG4gQnJhZGxleTsgdW5iZWFyYWJs
ZUBpZXRmLm9yZzxtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVW5i
ZWFyYWJsZV0gVXBkYXRlZCBDaGFydGVyIFByb3Bvc2FsDQoNCk15IGlzc3VlIGlzIGFnYWluIHdp
dGggdGhlIHRleHQgImJpbmRpbmcgdG8gdGhlIFRMUyBsYXllciIsIHRoYXQncyBjaGFubmVsIGJp
bmRpbmcuDQoNCk9uIFNhdHVyZGF5LCBKYW51YXJ5IDI0LCAyMDE1IDU6NTAgUE0sIFN0ZXBoZW4g
RmFycmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZTxtYWlsdG86c3RlcGhlbi5mYXJyZWxs
QGNzLnRjZC5pZT4+IHdyb3RlOg0KDQoNCkNoZWVycywNCg0KRWRpdGluZyB3aWxsIGVuc3VlOi0p
DQoNClMNCg0KT24gMjUvMDEvMTUgMDE6MzAsIEthdGhsZWVuIE1vcmlhcnR5IHdyb3RlOg0KPiBI
aSwNCj4NCj4gVGhlIGNoYXJ0ZXIgbG9va3MgbGlrZSBpdCBpcyBzaGFwaW5nIHVwLiAgSSBqdXN0
IGhhdmUgc29tZSBlZGl0b3JpYWwNCj4gc3VnZ2VzdGlvbnMgYXMgdGhlIGRpc2N1c3Npb24gY29u
dGludWVzLCB0YWtlIHRoZW0gb3IgbGVhdmUgdGhlbSwgbm90DQo+IGEgYmlnIGRlYWwuDQo+DQo+
IFN1Z2dlc3QgY2hhbmdpbmcgZnJvbToNCj4gVGhlIGlkZWEgb2YgVG9rZW4gQmluZGluZyBpcyB0
byBlbmFibGUgZGVmZW5zZSBhZ2FpbnN0IHN1Y2ggYXR0YWNrcyBieQ0KPiBjcnlwdG9ncmFwaGlj
YWxseSBiaW5kaW5nDQo+IHNlY3VyaXR5IHRva2VucyB0byB0aGUgVExTIGxheWVyLg0KPg0KPiBU
bzoNCj4gVG9rZW4gQmluZGluZyBlbmFibGVzIGRlZmVuc2UgYWdhaW5zdCBzdWNoIGF0dGFja3Mg
YnkgY3J5cHRvZ3JhcGhpY2FsbHkgYmluZGluZw0KPiBzZWN1cml0eSB0b2tlbnMgdG8gdGhlIFRM
UyBsYXllci4NCj4NCj4gVGhlIHdvcmQgZ29hbCBpcyB1c2VkIGEgYml0IG11Y2gsIGJ1dCB0aGlz
IGlzIGEgcGVyc29uYWwgcHJlZmVyZW5jZSAtDQo+IHRha2Ugb3IgbGVhdmUgdGhlIHN1Z2dlc3Rp
b25zLiAgSSBzdWdnZXN0IHJlbW92aW5nICJTb21lIiBpbiB0aGUgbGFzdA0KPiBzZW50ZW5jZSBs
aXN0ZWQgYXMgdGhpcyBvbmx5IHNheXMgdGhlICJtYWluIiBnb2Fscy9vYmplY3RpdmVzLCBzbw0K
PiB0aGVyZSBpcyB3aWdnbGUgcm9vbSBzdGlsbC4NCj4NCj4gRnJvbToNCj4gSXQgaXMgYSBnb2Fs
IG9mIHRoaXMgd29ya2luZyBncm91cCB0byBlbmFibGUgZGVmZW5zZSBhZ2FpbnN0IGF0dGFja3MN
Cj4gdGhhdCBpbnZvbHZlIHVuYXV0aG9yaXplZCByZXBsYXkgb2YNCj4gc2VjdXJpdHkgdG9rZW5z
LCBidXQgb3RoZXIgaXNzdWVzIGFzc29jaWF0ZWQgd2l0aCB0aGUgdXNlIG9mIHNlY3VyaXR5DQo+
IHRva2VucyBhcmUgb3V0IG9mIHNjb3BlLiBJdCBpcyBhIGdvYWwNCj4gb2YgdGhpcyB3b3JraW5n
IGdyb3VwIHRvIGRlc2lnbiB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCBzdWNoIHRoYXQNCj4g
aXQgd291bGQgYmUgYWxzbyB1c2VhYmxlIHdpdGgNCj4gYXBwbGljYXRpb24gcHJvdG9jb2xzIG90
aGVyIHRoYW4gSFRUUFMsIGhvd2V2ZXIgc3BlY2lmeWluZyBzdWNoIHVzZXMNCj4gaXMgbm90IGEg
cHJpbWFyeSBnb2FsLg0KPg0KPiBTb21lIG9mIHRoZSBtYWluIGRlc2lnbiBnb2FscyBmb3IgdGhl
IFRva2VuIEJpbmRpbmcgcHJvdG9jb2wsIGluIG5vDQo+IHBhcnRpY3VsYXIgb3JkZXI6DQo+DQo+
IFRvOg0KPiBJdCBpcyBhIGdvYWwgb2YgdGhpcyB3b3JraW5nIGdyb3VwIHRvIGVuYWJsZSBkZWZl
bnNlIGFnYWluc3QgYXR0YWNrcw0KPiB0aGF0IGludm9sdmUgdW5hdXRob3JpemVkIHJlcGxheSBv
Zg0KPiBzZWN1cml0eSB0b2tlbnMuICBPdGhlciBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIHRoZSB1
c2Ugb2Ygc2VjdXJpdHkNCj4gdG9rZW5zIGFyZSBvdXQgb2Ygc2NvcGUuIEFub3RoZXIgZ29hbA0K
PiBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAgaXMgdG8gZGVzaWduIHRoZSBUb2tlbiBCaW5kaW5nIHBy
b3RvY29sIHN1Y2gNCj4gdGhhdCBpdCB3b3VsZCBiZSBhbHNvIHVzZWFibGUgd2l0aA0KPiBhcHBs
aWNhdGlvbiBwcm90b2NvbHMgb3RoZXIgdGhhbiBIVFRQUy4gIFNwZWNpZnlpbmcgYWx0ZXJuYXRl
DQo+IGFwcGxpY2F0aW9uIHByb3RvY29scyBpcyBub3QgYSBwcmltYXJ5IGdvYWwuDQo+DQo+IFRo
ZSBtYWluIGRlc2lnbiBvYmplY3RpdmVzIGZvciB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCwg
aW4gbm8NCj4gcGFydGljdWxhciBvcmRlcjoNCj4NCj4gIzggLSBzcGVjIHNob3VsZCBwcm9iYWJs
eSBiZSBzcGVsbGVkIG91dCBhcyBzcGVjaWZpY2F0aW9uLg0KPg0KPiBUaGFua3MsDQo+IEthdGhs
ZWVuDQo+DQo+DQo+IE9uIFR1ZSwgSmFuIDIwLCAyMDE1IGF0IDc6MDcgUE0sIEFuZHJlaSBQb3Bv
dg0KPiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNy
b3NvZnQuY29tPj4gd3JvdGU6DQo+PiBJIGJlbGlldmUgSeKAmXZlIGFkZHJlc3NlZCB0aGUgZmVl
ZGJhY2sgcmVjZWl2ZWQgc28gZmFyOyB0aGUgdXBkYXRlZCBjaGFydGVyDQo+PiBkcmFmdCBpcyBv
biBHaXRIdWIgZm9yIGVhc3kgYXV0aG9yaW5nOg0KPj4NCj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9U
b2tlbkJpbmRpbmcvV0ctQ2hhcnRlcg0KPj4NCj4+DQo+Pg0KPj4gUHVsbCByZXF1ZXN0cyBhcmUg
d2VsY29tZSwNCj4+DQo+Pg0KPj4NCj4+IFRoYW5rcywNCj4+DQo+Pg0KPj4NCj4+IEFuZHJlaQ0K
Pj4NCj4+DQo+Pg0KPj4gRnJvbTogSm9obiBCcmFkbGV5IFttYWlsdG86dmU3anRiQHZlN2p0Yi5j
b208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPl0NCj4+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5
IDE1LCAyMDE1IDEyOjE2IFBNDQo+Pg0KPj4NCj4+IFRvOiBBbmRyZWkgUG9wb3YNCj4+IENjOiB1
bmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzp1bmJlYXJhYmxlQGlldGYub3JnPg0KPj4gU3ViamVj
dDogUmU6IFtVbmJlYXJhYmxlXSBVcGRhdGVkIENoYXJ0ZXIgUHJvcG9zYWwNCj4+DQo+Pg0KPj4N
Cj4+IEEgY291cGxlIG1vcmUgcG9zc2libGUgY2xhcmlmaWNhdGlvbnMuDQo+Pg0KPj4NCj4+DQo+
Pg0KPj4NCj4+DQo+Pg0KPj4gMi4gICAgICAgICAgICBTcGVjaWZ5IHRoZSB1c2Ugb2YgdGhlIFRv
a2VuIEJpbmRpbmcgcHJvdG9jb2wgaW4gY29tYmluYXRpb24NCj4+IHdpdGggSFRUUFMuDQo+Pg0K
Pj4NCj4+DQo+PiBIVFRQUyBpcyBwcm9iYWJseSBpbnRlbmRlZCB0byBiZSBzaG9ydGhhbmQgZm9y
IGEgaHR0cCBiaW5kaW5nIGZvciBUTFMgKw0KPj4gdG9rZW4gQmluZGluZyBhcyBpcyBkZWZpbmVk
IGluICJUb2tlbiBCaW5kaW5nIG92ZXIgSFRUUCINCj4+IFtodHRwczovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtYmFsZmFuei1odHRwcy10b2tlbi1iaW5kaW5nLTAwXS4NCj4+DQo+Pg0KPj4N
Cj4+IFRoaXMgaXMgYSBiaW5kaW5nIHRvIEhUVFAgKHZpYSBhIG5ldyBoZWFkZXIpIGFuZCB0byBI
VE1MICAodmlhIFhNTCBIVFRQDQo+PiByZXF1ZXN0KS4NCj4+DQo+Pg0KPj4NCj4+IElmIHdlIGFs
c28gc2F5IHRoYXQgcG9zc2libGUgZnV0dXJlIGJpbmRpbmcgbWF5IGJlIGEgU0FTU0wvR1NTLUFQ
SSBiaW5kaW5nDQo+PiBmb3IgVExTICsgdG9rZW4gYmluZGluZyAgKFRoZSBzYXNzbC1vYXV0aCBz
cGVjDQo+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1raXR0ZW4tc2Fz
bC1vYXV0aC0xOCBtaWdodCB1c2Ugc3VjaCBhDQo+PiB0aGluZy4pDQo+Pg0KPj4NCj4+DQo+Pg0K
Pj4NCj4+IE9uZSBvdGhlciB0aGluZyBJIG5vdGUgaW4gdGhlIGRyYWZ0cywgaXMgdGhhdCBhdCBu
byBwb2ludCBhcmUgIHRva2Vucw0KPj4gZGVmaW5lZCBvciBldmVuIHJlYWxseSBkaXNjdXNzZWQg
b3RoZXIgdGhhbiBhcyBzb21ldGhpbmcgdGhhdCBhcHBsaWNhdGlvbnMNCj4+IGNhbiBiaW5kIHRv
IHRoZSBleHBvc2VkIHB1YmxpYyBrZXkuDQo+Pg0KPj4gVGhlIGFwcGxpY2F0aW9ucyB3aWxsIGJp
bmQgdG9rZW5zIHRvIHRoZSBrZXlzIGV4cG9zZWQgYnkgdGhlIHNwZWNzIHZpYSB0aGUNCj4+IGJp
bmRpbmdzLiAgVGhlIG5hbWluZyBtYXkgc2xpZ2h0bHkgbWlzZGlyZWN0IHBlb3BsZSwgYnV0IHRo
ZXJlIGhhdmUgYWxyZWFkeQ0KPj4gYmVlbiB0b28gbWFueSBuYW1lcyBmb3IgdGhpcyBzbyBJIHdv
bid0IHB1c2ggdGhlIHBvaW50Lg0KPj4NCj4+DQo+Pg0KPj4gSSB0aGluayBrZWVwaW5nIHRoaXMg
ZG93biBjbG9zZSB0byB0aGUgVExTIGxheWVyIGFuZCBkZWZpbmluZyBiaW5kaW5ncyB0bw0KPj4g
SFRUUCBhbmQgb3RoZXIgcHJvdG9jb2xzIGlzIGluIHNjb3BlLg0KPj4NCj4+IEVuY291cmFnaW5n
IGFwcGxpY2F0aW9ucyB0aGF0IHVzZSBwcm90b2NvbHMgbGlrZSBIVFRQICsgVExTIHRvIHVzZSB0
aGUNCj4+IGJpbmRpbmdzIHRvIGJpbmQgdGhlcmUgc2VjdXJpdHkgdG9rZW5zL2Nvb2tpZXMgaXMg
aW4gc2NvcGUuDQo+Pg0KPj4NCj4+DQo+PiBJIHRoaW5rIGRlZmluaW5nIHRoZSBleHRlbnNpb25z
IGZvciB0aG9zZSBhcHBsaWNhdGlvbnMgdG8gdXNlIHRoZSBiaW5kaW5ncw0KPj4gaXMgc2hvdWxk
IGJlIHVwIHRvIHRoZSBhcHBsaWNhdGlvbnMgdGhlbXNlbHZlcyB3aGVyZSB0aGVyZSBpcyBhY3Rp
dmUNCj4+IHBhcnRpY2lwYXRpb24uDQo+Pg0KPj4NCj4+DQo+PiBUcnlpbmcgdG8gZXh0ZW5kIHRo
aXMgdG8gY292ZXIgZW5kIHRvIGVuZCBtZXNzYWdlIHNpZ25pbmcgb3V0c2lkZSBvZiBhIFRMUw0K
Pj4gc2Vzc2lvbiBzaG91bGQgYmUgZXhwcmVzc2x5IG91dCBvZiBzY29wZS4NCj4+DQo+Pg0KPj4N
Cj4+IFdlIG1heSBob3dldmVyIHdhbnQgdG8gc2F5IHNvbWV0aGluZyBhYm91dCBob3cgYSBUTFMg
c2Vzc2lvbiB0ZXJtaW5hdGVkIG9uIGENCj4+IFRMUyBkZXZpY2UgY2FuIGhhdmUgdGhlIFRva2Vu
IEJpbmRpbmcgSUQgZm9yIHRoZSBzZXNzaW9uIHBhc3NlZCBpbiBhIEhUVFANCj4+IGhlYWRlci4N
Cj4+DQo+PiBUaGF0IGFuZCBwb3NzaWJseSBzb21lIG90aGVyIFRMUyBhcHBsaWFuY2UgaXNzdWVz
IGFyZSBpbiBzY29wZSBmb3IgIlRva2VuDQo+PiBCaW5kaW5nIG92ZXIgSFRUUCINCj4+DQo+Pg0K
Pj4NCj4+IFJlZ2FyZHMNCj4+DQo+PiBKb2huIEIuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+
Pg0KPj4gT24gSmFuIDE1LCAyMDE1LCBhdCAzOjUyIFBNLCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Q
b3BvdkBtaWNyb3NvZnQuY29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+DQo+
PiB3cm90ZToNCj4+DQo+Pg0KPj4NCj4+IFRoYW5rcyBKb2huOyBib3RoIHN1Z2dlc3Rpb25zIG1h
a2Ugc2Vuc2UgdG8gbWU7IHdpbGwgcmVwaHJhc2UgaW4gdGhlIG5leHQNCj4+IHJldmlzaW9uLg0K
Pj4NCj4+DQo+Pg0KPj4gQ2hlZXJzLA0KPj4NCj4+DQo+Pg0KPj4gQW5kcmVpDQo+Pg0KPj4NCj4+
DQo+PiBGcm9tOiBKb2huIEJyYWRsZXkgW21haWx0bzp2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86
dmU3anRiQHZlN2p0Yi5jb20+XQ0KPj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTUsIDIwMTUg
OToyNSBBTQ0KPj4gVG86IEFuZHJlaSBQb3Bvdg0KPj4gQ2M6IHVuYmVhcmFibGVAaWV0Zi5vcmc8
bWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmc+DQo+PiBTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVd
IFVwZGF0ZWQgQ2hhcnRlciBQcm9wb3NhbA0KPj4NCj4+DQo+Pg0KPj4gSSBhbSBnZW5lcmFsbHkg
aW4gYWdyZW1lbnQuDQo+Pg0KPj4NCj4+DQo+PiBBIGNvdXBsZSBvZiBwb2ludHMuDQo+Pg0KPj4N
Cj4+DQo+PiBVbmRlciBkZXNpZ24gZ29hbHMgY2hhbmdlIDEgdG8uDQo+Pg0KPj4NCj4+DQo+PiAx
LiAgQWxsb3cgYXBwbGljYXRpb25zIHRvIHByZXZlbnQgdGhlIGV4cG9ydCBhbmQgcmVwbGF5IG9m
IHNlY3VyaXR5IHRva2Vucy4NCj4+DQo+Pg0KPj4NCj4+IFlvdSBjb3VsZCBtYWtlIHRoYXQgYXBw
bGljYXRpb25zIGFuZCBwcm90b2NvbHMgaWYgeW91IGxpa2UgYXMgc29tZSBwZW9wbGUNCj4+IG1h
eSBzZWUgdGhpbmdzIGxpa2UgT0F1dGggYXMgYSBwcm90b2NvbCB2cyBhbiBhcHBsaWNhdGlvbi4N
Cj4+DQo+PiBUaGUgcG9pbnQgYmVpbmcgdGhhdCB0aGUgZ29hbCBpcyB0byBwcm92aWRlIHRoZSBo
b29rcyBmb3IgdGhpbmdzIGEgbGF5ZXINCj4+IGFib3ZlIHRoZXNlIHNwZWNpZmljYXRpb25zIHRv
IG1ha2Ugc2VjdXJpdHkgZGVjaXNpb25zLCBub3QgdGhlIHRva2VuIGJpbmRpbmcNCj4+IHByb3Rv
Y29sIGl0c2VsZi4NCj4+DQo+Pg0KPj4NCj4+DQo+Pg0KPj4gSW4gMyB5b3UgdXNlIHRoZSB0ZXJt
IGZlZGVyYXRpb24uICBUaGF0IG1heSBiZSBsYXJnZXIgaW4gc2NvcGUgdGhhbiB3aGF0IEkNCj4+
IHRoaW5rIHlvdSBpbnRlbmQgZnJvbSB0aGUgdHdvIGRyYWZ0cy4NCj4+DQo+PiBGZWRlcmF0aW9u
IGlzIGEgbXVjaCBsYXJnZXIgdG9waWMgdGhhbiBhbGxvd2luZyB0aGUgcHVibGljIGtleSBmcm9t
IG9uZQ0KPj4gY29ubmVjdGlvbiB0byBiZSBleHBvc2VkIGluIGEgY29ubmVjdGlvbiB0byBhIHNl
Y29uZCBwYXJ0eSB2aWEgc29tZSBzb3J0IG9mDQo+PiBleHByZXNzIGNvbnNlbnQgZnJvbSB0aGUg
Zmlyc3QgcGFydHkuDQo+Pg0KPj4NCj4+DQo+PiBTaHJpbmtpbmcgdGhlIHNjb3BlIHRvIGhvdyBw
dWJsaWMga2V5cyBtYXkgYmUgc2hhcmVkIHdpdGggcGVybWlzc2lvbiB0bw0KPj4gdGhpcmQgcGFy
dGllcyBtYXkgbWFrZSBzb21lIHBlb3BsZSBtb3JlIGNvbWZvcnRhYmxlLCBpZiB0aGV5IGFyZSBj
b25jZXJuZWQNCj4+IHRoYXQgdGhpcyBpcyB0cnlpbmcgdG8gYmUgYSBuZXcgZmVkZXJhdGlvbiBw
cm90b2NvbCB0byBjb21wZXRlIHdpdGggU0FNTCBvcg0KPj4gT0F1dGguDQo+Pg0KPj4NCj4+DQo+
PiBSZWdhcmRzDQo+Pg0KPj4gSm9obiBCLg0KPj4NCj4+DQo+Pg0KPj4gT24gSmFuIDE0LCAyMDE1
LCBhdCA5OjE0IFBNLCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPG1h
aWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+DQo+PiB3cm90ZToNCj4+DQo+Pg0KPj4N
Cj4+IFRoZSBkaXNjdXNzaW9uIG9uIHRoaXMgbWFpbGluZyBsaXN0IGhhcyBzdWJzaWRlZCBvdmVy
IHRoZSBob2xpZGF5cywgc28gSQ0KPj4gbG9va2VkIHRocm91Z2ggdGhlIG1lc3NhZ2VzIGZvciBm
ZWVkYmFjayByZWdhcmRpbmcgdGhlIHByb3Bvc2VkIGNoYXJ0ZXIgYW5kDQo+PiBpbmNvcnBvcmF0
ZWQgYSBjb3VwbGUgb2YgY2hhbmdlcyBzdWdnZXN0ZWQgc28gZmFyOg0KPj4NCj4+IDEuIEEgbmV3
IGRlc2lnbiBnb2FsOiB0aGUgc29sdXRpb24gbXVzdCB3b3JrIGZvciBXZWIgYnJvd3NlcnMuIEUu
Zy4gdGhpcw0KPj4gbWVhbnMgdGhhdCBzZWN1cml0eSB0b2tlbnMgbXVzdCBiZSBwcmVzZW50YWJs
ZSBvdmVyIG11bHRpcGxlIFRMUyBzZXNzaW9ucw0KPj4gYW5kIGNvbm5lY3Rpb25zLg0KPj4NCj4+
IDIuIFJlbW92ZWQgc3BlY2lmaWMgbWlsZXN0b25lIGRhdGVzLg0KPj4NCj4+DQo+Pg0KPj4gTG9v
a2luZyBmb3J3YXJkIHRvIG1vcmUgZGlzY3Vzc2lvbiBvZiB0aGUgY2hhcnRlciwNCj4+DQo+Pg0K
Pj4NCj4+IFRoYW5rcywNCj4+DQo+Pg0KPj4NCj4+IEFuZHJlaQ0KPj4NCj4+DQo+Pg0KPj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+DQo+
PiBUb2tlbiBCaW5kaW5nIChUQikNCj4+DQo+Pg0KPj4NCj4+IENoYXJ0ZXIgZm9yIFdvcmtpbmcg
R3JvdXANCj4+DQo+Pg0KPj4NCj4+IFdlYiBzZXJ2aWNlcyBnZW5lcmF0ZSB2YXJpb3VzIHNlY3Vy
aXR5IHRva2VucyAoZS5nLiAgSFRUUCBjb29raWVzLCBPQXV0aA0KPj4gdG9rZW5zLCBldGMuKSBm
b3Igd2ViIGFwcGxpY2F0aW9ucyB0byBhY2Nlc3MgcHJvdGVjdGVkIHJlc291cmNlcy4gQ3VycmVu
dGx5DQo+PiB0aGVzZSBhcmUgYmVhcmVyIHRva2VucywgaS5lLiBhbnkgcGFydHkgaW4gcG9zc2Vz
c2lvbiBvZiBzdWNoIHRva2VuIGdhaW5zDQo+PiBhY2Nlc3MgdG8gdGhlIHByb3RlY3RlZCByZXNv
dXJjZS4gQXR0YWNrZXJzIGV4cG9ydCBiZWFyZXIgdG9rZW5zIGZyb20gY2xpZW50DQo+PiBtYWNo
aW5lcyBvciBmcm9tIGNvbXByb21pc2VkIG5ldHdvcmsgY29ubmVjdGlvbnMsIHByZXNlbnQgdGhl
c2UgYmVhcmVyDQo+PiB0b2tlbnMgdG8gV2ViIHNlcnZpY2VzLCBhbmQgaW1wZXJzb25hdGUgYXV0
aGVudGljYXRlZCB1c2Vycy4gVGhlIGlkZWEgb2YNCj4+IFRva2VuIEJpbmRpbmcgaXMgdG8gZW5h
YmxlIGRlZmVuc2UgYWdhaW5zdCBzdWNoIGF0dGFja3MgYnkgY3J5cHRvZ3JhcGhpY2FsbHkNCj4+
IGJpbmRpbmcgc2VjdXJpdHkgdG9rZW5zIHRvIHRoZSBUTFMgbGF5ZXIuDQo+Pg0KPj4NCj4+DQo+
PiBUaGUgdGFza3Mgb2YgdGhpcyB3b3JraW5nIGdyb3VwIGFyZSBhcyBmb2xsb3dzOg0KPj4NCj4+
IDEuICAgICAgICAgICAgU3BlY2lmeSB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCB2MS4wLg0K
Pj4NCj4+IDIuICAgICAgICAgICAgU3BlY2lmeSB0aGUgdXNlIG9mIHRoZSBUb2tlbiBCaW5kaW5n
IHByb3RvY29sIGluIGNvbWJpbmF0aW9uDQo+PiB3aXRoIEhUVFBTLg0KPj4NCj4+DQo+Pg0KPj4g
SXQgaXMgYSBnb2FsIG9mIHRoaXMgd29ya2luZyBncm91cCB0byBlbmFibGUgZGVmZW5zZSBhZ2Fp
bnN0IGF0dGFja3MgdGhhdA0KPj4gaW52b2x2ZSB1bmF1dGhvcml6ZWQgcmVwbGF5IG9mIHNlY3Vy
aXR5IHRva2VucywgYnV0IG90aGVyIGlzc3VlcyBhc3NvY2lhdGVkDQo+PiB3aXRoIHRoZSB1c2Ug
b2Ygc2VjdXJpdHkgdG9rZW5zIGFyZSBvdXQgb2Ygc2NvcGUuIEl0IGlzIGEgZ29hbCBvZiB0aGlz
DQo+PiB3b3JraW5nIGdyb3VwIHRvIGRlc2lnbiB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCBz
dWNoIHRoYXQgaXQgd291bGQgYmUNCj4+IGFsc28gdXNlYWJsZSB3aXRoIGFwcGxpY2F0aW9uIHBy
b3RvY29scyBvdGhlciB0aGFuIEhUVFBTLCBob3dldmVyIHNwZWNpZnlpbmcNCj4+IHN1Y2ggdXNl
cyBpcyBub3QgYSBwcmltYXJ5IGdvYWwuDQo+Pg0KPj4NCj4+DQo+PiBTb21lIG9mIHRoZSBtYWlu
IGRlc2lnbiBnb2FscyBmb3IgdGhlIFRva2VuIEJpbmRpbmcgcHJvdG9jb2wsIGluIG5vDQo+PiBw
YXJ0aWN1bGFyIG9yZGVyOg0KPj4NCj4+IDEuICAgICAgICAgICAgUHJldmVudCBleHBvcnQgYW5k
IHJlcGxheSBvZiBzZWN1cml0eSB0b2tlbnMuDQo+Pg0KPj4gMi4gICAgICAgICAgICBBbGxvdyBz
dHJvbmcga2V5IHByb3RlY3Rpb24sIGUuZy4gdXNpbmcgaGFyZHdhcmUtYm91bmQga2V5cy4NCj4+
DQo+PiAzLiAgICAgICAgICAgIFN1cHBvcnQgYm90aCBmaXJzdC1wYXJ0eSBhbmQgZmVkZXJhdGlv
biBzY2VuYXJpb3MuDQo+Pg0KPj4gNC4gICAgICAgICAgICBQcmVzZXJ2ZSB1c2VyIHByaXZhY3ku
DQo+Pg0KPj4gNS4gICAgICAgICAgICBNYWtlIHRoZSBUb2tlbiBCaW5kaW5nIHByb3RvY29sIHVz
ZWFibGUgaW4gY29tYmluYXRpb24gd2l0aCBhDQo+PiB2YXJpZXR5IG9mIGFwcGxpY2F0aW9uIHBy
b3RvY29scy4NCj4+DQo+PiA2LiAgICAgICAgICAgIEFsbG93IHRoZSBuZWdvdGlhdGlvbiBvZiB0
aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCB3aXRob3V0DQo+PiBhZGRpdGlvbmFsIHJvdW5kLXRy
aXBzLg0KPj4NCj4+IDcuICAgICAgICAgICAgQWxsb3cgdGhlIHVzZSBvZiBtdWx0aXBsZSBjcnlw
dG9ncmFwaGljIGFsZ29yaXRobXMsIHNvIHRoYXQgYQ0KPj4gdmFyaWV0eSBvZiBzZWN1cmUgaGFy
ZHdhcmUgbW9kdWxlcyB3aXRoIGRpZmZlcmVudCBjcnlwdG9ncmFwaGljIGNhcGFiaWxpdGllcw0K
Pj4gY291bGQgYmUgdXNlZCB3aXRoIFRva2VuIEJpbmRpbmcuDQo+Pg0KPj4gOC4gICAgICAgICAg
ICBQcm9wb3NlIFRva2VuIEJpbmRpbmcgc3BlYyB0aGF0IGNhbiBiZSBpbXBsZW1lbnRlZCBpbiBX
ZWINCj4+IGJyb3dzZXJzIChidXQgaXMgbm90IGxpbWl0ZWQgdG8gdGhlbSkuIEUuZy4gV2ViIGJy
b3dzZXJzIHJlcXVpcmUgdGhhdCB0aGUNCj4+IHNhbWUgYm91bmQgc2VjdXJpdHkgdG9rZW4gbXVz
dCBiZSBwcmVzZW50YWJsZSBvdmVyIG11bHRpcGxlIFRMUyBzZXNzaW9ucyBhbmQNCj4+IGNvbm5l
Y3Rpb25zLg0KPj4NCj4+DQo+Pg0KPj4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCB1c2UgdGhlIGZv
bGxvd2luZyBkb2N1bWVudHMgYXMgYSBzdGFydGluZyBwb2ludCBmb3INCj4+IGl0cyB3b3JrOg0K
Pj4NCj4+IC0gICAgICAgICAgICBkcmFmdC1wb3Bvdi10b2tlbi1iaW5kaW5nLTAwOw0KPj4NCj4+
IC0gICAgICAgICAgICBkcmFmdC1iYWxmYW56LWh0dHBzLXRva2VuLWJpbmRpbmctMDAuDQo+Pg0K
Pj4NCj4+DQo+PiBUaGlzIFdHIHdpbGwgY29sbGFib3JhdGUgd2l0aCBvdGhlciBJRVRGIFdHcywg
aW4gcGFydGljdWxhciB3aXRoIHRoZSBUTFMsDQo+PiBIVFRQYmlzIGFuZCBPYXV0aCBXR3MuDQo+
Pg0KPj4NCj4+DQo+PiBNaWxlc3RvbmVzOg0KPj4NCj4+IC0gICAgICAgICAgICBXRyBkb2N1bWVu
dCBmb3IgdGhlIFRva2VuIEJpbmRpbmcgUHJvdG9jb2wgdjEuMC4NCj4+DQo+PiAtICAgICAgICAg
ICAgV0cgZG9jdW1lbnQgZm9yIEhUVFBTIFRva2VuIEJpbmRpbmcuDQo+Pg0KPj4gLSAgICAgICAg
ICAgIFRva2VuIEJpbmRpbmcgUHJvdG9jb2wgdjEuMCB0byBJRVNHLg0KPj4NCj4+IC0gICAgICAg
ICAgICBIVFRQUyBUb2tlbiBCaW5kaW5nIHRvIElFU0cuDQo+Pg0KPj4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFVuYmVhcmFibGUgbWFpbGluZyBs
aXN0DQo+PiBVbmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnPg0K
Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQo+Pg0K
Pj4NCj4+DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj4+IFVuYmVhcmFibGUgbWFpbGluZyBsaXN0DQo+PiBVbmJlYXJhYmxlQGlldGYub3Jn
PG1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnPg0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQo+Pg0KPg0KPg0KPg0KDQpfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QN
ClVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmc+DQpodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCg0K

--_000_BN3PR0301MB12503B0B51D3D03E37036A2A8C310BN3PR0301MB1250_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN
Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx
NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN
CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq
Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN
Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv
LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K
CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bh
bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m
YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm
YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N
CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g
MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u
MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0
cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b
aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt
YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k
aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1
cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNpbmNlIG5vYm9keSBzZWVtcyB0byBvYmpl
Y3QsIEnigJl2ZSBwdXNoZWQgQmlsbOKAmXMgY2hhbmdlIHRvDQo8YSBocmVmPSJodHRwczovL2dp
dGh1Yi5jb20vVG9rZW5CaW5kaW5nL1dHLUNoYXJ0ZXIiPkdpdEh1YjwvYT4uPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m
bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv
cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm
cXVvdDssc2Fucy1zZXJpZiI+IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNA
aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHJlaSBQb3Bvdjxicj4NCjxiPlNlbnQ6
PC9iPiBNb25kYXksIEphbnVhcnkgMjYsIDIwMTUgNTowOCBQTTxicj4NCjxiPlRvOjwvYj4gQmls
bCBNaWxsczsgU3RlcGhlbiBGYXJyZWxsOyBLYXRobGVlbiBNb3JpYXJ0eTxicj4NCjxiPkNjOjwv
Yj4gSm9obiBCcmFkbGV5OyB1bmJlYXJhYmxlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+
IFJlOiBbVW5iZWFyYWJsZV0gVXBkYXRlZCBDaGFydGVyIFByb3Bvc2FsPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx
RjQ5N0QiPkFmdGVyIGNoYXR0aW5nIHdpdGggQmlsbCBvZmYtbGlzdCwgaGVyZSBpcyB0aGUgc3Bl
Y2lmaWMgY2hhbmdlIHByb3Bvc2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
IzFGNDk3RCI+VGhlIGNoYXJ0ZXIgZHJhZnQgY3VycmVudGx5IHNheXM6PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi
PuKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNv
bGFzO2NvbG9yOiMzMzMzMzM7YmFja2dyb3VuZDp3aGl0ZSI+VG9rZW4gQmluZGluZyBlbmFibGVz
IGRlZmVuc2UgYWdhaW5zdCBzdWNoIGF0dGFja3MgYnkgY3J5cHRvZ3JhcGhpY2FsbHkgYmluZGlu
ZyBzZWN1cml0eSB0b2tlbnMgdG8gdGhlIFRMUyBsYXllci48L3NwYW4+PHNwYW4gc3R5bGU9ImNv
bG9yOiMxRjQ5N0QiPuKAnDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3
RCI+VGhlIHByb3Bvc2VkIHRleHQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPuKAnDwvc3Bhbj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOiMzMzMzMzM7YmFj
a2dyb3VuZDp3aGl0ZSI+VG9rZW4gQmluZGluZyBlbmFibGVzIGRlZmVuc2UgYWdhaW5zdCBzdWNo
IGF0dGFja3MgYnkgY3J5cHRvZ3JhcGhpY2FsbHkgYmluZGluZyBzZWN1cml0eSB0b2tlbnMgdG8g
YSBzZWNyZXQgaGVsZCBieSB0aGUNCiBjbGllbnQuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjoj
MUY0OTdEIj7igJw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv
cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgdGhlIG1haWxpbmcgbGlzdCBp
cyBPSyB3aXRoIHRoaXMgY2hhbmdlLCBJ4oCZbGwgZ28gYWhlYWQgYW5kIHVwZGF0ZSB0aGUgY2hh
cnRlciBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRo
YW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh
bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkFuZHJlaTxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp
Zjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp
diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp
bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z
LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQmlsbCBNaWxscyBbPGEg
aHJlZj0ibWFpbHRvOndtaWxsc185MjEwNUB5YWhvby5jb20iPm1haWx0bzp3bWlsbHNfOTIxMDVA
eWFob28uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgSmFudWFyeSAyNCwg
MjAxNSA2OjA4IFBNPGJyPg0KPGI+VG86PC9iPiBTdGVwaGVuIEZhcnJlbGw7IEthdGhsZWVuIE1v
cmlhcnR5OyBBbmRyZWkgUG9wb3Y8YnI+DQo8Yj5DYzo8L2I+IEpvaG4gQnJhZGxleTsgPGEgaHJl
Zj0ibWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmciPnVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+PGJy
Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gVXBkYXRlZCBDaGFydGVyIFByb3Bv
c2FsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi
bGFjayI+TXkgaXNzdWUgaXMgYWdhaW4gd2l0aCB0aGUgdGV4dCAmcXVvdDtiaW5kaW5nIHRvIHRo
ZSBUTFMgbGF5ZXImcXVvdDssIHRoYXQncyBjaGFubmVsIGJpbmRpbmcuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6
YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo
aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh
bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5PbiBTYXR1cmRheSwgSmFudWFyeSAyNCwg
MjAxNSA1OjUwIFBNLCBTdGVwaGVuIEZhcnJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVwaGVu
LmZhcnJlbGxAY3MudGNkLmllIj5zdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPC9hPiZndDsgd3Jv
dGU6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss
c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQ7YmFja2dyb3Vu
ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz
YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi
bGFjayI+PGJyPg0KQ2hlZXJzLDxicj4NCjxicj4NCkVkaXRpbmcgd2lsbCBlbnN1ZTotKTxicj4N
Cjxicj4NClM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJ5cXRmZDQyOTkzIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si
Pjxicj4NCk9uIDI1LzAxLzE1IDAxOjMwLCBLYXRobGVlbiBNb3JpYXJ0eSB3cm90ZTo8YnI+DQom
Z3Q7IEhpLDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgY2hhcnRlciBsb29rcyBsaWtlIGl0IGlz
IHNoYXBpbmcgdXAuJm5ic3A7IEkganVzdCBoYXZlIHNvbWUgZWRpdG9yaWFsPGJyPg0KJmd0OyBz
dWdnZXN0aW9ucyBhcyB0aGUgZGlzY3Vzc2lvbiBjb250aW51ZXMsIHRha2UgdGhlbSBvciBsZWF2
ZSB0aGVtLCBub3Q8YnI+DQomZ3Q7IGEgYmlnIGRlYWwuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFN1
Z2dlc3QgY2hhbmdpbmcgZnJvbTo8YnI+DQomZ3Q7IFRoZSBpZGVhIG9mIFRva2VuIEJpbmRpbmcg
aXMgdG8gZW5hYmxlIGRlZmVuc2UgYWdhaW5zdCBzdWNoIGF0dGFja3MgYnk8YnI+DQomZ3Q7IGNy
eXB0b2dyYXBoaWNhbGx5IGJpbmRpbmc8YnI+DQomZ3Q7IHNlY3VyaXR5IHRva2VucyB0byB0aGUg
VExTIGxheWVyLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUbzo8YnI+DQomZ3Q7IFRva2VuIEJpbmRp
bmcgZW5hYmxlcyBkZWZlbnNlIGFnYWluc3Qgc3VjaCBhdHRhY2tzIGJ5IGNyeXB0b2dyYXBoaWNh
bGx5IGJpbmRpbmc8YnI+DQomZ3Q7IHNlY3VyaXR5IHRva2VucyB0byB0aGUgVExTIGxheWVyLjxi
cj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgd29yZCBnb2FsIGlzIHVzZWQgYSBiaXQgbXVjaCwgYnV0
IHRoaXMgaXMgYSBwZXJzb25hbCBwcmVmZXJlbmNlIC08YnI+DQomZ3Q7IHRha2Ugb3IgbGVhdmUg
dGhlIHN1Z2dlc3Rpb25zLiZuYnNwOyBJIHN1Z2dlc3QgcmVtb3ZpbmcgJnF1b3Q7U29tZSZxdW90
OyBpbiB0aGUgbGFzdDxicj4NCiZndDsgc2VudGVuY2UgbGlzdGVkIGFzIHRoaXMgb25seSBzYXlz
IHRoZSAmcXVvdDttYWluJnF1b3Q7IGdvYWxzL29iamVjdGl2ZXMsIHNvPGJyPg0KJmd0OyB0aGVy
ZSBpcyB3aWdnbGUgcm9vbSBzdGlsbC48YnI+DQomZ3Q7IDxicj4NCiZndDsgRnJvbTo8YnI+DQom
Z3Q7IEl0IGlzIGEgZ29hbCBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAgdG8gZW5hYmxlIGRlZmVuc2Ug
YWdhaW5zdCBhdHRhY2tzPGJyPg0KJmd0OyB0aGF0IGludm9sdmUgdW5hdXRob3JpemVkIHJlcGxh
eSBvZjxicj4NCiZndDsgc2VjdXJpdHkgdG9rZW5zLCBidXQgb3RoZXIgaXNzdWVzIGFzc29jaWF0
ZWQgd2l0aCB0aGUgdXNlIG9mIHNlY3VyaXR5PGJyPg0KJmd0OyB0b2tlbnMgYXJlIG91dCBvZiBz
Y29wZS4gSXQgaXMgYSBnb2FsPGJyPg0KJmd0OyBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAgdG8gZGVz
aWduIHRoZSBUb2tlbiBCaW5kaW5nIHByb3RvY29sIHN1Y2ggdGhhdDxicj4NCiZndDsgaXQgd291
bGQgYmUgYWxzbyB1c2VhYmxlIHdpdGg8YnI+DQomZ3Q7IGFwcGxpY2F0aW9uIHByb3RvY29scyBv
dGhlciB0aGFuIEhUVFBTLCBob3dldmVyIHNwZWNpZnlpbmcgc3VjaCB1c2VzPGJyPg0KJmd0OyBp
cyBub3QgYSBwcmltYXJ5IGdvYWwuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNvbWUgb2YgdGhlIG1h
aW4gZGVzaWduIGdvYWxzIGZvciB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCwgaW4gbm88YnI+
DQomZ3Q7IHBhcnRpY3VsYXIgb3JkZXI6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRvOjxicj4NCiZn
dDsgSXQgaXMgYSBnb2FsIG9mIHRoaXMgd29ya2luZyBncm91cCB0byBlbmFibGUgZGVmZW5zZSBh
Z2FpbnN0IGF0dGFja3M8YnI+DQomZ3Q7IHRoYXQgaW52b2x2ZSB1bmF1dGhvcml6ZWQgcmVwbGF5
IG9mPGJyPg0KJmd0OyBzZWN1cml0eSB0b2tlbnMuJm5ic3A7IE90aGVyIGlzc3VlcyBhc3NvY2lh
dGVkIHdpdGggdGhlIHVzZSBvZiBzZWN1cml0eTxicj4NCiZndDsgdG9rZW5zIGFyZSBvdXQgb2Yg
c2NvcGUuIEFub3RoZXIgZ29hbDxicj4NCiZndDsgb2YgdGhpcyB3b3JraW5nIGdyb3VwIGlzIHRv
IGRlc2lnbiB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCBzdWNoPGJyPg0KJmd0OyB0aGF0IGl0
IHdvdWxkIGJlIGFsc28gdXNlYWJsZSB3aXRoPGJyPg0KJmd0OyBhcHBsaWNhdGlvbiBwcm90b2Nv
bHMgb3RoZXIgdGhhbiBIVFRQUy4mbmJzcDsgU3BlY2lmeWluZyBhbHRlcm5hdGU8YnI+DQomZ3Q7
IGFwcGxpY2F0aW9uIHByb3RvY29scyBpcyBub3QgYSBwcmltYXJ5IGdvYWwuPGJyPg0KJmd0OyA8
YnI+DQomZ3Q7IFRoZSBtYWluIGRlc2lnbiBvYmplY3RpdmVzIGZvciB0aGUgVG9rZW4gQmluZGlu
ZyBwcm90b2NvbCwgaW4gbm88YnI+DQomZ3Q7IHBhcnRpY3VsYXIgb3JkZXI6PGJyPg0KJmd0OyA8
YnI+DQomZ3Q7ICM4IC0gc3BlYyBzaG91bGQgcHJvYmFibHkgYmUgc3BlbGxlZCBvdXQgYXMgc3Bl
Y2lmaWNhdGlvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDsgS2F0aGxl
ZW48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBUdWUsIEphbiAyMCwgMjAxNSBh
dCA3OjA3IFBNLCBBbmRyZWkgUG9wb3Y8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86QW5k
cmVpLlBvcG92QG1pY3Jvc29mdC5jb20iPkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZn
dDsgd3JvdGU6PGJyPg0KJmd0OyZndDsgSSBiZWxpZXZlIEnigJl2ZSBhZGRyZXNzZWQgdGhlIGZl
ZWRiYWNrIHJlY2VpdmVkIHNvIGZhcjsgdGhlIHVwZGF0ZWQgY2hhcnRlcjxicj4NCiZndDsmZ3Q7
IGRyYWZ0IGlzIG9uIEdpdEh1YiBmb3IgZWFzeSBhdXRob3Jpbmc6PGJyPg0KJmd0OyZndDs8YnI+
DQomZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vVG9rZW5CaW5kaW5nL1dHLUNo
YXJ0ZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vVG9rZW5CaW5kaW5nL1dH
LUNoYXJ0ZXI8L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsgUHVsbCByZXF1ZXN0cyBhcmUgd2VsY29tZSw8YnI+DQomZ3Q7Jmd0Ozxicj4N
CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGFua3MsPGJyPg0KJmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQW5kcmVpPGJyPg0K
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgRnJvbTog
Sm9obiBCcmFkbGV5IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj52
ZTdqdGJAdmU3anRiLmNvbTwvYT5dPGJyPg0KJmd0OyZndDsgU2VudDogVGh1cnNkYXksIEphbnVh
cnkgMTUsIDIwMTUgMTI6MTYgUE08YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0
OyZndDsgVG86IEFuZHJlaSBQb3Bvdjxicj4NCiZndDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86
dW5iZWFyYWJsZUBpZXRmLm9yZyI+dW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0
OyBTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFVwZGF0ZWQgQ2hhcnRlciBQcm9wb3NhbDxicj4N
CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEEgY291
cGxlIG1vcmUgcG9zc2libGUgY2xhcmlmaWNhdGlvbnMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAyLiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7IFNwZWNpZnkgdGhlIHVzZSBvZiB0aGUgVG9rZW4gQmluZGluZyBw
cm90b2NvbCBpbiBjb21iaW5hdGlvbjxicj4NCiZndDsmZ3Q7IHdpdGggSFRUUFMuPGJyPg0KJmd0
OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSFRUUFMgaXMg
cHJvYmFibHkgaW50ZW5kZWQgdG8gYmUgc2hvcnRoYW5kIGZvciBhIGh0dHAgYmluZGluZyBmb3Ig
VExTICYjNDM7PGJyPg0KJmd0OyZndDsgdG9rZW4gQmluZGluZyBhcyBpcyBkZWZpbmVkIGluICZx
dW90O1Rva2VuIEJpbmRpbmcgb3ZlciBIVFRQJnF1b3Q7PGJyPg0KJmd0OyZndDsgWzxhIGhyZWY9
Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iYWxmYW56LWh0dHBzLXRva2VuLWJp
bmRpbmctMDAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh
ZnQtYmFsZmFuei1odHRwcy10b2tlbi1iaW5kaW5nLTAwPC9hPl0uPGJyPg0KJmd0OyZndDs8YnI+
DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhpcyBpcyBhIGJpbmRpbmcg
dG8gSFRUUCAodmlhIGEgbmV3IGhlYWRlcikgYW5kIHRvIEhUTUwmbmJzcDsgKHZpYSBYTUwgSFRU
UDxicj4NCiZndDsmZ3Q7IHJlcXVlc3QpLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+
DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IElmIHdlIGFsc28gc2F5IHRoYXQgcG9zc2libGUgZnV0
dXJlIGJpbmRpbmcgbWF5IGJlIGEgU0FTU0wvR1NTLUFQSSBiaW5kaW5nPGJyPg0KJmd0OyZndDsg
Zm9yIFRMUyAmIzQzOyB0b2tlbiBiaW5kaW5nJm5ic3A7IChUaGUgc2Fzc2wtb2F1dGggc3BlYzxi
cj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p
ZXRmLWtpdHRlbi1zYXNsLW9hdXRoLTE4IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1raXR0ZW4tc2FzbC1vYXV0aC0xOCA8L2E+bWlnaHQg
dXNlIHN1Y2ggYTxicj4NCiZndDsmZ3Q7IHRoaW5nLik8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn
dDsgT25lIG90aGVyIHRoaW5nIEkgbm90ZSBpbiB0aGUgZHJhZnRzLCBpcyB0aGF0IGF0IG5vIHBv
aW50IGFyZSZuYnNwOyB0b2tlbnM8YnI+DQomZ3Q7Jmd0OyBkZWZpbmVkIG9yIGV2ZW4gcmVhbGx5
IGRpc2N1c3NlZCBvdGhlciB0aGFuIGFzIHNvbWV0aGluZyB0aGF0IGFwcGxpY2F0aW9uczxicj4N
CiZndDsmZ3Q7IGNhbiBiaW5kIHRvIHRoZSBleHBvc2VkIHB1YmxpYyBrZXkuPGJyPg0KJmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0OyBUaGUgYXBwbGljYXRpb25zIHdpbGwgYmluZCB0b2tlbnMgdG8gdGhl
IGtleXMgZXhwb3NlZCBieSB0aGUgc3BlY3MgdmlhIHRoZTxicj4NCiZndDsmZ3Q7IGJpbmRpbmdz
LiZuYnNwOyBUaGUgbmFtaW5nIG1heSBzbGlnaHRseSBtaXNkaXJlY3QgcGVvcGxlLCBidXQgdGhl
cmUgaGF2ZSBhbHJlYWR5PGJyPg0KJmd0OyZndDsgYmVlbiB0b28gbWFueSBuYW1lcyBmb3IgdGhp
cyBzbyBJIHdvbid0IHB1c2ggdGhlIHBvaW50Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEkgdGhpbmsga2VlcGluZyB0aGlzIGRvd24gY2xv
c2UgdG8gdGhlIFRMUyBsYXllciBhbmQgZGVmaW5pbmcgYmluZGluZ3MgdG88YnI+DQomZ3Q7Jmd0
OyBIVFRQIGFuZCBvdGhlciBwcm90b2NvbHMgaXMgaW4gc2NvcGUuPGJyPg0KJmd0OyZndDs8YnI+
DQomZ3Q7Jmd0OyBFbmNvdXJhZ2luZyBhcHBsaWNhdGlvbnMgdGhhdCB1c2UgcHJvdG9jb2xzIGxp
a2UgSFRUUCAmIzQzOyBUTFMgdG8gdXNlIHRoZTxicj4NCiZndDsmZ3Q7IGJpbmRpbmdzIHRvIGJp
bmQgdGhlcmUgc2VjdXJpdHkgdG9rZW5zL2Nvb2tpZXMgaXMgaW4gc2NvcGUuPGJyPg0KJmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSB0aGluayBkZWZp
bmluZyB0aGUgZXh0ZW5zaW9ucyBmb3IgdGhvc2UgYXBwbGljYXRpb25zIHRvIHVzZSB0aGUgYmlu
ZGluZ3M8YnI+DQomZ3Q7Jmd0OyBpcyBzaG91bGQgYmUgdXAgdG8gdGhlIGFwcGxpY2F0aW9ucyB0
aGVtc2VsdmVzIHdoZXJlIHRoZXJlIGlzIGFjdGl2ZTxicj4NCiZndDsmZ3Q7IHBhcnRpY2lwYXRp
b24uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn
dDsgVHJ5aW5nIHRvIGV4dGVuZCB0aGlzIHRvIGNvdmVyIGVuZCB0byBlbmQgbWVzc2FnZSBzaWdu
aW5nIG91dHNpZGUgb2YgYSBUTFM8YnI+DQomZ3Q7Jmd0OyBzZXNzaW9uIHNob3VsZCBiZSBleHBy
ZXNzbHkgb3V0IG9mIHNjb3BlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7IFdlIG1heSBob3dldmVyIHdhbnQgdG8gc2F5IHNvbWV0aGluZyBh
Ym91dCBob3cgYSBUTFMgc2Vzc2lvbiB0ZXJtaW5hdGVkIG9uIGE8YnI+DQomZ3Q7Jmd0OyBUTFMg
ZGV2aWNlIGNhbiBoYXZlIHRoZSBUb2tlbiBCaW5kaW5nIElEIGZvciB0aGUgc2Vzc2lvbiBwYXNz
ZWQgaW4gYSBIVFRQPGJyPg0KJmd0OyZndDsgaGVhZGVyLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0
OyZndDsgVGhhdCBhbmQgcG9zc2libHkgc29tZSBvdGhlciBUTFMgYXBwbGlhbmNlIGlzc3VlcyBh
cmUgaW4gc2NvcGUgZm9yICZxdW90O1Rva2VuPGJyPg0KJmd0OyZndDsgQmluZGluZyBvdmVyIEhU
VFAmcXVvdDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQom
Z3Q7Jmd0OyBSZWdhcmRzPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBKb2huIEIuPGJyPg0K
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQom
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBPbiBKYW4g
MTUsIDIwMTUsIGF0IDM6NTIgUE0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFu
ZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4m
Z3Q7PGJyPg0KJmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N
CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhhbmtzIEpvaG47IGJvdGggc3VnZ2VzdGlvbnMgbWFr
ZSBzZW5zZSB0byBtZTsgd2lsbCByZXBocmFzZSBpbiB0aGUgbmV4dDxicj4NCiZndDsmZ3Q7IHJl
dmlzaW9uLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0OyBBbmRyZWk8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0
OyZndDs8YnI+DQomZ3Q7Jmd0OyBGcm9tOiBKb2huIEJyYWRsZXkgW21haWx0bzo8YSBocmVmPSJt
YWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIuY29tPC9hPl08YnI+DQomZ3Q7
Jmd0OyBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAxNSwgMjAxNSA5OjI1IEFNPGJyPg0KJmd0OyZn
dDsgVG86IEFuZHJlaSBQb3Bvdjxicj4NCiZndDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86dW5i
ZWFyYWJsZUBpZXRmLm9yZyI+dW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyBT
dWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFVwZGF0ZWQgQ2hhcnRlciBQcm9wb3NhbDxicj4NCiZn
dDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEkgYW0gZ2Vu
ZXJhbGx5IGluIGFncmVtZW50Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7IEEgY291cGxlIG9mIHBvaW50cy48YnI+DQomZ3Q7Jmd0Ozxicj4N
CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBVbmRlciBkZXNpZ24gZ29hbHMg
Y2hhbmdlIDEgdG8uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDsgMS4mbmJzcDsgQWxsb3cgYXBwbGljYXRpb25zIHRvIHByZXZlbnQgdGhlIGV4
cG9ydCBhbmQgcmVwbGF5IG9mIHNlY3VyaXR5IHRva2Vucy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBZb3UgY291bGQgbWFrZSB0aGF0IGFw
cGxpY2F0aW9ucyBhbmQgcHJvdG9jb2xzIGlmIHlvdSBsaWtlIGFzIHNvbWUgcGVvcGxlPGJyPg0K
Jmd0OyZndDsgbWF5IHNlZSB0aGluZ3MgbGlrZSBPQXV0aCBhcyBhIHByb3RvY29sIHZzIGFuIGFw
cGxpY2F0aW9uLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIHBvaW50IGJlaW5nIHRo
YXQgdGhlIGdvYWwgaXMgdG8gcHJvdmlkZSB0aGUgaG9va3MgZm9yIHRoaW5ncyBhIGxheWVyPGJy
Pg0KJmd0OyZndDsgYWJvdmUgdGhlc2Ugc3BlY2lmaWNhdGlvbnMgdG8gbWFrZSBzZWN1cml0eSBk
ZWNpc2lvbnMsIG5vdCB0aGUgdG9rZW4gYmluZGluZzxicj4NCiZndDsmZ3Q7IHByb3RvY29sIGl0
c2VsZi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSW4gMyB5b3UgdXNlIHRoZSB0ZXJtIGZl
ZGVyYXRpb24uJm5ic3A7IFRoYXQgbWF5IGJlIGxhcmdlciBpbiBzY29wZSB0aGFuIHdoYXQgSTxi
cj4NCiZndDsmZ3Q7IHRoaW5rIHlvdSBpbnRlbmQgZnJvbSB0aGUgdHdvIGRyYWZ0cy48YnI+DQom
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEZlZGVyYXRpb24gaXMgYSBtdWNoIGxhcmdlciB0b3BpYyB0
aGFuIGFsbG93aW5nIHRoZSBwdWJsaWMga2V5IGZyb20gb25lPGJyPg0KJmd0OyZndDsgY29ubmVj
dGlvbiB0byBiZSBleHBvc2VkIGluIGEgY29ubmVjdGlvbiB0byBhIHNlY29uZCBwYXJ0eSB2aWEg
c29tZSBzb3J0IG9mPGJyPg0KJmd0OyZndDsgZXhwcmVzcyBjb25zZW50IGZyb20gdGhlIGZpcnN0
IHBhcnR5Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7IFNocmlua2luZyB0aGUgc2NvcGUgdG8gaG93IHB1YmxpYyBrZXlzIG1heSBiZSBzaGFy
ZWQgd2l0aCBwZXJtaXNzaW9uIHRvPGJyPg0KJmd0OyZndDsgdGhpcmQgcGFydGllcyBtYXkgbWFr
ZSBzb21lIHBlb3BsZSBtb3JlIGNvbWZvcnRhYmxlLCBpZiB0aGV5IGFyZSBjb25jZXJuZWQ8YnI+
DQomZ3Q7Jmd0OyB0aGF0IHRoaXMgaXMgdHJ5aW5nIHRvIGJlIGEgbmV3IGZlZGVyYXRpb24gcHJv
dG9jb2wgdG8gY29tcGV0ZSB3aXRoIFNBTUwgb3I8YnI+DQomZ3Q7Jmd0OyBPQXV0aC48YnI+DQom
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBSZWdhcmRz
PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBKb2huIEIuPGJyPg0KJmd0OyZndDs8YnI+DQom
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgT24gSmFuIDE0LCAyMDE1LCBhdCA5
OjE0IFBNLCBBbmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWlj
cm9zb2Z0LmNvbSI+QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCiZndDsm
Z3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N
CiZndDsmZ3Q7IFRoZSBkaXNjdXNzaW9uIG9uIHRoaXMgbWFpbGluZyBsaXN0IGhhcyBzdWJzaWRl
ZCBvdmVyIHRoZSBob2xpZGF5cywgc28gSTxicj4NCiZndDsmZ3Q7IGxvb2tlZCB0aHJvdWdoIHRo
ZSBtZXNzYWdlcyBmb3IgZmVlZGJhY2sgcmVnYXJkaW5nIHRoZSBwcm9wb3NlZCBjaGFydGVyIGFu
ZDxicj4NCiZndDsmZ3Q7IGluY29ycG9yYXRlZCBhIGNvdXBsZSBvZiBjaGFuZ2VzIHN1Z2dlc3Rl
ZCBzbyBmYXI6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAxLiBBIG5ldyBkZXNpZ24gZ29h
bDogdGhlIHNvbHV0aW9uIG11c3Qgd29yayBmb3IgV2ViIGJyb3dzZXJzLiBFLmcuIHRoaXM8YnI+
DQomZ3Q7Jmd0OyBtZWFucyB0aGF0IHNlY3VyaXR5IHRva2VucyBtdXN0IGJlIHByZXNlbnRhYmxl
IG92ZXIgbXVsdGlwbGUgVExTIHNlc3Npb25zPGJyPg0KJmd0OyZndDsgYW5kIGNvbm5lY3Rpb25z
Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgMi4gUmVtb3ZlZCBzcGVjaWZpYyBtaWxlc3Rv
bmUgZGF0ZXMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsgTG9va2luZyBmb3J3YXJkIHRvIG1vcmUgZGlzY3Vzc2lvbiBvZiB0aGUgY2hhcnRl
ciw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0
OyBUaGFua3MsPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsgQW5kcmVpPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7
PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX188YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRva2VuIEJpbmRpbmcgKFRC
KTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7
IENoYXJ0ZXIgZm9yIFdvcmtpbmcgR3JvdXA8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJy
Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBXZWIgc2VydmljZXMgZ2VuZXJhdGUgdmFyaW91cyBz
ZWN1cml0eSB0b2tlbnMgKGUuZy4mbmJzcDsgSFRUUCBjb29raWVzLCBPQXV0aDxicj4NCiZndDsm
Z3Q7IHRva2VucywgZXRjLikgZm9yIHdlYiBhcHBsaWNhdGlvbnMgdG8gYWNjZXNzIHByb3RlY3Rl
ZCByZXNvdXJjZXMuIEN1cnJlbnRseTxicj4NCiZndDsmZ3Q7IHRoZXNlIGFyZSBiZWFyZXIgdG9r
ZW5zLCBpLmUuIGFueSBwYXJ0eSBpbiBwb3NzZXNzaW9uIG9mIHN1Y2ggdG9rZW4gZ2FpbnM8YnI+
DQomZ3Q7Jmd0OyBhY2Nlc3MgdG8gdGhlIHByb3RlY3RlZCByZXNvdXJjZS4gQXR0YWNrZXJzIGV4
cG9ydCBiZWFyZXIgdG9rZW5zIGZyb20gY2xpZW50PGJyPg0KJmd0OyZndDsgbWFjaGluZXMgb3Ig
ZnJvbSBjb21wcm9taXNlZCBuZXR3b3JrIGNvbm5lY3Rpb25zLCBwcmVzZW50IHRoZXNlIGJlYXJl
cjxicj4NCiZndDsmZ3Q7IHRva2VucyB0byBXZWIgc2VydmljZXMsIGFuZCBpbXBlcnNvbmF0ZSBh
dXRoZW50aWNhdGVkIHVzZXJzLiBUaGUgaWRlYSBvZjxicj4NCiZndDsmZ3Q7IFRva2VuIEJpbmRp
bmcgaXMgdG8gZW5hYmxlIGRlZmVuc2UgYWdhaW5zdCBzdWNoIGF0dGFja3MgYnkgY3J5cHRvZ3Jh
cGhpY2FsbHk8YnI+DQomZ3Q7Jmd0OyBiaW5kaW5nIHNlY3VyaXR5IHRva2VucyB0byB0aGUgVExT
IGxheWVyLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7IFRoZSB0YXNrcyBvZiB0aGlzIHdvcmtpbmcgZ3JvdXAgYXJlIGFzIGZvbGxvd3M6PGJy
Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAxLiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7IFNwZWNpZnkgdGhlIFRva2VuIEJpbmRpbmcgcHJvdG9jb2wgdjEuMC48YnI+
DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDIuJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgU3BlY2lmeSB0aGUgdXNlIG9mIHRoZSBUb2tlbiBCaW5kaW5nIHByb3RvY29s
IGluIGNvbWJpbmF0aW9uPGJyPg0KJmd0OyZndDsgd2l0aCBIVFRQUy48YnI+DQomZ3Q7Jmd0Ozxi
cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJdCBpcyBhIGdvYWwgb2Yg
dGhpcyB3b3JraW5nIGdyb3VwIHRvIGVuYWJsZSBkZWZlbnNlIGFnYWluc3QgYXR0YWNrcyB0aGF0
PGJyPg0KJmd0OyZndDsgaW52b2x2ZSB1bmF1dGhvcml6ZWQgcmVwbGF5IG9mIHNlY3VyaXR5IHRv
a2VucywgYnV0IG90aGVyIGlzc3VlcyBhc3NvY2lhdGVkPGJyPg0KJmd0OyZndDsgd2l0aCB0aGUg
dXNlIG9mIHNlY3VyaXR5IHRva2VucyBhcmUgb3V0IG9mIHNjb3BlLiBJdCBpcyBhIGdvYWwgb2Yg
dGhpczxicj4NCiZndDsmZ3Q7IHdvcmtpbmcgZ3JvdXAgdG8gZGVzaWduIHRoZSBUb2tlbiBCaW5k
aW5nIHByb3RvY29sIHN1Y2ggdGhhdCBpdCB3b3VsZCBiZTxicj4NCiZndDsmZ3Q7IGFsc28gdXNl
YWJsZSB3aXRoIGFwcGxpY2F0aW9uIHByb3RvY29scyBvdGhlciB0aGFuIEhUVFBTLCBob3dldmVy
IHNwZWNpZnlpbmc8YnI+DQomZ3Q7Jmd0OyBzdWNoIHVzZXMgaXMgbm90IGEgcHJpbWFyeSBnb2Fs
Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7
IFNvbWUgb2YgdGhlIG1haW4gZGVzaWduIGdvYWxzIGZvciB0aGUgVG9rZW4gQmluZGluZyBwcm90
b2NvbCwgaW4gbm88YnI+DQomZ3Q7Jmd0OyBwYXJ0aWN1bGFyIG9yZGVyOjxicj4NCiZndDsmZ3Q7
PGJyPg0KJmd0OyZndDsgMS4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw
OyBQcmV2ZW50IGV4cG9ydCBhbmQgcmVwbGF5IG9mIHNlY3VyaXR5IHRva2Vucy48YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7IDIuJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgQWxsb3cgc3Ryb25nIGtleSBwcm90ZWN0aW9uLCBlLmcuIHVzaW5nIGhhcmR3YXJlLWJv
dW5kIGtleXMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAzLiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFN1cHBvcnQgYm90aCBmaXJzdC1wYXJ0eSBhbmQgZmVk
ZXJhdGlvbiBzY2VuYXJpb3MuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA0LiZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFByZXNlcnZlIHVzZXIgcHJpdmFjeS48
YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IDUuJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgTWFrZSB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCB1c2VhYmxlIGlu
IGNvbWJpbmF0aW9uIHdpdGggYTxicj4NCiZndDsmZ3Q7IHZhcmlldHkgb2YgYXBwbGljYXRpb24g
cHJvdG9jb2xzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgNi4mbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBbGxvdyB0aGUgbmVnb3RpYXRpb24gb2YgdGhlIFRv
a2VuIEJpbmRpbmcgcHJvdG9jb2wgd2l0aG91dDxicj4NCiZndDsmZ3Q7IGFkZGl0aW9uYWwgcm91
bmQtdHJpcHMuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA3LiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFsbG93IHRoZSB1c2Ugb2YgbXVsdGlwbGUgY3J5cHRv
Z3JhcGhpYyBhbGdvcml0aG1zLCBzbyB0aGF0IGE8YnI+DQomZ3Q7Jmd0OyB2YXJpZXR5IG9mIHNl
Y3VyZSBoYXJkd2FyZSBtb2R1bGVzIHdpdGggZGlmZmVyZW50IGNyeXB0b2dyYXBoaWMgY2FwYWJp
bGl0aWVzPGJyPg0KJmd0OyZndDsgY291bGQgYmUgdXNlZCB3aXRoIFRva2VuIEJpbmRpbmcuPGJy
Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyA4LiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7IFByb3Bvc2UgVG9rZW4gQmluZGluZyBzcGVjIHRoYXQgY2FuIGJlIGltcGxl
bWVudGVkIGluIFdlYjxicj4NCiZndDsmZ3Q7IGJyb3dzZXJzIChidXQgaXMgbm90IGxpbWl0ZWQg
dG8gdGhlbSkuIEUuZy4gV2ViIGJyb3dzZXJzIHJlcXVpcmUgdGhhdCB0aGU8YnI+DQomZ3Q7Jmd0
OyBzYW1lIGJvdW5kIHNlY3VyaXR5IHRva2VuIG11c3QgYmUgcHJlc2VudGFibGUgb3ZlciBtdWx0
aXBsZSBUTFMgc2Vzc2lvbnMgYW5kPGJyPg0KJmd0OyZndDsgY29ubmVjdGlvbnMuPGJyPg0KJmd0
OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIHdvcmtp
bmcgZ3JvdXAgd2lsbCB1c2UgdGhlIGZvbGxvd2luZyBkb2N1bWVudHMgYXMgYSBzdGFydGluZyBw
b2ludCBmb3I8YnI+DQomZ3Q7Jmd0OyBpdHMgd29yazo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7IC0mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBkcmFmdC1wb3Bv
di10b2tlbi1iaW5kaW5nLTAwOzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgLSZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGRyYWZ0LWJhbGZhbnotaHR0cHMtdG9r
ZW4tYmluZGluZy0wMC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8
YnI+DQomZ3Q7Jmd0OyBUaGlzIFdHIHdpbGwgY29sbGFib3JhdGUgd2l0aCBvdGhlciBJRVRGIFdH
cywgaW4gcGFydGljdWxhciB3aXRoIHRoZSBUTFMsPGJyPg0KJmd0OyZndDsgSFRUUGJpcyBhbmQg
T2F1dGggV0dzLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N
CiZndDsmZ3Q7IE1pbGVzdG9uZXM6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgV0cgZG9jdW1lbnQgZm9yIHRoZSBU
b2tlbiBCaW5kaW5nIFByb3RvY29sIHYxLjAuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAt
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgV0cgZG9jdW1lbnQgZm9y
IEhUVFBTIFRva2VuIEJpbmRpbmcuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVG9rZW4gQmluZGluZyBQcm90b2Nv
bCB2MS4wIHRvIElFU0cuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAtJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSFRUUFMgVG9rZW4gQmluZGluZyB0byBJRVNH
Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyBVbmJlYXJhYmxlIG1haWxpbmcgbGlz
dDxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnIj5VbmJl
YXJhYmxlQGlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll
dGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZTwvYT48YnI+DQomZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0K
Jmd0OyZndDsgVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyA8YSBocmVmPSJt
YWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZyI+VW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+DQom
Z3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Vu
YmVhcmFibGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL3VuYmVhcmFibGU8L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsg
PGJyPg0KJmd0OyA8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXzxicj4NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i
bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmciPlVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+PGJyPg0K
PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxl
IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91
bmJlYXJhYmxlPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2JhY2tncm91bmQ6d2hpdGUiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtj
b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_BN3PR0301MB12503B0B51D3D03E37036A2A8C310BN3PR0301MB1250_--