From nobody Mon May 9 13:02:53 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1908A12D604 for ; Mon, 9 May 2016 13:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 483KU9Jf8Ipq for ; Mon, 9 May 2016 13:02:50 -0700 (PDT) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E70512D5EF for ; Mon, 9 May 2016 13:02:50 -0700 (PDT) Received: by mail-ig0-x236.google.com with SMTP id m9so101290535ige.1 for ; Mon, 09 May 2016 13:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=dtvx8u6E+XBKdG4W5f0MYNqzDW4OxP+oEM9qn6Ifw4I=; b=n3Zgm8+1tPVwztXAz6ioR7d84Lj4MOdJ5ggewduwh1HpqI7A5DvbFKUFfQ6WLwK15W 76Y/oa805rZ3epKtUUk3aKkVuELHEZcv/pvt/sANu77QsEDCJWm3wRz7zAABHvs9FN/A Hr/kg9UXrQFHhO4FAuYyJY/mmemX/65lIdAg4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dtvx8u6E+XBKdG4W5f0MYNqzDW4OxP+oEM9qn6Ifw4I=; b=bU6LJPoozvDA078ZpK6s3NWLsvI2uGFx2UEwOjKtnxafPrmuZXJhQND1baEfVGDloM kBLFpFRut1sL7hxVZjPCtMbUkNARgEQMzukuXwGGI7iBJiqF6UU2eQ0b6wzCGAcKD/+z YSdM+F7+JYFcThCSqOqUzoj4FHspPsmK6C2Sax1jsB9DTs4GGFljdytWJ1haGfyaDKDL ztaC5XfcABRSIk5IlsTR3ER9MkPLf2/r2elKiKlVlleUdtGxZOdGnkH44SIiokZcBDBD cPdHdVQSZqF3gVAFlukUNUyRBA6EWQJuAr4HlVLuRySNyb5mZ0HNcFy+JU5/5Ol1Ky0b slfA== X-Gm-Message-State: AOPr4FXaq7Tpk6CXNWDtW2zqxNvK3kp0/4JpQiwEX2XYPCvImoDuTj8DOgdpIU6JTCViwpJJchmpJoa8iS+J4qHu X-Received: by 10.50.29.242 with SMTP id n18mr13236058igh.62.1462824169688; Mon, 09 May 2016 13:02:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.81.1 with HTTP; Mon, 9 May 2016 13:02:20 -0700 (PDT) From: Brian Campbell Date: Mon, 9 May 2016 14:02:20 -0600 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary=f46d04428eca00fa7d05326e4b07 Archived-At: Subject: [Unbearable] fixing-up obsolete mentions of SignatureAndHashAlgorithms X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 09 May 2016 20:02:52 -0000 --f46d04428eca00fa7d05326e4b07 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In =C2=A73.4 or HTTPSTB there are two mentions of SignatureAndHashAlgorithm= s, which doesn't exist anymore. It was removed from TBPROTO a couple revisions ago. I sent a pull request, https://github.com/TokenBinding/Internet-Drafts/pull/31, with text to update the terminology to be consistent. I tried to use the correct terminology (Token Binding key parameters) and maintain the existing style of the document source. But, other than a comment from Jeff, it's just been sitting there for ten days so I thought I'd ping the list about it. It's not entirely clear what the best way to comment/contribute is - email to this list, pull requests, issues, other - so I figured I'd try a different one. I'm not partial to the particular text in the PR but do believe it's something that needs to be fixed in some way. --f46d04428eca00fa7d05326e4b07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In =C2=A73.4 or HTTPSTB there are two mentions o= f SignatureAndHashAlgorithms, which doesn't exist anymore. It was remov= ed from TBPROTO a couple revisions ago.

I sent a pull request,= https:= //github.com/TokenBinding/Internet-Drafts/pull/31, with text to update = the terminology to be consistent. I tried to use the correct terminology (T= oken Binding key parameters) and maintain the existing style of the documen= t source. But, other than a comment from Jeff, it's just been sitting t= here for ten days so I thought I'd ping the list about it. It's not= entirely clear what the best way to comment/contribute is - email to this = list, pull requests, issues, other - so I figured I'd try a different o= ne.

I'm not partial to the particular text in the PR= but do believe it's something that needs to be fixed in some way.
=





--f46d04428eca00fa7d05326e4b07-- From nobody Mon May 9 14:13:02 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0FA12D50C for ; Mon, 9 May 2016 14:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgxSeTTd4Qqa for ; Mon, 9 May 2016 14:12:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0779.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::779]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C50312D1B9 for ; Mon, 9 May 2016 14:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hHCqZntqd3hYTzgGeJDzurTVeRwx/8GhFwb5uEA30Y0=; b=o3icHhDRFi7GHNJ9uh/v+goLJDvMRgTqfsnsPDqpOniPEUBSL21VsqyZxWYi0rzJYi/1MFnoTXMNO+4icy61aLkDdDQIP2jaVNGg5+pz3W8Wi4Bw17anlRjRrjmAb6w0rZ6dgEs/nZD9GBOxI07N4qm3zPYL1/CwNMt3OfJybhw= Received: from BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) by BN3PR03MB1447.namprd03.prod.outlook.com (10.163.34.30) with Microsoft SMTP Server (TLS) id 15.1.492.11; Mon, 9 May 2016 21:12:33 +0000 Received: from BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) by BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) with mapi id 15.01.0492.015; Mon, 9 May 2016 21:12:33 +0000 From: Andrei Popov To: Brian Campbell , IETF Tokbind WG Thread-Topic: [Unbearable] fixing-up obsolete mentions of SignatureAndHashAlgorithms Thread-Index: AQHRqi3HzIf8Oi9lAke5R3rxeWEYh5+xGS5Q Date: Mon, 9 May 2016 21:12:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:e::1d2] x-ms-office365-filtering-correlation-id: 19b45665-3a19-488b-7778-08d3784ea3aa x-microsoft-exchange-diagnostics: 1; BN3PR03MB1447; 5:pq6CZJgnZ3o93F66pPu8FsmPWa9c+IX089VgxvMGIuDYfDApPm5hXkicN3TbVVVDqGeOYjrnYerGqrsB4IjDWFsbt1dyJtrhAz9LnFIR+O99nkiQpGK8eLwcteUtShy/tGefKW/isLso9OpfYF9SVQ==; 24:rCPDfz1LSWN6WAVT42xwi/llcZWDWq9fvWB3VgLgHt/LgM9BU9QVhTGq+u6Rkokba1ECdnUgtF/jnseVHJL/d1zsEzzSD30+KgcNSBg8B90=; 7:NPxIuecClM4DN78L+wMUD+FoDt6smhNRk1jHbM4CBraiCS7radaCw4Yk0jWPpqvLzNzgY/BdLENimPzbOeninJWbZ+YwD+WI/medfuHuJPxmZ4qV/vvXlkVD2YqF121OKY8XuPqZ2HAeiToIifAfYPi1VxbPUkm20FnHvxX3xG3aGx2jZqKeTg8kNg0GrVzZPZC5RsJmGDWx4ja8l376/w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1447; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN3PR03MB1447; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1447; x-forefront-prvs: 0937FB07C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(15975445007)(5003600100002)(77096005)(8990500004)(6116002)(1220700001)(122556002)(8936002)(19609705001)(102836003)(19300405004)(5008740100001)(790700001)(189998001)(2906002)(107886002)(19625215002)(5001770100001)(10400500002)(33656002)(10290500002)(586003)(11100500001)(76576001)(19580405001)(16236675004)(5005710100001)(10090500001)(19580395003)(50986999)(54356999)(81166005)(19617315012)(9326002)(9686002)(99286002)(92566002)(5004730100002)(3660700001)(74316001)(76176999)(3280700002)(87936001)(2950100001)(2900100001)(106116001)(5002640100001)(86362001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1447; H:BN3PR03MB1445.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB144507E132982E45C1759EDE8C700BN3PR03MB1445namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 May 2016 21:12:32.8011 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1447 Archived-At: Subject: Re: [Unbearable] fixing-up obsolete mentions of SignatureAndHashAlgorithms X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 09 May 2016 21:13:01 -0000 --_000_BN3PR03MB144507E132982E45C1759EDE8C700BN3PR03MB1445namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNCg0Kw5ggIEl0J3Mgbm90IGVudGlyZWx5IGNsZWFyIHdoYXQgdGhlIGJlc3Qg d2F5IHRvIGNvbW1lbnQvY29udHJpYnV0ZSBpcyAtIGVtYWlsIHRvIHRoaXMgbGlzdCwgcHVsbCBy ZXF1ZXN0cywgaXNzdWVzLCBvdGhlciAtIHNvIEkgZmlndXJlZCBJJ2QgdHJ5IGEgZGlmZmVyZW50 IG9uZS4NCklkZWFsbHksIFBSIG9yIGlzc3VlICsgbWVzc2FnZSBvbiB0aGUgbWFpbGluZyBsaXN0 LCBzaW5jZSBub3QgYWxsIFRva2JpbmQgcGFydGljaXBhbnRzIG1vbml0b3IgR2l0SHViLg0KDQoN CsOYICBCdXQsIG90aGVyIHRoYW4gYSBjb21tZW50IGZyb20gSmVmZiwgaXQncyBqdXN0IGJlZW4g c2l0dGluZyB0aGVyZSBmb3IgdGVuIGRheXMgc28gSSB0aG91Z2h0IEknZCBwaW5nIHRoZSBsaXN0 IGFib3V0IGl0Lg0KVGhpcyBpcyBjbGVhcmx5IGFuIGluY29uc2lzdGVuY3kgYmV0d2VlbiBkb2N1 bWVudHM7IHRoZSBlZGl0b3JzIHdpbGwgZml4IGluIHRoZSBuZXh0IHJldmlzaW9uLg0KDQpUaGFu a3MsDQoNCkFuZHJlaQ0KDQpGcm9tOiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJsZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IE1vbmRheSwg TWF5IDksIDIwMTYgMTowMiBQTQ0KVG86IElFVEYgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRm Lm9yZz4NClN1YmplY3Q6IFtVbmJlYXJhYmxlXSBmaXhpbmctdXAgb2Jzb2xldGUgbWVudGlvbnMg b2YgU2lnbmF0dXJlQW5kSGFzaEFsZ29yaXRobXMNCg0KSW4gwqczLjQgb3IgSFRUUFNUQiB0aGVy ZSBhcmUgdHdvIG1lbnRpb25zIG9mIFNpZ25hdHVyZUFuZEhhc2hBbGdvcml0aG1zLCB3aGljaCBk b2Vzbid0IGV4aXN0IGFueW1vcmUuIEl0IHdhcyByZW1vdmVkIGZyb20gVEJQUk9UTyBhIGNvdXBs ZSByZXZpc2lvbnMgYWdvLg0KSSBzZW50IGEgcHVsbCByZXF1ZXN0LCBodHRwczovL2dpdGh1Yi5j b20vVG9rZW5CaW5kaW5nL0ludGVybmV0LURyYWZ0cy9wdWxsLzMxLCB3aXRoIHRleHQgdG8gdXBk YXRlIHRoZSB0ZXJtaW5vbG9neSB0byBiZSBjb25zaXN0ZW50LiBJIHRyaWVkIHRvIHVzZSB0aGUg Y29ycmVjdCB0ZXJtaW5vbG9neSAoVG9rZW4gQmluZGluZyBrZXkgcGFyYW1ldGVycykgYW5kIG1h aW50YWluIHRoZSBleGlzdGluZyBzdHlsZSBvZiB0aGUgZG9jdW1lbnQgc291cmNlLiBCdXQsIG90 aGVyIHRoYW4gYSBjb21tZW50IGZyb20gSmVmZiwgaXQncyBqdXN0IGJlZW4gc2l0dGluZyB0aGVy ZSBmb3IgdGVuIGRheXMgc28gSSB0aG91Z2h0IEknZCBwaW5nIHRoZSBsaXN0IGFib3V0IGl0LiBJ dCdzIG5vdCBlbnRpcmVseSBjbGVhciB3aGF0IHRoZSBiZXN0IHdheSB0byBjb21tZW50L2NvbnRy aWJ1dGUgaXMgLSBlbWFpbCB0byB0aGlzIGxpc3QsIHB1bGwgcmVxdWVzdHMsIGlzc3Vlcywgb3Ro ZXIgLSBzbyBJIGZpZ3VyZWQgSSdkIHRyeSBhIGRpZmZlcmVudCBvbmUuDQpJJ20gbm90IHBhcnRp YWwgdG8gdGhlIHBhcnRpY3VsYXIgdGV4dCBpbiB0aGUgUFIgYnV0IGRvIGJlbGlldmUgaXQncyBz b21ldGhpbmcgdGhhdCBuZWVkcyB0byBiZSBmaXhlZCBpbiBzb21lIHdheS4NCg0KDQoNCg== --_000_BN3PR03MB144507E132982E45C1759EDE8C700BN3PR03MB1445namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjIwMjkxMzY5NjQ7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjExOTYyMDc1NzAgMTMyNTAy NjI1OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0 LWF0OjM7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsN Cgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQnJpYW4sPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpX aW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkl0J3Mgbm90IGVudGlyZWx5IGNsZWFy IHdoYXQgdGhlIGJlc3Qgd2F5IHRvIGNvbW1lbnQvY29udHJpYnV0ZSBpcyAtIGVtYWlsIHRvIHRo aXMgbGlzdCwgcHVsbCByZXF1ZXN0cywgaXNzdWVzLCBvdGhlciAtIHNvIEkgZmlndXJlZCBJJ2Qg dHJ5IGEgZGlmZmVyZW50IG9uZS48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPklkZWFsbHksIFBSIG9yIGlzc3VlICYjNDM7IG1lc3NhZ2Ugb24gdGhlIG1h aWxpbmcgbGlzdCwgc2luY2Ugbm90IGFsbCBUb2tiaW5kIHBhcnRpY2lwYW50cyBtb25pdG9yIEdp dEh1Yi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+QnV0LCBvdGhlciB0aGFuIGEgY29tbWVudCBmcm9tIEplZmYsIGl0J3MganVzdCBiZWVuIHNp dHRpbmcgdGhlcmUgZm9yIHRlbiBkYXlzIHNvIEkgdGhvdWdodCBJJ2QgcGluZyB0aGUgbGlzdCBh Ym91dCBpdC48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlRoaXMgaXMgY2xlYXJseSBhbiBpbmNvbnNpc3RlbmN5IGJldHdlZW4gZG9jdW1lbnRzOyB0aGUg ZWRpdG9ycyB3aWxsIGZpeCBpbiB0aGUgbmV4dCByZXZpc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkFuZHJlaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBVbmJlYXJhYmxlIFttYWlsdG86dW5i ZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBDYW1w YmVsbDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSA5LCAyMDE2IDE6MDIgUE08YnI+DQo8 Yj5Ubzo8L2I+IElFVEYgVG9rYmluZCBXRyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gW1VuYmVhcmFibGVdIGZpeGluZy11cCBvYnNvbGV0ZSBtZW50aW9u cyBvZiBTaWduYXR1cmVBbmRIYXNoQWxnb3JpdGhtczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5J biDCpzMuNCBvciBIVFRQU1RCIHRoZXJlIGFyZSB0d28gbWVudGlvbnMgb2YgU2lnbmF0dXJlQW5k SGFzaEFsZ29yaXRobXMsIHdoaWNoIGRvZXNuJ3QgZXhpc3QgYW55bW9yZS4gSXQgd2FzIHJlbW92 ZWQgZnJvbSBUQlBST1RPIGEgY291cGxlIHJldmlzaW9ucyBhZ28uPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ SSBzZW50IGEgcHVsbCByZXF1ZXN0LCA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vVG9rZW5C aW5kaW5nL0ludGVybmV0LURyYWZ0cy9wdWxsLzMxIj4NCmh0dHBzOi8vZ2l0aHViLmNvbS9Ub2tl bkJpbmRpbmcvSW50ZXJuZXQtRHJhZnRzL3B1bGwvMzE8L2E+LCB3aXRoIHRleHQgdG8gdXBkYXRl IHRoZSB0ZXJtaW5vbG9neSB0byBiZSBjb25zaXN0ZW50LiBJIHRyaWVkIHRvIHVzZSB0aGUgY29y cmVjdCB0ZXJtaW5vbG9neSAoVG9rZW4gQmluZGluZyBrZXkgcGFyYW1ldGVycykgYW5kIG1haW50 YWluIHRoZSBleGlzdGluZyBzdHlsZSBvZiB0aGUgZG9jdW1lbnQgc291cmNlLiBCdXQsIG90aGVy IHRoYW4NCiBhIGNvbW1lbnQgZnJvbSBKZWZmLCBpdCdzIGp1c3QgYmVlbiBzaXR0aW5nIHRoZXJl IGZvciB0ZW4gZGF5cyBzbyBJIHRob3VnaHQgSSdkIHBpbmcgdGhlIGxpc3QgYWJvdXQgaXQuIEl0 J3Mgbm90IGVudGlyZWx5IGNsZWFyIHdoYXQgdGhlIGJlc3Qgd2F5IHRvIGNvbW1lbnQvY29udHJp YnV0ZSBpcyAtIGVtYWlsIHRvIHRoaXMgbGlzdCwgcHVsbCByZXF1ZXN0cywgaXNzdWVzLCBvdGhl ciAtIHNvIEkgZmlndXJlZCBJJ2QgdHJ5IGEgZGlmZmVyZW50DQogb25lLiA8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBub3QgcGFydGlhbCB0 byB0aGUgcGFydGljdWxhciB0ZXh0IGluIHRoZSBQUiBidXQgZG8gYmVsaWV2ZSBpdCdzIHNvbWV0 aGluZyB0aGF0IG5lZWRzIHRvIGJlIGZpeGVkIGluIHNvbWUgd2F5Lg0KPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_BN3PR03MB144507E132982E45C1759EDE8C700BN3PR03MB1445namp_-- From nobody Mon May 9 14:30:39 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47B2112D596 for ; Mon, 9 May 2016 14:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58jbs65nW_es for ; Mon, 9 May 2016 14:30:35 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B74C12D1B9 for ; Mon, 9 May 2016 14:30:35 -0700 (PDT) Received: by mail-ig0-x229.google.com with SMTP id m9so103125948ige.1 for ; Mon, 09 May 2016 14:30:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NWk1SQ3RxR/ICpiMnQ7EiI9f1UPVR2d/XpXGpkPCByo=; b=LVa6S3UujMVgpSISIQWC7O1/NSTUHgt/44Itotv0dy2fv3g9OCHebhC1Ad4SrVSupb m5Fe5lvouQOq5Of6FqK3l4V9zuCif0p5k7LyaUrTY0W+x7c7ExensrnOgsyLji2YA5Al au0Aeo9snt10kOlIA031hfjCZvor8ejzedf5w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NWk1SQ3RxR/ICpiMnQ7EiI9f1UPVR2d/XpXGpkPCByo=; b=LsZ43kWeolkMK7chJOXlR1UuqI7Q7qiaGQe+3kbbD7Mnm+0VoziqlFSatQnsa1XTqk pcBy+DfwkbccjbuBMa/zw6S4W7wWRwH1cj7TovUnexB6G6VsjMBb2/a5rp46OlENYmgI 25bq35fbQ/GHaJw5aHjEt34o6EuE1zTq36X4kytpScYpQEQtXGB7rfWiR7Y/EjNaK/fa gFwgfU9bho/A0Ap9+7K+MsqCjcSa9Pbw4uSPWNlGES77kcg5Gb04WJyhVCAcaC0w2ChG cVarupjNs4y31TVGNO+TwxMW8/dT/ZsN32ZsVnJvu4E/XUjFPUjsJBLg3880kjmTWKXM sqjg== X-Gm-Message-State: AOPr4FX7euFddDejSi9XlJMyG8vVmimSRfKIn6y5DRrtU2DXh9k74OgJLVQnBEQhw5Pjo91NrztAwiA9ORlCIYuR X-Received: by 10.50.29.242 with SMTP id n18mr13568717igh.62.1462829434506; Mon, 09 May 2016 14:30:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.81.1 with HTTP; Mon, 9 May 2016 14:30:05 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 9 May 2016 15:30:05 -0600 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=f46d04428ecacfadb105326f8452 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] fixing-up obsolete mentions of SignatureAndHashAlgorithms X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 09 May 2016 21:30:37 -0000 --f46d04428ecacfadb105326f8452 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Andrei. On Mon, May 9, 2016 at 3:12 PM, Andrei Popov wrote: > Hi Brian, > > > > =C3=98 It's not entirely clear what the best way to comment/contribute i= s - > email to this list, pull requests, issues, other - so I figured I'd try a > different one. > > Ideally, PR or issue + message on the mailing list, since not all Tokbind > participants monitor GitHub. > > > > =C3=98 But, other than a comment from Jeff, it's just been sitting there= for > ten days so I thought I'd ping the list about it. > > This is clearly an inconsistency between documents; the editors will fix > in the next revision. > > > > Thanks, > > > > Andrei > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Br= ian > Campbell > *Sent:* Monday, May 9, 2016 1:02 PM > *To:* IETF Tokbind WG > *Subject:* [Unbearable] fixing-up obsolete mentions of > SignatureAndHashAlgorithms > > > > In =C2=A73.4 or HTTPSTB there are two mentions of SignatureAndHashAlgorit= hms, > which doesn't exist anymore. It was removed from TBPROTO a couple revisio= ns > ago. > > I sent a pull request, > https://github.com/TokenBinding/Internet-Drafts/pull/31, with text to > update the terminology to be consistent. I tried to use the correct > terminology (Token Binding key parameters) and maintain the existing styl= e > of the document source. But, other than a comment from Jeff, it's just be= en > sitting there for ten days so I thought I'd ping the list about it. It's > not entirely clear what the best way to comment/contribute is - email to > this list, pull requests, issues, other - so I figured I'd try a differen= t > one. > > I'm not partial to the particular text in the PR but do believe it's > something that needs to be fixed in some way. > > > > > > --f46d04428ecacfadb105326f8452 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Andrei.

On Mon, May 9, 2016 at 3:12 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

Hi Brian,

=C2=A0

=C3=98= =C2=A0 It's not entirely clear what the best way t= o comment/contribute is - email to this list, pull requests, issues, other = - so I figured I'd try a different one.

Ideally, PR or issue + message o= n the mailing list, since not all Tokbind participants monitor GitHub.

=C2=A0

=C3=98= =C2=A0 But, other than a comment from Jeff, it's j= ust been sitting there for ten days so I thought I'd ping the list abou= t it.

This is clearly an inconsistency= between documents; the editors will fix in the next revision.

=C2=A0

Thanks,

=C2=A0

Andrei

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ietf.o= rg] On Behalf Of Brian Campbell
Sent: Monday, May 9, 2016 1:02 PM
To: IETF Tokbind WG <unbearable@ietf.org>
Subject: [Unbearable] fixing-up obsolete mentions of SignatureAndHas= hAlgorithms

=C2=A0

In =C2=A73.4 or HTTPSTB= there are two mentions of SignatureAndHashAlgorithms, which doesn't ex= ist anymore. It was removed from TBPROTO a couple revisions ago.<= /u>

I sent a pull request, = https://github.com/TokenBinding/Internet-Drafts/pull/31, with text to u= pdate the terminology to be consistent. I tried to use the correct terminol= ogy (Token Binding key parameters) and maintain the existing style of the d= ocument source. But, other than a comment from Jeff, it's just been sitting there for ten days so I th= ought I'd ping the list about it. It's not entirely clear what the = best way to comment/contribute is - email to this list, pull requests, issu= es, other - so I figured I'd try a different one.

I'm not partial to the particular text in the PR= but do believe it's something that needs to be fixed in some way.

=C2=A0




--f46d04428ecacfadb105326f8452-- From nobody Fri May 13 14:15:42 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C6D12D66E for ; Fri, 13 May 2016 14:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYnq9wFIycgL for ; Fri, 13 May 2016 14:15:32 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507E312D616 for ; Fri, 13 May 2016 14:15:32 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id 190so148304400iow.1 for ; Fri, 13 May 2016 14:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=heaVPm7QX82oFGX4xq/dbeh/yt46QJBEP2QdR5MWS6M=; b=hRhd8wmE2OhTT+JCbE6jk1ZCMSF1CgF84XlbST+8S3YIITBXNi5SffNWzW4P5rwrAj N220Fd9BJmLcce+4BRDw/0K4mlo/cxpZYh0y7+R0PJSiotEiPwlW+iSkJZR3sz9thJyV CtwtiLoHg1IojvFnZktO/sbBPG/q/X6/t5QqM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=heaVPm7QX82oFGX4xq/dbeh/yt46QJBEP2QdR5MWS6M=; b=gotOhIe4nBIX5GAc+Xgf57bqZC2lpI41TBTgaCb838Yh1wuTXOpa3C2GOhVnxyGARN 4JmAJsN3FLiaySRdZrWm5Ihdb3UBq48NpM4iaiXGEjweWWKuKeoxFZz49Blc1yyACTYo ovCTwCyG1ApKaowUF19823BlSyzBclQLsLVQ8Vfk/77DhhK3B4gdpXNw7VdzdB3xqi0x Qzl1K1adrjlHiXuKculcXWx3hKDwADUmiBUNd4x30tKRfbJ5pPsmb21T+QXxtxAZDc2f a6QTS21u11iQTCqR58gIIj223eFHsfrTd+Pnq2ze1QePzT9WGbe/nn3eZdM1jcobUqJr YuRg== X-Gm-Message-State: AOPr4FUkZywx3NnV79fbul1gR0ibYdzMnbzCQNbhp8VoM3ASWHYBw4AyD7mNxL2VJKWVio1Iz/UEBi0L9K+F/6k5 X-Received: by 10.107.8.141 with SMTP id h13mr13383679ioi.95.1463174131587; Fri, 13 May 2016 14:15:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.105.129 with HTTP; Fri, 13 May 2016 14:15:02 -0700 (PDT) From: Brian Campbell Date: Fri, 13 May 2016 15:15:02 -0600 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary=001a113f9ab05bd85a0532bfc6b8 Archived-At: Subject: [Unbearable] HTTPSTB: discuss scoping of token binding keys earlier in the document X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 13 May 2016 21:15:36 -0000 --001a113f9ab05bd85a0532bfc6b8 Content-Type: text/plain; charset=UTF-8 I put in https://github.com/TokenBinding/Internet-Drafts/issues/33 but am sending this message to the list too as some/many WG participants don't actively monitor GitHub (as suggested by Andrei). Text of the issue is copied below. Thanks! As of draft-ietf-tokbind-https-03 in the Privacy Considerations Section 5.1 Scoping of Token Binding Keys is the first real mention that token binding keys/ids should be scoped to public suffix + 1. Though the first sentence in 3.1 hints at it, it's not defined until later. The scope of where TB keys are sent is a pretty fundamental part of HTTPSTB and, as such, I believe should be defined/discussed in Section 2 along with the Sec-Token-Binding header that the scoping applies to. The Privacy Considerations are still good considerations but then could refer back to the scoping definition in Sec 2 rather than being the definition. Public suffix + 1 makes sense as the scope for browser user agents but is maybe overly restrictive/prescriptive for some other HTTPS cases. OAuth access tokens come to mind, although it's still up in the air at this point how exactly OAuth will leverage TB, but there's potently a case for an OAuth client acting as an HTTPS client to want to have an token bound access token that can be used at multiple resource servers, which might be on different hosts/domains. The privacy concerns that arise from that situation are already there because the access token is correlatable so allowing the scope of the TB key to do the same doesn't make things any worse. It's the same from a privacy perspective, just more secure. Having HTTPSTB clearly define the public suffix + 1 scope for browsers while still allowing for cases like that OAuth one might be useful. --001a113f9ab05bd85a0532bfc6b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I put in https://github.com/TokenBinding/Internet-Drafts/issues= /33 but am sending this message to the list too as some/many WG partici= pants don't actively monitor GitHub (as suggested by Andrei). Text of t= he issue is copied below. Thanks!


As of draft-ietf-tokbind-https-03 in the Privacy Consid= erations=C2=A0Section 5.1 Scoping of To= ken Binding Keys is the first real mention that token binding keys/ids = should be scoped to public suffix + 1. Though the first sentence in 3.1 hin= ts at it, it's not defined until later.

The scope of where TB keys are sent is a pretty fundamental part of H= TTPSTB and, as such, I believe should be defined/discussed in Section 2 alo= ng with the Sec-Token-Binding header that the scoping applies to. The Priva= cy Considerations are still good considerations but then could refer back t= o the scoping definition in Sec 2 rather than being the definition.

Public suffix + 1 makes sense as the= scope for browser user agents but is maybe overly restrictive/prescriptive= for some other HTTPS cases. OAuth access tokens come to mind, although it&= #39;s still up in the air at this point how exactly OAuth will leverage TB,= but there's potently a case for an OAuth client acting as an HTTPS cli= ent to want to have an token bound access token that can be used at multipl= e resource servers, which might be on different hosts/domains. The privacy = concerns that arise from that situation are already there because the acces= s token is correlatable so allowing the scope of the TB key to do the same = doesn't make things any worse. It's the same from a privacy perspec= tive, just more secure. Having HTTPSTB clearly define the public suffix + 1= scope for browsers while still allowing for cases like that OAuth one migh= t be useful.


--001a113f9ab05bd85a0532bfc6b8-- From nobody Fri May 13 14:43:45 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CBC12D616 for ; Fri, 13 May 2016 14:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zX55EJdGSxqd for ; Fri, 13 May 2016 14:43:40 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-eopbgr700097.outbound.protection.outlook.com [40.107.70.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC04212B030 for ; Fri, 13 May 2016 14:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qxjmDqFplWoZW3XnJ+J5OWvUZXk64R6A/PhLofyEO00=; b=APJDHbxoZTKA6AW32wXdv8G/4hKsAlN8WvgMbArzsXjFAFxQ9d9TPxfA/hkANIqkbF77b83siuCle2lCk7cSNOdOwirR/CAmnuXdKFHaxZvKIfJthSxJCT06fkBdGU9i65QKPmwjO4OA43vYbn1gzW8N282Q1swRqJftMrtFlVQ= Received: from BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) by BN3PR03MB1446.namprd03.prod.outlook.com (10.163.34.29) with Microsoft SMTP Server (TLS) id 15.1.497.12; Fri, 13 May 2016 21:43:39 +0000 Received: from BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) by BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) with mapi id 15.01.0497.014; Fri, 13 May 2016 21:43:39 +0000 From: Andrei Popov To: Brian Campbell , IETF Tokbind WG Thread-Topic: [Unbearable] HTTPSTB: discuss scoping of token binding keys earlier in the document Thread-Index: AQHRrVyevC62/vyg4k2YGB+29bAoRp+3ZXeA Date: Fri, 13 May 2016 21:43:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:f::1d2] x-ms-office365-filtering-correlation-id: da0e40ce-203c-4a41-8f71-08d37b77a540 x-microsoft-exchange-diagnostics: 1; BN3PR03MB1446; 5:CdVVjayApCvh6dY3ywGClJctX9stuNy8A58Zun7INIhX4F/DMwTPjc48zmG4QYelNLxIwI5fjV8/xI++TV0qOeejDx1k/9YTSBAvWRAvqVl0VEkFdt+Iw1yhTRwy5BsZgVEowZKzmUwP1Xxdo/9V7Q==; 24:QXcwxK9MvTvcU4OzVokzku+q8jlu1cp//+4rYPUTqmaOeFRwDVk/BD1hpzLJRc5+MKViEd2taW7kCASYSUOXbVGM0idxDZAgKk3nRWoA/7Q=; 7:rtNYgm18nzIiQfb35Hbnv1D04vXauJxzWlu2gt5bFBjFVcok+clZ89pVC5TPZeybUAx4kJUbx6jt2El/ODJ6pWswArWkVg8+9rnqeTJuhzQnJIXKGtLnmdYTgENAsFA1DOW+OSFE0ty5ymBN6qoiCzervkREnQdLDUG7Kk4yw7zvpwPJO+igXVavRbckcFNYCN/LjpryWuX4ooOhaVwl2Q== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR03MB1446; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1446; x-forefront-prvs: 0941B96580 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(10400500002)(5005710100001)(10290500002)(81166006)(19300405004)(8990500004)(33656002)(87936001)(8936002)(2906002)(19617315012)(6116002)(76576001)(76176999)(54356999)(50986999)(19625215002)(3660700001)(3280700002)(1220700001)(86612001)(102836003)(5008740100001)(9686002)(586003)(5002640100001)(74316001)(9326002)(790700001)(86362001)(19580395003)(99286002)(15975445007)(19580405001)(5004730100002)(16236675004)(106116001)(122556002)(5001770100001)(2950100001)(2900100001)(10090500001)(19609705001)(107886002)(5003600100002)(189998001)(92566002)(11100500001)(77096005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1446; H:BN3PR03MB1445.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB1445F6B86A15237F43DA3CC98C740BN3PR03MB1445namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2016 21:43:39.0199 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1446 Archived-At: Subject: Re: [Unbearable] HTTPSTB: discuss scoping of token binding keys earlier in the document X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 13 May 2016 21:43:43 -0000 --_000_BN3PR03MB1445F6B86A15237F43DA3CC98C740BN3PR03MB1445namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNCg0Kw5ggIEhhdmluZyBIVFRQU1RCIGNsZWFybHkgZGVmaW5lIHRoZSBwdWJs aWMgc3VmZml4ICsgMSBzY29wZSBmb3IgYnJvd3NlcnMgd2hpbGUgc3RpbGwgYWxsb3dpbmcgZm9y IGNhc2VzIGxpa2UgdGhhdCBPQXV0aCBvbmUgbWlnaHQgYmUgdXNlZnVsLg0KUGVyaGFwcyB0aGUg bGF0dGVyIChkaWZmZXJlbnQga2V5IHNjb3BpbmcgZm9yIE9BdXRoKSBzaG91bGQgYmUgcGFydCBv ZiBhIHNlcGFyYXRlIE9BVVRIVEIgc3BlYy4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KRnJvbTog VW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEJyaWFuIENhbXBiZWxsDQpTZW50OiBGcmlkYXksIE1heSAxMywgMjAxNiAyOjE1IFBNDQpU bzogSUVURiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogW1VuYmVh cmFibGVdIEhUVFBTVEI6IGRpc2N1c3Mgc2NvcGluZyBvZiB0b2tlbiBiaW5kaW5nIGtleXMgZWFy bGllciBpbiB0aGUgZG9jdW1lbnQNCg0KSSBwdXQgaW4gaHR0cHM6Ly9naXRodWIuY29tL1Rva2Vu QmluZGluZy9JbnRlcm5ldC1EcmFmdHMvaXNzdWVzLzMzIGJ1dCBhbSBzZW5kaW5nIHRoaXMgbWVz c2FnZSB0byB0aGUgbGlzdCB0b28gYXMgc29tZS9tYW55IFdHIHBhcnRpY2lwYW50cyBkb24ndCBh Y3RpdmVseSBtb25pdG9yIEdpdEh1YiAoYXMgc3VnZ2VzdGVkIGJ5IEFuZHJlaSkuIFRleHQgb2Yg dGhlIGlzc3VlIGlzIGNvcGllZCBiZWxvdy4gVGhhbmtzIQ0KDQoNCg0KDQpBcyBvZiBkcmFmdC1p ZXRmLXRva2JpbmQtaHR0cHMtMDMgaW4gdGhlIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMgU2VjdGlv biA1LjEgU2NvcGluZyBvZiBUb2tlbiBCaW5kaW5nIEtleXMgPGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQtaHR0cHMtMDMjc2VjdGlvbi01LjE+IGlzIHRoZSBm aXJzdCByZWFsIG1lbnRpb24gdGhhdCB0b2tlbiBiaW5kaW5nIGtleXMvaWRzIHNob3VsZCBiZSBz Y29wZWQgdG8gcHVibGljIHN1ZmZpeCArIDEuIFRob3VnaCB0aGUgZmlyc3Qgc2VudGVuY2UgaW4g My4xIGhpbnRzIGF0IGl0LCBpdCdzIG5vdCBkZWZpbmVkIHVudGlsIGxhdGVyLg0KDQpUaGUgc2Nv cGUgb2Ygd2hlcmUgVEIga2V5cyBhcmUgc2VudCBpcyBhIHByZXR0eSBmdW5kYW1lbnRhbCBwYXJ0 IG9mIEhUVFBTVEIgYW5kLCBhcyBzdWNoLCBJIGJlbGlldmUgc2hvdWxkIGJlIGRlZmluZWQvZGlz Y3Vzc2VkIGluIFNlY3Rpb24gMiBhbG9uZyB3aXRoIHRoZSBTZWMtVG9rZW4tQmluZGluZyBoZWFk ZXIgdGhhdCB0aGUgc2NvcGluZyBhcHBsaWVzIHRvLiBUaGUgUHJpdmFjeSBDb25zaWRlcmF0aW9u cyBhcmUgc3RpbGwgZ29vZCBjb25zaWRlcmF0aW9ucyBidXQgdGhlbiBjb3VsZCByZWZlciBiYWNr IHRvIHRoZSBzY29waW5nIGRlZmluaXRpb24gaW4gU2VjIDIgcmF0aGVyIHRoYW4gYmVpbmcgdGhl IGRlZmluaXRpb24uDQoNClB1YmxpYyBzdWZmaXggKyAxIG1ha2VzIHNlbnNlIGFzIHRoZSBzY29w ZSBmb3IgYnJvd3NlciB1c2VyIGFnZW50cyBidXQgaXMgbWF5YmUgb3Zlcmx5IHJlc3RyaWN0aXZl L3ByZXNjcmlwdGl2ZSBmb3Igc29tZSBvdGhlciBIVFRQUyBjYXNlcy4gT0F1dGggYWNjZXNzIHRv a2VucyBjb21lIHRvIG1pbmQsIGFsdGhvdWdoIGl0J3Mgc3RpbGwgdXAgaW4gdGhlIGFpciBhdCB0 aGlzIHBvaW50IGhvdyBleGFjdGx5IE9BdXRoIHdpbGwgbGV2ZXJhZ2UgVEIsIGJ1dCB0aGVyZSdz IHBvdGVudGx5IGEgY2FzZSBmb3IgYW4gT0F1dGggY2xpZW50IGFjdGluZyBhcyBhbiBIVFRQUyBj bGllbnQgdG8gd2FudCB0byBoYXZlIGFuIHRva2VuIGJvdW5kIGFjY2VzcyB0b2tlbiB0aGF0IGNh biBiZSB1c2VkIGF0IG11bHRpcGxlIHJlc291cmNlIHNlcnZlcnMsIHdoaWNoIG1pZ2h0IGJlIG9u IGRpZmZlcmVudCBob3N0cy9kb21haW5zLiBUaGUgcHJpdmFjeSBjb25jZXJucyB0aGF0IGFyaXNl IGZyb20gdGhhdCBzaXR1YXRpb24gYXJlIGFscmVhZHkgdGhlcmUgYmVjYXVzZSB0aGUgYWNjZXNz IHRva2VuIGlzIGNvcnJlbGF0YWJsZSBzbyBhbGxvd2luZyB0aGUgc2NvcGUgb2YgdGhlIFRCIGtl eSB0byBkbyB0aGUgc2FtZSBkb2Vzbid0IG1ha2UgdGhpbmdzIGFueSB3b3JzZS4gSXQncyB0aGUg c2FtZSBmcm9tIGEgcHJpdmFjeSBwZXJzcGVjdGl2ZSwganVzdCBtb3JlIHNlY3VyZS4gSGF2aW5n IEhUVFBTVEIgY2xlYXJseSBkZWZpbmUgdGhlIHB1YmxpYyBzdWZmaXggKyAxIHNjb3BlIGZvciBi cm93c2VycyB3aGlsZSBzdGlsbCBhbGxvd2luZyBmb3IgY2FzZXMgbGlrZSB0aGF0IE9BdXRoIG9u ZSBtaWdodCBiZSB1c2VmdWwuDQoNCg== --_000_BN3PR03MB1445F6B86A15237F43DA3CC98C740BN3PR03MB1445namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFy YWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJ bWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsN CgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MzcwNjExMTY5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczotNjc3NDkzNTE0IC0xNjk1NzU0NDU2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6ODsNCgltc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg bDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5I aSBCcmlhbiwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+ PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPkhhdmluZyBIVFRQU1RC IGNsZWFybHkgZGVmaW5lIHRoZSBwdWJsaWMgc3VmZml4ICYjNDM7IDEgc2NvcGUgZm9yIGJyb3dz ZXJzIHdoaWxlIHN0aWxsIGFsbG93aW5nIGZvciBjYXNlcyBsaWtlIHRoYXQgT0F1dGggb25lIG1p Z2h0IGJlIHVzZWZ1bC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5QZXJoYXBzIHRoZSBsYXR0ZXIgKGRpZmZlcmVudCBrZXkgc2NvcGluZyBm b3IgT0F1dGgpIHNob3VsZCBiZSBwYXJ0IG9mIGEgc2VwYXJhdGUgT0FVVEhUQiBzcGVjLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kcmVpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFVuYmVhcmFi bGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTWF5IDEzLCAyMDE2 IDI6MTUgUE08YnI+DQo8Yj5Ubzo8L2I+IElFVEYgVG9rYmluZCBXRyAmbHQ7dW5iZWFyYWJsZUBp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1VuYmVhcmFibGVdIEhUVFBTVEI6IGRp c2N1c3Mgc2NvcGluZyBvZiB0b2tlbiBiaW5kaW5nIGtleXMgZWFybGllciBpbiB0aGUgZG9jdW1l bnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHB1dCBpbiA8YSBocmVm PSJodHRwczovL2dpdGh1Yi5jb20vVG9rZW5CaW5kaW5nL0ludGVybmV0LURyYWZ0cy9pc3N1ZXMv MzMiPg0KaHR0cHM6Ly9naXRodWIuY29tL1Rva2VuQmluZGluZy9JbnRlcm5ldC1EcmFmdHMvaXNz dWVzLzMzPC9hPiBidXQgYW0gc2VuZGluZyB0aGlzIG1lc3NhZ2UgdG8gdGhlIGxpc3QgdG9vIGFz IHNvbWUvbWFueSBXRyBwYXJ0aWNpcGFudHMgZG9uJ3QgYWN0aXZlbHkgbW9uaXRvciBHaXRIdWIg KGFzIHN1Z2dlc3RlZCBieSBBbmRyZWkpLiBUZXh0IG9mIHRoZSBpc3N1ZSBpcyBjb3BpZWQgYmVs b3cuIFRoYW5rcyENCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0O2xpbmUtaGVpZ2h0OjE2LjhwdDtiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMzMzMzMzIj5BcyBvZiBkcmFmdC1pZXRmLXRva2JpbmQtaHR0cHMtMDMg aW4gdGhlIFByaXZhY3kgQ29uc2lkZXJhdGlvbnMmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzLTAzI3NlY3Rpb24tNS4xIj48 c3BhbiBzdHlsZT0iY29sb3I6IzQwNzhDMDt0ZXh0LWRlY29yYXRpb246bm9uZSI+U2VjdGlvbg0K IDUuMSBTY29waW5nIG9mIFRva2VuIEJpbmRpbmcgS2V5cyA8L3NwYW4+PC9hPmlzIHRoZSBmaXJz dCByZWFsIG1lbnRpb24gdGhhdCB0b2tlbiBiaW5kaW5nIGtleXMvaWRzIHNob3VsZCBiZSBzY29w ZWQgdG8gcHVibGljIHN1ZmZpeCAmIzQzOyAxLiBUaG91Z2ggdGhlIGZpcnN0IHNlbnRlbmNlIGlu IDMuMSBoaW50cyBhdCBpdCwgaXQncyBub3QgZGVmaW5lZCB1bnRpbCBsYXRlci48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBpbjtsaW5lLWhlaWdodDox Ni44cHQ7YmFja2dyb3VuZDp3aGl0ZTt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+VGhlIHNjb3BlIG9mIHdoZXJlIFRC IGtleXMgYXJlIHNlbnQgaXMgYSBwcmV0dHkgZnVuZGFtZW50YWwgcGFydCBvZiBIVFRQU1RCIGFu ZCwgYXMgc3VjaCwgSSBiZWxpZXZlIHNob3VsZCBiZSBkZWZpbmVkL2Rpc2N1c3NlZCBpbiBTZWN0 aW9uIDIgYWxvbmcgd2l0aCB0aGUgU2VjLVRva2VuLUJpbmRpbmcgaGVhZGVyDQogdGhhdCB0aGUg c2NvcGluZyBhcHBsaWVzIHRvLiBUaGUgUHJpdmFjeSBDb25zaWRlcmF0aW9ucyBhcmUgc3RpbGwg Z29vZCBjb25zaWRlcmF0aW9ucyBidXQgdGhlbiBjb3VsZCByZWZlciBiYWNrIHRvIHRoZSBzY29w aW5nIGRlZmluaXRpb24gaW4gU2VjIDIgcmF0aGVyIHRoYW4gYmVpbmcgdGhlIGRlZmluaXRpb24u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MGluO2xpbmUtaGVp Z2h0OjE2LjhwdDtiYWNrZ3JvdW5kOndoaXRlO21hcmdpbi1ib3R0b206MHB4IWltcG9ydGFudDt0 ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzMzMzMzMyI+UHVibGljIHN1ZmZpeCAmIzQzOyAxIG1ha2VzIHNlbnNlIGFzIHRoZSBzY29w ZSBmb3IgYnJvd3NlciB1c2VyIGFnZW50cyBidXQgaXMgbWF5YmUgb3Zlcmx5IHJlc3RyaWN0aXZl L3ByZXNjcmlwdGl2ZSBmb3Igc29tZSBvdGhlciBIVFRQUyBjYXNlcy4gT0F1dGggYWNjZXNzIHRv a2VucyBjb21lIHRvIG1pbmQsIGFsdGhvdWdoDQogaXQncyBzdGlsbCB1cCBpbiB0aGUgYWlyIGF0 IHRoaXMgcG9pbnQgaG93IGV4YWN0bHkgT0F1dGggd2lsbCBsZXZlcmFnZSBUQiwgYnV0IHRoZXJl J3MgcG90ZW50bHkgYSBjYXNlIGZvciBhbiBPQXV0aCBjbGllbnQgYWN0aW5nIGFzIGFuIEhUVFBT IGNsaWVudCB0byB3YW50IHRvIGhhdmUgYW4gdG9rZW4gYm91bmQgYWNjZXNzIHRva2VuIHRoYXQg Y2FuIGJlIHVzZWQgYXQgbXVsdGlwbGUgcmVzb3VyY2Ugc2VydmVycywgd2hpY2ggbWlnaHQgYmUg b24NCiBkaWZmZXJlbnQgaG9zdHMvZG9tYWlucy4gVGhlIHByaXZhY3kgY29uY2VybnMgdGhhdCBh cmlzZSBmcm9tIHRoYXQgc2l0dWF0aW9uIGFyZSBhbHJlYWR5IHRoZXJlIGJlY2F1c2UgdGhlIGFj Y2VzcyB0b2tlbiBpcyBjb3JyZWxhdGFibGUgc28gYWxsb3dpbmcgdGhlIHNjb3BlIG9mIHRoZSBU QiBrZXkgdG8gZG8gdGhlIHNhbWUgZG9lc24ndCBtYWtlIHRoaW5ncyBhbnkgd29yc2UuIEl0J3Mg dGhlIHNhbWUgZnJvbSBhIHByaXZhY3kgcGVyc3BlY3RpdmUsDQoganVzdCBtb3JlIHNlY3VyZS4g SGF2aW5nIEhUVFBTVEIgY2xlYXJseSBkZWZpbmUgdGhlIHB1YmxpYyBzdWZmaXggJiM0MzsgMSBz Y29wZSBmb3IgYnJvd3NlcnMgd2hpbGUgc3RpbGwgYWxsb3dpbmcgZm9yIGNhc2VzIGxpa2UgdGhh dCBPQXV0aCBvbmUgbWlnaHQgYmUgdXNlZnVsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN3PR03MB1445F6B86A15237F43DA3CC98C740BN3PR03MB1445namp_-- From nobody Fri May 13 14:50:31 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A38AF12B030 for ; Fri, 13 May 2016 14:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-LFv9RDAZUQ for ; Fri, 13 May 2016 14:50:28 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F83612D6A1 for ; Fri, 13 May 2016 14:50:28 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id f89so148766008ioi.0 for ; Fri, 13 May 2016 14:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VpAFzu3PKKyRmocaLKlMfhpf06I7Fn/3NYIlZASC788=; b=pBkCwmEDbwYlT05YT6h8R0tGibQQTghWEPID21wB07bLUL/q3BuL+OwpCnljQDCDh5 SJUAuJEyktiniARQay1vTM/VB8Bjw7co41G/iUSLWKqKcVcQNy1aawLWdl25AhcJoF8M hNCn6DJqfasiAatpdFDvLSf75VOVotAiUxyjQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VpAFzu3PKKyRmocaLKlMfhpf06I7Fn/3NYIlZASC788=; b=VnAqB9U0v8Drvb0gRh5YIINXxJ5rsNsmXJ5dT1qiUNYJCqXG6WexMuQsdGyIIIyhJZ OA0tdO4fa1BpzZ+fG/gkWYMZL+nfafLjgK53oFCOUImTDvgHvhT37ZTaUJRqbC8ZKf87 S4U13GdqKoCqrI2PVVP2e3Mnd473Zc67mqj2cXjIQcOsWynop0OM0WLWL0qi1I3I5yYw szJwAOm5MSu13ABoI9InyraqvrdOG9HuswJVPj3Yb0BSZ03VMiAhH0f3VJ2IstW9RDdr bkPhHLm5Mnto/iHWneX9IzcRcHSdLNXUl3UNJSo4UCxwhjqNFYzdQibWLLFgA7eTLXR5 DhBQ== X-Gm-Message-State: AOPr4FUiXE5A2uQ35Tu7CspLx5jLcPq0fla9RVyqjyuLesTLtB2/X/gTRwL8BvlwbFgzCYgYHtKU2mg9DvbgTD7H X-Received: by 10.36.123.77 with SMTP id q74mr3374243itc.42.1463176227352; Fri, 13 May 2016 14:50:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.105.129 with HTTP; Fri, 13 May 2016 14:49:57 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Fri, 13 May 2016 15:49:57 -0600 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a11475b2246b15f0532c0437d Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] HTTPSTB: discuss scoping of token binding keys earlier in the document X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 13 May 2016 21:50:30 -0000 --001a11475b2246b15f0532c0437d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed, HTTPSTB shouldn't define any scoping for the hypothetical OAUTHTB. But OAuth also uses HTTPS so having the language in HTTPSTB not preclude what OAuth might do could be useful. On Fri, May 13, 2016 at 3:43 PM, Andrei Popov wrote: > Hi Brian, > > > > =C3=98 Having HTTPSTB clearly define the public suffix + 1 scope for bro= wsers > while still allowing for cases like that OAuth one might be useful. > > Perhaps the latter (different key scoping for OAuth) should be part of a > separate OAUTHTB spec. > > > > Cheers, > > > > Andrei > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Br= ian > Campbell > *Sent:* Friday, May 13, 2016 2:15 PM > *To:* IETF Tokbind WG > *Subject:* [Unbearable] HTTPSTB: discuss scoping of token binding keys > earlier in the document > > > > I put in https://github.com/TokenBinding/Internet-Drafts/issues/33 but am > sending this message to the list too as some/many WG participants don't > actively monitor GitHub (as suggested by Andrei). Text of the issue is > copied below. Thanks! > > > > > As of draft-ietf-tokbind-https-03 in the Privacy Considerations Section > 5.1 Scoping of Token Binding Keys > is > the first real mention that token binding keys/ids should be scoped to > public suffix + 1. Though the first sentence in 3.1 hints at it, it's not > defined until later. > > The scope of where TB keys are sent is a pretty fundamental part of > HTTPSTB and, as such, I believe should be defined/discussed in Section 2 > along with the Sec-Token-Binding header that the scoping applies to. The > Privacy Considerations are still good considerations but then could refer > back to the scoping definition in Sec 2 rather than being the definition. > > Public suffix + 1 makes sense as the scope for browser user agents but is > maybe overly restrictive/prescriptive for some other HTTPS cases. OAuth > access tokens come to mind, although it's still up in the air at this poi= nt > how exactly OAuth will leverage TB, but there's potently a case for an > OAuth client acting as an HTTPS client to want to have an token bound > access token that can be used at multiple resource servers, which might b= e > on different hosts/domains. The privacy concerns that arise from that > situation are already there because the access token is correlatable so > allowing the scope of the TB key to do the same doesn't make things any > worse. It's the same from a privacy perspective, just more secure. Having > HTTPSTB clearly define the public suffix + 1 scope for browsers while sti= ll > allowing for cases like that OAuth one might be useful. > > > --001a11475b2246b15f0532c0437d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed, HTTPSTB shouldn't define any scoping for the h= ypothetical OAUTHTB. But OAuth also uses HTTPS so having the language in HT= TPSTB not preclude what OAuth might do could be useful.

On Fri, May 13, 2016 at 3:= 43 PM, Andrei Popov <Andrei.Popov@microsoft.com> wr= ote:

Hi Brian,

=C2=A0

=C3=98=C2= =A0 Having HTTPSTB clearly define = the public suffix + 1 scope for browsers while still allowing for cases lik= e that OAuth one might be useful.

Perhaps the latter (different key sco= ping for OAuth) should be part of a separate OAUTHTB spec.

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ie= tf.org] On Behalf Of Brian Campbell
Sent: Friday, May 13, 2016 2:15 PM
To: IETF Tokbind WG <unbearable@ietf.org>
Subject: [Unbearable] HTTPSTB: discuss scoping of token binding keys= earlier in the document

=C2=A0

I put in https://github.com/TokenBinding/Internet-Drafts/issues/33 but am sendin= g this message to the list too as some/many WG participants don't activ= ely monitor GitHub (as suggested by Andrei). Text of the issue is copied be= low. Thanks!




As of draft-ietf-tokbind-https-03 in the Privacy Considerations= =C2=A0Section 5.1 Scoping of Token Binding Keys is the first real mention tha= t token binding keys/ids should be scoped to public suffix + 1. Though the = first sentence in 3.1 hints at it, it's not defined until later.=

The scope of where TB keys are sent is a pretty fundamenta= l part of HTTPSTB and, as such, I believe should be defined/discussed in Se= ction 2 along with the Sec-Token-Binding header that the scoping applies to. The Privacy Considerations are still good con= siderations but then could refer back to the scoping definition in Sec 2 ra= ther than being the definition.

Public suffix + 1 makes sense as the scope for browser use= r agents but is maybe overly restrictive/prescriptive for some other HTTPS = cases. OAuth access tokens come to mind, although it's still up in the air at this point how exactly OAuth will leverage= TB, but there's potently a case for an OAuth client acting as an HTTPS= client to want to have an token bound access token that can be used at mul= tiple resource servers, which might be on different hosts/domains. The privacy concerns that arise from that situati= on are already there because the access token is correlatable so allowing t= he scope of the TB key to do the same doesn't make things any worse. It= 's the same from a privacy perspective, just more secure. Having HTTPSTB clearly define the public suffix + 1 scop= e for browsers while still allowing for cases like that OAuth one might be = useful.

=C2=A0


--001a11475b2246b15f0532c0437d-- From nobody Mon May 16 11:06:22 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879B612D163 for ; Mon, 16 May 2016 11:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUv-kDSYCeUK for ; Mon, 16 May 2016 11:06:18 -0700 (PDT) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1A512D500 for ; Mon, 16 May 2016 11:06:18 -0700 (PDT) Received: by mail-ig0-x22c.google.com with SMTP id s8so43924831ign.0 for ; Mon, 16 May 2016 11:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=CYNrhhYxD1W4v7iu0JInBB/8ym9ExMh3c+cbSsmELB4=; b=kAubg4+y4RKIysMVRSrDXFB2YOjzVBdsQgU+nh2K5bGFl9FLYc7sUL9/6S3Sf+91WG gmGCS1fYvNLXvAF9wWRoxcdJ8t0JEcwkkiQxOryuv8Muw9M63lnLMG2QbP1dzreR5NUS aGHgZvOeFwqgU3fsjLu7Y6LDehrSOy9lbtiIc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=CYNrhhYxD1W4v7iu0JInBB/8ym9ExMh3c+cbSsmELB4=; b=ScCwD757DN0Hf4tS5WdCJcA9+ZwXZ2yRWEIMEVHScMzT+bB/QBkp80o678tJvIzUvD PJ54ccdnPLnRMXUdurm1Dc8ZHntaZqupvuREgK8eTaew8hSO4h73QXllAAN+KRRbvSBn whOt1QCWJJNouTLKhanOZFxhE1RccyJKxk20WLgcvGgv+CTIdKEiczvF5PRrc2qg4Xje +zsG7L0mvSfufkQpV/bq4nCNVRIblf6Q3W67YMkcjyfC7NEtH2+c9TIZqZgS1fsuRfVu nj0duZKWXU3kc8Nf9B0M+Hxxm16OvMVPKOQTx5UV5LtZrzqlmYlzUcE9evE2DMgAhORu T89Q== X-Gm-Message-State: AOPr4FVhxvIRsaBgfq5RLzpg7Dkwpaq0n4YIT6D+OrKqguJFOjz3llhLP7gWk2+yyO0bwPoWaAd5O9FuHRWEpDUQ X-Received: by 10.50.67.113 with SMTP id m17mr10107487igt.62.1463421978166; Mon, 16 May 2016 11:06:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.105.129 with HTTP; Mon, 16 May 2016 11:05:48 -0700 (PDT) From: Brian Campbell Date: Mon, 16 May 2016 12:05:48 -0600 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary=047d7bd753ea2a66a00532f97b93 Archived-At: Subject: [Unbearable] HTTPSTB: more explicitly state that referred token binding only sent on redirect request (issue #34) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 16 May 2016 18:06:20 -0000 --047d7bd753ea2a66a00532f97b93 Content-Type: text/plain; charset=UTF-8 copied content from https://github.com/TokenBinding/Internet-Drafts/issues/34 below On my initial reading of draft-ietf-tokbind-https-03 it was not immediately clear to me that the referred token binding was to be sent to the Token Provider only on the request resulting from the 30x redirect from the the Token Consumer with the Include-Referer-Token-Binding-ID and not on any subsequent requests to the Token Provider. I asked about this in BA, though the minutes don't fully capture it , and it was explained (thank you Andrei et al) that the referred token binding is only sent once on the redirect request and not again. After having it explained and on reading it again, the 3rd paragraph of section 3.3 does say that the referred token binding is sent "on the redirect request." So the behavior is stated in the text but I do believe the draft would be more clear if it explicitly stated that the referred token binding is sent only on the request resulting from the redirect and not on any subsequent requests to the Token Provider. Thanks! --047d7bd753ea2a66a00532f97b93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
copied content from https://github.com/TokenBinding/Internet-Dr= afts/issues/34 below

On my initial reading of draft-ietf-tokbind-https-03 it was not immediate= ly clear to me that the referred token binding was to be sent to the Token = Provider only on the request resulting from the 30x redirect from the the T= oken Consumer with the Include-Referer-Token-Binding-ID and not on any subs= equent requests to the Token Provider. I asked about this in BA,=C2=A0though the minutes don't fully capture it, and it w= as explained (thank you Andrei et al) that the referred token binding is on= ly sent once on the redirect request and not again.

After having it explained and on reading it again, the 3rd pa= ragraph of section 3.3 does say that the referred token binding is sent &qu= ot;on the redirect request." So the behavior is stated in the text but= I do believe the draft would be more clear if it explicitly stated that th= e referred token binding is sent only on the request resulting from the red= irect and not on any subsequent requests to the Token Provider.

Thanks!


--047d7bd753ea2a66a00532f97b93-- From nobody Mon May 16 12:01:05 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191E612D61D for ; Mon, 9 May 2016 13:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.909 X-Spam-Level: X-Spam-Status: No, score=-5.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_16=1.092, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4UOGqd7f4-z for ; Mon, 9 May 2016 13:33:39 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext2.iad.github.net [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8AF12D12A for ; Mon, 9 May 2016 13:33:39 -0700 (PDT) Date: Mon, 09 May 2016 13:33:37 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1462826017; bh=Chfsp7FJ0fQ+C35cEgR97gh6L24Fvg3hmh5v6stTj48=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=QE5eMDY8PyJ90Z/BypAtHaV52bqa7Y/RL8GY2o73XqPy3lSUXPxLRSrlvXlGY485w qh/M8pOZcrTTl+xeo3JhjyR2se19DMDIoAPIJ48SpSx8KOKtVMhjiZA49rW3YJHJfY 4F0P2Ud6FdvhUFXHybMcG46j24G6xTtCB88zJoiI= From: Brian Campbell To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_5730f421cc4ad_2c533fd13ad212c0383355"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: b---c X-GitHub-Recipient: unbearable-ML X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Mon, 16 May 2016 12:01:04 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: make it URL-safe base64 (#27) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Reply-To: TokenBinding/Internet-Drafts 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, 09 May 2016 20:33:41 -0000 ----==_mimepart_5730f421cc4ad_2c533fd13ad212c0383355 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Current text in section 2 has "web-safe Base64-encoding" which many people will likely understand but is probably a bit too colloquial for an RFC. I might suggest something like the following, which borrows languge from existing RFCs that use a URL-safe base64 encoding. > The header field name is "Sec-Token-Binding" and its value, EncodedTokenBindingMessage, is a web-safe Base64-encoding of the TokenBindingMessage defined in the TokenBindingProtocol [TBPROTO] using the URL- and filename-safe character set defined in Section 5 of RFC 4648 [RFC4648], with all trailing pad characters '=' omitted and without the inclusion of any line breaks, whitespace, or other additional characters. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/TokenBinding/Internet-Drafts/issues/27#issuecomment-217980935 ----==_mimepart_5730f421cc4ad_2c533fd13ad212c0383355 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Current text in section 2 has "web-safe Base64-encoding" which many people will likely understand but is probably a bit too colloquial for an RFC. I might suggest something like the following, which borrows languge from existing RFCs that use a URL-safe base64 encoding.

The header field name is "Sec-Token-Binding" and its value, EncodedTokenBindingMessage, is a web-safe Base64-encoding of the TokenBindingMessage defined in the TokenBindingProtocol [TBPROTO] using the URL- and filename-safe character set defined in Section 5 of RFC 4648 [RFC4648], with all trailing pad characters '=' omitted and without the inclusion of any line breaks, whitespace, or other additional characters.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

----==_mimepart_5730f421cc4ad_2c533fd13ad212c0383355-- From nobody Mon May 16 12:01:31 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D9012D0E5 for ; Fri, 13 May 2016 15:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.455 X-Spam-Level: X-Spam-Status: No, score=-5.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBr1TcApQHvu for ; Fri, 13 May 2016 15:01:13 -0700 (PDT) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext7.iad.github.net [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543EF12D09D for ; Fri, 13 May 2016 15:01:13 -0700 (PDT) Date: Fri, 13 May 2016 15:01:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1463176872; bh=iCoT0AGASxhsAHXBwsbLh2nmDb+ZS9SDrtJsfK6GtA8=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=YiNvZGlwkk+OmLcD3e+zgTcC2zyens2YShq7HF6m2KBKyE9/pOPrYm6f/iMS1Kgot +SW37H8W7AKCXhJJUYeE5RsxWXc+9m+RjoxZNGg3nJ5haLAPkFqVZ0M7RRbTmvOsp5 0NcbydRPrDSGTzFQyXaBgRuog8cOQF00TiVh1m64= From: Brian Campbell To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57364ea84b439_4c233fae4700929c727e6"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: b---c X-GitHub-Recipient: unbearable-ML X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Mon, 16 May 2016 12:01:30 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] Include-Referer-Token-Binding-ID header meaningful beyond HTTP 302/1? (#10) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Reply-To: TokenBinding/Internet-Drafts 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, 13 May 2016 22:01:15 -0000 ----==_mimepart_57364ea84b439_4c233fae4700929c727e6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit At the meeting in Buenos Aires there seemed to be pretty wide consensus that the Include-Referer-Token-Binding-ID only having meaning for 30x status codes was sufficient for the scope of the draft-ietf-tokbind-https document. And that fetch() or other things that might use TB could define their own semantics for it if/when necessary. As of draft -03 the Include-Referer-Token-Binding-ID header is defined to have meaning for 301, 302, 303, 307 or 308. So transmitting an authentication request to the token provider/IDP via the HTTP POST method could be achieved by the token consumer/RP sending an auto-submitting form post with the request back to itself and responding to that with a 307 directing the browser to resubmit the POST data to the token provider/IDP. It's a little ugly but will work with only the functionally provided by draft-ietf-tokbind-https. So with all that said, I think this issue can be closed now. --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/TokenBinding/Internet-Drafts/issues/10#issuecomment-219170018 ----==_mimepart_57364ea84b439_4c233fae4700929c727e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

At the meeting in Buenos Aires there seemed to be pretty wide consensus that the Include-Referer-Token-Binding-ID only having meaning for 30x status codes was sufficient for the scope of the draft-ietf-tokbind-https document. And that fetch() or other things that might use TB could define their own semantics for it if/when necessary.

As of draft -03 the Include-Referer-Token-Binding-ID header is defined to have meaning for 301, 302, 303, 307 or 308. So transmitting an authentication request to the token provider/IDP via the HTTP POST method could be achieved by the token consumer/RP sending an auto-submitting form post with the request back to itself and responding to that with a 307 directing the browser to resubmit the POST data to the token provider/IDP. It's a little ugly but will work with only the functionally provided by draft-ietf-tokbind-https.

So with all that said, I think this issue can be closed now.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

----==_mimepart_57364ea84b439_4c233fae4700929c727e6-- From nobody Mon May 16 12:03:20 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C222B12D8C6 for ; Mon, 16 May 2016 10:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.455 X-Spam-Level: X-Spam-Status: No, score=-5.455 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7SFejP3CgHl for ; Mon, 16 May 2016 10:59:33 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext6.iad.github.net [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E3AE12D8C5 for ; Mon, 16 May 2016 10:59:33 -0700 (PDT) Date: Mon, 16 May 2016 10:59:31 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1463421571; bh=n5KAD/uhIUIqIjimArg2n43q2fIeuSSgplktbez8wNE=; h=From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=lFjFAj98GFdLRgPDF1YlZCPGSOL7RGQ+2mlUNvqJfBdyBYZbqgUMjVS25vkj4CC/R tu9KdJ9mMLz6MXg1qu2aFD8viS/pYvsHTdoIaCB8jCIAubXdaXfVHvVHmI2s0RbPCV +3isDg2W57h4Zv2dragzeRoLtvTGdyTlMFGcVBck= From: Brian Campbell To: TokenBinding/Internet-Drafts Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_573a0a83d1128_1d7f3fcf9730f2b892469"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: b---c X-GitHub-Recipient: unbearable-ML X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Mon, 16 May 2016 12:03:18 -0700 Subject: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: more explicitly state that referred token binding only sent on redirect request (#34) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Reply-To: TokenBinding/Internet-Drafts 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, 16 May 2016 17:59:35 -0000 ----==_mimepart_573a0a83d1128_1d7f3fcf9730f2b892469 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On my initial reading of draft-ietf-tokbind-https-03 it was not immediately clear to me that the referred token binding was to be sent to the Token Provider only on the request resulting from the 30x redirect from the the Token Consumer with the Include-Referer-Token-Binding-ID and not on any subsequent requests to the Token Provider. I asked about this in BA, [though the minutes don't fully capture it](https://datatracker.ietf.org/doc/minutes-95-tokbind/), and it was explained (thank you Andrei et al) that the referred token binding is only sent once on the redirect request and not again. After having it explained and on reading it again, the 3rd paragraph of section 3.3 does say that the referred token binding is sent "on the redirect request." So the behavior is stated in the text but I do believe the draft would be more clear if it explicitly stated that the referred token binding is sent only on the request resulting from the redirect and not on any subsequent requests to the Token Provider. Thanks! --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/TokenBinding/Internet-Drafts/issues/34 ----==_mimepart_573a0a83d1128_1d7f3fcf9730f2b892469 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

On my initial reading of draft-ietf-tokbind-https-03 it was not immediately clear to me that the referred token binding was to be sent to the Token Provider only on the request resulting from the 30x redirect from the the Token Consumer with the Include-Referer-Token-Binding-ID and not on any subsequent requests to the Token Provider. I asked about this in BA, though the minutes don't fully capture it, and it was explained (thank you Andrei et al) that the referred token binding is only sent once on the redirect request and not again.

After having it explained and on reading it again, the 3rd paragraph of section 3.3 does say that the referred token binding is sent "on the redirect request." So the behavior is stated in the text but I do believe the draft would be more clear if it explicitly stated that the referred token binding is sent only on the request resulting from the redirect and not on any subsequent requests to the Token Provider.

Thanks!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

----==_mimepart_573a0a83d1128_1d7f3fcf9730f2b892469-- From nobody Mon May 16 13:23:03 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9750012DA2B for ; Mon, 16 May 2016 13:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYXsBQRQd4VF for ; Mon, 16 May 2016 13:22:58 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6BFF12D66F for ; Mon, 16 May 2016 13:22:58 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id d62so224604795iof.2 for ; Mon, 16 May 2016 13:22:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=magK/JbtPzHVYC/fhAFQpIWPUvOx25apz6a1grkDfm8=; b=Lggsew7LnlpGRQW3/kHqk9+OzWO+XF4Jp6ykfmPRqR6TlZDBd3wl8/7RBMZ7V2p9fH 9TNIf/QNC1oCfFAdvzoxvPraoXE+Nrfy7YzADdeDmLNdqU5YoovSOttdupRWCyG70cym EWcn/tOT+7EiSWyz2MDFSmoaQMj7P29mdbRNQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=magK/JbtPzHVYC/fhAFQpIWPUvOx25apz6a1grkDfm8=; b=JpAwBLdPxzRRUvzyYzESf1B25sDHkQzh0wM5af7qMLtU5LRLMA+0ERiR0iktx9Kglo 0Ix2rmaN21j2bv6hWFhdI6YfLNiEpy4PBwpodg+eOesxKH8pfseYUPQ1+4/pKVNu423J PupNp4BO/0WSRjKuKOmew6E4hi9716rycuHieW64N7ieVqqmpBPv97qBwMk+Dkpr4OXm st1NOzJDtP17Xz4Bz17Ifzw+cRbq03l1zmgAoBrBCTxZVfHi38wzcXPAz4EVkXkCemUy QrBvo+v4RI7zlS/DcTs9Q6bFW4cB8HvkP7vhFP+nQxmNPbzRNT5oG11mIHEblcEXwxXX LTKA== X-Gm-Message-State: AOPr4FX2jw+kpCwHK44lQeq+WLjQJ2qAAkWM+bhRHAjMI29+TgxRMLhjp0q4MLyGCpYB7pAHvNh+lV0+FuhkVo5J X-Received: by 10.36.115.76 with SMTP id y73mr10619371itb.63.1463430177714; Mon, 16 May 2016 13:22:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.105.129 with HTTP; Mon, 16 May 2016 13:22:28 -0700 (PDT) From: Brian Campbell Date: Mon, 16 May 2016 14:22:28 -0600 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary=001a11439870e59fad0532fb6395 Archived-At: Subject: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 16 May 2016 20:23:00 -0000 --001a11439870e59fad0532fb6395 Content-Type: text/plain; charset=UTF-8 It seems like github recently started sending some notifications to the WG list but it's not clear how reliable that is so I'm gonna double post anyway. The text from https://github.com/TokenBinding/Internet-Drafts/issues/35 follows. As mentioned at IETF 95 I propose that the referred Token Binding be sent via a separate header (say Sec-Referred-Token-Binding) rather than as part of the Sec-Token-Binding header. At the HTTP layer separate headers will make it much more clear what is going on. Just looking for the presence or absence of the Sec-Referred-Token-Binding header will indicate if a referred TB was sent, which is very easy. Rather than having to decode the Sec-Token-Binding header value and process the binary content, which is possible but much more involved. Having a separate header for the referred TB allows the client/user agent to always send the provided TB via Sec-Token-Binding and not have to build a new TB message on the redirect request and then go back to the provided TB on subsequent requests. Also not having the value of Sec-Token-Binding change (other then a new TLS session with new EKM) should make it nicely efficient with HTTP/2 header compression. I also believe it will be easier to covey the concepts in the text of the spec. Talking about when the Sec-Referred-Token-Binding is sent or not sent rather than talking about when the referred TB is included as part of the TB message that is sent with Sec-Token-Binding seems much more straightforward. Anecdotally, there's been some discussion about using TB in OpenID Connect and and in talking about it people often say "the referred token binding header", which isn't accurate relative to HTTPSTB-03 but belies the fact that federation folks already think about it as separate header. And I think that's a natural way think about it so it's not terribly surprising. I won't name any names but one of the chairs of the WG is among those who said "the referred token binding header." I realize this is not an insignificant change but I strongly believe it'd be a simplification and improvement for HTTPS TB. There's not yet (that I'm aware of anyway) any profiling of TB for federation like protocols such OpenID Connect, OAuth or SAML so this would be an opportune time to change how the referred Token Binding is conveyed. --001a11439870e59fad0532fb6395 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It seems like github recently started sending some notific= ations to the WG list but it's not clear how reliable that is so I'= m gonna double post anyway. The text from https://github.com/TokenBinding/Intern= et-Drafts/issues/35 follows.

As mentioned=C2=A0at IETF 95=C2=A0I propose that the referred Token Binding be sent via a = separate header (say Sec-Referred-Token-Binding) rather than as part of the= Sec-Token-Binding header.

At the HTTP= layer separate headers will make it much more clear what is going on. Just= looking for the presence or absence of the Sec-Referred-Token-Binding head= er will indicate if a referred TB was sent, which is very easy. Rather than= having to decode the Sec-Token-Binding header value and process the binary= content, which is possible but much more involved.

Having a separate header for the referred TB allows the clien= t/user agent to always send the provided TB via Sec-Token-Binding and not h= ave to build a new TB message on the redirect request and then go back to t= he provided TB on subsequent requests. Also not having the value of Sec-Tok= en-Binding change (other then a new TLS session with new EKM) should make i= t nicely efficient with HTTP/2 header compression.

I also believe it will be easier to covey the concepts in the = text of the spec. Talking about when the Sec-Referred-Token-Binding is sent= or not sent rather than talking about when the referred TB is included as = part of the TB message that is sent with Sec-Token-Binding seems much more = straightforward.

Anecdotally, there= 9;s been some discussion about using TB in OpenID Connect and and in talkin= g about it people often say "the referred token binding header", = which isn't accurate relative to HTTPSTB-03 but belies the fact that fe= deration folks already think about it as separate header. And I think that&= #39;s a natural way think about it so it's not terribly surprising. I w= on't name any names but one of the chairs of the WG is among those who = said "the referred token binding header."

I realize this is not an insignificant change but I = strongly believe it'd be a simplification and improvement for HTTPS TB.= There's not yet (that I'm aware of anyway) any profiling of TB for= federation like protocols such OpenID Connect, OAuth or SAML so this would= be an opportune time to change how the referred Token Binding is conveyed.=


--001a11439870e59fad0532fb6395-- From nobody Tue May 17 10:21:37 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CCAA12D841 for ; Tue, 17 May 2016 10:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVQKzpCc-14H for ; Tue, 17 May 2016 10:21:31 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0128.outbound.protection.outlook.com [65.55.169.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A2C712D1DB for ; Tue, 17 May 2016 10:21:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=llPkyjpfZmzaR1IJiE1BZkeRkwWHvwn+FPM6JE1Jeco=; b=jqCngasarBnOnNM8m/xVB0gsBEWxvn67SFLIF4ufYEU1OJK0GFBpNVOo4eQmsZnykeyWzHeCfJtu+oIDM6L/3G0ZC03ZptXRb4YIgrzK/Obahs/StlayXVwnIC6Sq7tJjHGGQAY68cNMPUN2jDbOxf7wNVRr/2ld5sZ529ElrBg= Received: from BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) by BN3PR03MB1446.namprd03.prod.outlook.com (10.163.34.29) with Microsoft SMTP Server (TLS) id 15.1.497.12; Tue, 17 May 2016 17:21:29 +0000 Received: from BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) by BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) with mapi id 15.01.0497.019; Tue, 17 May 2016 17:21:29 +0000 From: Andrei Popov To: Brian Campbell , IETF Tokbind WG Thread-Topic: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) Thread-Index: AQHRr7DCodP2ByS3Qk+hp2frsgjWrZ+8RLeQ Date: Tue, 17 May 2016 17:21:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:f::1d2] x-ms-office365-filtering-correlation-id: 8a058043-4a97-4781-4821-08d37e77af37 x-microsoft-exchange-diagnostics: 1; BN3PR03MB1446; 5:L+PUoyIQ7oCmvOW5ohrmqG0GK853bWodAnCnaOxFbEqSryGkbMVRhSklMST9CYQVZdmlChWPc5H4xlQN2ksh5JuAS9pive9end0DWIF/jX0VFpsIT6FteWxWpgWEpsErhyLYH864Yo5ctW3kkvpE0w==; 24:iyqUNaDFVzIPJ7YGgMrIVn307EFyoO8kJ0zHO/0Gf0sQgYebD8WxoiXsS7PCCnSjNkiJwnqlncrjGEd+Lng2f+QVBxpPYSFH+D2AVtZHobI=; 7:G0lX9JJe9eiHVPsfN/c/RD2GECHb285LDmk3EfKRFkUat8nrR2BsMhkGuziL+q5JYHLQ3MzVAuopOl7QSXgdBZp3m1LPH+mzfYBrj3glcci5yEpJJDGhPNcXYeoRELHqBQkImPgUVoW1cpMgri1i1OAij8RKgg/o63fRc132qc4VD+wEQtfLAZ57YZzTFkBGr2WA7KcchAQE3lUr4slBaQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN3PR03MB1446; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1446; x-forefront-prvs: 0945B0CC72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(51444003)(377454003)(5383002)(10290500002)(8936002)(5005710100001)(5003600100002)(10400500002)(2950100001)(8990500004)(5008740100001)(106116001)(92566002)(19580395003)(19580405001)(10090500001)(19300405004)(586003)(86362001)(81166006)(11100500001)(16236675004)(9686002)(1220700001)(9326002)(2906002)(5002640100001)(19617315012)(77096005)(87936001)(122556002)(19625215002)(74316001)(15975445007)(50986999)(54356999)(76176999)(5004730100002)(76576001)(86612001)(33656002)(189998001)(102836003)(6116002)(2900100001)(5001770100001)(790700001)(107886002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1446; H:BN3PR03MB1445.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB144522E21E8685A853DAB17E8C480BN3PR03MB1445namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2016 17:21:29.0840 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1446 Archived-At: Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 17:21:34 -0000 --_000_BN3PR03MB144522E21E8685A853DAB17E8C480BN3PR03MB1445namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNClRoZSBjdXJyZW50IGZvcm1hdCwgd2hlcmUgYWxsIFRva2VuIEJpbmRpbmdz IGFyZSBjb250YWluZWQgaW4gb25lIFRva2VuIEJpbmRpbmcgbWVzc2FnZSwgcHJvdmlkZXMgdXNl ZnVsIGVuY2Fwc3VsYXRpb24uIFRoZSBIVFRQIGxheWVyIGRvZXMgbm90IG5lZWQgdG8ga25vdyB0 aGUgZGV0YWlscyBvZiB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCwgd2hpY2ggY2FuIGJlIGlt cGxlbWVudGVkIGluIGEgc2VwYXJhdGUgbGlicmFyeS4gSWYgdG9tb3Jyb3cgd2UgZGVmaW5lIGEg bmV3IFRva2VuIEJpbmRpbmcgdHlwZSwgYW4gZXhpc3RpbmcgSFRUUCBpbXBsZW1lbnRhdGlvbiBj YW4gY2FycnkgaXQgaW4gdGhlIFNlYy1Ub2tlbi1CaW5kaW5nIGhlYWRlciB3aXRob3V0IG1vZGlm aWNhdGlvbi4gT25seSB0aGUgVG9rZW4gQmluZGluZyBsaWJyYXJ5IHdvdWxkIG5lZWQgdG8gYmUg dXBkYXRlZC4NCg0Kw5ggIEF0IHRoZSBIVFRQIGxheWVyIHNlcGFyYXRlIGhlYWRlcnMgd2lsbCBt YWtlIGl0IG11Y2ggbW9yZSBjbGVhciB3aGF0IGlzIGdvaW5nIG9uLiBKdXN0IGxvb2tpbmcgZm9y IHRoZSBwcmVzZW5jZSBvciBhYnNlbmNlIG9mIHRoZSBTZWMtUmVmZXJyZWQtVG9rZW4tQmluZGlu ZyBoZWFkZXIgd2lsbCBpbmRpY2F0ZSBpZiBhIHJlZmVycmVkIFRCIHdhcyBzZW50LCB3aGljaCBp cyB2ZXJ5IGVhc3kuDQpUaGlzIGNhbiBiZSBzb2x2ZWQgYnkgaW5jbHVkaW5nIGEgVEIgcGFyc2Vy IGluIHRoZSBwcm90b2NvbCBhbmFseXplci4gV2hpY2ggd291bGQgYWxzbyBwcm92aWRlIGZ1cnRo ZXIgdXNlZnVsIGluc2lnaHRzIGludG8gVEIga2V5IHBhcmFtZXRlcnMsIGV0Yy4NCg0KDQrDmCAg SGF2aW5nIGEgc2VwYXJhdGUgaGVhZGVyIGZvciB0aGUgcmVmZXJyZWQgVEIgYWxsb3dzIHRoZSBj bGllbnQvdXNlciBhZ2VudCB0byBhbHdheXMgc2VuZCB0aGUgcHJvdmlkZWQgVEIgdmlhIFNlYy1U b2tlbi1CaW5kaW5nIGFuZCBub3QgaGF2ZSB0byBidWlsZCBhIG5ldyBUQiBtZXNzYWdlIG9uIHRo ZSByZWRpcmVjdCByZXF1ZXN0IGFuZCB0aGVuIGdvIGJhY2sgdG8gdGhlIHByb3ZpZGVkIFRCIG9u IHN1YnNlcXVlbnQgcmVxdWVzdHMuDQpJIGRvbuKAmXQgdGhpbmsgdGhlcmXigJlzIGFuIG9wdGlt aXphdGlvbiBhbiBIVFRQIHN0YWNrIGNhbiBkbyBXUlQgYnVpbGRpbmcgVEIgbWVzc2FnZXMgdGhh dCBhIFRva2VuIEJpbmRpbmcgbGlicmFyeSBjYW7igJl0LCBhbmQgdGhlIFRva2VuIEJpbmRpbmcg bGlicmFyeSBpcyB3aGVyZSBzdWNoIG9wdGltaXphdGlvbnMgYmVsb25nLg0KDQpGb3IgdGhlIGFi b3ZlIHJlYXNvbnMsIEkgd291bGQgcHJlZmVyIHRvIGtlZXAgYWxsIFRva2VuIEJpbmRpbmdzIGlu IG9uZSBUb2tlbiBCaW5kaW5nIG1lc3NhZ2UuDQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206 IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDogTW9uZGF5LCBNYXkgMTYsIDIwMTYgMToyMiBQTQ0K VG86IElFVEYgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtVbmJl YXJhYmxlXSBIVFRQU1RCOiBkaXN0aW5jdCBoZWFkZXIgZm9yIHRoZSByZWZlcnJlZCBUb2tlbiBC aW5kaW5nIChpc3N1ZSAjMzUpDQoNCkl0IHNlZW1zIGxpa2UgZ2l0aHViIHJlY2VudGx5IHN0YXJ0 ZWQgc2VuZGluZyBzb21lIG5vdGlmaWNhdGlvbnMgdG8gdGhlIFdHIGxpc3QgYnV0IGl0J3Mgbm90 IGNsZWFyIGhvdyByZWxpYWJsZSB0aGF0IGlzIHNvIEknbSBnb25uYSBkb3VibGUgcG9zdCBhbnl3 YXkuIFRoZSB0ZXh0IGZyb20gaHR0cHM6Ly9naXRodWIuY29tL1Rva2VuQmluZGluZy9JbnRlcm5l dC1EcmFmdHMvaXNzdWVzLzM1IGZvbGxvd3MuDQoNCg0KDQpBcyBtZW50aW9uZWQgYXQgSUVURiA5 NTxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9taW51dGVzLTk1LXRva2JpbmQvPiBJ IHByb3Bvc2UgdGhhdCB0aGUgcmVmZXJyZWQgVG9rZW4gQmluZGluZyBiZSBzZW50IHZpYSBhIHNl cGFyYXRlIGhlYWRlciAoc2F5IFNlYy1SZWZlcnJlZC1Ub2tlbi1CaW5kaW5nKSByYXRoZXIgdGhh biBhcyBwYXJ0IG9mIHRoZSBTZWMtVG9rZW4tQmluZGluZyBoZWFkZXIuDQoNCkF0IHRoZSBIVFRQ IGxheWVyIHNlcGFyYXRlIGhlYWRlcnMgd2lsbCBtYWtlIGl0IG11Y2ggbW9yZSBjbGVhciB3aGF0 IGlzIGdvaW5nIG9uLiBKdXN0IGxvb2tpbmcgZm9yIHRoZSBwcmVzZW5jZSBvciBhYnNlbmNlIG9m IHRoZSBTZWMtUmVmZXJyZWQtVG9rZW4tQmluZGluZyBoZWFkZXIgd2lsbCBpbmRpY2F0ZSBpZiBh IHJlZmVycmVkIFRCIHdhcyBzZW50LCB3aGljaCBpcyB2ZXJ5IGVhc3kuIFJhdGhlciB0aGFuIGhh dmluZyB0byBkZWNvZGUgdGhlIFNlYy1Ub2tlbi1CaW5kaW5nIGhlYWRlciB2YWx1ZSBhbmQgcHJv Y2VzcyB0aGUgYmluYXJ5IGNvbnRlbnQsIHdoaWNoIGlzIHBvc3NpYmxlIGJ1dCBtdWNoIG1vcmUg aW52b2x2ZWQuDQoNCkhhdmluZyBhIHNlcGFyYXRlIGhlYWRlciBmb3IgdGhlIHJlZmVycmVkIFRC IGFsbG93cyB0aGUgY2xpZW50L3VzZXIgYWdlbnQgdG8gYWx3YXlzIHNlbmQgdGhlIHByb3ZpZGVk IFRCIHZpYSBTZWMtVG9rZW4tQmluZGluZyBhbmQgbm90IGhhdmUgdG8gYnVpbGQgYSBuZXcgVEIg bWVzc2FnZSBvbiB0aGUgcmVkaXJlY3QgcmVxdWVzdCBhbmQgdGhlbiBnbyBiYWNrIHRvIHRoZSBw cm92aWRlZCBUQiBvbiBzdWJzZXF1ZW50IHJlcXVlc3RzLiBBbHNvIG5vdCBoYXZpbmcgdGhlIHZh bHVlIG9mIFNlYy1Ub2tlbi1CaW5kaW5nIGNoYW5nZSAob3RoZXIgdGhlbiBhIG5ldyBUTFMgc2Vz c2lvbiB3aXRoIG5ldyBFS00pIHNob3VsZCBtYWtlIGl0IG5pY2VseSBlZmZpY2llbnQgd2l0aCBI VFRQLzIgaGVhZGVyIGNvbXByZXNzaW9uLg0KDQpJIGFsc28gYmVsaWV2ZSBpdCB3aWxsIGJlIGVh c2llciB0byBjb3ZleSB0aGUgY29uY2VwdHMgaW4gdGhlIHRleHQgb2YgdGhlIHNwZWMuIFRhbGtp bmcgYWJvdXQgd2hlbiB0aGUgU2VjLVJlZmVycmVkLVRva2VuLUJpbmRpbmcgaXMgc2VudCBvciBu b3Qgc2VudCByYXRoZXIgdGhhbiB0YWxraW5nIGFib3V0IHdoZW4gdGhlIHJlZmVycmVkIFRCIGlz IGluY2x1ZGVkIGFzIHBhcnQgb2YgdGhlIFRCIG1lc3NhZ2UgdGhhdCBpcyBzZW50IHdpdGggU2Vj LVRva2VuLUJpbmRpbmcgc2VlbXMgbXVjaCBtb3JlIHN0cmFpZ2h0Zm9yd2FyZC4NCg0KQW5lY2Rv dGFsbHksIHRoZXJlJ3MgYmVlbiBzb21lIGRpc2N1c3Npb24gYWJvdXQgdXNpbmcgVEIgaW4gT3Bl bklEIENvbm5lY3QgYW5kIGFuZCBpbiB0YWxraW5nIGFib3V0IGl0IHBlb3BsZSBvZnRlbiBzYXkg InRoZSByZWZlcnJlZCB0b2tlbiBiaW5kaW5nIGhlYWRlciIsIHdoaWNoIGlzbid0IGFjY3VyYXRl IHJlbGF0aXZlIHRvIEhUVFBTVEItMDMgYnV0IGJlbGllcyB0aGUgZmFjdCB0aGF0IGZlZGVyYXRp b24gZm9sa3MgYWxyZWFkeSB0aGluayBhYm91dCBpdCBhcyBzZXBhcmF0ZSBoZWFkZXIuIEFuZCBJ IHRoaW5rIHRoYXQncyBhIG5hdHVyYWwgd2F5IHRoaW5rIGFib3V0IGl0IHNvIGl0J3Mgbm90IHRl cnJpYmx5IHN1cnByaXNpbmcuIEkgd29uJ3QgbmFtZSBhbnkgbmFtZXMgYnV0IG9uZSBvZiB0aGUg Y2hhaXJzIG9mIHRoZSBXRyBpcyBhbW9uZyB0aG9zZSB3aG8gc2FpZCAidGhlIHJlZmVycmVkIHRv a2VuIGJpbmRpbmcgaGVhZGVyLiINCg0KSSByZWFsaXplIHRoaXMgaXMgbm90IGFuIGluc2lnbmlm aWNhbnQgY2hhbmdlIGJ1dCBJIHN0cm9uZ2x5IGJlbGlldmUgaXQnZCBiZSBhIHNpbXBsaWZpY2F0 aW9uIGFuZCBpbXByb3ZlbWVudCBmb3IgSFRUUFMgVEIuIFRoZXJlJ3Mgbm90IHlldCAodGhhdCBJ J20gYXdhcmUgb2YgYW55d2F5KSBhbnkgcHJvZmlsaW5nIG9mIFRCIGZvciBmZWRlcmF0aW9uIGxp a2UgcHJvdG9jb2xzIHN1Y2ggT3BlbklEIENvbm5lY3QsIE9BdXRoIG9yIFNBTUwgc28gdGhpcyB3 b3VsZCBiZSBhbiBvcHBvcnR1bmUgdGltZSB0byBjaGFuZ2UgaG93IHRoZSByZWZlcnJlZCBUb2tl biBCaW5kaW5nIGlzIGNvbnZleWVkLg0KDQo= --_000_BN3PR03MB144522E21E8685A853DAB17E8C480BN3PR03MB1445namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFy YWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJ bWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsN CgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlk OjE0NTYzNzE0NDc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjkyOTYyMzI1OCAtOTQ2NTk2OTc0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVs MQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6NTsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxl dmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBCcmlhbiw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBjdXJyZW50IGZv cm1hdCwgd2hlcmUgYWxsIFRva2VuIEJpbmRpbmdzIGFyZSBjb250YWluZWQgaW4gb25lIFRva2Vu IEJpbmRpbmcgbWVzc2FnZSwgcHJvdmlkZXMgdXNlZnVsIGVuY2Fwc3VsYXRpb24uIFRoZSBIVFRQ IGxheWVyIGRvZXMgbm90IG5lZWQgdG8ga25vdyB0aGUNCiBkZXRhaWxzIG9mIHRoZSBUb2tlbiBC aW5kaW5nIHByb3RvY29sLCB3aGljaCBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gYSBzZXBhcmF0ZSBs aWJyYXJ5LiBJZiB0b21vcnJvdyB3ZSBkZWZpbmUgYSBuZXcgVG9rZW4gQmluZGluZyB0eXBlLCBh biBleGlzdGluZyBIVFRQIGltcGxlbWVudGF0aW9uIGNhbiBjYXJyeSBpdCBpbiB0aGUgU2VjLVRv a2VuLUJpbmRpbmcgaGVhZGVyIHdpdGhvdXQgbW9kaWZpY2F0aW9uLiBPbmx5IHRoZSBUb2tlbiBC aW5kaW5nDQogbGlicmFyeSB3b3VsZCBuZWVkIHRvIGJlIHVwZGF0ZWQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpX aW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMzMzMzMzMiPkF0IHRoZSBIVFRQIGxheWVyIHNlcGFyYXRlIGhlYWRlcnMgd2lsbCBtYWtlIGl0 IG11Y2ggbW9yZSBjbGVhciB3aGF0IGlzIGdvaW5nIG9uLiBKdXN0IGxvb2tpbmcgZm9yIHRoZSBw cmVzZW5jZSBvciBhYnNlbmNlIG9mIHRoZSBTZWMtUmVmZXJyZWQtVG9rZW4tQmluZGluZw0KIGhl YWRlciB3aWxsIGluZGljYXRlIGlmIGEgcmVmZXJyZWQgVEIgd2FzIHNlbnQsIHdoaWNoIGlzIHZl cnkgZWFzeS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5UaGlzIGNhbiBiZSBzb2x2ZWQgYnkgaW5jbHVkaW5nIGEgVEIgcGFyc2VyIGluIHRo ZSBwcm90b2NvbCBhbmFseXplci4gV2hpY2ggd291bGQgYWxzbyBwcm92aWRlIGZ1cnRoZXIgdXNl ZnVsIGluc2lnaHRzIGludG8gVEIga2V5IHBhcmFtZXRlcnMsIGV0Yy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzMzMzMzMyI+SGF2aW5nIGEgc2VwYXJhdGUgaGVhZGVyIGZvciB0aGUgcmVmZXJyZWQg VEIgYWxsb3dzIHRoZSBjbGllbnQvdXNlciBhZ2VudCB0byBhbHdheXMgc2VuZCB0aGUgcHJvdmlk ZWQgVEIgdmlhIFNlYy1Ub2tlbi1CaW5kaW5nIGFuZCBub3QgaGF2ZSB0byBidWlsZA0KIGEgbmV3 IFRCIG1lc3NhZ2Ugb24gdGhlIHJlZGlyZWN0IHJlcXVlc3QgYW5kIHRoZW4gZ28gYmFjayB0byB0 aGUgcHJvdmlkZWQgVEIgb24gc3Vic2VxdWVudCByZXF1ZXN0cy48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQgdGhpbmsgdGhl cmXigJlzIGFuIG9wdGltaXphdGlvbiBhbiBIVFRQIHN0YWNrIGNhbiBkbyBXUlQgYnVpbGRpbmcg VEIgbWVzc2FnZXMgdGhhdCBhIFRva2VuIEJpbmRpbmcgbGlicmFyeSBjYW7igJl0LCBhbmQgdGhl IFRva2VuIEJpbmRpbmcgbGlicmFyeSBpcyB3aGVyZQ0KIHN1Y2ggb3B0aW1pemF0aW9ucyBiZWxv bmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Gb3IgdGhlIGFi b3ZlIHJlYXNvbnMsIEkgd291bGQgcHJlZmVyIHRvIGtlZXAgYWxsIFRva2VuIEJpbmRpbmdzIGlu IG9uZSBUb2tlbiBCaW5kaW5nIG1lc3NhZ2UuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkFuZHJlaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJsZS1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBDYW1wYmVsbDxicj4N CjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAxNiwgMjAxNiAxOjIyIFBNPGJyPg0KPGI+VG86PC9i PiBJRVRGIFRva2JpbmQgV0cgJmx0O3VuYmVhcmFibGVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFtVbmJlYXJhYmxlXSBIVFRQU1RCOiBkaXN0aW5jdCBoZWFkZXIgZm9yIHRoZSBy ZWZlcnJlZCBUb2tlbiBCaW5kaW5nIChpc3N1ZSAjMzUpPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SXQgc2VlbXMgbGlrZSBnaXRodWIgcmVjZW50bHkgc3RhcnRlZCBzZW5k aW5nIHNvbWUgbm90aWZpY2F0aW9ucyB0byB0aGUgV0cgbGlzdCBidXQgaXQncyBub3QgY2xlYXIg aG93IHJlbGlhYmxlIHRoYXQgaXMgc28gSSdtIGdvbm5hIGRvdWJsZSBwb3N0IGFueXdheS4gVGhl IHRleHQgZnJvbQ0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL1Rva2VuQmluZGluZy9JbnRl cm5ldC1EcmFmdHMvaXNzdWVzLzM1Ij5odHRwczovL2dpdGh1Yi5jb20vVG9rZW5CaW5kaW5nL0lu dGVybmV0LURyYWZ0cy9pc3N1ZXMvMzU8L2E+IGZvbGxvd3MuDQo8YnI+DQo8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDtsaW5lLWhlaWdo dDoxNi44cHQ7YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMz MyI+QXMgbWVudGlvbmVkJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvbWludXRlcy05NS10b2tiaW5kLyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0MDc4QzA7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPmF0DQogSUVURiA5NTwvc3Bhbj48L2E+Jm5ic3A7SSBwcm9wb3Nl IHRoYXQgdGhlIHJlZmVycmVkIFRva2VuIEJpbmRpbmcgYmUgc2VudCB2aWEgYSBzZXBhcmF0ZSBo ZWFkZXIgKHNheSBTZWMtUmVmZXJyZWQtVG9rZW4tQmluZGluZykgcmF0aGVyIHRoYW4gYXMgcGFy dCBvZiB0aGUgU2VjLVRva2VuLUJpbmRpbmcgaGVhZGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGluO2xpbmUtaGVpZ2h0OjE2LjhwdDtiYWNrZ3Jv dW5kOndoaXRlO3RleHQtYWxpZ246c3RhcnQ7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMzMzMzMzIj5BdCB0aGUgSFRUUCBsYXllciBzZXBhcmF0ZSBoZWFkZXJz IHdpbGwgbWFrZSBpdCBtdWNoIG1vcmUgY2xlYXIgd2hhdCBpcyBnb2luZyBvbi4gSnVzdCBsb29r aW5nIGZvciB0aGUgcHJlc2VuY2Ugb3IgYWJzZW5jZSBvZiB0aGUgU2VjLVJlZmVycmVkLVRva2Vu LUJpbmRpbmcgaGVhZGVyIHdpbGwgaW5kaWNhdGUNCiBpZiBhIHJlZmVycmVkIFRCIHdhcyBzZW50 LCB3aGljaCBpcyB2ZXJ5IGVhc3kuIFJhdGhlciB0aGFuIGhhdmluZyB0byBkZWNvZGUgdGhlIFNl Yy1Ub2tlbi1CaW5kaW5nIGhlYWRlciB2YWx1ZSBhbmQgcHJvY2VzcyB0aGUgYmluYXJ5IGNvbnRl bnQsIHdoaWNoIGlzIHBvc3NpYmxlIGJ1dCBtdWNoIG1vcmUgaW52b2x2ZWQuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW47bGluZS1oZWlnaHQ6MTYu OHB0O2JhY2tncm91bmQ6d2hpdGU7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPkhhdmluZyBhIHNlcGFyYXRlIGhlYWRl ciBmb3IgdGhlIHJlZmVycmVkIFRCIGFsbG93cyB0aGUgY2xpZW50L3VzZXIgYWdlbnQgdG8gYWx3 YXlzIHNlbmQgdGhlIHByb3ZpZGVkIFRCIHZpYSBTZWMtVG9rZW4tQmluZGluZyBhbmQgbm90IGhh dmUgdG8gYnVpbGQgYSBuZXcgVEIgbWVzc2FnZSBvbiB0aGUgcmVkaXJlY3QNCiByZXF1ZXN0IGFu ZCB0aGVuIGdvIGJhY2sgdG8gdGhlIHByb3ZpZGVkIFRCIG9uIHN1YnNlcXVlbnQgcmVxdWVzdHMu IEFsc28gbm90IGhhdmluZyB0aGUgdmFsdWUgb2YgU2VjLVRva2VuLUJpbmRpbmcgY2hhbmdlIChv dGhlciB0aGVuIGEgbmV3IFRMUyBzZXNzaW9uIHdpdGggbmV3IEVLTSkgc2hvdWxkIG1ha2UgaXQg bmljZWx5IGVmZmljaWVudCB3aXRoIEhUVFAvMiBoZWFkZXIgY29tcHJlc3Npb24uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW47bGluZS1oZWlnaHQ6 MTYuOHB0O2JhY2tncm91bmQ6d2hpdGU7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPkkgYWxzbyBiZWxpZXZlIGl0IHdp bGwgYmUgZWFzaWVyIHRvIGNvdmV5IHRoZSBjb25jZXB0cyBpbiB0aGUgdGV4dCBvZiB0aGUgc3Bl Yy4gVGFsa2luZyBhYm91dCB3aGVuIHRoZSBTZWMtUmVmZXJyZWQtVG9rZW4tQmluZGluZyBpcyBz ZW50IG9yIG5vdCBzZW50IHJhdGhlciB0aGFuIHRhbGtpbmcgYWJvdXQgd2hlbg0KIHRoZSByZWZl cnJlZCBUQiBpcyBpbmNsdWRlZCBhcyBwYXJ0IG9mIHRoZSBUQiBtZXNzYWdlIHRoYXQgaXMgc2Vu dCB3aXRoIFNlYy1Ub2tlbi1CaW5kaW5nIHNlZW1zIG11Y2ggbW9yZSBzdHJhaWdodGZvcndhcmQu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW47bGlu ZS1oZWlnaHQ6MTYuOHB0O2JhY2tncm91bmQ6d2hpdGU7dGV4dC1hbGlnbjpzdGFydDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPkFuZWNkb3RhbGx5 LCB0aGVyZSdzIGJlZW4gc29tZSBkaXNjdXNzaW9uIGFib3V0IHVzaW5nIFRCIGluIE9wZW5JRCBD b25uZWN0IGFuZCBhbmQgaW4gdGFsa2luZyBhYm91dCBpdCBwZW9wbGUgb2Z0ZW4gc2F5ICZxdW90 O3RoZSByZWZlcnJlZCB0b2tlbiBiaW5kaW5nIGhlYWRlciZxdW90Oywgd2hpY2ggaXNuJ3QgYWNj dXJhdGUNCiByZWxhdGl2ZSB0byBIVFRQU1RCLTAzIGJ1dCBiZWxpZXMgdGhlIGZhY3QgdGhhdCBm ZWRlcmF0aW9uIGZvbGtzIGFscmVhZHkgdGhpbmsgYWJvdXQgaXQgYXMgc2VwYXJhdGUgaGVhZGVy LiBBbmQgSSB0aGluayB0aGF0J3MgYSBuYXR1cmFsIHdheSB0aGluayBhYm91dCBpdCBzbyBpdCdz IG5vdCB0ZXJyaWJseSBzdXJwcmlzaW5nLiBJIHdvbid0IG5hbWUgYW55IG5hbWVzIGJ1dCBvbmUg b2YgdGhlIGNoYWlycyBvZiB0aGUgV0cgaXMgYW1vbmcgdGhvc2UNCiB3aG8gc2FpZCAmcXVvdDt0 aGUgcmVmZXJyZWQgdG9rZW4gYmluZGluZyBoZWFkZXIuJnF1b3Q7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MGluO2xpbmUtaGVpZ2h0OjE2LjhwdDtiYWNrZ3Jv dW5kOndoaXRlO21hcmdpbi1ib3R0b206MHB4IWltcG9ydGFudDt0ZXh0LWFsaWduOnN0YXJ0O3dv cmQtc3BhY2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+SSByZWFs aXplIHRoaXMgaXMgbm90IGFuIGluc2lnbmlmaWNhbnQgY2hhbmdlIGJ1dCBJIHN0cm9uZ2x5IGJl bGlldmUgaXQnZCBiZSBhIHNpbXBsaWZpY2F0aW9uIGFuZCBpbXByb3ZlbWVudCBmb3IgSFRUUFMg VEIuIFRoZXJlJ3Mgbm90IHlldCAodGhhdCBJJ20gYXdhcmUgb2YgYW55d2F5KSBhbnkgcHJvZmls aW5nDQogb2YgVEIgZm9yIGZlZGVyYXRpb24gbGlrZSBwcm90b2NvbHMgc3VjaCBPcGVuSUQgQ29u bmVjdCwgT0F1dGggb3IgU0FNTCBzbyB0aGlzIHdvdWxkIGJlIGFuIG9wcG9ydHVuZSB0aW1lIHRv IGNoYW5nZSBob3cgdGhlIHJlZmVycmVkIFRva2VuIEJpbmRpbmcgaXMgY29udmV5ZWQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN3PR03MB144522E21E8685A853DAB17E8C480BN3PR03MB1445namp_-- From nobody Tue May 17 12:35:39 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3315912D919 for ; Tue, 17 May 2016 12:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vz5ROZF2ORrN for ; Tue, 17 May 2016 12:35:30 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211E112DD55 for ; Tue, 17 May 2016 12:35:30 -0700 (PDT) Received: by mail-ig0-x22d.google.com with SMTP id m9so15680036ige.1 for ; Tue, 17 May 2016 12:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:from:date:message-id:subject:to; bh=RhAL41FgCakiAyv/YOg69P/cGTn4ySX4F2V0JKEDptM=; b=Z1K9DOLobeDytQwlwM0dDJfljXx6JgEABy+UmZlk1bC6Z5E++lRkoL6kOMxvGfXvC1 VAiBXWq+o0gLH2QoMWtGzzpiun7WtipgUojWy3nwK3ugHu2WwQSPDYi0dZb7Zci8CB6S YSHPfKd5FPmNWmV0XwK4/K3TLnS9QclVh1eAo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=RhAL41FgCakiAyv/YOg69P/cGTn4ySX4F2V0JKEDptM=; b=SE/KUxx+NJiwpEpeLprs1HekX67WsZSWJzmH3O/z641O37iijqx5/k0gLhp1bQUHmf R7xVrr1PhHgivQ5xsRt3I1YjKTKoyZ3Xq680PYquuNhUry0S/HV+90GyFxNJFW4YGLEB mguJiYaiC1voArn0+/zTASXDwIASkQI3hYB+Pf/WSpw5HkCPauhPSrEbi18dQuoeeilS cHD+U+kExoHSJEYgNTTKWZid2I/UJp2CjOOOWCd6QpjI7sBsDoRvBUQuen+GiWft2w2d ilqxzt4cCu5LrYNxLY4f4L6x+1k0rFYsosrd4fDMjgYGeTBR6z5VUjE+i5TJkQRj7n/1 hrhg== X-Gm-Message-State: AOPr4FUeLnpC6SeauG5kHoL+Ceen/dsfRa7M3iBaAjoUQcigLPGFL75oSYxE5rtgjqAA2GSnuizk5jLEi091Kcou X-Received: by 10.50.15.131 with SMTP id x3mr14886887igc.18.1463513729327; Tue, 17 May 2016 12:35:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.105.129 with HTTP; Tue, 17 May 2016 12:34:59 -0700 (PDT) From: Brian Campbell Date: Tue, 17 May 2016 13:34:59 -0600 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary=14dae9340d97f601e605330ed7a4 Archived-At: Subject: [Unbearable] ecdsap256 questions X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 19:35:37 -0000 --14dae9340d97f601e605330ed7a4 Content-Type: text/plain; charset=UTF-8 Is ecdsap256 the NIST P-256 curve? I'm guessing so but it's not totally clear from the document. The relevant text (that I could find anyway) from TBPROTO-03 here: "When an ecdsap256 key is used, TokenBinding.signature contains a pair of integers, R followed by S, as defined in [ANSI.X9-62.2005 ]. R and S are encoded in big-endian format. ECPoint.point contains the X coordinate followed by the Y coordinate. The X and Y coordinates are unsigned integers encoded in big-endian format." I was going to suggest that TBPROTO explicitly say that for ecdsap256 R & S and X & Y always be exactly 32 octets/bytes long and that any leading zero bytes be preserved (rare but possible AFAIK), which I assume was the intent so that the point and signature can be consistently processed. Then I thought maybe I should first look at ANSI.X9-62 to see if this was already clearly stated there somewhere. But it seems that one can't actually read X9-62 without shelling out $100, which is a lot to just look for a little details like that. So, from that fun little story (sorry!), a couple comments/questions: Can TBPROTO state the curve used with the ecdsap256 TB key parameters in a way that's easy and obvious? And maybe also cite a document that's a little more accessible than X9-62 in doing so? I believe many RFCs, 7518/JWA for example, cite FIPS PUB 186-4 "Digital Signature Standard (DSS)" for ECDSA and the P-* curves. I expect most implementers will be using an existing ECDSA implementation and just need to get the parameters and input/output formatted correctly. That reference and the text in JWA was enough for many independent implementations to get it right with JWS. And about getting the input/output formatted correctly, can or should TBPROTO say that R&S/X&Y are always 32 bytes and so leading zeros need to be added or retained? Thanks for obliging my little questions, Brian --14dae9340d97f601e605330ed7a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is ecdsap256 the NIST P-256 curve? I'm = guessing so but it's not totally clear from the document. The relevant = text (that I could find anyway) from TBPROTO-03 here:

   "=
When an ecdsap256 key is used, TokenBinding.signature contains a pair
   of integers, R followed by S, as defined in [ANSI.X9-62.2005].  R and
   S are encoded in big-endian format.  ECPoint.point contains the X
   coordinate followed by the Y coordinate.  The X and Y coordinates are
   unsigned integers encoded in big-endian format."

I w= as going to suggest that TBPROTO explicitly say that for ecdsap256 R & = S and X & Y always be exactly 32 octets/bytes long and that any leading= zero bytes be preserved (rare but possible AFAIK), which I assume was the = intent so that the point and signature can be consistently processed. Then = I thought maybe I should first look at ANSI.X9-62 to see if this was alread= y clearly stated there somewhere. But it seems that one can't actually = read X9-62 without shelling out $100, which is a lot to just look for a lit= tle details like that.=C2=A0=C2=A0

So, from that fun little s= tory (sorry!), a couple comments/questions:

Can TBPROTO state = the curve used with the ecdsap256 TB key parameters in a way that's eas= y and obvious? And maybe also cite a document that's a little more acce= ssible than X9-62 in doing so?=C2=A0 I believe many RFCs, 7518/JWA fo= r example, cite FIPS PUB 186-4 "Digital Signature Standar= d (DSS)" for ECDSA and the P-* curves. I expect most implementers = will be using an existing ECDSA implementation and just need to get the par= ameters and input/output formatted correctly. That reference and the text i= n JWA was enough for many independent implementations to get it right with = JWS.

And about getting the input/output formatted c= orrectly, can or should TBPROTO say that R&S/X&Y are always 32 byte= s and so leading zeros need to be added or retained?

Tha= nks for obliging my little questions,
Brian
<= br>
--14dae9340d97f601e605330ed7a4-- From nobody Tue May 17 14:05:32 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CF112D1F0 for ; Tue, 17 May 2016 14:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sTbkNNIZ_9X3 for ; Tue, 17 May 2016 14:05:27 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C2F12D188 for ; Tue, 17 May 2016 13:57:59 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id d62so40037548iof.2 for ; Tue, 17 May 2016 13:57:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=anttIsg+uj6L2COvbM5xbqAx7TViIFVUNOUB3gpsRiQ=; b=Enc9nWU/TG7xzfOkaFm4HFkK8p7LusHB/Cglkw1ZY8TWOLMnbOTEddjEvB8RXrU8S7 Mf1noBso8M6ARhK5SMHlcwI6dUMcQya/zsBvlv/8odzylq2rwqrexNbqcSTJsIUvm98t vmileLPx2g1bH/QXUEnlIYGp4MphBabv45mCw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=anttIsg+uj6L2COvbM5xbqAx7TViIFVUNOUB3gpsRiQ=; b=JF20Ssk3ojNq/oFA6DyOG0iOvxVEErBG8WppYW7ffpDGufhvjObzo7fCGK340fmg3e wnMGGl/8wOyFG0zXd0dxsGK4SweZGe74GI66mxpjN2dk68fmFC2kmUVpIA73VK0Z8hKj /WqC2pmqTjHL2ptJrsRFPW1ucN0wnisy57CAUvkZMM3hwn+Ue/i1WmyUsnq8bjD67pQ9 OKkAAlFwE3wsrAhVkfgadQU4PcVAFXmiBrGqaY5Z7sM0JsL9+xwnkiQ/S549on3ndtYD 360V+MJofQ+nz5HbVN1A3HLiNpfR+LUfxksV6P1j7Y7nqE3Cz1Ca8oWnoUtlpfniu2Dq y/5w== X-Gm-Message-State: AOPr4FVCI+pxfxkAj5f01j2kwJq4gJk55/i4E+Evfx8bUHxmoBfAVxaeYxPcJeI0RwzrBW5NI9NM0m/oxUu41vse X-Received: by 10.107.28.14 with SMTP id c14mr2556428ioc.86.1463518679009; Tue, 17 May 2016 13:57:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.105.129 with HTTP; Tue, 17 May 2016 13:57:29 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Tue, 17 May 2016 14:57:29 -0600 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a1140aa78fc525905330ffea0 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 21:05:29 -0000 --001a1140aa78fc525905330ffea0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Despite my lack of agreement, Andrei, I appreciate the reply. My replies inline below... On Tue, May 17, 2016 at 11:21 AM, Andrei Popov wrote: > Hi Brian, > > > > The current format, where all Token Bindings are contained in one Token > Binding message, provides useful encapsulation. The HTTP layer does not > need to know the details of the Token Binding protocol, which can be > implemented in a separate library. If tomorrow we define a new Token > Binding type, an existing HTTP implementation can carry it in the > Sec-Token-Binding header without modification. Only the Token Binding > library would need to be updated. > The HTTP layer does need to know about TB for TB to be of any value - that's where the signature(s) get verified and where cookies and other tokens are actually bound. If a new Token Binding type is defined (which honestly seems unlikely), yes it could be carried in the current format but the HTTP layer would also need to be updated to do anything useful with it. I don't see the benefit of this encapsulation. =C3=98 At the HTTP layer separate headers will make it much more clear wha= t is > going on. Just looking for the presence or absence of the > Sec-Referred-Token-Binding header will indicate if a referred TB was sent= , > which is very easy. > > This can be solved by including a TB parser in the protocol analyzer. > Which would also provide further useful insights into TB key parameters, > etc. > > But my point isn't that it can't be done. It's that it's really useful to be able to look at HTTP and tell whats going on without having to use a protocol analyzer or TB parser. > =C3=98 Having a separate header for the referred TB allows the client/us= er > agent to always send the provided TB via Sec-Token-Binding and not have t= o > build a new TB message on the redirect request and then go back to the > provided TB on subsequent requests. > > I don=E2=80=99t think there=E2=80=99s an optimization an HTTP stack can d= o WRT building TB > messages that a Token Binding library can=E2=80=99t, and the Token Bindin= g library > is where such optimizations belong. > It's not an optimization but rather just a simplification where the provided TB is always sent the same way no matter what and the referrer/referred is processed independently. To my eye, that's better cohesion and less coupling. HTTP/2 header compression, however, is an optimization in the HTTP layer that would be helped by having the provided TB header not change. > > > For the above reasons, I would prefer to keep all Token Bindings in one > Token Binding message. > > > I got a pretty good idea of your preference when I first mentioned separate headers in BA :) My preference is obviously different and I wanted to voice that on the list/github. But I guess ultimately it's an aesthetics or eye of the beholder kind of thing. I won't fight about it too hard. And I'm just a guy, not an editor. But I was looking the share the viewpoint of what seems simpler at the HTTP layer from someone who works primarily at the HTTP layer. I hope that viewpoint can be considered even though two headers is different than what's already done. I'd also be interested in knowing if others in the WG have opinions here or if I'm the outlier? > Cheers, > > > > Andrei > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Br= ian > Campbell > *Sent:* Monday, May 16, 2016 1:22 PM > *To:* IETF Tokbind WG > *Subject:* [Unbearable] HTTPSTB: distinct header for the referred Token > Binding (issue #35) > > > > It seems like github recently started sending some notifications to the W= G > list but it's not clear how reliable that is so I'm gonna double post > anyway. The text from > https://github.com/TokenBinding/Internet-Drafts/issues/35 follows. > > > As mentioned at IETF 95 > I propose that the > referred Token Binding be sent via a separate header (say > Sec-Referred-Token-Binding) rather than as part of the Sec-Token-Binding > header. > > At the HTTP layer separate headers will make it much more clear what is > going on. Just looking for the presence or absence of the > Sec-Referred-Token-Binding header will indicate if a referred TB was sent= , > which is very easy. Rather than having to decode the Sec-Token-Binding > header value and process the binary content, which is possible but much > more involved. > > Having a separate header for the referred TB allows the client/user agent > to always send the provided TB via Sec-Token-Binding and not have to buil= d > a new TB message on the redirect request and then go back to the provided > TB on subsequent requests. Also not having the value of Sec-Token-Binding > change (other then a new TLS session with new EKM) should make it nicely > efficient with HTTP/2 header compression. > > I also believe it will be easier to covey the concepts in the text of the > spec. Talking about when the Sec-Referred-Token-Binding is sent or not se= nt > rather than talking about when the referred TB is included as part of the > TB message that is sent with Sec-Token-Binding seems much more > straightforward. > > Anecdotally, there's been some discussion about using TB in OpenID Connec= t > and and in talking about it people often say "the referred token binding > header", which isn't accurate relative to HTTPSTB-03 but belies the fact > that federation folks already think about it as separate header. And I > think that's a natural way think about it so it's not terribly surprising= . > I won't name any names but one of the chairs of the WG is among those who > said "the referred token binding header." > > I realize this is not an insignificant change but I strongly believe it'd > be a simplification and improvement for HTTPS TB. There's not yet (that I= 'm > aware of anyway) any profiling of TB for federation like protocols such > OpenID Connect, OAuth or SAML so this would be an opportune time to chang= e > how the referred Token Binding is conveyed. > > > --001a1140aa78fc525905330ffea0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Despite my lack of agr= eement, Andrei, I appreciate the reply. My replies inline below...

On Tue, M= ay 17, 2016 at 11:21 AM, Andrei Popov <Andrei.Popov@microsoft.com= > wrote:

Hi Brian,

=C2=A0

The current format, where all To= ken Bindings are contained in one Token Binding message, provides useful en= capsulation. The HTTP layer does not need to know the details of the Token Binding protocol, which can be implemented in a separ= ate library. If tomorrow we define a new Token Binding type, an existing HT= TP implementation can carry it in the Sec-Token-Binding header without modi= fication. Only the Token Binding library would need to be updated.

=
The HTTP layer does need= to know about TB for TB to be of any value - that's where the signatur= e(s) get verified and where cookies and other tokens are actually bound.=C2= =A0 If a new Token Binding type is defined (which honestly seems unlikely),= yes it could be carried in the current format but the HTTP layer would als= o need to be updated to do anything useful with it. I don't see the ben= efit of this encapsulation.

<= div>

=C3=98= =C2=A0 At the HTTP layer separa= te headers will make it much more clear what is going on. Just looking for = the presence or absence of the Sec-Referred-Token-Binding header will indicate if a referred TB was sent, which is very easy.=

This can be solved by including = a TB parser in the protocol analyzer. Which would also provide further usef= ul insights into TB key parameters, etc.


But my p= oint isn't that it can't be done. It's that it's really use= ful to be able to look at HTTP and tell whats going on without having to us= e a protocol analyzer or TB parser.
=C2=A0

=C3=98= =C2=A0 Having a separate header= for the referred TB allows the client/user agent to always send the provid= ed TB via Sec-Token-Binding and not have to build a new TB message on the redirect request and then go back to the provided = TB on subsequent requests.<= /p>

I don=E2=80=99t think there=E2= =80=99s an optimization an HTTP stack can do WRT building TB messages that = a Token Binding library can=E2=80=99t, and the Token Binding library is whe= re such optimizations belong.


It's not an optimization bu= t rather just a simplification where the provided TB is always sent the sam= e way no matter what and the referrer/referred is processed independently. = To my eye, that's better cohesion and less coupling.

HTTP/2 hea= der compression, however, is an optimization in the HTTP layer that would b= e helped by having the provided TB header not change.

<= div>=C2=A0

=C2=A0

For the above reasons, I would p= refer to keep all Token Bindings in one Token Binding message.

=C2=A0


I got a pretty g= ood idea of your preference when I first mentioned separate headers in BA := ) My preference is obviously different and I wanted to voice that on the li= st/github. But I guess ultimately it's an aesthetics or eye of the beho= lder kind of thing. I won't fight about it too hard. And I'm just a= guy, not an editor. But I was looking the share the viewpoint of what seem= s simpler at the HTTP layer from someone who works primarily at the HTTP la= yer. I hope that viewpoint can be considered even though two headers is dif= ferent than what's already done.

I'd also be interested in knowing if others in= the WG have opinions here or if I'm the outlier?
=
=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ietf.o= rg] On Behalf Of Brian Campbell
Sent: Monday, May 16, 2016 1:22 PM
To: IETF Tokbind WG <unbearable@ietf.org>
Subject: [Unbearable] HTTPSTB: distinct header for the referred Toke= n Binding (issue #35)

=C2=A0

It seems like github recently started sending some n= otifications to the WG list but it's not clear how reliable that is so = I'm gonna double post anyway. The text from https://github.com/TokenBinding/Internet-Drafts/issues/35 = follows.


As mentioned=C2=A0at IETF 95=C2=A0I propose that the referred Token Binding be sent = via a separate header (say Sec-Referred-Token-Binding) rather than as part = of the Sec-Token-Binding header.

At the HTTP layer separate headers will make it much= more clear what is going on. Just looking for the presence or absence of t= he Sec-Referred-Token-Binding header will indicate if a referred TB was sent, which is very easy. Rather than having to decod= e the Sec-Token-Binding header value and process the binary content, which = is possible but much more involved.

Having a separate header for the referred TB allows = the client/user agent to always send the provided TB via Sec-Token-Binding = and not have to build a new TB message on the redirect request and then go back to the provided TB on subsequent requests. Also n= ot having the value of Sec-Token-Binding change (other then a new TLS sessi= on with new EKM) should make it nicely efficient with HTTP/2 header compres= sion.

I also believe it will be easier to covey the concep= ts in the text of the spec. Talking about when the Sec-Referred-Token-Bindi= ng is sent or not sent rather than talking about when the referred TB is included as part of the TB message that is sent with Se= c-Token-Binding seems much more straightforward.

Anecdotally, there's been some discussion about = using TB in OpenID Connect and and in talking about it people often say &qu= ot;the referred token binding header", which isn't accurate relative to HTTPSTB-03 but belies the fact that federation folks already t= hink about it as separate header. And I think that's a natural way thin= k about it so it's not terribly surprising. I won't name any names = but one of the chairs of the WG is among those who said "the referred token binding header."

I realize this is not an insignificant change but I = strongly believe it'd be a simplification and improvement for HTTPS TB.= There's not yet (that I'm aware of anyway) any profiling of TB for federation like protocols such OpenID Connect, OAuth or SAML so = this would be an opportune time to change how the referred Token Binding is= conveyed.

=C2=A0


--001a1140aa78fc525905330ffea0-- From nobody Tue May 17 14:47:00 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3645912D979 for ; Tue, 17 May 2016 14:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=buckeyemailosu.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SwS-yWkxvKC for ; Tue, 17 May 2016 14:46:47 -0700 (PDT) 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 1F0D212DA3E for ; Tue, 17 May 2016 14:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buckeyemailosu.onmicrosoft.com; s=selector1-osu-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/eShsY1LiAqPbsOTGDGTGW0MXwlY2QyosHB677ZzOwY=; b=Ya0bTGqGqzlC9OJpSmpwIbrO+8D0s3W3ADqqv0grpJS85Y7Hfm7WZr0ibYzUUjxgJuziXTrkRZcG9RXu6XGTTWWE3O/XpWOClMsZd8cq3fShtoQ4mvDxsw5Pek44t5Clxo+csVv71i8c4tuUc6djft4YOAByUTn6g/vWWQ+qB2E= Received: from CY1PR0101CA0026.prod.exchangelabs.com (10.162.170.36) by BN3PR01MB1286.prod.exchangelabs.com (10.163.35.22) with Microsoft SMTP Server (TLS) id 15.1.501.7; Tue, 17 May 2016 21:46:45 +0000 Received: from BN1BFFO11OLC004.protection.gbl (2a01:111:f400:7c10::1:137) by CY1PR0101CA0026.outlook.office365.com (2a01:111:e400:51d0::36) with Microsoft SMTP Server (TLS) id 15.1.497.12 via Frontend Transport; Tue, 17 May 2016 21:46:45 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.218) smtp.mailfrom=osu.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=osu.edu; Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.218 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.218; helo=cio-tnc-pf04.osuad.osu.edu; Received: from cio-tnc-pf04.osuad.osu.edu (164.107.81.218) by BN1BFFO11OLC004.mail.protection.outlook.com (10.58.145.15) with Microsoft SMTP Server (TLS) id 15.1.497.8 via Frontend Transport; Tue, 17 May 2016 21:46:44 +0000 Received: from CIO-TNC-HT05.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1.2 with cipher AES256-SHA256 (256/256 bits)) (No client certificate requested) by cio-tnc-pf04.osuad.osu.edu (Postfix) with ESMTPS id 8CFE7380070; Tue, 17 May 2016 17:46:43 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.03.0248.002; Tue, 17 May 2016 17:46:38 -0400 From: "Cantor, Scott" To: Brian Campbell , Andrei Popov Thread-Topic: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) Thread-Index: AQHRsH/wUZPFP+71UkmQUk1veolL6Z+9mWgA Date: Tue, 17 May 2016 21:46:37 +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: [162.244.106.216] x-header-sapphire: true Content-Type: text/plain; charset="utf-8" Content-ID: <59E03D91EA55D14DB3AEC0E2D4795E70@osu.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:164.107.81.218; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(199003)(24454002)(189002)(377454003)(36756003)(106116001)(106466001)(586003)(89122001)(6116002)(109096001)(3846002)(102836003)(2421001)(33656002)(50466002)(92566002)(76176999)(54356999)(4326007)(2950100001)(189998001)(50986999)(11100500001)(88552002)(5004730100002)(2906002)(5250100002)(5001770100001)(16796002)(75432002)(23676002)(19580405001)(19580395003)(8676002)(8666002)(90282001)(8936002)(1220700001)(5003600100002)(86362001)(2561002)(6806005)(93346002)(87936001)(47776003)(5008740100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB1286; H:cio-tnc-pf04.osuad.osu.edu; FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11OLC004; 1:19Yk/suhllXEfAShuSZDMlKKji0hbSxyJA6wnRvoZ4Ff0bllkGuDv6YHzZQtKfbP4RbhD54bag3AKXXjyr9OOu6HNVO73pOFaWjkCca3nqk4JnvJPSth8UA4FGKPHaAAmT5Q9N2NNM45mNQ4HDqtpcN5+4uf5YN3NHRDfzWUS8lSnFvR/v97/vbOvwu0E9D9UBZ4l3OQpQq6AUr2diM66+79OVU6LX68Hqoeeca4zQLFLpbZM052bzV2mXFq8zZaT+yRqYanpeEajgPyujK4Zx/Bgn3m9iS70y8al0cjaZJxfw1TVCAk6ZCey3kW0pZLMcLX+wtCys+uBkz5dpnjQuDp83UWU/IbTV52m9FoKYsocMTJANsCdmCpJKb7SJnTXpel+KHfS3A4xcpHB5kY8DNspOE+jftYQrXGVUH3dVmWwf/hvwQa7L28DkO4TtbDlBWap4iCOA3vcWajXdu1Uuhsl8gg0Q58ZsBGe39+Ji7nR3m2n7NH3R5xxtg4emDJ8UeVYCIDhNr2m2dtUFZ3sITfOt5wHJ2SVa5aL1pmMzk= X-MS-Office365-Filtering-Correlation-Id: 6f8d1c96-3ecb-4aee-9fd8-08d37e9cbd95 X-Microsoft-Exchange-Diagnostics: 1; BN3PR01MB1286; 2:78spNUU5ozp9KNWui/WnEqtsSSu7G9JO7MMMy9B2HN6QgSLauUC4zH/Yy+2+rHCi6QyleOgJD087tHhxtt1ueg7PVwBkZbtnRV8AMI5QuDOUwplT/+yNsW8PF+UVO2yw2H68KJl0QvYkxKyHMBmqoP3BlNA2fdYKb8AMYYCWAwfuVg5V2rIAH3TO4u17ygY9; 3:Wf2FbkWm9gd1l3ImirjTaP4Xo9+VfMLK7SLT4x8Bx0J/bkakLyE0AjeUNfTLBaNjVllMw/sTIAqZus803fdRSqR05cIueiJph0cJyg2c1vcujzI1CqFCTMo3P1NoUhXBZtxD3wJsQmF8rGYZVuuWMbSTaOevCML6tdq36q4QBxTCZkWZG7sQBZAuLovGEs18VkXVS1rRott26/HorxX4E0mPakS/kn6LQkuyyHazUXSDYhHFPC8D3VSqYK1d9x8LI31vomI+lEWBV8x9AkqJHA==; 25:Ao4wvL52atg84pOYl5nXP5g4drmX+7dxUWTsCyqX7eeyjcslxiRQFc3IkDcqlro27XH3S9QdnMeFtL1dZwJ/ENqDU8vaeDmveDeryJAR0WbB7I9zBxgm4u1R0drKiTqRCadpo+KbD9WzSHE7xoWFrpPIK+K9/iFdTwxc1AFcXYbeihi9Unu7pkX0Nip+gXbAAE25ML5QzWO1uRTGeFOjSzA1xm6lpFtnKrIpjOvrrvQ5CbdN0cykTQ2pukPw246CQh0dKS+4YMskhhW1tdZZLehf36JqGzYdFLlbtP6ELZRLyTC/eQ/Jm2IKtesXeCKFGcH376FWOgl1p0thl1AXXDZk515sTUHPTti9VocuH8tS08jFSze7dZNx1ro9MjM/0C4MiBzhaoMeRdc+VfGru+dTQ6E5tgoLrsUQ4oTVnXc= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BN3PR01MB1286; X-Microsoft-Exchange-Diagnostics: 1; BN3PR01MB1286; 20:DYE3Zt58U0JKCBBuLkSKVc1p+GHD6f6NFgRuGvM9w4wreMUFvPmqVwjENnjRyGkUlUWqRwUD7o/cprGDV/boflXNY1f5m4bmSluQec/3B9FHx0kvSzzZgKGQ9Erd+MTBm4kafLg66Dg2qyL+c5fqRnRwjDySzBfzDtr1LSRpNYTwqti93Op/dSnD79251Xf1RBHD4ZPbZVwDKWuDAGVaxwdX2p5M3NoYnv0bFa4zzZUTIfsD/L3XrsvuHTlt6lj57fWBcTTLF7XcaPnc3hRk8ky7ZvBKWWlA770/42Zl5esnjLSlRXWjOGgq+4ikhcLeBGg7ZeyTlQWBolsL6JKo3faM/xvTNjx1vNGCY5Dog6PeKFkIzC/0eVswi2Gsf3aoJH7xA3fMw//lWEedlj/L8Qoaee3sGhAAYdemVbPQjAO2EKAFZGqYjWJ6OxIKP1zs5xanEl8tPa1qBMz/q+5PAlPuMjDG32Wcv0LX80+6KAD0jroMpuC+VJLuChaeYSdH; 4:8pbYHAVpgUG0b6SzH8jwwan5znWx/pIo/gIeNrKjRKIzatyfaEUhQJ0SoG6XTpjV/kQccO4exmlanxKULSfJjXKOgOUFimu3CGyBqOt+VYFGlJbOw4NTZsdTB3F7BhvngPwfOAdUDIe4dj2Iag5xmDn1ckv99Ch0/z28Fuun/PJucOsmyg5Rk608n5entZwLKPr4yr2o9WDC5+vKUJuDH60zBt1pJw4i8GUgpKvfRjm6KpG+r1ZBM93weAeQRIIRuva/1MYtCIaLHroaYTniSYZeZWPi+sEdQ6RRkaw3rLDNE/pYXOEGzNMFL46xWsNOJr4KbXuI6xzL/k13Vd+VD/V7jOvGB0i1J6HVkP8PdxZMOK9ZuihpzthXYNZNXfAmYNmy1zf8hl0E1QGBrlrq9x0Z3H5tGDAi6MUnub4ujDvQ1TquTjGUIaU62xELVGZf X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(13018025)(8121501046)(5005006)(13017025)(13023025)(13024025)(13015025)(3002001)(10201501046); SRVR:BN3PR01MB1286; BCL:0; PCL:0; RULEID:; SRVR:BN3PR01MB1286; X-Forefront-PRVS: 0945B0CC72 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjAxTUIxMjg2OzIzOnVKYnBYMTZiaXJ5MTZmWXJBT1VSbzV2WEkw?= =?utf-8?B?c1hHOHJUTTF1emQzbTBiaDd0RGdGZFczckxKWkJaYkd0SSs2SDl3TmdLd1Nl?= =?utf-8?B?SEpkS0ZFQkN4cjZxbUtkQ250eDJJRUhOL2djNUVBK2o1LzYrNkZuUzBOUmd6?= =?utf-8?B?NUpjdkZwU21pekZPa3g5dzhlZlNkVENhL0tJWENiL1hMWER1TzdwaWV1Tlhp?= =?utf-8?B?enlKc2F3OXB0RnhtQlB3RUp4emIwd2FLT0dKWlF0TG4zaUx5bzFMTGNRYVZs?= =?utf-8?B?TVlHZVl3VGtPeWVYN0RYRlhwdlBRcHFhYXo4bzhvSjBmYnFPSzgrWFhZY3Vu?= =?utf-8?B?YzA5TjU2dHBxTFVRN2RxRnZlNTVLRTJGMTM3L0FKKzBZK0l1MEFFOUdqaDB6?= =?utf-8?B?OWQyY3JrNVVvNWpJeE9ZbUpTQWpVODIwKzlldG83SVJXVXFrcEJpSnBhM1kz?= =?utf-8?B?U3gyb2RJNVNrTzZjTW5sdUtYTVNyeVpwc0p3dW9QU1JmdVd6aW1qakdaN3lt?= =?utf-8?B?ZWlVQzIzUjNBNmYxbEVvSWNuTkRiTlNNT3hhbjZGeHdZOFB3ZUtPSTNCTDB2?= =?utf-8?B?aEVXeFdmQ1g1Z0dJbXRsVHArUFQxdjRmUDFFZkwxK3ZDQXF5RXlKL1BjSUx1?= =?utf-8?B?d3M4NlduOVZYREhuTDZDMk5NZkRnaHlGZ2dMNHNWTHBqeTZlaC9IWUtYUlF6?= =?utf-8?B?ZHpVT2hjL0JTL2FhaURkWXVlOTJZNDZBNDk5b0ZJdkRQM3lva0NMcnlmNm1L?= =?utf-8?B?VDdIa1RBSXROTmErVEw3RmdpdkkyNFptYXdUV0pkakI5TEhlRXc4NnRaMGZH?= =?utf-8?B?VW9jM1dhNGVIbktGM3B1UkZTTWIxdjVBZkx2NXpyUXNHNWorc2xHclFaWE1R?= =?utf-8?B?eVhmV29OMWlmR1pET0w4a1V0N2RUWWtkUnFsYlNiRHRiZGVEUUJQNGtHMVhy?= =?utf-8?B?bm9ieXNlNzNwV1Vjc0RIL1ppTFBRelI2WDJ2eXB3L2N3ZUlmSVFlWUNMQWlM?= =?utf-8?B?d1ZCcGM3K2t0SkpUQjUxblNVSUxzbm44dVFlbmFvL0VmN3MzRGErWUhlY2dl?= =?utf-8?B?SFdxVVhXc3Zrb3FuN1FCaXZDbGQyRXZ1Nm10WGU3K3kzdklsd2pLQ2xZN1dN?= =?utf-8?B?VE1mWHZlMUNHQkFidW9oS09ZMDRVV1NHUERlc3lpZWhLOE4zTnpHZzU3T3ND?= =?utf-8?B?M2ZMOFNsTm9NYVZvT0JnMnU4U2Z2NSt5SkRtMThWdTNlQWhBNi9DaVM2N2l1?= =?utf-8?B?QzQwSVplUTJyOHN1anZaVXZoTDBSbGFVVHNPTXhPazdxWS9KZS9oUFh1M0NV?= =?utf-8?B?MFpxdnlWZElXY2dSVHJKM3Y4V0dBeVZ5TnFBWVl0TU43eWEvTzVVa01ZaFdJ?= =?utf-8?B?YXRKMDM5NHNaOW9nOUJWbXhpU0NYQjhFckVsbVMrUTdUbVgrREhWRmdnVHlJ?= =?utf-8?B?YndzVk95TWFVV1BPeXF2T2Q5WWswdTJGL2FBTVZlVUo0QVh2S2JTRkFLY0I3?= =?utf-8?B?TTh6ZjBKU2R6RDhYNzB5dytMMjQxSmJmVEVJZThGVitnSUhYS3VZQkxoTHhh?= =?utf-8?B?RngvT1MxWkJOdTZoRzlzbE85bHU4b2JBNk1FRHdnSTZkRUJDSkl0Rkt1ci96?= =?utf-8?B?eS9Id1hlM1lIYUZGSjhOYXpZVGQ3bVBwSUdXQ1lCdkU0eTkyeFFzM0NDbkow?= =?utf-8?B?aVJYbkFOd2ZzcFp4d2c5QkdMSDVTQ2RIQ3pFTjNKUHU4T3c3aUh2SHNIMlNv?= =?utf-8?B?d0tBcWdjUlpEZU5SYnZidz09?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR01MB1286; 5:CZ4wEOZ3He3SSL0P8/X71cjo7SOOLrOyRuDWwNJrcIC+ufyHTn29k/cG0n/bjIfMsoBYYUi/9MzwOMo+z6JZAoucbQYXRu1J+horgannc8MmG9IjQzx8PaNVAJ55k71mqzJuW+FIkunyMppKhR41sA==; 24:qz/ojut5VKPVclE0RvjD8YjfYOueceKiZiye2uTiQIWF+DYqgsyiwbCXEKOJXV+5WX7LprLEZJj4zmKNmVUhjFxmOpuQqHO8KDtLQeI9KIc=; 7:XfziCKPVd6K5r6QarA+WP2l0YX3nKeKUoMeqWkgd2WuoeSQGGR7rockS+aFPkp6137UrLHcujsPJHn4OHeUOYfoYHHpoJqeGCbswmQBeEQ4iGSHDfutdvQf1JkE3xLczfCKVUJif+e89tnWSdH/1Lb27lp1KCiwZYDxBq5M3EUO4YLquIpPk0NJJ4tJc3e9s; 20:qShuEzqRdO03+BGMVAXBxmzLRvUi0qbTkhFzguPoPum7XnJACZtYH6O0o9sikEwd4gisiX0HikkJiIyW5vBsdNWBHQPPtMwDawT8eMNAwrvTiZsBgsG/XgoJ2wFDHa7Lxl2EIht/VN7tBe5ZewoFA8dnUqUKa1Z7sKY0ktYjxnQ= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2016 21:46:44.8977 (UTC) X-MS-Exchange-CrossTenant-Id: eb095636-1052-4895-952b-1ff9df1d1121 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=eb095636-1052-4895-952b-1ff9df1d1121; Ip=[164.107.81.218]; Helo=[cio-tnc-pf04.osuad.osu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR01MB1286 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 21:46:57 -0000 T24gNS8xNy8xNiwgMzo1NyBQTSwgIlVuYmVhcmFibGUgb24gYmVoYWxmIG9mIEJyaWFuIENhbXBi ZWxsIiA8dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBiY2FtcGJlbGxA cGluZ2lkZW50aXR5LmNvbT4gd3JvdGU6DQoNCg0KPg0KPkknZCBhbHNvIGJlIGludGVyZXN0ZWQg aW4ga25vd2luZyBpZiBvdGhlcnMgaW4gdGhlIFdHIGhhdmUgb3BpbmlvbnMgaGVyZSBvciBpZiBJ J20gdGhlIG91dGxpZXI/DQoNCkknbSBzdGlsbCBhc3Nlc3NpbmcsIGJ1dCBJIHRoaW5rIGFzIGEg Z2VuZXJhbCBydWxlIHRoZSB3b3JsZCBoYXMgZGVtb25zdHJhdGVkIHRoYXQgd2hlcmUgdGhlIHdl YiBpcyBjb25jZXJuZWQsIHRyYWRpdGlvbmFsIHZpZXdzIG9mIGxpYnJhcnkgc2VwYXJhdGlvbiBv ZiBjb25jZXJucyBhcmUgbm90IHZhbHVlZCwgc28gZXZlbiBpZiBvbmUgcGVyc29uIHRob3VnaHQg aGF2aW5nIGEgc2VwYXJhdGUgbGlicmFyeSBmb3IgdGhpcyBtYWRlIHNlbnNlLCB0aGUgdHdlbnR5 IHNjcmlwdGVycyBpbiB0aGUgbmV4dCByb29tIHdvdWxkbid0Lg0KDQpNeSBjb25jZXJucyBhcmUg bW9yZSB0aGUgaXNzdWVzIGFyb3VuZCBpbnRlZ3JhdGlvbiB3aXRoIHRoZSBUTFMgbGF5ZXIsIHdo aWNoIEkgYW0gc3RpbGwgdW5jb252aW5jZWQgYXJlIGdvaW5nIHRvIGJlIHRyYWN0YWJsZSBhbnkg dGltZSBzb29uLiBJIGRvbid0IHNlZSBhbnkgd2F5IHRvIGltcGxlbWVudCB0aGlzIG9uIHRvcCBv ZiBKYXZhIHJpZ2h0IG5vdywgZm9yIGV4YW1wbGUsIG5vIG1hdHRlciB3aGF0IGxheWVyIHlvdSdy ZSBpbi4gSWYgeW91IHRoaW5rIHRoYXQncyBwb3NzaWJsZSwgSSdkIGJlIHZlcnkgaW50ZXJlc3Rl ZCBpbiBhbiBvZmZsaW5lIGRpc2N1c3Npb24gb24gdGhhdC4NCg0KT24gdGhlIFNBTUwgc2lkZSwg dGhlcmUncyBhbHJlYWR5IGFuIGV4dGVuc2lvbiB0aGF0J3MgcmVhc29uYWJseSBzaXR1YXRlZCB0 byBjYXJyeSB0aGUgbmVjZXNzYXJ5IGluZm9ybWF0aW9uIGF0IHRoYXQgbGF5ZXIsIGJ1dCBpdCBk b2Vzbid0IGRvIG11Y2ggZ29vZCBpZiB0aGVyZSdzIG5vdGhpbmcgdG8gcHV0IGluIGl0LiBJbiB0 aGUgc2FtZSB3YXkgSSBjYW4ndCBzdXBwb3J0IHRscy11bmlxdWUgY2hhbm5lbCBiaW5kaW5ncyBp biBKYXZhLCBJIGRvbid0IHRoaW5rIEkgY2FuIHN1cHBvcnQgdGhpcyBlaXRoZXIuIE9yIHBvc3Np Ymx5IG9uIHRvcCBvZiBPcGVuU1NMLCBidXQgdGhhdCdzIGxlc3MgY2xlYXIgYXQgdGhpcyBwb2lu dC4NCg0KLS0gU2NvdHQNCg0K From nobody Tue May 17 14:58:18 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF4312DA43 for ; Tue, 17 May 2016 14:58:17 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ycYSfeaIf9T for ; Tue, 17 May 2016 14:58:14 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B90E12D9C8 for ; Tue, 17 May 2016 14:58:14 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id x7so17038961qkd.3 for ; Tue, 17 May 2016 14:58:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+lkh2bUCc82Bhx9nWTAG4+0uQN2QDRoILqQv/1EtlQk=; b=rUc/HRzsjwEO/UTUNJ1jhh/wyH3DjyEUh6htz1qi5iokLg55jAbs53QOWPQO0nUiWX V9I/Th/L0wRYGDLkID2dvWb7FQG2f7NCUb1n9hBLoVlFa9C/OpbFiP9uP+JvBcf9m7G4 YAZP0m0khDz9KQckQ4kfmCn0pEJdny/mq7q8Yrz6TlcqB+P+ot2+IkBP9Z1XrfHTf7km mF+bz714m/MI0irqlOQ3kgxYFA6cYw0xGCGOvNU5srO//GQtJrLMIPZa2Z5CaNd0xzwp vgGSUkKx8zNEV3gWeMWcq5ozjHL/O+wW2E3O26fBBs+y2XpUQ7Q5Dd0fIqhdv1CO9D11 ZySg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+lkh2bUCc82Bhx9nWTAG4+0uQN2QDRoILqQv/1EtlQk=; b=KuL3dYsO6zqcAEJmBpKj9pqhtpuNuNX8oG6uIz74t9ADuYyODBVLVxcYOzd2Lfdu0w 791PzIzhItVwhqEVpF2zYTILSkLxiIggyqVeSuTYjKbqEwZJEcbfypRkE+B1CoYJiYKz r6LRTzygUDJC0s7rQ9hg0Lia6gQKUSgRyOHwPhP1FS+gz6xycPQSQuX6uttqgQgkRcr5 0fiwgxzoK6WK3QmQUbTHiql7kKMequ95l+xgqXky4dp3dOGAFYa+L2bVsWEE82fJXCgR l8DSoKCDrvOgl/Pa6BKP/du9rp7SIzsgez4T6oJcPqVFAmOuY0BKJmTHOUsd4qk7axTZ iwAg== X-Gm-Message-State: AOPr4FW0TpdbQGKUjxKbGd4B5I+xt3fpqn7kx27otoUNS0rtYUCV58905S0epjMKRxcGuw== X-Received: by 10.55.129.65 with SMTP id c62mr4321996qkd.171.1463522293538; Tue, 17 May 2016 14:58:13 -0700 (PDT) Received: from [192.168.8.100] ([181.202.159.13]) by smtp.gmail.com with ESMTPSA id b40sm2485192qga.47.2016.05.17.14.58.10 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2016 14:58:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Tue, 17 May 2016 18:58:08 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4EB8ABC2-9CE4-4A0F-B030-C3EAAC046DE0@ve7jtb.com> References: To: Andrei Popov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF Tokbind WG , Brian Campbell Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 21:58:17 -0000 This did come up at IETF 95. =20 I haven=E2=80=99t seen strong sentiment in favour of this proposed = change.=20 I have in conversations used the term =E2=80=9Creferred token binding = header=E2=80=9D to refer to the Sec-Token-Binding header containing a = TokenBinding with TokenBindingType referred_token_binding in addition to = a TokenBinding structure with TokenBindingType provided_token_binding.=20= It is just easier to say to get the higher level federation point = across. Perhaps I need to be more specific with some people:) If people have strong feeling s about this it will soon be too late to = do major surgery as we would like to get to the testing and interop = phase ASAP to get this puppy out ad doing some good in the world soon. John B. > On May 17, 2016, at 2:21 PM, Andrei Popov = wrote: >=20 > Hi Brian, > =20 > The current format, where all Token Bindings are contained in one = Token Binding message, provides useful encapsulation. The HTTP layer = does not need to know the details of the Token Binding protocol, which = can be implemented in a separate library. If tomorrow we define a new = Token Binding type, an existing HTTP implementation can carry it in the = Sec-Token-Binding header without modification. Only the Token Binding = library would need to be updated. > =C3=98 At the HTTP layer separate headers will make it much more = clear what is going on. Just looking for the presence or absence of the = Sec-Referred-Token-Binding header will indicate if a referred TB was = sent, which is very easy. > This can be solved by including a TB parser in the protocol analyzer. = Which would also provide further useful insights into TB key parameters, = etc. > =20 > =C3=98 Having a separate header for the referred TB allows the = client/user agent to always send the provided TB via Sec-Token-Binding = and not have to build a new TB message on the redirect request and then = go back to the provided TB on subsequent requests. > I don=E2=80=99t think there=E2=80=99s an optimization an HTTP stack = can do WRT building TB messages that a Token Binding library can=E2=80=99t= , and the Token Binding library is where such optimizations belong. > =20 > For the above reasons, I would prefer to keep all Token Bindings in = one Token Binding message. > =20 > Cheers, > =20 > Andrei > =20 > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of = Brian Campbell > Sent: Monday, May 16, 2016 1:22 PM > To: IETF Tokbind WG > Subject: [Unbearable] HTTPSTB: distinct header for the referred Token = Binding (issue #35) > =20 > It seems like github recently started sending some notifications to = the WG list but it's not clear how reliable that is so I'm gonna double = post anyway. The text from = https://github.com/TokenBinding/Internet-Drafts/issues/35follows.=20 >=20 >=20 > As mentioned at IETF 95 I propose that the referred Token Binding be = sent via a separate header (say Sec-Referred-Token-Binding) rather than = as part of the Sec-Token-Binding header. >=20 > At the HTTP layer separate headers will make it much more clear what = is going on. Just looking for the presence or absence of the = Sec-Referred-Token-Binding header will indicate if a referred TB was = sent, which is very easy. Rather than having to decode the = Sec-Token-Binding header value and process the binary content, which is = possible but much more involved. >=20 > Having a separate header for the referred TB allows the client/user = agent to always send the provided TB via Sec-Token-Binding and not have = to build a new TB message on the redirect request and then go back to = the provided TB on subsequent requests. Also not having the value of = Sec-Token-Binding change (other then a new TLS session with new EKM) = should make it nicely efficient with HTTP/2 header compression. >=20 > I also believe it will be easier to covey the concepts in the text of = the spec. Talking about when the Sec-Referred-Token-Binding is sent or = not sent rather than talking about when the referred TB is included as = part of the TB message that is sent with Sec-Token-Binding seems much = more straightforward. >=20 > Anecdotally, there's been some discussion about using TB in OpenID = Connect and and in talking about it people often say "the referred token = binding header", which isn't accurate relative to HTTPSTB-03 but belies = the fact that federation folks already think about it as separate = header. And I think that's a natural way think about it so it's not = terribly surprising. I won't name any names but one of the chairs of the = WG is among those who said "the referred token binding header." >=20 > I realize this is not an insignificant change but I strongly believe = it'd be a simplification and improvement for HTTPS TB. There's not yet = (that I'm aware of anyway) any profiling of TB for federation like = protocols such OpenID Connect, OAuth or SAML so this would be an = opportune time to change how the referred Token Binding is conveyed. > =20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Tue May 17 15:06:30 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7FA412DA92 for ; Tue, 17 May 2016 15:06:28 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pq7I7gDYZMtA for ; Tue, 17 May 2016 15:06:27 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E743112D538 for ; Tue, 17 May 2016 15:06:26 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id n63so17160861qkf.0 for ; Tue, 17 May 2016 15:06:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mF0WXuSMzdyzSNbZ8Dtx5+AvMjhiWIkl0iSNVO7DGF4=; b=Ab7xejiNevi6/hE/XCEaKtFHdK3+VpnnUzHcstYW74mInIJ04mdhMCSvf9dKeEopMk U+4XlhxaEYRYx9Bhaz/lG7Vifys1yto3HFdAx04VsO/UCmekR2Jy3/9hkkGUhC0LZP7w FHlUMQ9je/MOw3FNcN7t6hADooX131nvXEuS8Z2zUhlsZAsSVFVF1RG0ifaqAHvD85qH f3XH2ZK6ZWFS/Ju6riAMqaJ0FKG5UDNuUMJO9deH+jUo7q03wacsdQmoyzS76Yzi4ADK X13KcxjM4iaBqdjHvQ6HR4DdpM6SVjSrvBFVg8TjzfZ84p7Lk0wl+u9EwaDwurNFy35f JSWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mF0WXuSMzdyzSNbZ8Dtx5+AvMjhiWIkl0iSNVO7DGF4=; b=PC33r/XA3X5bvAGFeq4gxR4qJzIU6LNtx/xsvToZyxD33CN0ksJJegxpmZAw/EZLFr fklhV7aJcMROtx0ygV7EL34DbXsx1oeed1H4T5uNkPT/sClhrojEGV00NvaPWUnZggR7 /mUY4SHFraPiI9vB5F4Nj2K+m/fNTr+/nLUHJm8fa6+jtncN6Pb6g8GDCO7O4Sg42z2e OFykWbTqix2q8ctgI4ohT3jDpmBSoIekveVHs2vb8FRj0waqiZDuSMIVoHVzr0AwEntH TWXFgAQ1O3QYfOKlkfdFYL0xTCcEX7QCyYz4HEEdDlBGgVeKYg2HqjNpFfKEUiyUpmep uvRA== X-Gm-Message-State: AOPr4FWEvZGaoFx3QzhK6fNmcxZgQhLbWjDsrQMj7nz9B+1PgFTcV3hPbNnKx0Ew9YHiFw== X-Received: by 10.55.189.132 with SMTP id n126mr4598407qkf.117.1463522785882; Tue, 17 May 2016 15:06:25 -0700 (PDT) Received: from [192.168.8.100] ([181.202.159.13]) by smtp.gmail.com with ESMTPSA id y60sm2514746qgd.10.2016.05.17.15.06.23 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2016 15:06:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Tue, 17 May 2016 19:06:20 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Scott Cantor X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Andrei Popov , Brian Campbell , IETF Tokbind WG Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 22:06:29 -0000 Good point Scott. We do have commitment from the browser venders, but that doesn=E2=80=99t = help much on the server side. There is a python test server as part of Chromium but that is based on = libs not commonly supported. Roland Headburg is looking at how Python = support can be added. There are people looking at what the best approach fro Java will be = (Including Brian) We will also need coverage of other platforms and support in reverse = proxies. I understand that this is not going to be an overnight thing.=20= The sooner we lock down the spec and get the tooling going the better. PS there are also iOS and Android libs available for native apps, as = well as win 10 needing a update to support the current version. John B. > On May 17, 2016, at 6:46 PM, Cantor, Scott wrote: >=20 > On 5/17/16, 3:57 PM, "Unbearable on behalf of Brian Campbell" = = wrote: >=20 >=20 >>=20 >> I'd also be interested in knowing if others in the WG have opinions = here or if I'm the outlier? >=20 > I'm still assessing, but I think as a general rule the world has = demonstrated that where the web is concerned, traditional views of = library separation of concerns are not valued, so even if one person = thought having a separate library for this made sense, the twenty = scripters in the next room wouldn't. >=20 > My concerns are more the issues around integration with the TLS layer, = which I am still unconvinced are going to be tractable any time soon. I = don't see any way to implement this on top of Java right now, for = example, no matter what layer you're in. If you think that's possible, = I'd be very interested in an offline discussion on that. >=20 > On the SAML side, there's already an extension that's reasonably = situated to carry the necessary information at that layer, but it = doesn't do much good if there's nothing to put in it. In the same way I = can't support tls-unique channel bindings in Java, I don't think I can = support this either. Or possibly on top of OpenSSL, but that's less = clear at this point. >=20 > -- Scott >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Tue May 17 15:16:10 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2299712D538 for ; Tue, 17 May 2016 15:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=buckeyemailosu.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDkmX-JuG5gr for ; Tue, 17 May 2016 15:16:03 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0147.outbound.protection.outlook.com [207.46.100.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD2D12DA81 for ; Tue, 17 May 2016 15:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buckeyemailosu.onmicrosoft.com; s=selector1-osu-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fD4odWqdWt1I9y4eGYikehTbKWwfwzdVzFnAd/ONTss=; b=G8HfJL0629CbRhUEXULTwcg7VRT6c7DLbyT//rsLm3RhOMihTnvAnGZNGljizMSJU2YupnnZxEhRfKyjDtd5mz87wUH+x8XrWTfK68OCLv2xQzPNx6/Qz1NttkDnlMf93ysJvGjCUP+vYbg6NbDuz6aGpICCMRpBoR4xJDjhL8Y= Received: from CY1PR0101CA0026.prod.exchangelabs.com (10.162.170.36) by BY2PR01MB1928.prod.exchangelabs.com (10.166.109.28) with Microsoft SMTP Server (TLS) id 15.1.497.12; Tue, 17 May 2016 22:15:57 +0000 Received: from BY2FFO11FD011.protection.gbl (2a01:111:f400:7c0c::119) by CY1PR0101CA0026.outlook.office365.com (2a01:111:e400:51d0::36) with Microsoft SMTP Server (TLS) id 15.1.497.12 via Frontend Transport; Tue, 17 May 2016 22:15:57 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.214) smtp.mailfrom=osu.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=osu.edu; Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.214 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.214; helo=cio-krc-pf07.osuad.osu.edu; Received: from cio-krc-pf07.osuad.osu.edu (164.107.81.214) by BY2FFO11FD011.mail.protection.outlook.com (10.1.14.129) with Microsoft SMTP Server (TLS) id 15.1.492.8 via Frontend Transport; Tue, 17 May 2016 22:15:57 +0000 Received: from CIO-KRC-HT02.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1.2 with cipher AES256-SHA256 (256/256 bits)) (No client certificate requested) by cio-krc-pf07.osuad.osu.edu (Postfix) with ESMTPS id B38A4500074; Tue, 17 May 2016 18:15:55 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.03.0248.002; Tue, 17 May 2016 18:15:44 -0400 From: "Cantor, Scott" To: John Bradley Thread-Topic: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) Thread-Index: AQHRsH/wUZPFP+71UkmQUk1veolL6Z+9mWgAgABZVQD//67NgA== Date: Tue, 17 May 2016 22:15:43 +0000 Message-ID: <838CA767-4DBF-401B-B072-0262C82158E8@osu.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [162.244.106.216] x-header-sapphire: true Content-Type: text/plain; charset="utf-8" Content-ID: <3CF313472E963848824839D010949394@osu.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:164.107.81.214; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(24454002)(377454003)(189002)(199003)(36756003)(5003600100002)(110136002)(50466002)(16796002)(5008740100001)(87936001)(6806005)(90282001)(19580405001)(2950100001)(92566002)(5250100002)(8666002)(189998001)(19580395003)(88552002)(89122001)(54356999)(106116001)(76176999)(50986999)(75432002)(8676002)(93346002)(47776003)(8936002)(109096001)(106466001)(2906002)(3846002)(1220700001)(4326007)(6116002)(102836003)(586003)(5004730100002)(11100500001)(33656002)(86362001)(23676002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR01MB1928; H:cio-krc-pf07.osuad.osu.edu; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD011; 1:6DJe3GQZhEi2Nhujqi3VmFl0arn2VUYMLqatC2Sn7V4swc7sXjEze7/ceLkeYzT8egHLvidSlbLC2e7lYmPjLln4rjrJ5yj82OjvzLkgzIjeiZEqfOCvDSbRVvw4MtK9rfo+cNozNLY2K8dzYSinN+vP1FKtRvxFXv1kcdRRjoRGDVejfCErZnJGdDBeJYpKOTPeicJv1FbjZXHw/r5ZZz36OdrBloCseSvObPl+0OmQz/aBVk5O90vDC+bMPqZZ+5JY/Wh9pp9F307NvMZfpWnTP1IFVDaMRvV9Im7JirSu8FFsEH7qHXLbC7a9pmRVwpkV4TnZw/T7A86slkY2ZywiIfTt8F5YOpp5Mq8iGxDbrvVb5xyd1EiAFOTQkI7GKFl5H3cYPg2dn2AMJ4B0/YmXQtBJUwTr9e9Gt+hAHRutLnyZ/6bsiXg1vAhg5Z7PnrlW4M97+TWumHZlfbq8l1VacqStSuQ4m0yjIIqufJdkEWJHSO2ZE3Exlsu/4QoHFhgnb5wXfZ0be1XAZrMQw/jkPg8Ya0KBdGPRS2nOOKEhHi4f6Wipc4AeZ0KhGPCf X-MS-Office365-Filtering-Correlation-Id: 0403562f-a62a-40b2-f8df-08d37ea0d20d X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1928; 2:wQxuJrAKOQGF2aRLVVNLd8xs7Eyf5sM9SmmsZ3+ULx4kSqVclIdJCA+RRmMhE37Rf9pJ30ILYxy9JYVpbghw8wg93s4q7MOc7ORDyT57AS8zQs7Y3MUm/3zbj5LqVVrXMEAq4C/Qxtui2/6kSyXezrD7wCTN0XEVfpJZZYmHIjzJSXlqTCTSnsdnfpwj5bbP; 3:EaHxNJSDnRzqzHYtGt1jYjkKPaZhDtvw0NSAtMXCUR30dYrzXeypbECbcLwYoXgeZD5Red4Dhi6MxnyIt2fubez5W/sRLS1Mcmmbssx9HQL6HQ6XwzP9WdDu0Z2ibD4ZkcoY7N9DZxlYy8lc/mB7RoLC6qG5nwdFFngMryOW9TLzDF924JJXgiHMfwNJOnQjRBQnprGX2/CrIvXCfIMH69hAhEY6lxHV/0EXOSRvDGcMpgKR+6rou+x8uhkVkU1EVmmZdZRhAi669ELHyNOO6A== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BY2PR01MB1928; X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1928; 25:xC9ppX73JVtSYhsbpMIuouspb9KdnOn39z3t9m2FwE1hDz16ULEYtLr/1QoCRzDd0fJ5YkI/WjBOHMsm1cPBTsy5zRjfSbghSxs3kF04aC0iIioS7IyhXJy5pRC1gjMJSqa/St2qsZmMJ83EgUCW32FGhXIyxAyJcTrsMWT9nu/dDAl1qoXiFM+Dzc09YtRkIEcNFOsW8qDV6RcFfnI0i/zQlMhlLNQ3aPltTJLtoOmgEBMCl5EE/mAsqoBeBiIe+G5VdIl+vNo1yUDDrgmMYWd7lsBlmDgB8BzBjGvElUTw/E3XCQ9PD1rIq1h4Ar260+Cju3UA0eEUifYQ9rmjtHLeeXYUNa5WalB0g/dA6C5U79N/uHEVWZrJwnz6b7XwSBmmrR3xCIIB90Q4nsq7lTv4v2ScWJk/NaRSwbMLmU8M6cFLnP+vUE9kbvlrbEbLt0oRj90io5nRg6b07WA8p2VIWbbgIZtE40ya4oVO40tRopzt7gYldhAxLZX6QygVN07rzCLIBSd63oBmdflSAKHGaL3mmAp7ttbNTAar8yXG06YmSTFmvNQy3DUPOceJhmd8+nWBaegZlePKbtfwHnE2r285NhTjO80IDBf2mln5Fk+ABz7hpACyzFcMOxE7Yn6BqRbRi/3J26b58AeBjgxoydEjB2wzbIXfImlhqa63eQimenPHuHCjnvym7cT+UVKBpBxBdcmC5e77WnkOy1pT+4VJWzgSxUuTy9kBShuiwHOIYJSsbXdT861uAQ84wo7nIJ9eatw4GOymDUsxgw== X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1928; 20:pwScsT80b+EQCQgkm5/VhF+DpwtYx0vHgr0+yz20ynmaEYT0Y6ylk6XhCNUxcuTKHFizKDFtnPCnle41EkcIjlNqj3Fe2kqa5Ev0ivoGHzePQkih7JutlRgvLzGkNIpeN0afVqNbP6Mava9gRnjkUnwp9un85z+d43o5lekjWu50krIrJ/aTYKvqPyK5l7Vmw79uq22+nf0drhpoRMxAYldLuVdzC60ZLx5Wsme+HMyeTxabngsWzqr8jEEwfDKjWB4REMGEdJG7ZJf6Qk6T7CuQYSznQUKCFiab1xgk7SOMqxgdexzCUKhGc6UHqn6ViOvQxGPJocVdbxIWuRpz0M72r/PdV4y7PmmNBMRj5AcNRK5OsfGM3KHUd0iQ/Qr2UBxvMMh6e0NYugFdIa0OrKVKD2AeCCEKot4gz2NATf2gWCDnMeUUVcciqojXmdVjmlu0x/f8ZpbOAlQsbh3LsDku4TV/vslYH2EvGywKi0KCZCv3aKmw3/51tvhsqCJ/; 4:8WQq5/XwOsRFt6xCE4eE5gxeuf1y3lbEzP0Ug9OC1cZMuwaoPeuSZiPkkny7LDwALNfYWuza50zCTc7FcyAfv5Ehkba/Oh7yTWm36UZWvm3X+iYj4XXKsI8Lb2LKvTxRUhAFHPyeLW6/Us123g5ZIyHwdD8HtmAjrevbtgzYgdcU9VugROA+nEq6zdSjk9B7F7CRc91AipUvS5xxiqx9GtjnCIbtjcjpQWKnW0ADtCNXOLtBHCSSSILLzNfZWIe507isYeZfVHZaSMt7CDcH5/a2pL7yRNFz2QXejo2mAuIkFfeZEPxWFZAxPBWIJ6laHi6P7WVvuYY5LLWCdb9Gse7PJGmQk0uLt14+QKljN/IH0no1kTZGvKLnVPfRRx7QrqW6Ylmi6x4stUI6OOPE3W+/5XG0Vlrt/af3hTsYYigS89GDXISJCMAXH8I7DHnc X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(13017025)(13023025)(5005006)(8121501046)(13024025)(13015025)(13018025)(10201501046)(3002001); SRVR:BY2PR01MB1928; BCL:0; PCL:0; RULEID:; SRVR:BY2PR01MB1928; X-Forefront-PRVS: 0945B0CC72 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjAxTUIxOTI4OzIzOkhWV1p2dWVnVHh4WTZhVnJibDBUMGYyZkZR?= =?utf-8?B?TDY0dTI4K1ArekF6eTc1MVA4cFgwTXhwT2Q5OGxxT0k5VkZLQjBuRGNid09Z?= =?utf-8?B?dWdVVUlrU1JtczVBZXhPckVjQy83N2pTVmpWZy8zZ1gwK0VmZ2hqcThVek9C?= =?utf-8?B?c3Q5ZlpPWkx1OXhURGIya205Z3RuSEx5Qk9jTFRtS0xINks3RjdjRmtjUVpP?= =?utf-8?B?RTJ5eEhLVEl5ejM4YUxFbFVEdGtwZjJ5cXVZQWZFMHZENTVSV3YwL003WHJ3?= =?utf-8?B?N0xkUkhJdlZHbkp2S25Fa29Bd05yNnltTlpyVVk0UjZ1Y0JBaHZQaytiTDVU?= =?utf-8?B?a3gxaVkyQzBGODF2eXMwOWx3N2JiSXhIWldSMnJlbGtwcURLZDlWZ2tvb2dP?= =?utf-8?B?VlR5bmQ2dkZOZUhnaVRxU1ZtKzd5UFA1UU1VYStEaWhXSFRzNm1iYVNva1pj?= =?utf-8?B?emMzRXZ1V2I5eG9ScWd0dmNwcFpvZUx5L1dxK1BCU3BZelhTQUw4Y2JKZnIx?= =?utf-8?B?TG8rM2MwcWVJbkNDZ25mblJzaUFQZFcvK0RnaWd6WWhVb3FFd09maUdLK0Vr?= =?utf-8?B?U3dFblR2bW5va2lkeERydTBrYnNnSldxcDROZ2xKdkQ5ZGwrT2kxQU1iU1Jj?= =?utf-8?B?NDlHTE9NRmVnT3BwRnlVSm5zYnR1dkJvUGUvUkptNnRUejF6T0s3a0RiU09o?= =?utf-8?B?M2IvcU85VVUyKzdYdmRHR1lTTVZNLzZwUTZuenVEYUZjejNBUUJHTHBkTHNK?= =?utf-8?B?RUc5R2tNOTJCODBZclhTQ0RMcXVuamxNRFdyWTd6TWNienVnVHN4QVNrTVM2?= =?utf-8?B?NU90MStOMm1oQVFNRHl5RERwZWRUOHdmZ0RzTmRBYlplN2xySW4vbVlFRnEy?= =?utf-8?B?Z2JxbFJYcXZWS2k3bkxzbmd2aFZNd1RkYzlQNFZaSzQ4amsraTFndXY3cE9I?= =?utf-8?B?Vmt4TmhyVFEwV0RqWHZ0TlVMQmUzRWdHTHZvdlRtTk1KWCtCYTNxcHhCUzM5?= =?utf-8?B?SnltV1NWUlJIclBlTTB1c0xHYVQrK0MzaG5BbTE3c1grZ0VQVysvV2huQVpu?= =?utf-8?B?RzQ3MCtXNS9xZmZad3o4WUprUUxEZzJwM2dqOGowWU90SmlielgzeHFyYXJI?= =?utf-8?B?ZmxCQW5ZTzczZlRwYUtyUStiV1dXbkI4ZjUrcnpuMStST1V5Rm1oV0lQV2Ux?= =?utf-8?B?RktaLzdsQ056bDA1QkE1Yk5pMmRocnBFakp1M1VQcXU0c0tNYWw1emF0K0Uz?= =?utf-8?B?Si9zZlUweDNPLzEwZnRSUFJ5d3VWUGk3alhGM0hmSWhtZXZIR1pNZWF3NkdH?= =?utf-8?B?VmZ4OXZxZ0ZXeGhNNDJycStJYXNoNjdYM0o1dVVjUE9UZXBJMzRxdGIrd0Jx?= =?utf-8?B?VEYwRC8vc1FhNUV3dUQ5OEpOOG5nZWpGYlZXY3p4K1gzU2VyamxyZElPUWRn?= =?utf-8?B?b2VZNlI4Z044cjZVWHRNTTVWcTlCUTVjdnV3T1Rzb2xNQmVRcUcxa2lXL0NG?= =?utf-8?B?RHJJN0I2YWdGSmgzWGpYaVZ4eE5mL1pEVWovSThocHVqS3ZLVDF5STJDMDk1?= =?utf-8?B?QzExZDhhNHVmRHNqMCt5QkluRjdQSFFxcW4rZVpuODVKVDQrY0xvWkd1Zk9J?= =?utf-8?B?aEM4eXFXaDVoQk1JNFNkWDc0Q3k3L3NUSlN6M3BraWV3U3VTZnZpcVFHQkQ4?= =?utf-8?Q?wgo0jjfBPWuXdNMgwY=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1928; 5:wSsLWniGkxzVLh8KDB26VcKryXpdo5BnXzA+XZ6WHJkSYKh0mgq9KmLG93ka/Q2yDxXSIJHltrsFz109XLMLOYzBazM6kQjyMO1TpUL+I7g3bmS9kN0sn4aG79xjjJpAD+jdaddeA5n1UCPKQzIBNA==; 24:aFq3ZfTq3swYtVTITLubPkcWDwtVmW8mY6RNL3rOb559kIUSDC1ErHP/qxvtlYBLz9OZiNwHwTHXxppK6Uyrc6iXnKfAd01W5TivNIvvdEQ=; 7:HwO+ZGpZFZaL+yh0aulAhLE3zWS4vTwbpiCPQ8WGMJhtJVtk+v5tiC8QirZkcXTF02w8+uqY2lX8DIeWo1PIFWuyXT+Ru+3FqpN67tEcJiK55nn62LXRCpD5dK5cDrDs/nJuwdE560TFoVIfjnZpVp0/SbAthQStBId23U3TQDpjbBVcGDwHo8lixiDLl+Mw; 20:W07gkIi8B7aruiz3x5l8elqppfsPJXqthxZwpyqCdYMkItBf1tjDoCUia7Pd9oj7kip6rmonVOXjzn8xJ4XXnVa6ZiFm0hk31flIGpKHeeMVhoGgFbqGGCyk4ZsBuOThg/bYPgBLKDgwG1M+KnKYxt8IJmLi+EpcIfWQGTJ6V1g= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2016 22:15:57.1654 (UTC) X-MS-Exchange-CrossTenant-Id: eb095636-1052-4895-952b-1ff9df1d1121 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=eb095636-1052-4895-952b-1ff9df1d1121; Ip=[164.107.81.214]; Helo=[cio-krc-pf07.osuad.osu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR01MB1928 Archived-At: Cc: Andrei Popov , Brian Campbell , IETF Tokbind WG Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 22:16:06 -0000 T24gNS8xNy8xNiwgNTowNiBQTSwgIlVuYmVhcmFibGUgb24gYmVoYWxmIG9mIEpvaG4gQnJhZGxl eSIgPHVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgdmU3anRiQHZlN2p0 Yi5jb20+IHdyb3RlOg0KDQoNCg0KPldlIGRvIGhhdmUgY29tbWl0bWVudCBmcm9tIHRoZSBicm93 c2VyIHZlbmRlcnMsIGJ1dCB0aGF0IGRvZXNu4oCZdCBoZWxwIG11Y2ggb24gdGhlIHNlcnZlciBz aWRlLg0KDQpZZXMsIHNvcnJ5LCBJIHNob3VsZCBoYXZlIGFja25vd2xlZGdlZCB0aGF0LiBUYWtl cyB0d28gdG8gdGFuZ28gdGhvdWdoLg0KDQo+VGhlcmUgYXJlIHBlb3BsZSBsb29raW5nIGF0IHdo YXQgdGhlIGJlc3QgYXBwcm9hY2ggZnJvIEphdmEgd2lsbCBiZSAoSW5jbHVkaW5nIEJyaWFuKQ0K DQpJIHdhcyB1bnN1YnRseSB0cnlpbmcgdG8gZWxpY2l0IHRoYXQgaW5mb3JtYXRpb24uDQoNClNl cGFyYXRlbHksIGhhcyBhbnlib2R5IHJldmlld2VkIHdoZXRoZXIgdGhpcyAqaXMqIGFjdHVhbGx5 IHN1ZmZpY2llbnRseSB0aGUgc2FtZSBhcyBHU1MgY2hhbm5lbCBiaW5kaW5nIHN1Y2ggdGhhdCBp dCBzaG91bGQgYmUgZGVmaW5lZCBhcyBhIENCIHR5cGU/IEkgaGF2ZSBub3QgYmVlbiBhYmxlIHRv IGlkZW50aWZ5IGEgbWVhbmluZ2Z1bCBkaWZmZXJlbmNlIHRoYXQgd291bGQgcHJlY2x1ZGUgZG9p bmcgc28sIGFuZCBpZiB0aGlzIGlzIGdvaW5nIHRvIGdldCBpbXBsZW1lbnRlZCwgdGhlbiBpdCBz aG91bGQgcmVwbGFjZSB0bHMtdW5pcXVlLCB3aGljaCBoYXMgbm90IGJlZW4gaW1wbGVtZW50ZWQg KHNpZ25pZmljYW50bHkpLg0KDQpTZWxmaXNobHksIHRoYXQgbWFrZXMgaXQgbW9yZSB0cml2aWFs IGZvciBtZSB0byBkbyBsZXNzIHdvcmsgc2luY2UgQ0Igd2FzIGFscmVhZHkgcHJvZmlsZWQgZm9y IHVzZSBpbiBTQU1MLg0KDQpUaHgsDQotLSBTY290dA0KDQo= From nobody Tue May 17 15:31:04 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B2612DDE7 for ; Tue, 17 May 2016 15:31:01 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCwAAuPFH4BI for ; Tue, 17 May 2016 15:30:59 -0700 (PDT) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ED9312DAD5 for ; Tue, 17 May 2016 15:30:40 -0700 (PDT) Received: by mail-qk0-x232.google.com with SMTP id n63so17449337qkf.0 for ; Tue, 17 May 2016 15:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ufZ5EGSkZS60uKbPHv+u2QeuMtenal9URGwgnbPFEgA=; b=iTRWma2fM5A9+tVVNeGvaBDBUY11bKuTmOeeL/gvOdp57yiaZa1602OOzWdb54V2/v W3BmgkL8x9220VMxyozs66ZK3OidGVHZAw1yJSkfKdMyrEo8TYmAh20WLb70hwDUSpQg 6W/HAK4PmzkXRjofPJ0PMvH0VPWaS/AK5Ik0Y64e5UIL+rfhdYSSLyAm1NMXqKxebBjf lbXXw5WJ+4Tgr7qLJoCvlNPAnAmb4ut+qTntUz8PfezurFcYVvPM9IagGX8RXb6aClhk KW7bmEiX1K2Me1+1U/mIeLVOuKRx4CN32OKNVEWMY3QqmsmvH4cl589I7ZMEA6jtpoKu DeQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ufZ5EGSkZS60uKbPHv+u2QeuMtenal9URGwgnbPFEgA=; b=VN+R+1BTWmUXTI7XEV3EclgrKaDNT+VyvrKQgvFTLfXlq7u9wqRRWy8Og72iuny39V JJyQOJwCQgk2rCCCuCLtY8SVLnVZ9ZEPHCGcIJZHjsiy5eAZ+fCO58435oZcVpIPbMSY NrcCFFmcbp0TH3LEJHmYLiHcWOCb/R4WLQDPDlcdvK6iNnSbT2625sVSKxRU++tkgs9X 7cmRYME4u6WrEjZcDaXyjnS2q285WtUIwCe50SRuq+YYeFjSx/HG/PIYEb/30PVksjQf AkL384SnSST1wESn9FwEFsc+MlMI/m7EEUk/QDGsFHQeXBv7AIvsUPPTWVG5kDT2jqbh xpeA== X-Gm-Message-State: AOPr4FXAfpmYkQ1PKYUUadYqE5vgCAYsxzrf5cxvNEEFmXS11kUW9hejTeXktsJXFR7zWw== X-Received: by 10.55.10.130 with SMTP id 124mr4567693qkk.91.1463524239242; Tue, 17 May 2016 15:30:39 -0700 (PDT) Received: from [192.168.8.100] ([181.202.159.13]) by smtp.gmail.com with ESMTPSA id 90sm2568892qgh.28.2016.05.17.15.30.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2016 15:30:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: <838CA767-4DBF-401B-B072-0262C82158E8@osu.edu> Date: Tue, 17 May 2016 19:30:32 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0FCCDAB0-D6DF-4329-B5EF-71611CA5216A@ve7jtb.com> References: <838CA767-4DBF-401B-B072-0262C82158E8@osu.edu> To: Scott Cantor X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Andrei Popov , Brian Campbell , IETF Tokbind WG Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 22:31:01 -0000 TLS unique is insecure. That caused some changes to token binding to = require the key to sign over the EKM instead. The token binding ID is a public key that signs over a EKM (formerly tls = unique ) and is placed in a header to give the readers digest version. GSS-API is not HTTP so we would need a way to replace the HTTP header = carrying the token binding message. This may be relevant for OAuth over SASL RFC 7628 where you want to = token bind a OAuth AT over SASL from say a mail client. =20 I suspect there are issues that would need to be addressed as I don=E2=80=99= t think that it is a drop in replacement at the federation level.=20 That might be the place to put it after everything else is sorted. John B. > On May 17, 2016, at 7:15 PM, Cantor, Scott wrote: >=20 > On 5/17/16, 5:06 PM, "Unbearable on behalf of John Bradley" = wrote: >=20 >=20 >=20 >> We do have commitment from the browser venders, but that doesn=E2=80=99= t help much on the server side. >=20 > Yes, sorry, I should have acknowledged that. Takes two to tango = though. >=20 >> There are people looking at what the best approach fro Java will be = (Including Brian) >=20 > I was unsubtly trying to elicit that information. >=20 > Separately, has anybody reviewed whether this *is* actually = sufficiently the same as GSS channel binding such that it should be = defined as a CB type? I have not been able to identify a meaningful = difference that would preclude doing so, and if this is going to get = implemented, then it should replace tls-unique, which has not been = implemented (significantly). >=20 > Selfishly, that makes it more trivial for me to do less work since CB = was already profiled for use in SAML. >=20 > Thx, > -- Scott >=20 From nobody Tue May 17 15:36:10 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB74412D537 for ; Tue, 17 May 2016 15:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYUU8nUudTsE for ; Tue, 17 May 2016 15:36:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::764]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1235D12D51C for ; Tue, 17 May 2016 15:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TGeR1VGTE9MJkwekcrDfTzkVgKD9TfJuuCWDD6+M248=; b=YvPojaoW5DrGEX/gYa2W7ucu3OscOxVLLYlXgFiNdwL1Q64+0U07NZ/hnduFJgPfoHak8fKp7B8RIDf4aXWdoNEDJYL8fbyK+vN7q4ZL26aZHSFZ5RrLUVSt3vW5y0jB4C2QJauNK/oJ+kmxdKmWoGW4uaa23q2J3OQUxoNrc3w= Received: from BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) by BN3PR03MB1448.namprd03.prod.outlook.com (10.163.35.11) with Microsoft SMTP Server (TLS) id 15.1.501.7; Tue, 17 May 2016 22:35:47 +0000 Received: from BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) by BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) with mapi id 15.01.0497.019; Tue, 17 May 2016 22:35:47 +0000 From: Andrei Popov To: Brian Campbell Thread-Topic: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) Thread-Index: AQHRsH7NJR2mVJvqxkCfe/+qylCsN5+9nfOw Date: Tue, 17 May 2016 22:35:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:f::1d2] x-ms-office365-filtering-correlation-id: ae05f2ec-090b-44cf-f610-08d37ea3973a x-microsoft-exchange-diagnostics: 1; BN3PR03MB1448; 5:pHzgFqQ26S7Ul1QKyJoFad+unmWveO9iOorj8fc0RyqU9euIrhg/fwefkKEUgR66FV6rTJ2tqZpapCbFUxd+XYesbHoiCH2yhlgYUFLuW1Z6iqiMIbI9bRKLdyiIRa/T7ip5B83snB6sZYIoV3ifSA==; 24:S3iobdBjL9d7CuiIuxqrEBvQYKvzXrbyHaqpxtXYcjy4fvsv/eFCGMHE+G7CPkf9xUpM+c8rV+CvePbKYclBRrWFeeXim9HRLGAnQdV6bbQ=; 7:62yE9Hjs/tMEuPRQ0M2eSp12gQM3nXJPM81eedxT701AoFhttC5O3wGx2xKBUC5xS/WQklAGy0zFg6Oj464K+PBxxrRVWrDWFM4sS6iz3xNWy+TAfbALXXSq9EAo+xnOUj9zUMqytdrihXVvx1fONUgdMp1aBMhZye5RcEMkiYKI857pOw7ltQhIxnONcZLgoWevVemXoQW4Kx4BuDhyUg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1448; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN3PR03MB1448; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1448; x-forefront-prvs: 0945B0CC72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(377454003)(2906002)(122556002)(19580395003)(19580405001)(106116001)(586003)(102836003)(6116002)(2950100001)(790700001)(1220700001)(5008740100001)(99286002)(4326007)(92566002)(15975445007)(87936001)(74316001)(77096005)(76576001)(19625215002)(33656002)(10090500001)(11100500001)(5004730100002)(8990500004)(5002640100001)(10290500002)(10400500002)(5005710100001)(16236675004)(5003600100002)(8936002)(3280700002)(9686002)(3660700001)(110136002)(189998001)(19300405004)(8676002)(81166006)(86362001)(54356999)(76176999)(50986999)(19617315012)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1448; H:BN3PR03MB1445.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB1445B30EF30B69B5F51564078C480BN3PR03MB1445namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2016 22:35:46.8864 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1448 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 22:36:08 -0000 --_000_BN3PR03MB1445B30EF30B69B5F51564078C480BN3PR03MB1445namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIFRoZSBIVFRQIGxheWVyIGRvZXMgbmVlZCB0byBrbm93IGFib3V0IFRCIGZvciBUQiB0byBi ZSBvZiBhbnkgdmFsdWUgLSB0aGF0J3Mgd2hlcmUgdGhlIHNpZ25hdHVyZShzKSBnZXQgdmVyaWZp ZWQgYW5kIHdoZXJlIGNvb2tpZXMgYW5kIG90aGVyIHRva2VucyBhcmUgYWN0dWFsbHkgYm91bmQu DQpXaXRoIHRoZSBjdXJyZW50IFRCIG1lc3NhZ2Ugc3RydWN0dXJlLCB0aGUgSFRUUCBsYXllciBj YW4gc2ltcGx5IHBhc3MgdGhlIGNvbnRlbnRzIG9mIHRoZSBoZWFkZXIgdG8gdGhlIFRCIGxpYnJh cnksIGdldCBiYWNrIHZlcmlmaWVkIGJpbmRpbmdzIGFuZCBhY3Qgb24gdGhlIG9uZXMgdGhhdCB0 aGUgSFRUUCBsYXllciB1bmRlcnN0YW5kcy4gQW5kIEkgbGlrZSB0aGUgZmFjdCB0aGF0IGN1cnJl bnRseSB0aGUgVEIgbGlicmFyeSBnZXRzIGFsbCBhdmFpbGFibGUgVEIgaW5mb3JtYXRpb24gYXQg b25lIHRpbWUgYW5kIGluIG9uZSBwaWVjZS4NCg0KDQrDmCAgQnV0IG15IHBvaW50IGlzbid0IHRo YXQgaXQgY2FuJ3QgYmUgZG9uZS4gSXQncyB0aGF0IGl0J3MgcmVhbGx5IHVzZWZ1bCB0byBiZSBh YmxlIHRvIGxvb2sgYXQgSFRUUCBhbmQgdGVsbCB3aGF0cyBnb2luZyBvbiB3aXRob3V0IGhhdmlu ZyB0byB1c2UgYSBwcm90b2NvbCBhbmFseXplciBvciBUQiBwYXJzZXIuDQpVbmRlcnN0b29kLiBJ 4oCZbSBtZXJlbHkgcG9pbnRpbmcgb3V0IHRoYXQgZS5nLiB3aGVuIGRlYnVnZ2luZyBhbiBpc3N1 ZSwgaXTigJlzIHVzdWFsbHkgbm90IGVub3VnaCB0byBzZWUgd2hhdCB0eXBlcyBvZiBiaW5kaW5n cyB3ZXJlIHNlbnQsIHNvIGdlbmVyYWxseSBvbmUgY2Fu4oCZdCBhdm9pZCBwYXJzaW5nIFRva2Vu QmluZGluZyBtZXNzYWdlcyBhbnl3YXksIGFuZCBwYXJzaW5nIHRvb2xzIHdpbGwgbGlrZWx5IGJl Y29tZSBhdmFpbGFibGUuDQoNCg0Kw5ggIEl0J3Mgbm90IGFuIG9wdGltaXphdGlvbiBidXQgcmF0 aGVyIGp1c3QgYSBzaW1wbGlmaWNhdGlvbiB3aGVyZSB0aGUgcHJvdmlkZWQgVEIgaXMgYWx3YXlz IHNlbnQgdGhlIHNhbWUgd2F5IG5vIG1hdHRlciB3aGF0IGFuZCB0aGUgcmVmZXJyZXIvcmVmZXJy ZWQgaXMgcHJvY2Vzc2VkIGluZGVwZW5kZW50bHkNClByb3ZpZGVkIGFuZCByZWZlcnJlZCBiaW5k aW5ncyBjYW7igJl0IGJlIHByb2Nlc3NlZCBlbnRpcmVseSBpbmRlcGVuZGVudGx5OiBlLmcuIHJl ZmVycmVkIGJpbmRpbmcgY2Fubm90IGJlIHVzZWQgaWYgdGhlIHByb3ZpZGVkIG9uZSBmYWlscyB2 ZXJpZmljYXRpb24uIEEgVEIgbGlicmFyeSBjYW4gb25seSBlbnN1cmUgdGhpcyBpZiBpdCBoYXMg YWNjZXNzIHRvIGFsbCBhdmFpbGFibGUgYmluZGluZ3MuDQoNCg0Kw5ggIEJ1dCBJIHdhcyBsb29r aW5nIHRoZSBzaGFyZSB0aGUgdmlld3BvaW50IG9mIHdoYXQgc2VlbXMgc2ltcGxlciBhdCB0aGUg SFRUUCBsYXllciBmcm9tIHNvbWVvbmUgd2hvIHdvcmtzIHByaW1hcmlseSBhdCB0aGUgSFRUUCBs YXllci4NClRvIGJlIGNsZWFyLCBJIGhpZ2hseSB2YWx1ZSB5b3VyIHZpZXdwb2ludCwgYWx0aG91 Z2ggSSBkaXNhZ3JlZSB3aXRoIGl0LiBCcmluZ2luZyBpdCB1cCBvbiB0aGUgbWFpbGluZyBsaXN0 IGlzIGNlcnRhaW5seSB0aGUgcmlnaHQgdGhpbmcgdG8gZG8uDQoNCkNoZWVycywNCg0KQW5kcmVp DQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j b21dDQpTZW50OiBUdWVzZGF5LCBNYXkgMTcsIDIwMTYgMTo1NyBQTQ0KVG86IEFuZHJlaSBQb3Bv diA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+DQpDYzogSUVURiBUb2tiaW5kIFdHIDx1bmJl YXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBIVFRQU1RCOiBkaXN0 aW5jdCBoZWFkZXIgZm9yIHRoZSByZWZlcnJlZCBUb2tlbiBCaW5kaW5nIChpc3N1ZSAjMzUpDQoN CkRlc3BpdGUgbXkgbGFjayBvZiBhZ3JlZW1lbnQsIEFuZHJlaSwgSSBhcHByZWNpYXRlIHRoZSBy ZXBseS4gTXkgcmVwbGllcyBpbmxpbmUgYmVsb3cuLi4NCg0KT24gVHVlLCBNYXkgMTcsIDIwMTYg YXQgMTE6MjEgQU0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFp bHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpIaSBCcmlhbiwNCg0KVGhl IGN1cnJlbnQgZm9ybWF0LCB3aGVyZSBhbGwgVG9rZW4gQmluZGluZ3MgYXJlIGNvbnRhaW5lZCBp biBvbmUgVG9rZW4gQmluZGluZyBtZXNzYWdlLCBwcm92aWRlcyB1c2VmdWwgZW5jYXBzdWxhdGlv bi4gVGhlIEhUVFAgbGF5ZXIgZG9lcyBub3QgbmVlZCB0byBrbm93IHRoZSBkZXRhaWxzIG9mIHRo ZSBUb2tlbiBCaW5kaW5nIHByb3RvY29sLCB3aGljaCBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gYSBz ZXBhcmF0ZSBsaWJyYXJ5LiBJZiB0b21vcnJvdyB3ZSBkZWZpbmUgYSBuZXcgVG9rZW4gQmluZGlu ZyB0eXBlLCBhbiBleGlzdGluZyBIVFRQIGltcGxlbWVudGF0aW9uIGNhbiBjYXJyeSBpdCBpbiB0 aGUgU2VjLVRva2VuLUJpbmRpbmcgaGVhZGVyIHdpdGhvdXQgbW9kaWZpY2F0aW9uLiBPbmx5IHRo ZSBUb2tlbiBCaW5kaW5nIGxpYnJhcnkgd291bGQgbmVlZCB0byBiZSB1cGRhdGVkLg0KDQpUaGUg SFRUUCBsYXllciBkb2VzIG5lZWQgdG8ga25vdyBhYm91dCBUQiBmb3IgVEIgdG8gYmUgb2YgYW55 IHZhbHVlIC0gdGhhdCdzIHdoZXJlIHRoZSBzaWduYXR1cmUocykgZ2V0IHZlcmlmaWVkIGFuZCB3 aGVyZSBjb29raWVzIGFuZCBvdGhlciB0b2tlbnMgYXJlIGFjdHVhbGx5IGJvdW5kLiAgSWYgYSBu ZXcgVG9rZW4gQmluZGluZyB0eXBlIGlzIGRlZmluZWQgKHdoaWNoIGhvbmVzdGx5IHNlZW1zIHVu bGlrZWx5KSwgeWVzIGl0IGNvdWxkIGJlIGNhcnJpZWQgaW4gdGhlIGN1cnJlbnQgZm9ybWF0IGJ1 dCB0aGUgSFRUUCBsYXllciB3b3VsZCBhbHNvIG5lZWQgdG8gYmUgdXBkYXRlZCB0byBkbyBhbnl0 aGluZyB1c2VmdWwgd2l0aCBpdC4gSSBkb24ndCBzZWUgdGhlIGJlbmVmaXQgb2YgdGhpcyBlbmNh cHN1bGF0aW9uLg0KDQo+ICBBdCB0aGUgSFRUUCBsYXllciBzZXBhcmF0ZSBoZWFkZXJzIHdpbGwg bWFrZSBpdCBtdWNoIG1vcmUgY2xlYXIgd2hhdCBpcyBnb2luZyBvbi4gSnVzdCBsb29raW5nIGZv ciB0aGUgcHJlc2VuY2Ugb3IgYWJzZW5jZSBvZiB0aGUgU2VjLVJlZmVycmVkLVRva2VuLUJpbmRp bmcgaGVhZGVyIHdpbGwgaW5kaWNhdGUgaWYgYSByZWZlcnJlZCBUQiB3YXMgc2VudCwgd2hpY2gg aXMgdmVyeSBlYXN5Lg0KVGhpcyBjYW4gYmUgc29sdmVkIGJ5IGluY2x1ZGluZyBhIFRCIHBhcnNl ciBpbiB0aGUgcHJvdG9jb2wgYW5hbHl6ZXIuIFdoaWNoIHdvdWxkIGFsc28gcHJvdmlkZSBmdXJ0 aGVyIHVzZWZ1bCBpbnNpZ2h0cyBpbnRvIFRCIGtleSBwYXJhbWV0ZXJzLCBldGMuDQoNCkJ1dCBt eSBwb2ludCBpc24ndCB0aGF0IGl0IGNhbid0IGJlIGRvbmUuIEl0J3MgdGhhdCBpdCdzIHJlYWxs eSB1c2VmdWwgdG8gYmUgYWJsZSB0byBsb29rIGF0IEhUVFAgYW5kIHRlbGwgd2hhdHMgZ29pbmcg b24gd2l0aG91dCBoYXZpbmcgdG8gdXNlIGEgcHJvdG9jb2wgYW5hbHl6ZXIgb3IgVEIgcGFyc2Vy Lg0KDQoNCj4gIEhhdmluZyBhIHNlcGFyYXRlIGhlYWRlciBmb3IgdGhlIHJlZmVycmVkIFRCIGFs bG93cyB0aGUgY2xpZW50L3VzZXIgYWdlbnQgdG8gYWx3YXlzIHNlbmQgdGhlIHByb3ZpZGVkIFRC IHZpYSBTZWMtVG9rZW4tQmluZGluZyBhbmQgbm90IGhhdmUgdG8gYnVpbGQgYSBuZXcgVEIgbWVz c2FnZSBvbiB0aGUgcmVkaXJlY3QgcmVxdWVzdCBhbmQgdGhlbiBnbyBiYWNrIHRvIHRoZSBwcm92 aWRlZCBUQiBvbiBzdWJzZXF1ZW50IHJlcXVlc3RzLg0KSSBkb27igJl0IHRoaW5rIHRoZXJl4oCZ cyBhbiBvcHRpbWl6YXRpb24gYW4gSFRUUCBzdGFjayBjYW4gZG8gV1JUIGJ1aWxkaW5nIFRCIG1l c3NhZ2VzIHRoYXQgYSBUb2tlbiBCaW5kaW5nIGxpYnJhcnkgY2Fu4oCZdCwgYW5kIHRoZSBUb2tl biBCaW5kaW5nIGxpYnJhcnkgaXMgd2hlcmUgc3VjaCBvcHRpbWl6YXRpb25zIGJlbG9uZy4NCg0K SXQncyBub3QgYW4gb3B0aW1pemF0aW9uIGJ1dCByYXRoZXIganVzdCBhIHNpbXBsaWZpY2F0aW9u IHdoZXJlIHRoZSBwcm92aWRlZCBUQiBpcyBhbHdheXMgc2VudCB0aGUgc2FtZSB3YXkgbm8gbWF0 dGVyIHdoYXQgYW5kIHRoZSByZWZlcnJlci9yZWZlcnJlZCBpcyBwcm9jZXNzZWQgaW5kZXBlbmRl bnRseS4gVG8gbXkgZXllLCB0aGF0J3MgYmV0dGVyIGNvaGVzaW9uIGFuZCBsZXNzIGNvdXBsaW5n Lg0KDQpIVFRQLzIgaGVhZGVyIGNvbXByZXNzaW9uLCBob3dldmVyLCBpcyBhbiBvcHRpbWl6YXRp b24gaW4gdGhlIEhUVFAgbGF5ZXIgdGhhdCB3b3VsZCBiZSBoZWxwZWQgYnkgaGF2aW5nIHRoZSBw cm92aWRlZCBUQiBoZWFkZXIgbm90IGNoYW5nZS4NCg0KDQpGb3IgdGhlIGFib3ZlIHJlYXNvbnMs IEkgd291bGQgcHJlZmVyIHRvIGtlZXAgYWxsIFRva2VuIEJpbmRpbmdzIGluIG9uZSBUb2tlbiBC aW5kaW5nIG1lc3NhZ2UuDQoNCg0KSSBnb3QgYSBwcmV0dHkgZ29vZCBpZGVhIG9mIHlvdXIgcHJl ZmVyZW5jZSB3aGVuIEkgZmlyc3QgbWVudGlvbmVkIHNlcGFyYXRlIGhlYWRlcnMgaW4gQkEgOikg TXkgcHJlZmVyZW5jZSBpcyBvYnZpb3VzbHkgZGlmZmVyZW50IGFuZCBJIHdhbnRlZCB0byB2b2lj ZSB0aGF0IG9uIHRoZSBsaXN0L2dpdGh1Yi4gQnV0IEkgZ3Vlc3MgdWx0aW1hdGVseSBpdCdzIGFu IGFlc3RoZXRpY3Mgb3IgZXllIG9mIHRoZSBiZWhvbGRlciBraW5kIG9mIHRoaW5nLiBJIHdvbid0 IGZpZ2h0IGFib3V0IGl0IHRvbyBoYXJkLiBBbmQgSSdtIGp1c3QgYSBndXksIG5vdCBhbiBlZGl0 b3IuIEJ1dCBJIHdhcyBsb29raW5nIHRoZSBzaGFyZSB0aGUgdmlld3BvaW50IG9mIHdoYXQgc2Vl bXMgc2ltcGxlciBhdCB0aGUgSFRUUCBsYXllciBmcm9tIHNvbWVvbmUgd2hvIHdvcmtzIHByaW1h cmlseSBhdCB0aGUgSFRUUCBsYXllci4gSSBob3BlIHRoYXQgdmlld3BvaW50IGNhbiBiZSBjb25z aWRlcmVkIGV2ZW4gdGhvdWdoIHR3byBoZWFkZXJzIGlzIGRpZmZlcmVudCB0aGFuIHdoYXQncyBh bHJlYWR5IGRvbmUuDQpJJ2QgYWxzbyBiZSBpbnRlcmVzdGVkIGluIGtub3dpbmcgaWYgb3RoZXJz IGluIHRoZSBXRyBoYXZlIG9waW5pb25zIGhlcmUgb3IgaWYgSSdtIHRoZSBvdXRsaWVyPw0KDQoN CkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJhYmxl LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZz5dIE9u IEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVsbA0KU2VudDogTW9uZGF5LCBNYXkgMTYsIDIwMTYgMToy MiBQTQ0KVG86IElFVEYgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86dW5i ZWFyYWJsZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbVW5iZWFyYWJsZV0gSFRUUFNUQjogZGlzdGlu Y3QgaGVhZGVyIGZvciB0aGUgcmVmZXJyZWQgVG9rZW4gQmluZGluZyAoaXNzdWUgIzM1KQ0KDQpJ dCBzZWVtcyBsaWtlIGdpdGh1YiByZWNlbnRseSBzdGFydGVkIHNlbmRpbmcgc29tZSBub3RpZmlj YXRpb25zIHRvIHRoZSBXRyBsaXN0IGJ1dCBpdCdzIG5vdCBjbGVhciBob3cgcmVsaWFibGUgdGhh dCBpcyBzbyBJJ20gZ29ubmEgZG91YmxlIHBvc3QgYW55d2F5LiBUaGUgdGV4dCBmcm9tIGh0dHBz Oi8vZ2l0aHViLmNvbS9Ub2tlbkJpbmRpbmcvSW50ZXJuZXQtRHJhZnRzL2lzc3Vlcy8zNSBmb2xs b3dzLg0KDQoNCkFzIG1lbnRpb25lZCBhdCBJRVRGIDk1PGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL21pbnV0ZXMtOTUtdG9rYmluZC8+IEkgcHJvcG9zZSB0aGF0IHRoZSByZWZlcnJl ZCBUb2tlbiBCaW5kaW5nIGJlIHNlbnQgdmlhIGEgc2VwYXJhdGUgaGVhZGVyIChzYXkgU2VjLVJl ZmVycmVkLVRva2VuLUJpbmRpbmcpIHJhdGhlciB0aGFuIGFzIHBhcnQgb2YgdGhlIFNlYy1Ub2tl bi1CaW5kaW5nIGhlYWRlci4NCg0KQXQgdGhlIEhUVFAgbGF5ZXIgc2VwYXJhdGUgaGVhZGVycyB3 aWxsIG1ha2UgaXQgbXVjaCBtb3JlIGNsZWFyIHdoYXQgaXMgZ29pbmcgb24uIEp1c3QgbG9va2lu ZyBmb3IgdGhlIHByZXNlbmNlIG9yIGFic2VuY2Ugb2YgdGhlIFNlYy1SZWZlcnJlZC1Ub2tlbi1C aW5kaW5nIGhlYWRlciB3aWxsIGluZGljYXRlIGlmIGEgcmVmZXJyZWQgVEIgd2FzIHNlbnQsIHdo aWNoIGlzIHZlcnkgZWFzeS4gUmF0aGVyIHRoYW4gaGF2aW5nIHRvIGRlY29kZSB0aGUgU2VjLVRv a2VuLUJpbmRpbmcgaGVhZGVyIHZhbHVlIGFuZCBwcm9jZXNzIHRoZSBiaW5hcnkgY29udGVudCwg d2hpY2ggaXMgcG9zc2libGUgYnV0IG11Y2ggbW9yZSBpbnZvbHZlZC4NCg0KSGF2aW5nIGEgc2Vw YXJhdGUgaGVhZGVyIGZvciB0aGUgcmVmZXJyZWQgVEIgYWxsb3dzIHRoZSBjbGllbnQvdXNlciBh Z2VudCB0byBhbHdheXMgc2VuZCB0aGUgcHJvdmlkZWQgVEIgdmlhIFNlYy1Ub2tlbi1CaW5kaW5n IGFuZCBub3QgaGF2ZSB0byBidWlsZCBhIG5ldyBUQiBtZXNzYWdlIG9uIHRoZSByZWRpcmVjdCBy ZXF1ZXN0IGFuZCB0aGVuIGdvIGJhY2sgdG8gdGhlIHByb3ZpZGVkIFRCIG9uIHN1YnNlcXVlbnQg cmVxdWVzdHMuIEFsc28gbm90IGhhdmluZyB0aGUgdmFsdWUgb2YgU2VjLVRva2VuLUJpbmRpbmcg Y2hhbmdlIChvdGhlciB0aGVuIGEgbmV3IFRMUyBzZXNzaW9uIHdpdGggbmV3IEVLTSkgc2hvdWxk IG1ha2UgaXQgbmljZWx5IGVmZmljaWVudCB3aXRoIEhUVFAvMiBoZWFkZXIgY29tcHJlc3Npb24u DQoNCkkgYWxzbyBiZWxpZXZlIGl0IHdpbGwgYmUgZWFzaWVyIHRvIGNvdmV5IHRoZSBjb25jZXB0 cyBpbiB0aGUgdGV4dCBvZiB0aGUgc3BlYy4gVGFsa2luZyBhYm91dCB3aGVuIHRoZSBTZWMtUmVm ZXJyZWQtVG9rZW4tQmluZGluZyBpcyBzZW50IG9yIG5vdCBzZW50IHJhdGhlciB0aGFuIHRhbGtp bmcgYWJvdXQgd2hlbiB0aGUgcmVmZXJyZWQgVEIgaXMgaW5jbHVkZWQgYXMgcGFydCBvZiB0aGUg VEIgbWVzc2FnZSB0aGF0IGlzIHNlbnQgd2l0aCBTZWMtVG9rZW4tQmluZGluZyBzZWVtcyBtdWNo IG1vcmUgc3RyYWlnaHRmb3J3YXJkLg0KDQpBbmVjZG90YWxseSwgdGhlcmUncyBiZWVuIHNvbWUg ZGlzY3Vzc2lvbiBhYm91dCB1c2luZyBUQiBpbiBPcGVuSUQgQ29ubmVjdCBhbmQgYW5kIGluIHRh bGtpbmcgYWJvdXQgaXQgcGVvcGxlIG9mdGVuIHNheSAidGhlIHJlZmVycmVkIHRva2VuIGJpbmRp bmcgaGVhZGVyIiwgd2hpY2ggaXNuJ3QgYWNjdXJhdGUgcmVsYXRpdmUgdG8gSFRUUFNUQi0wMyBi dXQgYmVsaWVzIHRoZSBmYWN0IHRoYXQgZmVkZXJhdGlvbiBmb2xrcyBhbHJlYWR5IHRoaW5rIGFi b3V0IGl0IGFzIHNlcGFyYXRlIGhlYWRlci4gQW5kIEkgdGhpbmsgdGhhdCdzIGEgbmF0dXJhbCB3 YXkgdGhpbmsgYWJvdXQgaXQgc28gaXQncyBub3QgdGVycmlibHkgc3VycHJpc2luZy4gSSB3b24n dCBuYW1lIGFueSBuYW1lcyBidXQgb25lIG9mIHRoZSBjaGFpcnMgb2YgdGhlIFdHIGlzIGFtb25n IHRob3NlIHdobyBzYWlkICJ0aGUgcmVmZXJyZWQgdG9rZW4gYmluZGluZyBoZWFkZXIuIg0KDQpJ IHJlYWxpemUgdGhpcyBpcyBub3QgYW4gaW5zaWduaWZpY2FudCBjaGFuZ2UgYnV0IEkgc3Ryb25n bHkgYmVsaWV2ZSBpdCdkIGJlIGEgc2ltcGxpZmljYXRpb24gYW5kIGltcHJvdmVtZW50IGZvciBI VFRQUyBUQi4gVGhlcmUncyBub3QgeWV0ICh0aGF0IEknbSBhd2FyZSBvZiBhbnl3YXkpIGFueSBw cm9maWxpbmcgb2YgVEIgZm9yIGZlZGVyYXRpb24gbGlrZSBwcm90b2NvbHMgc3VjaCBPcGVuSUQg Q29ubmVjdCwgT0F1dGggb3IgU0FNTCBzbyB0aGlzIHdvdWxkIGJlIGFuIG9wcG9ydHVuZSB0aW1l IHRvIGNoYW5nZSBob3cgdGhlIHJlZmVycmVkIFRva2VuIEJpbmRpbmcgaXMgY29udmV5ZWQuDQoN Cg0K --_000_BN3PR03MB1445B30EF30B69B5F51564078C480BN3PR03MB1445namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFy YWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJ bWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsN CgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlk OjIyNTY1MTk1NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6MjEwOTM4NTY3MiAtMjAwNDE4MjMwOCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZl bDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjU7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMjc0RTEzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImNv bG9yOiMyNzRFMTMiPlRoZSBIVFRQIGxheWVyIGRvZXMgbmVlZCB0byBrbm93IGFib3V0IFRCIGZv ciBUQiB0byBiZSBvZiBhbnkgdmFsdWUgLSB0aGF0J3Mgd2hlcmUgdGhlIHNpZ25hdHVyZShzKSBn ZXQgdmVyaWZpZWQgYW5kIHdoZXJlIGNvb2tpZXMgYW5kIG90aGVyIHRva2VucyBhcmUgYWN0dWFs bHkgYm91bmQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldpdGggdGhlIGN1cnJlbnQgVEIgbWVzc2FnZSBz dHJ1Y3R1cmUsIHRoZSBIVFRQIGxheWVyIGNhbiBzaW1wbHkgcGFzcyB0aGUgY29udGVudHMgb2Yg dGhlIGhlYWRlciB0byB0aGUgVEIgbGlicmFyeSwgZ2V0IGJhY2sgdmVyaWZpZWQgYmluZGluZ3Mg YW5kIGFjdCBvbiB0aGUNCiBvbmVzIHRoYXQgdGhlIEhUVFAgbGF5ZXIgdW5kZXJzdGFuZHMuIEFu ZCBJIGxpa2UgdGhlIGZhY3QgdGhhdCBjdXJyZW50bHkgdGhlIFRCIGxpYnJhcnkgZ2V0cyBhbGwg YXZhaWxhYmxlIFRCIGluZm9ybWF0aW9uIGF0IG9uZSB0aW1lIGFuZCBpbiBvbmUgcGllY2UuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IHN0eWxlPSJjb2xvcjojMjc0RTEzIj5CdXQgbXkgcG9pbnQgaXNuJ3QgdGhhdCBpdCBjYW4ndCBi ZSBkb25lLiBJdCdzIHRoYXQgaXQncyByZWFsbHkgdXNlZnVsIHRvIGJlIGFibGUgdG8gbG9vayBh dCBIVFRQIGFuZCB0ZWxsIHdoYXRzIGdvaW5nIG9uIHdpdGhvdXQgaGF2aW5nIHRvIHVzZSBhIHBy b3RvY29sIGFuYWx5emVyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjc0RTEzIj4NCiBv ciBUQiBwYXJzZXIuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+VW5kZXJzdG9vZC4gSeKAmW0gbWVyZWx5IHBvaW50aW5nIG91dCB0aGF0IGUu Zy4gd2hlbiBkZWJ1Z2dpbmcgYW4gaXNzdWUsIGl04oCZcyB1c3VhbGx5IG5vdCBlbm91Z2ggdG8g c2VlIHdoYXQgdHlwZXMgb2YgYmluZGluZ3Mgd2VyZSBzZW50LCBzbyBnZW5lcmFsbHkgb25lIGNh buKAmXQNCiBhdm9pZCBwYXJzaW5nIFRva2VuQmluZGluZyBtZXNzYWdlcyBhbnl3YXksIGFuZCBw YXJzaW5nIHRvb2xzIHdpbGwgbGlrZWx5IGJlY29tZSBhdmFpbGFibGUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJjb2xv cjojMjc0RTEzIj5JdCdzIG5vdCBhbiBvcHRpbWl6YXRpb24gYnV0IHJhdGhlciBqdXN0IGEgc2lt cGxpZmljYXRpb24gd2hlcmUgdGhlIHByb3ZpZGVkIFRCIGlzIGFsd2F5cyBzZW50IHRoZSBzYW1l IHdheSBubyBtYXR0ZXIgd2hhdCBhbmQgdGhlIHJlZmVycmVyL3JlZmVycmVkIGlzIHByb2Nlc3Nl ZCBpbmRlcGVuZGVudGx5PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+UHJvdmlkZWQgYW5kIHJlZmVycmVkIGJpbmRpbmdzIGNhbuKAmXQgYmUg cHJvY2Vzc2VkIGVudGlyZWx5IGluZGVwZW5kZW50bHk6IGUuZy4gcmVmZXJyZWQgYmluZGluZyBj YW5ub3QgYmUgdXNlZCBpZiB0aGUgcHJvdmlkZWQgb25lIGZhaWxzIHZlcmlmaWNhdGlvbi4gQSBU QiBsaWJyYXJ5DQogY2FuIG9ubHkgZW5zdXJlIHRoaXMgaWYgaXQgaGFzIGFjY2VzcyB0byBhbGwg YXZhaWxhYmxlIGJpbmRpbmdzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMx RjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iY29sb3I6IzI3NEUxMyI+QnV0IEkgd2FzIGxv b2tpbmcgdGhlIHNoYXJlIHRoZSB2aWV3cG9pbnQgb2Ygd2hhdCBzZWVtcyBzaW1wbGVyIGF0IHRo ZSBIVFRQIGxheWVyIGZyb20gc29tZW9uZSB3aG8gd29ya3MgcHJpbWFyaWx5IGF0IHRoZSBIVFRQ IGxheWVyLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPlRvIGJlIGNsZWFyLCBJIGhpZ2hseSB2YWx1ZSB5b3VyIHZpZXdwb2ludCwgYWx0aG91 Z2ggSSBkaXNhZ3JlZSB3aXRoIGl0LiBCcmluZ2luZyBpdCB1cCBvbiB0aGUgbWFpbGluZyBsaXN0 IGlzIGNlcnRhaW5seSB0aGUgcmlnaHQgdGhpbmcgdG8gZG8uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQnJpYW4gQ2FtcGJlbGwgW21haWx0bzpi Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBN YXkgMTcsIDIwMTYgMTo1NyBQTTxicj4NCjxiPlRvOjwvYj4gQW5kcmVpIFBvcG92ICZsdDtBbmRy ZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IElFVEYgVG9rYmluZCBX RyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtV bmJlYXJhYmxlXSBIVFRQU1RCOiBkaXN0aW5jdCBoZWFkZXIgZm9yIHRoZSByZWZlcnJlZCBUb2tl biBCaW5kaW5nIChpc3N1ZSAjMzUpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyNzRFMTMiPkRlc3BpdGUgbXkgbGFjayBvZiBhZ3JlZW1l bnQsIEFuZHJlaSwgSSBhcHByZWNpYXRlIHRoZSByZXBseS4gTXkgcmVwbGllcyBpbmxpbmUgYmVs b3cuLi4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gVHVlLCBNYXkgMTcsIDIwMTYgYXQgMTE6MjEgQU0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEg aHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEJyaWFuLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBjdXJyZW50IGZvcm1hdCwgd2hlcmUgYWxsIFRv a2VuIEJpbmRpbmdzIGFyZSBjb250YWluZWQgaW4gb25lIFRva2VuIEJpbmRpbmcgbWVzc2FnZSwg cHJvdmlkZXMgdXNlZnVsDQogZW5jYXBzdWxhdGlvbi4gVGhlIEhUVFAgbGF5ZXIgZG9lcyBub3Qg bmVlZCB0byBrbm93IHRoZSBkZXRhaWxzIG9mIHRoZSBUb2tlbiBCaW5kaW5nIHByb3RvY29sLCB3 aGljaCBjYW4gYmUgaW1wbGVtZW50ZWQgaW4gYSBzZXBhcmF0ZSBsaWJyYXJ5LiBJZiB0b21vcnJv dyB3ZSBkZWZpbmUgYSBuZXcgVG9rZW4gQmluZGluZyB0eXBlLCBhbiBleGlzdGluZyBIVFRQIGlt cGxlbWVudGF0aW9uIGNhbiBjYXJyeSBpdCBpbiB0aGUgU2VjLVRva2VuLUJpbmRpbmcNCiBoZWFk ZXIgd2l0aG91dCBtb2RpZmljYXRpb24uIE9ubHkgdGhlIFRva2VuIEJpbmRpbmcgbGlicmFyeSB3 b3VsZCBuZWVkIHRvIGJlIHVwZGF0ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyNzRFMTMiPlRoZSBI VFRQIGxheWVyIGRvZXMgbmVlZCB0byBrbm93IGFib3V0IFRCIGZvciBUQiB0byBiZSBvZiBhbnkg dmFsdWUgLSB0aGF0J3Mgd2hlcmUgdGhlIHNpZ25hdHVyZShzKSBnZXQgdmVyaWZpZWQgYW5kIHdo ZXJlIGNvb2tpZXMgYW5kIG90aGVyIHRva2VucyBhcmUgYWN0dWFsbHkgYm91bmQuJm5ic3A7IElm IGEgbmV3IFRva2VuDQogQmluZGluZyB0eXBlIGlzIGRlZmluZWQgKHdoaWNoIGhvbmVzdGx5IHNl ZW1zIHVubGlrZWx5KSwgeWVzIGl0IGNvdWxkIGJlIGNhcnJpZWQgaW4gdGhlIGN1cnJlbnQgZm9y bWF0IGJ1dCB0aGUgSFRUUCBsYXllciB3b3VsZCBhbHNvIG5lZWQgdG8gYmUgdXBkYXRlZCB0byBk byBhbnl0aGluZyB1c2VmdWwgd2l0aCBpdC4gSSBkb24ndCBzZWUgdGhlIGJlbmVmaXQgb2YgdGhp cyBlbmNhcHN1bGF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6V2luZ2RpbmdzO2NvbG9yOiMxRjQ5N0QiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzMzMzMzMyI+QXQgdGhlIEhUVFAgbGF5ZXIgc2VwYXJhdGUgaGVhZGVycyB3aWxs IG1ha2UgaXQgbXVjaCBtb3JlIGNsZWFyIHdoYXQgaXMgZ29pbmcgb24uIEp1c3QgbG9va2luZyBm b3IgdGhlIHByZXNlbmNlIG9yIGFic2VuY2Ugb2YgdGhlIFNlYy1SZWZlcnJlZC1Ub2tlbi1CaW5k aW5nIGhlYWRlciB3aWxsIGluZGljYXRlDQogaWYgYSByZWZlcnJlZCBUQiB3YXMgc2VudCwgd2hp Y2ggaXMgdmVyeSBlYXN5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoaXMgY2FuIGJlIHNvbHZlZCBi eSBpbmNsdWRpbmcgYSBUQiBwYXJzZXIgaW4gdGhlIHByb3RvY29sIGFuYWx5emVyLiBXaGljaCB3 b3VsZCBhbHNvIHByb3ZpZGUgZnVydGhlcg0KIHVzZWZ1bCBpbnNpZ2h0cyBpbnRvIFRCIGtleSBw YXJhbWV0ZXJzLCBldGMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMjc0RTEzIj5CdXQgbXkgcG9pbnQgaXNuJ3QgdGhhdCBpdCBjYW4ndCBiZSBkb25lLiBJ dCdzIHRoYXQgaXQncyByZWFsbHkgdXNlZnVsIHRvIGJlIGFibGUgdG8gbG9vayBhdCBIVFRQIGFu ZCB0ZWxsIHdoYXRzIGdvaW5nIG9uIHdpdGhvdXQgaGF2aW5nIHRvIHVzZSBhIHByb3RvY29sIGFu YWx5emVyPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjc0RTEzIj4NCiBvciBUQiBwYXJz ZXIuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48YnI+DQombmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxw PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xv cjojMUY0OTdEIj7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPkhh dmluZyBhIHNlcGFyYXRlIGhlYWRlciBmb3IgdGhlIHJlZmVycmVkIFRCIGFsbG93cyB0aGUgY2xp ZW50L3VzZXIgYWdlbnQgdG8gYWx3YXlzIHNlbmQgdGhlIHByb3ZpZGVkIFRCIHZpYSBTZWMtVG9r ZW4tQmluZGluZyBhbmQgbm90IGhhdmUgdG8gYnVpbGQgYSBuZXcgVEIgbWVzc2FnZSBvbiB0aGUN CiByZWRpcmVjdCByZXF1ZXN0IGFuZCB0aGVuIGdvIGJhY2sgdG8gdGhlIHByb3ZpZGVkIFRCIG9u IHN1YnNlcXVlbnQgcmVxdWVzdHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHRoaW5r IHRoZXJl4oCZcyBhbiBvcHRpbWl6YXRpb24gYW4gSFRUUCBzdGFjayBjYW4gZG8gV1JUIGJ1aWxk aW5nIFRCIG1lc3NhZ2VzIHRoYXQgYSBUb2tlbiBCaW5kaW5nDQogbGlicmFyeSBjYW7igJl0LCBh bmQgdGhlIFRva2VuIEJpbmRpbmcgbGlicmFyeSBpcyB3aGVyZSBzdWNoIG9wdGltaXphdGlvbnMg YmVsb25nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojMjc0RTEzIj5JdCdzIG5vdCBhbiBvcHRpbWl6YXRp b24gYnV0IHJhdGhlciBqdXN0IGEgc2ltcGxpZmljYXRpb24gd2hlcmUgdGhlIHByb3ZpZGVkIFRC IGlzIGFsd2F5cyBzZW50IHRoZSBzYW1lIHdheSBubyBtYXR0ZXIgd2hhdCBhbmQgdGhlIHJlZmVy cmVyL3JlZmVycmVkIGlzIHByb2Nlc3NlZCBpbmRlcGVuZGVudGx5LiBUbw0KIG15IGV5ZSwgdGhh dCdzIGJldHRlciBjb2hlc2lvbiBhbmQgbGVzcyBjb3VwbGluZy4gPGJyPg0KPGJyPg0KSFRUUC8y IGhlYWRlciBjb21wcmVzc2lvbiwgaG93ZXZlciwgaXMgYW4gb3B0aW1pemF0aW9uIGluIHRoZSBI VFRQIGxheWVyIHRoYXQgd291bGQgYmUgaGVscGVkIGJ5IGhhdmluZyB0aGUgcHJvdmlkZWQgVEIg aGVhZGVyIG5vdCBjaGFuZ2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkZvciB0aGUgYWJv dmUgcmVhc29ucywgSSB3b3VsZCBwcmVmZXIgdG8ga2VlcCBhbGwgVG9rZW4gQmluZGluZ3MgaW4g b25lIFRva2VuIEJpbmRpbmcgbWVzc2FnZS4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQo8c3BhbiBzdHlsZT0iY29sb3I6IzI3NEUxMyI+SSBnb3QgYSBwcmV0dHkgZ29vZCBpZGVhIG9m IHlvdXIgcHJlZmVyZW5jZSB3aGVuIEkgZmlyc3QgbWVudGlvbmVkIHNlcGFyYXRlIGhlYWRlcnMg aW4gQkEgOikgTXkgcHJlZmVyZW5jZSBpcyBvYnZpb3VzbHkgZGlmZmVyZW50IGFuZCBJIHdhbnRl ZCB0byB2b2ljZSB0aGF0IG9uIHRoZSBsaXN0L2dpdGh1Yi4gQnV0IEkgZ3Vlc3MgdWx0aW1hdGVs eSBpdCdzIGFuIGFlc3RoZXRpY3Mgb3IgZXllIG9mDQogdGhlIGJlaG9sZGVyIGtpbmQgb2YgdGhp bmcuIEkgd29uJ3QgZmlnaHQgYWJvdXQgaXQgdG9vIGhhcmQuIEFuZCBJJ20ganVzdCBhIGd1eSwg bm90IGFuIGVkaXRvci4gQnV0IEkgd2FzIGxvb2tpbmcgdGhlIHNoYXJlIHRoZSB2aWV3cG9pbnQg b2Ygd2hhdCBzZWVtcyBzaW1wbGVyIGF0IHRoZSBIVFRQIGxheWVyIGZyb20gc29tZW9uZSB3aG8g d29ya3MgcHJpbWFyaWx5IGF0IHRoZSBIVFRQIGxheWVyLiBJIGhvcGUgdGhhdCB2aWV3cG9pbnQg Y2FuDQogYmUgY29uc2lkZXJlZCBldmVuIHRob3VnaCB0d28gaGVhZGVycyBpcyBkaWZmZXJlbnQg dGhhbiB3aGF0J3MgYWxyZWFkeSBkb25lLiA8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMjc0RTEz Ij5JJ2QgYWxzbyBiZSBpbnRlcmVzdGVkIGluIGtub3dpbmcgaWYgb3RoZXJzIGluIHRoZSBXRyBo YXZlIG9waW5pb25zIGhlcmUgb3IgaWYgSSdtIHRoZSBvdXRsaWVyPzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVlcnMsPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QW5kcmVpPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiBVbmJlYXJhYmxlIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnVuYmVhcmFibGUtYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9y ZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8 L2I+IE1vbmRheSwgTWF5IDE2LCAyMDE2IDE6MjIgUE08YnI+DQo8Yj5Ubzo8L2I+IElFVEYgVG9r YmluZCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj51bmJlYXJhYmxlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g W1VuYmVhcmFibGVdIEhUVFBTVEI6IGRpc3RpbmN0IGhlYWRlciBmb3IgdGhlIHJlZmVycmVkIFRv a2VuIEJpbmRpbmcgKGlzc3VlICMzNSk8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Ij5JdCBzZWVtcyBsaWtlIGdpdGh1YiByZWNlbnRseSBzdGFydGVkIHNl bmRpbmcgc29tZSBub3RpZmljYXRpb25zIHRvIHRoZSBXRyBsaXN0IGJ1dCBpdCdzIG5vdCBjbGVh ciBob3cgcmVsaWFibGUgdGhhdCBpcyBzbyBJJ20gZ29ubmEgZG91YmxlIHBvc3QgYW55d2F5LiBU aGUgdGV4dCBmcm9tDQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vVG9rZW5CaW5kaW5nL0lu dGVybmV0LURyYWZ0cy9pc3N1ZXMvMzUiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZ2l0aHVi LmNvbS9Ub2tlbkJpbmRpbmcvSW50ZXJuZXQtRHJhZnRzL2lzc3Vlcy8zNTwvYT4gZm9sbG93cy4g PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQ7bGluZS1oZWlnaHQ6MTYuOHB0O2JhY2tncm91bmQ6d2hpdGU7YmFja2dyb3VuZC1hdHRhY2ht ZW50OnNjcm9sbDtiYWNrZ3JvdW5kLXBvc2l0aW9uLXg6MCU7YmFja2dyb3VuZC1wb3NpdGlvbi15 OjAlIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPkFzIG1lbnRpb25lZCZuYnNw OzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL21pbnV0ZXMtOTUtdG9r YmluZC8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzQwNzhDMDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+YXQgSUVURiA5NTwvc3Bhbj48L2E+Jm5ic3A7SSBwcm9wb3NlIHRoYXQN CiB0aGUgcmVmZXJyZWQgVG9rZW4gQmluZGluZyBiZSBzZW50IHZpYSBhIHNlcGFyYXRlIGhlYWRl ciAoc2F5IFNlYy1SZWZlcnJlZC1Ub2tlbi1CaW5kaW5nKSByYXRoZXIgdGhhbiBhcyBwYXJ0IG9m IHRoZSBTZWMtVG9rZW4tQmluZGluZyBoZWFkZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2xpbmUtaGVpZ2h0OjE2LjhwdDtiYWNrZ3JvdW5k OndoaXRlO3RleHQtYWxpZ246c3RhcnQ7YmFja2dyb3VuZC1hdHRhY2htZW50OnNjcm9sbDtiYWNr Z3JvdW5kLXBvc2l0aW9uLXg6MCU7YmFja2dyb3VuZC1wb3NpdGlvbi15OjAlO3dvcmQtc3BhY2lu ZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+QXQgdGhlIEhUVFAgbGF5 ZXIgc2VwYXJhdGUgaGVhZGVycyB3aWxsIG1ha2UgaXQgbXVjaCBtb3JlIGNsZWFyIHdoYXQgaXMg Z29pbmcgb24uIEp1c3QgbG9va2luZyBmb3IgdGhlIHByZXNlbmNlIG9yIGFic2VuY2Ugb2YgdGhl IFNlYy1SZWZlcnJlZC1Ub2tlbi1CaW5kaW5nIGhlYWRlciB3aWxsIGluZGljYXRlDQogaWYgYSBy ZWZlcnJlZCBUQiB3YXMgc2VudCwgd2hpY2ggaXMgdmVyeSBlYXN5LiBSYXRoZXIgdGhhbiBoYXZp bmcgdG8gZGVjb2RlIHRoZSBTZWMtVG9rZW4tQmluZGluZyBoZWFkZXIgdmFsdWUgYW5kIHByb2Nl c3MgdGhlIGJpbmFyeSBjb250ZW50LCB3aGljaCBpcyBwb3NzaWJsZSBidXQgbXVjaCBtb3JlIGlu dm9sdmVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdDtsaW5lLWhlaWdodDoxNi44cHQ7YmFja2dyb3VuZDp3aGl0ZTt0ZXh0LWFsaWduOnN0YXJ0 O2JhY2tncm91bmQtYXR0YWNobWVudDpzY3JvbGw7YmFja2dyb3VuZC1wb3NpdGlvbi14OjAlO2Jh Y2tncm91bmQtcG9zaXRpb24teTowJTt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMzMzMzMzMiPkhhdmluZyBhIHNlcGFyYXRlIGhlYWRlciBmb3IgdGhlIHJlZmVy cmVkIFRCIGFsbG93cyB0aGUgY2xpZW50L3VzZXIgYWdlbnQgdG8gYWx3YXlzIHNlbmQgdGhlIHBy b3ZpZGVkIFRCIHZpYSBTZWMtVG9rZW4tQmluZGluZyBhbmQgbm90IGhhdmUgdG8gYnVpbGQgYSBu ZXcgVEIgbWVzc2FnZSBvbiB0aGUgcmVkaXJlY3QNCiByZXF1ZXN0IGFuZCB0aGVuIGdvIGJhY2sg dG8gdGhlIHByb3ZpZGVkIFRCIG9uIHN1YnNlcXVlbnQgcmVxdWVzdHMuIEFsc28gbm90IGhhdmlu ZyB0aGUgdmFsdWUgb2YgU2VjLVRva2VuLUJpbmRpbmcgY2hhbmdlIChvdGhlciB0aGVuIGEgbmV3 IFRMUyBzZXNzaW9uIHdpdGggbmV3IEVLTSkgc2hvdWxkIG1ha2UgaXQgbmljZWx5IGVmZmljaWVu dCB3aXRoIEhUVFAvMiBoZWFkZXIgY29tcHJlc3Npb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0O2xpbmUtaGVpZ2h0OjE2LjhwdDtiYWNrZ3Jv dW5kOndoaXRlO3RleHQtYWxpZ246c3RhcnQ7YmFja2dyb3VuZC1hdHRhY2htZW50OnNjcm9sbDti YWNrZ3JvdW5kLXBvc2l0aW9uLXg6MCU7YmFja2dyb3VuZC1wb3NpdGlvbi15OjAlO3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+SSBhbHNvIGJlbGll dmUgaXQgd2lsbCBiZSBlYXNpZXIgdG8gY292ZXkgdGhlIGNvbmNlcHRzIGluIHRoZSB0ZXh0IG9m IHRoZSBzcGVjLiBUYWxraW5nIGFib3V0IHdoZW4gdGhlIFNlYy1SZWZlcnJlZC1Ub2tlbi1CaW5k aW5nIGlzIHNlbnQgb3Igbm90IHNlbnQgcmF0aGVyIHRoYW4gdGFsa2luZyBhYm91dCB3aGVuDQog dGhlIHJlZmVycmVkIFRCIGlzIGluY2x1ZGVkIGFzIHBhcnQgb2YgdGhlIFRCIG1lc3NhZ2UgdGhh dCBpcyBzZW50IHdpdGggU2VjLVRva2VuLUJpbmRpbmcgc2VlbXMgbXVjaCBtb3JlIHN0cmFpZ2h0 Zm9yd2FyZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQ7bGluZS1oZWlnaHQ6MTYuOHB0O2JhY2tncm91bmQ6d2hpdGU7dGV4dC1hbGlnbjpzdGFy dDtiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6c2Nyb2xsO2JhY2tncm91bmQtcG9zaXRpb24teDowJTti YWNrZ3JvdW5kLXBvc2l0aW9uLXk6MCU7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMzMzMzMzIj5BbmVjZG90YWxseSwgdGhlcmUncyBiZWVuIHNvbWUgZGlzY3Vz c2lvbiBhYm91dCB1c2luZyBUQiBpbiBPcGVuSUQgQ29ubmVjdCBhbmQgYW5kIGluIHRhbGtpbmcg YWJvdXQgaXQgcGVvcGxlIG9mdGVuIHNheSAmcXVvdDt0aGUgcmVmZXJyZWQgdG9rZW4gYmluZGlu ZyBoZWFkZXImcXVvdDssIHdoaWNoIGlzbid0IGFjY3VyYXRlDQogcmVsYXRpdmUgdG8gSFRUUFNU Qi0wMyBidXQgYmVsaWVzIHRoZSBmYWN0IHRoYXQgZmVkZXJhdGlvbiBmb2xrcyBhbHJlYWR5IHRo aW5rIGFib3V0IGl0IGFzIHNlcGFyYXRlIGhlYWRlci4gQW5kIEkgdGhpbmsgdGhhdCdzIGEgbmF0 dXJhbCB3YXkgdGhpbmsgYWJvdXQgaXQgc28gaXQncyBub3QgdGVycmlibHkgc3VycHJpc2luZy4g SSB3b24ndCBuYW1lIGFueSBuYW1lcyBidXQgb25lIG9mIHRoZSBjaGFpcnMgb2YgdGhlIFdHIGlz IGFtb25nIHRob3NlDQogd2hvIHNhaWQgJnF1b3Q7dGhlIHJlZmVycmVkIHRva2VuIGJpbmRpbmcg aGVhZGVyLiZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tdG9w OjBpbjtsaW5lLWhlaWdodDoxNi44cHQ7YmFja2dyb3VuZDp3aGl0ZTttYXJnaW4tYm90dG9tOjBw eCFpbXBvcnRhbnQ7dGV4dC1hbGlnbjpzdGFydDtiYWNrZ3JvdW5kLWF0dGFjaG1lbnQ6c2Nyb2xs O2JhY2tncm91bmQtcG9zaXRpb24teDowJTtiYWNrZ3JvdW5kLXBvc2l0aW9uLXk6MCU7d29yZC1z cGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj5JIHJlYWxpemUg dGhpcyBpcyBub3QgYW4gaW5zaWduaWZpY2FudCBjaGFuZ2UgYnV0IEkgc3Ryb25nbHkgYmVsaWV2 ZSBpdCdkIGJlIGEgc2ltcGxpZmljYXRpb24gYW5kIGltcHJvdmVtZW50IGZvciBIVFRQUyBUQi4g VGhlcmUncyBub3QgeWV0ICh0aGF0IEknbSBhd2FyZSBvZiBhbnl3YXkpIGFueSBwcm9maWxpbmcN CiBvZiBUQiBmb3IgZmVkZXJhdGlvbiBsaWtlIHByb3RvY29scyBzdWNoIE9wZW5JRCBDb25uZWN0 LCBPQXV0aCBvciBTQU1MIHNvIHRoaXMgd291bGQgYmUgYW4gb3Bwb3J0dW5lIHRpbWUgdG8gY2hh bmdlIGhvdyB0aGUgcmVmZXJyZWQgVG9rZW4gQmluZGluZyBpcyBjb252ZXllZC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN3PR03MB1445B30EF30B69B5F51564078C480BN3PR03MB1445namp_-- From nobody Tue May 17 15:38:03 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901D812DAC3 for ; Tue, 17 May 2016 15:38:01 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=buckeyemailosu.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zTPW1q9yV57K for ; Tue, 17 May 2016 15:38:00 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0799.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:799]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA8E12D53E for ; Tue, 17 May 2016 15:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buckeyemailosu.onmicrosoft.com; s=selector1-osu-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=m0BYIjZumLSsIIDF5UDateQisEjuU/n+/lPb1pBvYWA=; b=YC7ZU2GgMEy/D7qj1ddHJaeOWARS5Ozv98+7T7aKDjRWMis5EBSYE0j3Pf4ud2aBLc9o12eQ7clQ4iCYu8nxfiznCp7L1uQ2tKXWTTjLqxDLoFXUe0pGsHHMWcIbiEvc5cOsJHIF7Zghyw2XdB8lgmtPMyhfvxoDjJvR8ycEPmA= Received: from BY2PR01CA0083.prod.exchangelabs.com (10.163.25.51) by BLUPR01MB129.prod.exchangelabs.com (10.242.201.20) with Microsoft SMTP Server (TLS) id 15.1.497.12; Tue, 17 May 2016 22:37:43 +0000 Received: from BL2FFO11FD048.protection.gbl (2a01:111:f400:7c09::104) by BY2PR01CA0083.outlook.office365.com (2a01:111:e400:5262::51) with Microsoft SMTP Server (TLS) id 15.1.497.12 via Frontend Transport; Tue, 17 May 2016 22:37:42 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.220) smtp.mailfrom=osu.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=osu.edu; Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.220 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.220; helo=cio-tnc-pf06.osuad.osu.edu; Received: from cio-tnc-pf06.osuad.osu.edu (164.107.81.220) by BL2FFO11FD048.mail.protection.outlook.com (10.173.161.210) with Microsoft SMTP Server (TLS) id 15.1.492.8 via Frontend Transport; Tue, 17 May 2016 22:37:42 +0000 Received: from CIO-TNC-HT06.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1.2 with cipher AES256-SHA256 (256/256 bits)) (No client certificate requested) by cio-tnc-pf06.osuad.osu.edu (Postfix) with ESMTPS id C93873C008A; Tue, 17 May 2016 18:37:40 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.03.0248.002; Tue, 17 May 2016 18:37:32 -0400 From: "Cantor, Scott" To: John Bradley Thread-Topic: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) Thread-Index: AQHRsH/wUZPFP+71UkmQUk1veolL6Z+9mWgAgABZVQD//67NgIAAV/YA//+uIwA= Date: Tue, 17 May 2016 22:37:32 +0000 Message-ID: References: <838CA767-4DBF-401B-B072-0262C82158E8@osu.edu> <0FCCDAB0-D6DF-4329-B5EF-71611CA5216A@ve7jtb.com> In-Reply-To: <0FCCDAB0-D6DF-4329-B5EF-71611CA5216A@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [162.244.106.216] x-header-sapphire: true Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:164.107.81.220; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(24454002)(189002)(199003)(377454003)(110136002)(586003)(36756003)(92566002)(106466001)(2906002)(8666002)(4326007)(189998001)(86362001)(23676002)(88552002)(5008740100001)(93346002)(5003600100002)(3846002)(102836003)(1220700001)(11100500001)(6806005)(50466002)(19580395003)(5004730100002)(47776003)(109096001)(89122001)(50986999)(6116002)(2950100001)(8676002)(5250100002)(8936002)(19580405001)(16796002)(87936001)(106116001)(76176999)(54356999)(33656002)(90282001)(75432002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR01MB129; H:cio-tnc-pf06.osuad.osu.edu; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD048; 1:Lr/ceSpT4mAceH2weq1JOdXiLfuZ9izgMCJF0Z77sDi4abWmrS/s6cBr1J4GVfMB9dTKb/4VTW/ZIe7saDWLiK5bD02UWyAKKXOv134sNmEn5nTW7MnV0y1P0VfOE+MZ+7ZjIjOAMrtX+0CASKjAc3SSKy6/wQ6TK7eEml/PiwGU32X1SI4s9YFLR5qWWbp0ZPb2Nu6w3nDnazMw5fTIn1VOMfODShjcTkPrNrUifKKBzd17VNffqg0uyg+vdFfwp0Trq30ylrGgbwsi0cnYsg074MsqFCGPbd0PmILjzz9iPmHHtv9d4d6iq/YGd9d29aFGv0OAFEP0p8J/LMBIbxvcU0wxiaznnDcOQQRP0N8e8N/YQe/gZHqaFZNtR0584GmQShspLwxdfgTTIVnGUpJfwKhlBURaYKE+Q2I/LHBaxbdpdE8TjDiQPMAGjcGfJSHH8VO0FfgHaWC0HpMqX5QEw6gnJv64UOz3H6SYE7vV81MB7G0qTcCyEfMQj5zWL5k3azKsfedG+1hJXsnuCPdRufgy5mMVTXEADGiMz6+pkj5vZpNd9ElGEHBUUpg/ X-MS-Office365-Filtering-Correlation-Id: f6fcab16-fe6d-4c12-7355-08d37ea3dc32 X-Microsoft-Exchange-Diagnostics: 1; BLUPR01MB129; 2:NtHqAxgYl03QuQRgVgx+SN4Wf7jBY8qJkAloM6/shAOcfUhcqPTiXIxiaweDlJvlNYz53A4mDOY0Blv+aQJ9Zn72IWt/rSxrJz9JfUPONZpuwZU07LsJUA9Sr66mdNAtcWPy4oH1cwJb5hg7d1iCvjkRvp8o8F4Rec/XmbQrJs62Lb/0y4tvCYoF3Jp9ss5x; 3:kZdT253dwyRBrjtQ4fPQSz/0ecC0UVCWkhTKPU4YUVMXC+0FxM9J8QEVUeIg06a6LojCYqRdziBcVSG3ILZFFA3uBnJgFdfwSWIwXSrlJNy6Ma5ZD/aUpVMi8VufV/Gk++SSfZctXNQZq7Fu0K/WO5AQtSHK+0nIswsscICnPJgoVVfHNHhydYCNlPb+VEp3bcWqbPiegtSs1DPiemKxndEXu4MYORFHo7xT9WCzFL6ezOk9sUurSAIq8pTxrU3rlMQkoC8jKVxqZ1IShAbdcw==; 25:qy7xdwtDX9zzA4lsKmeKfI5AYn7sIzfhEc+pz3QHlQ5kpy7dcbWw8Zt1wiy+BbpX9SjjbEBF6OThXUCR8VnM5Ogk41L9nFOkZApq3u2TlWaDYJx90Di+SFX6Ch8VLzx+dOGG6jk4yKfCTkYPfSGP7p+O92fEUNKrRJCXVTWkqErksHsehTC3l+sg2sxWFVsYp3Kg/2+w1fGRp+/4+OtT6Iv9V17cnpYpPlY7EoJgmx9BPFkHAHlzweJjRgSjRfrgA0T7kBt1LiMamErAV7hJYFW+2+RjQX+wEsQmjLhHM8jHhDRZnPVlch+JlMFRXSL9vsAjsZFQMIr2Nd2G+FODXYilGtx7Z4ZNZCwISMG61ixZNaHVyye8rEqZcsNAPLTGZqohW1O2FgHNmfyJ5gkDEVDk2/0virt+RNJ5Qy6yqPI= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BLUPR01MB129; X-Microsoft-Exchange-Diagnostics: 1; BLUPR01MB129; 20:aG3ABlqB0YHldfKAfGo2tN1P5NmFGNYDs1PMsjRuNYQf/fs2bJkGi7EkDRF4DM6LmYyLhpZ8SqVDpvwye6tE2MC+a60r52nE+Kf2TQDCg+Q3m5fCJZYk0M1GZh9A1wkz7DtDZ5dYbql6bwGh3/1VU4jni2Tlj3nyVFJP2KrtUAF+Uzag3f7yoPDEy0c0MHPgHQ364638w/c+3mhgFOLeftfNbAwxXqOFjQLHCNGRhhTD2Ckcu9RqeeGJIw1CTyvJ7wF2nKis93KH00qNkG58/JD5lNdQNm08li2sxK9mhfZvs0It/d38+dlXGBUPdCuiBNt60pb2DctURK8QG+LMgBvgnpr8IYWZnO7tcoVenOlC73yG/i1mJsmAVMeSxj8sxxOPZntdoAfqGmkum9+FsJn8JfEgwcaKr6qG7klSa6faPIOF16ceNbyITZVJUticB+b0nV71PdtSwNbsExYU/GE572X84NiIdPlxpjueMaVmbfjJosKgnT5WAZnMz8Si; 4:ExeCPRAeGKIWJ1T5BWc2ngJvg+pYSAoP82f0RDupsEFO5QhqVyj3rWCbUaNnCaA/lyxwOfeCuM8Wqaw7sqGYuY+E33nv0VTNx85n20/bYc2OAn5+iMid8eMRt8OvWq06OMm4aK6O4uRBXfccPl/U4Uq85BFrdo3P4wGR0gWG9aXoIT5Y2lVWHvPUzOEThSMosrAkycFfncXw6+395Ky5jERdUibj5m8ASRN4DTz0o2MntpCYWddGotaLhADhY9tBz3Qlnl2mbXkOXoPOMIY6NkKx/sJpX8Cw3OIrCmZ7GqhVSblq6j21EGE4SErx+Lv+9ZC5wB/RpDIRmbbpssFvvwblsXq3MsHngD+JpfdXkNf+7jinCc5KnYPSqUNX9tgoakCyxCOLtMC14Jyj7+XhSZZCt+nOUVXLP2EEMKdx5s+5/dP5U+qhY9elAE1JIylG X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(13017025)(13015025)(5005006)(8121501046)(13024025)(13023025)(13018025)(3002001)(10201501046); SRVR:BLUPR01MB129; BCL:0; PCL:0; RULEID:; SRVR:BLUPR01MB129; X-Forefront-PRVS: 0945B0CC72 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjAxTUIxMjk7MjM6b2JIb1pFUmo0TGJ2Q24xS0dodlV3clgvUVZX?= =?utf-8?B?R29VUkl1MGtzUEVSNmtnMDk2OGRxOXVMR29ObEFJOFBVWU9Xam1XZnlucEJ4?= =?utf-8?B?NFlhYUZ6OC9menM3TU5Qdm1YTVY4RVRrRkxZd0FEdzNiNjE2S29ZbmZYREpi?= =?utf-8?B?VVpvSkZGOEVML3JJbDRqcTFrU0NnV2FySTJxNXJQeXVnZUJUT1BRT3ZpYndn?= =?utf-8?B?NGJYMkdNbjZBbTJDV2tSTFBONjRZTFB5SmxEcGtOL3lYTks1aXNWTzNvN29h?= =?utf-8?B?WGRGaFlxdXlRTFBPeFhwaFRndWhRWTQ0RWdwRW1La2Ivd0g1T3JiVnFWRUFk?= =?utf-8?B?cmZ2UGxyK1UyWDBvTksvOHY1Qk9hMUxtdEtlSXpZSFhYcmFXZXV4WForanJl?= =?utf-8?B?Szc5SUVab1RLM2RYOW9iQkJKT2JpbXJ5K3hmVlNRdjhCTVZ2VDZ4bmpjQkRm?= =?utf-8?B?UjhjZURnMVROZmFSaEFyYzNiKzFnZ2pBK1paaURDRVlmUEE5SSs0M3V3aXBh?= =?utf-8?B?ZFZXWUdBdklBR0VkRm1nbFlmb1J1aXF3WWo3UHVSalpaTkNqaW55VnlTUk02?= =?utf-8?B?R1lOY0grTHVhbmwxcFhNaWp6YkJqU1MvVDF6d2hnMkJWNkFhc1Bsd2Vyb01W?= =?utf-8?B?MmdsM3dYUnJ3SHJoRUYwTnl4THB3MmpPc0x3Q3ZBMVVKd3ptbUJLeXE0WTFm?= =?utf-8?B?K2I5bm9HNUVyMWRQTDVvTzM5OTl1UldPRTFzYlU3NEN5aUdIdXI2YndaVU9y?= =?utf-8?B?Ui9CaTRGdzlPdm01MDlvY2hVYlhnMkhlNm9DV0lUekxzOVNsd08xUHFmNWp3?= =?utf-8?B?VU91Z0p1S0RJL09PZW9ZQUNrN1I0SFFqdU9FZ1B5cEFRRGl1T2JOWVNBM2lY?= =?utf-8?B?SlFlQXprdWZHMjkzM0NsMW95TE9JbmdYZHdXcVFDSE9lUW1JK1Z4akppY1Jy?= =?utf-8?B?dlZ2SFppWDU1MUhtUmFwL0RvSCtVVktkL0JyUjRSUUs1cGpDaGd0N0F2Q2VG?= =?utf-8?B?RHQ4ZFB2azhrTzI2S0YyTWJ5amk1NXh1b3RwR1k5NmJ0WVN0bGtqUTJmVm5V?= =?utf-8?B?cDRNZ0dpRVBlTzZROUY1MTNMMExZQktuMUtwM2FKY2pYbThWamNyYit2d0dQ?= =?utf-8?B?eEJiZytnQ1RRRGZYcmJpUStoYW9sRzB4YnlDbEZvY292akpPdTRJTVNLNkRp?= =?utf-8?B?dHhTajRDd3MwRDFNbFVqbjZHWnFHNUNKU0d3aFlTT250S1lMSlYrZVdncG9J?= =?utf-8?B?WmxaUlFGVG9UYkthR3pFTUQyOWtvd0I4T2RicFVrRVlRMHA5Q21MRnVBTnRN?= =?utf-8?B?MzNTeHc0c1VZY2NQTTk4a283ODhlaDdla05IdjNQQi9VU3I3TFIzT3lPdjJm?= =?utf-8?B?bXBVekRXK2E5MFdkQzNQQXgyVExLay9MaHFrR1NjL0lSSnpTN0l0SExMZTZ6?= =?utf-8?B?U2JpbUhIdUpEemJ0N1IzaFg4VmRyUmFxaFRJY1JJMy9tOTAreFVWR09ZbWpm?= =?utf-8?B?RFlXRWpqc1B2Ymg5bHJROFBsdmlESDl1NE5uZE13anZZQzJyVzNmcTN2N08w?= =?utf-8?B?NHBJdWl1bGlRbGVZWm9nS3R0Um9YUXZoaEdWTisxNnM4aTd5VXlCV0RJdWhy?= =?utf-8?B?eWZmOVNLV09Ma2puMEhlYlZyRkxOZ0dEU1JVR1BOQXJRc3VkSnJiKzMrVHE0?= =?utf-8?Q?OiYjcbnszBorCxumE=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR01MB129; 5:cCeZBndq1qyyA8suV30KqJovnXupheCmvxWKFfeZr/JjTH8TzNK2JgUsSJg1HEDnbVCtLtNhH1Ila15FoBciSPqTb7aMbGZfElXhaWx9+cfYxKJ/7VZrDtLoPQrZywMnSduR+Qoka1veRdhyCx08Pg==; 24:jX6b29FV4j2JE89xqUnjZiwhtq502HO/dXBA6Lbzob46q3Gh9hAyhjo/6lwBO0rp5P/hvjVmKTOqWwke4GhnYm4DfqJ71SAiumMziZwntRg=; 7:to+XGKmkyyalqZV2GmlBBhc6cABhXeCfysY9z3/3cTf1BO3rCcVd/A+wJC6YQMY/Y0y0onjCnOabHSQqpXZih3Qk68Zc+JHTyYYMUbxfywsqBK0mIRH9XaEFZ0A2Rxqkr7GxMM8xQa2m1GDTQTqNfcizYZEI8Jc0emETFDGNX5JkeWJ3GNEHCWndtQp0hnhI; 20:MLMhXb+V9MaXHlKICeS1NqL08lqSdMLLMzyjQRjY2UujmVyu0Kb1XqdaKFkBn/y59Rl6elv1FlzIfghqLySoLS6+LkpxjU7Ee9t4xi6QhEC5lOQTMvtPyZAyDvuNBQo2hryJZDKHIL+Fj1non+plNeeWWC9nm0l54MKtSor7u0I= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2016 22:37:42.7342 (UTC) X-MS-Exchange-CrossTenant-Id: eb095636-1052-4895-952b-1ff9df1d1121 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=eb095636-1052-4895-952b-1ff9df1d1121; Ip=[164.107.81.220]; Helo=[cio-tnc-pf06.osuad.osu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR01MB129 Archived-At: Cc: Andrei Popov , Brian Campbell , IETF Tokbind WG Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 22:38:01 -0000 T24gNS8xNy8xNiwgNTozMCBQTSwgIkpvaG4gQnJhZGxleSIgPHZlN2p0YkB2ZTdqdGIuY29tPiB3 cm90ZToNCg0KDQoNCj5UTFMgdW5pcXVlIGlzIGluc2VjdXJlLiAgVGhhdCBjYXVzZWQgc29tZSBj aGFuZ2VzIHRvIHRva2VuIGJpbmRpbmcgdG8gcmVxdWlyZSB0aGUga2V5IHRvIHNpZ24gb3ZlciB0 aGUgRUtNIGluc3RlYWQuDQoNCkluc2VjdXJlIHdoZW4gdXNlZCBmb3IgQ0I/IEknbSBub3Qgc3Vn Z2VzdGluZyB0bHMtdW5pcXVlIGlzIHNvbWVob3cgdXNhYmxlICpoZXJlKi4NCg0KSSdtIG5vdCBz dWdnZXN0aW5nIHRoaXMgaXMgdGhlIHNhbWUgYXMgQ0IsIEknbSBiYXNpY2FsbHkgYXNraW5nIGlm IHRoaXMgcGFydGljdWxhciBkZXJpdmF0aW9uIG9mIHRoZSBUTFMgc2Vzc2lvbiBjb3VsZCBhbHNv IGJlIHVzZWQgYXMgYSBDQiB0eXBlIHdpdGhpbiBHU1MuDQoNCj5UaGlzIG1heSBiZSByZWxldmFu dCBmb3IgT0F1dGggb3ZlciBTQVNMIFJGQyA3NjI4IHdoZXJlIHlvdSB3YW50IHRvIHRva2VuIGJp bmQgYSBPQXV0aCBBVCBvdmVyIFNBU0wgZnJvbSBzYXkgYSBtYWlsIGNsaWVudC4NCg0KUmlnaHQu DQoNCi0tIFNjb3R0DQoNCg== From nobody Tue May 17 15:54:28 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6860F12D162 for ; Tue, 17 May 2016 15:54:25 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PTe8jPxI3z0 for ; Tue, 17 May 2016 15:54:23 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A323512B036 for ; Tue, 17 May 2016 15:54:22 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id n63so17710199qkf.0 for ; Tue, 17 May 2016 15:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NhvYCE2EFzwRbMVbB/UUAPIr0/BT+WXa+U3b4kiQuWQ=; b=VOLF0GzjuaLg/RIQNlnLImZao2t62509HhB+1q05YXMGC8s0y3feMQdv8YuL18Bcu8 b8TEfI998P02dFfhHiqYO9LtkEHKzuqk/QHesv+G7xT9c0ETIbUlLNLyETqkg/OY6BqH vwaPp6jtpO63bX/O5jXeX2id0O5RLsqXfOpi0E7/0CLiMLiJWCbUb6APWfjkgEmd5dtJ PPZlE9shSlXe4qfEb2/RXvdUAC8m6RpxCNVFBE4LCn2odqkxQva3Z2rBuE8HCJiiivxy UdMBu5HrsNF69j3TNchcl8cA1IeeFPZ8eve2J1mUFjD+VhH7UBjt1mcaVfXeP9/4v6Gn 3OUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NhvYCE2EFzwRbMVbB/UUAPIr0/BT+WXa+U3b4kiQuWQ=; b=EHCrIOG/g5EjZJr40Ka37FuInp9gnqDtOz35OszsJBuT1lSQbEB6VeJMlDSbtdjZGd KAbV2P6lOcCDtXU2LJrmmQR8Fi10xV0QmpcWgoF3pg3KxDAlaAsVUJSbi6nKpG5aVMHO O+xEhNogbnTsjt56fJVPud1k6wyy65O8pJjATVeeTpe1c923PvTFdra/8WKHLH1zBafh Nb7vU+cWmSxASud1OWRVQNKgkWGVe2ZR1GAXKrs5wiBfGFP4ezgpvjqqN9XdmXnaNtDY b9mnGcKgi3Wzh/S/sktQtgmTE9uunPrkwRtc7svf/80OU2S55c7ZWbpcT1frhfjXF1w/ iojw== X-Gm-Message-State: AOPr4FW+jDkFrYqj6ppxLEGHCMUIrrbbwIsCT/l2aAWiu7hOFSfG2iBbAnIfj1yoxHneAg== X-Received: by 10.55.181.67 with SMTP id e64mr4741667qkf.112.1463525661666; Tue, 17 May 2016 15:54:21 -0700 (PDT) Received: from [192.168.8.100] ([181.202.159.13]) by smtp.gmail.com with ESMTPSA id p128sm2592785qha.41.2016.05.17.15.54.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 17 May 2016 15:54:20 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Tue, 17 May 2016 19:54:20 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <838CA767-4DBF-401B-B072-0262C82158E8@osu.edu> <0FCCDAB0-D6DF-4329-B5EF-71611CA5216A@ve7jtb.com> To: Scott Cantor X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Andrei Popov , Brian Campbell , IETF Tokbind WG Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 22:54:25 -0000 The TLS unique is vulnerable to the 3 way handshake attack = https://mitls.org/pages/attacks/3SHAKE at-least for HTTP over TLS. =20 I am guessing that the same would apply to other protocols over TLS, but = don=E2=80=99t take my work for it. EKM RFC 5705 is what Token binding is using instead of TLS Unique. =20 John B. > On May 17, 2016, at 7:37 PM, Cantor, Scott wrote: >=20 > On 5/17/16, 5:30 PM, "John Bradley" wrote: >=20 >=20 >=20 >> TLS unique is insecure. That caused some changes to token binding to = require the key to sign over the EKM instead. >=20 > Insecure when used for CB? I'm not suggesting tls-unique is somehow = usable *here*. >=20 > I'm not suggesting this is the same as CB, I'm basically asking if = this particular derivation of the TLS session could also be used as a CB = type within GSS. >=20 >> This may be relevant for OAuth over SASL RFC 7628 where you want to = token bind a OAuth AT over SASL from say a mail client. >=20 > Right. >=20 > -- Scott >=20 From nobody Tue May 17 16:12:59 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB0A12D61D for ; Tue, 17 May 2016 16:12:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v14w73nLjOMi for ; Tue, 17 May 2016 16:12:56 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0137.outbound.protection.outlook.com [207.46.100.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4595612D1CB for ; Tue, 17 May 2016 16:12:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5ZAwNWMemcAFfoZ9FvK0AVGNOVzQLl16W6V5hncX0mM=; b=hno1bTycflNAc7aQCzIv4u2r9piqCBG0mrIgftfvfkqn5PEvUfsFe+/bzAlUJiOYgZ/hJCLXuw54ljCidmQnCWfmir2OPvPw56Jcm9m0ctOSvY2qsUP8WhefhzDKnm1Ui2TDTDwvGLHW2dY6yO7f6tun3VtXIf6Zfoj686NIOAg= Received: from BY1PR03MB1450.namprd03.prod.outlook.com (10.162.127.156) by BY1PR03MB1450.namprd03.prod.outlook.com (10.162.127.156) with Microsoft SMTP Server (TLS) id 15.1.497.12; Tue, 17 May 2016 23:12:55 +0000 Received: from BY1PR03MB1450.namprd03.prod.outlook.com ([10.162.127.156]) by BY1PR03MB1450.namprd03.prod.outlook.com ([10.162.127.156]) with mapi id 15.01.0497.019; Tue, 17 May 2016 23:12:55 +0000 From: Andrei Popov To: John Bradley , Scott Cantor Thread-Topic: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) Thread-Index: AQHRsH7NJR2mVJvqxkCfe/+qylCsN5+9qi+AgAAFggCAAAKfgIAABCQAgAAB9ACAAASyAIAAAckQ Date: Tue, 17 May 2016 23:12:54 +0000 Message-ID: References: <838CA767-4DBF-401B-B072-0262C82158E8@osu.edu> <0FCCDAB0-D6DF-4329-B5EF-71611CA5216A@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ve7jtb.com; dkim=none (message not signed) header.d=none;ve7jtb.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:e::1d2] x-ms-office365-filtering-correlation-id: 00032bbe-fb63-4700-c5ce-08d37ea8c72a x-microsoft-exchange-diagnostics: 1; BY1PR03MB1450; 5:qm+ZF1XKyTphSvMDBSb8LElxYFtGj99MrkEh3Ly/I3LH3Dnn7GIxYN1ft5YbPWeQZZGaaWpXBl0eKS7q9kYUOpzZ42K3cNqhqkdDOntJvmN9xPJ1DFQGjla71cpFrf6tue7eBbuI/ioxCTzfVCs6NA==; 24:T1tlvuJfg9o5S2qx9cVzFZJsbqW7R6ggzy26gpbuO+MdopOEXook2eUpcjrDiE1vu8ziNbxqqcXQ1nD4GMePP5SO8KxujRYrn21rm22zazM=; 7:hP48PrrPvQ7/r3EArEGqXVx7k+XiVY6PVl0ckrNjX9rQC/tgaKrL/FcL4yk3rD9OZiNc6ZzJrt677zh9d1kVg4VJ5brzTk6FoXGXFPjjv36JWfJBZqF23Y3sYZ19Us1SHW/ISq4DbmNx/MsCMg160iZ/6Q6WoMInyee7YW6wp4J5QYCxfbKl/DpVR73WJqn6VKY3/A5tmYmXruJhGLPJFw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR03MB1450; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BY1PR03MB1450; BCL:0; PCL:0; RULEID:; SRVR:BY1PR03MB1450; x-forefront-prvs: 0945B0CC72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(13464003)(11100500001)(50986999)(54356999)(106116001)(76176999)(9686002)(122556002)(8666002)(3660700001)(99286002)(5002640100001)(15975445007)(77096005)(1220700001)(5003600100002)(3280700002)(10090500001)(189998001)(2906002)(86362001)(4326007)(19580405001)(87936001)(76576001)(2171001)(8936002)(6116002)(102836003)(586003)(19580395003)(74316001)(8990500004)(10290500002)(10400500002)(2950100001)(81166006)(5005710100001)(5004730100002)(33656002)(92566002)(5008740100001)(8676002)(5001770100001)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR03MB1450; H:BY1PR03MB1450.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 May 2016 23:12:54.9040 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB1450 Archived-At: Cc: IETF Tokbind WG , Brian Campbell Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 17 May 2016 23:12:58 -0000 VHJpcGxlIGhhbmRzaGFrZSBhdHRhY2sgYWxsb3dzIE1JVE0gdG8gc3luY2hyb25pemUgVExTIG1h c3RlciBzZWNyZXRzIG9mIHRoZSBjbGllbnQtdG8tTUlUTSBUTFMgc2Vzc2lvbiBhbmQgdGhlIE1J VE0tdG8tc2VydmVyIFRMUyBzZXNzaW9uLg0KVGhpcyBkZWZlYXRzIGFsbCBiaW5kaW5ncyB0aGF0 IGFyZSBiYXNlZCBvbiBhIHByb2R1Y3Qgb2YgdGhlIFRMUyBtYXN0ZXIgc2VjcmV0LCBpbmNsdWRp bmcgdGhvc2UgYmFzZWQgb24gVExTLVVOSVFVRSBhbmQga2V5aW5nIG1hdGVyaWFsIGV4cG9ydGVy cy4NCkZvciB0aGlzIHJlYXNvbiwgVG9rZW4gQmluZGluZyBNVVNUIE5PVCBiZSB1c2VkIHdoZW4g RXh0ZW5kZWQgTWFzdGVyIFNlY3JldCAoRU1TKSBpcyBub3QgbmVnb3RpYXRlZC4gDQoNClNlcGFy YXRlbHksIFRMUy1VTklRVUUgaXMgd2VhaywgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIHRoZSB0cmlw bGUgaGFuZHNoYWtlIGF0dGFjayBpcyBtaXRpZ2F0ZWQuIFRoZXJlZm9yZSwgd2UgdXBkYXRlZCB0 aGUgVEIgZHJhZnRzIHRvIHVzZSBrZXlpbmcgbWF0ZXJpYWwgZXhwb3J0ZXJzLg0KDQpDaGVlcnMs DQoNCkFuZHJlaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSm9obiBCcmFk bGV5IFttYWlsdG86dmU3anRiQHZlN2p0Yi5jb21dIA0KU2VudDogVHVlc2RheSwgTWF5IDE3LCAy MDE2IDM6NTQgUE0NClRvOiBTY290dCBDYW50b3IgPGNhbnRvci4yQG9zdS5lZHU+DQpDYzogQW5k cmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT47IEJyaWFuIENhbXBiZWxsIDxi Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT47IElFVEYgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gSFRUUFNUQjogZGlzdGluY3QgaGVh ZGVyIGZvciB0aGUgcmVmZXJyZWQgVG9rZW4gQmluZGluZyAoaXNzdWUgIzM1KQ0KDQpUaGUgVExT IHVuaXF1ZSBpcyB2dWxuZXJhYmxlIHRvIHRoZSAzIHdheSBoYW5kc2hha2UgYXR0YWNrIGh0dHBz Oi8vbWl0bHMub3JnL3BhZ2VzL2F0dGFja3MvM1NIQUtFIGF0LWxlYXN0IGZvciBIVFRQIG92ZXIg VExTLiAgDQpJIGFtIGd1ZXNzaW5nIHRoYXQgdGhlIHNhbWUgd291bGQgYXBwbHkgdG8gb3RoZXIg cHJvdG9jb2xzIG92ZXIgVExTLCBidXQgZG9u4oCZdCB0YWtlIG15IHdvcmsgZm9yIGl0Lg0KDQpF S00gIFJGQyA1NzA1IGlzIHdoYXQgVG9rZW4gYmluZGluZyBpcyB1c2luZyBpbnN0ZWFkIG9mIFRM UyBVbmlxdWUuICANCg0KSm9obiBCLg0KDQoNCj4gT24gTWF5IDE3LCAyMDE2LCBhdCA3OjM3IFBN LCBDYW50b3IsIFNjb3R0IDxjYW50b3IuMkBvc3UuZWR1PiB3cm90ZToNCj4gDQo+IE9uIDUvMTcv MTYsIDU6MzAgUE0sICJKb2huIEJyYWRsZXkiIDx2ZTdqdGJAdmU3anRiLmNvbT4gd3JvdGU6DQo+ IA0KPiANCj4gDQo+PiBUTFMgdW5pcXVlIGlzIGluc2VjdXJlLiAgVGhhdCBjYXVzZWQgc29tZSBj aGFuZ2VzIHRvIHRva2VuIGJpbmRpbmcgdG8gcmVxdWlyZSB0aGUga2V5IHRvIHNpZ24gb3ZlciB0 aGUgRUtNIGluc3RlYWQuDQo+IA0KPiBJbnNlY3VyZSB3aGVuIHVzZWQgZm9yIENCPyBJJ20gbm90 IHN1Z2dlc3RpbmcgdGxzLXVuaXF1ZSBpcyBzb21laG93IHVzYWJsZSAqaGVyZSouDQo+IA0KPiBJ J20gbm90IHN1Z2dlc3RpbmcgdGhpcyBpcyB0aGUgc2FtZSBhcyBDQiwgSSdtIGJhc2ljYWxseSBh c2tpbmcgaWYgdGhpcyBwYXJ0aWN1bGFyIGRlcml2YXRpb24gb2YgdGhlIFRMUyBzZXNzaW9uIGNv dWxkIGFsc28gYmUgdXNlZCBhcyBhIENCIHR5cGUgd2l0aGluIEdTUy4NCj4gDQo+PiBUaGlzIG1h eSBiZSByZWxldmFudCBmb3IgT0F1dGggb3ZlciBTQVNMIFJGQyA3NjI4IHdoZXJlIHlvdSB3YW50 IHRvIHRva2VuIGJpbmQgYSBPQXV0aCBBVCBvdmVyIFNBU0wgZnJvbSBzYXkgYSBtYWlsIGNsaWVu dC4NCj4gDQo+IFJpZ2h0Lg0KPiANCj4gLS0gU2NvdHQNCj4gDQoNCg== From nobody Tue May 17 21:41:28 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A6112D0D8 for ; Tue, 17 May 2016 21:41:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YHMuYGmwfRR for ; Tue, 17 May 2016 21:41:25 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C19112DB05 for ; Tue, 17 May 2016 21:41:25 -0700 (PDT) X-AuditID: 12074422-927ff7000000760a-4a-573bf274be42 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 57.F0.30218.472FB375; Wed, 18 May 2016 00:41:24 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u4I4fNbn012437; Wed, 18 May 2016 00:41:23 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u4I4fJFY024863 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 May 2016 00:41:22 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u4I4fIW0020127; Wed, 18 May 2016 00:41:18 -0400 (EDT) Date: Wed, 18 May 2016 00:41:18 -0400 (EDT) From: Benjamin Kaduk To: "Cantor, Scott" In-Reply-To: Message-ID: References: <838CA767-4DBF-401B-B072-0262C82158E8@osu.edu> <0FCCDAB0-D6DF-4329-B5EF-71611CA5216A@ve7jtb.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUixCmqrVvyyTrc4NpnPosfk2YwW6z+f5PR ouWIuMW5xwuZLFbf/cvmwOqxZMlPJo/WHX/ZPZqvLmf3uHv0IovH7dsbWQJYo7hsUlJzMstS i/TtErgyHhxexFowma1i5dtt7A2M71i6GDk5JARMJHYd3M3UxcjFISTQxiQxp3EHI4SzkVHi 3eQFbBDOISaJP/+fQTkNjBL7Vp1mB+lnEdCWOHXhIyOIzSagIjHzzUY2EFtEQE1i9YK3zCAN zAL7GCUOn5kAtlBYIF7i+qzvYDangLVE75ddQM0cHLwCjhLNy/IhFtxklthw9D7YAlEBHYnV +6eA1fMKCEqcnPkEzGYW0JJYPn0bywRGgVlIUrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszL Sy3SNdXLzSzRS00p3cQICmh2F6UdjBP/eR1iFOBgVOLh3dBvHS7EmlhWXJl7iFGSg0lJlPeC CVCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO+bD0A53pTEyqrUonyYlDQHi5I4b1DksTAhgfTE ktTs1NSC1CKYrAwHh5IEr89HoEbBotT01Iq0zJwShDQTByfIcB6g4YkgNbzFBYm5xZnpEPlT jMYc6+beWMvEseDH7bVMQix5+XmpUuK8HSClAiClGaV5cNPASWk3k+orRnGg54R580CqeIAJ DW7eK6BVTECrJphZgKwqSURISTUwhrmIXelJT5q7/dqqx93qp8QbvWP3Lls+9aXcbcMD+lnx zzcnHOlWP7al+2/izT6mi/Pvbmisc9SdFlp+6pb9vVuHdO+qLs7ItD5/wmvirv1p7C+mnOzv ///VOZur0fOtplPPgp/9B67/udm1P+tts25Yj0Hu6i2WKR882OosZb7KG6vFq8+XVWIpzkg0 1GIuKk4EAJpYbo8lAwAA Archived-At: Cc: John Bradley , Andrei Popov , Brian Campbell , IETF Tokbind WG Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 04:41:27 -0000 On Tue, 17 May 2016, Cantor, Scott wrote: > On 5/17/16, 5:30 PM, "John Bradley" wrote: > > > > > I'm not suggesting this is the same as CB, I'm basically asking if this > particular derivation of the TLS session could also be used as a CB type > within GSS. I am not promising to do the research into the interactions between the token binding EKM material and GSS channel bindings, but the "normal" thing to do if one wants to bind a given TLS connection to a GSS-API security context exchanging messages over that TLS connection would be to define a new EKM for TLS that is used solely for that purpose. (Reusing crypto secrets is generally something to be avoided.) I don't think anyone has written up a draft for that yet, though... -Ben From nobody Wed May 18 08:58:55 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D034012D113 for ; Wed, 18 May 2016 08:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=buckeyemailosu.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MBQeZV3sjh4b for ; Wed, 18 May 2016 08:58:53 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0140.outbound.protection.outlook.com [207.46.100.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1012A12D0B8 for ; Wed, 18 May 2016 08:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buckeyemailosu.onmicrosoft.com; s=selector1-osu-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BGEWqOnvHVPHSrnHmWhF7zdE2fzvS0mtN8d2rrVAbDo=; b=HuyO4GlY9212FwLeav862k7NafQsqOOwf0xTGLap7yshIFoKbpx8kCNzB1GvYo+Z3sKhG8VWUv3yOmwBAbYsiLOPIMAXAobVYzx7Jd768scBWOh5US4tMSw5McYK7yJGG2V3N1nBK81ZpYFJsCZp8aogXskiraIpglWZsCD2/E4= Received: from CY1PR01CA0037.prod.exchangelabs.com (10.163.94.47) by BY2PR0101MB0872.prod.exchangelabs.com (10.160.123.155) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 18 May 2016 15:58:52 +0000 Received: from BY2FFO11FD028.protection.gbl (2a01:111:f400:7c0c::101) by CY1PR01CA0037.outlook.office365.com (2a01:111:e400:5290::47) with Microsoft SMTP Server (TLS) id 15.1.497.12 via Frontend Transport; Wed, 18 May 2016 15:58:51 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.212) smtp.mailfrom=osu.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=osu.edu; Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.212 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.212; helo=cio-krc-pf05.osuad.osu.edu; Received: from cio-krc-pf05.osuad.osu.edu (164.107.81.212) by BY2FFO11FD028.mail.protection.outlook.com (10.1.15.217) with Microsoft SMTP Server (TLS) id 15.1.497.8 via Frontend Transport; Wed, 18 May 2016 15:58:51 +0000 Received: from CIO-TNC-HT08.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1.2 with cipher AES256-SHA256 (256/256 bits)) (No client certificate requested) by cio-krc-pf05.osuad.osu.edu (Postfix) with ESMTPS id 8246260058; Wed, 18 May 2016 11:58:50 -0400 (EDT) Received: from CIO-KRC-D2MBX08.osuad.osu.edu ([fe80::3cdf:372e:4e57:db2a]) by CIO-TNC-HT08.osuad.osu.edu ([fe80::8431:784b:bd14:3d8%18]) with mapi id 14.03.0248.002; Wed, 18 May 2016 11:58:49 -0400 From: "Cantor, Scott" To: Benjamin Kaduk Thread-Topic: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) Thread-Index: AQHRsH/wUZPFP+71UkmQUk1veolL6Z+9mWgAgABZVQD//67NgIAAV/YA//+uIwCAALl0AIAAaXkA Date: Wed, 18 May 2016 15:58:47 +0000 Message-ID: <81A057BF-3714-4FAE-B61F-994456101F56@osu.edu> References: <838CA767-4DBF-401B-B072-0262C82158E8@osu.edu> <0FCCDAB0-D6DF-4329-B5EF-71611CA5216A@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.94.72] x-header-sapphire: true Content-Type: text/plain; charset="utf-8" Content-ID: <2F46AFF7CA22BC488134049349F36AA4@osu.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:164.107.81.212; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(377454003)(24454002)(189002)(51444003)(5383002)(199003)(86766002)(1220700001)(110136002)(102836003)(92566002)(6116002)(82746002)(19580395003)(83716003)(189998001)(93346002)(586003)(93886004)(8666002)(66066001)(11100500001)(16796002)(54356999)(5008740100001)(47776003)(6806005)(36756003)(88552002)(2950100001)(8936002)(5250100002)(76176999)(2900100001)(19580405001)(75432002)(50466002)(90282001)(50986999)(5004730100002)(23676002)(106466001)(33656002)(8676002)(109096001)(106116001)(4326007)(89122001)(87936001)(5003600100002)(2171001)(86362001)(2906002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0101MB0872; H:cio-krc-pf05.osuad.osu.edu; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD028; 1:4l0BZU/FBrypUUJ9Ef9aOnproFPP5iAD6WaLhRBNqjLYG0LllS6/1nbhzqqhB7UhGYOYH+VuSMZIbT6dGr80ktkaazJxLPvRpgWcW6HlE3G1Wbi/8gC9dYIqJxmWG1kgrRAapESEH/2eFPdHiPfz7UiMbYxdgsuJW+HVtB9v8MbzaI7tTUQdPUSzAqemd2fPqYS7miUlQoWgVKYrheoBMPOlwZLU9OfySpQbWdHe3yXpZSZptfggXtXBmDlqzxpMFvXe64rhp4qG/1bvUGA7Q3apbnxlFRGB7ZkuI9PTlOpJvYndfkLgipIioEEPMrss8P5OfTBObHNEAyDUr3fC+Ccn0Fj3/6eHf2GpDyYMDx9rG6beZYPMpo/o9FuI8Gl0uxtIcG5Y3iWg9W6wcPg/2AwEnLmhXxxM4pKeu1aDoPT2weFQZbxWpsNGU5bt/gMFFn+VwLrFHIbB/joCs7WLsYbJUqG6TpsMkTlEqXlopOyAhnB0m2fGMtcgbQQ4n54OOJ9ueG9T/G39HlYwWugGOQ== X-MS-Office365-Filtering-Correlation-Id: 893d4d70-0885-44f4-c42d-08d37f354e84 X-Microsoft-Exchange-Diagnostics: 1; BY2PR0101MB0872; 2:JcxVv8rJDwkRlqxdFNil2l/6Sj2lWGZOJ0aSX0c1FIpDwbk6zFsLA0pJb3A6U8Q4wsRd5N67YLYY0twpT8HQWF9EVBnu8aNEIAL2ExzRCDZKl5k+FMUdRoyJghPJQY4SM/TfVSj06PM1nBKXOVZqeJRy6AZFQLvGD6Q1f4Mj7wVXGFLGbk3M8IxeqQLHDDjQ; 3:BBW+qSjr+6iLBEj3NpfW/6EMEoKf1KAzpu+poS4muXWTIFHUdZS4YzDO7ycPPzHzZ+8bPzURqtB6+6CvN1UvLYptc8Hs0t7WzXLHbreiCfLHEQGO1r6f0EpniisXgPb4OuTE1QnqYwtyyvubEIM2wqRRt99hMTYSYNQUxkhUQ5kobreZSKRD1apqxepXxV3OKcsuVkNT04dicInMdfKebfN/DpHcdP+ypT4Y5AlGcxSSgM8QwtHQ9UgJcCDUfl5GVuA8TMdytGlq4K5qRgHIwQ==; 25:S+PT/CNg7q81WCcalbbESCa05Hm7J+pfkl4vjCJi5RkNVbbCnjnYmv5w9U+L1gFx+xVVd9tBVmsPl17xbG69NXM7ndMrrpfgVYUvRyPcSLHGAGkbBZ5UtPT63UX2sXbZYieHq42iIGDqz/o3nG9hSRcuazo+xEHKznOIvsenxGiqMb/HE9CQ6l0MrGZtyqPzC7cekgA5VQe4qUfXJuDLpsiJqWxHoJ9GjnvrmeymIEw2mq5r7zOPeA+QF1BPqEyEyw6/P9BJVoUNNBYzps+LsPIOyLsU0AWXBfFW2yH3lz+X2ncCx5n6QyP9CTJk3rjW8h6AmzIcMTMKx4gNf5qAv3RRdJajrT+nEMW2xZJhMxfP7H1cyoJVsVdJK3Cao4MO2JF/gYcCh5mDdOjaie1AcMQ/BFjfAo0lrAEvjrZcnM4= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BY2PR0101MB0872; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0101MB0872; 20:eLaK9+XLGdxtwVsTg0C5LK+HZ8z7wEGW/tP+gflQdZjn4/66WGb6HMs+PSiBCG0NU5fPHr1cP2MTQT6aKPZ7u8y5n/B1rKbXiLYqwxVKLieZX5RasXyRcClj6itGLt8t3yD9cAK5Vq5pQ1e/CZXxBDVTNuNlQSLszbku56HE3VbrKSIu93Cwt80Xcv3SscXr20TG86dVgpjQSYUXhHCbjPqfzs5PaFerFkFKK87DyVo0ITRTTCIxi1/+wPcKvbkNAd28tFOgxgHDb9BJw//XvlRMv3ZSKGt2ZPUBQw2HtyhRrR6SAyEPst0aQCLwC8gCusInruZxvPuN7pq60wqnsQJunRpmH+Hk/Zmn0GfMUMdbdJJJ+WKo3uVaSc8pyk15l7MBTfXZlFCML+i5AFbx3edANdr3Vx4a9/RKUilWBDuibFxi/n4fi25iFhsyl5m6HevQcQY+XPu3jFb48C5sMq7pRL/UQaqDVej3TjJjsiMXBqiMc66Xm5qrml3f3FLQ; 4:D3nt2yUA+MLS4dXcZL2ozlPp+bV7onemaFeW/et8/v55ErSKGqWgwDXnILpJ3q5xqPYXBobWSC8E6gi+nMwC7EJA3GJ8TXJ+wKsM+bAeL18z74zFDB7uCPQUdbndLw1KH9LwN7HUGWAch/zP5uQsgIXHDtO3IHdVKG5PJbw5ou1oIAGixG+e1KOY0SOFtBE+QUyV5A9JhXFvYzzjDGkWOHRWc2dYIzX2/uWTqTm5C6HovPN4Nt4553EGzMX/QiPa5EYACkmnuJBPov3CCv1hGjYnWFcs38540Vm+66Pelhd/GX+Dlrllv/x5om942WgcrFWscS1+sWOLaP5FTqjwvD7xdwiKidYGXwbdpo6dQSUWvnZwH5lH7R/wqTNl+jX/nc4mgjYDtQCuhKTSBjRDG5IKlPzj/3HJxCv2R4rQTyA= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(5005006)(13016025)(8121501046)(13023025)(13024025)(13018025)(10201501046)(3002001); SRVR:BY2PR0101MB0872; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0101MB0872; X-Forefront-PRVS: 0946DC87A1 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjAxMDFNQjA4NzI7MjM6VklJMkJyNEJZRXhiR1Q0SUFHN2FRNVNF?= =?utf-8?B?QXZUQTdPUVlpVDA2aEtIMkJ2WWxLWnErUmhjMWFCb3RoSGdzNlpRMXI3Z3Fo?= =?utf-8?B?b2tuQW5FMzZrQ3ZuZlVORUI0eFpuNmk3SE9DVFVjV1JONStXeU16dmFJcEFY?= =?utf-8?B?UU5jc1UxdUhKR1BVbUZXSUFMeDJ0QXkrZ2k3bnMrU0M4UllwNXVLUndIaEtJ?= =?utf-8?B?cEJLdEZrcEg3ejBLZWZ5MHVpNEl0RmZ2eWtLamtGRGRiRWxUR1FqVkVPVS93?= =?utf-8?B?K2pWanhoRVlNWHZuNS9RcGNudVNaV3c4eTZLSVMxbGl1TTI3TVVMYVgrQkp5?= =?utf-8?B?QWRQU0w5WHhVaTNETm5nc3l5RlEvdUZjSTlyTW9YK0grVmdzcTE4aVp2Rm5H?= =?utf-8?B?TEwxMEp2cXJ5cmVMZGdxcWhFekxPSW9zeXl4c2poRENGRUVDSHRpWWovcXJP?= =?utf-8?B?anhubFpPZVVWMmF2MEl3L3ZyNGpXUFVmZnJIdEJQUjR0Vm0wa05GVklXNWtp?= =?utf-8?B?TFRSblo5RnJVeWlXYlkxWWF6aDZYRDJTa2U4VkdmTnNvWUd5U2dvanVwemdJ?= =?utf-8?B?SmNPRWhyakhMcVhIU2VDYXN6aG1WQ25ZMlZlV01KZXFkN3lWcEdQVnZLeTUy?= =?utf-8?B?QjV2cHZVZXBRbTZ3S0h4UGxsTVdhTzAxMDFFREltWUpZaytLMXBJUVFFcmpj?= =?utf-8?B?STBWQjFaTktLN3NOdFlmRm9nNEFkaGJEb1NEMXhXamhxMEZRT1FLUi9FU0RD?= =?utf-8?B?M01xUGptTmUwUHNDUW83VnJja21SVmhCckp6RGpaTHVhTmE1Q2F0U0IxT1dY?= =?utf-8?B?RmhEMURibEZZUS9lM2J0YzRReVVBbUhGNzMrUEQ1bnMrYTRvUlNoUDlZcTBZ?= =?utf-8?B?KzNCTGVZQW95M0x1MEgrckZCUG5kdWRzMDFBeFNPMWNXSXA5bjhNaHpmVmdr?= =?utf-8?B?emZrMUpqVGJyQU9zTFJ2K09mKzViQXYvWDJnUWh4alB2OFVuVDM5NjI0LzYz?= =?utf-8?B?S0JYSkQ1NjJhK2FldnI4dzhtZWwwbXpDWWYyNEZ5NDlBNjdDVll6RkpLWC9J?= =?utf-8?B?OTJUSUxiNWpaR1ZYN0EvblBDY2ZreTluQTJ2c2lKRUdlLzJnREZmL3R1N1ZD?= =?utf-8?B?Y1JxcTdhT0FySzgzOUdQdXQzdlVjOCtTQTU0K29MeG1zVDJicS9GaW9HOWtX?= =?utf-8?B?ZlFCdXQ5WU1Hc0E1VDBOZWFiSWFHUjhyVitrOUpBUzVDQlpxRHkrUWNub25w?= =?utf-8?B?NkhrbGlkNjEzZ2xnMTAxcGhsWjV3UEFTWGR2cmJQRmQrcDVNbE0wVnprc0RM?= =?utf-8?B?K1RRZGRPRGloMklGQ3Z6cUxQMWhXb28wa3lrOWVXckNTWkQweGNIdVV1M0xU?= =?utf-8?B?Z0ZVZlpjVkR5eXpzYzZxNXJUWjg2aG5lSW1SVlBVVkY2VUxVSUdDbTBYdTdw?= =?utf-8?B?cFZvcTlPUFVjYVhSTFV2NlRaak04cG9hNG52cDVZRlQ3R0V1YVJMbGhLemdX?= =?utf-8?B?d1JsM1NBQjc4bkQ1Y3RzM3kwM3ZKRmdjNHl1M3lrZ0hUU1BPTm9kYWVJUEUr?= =?utf-8?B?SGN2bVRjZlIwdVlMWmd1eDUzVHN5aExaeEhDby9sTGxsenlZNTdSTW9hYTVs?= =?utf-8?B?UVdXRzlNNlQvY0ZGRitXTkQyNkNQamsvRUJubXpnUHhna1R5YktyU3R1OUxC?= =?utf-8?B?Ri9BYWk3ZzVmUEppTjh1QWtwT2FNcitUWVNPbGRJTDVDM1Y4S1ByTVRIOEZ3?= =?utf-8?B?SjlVWFFxY3ZUV0tFY1hwVU9MZ0FFVE9tY2ZzQ2hNSUt1Ti8zV00vVGFleHo2?= =?utf-8?B?ajhnckZEcUVKNURKRXlaajZrVnZZc0tRU002RnFCRE1MWmh5S3cwTWNiZnZT?= =?utf-8?B?bE5qcnRFTmhCRk80ZFNsZHhOS1FiRjJnSGIzeWtmRkgrd2lTWTFJQkJpYjdZ?= =?utf-8?B?WVd0TlA5VWhxbkE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR0101MB0872; 5:paWYtZoN1l62zcKEPNWP4Gau6f2esGBEVUbJfFIsiemNoBuVcM7s3ir0q5MnPCD+NvdpHrfWsJKvNQXYTCs1o7pP+hliYW1hFozeUf+POQGc2Vmk4dPRxVQnKdTpvfVpXDboCoZHlF2qt2AywJxjRA==; 24:+HVV27yB9b3NnNJA4IAjwWDbewlBAo//xKkVf+DDnMmJ5IS8Yax7UPXoSDTd4Uf0SzUDr5IlH1a/V/YvBeCvaTAckqPytOxhOyQpyWAujQY=; 7:afsE+lksgHaYwq4R3MTmuUzMVw03q8yjpjJ8sKnijm9yszJXCmAknMv5LuQc1KyonCV6m4IpvA+jIbnU5f+nRUCAn2+ouLmxcnk5K1f77JwSyhNHZG+iT8SkzR73zwAj+rtVG9t3NShueNDcCTYecsCjkRYmn5nYJ7AKycirSTY96f4Ed5fbbKVDdB9YGMyp; 20:Tl5d5TCzqRA5kcRE2jYUZxSxBV9LKd9Nv7jR2bRvmrrB486rHzRzc0fuj54ZKR3Sjy2tFEoF9fThATVEUxWcxr5zmWwpA6/+MplkYLhHWB5EDrzSyGQ8JM3CiR1VxUqX1gYr4TiXOXdc8ph2PePU5NwqdEGpW/Y8EE30wdT4ZAE= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 May 2016 15:58:51.4973 (UTC) X-MS-Exchange-CrossTenant-Id: eb095636-1052-4895-952b-1ff9df1d1121 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=eb095636-1052-4895-952b-1ff9df1d1121; Ip=[164.107.81.212]; Helo=[cio-krc-pf05.osuad.osu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0101MB0872 Archived-At: Cc: John Bradley , Andrei Popov , Brian Campbell , IETF Tokbind WG Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 15:58:55 -0000 T24gNS8xNy8xNiwgMTE6NDEgUE0sICJCZW5qYW1pbiBLYWR1ayIgPGthZHVrQE1JVC5FRFU+IHdy b3RlOg0KDQoNCg0KPkkgYW0gbm90IHByb21pc2luZyB0byBkbyB0aGUgcmVzZWFyY2ggaW50byB0 aGUgaW50ZXJhY3Rpb25zIGJldHdlZW4gdGhlDQo+dG9rZW4gYmluZGluZyBFS00gbWF0ZXJpYWwg YW5kIEdTUyBjaGFubmVsIGJpbmRpbmdzLCBidXQgdGhlICJub3JtYWwiDQo+dGhpbmcgdG8gZG8g aWYgb25lIHdhbnRzIHRvIGJpbmQgYSBnaXZlbiBUTFMgY29ubmVjdGlvbiB0byBhIEdTUy1BUEkN Cj5zZWN1cml0eSBjb250ZXh0IGV4Y2hhbmdpbmcgbWVzc2FnZXMgb3ZlciB0aGF0IFRMUyBjb25u ZWN0aW9uIHdvdWxkIGJlIHRvDQo+ZGVmaW5lIGEgbmV3IEVLTSBmb3IgVExTIHRoYXQgaXMgdXNl ZCBzb2xlbHkgZm9yIHRoYXQgcHVycG9zZS4NCg0KSWYgeW91IG1lYW4gdGhhdCBhIG5ldyBDQiB0 eXBlIGlzIG5lZWRlZCwgcHJvYmFibHkgc28uIElmIHlvdSBtZWFuIHJhdGhlciB0aGF0IENCIGFz IGEgbWVjaGFuaXNtIHNob3VsZCBub3QgYmUgdXNlZCB3aXRoIFRMUyBhdCBwcmVzZW50IHdpdGgg R1NTLCBJIHRoaW5rIHRoYXQgcHJvYmFibHkgc2hvdWxkIGJlIHN0YXRlZCBzb21ld2hlcmUuLi4N Cg0KQnV0IHRoaXMgaXMgbW9yZSBvZiBhIGtpdHRlbiBjb252ZXJzYXRpb24sIEkgb25seSByYWlz ZSBpdCBoZXJlIGluIGxpZ2h0IG9mIHRoZSBjb21tb24gcHJvYmxlbSBiZXR3ZWVuIGJvdGggdGhh dCB0aGUgbGFjayBvZiBzdXBwb3J0IGluIFRMUyBzdGFja3MgZm9yIGV4cG9zaW5nIHRoZSBuZWNl c3NhcnkgYml0cyBtYWtlcyBpbXBsZW1lbnRpbmcgZWl0aGVyIGRpZmZpY3VsdCBhdCBwcmVzZW50 Lg0KDQotLSBTY290dA0KDQo= From nobody Wed May 18 09:10:39 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBF812D18C for ; Wed, 18 May 2016 09:10:38 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_rTod3s21ox for ; Wed, 18 May 2016 09:10:36 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 842F812D16D for ; Wed, 18 May 2016 09:10:36 -0700 (PDT) Received: by mail-qg0-x230.google.com with SMTP id f74so28364806qge.2 for ; Wed, 18 May 2016 09:10:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZH6DhZ+ClD2pJ8Wtv3sEP9al97oN/Ccq7OKYqo3BO6k=; b=Wzo1JWtlgRP1OwVkF8hGbtktJkITUZUP/yjy42rnsE0FqxBypew2iNWiLMPDF41i8G gdooLyQBDF2LHS3UhlCKmjy1F+fsZEkE7V7x0MHLniSMtGh7ZVMGfmgpA8EFvDpBEFLm LmjFjHxTiLl5mkPoETYNqz8srcESwfhanxC4LMQxmtb5Bpp8+6XzfgW4Di7tY76BCdvO 2Eqf1CyU03w0C/FqB066UHwUZSOltZyGurRe4RW5+t5iKHCgw/9JH3RlnvQnxNLk+vUk 9xAnoPqqIVV/hIO96FKX4iZ3TKYuBBwSsfK31KMvpx63HYkbdKOZ8SEQiVACRjKR+wT3 H93g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZH6DhZ+ClD2pJ8Wtv3sEP9al97oN/Ccq7OKYqo3BO6k=; b=DVlusZ8c12VoldRypOxV2vaUOL4poACq7jJguM9tlb6yxjinQY3IJnyCI7q8Rj0Dpi hJ3x4pPYY3oNsOnieQ3EF3UTiRrAcWY1J6TacsAWrpFsQRTN1wWJxHXsPjGpuwn3xKAq qvu51BjlRtOS516v0UPO143ERIcezUin+tiuxMkSiMcQmr90OtprjCa70dWqjb8F0qfL X5qqy1ThklMMLOe1NGsTVd67AXK0TuTYvdQNp694jeE0P4rYYDkY5uFreizqQtQMtyhu FC+YuCy0vJhQDzIYlaszMxREjjMZyTO+xKkXBygAlMi1nouOz9s7bElQ+bn9SUUwATZh yX1A== X-Gm-Message-State: AOPr4FXrRioT8k49Lr+hyV0shlJostQHvl2HucBwOMz76zl8hPMMmZKdblMrS90WixDwxA== X-Received: by 10.141.3.66 with SMTP id f63mr8957852qhd.55.1463587835247; Wed, 18 May 2016 09:10:35 -0700 (PDT) Received: from [192.168.8.100] ([181.202.19.44]) by smtp.gmail.com with ESMTPSA id b99sm4474246qge.22.2016.05.18.09.10.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2016 09:10:34 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: <81A057BF-3714-4FAE-B61F-994456101F56@osu.edu> Date: Wed, 18 May 2016 12:10:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <838CA767-4DBF-401B-B072-0262C82158E8@osu.edu> <0FCCDAB0-D6DF-4329-B5EF-71611CA5216A@ve7jtb.com> <81A057BF-3714-4FAE-B61F-994456101F56@osu.edu> To: Scott Cantor X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF Tokbind WG , Andrei Popov , Brian Campbell , Benjamin Kaduk Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 16:10:38 -0000 If you are trying to do OAuth GSSAPI you may not want to have to refresh = the AT every time the EKM changes. =20 If the Token binding ID were used that could persist over multiple TLS = sessions.=20 Unfortunately I don=E2=80=99t know off hand what would beed to be done = on the GSS side to make that possible. It might be that using EKM directly and refreshing the AT with a token = bound refresh token might be the practical thing to avoid complicated = re-plumbing of GSSAPI. To use Token binding directly the GSS layer would need to validate the = TB message and pass the validated token binding id up the stack for the = application to validate the access token, or you would need to pass the = TB EKM plus the token binding message up the stack for the app to do all = of the token binding validation itself. I agree that getting support in the stacks for access to EKM export is = one of the first steps for deployment. John B. > On May 18, 2016, at 11:58 AM, Cantor, Scott wrote: >=20 > On 5/17/16, 11:41 PM, "Benjamin Kaduk" wrote: >=20 >=20 >=20 >> I am not promising to do the research into the interactions between = the >> token binding EKM material and GSS channel bindings, but the "normal" >> thing to do if one wants to bind a given TLS connection to a GSS-API >> security context exchanging messages over that TLS connection would = be to >> define a new EKM for TLS that is used solely for that purpose. >=20 > If you mean that a new CB type is needed, probably so. If you mean = rather that CB as a mechanism should not be used with TLS at present = with GSS, I think that probably should be stated somewhere... >=20 > But this is more of a kitten conversation, I only raise it here in = light of the common problem between both that the lack of support in TLS = stacks for exposing the necessary bits makes implementing either = difficult at present. >=20 > -- Scott >=20 From nobody Wed May 18 11:23:38 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAA812D63B for ; Wed, 18 May 2016 11:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlJjK3ejGtbb for ; Wed, 18 May 2016 11:23:36 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6759312D633 for ; Wed, 18 May 2016 11:23:36 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id 190so76349954iow.1 for ; Wed, 18 May 2016 11:23:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dfey9esGNByZGlAmhrHZHjW/mOcuPJeJVehYie/BAjQ=; b=EicfAPN7kI0zBu4ltGFR/6SkPs0DxsL6SkO1fl3t513AI3BZrkssAvClFv0lgT5LRR 9U17UEk1boPrFEHhA7fJIsZPGhD2a/1oynBpNvwSz7nE+o6Z3OFrW24CjFIFrTHOkZRX tSGBDCHXgaFH43LQHm5VXDZISHuBz8md8gSD8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Dfey9esGNByZGlAmhrHZHjW/mOcuPJeJVehYie/BAjQ=; b=fmJp6rLumI58tevalQgFSChyOTnK4c+vTX3nYs1rgniPhlWVEa4kL3//BeVHnQjZni jE+E+qmmo/7iJ1Nf9Ton7ze8LmZkB4xABdksrxqIgK5Rg/Pma3NFvBX5LpEGLYEqp5ZE bNd2rmDgswMTjjvzQpa/ZpC1YW3eyfxpnZ5J5w1D787/iGNOax4v61HboTIDMzvZvAEb YCRLtP/h5UmD9Y8KZ0W1fgI0TiTXtSUzIA/G6sdKcJFLNC+4gd1X8XAs1mGbNfgIMNXk dnqP0q+LYouTrHryxjkCPbDeXYLLLCMmCKZ1xLHaTXR+K+wK3V6FutRQXRIqDMupFe9Q y3yQ== X-Gm-Message-State: AOPr4FXjLESY5LQeRc7OZYq2ztu/+JZwEeiJ0uC4gmYRfc0+5HGnmBn9P3DAoIb+27RFMyuEeh7xEtlkFWiH4AF/ X-Received: by 10.36.108.76 with SMTP id w73mr6770926itb.63.1463595815697; Wed, 18 May 2016 11:23:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.105.129 with HTTP; Wed, 18 May 2016 11:23:06 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 18 May 2016 12:23:06 -0600 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a1145bcb4b0a3bb053321f466 Archived-At: Cc: Scott Cantor , Andrei Popov , IETF Tokbind WG Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 18:23:37 -0000 --001a1145bcb4b0a3bb053321f466 Content-Type: text/plain; charset=UTF-8 On Tue, May 17, 2016 at 4:06 PM, John Bradley wrote: > > There are people looking at what the best approach fro Java will be > (Including Brian) > > Yes, I plan to dig into it and see what can be done server side in Java and/or what the major obstacles are. I do expect it'll be rather challenging/painful though so I've been biding my time before jumping in by doing some review and feedback on the current drafts. --001a1145bcb4b0a3bb053321f466 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, May 17, 2016 at 4:06 PM, John Bradley <ve7jtb@ve7jtb.com&g= t; wrote:

There are people looking at what the best approach fro Java will be (Includ= ing Brian)


Yes, I plan to dig into it and see wha= t can be done server side in Java and/or what the major obstacles are. I do= expect it'll be rather challenging/painful though so I've been bid= ing my time before jumping in by doing some review and feedback on the curr= ent drafts.=C2=A0

--001a1145bcb4b0a3bb053321f466-- From nobody Wed May 18 11:30:28 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 967E412D630 for ; Wed, 18 May 2016 11:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doXR3tYIxesc for ; Wed, 18 May 2016 11:30:24 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28A012D607 for ; Wed, 18 May 2016 11:30:23 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id i75so76716396ioa.3 for ; Wed, 18 May 2016 11:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cNtip8s4F480tawqrUmf5mKujcfxXxYYKuTg4kxF4zo=; b=VvWmQNtcYlgktLEiNkrNYvB6kzu6Y7uQzkAJJdH3ywQy7bES8r+jKYX68mmGe9wjek E8r4T1BuXLtSsnMTA7va/Gv4BMqzOedD+58WiB3pj3EDzLoi5Fm3uUMUdYi89o9uxJfp ogO5SN3L+rXjqw/oxpKScDbclZPiQ/rZGva1Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cNtip8s4F480tawqrUmf5mKujcfxXxYYKuTg4kxF4zo=; b=OI384xPf6b72EWAY6gP8xzQQLbiMIpjoKURNRCnM78RqhA1TGn8+C2wDE0hKihaz05 5uRSkdQmIkFZJMT6ivT3YhEn0uGP6K929WrbvkL06yPrksGDFTIz70TbRu78gkssNM96 YcjRQYqaGP6cERsZ6wcpiGZ6ei7IP8h6NaNuxc25KHTK+crnXfr3+tOTJEHGStms3Q5P oOmVxhJUYd7dKAMvuAevmDYgaeIxHPLyfk5laIjPmeZoOGwcZj9ykRf8OBl7N6JghYu6 TXpkR3MZDcA8yT9FY3EbNXx576AalNJNn6eTUPLaeIzRo4AM1Hw58NchciERAmXfodeC ks1Q== X-Gm-Message-State: AOPr4FU6zr+n7/zT+zMXwEEXd0SEROcFFTVfoDXdHiKNKQzefJwxVfRY7hN/WOcYmTa4AhMUfPNVMLoecOu3dM13 X-Received: by 10.107.8.141 with SMTP id h13mr6632118ioi.95.1463596223002; Wed, 18 May 2016 11:30:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.105.129 with HTTP; Wed, 18 May 2016 11:29:53 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 18 May 2016 12:29:53 -0600 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a113f9ab0f7ad530533220cd6 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 18:30:26 -0000 --001a113f9ab0f7ad530533220cd6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Arguing on the internet is usually about this effective in swaying one viewpoint or the other. I appreciate the discourse though and, short of a mad rush of support, I concede on the proposal. On Tue, May 17, 2016 at 4:35 PM, Andrei Popov wrote: > =C3=98 The HTTP layer does need to know about TB for TB to be of any val= ue - > that's where the signature(s) get verified and where cookies and other > tokens are actually bound. > > With the current TB message structure, the HTTP layer can simply pass the > contents of the header to the TB library, get back verified bindings and > act on the ones that the HTTP layer understands. And I like the fact that > currently the TB library gets all available TB information at one time an= d > in one piece. > > > > =C3=98 But my point isn't that it can't be done. It's that it's really u= seful > to be able to look at HTTP and tell whats going on without having to use = a > protocol analyzer or TB parser. > > Understood. I=E2=80=99m merely pointing out that e.g. when debugging an i= ssue, > it=E2=80=99s usually not enough to see what types of bindings were sent, = so > generally one can=E2=80=99t avoid parsing TokenBinding messages anyway, a= nd parsing > tools will likely become available. > > > > =C3=98 It's not an optimization but rather just a simplification where t= he > provided TB is always sent the same way no matter what and the > referrer/referred is processed independently > > Provided and referred bindings can=E2=80=99t be processed entirely indepe= ndently: > e.g. referred binding cannot be used if the provided one fails > verification. A TB library can only ensure this if it has access to all > available bindings. > > > > =C3=98 But I was looking the share the viewpoint of what seems simpler a= t the > HTTP layer from someone who works primarily at the HTTP layer. > > To be clear, I highly value your viewpoint, although I disagree with it. > Bringing it up on the mailing list is certainly the right thing to do. > > > > Cheers, > > > > Andrei > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Tuesday, May 17, 2016 1:57 PM > *To:* Andrei Popov > *Cc:* IETF Tokbind WG > *Subject:* Re: [Unbearable] HTTPSTB: distinct header for the referred > Token Binding (issue #35) > > > > Despite my lack of agreement, Andrei, I appreciate the reply. My replies > inline below... > > > > On Tue, May 17, 2016 at 11:21 AM, Andrei Popov > wrote: > > Hi Brian, > > > > The current format, where all Token Bindings are contained in one Token > Binding message, provides useful encapsulation. The HTTP layer does not > need to know the details of the Token Binding protocol, which can be > implemented in a separate library. If tomorrow we define a new Token > Binding type, an existing HTTP implementation can carry it in the > Sec-Token-Binding header without modification. Only the Token Binding > library would need to be updated. > > > > The HTTP layer does need to know about TB for TB to be of any value - > that's where the signature(s) get verified and where cookies and other > tokens are actually bound. If a new Token Binding type is defined (which > honestly seems unlikely), yes it could be carried in the current format b= ut > the HTTP layer would also need to be updated to do anything useful with i= t. > I don't see the benefit of this encapsulation. > > =C3=98 At the HTTP layer separate headers will make it much more clear w= hat > is going on. Just looking for the presence or absence of the > Sec-Referred-Token-Binding header will indicate if a referred TB was sent= , > which is very easy. > > This can be solved by including a TB parser in the protocol analyzer. > Which would also provide further useful insights into TB key parameters, > etc. > > > > But my point isn't that it can't be done. It's that it's really useful to > be able to look at HTTP and tell whats going on without having to use a > protocol analyzer or TB parser. > > > =C3=98 Having a separate header for the referred TB allows the client/us= er > agent to always send the provided TB via Sec-Token-Binding and not have t= o > build a new TB message on the redirect request and then go back to the > provided TB on subsequent requests. > > I don=E2=80=99t think there=E2=80=99s an optimization an HTTP stack can d= o WRT building TB > messages that a Token Binding library can=E2=80=99t, and the Token Bindin= g library > is where such optimizations belong. > > > > It's not an optimization but rather just a simplification where the > provided TB is always sent the same way no matter what and the > referrer/referred is processed independently. To my eye, that's better > cohesion and less coupling. > > HTTP/2 header compression, however, is an optimization in the HTTP layer > that would be helped by having the provided TB header not change. > > > > > > For the above reasons, I would prefer to keep all Token Bindings in one > Token Binding message. > > > > > I got a pretty good idea of your preference when I first mentioned > separate headers in BA :) My preference is obviously different and I want= ed > to voice that on the list/github. But I guess ultimately it's an aestheti= cs > or eye of the beholder kind of thing. I won't fight about it too hard. An= d > I'm just a guy, not an editor. But I was looking the share the viewpoint = of > what seems simpler at the HTTP layer from someone who works primarily at > the HTTP layer. I hope that viewpoint can be considered even though two > headers is different than what's already done. > > I'd also be interested in knowing if others in the WG have opinions here > or if I'm the outlier? > > > > > Cheers, > > > > Andrei > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Br= ian > Campbell > *Sent:* Monday, May 16, 2016 1:22 PM > *To:* IETF Tokbind WG > *Subject:* [Unbearable] HTTPSTB: distinct header for the referred Token > Binding (issue #35) > > > > It seems like github recently started sending some notifications to the W= G > list but it's not clear how reliable that is so I'm gonna double post > anyway. The text from > https://github.com/TokenBinding/Internet-Drafts/issues/35 follows. > > As mentioned at IETF 95 > I propose that the > referred Token Binding be sent via a separate header (say > Sec-Referred-Token-Binding) rather than as part of the Sec-Token-Binding > header. > > At the HTTP layer separate headers will make it much more clear what is > going on. Just looking for the presence or absence of the > Sec-Referred-Token-Binding header will indicate if a referred TB was sent= , > which is very easy. Rather than having to decode the Sec-Token-Binding > header value and process the binary content, which is possible but much > more involved. > > Having a separate header for the referred TB allows the client/user agent > to always send the provided TB via Sec-Token-Binding and not have to buil= d > a new TB message on the redirect request and then go back to the provided > TB on subsequent requests. Also not having the value of Sec-Token-Binding > change (other then a new TLS session with new EKM) should make it nicely > efficient with HTTP/2 header compression. > > I also believe it will be easier to covey the concepts in the text of the > spec. Talking about when the Sec-Referred-Token-Binding is sent or not se= nt > rather than talking about when the referred TB is included as part of the > TB message that is sent with Sec-Token-Binding seems much more > straightforward. > > Anecdotally, there's been some discussion about using TB in OpenID Connec= t > and and in talking about it people often say "the referred token binding > header", which isn't accurate relative to HTTPSTB-03 but belies the fact > that federation folks already think about it as separate header. And I > think that's a natural way think about it so it's not terribly surprising= . > I won't name any names but one of the chairs of the WG is among those who > said "the referred token binding header." > > I realize this is not an insignificant change but I strongly believe it'd > be a simplification and improvement for HTTPS TB. There's not yet (that I= 'm > aware of anyway) any profiling of TB for federation like protocols such > OpenID Connect, OAuth or SAML so this would be an opportune time to chang= e > how the referred Token Binding is conveyed. > > > > > --001a113f9ab0f7ad530533220cd6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Arguing on the internet is usually about this effecti= ve in swaying one viewpoint or the other.

I appreciate the di= scourse though and, short of a mad rush of support, I concede on the propos= al.

On Tue, May 17, 2016 at 4:35 PM, Andrei Popov <Andrei.Popov@micr= osoft.com> wrote:

=C3=98<= span style=3D"font:7.0pt "Times New Roman"">=C2=A0 The HTTP layer do= es need to know about TB for TB to be of any value - that's where the s= ignature(s) get verified and where cookies and other tokens are actually bo= und.

With the current TB message structure= , the HTTP layer can simply pass the contents of the header to the TB libra= ry, get back verified bindings and act on the ones that the HTTP layer understands. And I like the fact that currently t= he TB library gets all available TB information at one time and in one piec= e.

=C2=A0

=C3=98=C2= =A0 But my point isn&= #39;t that it can't be done. It's that it's really useful to be= able to look at HTTP and tell whats going on without having to use a proto= col analyzer or TB parser.

Understood. I=E2=80=99m merely pointi= ng out that e.g. when debugging an issue, it=E2=80=99s usually not enough t= o see what types of bindings were sent, so generally one can=E2=80=99t avoid parsing TokenBinding messages anyway, and parsing tools will likely = become available.

=C2=A0

=C3=98=C2= =A0 It's not an o= ptimization but rather just a simplification where the provided TB is alway= s sent the same way no matter what and the referrer/referred is processed i= ndependently

Provided and referred bindings can=E2= =80=99t be processed entirely independently: e.g. referred binding cannot b= e used if the provided one fails verification. A TB library can only ensure this if it has access to all available bindings.=

=C2=A0

=C3=98=C2= =A0 But I was looking= the share the viewpoint of what seems simpler at the HTTP layer from someo= ne who works primarily at the HTTP layer.

To be clear, I highly value your view= point, although I disagree with it. Bringing it up on the mailing list is c= ertainly the right thing to do.

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingiden= tity.com]
Sent: Tuesday, May 17, 2016 1:57 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: IETF Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred = Token Binding (issue #35)

=C2=A0

Despite my lack of agr= eement, Andrei, I appreciate the reply. My replies inline below...

=C2=A0

On Tue, May 17, 2016 at 11:21 AM, Andrei Popov <<= a href=3D"mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov= @microsoft.com> wrote:

Hi Brian,

=C2=A0

The current format, where all Token B= indings are contained in one Token Binding message, provides useful encapsulation. The HTTP layer does not need to know the details of the Tok= en Binding protocol, which can be implemented in a separate library. If tom= orrow we define a new Token Binding type, an existing HTTP implementation c= an carry it in the Sec-Token-Binding header without modification. Only the Token Binding library would need to = be updated.

=C2=A0

The HTTP layer does need to know about TB for TB to be of any valu= e - that's where the signature(s) get verified and where cookies and ot= her tokens are actually bound.=C2=A0 If a new Token Binding type is defined (which honestly seems unlikely), yes it could be c= arried in the current format but the HTTP layer would also need to be updat= ed to do anything useful with it. I don't see the benefit of this encap= sulation.

=C3= =98=C2=A0 At the HTTP layer separate headers will make it muc= h more clear what is going on. Just looking for the presence or absence of = the Sec-Referred-Token-Binding header will indicate if a referred TB was sent, which is very easy.

This can be solved by including a TB = parser in the protocol analyzer. Which would also provide further useful insights into TB key parameters, etc.

=C2=A0

But my point isn't= that it can't be done. It's that it's really useful to be able= to look at HTTP and tell whats going on without having to use a protocol a= nalyzer or TB parser.
=C2=A0

=C3= =98=C2=A0 Having a separate header for the referred TB allows= the client/user agent to always send the provided TB via Sec-Token-Binding= and not have to build a new TB message on the redirect request and then go back to the provided TB on subsequent request= s.

I don=E2=80=99t think there=E2=80=99s= an optimization an HTTP stack can do WRT building TB messages that a Token= Binding library can=E2=80=99t, and the Token Binding library is where such optimiz= ations belong.

=C2=A0

It's not an optimization but rather just a simplification wher= e the provided TB is always sent the same way no matter what and the referr= er/referred is processed independently. To my eye, that's better cohesion and less coupling.

HTTP/2 header compression, however, is an optimization in the HTTP layer th= at would be helped by having the provided TB header not change.

=C2=A0

=C2=A0

For the above reasons, I would prefer= to keep all Token Bindings in one Token Binding message.

=C2=A0


I got a pretty good idea of your preference w= hen I first mentioned separate headers in BA :) My preference is obviously = different and I wanted to voice that on the list/github. But I guess ultima= tely it's an aesthetics or eye of the beholder kind of thing. I won't fight about it too hard. And I'= ;m just a guy, not an editor. But I was looking the share the viewpoint of = what seems simpler at the HTTP layer from someone who works primarily at th= e HTTP layer. I hope that viewpoint can be considered even though two headers is different than what's already= done.

I'd also be intere= sted in knowing if others in the WG have opinions here or if I'm the ou= tlier?


=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ie= tf.org] On Behalf Of Brian Campbell
Sent: Monday, May 16, 2016 1:22 PM
To: IETF Tokbind WG <unbearable@ietf.org>
Subject: [Unbearable] HTTPSTB: distinct header for the referred Toke= n Binding (issue #35)

=C2=A0

It seems like github = recently started sending some notifications to the WG list but it's not= clear how reliable that is so I'm gonna double post anyway. The text f= rom https://github.com/TokenBinding/Internet-Drafts/issues/35 follows.

As mentioned=C2=A0at IETF 95=C2=A0I propose that the referred Token Binding be sent via a separate header (say Sec-Referred= -Token-Binding) rather than as part of the Sec-Token-Binding header.=

At the HTTP layer separate headers will make it much more = clear what is going on. Just looking for the presence or absence of the Sec= -Referred-Token-Binding header will indicate if a referred TB was sent, which is very easy. Rather than having to decod= e the Sec-Token-Binding header value and process the binary content, which = is possible but much more involved.

Having a separate header for the referred TB allows the cl= ient/user agent to always send the provided TB via Sec-Token-Binding and no= t have to build a new TB message on the redirect request and then go back to the provided TB on subsequent requests. Also n= ot having the value of Sec-Token-Binding change (other then a new TLS sessi= on with new EKM) should make it nicely efficient with HTTP/2 header compres= sion.

I also believe it will be easier to covey the concepts in = the text of the spec. Talking about when the Sec-Referred-Token-Binding is = sent or not sent rather than talking about when the referred TB is included as part of the TB message that is sent with Se= c-Token-Binding seems much more straightforward.

Anecdotally, there's been some discussion about using = TB in OpenID Connect and and in talking about it people often say "the= referred token binding header", which isn't accurate relative to HTTPSTB-03 but belies the fact that federation folks already t= hink about it as separate header. And I think that's a natural way thin= k about it so it's not terribly surprising. I won't name any names = but one of the chairs of the WG is among those who said "the referred token binding header."

I realize this is not an insignificant change but I strong= ly believe it'd be a simplification and improvement for HTTPS TB. There= 's not yet (that I'm aware of anyway) any profiling of TB for federation like protocols such OpenID Connect, OAuth or SAML so = this would be an opportune time to change how the referred Token Binding is= conveyed.

=C2=A0

=C2=A0


--001a113f9ab0f7ad530533220cd6-- From nobody Wed May 18 12:15:50 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C31F12D652 for ; Wed, 18 May 2016 12:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOVF-YEh3Tvm for ; Wed, 18 May 2016 12:15:47 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0127.outbound.protection.outlook.com [65.55.169.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F679128B44 for ; Wed, 18 May 2016 12:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FLCboWh3SarumHnRpi3NjUxdwFqOyrACn0QMiL0N7XE=; b=DtPRE3HPxQzhLSTyzc8XVaF2PAzfXffJJau8ET/KdNBWtKhXW43KmuD8fT4J6s2MgixRSwIH1drWkIHzL6oVpQLc4YAwZGC+4wLDdB8Ux9z8mJjY4DZ0scWc1socUJCQCgXgT4PUKDxTX3Mcz2AX9R13th+QILJd4qHSqPQ3R2s= Received: from BN3PR0301MB1234.namprd03.prod.outlook.com (10.161.207.22) by BY1PR03MB1449.namprd03.prod.outlook.com (10.162.127.155) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 18 May 2016 19:15:45 +0000 Received: from BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) by BN3PR0301MB1234.namprd03.prod.outlook.com ([10.161.207.22]) with mapi id 15.01.0492.020; Wed, 18 May 2016 19:15:44 +0000 From: Anthony Nadalin To: John Bradley , Scott Cantor Thread-Topic: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) Thread-Index: AQHRsGCSshtGmFIG6UewA/gZmTHgCZ+9nLGAgAANuoCAAAWCAIAAAp+AgAAEJACAAAH1AIAAZaMAgAC9SYCAAANFgIAAM1kQ Date: Wed, 18 May 2016 19:15:44 +0000 Message-ID: References: <838CA767-4DBF-401B-B072-0262C82158E8@osu.edu> <0FCCDAB0-D6DF-4329-B5EF-71611CA5216A@ve7jtb.com> <81A057BF-3714-4FAE-B61F-994456101F56@osu.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ve7jtb.com; dkim=none (message not signed) header.d=none;ve7jtb.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:7::6] x-ms-office365-filtering-correlation-id: e971933a-9d03-42cd-2d60-08d37f50cf9f x-microsoft-exchange-diagnostics: 1; BY1PR03MB1449; 5:aZtrlavYy7H0KIEOFjXfp5J0Sqh8QfAyUb6ioVUjJg4Cn7a6tjq0LJAoqzPpm6y7octWBK/FEtlhz+zJqqdEBB0PuQtwDXQAL/TsnzHLQHnunhYMXhTa4HChLh6p7GEKdRTezALG7nOc/YaKlQ5ULQ==; 24:AjFiEPRik1bXzSuCJfgyGdt36I7+btG2JbPX0OsmBMN4No+WU+FEN01L+kOHCSVJWYMU90oSgHlXn8Fx15NM4gXly3tPWavcHOPHyW7qymM=; 7:ElLtnQzWls/mGDY3F8jsH6yegr0nbigYSE7RPsIr7v+zB/WUlVjPo4dWGiGHzxPur3x8Sp6VdXzo3ogl8DCztj24FRUPe2qDKpZ82Tl8/+sc2BE+6dvNjaOtZn1s6VYoYgGWHQaIxyrgpyAuDD3WwYAciUq6OcoZcTxGU1Irido= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR03MB1449; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BY1PR03MB1449; BCL:0; PCL:0; RULEID:; SRVR:BY1PR03MB1449; x-forefront-prvs: 0946DC87A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(5383002)(106116001)(5005710100001)(76176999)(50986999)(10400500002)(54356999)(1220700001)(4326007)(5002640100001)(586003)(10090500001)(19580405001)(8990500004)(99286002)(93886004)(19580395003)(10290500002)(5008740100001)(77096005)(122556002)(575784001)(81166006)(5004730100002)(8666002)(87936001)(8936002)(2906002)(3660700001)(33656002)(5003600100002)(86612001)(5001770100001)(2900100001)(8676002)(3280700002)(74316001)(2950100001)(15975445007)(2171001)(9686002)(92566002)(86362001)(189998001)(102836003)(6116002)(7059030)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR03MB1449; H:BN3PR0301MB1234.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.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 May 2016 19:15:44.3048 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR03MB1449 Archived-At: Cc: IETF Tokbind WG , Brian Campbell , Andrei Popov , Benjamin Kaduk Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 19:15:49 -0000 VGhlIGNoYW5nZSB0byBKYXZhIChKU1NFKSBpcyBzdHJhaWdodCBmb3J3YXJkLCBidXQgZ2V0dGlu ZyB0aGF0IGNoYW5nZSBtYWRlIGFuZCBvdXQgaW50byB0aGUgdmFyaW91cyB2ZXJzaW9ucy9pbXBs ZW1lbnRhdGlvbnMgb2YgSlNTRSBpcyBhIGRpZmZlcmVudCBzdG9yeSANCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2huIEJyYWRsZXkNClNlbnQ6IFdlZG5lc2RheSwg TWF5IDE4LCAyMDE2IDk6MTAgQU0NClRvOiBTY290dCBDYW50b3IgPGNhbnRvci4yQG9zdS5lZHU+ DQpDYzogSUVURiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPjsgQW5kcmVpIFBvcG92 IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT47IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxA cGluZ2lkZW50aXR5LmNvbT47IEJlbmphbWluIEthZHVrIDxrYWR1a0BNSVQuRURVPg0KU3ViamVj dDogUmU6IFtVbmJlYXJhYmxlXSBIVFRQU1RCOiBkaXN0aW5jdCBoZWFkZXIgZm9yIHRoZSByZWZl cnJlZCBUb2tlbiBCaW5kaW5nIChpc3N1ZSAjMzUpDQoNCklmIHlvdSBhcmUgdHJ5aW5nIHRvIGRv IE9BdXRoIEdTU0FQSSB5b3UgbWF5IG5vdCB3YW50IHRvIGhhdmUgdG8gcmVmcmVzaCB0aGUgQVQg ZXZlcnkgdGltZSB0aGUgRUtNIGNoYW5nZXMuICAgDQpJZiB0aGUgVG9rZW4gYmluZGluZyBJRCB3 ZXJlIHVzZWQgdGhhdCBjb3VsZCBwZXJzaXN0IG92ZXIgbXVsdGlwbGUgVExTIHNlc3Npb25zLiAN Cg0KVW5mb3J0dW5hdGVseSBJIGRvbuKAmXQga25vdyBvZmYgaGFuZCB3aGF0IHdvdWxkIGJlZWQg dG8gYmUgZG9uZSBvbiB0aGUgR1NTIHNpZGUgdG8gbWFrZSB0aGF0IHBvc3NpYmxlLg0KDQpJdCBt aWdodCBiZSB0aGF0IHVzaW5nIEVLTSBkaXJlY3RseSBhbmQgcmVmcmVzaGluZyB0aGUgQVQgd2l0 aCBhIHRva2VuIGJvdW5kIHJlZnJlc2ggdG9rZW4gbWlnaHQgYmUgdGhlIHByYWN0aWNhbCB0aGlu ZyB0byBhdm9pZCBjb21wbGljYXRlZCByZS1wbHVtYmluZyBvZiBHU1NBUEkuDQoNClRvIHVzZSBU b2tlbiBiaW5kaW5nIGRpcmVjdGx5IHRoZSBHU1MgbGF5ZXIgd291bGQgbmVlZCB0byB2YWxpZGF0 ZSB0aGUgVEIgbWVzc2FnZSBhbmQgcGFzcyB0aGUgdmFsaWRhdGVkIHRva2VuIGJpbmRpbmcgaWQg dXAgdGhlIHN0YWNrIGZvciB0aGUgYXBwbGljYXRpb24gdG8gdmFsaWRhdGUgdGhlIGFjY2VzcyB0 b2tlbiwgb3IgeW91IHdvdWxkIG5lZWQgdG8gcGFzcyB0aGUgVEIgRUtNIHBsdXMgdGhlIHRva2Vu IGJpbmRpbmcgbWVzc2FnZSB1cCB0aGUgc3RhY2sgZm9yIHRoZSBhcHAgdG8gZG8gYWxsIG9mIHRo ZSB0b2tlbiBiaW5kaW5nIHZhbGlkYXRpb24gaXRzZWxmLg0KDQpJIGFncmVlIHRoYXQgZ2V0dGlu ZyBzdXBwb3J0IGluIHRoZSBzdGFja3MgZm9yIGFjY2VzcyB0byBFS00gZXhwb3J0IGlzIG9uZSBv ZiB0aGUgZmlyc3Qgc3RlcHMgZm9yIGRlcGxveW1lbnQuDQoNCkpvaG4gQi4NCg0KDQo+IE9uIE1h eSAxOCwgMjAxNiwgYXQgMTE6NTggQU0sIENhbnRvciwgU2NvdHQgPGNhbnRvci4yQG9zdS5lZHU+ IHdyb3RlOg0KPiANCj4gT24gNS8xNy8xNiwgMTE6NDEgUE0sICJCZW5qYW1pbiBLYWR1ayIgPGth ZHVrQE1JVC5FRFU+IHdyb3RlOg0KPiANCj4gDQo+IA0KPj4gSSBhbSBub3QgcHJvbWlzaW5nIHRv IGRvIHRoZSByZXNlYXJjaCBpbnRvIHRoZSBpbnRlcmFjdGlvbnMgYmV0d2VlbiANCj4+IHRoZSB0 b2tlbiBiaW5kaW5nIEVLTSBtYXRlcmlhbCBhbmQgR1NTIGNoYW5uZWwgYmluZGluZ3MsIGJ1dCB0 aGUgIm5vcm1hbCINCj4+IHRoaW5nIHRvIGRvIGlmIG9uZSB3YW50cyB0byBiaW5kIGEgZ2l2ZW4g VExTIGNvbm5lY3Rpb24gdG8gYSBHU1MtQVBJIA0KPj4gc2VjdXJpdHkgY29udGV4dCBleGNoYW5n aW5nIG1lc3NhZ2VzIG92ZXIgdGhhdCBUTFMgY29ubmVjdGlvbiB3b3VsZCANCj4+IGJlIHRvIGRl ZmluZSBhIG5ldyBFS00gZm9yIFRMUyB0aGF0IGlzIHVzZWQgc29sZWx5IGZvciB0aGF0IHB1cnBv c2UuDQo+IA0KPiBJZiB5b3UgbWVhbiB0aGF0IGEgbmV3IENCIHR5cGUgaXMgbmVlZGVkLCBwcm9i YWJseSBzby4gSWYgeW91IG1lYW4gcmF0aGVyIHRoYXQgQ0IgYXMgYSBtZWNoYW5pc20gc2hvdWxk IG5vdCBiZSB1c2VkIHdpdGggVExTIGF0IHByZXNlbnQgd2l0aCBHU1MsIEkgdGhpbmsgdGhhdCBw cm9iYWJseSBzaG91bGQgYmUgc3RhdGVkIHNvbWV3aGVyZS4uLg0KPiANCj4gQnV0IHRoaXMgaXMg bW9yZSBvZiBhIGtpdHRlbiBjb252ZXJzYXRpb24sIEkgb25seSByYWlzZSBpdCBoZXJlIGluIGxp Z2h0IG9mIHRoZSBjb21tb24gcHJvYmxlbSBiZXR3ZWVuIGJvdGggdGhhdCB0aGUgbGFjayBvZiBz dXBwb3J0IGluIFRMUyBzdGFja3MgZm9yIGV4cG9zaW5nIHRoZSBuZWNlc3NhcnkgYml0cyBtYWtl cyBpbXBsZW1lbnRpbmcgZWl0aGVyIGRpZmZpY3VsdCBhdCBwcmVzZW50Lg0KPiANCj4gLS0gU2Nv dHQNCj4gDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KVW5iZWFyYWJsZUBpZXRmLm9yZw0KaHR0cHM6Ly9u YTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3 d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZ1bmJlYXJhYmxlJmRhdGE9MDElN2Mw MSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjMDA1Y2Q0N2IxOGYyNDdhZDQ2ZTgwOGQzN2Yz NmY0ZTMlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9SWROaW0y SVdVSkpna3R1bTBQc1F2eUFFVGYlMmZCbllkJTJiVmF2UndFaTAzMEklM2QNCg== From nobody Wed May 18 12:26:10 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E2612D64B for ; Wed, 18 May 2016 12:26:09 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j23w0txXMJLH for ; Wed, 18 May 2016 12:26:06 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 863F312D648 for ; Wed, 18 May 2016 12:26:06 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id x7so33213692qkd.3 for ; Wed, 18 May 2016 12:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IIDsCB99zmonpZPIf52O+SJcrRVnkEonAgGgpyXqPiU=; b=nxmRoz4YVdqAa+2W3uR2fV5GOxvYN3q01yJ576p2FrQ799+pF0LVc1comcUWlqirId IoRpuad1sHlmZiFqn7lYFzLpMtAA6q+6woS6zO7FaIuXJZET9vBdZIEqqiPR8DaSMoro 7fY3r9mCu92/5EY03fInoaEN7SD2TLRXHzByVIG0+h1Y8gzVRuLbzakS8895fhATf3Ge SyH3oqJb//aM79C3lcRYwQfP/xhBrxdWlwoQKLsiIgGCFDuxEfnmSiU4mEWNScdHcitt iebHT+4yoiG/hYANaJ4XPm5jbPEBYm5hSwInr/IBewHIr//58slTZDYP14UA6pARBOqw h8sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=IIDsCB99zmonpZPIf52O+SJcrRVnkEonAgGgpyXqPiU=; b=KxGRcSfLImvpgcw0SHAxYHU2ayN4/7VpOMRNrbvn6ySru/zVzq3Rh7p/CJz73rp1vd iMxbNro/wESWJAzz9rIer7U6r8s7LTbIR89jOg3vC+2TCbhtgokzMi9q2gwghF05Cu7K EnI+CdOu3/+zh1Kq/9LVuIKvX1MBYDEuIzbQeSJCdfrsAWqFuabKM4xCbyGAGOduiPrP q4BHQCLlT3oWRHdWb1VpWraLLNiHVt4kl7PyQPMFEQr6WqrKXOZod4MlaFDsIgDE+IP9 sF3w4pCIXTBJTfWlSpyRDvLLnyCY685t06PN7kY1/4mpr7LHpQg7+15oI5kmvN7Ndo2J yyPA== X-Gm-Message-State: AOPr4FUyllqwg3/Ly7U8v7t1L4WOxsiuNgVU9cuGgKO/dNLtkiX2W05LHZdhFnULsdQKIA== X-Received: by 10.55.8.12 with SMTP id 12mr9498145qki.200.1463599565450; Wed, 18 May 2016 12:26:05 -0700 (PDT) Received: from [192.168.8.100] ([181.202.19.44]) by smtp.gmail.com with ESMTPSA id z189sm4851034qhb.42.2016.05.18.12.26.02 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2016 12:26:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Wed, 18 May 2016 15:25:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <834F054F-3DF0-477A-AF44-F62AFCD5C35B@ve7jtb.com> References: <838CA767-4DBF-401B-B072-0262C82158E8@osu.edu> <0FCCDAB0-D6DF-4329-B5EF-71611CA5216A@ve7jtb.com> <81A057BF-3714-4FAE-B61F-994456101F56@osu.edu> To: Anthony Nadalin X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Scott Cantor , IETF Tokbind WG , Brian Campbell , Andrei Popov , Benjamin Kaduk Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 19:26:09 -0000 Sorry I din=E2=80=99t mean to underestimate the amount of political work = required for Java. John B. > On May 18, 2016, at 3:15 PM, Anthony Nadalin = wrote: >=20 > The change to Java (JSSE) is straight forward, but getting that change = made and out into the various versions/implementations of JSSE is a = different story=20 >=20 > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of = John Bradley > Sent: Wednesday, May 18, 2016 9:10 AM > To: Scott Cantor > Cc: IETF Tokbind WG ; Andrei Popov = ; Brian Campbell = ; Benjamin Kaduk > Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred = Token Binding (issue #35) >=20 > If you are trying to do OAuth GSSAPI you may not want to have to = refresh the AT every time the EKM changes. =20 > If the Token binding ID were used that could persist over multiple TLS = sessions.=20 >=20 > Unfortunately I don=E2=80=99t know off hand what would beed to be done = on the GSS side to make that possible. >=20 > It might be that using EKM directly and refreshing the AT with a token = bound refresh token might be the practical thing to avoid complicated = re-plumbing of GSSAPI. >=20 > To use Token binding directly the GSS layer would need to validate the = TB message and pass the validated token binding id up the stack for the = application to validate the access token, or you would need to pass the = TB EKM plus the token binding message up the stack for the app to do all = of the token binding validation itself. >=20 > I agree that getting support in the stacks for access to EKM export is = one of the first steps for deployment. >=20 > John B. >=20 >=20 >> On May 18, 2016, at 11:58 AM, Cantor, Scott wrote: >>=20 >> On 5/17/16, 11:41 PM, "Benjamin Kaduk" wrote: >>=20 >>=20 >>=20 >>> I am not promising to do the research into the interactions between=20= >>> the token binding EKM material and GSS channel bindings, but the = "normal" >>> thing to do if one wants to bind a given TLS connection to a GSS-API=20= >>> security context exchanging messages over that TLS connection would=20= >>> be to define a new EKM for TLS that is used solely for that purpose. >>=20 >> If you mean that a new CB type is needed, probably so. If you mean = rather that CB as a mechanism should not be used with TLS at present = with GSS, I think that probably should be stated somewhere... >>=20 >> But this is more of a kitten conversation, I only raise it here in = light of the common problem between both that the lack of support in TLS = stacks for exposing the necessary bits makes implementing either = difficult at present. >>=20 >> -- Scott >>=20 >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > = https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.iet= f.org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7ctonynad%40microso= ft.com%7c005cd47b18f247ad46e808d37f36f4e3%7c72f988bf86f141af91ab2d7cd011db= 47%7c1&sdata=3DIdNim2IWUJJgktum0PsQvyAETf%2fBnYd%2bVavRwEi030I%3d From nobody Wed May 18 12:57:46 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB4A12D6A0 for ; Wed, 18 May 2016 12:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=buckeyemailosu.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ng_0jEwmUImh for ; Wed, 18 May 2016 12:57:43 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0136.outbound.protection.outlook.com [65.55.169.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2DC12D68D for ; Wed, 18 May 2016 12:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buckeyemailosu.onmicrosoft.com; s=selector1-osu-edu; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UeStpKj2v8G8abLQw7PTpeKThoYt1h7Yg2RK7ezIUr4=; b=nZu35uo5UfW9rAal4w6QpR/Ud2lPN3cjBqAoaJ6bEirmj1QayGTnBzu1CQFIlvxl+UsoX0uZqi1uOZ45SULjNtYn+EE1ih+YMRpWaLy9/7XPgEyynCFUC/lm4JqpIlsyyNuH8spJgTi6h6d3kJuvObv0b2qg1b9ICNYmvHsJdp4= Received: from BLUPR0101CA0040.prod.exchangelabs.com (10.163.116.178) by CY1PR01MB1295.prod.exchangelabs.com (10.163.18.145) with Microsoft SMTP Server (TLS) id 15.1.497.12; Wed, 18 May 2016 19:57:41 +0000 Received: from BY2FFO11FD008.protection.gbl (2a01:111:f400:7c0c::166) by BLUPR0101CA0040.outlook.office365.com (2a01:111:e400:52e8::50) with Microsoft SMTP Server (TLS) id 15.1.497.12 via Frontend Transport; Wed, 18 May 2016 19:57:40 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.214) smtp.mailfrom=osu.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=osu.edu; Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.214 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.214; helo=cio-krc-pf07.osuad.osu.edu; Received: from cio-krc-pf07.osuad.osu.edu (164.107.81.214) by BY2FFO11FD008.mail.protection.outlook.com (10.1.14.159) with Microsoft SMTP Server (TLS) id 15.1.497.8 via Frontend Transport; Wed, 18 May 2016 19:57:40 +0000 Received: from CIO-KRC-HT02.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1.2 with cipher AES256-SHA256 (256/256 bits)) (No client certificate requested) by cio-krc-pf07.osuad.osu.edu (Postfix) with ESMTPS id C2A78500073; Wed, 18 May 2016 15:57:39 -0400 (EDT) Received: from CIO-KRC-D2MBX08.osuad.osu.edu ([fe80::3cdf:372e:4e57:db2a]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.03.0248.002; Wed, 18 May 2016 15:57:34 -0400 From: "Cantor, Scott" To: Brian Campbell , John Bradley Thread-Topic: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) Thread-Index: AQHRsH/wUZPFP+71UkmQUk1veolL6Z+9mWgAgAFqYz6AAAl6gA== Date: Wed, 18 May 2016 19:57:33 +0000 Message-ID: <0CBB891B-A123-4DD3-9897-D3E9DAA4A77B@osu.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.94.88] x-header-sapphire: true Content-Type: text/plain; charset="utf-8" Content-ID: <0E6C13D425983A4BBD3FD8AA551FBC86@osu.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:164.107.81.214; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(189002)(199003)(5383002)(5008740100001)(5001770100001)(23676002)(89122001)(109096001)(106466001)(90282001)(106116001)(3846002)(83716003)(586003)(6116002)(102836003)(6806005)(36756003)(11100500001)(93886004)(5004730100002)(8676002)(8936002)(75432002)(92566002)(47776003)(66066001)(189998001)(88552002)(8666002)(93346002)(16796002)(5003600100002)(87936001)(50466002)(2906002)(4326007)(33656002)(5250100002)(2950100001)(2900100001)(86362001)(82746002)(50986999)(76176999)(1220700001)(54356999)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR01MB1295; H:cio-krc-pf07.osuad.osu.edu; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD008; 1:ma/9/f1q9dd5K1Qzeiin5pUf1MWRYgub7nI+DWWq+RUM1EvBE9XNgPfBxLmzQTcdN7KokoJ3sGpL1gPJEB4JAF+KXTcHAE8SEtnM/P6k6EJpAW9GVj5jJl5VMqJykVsOPifjt5RhO09AGam2ywR98jTx4RVxJPOP3CD2eqKwCca3Onmx+QkRBxWzH+mRZ5udXlo8kHMFMJBmeLxhAB4f59oa4ns/9BGj3jupmaOSu/uSNztoJTQAc1fms8PYFlpmTH9mnnJgcjsYfc/0V9R4vxJVpUDznv/WEV39FApadZQvbV9uWw2FSPLh7ktQRjwhF5UaF0x6M1DRIZPVzHK3lyLuzHt6VNkZrakOp9ZgU6DVBtCDitMiMudF3UYbJioDDgfxK9vwwVhKOhE3HAdnrPVzEnNWaSIx8rKKT+oKBgCmaIl6MpRgzjDevzH4ZrKyIMRjZSUDThIYD06rsIR7+j8YpGPtSboaXROjB5lJaPmKj0QoOejUhdx1mXFfyoN7L3b3CSZ6GZ1QPb4koV1iKA== X-MS-Office365-Filtering-Correlation-Id: 350b6116-524d-4019-1c0b-08d37f56ab7d X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB1295; 2:NhhdhyE3q1huhwAs4ob34fkjEFoUHdn+oE6zbgAtdsowpb3lGBv+kqhRbPRQ/F5f5Ii808CkRrIDAG2bmaKQq3foaEuLQLgxozC0kegmFmhRp99MqWascx0YIZPKtfp/HBoonwVyeITh+tPvvnMb3dgzR6QVVh/F/idgp37eYZUhcEJCIH7AcMoqx8ZCT8Rv; 3:StJYMaMZBhUPNmgk/FnGrC4TzsAOEsCYyhczX2u1u42pcX7NYs7UNwgVAMNGpfOoEoUbOdUTkW+VL7n0o5X9G5n12/Zt1S0cPgMeFCtBq+EzC5C2ylDHek0BoM6YvAC9+nQ6fpI4fCJOwgQAsXBvWdBTMrRH1dljJudnOvhZi4GJ6UC2UySuPypHJ3nHZXYKhaBfbUVTh3nzeXf7w5b83Ii8LT6d5JxTHTrwbGrW+6MSAVXwC0Q5csDBGLhDubvep0D/PMOPPHI2+sFCBY6eHg== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:CY1PR01MB1295; X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB1295; 25:VnXcbT+4/WVaLV35m5kgFvz1s2ocb+qAs06gOHFF3TsbC3JQkYpsolCdeBtZo8hb2tD5VWkcLvq414Hz9p8DyS3XTvGf6NaKQ0vK06n0B4EZ+ycZS2C3UiMgq9XL9mxywmNQEwCewAQYse+dWF4EvsS/UMxfbRSHQYnc0bxMed9OD6n6xLzmdRI+2myFCNCBGmBQoeQJ1WzEdkdSTQnqqc0bUD+OjvD5wO54YxkGYrOZuKyZjJjoK5ELxohrrvvyiihWPqH/N45mAxIVIJz+eWMeXq2JGn/HJD2ZOX5QS0I11NdlMcQGOTrBZJURMURjS0hXFjZ6hkKzyYFFWPM8RG1sV4CyCd+dhIWJksDCCskaL/kw08E0BLW/Wb8BjOqzRWqOKHnVdFM6MucNJX6KvDmX/FWhh/Z5SvN+bZmnrYTrvppVCLI+SrMHKWyYMsic6VSu4YIGFye9jBTUUlHAR344Sz2x0JYxfo16LYlBItHAc+/4eK8TqZjfgNZfO9bMzJVh1Kcxi3LmllFWpftDLjzGfN4c08jtFQ5a0I0ixwmi1+a7Z+OI0UwExWFo3iBet3/tbbtwL/VVEJ4CbIzh5sAl2V1Mi9h0bEFOwxvQBnuEz7we1/AH/oeQ9JAI/A9P5XsJBG0ra6JasGILmNdnewI1VtgSxwmTES2dBoHdGISaEfUCFTgIAVdUEuE9hrh3MQ6lqbDGulRA29siNCWumiSMkglvLXggP+PUuUfkYjCDms021tzIXJV1jF/ODp7rYyKfqrPoGcUexYAzjeVzvA== X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB1295; 20:36X8Ndzkv25y7WEODqchkoLXHa9kdeKE4ad7CbQfu7TEUZsJ6iBdpV0FIXZTgzsBsmz/a0qTFenNKGYQV52whsrSOLrT8YIxH/0ao6vD/FuYPJd1OPoglZ3Ea5kYLMnx/PVcHMc0TncMzBdmJU4pQWo+lqr1QQtnjfAZSeOp+6OgTtHs3zpcbQUgSxa+bDUSrfbjwAnteEuDRwpk3UnNHexp62c6aAbW+DpaLaSI32XXcluH0DKW6aKnpr3y/CVVUPehLjQ7iSntBzpwxCOC5Tup61AaTMt6MCUwHNxV9DO3e4ikUQ/svovEFaR0tRbXJQCBMSzwVRhCk3T89Op/36A9rDtxpx80PkgRBE60LorfA1UrBElFc+9uqykn0kcXbnfst7F8avNti4Sd/jTbw5/dINhrB8HrgeLEchqeTnvg5RBtKF1m5YDSRqgoHmeLiOpzKl+fdo/s971689voPZylE9Y4inOLA+DulW6WOB/E1l5UDk3lAdzDue0UvHX9; 4:rR7SPkQof6oY4FFuFMvOJZ84X4RBRn9OocLTbhZxb5TcA/wkpJ41Qzpn3XYbPNUQNTw27lzLmk3fjecPijLACzrvQXmgjHWuCBuWeL+QHj0BGf2695nQatMIXi6zPTdYCzAMeynldg7d2q09gGY81HEVar5rnDgaASCroM6+PnBsb+g/CjLiFqTTtSD5VZqvxn5K/VAkJwTn/3hGKHOmXUM+4kB/2zRfbiENylSZHLEXypodXZ0RfRnozosLXqOGska0D8kKqryB/fDMC1DGs31HdiCSJEVfrnNfQ0ejGMsKvrj0LtZNrUaQWMPgZvpo66Un8aPPJQhlFJD6VgSCQsyCtD6BrC8tNhH0aqK97SSzJlLlFUIKDwUJi5Od0bYvbXsLVzH2C7tDQiHR5MJylNdEeFdVqCY+2rXcfMcBxUofbtV21ifuUxDmYKNMKY+t X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(13017025)(5005006)(8121501046)(13024025)(13023025)(13015025)(13018025)(10201501046)(3002001); SRVR:CY1PR01MB1295; BCL:0; PCL:0; RULEID:; SRVR:CY1PR01MB1295; X-Forefront-PRVS: 0946DC87A1 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjAxTUIxMjk1OzIzOm1GVzk2VUxtT0pnRHZwdlhvSm5Va0kyNWZL?= =?utf-8?B?ZmY1WjlXS0VWZlRZdjg1S2dicEVyUVAwa25rNVkrTkJheGNzUXUrUUtIc3VL?= =?utf-8?B?VDh0bVNYRGxmdmRUMEhiQmJOV0I2Nzd2aU81QjY5ZGJBV2RXYzArdEIyVFRT?= =?utf-8?B?QkdYMUFOWG1UTUdLUmJ2emhLQUdVM0dIaXZjeERGbFQwMHBQdDY4cFRBZnJS?= =?utf-8?B?TDVPb1lBVUJLaXA0TmxRcEFRSWUxcHo1R1NXL0k0VkZmdlptQzVJaXBjSmtL?= =?utf-8?B?dWZHaUE2M0Zkcmd5YnJGNmsxVTlvNktnTFVRdFk1VWgxa2lmQmpwMmxrUFBz?= =?utf-8?B?WkdPYy9jZFg3OVV0cGJUNHM0UytlQk5SY29YOHM2ZGdJckJ6K1Y4ajBxUXJy?= =?utf-8?B?a0ZmbjlqWHVaM1g3SU1NbGJYV1JYZS95V0hUWjdVMys2c3hpTnd5a3kvYURs?= =?utf-8?B?SS9PU1cyVFQyZjQ4ZEs4NFlvZW9qcTdoN0dVWEo1WDl3MVlpbjFXOGEvSHFO?= =?utf-8?B?WkV6VUVJZklhVnNVWnFtajBGNXBRRGlRZnhYUEFpQnB6ZjFEV2kveWNMMjhk?= =?utf-8?B?dDQrVFpuaWpuNWpKQ0pxMHQ4T0llSDVQblU1dGZqc2NBWVhVMFZvZU53Z2Iv?= =?utf-8?B?Z0pHd1FFVzg0MzRsSUxYNFpNb0xSbi9sdjdpd1BxUzBpOVVYU3lSVnFSUHNk?= =?utf-8?B?UmVGY2NVamg3Zi9jY1I5bnhqS1owSlZUbjduY2tIMkE0amt6YTB1ZzQwSWVh?= =?utf-8?B?bVZKeWRJVHpjQTJmZjR4ZUNTWm0vcDZ4ajl0amkrZjV6NE5uM1FBU3ZJeTBV?= =?utf-8?B?WDM5TmwyUkVyQlJpNUZDdzIzWmJMR2tXTzBocEFXVjZTWCs4dkFxVVJSSmRU?= =?utf-8?B?VUNrZ3hmWDB2UXJweG53YzlDY1Mrdy9aN0NNSUkzK3VjVWEvUFNkcHZmb1Bp?= =?utf-8?B?Y2wySEtsSkV4YmlEbHNSTXppK2NkTHY3UmRRWnNZQUZUdWYyaXJOaGlJUTlU?= =?utf-8?B?WWFPZ0tUUnNRNDhndmtpQzVwTWdDNU5PeEtZTUVidzRxNzFJMkZvRlJlWWpJ?= =?utf-8?B?aHdicEJsZDZGdkRPY0VjTkZTbEViZVZ4UjlBTGE5aExhd2VHR3lCWUg2emQr?= =?utf-8?B?ZFI1KzhCNGV0UzVUMEZWZG4zL1lMZytYeHhuRFF5ZXdlK0pZRUx3ZkRRQkhB?= =?utf-8?B?a3lOSUJCamFTQmluYVQ3WFdJUmp3c1pqSXM3aUdlMFFhM3JpV1ZZaTZiT3Vy?= =?utf-8?B?aHJQeTZpdWE3bnhHb0ErRC9TbFJ1d2hSaGhUR2Y2QWNvWEcyd3VPcC8yanE0?= =?utf-8?B?TUx2b2ZodHZRMDBCTDlrMXJ2OFJVS2E3bUtEbzZIY3ZCOS9XamU0LzNNclNm?= =?utf-8?B?bWlPNUVmWDZuazV6MWJ2UVFMTk1LTW1KeWlIR2MvUkRMK292anhvRnp5Z3Ex?= =?utf-8?B?U3Zja2NqRFJPUS91NjdzZkVJcXphNHQ5YVVaemM4MUhEMjRic0lCL3h0bUpZ?= =?utf-8?B?cVBVODBtVGdWRUh3a0lxSHNFeUt1d3NtUDJXaDZiUkxWTHIrZmpNa3lFSEE5?= =?utf-8?B?K2NoTVRBYmQyUW9xdjh4blFpTEV2SkpwWnZudDFHSWhBcmtZbENaVUFvVFlp?= =?utf-8?B?SXVhVlRRYnR2OFlHT0FUdWVwa2t1UVlBRWIxSW9LSk9SNlFBLzlGQldtb29L?= =?utf-8?B?c0o0Zk43N2JIMElrejMvVzBkM0l5UWRvUVBKYk1lTHFVMkRPSUU2dUtEWWhk?= =?utf-8?B?eFErVFMvV25xMHYxemdlUT09?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB1295; 5:KLC1qhOSZKnZJN8NrQyA5sJp/WCDwrRm2gbxHPKiOuojmO7m5zkWqHf0ivD0FdOBkOz3l3y0Pd0FnOJuGq4vlrPk6KZhPmhA2sRHAQwCsPKEshhb7AxAFvMEt9rNAoPM8zmvERLN3s0I37JO6dsayw==; 24:vQ4ohjIo/9s2gW+7StJ2nuQjZXPZw0NK14QlvhYktYM9kRrMNPr3QDsu+cxSFoR8TcFIHjaFITPQvP+fdqEiMhG5wzGWPZd6RblrfpRU1Fc=; 7:IQfXRJnMj79PR5DxTW/uaI4VJCZ4+UJGX4IzqCFI6m43GJQnN28HB55SN6c1I2t8f/O4pFnbm+9Qm/6Rx6m6MNjKJGmd/iEpyjC/V9bi8yvQWO1Qcyz/QgZarqywkdenEeor2vKgeUw4wfsszWW/fv5c2VV5GjoBPUDE3FCCsBEEoITObmaQQ7YTgo8XaKSR; 20:yofbiXB9JqaZ1rC/laZkRd6wBAjljjUWvNHcTkypq5vit5WueoQmJ1DRvl1+g+iwY6Yk653PiNHDxhaX1qQJpLj76TABGDbVjUyS01m03v9EM1+3eDU4cpq4/31c2Mt0cYK88VukQmRw28S9Lb6aUZR/+lq4eGHm4Qejh/uTkrQ= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 May 2016 19:57:40.4617 (UTC) X-MS-Exchange-CrossTenant-Id: eb095636-1052-4895-952b-1ff9df1d1121 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=eb095636-1052-4895-952b-1ff9df1d1121; Ip=[164.107.81.214]; Helo=[cio-krc-pf07.osuad.osu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR01MB1295 Archived-At: Cc: Andrei Popov , IETF Tokbind WG Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 19:57:45 -0000 PlllcywgSSBwbGFuIHRvIGRpZyBpbnRvIGl0IGFuZCBzZWUgd2hhdCBjYW4gYmUgZG9uZSBzZXJ2 ZXIgc2lkZSBpbiBKYXZhIGFuZC9vciB3aGF0IHRoZQ0KPiBtYWpvciBvYnN0YWNsZXMgYXJlLiBJ IGRvIGV4cGVjdCBpdCdsbCBiZSByYXRoZXIgY2hhbGxlbmdpbmcvcGFpbmZ1bCB0aG91Z2ggc28g SSd2ZSBiZWVuDQo+IGJpZGluZyBteSB0aW1lIGJlZm9yZSBqdW1waW5nIGluIGJ5IGRvaW5nIHNv bWUgcmV2aWV3IGFuZCBmZWVkYmFjayBvbiB0aGUgY3VycmVudA0KPiBkcmFmdHMuICANCg0KSWYg aXQncyBub3Qgb3V0IG9mIGxpbmUgdG8gYXNrIHRvIGJlIGluIHRoZSBsb29wIG9uIHRoYXQsIG9y IGlmIEkgY2FuIGhlbHAgd2l0aCB0aGF0LCBJJ2QgYXBwcmVjaWF0ZSBpdC4gSSB0aGluayBpdCB3 aWxsIGJlIGEgc29tZXdoYXQgc2hvcnQgYW5hbHlzaXMgYXQgcHJlc2VudC4NCg0KLS0gU2NvdHQN Cg0KDQoNCg== From nobody Wed May 18 13:13:04 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CFB12D6B1 for ; Wed, 18 May 2016 13:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diEPTsScOphQ for ; Wed, 18 May 2016 13:12:59 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB6C12D6AC for ; Wed, 18 May 2016 13:12:57 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u4IKCuCa022012 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 May 2016 20:12:57 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u4IKCuMo029689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 May 2016 20:12:56 GMT Received: from abhmp0007.oracle.com (abhmp0007.oracle.com [141.146.116.13]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u4IKCovW010587; Wed, 18 May 2016 20:12:55 GMT Received: from [172.16.3.168] (/195.110.148.170) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 18 May 2016 13:12:44 -0700 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (13E238) In-Reply-To: <834F054F-3DF0-477A-AF44-F62AFCD5C35B@ve7jtb.com> Date: Wed, 18 May 2016 22:12:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1972AB81-7E44-4912-83D7-33A70667DE08@oracle.com> References: <838CA767-4DBF-401B-B072-0262C82158E8@osu.edu> <0FCCDAB0-D6DF-4329-B5EF-71611CA5216A@ve7jtb.com> <81A057BF-3714-4FAE-B61F-994456101F56@osu.edu> <834F054F-3DF0-477A-AF44-F62AFCD5C35B@ve7jtb.com> To: John Bradley X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: Anthony Nadalin , Andrei Popov , Scott Cantor , IETF Tokbind WG , Benjamin Kaduk , Brian Campbell Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 20:13:02 -0000 No politics at all. It is just a case of convincing java folks people want i= t. Normally they would wait for the rfc, but I explained why now is much pre= ferred. =20 I am pushing hard for java 9 and then may be retrofit for java 8.=20 Still we have to he realistic with platform tech. It will take time to move u= p the stack into app servers and gateways for example.=20 For those that want to voice support please email me and I will send you the= team contact.=20 I was told we are very late in the java 9 cycle...so be enthusiastic in your= support.=20 Thanks to those who have already written in.=20 Ciao, Phil > On May 18, 2016, at 21:25, John Bradley wrote: >=20 > Sorry I din=E2=80=99t mean to underestimate the amount of political work r= equired for Java. >=20 > John B. >> On May 18, 2016, at 3:15 PM, Anthony Nadalin wrot= e: >>=20 >> The change to Java (JSSE) is straight forward, but getting that change ma= de and out into the various versions/implementations of JSSE is a different s= tory=20 >>=20 >> -----Original Message----- >> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of John B= radley >> Sent: Wednesday, May 18, 2016 9:10 AM >> To: Scott Cantor >> Cc: IETF Tokbind WG ; Andrei Popov ; Brian Campbell ; Benjamin Kaduk >> Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token= Binding (issue #35) >>=20 >> If you are trying to do OAuth GSSAPI you may not want to have to refresh t= he AT every time the EKM changes. =20 >> If the Token binding ID were used that could persist over multiple TLS se= ssions.=20 >>=20 >> Unfortunately I don=E2=80=99t know off hand what would beed to be done on= the GSS side to make that possible. >>=20 >> It might be that using EKM directly and refreshing the AT with a token bo= und refresh token might be the practical thing to avoid complicated re-plumb= ing of GSSAPI. >>=20 >> To use Token binding directly the GSS layer would need to validate the TB= message and pass the validated token binding id up the stack for the applic= ation to validate the access token, or you would need to pass the TB EKM plu= s the token binding message up the stack for the app to do all of the token b= inding validation itself. >>=20 >> I agree that getting support in the stacks for access to EKM export is on= e of the first steps for deployment. >>=20 >> John B. >>=20 >>=20 >>> On May 18, 2016, at 11:58 AM, Cantor, Scott wrote: >>>=20 >>> On 5/17/16, 11:41 PM, "Benjamin Kaduk" wrote: >>>=20 >>>=20 >>>=20 >>>> I am not promising to do the research into the interactions between=20 >>>> the token binding EKM material and GSS channel bindings, but the "norma= l" >>>> thing to do if one wants to bind a given TLS connection to a GSS-API=20= >>>> security context exchanging messages over that TLS connection would=20 >>>> be to define a new EKM for TLS that is used solely for that purpose. >>>=20 >>> If you mean that a new CB type is needed, probably so. If you mean rathe= r that CB as a mechanism should not be used with TLS at present with GSS, I t= hink that probably should be stated somewhere... >>>=20 >>> But this is more of a kitten conversation, I only raise it here in light= of the common problem between both that the lack of support in TLS stacks f= or exposing the necessary bits makes implementing either difficult at presen= t. >>>=20 >>> -- Scott >>=20 >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7ctonynad%40microsof= t.com%7c005cd47b18f247ad46e808d37f36f4e3%7c72f988bf86f141af91ab2d7cd011db47%= 7c1&sdata=3DIdNim2IWUJJgktum0PsQvyAETf%2fBnYd%2bVavRwEi030I%3d >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Wed May 18 14:29:36 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99CA012D768 for ; Wed, 18 May 2016 14:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwUsHs1QGRCt for ; Wed, 18 May 2016 14:29:33 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DA9512D765 for ; Wed, 18 May 2016 14:29:33 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id f89so82803599ioi.0 for ; Wed, 18 May 2016 14:29:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZEXvLV/4R3f/6nP5J9bC95YSRKD6ACvHTSQk8eIlQYs=; b=cA4vehB25n3PZRpuS0nj6omDm0xXMu5oCunUjSI+TnVmSES5ZIr2nUoS/f5K/qiqEZ 2REsaLyjpVs8TAiaMG7z1PbReeusHCps6/CnmhjynwCmPB5bNpwMV8rz7WJSIRd3zyp7 iGLUsArmaBGzPIjHeQB10jQEf+gkHGrUcZoYQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZEXvLV/4R3f/6nP5J9bC95YSRKD6ACvHTSQk8eIlQYs=; b=nNiPySwQ4yaYOaPtpdEwk8RzWl6JkZ9QbgxQBCLqtQrTyaqxkmVKrPJxfyN3yScX64 fIzG+6yEl+6SSpA/hv/btCRkFhSWxri/AlbaC7Ew47GrJzFjj5F9WESudYXOuPrt5TYm WNmLOJCMXUfaHx6QK7zSfG+IOH3DGU6mkc9MRcXkAYAZotvRk/nQnITMfG/xt1AxgQY2 DkZkDGD7jAAHdNVX7ZUpNVjLuhktmBWRipbOSCy4c765WKNwJ8Z0TkBW/Wz1PopTfRxD qrC3nzefg4EInuSDRtJbeJZeWhvCRrcV3ypVLS69NE2qqV8NI29ym93um+8S1UMWk7gd 0xCA== X-Gm-Message-State: AOPr4FX2jd5jzaPL5aXrC/a87pO4eZAOe92NC1PRleAPC2o1sdvwMK8j3Jk5mdYIpNEUM5PuEHTqQuJBD0K6o1x+ X-Received: by 10.107.8.141 with SMTP id h13mr7223911ioi.95.1463606972213; Wed, 18 May 2016 14:29:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.105.129 with HTTP; Wed, 18 May 2016 14:29:02 -0700 (PDT) In-Reply-To: <0CBB891B-A123-4DD3-9897-D3E9DAA4A77B@osu.edu> References: <0CBB891B-A123-4DD3-9897-D3E9DAA4A77B@osu.edu> From: Brian Campbell Date: Wed, 18 May 2016 15:29:02 -0600 Message-ID: To: "Cantor, Scott" Content-Type: multipart/alternative; boundary=001a113f9ab0abaa3f0533248da9 Archived-At: Cc: John Bradley , Andrei Popov , IETF Tokbind WG Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 21:29:34 -0000 --001a113f9ab0abaa3f0533248da9 Content-Type: text/plain; charset=UTF-8 Sure, not out of line at all. I'm probably naively hoping to hack/fight though the reasons you expect it to be a short analysis. But that might be overly optimistic. On Wed, May 18, 2016 at 1:57 PM, Cantor, Scott wrote: > >Yes, I plan to dig into it and see what can be done server side in Java > and/or what the > > major obstacles are. I do expect it'll be rather challenging/painful > though so I've been > > biding my time before jumping in by doing some review and feedback on > the current > > drafts. > > If it's not out of line to ask to be in the loop on that, or if I can help > with that, I'd appreciate it. I think it will be a somewhat short analysis > at present. > > -- Scott > > > > --001a113f9ab0abaa3f0533248da9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sure, not out of line at all. I'm probably naively hop= ing to hack/fight though the reasons you expect it to be a short analysis. = But that might be overly optimistic.

On Wed, May 18, 2016 at 1:57 PM, Cantor, = Scott <cantor.2@osu.edu> wrote:
>Yes, I plan to dig into it and see what c= an be done server side in Java and/or what the
> major obstacles are. I do expect it'll be rather challenging/painf= ul though so I've been
> biding my time before jumping in by doing some review and feedback on = the current
> drafts.

If it's not out of line to ask to be in the loop on that, or if = I can help with that, I'd appreciate it. I think it will be a somewhat = short analysis at present.

-- Scott




--001a113f9ab0abaa3f0533248da9-- From nobody Wed May 18 14:35:28 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD7812D76E for ; Wed, 18 May 2016 14:35:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny1ZaBSoH6za for ; Wed, 18 May 2016 14:35:23 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B95F112D767 for ; Wed, 18 May 2016 14:35:23 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id d62so82981770iof.2 for ; Wed, 18 May 2016 14:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y/bxlUH1incL1kM+0dUEh3jOjyuYtpxovkeJoNKioNw=; b=mAAXmvotsQJPe3+LFPx5qYXAKMMyJteLmE51BoNe1AfmfYbmzoxm3AIwK1gaGmN4Lc ojzrmAZ2fgpR4IJtKPu5XF1a8pDdYUSfq5Q4PMQLyNQf/Gbd/OtjT463cNmeQo+CsVZv 88ru/wFgn02mfCfmxjaoSYdIACZLtUu896ec8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y/bxlUH1incL1kM+0dUEh3jOjyuYtpxovkeJoNKioNw=; b=Yhkm+K4uW8gGMp8rItNoXqOpRDzVKQrNDvWCiucowAtKe+wC+W4b5/kTFHWKisyEAP V7BNTVCCEyaRlUX4W7G3I0MsYo1JVL594/0rhiq/66I2qucJckK5ys70oQEStLmKphCt Z45x9qawgZFfOm6W8juU4rdhTLxJL8iHPgO89Y74wNc/tXpZdbD2H3CbKNhRTYyzpf0x 69EVq4GM0iDIsKb953lZakPbjUhSFAy8UQql2WU7AP3C7G5DLdhDo9YF4wYtf5HZSFa+ kJODAE6Dhn0//Ra2M3VaDpG3raz1Bsjwlh3ZqJvgbDtKu/oDqhhiYEOuDHkK6RDB4UlY zsgQ== X-Gm-Message-State: AOPr4FV+NQ0RR3n7XXipTFZr050OvzTw5S3qsm6mYKUJ2F4t0a19rO/+ls8fKcFmRCdn/ZnqCUselRIBuD8BHoCZ X-Received: by 10.36.130.130 with SMTP id t124mr152696itd.42.1463607323069; Wed, 18 May 2016 14:35:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.105.129 with HTTP; Wed, 18 May 2016 14:34:53 -0700 (PDT) In-Reply-To: <1972AB81-7E44-4912-83D7-33A70667DE08@oracle.com> References: <838CA767-4DBF-401B-B072-0262C82158E8@osu.edu> <0FCCDAB0-D6DF-4329-B5EF-71611CA5216A@ve7jtb.com> <81A057BF-3714-4FAE-B61F-994456101F56@osu.edu> <834F054F-3DF0-477A-AF44-F62AFCD5C35B@ve7jtb.com> <1972AB81-7E44-4912-83D7-33A70667DE08@oracle.com> From: Brian Campbell Date: Wed, 18 May 2016 15:34:53 -0600 Message-ID: To: "Phil Hunt (IDM)" Content-Type: multipart/alternative; boundary=94eb2c08952c9531c8053324a2b2 Archived-At: Cc: Anthony Nadalin , Andrei Popov , Scott Cantor , IETF Tokbind WG , Benjamin Kaduk , John Bradley Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred Token Binding (issue #35) X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 18 May 2016 21:35:26 -0000 --94eb2c08952c9531c8053324a2b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I understand the reluctance to put something in before RFC. What's really needed though isn't support for a draft of TB. What's needed at this point is the appropriate hooks to implement simple(ish) TLS extensions and get at the EKM. And that stuff is in RFCs. Please do send that contact info, Phil. On Wed, May 18, 2016 at 2:12 PM, Phil Hunt (IDM) wrote: > No politics at all. It is just a case of convincing java folks people wan= t > it. Normally they would wait for the rfc, but I explained why now is much > preferred. > > I am pushing hard for java 9 and then may be retrofit for java 8. > > Still we have to he realistic with platform tech. It will take time to > move up the stack into app servers and gateways for example. > > For those that want to voice support please email me and I will send you > the team contact. > > I was told we are very late in the java 9 cycle...so be enthusiastic in > your support. > > Thanks to those who have already written in. > > Ciao, > > Phil > > > On May 18, 2016, at 21:25, John Bradley wrote: > > > > Sorry I din=E2=80=99t mean to underestimate the amount of political wor= k > required for Java. > > > > John B. > >> On May 18, 2016, at 3:15 PM, Anthony Nadalin > wrote: > >> > >> The change to Java (JSSE) is straight forward, but getting that change > made and out into the various versions/implementations of JSSE is a > different story > >> > >> -----Original Message----- > >> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of > John Bradley > >> Sent: Wednesday, May 18, 2016 9:10 AM > >> To: Scott Cantor > >> Cc: IETF Tokbind WG ; Andrei Popov < > Andrei.Popov@microsoft.com>; Brian Campbell ; > Benjamin Kaduk > >> Subject: Re: [Unbearable] HTTPSTB: distinct header for the referred > Token Binding (issue #35) > >> > >> If you are trying to do OAuth GSSAPI you may not want to have to > refresh the AT every time the EKM changes. > >> If the Token binding ID were used that could persist over multiple TLS > sessions. > >> > >> Unfortunately I don=E2=80=99t know off hand what would beed to be done= on the > GSS side to make that possible. > >> > >> It might be that using EKM directly and refreshing the AT with a token > bound refresh token might be the practical thing to avoid complicated > re-plumbing of GSSAPI. > >> > >> To use Token binding directly the GSS layer would need to validate the > TB message and pass the validated token binding id up the stack for the > application to validate the access token, or you would need to pass the T= B > EKM plus the token binding message up the stack for the app to do all of > the token binding validation itself. > >> > >> I agree that getting support in the stacks for access to EKM export is > one of the first steps for deployment. > >> > >> John B. > >> > >> > >>> On May 18, 2016, at 11:58 AM, Cantor, Scott wrote: > >>> > >>> On 5/17/16, 11:41 PM, "Benjamin Kaduk" wrote: > >>> > >>> > >>> > >>>> I am not promising to do the research into the interactions between > >>>> the token binding EKM material and GSS channel bindings, but the > "normal" > >>>> thing to do if one wants to bind a given TLS connection to a GSS-API > >>>> security context exchanging messages over that TLS connection would > >>>> be to define a new EKM for TLS that is used solely for that purpose. > >>> > >>> If you mean that a new CB type is needed, probably so. If you mean > rather that CB as a mechanism should not be used with TLS at present with > GSS, I think that probably should be stated somewhere... > >>> > >>> But this is more of a kitten conversation, I only raise it here in > light of the common problem between both that the lack of support in TLS > stacks for exposing the necessary bits makes implementing either difficul= t > at present. > >>> > >>> -- Scott > >> > >> _______________________________________________ > >> Unbearable mailing list > >> Unbearable@ietf.org > >> > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2fmailman%2flistinfo%2funbearable&data=3D01%7c01%7ctonynad%40microso= ft.com%7c005cd47b18f247ad46e808d37f36f4e3%7c72f988bf86f141af91ab2d7cd011db4= 7%7c1&sdata=3DIdNim2IWUJJgktum0PsQvyAETf%2fBnYd%2bVavRwEi030I%3d > > > > _______________________________________________ > > 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 > --94eb2c08952c9531c8053324a2b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I understand the reluctance to put something in befor= e RFC. What's really needed though isn't support for a draft of TB.= What's needed at this point is the appropriate hooks to implement simp= le(ish) TLS extensions and get at the EKM. And that stuff is in RFCs. =C2= =A0

Please do send that contact info, Phil.

=C2= =A0

On Wed, May 18, 2016 at 2:12 PM, Phil Hunt (IDM) <phil.hunt@oracle.co= m> wrote:
No politics at al= l. It is just a case of convincing java folks people want it. Normally they= would wait for the rfc, but I explained why now is much preferred.

I am pushing hard for java 9 and then may be retrofit for java 8.

Still we have to he realistic with platform tech. It will take time to move= up the stack into app servers and gateways for example.

For those that want to voice support please email me and I will send you th= e team contact.

I was told we are very late in the java 9 cycle...so be enthusiastic in you= r support.

Thanks to those who have already written in.

Ciao,

Phil

> On May 18, 2016, at 21:25, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
> Sorry I din=E2=80=99t mean to underestimate the amount of political wo= rk required for Java.
>
> John B.
>> On May 18, 2016, at 3:15 PM, Anthony Nadalin <tonynad@microsoft.com> wrote:
>>
>> The change to Java (JSSE) is straight forward, but getting that ch= ange made and out into the various versions/implementations of JSSE is a di= fferent story
>>
>> -----Original Message-----
>> From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of John Bradley
>> Sent: Wednesday, May 18, 2016 9:10 AM
>> To: Scott Cantor <cantor.2@= osu.edu>
>> Cc: IETF Tokbind WG <unb= earable@ietf.org>; Andrei Popov <Andrei.Popov@microsoft.com>; Brian Campbell <bcampbell@pingidentity.com>;= Benjamin Kaduk <kaduk@MIT.EDU><= br> >> Subject: Re: [Unbearable] HTTPSTB: distinct header for the referre= d Token Binding (issue #35)
>>
>> If you are trying to do OAuth GSSAPI you may not want to have to r= efresh the AT every time the EKM changes.
>> If the Token binding ID were used that could persist over multiple= TLS sessions.
>>
>> Unfortunately I don=E2=80=99t know off hand what would beed to be = done on the GSS side to make that possible.
>>
>> It might be that using EKM directly and refreshing the AT with a t= oken bound refresh token might be the practical thing to avoid complicated = re-plumbing of GSSAPI.
>>
>> To use Token binding directly the GSS layer would need to validate= the TB message and pass the validated token binding id up the stack for th= e application to validate the access token, or you would need to pass the T= B EKM plus the token binding message up the stack for the app to do all of = the token binding validation itself.
>>
>> I agree that getting support in the stacks for access to EKM expor= t is one of the first steps for deployment.
>>
>> John B.
>>
>>
>>> On May 18, 2016, at 11:58 AM, Cantor, Scott <cantor.2@osu.edu> wrote:
>>>
>>> On 5/17/16, 11:41 PM, "Benjamin Kaduk" <kaduk@MIT.EDU> wrote:
>>>
>>>
>>>
>>>> I am not promising to do the research into the interaction= s between
>>>> the token binding EKM material and GSS channel bindings, b= ut the "normal"
>>>> thing to do if one wants to bind a given TLS connection to= a GSS-API
>>>> security context exchanging messages over that TLS connect= ion would
>>>> be to define a new EKM for TLS that is used solely for tha= t purpose.
>>>
>>> If you mean that a new CB type is needed, probably so. If you = mean rather that CB as a mechanism should not be used with TLS at present w= ith GSS, I think that probably should be stated somewhere...
>>>
>>> But this is more of a kitten conversation, I only raise it her= e in light of the common problem between both that the lack of support in T= LS stacks for exposing the necessary bits makes implementing either difficu= lt at present.
>>>
>>> -- Scott
>>
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://na01.safelink= s.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf.org%2fmailman%2flist= info%2funbearable&data=3D01%7c01%7ctonynad%40microsoft.com%7c005cd47b18= f247ad46e808d37f36f4e3%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DI= dNim2IWUJJgktum0PsQvyAETf%2fBnYd%2bVavRwEi030I%3d
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listin= fo/unbearable

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

--94eb2c08952c9531c8053324a2b2-- From nobody Thu May 19 16:17:01 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A9B12D0C6 for ; Thu, 19 May 2016 16:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MU0050Tw1kOL for ; Thu, 19 May 2016 16:16:56 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0745.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::745]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B349412B05C for ; Thu, 19 May 2016 16:16:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=b+xlbSrA/yfn5EvSDgy0ADq2I+RiV5AYXh7sAD9uHzE=; b=lx592f0Kv2ZNt5hNJ3qTyud61G7OWC5KhrOTD1e57mG6cQsKEsqH/ON3zToXSY8XPguQArz0iS5skU5ISEmJKLVWRj8LP1+OrUxwHpssQylVufYyrbSEYoXzNCK83IoNdQUx08alyHVnPudaS5lDI5x1Hxcrh+Dc2xv7ok94azU= Received: from BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) by BN3PR03MB1446.namprd03.prod.outlook.com (10.163.34.29) with Microsoft SMTP Server (TLS) id 15.1.501.7; Thu, 19 May 2016 23:16:36 +0000 Received: from BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) by BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) with mapi id 15.01.0501.010; Thu, 19 May 2016 23:16:36 +0000 From: Andrei Popov To: =JeffH , IETF Tokbind WG Thread-Topic: [Unbearable] Re-opened "added explicit referred TB processing" PR#16 Thread-Index: AQHRoN71ot+IWwV+y0a3Vv4/xVIvlp/BBtlg Date: Thu, 19 May 2016 23:16:36 +0000 Message-ID: References: <57214F22.5070209@KingsMountain.com> In-Reply-To: <57214F22.5070209@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: KingsMountain.com; dkim=none (message not signed) header.d=none;KingsMountain.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8::1d2] x-ms-office365-filtering-correlation-id: 165bceb4-4f57-4472-324a-08d3803ba030 x-microsoft-exchange-diagnostics: 1; BN3PR03MB1446; 5:mxWervi1A+8pGzrEDp/YJBG2j4p941X8HAgx5/GqSgQlBmEy1ntBhhYKyWy2/J7e/caCcoqIUM/nuTugvLzgl9PfjaoCw2D2oQBBBYhGQHDn4W9IcFP4yP5X09Uef+IzWvmNmxZ30csFVggYPsaF+A==; 24:Z+uc7UXiswaMzhwB2KsHGPghIQSM+B6oOzBp2hObxbVpctWkwHgJWhEgdOGxZKGARo5x/6rIif3tvjf1wfzq0I5SNXfAGyl4H2oe7gaw6uU=; 7:njNtqwQhffSXdzlwqiZCWsp9tV7VheDHvJyxSqLOPiGslrsdPzdIpT9jkcDniLlQlK36JQ4PEoA328SCXAZaBHX5lcj9ohvYmuaWPF4k75nYA1DVLm28o6d5ytZSdIHvq3syDJmRfgCbRcQBALYV/4wpqxM2QTGwFR4OrPsa2HAbtfGsKESawIQlwErpiGI9zzhj54MoozyHKXUFqWJung== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR03MB1446; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1446; x-forefront-prvs: 094700CA91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(86362001)(5002640100001)(76176999)(54356999)(76576001)(107886002)(5001770100001)(50986999)(189998001)(87936001)(77096005)(15975445007)(2900100001)(92566002)(106116001)(2950100001)(99286002)(122556002)(8676002)(3280700002)(81166006)(8936002)(2906002)(11100500001)(3660700001)(6116002)(9686002)(586003)(102836003)(1220700001)(5008740100001)(5004730100002)(74316001)(10400500002)(5005710100001)(10290500002)(10090500001)(19580395003)(19580405001)(33656002)(5003600100002)(8990500004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1446; H:BN3PR03MB1445.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2016 23:16:36.5810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1446 Archived-At: Subject: Re: [Unbearable] Re-opened "added explicit referred TB processing" PR#16 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 19 May 2016 23:16:59 -0000 PR #16 has been merged: https://github.com/TokenBinding/Internet-Drafts/blo= b/master/draft-ietf-tokbind-protocol-06.xml Cheers, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of =3DJeffH Sent: Wednesday, April 27, 2016 4:46 PM To: IETF Tokbind WG Subject: [Unbearable] Re-opened "added explicit referred TB processing" PR#= 16 https://github.com/TokenBinding/Internet-Drafts/pull/16 re-opening, see issue #21 -- have added commits to update these proposed ch= anges. TBPROTO: Add more info about the intended use of Referred bindings #21 https://github.com/TokenBinding/Internet-Drafts/issues/21 per various discussions with OAuth folk at IETF-95, it appears there will b= e a forthcoming OAuth Internet-Draft making use of Token Binding Protocol a= nd referred_token_binding TBtype ("referred bindings"). Thus, we will retai= n referred_token_binding TBtype in TBPROTO (-tokbind-protocol) and update the relevant spec prose to hopefully make it= s semantics and use more clear. NOTE: The present proposed content of PR#16 does not quite fully accomplish= the separation of processing rules from the TBMsg syntax exposition, nor c= larify the semantics of referred bindings, to the extent that I/we intend t= o -- tho, if this overall direction seems ok, the necessary further editing= can be done either before or after merge of this PR. Please review PR#16 thx, HTH, =3DJeffH _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable From nobody Fri May 20 12:08:44 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C665B12D608 for ; Fri, 20 May 2016 12:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXgiVNE6yiMV for ; Fri, 20 May 2016 12:08:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0106.outbound.protection.outlook.com [65.55.169.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E57812D5DC for ; Fri, 20 May 2016 12:08:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=emanRSnvWFjqgG6ilzydhj17I4lkA3uYYFbbnioFqIY=; b=VyOAV3bgQ7wGGkCOyjIxdkJld8XsvZWiCjOh3J5JAO/s5M+LowcJkSQrYs3zUyis/6wwDGALtF8dmwHP7aNswABc1RCMyXE+TE7rmGLLaNloQbrU0YzYF5rq9BAB42YKoLysM9h7OEtXh6lFwa3dec1OV/VofC/I4TuxcNWCGiQ= Received: from BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) by BN3PR03MB1447.namprd03.prod.outlook.com (10.163.34.30) with Microsoft SMTP Server (TLS) id 15.1.501.7; Fri, 20 May 2016 19:08:37 +0000 Received: from BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) by BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) with mapi id 15.01.0501.011; Fri, 20 May 2016 19:08:37 +0000 From: Andrei Popov To: Brian Campbell , IETF Tokbind WG Thread-Topic: [Unbearable] ecdsap256 questions Thread-Index: AQHRsHNO0gHpa/iOlEmlbmpufE8V3p/CNOMw Date: Fri, 20 May 2016 19:08:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8::1d2] x-ms-office365-filtering-correlation-id: 0a220748-ad9b-4ff3-d75c-08d380e225d4 x-microsoft-exchange-diagnostics: 1; BN3PR03MB1447; 5:lcuzD4Kt4J4UAFCb6k7K/cSUcphjjBOxM8hobpnpG98zLi1/To31oYPeYXLRn/z45q0W1xYByj1e4LlyxMvo33XBhIskt1rYPMLPRzyChYpkMQfdPLq8/hY1yhRwx0pUd5sCcZFla/mNrTzaZKRkKg==; 24:pIpBiQJl0rZ7tPW90iNSlETNiNnq5qJushyj6zm4FJSOWUspC3d09PMDm1iytIHDc5Bp7GQBPlVM29jj14RLtPP/YMw5uf4zWpypXzWgGbs=; 7:KuqhLas1SinsvU9ZkVmLzjG1DI+SCpxpZrmbeI76YGrZ4dL3c8Omgv9MgJ3XCTEZWkutXsHgSTxAfXSVqTXjJCE1IZNd2B7NCeRVPkkDw4bPiPba3+AQg5eJt9TGWZmy/b2hL0CvryUAY117XoHzfsr+amWexsBT1IdyRnhvRGlbY46PeWbECiofai+Tvg1jDEV7beAIPVo1/OJhD2Nn3w== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1447; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:BN3PR03MB1447; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1447; x-forefront-prvs: 09480768F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(124975003)(243025005)(377454003)(99286002)(5003600100002)(50986999)(2950100001)(106116001)(5008740100001)(33656002)(54356999)(76176999)(1220700001)(19617315012)(10400500002)(5005710100001)(77096005)(5004730100002)(10290500002)(16236675004)(19625215002)(15975445007)(3280700002)(8936002)(122556002)(19580395003)(19580405001)(3660700001)(189998001)(11100500001)(81166006)(8676002)(6116002)(790700001)(102836003)(107886002)(87936001)(76576001)(8990500004)(9686002)(586003)(19300405004)(10090500001)(74316001)(92566002)(86362001)(2906002)(5002640100001)(5001770100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1447; H:BN3PR03MB1445.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB144572B382F3081A2FF8776E8C4B0BN3PR03MB1445namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2016 19:08:37.2698 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1447 Archived-At: Subject: Re: [Unbearable] ecdsap256 questions X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 20 May 2016 19:08:42 -0000 --_000_BN3PR03MB144572B382F3081A2FF8776E8C4B0BN3PR03MB1445namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgZmVlZGJhY2sgQnJpYW4sIEnigJlsbCBjbGFyaWZ5IGluIHRoZSBuZXh0 IHJldmlzaW9uLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBVbmJlYXJhYmxlIFttYWls dG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gQ2FtcGJl bGwNClNlbnQ6IFR1ZXNkYXksIE1heSAxNywgMjAxNiAxMjozNSBQTQ0KVG86IElFVEYgVG9rYmlu ZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtVbmJlYXJhYmxlXSBlY2RzYXAy NTYgcXVlc3Rpb25zDQoNCklzIGVjZHNhcDI1NiB0aGUgTklTVCBQLTI1NiBjdXJ2ZT8gSSdtIGd1 ZXNzaW5nIHNvIGJ1dCBpdCdzIG5vdCB0b3RhbGx5IGNsZWFyIGZyb20gdGhlIGRvY3VtZW50LiBU aGUgcmVsZXZhbnQgdGV4dCAodGhhdCBJIGNvdWxkIGZpbmQgYW55d2F5KSBmcm9tIFRCUFJPVE8t MDMgaGVyZToNCg0KICAgIldoZW4gYW4gZWNkc2FwMjU2IGtleSBpcyB1c2VkLCBUb2tlbkJpbmRp bmcuc2lnbmF0dXJlIGNvbnRhaW5zIGEgcGFpcg0KDQogICBvZiBpbnRlZ2VycywgUiBmb2xsb3dl ZCBieSBTLCBhcyBkZWZpbmVkIGluIFtBTlNJLlg5LTYyLjIwMDU8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1wcm90b2NvbC0wNSNyZWYtQU5TSS5YOS02Mi4y MDA1Pl0uICBSIGFuZA0KDQogICBTIGFyZSBlbmNvZGVkIGluIGJpZy1lbmRpYW4gZm9ybWF0LiAg RUNQb2ludC5wb2ludCBjb250YWlucyB0aGUgWA0KDQogICBjb29yZGluYXRlIGZvbGxvd2VkIGJ5 IHRoZSBZIGNvb3JkaW5hdGUuICBUaGUgWCBhbmQgWSBjb29yZGluYXRlcyBhcmUNCg0KICAgdW5z aWduZWQgaW50ZWdlcnMgZW5jb2RlZCBpbiBiaWctZW5kaWFuIGZvcm1hdC4iDQoNCkkgd2FzIGdv aW5nIHRvIHN1Z2dlc3QgdGhhdCBUQlBST1RPIGV4cGxpY2l0bHkgc2F5IHRoYXQgZm9yIGVjZHNh cDI1NiBSICYgUyBhbmQgWCAmIFkgYWx3YXlzIGJlIGV4YWN0bHkgMzIgb2N0ZXRzL2J5dGVzIGxv bmcgYW5kIHRoYXQgYW55IGxlYWRpbmcgemVybyBieXRlcyBiZSBwcmVzZXJ2ZWQgKHJhcmUgYnV0 IHBvc3NpYmxlIEFGQUlLKSwgd2hpY2ggSSBhc3N1bWUgd2FzIHRoZSBpbnRlbnQgc28gdGhhdCB0 aGUgcG9pbnQgYW5kIHNpZ25hdHVyZSBjYW4gYmUgY29uc2lzdGVudGx5IHByb2Nlc3NlZC4gVGhl biBJIHRob3VnaHQgbWF5YmUgSSBzaG91bGQgZmlyc3QgbG9vayBhdCBBTlNJLlg5LTYyIHRvIHNl ZSBpZiB0aGlzIHdhcyBhbHJlYWR5IGNsZWFybHkgc3RhdGVkIHRoZXJlIHNvbWV3aGVyZS4gQnV0 IGl0IHNlZW1zIHRoYXQgb25lIGNhbid0IGFjdHVhbGx5IHJlYWQgWDktNjIgd2l0aG91dCBzaGVs bGluZyBvdXQgJDEwMCwgd2hpY2ggaXMgYSBsb3QgdG8ganVzdCBsb29rIGZvciBhIGxpdHRsZSBk ZXRhaWxzIGxpa2UgdGhhdC4NClNvLCBmcm9tIHRoYXQgZnVuIGxpdHRsZSBzdG9yeSAoc29ycnkh KSwgYSBjb3VwbGUgY29tbWVudHMvcXVlc3Rpb25zOg0KQ2FuIFRCUFJPVE8gc3RhdGUgdGhlIGN1 cnZlIHVzZWQgd2l0aCB0aGUgZWNkc2FwMjU2IFRCIGtleSBwYXJhbWV0ZXJzIGluIGEgd2F5IHRo YXQncyBlYXN5IGFuZCBvYnZpb3VzPyBBbmQgbWF5YmUgYWxzbyBjaXRlIGEgZG9jdW1lbnQgdGhh dCdzIGEgbGl0dGxlIG1vcmUgYWNjZXNzaWJsZSB0aGFuIFg5LTYyIGluIGRvaW5nIHNvPyAgSSBi ZWxpZXZlIG1hbnkgUkZDcywgNzUxOC9KV0E8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NzUxOCNzZWN0aW9uLTMuND4gZm9yIGV4YW1wbGUsIGNpdGUgRklQUyBQVUIgMTg2LTQgIkRpZ2l0 YWwgU2lnbmF0dXJlIFN0YW5kYXJkIChEU1MpIjxodHRwOi8vbnZscHVicy5uaXN0Lmdvdi9uaXN0 cHVicy9GSVBTL05JU1QuRklQUy4xODYtNC5wZGY+IGZvciBFQ0RTQSBhbmQgdGhlIFAtKiBjdXJ2 ZXMuIEkgZXhwZWN0IG1vc3QgaW1wbGVtZW50ZXJzIHdpbGwgYmUgdXNpbmcgYW4gZXhpc3Rpbmcg RUNEU0EgaW1wbGVtZW50YXRpb24gYW5kIGp1c3QgbmVlZCB0byBnZXQgdGhlIHBhcmFtZXRlcnMg YW5kIGlucHV0L291dHB1dCBmb3JtYXR0ZWQgY29ycmVjdGx5LiBUaGF0IHJlZmVyZW5jZSBhbmQg dGhlIHRleHQgaW4gSldBIHdhcyBlbm91Z2ggZm9yIG1hbnkgaW5kZXBlbmRlbnQgaW1wbGVtZW50 YXRpb25zIHRvIGdldCBpdCByaWdodCB3aXRoIEpXUy4NCkFuZCBhYm91dCBnZXR0aW5nIHRoZSBp bnB1dC9vdXRwdXQgZm9ybWF0dGVkIGNvcnJlY3RseSwgY2FuIG9yIHNob3VsZCBUQlBST1RPIHNh eSB0aGF0IFImUy9YJlkgYXJlIGFsd2F5cyAzMiBieXRlcyBhbmQgc28gbGVhZGluZyB6ZXJvcyBu ZWVkIHRvIGJlIGFkZGVkIG9yIHJldGFpbmVkPw0KVGhhbmtzIGZvciBvYmxpZ2luZyBteSBsaXR0 bGUgcXVlc3Rpb25zLA0KQnJpYW4NCg0K --_000_BN3PR03MB144572B382F3081A2FF8776E8C4B0BN3PR03MB1445namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25vcm1hbDAs IGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1h bDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uSFRNTFBy ZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3Jt YXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgZmVlZGJhY2sgQnJpYW4s IEnigJlsbCBjbGFyaWZ5IGluIHRoZSBuZXh0IHJldmlzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+QW5kcmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFVuYmVhcmFibGUgW21haWx0bzp1bmJl YXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyaWFuIENhbXBi ZWxsPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1heSAxNywgMjAxNiAxMjozNSBQTTxicj4N CjxiPlRvOjwvYj4gSUVURiBUb2tiaW5kIFdHICZsdDt1bmJlYXJhYmxlQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBbVW5iZWFyYWJsZV0gZWNkc2FwMjU2IHF1ZXN0aW9uczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SXMgZWNkc2FwMjU2IHRoZSBOSVNUIFAtMjU2IGN1 cnZlPyBJJ20gZ3Vlc3Npbmcgc28gYnV0IGl0J3Mgbm90IHRvdGFsbHkgY2xlYXIgZnJvbSB0aGUg ZG9jdW1lbnQuIFRoZSByZWxldmFudCB0ZXh0ICh0aGF0IEkgY291bGQgZmluZCBhbnl3YXkpIGZy b20gVEJQUk9UTy0wMyBoZXJlOjxvOnA+PC9vOnA+PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsgJnF1 b3Q7V2hlbiBhbiBlY2RzYXAyNTYga2V5IGlzIHVzZWQsIFRva2VuQmluZGluZy5zaWduYXR1cmUg Y29udGFpbnMgYSBwYWlyPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IG9mIGlu dGVnZXJzLCBSIGZvbGxvd2VkIGJ5IFMsIGFzIGRlZmluZWQgaW4gWzxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQtcHJvdG9jb2wtMDUjcmVmLUFO U0kuWDktNjIuMjAwNSIgdGFyZ2V0PSJfYmxhbmsiPkFOU0kuWDktNjIuMjAwNTwvYT5dLiZuYnNw OyBSIGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBTIGFyZSBlbmNvZGVk IGluIGJpZy1lbmRpYW4gZm9ybWF0LiZuYnNwOyBFQ1BvaW50LnBvaW50IGNvbnRhaW5zIHRoZSBY PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGNvb3JkaW5hdGUgZm9sbG93ZWQg YnkgdGhlIFkgY29vcmRpbmF0ZS4mbmJzcDsgVGhlIFggYW5kIFkgY29vcmRpbmF0ZXMgYXJlPG86 cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IHVuc2lnbmVkIGludGVnZXJzIGVuY29k ZWQgaW4gYmlnLWVuZGlhbiBmb3JtYXQuJnF1b3Q7PG86cD48L286cD48L3ByZT4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgd2FzIGdvaW5nIHRvIHN1Z2dl c3QgdGhhdCBUQlBST1RPIGV4cGxpY2l0bHkgc2F5IHRoYXQgZm9yIGVjZHNhcDI1NiBSICZhbXA7 IFMgYW5kIFggJmFtcDsgWSBhbHdheXMgYmUgZXhhY3RseSAzMiBvY3RldHMvYnl0ZXMgbG9uZyBh bmQgdGhhdCBhbnkgbGVhZGluZyB6ZXJvIGJ5dGVzIGJlIHByZXNlcnZlZCAocmFyZSBidXQgcG9z c2libGUgQUZBSUspLCB3aGljaCBJIGFzc3VtZQ0KIHdhcyB0aGUgaW50ZW50IHNvIHRoYXQgdGhl IHBvaW50IGFuZCBzaWduYXR1cmUgY2FuIGJlIGNvbnNpc3RlbnRseSBwcm9jZXNzZWQuIFRoZW4g SSB0aG91Z2h0IG1heWJlIEkgc2hvdWxkIGZpcnN0IGxvb2sgYXQgQU5TSS5YOS02MiB0byBzZWUg aWYgdGhpcyB3YXMgYWxyZWFkeSBjbGVhcmx5IHN0YXRlZCB0aGVyZSBzb21ld2hlcmUuIEJ1dCBp dCBzZWVtcyB0aGF0IG9uZSBjYW4ndCBhY3R1YWxseSByZWFkIFg5LTYyIHdpdGhvdXQgc2hlbGxp bmcNCiBvdXQgJDEwMCwgd2hpY2ggaXMgYSBsb3QgdG8ganVzdCBsb29rIGZvciBhIGxpdHRsZSBk ZXRhaWxzIGxpa2UgdGhhdC4mbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+U28sIGZyb20g dGhhdCBmdW4gbGl0dGxlIHN0b3J5IChzb3JyeSEpLCBhIGNvdXBsZSBjb21tZW50cy9xdWVzdGlv bnM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+Q2FuIFRCUFJPVE8gc3RhdGUgdGhlIGN1cnZlIHVzZWQgd2l0 aCB0aGUgZWNkc2FwMjU2IFRCIGtleSBwYXJhbWV0ZXJzIGluIGEgd2F5IHRoYXQncyBlYXN5IGFu ZCBvYnZpb3VzPyBBbmQgbWF5YmUgYWxzbyBjaXRlIGEgZG9jdW1lbnQgdGhhdCdzIGEgbGl0dGxl IG1vcmUgYWNjZXNzaWJsZSB0aGFuIFg5LTYyIGluIGRvaW5nIHNvPyZuYnNwOyBJIGJlbGlldmUg bWFueQ0KIFJGQ3MsIDxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc1MTgj c2VjdGlvbi0zLjQiIHRhcmdldD0iX2JsYW5rIj43NTE4L0pXQTwvYT4gZm9yIGV4YW1wbGUsIGNp dGUNCjxhIGhyZWY9Imh0dHA6Ly9udmxwdWJzLm5pc3QuZ292L25pc3RwdWJzL0ZJUFMvTklTVC5G SVBTLjE4Ni00LnBkZiIgdGFyZ2V0PSJfYmxhbmsiPg0KRklQUyBQVUIgMTg2LTQgJnF1b3Q7RGln aXRhbCBTaWduYXR1cmUgU3RhbmRhcmQgKERTUykmcXVvdDs8L2E+IGZvciBFQ0RTQSBhbmQgdGhl IFAtKiBjdXJ2ZXMuIEkgZXhwZWN0IG1vc3QgaW1wbGVtZW50ZXJzIHdpbGwgYmUgdXNpbmcgYW4g ZXhpc3RpbmcgRUNEU0EgaW1wbGVtZW50YXRpb24gYW5kIGp1c3QgbmVlZCB0byBnZXQgdGhlIHBh cmFtZXRlcnMgYW5kIGlucHV0L291dHB1dCBmb3JtYXR0ZWQgY29ycmVjdGx5LiBUaGF0IHJlZmVy ZW5jZSBhbmQgdGhlIHRleHQNCiBpbiBKV0Egd2FzIGVub3VnaCBmb3IgbWFueSBpbmRlcGVuZGVu dCBpbXBsZW1lbnRhdGlvbnMgdG8gZ2V0IGl0IHJpZ2h0IHdpdGggSldTLg0KPG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPkFuZCBhYm91dCBnZXR0aW5nIHRoZSBpbnB1dC9vdXRwdXQgZm9y bWF0dGVkIGNvcnJlY3RseSwgY2FuIG9yIHNob3VsZCBUQlBST1RPIHNheSB0aGF0IFImYW1wO1Mv WCZhbXA7WSBhcmUgYWx3YXlzIDMyIGJ5dGVzIGFuZCBzbyBsZWFkaW5nIHplcm9zIG5lZWQgdG8g YmUgYWRkZWQgb3IgcmV0YWluZWQ/DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3Igb2JsaWdpbmcgbXkgbGl0dGxlIHF1ZXN0aW9u cywgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C cmlhbiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN3PR03MB144572B382F3081A2FF8776E8C4B0BN3PR03MB1445namp_-- From nobody Fri May 20 16:38:32 2016 Return-Path: X-Original-To: unbearable@ietf.org Delivered-To: unbearable@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31A8312D673; Fri, 20 May 2016 16:38:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160520233829.4819.15659.idtracker@ietfa.amsl.com> Date: Fri, 20 May 2016 16:38:29 -0700 Archived-At: Cc: unbearable@ietf.org Subject: [Unbearable] I-D Action: draft-ietf-tokbind-protocol-06.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 20 May 2016 23:38:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Token Binding of the IETF. Title : The Token Binding Protocol Version 1.0 Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Jeff Hodges Filename : draft-ietf-tokbind-protocol-06.txt Pages : 15 Date : 2016-05-20 Abstract: This document specifies Version 1.0 of the Token Binding protocol. The Token Binding protocol allows client/server applications to create long-lived, uniquely identifiable TLS [RFC5246] bindings spanning multiple TLS sessions and connections. Applications are then enabled to cryptographically bind security tokens to the TLS layer, preventing token export and replay attacks. To protect privacy, the TLS Token Binding identifiers are only transmitted encrypted and can be reset by the user at any time. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tokbind-protocol-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-protocol-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 20 16:54:58 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8021112D662; Fri, 20 May 2016 16:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgZk585-qghC; Fri, 20 May 2016 16:54:54 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0133.outbound.protection.outlook.com [207.46.100.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 92D2E12D5D2; Fri, 20 May 2016 16:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pScM7Rl2+7G6/fSU1QeaoA8tnsoM8qW/0FQFKAnV9vk=; b=B7+ialITEVQEO0pjebqt8t6SWe/pKiJNtJNQZYogy/bKG0EtunvK1kOFrO+TsaHhvGtT4NORODc9g0aSvx+v4tZscaJcwza40+/jtaprE4EDMwZhKaSTzPWFFxJAdlbD0nCu1eLOyTLP/zTfrWzQv410bV1rtu3MsaRP9cQSJ/o= Received: from BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) by BN3PR03MB1447.namprd03.prod.outlook.com (10.163.34.30) with Microsoft SMTP Server (TLS) id 15.1.501.7; Fri, 20 May 2016 23:54:53 +0000 Received: from BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) by BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) with mapi id 15.01.0501.011; Fri, 20 May 2016 23:54:53 +0000 From: Andrei Popov To: "internet-drafts@ietf.org" Thread-Topic: [Unbearable] I-D Action: draft-ietf-tokbind-protocol-06.txt Thread-Index: AQHRsvDDJgSIkJM+1EOPeTdj41YXzp/CfCCg Date: Fri, 20 May 2016 23:54:52 +0000 Message-ID: References: <20160520233829.4819.15659.idtracker@ietfa.amsl.com> In-Reply-To: <20160520233829.4819.15659.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8::1d2] x-ms-office365-filtering-correlation-id: aab83da0-43c2-4c34-7f71-08d3810a233a x-microsoft-exchange-diagnostics: 1; BN3PR03MB1447; 5:ImFuXlnCNYFYCS9L0/dhNYq/ICfpBxnf40qYtkiCk1bC7e2Zfem9gQo+adPuRg1EN++XySYJ+6Cj3JVmQlnwErtYL1tlQKKKxDzwixPTbRgYERYgu4w+Wm3LGbLR9C64B+7ys5cDRdYlYzWaDl9gCQ==; 24:PY0uPGDTuiIDfIeSl83O4+/C9Abp0WiQP6PWV5u2GdPWWeIN1EvGS5QH4D87bz1h8YzMvrkf/QtQ0rup8hdrufQeEQ0N/EDaiDmq1N4Dnj4=; 7:cFq9UG2Ef2st+3lftGR6v83HAnYKFfPBn2jK1R1/dyz6qhJV3TyCLGk+SrI3qsGldiz7EPV/mI/4ToU+qIlhT2S+EeqQjvK+365x04qfKEO2a4F6o6/W56M3MVdDbStAcW2IdapcO+ZT3iFk/0XAc/mHUaHjBwIcCJiEJfV8K3wdOWwC0TBXqLTCA1oLckf3LKck6wHtR+A/3PwqHd85Fg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1447; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR03MB1447; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1447; x-forefront-prvs: 09480768F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(377424004)(76576001)(87936001)(586003)(9686002)(2501003)(102836003)(6116002)(81166006)(8676002)(110136002)(4326007)(5002640100001)(86362001)(92566002)(10090500001)(5640700001)(2906002)(74316001)(450100001)(230783001)(76176999)(54356999)(1220700001)(2950100001)(50986999)(5003600100002)(99286002)(2900100001)(33656002)(106116001)(5008740100001)(19580405001)(19580395003)(3660700001)(122556002)(2351001)(11100500001)(189998001)(10290500002)(5004730100002)(77096005)(15975445007)(8936002)(3280700002)(10400500002)(5005710100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1447; H:BN3PR03MB1445.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2016 23:54:52.7095 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1447 Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] I-D Action: draft-ietf-tokbind-protocol-06.txt X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 20 May 2016 23:54:56 -0000 VEJQUk9UTy0wNiBpbmNsdWRlcyBlZGl0b3JpYWwgY2hhbmdlcyBmcm9tIEplZmYgSG9kZ2VzIGFu ZCBFQ0RTQSBQLTI1NiBjbGFyaWZpY2F0aW9ucyBzdWdnZXN0ZWQgYnkgQnJpYW4gQ2FtcGJlbGwu DQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQpTZW50OiBGcmlkYXksIE1heSAyMCwgMjAx NiA0OjM4IFBNDQpUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQpDYzogdW5iZWFyYWJsZUBpZXRm Lm9yZw0KU3ViamVjdDogW1VuYmVhcmFibGVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtdG9rYmlu ZC1wcm90b2NvbC0wNi50eHQNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0 IGlzIGEgd29yayBpdGVtIG9mIHRoZSBUb2tlbiBCaW5kaW5nIG9mIHRoZSBJRVRGLg0KDQogICAg ICAgIFRpdGxlICAgICAgICAgICA6IFRoZSBUb2tlbiBCaW5kaW5nIFByb3RvY29sIFZlcnNpb24g MS4wDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IEFuZHJlaSBQb3Bvdg0KICAgICAgICAgICAg ICAgICAgICAgICAgICBNYWdudXMgTnlzdHLDtm0NCiAgICAgICAgICAgICAgICAgICAgICAgICAg RGlyayBCYWxmYW56DQogICAgICAgICAgICAgICAgICAgICAgICAgIEFkYW0gTGFuZ2xleQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICBKZWZmIEhvZGdlcw0KCUZpbGVuYW1lICAgICAgICA6IGRy YWZ0LWlldGYtdG9rYmluZC1wcm90b2NvbC0wNi50eHQNCglQYWdlcyAgICAgICAgICAgOiAxNQ0K CURhdGUgICAgICAgICAgICA6IDIwMTYtMDUtMjANCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3Vt ZW50IHNwZWNpZmllcyBWZXJzaW9uIDEuMCBvZiB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbC4N CiAgIFRoZSBUb2tlbiBCaW5kaW5nIHByb3RvY29sIGFsbG93cyBjbGllbnQvc2VydmVyIGFwcGxp Y2F0aW9ucyB0bw0KICAgY3JlYXRlIGxvbmctbGl2ZWQsIHVuaXF1ZWx5IGlkZW50aWZpYWJsZSBU TFMgW1JGQzUyNDZdIGJpbmRpbmdzDQogICBzcGFubmluZyBtdWx0aXBsZSBUTFMgc2Vzc2lvbnMg YW5kIGNvbm5lY3Rpb25zLiAgQXBwbGljYXRpb25zIGFyZQ0KICAgdGhlbiBlbmFibGVkIHRvIGNy eXB0b2dyYXBoaWNhbGx5IGJpbmQgc2VjdXJpdHkgdG9rZW5zIHRvIHRoZSBUTFMNCiAgIGxheWVy LCBwcmV2ZW50aW5nIHRva2VuIGV4cG9ydCBhbmQgcmVwbGF5IGF0dGFja3MuICBUbyBwcm90ZWN0 DQogICBwcml2YWN5LCB0aGUgVExTIFRva2VuIEJpbmRpbmcgaWRlbnRpZmllcnMgYXJlIG9ubHkg dHJhbnNtaXR0ZWQNCiAgIGVuY3J5cHRlZCBhbmQgY2FuIGJlIHJlc2V0IGJ5IHRoZSB1c2VyIGF0 IGFueSB0aW1lLg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlz IGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10 b2tiaW5kLXByb3RvY29sLw0KDQpUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWls YWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQt cHJvdG9jb2wtMDYNCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxh YmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtdG9r YmluZC1wcm90b2NvbC0wNg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0K SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0K ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0DQpV bmJlYXJhYmxlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3VuYmVhcmFibGUNCg== From nobody Mon May 23 15:05:36 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20AEA12D136 for ; Mon, 23 May 2016 15:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-ZhMyRCsrQ6 for ; Mon, 23 May 2016 15:05:33 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30A7F12D59A for ; Mon, 23 May 2016 15:05:33 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id y2so170402844vka.3 for ; Mon, 23 May 2016 15:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l8tcMrct1cHbLjp7E8bc9cn2YmRhmOXF3jA54w7PztE=; b=A1uVoLD6F4/yhHx43PIF4WMe3mYeJArNSRG/suic8p+g5K0aLM3bXFWTBi3RwHL8QV /OGOxFDltNlHiFeEodLCZr5MEcI2DvvuPiq6d7xzbbFZRovj/GNy/4i5WMEPNohI1+Rf 83LlWENIYM/nQHOirUXhbcsSkrxgiKFNl6WTxQd38vBRqmYg5PtHmdGT+yvXrwxwI+7T 3FhmXNdwfJPRIaF0gVLLOTQcU+bCj24zfnvRJ8Y0O6LYlPrdnV6SL0WFrYXNn0rRhWs2 X2YSsQuRTuIyLFq2r+BL8c5OS9uK8sDbPla8C34Su4fz+E6RWt8d+dsuXjq/ulBaIAk+ M6ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l8tcMrct1cHbLjp7E8bc9cn2YmRhmOXF3jA54w7PztE=; b=UwC6WD/WOWQQX08TWkcUEsX0WzBiKUyqngU2TLr6+UytYZiGHONXqbLAj3beGBKfU8 QQpdqMmJgSQyn7JgFNpzW+yokmDGM7FHWMbAQmfURPGr57stGKkY8KoPQVKkE0zfBNcG 205OOw/VBh+VKg1NXKro/JZuID7t3xOjTeDgFtFqNvuwgFLqbgl0c+rX3Sw/Cc1migE5 5ttdGM5hv61UjJeMPIMjI3hSEas4K8hIGx7grd3wuqqr37335hiXlYKvhdCi7RqV5xPc K+Snhz37zVLYRxNZDdZCEDKVcU1ANuvRxTT8LyC+Sl094H+JSCXZ57RWVwFdhkOyAkqb 8+lQ== X-Gm-Message-State: ALyK8tK5f21ILgqwOjxQhBAC7I+RXb315+pAYtAN4/jMyspYeFOjksPiQBHhknOb/LMhpPPkhxAHlZLY+Gw8fOJI X-Received: by 10.31.107.207 with SMTP id k76mr637307vki.52.1464041131971; Mon, 23 May 2016 15:05:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.26.132 with HTTP; Mon, 23 May 2016 15:05:12 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Mon, 23 May 2016 15:05:12 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a114785ae9bfb44053389a306 Archived-At: Cc: IETF Tokbind WG , Brian Campbell Subject: Re: [Unbearable] ecdsap256 questions X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 22:05:35 -0000 --001a114785ae9bfb44053389a306 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm curious as to why the format for R&S was chosen as such in draft-06. The format that my implementation uses differs from what is in draft-06, yet as far as I can tell is compliant with the draft-05 version. My implementation formats the signature as a DER-encoded ECDSA-Sig-Value ASN.1 object. This is defined in RFC 5480, which refers to X9.62 as where this ASN.1 definition comes from (I also don't have a copy of X9.62 to check against). This definition (the ECDSA-Sig-Value ASN.1 object) is the same format of signature used in tls, so it seems like a Token Binding library should have no difficulty producing/consuming this signature format. If X9.62 is going to be used as the reference for this pair of 32-byte ints with leading zeroes, can the section of X9.62 that defines this be cited? On Fri, May 20, 2016 at 12:08 PM, Andrei Popov wrote: > Thanks for the feedback Brian, I=E2=80=99ll clarify in the next revision. > > > > Cheers, > > > > Andrei > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Br= ian > Campbell > *Sent:* Tuesday, May 17, 2016 12:35 PM > *To:* IETF Tokbind WG > *Subject:* [Unbearable] ecdsap256 questions > > > > Is ecdsap256 the NIST P-256 curve? I'm guessing so but it's not totally > clear from the document. The relevant text (that I could find anyway) fro= m > TBPROTO-03 here: > > "When an ecdsap256 key is used, TokenBinding.signature contains a pair > > of integers, R followed by S, as defined in [ANSI.X9-62.2005 ]. = R and > > S are encoded in big-endian format. ECPoint.point contains the X > > coordinate followed by the Y coordinate. The X and Y coordinates are > > unsigned integers encoded in big-endian format." > > > > I was going to suggest that TBPROTO explicitly say that for ecdsap256 R & > S and X & Y always be exactly 32 octets/bytes long and that any leading > zero bytes be preserved (rare but possible AFAIK), which I assume was the > intent so that the point and signature can be consistently processed. The= n > I thought maybe I should first look at ANSI.X9-62 to see if this was > already clearly stated there somewhere. But it seems that one can't > actually read X9-62 without shelling out $100, which is a lot to just loo= k > for a little details like that. > > So, from that fun little story (sorry!), a couple comments/questions: > > Can TBPROTO state the curve used with the ecdsap256 TB key parameters in = a > way that's easy and obvious? And maybe also cite a document that's a litt= le > more accessible than X9-62 in doing so? I believe many RFCs, 7518/JWA > for example, cite FIPS > PUB 186-4 "Digital Signature Standard (DSS)" > for ECDSA and > the P-* curves. I expect most implementers will be using an existing ECDS= A > implementation and just need to get the parameters and input/output > formatted correctly. That reference and the text in JWA was enough for ma= ny > independent implementations to get it right with JWS. > > And about getting the input/output formatted correctly, can or should > TBPROTO say that R&S/X&Y are always 32 bytes and so leading zeros need to > be added or retained? > > Thanks for obliging my little questions, > > Brian > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a114785ae9bfb44053389a306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm curious as to why the format for R&S was chose= n as such in draft-06. The format that my implementation uses differs from = what is in draft-06, yet as far as I can tell is compliant with the draft-0= 5 version. My implementation formats the signature as a DER-encoded=C2=A0ECDSA-Sig-Value ASN.1 ob= ject. This is defined in RFC 5480, which refers to X9.62 as where this ASN.= 1 definition comes from (I also don't have a copy of X9.62 to check aga= inst). This definition (the ECDSA-Sig-Value ASN.1 object) is the same forma= t of signature used in tls, so it seems like a Token Binding library should= have no difficulty producing/consuming this signature format. If X9.62 is = going to be used as the reference for this pair of 32-byte ints with leadin= g zeroes, can the section of X9.62 that defines this be cited?
=

On Fri, May 20, 2= 016 at 12:08 PM, Andrei Popov <Andrei.Popov@microsoft.com>= wrote:

Thanks for the feedback Brian, I=E2= =80=99ll clarify in the next revision.

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ie= tf.org] On Behalf Of Brian Campbell
Sent: Tuesday, May 17, 2016 12:35 PM
To: IETF Tokbind WG <unbearable@ietf.org>
Subject: [Unbearable] ecdsap256 questions

=C2=A0

Is ecdsap256 the NIST= P-256 curve? I'm guessing so but it's not totally clear from the d= ocument. The relevant text (that I could find anyway) from TBPROTO-03 here:= 

=C2=A0=C2=A0 "When an ecdsap256 key is used, TokenBinding.signatu=
re contains a pair
=C2=A0=C2=A0 of integers, R followed by S, as defined in [ANSI.X9-62.2005].=C2=A0 R and
=C2=A0=C2=A0 S are encoded in big-endian format.=C2=A0 ECPoint.point c=
ontains the X
=C2=A0=C2=A0 coordinate followed by the Y coordinate.=C2=A0 The X and =
Y coordinates are
=C2=A0=C2=A0 unsigned integers encoded in big-endian format."<=
/u>

=C2=A0

I was going to sugges= t that TBPROTO explicitly say that for ecdsap256 R & S and X & Y al= ways be exactly 32 octets/bytes long and that any leading zero bytes be pre= served (rare but possible AFAIK), which I assume was the intent so that the point and signature can be consistently process= ed. Then I thought maybe I should first look at ANSI.X9-62 to see if this w= as already clearly stated there somewhere. But it seems that one can't = actually read X9-62 without shelling out $100, which is a lot to just look for a little details like that.=C2= =A0=C2=A0

So, from that fun lit= tle story (sorry!), a couple comments/questions:

Can TBPROTO state the= curve used with the ecdsap256 TB key parameters in a way that's easy a= nd obvious? And maybe also cite a document that's a little more accessi= ble than X9-62 in doing so?=C2=A0 I believe many RFCs, 7518/JWA for example, cite FIPS PUB 186-4 "Digital Signature Standard (DSS)" for ECDSA a= nd the P-* curves. I expect most implementers will be using an existing ECD= SA implementation and just need to get the parameters and input/output form= atted correctly. That reference and the text in JWA was enough for many independent implementations to get it right wit= h JWS.

And about getting the= input/output formatted correctly, can or should TBPROTO say that R&S/X= &Y are always 32 bytes and so leading zeros need to be added or retaine= d?

Thanks for obliging my little questions, <= /u>

Brian

=C2=A0<= /p>


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


--001a114785ae9bfb44053389a306-- From nobody Mon May 23 15:17:46 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC6112D5CE for ; Mon, 23 May 2016 15:17:44 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X63EDT_EJP5I for ; Mon, 23 May 2016 15:17:43 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 700B612B050 for ; Mon, 23 May 2016 15:17:43 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id e62so40128465ita.1 for ; Mon, 23 May 2016 15:17:43 -0700 (PDT) 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; bh=t06n807HoqBfgeuI/DperiluudHwxIZGAxw10zAuRFg=; b=NMkN4GbsZv1v7458LhhAm8VMtE6urAW5Q+s7B+eVV38b9ayafhlx1BLLtJavA3xyR0 Mk1MkSCw34ktfqcn+VynovT6kydXjGnnTkf3nfWkOPmPbaEA8HvZVxPVZCEu/nkU3kWI 4aPocFV3StY5JaXJG4WeFC5ZFBcARXYiTbVG7S3NNWhvftOitQ2lPqtFCj+D5OvDdkmK hP27zkIhNJzddO3ZfeYLsKbetshGYBx6Kbpw1hoITmj9dJnBOwclICgafqZSNzGXcJ1U DUwpf44514ScYBAY3qQAt4mjJ078TBTtVDZB5gEN+bIfmCvhXza1ZAhsS0s4HggilMri uONQ== 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; bh=t06n807HoqBfgeuI/DperiluudHwxIZGAxw10zAuRFg=; b=HKV3b8tEWevjpWW5WNbAaneQiXVo19AR8OgXFz5jN49DqNdks3gyv8SKlOcu4OOhTu 8ap7twyoPYx8XiunaXgkfrE7zYAdb5ATIHpV/+UGcUyBwGyVVEa7+C47yftz9/2FNM5a 0tPDoAKGY+1e9WmggxsVhZ9GfgMS9ln+fJeHi2CRi9tCyL/qxnYQ5YAk00Vg2edKQtxV zo65rWJayrlIKfDgEGQPbTDnHu2/FY5vNdeTKECHYChYq/us616Y8P4X2XDuhoxrNlQ5 CdtSgzjQz4z8aG5QrauIVS9xwDvIQjp0dXwx14sFmerBDkwiXbBA6Nyka3pQRIWORsmr azDA== X-Gm-Message-State: ALyK8tKaz0ohMxNTlrtJz+QAk6iwYM3DpfTFXAR/2WX4/0v4dZanIKDCKk0Oj6Z9S+1c2tiZtuu63jXu8sVE6w== MIME-Version: 1.0 X-Received: by 10.36.254.131 with SMTP id w125mr1551231ith.49.1464041862702; Mon, 23 May 2016 15:17:42 -0700 (PDT) Received: by 10.36.43.23 with HTTP; Mon, 23 May 2016 15:17:42 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 May 2016 18:17:42 -0400 Message-ID: From: Martin Thomson To: Nick Harper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Andrei Popov , Brian Campbell , IETF Tokbind WG Subject: Re: [Unbearable] ecdsap256 questions X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 22:17:44 -0000 On 23 May 2016 at 18:05, Nick Harper wrote: > My implementation formats the signature as a DER-encoded ECDSA-Sig-Value > ASN.1 object. R||S is pretty widely used now. We definitely don't need more ASN.1+DER. I think that you will find that there is no single reference for this, though WebCrypto does it this way, as does a bunch of other more modern stuff. The idea being that you don't need to worry about R and S separately, which is good for your API. You definitely don't need to carry around the extra baggage that DER provides you with. That is, you keep the API clean: S = sign(k, M) ok = verify(K, M, S) From nobody Mon May 23 15:39:15 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6104B12DBEA for ; Mon, 23 May 2016 15:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ne-rVgLvBzXW for ; Mon, 23 May 2016 15:39:12 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0114.outbound.protection.outlook.com [207.46.100.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E8612B008 for ; Mon, 23 May 2016 15:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=90OO984k/d0nu5Xmzb/thSN6PSN31Ze/J/BjdBRYsj8=; b=DP2LfcZoajrp/tEaOqgtfzVRTfUqMKCgBSfSztwbf7DABD+JzyEt79FZ+eHYyLNGVGPNtEPQww9TD+jZIsnwBcl6iwA05jYda8rW4wTK1FJqeWS8IqVK5B9ZecN5cacDuWK51QuIUr3BidEK3tlI7oqsJEauUrUuxe6ICrgxuWI= Received: from BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) by BN3PR03MB1446.namprd03.prod.outlook.com (10.163.34.29) with Microsoft SMTP Server (TLS) id 15.1.501.7; Mon, 23 May 2016 22:39:09 +0000 Received: from BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) by BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) with mapi id 15.01.0501.012; Mon, 23 May 2016 22:39:09 +0000 From: Andrei Popov To: Martin Thomson , Nick Harper Thread-Topic: [Unbearable] ecdsap256 questions Thread-Index: AQHRsHNO0gHpa/iOlEmlbmpufE8V3p/CNOMwgATokQCAAAN+AIAAA/Dw Date: Mon, 23 May 2016 22:39:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:7::1d2] x-ms-office365-filtering-correlation-id: 5aa26459-977a-4af2-7dc7-08d3835b0e67 x-microsoft-exchange-diagnostics: 1; BN3PR03MB1446; 5:iPYnpskOEhyaj4PSo73HcNML3Lg2GtvQzuSKma9dBmoCyAzlO609fAQVL6tpgaENmvwXWBiLNUElGxV8/5gNyRVleLh3xXseLERn+Uy4XYw8ctHs/OwfFkozJrNpvhFqscjDSINuXLdl+GkHeqZSGQ==; 24:QMWdrAYhZRPWoU+MDAFnQiKfb9DqJQ5j4iuG2so8zWMRzofmT8400ffYGeZyjt59K/yGKAiNeUSB+IjFM4Chb25VIQJNImBzYp631SVXL2o=; 7:y2M4fZgpkCJ4iVkuK/GYsOJeN5reivKvY0R03YgsuRg1QwqUk3dr4eItZ4XDk5Mxi9NRQnMggdbkIxWbKChwecbUaMkaCXnWFTwtxcBTM3d0mlUtaF9fUZRFg0HADI2B/wPk+nXlSPnS4+Gl2CokLfm12nSvDwbCEtWKv6W7waEl1pOCaButD0Jp7Xo2z9ERZsZhkWQJd/mPmmeUe+X4Dg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR03MB1446; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1446; x-forefront-prvs: 0951AB0A30 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(24454002)(33656002)(5002640100001)(189998001)(86362001)(86612001)(93886004)(5001770100001)(5003600100002)(10090500001)(76576001)(87936001)(10290500002)(10400500002)(5005710100001)(5004730100002)(50986999)(19580405001)(1220700001)(2906002)(54356999)(2950100001)(76176999)(19580395003)(2900100001)(106116001)(6116002)(586003)(102836003)(5008740100001)(77096005)(4326007)(11100500001)(92566002)(9686002)(74316001)(81166006)(8936002)(8676002)(122556002)(3280700002)(99286002)(3660700001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1446; H:BN3PR03MB1445.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 May 2016 22:39:09.3775 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1446 Archived-At: Cc: IETF Tokbind WG , Brian Campbell Subject: Re: [Unbearable] ecdsap256 questions X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 22:39:13 -0000 PiBJJ20gY3VyaW91cyBhcyB0byB3aHkgdGhlIGZvcm1hdCBmb3IgUiZTIHdhcyBjaG9zZW4gYXMg c3VjaCBpbiBkcmFmdC0wNi4NCg0KQXMgZWFybHkgYXMgVEJQUk9UTy0wNCB3ZSBzYWlkICIgUiBh bmQgUyBhcmUgZW5jb2RlZCBpbiBiaWctZW5kaWFuIGZvcm1hdC4iDQpUQlBST1RPLTA2IG9ubHkg Y2xhcmlmaWVkIHRoYXQgdGhlcmUgYXJlIDMyIGJ5dGVzIGFuZCBsZWFkaW5nIHplcm9zIChpZiBh bnkpIGFyZSBwcmVzZXJ2ZWQsIHBlciBCcmlhbidzIGNvbW1lbnQuDQoNCk15IG9yaWdpbmFsIHRo aW5raW5nIHdhcyB0aGF0IHdlIHdvdWxkIHVzZSBUTFMtc3R5bGUgQVNOLjErREVSLCBidXQgdGhl cmUgaGF2ZSBiZWVuIGNvbmNlcm5zIGFib3V0IHVubmVjZXNzYXJ5IGNvbXBsZXhpdHkuIEkgdGVu ZCB0byBhZ3JlZSB3aXRoIE1hcnRpbiB0aGF0IHdlIGRvbid0IG5lZWQgbW9yZSBBU04uMStERVIu Li4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IE1hcnRpbiBUaG9tc29uIFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tXSANClNl bnQ6IE1vbmRheSwgTWF5IDIzLCAyMDE2IDM6MTggUE0NClRvOiBOaWNrIEhhcnBlciA8bmhhcnBl ckBnb29nbGUuY29tPg0KQ2M6IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5j b20+OyBJRVRGIFRva2JpbmQgV0cgPHVuYmVhcmFibGVAaWV0Zi5vcmc+OyBCcmlhbiBDYW1wYmVs bCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVd IGVjZHNhcDI1NiBxdWVzdGlvbnMNCg0KT24gMjMgTWF5IDIwMTYgYXQgMTg6MDUsIE5pY2sgSGFy cGVyIDxuaGFycGVyQGdvb2dsZS5jb20+IHdyb3RlOg0KPiBNeSBpbXBsZW1lbnRhdGlvbiBmb3Jt YXRzIHRoZSBzaWduYXR1cmUgYXMgYSBERVItZW5jb2RlZCANCj4gRUNEU0EtU2lnLVZhbHVlDQo+ IEFTTi4xIG9iamVjdC4NCg0KUnx8UyBpcyBwcmV0dHkgd2lkZWx5IHVzZWQgbm93LiAgV2UgZGVm aW5pdGVseSBkb24ndCBuZWVkIG1vcmUNCkFTTi4xK0RFUi4gIEkgdGhpbmsgdGhhdCB5b3Ugd2ls bCBmaW5kIHRoYXQgdGhlcmUgaXMgbm8gc2luZ2xlIHJlZmVyZW5jZSBmb3IgdGhpcywgdGhvdWdo IFdlYkNyeXB0byBkb2VzIGl0IHRoaXMgd2F5LCBhcyBkb2VzIGEgYnVuY2ggb2Ygb3RoZXIgbW9y ZSBtb2Rlcm4gc3R1ZmYuDQoNClRoZSBpZGVhIGJlaW5nIHRoYXQgeW91IGRvbid0IG5lZWQgdG8g d29ycnkgYWJvdXQgUiBhbmQgUyBzZXBhcmF0ZWx5LCB3aGljaCBpcyBnb29kIGZvciB5b3VyIEFQ SS4gIFlvdSBkZWZpbml0ZWx5IGRvbid0IG5lZWQgdG8gY2FycnkgYXJvdW5kIHRoZSBleHRyYSBi YWdnYWdlIHRoYXQgREVSIHByb3ZpZGVzIHlvdSB3aXRoLiAgVGhhdCBpcywgeW91IGtlZXAgdGhl IEFQSSBjbGVhbjoNCg0KICBTID0gc2lnbihrLCBNKQ0KICBvayA9IHZlcmlmeShLLCBNLCBTKQ0K From nobody Mon May 23 16:17:21 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467CE12B076 for ; Mon, 23 May 2016 16:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id joohoCTkLuSO for ; Mon, 23 May 2016 16:17:18 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 856F912D500 for ; Mon, 23 May 2016 16:17:18 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id c189so313116vkb.1 for ; Mon, 23 May 2016 16:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6eJh6nxt1GDHZhABSw6JTBhjda2zcXBXPWqATl/2eKw=; b=RXgAIHzLVZBKS0RbZw0AT8FIhQmuzulqEqjbi1+iOdmc9YX+nTBK7H2OJzoPA46JWI kXJnbez0L/DdMi2xlLEitoyengxD3r9z0SCNZgDGxo7vPDVjBF18f+3Ir7vbHFzGNdin 7uYufcAAI66l+XJWPioFnPKj3V2N0MICZ3CMXExtyayBbVA1AnEzPp2PxFIQtqIjqWxE MH5tF0N6wxeJmUQTW2gmgYfMnkZGTSW403YkxHg0eD3VM3FT/DfPaEUR33yC2RINvnet hJRGuHxFEXs5WFHxmUlZdQB5iszQJZZZBUICBZyzqy33dD7kB+NeVkGmhOCLrzgKkpxi sIyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6eJh6nxt1GDHZhABSw6JTBhjda2zcXBXPWqATl/2eKw=; b=hcxIuBavN4cHbt/tG2YZxsMBBU0uIRDHygXWnrc6dP39wHoH//q88+sBidq2b4BKnB 9hHhUhsI+mvWI9F/0YpQ+IMaN6TWjkdNjdFuyzIIZZ00WZAU3mrkqrKDNrb56wduFNx1 9As9MtcDeh6Rudb2DLZ4+4ptMHX8RGiPLzf34lS5Qmyw8VxdURdpSQ/U7feFhKd1L9vR FNGyhhGXtrhI7VRrg6Pom7GExjkQGR2ImUr518yYto/yGXnRFMGNFVUE4goVQotavmcC +IAXNAGRVXioyCsb6yLqrVjWuVm9Op7FdosO3luDVUREOKmUWEGGGMXyVjIdF/PMwXo6 ZhXQ== X-Gm-Message-State: ALyK8tI7OC7FRyswhyaEgs4R4nIQwtGYEkCD3NHXk4rRYWxiuLQ6lSiUYD0HNTA+CQr+HGWqsRsGp5/qFiBmhxWQ X-Received: by 10.31.157.211 with SMTP id g202mr732581vke.49.1464045437380; Mon, 23 May 2016 16:17:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.26.132 with HTTP; Mon, 23 May 2016 16:16:57 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Mon, 23 May 2016 16:16:57 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a11427ad83b3d4a05338aa495 Archived-At: Cc: IETF Tokbind WG , Brian Campbell , Martin Thomson Subject: Re: [Unbearable] ecdsap256 questions X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 23 May 2016 23:17:20 -0000 --001a11427ad83b3d4a05338aa495 Content-Type: text/plain; charset=UTF-8 I agree with you and Martin that we don't need more ASN.1 + DER, and the format in draft 06 makes sense for something modern. On Mon, May 23, 2016 at 3:39 PM, Andrei Popov wrote: > > I'm curious as to why the format for R&S was chosen as such in draft-06. > > As early as TBPROTO-04 we said " R and S are encoded in big-endian format." > TBPROTO-06 only clarified that there are 32 bytes and leading zeros (if > any) are preserved, per Brian's comment. > > My original thinking was that we would use TLS-style ASN.1+DER, but there > have been concerns about unnecessary complexity. I tend to agree with > Martin that we don't need more ASN.1+DER... > > Cheers, > > Andrei > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Monday, May 23, 2016 3:18 PM > To: Nick Harper > Cc: Andrei Popov ; IETF Tokbind WG < > unbearable@ietf.org>; Brian Campbell > Subject: Re: [Unbearable] ecdsap256 questions > > On 23 May 2016 at 18:05, Nick Harper wrote: > > My implementation formats the signature as a DER-encoded > > ECDSA-Sig-Value > > ASN.1 object. > > R||S is pretty widely used now. We definitely don't need more > ASN.1+DER. I think that you will find that there is no single reference > for this, though WebCrypto does it this way, as does a bunch of other more > modern stuff. > > The idea being that you don't need to worry about R and S separately, > which is good for your API. You definitely don't need to carry around the > extra baggage that DER provides you with. That is, you keep the API clean: > > S = sign(k, M) > ok = verify(K, M, S) > --001a11427ad83b3d4a05338aa495 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with you and Martin that we don't need more AS= N.1 + DER, and the format in draft 06 makes sense for something modern.

On Mon, May 23,= 2016 at 3:39 PM, Andrei Popov <Andrei.Popov@microsoft.com>= ; wrote:
> I&#= 39;m curious as to why the format for R&S was chosen as such in draft-0= 6.

As early as TBPROTO-04 we said " R and S are encoded in big-end= ian format."
TBPROTO-06 only clarified that there are 32 bytes and leading zeros (if any= ) are preserved, per Brian's comment.

My original thinking was that we would use TLS-style ASN.1+DER, but there h= ave been concerns about unnecessary complexity. I tend to agree with Martin= that we don't need more ASN.1+DER...

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:ma= rtin.thomson@gmail.com]
Sent: Monday, May 23, 2016 3:18 PM
To: Nick Harper <nharper@google.co= m>
Cc: Andrei Popov <Andrei.P= opov@microsoft.com>; IETF Tokbind WG <unbearable@ietf.org>; Brian Campbell <bcampbell@pingidentity.com>
Subject: Re: [Unbearable] ecdsap256 questions

On 23 May 2016 at 18:05, Nick Harper <nharper@google.com> wrote:
> My implementation formats the signature as a DER-encoded
> ECDSA-Sig-Value
> ASN.1 object.

R||S is pretty widely used now.=C2=A0 We definitely don't need more
ASN.1+DER.=C2=A0 I think that you will find that there is no single referen= ce for this, though WebCrypto does it this way, as does a bunch of other mo= re modern stuff.

The idea being that you don't need to worry about R and S separately, w= hich is good for your API.=C2=A0 You definitely don't need to carry aro= und the extra baggage that DER provides you with.=C2=A0 That is, you keep t= he API clean:

=C2=A0 S =3D sign(k, M)
=C2=A0 ok =3D verify(K, M, S)

--001a11427ad83b3d4a05338aa495-- From nobody Mon May 23 17:19:33 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174A612D5F6 for ; Mon, 23 May 2016 17:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQts2_DdQnWs for ; Mon, 23 May 2016 17:19:30 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8DEE12D5EE for ; Mon, 23 May 2016 17:19:29 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id y2so1543147vka.3 for ; Mon, 23 May 2016 17:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e0baXV/Ka1HM0m18H0A7Y0KXN93uE4QuEhGVx8pfV8c=; b=jdyL+AJmW6D3oQu+JeWadi1t1PDH9OKaCJ9QaWWfcR4gS6l23XhMzPGSWcuoxw8huR wndbyDwrFlrgRjYTps2+Mh9xwhNZGyIeRU4MYsiPj+uJFvEOauumRy93jPhIpsuIl6sA sulT2Qcyf9EJSw/z3O65MufIr8+i+So6EE8ZSPsI7LU8Evekc1D2eEqzLLwa9GmxJGXj ly8zNu6XHq+HE+TMIQ2N6qd/EVpwnmY6+zrZZ6r+m9PeVne3eEbRYwl4RUNn8Z/dXzyV kwAX9HxTViakcEHxhB9zNA7nXlGoCw/B6qqvZzU5ZiAUEbZW9YMicut5eRt98Vohsje7 FdRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e0baXV/Ka1HM0m18H0A7Y0KXN93uE4QuEhGVx8pfV8c=; b=SBfgzy/xQ26busP0FWA9HDhN4Fu/1r3CKo8AkEcNxx0RqksAcy64CV7frFea/WaiDi i+a6B7N404B/dMqlkXWD8I95iSCMpii9YWn7WjCxOC20DMZK97qiDP9k4ZL44IN4yg15 pJYB9cXa19jwTOweG0q1CMyUPftU6wHZVDyqQZwF0MYLzYggGRgD3f+gLk0oC40bpWLS vM9VSmEmPDlk7gVdb+W/vyQfXWL2kETVysiQiYRcNfrwOyHyGwO1TeomHANgxhHXS/+k /05Snyo87rn6qwath/uBleKXzKL2zK3AI6quwBsBrm2DbiBWzw0jZ+JxgWpjFtbGsIuc SjRg== X-Gm-Message-State: ALyK8tLMGS6LIHIEtDWzwJ/boUlcJGDYXLX3KdZotX4drIaHUgDutzpWm5hAdwsJ7x9gGLFk/HEH0BZv/CXqeBPZ X-Received: by 10.159.36.39 with SMTP id 36mr997447uaq.34.1464049168677; Mon, 23 May 2016 17:19:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.61.132 with HTTP; Mon, 23 May 2016 17:19:28 -0700 (PDT) In-Reply-To: References: From: Bill Cox Date: Mon, 23 May 2016 17:19:28 -0700 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=001a11352768a2bd2e05338b8209 Archived-At: Cc: Andrei Popov , Brian Campbell , Martin Thomson , IETF Tokbind WG Subject: Re: [Unbearable] ecdsap256 questions X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 May 2016 00:19:31 -0000 --001a11352768a2bd2e05338b8209 Content-Type: text/plain; charset=UTF-8 On Mon, May 23, 2016 at 4:16 PM, Nick Harper wrote: > I agree with you and Martin that we don't need more ASN.1 + DER, and the > format in draft 06 makes sense for something modern. > Just one question: how are the RSA exponent and modulus length-prefixed? Are they uint16-length-prefixed? Bill --001a11352768a2bd2e05338b8209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, May 23, 2016 at 4:16 PM, Nick Harper <nharper@google.com> wrote:
I agree with y= ou and Martin that we don't need more ASN.1 + DER, and the format in dr= aft 06 makes sense for something modern.

<= div>Just one question: how are the RSA exponent and modulus length-prefixed= ?=C2=A0 Are they uint16-length-prefixed?

Bill
--001a11352768a2bd2e05338b8209-- From nobody Mon May 23 17:30:55 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87C812D520 for ; Mon, 23 May 2016 17:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErPQGaQhbE3B for ; Mon, 23 May 2016 17:30:51 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::709]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D78712B00D for ; Mon, 23 May 2016 17:30:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YXistSyARuZXgkNfHupFVaL5Q2YBwNF4527mYjiRmls=; b=KnZNZSGqf5/HdabqFpWJtYZARK6by39FAfaKaQRgTZbu+8xSZRd9BJvqjVCuxqoohHQwkXcY35POwGwDFU+ZKpmwxHjPuFTcdpM0e5Bf1MMFk5kh3ECZ0PN+h+M2ZGWL7+JF6nGyl7OMwoeMiClF7X3NFi+vqGaGa6jAUg+sdl8= Received: from BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) by BN3PR03MB1448.namprd03.prod.outlook.com (10.163.35.11) with Microsoft SMTP Server (TLS) id 15.1.501.7; Tue, 24 May 2016 00:30:32 +0000 Received: from BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) by BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) with mapi id 15.01.0501.012; Tue, 24 May 2016 00:30:31 +0000 From: Andrei Popov To: Bill Cox , Nick Harper Thread-Topic: [Unbearable] ecdsap256 questions Thread-Index: AQHRsHNO0gHpa/iOlEmlbmpufE8V3p/CNOMwgATokQCAAAN+AIAAA/DwgAAMnoCAABF3AIAAAofQ Date: Tue, 24 May 2016 00:30:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: google.com; dkim=none (message not signed) header.d=none;google.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:7::1d2] x-ms-office365-filtering-correlation-id: 25e8db1f-df20-4e09-71d4-08d3836a9d41 x-microsoft-exchange-diagnostics: 1; BN3PR03MB1448; 5:fsE3RYcNiPQ5Rq8wP9Pl5MA9bQ69wyScKWrw8uFcSL4b3uSDxfCKI+YcYorfkav2uzyuqIpxVazcmLh/Vc/axDSCK3Xa8dNTfWzDdh0706Lz2tWeGqu31oylwAnP1AGAKXANy0Uitm+UetMFsk2IVQ==; 24:lTulpU1lpXToxZTfubUyORs5dTfVlOHxLAsOfZzkbOIVv3+wYSb5dxB7TYW9ozL5kh8Q2LRffwHMBE/Z7s7MvSLXKwMID0SWsBJaenh38A0=; 7:RhoiScHc2WY/oU/khMz100UhQ1tUCwGrfcnUaes0wuxR1BmnHI/6UYuopDfWyds1ppyWrMspIERlnPMLb+LmT4RrOB1JW9ERkT3qvzIuxThivuFvATH15Cvo2sepiHcmvf9MkXk3Vet64o3GeLEO2NZvVnIplRRXzbfULTNTj0eVrRgAXZ75Mopa8oBK9kCkadVfdUv5PRnDwVQBLSxz/g== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1448; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR03MB1448; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1448; x-forefront-prvs: 09525C61DB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(377454003)(24454002)(77096005)(2900100001)(15975445007)(19580395003)(2950100001)(5008740100001)(19580405001)(99286002)(86612001)(74316001)(92566002)(122556002)(6116002)(102836003)(790700001)(8676002)(81166006)(1220700001)(19609705001)(87936001)(8936002)(76576001)(586003)(19300405004)(76176999)(50986999)(54356999)(19625215002)(5004730100002)(5001770100001)(3280700002)(3660700001)(10400500002)(10290500002)(5005710100001)(189998001)(16236675004)(33656002)(4326007)(93886004)(8990500004)(5002640100001)(9686002)(5003600100002)(2906002)(106116001)(86362001)(10090500001)(3826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1448; H:BN3PR03MB1445.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB144535196D435593043A07338C4F0BN3PR03MB1445namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2016 00:30:31.2872 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1448 Archived-At: Cc: IETF Tokbind WG , Brian Campbell , Martin Thomson Subject: Re: [Unbearable] ecdsap256 questions X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 24 May 2016 00:30:54 -0000 --_000_BN3PR03MB144535196D435593043A07338C4F0BN3PR03MB1445namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 c3RydWN0IHsNCiAgICBvcGFxdWUgbW9kdWx1czwxLi4yXjE2LTE+Ow0KICAgIG9wYXF1ZSBwdWJs aWNleHBvbmVudDwxLi4yXjgtMT47DQp9IFJTQVB1YmxpY0tleTsNCg0KSW4g4oCcVExTIFByZXNl bnRhdGlvbiBMYW5ndWFnZeKAnSwgdGhpcyBtZWFucyAyIGJ5dGVzIG9mIGxlbmd0aCBwcmVmaXgg Zm9yIG1vZHVsdXMgYW5kIDEgYnl0ZSBvZiBsZW5ndGggcHJlZml4IGZvciBleHBvbmVudC4NCg0K Q2hlZXJzLA0KDQpBbmRyZWkNCg0KRnJvbTogQmlsbCBDb3ggW21haWx0bzp3YXl3YXJkZ2Vla0Bn b29nbGUuY29tXQ0KU2VudDogTW9uZGF5LCBNYXkgMjMsIDIwMTYgNToxOSBQTQ0KVG86IE5pY2sg SGFycGVyIDxuaGFycGVyQGdvb2dsZS5jb20+DQpDYzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9w b3ZAbWljcm9zb2Z0LmNvbT47IElFVEYgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz47 IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT47IE1hcnRpbiBUaG9t c29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVd IGVjZHNhcDI1NiBxdWVzdGlvbnMNCg0KT24gTW9uLCBNYXkgMjMsIDIwMTYgYXQgNDoxNiBQTSwg TmljayBIYXJwZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbTxtYWlsdG86bmhhcnBlckBnb29nbGUuY29t Pj4gd3JvdGU6DQpJIGFncmVlIHdpdGggeW91IGFuZCBNYXJ0aW4gdGhhdCB3ZSBkb24ndCBuZWVk IG1vcmUgQVNOLjEgKyBERVIsIGFuZCB0aGUgZm9ybWF0IGluIGRyYWZ0IDA2IG1ha2VzIHNlbnNl IGZvciBzb21ldGhpbmcgbW9kZXJuLg0KDQpKdXN0IG9uZSBxdWVzdGlvbjogaG93IGFyZSB0aGUg UlNBIGV4cG9uZW50IGFuZCBtb2R1bHVzIGxlbmd0aC1wcmVmaXhlZD8gIEFyZSB0aGV5IHVpbnQx Ni1sZW5ndGgtcHJlZml4ZWQ/DQoNCkJpbGwNCg== --_000_BN3PR03MB144535196D435593043A07338C4F0BN3PR03MB1445namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+c3Ry dWN0IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9wYXF1ZSBtb2R1bHVz Jmx0OzEuLjJeMTYtMSZndDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyBv cGFxdWUgcHVibGljZXhwb25lbnQmbHQ7MS4uMl44LTEmZ3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj59 IFJTQVB1YmxpY0tleTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkluIOKAnFRMUyBQcmVzZW50YXRpb24gTGFuZ3VhZ2XigJ0sIHRoaXMgbWVhbnMgMiBieXRlcyBv ZiBsZW5ndGggcHJlZml4IGZvciBtb2R1bHVzIGFuZCAxIGJ5dGUgb2YgbGVuZ3RoIHByZWZpeCBm b3IgZXhwb25lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5D aGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbmRyZWk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gQmlsbCBDb3ggW21haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tXQ0KPGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgTWF5IDIzLCAyMDE2IDU6MTkgUE08YnI+DQo8Yj5Ubzo8L2I+ IE5pY2sgSGFycGVyICZsdDtuaGFycGVyQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBB bmRyZWkgUG9wb3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tJmd0OzsgSUVURiBUb2ti aW5kIFdHICZsdDt1bmJlYXJhYmxlQGlldGYub3JnJmd0OzsgQnJpYW4gQ2FtcGJlbGwgJmx0O2Jj YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tJmd0OzsgTWFydGluIFRob21zb24gJmx0O21hcnRpbi50 aG9tc29uQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxl XSBlY2RzYXAyNTYgcXVlc3Rpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1heSAyMywgMjAxNiBhdCA0OjE2IFBNLCBOaWNrIEhh cnBlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm5oYXJwZXJAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHdpdGggeW91IGFu ZCBNYXJ0aW4gdGhhdCB3ZSBkb24ndCBuZWVkIG1vcmUgQVNOLjEgJiM0MzsgREVSLCBhbmQgdGhl IGZvcm1hdCBpbiBkcmFmdCAwNiBtYWtlcyBzZW5zZSBmb3Igc29tZXRoaW5nIG1vZGVybi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SnVzdCBvbmUgcXVlc3Rpb246IGhvdyBhcmUgdGhlIFJTQSBleHBvbmVudCBhbmQg bW9kdWx1cyBsZW5ndGgtcHJlZml4ZWQ/Jm5ic3A7IEFyZSB0aGV5IHVpbnQxNi1sZW5ndGgtcHJl Zml4ZWQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkJpbGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN3PR03MB144535196D435593043A07338C4F0BN3PR03MB1445namp_-- From nobody Thu May 26 14:18:44 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C5A12DB42 for ; Thu, 26 May 2016 14:18:41 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeoW7428cscW for ; Thu, 26 May 2016 14:18:39 -0700 (PDT) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1833712DB27 for ; Thu, 26 May 2016 14:17:47 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id z123so53559314itg.0 for ; Thu, 26 May 2016 14:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ay2WcJU1HdWClC+rfaC69YYYMYJnniK0g/eygWczbLw=; b=k9uVyP62/EeyHvnJcCgyOvNaus4HR3JV6Q40gTh9HO/JPOZfuJsecFyoY+LOOYplvu x4Jgh3QWUFtONkXu0tGpO9MqCJpfLKTPvRYzbyjumo7FGY1kjbekqg633L2Lb3Y6s5N/ fl6UucM54E41XdRZU3xtQUlFgbaOnbOithYi4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ay2WcJU1HdWClC+rfaC69YYYMYJnniK0g/eygWczbLw=; b=NsJoMDW+8CBNn4Qt6+a+IEQ3/YVFmw9wa28WuqyTswv9e1HawphB9JJ/Y34KKZVA+b MFU5p2oMUuPi2yjipTtVuNeq0AlE44+FNe4M9OapU+kX2In/krG32tasgxAisXTL9IZT qFeRv2OXXeER6MrorX0KCUANvj724yQNXXDfp8r95IyWJxb04KB7NTuY5aNGMHfVwo5+ s5IeGpPbryxDmOCnEeVZjU3x90ejrxc054pPZQJ3uWSBNSMYMpiovnUz4GunF9eYkDPU M4LhpxWoKK75QbUiHShJMhjBI9A1MjgPF5sJ2kBd+pt3tSaK9D/RlAXWttTih4d9neto EgPg== X-Gm-Message-State: ALyK8tIAYrtTkMFtP786DBqO0Waz4NY8gaUaDXvACEfl3lBtFlp43afLAvBS3VYkv14Mo+8/JIcXQntf5pWWdnEt X-Received: by 10.36.123.77 with SMTP id q74mr5129682itc.42.1464297466368; Thu, 26 May 2016 14:17:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.105.129 with HTTP; Thu, 26 May 2016 14:17:16 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 26 May 2016 15:17:16 -0600 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a11475b225434270533c5522b Archived-At: Cc: IETF Tokbind WG , Martin Thomson , Nick Harper , Bill Cox Subject: Re: [Unbearable] ecdsap256 questions X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 26 May 2016 21:18:41 -0000 --001a11475b225434270533c5522b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Might there be some value in providing some examples in -tokbind-protocol and/or -tokbind-https that could help serve to validate reader's interpretation of the text? As an implementer of JWS & JWE, for instance, I found the examples in the documents to be exceptionally valuable in aiding my understanding and helping to vet the implementation. I think some example TokenBindingMessages in the TB doc(s) could be similarly valuable. On Mon, May 23, 2016 at 6:30 PM, Andrei Popov wrote: > struct { > > opaque modulus<1..2^16-1>; > > opaque publicexponent<1..2^8-1>; > > } RSAPublicKey; > > > > In =E2=80=9CTLS Presentation Language=E2=80=9D, this means 2 bytes of len= gth prefix for > modulus and 1 byte of length prefix for exponent. > > > > Cheers, > > > > Andrei > > > > *From:* Bill Cox [mailto:waywardgeek@google.com] > *Sent:* Monday, May 23, 2016 5:19 PM > *To:* Nick Harper > *Cc:* Andrei Popov ; IETF Tokbind WG < > unbearable@ietf.org>; Brian Campbell ; Martin > Thomson > *Subject:* Re: [Unbearable] ecdsap256 questions > > > > On Mon, May 23, 2016 at 4:16 PM, Nick Harper wrote: > > I agree with you and Martin that we don't need more ASN.1 + DER, and the > format in draft 06 makes sense for something modern. > > > > Just one question: how are the RSA exponent and modulus length-prefixed? > Are they uint16-length-prefixed? > > > > Bill > --001a11475b225434270533c5522b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Might there be some value in providing some examples in -t= okbind-protocol and/or -tokbind-https that could help serve to validate rea= der's interpretation of the text?

As an implementer of JWS &= JWE, for instance, I found the examples in the documents to be exceptional= ly valuable in aiding my understanding and helping to vet the implementatio= n. I think some example TokenBindingMessages in the TB doc(s) could be simi= larly valuable.


On Mon, May 23, 2016 at 6:30 PM, Andrei P= opov <Andrei.Popov@microsoft.com> wrote:

struct {

=C2=A0=C2=A0=C2=A0 opaque modulus<= 1..2^16-1>;

=C2=A0=C2=A0=C2=A0 opaque publicexpon= ent<1..2^8-1>;

} RSAPublicKey;<= /p>

=C2=A0

In =E2=80=9CTLS Presentation Language= =E2=80=9D, this means 2 bytes of length prefix for modulus and 1 byte of le= ngth prefix for exponent.

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Bill Cox [mailto:waywardgeek@google.com]
Sent: Monday, May 23, 2016 5:19 PM
To: Nick Harper <nharper@google.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; IETF Tokbind WG <unbearable@ietf.org<= /a>>; Brian Campbell <bcampbell@pingidentity.com>; Martin Thomson <martin.thomson@g= mail.com>
Subject: Re: [Unbearable] ecdsap256 questions

=C2=A0

On Mon, May 23, 2016 at 4:16 PM, Nick Harper <nharper@google.com= > wrote:

I agree with you and Martin that we don't need m= ore ASN.1 + DER, and the format in draft 06 makes sense for something moder= n.

=C2=A0

Just one question: how are the RSA exponent and modu= lus length-prefixed?=C2=A0 Are they uint16-length-prefixed?

=C2=A0

Bill


--001a11475b225434270533c5522b-- From nobody Fri May 27 12:39:00 2016 Return-Path: X-Original-To: unbearable@ietf.org Delivered-To: unbearable@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BA612D87C; Fri, 27 May 2016 12:38:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160527193858.11078.99745.idtracker@ietfa.amsl.com> Date: Fri, 27 May 2016 12:38:58 -0700 Archived-At: Cc: leifj@matematik.su.se, unbearable@ietf.org, tokbind-chairs@ietf.org, stephen.farrell@cs.tcd.ie Subject: [Unbearable] tokbind - New Meeting Session Request for IETF 96 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 27 May 2016 19:38:58 -0000 A new meeting session request has just been submitted by Leif Johansson, a Chair of the tokbind working group. --------------------------------------------------------- Working Group Name: Token Binding Area Name: Security Area Session Requester: Leif Johansson Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 75 Conflicts to Avoid: First Priority: httpbis oauth jose Special Requests: Avoid entire SEC area --------------------------------------------------------- From nobody Sat May 28 02:42:37 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416BB12D1C0 for ; Sat, 28 May 2016 02:42:35 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UI--H9wkgeWT for ; Sat, 28 May 2016 02:42:33 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73CB12D111 for ; Sat, 28 May 2016 02:42:32 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id w16so42610091lfd.2 for ; Sat, 28 May 2016 02:42:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=eyBO9AnB0JmQHBRC2/2PAWTDCELzlc7+Evx2sxyx+z0=; b=vmsDwuC2X1EqHeTto1wXcBrHUFxkW5bOaLCWok+7y00BZ0N9ygbw1kRucH6pJWK8xx ksm7PcrBXCrSp9AR6bEWF2uy1csQzAJvQ0SBMNcI0ZZhSD9pxk87num3TariR/fpDHBM jx1UH/s8astd9Oy3NKRqDQaZrIF2kjUopotWKO++iphIWwTvQ6H3BY1zpCZsnStC4RwB mL2p0bthDWbo2iaSi9oWxeT+ddoOchG4cA5VE4yTg/xYIItlTGwhGQkO570u5rx8NDiG WzjRl9jZJQtkiTeC3mNK7ecckbdtBbc1ZbHVf7atHlU0436ZBvWgXFOwpMtFj9JOPfJl CaeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=eyBO9AnB0JmQHBRC2/2PAWTDCELzlc7+Evx2sxyx+z0=; b=Dpbs5oosg7mmcbW1WhFvzbMn66Q67hPDt2UHqEDMSQA7SC4cFqnb1TgYELuIY/PQSO oGDwHuUGTWM7aVSp23ROfzBGikLLJ6ogbXdWbljgwVVR0ivbuUSQD5TA+cohnFU3iVAh vWGTEopahvFHgQYIAtOpAoImzW93/Ps+DEpkDfUGK6KsnRjsuWmUpfL74vcONVUkn6mv Q87t1v78NOKPvlsMvyyarChLzrzKM8A/Llr/bIXOSGqlt5Z76KN2yZIztdaoMidXbXVm 9Qq8li7CrmjVyBlryh+bwwBD8+pZAwZI9CeWuapGLuyQyDHhRXSDsm18mi905hgC4QEd Cf/Q== X-Gm-Message-State: ALyK8tKua2BSsQ8BwpuuaVf0cFTy20esoZ0topv0I96JJ7LgKkFt1rdoiU3CluLNQIVC1w== X-Received: by 10.25.216.223 with SMTP id r92mr5912927lfi.122.1464428550639; Sat, 28 May 2016 02:42:30 -0700 (PDT) Received: from [10.0.0.107] (tb62-102-145-131.cust.teknikbyran.com. [62.102.145.131]) by smtp.googlemail.com with ESMTPSA id s19sm2660638lfd.23.2016.05.28.02.42.29 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 28 May 2016 02:42:29 -0700 (PDT) To: unbearable@ietf.org References: <20160527193858.11078.99745.idtracker@ietfa.amsl.com> From: Leif Johansson Message-ID: <57496804.1050908@mnt.se> Date: Sat, 28 May 2016 11:42:28 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <20160527193858.11078.99745.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Unbearable] tokbind - New Meeting Session Request for IETF 96 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 28 May 2016 09:42:35 -0000 On 2016-05-27 21:38, "IETF Meeting Session Request Tool" wrote: > > > A new meeting session request has just been submitted by Leif Johansson, a Chair of the tokbind working group. > > Folks, Its agenda creation time for Berlin! Cheers Leif > --------------------------------------------------------- > Working Group Name: Token Binding > Area Name: Security Area > Session Requester: Leif Johansson > > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 75 > Conflicts to Avoid: > First Priority: httpbis oauth jose > > > > > Special Requests: > Avoid entire SEC area > --------------------------------------------------------- > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > From nobody Tue May 31 09:32:59 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B28B312D81C for ; Tue, 31 May 2016 09:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWqCwCSv1SOO for ; Tue, 31 May 2016 09:32:55 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0133.outbound.protection.outlook.com [207.46.100.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 D5ACF12D81F for ; Tue, 31 May 2016 09:32:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XEeTcGi3N/nVrHHVN73qTyBm8T49728RSizjt4mmQMs=; b=fCWNBcxFPR4oJIeK6O4L0RmELlk5px40ocD61iivFFGPND86dsp3lovnHgt/bpNqQhXw+ix7dk1bAMAi0QYoL5Wg1vhfF5ET5r5QrrVoeLyqJn0DVue30Wzp4u6U6QJL/Ao/A/fdTpWtEJ0drVNclv+cRAtW2O+Dd+yFqhba88Y= Received: from BN3PR03MB1445.namprd03.prod.outlook.com (10.163.34.28) by BN3PR03MB1446.namprd03.prod.outlook.com (10.163.34.29) with Microsoft SMTP Server (TLS) id 15.1.501.7; Tue, 31 May 2016 16:32:52 +0000 Received: from BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) by BN3PR03MB1445.namprd03.prod.outlook.com ([10.163.34.28]) with mapi id 15.01.0501.017; Tue, 31 May 2016 16:32:52 +0000 From: Andrei Popov To: Brian Campbell Thread-Topic: [Unbearable] ecdsap256 questions Thread-Index: AQHRsHNO0gHpa/iOlEmlbmpufE8V3p/CNOMwgATokQCAAAN+AIAAA/DwgAAMnoCAABF3AIAAAofQgASBkACAB4tjkA== Date: Tue, 31 May 2016 16:32:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: pingidentity.com; dkim=none (message not signed) header.d=none;pingidentity.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [50.46.229.189] x-ms-office365-filtering-correlation-id: 3035e927-2f32-48a0-125d-08d38971360b x-microsoft-exchange-diagnostics: 1; BN3PR03MB1446; 5:TfQ2BZQBOgTeoIPpKrENEB16HVqaO/CuKDwQGSVXd+xxIFeV32ywlAkshYOjQJKG8MvQBChnmIE3lpkBND1aqRUHykxdbFJW37VI+cRR+cteBdYCiypj/PO75ZgIDcJUAqEYnxvmRMF9erkIxyfJUQ==; 24:mGvbvuqH4M/5vzNt+TVGh/uKMB97NpV0AD9CZIf+bXIPjrJGUXMQdHHjHAbeyFPG3Y/51huvOUXtwAd1I1q1fLgvNoMolcLlZ0ARUMqnlfw=; 7:x4SEKPzRg1PTEaVuMPCPtgmseuwv5HFHJoVaji9vV/k4GhUpMaTZsZxJBFP3acIi1JexGyDW6gafG/Nr3Qg5saBP3G9fS0F6XTpsmXu+5DW2Pd6RFA3ZMkgR6gFo2fnQoa3IHSADEk5iQIM57JBmKYTi/BSSKVRTiTN/2ZUMhQ+ejwTb48Rhb+NK5UunXN5Mw2A6YyJTFiyp3bbx+UQ/yw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR03MB1446; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN3PR03MB1446; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB1446; x-forefront-prvs: 095972DF2F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(9326002)(19580395003)(54356999)(19580405001)(76176999)(8990500004)(50986999)(11100500001)(10090500001)(9686002)(93886004)(2900100001)(87936001)(110136002)(2950100001)(16236675004)(189998001)(2906002)(8676002)(5004730100002)(8936002)(81166006)(33656002)(19609705001)(122556002)(10290500002)(99286002)(10400500002)(5005710100001)(4326007)(19625215002)(66066001)(3660700001)(3280700002)(74316001)(19300405004)(5003600100002)(3846002)(5008740100001)(790700001)(76576001)(102836003)(77096005)(6116002)(586003)(15975445007)(5002640100001)(86362001)(106116001)(92566002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB1446; H:BN3PR03MB1445.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB14457D001A89B82CB9F4CCF48C460BN3PR03MB1445namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 May 2016 16:32:51.9595 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB1446 Archived-At: Cc: IETF Tokbind WG , Martin Thomson , Nick Harper , Bill Cox Subject: Re: [Unbearable] ecdsap256 questions X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 31 May 2016 16:32:57 -0000 --_000_BN3PR03MB14457D001A89B82CB9F4CCF48C460BN3PR03MB1445namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNCkZvciBtZSBwZXJzb25hbGx5LCBsb29raW5nIGF0IEJMT0JzIGRvZXNuJ3Qg aGVscCBtdWNoLiBJdCBpcyB0cnVlIHRoYXQgdGhlIHNwZWMgcmVsaWVzIG9uIHRoZSByZWFkZXIg dW5kZXJzdGFuZGluZyB0aGUgIlRMUyBwcmVzZW50YXRpb24gbGFuZ3VhZ2UiLiBIb3dldmVyLCBJ IGRvbid0IGZlZWwgc3Ryb25nbHkgYWJvdXQgdGhpczsgaWYgdGhlcmUgaXMgV0cgc3VwcG9ydCBm b3IgYWRkaW5nIHNhbXBsZSBtZXNzYWdlIEJMT0JzIHRvIHRoZSBzcGVjLCBJIGNhbiBkbyBpdCBv bmNlIG91ciBpbXBsZW1lbnRhdGlvbiBpcyB1cCB0byBkYXRlIHdpdGggdGhlIHNwZWMuDQoNCkNo ZWVycywNCg0KQW5kcmVpDQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb21dDQpTZW50OiBUaHVyc2RheSwgTWF5IDI2LCAyMDE2IDI6MTcgUE0N ClRvOiBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPg0KQ2M6IEJpbGwg Q294IDx3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPjsgTmljayBIYXJwZXIgPG5oYXJwZXJAZ29vZ2xl LmNvbT47IElFVEYgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz47IE1hcnRpbiBUaG9t c29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVd IGVjZHNhcDI1NiBxdWVzdGlvbnMNCg0KTWlnaHQgdGhlcmUgYmUgc29tZSB2YWx1ZSBpbiBwcm92 aWRpbmcgc29tZSBleGFtcGxlcyBpbiAtdG9rYmluZC1wcm90b2NvbCBhbmQvb3IgLXRva2JpbmQt aHR0cHMgdGhhdCBjb3VsZCBoZWxwIHNlcnZlIHRvIHZhbGlkYXRlIHJlYWRlcidzIGludGVycHJl dGF0aW9uIG9mIHRoZSB0ZXh0Pw0KDQpBcyBhbiBpbXBsZW1lbnRlciBvZiBKV1MgJiBKV0UsIGZv ciBpbnN0YW5jZSwgSSBmb3VuZCB0aGUgZXhhbXBsZXMgaW4gdGhlIGRvY3VtZW50cyB0byBiZSBl eGNlcHRpb25hbGx5IHZhbHVhYmxlIGluIGFpZGluZyBteSB1bmRlcnN0YW5kaW5nIGFuZCBoZWxw aW5nIHRvIHZldCB0aGUgaW1wbGVtZW50YXRpb24uIEkgdGhpbmsgc29tZSBleGFtcGxlIFRva2Vu QmluZGluZ01lc3NhZ2VzIGluIHRoZSBUQiBkb2MocykgY291bGQgYmUgc2ltaWxhcmx5IHZhbHVh YmxlLg0KDQoNCk9uIE1vbiwgTWF5IDIzLCAyMDE2IGF0IDY6MzAgUE0sIEFuZHJlaSBQb3BvdiA8 QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQu Y29tPj4gd3JvdGU6DQpzdHJ1Y3Qgew0KICAgIG9wYXF1ZSBtb2R1bHVzPDEuLjJeMTYtMT47DQog ICAgb3BhcXVlIHB1YmxpY2V4cG9uZW50PDEuLjJeOC0xPjsNCn0gUlNBUHVibGljS2V5Ow0KDQpJ biDigJxUTFMgUHJlc2VudGF0aW9uIExhbmd1YWdl4oCdLCB0aGlzIG1lYW5zIDIgYnl0ZXMgb2Yg bGVuZ3RoIHByZWZpeCBmb3IgbW9kdWx1cyBhbmQgMSBieXRlIG9mIGxlbmd0aCBwcmVmaXggZm9y IGV4cG9uZW50Lg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBCaWxsIENveCBbbWFpbHRv OndheXdhcmRnZWVrQGdvb2dsZS5jb208bWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb20+XQ0K U2VudDogTW9uZGF5LCBNYXkgMjMsIDIwMTYgNToxOSBQTQ0KVG86IE5pY2sgSGFycGVyIDxuaGFy cGVyQGdvb2dsZS5jb208bWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbT4+DQpDYzogQW5kcmVpIFBv cG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jv c29mdC5jb20+PjsgSUVURiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzp1 bmJlYXJhYmxlQGlldGYub3JnPj47IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PjsgTWFydGluIFRob21z b24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwu Y29tPj4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gZWNkc2FwMjU2IHF1ZXN0aW9ucw0KDQpP biBNb24sIE1heSAyMywgMjAxNiBhdCA0OjE2IFBNLCBOaWNrIEhhcnBlciA8bmhhcnBlckBnb29n bGUuY29tPG1haWx0bzpuaGFycGVyQGdvb2dsZS5jb20+PiB3cm90ZToNCkkgYWdyZWUgd2l0aCB5 b3UgYW5kIE1hcnRpbiB0aGF0IHdlIGRvbid0IG5lZWQgbW9yZSBBU04uMSArIERFUiwgYW5kIHRo ZSBmb3JtYXQgaW4gZHJhZnQgMDYgbWFrZXMgc2Vuc2UgZm9yIHNvbWV0aGluZyBtb2Rlcm4uDQoN Ckp1c3Qgb25lIHF1ZXN0aW9uOiBob3cgYXJlIHRoZSBSU0EgZXhwb25lbnQgYW5kIG1vZHVsdXMg bGVuZ3RoLXByZWZpeGVkPyAgQXJlIHRoZXkgdWludDE2LWxlbmd0aC1wcmVmaXhlZD8NCg0KQmls bA0KDQo= --_000_BN3PR03MB14457D001A89B82CB9F4CCF48C460BN3PR03MB1445namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgQnJpYW4sPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Gb3IgbWUgcGVyc29uYWxseSwgbG9va2luZyBh dCBCTE9CcyBkb2Vzbid0IGhlbHAgbXVjaC4gSXQgaXMgdHJ1ZSB0aGF0IHRoZSBzcGVjIHJlbGll cyBvbiB0aGUgcmVhZGVyIHVuZGVyc3RhbmRpbmcgdGhlICZxdW90O1RMUyBwcmVzZW50YXRpb24g bGFuZ3VhZ2UmcXVvdDsuIEhvd2V2ZXIsIEkNCiBkb24ndCBmZWVsIHN0cm9uZ2x5IGFib3V0IHRo aXM7IGlmIHRoZXJlIGlzIFdHIHN1cHBvcnQgZm9yIGFkZGluZyBzYW1wbGUgbWVzc2FnZSBCTE9C cyB0byB0aGUgc3BlYywgSSBjYW4gZG8gaXQgb25jZSBvdXIgaW1wbGVtZW50YXRpb24gaXMgdXAg dG8gZGF0ZSB3aXRoIHRoZSBzcGVjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFp bEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9w Pg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1heSAyNiwgMjAxNiAyOjE3 IFBNPGJyPg0KPGI+VG86PC9iPiBBbmRyZWkgUG9wb3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3Nv ZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQmlsbCBDb3ggJmx0O3dheXdhcmRnZWVrQGdvb2ds ZS5jb20mZ3Q7OyBOaWNrIEhhcnBlciAmbHQ7bmhhcnBlckBnb29nbGUuY29tJmd0OzsgSUVURiBU b2tiaW5kIFdHICZsdDt1bmJlYXJhYmxlQGlldGYub3JnJmd0OzsgTWFydGluIFRob21zb24gJmx0 O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtV bmJlYXJhYmxlXSBlY2RzYXAyNTYgcXVlc3Rpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+TWlnaHQgdGhlcmUgYmUgc29tZSB2YWx1ZSBpbiBwcm92aWRpbmcgc29tZSBl eGFtcGxlcyBpbiAtdG9rYmluZC1wcm90b2NvbCBhbmQvb3IgLXRva2JpbmQtaHR0cHMgdGhhdCBj b3VsZCBoZWxwIHNlcnZlIHRvIHZhbGlkYXRlIHJlYWRlcidzIGludGVycHJldGF0aW9uIG9mIHRo ZSB0ZXh0Pzxicj4NCjxicj4NCkFzIGFuIGltcGxlbWVudGVyIG9mIEpXUyAmYW1wOyBKV0UsIGZv ciBpbnN0YW5jZSwgSSBmb3VuZCB0aGUgZXhhbXBsZXMgaW4gdGhlIGRvY3VtZW50cyB0byBiZSBl eGNlcHRpb25hbGx5IHZhbHVhYmxlIGluIGFpZGluZyBteSB1bmRlcnN0YW5kaW5nIGFuZCBoZWxw aW5nIHRvIHZldCB0aGUgaW1wbGVtZW50YXRpb24uIEkgdGhpbmsgc29tZSBleGFtcGxlIFRva2Vu QmluZGluZ01lc3NhZ2VzIGluIHRoZSBUQiBkb2MocykgY291bGQgYmUgc2ltaWxhcmx5DQogdmFs dWFibGUuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIE1vbiwgTWF5IDIzLCAyMDE2IGF0IDY6MzAgUE0sIEFuZHJlaSBQb3Bv diAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9 Il9ibGFuayI+QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPnN0cnVjdCB7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9wYXF1ZSBtb2R1bHVzJmx0OzEuLjJeMTYtMSZndDs7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9wYXF1ZSBwdWJsaWNleHBv bmVudCZsdDsxLi4yXjgtMSZndDs7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+fSBSU0FQdWJsaWNLZXk7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SW4g4oCcVExT IFByZXNlbnRhdGlvbiBMYW5ndWFnZeKAnSwgdGhpcyBtZWFucyAyIGJ5dGVzIG9mIGxlbmd0aCBw cmVmaXggZm9yIG1vZHVsdXMgYW5kIDEgYnl0ZSBvZiBsZW5ndGgNCiBwcmVmaXggZm9yIGV4cG9u ZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZWVy cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BbmRyZWk8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IEJpbGwgQ294IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOndheXdhcmRnZWVr QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj53YXl3YXJkZ2Vla0Bnb29nbGUuY29tPC9hPl0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAyMywgMjAxNiA1OjE5IFBNPGJyPg0KPGI+ VG86PC9iPiBOaWNrIEhhcnBlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm5oYXJwZXJAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBBbmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9z b2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZn dDs7IElFVEYgVG9rYmluZCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj51bmJlYXJhYmxlQGlldGYub3JnPC9hPiZndDs7IEJyaWFuIENh bXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRh cmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7Ow0KIE1hcnRp biBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+bWFydGluLnRob21zb25AZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBlY2RzYXAyNTYgcXVlc3Rpb25zPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gTW9uLCBN YXkgMjMsIDIwMTYgYXQgNDoxNiBQTSwgTmljayBIYXJwZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpu aGFycGVyQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5uaGFycGVyQGdvb2dsZS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5JIGFncmVlIHdpdGggeW91IGFuZCBNYXJ0aW4gdGhhdCB3ZSBkb24ndCBuZWVkIG1v cmUgQVNOLjEgJiM0MzsgREVSLCBhbmQgdGhlIGZvcm1hdCBpbiBkcmFmdCAwNiBtYWtlcyBzZW5z ZSBmb3Igc29tZXRoaW5nIG1vZGVybi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkp1c3Qgb25lIHF1ZXN0aW9u OiBob3cgYXJlIHRoZSBSU0EgZXhwb25lbnQgYW5kIG1vZHVsdXMgbGVuZ3RoLXByZWZpeGVkPyZu YnNwOyBBcmUgdGhleSB1aW50MTYtbGVuZ3RoLXByZWZpeGVkPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmlsbDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN3PR03MB14457D001A89B82CB9F4CCF48C460BN3PR03MB1445namp_-- From nobody Tue May 31 11:23:32 2016 Return-Path: X-Original-To: unbearable@ietfa.amsl.com Delivered-To: unbearable@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481A212D8A6 for ; Tue, 31 May 2016 11:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttUUkqC2WnQU for ; Tue, 31 May 2016 11:23:29 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0555212D89F for ; Tue, 31 May 2016 11:23:28 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id f8so142005440ioe.3 for ; Tue, 31 May 2016 11:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5de7dgejbxUySB67DqUscAj2NJ9DD2kp6YltvtpOnes=; b=cvsQ8/2gu1QnGuUUNSLDbmiYraxu01oCCrYa4onUk6ZW85BmHhyUcPeNGzYXb54zWv oC0lmmEQ66f/dj181uDYlc59scsTy9aP42laG+P5ghZW9JxWUL4HcRogaUA8YXPzi8no 8w2VXuIGHCtP/G/Bj1BEgk1ah9BlTk0jqXJMs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5de7dgejbxUySB67DqUscAj2NJ9DD2kp6YltvtpOnes=; b=B+b8VVUn+o3gLP9VpaazBie7QyYqDnS9Mg9gHrgUiofpkQFCMz1ynzWGQz9fMXIXjq bwBwhAtzwCXzgXK//YjJQ1qY+hClO0lkZRSAwUdeCZnr0y4gqNyJWsu4D/onNyHGDemZ URUrUzhKc319Ps4j9QD2+aHI1pOhaVus3ab2j7SAm0+hqq2uRnZQizwZgYEjhvQmVLbL AinwvKPZ4PrdKeK/K7RC5TTeyptP4clcWIKBoJwbZjxyLasPsRqxfslKmcLaI22Rznqc dzLFhJTjtMFOnLGqmZmSnq5Eib1DfXOIZuU/9fxmvRuIPdWKYWao8rbddNVl5bevgqLY QpbQ== X-Gm-Message-State: ALyK8tIOuSmefjyRgJBAgCTsiW5kc55zsvidN2FOwDlQ5bnmJ/oEoVNTKZo7/X1ctjDRoSfUiNNQhi9Vnuo757Ry X-Received: by 10.107.28.14 with SMTP id c14mr27721398ioc.86.1464719008256; Tue, 31 May 2016 11:23:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.105.129 with HTTP; Tue, 31 May 2016 11:22:58 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Tue, 31 May 2016 12:22:58 -0600 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a1140aa782ef16a053427785b Archived-At: Cc: IETF Tokbind WG , Martin Thomson , Nick Harper , Bill Cox Subject: Re: [Unbearable] ecdsap256 questions X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 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, 31 May 2016 18:23:31 -0000 --001a1140aa782ef16a053427785b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agree that just looking at BLOBs doesn't help much or at all. The value, I think, is providing an early sanity check for implementations. Or parts of implementations anyway. Several of the key parameter type's signatures aren't deterministic so one can't just reproduce examples for those. But if one can verify the examples and produce results that can also be verified, it's a pretty good sign things are in good shape. The EKM value needs to be provided with the example too for such implementation checks to be possible. Such examples can help drive out interoperability problems earlier on before implementations actually interoperate. On Tue, May 31, 2016 at 10:32 AM, Andrei Popov wrote: > Hi Brian, > > > > For me personally, looking at BLOBs doesn't help much. It is true that th= e > spec relies on the reader understanding the "TLS presentation language". > However, I don't feel strongly about this; if there is WG support for > adding sample message BLOBs to the spec, I can do it once our > implementation is up to date with the spec. > > > > Cheers, > > > > Andrei > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Thursday, May 26, 2016 2:17 PM > *To:* Andrei Popov > *Cc:* Bill Cox ; Nick Harper = ; > IETF Tokbind WG ; Martin Thomson < > martin.thomson@gmail.com> > *Subject:* Re: [Unbearable] ecdsap256 questions > > > > Might there be some value in providing some examples in -tokbind-protocol > and/or -tokbind-https that could help serve to validate reader's > interpretation of the text? > > As an implementer of JWS & JWE, for instance, I found the examples in the > documents to be exceptionally valuable in aiding my understanding and > helping to vet the implementation. I think some example > TokenBindingMessages in the TB doc(s) could be similarly valuable. > > > > > > On Mon, May 23, 2016 at 6:30 PM, Andrei Popov > wrote: > > struct { > > opaque modulus<1..2^16-1>; > > opaque publicexponent<1..2^8-1>; > > } RSAPublicKey; > > > > In =E2=80=9CTLS Presentation Language=E2=80=9D, this means 2 bytes of len= gth prefix for > modulus and 1 byte of length prefix for exponent. > > > > Cheers, > > > > Andrei > > > > *From:* Bill Cox [mailto:waywardgeek@google.com] > *Sent:* Monday, May 23, 2016 5:19 PM > *To:* Nick Harper > *Cc:* Andrei Popov ; IETF Tokbind WG < > unbearable@ietf.org>; Brian Campbell ; Martin > Thomson > *Subject:* Re: [Unbearable] ecdsap256 questions > > > > On Mon, May 23, 2016 at 4:16 PM, Nick Harper wrote: > > I agree with you and Martin that we don't need more ASN.1 + DER, and the > format in draft 06 makes sense for something modern. > > > > Just one question: how are the RSA exponent and modulus length-prefixed? > Are they uint16-length-prefixed? > > > > Bill > > > --001a1140aa782ef16a053427785b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agree that just looking at BLOBs doesn't help much or = at all. The value, I think, is providing an early sanity check for implemen= tations. Or parts of implementations anyway. Several of the key parameter t= ype's signatures aren't deterministic so one can't just reprodu= ce examples for those. But if one can verify the examples and produce resul= ts that can also be verified, it's a pretty good sign things are in goo= d shape. The EKM value needs to be provided with the example too for such i= mplementation checks to be possible. Such examples can help drive out inter= operability problems earlier on before implementations actually interoperat= e. =C2=A0 =C2=A0

=C2=A0

On Tue, May 31, 2016 at 10:32 AM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

Hi Brian,

=C2=A0

For me personally, looking at BLOBs d= oesn't help much. It is true that the spec relies on the reader underst= anding the "TLS presentation language". However, I don't feel strongly about this; if there is WG support for adding samp= le message BLOBs to the spec, I can do it once our implementation is up to = date with the spec.

<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif;c= olor:#1f497d">=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingiden= tity.com]
Sent: Thursday, May 26, 2016 2:17 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Bill Cox <waywardgeek@google.com>; Nick Harper <nharper@google.com>; IETF Tokb= ind WG <unbeara= ble@ietf.org>; Martin Thomson <martin.thomson@gmail.com>
Subject: Re: [Unbearable] ecdsap256 questions

=C2=A0

Might there be some value in providing some examples= in -tokbind-protocol and/or -tokbind-https that could help serve to valida= te reader's interpretation of the text?

As an implementer of JWS & JWE, for instance, I found the examples in t= he documents to be exceptionally valuable in aiding my understanding and he= lping to vet the implementation. I think some example TokenBindingMessages = in the TB doc(s) could be similarly valuable.

=C2=A0

=C2=A0

On Mon, May 23, 2016 at 6:30 PM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

struct {

=C2=A0=C2=A0=C2=A0 opaque modulus<= 1..2^16-1>;

=C2=A0=C2=A0=C2=A0 opaque publicexpon= ent<1..2^8-1>;

} RSAPublicKey;<= /p>

=C2=A0

In =E2=80=9CTLS Presentation Language= =E2=80=9D, this means 2 bytes of length prefix for modulus and 1 byte of le= ngth prefix for exponent.

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Bill Cox [mailto:waywardgeek@google.com]
Sent: Monday, May 23, 2016 5:19 PM
To: Nick Harper <nharper@google.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; IETF Tokbind WG <unbearable@ietf.org<= /a>>; Brian Campbell <bcampbell@pingidentity.com>; Martin Thomson <martin.thomson@gmail.com>
Subject: Re: [Unbearable] ecdsap256 questions

=C2=A0

On Mon, May 23, 2016 at 4:16 PM, Nick Harper <nharper@google.com= > wrote:

I agree with you and Martin that we don't need m= ore ASN.1 + DER, and the format in draft 06 makes sense for something moder= n.

=C2=A0

Just one question: how are the RSA exponent and modu= lus length-prefixed?=C2=A0 Are they uint16-length-prefixed?

=C2=A0

Bill

=C2=A0


--001a1140aa782ef16a053427785b--