From nobody Mon Aug 1 08:54: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 C5AE012B044 for ; Mon, 1 Aug 2016 08:54: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=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 LPS40ws3X4ri for ; Mon, 1 Aug 2016 08:54:26 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 74EA612DA10 for ; Mon, 1 Aug 2016 08:54:26 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id f6so249214530ith.1 for ; Mon, 01 Aug 2016 08:54:26 -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=Zbo/0zhVwuNWFLa22aVZokDe6W8ZpUfVN50aoxMqK+I=; b=nFMTPfrfpIjsdEmIgu+EBiK5q8d6iH1XsIEDPrkM4r6VGfBMaNkXIMkWon1hSKXYrM 1VHfY3e/MdOzaPwlWY6QK2ztOMs3e2qGMwY06Pzlx62tg1SI0pNoVDSUg8ZRa4rTRRFZ ZuDbtOoJncHob/FSbIrXfwY2zisPtYlfpLkDM= 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=Zbo/0zhVwuNWFLa22aVZokDe6W8ZpUfVN50aoxMqK+I=; b=Hyp/ZQ1bhEytQrNnzzUQ5/UGyCLIdWtpU68HzvkB0ZZe69CNUyZInTIUP8sgadtwcs 6oZBQ0xIhDIqC72rl2eK0eoArNk4l8RYMgu/HtvRgV0qd1fE6evBiPcAiEdfWaYt9YGn tvhtFk153ubty1zg/vvW0LeXkssp34frhE15ObzggQSydC3BI8pnNIItlu3OV3l/d4b5 loQCJtksbf47XhjS1LNydRKJQNWxcn+ryg3zNMLIblxLELJxrJe+/ATnhYdCElavSyrH VUi3KjgARPHtYIFrDLInLj2A7M0BDJTyprTn5wjP2yT7G1bJ2T08y5qeB/JgfY+zPhz9 VYEg== X-Gm-Message-State: AEkoouuzVFLQ64hqvTXLFfnJZoaiJAhXZUtNu+9crjg738T7pgi+6xh0M9gNBeOZKD+SortRqZzbT1+cOQepbAbU X-Received: by 10.36.33.197 with SMTP id e188mr14744574ita.42.1470066862530; Mon, 01 Aug 2016 08:54:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Mon, 1 Aug 2016 08:53:51 -0700 (PDT) In-Reply-To: <56260ABF-1B8A-41CB-BA16-0ACFFDE80097@me.com> References: <56260ABF-1B8A-41CB-BA16-0ACFFDE80097@me.com> From: Brian Campbell Date: Mon, 1 Aug 2016 09:53:51 -0600 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a1146ec4e2364ce0539049da9 Archived-At: Cc: IETF Tokbind WG , Dirk Balfanz , Andrei Popov , =JeffH Hodges Subject: Re: [Unbearable] Base64url encoding in draft-ietf-tokbind-https 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, 01 Aug 2016 15:54:28 -0000 --001a1146ec4e2364ce0539049da9 Content-Type: text/plain; charset=UTF-8 Most base64 decoders, I think, will happily handle both padded and unpadded input. So it probably doesn't matter all that much. But for consistency and marginal space savings, I'd be in favor of having HTTPSTB say to omit the padding. There's some language in a comment on https://github.com/TokenBinding/Internet-Drafts/issues/27 to that effect, which could be borrowed from, if desired. Most base64 encoders/decoders (nowadays?) also handle both the standard and the URL/filename safe alphabet. I don't really think there's value in an appendix like the one in RFC 7515. On Fri, Jul 29, 2016 at 4:30 PM, John Bradley wrote: > Brian Campbell has pointed out to me that in testing Chrome 54.0.2811.0 > it is sending Sec-Token-Binding headers with padding. > > In https://tools.ietf.org/html/draft-ietf-tokbind-https-05#section-2 we > say > > The header field name is "Sec-Token-Binding", and > EncodedTokenBindingMessage is a base64url encoding (see [RFC4648] > Section 5 ) of the TokenBindingMessage as defined in > [I-D.ietf-tokbind-protocol ] > > > When we did JOSE we found RFC4648 > a touch to vague on > padding. in principal encoders and decoders will work both ways. > However for interoperability and space saving we required the producer to > send non padded to avoid confusion. > > We also added a appendix to help people with base64url without padding. > https://tools.ietf.org/html/rfc7515#appendix-C > > Can the authors look at clarifying this, as written sending with or > without padding is allowed by my reading. > > Including the appendix would also be fine with me if people think it would > help clarify things for developers. > > Thanks. > > John B. > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a1146ec4e2364ce0539049da9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Most base64 decoders, I think, will happily handle both pa= dded and unpadded input.=C2=A0 So it probably doesn't matter all that m= uch. But for consistency and marginal space savings, I'd be in favor of= having HTTPSTB say to omit the padding. There's some language in a com= ment on https://github.com/TokenBinding/Internet-Drafts/issues/27 to that ef= fect, which could be borrowed from, if desired.

Most base64 encoder= s/decoders (nowadays?) also handle both the standard and the URL/filename s= afe alphabet. I don't really think there's value in an appendix lik= e the one in RFC 7515.

On Fri, Jul 29, 2016 at 4:30 PM, John Bradley <jbradley@me.= com> wrote:
Brian Campbell has pointed out to me that in testing C= hrome=C2=A054.0= .2811.0 it is sending Sec-Token-Binding headers with padding.

= 
 The header field na=
me is "Sec-Token-Binding", and
   EncodedTokenBindingMessage is a base64url encoding (see [RFC4648]
   Section=C2=A05) of the TokenBindingMessage as defined in
   [I-D.ietf-tokbind-protocol]=

When we did JOSE we found=C2=A0RFC4648=C2=A0a touch to vague on padding. =C2=A0in p= rincipal encoders and decoders will work both ways.
However for i= nteroperability and space saving we required the producer to send non padde= d to avoid confusion.

We also added a appendix to = help people with base64url without padding.

Can the authors = =C2=A0look at clarifying this, =C2=A0as written sending with or without pad= ding is allowed by my reading.

Including the appen= dix would also be fine with me if people think it would help clarify things= for developers.

Thanks.

= John B.

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


--001a1146ec4e2364ce0539049da9-- From nobody Mon Aug 1 09:13:48 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 88AD412D147 for ; Mon, 1 Aug 2016 09:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.007 X-Spam-Level: X-Spam-Status: No, score=-4.007 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=me.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 iN5vJRSaBGzW for ; Mon, 1 Aug 2016 09:13:44 -0700 (PDT) Received: from pv35p16im-ztdg05081101.me.com (pv35p16im-ztdg05081101.me.com [17.133.187.172]) (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 8717E12D0F9 for ; Mon, 1 Aug 2016 09:13:43 -0700 (PDT) Received: from process-dkim-sign-daemon.pv35p16im-ztdg05081101.me.com by pv35p16im-ztdg05081101.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OB800C00NP5XK00@pv35p16im-ztdg05081101.me.com> for unbearable@ietf.org; Mon, 01 Aug 2016 16:13:43 +0000 (GMT) Received: from [192.168.1.47] (191-115-97-190.baf.movistar.cl [191.115.97.190]) by pv35p16im-ztdg05081101.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OB800JJDNQKLZ10@pv35p16im-ztdg05081101.me.com>; Mon, 01 Aug 2016 16:13:42 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-08-01_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1608010170 Content-type: multipart/alternative; boundary="Apple-Mail=_5CE9043F-EE5A-405E-ABF8-57C4DB6A608B" MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-reply-to: Date: Mon, 01 Aug 2016 12:13:31 -0400 Message-id: <6FAE8287-E6E7-4E21-BFC9-60B948ABDB2D@me.com> References: <56260ABF-1B8A-41CB-BA16-0ACFFDE80097@me.com> To: Brian Campbell X-Mailer: Apple Mail (2.3124) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=4d515a; t=1470068023; bh=YuVe6lh863GgxLWBbBbDvKz4qYzWwoJLeVz4cqTt3Hs=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=oWYf6kGcM0nLeQIiQn6TkBBdHZAio9MqgBl2f/j5+Tz0azAO4Lg/o+aghdCJh0j9I cMdjOk7ibiIh9P2O2XM3kYL96a0cZxidrtE0R7vFhNLVty7nTmfLRoskJNsUFDp/7r HevLw4NxhjcN7g7Qtcvg/oFC0jtFQlnBPD7zndux3wHXjsKK4bGCJHG3cUEFsk/AxC DU+rXrnfdmn/OSPJf48SH3k/85clWk+dIIZv98on12LXbgkciPflFnLb506HeWTqH3 QsfrSH0ad4KVdgOJkYPD/atX6PFS8SR3QIQOpWHoDXK3Y7NYGnMZaUC8ms5DKSzAsY JJkIUNV1o+Cfg== Archived-At: Cc: IETF Tokbind WG , Dirk Balfanz , Andrei Popov , =JeffH Hodges Subject: Re: [Unbearable] Base64url encoding in draft-ietf-tokbind-https 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, 01 Aug 2016 16:13:46 -0000 --Apple-Mail=_5CE9043F-EE5A-405E-ABF8-57C4DB6A608B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Decoders will likely do the correct thing. However having one correct = way to produce encoded token binding message will reduce confusion I = suspect, it makes examples less ambiguous. John B. > On Aug 1, 2016, at 11:53 AM, Brian Campbell = wrote: >=20 > Most base64 decoders, I think, will happily handle both padded and = unpadded input. So it probably doesn't matter all that much. But for = consistency and marginal space savings, I'd be in favor of having = HTTPSTB say to omit the padding. There's some language in a comment on = https://github.com/TokenBinding/Internet-Drafts/issues/27 = to that = effect, which could be borrowed from, if desired.=20 >=20 > Most base64 encoders/decoders (nowadays?) also handle both the = standard and the URL/filename safe alphabet. I don't really think = there's value in an appendix like the one in RFC 7515.=20 >=20 > On Fri, Jul 29, 2016 at 4:30 PM, John Bradley > wrote: > Brian Campbell has pointed out to me that in testing Chrome = 54.0.2811.0 it is sending Sec-Token-Binding headers with padding. >=20 > In https://tools.ietf.org/html/draft-ietf-tokbind-https-05#section-2 = we = say > The header field name is "Sec-Token-Binding", and > EncodedTokenBindingMessage is a base64url encoding (see [RFC4648] > Section=C2=A05 ) of = the TokenBindingMessage as defined in > [I-D.ietf-tokbind-protocol = ] >=20 > When we did JOSE we found RFC4648 = a touch to vague on = padding. in principal encoders and decoders will work both ways. > However for interoperability and space saving we required the producer = to send non padded to avoid confusion. >=20 > We also added a appendix to help people with base64url without = padding. > https://tools.ietf.org/html/rfc7515#appendix-C = >=20 > Can the authors look at clarifying this, as written sending with or = without padding is allowed by my reading. >=20 > Including the appendix would also be fine with me if people think it = would help clarify things for developers. >=20 > Thanks. >=20 > John B. >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable = >=20 >=20 --Apple-Mail=_5CE9043F-EE5A-405E-ABF8-57C4DB6A608B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Decoders will likely do the correct thing.  However = having one correct way to produce encoded token binding message will = reduce confusion I suspect, it makes examples less ambiguous.

John B.
On = Aug 1, 2016, at 11:53 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Most base64 decoders, I think, will happily handle both = padded and unpadded input.  So it probably doesn't matter all that = much. But for consistency and marginal space savings, I'd be in favor of = having HTTPSTB say to omit the padding. There's some language in a = comment on https://github.com/TokenBinding/Internet-Drafts/issues/27 = to that effect, which could be borrowed from, if desired.

Most base64 encoders/decoders (nowadays?) also = handle both the standard and the URL/filename safe alphabet. I don't = really think there's value in an appendix like the one in RFC 7515.

On Fri, Jul 29, 2016 at 4:30 PM, John Bradley = <jbradley@me.com> wrote:
Brian Campbell has pointed out = to me that in testing Chrome 54.0.2811.0 it is sending Sec-Token-Binding headers with = padding.

In https://tools.ietf.org/html/draft-ietf-tokbind-https-05#section= -2 we say
 The header field name is "Sec-Token-Binding", and
   EncodedTokenBindingMessage is a base64url encoding (see [RFC4648]
   Section 5) of the TokenBindingMessage as defined in
   [I-D.ietf-tokbind-protocol]

When we did JOSE we found RFC4648 a touch to vague on padding.  in = principal encoders and decoders will work both ways.
However for interoperability and space saving we required the = producer to send non padded to avoid confusion.

We also added a appendix to help people = with base64url without padding.
https://tools.ietf.org/html/rfc7515#appendix-C

Can the authors =  look at clarifying this,  as written sending with or without = padding is allowed by my reading.

Including the appendix would also be = fine with me if people think it would help clarify things for = developers.

Thanks.

John B.

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



= --Apple-Mail=_5CE9043F-EE5A-405E-ABF8-57C4DB6A608B-- From nobody Mon Aug 1 16:07:57 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 9D6F512D801 for ; Mon, 1 Aug 2016 16:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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.287, 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 S2o8vG4XPHHq for ; Mon, 1 Aug 2016 16:07:52 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 510B212D824 for ; Mon, 1 Aug 2016 16:07:46 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id f65so387513498wmi.0 for ; Mon, 01 Aug 2016 16:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wN13796qwnRhXxIabuWkZ582P8cBEt/gat6SVi57jqw=; b=h9iBjeYLjZ6AKRO4a1gh16jUNDjGxpFTFKciRawxTU4y6t78vV1kWgrSzxCoRCA+0P rfKj/XC0BAKqxLpfCCyYzktcm/yXC8et0Hy/Bx/SN2ICHRmpcyFxUjX7feZi6OYoE/L1 Ud0E/Tv4vmKONhfCzPi74kLofGbAUkOx06Nz5JuwnIFkShg47aviGqxm7t9d+O0/imOU yd/4lIOUrX/jcZfbz1NCNlnO++ZXEhpCdw1VlJ91NedKEddtvUgy+4QuXP6n6r8EiNnH 23pKKNpre+yQVuu+WUzPERAZ4g5GyMM//4xqDXGcTKWD/aGAXXNSOI4ExacseAHa0xOF sbbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wN13796qwnRhXxIabuWkZ582P8cBEt/gat6SVi57jqw=; b=WveZYp3UXZ6C0yMz80h0AgQfh42FZ5AVMBkYL1M8Ci905zRnLuWK7p6suIg3Dw59Wx 5LNrMWBT7vT4brlQ7IpsJGLOf6vHZYjheT/uP6CNJLZau5dkX0rFGF5OlJGvMKCxsNRX JQDzZ0h+pS3rCsJIDJKu1l0TcXg2TmuNH2p/UjaVhMRYihO5Adjy7DIbwxFFY8oYLgag X1+NBLmLonYvf1guIk8YvaqhiFIvRoFOlRnVK30GA3gQf0d4VDNAjPQbkmC6QA1/MZ9G +EomQbYDYS78ezcyMhwmR9zhOwvc45sqBfAVz2oe2JhlMH8zaH0lcRH/tqCdtPOiCD7J fJHA== X-Gm-Message-State: AEkoout4A8QXanosE10sYpBWJmG6GDVK384LD6t+/0PNRKIFOKXa1bq7IjRwV83K5q+Ubf1dADZNksow85v7r1dA X-Received: by 10.194.82.67 with SMTP id g3mr53226665wjy.71.1470092864679; Mon, 01 Aug 2016 16:07:44 -0700 (PDT) MIME-Version: 1.0 References: <56260ABF-1B8A-41CB-BA16-0ACFFDE80097@me.com> <6FAE8287-E6E7-4E21-BFC9-60B948ABDB2D@me.com> In-Reply-To: <6FAE8287-E6E7-4E21-BFC9-60B948ABDB2D@me.com> From: Dirk Balfanz Date: Mon, 01 Aug 2016 23:07:32 +0000 Message-ID: To: John Bradley , Brian Campbell Content-Type: multipart/alternative; boundary=047d7b86e92efce29d05390aaa0d Archived-At: Cc: IETF Tokbind WG , Andrei Popov , =JeffH Hodges Subject: Re: [Unbearable] Base64url encoding in draft-ietf-tokbind-https 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, 01 Aug 2016 23:07:55 -0000 --047d7b86e92efce29d05390aaa0d Content-Type: text/plain; charset=UTF-8 Can you guys propose some language how to make this more precise? And add that to https://github.com/TokenBinding/Internet-Drafts/issues/56 ? Thanks, Dirk. On Mon, Aug 1, 2016 at 9:13 AM John Bradley wrote: > Decoders will likely do the correct thing. However having one correct way > to produce encoded token binding message will reduce confusion I suspect, > it makes examples less ambiguous. > > John B. > > On Aug 1, 2016, at 11:53 AM, Brian Campbell > wrote: > > Most base64 decoders, I think, will happily handle both padded and > unpadded input. So it probably doesn't matter all that much. But for > consistency and marginal space savings, I'd be in favor of having HTTPSTB > say to omit the padding. There's some language in a comment on > https://github.com/TokenBinding/Internet-Drafts/issues/27 to that effect, > which could be borrowed from, if desired. > > Most base64 encoders/decoders (nowadays?) also handle both the standard > and the URL/filename safe alphabet. I don't really think there's value in > an appendix like the one in RFC 7515. > > On Fri, Jul 29, 2016 at 4:30 PM, John Bradley wrote: > >> Brian Campbell has pointed out to me that in testing Chrome 54.0.2811.0 >> it is sending Sec-Token-Binding headers with padding. >> >> In https://tools.ietf.org/html/draft-ietf-tokbind-https-05#section-2 we >> say >> >> The header field name is "Sec-Token-Binding", and >> EncodedTokenBindingMessage is a base64url encoding (see [RFC4648] >> Section 5 ) of the TokenBindingMessage as defined in >> [I-D.ietf-tokbind-protocol ] >> >> >> When we did JOSE we found RFC4648 >> a touch to vague on >> padding. in principal encoders and decoders will work both ways. >> However for interoperability and space saving we required the producer to >> send non padded to avoid confusion. >> >> We also added a appendix to help people with base64url without padding. >> https://tools.ietf.org/html/rfc7515#appendix-C >> >> Can the authors look at clarifying this, as written sending with or >> without padding is allowed by my reading. >> >> Including the appendix would also be fine with me if people think it >> would help clarify things for developers. >> >> Thanks. >> >> John B. >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >> >> > > --047d7b86e92efce29d05390aaa0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can you guys propose some language how to make this more p= recise? And add that to=C2=A0https://github.com/TokenBinding/Internet-Drafts/iss= ues/56=C2=A0?

Thanks,=C2=A0

Dirk.

On Mon, Aug 1, 2016 at 9:13 AM John Br= adley <jbradley@me.com> wrote:=
Decoders will likely do the correct thing.=C2=A0 However having one corre= ct way to produce encoded token binding message will reduce confusion I sus= pect, it makes examples less ambiguous.

John B.

On Aug 1, 2016, at 11:53 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Most base64 decoders, I think, will happily hand= le both padded and unpadded input.=C2=A0 So it probably doesn't matter = all that much. But for consistency and marginal space savings, I'd be i= n favor of having HTTPSTB say to omit the padding. There's some languag= e in a comment on https://github.com/TokenBinding/Internet-Dra= fts/issues/27 to that effect, which could be borrowed from, if desired.=

Most base64 encoders/decoders (nowadays?) also handle both the sta= ndard and the URL/filename safe alphabet. I don't really think there= 9;s value in an appendix like the one in RFC 7515.

On Fri, Jul 29, 2016 at 4:30 PM= , John Bradley <jbradley@me.com> wrote:
Brian Campbell has pointe= d out to me that in testing Chrome=C2=A054.0.2811.0 it is sending Sec-Token-Binding header= s with padding.

The header field name is "Sec-Token-Binding", and EncodedTokenBindingMessage is a base64url encoding (see [RFC4648] Section=C2=A05) of the TokenBindingMessage as defined in [I-D.ietf-tokbind-protocol]=

When we did JOSE we found=C2=A0RFC4648=C2=A0a touch to vague on padding. =C2=A0in p= rincipal encoders and decoders will work both ways.
However for i= nteroperability and space saving we required the producer to send non padde= d to avoid confusion.

We also added a appendix to = help people with base64url without padding.

Can the authors = =C2=A0look at clarifying this, =C2=A0as written sending with or without pad= ding is allowed by my reading.

Including the appen= dix would also be fine with me if people think it would help clarify things= for developers.

Thanks.

= John B.

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



--047d7b86e92efce29d05390aaa0d-- From nobody Tue Aug 2 00:06:48 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 5C8D912B03C for ; Tue, 2 Aug 2016 00:06:47 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 Pvcklk9__F8N for ; Tue, 2 Aug 2016 00:06:45 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id BB96012B004 for ; Tue, 2 Aug 2016 00:06:45 -0700 (PDT) Received: (qmail 28011 invoked by uid 0); 2 Aug 2016 07:06:40 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy4.mail.unifiedlayer.com with SMTP; 2 Aug 2016 07:06:39 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id S76a1t00n2UhLwi0176dXa; Tue, 02 Aug 2016 01:06:39 -0600 X-Authority-Analysis: v=2.1 cv=TIHWFTVa c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=7z1cN_iqozsA:10 a=1XWaLZrsAAAA:8 a=NEAV23lmAAAA:8 a=HHGDD-5mAAAA:8 a=LS6YZpeZAAAA:8 a=48vgC7mUAAAA:8 a=Ufh3ZrjqDVdETcgavz4A:9 a=QEXdDO2ut3YA:10 a=nJcEw6yWrPvoIXZ49MH8:22 a=Bn2pgwyD2vrAyMmN8A2t:22 a=B8TCfWyN7RlcJ1j5uPC-:22 a=IRr2vCDBpksuBOXhfkKu:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=MIME-Version:Content-Type:In-Reply-To: References:Subject:Cc:To:From:Message-ID:Date; bh=Z7MVDjRl3DteRbpF72kpZcfxGxHE1FSzwIyhuOtwww4=; b=mPLXZZwvijIWM2kRw7VYBuPplm FS+6ea8rBvYN8P+Bq0zfNkYJsF9bx2pvVS++vuXgyDA8/nGC+8G4St0F/SFWL/KV3IvqMcXh0y0Mu C9cmRr636fU/p/7a8LbLuEACf; Received: from [127.0.0.1] (port=33917 helo=box514.bluehost.com) by box514.bluehost.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86_2) (envelope-from ) id 1bUTmc-0000Il-PI; Tue, 02 Aug 2016 01:06:34 -0600 Received: from 88.102.9.71 ([88.102.9.71]) by box514.bluehost.com (Horde Framework) with HTTP; Tue, 02 Aug 2016 01:06:29 -0600 Date: Tue, 02 Aug 2016 01:06:29 -0600 Message-ID: <20160802010629.Horde.U7dIuq8Tpv2-SnvY3Dfd9ae@box514.bluehost.com> From: jeff.hodges@kingsmountain.com To: Dirk Balfanz References: <56260ABF-1B8A-41CB-BA16-0ACFFDE80097@me.com> <6FAE8287-E6E7-4E21-BFC9-60B948ABDB2D@me.com> In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-Identified-User: {:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:program running on server} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - kingsmountain.com X-Source-IP: 127.0.0.1 X-Exim-ID: 1bUTmc-0000Il-PI X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (box514.bluehost.com) [127.0.0.1]:33917 X-Source-Auth: jeff.hodges@kingsmountain.com X-Email-Count: 0 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Cc: IETF Tokbind WG , Brian Campbell , Andrei Popov , =JeffH Hodges , John Bradley Subject: Re: [Unbearable] Base64url encoding in draft-ietf-tokbind-https 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, 02 Aug 2016 07:06:47 -0000 Quoting Dirk Balfanz : > Can you guys propose some language how to make this more precise? And add > that to https://github.com/TokenBinding/Internet-Drafts/issues/56 ? see: https://github.com/TokenBinding/Internet-Drafts/issues/56#issuecomment-236815758 > On Mon, Aug 1, 2016 at 9:13 AM John Bradley wrote: > >> Decoders will likely do the correct thing. However having one correct way >> to produce encoded token binding message will reduce confusion I suspect, >> it makes examples less ambiguous. >> >> John B. >> >> On Aug 1, 2016, at 11:53 AM, Brian Campbell >> wrote: >> >> Most base64 decoders, I think, will happily handle both padded and >> unpadded input. So it probably doesn't matter all that much. But for >> consistency and marginal space savings, I'd be in favor of having HTTPSTB >> say to omit the padding. There's some language in a comment on >> https://github.com/TokenBinding/Internet-Drafts/issues/27 to that effect, >> which could be borrowed from, if desired. >> >> Most base64 encoders/decoders (nowadays?) also handle both the standard >> and the URL/filename safe alphabet. I don't really think there's value in >> an appendix like the one in RFC 7515. >> >> On Fri, Jul 29, 2016 at 4:30 PM, John Bradley wrote: >> >>> Brian Campbell has pointed out to me that in testing Chrome 54.0.2811.0 >>> it is sending Sec-Token-Binding headers with padding. >>> >>> In https://tools.ietf.org/html/draft-ietf-tokbind-https-05#section-2 we >>> say >>> >>> The header field name is "Sec-Token-Binding", and >>> EncodedTokenBindingMessage is a base64url encoding (see [RFC4648] >>> Section 5 ) of >>> the TokenBindingMessage as defined in >>> [I-D.ietf-tokbind-protocol >>> ] >>> >>> >>> When we did JOSE we found RFC4648 >>> a touch to vague on >>> padding. in principal encoders and decoders will work both ways. >>> However for interoperability and space saving we required the producer to >>> send non padded to avoid confusion. >>> >>> We also added a appendix to help people with base64url without padding. >>> https://tools.ietf.org/html/rfc7515#appendix-C >>> >>> Can the authors look at clarifying this, as written sending with or >>> without padding is allowed by my reading. >>> >>> Including the appendix would also be fine with me if people think it >>> would help clarify things for developers. >>> >>> Thanks. >>> >>> John B. >>> >>> _______________________________________________ >>> Unbearable mailing list >>> Unbearable@ietf.org >>> https://www.ietf.org/mailman/listinfo/unbearable >>> >>> >> >> From nobody Tue Aug 2 07:14: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 A6BBC12D73C for ; Tue, 2 Aug 2016 07:14:56 -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 RH-Iqe0mRAiQ for ; Tue, 2 Aug 2016 07:14:52 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 59DC412D630 for ; Tue, 2 Aug 2016 07:14:52 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id f6so202008064ith.0 for ; Tue, 02 Aug 2016 07:14:52 -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=UvSTKUMy1arYhLcSkPID9I1J3YwgWha69nYFfp48Lxo=; b=psoa6BaBT6v5cMECXMuzqlgSYCbWsSmpZcdnShrqd6841IV2niCZx5w0pG6cI0CKSm 2uqNt1n73tSts9EJU8R7ENDnqQxQY+JkNYB37A4N9Vs02SQIwJzh47WmBVEYJ/JKnQfh BtSLNmpuTjmVMDYNuHnsjkIFfQXEChjORUIig= 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=UvSTKUMy1arYhLcSkPID9I1J3YwgWha69nYFfp48Lxo=; b=QxuVBSr7jS7MMvNipuNTxQaZfVYoorpoeyTZhtY70PvlCvuFzze14n9baaNUbRlmrx e6oEChZjZWCm8HY1QF72fLlX2oaC5ovOLptrg4hHlHMi6Z1ZspShmmmmcX7TL/Qb14sd oKPVuLRygGXob/0hDy1UBoFYD2evdkGP91CoJZzaWXZ2A85FCKI5/9Lh22JWQ7qUiiuf OP0p/VXt/6+h60j8JrAp5Ni3oLxvhBp9UTkZ4Zowsvn6ru87jPpD/lrSbIS/As/T2N1U gtee1qzVfVGhKx1Pr6vYA1GwyT9gTwvk6dK2kRANXaYSKaC93meGBnAa7mBEMCJDg1BV LotA== X-Gm-Message-State: AEkoousjGxu5FJak3EcDrEfRi0fQTET+6377TlF8vr0gm61D8DIPmMVT4LDIgD8cTUjJmktPeovmkkwNywewfoxy X-Received: by 10.36.34.145 with SMTP id o139mr57300552ito.11.1470147291596; Tue, 02 Aug 2016 07:14:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Tue, 2 Aug 2016 07:14:20 -0700 (PDT) In-Reply-To: <20160802010629.Horde.U7dIuq8Tpv2-SnvY3Dfd9ae@box514.bluehost.com> References: <56260ABF-1B8A-41CB-BA16-0ACFFDE80097@me.com> <6FAE8287-E6E7-4E21-BFC9-60B948ABDB2D@me.com> <20160802010629.Horde.U7dIuq8Tpv2-SnvY3Dfd9ae@box514.bluehost.com> From: Brian Campbell Date: Tue, 2 Aug 2016 08:14:20 -0600 Message-ID: To: Jeff Hodges Content-Type: multipart/alternative; boundary=001a11406670156489053917579e Archived-At: Cc: IETF Tokbind WG , =JeffH Hodges , Dirk Balfanz , Andrei Popov , John Bradley Subject: Re: [Unbearable] Base64url encoding in draft-ietf-tokbind-https 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, 02 Aug 2016 14:14:56 -0000 --001a11406670156489053917579e Content-Type: text/plain; charset=UTF-8 I just submitted pull request #57 , which has proposed language for this (also copied below). The header field name is "Sec-Token-Binding" and its value is a base64url encoding of the TokenBindingMessage defined in [I-D.ietf-tokbind-protocol] using the URL- and filename-safe character set described in Section 5 of [RFC4648], with all trailing pad characters '=' omitted and without the inclusion of any line breaks, whitespace, or other additional characters. On Tue, Aug 2, 2016 at 1:06 AM, wrote: > > Quoting Dirk Balfanz : > >> Can you guys propose some language how to make this more precise? And add >> that to https://github.com/TokenBinding/Internet-Drafts/issues/56 ? >> > > see: > https://github.com/TokenBinding/Internet-Drafts/issues/56#issuecomment-236815758 > > > > > On Mon, Aug 1, 2016 at 9:13 AM John Bradley wrote: >> >> Decoders will likely do the correct thing. However having one correct way >>> to produce encoded token binding message will reduce confusion I suspect, >>> it makes examples less ambiguous. >>> >>> John B. >>> >>> On Aug 1, 2016, at 11:53 AM, Brian Campbell >>> wrote: >>> >>> Most base64 decoders, I think, will happily handle both padded and >>> unpadded input. So it probably doesn't matter all that much. But for >>> consistency and marginal space savings, I'd be in favor of having HTTPSTB >>> say to omit the padding. There's some language in a comment on >>> https://github.com/TokenBinding/Internet-Drafts/issues/27 to that >>> effect, >>> which could be borrowed from, if desired. >>> >>> Most base64 encoders/decoders (nowadays?) also handle both the standard >>> and the URL/filename safe alphabet. I don't really think there's value in >>> an appendix like the one in RFC 7515. >>> >>> On Fri, Jul 29, 2016 at 4:30 PM, John Bradley wrote: >>> >>> Brian Campbell has pointed out to me that in testing Chrome 54.0.2811.0 >>>> it is sending Sec-Token-Binding headers with padding. >>>> >>>> In https://tools.ietf.org/html/draft-ietf-tokbind-https-05#section-2 we >>>> say >>>> >>>> The header field name is "Sec-Token-Binding", and >>>> EncodedTokenBindingMessage is a base64url encoding (see [RFC4648] >>>> Section 5 ) of the >>>> TokenBindingMessage as defined in >>>> [I-D.ietf-tokbind-protocol < >>>> https://tools.ietf.org/html/draft-ietf-tokbind-https-05#ref-I-D.ietf-tokbind-protocol >>>> >] >>>> >>>> >>>> When we did JOSE we found RFC4648 >>>> a touch to vague on >>>> padding. in principal encoders and decoders will work both ways. >>>> However for interoperability and space saving we required the producer >>>> to >>>> send non padded to avoid confusion. >>>> >>>> We also added a appendix to help people with base64url without padding. >>>> https://tools.ietf.org/html/rfc7515#appendix-C >>>> >>>> Can the authors look at clarifying this, as written sending with or >>>> without padding is allowed by my reading. >>>> >>>> Including the appendix would also be fine with me if people think it >>>> would help clarify things for developers. >>>> >>>> Thanks. >>>> >>>> John B. >>>> >>>> _______________________________________________ >>>> Unbearable mailing list >>>> Unbearable@ietf.org >>>> https://www.ietf.org/mailman/listinfo/unbearable >>>> >>>> >>>> >>> >>> > > > --001a11406670156489053917579e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I just submitted pull request #57, which ha= s proposed language for this (also copied below).

=C2=A0=C2=A0 The header field name is "= Sec-Token-Binding" and its value is a
=C2=A0=C2=A0 base64url encodi= ng of the TokenBindingMessage defined in
=C2=A0=C2=A0 [I-D.ietf-tokbind-= protocol] using the URL- and filename-safe
=C2=A0=C2=A0 character set de= scribed in Section 5 of [RFC4648], with all trailing
=C2=A0=C2=A0 pad ch= aracters '=3D' omitted and without the inclusion of any line
=C2= =A0=C2=A0 breaks, whitespace, or other additional characters.

On Tue, Aug 2, 2= 016 at 1:06 AM, <jeff.hodges@kingsmountain.com>= wrote:

Quoting Dirk Balfanz <balfanz@google.com>:
Can you guys propose some language how to make this more precise? And add that to https://github.com/TokenBinding/Int= ernet-Drafts/issues/56 ?

 see: https://github.= com/TokenBinding/Internet-Drafts/issues/56#issuecomment-236815758




On Mon, Aug 1, 2016 at 9:13 AM John Bradley <jbradley@me.com> wrote:

Decoders will likely do the correct thing.=C2=A0 However having one correct= way
to produce encoded token binding message will reduce confusion I suspect, it makes examples less ambiguous.

John B.

On Aug 1, 2016, at 11:53 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:

Most base64 decoders, I think, will happily handle both padded and
unpadded input.=C2=A0 So it probably doesn't matter all that much. But = for
consistency and marginal space savings, I'd be in favor of having HTTPS= TB
say to omit the padding. There's some language in a comment on
https://github.com/TokenBinding/Internet-Dr= afts/issues/27 to that effect,
which could be borrowed from, if desired.

Most base64 encoders/decoders (nowadays?) also handle both the standard
and the URL/filename safe alphabet. I don't really think there's va= lue in
an appendix like the one in RFC 7515.

On Fri, Jul 29, 2016 at 4:30 PM, John Bradley <jbradley@me.com> wrote:

Brian Campbell has pointed out to me that in testing Chrome 54.0.2811.0
it is sending Sec-Token-Binding headers with padding.

In https://tools.ietf.org/html/draf= t-ietf-tokbind-https-05#section-2 we
say

=C2=A0The header field name is "Sec-Token-Binding", and
=C2=A0 =C2=A0EncodedTokenBindingMessage is a base64url encoding (see [RFC46= 48]
 =C2=A0 =C2=A0Section 5 <https://tools.ietf.org/html/= rfc4648#section-5>) of the TokenBindingMessage as defined in
=C2=A0 =C2=A0[I-D.ietf-tokbind-protocol <https://tools.ietf.org/html/draft-ietf-tokbind= -https-05#ref-I-D.ietf-tokbind-protocol>]


When we did JOSE we found RFC4648
 <https://tools.ietf.org/html/rfc4648#section-5&g= t; a touch to vague on
padding.=C2=A0 in principal encoders and decoders will work both ways.
However for interoperability and space saving we required the producer to send non padded to avoid confusion.

We also added a appendix to help people with base64url without padding.
https://tools.ietf.org/html/rfc7515#appendix-C

Can the authors=C2=A0 look at clarifying this,=C2=A0 as written sending wit= h or
without padding is allowed by my reading.

Including the appendix would also be fine with me if people think it
would help clarify things for developers.

Thanks.

John B.

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








--001a11406670156489053917579e-- From nobody Tue Aug 2 07:50:47 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 E8475127058 for ; Tue, 2 Aug 2016 07:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 pZ9Gc1ANCHmG for ; Tue, 2 Aug 2016 07:50:42 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0125.outbound.protection.outlook.com [104.47.33.125]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA81A12D67D for ; Tue, 2 Aug 2016 07:50:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vXgol1wzbI7Bmxp972Pa+Oiv0f/n1rnf5Bhhw5VO/SQ=; b=CPLesV1/ZpQxL+fTlSeOK4AWy91cDYyF/aj9eySg4WBk464TDip415Ir1j7uUHUzMyjfbwC8/jkYfjp01l83mpnkcSsW5q1tIc3MdgcKxLth4Gbl3OECEkGWs/vWWqbKCPxvs5MYKS3v77mirlgWQcmfvMryn4WTtguDtsCpGMs= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN2PR03MB2159.namprd03.prod.outlook.com (10.166.209.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 2 Aug 2016 14:50:35 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0549.022; Tue, 2 Aug 2016 14:50:35 +0000 From: Mike Jones To: Brian Campbell , Jeff Hodges Thread-Topic: [Unbearable] Base64url encoding in draft-ietf-tokbind-https Thread-Index: AQHR6ejZznQP9hW/GE6FMmxO6JVaFKA0RfmAgAAFf4CAAHOtAIAAhdGAgAB3igCAAAoXQA== Date: Tue, 2 Aug 2016 14:50:35 +0000 Message-ID: References: <56260ABF-1B8A-41CB-BA16-0ACFFDE80097@me.com> <6FAE8287-E6E7-4E21-BFC9-60B948ABDB2D@me.com> <20160802010629.Horde.U7dIuq8Tpv2-SnvY3Dfd9ae@box514.bluehost.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.201.94.142] x-ms-office365-filtering-correlation-id: e1c7b9ee-8f35-4808-d022-08d3bae45c85 x-microsoft-exchange-diagnostics: 1; SN2PR03MB2159; 6:+b8QNBU5PW80NTtk6Lh8QYL3vIFxnYpR20UHv7SUpZeIH9cJKO1S4HeRli9zt6696nfyXChCFVhgnhzeF0L7NhGTjKoKssUnJfs9A/jZmlQXo5BaElPE8qW5eD3oNsMqmzPgZw7JcBQ//k8hnSMvlSdWS1yNnpNaZoSwkx74zHMM8iGd2EpnE4/jFjluSfJVaan/NGFz67CtH3GOXxBcl60RNrqh9/e863FsrmQSTR1sxkujn58QW0UPHggzP5lHG3XrXSTAXuzEsAc9go8j1M2Tfk3jko//XSQP/qD8IENckV34hNQWVAtPAP82hoPkBE7DBhD5VDH+iabUoausNw==; 5:m0D06UyM1Ntt2fYg06ZYfCJYs6mN4NCqMkEc5PWhYoHi00FA5Yysk6tnzLgrlOK2wV2GGMH136YyHZYW3UQRhWeqVyP1PcDoBZDu7bJOon0NQp11ItnNFFUk3XA7Cstkzfbhms5v3T+pc+zc/WO1pg==; 24:lXg29EcQikSJkLrWm6vEtgjt6E1CD/nOLfi7uHSa5TradN6N17ybzmzrZNyaOG1eNGDR8H3ruPjnJFCH1vOAy/pEmoVAu9i1Lhty+KUwsc4=; 7:i3UfKqC9+uYIZhW8atnEEPX8MgVNl+YCqjo+fAb5WI+zs8sJMHGUmGqTABWWSgYxHZH3Qte+v3+rZZ2TKxk41VjmPCPXjJNa5ow0Ps3fVtR5haDuS9vpUY6mPAdftSyN4zieLvbtJDUL7IJEsTAsz+k6LzOD0thMscrZ1FCaHPBaBLTC0QdQR/mGbHdfS9G8Cb8QWXazcHN1HMW+XTuMRUjxyjP1I4ZuGmxSVG8++QzR1Ao1CVHMUpzXpgKDDGKI x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR03MB2159; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(252895345309445)(188474585043545)(166708455590820)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN2PR03MB2159; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2159; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(24454002)(199003)(189002)(2900100001)(76176999)(11100500001)(54356999)(81156014)(81166006)(50986999)(586003)(2950100001)(33656002)(230783001)(5002640100001)(92566002)(68736007)(16236675004)(74316002)(3280700002)(19617315012)(19609705001)(86612001)(76576001)(8676002)(5001770100001)(19300405004)(4326007)(3660700001)(93886004)(15975445007)(102836003)(10090500001)(86362001)(9686002)(97736004)(122556002)(105586002)(8990500004)(66066001)(10400500002)(5005710100001)(10290500002)(189998001)(99286002)(101416001)(2906002)(77096005)(7736002)(7696003)(19580395003)(19580405001)(7906003)(106356001)(106116001)(19625215002)(6116002)(790700001)(3846002)(8666005)(8936002)(7846002)(87936001)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR03MB2159; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB16455442EFE001FDA938B5B7F5050SN1PR0301MB1645_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2016 14:50:35.4553 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2159 Archived-At: Cc: IETF Tokbind WG , John Bradley , Dirk Balfanz , Andrei Popov , =JeffH Hodges Subject: Re: [Unbearable] Base64url encoding in draft-ietf-tokbind-https 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, 02 Aug 2016 14:50:46 -0000 --_000_SN1PR0301MB16455442EFE001FDA938B5B7F5050SN1PR0301MB1645_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEJyaWFuIENhbXBiZWxsDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMiwg MjAxNiA3OjE0IEFNDQpUbzogSmVmZiBIb2RnZXMgPGplZmYuaG9kZ2VzQGtpbmdzbW91bnRhaW4u Y29tPg0KQ2M6IElFVEYgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz47ID1KZWZmSCBI b2RnZXMgPEplZmYuSG9kZ2VzQHBheXBhbC5jb20+OyBEaXJrIEJhbGZhbnogPGJhbGZhbnpAZ29v Z2xlLmNvbT47IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+OyBKb2hu IEJyYWRsZXkgPGpicmFkbGV5QG1lLmNvbT4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gQmFz ZTY0dXJsIGVuY29kaW5nIGluIGRyYWZ0LWlldGYtdG9rYmluZC1odHRwcw0KDQpJIGp1c3Qgc3Vi bWl0dGVkIHB1bGwgcmVxdWVzdCAjNTc8aHR0cHM6Ly9naXRodWIuY29tL1Rva2VuQmluZGluZy9J bnRlcm5ldC1EcmFmdHMvcHVsbC81Nz4sIHdoaWNoIGhhcyBwcm9wb3NlZCBsYW5ndWFnZSBmb3Ig dGhpcyAoYWxzbyBjb3BpZWQgYmVsb3cpLg0KDQogICBUaGUgaGVhZGVyIGZpZWxkIG5hbWUgaXMg IlNlYy1Ub2tlbi1CaW5kaW5nIiBhbmQgaXRzIHZhbHVlIGlzIGENCiAgIGJhc2U2NHVybCBlbmNv ZGluZyBvZiB0aGUgVG9rZW5CaW5kaW5nTWVzc2FnZSBkZWZpbmVkIGluDQogICBbSS1ELmlldGYt dG9rYmluZC1wcm90b2NvbF0gdXNpbmcgdGhlIFVSTC0gYW5kIGZpbGVuYW1lLXNhZmUNCiAgIGNo YXJhY3RlciBzZXQgZGVzY3JpYmVkIGluIFNlY3Rpb24gNSBvZiBbUkZDNDY0OF0sIHdpdGggYWxs IHRyYWlsaW5nDQogICBwYWQgY2hhcmFjdGVycyAnPScgb21pdHRlZCBhbmQgd2l0aG91dCB0aGUg aW5jbHVzaW9uIG9mIGFueSBsaW5lDQogICBicmVha3MsIHdoaXRlc3BhY2UsIG9yIG90aGVyIGFk ZGl0aW9uYWwgY2hhcmFjdGVycy4NCg0KT24gVHVlLCBBdWcgMiwgMjAxNiBhdCAxOjA2IEFNLCA8 amVmZi5ob2RnZXNAa2luZ3Ntb3VudGFpbi5jb208bWFpbHRvOmplZmYuaG9kZ2VzQGtpbmdzbW91 bnRhaW4uY29tPj4gd3JvdGU6DQoNClF1b3RpbmcgRGlyayBCYWxmYW56IDxiYWxmYW56QGdvb2ds ZS5jb208bWFpbHRvOmJhbGZhbnpAZ29vZ2xlLmNvbT4+Og0KQ2FuIHlvdSBndXlzIHByb3Bvc2Ug c29tZSBsYW5ndWFnZSBob3cgdG8gbWFrZSB0aGlzIG1vcmUgcHJlY2lzZT8gQW5kIGFkZA0KdGhh dCB0byBodHRwczovL2dpdGh1Yi5jb20vVG9rZW5CaW5kaW5nL0ludGVybmV0LURyYWZ0cy9pc3N1 ZXMvNTYgPw0KDQpzZWU6IGh0dHBzOi8vZ2l0aHViLmNvbS9Ub2tlbkJpbmRpbmcvSW50ZXJuZXQt RHJhZnRzL2lzc3Vlcy81NiNpc3N1ZWNvbW1lbnQtMjM2ODE1NzU4DQoNCg0KDQpPbiBNb24sIEF1 ZyAxLCAyMDE2IGF0IDk6MTMgQU0gSm9obiBCcmFkbGV5IDxqYnJhZGxleUBtZS5jb208bWFpbHRv OmpicmFkbGV5QG1lLmNvbT4+IHdyb3RlOg0KRGVjb2RlcnMgd2lsbCBsaWtlbHkgZG8gdGhlIGNv cnJlY3QgdGhpbmcuICBIb3dldmVyIGhhdmluZyBvbmUgY29ycmVjdCB3YXkNCnRvIHByb2R1Y2Ug ZW5jb2RlZCB0b2tlbiBiaW5kaW5nIG1lc3NhZ2Ugd2lsbCByZWR1Y2UgY29uZnVzaW9uIEkgc3Vz cGVjdCwNCml0IG1ha2VzIGV4YW1wbGVzIGxlc3MgYW1iaWd1b3VzLg0KDQpKb2huIEIuDQoNCk9u IEF1ZyAxLCAyMDE2LCBhdCAxMTo1MyBBTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5n aWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+DQp3cm90ZToN Cg0KTW9zdCBiYXNlNjQgZGVjb2RlcnMsIEkgdGhpbmssIHdpbGwgaGFwcGlseSBoYW5kbGUgYm90 aCBwYWRkZWQgYW5kDQp1bnBhZGRlZCBpbnB1dC4gIFNvIGl0IHByb2JhYmx5IGRvZXNuJ3QgbWF0 dGVyIGFsbCB0aGF0IG11Y2guIEJ1dCBmb3INCmNvbnNpc3RlbmN5IGFuZCBtYXJnaW5hbCBzcGFj ZSBzYXZpbmdzLCBJJ2QgYmUgaW4gZmF2b3Igb2YgaGF2aW5nIEhUVFBTVEINCnNheSB0byBvbWl0 IHRoZSBwYWRkaW5nLiBUaGVyZSdzIHNvbWUgbGFuZ3VhZ2UgaW4gYSBjb21tZW50IG9uDQpodHRw czovL2dpdGh1Yi5jb20vVG9rZW5CaW5kaW5nL0ludGVybmV0LURyYWZ0cy9pc3N1ZXMvMjcgdG8g dGhhdCBlZmZlY3QsDQp3aGljaCBjb3VsZCBiZSBib3Jyb3dlZCBmcm9tLCBpZiBkZXNpcmVkLg0K DQpNb3N0IGJhc2U2NCBlbmNvZGVycy9kZWNvZGVycyAobm93YWRheXM/KSBhbHNvIGhhbmRsZSBi b3RoIHRoZSBzdGFuZGFyZA0KYW5kIHRoZSBVUkwvZmlsZW5hbWUgc2FmZSBhbHBoYWJldC4gSSBk b24ndCByZWFsbHkgdGhpbmsgdGhlcmUncyB2YWx1ZSBpbg0KYW4gYXBwZW5kaXggbGlrZSB0aGUg b25lIGluIFJGQyA3NTE1Lg0KDQpPbiBGcmksIEp1bCAyOSwgMjAxNiBhdCA0OjMwIFBNLCBKb2hu IEJyYWRsZXkgPGpicmFkbGV5QG1lLmNvbTxtYWlsdG86amJyYWRsZXlAbWUuY29tPj4gd3JvdGU6 DQpCcmlhbiBDYW1wYmVsbCBoYXMgcG9pbnRlZCBvdXQgdG8gbWUgdGhhdCBpbiB0ZXN0aW5nIENo cm9tZSA1NC4wLjI4MTEuMA0KaXQgaXMgc2VuZGluZyBTZWMtVG9rZW4tQmluZGluZyBoZWFkZXJz IHdpdGggcGFkZGluZy4NCg0KSW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWll dGYtdG9rYmluZC1odHRwcy0wNSNzZWN0aW9uLTIgd2UNCnNheQ0KDQogVGhlIGhlYWRlciBmaWVs ZCBuYW1lIGlzICJTZWMtVG9rZW4tQmluZGluZyIsIGFuZA0KICAgRW5jb2RlZFRva2VuQmluZGlu Z01lc3NhZ2UgaXMgYSBiYXNlNjR1cmwgZW5jb2RpbmcgKHNlZSBbUkZDNDY0OF0NCiAgIFNlY3Rp b24gNSA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ2NDgjc2VjdGlvbi01Pikgb2Yg dGhlIFRva2VuQmluZGluZ01lc3NhZ2UgYXMgZGVmaW5lZCBpbg0KICAgW0ktRC5pZXRmLXRva2Jp bmQtcHJvdG9jb2wgPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2Jp bmQtaHR0cHMtMDUjcmVmLUktRC5pZXRmLXRva2JpbmQtcHJvdG9jb2w+XQ0KDQoNCldoZW4gd2Ug ZGlkIEpPU0Ugd2UgZm91bmQgUkZDNDY0OA0KPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9y ZmM0NjQ4I3NlY3Rpb24tNT4gYSB0b3VjaCB0byB2YWd1ZSBvbg0KcGFkZGluZy4gIGluIHByaW5j aXBhbCBlbmNvZGVycyBhbmQgZGVjb2RlcnMgd2lsbCB3b3JrIGJvdGggd2F5cy4NCkhvd2V2ZXIg Zm9yIGludGVyb3BlcmFiaWxpdHkgYW5kIHNwYWNlIHNhdmluZyB3ZSByZXF1aXJlZCB0aGUgcHJv ZHVjZXIgdG8NCnNlbmQgbm9uIHBhZGRlZCB0byBhdm9pZCBjb25mdXNpb24uDQoNCldlIGFsc28g YWRkZWQgYSBhcHBlbmRpeCB0byBoZWxwIHBlb3BsZSB3aXRoIGJhc2U2NHVybCB3aXRob3V0IHBh ZGRpbmcuDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxNSNhcHBlbmRpeC1DDQoN CkNhbiB0aGUgYXV0aG9ycyAgbG9vayBhdCBjbGFyaWZ5aW5nIHRoaXMsICBhcyB3cml0dGVuIHNl bmRpbmcgd2l0aCBvcg0Kd2l0aG91dCBwYWRkaW5nIGlzIGFsbG93ZWQgYnkgbXkgcmVhZGluZy4N Cg0KSW5jbHVkaW5nIHRoZSBhcHBlbmRpeCB3b3VsZCBhbHNvIGJlIGZpbmUgd2l0aCBtZSBpZiBw ZW9wbGUgdGhpbmsgaXQNCndvdWxkIGhlbHAgY2xhcmlmeSB0aGluZ3MgZm9yIGRldmVsb3BlcnMu DQoNClRoYW5rcy4NCg0KSm9obiBCLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QNClVuYmVhcmFibGVAaWV0 Zi5vcmc8bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCg0KDQoNCg0KDQo= --_000_SN1PR0301MB16455442EFE001FDA938B5B7F5050SN1PR0301MB1645_ 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 IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+JiM0MzsxPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwv cD4NCjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGll dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBDYW1wYmVsbDxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBBdWd1c3QgMiwgMjAxNiA3OjE0IEFNPGJyPg0KPGI+VG86PC9iPiBKZWZm IEhvZGdlcyAmbHQ7amVmZi5ob2RnZXNAa2luZ3Ntb3VudGFpbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBJRVRGIFRva2JpbmQgV0cgJmx0O3VuYmVhcmFibGVAaWV0Zi5vcmcmZ3Q7OyA9SmVmZkgg SG9kZ2VzICZsdDtKZWZmLkhvZGdlc0BwYXlwYWwuY29tJmd0OzsgRGlyayBCYWxmYW56ICZsdDti YWxmYW56QGdvb2dsZS5jb20mZ3Q7OyBBbmRyZWkgUG9wb3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNy b3NvZnQuY29tJmd0OzsgSm9obiBCcmFkbGV5ICZsdDtqYnJhZGxleUBtZS5jb20mZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gQmFzZTY0dXJsIGVuY29kaW5nIGluIGRy YWZ0LWlldGYtdG9rYmluZC1odHRwczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSBqdXN0IHN1Ym1pdHRlZCA8YSBocmVm PSJodHRwczovL2dpdGh1Yi5jb20vVG9rZW5CaW5kaW5nL0ludGVybmV0LURyYWZ0cy9wdWxsLzU3 IiB0YXJnZXQ9Il9ibGFuayI+DQpwdWxsIHJlcXVlc3QgIzU3PC9hPiwgd2hpY2ggaGFzIHByb3Bv c2VkIGxhbmd1YWdlIGZvciB0aGlzIChhbHNvIGNvcGllZCBiZWxvdykuIDxicj4NCjxicj4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i c3A7IFRoZSBoZWFkZXIgZmllbGQgbmFtZSBpcyAmcXVvdDtTZWMtVG9rZW4tQmluZGluZyZxdW90 OyBhbmQgaXRzIHZhbHVlIGlzIGE8YnI+DQombmJzcDsmbmJzcDsgYmFzZTY0dXJsIGVuY29kaW5n IG9mIHRoZSBUb2tlbkJpbmRpbmdNZXNzYWdlIGRlZmluZWQgaW48YnI+DQombmJzcDsmbmJzcDsg W0ktRC5pZXRmLXRva2JpbmQtcHJvdG9jb2xdIHVzaW5nIHRoZSBVUkwtIGFuZCBmaWxlbmFtZS1z YWZlPGJyPg0KJm5ic3A7Jm5ic3A7IGNoYXJhY3RlciBzZXQgZGVzY3JpYmVkIGluIFNlY3Rpb24g NSBvZiBbUkZDNDY0OF0sIHdpdGggYWxsIHRyYWlsaW5nPGJyPg0KJm5ic3A7Jm5ic3A7IHBhZCBj aGFyYWN0ZXJzICc9JyBvbWl0dGVkIGFuZCB3aXRob3V0IHRoZSBpbmNsdXNpb24gb2YgYW55IGxp bmU8YnI+DQombmJzcDsmbmJzcDsgYnJlYWtzLCB3aGl0ZXNwYWNlLCBvciBvdGhlciBhZGRpdGlv bmFsIGNoYXJhY3RlcnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFR1ZSwgQXVnIDIsIDIwMTYgYXQgMTowNiBBTSwgJmx0OzxhIGhyZWY9Im1haWx0bzpq ZWZmLmhvZGdlc0BraW5nc21vdW50YWluLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmplZmYuaG9kZ2Vz QGtpbmdzbW91bnRhaW4uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KUXVvdGluZyBEaXJrIEJhbGZhbnogJmx0 OzxhIGhyZWY9Im1haWx0bzpiYWxmYW56QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5iYWxm YW56QGdvb2dsZS5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5DYW4geW91IGd1eXMgcHJvcG9zZSBzb21lIGxhbmd1YWdlIGhvdyB0 byBtYWtlIHRoaXMgbW9yZSBwcmVjaXNlPyBBbmQgYWRkPGJyPg0KdGhhdCB0byA8YSBocmVmPSJo dHRwczovL2dpdGh1Yi5jb20vVG9rZW5CaW5kaW5nL0ludGVybmV0LURyYWZ0cy9pc3N1ZXMvNTYi IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZ2l0aHViLmNvbS9Ub2tlbkJpbmRpbmcvSW50ZXJu ZXQtRHJhZnRzL2lzc3Vlcy81NjwvYT4gPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpz ZWU6IDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9Ub2tlbkJpbmRpbmcvSW50ZXJuZXQtRHJh ZnRzL2lzc3Vlcy81NiNpc3N1ZWNvbW1lbnQtMjM2ODE1NzU4IiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL2dpdGh1Yi5jb20vVG9rZW5CaW5kaW5nL0ludGVybmV0LURyYWZ0cy9pc3N1ZXMvNTYj aXNzdWVjb21tZW50LTIzNjgxNTc1ODwvYT48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPk9uIE1vbiwgQXVnIDEsIDIwMTYgYXQgOToxMyBBTSBKb2huIEJyYWRs ZXkgJmx0OzxhIGhyZWY9Im1haWx0bzpqYnJhZGxleUBtZS5jb20iIHRhcmdldD0iX2JsYW5rIj5q YnJhZGxleUBtZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkRlY29k ZXJzIHdpbGwgbGlrZWx5IGRvIHRoZSBjb3JyZWN0IHRoaW5nLiZuYnNwOyBIb3dldmVyIGhhdmlu ZyBvbmUgY29ycmVjdCB3YXk8YnI+DQp0byBwcm9kdWNlIGVuY29kZWQgdG9rZW4gYmluZGluZyBt ZXNzYWdlIHdpbGwgcmVkdWNlIGNvbmZ1c2lvbiBJIHN1c3BlY3QsPGJyPg0KaXQgbWFrZXMgZXhh bXBsZXMgbGVzcyBhbWJpZ3VvdXMuPGJyPg0KPGJyPg0KSm9obiBCLjxicj4NCjxicj4NCk9uIEF1 ZyAxLCAyMDE2LCBhdCAxMTo1MyBBTSwgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0 bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBw aW5naWRlbnRpdHkuY29tPC9hPiZndDs8YnI+DQp3cm90ZTo8YnI+DQo8YnI+DQpNb3N0IGJhc2U2 NCBkZWNvZGVycywgSSB0aGluaywgd2lsbCBoYXBwaWx5IGhhbmRsZSBib3RoIHBhZGRlZCBhbmQ8 YnI+DQp1bnBhZGRlZCBpbnB1dC4mbmJzcDsgU28gaXQgcHJvYmFibHkgZG9lc24ndCBtYXR0ZXIg YWxsIHRoYXQgbXVjaC4gQnV0IGZvcjxicj4NCmNvbnNpc3RlbmN5IGFuZCBtYXJnaW5hbCBzcGFj ZSBzYXZpbmdzLCBJJ2QgYmUgaW4gZmF2b3Igb2YgaGF2aW5nIEhUVFBTVEI8YnI+DQpzYXkgdG8g b21pdCB0aGUgcGFkZGluZy4gVGhlcmUncyBzb21lIGxhbmd1YWdlIGluIGEgY29tbWVudCBvbjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9Ub2tlbkJpbmRpbmcvSW50ZXJuZXQtRHJh ZnRzL2lzc3Vlcy8yNyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9Ub2tlbkJp bmRpbmcvSW50ZXJuZXQtRHJhZnRzL2lzc3Vlcy8yNzwvYT4gdG8gdGhhdCBlZmZlY3QsPGJyPg0K d2hpY2ggY291bGQgYmUgYm9ycm93ZWQgZnJvbSwgaWYgZGVzaXJlZC48YnI+DQo8YnI+DQpNb3N0 IGJhc2U2NCBlbmNvZGVycy9kZWNvZGVycyAobm93YWRheXM/KSBhbHNvIGhhbmRsZSBib3RoIHRo ZSBzdGFuZGFyZDxicj4NCmFuZCB0aGUgVVJML2ZpbGVuYW1lIHNhZmUgYWxwaGFiZXQuIEkgZG9u J3QgcmVhbGx5IHRoaW5rIHRoZXJlJ3MgdmFsdWUgaW48YnI+DQphbiBhcHBlbmRpeCBsaWtlIHRo ZSBvbmUgaW4gUkZDIDc1MTUuPGJyPg0KPGJyPg0KT24gRnJpLCBKdWwgMjksIDIwMTYgYXQgNDoz MCBQTSwgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86amJyYWRsZXlAbWUuY29tIiB0 YXJnZXQ9Il9ibGFuayI+amJyYWRsZXlAbWUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5CcmlhbiBDYW1wYmVsbCBoYXMgcG9pbnRlZCBvdXQgdG8gbWUgdGhhdCBpbiB0 ZXN0aW5nIENocm9tZSA1NC4wLjI4MTEuMDxicj4NCml0IGlzIHNlbmRpbmcgU2VjLVRva2VuLUJp bmRpbmcgaGVhZGVycyB3aXRoIHBhZGRpbmcuPGJyPg0KPGJyPg0KSW4gPGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1odHRwcy0wNSNzZWN0aW9u LTIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1p ZXRmLXRva2JpbmQtaHR0cHMtMDUjc2VjdGlvbi0yPC9hPiB3ZTxicj4NCnNheTxicj4NCjxicj4N CiZuYnNwO1RoZSBoZWFkZXIgZmllbGQgbmFtZSBpcyAmcXVvdDtTZWMtVG9rZW4tQmluZGluZyZx dW90OywgYW5kPGJyPg0KJm5ic3A7ICZuYnNwO0VuY29kZWRUb2tlbkJpbmRpbmdNZXNzYWdlIGlz IGEgYmFzZTY0dXJsIGVuY29kaW5nIChzZWUgW1JGQzQ2NDhdPGJyPg0KJm5ic3A7ICZuYnNwO1Nl Y3Rpb24gNSAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ2NDgj c2VjdGlvbi01IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzQ2NDgjc2VjdGlvbi01PC9hPiZndDspIG9mIHRoZSBUb2tlbkJpbmRpbmdNZXNzYWdlIGFzIGRl ZmluZWQgaW48YnI+DQombmJzcDsgJm5ic3A7W0ktRC5pZXRmLXRva2JpbmQtcHJvdG9jb2wgJmx0 OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQt aHR0cHMtMDUjcmVmLUktRC5pZXRmLXRva2JpbmQtcHJvdG9jb2wiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10b2tiaW5kLWh0dHBzLTA1I3Jl Zi1JLUQuaWV0Zi10b2tiaW5kLXByb3RvY29sPC9hPiZndDtdPGJyPg0KPGJyPg0KPGJyPg0KV2hl biB3ZSBkaWQgSk9TRSB3ZSBmb3VuZCBSRkM0NjQ4PGJyPg0KJmx0OzxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NjQ4I3NlY3Rpb24tNSIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NjQ4I3NlY3Rpb24tNTwvYT4mZ3Q7IGEgdG91 Y2ggdG8gdmFndWUgb248YnI+DQpwYWRkaW5nLiZuYnNwOyBpbiBwcmluY2lwYWwgZW5jb2RlcnMg YW5kIGRlY29kZXJzIHdpbGwgd29yayBib3RoIHdheXMuPGJyPg0KSG93ZXZlciBmb3IgaW50ZXJv cGVyYWJpbGl0eSBhbmQgc3BhY2Ugc2F2aW5nIHdlIHJlcXVpcmVkIHRoZSBwcm9kdWNlciB0bzxi cj4NCnNlbmQgbm9uIHBhZGRlZCB0byBhdm9pZCBjb25mdXNpb24uPGJyPg0KPGJyPg0KV2UgYWxz byBhZGRlZCBhIGFwcGVuZGl4IHRvIGhlbHAgcGVvcGxlIHdpdGggYmFzZTY0dXJsIHdpdGhvdXQg cGFkZGluZy48YnI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUx NSNhcHBlbmRpeC1DIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzc1MTUjYXBwZW5kaXgtQzwvYT48YnI+DQo8YnI+DQpDYW4gdGhlIGF1dGhvcnMmbmJzcDsg bG9vayBhdCBjbGFyaWZ5aW5nIHRoaXMsJm5ic3A7IGFzIHdyaXR0ZW4gc2VuZGluZyB3aXRoIG9y PGJyPg0Kd2l0aG91dCBwYWRkaW5nIGlzIGFsbG93ZWQgYnkgbXkgcmVhZGluZy48YnI+DQo8YnI+ DQpJbmNsdWRpbmcgdGhlIGFwcGVuZGl4IHdvdWxkIGFsc28gYmUgZmluZSB3aXRoIG1lIGlmIHBl b3BsZSB0aGluayBpdDxicj4NCndvdWxkIGhlbHAgY2xhcmlmeSB0aGluZ3MgZm9yIGRldmVsb3Bl cnMuPGJyPg0KPGJyPg0KVGhhbmtzLjxicj4NCjxicj4NCkpvaG4gQi48YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClVuYmVhcmFi bGUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5VbmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZSIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZTwv YT48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN1PR0301MB16455442EFE001FDA938B5B7F5050SN1PR0301MB1645_-- From nobody Tue Aug 2 14:50:12 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 B4C8612D81C for ; Tue, 2 Aug 2016 14:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -22.52 X-Spam-Level: X-Spam-Status: No, score=-22.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=paypal.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 fPRSTQYpAJT3 for ; Tue, 2 Aug 2016 14:50:07 -0700 (PDT) Received: from lvs-ipout-02-data1.paypalcorp.com (lvs-ipout-02-data1.paypalcorp.com [173.224.161.144]) (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 06B7212B054 for ; Tue, 2 Aug 2016 14:50:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=paypal.com; i=@paypal.com; q=dns/txt; s=pp-dkim1; t=1470174606; x=1501710606; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rRN7NPYU3xjXH7Ru276a2BpkHxJHbbuI4qFHhZqpR5k=; b=HgBZXSsct6QHoHefrfpMkpIgJsrmXEmSUkDE/hD50PjARnxSE0XxRxAm mOuvApGqXSKx85JNecrJ8510giXa/4jVgMhpOmdPew8ARGw9xoeBmB3mE a8eyUbtiw9aTvUwT21oh0MsrLvGdJ2GcjVptvEgOQllY5oDDjNYczZAZa 0u/6m3ge9IMvuZUqnrd/O1eshAcLW2PBJSQndEmwcNHSlhzJqZk6rbyQ5 NDv5D6ClBElZ3CehyEM8lr02YG26+tnnh1CqqSnRDojFXMFSIszhRZWDk ykb68q0GuAh37Qgh5TekIHBJyZRO74O+gR/V8IEfMRvPnN1XyVBPiHn7d w==; X-IronPort-AV: E=Sophos; i="5.28,462,1464678000"; d="scan'208,217"; a="18842556" Received: from unknown (HELO lvs-ipcld-01-data1.paypalcorp.com) ([10.185.246.167]) by lvs-ipout-02-data1.paypalcorp.com with ESMTP; 02 Aug 2016 14:50:06 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,462,1464678000"; d="scan'208,217";a="97094" X-CloudService: Office365 Received: from mail-by2nam01lp0184.outbound.protection.outlook.com (HELO NAM01-BY2-obe.outbound.protection.outlook.com) ([216.32.181.184]) by lvs-ipcld-01-data1.paypalcorp.com with ESMTP/TLS/AES256-SHA; 02 Aug 2016 14:48:21 -0700 Received: from SN1PR06MB2094.namprd06.prod.outlook.com (10.169.125.142) by SN1PR06MB2093.namprd06.prod.outlook.com (10.169.125.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 2 Aug 2016 21:50:03 +0000 Received: from SN1PR06MB2094.namprd06.prod.outlook.com ([10.169.125.142]) by SN1PR06MB2094.namprd06.prod.outlook.com ([10.169.125.142]) with mapi id 15.01.0549.022; Tue, 2 Aug 2016 21:50:05 +0000 From: "Hodges, Jeff" To: Brian Campbell Thread-Topic: [Unbearable] Base64url encoding in draft-ietf-tokbind-https Thread-Index: AQHR6ejZ1bxNaROhMUC5jHHU/swDI6A0RfmAgAAFf4CAAHOtAIAAhdGAgAB3igCAAAohgIAAADMA Date: Tue, 2 Aug 2016 21:50:05 +0000 Message-ID: References: <56260ABF-1B8A-41CB-BA16-0ACFFDE80097@me.com> <6FAE8287-E6E7-4E21-BFC9-60B948ABDB2D@me.com> <20160802010629.Horde.U7dIuq8Tpv2-SnvY3Dfd9ae@box514.bluehost.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.9.151119 authentication-results: spf=none (sender IP is ) smtp.mailfrom=jeff.hodges@paypal.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [172.56.6.111] x-ms-office365-filtering-correlation-id: e174cfcf-17e8-4903-b8c1-08d3bb1ef6ef x-microsoft-exchange-diagnostics: 1; SN1PR06MB2093; 6:EpIeu6cq+OCZdlD14FSDGsXWe/p+m7lLyPd4KNZ8GvamT8xpETOTQEfmMioMjlfTBYd5HTlgpQj2VQ7IfBfgvcP3ee7QS6ifmH6/uw7AqCmdgXgGuvo/Zsp0t+b28R3WCmOmmvd9VbCcXkbZnO2eL2NRLENwD3yMF142W+eZf0jlPssPSIpNlxycgJkioHopTb4Fv6125ut4uYoTSe2fNPvS8X21BFGW2VEOoPjjOJmMKMGiC32zHY+yiyL8q5bIUOWwUM9HfD+dV2MgidTamAxErrbDXmMTyEwzqsdgWPSp7w+h5FOxUXwtAxlndryo6zhgpDmOqJaS8HOrUKMFwA==; 5:9CIr+xdCT27HSGP2pVkXSl0aEl3W/b413LzhQwLm8nRpCwuVdQD0D5zaDgfMSPX61wfVZ5cIwfJI0XtVtYsx7cfaxhihl1xnDbLh15ozxZcOL4ClHc1vEHyC50sjahRUqj7Bj+HUHbTOla2OVRtVTA==; 24:fCHbfeJxTG39+1eAeXW6b8DQW4pZtcgFPzh+UJnRc2TpQaLlItUFHLRgxVRIZg2zdEW3XoX5YJ+uFkr1lwKR8vG0ph6BSRRKL/zgPoZc8Hw=; 7:4E60t+ZsO/mOckuC05hVFqX8tyfmWZoZ+QLeiI/L1N7Y1dfYtuFor4qIuaPRjGZlZGhnWrbPsRmy3WHJ9wL3RIBjYUFhJv/mv2HDEYSxaAVvG92+sLBHh9PjxkCGQG9vCftsUHSx12Z23YXqj6rRU6ZmTwKs8223LoBFweg54OtFJKaq7pq/DirLBxqwCzIpdOZqAtkl+y5gvcUwAH2ZJebSwOunjiTF+s6jjxV4qb+6kuu777La3n0V6W34IRWt x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR06MB2093; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(252895345309445)(188474585043545)(166708455590820)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026); SRVR:SN1PR06MB2093; BCL:0; PCL:0; RULEID:; SRVR:SN1PR06MB2093; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(24454002)(377454003)(230783001)(97736004)(586003)(2950100001)(2900100001)(122556002)(105586002)(82432001)(99286002)(4500500003)(19625215002)(106116001)(5002640100001)(36756003)(106356001)(87936001)(93886004)(189998001)(7736002)(8676002)(2906002)(83506001)(8666005)(4326007)(19580395003)(81156014)(7846002)(3846002)(92566002)(77096005)(3280700002)(73692002)(7906003)(68736007)(102836003)(19300405004)(10300500001)(6116002)(76176999)(81166006)(86362001)(8936002)(77072002)(54356999)(4001350100001)(66066001)(15975445007)(790700001)(101416001)(9686002)(19617315012)(110136002)(10130500003)(50986999)(16236675004)(10290500002)(10770500004)(19580405001)(10400500002)(3660700001)(56826009)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR06MB2093; H:SN1PR06MB2094.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: paypal.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D3C663CECE3F1jehodgespaypalcorpcom_" MIME-Version: 1.0 X-OriginatorOrg: paypal.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2016 21:50:05.4249 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: fb007914-6020-4374-977e-21bac5f3f4c8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR06MB2093 X-CFilter-Loop: Reflected Archived-At: Cc: IETF Tokbind WG , Dirk Balfanz , Andrei Popov , John Bradley Subject: Re: [Unbearable] Base64url encoding in draft-ietf-tokbind-https 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, 02 Aug 2016 21:50:10 -0000 --_000_D3C663CECE3F1jehodgespaypalcorpcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: "Michael.Jones@microsoft.com" > Date: Tuesday, August 2, 2016 at 7:50 AM To: Brian Campbell >, =3DJeffH > Cc: Tokbind WG >, "Hodges, = Jeff" >, Dirk Balfanz= >, Andrei Popov >, John Bradley > Subject: RE: [Unbearable] Base64url encoding in draft-ietf-tokbind-https +1 From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Brian Ca= mpbell Sent: Tuesday, August 2, 2016 7:14 AM To: Jeff Hodges > Cc: IETF Tokbind WG >; =3DJ= effH Hodges >; Dirk B= alfanz >; Andrei Popov >; John Bradley > Subject: Re: [Unbearable] Base64url encoding in draft-ietf-tokbind-https I just submitted pull request #57, which has proposed language for this (also copied below). The header field name is "Sec-Token-Binding" and its value is a base64url encoding of the TokenBindingMessage defined in [I-D.ietf-tokbind-protocol] using the URL- and filename-safe character set described in Section 5 of [RFC4648], with all trailing pad characters '=3D' omitted and without the inclusion of any line breaks, whitespace, or other additional characters. On Tue, Aug 2, 2016 at 1:06 AM, > wrote: Quoting Dirk Balfanz >: Can you guys propose some language how to make this more precise? And add that to https://github.com/TokenBinding/Internet-Drafts/issues/56 ? see: https://github.com/TokenBinding/Internet-Drafts/issues/56#issuecomment= -236815758 On Mon, Aug 1, 2016 at 9:13 AM John Bradley > wrote: Decoders will likely do the correct thing. However having one correct way to produce encoded token binding message will reduce confusion I suspect, it makes examples less ambiguous. John B. On Aug 1, 2016, at 11:53 AM, Brian Campbell > wrote: Most base64 decoders, I think, will happily handle both padded and unpadded input. So it probably doesn't matter all that much. But for consistency and marginal space savings, I'd be in favor of having HTTPSTB say to omit the padding. There's some language in a comment on https://github.com/TokenBinding/Internet-Drafts/issues/27 to that effect, which could be borrowed from, if desired. Most base64 encoders/decoders (nowadays?) also handle both the standard and the URL/filename safe alphabet. I don't really think there's value in an appendix like the one in RFC 7515. On Fri, Jul 29, 2016 at 4:30 PM, John Bradley > wrote: Brian Campbell has pointed out to me that in testing Chrome 54.0.2811.0 it is sending Sec-Token-Binding headers with padding. In https://tools.ietf.org/html/draft-ietf-tokbind-https-05#section-2 we say The header field name is "Sec-Token-Binding", and EncodedTokenBindingMessage is a base64url encoding (see [RFC4648] Section 5 ) of the TokenB= indingMessage as defined in [I-D.ietf-tokbind-protocol ] When we did JOSE we found RFC4648 a touch to vague on padding. in principal encoders and decoders will work both ways. However for interoperability and space saving we required the producer to send non padded to avoid confusion. We also added a appendix to help people with base64url without padding. https://tools.ietf.org/html/rfc7515#appendix-C Can the authors look at clarifying this, as written sending with or without padding is allowed by my reading. Including the appendix would also be fine with me if people think it would help clarify things for developers. Thanks. John B. _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable --_000_D3C663CECE3F1jehodgespaypalcorpcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
+1

From: "Michael.Jones@microsoft.com" <Michael.Jones@microsoft.com>=
Date: Tuesday, August 2, 2016 at 7:= 50 AM
To: Brian Campbell <bcampbell@pingidentity.com>, =3DJe= ffH <jeff.hodges@kingsm= ountain.com>
Cc: Tokbind WG <unbearable@ietf.org>, "Hodges, Jeff"= ; <Jeff.Hodges@PayPal.com&= gt;, Dirk Balfanz <balfanz@google.= com>, Andrei Popov <Andrei.Popo= v@microsoft.com>, John Bradley <jbradley@me.com>
Subject: RE: [Unbearable] Base64url= encoding in draft-ietf-tokbind-https

+1

&nbs= p;

From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Tuesday, August 2, 2016 7:14 AM
To: Jeff Hodges <jeff.hodges@kingsmountain.com>
Cc: IETF Tokbind WG <unbea= rable@ietf.org>; =3DJeffH Hodges <Jeff.Hodges@paypal.com>; Dirk Balfanz <balfanz@google.com>; Andrei Popov <Andrei.Popov@micro= soft.com>; John Bradley <jbrad= ley@me.com>
Subject: Re: [Unbearable] Base64url encoding in draft-ietf-tokbind-h= ttps

 

I just submitted pull request #57, which has proposed language for this (also copied bel= ow).

   The header field n= ame is "Sec-Token-Binding" and its value is a
   base64url encoding of the TokenBindingMessage defined in
   [I-D.ietf-tokbind-protocol] using the URL- and filename-safe    character set described in Section 5 of [RFC4648], with all tr= ailing
   pad characters '=3D' omitted and without the inclusion of any = line
   breaks, whitespace, or other additional characters.

 

On Tue, Aug 2, 2016 at 1:06 AM, <jeff.hodges@kingsmountai= n.com> wrote:


Quoting Dirk Balfanz <balfanz@google.com>:

Can you guys propose some language how to make this = more precise? And add
that to https://github.com/TokenBinding/Internet-Drafts/issues/56 ?<= /p>


see: https://github.com/TokenBinding/Internet-Drafts/issues/56#issuecomment-2368= 15758



On Mon, Aug 1, 2016 a= t 9:13 AM John Bradley <jbradley@me.com> wrote:

Decoders will likely = do the correct thing.  However having one correct way
to produce encoded token binding message will reduce confusion I suspect, it makes examples less ambiguous.

John B.

On Aug 1, 2016, at 11:53 AM, Brian Campbell <bcampbell@pingidentity.com>
wrote:

Most base64 decoders, I think, will happily handle both padded and
unpadded input.  So it probably doesn't matter all that much. But for<= br> consistency and marginal space savings, I'd be in favor of having HTTPSTB say to omit the padding. There's some language in a comment on
https://github.com/TokenBinding/Internet-Drafts/issues/27 = to that effect,
which could be borrowed from, if desired.

Most base64 encoders/decoders (nowadays?) also handle both the standard
and the URL/filename safe alphabet. I don't really think there's value in an appendix like the one in RFC 7515.

On Fri, Jul 29, 2016 at 4:30 PM, John Bradley <jbradley@me.com> wrote:

Brian Campbell has po= inted out to me that in testing Chrome 54.0.2811.0
it is sending Sec-Token-Binding headers with padding.

In https://tools.ietf.org/html/draft-ietf-tokbind-https-05#section-2 we say

 The header field name is "Sec-Token-Binding", and
   EncodedTokenBindingMessage is a base64url encoding (see [RFC46= 48]
   Section 5 <https://tools.ietf.org/html/rfc4648#section-5>) of the TokenBindingMessage as defined in
   [I-D.ietf-tokbind-protocol <https://tools.ietf.org/html/draft-ietf-tokbind-https-05#ref-I-D= .ietf-tokbind-protocol>]


When we did JOSE we found RFC4648
<https://tools.ietf.org/html/rfc4648#section-5> a touch to vague= on
padding.  in principal encoders and decoders will work both ways.
However for interoperability and space saving we required the producer to send non padded to avoid confusion.

We also added a appendix to help people with base64url without padding.
https://tools.ietf.org/html/rfc7515#appendix-C

Can the authors  look at clarifying this,  as written sending wit= h or
without padding is allowed by my reading.

Including the appendix would also be fine with me if people think it
would help clarify things for developers.

Thanks.

John B.

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

 



 

 --_000_D3C663CECE3F1jehodgespaypalcorpcom_-- From nobody Tue Aug 2 16:43: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 2057212DDD3 for ; Tue, 26 Jul 2016 07:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-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_HI=-5, 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 ItpfQmffCwpU for ; Tue, 26 Jul 2016 07:20:29 -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 9E5A812DDD1 for ; Tue, 26 Jul 2016 07:00:52 -0700 (PDT) Date: Tue, 26 Jul 2016 07:00:51 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1469541651; bh=3CLsuD4x9p8JtNqRURpryNByX7WvjqI7q2MUnriIG5o=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=b1qc+0sA+ttDit2/IiHptm1K2WEnV/JUHKbC5soVVH+3Dsppm5ArBAfRQlV+YyXyp oewv1bs2B4KRCn8BNfBqTHNzunUdsexKlrZY5lAI2wbkHJgzUpaeEmNcmmRpC8Bxxs cTTjqz4qMO/nGhZI2R5hA+w18rhwoUE0jwA00sxA= From: =JeffH To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57976d1351fad_1e753fe4fa45b2c08442d8"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: equalsJeffH X-GitHub-Recipient: unbearable-ML X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Tue, 02 Aug 2016 16:43:12 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] TBPROTO-09: address implementation/api guidance (#54) 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: Tue, 26 Jul 2016 14:20:34 -0000 ----==_mimepart_57976d1351fad_1e753fe4fa45b2c08442d8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > + Thus, Token Binding implementations providing an Application Programming Interface (API) should > + provide means for applications to produce Token Binding messages containing Token Binding values > + for application-specified TLS connections, > + such as by identifying the connections or by supplying the corresponding EKM values. > + > + > + The application needs to be able to denote the Token Binding type (e.g., provided, referred, etc.) > + to be used in the message for each specified connection (or EKM value), > + as well as the TLS connection the application will send the Token Binding message over. > + The result should be a Token Binding message containing Token Binding values > + bound to an application-specified TLS connection over which the Token Binding message is sent. > + Additionally, see , > + which provides further guidance regarding the use of this functionality. > + > + > + Thanks for making these mods, Mike! regarding the above section.. hmm, this spec is overall written in terms of "client", rather than "(web) user agent". E.g., the latter term is first introduced in the section preceding this one and occurs only a few times. So I think we can simplify the first paragraph accordingly. Plus, the second paragraph essentially repeats info that's in the first. how about the below build on the above? ``` HTTPS-based applications may have multi-party use cases other than, or in addition to, the HTTP redirect-based signaling-and-conveyance of referred token bindings, as presented above in . Thus, generic Token Binding implementations intended to support any HTTPS-based client-side application (e.g., so-called "native applications"), should provide means for applications to have Token Binding messages, containing Token Binding IDs of various application-specified Token Binding types and for application-specified TLS connections, conveyed over an application-specified HTTPS connection, i.e., within the TokenBindingMessage conveyed by the Sec-Token-Binding header field. See "", for privacy guidance regarding the use of this functionality. ``` [ fyi/fwiw, the markup for the NOTE is as I used in RFC6797 and passed muster with the rfc-editor ] --- 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/pull/54/files/71df58b4e95382123ec8bedd39b3f525171350a4#r72254548 ----==_mimepart_57976d1351fad_1e753fe4fa45b2c08442d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

In draft-ietf-tokbind-https-06.xml:

> +	Thus, Token Binding implementations providing an Application Programming Interface (API) should 
> +	provide means for applications to produce Token Binding messages containing Token Binding values
> +	for application-specified TLS connections,
> +	such as by identifying the connections or by supplying the corresponding EKM values.
> +      </t>
> +      <t>
> +	The application needs to be able to denote the Token Binding type (e.g., provided, referred, etc.)
> +	to be used in the message for each specified connection (or EKM value),
> +	as well as the TLS connection the application will send the Token Binding message over.
> +	The result should be a Token Binding message containing Token Binding values
> +	bound to an application-specified TLS connection over which the Token Binding message is sent.
> +	Additionally, see <xref target="privacy-cons"/> <xref target="privacy-cons" format="title"/>,
> +	which provides further guidance regarding the use of this functionality.
> +      </t>
> +    </section>
> +

Thanks for making these mods, Mike!

regarding the above section..

hmm, this spec is overall written in terms of "client", rather than "(web) user agent". E.g., the latter term is first introduced in the section preceding this one and occurs only a few times. So I think we can simplify the first paragraph accordingly. Plus, the second paragraph essentially repeats info that's in the first.

how about the below build on the above?

<t>
  HTTPS-based applications may have multi-party use 
  cases other than, or in addition to, the HTTP redirect-based 
  signaling-and-conveyance of referred token bindings, as 
  presented above in <xref target="sctn-http-redir">.
</t>
<t>
  Thus, generic Token Binding implementations intended to support 
  any HTTPS-based client-side application (e.g., so-called "native 
  applications"), should provide means for applications to have 
  Token Binding messages, containing Token Binding IDs of various 
  application-specified Token Binding types and 
  for application-specified TLS connections, conveyed over an
  application-specified HTTPS connection, i.e., within the 
  TokenBindingMessage conveyed by the Sec-Token-Binding header
  field. 
  <list style="hanging" hangIndent="7">
    <t hangText="NOTE:">
      See <xref target="privacy-cons"/> 
      "<xref target="privacy-cons" format="title"/>",
      for privacy guidance regarding the use of 
      this functionality.
     </t>
  </list>
</t>

[ fyi/fwiw, the markup for the NOTE is as I used in RFC6797 and passed muster with the rfc-editor ]

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

----==_mimepart_57976d1351fad_1e753fe4fa45b2c08442d8-- From nobody Tue Aug 2 16:43:19 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 9BC9312DD36 for ; Tue, 26 Jul 2016 08:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_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 q-K1EEKkNres for ; Tue, 26 Jul 2016 08:15:21 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B288712DD39 for ; Tue, 26 Jul 2016 07:40:54 -0700 (PDT) Date: Tue, 26 Jul 2016 07:40:51 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1469544052; bh=Eh9UDeYsLcJN28lbuT5zZXl/CayBXHBVZgOBByT1Dfo=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=CQFkp+spF/sDuC19MK42ci8gU1Abr01vmFq4k3GGYmbZgMdjLyP1qquY19DGJBy2P eqyC1keODeu4Tl0slIq2on7sD8v0oXo3fevFWMIaOaJuyVM0tUc7KMVuSfpDvIwuuD fnaood0kBwoVetnt9T6YDsxjxc300BNJWxf++NuI= From: =JeffH To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57977673e146d_77f93fce9e23b2a07326bb"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: equalsJeffH X-GitHub-Recipient: unbearable-ML X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Tue, 02 Aug 2016 16:43:12 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] TBPROTO-09: address implementation/api guidance (#54) 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: Tue, 26 Jul 2016 15:15:24 -0000 ----==_mimepart_57977673e146d_77f93fce9e23b2a07326bb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > + also having Token Binding information for these connections > + does not provide additional correlation information. > + However, if not, by providing Token Bindings, > + then there is potential to expose additional information > + that could be used to correlate the endpoints that different parties are communicating with. > + In these cases, a privacy analysis of correlations enabled > + and the potential privacy impacts of those correlations should be performed > + as part of the decision whether to utilize token binding in those cases. > + > + > + Care should be taken to ensure that unrelated applications cannot obtain information > + about each other's Token Bindings. > + For instance, a Token Binding implementation shared between multiple applications on a machine > + should prevent unrelated applications from seeing each other's Token Binding information. > + Application isolation and key segregation should be used to prevent this. > + wordsmith suggestions on the above two paragraphs... An application's communicating parties, that receive Token Bindings for TLS connections other than their own, obtain information about the application's other TLS connections. The Token Binding IDs in these other Token Bindings can serve as correlation handles for the endpoints of the other connections. If the application is already aware of these other connections, then no additional information is being exposed. For instance, if in a redirect-based federation protocol, the Identity Provider and Relying Party already have URLs for one another, also having Token Binding information for these connections does not provide additional correlation information. If not, then by providing the other Token Bindings there is potential to expose additional information that can be used to correlate the endpoints the other parties are communicating with. In such cases, a privacy analysis of enabled correlations and their potential privacy impacts should be performed as part of the application design decisions of how, and whether, to utilize Token Bindings. Also, care should be taken to ensure that unrelated applications cannot obtain information about each other's Token Bindings. For instance, a Token Binding implementation shared between multiple applications on a given system should prevent unrelated applications from obtaining each other's Token Binding information. This may be accomplished by using techniques such as application isolation and key segregation, depending upon system capabilities. HTH, =JeffH --- 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/pull/54/files/71df58b4e95382123ec8bedd39b3f525171350a4#r72262727 ----==_mimepart_57977673e146d_77f93fce9e23b2a07326bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

In draft-ietf-tokbind-https-06.xml:

> +	  also having Token Binding information for these connections
> +	  does not provide additional correlation information.
> +	  However, if not, by providing Token Bindings,
> +	  then there is potential to expose additional information
> +	  that could be used to correlate the endpoints that different parties are communicating with.
> +	  In these cases, a privacy analysis of correlations enabled
> +	  and the potential privacy impacts of those correlations should be performed
> +	  as part of the decision whether to utilize token binding in those cases.
> +	</t>
> +	<t>
> +	  Care should be taken to ensure that unrelated applications cannot obtain information
> +	  about each other's Token Bindings.
> +	  For instance, a Token Binding implementation shared between multiple applications on a machine
> +	  should prevent unrelated applications from seeing each other's Token Binding information.
> +	  Application isolation and key segregation should be used to prevent this.
> +	</t>

wordsmith suggestions on the above two paragraphs...


An application's communicating parties, that receive Token Bindings for TLS connections other than their own, obtain information about the application's other TLS connections. The Token Binding IDs in these other Token Bindings can serve as correlation handles for the endpoints of the other connections.
If the application is already aware of these other connections, then no additional information is being exposed. For instance, if in a redirect-based federation protocol, the Identity Provider and Relying Party already have URLs for one another, also having Token Binding information for these connections does not provide additional correlation information.
If not, then by providing the other Token Bindings there is potential to expose additional information that can be used to correlate the endpoints the other parties are communicating with.
In such cases, a privacy analysis of enabled correlations and their potential privacy impacts should be performed as part of the application design decisions of how, and whether, to utilize Token Bindings.


Also, care should be taken to ensure that unrelated applications cannot obtain information about each other's Token Bindings. For instance, a Token Binding implementation shared between multiple applications on a given system should prevent unrelated applications from obtaining each other's Token Binding information. This may be accomplished by using techniques such as application isolation and key segregation, depending upon system capabilities.

HTH,

=JeffH

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

----==_mimepart_57977673e146d_77f93fce9e23b2a07326bb-- From nobody Tue Aug 2 16:43: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 47A1912D8AC for ; Fri, 29 Jul 2016 13:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.908 X-Spam-Level: X-Spam-Status: No, score=-5.908 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, 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 f5O03PlvoT0K for ; Fri, 29 Jul 2016 13:39:42 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C8B12D88A for ; Fri, 29 Jul 2016 13:39:42 -0700 (PDT) Date: Fri, 29 Jul 2016 13:39:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1469824782; bh=6L8RAeZXx+bHixjZ6yIUbGCLhF4T1G68//qsDI7RHRg=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=Wtu9aO4ItLC2k60KM1r0DDudSU10muEu8bAQLlTKkrN4ZkOv2YVdiMiyJZlc6TZH+ 6NeAfTZ8Gr7FKwB3ggIpQ/+3ibCXQSMmZf1mS7WYIHbW0UWYyPr0Tk4rctyiNBIIq0 PkoyqLO9ADwN4Iv3/cSKz8BFdBRd8xNNevidmyGY= From: Brian Campbell To: TokenBinding/Internet-Drafts Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_579bbf0e1a4f3_36493f9a9a4f92b8822be"; 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: Tue, 02 Aug 2016 16:43:12 -0700 Subject: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: clarify that browser sends referred TB even when eTLD+1 is the same (#55) 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, 29 Jul 2016 20:39:44 -0000 ----==_mimepart_579bbf0e1a4f3_36493f9a9a4f92b8822be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit see https://www.ietf.org/mail-archive/web/unbearable/current/msg00618.html and followup https://www.ietf.org/mail-archive/web/unbearable/current/msg00619.html --- 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/55 ----==_mimepart_579bbf0e1a4f3_36493f9a9a4f92b8822be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

see https://www.ietf.org/mail-archive/web/unbearable/current/msg00618.html and followup https://www.ietf.org/mail-archive/web/unbearable/current/msg00619.html

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

----==_mimepart_579bbf0e1a4f3_36493f9a9a4f92b8822be-- From nobody Tue Aug 2 16:43:29 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 59A4312D7BB for ; Mon, 1 Aug 2016 16:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.941 X-Spam-Level: X-Spam-Status: No, score=-4.941 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_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 O6kbsf9JwOd9 for ; Mon, 1 Aug 2016 16:07:18 -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 7D53B12D800 for ; Mon, 1 Aug 2016 16:07:15 -0700 (PDT) Date: Mon, 01 Aug 2016 16:07:14 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470092834; bh=Fhxw/QoLxu8ITSiqdcD38g187w/I+jeq/lj//nulkJI=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=B1590elY+Y4uqmpBe/G3F2Yoopcgl6Uo+m+z7SNnI2KAbRbgbL9bmb//ZYKSOeeOj LPRkU9SGaMjJ9YCNRdhwPYY35yt6XSWJpI6d9qbjUnGFnVvBivahiL5XS4n1SbC2Jj IxFZibRFxXZEzlJSbIYoPxicrDFndn3/1L8wdGzU= From: balfanz To: TokenBinding/Internet-Drafts Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_579fd6229c0af_5b2a3fc1299d52b8185590"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: balfanz X-GitHub-Recipient: unbearable-ML X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Tue, 02 Aug 2016 16:43:12 -0700 Subject: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: Clarify that base64url encoding means no padding. (#56) 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, 01 Aug 2016 23:07:19 -0000 ----==_mimepart_579fd6229c0af_5b2a3fc1299d52b8185590 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit We should clarify that the Sec-Token-Binding header shouldn't have any padding appended as part of the base64 encoding. --- 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/56 ----==_mimepart_579fd6229c0af_5b2a3fc1299d52b8185590 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

We should clarify that the Sec-Token-Binding header shouldn't have any padding appended as part of the base64 encoding.

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

----==_mimepart_579fd6229c0af_5b2a3fc1299d52b8185590-- From nobody Tue Aug 2 16:43: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 E57E612B035 for ; Mon, 1 Aug 2016 23:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.908 X-Spam-Level: X-Spam-Status: No, score=-5.908 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, 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 zXdtD9UKjuHY for ; Mon, 1 Aug 2016 23:30:04 -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 6F5BB12B004 for ; Mon, 1 Aug 2016 23:30:04 -0700 (PDT) Date: Mon, 01 Aug 2016 23:30:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470119403; bh=yK7YnR6NMMAJbu+8xYgrK4AogkF4iQj2c1zzJvBpzSI=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=APH2TB0NiH2Fe05rPWzlNsHWnqyXUccw704ebXVbLCtLpe9ajVYCsnPQ1MSVE9ha0 pXSkAOsBk4WIHXO+AgNtFQzscfBbtom0ocEsN6N0WyrXJSzm5LP9EgsWxnJ9N5dLej ZFH37GZ8cUb9bBGBeXNw5y++mjGCaNYVThhbj3P0= From: =JeffH To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57a03deb8c93f_4f903fdc6a4252bc46751"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: equalsJeffH X-GitHub-Recipient: unbearable-ML X-GitHub-Reason: push X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Tue, 02 Aug 2016 16:43:12 -0700 Cc: Push Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] TBPROTO-09: address implementation/api guidance (#54) 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: Tue, 02 Aug 2016 06:30:06 -0000 ----==_mimepart_57a03deb8c93f_4f903fdc6a4252bc46751 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @equalsJeffH pushed 1 commit. 448a276 build upon language in HTTPSTB impl cons & priv cons --- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/TokenBinding/Internet-Drafts/pull/54/files/71df58b4e95382123ec8bedd39b3f525171350a4..448a276e23f9c4e94dcd00f90237204f0bd6d617 ----==_mimepart_57a03deb8c93f_4f903fdc6a4252bc46751 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@equalsJeffH pushed 1 commit.

  • 448a276 build upon language in HTTPSTB impl cons & priv cons

—
You are receiving this because you are subscribed to this thread.
View it on GitHub or mute the thread.

----==_mimepart_57a03deb8c93f_4f903fdc6a4252bc46751-- From nobody Tue Aug 2 16:43: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 001A712D0AD for ; Mon, 1 Aug 2016 23:35:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.908 X-Spam-Level: X-Spam-Status: No, score=-5.908 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, 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 so4eBo3_RYX6 for ; Mon, 1 Aug 2016 23:35:39 -0700 (PDT) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext5.iad.github.net [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A47712B004 for ; Mon, 1 Aug 2016 23:35:39 -0700 (PDT) Date: Mon, 01 Aug 2016 23:35:38 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470119738; bh=StB3BK+GYqBxwEWd7YcxNxCHQn4qBCoEr4SO7CbDWZY=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=SbtGthCWvk9Aqaor61Axz5dNE/601DypECE0GNbz0n4vGgS1/VlbH3FrboDB4yq7L V0FIkbeojlmqjN8cYIHHvNcIOJ4Za/DJSoICpGVDRKZlHdn/PUZhcUiugYa1yeIe5v 5UFP5/9p2uOpw2+TDOEvM1wGcn/lbEdm5zLjNOP8= From: =JeffH To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57a03f3ad5233_12043fbbc28492bc175822"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: equalsJeffH X-GitHub-Recipient: unbearable-ML X-GitHub-Reason: push X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Tue, 02 Aug 2016 16:43:12 -0700 Cc: Push Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] TBPROTO-09: address implementation/api guidance (#54) 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: Tue, 02 Aug 2016 06:35:41 -0000 ----==_mimepart_57a03f3ad5233_12043fbbc28492bc175822 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @equalsJeffH pushed 1 commit. fb333e9 fix up line breaks to be readable in github diff --- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/TokenBinding/Internet-Drafts/pull/54/files/448a276e23f9c4e94dcd00f90237204f0bd6d617..fb333e90a8f38d536472972d376202955ae90ce7 ----==_mimepart_57a03f3ad5233_12043fbbc28492bc175822 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@equalsJeffH pushed 1 commit.

  • fb333e9 fix up line breaks to be readable in github diff

—
You are receiving this because you are subscribed to this thread.
View it on GitHub or mute the thread.

----==_mimepart_57a03f3ad5233_12043fbbc28492bc175822-- From nobody Tue Aug 2 16:43: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 EDF9712B004 for ; Mon, 1 Aug 2016 23:48:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.908 X-Spam-Level: X-Spam-Status: No, score=-5.908 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, 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 UQNMfODHmHq4 for ; Mon, 1 Aug 2016 23:48:03 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C15B9128E18 for ; Mon, 1 Aug 2016 23:48:03 -0700 (PDT) Date: Mon, 01 Aug 2016 23:48:03 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470120483; bh=ijNIqiP4GBCmIMewTtvDqjFoDnt185ekJJawMC053i8=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Ya7j5EspGTSGuBAbWG9sIpqeO2+8BQYOb7bBAmP8hyo48O65n6dXunyqQkMKrKpIA AGg71vkhe4WbCzG//7NUj1BALr9jm5DLy3i5AakD/5VVz3o2p6JK9Gln71fcGgCekS +EMmx/xlLEcyIArfMgpEcBUcMImXDiR84UXZyqA4= From: =JeffH To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57a04223208a4_11e43fbbc28492bc2812a4"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: equalsJeffH X-GitHub-Recipient: unbearable-ML X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Tue, 02 Aug 2016 16:43:12 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: Clarify that base64url encoding means no padding. (#56) 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: Tue, 02 Aug 2016 06:48:05 -0000 ----==_mimepart_57a04223208a4_11e43fbbc28492bc2812a4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit how about the language proposed by @b---c here: https://github.com/TokenBinding/Internet-Drafts/issues/27#issuecomment-217980935 ? --- 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/56#issuecomment-236815758 ----==_mimepart_57a04223208a4_11e43fbbc28492bc2812a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

how about the language proposed by @b---c here: #27 (comment) ?

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

----==_mimepart_57a04223208a4_11e43fbbc28492bc2812a4-- From nobody Tue Aug 2 16:43:41 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 1323512D744 for ; Tue, 2 Aug 2016 07:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 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_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 wgNRul8mNkqQ for ; Tue, 2 Aug 2016 07:09:28 -0700 (PDT) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext8.iad.github.net [192.30.252.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F5212D73C for ; Tue, 2 Aug 2016 07:09:28 -0700 (PDT) Date: Tue, 02 Aug 2016 07:09:26 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470146967; bh=PQkS33LESuAiKfD5tsBAt7MN4IDnA+oq+4lWjEXJngk=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=z8+LsXuhM2BAly3/u/SE+9BzUEqlK0DtHI85NGnRvM0wAb+GtZGMQoSHgu04sLHdu G+KoBmOXrAeS7UMmrHfpxULwjp3EFHNbnzOM49/9P9l2Ym80lJu3QY6YvZHWpZFj+s OJLTQcHhBQUMd/UUnuoTS6Si/4eVhF3B7QhXWxSg= From: Brian Campbell To: TokenBinding/Internet-Drafts Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57a0a996ea5dd_16d73fdd77acb2c0133324"; 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: Tue, 02 Aug 2016 16:43:12 -0700 Subject: [Unbearable] [TokenBinding/Internet-Drafts] clarify in HTTPSTB that base64url encoding means no padding, etc. (#57) 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: Tue, 02 Aug 2016 14:09:34 -0000 ----==_mimepart_57a0a996ea5dd_16d73fdd77acb2c0133324 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit for #56 clarify in HTTPSTB that base64url encoding means no padding, no line breaks, no whitespace, etc. You can view, comment on, or merge this pull request online at: https://github.com/TokenBinding/Internet-Drafts/pull/57 -- Commit Summary -- * arify in HTTPSTB that base64url encoding means no padding, no line breaks, etc. -- File Changes -- M draft-ietf-tokbind-https-05.xml (16) -- Patch Links -- https://github.com/TokenBinding/Internet-Drafts/pull/57.patch https://github.com/TokenBinding/Internet-Drafts/pull/57.diff --- 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/pull/57 ----==_mimepart_57a0a996ea5dd_16d73fdd77acb2c0133324 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

for #56 clarify in HTTPSTB that base64url encoding means no padding, no line breaks, no whitespace, etc.

You can view, comment on, or merge this pull request online at:

  https://github.com/TokenBinding/Internet-Drafts/pull/57

Commit Summary

  • arify in HTTPSTB that base64url encoding means no padding, no line breaks, etc.

File Changes

Patch Links:

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

----==_mimepart_57a0a996ea5dd_16d73fdd77acb2c0133324-- From nobody Tue Aug 2 16:43:43 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 1287412D750 for ; Tue, 2 Aug 2016 07:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.454 X-Spam-Level: X-Spam-Status: No, score=-5.454 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, 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 U4eHDbyxya5e for ; Tue, 2 Aug 2016 07:21:30 -0700 (PDT) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext5.iad.github.net [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DCAD12D74B for ; Tue, 2 Aug 2016 07:21:30 -0700 (PDT) Date: Tue, 02 Aug 2016 07:21:29 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470147689; bh=asfAXEhp8oGcZwYLLOADWyN7iO8fiozhXZrLZP9pMeo=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=1yhvMZMqDggucMuBHEqVMAhdDpNpA4jviSXrDKMfjmCYmWL22Og1SvzknJJ242jQH JBlzKUeOTrQhOVR0rsfrh+Z3yFokUvPX/E7/RR5XRyqWWe9E+4+/BYhioy0oVMKZP2 fGUE4IG5gqxLqfIBElTFehd+xdYwDvFWVYbEMC9s= From: Brian Campbell To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57a0ac6962c45_23fa3f9f37fe129c4269f0"; 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: Tue, 02 Aug 2016 16:43:12 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: Clarify that base64url encoding means no padding. (#56) 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: Tue, 02 Aug 2016 14:21:35 -0000 ----==_mimepart_57a0ac6962c45_23fa3f9f37fe129c4269f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit PR #57 has language very similar to what was suggested in the comment on issue #27 --- 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/56#issuecomment-236919436 ----==_mimepart_57a0ac6962c45_23fa3f9f37fe129c4269f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

PR #57 has language very similar to what was suggested in the comment on issue #27

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

----==_mimepart_57a0ac6962c45_23fa3f9f37fe129c4269f0-- From nobody Tue Aug 2 16:43: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 9F9AB12B02E for ; Tue, 2 Aug 2016 09:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 a-s1DVDk7sTh for ; Tue, 2 Aug 2016 09:44:14 -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 EBF7012B010 for ; Tue, 2 Aug 2016 09:44:13 -0700 (PDT) Date: Tue, 02 Aug 2016 09:44:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470156252; bh=oEqDsyhctMhWEra3EUjubVaRw9fU5MovJ5BtNwYXJ0w=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=yGa3qtH52sk8HJM1L1UXIlHzFpzCXnTzqQTNndPe3vwKKwTAxP5rOBQDgMwTSSBEl 0iXEDtdBwq3XelZz2wse12gGfNqHkbUH2WzwHi+vXulGeUbn+cvwCXaABPiIGFHNKU noLPhKuhnJa4T0itzwNh9rDp1cBg/O55i05sKIpE= From: Nick Harper To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57a0cddcd2d82_25da3fa6c54512c01556b9"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: nharper X-GitHub-Recipient: unbearable-ML X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Tue, 02 Aug 2016 16:43:12 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] TBPROTO-09: address implementation/api guidance (#54) 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: Tue, 02 Aug 2016 16:44:15 -0000 ----==_mimepart_57a0cddcd2d82_25da3fa6c54512c01556b9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit > @@ -937,6 +965,42 @@ contexts. Other approaches are possible, but are outside the scope of this speci > mechanisms. > > > +
> + > + An application's communicating parties, that receive > + Token Bindings for TLS connections other than their own, > + obtain information about the application's other TLS > + connections. > + The Token Binding IDs in these other Token Bindings can > + serve as correlation handles for > + the endpoints of the other connections. > + If the application is already aware of these other > + connections, then no additional information is being exposed. I'm still confused here. Is the application something like a native app, which is acting as an https client? Are these "other connections" ones that the application makes? If both of those are true, then it's trivial to see that the application is always aware of these other connections. However, I suppose that's not what this means, so I'm wondering what the definitions are of "the application" and "other connections". --- 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/pull/54/files/fb333e90a8f38d536472972d376202955ae90ce7#r73192044 ----==_mimepart_57a0cddcd2d82_25da3fa6c54512c01556b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

In draft-ietf-tokbind-https-06.xml:

> @@ -937,6 +965,42 @@ contexts. Other approaches are possible, but are outside the scope of this speci
>            mechanisms.
>          </t>
>        </section>
> +        <section title="Correlation" anchor="Correlation">
> +          <t>
> +            An application's communicating parties, that receive 
> +            Token Bindings for TLS connections other than their own, 
> +            obtain information about the application's other TLS 
> +            connections.
> +            The Token Binding IDs in these other Token Bindings can 
> +            serve as correlation handles for
> +            the endpoints of the other connections.
> +            If the application is already aware of these other 
> +            connections, then no additional information is being exposed.

I'm still confused here. Is the application something like a native app, which is acting as an https client? Are these "other connections" ones that the application makes? If both of those are true, then it's trivial to see that the application is always aware of these other connections. However, I suppose that's not what this means, so I'm wondering what the definitions are of "the application" and "other connections".

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

----==_mimepart_57a0cddcd2d82_25da3fa6c54512c01556b9-- From nobody Tue Aug 2 16:43:48 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 3B05712D694 for ; Tue, 2 Aug 2016 10:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 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_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 nr7J_5_ef2QJ for ; Tue, 2 Aug 2016 10:10:48 -0700 (PDT) Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7061E12B05B for ; Tue, 2 Aug 2016 10:10:48 -0700 (PDT) Date: Tue, 02 Aug 2016 10:10:47 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470157847; bh=ckrqKpG8SOczR46AmfNBXsJRy2am6RSg4UshclMY2WA=; h=From:Reply-To:To:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=drKvmd6Do53okh3Z4QNw8/mQXYx1QSQ3e/orIF2d7sW5dkTlS0+xHR6kBeLyJ5xBJ h0NgW9lDyJIXGrPpma4Cc4MvE0ZJrk9JvVvGm2vK+xcph17a8DMWjzNze/vRp/enSQ VJtDxGxvLMGJC8fNcrSwx3YMj0Z4Y/+SZ5kycGWE= From: Brian Campbell To: TokenBinding/Internet-Drafts Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57a0d417765bc_496b3f81f53ef2b81800d6"; 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: Tue, 02 Aug 2016 16:43:12 -0700 Subject: [Unbearable] [TokenBinding/Internet-Drafts] TBNEGO can/should indicate 24 for the token_binding extension type value (#58) 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: Tue, 02 Aug 2016 17:10:50 -0000 ----==_mimepart_57a0d417765bc_496b3f81f53ef2b81800d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit IANA did early assignment of 24 for the token_binding TLS extension so TBNEGO can and should use it (borrowed language from the IANA Considerations of RFC 7627) You can view, comment on, or merge this pull request online at: https://github.com/TokenBinding/Internet-Drafts/pull/58 -- Commit Summary -- * IANA did early assignment of 24 for the token_binding TLS extension so TBNEGO can and should use it (borrowed language from the IANA Considerations of RFC 7627) -- File Changes -- M draft-ietf-tokbind-negotiation-03.xml (10) -- Patch Links -- https://github.com/TokenBinding/Internet-Drafts/pull/58.patch https://github.com/TokenBinding/Internet-Drafts/pull/58.diff --- 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/pull/58 ----==_mimepart_57a0d417765bc_496b3f81f53ef2b81800d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

IANA did early assignment of 24 for the token_binding TLS extension so TBNEGO can and should use it (borrowed language from the IANA Considerations of RFC 7627)

You can view, comment on, or merge this pull request online at:

  https://github.com/TokenBinding/Internet-Drafts/pull/58

Commit Summary

  • IANA did early assignment of 24 for the token_binding TLS extension so TBNEGO can and should use it (borrowed language from the IANA Considerations of RFC 7627)

File Changes

Patch Links:

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

----==_mimepart_57a0d417765bc_496b3f81f53ef2b81800d6-- From nobody Tue Aug 2 16:43: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 7300612B054 for ; Tue, 2 Aug 2016 14:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.454 X-Spam-Level: X-Spam-Status: No, score=-5.454 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, 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 lnSkggxjXjlI for ; Tue, 2 Aug 2016 14:49:06 -0700 (PDT) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext5.iad.github.net [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B4612B009 for ; Tue, 2 Aug 2016 14:49:06 -0700 (PDT) Date: Tue, 02 Aug 2016 14:49:05 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470174545; bh=w1hOQMKStBGHoQkuPvcV018Pe9LxQOGLLg2dP/qiimY=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Z9L4atqmXanj6tIYYpQL60zEYO/HT8CacgAFfbxKfAnG1ih3QbgHP0WpYKDlPSbJn qSX5fWCqZJeD0buzXaAI2Mgs+8VuIO7Bbxf0SxvW+t3McBLTvkQr/ECA0j22ftOaaw s09mqCTREUVdezRXIQkV3HrB4IeikOPl4agug358= From: =JeffH To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57a1155111eaa_60ce3feead7b529c178136"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: equalsJeffH X-GitHub-Recipient: unbearable-ML X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Tue, 02 Aug 2016 16:43:12 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] clarify in HTTPSTB that base64url encoding means no padding, etc. (#57) 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: Tue, 02 Aug 2016 21:49:07 -0000 ----==_mimepart_57a1155111eaa_60ce3feead7b529c178136 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit looks good to me, thanks Brian. --- 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/pull/57#issuecomment-237056229 ----==_mimepart_57a1155111eaa_60ce3feead7b529c178136 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

looks good to me, thanks Brian.

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

----==_mimepart_57a1155111eaa_60ce3feead7b529c178136-- From nobody Tue Aug 2 16:48: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 8C01512D5C0 for ; Tue, 2 Aug 2016 16:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.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 bYpKMsIxuv9T for ; Tue, 2 Aug 2016 16:48:25 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 484C112B015 for ; Tue, 2 Aug 2016 16:48:25 -0700 (PDT) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u72NjjGR004243 for ; Tue, 2 Aug 2016 16:48:25 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : content-type : mime-version; s=facebook; bh=lnxpqZ9Piub6tUdjDpZNZjQBw8BT4jXzQ4+ywW8LHZ8=; b=kkN/vR9+ysvWWwGYvh7bGW3f1PEoLo/CnXVysEkOiqSht2q4gOxcQruH3Cq7IXZ/E5wV Ncr33ZRxP/GR8eHs4RFTxdyfNtxhNAmGq2GUDTSBbHmvFsvSdshL3FGTMqfUekQsSbEn 1h2xd2ykQSuea53orTJCnPxD9mNsEgFDzak= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 24k4qur99a-13 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 02 Aug 2016 16:48:25 -0700 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.29]) by PRN-CHUB10.TheFacebook.com ([fe80::c983:d64f:e422:461d%12]) with mapi id 14.03.0294.000; Tue, 2 Aug 2016 16:47:27 -0700 From: Subodh Iyengar To: "unbearable@ietf.org" Thread-Topic: migrations of token bindings Thread-Index: AdHtGANk8YhqkfT0RKqstDH3Uk+wIQ== Date: Tue, 2 Aug 2016 23:47:26 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E99565A9DF7@PRN-MBX01-4.TheFacebook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_974CF78E8475CD4CA398B1FCA21C8E99565A9DF7PRNMBX014TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-02_18:, , signatures=0 Archived-At: Subject: [Unbearable] migrations of token bindings 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, 02 Aug 2016 23:48:26 -0000 --_000_974CF78E8475CD4CA398B1FCA21C8E99565A9DF7PRNMBX014TheFac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Davidben and I were chatting during IETF Berlin about token bindings and we= discussed some interesting issues around token bindings and migrations. 2 cases come to my mind: * For example let's say Server 1 negotiates key parameters ecdsa and establ= ishes a token binding with ecdsa params, however the relying party for a re= ferred token binding only supports pkcs1.5. * A new token binding type is added for example eddsa and the server wants = to migrate it's existing ecdsa token binding to an eddsa token binding. One way to migrate token bindings comes to mind but it's super nasty. For e= xample let's say Server 1 runs on origin server.com which has the original = bindings. You could have Server 1 create a new domain migration.server.com = (which supports both ecdsa and pkcs1.5) and then server.com could 302 to mi= gration.server.com with a referred token binding. This is really painful to= migrate and probably impractical for many services. However I think there might be a more elegant solution. One proposal could = be to change the server token binding extension to be allowed to specify mu= ltiple supported token bindings instead of requiring just one. This will al= low the server to negotiate not only ecdsa but also pkcs1.5 token bindings = and store them together. This would make migration easier. For example if s= erver only supported ecdsa initially and had token binding id =3D A initial= ly, and needed to support a new party which supported pkcs1.5, it would adv= ertise support for both. Then the client would send it 2 bindings A and B w= hich it can store together. Has this problem been discussed before? Subodh --_000_974CF78E8475CD4CA398B1FCA21C8E99565A9DF7PRNMBX014TheFac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Davidben and I were chatting d= uring IETF Berlin about token bindings and we discussed some interesting is= sues around token bindings and migrations. 

2 cases come to my mind:
* For example let's say Server 1 negot= iates key parameters ecdsa and establishes a token binding with ecdsa param= s, however the relying party for a referred token binding only supports pkc= s1.5. 

* A new token binding type is added fo= r example eddsa and the server wants to migrate it's existing ecdsa token b= inding to an eddsa token binding. 

One way to migrate token bindings come= s to mind but it's super nasty. For example let's say Server 1 runs on orig= in server.com which has the original bindings. You could have Server 1 crea= te a new domain migration.server.com (which supports both ecdsa and pkcs1.5) and then server.com could 302 to m= igration.server.com with a referred token binding. This is really painful t= o migrate and probably impractical for many services.  

However I think there might be a more = elegant solution. One proposal could be to change the server token binding = extension to be allowed to specify multiple supported token bindings instea= d of requiring just one. This will allow the server to negotiate not only ecdsa but also pkcs1.5 token bindin= gs and store them together. This would make migration easier. For example i= f server only supported ecdsa initially and had token binding id =3D A init= ially, and needed to support a new party which supported pkcs1.5, it would advertise support for both. Then t= he client would send it 2 bindings A and B which it can store together.&nbs= p;

Has this problem been discussed before= ?

Subodh
--_000_974CF78E8475CD4CA398B1FCA21C8E99565A9DF7PRNMBX014TheFac_-- From nobody Tue Aug 2 17:27: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 1B74D12B03D for ; Tue, 2 Aug 2016 17:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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.287, 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 z-2_RXjtEiGY for ; Tue, 2 Aug 2016 17:27:16 -0700 (PDT) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::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 F1F1012B05A for ; Tue, 2 Aug 2016 17:27:15 -0700 (PDT) Received: by mail-vk0-x230.google.com with SMTP id w127so135038505vkh.2 for ; Tue, 02 Aug 2016 17:27:15 -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=kc1u3eNm7/o9B8Aklm1n+TdSizNrorRIUDSN7cmoN34=; b=OJRcZh6edzBEv6hZsGlTx7P31IPj5Z9ia247hyQhubxRdnYECym5X2R470DP2DA0J9 xyUkJKhKwSIJZUuUCuRtNCM0kuKKQp+tpv5d4TiyMkPD8wFgp5NYPAfNetgnX/ZV7iJd AYiQly+G69UzhEx+7BfSmzlp1IrPSruxbamWTRc2ejYlb501HF+WhadV4XAu8dQk7lT8 OXJESrjuD3umghlpFFSmKjwMkvUojxH1pLUntluzT6cq2JX7zDCpFsV6ePEwgskiSLoa nEU7ljaTzd9dpQjuqP862TRKlt5HP8EHpDO/HxIlcpt3SBP8Wm+Qf2pIT7yxHYn+WAIX kEbQ== 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=kc1u3eNm7/o9B8Aklm1n+TdSizNrorRIUDSN7cmoN34=; b=i02cOoWBjFKFxARzQcV+UtKtSWl7/0YxU+iRuSPzVA0Q12phNVZTSlk0t5hZA1xzEf lcP63ZAkVMz8px9YggabmazddMyPSJBg2JXLpn+ItAVQenx1mS9pU3XE/LB3ZNeRHI9K fTKXIS6aYws/XUZrUHopkiNuCQv3cBHNi/Hf/9n0nFOdsLfg/en6/kUx7eMPCArnabWG nSlUt5CLc+q3sFNW8qprFoxpjsZIG1PK9rtLpYrCBZDAccUujwYAvdXPt3OUBQt1jFL/ zxNYyS9KqaKIdpN4iRpC6LqFS3N+JBKcf8zkCXPgQ1YoCgvm6TMuoxosOpWV3uCGTdA8 Byzg== X-Gm-Message-State: AEkoousOLm3SmJ7H43WsVi/6GVhXMGQ1+UelzECm4yKpTaLGD4j95j8AsoSq8Wj8tfbP3gfrP6iXMqqQpy5gYXVq X-Received: by 10.31.109.67 with SMTP id i64mr27858906vkc.10.1470184034788; Tue, 02 Aug 2016 17:27:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.148 with HTTP; Tue, 2 Aug 2016 17:26:53 -0700 (PDT) In-Reply-To: <974CF78E8475CD4CA398B1FCA21C8E99565A9DF7@PRN-MBX01-4.TheFacebook.com> References: <974CF78E8475CD4CA398B1FCA21C8E99565A9DF7@PRN-MBX01-4.TheFacebook.com> From: Nick Harper Date: Tue, 2 Aug 2016 17:26:53 -0700 Message-ID: To: Subodh Iyengar Content-Type: multipart/alternative; boundary=94eb2c095c0a26467905391fe5ce Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] migrations of token bindings 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, 03 Aug 2016 00:27:19 -0000 --94eb2c095c0a26467905391fe5ce Content-Type: text/plain; charset=UTF-8 On Tue, Aug 2, 2016 at 4:47 PM, Subodh Iyengar wrote: > Davidben and I were chatting during IETF Berlin about token bindings and > we discussed some interesting issues around token bindings and migrations. > > 2 cases come to my mind: > * For example let's say Server 1 negotiates key parameters ecdsa and > establishes a token binding with ecdsa params, however the relying party > for a referred token binding only supports pkcs1.5. > I agree that current negotiation mechanisms are probably not enough for a client to know if a relying party will accept a referred token binding that is sent in an environment with diversity of key types. (I hope there are no servers that are only going to support pkcs1v1.5 - they should at least support pss if they're doing rsa.) > > * A new token binding type is added for example eddsa and the server wants > to migrate it's existing ecdsa token binding to an eddsa token binding. > > One way to migrate token bindings comes to mind but it's super nasty. For > example let's say Server 1 runs on origin server.com which has the > original bindings. You could have Server 1 create a new domain > migration.server.com (which supports both ecdsa and pkcs1.5) and then > server.com could 302 to migration.server.com with a referred token > binding. This is really painful to migrate and probably impractical for > many services. > For this to work, migration.server.com would have to support ecdsa and rsa, but not advertise support for ecdsa. Otherwise, the client would send an ecdsa key as the provided key for migration.server.com (and as the referred key to the relying party that only supports rsa). > > However I think there might be a more elegant solution. One proposal could > be to change the server token binding extension to be allowed to specify > multiple supported token bindings instead of requiring just one. This will > allow the server to negotiate not only ecdsa but also pkcs1.5 token > bindings and store them together. This would make migration easier. For > example if server only supported ecdsa initially and had token binding id = > A initially, and needed to support a new party which supported pkcs1.5, it > would advertise support for both. Then the client would send it 2 bindings > A and B which it can store together. > This sounds like an interesting idea, but I'm concerned that it would require a client to always compute and send as many signatures as are in the set of key types the client supports intersected with the key types the server supports (I imagine this set would start off looking like [pss, p256], and at some point in the future [pss, p256, Ed25519]). Perpetually requiring the client to compute and send multiple signatures which have the same purpose sounds like a waste of computation and bandwidth. If the requirement is loosened that a client send all signatures that both it and the server support, then I could imagine a client would never want to use a new key with that server unless the server drops support for the old key type. > > Has this problem been discussed before? > There was some discussion in the past, https://mailarchive.ietf.org/arch/msg/unbearable/RCQpBN0_b-jotGlSJisFUh_K54g is an example. > > Subodh > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --94eb2c095c0a26467905391fe5ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 2, 2016 at 4:47 PM, Subodh= Iyengar <subodh@fb.com> wrote:
Davidben and I were chatting durin= g IETF Berlin about token bindings and we discussed some interesting issues= around token bindings and migrations.=C2=A0

2 cases come to my mind:
* For example let's say Server 1 neg= otiates key parameters ecdsa and establishes a token binding with ecdsa par= ams, however the relying party for a referred token binding only supports p= kcs1.5.=C2=A0

I agree tha= t current negotiation mechanisms are probably not enough for a client to kn= ow if a relying party will accept a referred token binding that is sent in = an environment with diversity of key types. (I hope there are no servers th= at are only going to support pkcs1v1.5 - they should at least support pss i= f they're doing rsa.)=C2=A0

* A new token binding type is added for = example eddsa and the server wants to migrate it's existing ecdsa token= binding to an eddsa token binding.=C2=A0

One way to migrate token bindings comes = to mind but it's super nasty. For example let's say Server 1 runs o= n origin server.com whi= ch has the original bindings. You could have Server 1 create a new domain <= a href=3D"http://migration.server.com" target=3D"_blank">migration.server.c= om (which supports both ecdsa and pkcs1.5) and then server.com could 302 to migration.server.com with a referred = token binding. This is really painful to migrate and probably impractical f= or many services. =C2=A0

= For this to work, migration.server.= com would have to support ecdsa and rsa, but not advertise support for = ecdsa. Otherwise, the client would send an ecdsa key as the provided key fo= r migration.server.com (and as = the referred key to the relying party that only supports rsa).=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">

However I think there might be a more el= egant solution. One proposal could be to change the server token binding ex= tension to be allowed to specify multiple supported token bindings instead = of requiring just one. This will allow the server to negotiate not only ecdsa but also pkcs1.5 token bindin= gs and store them together. This would make migration easier. For example i= f server only supported ecdsa initially and had token binding id =3D A init= ially, and needed to support a new party which supported pkcs1.5, it would advertise support for both. Then t= he client would send it 2 bindings A and B which it can store together.=C2= =A0

This sounds like an i= nteresting idea, but I'm concerned that it would require a client to al= ways compute and send as many signatures as are in the set of key types the= client supports intersected with the key types the server supports (I imag= ine this set would start off looking like [pss, p256], and at some point in= the future [pss, p256, Ed25519]). Perpetually requiring the client to comp= ute and send multiple signatures which have the same purpose sounds like a = waste of computation and bandwidth. If the requirement is loosened that a c= lient send all signatures that both it and the server support, then I could= imagine a client would never want to use a new key with that server unless= the server drops support for the old key type.

Has this problem been discussed before?<= /div>

There was some discussion= in the past, https://mailarchive.ietf.org/arch/msg/unbearabl= e/RCQpBN0_b-jotGlSJisFUh_K54g is an example.=C2=A0
<= font color=3D"#888888">

Subodh

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


--94eb2c095c0a26467905391fe5ce-- From nobody Tue Aug 2 17:37: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 5F7D112B04A for ; Tue, 2 Aug 2016 17:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.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 zwHZJBU7fTa9 for ; Tue, 2 Aug 2016 17:37:14 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 C8D7912B03D for ; Tue, 2 Aug 2016 17:37:14 -0700 (PDT) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.11/8.16.0.11) with SMTP id u730ZpMJ029328; Tue, 2 Aug 2016 17:37:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=l0O+XMNlOpmYUOiSSa+7MjcwOgTCxqiPE4HlZq56alM=; b=TsJ3zTC0DzNM91os99CQIyTEE4T2rzzPtC+REplkfgb+4KvyQkzvt+7SrNEiYBSxhumV mVd6OJD5qUq1/jLf98IfuFZBSV0lYDo58wzRSLoandsH0TYENxYPSvEPHiuWbkIAhIJS P/MRapLqxbjoStLkygnO/7N+NDu/wWJPPRA= Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 24k677r06b-2 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 02 Aug 2016 17:37:12 -0700 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.29]) by PRN-CHUB07.TheFacebook.com ([fe80::d38:43fc:554e:146a%12]) with mapi id 14.03.0294.000; Tue, 2 Aug 2016 17:37:11 -0700 From: Subodh Iyengar To: Nick Harper Thread-Topic: [Unbearable] migrations of token bindings Thread-Index: AdHtGANk8YhqkfT0RKqstDH3Uk+wIQAQGS2A//+LD50= Date: Wed, 3 Aug 2016 00:37:11 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E99565A9EB0@PRN-MBX01-4.TheFacebook.com> References: <974CF78E8475CD4CA398B1FCA21C8E99565A9DF7@PRN-MBX01-4.TheFacebook.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_974CF78E8475CD4CA398B1FCA21C8E99565A9EB0PRNMBX014TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-02_18:, , signatures=0 Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] migrations of token bindings 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, 03 Aug 2016 00:37:17 -0000 --_000_974CF78E8475CD4CA398B1FCA21C8E99565A9EB0PRNMBX014TheFac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > For this to work, migration.server.com would have to sup= port ecdsa and rsa, but not advertise support for ecdsa. Otherwise, the cli= ent would send an ecdsa key as the provided key for migration.server.com (and as the referred key to the relying party that only sup= ports rsa). This is an interesting point. If the migration server would not advertise s= upport for ECDSA, then I think the referred token binding (which would be e= cdsa) would probably not be sent, or rather I'm not sure what happens with = the referred token binding with a key param which is not negotiated. This w= as meant to be a strawman solution, and thinking about it again this would = probably not work. >This sounds like an interesting idea, but I'm concerned that it would requ= ire a client to always compute and send as many signatures as are in the se= t of key types the client supports intersected with the key types the serve= r supports Ya I think this is a tradeoff here. I imagine that this would happen, at le= ast in our case, only when we need to do a migration. In absence of another= practical solution (Does one exist?), it seems reasonable to retain this f= lexibility. The server would probably stop advertising support once it's do= ne with the migration. Subodh ________________________________ From: Nick Harper [nharper@google.com] Sent: Tuesday, August 02, 2016 5:26 PM To: Subodh Iyengar Cc: unbearable@ietf.org Subject: Re: [Unbearable] migrations of token bindings On Tue, Aug 2, 2016 at 4:47 PM, Subodh Iyengar > wrote: Davidben and I were chatting during IETF Berlin about token bindings and we= discussed some interesting issues around token bindings and migrations. 2 cases come to my mind: * For example let's say Server 1 negotiates key parameters ecdsa and establ= ishes a token binding with ecdsa params, however the relying party for a re= ferred token binding only supports pkcs1.5. I agree that current negotiation mechanisms are probably not enough for a c= lient to know if a relying party will accept a referred token binding that = is sent in an environment with diversity of key types. (I hope there are no= servers that are only going to support pkcs1v1.5 - they should at least su= pport pss if they're doing rsa.) * A new token binding type is added for example eddsa and the server wants = to migrate it's existing ecdsa token binding to an eddsa token binding. One way to migrate token bindings comes to mind but it's super nasty. For e= xample let's say Server 1 runs on origin server.com which has the or= iginal bindings. You could have Server 1 create a new domain migration.serv= er.com (which supports both ecdsa and pkcs1.5) and then = server.com could 302 to migration.server.com with a= referred token binding. This is really painful to migrate and probably imp= ractical for many services. For this to work, migration.server.com would have to suppo= rt ecdsa and rsa, but not advertise support for ecdsa. Otherwise, the clien= t would send an ecdsa key as the provided key for migration.server.com (and as the referred key to the relying party that only suppor= ts rsa). However I think there might be a more elegant solution. One proposal could = be to change the server token binding extension to be allowed to specify mu= ltiple supported token bindings instead of requiring just one. This will al= low the server to negotiate not only ecdsa but also pkcs1.5 token bindings = and store them together. This would make migration easier. For example if s= erver only supported ecdsa initially and had token binding id =3D A initial= ly, and needed to support a new party which supported pkcs1.5, it would adv= ertise support for both. Then the client would send it 2 bindings A and B w= hich it can store together. This sounds like an interesting idea, but I'm concerned that it would requi= re a client to always compute and send as many signatures as are in the set= of key types the client supports intersected with the key types the server= supports (I imagine this set would start off looking like [pss, p256], and= at some point in the future [pss, p256, Ed25519]). Perpetually requiring t= he client to compute and send multiple signatures which have the same purpo= se sounds like a waste of computation and bandwidth. If the requirement is = loosened that a client send all signatures that both it and the server supp= ort, then I could imagine a client would never want to use a new key with t= hat server unless the server drops support for the old key type. Has this problem been discussed before? There was some discussion in the past, https://mailarchive.ietf.org/arch/ms= g/unbearable/RCQpBN0_b-jotGlSJisFUh_K54g is an example. Subodh _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable --_000_974CF78E8475CD4CA398B1FCA21C8E99565A9EB0PRNMBX014TheFac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
&= gt; For this to work, migration.server.com would have to support ecdsa and rsa, but not advertise support for ecdsa. Otherw= ise, the client would send an ecdsa key as the provided key for migration.server.com (and as the referred key to the relying party that only supports rsa). 

This is an interesting point. If the migration server would not advert= ise support for ECDSA, then I think the referred token binding (which would= be ecdsa) would probably not be sent, or rather I'm not sure what happens = with the referred token binding with a key param which is not negotiated. This was meant to be a strawman = solution, and thinking about it again this would probably not work.  <= /div>
<= br>
&= gt;This sounds like an interesting idea, but I'm concerned that it would re= quire a client to always compute and send as many signatures as are in the = set of key types the client supports intersected with the key types the server supports
<= br>
Y= a I think this is a tradeoff here. I imagine that this would happen, at lea= st in our case, only when we need to do a migration. In absence of another = practical solution (Does one exist?), it seems reasonable to retain this flexibility. The server would probably stop adve= rtising support once it's done with the migration.
<= br>
Subodh
From: Nick Harper [nharper@google.com] Sent: Tuesday, August 02, 2016 5:26 PM
To: Subodh Iyengar
Cc: unbearable@ietf.org
Subject: Re: [Unbearable] migrations of token bindings



On Tue, Aug 2, 2016 at 4:47 PM, Subodh Iyengar <= span dir=3D"ltr"> <subodh@fb.com>= ; wrote:
Davidben and I were chatting during IET= F Berlin about token bindings and we discussed some interesting issues arou= nd token bindings and migrations. 

2 cases come to my mind:
* For example let's say Server 1 negotia= tes key parameters ecdsa and establishes a token binding with ecdsa params,= however the relying party for a referred token binding only supports pkcs1= .5. 

I agree that current negotiation mechanisms are probably not enough fo= r a client to know if a relying party will accept a referred token binding = that is sent in an environment with diversity of key types. (I hope there a= re no servers that are only going to support pkcs1v1.5 - they should at least support pss if they're doing r= sa.) 

* A new token binding type is added for = example eddsa and the server wants to migrate it's existing ecdsa token bin= ding to an eddsa token binding. 

One way to migrate token bindings comes = to mind but it's super nasty. For example let's say Server 1 runs on origin server.com which has the original bindings. You could have Server 1 cre= ate a new domain migration.server.com (which supports both ecdsa and pkcs1.5) and then <= a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__server.com&= amp;d=3DCwMFaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN7f= Q&m=3DNyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=3DJY8OTOqhlgLpv= TOoCZYcT4cCI1robvKQ-cB2q2GjBLI&e=3D" target=3D"_blank"> server.com could 302 to migration.server.com with a referred token binding. This is really pain= ful to migrate and probably impractical for many services.  

For this to work, migration.server.com would have to support ecdsa and rsa, but not adver= tise support for ecdsa. Otherwise, the client would send an ecdsa key as th= e provided key for migration.server.com (and as the referred key to the relying party that= only supports rsa). 

However I think there might be a more el= egant solution. One proposal could be to change the server token binding ex= tension to be allowed to specify multiple supported token bindings instead = of requiring just one. This will allow the server to negotiate not only ecdsa but also pkcs1.5 token bindings and= store them together. This would make migration easier. For example if serv= er only supported ecdsa initially and had token binding id =3D A initially,= and needed to support a new party which supported pkcs1.5, it would advertise support for both. Then the cli= ent would send it 2 bindings A and B which it can store together. 

This sounds like an interesting idea, but I'm concerned that it would = require a client to always compute and send as many signatures as are in th= e set of key types the client supports intersected with the key types the s= erver supports (I imagine this set would start off looking like [pss, p256], and at some point in the future = [pss, p256, Ed25519]). Perpetually requiring the client to compute and send= multiple signatures which have the same purpose sounds like a waste of com= putation and bandwidth. If the requirement is loosened that a client send all signatures that both it and the server = support, then I could imagine a client would never want to use a new key wi= th that server unless the server drops support for the old key type.

Has this problem been discussed before?<= /div>

There was some discussion in the past, https://mailarchive.ietf.org/arch/msg/unbearable/RCQpBN0_b-jotGlSJisFUh_K54= g is an example. 

Subodh

_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/un= bearable


--_000_974CF78E8475CD4CA398B1FCA21C8E99565A9EB0PRNMBX014TheFac_-- From nobody Tue Aug 2 17:55:09 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 3AE1912B04A for ; Tue, 2 Aug 2016 17:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 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, RP_MATCHES_RCVD=-1.287, 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 AhZMEBSGuRyw for ; Tue, 2 Aug 2016 17:55:05 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 0D0BD12B038 for ; Tue, 2 Aug 2016 17:55:05 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id k90so141716825uak.0 for ; Tue, 02 Aug 2016 17:55:04 -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=KHDYUk6GZXe5Mg0tUkYy4J1guVWk4qW3C9ZugLBFDUY=; b=jiyhSw3GHBV30mcdveLlDWYMv7I/KtRVp0qoiIuqeIuRd5WSXSqLtpKMHBkDfQtyMq LBPmW8jynV+Hor5lg3PdBQCEwmB8TiG0s0W0OScCxaOzHjPvNCUNYxPIucnfc7Kt9L67 egKzC8sUsySH1hcl5RQ8pVd1hQ+VQ+duugBUXRaghCkffrg4qcnLbkVFid1+DxqFNg2u RTeNd3JhSk8buTio0Gi9AG3K7FkzYjLjBYx4bDBVN3qJGubb76etmHqMr7d615RGTfaX cuT6by2r4CxAfG1evcIr02T46aax57v1kDGK/t3QCf/FF0wv7goN04AVUUFR32sTx2JH RGtw== 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=KHDYUk6GZXe5Mg0tUkYy4J1guVWk4qW3C9ZugLBFDUY=; b=LA6fxW2CReoXDOr0MJa44VUb9A/PnPxIOvsNA3o2F3S7dEz+TnjC9XM2WjYbm7det+ s8nLvWFtEjJRqW8mxRSzKvDClaEM3y0PtmY6n47pja8ajiQa1DBzXE5GVZeEtMJkF0IQ T+YEQDoFs7MUONjBw6GAmt+2c7RUzcfdtT+07ssIzlahU+Nu9in86dmBGIeUTcQqqRGQ xy+dTwFLdvT+cFppDF0cJ+kZSGNP8nIM56ckdfTrX4PRRb/5Iyqg3zZU5rTOTiCF3UHJ ajsB/9PG5PVcRzVtKOnATgpdW+5DlgS7AO3tTlHdGSgFyWsgVdfjnmnE6wO+8u2MwsIh RY/Q== X-Gm-Message-State: AEkoouspvYaZ4TeOumwQKg0oAbIeOhThjvMK5usNZBQwFd6BxNP9rcps8cALcsFI77pEtPUil/sUCduKbMGFUW6J X-Received: by 10.159.36.205 with SMTP id 71mr32373590uar.121.1470185703930; Tue, 02 Aug 2016 17:55:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.148 with HTTP; Tue, 2 Aug 2016 17:54:43 -0700 (PDT) In-Reply-To: <974CF78E8475CD4CA398B1FCA21C8E99565A9EB0@PRN-MBX01-4.TheFacebook.com> References: <974CF78E8475CD4CA398B1FCA21C8E99565A9DF7@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9EB0@PRN-MBX01-4.TheFacebook.com> From: Nick Harper Date: Tue, 2 Aug 2016 17:54:43 -0700 Message-ID: To: Subodh Iyengar Content-Type: multipart/alternative; boundary=001a113e5ddea3582f0539204809 Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] migrations of token bindings 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, 03 Aug 2016 00:55:08 -0000 --001a113e5ddea3582f0539204809 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 2, 2016 at 5:37 PM, Subodh Iyengar wrote: > > For this to work, migration.server.com > would > have to support ecdsa and rsa, but not advertise support for ecdsa. > Otherwise, the client would send an ecdsa key as the provided key for > migration.server.com > (and > as the referred key to the relying party that only supports rsa). > >> > This is an interesting point. If the migration server would not advertise > support for ECDSA, then I think the referred token binding (which would b= e > ecdsa) would probably not be sent, or rather I'm not sure what happens wi= th > the referred token binding with a key param which is not negotiated. This > was meant to be a strawman solution, and thinking about it again this wou= ld > probably not work. > My assumption is that a client sends a referred token binding if the referer indicates to do so, and no consideration is given to what the relying party supports compared to the key type of the referred TB. > > >This sounds like an interesting idea, but I'm concerned that it would > require a client to always compute and send as many signatures as are in > the set of key types the client supports intersected with the key types t= he > server supports > > Ya I think this is a tradeoff here. I imagine that this would happen, at > least in our case, only when we need to do a migration. In absence of > another practical solution (Does one exist?), it seems reasonable to reta= in > this flexibility. The server would probably stop advertising support once > it's done with the migration. > I think some sort of migration negotiation would require more bits of information to be sent, like the client indicating which types it has keys for, or the server requesting the client to make a key of a particular type. I think an ideal solution would require no server state and no client state past the key store (a table of eTLD+1s, key types, and keys, i.e. no "migration in progress" bit). An ideal solution would also involve only one connection with multiple keys in use at the same time (or even better, some application layer signaling so only one request has both keys in use at the same time). I'm doubtful such a thing even exists. Suppose a server runs example.com and supersecret.example.com, with supersecret.example.com setting some cookies that are restricted to that domain. Cookies for both example.com and supersecret.example.com will be bound to the same token binding key K1. If we do some song-and-dance on a connection to example.com to migrate from K1 to K2, that will only migrate the bindings for the example.com cookies - the supersecret.example.com cookies will still be bound to K1. (I'm assuming that the cookie has some encrypted and integrity-protected identifier for the token binding key in it, instead of it being some sort of server-side lookup.) > > Subodh > ------------------------------ > *From:* Nick Harper [nharper@google.com] > *Sent:* Tuesday, August 02, 2016 5:26 PM > *To:* Subodh Iyengar > *Cc:* unbearable@ietf.org > *Subject:* Re: [Unbearable] migrations of token bindings > > > > On Tue, Aug 2, 2016 at 4:47 PM, Subodh Iyengar wrote: > >> Davidben and I were chatting during IETF Berlin about token bindings and >> we discussed some interesting issues around token bindings and migration= s. >> >> 2 cases come to my mind: >> * For example let's say Server 1 negotiates key parameters ecdsa and >> establishes a token binding with ecdsa params, however the relying party >> for a referred token binding only supports pkcs1.5. >> > > I agree that current negotiation mechanisms are probably not enough for a > client to know if a relying party will accept a referred token binding th= at > is sent in an environment with diversity of key types. (I hope there are = no > servers that are only going to support pkcs1v1.5 - they should at least > support pss if they're doing rsa.) > >> >> * A new token binding type is added for example eddsa and the server >> wants to migrate it's existing ecdsa token binding to an eddsa token >> binding. >> >> One way to migrate token bindings comes to mind but it's super nasty. Fo= r >> example let's say Server 1 runs on origin server.com >> >> which has the original bindings. You could have Server 1 create a new >> domain migration.server.com >> >> (which supports both ecdsa and pkcs1.5) and then server.com >> >> could 302 to migration.server.com >> >> with a referred token binding. This is really painful to migrate and >> probably impractical for many services. >> > > For this to work, migration.server.com > > would have to support ecdsa and rsa, but not advertise support for ecdsa. > Otherwise, the client would send an ecdsa key as the provided key for > migration.server.com > > (and as the referred key to the relying party that only supports rsa). > >> >> However I think there might be a more elegant solution. One proposal >> could be to change the server token binding extension to be allowed to >> specify multiple supported token bindings instead of requiring just one. >> This will allow the server to negotiate not only ecdsa but also pkcs1.5 >> token bindings and store them together. This would make migration easier= . >> For example if server only supported ecdsa initially and had token bindi= ng >> id =3D A initially, and needed to support a new party which supported >> pkcs1.5, it would advertise support for both. Then the client would send= it >> 2 bindings A and B which it can store together. >> > > This sounds like an interesting idea, but I'm concerned that it would > require a client to always compute and send as many signatures as are in > the set of key types the client supports intersected with the key types t= he > server supports (I imagine this set would start off looking like [pss, > p256], and at some point in the future [pss, p256, Ed25519]). Perpetually > requiring the client to compute and send multiple signatures which have t= he > same purpose sounds like a waste of computation and bandwidth. If the > requirement is loosened that a client send all signatures that both it an= d > the server support, then I could imagine a client would never want to use= a > new key with that server unless the server drops support for the old key > type. > >> >> Has this problem been discussed before? >> > > There was some discussion in the past, > https://mailarchive.ietf.org/arch/msg/unbearable/RCQpBN0_b-jotGlSJisFUh_K= 54g > > is an example. > >> >> Subodh >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >> >> >> > --001a113e5ddea3582f0539204809 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 2, 2016 at 5:37 PM, Subodh Iyengar <subodh@fb.com> wrote:
> = For this to work,=C2=A0migration.server.com=C2=A0would have to support ecdsa and rsa, but not advertise support for ecdsa. Otherw= ise, the client would send an ecdsa key as the provided key for=C2=A0migration.server.com=C2=A0(and as the referred key to the relying party that only supports rsa).=C2=A0

This is an interesting point. If the migration server would not= advertise support for ECDSA, then I think the referred token binding (whic= h would be ecdsa) would probably not be sent, or rather I'm not sure wh= at happens with the referred token binding with a key param which is not negotiated. This was meant to be a strawman = solution, and thinking about it again this would probably not work. =C2=A0<= /div>

My assumption is that a c= lient sends a referred token binding if the referer indicates to do so, and= no consideration is given to what the relying party supports compared to t= he key type of the referred TB.

>T= his sounds like an interesting idea, but I'm concerned that it would re= quire a client to always compute and send as many signatures as are in the = set of key types the client supports intersected with the key types the server supports

example.com and supersecret.example.com, with supersecret.example.com setting some cookies that are res= tricted to that domain. Cookies for both exa= mple.com and supersecret.exa= mple.com will be bound to the same token binding key K1. If we do some = song-and-dance on a connection to example.co= m to migrate from K1 to K2, that will only migrate the bindings for the= example.com cookies - the supersecret.example.com cookies will stil= l be bound to K1. (I'm assuming that the cookie has some encrypted and = integrity-protected identifier for the token binding key in it, instead of = it being some sort of server-side lookup.)

Subodh
From: Nick Harper [nharper@google.com= ]
Sent: Tuesday, August 02, 2016 5:26 PM
To: Subodh Iyengar
Cc: unbeara= ble@ietf.org
Subject: Re: [Unbearable] migrations of token bindings



On Tue, Aug 2, 2016 at 4:47 PM, Subodh Iyengar <= span dir=3D"ltr"> <subodh@fb.com>= ; wrote:
Davidben and I were chatting during IET= F Berlin about token bindings and we discussed some interesting issues arou= nd token bindings and migrations.=C2=A0

2 cases come to my mind:
* For example let's say Server 1 neg= otiates key parameters ecdsa and establishes a token binding with ecdsa par= ams, however the relying party for a referred token binding only supports p= kcs1.5.=C2=A0

I agree that current negotiation mechanisms are probably not enough fo= r a client to know if a relying party will accept a referred token binding = that is sent in an environment with diversity of key types. (I hope there a= re no servers that are only going to support pkcs1v1.5 - they should at least support pss if they're doi= ng rsa.)=C2=A0

* A new token binding type is added for = example eddsa and the server wants to migrate it's existing ecdsa token= binding to an eddsa token binding.=C2=A0

One way to migrate token bindings comes = to mind but it's super nasty. For example let's say Server 1 runs o= n origin server.com which has the original bindings. You could have Server 1 cre= ate a new domain migration.server.com (which supports both ecdsa and pkcs1.5) and then <= a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__server.com&= amp;d=3DCwMFaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN7f= Q&m=3DNyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=3DJY8OTOqhlgLpv= TOoCZYcT4cCI1robvKQ-cB2q2GjBLI&e=3D" target=3D"_blank"> server.com could 302 to migration.server.com with a referred token binding. This is really pain= ful to migrate and probably impractical for many services. =C2=A0

For this to work, migration.server.com would have to support ecdsa and rsa, but not adver= tise support for ecdsa. Otherwise, the client would send an ecdsa key as th= e provided key for migration.server.com (and as the referred key to the relying party that= only supports rsa).=C2=A0

However I think there might be a more el= egant solution. One proposal could be to change the server token binding ex= tension to be allowed to specify multiple supported token bindings instead = of requiring just one. This will allow the server to negotiate not only ecdsa but also pkcs1.5 token bindings and= store them together. This would make migration easier. For example if serv= er only supported ecdsa initially and had token binding id =3D A initially,= and needed to support a new party which supported pkcs1.5, it would advertise support for both. Then the cli= ent would send it 2 bindings A and B which it can store together.=C2=A0

This sounds like an interesting idea, but I'm concerned that it wo= uld require a client to always compute and send as many signatures as are i= n the set of key types the client supports intersected with the key types t= he server supports (I imagine this set would start off looking like [pss, p256], and at some point in the future = [pss, p256, Ed25519]). Perpetually requiring the client to compute and send= multiple signatures which have the same purpose sounds like a waste of com= putation and bandwidth. If the requirement is loosened that a client send all signatures that both it and the server = support, then I could imagine a client would never want to use a new key wi= th that server unless the server drops support for the old key type.

Has this problem been discussed before?<= /div>

There was some discussion in the past, https://mailarchive.ietf.org/arch/msg/unbearable/RCQpBN0_b-jotGlSJisFUh_K54= g is an example.=C2=A0

Subodh

_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/un= bearable



--001a113e5ddea3582f0539204809-- From nobody Tue Aug 2 18:39:29 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 91B2112D143 for ; Tue, 2 Aug 2016 18:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.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 Pb4TpfERbE7b for ; Tue, 2 Aug 2016 18:39:24 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 D551312D876 for ; Tue, 2 Aug 2016 18:39:24 -0700 (PDT) Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u731alAP023327; Tue, 2 Aug 2016 18:39:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=3ktMupdgsiPQKnFD1D7+rIpTSU+NZi4PMq8K0Ngzix8=; b=q4+qow6NKpapaj8h4fL1Q0rpdhSlcRAKxFy5DAYatraEhWtdGPaLtXK7IltZ/Kpur35b CDcWLcEHdw14Mha1GFNHqUfdRMiSslAwQN9cLqnC2Uq1gJoSHkqfBk7gJjIaTbQYplXb dKPvE2Mzc/S62WZX9ajFU/dFJ2aew+mRvxA= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 24k6v002t8-10 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 02 Aug 2016 18:39:23 -0700 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.29]) by PRN-CHUB10.TheFacebook.com ([fe80::c983:d64f:e422:461d%12]) with mapi id 14.03.0294.000; Tue, 2 Aug 2016 18:36:48 -0700 From: Subodh Iyengar To: Nick Harper Thread-Topic: [Unbearable] migrations of token bindings Thread-Index: AdHtGANk8YhqkfT0RKqstDH3Uk+wIQAQGS2A//+LD52AAHy3gP//i/aA Date: Wed, 3 Aug 2016 01:36:46 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E99565A9F26@PRN-MBX01-4.TheFacebook.com> References: <974CF78E8475CD4CA398B1FCA21C8E99565A9DF7@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9EB0@PRN-MBX01-4.TheFacebook.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_974CF78E8475CD4CA398B1FCA21C8E99565A9F26PRNMBX014TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-03_01:, , signatures=0 Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] migrations of token bindings 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, 03 Aug 2016 01:39:27 -0000 --_000_974CF78E8475CD4CA398B1FCA21C8E99565A9F26PRNMBX014TheFac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > An ideal solution would also involve only one connection with multiple ke= ys in use at the same time (or even better, some application layer signalin= g so only one request has both keys in use at the same time). I think there might be a confusion here. The suggested proposal is to have = the server say I support pkcs and ecdsa and then the client would send bind= ings with both ids. During a migration from K1 -> K2 bindings both the ids,= old and new, would automatically be in the token binding message. Isn't th= at exactly what you're asking for? There are 2 cases here: 1. Migrating from K1 -> K2 which share the same type 2. Migrating from K1 -> K2 which share different types. (1) is possible even in the current spec because the client can send multip= le bindings for the same type. (2) is not possible in the current spec (I think), hence the proposal. The token binding cookie would be changed to contain signed(token || K2) wh= en the server validates K1 was correct and a new cookie would be set. So I= don't think additional client or server state is required, just the token = would be changed. >I think some sort of migration negotiation would require more bits of info= rmation to be sent, like the client indicating which types it has keys for,= or the server requesting the client to make a key of a particular type I don't think any addition migration in progress state is required. The sta= te of migrations is usually monitored via backed logging of requests and ob= serving how many requests have K2 and K1 vs K1 only (This could technically= be considered state, but not in the sense of state that servers need to tr= ack strictly for correct operation). > If we do some song-and-dance on a connection to example.com to mi= grate from K1 to K2, that will only migrate the bindings for the example.co= m cookies - the supersecret.example.com cookies= will still be bound to K1. The supersecret cookies (specific to supersecret) would also go through the= same song and dance of example.com. The first time someone hits supersecre= t after someone has decided they need to start migrating, they would get th= e new cookie with the new token binding. Migration is not be the only case though. There are also cases where both m= ight need to be supported simultaneously forever. For example you want to t= alk to an identity provider that supports pkcs1.5 only and you only care ab= out ecdsa bindings for your own site. I hope that doesn't happen with pkcs1= .5, however in the future this might happen with eddsa where you might want= to start binding to curve25519 ids while providers are stuck with ecdsa bi= ndings. Subodh ________________________________ From: Nick Harper [nharper@google.com] Sent: Tuesday, August 02, 2016 5:54 PM To: Subodh Iyengar Cc: unbearable@ietf.org Subject: Re: [Unbearable] migrations of token bindings On Tue, Aug 2, 2016 at 5:37 PM, Subodh Iyengar > wrote: > For this to work, migration.server.com would have to sup= port ecdsa and rsa, but not advertise support for ecdsa. Otherwise, the cli= ent would send an ecdsa key as the provided key for migration.server.com (and as the referred key to the relying party that only sup= ports rsa). This is an interesting point. If the migration server would not advertise s= upport for ECDSA, then I think the referred token binding (which would be e= cdsa) would probably not be sent, or rather I'm not sure what happens with = the referred token binding with a key param which is not negotiated. This w= as meant to be a strawman solution, and thinking about it again this would = probably not work. My assumption is that a client sends a referred token binding if the refere= r indicates to do so, and no consideration is given to what the relying par= ty supports compared to the key type of the referred TB. >This sounds like an interesting idea, but I'm concerned that it would requ= ire a client to always compute and send as many signatures as are in the se= t of key types the client supports intersected with the key types the serve= r supports Ya I think this is a tradeoff here. I imagine that this would happen, at le= ast in our case, only when we need to do a migration. In absence of another= practical solution (Does one exist?), it seems reasonable to retain this f= lexibility. The server would probably stop advertising support once it's do= ne with the migration. I think some sort of migration negotiation would require more bits of infor= mation to be sent, like the client indicating which types it has keys for, = or the server requesting the client to make a key of a particular type. I t= hink an ideal solution would require no server state and no client state pa= st the key store (a table of eTLD+1s, key types, and keys, i.e. no "migrati= on in progress" bit). An ideal solution would also involve only one connect= ion with multiple keys in use at the same time (or even better, some applic= ation layer signaling so only one request has both keys in use at the same = time). I'm doubtful such a thing even exists. Suppose a server runs example.com and supersecret.example.com, with supersecret.exa= mple.com setting some cookies that are restricted to th= at domain. Cookies for both example.com and supersecret.example.com= will be bound to the same token binding key K1. If we = do some song-and-dance on a connection to example.com to migrate fr= om K1 to K2, that will only migrate the bindings for the example.com cookies - the supersecret.example.com cookies will st= ill be bound to K1. (I'm assuming that the cookie has some encrypted and in= tegrity-protected identifier for the token binding key in it, instead of it= being some sort of server-side lookup.) Subodh ________________________________ From: Nick Harper [nharper@google.com] Sent: Tuesday, August 02, 2016 5:26 PM To: Subodh Iyengar Cc: unbearable@ietf.org Subject: Re: [Unbearable] migrations of token bindings On Tue, Aug 2, 2016 at 4:47 PM, Subodh Iyengar > wrote: Davidben and I were chatting during IETF Berlin about token bindings and we= discussed some interesting issues around token bindings and migrations. 2 cases come to my mind: * For example let's say Server 1 negotiates key parameters ecdsa and establ= ishes a token binding with ecdsa params, however the relying party for a re= ferred token binding only supports pkcs1.5. I agree that current negotiation mechanisms are probably not enough for a c= lient to know if a relying party will accept a referred token binding that = is sent in an environment with diversity of key types. (I hope there are no= servers that are only going to support pkcs1v1.5 - they should at least su= pport pss if they're doing rsa.) * A new token binding type is added for example eddsa and the server wants = to migrate it's existing ecdsa token binding to an eddsa token binding. One way to migrate token bindings comes to mind but it's super nasty. For e= xample let's say Server 1 runs on origin server.com which has the or= iginal bindings. You could have Server 1 create a new domain migration.serv= er.com (which supports both ecdsa and pkcs1.5) and then = server.com could 302 to migration.server.com with a= referred token binding. This is really painful to migrate and probably imp= ractical for many services. For this to work, migration.server.com would have to suppo= rt ecdsa and rsa, but not advertise support for ecdsa. Otherwise, the clien= t would send an ecdsa key as the provided key for migration.server.com (and as the referred key to the relying party that only suppor= ts rsa). However I think there might be a more elegant solution. One proposal could = be to change the server token binding extension to be allowed to specify mu= ltiple supported token bindings instead of requiring just one. This will al= low the server to negotiate not only ecdsa but also pkcs1.5 token bindings = and store them together. This would make migration easier. For example if s= erver only supported ecdsa initially and had token binding id =3D A initial= ly, and needed to support a new party which supported pkcs1.5, it would adv= ertise support for both. Then the client would send it 2 bindings A and B w= hich it can store together. This sounds like an interesting idea, but I'm concerned that it would requi= re a client to always compute and send as many signatures as are in the set= of key types the client supports intersected with the key types the server= supports (I imagine this set would start off looking like [pss, p256], and= at some point in the future [pss, p256, Ed25519]). Perpetually requiring t= he client to compute and send multiple signatures which have the same purpo= se sounds like a waste of computation and bandwidth. If the requirement is = loosened that a client send all signatures that both it and the server supp= ort, then I could imagine a client would never want to use a new key with t= hat server unless the server drops support for the old key type. Has this problem been discussed before? There was some discussion in the past, https://mailarchive.ietf.org/arch/ms= g/unbearable/RCQpBN0_b-jotGlSJisFUh_K54g is an example. Subodh _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable --_000_974CF78E8475CD4CA398B1FCA21C8E99565A9F26PRNMBX014TheFac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>&= nbsp;An ideal solution would also involve only one connection with multiple keys in use at the same time (or= even better, some application layer signaling so only one request has both= keys in use at the same time). 

I think there might be a confusion here. The suggested proposal is to = have the server say I support pkcs and ecdsa and then the client would send= bindings with both ids. During a migration from K1 -> K2 bindings both = the ids, old and new, would automatically be in the token binding message. Isn't that exactly what you're asking for= ?

There are 2 cases here:
1. Migrating from K1 -> K2 which share the same type
2. Migrating from K1 -> K2 which sh= are different types.

(1) is possible even in the current sp= ec because the client can send multiple bindings for the same type.
(2) is not possible in the current spe= c (I think), hence the proposal.  

The token binding cookie would be changed to contain signed(token || K= 2) when the server validates K1 was correct and a new cookie would be set. =  So I don't think additional cli= ent or server state is required, just the token would be changed.

>I think some sort of migration negotiatio= n would require more bits of information to be sent, like the client indica= ting which types it has keys for, or the server requesting the client to make a key of a particular type

I don't think any addition migration = in progress state is required. The state of migrations is usually monitored= via backed logging of requests and observing how many requests have K2 and= K1 vs K1 only (This could technically be considered state, but not in the sense of state that servers need to tr= ack strictly for correct operation). 

> If we do some song-and-dance on a connec= tion to example.com to migrate from K1 to K2, that will only migrate the bindings for the example.com cookies - the supersecret.example.com cookies will still be bound to K1.
The supersecret cookies (specific to supersecret) would also go throug= h the same song and dance of example.com. The first time someone hits super= secret after someone has decided they need to start migrating, they would g= et the new cookie with the new token binding.

Migration is not be the only cas= e though. There are also cases where both might need to be supp= orted simultaneously forever. For example you want to talk to an identity p= rovider that supports pkcs1.5 only and you only care about ecdsa bindings for your own site. I hope that doesn't = happen with pkcs1.5, however in the future this might happen with eddsa whe= re you might want to start binding to curve25519 ids while providers are st= uck with ecdsa bindings. 

Subodh
From: Nick Harper [nharper@google.com] Sent: Tuesday, August 02, 2016 5:54 PM
To: Subodh Iyengar
Cc: unbearable@ietf.org
Subject: Re: [Unbearable] migrations of token bindings



On Tue, Aug 2, 2016 at 5:37 PM, Subodh Iyengar <= span dir=3D"ltr"> <subodh@fb.com>= ; wrote:
>= For this to work, migration.server.com would have to support ecdsa and rsa, but not advertise support for ecdsa. Otherw= ise, the client would send an ecdsa key as the provided key for migration.s= erver.com (and as the referred key to the relying party that only supports rsa). 

This is an interesting point. If the migration server would not advert= ise support for ECDSA, then I think the referred token binding (which would= be ecdsa) would probably not be sent, or rather I'm not sure what happens = with the referred token binding with a key param which is not negotiated. This was meant to be a strawman = solution, and thinking about it again this would probably not work.  <= /div>

My assumption is that a client sends a referred token binding if the r= eferer indicates to do so, and no consideration is given to what the relyin= g party supports compared to the key type of the referred TB.

>= This sounds like an interesting idea, but I'm concerned that it would requi= re a client to always compute and send as many signatures as are in the set= of key types the client supports intersected with the key types the server supports
Ya I= think this is a tradeoff here. I imagine that this would happen, at least = in our case, only when we need to do a migration. In absence of another pra= ctical solution (Does one exist?), it seems reasonable to retain this flexibility. The server would probably stop adve= rtising support once it's done with the migration.

I think some sort of migration negotiation would require more bits of = information to be sent, like the client indicating which types it has keys = for, or the server requesting the client to make a key of a particular type= . I think an ideal solution would require no server state and no client state past the key store (a table of= eTLD+1s, key types, and keys, i.e. no "migration in progress"= ; bit). An ideal solution would also involve only one connection with multi= ple keys in use at the same time (or even better, some application layer signaling so only one request has both keys in use = at the same time).

I'm doubtful such a thing even exists. Suppose a server runs example.com and supersecret.example.com, with supersecret.example.com setting some cookies that are restricted to tha= t domain. Cookies for both example.com and supersecret.example.com will be bound to the same token binding key K1.= If we do some song-and-dance on a connection to example.com to migrate from K1 to K2, that will only migrate the bindin= gs for the example.com cookies - the supersecret.example.com cookies will still be bound to K1. (I'm assumin= g that the cookie has some encrypted and integrity-protected identifier for= the token binding key in it, instead of it being some sort of server-side = lookup.)

Subodh
From: Nick Harper [nharper@google.com= ]
Sent: Tuesday, August 02, 2016 5:26 PM
To: Subodh Iyengar
Cc: unbeara= ble@ietf.org
Subject: Re: [Unbearable] migrations of token bindings



On Tue, Aug 2, 2016 at 4:47 PM, Subodh Iyengar <= span dir=3D"ltr"> <subodh@fb.com>= ; wrote:
Davidben and I were chatting during IET= F Berlin about token bindings and we discussed some interesting issues arou= nd token bindings and migrations. 

2 cases come to my mind:
* For example let's say Server 1 negotia= tes key parameters ecdsa and establishes a token binding with ecdsa params,= however the relying party for a referred token binding only supports pkcs1= .5. 

I agree that current negotiation mechanisms are probably not enough fo= r a client to know if a relying party will accept a referred token binding = that is sent in an environment with diversity of key types. (I hope there a= re no servers that are only going to support pkcs1v1.5 - they should at least support pss if they're doing r= sa.) 

* A new token binding type is added for = example eddsa and the server wants to migrate it's existing ecdsa token bin= ding to an eddsa token binding. 

One way to migrate token bindings comes = to mind but it's super nasty. For example let's say Server 1 runs on origin server.com which has the original bindings. You could have Server 1 cre= ate a new domain migration.server.com (which supports both ecdsa and pkcs1.5) and then <= a href=3D"https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__server.com&= amp;d=3DCwMFaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN7f= Q&m=3DNyY7oNMAn3NOUUgtYYFarC5bVw1IJXoMylMSkPVikhk&s=3DJY8OTOqhlgLpv= TOoCZYcT4cCI1robvKQ-cB2q2GjBLI&e=3D" target=3D"_blank"> server.com could 302 to migration.server.com with a referred token binding. This is really pain= ful to migrate and probably impractical for many services.  

For this to work, migration.server.com would have to support ecdsa and rsa, but not adver= tise support for ecdsa. Otherwise, the client would send an ecdsa key as th= e provided key for migration.server.com (and as the referred key to the relying party that= only supports rsa). 

However I think there might be a more el= egant solution. One proposal could be to change the server token binding ex= tension to be allowed to specify multiple supported token bindings instead = of requiring just one. This will allow the server to negotiate not only ecdsa but also pkcs1.5 token bindings and= store them together. This would make migration easier. For example if serv= er only supported ecdsa initially and had token binding id =3D A initially,= and needed to support a new party which supported pkcs1.5, it would advertise support for both. Then the cli= ent would send it 2 bindings A and B which it can store together. 

This sounds like an interesting idea, but I'm concerned that it would = require a client to always compute and send as many signatures as are in th= e set of key types the client supports intersected with the key types the s= erver supports (I imagine this set would start off looking like [pss, p256], and at some point in the future = [pss, p256, Ed25519]). Perpetually requiring the client to compute and send= multiple signatures which have the same purpose sounds like a waste of com= putation and bandwidth. If the requirement is loosened that a client send all signatures that both it and the server = support, then I could imagine a client would never want to use a new key wi= th that server unless the server drops support for the old key type.

Has this problem been discussed before?<= /div>

There was some discussion in the past, https://mailarchive.ietf.org/arch/msg/unbearable/RCQpBN0_b-jotGlSJisFUh_K54= g is an example. 

Subodh

_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/un= bearable



--_000_974CF78E8475CD4CA398B1FCA21C8E99565A9F26PRNMBX014TheFac_-- From nobody Wed Aug 3 08:52:34 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 3BF5012D675 for ; Wed, 3 Aug 2016 08:52:33 -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 Cbr5F3BF8Zlr for ; Wed, 3 Aug 2016 08:52:30 -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 EEA8512DD04 for ; Wed, 3 Aug 2016 08:50:56 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id 38so247076205iol.0 for ; Wed, 03 Aug 2016 08:50:56 -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=2WoyhZaYlkU/HzoRYHbpI8EZh8UhgGhx/7hN79UP6HE=; b=TJDAkB7ai0kDjYRqXPITEIc25iPIRA38vR22FH8udXyBnVh0Bf1bE0HWQPmMc02bxi tiRZ04IkbBgD/3gdJ489S4XjJ5dfSshvUODyyOWmu8vMFqivrTeQm6Uk4XJD0Ft2yXAS a69cq7gSKZVkBhgz2MNPnFeJs/30X5CQT6Bt0= 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=2WoyhZaYlkU/HzoRYHbpI8EZh8UhgGhx/7hN79UP6HE=; b=Iia4FJBz0NZYjoVMR3PRjQK9HHZtmCKTcA96rmaqfsRGDIN+FEn6vBP9gz7hWa00Bg o8Prc+WYo8fyz0Bk6GkWrk3eHtfEa6ilQJWpTxvrpsyekk7h3Yzo5dmRkMSIWxou1IO7 kMc6kMQ0g3UKeQXgWTbkDEcgiGYP8wCS8GFgsSlKMBChxlWWclmCgFkHf9Z1Q4QWd9n3 fiG/QeB64wNmDEhHEqHsD8LDgxDJFl4PzVlh/zpIU8LNLeepvpcH4FJXT9b34ysUuav/ FgTAqfygYO0omyLuwCrxfERf7tid1DWCccanyZns/OjyOhMlGblnBSuY0tjk8a+8q1pE ThVg== X-Gm-Message-State: AEkoousj7M7SoFQX5wtstoCjqBtUp/nmAqh5uG+NaUO+0W67wZmfrCE0KcrvA49f+ZBnnNzVbX+CIUnjVQCmMoME X-Received: by 10.107.8.94 with SMTP id 91mr65552383ioi.86.1470239456196; Wed, 03 Aug 2016 08:50:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Wed, 3 Aug 2016 08:50:25 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 3 Aug 2016 09:50:25 -0600 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a113f3a8885a9fd05392ccc91 Archived-At: Cc: Dave Tonge , John Bradley , IETF Tokbind WG , Bill Cox Subject: Re: [Unbearable] Current implementations of token binding spec? 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, 03 Aug 2016 15:52:33 -0000 --001a113f3a8885a9fd05392ccc91 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Related to this, I submitted this pull request for TBNEGO to use 24 rather than TBD for the ExtensionType Value. On Tue, Jun 21, 2016 at 3:13 PM, Andrei Popov wrote: > Hi Brian, > > > > Early assignment is available; please see attached. > > > > =E2=80=9C24 token_binding (TEMPORARY - registered 2016-02-04, exp= ires > 2017-02-04) > > [draft-ietf-tokbind-negotiation]=E2=80=9D > > > > Cheers, > > > > Andrei > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Br= ian > Campbell > *Sent:* Tuesday, June 21, 2016 1:48 PM > *To:* Dave Tonge > *Cc:* John Bradley ; IETF Tokbind WG < > unbearable@ietf.org>; Bill Cox > *Subject:* Re: [Unbearable] Current implementations of token binding spec= ? > > > > In the implementations that are out there now, what value is being used t= o > identify the token_binding ExtensionType? TBNEGO just has a TBD > > right now. Is there any work underway towards getting early assignment of= a > ExtensionType Value for TB? Or is that even possible? > > > > On Tue, Jun 21, 2016 at 10:13 AM, Dave Tonge > wrote: > > Thanks Bill and John > > > > Bill - looking forward to it, I'll give it a try when its released. > > John - I'll take a look at the test server in chromium. > > > > I'm keen to help push forward support, so please let me know if there is > anything else I can to do to help. > > > > Thanks > > > > Dave > > > > On 21 June 2016 at 16:35, John Bradley wrote: > > Currently if you are brave, there is a Python test server as part of the > Chromium project on Github for testing. > > https://github.com/chromium/chromium > > > > Last time I tried it you needed to checkout the whole project to get the > test server to build. > > I think they are working on making that easier. > > > > Also as part of that project there is the Cronet http/TLS lib that can be > used on iOS and Android. > > > > We are hoping to include that as an option in the AppAuth project for > token binding refresh and access tokens on mobile. > > > > https://github.com/openid > > > > We are working/lobbying to get support included in more places such as > Python and Java. > > > > I hope you can contribute to the WG and help us move this spec to a RFC > quickly by showing demand. > > > > Regards > > John B. > > > > > > On Jun 21, 2016, at 10:55 AM, Dave Tonge > wrote: > > > > Hi > > > > I'm currently working with the UK Open Banking Standard > and the OpenID Financial API WG > . > > The issue of token binding is being discussed and I wanted to try out an > actual real world implementation. > > After some research there don't seem to be many implementations in the > wild (unless I've missed something). > > > > It is supported in Chrome, but doesn't seem to be supported in OpenSSL ye= t > (and therefore not in Node.JS, Python, Ruby, etc. > > I've opened an issue on the OpenSSL repo: > https://github.com/openssl/openssl/issues/1242 > > > > Is my understanding correct? How would you recommend trying out a a live > implementation of token binding? > > > > Thanks > > > > -- > > *Dave Tonge* > > CTO > > 10 Temple Back | Bristol | BS1 6FL > > *t: *+44 (0)117 280 5120 <%2B44%20%280%29117%20280%205120> > > *m: *+44 (0)7577 815570 <%2B44%20%280%297577%20815570> > > > > Momentum Financial Technology Ltd is authorised and regulated by the > Financial Conduct Authority (Register number *561538*). Registered in > England & Wales, company registration number *06909772*. DISCLAIMER: This > email (including any attachments) is subject to copyright, and the > information in it is confidential. Use of this email or of any informatio= n > in it other than by the addressee is unauthorised and unlawful. Whilst > reasonable efforts are made to ensure that any attachments are virus-free= , > it is the recipient's sole responsibility to scan all attachments for > viruses. All calls and emails to and from this company may be monitored a= nd > recorded for legitimate purposes relating to this company's business. Any > opinions expressed in this email (or in any attachments) are those of the > author and do not necessarily represent the opinions of Momentum Financia= l > Technology Ltd or of any other group company. > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > > > > > > > -- > > *Dave Tonge* > > CTO > > 10 Temple Back | Bristol | BS1 6FL > > *t: *+44 (0)117 280 5120 <%2B44%20%280%29117%20280%205120> > > *m: *+44 (0)7577 815570 <%2B44%20%280%297577%20815570> > > > > Momentum Financial Technology Ltd is authorised and regulated by the > Financial Conduct Authority (Register number *561538*). Registered in > England & Wales, company registration number *06909772*. DISCLAIMER: This > email (including any attachments) is subject to copyright, and the > information in it is confidential. Use of this email or of any informatio= n > in it other than by the addressee is unauthorised and unlawful. Whilst > reasonable efforts are made to ensure that any attachments are virus-free= , > it is the recipient's sole responsibility to scan all attachments for > viruses. All calls and emails to and from this company may be monitored a= nd > recorded for legitimate purposes relating to this company's business. Any > opinions expressed in this email (or in any attachments) are those of the > author and do not necessarily represent the opinions of Momentum Financia= l > Technology Ltd or of any other group company. > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > > > > ---------- Forwarded message ---------- > From: Amanda Baber via RT > To: > Cc: "stephen.farrell@cs.tcd.ie" , " > ve7jtb@ve7jtb.com" , " > draft-ietf-tokbind-negotiation.all@ietf.org" < > draft-ietf-tokbind-negotiation.all@ietf.org> > Date: Fri, 5 Feb 2016 01:30:25 +0000 > Subject: [IANA #890903] Early code point assignment requests for > "Transport Layer Security (TLS) Extensions" registry > (draft-ietf-tokbind-negotiation) > Hi all, > > IANA has made the following early allocation in the TLS ExtensionType > Values registry, in accordance with RFC 7120: > > 24 token_binding (TEMPORARY - registered 2016-02-04, expires > 2017-02-04) > [draft-ietf-tokbind-negotiation] > > When the IESG notifies us that they've approved the document for > publication, we'll update the reference and remove the "temporary" note. = If > the document hasn't been approved within roughly 60 days of the expiratio= n > date, we'll ask you whether you want to renew the allocation for one more > year. (Early allocations can be renewed only once.) > > Best regards, > > Amanda Baber > IANA Senior Specialist > ICANN > > On Tue Feb 02 23:50:50 2016, ve7jtb@ve7jtb.com wrote: > > > > The Tokbind WG would like to ask for an early allocation of an IANA > > code point for the "TLS Extension for Token Binding Protocol > > Negotiation" ( > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2ftools.= ietf.org%2fhtml%2fdraft-ietf-tokbind-&data=3D01%7c01%7cAndrei.Popov%40micro= soft.com%7c5d373707b8d6408f00b908d32dcbf04f%7c72f988bf86f141af91ab2d7cd011d= b47%7c1&sdata=3DHkYLjr%2bpZbts%2fdRKcXSeM1WdO74TsRZMA4bL2WBYlZ8%3d > > negotiation-02 < > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2ftools.= ietf.org%2fhtml%2fdraft-ietf-tokbind-&data=3D01%7c01%7cAndrei.Popov%40micro= soft.com%7c5d373707b8d6408f00b908d32dcbf04f%7c72f988bf86f141af91ab2d7cd011d= b47%7c1&sdata=3DHkYLjr%2bpZbts%2fdRKcXSeM1WdO74TsRZMA4bL2WBYlZ8%3d > > negotiation-02>). This document defines a new TLS extension > > "token_binding", which needs to be added to the IANA "Transport Layer > > Security (TLS) Extensions" registry. > > > > Please note that this document also seeks to establish a registry for > > identifiers of Token Binding key parameters entitled "Token Binding > > Key Parameters" under the "Token Binding Protocol" heading. This new > > registry is not part of the early assignment request. > > > > At this point, authors do not expect major changes in the "TLS > > Extension for Token Binding Protocol Negotiation" specification. There > > are at least two prototype implementations of this specification being > > worked on (by Google and Microsoft). An early IANA code point > > assignment would facilitate implementation and deployment experience > > prior to the publication of the RFC. > > > > Regards > > John Bradley > > > > > --001a113f3a8885a9fd05392ccc91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Related to this, I submitted this pull re= quest for TBNEGO to use 24 rather than TBD for the ExtensionType Value.=

On Tue= , Jun 21, 2016 at 3:13 PM, Andrei Popov <Andrei.Popov@microsoft.c= om> wrote:

Hi Brian,

=C2=A0

Early assignment is available; please= see attached.

=C2=A0

=E2=80=9C24=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 token_binding (TEMPORARY - registered 2016-02-04, = expires 2017-02-04)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0

[draft-ietf-tokbind-negotiation]=E2=80=9D

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ie= tf.org] On Behalf Of Brian Campbell
Sent: Tuesday, June 21, 2016 1:48 PM
To: Dave Tonge <dave.tonge@momentumft.co.uk>
Cc: John Bradley <ve7jtb@ve7jtb.com>; IETF Tokbind WG <unbearable@ietf.org>; Bill Cox = <waywardgeek= @google.com>
Subject: Re: [Unbearable] Current implementations of token binding s= pec?

=C2=A0

In the implementations that are out there now, what = value is being used to identify the token_binding ExtensionType? TBNEGO just has a TBD right now. Is there any work underway towards get= ting early assignment of a ExtensionType Value for TB? Or is that even poss= ible?

=C2=A0

On Tue, Jun 21, 2016 at 10:13 AM, Dave Tonge <dave.tonge@mo= mentumft.co.uk> wrote:

Thanks Bill and John

=C2=A0

Bill - looking forward to it, I'll give it a try when its r= eleased.

John - I'll take a look at the test server in chromium.<= /u>

=C2=A0

I'm keen to help push forward support, so please let me kno= w if there is anything else I can to do to help.

=C2=A0

Thanks

=C2=A0

Dave

=C2=A0

On 21 June 2016 at 16:35, John Bradley <ve7jtb@ve7jtb.com> w= rote:

Currently if you are brave, there is a Python test s= erver as part of the Chromium project on Github for testing.<= /p>

=C2=A0

Last time I tried it you needed to checkout the whol= e project to get the test server to build. =C2=A0

I think they are working on making that easier.=C2= =A0

=C2=A0

Also as part of that project there is the Cronet htt= p/TLS lib that can be used on iOS and Android.

=C2=A0

We are hoping to include that as an option in the Ap= pAuth project for token binding refresh and access tokens on mobile.=

=C2=A0

https://github.com/openid

=C2=A0

We are working/lobbying to get support included in m= ore places such as Python and Java.

=C2=A0

I hope you can contribute to the WG and help us move= this spec to a RFC quickly by showing demand.

=C2=A0

Regards

John B.

=C2=A0

=C2=A0

On Jun 21, 2016, at 10:55 AM, Dave Tonge <dave.tonge@moment= umft.co.uk> wrote:

=C2=A0

Hi

=C2=A0

I'm currently working with the UK Ope= n Banking Standard and the OpenID= Financial API WG.=C2=A0

The issue of token binding is being discussed and I wanted to t= ry out an actual real world implementation.=C2=A0

After some research there don't seem to be many implementat= ions in the wild (unless I've missed something).

=C2=A0

It is supported in Chrome, but doesn't seem to be supported= in OpenSSL yet (and therefore not in Node.JS, Python, Ruby, etc.=

I've opened an issue on the OpenSSL repo: https://github.com/openssl/openssl/issues/1242

=C2=A0

Is my understanding correct? How would you recommend trying out= a a live implementation of token binding?

=C2=A0

Thanks

=C2=A0

--

Dave Tonge<= /p>

CTO

10 Temple Back | Bristol | BS1 6FL

=C2=A0

Momentum Financial Technology Ltd is aut= horised and regulated by the Financial Conduct Authority (Register number= =C2=A0561538). Registered in England & Wales, company registration number=C2=A006909772.=C2=A0DI= SCLAIMER: This email (including any attachments) is subject to copyright, and the in= formation in it is confidential. Use of this email or of any information in= it other than by the addressee is unauthorised and unlawful. Whilst reason= able efforts are made to ensure that any attachments are virus-free, it is the recipient's sole respon= sibility to scan all attachments for viruses. All calls and emails to and f= rom this company may be monitored and recorded for legitimate purposes rela= ting to this company's business. Any opinions expressed in this email (or in any attachments) are those of the = author and do not necessarily represent the opinions of Momentum Financial = Technology Ltd or of any other group company.<= /u>

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

=C2=A0



=C2=A0

--

Dave Tonge<= /p>

CTO

10 Temple Back | Bristol | BS1 6FL

=C2=A0

Momentum Financial Technology Ltd is aut= horised and regulated by the Financial Conduct Authority (Register number= =C2=A0561538). Registered in England & Wales, company registration number=C2=A006909772.=C2=A0DI= SCLAIMER: This email (including any attachments) is subject to copyright, and the in= formation in it is confidential. Use of this email or of any information in= it other than by the addressee is unauthorised and unlawful. Whilst reason= able efforts are made to ensure that any attachments are virus-free, it is the recipient's sole respon= sibility to scan all attachments for viruses. All calls and emails to and f= rom this company may be monitored and recorded for legitimate purposes rela= ting to this company's business. Any opinions expressed in this email (or in any attachments) are those of the = author and do not necessarily represent the opinions of Momentum Financial = Technology Ltd or of any other group company.<= /u>


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

=C2=A0



---------- Forwarded message ----------
From:=C2=A0Amanda Baber = via RT <iana-prot-pa= ram-comment@iana.org>
To:=C2=A0
Cc:=C2=A0"stephen.farrell@cs.tcd.ie" <stephen.farrell@cs.tcd.ie>, = "ve7jtb@ve7jtb.com" <= ve7jtb@ve7jtb.com>, "draft-ietf-tokbin= d-negotiation.all@ietf.org" <draft-ietf-tokbind-negotiation.all@ietf.org>
Date:=C2=A0Fri, 5 Feb 2016 01:30:25 +0000
Subject:=C2=A0[IANA #= 890903] Early code point assignment requests for "Transport Layer Secu= rity (TLS) Extensions" registry (draft-ietf-tokbind-negotiation)
Hi= all,

IANA has made the following early allocation in the TLS ExtensionType Value= s registry, in accordance with RFC 7120:

24=C2=A0 =C2=A0 =C2=A0 token_binding (TEMPORARY - registered 2016-02-04, ex= pires 2017-02-04)
[draft-ietf-tokbind-negotiation]

When the IESG notifies us that they've approved the document for public= ation, we'll update the reference and remove the "temporary" = note. If the document hasn't been approved within roughly 60 days of th= e expiration date, we'll ask you whether you want to renew the allocati= on for one more year. (Early allocations can be renewed only once.)

Best regards,

Amanda Baber
IANA Senior Specialist
ICANN

On Tue Feb 02 23:50:50 2016, ve7jtb@ve= 7jtb.com wrote:
>
> The Tokbind WG would like to ask for an early allocation of an IANA > code point for the "TLS Extension for Token Binding Protocol
> Negotiation" (http= s://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2ftools.ietf.o= rg%2fhtml%2fdraft-ietf-tokbind-&data=3D01%7c01%7cAndrei.Popov%40microso= ft.com%7c5d373707b8d6408f00b908d32dcbf04f%7c72f988bf86f141af91ab2d7cd011db4= 7%7c1&sdata=3DHkYLjr%2bpZbts%2fdRKcXSeM1WdO74TsRZMA4bL2WBYlZ8%3d > negotiation-02 <http= s://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2ftools.ietf.o= rg%2fhtml%2fdraft-ietf-tokbind-&data=3D01%7c01%7cAndrei.Popov%40microso= ft.com%7c5d373707b8d6408f00b908d32dcbf04f%7c72f988bf86f141af91ab2d7cd011db4= 7%7c1&sdata=3DHkYLjr%2bpZbts%2fdRKcXSeM1WdO74TsRZMA4bL2WBYlZ8%3d > negotiation-02>). This document defines a new TLS extension
> "token_binding", which needs to be added to the IANA "T= ransport Layer
> Security (TLS) Extensions" registry.
>
> Please note that this document also seeks to establish a registry for<= br> > identifiers of Token Binding key parameters entitled "Token Bindi= ng
> Key Parameters" under the "Token Binding Protocol" head= ing. This new
> registry is not part of the early assignment request.
>
> At this point, authors do not expect major changes in the "TLS > Extension for Token Binding Protocol Negotiation" specification. = There
> are at least two prototype implementations of this specification being=
> worked on (by Google and Microsoft). An early IANA code point
> assignment would facilitate implementation and deployment experience > prior to the publication of the RFC.
>
> Regards
> John Bradley





--001a113f3a8885a9fd05392ccc91-- From nobody Wed Aug 3 15:00: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 4139A12D0B4 for ; Wed, 3 Aug 2016 11:13:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-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_HI=-5, 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 AYdlS3JqCN_s for ; Wed, 3 Aug 2016 11:13:35 -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 A433512D5FC for ; Wed, 3 Aug 2016 11:13:35 -0700 (PDT) Date: Wed, 03 Aug 2016 11:09:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1470248014; bh=vto5D2QEwb8oP5sVn0J2quG1j/LT9dOetW9ltoN8sTo=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Ep6i0ow9FW0ld+QYf2+C55nP4CDPIoDK+eul8ookBBVcxLE3Z2p7QRvlhzlvQLkWI ORv9xKcsfSAa/sKVi8g6U+M8FrGGOReuBkjMzA2tDoH6moYCp0Q5Lcozbh4zh+BPTL FfCFp5xniVa0H8Y2rTph4Oc1hLscZr0p4tNU5o0E= From: Brian Campbell To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57a2334f69c52_52353fcb656652b822994cf"; 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: Wed, 03 Aug 2016 15:00:31 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] TBPROTO: provide some examples (#39) 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: Wed, 03 Aug 2016 18:13:40 -0000 ----==_mimepart_57a2334f69c52_52353fcb656652b822994cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here are a couple of TokenBindingMessages produced by Chrome Canary and v= alidated with code I wrote (so semi confident that they are correct). = **This one has a single ecdsap256 provided token binding :** TokenBindingMessage: `[0, 135, 0, 2, 64, 32, 73, 230, 99, 203, 36, 207, 2= 4, 103, 79, 159, 0, 238, 132, 135, 175, 167, 87, 165, 15, 130, 169, 136, = 57, 4, 210, 72, 101, 28, 230, 161, 187, 73, 244, 2, 99, 163, 248, 100, 60= , 63, 220, 98, 227, 57, 232, 238, 135, 8, 197, 7, 13, 248, 103, 46, 146, = 66, 56, 216, 158, 130, 85, 52, 113, 0, 64, 141, 140, 40, 147, 111, 16, 16= 1, 207, 132, 223, 89, 97, 189, 179, 243, 207, 120, 167, 175, 72, 0, 166, = 193, 207, 240, 24, 41, 85, 2, 80, 9, 7, 254, 133, 111, 68, 30, 146, 53, 6= 9, 198, 3, 170, 43, 168, 91, 65, 197, 79, 215, 207, 1, 77, 136, 114, 41, = 212, 125, 24, 249, 174, 18, 88, 190, 0, 0]` Base64url encoded TokenBindingMessage: `AIcAAkAgSeZjyyTPGGdPnwDuhIevp1elD= 4KpiDkE0khlHOahu0n0AmOj-GQ8P9xi4zno7ocIxQcN-GcukkI42J6CVTRxAECNjCiTbxChz4= TfWWG9s_PPeKevSACmwc_wGClVAlAJB_6Fb0QekjVFxgOqK6hbQcVP188BTYhyKdR9GPmuEli= -AAA` EKM: `[251, 106, 16, 126, 68, 133, 18, 244, 226, 13, 10, 209, 1, 7, 188, = 125, 102, 140, 227, 208, 169, 195, 152, 18, 160, 165, 86, 101, 35, 134, 2= 24, 166]` Base64url encoded EKM: `-2oQfkSFEvTiDQrRAQe8fWaM49Cpw5gSoKVWZSOG4KY ` **This one has a ecdsap256 provided and referred token binding:** TokenBindingMessage: `[1, 14, 0, 2, 64, 185, 78, 236, 69, 100, 221, 93, 1= 60, 223, 236, 230, 129, 26, 106, 218, 162, 159, 111, 14, 133, 214, 182, 1= 25, 237, 141, 121, 178, 38, 38, 142, 236, 183, 83, 144, 138, 53, 204, 23,= 158, 177, 216, 168, 207, 59, 61, 200, 165, 122, 2, 123, 58, 140, 93, 236= , 170, 98, 68, 100, 72, 167, 152, 194, 1, 122, 0, 64, 110, 161, 137, 8, 2= 54, 228, 94, 178, 154, 152, 44, 186, 82, 41, 125, 231, 190, 78, 224, 136,= 238, 71, 80, 239, 78, 176, 115, 22, 65, 216, 91, 249, 120, 53, 87, 89, 7= 5, 223, 246, 165, 27, 182, 0, 124, 174, 240, 2, 114, 139, 167, 111, 128, = 98, 240, 244, 115, 173, 37, 249, 233, 120, 76, 106, 6, 0, 0, 1, 2, 64, 82= , 225, 38, 192, 194, 224, 125, 173, 193, 178, 213, 119, 32, 176, 126, 112= , 196, 212, 85, 239, 108, 117, 31, 106, 227, 180, 126, 162, 51, 21, 128, = 212, 136, 132, 129, 2, 155, 89, 143, 244, 233, 52, 32, 166, 161, 121, 103= , 182, 212, 189, 191, 235, 68, 71, 199, 124, 183, 232, 223, 0, 69, 218, 2= 08, 179, 0, 64, 134, 244, 179, 39, 190, 58, 163, 55, 245, 95, 100, 217, 1= 22, 170, 130, 19, 72, 168, 197, 123, 199, 118, 13, 130, 103, 227, 22, 230= , 177, 16, 87, 78, 75, 39, 88, 28, 185, 226, 63, 40, 188, 105, 22, 116, 1= 51, 136, 156, 33, 16, 97, 214, 154, 79, 214, 148, 190, 212, 242, 42, 146,= 99, 212, 130, 87, 0, 0]` Base64url encoded TokenBindingMessage: `AQ4AAkC5TuxFZN1doN_s5oEaatqin28Oh= da2fe2NebImJo7st1OQijXMF56x2KjPOz3IpXoCezqMXeyqYkRkSKeYwgF6AEBuoYkI_uResp= qYLLpSKX3nvk7giO5HUO9OsHMWQdhb-Xg1V1lL3_alG7YAfK7wAnKLp2-AYvD0c60l-el4TGo= GAAABAkBS4SbAwuB9rcGy1XcgsH5wxNRV72x1H2rjtH6iMxWA1IiEgQKbWY_06TQgpqF5Z7bU= vb_rREfHfLfo3wBF2tCzAECG9LMnvjqjN_VfZNl6qoITSKjFe8d2DYJn4xbmsRBXTksnWBy54= j8ovGkWdJeInCEQYdaaT9aUvtTyKpJj1IJXAAA` EKM: `[234, 61, 72, 151, 56, 73, 156, 5, 160, 173, 240, 104, 217, 237, 18= 4, 217, 86, 77, 183, 171, 194, 35, 55, 74, 241, 159, 252, 213, 174, 223, = 92, 184]` Base64url encoded EKM: `6j1IlzhJnAWgrfBo2e242VZNt6vCIzdK8Z_81a7fXLg` --- 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/39#issuecomment-23= 7317839= ----==_mimepart_57a2334f69c52_52353fcb656652b822994cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Here are a couple of TokenBindingMessages produced by Chrome Canary an= d validated with code I wrote (so semi confident that they are correct). =

This one has a single ecdsap256 provided token binding :
TokenBindingMessage: [0, 135, 0, 2, 64, 32, 73, 230, 99, 203, 36, 2= 07, 24, 103, 79, 159, 0, 238, 132, 135, 175, 167, 87, 165, 15, 130, 169, = 136, 57, 4, 210, 72, 101, 28, 230, 161, 187, 73, 244, 2, 99, 163, 248, 10= 0, 60, 63, 220, 98, 227, 57, 232, 238, 135, 8, 197, 7, 13, 248, 103, 46, = 146, 66, 56, 216, 158, 130, 85, 52, 113, 0, 64, 141, 140, 40, 147, 111, 1= 6, 161, 207, 132, 223, 89, 97, 189, 179, 243, 207, 120, 167, 175, 72, 0, = 166, 193, 207, 240, 24, 41, 85, 2, 80, 9, 7, 254, 133, 111, 68, 30, 146, = 53, 69, 198, 3, 170, 43, 168, 91, 65, 197, 79, 215, 207, 1, 77, 136, 114,= 41, 212, 125, 24, 249, 174, 18, 88, 190, 0, 0]
Base64url encoded TokenBindingMessage: AIcAAkAgSeZjyyTPGGdPnwDuhIev= p1elD4KpiDkE0khlHOahu0n0AmOj-GQ8P9xi4zno7ocIxQcN-GcukkI42J6CVTRxAECNjCiTb= xChz4TfWWG9s_PPeKevSACmwc_wGClVAlAJB_6Fb0QekjVFxgOqK6hbQcVP188BTYhyKdR9GP= muEli-AAA
EKM: [251, 106, 16, 126, 68, 133, 18, 244, 226, 13, 10, 209, 1, 7, = 188, 125, 102, 140, 227, 208, 169, 195, 152, 18, 160, 165, 86, 101, 35, 1= 34, 224, 166]
Base64url encoded EKM: -2oQfkSFEvTiDQrRAQe8fWaM49Cpw5gSoKVWZSOG4KY<= /code>

This one has a ecdsap256 provided and referred token binding:<= /strong>
TokenBindingMessage: [1, 14, 0, 2, 64, 185, 78, 236, 69, 100, 221, = 93, 160, 223, 236, 230, 129, 26, 106, 218, 162, 159, 111, 14, 133, 214, 1= 82, 125, 237, 141, 121, 178, 38, 38, 142, 236, 183, 83, 144, 138, 53, 204= , 23, 158, 177, 216, 168, 207, 59, 61, 200, 165, 122, 2, 123, 58, 140, 93= , 236, 170, 98, 68, 100, 72, 167, 152, 194, 1, 122, 0, 64, 110, 161, 137,= 8, 254, 228, 94, 178, 154, 152, 44, 186, 82, 41, 125, 231, 190, 78, 224,= 136, 238, 71, 80, 239, 78, 176, 115, 22, 65, 216, 91, 249, 120, 53, 87, = 89, 75, 223, 246, 165, 27, 182, 0, 124, 174, 240, 2, 114, 139, 167, 111, = 128, 98, 240, 244, 115, 173, 37, 249, 233, 120, 76, 106, 6, 0, 0, 1, 2, 6= 4, 82, 225, 38, 192, 194, 224, 125, 173, 193, 178, 213, 119, 32, 176, 126= , 112, 196, 212, 85, 239, 108, 117, 31, 106, 227, 180, 126, 162, 51, 21, = 128, 212, 136, 132, 129, 2, 155, 89, 143, 244, 233, 52, 32, 166, 161, 121= , 103, 182, 212, 189, 191, 235, 68, 71, 199, 124, 183, 232, 223, 0, 69, 2= 18, 208, 179, 0, 64, 134, 244, 179, 39, 190, 58, 163, 55, 245, 95, 100, 2= 17, 122, 170, 130, 19, 72, 168, 197, 123, 199, 118, 13, 130, 103, 227, 22= , 230, 177, 16, 87, 78, 75, 39, 88, 28, 185, 226, 63, 40, 188, 105, 22, 1= 16, 151, 136, 156, 33, 16, 97, 214, 154, 79, 214, 148, 190, 212, 242, 42,= 146, 99, 212, 130, 87, 0, 0]
Base64url encoded TokenBindingMessage: AQ4AAkC5TuxFZN1doN_s5oEaatqi= n28Ohda2fe2NebImJo7st1OQijXMF56x2KjPOz3IpXoCezqMXeyqYkRkSKeYwgF6AEBuoYkI_= uRespqYLLpSKX3nvk7giO5HUO9OsHMWQdhb-Xg1V1lL3_alG7YAfK7wAnKLp2-AYvD0c60l-e= l4TGoGAAABAkBS4SbAwuB9rcGy1XcgsH5wxNRV72x1H2rjtH6iMxWA1IiEgQKbWY_06TQgpqF= 5Z7bUvb_rREfHfLfo3wBF2tCzAECG9LMnvjqjN_VfZNl6qoITSKjFe8d2DYJn4xbmsRBXTksn= WBy54j8ovGkWdJeInCEQYdaaT9aUvtTyKpJj1IJXAAA
EKM: [234, 61, 72, 151, 56, 73, 156, 5, 160, 173, 240, 104, 217, 23= 7, 184, 217, 86, 77, 183, 171, 194, 35, 55, 74, 241, 159, 252, 213, 174, = 223, 92, 184]
Base64url encoded EKM: 6j1IlzhJnAWgrfBo2e242VZNt6vCIzdK8Z_81a7fXLg<= /code>

&m= dash;
You are receiving this because you are subscribed to this thre= ad.
Reply to this email directly, view it on Git= Hub, or mute the thread= .3D""

= ----==_mimepart_57a2334f69c52_52353fcb656652b822994cf-- From nobody Wed Aug 3 18:04: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 2BF5712D112 for ; Wed, 3 Aug 2016 18:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 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, RP_MATCHES_RCVD=-1.287, 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 jmprFlMxxlZR for ; Wed, 3 Aug 2016 18:04:28 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 4E691128B44 for ; Wed, 3 Aug 2016 18:04:28 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id 35so165000640uap.1 for ; Wed, 03 Aug 2016 18:04:28 -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=0VDet3e/gDDYos1r1jwGNtyigOjQV8FCDcJUuiQ01Yo=; b=ByAsPLsJQiZw/9DiYNn7/A/vaUpt5LjKb3pbn76Z0gg9Fb333ejKIKWCqCIYUOFdxA EelvsDrzBVf8tGg64fKGfMK3Twf0jv9hG85tKkBBI/YUre1E6BPg6BTQOImnjM5xBUTM 5Yqgd1Gtwdp2T6Fw9CaWXf1UzlIFQiDX6eWR7XPfAjsAk2fh6Bo/l9KzIhgVgeRttazv F5M469SK/0yIa6062eMiknf6X/kAL49lH3YrUEHz2W9njtoZHH4clfW0e68K6CTAf/G3 pvwuCKx1+x34gqeuXVu3BXTS895KT0RKjGlvroS8pXd/VM9Vapzge0cheg4BzQUbqVCd gOJg== 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=0VDet3e/gDDYos1r1jwGNtyigOjQV8FCDcJUuiQ01Yo=; b=U43UnvhWjWT3xGzAf50HRzEicTXYBRps5KRY7mVeasWmDUIAQzQxw8ML6V0jr+sLpw jMzMT8eMBW/a8456+BuhIMQgpg+8Bai/vfFejNy0rhChkgS3aDZyrNEVoZzV0yOTu3G/ a3vJWzKWP8FyPc4iqCzIhh5pqimVd1XCad+hDar5rrGZ+asU+wHA3Gj4pTh1rHigJ6g9 k8qzkwmpmkBf3+DnECYCrlfXNX8MkGbBkHtCej4z7JOOLmdJz7ZrfLZ8sQhmF9yB0hTi QZIuTBrMGKAJSjboTHjT/iGuD2Vf6Ult1rJJ75afMla5g52IWQlDqZQIACnjpP9Uhquj 7gdQ== X-Gm-Message-State: AEkoousThok+N/Hmil0X9eTudlkAz1/LxJwBSVScCec9Th5CJak51gIVjpbYUGKfbbUfiFHgXFp7tGNgSqzkzyeE X-Received: by 10.176.82.219 with SMTP id w27mr173309uaw.121.1470272667111; Wed, 03 Aug 2016 18:04:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.148 with HTTP; Wed, 3 Aug 2016 18:04:06 -0700 (PDT) In-Reply-To: <974CF78E8475CD4CA398B1FCA21C8E99565A9F26@PRN-MBX01-4.TheFacebook.com> References: <974CF78E8475CD4CA398B1FCA21C8E99565A9DF7@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9EB0@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9F26@PRN-MBX01-4.TheFacebook.com> From: Nick Harper Date: Wed, 3 Aug 2016 18:04:06 -0700 Message-ID: To: Subodh Iyengar Content-Type: multipart/alternative; boundary=94eb2c1915ee0c26c3053934881e Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] migrations of token bindings 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, 04 Aug 2016 01:04:31 -0000 --94eb2c1915ee0c26c3053934881e Content-Type: text/plain; charset=UTF-8 I chatted with Subodh offline about how to do key migrations for Token Binding. We came up with the following as a potential change to be able to support migrating from one key type to another. When a client sends the Token Binding negotiation TLS extension, it includes with each key type whether or not it has a key of that type. Upon receipt of that extension, the server consults its list of supported key types in preference order (and filters it based on what the client sent). The server puts one or two values in its key_parameters_list: The key type at the top of the filtered list, and the highest key type on the filtered list that a client has a key for (these will be the same thing in most cases, in which case the server sends only one value). If the server sends two values, it must do so in this order (to indicate to the client what the server's preference is). When a client receives two values in the key_parameters_list from the server, the client generates a TokenBindingMessage with two provided TokenBindings. (This means that the client is generating a new keypair for one of the token bindings.) Once the client receives a successful response to the application layer request that contained that TokenBindingMessage (e.g. a 2xx or 3xx HTTP response for a request with a Sec-Token-Binding header), the client may discard the key of the type that was not first in the server's key_parameters_list. When a server receives a TokenBindingMessage with two provided TokenBindings, it must rebind the tokens sent by the client to be bound to the new key (this is identified as the key of the type that the server has ranked higher on its preference list). There is also some implementation guidance for client HTTPS Token Binding implementations. Since the same Token Binding key is used for all origins on an eTLD+1, but a request to one origin might only contain some of the tokens on that eTLD+1, the client needs to keep track of which keys for the eTLD+1 are used on which origins, and make sure that a key is not discarded until it is no longer used on any of the origins for that eTLD+1. Furthermore, if a key of a type T for an eTLD+1 has never been presented to a particular origin in that eTLD+1, the client must not indicate that it has a key of type T in the negotiation extension. This client side complication is to handle the scenario of multiple subdomains on an eTLD+1 which have different cookies. Consider a client and server that support key types T1 and T2 (with T2 preferred over T1), and a client that currently only has key K1 (of type T1) for multiple domains on that server. The client and server both wish to migrate to a new key K2 of type T2. In this example, the server runs foo.example.com and bar.example.com, which have different cookies. 1. Client sends negotiation extension with (T1, true) and (T2, false) when connecting to foo.example.com. Server responds with T2, T1. 2. Client generates new key K2 of type T2 for eTLD+1 example.com, no origin. (K1 is in the key store for eTLD+1 example.com, origins foo.example.com, bar.example.com.) 3. Client sends Sec-Token-Binding header with K1 and K2 as provided token bindings; server responds with a 2xx or 3xx response code. 4. Client updates key store so K2 has origin foo.example.com and K1 no longer has that origin (it only has bar.example.com listed as its origin). Now, on future connections, the client can send a negotiation extension with (T1, false), (T2, true) to foo.example.com, and foo.example.com will only send back T2. Note that when the client is deciding whether or not to indicate it has a key of a particular type, it is checking for a key of that type for that origin, and not for that eTLD+1. When the server connects to bar.example.com, it continues as follows: 5. Client sends negotiation extension with (T1, true), (T2, false), and bar.example.com responds with T2, T1. 6. Client sends Sec-Token-Binding header with K1 and K2 as provided token bindings; server responds with 2xx or 3xx response code. 7. Client updates key store to add bar.example.com as an origin for K2, and remove bar.example.com as an origin for K1. 8. Client sees that K1 has no more origins, and removes it from the key store. --94eb2c1915ee0c26c3053934881e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I chatted with Subodh offline about how to do key migrations for Token Bin= ding. We came up with the following as a potential change to be able to sup= port migrating from one key type to another.

When a client sends the To= ken Binding negotiation TLS extension, it includes with each key type wheth= er or not it has a key of that type.
<= br>
Upon receipt of that extension, th= e server consults its list of supported key types in preference order (and = filters it based on what the client sent). The server puts one or two value= s in its key_parameters_list: The key type at the top of the filtered list,= and the highest key type on the filtered list that a client has a key for = (these will be the same thing in most cases, in which case the server sends= only one value). If the server sends two values, it must do so in this ord= er (to indicate to the client what the server's preference is).

Whe= n a client receives two values in the key_parameters_list from the server, = the client generates a TokenBindingMessage with two provided TokenBindings.= (This means that the client is generating a new keypair for one of the tok= en bindings.) Once the client receives a successful response to the applica= tion layer request that contained that TokenBindingMessage (e.g. a 2xx or 3= xx HTTP response for a request with a Sec-Token-Binding header), the client= may discard the key of the type that was not first in the server's key= _parameters_list.

When a server receives a TokenBindingMessage with two= provided TokenBindings, it must rebind the tokens sent by the client to be= bound to the new key (this is identified as the key of the type that the s= erver has ranked higher on its preference list).

There is also some imp= lementation guidance for client HTTPS Token Binding implementations. Since = the same Token Binding key is used for all origins on an eTLD+1, but a requ= est to one origin might only contain some of the tokens on that eTLD+1, the= client needs to keep track of which keys for the eTLD+1 are used on which = origins, and make sure that a key is not discarded until it is no longer us= ed on any of the origins for that eTLD+1. Furthermore, if a key of a type T= for an eTLD+1 has never been presented to a particular origin in that eTLD= +1, the client must not indicate that it has a key of type T in the negotia= tion extension.

This client side complication is to handle the scenar= io of multiple subdomains on an eTLD+1 which have different cookies. Consid= er a client and server that support key types T1 and T2 (with T2 preferred = over T1), and a client that currently only has key K1 (of type T1) for mult= iple domains on that server. The client and server both wish to migrate to = a new key K2 of type T2. In this example, the server runs=C2=A0foo.example.com=C2=A0and=C2= =A0bar.example.com, which have different cookies.
2. Client generates new key K2 of type T2 for eTLD+1=C2=A0example.com, no origin. (K1 is in= the key store for eTLD+1=C2=A0example.com, origins=C2=A0foo.example.com,=C2=A0bar.example.com.)
3. Client sends Sec-Token-Binding header with K1 and K2 as provided tok= en bindings; server responds with a 2xx or 3xx response code.
4. Client updates key store so K2 has origin=C2=A0<= a href=3D"http://foo.example.com/" target=3D"_blank">foo.example.com=C2= =A0and K1 no longer has that origin (it only has=C2=A0bar.example.com=C2=A0listed as its ori= gin).
Now, on future connections, the = client can send a negotiation extension with (T1, false), (T2, true) to=C2= =A0foo.example.com, and=C2=A0foo.examp= le.com=C2=A0will only send back T2.
Note that when the client is deciding whether or not to indicate it has a= key of a particular type, it is checking for a key of that type for that o= rigin, and not for that eTLD+1.
When t= he server connects to=C2=A0bar.example.com, it continues as follows:
5. Client sends negotiation extension with (T1, true), (T2, f= alse), and=C2=A0bar.e= xample.com=C2=A0responds with T2, T1.
6. Client sends Sec-Token-Binding header with K1 and K2 as provided tok= en bindings; server responds with 2xx or 3xx response code.
7. Client updates key store to add=C2=A0bar.example.com=C2=A0as an ori= gin for K2, and remove=C2=A0bar.example.com=C2=A0as an origin for K1.
8. Client sees that K1 has no more origins, and removes it f= rom the key store.

--94eb2c1915ee0c26c3053934881e-- From nobody Thu Aug 4 15:22: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 6EF5212D88B for ; Thu, 4 Aug 2016 15:22:43 -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 v2n_QC70G9aD for ; Thu, 4 Aug 2016 15:22:41 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 9721B12D890 for ; Thu, 4 Aug 2016 15:22:41 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id x130so3279789ite.1 for ; Thu, 04 Aug 2016 15:22:41 -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=DYQBQ4sBen3+R0c/sceJZSgIQvTUUoCQM9zCgnU3m1M=; b=GQgzw3mRndOHVN4ynq1PZY19wpJLTFrOtjwORvFvIVkY94MTWaDV95rVeLrYnTJabu 2hPxx0Nm+BX5KR3TuROix9UcVJybt6bgJvoJqCyplXRuOlMe9X4QCXnhRSoqR3yL6aH9 T8Md/fvt7aj3CCXbeoMFxxlWFyMo2VvyrPGc0= 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=DYQBQ4sBen3+R0c/sceJZSgIQvTUUoCQM9zCgnU3m1M=; b=HvM2UHegbLeuI14RPiOEVfjK5vbOFWfesxyBE8OWJd+25KGwwV95OnbD6lyipxY5c+ aE7hfpmS0tpuLZYB21rqKbzTw0H0F+L6Y9fO8dQVf/OPfldoeCUQhNxaa4AHTiwMi7WU I36ye3PlYEfRCkYSMEkBUtiA/w6+uKz0r7nE48sWEBHx0MIFpFOCrOd824XldhglAnY5 HAFDzK6tmKwcdxiQgMe5m2I89fTmWHvUrP6gRSmcy9BmZi8vmTlYgk2t28hZ7ZhawFGg 03aXUF6LpZbLNyBiNfYCIlfeRn/pAdpIJZ8/V4lFst5G1+SP0xe1MgCUZFFHF23lVoX1 1dBg== X-Gm-Message-State: AEkoouuPiSJNSYHtjfTAx0w2p/p/dBhlA/Z10/oHAiOonsm2lWeTffsRVMmWZNbYxN9H43k8sCjUe0OMqTdlKYbh X-Received: by 10.36.33.197 with SMTP id e188mr393454ita.42.1470349360716; Thu, 04 Aug 2016 15:22:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Thu, 4 Aug 2016 15:22:10 -0700 (PDT) From: Brian Campbell Date: Thu, 4 Aug 2016 16:22:10 -0600 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary=001a1146ec4e57a45b0539466353 Archived-At: Subject: [Unbearable] support for different key parameters within the same TLD+1 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, 04 Aug 2016 22:22:43 -0000 --001a1146ec4e57a45b0539466353 Content-Type: text/plain; charset=UTF-8 It's possible (maybe even likely) that different servers supporting different TokenBindingKeyParameters will be deployed in the same TLD+1. I'm wondering if more guidance is needed around expected or desired behavior in such circumstances? For example, let's say a browser that supports all three key parameters has already established an ecdsap256 token binding with one.example.com. When it goes to make a request to two.example.com, should it offer only ecdsap256 in the key_parameters_list of the token_binding TLS extension? Or should it offer all supported key parameters in the key_parameters_list? The latter might imply that multiple Token Binding IDs are maintained by the client per TLD+1. --001a1146ec4e57a45b0539466353 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's possible (maybe even likely) that different = servers supporting different TokenBindingKeyParameters will be deployed in = the same TLD+1.

I'm wondering if more guidance is nee= ded around expected or desired behavior in such circumstances?

For = example, let's say a browser that supports all three key parameters has= already established an ecdsap256 token binding with one.example.com. When it goes to make a request to two.example.com, should it offer only ecdsa= p256 in the key_parameters_list of the token_binding TLS extension? Or shou= ld it offer all supported key parameters in the key_parameters_list? The la= tter might imply that multiple Token Binding IDs are maintained by the clie= nt per TLD+1.


--001a1146ec4e57a45b0539466353-- From nobody Thu Aug 4 15:29: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 3B4F712DB24 for ; Thu, 4 Aug 2016 15:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.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 Kd9liewxQIF1 for ; Thu, 4 Aug 2016 15:29:55 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 2511912DA8A for ; Thu, 4 Aug 2016 15:29:55 -0700 (PDT) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.11/8.16.0.11) with SMTP id u74MTsXC024121; Thu, 4 Aug 2016 15:29:54 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=JqtqxXMFz9y1rGeqBGelNcrQPE3lzM+MkjBvwYZTa5k=; b=nbJafpjHE8VzLcExUtmUXWP/AZi3BWlutXL3w4ipHqP/IejbcgKXoesinxyfmH6OOzfI JiXbHADNFiZf9xoQODoTSTU7hhnnsd5pEenHVkL2r+hNN4NXPRnr5e+RzHkOKYMfDLhh dF71otG3P9wVxUyTdDsB0ezq1RsGx6Z2BwY= Received: from mail.thefacebook.com ([199.201.64.23]) by m0001303.ppops.net with ESMTP id 24kka7bwxp-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 04 Aug 2016 15:29:54 -0700 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.29]) by PRN-CHUB10.TheFacebook.com ([fe80::c983:d64f:e422:461d%12]) with mapi id 14.03.0294.000; Thu, 4 Aug 2016 15:29:52 -0700 From: Subodh Iyengar To: Brian Campbell , IETF Tokbind WG Thread-Topic: [Unbearable] support for different key parameters within the same TLD+1 Thread-Index: AQHR7p67m9BwLbm/G0mw+10KE4aXFqA5YWfp Date: Thu, 4 Aug 2016 22:29:51 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E99565AB421@PRN-MBX01-4.TheFacebook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_974CF78E8475CD4CA398B1FCA21C8E99565AB421PRNMBX014TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-04_13:, , signatures=0 Archived-At: Subject: Re: [Unbearable] support for different key parameters within the same TLD+1 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, 04 Aug 2016 22:29:57 -0000 --_000_974CF78E8475CD4CA398B1FCA21C8E99565AB421PRNMBX014TheFac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nick and I were chatting about this particular case and the problem is a bi= t worse and a lot of guidance is needed for this. For example if you do non= overlapping token bindings on different domains within one TLD + 1 and sha= re a cert between them, if a browser coalesces connections between the doma= ins since their identity would be correct, token binding would fail. Subodh ________________________________ From: Unbearable [unbearable-bounces@ietf.org] on behalf of Brian Campbell = [bcampbell@pingidentity.com] Sent: Thursday, August 04, 2016 3:22 PM To: IETF Tokbind WG Subject: [Unbearable] support for different key parameters within the same = TLD+1 It's possible (maybe even likely) that different servers supporting differe= nt TokenBindingKeyParameters will be deployed in the same TLD+1. I'm wondering if more guidance is needed around expected or desired behavio= r in such circumstances? For example, let's say a browser that supports all three key parameters has= already established an ecdsap256 token binding with one.example.com. When it goes to make a request to two.example.com, shoul= d it offer only ecdsap256 in the key_parameters_list of the token_binding T= LS extension? Or should it offer all supported key parameters in the key_pa= rameters_list? The latter might imply that multiple Token Binding IDs are m= aintained by the client per TLD+1. --_000_974CF78E8475CD4CA398B1FCA21C8E99565AB421PRNMBX014TheFac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Nick and I were chatting about this particular case and the problem = is a bit worse and a lot of guidance is needed for this. For example if you= do non overlapping token bindings on different domains within one TLD + 1 and share a cert between them,= if a browser coalesces connections between the domains since their identit= y would be correct, token binding would fail.

Subodh
From: Unbearable [unbearable-bounces@ietf= .org] on behalf of Brian Campbell [bcampbell@pingidentity.com]
Sent: Thursday, August 04, 2016 3:22 PM
To: IETF Tokbind WG
Subject: [Unbearable] support for different key parameters within th= e same TLD+1

It's possible (maybe even likely) that different servers supporting di= fferent TokenBindingKeyParameters will be deployed in the same TLD+1.
I'm wondering if more guidance is needed around expected or desired be= havior in such circumstances?

For example, let's say a browser that supports all three key parameters has= already established an ecdsap256 token binding with one.example.com. When it goes to make a request to two.example.com, should it offer only ecdsap256 in the key_parameters_l= ist of the token_binding TLS extension? Or should it offer all supported ke= y parameters in the key_parameters_list? The latter might imply that multip= le Token Binding IDs are maintained by the client per TLD+1.


--_000_974CF78E8475CD4CA398B1FCA21C8E99565AB421PRNMBX014TheFac_-- From nobody Thu Aug 4 15:45:06 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 C0AB812B05A for ; Thu, 4 Aug 2016 15:45:05 -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 XEiSne6Y0tLM for ; Thu, 4 Aug 2016 15:45:03 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 37A2D12D5D0 for ; Thu, 4 Aug 2016 15:45:01 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id u186so8271849ita.0 for ; Thu, 04 Aug 2016 15:45:01 -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=5R4aFd3LvxUhi10sFcQ+rm6GSf5LePovh+iU4qEi7EY=; b=EN1S+SohKMN590jhQJxwntuaF8LfWZ28IjYSKEn+tEWCxHYDqYrH2Csv6TVkFK5KQ/ 3dNczMbiTcqf17kKATAXwCG4j7K3oP5HmkR/uqFAnwzTT9gpMl4pwIsc/R0txmGtI5xr hNG3sxsv/MfT0f/nqmQRZAspWVpquWFFZA0O8= 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=5R4aFd3LvxUhi10sFcQ+rm6GSf5LePovh+iU4qEi7EY=; b=SjgrPcLCw781tznqyfteUJevJsq4kQo9wzpXgT0fhHId7q+xiuKWeYO3fekPn5jrpx 4rjh3wKeSAzWbB0frtV67lREYUMEHH9EoEJO8lK21+xZKD93qbikkt3uqU3XQbk9UCpB MHA4pqv3QDmiT4vqhQv/TJ5EkeCmuHJo9A17ogTZmlsOWNXQgwaRolCOTYh0VJtBtrHR OE5DPEwhymbSwXQ5agbxBv52SymDE11kF1+oE6/8Q2ygCuQz0f9VA0JWFWOYffXgDdlk yoFg5olc/ksdHVtV39Z4WsJ57oqMP8EwHdDKsQer3JNAGM5WDkIMfBJlJWRg9Dh8fUZH PRkw== X-Gm-Message-State: AEkoouvj3hRne6wl26YCZSNFmIXbC8mDyC4m3h0DeGUNVFWc2VeDE6QuyOSdWskqMgHqI5dBc/rYd46X9gs8aQ8C X-Received: by 10.36.33.197 with SMTP id e188mr483392ita.42.1470350700529; Thu, 04 Aug 2016 15:45:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Thu, 4 Aug 2016 15:44:30 -0700 (PDT) In-Reply-To: <974CF78E8475CD4CA398B1FCA21C8E99565AB421@PRN-MBX01-4.TheFacebook.com> References: <974CF78E8475CD4CA398B1FCA21C8E99565AB421@PRN-MBX01-4.TheFacebook.com> From: Brian Campbell Date: Thu, 4 Aug 2016 16:44:30 -0600 Message-ID: To: Subodh Iyengar Content-Type: multipart/alternative; boundary=001a1146ec4e335dfa053946b331 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] support for different key parameters within the same TLD+1 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, 04 Aug 2016 22:45:06 -0000 --001a1146ec4e335dfa053946b331 Content-Type: text/plain; charset=UTF-8 My thinking about this was admittedly sparked by the migration thread between you and Nick (I'm still thinking about migration BTW). Forgive my ignorance here but how could browser coalesces connections to different domains if they are on different hosts (different IP addresses)? I guess I'm making the assumption that supported key parameters will be consistent per host at least. Ultimately though I guess we are on the same page that some additional guidance would be useful. On Thu, Aug 4, 2016 at 4:29 PM, Subodh Iyengar wrote: > Nick and I were chatting about this particular case and the problem is a > bit worse and a lot of guidance is needed for this. For example if you do > non overlapping token bindings on different domains within one TLD + 1 and > share a cert between them, if a browser coalesces connections between the > domains since their identity would be correct, token binding would fail. > > Subodh > ------------------------------ > *From:* Unbearable [unbearable-bounces@ietf.org] on behalf of Brian > Campbell [bcampbell@pingidentity.com] > *Sent:* Thursday, August 04, 2016 3:22 PM > *To:* IETF Tokbind WG > *Subject:* [Unbearable] support for different key parameters within the > same TLD+1 > > It's possible (maybe even likely) that different servers supporting > different TokenBindingKeyParameters will be deployed in the same TLD+1. > > I'm wondering if more guidance is needed around expected or desired > behavior in such circumstances? > > For example, let's say a browser that supports all three key parameters > has already established an ecdsap256 token binding with one.example.com > . > When it goes to make a request to two.example.com > , > should it offer only ecdsap256 in the key_parameters_list of the > token_binding TLS extension? Or should it offer all supported key > parameters in the key_parameters_list? The latter might imply that multiple > Token Binding IDs are maintained by the client per TLD+1. > > > --001a1146ec4e335dfa053946b331 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My thinking about this was admittedly sparked by the = migration thread between you and Nick (I'm still thinking about migrati= on BTW).

Forgive my ignorance here but how could browser= coalesces connections to different domains if they are on different hosts = (different IP addresses)? I guess I'm making the assumption that suppor= ted key parameters will be consistent per host at least.

Ultimately though I guess we are on the same page that some additional gui= dance would be useful.=C2=A0 =C2=A0

On Thu, Aug 4, 2016 at 4:29 PM, Subodh I= yengar <subodh@fb.com> wrote:
Nick and I were chatting about this particular case and the problem is a = bit worse and a lot of guidance is needed for this. For example if you do n= on overlapping token bindings on different domains within one TLD + 1 and share a cert between them, if = a browser coalesces connections between the domains since their identity wo= uld be correct, token binding would fail.

Subodh
From: Unbearable [unbearable-bounces@ietf.org] on behalf of Brian C= ampbell [bc= ampbell@pingidentity.com]
Sent: Thursday, August 04, 2016 3:22 PM
To: IETF Tokbind WG
Subject: [Unbearable] support for different key parameters within th= e same TLD+1

It's possible (maybe even likely) that different servers supportin= g different TokenBindingKeyParameters will be deployed in the same TLD+1.
I'm wondering if more guidance is needed around expected or desire= d behavior in such circumstances?

For example, let's say a browser that supports all three key parameters= has already established an ecdsap256 token binding with one.example.com. When it goes to make a request to two.example.com, should it offer only ecdsap256 in the key_parameters_l= ist of the token_binding TLS extension? Or should it offer all supported ke= y parameters in the key_parameters_list? The latter might imply that multip= le Token Binding IDs are maintained by the client per TLD+1.



--001a1146ec4e335dfa053946b331-- From nobody Thu Aug 4 15:49:27 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 D67F912D093 for ; Thu, 4 Aug 2016 15:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 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, RP_MATCHES_RCVD=-1.287, 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 MEk3NxoLNyRn for ; Thu, 4 Aug 2016 15:49:23 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 7E1D812B062 for ; Thu, 4 Aug 2016 15:49:23 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id j59so185063975uaj.3 for ; Thu, 04 Aug 2016 15:49:23 -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=umeabHdsiG6//7ZUAycbbG42lf0PLQsr2zxd+6ti56o=; b=JoLLNP5iRziLJzq8WzbsjYLGDmcqpd1Ggy1n2pOLgzu4y6yTY6t2sjpU4t++sbqCE5 LhZL0USPTZYlh5Pi7ziD+HyOm1XyMeZLqqqN2VRdRMNqL16L2tamsdCECr8OS0Dx9cl2 xHNRh/XDtZ5bKxOWHy+/m9sGW0AZ9caL+WwhmfF27YRUkuihEYgD2oJGh277DuIhnj7Q nNzio6VrgzBYVALAcyhkljENcgy4lGzqsjuS9qtutRumPpGqzLGJ6ziApMIczBhLkueL k33gkMzpIgk28Wz0ybukOAGpkbP2Hkalmw3xlCx9mRwkWC2goesxAvYTj27X8tbp8PCg Dbww== 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=umeabHdsiG6//7ZUAycbbG42lf0PLQsr2zxd+6ti56o=; b=Kj7omfUqI/sUkitNtIOZAH4IRNbFYN3ZYmjhU/ncvexNm/mGuXieF4rsusd5lJvrOo IBWaaHU8TV9K4ypZIr7TxqATHqoIn7BSenzs/Ps6pRzrFRNI0iXeO+Tv3o0QBmtDpVVB NCf/wKE5vbVgqebBHDYG4d4zuLTO6t9raP0IJz3GUuIBRePl2B9phAF46fwvv7LDi/av /wy1Wf3dawsk9pVJXdMownwR5OqHGW2RF3PKRuGldIhlmBmJeyGoBOO+pOA+oRbOqh1H eiFVhGY8eG6WQbZQSg82bJ7J0NIPapZkZz4DtQuXHJFicuyMSr+04n+9wnaQ5VsR5aoa cGmw== X-Gm-Message-State: AEkoouvAnRkiV0+rq2IjLHVtOO+N4NKTDH8ORTc8bWqjskpcrZ2SEUN1+ZDLUfXJLRcLr0WpVI7j17JXMdG2mXZC X-Received: by 10.176.2.242 with SMTP id 105mr5041835uah.10.1470350962338; Thu, 04 Aug 2016 15:49:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.148 with HTTP; Thu, 4 Aug 2016 15:49:02 -0700 (PDT) In-Reply-To: References: <974CF78E8475CD4CA398B1FCA21C8E99565AB421@PRN-MBX01-4.TheFacebook.com> From: Nick Harper Date: Thu, 4 Aug 2016 15:49:02 -0700 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=001a1142e550ceac26053946c2f4 Archived-At: Cc: IETF Tokbind WG , Subodh Iyengar Subject: Re: [Unbearable] support for different key parameters within the same TLD+1 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, 04 Aug 2016 22:49:26 -0000 --001a1142e550ceac26053946c2f4 Content-Type: text/plain; charset=UTF-8 I definitely think that more guidance is needed around what key parameters a client should advertise if it already has one key for that domain. If the same IP address is used to host multiple domains, and the cert covers multiple domains (e.g. one.example.com and two.example.com), then an H2 client can coalesce connections for one.example.com and two.example.com - i.e. use one connection for requests on both domains. My assumption is that if two domains are co-hosted like that, then they will support the same token binding key parameters (otherwise they'd be changing what they put in the server negotiation extension based on what the client sends in SNI, but otherwise sending the same cert, which seems a bit odd to me). On Thu, Aug 4, 2016 at 3:44 PM, Brian Campbell wrote: > My thinking about this was admittedly sparked by the migration thread > between you and Nick (I'm still thinking about migration BTW). > > Forgive my ignorance here but how could browser coalesces connections to > different domains if they are on different hosts (different IP addresses)? > I guess I'm making the assumption that supported key parameters will be > consistent per host at least. > > Ultimately though I guess we are on the same page that some additional > guidance would be useful. > > On Thu, Aug 4, 2016 at 4:29 PM, Subodh Iyengar wrote: > >> Nick and I were chatting about this particular case and the problem is a >> bit worse and a lot of guidance is needed for this. For example if you do >> non overlapping token bindings on different domains within one TLD + 1 and >> share a cert between them, if a browser coalesces connections between the >> domains since their identity would be correct, token binding would fail. >> >> Subodh >> ------------------------------ >> *From:* Unbearable [unbearable-bounces@ietf.org] on behalf of Brian >> Campbell [bcampbell@pingidentity.com] >> *Sent:* Thursday, August 04, 2016 3:22 PM >> *To:* IETF Tokbind WG >> *Subject:* [Unbearable] support for different key parameters within the >> same TLD+1 >> >> It's possible (maybe even likely) that different servers supporting >> different TokenBindingKeyParameters will be deployed in the same TLD+1. >> >> I'm wondering if more guidance is needed around expected or desired >> behavior in such circumstances? >> >> For example, let's say a browser that supports all three key parameters >> has already established an ecdsap256 token binding with one.example.com. >> When it goes to make a request to two.example.com, should it offer only >> ecdsap256 in the key_parameters_list of the token_binding TLS extension? Or >> should it offer all supported key parameters in the key_parameters_list? >> The latter might imply that multiple Token Binding IDs are maintained by >> the client per TLD+1. >> >> >> > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a1142e550ceac26053946c2f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I definitely think that more guidance is needed around wha= t key parameters a client should advertise if it already has one key for th= at domain.

If the same IP address is used to host multip= le domains, and the cert covers multiple domains (e.g. one.example.com and t= wo.example.com), then an H2 client can coalesce connections for one.example.com and two.example.com - i.e. use one connection for requests on b= oth domains. My assumption is that if two domains are co-hosted like that, = then they will support the same token binding key parameters (otherwise the= y'd be changing what they put in the server negotiation extension based= on what the client sends in SNI, but otherwise sending the same cert, whic= h seems a bit odd to me).

On Thu, Aug 4, 2016 at 3:44 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:
My thinking about this was admittedly spar= ked by the migration thread between you and Nick (I'm still thinking ab= out migration BTW).

Forgive my ignorance here but how co= uld browser coalesces connections to different domains if they are on diffe= rent hosts (different IP addresses)? I guess I'm making the assumption = that supported key parameters will be consistent per host at least.
Ultimately though I guess we are on the same page that some add= itional guidance would be useful.=C2=A0 =C2=A0

On Thu, Aug 4, 2016 at 4:29 PM, Subodh Iyengar <subodh@fb.com> wrote:
Nick and I were chatting about this particular case and the problem is a = bit worse and a lot of guidance is needed for this. For example if you do n= on overlapping token bindings on different domains within one TLD + 1 and share a cert between them, if = a browser coalesces connections between the domains since their identity wo= uld be correct, token binding would fail.

Subodh
From: Unbearable [unbearable-bounces@ietf.org] on beha= lf of Brian Campbell [bcampbell@pingidentity.com]
Sent: Thursday, August 04, 2016 3:22 PM
To: IETF Tokbind WG
Subject: [Unbearable] support for different key parameters within th= e same TLD+1

It's possible (maybe even likely) that different servers supportin= g different TokenBindingKeyParameters will be deployed in the same TLD+1.
I'm wondering if more guidance is needed around expected or desire= d behavior in such circumstances?

For example, let's say a browser that supports all three key parameters= has already established an ecdsap256 token binding with one.example.com. When it goes to make a request to two.example.com, should it offer only ecdsap256 in the key_parameters_l= ist of the token_binding TLS extension? Or should it offer all supported ke= y parameters in the key_parameters_list? The latter might imply that multip= le Token Binding IDs are maintained by the client per TLD+1.




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


--001a1142e550ceac26053946c2f4-- From nobody Thu Aug 4 16:53:40 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 DFD3E12D531 for ; Thu, 4 Aug 2016 16:53:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fb.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 9wgpP3l_YG77 for ; Thu, 4 Aug 2016 16:53:36 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (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 0921D12D125 for ; Thu, 4 Aug 2016 16:53:35 -0700 (PDT) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u74Nn8wl015180; Thu, 4 Aug 2016 16:53:33 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=NYP6EeOh0emsUkxFO2K5KrVxvdElsADfFUkSmxGC0/0=; b=Lw7w+8SUqtZ1O7P9zIkETAADuEXoLs6i6h2X5WH0H5eOl7xzI2S8ylGBjZHzhnjg75R1 3oOHO6eEDjmqAbPudru89TSoU6e4pIwTM6/wgOmODAr/yMydVCh3smkXbvKUNUI2uBEQ 4OFhp74jUT0I1Sser8kTu2hhZ8ijUAzoU1k= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 24kypqe1bm-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 04 Aug 2016 16:53:33 -0700 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.29]) by PRN-CHUB16.TheFacebook.com ([fe80::7948:a494:45d7:3dd9%12]) with mapi id 14.03.0294.000; Thu, 4 Aug 2016 16:53:30 -0700 From: Subodh Iyengar To: Nick Harper , Brian Campbell Thread-Topic: [Unbearable] support for different key parameters within the same TLD+1 Thread-Index: AQHR7qHWfLRoGofmrkycBUHv9Fk4sqA53N8A//+bBJI= Date: Thu, 4 Aug 2016 23:53:30 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E99565AB53E@PRN-MBX01-4.TheFacebook.com> References: <974CF78E8475CD4CA398B1FCA21C8E99565AB421@PRN-MBX01-4.TheFacebook.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_974CF78E8475CD4CA398B1FCA21C8E99565AB53EPRNMBX014TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-08-04_15:, , signatures=0 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] support for different key parameters within the same TLD+1 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, 04 Aug 2016 23:53:39 -0000 --_000_974CF78E8475CD4CA398B1FCA21C8E99565AB53EPRNMBX014TheFac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The Http2 spec allows this connection coalescing to happen. You can run 2 d= ifferent origins on the same IP address. Servers already use SNI informatio= n to determine which certificate to serve, similarly servers could also use= this to determine what token binding params could be negotiated. I'm defin= itely not endorsing this behavior :), but that it's possible. I agree with Nick and also think a section like Token binding deployment ad= vice would go a long way to prevent silly mistakes from service owners. Thi= s section could possibly say that you should use the same token bindings fo= r all domains within the eTLD + 1. It could also include guidance on migrat= ing token binding params as well which we're discussing on another thread. Subodh ________________________________ From: Nick Harper [nharper@google.com] Sent: Thursday, August 04, 2016 3:49 PM To: Brian Campbell Cc: Subodh Iyengar; IETF Tokbind WG Subject: Re: [Unbearable] support for different key parameters within the s= ame TLD+1 I definitely think that more guidance is needed around what key parameters = a client should advertise if it already has one key for that domain. If the same IP address is used to host multiple domains, and the cert cover= s multiple domains (e.g. one.example.com and two.example.com), then an H2 client can coalesce connections for one.example.com<= https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__one.example.com&d=3DC= wMFaQ&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN7fQ&m=3DLkbmWhNTDGL= IMa1qKiPgi1oQElW9SuFaekoMIdfY0-0&s=3DXz0qySs-UD_mfh0z8Y4P0X-23AGDMCfXabDRKh= CO4yI&e=3D> and two.example.com - i.e. use one connection for = requests on both domains. My assumption is that if two domains are co-hoste= d like that, then they will support the same token binding key parameters (= otherwise they'd be changing what they put in the server negotiation extens= ion based on what the client sends in SNI, but otherwise sending the same c= ert, which seems a bit odd to me). On Thu, Aug 4, 2016 at 3:44 PM, Brian Campbell > wrote: My thinking about this was admittedly sparked by the migration thread betwe= en you and Nick (I'm still thinking about migration BTW). Forgive my ignorance here but how could browser coalesces connections to di= fferent domains if they are on different hosts (different IP addresses)? I = guess I'm making the assumption that supported key parameters will be consi= stent per host at least. Ultimately though I guess we are on the same page that some additional guid= ance would be useful. On Thu, Aug 4, 2016 at 4:29 PM, Subodh Iyengar wrote: Nick and I were chatting about this particular case and the problem is a bi= t worse and a lot of guidance is needed for this. For example if you do non= overlapping token bindings on different domains within one TLD + 1 and sha= re a cert between them, if a browser coalesces connections between the doma= ins since their identity would be correct, token binding would fail. Subodh ________________________________ From: Unbearable [unbearable-bounces@ietf.org] on behalf of Brian Campbell = [bcampbell@pingidentity.com] Sent: Thursday, August 04, 2016 3:22 PM To: IETF Tokbind WG Subject: [Unbearable] support for different key parameters within the same = TLD+1 It's possible (maybe even likely) that different servers supporting differe= nt TokenBindingKeyParameters will be deployed in the same TLD+1. I'm wondering if more guidance is needed around expected or desired behavio= r in such circumstances? For example, let's say a browser that supports all three key parameters has= already established an ecdsap256 token binding with one.example.com. When = it goes to make a request to two.example.com, should it offer only ecdsap25= 6 in the key_parameters_list of the token_binding TLS extension? Or should = it offer all supported key parameters in the key_parameters_list? The latte= r might imply that multiple Token Binding IDs are maintained by the client = per TLD+1. _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable --_000_974CF78E8475CD4CA398B1FCA21C8E99565AB53EPRNMBX014TheFac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The Http2 spec allows this connection coalescing to happen. You can = run 2 different origins on the same IP address. Servers already use SNI inf= ormation to determine which certificate to serve, similarly servers could also use this to determine what token bi= nding params could be negotiated. I'm definitely not endorsing this behavio= r :), but that it's possible.

I agree with Nick and also think a section like Token binding deployme= nt advice would go a long way to prevent silly mistakes from service owners= . This section could possibly sa= y that you should use the same token bindings for all domains within the eTLD + 1. It could also include guidance on migrating token binding param= s as well which we're discussing on another thread. 

Subodh
From: Nick Harper [nharper@google.com] Sent: Thursday, August 04, 2016 3:49 PM
To: Brian Campbell
Cc: Subodh Iyengar; IETF Tokbind WG
Subject: Re: [Unbearable] support for different key parameters withi= n the same TLD+1

I definitely think that more guidance is needed around wha= t key parameters a client should advertise if it already has one key for th= at domain.

If the same IP address is used to host multiple domains, and the cert = covers multiple domains (e.g. one.example.com and two.example.com), then an H2 client can coalesce connections for one.example.com and two.example.com - i.e. use one connection for requests on both domains.= My assumption is that if two domains are co-hosted like that, then they wi= ll support the same token binding key parameters (otherwise they'd be chang= ing what they put in the server negotiation extension based on what the client sends in SNI, but otherwise= sending the same cert, which seems a bit odd to me).

On Thu, Aug 4, 2016 at 3:44 PM, Brian Campbell <= span dir=3D"ltr"> <bcampbe= ll@pingidentity.com> wrote:
My thinking about this was admittedly sparked by the migration thread = between you and Nick (I'm still thinking about migration BTW).

Forgive my ignorance here but how could browser coalesces connections = to different domains if they are on different hosts (different IP addresses= )? I guess I'm making the assumption that supported key parameters will be = consistent per host at least.

Ultimately though I guess we are on the same page that some additional= guidance would be useful.   

On Thu, Aug 4, 2016 at 4:29 PM, Subodh Iyengar <= span dir=3D"ltr"> <subodh@fb.com> wrote:
Nick and I were chatting about this particular case and the problem is= a bit worse and a lot of guidance is needed for this. For example if you d= o non overlapping token bindings on different domains within one TLD + 1 and share a cert between them, if= a browser coalesces connections between the domains since their identity w= ould be correct, token binding would fail.

Subodh
From: Unbearable [unbearable-bounces@ietf.org] on beha= lf of Brian Campbell [bcampbell@pingidentity.com]
Sent: Thursday, August 04, 2016 3:22 PM
To: IETF Tokbind WG
Subject: [Unbearable] support for different key parameters within th= e same TLD+1

It's possible (maybe even likely) that different servers supporting di= fferent TokenBindingKeyParameters will be deployed in the same TLD+1.
I'm wondering if more guidance is needed around expected or desired be= havior in such circumstances?

For example, let's say a browser that supports all three key parameters has= already established an ecdsap256 token binding with one.example.com. When it goes to make a request to two.example.co= m, should it offer only ecdsap256 in the key_parameters_list of the tok= en_binding TLS extension? Or should it offer all supported key parameters i= n the key_parameters_list? The latter might imply that multiple Token Binding IDs are maintained by the client p= er TLD+1.




_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
htt= ps://www.ietf.org/mailman/listinfo/unbearable


--_000_974CF78E8475CD4CA398B1FCA21C8E99565AB53EPRNMBX014TheFac_-- From nobody Thu Aug 4 17:05:29 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 301C812D86F for ; Thu, 4 Aug 2016 17:05:26 -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 anMRb_tjxT6n for ; Thu, 4 Aug 2016 17:05:22 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0098.outbound.protection.outlook.com [104.47.40.98]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF4512D812 for ; Thu, 4 Aug 2016 17:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buckeyemailosu.onmicrosoft.com; s=selector1-osu-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=r9XZaPfLM/lASWUGM9AIeg/5M0HI/9nTCUVko1FjP64=; b=nUp0+apKJYuS2fHu++tckLFRrAitG/W9AkQ4PWpoReEJyz+RKmJd+JZ0jJ/aGorPIjMxXLiXn300f/Ha32P1r50EBXsIbNH1OMm+uhhpjhadvsBD5eGYiZ70X0dDumDGvFnP8IFPLFnnUVjSMlOFY58mR0L6EbqLZh4BKVQEXxE= Received: from BY2PR01CA0049.prod.exchangelabs.com (10.255.242.39) by SN2PR01MB2207.prod.exchangelabs.com (10.166.209.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Fri, 5 Aug 2016 00:05:18 +0000 Received: from BY2FFO11FD034.protection.gbl (2a01:111:f400:7c0c::112) by BY2PR01CA0049.outlook.office365.com (2a01:111:e400:2c76::39) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.15 via Frontend Transport; Fri, 5 Aug 2016 00:05:17 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.222) smtp.mailfrom=osu.edu; fb.com; dkim=none (message not signed) header.d=none;fb.com; dmarc=bestguesspass action=none header.from=osu.edu; Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.222 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.222; helo=cio-tnc-pf08.osuad.osu.edu; Received: from cio-tnc-pf08.osuad.osu.edu (164.107.81.222) by BY2FFO11FD034.mail.protection.outlook.com (10.1.14.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.557.8 via Frontend Transport; Fri, 5 Aug 2016 00:05:18 +0000 Received: from CIO-TNC-HT07.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-pf08.osuad.osu.edu (Postfix) with ESMTPS id 739A42E007C; Thu, 4 Aug 2016 20:05:17 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::3ca1:e895:a165:1359%10]) with mapi id 14.03.0248.002; Thu, 4 Aug 2016 20:05:02 -0400 From: "Cantor, Scott" To: Subodh Iyengar , Nick Harper , "Brian Campbell" Thread-Topic: [Unbearable] support for different key parameters within the same TLD+1 Thread-Index: AQHR7qHWfLRoGofmrkycBUHv9Fk4sqA53N8A//+bBJKAAAPwsA== Date: Fri, 5 Aug 2016 00:05:02 +0000 Message-ID: <9846A6064BD102419D06814DD0D78DE1129DFAE8@CIO-TNC-D2MBX02.osuad.osu.edu> References: <974CF78E8475CD4CA398B1FCA21C8E99565AB421@PRN-MBX01-4.TheFacebook.com> , <974CF78E8475CD4CA398B1FCA21C8E99565AB53E@PRN-MBX01-4.TheFacebook.com> In-Reply-To: <974CF78E8475CD4CA398B1FCA21C8E99565AB53E@PRN-MBX01-4.TheFacebook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.14.29] x-header-sapphire: true Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:164.107.81.222; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(438002)(199003)(189002)(106116001)(54356999)(109096001)(8676002)(89122001)(356003)(76176999)(8746002)(246002)(7736002)(7846002)(7696003)(93886004)(90282001)(5001770100001)(47776003)(305945005)(19580395003)(8936002)(33656002)(7596002)(55846006)(75432002)(16796002)(50986999)(93346002)(3846002)(6116002)(46406003)(23726003)(189998001)(87936001)(92566002)(86362001)(2920100001)(2900100001)(2950100001)(66066001)(2906002)(97756001)(102836003)(586003)(50466002)(106466001)(5250100002)(4326007)(88552002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR01MB2207; H:cio-tnc-pf08.osuad.osu.edu; FPR:; SPF:Pass; PTR:cio-tnc-pf08.osuad.osu.edu; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD034; 1:Cm/31YppeRDKKV1UhV+RG5g1aa2BnJgQt3ksIn0Puq6FFLKOzETy0RH6SXgyXwGfiPwVgeHVCqKZJt/Lt4T7B6//LG9Yx4X9qjlZZr8BL5CzkNssTpSRVkHpoLxVpI94BefQtrWbcay/w4ClxG4fA8dyZkCxVGzjY3XCiCLEMjpxs7eOo5QtafUANxgJwlqRtFtcv7N9kZVsIIZi56JUd8OuZT911UwEOM9iLD/4C0uwU4e7gqo4lAT2kgclZuQYlipKX45riMxUpCnGB65rSRtQ3yD/i3z1M7kO6Lf26PtXwhwRpHvSHaL9gm0kjMdbC28PdmojK3XwOumI1P6MnhGEcAZOFozePq/VlTW2r6+kMHX//nb+XbqkuNLD81WiTOFwlAzQuhEOIHbZRgEde8MdZVLRZd3earJw/PQrJqqD0I9C9XNSjOZf+506T3fS23I8NxjyWCF1mttJ5bx5n+2NRXnZMhZR2PPSu8wO/HQ4t8bJn8m7O6hHi3Ek3dtVvFtCnI9eRxY7iI+mbeBDV4G4MlONuGYZRm3QLRJHV0I= X-MS-Office365-Filtering-Correlation-Id: 83a2e2de-0283-4436-db55-08d3bcc42f8c X-Microsoft-Exchange-Diagnostics: 1; SN2PR01MB2207; 2:tyz8+pW4IAZurQhDD3nUCx2EsAjcNamn896Oj0rIIzF5wIPu5gRvR95jmNiNP7Ozb/mNCI9im78q+IEuVR7LUlXmbF2smntDul+7rPi5kkfC73qnOkGhg/j7X3w+kC93t849k0tmLL5M82yfqGXjFxnr7PiwlJ4pTWStHWmMFuGX/YGgWVzfW9diijp1242v; 3:s/RiN0uNoYzEHB6u/hYshMxopZu4ClgppjTIz0heODIVO9+OS/EC49vF3tjnS622ZwvOf0akbbLgCC/l8agszDCGGdRmmIrWlUEkClYmtHZD2vGcs86SswLR95eAjUACpJ1OmnzTmqnsy9CaYucSXv8+4sOCQol4O7jmKtMFF6T8zblQs3oZS9imr7N2MHoMliQ9fCy1TA16vW3WRLGzbcQ2eO3yAm4wlF7z/9gB5WW4ljumlD8UJv72ZlqCQr3wPU1iEiS3k1OBT6shRncwTw== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:SN2PR01MB2207; X-Microsoft-Exchange-Diagnostics: 1; SN2PR01MB2207; 25:BVi/qRx1VRDImi6C4pvTxB29QJAHXiqGF9PzpY1/PTh952JUD1RwJZTMrpLRSv6hknIWP8zfFUGpt0vz2ve1LcyWu6xyo7SP12SRZQ6K6sj2OrTVtgMJlof/mS9S/ZZ8rhUpZmAHnJzQo0LCInKdoRlYthis6T/ES7xYTA8PyKwOWEM7yUB8naFaYehJbJALQDdnXKw6iTLbHMhQUQREwfwjFNRKN2z3NnSCO1r8ousAFI6ZVnittHTSOaGN+aGXpqw4AcyIX+9rgvtl7YROX1mrXsG/CIGFWGvy+bmYMA3fdw4UjOxKdKza3HdgN1MMJzIzCMl0zm4+XrzBcfcqieJJlDtt62WHS35DuK93MPc0EMBnYzRTwyL2xl76xCL48E8O+0X2BkOZFQXYcPQpYd8uEcJESBBT8V9DUk1A7fV54uLcQvY+wYQkRLYTpDV74SHlqSW/jsF4YFtXM7foV35t11GEuDnevGyBCtM/8KMWpMyahMgHJDJnyCs/n/bnY8BXJwhZUw6LuvPYWeJkQlHQpiZmAImjd9R0R51iay9qRcENdVqlqrBRzsaz76q6qsK8tsJBGI5pXxPOOWqh95pIrYyHp+tbfFKDgF0UqJxQ0eR64OVE+tPhihM4+TWZZuWjdN8+dmj1Wv3Ky7n6jTxWmS4vnMmqc36XvKMNPttvhppqIIoehL139GaV9VfmmqMWB+dcMB23X40Tm4O7Quk9Ewcu38hy19bkscM26DvOvV8xMMRVUzCZqbY+R+9A X-Microsoft-Exchange-Diagnostics: 1; SN2PR01MB2207; 31:MNWkHzaeIjn5V2h3w7Fntvul9q+FZB519KtvpA8oKqenWOzBk3ku1P6R1gtke4rMoVhVkvu2PlQG7ZRqd286HGCa2546VY1ETmkriL9njnMI9LyPE2kf5wa7LG3mXsHK6YKZFlr7ZZf424xNP77VKSobJHNElWkg55xPAo5m+1434mpHIKoDWPNXvU5LFTmCqt8Zk7WaMxnJ7AxaMLo7uijSRYwNWHbL76C3KAQDE58=; 20:LNOWpvqnhWnKjGDlocDqDUY46JW2g006s1xwnmoXNrHRXbRWGdcpSry0y4uVO8LVNwBZsTA/kzqjpObSlzhGTOOPCSYx3JB9DKLTwThexfRRpTNnoA9OZtn9i2kfnShkrv4Dvb6e8bGX5cHBW9zpVrA1cgWkl15JZx6Tr0pz0ZT/3Jii/pEqyg/XOmVs936it6BOn8vBeg4XUDI6yy/2/itbNMDwVLsJGWEVFFK2pKj9giEfDm1YvrhcticKWqcFi0oMrRNoyOECImwZyu6iI7EOdOvxwpdwpfrLBaGpYVcWuBoqJWUmk70RC7eEKgPugw6fPjqv70GRopzb0PTIpTTSpLcHhR02Dn2RaG8Rj8a+FEGdlJHeS6Hw6kHgmg+YoufRqngjurT13jPMAP2wAVQfynpERdi0bomu1fhnoyFEtfru4PstOG464MRhLougQSngxg/U9R5o/VIu2D8HTz/mRnOJgvHJxZrW0vfZCTwRCzPblMScBzFUj6om/gEB X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(92004823454550); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(13017025)(8121501046)(13018025)(13024025)(13015025)(13023025)(5005006)(3002001)(10201501046); SRVR:SN2PR01MB2207; BCL:0; PCL:0; RULEID:; SRVR:SN2PR01MB2207; X-Microsoft-Exchange-Diagnostics: 1; SN2PR01MB2207; 4:sAj0+aaldIRew8lm0n2ynFzEZuMZf6jTzZ/UB5lCJBlsIzJBpN5/F6slZIIVctfid+cyj2wRtXOKDsOR9Ezt2uCcgc+cJ2Y29NbbIEOglLwlD8QuHffN10MjE3mp18vD0raKMAQQponUDhmZX3la1kghZeqeIfQzymJnykUfBXx/sBuY+ivW6m6dOxQq/LOI/j2EW9WiBWIxvTY1A2twGsdRkjwM7eI+38PL74lc3ftJj4T0z7njSjhQgZLcGG9V3LkBYxDQwNW50BIXENVqnO3t8leHcwgaIQVHvgF0cCYvTR1cvVtZMfm3aWXYEY4Q0rHbYaWQ4qlv+wu95IGXISw9iOk7bReKoOk/4QpP7uZtTfnB9XYhNb7Mxu3Xz8UEHpq0S9KrstCgl+Uycgzs6Cl1beX4rNd08jcKfSaiBBNlY7yoRUDXwKhqHYd5jy8D0Pw7KhjhYEJe45cB6N/z6TvoBl0/ql5HFVf0H4e54VA= X-Forefront-PRVS: 0025434D2D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN2PR01MB2207; 23:7/W51mllj/ht6EsqM/aw6o6qjdxiyeALbdyyrIs18?= =?us-ascii?Q?HFTdAux4xP6FnocZe0oCJGX2JdvfwDQx4fsPCQLj/Wy82e6DiQnyuZffkXP3?= =?us-ascii?Q?XTCvyHYD9jQ1O1zpXqbd409ZY5qIuAi+b45ehRYBV43+YIljqx8uA82NpVe6?= =?us-ascii?Q?fFd0P8UB3stri1ZsQqgOc3/B3A48o/UWT2ni6yJ682byw2SaGbB+h2+9P2a0?= =?us-ascii?Q?5E7EalXCeuNIsstswTCvjJwY+Kbe8lQfym/YWSvx3LeXZjOqYsJTW7ptYvn8?= =?us-ascii?Q?UtCz4iMqHgxzYEZLUr3rcugj2cfcqJ/unTV/UzCifR2PnwIkac/M68M6vYFG?= =?us-ascii?Q?euSHLOPv1ygvYtwxLGhVJPwlJR+Lif0J8/HgJqD5t3R2a30pAiqxTTHeauW2?= =?us-ascii?Q?pW4Cos8UHr49+PRjTiSvXJ9SQxLXb6SqmXv5JQ5qT8MvMsVp3Aq+OZ9WBJkD?= =?us-ascii?Q?BVzZNTN2Po2E4BrimaCVVtZogcqYTrTbbOvd7FILKjLlE2GjXumbYdrxmZ1c?= =?us-ascii?Q?jVM4EyejCeawpxLEIisulYCCx6TXpGzWK7uO39ai+g0RE7GMsVm6ijGMmnik?= =?us-ascii?Q?8CAFxO0RI4XHev6FGK9XEVpEQr5QE2XDT10Za2ZxOqAXy62gym6JWs4N9iyk?= =?us-ascii?Q?GQpDiVZFIxSzccz5s6ZWnN/gv1Mhu8QvvKld34QN6H8PziTO/VSBNVFYZAmd?= =?us-ascii?Q?ZJFV4KEn64zXIE3u/mbUT7TA/6VpSnERK3xLAavHo8CJry0U7MUv6123D1w4?= =?us-ascii?Q?PqkZcFbnCpUqcG3QevtTuhPmYvw7zobZKIXiT3rWpPXuU2UYZ54KObLBBBoU?= =?us-ascii?Q?AHbgi8ZBiZq9+94jL0L6MYAnZYXZ+8DKB+9t3PC9buvQWZNEKhsb065l+tVn?= =?us-ascii?Q?3f9jgpJ6gk62Gsl3/71m6C0vPIWdkEFV0fvDaJ0Rb00bTWkw7yh4iGvhqRwS?= =?us-ascii?Q?T75KKrHfy9j1/t3rHckg7Mr2Q0XwuMx9mQvYKvN6+kMDWvzt7SZNhgCECGfv?= =?us-ascii?Q?CYV/VMRSkEMKO5KxKGXuOw0oLqkOceaeVt68bRzkP+P+Rg6NwPfuiOs0Z3z4?= =?us-ascii?Q?HJo13I38MqPsYnaByYI5C3fg8ooRF/rGWtiED5bTAM9C8DDer1NIRNxmztf7?= =?us-ascii?Q?aySIIRuwpjCEG1dG3xWcOltU/qmUTPBry7o+upab61MOcpFFKylpsDbBB2+o?= =?us-ascii?Q?G0KSsAGD+R0fWjZNWtacdRs9yq1FqJCX2QKm8F4nMkcqD/6t+yM4S7im3cJx?= =?us-ascii?Q?BwVTFuCP0nN7z/YOSRF637N2OqqkOWIQXCj/nSUJgluODUPf+h1+SDXyVYqN?= =?us-ascii?B?QT09?= X-Microsoft-Exchange-Diagnostics: 1; SN2PR01MB2207; 6:qGt43nea2tZXgC743vYFYJqo6vLndFxBQPib7ewY6ACtXkxhsHq4ksbXn+btneIdBBL2mD5uH7uqSWeMSTQr/7IBeob4YXiXWMEehkp/S4v96DAFqJqxNe/JF7nGDFUxY3mlOg4lKsgEcIyiYrC/t1/GopDR91uM9meDCiFNH426XEN1BK4vQZwMI+LYnSllCxmZSwnvjIC5q2y5uOzIiN/PHWtMnm414jTWuvRzahrH4KAdy50+0BR4E+ov/bT21DiQ7G7/iZqq8lCpf1Vj/Q0JQTfZuFS81YvxAgsstm8=; 5:ionYFdZl+ZSN7vkGaPY+O3fXFENwAtJWA8tW1UN/1dJl8X3y91NIk21OJv7nxx/ZpgfyDNUo3vERqEUgrUA8Cv3yxkw4MiMsDUYlyBpP7O/hZko9Nh6WnAIHXK27dQDAv/OSy5MsaVPZE/PHaJEeBA==; 24:1WfsNRS1dsl3VQe9ogqF8lk8YLjiEUUVmZiNwsUWzt/T6VC9Qhxq6wy/SAaPUCaXp5zfRMciyzDDs9hPuCvCXvCmt/a90sPiyS11OZPQh+A=; 7:vKUjR65hDugEWn6skhDH8Kmnij+PuLdHpNOQHam6jW0/pvZouZRKMaOp7Ikofj0HeeTLkdDp/VUYYE1Ez2WNHW0WIW9XslXhaMHtHuIyw0SqSVRNPEgDvyl43PY3zc2nW+qr0dPI+XpkFjCe0d+VNEGJJlNyzwmYasVom53Brct/U/14mI0YjHAb5mo17k4+blKrr8X31+buVbcAr9dqIgS2z6KjFceI65wTxpZo2LmtlotzS+B6sol3IowUHCsl SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN2PR01MB2207; 20:6XQoiLLQCsX/dGny38VNhCezgMyI8vz+2BqEQMlWKSZA6IUd63CaYJ0VOZ2jZJto3ndFy5LfDkXTMZdSecKmMF2w57UI4SxtuVwOpksJ7xpIHFiWN6Dm7sECoqMBnu1e2hB7BC/5vFAidRpUglXorLOetgem9icYzgwlSdAhNnA= X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2016 00:05:18.4872 (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.222]; Helo=[cio-tnc-pf08.osuad.osu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR01MB2207 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] support for different key parameters within the same TLD+1 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, 05 Aug 2016 00:05:26 -0000 > I agree with Nick and also think a section like Token binding deployment > advice would go a long way to prevent silly mistakes from service owners. > This section could possibly say that you should use the same token bindin= gs > for all domains within the eTLD + 1. I trust it's understood that at a large organization, there is no way to as= sume any relationship whatsoever between one.osu.edu and two.osu.edu. Diffe= rent software, departments, operating policies, everything. They may as wel= l not be related. This spec doesn't assume that a binding to one is equivalent to the other, = does it? That would be...really unfortunate. -- Scott From nobody Thu Aug 4 17:12: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 532D712D8B4 for ; Thu, 4 Aug 2016 17:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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.287, 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 KA3z3RGRAvjm for ; Thu, 4 Aug 2016 17:11:59 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::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 0C45712D5BF for ; Thu, 4 Aug 2016 17:11:59 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id n129so179751984vke.3 for ; Thu, 04 Aug 2016 17:11:58 -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=nA4DdZAqKsfYMf2a9DUZ99lf6QVjDb0GBLzE+r5zQ2w=; b=IVS/3IgTN29ms8NvnV/FSyghhT45d7f2TNNjzUsJa0zFxwimvDmzv6+60ftFUah2lk eIY6dplhbI/ZZ7hiAe9TQGGK3S+7mXiGjRCeQ9o3Fcx+wendFqBwTrogQqOJ34fxQi21 XTPquC8822adm2SvybksVV7vze0FGcG7GY3H53z6h5IF7U87JxQ0j3Op32SeGLUF9PFy RVK3AF/MS3+Xa2YFKJJ9sobouwLG5h5ZMec4O0gt/DIH55FMpib3ciZVuqrDm9d2Xqz0 cbYVdVHXVFF1BLGRsEVp7LZtcrzsfe3bCRyVF/jGTykzTRt3TUDuubryULQh41M1N8bS gL8w== 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=nA4DdZAqKsfYMf2a9DUZ99lf6QVjDb0GBLzE+r5zQ2w=; b=B7ep0qsyHCgvYxir1KIrLYCZLyWPEpv12D1CyX+M3iwDaFNfTe5Bss8kFy+zv6PBaP 56STzlBruvkKKL6BmLc3Dq41CpqYF9eeV0AsXrq0RLthz9HmLi2x3IAsTlbYNhV/TXpa zFYMmmKv6VUcHxiBaMoWYONHxGk+zxz9kxRuFr4GrdufC7IxOwKGPT6Kb1Vxp1tTyVcp WmTukXa+/MIbmsSaZuOu1t00cfx4TfLZtndvzCvEG/ObpVZMZRgFB89Q5WKWlqhgyUVg OHC/lFrqvpKcjr92bjmQtz0U6fpyPICDNc992BMw4M/Wh9uhq3vZFf45p+ud0IV+B+Da VhnQ== X-Gm-Message-State: AEkoouvDifgv3rj0ZGFsjxUG7G+zLJ9uFBzOFxcMDWH0Q00R3kIoiaxZR10TLz0k6iZ5fnBjd+B8FcEItSYF4BEH X-Received: by 10.31.99.1 with SMTP id x1mr4537713vkb.10.1470355917984; Thu, 04 Aug 2016 17:11:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.191.148 with HTTP; Thu, 4 Aug 2016 17:11:37 -0700 (PDT) In-Reply-To: <9846A6064BD102419D06814DD0D78DE1129DFAE8@CIO-TNC-D2MBX02.osuad.osu.edu> References: <974CF78E8475CD4CA398B1FCA21C8E99565AB421@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565AB53E@PRN-MBX01-4.TheFacebook.com> <9846A6064BD102419D06814DD0D78DE1129DFAE8@CIO-TNC-D2MBX02.osuad.osu.edu> From: Nick Harper Date: Thu, 4 Aug 2016 17:11:37 -0700 Message-ID: To: "Cantor, Scott" Content-Type: multipart/alternative; boundary=94eb2c07b1782fbafa053947ea3c Archived-At: Cc: IETF Tokbind WG , Subodh Iyengar , Brian Campbell Subject: Re: [Unbearable] support for different key parameters within the same TLD+1 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, 05 Aug 2016 00:12:01 -0000 --94eb2c07b1782fbafa053947ea3c Content-Type: text/plain; charset=UTF-8 The HTTPSTB spec says that token binding keys must be scoped at eTLD+1 (section 2.1). This means that if one.osu.edu and two.osu.edu support the same key params, a client will use the same token binding key with both. This is required so that token binding keys are scoped at the same level as cookies. The two domains are free to negotiate different key params if they want. The concern around H2 coalescing only applies if the two domain names point to the same IP address and the certificate lists both domain names in the SAN. If those conditions are met, I think it's reasonable to assume that there's a relationship between them, and require the two domains to negotiate the same token binding key params. On Thu, Aug 4, 2016 at 5:05 PM, Cantor, Scott wrote: > > I agree with Nick and also think a section like Token binding deployment > > advice would go a long way to prevent silly mistakes from service owners. > > This section could possibly say that you should use the same token > bindings > > for all domains within the eTLD + 1. > > I trust it's understood that at a large organization, there is no way to > assume any relationship whatsoever between one.osu.edu and two.osu.edu. > Different software, departments, operating policies, everything. They may > as well not be related. > > This spec doesn't assume that a binding to one is equivalent to the other, > does it? That would be...really unfortunate. > > -- Scott > > --94eb2c07b1782fbafa053947ea3c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The HTTPSTB spec says that token binding keys must be scop= ed at eTLD+1 (section 2.1). This means that if one.osu.edu and two.osu.edu suppo= rt the same key params, a client will use the same token binding key with b= oth. This is required so that token binding keys are scoped at the same lev= el as cookies. The two domains are free to negotiate different key params i= f they want.

The concern around H2 coalescing only appli= es if the two domain names point to the same IP address and the certificate= lists both domain names in the SAN. If those conditions are met, I think i= t's reasonable to assume that there's a relationship between them, = and require the two domains to negotiate the same token binding key params.=

On Th= u, Aug 4, 2016 at 5:05 PM, Cantor, Scott <cantor.2@osu.edu> w= rote:
> I agree with = Nick and also think a section like Token binding deployment
> advice would go a long way to prevent silly mistakes from service owne= rs.
> This section could possibly say that you should use the same token bin= dings
> for all domains within the eTLD + 1.

I trust it's understood that at a large organization, there is n= o way to assume any relationship whatsoever between one.osu.edu and two.osu.edu. = Different software, departments, operating policies, everything. They may a= s well not be related.

This spec doesn't assume that a binding to one is equivalent to the oth= er, does it? That would be...really unfortunate.

-- Scott


--94eb2c07b1782fbafa053947ea3c-- From nobody Thu Aug 4 17:34: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 AB2AD12D1EB for ; Thu, 4 Aug 2016 17:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 KGEQVBsAOvAl for ; Thu, 4 Aug 2016 17:34:27 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0123.outbound.protection.outlook.com [104.47.32.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8848F12D1AF for ; Thu, 4 Aug 2016 17:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buckeyemailosu.onmicrosoft.com; s=selector1-osu-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MdgJ4Q6Xlu8Fd4jdAnz6Q6Np3FYL8hJWpRwMHK6ZZeg=; b=XFm3H3jEfIf0JNf22b9txzJT7kOdQbqhyCtPPRL2fGq4QSWXa8t/SvCqe3wGd7fyC2qA70FyYtGyDyA8434xlRCTvyaiH77qd+5ptQXzdUvTWq0vSSZKqIxrSr3vrvU+gO51Ss97XLaXB2x6FuPMiPhC95qtWur2CSUF9mthuOI= Received: from CY1PR0101CA0001.prod.exchangelabs.com (10.162.170.11) by CO2PR01MB2200.prod.exchangelabs.com (10.166.91.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Fri, 5 Aug 2016 00:34:25 +0000 Received: from BN1BFFO11FD024.protection.gbl (2a01:111:f400:7c10::1:103) by CY1PR0101CA0001.outlook.office365.com (2a01:111:e400:51d0::11) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.15 via Frontend Transport; Fri, 5 Aug 2016 00:34:25 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.212) smtp.mailfrom=osu.edu; fb.com; dkim=none (message not signed) header.d=none;fb.com; 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 BN1BFFO11FD024.mail.protection.outlook.com (10.58.144.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.557.8 via Frontend Transport; Fri, 5 Aug 2016 00:34:25 +0000 Received: from CIO-KRC-HT01.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 970C76004C; Thu, 4 Aug 2016 20:34:24 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.03.0248.002; Thu, 4 Aug 2016 20:34:23 -0400 From: "Cantor, Scott" To: Nick Harper Thread-Topic: [Unbearable] support for different key parameters within the same TLD+1 Thread-Index: AQHR7qHWfLRoGofmrkycBUHv9Fk4sqA53N8A//+bBJKAAAPwsIAARdSA///BriA= Date: Fri, 5 Aug 2016 00:34:22 +0000 Message-ID: <9846A6064BD102419D06814DD0D78DE1129DFB50@CIO-TNC-D2MBX02.osuad.osu.edu> References: <974CF78E8475CD4CA398B1FCA21C8E99565AB421@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565AB53E@PRN-MBX01-4.TheFacebook.com> <9846A6064BD102419D06814DD0D78DE1129DFAE8@CIO-TNC-D2MBX02.osuad.osu.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.14.29] x-header-sapphire: true Content-Type: text/plain; charset="utf-8" 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)(7916002)(2980300002)(438002)(189002)(199003)(88552002)(19580395003)(7596002)(305945005)(15975445007)(2920100001)(2950100001)(7846002)(7736002)(66066001)(23676002)(2900100001)(4326007)(75432002)(2906002)(6116002)(93346002)(7696003)(102836003)(11100500001)(586003)(3846002)(16796002)(47776003)(55846006)(90282001)(87936001)(50466002)(86766002)(8936002)(356003)(109096001)(54356999)(110136002)(189998001)(93886004)(89122001)(76176999)(5250100002)(92566002)(50986999)(86362001)(106116001)(246002)(8676002)(33656002)(106466001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR01MB2200; H:cio-krc-pf05.osuad.osu.edu; FPR:; SPF:Pass; PTR:cio-krc-pf05.osuad.osu.edu; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD024; 1:kps3+ciBLlYjSf4Ct/BddIeEt5G2Z771FI8wr8mnXY0B6oAacWF7l9vmyNsANFfUydgNZsDZ5ffOwoBSqjbtEO+APgHr47GWgfJXV+K58Z182Ae0bf6ZhCHGFgqjZ3SkaKUjf0pC8vWM/XZBUCyGm4H+CWkOq4iP9Ie5FUtTon3iJfoViNFXiRtAOUc150b9u8Khz9XQo6u6ooQ3T5VS9r7+dki+/nMsJOoBPGPxE3TMCoLs9fx9sa2p1MtnzX4QvzNLZEa6yHhkhoQAiqEsx1rY9TvDQs4oC/7TmlKl2mGz39r0VVDwj7essmMKm9/pP9dnSQR4CuT8/U9aFHPs7F6eaYna8CepLtA0f8PLZcqxXWr5VPQO7pdOSwAEhfckxWUGq9wLAa/AS24J4fa8WPQDVrsB/oRV4oCJrApOSQBw/XWMQytNwdrAeXcda+1LF/uub2WKKHhAYwNCkqO5dTPTaJHk0cZOry5d0m2ddWsJ8C4WeF6rvMq3Ih21b0qgZayISVkwmKrf5pGjj4UqzQHmnFcbYQm1EksofpfkQDE= X-MS-Office365-Filtering-Correlation-Id: f3aef1bc-b7e0-4502-9854-08d3bcc840d1 X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2200; 2:cqz12QlOmPbRFOiyRBPjwuVeev9rPF6f0Hu3ajbr1WDG2/BrJfNAspdYUXmug2ci/2TCdH75X6vIHi8iSt+8f34QxHfr2eFotxw4usJP1j/D1PPScDoKHY4HW8bxQOiz0IcgHZihFJQYtuq16exlqqYCPR8+Ojd9ipcpCWu4kWbDuajjOPLPP8/QyWraUU1S; 3:eyN/V3XkLAvK8gNQuCAoNr+US7s70aUGHmueN79kxKcfzhXYwziDzBgJojX2keW+hq72XcGG39jlD2YakQwSuClIw4wW0ospbUwirrIT/tBUfGE5/4Zlhv1jGh02VWcsLI/F+yw0hyRon5qyU15EOtemKAP75IwzlswZwMHo4WJ3UB4oYdKK5ANTcMVg4wnWI8lnCwnYoonliezIqOytL/EXYdW0L7ORNxxGxpBALCpl8Mqlr46Ft23c5nSvfQb3EMyPO8WA4W2rTQM85WFLnQ== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:CO2PR01MB2200; X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2200; 25:bvtXaRvdLJzHqJl9gUz8LGoYpur8PH2llhMXBPtozIi1Xiiu33XK9A67G0M/gbTki76ZUZ1x2hLjk/8ucmWnSSMG961OPqCIiC8rX/iaiIiyBdYvL/W+ATl7/ZgDeKgvGBWM/3rMkrot27G6meHoTn4JtW5kLLN9FK9Ta4Xhpixm1DTXgh+BCzEF+Hr1z7IxSfriuVJuR4uiZV77FByuOsj7lMnrHwpQj2JAA1RCEVLqWIGkPiUAIGatuMKKfziUhfEIBkguOlhkmcZ6Z1vwYOT0QISqo4RlSrPCm1i3/51C8Hynbn9DvX2NYjwv5CLp4x6ItSHpwmMFADH1RZaTByWo7RZVP+qb61OmHAKso3537Yf2vusVCi52bnmykMtei18zcaJuTOejWVGevuETEFTimlPNWhQThtJEpWKaF9vQa1CxxnoC/96QUDa0COm+7/OUetrw1N2DWMYaMMoyCB1IutLuzBkiRvIf5i2Sx1VI54KB1SAmbYV1bz3+Wdknk8JmwDHQBmOzCINEKZpZSENJgxyBuDp82jSUx/U4IqubQeEL1Xs2eD3kl4lv4hPCCkPzsk9S1Y2dNqYuwjC9gt2S/3p/kqrJ7+KvNsRJzV2slQIkhcfHJwrMaSR9WRtUgGjNa85aFcYMKNimdpYLjsTmPFopsW5AWgbYb8DjDzdVEWiMztd5FR0ujUqe4I64V+3xXgI/pBVfxK9wngxUDIWebdJ6h9R7LFBlmxpeLLOYOXoV18aGk89A4JamsA/jThGAUS5fVk/DnfmCT/ruXPlrsLeak8xJ4X988PbRjwtjpEPxU56kRasNYTUgJJ4CK1+lN2YJw896vdHBbE+hqz/j2JDQZW/W3+bN0mgJZeQ= X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2200; 31:CDGzdnbbDbt+iWLW3GiKcGcq+seTEX43ulbk1P8FcdN2UTw4aC+xD3La+QNW+j4qyzQbkQcB6gai5akbvChw+CMzJwWLDf1lxhr0LSY4kMFAwTpGHU1F6rJZcUIXeaRq4Us6Y1wEAs/DzBcaqX16u3HpIH8mA8QYyFU/tAHoI90sEpsP74CVb/6IWm61ul5bPQ2od2nbbmmz/3AnkXWA/K9TnDD+/7mcQDDVKbgggtk=; 20:IaqFOur9tAzqCDy9Cx1WUgCB4aNWjmXwMpFxIrSVJxktioI1QgCI62iWHDPblUNqgAVPi2yP1MGIUOsxyxaNBobfWs857zfx43RAFtECBYfJFdmK163H8JArrOl0XnDp3p/ZA5e1t6lGZ3qdhZVbNurBsfQsxIF/T+e46AvhbWzAqq3WjPviD6B8fMT9fsaU2yJhssiPuUVfGOspnP+n88yHtkO7qE1aB1gKGCHvDDTANN7/3FVvq7DO6CnP4yiiuYjf+8N3ExRc/HLfrnkUOzSvhlVgo7LL4m/IaRS5/Umpmbk3ZC1fs7/ss4bF3sN2LIgpkZdDRcPwcBMBqx646JZd9V+0RIPkroPJ9KiKWGIoOuYCX1xndczxX3vqQpfFcb7rz+BGUhjSTj+lD5lC8doczfmkLc/zUSEpxt1jcgqSuVwz9TIeJmliTt91aRp/q9dnXwLpFkwA2d0/UNzEYQey5qsLYoXs8k9tn9Cd4ivx4E69xof2eiQdIpl97C0+ X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705)(92004823454550); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(13016025)(13024025)(13023025)(13018025)(8121501046)(5005006)(10201501046)(3002001); SRVR:CO2PR01MB2200; BCL:0; PCL:0; RULEID:; SRVR:CO2PR01MB2200; X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2200; 4:v8GCUfAWnlR1XwA7QdtYbKcssqDkefBqM3eQy4KCO8BwWok/tag+/OlnxGgZ+1smxdcYaYVr6Ksj+qYCRSjUCRzdefHOfka63I3sTOzmZbMp0fHbZebgYvgcWsnMclUFnC6dGhBYVWOzRWCdjOvZg3DQLY50EtkmGV7Xm7axFZhpGq1R1QFEufILhegtgsa4DlzrGl8pAQAa413ZHHeCXuHq/Sa18Ci2zqewRNolDGJ6IC4lH2A65bIHK7UnNNhN5m0UuaUwnYG4HsgnQPBTTQjJB5d0ZbN534NJ8MNMH2QVQKkHa4IcioKaiHyzbKjOMGIPR3+/cqUaJxzlkO8o0MO21gTc4Ov0DGF9zxTMRlTVRzNGERhOWbFZ0aRKXmbzqPFYdsC4Cgzgkuvwq+A49jiLZG3qLmAaOlJvrPtJ7zFd3M35uYxat2F/UWsw/C9DZEU1AFlSu7/val44pPNX5NguUB1MS9foyxJ73dG+RF1DMjJsKq7gC9e+caG7YIyT X-Forefront-PRVS: 0025434D2D X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjAxTUIyMjAwOzIzOkJ1Vnhhb1dFQjhtbXNOSFdRQkQ5RGFMN1Er?= =?utf-8?B?WjBMVmprT29VY1BmQlVCQ0pvUVdpa1A2bVI1cGNyZlNoRmViVyt3ZTArbDdJ?= =?utf-8?B?UThXWDJwZm02M21UU0N1YzkwdG51OERZTG0yOUxkMDdEOHNnUTV6dDM0dXR0?= =?utf-8?B?dHJya3lGbmZhRGIyZElObi9GS21DekZDS0F2QkpiWERzRUV6a2k3SGVQdjVJ?= =?utf-8?B?SVkzSUlXVnFNWjdPdnhWam40ckNuMk5UWHZtbG42c1ZFVGtxUzZ0Yit2dUFF?= =?utf-8?B?TnRyTHpjOTc4b1drRktNSlhuMEJwa3VKK0JWWDZPaktQeWREcW1IVTlGd1Bl?= =?utf-8?B?TzF0QjIvOFdMSFRXVXVJMzZRSjFEYS9xemQrMkpGZ2Y4bW9vRkxVTG15MkJE?= =?utf-8?B?TkMrdkhzQUxDWnpwN1FEdUkvUmtHZExiU2tDOUpMNnZ6QnYwVWR0SFJNUWxn?= =?utf-8?B?SllVWk5YUlRlUDk4VFVlWHlHdHhiNTVkM1cxdnJxVm55c2FPNnRsK1BQYWRP?= =?utf-8?B?cU14WnI1SHdyVkJUY1NZd2I5WnArR2JMSC9nTy9UeXdaTzRDMG4rNllWcUZ5?= =?utf-8?B?SFg4aG90M2R6eW5pYXd6MU4rUjFJaS9DYmVYUWRHTmE2NGJCRHVuY053Zk9I?= =?utf-8?B?eWRsdDg2TzJLbjRoZXFWYVNnN1NTa3k4azVRQmhrVFFMN0RwNjQxR3pvNmVJ?= =?utf-8?B?bmJEVkJad2JtanM1OHMxZlNKMUNJK0JDQnQwbU5jbzcwTW1kRmp2ZnZNajVq?= =?utf-8?B?V3pweWp5THpueGZQK2F0czdDSTVDa3JBZEM4a3hSZkswRU44M3ZScnFCNGxE?= =?utf-8?B?TzlzR0xvZmorU3hZYkxzZUk2SjAycHZNTnV4aUZ5czJzaFBlNUg1MWxjTWxx?= =?utf-8?B?Qjdnd08wTFZzQVhPajR2NEpwUmViQ1NyQlg3bTZrQys3eG9YYktVenZCSitv?= =?utf-8?B?WHlGVkxFSFFOeHRTSjBlZmN0dS9OTUJ2eEQ2UU5GWWtmdUVpVC9yZ2VrTUk0?= =?utf-8?B?TWdpLzc1ckIxM2YwM0RpeVptNThYTmRzcmRXTkZOa2hpNzZyckcyZzVmQjR2?= =?utf-8?B?UFBaS3dZZDZDNzM3U2JwV0VsdUZGdWQzcTY4Z21qMG40WGQzbTYrNWUwYVZM?= =?utf-8?B?b2IxT09rTU9qVnBveTV4TmpXOHd4Ny9icU0zenZnakJLK2xBSnFyUU9saHVZ?= =?utf-8?B?VGgyTnpCWTlybmI4azZ0M0NYTjg5aENGMjd5ZHVRSkVNdElkRDZpanFSNFpR?= =?utf-8?B?VlJVYWtmeUk4WmVUSVc3YWYrSDVMV2ZITGZMQ3FvT3QrVkdvOFlONzdkR3kr?= =?utf-8?B?b0lTbnp1bDV6SnFqYlpSVzhKT1IzN1BOMjdnN0NjMVJHWUVZN2hhTFlaMWdM?= =?utf-8?B?anc1MWZSYTZuWGJwU3BkaDhPU3dZZmdJRnZPenR5Vk5YVzlRK2ZYQUxpOGtK?= =?utf-8?B?NjJhQkRJcjBxNUhycW9xZVZXZEk5S25DR2RWMkJPaTV3Z0lzQ2JCbXhLYlJp?= =?utf-8?B?enVCYnZNR3h3bVdKaUZyTENWdlpDT0J6UzF6VmZDSk5pOEl3WWpOend5a00r?= =?utf-8?B?b0pUY0J4MmVKV3Z0UDdEd3crMlNSYjNDUEwrMjFTMnNQY3o2UnlTYm5jNmgx?= =?utf-8?B?TXZSYk1tZElobmFVUXg4QnVBNXVnZE1EdjhRTm9lVzFoQ0ZlaEx6aGYwWHN6?= =?utf-8?B?Q2dzQmg2TUlYbjZvclJUYVhrbUF4OFlPaFdhM2gxKzZpQXc5T2JVZHhZRnZE?= =?utf-8?B?dEozTjNsVk1IUmRKenExdz09?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2200; 6:ujnILQFNabHQogChkIlNEHLDenVa0TijP9ee7KrDGtTGXp4r/DkO3hWfD2JRlwp1Xn0tTsdURDkbu8ZBr5VkR2Lcf+o4mgEClXqUM9GcIZJnqU7Ej4y8m/FAqhoKqt+cJMLiX21XTPZLq0/kkudmrJQwgNWlQC+RUoMaF373TzvAK8EtEKGyQKfb6pNvhXuJo9RyRN9rQ51ZQEEybYbKseGQYYxvZ2Ven87KZri+FA49UpOWzq2k2fNLMBbaNwC8eK5fn3O7vXaRBjWzTwIa10wwm7wOIWqohRCAaiA6aQo=; 5:eYsTSE1BxI+9cLgJIWWHDB9aiCRCRwvYxw6qdl1Nk82aLSt37YoQlTUi16XCC9Ee5A84moQwB9aBb0g5iF2V2GnsCRHvpqD3ukpdwPP394hxzXjSMK6JQFZnuJpRc7XSmgZBQN7Sg9iWrzcElDuO8Q==; 24:PA+qjbggtnQWyxq5qWKWpH7krpZK+k66xxLOx2sZuoVjGRUQsV5V8KSiGOJYwMmH9ShRhEZGUztamU0DM0jdIgDzN/xrL4rsxtgxmjGlo60=; 7:mw3Out0ynxTOK4plrerRjhQ0K3KWx6wPWlvE2bqyOKCiNQo7inXljNJ/9hJzQQBtyUUUZWoyv6ku3OYlvDdBE6znlUUWM17/uOTVB/dvIZjr6AvfjizGEd74P4tTHUguxcBjDLFA3FnCjujTiUa455Ov7Z8fxk2aFjTTg+MlUQwLC/LkzpELsNaHgcdwG6QN93e2ABvsfJ4aWRX+KWjonwYPI9aAo9bPLnNQWETRhn0JtP5PIK/dQobD5wAMQrO0 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2200; 20:h5+t+uAEE5iulKzyvi3OPkys2XsgttwVYwGNp8ifm0QfRkHSWuQkmihAurWIqyAy1gDnavju/BzgEd14FJL+/5LoP3V2hBxe0VLuDMdN4g3we4r0z+Dd+wqae6dlpfz+5uIDMROrkI25zcTR6hdu30VYnoOTvSUkIr/jltLAt+A= X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2016 00:34:25.5082 (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: CO2PR01MB2200 Archived-At: Cc: IETF Tokbind WG , Subodh Iyengar , Brian Campbell Subject: Re: [Unbearable] support for different key parameters within the same TLD+1 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, 05 Aug 2016 00:34:30 -0000 PiBUaGUgSFRUUFNUQiBzcGVjIHNheXMgdGhhdCB0b2tlbiBiaW5kaW5nIGtleXMgbXVzdCBiZSBz Y29wZWQgYXQgZVRMRCsxDQo+IChzZWN0aW9uIDIuMSkuIFRoaXMgbWVhbnMgdGhhdCBpZiBvbmUu b3N1LmVkdSA8aHR0cDovL29uZS5vc3UuZWR1PiAgYW5kDQo+IHR3by5vc3UuZWR1IDxodHRwOi8v dHdvLm9zdS5lZHU+ICBzdXBwb3J0IHRoZSBzYW1lIGtleSBwYXJhbXMsIGEgY2xpZW50DQo+IHdp bGwgdXNlIHRoZSBzYW1lIHRva2VuIGJpbmRpbmcga2V5IHdpdGggYm90aC4gVGhpcyBpcyByZXF1 aXJlZCBzbyB0aGF0IHRva2VuDQo+IGJpbmRpbmcga2V5cyBhcmUgc2NvcGVkIGF0IHRoZSBzYW1l IGxldmVsIGFzIGNvb2tpZXMuDQoNCktleSBwYXJhbXMgbWVhbmluZyB0aGUgYWN0dWFsIGtleT8g QWNjb3JkaW5nIHRvIHRoZSBkcmFmdCwgSSB0aG91Z2h0IGl0IHJlZmVycmVkIHRvIHRoZSB0eXBl IG9mIGFsZ29yaXRobSBiZWluZyBhcHBsaWVkLCB3aGljaCBpcyBhIHZlcnkgbGltaXRlZCBzZXQs IGFuZCBjZXJ0YWlubHkgZG9lc24ndCBpbXBseSBhbnkgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhl IHNlcnZlcnMuDQoNCj4gVGhlIHR3byBkb21haW5zIGFyZSBmcmVlIHRvIG5lZ290aWF0ZSBkaWZm ZXJlbnQga2V5IHBhcmFtcyBpZiB0aGV5IHdhbnQuDQoNCk1heWJlIEkgZG9uJ3QgdW5kZXJzdGFu ZCB3aGF0IGtleSBwYXJhbXMgbWVhbnMuIEknbSBub3QgdGhhdCBmYW1pbGlhciB3aXRoIHRoZSBt YXRlcmlhbCB5ZXQsIGJ1dCBpdCdzIGRlZXBseSB3b3JyeWluZyB0byBzZWUgcGVvcGxlIHJlZmVy IHRvIGVUTEQrMSBhcyBhIHNlY3VyaXR5IHVtYnJlbGxhLg0KDQo+IFRoZSBjb25jZXJuIGFyb3Vu ZCBIMiBjb2FsZXNjaW5nIG9ubHkgYXBwbGllcyBpZiB0aGUgdHdvIGRvbWFpbiBuYW1lcw0KPiBw b2ludCB0byB0aGUgc2FtZSBJUCBhZGRyZXNzIGFuZCB0aGUgY2VydGlmaWNhdGUgbGlzdHMgYm90 aCBkb21haW4gbmFtZXMgaW4NCj4gdGhlIFNBTi4gSWYgdGhvc2UgY29uZGl0aW9ucyBhcmUgbWV0 LCBJIHRoaW5rIGl0J3MgcmVhc29uYWJsZSB0byBhc3N1bWUgdGhhdA0KPiB0aGVyZSdzIGEgcmVs YXRpb25zaGlwIGJldHdlZW4gdGhlbSwgYW5kIHJlcXVpcmUgdGhlIHR3byBkb21haW5zIHRvDQo+ IG5lZ290aWF0ZSB0aGUgc2FtZSB0b2tlbiBiaW5kaW5nIGtleSBwYXJhbXMuDQoNClllcywgSSBh Z3JlZSB3dGggdGhhdC4NCg0KLS0gU2NvdHQNCg0K From nobody Thu Aug 4 17:40: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 433F712DB59 for ; Thu, 4 Aug 2016 17:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 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, RP_MATCHES_RCVD=-1.287, 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 6n229b6h0Tlq for ; Thu, 4 Aug 2016 17:40:18 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 1036A12DB51 for ; Thu, 4 Aug 2016 17:40:18 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id 35so186767568uap.1 for ; Thu, 04 Aug 2016 17:40: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=SuFSibrI9Wnm+T6t7OflL0VO9YdZuOX7Bw4+grmMEBo=; b=UajI5WIbXeKCpz6JYqzZUVTYY/tDj54AnlKq8I0QFDtSnJIqHkyDnVFovQbFdyuAJR 0zO6lTfWb699yDQ/x2VYkf/+StCwuyvkiHS2zWhxQR6yPQTA9kuz/vWaGZ2zxQg5MzuX a+P5NdiTwixI1WclvHX2AKDC31cfIAn1LsS6DZiW0FHktaPEvW+0PQmnpBxnFEyu7qa5 Drj0ZYVAAylWgDOhs3UuEFSUj7lmzJTRctnJUjOgYHTgQJeHe+Yxevkhmiu6imHewLF3 ikBhYNj0p+ZJSXB41FOpCl0nOUdd2KGvgEHvqiIj69QbmxQ9dYUboCu7wRVC6Ad8Og3t F5nw== 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=SuFSibrI9Wnm+T6t7OflL0VO9YdZuOX7Bw4+grmMEBo=; b=mjtuMRyXy6TSoRhxhWA7Nlte1d/C6l1vxGkuW9jSTDTkedxVbBcwFP7VcgRZyoG8ei ivpshiqZTV12fVcf3TcDenh2odZlcntRLbyYdsGmgBPv9fUFue35lY+f4Akz81izetwr hVsCeSiYMBnSLTWG5Vka+iSUWJEBrrh2OIIrAKiX6KHJQ0V3ju7xY4nCZcKIMyfY2/W2 vew9pav6mIh6QThajhzNt6hdfhcmwGFahGEbZ21P4H1qdnOpQok5o56UWSwf2JVwcu4p mQuY1tV330c1L2RR/djkCPuTTHa7iOovewpM9a5rY+5IZZmfrn+3MAa7MQhqH/IRnA1h FKjg== X-Gm-Message-State: AEkoouu6+Bu6PazGxy/NdyG0GFiPr/NLV4kj4UTJy9PBd9rAtwfFoSy1isgGUoM/EPPaxaAuVjMaXMvFcJJ6IjMv X-Received: by 10.176.82.226 with SMTP id w31mr3499983uaw.104.1470357616964; Thu, 04 Aug 2016 17:40:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.86.198 with HTTP; Thu, 4 Aug 2016 17:39:56 -0700 (PDT) In-Reply-To: <9846A6064BD102419D06814DD0D78DE1129DFB50@CIO-TNC-D2MBX02.osuad.osu.edu> References: <974CF78E8475CD4CA398B1FCA21C8E99565AB421@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565AB53E@PRN-MBX01-4.TheFacebook.com> <9846A6064BD102419D06814DD0D78DE1129DFAE8@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129DFB50@CIO-TNC-D2MBX02.osuad.osu.edu> From: Nick Harper Date: Thu, 4 Aug 2016 17:39:56 -0700 Message-ID: To: "Cantor, Scott" Content-Type: multipart/alternative; boundary=94eb2c190c5c73fee90539484f61 Archived-At: Cc: IETF Tokbind WG , Subodh Iyengar , Brian Campbell Subject: Re: [Unbearable] support for different key parameters within the same TLD+1 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, 05 Aug 2016 00:40:28 -0000 --94eb2c190c5c73fee90539484f61 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 4, 2016 at 5:34 PM, Cantor, Scott wrote: > > The HTTPSTB spec says that token binding keys must be scoped at eTLD+1 > > (section 2.1). This means that if one.osu.edu and > > two.osu.edu support the same key params, a client > > will use the same token binding key with both. This is required so that > token > > binding keys are scoped at the same level as cookies. > > Key params meaning the actual key? According to the draft, I thought it > referred to the type of algorithm being applied, which is a very limited > set, and certainly doesn't imply any relationship between the servers. > Key params means the type of key (e.g. RSA-PSS or ECDSA P256). The keys themselves are scoped to eTLD+1 - see draft-ietf-tokbind-https-05 section 2.1 for the wording. Suppose we have a client that only supports P256 keys (e.g. Chrome). If this client negotiates token binding with both one.osu.edu and two.osu.edu, then it will use the same key for both, because the key is scoped to osu.edu. This is the same as with cookies: a client could connect to one.osu.edu which sets a cookie on the domain osu.edu, and on a future connection to two.osu.edu, that server can read the cookie that one.osu.edu set. > > > The two domains are free to negotiate different key params if they want. > > Maybe I don't understand what key params means. I'm not that familiar with > the material yet, but it's deeply worrying to see people refer to eTLD+1 as > a security umbrella. > > > The concern around H2 coalescing only applies if the two domain names > > point to the same IP address and the certificate lists both domain names > in > > the SAN. If those conditions are met, I think it's reasonable to assume > that > > there's a relationship between them, and require the two domains to > > negotiate the same token binding key params. > > Yes, I agree wth that. > > -- Scott > > --94eb2c190c5c73fee90539484f61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 4, 2016 at 5:34 PM, Cantor, Scott <cantor.2@osu.edu>= wrote:
> The HTTPSTB spec says that token binding keys must be = scoped at eTLD+1
> (section 2.1). This means that if one.osu.edu <http://one.osu.edu&= gt;=C2=A0 and
> tw= o.osu.edu <http://two.osu.edu>=C2=A0 support the same key params, a= client
> will use the same token binding key with both. = This is required so that token
> binding keys are scoped at the same level as cookies.

Key params meaning the actual key? According to the draft, I thought= it referred to the type of algorithm being applied, which is a very limite= d set, and certainly doesn't imply any relationship between the servers= .

Key params means the type of key (e.g= . RSA-PSS or ECDSA P256). The keys themselves are scoped to eTLD+1 - see=C2= =A0draft-ietf-tokbind-https-05 section 2.1 for the wording. Suppose we have= a client that only supports P256 keys (e.g. Chrome). If this client negoti= ates token binding with both one.osu.edu= and two.osu.edu, then it will use the s= ame key for both, because the key is scoped to o= su.edu. This is the same as with cookies: a client could connect to one.osu.edu which sets a cookie on the doma= in osu.edu, and on a future connection to two.osu.edu, that server can read the cook= ie that one.osu.edu set.

> The two domains are free to negotiate different key params if they wan= t.

Maybe I don't understand what key params means. I'm not that= familiar with the material yet, but it's deeply worrying to see people= refer to eTLD+1 as a security umbrella.

> The concern around H2 coalescing only applies if the two domain names<= br> > point to the same IP address and the certificate lists both domain nam= es in
> the SAN. If those conditions are met, I think it's reasonable to a= ssume that
> there's a relationship between them, and require the two domains t= o
> negotiate the same token binding key params.

Yes, I agree wth that.

-- Scott


--94eb2c190c5c73fee90539484f61-- From nobody Thu Aug 4 17:47: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 3E93812D6B3 for ; Thu, 4 Aug 2016 17:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 H8zQ5KzIVF5C for ; Thu, 4 Aug 2016 17:47:23 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0105.outbound.protection.outlook.com [104.47.36.105]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F8C12DB56 for ; Thu, 4 Aug 2016 17:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buckeyemailosu.onmicrosoft.com; s=selector1-osu-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3B1rf8JPu/ugyedZrDON/jXb0tZ83BuXTkUyMZfalcQ=; b=Ab6y8j1iW5km+LPTY9tU2+1iPLIoqB9abBegBxlwqa7KayBLFHtOzKKidLrPJ5oQnEbgt+pKCDP7UvoFVeyA1yCUdOV6/xAooh2OTPwBakjD72gDZVZDkY62jYOO5BzwNmbgQipMNKepliyE2+YS9CmgiFR8KUzIqjPfF6GK7Tw= Received: from BY2PR01CA0025.prod.exchangelabs.com (10.255.242.15) by CO2PR01MB2198.prod.exchangelabs.com (10.166.91.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Fri, 5 Aug 2016 00:47:21 +0000 Received: from BN1AFFO11FD040.protection.gbl (2a01:111:f400:7c10::186) by BY2PR01CA0025.outlook.office365.com (2a01:111:e400:2c76::15) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.15 via Frontend Transport; Fri, 5 Aug 2016 00:47:20 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.214) smtp.mailfrom=osu.edu; fb.com; dkim=none (message not signed) header.d=none;fb.com; 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 BN1AFFO11FD040.mail.protection.outlook.com (10.58.52.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.557.8 via Frontend Transport; Fri, 5 Aug 2016 00:47:21 +0000 Received: from CIO-KRC-HT01.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 EAED6500036; Thu, 4 Aug 2016 20:47:20 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.03.0248.002; Thu, 4 Aug 2016 20:47:20 -0400 From: "Cantor, Scott" To: Nick Harper Thread-Topic: [Unbearable] support for different key parameters within the same TLD+1 Thread-Index: AQHR7qHWfLRoGofmrkycBUHv9Fk4sqA53N8A//+bBJKAAAPwsIAARdSA///BriCAAEY8AP//vbXA Date: Fri, 5 Aug 2016 00:47:19 +0000 Message-ID: <9846A6064BD102419D06814DD0D78DE1129DFB82@CIO-TNC-D2MBX02.osuad.osu.edu> References: <974CF78E8475CD4CA398B1FCA21C8E99565AB421@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565AB53E@PRN-MBX01-4.TheFacebook.com> <9846A6064BD102419D06814DD0D78DE1129DFAE8@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129DFB50@CIO-TNC-D2MBX02.osuad.osu.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.14.29] x-header-sapphire: true Content-Type: text/plain; charset="utf-8" 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)(7916002)(2980300002)(438002)(199003)(189002)(7736002)(7696003)(110136002)(8936002)(2906002)(586003)(55846006)(87936001)(5250100002)(246002)(50466002)(66066001)(54356999)(7596002)(102836003)(6116002)(3846002)(16796002)(96286002)(76176999)(50986999)(93346002)(189998001)(19580395003)(92566002)(4326007)(23676002)(15975445007)(89122001)(90282001)(33656002)(305945005)(106116001)(106466001)(356003)(2920100001)(2950100001)(2900100001)(47776003)(75432002)(7846002)(88552002)(93886004)(109096001)(86362001)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR01MB2198; H:cio-krc-pf07.osuad.osu.edu; FPR:; SPF:Pass; PTR:cio-krc-pf07.osuad.osu.edu; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD040; 1:qxOCT60VP6yUNoUhw4evihteEjp/kTQEVpo59AWGlbBhnI9ApmeKR8JMc0FUxHwyz518IIPCSPkx5H2LEdcajYVFoznUsYM2jG/X1ybXi5ILZvlWeNiJnepSAmC6B3Nw+ezUfgysZNVcxXIsfE6lR4SeKZ2wcaX1JfC3Ha51xdtEGvTsrHTtDajmdSRSFT8JzO9OFnnKi7BWZD3dge+ABuH7ZUZCCrpYg13T2r+66ktXkd4Tg02wcSa7yUo22WX0CEeV8MLXyR9uL518QiXGdzByyRPkHm3oDWxeQwoxWWD824NFqLu24Nl41ocdwPpTLvEadJoVDqWqlNhErdkE0d88AklPdndJ1NeQot+qjpHDvHLdvNbSCRzbnjnFCEYNEuj/l2DrhDIDamer3X4on00oL2AEwuo34GQn/H8/gQNJxkLRrHQi15MNFdOje59ad9AeKAPA+AmdQO3pC51gHMN8M/7lCgxr4YO2hwLFO+2yFWyfoXCcThdH/H1eJ4EPIztt718WfRrDaBDiQFfPbXoc1cwi8NJLjeSvvJAI8UEQTTXGAQIjarFIjSPCWDG9 X-MS-Office365-Filtering-Correlation-Id: c102a461-c0c0-45c2-2fb7-08d3bcca0f5a X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2198; 2:roiRoO5QJPo8lqMTS2/FnMnGkQhbYz/2JHtGH4CTIU27PRv9v3hCYBpvDQKPSX/h6nvjXSkzdfhMjy0glfn17lTDOMydyIQRGkl5G3vgkDCKofgygb6GvSjrvTCP5W+9X8w9MM4FDg0WEzuKtExzBZ7KM0Wpi+KI3bFV8O3rz79PaB+czueTr8TWCvlY0UsU; 3:84UqFFg8EsgMW6FitbR2Vuh2N8a5TENIr3oiApzQunrxp+1BlZQoqUNeysSMyBLPssnqiwvMEF9fTtWfw66wRQt/OFwC+lkWWoyQeNPQQw/7Ovqb0Fe5NexEL1XQ/JmLzUZl6KZfFeXW2/Czg9PA8Q+5oIXFmi4zF8OePuIKRIJb9hdAUuxiDrEjAu5mY+Zm5/n16eFz2/MEAQqfoF6I2P0XQkqqc/6IzJQLL1o6IIz929WGnjl6Ej2RX0kGjzhg0JQvnD3voS49l7vtPSJMfg==; 25:kPcCKZ6r83g1UkYN6Fl077EO8Tc/qOrirt4qkeifZ1jYKSE9J8TgOZQhOPlpJ4o0UDNz+ZXq9Ahc3+jOzPtP49g3WkAtqld72+T8/3WlfGh7aYCxMn6cQjpmaDwcRwd3GZrVhWFUWcHTjIpvsI49Ii0l1QUIlDppsB9Nm26jjT3cp8aDBl7o78+TC1wdQybQzXUZQh1do4LGjquzj1/PPA2ujmFcoei9p2uPMKM7pkAf31E2JWc1uUFdhX8q2uGvx8p6LdkpSy0TAF65EL9p90yy12y2hYIjaBUHGR1rwYLKnvNhGvYkz0N/SXVmrD8N7wuu5j8GT7evGyXjnCUuD+DRszHbtlqdmbjXgNLb6rDpzIYikphTAREfbY19VOU53vjgpWfNgjgQX50ohhwK1VPF9lWALpTmyUAumjMl+1Q= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:CO2PR01MB2198; X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2198; 31:57fYsjb0Rjesqn+4vK6lynKxSYa4VEJY3dR+FJuDC+H7wK74hnIL990UxXxkiwxyhHpdpk1pLo7H0ZeILV98+0nD/4ayopSRQDIsXL92yYEk58O0K2WKrxWUwv9rnqW4Hi6gg+kyYsaymP/Q7sruzXlrxjZPUfg1nz0+EAs4On0q43Ug7gvZET4+A1EBKQ0ig6mrYmYfg7Y4fzy8iDB6wxPEvYrjwau45S+aDfrNkh4=; 20:F1PDCWCo82kTuq1K6peuaUlSJ0s3HKawuKCbNFOlUsW0pQu7odZX/llrhuGvRF6L4/v13GtdGE6nkj/r5i+s1zATqkHe8O83tBEcLNkRkJSgrt/DjN1+V4h/PbzVR4RDOmck+ReIbZ1Rko6PlfQrVMesbMAo2umrGumw98UN1mn+F1z5//RJE2B98kt+1MJ5tGcpc7dZ2P3Ioo7Kr6iSaSTEZvCs9ePJ7lz80rOBDlRCw8YzOukLfCR4msyi5MYByHD3pMVLn9ZHWtYKdnRadD2xODCDShdj9oHDSqiYrQlRVxWa/zjqW+NoUnVRCgcNP8iU1KqahWJNsYuCCdJnC9lo6hlSRVQnAvmwUD1ug/L9FqYeDso6uFZq/0ShLE/Ay+nPWC9xFjguiLM2H1w2XOfcFQRxaiFgRr2HMrMqsAyx2/xD4k8YMVciLhPkB/GvyC9uESNBLXApTIev8nfpBvq+kTk7lPZmodPI0XCroa/P4NBBohiEPNvu0fT0wHN0 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(21532816269658)(92004823454550); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(13017025)(8121501046)(13018025)(13024025)(13015025)(13023025)(5005006)(3002001)(10201501046); SRVR:CO2PR01MB2198; BCL:0; PCL:0; RULEID:; SRVR:CO2PR01MB2198; X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2198; 4:JMhl6fv4HhJ9FNbwyMfZoCDoNuQs5woWsMKRlxArek86DcJb5srYKwBgQVtSLwY0gvgtr5WHv5Ae/4SGYpeaHKZvCjvYDMu+lNCCXMA+UgR8/RMbq2KelvbZbDHYdYy5LLZfTsTMrFnUtro+7QrFmVbxVBoqydzN9+JE9xdxPCdqjjjrz8C/aLVhpYu+h2oXLxXffCeTHW/1PtqieB0cGpMx4UXfc+iKLAHsTsWYmweAGapZ3pinqEOK/4B3g3E8xIozb03bLMDhfg37wdwdLfF5DKhIuC2ECur+DumDaFaV8hQAjny3x9Q2ohSHgMQqH8eHbIr2ROtQIwPNZdIumDKFBIQDAAaUOW0R3RSXElf5Z66X9luHA36qnfyTTRWf0M3tr6W9iucOqXZ8wHXwaAwt5Y7NYWcy8QpK9NKiiwnU4SOAtbIC05FUa+BN2MEKxu/MQU/PWggkEfnuhsklSaVdvo2nV3Orvc+HvPj+rCoGIJiIrKK0D7eIT+6OqO1a20+JFFZDUCdVHvK5vD1TP5Fyq9Koc+5rogWPmBmVdu8l4O5arnr2bHrcPx3PAKpV X-Forefront-PRVS: 0025434D2D X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjAxTUIyMTk4OzIzOld2TStmbzBrQnRZbjVSRkJJY0daNmZyMkN3?= =?utf-8?B?WXVpeU5ldnplUmxybEJPK0U2RW9DQVJOMWI0cWt4UnVCdk9JZGNaRS9SbWI4?= =?utf-8?B?YURqY0pSNVRXczVOU0pIS2xoNlpqVzlYVUNKcDdKL1FpeUJxbnF4MC8rRy9q?= =?utf-8?B?b0diUDdTSEJxT3llNjNGMDN6blVHems2ZjRhaktSdVJWRVc3N0pOUlNFTVpO?= =?utf-8?B?TWpIUDFkNzVYcjV0QVVUUDlUQTZyQlhnc1RvcThOL3cxOHN6ZDJ0QVlHbDdm?= =?utf-8?B?UnNDOHF6U3EybXExbTNLQk9sWThKdlJlUmovRzBsVzZYTUg2MjB2S2lwRWh5?= =?utf-8?B?TXhTOWZqTk9QZG1JMGs2T2JTbVhEY3hMUnh0eUwvUTBTK2o0N1pFVlA1MkEx?= =?utf-8?B?a0lWMXdXZzVVNU5PaWtqQWFoSnl3SzhIbzhzTExSVU10ODJ6NVJkS2h2REtR?= =?utf-8?B?Z1lnMXVMZENjMXZDYXdTRmcwVlRheVFKalRxTjl1b0c4blUvd0trQlVWRnYx?= =?utf-8?B?dGo3MkU0eVN2TkdMNDk3WWVvTDIyLzUrcU16cWlXMUJCOGc1ckMxay9IQUpT?= =?utf-8?B?VGlySDdGU2RPSDhJRFZPbDJaYXp6d1U2RnlkQ1Q2aHhkZ3BmY1dhTVg3NWg4?= =?utf-8?B?OExhM3BKaDd1VjNFOTZxeHV2cDBlVXdsVlMxUW1wT2tCYmEzY1VjQ3BkQzR2?= =?utf-8?B?K1Z0c2dXSHZvM1RMK2JDVlJ5Z0FjdFFXdm9zUU4zVUVseWJkL2diY0R5Ukwr?= =?utf-8?B?d2VlSThicVV4czAxTkJYb0NRZGp6amVtSFRaOUFzTWdrUlFUYnBTeTFKM3ZR?= =?utf-8?B?V1Y3UDQzV2dqM0ZuRjc0WWtFOWd5NktmNlg1RHdvODJSZkN2dTRyZXdCc2R0?= =?utf-8?B?UTZJME1JUmNnRHhISUNpbzdGOHBhZStHUG82U0F0emU5U2hMNlRrQW5xaEZi?= =?utf-8?B?ZlBpTnNmR2IvK0tiV0t3cUpnT1BVMnNzZ25CekEvb3FTV0xlNktyNEN5dktv?= =?utf-8?B?R2s0dDlFLzB1dDRFSmxFZFgzMnZJWGFqZXM1YnByVkhhd1lieTVKRTNjRHRh?= =?utf-8?B?M21yQlJoMnU4OHZ0VVBySjg2QWNDbXMzKzgzV09reHFQOFpLOXlnbDFhMUx2?= =?utf-8?B?MkV6WjArR2l5OEVkdURWNnVzYVZsdXdpV1VaalZEV2RwUDRyZ3RPNnFYbWNU?= =?utf-8?B?enpmM3J1d2doendrNkpzeWdWTWNrT3dvNUNEdVBUVVV0MllDVmlrUDF5N25z?= =?utf-8?B?dFBvM3Y4WXczSXdzVGhEelY5ckpDZDFMRTl4em5kamJtbFRJUnhZSjU0algr?= =?utf-8?B?aU9uRUtHRDdqZk5IRmNJcFdlL21oZ1VrUC9jclJLeHU4dVMwcUlkRm1hOHpT?= =?utf-8?B?UDBQWS81ZnRCekF0NHRuV05OTFV4QkJZcWxhd2JYWjNFNS8rcTlaZ1luMEdm?= =?utf-8?B?Zm9yTkRDVVZUejhjNDk5Nmh5RzNHKzlzN0NTOTgyTzZUb2wrYithT3hrQ2FN?= =?utf-8?B?OWxxZmJ1WG1iSkxWV1h1a3dYaCtrUjZmTHhQM3ZySGNiV3R2dXE2cnRCRFE5?= =?utf-8?B?YmV4ME5URTZiSTF0VEx5ZTNoQTQraUpkZ0RjMHVmbWIycjZuQ1lTa0NaK3A0?= =?utf-8?B?aElnSjRqWnhjZ3VOS2VLUm9NbGF1aGdQT2tSTFJldnloQ0p3djgwbE9UbEQx?= =?utf-8?Q?WBJjObYnH6Hi7CVcVs=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2198; 6:56pxDbH0drA3v/NJRh3Mj1Oq6pZpSYSE3kzTNyN3ItNUNZ5seLJyMr8nblML9Eggp1mxwvIyrC1X5VGkQGmef6rMKvwnvSNrk5jUnOtFpAJRHkLjjy12f5vllj3iJyrsRPL3sxaEdGRcE8OU2aXLZH4tCbZ+7P0TrlCZk6QKNUQFMMPgdsMOdiIRs26ZVPt8sQ2r5wBRrtxnqo4Z+w2ZmspAFq5DVONnqTea1NYDQMDom+Pd2dPbYz13O/iRnCe03uz9gQGlUi+bYmWLyzDGMUCujhE61q3/+jZ6G8UM5GQ=; 5:+bFNrC+J2MjOd9xagYf5h1yNlJZlbOFcjtGmP6yDQ/z4Pf24Qww4rUfFb/3MncXb+dp24LvnWUbgu8FoIn7cvQVbS1HBvR+IbGAEiEuZtTpgDInectcJptLHrglgS44a4XIP5TpOe42GmHZ/PnMIow==; 24:iaWtacLBZhmStmEMfDEdQJcDlRi/rJSQLlvUZuVyS5ADOD+G0rys9hOgufqGpChSmR3ruZSWQ0+ZmysIGovzfcDS48orOuErg24+7MzaJV8=; 7:Mgd0/pp69YXsGloKdUjSsUXf1ANLGusJTxV0H9GwDRDfUaoGbabzYoxo+UFwq7+ko+yG1K7teVxTaVPpQ3e8DhCFCavacxJarJKzxhb4coaRHR6UZBjzr0NYg2a0QjSOrXNxiRBcK7RJkjiaGpDYHD7PkTbmslRU4XqY1dgAKVqeGVPb0HkD508mAO/IdsALDPVobOOjM1id54DW2Z69oNg3lQm2HV+1hhJHLjibEEMencJ+cZOV+/LuhOZr4VL/ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2198; 20:+vc8C67iZpVV3LtcJkhxMKuBf+qDREdHx9xuAX1Qz5mDQdTBTRoNdMmAy5gUhyfFxZgJSTyPrrp2+ntjGq+CPg+/8r2kP9I8x4stP3cOXPVXWZQSBsvdy+ULMyvz6WPCt9QsD5Ka3M9LwLw/JPyqsdrKsjJPbp8h+0iemY2GCFg= X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2016 00:47:21.5264 (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: CO2PR01MB2198 Archived-At: Cc: IETF Tokbind WG , Subodh Iyengar , Brian Campbell Subject: Re: [Unbearable] support for different key parameters within the same TLD+1 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, 05 Aug 2016 00:47:25 -0000 PiBLZXkgcGFyYW1zIG1lYW5zIHRoZSB0eXBlIG9mIGtleSAoZS5nLiBSU0EtUFNTIG9yIEVDRFNB IFAyNTYpLg0KDQpZZXMsIHRoYXQgd2FzIG15IHVuZGVyc3RhbmRpbmcgKHRoYW5rcykuDQoNCj4g VGhlIGtleXMNCj4gdGhlbXNlbHZlcyBhcmUgc2NvcGVkIHRvIGVUTEQrMSAtIHNlZSBkcmFmdC1p ZXRmLXRva2JpbmQtaHR0cHMtMDUgc2VjdGlvbg0KPiAyLjEgZm9yIHRoZSB3b3JkaW5nLiBTdXBw b3NlIHdlIGhhdmUgYSBjbGllbnQgdGhhdCBvbmx5IHN1cHBvcnRzIFAyNTYga2V5cw0KPiAoZS5n LiBDaHJvbWUpLiBJZiB0aGlzIGNsaWVudCBuZWdvdGlhdGVzIHRva2VuIGJpbmRpbmcgd2l0aCBi b3RoIG9uZS5vc3UuZWR1DQo+IDxodHRwOi8vb25lLm9zdS5lZHU+ICBhbmQgdHdvLm9zdS5lZHUg PGh0dHA6Ly90d28ub3N1LmVkdT4gLCB0aGVuIGl0IHdpbGwNCj4gdXNlIHRoZSBzYW1lIGtleSBm b3IgYm90aCwgYmVjYXVzZSB0aGUga2V5IGlzIHNjb3BlZCB0byBvc3UuZWR1DQo+IDxodHRwOi8v b3N1LmVkdT4gLiBUaGlzIGlzIHRoZSBzYW1lIGFzIHdpdGggY29va2llczogYSBjbGllbnQgY291 bGQgY29ubmVjdCB0bw0KPiBvbmUub3N1LmVkdSA8aHR0cDovL29uZS5vc3UuZWR1PiAgd2hpY2gg c2V0cyBhIGNvb2tpZSBvbiB0aGUgZG9tYWluDQo+IG9zdS5lZHUgPGh0dHA6Ly9vc3UuZWR1PiAs IGFuZCBvbiBhIGZ1dHVyZSBjb25uZWN0aW9uIHRvIHR3by5vc3UuZWR1DQo+IDxodHRwOi8vdHdv Lm9zdS5lZHU+ICwgdGhhdCBzZXJ2ZXIgY2FuIHJlYWQgdGhlIGNvb2tpZSB0aGF0IG9uZS5vc3Uu ZWR1DQo+IDxodHRwOi8vb25lLm9zdS5lZHU+ICBzZXQuDQoNCipDb3VsZCogc2V0IGEgY29va2ll IHRoYXQgd2F5LCB5ZXMuIE15IHF1ZXN0aW9uIGlzIHdoeSBpdCBtdXN0LCBzaW5jZSBzZXJ2ZXJz IGNlcnRhaW5seSBjYW4gYW5kIGRvIHNldCBjb29raWVzIGRpcmVjdGx5IG9uIHRoZSBmdWxsIGhv c3RuYW1lLiBUaGF0J3MgYSBmYXIgbW9yZSBjb21tb24gY2FzZS4NCg0KLS0gU2NvdHQNCg0K From nobody Thu Aug 4 17:53: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 1352F12DB53 for ; Thu, 4 Aug 2016 17:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.987 X-Spam-Level: X-Spam-Status: No, score=-3.987 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.287, 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 aKGVWxodt3Sb for ; Thu, 4 Aug 2016 17:53:07 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 60E5512DA7D for ; Thu, 4 Aug 2016 17:53:07 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id j12so258386213ywb.2 for ; Thu, 04 Aug 2016 17:53:07 -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=D6Alms1gCw5tSqKaF23K+US7iMN6E5TZib6XbNex1TQ=; b=Gep4UiaA8wn+tzR8M2vTroLbCdQd4DTBgfWdjMpyDkTeG7+isMWoDA0AB9fZXI2Pfh nbZHiShOVpQfOUIC/WAmC8Njb/HUy4A72hbIaMs6QOCnb86iReI1Mqb6PMzmpJGGfWlT u4RA1DqeK2Wv1pn2BYBMrXT0noYQQuuGZXVs8nrBwanSifYzxBaXCaXD+3EJTOrTvsiE FqJJh5Co9ruWMYI2oLUVtxhVwC40BLK7dNiV/aQwooPFASMFjS+Vj+P+YfpyWwHfGs1u Fo48OhbXiSXR7pSwJHkn4t/jUF6FspSGfxtYkIBHvhkaUCfYABvJkIpfzTC+20rePuWp N/GQ== 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=D6Alms1gCw5tSqKaF23K+US7iMN6E5TZib6XbNex1TQ=; b=GzQ+4sTL1UxpwStaTUet+sR4wq7/fG+7Amv63UAu8lnSZg7QUGOsfcRx/GBTnni87C ZzX7J/A4HmVSzA8RQ2uDwGXNt6l7mQzSOIsS27OD8UZ/eDjcRQ5jkRc4xe1QY6LkR28O 7t/SJyA8Ky0xWHjKNQ5HwKeufQeumgGS5fahSyll1T6KtauYJW10BmaPPpPNfwhJPzfT VXNuegZCKUal5FXGQ5K79/8hCfxUaxzeV/QuvuM4b3Kg1XEW5h3wKKNCxTZdFcLxsdHA CfEGDs/Tm4KUH8ZTHYXRldiyngel7/9rE+t8dowmiFbRBSXZkRg21F9tXy/bnl72u6FV L3/g== X-Gm-Message-State: AEkoouvGWI8Ckn1a7EhgxGF9m93Gs3sf1rGX3ytm7DE+bMA1nx4danySfDm0ud4WZj8pDNY1ZY3dpxb15GEV24+u X-Received: by 10.129.39.8 with SMTP id n8mr56974341ywn.294.1470358386562; Thu, 04 Aug 2016 17:53:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.161.134 with HTTP; Thu, 4 Aug 2016 17:52:46 -0700 (PDT) In-Reply-To: <9846A6064BD102419D06814DD0D78DE1129DFB82@CIO-TNC-D2MBX02.osuad.osu.edu> References: <974CF78E8475CD4CA398B1FCA21C8E99565AB421@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565AB53E@PRN-MBX01-4.TheFacebook.com> <9846A6064BD102419D06814DD0D78DE1129DFAE8@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129DFB50@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129DFB82@CIO-TNC-D2MBX02.osuad.osu.edu> From: Nick Harper Date: Thu, 4 Aug 2016 17:52:46 -0700 Message-ID: To: "Cantor, Scott" Content-Type: multipart/alternative; boundary=001a1140857e5345410539487dca Archived-At: Cc: IETF Tokbind WG , Subodh Iyengar , Brian Campbell Subject: Re: [Unbearable] support for different key parameters within the same TLD+1 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, 05 Aug 2016 00:53:09 -0000 --001a1140857e5345410539487dca Content-Type: text/plain; charset=UTF-8 A site example.com might want to issue a cookie on that domain and create a token binding for it. It then might use that cookie on one.example.com and two.example.com. To be able to verify the token binding, the client has to use the same key on the connection to example.com, one.example.com, and two.example.com. The client doesn't know a priori how the server might choose to issue and use cookies across its domains, so it scopes the key to match the widest scope of the cookies to ensure that the server can verify the binding regardless of where the server uses the cookies. On Thu, Aug 4, 2016 at 5:47 PM, Cantor, Scott wrote: > > *Could* set a cookie that way, yes. My question is why it must, since > servers certainly can and do set cookies directly on the full hostname. > That's a far more common case. > > -- Scott > > --001a1140857e5345410539487dca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A site example.com migh= t want to issue a cookie on that domain and create a token binding for it. = It then might use that cookie on one.exa= mple.com and two.example.com. To= be able to verify the token binding, the client has to use the same key on= the connection to example.com, one.example.com, and two.example.com. The client doesn't know a priori how = the server might choose to issue and use cookies across its domains, so it = scopes the key to match the widest scope of the cookies to ensure that the = server can verify the binding regardless of where the server uses the cooki= es.

On Thu, Au= g 4, 2016 at 5:47 PM, Cantor, Scott <cantor.2@osu.edu> wrote:=

*Could* set a cookie that way, yes. My question is why it must, since serve= rs certainly can and do set cookies directly on the full hostname. That'= ;s a far more common case.

-- Scott


--001a1140857e5345410539487dca-- From nobody Thu Aug 4 18:00:19 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 C514512DB76 for ; Thu, 4 Aug 2016 18:00: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 1RhRlJVbl_jQ for ; Thu, 4 Aug 2016 18:00:15 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 6328912DB6B for ; Thu, 4 Aug 2016 18:00:14 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id p186so124201669qkd.1 for ; Thu, 04 Aug 2016 18:00: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=3dODdDGFwAqPB99JqT0pYW2s36PYj9GecZ309sAAOjE=; b=AhcBM0IEUrA3esO9TgE08uwwnMadRpfsrcR5u30o1vDgVD1xBXRUfEYF2g5v8gfkEY MXaHU9qlqT04dbIrpIr6uwsUXdRnAOHo6pfXtRbtqo19F+AKfG/HiZ6gxvYDKKmqAe+M 9XTlAGeeT/Of4IGPKlHA5i3Gz/n/YbDZV9cz1CIh/6rq5zjTUHOvP2oeHaxDaYcuR64D DyovTXMxa0CFnA8h07OKwcr6PYWAujwq0CxY4AKBm5ujtE1rnF5OHcHqBH/7OX9OWWg3 aL+tZNhymhcq48MB/SePAvxG+ccLbJJtUUE19rZgn8tmymr4qzaZXuGh590cuMNJdMWt I4QQ== 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=3dODdDGFwAqPB99JqT0pYW2s36PYj9GecZ309sAAOjE=; b=ahbVJtm5j4W5dxothxG4rRFMTBlPn7dX7n68JptncAtFCVahdpjW7dh/aHA7/oOpoo 9LtsLxNolUtBTkUtF1B4mTy/GBM3O9FfWtlywj3WZEWUKjbidQSAEEkbKeLGI6016qVp A2bpHHToKidgv+EoZ1wyDPxsOfHSqOToNxwo/wo9JjwDP9LqFtk1J/h/ilCwiEvSgujj rOfe4st1ddKZoEkCEAygSvrtujugCvMb11w7QTAR3etFKIJga/HAur/VeIgVPxmeGTgN zBCOpvUZPY3zKZSZvxcbe9T4CoK7EzWEzP4m+jX7qZNrrnqkH6MzZb786yzf8X+MDbkI fTiw== X-Gm-Message-State: AEkoouvfhsBS/nGnOR9dm5rb18H4szzsga6F33Wd7sE4HjQK5XBs9ulcOqAXd8ScSS6aGSgK X-Received: by 10.55.26.40 with SMTP id a40mr10573817qka.251.1470358813294; Thu, 04 Aug 2016 18:00:13 -0700 (PDT) Received: from [192.168.1.49] ([191.115.182.132]) by smtp.gmail.com with ESMTPSA id p76sm8295026qkl.48.2016.08.04.18.00.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 04 Aug 2016 18:00:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: <9846A6064BD102419D06814DD0D78DE1129DFB82@CIO-TNC-D2MBX02.osuad.osu.edu> Date: Thu, 4 Aug 2016 21:00:02 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <974CF78E8475CD4CA398B1FCA21C8E99565AB421@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565AB53E@PRN-MBX01-4.TheFacebook.com> <9846A6064BD102419D06814DD0D78DE1129DFAE8@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129DFB50@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129DFB82@CIO-TNC-D2MBX02.osuad.osu.edu> To: Scott Cantor X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF Tokbind WG , Subodh Iyengar , Nick Harper , Brian Campbell Subject: Re: [Unbearable] support for different key parameters within the same TLD+1 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, 05 Aug 2016 01:00:18 -0000 Token binding dosent change the way hosts set cookies from a scoping = perspective. However if one.osu.edu set a domain cookie for osu.edu that contains the = token binding ID then two.osu.edu would be able to validate that cookie = as it would be receiving the same token binding ID from the user agent = (assuming that the same keyparam was negotiated). Think of eTLD+1 as the segmentation boundary for correlation. =20 If the browser used the same token binding ID for every site then they = would be able to easily correlate the browsers activity. So if there is a problem with eTLD+1 it is that token binding could be = used as a way to correlate the users activity between one.osu.edu and = two.osu.edu. However given that the cookie policy of browsers is going to let you do = that anyway token binding is not leaking any more information than the = cookies would on there own. The idea is that in situations where hosts do share cookie information = they can also share the token binding ID so that those cookies are bound = to the user agent and not subject to man in the middle theft and replay. I hope that helps. John B. > On Aug 4, 2016, at 8:47 PM, Cantor, Scott wrote: >=20 >> Key params means the type of key (e.g. RSA-PSS or ECDSA P256). >=20 > Yes, that was my understanding (thanks). >=20 >> The keys >> themselves are scoped to eTLD+1 - see draft-ietf-tokbind-https-05 = section >> 2.1 for the wording. Suppose we have a client that only supports P256 = keys >> (e.g. Chrome). If this client negotiates token binding with both = one.osu.edu >> and two.osu.edu , then it = will >> use the same key for both, because the key is scoped to osu.edu >> . This is the same as with cookies: a client could = connect to >> one.osu.edu which sets a cookie on the domain >> osu.edu , and on a future connection to two.osu.edu >> , that server can read the cookie that = one.osu.edu >> set. >=20 > *Could* set a cookie that way, yes. My question is why it must, since = servers certainly can and do set cookies directly on the full hostname. = That's a far more common case. >=20 > -- Scott >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Thu Aug 4 18:20:47 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 0E5DB12D67A for ; Thu, 4 Aug 2016 18:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 jiYe0iUSuneQ for ; Thu, 4 Aug 2016 18:20:43 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0123.outbound.protection.outlook.com [104.47.41.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F13112D531 for ; Thu, 4 Aug 2016 18:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buckeyemailosu.onmicrosoft.com; s=selector1-osu-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rWgG8pzEekz8Qo36ZGrw2EruGzEp6ggz/iAk5GE7xL0=; b=mzkfOPtI7bCTGLTRrke0ckiokrNh5gts69TCcBzyFiFsWHBhnBRASNMtH67LU8agKwou/fI2Y7iZnmTVuq0WE/5S2ORTr1i+qKm+N0LWl7vzT6UMvw5OZLSIacsDmGv3TNs6gC7At/6Fgx9Q3EaExqgO9RRLFBxZIRam0PWKkjc= Received: from BY2PR01CA0073.prod.exchangelabs.com (10.163.25.41) by SN1PR01MB1840.prod.exchangelabs.com (10.165.226.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Fri, 5 Aug 2016 01:20:41 +0000 Received: from BY2FFO11FD004.protection.gbl (2a01:111:f400:7c0c::191) by BY2PR01CA0073.outlook.office365.com (2a01:111:e400:5262::41) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.15 via Frontend Transport; Fri, 5 Aug 2016 01:20:41 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.220) smtp.mailfrom=osu.edu; fb.com; dkim=none (message not signed) header.d=none;fb.com; 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 BY2FFO11FD004.mail.protection.outlook.com (10.1.14.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.557.8 via Frontend Transport; Fri, 5 Aug 2016 01:20:41 +0000 Received: from CIO-TNC-HT07.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 DB6E73C0068; Thu, 4 Aug 2016 21:20:40 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::3ca1:e895:a165:1359%10]) with mapi id 14.03.0248.002; Thu, 4 Aug 2016 21:20:39 -0400 From: "Cantor, Scott" To: John Bradley Thread-Topic: [Unbearable] support for different key parameters within the same TLD+1 Thread-Index: AQHR7qHWfLRoGofmrkycBUHv9Fk4sqA53N8A//+bBJKAAAPwsIAARdSA///BriCAAEY8AP//vbXAAAj9FQAAB//SsA== Date: Fri, 5 Aug 2016 01:20:39 +0000 Message-ID: <9846A6064BD102419D06814DD0D78DE1129DFBF7@CIO-TNC-D2MBX02.osuad.osu.edu> References: <974CF78E8475CD4CA398B1FCA21C8E99565AB421@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565AB53E@PRN-MBX01-4.TheFacebook.com> <9846A6064BD102419D06814DD0D78DE1129DFAE8@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129DFB50@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129DFB82@CIO-TNC-D2MBX02.osuad.osu.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.14.29] x-header-sapphire: true Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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)(7916002)(2980300002)(438002)(199003)(189002)(109096001)(106466001)(54356999)(76176999)(50986999)(246002)(356003)(75432002)(7846002)(7736002)(8746002)(305945005)(86362001)(7696003)(16796002)(2906002)(90282001)(4326007)(87936001)(106116001)(8676002)(89122001)(8936002)(7596002)(46406003)(110136002)(93886004)(33656002)(92566002)(88552002)(97756001)(50466002)(93346002)(11100500001)(23726003)(66066001)(5250100002)(189998001)(2920100001)(102836003)(2950100001)(586003)(6116002)(2900100001)(47776003)(3846002)(55846006); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR01MB1840; H:cio-tnc-pf06.osuad.osu.edu; FPR:; SPF:Pass; PTR:cio-tnc-pf06.osuad.osu.edu; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD004; 1:YRXuus/4zoFuwdvacPWgOL4Tgm8pZdJ0JGeZUYOMn4nsJrHJTk2qrgTMXP/Oqs44izY+PI/MF9uaAQVkx5wgJxSin0EiJYYXZA8qGcx4ERnu8zlV4/SepnG/Fua+/RfYKDr7cQg9o7g0ENBTqEgC7GWnTtwQty+1udrSP+7P5/JCXZz0h8cVxWmOXK9QJOCr+Z4TMtLC1i0bGz1rblcSq2eL3ohj08WfAgfLCAhPLrEF/0hn1BxwPns7jgeiunHHKBMylEAUr8FvUIaOlXRWpxplDJaLnv2lv2q06cc19FTiO0vSyoRUyv7O22cS1jsGXNHMPXLIkuL+BuF0unpHodqfV+GiY8krlyYwsmVLb8mmBAtKoX3ZosZxW1lIBOu2J9TKOZ0NSvsQR2G9FrR2XmmkpvVNPi5X0u9DZO9G7neJDZJ68Nv0Flb2J7rACP7T2VZHZxVufwAe4pZsiuD8RqsJGA5PmVeG/AVMrqJjS/mi5PKT0OuSEXhxY02a3kE7SjAXpY/IG9piQfOY9CcnZ3KJ2YOeHTmY/N/yFAvqAGQ7liPyBR8Wsl5BbiQNoZGJ X-MS-Office365-Filtering-Correlation-Id: 4335ccc3-3b03-453f-49a8-08d3bcceb78d X-Microsoft-Exchange-Diagnostics: 1; SN1PR01MB1840; 2:v3mzt8T/wzssYtTmACQSD/QMQP8JHOmwPO5PLaCWk0ZIJrC2AW6sz8c0PZ2jxP0r/YYFDY1FmMDlQSkAVinrHDkJBxnczHR/SFBstSRYdROZNkmKdH18SX1MtmW92yZWsSrtqh3AVf21jMsyueDCb9SPiR2rH/50Wy+YsG+ccH+qzjlaID+1N5unFCUsM1uv; 3:EAWrVi1wxV7dyCrwJqLj0JgQtG7Cv3Ai3ucY1xgmnXZ4OMaaRU+5LJDPr7WuCKnooe5IqcTiJwU6CTXfD63jKMBk097GA7kV6uUOMS/oAn654OFy8IgSJrANGAOopuBfZ1tVB6FMDjsmoZ3aTvEq5rpqEjkMD/L1KaGMGZw4EFu/O07WF0w/y8uGO87BXttMQ8qYPPaYKvXQr6OUUfQhFHAk8cnbXHzMnO/CTAuGOXQgOtCEcmPNWL7mRSDiXY4mgsMT6R1tKthvNqES+AdAYg==; 25:4tTEn5tB90FBBEFFhcncvrXk5RVYDMSuUeX9GMQONUxHZ8Bc0rKxzfmt20arf3QuffdN98vGve9pQkwsxguh+mtT02lu8e1fZzHOo5t2c4zwg3kJnRs2J+N5O0v6BF0OW9PjbvIfP2ibnW4xG3VOSUkKd1Op4xlYKkeKtKA/wI84a9IbEwneUtwQ4rFp/TPD32By4asqlDzpiM/Jnkn1g8hJzmVw9IZaSPqjA5rw/zUQW2VN0DPFdQYfPMckhooFqebAWn4y6QBkQL58d2146qMgyIKP91vjGE7NF6Yh54eEJ8JgQ3hBwBo1FeuvfmhY2MJQteFh9eHD64+dHYgeS6e0zc51jPnRXurLyQ0ZNmuvbneOTU+1PZP4cY11XPGywadoERBFstzCrF9RaJW1GN/ePwfv7k6YqtUjtFLmaLY= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:SN1PR01MB1840; X-Microsoft-Exchange-Diagnostics: 1; SN1PR01MB1840; 31:62cFpMzR8+lp8HPi83AyP4iWgttNBJm8pLQKlSz/Qs2gaATPNWrcinowGkCV7FB+EAy6vkRtOuetC9m/H0e3ZUhVg75PvspsQ90QYK0QLmLIbfBPldQXukm5I/Mew+uaw/PrxcMmpx4O1AKzlIXt0lb6M0F6FiSN/ahAPJjokkwwi27EyzSITAihBqNb513zlJCblpOCQlHH27hND16Hp16dtsIxpKy8wq53/Z+InzU=; 20:BXx65OM64SjwJ+1ooyDg5Z+/NqcbBg8Rj/aZU3BxNfE2WsSnC8tvJLiVVQtqJNF6wVPA785mcIb9oPSU6vuRlNUbr/ZZtXi86LPxTQ4plOBs963Y3xiNj6GQTmQpITk1qK+UAOSj0PtQsZK8VcdbV/aFe7u07rbfV/1QjlBIZkenCdNWegLZ4nLHXTSKgByv4Jr03ww5AOjeFopyG+1ugkfaGl+t3ry8ZYfcT7b891hfSdMUmjkA+R655s7lhkAssCcXVg6sSafqKsLG3kC5RcZTVJu3jL8Q3Zpg/Pvbcx0FYuq3Pa8rckZ9Rn3UcDwB9UKTBFRw8r+J1+7qN+gyJ/zdVnepClcnBaxC6LB6h9cxZto9Wx84i0vjojvmVsRBa8We/Fp3hw6jN7klEPFhRgF+Rxww5ksZrpdSyk3gVrdl+ZjxPzp/7cinall44rNlZSnCIzfjUdIWPmE3CfFDxarRDOziYrwdW6K3aqaU/3qxJ8f2CJCCDYdUgpmoegkT X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(13023025)(13024025)(13015025)(13018025)(13017025)(8121501046)(5005006)(3002001)(10201501046); SRVR:SN1PR01MB1840; BCL:0; PCL:0; RULEID:; SRVR:SN1PR01MB1840; X-Microsoft-Exchange-Diagnostics: 1; SN1PR01MB1840; 4:qgR8hp/ELSUe7KqHn+IFDbmm+ZXcS+ZYtsP7xnVa0012jPCOmLDRtQ3QAomjAFgeH2tyJAjPyJHEm9dIvxnU09pgXVh61K4EKTIGe+K2/XevXnU15xL9yMlrHzV5jT9z+Mj4Pnxt6fx/VDKVKYMzfUAiHnK5o/hRaaGJtAFGst0kbqmUsWatZnS1cVNaNy6efVzKVFyiPSiasXvkqy6DM9J2FbAvyF5DqdoyDONFCY+Rwu8bSML03sU/VSj/QLdZGPSdbe/dxhpHY1H0CBcFHQJWtJnxqXtNA/aJqzgvG+Wc/2Ejotf5JzkSMpsNY3dNduWsJmV94NP0Bo6KqG2TBtdRlykZpniZyHUYZD4cS9hyRYZWloEKQMVoUbsgx64DPX7gJMB8tl91lxg3WucMMzuFy7CGYF7Wy+/B3yizgiFcSw9xsqugAeE3jLaia25m X-Forefront-PRVS: 0025434D2D X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR01MB1840; 23:QHiSWf2Oz9UFD1Bavr2gd5NWyvdXlLePGXu7ZCTjN?= =?us-ascii?Q?teCm/2q0B6SIf1KRSczM3m285EDK7QWcrgx1GRJDvu5Ol0D5fXsuYnK/pLS6?= =?us-ascii?Q?z6ouXJzWBtaMTLvUiNmRh+QSmCPH92hrdbJo3kwSAK5TsYIce9v8K2/IDFhB?= =?us-ascii?Q?Eht1BPjK+1839308Ggl+wkJW1YI+Va801nk3BsbHwheRDXyqbOJ/OAieXAgN?= =?us-ascii?Q?+zMw0rxuGz4kz3RoO9axv2Q319pgAZoxYDkUuWNkdSgZG13GfgmCkmi+f1i4?= =?us-ascii?Q?vgqO69SryMqSPFTpwRvv3AsTQeq8FWlZSYnLcUpVKKauoRrv72WMnKPahUZb?= =?us-ascii?Q?dcMXPDTO79SUrplzmFrRMzYAUtDzRxvkC+RqvIcgHSN+OlgTN4AohIpa8iJD?= =?us-ascii?Q?npnOIpPBfjz8VzIqAkF1+s+eo/gneenah1hj6qmcQ1rhy/SUCLMr+ak7nxfk?= =?us-ascii?Q?kcL/Nx/LPs3t8hLvl4+nwz/Vj6twAY6byP9EYV+x48KJdA2aQAT8mb3lb7vd?= =?us-ascii?Q?hhRx6SrfjALcOvJRNy75NvdAc8aWdP75sAdOkwi/HZoxWwqaTm358tPbDVue?= =?us-ascii?Q?vJ6NrIE6LPUlLKehQ7FpUsXrh8ek7BHnbrShU9JQWTO0ZnJGUKj6p6+1BuUf?= =?us-ascii?Q?5/M1FIhz9soPzFQ3g4sXZGnDwOFUxaq8K0dj+kYt11yOm3rXhmdByhVfRXRz?= =?us-ascii?Q?IaS+6n+mkhJVjeg2+kWvMKS6usZG+70PF9UuttClQXa/iF7YL26dRen3aPdM?= =?us-ascii?Q?EGn4Ffa8e/1POFsivF818NRWbLHrvZUKzcYF1U56iy81Xj0/ZJnfMOBgRouq?= =?us-ascii?Q?S5qJgYt7cDabz95HeaAbxpzfVB1NI/uParh3ECmbMxHOQoB/KkN7pnk717E2?= =?us-ascii?Q?U3kyJkQ+DJ+UetVZX2epd/804CGHperTbVAykUyZW3z07Yy59pofVINCYB0g?= =?us-ascii?Q?+30bbPPDRueqiZPeqlVmTn3adPeoqAds8gd57k/NQ8Lv5mU917zuaJO+LciA?= =?us-ascii?Q?q7vrRgcf1tW73xstJszTc3uSJvVItcCK7sl9/qDIuSe7jyovic0jWp6EKhTx?= =?us-ascii?Q?0994YhGBK/ZR0GyNwoOFP8V6bin6QOZJjWNLeiYOt97Wh5ktts2RfMW2AbVL?= =?us-ascii?Q?LSl+hdWBblWpjXF0LgkKw62d5rgyDQ07d9sNDZCrwHbNXxOFUvZcvLeMWnOE?= =?us-ascii?Q?DMNovjxxzE9aqSPxvGk6wSxQrnN/cnCW3IbbwTJGS1ofkEQf4ADY+JODxNum?= =?us-ascii?Q?EIQqk3MRPEglWEgsZfjfKcaxcqJNXMgpSzYWkRb?= X-Microsoft-Exchange-Diagnostics: 1; SN1PR01MB1840; 6:/acRdDe+kTwwh/oeIGT9nCNDGZwpcwrMH8E9urIK6kVVdlhb4Tu72GMvsOd8t+sEGFXp51KYNF75/CbnhIo8luCprWF3xcTwJUhwz5uyXgm+FlcTYvTcVUrBUdTVQ4CspOB+xcAmo2e1y10TJgmxGuWoSGkaANG1j8ea9YbU0PAKE95/lLQi1pseXe9u0NEqeLvGT8Au/zH73+mw6nz21q3LODfOPKtM6ZKAVfkSmg33VkZNx9GhC9skB8Ia/RbOQS9QO3d2wHDh+A22Y+Icm19zUPvSVBpJHBDY6DzLVEY=; 5:oX8PQpXKW0Rvgkcf635ROAh/sBo3zOPHT8zvzyeW9LOqlCvAFVdx3vPVqOm6ycFEyS2zMUKBCMseejd1loPKuCbzPcUNTLm6ybt/tcNxLl8y36ro0c1Vv4ENgje8yI6VBBT4/WJeKK4wtf1FYQQMpA==; 24:0pScxuKFFQobL8KdAGZhF/+mEjPMRE3p3DhnD0mdZpg3TAM+RL2KD3DZ2LvVrc2/NdcxOWXJCUHvAi9PKwzi+33YMH5Cvd/8vAt0ls3gQKY=; 7:N4JDsw+TGWil102k727lPWNSIIZ5xgYcsczsp2MAhetu1/Vj4rYDQLd5ieEVoXN87nKgrODf79fSJMVASt/1r9DMzt1JYesK8jH2hQx5P4766qdyy0N6Z0wgvjyLYHH4dlI2SK2cY5xKbneA/vtUg7js4NisuEfBHtbGYoStEHT28ZQmWnCYHwLaDvVBiffzsDZyqybTa1XX5OWGHIg6P/smkFexBp45FJqF0ONRGJA7D/n0rhgGDC9lvcugsQhp SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; SN1PR01MB1840; 20:MWofwzOUNwzgUuUF6YtQR2AcCw95N10FH9H2RTRtJulYB3rjz3uT3mJ7UfG5Edh5Tl5O4ZnxO76AYIr3k2JLwt30mxCM53liG0ip1T2xpwFWr4oe7eZmMUuDs35scWN86PWQfvehWwRPNbL3dk70uWNhL2eimMgjZHqFuAwfypY= X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2016 01:20:41.6430 (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: SN1PR01MB1840 Archived-At: Cc: IETF Tokbind WG , Subodh Iyengar , Nick Harper , Brian Campbell Subject: Re: [Unbearable] support for different key parameters within the same TLD+1 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, 05 Aug 2016 01:20:46 -0000 > The idea is that in situations where hosts do share cookie information th= ey > can also share the token binding ID so that those cookies are bound to th= e > user agent and not subject to man in the middle theft and replay. The confusion was mine, my brain was seeing "token binding key" and thinkin= g "token binding header". The signature, not the private key in the client.= Sorry for the interruption... -- Scott From nobody Thu Aug 4 19:42:16 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 818B312D578 for ; Thu, 4 Aug 2016 19:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 Z70pKO3FEQOQ for ; Thu, 4 Aug 2016 19:42:12 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 1072C12B039 for ; Thu, 4 Aug 2016 19:42:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,471,1464616800"; d="scan'208";a="97359804" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 05 Aug 2016 12:42:06 +1000 X-IronPort-AV: E=McAfee;i="5700,7163,8247"; a="198050640" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcbvi.tcif.telstra.com.au with ESMTP; 05 Aug 2016 12:42:05 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3754.srv.dir.telstra.com ([2002:ac31:28c6::ac31:28c6]) with mapi; Fri, 5 Aug 2016 12:42:05 +1000 From: "Manger, James" To: John Bradley , Scott Cantor Date: Fri, 5 Aug 2016 12:42:03 +1000 Thread-Topic: [Unbearable] support for different key parameters within the same TLD+1 Thread-Index: AdHutMER8i/XOusOSKOvp0tkrBsg8wACTbAQ Message-ID: <255B9BB34FB7D647A506DC292726F6E13BFE155A4C@WSMSG3153V.srv.dir.telstra.com> References: <974CF78E8475CD4CA398B1FCA21C8E99565AB421@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565AB53E@PRN-MBX01-4.TheFacebook.com> <9846A6064BD102419D06814DD0D78DE1129DFAE8@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129DFB50@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129DFB82@CIO-TNC-D2MBX02.osuad.osu.edu> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IETF Tokbind WG , Subodh Iyengar , Nick Harper , Brian Campbell Subject: Re: [Unbearable] support for different key parameters within the same TLD+1 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, 05 Aug 2016 02:42:14 -0000 > Token binding dosent change the way hosts set cookies from a scoping pers= pective. Yes it does, because asking for token binding is effectively establishing a= randomly-chosen long-term "cookie" ... that happens to have crypto protect= ion, and is transported in a different field than the "Cookie" header. > However if one.osu.edu set a domain cookie for osu.edu that contains the = token binding ID then two.osu.edu would be able to validate that cookie as= it would be receiving the same token binding ID from the user agent (assum= ing that the same keyparam was negotiated). > > Think of eTLD+1 as the segmentation boundary for correlation. =20 > > If the browser used the same token binding ID for every site then they wo= uld be able to easily correlate the browsers activity. > > So if there is a problem with eTLD+1 it is that token binding could be us= ed as a way to correlate the users activity between one.osu.edu and two.osu= .edu. > > However given that the cookie policy of browsers is going to let you do t= hat anyway token binding is not leaking any more information than the cooki= es would on there own. > > The idea is that in situations where hosts do share cookie information th= ey can also share the token binding ID so that those cookies are bound to t= he user agent and not subject to man in the middle theft and replay. Hosts one.osu.edu and two.osu.edu can choose to share cookies, but they can= also choose not to. How bad is it if token binding doesn't allow that choice (it is always shar= ed)? You cannot get the security benefit of token binding without allowing corre= lation across eTLD+1. You cannot "clear cookies" for one.osu.edu without ha= rming your security at two.osu.edu. Would the alternative be to specify a domain (or origin?) in the token bind= ing negotiation TLS extension, like the cookie "domain" parameter? Or is correlation within an eTLD+1 simply the reality of the web? > I hope that helps. > > John B. -- James Manger From nobody Fri Aug 5 09:52: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 AE46812D906 for ; Fri, 5 Aug 2016 09:52:01 -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 ih2aTfwQUheH for ; Fri, 5 Aug 2016 09:51:58 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 B500D12D908 for ; Fri, 5 Aug 2016 09:51:58 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id q83so305688019iod.1 for ; Fri, 05 Aug 2016 09:51:58 -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=/yuZ+pZKx3rrMdrwqZaW/K8RwCLQcemIfKojT/wFyMI=; b=mv8mu2M5qEyfGqp781fUNzG22kB220A3ulGrhBKIxC2vo9jIGwQTm2G64D8qehk4ho F7Be0dovo3sBgN0PpSIJm88cFzwMRa9mXFSbofpnk2B0zFlHZ8YtC3PA8na1KuNC6lu3 Eeoo+e4oR9DC2PmCLyrku0yES+mul/CBMqTD0= 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=/yuZ+pZKx3rrMdrwqZaW/K8RwCLQcemIfKojT/wFyMI=; b=OMlRXdDR+pmrjDuacUlS0m5tu4fRdhFX0x6bgbgAGDl8Wx5Um/Qg4GRcItmTyYcnci PhIiK4R9WK+rCIvJWANGY6BV3CgjC7+pl32CbODun3zyizoEFXsNZOohOU9gM19jbjoO 5tn+3umY9nD884j4CxHTCqfGWexRRGk7ZlM+MDb+NeJUHOdIOk+sdW4YrdSbVlyY0nb/ gacYpM5lW36Ljs8aHe76WYN9YZexGSZhF7/xOrcWuTVunX0m4eWJXYd2wQjUlt7ueB7T xVpo3yjSBkoTpSLIPTvLBmQxwfnoBH8cmquprACC47L1ZoP0eKph51s8z9zpb3r3+izC bgFw== X-Gm-Message-State: AEkooutEg8H6ImvjlGSho7YWpQWB+vyyWhj6UWocWVj9lL+jQaLw3CHGGAmhyONUey7G1SVCmpNc6tu5jRHrFKcd X-Received: by 10.107.8.94 with SMTP id 91mr78278475ioi.86.1470415917835; Fri, 05 Aug 2016 09:51:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Fri, 5 Aug 2016 09:51:27 -0700 (PDT) In-Reply-To: <974CF78E8475CD4CA398B1FCA21C8E99565AB53E@PRN-MBX01-4.TheFacebook.com> References: <974CF78E8475CD4CA398B1FCA21C8E99565AB421@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565AB53E@PRN-MBX01-4.TheFacebook.com> From: Brian Campbell Date: Fri, 5 Aug 2016 10:51:27 -0600 Message-ID: To: Subodh Iyengar Content-Type: multipart/alternative; boundary=001a113f3a887486cf053955e2f0 Archived-At: Cc: IETF Tokbind WG , Nick Harper Subject: Re: [Unbearable] support for different key parameters within the same TLD+1 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, 05 Aug 2016 16:52:02 -0000 --001a113f3a887486cf053955e2f0 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 4, 2016 at 5:53 PM, Subodh Iyengar wrote: > The Http2 spec allows this connection coalescing to happen. You can run 2 > different origins on the same IP address. Servers already use SNI > information to determine which certificate to serve, similarly servers > could also use this to determine what token binding params could be > negotiated. I'm definitely not endorsing this behavior :), but that it's > possible. > > I tend to agree with Nick (and I guess you too given the non-endorsement :) that it seems like a reasonable assumption/expectation that the supported token binding key parameters would be the same in that situation. There's good reason to use SNI to chose the server certificate. Using SNI to vary TB params seems just arbitrary. I think that's an acceptable limitation. > I agree with Nick and also think a section like Token binding deployment > advice would go a long way to prevent silly mistakes from service owners. This > section could possibly say that you should use the same token bindings for > all domains within the eTLD + 1. > There are many cases where, due to different products or technology stacks or ownership or etc., that may not be feasible. Any such guidance just needs to be aware of real world deployment constraints. > It could also include guidance on migrating token binding params as well > which we're discussing on another thread. > > Subodh > ------------------------------ > *From:* Nick Harper [nharper@google.com] > *Sent:* Thursday, August 04, 2016 3:49 PM > *To:* Brian Campbell > *Cc:* Subodh Iyengar; IETF Tokbind WG > *Subject:* Re: [Unbearable] support for different key parameters within > the same TLD+1 > > I definitely think that more guidance is needed around what key parameters > a client should advertise if it already has one key for that domain. > > If the same IP address is used to host multiple domains, and the cert > covers multiple domains (e.g. one.example.com > > and two.example.com > ), > then an H2 client can coalesce connections for one.example.com > > and two.example.com > > - i.e. use one connection for requests on both domains. My assumption is > that if two domains are co-hosted like that, then they will support the > same token binding key parameters (otherwise they'd be changing what they > put in the server negotiation extension based on what the client sends in > SNI, but otherwise sending the same cert, which seems a bit odd to me). > > On Thu, Aug 4, 2016 at 3:44 PM, Brian Campbell > wrote: > >> My thinking about this was admittedly sparked by the migration thread >> between you and Nick (I'm still thinking about migration BTW). >> >> Forgive my ignorance here but how could browser coalesces connections to >> different domains if they are on different hosts (different IP addresses)? >> I guess I'm making the assumption that supported key parameters will be >> consistent per host at least. >> >> Ultimately though I guess we are on the same page that some additional >> guidance would be useful. >> >> On Thu, Aug 4, 2016 at 4:29 PM, Subodh Iyengar wrote: >> >>> Nick and I were chatting about this particular case and the problem is a >>> bit worse and a lot of guidance is needed for this. For example if you do >>> non overlapping token bindings on different domains within one TLD + 1 and >>> share a cert between them, if a browser coalesces connections between the >>> domains since their identity would be correct, token binding would fail. >>> >>> Subodh >>> ------------------------------ >>> *From:* Unbearable [unbearable-bounces@ietf.org] on behalf of Brian >>> Campbell [bcampbell@pingidentity.com] >>> *Sent:* Thursday, August 04, 2016 3:22 PM >>> *To:* IETF Tokbind WG >>> *Subject:* [Unbearable] support for different key parameters within the >>> same TLD+1 >>> >>> It's possible (maybe even likely) that different servers supporting >>> different TokenBindingKeyParameters will be deployed in the same TLD+1. >>> >>> I'm wondering if more guidance is needed around expected or desired >>> behavior in such circumstances? >>> >>> For example, let's say a browser that supports all three key parameters >>> has already established an ecdsap256 token binding with one.example.com. >>> When it goes to make a request to two.example.com, should it offer only >>> ecdsap256 in the key_parameters_list of the token_binding TLS extension? Or >>> should it offer all supported key parameters in the key_parameters_list? >>> The latter might imply that multiple Token Binding IDs are maintained by >>> the client per TLD+1. >>> >>> >>> >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/ >> >> listinfo/unbearable >> >> > --001a113f3a887486cf053955e2f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 4, 2016 at 5:53 PM, Subodh Iyengar <subodh@fb.com> wrote:
The Http2 spec allows this connection coalescing to happen. You can ru= n 2 different origins on the same IP address. Servers already use SNI infor= mation to determine which certificate to serve, similarly servers could also use this to determine what token bi= nding params could be negotiated. I'm definitely not endorsing this beh= avior :), but that it's possible.


I tend to agree with Nick = (and I guess you too given the non-endorsement :) that it seems like a reas= onable assumption/expectation that the supported token binding key paramete= rs would be the same in that situation. There's good reason to use SNI = to chose the server certificate.=C2=A0 Using SNI to vary TB params seems ju= st arbitrary. I think that's an acceptable limitation.

=C2=A0
I agree with Nick and also think a section like Token binding deployme= nt advice would go a long way to prevent silly mistakes from service owners= .=C2=A0This section could possibly say = that you should use the same token bindings for all domains within the eTLD + 1.
=

There are many cases where, due to different products o= r technology stacks or ownership or etc., that may not be feasible.=C2=A0 A= ny such guidance just needs to be aware of real world deployment constraint= s.


=C2=A0
=C2=A0It could also include guidance on migratin= g token binding params as well which we're discussing on another thread= .=C2=A0

Subodh
From: Nick Harper [nharper@google.com]
Sent: Thursday, August 04, 2016 3:49 PM
To: Brian Campbell
Cc: Subodh Iyengar; IETF Tokbind WG
Subject: Re: [Unbearable] support for different key parameters withi= n the same TLD+1

I definitely think that more guidance is needed around wha= t key parameters a client should advertise if it already has one key for th= at domain.

If the same IP address is used to host multiple domains, and the cert = covers multiple domains (e.g. one.example.com and two.example.com), then an H2 client can coalesce connections for one.example.com and two.example.com - i.e. use one connection for requests on both domains.= My assumption is that if two domains are co-hosted like that, then they wi= ll support the same token binding key parameters (otherwise they'd be c= hanging what they put in the server negotiation extension based on what the client sends in SNI, but otherwise= sending the same cert, which seems a bit odd to me).

On Thu, Aug 4, 2016 at 3:44 PM, Brian Campbell <= span dir=3D"ltr"> <bcampbe= ll@pingidentity.com> wrote:
My thinking about this was admittedly sparked by the migration thread = between you and Nick (I'm still thinking about migration BTW).

Forgive my ignorance here but how could browser coalesces connections = to different domains if they are on different hosts (different IP addresses= )? I guess I'm making the assumption that supported key parameters will= be consistent per host at least.

Ultimately though I guess we are on the same page that some additional= guidance would be useful.=C2=A0 =C2=A0

On Thu, Aug 4, 2016 at 4:29 PM, Subodh Iyengar <= span dir=3D"ltr"> <subodh@fb.com> wrote:
Nick and I were chatting about this particular case and the problem is= a bit worse and a lot of guidance is needed for this. For example if you d= o non overlapping token bindings on different domains within one TLD + 1 and share a cert between them, if a b= rowser coalesces connections between the domains since their identity would= be correct, token binding would fail.

Subodh
From: Unbearable [unbearable-bounces@ietf.org] on beha= lf of Brian Campbell [bcampbell@pingidentity.com]
Sent: Thursday, August 04, 2016 3:22 PM
To: IETF Tokbind WG
Subject: [Unbearable] support for different key parameters within th= e same TLD+1

It's possible (maybe even likely) that different servers supportin= g different TokenBindingKeyParameters will be deployed in the same TLD+1.
I'm wondering if more guidance is needed around expected or desire= d behavior in such circumstances?

For example, let's say a browser that supports all three key parameters= has already established an ecdsap256 token binding with one.example.com. When it goes to make a request to two.example.co= m, should it offer only ecdsap256 in the key_parameters_list of the tok= en_binding TLS extension? Or should it offer all supported key parameters i= n the key_parameters_list? The latter might imply that multiple Token Binding IDs are maintained by the client p= er TLD+1.




_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
htt= ps://www.ietf.org/mailman/listinfo/unbearable



--001a113f3a887486cf053955e2f0-- From nobody Fri Aug 5 10:26:54 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 91BDE12D927 for ; Fri, 5 Aug 2016 10:26: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 vnhBN25p2VVX for ; Fri, 5 Aug 2016 10:26:50 -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 9DF3912D54B for ; Fri, 5 Aug 2016 10:26:47 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id 38so306041569iol.0 for ; Fri, 05 Aug 2016 10:26: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=XQS7z+YnGS9xOs6yPZcUAXN/LanO5+jz1OpzJ5Z++/o=; b=l3bhKb1zhgYe4TAsT7LaiJSioyBqxsULcRZb5jR0+FGoS9+oBfUOTxPyTGWuVd5hBI n7Mf/a429R3LzYaHKFkgqJS6w1KUcCXv/ma1siBGoUINHzeW2asj9KHvxIWA/Nzt7iKi xvzPIZq+Y2lxmsfXSt3XIy4kNzY5/7PMEGA5g= 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=XQS7z+YnGS9xOs6yPZcUAXN/LanO5+jz1OpzJ5Z++/o=; b=DgMwsGg2tHE59oDQCfzDSschmXiRUj4/ipJQR5sB1d7uXwAm+8RvClcP2I/4lngE+F uLUJuyQ0sThGJMSgM7eBHo5pg9v523JTnx6OaJ4nvMXjLEF9SD+t1VgFrEu1MIaftWVl OFVUL9Floo/L79p/lLS+kQ+vtozd8cU6qG7cMmMGyJLikXFb6GxQ0sLwCbwZXq8G5U0N rmVKLDAcCRqnZrhG0VJeK0nOI2qsMk4Yu9wTYtaqsAQRjcfE8P0TLu47N/NvN1XQuduR fjsPDv72jFAEbjUDUJwFPIw7UiYB73uVMRpsp/DDjOWj9by7d6GnAOttpbos+A+RvUpt U23g== X-Gm-Message-State: AEkoouvdVvT7u3ArKpy9Yn35FLaJpWASU0euhgyBSI/2f1fVhoH6h3l2a2o2/a3kUs6+vwzEG/hN4Hc469aPXqxg X-Received: by 10.107.8.140 with SMTP id h12mr84657417ioi.95.1470418006836; Fri, 05 Aug 2016 10:26:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Fri, 5 Aug 2016 10:26:16 -0700 (PDT) In-Reply-To: References: <974CF78E8475CD4CA398B1FCA21C8E99565AB421@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565AB53E@PRN-MBX01-4.TheFacebook.com> <9846A6064BD102419D06814DD0D78DE1129DFAE8@CIO-TNC-D2MBX02.osuad.osu.edu> From: Brian Campbell Date: Fri, 5 Aug 2016 11:26:16 -0600 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=001a113fb6b0f85af00539565e85 Archived-At: Cc: "Cantor, Scott" , IETF Tokbind WG , Subodh Iyengar Subject: Re: [Unbearable] support for different key parameters within the same TLD+1 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, 05 Aug 2016 17:26:52 -0000 --001a113fb6b0f85af00539565e85 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 4, 2016 at 6:11 PM, Nick Harper wrote: > The HTTPSTB spec says that token binding keys must be scoped at eTLD+1 > (section 2.1). This means that if one.osu.edu and two.osu.edu support the > same key params, a client will use the same token binding key with both. > This is required so that token binding keys are scoped at the same level as > cookies. The two domains are free to negotiate different key params if they > want. > The expected client behavior in that last case is what my question was about originally. Even though token binding keys are scoped at eTLD+1, because two sub domains can negotiate different key params, there seems to be an implication that a client should be able to store a key per supported key params per eTLD+1. This wasn't immediately obvious, to me anyway, so some additional guidance seems like it might be valuable. > > The concern around H2 coalescing only applies if the two domain names > point to the same IP address and the certificate lists both domain names in > the SAN. If those conditions are met, I think it's reasonable to assume > that there's a relationship between them, and require the two domains to > negotiate the same token binding key params. > Agree. > > On Thu, Aug 4, 2016 at 5:05 PM, Cantor, Scott wrote: > >> > I agree with Nick and also think a section like Token binding deployment >> > advice would go a long way to prevent silly mistakes from service >> owners. >> > This section could possibly say that you should use the same token >> bindings >> > for all domains within the eTLD + 1. >> >> I trust it's understood that at a large organization, there is no way to >> assume any relationship whatsoever between one.osu.edu and two.osu.edu. >> Different software, departments, operating policies, everything. They may >> as well not be related. >> >> This spec doesn't assume that a binding to one is equivalent to the >> other, does it? That would be...really unfortunate. >> >> -- Scott >> >> > --001a113fb6b0f85af00539565e85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 4, 2016 at 6:11 PM, Nick Harper <nharper@google.com&g= t; wrote:
The HTTPSTB spec says that token binding keys must be scoped at= eTLD+1 (section 2.1). This means that if one.osu.edu and two.osu.edu support the same key params, a client will use = the same token binding key with both. This is required so that token bindin= g keys are scoped at the same level as cookies. The two domains are free to= negotiate different key params if they want.

The expected client behavior in that last case is what my question= was about originally. Even though token binding keys are scoped at eTLD+1,= because two sub domains can negotiate different key params, there seems to= be an implication that a client should be able to store a key per supporte= d key params per eTLD+1. This wasn't immediately obvious, to me anyway,= so some additional guidance seems like it might be valuable.=C2=A0

=C2=A0
<= div dir=3D"ltr">

The concern around H2 coalescing only a= pplies if the two domain names point to the same IP address and the certifi= cate lists both domain names in the SAN. If those conditions are met, I thi= nk it's reasonable to assume that there's a relationship between th= em, and require the two domains to negotiate the same token binding key par= ams.

Agree.
=C2= =A0

On Thu, Aug 4, 2016 at = 5:05 PM, Cantor, Scott <cantor.2@osu.edu> wrote:
> I agree with Nick and a= lso think a section like Token binding deployment
> advice would go a long way to prevent silly mistakes from service owne= rs.
> This section could possibly say that you should use the same token bin= dings
> for all domains within the eTLD + 1.

I trust it's understood that at a large organization, there is n= o way to assume any relationship whatsoever between one.osu.edu and two.osu.edu. = Different software, departments, operating policies, everything. They may a= s well not be related.

This spec doesn't assume that a binding to one is equivalent to the oth= er, does it? That would be...really unfortunate.

-- Scott



--001a113fb6b0f85af00539565e85-- From nobody Fri Aug 5 12:45: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 C13A712D900 for ; Fri, 5 Aug 2016 12:45:24 -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 hv0H1eYVMDob for ; Fri, 5 Aug 2016 12:45:20 -0700 (PDT) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 A546712D18A for ; Fri, 5 Aug 2016 12:45:18 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id x130so30317274ite.1 for ; Fri, 05 Aug 2016 12:45: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=14Mt6MFQwGtCgsVIUxI2I34Lvnj1NFVuIiR8LBoyuuo=; b=AgO6XJ1eINDcrpFz2nWNuoGrgiSvOG43zjk/g+gFYYIDlHEsMc9cRFaEw5teVMKM1J 3GlrtmZ4ju59KDk0oHUObS2p5VKhoV9kfEeelBnAXOPfUtvq39j0RKFJMMTkkmbM3Cgq 5dilmKlHvHdlLZQhpH4yk/kxolVZ2vV7jhIXU= 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=14Mt6MFQwGtCgsVIUxI2I34Lvnj1NFVuIiR8LBoyuuo=; b=EtCqQ8oh6sma9NFedv40fU0C9unyqzGzGHyUvJ8uwl7+kJr+r/f9YvuociUf7SrSez TWHnVAk+rniniF8OEXcChkabOOCYHHE3CJDe10cXGZmT4I+pFm8tWQORxKW9FXhHdsOu VB0zxdnC2gWI6T5HfdGD1lM5WWJTJMWALxtVTLxEa8bAYyyCejZXTQ3n51BJYhH03e0h QU2Unx58ejNyQlUemUNUTrXErIIKuav9962RPgpgNSRm+dzqgIqOII36bT+9YcRxJa4+ fotM/lHvlTbRgc/xVkzahT2eBLk8VKfa4zxMns6GwjoueXrcxufZLCeke4Cmke/LfWva m15A== X-Gm-Message-State: AEkoouvBnRagPy8EUQykFPwd+pSmrYalINV0HcGVNL7xVX99wWMvXkYse8BPh7KK/vC3vsVl+lA6KgWzr0pphBkX X-Received: by 10.36.34.145 with SMTP id o139mr6540461ito.11.1470426317846; Fri, 05 Aug 2016 12:45:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Fri, 5 Aug 2016 12:44:47 -0700 (PDT) From: Brian Campbell Date: Fri, 5 Aug 2016 13:44:47 -0600 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary=001a114066705813610539584ee7 Archived-At: Subject: [Unbearable] referred token binding and unknown key_parameters 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, 05 Aug 2016 19:45:25 -0000 --001a114066705813610539584ee7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The way that TokenBindingID and TokenBindingKeyParameters are structured in TBPROTO =C2=A73 would seem to mean that a system processing a TokenBindingMessage would be unable to proceed if it encountered a key_parameters that it didn't understand. This should never be a problem with the provided TB because the key_parameters are negotiated in the handshake. However, the referred TB isn't negotiated with the token provider and so might contain a TokenBindingID that the token provider doesn't know how to parse. For example, say a new EdDSA TokenBindingKeyParameters is defined in the future, which a browser and relying party / token consumer web site support before an identity / token provider. A federated flow with the Include-Referred-Token-Binding-ID header would result in the new new EdDSA TokenBindingKeyParameters being sent to the identity / token provider as the referred token binding, which would make the TokenBindingMessage (nearly) impossible to process because it doesn't know the structure or length of the new token binding ID. Would it make sense to have TokenBindingID/TokenBindingKeyParameters defined more like TLS hello extensions where the type and length are available in the front of the structure in a consistent way? That would allow for processors of TokenBindingMessages to skip over TokenBindingIDs that aren't understood. --001a114066705813610539584ee7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The way that TokenBindingID and TokenB= indingKeyParameters are structured in TBPROTO =C2=A73 would seem = to mean that a system processing a TokenBindingMessage would be unable to p= roceed if it encountered a key_parameters that it didn't understand.
This should never be a problem with the provided TB because the = key_parameters are negotiated in the handshake.

However, the = referred TB isn't negotiated with the token provider and so might conta= in a TokenBindingID that the token provider doesn't know how to parse. = For example, say a new EdDSA TokenBindingKeyParameters is defined in the fu= ture, which a browser and relying party / token consumer web site support b= efore an identity / token provider. A federated flow with the Include-Refer= red-Token-Binding-ID header would result in the new new EdDSA TokenBindingK= eyParameters being sent to the identity / token provider as the referred to= ken binding, which would make the TokenBindingMessage (nearly) impossible t= o process because it doesn't know the structure or length of the new to= ken binding ID.

Would it make sense to have TokenBindingID/To= kenBindingKeyParameters defined more like TLS hello extensions where the ty= pe and length are available in the front of the structure in a consistent w= ay? That would allow for processors of TokenBindingMessages to skip over To= kenBindingIDs that aren't understood.

<= br>


--001a114066705813610539584ee7-- From nobody Sun Aug 7 10:15: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 EF0AA12D197 for ; Sun, 7 Aug 2016 10:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ryc431pJCu-6 for ; Sun, 7 Aug 2016 10:15:55 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0115.outbound.protection.outlook.com [104.47.36.115]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B05D12D0A0 for ; Sun, 7 Aug 2016 10:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dtqjPPOsv5VmPfD+cCDpurQfeeKVDJfVQNMpsQrMXPU=; b=Rr761XVxg9dtlxgX+CYGzcHDSpZn2XsaHE2EAGi1pqKdSinoPMxXWnPvmuKGRD7YYH+xMBEPYKS47LBE2oDQREYyvU72jaLspKCWR6IiByKRtWqlN01p73xwUiNpbClFXND08TjGKKeUHteCK9IVTBWseKbHBr7ebme4MRln97I= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Sun, 7 Aug 2016 17:15:52 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0549.025; Sun, 7 Aug 2016 17:15:52 +0000 From: Andrei Popov To: Brian Campbell , IETF Tokbind WG Thread-Topic: [Unbearable] referred token binding and unknown key_parameters Thread-Index: AQHR71H1I13Y1GDGL0KPanqr+zz3U6A9u6Fg Date: Sun, 7 Aug 2016 17:15:52 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [50.46.229.189] x-ms-office365-filtering-correlation-id: 37663ee1-cdab-4dd9-fa3f-08d3bee67c23 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2155; 6:U+r6QNwYF4bhJZJttUrGPO2kFfdl3LH2C8QtM3GwgAP71slF07wvXzTDpuww8LbOG6EirhXtA2Da674vqMY5gmkTfbQEiL16tJ5tQ0mmdrRetnMpp1z6SIQfiHdg5/s9hZnThRay6dR+Nasr0UYcQb14gcOO5e8nMP+Bba5I9gmKiWHgFpZXVWm6LQUnJrzOYX4tnZ3nVGIrdgUmdUOhjtHdg1eNb0ldDe2MfDs/S5KaGKLzjItIgL3BbomuQHAaWYrPU9tGp3AnqkkskQALW/e2qF0zDUMBkzS2R44unAwKcIk4DPlTu1DkuhR5JRxr9bhx3miZdpd/2YM6Xi/FrA==; 5:aklxenu0fGNE+4AoHyOtoV11EhSAPGkPB7W4eX/SjCnieWSDglzEk8zYneSEWdq9itmonloETc+/G2Vy9CSEsfYYiGjddsQFjByvTIOQqb7uGh7Hv3jT0uccAnNGNioerMpbbQRZZxpqyvRAy7kBNw==; 24:8gR3WM2DCpbQ7z5zY3ttpbB7V5Pt8VrObl6luJhhU3z6Ztu24ChUFrDS6Ho1uR48wLxCjdNf83wMrPCU5Hcx9DpGEMNshW8jSErndbv4IP0=; 7:IcjaCOP6nv+1jUk3yeTNhkUt+emzy0bovFfYHFcA2DNmjWP6HE7Fv/6MwY7uZWQsc9vbHhu+urL/lLoNyJmeYLIWRJKUxZ/egsPYWqkjd+OojW3DLd1eEaCIFiCOM0GOfz8UD2x6vy+1FeaeifYc0Hk6nEDUw90LECy1nn4By5SLC2jB8ZTxyIUkQrtIwpJrciBw30XTEVf6UiHbhd/ATHEkQ7Tp5tIvSCpm1i12D9DieMTjIdt8p8mVWjU6ycsl x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2155; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2155; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2155; x-forefront-prvs: 0027ED21E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(199003)(189002)(16236675004)(2906002)(9686002)(19300405004)(189998001)(86362001)(92566002)(68736007)(3660700001)(86612001)(586003)(3280700002)(99286002)(19609705001)(2950100001)(2900100001)(19580405001)(19580395003)(15975445007)(77096005)(790700001)(87936001)(6116002)(102836003)(7846002)(76176999)(74316002)(107886002)(5002640100001)(8676002)(8990500004)(10090500001)(8936002)(101416001)(106116001)(106356001)(10400500002)(10290500002)(5005710100001)(66066001)(33656002)(105586002)(81156014)(81166006)(19625215002)(3846002)(50986999)(7736002)(7696003)(122556002)(97736004)(11100500001)(5001770100001)(7906003)(19617315012)(76576001)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2155; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB21550C08FD6702D210BF3B168C1A0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2016 17:15:52.1728 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2155 Archived-At: Subject: Re: [Unbearable] referred token binding and unknown key_parameters 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: Sun, 07 Aug 2016 17:15:58 -0000 --_000_CY1PR03MB21550C08FD6702D210BF3B168C1A0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBpdCBtYXkgYmUgYSBnb29kIGlkZWEgdG8gZG8gc29tZXRoaW5nIGxpa2UgdGhpczoNCg0K ICAgICBzdHJ1Y3Qgew0KICAgICAgICAgVG9rZW5CaW5kaW5nS2V5UGFyYW1ldGVycyBrZXlfcGFy YW1ldGVyczsNCiAgICAgICAgIG9wYXF1ZSBUb2tlbkJpbmRpbmdJRF9kYXRhPDEuLjJeMTYtMT47 DQogICAgICAgICB9DQogICAgIH0gVG9rZW5CaW5kaW5nSUQ7DQoNCldoZXJlIFRva2VuQmluZGlu Z0lEX2RhdGEgaXMgUlNBUHVibGljS2V5LCBFQ1BvaW50IG9yIHNvbWV0aGluZyBlbHNlLCBkZXBl bmRpbmcgb24gdGhlIGtleV9wYXJhbWV0ZXJzLiBUaGlzIGFkZHMgYSBjb3VwbGUgb2YgYnl0ZXMs IGJ1dCBtYWtlcyB0aGUgZW50aXJlIFRva2VuQmluZGluZyBza2lwcGFibGUuDQoNCkRvIHlvdSBt aW5kIG9wZW5pbmcgYSBHaXRIdWIgaXNzdWUsIHNvIHRoYXQgd2UgZG9u4oCZdCBmb3JnZXQgYWJv dXQgdGhpcz8NCg0KVGhhbmtzLA0KDQpBbmRyZWkNCg0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRv OnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIENhbXBiZWxs DQpTZW50OiBGcmlkYXksIEF1Z3VzdCA1LCAyMDE2IDEyOjQ1IFBNDQpUbzogSUVURiBUb2tiaW5k IFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogW1VuYmVhcmFibGVdIHJlZmVycmVk IHRva2VuIGJpbmRpbmcgYW5kIHVua25vd24ga2V5X3BhcmFtZXRlcnMNCg0KVGhlIHdheSB0aGF0 IFRva2VuQmluZGluZ0lEIGFuZCBUb2tlbkJpbmRpbmdLZXlQYXJhbWV0ZXJzIGFyZSBzdHJ1Y3R1 cmVkIGluIFRCUFJPVE8gwqczPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXRva2JpbmQtcHJvdG9jb2wtMDgjc2VjdGlvbi0zPiB3b3VsZCBzZWVtIHRvIG1lYW4gdGhhdCBh IHN5c3RlbSBwcm9jZXNzaW5nIGEgVG9rZW5CaW5kaW5nTWVzc2FnZSB3b3VsZCBiZSB1bmFibGUg dG8gcHJvY2VlZCBpZiBpdCBlbmNvdW50ZXJlZCBhIGtleV9wYXJhbWV0ZXJzIHRoYXQgaXQgZGlk bid0IHVuZGVyc3RhbmQuDQpUaGlzIHNob3VsZCBuZXZlciBiZSBhIHByb2JsZW0gd2l0aCB0aGUg cHJvdmlkZWQgVEIgYmVjYXVzZSB0aGUga2V5X3BhcmFtZXRlcnMgYXJlIG5lZ290aWF0ZWQgaW4g dGhlIGhhbmRzaGFrZS4NCkhvd2V2ZXIsIHRoZSByZWZlcnJlZCBUQiBpc24ndCBuZWdvdGlhdGVk IHdpdGggdGhlIHRva2VuIHByb3ZpZGVyIGFuZCBzbyBtaWdodCBjb250YWluIGEgVG9rZW5CaW5k aW5nSUQgdGhhdCB0aGUgdG9rZW4gcHJvdmlkZXIgZG9lc24ndCBrbm93IGhvdyB0byBwYXJzZS4g Rm9yIGV4YW1wbGUsIHNheSBhIG5ldyBFZERTQSBUb2tlbkJpbmRpbmdLZXlQYXJhbWV0ZXJzIGlz IGRlZmluZWQgaW4gdGhlIGZ1dHVyZSwgd2hpY2ggYSBicm93c2VyIGFuZCByZWx5aW5nIHBhcnR5 IC8gdG9rZW4gY29uc3VtZXIgd2ViIHNpdGUgc3VwcG9ydCBiZWZvcmUgYW4gaWRlbnRpdHkgLyB0 b2tlbiBwcm92aWRlci4gQSBmZWRlcmF0ZWQgZmxvdyB3aXRoIHRoZSBJbmNsdWRlLVJlZmVycmVk LVRva2VuLUJpbmRpbmctSUQgaGVhZGVyIHdvdWxkIHJlc3VsdCBpbiB0aGUgbmV3IG5ldyBFZERT QSBUb2tlbkJpbmRpbmdLZXlQYXJhbWV0ZXJzIGJlaW5nIHNlbnQgdG8gdGhlIGlkZW50aXR5IC8g dG9rZW4gcHJvdmlkZXIgYXMgdGhlIHJlZmVycmVkIHRva2VuIGJpbmRpbmcsIHdoaWNoIHdvdWxk IG1ha2UgdGhlIFRva2VuQmluZGluZ01lc3NhZ2UgKG5lYXJseSkgaW1wb3NzaWJsZSB0byBwcm9j ZXNzIGJlY2F1c2UgaXQgZG9lc24ndCBrbm93IHRoZSBzdHJ1Y3R1cmUgb3IgbGVuZ3RoIG9mIHRo ZSBuZXcgdG9rZW4gYmluZGluZyBJRC4NCldvdWxkIGl0IG1ha2Ugc2Vuc2UgdG8gaGF2ZSBUb2tl bkJpbmRpbmdJRC9Ub2tlbkJpbmRpbmdLZXlQYXJhbWV0ZXJzIGRlZmluZWQgbW9yZSBsaWtlIFRM UyBoZWxsbyBleHRlbnNpb25zIHdoZXJlIHRoZSB0eXBlIGFuZCBsZW5ndGggYXJlIGF2YWlsYWJs ZSBpbiB0aGUgZnJvbnQgb2YgdGhlIHN0cnVjdHVyZSBpbiBhIGNvbnNpc3RlbnQgd2F5PyBUaGF0 IHdvdWxkIGFsbG93IGZvciBwcm9jZXNzb3JzIG9mIFRva2VuQmluZGluZ01lc3NhZ2VzIHRvIHNr aXAgb3ZlciBUb2tlbkJpbmRpbmdJRHMgdGhhdCBhcmVuJ3QgdW5kZXJzdG9vZC4NCg0KDQoNCg0K --_000_CY1PR03MB21550C08FD6702D210BF3B168C1A0CY1PR03MB2155namp_ 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 IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlllcywgaXQgbWF5IGJl IGEgZ29vZCBpZGVhIHRvIGRvIHNvbWV0aGluZyBsaWtlIHRoaXM6PGJyPg0KPGJyPg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgc3RydWN0IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUb2tlbkJpbmRpbmdLZXlQYXJhbWV0ZXJzIGtl eV9wYXJhbWV0ZXJzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IG9wYXF1ZSBUb2tlbkJpbmRpbmdJRF9kYXRhJmx0OzEuLjJeMTYtMSZndDs7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH0gVG9rZW5CaW5kaW5nSUQ7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PldoZXJlIFRva2VuQmluZGluZ0lEX2RhdGEgaXMgUlNBUHVibGljS2V5LCBFQ1BvaW50IG9yIHNv bWV0aGluZyBlbHNlLCBkZXBlbmRpbmcgb24gdGhlIGtleV9wYXJhbWV0ZXJzLiBUaGlzIGFkZHMg YSBjb3VwbGUgb2YgYnl0ZXMsIGJ1dCBtYWtlcyB0aGUgZW50aXJlIFRva2VuQmluZGluZyBza2lw cGFibGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkRvIHlvdSBtaW5kIG9wZW5pbmcgYSBHaXRIdWIgaXNzdWUs IHNvIHRoYXQgd2UgZG9u4oCZdCBmb3JnZXQgYWJvdXQgdGhpcz88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhh bmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFVuYmVh cmFibGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkJyaWFuIENhbXBiZWxsPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgQXVndXN0IDUs IDIwMTYgMTI6NDUgUE08YnI+DQo8Yj5Ubzo8L2I+IElFVEYgVG9rYmluZCBXRyAmbHQ7dW5iZWFy YWJsZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1VuYmVhcmFibGVdIHJlZmVy cmVkIHRva2VuIGJpbmRpbmcgYW5kIHVua25vd24ga2V5X3BhcmFtZXRlcnM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPlRoZSB3YXkgdGhhdCBUb2tlbkJpbmRpbmdJRCBhbmQgVG9rZW5C aW5kaW5nS2V5UGFyYW1ldGVycyBhcmUgc3RydWN0dXJlZCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1wcm90b2NvbC0wOCNzZWN0aW9u LTMiPlRCUFJPVE8gwqczPC9hPiB3b3VsZCBzZWVtIHRvIG1lYW4gdGhhdCBhIHN5c3RlbSBwcm9j ZXNzaW5nIGEgVG9rZW5CaW5kaW5nTWVzc2FnZSB3b3VsZCBiZSB1bmFibGUgdG8gcHJvY2VlZCBp ZiBpdCBlbmNvdW50ZXJlZCBhIGtleV9wYXJhbWV0ZXJzIHRoYXQgaXQgZGlkbid0IHVuZGVyc3Rh bmQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+VGhpcyBzaG91bGQgbmV2ZXIgYmUgYSBwcm9ibGVtIHdpdGgg dGhlIHByb3ZpZGVkIFRCIGJlY2F1c2UgdGhlIGtleV9wYXJhbWV0ZXJzIGFyZSBuZWdvdGlhdGVk IGluIHRoZSBoYW5kc2hha2UuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5Ib3dldmVyLCB0aGUgcmVmZXJy ZWQgVEIgaXNuJ3QgbmVnb3RpYXRlZCB3aXRoIHRoZSB0b2tlbiBwcm92aWRlciBhbmQgc28gbWln aHQgY29udGFpbiBhIFRva2VuQmluZGluZ0lEIHRoYXQgdGhlIHRva2VuIHByb3ZpZGVyIGRvZXNu J3Qga25vdyBob3cgdG8gcGFyc2UuIEZvciBleGFtcGxlLCBzYXkgYSBuZXcgRWREU0EgVG9rZW5C aW5kaW5nS2V5UGFyYW1ldGVycw0KIGlzIGRlZmluZWQgaW4gdGhlIGZ1dHVyZSwgd2hpY2ggYSBi cm93c2VyIGFuZCByZWx5aW5nIHBhcnR5IC8gdG9rZW4gY29uc3VtZXIgd2ViIHNpdGUgc3VwcG9y dCBiZWZvcmUgYW4gaWRlbnRpdHkgLyB0b2tlbiBwcm92aWRlci4gQSBmZWRlcmF0ZWQgZmxvdyB3 aXRoIHRoZSBJbmNsdWRlLVJlZmVycmVkLVRva2VuLUJpbmRpbmctSUQgaGVhZGVyIHdvdWxkIHJl c3VsdCBpbiB0aGUgbmV3IG5ldyBFZERTQSBUb2tlbkJpbmRpbmdLZXlQYXJhbWV0ZXJzDQogYmVp bmcgc2VudCB0byB0aGUgaWRlbnRpdHkgLyB0b2tlbiBwcm92aWRlciBhcyB0aGUgcmVmZXJyZWQg dG9rZW4gYmluZGluZywgd2hpY2ggd291bGQgbWFrZSB0aGUgVG9rZW5CaW5kaW5nTWVzc2FnZSAo bmVhcmx5KSBpbXBvc3NpYmxlIHRvIHByb2Nlc3MgYmVjYXVzZSBpdCBkb2Vzbid0IGtub3cgdGhl IHN0cnVjdHVyZSBvciBsZW5ndGggb2YgdGhlIG5ldyB0b2tlbiBiaW5kaW5nIElELg0KPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvdWxkIGl0IG1ha2Ugc2Vu c2UgdG8gaGF2ZSBUb2tlbkJpbmRpbmdJRC9Ub2tlbkJpbmRpbmdLZXlQYXJhbWV0ZXJzIGRlZmlu ZWQgbW9yZSBsaWtlIFRMUyBoZWxsbyBleHRlbnNpb25zIHdoZXJlIHRoZSB0eXBlIGFuZCBsZW5n dGggYXJlIGF2YWlsYWJsZSBpbiB0aGUgZnJvbnQgb2YgdGhlIHN0cnVjdHVyZSBpbiBhIGNvbnNp c3RlbnQgd2F5PyBUaGF0IHdvdWxkIGFsbG93IGZvciBwcm9jZXNzb3JzIG9mIFRva2VuQmluZGlu Z01lc3NhZ2VzDQogdG8gc2tpcCBvdmVyIFRva2VuQmluZGluZ0lEcyB0aGF0IGFyZW4ndCB1bmRl cnN0b29kLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR03MB21550C08FD6702D210BF3B168C1A0CY1PR03MB2155namp_-- From nobody Sun Aug 7 19:38:34 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 B5F6212D518 for ; Sun, 7 Aug 2016 19:38:32 -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, FREEMAIL_FROM=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 (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 wfXhaDm8X2_m for ; Sun, 7 Aug 2016 19:38:31 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 1161912D1E7 for ; Sun, 7 Aug 2016 19:38:31 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id p186so184633479qkd.1 for ; Sun, 07 Aug 2016 19:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FMrjvNXmDbDt6puxVHcRccs1djR4ykAYyFjAr0hnOe8=; b=0STPEneM4sYVwE2ZqOCXB3hT8v2n8M5zT+4QeAi8Bkv/ujvfLjDUakibF5FD6wCee0 pZvzaTU4o+zAbtsj6pglShyEWYKLp5etOoQqK7Tj7f49MDo3FyhoTojVAl8Xkap6Xf8A B4TjB0EFWxzpnscb4/nC9GdKLtkyyxG5M3xW/UaWH9dGflhRFkr67J3iMWkBmIS94z/9 WMfFOdvbFLck2SEmVsd1hKmGu7A1QXHX1zAwc71Ji5y/DIyu4M2tTrFZ2YJg3tcWZImy H+CD+QZ1uZqOxSTd3E8SVe2tc4UBtYcMZ7IWkkqyjnmv52iQd+KfNtp6K/F4RJqpexD3 0U7A== 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=FMrjvNXmDbDt6puxVHcRccs1djR4ykAYyFjAr0hnOe8=; b=QR1pmrdK96Ty8ICAsgxfMFYN8x2vtJU5y+1kSUQs+C230h1OWMgz/EQt9lEgNW4Ajw RJcaOfcdp3BIVicpi6uN9KUHZrEB5D4kPiY7yLHH1M0rtdGR5ZjNLJd/5Aor3nNzAUnB V3hzIRYn6zdmoIbY9fe4JB5+qeVOFM+O75AYjQDS2ZG1DpxbcHOaZ1Zsol6MDsVA63IW UknBJo4xsBQ4dYbZx3RHwZ+7qZ8ctT+05MJ1s8QfRTfGFkKxJ78lPkdSdsN5o8dCZp8t Bd/QhpLDWQ2pphIJbupZ9oNW7UYBZR13eSbKqUu4vaY6pPNy/hltzU/DsSKONG6PdCgK 68FA== X-Gm-Message-State: AEkooutFYKUelF4zXwJaQiJgpkCfgkzif+mvpzsui7HHenUx0wr3ZkIWZqMVIBFVc6j94ZYpP2s9482j/eNFOw== X-Received: by 10.55.116.134 with SMTP id p128mr3903597qkc.165.1470623910217; Sun, 07 Aug 2016 19:38:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Sun, 7 Aug 2016 19:38:29 -0700 (PDT) In-Reply-To: References: <974CF78E8475CD4CA398B1FCA21C8E99565A9DF7@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9EB0@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9F26@PRN-MBX01-4.TheFacebook.com> From: Martin Thomson Date: Mon, 8 Aug 2016 12:38:29 +1000 Message-ID: To: Nick Harper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "unbearable@ietf.org" , Subodh Iyengar Subject: Re: [Unbearable] migrations of token bindings 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, 08 Aug 2016 02:38:33 -0000 On 4 August 2016 at 11:04, Nick Harper wrote: > When a server receives a TokenBindingMessage with two provided > TokenBindings, it must rebind the tokens sent by the client to be bound to > the new key (this is identified as the key of the type that the server has > ranked higher on its preference list). What about those tokens that require a third-party to authenticate them? See also the discussion in ACME regarding the migration of keys. There's an attack that is described there if you just have independent signatures. See https://mailarchive.ietf.org/arch/msg/acme/-HKly8leUaA_TT6r0mgIkoX52tM From nobody Sun Aug 7 23:50:48 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 60D1D12D74C for ; Sun, 7 Aug 2016 23:50:47 -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, FREEMAIL_FROM=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 (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 WzfpUE1emzr8 for ; Sun, 7 Aug 2016 23:50:46 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::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 0624712D192 for ; Sun, 7 Aug 2016 23:50:46 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id t7so37439902qkh.0 for ; Sun, 07 Aug 2016 23:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=7Nj+GW8xuA4RWNzMcU1AVfk197ePikBS00i921T9MMU=; b=ABt9pp+puSN4cgFPU4bgURMnyUD+xUKNQll0Uo0aep1KBvsh9BRER/TmfXqK68xy/v NKqY33s4FdwUQTkF4hiBjL/Puyjn0CgTLQF8MpZ9e5kTvUXpGOcL0gafDcBJHLbkuiB2 viyfedLOuEdVtTrmk/JQ7jtTA5uRDTP5IEFntGrgSCJuQW/WeXknFZlWaWzTBcIWbUSx evmdPdvcytoOprHmfuaMYxtNwUwden7/f37u5bTq8TqIwOWSZJKoS42bktoPV88/1ZZy OvP49mIU/hRPGqdCtz7BsTapGEM/VWYKpCnCQXsY9SIRvbMlyQWIBWB6viYIDkQSdvIV oSCw== 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=7Nj+GW8xuA4RWNzMcU1AVfk197ePikBS00i921T9MMU=; b=ivTSd/vG2DtmBWAWJ6HddlIBgRqOras4H0nm+0zDi8qHsjrnFPRaB1r4pLVA9vgT87 6z0Y7Yy52yeyRt9/g3e6+e6esa9rhL8gZ503xFT6rdsm8anivPdsgJcwq+G1lD2sSlMG q7bfOTNuYvhaDLkdPdJmOZIqxYzlNNKIP3UK7ypbpCyXZduVMwuSbDjch6H6hvWxqUGn 0eFpuHzCU0fhaG7pg50Yj4GYY+ooHw2Vkuo5fA1B9vO50xOgnsNkcWY/KOBbeJoeTb0Y ALUTRmoqU3flvKsxZeRNFodRfAUvOUe1LyWNvDQgj9IQJIb9EUYP0Rv26QrIyu5W/U02 u1Fw== X-Gm-Message-State: AEkoouuq1jGdlbufTR/aJ3cSE9EzC8rtIQif1DZyMM/Uy/1JcT8xMnDHr6Hp42wtJT1g3EhkJntMNw/NJzxd7w== X-Received: by 10.55.6.19 with SMTP id 19mr7641370qkg.156.1470639045091; Sun, 07 Aug 2016 23:50:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Sun, 7 Aug 2016 23:50:44 -0700 (PDT) From: Martin Thomson Date: Mon, 8 Aug 2016 16:50:44 +1000 Message-ID: To: "unbearable@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Unbearable] TLS extension: version field 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, 08 Aug 2016 06:50:47 -0000 This is getting a lot of use recently: https://www.imperialviolet.org/2016/05/16/agility.html Specifically: "concentrate all extensibility in a single place and actively defend it". The version field in the TLS extension is a great example of exactly the sort of field we should avoid on these grounds. Why can't we just use a new extension when it comes time to replace this protocol with version 2? From nobody Sun Aug 7 23:54:41 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 683D112B049 for ; Sun, 7 Aug 2016 23:54:35 -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, FREEMAIL_FROM=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 (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 X3Xkh_SwDxGM for ; Sun, 7 Aug 2016 23:54:32 -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 B734012B01F for ; Sun, 7 Aug 2016 23:54:32 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id p186so187912774qkd.1 for ; Sun, 07 Aug 2016 23:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=YCJx2G+Skyu01IZ4O2edV3SZbTxb7lw8tniUJezCgmU=; b=wwWtr58tt/jsyqRRUo7XiyPo9D4jVkd1gRELrlS4EBTAiLx64ElMP+uSANe8Jw57r/ NPiBsY8AvAswijszbaS1BGX5pt/7x4tItNkhZ59tRMi6TVaRFCyDKqpD7y0Pv24Kva2V NzBfmWBGnHRQPiVBlVEwEr+I16HKToJoV85c3eK9UHFvhORj/mmoYMQbFT0/c9oeZthv BR3HS/1nF0DSHUQk9OFWQMMVoBGlRHPoxys6UDCprW04W5VMV2SBn10T9M/rrT3Scc4z R+dbzX+H4xYwddaQ6XMc3s8ZkAtX5a1+ot5vL21q4CHZtaarA+X+RsHIuFceuPy5mJT3 sL/A== 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=YCJx2G+Skyu01IZ4O2edV3SZbTxb7lw8tniUJezCgmU=; b=mee8BR1ioyc/lHj3RzDrlkDSZG/7R5OO4BVluBAaQ8NXrLAH4/N4rK1sEPKW8sPFs4 W6c1imFDZvRcfudy8RThCePVmayQ5Tkbs4QDejQUAPSu7Ek8G3ZFXcNQ9O/n2slUvRNA mH4ivo4xwsALsV2s7vYW7N0G4+7QGJXRsK9LYZAekEKIxFuH2EUBK2ueac1IeYz7nR0F tVa+pZgv0nF3HhxHx8dZCg5hDsD0Yu5dfYIUxr1ncay+p2ABJQF7pQA+j6P9S0oFPjBG rg5LumO92GDc1cgVz74y+Mb/1WwJugq3xuPBZr+g40OJmw70V19Z8kzpR9kLOm1OqQyQ ZL2w== X-Gm-Message-State: AEkooutdfCU5r3PdBaL7SVrIHd4W5xlJWcsLU1ESPaLqqD/zl7gRjtQZI2bqma2g9X7Ipe3BIFtPw6ZU08wXGg== X-Received: by 10.55.116.134 with SMTP id p128mr4626174qkc.165.1470639271660; Sun, 07 Aug 2016 23:54:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Sun, 7 Aug 2016 23:54:31 -0700 (PDT) From: Martin Thomson Date: Mon, 8 Aug 2016 16:54:31 +1000 Message-ID: To: "unbearable@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Unbearable] Renegotiation info extension 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, 08 Aug 2016 06:54:35 -0000 I know that this is probably old news, but there is an alternative to using the renegotiation info extension. That is to forbid renegotiation entirely. We're at the point now where lots of implementations do this and some of them are not including the RI extension at the same time. For TB, rather than requiring RI, can we instead prohibit the use of renegotiation if RI is not negotiated? From nobody Mon Aug 8 00:53: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 1FC6512B068 for ; Mon, 8 Aug 2016 00:53:57 -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, FREEMAIL_FROM=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 (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 LjY6Mt6jj96m for ; Mon, 8 Aug 2016 00:53:56 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 0979E12B02A for ; Mon, 8 Aug 2016 00:53:55 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id x185so121808533qkc.2 for ; Mon, 08 Aug 2016 00:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=nwRmNg1xQFAMi5o6Fqo3oksxcK+25s18D7h74b4WItU=; b=skPXozZgBmkO/KGxMPaauANhoyXMH+erIE2Z838moSYctFxAdm4aUb4DOrv4O3txhw /lXI5osscgOZphEiSppyQ9qluU/AyydXdnDvAAPn4VSJ3P3dr2x+LCcmoO+pKxf7BIte wZFrchlVNSmutiNGhrlI5isu4VhAlhovc/1iuBNFHtLuejeGU55sNQ4GOxL8SJFlI6nZ b1Pqu771HxcNAcfxOxI6HQDW93UdR/I7oMNc6hvFTVjUI8Ix6hbXGzIA9hG+CqW1w3In 6WH4a1Ll0PQimCKQs0Z0DBKCCq4XOy1mntzO2F+lBOnus5zJ3nKnmMzLDZ+lEeMGOOIE 5ufQ== 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:content-transfer-encoding; bh=nwRmNg1xQFAMi5o6Fqo3oksxcK+25s18D7h74b4WItU=; b=Rj3dCEKURlSH3bbT1ypssKjuD59JySOEuCGay3SueBHQikgME7f3Z7dyoNNwYGzL7E /je4UFizernL3SEfQYJpfkpV3GqHm9QH/C8fpjCtYLXOCYZmsnbnDrUz3G48Nb12KZFb RUb9l9vviYWZKHXTS4HImGCymWIcT6tDnXfptocsI8QglM44LRt+EIo5YU1bNr5JQsie fTHqdnnS07EEwxpcl3+lFCvgisBHqp6/tVhS3SHkh4iFJgc/HzLhO7h7vjpGJQtFegF8 9h4Q3nPJpMDobO0xU4Hbj+YEeyA/WlRs1xBFfYavXtyvZV4/oVULliH2aGKgIqCZ7YAh /vrw== X-Gm-Message-State: AEkoout8JM0U6TMJhUCe77BPqF3+4q80WaKLdHhxVfHXhpMPuScLZKv9ZYk7yLo1qwOGO4OFv2kgsXUIj4XSaQ== X-Received: by 10.55.116.134 with SMTP id p128mr4823223qkc.165.1470642834995; Mon, 08 Aug 2016 00:53:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Mon, 8 Aug 2016 00:53:54 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 8 Aug 2016 17:53:54 +1000 Message-ID: To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF Tokbind WG , Brian Campbell Subject: Re: [Unbearable] referred token binding and unknown key_parameters 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, 08 Aug 2016 07:53:57 -0000 On 8 August 2016 at 03:15, Andrei Popov wrote: > Do you mind opening a GitHub issue, so that we don=E2=80=99t forget about= this? I independently opened #61. (Apologies to Andrei and Brian, but gmail has decided that all microsoft.com and pingidentity.com email on lists are spam. I missed these emails.) From nobody Mon Aug 8 01:04:24 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 1FF6712D60B for ; Mon, 8 Aug 2016 01:04:24 -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, FREEMAIL_FROM=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 (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 UPjE5kSR7cAW for ; Mon, 8 Aug 2016 01:04:22 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 5977412D5F8 for ; Mon, 8 Aug 2016 01:04:22 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id x185so121975230qkc.2 for ; Mon, 08 Aug 2016 01:04:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=SyyntF5MVeGI7Q7k/4mdPVt6A1393ClfBKi7qXvpUZQ=; b=w49EDGR6w959Q8VVtB2lXnDHfPhViO7UUpHTau0Qkn4Peunt9zl0Ll1twmN5pMTbxu nrj470YtuDWIZh7Pu2TOTZXxQtna9qHS/JBUqziiEyLqkXS9Alu15qsdUHMsKc7jxxQ1 feKPVo5091Ookpq0SLNfsiBZJgRMnhthdMTyw14Rnn6XqU+rCNahRwrWiS4nyBjLN2sx mlpCAdVeo5sB3HEFHI0yUtA09wKvIeEeJQSyKnZ6hSEtuihxe2Siesb6S6Y1n7ffESzs nQJFbHCpEqFxa2yEh0F3bKFRVXpNbkn/g/Q1qm54FGLK5K43pnXPADw5lIaxZcVESRBl gEbw== 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:cc; bh=SyyntF5MVeGI7Q7k/4mdPVt6A1393ClfBKi7qXvpUZQ=; b=JI5j6k6usk7hv53OX+He0nlLmTfyHL3cIBLBRR4J5bfEeqCGiCn3i2jnSW788SYo3p wZK0TrzQkaNKy1zQrGbwo5Lnr+PlkTj+fBXBPq1u80oeFGO9XbdUUsJh9B9Ej3WlCkmR Jmz0uUxNP3eBjG+2FwTNN7aNSBloSwdrKHoyb+EvPeLswJ3Ubp6S6giGwEJXr1Nh3qUT grNrC4DwLQLLcrN1PgzftJhJfgOgRDAaEjSMf4CPM1/R3flV99uSi4t5QviCbLck4aor 3AIom0usmQEVek/t3o0Y5KEPg2JirPCXaLTYw9MLbotOpIQdKyu1I8LD+KqRhluefbzL 6oQA== X-Gm-Message-State: AEkoouvTm3g7ZtKeue6Yj2c8D2tCgoyEeUU6w25rcDmW6d7D5cw7qccQYWdcRRJPgCzJSAVt45EhwRXncg6bIg== X-Received: by 10.55.184.2 with SMTP id i2mr25333290qkf.261.1470643461445; Mon, 08 Aug 2016 01:04:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Mon, 8 Aug 2016 01:04:21 -0700 (PDT) From: Martin Thomson Date: Mon, 8 Aug 2016 18:04:21 +1000 Message-ID: To: "Manger, James" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Subodh Iyengar , Scott Cantor , IETF Tokbind WG , John Bradley , Brian Campbell , Nick Harper Subject: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 08 Aug 2016 08:04:24 -0000 On 5 August 2016 at 12:42, Manger, James wrote: > Would the alternative be to specify a domain (or origin?) in the token binding negotiation TLS extension, like the cookie "domain" parameter? > Or is correlation within an eTLD+1 simply the reality of the web? The alternative is to limit token bindings to a single origin and accept that token binding only protects cookies for the origin on which they were originally created. We've taken great pains to limit the damage that our shared legacy causes. I'd rather that token binding not further entrench the mistakes of cookies. In this case, I would prefer that this go beyond the host-only handling for cookies which RFC 6265 defines, by limiting them to the full RFC 6455 tuple of scheme+host+port. That means that only the origin that generates the bound cookie can validate it, but I'm having trouble identifying cases where this would be anything worse than merely inconvenient for servers to use. From nobody Mon Aug 8 07:02:07 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 2E33212D829 for ; Mon, 8 Aug 2016 07:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 cWW77qAOV4Ce for ; Mon, 8 Aug 2016 07:02:04 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0113.outbound.protection.outlook.com [104.47.37.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9B2126D74 for ; Mon, 8 Aug 2016 07:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buckeyemailosu.onmicrosoft.com; s=selector1-osu-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fiyOXdS8cvlYrnBASgybvmyGt8ETpgrRGJFgtbXiKnE=; b=hyJhp3eB3XTMefXLE0vKYDPyxprhN6KlGOVHFfKZFKdEdOJ1r06T6VK+kRd37ahG+NcXqjtYL7HBIsphbPZuiW0oIXXL6j/LYXcfQbq7AUgj+H3qu3xbwI75tYDx7Heg1tUhMLmvClIv6E5IWPFKvclnik6lJvL45r5zFrQOESM= Received: from BN6PR01CA0060.prod.exchangelabs.com (10.172.194.150) by CO1PR01MB256.prod.exchangelabs.com (10.242.168.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 8 Aug 2016 14:02:02 +0000 Received: from BL2FFO11OLC001.protection.gbl (2a01:111:f400:7c09::100) by BN6PR01CA0060.outlook.office365.com (2603:10b6:404:cc::22) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.15 via Frontend Transport; Mon, 8 Aug 2016 14:02:01 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.218) smtp.mailfrom=osu.edu; fb.com; dkim=none (message not signed) header.d=none;fb.com; 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 BL2FFO11OLC001.mail.protection.outlook.com (10.173.161.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.557.8 via Frontend Transport; Mon, 8 Aug 2016 14:02:02 +0000 Received: from CIO-KRC-HT01.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 8B93D380034; Mon, 8 Aug 2016 10:02:01 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.03.0248.002; Mon, 8 Aug 2016 10:01:32 -0400 From: "Cantor, Scott" To: Martin Thomson , "Manger, James" Thread-Topic: Revisit eTLD+1 (was Re: [Unbearable] support for different key parameters within the same TLD+1) Thread-Index: AQHR8Ut5hSTAM1DKPkKzsrd/CJXFNaA/FxZA Date: Mon, 8 Aug 2016 14:01:31 +0000 Message-ID: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.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.249] x-header-sapphire: true Content-Type: text/plain; charset="utf-8" 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)(979002)(6009001)(7916002)(2980300002)(438002)(199003)(189002)(7696003)(7846002)(8676002)(8936002)(23676002)(356003)(8666005)(87936001)(66066001)(3846002)(16796002)(102836003)(6116002)(2900100001)(88552002)(2920100001)(2950100001)(2906002)(246002)(189998001)(55846006)(7736002)(586003)(47776003)(7596002)(4326007)(33656002)(50466002)(89122001)(106116001)(106466001)(5250100002)(50986999)(54356999)(93346002)(109096001)(76176999)(86362001)(90282001)(305945005)(75432002)(92566002)(5001770100001)(561944003)(7059030)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR01MB256; H:cio-tnc-pf04.osuad.osu.edu; FPR:; SPF:Pass; PTR:cio-tnc-pf04.osuad.osu.edu; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC001; 1:qtKjwGoNICcu92lniSBafTjIklg0y9ApPQf6AvB7VFzyj0oQjSGD3a3oGHiAYkxeEZjQ5fO7toTutK8mn4VeC77uT0faula8HsvBZbqWYumzrEafy/ChDlm+mtWDW6tfMTY1AlU+49YyNc/oKY0stvUlqmS7g28rF1czSHH87dBq11k9ORwWsfxzHM4jRO60w5KQmaUHkGndC/CdDDS/tbRZkfp5WOI61AZYRwz143W6rZworOZYgj50OqSR4L9UUIp1inU+ALMzV0KvCNl8gZOpOWdfjFSxeByJiYsZaMwQyyM5FMBRWrdBHrnGre+BYbCHNKzzHqeT0tHtQDeWoTP3DWEYgcQNtJBSZ6LLL88pJCQUMCwNMXY/XQ/xPCKL4ht0Z/dmpKSW1nopt/TpMdWMees1Z0k2YkTZ+TWh5R2nGOZy+Cx9XR2oJXccLZbDM3PcEnVXfHc2vRlfRS2O4dVHDRr7eHoBBuTH5wo5wzsgkQ/2nOWoZqM/nS/UDpL7xoEEg1CdIRzWxn6cHwhEgBbVLN9FIzMwwZYmKvgpD3/7Jv3jy1XCg4EkDY+XMn1n X-MS-Office365-Filtering-Correlation-Id: 8478a6ea-ad64-45c3-635c-08d3bf949291 X-Microsoft-Exchange-Diagnostics: 1; CO1PR01MB256; 2:yg9+n48OjbwRUehZ4uQgfhjlZYqI8MQmkEcWMW0eJb1Qp2KfVSKgBydlnfhUqhUII1aL5Hv5JAW6HH4N+8cFH2Qm4jguK/g7S34o596iZcW54LYfLmLYdn7rwwp6lJbHVYyd3HILZCu5nYBY05CmjnVvP4wd7bF6x1cYaWacp0BViOC1zkFinvefU6QdESyY; 3:BMnVq4XLs5drKs1OKwqDgMw+/6Yf9mq1SiQ6dCQ8f8JRWxfeD9BLyBBKJDfgcsiyrSafr+gpp/EU9vrE1LvXgQozscqaMdm6IrLm440PU3E18Et41iFCUC9PDQh5G5/4RZaz6ChudtdPEojpFDIpdMxMQfZ8lEcb/O695IC24Sh7LoOluR68r2yQBL6UE4Pm/AF8PKgH870fadZmmjsXLDlEUxLwKZU7oIykiMr57zt0d1gfS5IH8LihdJ04Jx8XCKzu7XdjUJCaIvqYU/6SSQ== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:CO1PR01MB256; X-Microsoft-Exchange-Diagnostics: 1; CO1PR01MB256; 25:2sTVHF0D2YbsPEOElkOVeElqwLbQF51l5J9TaPqQZPVx+kOi4sV6iOp+UVQMB5hfuOmHTqemnytciec0qlhxcroDSL9zFMVSdgYs+eH6oLy3Vor011YTXAbI0KV/wY/wI+U86mojOGuzg2WSsU7McUVARn0SV0zgzOQKFg8XWGLj+/+ixmZOSuGqZOhjL0VIecWwgTIwpoFYbWk4f4dcxjAlZ4juJymKB1hnvbC1TZ+V6fmcJkAKkRZ3ltNACm4kWZetLO31XvO+TfgaoweyjqXvSpk7tZzLpk5hlhEelfLzqpHxwPc1/elRp5VGRfOvx/zATpgaI5B80uounWfbcOTkQg6JnRWNTKIH3mCF0XndYyUFPPnqlWh8v/aCHNl+Ojc5Fo1WrqTNAN2QLHfyUsf4QoLGPW91opiyQvGlPAenasIjkX2m7UYEGPGZHOxshBlFhZCtw2y2s/Vxhjly1m6vk1rZfmbGZi4kMWZMAL1b0AM5bieg5T5pPhk4K2hFKyOzGbulMKFM3F1TrhaXh662aSdBgGXEIqXLNWBSQuPrs9tCd3TuP3iaOUO7scklnA9nxlSQNh4EH2ozWIJXbxtAhELqx4EnrOtOUY5fRU6h2TchqndkAqUOHMuKWO3JAGCQQQktmHAGKduEqM2HSCJPU67ZpVmmpbGNb4tUPt9f5/9HmfysCH2boUCZk6q0T0YcmC3rGPJYSQRcyyv1L/8EBV225vAgat3YA0vUoMJFFj9010bNgyaw0lZlZv4LjdI3Oorlh14m4m2uZJeUbQ== X-Microsoft-Exchange-Diagnostics: 1; CO1PR01MB256; 31:s6bHNGr+uzPyv+vsfZeX0m1++zEnv8M5BDjs17j8R4vwscomcFkVNBIjz5QqTDNqbDW33ougwVbi+tK6NONj7RN96x4M7e3BLde85Gx/3MaxfMJpVQsmDiQdW8mIzFM2y/LZ+KmHvfCwQ7uzjXF9HXzEItrYnzZ6K1YjBN+B0SJKwzqUIAZs4MYFX5njQGZxUIOcGu02WQ1KjVktUTwiU5qzLbrUrrWvkqtfDU2HbrM=; 20:GH/mpvDcH4uOPonsdh9hm8DzJjjQlhKzEyro0I9+OsROSpIJZsLWM4j/oH628H1bzusF9BS7H9BsCAD6aEW7rnjhN8JkdJXG1xnaWoeHBZSgoMRbjU4seZeaW3Am0snOSpkPxvPP7QENUxdLsWvCr0QldUbzJFpn8riznz3G1tEyllAJmBohrOoBr8gkwxIosjldwUjDq9aPuvVlqaDMI39phzMdWmu6T13m+caYgvFInFs3wAP9nk4OWhegr5bcKhJjpwpceuOrPCZVTqulCNIBYXtxbaCETEGDojMBQr9ux7b+yFzPzcrObz6efLcC0s+cvBxRoYFqB+B4oC/qfb4lKCS1uWXEdIksejI52LYiHCmprJkXcxLiD0mRx9ACUmbyL6ALcYzfbrsb8ocO8ZljWszUjo/W7KOS6E0oRVYgqXO3m9zfrm2McxxHlr2nu4061q3hhtnJUfrjzZHXXW+pl8XuqM7lpXjKeoJb7MgQtmx3ONTPNDXs80Es6kSG X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(13024025)(13023025)(13015025)(13017025)(5005006)(8121501046)(13018025)(3002001)(10201501046); SRVR:CO1PR01MB256; BCL:0; PCL:0; RULEID:; SRVR:CO1PR01MB256; X-Microsoft-Exchange-Diagnostics: 1; CO1PR01MB256; 4:hFTq3AzK0l3deB7CwPqX1yEhxsDSHf6FBiqjqhAsNnZ7ZPWl1uENBKzdAfWxmT6UJ1U9PUgk5iVyt45L4fGVcWJsV/7E2cEhiADTFvDwnScvnEaw9gKnXWPmnqFBbh7vmRVQ3+oRchEwJsUksoXodL2U3alyl5TDspSln05Yl9+27e9Pn4OE5eFph4SVz87QnHvR8anFQL7+ZeCEit8xCvArPV/ReBkh9kBpbyLq2AzwrQAsKgvYfXACwyo2pBSdMcvixtxg/EK5kdXSI1efesDNtylHjFUs/43av5vEtegBg9HpzMhYZ9aVYDbRjtKCJ6JpZfcWgvU0+e4E44R4ntTpWmDtOD00uqJOliy3HRtRCdE1LblWQI6zjV3tKyPG8+lOVXFQX56/GeAPICgKxtOmmXr6lzK5N8jTGBtpTp3DkZ+A/jBlLXCBh5jmO3+V X-Forefront-PRVS: 00286C0CA6 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzFQUjAxTUIyNTY7MjM6K0V0ZEE0aDdYcWQyUnFXYXVsV1ZrUzZSNFJK?= =?utf-8?B?dFFKK3VyVTk0OUlQbWJqeUZWV1AvVVlrNEpaT0FKUHpHajd0U3pOaVlJRlgw?= =?utf-8?B?L1RIblhtSjl0MHIwVFFuRXoyckpFclpQeWxySHB3ZUllNm9xeG11SGdTZlFj?= =?utf-8?B?TnhGLzFqZkhBUU51L1FhNEd6b040ZkViampZbThLc1lZa2JLQTVXYmlSQmZx?= =?utf-8?B?b3RGc0s2eFJEeTBEbE8raVpkZ0NmaEZTQVVJbkwyNnMxOE9sdVVlejNjaUt0?= =?utf-8?B?MU5rV281cFlJNXdwb3V6dm10UVlsejlhdE5KT204UzRVbUlkb2tpRWZtVHVs?= =?utf-8?B?dVRhaWl3cUhtZjV0UThia2ZvcFR3R1hMQXA3VDFaeE5DSkZWemcxZ2dpTjN3?= =?utf-8?B?bGlIV3ZhbnF4a2VBUGRKWllhaFU5cER5UU8rUHliVDFyUWpJM3c0VkNUNi9v?= =?utf-8?B?R3JRRkloVUY3UFh0ZEw1TFRoM05FdDFNNVJMOFRPdW1MQjdhWUhuTUFnOTM2?= =?utf-8?B?T1ZScTRXRlJCaXJHRkhPblgzZk1jUjhLR0RxaVpkQUhKVS8xQ2tML055Mmhp?= =?utf-8?B?d0xSaTR4U3pMZWVYL2dDSjgydklzcU5yZ2lCYitpSlpXdlBnZU1tVGJ2UXlP?= =?utf-8?B?TGU5Zjk4bkNMT0w4U0tqK0RpMTJ2QWRxazM2cmpVOFBHTk13eGdFWWZxRlky?= =?utf-8?B?VDJwQTgvZC9XbG5BWlUyUER2ZnY1MGJGaDBrZEdKVVVnb05nUVFtWkdVbXQ2?= =?utf-8?B?bWhpeWcrSnNxT1RNNDZsamorK1R5dFlsNEdJWC9nTkRqWE1BdWY1NWFsVzhh?= =?utf-8?B?bGZrMDAyWFB4Q2p1NDBpTExDOXBIWjdSVWUxaHV2cW9ZeDVyRmFUQVhGc3d5?= =?utf-8?B?REVOSHNEcDhhMWp6NXRGbUFMNDBQSEtqQjE4Q2ltVWRFLzFWbnZhUGdyY3p5?= =?utf-8?B?SzdkaDhLNUlDVzhMeE5vRURDQnFXc0ZReWVqU1N2OGtJRjBRUGRpRU9sOUIv?= =?utf-8?B?MVdiVG1rUXM1ZSt1SGFSWnhwbXFRQXBDeE9KMWFFUDhQMFVlTmJkZTR2ZzBJ?= =?utf-8?B?ZThTdXE5YTZsQ1hweU5BUEFZQnZNNWZzODZqVlAybUE2Y0IyeXhjWldOaGlO?= =?utf-8?B?blQ2R0xOTEt6WXBQNzB3U0c1by9sMEhlTG9JRENCL0dPWEJ2ek1sbllVTWlz?= =?utf-8?B?anlVRTYwZXNrdUNKbW5aMlZ4QUl5Q0hKVC9IeUJQek5KZEh3R2ZaQWRwb0lU?= =?utf-8?B?QWdyT1JZbURyNmx5a2daSmdFSGJPK3lZMXo4NGZIUVljSURoYmZJY0RHMkly?= =?utf-8?B?WEsyM1p0L1V1NTlkOTBWaHlIeXpGbWxiN0tZSzJ6emJuMTVIbHhUTllKVHJo?= =?utf-8?B?NE1vSDNaWU0wNGRRM0RPNklYcCthUnE3dGlac2tzMnlYZUdWeWNPY0xBMTFm?= =?utf-8?B?VmxGM0F3OEoybXBnL1R0NlRyTUNvQ3k5Wm51VFh0RTlRenEzd2luZFN4WStt?= =?utf-8?B?cFZ0WkxhUmdMTXpnVzNLenZmUWZZakxqNG1YT3pWcXdVQ3dyd0lEN0ZMelF0?= =?utf-8?B?anRBRnJPcHpWblBJb2hva0xXbC9Tb3ovbzJYTHczaXBneXFJc2lNUk1CMC9n?= =?utf-8?B?M1czSU9STm9zSllpbUdwVlVIQVloVkpsbmxJSGhqUHpzcGJzaFMrQ2VtTVR5?= =?utf-8?B?Z1JKai9xMGxXTFdmWEZoVTlhejdMcythWmdtNERHYVp2a3oyYUVoUEwvWTFh?= =?utf-8?B?Rko0VTJsSjJCdGdnaG1xeFFtL2NZb25ON1pyOG80dmJEcXNyZmlQbG9PdGhx?= =?utf-8?Q?baLjhTvpf5W/?= X-Microsoft-Exchange-Diagnostics: 1; CO1PR01MB256; 6:YlSi1hhAhK63pCm93JUOCpzU2VSb4RfTyhWDN/rICGilu1DEB/duEAz8R6aZy60/PBjcO65lhSv/WvRgt6cHluK3xTxnLCkkW94sAwHltfOWjhqSjMxmw4k214xTWkixJvJquR0fJBUdAJXBkTQiw3VEPh/rXrdQFwoDT9XMT+u68DCoPlpZkEuNv20JCcbA2XRjlR4Zu5Q+53r3Er4hkNui1YZzdb5qSEAdRUnr98H5npmZkCyUAQ14Xbc0CTyiAhYDuqd73yx16BA3x7qgjQh3LYM/nSbs8b9ySuEndjc=; 5:sPmQVX7/llZChQb0hsPRvaP1HKnTqTkdcx2mVDg7Mqo4VWe/LVWdrcxpiS4mLXqvRioJVh7PEo9mMdAd4qY0qPHTOAOeBEyt0EXgNLk/gF99UwB4ZC/2lgsN9ZSuKXVN8tTsEZCqtuyN5bFEpuqMQA==; 24:XVOb7ER5VssG5asyHW32POejY8SP+NGa8Lp/RUI9qyheZSlZwjLl8uLANGbsitTiuM5OBKftF6+OwV6w7+HsmWcjH/I58/6laFp7znz0Il4=; 7:HQBUxZ5Gtr6jiZl6snSI954Pc0MElkFsy349FUpDStZfbU+CzVl70V/Gk/ShTawLeZ4YcG25OBarwHU0qcUzPcDQSNTb5vxj2tDZQZQ0D8vv4Vx+Chxs0AYXTvL7fflz8yX+TQBWGu3hyN0BsbKs6Orb2wKCCJmsWp2F8NdxARzsJDnvRP+5JD34z/o31mI8MHKOWbScEk+sOTAqWBYRrEIj7gBy1mft70VvbBl/JmfncGMozGqc1N/I1UC7+fPX SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO1PR01MB256; 20:nanCzJ0GcYwvOQiaCf/3TUxMdtT43758r0DqgavsjJL0FNnDcJ/lMPdhEhEGNp7l4C9A1CYIYqL5FUK1Pn7PAEtkDofvX1J8HEbGDw4+L2XAgqoAepMkGNcOwJNdHef2WfnhUWyMdSVPEKuhzhNYnUXcMXGPRveBvDBMII0qWKY= X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Aug 2016 14:02:02.3346 (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: CO1PR01MB256 Archived-At: Cc: John Bradley , IETF Tokbind WG , Subodh Iyengar , Nick Harper , Brian Campbell Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 08 Aug 2016 14:02:06 -0000 PiBUaGF0IG1lYW5zIHRoYXQgb25seSB0aGUgb3JpZ2luIHRoYXQgZ2VuZXJhdGVzIHRoZSBib3Vu ZCBjb29raWUgY2FuDQo+IHZhbGlkYXRlIGl0LCBidXQgSSdtIGhhdmluZyB0cm91YmxlIGlkZW50 aWZ5aW5nIGNhc2VzIHdoZXJlIHRoaXMgd291bGQNCj4gYmUgYW55dGhpbmcgd29yc2UgdGhhbiBt ZXJlbHkgaW5jb252ZW5pZW50IGZvciBzZXJ2ZXJzIHRvIHVzZS4NCg0KV2hpbGUgSSBmYXZvciB0 aGlzIHByb3Bvc2FsLCBJIGNhbid0IHNheSB0aGF0IEkgaGF2ZSB0aGUgZnVsbCByYW5nZSBvZiB1 c2UgY2FzZXMgaW4gbWluZCBzaW5jZSBJJ20gY29taW5nIHRvIHRoZSBjb252ZXJzYXRpb24gbGF0 ZS4gTXkgY29uY2VybnMgYWJvdXQgdGhlIHNoYXJpbmcgb2YgYmluZGluZ3Mgd2VyZSBtb3N0bHkg bW90aXZhdGVkIGJ5IGNvbmZ1c2lvbi9icmFpbi1mcmVlemUgb24gbXkgcGFydCwgc28gaXQncyBu b3doZXJlIG5lYXIgYXMgYmFkIGFzIEkgd2FzIGVudmlzaW9uaW5nLg0KDQpNeSBndWVzcyBpcyB0 aGF0IG9uZSBjb21tb24gc2NlbmFyaW8gdGhpcyB3b3VsZCBibG9jayBpcyB0aGUgdXNlIG9mIGJv dW5kIGRvbWFpbiBjb29raWVzIHRvIGltcGxlbWVudCBpbnRyYS1lbnRlcnByaXNlIFNTTywgd2hp Y2ggKG1pbnVzIHRoZSB0b2tlbiBiaW5kaW5nKSBpcy93YXMgYSBmYWlybHkgY29tbW9uIHByYWN0 aWNlIGJlZm9yZSB0aGUgcmlzZSBvZiByZWFsIGZlZGVyYXRpb24gc3RhbmRhcmRzLCBhbmQgaXMg c3RpbGwgc3VwcG9ydGVkIHRvZGF5IGJ5IHNvbWUgY29tbWVyY2lhbCBhbmQgb3BlbiBzb3VyY2Ug U1NPIHNvZnR3YXJlLg0KDQpJIGRvIHRoaW5rIGl0IHdvdWxkIGJlIHVuZm9ydHVuYXRlIGlmIHRo ZXJlIHdlcmVuJ3QgYSAqd2F5KiB0byBsaW1pdCB0aGlzLCBldmVuIGlmIGl0IHdlcmUgYWN0dWFs bHkgc3RpbGwgYWxsb3dlZC4gSXQncyBvbmUgdGhpbmcgdG8gc2F5IHlvdSBjYW4gc2hhcmUgdGhl bSwgYnV0IGl0J3MgYW5vdGhlciB0byBzYXkgeW91IG11c3QuDQoNCi0tIFNjb3R0DQoNCg== From nobody Mon Aug 8 08:35:23 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 991FC12B01B for ; Mon, 8 Aug 2016 08:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, 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 bEVAllgEHF0o for ; Mon, 8 Aug 2016 08:35:20 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 E9DEB127077 for ; Mon, 8 Aug 2016 08:35:19 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 35so258693412uap.1 for ; Mon, 08 Aug 2016 08:35:19 -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=uIyFzWsTXH6EGPNR3Cin556865xEwyER8HaQRKK+Mmg=; b=Jkn3iWPLu+k9KC48WyLMW6lRAmdmsRGsi3Fpwpw8/yLUmj20Ka8VCOAjludwk7tida akMuIuUdbDvbElttYVaGGtKy2gxJFOtFCMrBqXPoAIHghqypfhTyNWRp1dRXpOULkdp8 18HZMoYouNlLPhw6VUSpCyLkCzfzHFLsLcXXOSM9h9LScZmX6ykbNY5NGaCoE8qnOnjw 6T0EYarLcpgM2pW6IgBM3ZLEW78ROOtNQ6+mXYmpxE6NwzMzQLEql5y4G9XYSK+OszZs CWSGXY4XXbycTVYG+qs0OLwaQEf8Ioyc7k8Rj4JLZfpUJ+/ttNEPY8QRHnlntXItj/Rf mv2A== 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=uIyFzWsTXH6EGPNR3Cin556865xEwyER8HaQRKK+Mmg=; b=dTvLbbn65qHMYVTDqA6wX1sCip7IPTGGzq0LcvGRyJAy0mC+eTNJHDCiklNPrblhwT DDthq6bU51OSU9bX8Yrn+bCq9bFa+rvbOKovvuE1X7IYNwlW9ZyeDTVX2Twxl0tYPU7W J0jtoCWiMv356qNs6hBWfkIYmZ+ltefihNJGpyslvnGAE0G7rvUyTKXjjEJIZcKnAMdj nPTMytMf5O/2Dumy2Gusa4rwlsOzHTi+bc26sOmdozMkTW70s2ngpEIZ3UvpoSdnqfaD XpjRbKt44i9dnp+QUHOIUlqrK4Ay6VZXHDxjCVyJeXM6+9noFcdZMUxWhb8RgQtf9F3e dXFQ== X-Gm-Message-State: AEkoout2JZGQZEH5xSuyGVH3g6Rz68G0c1gPX2De0zCvvd06aLXBWPF3RHfLKB8XO+sVE3kuDREN9pGHed1ms3OV X-Received: by 10.31.108.27 with SMTP id h27mr7360300vkc.46.1470670518657; Mon, 08 Aug 2016 08:35:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.97.2 with HTTP; Mon, 8 Aug 2016 08:35:18 -0700 (PDT) In-Reply-To: References: From: Bill Cox Date: Mon, 8 Aug 2016 08:35:18 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114794d8d90103053991290a Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] TLS extension: version field 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, 08 Aug 2016 15:35:21 -0000 --001a114794d8d90103053991290a Content-Type: text/plain; charset=UTF-8 On Sun, Aug 7, 2016 at 11:50 PM, Martin Thomson wrote: > This is getting a lot of use recently: > > https://www.imperialviolet.org/2016/05/16/agility.html > > Specifically: "concentrate all extensibility in a single place and > actively defend it". > > The version field in the TLS extension is a great example of exactly > the sort of field we should avoid on these grounds. Why can't we just > use a new extension when it comes time to replace this protocol with > version 2? > Wouldn't that break version negotiation? If the server supports only version 1, and the client offers only version 2, is it possible to agree on version 1? We're using the major version as 0 for testing, and the minor version is the version of the TB specification supported. I currently reject all TB connections below (0, 8), and this seems to be working well. Given the recent changes in the spec, the version numbers are quite helpful. When we support the 1.0 version, I plan to start rejecting 0 as the major version. Maybe there is a better way to do this, but I'd prefer to keep the version numbers for now. Bill --001a114794d8d90103053991290a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Aug 7, 2016 at 11:50 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
This is gettin= g a lot of use recently:

=C2=A0 https://www.imperialviolet.org/201= 6/05/16/agility.html

Specifically: "concentrate all extensibility in a single place and
actively defend it".

The version field in the TLS extension is a great example of exactly
the sort of field we should avoid on these grounds.=C2=A0 Why can't we = just
use a new extension when it comes time to replace this protocol with
version 2?

Wouldn't that break vers= ion negotiation?=C2=A0 If the server supports only version 1, and the clien= t offers only version 2, is it possible to agree on version 1?
We're using the major version as 0 for testing, and the mi= nor version is the version of the TB specification supported.=C2=A0 I curre= ntly reject all TB connections below (0, 8), and this seems to be working w= ell.=C2=A0 Given the recent changes in the spec, the version numbers are qu= ite helpful.=C2=A0 When we support the 1.0 version, I plan to start rejecti= ng 0 as the major version.

Maybe there is a better= way to do this, but I'd prefer to keep the version numbers for now.

Bill
--001a114794d8d90103053991290a-- From nobody Mon Aug 8 09:10:08 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 A664E12D0AC for ; Mon, 8 Aug 2016 09:10:06 -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 q1suM0jvmejJ for ; Mon, 8 Aug 2016 09:10:05 -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 F194E12B01B for ; Mon, 8 Aug 2016 09:10:04 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id m101so361639776ioi.2 for ; Mon, 08 Aug 2016 09:10:04 -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=mIkUO4jigUrjV4xDEL3NAVi4e9RcZOpW4MyJXFhKsao=; b=LKnYHHNMZqdg2h4/6AXaKEJMB9l4kS4tz/PcBB21fDZxc2D8zuOkArEg/svFbZGGSL z8fnU87L8oml+MB3rOfVQTDOtJA/KUu+pIk6UwkBDN4p847lrTI5dEUWqGRRb6NYrqBW yvZO1F6v+aFF/fxswYOFJpcjZt1qKulnMTk7Q= 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=mIkUO4jigUrjV4xDEL3NAVi4e9RcZOpW4MyJXFhKsao=; b=EU1XiPGCtDYgO3OsHjYc8hR5yEgFL6Ab9WjM9bQUz47mVInYcQEgNCO7bRGhp+2S+y wO+8tx2h/ZjJHVUzSQfeZCfWJMO2ovEu05Vv0IAvcvBEiTs0r7hnY6RS/vu3nwt3XQtr jQDWBFFHZyc0vs+ZJyWNDfFqguw93UfrR0R0U4JdQFEzfbpGsN+xea+Rs1OYd6CGcmhu O6Uvo3HxgssRZH7FCSNkE4Qu7A5uIiA+ar2YmZZv7Ezj4LmWWfJ8YFNAG0RtcdqoKq4i j0TLccwFLnDOZploKKVgK70N0onp1qn4Oil8ZpRyL3z9H5MJlAIgezbadW4EcBKt8jik U+jw== X-Gm-Message-State: AEkoouvmtGwM2pogsuoCOl6FvDhz3SJzaeUhyT8z36/23B5QchvJXiqH7zJrF9ImqFkEHZxnL2R3mLz52KmCeiPy X-Received: by 10.107.50.19 with SMTP id y19mr90874338ioy.174.1470672598125; Mon, 08 Aug 2016 09:09:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Mon, 8 Aug 2016 09:09:27 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Mon, 8 Aug 2016 10:09:27 -0600 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114469c4e3e1b5053991a548 Archived-At: Cc: Andrei Popov , IETF Tokbind WG Subject: Re: [Unbearable] referred token binding and unknown key_parameters 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, 08 Aug 2016 16:10:07 -0000 --001a114469c4e3e1b5053991a548 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable With #61 , Martin beat me to opening an issue. Adding the two extra bytes is unfortunate but will save some pain down the road so is worth it, I think. Given the static size nature ecdsap256, we could reclaim one of those bytes for that ID by using fixed-length vector(s) to define what's in TokenBindingID_data for that type. Something like: struct { opaque x [32]; opaque y [32]; } ECTokenBindingID_data; or struct { opaque point [64]; } ECTokenBindingID_data; Just a thought anyway. Don't know if that's better or worse or worth doing for one byte. On Mon, Aug 8, 2016 at 1:53 AM, Martin Thomson wrote: > On 8 August 2016 at 03:15, Andrei Popov > wrote: > > Do you mind opening a GitHub issue, so that we don=E2=80=99t forget abo= ut this? > > I independently opened #61. > > (Apologies to Andrei and Brian, but gmail has decided that all > microsoft.com and pingidentity.com email on lists are spam. I missed > these emails.) > --001a114469c4e3e1b5053991a548 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
With #61, Martin beat= me to opening an issue.

Adding the two extra bytes is unfortunate = but will save some pain down the road so is worth it, I think.

Given the static size nature ecdsap256, we could reclaim one of those byt= es for that ID by using fixed-length vector(s) to define what's in Toke= nBindingID_data for that type. Something like:

=C2=A0 struct {
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 opaque x [32];
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 opaque y [32];
=C2=A0 } ECT= okenBindingID_data;

or

=C2=A0 struct {
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 opaque point [64];
=C2=A0 } ECToken= BindingID_data;

Just a thought anyway. Don't know if that&= #39;s better or worse or worth doing for one byte.
=


On Mon, Aug 8, 2016 at 1:53 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 8 August 2016 at 03:15, Andrei Popov <Andrei.Popov@microsoft.com> = wrote:
> Do you mind opening a GitHub issue, so that we don=E2=80=99t forget ab= out this?

I independently opened #61.

(Apologies to Andrei and Brian, but gmail has decided that all
micro= soft.com and pingidentity.com email on lists are spam.=C2=A0 I missed=
these emails.)

--001a114469c4e3e1b5053991a548-- From nobody Mon Aug 8 10:52:35 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 7B1D612D87D for ; Mon, 8 Aug 2016 10:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, 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 CyMPDa4XsBhv for ; Mon, 8 Aug 2016 10:52:31 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 E06C212D883 for ; Mon, 8 Aug 2016 10:52:28 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id 35so264996966uap.1 for ; Mon, 08 Aug 2016 10:52:28 -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=pNBggHwgDcZa4ON3qYsup/Rgii9vGyVMu+/TpjOQ3Y4=; b=JiVgeRwx4OPhbbMnJHGcwP2rvLBRj9Z04EDmKNy2fF35pMqRTjcq4W0bgC4uWpPQ9J qOuJMIo4BAPIpZ56H0LE+2sFsG1W9on0ckF1wFTohCxfSItbI3YRdvni7Wr/L281JM6r DxSV1HAzscpBlh20cAXKPCt1f4bTg3IKl3ZVCyFqpLNqTJ7gqmJVoWo2mGQrun/9YMTb wmS0W1MGKHzAqy+smOFrgReo3TuP65VzyElzFlfHKZOlr3EgtYGFomO8Es5IVWOHywss kndPEVVzf6zClNYhG9ZGX1q2hYugotbPkpDbZs3TXbgwu5Q5cSiZXSMPI7V0/FZxiLIb VAZQ== 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=pNBggHwgDcZa4ON3qYsup/Rgii9vGyVMu+/TpjOQ3Y4=; b=YH1/C+Kj/FGr8d5IJKFiEBzGYrZM9Q3+r92wMKBGS92ALtN236BEweKgxME+e5XDTn sDHS4+TvnFAi+RjQ7umRZXqoipS7nnYIezNnjfdYRNXFvcBYf7/73obJL9WHzAOi7ysl uRlWeGly9j6UHD4Nw2xfIUzVRUiYAxKe36oTmuZMSgdBLQCpoxZZQ3XikXwxfGWzixDd W+qhzG7OicqKjGquqGcmshqzjXIuBxBQPNOFmHogbqsm2KY/LIWzN6pYWbCcfMBliYVy aNPrpGyZ5dwlboCp3jaZVRpj4wMGW//3HP985qy0ZvPo4LhnZ6fekP4eSzQBLDS76R2b y3Wg== X-Gm-Message-State: AEkoousgL+StRuP7JuGpkwl9/97lOsAf0vYv7/OedcWFiTyBVzw9ULkfxiKd4VYuTJCgOBfmxMs+xqoP/CnZ6WQV X-Received: by 10.159.36.15 with SMTP id 15mr40458125uaq.79.1470678747747; Mon, 08 Aug 2016 10:52:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.209 with HTTP; Mon, 8 Aug 2016 10:52:07 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Mon, 8 Aug 2016 10:52:07 -0700 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a113cd58656fa820539931433 Archived-At: Cc: "unbearable@ietf.org" , Martin Thomson Subject: Re: [Unbearable] TLS extension: version field 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, 08 Aug 2016 17:52:33 -0000 --001a113cd58656fa820539931433 Content-Type: text/plain; charset=UTF-8 I generally agree with Martin that the version field isn't needed and a new TLS extension can be used when it's time for protocol version 2. Version negotiation wouldn't be broken by this. A client would offer whichever extensions it supports (so if it supports 1 and 2, it would send the extensions for 1 and 2). This would have better version negotiation properties than the existing mechanism. Under the new mechanism (separate extension for versions 1 and 2), if a server sends an extension for either version, it knows that the client supports that version. Right now, a client could send version 2 in its extension, the server respond with version 1, and end up with token binding not being negotiated because the client doesn't support version 1 (but the server not knowing that until it fails to receive a TokenBindingMessage). Using the version number for draft versions has been useful for testing, but we could easily use other mechanisms, like use a different (unassigned) TLS extension number for each draft version, or send an extra extension indicating the token binding extension version (like the TLS 1.3 draft version extension). On Mon, Aug 8, 2016 at 8:35 AM, Bill Cox wrote: > On Sun, Aug 7, 2016 at 11:50 PM, Martin Thomson > wrote: > >> This is getting a lot of use recently: >> >> https://www.imperialviolet.org/2016/05/16/agility.html >> >> Specifically: "concentrate all extensibility in a single place and >> actively defend it". >> >> The version field in the TLS extension is a great example of exactly >> the sort of field we should avoid on these grounds. Why can't we just >> use a new extension when it comes time to replace this protocol with >> version 2? >> > > Wouldn't that break version negotiation? If the server supports only > version 1, and the client offers only version 2, is it possible to agree on > version 1? > > We're using the major version as 0 for testing, and the minor version is > the version of the TB specification supported. I currently reject all TB > connections below (0, 8), and this seems to be working well. Given the > recent changes in the spec, the version numbers are quite helpful. When we > support the 1.0 version, I plan to start rejecting 0 as the major version. > > Maybe there is a better way to do this, but I'd prefer to keep the version > numbers for now. > > Bill > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a113cd58656fa820539931433 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I generally agree with Martin that the version field isn&#= 39;t needed and a new TLS extension can be used when it's time for prot= ocol version 2.

Version negotiation wouldn't be brok= en by this. A client would offer whichever extensions it supports (so if it= supports 1 and 2, it would send the extensions for 1 and 2). This would ha= ve better version negotiation properties than the existing mechanism. Under= the new mechanism (separate extension for versions 1 and 2), if a server s= ends an extension for either version, it knows that the client supports tha= t version. Right now, a client could send version 2 in its extension, the s= erver respond with version 1, and end up with token binding not being negot= iated because the client doesn't support version 1 (but the server not = knowing that until it fails to receive a TokenBindingMessage).
Using the version number for draft versions has been useful fo= r testing, but we could easily use other mechanisms, like use a different (= unassigned) TLS extension number for each draft version, or send an extra e= xtension indicating the token binding extension version (like the TLS 1.3 d= raft version extension).

On Mon, Aug 8, 2016 at 8:35 AM, Bill Cox <waywardg= eek@google.com> wrote:
On Sun, Aug 7, 2016 at 11:50 PM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
Thi= s is getting a lot of use recently:

=C2=A0 https://www.imperialviolet.org/201= 6/05/16/agility.html

Specifically: "concentrate all extensibility in a single place and
actively defend it".

The version field in the TLS extension is a great example of exactly
the sort of field we should avoid on these grounds.=C2=A0 Why can't we = just
use a new extension when it comes time to replace this protocol with
version 2?

Wouldn't that bre= ak version negotiation?=C2=A0 If the server supports only version 1, and th= e client offers only version 2, is it possible to agree on version 1?
=

We're using the major version as 0 for testing, and= the minor version is the version of the TB specification supported.=C2=A0 = I currently reject all TB connections below (0, 8), and this seems to be wo= rking well.=C2=A0 Given the recent changes in the spec, the version numbers= are quite helpful.=C2=A0 When we support the 1.0 version, I plan to start = rejecting 0 as the major version.

Maybe there is a= better way to do this, but I'd prefer to keep the version numbers for = now.
=

Bill

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


--001a113cd58656fa820539931433-- From nobody Mon Aug 8 11:05: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 1DC1212D677 for ; Mon, 8 Aug 2016 11:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 DVC--vv5nFbQ for ; Mon, 8 Aug 2016 11:05:27 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0113.outbound.protection.outlook.com [104.47.42.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021DC12D0E5 for ; Mon, 8 Aug 2016 11:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zXlywAt97M9RHM6sNsA1yJEm8fvVGzrvTBSDn5cwneo=; b=bGQK5RutoQBdl5LVmm6kAP9o8cP+PUzOJovvw8h54L8JdgKJwB5O5YbV80ZzhFCmUGgTjcE6A9hoP/JWSSBQzsRz6GuGaSBxyZiOT5Ly4Nghi1InWHKFiSDwpez5Myk+KxePYwkVfuU/rGrSguWJLZh9KkZkGcVozJW20dKqGuk= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2154.namprd03.prod.outlook.com (10.166.206.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 8 Aug 2016 18:05:24 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0549.025; Mon, 8 Aug 2016 18:05:24 +0000 From: Andrei Popov To: Nick Harper , Bill Cox Thread-Topic: [Unbearable] TLS extension: version field Thread-Index: AQHR8UE0hAr3fGh5LkSos3djbwbcUaA/MmwAgAAmOoCAAAGk8A== Date: Mon, 8 Aug 2016 18:05:23 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:1::2d7] x-ms-office365-filtering-correlation-id: 7ab7229f-2628-46b1-fa09-08d3bfb691f2 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2154; 6:oeO9QUrifrVpkVgZDZEJMCNxMb6Cy+Ytgzw8rowhGQx4eAFmIgwD5aojTe/o7W97SRIVj4PoAhLPKsB3JO2+nGe5zi7JBsjLigK67bT9+sqzRpW2JgiEPtRbDzwGTOj13SS5Fzq2ZgaOWLcJvkbBbPIVI2ZkUSqzywwdNYE8zbL/U9Va7keQ1ebCafjlUa8kn5E3vVoNFfYcd5yWs5+MLrkemH5s0gmP4V+8/UjgP9hQLTSWTnxLs44w9RVPn3VZ64TtWtJbIX6FhMnKkMVmshpmzhfZSD4EDclzeIiHpwIACsupWs1qszkzQabmvh3kppBdJepp5FP5c3T/mBlDOw==; 5:pIynXdfm3fO97TV9UKXjf/ll3WK+dZkQCby0brXBnKiu+qG3/35HLq9pM0w5u6ZFJjuzRcfcW/NOV208f0GxXUTXYYknVkvNCsPFc7uIMjiLZyG56hs7M5rQ68RzG7O786rMIP6jCBigq1riX2HmbA==; 24:hwqhchggN8wRaEHLDzh5J6ho2Vt4wZlVMwgZ9biaXUymHaaB8o3QGp0nzCc1fRNd9iKEv49AkvLGoxjwJTYrL2yVfkn9awRbm2QYAv/FiBk=; 7:vWvaRSTTJy0U/eop/tuKPmYSvg8piEjZm77/GwGBr6sjKNbUcbEboRpIFUfB4j9Lf5fVJ4o2+at9zF13/T//kVG+lc0aFBRdYKFXvhFe5c1B7sRKeTZ9KEuTx9koFhP+88kUo3OOltGnf4koJp9FX+uHXuw2NdL8ps05q9ftjsaGwLbqkupM/CndBHYPGV6qd8raf8G4ErmoT64D6Vw7IC4lIm//U0cWdINC+NYMY+p/bwTnxIlnuujfVNtRfkNK x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2154; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(788757137089)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2154; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2154; x-forefront-prvs: 00286C0CA6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(24454002)(377454003)(199003)(189998001)(7906003)(97736004)(10090500001)(7696003)(7846002)(7736002)(5001770100001)(8990500004)(19609705001)(122556002)(19580405001)(19580395003)(92566002)(86362001)(10290500002)(10400500002)(74316002)(87936001)(3660700001)(3280700002)(77096005)(15975445007)(2950100001)(86612001)(76576001)(5005710100001)(102836003)(790700001)(6116002)(2900100001)(4326007)(2906002)(9686002)(54356999)(105586002)(99286002)(16236675004)(19625215002)(19300405004)(11100500001)(101416001)(19617315012)(8676002)(76176999)(50986999)(81166006)(106356001)(106116001)(586003)(8936002)(5002640100001)(81156014)(68736007)(33656002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2154; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB2155810C4F001A466CEAB6B08C1B0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2016 18:05:23.9832 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2154 Archived-At: Cc: "unbearable@ietf.org" , Martin Thomson Subject: Re: [Unbearable] TLS extension: version field 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, 08 Aug 2016 18:05:29 -0000 --_000_CY1PR03MB2155810C4F001A466CEAB6B08C1B0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHVzZSBvZiBzZXBhcmF0ZSBUTFMgZXh0ZW5zaW9ucyBmb3IgZWFjaCBUQiB2ZXJzaW9uIGhh cyBhIGNvdXBsZSBvZiB1bmRlc2lyYWJsZSBwcm9wZXJ0aWVzOg0KDQoxLiAgICAgIEl04oCZcyB3 YXN0ZWZ1bCBvbiB0aGUgd2lyZTogb25lIHdvdWxkIGJlIGR1cGxpY2F0aW5nIFRMUyBleHRlbnNp b24gYnl0ZXMgYW5kIGxpc3RzIG9mIFRCIGtleSBwYXJhbWV0ZXJzLiBBbmQgdGhpcyBpcyBpbiB0 aGUgQ2xpZW50SGVsbG8sIHdoZXJlIHdlIGNhcmUgYWJvdXQgc2l6ZS4NCg0KMi4gICAgICBFdmVy eSB0aW1lIHdlIGNvbWUgdXAgd2l0aCBhIG5ldyBUQiB2ZXJzaW9uLCB3ZSBuZWVkIHRvIHNwZWNp ZnkgYSBuZXcgVExTIGV4dGVuc2lvbiB3aXRoIGl0cyBJQU5BIG51bWJlciwgZXRjLg0KDQpDaGVl cnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJsZS1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTmljayBIYXJwZXINClNlbnQ6IE1vbmRheSwgQXVn dXN0IDgsIDIwMTYgMTA6NTIgQU0NClRvOiBCaWxsIENveCA8d2F5d2FyZGdlZWtAZ29vZ2xlLmNv bT4NCkNjOiB1bmJlYXJhYmxlQGlldGYub3JnOyBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21z b25AZ21haWwuY29tPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBUTFMgZXh0ZW5zaW9uOiB2 ZXJzaW9uIGZpZWxkDQoNCkkgZ2VuZXJhbGx5IGFncmVlIHdpdGggTWFydGluIHRoYXQgdGhlIHZl cnNpb24gZmllbGQgaXNuJ3QgbmVlZGVkIGFuZCBhIG5ldyBUTFMgZXh0ZW5zaW9uIGNhbiBiZSB1 c2VkIHdoZW4gaXQncyB0aW1lIGZvciBwcm90b2NvbCB2ZXJzaW9uIDIuDQoNClZlcnNpb24gbmVn b3RpYXRpb24gd291bGRuJ3QgYmUgYnJva2VuIGJ5IHRoaXMuIEEgY2xpZW50IHdvdWxkIG9mZmVy IHdoaWNoZXZlciBleHRlbnNpb25zIGl0IHN1cHBvcnRzIChzbyBpZiBpdCBzdXBwb3J0cyAxIGFu ZCAyLCBpdCB3b3VsZCBzZW5kIHRoZSBleHRlbnNpb25zIGZvciAxIGFuZCAyKS4gVGhpcyB3b3Vs ZCBoYXZlIGJldHRlciB2ZXJzaW9uIG5lZ290aWF0aW9uIHByb3BlcnRpZXMgdGhhbiB0aGUgZXhp c3RpbmcgbWVjaGFuaXNtLiBVbmRlciB0aGUgbmV3IG1lY2hhbmlzbSAoc2VwYXJhdGUgZXh0ZW5z aW9uIGZvciB2ZXJzaW9ucyAxIGFuZCAyKSwgaWYgYSBzZXJ2ZXIgc2VuZHMgYW4gZXh0ZW5zaW9u IGZvciBlaXRoZXIgdmVyc2lvbiwgaXQga25vd3MgdGhhdCB0aGUgY2xpZW50IHN1cHBvcnRzIHRo YXQgdmVyc2lvbi4gUmlnaHQgbm93LCBhIGNsaWVudCBjb3VsZCBzZW5kIHZlcnNpb24gMiBpbiBp dHMgZXh0ZW5zaW9uLCB0aGUgc2VydmVyIHJlc3BvbmQgd2l0aCB2ZXJzaW9uIDEsIGFuZCBlbmQg dXAgd2l0aCB0b2tlbiBiaW5kaW5nIG5vdCBiZWluZyBuZWdvdGlhdGVkIGJlY2F1c2UgdGhlIGNs aWVudCBkb2Vzbid0IHN1cHBvcnQgdmVyc2lvbiAxIChidXQgdGhlIHNlcnZlciBub3Qga25vd2lu ZyB0aGF0IHVudGlsIGl0IGZhaWxzIHRvIHJlY2VpdmUgYSBUb2tlbkJpbmRpbmdNZXNzYWdlKS4N Cg0KVXNpbmcgdGhlIHZlcnNpb24gbnVtYmVyIGZvciBkcmFmdCB2ZXJzaW9ucyBoYXMgYmVlbiB1 c2VmdWwgZm9yIHRlc3RpbmcsIGJ1dCB3ZSBjb3VsZCBlYXNpbHkgdXNlIG90aGVyIG1lY2hhbmlz bXMsIGxpa2UgdXNlIGEgZGlmZmVyZW50ICh1bmFzc2lnbmVkKSBUTFMgZXh0ZW5zaW9uIG51bWJl ciBmb3IgZWFjaCBkcmFmdCB2ZXJzaW9uLCBvciBzZW5kIGFuIGV4dHJhIGV4dGVuc2lvbiBpbmRp Y2F0aW5nIHRoZSB0b2tlbiBiaW5kaW5nIGV4dGVuc2lvbiB2ZXJzaW9uIChsaWtlIHRoZSBUTFMg MS4zIGRyYWZ0IHZlcnNpb24gZXh0ZW5zaW9uKS4NCg0KT24gTW9uLCBBdWcgOCwgMjAxNiBhdCA4 OjM1IEFNLCBCaWxsIENveCA8d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTxtYWlsdG86d2F5d2FyZGdl ZWtAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KT24gU3VuLCBBdWcgNywgMjAxNiBhdCAxMTo1MCBQTSwg TWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRo b21zb25AZ21haWwuY29tPj4gd3JvdGU6DQpUaGlzIGlzIGdldHRpbmcgYSBsb3Qgb2YgdXNlIHJl Y2VudGx5Og0KDQogIGh0dHBzOi8vd3d3LmltcGVyaWFsdmlvbGV0Lm9yZy8yMDE2LzA1LzE2L2Fn aWxpdHkuaHRtbA0KDQpTcGVjaWZpY2FsbHk6ICJjb25jZW50cmF0ZSBhbGwgZXh0ZW5zaWJpbGl0 eSBpbiBhIHNpbmdsZSBwbGFjZSBhbmQNCmFjdGl2ZWx5IGRlZmVuZCBpdCIuDQoNClRoZSB2ZXJz aW9uIGZpZWxkIGluIHRoZSBUTFMgZXh0ZW5zaW9uIGlzIGEgZ3JlYXQgZXhhbXBsZSBvZiBleGFj dGx5DQp0aGUgc29ydCBvZiBmaWVsZCB3ZSBzaG91bGQgYXZvaWQgb24gdGhlc2UgZ3JvdW5kcy4g IFdoeSBjYW4ndCB3ZSBqdXN0DQp1c2UgYSBuZXcgZXh0ZW5zaW9uIHdoZW4gaXQgY29tZXMgdGlt ZSB0byByZXBsYWNlIHRoaXMgcHJvdG9jb2wgd2l0aA0KdmVyc2lvbiAyPw0KDQpXb3VsZG4ndCB0 aGF0IGJyZWFrIHZlcnNpb24gbmVnb3RpYXRpb24/ICBJZiB0aGUgc2VydmVyIHN1cHBvcnRzIG9u bHkgdmVyc2lvbiAxLCBhbmQgdGhlIGNsaWVudCBvZmZlcnMgb25seSB2ZXJzaW9uIDIsIGlzIGl0 IHBvc3NpYmxlIHRvIGFncmVlIG9uIHZlcnNpb24gMT8NCg0KV2UncmUgdXNpbmcgdGhlIG1ham9y IHZlcnNpb24gYXMgMCBmb3IgdGVzdGluZywgYW5kIHRoZSBtaW5vciB2ZXJzaW9uIGlzIHRoZSB2 ZXJzaW9uIG9mIHRoZSBUQiBzcGVjaWZpY2F0aW9uIHN1cHBvcnRlZC4gIEkgY3VycmVudGx5IHJl amVjdCBhbGwgVEIgY29ubmVjdGlvbnMgYmVsb3cgKDAsIDgpLCBhbmQgdGhpcyBzZWVtcyB0byBi ZSB3b3JraW5nIHdlbGwuICBHaXZlbiB0aGUgcmVjZW50IGNoYW5nZXMgaW4gdGhlIHNwZWMsIHRo ZSB2ZXJzaW9uIG51bWJlcnMgYXJlIHF1aXRlIGhlbHBmdWwuICBXaGVuIHdlIHN1cHBvcnQgdGhl IDEuMCB2ZXJzaW9uLCBJIHBsYW4gdG8gc3RhcnQgcmVqZWN0aW5nIDAgYXMgdGhlIG1ham9yIHZl cnNpb24uDQoNCk1heWJlIHRoZXJlIGlzIGEgYmV0dGVyIHdheSB0byBkbyB0aGlzLCBidXQgSSdk IHByZWZlciB0byBrZWVwIHRoZSB2ZXJzaW9uIG51bWJlcnMgZm9yIG5vdy4NCg0KQmlsbA0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVW5iZWFyYWJs ZSBtYWlsaW5nIGxpc3QNClVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOlVuYmVhcmFibGVAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUN Cg0K --_000_CY1PR03MB2155810C4F001A466CEAB6B08C1B0CY1PR03MB2155namp_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgs IGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1w cmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdp bi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28t c3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2lu LXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDow aW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6Njc4MTI0ODYyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRl bXBsYXRlLWlkczoxNzEwMTQzOTIwIDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAz IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGww OmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGlu O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPlRoZSB1c2Ugb2Ygc2VwYXJhdGUgVExTIGV4dGVuc2lvbnMgZm9yIGVh Y2ggVEIgdmVyc2lvbiBoYXMgYSBjb3VwbGUgb2YgdW5kZXNpcmFibGUgcHJvcGVydGllczo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRl eHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5JdOKAmXMgd2FzdGVmdWwgb24gdGhlIHdpcmU6IG9uZSB3b3VsZCBi ZSBkdXBsaWNhdGluZyBUTFMgZXh0ZW5zaW9uIGJ5dGVzIGFuZCBsaXN0cyBvZiBUQiBrZXkgcGFy YW1ldGVycy4gQW5kIHRoaXMgaXMgaW4gdGhlIENsaWVudEhlbGxvLCB3aGVyZSB3ZSBjYXJlIGFi b3V0IHNpemUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RXZlcnkgdGltZSB3ZSBjb21lIHVwIHdpdGgg YSBuZXcgVEIgdmVyc2lvbiwgd2UgbmVlZCB0byBzcGVjaWZ5IGEgbmV3IFRMUyBleHRlbnNpb24g d2l0aCBpdHMgSUFOQSBudW1iZXIsIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbmRyZWk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFVuYmVhcmFibGUgW21haWx0 bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk5pY2sg SGFycGVyPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDgsIDIwMTYgMTA6NTIgQU08 YnI+DQo8Yj5Ubzo8L2I+IEJpbGwgQ294ICZsdDt3YXl3YXJkZ2Vla0Bnb29nbGUuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gdW5iZWFyYWJsZUBpZXRmLm9yZzsgTWFydGluIFRob21zb24gJmx0O21h cnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJl YXJhYmxlXSBUTFMgZXh0ZW5zaW9uOiB2ZXJzaW9uIGZpZWxkPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSBnZW5lcmFsbHkgYWdyZWUgd2l0aCBNYXJ0aW4gdGhhdCB0aGUg dmVyc2lvbiBmaWVsZCBpc24ndCBuZWVkZWQgYW5kIGEgbmV3IFRMUyBleHRlbnNpb24gY2FuIGJl IHVzZWQgd2hlbiBpdCdzIHRpbWUgZm9yIHByb3RvY29sIHZlcnNpb24gMi48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlZlcnNpb24gbmVnb3RpYXRpb24gd291 bGRuJ3QgYmUgYnJva2VuIGJ5IHRoaXMuIEEgY2xpZW50IHdvdWxkIG9mZmVyIHdoaWNoZXZlciBl eHRlbnNpb25zIGl0IHN1cHBvcnRzIChzbyBpZiBpdCBzdXBwb3J0cyAxIGFuZCAyLCBpdCB3b3Vs ZCBzZW5kIHRoZSBleHRlbnNpb25zIGZvciAxIGFuZCAyKS4gVGhpcyB3b3VsZCBoYXZlIGJldHRl ciB2ZXJzaW9uIG5lZ290aWF0aW9uIHByb3BlcnRpZXMgdGhhbiB0aGUNCiBleGlzdGluZyBtZWNo YW5pc20uIFVuZGVyIHRoZSBuZXcgbWVjaGFuaXNtIChzZXBhcmF0ZSBleHRlbnNpb24gZm9yIHZl cnNpb25zIDEgYW5kIDIpLCBpZiBhIHNlcnZlciBzZW5kcyBhbiBleHRlbnNpb24gZm9yIGVpdGhl ciB2ZXJzaW9uLCBpdCBrbm93cyB0aGF0IHRoZSBjbGllbnQgc3VwcG9ydHMgdGhhdCB2ZXJzaW9u LiBSaWdodCBub3csIGEgY2xpZW50IGNvdWxkIHNlbmQgdmVyc2lvbiAyIGluIGl0cyBleHRlbnNp b24sIHRoZSBzZXJ2ZXINCiByZXNwb25kIHdpdGggdmVyc2lvbiAxLCBhbmQgZW5kIHVwIHdpdGgg dG9rZW4gYmluZGluZyBub3QgYmVpbmcgbmVnb3RpYXRlZCBiZWNhdXNlIHRoZSBjbGllbnQgZG9l c24ndCBzdXBwb3J0IHZlcnNpb24gMSAoYnV0IHRoZSBzZXJ2ZXIgbm90IGtub3dpbmcgdGhhdCB1 bnRpbCBpdCBmYWlscyB0byByZWNlaXZlIGEgVG9rZW5CaW5kaW5nTWVzc2FnZSkuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlVzaW5nIHRoZSB2 ZXJzaW9uIG51bWJlciBmb3IgZHJhZnQgdmVyc2lvbnMgaGFzIGJlZW4gdXNlZnVsIGZvciB0ZXN0 aW5nLCBidXQgd2UgY291bGQgZWFzaWx5IHVzZSBvdGhlciBtZWNoYW5pc21zLCBsaWtlIHVzZSBh IGRpZmZlcmVudCAodW5hc3NpZ25lZCkgVExTIGV4dGVuc2lvbiBudW1iZXIgZm9yIGVhY2ggZHJh ZnQgdmVyc2lvbiwgb3Igc2VuZCBhbiBleHRyYSBleHRlbnNpb24gaW5kaWNhdGluZyB0aGUNCiB0 b2tlbiBiaW5kaW5nIGV4dGVuc2lvbiB2ZXJzaW9uIChsaWtlIHRoZSBUTFMgMS4zIGRyYWZ0IHZl cnNpb24gZXh0ZW5zaW9uKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBdWcgOCwgMjAxNiBhdCA4OjM1IEFNLCBCaWxsIENveCAm bHQ7PGEgaHJlZj0ibWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5r Ij53YXl3YXJkZ2Vla0Bnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g U3VuLCBBdWcgNywgMjAxNiBhdCAxMTo1MCBQTSwgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9 Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGdldHRpbmcgYSBsb3Qgb2YgdXNlIHJl Y2VudGx5Ojxicj4NCjxicj4NCiZuYnNwOyA8YSBocmVmPSJodHRwczovL3d3dy5pbXBlcmlhbHZp b2xldC5vcmcvMjAxNi8wNS8xNi9hZ2lsaXR5Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBz Oi8vd3d3LmltcGVyaWFsdmlvbGV0Lm9yZy8yMDE2LzA1LzE2L2FnaWxpdHkuaHRtbDwvYT48YnI+ DQo8YnI+DQpTcGVjaWZpY2FsbHk6ICZxdW90O2NvbmNlbnRyYXRlIGFsbCBleHRlbnNpYmlsaXR5 IGluIGEgc2luZ2xlIHBsYWNlIGFuZDxicj4NCmFjdGl2ZWx5IGRlZmVuZCBpdCZxdW90Oy48YnI+ DQo8YnI+DQpUaGUgdmVyc2lvbiBmaWVsZCBpbiB0aGUgVExTIGV4dGVuc2lvbiBpcyBhIGdyZWF0 IGV4YW1wbGUgb2YgZXhhY3RseTxicj4NCnRoZSBzb3J0IG9mIGZpZWxkIHdlIHNob3VsZCBhdm9p ZCBvbiB0aGVzZSBncm91bmRzLiZuYnNwOyBXaHkgY2FuJ3Qgd2UganVzdDxicj4NCnVzZSBhIG5l dyBleHRlbnNpb24gd2hlbiBpdCBjb21lcyB0aW1lIHRvIHJlcGxhY2UgdGhpcyBwcm90b2NvbCB3 aXRoPGJyPg0KdmVyc2lvbiAyPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V291bGRuJ3QgdGhhdCBicmVhayB2ZXJzaW9uIG5lZ290 aWF0aW9uPyZuYnNwOyBJZiB0aGUgc2VydmVyIHN1cHBvcnRzIG9ubHkgdmVyc2lvbiAxLCBhbmQg dGhlIGNsaWVudCBvZmZlcnMgb25seSB2ZXJzaW9uIDIsIGlzIGl0IHBvc3NpYmxlIHRvIGFncmVl IG9uIHZlcnNpb24gMT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V2UncmUgdXNpbmcgdGhlIG1ham9yIHZlcnNpb24gYXMgMCBmb3IgdGVzdGlu ZywgYW5kIHRoZSBtaW5vciB2ZXJzaW9uIGlzIHRoZSB2ZXJzaW9uIG9mIHRoZSBUQiBzcGVjaWZp Y2F0aW9uIHN1cHBvcnRlZC4mbmJzcDsgSSBjdXJyZW50bHkgcmVqZWN0IGFsbCBUQiBjb25uZWN0 aW9ucyBiZWxvdyAoMCwgOCksIGFuZCB0aGlzIHNlZW1zIHRvIGJlIHdvcmtpbmcgd2VsbC4mbmJz cDsgR2l2ZW4gdGhlIHJlY2VudCBjaGFuZ2VzIGluDQogdGhlIHNwZWMsIHRoZSB2ZXJzaW9uIG51 bWJlcnMgYXJlIHF1aXRlIGhlbHBmdWwuJm5ic3A7IFdoZW4gd2Ugc3VwcG9ydCB0aGUgMS4wIHZl cnNpb24sIEkgcGxhbiB0byBzdGFydCByZWplY3RpbmcgMCBhcyB0aGUgbWFqb3IgdmVyc2lvbi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWF5 YmUgdGhlcmUgaXMgYSBiZXR0ZXIgd2F5IHRvIGRvIHRoaXMsIGJ1dCBJJ2QgcHJlZmVyIHRvIGtl ZXAgdGhlIHZlcnNpb24gbnVtYmVycyBmb3Igbm93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5CaWxsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZyI+VW5iZWFyYWJsZUBpZXRm Lm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3VuYmVhcmFibGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3VuYmVhcmFibGU8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR03MB2155810C4F001A466CEAB6B08C1B0CY1PR03MB2155namp_-- From nobody Mon Aug 8 11:14:23 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 0655912D105 for ; Mon, 8 Aug 2016 11:14:22 -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 gbozKXiUtH-e for ; Mon, 8 Aug 2016 11:14:20 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 A76BE12D1DD for ; Mon, 8 Aug 2016 11:14:19 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id m101so364929075ioi.2 for ; Mon, 08 Aug 2016 11:14:19 -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=3zEKmHV0CzllRgkvJXPsSga4d8d9W0osHxJ1Hh+m5CY=; b=Cxtjb9ayrK49aeRAijIkAozZ33TVKx4Hns7h1QH1+2CWeeq3A3D7entcK7JotodQnW g6nmivCABnq5RNRE4hfzMMSXRQpN85wWMn524EF+9bv4gEnhE3KWoAYdgJSJJmAZdsLe MwHG0RKx9tPF6sBqi3h+BWzJ52eJq8FjEPZaU= 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=3zEKmHV0CzllRgkvJXPsSga4d8d9W0osHxJ1Hh+m5CY=; b=Fwcyd20tAru9UiSRNsZmW++GZwfjdf7i+prUMCYP77qRRXoaFZG4tNn8iANQtynWRP bDoMLOGkPMs0wlWL1oqlrpj61gtU62vo06SwJ9Y+PqVwA0lTc5lBHw3wMd+BKA+4CXV0 PwTeOJcRl/DibQeyKzsHwI/KdQjLsKU9lUMbMf3OXOJuAI13g/BMX+rR1p7wRo5oS8wc o3TpehKBdSLiIbPpiB7tPt1lbNEpO6gER/75QnL7TcXsI9HBp92XG8YgaZUN+TLmuQwl CTMxcrP30g3JU+0+JprvQVlFPYlRPD0sB0TV6gGLx2g3VWcc3l2X9Rz9V+/5qspQBrBZ dfag== X-Gm-Message-State: AEkoous9rUndWxMwIvd94ZWJI3NZfgrPj8BjeaNOaL/TJBWQiKGP3kgzzZUuZm4+PQp4zgTwbhoTEKlVQhtA78ZJ X-Received: by 10.107.50.19 with SMTP id y19mr91565973ioy.174.1470680058698; Mon, 08 Aug 2016 11:14:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Mon, 8 Aug 2016 11:13:48 -0700 (PDT) In-Reply-To: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> From: Brian Campbell Date: Mon, 8 Aug 2016 12:13:48 -0600 Message-ID: To: "Cantor, Scott" Content-Type: multipart/alternative; boundary=001a114469c47ae0c105399362b4 Archived-At: Cc: Subodh Iyengar , Martin Thomson , IETF Tokbind WG , John Bradley , "Manger, James" , Nick Harper Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 08 Aug 2016 18:14:22 -0000 --001a114469c47ae0c105399362b4 Content-Type: text/plain; charset=UTF-8 Even with real federated SSO standards, using domain cookie(s) to track authenticated end-user state is very very common for intra-enterprise SSO and on different sites/services on larger web properties (I presume, anyway, from the many .bigcompany.com cookies I have in my browser). The the eTLD+1 scoping is pragmatic and useful and, with it, Token Binding can improve the security of such deployments. Scoping tighter than that would be much more than merely inconvenient - it would require re-architecture of many intra-domain SSO deployments and/or impede the adoption of Token Binding. On Mon, Aug 8, 2016 at 8:01 AM, Cantor, Scott wrote: > > That means that only the origin that generates the bound cookie can > > validate it, but I'm having trouble identifying cases where this would > > be anything worse than merely inconvenient for servers to use. > > While I favor this proposal, I can't say that I have the full range of use > cases in mind since I'm coming to the conversation late. My concerns about > the sharing of bindings were mostly motivated by confusion/brain-freeze on > my part, so it's nowhere near as bad as I was envisioning. > > My guess is that one common scenario this would block is the use of bound > domain cookies to implement intra-enterprise SSO, which (minus the token > binding) is/was a fairly common practice before the rise of real federation > standards, and is still supported today by some commercial and open source > SSO software. > > I do think it would be unfortunate if there weren't a *way* to limit this, > even if it were actually still allowed. It's one thing to say you can share > them, but it's another to say you must. > > -- Scott > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --001a114469c47ae0c105399362b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Even with real federated SSO standards, using domain cooki= e(s) to track authenticated end-user state is very very common for intra-en= terprise SSO and on different sites/services on larger web properties (I pr= esume, anyway, from the many .bigcompany.com cookies I have in my browser).=C2=A0 The the eTLD= +1 scoping is pragmatic and useful and, with it, Token Binding can improve = the security of such deployments. Scoping tighter than that would be much m= ore than merely inconvenient - it would require re-architecture of many int= ra-domain SSO deployments and/or impede the adoption of Token Binding.=C2= =A0

On = Mon, Aug 8, 2016 at 8:01 AM, Cantor, Scott <cantor.2@osu.edu>= wrote:
> That means = that only the origin that generates the bound cookie can
> validate it, but I'm having trouble identifying cases where this w= ould
> be anything worse than merely inconvenient for servers to use.

While I favor this proposal, I can't say that I have the full ra= nge of use cases in mind since I'm coming to the conversation late. My = concerns about the sharing of bindings were mostly motivated by confusion/b= rain-freeze on my part, so it's nowhere near as bad as I was envisionin= g.

My guess is that one common scenario this would block is the use of bound d= omain cookies to implement intra-enterprise SSO, which (minus the token bin= ding) is/was a fairly common practice before the rise of real federation st= andards, and is still supported today by some commercial and open source SS= O software.

I do think it would be unfortunate if there weren't a *way* to limit th= is, even if it were actually still allowed. It's one thing to say you c= an share them, but it's another to say you must.

-- Scott

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

--001a114469c47ae0c105399362b4-- From nobody Mon Aug 8 11:17: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 D2B6112B013 for ; Mon, 8 Aug 2016 11:17:18 -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 13o8VVE63dmQ for ; Mon, 8 Aug 2016 11:17:16 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0126.outbound.protection.outlook.com [104.47.32.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4E512D1DD for ; Mon, 8 Aug 2016 11:17:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nn88XrTbxoW8PHytI9kMFGzpFJejJior93LG7kcPm6c=; b=fLphpxdPiL3hD7siAtAfDhJgvlVJ5yM3iZsacUmj79jtcod6h5NkXMk0eBfN7314onKX+ZdEWZbcQE9i6mr7XRJRUpQL7e9X1WjGTwQXWypCcwNNqoSbTowAlF/R491KXCjDLOLcy1kiFw9etYJ7n9uNWkXPPZeRl2401hLfDJ4= Received: from DM5PR03MB2441.namprd03.prod.outlook.com (10.168.233.11) by DM5PR03MB2441.namprd03.prod.outlook.com (10.168.233.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 8 Aug 2016 18:17:14 +0000 Received: from DM5PR03MB2441.namprd03.prod.outlook.com ([10.168.233.11]) by DM5PR03MB2441.namprd03.prod.outlook.com ([10.168.233.11]) with mapi id 15.01.0549.025; Mon, 8 Aug 2016 18:17:14 +0000 From: Anthony Nadalin To: Martin Thomson , Nick Harper Thread-Topic: [Unbearable] migrations of token bindings Thread-Index: AdHtGANk8YhqkfT0RKqstDH3Uk+wIQABbhaAAABcF4AAAJzCgAABd/UAADEmigAAzHZEgAAgxE3g Date: Mon, 8 Aug 2016 18:17:14 +0000 Message-ID: References: <974CF78E8475CD4CA398B1FCA21C8E99565A9DF7@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9EB0@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9F26@PRN-MBX01-4.TheFacebook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [2001:4898:80e8:7::4d0] x-ms-office365-filtering-correlation-id: 6f5b1272-e0fd-4db6-1e0a-08d3bfb8397e x-microsoft-exchange-diagnostics: 1; DM5PR03MB2441; 6:XeS3j4SNWyonnClRMsDsW7O6xlCdQ5I6R1ehvou8vpPma0RVl1e3WX75lN7oGfZDiLzpx5Gd1+qStwTZfgi9Uz25D5IH6S6tpsLzAy0I2YtGnAeH4M6rQJOsQL3PSSjrBAt87SpRnsyXsigTX0Hp2iBQjxYdDgOpv3k/wC+aBbPf8Ech9+lYnMwGOGZwr9GpNAAFhQ7RWmHxuprpfovMvud9kFHfx6LxzSKbhhlsOFG/8tyQEJ4JlCsoTFF4Ox5754FC55Btzm5tNRWn0mBRiBCHNjaFyRQmuE7s7K207hbPOGU3URoQpfDHwQxrKNwi2VG11PQapu8eL5B9gRmKUw==; 5:ENHt+PqEa5NUYBebhJ0gu2KET5ncwV/L+4lfr2k6lZ+NJVzhFJUY8tBOo2OmU2K7Ndk2qk/AXrdK1PJ6i0zDJn/YKNd6e8ycEtmJJ5/7t2XnTY6nrk830pNglL4VmSiO7pK2h9h1Rrzzw0TNRoaCZg==; 24:K1PepuLFhqNje4/+h3HsJi7h0U6WUpu7Vj9bXlzBJmgrbw/WiD8dtkpm1lb8lWuOXCS/P5DCfnpDPtOagKEbbSI7xxfclgUbcn6BbvW0hO0=; 7:rZDJ+WAanQB8iZ/4uF9nX9v3IBHMEjXkqpNiDH4iHKixkSvMfqfXlWTvaJFlQczZcJrwOMaW16w7E6mGIDPvUKyDr8J7aLw0Qpeb7iwXl2GDNxoMkT3/A1eDaNE6PMPGh0C1wP+V+sh1Ltj8Y/BnMnYe2/zWTf7RQzE/hc1JR1ADNcJFOqH/YbAujPIg1fSwmzwfk98P6JjEJwnXVjdvK55CjaB4YNqWk7f91Ek9IUQ8aiga9g9dhBpYo1xvgD7W x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM5PR03MB2441; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(189930954265078)(67672495146484)(211936372134217)(219752817060721); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM5PR03MB2441; BCL:0; PCL:0; RULEID:; SRVR:DM5PR03MB2441; x-forefront-prvs: 00286C0CA6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(199003)(24454002)(13464003)(189002)(86362001)(189998001)(575784001)(3280700002)(10290500002)(5001770100001)(5002640100001)(4326007)(97736004)(50986999)(106356001)(76576001)(586003)(10090500001)(8676002)(3660700001)(77096005)(81156014)(81166006)(2906002)(92566002)(33656002)(9686002)(2900100001)(2950100001)(76176999)(10400500002)(5005710100001)(8990500004)(86612001)(102836003)(6116002)(54356999)(99286002)(87936001)(74316002)(15975445007)(101416001)(19580405001)(19580395003)(8936002)(305945005)(105586002)(122556002)(11100500001)(7846002)(7696003)(7736002)(93886004)(68736007)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR03MB2441; H:DM5PR03MB2441.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 08 Aug 2016 18:17:14.7404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR03MB2441 Archived-At: Cc: "unbearable@ietf.org" , Subodh Iyengar Subject: Re: [Unbearable] migrations of token bindings 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, 08 Aug 2016 18:17:19 -0000 By authenticate them do you me validate their authenticity ? or something d= ifferent? -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Martin T= homson Sent: Sunday, August 7, 2016 7:38 PM To: Nick Harper Cc: unbearable@ietf.org; Subodh Iyengar Subject: Re: [Unbearable] migrations of token bindings On 4 August 2016 at 11:04, Nick Harper wrote: > When a server receives a TokenBindingMessage with two provided=20 > TokenBindings, it must rebind the tokens sent by the client to be=20 > bound to the new key (this is identified as the key of the type that=20 > the server has ranked higher on its preference list). What about those tokens that require a third-party to authenticate them? See also the discussion in ACME regarding the migration of keys. There's an attack that is described there if you just have independent sign= atures. See https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%= 2f%2fmailarchive.ietf.org%2farch%2fmsg%2facme%2f-HKly8leUaA_TT6r0mgIkoX52tM= &data=3D02%7c01%7ctonynad%40microsoft.com%7c216ab9b6547543d4e14408d3bf3518e= 3%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c636062207174411173&sdata=3Db= gh22PzOsrFYNdc8sPpitadlucMFqhoULpahKhWHvxI%3d _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2funbearable&data=3D02%7c01%7ctonynad%40microsoft= .com%7c216ab9b6547543d4e14408d3bf3518e3%7c72f988bf86f141af91ab2d7cd011db47%= 7c1%7c0%7c636062207174411173&sdata=3DmNEd%2fw1WSac0Goj9rhina9aIV6DBeR4YN3%2= b2AMjIpNA%3d From nobody Mon Aug 8 11:27: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 48DA612D88D for ; Mon, 8 Aug 2016 11:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 lq1ppf26QWn5 for ; Mon, 8 Aug 2016 11:26:38 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0131.outbound.protection.outlook.com [104.47.33.131]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF54712D888 for ; Mon, 8 Aug 2016 11:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buckeyemailosu.onmicrosoft.com; s=selector1-osu-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=f63b+5Y4d+246yE2grnZMLVYZIr3Nna2qBlZo9VFYmw=; b=DYGUV+K3tvJ4DA3BdXHySOsOJ2Ns1CwfTdlsdPW631eFVNmU26X/iBCsWlQ2dYSBxGhsPmiuHSTstevjRWQ+gsG6auboc1RVUgKPhrE0poZTf0LGFAuaA1GSvOgfp5wneyHIFgxRDsn9nUQS9pNUSJ4fMZCeIV+N9V717kLau8k= Received: from BN6PR01CA0057.prod.exchangelabs.com (10.172.194.147) by CY1PR01MB2203.prod.exchangelabs.com (10.166.206.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 8 Aug 2016 18:26:34 +0000 Received: from BY2FFO11FD026.protection.gbl (2a01:111:f400:7c0c::125) by BN6PR01CA0057.outlook.office365.com (2603:10b6:404:cc::19) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.15 via Frontend Transport; Mon, 8 Aug 2016 18:26:34 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.216) 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.216 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.216; helo=cio-tnc-pf02.osuad.osu.edu; Received: from cio-tnc-pf02.osuad.osu.edu (164.107.81.216) by BY2FFO11FD026.mail.protection.outlook.com (10.1.15.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.557.8 via Frontend Transport; Mon, 8 Aug 2016 18:26:34 +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-pf02.osuad.osu.edu (Postfix) with ESMTPS id A8F9020067; Mon, 8 Aug 2016 14:26:33 -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; Mon, 8 Aug 2016 14:26:32 -0400 From: "Cantor, Scott" To: Brian Campbell Thread-Topic: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) Thread-Index: AQHR8aDDx+pDq6EZgE2nj7753s28fqA/YE6Q Date: Mon, 8 Aug 2016 18:26:31 +0000 Message-ID: <9846A6064BD102419D06814DD0D78DE1129E19BF@CIO-TNC-D2MBX02.osuad.osu.edu> References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> 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.249] x-header-sapphire: true Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:164.107.81.216; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(979002)(6009001)(7916002)(2980300002)(438002)(52314003)(199003)(189002)(2906002)(90282001)(88552002)(189998001)(86362001)(586003)(50466002)(2920100001)(2950100001)(93346002)(19580395003)(2900100001)(92566002)(87936001)(102836003)(6116002)(109096001)(75432002)(89122001)(7846002)(76176999)(47776003)(16796002)(8676002)(110136002)(106466001)(106116001)(66066001)(33656002)(55846006)(8936002)(3846002)(23676002)(356003)(4326007)(54356999)(5250100002)(50986999)(246002)(7736002)(7696003)(305945005)(11100500001)(7596002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR01MB2203; H:cio-tnc-pf02.osuad.osu.edu; FPR:; SPF:Pass; PTR:cio-tnc-pf02.osuad.osu.edu; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD026; 1:Xa0F6BES4abbbV65qMAq89i86JOxT+vL511OYOWXSv2DLWKUatiM5222WPc27h3pFKWheWg4hz/Lq+zvt3xWfKQ4hN1DPctNPyTwNEpzDbvGAOVkoBqOSIBFQuwxFPZUIZpJN6rfEW//WrHtvhYXaAEwUVNB6wht19zvRcNJbdTvhRQXWe93Rn9IhEVZ3DEb0NswbftuBeMM54c4cs17WxM8fB1YBCDZFx9GmzrsQDskpaqj6nIAxEJXLVqjADyibNU/4VW4ZFOR0hBZg+mJIMI+fR/AakVi4OWzm2I9DDAWHevUBQpbCMkDjadx10zmApmIIyHJlXHom0vzY0uMKLnvstoCRwFnbM+tnc39gu+CQPPDqaLUIJMYumUMXbJ9tDAGOxDyH8JogVrPDjGNvhLgbY+IXv7l/pCtM9x6JBWv2UhkhIOhrPYloO9hCLy2vyVW0P3psM9Q5FaC95Vr+Qvi3wp4FTjkX64HGfjL6vAM+3b8s/xelpFcRNlA+R0olTz4dB17RGnqX2DrKzdVHIX9WZUUQpJX4/dICfGiABxSu+rHIXhmGn8vkxnd285i X-MS-Office365-Filtering-Correlation-Id: d9b14c0b-38e4-4a78-e8c6-08d3bfb9876a X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB2203; 2:CFsiK4TQ5J5au7vKxlkgm0PGHLzjIn0ifFRyhc2wIFDZidVbfQz/idQU2LYdWUq2RBdyecrT5n/JcSulweWVnUuLjT78xOM3U2yn4NhFE1W51e/8nLh9HarP/HnJi7668g5NDe+sAfivyHraF0tJe4GB9MrNMiMV+dcsNdCWdT405xNZxRQLcvPPbRWSstLi; 3:GTCsqezqBfy2L+1t3d+FT4pc9CqReXJayHRL6OqLTX9Ml5xlsUu6zSAoAdtyJ+FAvvqYrEORW/3ufSw+oxgGjvkP7qICDvqkaz3Ij4nT6MhiB24Pgb7Nx6gCrLuf/oSjy0iwz7oyApvVHlRK8BAhHBbiY5u9xosJBUlCDBwDXfo1p7UVpol75crJv+MPMeVuggN1R3GwsG1IGkql/EDBu8JnH8V6njiGiBm6wwx6bW/7PXBwH7BOk+9lfga+vDdKVpgDhNh9oP8M6BzDld3upw== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:CY1PR01MB2203; X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB2203; 25:sBqq8qRNlqpIEQM93KmmyLwzUR7fQJNVfLS2ssxyD6czDTWveTHxui9sKxxeBulxBX91Y0sb2CMvIJdo9qSYiGTKbp55j62u0/HgklUaakseHIbhvULtKPYoqSaPDYHuQUMeKWsyGOKasy5j2k735nM/EH2x6YccJcEz4HL3zcoLj28iJdPaM9K+5RneJxyBRywYoCMgfGlN2r69b4EcUQ2RGt4BJiRZQODN7964GKoug7DbJvekKDiIBJYbOTGi5bQ+xtkx+XEf0qlimw64CsyjIEbxtvxVyUN0uXfwDN7ho5sUDGYV90/QMChrUpPesTuZvH6sXYF3rn6dW2zdYK4VJ2MTH6H35rBpVGluhFOX0Jii50oZ+A7OS5P8MJ/3M7s93RfypbEAmV9sSGGbkYGSdJk/5ZCkaiYhZ5Ej+rdEhj8qDn4D+wnPnbgDItPrO4JRZCumxoD50YhFBytOkeH3XlaOJbaTTioRkkGLz5wEoZcp2x68j43zxec8NMuJ2cRVuo+knjkmElpJXsRsohqt6tFlBHaigU6vHU7MxGhADFZslUGqnK/+I4p9XOuSv5oembxwhDpwbdweaGnCBNa5qUPG/lRG3KXdIIl/Vh4EeN0hr5Pk46+QLYFlVDtkc4lnIRjISZk+aKsWtHRksF98LTvcH4Rvul7Ezhxhq1Faj9VQmqlKdVV9yEVSBsW95D8tVUmaCdXe+IWMWhAVtUwzvWWZ5NrLdWg6ymNQRQfW98V+oxC91FwmJ1qf0vyl4jqQ/MhISOxdWdbGYVkEZg== X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB2203; 31:JwIGlzvzmLoFPQDCHGXHBYsi00txTQdXS8GBD+x7oINdkEkq9hlGbziEyvPLDMrp7iuiBlQtevbd0d90r6X2/zAv6mWiqa1kUTx8wJICcnn08f/TXAyCUPM2TYxSL5HquWoXJSTyzSDmKsU+E7XbZfD/LPdXOLzNy7T3nfttT1NBA6IN9Pp6rcqFke9IM/bi1qX66sSI8HB3bZEHRcz3omDyYWdfO7Nq3EIj2JOrswY=; 20:rTDNKOw4HexbaSOkTUvpj8+HFvRWUCJXb+VBlEZoMogDi/u4t5Mn4AhgPc6flRdD8//bgGQbn2wIwPf162W3ZdC42NPAIuIYPipAlPUy/2cKO0iJ8ftR5e53B2tqGXo02G8fdVOxfm4YNikJRrgnM7tNq0wvUbkR/eTIpsm5Z1n2M2XNGftri/DUYnNIiffxRlNprMe+SHwmeVU++Zd5JP9M52UamTm0N4ooKPeUQyjfr04D9uKBBJr4ODlfFpVGQZ1SL/odagmPaDzOV1Ry3fX/I49WhES1Hj4lvhNIMYa3bmD6A0Er5MeRl4FZP5Pk7UgHMFmVSe1QSUmFuHwwVzITva52k/pkQreqEEDiT5DzySRUzPisDfL7uH5zj+gvcjLvzPtfnYjzcGEel9ZJ3edBwo301whgfKiKohklpOCMmx0fhF3x3yEQ40yUjtM1zd/Qki06cF7NysQwsxcZFMi6F9mSXgHlHpqolNKHne8ZF0oZQDZY4olzpyopZbu7 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(192374486261705); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(5005006)(13018025)(8121501046)(13024025)(13017025)(13023025)(13015025)(3002001)(10201501046); SRVR:CY1PR01MB2203; BCL:0; PCL:0; RULEID:; SRVR:CY1PR01MB2203; X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB2203; 4:Ccwati0Mw0sn/C04/4bjmKA9VnEItWI+UrVhvrPrKah+fPMuEcRE29RHTAfcdxnrvyu3hotMojqgRC3iC+0s6e2NgSLetOcH3KTshYnhdalMVHQCXG8Wi4OdrnykRAc8Txg9Gyo3+b+gOpkb0nb7ys+w7VZ0KtAMeZh5WaKzNDE0EgGfK4CXuf4T0/Zfd5e5fhhZP6nETyPzzpk/Y5KRuyHRErdQ39dolRDeo4/LXRr4M/nqY5e/Uv0CdXo7glXjHD4hGGeRyNnwXOFOmAXY8KdzzDPW+Z/oci2yizRFl711UtWZkW4nXuvVSXrrSjpZEp+WTIAAMT1Hoqdu70/0Xb+GvCRc8W311l9ZXihrJkOhDj5jeU8rG+GimKhMxYQ26LA5ogzZoZfNDwrqSL3u0PZ4nwwEVxir8skENXoy5Kh38QZRnSp2yQAqV5G9qaw96viCCS+XFkBnwRMynfjOQOG8xH5+c5dyBZEi8WOApBg= X-Forefront-PRVS: 00286C0CA6 X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjAxTUIyMjAzOzIzOllCM2pJbHBYQnhPa2l0OVVLT0lRWVFydXdZ?= =?utf-8?B?Ky9wWTFhSUN6ZDhiS053V3JtQXcyemxLVzJwMUhhS2w3RlNIa3QxV1k3aFNV?= =?utf-8?B?dTJPaFZZMDBpU1I1bG1RZm9BZENNWUw1SysvcVhvSlZvUHNTZU1hTUR1Y0Vi?= =?utf-8?B?c1hGdFJURVo1R0pvMlJITjZmU2FVTFhkUU9BNkdzcWN0OEtKRm9aWFNKazBw?= =?utf-8?B?VFI3elo4MklHRmtuY2FScVIveHlvTUhSYUFjU3pGU0RlcGorVnZyWWpES0U5?= =?utf-8?B?L1RYNTIyeFFobGo1LzlQNmpjeFk1RzZFLzdUUDh3bUVVbGkxekg3REUzZW0r?= =?utf-8?B?NDJ0U3A1d1plaEFxaG43ak9vVStWcEVxU1NkaFY5ZHNpYmYrUk9BRVhkMHhq?= =?utf-8?B?VTR5MnRJcjB0b3dvNHRVR3pNeXZIc1NqRHFhUmlnQzVyUU43YUpyMzZjTTlp?= =?utf-8?B?c1FrcTA5UTU5dDJ3dGkwa2I4d0piUEdXQi9uYWFMb2lKYWJhY3pGWHpvNGx4?= =?utf-8?B?U3hGcUhqRHZ2L2JPbE1aNzljZlZKQzFOUCtXUUs1M1pveGdvVnR3bVN5V0lu?= =?utf-8?B?OFR1cW9yRWlFRnlhblgvTzhVc3dtYVdCeGRVVmYzZWtWZWhDaGcvb0tBNVE0?= =?utf-8?B?THRIVUVtNE9ZVkhWS0lnV2F2dXZNZWFzZzFyaFkzUnNndGMvRFVENTVQZlIz?= =?utf-8?B?TEpLSmw0Q0ZuVnNCdHdHdkNYV2FJYWljdlZHVG9CREpLaFBaZlVPbFpPb21W?= =?utf-8?B?YVpTeGZUbCsvUEVyRmpvQ1Rwc0Z4SU40bzBiZFp6Mm42SFV4ZXBEbEU5TmZF?= =?utf-8?B?M0s4eFRpL2wxZjJkdVN4a0Z1ZGFFTjJyQytoeWdqUTNzaW5UUUg3SFBMZ204?= =?utf-8?B?anlPZHpjczBGeERYemp0TU5VOVY0UFhITVo4NVg3VVphamNLQ2xKMWQwMFhK?= =?utf-8?B?SkEwaHdwaGlmREtWa1VOUitkWTFEcTBGZWQvWS9mZGdhTnZDWEpsczVJRUxX?= =?utf-8?B?NDhxTnk5Q2V6dXdNMGlENHVTdlY3MWVTbG5DRnd3VGFYUHJEVEVEcnpUWjJY?= =?utf-8?B?OXRsVGhxdDZlT2hWQ1hKWnJlYkFZMGhTL3YrdFk3cjh0eHdsbnFPaGpNSVZh?= =?utf-8?B?cXdNN3NhSFFJclAvM3ErK1p5eVNaQ2VMWVA3RDREUFI4Q0JmeTR3ZVlkNCsz?= =?utf-8?B?bmtUY1J4ZFBsblFEQS96YnpMek1vaHpmeG1yT3ZESys4UHJMTUo2ZTdIZ1VP?= =?utf-8?B?YjA2SEtwLzNZT0F3L3lWY0JWdHNrR1hoZnBURFZ1dzBsRlgxWTZtYWJEeUpU?= =?utf-8?B?Q0ExRnJqTkRWZ3pWZU9EY2pIb0VsTldZUGlPU2paaC9PR05JS2RxRXhJbWFn?= =?utf-8?B?aXZ5b0dkU1p6b3Q0RjgwRFRVREFjanNSVmE2Rkl1QVZ2d25vZEZhMFR1NVRs?= =?utf-8?B?ZE90YUZvYTZJZkc3TWtLelhDSE11eXVYM3doQmRBMTl4aWRzTERRVHlUaHJV?= =?utf-8?B?RFd6RXlKTytCYjBmdVVwT1NxaXVjNFpaY2JocjBKMWVpYWFjb1p3cFdyUnVq?= =?utf-8?B?TFViOGZlZ0REeDdaYk9lTVAvYWJLd0tHV0xEbzBMa2oyOWk4UUdzbUxWZnNE?= =?utf-8?B?S2h2bkFjd1FMbXd5Uml2dnRUU3RoZ2FJOUs1THZnVGlRT0FhYnpSQitLMWQr?= =?utf-8?B?M2h6RXdKckhXU29NRE9zVzR4Qk1WN2dFUE5scnJ0UUtDY2NYdFJqU2VrUVUy?= =?utf-8?B?Z01mY3JqVjNYZy9oT3Jlc1VhVzJjcHhBU2NFc0hUcDRSV3dXQW50MmJsV0Zn?= =?utf-8?Q?Juw507JE6AP1Y?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB2203; 6:2AJ4HndMx/4p0UtLaK+H6499bN0z6DcgSpyzKcz6WfBmQI7H0tqt/ZAP39vWVkNG/Fd/H6edRJnGVZrr3rM3d0ltBJDb9l+byDy0HKVfPp3Fe36hfNoCOloufaJcptQvpxC+EQXoQwn8EB4eZC2tUToAcXe1R7JtA5Mqb4ffkLrDdal/1+mGeizxpQN6iMgbqCd4x1PxPSCX9gx9EafJk1dY26Uobe1qX+bV9Ft9EyEbAV/79NgQCe+qEvUncKTm0DMW4E/pdLydDXvGusfrWvURNDbVVRkHov4+RDjXrS0=; 5:wuRUe2TcR2MVJ0oOGCUwCP7S76+soU6IbfFFUmUMMMgMrJE6Njmv+13EaLVNI/LZSov+fTq9Po9WGxaQ4Hu4cbpujafJq0r77g8pViHq4ZHYFtGGPrf6zq8HOcygfaqOzmTqK+Tr+EO/IHpkEHVP+w==; 24:Y60VmA1lWMeGzhJWW3d+mvuBAm/tlfUmIsebZ4cdbARcbxmPR0vZBQcKiHTW8JjymNKbMJ5O/uGmuJx8IEZHd/QZFcur7yAa+erPkRD6kNg=; 7:ZlLfEk2GVXpDqImUUrnjwo3B8fZoGOO1rKttWztXrv9/F4qfvcEu3kmbYHofcwah+IgNows/YjOTqQ4r5Un5RSgWbzv8NU5rlf18IKwb8h9XuyhMJD3pM+IkuVnGKCBSXXqlIJUzujqC6Au8s//khQ2/hqwfT7sVZb5hE+xGSd2fOWCePE3ZSofWCzgPDz/5iE1dxW8lt3RksJNfF9O4ZLudJaXjbrEFZDreKA8sFYsXSGa5Xfvrvsazkr9WEvp8 SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB2203; 20:XAgLhHS3ocZDne9gLrzs4CY0cxuP6P0k4ISaxEEezPI9SvLjUaP3mY33WAiDZopTq/7qjv0mRdpkoa493uluddDiTC5CnnRylDMDzeYx6kdRvUUtiSa5GrSjclMzVBN70knxKKMo29J4m26lAG/Ut8GgSo3aX1hIalijrzZKmh0= X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Aug 2016 18:26:34.9441 (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.216]; Helo=[cio-tnc-pf02.osuad.osu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR01MB2203 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 08 Aug 2016 18:26:44 -0000 PiBFdmVuIHdpdGggcmVhbCBmZWRlcmF0ZWQgU1NPIHN0YW5kYXJkcywgdXNpbmcgZG9tYWluIGNv b2tpZShzKSB0byB0cmFjaw0KPiBhdXRoZW50aWNhdGVkIGVuZC11c2VyIHN0YXRlIGlzIHZlcnkg dmVyeSBjb21tb24gZm9yIGludHJhLWVudGVycHJpc2UgU1NPDQo+IGFuZCBvbiBkaWZmZXJlbnQg c2l0ZXMvc2VydmljZXMgb24gbGFyZ2VyIHdlYiBwcm9wZXJ0aWVzIChJIHByZXN1bWUsIGFueXdh eSwNCj4gZnJvbSB0aGUgbWFueSAuYmlnY29tcGFueS5jb20gY29va2llcyBJIGhhdmUgaW4gbXkg YnJvd3NlcikuDQoNCkFuZCBoZXksIGl0IGhlbHBzIHlvdSB0cmFjayBwZW9wbGUgdG9vLi4uDQoN Cj4gVGhlIHRoZSBlVExEKzEgc2NvcGluZyBpcyBwcmFnbWF0aWMgYW5kIHVzZWZ1bCBhbmQsIHdp dGggaXQsDQo+IFRva2VuIEJpbmRpbmcgY2FuIGltcHJvdmUgdGhlIHNlY3VyaXR5IG9mIHN1Y2gg ZGVwbG95bWVudHMuDQoNCkknbSBqdXN0IGFncmVlaW5nIHdpdGggdGhlIHNlbnRpbWVudCB0aGF0 IGl0IGtpbmQgb2Ygc3Vja3MgdG8gKnJlcXVpcmUqIGl0LiBJdCdzIGEgY29tcGxleGl0eSAvIHBy aXZhY3kgdHJhZGUtb2ZmLCBvYnZpb3VzbHkuDQoNCkkgd291bGQgaG9wZSB0aGF0IGlmIGEgY29v a2llIHNwZWMgd2VyZSBpbnZlbnRlZCB0b2RheSwgcHJvcG9zaW5nIHRoYXQgb25seSBlVExEKzEg c2NvcGluZyBiZSBzdXBwb3J0ZWQgd291bGQgaGF2ZSBiZWVuIG5lZ2F0aXZlbHkgcmVjZWl2ZWQu DQoNCi0tIFNjb3R0DQoNCg== From nobody Mon Aug 8 11:39: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 9538412D8CF for ; Mon, 8 Aug 2016 11:39:10 -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, 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 (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 hKVXqegCP8Hs for ; Mon, 8 Aug 2016 11:39:05 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 66DFA12D51F for ; Mon, 8 Aug 2016 11:38:32 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id u25so207592584qtb.1 for ; Mon, 08 Aug 2016 11:38:32 -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:message-id:references :to; bh=xLp74ESmjEmJmz4XPIh9niM1TU6UlRukL5p5tEFsgNs=; b=ZxXPVnCTTXT3kq1d2ImzFyvk9TYzlMpwrQl2/VCpM+Qsg9/tb4cE5IDFnhlJlz3vVa DMmrG+C+bSoKYCMvkxiLXSDTNNmF8dHaDRA/5VOqGGVwL4FTfp5VzC3DnjdZQbv5XlAX KlLft245xpgrZ7J4FLHLECZm0ZuuA9rStjegz45huXRLKXM5TAwSU1zIHcFoVEAuouoH ixQmGnnC5F0M0F5nlXbeYwzM/YQQrEpnp+OgBfP9aOnFBqVUsUOSBkODN/TluArDO+eK dEmihZ7B2ewpLZThSnXPHizp7qbldIJQKPus0MFiajjZ1O3bSMx2OQoVycQOIwlJ4VG5 l7jA== 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 :message-id:references:to; bh=xLp74ESmjEmJmz4XPIh9niM1TU6UlRukL5p5tEFsgNs=; b=ajHTWVrdWmkv68JSYMpHDYNiJSVIEFEDFbCr6InXj6HDo6xACaO4KLQpum7DUe8gEH 0/KXGSkCG5b5sFWaQ3SyE6zZxyh+rwvUIDSegWkKw1Sb6nF1/ghXoc6oPb1MBJvLim0u kQ5X0tQbrSGt4uDI4SMJhH1LB4TFiwNQuNkzgnGByEgBD8ZfHVYbq/UZ/uTeeQj9NfVA GgwwcMbrnvaaS5aYE+/aqlsoS424o7xemrhfkUZFhOBTGH9lKvxX2N48+jh40NxoRS9M 5G3Ii4obSdrFNNJ5R1MXm9wP/d8mt6bLLrNSv95NlyrzcvkbXdd8x3nwDNobYVV0URyd +qjg== X-Gm-Message-State: AEkoousyIOKs98R8haQHmlnwBW0f8dGWmfMXcLZ3UB1R6V1bA0zsfkJLOKjAFd+eM9c2YpUs X-Received: by 10.200.48.146 with SMTP id v18mr30008418qta.107.1470681511390; Mon, 08 Aug 2016 11:38:31 -0700 (PDT) Received: from [192.168.8.100] ([181.202.0.34]) by smtp.gmail.com with ESMTPSA id j67sm3207228qkf.41.2016.08.08.11.38.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 08 Aug 2016 11:38:30 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_89FF191E-557E-45E5-92D3-B5CE7A09612A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Mon, 8 Aug 2016 14:38:26 -0400 Message-Id: References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> To: Brian Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Subodh Iyengar , Martin Thomson , Scott Cantor , IETF Tokbind WG , "Manger, James" , Nick Harper Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 08 Aug 2016 18:39:10 -0000 --Apple-Mail=_89FF191E-557E-45E5-92D3-B5CE7A09612A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 No Hat. I tend to agree with Brian. I know of lots of Web Access Management type applications that use these = sorts of cookies for session extension and other things. I think having different rules for Token Binding and cookies would = likely hurt adoption. However I am sensitive to unintended correlation. Martin do you have some idea how a token bound cookie set by = x.example.com could be validated by y.example.com under a strict same = origin policy. It strikes me that if you could then you haven=E2=80=99t stopped = correlation, but perhaps you have a idea how to do that. If we are only talking inconvenience I might be convinced, but = impossible is a larger issue. My biggest privacy concern is the theft and re use of the cookies, = saying some cookies cant be protected is a hard sell. Regards John B. > On Aug 8, 2016, at 2:13 PM, Brian Campbell = wrote: >=20 > Even with real federated SSO standards, using domain cookie(s) to = track authenticated end-user state is very very common for = intra-enterprise SSO and on different sites/services on larger web = properties (I presume, anyway, from the many .bigcompany.com = cookies I have in my browser). The the eTLD+1 = scoping is pragmatic and useful and, with it, Token Binding can improve = the security of such deployments. Scoping tighter than that would be = much more than merely inconvenient - it would require re-architecture of = many intra-domain SSO deployments and/or impede the adoption of Token = Binding. =20 >=20 > On Mon, Aug 8, 2016 at 8:01 AM, Cantor, Scott > wrote: > > That means that only the origin that generates the bound cookie can > > validate it, but I'm having trouble identifying cases where this = would > > be anything worse than merely inconvenient for servers to use. >=20 > While I favor this proposal, I can't say that I have the full range of = use cases in mind since I'm coming to the conversation late. My concerns = about the sharing of bindings were mostly motivated by = confusion/brain-freeze on my part, so it's nowhere near as bad as I was = envisioning. >=20 > My guess is that one common scenario this would block is the use of = bound domain cookies to implement intra-enterprise SSO, which (minus the = token binding) is/was a fairly common practice before the rise of real = federation standards, and is still supported today by some commercial = and open source SSO software. >=20 > I do think it would be unfortunate if there weren't a *way* to limit = this, even if it were actually still allowed. It's one thing to say you = can share them, but it's another to say you must. >=20 > -- Scott >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable = >=20 --Apple-Mail=_89FF191E-557E-45E5-92D3-B5CE7A09612A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
No Hat.

I tend to agree with Brian.

I know of lots of Web Access Management = type applications that use these sorts of cookies for session extension = and other things.

I think having different rules for Token Binding and cookies = would likely hurt adoption.

However I am sensitive to unintended correlation.

Martin do you have some = idea how a token bound cookie set by x.example.com could be validated by y.example.com under a = strict same origin policy.

It strikes me that if you could then you haven=E2=80=99t = stopped correlation, but perhaps you have a idea how to do = that.
If we are only talking inconvenience I might = be convinced, but impossible is a larger issue.

My biggest privacy concern is the theft = and re use of the cookies, saying some cookies cant be protected is a = hard sell.

Regards
John B.



On Aug 8, 2016, at 2:13 PM, Brian Campbell = <bcampbell@pingidentity.com> wrote:

Even with real federated SSO standards, using domain = cookie(s) to track authenticated end-user state is very very common for = intra-enterprise SSO and on different sites/services on larger web = properties (I presume, anyway, from the many .bigcompany.com cookies I have in my browser).  The = the eTLD+1 scoping is pragmatic and useful and, with it, Token Binding = can improve the security of such deployments. Scoping tighter than that = would be much more than merely inconvenient - it would require = re-architecture of many intra-domain SSO deployments and/or impede the = adoption of Token Binding. 

On Mon, = Aug 8, 2016 at 8:01 AM, Cantor, Scott <cantor.2@osu.edu> wrote:
> = That means that only the origin that generates the bound cookie can
> validate it, but I'm having trouble identifying cases where this = would
> be anything worse than merely inconvenient for servers to use.

While I favor this proposal, I can't say that I have the full = range of use cases in mind since I'm coming to the conversation late. My = concerns about the sharing of bindings were mostly motivated by = confusion/brain-freeze on my part, so it's nowhere near as bad as I was = envisioning.

My guess is that one common scenario this would block is the use of = bound domain cookies to implement intra-enterprise SSO, which (minus the = token binding) is/was a fairly common practice before the rise of real = federation standards, and is still supported today by some commercial = and open source SSO software.

I do think it would be unfortunate if there weren't a *way* to limit = this, even if it were actually still allowed. It's one thing to say you = can share them, but it's another to say you must.

-- Scott

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


= --Apple-Mail=_89FF191E-557E-45E5-92D3-B5CE7A09612A-- From nobody Mon Aug 8 11:44:34 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 847F812D897 for ; Mon, 8 Aug 2016 11:44:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 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, 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 mziB9PUePJLH for ; Mon, 8 Aug 2016 11:44:14 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 1561312D8AD for ; Mon, 8 Aug 2016 11:41:01 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id m101so365619648ioi.2 for ; Mon, 08 Aug 2016 11:41:01 -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=k/GrVXxWH/+WctzkVrK6jdR7RtJT88IxhGFeFbHEYks=; b=LJgSlA10wuxWofYLMTHpz2zYWaPvcpmk3ZwfnWMOgLTuRFwMzxB4Aft95f2uiYnrcH BtAUbSqCoGz50K0MtLt5juvsicsykSYDLIwMeN0aZQtuvvNmkTdRNDBrZj/AirHqNpIa LITHpB0jVksn1MF1ELAfrHP5SCfSL8qGep2j0= 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=k/GrVXxWH/+WctzkVrK6jdR7RtJT88IxhGFeFbHEYks=; b=E2gvA95l7FqTMIT8Eoj7ahuzNAqnVacCdvnofxk+SBoG6Wd0uYeMSD/1Gb1XQyAwLs TY5LEWGzQ6uiCb9vg69gOQAXBjDBmHnvaaMmHDyZUKqeDEQrAzlGffFDmzpVPcQcelPY 4/wzLZTfcHUW/eRf1/ntqvm0Mnzzdarjy+fOMg6E5qkyHZQuQ03qHjG9NV4QigyXe2+5 k2p3vgJyEV6GAxMHlvW7KlUO7nURvv0nj+RMePE9kKm+12NIMPimq4IO4AFbKQqo0sbj gjT9MakP7hrq9hqwoyGFMaTDNI7SqcztVBXZ0gLwKiVclnPNt+DBlWZSMDLhkuX0uCwd B44Q== X-Gm-Message-State: AEkoousa7eg80GfujuMBdA1kkotFxhGtoTbC/NfMFBC+KDthv7MBpL0xFsSL2uWg0+J4rJF7XYJ11rt4DojI5TbW X-Received: by 10.107.8.140 with SMTP id h12mr98822736ioi.95.1470681660337; Mon, 08 Aug 2016 11:41:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Mon, 8 Aug 2016 11:40:29 -0700 (PDT) In-Reply-To: References: <974CF78E8475CD4CA398B1FCA21C8E99565A9DF7@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9EB0@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9F26@PRN-MBX01-4.TheFacebook.com> From: Brian Campbell Date: Mon, 8 Aug 2016 12:40:29 -0600 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=001a113fb6b0f14758053993c17c Archived-At: Cc: "unbearable@ietf.org" , Subodh Iyengar Subject: Re: [Unbearable] migrations of token bindings 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, 08 Aug 2016 18:44:24 -0000 --001a113fb6b0f14758053993c17c Content-Type: text/plain; charset=UTF-8 I guess the question that comes to my mind is whether key migration is something that really needs to be accommodated by the protocol. How often will it really happen? A new key_parameters type might be introduced every few years at the most. And even if a client were to explicitly discard 'old' established bindings to force a change, the impact is no worse than a user choosing to clear cookies. The authentication context just has to be reestablished (log in again). On Wed, Aug 3, 2016 at 7:04 PM, Nick Harper wrote: > I chatted with Subodh offline about how to do key migrations for Token > Binding. We came up with the following as a potential change to be able to > support migrating from one key type to another. > > When a client sends the Token Binding negotiation TLS extension, it > includes with each key type whether or not it has a key of that type. > > Upon receipt of that extension, the server consults its list of supported > key types in preference order (and filters it based on what the client > sent). The server puts one or two values in its key_parameters_list: The > key type at the top of the filtered list, and the highest key type on the > filtered list that a client has a key for (these will be the same thing in > most cases, in which case the server sends only one value). If the server > sends two values, it must do so in this order (to indicate to the client > what the server's preference is). > > When a client receives two values in the key_parameters_list from the > server, the client generates a TokenBindingMessage with two provided > TokenBindings. (This means that the client is generating a new keypair for > one of the token bindings.) Once the client receives a successful response > to the application layer request that contained that TokenBindingMessage > (e.g. a 2xx or 3xx HTTP response for a request with a Sec-Token-Binding > header), the client may discard the key of the type that was not first in > the server's key_parameters_list. > > When a server receives a TokenBindingMessage with two provided > TokenBindings, it must rebind the tokens sent by the client to be bound to > the new key (this is identified as the key of the type that the server has > ranked higher on its preference list). > > There is also some implementation guidance for client HTTPS Token Binding > implementations. Since the same Token Binding key is used for all origins > on an eTLD+1, but a request to one origin might only contain some of the > tokens on that eTLD+1, the client needs to keep track of which keys for the > eTLD+1 are used on which origins, and make sure that a key is not discarded > until it is no longer used on any of the origins for that eTLD+1. > Furthermore, if a key of a type T for an eTLD+1 has never been presented to > a particular origin in that eTLD+1, the client must not indicate that it > has a key of type T in the negotiation extension. > > This client side complication is to handle the scenario of multiple > subdomains on an eTLD+1 which have different cookies. Consider a client and > server that support key types T1 and T2 (with T2 preferred over T1), and a > client that currently only has key K1 (of type T1) for multiple domains on > that server. The client and server both wish to migrate to a new key K2 of > type T2. In this example, the server runs foo.example.com and bar. > example.com, which have different cookies. > 1. Client sends negotiation extension with (T1, true) and (T2, false) when > connecting to foo.example.com. Server responds with T2, T1. > 2. Client generates new key K2 of type T2 for eTLD+1 example.com, no > origin. (K1 is in the key store for eTLD+1 example.com, origins > foo.example.com, bar.example.com.) > 3. Client sends Sec-Token-Binding header with K1 and K2 as provided token > bindings; server responds with a 2xx or 3xx response code. > 4. Client updates key store so K2 has origin foo.example.com and K1 no > longer has that origin (it only has bar.example.com listed as its origin). > Now, on future connections, the client can send a negotiation extension > with (T1, false), (T2, true) to foo.example.com, and foo.example.com will > only send back T2. > Note that when the client is deciding whether or not to indicate it has a > key of a particular type, it is checking for a key of that type for that > origin, and not for that eTLD+1. > When the server connects to bar.example.com, it continues as follows: > 5. Client sends negotiation extension with (T1, true), (T2, false), and > bar.example.com responds with T2, T1. > 6. Client sends Sec-Token-Binding header with K1 and K2 as provided token > bindings; server responds with 2xx or 3xx response code. > 7. Client updates key store to add bar.example.com as an origin for K2, > and remove bar.example.com as an origin for K1. > 8. Client sees that K1 has no more origins, and removes it from the key > store. > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a113fb6b0f14758053993c17c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I guess the question that comes to my mind is whether= key migration is something that really needs to be accommodated by the pro= tocol.

How often will it really happen? A new key_parameters = type might be introduced every few years at the most. And even if a client = were to explicitly discard 'old' established bindings to force a ch= ange, the impact is no worse than a user choosing to clear cookies. The aut= hentication context just has to be reestablished (log in again). =C2=A0

On Wed, Au= g 3, 2016 at 7:04 PM, Nick Harper <nharper@google.com> wrot= e:
I chatted with Subodh offline about h= ow to do key migrations for Token Binding. We came up with the following as= a potential change to be able to support migrating from one key type to an= other.

When a client sends the Token Binding negotiation TLS extension,= it includes with each key type whether or not it has a key of that type.

Upon receipt of that extension, the server consults its list of supporte= d key types in preference order (and filters it based on what the client se= nt). The server puts one or two values in its key_parameters_list: The key = type at the top of the filtered list, and the highest key type on the filte= red list that a client has a key for (these will be the same thing in most = cases, in which case the server sends only one value). If the server sends = two values, it must do so in this order (to indicate to the client what the= server's preference is).

When a client receives two values in the = key_parameters_list from the server, the client generates a TokenBindingMes= sage with two provided TokenBindings. (This means that the client is genera= ting a new keypair for one of the token bindings.) Once the client receives= a successful response to the application layer request that contained that= TokenBindingMessage (e.g. a 2xx or 3xx HTTP response for a request with a = Sec-Token-Binding header), the client may discard the key of the type that = was not first in the server's key_parameters_list.

When a server re= ceives a TokenBindingMessage with two provided TokenBindings, it must rebin= d the tokens sent by the client to be bound to the new key (this is identif= ied as the key of the type that the server has ranked higher on its prefere= nce list).

There is also some implementation guidance for client HTTPS = Token Binding implementations. Since the same Token Binding key is used for= all origins on an eTLD+1, but a request to one origin might only contain s= ome of the tokens on that eTLD+1, the client needs to keep track of which k= eys for the eTLD+1 are used on which origins, and make sure that a key is n= ot discarded until it is no longer used on any of the origins for that eTLD= +1. Furthermore, if a key of a type T for an eTLD+1 has never been presente= d to a particular origin in that eTLD+1, the client must not indicate that = it has a key of type T in the negotiation extension.

This client side c= omplication is to handle the scenario of multiple subdomains on an eTLD+1 w= hich have different cookies. Consider a client and server that support key = types T1 and T2 (with T2 preferred over T1), and a client that currently on= ly has key K1 (of type T1) for multiple domains on that server. The client = and server both wish to migrate to a new key K2 of type T2. In this example= , the server runs=C2=A0foo.example.com=C2=A0and=C2=A0bar.example.com, which have different cookies.
1. Client sends negotiation extension with= (T1, true) and (T2, false) when connecting to=C2=A0foo.example.com. Server responds with T2= , T1.
2. Client generates new key K2 o= f type T2 for eTLD+1=C2=A0example.com, no origin. (K1 is in the key store for eTLD+1=C2=A0example.com, origins=C2=A0<= a href=3D"http://foo.example.com/" target=3D"_blank">foo.example.com,= =C2=A0bar.exampl= e.com.)
3. Client sends Sec-Token-= Binding header with K1 and K2 as provided token bindings; server responds w= ith a 2xx or 3xx response code.
4. Cli= ent updates key store so K2 has origin=C2=A0foo.example.com=C2=A0and K1 no longer has that o= rigin (it only has=C2=A0bar.example.com=C2=A0listed as its origin).
Now, on future connections, the client can send a negotiation = extension with (T1, false), (T2, true) to=C2=A0foo.example.com, and=C2=A0foo.example.com=C2=A0will only send = back T2.
Note that when the client is = deciding whether or not to indicate it has a key of a particular type, it i= s checking for a key of that type for that origin, and not for that eTLD+1.=
When the server connects to=C2=A0bar.example.com, it c= ontinues as follows:
5. Client sends n= egotiation extension with (T1, true), (T2, false), and=C2=A0bar.example.com=C2=A0responds wi= th T2, T1.
6. Client sends Sec-Token-B= inding header with K1 and K2 as provided token bindings; server responds wi= th 2xx or 3xx response code.
7. Client= updates key store to add=C2=A0bar.example.com=C2=A0as an origin for K2, and remove=C2=A0<= a href=3D"http://bar.example.com/" target=3D"_blank">bar.example.com=C2= =A0as an origin for K1.
8. Client sees= that K1 has no more origins, and removes it from the key store.
=

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


--001a113fb6b0f14758053993c17c-- From nobody Mon Aug 8 11:57:09 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 454F012D8A7 for ; Mon, 8 Aug 2016 11:57:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.987 X-Spam-Level: X-Spam-Status: No, score=-2.987 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, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247, 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 tZ0Wm5ED-BIf for ; Mon, 8 Aug 2016 11:56:55 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 8BAB212D534 for ; Mon, 8 Aug 2016 11:53:55 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id i31so122227733uai.2 for ; Mon, 08 Aug 2016 11:53:55 -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=XcuzRcG4cLm79rpNUvVcKUiD1rzRxL/gYE40H9OW1yQ=; b=Q0/fSWiEiPhDOInMni7Jdu6paCUNUKiH2+dK3L+Q1peSQcuW3iOPKFIAUzE1DeZqcm HJR8SRKEdIi1ouKget+gqiZUNxJ4UAzcNcxLldw5oJd04Z69VtWe3rMepbbL9aPuni8L eQq1PODS7KESwduJB05Z01uBXm9WvwPBSreXIUE5c5dkbsjM/93XFvVa1OiO8liSMXW6 3xy1DB4ltcpC/BEr1Rjt1HRVk6Nd9of3NMlkzoQ6jvbk/fVG6iaCZftxyGB1+ocEcoJB vsm6+BxlFyJ/wv0HWd1ZurgiT1PpzZOo1Zi6deZ1qsyNvFlWlR7GI7lZkeMijSi2yMLI ugVQ== 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=XcuzRcG4cLm79rpNUvVcKUiD1rzRxL/gYE40H9OW1yQ=; b=U3ZwNiMwQqPdnTJKvRChb14C2iSFIM9G+nUN/9TYFSKe20qiljyBOn8FUbHpRxz6yj M13nxkFIc7jF6+iSS4+4ytPmrCHcLeIHtYiv23TE8y8XliHj7mZstCxlUPfBXFsVNPas 2moAZkXJ3uJScTCdt+zxkbrzX/VE5dLcKngDw5243LUcwp/rpNe2/vfzr7rQFJcsb884 omqc5MM4ZDfRD9pETF428VhyRL/KTjKHFsMs3XFCK1ZyeaY3vzunbY/BCmeG6I9cJlP7 LbwDilWBTqQpqBLqFvpSpJ3r+Xmii3pKtMS4sLUUfqL8Om4D3m42FGQkTRkvcO9+zpFI HAng== X-Gm-Message-State: AEkoous2KNYXatJVeO5YTxWt4+2bZDIvnpWqPVwXYx9pBEaSYsBTyfct8NbMDMYshvCH3DUhljzf/dtzhE3FOoA5 X-Received: by 10.31.109.193 with SMTP id i184mr4078138vkc.10.1470682434495; Mon, 08 Aug 2016 11:53:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.209 with HTTP; Mon, 8 Aug 2016 11:53:34 -0700 (PDT) In-Reply-To: References: <974CF78E8475CD4CA398B1FCA21C8E99565A9DF7@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9EB0@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9F26@PRN-MBX01-4.TheFacebook.com> From: Nick Harper Date: Mon, 8 Aug 2016 11:53:34 -0700 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=94eb2c096db4163b71053993f028 Archived-At: Cc: "unbearable@ietf.org" , Subodh Iyengar Subject: Re: [Unbearable] migrations of token bindings 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, 08 Aug 2016 18:57:04 -0000 --94eb2c096db4163b71053993f028 Content-Type: text/plain; charset=UTF-8 A related issue to migration is what should a client's behavior be if it supports multiple key types when it has one key that it can use with a server and is generating its negotiation extension. More concretely, suppose a client supports PSS and P256, and has a PSS key for example.com. When the client is connecting to example.com, should it list just PSS in its extension, or both PSS and P256? If the client lists PSS followed by P256 (to indicate that the client prefers PSS, since they are in preference order), but the server prefers P256 over PSS, should the server negotiate P256 or PSS? If the server negotiates P256, it just broke the binding it had for any tokens because the client just made a new key. This could be viewed as the one-time migration cost (which is a reasonable cost if it happens only one time), but now imagine that example.com is served by multiple servers that are slowly rolling out the preference change of preferring P256 over PSS, and the client is bouncing between servers that prefer one over the other. Now this "one-time" migration happens every time the client hits a server that has a different preference list compared to the previous server. On Mon, Aug 8, 2016 at 11:40 AM, Brian Campbell wrote: > I guess the question that comes to my mind is whether key migration is > something that really needs to be accommodated by the protocol. > > How often will it really happen? A new key_parameters type might be > introduced every few years at the most. And even if a client were to > explicitly discard 'old' established bindings to force a change, the impact > is no worse than a user choosing to clear cookies. The authentication > context just has to be reestablished (log in again). > > On Wed, Aug 3, 2016 at 7:04 PM, Nick Harper wrote: > >> I chatted with Subodh offline about how to do key migrations for Token >> Binding. We came up with the following as a potential change to be able to >> support migrating from one key type to another. >> >> When a client sends the Token Binding negotiation TLS extension, it >> includes with each key type whether or not it has a key of that type. >> >> Upon receipt of that extension, the server consults its list of supported >> key types in preference order (and filters it based on what the client >> sent). The server puts one or two values in its key_parameters_list: The >> key type at the top of the filtered list, and the highest key type on the >> filtered list that a client has a key for (these will be the same thing in >> most cases, in which case the server sends only one value). If the server >> sends two values, it must do so in this order (to indicate to the client >> what the server's preference is). >> >> When a client receives two values in the key_parameters_list from the >> server, the client generates a TokenBindingMessage with two provided >> TokenBindings. (This means that the client is generating a new keypair for >> one of the token bindings.) Once the client receives a successful response >> to the application layer request that contained that TokenBindingMessage >> (e.g. a 2xx or 3xx HTTP response for a request with a Sec-Token-Binding >> header), the client may discard the key of the type that was not first in >> the server's key_parameters_list. >> >> When a server receives a TokenBindingMessage with two provided >> TokenBindings, it must rebind the tokens sent by the client to be bound to >> the new key (this is identified as the key of the type that the server has >> ranked higher on its preference list). >> >> There is also some implementation guidance for client HTTPS Token Binding >> implementations. Since the same Token Binding key is used for all origins >> on an eTLD+1, but a request to one origin might only contain some of the >> tokens on that eTLD+1, the client needs to keep track of which keys for the >> eTLD+1 are used on which origins, and make sure that a key is not discarded >> until it is no longer used on any of the origins for that eTLD+1. >> Furthermore, if a key of a type T for an eTLD+1 has never been presented to >> a particular origin in that eTLD+1, the client must not indicate that it >> has a key of type T in the negotiation extension. >> >> This client side complication is to handle the scenario of multiple >> subdomains on an eTLD+1 which have different cookies. Consider a client and >> server that support key types T1 and T2 (with T2 preferred over T1), and a >> client that currently only has key K1 (of type T1) for multiple domains on >> that server. The client and server both wish to migrate to a new key K2 of >> type T2. In this example, the server runs foo.example.com and bar.e >> xample.com, which have different cookies. >> 1. Client sends negotiation extension with (T1, true) and (T2, false) >> when connecting to foo.example.com. Server responds with T2, T1. >> 2. Client generates new key K2 of type T2 for eTLD+1 example.com, no >> origin. (K1 is in the key store for eTLD+1 example.com, origins >> foo.example.com, bar.example.com.) >> 3. Client sends Sec-Token-Binding header with K1 and K2 as provided token >> bindings; server responds with a 2xx or 3xx response code. >> 4. Client updates key store so K2 has origin foo.example.com and K1 no >> longer has that origin (it only has bar.example.com listed as its >> origin). >> Now, on future connections, the client can send a negotiation extension >> with (T1, false), (T2, true) to foo.example.com, and foo.example.com will >> only send back T2. >> Note that when the client is deciding whether or not to indicate it has a >> key of a particular type, it is checking for a key of that type for that >> origin, and not for that eTLD+1. >> When the server connects to bar.example.com, it continues as follows: >> 5. Client sends negotiation extension with (T1, true), (T2, false), and >> bar.example.com responds with T2, T1. >> 6. Client sends Sec-Token-Binding header with K1 and K2 as provided token >> bindings; server responds with 2xx or 3xx response code. >> 7. Client updates key store to add bar.example.com as an origin for K2, >> and remove bar.example.com as an origin for K1. >> 8. Client sees that K1 has no more origins, and removes it from the key >> store. >> >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >> >> > --94eb2c096db4163b71053993f028 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A related issue to migration is what should a client's= behavior be if it supports multiple key types when it has one key that it = can use with a server and is generating its negotiation extension. More con= cretely, suppose a client supports PSS and P256, and has a PSS key for example.com. When the client is connecting t= o example.com, should it list just PSS i= n its extension, or both PSS and P256? If the client lists PSS followed by = P256 (to indicate that the client prefers PSS, since they are in preference= order), but the server prefers P256 over PSS, should the server negotiate = P256 or PSS? If the server negotiates P256, it just broke the binding it ha= d for any tokens because the client just made a new key. This could be view= ed as the one-time migration cost (which is a reasonable cost if it happens= only one time), but now imagine that exampl= e.com is served by multiple servers that are slowly rolling out the pre= ference change of preferring P256 over PSS, and the client is bouncing betw= een servers that prefer one over the other. Now this "one-time" m= igration happens every time the client hits a server that has a different p= reference list compared to the previous server.

On Mon, Aug 8, 2016 at 11:40 AM, Brian = Campbell <bcampbell@pingidentity.com> wrote:
I guess the question that= comes to my mind is whether key migration is something that really needs t= o be accommodated by the protocol.

How often will it really h= appen? A new key_parameters type might be introduced every few years at the= most. And even if a client were to explicitly discard 'old' establ= ished bindings to force a change, the impact is no worse than a user choosi= ng to clear cookies. The authentication context just has to be reestablishe= d (log in again). =C2=A0

On Wed, Aug 3, 2016 at 7:04 PM, Ni= ck Harper <nharper@google.com> wrote:
I chatted with Subodh offl= ine about how to do key migrations for Token Binding. We came up with the f= ollowing as a potential change to be able to support migrating from one key= type to another.

When a client sends the Token Binding negotiation TLS= extension, it includes with each key type whether or not it has a key of t= hat type.

Upon receipt of that extension, the server consults its list = of supported key types in preference order (and filters it based on what th= e client sent). The server puts one or two values in its key_parameters_lis= t: The key type at the top of the filtered list, and the highest key type o= n the filtered list that a client has a key for (these will be the same thi= ng in most cases, in which case the server sends only one value). If the se= rver sends two values, it must do so in this order (to indicate to the clie= nt what the server's preference is).

When a client receives two val= ues in the key_parameters_list from the server, the client generates a Toke= nBindingMessage with two provided TokenBindings. (This means that the clien= t is generating a new keypair for one of the token bindings.) Once the clie= nt receives a successful response to the application layer request that con= tained that TokenBindingMessage (e.g. a 2xx or 3xx HTTP response for a requ= est with a Sec-Token-Binding header), the client may discard the key of the= type that was not first in the server's key_parameters_list.

When = a server receives a TokenBindingMessage with two provided TokenBindings, it= must rebind the tokens sent by the client to be bound to the new key (this= is identified as the key of the type that the server has ranked higher on = its preference list).

There is also some implementation guidance for cl= ient HTTPS Token Binding implementations. Since the same Token Binding key = is used for all origins on an eTLD+1, but a request to one origin might onl= y contain some of the tokens on that eTLD+1, the client needs to keep track= of which keys for the eTLD+1 are used on which origins, and make sure that= a key is not discarded until it is no longer used on any of the origins fo= r that eTLD+1. Furthermore, if a key of a type T for an eTLD+1 has never be= en presented to a particular origin in that eTLD+1, the client must not ind= icate that it has a key of type T in the negotiation extension.

This cl= ient side complication is to handle the scenario of multiple subdomains on = an eTLD+1 which have different cookies. Consider a client and server that s= upport key types T1 and T2 (with T2 preferred over T1), and a client that c= urrently only has key K1 (of type T1) for multiple domains on that server. = The client and server both wish to migrate to a new key K2 of type T2. In t= his example, the server runs=C2=A0foo.example.com=C2=A0and=C2=A0bar.example.com, which have different co= okies.
1. Client sends negotiation ext= ension with (T1, true) and (T2, false) when connecting to=C2=A0foo.example.com. Server respo= nds with T2, T1.
2. Client generates n= ew key K2 of type T2 for eTLD+1=C2=A0example.com, no origin. (K1 is in the key store for eTLD+1= =C2=A0example.com, or= igins=C2=A0foo.exampl= e.com,=C2=A0bar.e= xample.com.)
3. Client sends = Sec-Token-Binding header with K1 and K2 as provided token bindings; server = responds with a 2xx or 3xx response code.
4. Client updates key store so K2 has origin=C2=A0foo.example.com=C2=A0and K1 no longer = has that origin (it only has=C2=A0bar.example.com=C2=A0listed as its origin).
Now, on future connections, the client can send a ne= gotiation extension with (T1, false), (T2, true) to=C2=A0foo.example.com, and=C2=A0foo.example.com=C2=A0wil= l only send back T2.
Note that when th= e client is deciding whether or not to indicate it has a key of a particula= r type, it is checking for a key of that type for that origin, and not for = that eTLD+1.
When the server connects = to=C2=A0bar.example.c= om, it continues as follows:
5. Cl= ient sends negotiation extension with (T1, true), (T2, false), and=C2=A0bar.example.com=C2= =A0responds with T2, T1.
6. Client sen= ds Sec-Token-Binding header with K1 and K2 as provided token bindings; serv= er responds with 2xx or 3xx response code.
7. Client updates key store to add=C2=A0bar.example.com=C2=A0as an origin for K2, and r= emove=C2=A0bar.exampl= e.com=C2=A0as an origin for K1.
8.= Client sees that K1 has no more origins, and removes it from the key store= .


_____________________________________= __________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearabl= e



--94eb2c096db4163b71053993f028-- From nobody Mon Aug 8 12:17:52 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 852A212D176 for ; Mon, 8 Aug 2016 12:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 0H7SrxhVQY2X for ; Mon, 8 Aug 2016 12:17:33 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0120.outbound.protection.outlook.com [104.47.34.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B84A12B046 for ; Mon, 8 Aug 2016 12:17:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=j6YbYQrxgiY3XIhR6Sn17dj/hlD8vsNuC5RA0/YAcnw=; b=HYlP6raYnkmJdviKFkLiJKWlyzGtD2CAGZTb1lfGbjRKQtO52xguxZIc1Mw0cWsgjDrQwtTfA1EyzjNILrvZS/QApqgZe28Khv5QFKkprUYkfBFZ5bbqeMLmkuTQZSM5tpvfyt00XPpNXEO/tZjNpIz1cRKg7Of0p6STPlz+TNk= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2154.namprd03.prod.outlook.com (10.166.206.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 8 Aug 2016 19:17:31 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0549.025; Mon, 8 Aug 2016 19:17:30 +0000 From: Andrei Popov To: Nick Harper , Brian Campbell Thread-Topic: [Unbearable] migrations of token bindings Thread-Index: AdHtGANk8YhqkfT0RKqstDH3Uk+wIQABbhaAAABcF4AAAJzCgAABd/UAADEmigAA7g84gAAAdPkAAACM+pA= Date: Mon, 8 Aug 2016 19:17:30 +0000 Message-ID: References: <974CF78E8475CD4CA398B1FCA21C8E99565A9DF7@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9EB0@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9F26@PRN-MBX01-4.TheFacebook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:d::1d2] x-ms-office365-filtering-correlation-id: a7f755f0-49bb-422f-7b55-08d3bfc0a4dc x-microsoft-exchange-diagnostics: 1; CY1PR03MB2154; 6:31p3ju1uUvSk9grEwIJ8oSnyng3CulnPCW/4KCb+wfQMk9Vv+LFNALv98XSIZaqWZH2tkHotcUNrj8oAwy1CEobCIB84Gs/fuxt/prmB9LJqZfOKNVfalxCA3XH7AjvF9jjK70pIHnatJX46Ks47E13+fnw1GgL/t9H+d4Y0lnaXBItPe8opMYKsnK0O4kpYwnxh61Kbi46dWVpQNlBWePDky7HkAsrVAtJtyr3q5u/Mb6Lnm/yJF9pLeE7CbtNswIUjoomGpSsMM0hwM+l0uo8CBVCs+w1HkLgJQQIOHXTrbIF2ZIvlXiL+ByKpz93bDp3Gfn2cKHCcGCwPCjHucw==; 5:oFQq4Ufq5/K48ta9BtmT5AHDBHpJrE+ysv/Q3Qe5DNnvRNE5n9PqciMWZrWtqqWokUEAKo9bil1mdxhupY8Nr4hQAtlCyFRpRcHS7mICcZa6GuwvIghREXY8IwqGKP95VJz/6yS/hUJ0SVeL4roU1w==; 24:6Zblhc3Ht6tcQX7DizvM35LrGK4TBB2r52Qeb/e7GnAXOmr75zcBrYHj8w09BQELN6mtBfnZpFrvXTNTEsw80aTdDxgcDRADUM8+Wb+oPF4=; 7:MSW8sQmeXpyC+J24IqmK9kVro6mPDSdjFYji5Tc82GDKFpXT1gfDrP16dEnEhZQWbgkev/p90l6u3HWOAq2hAZQQutvZ5Rsf41avO0B3LsXy50tOngSigvScSCSx8fyUhc1XH4m428Cq1mhG8Z8CFfO0LplOr2WPlrfpIGZjXR+1860MY/JUaLRHf0B6iUUjuVI7/ZSYTy2XPvItnjtSbfWtxqVwQRRDcXfL1Y0tKHgwZuNw1ZiCaAi/KZ8C9Z4g x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2154; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(67672495146484)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2154; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2154; x-forefront-prvs: 00286C0CA6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(24454002)(199003)(189002)(99286002)(16236675004)(105586002)(101416001)(19625215002)(19300405004)(15395725005)(2906002)(4326007)(9686002)(54356999)(93886004)(8936002)(1680700002)(33656002)(5002640100001)(81156014)(68736007)(19617315012)(8676002)(76176999)(50986999)(586003)(81166006)(106356001)(10290500002)(92566002)(19580395003)(19580405001)(86362001)(10090500001)(7696003)(189998001)(7906003)(97736004)(19609705001)(8990500004)(122556002)(7736002)(7846002)(5001770100001)(790700001)(102836003)(5005710100001)(2900100001)(6116002)(77096005)(16601075003)(74316002)(10400500002)(3280700002)(87936001)(3660700001)(76576001)(2950100001)(15975445007)(86612001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2154; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB2155E68DEA5EE81504D13DED8C1B0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2016 19:17:30.6708 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2154 Archived-At: Cc: "unbearable@ietf.org" , Subodh Iyengar Subject: Re: [Unbearable] migrations of token bindings 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, 08 Aug 2016 19:17:38 -0000 --_000_CY1PR03MB2155E68DEA5EE81504D13DED8C1B0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXMgdGhlIGFiaWxpdHkgdG8gcmUtYmluZCB0b2tlbnMgdG8gYSBkaWZmZXJlbnQga2V5IHR5cGUg d2l0aG91dCByZWF1dGhlbnRpY2F0aW9uIGFuIGltcG9ydGFudCByZXF1aXJlbWVudD8gVGhpcyBp bmNyZWFzZXMgaW1wbGVtZW50YXRpb24gY29tcGxleGl0eSBhbmQgY29tcHV0YXRpb25hbCBjb3N0 IChpZiBtdWx0aXBsZSBzaWduYXR1cmVzIGFyZSBpbnZvbHZlZCkgYW5kIHRoZXJlZm9yZSBpcyBu b3Qgc3VwcG9ydGVkIGluIHRoZSBjdXJyZW50IHNwZWNzLg0KDQoNCsOYICBXaGVuIHRoZSBjbGll bnQgaXMgY29ubmVjdGluZyB0byBleGFtcGxlLmNvbTxodHRwOi8vZXhhbXBsZS5jb20+LCBzaG91 bGQgaXQgbGlzdCBqdXN0IFBTUyBpbiBpdHMgZXh0ZW5zaW9uLCBvciBib3RoIFBTUyBhbmQgUDI1 Nj8NClRoZSBjbGllbnQgaW5kaWNhdGVzIGFsbCBzdXBwb3J0ZWQgVEIgcGFyYW1ldGVycy4NCg0K DQrDmCAgSWYgdGhlIGNsaWVudCBsaXN0cyBQU1MgZm9sbG93ZWQgYnkgUDI1NiAodG8gaW5kaWNh dGUgdGhhdCB0aGUgY2xpZW50IHByZWZlcnMgUFNTLCBzaW5jZSB0aGV5IGFyZSBpbiBwcmVmZXJl bmNlIG9yZGVyKSwgYnV0IHRoZSBzZXJ2ZXIgcHJlZmVycyBQMjU2IG92ZXIgUFNTLCBzaG91bGQg dGhlIHNlcnZlciBuZWdvdGlhdGUgUDI1NiBvciBQU1M/DQpHZW5lcmFsbHksIHRoZSBzZXJ2ZXIg c2hvdWxkIHVzZSB0aGUgc2VydmVy4oCZcyBwcmVmZXJlbmNlcy4gSG93ZXZlciwgdGhlcmUgbWF5 IGJlIGNvbmZpZ3VyYXRpb25zIHdoZXJlIGNsaWVudCBwcmVmZXJlbmNlcyBhcmUgaG9ub3JlZC4N Cg0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE5pY2sgSGFycGVyDQpTZW50OiBNb25kYXksIEF1Z3VzdCA4LCAyMDE2IDEx OjU0IEFNDQpUbzogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPg0K Q2M6IHVuYmVhcmFibGVAaWV0Zi5vcmc7IFN1Ym9kaCBJeWVuZ2FyIDxzdWJvZGhAZmIuY29tPg0K U3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBtaWdyYXRpb25zIG9mIHRva2VuIGJpbmRpbmdzDQoN CkEgcmVsYXRlZCBpc3N1ZSB0byBtaWdyYXRpb24gaXMgd2hhdCBzaG91bGQgYSBjbGllbnQncyBi ZWhhdmlvciBiZSBpZiBpdCBzdXBwb3J0cyBtdWx0aXBsZSBrZXkgdHlwZXMgd2hlbiBpdCBoYXMg b25lIGtleSB0aGF0IGl0IGNhbiB1c2Ugd2l0aCBhIHNlcnZlciBhbmQgaXMgZ2VuZXJhdGluZyBp dHMgbmVnb3RpYXRpb24gZXh0ZW5zaW9uLiBNb3JlIGNvbmNyZXRlbHksIHN1cHBvc2UgYSBjbGll bnQgc3VwcG9ydHMgUFNTIGFuZCBQMjU2LCBhbmQgaGFzIGEgUFNTIGtleSBmb3IgZXhhbXBsZS5j b208aHR0cDovL2V4YW1wbGUuY29tPi4gV2hlbiB0aGUgY2xpZW50IGlzIGNvbm5lY3RpbmcgdG8g ZXhhbXBsZS5jb208aHR0cDovL2V4YW1wbGUuY29tPiwgc2hvdWxkIGl0IGxpc3QganVzdCBQU1Mg aW4gaXRzIGV4dGVuc2lvbiwgb3IgYm90aCBQU1MgYW5kIFAyNTY/IElmIHRoZSBjbGllbnQgbGlz dHMgUFNTIGZvbGxvd2VkIGJ5IFAyNTYgKHRvIGluZGljYXRlIHRoYXQgdGhlIGNsaWVudCBwcmVm ZXJzIFBTUywgc2luY2UgdGhleSBhcmUgaW4gcHJlZmVyZW5jZSBvcmRlciksIGJ1dCB0aGUgc2Vy dmVyIHByZWZlcnMgUDI1NiBvdmVyIFBTUywgc2hvdWxkIHRoZSBzZXJ2ZXIgbmVnb3RpYXRlIFAy NTYgb3IgUFNTPyBJZiB0aGUgc2VydmVyIG5lZ290aWF0ZXMgUDI1NiwgaXQganVzdCBicm9rZSB0 aGUgYmluZGluZyBpdCBoYWQgZm9yIGFueSB0b2tlbnMgYmVjYXVzZSB0aGUgY2xpZW50IGp1c3Qg bWFkZSBhIG5ldyBrZXkuIFRoaXMgY291bGQgYmUgdmlld2VkIGFzIHRoZSBvbmUtdGltZSBtaWdy YXRpb24gY29zdCAod2hpY2ggaXMgYSByZWFzb25hYmxlIGNvc3QgaWYgaXQgaGFwcGVucyBvbmx5 IG9uZSB0aW1lKSwgYnV0IG5vdyBpbWFnaW5lIHRoYXQgZXhhbXBsZS5jb208aHR0cDovL2V4YW1w bGUuY29tPiBpcyBzZXJ2ZWQgYnkgbXVsdGlwbGUgc2VydmVycyB0aGF0IGFyZSBzbG93bHkgcm9s bGluZyBvdXQgdGhlIHByZWZlcmVuY2UgY2hhbmdlIG9mIHByZWZlcnJpbmcgUDI1NiBvdmVyIFBT UywgYW5kIHRoZSBjbGllbnQgaXMgYm91bmNpbmcgYmV0d2VlbiBzZXJ2ZXJzIHRoYXQgcHJlZmVy IG9uZSBvdmVyIHRoZSBvdGhlci4gTm93IHRoaXMgIm9uZS10aW1lIiBtaWdyYXRpb24gaGFwcGVu cyBldmVyeSB0aW1lIHRoZSBjbGllbnQgaGl0cyBhIHNlcnZlciB0aGF0IGhhcyBhIGRpZmZlcmVu dCBwcmVmZXJlbmNlIGxpc3QgY29tcGFyZWQgdG8gdGhlIHByZXZpb3VzIHNlcnZlci4NCg0KT24g TW9uLCBBdWcgOCwgMjAxNiBhdCAxMTo0MCBBTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBw aW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3Rl Og0KSSBndWVzcyB0aGUgcXVlc3Rpb24gdGhhdCBjb21lcyB0byBteSBtaW5kIGlzIHdoZXRoZXIg a2V5IG1pZ3JhdGlvbiBpcyBzb21ldGhpbmcgdGhhdCByZWFsbHkgbmVlZHMgdG8gYmUgYWNjb21t b2RhdGVkIGJ5IHRoZSBwcm90b2NvbC4NCkhvdyBvZnRlbiB3aWxsIGl0IHJlYWxseSBoYXBwZW4/ IEEgbmV3IGtleV9wYXJhbWV0ZXJzIHR5cGUgbWlnaHQgYmUgaW50cm9kdWNlZCBldmVyeSBmZXcg eWVhcnMgYXQgdGhlIG1vc3QuIEFuZCBldmVuIGlmIGEgY2xpZW50IHdlcmUgdG8gZXhwbGljaXRs eSBkaXNjYXJkICdvbGQnIGVzdGFibGlzaGVkIGJpbmRpbmdzIHRvIGZvcmNlIGEgY2hhbmdlLCB0 aGUgaW1wYWN0IGlzIG5vIHdvcnNlIHRoYW4gYSB1c2VyIGNob29zaW5nIHRvIGNsZWFyIGNvb2tp ZXMuIFRoZSBhdXRoZW50aWNhdGlvbiBjb250ZXh0IGp1c3QgaGFzIHRvIGJlIHJlZXN0YWJsaXNo ZWQgKGxvZyBpbiBhZ2FpbikuDQoNCk9uIFdlZCwgQXVnIDMsIDIwMTYgYXQgNzowNCBQTSwgTmlj ayBIYXJwZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbTxtYWlsdG86bmhhcnBlckBnb29nbGUuY29tPj4g d3JvdGU6DQpJIGNoYXR0ZWQgd2l0aCBTdWJvZGggb2ZmbGluZSBhYm91dCBob3cgdG8gZG8ga2V5 IG1pZ3JhdGlvbnMgZm9yIFRva2VuIEJpbmRpbmcuIFdlIGNhbWUgdXAgd2l0aCB0aGUgZm9sbG93 aW5nIGFzIGEgcG90ZW50aWFsIGNoYW5nZSB0byBiZSBhYmxlIHRvIHN1cHBvcnQgbWlncmF0aW5n IGZyb20gb25lIGtleSB0eXBlIHRvIGFub3RoZXIuDQoNCldoZW4gYSBjbGllbnQgc2VuZHMgdGhl IFRva2VuIEJpbmRpbmcgbmVnb3RpYXRpb24gVExTIGV4dGVuc2lvbiwgaXQgaW5jbHVkZXMgd2l0 aCBlYWNoIGtleSB0eXBlIHdoZXRoZXIgb3Igbm90IGl0IGhhcyBhIGtleSBvZiB0aGF0IHR5cGUu DQoNClVwb24gcmVjZWlwdCBvZiB0aGF0IGV4dGVuc2lvbiwgdGhlIHNlcnZlciBjb25zdWx0cyBp dHMgbGlzdCBvZiBzdXBwb3J0ZWQga2V5IHR5cGVzIGluIHByZWZlcmVuY2Ugb3JkZXIgKGFuZCBm aWx0ZXJzIGl0IGJhc2VkIG9uIHdoYXQgdGhlIGNsaWVudCBzZW50KS4gVGhlIHNlcnZlciBwdXRz IG9uZSBvciB0d28gdmFsdWVzIGluIGl0cyBrZXlfcGFyYW1ldGVyc19saXN0OiBUaGUga2V5IHR5 cGUgYXQgdGhlIHRvcCBvZiB0aGUgZmlsdGVyZWQgbGlzdCwgYW5kIHRoZSBoaWdoZXN0IGtleSB0 eXBlIG9uIHRoZSBmaWx0ZXJlZCBsaXN0IHRoYXQgYSBjbGllbnQgaGFzIGEga2V5IGZvciAodGhl c2Ugd2lsbCBiZSB0aGUgc2FtZSB0aGluZyBpbiBtb3N0IGNhc2VzLCBpbiB3aGljaCBjYXNlIHRo ZSBzZXJ2ZXIgc2VuZHMgb25seSBvbmUgdmFsdWUpLiBJZiB0aGUgc2VydmVyIHNlbmRzIHR3byB2 YWx1ZXMsIGl0IG11c3QgZG8gc28gaW4gdGhpcyBvcmRlciAodG8gaW5kaWNhdGUgdG8gdGhlIGNs aWVudCB3aGF0IHRoZSBzZXJ2ZXIncyBwcmVmZXJlbmNlIGlzKS4NCg0KV2hlbiBhIGNsaWVudCBy ZWNlaXZlcyB0d28gdmFsdWVzIGluIHRoZSBrZXlfcGFyYW1ldGVyc19saXN0IGZyb20gdGhlIHNl cnZlciwgdGhlIGNsaWVudCBnZW5lcmF0ZXMgYSBUb2tlbkJpbmRpbmdNZXNzYWdlIHdpdGggdHdv IHByb3ZpZGVkIFRva2VuQmluZGluZ3MuIChUaGlzIG1lYW5zIHRoYXQgdGhlIGNsaWVudCBpcyBn ZW5lcmF0aW5nIGEgbmV3IGtleXBhaXIgZm9yIG9uZSBvZiB0aGUgdG9rZW4gYmluZGluZ3MuKSBP bmNlIHRoZSBjbGllbnQgcmVjZWl2ZXMgYSBzdWNjZXNzZnVsIHJlc3BvbnNlIHRvIHRoZSBhcHBs aWNhdGlvbiBsYXllciByZXF1ZXN0IHRoYXQgY29udGFpbmVkIHRoYXQgVG9rZW5CaW5kaW5nTWVz c2FnZSAoZS5nLiBhIDJ4eCBvciAzeHggSFRUUCByZXNwb25zZSBmb3IgYSByZXF1ZXN0IHdpdGgg YSBTZWMtVG9rZW4tQmluZGluZyBoZWFkZXIpLCB0aGUgY2xpZW50IG1heSBkaXNjYXJkIHRoZSBr ZXkgb2YgdGhlIHR5cGUgdGhhdCB3YXMgbm90IGZpcnN0IGluIHRoZSBzZXJ2ZXIncyBrZXlfcGFy YW1ldGVyc19saXN0Lg0KDQpXaGVuIGEgc2VydmVyIHJlY2VpdmVzIGEgVG9rZW5CaW5kaW5nTWVz c2FnZSB3aXRoIHR3byBwcm92aWRlZCBUb2tlbkJpbmRpbmdzLCBpdCBtdXN0IHJlYmluZCB0aGUg dG9rZW5zIHNlbnQgYnkgdGhlIGNsaWVudCB0byBiZSBib3VuZCB0byB0aGUgbmV3IGtleSAodGhp cyBpcyBpZGVudGlmaWVkIGFzIHRoZSBrZXkgb2YgdGhlIHR5cGUgdGhhdCB0aGUgc2VydmVyIGhh cyByYW5rZWQgaGlnaGVyIG9uIGl0cyBwcmVmZXJlbmNlIGxpc3QpLg0KDQpUaGVyZSBpcyBhbHNv IHNvbWUgaW1wbGVtZW50YXRpb24gZ3VpZGFuY2UgZm9yIGNsaWVudCBIVFRQUyBUb2tlbiBCaW5k aW5nIGltcGxlbWVudGF0aW9ucy4gU2luY2UgdGhlIHNhbWUgVG9rZW4gQmluZGluZyBrZXkgaXMg dXNlZCBmb3IgYWxsIG9yaWdpbnMgb24gYW4gZVRMRCsxLCBidXQgYSByZXF1ZXN0IHRvIG9uZSBv cmlnaW4gbWlnaHQgb25seSBjb250YWluIHNvbWUgb2YgdGhlIHRva2VucyBvbiB0aGF0IGVUTEQr MSwgdGhlIGNsaWVudCBuZWVkcyB0byBrZWVwIHRyYWNrIG9mIHdoaWNoIGtleXMgZm9yIHRoZSBl VExEKzEgYXJlIHVzZWQgb24gd2hpY2ggb3JpZ2lucywgYW5kIG1ha2Ugc3VyZSB0aGF0IGEga2V5 IGlzIG5vdCBkaXNjYXJkZWQgdW50aWwgaXQgaXMgbm8gbG9uZ2VyIHVzZWQgb24gYW55IG9mIHRo ZSBvcmlnaW5zIGZvciB0aGF0IGVUTEQrMS4gRnVydGhlcm1vcmUsIGlmIGEga2V5IG9mIGEgdHlw ZSBUIGZvciBhbiBlVExEKzEgaGFzIG5ldmVyIGJlZW4gcHJlc2VudGVkIHRvIGEgcGFydGljdWxh ciBvcmlnaW4gaW4gdGhhdCBlVExEKzEsIHRoZSBjbGllbnQgbXVzdCBub3QgaW5kaWNhdGUgdGhh dCBpdCBoYXMgYSBrZXkgb2YgdHlwZSBUIGluIHRoZSBuZWdvdGlhdGlvbiBleHRlbnNpb24uDQoN ClRoaXMgY2xpZW50IHNpZGUgY29tcGxpY2F0aW9uIGlzIHRvIGhhbmRsZSB0aGUgc2NlbmFyaW8g b2YgbXVsdGlwbGUgc3ViZG9tYWlucyBvbiBhbiBlVExEKzEgd2hpY2ggaGF2ZSBkaWZmZXJlbnQg Y29va2llcy4gQ29uc2lkZXIgYSBjbGllbnQgYW5kIHNlcnZlciB0aGF0IHN1cHBvcnQga2V5IHR5 cGVzIFQxIGFuZCBUMiAod2l0aCBUMiBwcmVmZXJyZWQgb3ZlciBUMSksIGFuZCBhIGNsaWVudCB0 aGF0IGN1cnJlbnRseSBvbmx5IGhhcyBrZXkgSzEgKG9mIHR5cGUgVDEpIGZvciBtdWx0aXBsZSBk b21haW5zIG9uIHRoYXQgc2VydmVyLiBUaGUgY2xpZW50IGFuZCBzZXJ2ZXIgYm90aCB3aXNoIHRv IG1pZ3JhdGUgdG8gYSBuZXcga2V5IEsyIG9mIHR5cGUgVDIuIEluIHRoaXMgZXhhbXBsZSwgdGhl IHNlcnZlciBydW5zIGZvby5leGFtcGxlLmNvbTxodHRwOi8vZm9vLmV4YW1wbGUuY29tLz4gYW5k IGJhci5leGFtcGxlLmNvbTxodHRwOi8vYmFyLmV4YW1wbGUuY29tLz4sIHdoaWNoIGhhdmUgZGlm ZmVyZW50IGNvb2tpZXMuDQoxLiBDbGllbnQgc2VuZHMgbmVnb3RpYXRpb24gZXh0ZW5zaW9uIHdp dGggKFQxLCB0cnVlKSBhbmQgKFQyLCBmYWxzZSkgd2hlbiBjb25uZWN0aW5nIHRvIGZvby5leGFt cGxlLmNvbTxodHRwOi8vZm9vLmV4YW1wbGUuY29tLz4uIFNlcnZlciByZXNwb25kcyB3aXRoIFQy LCBUMS4NCjIuIENsaWVudCBnZW5lcmF0ZXMgbmV3IGtleSBLMiBvZiB0eXBlIFQyIGZvciBlVExE KzEgZXhhbXBsZS5jb208aHR0cDovL2V4YW1wbGUuY29tLz4sIG5vIG9yaWdpbi4gKEsxIGlzIGlu IHRoZSBrZXkgc3RvcmUgZm9yIGVUTEQrMSBleGFtcGxlLmNvbTxodHRwOi8vZXhhbXBsZS5jb20v Piwgb3JpZ2lucyBmb28uZXhhbXBsZS5jb208aHR0cDovL2Zvby5leGFtcGxlLmNvbS8+LCBiYXIu ZXhhbXBsZS5jb208aHR0cDovL2Jhci5leGFtcGxlLmNvbS8+LikNCjMuIENsaWVudCBzZW5kcyBT ZWMtVG9rZW4tQmluZGluZyBoZWFkZXIgd2l0aCBLMSBhbmQgSzIgYXMgcHJvdmlkZWQgdG9rZW4g YmluZGluZ3M7IHNlcnZlciByZXNwb25kcyB3aXRoIGEgMnh4IG9yIDN4eCByZXNwb25zZSBjb2Rl Lg0KNC4gQ2xpZW50IHVwZGF0ZXMga2V5IHN0b3JlIHNvIEsyIGhhcyBvcmlnaW4gZm9vLmV4YW1w bGUuY29tPGh0dHA6Ly9mb28uZXhhbXBsZS5jb20vPiBhbmQgSzEgbm8gbG9uZ2VyIGhhcyB0aGF0 IG9yaWdpbiAoaXQgb25seSBoYXMgYmFyLmV4YW1wbGUuY29tPGh0dHA6Ly9iYXIuZXhhbXBsZS5j b20vPiBsaXN0ZWQgYXMgaXRzIG9yaWdpbikuDQpOb3csIG9uIGZ1dHVyZSBjb25uZWN0aW9ucywg dGhlIGNsaWVudCBjYW4gc2VuZCBhIG5lZ290aWF0aW9uIGV4dGVuc2lvbiB3aXRoIChUMSwgZmFs c2UpLCAoVDIsIHRydWUpIHRvIGZvby5leGFtcGxlLmNvbTxodHRwOi8vZm9vLmV4YW1wbGUuY29t Lz4sIGFuZCBmb28uZXhhbXBsZS5jb208aHR0cDovL2Zvby5leGFtcGxlLmNvbS8+IHdpbGwgb25s eSBzZW5kIGJhY2sgVDIuDQpOb3RlIHRoYXQgd2hlbiB0aGUgY2xpZW50IGlzIGRlY2lkaW5nIHdo ZXRoZXIgb3Igbm90IHRvIGluZGljYXRlIGl0IGhhcyBhIGtleSBvZiBhIHBhcnRpY3VsYXIgdHlw ZSwgaXQgaXMgY2hlY2tpbmcgZm9yIGEga2V5IG9mIHRoYXQgdHlwZSBmb3IgdGhhdCBvcmlnaW4s IGFuZCBub3QgZm9yIHRoYXQgZVRMRCsxLg0KV2hlbiB0aGUgc2VydmVyIGNvbm5lY3RzIHRvIGJh ci5leGFtcGxlLmNvbTxodHRwOi8vYmFyLmV4YW1wbGUuY29tLz4sIGl0IGNvbnRpbnVlcyBhcyBm b2xsb3dzOg0KNS4gQ2xpZW50IHNlbmRzIG5lZ290aWF0aW9uIGV4dGVuc2lvbiB3aXRoIChUMSwg dHJ1ZSksIChUMiwgZmFsc2UpLCBhbmQgYmFyLmV4YW1wbGUuY29tPGh0dHA6Ly9iYXIuZXhhbXBs ZS5jb20vPiByZXNwb25kcyB3aXRoIFQyLCBUMS4NCjYuIENsaWVudCBzZW5kcyBTZWMtVG9rZW4t QmluZGluZyBoZWFkZXIgd2l0aCBLMSBhbmQgSzIgYXMgcHJvdmlkZWQgdG9rZW4gYmluZGluZ3M7 IHNlcnZlciByZXNwb25kcyB3aXRoIDJ4eCBvciAzeHggcmVzcG9uc2UgY29kZS4NCjcuIENsaWVu dCB1cGRhdGVzIGtleSBzdG9yZSB0byBhZGQgYmFyLmV4YW1wbGUuY29tPGh0dHA6Ly9iYXIuZXhh bXBsZS5jb20vPiBhcyBhbiBvcmlnaW4gZm9yIEsyLCBhbmQgcmVtb3ZlIGJhci5leGFtcGxlLmNv bTxodHRwOi8vYmFyLmV4YW1wbGUuY29tLz4gYXMgYW4gb3JpZ2luIGZvciBLMS4NCjguIENsaWVu dCBzZWVzIHRoYXQgSzEgaGFzIG5vIG1vcmUgb3JpZ2lucywgYW5kIHJlbW92ZXMgaXQgZnJvbSB0 aGUga2V5IHN0b3JlLg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KVW5iZWFyYWJsZUBpZXRmLm9yZzxt YWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdW5iZWFyYWJsZQ0KDQoNCg== --_000_CY1PR03MB2155E68DEA5EE81504D13DED8C1B0CY1PR03MB2155namp_ 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 bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE4Mzc5MjYzMDsNCgltc28t bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6ODc5OTA2MzcwIDM2ODcy ODY1NiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0 LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 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 LHNhbnMtc2VyaWYiPklzIHRoZSBhYmlsaXR5IHRvIHJlLWJpbmQgdG9rZW5zIHRvIGEgZGlmZmVy ZW50IGtleSB0eXBlIHdpdGhvdXQgcmVhdXRoZW50aWNhdGlvbiBhbiBpbXBvcnRhbnQgcmVxdWly ZW1lbnQ/IFRoaXMgaW5jcmVhc2VzIGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkgYW5kIGNvbXB1 dGF0aW9uYWwgY29zdA0KIChpZiBtdWx0aXBsZSBzaWduYXR1cmVzIGFyZSBpbnZvbHZlZCkgYW5k IHRoZXJlZm9yZSBpcyBub3Qgc3VwcG9ydGVkIGluIHRoZSBjdXJyZW50IHNwZWNzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5Oldp bmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9u dDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPldoZW4gdGhlIGNsaWVudCBpcyBjb25uZWN0aW5nIHRvIDxhIGhy ZWY9Imh0dHA6Ly9leGFtcGxlLmNvbSI+DQpleGFtcGxlLmNvbTwvYT4sIHNob3VsZCBpdCBsaXN0 IGp1c3QgUFNTIGluIGl0cyBleHRlbnNpb24sIG9yIGJvdGggUFNTIGFuZCBQMjU2PzxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5UaGUgY2xpZW50IGluZGljYXRlcyBhbGwgc3VwcG9ydGVkIFRCIHBhcmFt ZXRlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEg bGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SWYgdGhlIGNsaWVudCBsaXN0cyBQU1Mg Zm9sbG93ZWQgYnkgUDI1NiAodG8gaW5kaWNhdGUgdGhhdCB0aGUgY2xpZW50IHByZWZlcnMgUFNT LCBzaW5jZSB0aGV5IGFyZSBpbiBwcmVmZXJlbmNlIG9yZGVyKSwgYnV0IHRoZSBzZXJ2ZXIgcHJl ZmVycyBQMjU2IG92ZXIgUFNTLCBzaG91bGQgdGhlIHNlcnZlciBuZWdvdGlhdGUgUDI1NiBvciBQ U1M/PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkdlbmVyYWxseSwgdGhlIHNlcnZlciBzaG91bGQgdXNl IHRoZSBzZXJ2ZXLigJlzIHByZWZlcmVuY2VzLiBIb3dldmVyLCB0aGVyZSBtYXkgYmUgY29uZmln dXJhdGlvbnMgd2hlcmUgY2xpZW50IHByZWZlcmVuY2VzIGFyZSBob25vcmVkLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVW5iZWFyYWJsZSBbbWFp bHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Tmlj ayBIYXJwZXI8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgOCwgMjAxNiAxMTo1NCBB TTxicj4NCjxiPlRvOjwvYj4gQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBwaW5naWRlbnRp dHkuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gdW5iZWFyYWJsZUBpZXRmLm9yZzsgU3Vib2RoIEl5 ZW5nYXIgJmx0O3N1Ym9kaEBmYi5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVW5i ZWFyYWJsZV0gbWlncmF0aW9ucyBvZiB0b2tlbiBiaW5kaW5nczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkEgcmVsYXRlZCBpc3N1ZSB0byBtaWdyYXRpb24gaXMgd2hhdCBz aG91bGQgYSBjbGllbnQncyBiZWhhdmlvciBiZSBpZiBpdCBzdXBwb3J0cyBtdWx0aXBsZSBrZXkg dHlwZXMgd2hlbiBpdCBoYXMgb25lIGtleSB0aGF0IGl0IGNhbiB1c2Ugd2l0aCBhIHNlcnZlciBh bmQgaXMgZ2VuZXJhdGluZyBpdHMgbmVnb3RpYXRpb24gZXh0ZW5zaW9uLiBNb3JlIGNvbmNyZXRl bHksIHN1cHBvc2UgYSBjbGllbnQgc3VwcG9ydHMNCiBQU1MgYW5kIFAyNTYsIGFuZCBoYXMgYSBQ U1Mga2V5IGZvciA8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20iPmV4YW1wbGUuY29tPC9hPi4g V2hlbiB0aGUgY2xpZW50IGlzIGNvbm5lY3RpbmcgdG8NCjxhIGhyZWY9Imh0dHA6Ly9leGFtcGxl LmNvbSI+ZXhhbXBsZS5jb208L2E+LCBzaG91bGQgaXQgbGlzdCBqdXN0IFBTUyBpbiBpdHMgZXh0 ZW5zaW9uLCBvciBib3RoIFBTUyBhbmQgUDI1Nj8gSWYgdGhlIGNsaWVudCBsaXN0cyBQU1MgZm9s bG93ZWQgYnkgUDI1NiAodG8gaW5kaWNhdGUgdGhhdCB0aGUgY2xpZW50IHByZWZlcnMgUFNTLCBz aW5jZSB0aGV5IGFyZSBpbiBwcmVmZXJlbmNlIG9yZGVyKSwgYnV0IHRoZSBzZXJ2ZXIgcHJlZmVy cyBQMjU2DQogb3ZlciBQU1MsIHNob3VsZCB0aGUgc2VydmVyIG5lZ290aWF0ZSBQMjU2IG9yIFBT Uz8gSWYgdGhlIHNlcnZlciBuZWdvdGlhdGVzIFAyNTYsIGl0IGp1c3QgYnJva2UgdGhlIGJpbmRp bmcgaXQgaGFkIGZvciBhbnkgdG9rZW5zIGJlY2F1c2UgdGhlIGNsaWVudCBqdXN0IG1hZGUgYSBu ZXcga2V5LiBUaGlzIGNvdWxkIGJlIHZpZXdlZCBhcyB0aGUgb25lLXRpbWUgbWlncmF0aW9uIGNv c3QgKHdoaWNoIGlzIGEgcmVhc29uYWJsZSBjb3N0IGlmIGl0DQogaGFwcGVucyBvbmx5IG9uZSB0 aW1lKSwgYnV0IG5vdyBpbWFnaW5lIHRoYXQgPGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tIj5l eGFtcGxlLmNvbTwvYT4gaXMgc2VydmVkIGJ5IG11bHRpcGxlIHNlcnZlcnMgdGhhdCBhcmUgc2xv d2x5IHJvbGxpbmcgb3V0IHRoZSBwcmVmZXJlbmNlIGNoYW5nZSBvZiBwcmVmZXJyaW5nIFAyNTYg b3ZlciBQU1MsIGFuZCB0aGUgY2xpZW50IGlzIGJvdW5jaW5nIGJldHdlZW4gc2VydmVycyB0aGF0 IHByZWZlciBvbmUNCiBvdmVyIHRoZSBvdGhlci4gTm93IHRoaXMgJnF1b3Q7b25lLXRpbWUmcXVv dDsgbWlncmF0aW9uIGhhcHBlbnMgZXZlcnkgdGltZSB0aGUgY2xpZW50IGhpdHMgYSBzZXJ2ZXIg dGhhdCBoYXMgYSBkaWZmZXJlbnQgcHJlZmVyZW5jZSBsaXN0IGNvbXBhcmVkIHRvIHRoZSBwcmV2 aW91cyBzZXJ2ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBNb24sIEF1ZyA4LCAyMDE2IGF0IDExOjQwIEFNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdCI+SSBndWVzcyB0aGUgcXVlc3Rpb24gdGhhdCBjb21lcyB0byBt eSBtaW5kIGlzIHdoZXRoZXIga2V5IG1pZ3JhdGlvbiBpcyBzb21ldGhpbmcgdGhhdCByZWFsbHkg bmVlZHMgdG8gYmUgYWNjb21tb2RhdGVkIGJ5IHRoZSBwcm90b2NvbC4NCjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgb2Z0ZW4gd2lsbCBpdCByZWFsbHkg aGFwcGVuPyBBIG5ldyBrZXlfcGFyYW1ldGVycyB0eXBlIG1pZ2h0IGJlIGludHJvZHVjZWQgZXZl cnkgZmV3IHllYXJzIGF0IHRoZSBtb3N0LiBBbmQgZXZlbiBpZiBhIGNsaWVudCB3ZXJlIHRvIGV4 cGxpY2l0bHkgZGlzY2FyZCAnb2xkJyBlc3RhYmxpc2hlZCBiaW5kaW5ncyB0byBmb3JjZSBhIGNo YW5nZSwgdGhlIGltcGFjdCBpcyBubyB3b3JzZSB0aGFuIGEgdXNlcg0KIGNob29zaW5nIHRvIGNs ZWFyIGNvb2tpZXMuIFRoZSBhdXRoZW50aWNhdGlvbiBjb250ZXh0IGp1c3QgaGFzIHRvIGJlIHJl ZXN0YWJsaXNoZWQgKGxvZyBpbiBhZ2FpbikuICZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVnIDMsIDIw MTYgYXQgNzowNCBQTSwgTmljayBIYXJwZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpuaGFycGVyQGdv b2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5uaGFycGVyQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuNXB0Ij5JIGNoYXR0ZWQgd2l0aCBTdWJvZGggb2ZmbGluZSBhYm91dCBo b3cgdG8gZG8ga2V5IG1pZ3JhdGlvbnMgZm9yIFRva2VuIEJpbmRpbmcuIFdlIGNhbWUgdXAgd2l0 aCB0aGUgZm9sbG93aW5nIGFzIGEgcG90ZW50aWFsIGNoYW5nZSB0byBiZSBhYmxlIHRvIHN1cHBv cnQgbWlncmF0aW5nIGZyb20gb25lIGtleSB0eXBlIHRvIGFub3RoZXIuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+ V2hlbiBhIGNsaWVudCBzZW5kcyB0aGUgVG9rZW4gQmluZGluZyBuZWdvdGlhdGlvbiBUTFMgZXh0 ZW5zaW9uLCBpdCBpbmNsdWRlcyB3aXRoIGVhY2gga2V5IHR5cGUgd2hldGhlciBvciBub3QgaXQg aGFzIGEga2V5IG9mIHRoYXQgdHlwZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5VcG9uIHJlY2VpcHQgb2YgdGhh dCBleHRlbnNpb24sIHRoZSBzZXJ2ZXIgY29uc3VsdHMgaXRzIGxpc3Qgb2Ygc3VwcG9ydGVkIGtl eSB0eXBlcyBpbiBwcmVmZXJlbmNlIG9yZGVyIChhbmQgZmlsdGVycyBpdCBiYXNlZCBvbiB3aGF0 IHRoZSBjbGllbnQgc2VudCkuIFRoZSBzZXJ2ZXIgcHV0cyBvbmUgb3IgdHdvIHZhbHVlcyBpbiBp dHMga2V5X3BhcmFtZXRlcnNfbGlzdDoNCiBUaGUga2V5IHR5cGUgYXQgdGhlIHRvcCBvZiB0aGUg ZmlsdGVyZWQgbGlzdCwgYW5kIHRoZSBoaWdoZXN0IGtleSB0eXBlIG9uIHRoZSBmaWx0ZXJlZCBs aXN0IHRoYXQgYSBjbGllbnQgaGFzIGEga2V5IGZvciAodGhlc2Ugd2lsbCBiZSB0aGUgc2FtZSB0 aGluZyBpbiBtb3N0IGNhc2VzLCBpbiB3aGljaCBjYXNlIHRoZSBzZXJ2ZXIgc2VuZHMgb25seSBv bmUgdmFsdWUpLiBJZiB0aGUgc2VydmVyIHNlbmRzIHR3byB2YWx1ZXMsIGl0IG11c3QgZG8NCiBz byBpbiB0aGlzIG9yZGVyICh0byBpbmRpY2F0ZSB0byB0aGUgY2xpZW50IHdoYXQgdGhlIHNlcnZl cidzIHByZWZlcmVuY2UgaXMpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPldoZW4gYSBjbGllbnQgcmVjZWl2ZXMg dHdvIHZhbHVlcyBpbiB0aGUga2V5X3BhcmFtZXRlcnNfbGlzdCBmcm9tIHRoZSBzZXJ2ZXIsIHRo ZSBjbGllbnQgZ2VuZXJhdGVzIGEgVG9rZW5CaW5kaW5nTWVzc2FnZSB3aXRoIHR3byBwcm92aWRl ZCBUb2tlbkJpbmRpbmdzLiAoVGhpcyBtZWFucyB0aGF0IHRoZSBjbGllbnQgaXMgZ2VuZXJhdGlu ZyBhIG5ldyBrZXlwYWlyDQogZm9yIG9uZSBvZiB0aGUgdG9rZW4gYmluZGluZ3MuKSBPbmNlIHRo ZSBjbGllbnQgcmVjZWl2ZXMgYSBzdWNjZXNzZnVsIHJlc3BvbnNlIHRvIHRoZSBhcHBsaWNhdGlv biBsYXllciByZXF1ZXN0IHRoYXQgY29udGFpbmVkIHRoYXQgVG9rZW5CaW5kaW5nTWVzc2FnZSAo ZS5nLiBhIDJ4eCBvciAzeHggSFRUUCByZXNwb25zZSBmb3IgYSByZXF1ZXN0IHdpdGggYSBTZWMt VG9rZW4tQmluZGluZyBoZWFkZXIpLCB0aGUgY2xpZW50IG1heSBkaXNjYXJkDQogdGhlIGtleSBv ZiB0aGUgdHlwZSB0aGF0IHdhcyBub3QgZmlyc3QgaW4gdGhlIHNlcnZlcidzIGtleV9wYXJhbWV0 ZXJzX2xpc3QuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+V2hlbiBhIHNlcnZlciByZWNlaXZlcyBhIFRva2VuQmlu ZGluZ01lc3NhZ2Ugd2l0aCB0d28gcHJvdmlkZWQgVG9rZW5CaW5kaW5ncywgaXQgbXVzdCByZWJp bmQgdGhlIHRva2VucyBzZW50IGJ5IHRoZSBjbGllbnQgdG8gYmUgYm91bmQgdG8gdGhlIG5ldyBr ZXkgKHRoaXMgaXMgaWRlbnRpZmllZCBhcyB0aGUga2V5IG9mIHRoZSB0eXBlIHRoYXQgdGhlIHNl cnZlcg0KIGhhcyByYW5rZWQgaGlnaGVyIG9uIGl0cyBwcmVmZXJlbmNlIGxpc3QpLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQiPlRoZXJlIGlzIGFsc28gc29tZSBpbXBsZW1lbnRhdGlvbiBndWlkYW5jZSBmb3IgY2xp ZW50IEhUVFBTIFRva2VuIEJpbmRpbmcgaW1wbGVtZW50YXRpb25zLiBTaW5jZSB0aGUgc2FtZSBU b2tlbiBCaW5kaW5nIGtleSBpcyB1c2VkIGZvciBhbGwgb3JpZ2lucyBvbiBhbiBlVExEJiM0Mzsx LCBidXQgYSByZXF1ZXN0IHRvIG9uZSBvcmlnaW4gbWlnaHQgb25seSBjb250YWluDQogc29tZSBv ZiB0aGUgdG9rZW5zIG9uIHRoYXQgZVRMRCYjNDM7MSwgdGhlIGNsaWVudCBuZWVkcyB0byBrZWVw IHRyYWNrIG9mIHdoaWNoIGtleXMgZm9yIHRoZSBlVExEJiM0MzsxIGFyZSB1c2VkIG9uIHdoaWNo IG9yaWdpbnMsIGFuZCBtYWtlIHN1cmUgdGhhdCBhIGtleSBpcyBub3QgZGlzY2FyZGVkIHVudGls IGl0IGlzIG5vIGxvbmdlciB1c2VkIG9uIGFueSBvZiB0aGUgb3JpZ2lucyBmb3IgdGhhdCBlVExE JiM0MzsxLiBGdXJ0aGVybW9yZSwgaWYgYSBrZXkgb2YgYQ0KIHR5cGUgVCBmb3IgYW4gZVRMRCYj NDM7MSBoYXMgbmV2ZXIgYmVlbiBwcmVzZW50ZWQgdG8gYSBwYXJ0aWN1bGFyIG9yaWdpbiBpbiB0 aGF0IGVUTEQmIzQzOzEsIHRoZSBjbGllbnQgbXVzdCBub3QgaW5kaWNhdGUgdGhhdCBpdCBoYXMg YSBrZXkgb2YgdHlwZSBUIGluIHRoZSBuZWdvdGlhdGlvbiBleHRlbnNpb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVw dCI+VGhpcyBjbGllbnQgc2lkZSBjb21wbGljYXRpb24gaXMgdG8gaGFuZGxlIHRoZSBzY2VuYXJp byBvZiBtdWx0aXBsZSBzdWJkb21haW5zIG9uIGFuIGVUTEQmIzQzOzEgd2hpY2ggaGF2ZSBkaWZm ZXJlbnQgY29va2llcy4gQ29uc2lkZXIgYSBjbGllbnQgYW5kIHNlcnZlciB0aGF0IHN1cHBvcnQg a2V5IHR5cGVzIFQxIGFuZCBUMiAod2l0aCBUMiBwcmVmZXJyZWQgb3Zlcg0KIFQxKSwgYW5kIGEg Y2xpZW50IHRoYXQgY3VycmVudGx5IG9ubHkgaGFzIGtleSBLMSAob2YgdHlwZSBUMSkgZm9yIG11 bHRpcGxlIGRvbWFpbnMgb24gdGhhdCBzZXJ2ZXIuIFRoZSBjbGllbnQgYW5kIHNlcnZlciBib3Ro IHdpc2ggdG8gbWlncmF0ZSB0byBhIG5ldyBrZXkgSzIgb2YgdHlwZSBUMi4gSW4gdGhpcyBleGFt cGxlLCB0aGUgc2VydmVyIHJ1bnMmbmJzcDs8YSBocmVmPSJodHRwOi8vZm9vLmV4YW1wbGUuY29t LyIgdGFyZ2V0PSJfYmxhbmsiPmZvby5leGFtcGxlLmNvbTwvYT4mbmJzcDthbmQmbmJzcDs8YSBo cmVmPSJodHRwOi8vYmFyLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPmJhci5leGFtcGxl LmNvbTwvYT4sDQogd2hpY2ggaGF2ZSBkaWZmZXJlbnQgY29va2llcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0Ij4xLiBDbGllbnQgc2VuZHMgbmVnb3RpYXRpb24gZXh0ZW5zaW9uIHdp dGggKFQxLCB0cnVlKSBhbmQgKFQyLCBmYWxzZSkgd2hlbiBjb25uZWN0aW5nIHRvJm5ic3A7PGEg aHJlZj0iaHR0cDovL2Zvby5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5mb28uZXhhbXBs ZS5jb208L2E+LiBTZXJ2ZXIgcmVzcG9uZHMgd2l0aCBUMiwgVDEuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjVwdCI+Mi4gQ2xpZW50IGdlbmVyYXRlcyBuZXcga2V5IEsyIG9mIHR5cGUgVDIg Zm9yIGVUTEQmIzQzOzEmbmJzcDs8YSBocmVmPSJodHRwOi8vZXhhbXBsZS5jb20vIiB0YXJnZXQ9 Il9ibGFuayI+ZXhhbXBsZS5jb208L2E+LCBubyBvcmlnaW4uIChLMSBpcyBpbiB0aGUga2V5IHN0 b3JlIGZvciBlVExEJiM0MzsxJm5ic3A7PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tLyIgdGFy Z2V0PSJfYmxhbmsiPmV4YW1wbGUuY29tPC9hPiwNCiBvcmlnaW5zJm5ic3A7PGEgaHJlZj0iaHR0 cDovL2Zvby5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5mb28uZXhhbXBsZS5jb208L2E+ LCZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9iYXIuZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+ YmFyLmV4YW1wbGUuY29tPC9hPi4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+My4g Q2xpZW50IHNlbmRzIFNlYy1Ub2tlbi1CaW5kaW5nIGhlYWRlciB3aXRoIEsxIGFuZCBLMiBhcyBw cm92aWRlZCB0b2tlbiBiaW5kaW5nczsgc2VydmVyIHJlc3BvbmRzIHdpdGggYSAyeHggb3IgM3h4 IHJlc3BvbnNlIGNvZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+NC4gQ2xpZW50 IHVwZGF0ZXMga2V5IHN0b3JlIHNvIEsyIGhhcyBvcmlnaW4mbmJzcDs8YSBocmVmPSJodHRwOi8v Zm9vLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPmZvby5leGFtcGxlLmNvbTwvYT4mbmJz cDthbmQgSzEgbm8gbG9uZ2VyIGhhcyB0aGF0IG9yaWdpbiAoaXQgb25seSBoYXMmbmJzcDs8YSBo cmVmPSJodHRwOi8vYmFyLmV4YW1wbGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPmJhci5leGFtcGxl LmNvbTwvYT4mbmJzcDtsaXN0ZWQNCiBhcyBpdHMgb3JpZ2luKS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuNXB0Ij5Ob3csIG9uIGZ1dHVyZSBjb25uZWN0aW9ucywgdGhlIGNsaWVudCBjYW4g c2VuZCBhIG5lZ290aWF0aW9uIGV4dGVuc2lvbiB3aXRoIChUMSwgZmFsc2UpLCAoVDIsIHRydWUp IHRvJm5ic3A7PGEgaHJlZj0iaHR0cDovL2Zvby5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5r Ij5mb28uZXhhbXBsZS5jb208L2E+LCBhbmQmbmJzcDs8YSBocmVmPSJodHRwOi8vZm9vLmV4YW1w bGUuY29tLyIgdGFyZ2V0PSJfYmxhbmsiPmZvby5leGFtcGxlLmNvbTwvYT4mbmJzcDt3aWxsDQog b25seSBzZW5kIGJhY2sgVDIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+Tm90ZSB0 aGF0IHdoZW4gdGhlIGNsaWVudCBpcyBkZWNpZGluZyB3aGV0aGVyIG9yIG5vdCB0byBpbmRpY2F0 ZSBpdCBoYXMgYSBrZXkgb2YgYSBwYXJ0aWN1bGFyIHR5cGUsIGl0IGlzIGNoZWNraW5nIGZvciBh IGtleSBvZiB0aGF0IHR5cGUgZm9yIHRoYXQgb3JpZ2luLCBhbmQgbm90IGZvciB0aGF0IGVUTEQm IzQzOzEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+V2hlbiB0aGUgc2VydmVyIGNv bm5lY3RzIHRvJm5ic3A7PGEgaHJlZj0iaHR0cDovL2Jhci5leGFtcGxlLmNvbS8iIHRhcmdldD0i X2JsYW5rIj5iYXIuZXhhbXBsZS5jb208L2E+LCBpdCBjb250aW51ZXMgYXMgZm9sbG93czo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij41LiBDbGllbnQgc2VuZHMgbmVnb3RpYXRpb24g ZXh0ZW5zaW9uIHdpdGggKFQxLCB0cnVlKSwgKFQyLCBmYWxzZSksIGFuZCZuYnNwOzxhIGhyZWY9 Imh0dHA6Ly9iYXIuZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+YmFyLmV4YW1wbGUuY29t PC9hPiZuYnNwO3Jlc3BvbmRzIHdpdGggVDIsIFQxLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS41cHQiPjYuIENsaWVudCBzZW5kcyBTZWMtVG9rZW4tQmluZGluZyBoZWFkZXIgd2l0aCBLMSBh bmQgSzIgYXMgcHJvdmlkZWQgdG9rZW4gYmluZGluZ3M7IHNlcnZlciByZXNwb25kcyB3aXRoIDJ4 eCBvciAzeHggcmVzcG9uc2UgY29kZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij43 LiBDbGllbnQgdXBkYXRlcyBrZXkgc3RvcmUgdG8gYWRkJm5ic3A7PGEgaHJlZj0iaHR0cDovL2Jh ci5leGFtcGxlLmNvbS8iIHRhcmdldD0iX2JsYW5rIj5iYXIuZXhhbXBsZS5jb208L2E+Jm5ic3A7 YXMgYW4gb3JpZ2luIGZvciBLMiwgYW5kIHJlbW92ZSZuYnNwOzxhIGhyZWY9Imh0dHA6Ly9iYXIu ZXhhbXBsZS5jb20vIiB0YXJnZXQ9Il9ibGFuayI+YmFyLmV4YW1wbGUuY29tPC9hPiZuYnNwO2Fz DQogYW4gb3JpZ2luIGZvciBLMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij44LiBD bGllbnQgc2VlcyB0aGF0IEsxIGhhcyBubyBtb3JlIG9yaWdpbnMsIGFuZCByZW1vdmVzIGl0IGZy b20gdGhlIGtleSBzdG9yZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpVbmJlYXJhYmxl QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Vu YmVhcmFibGU8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR03MB2155E68DEA5EE81504D13DED8C1B0CY1PR03MB2155namp_-- From nobody Mon Aug 8 12:22:48 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 E261612D5EB for ; Mon, 8 Aug 2016 12:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.09 X-Spam-Level: * X-Spam-Status: No, score=1.09 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URI_HEX=1.122] autolearn=no 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 EJECWNTuARv5 for ; Mon, 8 Aug 2016 12:22:25 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0101.outbound.protection.outlook.com [104.47.42.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E67C12B058 for ; Mon, 8 Aug 2016 12:22:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ATyeArB91VDkxD1Sb+Ie17a8bDBiqHHiuRPhRITVS/k=; b=CQ93Vx5d14S54J6jQTpKO9ATzthHBY2LEHbno+0PvYqPEOzQSVXB6xcmSLQ383Xts6wP2OU2Ll8iM7CmFuxhCNrap+fwcONcs1JF0kFjEufY/RvLnOCZIXgLVIMimgdw7dB1gpOUZ4rRlyER3om5fi8cSp9SWNFYC8JXcdR6hWE= Received: from DM5PR03MB2441.namprd03.prod.outlook.com (10.168.233.11) by SN2PR03MB2159.namprd03.prod.outlook.com (10.166.209.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 8 Aug 2016 19:22:21 +0000 Received: from DM5PR03MB2441.namprd03.prod.outlook.com ([10.168.233.11]) by DM5PR03MB2441.namprd03.prod.outlook.com ([10.168.233.11]) with mapi id 15.01.0549.025; Mon, 8 Aug 2016 19:22:21 +0000 From: Anthony Nadalin To: Andrei Popov , Nick Harper , Brian Campbell Thread-Topic: [Unbearable] migrations of token bindings Thread-Index: AdHtGANk8YhqkfT0RKqstDH3Uk+wIQABbhaAAABcF4AAAJzCgAABd/UAADEmigAA7g84gAAAdPkAAACM+pAAAG7O8A== Date: Mon, 8 Aug 2016 19:22:21 +0000 Message-ID: References: <974CF78E8475CD4CA398B1FCA21C8E99565A9DF7@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9EB0@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9F26@PRN-MBX01-4.TheFacebook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [2001:4898:80e8:d::4d0] x-ms-office365-filtering-correlation-id: 94a0e083-fef7-4e12-42f0-08d3bfc15212 x-microsoft-exchange-diagnostics: 1; SN2PR03MB2159; 6:9jiqmXGrVw7S7iiHZiIbmHy9ArzuxmcO9xCXaYN30MZDfDaNPHvgdAl633xguYRLkj3PSVMgIXyiahxY/+qF5y1hD5i/+8xyhkBkjEn1QJYB2Icp3d6SvaO1HjWWaMC56EpuCeNtOLIAoh+Gq++syxRYuQqifs5dNwCMs8dUBWarDbOv7Zk1Dk6mGxkL8N8ukhXTPeI/bbv/vDJ9r6ttOawLkO8JAhYSqVWLHdySNuNKsnbXvzj1TaYtsohl+eP7GGTqInbzXxW6ltvf03APVTFH/QHMGLcCIz9/2pTjPWVfs6ypJSPzwssxTAXnySxQEcXabMHim9VJC8fEjkEFPw==; 5:Ek1MUMFvQrqZ2OgT2TdFd8C9XNmJzN3YHWUcG6i9HdqmB4PxHJsJSQNO2ILuVZrnLcIaTg8hVTlLA+z/hNhFoTD5G1gOFHU8BVpLP1RoFnoFZkFx8GdiUCc1eq7YNzqPbkV+Acxna5efJ9FTLXJiuw==; 24:WaDA2w6bgzgDf8JikmeRzHoOKGZXoWJ6N1e/v5YZIZcVh9W7qZALb4KNPDmWFCMQZvd2Bjzl/fzsVzFr7OYsL8g5NQJ3ZpJaMBIIkcfgOo8=; 7:LpKWYGhq+ke4f1oGuoWRR0B7PEnhtXLi4wEAd3bwOYbAYWblOq5AtlzcLlidOC6uve/C8O+dFp5glCteESgZuNLpfB5ACbRWughgjtQSEOqBKPK8CNpKXVZA9ieTiM5J9AIg4RmMxZOpdOur/VDRu/66Gm/2MLXq35ad1zFsrrG2VieH9QDfFAZ8mzQcBlBzAvAcCfvwkL4zTUsjuLH5g8K3x8LvOzp8+bmX9gcBr8Yh/4zFcS9IU5/41slXV8SA x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR03MB2159; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(189930954265078)(67672495146484)(211936372134217)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN2PR03MB2159; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2159; x-forefront-prvs: 00286C0CA6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(24454002)(377454003)(105586002)(54356999)(76176999)(50986999)(122556002)(97736004)(5001770100001)(101416001)(19625215002)(68736007)(7696003)(7736002)(7906003)(2421001)(19617315012)(6116002)(189998001)(5002640100001)(7846002)(1511001)(790700001)(19580405001)(19300405004)(19580395003)(19609705001)(8676002)(2906002)(33656002)(8936002)(16236675004)(102836003)(106356001)(4326007)(99286002)(2561002)(74316002)(10090500001)(81166006)(76576001)(86612001)(586003)(5005710100001)(77096005)(9686002)(86362001)(87936001)(92566002)(93886004)(3660700001)(15975445007)(3280700002)(10400500002)(11100500001)(10290500002)(81156014)(2950100001)(2900100001)(8990500004)(3826002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR03MB2159; H:DM5PR03MB2441.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR03MB244123682F06D67E4ED0E083A61B0DM5PR03MB2441namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2016 19:22:21.3181 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2159 Archived-At: Cc: "unbearable@ietf.org" , Subodh Iyengar Subject: Re: [Unbearable] migrations of token bindings 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, 08 Aug 2016 19:22:30 -0000 X-List-Received-Date: Mon, 08 Aug 2016 19:22:30 -0000 --_000_DM5PR03MB244123682F06D67E4ED0E083A61B0DM5PR03MB2441namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q3VycmVudGx5IHdlIGhhdmUgbm8gcmVxdWlyZW1lbnRzIGZvciB0aGlzIGZlYXR1cmUuDQoNCkZy b206IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBBbmRyZWkgUG9wb3YNClNlbnQ6IE1vbmRheSwgQXVndXN0IDgsIDIwMTYgMTI6MTgg UE0NClRvOiBOaWNrIEhhcnBlciA8bmhhcnBlckBnb29nbGUuY29tPjsgQnJpYW4gQ2FtcGJlbGwg PGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPg0KQ2M6IHVuYmVhcmFibGVAaWV0Zi5vcmc7IFN1 Ym9kaCBJeWVuZ2FyIDxzdWJvZGhAZmIuY29tPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBt aWdyYXRpb25zIG9mIHRva2VuIGJpbmRpbmdzDQoNCklzIHRoZSBhYmlsaXR5IHRvIHJlLWJpbmQg dG9rZW5zIHRvIGEgZGlmZmVyZW50IGtleSB0eXBlIHdpdGhvdXQgcmVhdXRoZW50aWNhdGlvbiBh biBpbXBvcnRhbnQgcmVxdWlyZW1lbnQ/IFRoaXMgaW5jcmVhc2VzIGltcGxlbWVudGF0aW9uIGNv bXBsZXhpdHkgYW5kIGNvbXB1dGF0aW9uYWwgY29zdCAoaWYgbXVsdGlwbGUgc2lnbmF0dXJlcyBh cmUgaW52b2x2ZWQpIGFuZCB0aGVyZWZvcmUgaXMgbm90IHN1cHBvcnRlZCBpbiB0aGUgY3VycmVu dCBzcGVjcy4NCg0KDQrDmCAgV2hlbiB0aGUgY2xpZW50IGlzIGNvbm5lY3RpbmcgdG8gZXhhbXBs ZS5jb208aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9 aHR0cCUzYSUyZiUyZmV4YW1wbGUuY29tJmRhdGE9MDIlN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3Nv ZnQuY29tJTdjYjI0MTM1NmYxMzMzNGIwYjBiY2MwOGQzYmZjMGFlNjElN2M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3YzElN2MwJTdjNjM2MDYyODA2Njc2ODk2MjAxJnNkYXRhPSUy ZktOY3o3WXlSdDJyb2NQYiUyYjAwSlhqc0wxdUJJdTVCT1lQVUNPbXRaVyUyYkUlM2Q+LCBzaG91 bGQgaXQgbGlzdCBqdXN0IFBTUyBpbiBpdHMgZXh0ZW5zaW9uLCBvciBib3RoIFBTUyBhbmQgUDI1 Nj8NClRoZSBjbGllbnQgaW5kaWNhdGVzIGFsbCBzdXBwb3J0ZWQgVEIgcGFyYW1ldGVycy4NCg0K DQrDmCAgSWYgdGhlIGNsaWVudCBsaXN0cyBQU1MgZm9sbG93ZWQgYnkgUDI1NiAodG8gaW5kaWNh dGUgdGhhdCB0aGUgY2xpZW50IHByZWZlcnMgUFNTLCBzaW5jZSB0aGV5IGFyZSBpbiBwcmVmZXJl bmNlIG9yZGVyKSwgYnV0IHRoZSBzZXJ2ZXIgcHJlZmVycyBQMjU2IG92ZXIgUFNTLCBzaG91bGQg dGhlIHNlcnZlciBuZWdvdGlhdGUgUDI1NiBvciBQU1M/DQpHZW5lcmFsbHksIHRoZSBzZXJ2ZXIg c2hvdWxkIHVzZSB0aGUgc2VydmVy4oCZcyBwcmVmZXJlbmNlcy4gSG93ZXZlciwgdGhlcmUgbWF5 IGJlIGNvbmZpZ3VyYXRpb25zIHdoZXJlIGNsaWVudCBwcmVmZXJlbmNlcyBhcmUgaG9ub3JlZC4N Cg0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE5pY2sgSGFycGVyDQpTZW50OiBNb25kYXksIEF1Z3VzdCA4LCAyMDE2IDEx OjU0IEFNDQpUbzogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1h aWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+DQpDYzogdW5iZWFyYWJsZUBpZXRmLm9y ZzxtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZz47IFN1Ym9kaCBJeWVuZ2FyIDxzdWJvZGhAZmIu Y29tPG1haWx0bzpzdWJvZGhAZmIuY29tPj4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gbWln cmF0aW9ucyBvZiB0b2tlbiBiaW5kaW5ncw0KDQpBIHJlbGF0ZWQgaXNzdWUgdG8gbWlncmF0aW9u IGlzIHdoYXQgc2hvdWxkIGEgY2xpZW50J3MgYmVoYXZpb3IgYmUgaWYgaXQgc3VwcG9ydHMgbXVs dGlwbGUga2V5IHR5cGVzIHdoZW4gaXQgaGFzIG9uZSBrZXkgdGhhdCBpdCBjYW4gdXNlIHdpdGgg YSBzZXJ2ZXIgYW5kIGlzIGdlbmVyYXRpbmcgaXRzIG5lZ290aWF0aW9uIGV4dGVuc2lvbi4gTW9y ZSBjb25jcmV0ZWx5LCBzdXBwb3NlIGEgY2xpZW50IHN1cHBvcnRzIFBTUyBhbmQgUDI1NiwgYW5k IGhhcyBhIFBTUyBrZXkgZm9yIGV4YW1wbGUuY29tPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZleGFtcGxlLmNvbSZkYXRhPTAy JTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2IyNDEzNTZmMTMzMzRiMGIwYmNjMDhk M2JmYzBhZTYxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJTdjMCU3YzYz NjA2MjgwNjY3Njg5NjIwMSZzZGF0YT0lMmZLTmN6N1l5UnQycm9jUGIlMmIwMEpYanNMMXVCSXU1 Qk9ZUFVDT210WlclMmJFJTNkPi4gV2hlbiB0aGUgY2xpZW50IGlzIGNvbm5lY3RpbmcgdG8gZXhh bXBsZS5jb208aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cCUzYSUyZiUyZmV4YW1wbGUuY29tJmRhdGE9MDIlN2MwMSU3Y3RvbnluYWQlNDBtaWNy b3NvZnQuY29tJTdjYjI0MTM1NmYxMzMzNGIwYjBiY2MwOGQzYmZjMGFlNjElN2M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzElN2MwJTdjNjM2MDYyODA2Njc2ODk2MjAxJnNkYXRh PSUyZktOY3o3WXlSdDJyb2NQYiUyYjAwSlhqc0wxdUJJdTVCT1lQVUNPbXRaVyUyYkUlM2Q+LCBz aG91bGQgaXQgbGlzdCBqdXN0IFBTUyBpbiBpdHMgZXh0ZW5zaW9uLCBvciBib3RoIFBTUyBhbmQg UDI1Nj8gSWYgdGhlIGNsaWVudCBsaXN0cyBQU1MgZm9sbG93ZWQgYnkgUDI1NiAodG8gaW5kaWNh dGUgdGhhdCB0aGUgY2xpZW50IHByZWZlcnMgUFNTLCBzaW5jZSB0aGV5IGFyZSBpbiBwcmVmZXJl bmNlIG9yZGVyKSwgYnV0IHRoZSBzZXJ2ZXIgcHJlZmVycyBQMjU2IG92ZXIgUFNTLCBzaG91bGQg dGhlIHNlcnZlciBuZWdvdGlhdGUgUDI1NiBvciBQU1M/IElmIHRoZSBzZXJ2ZXIgbmVnb3RpYXRl cyBQMjU2LCBpdCBqdXN0IGJyb2tlIHRoZSBiaW5kaW5nIGl0IGhhZCBmb3IgYW55IHRva2VucyBi ZWNhdXNlIHRoZSBjbGllbnQganVzdCBtYWRlIGEgbmV3IGtleS4gVGhpcyBjb3VsZCBiZSB2aWV3 ZWQgYXMgdGhlIG9uZS10aW1lIG1pZ3JhdGlvbiBjb3N0ICh3aGljaCBpcyBhIHJlYXNvbmFibGUg Y29zdCBpZiBpdCBoYXBwZW5zIG9ubHkgb25lIHRpbWUpLCBidXQgbm93IGltYWdpbmUgdGhhdCBl eGFtcGxlLmNvbTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwJTNhJTJmJTJmZXhhbXBsZS5jb20mZGF0YT0wMiU3YzAxJTdjdG9ueW5hZCU0MG1p Y3Jvc29mdC5jb20lN2NiMjQxMzU2ZjEzMzM0YjBiMGJjYzA4ZDNiZmMwYWU2MSU3YzcyZjk4OGJm ODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSU3YzAlN2M2MzYwNjI4MDY2NzY4OTYyMDEmc2Rh dGE9JTJmS05jejdZeVJ0MnJvY1BiJTJiMDBKWGpzTDF1Qkl1NUJPWVBVQ09tdFpXJTJiRSUzZD4g aXMgc2VydmVkIGJ5IG11bHRpcGxlIHNlcnZlcnMgdGhhdCBhcmUgc2xvd2x5IHJvbGxpbmcgb3V0 IHRoZSBwcmVmZXJlbmNlIGNoYW5nZSBvZiBwcmVmZXJyaW5nIFAyNTYgb3ZlciBQU1MsIGFuZCB0 aGUgY2xpZW50IGlzIGJvdW5jaW5nIGJldHdlZW4gc2VydmVycyB0aGF0IHByZWZlciBvbmUgb3Zl ciB0aGUgb3RoZXIuIE5vdyB0aGlzICJvbmUtdGltZSIgbWlncmF0aW9uIGhhcHBlbnMgZXZlcnkg dGltZSB0aGUgY2xpZW50IGhpdHMgYSBzZXJ2ZXIgdGhhdCBoYXMgYSBkaWZmZXJlbnQgcHJlZmVy ZW5jZSBsaXN0IGNvbXBhcmVkIHRvIHRoZSBwcmV2aW91cyBzZXJ2ZXIuDQoNCk9uIE1vbiwgQXVn IDgsIDIwMTYgYXQgMTE6NDAgQU0sIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3cm90ZToNCkkgZ3Vl c3MgdGhlIHF1ZXN0aW9uIHRoYXQgY29tZXMgdG8gbXkgbWluZCBpcyB3aGV0aGVyIGtleSBtaWdy YXRpb24gaXMgc29tZXRoaW5nIHRoYXQgcmVhbGx5IG5lZWRzIHRvIGJlIGFjY29tbW9kYXRlZCBi eSB0aGUgcHJvdG9jb2wuDQpIb3cgb2Z0ZW4gd2lsbCBpdCByZWFsbHkgaGFwcGVuPyBBIG5ldyBr ZXlfcGFyYW1ldGVycyB0eXBlIG1pZ2h0IGJlIGludHJvZHVjZWQgZXZlcnkgZmV3IHllYXJzIGF0 IHRoZSBtb3N0LiBBbmQgZXZlbiBpZiBhIGNsaWVudCB3ZXJlIHRvIGV4cGxpY2l0bHkgZGlzY2Fy ZCAnb2xkJyBlc3RhYmxpc2hlZCBiaW5kaW5ncyB0byBmb3JjZSBhIGNoYW5nZSwgdGhlIGltcGFj dCBpcyBubyB3b3JzZSB0aGFuIGEgdXNlciBjaG9vc2luZyB0byBjbGVhciBjb29raWVzLiBUaGUg YXV0aGVudGljYXRpb24gY29udGV4dCBqdXN0IGhhcyB0byBiZSByZWVzdGFibGlzaGVkIChsb2cg aW4gYWdhaW4pLg0KDQpPbiBXZWQsIEF1ZyAzLCAyMDE2IGF0IDc6MDQgUE0sIE5pY2sgSGFycGVy IDxuaGFycGVyQGdvb2dsZS5jb208bWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbT4+IHdyb3RlOg0K SSBjaGF0dGVkIHdpdGggU3Vib2RoIG9mZmxpbmUgYWJvdXQgaG93IHRvIGRvIGtleSBtaWdyYXRp b25zIGZvciBUb2tlbiBCaW5kaW5nLiBXZSBjYW1lIHVwIHdpdGggdGhlIGZvbGxvd2luZyBhcyBh IHBvdGVudGlhbCBjaGFuZ2UgdG8gYmUgYWJsZSB0byBzdXBwb3J0IG1pZ3JhdGluZyBmcm9tIG9u ZSBrZXkgdHlwZSB0byBhbm90aGVyLg0KDQpXaGVuIGEgY2xpZW50IHNlbmRzIHRoZSBUb2tlbiBC aW5kaW5nIG5lZ290aWF0aW9uIFRMUyBleHRlbnNpb24sIGl0IGluY2x1ZGVzIHdpdGggZWFjaCBr ZXkgdHlwZSB3aGV0aGVyIG9yIG5vdCBpdCBoYXMgYSBrZXkgb2YgdGhhdCB0eXBlLg0KDQpVcG9u IHJlY2VpcHQgb2YgdGhhdCBleHRlbnNpb24sIHRoZSBzZXJ2ZXIgY29uc3VsdHMgaXRzIGxpc3Qg b2Ygc3VwcG9ydGVkIGtleSB0eXBlcyBpbiBwcmVmZXJlbmNlIG9yZGVyIChhbmQgZmlsdGVycyBp dCBiYXNlZCBvbiB3aGF0IHRoZSBjbGllbnQgc2VudCkuIFRoZSBzZXJ2ZXIgcHV0cyBvbmUgb3Ig dHdvIHZhbHVlcyBpbiBpdHMga2V5X3BhcmFtZXRlcnNfbGlzdDogVGhlIGtleSB0eXBlIGF0IHRo ZSB0b3Agb2YgdGhlIGZpbHRlcmVkIGxpc3QsIGFuZCB0aGUgaGlnaGVzdCBrZXkgdHlwZSBvbiB0 aGUgZmlsdGVyZWQgbGlzdCB0aGF0IGEgY2xpZW50IGhhcyBhIGtleSBmb3IgKHRoZXNlIHdpbGwg YmUgdGhlIHNhbWUgdGhpbmcgaW4gbW9zdCBjYXNlcywgaW4gd2hpY2ggY2FzZSB0aGUgc2VydmVy IHNlbmRzIG9ubHkgb25lIHZhbHVlKS4gSWYgdGhlIHNlcnZlciBzZW5kcyB0d28gdmFsdWVzLCBp dCBtdXN0IGRvIHNvIGluIHRoaXMgb3JkZXIgKHRvIGluZGljYXRlIHRvIHRoZSBjbGllbnQgd2hh dCB0aGUgc2VydmVyJ3MgcHJlZmVyZW5jZSBpcykuDQoNCldoZW4gYSBjbGllbnQgcmVjZWl2ZXMg dHdvIHZhbHVlcyBpbiB0aGUga2V5X3BhcmFtZXRlcnNfbGlzdCBmcm9tIHRoZSBzZXJ2ZXIsIHRo ZSBjbGllbnQgZ2VuZXJhdGVzIGEgVG9rZW5CaW5kaW5nTWVzc2FnZSB3aXRoIHR3byBwcm92aWRl ZCBUb2tlbkJpbmRpbmdzLiAoVGhpcyBtZWFucyB0aGF0IHRoZSBjbGllbnQgaXMgZ2VuZXJhdGlu ZyBhIG5ldyBrZXlwYWlyIGZvciBvbmUgb2YgdGhlIHRva2VuIGJpbmRpbmdzLikgT25jZSB0aGUg Y2xpZW50IHJlY2VpdmVzIGEgc3VjY2Vzc2Z1bCByZXNwb25zZSB0byB0aGUgYXBwbGljYXRpb24g bGF5ZXIgcmVxdWVzdCB0aGF0IGNvbnRhaW5lZCB0aGF0IFRva2VuQmluZGluZ01lc3NhZ2UgKGUu Zy4gYSAyeHggb3IgM3h4IEhUVFAgcmVzcG9uc2UgZm9yIGEgcmVxdWVzdCB3aXRoIGEgU2VjLVRv a2VuLUJpbmRpbmcgaGVhZGVyKSwgdGhlIGNsaWVudCBtYXkgZGlzY2FyZCB0aGUga2V5IG9mIHRo ZSB0eXBlIHRoYXQgd2FzIG5vdCBmaXJzdCBpbiB0aGUgc2VydmVyJ3Mga2V5X3BhcmFtZXRlcnNf bGlzdC4NCg0KV2hlbiBhIHNlcnZlciByZWNlaXZlcyBhIFRva2VuQmluZGluZ01lc3NhZ2Ugd2l0 aCB0d28gcHJvdmlkZWQgVG9rZW5CaW5kaW5ncywgaXQgbXVzdCByZWJpbmQgdGhlIHRva2VucyBz ZW50IGJ5IHRoZSBjbGllbnQgdG8gYmUgYm91bmQgdG8gdGhlIG5ldyBrZXkgKHRoaXMgaXMgaWRl bnRpZmllZCBhcyB0aGUga2V5IG9mIHRoZSB0eXBlIHRoYXQgdGhlIHNlcnZlciBoYXMgcmFua2Vk IGhpZ2hlciBvbiBpdHMgcHJlZmVyZW5jZSBsaXN0KS4NCg0KVGhlcmUgaXMgYWxzbyBzb21lIGlt cGxlbWVudGF0aW9uIGd1aWRhbmNlIGZvciBjbGllbnQgSFRUUFMgVG9rZW4gQmluZGluZyBpbXBs ZW1lbnRhdGlvbnMuIFNpbmNlIHRoZSBzYW1lIFRva2VuIEJpbmRpbmcga2V5IGlzIHVzZWQgZm9y IGFsbCBvcmlnaW5zIG9uIGFuIGVUTEQrMSwgYnV0IGEgcmVxdWVzdCB0byBvbmUgb3JpZ2luIG1p Z2h0IG9ubHkgY29udGFpbiBzb21lIG9mIHRoZSB0b2tlbnMgb24gdGhhdCBlVExEKzEsIHRoZSBj bGllbnQgbmVlZHMgdG8ga2VlcCB0cmFjayBvZiB3aGljaCBrZXlzIGZvciB0aGUgZVRMRCsxIGFy ZSB1c2VkIG9uIHdoaWNoIG9yaWdpbnMsIGFuZCBtYWtlIHN1cmUgdGhhdCBhIGtleSBpcyBub3Qg ZGlzY2FyZGVkIHVudGlsIGl0IGlzIG5vIGxvbmdlciB1c2VkIG9uIGFueSBvZiB0aGUgb3JpZ2lu cyBmb3IgdGhhdCBlVExEKzEuIEZ1cnRoZXJtb3JlLCBpZiBhIGtleSBvZiBhIHR5cGUgVCBmb3Ig YW4gZVRMRCsxIGhhcyBuZXZlciBiZWVuIHByZXNlbnRlZCB0byBhIHBhcnRpY3VsYXIgb3JpZ2lu IGluIHRoYXQgZVRMRCsxLCB0aGUgY2xpZW50IG11c3Qgbm90IGluZGljYXRlIHRoYXQgaXQgaGFz IGEga2V5IG9mIHR5cGUgVCBpbiB0aGUgbmVnb3RpYXRpb24gZXh0ZW5zaW9uLg0KDQpUaGlzIGNs aWVudCBzaWRlIGNvbXBsaWNhdGlvbiBpcyB0byBoYW5kbGUgdGhlIHNjZW5hcmlvIG9mIG11bHRp cGxlIHN1YmRvbWFpbnMgb24gYW4gZVRMRCsxIHdoaWNoIGhhdmUgZGlmZmVyZW50IGNvb2tpZXMu IENvbnNpZGVyIGEgY2xpZW50IGFuZCBzZXJ2ZXIgdGhhdCBzdXBwb3J0IGtleSB0eXBlcyBUMSBh bmQgVDIgKHdpdGggVDIgcHJlZmVycmVkIG92ZXIgVDEpLCBhbmQgYSBjbGllbnQgdGhhdCBjdXJy ZW50bHkgb25seSBoYXMga2V5IEsxIChvZiB0eXBlIFQxKSBmb3IgbXVsdGlwbGUgZG9tYWlucyBv biB0aGF0IHNlcnZlci4gVGhlIGNsaWVudCBhbmQgc2VydmVyIGJvdGggd2lzaCB0byBtaWdyYXRl IHRvIGEgbmV3IGtleSBLMiBvZiB0eXBlIFQyLiBJbiB0aGlzIGV4YW1wbGUsIHRoZSBzZXJ2ZXIg cnVucyBmb28uZXhhbXBsZS5jb208aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmZvby5leGFtcGxlLmNvbSUyZiZkYXRhPTAyJTdj MDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2IyNDEzNTZmMTMzMzRiMGIwYmNjMDhkM2Jm YzBhZTYxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJTdjMCU3YzYzNjA2 MjgwNjY3Njg5NjIwMSZzZGF0YT1QSXVDbndyQ0RiU0FvVlVOWTRJRzVsMWRodXN6NEp0TXFPaldF biUyYkVQTVklM2Q+IGFuZCBiYXIuZXhhbXBsZS5jb208aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmJhci5leGFtcGxlLmNvbSUy ZiZkYXRhPTAyJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2IyNDEzNTZmMTMzMzRi MGIwYmNjMDhkM2JmYzBhZTYxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2Mx JTdjMCU3YzYzNjA2MjgwNjY3Njg5NjIwMSZzZGF0YT1ZZndwTWNwV09RJTJiMFpEdUxkalp5dGgl MmZNVlFGMVAyWE9aOURBRVRXdXFkRSUzZD4sIHdoaWNoIGhhdmUgZGlmZmVyZW50IGNvb2tpZXMu DQoxLiBDbGllbnQgc2VuZHMgbmVnb3RpYXRpb24gZXh0ZW5zaW9uIHdpdGggKFQxLCB0cnVlKSBh bmQgKFQyLCBmYWxzZSkgd2hlbiBjb25uZWN0aW5nIHRvIGZvby5leGFtcGxlLmNvbTxodHRwczov L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJm Zm9vLmV4YW1wbGUuY29tJTJmJmRhdGE9MDIlN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29t JTdjYjI0MTM1NmYxMzMzNGIwYjBiY2MwOGQzYmZjMGFlNjElN2M3MmY5ODhiZjg2ZjE0MWFmOTFh YjJkN2NkMDExZGI0NyU3YzElN2MwJTdjNjM2MDYyODA2Njc2ODk2MjAxJnNkYXRhPVBJdUNud3JD RGJTQW9WVU5ZNElHNWwxZGh1c3o0SnRNcU9qV0VuJTJiRVBNWSUzZD4uIFNlcnZlciByZXNwb25k cyB3aXRoIFQyLCBUMS4NCjIuIENsaWVudCBnZW5lcmF0ZXMgbmV3IGtleSBLMiBvZiB0eXBlIFQy IGZvciBlVExEKzEgZXhhbXBsZS5jb208aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmV4YW1wbGUuY29tJTJmJmRhdGE9MDIlN2Mw MSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjYjI0MTM1NmYxMzMzNGIwYjBiY2MwOGQzYmZj MGFlNjElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzElN2MwJTdjNjM2MDYy ODA2Njc2OTA2MjE0JnNkYXRhPTRUUFpmYXhmSWxlN293MSUyZndEdjZyb2pwSW1DR3NsMVV6TVVP TU0lMmYwS0xnJTNkPiwgbm8gb3JpZ2luLiAoSzEgaXMgaW4gdGhlIGtleSBzdG9yZSBmb3IgZVRM RCsxIGV4YW1wbGUuY29tPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZleGFtcGxlLmNvbSUyZiZkYXRhPTAyJTdjMDElN2N0b255 bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2IyNDEzNTZmMTMzMzRiMGIwYmNjMDhkM2JmYzBhZTYxJTdj NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJTdjMCU3YzYzNjA2MjgwNjY3Njkw NjIxNCZzZGF0YT00VFBaZmF4ZklsZTdvdzElMmZ3RHY2cm9qcEltQ0dzbDFVek1VT01NJTJmMEtM ZyUzZD4sIG9yaWdpbnMgZm9vLmV4YW1wbGUuY29tPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZmb28uZXhhbXBsZS5jb20lMmYm ZGF0YT0wMiU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NiMjQxMzU2ZjEzMzM0YjBi MGJjYzA4ZDNiZmMwYWU2MSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSU3 YzAlN2M2MzYwNjI4MDY2NzY5MDYyMTQmc2RhdGE9Q0N2YTk3dkp4eHR0djFNQTNRSVNuZDFMdW9N VUpWQTg5b2piNllZTDVydyUzZD4sIGJhci5leGFtcGxlLmNvbTxodHRwczovL25hMDEuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmYmFyLmV4YW1wbGUu Y29tJTJmJmRhdGE9MDIlN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjYjI0MTM1NmYx MzMzNGIwYjBiY2MwOGQzYmZjMGFlNjElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3YzElN2MwJTdjNjM2MDYyODA2Njc2OTA2MjE0JnNkYXRhPSUyZmhLUTV1anloVzFzZW5YUXll cWliUGdPTmVHQ2tHYlR1VHZJTkhoTzVSQSUzZD4uKQ0KMy4gQ2xpZW50IHNlbmRzIFNlYy1Ub2tl bi1CaW5kaW5nIGhlYWRlciB3aXRoIEsxIGFuZCBLMiBhcyBwcm92aWRlZCB0b2tlbiBiaW5kaW5n czsgc2VydmVyIHJlc3BvbmRzIHdpdGggYSAyeHggb3IgM3h4IHJlc3BvbnNlIGNvZGUuDQo0LiBD bGllbnQgdXBkYXRlcyBrZXkgc3RvcmUgc28gSzIgaGFzIG9yaWdpbiBmb28uZXhhbXBsZS5jb208 aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUz YSUyZiUyZmZvby5leGFtcGxlLmNvbSUyZiZkYXRhPTAyJTdjMDElN2N0b255bmFkJTQwbWljcm9z b2Z0LmNvbSU3Y2IyNDEzNTZmMTMzMzRiMGIwYmNjMDhkM2JmYzBhZTYxJTdjNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJTdjMCU3YzYzNjA2MjgwNjY3NjkwNjIxNCZzZGF0YT1D Q3ZhOTd2Snh4dHR2MU1BM1FJU25kMUx1b01VSlZBODlvamI2WVlMNXJ3JTNkPiBhbmQgSzEgbm8g bG9uZ2VyIGhhcyB0aGF0IG9yaWdpbiAoaXQgb25seSBoYXMgYmFyLmV4YW1wbGUuY29tPGh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYl MmZiYXIuZXhhbXBsZS5jb20lMmYmZGF0YT0wMiU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5j b20lN2NiMjQxMzU2ZjEzMzM0YjBiMGJjYzA4ZDNiZmMwYWU2MSU3YzcyZjk4OGJmODZmMTQxYWY5 MWFiMmQ3Y2QwMTFkYjQ3JTdjMSU3YzAlN2M2MzYwNjI4MDY2NzY5MDYyMTQmc2RhdGE9JTJmaEtR NXVqeWhXMXNlblhReWVxaWJQZ09OZUdDa0diVHVUdklOSGhPNVJBJTNkPiBsaXN0ZWQgYXMgaXRz IG9yaWdpbikuDQpOb3csIG9uIGZ1dHVyZSBjb25uZWN0aW9ucywgdGhlIGNsaWVudCBjYW4gc2Vu ZCBhIG5lZ290aWF0aW9uIGV4dGVuc2lvbiB3aXRoIChUMSwgZmFsc2UpLCAoVDIsIHRydWUpIHRv IGZvby5leGFtcGxlLmNvbTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwJTNhJTJmJTJmZm9vLmV4YW1wbGUuY29tJTJmJmRhdGE9MDIlN2MwMSU3 Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjYjI0MTM1NmYxMzMzNGIwYjBiY2MwOGQzYmZjMGFl NjElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzElN2MwJTdjNjM2MDYyODA2 Njc2OTA2MjE0JnNkYXRhPUNDdmE5N3ZKeHh0dHYxTUEzUUlTbmQxTHVvTVVKVkE4OW9qYjZZWUw1 cnclM2Q+LCBhbmQgZm9vLmV4YW1wbGUuY29tPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZmb28uZXhhbXBsZS5jb20lMmYmZGF0 YT0wMiU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NiMjQxMzU2ZjEzMzM0YjBiMGJj YzA4ZDNiZmMwYWU2MSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSU3YzAl N2M2MzYwNjI4MDY2NzY5MDYyMTQmc2RhdGE9Q0N2YTk3dkp4eHR0djFNQTNRSVNuZDFMdW9NVUpW QTg5b2piNllZTDVydyUzZD4gd2lsbCBvbmx5IHNlbmQgYmFjayBUMi4NCk5vdGUgdGhhdCB3aGVu IHRoZSBjbGllbnQgaXMgZGVjaWRpbmcgd2hldGhlciBvciBub3QgdG8gaW5kaWNhdGUgaXQgaGFz IGEga2V5IG9mIGEgcGFydGljdWxhciB0eXBlLCBpdCBpcyBjaGVja2luZyBmb3IgYSBrZXkgb2Yg dGhhdCB0eXBlIGZvciB0aGF0IG9yaWdpbiwgYW5kIG5vdCBmb3IgdGhhdCBlVExEKzEuDQpXaGVu IHRoZSBzZXJ2ZXIgY29ubmVjdHMgdG8gYmFyLmV4YW1wbGUuY29tPGh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZiYXIuZXhhbXBs ZS5jb20lMmYmZGF0YT0wMiU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NiMjQxMzU2 ZjEzMzM0YjBiMGJjYzA4ZDNiZmMwYWU2MSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdjMSU3YzAlN2M2MzYwNjI4MDY2NzY5MDYyMTQmc2RhdGE9JTJmaEtRNXVqeWhXMXNlblhR eWVxaWJQZ09OZUdDa0diVHVUdklOSGhPNVJBJTNkPiwgaXQgY29udGludWVzIGFzIGZvbGxvd3M6 DQo1LiBDbGllbnQgc2VuZHMgbmVnb3RpYXRpb24gZXh0ZW5zaW9uIHdpdGggKFQxLCB0cnVlKSwg KFQyLCBmYWxzZSksIGFuZCBiYXIuZXhhbXBsZS5jb208aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmJhci5leGFtcGxlLmNvbSUy ZiZkYXRhPTAyJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2IyNDEzNTZmMTMzMzRi MGIwYmNjMDhkM2JmYzBhZTYxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2Mx JTdjMCU3YzYzNjA2MjgwNjY3NjkwNjIxNCZzZGF0YT0lMmZoS1E1dWp5aFcxc2VuWFF5ZXFpYlBn T05lR0NrR2JUdVR2SU5IaE81UkElM2Q+IHJlc3BvbmRzIHdpdGggVDIsIFQxLg0KNi4gQ2xpZW50 IHNlbmRzIFNlYy1Ub2tlbi1CaW5kaW5nIGhlYWRlciB3aXRoIEsxIGFuZCBLMiBhcyBwcm92aWRl ZCB0b2tlbiBiaW5kaW5nczsgc2VydmVyIHJlc3BvbmRzIHdpdGggMnh4IG9yIDN4eCByZXNwb25z ZSBjb2RlLg0KNy4gQ2xpZW50IHVwZGF0ZXMga2V5IHN0b3JlIHRvIGFkZCBiYXIuZXhhbXBsZS5j b208aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cCUzYSUyZiUyZmJhci5leGFtcGxlLmNvbSUyZiZkYXRhPTAyJTdjMDElN2N0b255bmFkJTQwbWlj cm9zb2Z0LmNvbSU3Y2IyNDEzNTZmMTMzMzRiMGIwYmNjMDhkM2JmYzBhZTYxJTdjNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJTdjMCU3YzYzNjA2MjgwNjY3NjkwNjIxNCZzZGF0 YT0lMmZoS1E1dWp5aFcxc2VuWFF5ZXFpYlBnT05lR0NrR2JUdVR2SU5IaE81UkElM2Q+IGFzIGFu IG9yaWdpbiBmb3IgSzIsIGFuZCByZW1vdmUgYmFyLmV4YW1wbGUuY29tPGh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZiYXIuZXhh bXBsZS5jb20lMmYmZGF0YT0wMiU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NiMjQx MzU2ZjEzMzM0YjBiMGJjYzA4ZDNiZmMwYWU2MSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdjMSU3YzAlN2M2MzYwNjI4MDY2NzY5MDYyMTQmc2RhdGE9JTJmaEtRNXVqeWhXMXNl blhReWVxaWJQZ09OZUdDa0diVHVUdklOSGhPNVJBJTNkPiBhcyBhbiBvcmlnaW4gZm9yIEsxLg0K OC4gQ2xpZW50IHNlZXMgdGhhdCBLMSBoYXMgbm8gbW9yZSBvcmlnaW5zLCBhbmQgcmVtb3ZlcyBp dCBmcm9tIHRoZSBrZXkgc3RvcmUuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0DQpVbmJlYXJhYmxlQGll dGYub3JnPG1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1h biUyZmxpc3RpbmZvJTJmdW5iZWFyYWJsZSZkYXRhPTAyJTdjMDElN2N0b255bmFkJTQwbWljcm9z b2Z0LmNvbSU3Y2IyNDEzNTZmMTMzMzRiMGIwYmNjMDhkM2JmYzBhZTYxJTdjNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJTdjMCU3YzYzNjA2MjgwNjY3NjkwNjIxNCZzZGF0YT1T Q0VhYUQlMmJTMHl2MmJybGJqazRsUSUyZjFOUnA1SDF4WU1CSkl2bk1oem0lMmZrJTNkPg0KDQoN Cg== --_000_DM5PR03MB244123682F06D67E4ED0E083A61B0DM5PR03MB2441namp_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDoxODM3OTI2MzA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjg3OTkwNjM3MCAzNjg3Mjg2NTYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2 OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DdXJyZW50bHkgd2Ug aGF2ZSBubyByZXF1aXJlbWVudHMgZm9yIHRoaXMgZmVhdHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxl PSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVW5iZWFyYWJsZSBbbWFpbHRvOnVu YmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QW5kcmVpIFBv cG92PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDgsIDIwMTYgMTI6MTggUE08YnI+ DQo8Yj5Ubzo8L2I+IE5pY2sgSGFycGVyICZsdDtuaGFycGVyQGdvb2dsZS5jb20mZ3Q7OyBCcmlh biBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiB1bmJlYXJhYmxlQGlldGYub3JnOyBTdWJvZGggSXllbmdhciAmbHQ7c3Vib2RoQGZiLmNv bSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBtaWdyYXRpb25zIG9m IHRva2VuIGJpbmRpbmdzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JcyB0aGUgYWJpbGl0eSB0byByZS1iaW5kIHRva2VucyB0 byBhIGRpZmZlcmVudCBrZXkgdHlwZSB3aXRob3V0IHJlYXV0aGVudGljYXRpb24gYW4gaW1wb3J0 YW50IHJlcXVpcmVtZW50PyBUaGlzIGluY3JlYXNlcyBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5 IGFuZCBjb21wdXRhdGlvbmFsIGNvc3QNCiAoaWYgbXVsdGlwbGUgc2lnbmF0dXJlcyBhcmUgaW52 b2x2ZWQpIGFuZCB0aGVyZWZvcmUgaXMgbm90IHN1cHBvcnRlZCBpbiB0aGUgY3VycmVudCBzcGVj cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8y Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5XaGVuIHRoZSBjbGllbnQgaXMgY29ubmVjdGlu ZyB0byA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwJTNhJTJmJTJmZXhhbXBsZS5jb20mYW1wO2RhdGE9MDIlN2MwMSU3Y3Rvbnlu YWQlNDBtaWNyb3NvZnQuY29tJTdjYjI0MTM1NmYxMzMzNGIwYjBiY2MwOGQzYmZjMGFlNjElN2M3 MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzElN2MwJTdjNjM2MDYyODA2Njc2ODk2 MjAxJmFtcDtzZGF0YT0lMmZLTmN6N1l5UnQycm9jUGIlMmIwMEpYanNMMXVCSXU1Qk9ZUFVDT210 WlclMmJFJTNkIj4NCmV4YW1wbGUuY29tPC9hPiwgc2hvdWxkIGl0IGxpc3QganVzdCBQU1MgaW4g aXRzIGV4dGVuc2lvbiwgb3IgYm90aCBQU1MgYW5kIFAyNTY/PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlRoZSBjbGllbnQgaW5kaWNhdGVzIGFsbCBzdXBwb3J0ZWQgVEIgcGFyYW1ldGVycy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpX aW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT5JZiB0aGUgY2xpZW50IGxpc3RzIFBTUyBmb2xsb3dlZCBieSBQ MjU2ICh0byBpbmRpY2F0ZSB0aGF0IHRoZSBjbGllbnQgcHJlZmVycyBQU1MsIHNpbmNlIHRoZXkg YXJlIGluIHByZWZlcmVuY2Ugb3JkZXIpLCBidXQgdGhlIHNlcnZlciBwcmVmZXJzIFAyNTYgb3Zl ciBQU1MsIHNob3VsZCB0aGUgc2VydmVyIG5lZ290aWF0ZSBQMjU2IG9yIFBTUz88c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+R2VuZXJhbGx5LCB0aGUgc2VydmVyIHNob3VsZCB1c2UgdGhlIHNlcnZlcuKA mXMgcHJlZmVyZW5jZXMuIEhvd2V2ZXIsIHRoZXJlIG1heSBiZSBjb25maWd1cmF0aW9ucyB3aGVy ZSBjbGllbnQgcHJlZmVyZW5jZXMgYXJlIGhvbm9yZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBVbmJlYXJhYmxlIFs8YSBocmVmPSJtYWlsdG86 dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGll dGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+TmljayBIYXJwZXI8YnI+DQo8Yj5TZW50 OjwvYj4gTW9uZGF5LCBBdWd1c3QgOCwgMjAxNiAxMTo1NCBBTTxicj4NCjxiPlRvOjwvYj4gQnJp YW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bSI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEg aHJlZj0ibWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmciPnVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+ OyBTdWJvZGggSXllbmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1Ym9kaEBmYi5jb20iPnN1Ym9k aEBmYi5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIG1p Z3JhdGlvbnMgb2YgdG9rZW4gYmluZGluZ3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BIHJlbGF0ZWQgaXNzdWUgdG8gbWlncmF0aW9uIGlzIHdoYXQgc2hvdWxkIGEgY2xp ZW50J3MgYmVoYXZpb3IgYmUgaWYgaXQgc3VwcG9ydHMgbXVsdGlwbGUga2V5IHR5cGVzIHdoZW4g aXQgaGFzIG9uZSBrZXkgdGhhdCBpdCBjYW4gdXNlIHdpdGggYSBzZXJ2ZXIgYW5kIGlzIGdlbmVy YXRpbmcgaXRzIG5lZ290aWF0aW9uIGV4dGVuc2lvbi4gTW9yZSBjb25jcmV0ZWx5LCBzdXBwb3Nl IGEgY2xpZW50IHN1cHBvcnRzDQogUFNTIGFuZCBQMjU2LCBhbmQgaGFzIGEgUFNTIGtleSBmb3Ig PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cCUzYSUyZiUyZmV4YW1wbGUuY29tJmFtcDtkYXRhPTAyJTdjMDElN2N0b255bmFkJTQw bWljcm9zb2Z0LmNvbSU3Y2IyNDEzNTZmMTMzMzRiMGIwYmNjMDhkM2JmYzBhZTYxJTdjNzJmOTg4 YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJTdjMCU3YzYzNjA2MjgwNjY3Njg5NjIwMSZh bXA7c2RhdGE9JTJmS05jejdZeVJ0MnJvY1BiJTJiMDBKWGpzTDF1Qkl1NUJPWVBVQ09tdFpXJTJi RSUzZCI+DQpleGFtcGxlLmNvbTwvYT4uIFdoZW4gdGhlIGNsaWVudCBpcyBjb25uZWN0aW5nIHRv IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHAlM2ElMmYlMmZleGFtcGxlLmNvbSZhbXA7ZGF0YT0wMiU3YzAxJTdjdG9ueW5hZCU0 MG1pY3Jvc29mdC5jb20lN2NiMjQxMzU2ZjEzMzM0YjBiMGJjYzA4ZDNiZmMwYWU2MSU3YzcyZjk4 OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSU3YzAlN2M2MzYwNjI4MDY2NzY4OTYyMDEm YW1wO3NkYXRhPSUyZktOY3o3WXlSdDJyb2NQYiUyYjAwSlhqc0wxdUJJdTVCT1lQVUNPbXRaVyUy YkUlM2QiPg0KZXhhbXBsZS5jb208L2E+LCBzaG91bGQgaXQgbGlzdCBqdXN0IFBTUyBpbiBpdHMg ZXh0ZW5zaW9uLCBvciBib3RoIFBTUyBhbmQgUDI1Nj8gSWYgdGhlIGNsaWVudCBsaXN0cyBQU1Mg Zm9sbG93ZWQgYnkgUDI1NiAodG8gaW5kaWNhdGUgdGhhdCB0aGUgY2xpZW50IHByZWZlcnMgUFNT LCBzaW5jZSB0aGV5IGFyZSBpbiBwcmVmZXJlbmNlIG9yZGVyKSwgYnV0IHRoZSBzZXJ2ZXIgcHJl ZmVycyBQMjU2IG92ZXIgUFNTLCBzaG91bGQgdGhlIHNlcnZlcg0KIG5lZ290aWF0ZSBQMjU2IG9y IFBTUz8gSWYgdGhlIHNlcnZlciBuZWdvdGlhdGVzIFAyNTYsIGl0IGp1c3QgYnJva2UgdGhlIGJp bmRpbmcgaXQgaGFkIGZvciBhbnkgdG9rZW5zIGJlY2F1c2UgdGhlIGNsaWVudCBqdXN0IG1hZGUg YSBuZXcga2V5LiBUaGlzIGNvdWxkIGJlIHZpZXdlZCBhcyB0aGUgb25lLXRpbWUgbWlncmF0aW9u IGNvc3QgKHdoaWNoIGlzIGEgcmVhc29uYWJsZSBjb3N0IGlmIGl0IGhhcHBlbnMgb25seSBvbmUg dGltZSksIGJ1dA0KIG5vdyBpbWFnaW5lIHRoYXQgPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmV4YW1wbGUuY29t JmFtcDtkYXRhPTAyJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2IyNDEzNTZmMTMz MzRiMGIwYmNjMDhkM2JmYzBhZTYxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N2MxJTdjMCU3YzYzNjA2MjgwNjY3Njg5NjIwMSZhbXA7c2RhdGE9JTJmS05jejdZeVJ0MnJvY1Bi JTJiMDBKWGpzTDF1Qkl1NUJPWVBVQ09tdFpXJTJiRSUzZCI+DQpleGFtcGxlLmNvbTwvYT4gaXMg c2VydmVkIGJ5IG11bHRpcGxlIHNlcnZlcnMgdGhhdCBhcmUgc2xvd2x5IHJvbGxpbmcgb3V0IHRo ZSBwcmVmZXJlbmNlIGNoYW5nZSBvZiBwcmVmZXJyaW5nIFAyNTYgb3ZlciBQU1MsIGFuZCB0aGUg Y2xpZW50IGlzIGJvdW5jaW5nIGJldHdlZW4gc2VydmVycyB0aGF0IHByZWZlciBvbmUgb3ZlciB0 aGUgb3RoZXIuIE5vdyB0aGlzICZxdW90O29uZS10aW1lJnF1b3Q7IG1pZ3JhdGlvbiBoYXBwZW5z IGV2ZXJ5IHRpbWUgdGhlIGNsaWVudA0KIGhpdHMgYSBzZXJ2ZXIgdGhhdCBoYXMgYSBkaWZmZXJl bnQgcHJlZmVyZW5jZSBsaXN0IGNvbXBhcmVkIHRvIHRoZSBwcmV2aW91cyBzZXJ2ZXIuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEF1ZyA4LCAy MDE2IGF0IDExOjQwIEFNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgZ3Vlc3MgdGhlIHF1ZXN0 aW9uIHRoYXQgY29tZXMgdG8gbXkgbWluZCBpcyB3aGV0aGVyIGtleSBtaWdyYXRpb24gaXMgc29t ZXRoaW5nIHRoYXQgcmVhbGx5IG5lZWRzIHRvIGJlIGFjY29tbW9kYXRlZCBieSB0aGUgcHJvdG9j b2wuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IG9m dGVuIHdpbGwgaXQgcmVhbGx5IGhhcHBlbj8gQSBuZXcga2V5X3BhcmFtZXRlcnMgdHlwZSBtaWdo dCBiZSBpbnRyb2R1Y2VkIGV2ZXJ5IGZldyB5ZWFycyBhdCB0aGUgbW9zdC4gQW5kIGV2ZW4gaWYg YSBjbGllbnQgd2VyZSB0byBleHBsaWNpdGx5IGRpc2NhcmQgJ29sZCcgZXN0YWJsaXNoZWQgYmlu ZGluZ3MgdG8gZm9yY2UgYSBjaGFuZ2UsIHRoZSBpbXBhY3QgaXMgbm8gd29yc2UgdGhhbiBhIHVz ZXINCiBjaG9vc2luZyB0byBjbGVhciBjb29raWVzLiBUaGUgYXV0aGVudGljYXRpb24gY29udGV4 dCBqdXN0IGhhcyB0byBiZSByZWVzdGFibGlzaGVkIChsb2cgaW4gYWdhaW4pLiAmbmJzcDsNCjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBXZWQsIEF1ZyAzLCAyMDE2IGF0IDc6MDQgUE0sIE5pY2sgSGFycGVyICZsdDs8YSBocmVm PSJtYWlsdG86bmhhcnBlckBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bmhhcnBlckBnb29n bGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS41cHQiPkkgY2hhdHRlZCB3aXRoIFN1Ym9kaCBvZmZsaW5lIGFib3V0IGhv dyB0byBkbyBrZXkgbWlncmF0aW9ucyBmb3IgVG9rZW4gQmluZGluZy4gV2UgY2FtZSB1cCB3aXRo IHRoZSBmb2xsb3dpbmcgYXMgYSBwb3RlbnRpYWwgY2hhbmdlIHRvIGJlIGFibGUgdG8gc3VwcG9y dCBtaWdyYXRpbmcgZnJvbSBvbmUga2V5IHR5cGUgdG8gYW5vdGhlci48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5X aGVuIGEgY2xpZW50IHNlbmRzIHRoZSBUb2tlbiBCaW5kaW5nIG5lZ290aWF0aW9uIFRMUyBleHRl bnNpb24sIGl0IGluY2x1ZGVzIHdpdGggZWFjaCBrZXkgdHlwZSB3aGV0aGVyIG9yIG5vdCBpdCBo YXMgYSBrZXkgb2YgdGhhdCB0eXBlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPlVwb24gcmVjZWlwdCBvZiB0aGF0 IGV4dGVuc2lvbiwgdGhlIHNlcnZlciBjb25zdWx0cyBpdHMgbGlzdCBvZiBzdXBwb3J0ZWQga2V5 IHR5cGVzIGluIHByZWZlcmVuY2Ugb3JkZXIgKGFuZCBmaWx0ZXJzIGl0IGJhc2VkIG9uIHdoYXQg dGhlIGNsaWVudCBzZW50KS4gVGhlIHNlcnZlciBwdXRzIG9uZSBvciB0d28gdmFsdWVzIGluIGl0 cyBrZXlfcGFyYW1ldGVyc19saXN0Og0KIFRoZSBrZXkgdHlwZSBhdCB0aGUgdG9wIG9mIHRoZSBm aWx0ZXJlZCBsaXN0LCBhbmQgdGhlIGhpZ2hlc3Qga2V5IHR5cGUgb24gdGhlIGZpbHRlcmVkIGxp c3QgdGhhdCBhIGNsaWVudCBoYXMgYSBrZXkgZm9yICh0aGVzZSB3aWxsIGJlIHRoZSBzYW1lIHRo aW5nIGluIG1vc3QgY2FzZXMsIGluIHdoaWNoIGNhc2UgdGhlIHNlcnZlciBzZW5kcyBvbmx5IG9u ZSB2YWx1ZSkuIElmIHRoZSBzZXJ2ZXIgc2VuZHMgdHdvIHZhbHVlcywgaXQgbXVzdCBkbw0KIHNv IGluIHRoaXMgb3JkZXIgKHRvIGluZGljYXRlIHRvIHRoZSBjbGllbnQgd2hhdCB0aGUgc2VydmVy J3MgcHJlZmVyZW5jZSBpcykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+V2hlbiBhIGNsaWVudCByZWNlaXZlcyB0 d28gdmFsdWVzIGluIHRoZSBrZXlfcGFyYW1ldGVyc19saXN0IGZyb20gdGhlIHNlcnZlciwgdGhl IGNsaWVudCBnZW5lcmF0ZXMgYSBUb2tlbkJpbmRpbmdNZXNzYWdlIHdpdGggdHdvIHByb3ZpZGVk IFRva2VuQmluZGluZ3MuIChUaGlzIG1lYW5zIHRoYXQgdGhlIGNsaWVudCBpcyBnZW5lcmF0aW5n IGEgbmV3IGtleXBhaXINCiBmb3Igb25lIG9mIHRoZSB0b2tlbiBiaW5kaW5ncy4pIE9uY2UgdGhl IGNsaWVudCByZWNlaXZlcyBhIHN1Y2Nlc3NmdWwgcmVzcG9uc2UgdG8gdGhlIGFwcGxpY2F0aW9u IGxheWVyIHJlcXVlc3QgdGhhdCBjb250YWluZWQgdGhhdCBUb2tlbkJpbmRpbmdNZXNzYWdlIChl LmcuIGEgMnh4IG9yIDN4eCBIVFRQIHJlc3BvbnNlIGZvciBhIHJlcXVlc3Qgd2l0aCBhIFNlYy1U b2tlbi1CaW5kaW5nIGhlYWRlciksIHRoZSBjbGllbnQgbWF5IGRpc2NhcmQNCiB0aGUga2V5IG9m IHRoZSB0eXBlIHRoYXQgd2FzIG5vdCBmaXJzdCBpbiB0aGUgc2VydmVyJ3Mga2V5X3BhcmFtZXRl cnNfbGlzdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuNXB0Ij5XaGVuIGEgc2VydmVyIHJlY2VpdmVzIGEgVG9rZW5CaW5k aW5nTWVzc2FnZSB3aXRoIHR3byBwcm92aWRlZCBUb2tlbkJpbmRpbmdzLCBpdCBtdXN0IHJlYmlu ZCB0aGUgdG9rZW5zIHNlbnQgYnkgdGhlIGNsaWVudCB0byBiZSBib3VuZCB0byB0aGUgbmV3IGtl eSAodGhpcyBpcyBpZGVudGlmaWVkIGFzIHRoZSBrZXkgb2YgdGhlIHR5cGUgdGhhdCB0aGUgc2Vy dmVyDQogaGFzIHJhbmtlZCBoaWdoZXIgb24gaXRzIHByZWZlcmVuY2UgbGlzdCkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdCI+VGhlcmUgaXMgYWxzbyBzb21lIGltcGxlbWVudGF0aW9uIGd1aWRhbmNlIGZvciBjbGll bnQgSFRUUFMgVG9rZW4gQmluZGluZyBpbXBsZW1lbnRhdGlvbnMuIFNpbmNlIHRoZSBzYW1lIFRv a2VuIEJpbmRpbmcga2V5IGlzIHVzZWQgZm9yIGFsbCBvcmlnaW5zIG9uIGFuIGVUTEQmIzQzOzEs IGJ1dCBhIHJlcXVlc3QgdG8gb25lIG9yaWdpbiBtaWdodCBvbmx5IGNvbnRhaW4NCiBzb21lIG9m IHRoZSB0b2tlbnMgb24gdGhhdCBlVExEJiM0MzsxLCB0aGUgY2xpZW50IG5lZWRzIHRvIGtlZXAg dHJhY2sgb2Ygd2hpY2gga2V5cyBmb3IgdGhlIGVUTEQmIzQzOzEgYXJlIHVzZWQgb24gd2hpY2gg b3JpZ2lucywgYW5kIG1ha2Ugc3VyZSB0aGF0IGEga2V5IGlzIG5vdCBkaXNjYXJkZWQgdW50aWwg aXQgaXMgbm8gbG9uZ2VyIHVzZWQgb24gYW55IG9mIHRoZSBvcmlnaW5zIGZvciB0aGF0IGVUTEQm IzQzOzEuIEZ1cnRoZXJtb3JlLCBpZiBhIGtleSBvZiBhDQogdHlwZSBUIGZvciBhbiBlVExEJiM0 MzsxIGhhcyBuZXZlciBiZWVuIHByZXNlbnRlZCB0byBhIHBhcnRpY3VsYXIgb3JpZ2luIGluIHRo YXQgZVRMRCYjNDM7MSwgdGhlIGNsaWVudCBtdXN0IG5vdCBpbmRpY2F0ZSB0aGF0IGl0IGhhcyBh IGtleSBvZiB0eXBlIFQgaW4gdGhlIG5lZ290aWF0aW9uIGV4dGVuc2lvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuNXB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 Ij5UaGlzIGNsaWVudCBzaWRlIGNvbXBsaWNhdGlvbiBpcyB0byBoYW5kbGUgdGhlIHNjZW5hcmlv IG9mIG11bHRpcGxlIHN1YmRvbWFpbnMgb24gYW4gZVRMRCYjNDM7MSB3aGljaCBoYXZlIGRpZmZl cmVudCBjb29raWVzLiBDb25zaWRlciBhIGNsaWVudCBhbmQgc2VydmVyIHRoYXQgc3VwcG9ydCBr ZXkgdHlwZXMgVDEgYW5kIFQyICh3aXRoIFQyIHByZWZlcnJlZCBvdmVyDQogVDEpLCBhbmQgYSBj bGllbnQgdGhhdCBjdXJyZW50bHkgb25seSBoYXMga2V5IEsxIChvZiB0eXBlIFQxKSBmb3IgbXVs dGlwbGUgZG9tYWlucyBvbiB0aGF0IHNlcnZlci4gVGhlIGNsaWVudCBhbmQgc2VydmVyIGJvdGgg d2lzaCB0byBtaWdyYXRlIHRvIGEgbmV3IGtleSBLMiBvZiB0eXBlIFQyLiBJbiB0aGlzIGV4YW1w bGUsIHRoZSBzZXJ2ZXIgcnVucyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZmb28uZXhhbXBsZS5jb20l MmYmYW1wO2RhdGE9MDIlN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjYjI0MTM1NmYx MzMzNGIwYjBiY2MwOGQzYmZjMGFlNjElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3YzElN2MwJTdjNjM2MDYyODA2Njc2ODk2MjAxJmFtcDtzZGF0YT1QSXVDbndyQ0RiU0FvVlVO WTRJRzVsMWRodXN6NEp0TXFPaldFbiUyYkVQTVklM2QiIHRhcmdldD0iX2JsYW5rIj5mb28uZXhh bXBsZS5jb208L2E+Jm5ic3A7YW5kJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmJhci5leGFtcGxlLmNv bSUyZiZhbXA7ZGF0YT0wMiU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NiMjQxMzU2 ZjEzMzM0YjBiMGJjYzA4ZDNiZmMwYWU2MSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdjMSU3YzAlN2M2MzYwNjI4MDY2NzY4OTYyMDEmYW1wO3NkYXRhPVlmd3BNY3BXT1ElMmIw WkR1TGRqWnl0aCUyZk1WUUYxUDJYT1o5REFFVFd1cWRFJTNkIiB0YXJnZXQ9Il9ibGFuayI+YmFy LmV4YW1wbGUuY29tPC9hPiwNCiB3aGljaCBoYXZlIGRpZmZlcmVudCBjb29raWVzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS41cHQiPjEuIENsaWVudCBzZW5kcyBuZWdvdGlhdGlvbiBleHRl bnNpb24gd2l0aCAoVDEsIHRydWUpIGFuZCAoVDIsIGZhbHNlKSB3aGVuIGNvbm5lY3RpbmcgdG8m bmJzcDs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwJTNhJTJmJTJmZm9vLmV4YW1wbGUuY29tJTJmJmFtcDtkYXRhPTAyJTdjMDEl N2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2IyNDEzNTZmMTMzMzRiMGIwYmNjMDhkM2JmYzBh ZTYxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJTdjMCU3YzYzNjA2Mjgw NjY3Njg5NjIwMSZhbXA7c2RhdGE9UEl1Q253ckNEYlNBb1ZVTlk0SUc1bDFkaHVzejRKdE1xT2pX RW4lMmJFUE1ZJTNkIiB0YXJnZXQ9Il9ibGFuayI+Zm9vLmV4YW1wbGUuY29tPC9hPi4NCiBTZXJ2 ZXIgcmVzcG9uZHMgd2l0aCBUMiwgVDEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+ Mi4gQ2xpZW50IGdlbmVyYXRlcyBuZXcga2V5IEsyIG9mIHR5cGUgVDIgZm9yIGVUTEQmIzQzOzEm bmJzcDs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwJTNhJTJmJTJmZXhhbXBsZS5jb20lMmYmYW1wO2RhdGE9MDIlN2MwMSU3Y3Rv bnluYWQlNDBtaWNyb3NvZnQuY29tJTdjYjI0MTM1NmYxMzMzNGIwYjBiY2MwOGQzYmZjMGFlNjEl N2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzElN2MwJTdjNjM2MDYyODA2Njc2 OTA2MjE0JmFtcDtzZGF0YT00VFBaZmF4ZklsZTdvdzElMmZ3RHY2cm9qcEltQ0dzbDFVek1VT01N JTJmMEtMZyUzZCIgdGFyZ2V0PSJfYmxhbmsiPmV4YW1wbGUuY29tPC9hPiwNCiBubyBvcmlnaW4u IChLMSBpcyBpbiB0aGUga2V5IHN0b3JlIGZvciBlVExEJiM0MzsxJm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUy ZiUyZmV4YW1wbGUuY29tJTJmJmFtcDtkYXRhPTAyJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0 LmNvbSU3Y2IyNDEzNTZmMTMzMzRiMGIwYmNjMDhkM2JmYzBhZTYxJTdjNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN2MxJTdjMCU3YzYzNjA2MjgwNjY3NjkwNjIxNCZhbXA7c2RhdGE9 NFRQWmZheGZJbGU3b3cxJTJmd0R2NnJvanBJbUNHc2wxVXpNVU9NTSUyZjBLTGclM2QiIHRhcmdl dD0iX2JsYW5rIj5leGFtcGxlLmNvbTwvYT4sDQogb3JpZ2lucyZuYnNwOzxhIGhyZWY9Imh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYl MmZmb28uZXhhbXBsZS5jb20lMmYmYW1wO2RhdGE9MDIlN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3Nv ZnQuY29tJTdjYjI0MTM1NmYxMzMzNGIwYjBiY2MwOGQzYmZjMGFlNjElN2M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3YzElN2MwJTdjNjM2MDYyODA2Njc2OTA2MjE0JmFtcDtzZGF0 YT1DQ3ZhOTd2Snh4dHR2MU1BM1FJU25kMUx1b01VSlZBODlvamI2WVlMNXJ3JTNkIiB0YXJnZXQ9 Il9ibGFuayI+Zm9vLmV4YW1wbGUuY29tPC9hPiwmbmJzcDs8YSBocmVmPSJodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmYmFyLmV4 YW1wbGUuY29tJTJmJmFtcDtkYXRhPTAyJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3 Y2IyNDEzNTZmMTMzMzRiMGIwYmNjMDhkM2JmYzBhZTYxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN2MxJTdjMCU3YzYzNjA2MjgwNjY3NjkwNjIxNCZhbXA7c2RhdGE9JTJmaEtR NXVqeWhXMXNlblhReWVxaWJQZ09OZUdDa0diVHVUdklOSGhPNVJBJTNkIiB0YXJnZXQ9Il9ibGFu ayI+YmFyLmV4YW1wbGUuY29tPC9hPi4pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+ My4gQ2xpZW50IHNlbmRzIFNlYy1Ub2tlbi1CaW5kaW5nIGhlYWRlciB3aXRoIEsxIGFuZCBLMiBh cyBwcm92aWRlZCB0b2tlbiBiaW5kaW5nczsgc2VydmVyIHJlc3BvbmRzIHdpdGggYSAyeHggb3Ig M3h4IHJlc3BvbnNlIGNvZGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+NC4gQ2xp ZW50IHVwZGF0ZXMga2V5IHN0b3JlIHNvIEsyIGhhcyBvcmlnaW4mbmJzcDs8YSBocmVmPSJodHRw czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJm JTJmZm9vLmV4YW1wbGUuY29tJTJmJmFtcDtkYXRhPTAyJTdjMDElN2N0b255bmFkJTQwbWljcm9z b2Z0LmNvbSU3Y2IyNDEzNTZmMTMzMzRiMGIwYmNjMDhkM2JmYzBhZTYxJTdjNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJTdjMCU3YzYzNjA2MjgwNjY3NjkwNjIxNCZhbXA7c2Rh dGE9Q0N2YTk3dkp4eHR0djFNQTNRSVNuZDFMdW9NVUpWQTg5b2piNllZTDVydyUzZCIgdGFyZ2V0 PSJfYmxhbmsiPmZvby5leGFtcGxlLmNvbTwvYT4mbmJzcDthbmQNCiBLMSBubyBsb25nZXIgaGFz IHRoYXQgb3JpZ2luIChpdCBvbmx5IGhhcyZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZiYXIuZXhhbXBs ZS5jb20lMmYmYW1wO2RhdGE9MDIlN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjYjI0 MTM1NmYxMzMzNGIwYjBiY2MwOGQzYmZjMGFlNjElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk MDExZGI0NyU3YzElN2MwJTdjNjM2MDYyODA2Njc2OTA2MjE0JmFtcDtzZGF0YT0lMmZoS1E1dWp5 aFcxc2VuWFF5ZXFpYlBnT05lR0NrR2JUdVR2SU5IaE81UkElM2QiIHRhcmdldD0iX2JsYW5rIj5i YXIuZXhhbXBsZS5jb208L2E+Jm5ic3A7bGlzdGVkDQogYXMgaXRzIG9yaWdpbikuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+Tm93LCBvbiBmdXR1cmUgY29ubmVjdGlvbnMsIHRoZSBj bGllbnQgY2FuIHNlbmQgYSBuZWdvdGlhdGlvbiBleHRlbnNpb24gd2l0aCAoVDEsIGZhbHNlKSwg KFQyLCB0cnVlKSB0byZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZmb28uZXhhbXBsZS5jb20lMmYmYW1w O2RhdGE9MDIlN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQuY29tJTdjYjI0MTM1NmYxMzMzNGIw YjBiY2MwOGQzYmZjMGFlNjElN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEl N2MwJTdjNjM2MDYyODA2Njc2OTA2MjE0JmFtcDtzZGF0YT1DQ3ZhOTd2Snh4dHR2MU1BM1FJU25k MUx1b01VSlZBODlvamI2WVlMNXJ3JTNkIiB0YXJnZXQ9Il9ibGFuayI+Zm9vLmV4YW1wbGUuY29t PC9hPiwNCiBhbmQmbmJzcDs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJmZm9vLmV4YW1wbGUuY29tJTJmJmFtcDtk YXRhPTAyJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2IyNDEzNTZmMTMzMzRiMGIw YmNjMDhkM2JmYzBhZTYxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJTdj MCU3YzYzNjA2MjgwNjY3NjkwNjIxNCZhbXA7c2RhdGE9Q0N2YTk3dkp4eHR0djFNQTNRSVNuZDFM dW9NVUpWQTg5b2piNllZTDVydyUzZCIgdGFyZ2V0PSJfYmxhbmsiPmZvby5leGFtcGxlLmNvbTwv YT4mbmJzcDt3aWxsDQogb25seSBzZW5kIGJhY2sgVDIuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjVwdCI+Tm90ZSB0aGF0IHdoZW4gdGhlIGNsaWVudCBpcyBkZWNpZGluZyB3aGV0aGVyIG9y IG5vdCB0byBpbmRpY2F0ZSBpdCBoYXMgYSBrZXkgb2YgYSBwYXJ0aWN1bGFyIHR5cGUsIGl0IGlz IGNoZWNraW5nIGZvciBhIGtleSBvZiB0aGF0IHR5cGUgZm9yIHRoYXQgb3JpZ2luLCBhbmQgbm90 IGZvciB0aGF0IGVUTEQmIzQzOzEuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+V2hl biB0aGUgc2VydmVyIGNvbm5lY3RzIHRvJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzYSUyZiUyZmJhci5leGFtcGxl LmNvbSUyZiZhbXA7ZGF0YT0wMiU3YzAxJTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NiMjQx MzU2ZjEzMzM0YjBiMGJjYzA4ZDNiZmMwYWU2MSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdjMSU3YzAlN2M2MzYwNjI4MDY2NzY5MDYyMTQmYW1wO3NkYXRhPSUyZmhLUTV1anlo VzFzZW5YUXllcWliUGdPTmVHQ2tHYlR1VHZJTkhoTzVSQSUzZCIgdGFyZ2V0PSJfYmxhbmsiPmJh ci5leGFtcGxlLmNvbTwvYT4sDQogaXQgY29udGludWVzIGFzIGZvbGxvd3M6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjVwdCI+NS4gQ2xpZW50IHNlbmRzIG5lZ290aWF0aW9uIGV4dGVuc2lv biB3aXRoIChUMSwgdHJ1ZSksIChUMiwgZmFsc2UpLCBhbmQmbmJzcDs8YSBocmVmPSJodHRwczov L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNhJTJmJTJm YmFyLmV4YW1wbGUuY29tJTJmJmFtcDtkYXRhPTAyJTdjMDElN2N0b255bmFkJTQwbWljcm9zb2Z0 LmNvbSU3Y2IyNDEzNTZmMTMzMzRiMGIwYmNjMDhkM2JmYzBhZTYxJTdjNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN2MxJTdjMCU3YzYzNjA2MjgwNjY3NjkwNjIxNCZhbXA7c2RhdGE9 JTJmaEtRNXVqeWhXMXNlblhReWVxaWJQZ09OZUdDa0diVHVUdklOSGhPNVJBJTNkIiB0YXJnZXQ9 Il9ibGFuayI+YmFyLmV4YW1wbGUuY29tPC9hPiZuYnNwO3Jlc3BvbmRzDQogd2l0aCBUMiwgVDEu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+Ni4gQ2xpZW50IHNlbmRzIFNlYy1Ub2tl bi1CaW5kaW5nIGhlYWRlciB3aXRoIEsxIGFuZCBLMiBhcyBwcm92aWRlZCB0b2tlbiBiaW5kaW5n czsgc2VydmVyIHJlc3BvbmRzIHdpdGggMnh4IG9yIDN4eCByZXNwb25zZSBjb2RlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS41cHQiPjcuIENsaWVudCB1cGRhdGVzIGtleSBzdG9yZSB0byBh ZGQmbmJzcDs8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwJTNhJTJmJTJmYmFyLmV4YW1wbGUuY29tJTJmJmFtcDtkYXRhPTAyJTdj MDElN2N0b255bmFkJTQwbWljcm9zb2Z0LmNvbSU3Y2IyNDEzNTZmMTMzMzRiMGIwYmNjMDhkM2Jm YzBhZTYxJTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJTdjMCU3YzYzNjA2 MjgwNjY3NjkwNjIxNCZhbXA7c2RhdGE9JTJmaEtRNXVqeWhXMXNlblhReWVxaWJQZ09OZUdDa0di VHVUdklOSGhPNVJBJTNkIiB0YXJnZXQ9Il9ibGFuayI+YmFyLmV4YW1wbGUuY29tPC9hPiZuYnNw O2FzDQogYW4gb3JpZ2luIGZvciBLMiwgYW5kIHJlbW92ZSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8v bmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZi YXIuZXhhbXBsZS5jb20lMmYmYW1wO2RhdGE9MDIlN2MwMSU3Y3RvbnluYWQlNDBtaWNyb3NvZnQu Y29tJTdjYjI0MTM1NmYxMzMzNGIwYjBiY2MwOGQzYmZjMGFlNjElN2M3MmY5ODhiZjg2ZjE0MWFm OTFhYjJkN2NkMDExZGI0NyU3YzElN2MwJTdjNjM2MDYyODA2Njc2OTA2MjE0JmFtcDtzZGF0YT0l MmZoS1E1dWp5aFcxc2VuWFF5ZXFpYlBnT05lR0NrR2JUdVR2SU5IaE81UkElM2QiIHRhcmdldD0i X2JsYW5rIj5iYXIuZXhhbXBsZS5jb208L2E+Jm5ic3A7YXMNCiBhbiBvcmlnaW4gZm9yIEsxLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjguIENsaWVudCBzZWVzIHRoYXQgSzEgaGFz IG5vIG1vcmUgb3JpZ2lucywgYW5kIHJlbW92ZXMgaXQgZnJvbSB0aGUga2V5IHN0b3JlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClVuYmVhcmFibGUgbWFpbGluZyBs aXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5VbmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3Lmll dGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmdW5iZWFyYWJsZSZhbXA7ZGF0YT0wMiU3YzAx JTdjdG9ueW5hZCU0MG1pY3Jvc29mdC5jb20lN2NiMjQxMzU2ZjEzMzM0YjBiMGJjYzA4ZDNiZmMw YWU2MSU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSU3YzAlN2M2MzYwNjI4 MDY2NzY5MDYyMTQmYW1wO3NkYXRhPVNDRWFhRCUyYlMweXYyYnJsYmprNGxRJTJmMU5ScDVIMXhZ TUJKSXZuTWh6bSUyZmslM2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGU8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM5PR03MB244123682F06D67E4ED0E083A61B0DM5PR03MB2441namp_-- From nobody Mon Aug 8 12:46:49 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 09EF212B03F for ; Mon, 8 Aug 2016 12:46:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 4Vf6KnozlmdZ for ; Mon, 8 Aug 2016 12:46:25 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0105.outbound.protection.outlook.com [104.47.33.105]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 278A112B02B for ; Mon, 8 Aug 2016 12:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NzARH0+GYg9TuEs0j+rhRBxtXNrizH9TRYjOgcPOWDI=; b=m9wr0066vJfJjZybcwR+jpAAymkMf3xa5u7s/qHz346zapg411CqiomD3YHNrmEAH0ksCGxqU72G3iBp3k/wDEGOrcxanHYk8mgnuWfewqb6pcAPK3aToTYLawsuKuWFmHzSn5kgbIOWYkXXbgK/tDQEcKS+IfOCUnfIJjm74Do= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 8 Aug 2016 19:46:22 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0549.025; Mon, 8 Aug 2016 19:46:22 +0000 From: Andrei Popov To: Martin Thomson , "unbearable@ietf.org" Thread-Topic: [Unbearable] Renegotiation info extension Thread-Index: AQHR8UG+1juUPHgk7k6r83vWCBCSUaA/dqjA Date: Mon, 8 Aug 2016 19:46:22 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:d::1d2] x-ms-office365-filtering-correlation-id: 0ca1ce51-6219-4fd2-c1f1-08d3bfc4ad13 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2155; 6:gIejcUpK3tpCxmQrlTv0uJP4JUlZ8jIwgAn2pDnZOThdkSqxwNEyqiq5ykeCnxIN/LT8Ff+SsWTIhw1RmSHPGtF4EzLaNDU/irDEbdTWuim2jBq6CIWmmJ3MXwOv2+lCqRuVQo2txR82z7XjNClILrrZnGkQQf0eZu+BZ9uGDWIMLyP5rnwlX/HZ2x3rIdn2EmK3vrbCw6vV4wffz1j8UvG6nWA/nMjoPKyay7797lgTbJJya+IbU0mFO3B1b//cfAf4CVUqPKrBZ9IjWchar6GJsSqlwqDZ40k7NFzgrb6Zd+7EtCkXz4fevSXBsNaU0NxVXnTQY3Xut/RF5tLrjA==; 5:23nkOBKzdXqvDDexeRvdemz5U3pHuEyi3CCxXQD5scgKy+x7BgDnVqguDZkowsT6YN+OLHNM0h+MVvPue2/T4PpIB0/PyJWnAiHxWIbjosbMsoD6Zo0hswNlVzCgiebq83lw+/kb9Fcx+ML+noGZcw==; 24:O4mtGjb1OnJuZ/ae9/ulphxE64sCO4gHsTNj8eis4+tj5DS45hxV5pIvv29Ps+4ejIqm6N+wJTWWXp3Rg4dtv536qNgnXLvGM5+yoXMYg1Q=; 7:4lVWHw83BzOsUPkl1R0rBHup1R1nw6TvkXgJigCvgKz/gu69c4xKDIyLyZgkuzuSezt8SnBenTcwWBkjoX9f+sj8lhe70vi5dXt0FQWtOmQJbm6PWzaPTHdxYAqMQgJV+yV3eermZkZlDgdyjgm9tzpqVwKbyAUbzSjitBtKqhCUVSwhdjE8VdtO9rrjrANza4IobRHfcdLWsMAZNHJUPIpQE6qyEjuz8ix84tfMRQ1ldD7UwESRtLaiFf5TT5KU x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2155; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2155; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2155; x-forefront-prvs: 00286C0CA6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(377454003)(189002)(2906002)(9686002)(86362001)(189998001)(3660700001)(92566002)(68736007)(586003)(86612001)(3280700002)(99286002)(2900100001)(2950100001)(19580405001)(19580395003)(15975445007)(77096005)(6116002)(102836003)(87936001)(7846002)(76176999)(74316002)(5002640100001)(8990500004)(107886002)(8676002)(10090500001)(8936002)(106116001)(106356001)(10400500002)(5005710100001)(101416001)(10290500002)(33656002)(105586002)(81156014)(50986999)(54356999)(7736002)(7696003)(122556002)(2501003)(97736004)(5001770100001)(305945005)(11100500001)(76576001)(81166006)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2155; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 08 Aug 2016 19:46:22.5288 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2155 Archived-At: Subject: Re: [Unbearable] Renegotiation info extension 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, 08 Aug 2016 19:46:32 -0000 Yes, we can rephrase the security consideration in this more nuanced way. -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Martin T= homson Sent: Sunday, August 7, 2016 11:55 PM To: unbearable@ietf.org Subject: [Unbearable] Renegotiation info extension I know that this is probably old news, but there is an alternative to using= the renegotiation info extension. That is to forbid renegotiation entirel= y. We're at the point now where lots of implementations do this and some o= f them are not including the RI extension at the same time. For TB, rather than requiring RI, can we instead prohibit the use of renego= tiation if RI is not negotiated? _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable From nobody Mon Aug 8 14:20:11 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 ED41A12D17E for ; Mon, 8 Aug 2016 14:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, 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 mm3GCxg_xnSH for ; Mon, 8 Aug 2016 14:20:08 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 7F4C412D176 for ; Mon, 8 Aug 2016 14:20:08 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id 97so38779587uav.3 for ; Mon, 08 Aug 2016 14:20:08 -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=TxbN1hlxEYzYxG8VDZsjnkyzGHIw++z2ZBWOYaDzh14=; b=DUv7IgeWlHn5Al1+0Q5Q6fwnpYsdT+T/DyMuN2kDtkztXnV3hCAqkBaImIRK+JNG+s TP6nD8MqwoOcpkCXffoA4H5ybPGA54zy+Ekj16B2dS/CpBTDK4BUNt4GUMvEY9kqSdul Ee0+jxxWPnW2SZu7y9mXCziMpCDlSGJUk1Pqqqy8iQCoQYnHVD8GQXlhYuE8SU/CV2Gy 5hKgfhhuYyN0Zc424B1B7ea9T3cFCCxB5co+l60ZrLDUdh/Yo3u45Ofo5ccalYeN8+2X Cfz/NZSnVq7aT6VnxOB/u9wpgQWQOFZc+40O/7oMd98VBpdRXh9GusSKLKTUfkGrHCm5 2E6A== 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=TxbN1hlxEYzYxG8VDZsjnkyzGHIw++z2ZBWOYaDzh14=; b=MACRb4CPXlcKdH+4MrKoqYe0rR5poiilI9sr9413d1w1Wbf+xDlK0X3hpKwdX7XvEm gNiM2A+fWc40uB0C3fxjbWCpSVThe3Ld/t0ftX0juCBcLzEznaUgIup3n5sJtYpbexpc 8UlN0hLvgkmETeK8ZnHNS2ixj+E6AOY9fmu7D8kdApBSLgNnUUvrs3nMZLTsjaYCNiRV KsQG4/+bYOn+9Ts7+bWWYokny68IZiLJexVarw3YA0ohCrROQmFCDT52w9Zc7xzQLlMV HxhNgp+fkiJTo1ZjZRFfyq+UAZCRqGqARi7e4ZNEZnZVYkcFbHz95eTbFSiZg4uyCJmn wMlg== X-Gm-Message-State: AEkoous7Xgptg4aRrz2kXudlvWXgAYPclw7hihZujcSwMn6eb40/gUSAIqWvc7Ff3U6r85iUlpvCv6KN/ZwgB5OS X-Received: by 10.176.2.242 with SMTP id 105mr15539142uah.10.1470691207470; Mon, 08 Aug 2016 14:20:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.209 with HTTP; Mon, 8 Aug 2016 14:19:47 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Mon, 8 Aug 2016 14:19:47 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a1142e550ff4034053995fab3 Archived-At: Cc: "unbearable@ietf.org" , Martin Thomson Subject: Re: [Unbearable] Renegotiation info extension 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, 08 Aug 2016 21:20:10 -0000 --001a1142e550ff4034053995fab3 Content-Type: text/plain; charset=UTF-8 Chrome's Token Binding implementation takes the approach of forbidding renegotiation entirely. I would be in support of only allowing one of token binding or renegotiation on a connection, and then this consideration about RI becomes a moot point. On Mon, Aug 8, 2016 at 12:46 PM, Andrei Popov wrote: > Yes, we can rephrase the security consideration in this more nuanced way. > > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Martin > Thomson > Sent: Sunday, August 7, 2016 11:55 PM > To: unbearable@ietf.org > Subject: [Unbearable] Renegotiation info extension > > I know that this is probably old news, but there is an alternative to > using the renegotiation info extension. That is to forbid renegotiation > entirely. We're at the point now where lots of implementations do this and > some of them are not including the RI extension at the same time. > > For TB, rather than requiring RI, can we instead prohibit the use of > renegotiation if RI is not negotiated? > > _______________________________________________ > 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 > --001a1142e550ff4034053995fab3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Chrome's Token Binding implementation takes the approa= ch of forbidding renegotiation entirely. I would be in support of only allo= wing one of token binding or renegotiation on a connection, and then this c= onsideration about RI becomes a moot point.

On Mon, Aug 8, 2016 at 12:46 PM, Andrei Pop= ov <Andrei.Popov@microsoft.com> wrote:
Yes, we can rephrase the security consideration in th= is more nuanced way.

-----Original Message-----
From: Unbearable [mailto:unb= earable-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Sunday, August 7, 2016 11:55 PM
To: unbearable@ietf.org
Subject: [Unbearable] Renegotiation info extension

I know that this is probably old news, but there is an alternative to using= the renegotiation info extension.=C2=A0 That is to forbid renegotiation en= tirely.=C2=A0 We're at the point now where lots of implementations do t= his and some of them are not including the RI extension at the same time.
For TB, rather than requiring RI, can we instead prohibit the use of renego= tiation if RI is not negotiated?

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

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

--001a1142e550ff4034053995fab3-- From nobody Mon Aug 8 14:24:51 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 55B8112D145 for ; Mon, 8 Aug 2016 14:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 HkgFuGzzL2mT for ; Mon, 8 Aug 2016 14:24:47 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0103.outbound.protection.outlook.com [104.47.41.103]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EB7112D131 for ; Mon, 8 Aug 2016 14:24:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RRtTeEPjOPcE/ceDaJZBA4+MgJn4Kstz3PJY2NZ9QS4=; b=aa1g/xOjs3JX4cOSr/tsCMd0ddXey8h1Dq3kTFMDHOsGJvpQEJ4xzcQkFJe0PAFNIajU4a1sXwzrwpM4uAC/N7YCZuAFSre+38ufe8gi2Tc92cQHZxZdEU5P7nF/4i6KTON8nYin7MJ6gmDBxvWodj7/JXMGwHYc+oniYGZRwXE= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2154.namprd03.prod.outlook.com (10.166.206.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 8 Aug 2016 21:24:44 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0549.025; Mon, 8 Aug 2016 21:24:44 +0000 From: Andrei Popov To: Nick Harper Thread-Topic: [Unbearable] Renegotiation info extension Thread-Index: AQHR8UG+1juUPHgk7k6r83vWCBCSUaA/dqjAgAAcAoCAAABzoA== Date: Mon, 8 Aug 2016 21:24:44 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:d::1d2] x-ms-office365-filtering-correlation-id: bc351bbe-c026-428e-88fd-08d3bfd26afa x-microsoft-exchange-diagnostics: 1; CY1PR03MB2154; 6:LJSpTfht3WqDm8I4de8XLrQqrAOxfGyrttuxGyxTd4JuABV6Bzur3N9ojaEPc3GXgYcxRT07cCWRRizZJdDS8PIVzt5UvMXTv0ZQY7ogSvEhERmBwST965BzTXg9Z8rygOZNoRTW1rNKSZfSFoXwTjAxSr1gY4rAdGXuqB0ZD+QTAqUIt3mxEBiZicmaNnEsyCfQ/v4GXTnjNFx/HNI2gx0gwxMZbuswK1Kv7Dn0SvzE6GMt0ZrpzeWXWeCpzEQoKfZrCjSuJ/05LPY8toeZ/YKEyBOp9BmFBEuMhVxpPJvTm9QAZ/JWOX6hQNAgT23TkMzwbFFZD7ZGHmZ96grmKQ==; 5:oeDU0q4n/0Q0RBbTQ82tvepUsrqGcjp05ZH2ItEkiYCGad4WWuG14uWEs39CHhY2+TSdjPLQ00mTLMosi4rT4ZddWc3477ZKb2n+YnKKp4gXlawCO9tMtpSVq1SPBLNuQHkpe5oI/s6jikjvFQUxWA==; 24:GBmZICNo/EbLnslw/bcvqP35WeCAMQ9MS0jtuLD7MIA6ZyTdxF6FCn6QPqd8Huu2LfFBbe1J0uiNDRfS6OXY3MKJvUFy0CkoxsKoGPZHfX0=; 7:awI+3q7JjPrEUyvT98R96xXE52aV0iCtteU3q1jqRLl2vajtktA3Kc4kKS+k5+XAOSZaixIxwE/nRukBIjEDCKCCR3B+DlcBqW5KEpoq2KUy7TgsBszxu1tvgK0IN+xbiLaEr9Z9OS2dqoA2UoeVS2VCQvImO+Ex6EQ3kzcj7bcese2uMpJSSGIV7mWfIAnXQKsx0G7qR2mfodQUEqDt4UDQyrvVGW2D10L4o710nQzwWdi4txQzJzc0tquk+/of x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2154; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2154; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2154; x-forefront-prvs: 00286C0CA6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(24454002)(13464003)(377454003)(199003)(189998001)(97736004)(7906003)(10090500001)(7696003)(7846002)(7736002)(122556002)(110136002)(8990500004)(19609705001)(19580405001)(19580395003)(92566002)(86362001)(74316002)(10400500002)(3660700001)(87936001)(3280700002)(77096005)(15975445007)(2950100001)(86612001)(10290500002)(5005710100001)(76576001)(102836003)(790700001)(6116002)(2900100001)(4326007)(2906002)(9686002)(54356999)(105586002)(99286002)(16236675004)(19300405004)(19625215002)(101416001)(11100500001)(8676002)(19617315012)(50986999)(76176999)(81166006)(106356001)(106116001)(586003)(8936002)(5002640100001)(68736007)(81156014)(33656002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2154; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB21559B7D89B6BC6B52D633078C1B0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2016 21:24:44.6411 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2154 Archived-At: Cc: "unbearable@ietf.org" , Martin Thomson Subject: Re: [Unbearable] Renegotiation info extension 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, 08 Aug 2016 21:24:49 -0000 --_000_CY1PR03MB21559B7D89B6BC6B52D633078C1B0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SUUvSUlTIHVzZSByZW5lZ290aWF0aW9uIGEgbG90LCBzbyBDaHJvbWXigJlzIGFwcHJvYWNoIHdv dWxkIG5vdCB3b3JrIGZvciB1cywgYnV0IE1hcnRpbuKAmXMgbnVhbmNlZCBsYW5ndWFnZSBkb2Vz Lg0KDQpGcm9tOiBOaWNrIEhhcnBlciBbbWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbV0NClNlbnQ6 IE1vbmRheSwgQXVndXN0IDgsIDIwMTYgMjoyMCBQTQ0KVG86IEFuZHJlaSBQb3BvdiA8QW5kcmVp LlBvcG92QG1pY3Jvc29mdC5jb20+DQpDYzogTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29u QGdtYWlsLmNvbT47IHVuYmVhcmFibGVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJs ZV0gUmVuZWdvdGlhdGlvbiBpbmZvIGV4dGVuc2lvbg0KDQpDaHJvbWUncyBUb2tlbiBCaW5kaW5n IGltcGxlbWVudGF0aW9uIHRha2VzIHRoZSBhcHByb2FjaCBvZiBmb3JiaWRkaW5nIHJlbmVnb3Rp YXRpb24gZW50aXJlbHkuIEkgd291bGQgYmUgaW4gc3VwcG9ydCBvZiBvbmx5IGFsbG93aW5nIG9u ZSBvZiB0b2tlbiBiaW5kaW5nIG9yIHJlbmVnb3RpYXRpb24gb24gYSBjb25uZWN0aW9uLCBhbmQg dGhlbiB0aGlzIGNvbnNpZGVyYXRpb24gYWJvdXQgUkkgYmVjb21lcyBhIG1vb3QgcG9pbnQuDQoN Ck9uIE1vbiwgQXVnIDgsIDIwMTYgYXQgMTI6NDYgUE0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBv cG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3Jv dGU6DQpZZXMsIHdlIGNhbiByZXBocmFzZSB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBpbiB0 aGlzIG1vcmUgbnVhbmNlZCB3YXkuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp1 bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb24N ClNlbnQ6IFN1bmRheSwgQXVndXN0IDcsIDIwMTYgMTE6NTUgUE0NClRvOiB1bmJlYXJhYmxlQGll dGYub3JnPG1haWx0bzp1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogW1VuYmVhcmFibGVd IFJlbmVnb3RpYXRpb24gaW5mbyBleHRlbnNpb24NCg0KSSBrbm93IHRoYXQgdGhpcyBpcyBwcm9i YWJseSBvbGQgbmV3cywgYnV0IHRoZXJlIGlzIGFuIGFsdGVybmF0aXZlIHRvIHVzaW5nIHRoZSBy ZW5lZ290aWF0aW9uIGluZm8gZXh0ZW5zaW9uLiAgVGhhdCBpcyB0byBmb3JiaWQgcmVuZWdvdGlh dGlvbiBlbnRpcmVseS4gIFdlJ3JlIGF0IHRoZSBwb2ludCBub3cgd2hlcmUgbG90cyBvZiBpbXBs ZW1lbnRhdGlvbnMgZG8gdGhpcyBhbmQgc29tZSBvZiB0aGVtIGFyZSBub3QgaW5jbHVkaW5nIHRo ZSBSSSBleHRlbnNpb24gYXQgdGhlIHNhbWUgdGltZS4NCg0KRm9yIFRCLCByYXRoZXIgdGhhbiBy ZXF1aXJpbmcgUkksIGNhbiB3ZSBpbnN0ZWFkIHByb2hpYml0IHRoZSB1c2Ugb2YgcmVuZWdvdGlh dGlvbiBpZiBSSSBpcyBub3QgbmVnb3RpYXRlZD8NCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0DQpVbmJlYXJh YmxlQGlldGYub3JnPG1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KVW5i ZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZQ0KDQo= --_000_CY1PR03MB21559B7D89B6BC6B52D633078C1B0CY1PR03MB2155namp_ 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 IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklFL0lJUyB1c2UgcmVuZWdvdGlhdGlvbiBhIGxvdCwgc28g Q2hyb21l4oCZcyBhcHByb2FjaCB3b3VsZCBub3Qgd29yayBmb3IgdXMsIGJ1dCBNYXJ0aW7igJlz IG51YW5jZWQgbGFuZ3VhZ2UgZG9lcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IE5pY2sgSGFycGVyIFttYWlsdG86bmhhcnBlckBnb29nbGUuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDgsIDIwMTYgMjoyMCBQTTxicj4N CjxiPlRvOjwvYj4gQW5kcmVpIFBvcG92ICZsdDtBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4udGhvbXNvbkBnbWFp bC5jb20mZ3Q7OyB1bmJlYXJhYmxlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb VW5iZWFyYWJsZV0gUmVuZWdvdGlhdGlvbiBpbmZvIGV4dGVuc2lvbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNocm9tZSdzIFRva2VuIEJpbmRpbmcgaW1wbGVtZW50YXRp b24gdGFrZXMgdGhlIGFwcHJvYWNoIG9mIGZvcmJpZGRpbmcgcmVuZWdvdGlhdGlvbiBlbnRpcmVs eS4gSSB3b3VsZCBiZSBpbiBzdXBwb3J0IG9mIG9ubHkgYWxsb3dpbmcgb25lIG9mIHRva2VuIGJp bmRpbmcgb3IgcmVuZWdvdGlhdGlvbiBvbiBhIGNvbm5lY3Rpb24sIGFuZCB0aGVuIHRoaXMgY29u c2lkZXJhdGlvbiBhYm91dCBSSSBiZWNvbWVzIGENCiBtb290IHBvaW50LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBdWcgOCwgMjAxNiBhdCAx Mjo0NiBQTSwgQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1p Y3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlllcywgd2UgY2FuIHJlcGhyYXNlIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIGlu IHRoaXMgbW9yZSBudWFuY2VkIHdheS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpG cm9tOiBVbmJlYXJhYmxlIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnVuYmVhcmFibGUtYm91bmNl c0BpZXRmLm9yZyI+dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9m IE1hcnRpbiBUaG9tc29uPGJyPg0KU2VudDogU3VuZGF5LCBBdWd1c3QgNywgMjAxNiAxMTo1NSBQ TTxicj4NClRvOiA8YSBocmVmPSJtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZyI+dW5iZWFyYWJs ZUBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBbVW5iZWFyYWJsZV0gUmVuZWdvdGlhdGlvbiBp bmZvIGV4dGVuc2lvbjxicj4NCjxicj4NCkkga25vdyB0aGF0IHRoaXMgaXMgcHJvYmFibHkgb2xk IG5ld3MsIGJ1dCB0aGVyZSBpcyBhbiBhbHRlcm5hdGl2ZSB0byB1c2luZyB0aGUgcmVuZWdvdGlh dGlvbiBpbmZvIGV4dGVuc2lvbi4mbmJzcDsgVGhhdCBpcyB0byBmb3JiaWQgcmVuZWdvdGlhdGlv biBlbnRpcmVseS4mbmJzcDsgV2UncmUgYXQgdGhlIHBvaW50IG5vdyB3aGVyZSBsb3RzIG9mIGlt cGxlbWVudGF0aW9ucyBkbyB0aGlzIGFuZCBzb21lIG9mIHRoZW0gYXJlIG5vdCBpbmNsdWRpbmcg dGhlIFJJDQogZXh0ZW5zaW9uIGF0IHRoZSBzYW1lIHRpbWUuPGJyPg0KPGJyPg0KRm9yIFRCLCBy YXRoZXIgdGhhbiByZXF1aXJpbmcgUkksIGNhbiB3ZSBpbnN0ZWFkIHByb2hpYml0IHRoZSB1c2Ug b2YgcmVuZWdvdGlhdGlvbiBpZiBSSSBpcyBub3QgbmVnb3RpYXRlZD88YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClVuYmVhcmFi bGUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmci PlVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlPC9hPjxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVW5iZWFy YWJsZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9y ZyI+VW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGU8L2E+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_CY1PR03MB21559B7D89B6BC6B52D633078C1B0CY1PR03MB2155namp_-- From nobody Mon Aug 8 14:45:25 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 568F412D537 for ; Mon, 8 Aug 2016 14:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, 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 LY6IebRjavoV for ; Mon, 8 Aug 2016 14:45:16 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 7F8E912D529 for ; Mon, 8 Aug 2016 14:45:16 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id 74so89379959uau.0 for ; Mon, 08 Aug 2016 14:45:16 -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=CY7pPa0xwg7mjHckjuQE2ZZiH+xq8UlY2qDJLljqljY=; b=NAQRRaRXCMOBKCfTVtninc9WNxQAOpFjay/LlrB3YBDVoX/Q9YUuznqn9Zs4qyV1mE p50PUW6Vz0ipicKLL7MtKkinXICobh7Qwh7LOgaRd9yCzchzwYCCtVvYNUwhq+LKSHN/ YPyCXuGXiMCW+urrxVb3TPusxG1lbDui4eOzB4ACZE+OxFMhOPqfMPvayEvdP8jYnuP6 nNYL7+yZIzDIStStJOUaMsHY4ZUu3smnmt98CLpy43a0J2th8jRkGHknyECwEcF/rIII pEWt9tT1337l7vth6VHmX3QeewOxAkeql6c6lhV/46ydQXDVFtVPmLXPE88KDMzl2tg+ yApQ== 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=CY7pPa0xwg7mjHckjuQE2ZZiH+xq8UlY2qDJLljqljY=; b=CL4tSdPcSJ8+AJl/bwoNwJWsranJnuDlId/sKfdUSi5nibHiefpNhSYRqp2BwZz2M2 rzxb9ZZWxq8SdI603nu3c+jP0iKZ7fsNFomEz3fvQd5TZoJz4ioVXgWkguriQOqn0hCb 9v3HUsXCEsE1BjIw2KE97JMP6tp507Jb6z2xFc6T5X5jZ8l0Ivdh1RcmvsFQwMJYsjHP YxkiB9hrwShOfaZqsQO4mYAm0uNozI1gDPfTwOgDaDo50CZQKQDUCnEkkoufHdzJuLq6 5ugAIjC3TL9jg3S3aHFaNrM5m5/sWnYfxw5l7gOCFOqNMGENgyBPjp1Ct6FqNkGkUWVe Fk0A== X-Gm-Message-State: AEkoouuZR4VcWJEGjafikPfX57NP6+IOMEC+57SQdHUh1tN7JWu9tjShMNQYFr2/feUopIUJnU5+QEistMR2jYmV X-Received: by 10.176.2.242 with SMTP id 105mr15588570uah.10.1470692715432; Mon, 08 Aug 2016 14:45:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.209 with HTTP; Mon, 8 Aug 2016 14:44:55 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Mon, 8 Aug 2016 14:44:55 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a1142e550e102b705399654ab Archived-At: Cc: "unbearable@ietf.org" , Martin Thomson Subject: Re: [Unbearable] Renegotiation info extension 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, 08 Aug 2016 21:45:24 -0000 --001a1142e550e102b705399654ab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If we want to support TB and renego, there are several things that need to be considered and clarified in the spec: If the state of extended master secret changes, what should happen? (I don't think this should be allowed) What's allowed to change in terms of Token Binding key params during a renegotiation? I think that it must stay the same - if Token Binding is negotiated, the same key param must be negotiated on both handshakes; inversely if Token Binding is not negotiated in the first handshake, then it must not be negotiated in the second. Even more details needs to go to what EKM value should be signed at any given point. Renegotiation can technically interleave with application data, so this seems quite ill-defined for what a TokenBindingMessage should include for a signature if it is sent in application data in the middle of a renegotiation. Suppose a renegotiation happens between a client's http request and the server's response (as is I believe the case for IIS with http/1.1). The client's request would contain a TokenBindingMessage with a signature over the original EKM, but when the server is sending the response the connection now has a new EKM, so the server needs to remember the old EKM to verify the signature. I imagine things get much more complicated with http2. On Mon, Aug 8, 2016 at 2:24 PM, Andrei Popov wrote: > IE/IIS use renegotiation a lot, so Chrome=E2=80=99s approach would not wo= rk for > us, but Martin=E2=80=99s nuanced language does. > > > > *From:* Nick Harper [mailto:nharper@google.com] > *Sent:* Monday, August 8, 2016 2:20 PM > *To:* Andrei Popov > *Cc:* Martin Thomson ; unbearable@ietf.org > *Subject:* Re: [Unbearable] Renegotiation info extension > > > > Chrome's Token Binding implementation takes the approach of forbidding > renegotiation entirely. I would be in support of only allowing one of tok= en > binding or renegotiation on a connection, and then this consideration abo= ut > RI becomes a moot point. > > > > On Mon, Aug 8, 2016 at 12:46 PM, Andrei Popov > wrote: > > Yes, we can rephrase the security consideration in this more nuanced way. > > > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Martin > Thomson > Sent: Sunday, August 7, 2016 11:55 PM > To: unbearable@ietf.org > Subject: [Unbearable] Renegotiation info extension > > I know that this is probably old news, but there is an alternative to > using the renegotiation info extension. That is to forbid renegotiation > entirely. We're at the point now where lots of implementations do this a= nd > some of them are not including the RI extension at the same time. > > For TB, rather than requiring RI, can we instead prohibit the use of > renegotiation if RI is not negotiated? > > _______________________________________________ > 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 > > > --001a1142e550e102b705399654ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If we want to support TB and renego, there are several thi= ngs that need to be considered and clarified in the spec:

If t= he state of extended master secret changes, what should happen? (I don'= t think this should be allowed)
What's allowed to change in t= erms of Token Binding key params during a renegotiation? I think that it mu= st stay the same - if Token Binding is negotiated, the same key param must = be negotiated on both handshakes; inversely if Token Binding is not negotia= ted in the first handshake, then it must not be negotiated in the second.

Even more details needs to go to what EKM value sho= uld be signed at any given point. Renegotiation can technically interleave = with application data, so this seems quite ill-defined for what a TokenBind= ingMessage should include for a signature if it is sent in application data= in the middle of a renegotiation.
Suppose a renegotiation = happens between a client's http request and the server's response (= as is I believe the case for IIS with http/1.1). The client's request w= ould contain a TokenBindingMessage with a signature over the original EKM, = but when the server is sending the response the connection now has a new EK= M, so the server needs to remember the old EKM to verify the signature. I i= magine things get much more complicated with http2.

On Mon, Aug 8, 2016 at 2:24= PM, Andrei Popov <Andrei.Popov@microsoft.com> wrot= e:

IE/IIS use renegotiation a lot, so Chrome=E2=80=99s= approach would not work for us, but Martin=E2=80=99s nuanced language does= .

=C2=A0

From: Nick Harper [mailto:nharper@google.com]
Sent: Monday, August 8, 2016 2:20 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Martin Thomson <martin.thomson@gmail.com>; unbearable@ietf.org
Subject: Re: [Unbearable] Renegotiation info extension=

=C2=A0

Chrome's Token Binding implementation takes the = approach of forbidding renegotiation entirely. I would be in support of onl= y allowing one of token binding or renegotiation on a connection, and then = this consideration about RI becomes a moot point.

=C2=A0

On Mon, Aug 8, 2016 at 12:46 PM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

Yes, we can rephrase the security consideration in t= his more nuanced way.


-----Original Message-----
From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Martin Th= omson
Sent: Sunday, August 7, 2016 11:55 PM
To: unbearable@iet= f.org
Subject: [Unbearable] Renegotiation info extension

I know that this is probably old news, but there is an alternative to using= the renegotiation info extension.=C2=A0 That is to forbid renegotiation en= tirely.=C2=A0 We're at the point now where lots of implementations do t= his and some of them are not including the RI extension at the same time.

For TB, rather than requiring RI, can we instead prohibit the use of renego= tiation if RI is not negotiated?

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

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

=C2=A0


--001a1142e550e102b705399654ab-- From nobody Mon Aug 8 15:27:35 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 82A4F12D0F9 for ; Mon, 8 Aug 2016 15:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 WBAbqFKhODPM for ; Mon, 8 Aug 2016 15:27:30 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0125.outbound.protection.outlook.com [104.47.38.125]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8909812D0CB for ; Mon, 8 Aug 2016 15:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FxEzfd17krN4MbfZWpqA6l3mHry6/p8pWLHbGEBXPYw=; b=dfX0LL013s8InjX6VoVq0S6PlXgFSse4+4YiTbJAZqs+an/BAqh/U7us9YsprEQ4iPliO3VD9ca4BfArZE5H6pe27IorzxA9KNXCSrUl1VMOoVNbzozO+uTJi0IDniI5+iFC28CvS2shnjweDF9oQf8mJRy/5K01dU7FikENcgM= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2156.namprd03.prod.outlook.com (10.166.206.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Mon, 8 Aug 2016 22:27:27 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0549.025; Mon, 8 Aug 2016 22:27:27 +0000 From: Andrei Popov To: Nick Harper Thread-Topic: [Unbearable] Renegotiation info extension Thread-Index: AQHR8UG+1juUPHgk7k6r83vWCBCSUaA/dqjAgAAcAoCAAABzoIAABpOAgAAHYiA= Date: Mon, 8 Aug 2016 22:27:27 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:d::1d2] x-ms-office365-filtering-correlation-id: 68589072-4a25-43dd-42c1-08d3bfdb2de6 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2156; 6:S8YOLEgqptGZXcicmBMuKyVtq4nxmfRzhfC/nrhGY7zvn1sltFn4Na9ZYbuYi/wq0qtO+eg2c+HxXeJj4DbNwYo+GwPASqE3rjKHNPBg8mFSLzZDbgbayv3eEWEERaalZ5DqSJYrHk+2K2hQDT0P3S/ffCW0wiTMW1keIeHAKbnZg2oul0+MBZRxJpuqTo8mbuvMRF0TJKHTHJca8EiIBxtcgQVNjg4j5nEcoax0cTTBQe1aVuddzdoIT9ykNi7bFWpwYBeLhMD0ulnIW7mH6u26xtqmTTEOYZcC9FA+rh80GLTcRnW1vzBmxGEy4peScyjnjsnB4zEu9mJ92NvT7A==; 5:LFZoBLKiAs/P5YiE5NcoLgWt3cqrzVS35TtIiiCStcIspzwtmq7XWtvpc0VmV0esny2gxb7MXBG7wJnamnpML8PW7IVzmae5EOEXNalVBOApN8emyikr5gfaj2CZuJ52uH+Jc5rQvcfh2JBRli/Gnw==; 24:+cCO33JStGXtjQ8LBxRfrzEjfvK55T6Q97iyHvMCIIoN7rBHs31qchA6zcqz9Z/13m8zGhcDofFujG26HiT+VrhA6Z1x14ypgqhpC5LPQwI=; 7:TtRejRtIB/6OJl5CGNOU7pGa7QumAVJVKtwZI1eYSYlzSksVGtgk+Ur/G7frvZTji5W0GvLoctsKoSKUo8jCoH0+gM1Bkbdld7ENQ5E/JWBcN/SVvDCjhq+gHHGMVGH6nCdF4ysGDrBk2hmk+d6j0BmErXtI3mC1EN3nzxmj23R7bshSreOc9okhJZOjj1b4UxU05Sl8K45WjhiKdbOtLTW894HhIdijy6GZdI647ikzryXc3qawsjcIDGUZfIdA x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2156; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2156; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2156; x-forefront-prvs: 00286C0CA6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(51444003)(24454002)(13464003)(377454003)(199003)(2906002)(3280700002)(3660700001)(8990500004)(4326007)(5002640100001)(86362001)(10290500002)(586003)(7736002)(81166006)(10400500002)(7696003)(33656002)(16236675004)(81156014)(76576001)(5005710100001)(122556002)(68736007)(7906003)(7846002)(10090500001)(11100500001)(9686002)(8676002)(92566002)(790700001)(74316002)(6116002)(102836003)(76176999)(8936002)(15975445007)(2950100001)(93886004)(19580395003)(2900100001)(77096005)(86612001)(189998001)(110136002)(19580405001)(19300405004)(105586002)(106356001)(50986999)(106116001)(19617315012)(54356999)(99286002)(97736004)(87936001)(101416001)(19625215002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2156; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB215599ADE9205B37647F7FFB8C1B0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2016 22:27:27.6568 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2156 Archived-At: Cc: "unbearable@ietf.org" , Martin Thomson Subject: Re: [Unbearable] Renegotiation info extension 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, 08 Aug 2016 22:27:33 -0000 --_000_CY1PR03MB215599ADE9205B37647F7FFB8C1B0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIElmIHRoZSBzdGF0ZSBvZiBleHRlbmRlZCBtYXN0ZXIgc2VjcmV0IGNoYW5nZXMsIHdoYXQg c2hvdWxkIGhhcHBlbj8NCkVNUyBpcyByZXF1aXJlZCB3aGVuIFRMUyA8PTEuMiBpcyB1c2VkIHdp dGggVEIsIHNlZSBUQlBST1RPIHNlY3Rpb24gOC41LCBzbyBFTVMgc3RhdGUgY2Fubm90IGNoYW5n ZS4NCg0KDQrDmCAgV2hhdCdzIGFsbG93ZWQgdG8gY2hhbmdlIGluIHRlcm1zIG9mIFRva2VuIEJp bmRpbmcga2V5IHBhcmFtcyBkdXJpbmcgYSByZW5lZ290aWF0aW9uPw0KVGhlIGNsaWVudCB1c2Vz IHRoZSB0b2tlbl9iaW5kaW5nIGV4dGVuc2lvbiBpbiBlYWNoIFRMUyBoYW5kc2hha2UsIHNvIGF0 IGxlYXN0IGluIHRoZW9yeSBhbnkgVEIgcGFyYW1ldGVycyBjYW4gY2hhbmdlLg0KDQoNCsOYICBT dXBwb3NlIGEgcmVuZWdvdGlhdGlvbiBoYXBwZW5zIGJldHdlZW4gYSBjbGllbnQncyBodHRwIHJl cXVlc3QgYW5kIHRoZSBzZXJ2ZXIncyByZXNwb25zZSAoYXMgaXMgSSBiZWxpZXZlIHRoZSBjYXNl IGZvciBJSVMgd2l0aCBodHRwLzEuMSkuIFRoZSBjbGllbnQncyByZXF1ZXN0IHdvdWxkIGNvbnRh aW4gYSBUb2tlbkJpbmRpbmdNZXNzYWdlIHdpdGggYSBzaWduYXR1cmUgb3ZlciB0aGUgb3JpZ2lu YWwgRUtNLCBidXQgd2hlbiB0aGUgc2VydmVyIGlzIHNlbmRpbmcgdGhlIHJlc3BvbnNlIHRoZSBj b25uZWN0aW9uIG5vdyBoYXMgYSBuZXcgRUtNLCBzbyB0aGUgc2VydmVyIG5lZWRzIHRvIHJlbWVt YmVyIHRoZSBvbGQgRUtNIHRvIHZlcmlmeSB0aGUgc2lnbmF0dXJlLg0KSWYgVEIgaXMgbmVnb3Rp YXRlZCBhcyBwYXJ0IG9mIHRoZSByZW5lZ290aWF0aW9uIGhhbmRzaGFrZSwgdGhlIGNsaWVudCBu ZWVkcyB0byBzZW5kIHRoZSBUQiBtZXNzYWdlIGluIHRoZSBuZXdseSBlc3RhYmxpc2hlZCBUTFMg c2Vzc2lvbiwgdXNpbmcgdGhlIG5ldyBFS00uDQoNCkZyb206IE5pY2sgSGFycGVyIFttYWlsdG86 bmhhcnBlckBnb29nbGUuY29tXQ0KU2VudDogTW9uZGF5LCBBdWd1c3QgOCwgMjAxNiAyOjQ1IFBN DQpUbzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4NCkNjOiBNYXJ0 aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPjsgdW5iZWFyYWJsZUBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBSZW5lZ290aWF0aW9uIGluZm8gZXh0ZW5zaW9u DQoNCklmIHdlIHdhbnQgdG8gc3VwcG9ydCBUQiBhbmQgcmVuZWdvLCB0aGVyZSBhcmUgc2V2ZXJh bCB0aGluZ3MgdGhhdCBuZWVkIHRvIGJlIGNvbnNpZGVyZWQgYW5kIGNsYXJpZmllZCBpbiB0aGUg c3BlYzoNCg0KSWYgdGhlIHN0YXRlIG9mIGV4dGVuZGVkIG1hc3RlciBzZWNyZXQgY2hhbmdlcywg d2hhdCBzaG91bGQgaGFwcGVuPyAoSSBkb24ndCB0aGluayB0aGlzIHNob3VsZCBiZSBhbGxvd2Vk KQ0KV2hhdCdzIGFsbG93ZWQgdG8gY2hhbmdlIGluIHRlcm1zIG9mIFRva2VuIEJpbmRpbmcga2V5 IHBhcmFtcyBkdXJpbmcgYSByZW5lZ290aWF0aW9uPyBJIHRoaW5rIHRoYXQgaXQgbXVzdCBzdGF5 IHRoZSBzYW1lIC0gaWYgVG9rZW4gQmluZGluZyBpcyBuZWdvdGlhdGVkLCB0aGUgc2FtZSBrZXkg cGFyYW0gbXVzdCBiZSBuZWdvdGlhdGVkIG9uIGJvdGggaGFuZHNoYWtlczsgaW52ZXJzZWx5IGlm IFRva2VuIEJpbmRpbmcgaXMgbm90IG5lZ290aWF0ZWQgaW4gdGhlIGZpcnN0IGhhbmRzaGFrZSwg dGhlbiBpdCBtdXN0IG5vdCBiZSBuZWdvdGlhdGVkIGluIHRoZSBzZWNvbmQuDQoNCkV2ZW4gbW9y ZSBkZXRhaWxzIG5lZWRzIHRvIGdvIHRvIHdoYXQgRUtNIHZhbHVlIHNob3VsZCBiZSBzaWduZWQg YXQgYW55IGdpdmVuIHBvaW50LiBSZW5lZ290aWF0aW9uIGNhbiB0ZWNobmljYWxseSBpbnRlcmxl YXZlIHdpdGggYXBwbGljYXRpb24gZGF0YSwgc28gdGhpcyBzZWVtcyBxdWl0ZSBpbGwtZGVmaW5l ZCBmb3Igd2hhdCBhIFRva2VuQmluZGluZ01lc3NhZ2Ugc2hvdWxkIGluY2x1ZGUgZm9yIGEgc2ln bmF0dXJlIGlmIGl0IGlzIHNlbnQgaW4gYXBwbGljYXRpb24gZGF0YSBpbiB0aGUgbWlkZGxlIG9m IGEgcmVuZWdvdGlhdGlvbi4NClN1cHBvc2UgYSByZW5lZ290aWF0aW9uIGhhcHBlbnMgYmV0d2Vl biBhIGNsaWVudCdzIGh0dHAgcmVxdWVzdCBhbmQgdGhlIHNlcnZlcidzIHJlc3BvbnNlIChhcyBp cyBJIGJlbGlldmUgdGhlIGNhc2UgZm9yIElJUyB3aXRoIGh0dHAvMS4xKS4gVGhlIGNsaWVudCdz IHJlcXVlc3Qgd291bGQgY29udGFpbiBhIFRva2VuQmluZGluZ01lc3NhZ2Ugd2l0aCBhIHNpZ25h dHVyZSBvdmVyIHRoZSBvcmlnaW5hbCBFS00sIGJ1dCB3aGVuIHRoZSBzZXJ2ZXIgaXMgc2VuZGlu ZyB0aGUgcmVzcG9uc2UgdGhlIGNvbm5lY3Rpb24gbm93IGhhcyBhIG5ldyBFS00sIHNvIHRoZSBz ZXJ2ZXIgbmVlZHMgdG8gcmVtZW1iZXIgdGhlIG9sZCBFS00gdG8gdmVyaWZ5IHRoZSBzaWduYXR1 cmUuIEkgaW1hZ2luZSB0aGluZ3MgZ2V0IG11Y2ggbW9yZSBjb21wbGljYXRlZCB3aXRoIGh0dHAy Lg0KDQpPbiBNb24sIEF1ZyA4LCAyMDE2IGF0IDI6MjQgUE0sIEFuZHJlaSBQb3BvdiA8QW5kcmVp LlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4g d3JvdGU6DQpJRS9JSVMgdXNlIHJlbmVnb3RpYXRpb24gYSBsb3QsIHNvIENocm9tZeKAmXMgYXBw cm9hY2ggd291bGQgbm90IHdvcmsgZm9yIHVzLCBidXQgTWFydGlu4oCZcyBudWFuY2VkIGxhbmd1 YWdlIGRvZXMuDQoNCkZyb206IE5pY2sgSGFycGVyIFttYWlsdG86bmhhcnBlckBnb29nbGUuY29t PG1haWx0bzpuaGFycGVyQGdvb2dsZS5jb20+XQ0KU2VudDogTW9uZGF5LCBBdWd1c3QgOCwgMjAx NiAyOjIwIFBNDQpUbzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxt YWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+Pg0KQ2M6IE1hcnRpbiBUaG9tc29uIDxt YXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+ OyB1bmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzp1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtVbmJlYXJhYmxlXSBSZW5lZ290aWF0aW9uIGluZm8gZXh0ZW5zaW9uDQoNCkNocm9t ZSdzIFRva2VuIEJpbmRpbmcgaW1wbGVtZW50YXRpb24gdGFrZXMgdGhlIGFwcHJvYWNoIG9mIGZv cmJpZGRpbmcgcmVuZWdvdGlhdGlvbiBlbnRpcmVseS4gSSB3b3VsZCBiZSBpbiBzdXBwb3J0IG9m IG9ubHkgYWxsb3dpbmcgb25lIG9mIHRva2VuIGJpbmRpbmcgb3IgcmVuZWdvdGlhdGlvbiBvbiBh IGNvbm5lY3Rpb24sIGFuZCB0aGVuIHRoaXMgY29uc2lkZXJhdGlvbiBhYm91dCBSSSBiZWNvbWVz IGEgbW9vdCBwb2ludC4NCg0KT24gTW9uLCBBdWcgOCwgMjAxNiBhdCAxMjo0NiBQTSwgQW5kcmVp IFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92QG1p Y3Jvc29mdC5jb20+PiB3cm90ZToNClllcywgd2UgY2FuIHJlcGhyYXNlIHRoZSBzZWN1cml0eSBj b25zaWRlcmF0aW9uIGluIHRoaXMgbW9yZSBudWFuY2VkIHdheS4NCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBP ZiBNYXJ0aW4gVGhvbXNvbg0KU2VudDogU3VuZGF5LCBBdWd1c3QgNywgMjAxNiAxMTo1NSBQTQ0K VG86IHVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBbVW5iZWFyYWJsZV0gUmVuZWdvdGlhdGlvbiBpbmZvIGV4dGVuc2lvbg0KDQpJIGtub3cg dGhhdCB0aGlzIGlzIHByb2JhYmx5IG9sZCBuZXdzLCBidXQgdGhlcmUgaXMgYW4gYWx0ZXJuYXRp dmUgdG8gdXNpbmcgdGhlIHJlbmVnb3RpYXRpb24gaW5mbyBleHRlbnNpb24uICBUaGF0IGlzIHRv IGZvcmJpZCByZW5lZ290aWF0aW9uIGVudGlyZWx5LiAgV2UncmUgYXQgdGhlIHBvaW50IG5vdyB3 aGVyZSBsb3RzIG9mIGltcGxlbWVudGF0aW9ucyBkbyB0aGlzIGFuZCBzb21lIG9mIHRoZW0gYXJl IG5vdCBpbmNsdWRpbmcgdGhlIFJJIGV4dGVuc2lvbiBhdCB0aGUgc2FtZSB0aW1lLg0KDQpGb3Ig VEIsIHJhdGhlciB0aGFuIHJlcXVpcmluZyBSSSwgY2FuIHdlIGluc3RlYWQgcHJvaGliaXQgdGhl IHVzZSBvZiByZW5lZ290aWF0aW9uIGlmIFJJIGlzIG5vdCBuZWdvdGlhdGVkPw0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVW5iZWFyYWJsZSBtYWls aW5nIGxpc3QNClVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClVuYmVhcmFibGUg bWFpbGluZyBsaXN0DQpVbmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzpVbmJlYXJhYmxlQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQoN Cg0K --_000_CY1PR03MB215599ADE9205B37647F7FFB8C1B0CY1PR03MB2155namp_ 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 bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjIwMjM4MjA2NDk7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE5MDQ5NzM4NiAtMTkz MjMzNDE4MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0 YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGlu O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SWYgdGhlIHN0YXRlIG9mIGV4dGVuZGVkIG1hc3Rl ciBzZWNyZXQgY2hhbmdlcywgd2hhdCBzaG91bGQgaGFwcGVuPzxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5FTVMgaXMgcmVxdWlyZWQgd2hlbiBUTFMgJmx0Oz0xLjIgaXMgdXNlZCB3aXRoIFRCLCBzZWUg VEJQUk9UTyBzZWN0aW9uIDguNSwgc28gRU1TIHN0YXRlIGNhbm5vdCBjaGFuZ2UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2lu Z2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+V2hhdCdzIGFsbG93ZWQgdG8gY2hhbmdlIGluIHRlcm1zIG9mIFRv a2VuIEJpbmRpbmcga2V5IHBhcmFtcyBkdXJpbmcgYSByZW5lZ290aWF0aW9uPzxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5UaGUgY2xpZW50IHVzZXMgdGhlIHRva2VuX2JpbmRpbmcgZXh0ZW5zaW9uIGlu IGVhY2ggVExTIGhhbmRzaGFrZSwgc28gYXQgbGVhc3QgaW4gdGhlb3J5IGFueSBUQiBwYXJhbWV0 ZXJzIGNhbiBjaGFuZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps MCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+U3VwcG9zZSBhIHJlbmVn b3RpYXRpb24gaGFwcGVucyBiZXR3ZWVuIGEgY2xpZW50J3MgaHR0cCByZXF1ZXN0IGFuZCB0aGUg c2VydmVyJ3MgcmVzcG9uc2UgKGFzIGlzIEkgYmVsaWV2ZSB0aGUgY2FzZSBmb3IgSUlTIHdpdGgg aHR0cC8xLjEpLiBUaGUgY2xpZW50J3MgcmVxdWVzdCB3b3VsZCBjb250YWluIGEgVG9rZW5CaW5k aW5nTWVzc2FnZSB3aXRoIGEgc2lnbmF0dXJlIG92ZXIgdGhlIG9yaWdpbmFsDQogRUtNLCBidXQg d2hlbiB0aGUgc2VydmVyIGlzIHNlbmRpbmcgdGhlIHJlc3BvbnNlIHRoZSBjb25uZWN0aW9uIG5v dyBoYXMgYSBuZXcgRUtNLCBzbyB0aGUgc2VydmVyIG5lZWRzIHRvIHJlbWVtYmVyIHRoZSBvbGQg RUtNIHRvIHZlcmlmeSB0aGUgc2lnbmF0dXJlLjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JZiBUQiBp cyBuZWdvdGlhdGVkIGFzIHBhcnQgb2YgdGhlIHJlbmVnb3RpYXRpb24gaGFuZHNoYWtlLCB0aGUg Y2xpZW50IG5lZWRzIHRvIHNlbmQgdGhlIFRCIG1lc3NhZ2UgaW4gdGhlIG5ld2x5IGVzdGFibGlz aGVkIFRMUyBzZXNzaW9uLCB1c2luZyB0aGUgbmV3IEVLTS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE5pY2sgSGFycGVyIFttYWlsdG86bmhhcnBl ckBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDgsIDIwMTYg Mjo0NSBQTTxicj4NCjxiPlRvOjwvYj4gQW5kcmVpIFBvcG92ICZsdDtBbmRyZWkuUG9wb3ZAbWlj cm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb20mZ3Q7OyB1bmJlYXJhYmxlQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gUmVuZWdvdGlhdGlvbiBpbmZvIGV4dGVuc2lvbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlIHdhbnQgdG8gc3VwcG9ydCBU QiBhbmQgcmVuZWdvLCB0aGVyZSBhcmUgc2V2ZXJhbCB0aGluZ3MgdGhhdCBuZWVkIHRvIGJlIGNv bnNpZGVyZWQgYW5kIGNsYXJpZmllZCBpbiB0aGUgc3BlYzo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgc3RhdGUgb2YgZXh0ZW5kZWQgbWFzdGVyIHNlY3JldCBj aGFuZ2VzLCB3aGF0IHNob3VsZCBoYXBwZW4/IChJIGRvbid0IHRoaW5rIHRoaXMgc2hvdWxkIGJl IGFsbG93ZWQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5XaGF0J3MgYWxsb3dlZCB0byBjaGFuZ2UgaW4gdGVybXMgb2YgVG9rZW4gQmluZGluZyBr ZXkgcGFyYW1zIGR1cmluZyBhIHJlbmVnb3RpYXRpb24/IEkgdGhpbmsgdGhhdCBpdCBtdXN0IHN0 YXkgdGhlIHNhbWUgLSBpZiBUb2tlbiBCaW5kaW5nIGlzIG5lZ290aWF0ZWQsIHRoZSBzYW1lIGtl eSBwYXJhbSBtdXN0IGJlIG5lZ290aWF0ZWQgb24gYm90aCBoYW5kc2hha2VzOyBpbnZlcnNlbHkg aWYgVG9rZW4gQmluZGluZw0KIGlzIG5vdCBuZWdvdGlhdGVkIGluIHRoZSBmaXJzdCBoYW5kc2hh a2UsIHRoZW4gaXQgbXVzdCBub3QgYmUgbmVnb3RpYXRlZCBpbiB0aGUgc2Vjb25kLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FdmVuIG1vcmUg ZGV0YWlscyBuZWVkcyB0byBnbyB0byB3aGF0IEVLTSB2YWx1ZSBzaG91bGQgYmUgc2lnbmVkIGF0 IGFueSBnaXZlbiBwb2ludC4gUmVuZWdvdGlhdGlvbiBjYW4gdGVjaG5pY2FsbHkgaW50ZXJsZWF2 ZSB3aXRoIGFwcGxpY2F0aW9uIGRhdGEsIHNvIHRoaXMgc2VlbXMgcXVpdGUgaWxsLWRlZmluZWQg Zm9yIHdoYXQgYSBUb2tlbkJpbmRpbmdNZXNzYWdlIHNob3VsZCBpbmNsdWRlIGZvciBhIHNpZ25h dHVyZQ0KIGlmIGl0IGlzIHNlbnQgaW4gYXBwbGljYXRpb24gZGF0YSBpbiB0aGUgbWlkZGxlIG9m IGEgcmVuZWdvdGlhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VwcG9zZSBhIHJlbmVnb3RpYXRpb24gaGFwcGVucyBiZXR3 ZWVuIGEgY2xpZW50J3MgaHR0cCByZXF1ZXN0IGFuZCB0aGUgc2VydmVyJ3MgcmVzcG9uc2UgKGFz IGlzIEkgYmVsaWV2ZSB0aGUgY2FzZSBmb3IgSUlTIHdpdGggaHR0cC8xLjEpLiBUaGUgY2xpZW50 J3MgcmVxdWVzdCB3b3VsZCBjb250YWluIGEgVG9rZW5CaW5kaW5nTWVzc2FnZSB3aXRoIGEgc2ln bmF0dXJlIG92ZXIgdGhlIG9yaWdpbmFsIEVLTSwNCiBidXQgd2hlbiB0aGUgc2VydmVyIGlzIHNl bmRpbmcgdGhlIHJlc3BvbnNlIHRoZSBjb25uZWN0aW9uIG5vdyBoYXMgYSBuZXcgRUtNLCBzbyB0 aGUgc2VydmVyIG5lZWRzIHRvIHJlbWVtYmVyIHRoZSBvbGQgRUtNIHRvIHZlcmlmeSB0aGUgc2ln bmF0dXJlLiBJIGltYWdpbmUgdGhpbmdzIGdldCBtdWNoIG1vcmUgY29tcGxpY2F0ZWQgd2l0aCBo dHRwMi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gTW9uLCBBdWcgOCwgMjAxNiBhdCAyOjI0IFBNLCBBbmRyZWkgUG9wb3YgJmx0OzxhIGhy ZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFu ZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+SUUvSUlTIHVzZSByZW5lZ290aWF0aW9uIGEgbG90LCBzbyBDaHJvbWXigJlzIGFw cHJvYWNoIHdvdWxkIG5vdCB3b3JrIGZvciB1cywgYnV0IE1hcnRpbuKAmXMgbnVhbmNlZCBsYW5n dWFnZSBkb2VzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IE5pY2sgSGFycGVyIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm5oYXJwZXJAZ29v Z2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5oYXJwZXJAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgOCwgMjAxNiAyOjIwIFBNPGJyPg0KPGI+VG86PC9i PiBBbmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDs8 YnI+DQo8Yj5DYzo8L2I+IE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGlu LnRob21zb25AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLnRob21zb25AZ21haWwu Y29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbVW5iZWFyYWJsZV0gUmVuZWdvdGlhdGlvbiBpbmZvIGV4dGVuc2lvbjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNocm9tZSdzIFRva2Vu IEJpbmRpbmcgaW1wbGVtZW50YXRpb24gdGFrZXMgdGhlIGFwcHJvYWNoIG9mIGZvcmJpZGRpbmcg cmVuZWdvdGlhdGlvbiBlbnRpcmVseS4gSSB3b3VsZCBiZSBpbiBzdXBwb3J0IG9mIG9ubHkgYWxs b3dpbmcgb25lIG9mIHRva2VuIGJpbmRpbmcgb3IgcmVuZWdvdGlhdGlvbiBvbiBhDQogY29ubmVj dGlvbiwgYW5kIHRoZW4gdGhpcyBjb25zaWRlcmF0aW9uIGFib3V0IFJJIGJlY29tZXMgYSBtb290 IHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pk9uIE1vbiwgQXVnIDgsIDIwMTYgYXQgMTI6NDYgUE0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5k cmVpLlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5ZZXMsIHdlIGNhbiByZXBocmFzZSB0aGUgc2VjdXJpdHkgY29uc2lkZXJh dGlvbiBpbiB0aGlzIG1vcmUgbnVhbmNlZCB3YXkuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08YnI+DQpGcm9tOiBVbmJlYXJhYmxlIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnVuYmVhcmFi bGUtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnVuYmVhcmFibGUtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBNYXJ0aW4gVGhvbXNvbjxicj4NClNlbnQ6IFN1bmRh eSwgQXVndXN0IDcsIDIwMTYgMTE6NTUgUE08YnI+DQpUbzogPGEgaHJlZj0ibWFpbHRvOnVuYmVh cmFibGVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51bmJlYXJhYmxlQGlldGYub3JnPC9hPjxi cj4NClN1YmplY3Q6IFtVbmJlYXJhYmxlXSBSZW5lZ290aWF0aW9uIGluZm8gZXh0ZW5zaW9uPGJy Pg0KPGJyPg0KSSBrbm93IHRoYXQgdGhpcyBpcyBwcm9iYWJseSBvbGQgbmV3cywgYnV0IHRoZXJl IGlzIGFuIGFsdGVybmF0aXZlIHRvIHVzaW5nIHRoZSByZW5lZ290aWF0aW9uIGluZm8gZXh0ZW5z aW9uLiZuYnNwOyBUaGF0IGlzIHRvIGZvcmJpZCByZW5lZ290aWF0aW9uIGVudGlyZWx5LiZuYnNw OyBXZSdyZSBhdCB0aGUgcG9pbnQgbm93IHdoZXJlIGxvdHMgb2YgaW1wbGVtZW50YXRpb25zIGRv IHRoaXMgYW5kIHNvbWUgb2YgdGhlbSBhcmUgbm90IGluY2x1ZGluZyB0aGUgUkkNCiBleHRlbnNp b24gYXQgdGhlIHNhbWUgdGltZS48YnI+DQo8YnI+DQpGb3IgVEIsIHJhdGhlciB0aGFuIHJlcXVp cmluZyBSSSwgY2FuIHdlIGluc3RlYWQgcHJvaGliaXQgdGhlIHVzZSBvZiByZW5lZ290aWF0aW9u IGlmIFJJIGlzIG5vdCBuZWdvdGlhdGVkPzxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PlVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlPC9hPjxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVW5iZWFy YWJsZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPlVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxl PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR03MB215599ADE9205B37647F7FFB8C1B0CY1PR03MB2155namp_-- From nobody Mon Aug 8 15:58: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 05C9C12B054 for ; Mon, 8 Aug 2016 15:58: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, FREEMAIL_FROM=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 (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 r8o1aReTB-u2 for ; Mon, 8 Aug 2016 15:58:29 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 7233612B012 for ; Mon, 8 Aug 2016 15:58:29 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id 52so211106795qtq.3 for ; Mon, 08 Aug 2016 15:58:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=vDJl7C43fY46SWbqUrnwD/Xpa3TUJbu9tQ4UejwBm9k=; b=s49IJArIwTg+6Qn9zE2WIug267+pSUVYX4RO/WKzAKUOoyOYs1dTpqWNA1wUb7h6au sTKrDyjfq9v3v1mzZ46ZNJAJmsFZ0dJEe53U+kxxEzuGLFMgPwg9i4lM1Km2fOMKVGps t50egu8/lU3fwehpip++D1xlNaJ02CmbSJL5pLVSwEfTK12UimOAotalTcj8QFnoEPZk XmirsJaBrnAk64dfNfZyn5FFyKtvk1ZKxnowp4Cy4JVLACVPZ4ajwlYlBlTOQuWYd/jx WN6HyFE1ffF4kNUN4nwystjmQiOdriaAwv9UJ6zfqri7+7LfD8CMEqA2/xPBqzyFQix4 9A/w== 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:content-transfer-encoding; bh=vDJl7C43fY46SWbqUrnwD/Xpa3TUJbu9tQ4UejwBm9k=; b=YA53YBkLyjMqy5TxSv9rbC6jrGB6DV9t/M0AtCwlpO8Lod3x3gQiDF80AWNlgV2Fr/ JaQmS8aNpw/cQPxqg35a/QLVTlnSo/WR/VivSUwIRLioCX+mA5CQkh/7hPnNo61qqlPB oVtn2mDedkmnPGiGkI310K3A0AgL/rWRfngyoS8+p/1Tdc6UVOcc6SiMsBKclUqy2LZF pn0mX5E748taLP/LxZaGwTLInXhXW8MHwrAinDebuSg+Y55du5f/BkJdaAhFbLL4WA/H evEF8YuW3L3QpqEEB+TUeWYFl9ad9qRH8JT4UY8MZyMca91ZNMWWZVUp05gBb+8127tm /OUw== X-Gm-Message-State: AEkoous0t3j2oZ9gQTJMmZBznQW9ky1TU6VQulEY79skSJeuafSPh9xL+9e3i7KFSKplueKo7fVBqubt1zDoYw== X-Received: by 10.200.57.34 with SMTP id s31mr29800718qtb.49.1470697108617; Mon, 08 Aug 2016 15:58:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Mon, 8 Aug 2016 15:58:28 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 9 Aug 2016 08:58:28 +1000 Message-ID: To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "unbearable@ietf.org" , Nick Harper Subject: Re: [Unbearable] Renegotiation info extension 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, 08 Aug 2016 22:58:31 -0000 On 9 August 2016 at 08:27, Andrei Popov wrote: > =C3=98 If the state of extended master secret changes, what should happe= n? > > EMS is required when TLS <=3D1.2 is used with TB, see TBPROTO section 8.5= , so > EMS state cannot change. Yes. Note that this is a requirement in the EMS RFC. You can't resume or renegotiate and then disable EMS. NSS at least has checks for that and I imagine other implementations will do as well. > If TB is negotiated as part of the renegotiation handshake, the client ne= eds > to send the TB message in the newly established TLS session, using the ne= w > EKM. I agree. New requests need to use the new EKM. There's a potential race here, so issue 64 might apply (https://github.com/TokenBinding/Internet-Drafts/issues/64). From nobody Mon Aug 8 16:03:27 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 A1E6712D0EC for ; Mon, 8 Aug 2016 16:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, 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 UuU3WGuwtixC for ; Mon, 8 Aug 2016 16:03:18 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 9905312D176 for ; Mon, 8 Aug 2016 16:03:17 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id 35so276835759uap.1 for ; Mon, 08 Aug 2016 16:03:17 -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=wLZfZOoyGlYBLGf2caE/Wri8OK0rIpcqpPy2+OTRTS0=; b=df+X15/Bjih8aWiLGbGNCnuntgP72yoWjq8Lzcn9QeODhC3x9s+REZX6EKQFjFiJIC rg7uRPp6wihlA3kxAJI2zsQqaJdSTPkNgvE6WJJeTIgjdUaq7RbKHzVRHSTfsZScKk5w hqhxo0XtFwqTL5ZeKlpoe8qoxwS1lCCErQZNF5T5Vx3e0IXGXVwudkNFZ++DmjAv/O8s lxMptY3oYJeU6Gw8auZQ+POttOwiekPdlujec6pNVFXh5cnND0tYX2p0Na5RlQSNna1g B0eGnuZboZSHN6s3aWusmhVq+56UCLSPO6wZPS75Z/KUvTvh6WQGDDNrYFKi7IAx+M0J lAZg== 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=wLZfZOoyGlYBLGf2caE/Wri8OK0rIpcqpPy2+OTRTS0=; b=QtBVejq7yDv4HrDAB7OfIsDaW+UG8GmoN7iTfiInjsmdxms+H3bstxt4ziJ0VZm5X9 VtZZExrgzgdI/OQgIjQFFa7N/ai9Hp1TQFzi+4i7092K4O3uvfF3ImRUNBoVK9/IDXpf jfAxMnDJq5YTSLiXbkFQhCfLLCSqkqIXIpHK3Tf9wK5lD0mNqb2lwS6LwHTLeM351FUz DE+qQUZGAxqb3zumi1eGVMjkKQylUgWHLGJ1ucjup+mRO8bZwtcE3JKmazz/wZlYeyRp JO/cNstpZoodi+8WyyyiXKUOialEUpT+3p2Xem9WysRHlW/k2n2zESWfrEBWVb9j6kxT n/yA== X-Gm-Message-State: AEkoouuAoScqMik5OtU0hwLSEJl+OVwA2vecnjjiD9ov0klw/vDoZymNkq60htIoh+v3TDJ8PcUErGErP/vRFDra X-Received: by 10.31.223.134 with SMTP id w128mr904166vkg.5.1470697394791; Mon, 08 Aug 2016 16:03:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.209 with HTTP; Mon, 8 Aug 2016 16:02:54 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Mon, 8 Aug 2016 16:02:54 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=94eb2c07cca8cd786a0539976b9c Archived-At: Cc: "unbearable@ietf.org" , Martin Thomson Subject: Re: [Unbearable] Renegotiation info extension 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, 08 Aug 2016 23:03:23 -0000 --94eb2c07cca8cd786a0539976b9c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 8, 2016 at 3:27 PM, Andrei Popov wrote: > > =C3=98 What's allowed to change in terms of Token Binding key params dur= ing a > renegotiation? > > The client uses the token_binding extension in each TLS handshake, so at > least in theory any TB parameters can change. > Why not require that TB parameters must be the same? This would simplify implementations insofar as the TB key would remain the same for the client. > > > =C3=98 Suppose a renegotiation happens between a client's http request a= nd > the server's response (as is I believe the case for IIS with http/1.1). T= he > client's request would contain a TokenBindingMessage with a signature ove= r > the original EKM, but when the server is sending the response the > connection now has a new EKM, so the server needs to remember the old EKM > to verify the signature. > > If TB is negotiated as part of the renegotiation handshake, the client > needs to send the TB message in the newly established TLS session, using > the new EKM. > I agree that the new EKM needs to be used; my concern is about implementation difficulty in getting this right. In this case, the client's request was sent before the renegotiation handshake, so it can only contain a signature of the old EKM. (The client didn't know renego was going to happen until after it sent the request.) The server's response is after the renegotiation handshake. Is the server going to try to use the old EKM or the new EKM when processing the client's request? Is the server going to process the request before or after requesting renego? If the server is processing the request after the renegotiation handshake occurs, is it going to remember the old EKM? This is a fairly straightforward example (client sends http request, server requests renego, client+server do renego handshake, server sends http response). If there are other interleavings, how do you propose a client and server synchronize the state of the TLS handshake with the application data that they're writing? > > > *From:* Nick Harper [mailto:nharper@google.com] > *Sent:* Monday, August 8, 2016 2:45 PM > > *To:* Andrei Popov > *Cc:* Martin Thomson ; unbearable@ietf.org > *Subject:* Re: [Unbearable] Renegotiation info extension > > > > If we want to support TB and renego, there are several things that need t= o > be considered and clarified in the spec: > > > > If the state of extended master secret changes, what should happen? (I > don't think this should be allowed) > > What's allowed to change in terms of Token Binding key params during a > renegotiation? I think that it must stay the same - if Token Binding is > negotiated, the same key param must be negotiated on both handshakes; > inversely if Token Binding is not negotiated in the first handshake, then > it must not be negotiated in the second. > > > > Even more details needs to go to what EKM value should be signed at any > given point. Renegotiation can technically interleave with application > data, so this seems quite ill-defined for what a TokenBindingMessage shou= ld > include for a signature if it is sent in application data in the middle o= f > a renegotiation. > > Suppose a renegotiation happens between a client's http request and the > server's response (as is I believe the case for IIS with http/1.1). The > client's request would contain a TokenBindingMessage with a signature ove= r > the original EKM, but when the server is sending the response the > connection now has a new EKM, so the server needs to remember the old EKM > to verify the signature. I imagine things get much more complicated with > http2. > > > > On Mon, Aug 8, 2016 at 2:24 PM, Andrei Popov > wrote: > > IE/IIS use renegotiation a lot, so Chrome=E2=80=99s approach would not wo= rk for > us, but Martin=E2=80=99s nuanced language does. > > > > *From:* Nick Harper [mailto:nharper@google.com] > *Sent:* Monday, August 8, 2016 2:20 PM > *To:* Andrei Popov > *Cc:* Martin Thomson ; unbearable@ietf.org > *Subject:* Re: [Unbearable] Renegotiation info extension > > > > Chrome's Token Binding implementation takes the approach of forbidding > renegotiation entirely. I would be in support of only allowing one of tok= en > binding or renegotiation on a connection, and then this consideration abo= ut > RI becomes a moot point. > > > > On Mon, Aug 8, 2016 at 12:46 PM, Andrei Popov > wrote: > > Yes, we can rephrase the security consideration in this more nuanced way. > > > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Martin > Thomson > Sent: Sunday, August 7, 2016 11:55 PM > To: unbearable@ietf.org > Subject: [Unbearable] Renegotiation info extension > > I know that this is probably old news, but there is an alternative to > using the renegotiation info extension. That is to forbid renegotiation > entirely. We're at the point now where lots of implementations do this a= nd > some of them are not including the RI extension at the same time. > > For TB, rather than requiring RI, can we instead prohibit the use of > renegotiation if RI is not negotiated? > > _______________________________________________ > 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 > > > > > --94eb2c07cca8cd786a0539976b9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 8, 2016 at 3:27 PM, Andrei Popov <Andrei.Popov@mi= crosoft.com> wrote:

=C3=98=C2=A0 What's allowed to change in terms of Token = Binding key params during a renegotiation?

The client uses the token_binding extension in each= TLS handshake, so at least in theory any TB parameters can change.<= /p>


Why not require that TB par= ameters must be the same? This would simplify implementations insofar as th= e TB key would remain the same for the client.=C2=A0

=

=C2=A0

=C3=98=C2=A0 Suppose a renegotiation happens between a clien= t's http request and the server's response (as is I believe the cas= e for IIS with http/1.1). The client's request would contain a TokenBin= dingMessage with a signature over the original EKM, but when the server is sending the response the connection now has a = new EKM, so the server needs to remember the old EKM to verify the signatur= e.

If TB is negotiated as part of the renegotiation ha= ndshake, the client needs to send the TB message in the newly established T= LS session, using the new EKM.


=
I agree that the new EKM needs to be used; my concern is about i= mplementation difficulty in getting this right. In this case, the client= 9;s request was sent before the renegotiation handshake, so it can only con= tain a signature of the old EKM. (The client didn't know renego was goi= ng to happen until after it sent the request.) The server's response is= after the renegotiation handshake. Is the server going to try to use the o= ld EKM or the new EKM when processing the client's request? Is the serv= er going to process the request before or after requesting renego? If the s= erver is processing the request after the renegotiation handshake occurs, i= s it going to remember the old EKM?

This is a fair= ly straightforward example (client sends http request, server requests rene= go, client+server do renego handshake, server sends http response). If ther= e are other interleavings, how do you propose a client and server synchroni= ze the state of the TLS handshake with the application data that they'r= e writing?

=C2=A0

From: Nick Harper [mailto:nharper@google.com]
Sent: Monday, August 8, 2016 2:45 PM


To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Martin Thomson <martin.thomson@gmail.com>; unbearable@ietf.org
Subject: Re: [Unbearable] Renegotiation info extension=

=C2=A0

If we want to support TB and renego, there are sever= al things that need to be considered and clarified in the spec:

=C2=A0

If the state of extended master secret changes, what= should happen? (I don't think this should be allowed)

What's allowed to change in terms of Token Bindi= ng key params during a renegotiation? I think that it must stay the same - = if Token Binding is negotiated, the same key param must be negotiated on bo= th handshakes; inversely if Token Binding is not negotiated in the first handshake, then it must not be negotiated i= n the second.

=C2=A0

Even more details needs to go to what EKM value shou= ld be signed at any given point. Renegotiation can technically interleave w= ith application data, so this seems quite ill-defined for what a TokenBindi= ngMessage should include for a signature if it is sent in application data in the middle of a renegotiation.=

Suppose a renegotiation happens between a client'= ;s http request and the server's response (as is I believe the case for= IIS with http/1.1). The client's request would contain a TokenBindingM= essage with a signature over the original EKM, but when the server is sending the response the connection now has a new E= KM, so the server needs to remember the old EKM to verify the signature. I = imagine things get much more complicated with http2.

=C2=A0

On Mon, Aug 8, 2016 at 2:24 PM, Andrei Popov <Andrei.Popov@m= icrosoft.com> wrote:

IE/IIS use renegotiation a lot, so Chrome=E2=80=99s= approach would not work for us, but Martin=E2=80=99s nuanced language does= .

=C2=A0

From: Nick Harper [mailto:nharper@google.com]
Sent: Monday, August 8, 2016 2:20 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Martin Thomson <martin.thomson@gmail.com>; unbearable@ietf.or= g
Subject: Re: [Unbearable] Renegotiation info extension=

=C2=A0

Chrome's Token Binding implementation takes the = approach of forbidding renegotiation entirely. I would be in support of onl= y allowing one of token binding or renegotiation on a connection, and then this consideration about RI becomes a moot point.<= /u>

=C2=A0

On Mon, Aug 8, 2016 at 12:46 PM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

Yes, we can rephrase the security consideration in t= his more nuanced way.


-----Original Message-----
From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Martin Th= omson
Sent: Sunday, August 7, 2016 11:55 PM
To: unbearable@iet= f.org
Subject: [Unbearable] Renegotiation info extension

I know that this is probably old news, but there is an alternative to using= the renegotiation info extension.=C2=A0 That is to forbid renegotiation en= tirely.=C2=A0 We're at the point now where lots of implementations do t= his and some of them are not including the RI extension at the same time.

For TB, rather than requiring RI, can we instead prohibit the use of renego= tiation if RI is not negotiated?

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

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

=C2=A0

=C2=A0


--94eb2c07cca8cd786a0539976b9c-- From nobody Mon Aug 8 16:10:06 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 3073112D0BB for ; Mon, 8 Aug 2016 16:10:05 -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, FREEMAIL_FROM=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 (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 KW9Zc3fBT5ML for ; Mon, 8 Aug 2016 16:10:04 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 DBF3912B074 for ; Mon, 8 Aug 2016 16:10:03 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id x25so211204408qtx.2 for ; Mon, 08 Aug 2016 16:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LPfL9fNhKZ9x7gKhb8YFM1LZSe0Iqs3Ks9RweZp8kWo=; b=Pu0A5jNCoC4/xHVtsDKLQ4z2B3FGBpNMUQ4q8nGVGzxXBpa8HBPW6A04OgNCtVb1tF YO/NdV1gvb4qHqzJNtlZn2H016IcW0x3j73ZBZRI5PhruD12fhS3DAR/ZRRotqkCFysN GP4Odp28xF0vwFIDzC6IfI9Eqa2/xnvqsgitpmTuyy40bEi2OcB2cgM7Q1Pv/KGgXi3U ahZOCZl0Cj6TIeRl7mGwAj8TRcBa0rtbU4IG2owP9Ci9TUcsXw8/I6rXrMVnHzOp3cuo OUIxsBg/DHMozMNS15u72q203ymSe1rtMjhm9c3+Sqqa2DMKdfVx/3En0tQz8qRZkJhd UT5g== 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=LPfL9fNhKZ9x7gKhb8YFM1LZSe0Iqs3Ks9RweZp8kWo=; b=R4w4E2qfzMbykDThqBgRgGAeBmpK5msks515s59pEls6EEg+ojXc00VC7NLVSM3Qpm XRCwiwJ76US4JZOm/IAJYinJmwai6PfbECAcxfkK9hTxyQWOEu5filbNCl8DLbfoMhCP qPyu+DN2W9g0YBOOgozXO5i0/raKs9stb/dHPDDhS7BMwqCDE/yA0DphD5fPGQcqlvuN t3ERbbY3PgBh4fj6rkrvv92tDgf7CEo7NnmDkbB8fobr6CCxVGHiOamj3iRomLPDmv6y 124fHNmwPD1TcMlv3QSzKxPMogKV1bK9msaLYBit6lE7sS0QVrD7f1vpRSoz1RdpmBqE 9gSQ== X-Gm-Message-State: AEkooutvFi2zEQKZSF0rqhbvz4/uqvlzCvsxB1cp12upQDJy3Q+zFkiLVFa0qB5Kdqr+CV25uRpPOrefIuZPjg== X-Received: by 10.200.50.199 with SMTP id a7mr31460677qtb.43.1470697803107; Mon, 08 Aug 2016 16:10:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Mon, 8 Aug 2016 16:10:02 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 9 Aug 2016 09:10:02 +1000 Message-ID: To: Brian Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Andrei Popov , IETF Tokbind WG Subject: Re: [Unbearable] referred token binding and unknown key_parameters 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, 08 Aug 2016 23:10:05 -0000 On 9 August 2016 at 02:09, Brian Campbell wrote: > Just a thought anyway. Don't know if that's better or worse or worth doing > for one byte. Note that I also opened #62, which suggests spending an extra byte. https://github.com/TokenBinding/Internet-Drafts/issues/62 From nobody Mon Aug 8 17:03: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 E236512D0BB for ; Mon, 8 Aug 2016 17:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 BdB6rLnUZuZV for ; Mon, 8 Aug 2016 17:03:53 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0091.outbound.protection.outlook.com [104.47.41.91]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1B4127735 for ; Mon, 8 Aug 2016 17:03:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9E9ADK0GzweuKsq/BdQnYog9t3OcFlZUV4ohvQVAXnA=; b=GAHfeq41cbq3AcVuR0gwDSQVyncmHJVwr1UGC1nBUi0yMgXIn4bxc0vWrzCSPxOUg+4ZnDjoB+cyhSH7bY6+2pmrznjNQAy17XfPj1FOvMzm7QRbnqmIS1MKvEmC3V1OM6U48f+/QbHFEZyY/kZS/dui7n5iEl8+jrjB+SaQvHU= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 9 Aug 2016 00:03:50 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0549.025; Tue, 9 Aug 2016 00:03:50 +0000 From: Andrei Popov To: Nick Harper Thread-Topic: [Unbearable] Renegotiation info extension Thread-Index: AQHR8UG+1juUPHgk7k6r83vWCBCSUaA/dqjAgAAcAoCAAABzoIAABpOAgAAHYiCAAA5nAIAAC8qA Date: Tue, 9 Aug 2016 00:03:50 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:d::1d2] x-ms-office365-filtering-correlation-id: 06518fcb-4632-447c-1f31-08d3bfe8a4af x-microsoft-exchange-diagnostics: 1; CY1PR03MB2155; 6:u/cEZcQRpVnEUxLgyifBcjhIbJ2ouyLzd+6UM1EbieWt3o6043pTyQ59bDC5zc3r/QzoZvef1s/Z3gZS5F9NBczGIlC+9P09e1xPcS87nXyjFYZt7LyZaxd/APb1wuIIbT9vvjQb0Db5VBmvSwVtEQd6+eMRQn544Y4AYl6ARF5ee4GbyUIdPCggNbLey/q5Q04znhNUUn8OOSzVjuuHyZTBVCVyUDTVCNRu4SpexetQj16XNWeT/c9OxGT4m66zyHQps9iye9lYwICm4AyYrrK045zE4g40/KMJvxExaN64FGjHjYSrX77HMT8ZYXx0XOlIpBq4ixlxq4lBNj6PYw==; 5:gbSpa/+HMt4czoxVMPElSFA9pFmINbzijk9lu1cVBBxBzW93lP+qjRetFx4nQhA6M76l2ZySC5d+oiFHFLtbFhlQguCBZg7VsoeZH+kgRtDtqCpK6XRE4n/SzXKQCkQ5/ml3cwvkoxBqBlHSjPdQYA==; 24:IEnog7Z0WQPRnImxMcReGEzp+PX5x7TaqMk6CFKez9uQw54omk+MnSwBqv+X6eghkAgi6ftH6p7kwusLByb1nmfrJw5Xv2q+6PSEAvSuvZ4=; 7:Z5zhjUGNCxU51UQS/NXD6dlSas0wdlNy2Ms+DiBef+sToD0txXyxtZtfKFXxsAhZYDfD2v/lS5yBydOVG/2cDEicGNxe32C88bhKQwyKW0drKBTNmXgIM0g6eYjeWC+GT4dmt+aF39oXmiUMUfCj2OV85NpguPBOJgJh2LkM9r+rNa8eW7dIYMr8/vUYR7ckS7jbIg3cQnacWouLXAe5QG8riFSeWmGF9kTR7i+OximoWn/FeVE/kXhx2TdkYttI x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2155; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2155; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2155; x-forefront-prvs: 0029F17A3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(51444003)(377454003)(199003)(189002)(13464003)(101416001)(5005710100001)(33656002)(10290500002)(106116001)(106356001)(10400500002)(81156014)(105586002)(74316002)(8676002)(8990500004)(7846002)(76176999)(5002640100001)(8936002)(10090500001)(110136002)(11100500001)(97736004)(19617315012)(7906003)(7736002)(7696003)(122556002)(81166006)(76576001)(93886004)(4326007)(54356999)(19625215002)(50986999)(86362001)(9686002)(189998001)(3660700001)(68736007)(790700001)(16236675004)(2906002)(102836003)(6116002)(19300405004)(87936001)(99286002)(86612001)(586003)(3280700002)(77096005)(2950100001)(15975445007)(2900100001)(19580405001)(19580395003)(92566002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2155; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB2155ECB11A6D643617C70C4F8C1C0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2016 00:03:50.4278 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2155 Archived-At: Cc: "unbearable@ietf.org" , Martin Thomson Subject: Re: [Unbearable] Renegotiation info extension 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, 09 Aug 2016 00:03:56 -0000 --_000_CY1PR03MB2155ECB11A6D643617C70C4F8C1C0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIFdoeSBub3QgcmVxdWlyZSB0aGF0IFRCIHBhcmFtZXRlcnMgbXVzdCBiZSB0aGUgc2FtZT8g VGhpcyB3b3VsZCBzaW1wbGlmeSBpbXBsZW1lbnRhdGlvbnMgaW5zb2ZhciBhcyB0aGUgVEIga2V5 IHdvdWxkIHJlbWFpbiB0aGUgc2FtZSBmb3IgdGhlIGNsaWVudC4NCk9uY2UgdGhlIFRMUyBoYW5k c2hha2UgaXMgY29tcGxldGUsIGEgY2xpZW50IHJlY2VpdmVzIHRoZSBuZWdvdGlhdGVkIFRCIHBh cmFtZXRlcnMsIHJldHJpZXZlcyB0aGUgYXBwcm9wcmlhdGUgVEIga2V5LCBhbmQgZ2VuZXJhdGVz IHRoZSBUQiBtZXNzYWdlLiBBZGRpbmcgYSB2ZXJpZmljYXRpb24gc3RlcCB0aGF0IHJlcXVpcmVz IHRoZSBjbGllbnQgdG8gZGlzdGluZ3Vpc2ggcmVuZWdvdGlhdGlvbnMgYW5kIHJlbWVtYmVyIHBy ZXZpb3VzIFRCIHNldHRpbmdzIGRvZXMgbm90IGxvb2sgbGlrZSBhIHNpbXBsaWZpY2F0aW9uIHRv IG1lLg0KDQoNCsOYICBJbiB0aGlzIGNhc2UsIHRoZSBjbGllbnQncyByZXF1ZXN0IHdhcyBzZW50 IGJlZm9yZSB0aGUgcmVuZWdvdGlhdGlvbiBoYW5kc2hha2UsIHNvIGl0IGNhbiBvbmx5IGNvbnRh aW4gYSBzaWduYXR1cmUgb2YgdGhlIG9sZCBFS00uDQpUcnVlLCBidXQgaXQgZG9lcyBub3QgbWF0 dGVyIGJlY2F1c2UgdGhlIGNsaWVudCBpcyB1bmF1dGhlbnRpY2F0ZWQgaW4gdGhpcyBUTFMgc2Vz c2lvbiwgc28gdGhlIHNlcnZlciBpbml0aWF0ZXMgcmVuZWdvdGlhdGlvbi4NCg0KDQrDmCAgVGhl IHNlcnZlcidzIHJlc3BvbnNlIGlzIGFmdGVyIHRoZSByZW5lZ290aWF0aW9uIGhhbmRzaGFrZS4g SXMgdGhlIHNlcnZlciBnb2luZyB0byB0cnkgdG8gdXNlIHRoZSBvbGQgRUtNIG9yIHRoZSBuZXcg RUtNIHdoZW4gcHJvY2Vzc2luZyB0aGUgY2xpZW50J3MgcmVxdWVzdD8NClRCIGlzIG5vdCBlc3Rh Ymxpc2hlZCB1bnRpbCB0aGUgY2xpZW50IHNlbmRzIHRoZSBUQiBtZXNzYWdlIGluIHRoZSBuZXcg VExTIHNlc3Npb24gYW5kIHRoZSBzZXJ2ZXIgdmFsaWRhdGVzIGl0LiBTbyB0aGUgc2VydmVyIHdp bGwgdXNlIHRoZSBjdXJyZW50IEVLTSBhdCB0aGUgdGltZSBvZiBUQiBtZXNzYWdlIHZhbGlkYXRp b24sIGkuZS4gdGhlIG5ldyBvbmUuDQoNCkZyb206IE5pY2sgSGFycGVyIFttYWlsdG86bmhhcnBl ckBnb29nbGUuY29tXQ0KU2VudDogTW9uZGF5LCBBdWd1c3QgOCwgMjAxNiA0OjAzIFBNDQpUbzog QW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4NCkNjOiBNYXJ0aW4gVGhv bXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPjsgdW5iZWFyYWJsZUBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtVbmJlYXJhYmxlXSBSZW5lZ290aWF0aW9uIGluZm8gZXh0ZW5zaW9uDQoNCg0K DQpPbiBNb24sIEF1ZyA4LCAyMDE2IGF0IDM6MjcgUE0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBv cG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3Jv dGU6DQoNCj4gIFdoYXQncyBhbGxvd2VkIHRvIGNoYW5nZSBpbiB0ZXJtcyBvZiBUb2tlbiBCaW5k aW5nIGtleSBwYXJhbXMgZHVyaW5nIGEgcmVuZWdvdGlhdGlvbj8NClRoZSBjbGllbnQgdXNlcyB0 aGUgdG9rZW5fYmluZGluZyBleHRlbnNpb24gaW4gZWFjaCBUTFMgaGFuZHNoYWtlLCBzbyBhdCBs ZWFzdCBpbiB0aGVvcnkgYW55IFRCIHBhcmFtZXRlcnMgY2FuIGNoYW5nZS4NCg0KV2h5IG5vdCBy ZXF1aXJlIHRoYXQgVEIgcGFyYW1ldGVycyBtdXN0IGJlIHRoZSBzYW1lPyBUaGlzIHdvdWxkIHNp bXBsaWZ5IGltcGxlbWVudGF0aW9ucyBpbnNvZmFyIGFzIHRoZSBUQiBrZXkgd291bGQgcmVtYWlu IHRoZSBzYW1lIGZvciB0aGUgY2xpZW50Lg0KDQoNCj4gIFN1cHBvc2UgYSByZW5lZ290aWF0aW9u IGhhcHBlbnMgYmV0d2VlbiBhIGNsaWVudCdzIGh0dHAgcmVxdWVzdCBhbmQgdGhlIHNlcnZlcidz IHJlc3BvbnNlIChhcyBpcyBJIGJlbGlldmUgdGhlIGNhc2UgZm9yIElJUyB3aXRoIGh0dHAvMS4x KS4gVGhlIGNsaWVudCdzIHJlcXVlc3Qgd291bGQgY29udGFpbiBhIFRva2VuQmluZGluZ01lc3Nh Z2Ugd2l0aCBhIHNpZ25hdHVyZSBvdmVyIHRoZSBvcmlnaW5hbCBFS00sIGJ1dCB3aGVuIHRoZSBz ZXJ2ZXIgaXMgc2VuZGluZyB0aGUgcmVzcG9uc2UgdGhlIGNvbm5lY3Rpb24gbm93IGhhcyBhIG5l dyBFS00sIHNvIHRoZSBzZXJ2ZXIgbmVlZHMgdG8gcmVtZW1iZXIgdGhlIG9sZCBFS00gdG8gdmVy aWZ5IHRoZSBzaWduYXR1cmUuDQpJZiBUQiBpcyBuZWdvdGlhdGVkIGFzIHBhcnQgb2YgdGhlIHJl bmVnb3RpYXRpb24gaGFuZHNoYWtlLCB0aGUgY2xpZW50IG5lZWRzIHRvIHNlbmQgdGhlIFRCIG1l c3NhZ2UgaW4gdGhlIG5ld2x5IGVzdGFibGlzaGVkIFRMUyBzZXNzaW9uLCB1c2luZyB0aGUgbmV3 IEVLTS4NCg0KSSBhZ3JlZSB0aGF0IHRoZSBuZXcgRUtNIG5lZWRzIHRvIGJlIHVzZWQ7IG15IGNv bmNlcm4gaXMgYWJvdXQgaW1wbGVtZW50YXRpb24gZGlmZmljdWx0eSBpbiBnZXR0aW5nIHRoaXMg cmlnaHQuIEluIHRoaXMgY2FzZSwgdGhlIGNsaWVudCdzIHJlcXVlc3Qgd2FzIHNlbnQgYmVmb3Jl IHRoZSByZW5lZ290aWF0aW9uIGhhbmRzaGFrZSwgc28gaXQgY2FuIG9ubHkgY29udGFpbiBhIHNp Z25hdHVyZSBvZiB0aGUgb2xkIEVLTS4gKFRoZSBjbGllbnQgZGlkbid0IGtub3cgcmVuZWdvIHdh cyBnb2luZyB0byBoYXBwZW4gdW50aWwgYWZ0ZXIgaXQgc2VudCB0aGUgcmVxdWVzdC4pIFRoZSBz ZXJ2ZXIncyByZXNwb25zZSBpcyBhZnRlciB0aGUgcmVuZWdvdGlhdGlvbiBoYW5kc2hha2UuIElz IHRoZSBzZXJ2ZXIgZ29pbmcgdG8gdHJ5IHRvIHVzZSB0aGUgb2xkIEVLTSBvciB0aGUgbmV3IEVL TSB3aGVuIHByb2Nlc3NpbmcgdGhlIGNsaWVudCdzIHJlcXVlc3Q/IElzIHRoZSBzZXJ2ZXIgZ29p bmcgdG8gcHJvY2VzcyB0aGUgcmVxdWVzdCBiZWZvcmUgb3IgYWZ0ZXIgcmVxdWVzdGluZyByZW5l Z28/IElmIHRoZSBzZXJ2ZXIgaXMgcHJvY2Vzc2luZyB0aGUgcmVxdWVzdCBhZnRlciB0aGUgcmVu ZWdvdGlhdGlvbiBoYW5kc2hha2Ugb2NjdXJzLCBpcyBpdCBnb2luZyB0byByZW1lbWJlciB0aGUg b2xkIEVLTT8NCg0KVGhpcyBpcyBhIGZhaXJseSBzdHJhaWdodGZvcndhcmQgZXhhbXBsZSAoY2xp ZW50IHNlbmRzIGh0dHAgcmVxdWVzdCwgc2VydmVyIHJlcXVlc3RzIHJlbmVnbywgY2xpZW50K3Nl cnZlciBkbyByZW5lZ28gaGFuZHNoYWtlLCBzZXJ2ZXIgc2VuZHMgaHR0cCByZXNwb25zZSkuIElm IHRoZXJlIGFyZSBvdGhlciBpbnRlcmxlYXZpbmdzLCBob3cgZG8geW91IHByb3Bvc2UgYSBjbGll bnQgYW5kIHNlcnZlciBzeW5jaHJvbml6ZSB0aGUgc3RhdGUgb2YgdGhlIFRMUyBoYW5kc2hha2Ug d2l0aCB0aGUgYXBwbGljYXRpb24gZGF0YSB0aGF0IHRoZXkncmUgd3JpdGluZz8NCg0KRnJvbTog TmljayBIYXJwZXIgW21haWx0bzpuaGFycGVyQGdvb2dsZS5jb208bWFpbHRvOm5oYXJwZXJAZ29v Z2xlLmNvbT5dDQpTZW50OiBNb25kYXksIEF1Z3VzdCA4LCAyMDE2IDI6NDUgUE0NCg0KVG86IEFu ZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3Bv dkBtaWNyb3NvZnQuY29tPj4NCkNjOiBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21h aWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+PjsgdW5iZWFyYWJsZUBpZXRm Lm9yZzxtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJs ZV0gUmVuZWdvdGlhdGlvbiBpbmZvIGV4dGVuc2lvbg0KDQpJZiB3ZSB3YW50IHRvIHN1cHBvcnQg VEIgYW5kIHJlbmVnbywgdGhlcmUgYXJlIHNldmVyYWwgdGhpbmdzIHRoYXQgbmVlZCB0byBiZSBj b25zaWRlcmVkIGFuZCBjbGFyaWZpZWQgaW4gdGhlIHNwZWM6DQoNCklmIHRoZSBzdGF0ZSBvZiBl eHRlbmRlZCBtYXN0ZXIgc2VjcmV0IGNoYW5nZXMsIHdoYXQgc2hvdWxkIGhhcHBlbj8gKEkgZG9u J3QgdGhpbmsgdGhpcyBzaG91bGQgYmUgYWxsb3dlZCkNCldoYXQncyBhbGxvd2VkIHRvIGNoYW5n ZSBpbiB0ZXJtcyBvZiBUb2tlbiBCaW5kaW5nIGtleSBwYXJhbXMgZHVyaW5nIGEgcmVuZWdvdGlh dGlvbj8gSSB0aGluayB0aGF0IGl0IG11c3Qgc3RheSB0aGUgc2FtZSAtIGlmIFRva2VuIEJpbmRp bmcgaXMgbmVnb3RpYXRlZCwgdGhlIHNhbWUga2V5IHBhcmFtIG11c3QgYmUgbmVnb3RpYXRlZCBv biBib3RoIGhhbmRzaGFrZXM7IGludmVyc2VseSBpZiBUb2tlbiBCaW5kaW5nIGlzIG5vdCBuZWdv dGlhdGVkIGluIHRoZSBmaXJzdCBoYW5kc2hha2UsIHRoZW4gaXQgbXVzdCBub3QgYmUgbmVnb3Rp YXRlZCBpbiB0aGUgc2Vjb25kLg0KDQpFdmVuIG1vcmUgZGV0YWlscyBuZWVkcyB0byBnbyB0byB3 aGF0IEVLTSB2YWx1ZSBzaG91bGQgYmUgc2lnbmVkIGF0IGFueSBnaXZlbiBwb2ludC4gUmVuZWdv dGlhdGlvbiBjYW4gdGVjaG5pY2FsbHkgaW50ZXJsZWF2ZSB3aXRoIGFwcGxpY2F0aW9uIGRhdGEs IHNvIHRoaXMgc2VlbXMgcXVpdGUgaWxsLWRlZmluZWQgZm9yIHdoYXQgYSBUb2tlbkJpbmRpbmdN ZXNzYWdlIHNob3VsZCBpbmNsdWRlIGZvciBhIHNpZ25hdHVyZSBpZiBpdCBpcyBzZW50IGluIGFw cGxpY2F0aW9uIGRhdGEgaW4gdGhlIG1pZGRsZSBvZiBhIHJlbmVnb3RpYXRpb24uDQpTdXBwb3Nl IGEgcmVuZWdvdGlhdGlvbiBoYXBwZW5zIGJldHdlZW4gYSBjbGllbnQncyBodHRwIHJlcXVlc3Qg YW5kIHRoZSBzZXJ2ZXIncyByZXNwb25zZSAoYXMgaXMgSSBiZWxpZXZlIHRoZSBjYXNlIGZvciBJ SVMgd2l0aCBodHRwLzEuMSkuIFRoZSBjbGllbnQncyByZXF1ZXN0IHdvdWxkIGNvbnRhaW4gYSBU b2tlbkJpbmRpbmdNZXNzYWdlIHdpdGggYSBzaWduYXR1cmUgb3ZlciB0aGUgb3JpZ2luYWwgRUtN LCBidXQgd2hlbiB0aGUgc2VydmVyIGlzIHNlbmRpbmcgdGhlIHJlc3BvbnNlIHRoZSBjb25uZWN0 aW9uIG5vdyBoYXMgYSBuZXcgRUtNLCBzbyB0aGUgc2VydmVyIG5lZWRzIHRvIHJlbWVtYmVyIHRo ZSBvbGQgRUtNIHRvIHZlcmlmeSB0aGUgc2lnbmF0dXJlLiBJIGltYWdpbmUgdGhpbmdzIGdldCBt dWNoIG1vcmUgY29tcGxpY2F0ZWQgd2l0aCBodHRwMi4NCg0KT24gTW9uLCBBdWcgOCwgMjAxNiBh dCAyOjI0IFBNLCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPG1haWx0 bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSUUvSUlTIHVzZSByZW5lZ290 aWF0aW9uIGEgbG90LCBzbyBDaHJvbWXigJlzIGFwcHJvYWNoIHdvdWxkIG5vdCB3b3JrIGZvciB1 cywgYnV0IE1hcnRpbuKAmXMgbnVhbmNlZCBsYW5ndWFnZSBkb2VzLg0KDQpGcm9tOiBOaWNrIEhh cnBlciBbbWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbTxtYWlsdG86bmhhcnBlckBnb29nbGUuY29t Pl0NClNlbnQ6IE1vbmRheSwgQXVndXN0IDgsIDIwMTYgMjoyMCBQTQ0KVG86IEFuZHJlaSBQb3Bv diA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3Nv ZnQuY29tPj4NCkNjOiBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1h aWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+PjsgdW5iZWFyYWJsZUBpZXRmLm9yZzxtYWls dG86dW5iZWFyYWJsZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gUmVuZWdv dGlhdGlvbiBpbmZvIGV4dGVuc2lvbg0KDQpDaHJvbWUncyBUb2tlbiBCaW5kaW5nIGltcGxlbWVu dGF0aW9uIHRha2VzIHRoZSBhcHByb2FjaCBvZiBmb3JiaWRkaW5nIHJlbmVnb3RpYXRpb24gZW50 aXJlbHkuIEkgd291bGQgYmUgaW4gc3VwcG9ydCBvZiBvbmx5IGFsbG93aW5nIG9uZSBvZiB0b2tl biBiaW5kaW5nIG9yIHJlbmVnb3RpYXRpb24gb24gYSBjb25uZWN0aW9uLCBhbmQgdGhlbiB0aGlz IGNvbnNpZGVyYXRpb24gYWJvdXQgUkkgYmVjb21lcyBhIG1vb3QgcG9pbnQuDQoNCk9uIE1vbiwg QXVnIDgsIDIwMTYgYXQgMTI6NDYgUE0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jv c29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpZZXMs IHdlIGNhbiByZXBocmFzZSB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBpbiB0aGlzIG1vcmUg bnVhbmNlZCB3YXkuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBVbmJlYXJh YmxlIFttYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzp1bmJlYXJhYmxl LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb24NClNlbnQ6IFN1 bmRheSwgQXVndXN0IDcsIDIwMTYgMTE6NTUgUE0NClRvOiB1bmJlYXJhYmxlQGlldGYub3JnPG1h aWx0bzp1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogW1VuYmVhcmFibGVdIFJlbmVnb3Rp YXRpb24gaW5mbyBleHRlbnNpb24NCg0KSSBrbm93IHRoYXQgdGhpcyBpcyBwcm9iYWJseSBvbGQg bmV3cywgYnV0IHRoZXJlIGlzIGFuIGFsdGVybmF0aXZlIHRvIHVzaW5nIHRoZSByZW5lZ290aWF0 aW9uIGluZm8gZXh0ZW5zaW9uLiAgVGhhdCBpcyB0byBmb3JiaWQgcmVuZWdvdGlhdGlvbiBlbnRp cmVseS4gIFdlJ3JlIGF0IHRoZSBwb2ludCBub3cgd2hlcmUgbG90cyBvZiBpbXBsZW1lbnRhdGlv bnMgZG8gdGhpcyBhbmQgc29tZSBvZiB0aGVtIGFyZSBub3QgaW5jbHVkaW5nIHRoZSBSSSBleHRl bnNpb24gYXQgdGhlIHNhbWUgdGltZS4NCg0KRm9yIFRCLCByYXRoZXIgdGhhbiByZXF1aXJpbmcg UkksIGNhbiB3ZSBpbnN0ZWFkIHByb2hpYml0IHRoZSB1c2Ugb2YgcmVuZWdvdGlhdGlvbiBpZiBS SSBpcyBub3QgbmVnb3RpYXRlZD8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0DQpVbmJlYXJhYmxlQGlldGYu b3JnPG1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KVW5iZWFyYWJsZUBp ZXRmLm9yZzxtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZQ0KDQoNCg0K --_000_CY1PR03MB2155ECB11A6D643617C70C4F8C1C0CY1PR03MB2155namp_ 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 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9y bWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tLTg4OTA1MDcxMTMzMzI5NDU3 NjBtc29saXN0cGFyYWdyYXBoLCBsaS5tLTg4OTA1MDcxMTMzMzI5NDU3NjBtc29saXN0cGFyYWdy YXBoLCBkaXYubS04ODkwNTA3MTEzMzMyOTQ1NzYwbXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5 bGUtbmFtZTptXy04ODkwNTA3MTEzMzMyOTQ1NzYwbXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE2ODM4 MjQ4MTk7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi01 MDU4ODc3NiAxNzQ3MjI3ODAwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXtt c28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJp ZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2lu LWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+V2h5IG5vdCByZXF1aXJlIHRoYXQgVEIgcGFyYW1ldGVycyBt dXN0IGJlIHRoZSBzYW1lPyBUaGlzIHdvdWxkIHNpbXBsaWZ5IGltcGxlbWVudGF0aW9ucyBpbnNv ZmFyIGFzIHRoZSBUQiBrZXkgd291bGQgcmVtYWluIHRoZSBzYW1lIGZvciB0aGUgY2xpZW50LiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5PbmNlIHRoZSBUTFMgaGFuZHNoYWtlIGlzIGNvbXBsZXRlLCBhIGNsaWVudCByZWNlaXZlcyB0 aGUgbmVnb3RpYXRlZCBUQiBwYXJhbWV0ZXJzLCByZXRyaWV2ZXMgdGhlIGFwcHJvcHJpYXRlIFRC IGtleSwgYW5kIGdlbmVyYXRlcyB0aGUgVEIgbWVzc2FnZS4gQWRkaW5nIGEgdmVyaWZpY2F0aW9u IHN0ZXANCiB0aGF0IHJlcXVpcmVzIHRoZSBjbGllbnQgdG8gZGlzdGluZ3Vpc2ggcmVuZWdvdGlh dGlvbnMgYW5kIHJlbWVtYmVyIHByZXZpb3VzIFRCIHNldHRpbmdzIGRvZXMgbm90IGxvb2sgbGlr ZSBhIHNpbXBsaWZpY2F0aW9uIHRvIG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkluIHRo aXMgY2FzZSwgdGhlIGNsaWVudCdzIHJlcXVlc3Qgd2FzIHNlbnQgYmVmb3JlIHRoZSByZW5lZ290 aWF0aW9uIGhhbmRzaGFrZSwgc28gaXQgY2FuIG9ubHkgY29udGFpbiBhIHNpZ25hdHVyZSBvZiB0 aGUgb2xkIEVLTS48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VHJ1ZSwgYnV0IGl0IGRvZXMgbm90IG1h dHRlciBiZWNhdXNlIHRoZSBjbGllbnQgaXMgdW5hdXRoZW50aWNhdGVkIGluIHRoaXMgVExTIHNl c3Npb24sIHNvIHRoZSBzZXJ2ZXIgaW5pdGlhdGVzIHJlbmVnb3RpYXRpb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2Rp bmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+VGhlIHNlcnZlcidzIHJlc3BvbnNlIGlzIGFmdGVyIHRoZSByZW5lZ290 aWF0aW9uIGhhbmRzaGFrZS4gSXMgdGhlIHNlcnZlciBnb2luZyB0byB0cnkgdG8gdXNlIHRoZSBv bGQgRUtNIG9yIHRoZSBuZXcgRUtNIHdoZW4gcHJvY2Vzc2luZyB0aGUgY2xpZW50J3MgcmVxdWVz dD88c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VEIgaXMgbm90IGVzdGFibGlzaGVkIHVudGlsIHRoZSBj bGllbnQgc2VuZHMgdGhlIFRCIG1lc3NhZ2UgaW4gdGhlIG5ldyBUTFMgc2Vzc2lvbiBhbmQgdGhl IHNlcnZlciB2YWxpZGF0ZXMgaXQuIFNvIHRoZSBzZXJ2ZXIgd2lsbCB1c2UgdGhlIGN1cnJlbnQg RUtNIGF0IHRoZSB0aW1lIG9mIFRCIG1lc3NhZ2UNCiB2YWxpZGF0aW9uLCBpLmUuIHRoZSBuZXcg b25lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g TmljayBIYXJwZXIgW21haWx0bzpuaGFycGVyQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gTW9uZGF5LCBBdWd1c3QgOCwgMjAxNiA0OjAzIFBNPGJyPg0KPGI+VG86PC9iPiBBbmRyZWkg UG9wb3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4g TWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs7IHVuYmVhcmFi bGVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBSZW5lZ290 aWF0aW9uIGluZm8gZXh0ZW5zaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBB dWcgOCwgMjAxNiBhdCAzOjI3IFBNLCBBbmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9Im1haWx0bzpB bmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJlaS5Qb3BvdkBt aWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibS04ODkwNTA3MTEzMzMyOTQ1NzYwbXNvbGlzdHBhcmFn cmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2Rpbmdz Ij7DmDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsNCjwvc3Bhbj5X aGF0J3MgYWxsb3dlZCB0byBjaGFuZ2UgaW4gdGVybXMgb2YgVG9rZW4gQmluZGluZyBrZXkgcGFy YW1zIGR1cmluZyBhIHJlbmVnb3RpYXRpb24/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGNsaWVudCB1c2VzIHRoZSB0b2tlbl9iaW5k aW5nIGV4dGVuc2lvbiBpbiBlYWNoIFRMUyBoYW5kc2hha2UsIHNvIGF0IGxlYXN0IGluIHRoZW9y eSBhbnkgVEIgcGFyYW1ldGVycyBjYW4gY2hhbmdlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5XaHkgbm90IHJlcXVpcmUgdGhhdCBUQiBwYXJhbWV0ZXJzIG11c3QgYmUgdGhlIHNhbWU/IFRo aXMgd291bGQgc2ltcGxpZnkgaW1wbGVtZW50YXRpb25zIGluc29mYXIgYXMgdGhlIFRCIGtleSB3 b3VsZCByZW1haW4gdGhlIHNhbWUgZm9yIHRoZSBjbGllbnQuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44 cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0ibS04ODkwNTA3MTEzMzMyOTQ1NzYwbXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj7DmDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsNCjwvc3Bhbj5TdXBwb3NlIGEgcmVuZWdvdGlhdGlv biBoYXBwZW5zIGJldHdlZW4gYSBjbGllbnQncyBodHRwIHJlcXVlc3QgYW5kIHRoZSBzZXJ2ZXIn cyByZXNwb25zZSAoYXMgaXMgSSBiZWxpZXZlIHRoZSBjYXNlIGZvciBJSVMgd2l0aCBodHRwLzEu MSkuIFRoZSBjbGllbnQncyByZXF1ZXN0IHdvdWxkIGNvbnRhaW4gYSBUb2tlbkJpbmRpbmdNZXNz YWdlIHdpdGggYSBzaWduYXR1cmUgb3ZlciB0aGUgb3JpZ2luYWwgRUtNLCBidXQgd2hlbiB0aGUN CiBzZXJ2ZXIgaXMgc2VuZGluZyB0aGUgcmVzcG9uc2UgdGhlIGNvbm5lY3Rpb24gbm93IGhhcyBh IG5ldyBFS00sIHNvIHRoZSBzZXJ2ZXIgbmVlZHMgdG8gcmVtZW1iZXIgdGhlIG9sZCBFS00gdG8g dmVyaWZ5IHRoZSBzaWduYXR1cmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+SWYgVEIgaXMgbmVnb3RpYXRlZCBhcyBwYXJ0IG9mIHRoZSBy ZW5lZ290aWF0aW9uIGhhbmRzaGFrZSwgdGhlIGNsaWVudCBuZWVkcyB0byBzZW5kIHRoZSBUQiBt ZXNzYWdlIGluIHRoZSBuZXdseQ0KIGVzdGFibGlzaGVkIFRMUyBzZXNzaW9uLCB1c2luZyB0aGUg bmV3IEVLTS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB0aGF0IHRoZSBuZXcg RUtNIG5lZWRzIHRvIGJlIHVzZWQ7IG15IGNvbmNlcm4gaXMgYWJvdXQgaW1wbGVtZW50YXRpb24g ZGlmZmljdWx0eSBpbiBnZXR0aW5nIHRoaXMgcmlnaHQuIEluIHRoaXMgY2FzZSwgdGhlIGNsaWVu dCdzIHJlcXVlc3Qgd2FzIHNlbnQgYmVmb3JlIHRoZSByZW5lZ290aWF0aW9uIGhhbmRzaGFrZSwg c28gaXQgY2FuIG9ubHkgY29udGFpbiBhIHNpZ25hdHVyZSBvZiB0aGUgb2xkDQogRUtNLiAoVGhl IGNsaWVudCBkaWRuJ3Qga25vdyByZW5lZ28gd2FzIGdvaW5nIHRvIGhhcHBlbiB1bnRpbCBhZnRl ciBpdCBzZW50IHRoZSByZXF1ZXN0LikgVGhlIHNlcnZlcidzIHJlc3BvbnNlIGlzIGFmdGVyIHRo ZSByZW5lZ290aWF0aW9uIGhhbmRzaGFrZS4gSXMgdGhlIHNlcnZlciBnb2luZyB0byB0cnkgdG8g dXNlIHRoZSBvbGQgRUtNIG9yIHRoZSBuZXcgRUtNIHdoZW4gcHJvY2Vzc2luZyB0aGUgY2xpZW50 J3MgcmVxdWVzdD8gSXMgdGhlDQogc2VydmVyIGdvaW5nIHRvIHByb2Nlc3MgdGhlIHJlcXVlc3Qg YmVmb3JlIG9yIGFmdGVyIHJlcXVlc3RpbmcgcmVuZWdvPyBJZiB0aGUgc2VydmVyIGlzIHByb2Nl c3NpbmcgdGhlIHJlcXVlc3QgYWZ0ZXIgdGhlIHJlbmVnb3RpYXRpb24gaGFuZHNoYWtlIG9jY3Vy cywgaXMgaXQgZ29pbmcgdG8gcmVtZW1iZXIgdGhlIG9sZCBFS00/PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgYSBmYWlybHkgc3Ry YWlnaHRmb3J3YXJkIGV4YW1wbGUgKGNsaWVudCBzZW5kcyBodHRwIHJlcXVlc3QsIHNlcnZlciBy ZXF1ZXN0cyByZW5lZ28sIGNsaWVudCYjNDM7c2VydmVyIGRvIHJlbmVnbyBoYW5kc2hha2UsIHNl cnZlciBzZW5kcyBodHRwIHJlc3BvbnNlKS4gSWYgdGhlcmUgYXJlIG90aGVyIGludGVybGVhdmlu Z3MsIGhvdyBkbyB5b3UgcHJvcG9zZSBhIGNsaWVudCBhbmQgc2VydmVyIHN5bmNocm9uaXplDQog dGhlIHN0YXRlIG9mIHRoZSBUTFMgaGFuZHNoYWtlIHdpdGggdGhlIGFwcGxpY2F0aW9uIGRhdGEg dGhhdCB0aGV5J3JlIHdyaXRpbmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE5pY2sgSGFy cGVyIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPm5oYXJwZXJAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBBdWd1c3QgOCwgMjAxNiAyOjQ1IFBNPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5Ubzo8L2I+IEFuZHJlaSBQb3BvdiAm bHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9i bGFuayI+QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4g TWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OzsNCjxh IGhyZWY9Im1haWx0bzp1bmJlYXJhYmxlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dW5iZWFy YWJsZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBS ZW5lZ290aWF0aW9uIGluZm8gZXh0ZW5zaW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgd2Ugd2FudCB0byBzdXBwb3J0 IFRCIGFuZCByZW5lZ28sIHRoZXJlIGFyZSBzZXZlcmFsIHRoaW5ncyB0aGF0IG5lZWQgdG8gYmUg Y29uc2lkZXJlZCBhbmQgY2xhcmlmaWVkIGluIHRoZSBzcGVjOjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5JZiB0aGUgc3RhdGUgb2YgZXh0ZW5kZWQgbWFzdGVyIHNl Y3JldCBjaGFuZ2VzLCB3aGF0IHNob3VsZCBoYXBwZW4/IChJIGRvbid0IHRoaW5rIHRoaXMgc2hv dWxkIGJlIGFsbG93ZWQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPldoYXQncyBhbGxvd2VkIHRvIGNoYW5nZSBpbiB0ZXJtcyBvZiBUb2tlbiBC aW5kaW5nIGtleSBwYXJhbXMgZHVyaW5nIGEgcmVuZWdvdGlhdGlvbj8gSSB0aGluayB0aGF0IGl0 IG11c3Qgc3RheSB0aGUgc2FtZSAtIGlmIFRva2VuIEJpbmRpbmcgaXMgbmVnb3RpYXRlZCwgdGhl IHNhbWUga2V5IHBhcmFtIG11c3QNCiBiZSBuZWdvdGlhdGVkIG9uIGJvdGggaGFuZHNoYWtlczsg aW52ZXJzZWx5IGlmIFRva2VuIEJpbmRpbmcgaXMgbm90IG5lZ290aWF0ZWQgaW4gdGhlIGZpcnN0 IGhhbmRzaGFrZSwgdGhlbiBpdCBtdXN0IG5vdCBiZSBuZWdvdGlhdGVkIGluIHRoZSBzZWNvbmQu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5FdmVuIG1vcmUgZGV0YWlscyBuZWVkcyB0byBnbyB0byB3aGF0IEVLTSB2YWx1ZSBzaG91bGQg YmUgc2lnbmVkIGF0IGFueSBnaXZlbiBwb2ludC4gUmVuZWdvdGlhdGlvbiBjYW4gdGVjaG5pY2Fs bHkgaW50ZXJsZWF2ZSB3aXRoIGFwcGxpY2F0aW9uIGRhdGEsIHNvIHRoaXMgc2VlbXMgcXVpdGUg aWxsLWRlZmluZWQNCiBmb3Igd2hhdCBhIFRva2VuQmluZGluZ01lc3NhZ2Ugc2hvdWxkIGluY2x1 ZGUgZm9yIGEgc2lnbmF0dXJlIGlmIGl0IGlzIHNlbnQgaW4gYXBwbGljYXRpb24gZGF0YSBpbiB0 aGUgbWlkZGxlIG9mIGEgcmVuZWdvdGlhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TdXBwb3NlIGEgcmVuZWdvdGlhdGlv biBoYXBwZW5zIGJldHdlZW4gYSBjbGllbnQncyBodHRwIHJlcXVlc3QgYW5kIHRoZSBzZXJ2ZXIn cyByZXNwb25zZSAoYXMgaXMgSSBiZWxpZXZlIHRoZSBjYXNlIGZvciBJSVMgd2l0aCBodHRwLzEu MSkuIFRoZSBjbGllbnQncyByZXF1ZXN0IHdvdWxkIGNvbnRhaW4gYQ0KIFRva2VuQmluZGluZ01l c3NhZ2Ugd2l0aCBhIHNpZ25hdHVyZSBvdmVyIHRoZSBvcmlnaW5hbCBFS00sIGJ1dCB3aGVuIHRo ZSBzZXJ2ZXIgaXMgc2VuZGluZyB0aGUgcmVzcG9uc2UgdGhlIGNvbm5lY3Rpb24gbm93IGhhcyBh IG5ldyBFS00sIHNvIHRoZSBzZXJ2ZXIgbmVlZHMgdG8gcmVtZW1iZXIgdGhlIG9sZCBFS00gdG8g dmVyaWZ5IHRoZSBzaWduYXR1cmUuIEkgaW1hZ2luZSB0aGluZ3MgZ2V0IG11Y2ggbW9yZSBjb21w bGljYXRlZCB3aXRoIGh0dHAyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+T24gTW9uLCBBdWcgOCwgMjAxNiBhdCAyOjI0IFBNLCBBbmRy ZWkgUG9wb3YgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPklFL0lJUyB1c2UgcmVuZWdvdGlhdGlvbiBhIGxvdCwgc28gQ2hyb21l4oCZcyBhcHBy b2FjaCB3b3VsZCBub3Qgd29yayBmb3IgdXMsIGJ1dCBNYXJ0aW7igJlzIG51YW5jZWQgbGFuZ3Vh Z2UgZG9lcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiBOaWNrIEhhcnBlciBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpuaGFycGVyQGdvb2ds ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5uaGFycGVyQGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+ U2VudDo8L2I+IE1vbmRheSwgQXVndXN0IDgsIDIwMTYgMjoyMCBQTTxicj4NCjxiPlRvOjwvYj4g QW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5j b20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWlsLmNv bTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj51bmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W1VuYmVhcmFibGVdIFJlbmVnb3RpYXRpb24gaW5mbyBleHRlbnNpb248L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DaHJvbWUncyBUb2tlbiBC aW5kaW5nIGltcGxlbWVudGF0aW9uIHRha2VzIHRoZSBhcHByb2FjaCBvZiBmb3JiaWRkaW5nIHJl bmVnb3RpYXRpb24gZW50aXJlbHkuIEkgd291bGQgYmUgaW4gc3VwcG9ydCBvZiBvbmx5IGFsbG93 aW5nIG9uZSBvZiB0b2tlbiBiaW5kaW5nIG9yIHJlbmVnb3RpYXRpb24gb24gYQ0KIGNvbm5lY3Rp b24sIGFuZCB0aGVuIHRoaXMgY29uc2lkZXJhdGlvbiBhYm91dCBSSSBiZWNvbWVzIGEgbW9vdCBw b2ludC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5P biBNb24sIEF1ZyA4LCAyMDE2IGF0IDEyOjQ2IFBNLCBBbmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9 Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJl aS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+WWVzLCB3ZSBjYW4gcmVwaHJhc2UgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b24gaW4gdGhpcyBtb3JlIG51YW5jZWQgd2F5LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp1bmJlYXJhYmxl LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51bmJlYXJhYmxlLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb248YnI+DQpTZW50OiBTdW5kYXks IEF1Z3VzdCA3LCAyMDE2IDExOjU1IFBNPGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzp1bmJlYXJh YmxlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+ DQpTdWJqZWN0OiBbVW5iZWFyYWJsZV0gUmVuZWdvdGlhdGlvbiBpbmZvIGV4dGVuc2lvbjxicj4N Cjxicj4NCkkga25vdyB0aGF0IHRoaXMgaXMgcHJvYmFibHkgb2xkIG5ld3MsIGJ1dCB0aGVyZSBp cyBhbiBhbHRlcm5hdGl2ZSB0byB1c2luZyB0aGUgcmVuZWdvdGlhdGlvbiBpbmZvIGV4dGVuc2lv bi4mbmJzcDsgVGhhdCBpcyB0byBmb3JiaWQgcmVuZWdvdGlhdGlvbiBlbnRpcmVseS4mbmJzcDsg V2UncmUgYXQgdGhlIHBvaW50IG5vdyB3aGVyZSBsb3RzIG9mIGltcGxlbWVudGF0aW9ucyBkbyB0 aGlzIGFuZCBzb21lIG9mIHRoZW0gYXJlIG5vdCBpbmNsdWRpbmcgdGhlIFJJDQogZXh0ZW5zaW9u IGF0IHRoZSBzYW1lIHRpbWUuPGJyPg0KPGJyPg0KRm9yIFRCLCByYXRoZXIgdGhhbiByZXF1aXJp bmcgUkksIGNhbiB3ZSBpbnN0ZWFkIHByb2hpYml0IHRoZSB1c2Ugb2YgcmVuZWdvdGlhdGlvbiBp ZiBSSSBpcyBub3QgbmVnb3RpYXRlZD88YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0PGJy Pg0KPGEgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5V bmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZTwvYT48YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClVuYmVhcmFi bGUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5VbmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZSIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZTwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR03MB2155ECB11A6D643617C70C4F8C1C0CY1PR03MB2155namp_-- From nobody Mon Aug 8 17:20:17 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 5B83D12D1A1 for ; Mon, 8 Aug 2016 17:20:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, 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 Vq-UGvyMPjA6 for ; Mon, 8 Aug 2016 17:20:12 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 09AFF12D10F for ; Mon, 8 Aug 2016 17:20:12 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id 35so278869475uap.1 for ; Mon, 08 Aug 2016 17:20:11 -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=phXL1kxvPhWvxzywW+ZlE1BYcbr02odYS6x1VcGy55o=; b=ArOrqWN0OWEF0Cmh1poD1QCdEJpqSnxdkGA6iJZLPJm9i/4UayymGf02E+1nHlC0cJ LCww0mu8+kIGCupzsRQpHPFTNHsaE49k1/UdViHtVsPzUQOGkCGSt+hmRpcB9jwm+g4q NsZaRju/+6JL2jUUIByQuc6saE7nHqI50MFWrxLYfUoLb1eBDb62ZPGqZN+JUF1txy3X zNhFn/+9a9rI1oDxKRNNvNbTOxjIqBinwjGH8JQA7O5dCYabtXOvrK4xFIZtQ5UgKo2U zzcqDh5Dy6nkR7FOUqFLaqXXdYAmeRF2yZHhJsDHEmpF2VOHloWLtOqqqqgGAcVftn37 Fb9Q== 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=phXL1kxvPhWvxzywW+ZlE1BYcbr02odYS6x1VcGy55o=; b=Qe1l8Yw1zqS8nw7OqKK+O8+EDiwTNjudgyIef724jKcYh5Cnq/fZ5pn8MzWowRkUGS HRqYW4VNxeYEyF30DdjtrKvA4R1xacOeCLxEhyPZIVQeciAIi5T5/RNFIIDIOHJUmDKL 4A4IdWU0x0UR+DTtSsm4ocmxE+n26Za8mm9fK4SEg9kp2S2DCMZFyu9EoK2AqhKZmqpX B/LGeyzEki+bT52g7UaQEXbjQ1vYtYZ1MN8AcO7AQUDkY48ZzQIrt57ekyobRrKvFhEA 7g+QHQVNu6RW7Jl2VdxQLrQoqTsvXvGZwp7O3gcmkj/phM+IxxYRewBAgVRqtjsJaJEU 8SFg== X-Gm-Message-State: AEkoout0PqyJO7UfcTN3RQ1zRskPsn9WBy+Qg0VuLdETkHO1xuZP28IP3gidBIo733MQRr3GcwWnM+HttY8sToiH X-Received: by 10.31.107.89 with SMTP id g86mr10881206vkc.52.1470702010970; Mon, 08 Aug 2016 17:20:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.209 with HTTP; Mon, 8 Aug 2016 17:19:50 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Mon, 8 Aug 2016 17:19:50 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a11478678ef8b390539987e37 Archived-At: Cc: "unbearable@ietf.org" , Martin Thomson Subject: Re: [Unbearable] Renegotiation info extension 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, 09 Aug 2016 00:20:16 -0000 --001a11478678ef8b390539987e37 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 8, 2016 at 5:03 PM, Andrei Popov wrote: > =C3=98 Why not require that TB parameters must be the same? This would > simplify implementations insofar as the TB key would remain the same for > the client. > > Once the TLS handshake is complete, a client receives the negotiated TB > parameters, retrieves the appropriate TB key, and generates the TB messag= e. > Adding a verification step that requires the client to distinguish > renegotiations and remember previous TB settings does not look like a > simplification to me. > > > > =C3=98 In this case, the client's request was sent before the renegotiat= ion > handshake, so it can only contain a signature of the old EKM. > > True, but it does not matter because the client is unauthenticated in thi= s > TLS session, so the server initiates renegotiation. > The client is still going to send a Sec-Token-Binding header in that request before the renego. Is the server completely ignoring the cookies (and the sec-token-binding header) in the request pre-renego? Unless the spec is going to add this restriction, I still think it should be considered. > > > =C3=98 The server's response is after the renegotiation handshake. Is th= e > server going to try to use the old EKM or the new EKM when processing the > client's request? > > TB is not established until the client sends the TB message in the new TL= S > session and the server validates it. So the server will use the current E= KM > at the time of TB message validation, i.e. the new one. > I'm imagining this flow: 1. Client sends http req 2. Server asks for renego 3. Client and server do renego handshake 4. Server sends http response (to req in #1) I'm assuming you're not saying that in step 4, the server is using the new EKM to validate the TB in request 1? If there are any other interleavings of the renegotiation handshake with application data that are possible, you should consider how TB will work in those cases, or forbid those cases. I'm curious how all of the use cases of renego with IE/IIS work with HTTP/2 (which forbids renego). Can we do the same thing for Token Binding? --001a11478678ef8b390539987e37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Aug 8, 2016 at 5:03 PM, Andrei Popov <Andrei.Popov@microsoft.= com> wrote:

=C3=98=C2=A0 Why not require that TB parameters must be the = same? This would simplify implementations insofar as the TB key would remai= n the same for the client.=C2=A0

Once the TLS handshake is complete, a client receiv= es the negotiated TB parameters, retrieves the appropriate TB key, and gene= rates the TB message. Adding a verification step that requires the client to distinguish renegotiations and remember previo= us TB settings does not look like a simplification to me.

=C2=A0

=C3=98=C2=A0 In this case, the client's request was sent= before the renegotiation handshake, so it can only contain a signature of = the old EKM.

True, but it does not matter because the client is = unauthenticated in this TLS session, so the server initiates renegotiation.=


The client is still= going to send a Sec-Token-Binding header in that request before the renego= . Is the server completely ignoring the cookies (and the sec-token-binding = header) in the request pre-renego? Unless the spec is going to add this res= triction, I still think it should be considered.=C2=A0

=

=C2=A0

=C3=98=C2=A0 The server's response is after the renegoti= ation handshake. Is the server going to try to use the old EKM or the new E= KM when processing the client's request?

TB is not established until the client sends the TB= message in the new TLS session and the server validates it. So the server = will use the current EKM at the time of TB message validation, i.e. the new one.


=
I'm imagining this flow:
1. Client sends http req<= /div>
2. Server asks for renego
3. Client and server do reneg= o handshake
4. Server sends http response (to req in #1)

I'm assuming you're not saying that in step 4, the= server is using the new EKM to validate the TB in request 1?
If there are any other interleavings of the renegotiation hands= hake with application data that are possible, you should consider how TB wi= ll work in those cases, or forbid those cases.

I&#= 39;m curious how all of the use cases of renego with IE/IIS work with HTTP/= 2 (which forbids renego). Can we do the same thing for Token Binding?
=

--001a11478678ef8b390539987e37-- From nobody Mon Aug 8 19: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 1BD6512D181 for ; Mon, 8 Aug 2016 19:01:03 -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, FREEMAIL_FROM=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 (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 kenK-3aD8RFJ for ; Mon, 8 Aug 2016 19:01:02 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 EFBCE12D176 for ; Mon, 8 Aug 2016 19:01:01 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id l2so416294qkf.3 for ; Mon, 08 Aug 2016 19:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SHYvCnBeOnqmybt+pGprf1GQsYe5g3SzRQB4ATNtPyk=; b=mh8Xu8fU7sKRPROB4T8JQ6LWX/VQxcGO1v2IN14X0cASr31mJIDkq7Gcw+mW1q8O/r AGQwFq+IhDIagLBYHBqHZnoBecM0XCzUEQZd8A4R1dIsCCepQVFE7zs1g82kWAMwr2Q+ v6/9xvCavbJj1SGzQWM4ICJLcDS+v7f7tdKsW6LcKgadYCKtNCgqOyUDK807xofI6hs7 O7YHeqwsZVuPGMCI7M402+g6ZvI17qiNlfr/SxU5cPXVQU6eSBHj2UNB9ACgSLajjgb/ SZ4Vu20PqpRGHi6rrjAoestaUYWnH5jPaKyzgzjrdENBK8MGCF3HRiToJQDdsRoKvdI/ vgrA== 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:content-transfer-encoding; bh=SHYvCnBeOnqmybt+pGprf1GQsYe5g3SzRQB4ATNtPyk=; b=JY9u84XzUXQfLg4+1VYUC60Gu35/qyIMC82nBvSRSdBHW+SKnO9Hm4BZjw2yD3IqTR ccecqSbOwzS/NoEUsibyL6l6T7dz5Dek+PfFCPyasdY4vcP+5yZHOv8YVAW0KtEbKiie foND0XEYXVdiT3NbL9XMbCkfcwJT+d3Redty2NWAh/DAMzTFxwaNnRTvi6+OSah8sSjT MNc7a6SNJ/DZYF8cK5QR71K9+2PjAz4JaV0ttrcnHNyPv/2E3Dn7JRV0z/btZkUlOkWu iJ97Ur5HX/D5zkmZTsudizSoDtV3BjZguGY4Y/SBCfwJpYw7VlvBXf1cuQ6upw4Wv4M+ OhPw== X-Gm-Message-State: AEkoouvP7TfWHClYmin4aR+qlgb4PPP9/tfoEvrYBIuhWGCLCEe+kbziKHS64GLG95zqfhHBbnPAzgntzyQMpg== X-Received: by 10.55.75.76 with SMTP id y73mr34500609qka.12.1470708060997; Mon, 08 Aug 2016 19:01:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Mon, 8 Aug 2016 19:01:00 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 9 Aug 2016 12:01:00 +1000 Message-ID: To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "unbearable@ietf.org" , Nick Harper , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 09 Aug 2016 02:01:03 -0000 On 9 August 2016 at 04:05, Andrei Popov wrote: > 1. It=E2=80=99s wasteful on the wire: one would be duplicating TLS e= xtension > bytes and lists of TB key parameters. And this is in the ClientHello, whe= re > we care about size. Yeah, I know that this costs, but if you move to that, it's 6-8 octets right now, plus any more for EdDSA. v2 might duplicate those octets, but that's nothing when compared with the 70+ octets that a key share in TLS 1.3 adds. > 2. Every time we come up with a new TB version, we need to specify a > new TLS extension with its IANA number, etc. Somehow, I don't think that's going to be a problem. From nobody Mon Aug 8 19:04: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 1DBA312D0FC for ; Mon, 8 Aug 2016 19:04:18 -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, FREEMAIL_FROM=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 (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 g5ZTWdlB-sRQ for ; Mon, 8 Aug 2016 19:04:17 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 E55C712B056 for ; Mon, 8 Aug 2016 19:04:16 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id t7so562248qkh.0 for ; Mon, 08 Aug 2016 19:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2HSnHU3EBpkYhVaXDCgsu2URKzP/eG3/gVqHnTxbKdo=; b=XpAXYf3inJZPZUdK9UmY/dqf2SzofveQ1k7Gw7T8ZLoIB2zjsVXUZSSKcbVIuMCK2K Gb+nU2+IvH4O9f1mN2+MAPhjFpPrQN8fyTBtV0aUwhSkqxRAioPbeehGQmWulXOd7CTt UJw8yaGd35GFgoQOMx5xdo38XH79QezxIMcGD39fJM+q28YUUMthLlyL0rlAYdX20f4c Fe/YfBp3/smLXjTfakhoA4E3+Cv6O1LsrZ3dN9Q6fKjyn4P1X9YH5UH3SqyfhfMZZ46M 92qMERnKTbnYdfpgNLP2gD2De3TyunNJIpTAfCIKYsGAGmai0PqMm+k+2ANUl+GclKZE zVlw== 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=2HSnHU3EBpkYhVaXDCgsu2URKzP/eG3/gVqHnTxbKdo=; b=aTH1J5eOhjGUvQEn2KOQsPA+ZEGWkVctJ/hWEtmy2PTgypweA6mKndrGcoYWsud3Nb ix1Vl5DgH30cVZOAg9In9wjOBT+A+yltOIAzNR3QmLnooE5DBILIKqUtbUouM4xudnER WDZvSipbEvN306av0X/xDsJSLeQ5+Ye+6K8iJZcgZtXHH446R0vBU3oH6dz1Y838Cc/8 KmIbhCmC29BSBzox9TiB4nMXPJcFpIlZvePwoNV/1Ihey2As13ELx8fndiPJZ6xJHVsW uApFJ70fT811Aw2zeAl0/IBrEZN8n4XwGv4EjPTXaK/HWXvXZJ83o8t5RND3MkNiNKTr piEA== X-Gm-Message-State: AEkoouv/jEI3TCZmU0RRhHk7z3Gn9ALJwg68QLWM3FuXdmC/wcpgcdZHA5FWOW3gEwYaAs1sV55DWBxrSjOzyA== X-Received: by 10.55.75.76 with SMTP id y73mr34513388qka.12.1470708256139; Mon, 08 Aug 2016 19:04:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Mon, 8 Aug 2016 19:04:15 -0700 (PDT) In-Reply-To: References: <974CF78E8475CD4CA398B1FCA21C8E99565A9DF7@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9EB0@PRN-MBX01-4.TheFacebook.com> <974CF78E8475CD4CA398B1FCA21C8E99565A9F26@PRN-MBX01-4.TheFacebook.com> From: Martin Thomson Date: Tue, 9 Aug 2016 12:04:15 +1000 Message-ID: To: Anthony Nadalin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "unbearable@ietf.org" , Subodh Iyengar , Nick Harper Subject: Re: [Unbearable] migrations of token bindings 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, 09 Aug 2016 02:04:18 -0000 On 9 August 2016 at 04:17, Anthony Nadalin wrote: > By authenticate them do you me validate their authenticity ? or something different? I meant to refer to referred token bindings. Migration there is harder. From nobody Mon Aug 8 19:14:48 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 1C02A12D685 for ; Mon, 8 Aug 2016 19:14:46 -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, FREEMAIL_FROM=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 (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 2SbZd08p8AAh for ; Mon, 8 Aug 2016 19:14:44 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 AD10E12D5EC for ; Mon, 8 Aug 2016 19:14:44 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id x185so668187qkc.2 for ; Mon, 08 Aug 2016 19:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R//NjYLFT5Fe6UWmF9vYZJrLM3EWJ3pIIGw3WRxD8NE=; b=vlJX1gzQoodVkuX6Yn/YJ56TV5PvdSOWAWdB/MzJaOa3qqOlBFbiWoy2oRkDiT4t5Q dFzz8xbs8jFbLlmxXV2EXsLdUBkiUv7DS3G4Ue9+0LYM63I+fmrfb6FC/pE5lBcFfacT xCc0HYXvvWPUlYsMVcTIbCtt9c6fOmSc8QyiV55hF6NHPhg4K5on0D6YKVeFCGiPWdwA vvQliGtjRUd391LqLcbg2j1/WmjAoN2hj7r5ictM3/1AkhY/A5uHV4H5qRXomnxVJHrV lDKZCDs+gOzZXJZtoPXVUuQhxYyegMYBbx4IRbO8u8DNrrG6IusrpUGXfIH/FDnvPISE nWzg== 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=R//NjYLFT5Fe6UWmF9vYZJrLM3EWJ3pIIGw3WRxD8NE=; b=B76QUzWZsFEENgnNsSXJac+mxvixVd71UAmNFexR3UV1jjD1/HPBE5OuVAG6JAzJW3 0ZSRLuIy98nELzTGhQRg+46uZyJbXqlemzhKuEDc3OPwj3Hrv87zokDJ30a/47kBbs+Z 0+YrcA4XrEnrs3WEW0vYrg4PYHgIV9+ja3uCBnskcHN154Y1WUh6jZeXnAB8JDuJE7cn db/TNb2lPFMe4O9FrPRehJM8oI+02KkViV9ZM1ZrhjsHlHF8K+G1uNYDniSTcxcEEZPo gTeewIBkt+3dYKhhUYXsJQCdKn4/2LZKrl49xbbFgPHTuNq4kIeLrKMYHbs0S9IB+Szw npgA== X-Gm-Message-State: AEkoouuzzGqDKOMSJMhvJF+zWRXjspry5iDLx5Jip8AyM+zjt4e9ewNIvLUFa4aqvV+F8ulHgCEm5MR6p2hzcQ== X-Received: by 10.55.116.134 with SMTP id p128mr9880526qkc.165.1470708883878; Mon, 08 Aug 2016 19:14:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Mon, 8 Aug 2016 19:14:43 -0700 (PDT) In-Reply-To: References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> From: Martin Thomson Date: Tue, 9 Aug 2016 12:14:43 +1000 Message-ID: To: John Bradley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Subodh Iyengar , Scott Cantor , IETF Tokbind WG , Brian Campbell , "Manger, James" , Nick Harper Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 09 Aug 2016 02:14:46 -0000 On 9 August 2016 at 04:38, John Bradley wrote: > Martin do you have some idea how a token bound cookie set by x.example.com > could be validated by y.example.com under a strict same origin policy. So x sets a cookie bound to key Kx. Only x can validate that key because the client doesn't use that key with other parties. That means that y needs to get the client to prove possession of (the private key for) Kx. With the help of x, it can easily do this with a referred token binding. y makes the client make a request to x, and x redirects back to y with the header field set. Then y is able to acquire proof from the client that it owns Kx. This only requires that y support the same signature schemes as x, and that y has help from x. Sure, this is inconvenient (it's round trips), but this establishes possible. And, once you have this proof, you might be able to store the mapping between Kx and Ky. From nobody Mon Aug 8 19:28:06 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 0369C12D592 for ; Mon, 8 Aug 2016 19:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 9RJsUV8Vx7QB for ; Mon, 8 Aug 2016 19:28:01 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0102.outbound.protection.outlook.com [104.47.37.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4AB812D688 for ; Mon, 8 Aug 2016 19:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8FEXUzFV0RvRX/g3CuNd9NOXgpYam/gSXjNpKEqBixY=; b=EhmWyrDGEbziK9linG/IInyDp6D1jNKT2Qe96J0hLhrvjsJ+Pplt4RLV9o2MlXT8all8IwiMT9r48t+0HgP5g311tmyk4uD8o12i9tciDsYVZOvI2wYP/YRD2MMLs5C7jDLyxrzS2kMCyMQzcEPuaOgbJa3/DgM9gDlIU04RKPk= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2156.namprd03.prod.outlook.com (10.166.206.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 9 Aug 2016 02:27:58 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0549.025; Tue, 9 Aug 2016 02:27:58 +0000 From: Andrei Popov To: Martin Thomson Thread-Topic: [Unbearable] TLS extension: version field Thread-Index: AQHR8UE0hAr3fGh5LkSos3djbwbcUaA/MmwAgAAmOoCAAAGk8IAAhvMAgAAFqjA= Date: Tue, 9 Aug 2016 02:27:58 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:d::1d2] x-ms-office365-filtering-correlation-id: 1cd50664-4736-4afd-29e8-08d3bffcc768 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2156; 6:nLT2gl89MzBIgBnSznjbLbQNOH/pQPYkGVkATXPC4c0ApnifWNiRYumN5b6xSwBO7X1rHYXUQYZt9rN7nySOF3oA3APMd3oHjPkJn0IMR4iOCXlzAYIX3ksuT9URk9LBVgvf/GhA8jFQpOabhNi1hsnzNRKbQHTHC3WdRzxyW5ZgMJebj+pgFebWgDNC/8qJxMy2YeEKJWuM2AC0bLYbK3X/EJGXO0/tL+tfdc61hACXezTSho1nLW5OQC+YNXmnYTsXnmNrHrR7uH3vlBmq8Zk7Qmn854j4A6xRFuCWuM+NLE8gI7o8ev4skr2oEtv5WsA4V8ch+a5wqB2f/EI1WA==; 5:ksMuYv8fMwXkj4be6HIDDsmKSRDx+Klm7cU0IBFBPc1xw2r4bwwxRZelS9cAkKJCL6LrbcnrhoqrEdOu95h+Jr06V39omyH+kMObbFouibEBelsrdJfXXSap3kfEp7kSWcyB61BSQGrrVPjGwhxlYw==; 24:Nw1uAvH5zJxclY+EOZzfIB3e3qS1zCkesVMddZ2HKLgd6UIWgFGUi28HkjVmq4/tedjgjn0wSkZtnlmXf+5Dh07QVCZSX+VDSfIVHF//0P4=; 7:tu2nIJbuGZRHhH7csiGWlpGUFe8zvjqKTaEnB6/FyJQwsxbsvK3ePaganAGlcNfH/YMkkuGHdf1dfa122kHXGBplJQzxomXQuCbiM6AuWj00PurSEcuG6DgkSCtm1VeyjFe9Olcu3TUX5GQyMAULmoAaNUCURo5eUl4yZ7ehLhdgdM5b4ohWP7pozTLbcwMjbsbD1pIZs7Tbx92xt79VKUsCeHWFTXEJUzkij1405DqntGrjG2XHoEhp4KeovfkF x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2156; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2156; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2156; x-forefront-prvs: 0029F17A3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(24454002)(13464003)(377454003)(199003)(2906002)(3280700002)(3660700001)(8990500004)(4326007)(86362001)(5002640100001)(10290500002)(586003)(81156014)(7736002)(81166006)(561944003)(305945005)(10400500002)(7696003)(7846002)(33656002)(76576001)(5005710100001)(68736007)(122556002)(11100500001)(10090500001)(9686002)(8676002)(74316002)(92566002)(6116002)(102836003)(76176999)(8936002)(2950100001)(93886004)(2900100001)(77096005)(19580395003)(105586002)(86612001)(189998001)(110136002)(19580405001)(106356001)(50986999)(106116001)(54356999)(99286002)(97736004)(101416001)(87936001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2156; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 09 Aug 2016 02:27:58.4515 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2156 Archived-At: Cc: "unbearable@ietf.org" , Nick Harper , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 09 Aug 2016 02:28:03 -0000 SXQncyA2LTggYnl0ZXMgdGltZXMgdGhlIG51bWJlciBvZiBzdXBwb3J0ZWQgVEIgdmVyc2lvbnMu IEluIHRoZSBUTFMgMS4zIGRpc2N1c3Npb24gc28gZmFyLCB3ZSd2ZSBub3QgYWRvcHRlZCB0aGUg ZXh0ZW5zaW9uLWJhc2VkIHByb3RvY29sIHZlcnNpb24gbmVnb3RpYXRpb24gYXBwcm9hY2guDQoN CkFsc28sIHRoZSBwcm9wb3NhbCByZXF1aXJlcyB0aGF0IGEgVExTIHN0YWNrIGJlIHVwZGF0ZWQg Zm9yIGV2ZXJ5IG5ldyBUQiB2ZXJzaW9uLCB3aGljaCBpcyBhIHJlYWwgZHJhd2JhY2suIFdpdGgg dGhlIGN1cnJlbnQgVEIgbmVnb3RpYXRpb24gZXh0ZW5zaW9uLCB3ZSBjYW4gYWRkIG5ldyBUQiB2 ZXJzaW9ucyB3aXRob3V0IGNoYW5naW5nIFRMUy4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcnRpbiBUaG9tc29uIFttYWlsdG86bWFy dGluLnRob21zb25AZ21haWwuY29tXSANClNlbnQ6IE1vbmRheSwgQXVndXN0IDgsIDIwMTYgNzow MSBQTQ0KVG86IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+DQpDYzog TmljayBIYXJwZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbT47IEJpbGwgQ294IDx3YXl3YXJkZ2Vla0Bn b29nbGUuY29tPjsgdW5iZWFyYWJsZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxl XSBUTFMgZXh0ZW5zaW9uOiB2ZXJzaW9uIGZpZWxkDQoNCk9uIDkgQXVndXN0IDIwMTYgYXQgMDQ6 MDUsIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPiAx LiAgICAgIEl04oCZcyB3YXN0ZWZ1bCBvbiB0aGUgd2lyZTogb25lIHdvdWxkIGJlIGR1cGxpY2F0 aW5nIFRMUyBleHRlbnNpb24NCj4gYnl0ZXMgYW5kIGxpc3RzIG9mIFRCIGtleSBwYXJhbWV0ZXJz LiBBbmQgdGhpcyBpcyBpbiB0aGUgQ2xpZW50SGVsbG8sIA0KPiB3aGVyZSB3ZSBjYXJlIGFib3V0 IHNpemUuDQoNClllYWgsIEkga25vdyB0aGF0IHRoaXMgY29zdHMsIGJ1dCBpZiB5b3UgbW92ZSB0 byB0aGF0LCBpdCdzIDYtOCBvY3RldHMgcmlnaHQgbm93LCBwbHVzIGFueSBtb3JlIGZvciBFZERT QS4gIHYyIG1pZ2h0IGR1cGxpY2F0ZSB0aG9zZSBvY3RldHMsIGJ1dCB0aGF0J3Mgbm90aGluZyB3 aGVuIGNvbXBhcmVkIHdpdGggdGhlIDcwKyBvY3RldHMgdGhhdCBhIGtleSBzaGFyZSBpbiBUTFMg MS4zIGFkZHMuDQoNCj4gMi4gICAgICBFdmVyeSB0aW1lIHdlIGNvbWUgdXAgd2l0aCBhIG5ldyBU QiB2ZXJzaW9uLCB3ZSBuZWVkIHRvIHNwZWNpZnkgYQ0KPiBuZXcgVExTIGV4dGVuc2lvbiB3aXRo IGl0cyBJQU5BIG51bWJlciwgZXRjLg0KDQpTb21laG93LCBJIGRvbid0IHRoaW5rIHRoYXQncyBn b2luZyB0byBiZSBhIHByb2JsZW0uDQo= From nobody Mon Aug 8 19:34:41 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 502A512D592 for ; Mon, 8 Aug 2016 19:34:39 -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, FREEMAIL_FROM=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 (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 EtokiGCLugXb for ; Mon, 8 Aug 2016 19:34:38 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 D9B9F12D1B1 for ; Mon, 8 Aug 2016 19:34:37 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id p186so986760qkd.1 for ; Mon, 08 Aug 2016 19:34:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dud1VTWtgqYkmYqzWoCa2I7fAms+sEDmBY4S20IqN0w=; b=r4SW2MZ9xlfIjth6bdkbYt8n40VbIn5y59/ci0kHdOevNgm8rpmfgtlg905w7JJHsL zKJdPGA0xGOt76qrbE3EZRE/GBOW50tAEMhepcGM/KdbNxZpcb8IXg5+jEIHAqSE0LqZ U7K/1LhCXqT4JfaE2ToOFMSiumCXJ304ITWgzXg85X2DpUkALW47HjQ2fHjEv/yiFH55 tx37pBUdTY2sfImHaMOc40WMbF//ZIB/jYaN4S4K4DcDLyYNM8W1gtLbnhsBCw0O6iE7 yDeM7z67fvFmquAiKM4/PFGfPt9PNJcIc5d2EMB0lCHI0ce0x2Ufr6LC+ijM+inc4kdz /X6A== 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=dud1VTWtgqYkmYqzWoCa2I7fAms+sEDmBY4S20IqN0w=; b=lgvPPbrvZucqVgLach1ThmhOQfCfyft5sadfCTmZusCVo2/LcEMdAhAdubN9/6JTP6 StYkMrCjR+0eJWxlt2s04qwcuz4EmJvPSUrvKbjtdfFqNb9CR8O5eGdr5eDrRp+zC0wX faaJxa5drCi3aJxDpvXCGDijI+GDjon0AImIEGPIPTjtybjB8dxUW+UGrchgfjQrWFcp iNXI2cbfSI8DLVjYLVxI73X3HYATbEchTvrhu7K+Gk26QxJH51cZ6H8/5/7FchHJf89W MjHj6WeYK3LIQoDWKupW/4i4s3SkCxoku4o8cecO6pP5D7V5SsAeouJqCxw+b6we6pTW oXLg== X-Gm-Message-State: AEkoouujDLX0Lx6QDTXPtBgB5gosNbNShUJC4AqJj7d9mgPk2riRj3hM3nqlPUAPauWkuO/TrZdykuMNLMv2bw== X-Received: by 10.55.75.76 with SMTP id y73mr34614151qka.12.1470710077111; Mon, 08 Aug 2016 19:34:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Mon, 8 Aug 2016 19:34:36 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Tue, 9 Aug 2016 12:34:36 +1000 Message-ID: To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "unbearable@ietf.org" , Nick Harper , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 09 Aug 2016 02:34:39 -0000 On 9 August 2016 at 12:27, Andrei Popov wrote: > Also, the proposal requires that a TLS stack be updated for every new TB version, which is a real drawback. With the current TB negotiation extension, we can add new TB versions without changing TLS. That's a problem that can be solved with software, if you care about that sort of thing: tls.addGenericClientHelloExtension(id, blob); tls.addGenericServerHelloExtensionHandler(id, (blob) => {...}); blob = tls.getGenericServerHelloExtension(id); From nobody Tue Aug 9 09:49: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 3A64212D84F for ; Tue, 9 Aug 2016 09:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 prlnrfmvyDtX for ; Tue, 9 Aug 2016 09:49:42 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0099.outbound.protection.outlook.com [104.47.42.99]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D17212D112 for ; Tue, 9 Aug 2016 09:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=i0d5nZti0wb9LSP+VakGBXjaFx9bQVo1Z04AAklLSJU=; b=BOORj24nHA+T+xHjin67sXRhySMinjgBkHCH7WGM++NNmazHYK4bg30ZUgyAE3wLy7nPXkhaXrN9p3enuVypUP4I5oEh8sw52w1sL2bqKIRylByuzn/Pn7KOtJZoZ30M9YJbRKSl1k83jc51NaCt+skKtY3/ZyS3lGmWI3Hv6Uk= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2153.namprd03.prod.outlook.com (10.166.206.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 9 Aug 2016 16:49:39 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0549.025; Tue, 9 Aug 2016 16:49:39 +0000 From: Andrei Popov To: Martin Thomson Thread-Topic: [Unbearable] TLS extension: version field Thread-Index: AQHR8UE0hAr3fGh5LkSos3djbwbcUaA/MmwAgAAmOoCAAAGk8IAAhvMAgAAFqjCAAAO6AIAA6WmA Date: Tue, 9 Aug 2016 16:49:39 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:d::1d2] x-ms-office365-filtering-correlation-id: a61f03e2-5f56-4eb2-102a-08d3c075278c x-microsoft-exchange-diagnostics: 1; CY1PR03MB2153; 6:o/ZRdOopao1imNrtn3I/WexN/Pdz8G9YhgBPPac1/Y+hlP4pa81+GJa8UcLqA/nwguqb5zVpXhbHgfkJJlRvf7FAI1dG7OX/pw0oKD3Mxlu0t8KrIBXumQEUdeQftsf2cEHe1KVUv1DNDRF73DBA1zKEBY1axYy80NfJ3xalRaOpMC9nuYZeCmUvgJpmmRK76YxxZ6Sd9qqJolRSEnDAxUR/RRGNKF+KfD2RF/KpYrQfEgWZdybZQ1uYapPOHZ+ZabXujDXlVKHmykm/JR4FOJB/gXhe2JipjnZgDotbjyJCW15Wtp9U12kh1zSDJDsKsxEXn9ooRoVqvaSfh/Fgww==; 5:ymBQIJpXUXoeztBkZNDzofFh1wXJRai9oyKzYk2yCnqcUMa0ncIME2h9f3BWqe5c/vTgNIc0BdRtopfsuhpYZwxJGKYw9/l+rk+8kuxZcjZesKxy73t0vSvz0OFUSlhpyD6VC2BjsjVVD9XNhdTo4w==; 24:2KBeB602HMAAt/H/73pqRclZ5sipl5NM+BidBXCvS5DxckQ4rGEj0KxvHYnqcmeZsyFr+yCjcZygtsSICL5+bbFaOj2UJ2oys5rroL+AGuQ=; 7:NTHMhVfkBdQ2wRaYUu+mps3AuOU9elWvSFRNAb7LmyRa0kQ61YoMXM90OC/BktiiqJAy4G5jQ/5kmN7wywnMbOxSiDefM0vtLMrPf6P0KInp1/2zrnp0rXUVp4LiviZ8FQr7QAs36eCMs6fQ7qbEO4VP6fGSgm6Xpg8iFJ6Zii631kDu8X1IwryxXxQJwb/CSzgvsmmLWPtqodqs26o+q5jkb6Wqt8+k3iT56MRK8Gj9GIeidYC88M3oU7/A75xy x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2153; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2153; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2153; x-forefront-prvs: 0029F17A3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(24454002)(189002)(377454003)(13464003)(5002640100001)(93886004)(586003)(3280700002)(2906002)(97736004)(99286002)(105586002)(3660700001)(8936002)(102836003)(6116002)(92566002)(10290500002)(561944003)(87936001)(10400500002)(4326007)(81156014)(33656002)(81166006)(8676002)(11100500001)(5005710100001)(2900100001)(106356001)(2950100001)(10090500001)(106116001)(86612001)(122556002)(110136002)(68736007)(7846002)(8990500004)(189998001)(7696003)(7736002)(54356999)(19580405001)(76176999)(19580395003)(9686002)(74316002)(86362001)(305945005)(50986999)(101416001)(77096005)(76576001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2153; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 09 Aug 2016 16:49:39.3596 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2153 Archived-At: Cc: "unbearable@ietf.org" , Nick Harper , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 09 Aug 2016 16:49:44 -0000 VGhlIGRyYXdiYWNrcyBvZiBuZWdvdGlhdGluZyBlYWNoIFRCIHZlcnNpb24gd2l0aCBhIGN1c3Rv bSBUTFMgZXh0ZW5zaW9uOg0KMS4gTW9yZSBieXRlcyBpbiB0aGUgQ2xpZW50SGVsbG87DQoyLiBN b3JlIElFVEYgcHJvY2VzcyB3aGVuIGFkZGluZyBuZXcgVEIgdmVyc2lvbnM7DQozLiBUTFMgdXBk YXRlIGZvciBlYWNoIFRCIHZlcnNpb24sIG9yIHRoZSBuZWVkIHRvIGFkZCAiZ2VuZXJpYyBUTFMg ZXh0ZW5zaW9uIiBzdXBwb3J0LCBwdXR0aW5nIHRoZSBjYWxsZXIgb2YgdGhlIFRMUyBzdGFjayBp biBjaGFyZ2Ugb2YgaGFuZGxpbmcgKGEgc3Vic2V0IG9mKSBUTFMgZXh0ZW5zaW9ucy4NCg0KVGhl IHBvdGVudGlhbCBiZW5lZml0czoNCmEpIEV4dGVuc2liaWxpdHkgaXMgY29uY2VudHJhdGVkIGlu IG9uZSBwbGFjZT8NCmIpIFRoZSBzZXJ2ZXIgaGFzIGEgbGlzdCBvZiBhbGwgY2xpZW50LXN1cHBv cnRlZCBUQiB2ZXJzaW9ucyBpbiB0aGUgQ2xpZW50SGVsbG8gKHRoaXMgY2FuIGJlIGFjaGlldmVk IHdpdGhpbiBvbmUgVExTIGV4dGVuc2lvbiwgaWYgZGVzaXJlZCkuDQoNClRvIG1lLCB0aGVzZSBk cmF3YmFja3Mgb3V0d2VpZ2ggdGhlIGJlbmVmaXRzLCBidXQgSSBjb3VsZCBsaXZlIHdpdGggZWl0 aGVyIGRlc2lnbi4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IE1hcnRpbiBUaG9tc29uIFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwu Y29tXSANClNlbnQ6IE1vbmRheSwgQXVndXN0IDgsIDIwMTYgNzozNSBQTQ0KVG86IEFuZHJlaSBQ b3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+DQpDYzogTmljayBIYXJwZXIgPG5oYXJw ZXJAZ29vZ2xlLmNvbT47IEJpbGwgQ294IDx3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPjsgdW5iZWFy YWJsZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBUTFMgZXh0ZW5zaW9uOiB2 ZXJzaW9uIGZpZWxkDQoNCk9uIDkgQXVndXN0IDIwMTYgYXQgMTI6MjcsIEFuZHJlaSBQb3BvdiA8 QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPiBBbHNvLCB0aGUgcHJvcG9zYWwg cmVxdWlyZXMgdGhhdCBhIFRMUyBzdGFjayBiZSB1cGRhdGVkIGZvciBldmVyeSBuZXcgVEIgdmVy c2lvbiwgd2hpY2ggaXMgYSByZWFsIGRyYXdiYWNrLiBXaXRoIHRoZSBjdXJyZW50IFRCIG5lZ290 aWF0aW9uIGV4dGVuc2lvbiwgd2UgY2FuIGFkZCBuZXcgVEIgdmVyc2lvbnMgd2l0aG91dCBjaGFu Z2luZyBUTFMuDQoNClRoYXQncyBhIHByb2JsZW0gdGhhdCBjYW4gYmUgc29sdmVkIHdpdGggc29m dHdhcmUsIGlmIHlvdSBjYXJlIGFib3V0IHRoYXQgc29ydCBvZiB0aGluZzoNCiAgdGxzLmFkZEdl bmVyaWNDbGllbnRIZWxsb0V4dGVuc2lvbihpZCwgYmxvYik7DQogIHRscy5hZGRHZW5lcmljU2Vy dmVySGVsbG9FeHRlbnNpb25IYW5kbGVyKGlkLCAoYmxvYikgPT4gey4uLn0pOw0KICBibG9iID0g dGxzLmdldEdlbmVyaWNTZXJ2ZXJIZWxsb0V4dGVuc2lvbihpZCk7DQo= From nobody Tue Aug 9 10:19: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 6230D12D128 for ; Tue, 9 Aug 2016 10:19:29 -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 SbsxbKyG5LGY for ; Tue, 9 Aug 2016 10:19:27 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0126.outbound.protection.outlook.com [104.47.32.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5BEC12D0E7 for ; Tue, 9 Aug 2016 10:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PpSYZw/TbVaVgVcweRksujq0bP9gXj1JIZhWvYE67ko=; b=QGw2RCg/1TThP0/2OOoaPTZlTPL1T3esZgqb++6h6oxP4szmB0h9bRKUTqh+VjV+su1Wnp39lOH7dsPeKeh/L1wGlf+8FdDmusCZEj5SBvid1pK8nCev3VCRHplE7Kl6djYh5cAJZWjXdYzhZ15GtLGC+FdEnq2qacWSOmrCqFg= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2156.namprd03.prod.outlook.com (10.166.206.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Tue, 9 Aug 2016 17:19:24 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0549.025; Tue, 9 Aug 2016 17:19:24 +0000 From: Andrei Popov To: Nick Harper Thread-Topic: [Unbearable] Renegotiation info extension Thread-Index: AQHR8UG+1juUPHgk7k6r83vWCBCSUaA/dqjAgAAcAoCAAABzoIAABpOAgAAHYiCAAA5nAIAAC8qAgAAJtQCAABXnQA== Date: Tue, 9 Aug 2016 17:19:23 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:d::1d2] x-ms-office365-filtering-correlation-id: 4a87cfbc-986c-4128-563a-08d3c0794f38 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2156; 6:up6BF8m6R37icm2MlYM20heM57l/JJTnQX/n5LN54/Jq/KD6BvItTNZtH2BvPNGbSVkiBLWOubCnCPt+ced9SXC3OTbwoKOxGTer14lIvX4mm0tCNcu0MvEi+ugOFv8ERRukwdR/ZrK79k8uyzJCifjY0JDmhaOy73r75jt3ZOeJYUOD2LE4aEBZ0B8+V2s6Lkaf++VuJe/irJrGyYgWp1mtgh4l/Es1ougol6o8J+q4fB4l79tKWNk5HfVaw/PfiUUIryk9c4HmarIoo/w3CJYBK/ZwRIpVuw3rntElC96eSUtfgtEfqAHQl5A9opLhJH6btCwtqEMc92wS4x8Ztg==; 5:VMWCgxm6uwD1ELJUH9hYCOh+f8BHKHKkE7W0Jhuau9y64iJzWNeTWploHRCzzgddj4SDuF3OLC9Lt38bHEKhQ4/NuNGV9ql3xDLN3YDyJ2vJ4EqsKuFIteUNzmK7UasgGX2XHb4WYsc9hw/mBP4Zuw==; 24:cPEpfEq4Po2pcOkxQS9QP7QelyHKvWaxGvCWYAGez3xL1lAL+/7hJQoYChipPhRtxU9OdhtCXE6v+/ykX5XLlf82YaRyQrjPdeXqu0/e1t0=; 7:yuCKjKU1NhWOfDzktOEAhWiHC3qHVMf9VFci40/mB7PAgqD8p3+We/JNBHa+Ouv6jKvzJW9mfgeu5xoXF/4TL3OIlwp19ccvW5JUAzQZ4/3SFq+q7U9uNzptdd5+GX6wTcmEXupuiwfiYDQB0+tw/Ng9W7F+sG6jJDLTQUny8cXTBbWDz8Dl9X2bVWI+a4O4u3SC1o4JQRoG1Tl4KbOzx2kiu89+OTF+wlft2beq1kTGrCwkd6bbIWT/UP9NiPVM x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2156; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2156; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2156; x-forefront-prvs: 0029F17A3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(189002)(24454002)(106116001)(86362001)(54356999)(76176999)(50986999)(19625215002)(97736004)(2950100001)(2900100001)(19609705001)(106356001)(101416001)(77096005)(15975445007)(33656002)(19580395003)(19580405001)(5005710100001)(19300405004)(92566002)(110136002)(8676002)(81166006)(81156014)(86612001)(16236675004)(189998001)(87936001)(10400500002)(10290500002)(2906002)(10090500001)(105586002)(4326007)(8990500004)(8936002)(93886004)(586003)(6116002)(102836003)(790700001)(122556002)(99286002)(5002640100001)(9686002)(74316002)(76576001)(68736007)(3280700002)(11100500001)(7736002)(7846002)(7696003)(3660700001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2156; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB2155C923F0BCAEF1E13DD8F08C1C0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2016 17:19:23.9617 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2156 Archived-At: Cc: "unbearable@ietf.org" , Martin Thomson Subject: Re: [Unbearable] Renegotiation info extension 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, 09 Aug 2016 17:19:29 -0000 --_000_CY1PR03MB2155C923F0BCAEF1E13DD8F08C1C0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluaywgYmFzZWQgb24gdGhlIGN1cnJlbnQgc3BlY3MsIHRoZSBmbG93IHdvdWxkIGxvb2sg bGlrZSB0aGlzOg0KDQoxLiAgICAgICBDbGllbnQgc2VuZHMgaHR0cCByZXF1ZXN0cyB3aXRoIFRC IG1lc3NhZ2U7DQoNCjIuICAgICAgIFNlcnZlciB2YWxpZGF0ZXMgVEIgdXNpbmcgdGhlIGN1cnJl bnQgRUtNIChBKSwgVEIgZXN0YWJsaXNoZWQuDQoNCjMuICAgICAgIFNlcnZlciBwcm9jZXNzZXMg SFRUUCByZXF1ZXN0LCB0cmlnZ2VycyByZW5lZ290aWF0aW9uOw0KDQo0LiAgICAgICBSZW5lZ290 aWF0aW9uIGhhbmRzaGFrZS4NCg0KNS4gICAgICAgU2VydmVyIHNlbmRzIGh0dHAgcmVzcG9uc2Ug KHVuYm91bmQsIGFzIFRCIGlzIG5vdCBlc3RhYmxpc2hlZCBpbiB0aGlzIFRMUyBzZXNzaW9uIHVu dGlsIHRoZSBjbGllbnQgc2VuZHMgYSBuZXcgVEIgbWVzc2FnZSkuDQoNCkZyb206IE5pY2sgSGFy cGVyIFttYWlsdG86bmhhcnBlckBnb29nbGUuY29tXQ0KU2VudDogTW9uZGF5LCBBdWd1c3QgOCwg MjAxNiA1OjIwIFBNDQpUbzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNv bT4NCkNjOiBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPjsgdW5iZWFy YWJsZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBSZW5lZ290aWF0aW9uIGlu Zm8gZXh0ZW5zaW9uDQoNCk9uIE1vbiwgQXVnIDgsIDIwMTYgYXQgNTowMyBQTSwgQW5kcmVpIFBv cG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jv c29mdC5jb20+PiB3cm90ZToNCg0KPiAgV2h5IG5vdCByZXF1aXJlIHRoYXQgVEIgcGFyYW1ldGVy cyBtdXN0IGJlIHRoZSBzYW1lPyBUaGlzIHdvdWxkIHNpbXBsaWZ5IGltcGxlbWVudGF0aW9ucyBp bnNvZmFyIGFzIHRoZSBUQiBrZXkgd291bGQgcmVtYWluIHRoZSBzYW1lIGZvciB0aGUgY2xpZW50 Lg0KT25jZSB0aGUgVExTIGhhbmRzaGFrZSBpcyBjb21wbGV0ZSwgYSBjbGllbnQgcmVjZWl2ZXMg dGhlIG5lZ290aWF0ZWQgVEIgcGFyYW1ldGVycywgcmV0cmlldmVzIHRoZSBhcHByb3ByaWF0ZSBU QiBrZXksIGFuZCBnZW5lcmF0ZXMgdGhlIFRCIG1lc3NhZ2UuIEFkZGluZyBhIHZlcmlmaWNhdGlv biBzdGVwIHRoYXQgcmVxdWlyZXMgdGhlIGNsaWVudCB0byBkaXN0aW5ndWlzaCByZW5lZ290aWF0 aW9ucyBhbmQgcmVtZW1iZXIgcHJldmlvdXMgVEIgc2V0dGluZ3MgZG9lcyBub3QgbG9vayBsaWtl IGEgc2ltcGxpZmljYXRpb24gdG8gbWUuDQoNCg0KPiAgSW4gdGhpcyBjYXNlLCB0aGUgY2xpZW50 J3MgcmVxdWVzdCB3YXMgc2VudCBiZWZvcmUgdGhlIHJlbmVnb3RpYXRpb24gaGFuZHNoYWtlLCBz byBpdCBjYW4gb25seSBjb250YWluIGEgc2lnbmF0dXJlIG9mIHRoZSBvbGQgRUtNLg0KVHJ1ZSwg YnV0IGl0IGRvZXMgbm90IG1hdHRlciBiZWNhdXNlIHRoZSBjbGllbnQgaXMgdW5hdXRoZW50aWNh dGVkIGluIHRoaXMgVExTIHNlc3Npb24sIHNvIHRoZSBzZXJ2ZXIgaW5pdGlhdGVzIHJlbmVnb3Rp YXRpb24uDQoNClRoZSBjbGllbnQgaXMgc3RpbGwgZ29pbmcgdG8gc2VuZCBhIFNlYy1Ub2tlbi1C aW5kaW5nIGhlYWRlciBpbiB0aGF0IHJlcXVlc3QgYmVmb3JlIHRoZSByZW5lZ28uIElzIHRoZSBz ZXJ2ZXIgY29tcGxldGVseSBpZ25vcmluZyB0aGUgY29va2llcyAoYW5kIHRoZSBzZWMtdG9rZW4t YmluZGluZyBoZWFkZXIpIGluIHRoZSByZXF1ZXN0IHByZS1yZW5lZ28/IFVubGVzcyB0aGUgc3Bl YyBpcyBnb2luZyB0byBhZGQgdGhpcyByZXN0cmljdGlvbiwgSSBzdGlsbCB0aGluayBpdCBzaG91 bGQgYmUgY29uc2lkZXJlZC4NCg0KDQo+ICBUaGUgc2VydmVyJ3MgcmVzcG9uc2UgaXMgYWZ0ZXIg dGhlIHJlbmVnb3RpYXRpb24gaGFuZHNoYWtlLiBJcyB0aGUgc2VydmVyIGdvaW5nIHRvIHRyeSB0 byB1c2UgdGhlIG9sZCBFS00gb3IgdGhlIG5ldyBFS00gd2hlbiBwcm9jZXNzaW5nIHRoZSBjbGll bnQncyByZXF1ZXN0Pw0KVEIgaXMgbm90IGVzdGFibGlzaGVkIHVudGlsIHRoZSBjbGllbnQgc2Vu ZHMgdGhlIFRCIG1lc3NhZ2UgaW4gdGhlIG5ldyBUTFMgc2Vzc2lvbiBhbmQgdGhlIHNlcnZlciB2 YWxpZGF0ZXMgaXQuIFNvIHRoZSBzZXJ2ZXIgd2lsbCB1c2UgdGhlIGN1cnJlbnQgRUtNIGF0IHRo ZSB0aW1lIG9mIFRCIG1lc3NhZ2UgdmFsaWRhdGlvbiwgaS5lLiB0aGUgbmV3IG9uZS4NCg0KSSdt IGltYWdpbmluZyB0aGlzIGZsb3c6DQoxLiBDbGllbnQgc2VuZHMgaHR0cCByZXENCjIuIFNlcnZl ciBhc2tzIGZvciByZW5lZ28NCjMuIENsaWVudCBhbmQgc2VydmVyIGRvIHJlbmVnbyBoYW5kc2hh a2UNCjQuIFNlcnZlciBzZW5kcyBodHRwIHJlc3BvbnNlICh0byByZXEgaW4gIzEpDQoNCkknbSBh c3N1bWluZyB5b3UncmUgbm90IHNheWluZyB0aGF0IGluIHN0ZXAgNCwgdGhlIHNlcnZlciBpcyB1 c2luZyB0aGUgbmV3IEVLTSB0byB2YWxpZGF0ZSB0aGUgVEIgaW4gcmVxdWVzdCAxPw0KDQpJZiB0 aGVyZSBhcmUgYW55IG90aGVyIGludGVybGVhdmluZ3Mgb2YgdGhlIHJlbmVnb3RpYXRpb24gaGFu ZHNoYWtlIHdpdGggYXBwbGljYXRpb24gZGF0YSB0aGF0IGFyZSBwb3NzaWJsZSwgeW91IHNob3Vs ZCBjb25zaWRlciBob3cgVEIgd2lsbCB3b3JrIGluIHRob3NlIGNhc2VzLCBvciBmb3JiaWQgdGhv c2UgY2FzZXMuDQoNCkknbSBjdXJpb3VzIGhvdyBhbGwgb2YgdGhlIHVzZSBjYXNlcyBvZiByZW5l Z28gd2l0aCBJRS9JSVMgd29yayB3aXRoIEhUVFAvMiAod2hpY2ggZm9yYmlkcyByZW5lZ28pLiBD YW4gd2UgZG8gdGhlIHNhbWUgdGhpbmcgZm9yIFRva2VuIEJpbmRpbmc/DQoNCg== --_000_CY1PR03MB2155C923F0BCAEF1E13DD8F08C1C0CY1PR03MB2155namp_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubTI1NzYwNzIzNDM5MDc5MDIyODBtc29saXN0cGFyYWdy YXBoLCBsaS5tMjU3NjA3MjM0MzkwNzkwMjI4MG1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tMjU3NjA3 MjM0MzkwNzkwMjI4MG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV8yNTc2MDcy MzQzOTA3OTAyMjgwbXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9z ZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNjA3MDUzOTI7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02ODU4Nzk3OTYgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSB0aGluaywgYmFzZWQgb24gdGhlIGN1 cnJlbnQgc3BlY3MsIHRoZSBmbG93IHdvdWxkIGxvb2sgbGlrZSB0aGlzOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkNsaWVudCBzZW5kcyBodHRwIHJlcXVlc3RzIHdpdGggVEIgbWVzc2FnZTs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4y LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TZXJ2ZXIgdmFsaWRhdGVzIFRCIHVzaW5nIHRoZSBj dXJyZW50IEVLTSAoQSksIFRCIGVzdGFibGlzaGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlNlcnZlciBwcm9jZXNzZXMgSFRUUCByZXF1ZXN0LCB0cmlnZ2VycyByZW5lZ290aWF0aW9uOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQu PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlbmVnb3RpYXRpb24gaGFuZHNoYWtlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjUuPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlNlcnZlciBzZW5kcyBodHRwIHJlc3BvbnNlICh1bmJvdW5kLCBh cyBUQiBpcyBub3QgZXN0YWJsaXNoZWQgaW4gdGhpcyBUTFMgc2Vzc2lvbiB1bnRpbCB0aGUgY2xp ZW50IHNlbmRzIGEgbmV3IFRCIG1lc3NhZ2UpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTmljayBIYXJwZXIgW21haWx0bzpuaGFycGVyQGdvb2ds ZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgOCwgMjAxNiA1OjIwIFBN PGJyPg0KPGI+VG86PC9iPiBBbmRyZWkgUG9wb3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3NvZnQu Y29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29u QGdtYWlsLmNvbSZndDs7IHVuYmVhcmFibGVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtVbmJlYXJhYmxlXSBSZW5lZ290aWF0aW9uIGluZm8gZXh0ZW5zaW9uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEF1ZyA4LCAy MDE2IGF0IDU6MDMgUE0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Q b3BvdkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92QG1pY3Jvc29m dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJtMjU3NjA3MjM0MzkwNzkwMjI4MG1zb2xpc3RwYXJhZ3JhcGgiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6Ny4wcHQiPiZuYnNwOw0KPC9zcGFuPldoeSBub3QgcmVxdWlyZSB0aGF0IFRCIHBh cmFtZXRlcnMgbXVzdCBiZSB0aGUgc2FtZT8gVGhpcyB3b3VsZCBzaW1wbGlmeSBpbXBsZW1lbnRh dGlvbnMgaW5zb2ZhciBhcyB0aGUgVEIga2V5IHdvdWxkIHJlbWFpbiB0aGUgc2FtZSBmb3IgdGhl IGNsaWVudC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5PbmNlIHRoZSBUTFMgaGFuZHNoYWtlIGlzIGNvbXBsZXRlLCBhIGNsaWVu dCByZWNlaXZlcyB0aGUgbmVnb3RpYXRlZCBUQiBwYXJhbWV0ZXJzLCByZXRyaWV2ZXMgdGhlIGFw cHJvcHJpYXRlIFRCDQoga2V5LCBhbmQgZ2VuZXJhdGVzIHRoZSBUQiBtZXNzYWdlLiBBZGRpbmcg YSB2ZXJpZmljYXRpb24gc3RlcCB0aGF0IHJlcXVpcmVzIHRoZSBjbGllbnQgdG8gZGlzdGluZ3Vp c2ggcmVuZWdvdGlhdGlvbnMgYW5kIHJlbWVtYmVyIHByZXZpb3VzIFRCIHNldHRpbmdzIGRvZXMg bm90IGxvb2sgbGlrZSBhIHNpbXBsaWZpY2F0aW9uIHRvIG1lLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTI1NzYwNzIzNDM5MDc5MDIyODBtc29saXN0cGFy YWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGlu Z3MiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOw0KPC9zcGFu PkluIHRoaXMgY2FzZSwgdGhlIGNsaWVudCdzIHJlcXVlc3Qgd2FzIHNlbnQgYmVmb3JlIHRoZSBy ZW5lZ290aWF0aW9uIGhhbmRzaGFrZSwgc28gaXQgY2FuIG9ubHkgY29udGFpbiBhIHNpZ25hdHVy ZSBvZiB0aGUgb2xkIEVLTS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5UcnVlLCBidXQgaXQgZG9lcyBub3QgbWF0dGVyIGJlY2F1c2UgdGhl IGNsaWVudCBpcyB1bmF1dGhlbnRpY2F0ZWQgaW4gdGhpcyBUTFMgc2Vzc2lvbiwgc28gdGhlIHNl cnZlciBpbml0aWF0ZXMgcmVuZWdvdGlhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIGNsaWVudCBpcyBzdGlsbCBnb2luZyB0byBzZW5kIGEgU2VjLVRva2VuLUJpbmRpbmcgaGVh ZGVyIGluIHRoYXQgcmVxdWVzdCBiZWZvcmUgdGhlIHJlbmVnby4gSXMgdGhlIHNlcnZlciBjb21w bGV0ZWx5IGlnbm9yaW5nIHRoZSBjb29raWVzIChhbmQgdGhlIHNlYy10b2tlbi1iaW5kaW5nIGhl YWRlcikgaW4gdGhlIHJlcXVlc3QgcHJlLXJlbmVnbz8gVW5sZXNzIHRoZSBzcGVjIGlzIGdvaW5n IHRvIGFkZA0KIHRoaXMgcmVzdHJpY3Rpb24sIEkgc3RpbGwgdGhpbmsgaXQgc2hvdWxkIGJlIGNv bnNpZGVyZWQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTI1NzYwNzIzNDM5MDc5MDIyODBtc29s aXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpX aW5nZGluZ3MiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOw0K PC9zcGFuPlRoZSBzZXJ2ZXIncyByZXNwb25zZSBpcyBhZnRlciB0aGUgcmVuZWdvdGlhdGlvbiBo YW5kc2hha2UuIElzIHRoZSBzZXJ2ZXIgZ29pbmcgdG8gdHJ5IHRvIHVzZSB0aGUgb2xkIEVLTSBv ciB0aGUgbmV3IEVLTSB3aGVuIHByb2Nlc3NpbmcgdGhlIGNsaWVudCdzIHJlcXVlc3Q/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VEIgaXMg bm90IGVzdGFibGlzaGVkIHVudGlsIHRoZSBjbGllbnQgc2VuZHMgdGhlIFRCIG1lc3NhZ2UgaW4g dGhlIG5ldyBUTFMgc2Vzc2lvbiBhbmQgdGhlIHNlcnZlciB2YWxpZGF0ZXMgaXQuIFNvDQogdGhl IHNlcnZlciB3aWxsIHVzZSB0aGUgY3VycmVudCBFS00gYXQgdGhlIHRpbWUgb2YgVEIgbWVzc2Fn ZSB2YWxpZGF0aW9uLCBpLmUuIHRoZSBuZXcgb25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JJ20gaW1hZ2luaW5nIHRoaXMgZmxvdzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuIENsaWVudCBzZW5kcyBodHRwIHJlcTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gU2VydmVyIGFza3Mg Zm9yIHJlbmVnbzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+My4gQ2xpZW50IGFuZCBzZXJ2ZXIgZG8gcmVuZWdvIGhhbmRzaGFrZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+NC4gU2VydmVyIHNlbmRz IGh0dHAgcmVzcG9uc2UgKHRvIHJlcSBpbiAjMSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIGFzc3VtaW5nIHlvdSdyZSBub3Qgc2F5aW5n IHRoYXQgaW4gc3RlcCA0LCB0aGUgc2VydmVyIGlzIHVzaW5nIHRoZSBuZXcgRUtNIHRvIHZhbGlk YXRlIHRoZSBUQiBpbiByZXF1ZXN0IDE/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZXJlIGFyZSBhbnkgb3RoZXIgaW50ZXJsZWF2aW5n cyBvZiB0aGUgcmVuZWdvdGlhdGlvbiBoYW5kc2hha2Ugd2l0aCBhcHBsaWNhdGlvbiBkYXRhIHRo YXQgYXJlIHBvc3NpYmxlLCB5b3Ugc2hvdWxkIGNvbnNpZGVyIGhvdyBUQiB3aWxsIHdvcmsgaW4g dGhvc2UgY2FzZXMsIG9yIGZvcmJpZCB0aG9zZSBjYXNlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIGN1cmlvdXMgaG93IGFsbCBvZiB0 aGUgdXNlIGNhc2VzIG9mIHJlbmVnbyB3aXRoIElFL0lJUyB3b3JrIHdpdGggSFRUUC8yICh3aGlj aCBmb3JiaWRzIHJlbmVnbykuIENhbiB3ZSBkbyB0aGUgc2FtZSB0aGluZyBmb3IgVG9rZW4gQmlu ZGluZz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR03MB2155C923F0BCAEF1E13DD8F08C1C0CY1PR03MB2155namp_-- From nobody Tue Aug 9 10:36:06 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 580C912B042 for ; Tue, 9 Aug 2016 10:36:05 -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 l7AFaC8WHgFL for ; Tue, 9 Aug 2016 10:36:04 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (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 2382612B01B for ; Tue, 9 Aug 2016 10:36:04 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id b62so18270380iod.3 for ; Tue, 09 Aug 2016 10:36:04 -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=mwYbU0e2xFl9cqv5WQGTb8SQaRK3w114DbXzhEoEwnY=; b=np9M68/xNi2CJFHWZrB586rsICuD7m9eA02aQrxrzAyGOdmnTyH19Pf9e+5Vko0Stn RmgPOncB3e1DTxsx6woyFlpC/2FCmiYMWF3hgYa571mkMyOhO03630ddkIvSVeAsRwXm qwzphxXPVO3VJvexcYfszcVdPZy8HPBu5FA/0= 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=mwYbU0e2xFl9cqv5WQGTb8SQaRK3w114DbXzhEoEwnY=; b=mLKlj7iItFNSyDeO/bNDrp5cIYO8vGy2kuTb//p2lkGNxZmqFqivXjb0QUd3dNptiJ 2OSlO1YL4ikq1XsW9byWWZTiKqVTLMdr8WCG8VDDuNSgby/6PA+eZP73hkaaYIzN4+XA Tuba2fUZ5ZWMnXbc7gJEYmrmtgFKf4mJlXY1b3FVDx7i3vy4E+s9G+j1N+cA3y/xurpj OY/cn7/qxEE+HbGTpSplkxYAxuqj3aOV/N6hx2YK/Ne5hGE6g/+/pKK0eIKcEiE0OXgi cHVYJmw8OC+GyGTGwYJEcCVydo47XcRJ8eqgqgyKEmj0DnarVKOVJhplNtcpzg5wAivr 2Pnw== X-Gm-Message-State: AEkoouuhWCZ6N9kFKXlpW310sSo5JbeVROi0S44gFmAUSHndK++hWuaQoEAlVfcPZRrnyTsJLLMHSWo8sgfPCJPm X-Received: by 10.107.50.19 with SMTP id y19mr258484ioy.174.1470764163359; Tue, 09 Aug 2016 10:36:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Tue, 9 Aug 2016 10:35:32 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Tue, 9 Aug 2016 11:35:32 -0600 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=001a114469c481849c0539a6f755 Archived-At: Cc: "unbearable@ietf.org" , Martin Thomson , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 09 Aug 2016 17:36:05 -0000 --001a114469c481849c0539a6f755 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 8, 2016 at 11:52 AM, Nick Harper wrote: > > Right now, a client could send version 2 in its extension, the server > respond with version 1, and end up with token binding not being negotiated > because the client doesn't support version 1 (but the server not knowing > that until it fails to receive a TokenBindingMessage). > I can't put my finger on exactly what issues might arise from this but it does seem potentially problematic that unless the TB versions match exactly in the TLS extensions, the sever can't know if the client will be doing token binding until it receives (or doesn't) a TokenBindingMessage at the application layer. --001a114469c481849c0539a6f755 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Aug 8, 2016 at 11:52 AM, Nick Harper <nharper@google.com>= wrote:
Right now, a client could send version 2 in its extension, the serve= r respond with version 1, and end up with token binding not being negotiate= d because the client doesn't support version 1 (but the server not know= ing that until it fails to receive a TokenBindingMessage).

I can't put my finger on exactly what issue= s might arise from this but it does seem potentially problematic that unles= s the TB versions match exactly in the TLS extensions, the sever can't = know if the client will be doing token binding until it receives (or doesn&= #39;t) a TokenBindingMessage at the application layer.
=C2= =A0
--001a114469c481849c0539a6f755-- From nobody Tue Aug 9 10:38:27 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 1553C12D0EA for ; Tue, 9 Aug 2016 10:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, 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 RJPkdiOOCtY1 for ; Tue, 9 Aug 2016 10:38:25 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 071A612D0E7 for ; Tue, 9 Aug 2016 10:38:25 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id 97so31208292uav.3 for ; Tue, 09 Aug 2016 10:38:24 -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=2oZDaYC7JtdZJpMpW69bJRKwVgyKqxWg312leWGgWTM=; b=Qq1c+EEd11c0Gh0685XYC0MuzlYXl/kpBkFFyHSQqBPMx5y0jtsGtoHVnr4I4otx3R UlRITdYqN+YMijJAXW8+YLDdLat6Cm0DfNdNN4Yh25zHdoP5VDyXHDNpGqAEhQ82tdoq uZ4lbT/Gg2UIUUdgXZPEbBjPZFZAxxlwo2Hg9pQAB12m6g4S9SBpMVED2Nvefh35J2sA As01d6uyMGbi72I6A0NSoVmdTQsot+u+FHZ8OHzEmAeGggI+YbTQcZFjduIXB32Ie4rz /wufhe0jt9e+gpQzRK3FjU9STS8shADh3/cIA5gT64M30/voN9FJ9e9nN/yH6c1v9uc3 w2jA== 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=2oZDaYC7JtdZJpMpW69bJRKwVgyKqxWg312leWGgWTM=; b=T5MuZKH7LzK6fsRDILauvY52iDtdh43689xH5za+MYIu9a8Gsi+eJeYg7vn7tUztUe l/DBRQ6Tdob5p6fJmIQpO7YPl1x5/dFvcRHb+sc/+5l4O7PblwQ2roeVTPzE7KC+l7dO J9ABJgOUczWqqQiwnybAHaeaMlBgtl/OhjGwzQJYpmYfu8PgkgOntSn58mX7jfRp3pNl QOZxjtkICHESWmqiijzUMmtJe5/BHG8r5wm8w3qDGotaD9BMcgSKIkHTky1modbghbeM lSEnl68zAVCtDevt1haDsfGfaA0NM8bgH1xfk3F1YVIHyL4XtSa4ggjpsFxH8dKCGF8b eMiQ== X-Gm-Message-State: AEkoouuZBx4kBbMdiIbRuZ7E4N4QZtp/RVdBAvQhSrra+9MSr/MA9l1jDyFd7O7Rxk5MDahMhk6GQekexWqjI1mH X-Received: by 10.31.107.89 with SMTP id g86mr12632278vkc.52.1470764303967; Tue, 09 Aug 2016 10:38:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.209 with HTTP; Tue, 9 Aug 2016 10:38:03 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Tue, 9 Aug 2016 10:38:03 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a11478678e351d80539a6ff88 Archived-At: Cc: "unbearable@ietf.org" , Martin Thomson , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 09 Aug 2016 17:38:27 -0000 --001a11478678e351d80539a6ff88 Content-Type: text/plain; charset=UTF-8 If we leave it as is, the version field is likely to ossify (like it has with every version of SSL and TLS), so there's a decent chance that for some implementations it won't work (a version intolerant server would reject a client's v2 token binding negotiation, instead of falling back to v1; separate extensions don't have this problem). This version field also assumes that the only thing (apart from version number) that needs to be negotiated is the key parameters. If a token binding v2 is added, will it want to negotiate something else (and then need a new TLS extension)? I'm wondering what future changes to token binding might look like that require bumping the protocol version number. I know that key attestation is something that could potentially be added. My understanding is that this would go in an Extension in the TokenBinding struct, and wouldn't need to bump the protocol version number. For the protocol version number to be changed, something would have to change the TokenBindingMessage format (or the format of one of its fields). There's already a decent amount of extensibility there in terms of key parameters, token binding types, and extensions. Changing the signature to be of something besides the EKM value is the only thing that comes to my mind that would fit in this format and require changing the version number. If more substantial changes are made to the TokenBindingMessage, I imagine that changes will need to be made to negotiation to support those changes. In that case, the version field in the current negotiation extension is useless (a new extension will be needed for negotiating new things). I think the likelihood that a change will be large enough to warrant a change in protocol version number, yet small enough that negotiation doesn't change, is fairly small. That, and the potential ossification of the version field seem like good reasons to remove the version field and use a new TLS extension number when the time comes. On Tue, Aug 9, 2016 at 9:49 AM, Andrei Popov wrote: > The drawbacks of negotiating each TB version with a custom TLS extension: > 1. More bytes in the ClientHello; > 2. More IETF process when adding new TB versions; > 3. TLS update for each TB version, or the need to add "generic TLS > extension" support, putting the caller of the TLS stack in charge of > handling (a subset of) TLS extensions. > > The potential benefits: > a) Extensibility is concentrated in one place? > b) The server has a list of all client-supported TB versions in the > ClientHello (this can be achieved within one TLS extension, if desired). > > To me, these drawbacks outweigh the benefits, but I could live with either > design. > > Cheers, > > Andrei > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Monday, August 8, 2016 7:35 PM > To: Andrei Popov > Cc: Nick Harper ; Bill Cox ; > unbearable@ietf.org > Subject: Re: [Unbearable] TLS extension: version field > > On 9 August 2016 at 12:27, Andrei Popov > wrote: > > Also, the proposal requires that a TLS stack be updated for every new TB > version, which is a real drawback. With the current TB negotiation > extension, we can add new TB versions without changing TLS. > > That's a problem that can be solved with software, if you care about that > sort of thing: > tls.addGenericClientHelloExtension(id, blob); > tls.addGenericServerHelloExtensionHandler(id, (blob) => {...}); > blob = tls.getGenericServerHelloExtension(id); > --001a11478678e351d80539a6ff88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If we leave it as is, the version field is likely to ossif= y (like it has with every version of SSL and TLS), so there's a decent = chance that for some implementations it won't work (a version intoleran= t server would reject a client's v2 token binding negotiation, instead = of falling back to v1; separate extensions don't have this problem).This version field also assumes that the only thing (apart from version n= umber) that needs to be negotiated is the key parameters. If a token bindin= g v2 is added, will it want to negotiate something else (and then need a ne= w TLS extension)?

I'm wondering what future ch= anges to token binding might look like that require bumping the protocol ve= rsion number. I know that key attestation is something that could potential= ly be added. My understanding is that this would go in an Extension in the = TokenBinding struct, and wouldn't need to bump the protocol version num= ber. For the protocol version number to be changed, something would have to= change the TokenBindingMessage format (or the format of one of its fields)= . There's already a decent amount of extensibility there in terms of ke= y parameters, token binding types, and extensions. Changing the signature t= o be of something besides the EKM value is the only thing that comes to my = mind that would fit in this format and require changing the version number.=

If more substantial changes are made to the Token= BindingMessage, I imagine that changes will need to be made to negotiation = to support those changes. In that case, the version field in the current ne= gotiation extension is useless (a new extension will be needed for negotiat= ing new things).

I think the likelihood that a cha= nge will be large enough to warrant a change in protocol version number, ye= t small enough that negotiation doesn't change, is fairly small. That, = and the potential ossification of the version field seem like good reasons = to remove the version field and use a new TLS extension number when the tim= e comes.

On Tue, Aug 9, 2016 at 9:49 AM, Andrei Popov <Andrei.Popov@mic= rosoft.com> wrote:
The draw= backs of negotiating each TB version with a custom TLS extension:
1. More bytes in the ClientHello;
2. More IETF process when adding new TB versions;
3. TLS update for each TB version, or the need to add "generic TLS ext= ension" support, putting the caller of the TLS stack in charge of hand= ling (a subset of) TLS extensions.

The potential benefits:
a) Extensibility is concentrated in one place?
b) The server has a list of all client-supported TB versions in the ClientH= ello (this can be achieved within one TLS extension, if desired).

To me, these drawbacks outweigh the benefits, but I could live with either = design.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:ma= rtin.thomson@gmail.com]
Sent: Monday, August 8, 2016 7:35 PM
To: Andrei Popov <Andrei.P= opov@microsoft.com>
Cc: Nick Harper <nharper@google.co= m>; Bill Cox <waywardge= ek@google.com>; unbearable@ie= tf.org
Subject: Re: [Unbearable] TLS extension: version field

On 9 August 2016 at 12:27, A= ndrei Popov <Andrei.Popov@= microsoft.com> wrote:
> Also, the proposal requires that a TLS stack be updated for every new = TB version, which is a real drawback. With the current TB negotiation exten= sion, we can add new TB versions without changing TLS.

That's a problem that can be solved with software, if you care about th= at sort of thing:
=C2=A0 tls.addGenericClientHelloExtension(id, blob);
=C2=A0 tls.addGenericServerHelloExtensionHandler(id, (blob) =3D&g= t; {...});
=C2=A0 blob =3D tls.getGenericServerHelloExtension(id);

--001a11478678e351d80539a6ff88-- From nobody Tue Aug 9 11:44: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 2C67912D50C for ; Tue, 9 Aug 2016 11:44:17 -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 t3I74UpS3nhn for ; Tue, 9 Aug 2016 11:44:15 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 D61DF12D0F7 for ; Tue, 9 Aug 2016 11:44:14 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id m101so20054504ioi.2 for ; Tue, 09 Aug 2016 11:44:14 -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=/XeOJe8uMrSpQOmeLWGIDPpK9K1V/PGJ9/GOaZSpt7E=; b=pMbg1p9pfEg3P1+QgpYCr0jub3K39wnbuxptcu1+tX4ea5B+SPzfqmBoRQKchKXoI2 nTe/Xrg9FyiDAYc+0Da4vfVnw3/KIGhS90inft38nX5SkDmAfT//PuE7YBCoYvma8oqk loRJP6tH6bJz/WFUhaBe1xYMbaFZzAuAiieEc= 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=/XeOJe8uMrSpQOmeLWGIDPpK9K1V/PGJ9/GOaZSpt7E=; b=J9TuVugJPynNMdpNy5z5gpvPQv3QlF9TpM8C+6oWVN749E26TLcbAxNGXCXRrmpjNg kju40MMQCE11gZz14KI/VVe4JWR2yIqEVNR13IrcYW2Zf20tTAdeaeDdclM1gWo9i3MN N2KpbS3J2c+6mj9OE53sw5QhN8OWdPxvDHHvYpgnedFQ9VLP83AWuTUwf9YcXDh+KIcg SGCLFkMFvNP/LaIjlEmPGseArkuJHrXCR5RYKT+wO7TDTajwP1rVQlivvAl6PwTk6H/a 9WMEmR5veaPKF6PxYsxSl9FBkRu4OzRbtijS7ZfWQt7Z5G3d81FL986aC5EHg7sv/2he hC9A== X-Gm-Message-State: AEkoousx8+WFZ6F9iMNLUio4/S1KmGEcUdqzveioFSvYiW3O7x6bo80BYnVTMoLPEFCPn3Do09RooxqP3gnIiXG/ X-Received: by 10.107.8.94 with SMTP id 91mr627755ioi.86.1470768254090; Tue, 09 Aug 2016 11:44:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Tue, 9 Aug 2016 11:43:43 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Tue, 9 Aug 2016 12:43:43 -0600 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=001a113f3a885517e30539a7eb87 Archived-At: Cc: Andrei Popov , Martin Thomson , "unbearable@ietf.org" , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 09 Aug 2016 18:44:17 -0000 --001a113f3a885517e30539a7eb87 Content-Type: text/plain; charset=UTF-8 I tend to agree with Martin and Nick's perspective here. Key parameters, token binding types, and extensions already provide for a fair amount of extensibility. One can't reliably predict the future but it seems more likely than not that the first version of TB (which doesn't even exist yet) could well have a nice long run before a new version is needed. A new extension can be done if and when that time comes and working with existing TLS extensions is much more likely to work in practice than a version mechanism within the TB that wont really be exercised because there's only one version. In meantime the client and server hello can use a few less bytes (no version) in the ordinary case of negotiating the only version of TB that exists (er, will exist soon). On Tue, Aug 9, 2016 at 11:38 AM, Nick Harper wrote: > If we leave it as is, the version field is likely to ossify (like it has > with every version of SSL and TLS), so there's a decent chance that for > some implementations it won't work (a version intolerant server would > reject a client's v2 token binding negotiation, instead of falling back to > v1; separate extensions don't have this problem). > This version field also assumes that the only thing (apart from version > number) that needs to be negotiated is the key parameters. If a token > binding v2 is added, will it want to negotiate something else (and then > need a new TLS extension)? > > I'm wondering what future changes to token binding might look like that > require bumping the protocol version number. I know that key attestation is > something that could potentially be added. My understanding is that this > would go in an Extension in the TokenBinding struct, and wouldn't need to > bump the protocol version number. For the protocol version number to be > changed, something would have to change the TokenBindingMessage format (or > the format of one of its fields). There's already a decent amount of > extensibility there in terms of key parameters, token binding types, and > extensions. Changing the signature to be of something besides the EKM value > is the only thing that comes to my mind that would fit in this format and > require changing the version number. > > If more substantial changes are made to the TokenBindingMessage, I imagine > that changes will need to be made to negotiation to support those changes. > In that case, the version field in the current negotiation extension is > useless (a new extension will be needed for negotiating new things). > > I think the likelihood that a change will be large enough to warrant a > change in protocol version number, yet small enough that negotiation > doesn't change, is fairly small. That, and the potential ossification of > the version field seem like good reasons to remove the version field and > use a new TLS extension number when the time comes. > > On Tue, Aug 9, 2016 at 9:49 AM, Andrei Popov > wrote: > >> The drawbacks of negotiating each TB version with a custom TLS extension: >> 1. More bytes in the ClientHello; >> 2. More IETF process when adding new TB versions; >> 3. TLS update for each TB version, or the need to add "generic TLS >> extension" support, putting the caller of the TLS stack in charge of >> handling (a subset of) TLS extensions. >> >> The potential benefits: >> a) Extensibility is concentrated in one place? >> b) The server has a list of all client-supported TB versions in the >> ClientHello (this can be achieved within one TLS extension, if desired). >> >> To me, these drawbacks outweigh the benefits, but I could live with >> either design. >> >> Cheers, >> >> Andrei >> >> -----Original Message----- >> From: Martin Thomson [mailto:martin.thomson@gmail.com] >> Sent: Monday, August 8, 2016 7:35 PM >> To: Andrei Popov >> Cc: Nick Harper ; Bill Cox ; >> unbearable@ietf.org >> Subject: Re: [Unbearable] TLS extension: version field >> >> On 9 August 2016 at 12:27, Andrei Popov >> wrote: >> > Also, the proposal requires that a TLS stack be updated for every new >> TB version, which is a real drawback. With the current TB negotiation >> extension, we can add new TB versions without changing TLS. >> >> That's a problem that can be solved with software, if you care about that >> sort of thing: >> tls.addGenericClientHelloExtension(id, blob); >> tls.addGenericServerHelloExtensionHandler(id, (blob) => {...}); >> blob = tls.getGenericServerHelloExtension(id); >> > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a113f3a885517e30539a7eb87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I tend to agree with Martin and Nick's perspective her= e. Key parameters, token binding types, and extensions already provide for = a fair amount of extensibility. One can't reliably predict the future b= ut it seems more likely than not that the first version of TB (which doesn&= #39;t even exist yet) could well have a nice long run before a new version = is needed. A new extension can be done if and when that time comes and work= ing with existing TLS extensions is much more likely to work in practice th= an a version mechanism within the TB that wont really be exercised because = there's only one version. In meantime the client and server hello can u= se a few less bytes (no version) in the ordinary case of negotiating the on= ly version of TB that exists (er, will exist soon).

=C2=A0

On Tue, Aug 9, 2= 016 at 11:38 AM, Nick Harper <nharper@google.com> wrote:
If we leave it as is, the = version field is likely to ossify (like it has with every version of SSL an= d TLS), so there's a decent chance that for some implementations it won= 't work (a version intolerant server would reject a client's v2 tok= en binding negotiation, instead of falling back to v1; separate extensions = don't have this problem).
This version field also assumes that the = only thing (apart from version number) that needs to be negotiated is the k= ey parameters. If a token binding v2 is added, will it want to negotiate so= mething else (and then need a new TLS extension)?

= I'm wondering what future changes to token binding might look like that= require bumping the protocol version number. I know that key attestation i= s something that could potentially be added. My understanding is that this = would go in an Extension in the TokenBinding struct, and wouldn't need = to bump the protocol version number. For the protocol version number to be = changed, something would have to change the TokenBindingMessage format (or = the format of one of its fields). There's already a decent amount of ex= tensibility there in terms of key parameters, token binding types, and exte= nsions. Changing the signature to be of something besides the EKM value is = the only thing that comes to my mind that would fit in this format and requ= ire changing the version number.

If more substanti= al changes are made to the TokenBindingMessage, I imagine that changes will= need to be made to negotiation to support those changes. In that case, the= version field in the current negotiation extension is useless (a new exten= sion will be needed for negotiating new things).

I= think the likelihood that a change will be large enough to warrant a chang= e in protocol version number, yet small enough that negotiation doesn't= change, is fairly small. That, and the potential ossification of the versi= on field seem like good reasons to remove the version field and use a new T= LS extension number when the time comes.
<= div class=3D"h5">

= On Tue, Aug 9, 2016 at 9:49 AM, Andrei Popov <Andrei.Popov@micro= soft.com> wrote:
The draw= backs of negotiating each TB version with a custom TLS extension:
1. More bytes in the ClientHello;
2. More IETF process when adding new TB versions;
3. TLS update for each TB version, or the need to add "generic TLS ext= ension" support, putting the caller of the TLS stack in charge of hand= ling (a subset of) TLS extensions.

The potential benefits:
a) Extensibility is concentrated in one place?
b) The server has a list of all client-supported TB versions in the ClientH= ello (this can be achieved within one TLS extension, if desired).

To me, these drawbacks outweigh the benefits, but I could live with either = design.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com]
Sent: Monday, August 8, 2016 7:35 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Nick Harper <nharper@google.com>; Bill Cox <waywardgeek@google.com>; unbearable@ietf.org
Subject: Re: [Unbearable] TLS extension: version field

On 9 August 2016 at 12:27, Andrei Popov <Andrei.Popov@microsoft.co= m> wrote:
> Also, the proposal requires that a TLS stack be updated for every new = TB version, which is a real drawback. With the current TB negotiation exten= sion, we can add new TB versions without changing TLS.

That's a problem that can be solved with software, if you care about th= at sort of thing:
=C2=A0 tls.addGenericClientHelloExtension(id, blob);
=C2=A0 tls.addGenericServerHelloExtensionHandler(id, (blob) =3D> {.= ..});
=C2=A0 blob =3D tls.getGenericServerHelloExtension(id);


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


--001a113f3a885517e30539a7eb87-- From nobody Tue Aug 9 12:04: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 6426C12D090 for ; Tue, 9 Aug 2016 12:04:32 -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 Nlnf18qIzk74 for ; Tue, 9 Aug 2016 12:04:31 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 5EF8412D50C for ; Tue, 9 Aug 2016 12:04:29 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id m101so20583279ioi.2 for ; Tue, 09 Aug 2016 12:04:29 -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=3eieQj/cnWxyjIES5HsqzCquh2uE9PvEwXIaD+g0qSM=; b=kf0npy5Hic3L78eol0Q9CbcRIude/+UVSy3TSgXUx2XfiZCzpCkseXdt8v28tF+afL bRL7Nw3OKIYeCej5IMgpPaiCn0CJ+/KOx6O+1VOlPRFJbDaRxK4eydJftrFUgU2szc/4 TdCouSuTauWZ4NT/n5UJGRRnctqV8XMuRyjgk= 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=3eieQj/cnWxyjIES5HsqzCquh2uE9PvEwXIaD+g0qSM=; b=O4USKjee5Y+8bjanLW5iGjGkiMr40VJsRAGiHgfg28rJEZLJxE5udqww0HK+j+tLFc JQk2bcNqrUOs7TBi5l+a/J/YM2/9E5WXQ9Ig5sWuzXWP6Xdiha/+8UuIT8dq0Qg90Ufv /6mCV/YOGxPm3c/mFgeXjHmhODh9cQOBzVIbdIeak9p2ZoH6ycNw4sw3c8zh98OI4F2D uTutNYHWuBU14RRQX1ostU7Ype3g4TCVpoLalbs+WsbklD5uniBaRHMmui4WFMFni2b6 sLYLJrTBE9VWQ8Sje27kidHoR8wvgtjYVvISwcW9g60gTuvw2K3LEz4BBSICs7pddNqS 2EAw== X-Gm-Message-State: AEkoouubmfjcT0auhIug8pfHuovSAUnyRcxcnzHDnWuNsD5QDrHIfbEsVroLMpX728HG+RBgzZYVsx6KPPCPUN2o X-Received: by 10.107.8.94 with SMTP id 91mr728557ioi.86.1470769468704; Tue, 09 Aug 2016 12:04:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Tue, 9 Aug 2016 12:03:58 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Tue, 9 Aug 2016 13:03:58 -0600 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113f3a88ba9b3c0539a83374 Archived-At: Cc: Andrei Popov , IETF Tokbind WG Subject: Re: [Unbearable] referred token binding and unknown key_parameters 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, 09 Aug 2016 19:04:32 -0000 --001a113f3a88ba9b3c0539a83374 Content-Type: text/plain; charset=UTF-8 With respect to #62, as mentioned in a comment, I don't think there's value in that extra byte. On Mon, Aug 8, 2016 at 5:10 PM, Martin Thomson wrote: > On 9 August 2016 at 02:09, Brian Campbell > wrote: > > Just a thought anyway. Don't know if that's better or worse or worth > doing > > for one byte. > > Note that I also opened #62, which suggests spending an extra byte. > > https://github.com/TokenBinding/Internet-Drafts/issues/62 > --001a113f3a88ba9b3c0539a83374 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
With respect to #62, as mentioned in a comment, I don'= t think there's value in that extra byte.

On Mon, Aug 8, 2016 at 5:10 PM, Mart= in Thomson <martin.thomson@gmail.com> wrote:
On 9 August 2016 at 02:09, Brian= Campbell <bcampbell@pingi= dentity.com> wrote:
> Just a thought anyway. Don't know if that's better or worse or= worth doing
> for one byte.

Note that I also opened #62, which suggests spending an extra byte.<= br>
https://github.com/TokenBinding/Inte= rnet-Drafts/issues/62

--001a113f3a88ba9b3c0539a83374-- From nobody Wed Aug 10 00:44: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 1CF5612D592 for ; Wed, 10 Aug 2016 00:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.947 X-Spam-Level: X-Spam-Status: No, score=-3.947 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.247, 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 0MKKatbL8R0M for ; Wed, 10 Aug 2016 00:44:24 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 2EFAE128B44 for ; Wed, 10 Aug 2016 00:44:24 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id f65so74277943wmi.0 for ; Wed, 10 Aug 2016 00:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=euLR4N00bEdw1pAfTvRcyAPFzttiUSo23WFGRITxuCU=; b=IxmsdOq//OTAxZqne7ZB8UdOsY+mGE90241B0m/Hf5dO8R7ZkdTjddpfX6UirnCbal ngpPF5q2wpPchbwekcaoEF0ct4AaKwf7RVf7HRlTUqAa1alAOyA9renjC6CeHLivdHaM p/InCYhjTf5HM2eqW2G7m1RsKohKfCwgpVQk1D15qu69rvzG9r10Bg/Mo++DWMMwYiXE fffM+goH/BsZDb5DLT9lvut5wdGMaQeHCgsIiVAdEJ9mS1H84PQZShaeGFK/BMnpqUOF UGrSOiGqyvicrH2a1D58jPwUIozG+s478KKFp5Awak1lkKfnq8AOMnYNUuIWm9TkGQxw Efiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=euLR4N00bEdw1pAfTvRcyAPFzttiUSo23WFGRITxuCU=; b=KUyNbg8nNfFnvnr+E29sp2Hezjss7ZqjpDZXBaqMgErdknyLtKpelohmj3MnuCEdEM JS0PFyeBpQiwLTHpFJ2T1a1BGDvnWKpg5KGICeBiPoCVznJ3JTkt/Tw8TL5t0QoecTtZ n4PTcC4I2PpVH/Yvj12/74xvj4KS1qTQjMGCvOEKjSUcb+S5tZHDanUhPYWNd+oy3Ly4 e6GWbh48ZNz1HuNxwJ2jr7JGpRD3xWn7k8VgLXE8v+qVkfpA6fneEWhcj+QWDs0JKiYh s/0KW0OkyXC4/TPsPqnO8KRz+J2IQEjoDAK7YSxK1QZ6Jcsu2HhKjvC12Tra8C96lgnP nSmQ== X-Gm-Message-State: AEkoousAq4elIC7YadlkBJtUrA1AXglP4PBlm0Sls+9CKPEJSEyX3dFsaUumesrJsLs2dEA5p5TJuLFJOzoK+KvX X-Received: by 10.194.82.67 with SMTP id g3mr2476066wjy.71.1470815062236; Wed, 10 Aug 2016 00:44:22 -0700 (PDT) MIME-Version: 1.0 References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> In-Reply-To: From: Dirk Balfanz Date: Wed, 10 Aug 2016 07:44:10 +0000 Message-ID: To: Martin Thomson , John Bradley Content-Type: multipart/alternative; boundary=047d7b86e92e5112d70539b2d148 Archived-At: Cc: Subodh Iyengar , Scott Cantor , IETF Tokbind WG , Brian Campbell , "Manger, James" , Nick Harper Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 10 Aug 2016 07:44:27 -0000 --047d7b86e92e5112d70539b2d148 Content-Type: text/plain; charset=UTF-8 Google sets an authentication cookie on *.google.com. We also set a variety of authentication-related cookies on more narrowly-defined domains, but it's that domain cookie that we channel-bind. Sometimes users arrive at, say, mail.google.com through a redirect from accounts.google.com (which mints the domain cookie) and in that case it's theoretically possible that they could arrive there with a referred token binding from accounts.google.com. So let's say a request comes into mail.google.com with provided token binding Kx, referred token binding Ky, and the cookie is bound to Ky. mail.google.com now would have to remember that Kx is also a valid token binding key for this cookie - presumably by mutating the cookie (or its associated session information on the server). Gmail can't write/mutate our authentication cookies - only our authentication infrastructure can do this. Not an insurmountable problem, but likely one that's big enough for gmail (and maps, and docs, etc.) to conclude that they shouldn't bother with channel binding. Then there are the cases in which users arrive at our destination services ( mail.google.com, maps.google.com, etc.) directly by typing the URL into their browser. In that case the service won't have the benefit of seeing the referred token binding, so the cookie will simply count as mismatched. Incurring the extra redirect in this case to accounts.google.com and back is again something that the various teams and services are not likely willing to pay. In conclusion, moving to an origin scope for token-binding keys would likely mean for a company like Google, which has big complicated old systems that are hard to change, that we couldn't in practice deploy it. Dirk. On Mon, Aug 8, 2016 at 7:14 PM Martin Thomson wrote: > On 9 August 2016 at 04:38, John Bradley wrote: > > Martin do you have some idea how a token bound cookie set by > x.example.com > > could be validated by y.example.com under a strict same origin policy. > > So x sets a cookie bound to key Kx. Only x can validate that key > because the client doesn't use that key with other parties. That > means that y needs to get the client to prove possession of (the > private key for) Kx. > > With the help of x, it can easily do this with a referred token > binding. y makes the client make a request to x, and x redirects back > to y with the > > header field set. Then y is able to acquire proof from the client > that it owns Kx. > > This only requires that y support the same signature schemes as x, and > that y has help from x. > > Sure, this is inconvenient (it's round trips), but this establishes > possible. And, once you have this proof, you might be able to store > the mapping between Kx and Ky. > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > --047d7b86e92e5112d70539b2d148 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Google sets an authentication cookie on *.google.com. We also set a variety of authentication-relat= ed cookies on more narrowly-defined domains, but it's that domain cooki= e that we channel-bind.

Sometimes users arrive at, say, = mail.google.com through a redirect f= rom accounts.google.com (which m= ints the domain cookie) and in that case it's theoretically possible th= at they could arrive there with a referred token binding from accounts.google.com. So let's say a reque= st comes into mail.google.com with p= rovided token binding Kx, referred token binding Ky, and the cookie is boun= d to Ky. mail.google.com now would h= ave to remember that Kx is also a valid token binding key for this cookie -= presumably by mutating the cookie (or its associated session information o= n the server). Gmail can't write/mutate our authentication cookies - on= ly our authentication infrastructure can do this. Not an insurmountable pro= blem, but likely one that's big enough for gmail (and maps, and docs, e= tc.) to conclude that they shouldn't bother with channel binding.
=

Then there are the cases in which users arrive at our d= estination services (mail.google.com= , maps.google.com, etc.) directly by= typing the URL into their browser. In that case the service won't have= the benefit of seeing the referred token binding, so the cookie will simpl= y count as mismatched. Incurring the extra redirect in this case to accounts.google.com and back is again s= omething that the various teams and services are not likely willing to pay.=

In conclusion, moving to an origin scope for toke= n-binding keys would likely mean for a company like Google, which has big c= omplicated old systems that are hard to change, that we couldn't in pra= ctice deploy it.

Dirk.

<= br>
On Mon, Aug 8, 2016 at 7:14 = PM Martin Thomson <martin.th= omson@gmail.com> wrote:
On 9= August 2016 at 04:38, John Bradley <ve7jtb@ve7jtb.com> wrote:
> Martin do you have some idea how a token bound cookie set by x.example.co= m
> could be validated by y.example.com under a strict same origin policy.<= br>
So x sets a cookie bound to key Kx.=C2=A0 Only x can validate that key
because the client doesn't use that key with other parties.=C2=A0 That<= br> means that y needs to get the client to prove possession of (the
private key for) Kx.

With the help of x, it can easily do this with a referred token
binding.=C2=A0 y makes the client make a request to x, and x redirects back=
to y with the <really-long-header-field-name-that-triggers-referred-toke= n-binding>
header field set.=C2=A0 Then y is able to acquire proof from the client
that it owns Kx.

This only requires that y support the same signature schemes as x, and
that y has help from x.

Sure, this is inconvenient (it's round trips), but this establishes
possible.=C2=A0 And, once you have this proof, you might be able to store the mapping between Kx and Ky.

_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearable=
--047d7b86e92e5112d70539b2d148-- From nobody Wed Aug 10 10:37:14 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 E88B612D82B for ; Wed, 10 Aug 2016 10:37:12 -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 iFzn16GB7bcz for ; Wed, 10 Aug 2016 10:37:10 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0092.outbound.protection.outlook.com [104.47.33.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D89D412D58A for ; Wed, 10 Aug 2016 10:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bNRW1kAuVF7PP7gfpjrzA0XABzL2uIiRyd4d0E5e774=; b=SFGmUc6SmW7kzLOJjIqj36Ocq+aE7v24a1w0uRNxfZY6DESpcOXuHvlvIeKdnCFqzv1QqtegwShPFxIDRicJQ4xumXjk5vKj104zdpzCLQRlhkWBnYg3Cj48kU59Lf06AknbPNG9FDOWGA1S5HGi2Eiae11+AmoJDnwzCZGpMAU= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2154.namprd03.prod.outlook.com (10.166.206.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 10 Aug 2016 17:37:06 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0549.025; Wed, 10 Aug 2016 17:37:06 +0000 From: Andrei Popov To: Dirk Balfanz , Martin Thomson , John Bradley Thread-Topic: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) Thread-Index: AQHR8Ut8epZDh2EP4E+neKQPnf2Vr6A/GCOAgABGfQCAAAbiAIAAf3yAgAHuYQCAAKUE0A== Date: Wed, 10 Aug 2016 17:37:06 +0000 Message-ID: References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:d::1d2] x-ms-office365-filtering-correlation-id: 0520bef5-5541-4aab-0ea8-08d3c144f2cb x-microsoft-exchange-diagnostics: 1; CY1PR03MB2154; 6:3794XyyITYV4g6/gtSlVGQdFvGf/Xodwo15YczDfULY0bUgtU+qc1Zef1Qb4taQmH+g3rkjOagweaoQejMPPTmWDE9WxhJor41UUi+no1/Ffl1c93W5T2SofkiQc/0O3g6FyE37OTGZktaOzW8CPFm3E03C7ZBkAi9qJiRZL389w5RENUld2Dcpqvj7zAdpdqbv6b4AdMKnRi/85RsRApU4tqyOLUN0KfxACbaVatG/DZLu4D1U4H6lSIbBEWVl8P0o8GXKDABjWbY20BBpcGYBsVqRQo77HAyUsinfumDHdRlVrvs4pR0Vbe1IhH0Lxu5J6sQQPEPuWdNcIKvupzg==; 5:2nOBS+Wy2eR4oA9ijaYjyZTESR24MY2c2v7VxLhaZIYDhl/mgVRIWQDA8MNY61OU0dj6aT1DQe6rXFZcWc4NA5f8HBbn0sQC8aghnlnqM6A2QLN9j20LcVJlVg10GiypanlPRRkow3K2yTaAt1Q6Aw==; 24:5/E4IQ8999eAJVqQQ1J6xZURVJx6ntWGZknK9sFamtPNjPxdqoBwgBXY7ZTMyURHTZiSBpKlD4abnHp5yQj4r46SkyXpM0ioFjTybVww77Q=; 7:gFfjnRwMB3pFEbKI6JLT0D4W3MaJtaNNcncfdqUKfVZVDxWtiE4b+19pGF160TmEgojm01Q3C6xdTpNcBs/7J7+/OiiDZSWr9wp9r71OIr3Hn0yMAovC/KimqRXH+eOTFeetLZuTnbgobGyfT6m+O4kwrlNdmlGIBOmJzYc9/D5qX9VpIklTy9Pz4TlLVHdtvpGxw2iJAlCgYZoNVuCjaA68T1Eniql3GRUoheFQUB4NX97a9XS/RtIGfnpG7cp3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2154; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(164470706584770)(67672495146484)(161160346721002)(272811157607776)(211936372134217)(21748063052155)(106180626270275)(92004823454550)(67441168502697); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2154; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2154; x-forefront-prvs: 0030839EEE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(24454002)(51444003)(189002)(377454003)(6116002)(19625215002)(790700001)(102836003)(19609705001)(16236675004)(101416001)(189998001)(33656002)(19580405001)(16601075003)(76576001)(19580395003)(99286002)(68736007)(8676002)(5001770100001)(81156014)(9686002)(11100500001)(586003)(5002640100001)(81166006)(106116001)(122556002)(106356001)(19300405004)(97736004)(8936002)(93886004)(15975445007)(8666005)(7846002)(87936001)(7736002)(86362001)(74316002)(7696003)(3280700002)(1680700002)(2950100001)(5005710100001)(4326007)(2906002)(8990500004)(2900100001)(77096005)(7906003)(10090500001)(92566002)(10400500002)(54356999)(50986999)(76176999)(105586002)(19617315012)(3660700001)(86612001)(10290500002)(7059030)(3826002)(16940595002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2154; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB2155707B42856AEA950664858C1D0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2016 17:37:06.2150 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2154 Archived-At: Cc: Subodh Iyengar , Scott Cantor , IETF Tokbind WG , Brian Campbell , "Manger, James" , Nick Harper Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 10 Aug 2016 17:37:13 -0000 --_000_CY1PR03MB2155707B42856AEA950664858C1D0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB0aGUgZXh0cmEgcm91bmQtdHJpcHMgd291bGQgYmUgYSBkZXBsb3ltZW50IGJsb2NrZXIg aW4gbWFueSBjYXNlcy4gR2VuZXJhbGx5LCBJIHRoaW5rIHRoYXQgc2NvcGluZyBUQiBrZXlzIG5h cnJvd2VyIHRoYW4gdGhlIHRva2VucyB0aGV5IHByb3RlY3Qgd291bGQgY2F1c2UgcHJvYmxlbXMu DQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206IFVuYmVhcmFibGUgW21haWx0bzp1bmJlYXJh YmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEaXJrIEJhbGZhbnoNClNlbnQ6IFdl ZG5lc2RheSwgQXVndXN0IDEwLCAyMDE2IDEyOjQ0IEFNDQpUbzogTWFydGluIFRob21zb24gPG1h cnRpbi50aG9tc29uQGdtYWlsLmNvbT47IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+ DQpDYzogU3Vib2RoIEl5ZW5nYXIgPHN1Ym9kaEBmYi5jb20+OyBTY290dCBDYW50b3IgPGNhbnRv ci4yQG9zdS5lZHU+OyBJRVRGIFRva2JpbmQgV0cgPHVuYmVhcmFibGVAaWV0Zi5vcmc+OyBCcmlh biBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+OyBNYW5nZXIsIEphbWVzIDxK YW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPjsgTmljayBIYXJwZXIgPG5oYXJwZXJAZ29v Z2xlLmNvbT4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gUmV2aXNpdCBlVExEKzEgKHdhcyBS ZTogc3VwcG9ydCBmb3IgZGlmZmVyZW50IGtleSBwYXJhbWV0ZXJzIHdpdGhpbiB0aGUgc2FtZSBU TEQrMSkNCg0KR29vZ2xlIHNldHMgYW4gYXV0aGVudGljYXRpb24gY29va2llIG9uICouZ29vZ2xl LmNvbTxodHRwOi8vZ29vZ2xlLmNvbT4uIFdlIGFsc28gc2V0IGEgdmFyaWV0eSBvZiBhdXRoZW50 aWNhdGlvbi1yZWxhdGVkIGNvb2tpZXMgb24gbW9yZSBuYXJyb3dseS1kZWZpbmVkIGRvbWFpbnMs IGJ1dCBpdCdzIHRoYXQgZG9tYWluIGNvb2tpZSB0aGF0IHdlIGNoYW5uZWwtYmluZC4NCg0KU29t ZXRpbWVzIHVzZXJzIGFycml2ZSBhdCwgc2F5LCBtYWlsLmdvb2dsZS5jb208aHR0cDovL21haWwu Z29vZ2xlLmNvbT4gdGhyb3VnaCBhIHJlZGlyZWN0IGZyb20gYWNjb3VudHMuZ29vZ2xlLmNvbTxo dHRwOi8vYWNjb3VudHMuZ29vZ2xlLmNvbT4gKHdoaWNoIG1pbnRzIHRoZSBkb21haW4gY29va2ll KSBhbmQgaW4gdGhhdCBjYXNlIGl0J3MgdGhlb3JldGljYWxseSBwb3NzaWJsZSB0aGF0IHRoZXkg Y291bGQgYXJyaXZlIHRoZXJlIHdpdGggYSByZWZlcnJlZCB0b2tlbiBiaW5kaW5nIGZyb20gYWNj b3VudHMuZ29vZ2xlLmNvbTxodHRwOi8vYWNjb3VudHMuZ29vZ2xlLmNvbT4uIFNvIGxldCdzIHNh eSBhIHJlcXVlc3QgY29tZXMgaW50byBtYWlsLmdvb2dsZS5jb208aHR0cDovL21haWwuZ29vZ2xl LmNvbT4gd2l0aCBwcm92aWRlZCB0b2tlbiBiaW5kaW5nIEt4LCByZWZlcnJlZCB0b2tlbiBiaW5k aW5nIEt5LCBhbmQgdGhlIGNvb2tpZSBpcyBib3VuZCB0byBLeS4gbWFpbC5nb29nbGUuY29tPGh0 dHA6Ly9tYWlsLmdvb2dsZS5jb20+IG5vdyB3b3VsZCBoYXZlIHRvIHJlbWVtYmVyIHRoYXQgS3gg aXMgYWxzbyBhIHZhbGlkIHRva2VuIGJpbmRpbmcga2V5IGZvciB0aGlzIGNvb2tpZSAtIHByZXN1 bWFibHkgYnkgbXV0YXRpbmcgdGhlIGNvb2tpZSAob3IgaXRzIGFzc29jaWF0ZWQgc2Vzc2lvbiBp bmZvcm1hdGlvbiBvbiB0aGUgc2VydmVyKS4gR21haWwgY2FuJ3Qgd3JpdGUvbXV0YXRlIG91ciBh dXRoZW50aWNhdGlvbiBjb29raWVzIC0gb25seSBvdXIgYXV0aGVudGljYXRpb24gaW5mcmFzdHJ1 Y3R1cmUgY2FuIGRvIHRoaXMuIE5vdCBhbiBpbnN1cm1vdW50YWJsZSBwcm9ibGVtLCBidXQgbGlr ZWx5IG9uZSB0aGF0J3MgYmlnIGVub3VnaCBmb3IgZ21haWwgKGFuZCBtYXBzLCBhbmQgZG9jcywg ZXRjLikgdG8gY29uY2x1ZGUgdGhhdCB0aGV5IHNob3VsZG4ndCBib3RoZXIgd2l0aCBjaGFubmVs IGJpbmRpbmcuDQoNClRoZW4gdGhlcmUgYXJlIHRoZSBjYXNlcyBpbiB3aGljaCB1c2VycyBhcnJp dmUgYXQgb3VyIGRlc3RpbmF0aW9uIHNlcnZpY2VzIChtYWlsLmdvb2dsZS5jb208aHR0cDovL21h aWwuZ29vZ2xlLmNvbT4sIG1hcHMuZ29vZ2xlLmNvbTxodHRwOi8vbWFwcy5nb29nbGUuY29tPiwg ZXRjLikgZGlyZWN0bHkgYnkgdHlwaW5nIHRoZSBVUkwgaW50byB0aGVpciBicm93c2VyLiBJbiB0 aGF0IGNhc2UgdGhlIHNlcnZpY2Ugd29uJ3QgaGF2ZSB0aGUgYmVuZWZpdCBvZiBzZWVpbmcgdGhl IHJlZmVycmVkIHRva2VuIGJpbmRpbmcsIHNvIHRoZSBjb29raWUgd2lsbCBzaW1wbHkgY291bnQg YXMgbWlzbWF0Y2hlZC4gSW5jdXJyaW5nIHRoZSBleHRyYSByZWRpcmVjdCBpbiB0aGlzIGNhc2Ug dG8gYWNjb3VudHMuZ29vZ2xlLmNvbTxodHRwOi8vYWNjb3VudHMuZ29vZ2xlLmNvbT4gYW5kIGJh Y2sgaXMgYWdhaW4gc29tZXRoaW5nIHRoYXQgdGhlIHZhcmlvdXMgdGVhbXMgYW5kIHNlcnZpY2Vz IGFyZSBub3QgbGlrZWx5IHdpbGxpbmcgdG8gcGF5Lg0KDQpJbiBjb25jbHVzaW9uLCBtb3Zpbmcg dG8gYW4gb3JpZ2luIHNjb3BlIGZvciB0b2tlbi1iaW5kaW5nIGtleXMgd291bGQgbGlrZWx5IG1l YW4gZm9yIGEgY29tcGFueSBsaWtlIEdvb2dsZSwgd2hpY2ggaGFzIGJpZyBjb21wbGljYXRlZCBv bGQgc3lzdGVtcyB0aGF0IGFyZSBoYXJkIHRvIGNoYW5nZSwgdGhhdCB3ZSBjb3VsZG4ndCBpbiBw cmFjdGljZSBkZXBsb3kgaXQuDQoNCkRpcmsuDQoNCg0KT24gTW9uLCBBdWcgOCwgMjAxNiBhdCA3 OjE0IFBNIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1h cnRpbi50aG9tc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KT24gOSBBdWd1c3QgMjAxNiBhdCAwNDoz OCwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0Yi5j b20+PiB3cm90ZToNCj4gTWFydGluIGRvIHlvdSBoYXZlIHNvbWUgaWRlYSBob3cgYSB0b2tlbiBi b3VuZCBjb29raWUgc2V0IGJ5IHguZXhhbXBsZS5jb208aHR0cDovL3guZXhhbXBsZS5jb20+DQo+ IGNvdWxkIGJlIHZhbGlkYXRlZCBieSB5LmV4YW1wbGUuY29tPGh0dHA6Ly95LmV4YW1wbGUuY29t PiB1bmRlciBhIHN0cmljdCBzYW1lIG9yaWdpbiBwb2xpY3kuDQoNClNvIHggc2V0cyBhIGNvb2tp ZSBib3VuZCB0byBrZXkgS3guICBPbmx5IHggY2FuIHZhbGlkYXRlIHRoYXQga2V5DQpiZWNhdXNl IHRoZSBjbGllbnQgZG9lc24ndCB1c2UgdGhhdCBrZXkgd2l0aCBvdGhlciBwYXJ0aWVzLiAgVGhh dA0KbWVhbnMgdGhhdCB5IG5lZWRzIHRvIGdldCB0aGUgY2xpZW50IHRvIHByb3ZlIHBvc3Nlc3Np b24gb2YgKHRoZQ0KcHJpdmF0ZSBrZXkgZm9yKSBLeC4NCg0KV2l0aCB0aGUgaGVscCBvZiB4LCBp dCBjYW4gZWFzaWx5IGRvIHRoaXMgd2l0aCBhIHJlZmVycmVkIHRva2VuDQpiaW5kaW5nLiAgeSBt YWtlcyB0aGUgY2xpZW50IG1ha2UgYSByZXF1ZXN0IHRvIHgsIGFuZCB4IHJlZGlyZWN0cyBiYWNr DQp0byB5IHdpdGggdGhlIDxyZWFsbHktbG9uZy1oZWFkZXItZmllbGQtbmFtZS10aGF0LXRyaWdn ZXJzLXJlZmVycmVkLXRva2VuLWJpbmRpbmc+DQpoZWFkZXIgZmllbGQgc2V0LiAgVGhlbiB5IGlz IGFibGUgdG8gYWNxdWlyZSBwcm9vZiBmcm9tIHRoZSBjbGllbnQNCnRoYXQgaXQgb3ducyBLeC4N Cg0KVGhpcyBvbmx5IHJlcXVpcmVzIHRoYXQgeSBzdXBwb3J0IHRoZSBzYW1lIHNpZ25hdHVyZSBz Y2hlbWVzIGFzIHgsIGFuZA0KdGhhdCB5IGhhcyBoZWxwIGZyb20geC4NCg0KU3VyZSwgdGhpcyBp cyBpbmNvbnZlbmllbnQgKGl0J3Mgcm91bmQgdHJpcHMpLCBidXQgdGhpcyBlc3RhYmxpc2hlcw0K cG9zc2libGUuICBBbmQsIG9uY2UgeW91IGhhdmUgdGhpcyBwcm9vZiwgeW91IG1pZ2h0IGJlIGFi bGUgdG8gc3RvcmUNCnRoZSBtYXBwaW5nIGJldHdlZW4gS3ggYW5kIEt5Lg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVW5iZWFyYWJsZSBtYWlsaW5n IGxpc3QNClVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCg== --_000_CY1PR03MB2155707B42856AEA950664858C1D0CY1PR03MB2155namp_ 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 IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlllcywgdGhlIGV4dHJhIHJvdW5kLXRyaXBzIHdvdWxkIGJl IGEgZGVwbG95bWVudCBibG9ja2VyIGluIG1hbnkgY2FzZXMuIEdlbmVyYWxseSwgSSB0aGluayB0 aGF0IHNjb3BpbmcgVEIga2V5cyBuYXJyb3dlciB0aGFuIHRoZSB0b2tlbnMgdGhleSBwcm90ZWN0 IHdvdWxkIGNhdXNlIHByb2JsZW1zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaGVlcnMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkFuZHJlaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+RGlyayBCYWxmYW56PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2Rh eSwgQXVndXN0IDEwLCAyMDE2IDEyOjQ0IEFNPGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gVGhvbXNv biAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29tJmd0OzsgSm9obiBCcmFkbGV5ICZsdDt2ZTdq dGJAdmU3anRiLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFN1Ym9kaCBJeWVuZ2FyICZsdDtzdWJv ZGhAZmIuY29tJmd0OzsgU2NvdHQgQ2FudG9yICZsdDtjYW50b3IuMkBvc3UuZWR1Jmd0OzsgSUVU RiBUb2tiaW5kIFdHICZsdDt1bmJlYXJhYmxlQGlldGYub3JnJmd0OzsgQnJpYW4gQ2FtcGJlbGwg Jmx0O2JjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tJmd0OzsgTWFuZ2VyLCBKYW1lcyAmbHQ7SmFt ZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbSZndDs7IE5pY2sgSGFycGVyICZsdDtuaGFycGVy QGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gUmV2 aXNpdCBlVExEJiM0MzsxICh3YXMgUmU6IHN1cHBvcnQgZm9yIGRpZmZlcmVudCBrZXkgcGFyYW1l dGVycyB3aXRoaW4gdGhlIHNhbWUgVExEJiM0MzsxKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkdvb2dsZSBzZXRzIGFuIGF1dGhlbnRpY2F0aW9uIGNvb2tpZSBvbiAqLjxh IGhyZWY9Imh0dHA6Ly9nb29nbGUuY29tIj5nb29nbGUuY29tPC9hPi4gV2UgYWxzbyBzZXQgYSB2 YXJpZXR5IG9mIGF1dGhlbnRpY2F0aW9uLXJlbGF0ZWQgY29va2llcyBvbiBtb3JlIG5hcnJvd2x5 LWRlZmluZWQgZG9tYWlucywgYnV0IGl0J3MgdGhhdCBkb21haW4gY29va2llIHRoYXQgd2UgY2hh bm5lbC1iaW5kLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ U29tZXRpbWVzIHVzZXJzIGFycml2ZSBhdCwgc2F5LCA8YSBocmVmPSJodHRwOi8vbWFpbC5nb29n bGUuY29tIj4NCm1haWwuZ29vZ2xlLmNvbTwvYT4gdGhyb3VnaCBhIHJlZGlyZWN0IGZyb20gPGEg aHJlZj0iaHR0cDovL2FjY291bnRzLmdvb2dsZS5jb20iPg0KYWNjb3VudHMuZ29vZ2xlLmNvbTwv YT4gKHdoaWNoIG1pbnRzIHRoZSBkb21haW4gY29va2llKSBhbmQgaW4gdGhhdCBjYXNlIGl0J3Mg dGhlb3JldGljYWxseSBwb3NzaWJsZSB0aGF0IHRoZXkgY291bGQgYXJyaXZlIHRoZXJlIHdpdGgg YSByZWZlcnJlZCB0b2tlbiBiaW5kaW5nIGZyb20NCjxhIGhyZWY9Imh0dHA6Ly9hY2NvdW50cy5n b29nbGUuY29tIj5hY2NvdW50cy5nb29nbGUuY29tPC9hPi4gU28gbGV0J3Mgc2F5IGEgcmVxdWVz dCBjb21lcyBpbnRvDQo8YSBocmVmPSJodHRwOi8vbWFpbC5nb29nbGUuY29tIj5tYWlsLmdvb2ds ZS5jb208L2E+IHdpdGggcHJvdmlkZWQgdG9rZW4gYmluZGluZyBLeCwgcmVmZXJyZWQgdG9rZW4g YmluZGluZyBLeSwgYW5kIHRoZSBjb29raWUgaXMgYm91bmQgdG8gS3kuDQo8YSBocmVmPSJodHRw Oi8vbWFpbC5nb29nbGUuY29tIj5tYWlsLmdvb2dsZS5jb208L2E+IG5vdyB3b3VsZCBoYXZlIHRv IHJlbWVtYmVyIHRoYXQgS3ggaXMgYWxzbyBhIHZhbGlkIHRva2VuIGJpbmRpbmcga2V5IGZvciB0 aGlzIGNvb2tpZSAtIHByZXN1bWFibHkgYnkgbXV0YXRpbmcgdGhlIGNvb2tpZSAob3IgaXRzIGFz c29jaWF0ZWQgc2Vzc2lvbiBpbmZvcm1hdGlvbiBvbiB0aGUgc2VydmVyKS4gR21haWwgY2FuJ3Qg d3JpdGUvbXV0YXRlIG91cg0KIGF1dGhlbnRpY2F0aW9uIGNvb2tpZXMgLSBvbmx5IG91ciBhdXRo ZW50aWNhdGlvbiBpbmZyYXN0cnVjdHVyZSBjYW4gZG8gdGhpcy4gTm90IGFuIGluc3VybW91bnRh YmxlIHByb2JsZW0sIGJ1dCBsaWtlbHkgb25lIHRoYXQncyBiaWcgZW5vdWdoIGZvciBnbWFpbCAo YW5kIG1hcHMsIGFuZCBkb2NzLCBldGMuKSB0byBjb25jbHVkZSB0aGF0IHRoZXkgc2hvdWxkbid0 IGJvdGhlciB3aXRoIGNoYW5uZWwgYmluZGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlbiB0aGVyZSBhcmUgdGhlIGNhc2VzIGluIHdo aWNoIHVzZXJzIGFycml2ZSBhdCBvdXIgZGVzdGluYXRpb24gc2VydmljZXMgKDxhIGhyZWY9Imh0 dHA6Ly9tYWlsLmdvb2dsZS5jb20iPm1haWwuZ29vZ2xlLmNvbTwvYT4sDQo8YSBocmVmPSJodHRw Oi8vbWFwcy5nb29nbGUuY29tIj5tYXBzLmdvb2dsZS5jb208L2E+LCBldGMuKSBkaXJlY3RseSBi eSB0eXBpbmcgdGhlIFVSTCBpbnRvIHRoZWlyIGJyb3dzZXIuIEluIHRoYXQgY2FzZSB0aGUgc2Vy dmljZSB3b24ndCBoYXZlIHRoZSBiZW5lZml0IG9mIHNlZWluZyB0aGUgcmVmZXJyZWQgdG9rZW4g YmluZGluZywgc28gdGhlIGNvb2tpZSB3aWxsIHNpbXBseSBjb3VudCBhcyBtaXNtYXRjaGVkLiBJ bmN1cnJpbmcgdGhlIGV4dHJhDQogcmVkaXJlY3QgaW4gdGhpcyBjYXNlIHRvIDxhIGhyZWY9Imh0 dHA6Ly9hY2NvdW50cy5nb29nbGUuY29tIj5hY2NvdW50cy5nb29nbGUuY29tPC9hPiBhbmQgYmFj ayBpcyBhZ2FpbiBzb21ldGhpbmcgdGhhdCB0aGUgdmFyaW91cyB0ZWFtcyBhbmQgc2VydmljZXMg YXJlIG5vdCBsaWtlbHkgd2lsbGluZyB0byBwYXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIGNvbmNsdXNpb24sIG1vdmluZyB0byBhbiBv cmlnaW4gc2NvcGUgZm9yIHRva2VuLWJpbmRpbmcga2V5cyB3b3VsZCBsaWtlbHkgbWVhbiBmb3Ig YSBjb21wYW55IGxpa2UgR29vZ2xlLCB3aGljaCBoYXMgYmlnIGNvbXBsaWNhdGVkIG9sZCBzeXN0 ZW1zIHRoYXQgYXJlIGhhcmQgdG8gY2hhbmdlLCB0aGF0IHdlIGNvdWxkbid0IGluIHByYWN0aWNl IGRlcGxveSBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+RGlyay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBNb24sIEF1ZyA4LCAyMDE2IGF0IDc6MTQgUE0gTWFydGluIFRob21z b24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iPm1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gOSBBdWd1c3QgMjAxNiBhdCAwNDoz OCwgSm9obiBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRh cmdldD0iX2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsg TWFydGluIGRvIHlvdSBoYXZlIHNvbWUgaWRlYSBob3cgYSB0b2tlbiBib3VuZCBjb29raWUgc2V0 IGJ5IDxhIGhyZWY9Imh0dHA6Ly94LmV4YW1wbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+DQp4LmV4 YW1wbGUuY29tPC9hPjxicj4NCiZndDsgY291bGQgYmUgdmFsaWRhdGVkIGJ5IDxhIGhyZWY9Imh0 dHA6Ly95LmV4YW1wbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+eS5leGFtcGxlLmNvbTwvYT4gdW5k ZXIgYSBzdHJpY3Qgc2FtZSBvcmlnaW4gcG9saWN5Ljxicj4NCjxicj4NClNvIHggc2V0cyBhIGNv b2tpZSBib3VuZCB0byBrZXkgS3guJm5ic3A7IE9ubHkgeCBjYW4gdmFsaWRhdGUgdGhhdCBrZXk8 YnI+DQpiZWNhdXNlIHRoZSBjbGllbnQgZG9lc24ndCB1c2UgdGhhdCBrZXkgd2l0aCBvdGhlciBw YXJ0aWVzLiZuYnNwOyBUaGF0PGJyPg0KbWVhbnMgdGhhdCB5IG5lZWRzIHRvIGdldCB0aGUgY2xp ZW50IHRvIHByb3ZlIHBvc3Nlc3Npb24gb2YgKHRoZTxicj4NCnByaXZhdGUga2V5IGZvcikgS3gu PGJyPg0KPGJyPg0KV2l0aCB0aGUgaGVscCBvZiB4LCBpdCBjYW4gZWFzaWx5IGRvIHRoaXMgd2l0 aCBhIHJlZmVycmVkIHRva2VuPGJyPg0KYmluZGluZy4mbmJzcDsgeSBtYWtlcyB0aGUgY2xpZW50 IG1ha2UgYSByZXF1ZXN0IHRvIHgsIGFuZCB4IHJlZGlyZWN0cyBiYWNrPGJyPg0KdG8geSB3aXRo IHRoZSAmbHQ7cmVhbGx5LWxvbmctaGVhZGVyLWZpZWxkLW5hbWUtdGhhdC10cmlnZ2Vycy1yZWZl cnJlZC10b2tlbi1iaW5kaW5nJmd0Ozxicj4NCmhlYWRlciBmaWVsZCBzZXQuJm5ic3A7IFRoZW4g eSBpcyBhYmxlIHRvIGFjcXVpcmUgcHJvb2YgZnJvbSB0aGUgY2xpZW50PGJyPg0KdGhhdCBpdCBv d25zIEt4Ljxicj4NCjxicj4NClRoaXMgb25seSByZXF1aXJlcyB0aGF0IHkgc3VwcG9ydCB0aGUg c2FtZSBzaWduYXR1cmUgc2NoZW1lcyBhcyB4LCBhbmQ8YnI+DQp0aGF0IHkgaGFzIGhlbHAgZnJv bSB4Ljxicj4NCjxicj4NClN1cmUsIHRoaXMgaXMgaW5jb252ZW5pZW50IChpdCdzIHJvdW5kIHRy aXBzKSwgYnV0IHRoaXMgZXN0YWJsaXNoZXM8YnI+DQpwb3NzaWJsZS4mbmJzcDsgQW5kLCBvbmNl IHlvdSBoYXZlIHRoaXMgcHJvb2YsIHlvdSBtaWdodCBiZSBhYmxlIHRvIHN0b3JlPGJyPg0KdGhl IG1hcHBpbmcgYmV0d2VlbiBLeCBhbmQgS3kuPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpVbmJlYXJhYmxlIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+VW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGU8L2E+PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR03MB2155707B42856AEA950664858C1D0CY1PR03MB2155namp_-- From nobody Wed Aug 10 10:43:27 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 233A212D834 for ; Wed, 10 Aug 2016 10:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 xbVWgGvH4ads for ; Wed, 10 Aug 2016 10:43:23 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0113.outbound.protection.outlook.com [104.47.37.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96C412D832 for ; Wed, 10 Aug 2016 10:43:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buckeyemailosu.onmicrosoft.com; s=selector1-osu-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=W1LK8FkpAOsCeKK61NMjSO3qrh4WQDUHzjotIOWSpBw=; b=kePajLQX8xODdBXBjtYze0YFIdlkmkD8voV6Jz58joe7vSyt73oJU/YiXbzd+jz9u3ZaQN9/YnkETadLXfJpM1IjJQ/yXzheOPhXOPY5m3T/O9vRfY8UxVLEr0z0IZw3BicWlar8gx9rbdGfUT0T6BskUza4k3AusCLa7G+CYR0= Received: from BY2PR01CA0077.prod.exchangelabs.com (10.163.25.45) by BY2PR01MB1781.prod.exchangelabs.com (10.166.108.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 10 Aug 2016 17:43:18 +0000 Received: from BY2FFO11OLC012.protection.gbl (2a01:111:f400:7c0c::104) by BY2PR01CA0077.outlook.office365.com (2a01:111:e400:5262::45) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.15 via Frontend Transport; Wed, 10 Aug 2016 17:43:18 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.212) smtp.mailfrom=osu.edu; fb.com; dkim=none (message not signed) header.d=none;fb.com; 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 BY2FFO11OLC012.mail.protection.outlook.com (10.1.15.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.567.7 via Frontend Transport; Wed, 10 Aug 2016 17:43:19 +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-krc-pf05.osuad.osu.edu (Postfix) with ESMTPS id BED3D60059; Wed, 10 Aug 2016 13:43:17 -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; Wed, 10 Aug 2016 13:43:16 -0400 From: "Cantor, Scott" To: Andrei Popov , Dirk Balfanz , Martin Thomson , John Bradley Thread-Topic: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) Thread-Index: AQHR8aDDx+pDq6EZgE2nj7753s28fqA/p+UAgAIq4z2AAOikAP//ve2w Date: Wed, 10 Aug 2016 17:43:15 +0000 Message-ID: <9846A6064BD102419D06814DD0D78DE1129E2F59@CIO-TNC-D2MBX02.osuad.osu.edu> References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> 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.214] x-header-sapphire: true Content-Type: text/plain; charset="utf-8" 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)(7916002)(2980300002)(438002)(199003)(189002)(51444003)(7846002)(66066001)(102836003)(55846006)(8666005)(7736002)(6116002)(7696003)(93346002)(16796002)(2421001)(11100500001)(3846002)(1511001)(106466001)(2950100001)(106116001)(356003)(7596002)(109096001)(86766002)(75432002)(47776003)(305945005)(8936002)(89122001)(2561002)(93886004)(2920100001)(2900100001)(50466002)(189998001)(87936001)(92566002)(33656002)(586003)(86362001)(5250100002)(8676002)(54356999)(76176999)(5001770100001)(88552002)(50986999)(90282001)(2906002)(23676002)(4326007)(246002)(626004)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR01MB1781; H:cio-krc-pf05.osuad.osu.edu; FPR:; SPF:Pass; PTR:cio-krc-pf05.osuad.osu.edu; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11OLC012; 1:D1Er0sbkdxkyqg8S/YlMPdsFjL/wTZbLFfZgzBtzCKqzZhb9I7bAY9jOl6Dcfcxax/CR+I35IsaILRqhpnGm8OD9mR3wBIfmo9cbimdsY4nW6imOKdb/aLMjKCHP9wG2qpuMfDoaXx28C9zuD5WQwYL69FHtygmnpJY5kzXlxq4kxZuAE3JzuTKq7ITvsUleMeXma90x6HMCD+Bqatqb0uHafD3EYuEpfFZEemNMbMqNXGlVZL5yA2bHimG5o9jp3TaEAxj6F9oNo8wNvD8jmmKMC9/arWVF92TdXJg1uuG/UBrZfDk7j8n2t3ESi88u6RfZ4hG5qsn1RxnJsA1W+1s7+6joPUa2Xstga2iEP07ET9t0YCsEOr3tlHopdYSjVPkBumjyF79yh45HyoIYGpnGs7SIcmkQw2IW9IHmbyWDghma1c2eqOpgY7+mStcohsTGXj4chRjnoLbcuGP2QWdO3Fv0ch9d96Y41k0VQByYiWZzeU7SNOE2020RXIetLwli8Wnba5We8wuFqukDNib4k9nJvBuOK2tJNMMi/VraosyI+Kyb52AP5OGovNGE X-MS-Office365-Filtering-Correlation-Id: e9d7dbc3-c4b3-451c-1f7e-08d3c145d155 X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1781; 2:bjTAGpXyBmCVMlhwrwkpcudS5652iTgOlBaxbMudqNTJHbVXpXXkZzibInY+7R8F16UI1h+LVbfZuisH6tXNS3h3bWGgXnQlcgwNcbbzrSOb+3WJ0bG1MY0MUOkTmxLr6KeVePmjw6IuRv+m1+z+taEUD/uY0cBaD6SN5OPHbmrqiGWpKVgAsyTSjfpOZ+Dx; 3:a50I1RYpdJ8FKQEjOsrAm2ehnd+eOoH5q3BTNY9lWocfhcZnDCp8V6Mm1jY11ElkF3jlS8IbYI5YS8L4nT8MWzzfQG1pxx/cjPkF8nC9Xiqz0ZvvAIOCH6g4kaiIc3rfr3NVzPfN21SvuiZRC1XWHTiPq2ksW/qvoJooc2dWWW/xgGeMugv9G4HrzIvSqmGSHvE5qz33jct7SYRJ7R1UnVtTvjQJ+mPZFaakSeGlVOKlGx4u21FLIuaSKMuDKUChgTolCxa7IFAS6anhgDaKLw== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BY2PR01MB1781; X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1781; 25:uP3zVzlqjtyp/arowu6xi7jS+UwYZ+p2yFj+z//b0CDjRFwuJe3VW+RC5rRnUZe6J5HEqPvWoLpGvVfVGyH2S7Uaa4EB38wTMsB/kxOrQ/UoeNRdprIAFSIW2uR0B9BQ/CpPp4THPfULEan71Zs2lbejJpKZsaO3ReBmlmAnoNuAk3iD8Rt9VdHwWQ0pKWzGPhwuODi4OmGZUwpn5B7vQjwd0xzj11J0slhOdCYDpjDXoVhZvO23FQkrt33cgPdk2EW3wzWi5hS/4cmH1DAJkE+6uTPn1884Ttm9O4yS4wO27qHaxhYXpRxu/nl785uIdtUwphNUXpbktcQpT46Qewhv6FazCqkxvkGLwfvaTxxSNrgEs+gL4HEhL4KlMeLHooGNG97PjqabA0x8E8ajcNomLIlhi69DbaKJTFlft6SQdFVhVKqnEldQSnxloPAlyORVPk2ijZSawV2XtZlPO30EuGEK4eL68F9feqxtJILmc4dNp8gVsqdaREUHsKxLmE2g9WDjOxhSrCX9dBOH7ooG0S7nC1vomO+pfuQKD5J3X48QI4rHPCePpRZhNc3HD2kqBfoosUIVa15KmPnmMRuL412H8chA4grIMjgqSbcEoI/S1NJOfImOYCOdeKC3r1drqcnrpMUcqIxXCIrmvKvpDxSYtQvWXQTz2CShEHHTANnSxaohcyQjIpzh6BhPrIm5okcUnYY5tgbBAYqC79C03rQLOKVLcZr2xkFzbsfF6teRVf6C9gxxkrWs66z+DyWNLaEUH9OTC5Tvti5kCw== X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1781; 31:JQ+iI6vqVqpb2vq9E07BThj6TjVd0DJR5sLbqGUGXeaHnETAUfyam3qMFeF26KQsoBZG13G2N7v4yAeZKYc2fbqAJBH9PLcawX18zOd0j8sNWcezxwSqur+JYCZmrFO0otOwyknRkGAuCMheqKS73aCqdShuK74fwAeXzaKrjJg6PuiBfk7PuG1OIH9yjBgm+mH/d860Gs+qlFcUqqMDJmFXgv8YSP+lGXd81FC1n94=; 20:7pFHEZH81OBTADP6AfxVUzodosiso2HW5BYmVRFvchUw1vAnFk6rhiY6eBaBUW44+H0mds8bdrVXM/Oz1OQlualeeSb5HqU7Z6oaR3P40V+lEUCf/Bbp7+d4IuxattjjmXFcGEOElT2xSJfi78HCBgWbZy31PY8WSAqahvQnLzFmyaAz8CpKA7vQ1xNvAkKaybQ23s145oGoafEjcps/4qgWl7dEjh1+5K/OSmumDevw0SzxoTFvcVeh6VL/upPwc6ng7RDedjmGQ97GmQtlEVP8FJN5S1nsWH/ngyTvDAcDup1DXUofU5biGNTLsvo4MS+AkD2nlvGCtpZEyG49ATWfj4NJHHDlVRn5nevvKJB/P3VmTHOpawE/vEqeclIdeVrmEVP3ED6seO02nRVyjI5QFccGwJF06j9hPWWNIoN+eGeTog7NClkFh2FG2mhrLhYu+METUJk6f3x2tt2vGmFSxI1SjQ5Os1DaTvEeEb2snoQOvHGrYjOTBkOf2oRc X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040166)(2401047)(13024025)(13016025)(13018025)(13023025)(8121501046)(5005006)(10201501046)(3002001); SRVR:BY2PR01MB1781; BCL:0; PCL:0; RULEID:; SRVR:BY2PR01MB1781; X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1781; 4:vhQCPEbWlIO8uV2ftpJImimUaGALa3tZqKMvVu5hyrvXNrP9KrgpEMpKU6sdD5DsyaaIXhcfv+c0E8CVxJgoaaEHVe9IZcniZOy1FMnnJgIDkgAs8eIOhsMu/a1jYDxzkjfmz6DLUCjbWgvvQhQtKk0stxqMyPCsQLfYtzCYFv3oMq2MwfFqiiue5zRRaEo52jHs3dPvqkFVS6dJq3r3vkQodVnmGCrrmHdjuMP9OmjJMphCJl0oR4VPw9je+8ZAoXFJkMKapFUkP2KxqBqG0Ciexfd7en+jrwuqvdPhToQS+aIrmFh0k0SeUOtcUvTloxswNmh0lmjhUATE1xK+MrlmYUYtO5s7Pulx/aMGPsikdHa6c4EU/R5yzT4VKVVNQ7JyD28Ts/K0LumnY6wB1rcmW0tIGbs4KPDDrRnQB6Sxpmi9Z1UHa+Sq8oDsr+7Nb5u0w20W9Ps4X3Z8bb1fY/ahuzf1doUI7Fcu3uXCUeE= X-Forefront-PRVS: 0030839EEE X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCWTJQUjAxTUIxNzgxOzIzOnMzMjFreWpxOUx3KzNMS2wyOVpTbGFzdVVz?= =?utf-8?B?ZHZvNFhMVDQ4Zk1tMFlmS3pWaitvTHJ3b1RGaCs5dG9yQTV2V2JRMTYyWUZo?= =?utf-8?B?Y041ZjN3UnB1ZWxpTFdyWjJQQzJWTXU4bWE0NVZnZExERC8wOHJVODg5MUZr?= =?utf-8?B?SEFnYUpHeTFxMk4yWTgzaERXNHhuWHcwQWlIZEFZQTA4SDc5OWR3cXYvUEFH?= =?utf-8?B?ekFRelkzYkE4NlQ2YkdzRmpQY0dhYWY5Mlc4aGNDa2E2bVhxbklabGJ2ZEht?= =?utf-8?B?eUIxU2kvQ1VnTUlYV2F2KzY1RElNK0Z0aGIvejhDZm5VZU1KQnhsMS9uZW9K?= =?utf-8?B?R2JuOG1nWDVqS2QwT1kwMXIrWHptemdBUjhlVStmNUpmRzJEZ1dCSVRJcmZG?= =?utf-8?B?ZXhXdVlDSHVxOUdQVVBMZFU1U3RhV0I2OVlrTXE2VWpBczROVXl2VWU2dlJG?= =?utf-8?B?Q3NFMDMzWTQveVNuVFI1a3RoQVAyQURaYzE2U1VVUFNxbzNaR1pCd1JlRlpt?= =?utf-8?B?Sm1LeVVpV3c1cGNYelVjUEg0RkRWYUtaQnVuaFRlUUJLRmRVMUZ2T0NEUm1h?= =?utf-8?B?ZVh4MUtacnhTUFF3ZEZYVm1neWlQaDlodW1BQWVhb09GQUw0djEyN0hNM1NR?= =?utf-8?B?WEZBOHJ3NHRBYjVuRGluS25UWmxVZjR5c1lKR293TjVLUWFabnRsbW83K2ha?= =?utf-8?B?NCtFNW1vTWlHVmV3QVBIQndLM1B1VXZPUFRYQ1ZTU3pFdXVrZUFmRmYwdkJV?= =?utf-8?B?K1czQWxrM1VRMGRsVjZEMEQ1V0ZoMjIwV3pwVzl3b1pKZnArU1R1VDFJNVhP?= =?utf-8?B?aDZ2bE9VRHdpVTVCa1FkV040WmhRSE9tTEdVN2hFd0txOG1pa1VCV2RleVRV?= =?utf-8?B?TmRHQUcralc1VjliNTZqUjJCVjA0Y1JFaWU4MkpTVHVLVEhMWTVKTFJ2MmNU?= =?utf-8?B?c25aa3BHeEZVWGcrVHYyTGpocnlCalRUWmpZVUNoL2NoRWNKRlppMHd5MkNE?= =?utf-8?B?VXhHZFNTZUM0eGxudlRMN1BWNytmZjFHODlLNEtwMWtYQVVHMXcxamlnSHRy?= =?utf-8?B?RndWK0JiQWFDT3lWWkU5WGpUcVFWY3FpNEMrTVp2dXFhOHpSVnR2VHBUbU1F?= =?utf-8?B?NHp6andzdWxNTjQ0WnByYUhaN0RQWGFuQyttMHdWdDBDVXRaT3RlUW55ZU1S?= =?utf-8?B?Z09HaFRxRWJyRFRMckRLdXdpUTFjTEEyZlRHSCtkcUFXdHZMN2tobm8xMjVt?= =?utf-8?B?cnBaTTJTSkIvc1ZwdEF1blk0eVBhZ3ZyM3p4akFEbUpPNnc4aEt4NEM1Y1Bk?= =?utf-8?B?SUZVWHhjcGdwakEvaFovUVpZY3ZiWFZKQUlrWnVlZU5HZG1QZ25tSHNEK29S?= =?utf-8?B?d20vek9hdFBWcVB0dUtQVTNCR2kzN3FnNG1ZbjYwVUN5Sk9OY1FCOUpSUGY1?= =?utf-8?B?VTQ2Z3lGZW1kbFNLTUNrNWFacURkUFRVNlBlMUF4Q3lHbWpJVlY1ei9Cbjlr?= =?utf-8?B?cFpseHlCZjY3QWh2a1FXbVh4RUtLMWVGUW1NUG11czZxakZ4alFMcnlWTGFR?= =?utf-8?B?OTYvUkV3RWZqcGliS0Y3QzV1bWsreHhFYUc1Z0NWR2NobFZjd2FlaUoranZC?= =?utf-8?B?RmRleDRQeXJCdkhMSmpjTUdjdmFpbGJ4RVVWL3dNN3hTM1djMElOaDF4ZU5M?= =?utf-8?B?dzFBbUovbUxDMDhDck1iclR6eXd1V1FFYnpDYTc2RW5KRzMzdmVGZHRSVmtY?= =?utf-8?B?K2o1TTdHUlV2MzU2NWJhVHduRjdmUS9YSndBOUdtN3pMdzMyc29UbHJaTFAy?= =?utf-8?B?M3BTbzhjRnhLMFhIaDlGU1lPWC9VN3E1UFUyeXZKKzhkTWo5cjQ5Y1R1WHgr?= =?utf-8?Q?90/PZGzIJU4=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1781; 6:ZE1/X7aZ0Zcgl6XBHyz131K/e0zpQsTjYxcY80ZNEa2xcfCzOZO3g8nJ3s/eVEDhAXJ1cUQwgNgj8rs7h7jxl5kR7rRWYVZD14zH03c7dY3af1Op13HwRBVlG1ERim1biFxn+qQEiPNqLFKvil5WE3icvSRziTi7B+REgMyrm6Pm7ioURMCUvWoYr2dfRHw+eBiIehW2KH36f7WQqbpTTvMTC+HeQlVYwEGfL6WIeKs45d8BlSGJuBe1N6EZtfa5NoWq0azsKEzgpJw7dWfhAHDZ7XV4D2OQspYZbWlKUL0=; 5:Qfqc3ClEJ2W2cYKkZuCEkWhjIff5fw4FhlWeDaX/9+RJGwte5qhzlzSJSN1AtwgaBmuFYQT4k0iPbLCqk7eB8T5eDzeWl9j1IZEFOP5ZCIg2cdVD5ziCP+XBqsSk+zMp4SV9W7CWlzMUyCKASN771Q==; 24:fTGGCab7CgM2nhLVGXjJA1lVTo3K1SaZ/38wefplUhTN/dGzsuBFwlG353Y68azZ8Ei1BvcgtwBe/qV20luOQ7Rei/8VaTPCT/7wfu3ijJ0=; 7:MoiCSGT//kXD7bgTQzLzRt1zumDwaHFTw83XjwQugjc6QeGWgcjjDmnKTfpncC4Q8Dh74ItKentEni5KL45fB530Cv6QuuQg490Vx3pdBtf5uO0uLf4q44cQQCeBo45HswH4+uxaaFaW/oL0RKfFtmk6ku2ptQTVSFhI5tMwnEBt3tU85jPAXHTAOlfB6oehXX5Nh+/4Z9xufSTb4BYYJ/AA1YsFd6tqvL0PDt8+BKk8pSMJfd8Iu2UyM4tY37YM SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BY2PR01MB1781; 20:OTIoC7Is9HP3g97WTzGc9WYGJRX/74WVeKrSudr69gHztLeXQc7jsRRGOHKExccdtvHYLBPvGWC9d68GEkZKI3Rh4Nj9lv/bWIm1BjPOdUuNO6LsdV14g/ssZMPbdg8zhVBrM7kUb/KtQpxTjLy7heoI5s6R2PBxMAIh51IT/BE= X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2016 17:43:19.6576 (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: BY2PR01MB1781 Archived-At: Cc: IETF Tokbind WG , Subodh Iyengar , "Manger, James" , Nick Harper , Brian Campbell Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 10 Aug 2016 17:43:25 -0000 PiBZZXMsIHRoZSBleHRyYSByb3VuZC10cmlwcyB3b3VsZCBiZSBhIGRlcGxveW1lbnQgYmxvY2tl ciBpbiBtYW55IGNhc2VzLg0KPiBHZW5lcmFsbHksIEkgdGhpbmsgdGhhdCBzY29waW5nIFRCIGtl eXMgbmFycm93ZXIgdGhhbiB0aGUgdG9rZW5zIHRoZXkgcHJvdGVjdA0KPiB3b3VsZCBjYXVzZSBw cm9ibGVtcy4NCg0KQW5kIHRoZXJlJ3Mgbm8gZmVhc2libGUgd2F5IGZvciBhIGRlcGxveWVyIHRv IGNvbmZpZ3VyZSBhIHNlcnZlciB3aXRoIHRoZSByZXF1aXJlZCBzY29waW5nIHRvIGluZm9ybSB0 aGUgY2xpZW50PyBFdmVuIGlmIGZlZGVyYXRpb24gZGlkbid0IHdvcmsgaW4gYSBwcmFjdGljYWwg d2F5IGluIHRoaXMga2luZCBvZiBzY2VuYXJpbyBiZWNhdXNlIG9mIHRoZSBjcm9zcy1zZXJ2ZXIg aXNzdWVzLCBqdXN0IHRoZSBhYmlsaXR5IHRvIGRvIGl0IGZvciBkaXJlY3RseSBpc3N1ZWQgY29v a2llcyB3b3VsZCBzdGlsbCBiZSBhIGJlbmVmaXQgdG8gcHJpdmFjeS4NCg0KLS0gU2NvdHQNCg0K From nobody Wed Aug 10 11:15:56 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 EF7DC12B042 for ; Wed, 10 Aug 2016 11:15:54 -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 u9pp5mjYxbbV for ; Wed, 10 Aug 2016 11:15:53 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 0E27B127078 for ; Wed, 10 Aug 2016 11:15:52 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id u25so24882179qtb.1 for ; Wed, 10 Aug 2016 11:15:52 -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=GF+8PI/wEOJyzOf9hqx/CO0V+RzdCI27bnQC1sn5V7k=; b=0uKc/lUogeyCihH2Y58qreXfUgPiRAcHCdfEYuo9Y00bXVx9AOGFShqrrUPy9RcTZp hUkZVQnvmyr9sTcQaJJtz+3rkHwWK1dFQ226xMsUUkHdrlp4PpC3SEgRa3oxOLPHzDHh g6T87pvUn3G7uZuzlyPoEa7qug3oj/ln0UT8uCwe6WMGILG9L3dw8ygcPFbtmu02xhVY hieGI5tM88qIZO2SK8NaeejgxN1y3cGigbUBMZGy0OE95e5bk2usMkmCZitqsoc/U5S3 5RFbz125pxGE/Omiy/T/8Qdxx4AqfJUdXAX2Ppww/ZI3pHiY8mcx2TXC0NpUkImd10BQ tvyA== 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=GF+8PI/wEOJyzOf9hqx/CO0V+RzdCI27bnQC1sn5V7k=; b=hd84kfk3uzzXFVraWB9Z2moM+a0YJVHOfJwO4IkW9Vwd9fN3cpZQHlqk7UqFXfMxJI R9YtdTMvaAHAG6V/gQvfKF/C8ADd9NFn5JBRmB5fyDrjjc2tqM/hCIjglGoFb/Oi/9IN Udpr+yFpArFHeQiM3Wh9k+mJMEkcAnuIN/QmKiRJSGit6i9uLYpTJ4xWo0RfnlucI9K1 SY0Hi49BdYyAEDzuEOK3mBbqxXHXOk63H4xkKVgY64PUK3H0TGh1Les+b90kI/MY4/XF 8hP2YUJL0GejpGoVpWT8RaWdJPSxD91yoVdydNEbYW8ULoqDmSKc7lZFBiXXiMAaVdKF Vn4Q== X-Gm-Message-State: AEkooutF635c1W9DIGOhKm9ToLOY3V9XMK/SzNHpvGGybJboSNa1BcACOpuaOvtm9FMLlCPm X-Received: by 10.237.56.170 with SMTP id k39mr5972986qte.138.1470852951833; Wed, 10 Aug 2016 11:15:51 -0700 (PDT) Received: from [192.168.1.49] ([191.115.89.220]) by smtp.gmail.com with ESMTPSA id 55sm23979531qtp.32.2016.08.10.11.15.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Aug 2016 11:15:51 -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: <9846A6064BD102419D06814DD0D78DE1129E2F59@CIO-TNC-D2MBX02.osuad.osu.edu> Date: Wed, 10 Aug 2016 14:15:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129E2F59@CIO-TNC-D2MBX02.osuad.osu.edu> To: Scott Cantor X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Andrei Popov , Subodh Iyengar , Dirk Balfanz , "Manger, James" , IETF Tokbind WG , Brian Campbell , Martin Thomson , Nick Harper Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 10 Aug 2016 18:15:55 -0000 No Hat Scott, are you suggesting that that be done on a per cookie basis, or as = something that the server would advertise in say a header that would = allow the browser to more tightly scope its bindings. It might be possible to have a default exact match but have a flag that = the browser could check to see if it should use eTLD+1. =20 That would allow the server to control it, however it runs the risk of = different servers publishing conflicting rules and causing issues. Completely scraping eTLD+1 seems like it would hurt deployment. How do people feel about a configuration flag of some sort for the = server and having a default. Thoughts? One other thing while I am at it. I have been looking at using Token Binding in OAuth. Because RSA Token binding ID are so large we are probably going to need = a thumbprint of them to put in tokens to keep the size from blowing up. This adds complexity over saying just send the token binding ID. So stepping back it is tempting to just say use the token binding iD and = strongly recommend EC keys as RSA ones really are only for backwards = compatibility and the size may cause things to break. My question is really backwards compatibility with what? Wouldn't it = be better to not try and support RSA and go all EC from the start. RSA = seems unlikely to be used in the real world as almost all of the = infrastructure is new and EC is the better choice. Wouldn=E2=80=99t it be better to have developers spend time on doing two = curve options rather than RSA. =20 Ditching RSA at this point may gore some ox at this point, however = dropping it might lower the complexity of some implementations as they = won=E2=80=99t need to worry about RSA. It also somewhat simplifies key migration in the short term. RSA just = don=E2=80=99t do it. Thoughts John B. > On Aug 10, 2016, at 1:43 PM, Cantor, Scott wrote: >=20 >> Yes, the extra round-trips would be a deployment blocker in many = cases. >> Generally, I think that scoping TB keys narrower than the tokens they = protect >> would cause problems. >=20 > And there's no feasible way for a deployer to configure a server with = the required scoping to inform the client? Even if federation didn't = work in a practical way in this kind of scenario because of the = cross-server issues, just the ability to do it for directly issued = cookies would still be a benefit to privacy. >=20 > -- Scott >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Wed Aug 10 11:26: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 83FE212D1A4 for ; Wed, 10 Aug 2016 11:26:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 maxcdfS7vCLn for ; Wed, 10 Aug 2016 11:26:01 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0096.outbound.protection.outlook.com [104.47.37.96]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E706C127078 for ; Wed, 10 Aug 2016 11:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buckeyemailosu.onmicrosoft.com; s=selector1-osu-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MYdR7r6xq30b9SFl/iBui40nsAfM100RmreFTtVDFMc=; b=X2vU3QUsED60dIuKKZsaCMHWOxYWr25feiopI5gVz3dmkT53ZTBa+B2Z8u2GGra3d6s8HgP9TfOppqyx55nZXUDkrAnFQA65Bn3gEAJzhg9GuNu1IJ7nYwJ8cCeItEYvj1sK2NMgbzFXVYdSbOXnpM7Hp0i3FfIkjNRh1CiZBYw= Received: from BLUPR01CA042.prod.exchangelabs.com (10.160.23.32) by CY1PR01MB2153.prod.exchangelabs.com (10.166.206.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 10 Aug 2016 18:25:58 +0000 Received: from BN1AFFO11FD018.protection.gbl (2a01:111:f400:7c10::192) by BLUPR01CA042.outlook.office365.com (2a01:111:e400:8a4::32) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.15 via Frontend Transport; Wed, 10 Aug 2016 18:25:59 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.212) smtp.mailfrom=osu.edu; fb.com; dkim=none (message not signed) header.d=none;fb.com; 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 BN1AFFO11FD018.mail.protection.outlook.com (10.58.52.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.567.7 via Frontend Transport; Wed, 10 Aug 2016 18:25:59 +0000 Received: from CIO-KRC-HT01.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 D9F9660059; Wed, 10 Aug 2016 14:25:58 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.03.0248.002; Wed, 10 Aug 2016 14:25:56 -0400 From: "Cantor, Scott" To: John Bradley Thread-Topic: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) Thread-Index: AQHR8aDDx+pDq6EZgE2nj7753s28fqA/p+UAgAIq4z2AAOikAP//ve2wgABM4ID//746kA== Date: Wed, 10 Aug 2016 18:25:56 +0000 Message-ID: <9846A6064BD102419D06814DD0D78DE1129E303A@CIO-TNC-D2MBX02.osuad.osu.edu> References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129E2F59@CIO-TNC-D2MBX02.osuad.osu.edu> <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> In-Reply-To: <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.94.214] x-header-sapphire: true Content-Type: text/plain; charset="utf-8" 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)(7916002)(2980300002)(438002)(189002)(78114003)(199003)(88552002)(6116002)(102836003)(4326007)(8666005)(2906002)(55846006)(7596002)(7696003)(75432002)(86766002)(7846002)(50466002)(7736002)(2920100001)(2950100001)(2900100001)(8676002)(586003)(305945005)(93346002)(3846002)(106466001)(76176999)(246002)(106116001)(87936001)(626004)(50986999)(54356999)(356003)(86362001)(90282001)(109096001)(89122001)(8936002)(33656002)(16796002)(47776003)(93886004)(5250100002)(92566002)(11100500001)(66066001)(189998001)(110136002)(23676002)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR01MB2153; H:cio-krc-pf05.osuad.osu.edu; FPR:; SPF:Pass; PTR:cio-krc-pf05.osuad.osu.edu; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD018; 1:u+/ThthHzPeFqZhNntCFHyHR7Gl6BSoHYV6S7yKhEHbKxyOLsTQblGpwr4PQ7mCJxHd+y8YIMNaUoPKCAVNckhFWD7eZj5xMr87W35sqTy6T+ipkjCiGzTtdTJbh5cPAna/elv8oJzu3RsxRLSvyDwWeYB+oJgFg12/aRmjYeG2J4PSFmEGQ16Mz7mPAhFcPXrkEtAskgQp42WgqRBdZ4fglyHUeZ8yz9h9G5qt9TIWenouFKYHgyQGt6bN/TTfHBUBadVLBhDDG+LLhiWatCZA+9OVYiZ/sTQyeYXmILRG2hoJRuPXlXoAe3hEgoOYwpxC8Ft/Sji0CihuMmW40daUfpmBS8tDkkKD/CN6y/+9o8RVYGpq2PoEUp58rqjj4bm9KnzyrJ+5DAZp09wrEPJf4HvkWciqeL1suEJsjD1p3G6A0CeEGDaBo9Ezrqmng2Ww7Ss7GtnpI16Ow7UozZOrofuWBHhCjo0ysUe4Z7VjRd596Zyqy2OdFREHDOimBHPVsMSJfjt/gcXfjtz4ulUemHnfxq/AgZFDYF8s5nVY= X-MS-Office365-Filtering-Correlation-Id: 3d6f6abe-fe46-49d6-7cda-08d3c14bc70b X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB2153; 2:hBpxZWMa5hqfggnVv/haIdzM8kHan9NAGxlr9B8RCi8gjw+xxtGCpI6qYvkiOIJ4F4oRNrHBwkl5rDKpjcxVFWeAmvUPTUYOdadgO9vDg/2zwtWcrIbZMBgdmbGOGHisGBIDxmGzXpnUFSNTrPLn8Bn1cjv+GIvUVnkBBAbCtDYkyrEaPgxpc1sWsRDvL8h/; 3:nxKKdPo9nTjBpa550OzA//orIBJElDwMSNH/0bw+CCyaFO0xRf7+ONQE4CxoNA55Sa9VwwZuGGIRaDpAtUfxzPfddpY5GrlA/DlK5Em4b7khr3Dud9w9uBnVQZ/ozzuljrFpFWiRv/8r3f26yNr4ar7oZc6GslKH6qI1A6dwagO/wMe+4TbMxfl+VY3bR8a9LkSZrQHOYh+2agGpfrb143Y4/lIl1TayRQrir8P6PyfMm/75ISJDgm5qhqX5hLLq6H0pMvqzvEXiPRMfjm9HJw==; 25:LLJQBeOvrF09hxtjvdnW6W+Cu54bB4JR8FXPlImki4nBVjWeAaFabSH4nNw3JCVEhs6fRicoUOs6YySDKXLjbLK0jHdLjFRqWD08uH5YJYWvLidUu/ZISdL2/UcMS82g06PFx55/y3M7F5kTCn0nPISib8JRvdccyOF+vZfLTYYQOTOor4wlW0cPYeMCCGi3hmiTBgZZyY3ri85ZoInwsDMrrX3/klrezfmu9NZxOVv9RBoEfQKv+b+Pp1mH49T+5Br+sRDb5bwlvXrPxasZcHyT0Ca3BQ0XCJk7nPbH1QOoWWQojuUa9O/Zewdt+4oK9bezp+WU6HB+wXmbIRCeH19PnyQQ/pUTlrT9w4K5RNkNqSzljqNosi2fMjAjacXhZLomwqI4ONipTwlfaSvfBvdbOenDEitfYzRIEHVN7v0= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:CY1PR01MB2153; X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB2153; 31:EOMWCbd1vg0l9shXTSvEQLrGdLzBdK22ngruiqDZo0mVQYgTPph1z5oNusLrZi80qyZIUDVzplZnBOCc8EN4VBIBE3rab/hXCFTc9Zu5WsbDwEl0yLhX9ncHUJDradcEJvZ2VGA8kHrTScQv1mMj7xODPt3Wu5wpPh+qb0toAvnS7vnE/OyoRcGzu6eVw4/Tgtxtjp3iUQDBd7ErZM4zv835cORbwQXpPYUMcYHePKY=; 20:e4le2Agffrxgr2D6JcYc78MJs0aHDsYB4mmbIAvEdK97gpmN4OmTemNyVEZKpYImX6yVV9M6eCl+L3n+3u8fQinKKVqGsmJvrTVLJdcO4T9xvuHBeRpQsH7IGGGyCKG8HvN4Z/E0QMV8ye6QzvXRiHNDqLl1KERV49hJ3kwSjrEb/OcIFtdQFhYVpJ/FPsvJjTVve+gMoxcgRlTUJAhf9g2tz55Gm/kx7sMXnR0d7KPfJ7aOJiuypne8bUHKBYFgXmkIm9f92OXnkHU+89Zmh6AZVDxPpZOI9ggJmCabOvRGsCWCC2HMTzX77PnG8BqJWLQgHdCpxUyI9x6ElY3yehD/NVOQxsSlrRBmOY4ry19lFZQmrRwNDNZg0PckAEzKVmzToPhjR/M4dmqvdsYOe3agYpdMynBksI8T/FEP7vY8zAgXDtxJZyly5XF8MlTxuBmhTJEkYmmx4cyAtNws7cXgI7tNBNjoPrOFxBBXqZn6ketsA+ecrDbT89g1SpD5 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(5005006)(8121501046)(13023025)(13018025)(13016025)(13024025)(3002001)(10201501046); SRVR:CY1PR01MB2153; BCL:0; PCL:0; RULEID:; SRVR:CY1PR01MB2153; X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB2153; 4:KSuYwy2+w8CyqskMOXn4ui3vNsoJlYoO5N8Zy2Ck1AOhIZYHHoFIEf4xvsTvFbgud5EVJGCzkW2Dy2pio7aj/UvlzGYS0EqNrn0JpoQNOB507bxt0yme7EzNMji0dxF1iCJa3Cj+BZLLNtnDZiQuZ/7rHnIL7zLnNee0lHn60gBPBNDTCz9HC5pJ4R5E+4NPsFYG+FbAuYUlaCNtqNAU5g0M/UyHByw2PGq0RgTcK1MsnUfcqeJS7GXXyuBuNMJZRYxulmU2DDxQMEIcd3ZlvS2pGBGLhpJH5/488F4fQXIQprfcblf+mH6vpzqYkrLEoWgTw4BH7G5UGDVw8dqR7HC8gbzIrgMDEcA3M2Hm1hF1zBsKAAw0GG6jvjM0zcNP3zd9PgMk80WuWD9e2fewg/kK9rGmi/dskbXeW+h1Nf/gUmo+E7IugKO2EOtk4WpXSxoWVd1CtmgbBzzvpGDgDrFHqWYXo6nlHoyCNlyqbl4= X-Forefront-PRVS: 0030839EEE X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDWTFQUjAxTUIyMTUzOzIzOmwwZTdxYS9tdGNDbFU5MWRPNlVZNms4VGU0?= =?utf-8?B?WitFN3p6Y2FTT1ErSGZ2bkZnanZ3ZzJ2dWtQMlJqK0dvNVd6TDZENTQzVyt3?= =?utf-8?B?RXpEM2ptZmN5MDczbnk2NEd0NzZ4QURPZFRBY0pTUERPckRQaHNTN3VPWUZ1?= =?utf-8?B?VDhOTGJrU25leVZzRmhHTkNYRWgraUhXNWMxaG9DU0YreDBCQ1FMVHZVNHNF?= =?utf-8?B?VXFPQmROUC9nT3Zua3hIcG9Vd3JCbmUyVlhjV1RhSVZ0UzVlMi9iT2NEUjY2?= =?utf-8?B?SGF0bHNTa3JjNlF1M3JydWlSUVM4WVdSZkpacnBLODVUQ1habFI5WFhrT0Ev?= =?utf-8?B?OStsOUNRcUU4K3hNdmp0OEdJZE1uMU1TVFVCL2ZQejVsYk4zVDAzT3BrTVYx?= =?utf-8?B?dEtmWWU2alNCTlBmWDIyZktCd21HRmdhdE9rTTYxWXR0b2R2NFRITmhDQUUz?= =?utf-8?B?NThxN0MvL2Q2RWtLdlFJb29KYnF6dGNGRkIrM2F0c1BZcmE1czhwbUxBQUlm?= =?utf-8?B?eEJ6N2puNnZ3bFNRUDhNdjRWR2dqVUZGQktrNDdtWUg5UW5EbU02Sm5iRVAy?= =?utf-8?B?N0tpY3RSZ21mbFBONlNab3ZxQ0ZJSlZDMTRwVUlBTWl6UzBobXNYWTFRYmNw?= =?utf-8?B?c1ZNSE1aQnBoU3RWbGVzVFRibFF1TTdaMForWTV3enlzRDdkcE5kTDM0VTI4?= =?utf-8?B?QVNqMTFUTDRCT1p3aDFIQVVtVTlCNWFldVh6dXVZN2k2azNCL0pQTzRXc1Ir?= =?utf-8?B?cWNVa0htMVkzOVlRaEE5bVgzTjlyTVNPOEVpZjdQQnZwTHBmQ2lSdXpPMm1T?= =?utf-8?B?MDN2NS9FY1NUL0tBRTlQQ0trcldmWU1tZGdpbWZDbDV2WmxHRlRzK3BPZEsr?= =?utf-8?B?emRVZzhsLzZ0cUY0cHoyRFdXNmVEb29wOE5XSXA3K3duVTlUZVExYkxwWEh6?= =?utf-8?B?RUZqSS9QR2hSV1hrZ2RiYWdweFloSWJxamFOSEdZQ0FjZElyRTFqUnplWXRL?= =?utf-8?B?S2Iyc1JPZjRVVFgrdGl4WEk0aDJFQnZwdjZDV2ZNVEhFK3p3VkpjUUZ4SlR0?= =?utf-8?B?NVN5U3BmR3RvV0JBQ1Q0dVhUeTlQQXIrT1lWdm5tNWFYSk9BM0Fsb2pzTUpF?= =?utf-8?B?U0F3SE4vS2p6c0Fia04wWWx0SkdEaFU1bldobmNTRTE5S2NicWpXTjZmMnpU?= =?utf-8?B?NlpZRlV2SlZ5ZS9KOU8rUzAyR3YvNFhRYlpWSTB6b2cyc3BGN1FwYTNlV0Vw?= =?utf-8?B?RFZYSnlMRmdmYUd5MW9LTTdPSkdhdjZWRTdQMmZva2VoT1NyeXZ6cDBFOEo3?= =?utf-8?B?L0hiY21DM2Y2S2FwMVkzZGVwa3BCVFg3VGlVQThHYVdhc0w5bEI5TUkxN1dz?= =?utf-8?B?ak5MRXZtcDQ2RDd2bWRUN3pwSDJ1V09Fb1IrVFhWRGk0MnBtT1draTlrSGdy?= =?utf-8?B?ZHVieE9oNklhTVFOZGJtOStkNEZDNUxzd01UWit0d2YzYU02bW5Kend1ZVJS?= =?utf-8?B?Wk9aRlRaV0w3TFFOOU1lNEtLaTU0SXdsemQxakltWWlMaEdISWxNV1pEeUg5?= =?utf-8?B?NUJUcWFzbU96NjlqWlh2SWhRZVlPY1BwVi9QYVg3Z0MvTjNiMVdLc1dIbkxX?= =?utf-8?B?OEtjUkU0b3RvSnB3RUhMbnd5eTQ4R0U2SjRqNTJvK2s2d2V2em5ab0ZSbzRV?= =?utf-8?B?RFZPbVBIMmtNeWNoeVVudTdYL3VIdWQxbWlIZ21EQjRqZFJtbGVielVqd1Q0?= =?utf-8?Q?INzQElTnrLl/y5rYfXj6y9Rnae5TFklsPQqBM=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB2153; 6:b5ohJXFDX+x371+X9i3oTggBaPcmeuQoSIr7uqCbvDUv5aKmP4pb91VzpcwROj38sthtreNLtj7wIkqIDC2WoSOViqogo0b1d0shHJD0xKePnLUDXe6iEwqlNGE4D4VQy7R3F0V8fmbNnY41aKPknxAQaUKFL7S4W5CacbpEvFoE2qyrQt8lSpigJ19xx6eDqEwUz6qeL7oPPQ7ad4OWsBMm5/C0brEZct23vDvJpZZUzmi4OScjavKpgQVy1dS57s3/Tt17O15b4Yn0/iUMdeiHr/HXh2omFw9VI6MJ0MA=; 5:BLd5GnPWnQfp4j/9FNFeioPeXdBODFHBCGdlib3xTng6Acml5Z1tSLj5nBEHHI0EzW4uUAUcm/FadebD/TpjIPekYb4JYM68LSDpdsyMvLZNbkQXnpF5JBtTslXmuHP0M9Nev6xI3ryOPXm1hZQ+QA==; 24:ORzcBAisjmukWU8xYtltQJmmZT5zRWxB4Q1U+L6+9CFphQ+3/KNumI6HSF4NTAcJPW1auIxQ2QBXIl94twJ+hHez7lutgT0cS+HOVinTEJc=; 7:S+/x5VeedYigcuKMBInRpXs1PuCNiy/0THL5t05BEBfFS3u1oi3E8ceXg1PtEDI0GoMhAMfpdUotjKPINAGdT8pNyaLJflGB/dwzh2vchvX+gxtk43ndlLeE9FyYyZ9HfurYDJ+4bx5gdlauyNvQShZHhmni7m7ju3FLantyiLXXlJoACfcTXN3rqZqnfOlldQMLiYbj0vZ7kQsvxbentaO0NGPnQmhK4iDb94YbLkREmiyK2/7qEorNq+hqoMQk SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR01MB2153; 20:cQBiGr9YadpOyScN+nY0YuC+n+ZnIFGwIO5xLmIIQMwD9n7KDHDHbVDJzjO48C1jQ6/525qPlOdeHHvsuybRwH3rsSlk/MKeRsS7Fk5dHwZoGeWWPOb2+yKCuNF55hL7Ce1gxITGw4ktwHEudtTQZJ1jgh/rjWGPeDrYCRVo9TI= X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2016 18:25:59.4406 (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: CY1PR01MB2153 Archived-At: Cc: Andrei Popov , Subodh Iyengar , Dirk Balfanz , "Manger, James" , IETF Tokbind WG , Brian Campbell , Martin Thomson , Nick Harper Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 10 Aug 2016 18:26:02 -0000 PiBTY290dCwgYXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgdGhhdCBiZSBkb25lIG9uIGEgcGVyIGNv b2tpZSBiYXNpcywgb3IgYXMNCj4gc29tZXRoaW5nIHRoYXQgdGhlIHNlcnZlciB3b3VsZCBhZHZl cnRpc2UgaW4gc2F5IGEgaGVhZGVyIHRoYXQgd291bGQgYWxsb3cNCj4gdGhlIGJyb3dzZXIgdG8g bW9yZSB0aWdodGx5IHNjb3BlIGl0cyBiaW5kaW5ncy4NCg0KTm90IHBlci1jb29raWUgKHRoYXQg d291bGQgY291cGxlIHRoZSBsYXllcnMgaW50b2xlcmFibHkpLiBJJ20gc3VnZ2VzdGluZyBhIHNl cnZlciBkZXBsb3ltZW50IHRoYXQgd2FzIHVuZGVyc3Rvb2QgdG8gYmUgc2VydmluZyBvbmx5IGNv b2tpZXMgdGhhdCBhcmUgb3JpZ2luLXNjb3BlZCBjb3VsZCBiZSBjb25maWd1cmVkIHRvIG1hdGNo IHRoYXQgaW4gdGhlIFRva2VuQmluZGluZyBsYXllciBieSBhZHZlcnRpc2luZyB0aGF0IHRvIHRo ZSBjbGllbnQuIEkgd291bGQgYXNzdW1lIHRoYXQgd291bGQgYmUgaW4gdGhlIFRMUyBoYW5kc2hh a2UgYW5kIG5vdCBpbiBhbiBIVFRQIGhlYWRlciwgYnV0IEknbSBub3QgdmVyc2VkIGVub3VnaCB5 ZXQgdG8ga25vdyBpZiBhIGhlYWRlciB3b3VsZCB3b3JrLg0KDQo+IFRoYXQgd291bGQgYWxsb3cg dGhlIHNlcnZlciB0byBjb250cm9sIGl0LCBob3dldmVyIGl0IHJ1bnMgdGhlIHJpc2sgb2YgZGlm ZmVyZW50DQo+IHNlcnZlcnMgcHVibGlzaGluZyBjb25mbGljdGluZyBydWxlcyBhbmQgY2F1c2lu ZyBpc3N1ZXMuDQoNCklmIHlvdSBzZXJ2ZXJzIGluIGEgY29tbW9uIHBvb2wsIHN1cmUsIGJ1dCB0 aGF0J3MgYSBidWcuIFNlcnZlcnMgdGhhdCBhcmUgdW5yZWxhdGVkIHRvIGVhY2ggb3RoZXIgd291 bGQgYmUgc2lnbmFsaW5nIGEgZGlmZmVyZW50IGV4cGVjdGF0aW9uLg0KDQo+IENvbXBsZXRlbHkg c2NyYXBpbmcgZVRMRCsxIHNlZW1zIGxpa2UgaXQgd291bGQgaHVydCBkZXBsb3ltZW50Lg0KDQpE b24ndCB0aGluayBhbnlib2R5IGhhcyBzdWdnZXN0ZWQgdGhhdCwgYW5kIGlmIGl0IGdvZXMgZnVy dGhlciBhbmQgdHVybnMgb3V0IHRoYXQgZmVkZXJhdGVkIHRva2VucyBlc3NlbnRpYWxseSBkZW1h bmQgaXQsIHNvIGJlIGl0Lg0KDQo+IEJlY2F1c2UgUlNBIFRva2VuIGJpbmRpbmcgSUQgYXJlIHNv IGxhcmdlIHdlIGFyZSBwcm9iYWJseSBnb2luZyB0byBuZWVkIGENCj4gdGh1bWJwcmludCBvZiB0 aGVtIHRvIHB1dCBpbiB0b2tlbnMgdG8ga2VlcCB0aGUgc2l6ZSBmcm9tIGJsb3dpbmcgdXAuDQoN Cj4gTXkgcXVlc3Rpb24gaXMgcmVhbGx5IGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHdpdGggd2hh dD8gICBXb3VsZG4ndCBpdCBiZQ0KPiBiZXR0ZXIgdG8gbm90IHRyeSBhbmQgc3VwcG9ydCBSU0Eg YW5kIGdvIGFsbCBFQyBmcm9tIHRoZSBzdGFydC4gICBSU0Egc2VlbXMNCj4gdW5saWtlbHkgdG8g YmUgdXNlZCBpbiB0aGUgcmVhbCB3b3JsZCBhcyBhbG1vc3QgYWxsIG9mIHRoZSBpbmZyYXN0cnVj dHVyZSBpcyBuZXcNCj4gYW5kIEVDIGlzIHRoZSBiZXR0ZXIgY2hvaWNlLg0KDQpUaGlzIGlzIHRo ZSBFQyB0aGF0J3MgY29uc3RhbnRseSBjb21waWxlZCBvdXQgb2YgbGlicmFyaWVzIG9uIHBvcHVs YXIgTGludXggZGlzdHJvcyAodGhpcyBpcyBhZG1pdHRlZGx5IHdhbmluZykgYW5kIGlzIG1pc3Np bmcgZnJvbSBoYWxmIHRoZSBPcGVuSkRLIHBhY2thZ2VzIG91dCB0aGVyZT8NCg0KLS0gU2NvdHQN Cg0KDQo= From nobody Wed Aug 10 12:13:23 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 A681012D5E3 for ; Wed, 10 Aug 2016 12:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 i3A2J6f_nCMo for ; Wed, 10 Aug 2016 12:04:31 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0090.outbound.protection.outlook.com [104.47.37.90]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B91412D169 for ; Wed, 10 Aug 2016 12:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FP+FZqre8TKzCMSkrh842F4iwa8wkgwxErQZNzJIoHI=; b=WtpJZuBbyW0k9EZkhRAmWkVo4Oax7s3rHZ9wNkw+/iXyHn9e+5iLvASIjhekYTy2uSDmNhuDTaZU8m1UDYH8t+Eq9XVXgTCjWtz7+8tef3b7RkZ8Whyi/GmRDb7ZuehkKZctcscswt6PI0NtxFBT6ompqCpJbBKtvg3Fy6U+WVE= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2154.namprd03.prod.outlook.com (10.166.206.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 10 Aug 2016 19:04:23 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0549.025; Wed, 10 Aug 2016 19:04:23 +0000 From: Andrei Popov To: Bill Cox , John Bradley Thread-Topic: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) Thread-Index: AQHR8Ut8epZDh2EP4E+neKQPnf2Vr6A/GCOAgABGfQCAAAbiAIAAf3yAgAHuYQCAAKUE0IAAAl6AgAAJFICAAAjdAIAAAzLw Date: Wed, 10 Aug 2016 19:04:23 +0000 Message-ID: References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129E2F59@CIO-TNC-D2MBX02.osuad.osu.edu> <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:d::1d2] x-ms-office365-filtering-correlation-id: 33c6990a-3d1d-483f-d4fc-08d3c1512498 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2154; 6:kFrVkshHw4XOFb0rfSgsL8NKOHhd8IM/mN35fwf1ZowebhYdPNB9WytMOYm94dPqZNmwlFFjRITIX5e4aa/t5Q/XR6dXFxm+OxMpN3wdDS4CGn3Hl9WRUmHcvy6/Nmq3clC0/ojZ8MHvVPA6+L+gQh3k5VnqjV4wLS1eV4rf5SgywwZE0C2MfSfY5amPf4ml2XX5bIbzwrQ5Q48Qdi0EGeCDqj/uSUhMgHaAicLT/4rshYYNo2URJX7eOV92WQesPnAAO1DHzsRCQpUwpmFsJfiWlaAzCwBNZfbaJfibGnLojUy1rj8twUaLMsPG8+3fkxs391t0OsQ4koeKNw+Ldw==; 5:3p4OwVOieJRtO9km+wp6ij+VzT9N2nLb0Wc1RWYfOh5MSR89T0wgDOAk/GQeyzQnA3YLpnhXnXUL8AZOkrnEDJ5ZGpy2opqivL4QXdgZkqa4hB2azO1YqF/ClPkYTGAzhcR2m8HyWzrBdid/YbGZNg==; 24:yuJhTS//D+h5QWdGhtttqpTUu5qeK0eFEgwTGWA4BkL7xD4qBskSi8A616g5ngiNHxAI5m+nGByg84X8IJL5uYP2fkRWnU4QAFk+uQaoYxs=; 7:9jYqxM5McN/ZJXph9BRmH705pqmy9ONkDbVqHR2CGWkm3Woyz6UzWY8+6Mwq4hoON0bBZ9/iQ0AJvj2ExgQzISmJ82SRc97ziDWyUedCfwl5DSrXjbD6bSnKkFN40l+nYdAb5w+RUx4p7cfHmq37tND0v5aV2eC1X3MfAWr8lkXEsIlBdbpcL3eB05hKA2S9YhwtQc5/LufKqNYTAAl6IixyKOKbDuSbIiguCBl5mNfPVKsO8GzB3e4Fp0390p0D x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2154; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(67672495146484)(272811157607776)(211936372134217)(21748063052155)(92004823454550)(67441168502697); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2154; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2154; x-forefront-prvs: 0030839EEE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(46034005)(24454002)(199003)(4326007)(2906002)(5005710100001)(2950100001)(92566002)(10400500002)(10090500001)(2900100001)(8990500004)(77096005)(15975445007)(7696003)(3280700002)(87936001)(8666005)(7846002)(74316002)(7736002)(86362001)(3660700001)(86612001)(10290500002)(76176999)(50986999)(54356999)(105586002)(33656002)(189998001)(99286002)(19580405001)(76576001)(19580395003)(790700001)(102836003)(19609705001)(6116002)(19625215002)(101416001)(16236675004)(19300405004)(97736004)(122556002)(106116001)(106356001)(7416002)(8936002)(93886004)(5001770100001)(9686002)(81156014)(68736007)(8676002)(81166006)(11100500001)(5002640100001)(586003)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2154; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB2155AF3B82A4C8359FD7D7538C1D0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2016 19:04:23.8338 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2154 Archived-At: X-Mailman-Approved-At: Wed, 10 Aug 2016 12:13:21 -0700 Cc: Subodh Iyengar , Dirk Balfanz , Martin Thomson , Scott Cantor , IETF Tokbind WG , Brian Campbell , "Manger, James" , Nick Harper Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 10 Aug 2016 19:04:33 -0000 --_000_CY1PR03MB2155AF3B82A4C8359FD7D7538C1D0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG8gc3RlcCBiYWNrIGEgYml0LCBUQiBzcGVjcyBleHBsaWNpdGx5IGF2b2lkIHNwZWNpZnlpbmcg bWV0aG9kcyBvZiBiaW5kaW5nIHRva2VucywgYWx0aG91Z2ggdGhleSBkbyBwcm92aWRlIGV4YW1w bGVzIG9mIHdoYXQgY291bGQgYmUgZG9uZS4NCg0KRXZlbiBpZiB3ZSB3ZXJlIHRvIHByb2hpYml0 IFJTQSwgd2UgY2Fu4oCZdCBndWFyZCBhZ2FpbnN0IGEgZnV0dXJlIGFsZ29yaXRobSB0aGF0IHJl cXVpcmVzIGEgbG9uZyBrZXkuDQoNClRoZSBzaW1wbGUgc29sdXRpb24gaXMgdG8gaGFzaCB0aGUg VEIgSURzLCBhbmQgaXQgd29ya3MgcmVnYXJkbGVzcyBvZiB0aGUga2V5IHR5cGUuIEl0IGlzIGFs c28gcG9zc2libGUgdGhhdCBCaWxs4oCZcyBpZGVhIHdvdWxkIHdvcmssIGFzIGFuIGFsdGVybmF0 aXZlLiBCdXQgSU1ITyB0aGlzIGJlbG9uZ3MgaW4gYSBoaWdoZXItbGV2ZWwgc3BlYy4NCg0KQ2hl ZXJzLA0KDQpBbmRyZWkNCg0KRnJvbTogQmlsbCBDb3ggW21haWx0bzp3YXl3YXJkZ2Vla0Bnb29n bGUuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTAsIDIwMTYgMTE6NDcgQU0NClRvOiBK b2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPg0KQ2M6IFNjb3R0IENhbnRvciA8Y2FudG9y LjJAb3N1LmVkdT47IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+OyBT dWJvZGggSXllbmdhciA8c3Vib2RoQGZiLmNvbT47IERpcmsgQmFsZmFueiA8YmFsZmFuekBnb29n bGUuY29tPjsgTWFuZ2VyLCBKYW1lcyA8SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbT47 IElFVEYgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz47IEJyaWFuIENhbXBiZWxsIDxi Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT47IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20+OyBOaWNrIEhhcnBlciA8bmhhcnBlckBnb29nbGUuY29tPg0KU3ViamVjdDog UmU6IFtVbmJlYXJhYmxlXSBSZXZpc2l0IGVUTEQrMSAod2FzIFJlOiBzdXBwb3J0IGZvciBkaWZm ZXJlbnQga2V5IHBhcmFtZXRlcnMgd2l0aGluIHRoZSBzYW1lIFRMRCsxKQ0KDQpPbiBXZWQsIEF1 ZyAxMCwgMjAxNiBhdCAxMToxNSBBTSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxt YWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCkkgaGF2ZSBiZWVuIGxvb2tpbmcgYXQg dXNpbmcgVG9rZW4gQmluZGluZyBpbiBPQXV0aC4NCg0KQmVjYXVzZSBSU0EgVG9rZW4gYmluZGlu ZyBJRCBhcmUgc28gbGFyZ2Ugd2UgYXJlIHByb2JhYmx5IGdvaW5nIHRvIG5lZWQgYSB0aHVtYnBy aW50IG9mIHRoZW0gdG8gcHV0IGluIHRva2VucyB0byBrZWVwIHRoZSBzaXplIGZyb20gYmxvd2lu ZyB1cC4NCg0KVGhpcyBhZGRzIGNvbXBsZXhpdHkgb3ZlciBzYXlpbmcganVzdCBzZW5kIHRoZSB0 b2tlbiBiaW5kaW5nIElELg0KDQpNaW5pbWl6aW5nIHRva2VuIHNpemUgaXMgaW1wb3J0YW50LCBz byBJJ2QgcHJlZmVyIGp1c3QgdG8gaGF2ZSBhIDY0LWJpdCBmaW5nZXJwcmludCBpZiBwb3NzaWJs ZS4gIFRvIGRvIHRoYXQgd2l0aG91dCBjcmVhdGluZyB0aGUgcmlzayB0aGF0IGF0dGFja2VycyBj YW4gY3JlYXRlIGtleSBwYWlycyB0aGF0IGhhdmUgdGhlIHNhbWUgZmluZ2VycHJpbnQsIHlvdSBo YXZlIHRvIHJhbmRvbWl6ZSB0aGUgaGFzaGluZyB3aXRoIGEgc2VjcmV0IG9mIHNvbWUgc29ydC4g IElmIHRoaXMgZmluZ2VycHJpbnQgaXMgaW4gYW4gZW5jcnlwdGVkIHBvcnRpb24gb2YgYW4gb2F1 dGggdG9rZW4sIHRoZW4gdGhlIHJhbmRvbWl6YXRpb24ga2V5IGNhbiBiZSBkZXJpdmVkIGZyb20g dGhlIGRlY3J5cHRpb24ga2V5LCBvciBzb21ldGhpbmcgbGlrZSB0aGF0Lg0KDQpJZiB3ZSBpbnN0 ZWFkIHN0b3JlIHRoZSB1bmNvbXByZXNlZCBFQyBrZXlzLCBpdCB3aWxsIHRha2UgNjQtYnl0ZXMs IDhYIGxhcmdlciB0aGFuIHJlcXVpcmVkLg0KDQpKdXN0IHNvbWUgZG9tZSBicmFpbnN0b3JtaW5n OiB3aGF0IGlmIHdlIGVuY3J5cHRlZCB0aGUgb2F1dGggdG9rZW4gb3IgY29va2llIHVzaW5nIHRo ZSBzdGFuZGFyZCBlbmNyeXB0aW9uIGtleSBoYXNoZWQgd2l0aCB0aGUgVEIgcHVibGljIGtleT8g IFRoYXQgd2F5IHdlIHZlcmlmeSB0aGUgVEIga2V5IGJ5IHN1Y2Nlc3NmdWxseSBkZWNyeXB0aW5n IHRoZSB0b2tlbiwgd2l0aG91dCBpbmNyZWFzaW5nIHRoZSBzaXplIG9mIHRoZSBjb29raWUvdG9r ZW4gYXQgYWxsLiAgSSB0aGluayB0aGlzIGZhbGxzIHVuZGVyIHRoZSBjb25jZXB0IG9mIEFFQUQs IHdoZXJlIHRoZSBUQiBwdWJsaWMga2V5IGlzIHNpbXBseSAiYWRkaXRpb25hbCBkYXRhIi4NCg0K QmlsbA0K --_000_CY1PR03MB2155AF3B82A4C8359FD7D7538C1D0CY1PR03MB2155namp_ 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 IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvIHN0ZXAgYmFjayBhIGJpdCwgVEIgc3BlY3MgZXhwbGlj aXRseSBhdm9pZCBzcGVjaWZ5aW5nIG1ldGhvZHMgb2YgYmluZGluZyB0b2tlbnMsIGFsdGhvdWdo IHRoZXkgZG8gcHJvdmlkZSBleGFtcGxlcyBvZiB3aGF0IGNvdWxkIGJlIGRvbmUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkV2ZW4gaWYgd2Ugd2VyZSB0byBwcm9oaWJpdCBSU0EsIHdlIGNhbuKAmXQgZ3VhcmQg YWdhaW5zdCBhIGZ1dHVyZSBhbGdvcml0aG0gdGhhdCByZXF1aXJlcyBhIGxvbmcga2V5LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5UaGUgc2ltcGxlIHNvbHV0aW9uIGlzIHRvIGhhc2ggdGhlIFRCIElEcywgYW5k IGl0IHdvcmtzIHJlZ2FyZGxlc3Mgb2YgdGhlIGtleSB0eXBlLiBJdCBpcyBhbHNvIHBvc3NpYmxl IHRoYXQgQmlsbOKAmXMgaWRlYSB3b3VsZCB3b3JrLCBhcyBhbiBhbHRlcm5hdGl2ZS4gQnV0IElN SE8gdGhpcyBiZWxvbmdzDQogaW4gYSBoaWdoZXItbGV2ZWwgc3BlYy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJpbGwgQ294IFttYWlsdG86d2F5d2FyZGdlZWtAZ29v Z2xlLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAxMCwgMjAxNiAx MTo0NyBBTTxicj4NCjxiPlRvOjwvYj4gSm9obiBCcmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRiLmNv bSZndDs8YnI+DQo8Yj5DYzo8L2I+IFNjb3R0IENhbnRvciAmbHQ7Y2FudG9yLjJAb3N1LmVkdSZn dDs7IEFuZHJlaSBQb3BvdiAmbHQ7QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20mZ3Q7OyBTdWJv ZGggSXllbmdhciAmbHQ7c3Vib2RoQGZiLmNvbSZndDs7IERpcmsgQmFsZmFueiAmbHQ7YmFsZmFu ekBnb29nbGUuY29tJmd0OzsgTWFuZ2VyLCBKYW1lcyAmbHQ7SmFtZXMuSC5NYW5nZXJAdGVhbS50 ZWxzdHJhLmNvbSZndDs7IElFVEYgVG9rYmluZCBXRyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZn dDs7IEJyaWFuIENhbXBiZWxsDQogJmx0O2JjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tJmd0Ozsg TWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs7IE5pY2sgSGFy cGVyICZsdDtuaGFycGVyQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb VW5iZWFyYWJsZV0gUmV2aXNpdCBlVExEJiM0MzsxICh3YXMgUmU6IHN1cHBvcnQgZm9yIGRpZmZl cmVudCBrZXkgcGFyYW1ldGVycyB3aXRoaW4gdGhlIHNhbWUgVExEJiM0MzsxKTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBdWcgMTAs IDIwMTYgYXQgMTE6MTUgQU0sIEpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0 YkB2ZTdqdGIuY29tIiB0YXJnZXQ9Il9ibGFuayI+dmU3anRiQHZlN2p0Yi5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGhhdmUgYmVlbiBsb29raW5nIGF0IHVzaW5nIFRva2VuIEJpbmRpbmcgaW4gT0F1dGguPGJyPg0K PGJyPg0KQmVjYXVzZSBSU0EgVG9rZW4gYmluZGluZyBJRCBhcmUgc28gbGFyZ2Ugd2UgYXJlIHBy b2JhYmx5IGdvaW5nIHRvIG5lZWQgYSB0aHVtYnByaW50IG9mIHRoZW0gdG8gcHV0IGluIHRva2Vu cyB0byBrZWVwIHRoZSBzaXplIGZyb20gYmxvd2luZyB1cC48YnI+DQo8YnI+DQpUaGlzIGFkZHMg Y29tcGxleGl0eSBvdmVyIHNheWluZyBqdXN0IHNlbmQgdGhlIHRva2VuIGJpbmRpbmcgSUQuPG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5NaW5pbWl6aW5nIHRva2VuIHNpemUgaXMgaW1wb3J0YW50LCBzbyBJJ2QgcHJlZmVyIGp1c3Qg dG8gaGF2ZSBhIDY0LWJpdCBmaW5nZXJwcmludCBpZiBwb3NzaWJsZS4mbmJzcDsgVG8gZG8gdGhh dCB3aXRob3V0IGNyZWF0aW5nIHRoZSByaXNrIHRoYXQgYXR0YWNrZXJzIGNhbiBjcmVhdGUga2V5 IHBhaXJzIHRoYXQgaGF2ZSB0aGUgc2FtZSBmaW5nZXJwcmludCwgeW91IGhhdmUgdG8gcmFuZG9t aXplIHRoZSBoYXNoaW5nDQogd2l0aCBhIHNlY3JldCBvZiBzb21lIHNvcnQuJm5ic3A7IElmIHRo aXMgZmluZ2VycHJpbnQgaXMgaW4gYW4gZW5jcnlwdGVkIHBvcnRpb24gb2YgYW4gb2F1dGggdG9r ZW4sIHRoZW4gdGhlIHJhbmRvbWl6YXRpb24ga2V5IGNhbiBiZSBkZXJpdmVkIGZyb20gdGhlIGRl Y3J5cHRpb24ga2V5LCBvciBzb21ldGhpbmcgbGlrZSB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZSBpbnN0ZWFkIHN0b3JlIHRo ZSB1bmNvbXByZXNlZCBFQyBrZXlzLCBpdCB3aWxsIHRha2UgNjQtYnl0ZXMsIDhYIGxhcmdlciB0 aGFuIHJlcXVpcmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5KdXN0IHNvbWUgZG9tZSBicmFpbnN0b3JtaW5nOiB3aGF0IGlmIHdlIGVuY3J5 cHRlZCB0aGUgb2F1dGggdG9rZW4gb3IgY29va2llIHVzaW5nIHRoZSBzdGFuZGFyZCBlbmNyeXB0 aW9uIGtleSBoYXNoZWQgd2l0aCB0aGUgVEIgcHVibGljIGtleT8mbmJzcDsgVGhhdCB3YXkgd2Ug dmVyaWZ5IHRoZSBUQiBrZXkgYnkgc3VjY2Vzc2Z1bGx5IGRlY3J5cHRpbmcgdGhlIHRva2VuLCB3 aXRob3V0IGluY3JlYXNpbmcgdGhlIHNpemUNCiBvZiB0aGUgY29va2llL3Rva2VuIGF0IGFsbC4m bmJzcDsgSSB0aGluayB0aGlzIGZhbGxzIHVuZGVyIHRoZSBjb25jZXB0IG9mIEFFQUQsIHdoZXJl IHRoZSBUQiBwdWJsaWMga2V5IGlzIHNpbXBseSAmcXVvdDthZGRpdGlvbmFsIGRhdGEmcXVvdDsu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJp bGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR03MB2155AF3B82A4C8359FD7D7538C1D0CY1PR03MB2155namp_-- From nobody Wed Aug 10 12:15: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 47BBE12D0E7 for ; Wed, 10 Aug 2016 11:47:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.247 X-Spam-Level: X-Spam-Status: No, score=-3.247 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, RP_MATCHES_RCVD=-1.247, 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 ivmAx4UYQKCZ for ; Wed, 10 Aug 2016 11:47:30 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 AE1BE12B03A for ; Wed, 10 Aug 2016 11:47:30 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 74so84603355uau.0 for ; Wed, 10 Aug 2016 11:47:30 -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=IyGDcewivcuXXx2GWOGLmjYpMN4VO4CYR7ze6tzDeDg=; b=id+wGuLss5G77lh37u9Ial+0FvqfDh+GBvJZ036h+RMR9XiU+swYvun7eaGQB4VO8x VogW7U75+HCccMlAf70dgL4qNVjORssB8ZVno2SEpdangRgbTB9+4z4UbqhGQZdPr7eY fOTtq9YFpuIVacU+gkFa3eFVanyOd0iXgYSXcDl8+bXuxLMdOtFyN7/rb8emvHFNK9wd NtCY/vUS2XIGO+GbOXwdth+W5SKnL0dkM2cCb15cg/xfRGedkUPr3+KOlCkJsZrMbMUq weyQzrR7Nw4WEQd6i/xOBJlU0dqXNPyZ6eW8XBJc2MDY4o3JaNvR2TW70SgKcGN3baAb abNA== 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=IyGDcewivcuXXx2GWOGLmjYpMN4VO4CYR7ze6tzDeDg=; b=Hc61/WhKx6hJlEf3xvqQlukZkCXveZq5LhjWCNiCwRaSaswIh9dcXKzI0WWuzzsBiF 3vL1R1T/zH01M28uzIs0qOFU0RO7yrE007AU8i8IKCQU/fbgq5ZwkAOYFaOYc5r26d/6 xAa+K7BGQT1fHgN0nEIs8/o1J5tYnfL9u+FXhSFz1Dab7oCuylNJM1iw/5Q0nXumX1Ky WPSGeL7m2L7vhr0icr42QOFHJ1fD8LgUOEYf1mcxnmNo2DT3X+Yp+vJxCmEPjkgUm/u2 ltRQGstJC94CvSKr5IfKyzNPWL3kvzUwq/0choIsOR21bBvgBXBlxdGM1UO2foCB2QUk XHxg== X-Gm-Message-State: AEkoousSsHYAe/XjmIDO3PfhZYZUF8hHXgKZm0wi+TThjuvSFE3kFMLPXuX0Zv/NXAc0RwNBiyIVru+4ZmhvD0oF X-Received: by 10.31.185.9 with SMTP id j9mr2775029vkf.144.1470854849641; Wed, 10 Aug 2016 11:47:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.97.2 with HTTP; Wed, 10 Aug 2016 11:47:28 -0700 (PDT) In-Reply-To: <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129E2F59@CIO-TNC-D2MBX02.osuad.osu.edu> <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> From: Bill Cox Date: Wed, 10 Aug 2016 11:47:28 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a11439cbcd494220539bc149a Archived-At: X-Mailman-Approved-At: Wed, 10 Aug 2016 12:14:58 -0700 Cc: Andrei Popov , Subodh Iyengar , Dirk Balfanz , Martin Thomson , Scott Cantor , IETF Tokbind WG , Brian Campbell , "Manger, James" , Nick Harper Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 10 Aug 2016 18:47:32 -0000 --001a11439cbcd494220539bc149a Content-Type: text/plain; charset=UTF-8 On Wed, Aug 10, 2016 at 11:15 AM, John Bradley wrote: > I have been looking at using Token Binding in OAuth. > > Because RSA Token binding ID are so large we are probably going to need a > thumbprint of them to put in tokens to keep the size from blowing up. > > This adds complexity over saying just send the token binding ID. > Minimizing token size is important, so I'd prefer just to have a 64-bit fingerprint if possible. To do that without creating the risk that attackers can create key pairs that have the same fingerprint, you have to randomize the hashing with a secret of some sort. If this fingerprint is in an encrypted portion of an oauth token, then the randomization key can be derived from the decryption key, or something like that. If we instead store the uncompresed EC keys, it will take 64-bytes, 8X larger than required. Just some dome brainstorming: what if we encrypted the oauth token or cookie using the standard encryption key hashed with the TB public key? That way we verify the TB key by successfully decrypting the token, without increasing the size of the cookie/token at all. I think this falls under the concept of AEAD, where the TB public key is simply "additional data". Bill --001a11439cbcd494220539bc149a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 10, 2016 at 11:15 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I have been looking at using To= ken Binding in OAuth.

Because RSA Token binding ID are so large we are probably going to need a t= humbprint of them to put in tokens to keep the size from blowing up.

This adds complexity over saying just send the token binding ID.

Minimizing token size is important, so I'd pr= efer just to have a 64-bit fingerprint if possible.=C2=A0 To do that withou= t creating the risk that attackers can create key pairs that have the same = fingerprint, you have to randomize the hashing with a secret of some sort.= =C2=A0 If this fingerprint is in an encrypted portion of an oauth token, th= en the randomization key can be derived from the decryption key, or somethi= ng like that.

If we instead store the uncompresed = EC keys, it will take 64-bytes, 8X larger than required.

Just some dome brainstorming: what if we encrypted the oauth token o= r cookie using the standard encryption key hashed with the TB public key?= =C2=A0 That way we verify the TB key by successfully decrypting the token, = without increasing the size of the cookie/token at all.=C2=A0 I think this = falls under the concept of AEAD, where the TB public key is simply "ad= ditional data".
=C2=A0
Bill
--001a11439cbcd494220539bc149a-- From nobody Wed Aug 10 12:31: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 6723D12D621 for ; Wed, 10 Aug 2016 12:31:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 NS8TCZeRIany for ; Wed, 10 Aug 2016 12:30:58 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 50F4B12D600 for ; Wed, 10 Aug 2016 12:30:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 543CCF545; Wed, 10 Aug 2016 22:30:57 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id kbVWbtuiUBsL; Wed, 10 Aug 2016 22:30:56 +0300 (EEST) Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id AC70027F; Wed, 10 Aug 2016 22:30:56 +0300 (EEST) Date: Wed, 10 Aug 2016 22:30:49 +0300 From: Ilari Liusvaara To: Bill Cox Message-ID: <20160810193049.6oohzvqpmzq66whe@LK-Perkele-V2.elisa-laajakaista.fi> References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129E2F59@CIO-TNC-D2MBX02.osuad.osu.edu> <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.2-neo (2016-07-23) Sender: ilariliusvaara@welho.com Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 10 Aug 2016 19:31:00 -0000 On Wed, Aug 10, 2016 at 11:47:28AM -0700, Bill Cox wrote: > On Wed, Aug 10, 2016 at 11:15 AM, John Bradley wrote: > > Just some dome brainstorming: what if we encrypted the oauth token or > cookie using the standard encryption key hashed with the TB public key? > That way we verify the TB key by successfully decrypting the token, without > increasing the size of the cookie/token at all. I think this falls under > the concept of AEAD, where the TB public key is simply "additional data". Those two ideas are rather different. One could stick the TB into key derivation (having key derivation is also useful to expand the often-anemic nonces spaces of various AEADs (12 octets isn't even remotely enough)). Or one could stick the TB as associated data (but if one doesn't have key derivation, using AEADs safely is rather hard, MRAEs are another matter). In both cases, if TB doesn't match, you get decryption failure, and neither expands cookie beyond what the standard encryption would do. Analogs to both ideas also work with VecMACs, if one does not need encryption. -Ilari From nobody Wed Aug 10 13:03:25 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 0F61812B042 for ; Wed, 10 Aug 2016 13:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 MrswwblnopaJ for ; Wed, 10 Aug 2016 13:03:22 -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 DECE912D63E for ; Wed, 10 Aug 2016 13:03:21 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id l2so54789559qkf.3 for ; Wed, 10 Aug 2016 13:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=ztZ5IJkrLhTk6aMzGSgfQ0J4HKZlJORvUmgMnVLdTMw=; b=vGDeGWLGP6Cne9AzZMaDojIwJduxmrNsiJUZs+E1ESKtLqrWJlFuQLmTT8h0xihHoO 1psVfzicAnjHmcBAwVjAW5fe9pXQktxSnB46ZCrcwKUslyKOkvrldec2x1E5J0SAB/TQ 6S7yAYog+j0YJjdQvG9avUoInt/UurKlq/m5XUH2eBbTlR+EvYuhMerst7d6tNT9Yjqa jdDSvdEwXNQoLWjSlN6dXKBZWYlTjS87f9aS9vn1iCAOi4eAmgnZubNFBfM7mrx1FHzF CeY4+6UYOKdGNpZnC+3azKQRZsj1qTCEk4cd/8NPCnhJJbmHGny2oS9jdgRGvVOZd4zt rfAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=ztZ5IJkrLhTk6aMzGSgfQ0J4HKZlJORvUmgMnVLdTMw=; b=lB90FLop3KC3pAzycUgFqz2uOIeF7TG+9UGl5oyFE0q278cst5Qmw1EK+6q4jKL4pR SR5uSkh7kTkZAZ0bLd5nUiHqhtGyy6cHdKTrFflgffNWbq/oTBqGWGCq3YvbAtPxc1tp QMRYqqDwIy/r/2RXFhfWFnN0Jr+2/0CYO+C8+xtiUbqbT3+sgUAKhpc3VVbzfip35viF W/GgpKfJm8tUjlNth+zazogByj5YNmQ57U/58wtI99ZdO7B2hflzArVb92POmZVL1djt QMkw6iMnAyi93KVRVpcUEHi3HgvhH2r97iPQCNFgoldvRldFCzrhEIfDSLdVRpmgBTOh j9Tg== X-Gm-Message-State: AEkooutO6zQNY2mx0db2L8E6iYAqYz18ogVy9Cgyy1ZCNx+McXfFsN447uJUlXe69N0LIYmR X-Received: by 10.55.140.4 with SMTP id o4mr6367854qkd.81.1470859400737; Wed, 10 Aug 2016 13:03:20 -0700 (PDT) Received: from [192.168.8.100] ([181.201.39.111]) by smtp.gmail.com with ESMTPSA id o131sm7192915qke.20.2016.08.10.13.03.19 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Aug 2016 13:03:20 -0700 (PDT) From: John Bradley Content-Type: multipart/alternative; boundary="Apple-Mail=_982114EB-7C0F-4D94-8400-4EAE2DA02188" Message-Id: <938E6A25-A3E0-4EE4-8FEA-53B8DFDA8420@ve7jtb.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Date: Wed, 10 Aug 2016 16:03:17 -0400 References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129E2F59@CIO-TNC-D2MBX02.osuad.osu.edu> <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> To: IETF Tokbind WG In-Reply-To: X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 10 Aug 2016 20:03:24 -0000 --Apple-Mail=_982114EB-7C0F-4D94-8400-4EAE2DA02188 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The representation of the token binding ID in a OAuth Token or ID_Token = would be a higher level spec. We did introduce those to the OAuth WG. I think it was you or Dirk that argued that we should keep it simple and = just pass the whole opaque token binding ID both in the token and when = we needed to refer to it in a parameter. In those specs we initially defined a SHA 256 thumbprint of the token = binding ID. To carry as a claim for the proof of possession. For cookies using the token binding_id as part of the encryption or = signing key via key derivation seems like a reasonable approach for long = keys.=20 For OAuth there are downsides to using and maintaining symmetric keys. = Signing the tokens with asymmetric keys has big advantages in = simplifying key distribution and rotation. I think carrying some representation of the key in the token will be = required for a good number of the use cases. However the encryption idea is interesting for cookies. So Andre, I take it that you think dropping RSA at this point is not = worth it as we are going to want to have short representations of keys = in the higher level specs anyway? We are currently recommending that servers support both RSA and EC. =20 Are we thinking that some clients would only be able to support RSA? I am guessing that browsers will all have EC and I suspect Windows and = CroNet will have EC. So yes I am being provocative, but I would like to have a answer that = the WG has thought through on the list about why we are doing RSA before = we get to the IESG and someone asks the question. John B. > On Aug 10, 2016, at 3:04 PM, Andrei Popov = wrote: >=20 > To step back a bit, TB specs explicitly avoid specifying methods of = binding tokens, although they do provide examples of what could be done. > =20 > Even if we were to prohibit RSA, we can=E2=80=99t guard against a = future algorithm that requires a long key. > =20 > The simple solution is to hash the TB IDs, and it works regardless of = the key type. It is also possible that Bill=E2=80=99s idea would work, = as an alternative. But IMHO this belongs in a higher-level spec. > =20 > Cheers, > =20 > Andrei > =20 > From: Bill Cox [mailto:waywardgeek@google.com]=20 > Sent: Wednesday, August 10, 2016 11:47 AM > To: John Bradley > Cc: Scott Cantor ; Andrei Popov = ; Subodh Iyengar ; Dirk = Balfanz ; Manger, James = ; IETF Tokbind WG = ; Brian Campbell ; = Martin Thomson ; Nick Harper = > Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for = different key parameters within the same TLD+1) > =20 > On Wed, Aug 10, 2016 at 11:15 AM, John Bradley > wrote: > I have been looking at using Token Binding in OAuth. >=20 > Because RSA Token binding ID are so large we are probably going to = need a thumbprint of them to put in tokens to keep the size from blowing = up. >=20 > This adds complexity over saying just send the token binding ID. > =20 > Minimizing token size is important, so I'd prefer just to have a = 64-bit fingerprint if possible. To do that without creating the risk = that attackers can create key pairs that have the same fingerprint, you = have to randomize the hashing with a secret of some sort. If this = fingerprint is in an encrypted portion of an oauth token, then the = randomization key can be derived from the decryption key, or something = like that. > =20 > If we instead store the uncompresed EC keys, it will take 64-bytes, 8X = larger than required. > =20 > Just some dome brainstorming: what if we encrypted the oauth token or = cookie using the standard encryption key hashed with the TB public key? = That way we verify the TB key by successfully decrypting the token, = without increasing the size of the cookie/token at all. I think this = falls under the concept of AEAD, where the TB public key is simply = "additional data". > =20 > Bill --Apple-Mail=_982114EB-7C0F-4D94-8400-4EAE2DA02188 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 The representation of the token binding ID in a OAuth Token = or ID_Token would be a higher level spec.  We did introduce those = to the OAuth WG.

I = think it was you or Dirk that argued that we should keep it simple and = just pass the whole opaque token binding ID both in the token and when = we needed to refer to it in a parameter.

In those specs we initially defined a = SHA 256 thumbprint of the token binding ID.  To carry as a claim = for the proof of possession.

For cookies using the token binding_id = as part of the encryption or signing key via key derivation seems like a = reasonable approach for long keys. 

For OAuth there are downsides to using = and maintaining symmetric keys.   Signing the tokens with = asymmetric keys has big advantages in simplifying key distribution and = rotation.

I = think carrying some representation of the key in the token will be = required for a good number of the use cases.

However the encryption idea is = interesting for cookies.

So Andre,  I take it that you think dropping RSA at this = point is not worth it as we are going to want to have short = representations of keys in the higher level specs anyway?

We are currently = recommending that servers support both RSA and EC.  

Are we thinking that = some clients would only be able to support RSA?

I am guessing that browsers will all = have EC and I suspect Windows and CroNet will have EC.

So yes I am being = provocative, but I would like to have a answer that the WG has thought = through on the list about why we are doing RSA before we get to the IESG = and someone asks the question.

John B.
On Aug 10, 2016, at 3:04 PM, = Andrei Popov <Andrei.Popov@microsoft.com> wrote:

To= step back a bit, TB specs explicitly avoid specifying methods of = binding tokens, although they do provide examples of what could be = done.
 
Even if we were to = prohibit RSA, we can=E2=80=99t guard against a future algorithm that = requires a long key.
 
The simple solution is to hash the TB IDs, and = it works regardless of the key type. It is also possible that Bill=E2=80=99= s idea would work, as an alternative. But IMHO this belongs in a = higher-level spec.
 
Cheers,
 
Andrei
 
From: Bill Cox [mailto:waywardgeek@google.com] 
Sent: Wednesday, August 10, 2016 = 11:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: Scott Cantor <cantor.2@osu.edu>; = Andrei Popov <Andrei.Popov@microsoft.com>; Subodh Iyengar <subodh@fb.com>; Dirk = Balfanz <balfanz@google.com>; Manger, James <James.H.Manger@team.telstra.com>; IETF Tokbind WG = <unbearable@ietf.org>; Brian Campbell <bcampbell@pingidentity.com>; Martin Thomson <martin.thomson@gmail.com>; Nick Harper <nharper@google.com>
Subject: Re: [Unbearable] Revisit = eTLD+1 (was Re: support for different key parameters within the same = TLD+1)
 
On = Wed, Aug 10, 2016 at 11:15 AM, John Bradley <ve7jtb@ve7jtb.com> = wrote:
I = have been looking at using Token Binding in OAuth.

Because RSA Token binding ID are so large we are probably = going to need a thumbprint of them to put in tokens to keep the size = from blowing up.

This adds complexity over = saying just send the token binding ID.
 
Minimizing token size = is important, so I'd prefer just to have a 64-bit fingerprint if = possible.  To do that without creating the risk that attackers can = create key pairs that have the same fingerprint, you have to randomize = the hashing with a secret of some sort.  If this fingerprint is in = an encrypted portion of an oauth token, then the randomization key can = be derived from the decryption key, or something like that.
 
If we instead store the uncompresed EC = keys, it will take 64-bytes, 8X larger than required.
 
Just some dome brainstorming: what if we = encrypted the oauth token or cookie using the standard encryption key = hashed with the TB public key?  That way we verify the TB key by = successfully decrypting the token, without increasing the size of the = cookie/token at all.  I think this falls under the concept of AEAD, = where the TB public key is simply "additional data".
 
Bill

= --Apple-Mail=_982114EB-7C0F-4D94-8400-4EAE2DA02188-- From nobody Wed Aug 10 14:40: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 DED2D12D0DF for ; Wed, 10 Aug 2016 14:40:03 -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 7TWWeittpb6J for ; Wed, 10 Aug 2016 14:40:02 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 82C3612D88E for ; Wed, 10 Aug 2016 14:40:02 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id x130so57540994ite.1 for ; Wed, 10 Aug 2016 14:40:02 -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=hTbH51ZczLZrm4tQdL9lVfN2BYBgJXt7mwoEQKH9kmQ=; b=QZLtcZzmlE1vFNWz8Wr1fxhTFL2Pz4OwfLwYkcGrZWjAgyqNzT9GJVk0fI/sZ6EdeW EI66hhAUycQq1g0gc0z8RsRZJWAlvvzW6+PYrSkpKsTAYWuUVceJqyUaE09us1oAwLH6 slSuA3ghqD+W0jhZlb9CvTnjgruIPigjYP1Y0= 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=hTbH51ZczLZrm4tQdL9lVfN2BYBgJXt7mwoEQKH9kmQ=; b=PlzQ3gDsB69zdtN2uzxL57fe6Tg+fqj1pvU/wZqN35Xij3hy8UwJ/r56lpH0GtgoXc zhi60U4M4kvkP14KVanaphRkr82aMePdB01iqp4F2DWOR8PaMk1lzSsp/Z0phW54KBdr XlrJ0i+wJjtKks2UZWwpKzygvB1yHUNKASjOf6cVhWg/h9I8Sbt9/BpWrO9IWOIGvAfK u2njF6BjDwW/bP8yVz7NtJKamyR7RcpASgVywrTArzNEzipSl7BKs6DquKkdEWHC3TjL SWTSnwJax5e9cwjr9ygtzXLCr4Q5Zpu2ZfoxJd6zzyKMhkPaFn7d1Uf8p/46rEVuhmNa dl9A== X-Gm-Message-State: AEkoout1WRY32RnbqttWEjKTaVnDHE3WjrgstfloNmdiKIhF2AhrdfFeG3G/SdlUqpy38cV69DkpCllwMC1VnOxu X-Received: by 10.36.206.129 with SMTP id v123mr6030683itg.11.1470865201826; Wed, 10 Aug 2016 14:40:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Wed, 10 Aug 2016 14:39:31 -0700 (PDT) In-Reply-To: <9846A6064BD102419D06814DD0D78DE1129E303A@CIO-TNC-D2MBX02.osuad.osu.edu> References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129E2F59@CIO-TNC-D2MBX02.osuad.osu.edu> <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> <9846A6064BD102419D06814DD0D78DE1129E303A@CIO-TNC-D2MBX02.osuad.osu.edu> From: Brian Campbell Date: Wed, 10 Aug 2016 15:39:31 -0600 Message-ID: To: "Cantor, Scott" Content-Type: multipart/alternative; boundary=94eb2c0af9fcde323f0539be7d0d Archived-At: Cc: Andrei Popov , Subodh Iyengar , Dirk Balfanz , "Manger, James" , IETF Tokbind WG , John Bradley , Martin Thomson , Nick Harper Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 10 Aug 2016 21:40:04 -0000 --94eb2c0af9fcde323f0539be7d0d Content-Type: text/plain; charset=UTF-8 On Wed, Aug 10, 2016 at 12:25 PM, Cantor, Scott wrote: > > > Completely scraping eTLD+1 seems like it would hurt deployment. > > Don't think anybody has suggested that, > I believe that is the very suggestion that started this thread (also issue #69 ) and is what I and a few others are pushing back on. --94eb2c0af9fcde323f0539be7d0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 10, 2016 at 12:25 PM, Cantor, Scott <cantor.2= @osu.edu> wrote:

> Completely scraping eTLD+1 seems like it would hurt deployment.

Don't think anybody has suggested that,

I believe that is the very suggestion that started= this thread (also issue #69) and is what I and a few othe= rs are pushing back on.
=C2=A0
--94eb2c0af9fcde323f0539be7d0d-- From nobody Wed Aug 10 14:44: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 29B3612B04F for ; Wed, 10 Aug 2016 14:44: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 W9Wb40GsWYNN for ; Wed, 10 Aug 2016 14:44:35 -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 C881F126579 for ; Wed, 10 Aug 2016 14:44:35 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id b62so54372944iod.3 for ; Wed, 10 Aug 2016 14:44: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=boz+YxnVD+cB23WO1HBAQFAHV6QIUdtFafqdlCUXyvk=; b=cfn7Sbe63CgVcEVAoPt/g87IpoAZnJoH0Ef0PdlNVUBUQi5EhjeAtqq1LrAw+IZ1Gf g0l/HB572RRX0sg4wqAYbd/FOhYelq9DuVLAyYDGiHVx46mKPX6FJBCTk1L1pJelyILa /NB+RfzX2NEfBvk9PItYfuV+D45UUJntYJfnE= 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=boz+YxnVD+cB23WO1HBAQFAHV6QIUdtFafqdlCUXyvk=; b=mNdgOfbrKGFQ/PyVOos+OyB7zq0EwgR6HO8Uj5UuJ4X6QIMqe7NCEpsXy9Y5LnuOW4 mX4vbVItF5A/JyYPjSZOpCY9Q+AUIlKkc9ts0SLxkw1WtwhnndhyfXi4SIv5LSTRjuDn nkWa7/V+UNM1amKcpRGE2rNt2ikUTH1YMW9NhQU6xvAXMNobShUjQorogFsjl0uPjYOV rI5PXdhXZ12uucefJ+3ZJ0wv9NjjzzGsC9wzlbX79jwciudf68TZBFzl+novKZhIwLtq 5pFRTlgNUSZ9LJ8fgY9Vmq19e6Sn04tAkfEQ8ci2qasgddbwu2is1NXhVL9DZQdMx06m 1x1g== X-Gm-Message-State: AEkoouumxxs4Tui66DqZwSumQ2jEwWvNV8Y7XVczI5Igz9e0agLr6+iD6TurI0eKUTfi1lgsoVnS+TkSKdanmPaf X-Received: by 10.107.8.94 with SMTP id 91mr7595981ioi.86.1470865475216; Wed, 10 Aug 2016 14:44:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Wed, 10 Aug 2016 14:44:04 -0700 (PDT) In-Reply-To: <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129E2F59@CIO-TNC-D2MBX02.osuad.osu.edu> <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> From: Brian Campbell Date: Wed, 10 Aug 2016 15:44:04 -0600 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a113f3a8829c5260539be8ea9 Archived-At: Cc: Andrei Popov , Subodh Iyengar , Dirk Balfanz , "Manger, James" , Scott Cantor , IETF Tokbind WG , Martin Thomson , Nick Harper Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 10 Aug 2016 21:44:37 -0000 --001a113f3a8829c5260539be8ea9 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 10, 2016 at 12:15 PM, John Bradley wrote: > No Hat > > Scott, are you suggesting that that be done on a per cookie basis, or as > something that the server would advertise in say a header that would allow > the browser to more tightly scope its bindings. > > It might be possible to have a default exact match but have a flag that > the browser could check to see if it should use eTLD+1. > > That would allow the server to control it, however it runs the risk of > different servers publishing conflicting rules and causing issues. > > Completely scraping eTLD+1 seems like it would hurt deployment. > > How do people feel about a configuration flag of some sort for the server > and having a default. > > Thoughts? > I'm pretty squarely in the eTLD+1 is just fine camp. But I wouldn't be opposed to exploring something like this, which I think might have to happen during negotiation. --001a113f3a8829c5260539be8ea9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 10, 2016 at 12:15 PM, John Bradley <ve7jtb@ve7jtb.com&= gt; wrote:
No H= at

Scott, are you suggesting that that be done on a per cookie basis, or as so= mething that the server would advertise in say a header that would allow th= e browser to more tightly scope its bindings.

It might be possible to have a default exact match but have a flag that the= browser could check to see if it should use eTLD+1.

That would allow the server to control it, however it runs the risk of diff= erent servers publishing conflicting rules and causing issues.

Completely scraping eTLD+1 seems like it would hurt deployment.

How do people feel about a configuration flag of some sort for the server a= nd having a default.

Thoughts?

I'm pretty squarely in the eTLD+1 is= just fine camp. But I wouldn't be opposed to exploring something like = this, which I think might have to happen during negotiation.
=C2=A0
=
--001a113f3a8829c5260539be8ea9-- From nobody Wed Aug 10 15:07: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 E4EB812D869 for ; Wed, 10 Aug 2016 15:07: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 8yaGEjoEAH7i for ; Wed, 10 Aug 2016 15:07:30 -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 9FB5712D83A for ; Wed, 10 Aug 2016 15:07:30 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id m101so54825528ioi.2 for ; Wed, 10 Aug 2016 15:07:30 -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=JEWfoiwAhVfEvazrhFrDq3rymQbFG5k96ZVfXYpn0rE=; b=BosOKVrf0Vo1uZ87mrdlnEPQcXu35ieAYUuSW/GTxyehS8UmrR/9mqGfpDjqW2p3eC LYrwgscns5b8xutIufdguQql2dWuKGXWosvtDg7Ty3SsQr/uPClbgeS8OBCjG2dscifl 6A+cThh3vN6qkrGdXXyz0rXp2/Uue4hq9XM6w= 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=JEWfoiwAhVfEvazrhFrDq3rymQbFG5k96ZVfXYpn0rE=; b=EsaUJfQVm094x3bCGJy2VKBCq76v9tfkmQ4SncxFnFv3XVgXKOR1bDL/XilAJ9m8g3 2xH4D5+j2KjiUNMLhvr2a5NSXE6Q+hu7zmsDAGvG7R3AJeI4ayqsgC6L2S5Nrv5luI8S NXjKll1Jz+WM+g604TOpX4rWZ/p8qS6/d40xEj1jDuH1SeEasiIS0co1Z93mid60t9/d eYeLChLrKO7gw0yOlD47hwKlMuHVwlAeh/P27US+vKwx1SHyliaDo/4KWKko26ObvfmZ gqhE2HaIgNrgz5T9Vak/+HmL55JOpKDRzDyjc1GOQImJXxNCyvcPYwieaOf9vkNu6X7u IjHA== X-Gm-Message-State: AEkooutEplavsTmdnP04NYtP1H7bosbRtHkwxEa5ChyZBBaDWsoYMVqhLztSJ54d/HImB+GDbEyUUpIK0GpH+4Rw X-Received: by 10.107.50.19 with SMTP id y19mr7650690ioy.174.1470866849963; Wed, 10 Aug 2016 15:07:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Wed, 10 Aug 2016 15:06:59 -0700 (PDT) In-Reply-To: References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129E2F59@CIO-TNC-D2MBX02.osuad.osu.edu> <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> From: Brian Campbell Date: Wed, 10 Aug 2016 16:06:59 -0600 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a114469c41ab8830539bee0d1 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 10 Aug 2016 22:07:32 -0000 --001a114469c41ab8830539bee0d1 Content-Type: text/plain; charset=UTF-8 +1 On Wed, Aug 10, 2016 at 1:04 PM, Andrei Popov wrote: > > The simple solution is to hash the TB IDs, and it works regardless of the > key type. > --001a114469c41ab8830539bee0d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Wed, Aug 10, 2016 at 1:04 PM, Andrei Popov <<= a href=3D"mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov= @microsoft.com> wrote:


The simple solution is to hash the TB IDs, and it w= orks regardless of the key type.

--001a114469c41ab8830539bee0d1-- From nobody Wed Aug 10 15:15: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 0CB1D126579 for ; Wed, 10 Aug 2016 14:45:40 -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 dq_BztJiycjS for ; Wed, 10 Aug 2016 14:45:37 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 23C7112D86C for ; Wed, 10 Aug 2016 14:45:37 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id x130so49778692ite.1 for ; Wed, 10 Aug 2016 14:45:37 -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=lXBLULOk6L5jOjNMJmWmMXKuA+HCQIqzj5VAvmOrSB4=; b=OqkKbEl+3YYYhUjpjrnqmwKtR0lQJK8U67qGV++9UAQQZhUGlkvg7uP+1OPEX16dok FjU60bUCxlMtlhCgQ/QSW96gncn4OfXlcPdluccsMk6Zsjt75EskMmojP7sI0BX5YOiO m4RdXurEKDGFAmytmdrnYfmfV6C27rzXMGtIs= 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=lXBLULOk6L5jOjNMJmWmMXKuA+HCQIqzj5VAvmOrSB4=; b=KOvSW1Hh4ZGVxPZTEcuC6tTnCxaqOXVDCGWwpX0qZ+TZBqi52h/XlJb7zev0Z7bJnJ KGG+rZWSmEkwCrIvdAmRvBpo5THWOGop/C7q3aBNHZX78PoByVKxJfnKzkbOLqtJoDPG 0p97EpVroCuI+ze7o0rHg/A5Oz4z7Hlr1mVcaf88Y9OL/ENyb3/MPiCa3x1v1oBVFI+f mG2wnhEqfAQusVuOLLT+s97JKAOUBs6VCF4N0RfTaAFXIxLcrIPEVo0Kkqj3tKjGIpTP 4RCN1toewry9C0DQckgV0Rm0zqOojQE8J2EkhyCCeIByHh4c2D1/U3SFr7gdvwSs2i1l ezZw== X-Gm-Message-State: AEkoousgU9j/3h0Wv4g2o2etmLFgVcYSZtrcOjp0ghoeoiovQI7JIwFjVsb9l3rDl7EHzqsM1/Rti7dL7eWolyEy X-Received: by 10.36.91.134 with SMTP id g128mr6047050itb.42.1470865536471; Wed, 10 Aug 2016 14:45:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Wed, 10 Aug 2016 14:45:05 -0700 (PDT) In-Reply-To: References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129E2F59@CIO-TNC-D2MBX02.osuad.osu.edu> <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> From: Brian Campbell Date: Wed, 10 Aug 2016 15:45:05 -0600 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a1144a1e6d079040539be91a8 Archived-At: X-Mailman-Approved-At: Wed, 10 Aug 2016 15:15:00 -0700 Cc: Subodh Iyengar , Dirk Balfanz , Martin Thomson , Scott Cantor , IETF Tokbind WG , Bill Cox , John Bradley , "Manger, James" , Nick Harper Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 10 Aug 2016 21:45:40 -0000 --001a1144a1e6d079040539be91a8 Content-Type: text/plain; charset=UTF-8 +1 On Wed, Aug 10, 2016 at 1:04 PM, Andrei Popov wrote: > > > The simple solution is to hash the TB IDs, and it works regardless of the > key type. > --001a1144a1e6d079040539be91a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Wed, Aug 10, 2016 at 1:04 PM, Andrei Popov <<= a href=3D"mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov= @microsoft.com> wrote:

= =C2=A0

The simple solution is to hash the TB IDs, and it w= orks regardless of the key type.

--001a1144a1e6d079040539be91a8-- From nobody Wed Aug 10 15:15: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 55EDC12D809 for ; Wed, 10 Aug 2016 15:13:28 -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 LBZgNXcfBaYA for ; Wed, 10 Aug 2016 15:13:25 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0109.outbound.protection.outlook.com [104.47.37.109]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B99112D12D for ; Wed, 10 Aug 2016 15:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q1JFoDG2LUud3WDUTBezhFhuxRQo3O9zLaUBN755kUE=; b=RNI7oh45GNB0Ii8Rj4h/wY9GM4rVc4Augn2zLKcHtk3OL3iqIxGQZcBXNmBay2CGsSpppzUT8DqH2q7gqWAoOI/d1E0kUjte3b4xynT/1ju2Egr7dnbpAb3Png0I46SXi1X3/CobyVTQ646EheSYJFgRSfTn40PoihKdoLXCmcQ= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2153.namprd03.prod.outlook.com (10.166.206.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 10 Aug 2016 22:13:22 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0549.025; Wed, 10 Aug 2016 22:13:22 +0000 From: Andrei Popov To: John Bradley Thread-Topic: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) Thread-Index: AQHR8Ut8epZDh2EP4E+neKQPnf2Vr6A/GCOAgABGfQCAAAbiAIAAf3yAgAHuYQCAAKUE0IAAAl6AgAAJFICAAAjdAIAAAzLwgAARB4CAACQF4A== Date: Wed, 10 Aug 2016 22:13:21 +0000 Message-ID: References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129E2F59@CIO-TNC-D2MBX02.osuad.osu.edu> <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> <0F5C7253-5A94-4855-B3F8-80E098209622@ve7jtb.com> In-Reply-To: <0F5C7253-5A94-4855-B3F8-80E098209622@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:d::1d2] x-ms-office365-filtering-correlation-id: 9ad12f14-96c6-405b-714f-08d3c16b8ab3 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2153; 6:1hZfOYf/AXYmqBd0W8+t5YOfpfyT4vBb1O+hLkmdvGc5OdEVTP3urI6ILQdSaEQDMkPmjPJnh+9pfjBoVCVj4ybNMMRzgENqxbeUKaI59QM3d+D3xJgh3Xe6TXW3ompZsAHmSwePyf3VeQadVDSMBv8xjG5joTRE6PN4by9ER1AhUUButYLwAHYscqCqzaToNI+C8i9M1titrEKxrJDk+Rjff5yxaLDnz9wxkcInJKY5rgbFwBWE8advHUGGhDJE3UsUlKF0mjcqBlerFohxC4/xOktxWLpBS4hoG9p93eCHQOEWnCkEgGdliVSteZBXTBXg6/zEV1YcK+qh5a/NCw==; 5:GgtDONIeDHYhQmfmNhKwLN3G/bR4XbxSNMR3MLBUfo+K+Sb1HJCGPGO5lNA2XwNx6tGIhS/wuYImAtmTWS7DLEF//IjcHcOX5fqEs4o+Q2ayWv1n8LEzatvzyU3p/7Rbl0yi6c34uRlmZPFanQCaoA==; 24:8sigu4gNugI4R2FEW77Piqfd48hMIPrDh/27rsCL1dSd9Ys9F6Tc4y2OrbSt5warbPUJyGS0xiYNQR6Nu0PXrKs4Pghnvo5r1pAU4yDXUeE=; 7:Mof37lCGA9IotJfyQeFOLolkbXptJT7wxc/+T0CYKbCeWxbr5v/9lU2+F8T5Ou576SF5UK6GEOnkvznjVsHdyEVs7PAlDAk/hNZgyoqDbO0yi6eqhLrAxC/bDwe1dI4uG18CU79V0gDN4ue99P8yLGICtjuYqYh9W7M5BnLAS2KsPWDJY3K8GAfMbkT7SfZY8waFI2mMBs9HqxGWFTZ5IuiqPwcV3YJ4SGoydGi5vpttZhx3YrdoHVS2Gg2Adpts x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2153; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(67672495146484)(272811157607776)(211936372134217)(21748063052155)(92004823454550)(67441168502697); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2153; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2153; x-forefront-prvs: 0030839EEE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(46034005)(24454002)(377454003)(110136002)(19625215002)(122556002)(68736007)(106116001)(86612001)(77096005)(101416001)(5005710100001)(10090500001)(74316002)(86362001)(16236675004)(50986999)(19580395003)(76576001)(189998001)(7736002)(7696003)(54356999)(19580405001)(8990500004)(8666005)(9686002)(7846002)(76176999)(3660700001)(2906002)(97736004)(8936002)(3280700002)(4326007)(8676002)(19300405004)(7416002)(5002640100001)(586003)(93886004)(106356001)(2900100001)(2950100001)(81166006)(10400500002)(10290500002)(92566002)(6116002)(15975445007)(790700001)(102836003)(81156014)(87936001)(11100500001)(33656002)(99286002)(105586002)(7059030)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2153; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB2155EFC85531E5E633777F278C1D0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2016 22:13:21.9496 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2153 Archived-At: X-Mailman-Approved-At: Wed, 10 Aug 2016 15:15:00 -0700 Cc: Subodh Iyengar , Dirk Balfanz , Martin Thomson , Scott Cantor , IETF Tokbind WG , Bill Cox , Brian Campbell , "Manger, James" , Nick Harper Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 10 Aug 2016 22:13:28 -0000 --_000_CY1PR03MB2155EFC85531E5E633777F278C1D0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIFNvIEFuZHJlLCAgSSB0YWtlIGl0IHRoYXQgeW91IHRoaW5rIGRyb3BwaW5nIFJTQSBhdCB0 aGlzIHBvaW50IGlzIG5vdCB3b3J0aCBpdCBhcyB3ZSBhcmUgZ29pbmcgdG8gd2FudCB0byBoYXZl IHNob3J0IHJlcHJlc2VudGF0aW9ucyBvZiBrZXlzIGluIHRoZSBoaWdoZXIgbGV2ZWwgc3BlY3Mg YW55d2F5Pw0KWWVzLCBJIHRoaW5rIHRoZXJlIGFyZSBnb29kIHJlYXNvbnMgdG8gaGF2ZSBzaG9y dCByZXByZXNlbnRhdGlvbnMgb2Yga2V5cyByZWdhcmRsZXNzIG9mIHRoZSBhbGdvcml0aG0uIEV2 ZW4gaWYgd2Ugd2VyZSB0byBkcm9wIFJTQSBub3csIHdlIG1heSBoYXZlIHRvIHVzZSBsb25nIGtl eXMgd2l0aCBhIGZ1dHVyZSBhbGdvcml0aG0uDQoNCg0Kw5ggIFNvIHllcyBJIGFtIGJlaW5nIHBy b3ZvY2F0aXZlLCBidXQgSSB3b3VsZCBsaWtlIHRvIGhhdmUgYSBhbnN3ZXIgdGhhdCB0aGUgV0cg aGFzIHRob3VnaHQgdGhyb3VnaCBvbiB0aGUgbGlzdCBhYm91dCB3aHkgd2UgYXJlIGRvaW5nIFJT QSBiZWZvcmUgd2UgZ2V0IHRvIHRoZSBJRVNHIGFuZCBzb21lb25lIGFza3MgdGhlIHF1ZXN0aW9u Lg0KSWRlYWxseSwgd2Ugd2FudCBvdXIgVEIga2V5cyBoYXJkd2FyZSBib3VuZCwgYW5kIHVuZm9y dHVuYXRlbHkgYSB2YXJpZXR5IG9mIGhhcmR3YXJlIGRldmljZXMgKG5vdGFibHksIFRQTXMpIGRv buKAmXQgc3VwcG9ydCBFQy4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KRnJvbTogSm9obiBCcmFk bGV5IFttYWlsdG86dmU3anRiQHZlN2p0Yi5jb21dDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAx MCwgMjAxNiAxOjAwIFBNDQpUbzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0 LmNvbT4NCkNjOiBCaWxsIENveCA8d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbT47IFNjb3R0IENhbnRv ciA8Y2FudG9yLjJAb3N1LmVkdT47IFN1Ym9kaCBJeWVuZ2FyIDxzdWJvZGhAZmIuY29tPjsgRGly ayBCYWxmYW56IDxiYWxmYW56QGdvb2dsZS5jb20+OyBNYW5nZXIsIEphbWVzIDxKYW1lcy5ILk1h bmdlckB0ZWFtLnRlbHN0cmEuY29tPjsgSUVURiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYu b3JnPjsgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPjsgTWFydGlu IFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IE5pY2sgSGFycGVyIDxuaGFycGVy QGdvb2dsZS5jb20+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFJldmlzaXQgZVRMRCsxICh3 YXMgUmU6IHN1cHBvcnQgZm9yIGRpZmZlcmVudCBrZXkgcGFyYW1ldGVycyB3aXRoaW4gdGhlIHNh bWUgVExEKzEpDQoNClRoZSByZXByZXNlbnRhdGlvbiBvZiB0aGUgdG9rZW4gYmluZGluZyBJRCBp biBhIE9BdXRoIFRva2VuIG9yIElEX1Rva2VuIHdvdWxkIGJlIGEgaGlnaGVyIGxldmVsIHNwZWMu ICBXZSBkaWQgaW50cm9kdWNlIHRob3NlIHRvIHRoZSBPQXV0aCBXRy4NCg0KSSB0aGluayBpdCB3 YXMgeW91IG9yIERpcmsgdGhhdCBhcmd1ZWQgdGhhdCB3ZSBzaG91bGQga2VlcCBpdCBzaW1wbGUg YW5kIGp1c3QgcGFzcyB0aGUgd2hvbGUgb3BhcXVlIHRva2VuIGJpbmRpbmcgSUQgYm90aCBpbiB0 aGUgdG9rZW4gYW5kIHdoZW4gd2UgbmVlZGVkIHRvIHJlZmVyIHRvIGl0IGluIGEgcGFyYW1ldGVy Lg0KDQpJbiB0aG9zZSBzcGVjcyB3ZSBpbml0aWFsbHkgZGVmaW5lZCBhIFNIQSAyNTYgdGh1bWJw cmludCBvZiB0aGUgdG9rZW4gYmluZGluZyBJRC4gIFRvIGNhcnJ5IGFzIGEgY2xhaW0gZm9yIHRo ZSBwcm9vZiBvZiBwb3NzZXNzaW9uLg0KDQpGb3IgY29va2llcyB1c2luZyB0aGUgdG9rZW4gYmlu ZGluZ19pZCBhcyBwYXJ0IG9mIHRoZSBlbmNyeXB0aW9uIG9yIHNpZ25pbmcga2V5IHZpYSBrZXkg ZGVyaXZhdGlvbiBzZWVtcyBsaWtlIGEgcmVhc29uYWJsZSBhcHByb2FjaCBmb3IgbG9uZyBrZXlz Lg0KDQpGb3IgT0F1dGggdGhlcmUgYXJlIGRvd25zaWRlcyB0byB1c2luZyBhbmQgbWFpbnRhaW5p bmcgc3ltbWV0cmljIGtleXMuICAgU2lnbmluZyB0aGUgdG9rZW5zIHdpdGggYXN5bW1ldHJpYyBr ZXlzIGhhcyBiaWcgYWR2YW50YWdlcyBpbiBzaW1wbGlmeWluZyBrZXkgZGlzdHJpYnV0aW9uIGFu ZCByb3RhdGlvbi4NCg0KSSB0aGluayBjYXJyeWluZyBzb21lIHJlcHJlc2VudGF0aW9uIG9mIHRo ZSBrZXkgaW4gdGhlIHRva2VuIHdpbGwgYmUgcmVxdWlyZWQgZm9yIGEgZ29vZCBudW1iZXIgb2Yg dGhlIHVzZSBjYXNlcy4NCg0KSG93ZXZlciB0aGUgZW5jcnlwdGlvbiBpZGVhIGlzIGludGVyZXN0 aW5nIGZvciBjb29raWVzLg0KDQpTbyBBbmRyZSwgIEkgdGFrZSBpdCB0aGF0IHlvdSB0aGluayBk cm9wcGluZyBSU0EgYXQgdGhpcyBwb2ludCBpcyBub3Qgd29ydGggaXQgYXMgd2UgYXJlIGdvaW5n IHRvIHdhbnQgdG8gaGF2ZSBzaG9ydCByZXByZXNlbnRhdGlvbnMgb2Yga2V5cyBpbiB0aGUgaGln aGVyIGxldmVsIHNwZWNzIGFueXdheT8NCg0KV2UgYXJlIGN1cnJlbnRseSByZWNvbW1lbmRpbmcg dGhhdCBzZXJ2ZXJzIHN1cHBvcnQgYm90aCBSU0EgYW5kIEVDLg0KDQpBcmUgd2UgdGhpbmtpbmcg dGhhdCBzb21lIGNsaWVudHMgd291bGQgb25seSBiZSBhYmxlIHRvIHN1cHBvcnQgUlNBPw0KDQpJ IGFtIGd1ZXNzaW5nIHRoYXQgYnJvd3NlcnMgd2lsbCBhbGwgaGF2ZSBFQyBhbmQgSSBzdXNwZWN0 IFdpbmRvd3MgYW5kIENyb05ldCB3aWxsIGhhdmUgRUMuDQoNClNvIHllcyBJIGFtIGJlaW5nIHBy b3ZvY2F0aXZlLCBidXQgSSB3b3VsZCBsaWtlIHRvIGhhdmUgYSBhbnN3ZXIgdGhhdCB0aGUgV0cg aGFzIHRob3VnaHQgdGhyb3VnaCBvbiB0aGUgbGlzdCBhYm91dCB3aHkgd2UgYXJlIGRvaW5nIFJT QSBiZWZvcmUgd2UgZ2V0IHRvIHRoZSBJRVNHIGFuZCBzb21lb25lIGFza3MgdGhlIHF1ZXN0aW9u Lg0KDQpKb2huIEIuDQoNCk9uIEF1ZyAxMCwgMjAxNiwgYXQgMzowNCBQTSwgQW5kcmVpIFBvcG92 IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29m dC5jb20+PiB3cm90ZToNCg0KVG8gc3RlcCBiYWNrIGEgYml0LCBUQiBzcGVjcyBleHBsaWNpdGx5 IGF2b2lkIHNwZWNpZnlpbmcgbWV0aG9kcyBvZiBiaW5kaW5nIHRva2VucywgYWx0aG91Z2ggdGhl eSBkbyBwcm92aWRlIGV4YW1wbGVzIG9mIHdoYXQgY291bGQgYmUgZG9uZS4NCg0KRXZlbiBpZiB3 ZSB3ZXJlIHRvIHByb2hpYml0IFJTQSwgd2UgY2Fu4oCZdCBndWFyZCBhZ2FpbnN0IGEgZnV0dXJl IGFsZ29yaXRobSB0aGF0IHJlcXVpcmVzIGEgbG9uZyBrZXkuDQoNClRoZSBzaW1wbGUgc29sdXRp b24gaXMgdG8gaGFzaCB0aGUgVEIgSURzLCBhbmQgaXQgd29ya3MgcmVnYXJkbGVzcyBvZiB0aGUg a2V5IHR5cGUuIEl0IGlzIGFsc28gcG9zc2libGUgdGhhdCBCaWxs4oCZcyBpZGVhIHdvdWxkIHdv cmssIGFzIGFuIGFsdGVybmF0aXZlLiBCdXQgSU1ITyB0aGlzIGJlbG9uZ3MgaW4gYSBoaWdoZXIt bGV2ZWwgc3BlYy4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KRnJvbTogQmlsbCBDb3ggW21haWx0 bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTAsIDIw MTYgMTE6NDcgQU0NClRvOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2 ZTdqdGJAdmU3anRiLmNvbT4+DQpDYzogU2NvdHQgQ2FudG9yIDxjYW50b3IuMkBvc3UuZWR1PG1h aWx0bzpjYW50b3IuMkBvc3UuZWR1Pj47IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jv c29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj47IFN1Ym9kaCBJeWVu Z2FyIDxzdWJvZGhAZmIuY29tPG1haWx0bzpzdWJvZGhAZmIuY29tPj47IERpcmsgQmFsZmFueiA8 YmFsZmFuekBnb29nbGUuY29tPG1haWx0bzpiYWxmYW56QGdvb2dsZS5jb20+PjsgTWFuZ2VyLCBK YW1lcyA8SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTxtYWlsdG86SmFtZXMuSC5NYW5n ZXJAdGVhbS50ZWxzdHJhLmNvbT4+OyBJRVRGIFRva2JpbmQgV0cgPHVuYmVhcmFibGVAaWV0Zi5v cmc8bWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmc+PjsgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+OyBN YXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhv bXNvbkBnbWFpbC5jb20+PjsgTmljayBIYXJwZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbTxtYWlsdG86 bmhhcnBlckBnb29nbGUuY29tPj4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gUmV2aXNpdCBl VExEKzEgKHdhcyBSZTogc3VwcG9ydCBmb3IgZGlmZmVyZW50IGtleSBwYXJhbWV0ZXJzIHdpdGhp biB0aGUgc2FtZSBUTEQrMSkNCg0KT24gV2VkLCBBdWcgMTAsIDIwMTYgYXQgMTE6MTUgQU0sIEpv aG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4g d3JvdGU6DQpJIGhhdmUgYmVlbiBsb29raW5nIGF0IHVzaW5nIFRva2VuIEJpbmRpbmcgaW4gT0F1 dGguDQoNCkJlY2F1c2UgUlNBIFRva2VuIGJpbmRpbmcgSUQgYXJlIHNvIGxhcmdlIHdlIGFyZSBw cm9iYWJseSBnb2luZyB0byBuZWVkIGEgdGh1bWJwcmludCBvZiB0aGVtIHRvIHB1dCBpbiB0b2tl bnMgdG8ga2VlcCB0aGUgc2l6ZSBmcm9tIGJsb3dpbmcgdXAuDQoNClRoaXMgYWRkcyBjb21wbGV4 aXR5IG92ZXIgc2F5aW5nIGp1c3Qgc2VuZCB0aGUgdG9rZW4gYmluZGluZyBJRC4NCg0KTWluaW1p emluZyB0b2tlbiBzaXplIGlzIGltcG9ydGFudCwgc28gSSdkIHByZWZlciBqdXN0IHRvIGhhdmUg YSA2NC1iaXQgZmluZ2VycHJpbnQgaWYgcG9zc2libGUuICBUbyBkbyB0aGF0IHdpdGhvdXQgY3Jl YXRpbmcgdGhlIHJpc2sgdGhhdCBhdHRhY2tlcnMgY2FuIGNyZWF0ZSBrZXkgcGFpcnMgdGhhdCBo YXZlIHRoZSBzYW1lIGZpbmdlcnByaW50LCB5b3UgaGF2ZSB0byByYW5kb21pemUgdGhlIGhhc2hp bmcgd2l0aCBhIHNlY3JldCBvZiBzb21lIHNvcnQuICBJZiB0aGlzIGZpbmdlcnByaW50IGlzIGlu IGFuIGVuY3J5cHRlZCBwb3J0aW9uIG9mIGFuIG9hdXRoIHRva2VuLCB0aGVuIHRoZSByYW5kb21p emF0aW9uIGtleSBjYW4gYmUgZGVyaXZlZCBmcm9tIHRoZSBkZWNyeXB0aW9uIGtleSwgb3Igc29t ZXRoaW5nIGxpa2UgdGhhdC4NCg0KSWYgd2UgaW5zdGVhZCBzdG9yZSB0aGUgdW5jb21wcmVzZWQg RUMga2V5cywgaXQgd2lsbCB0YWtlIDY0LWJ5dGVzLCA4WCBsYXJnZXIgdGhhbiByZXF1aXJlZC4N Cg0KSnVzdCBzb21lIGRvbWUgYnJhaW5zdG9ybWluZzogd2hhdCBpZiB3ZSBlbmNyeXB0ZWQgdGhl IG9hdXRoIHRva2VuIG9yIGNvb2tpZSB1c2luZyB0aGUgc3RhbmRhcmQgZW5jcnlwdGlvbiBrZXkg aGFzaGVkIHdpdGggdGhlIFRCIHB1YmxpYyBrZXk/ICBUaGF0IHdheSB3ZSB2ZXJpZnkgdGhlIFRC IGtleSBieSBzdWNjZXNzZnVsbHkgZGVjcnlwdGluZyB0aGUgdG9rZW4sIHdpdGhvdXQgaW5jcmVh c2luZyB0aGUgc2l6ZSBvZiB0aGUgY29va2llL3Rva2VuIGF0IGFsbC4gIEkgdGhpbmsgdGhpcyBm YWxscyB1bmRlciB0aGUgY29uY2VwdCBvZiBBRUFELCB3aGVyZSB0aGUgVEIgcHVibGljIGtleSBp cyBzaW1wbHkgImFkZGl0aW9uYWwgZGF0YSIuDQoNCkJpbGwNCg0K --_000_CY1PR03MB2155EFC85531E5E633777F278C1D0CY1PR03MB2155namp_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1z dHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE2MDI5NTg2Mzk7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDUzNjY5NTg2IDY3Njk4 Njk5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJ e21zby1saXN0LWlkOjIwNTQ1Nzk4Njc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi0xODc0OTc1NjEwIC0xNzA3OTk2NjE0IDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30N CkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGkt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTps ZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVs MSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2lu Z2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+U28gQW5kcmUsICZuYnNwO0kgdGFrZSBpdCB0aGF0IHlvdSB0aGlu ayBkcm9wcGluZyBSU0EgYXQgdGhpcyBwb2ludCBpcyBub3Qgd29ydGggaXQgYXMgd2UgYXJlIGdv aW5nIHRvIHdhbnQgdG8gaGF2ZSBzaG9ydCByZXByZXNlbnRhdGlvbnMgb2Yga2V5cyBpbiB0aGUg aGlnaGVyIGxldmVsIHNwZWNzIGFueXdheT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlllcywgSSB0aGluayB0aGVyZSBhcmUgZ29vZCByZWFzb25zIHRvIGhhdmUgc2hvcnQg cmVwcmVzZW50YXRpb25zIG9mIGtleXMgcmVnYXJkbGVzcyBvZiB0aGUgYWxnb3JpdGhtLiBFdmVu IGlmIHdlIHdlcmUgdG8gZHJvcCBSU0Egbm93LCB3ZSBtYXkgaGF2ZSB0byB1c2UgbG9uZyBrZXlz IHdpdGggYSBmdXR1cmUgYWxnb3JpdGhtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+PCFbaWYg IXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPlNvIHllcyBJIGFtIGJlaW5nIHByb3ZvY2F0aXZlLCBidXQgSSB3b3VsZCBsaWtlIHRvIGhh dmUgYSBhbnN3ZXIgdGhhdCB0aGUgV0cgaGFzIHRob3VnaHQgdGhyb3VnaCBvbiB0aGUgbGlzdCBh Ym91dCB3aHkgd2UgYXJlIGRvaW5nIFJTQSBiZWZvcmUgd2UgZ2V0IHRvIHRoZSBJRVNHIGFuZCBz b21lb25lIGFza3MgdGhlIHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JZGVhbGx5LCB3ZSB3YW50IG91ciBUQiBrZXlzIGhhcmR3 YXJlIGJvdW5kLCBhbmQgdW5mb3J0dW5hdGVseSBhIHZhcmlldHkgb2YgaGFyZHdhcmUgZGV2aWNl cyAobm90YWJseSwgVFBNcykgZG9u4oCZdCBzdXBwb3J0IEVDLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5DaGVl cnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkFuZHJlaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEpv aG4gQnJhZGxleSBbbWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFdlZG5lc2RheSwgQXVndXN0IDEwLCAyMDE2IDE6MDAgUE08YnI+DQo8Yj5Ubzo8L2I+IEFuZHJl aSBQb3BvdiAmbHQ7QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBCaWxsIENveCAmbHQ7d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbSZndDs7IFNjb3R0IENhbnRvciAm bHQ7Y2FudG9yLjJAb3N1LmVkdSZndDs7IFN1Ym9kaCBJeWVuZ2FyICZsdDtzdWJvZGhAZmIuY29t Jmd0OzsgRGlyayBCYWxmYW56ICZsdDtiYWxmYW56QGdvb2dsZS5jb20mZ3Q7OyBNYW5nZXIsIEph bWVzICZsdDtKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tJmd0OzsgSUVURiBUb2tiaW5k IFdHICZsdDt1bmJlYXJhYmxlQGlldGYub3JnJmd0OzsgQnJpYW4gQ2FtcGJlbGwgJmx0O2JjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tJmd0OzsNCiBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRo b21zb25AZ21haWwuY29tJmd0OzsgTmljayBIYXJwZXIgJmx0O25oYXJwZXJAZ29vZ2xlLmNvbSZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBSZXZpc2l0IGVUTEQmIzQz OzEgKHdhcyBSZTogc3VwcG9ydCBmb3IgZGlmZmVyZW50IGtleSBwYXJhbWV0ZXJzIHdpdGhpbiB0 aGUgc2FtZSBUTEQmIzQzOzEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIHJlcHJlc2VudGF0aW9uIG9mIHRoZSB0b2tlbiBiaW5kaW5nIElEIGluIGEg T0F1dGggVG9rZW4gb3IgSURfVG9rZW4gd291bGQgYmUgYSBoaWdoZXIgbGV2ZWwgc3BlYy4gJm5i c3A7V2UgZGlkIGludHJvZHVjZSB0aG9zZSB0byB0aGUgT0F1dGggV0cuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIGl0IHdhcyB5b3Ugb3IgRGly ayB0aGF0IGFyZ3VlZCB0aGF0IHdlIHNob3VsZCBrZWVwIGl0IHNpbXBsZSBhbmQganVzdCBwYXNz IHRoZSB3aG9sZSBvcGFxdWUgdG9rZW4gYmluZGluZyBJRCBib3RoIGluIHRoZSB0b2tlbiBhbmQg d2hlbiB3ZSBuZWVkZWQgdG8gcmVmZXIgdG8gaXQgaW4gYSBwYXJhbWV0ZXIuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRob3NlIHNwZWNz IHdlIGluaXRpYWxseSBkZWZpbmVkIGEgU0hBIDI1NiB0aHVtYnByaW50IG9mIHRoZSB0b2tlbiBi aW5kaW5nIElELiAmbmJzcDtUbyBjYXJyeSBhcyBhIGNsYWltIGZvciB0aGUgcHJvb2Ygb2YgcG9z c2Vzc2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Rm9yIGNvb2tpZXMgdXNpbmcgdGhlIHRva2VuIGJpbmRpbmdfaWQgYXMgcGFydCBvZiB0 aGUgZW5jcnlwdGlvbiBvciBzaWduaW5nIGtleSB2aWEga2V5IGRlcml2YXRpb24gc2VlbXMgbGlr ZSBhIHJlYXNvbmFibGUgYXBwcm9hY2ggZm9yIGxvbmcga2V5cy4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIE9BdXRoIHRoZXJl IGFyZSBkb3duc2lkZXMgdG8gdXNpbmcgYW5kIG1haW50YWluaW5nIHN5bW1ldHJpYyBrZXlzLiAm bmJzcDsgU2lnbmluZyB0aGUgdG9rZW5zIHdpdGggYXN5bW1ldHJpYyBrZXlzIGhhcyBiaWcgYWR2 YW50YWdlcyBpbiBzaW1wbGlmeWluZyBrZXkgZGlzdHJpYnV0aW9uIGFuZCByb3RhdGlvbi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGlu ayBjYXJyeWluZyBzb21lIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBrZXkgaW4gdGhlIHRva2VuIHdp bGwgYmUgcmVxdWlyZWQgZm9yIGEgZ29vZCBudW1iZXIgb2YgdGhlIHVzZSBjYXNlcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93ZXZlciB0 aGUgZW5jcnlwdGlvbiBpZGVhIGlzIGludGVyZXN0aW5nIGZvciBjb29raWVzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBBbmRyZSwgJm5i c3A7SSB0YWtlIGl0IHRoYXQgeW91IHRoaW5rIGRyb3BwaW5nIFJTQSBhdCB0aGlzIHBvaW50IGlz IG5vdCB3b3J0aCBpdCBhcyB3ZSBhcmUgZ29pbmcgdG8gd2FudCB0byBoYXZlIHNob3J0IHJlcHJl c2VudGF0aW9ucyBvZiBrZXlzIGluIHRoZSBoaWdoZXIgbGV2ZWwgc3BlY3MgYW55d2F5PzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBhcmUg Y3VycmVudGx5IHJlY29tbWVuZGluZyB0aGF0IHNlcnZlcnMgc3VwcG9ydCBib3RoIFJTQSBhbmQg RUMuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BcmUgd2UgdGhpbmtpbmcgdGhhdCBzb21lIGNsaWVudHMgd291bGQgb25seSBiZSBh YmxlIHRvIHN1cHBvcnQgUlNBPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGFtIGd1ZXNzaW5nIHRoYXQgYnJvd3NlcnMgd2lsbCBhbGwgaGF2 ZSBFQyBhbmQgSSBzdXNwZWN0IFdpbmRvd3MgYW5kIENyb05ldCB3aWxsIGhhdmUgRUMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIHllcyBJ IGFtIGJlaW5nIHByb3ZvY2F0aXZlLCBidXQgSSB3b3VsZCBsaWtlIHRvIGhhdmUgYSBhbnN3ZXIg dGhhdCB0aGUgV0cgaGFzIHRob3VnaHQgdGhyb3VnaCBvbiB0aGUgbGlzdCBhYm91dCB3aHkgd2Ug YXJlIGRvaW5nIFJTQSBiZWZvcmUgd2UgZ2V0IHRvIHRoZSBJRVNHIGFuZCBzb21lb25lIGFza3Mg dGhlIHF1ZXN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Kb2huIEIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBdWcgMTAsIDIwMTYsIGF0IDM6MDQg UE0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3Nv ZnQuY29tIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5U byBzdGVwIGJhY2sgYSBiaXQsIFRCIHNwZWNzIGV4cGxpY2l0bHkgYXZvaWQgc3BlY2lmeWluZyBt ZXRob2RzIG9mIGJpbmRpbmcgdG9rZW5zLCBhbHRob3VnaCB0aGV5IGRvIHByb3ZpZGUgZXhhbXBs ZXMgb2Ygd2hhdCBjb3VsZCBiZSBkb25lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5FdmVuIGlmIHdlIHdlcmUgdG8gcHJvaGliaXQgUlNBLCB3ZSBjYW7igJl0 IGd1YXJkIGFnYWluc3QgYSBmdXR1cmUgYWxnb3JpdGhtIHRoYXQgcmVxdWlyZXMgYSBsb25nIGtl eS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIHNpbXBs ZSBzb2x1dGlvbiBpcyB0byBoYXNoIHRoZSBUQiBJRHMsIGFuZCBpdCB3b3JrcyByZWdhcmRsZXNz IG9mIHRoZSBrZXkgdHlwZS4gSXQgaXMgYWxzbyBwb3NzaWJsZSB0aGF0IEJpbGzigJlzIGlkZWEg d291bGQgd29yaywgYXMgYW4gYWx0ZXJuYXRpdmUuIEJ1dCBJTUhPIHRoaXMgYmVsb25ncw0KIGlu IGEgaGlnaGVyLWxldmVsIHNwZWMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkNoZWVycyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+QW5kcmVpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5CaWxs DQogQ294IFs8YSBocmVmPSJtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbSI+bWFpbHRvOndh eXdhcmRnZWVrQGdvb2dsZS5jb208L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+V2VkbmVzZGF5LCBBdWd1c3QgMTAsIDIwMTYgMTE6 NDcgQU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPkpvaG4gQnJhZGxleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdq dGIuY29tIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5TY290dCBDYW50b3IgJmx0 OzxhIGhyZWY9Im1haWx0bzpjYW50b3IuMkBvc3UuZWR1Ij5jYW50b3IuMkBvc3UuZWR1PC9hPiZn dDs7IEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3Nv ZnQuY29tIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyBTdWJvZGggSXllbmdh ciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN1Ym9kaEBmYi5jb20iPnN1Ym9kaEBmYi5jb208L2E+Jmd0 OzsNCiBEaXJrIEJhbGZhbnogJmx0OzxhIGhyZWY9Im1haWx0bzpiYWxmYW56QGdvb2dsZS5jb20i PmJhbGZhbnpAZ29vZ2xlLmNvbTwvYT4mZ3Q7OyBNYW5nZXIsIEphbWVzICZsdDs8YSBocmVmPSJt YWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbSI+SmFtZXMuSC5NYW5nZXJAdGVh bS50ZWxzdHJhLmNvbTwvYT4mZ3Q7OyBJRVRGIFRva2JpbmQgV0cgJmx0OzxhIGhyZWY9Im1haWx0 bzp1bmJlYXJhYmxlQGlldGYub3JnIj51bmJlYXJhYmxlQGlldGYub3JnPC9hPiZndDs7DQogQnJp YW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bSI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OzsgTWFydGluIFRob21zb24gJmx0 OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iPm1hcnRpbi50aG9tc29u QGdtYWlsLmNvbTwvYT4mZ3Q7OyBOaWNrIEhhcnBlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5oYXJw ZXJAZ29vZ2xlLmNvbSI+bmhhcnBlckBnb29nbGUuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6 IFtVbmJlYXJhYmxlXSBSZXZpc2l0IGVUTEQmIzQzOzEgKHdhcyBSZTogc3VwcG9ydCBmb3IgZGlm ZmVyZW50IGtleSBwYXJhbWV0ZXJzIHdpdGhpbiB0aGUgc2FtZSBUTEQmIzQzOzEpPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEF1ZyAxMCwgMjAxNiBhdCAxMToxNSBBTSwgSm9obiBC cmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj52ZTdqdGJAdmU3anRiLmNvbTwvc3Bhbj48 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1y aWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBoYXZlIGJlZW4gbG9va2luZyBhdCB1c2luZyBUb2tlbiBCaW5kaW5nIGluIE9BdXRoLjxi cj4NCjxicj4NCkJlY2F1c2UgUlNBIFRva2VuIGJpbmRpbmcgSUQgYXJlIHNvIGxhcmdlIHdlIGFy ZSBwcm9iYWJseSBnb2luZyB0byBuZWVkIGEgdGh1bWJwcmludCBvZiB0aGVtIHRvIHB1dCBpbiB0 b2tlbnMgdG8ga2VlcCB0aGUgc2l6ZSBmcm9tIGJsb3dpbmcgdXAuPGJyPg0KPGJyPg0KVGhpcyBh ZGRzIGNvbXBsZXhpdHkgb3ZlciBzYXlpbmcganVzdCBzZW5kIHRoZSB0b2tlbiBiaW5kaW5nIElE LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWluaW1pemluZyB0b2tlbiBzaXpl IGlzIGltcG9ydGFudCwgc28gSSdkIHByZWZlciBqdXN0IHRvIGhhdmUgYSA2NC1iaXQgZmluZ2Vy cHJpbnQgaWYgcG9zc2libGUuJm5ic3A7IFRvIGRvIHRoYXQgd2l0aG91dCBjcmVhdGluZyB0aGUg cmlzayB0aGF0IGF0dGFja2VycyBjYW4gY3JlYXRlIGtleSBwYWlycyB0aGF0IGhhdmUgdGhlIHNh bWUgZmluZ2VycHJpbnQsIHlvdSBoYXZlIHRvIHJhbmRvbWl6ZSB0aGUgaGFzaGluZw0KIHdpdGgg YSBzZWNyZXQgb2Ygc29tZSBzb3J0LiZuYnNwOyBJZiB0aGlzIGZpbmdlcnByaW50IGlzIGluIGFu IGVuY3J5cHRlZCBwb3J0aW9uIG9mIGFuIG9hdXRoIHRva2VuLCB0aGVuIHRoZSByYW5kb21pemF0 aW9uIGtleSBjYW4gYmUgZGVyaXZlZCBmcm9tIHRoZSBkZWNyeXB0aW9uIGtleSwgb3Igc29tZXRo aW5nIGxpa2UgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgd2UgaW5zdGVhZCBz dG9yZSB0aGUgdW5jb21wcmVzZWQgRUMga2V5cywgaXQgd2lsbCB0YWtlIDY0LWJ5dGVzLCA4WCBs YXJnZXIgdGhhbiByZXF1aXJlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBzb21l IGRvbWUgYnJhaW5zdG9ybWluZzogd2hhdCBpZiB3ZSBlbmNyeXB0ZWQgdGhlIG9hdXRoIHRva2Vu IG9yIGNvb2tpZSB1c2luZyB0aGUgc3RhbmRhcmQgZW5jcnlwdGlvbiBrZXkgaGFzaGVkIHdpdGgg dGhlIFRCIHB1YmxpYyBrZXk/Jm5ic3A7IFRoYXQgd2F5IHdlIHZlcmlmeSB0aGUgVEIga2V5IGJ5 IHN1Y2Nlc3NmdWxseSBkZWNyeXB0aW5nIHRoZSB0b2tlbiwgd2l0aG91dCBpbmNyZWFzaW5nIHRo ZSBzaXplDQogb2YgdGhlIGNvb2tpZS90b2tlbiBhdCBhbGwuJm5ic3A7IEkgdGhpbmsgdGhpcyBm YWxscyB1bmRlciB0aGUgY29uY2VwdCBvZiBBRUFELCB3aGVyZSB0aGUgVEIgcHVibGljIGtleSBp cyBzaW1wbHkgJnF1b3Q7YWRkaXRpb25hbCBkYXRhJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5CaWxsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_CY1PR03MB2155EFC85531E5E633777F278C1D0CY1PR03MB2155namp_-- From nobody Wed Aug 10 16:04: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 84E9E12B069 for ; Wed, 10 Aug 2016 16:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 xxiSIoBeLWKh for ; Wed, 10 Aug 2016 16:04:42 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0098.outbound.protection.outlook.com [104.47.38.98]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E6312B038 for ; Wed, 10 Aug 2016 16:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buckeyemailosu.onmicrosoft.com; s=selector1-osu-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=u9kFVq1rF3kleOMEGt97i3sUQl+y/1Fuvq3abvXH6Zs=; b=HJ0dCjUSUmCgw6J3Js0XqljuLKjv3TQyli3Xpn77t3ESbEPilYbOgJ64PPI8c1eIpZnSPYcvAe2vqAli1nPKI2vbkIr17Q79cWrpH4DCFqJcM6Jd9JM4grNoek+plLYDFdsCIaBxyZq3tAjKQYn7Ja6mdshn6vblphNc0IpPNP4= Received: from BY2PR01CA0071.prod.exchangelabs.com (10.163.25.39) by CO2PR01MB2151.prod.exchangelabs.com (10.166.91.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 10 Aug 2016 23:04:39 +0000 Received: from BY2FFO11FD039.protection.gbl (2a01:111:f400:7c0c::171) by BY2PR01CA0071.outlook.office365.com (2a01:111:e400:5262::39) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.15 via Frontend Transport; Wed, 10 Aug 2016 23:04:39 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.214) smtp.mailfrom=osu.edu; fb.com; dkim=none (message not signed) header.d=none;fb.com; 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 BY2FFO11FD039.mail.protection.outlook.com (10.1.14.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.567.7 via Frontend Transport; Wed, 10 Aug 2016 23:04:40 +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-krc-pf07.osuad.osu.edu (Postfix) with ESMTPS id B65F1500036; Wed, 10 Aug 2016 19:04:39 -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; Wed, 10 Aug 2016 19:04:37 -0400 From: "Cantor, Scott" To: Brian Campbell Thread-Topic: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) Thread-Index: AQHR8aDDx+pDq6EZgE2nj7753s28fqA/p+UAgAIq4z2AAOikAP//ve2wgABM4ID//746kIAAerSA///UuAA= Date: Wed, 10 Aug 2016 23:04:36 +0000 Message-ID: <84F8594F-59B1-4935-86BA-99F758BFBF0B@osu.edu> References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129E2F59@CIO-TNC-D2MBX02.osuad.osu.edu> <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> <9846A6064BD102419D06814DD0D78DE1129E303A@CIO-TNC-D2MBX02.osuad.osu.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.14.104] 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.214; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(438002)(199003)(189002)(24454002)(377454003)(76176999)(93886004)(109096001)(50986999)(93346002)(47776003)(15975445007)(54356999)(89122001)(66066001)(8676002)(96286002)(19580405001)(7736002)(82746002)(92566002)(356003)(626004)(19580395003)(189998001)(305945005)(106466001)(11100500001)(106116001)(7846002)(110136002)(7696003)(8666005)(7596002)(2906002)(86362001)(4326007)(246002)(3846002)(6116002)(586003)(102836003)(83716003)(5250100002)(50466002)(87936001)(33656002)(2900100001)(75432002)(23676002)(16796002)(2950100001)(90282001)(8936002)(88552002)(36756003)(7059030)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO2PR01MB2151; H:cio-krc-pf07.osuad.osu.edu; FPR:; SPF:Pass; PTR:cio-krc-pf07.osuad.osu.edu; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD039; 1:I6AdK/2kK1gdbUDgahkcrKT7JWIy4HDOPWnkVcL87ShAg2sKSxJMW0dXwhYWrV/EC47Sc+RVrLCKuMCqAVAFQ4S4dGCatD9vmPWLk0aEaTTlblki65eWiaFBU57xdaxxhT37bbg3ktBwpFp+UnatGxbiQPr3f50KaYU02lK2uUbegXcPzfwV1qHe53IlaIIs1iXc1UAcolTOSGfGtK45RQmeQvMnxwvF8BQcY0B28/oSzynouVbjrBcyyYAlvSYH+fFU8xrd4+5gUpE2CPoYtbsAncIHBgaqRHbGKdljRO5mXgFFrzyGYzC6alPwSnC4kf/Flcy48VtoT9LJh/AW43+KEb6aOTKQMoSWNts7oUsr/CeIZjpatcz0Rqu4zaW78c/LOJdHJB0RffqE5h3Fpg7rRXEBgJWZPqn9uxJPYsLxLetNKMf7JS2nnZuHZLqLMWT+Q3Q1aIi5uExnSJrNQVpV/1iCLFShOc+a/zy7cUZrPW1n2cdpF8OCoMc05alrIqDxMUOig07KiLnoOYbkk9r+pw+yrPO1t9Ki2G6zM8V4ylGfPBgz0NrjTdkC1Jsv X-MS-Office365-Filtering-Correlation-Id: caaaf3dd-ca77-4490-704b-08d3c172b59d X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2151; 2:UZEL3ff4do1n6eFEZF+LRdJwTh1EKT5Y/P6EpOaa8u99whisfS/6/yKmW7cMqNoAysNgZBl+9yMZVVS0otcsns5LF3emFKQ9KJiZPspjQ1DJJvk76B97LXYee+9lqV9H+5/+Ibkg38HftXLuwLJHWY/T9nlAwg6h0ItI8ni9F5R+rrwrXDUFh9Eat8RrHCcG; 3:bmpvdGJGQ+Hwp3oRrx7VyBnMKQ4DKPte5woFb357Wbi3eiES1d81goA8BTVd3VbYcFoZcTxJSuWiP5eNSJhqBFIY0//qfidxRSKtl/66fgAgfN9Se/joOcv2c4PHWlzDz9E2KoyiIzIdXBKbdlUHRaM/387lHwacCmoYhEDwHzRbLiRjM4yDfx0SZr0wRXsTFofMzjqtq7V3cBfPt12OSIp8sAhrPw4UF+aZEJ0n9mfSKXcNZqpicIC4qFBSYeZ2BhnAy5x7J/dDamT+qHnLPw==; 25:y/siplW+he1x6ouXnhaPhzqgTHKxidJXKj9QokeDNaaOyFIPqAbchlR7JpMPm3R/iQTA0Wv72KgtYBMC46n3Jydjc23817koUUnlaVbSNmY4PJFYdbOnWYucAZZO95N9E7z2XmRUbMrs0rHsBlM9ELA7htr+C31/WHzsV+ihU8fQ+hP+lRQhBLN0FXpr6l1OMZbn7EQudY7l15nz98vqa0p3BJYn34aHJrCczYGhjCBTmJXEuV7wMaKVbRmZlsXEroUZ4Mr0/fpSn1BVjPqLC805HdjUxTmYGUhnrJuh2zO/eUqMZHhsHGjLv+uhEqgtZ8tSYMLkg3PSpiek40ywMzq5NU5idLe9gpnd/Zua/RnJ1XUTQfkX6z3ke5IzHKNull+eqonuAkPgdhXp2A0KftESOuzxU1vijhGG1X6D+hQ= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:CO2PR01MB2151; X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2151; 31:2pqmzLsvZMXQ+SlEaPKrhTRLsLkVcNoXUNA87LJICd3d2U4OMRxYl9sojRp9C+YlaHnhhPA1j8e19JFRTLq3rBjHtACal9xD7Wj46N/tOxxlTWQwBlj0HmMgJJGDwL2WxQK2nYxZttwDZuM05nqQuImWT2wkBNhwx67tJaA+zDHiyX2XY/sA66r4HzYv2ityItt++1JKEOsHR4w/YFDirxfd8kOaaV4h4s+gAW9zTXY=; 20:ZG9KQ2wBQyvURcc8pr5noN1tc+3pVUvapMcbPXOi9glCVpqn9CvKg1jY/8IjZxRqIK3YkUB0e4KvZpuFZb2ik5rcHmuc+pV36ijBr4ULHrGL9Txc7tHQLDgT7xmeS+r1ABLIpksCM5GlbW4TfswrOKkInqhz5K09USuN1AsO+6/V0rXI2ZP6R+xlYHsl7PJ3/E+xj39RvREPKbv0ui11EAgrqAUDnyH/IjHGflRCbvxMfq1g9ykEBBUu3vlOIMty+sGqgceFJjJqENDhMIjQjxj8/UtyMd8zUYKgqF7ZESv42mGT9WuMJFfb620efEeUSU8mAqaqJHP7geAn9vMu3uoSsbm3uO9pevskjf0i69f4x9SzwCUo0XaI+iW9vsO6uhlL2XZGlS9J+f+BfO/JV1xiutVcWkePfMc/hglt4tJ0kDeDuUg7iJZyHHMrujuKEM+NU2wmM2GLd8HB2mFGfpn5GzZ9P1Bh+2b3PPk7P9SKpxq57gm2dZ+a29HgKBHv X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(166708455590820); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040169)(2401047)(13017025)(8121501046)(5005006)(13018025)(13023025)(13024025)(13015025)(10201501046)(3002001); SRVR:CO2PR01MB2151; BCL:0; PCL:0; RULEID:; SRVR:CO2PR01MB2151; X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2151; 4:fldWwnhkPxTQGM3Dk7w4JyhO3DZ7dmp5Tq50Lo8v29aRmAwmRbLWaQGS8dt3cSrIk8G/C0eRucQY2dWNm31ah1tk/mcZnoNalYajKirV8UZDp4N84fC2V8nNtpvQeFxbhvCvwZ9r61P00TFTRAFqfzKnDCaZxh1yPLLnvvqBCAS4rrib8hVo0go8vwT+KtKAv0OLkzRHIv7yP9RVVJID5xIiJifQgmcTzSB+QSH1rI85zjrVmqyomRr54nmqjH2ioovmUT0aDJF1p3MiEvT7qJDvd05tWTAwGw9SkvLNdzw+I/h4z4gsXl8GPdPg85gP5FfIBbQ7CTjkNmG60vdeXKrUepYiXxB4yILHTsz9T9lJvkPBfO28XX/YVg/qKoRJVozeWG0GqHinqrewMks/hH5KZoYJO/MnEZAq+dFrc3yU0Ld4lvq1PjMJq7td6M10ieX2q12dq9WahNkIPZIWFKvupvmUvSB5is7RsyucpSTZjcoPggFBPjDZTDfqr9gb X-Forefront-PRVS: 0030839EEE X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtDTzJQUjAxTUIyMTUxOzIzOk9mb1VoSkIvRlRSa0RRUGxSMmwwMVBlZlVq?= =?utf-8?B?a3Nwd0RkRi9UYVViS2h1TFhGcS9CanJTWFp1SGRINGtNWTFhUE5sbEJGaHdZ?= =?utf-8?B?ZGlJYjN2ZXVGdzk1MXhGTzZiaVA2V3Q1WHU4SlFhRWZCNHVHd0t2MUJ3T3ZB?= =?utf-8?B?THpuSHRMc3hmbTVTcU5MRWcvcEJPZ2xLMW5OUHVhb1lsYXJYSExnN3RkMmxK?= =?utf-8?B?amNXS2d5MVZOZEpQdlFMVmVqTlp2ZlBGdFI0SEpBaklqdm9NelJ4eG90ejl6?= =?utf-8?B?WUtqYzM2RXM3c3VyTm5XcDY0cHpnWnZuWldaZ3BuUURCbEVZdEw4THA0NE5z?= =?utf-8?B?SjdmYlZkcVJLVFZvOVZzZ1NLSG9vSVZKVWZZNnJxazVOa1pWOFQ0eEZLUWZq?= =?utf-8?B?U3J4c2xKbmhLa0VXemlBamYyQyt2M1BxSUN0YUNEQllwc3ZWUnYyVVltRkpT?= =?utf-8?B?citEUUVIdkFiVW1KVjZKMENEcVhlSHBaQSswS2NHbHFUQ3BLTkdxVG1HTGlD?= =?utf-8?B?Q25zSjRnaGNWeTB3NEN0OXR3eEhpOC8xTFhkSkpmRTk4amlPWlEvN3VIU0Rr?= =?utf-8?B?OWpPRElBSGlucXFnZ2xhSVNxMkNEckQ5ZEpES2paTGhBM3VVbXRIOTVUdEE5?= =?utf-8?B?YU5zZGdSQjM3WmpYYVBSZk0xWnRaVjUvN0JZaW1jMXMvQSt0TnNpZGtVSDh4?= =?utf-8?B?OXVqdlprT2pzUXJoazRJWDVsYjVVaG9NaXBiTlpaeDdsSm9zKzlNU1NjVFVE?= =?utf-8?B?V3liQ1l0L1VQU3MxeGxoVmpHaGhGaHJGQTVIUGo0YjdOY1BsU2dieGIyRGZN?= =?utf-8?B?ZVJPeEpIQ213QWd5OGNEaUxuOVhMbnlVdHFhZFNVUnNuQzY1NFpwamZkQU1q?= =?utf-8?B?cjdMU1NscVpIVG9rejNKdWJ4K2lWQ3A1eHN4TVYyOGRvZVFuT1hTbkVRa3VS?= =?utf-8?B?RC9yNEZNbzBVWXJObDFXWTk3Wk5lNmJBWCtwSFNYZE90SzRHcTlXamNLU21N?= =?utf-8?B?RTIvNnh2V2xmeG9KNk9aSzlqQXoxWS93N1paOU40K2hJNHJPSlQ1SHc0OTJl?= =?utf-8?B?SXJkRTd6KzhFdG5IWHlmTklIcFVUUURBdSs4UnNhZ1BqQTR1RUZKMklzVjNi?= =?utf-8?B?OTk0VWZNSHl4Z2NNNXA2S1FMcHRpUzVhaFpaMVhrbkd4STZ1aFE3NDl0WER0?= =?utf-8?B?ajdwYWNCNDFzaEtmQS8ycUlldlk0T0pGQkRWakpaMDNidEZyUytEMDBHN0U4?= =?utf-8?B?ZjQwbmNXYlRkU211V1lwRUpmcm1aeFZXcWtOLzc4cDFWWlo4SldSWENJZHRn?= =?utf-8?B?ZnZBYzBQZHlORWY3TnBQZ21SMTVNUmZ3S1prd2t4VDhlaTBzSWdMWnFYNlNw?= =?utf-8?B?Vm8yV3VyU0pzYkVmYXF2TGNsTkFnY000ZWZpSFNxQkhCV3hhN2Fuc0lXTTN1?= =?utf-8?B?S0pMYUUrQ0dxRWYwd3Fnd0hOR3NMbDJjL2ZFNXZJaDJJdG0xSXp3VjNMb3gr?= =?utf-8?B?ck1CUjI4QWdpU2dhUllFSVJ0VVdmVjBVZjcvQjhPeHlZd1dhSDJQSDVqeENV?= =?utf-8?B?Ulg0bnlKNk04MUJiczg0Q0I5eDdGMVA4T2VtY0ZsUUdHNXpScHdoMnpEVUo5?= =?utf-8?B?UVBtZHNldG5BNTJFQ0g2OXJPUmwwWEJ3NWNVTi9FNDRBNTlETG5tM1NJa2Nj?= =?utf-8?B?R3Z3a3hDLy9rdmN6bStmOHZoSCtkZ2t6bkprV2szMm5BK09lSHJrR3pqbDZ4?= =?utf-8?B?cGU5VWdibG80T1VOWFB4VzN2Nlp0K2VXMVdPUUxwbDJEcUFmOUVUdDNwb1pC?= =?utf-8?B?L1U2QWQvbUptSXN2UFZqa1U5aTZDUkgrUVg0clljNkszTEV2QjNXOERROWVx?= =?utf-8?B?ZStidHpPSHZGVy9mSXY5N0MvMGsvNnZ5TmsyK25XbVc3WE5JR3pjbVpCem5C?= =?utf-8?B?c3hleHR2YXJXb05lSE8rUFoya0tudytXUjlQaFZKK0ZFYnBCZ2NJRDZxcVhz?= =?utf-8?Q?aQrgnY?= X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2151; 6:FYEXhI3K9bHcr4Dyw5UowRxbfkZ0U11TCC7vnNC8Z7ufDUFaHLucecFC93hKFEygdChC5z6FOARi83NimfTupihwKkX8V09+WZud16gAEVMbnK3sQzMkQURouQ1kdLFMuvrAlmKoaWITMOr5qhV/7m6ON86BsVM3tewPguY1uiEUABiY7Rk02Tk0zPCzHU4Y/AztLgOgekF1yicJL/51MbwuFmd6GoNbd/D5jcDUmkzUJFrEBv6I6PHhYj8HRhDTzyyAYZjrqkVg8wmaVTbxebLaJxSumQSOOqO6x4QNTXk=; 5:GRm7K5svgCzuXkmIFHKW4HsJFCmsbWOiqEgYRbq/s3zH2rHckEd6C1Zau2YKEBxhysrYnGvJ9ldDLDZ3CMxfnVQkTx36rBW+nCUOkap8R/0PzmIXld0OlBS9Nkn8Vrv+OVhwQGna5EukecMyR9jztw==; 24:1+Lce/NI91so8RNibgEEVrIDXJbfNjAXYSbaWM7Tk9TEA8ia8unDiXIK3wr5997JmFBfhV2p2JN0kQSuF818E7fq7ZpWLavBFVzalMTzREU=; 7:MRxG0lQHq4asUKiOVu5/svQC7hQ8YjSo/HrsbM99IxWjoGwpeJjDUjAkU4kLpwtuENjPrIdipbYy0XCdkXsZnsPAZvUWvywf1EmyJX486D9GxueYl3iNfM7D8rbnXLmfs+vMyYR4MhlmDz4t8MXDYP7TQXeoUFJggKtkK1hicVBxERlLUmz+O8lzofEbpIyD61tsxWwP1BELhGzZxcsyoT/EtUq+mHL37XEx/Kez42Fs0fpE0wOxuVbadMxV5cTz SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CO2PR01MB2151; 20:GvZEBNTsLuHrYxhhA8l+tFZiQG0WDPhbUxwkdyt/DAGhMwNB0dfNW/qCoAX23MUSZeCLvya0Onf5gWzInhnvk15DNZpWe4FQQ29yFx8Z6buX4LS3KjDkOnVaG8vnItBQHOXfOsYLs9AQmcAbqq70pKYmzTysGRVMn6EdmCaHpsA= X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Aug 2016 23:04:40.5082 (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: CO2PR01MB2151 Archived-At: Cc: Andrei Popov , Subodh Iyengar , Dirk Balfanz , "Manger, James" , IETF Tokbind WG , John Bradley , Martin Thomson , Nick Harper Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 10 Aug 2016 23:04:44 -0000 T24gOC8xMC8xNiwgNTozOSBQTSwgIkJyaWFuIENhbXBiZWxsIiA8YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb20+IHdyb3RlOg0KDQo+IEkgYmVsaWV2ZSB0aGF0IGlzIHRoZSB2ZXJ5IHN1Z2dlc3Rp b24gdGhhdCBzdGFydGVkIHRoaXMgdGhyZWFkIChhbHNvIA0KPiAgICBpc3N1ZSAjNjkgPGh0dHBz Oi8vZ2l0aHViLmNvbS9Ub2tlbkJpbmRpbmcvSW50ZXJuZXQtRHJhZnRzL2lzc3Vlcy82OT4pIGFu ZCBpcyB3aGF0IEkNCj4gYW5kIGEgZmV3IG90aGVycyBhcmUgcHVzaGluZyBiYWNrIG9uLiANCg0K T2ssICpJKiB3YXNuJ3Qgc3VnZ2VzdGluZyBpdC4gV2hpbGUgSSB0aGluayBjb29raWVzIGFyZSBi cm9rZW4sIEkgZG9uJ3QgdGhpbmsgb25lIGNhbiBzdHJlbmd0aGVuIHRoZW0gd2l0aG91dCBwYXJp dHkgaW4gdmFyaW91cyByZXNwZWN0cy4NCg0KLS0gU2NvdHQNCg0KDQo= From nobody Wed Aug 10 16:05:13 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 0E16612D090 for ; Wed, 10 Aug 2016 15:56:11 -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, 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 (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 p96GOEu_uSu6 for ; Wed, 10 Aug 2016 15:56:08 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 45DFC12B038 for ; Wed, 10 Aug 2016 15:56:08 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id v123so17640437qkh.2 for ; Wed, 10 Aug 2016 15:56:08 -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:message-id:references :to; bh=2C1sxqIvwoqBZXLUWvLE7wTu3p4YBsVMJaYOr/Ge5AA=; b=joSfErCwL7I1Rb70/wovFRwsvmWx6gbBNbGTfXkSrS9tC0hvsABNx4uwoyIhwn9qaH aryEUC2iQeUind5eW0TTCx8Aq1K51uUlgI6P1CacwzlEfum6+fKKifnEUaPz5aFjpUWP GMiheY9jw89KR6JgAJXAV8SgsXVUbQTIh8N6wjA/9H3q+cn1QR6gShZPBIA0zkVkqp/D H63p2nz4VHEIInFN3Wka30+eDUJI6BA2C2897VDxQ8RPdCPD8tQ79kOmfwWkY2rS/SUf +UDx7byw2pZQjCcTJXKrEjXZL6U28jTcG2fPni3YWWijudLlfwdBxnumJ6AN/aa3YxxN amzA== 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 :message-id:references:to; bh=2C1sxqIvwoqBZXLUWvLE7wTu3p4YBsVMJaYOr/Ge5AA=; b=LIRWtNEJ8yp3hS6YxM5zWS6GywrFNhcAGozOWeHxLRbI5wcLei/7sa+XweSe3GUbWt q31bz4pAZ1YjVPVpsDd5JVfbNHtVqoYqDqix+vjedAb3K6NwndZdL1qF2wdbKrvoXN1C URSg/YnRFn7PMaOtdRjrkDgQq9eIQZb0hqHtGUQulJ583DuRQJXv3ydJyz83fJ+D5Zrt sBnUKIVSTGelGhQkI6hd0mKDoKiGYzSgVb81psjjX8bbz36dd/Ivohm2GyMiDEurojue xBUbGWUU0nZlFY/YcYVkCUAv65PJiLx3xKztzzJwWWLoZamBQ32drqLkUbiaYBTkwewp edmQ== X-Gm-Message-State: AEkoouvlMJ4y9ARn0g10mA+LtiAyMSiwfrrDCMqOBl9rN8Rp4DLKqdM01sQGdEm7BYNiBgls X-Received: by 10.55.43.130 with SMTP id r2mr7853563qkr.223.1470869767099; Wed, 10 Aug 2016 15:56:07 -0700 (PDT) Received: from [192.168.1.49] ([191.115.111.163]) by smtp.gmail.com with ESMTPSA id l63sm24574466qkf.16.2016.08.10.15.55.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Aug 2016 15:56:06 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_EAA129BC-E6C9-44DE-92E9-97344588DD3B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Wed, 10 Aug 2016 18:55:44 -0400 Message-Id: <51A394CF-4480-4946-98F0-6E7A93190B2D@ve7jtb.com> References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129E2F59@CIO-TNC-D2MBX02.osuad.osu.edu> <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> <0F5C7253-5A94-4855-B3F8-80E098209622@ve7jtb.com> To: Andrei Popov X-Mailer: Apple Mail (2.3124) Archived-At: X-Mailman-Approved-At: Wed, 10 Aug 2016 16:05:09 -0700 Cc: Subodh Iyengar , Dirk Balfanz , Martin Thomson , Scott Cantor , IETF Tokbind WG , Bill Cox , Brian Campbell , "Manger, James" , Nick Harper Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 10 Aug 2016 22:56:11 -0000 --Apple-Mail=_EAA129BC-E6C9-44DE-92E9-97344588DD3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good point about the hardware support. That might be worth documenting someplace, so that people later = understand why we made the choice. Use RSA if you have hardware support for it and not EC. If you are = using a software keystore EC should be preferred for size. Something like that. Otherwise people will wonder when to use one over the other. John B. > On Aug 10, 2016, at 6:13 PM, Andrei Popov = wrote: >=20 > =C3=98 So Andre, I take it that you think dropping RSA at this point = is not worth it as we are going to want to have short representations of = keys in the higher level specs anyway? > Yes, I think there are good reasons to have short representations of = keys regardless of the algorithm. Even if we were to drop RSA now, we = may have to use long keys with a future algorithm. > =20 > =C3=98 So yes I am being provocative, but I would like to have a = answer that the WG has thought through on the list about why we are = doing RSA before we get to the IESG and someone asks the question. > Ideally, we want our TB keys hardware bound, and unfortunately a = variety of hardware devices (notably, TPMs) don=E2=80=99t support EC. > =20 > Cheers, > =20 > Andrei > =20 > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Wednesday, August 10, 2016 1:00 PM > To: Andrei Popov > Cc: Bill Cox ; Scott Cantor = ; Subodh Iyengar ; Dirk Balfanz = ; Manger, James ; = IETF Tokbind WG ; Brian Campbell = ; Martin Thomson ; = Nick Harper > Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for = different key parameters within the same TLD+1) > =20 > The representation of the token binding ID in a OAuth Token or = ID_Token would be a higher level spec. We did introduce those to the = OAuth WG. > =20 > I think it was you or Dirk that argued that we should keep it simple = and just pass the whole opaque token binding ID both in the token and = when we needed to refer to it in a parameter. > =20 > In those specs we initially defined a SHA 256 thumbprint of the token = binding ID. To carry as a claim for the proof of possession. > =20 > For cookies using the token binding_id as part of the encryption or = signing key via key derivation seems like a reasonable approach for long = keys.=20 > =20 > For OAuth there are downsides to using and maintaining symmetric keys. = Signing the tokens with asymmetric keys has big advantages in = simplifying key distribution and rotation. > =20 > I think carrying some representation of the key in the token will be = required for a good number of the use cases. > =20 > However the encryption idea is interesting for cookies. > =20 > So Andre, I take it that you think dropping RSA at this point is not = worth it as we are going to want to have short representations of keys = in the higher level specs anyway? > =20 > We are currently recommending that servers support both RSA and EC. =20= > =20 > Are we thinking that some clients would only be able to support RSA? > =20 > I am guessing that browsers will all have EC and I suspect Windows and = CroNet will have EC. > =20 > So yes I am being provocative, but I would like to have a answer that = the WG has thought through on the list about why we are doing RSA before = we get to the IESG and someone asks the question. > =20 > John B. > =20 > On Aug 10, 2016, at 3:04 PM, Andrei Popov > wrote: > =20 > To step back a bit, TB specs explicitly avoid specifying methods of = binding tokens, although they do provide examples of what could be done. > =20 > Even if we were to prohibit RSA, we can=E2=80=99t guard against a = future algorithm that requires a long key. > =20 > The simple solution is to hash the TB IDs, and it works regardless of = the key type. It is also possible that Bill=E2=80=99s idea would work, = as an alternative. But IMHO this belongs in a higher-level spec. > =20 > Cheers, > =20 > Andrei > =20 > From: Bill Cox [mailto:waywardgeek@google.com = ]=20 > Sent: Wednesday, August 10, 2016 11:47 AM > To: John Bradley > > Cc: Scott Cantor >; Andrei = Popov >; = Subodh Iyengar >; Dirk Balfanz = >; Manger, James = >; IETF Tokbind WG = >; Brian Campbell = >; Martin = Thomson >; = Nick Harper > > Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for = different key parameters within the same TLD+1) > =20 > On Wed, Aug 10, 2016 at 11:15 AM, John Bradley > wrote: > I have been looking at using Token Binding in OAuth. >=20 > Because RSA Token binding ID are so large we are probably going to = need a thumbprint of them to put in tokens to keep the size from blowing = up. >=20 > This adds complexity over saying just send the token binding ID. > =20 > Minimizing token size is important, so I'd prefer just to have a = 64-bit fingerprint if possible. To do that without creating the risk = that attackers can create key pairs that have the same fingerprint, you = have to randomize the hashing with a secret of some sort. If this = fingerprint is in an encrypted portion of an oauth token, then the = randomization key can be derived from the decryption key, or something = like that. > =20 > If we instead store the uncompresed EC keys, it will take 64-bytes, 8X = larger than required. > =20 > Just some dome brainstorming: what if we encrypted the oauth token or = cookie using the standard encryption key hashed with the TB public key? = That way we verify the TB key by successfully decrypting the token, = without increasing the size of the cookie/token at all. I think this = falls under the concept of AEAD, where the TB public key is simply = "additional data". > =20 > Bill --Apple-Mail=_EAA129BC-E6C9-44DE-92E9-97344588DD3B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Good point about the hardware support.

That might be worth documenting = someplace, so that people later understand why we made the = choice.

Use = RSA if you have hardware support for it and not EC.  If you are = using a software keystore EC should be preferred for size.

Something like = that.

Otherwise = people will wonder when to use one over the other.

John B.
On = Aug 10, 2016, at 6:13 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

=C3=98  So = Andre,  I take it that you think dropping RSA at this point is not = worth it as we are going to want to have short representations of keys = in the higher level specs anyway?
Yes, I think there are good reasons to = have short representations of keys regardless of the algorithm. Even if = we were to drop RSA now, we may have to use long keys with a future = algorithm.
 
=C3=98  So yes = I am being provocative, but I would like to have a answer that the WG = has thought through on the list about why we are doing RSA before we get = to the IESG and someone asks the question.
Ideally, we want our TB = keys hardware bound, and unfortunately a variety of hardware devices = (notably, TPMs) don=E2=80=99t support EC.
 
Cheers,
 
Andrei
 
From: John = Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, August 10, 2016 = 1:00 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Bill = Cox <waywardgeek@google.com>; Scott Cantor <cantor.2@osu.edu>; = Subodh Iyengar <subodh@fb.com>; Dirk Balfanz <balfanz@google.com>; = Manger, James <James.H.Manger@team.telstra.com>; IETF Tokbind WG = <unbearable@ietf.org>; Brian Campbell <bcampbell@pingidentity.com>; Martin Thomson <martin.thomson@gmail.com>; Nick Harper <nharper@google.com>
Subject: Re: [Unbearable] Revisit = eTLD+1 (was Re: support for different key parameters within the same = TLD+1)
 
The representation of the token binding ID in a OAuth = Token or ID_Token would be a higher level spec.  We did introduce = those to the OAuth WG.
 
I think it was you or Dirk that argued that we should = keep it simple and just pass the whole opaque token binding ID both in = the token and when we needed to refer to it in a parameter.
 
In those specs we initially defined a SHA = 256 thumbprint of the token binding ID.  To carry as a claim for = the proof of possession.
 
For cookies using the token binding_id as part of the = encryption or signing key via key derivation seems like a reasonable = approach for long keys. 
 
For OAuth there are downsides to using and = maintaining symmetric keys.   Signing the tokens with asymmetric = keys has big advantages in simplifying key distribution and = rotation.
 
I think carrying some representation of the key in = the token will be required for a good number of the use cases.
 
However the encryption idea is = interesting for cookies.
 
So Andre,  I take it that you think dropping RSA = at this point is not worth it as we are going to want to have short = representations of keys in the higher level specs anyway?
 
We are currently recommending that = servers support both RSA and EC.  
 
Are we thinking that some clients would = only be able to support RSA?
 
I am guessing that browsers will all have EC and I = suspect Windows and CroNet will have EC.
 
So yes I am being provocative, but I = would like to have a answer that the WG has thought through on the list = about why we are doing RSA before we get to the IESG and someone asks = the question.
 
John B.
 
On = Aug 10, 2016, at 3:04 PM, Andrei Popov <Andrei.Popov@microsoft.com>= wrote:
 
To= step back a bit, TB specs explicitly avoid specifying methods of = binding tokens, although they do provide examples of what could be = done.
 
Even if we were to prohibit RSA, we can=E2=80=99t = guard against a future algorithm that requires a long key.
 
The simple solution is to hash the TB IDs, and = it works regardless of the key type. It is also possible that Bill=E2=80=99= s idea would work, as an alternative. But IMHO this belongs in a = higher-level spec.
 
Cheers,
 
Andrei
 
From: Bill Cox [mailto:waywardgeek@google.com] 
Sent: Wednesday, August 10, 2016 = 11:47 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: Scott Cantor <cantor.2@osu.edu>; Andrei = Popov <Andrei.Popov@microsoft.com>; Subodh Iyengar <subodh@fb.com>; Dirk Balfanz <balfanz@google.com>; = Manger, James <James.H.Manger@team.telstra.com>; IETF Tokbind WG = <unbearable@ietf.org>; = Brian Campbell <bcampbell@pingidentity.com>; Martin Thomson <martin.thomson@gmail.com>; = Nick Harper <nharper@google.com>
Subject: Re: [Unbearable] Revisit = eTLD+1 (was Re: support for different key parameters within the same = TLD+1)
 
On = Wed, Aug 10, 2016 at 11:15 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
I have been looking at using Token Binding in OAuth.

Because RSA Token binding ID are so large we = are probably going to need a thumbprint of them to put in tokens to keep = the size from blowing up.

This adds = complexity over saying just send the token binding ID.
 
Minimizing token size is important, so = I'd prefer just to have a 64-bit fingerprint if possible.  To do = that without creating the risk that attackers can create key pairs that = have the same fingerprint, you have to randomize the hashing with a = secret of some sort.  If this fingerprint is in an encrypted = portion of an oauth token, then the randomization key can be derived = from the decryption key, or something like that.
 
If we instead store the uncompresed EC = keys, it will take 64-bytes, 8X larger than required.
 
Just some dome brainstorming: what if we = encrypted the oauth token or cookie using the standard encryption key = hashed with the TB public key?  That way we verify the TB key by = successfully decrypting the token, without increasing the size of the = cookie/token at all.  I think this falls under the concept of AEAD, = where the TB public key is simply "additional data".
 
Bill

= --Apple-Mail=_EAA129BC-E6C9-44DE-92E9-97344588DD3B-- From nobody Wed Aug 10 16:30:27 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 DDC1412D56F for ; Wed, 10 Aug 2016 16:30:26 -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 cE5oGw-oWrr4 for ; Wed, 10 Aug 2016 16:30:25 -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 DF1A712D0F9 for ; Wed, 10 Aug 2016 16:30:24 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id p186so59342199qkd.1 for ; Wed, 10 Aug 2016 16:30:24 -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=EQDlZM+aM3VT5rhmev7l24YggbaM1AHYTqUxpLFK8hg=; b=TGQt1qeGZXMDVCHu/iNB/QuZypOSvaXi40Hl5Ixf7pkzPxvHFxnriqATYSJKfs/fq2 wd2txPIVIedydKtls5oAm0UM2rflXd1Xzqa4ytrVcUiivy/lhLccfDyRqRUxmbGVcypP GeJBFNApv1aD8fDGk8m5YbLo4xclsqtEXSr2rX3n6+kvQppM8jMAvCt4Hk47ZNCmoMjt iYCNgKzZoOS1G01otP3aL27Vrv2FWn3YQCscbHGLwIv9gKs8JmPMNXCiYQRkcykv0mty Vx5YZjJ4wiHdo1pKde2Cq3q/TxLCYq+aIgzDXYr3J26LXqWr8WvynxJPjDXXNha7lkVd 9Bbw== 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=EQDlZM+aM3VT5rhmev7l24YggbaM1AHYTqUxpLFK8hg=; b=aMSx6fpawCWcsLQuNfFVRC3yO7hHdEsHESzfMbnWWVA5enNj0r+je6S0f0D2W6JbbN R608NjrabDgXJi5Yy/XfLoIorh0Q/DRqFkX0nwzXuNgb73gU6RQzHJoKhjVPqG+wDYuy eJpRBY37WEGPOr8XvZTsz7vG7+kYXkHlt/7BCaC+LrV4LTrPhKd1V+8EOwj1nKKeNMdR mW4EOkPl7qlqyKDOhLk+Oywie33Bds8cpZRDfl73J1iyR3nfFen3eb07Dgk4cS0mJPN0 0URqDfxg4YL5Muz6w3nWw5im4yZH+MMN6TU7Ls/7K2N7nNA3lf98zvM28LXCTW+yl9eJ mUQA== X-Gm-Message-State: AEkoouuLincY72LJstQxSM6jR8qc7TdeJNeoSGsLsY/QH0yHhaBurLBECsp2+DqQs3JiMuyt X-Received: by 10.55.190.199 with SMTP id o190mr7766283qkf.51.1470871823783; Wed, 10 Aug 2016 16:30:23 -0700 (PDT) Received: from [192.168.1.49] ([191.115.111.163]) by smtp.gmail.com with ESMTPSA id h186sm24707162qke.49.2016.08.10.16.30.21 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Aug 2016 16:30:23 -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: <84F8594F-59B1-4935-86BA-99F758BFBF0B@osu.edu> Date: Wed, 10 Aug 2016 19:30:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <18776400-6439-4F6C-9F41-08F61B3DC58B@ve7jtb.com> References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129E2F59@CIO-TNC-D2MBX02.osuad.osu.edu> <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> <9846A6064BD102419D06814DD0D78DE1129E303A@CIO-TNC-D2MBX02.osuad.osu.edu> <84F8594F-59B1-4935-86BA-99F758BFBF0B@osu.edu> To: Scott Cantor X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 10 Aug 2016 23:30:27 -0000 No Hat. I think it was Martin=E2=80=99s suggestion to move to strict same = origin. =20 You asked the question so are guilty by association:) Personally I have sort of mixed feelings about this. Moving to server configurable token binding scoping really only helps = the people who aren=E2=80=99t going to participate in correlation anyway = not collect information that could be used for correlation. It seems a bit like some governments who mandate the use of persistent = subjects (pair wise) to avoid correlation but at the same time require a = matching data set of attributes that includes full name birthdate and = address. =20 Any bad guy wanting to correlate in side of a eTLD+1 can just use a = cooke or change the token binding setting to use that origin. If I thought that the scoping rules for cookies were likely to change = being more conservative with token binding would make no more sense. Changing from eTLD+1 seems politicly correct, but on the other hand may = just be theatre. Can anyone come up with some real privacy increase that we can achieve = that would not easily be circumvented by anyone wanting to correlate. I would like to have a concrete threat so that we can judge if any = mitigation we propose might be effective. John B. > On Aug 10, 2016, at 7:04 PM, Cantor, Scott wrote: >=20 > On 8/10/16, 5:39 PM, "Brian Campbell" = wrote: >=20 >> I believe that is the very suggestion that started this thread (also=20= >> issue #69 = ) and is what = I >> and a few others are pushing back on.=20 >=20 > Ok, *I* wasn't suggesting it. While I think cookies are broken, I = don't think one can strengthen them without parity in various respects. >=20 > -- Scott >=20 >=20 From nobody Wed Aug 10 17:09: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 3DC4312D185 for ; Wed, 10 Aug 2016 17:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 82AyOITz6q1E for ; Wed, 10 Aug 2016 17:09:35 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0104.outbound.protection.outlook.com [104.47.34.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59E0912D130 for ; Wed, 10 Aug 2016 17:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=buckeyemailosu.onmicrosoft.com; s=selector1-osu-edu; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tPYIN9Ig9NFk3wXa7R2BG65cXRjoa3/konRtwdOedl8=; b=jlbOtdxnpEGqoNLvwy1ufKKQWB6i5YbLwTfk6cb1H9MxgrwudqSm+nUi2hBLdMue7Xi2GaLCFpDwHqOKUrpamrcNiYHA9O3mT2yShypKJwNWmeiSkwOQZEF+zjQ8mqVJitpthVlrZLtZO4CVTm2n5ZGF8gx2ao04eOgHW6Ojm/U= Received: from BY2PR01CA0037.prod.exchangelabs.com (10.255.242.27) by BN3PR01MB2148.prod.exchangelabs.com (10.166.73.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Thu, 11 Aug 2016 00:09:33 +0000 Received: from BN1AFFO11FD015.protection.gbl (2a01:111:f400:7c10::195) by BY2PR01CA0037.outlook.office365.com (2a01:111:e400:2c76::27) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.15 via Frontend Transport; Thu, 11 Aug 2016 00:09:32 +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 BN1AFFO11FD015.mail.protection.outlook.com (10.58.52.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.567.7 via Frontend Transport; Thu, 11 Aug 2016 00:09:33 +0000 Received: from CIO-KRC-HT01.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 137AD3C004C for ; Wed, 10 Aug 2016 20:09:33 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.03.0248.002; Wed, 10 Aug 2016 20:09:32 -0400 From: "Cantor, Scott" To: "unbearable@ietf.org" Thread-Topic: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) Thread-Index: AQHR8aDDx+pDq6EZgE2nj7753s28fqA/p+UAgAIq4z2AAOikAP//ve2wgABM4ID//746kIAAerSA///UuAAACUbSgAAAsQeAAACuMgA= Date: Thu, 11 Aug 2016 00:09:31 +0000 Message-ID: <6c0278e8-891d-0544-0e58-afa526b24cd0@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.14.104] 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)(979002)(6009001)(7916002)(2980300002)(438002)(189002)(377454003)(24454002)(199003)(2900100001)(90282001)(5640700001)(88552002)(7846002)(7736002)(86362001)(7696003)(106466001)(2906002)(246002)(2351001)(50466002)(106116001)(16796002)(2950100001)(1730700003)(8676002)(8936002)(31696002)(47776003)(92566002)(305945005)(7596002)(75432002)(5250100002)(50986999)(54356999)(76176999)(626004)(66066001)(450100001)(586003)(3846002)(356003)(102836003)(2501003)(6116002)(31686004)(33646002)(189998001)(107886002)(110136002)(89122001)(109096001)(87936001)(23676002)(36756003)(93346002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR01MB2148; H:cio-tnc-pf06.osuad.osu.edu; FPR:; SPF:Pass; PTR:cio-tnc-pf06.osuad.osu.edu; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD015; 1:yiZy2sYDFA2fCC1Npa9lfKMM5khjb/bRhMWWDZtx6bLjrsz71ZkyQ7eg86bqt3Tz4IweBMUldVuMc8pfuTG3NEAeBUwRr59pzoVMcvCUpFt3omTvwijumanOrLsZGX50FL/Ra15pdxmVUJTV8ilZ4AqOdl6Np0A3J9TZAWkatZppsimxEkX3mueQ7LHFZbuFlg84jTQFXjmkd40oAr9U6t5nP+H2g0EwwP/VYgDYD65lA1ltsj4MWz6Y0YtSvooLMG7UnGXnwlrllvLD99C7gOwwGSu38YPGbFJ+8xyfawY9lMmJB57Cc4ukgReM4BkSQ9A4THGGKAY0lS1fP1CLVgQGOa0TduGhGsqBjdw3DnqjxFVm22hPuDDCFSfu632KsCnuDfTXqUM5vpLo1pN1nR6DIipTEm+n045amKkcdgjZZxiHSb26LEntLlB2ki2++IvJgc1IlMcyRL6joYiQwUT8qtWx4I9ViL2nN6c4mNupmxTFqGC6znkQNJyl6hjuwxgWzwHv1sj5XwN9t/auDautASTwnSzrY2nuUp1Lx/I= X-MS-Office365-Filtering-Correlation-Id: ac25ad7f-b833-4af9-833e-08d3c17bc5fd X-Microsoft-Exchange-Diagnostics: 1; BN3PR01MB2148; 2:d25kfderpeC+PlMFROHvEa3DMqrxntm5OfcKUmCWOMYo3sB4C/hS6onSUu92hLpS1VXGw2PtyIyrLoVHNYw1hqskN9e1V4wEY9z1lpiDc8M+EMxrHX0/MWB0v2ksdo1eHwz5oIyt5z1YPJ1sWCe/0T2umpMCH/UFQofCpjeDCs/vVNWhpYbPUvfISt1RIBp1; 3:GAkTKwPbYDKAljGbMIEyY0KGXltWVmy1FLv3MeQLN7RtzDzNEDW8rXCeMJT5umIoHWP9i6O7W1bwglFRo9pfwiBbvgylyMOCmSZIElXk+UYYtBLu9JwvyMBW8GcArVAxwC2SkZpfrF9Apnkk6/TkTLyYr4FOhrzDPpJe/tVDx5blTEKWWGW3Y0kqQ8Kr9r3P0q18zUd3ONV9+DV5Fl2c1mSBMU8KODBT+gnKX2VWfedWei4szss1XIrV45Ffz3rl2JV9iQrUCvojMuHDxWh9ow== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BN3PR01MB2148; X-Microsoft-Exchange-Diagnostics: 1; BN3PR01MB2148; 25:XcOdC6WX92grQjApbR7BHQ+nGFheQJo+B1i5ohvZs4PFIFfOPQC4YPj1YJmRrl1/gkixt1xy6Bo+g1Uiw7ZdaMFk5hZkuQCeOv/CVGiyqim/4vQYpWz5OwY7EdQ4upuTW3lTLwyD0UXFxHRYid8dJvqC7IXygDPJtJytY0NjOVVffvAUsdsX6kK/7yhRaUK2hfD7yiQtQtyf8rcBCOQZE1kgrSKduIehmQu+i18IKmT7fjzv/gb1hqtUs9PgVPbkcYxNX2kyLbGGcWx/ue5oKzUDQ/YlY8b7zRHHzuEu3rfFxfqlQkUwmD8f++F/4skBwuF0TCddcPPRNt+ADk4v4Qwa5AI6bZ+44O+EL4fUlDk/+AA2oRA9n9cRjhONn0oqAPNKxzfWL7s07Cd7FEM1WF7m2NaLFVXuZYnIxdS8l8oHQlwkPGlLQZW/1Uq3E/kwahnfNuD1nkq6wEERAOAj1Bjoh18nPFPbWfNz08u6zW8HV53shvE6KH3/QzHGCPh4g3IsL0VE2YGBsaC94Jb5vAcX3Gf740NB4GzvANhZJv2WLLqh7EK7SCEj4kvLNi8zgcFc79+unF0JvOpV7Nbvdcig22TfOBgV2Ua5DsaNf2P5ylGMuKfmAnO+iFDi5Xyx9X09YDEJuSHV7iuGWSw4R3yexW2AQnzV1qN5l1H2SAgSDa0t6hglOXvuSeEftOM8GVgVUDbYVRtVPw9q6ekkMyCD5/N4Gjdpsqoyj32gHrFo4Sj8LopseGV1uHqiTaFW+rCSpHm/6HoB/hA/KhuCeg== X-Microsoft-Exchange-Diagnostics: 1; BN3PR01MB2148; 31:+PVyHqTdBPE+24+8SQXRNU+7pwLsJNkQmkR2q7EzTpWxXDFoDruIj0ScNG6UKxcdZFmYDd4DOfzbUrrzhFvqJgx8wZmEfCMClSx2YME1tty9MRfc+GfNjNhRCRfQwAHPLN92LX36f4QkSC+K8tFzzwLQ2AZEiQeN338B8nCndWgI57pHilxBHXYri8vvzXKmW6Gum7obiBKxPAza64Emie/BdDXTjrlPYze9CwExEgU=; 20:XzbBnCYuJb+KrDsu0dUbGn+gjnw7MdbDGYzADCVAJ8K/pAMMrXqHkRLTi9VbJVuWHpLDZt62V2Rz45HrnPuTGTnLmDpTO3HTZYCSyrsgsFY88Sx6rlfmJrizURtmllbVoCSCz+SQ1Fwhvk0RM9OVYTXU4E36IhkScbKpcqmhnZO6Hsicwk+ves5Bz6N04/YijXgF9od5pCmttuEwCxcMr1c4VsNY0cDR7drwFuX+yOk4yCXoIjDpvqg3TghZRU9hqZ0Q49yr4tXjHvs7dPTLDdo12W+BWkhSkdxLwqS1pye2h0nM1PCQuEAXIODylrG4acUL7qRFRxHxKRzd8Y7+ktNSGzhTC95Hio8tae+gAHC1aNf+TNxbXQAcGfm+v4FP+z+lpDRLRIl8hg6AnRkGnrkz7IxTfQ/e4d7aBs2o3ZAz0+MJAjcm05UVc+EN/BQP0sqs5d7uzDq8iy5pzRp7yWqL1hqMAtH3cDmGOQQy3SF/ggxchrN/hAD0gpmHWAig X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(2401047)(13018025)(13024025)(13023025)(13017025)(13015025)(8121501046)(5005006)(10201501046)(3002001); SRVR:BN3PR01MB2148; BCL:0; PCL:0; RULEID:; SRVR:BN3PR01MB2148; X-Microsoft-Exchange-Diagnostics: 1; BN3PR01MB2148; 4:mcPmO77++zObtVpBqGrYjNB9Ds/D61CxUrYIOXME6tHGhstsrmX7tn3z2h4lEvvPW7QUpxPwe/m7bI/ee4H474aXKfZ3P/lhIejMLtKhqcflhhwIVA+74zrlyB6QQ6TtXXjzJzusrZjQz0H8h33poVsb5eDdUSpd5jgASUbPVcj+2rPBjRfRapoGBso3l067EOz6sLrPgb8JeGKkNY0DGLIVNPo23sqeRc/5XEL0HrsCIQ4HiPZiNIJDMZ8tXWmuyeV6GYfRPyQxVEiqutg5N1LlJVZsgfjNXsiZ5JgM50RDcdeEaCkpdbFC9OEND6kv/7BUyqC1meLr3IKY9LoiNixHQPPK8p00jL5pC8VUkqXkwkv9TBJ144Rxu/Ym7ADiEDoyWcPThd8HVTD/XyRtBmg2YoFA8ux9CGv/4q4qvUsLqlO3+pbxmq6VTP162itO/PNUOw3SAV/CaQyuTgQ/0TlSEOfRuLq+oP8bVYysTmU= X-Forefront-PRVS: 0031A0FFAF X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTjNQUjAxTUIyMTQ4OzIzOndNUjc0SUhrSzNPanZzb01JRkJhSWI5OVhx?= =?utf-8?B?MXJCV0lTTXVqbXBlWk9kR0Zia0FBdVdxckNLVytIcmgwMkpHd1BsK0xCSHRm?= =?utf-8?B?aWdGSzVWYm9FMHdiNlJaTjJaRHpoa2Z5Sk1MNE5RVHZHc1dHYVg1VjdBZUJM?= =?utf-8?B?Y3J4eEJMZENhYzhWVEFjeGFJelJxVUprVnd2dlh1ZnIzbjY5Q0lIcGt4bVd1?= =?utf-8?B?WGZMdlVyYWdLQXplUk1kNEh0cytTVzhLMlAvVjdnTjB3eTduMmh5bWdEajNC?= =?utf-8?B?YjJ0dlBpVXR2dGRQWkdYeG9oMlBtb2Rua2xHQTNRQkJWc2NWOUVzbmJHdkZB?= =?utf-8?B?YlQ3ZFFsb2p5RnVZWVJ0NzdCZ2cxaXNTc1hKdThGYU1TeEJMbzV3ZXB6Ti9X?= =?utf-8?B?WGd1ZjF5am9hbndBdkhNZzU2dTVTOHJuSmpZMHpMVm9udEhsNjZ2M0puVWpZ?= =?utf-8?B?V1VuY0ROYmhiUFIrdWE2Mmp1UTNjdWlUOUZmMEhhNzBCR3lDSnQvaGlPdWox?= =?utf-8?B?WHBEUXhGaFVLd2tZU1NNOHJUYWJjd0xvUVQxSzJIWURjTjVQQkxvME5RbGFN?= =?utf-8?B?UG5salE4Y05QdExIai9iRmJ5YzU1TU45ckQ2NFVpdXh4Wm9qcUxiOGhoU3dC?= =?utf-8?B?SkwwR21YKzErNHJWbXpnVnVRQkpPODlKeHVDSDV0dlJKV0VuK3ZNYjN3ZnJV?= =?utf-8?B?VExLTi9taUZoL0dGTkQ3Zjg1WStKR1BKeFdvNjd6VXN2OXlMWlJXUlJoNkRY?= =?utf-8?B?ZWViaE1TQVNpbER4L2tCVHM5NVllaFBPemkrYTd2YlllVFR1R0FFMyt3WGox?= =?utf-8?B?R2dTZXJKQ2lUTVplNm05VzBtVUxmdE1JTC9acmdhZXBhYWVkdVVZUnBWWHJP?= =?utf-8?B?RGkrVGRuVjg5M0ZRMVc1OWw2by9FbGVVRmJBaFJDalR2eTlaY3g0N3J4TEtU?= =?utf-8?B?aXFNSDJKc0E4b0RNbG85SzFGd0ZNRWdlTDEyQUU0MXIzVUFFdGZPWHdyeFZX?= =?utf-8?B?T3llOTJBazExY1ErZHNoR2lsYnhib1p5WjMyQkZKQU1tYmdma1E3N1ZZSEY1?= =?utf-8?B?dEx1K3RpY3VNZGJjRHg3L2ZmOFoyaEIwaU5LOVY3bVRtV2tCU0VXRXA0eWVp?= =?utf-8?B?bVdOSzYrL0ZKTjV5OGUvQVduWitnQzh0dU1aWHBmN3Fqa1lCcmZFcXozYjFR?= =?utf-8?B?WWpRMmxXZkNvd093TUZLaUtZT3JpYzFQRWFVOG5MMVJqajlZeklxWUk0VG5j?= =?utf-8?B?aUFmME5Ld3c4UTFpNFl2NTM2a1RTdW8ySXc1VUFnY0dOOWdQV2xnNk54dDBn?= =?utf-8?B?QWNWUzROaWxmazBqOUpNRjZWT09YbnVOZzJnVXVreEEvUjRqQVJ2L0ExNEU2?= =?utf-8?B?RTdZZVh2ZUxJMW01VzFZV05PZzFJWEJabUlPWm84MTZaOHIzVjcyNjJKS3pO?= =?utf-8?B?OS8xUktJUDlidVJiQkZrK1hsZzlNby90d05WYXBUaXVLbTl2dFRFc2dMeTlZ?= =?utf-8?B?TC9KQ1crVjVyVmk2Vmhodis2VkpCdEt2NDNlY2N0cHlvR3M4bGtuNzhtdUpQ?= =?utf-8?B?ak11QjlWOWYzYnJjOXdCOFVMT01XMm1hWVExTVgwbzJpMDZ0TzZJaTY0SGFY?= =?utf-8?B?OHdWOEdaTnAxTTg5ZFYyTlFWWHBGeDZsUzAwdUZvU0RmRkQyTzBxdGcvV1g1?= =?utf-8?B?N0dJQUFmL1hLTWRHaTRFQy9GSXphRnhyOG04bHZkQmM4U2g4TTlibS91OExH?= =?utf-8?B?UFRIVFd1WFpKUFJzYWhGVlRlRmxrZElKeUwwbnFTdHdsTmpxc2c5bzRzOWdU?= =?utf-8?B?QVpFOHdZaVdQOGkxK2FKODdmRDlpRHpzY3ltT0R5dFcxK2wyUzlwZVhDaE9D?= =?utf-8?B?Qi92UWZQQkxRVDhZSUVzODE3REJDTlo0aEJuaFRIZEFiTXFqY0xXa3lnUUdT?= =?utf-8?B?SXZyWkhwbE15Qm80VGc3NGNVNGtJK0k3dEtpTlBHZk0xNzNSNzNneUo2akpD?= =?utf-8?Q?arHR5v?= X-Microsoft-Exchange-Diagnostics: 1; BN3PR01MB2148; 6:oKjF1+YGd8kk3sdKaIbhkM75dydOwmo5eSUl8P7yeXLxsMn19uFtmGOSta6EQr9/6i5HvM3C0RpGEfg1Nsm/CHCNyfATn6qzpTNdX93sZvVlNZzFdoe0j0RGX8omcC/Ks7OwC/dv34XJUNa6MF+SuJLVZc4W06buFyU/dFGkIz3pnnYp1Ze+5n+dwobe4bYrz3gRhinwemJ/O66GzZeGy4l3nI1oyuRmngBqzlJQzJyB29OgnRDFmp7TeKcYwWJWq5YN+kxkbjJ8CWuJ1BQ+2HlS42rK3ZmMzwbnVD7Rvus=; 5:BxWe64Gqum5NKGlFggvkTRXTSmhe/ez/ZNSs5ntx2jP5AqWu6gNsItU8YnSO4YaqvHN7fjec3jS6I2Qg5UqXaQkP5s7IVrdONcdSUY8/yzYavcKfoloy2ZVCwZRMgLDJ4c/831HkACI0Zy641oHykg==; 24:lLbKJ/DyobMe3ZgqeJUj76Ojy2wS+gOSbTtG4x3NNWUMZaXO95hEvfthLcWa973Z+6wPFUfI7KITheCedQYBG0rN+lm13iDOq7QP/B8o1Gk=; 7:UmBFaoONquw0FQAKj9lnBl+RwbLFn//RfUTvzskd7m3VLPC7ZIJRwyH/YU0GTZ4+QTYe0tY3pViahi9E5lQZwt7B09aLcRu7KdSqkgo5Q7ztpU6elFLogfAML+ZPLFbkaolwq/HukflVvofEnbyt8kfPbuIYZ5+sfmTVCy6WnxmSbcOcfCYfkxhimufONfDZnWKcgEqtKs5epCdJmahOisnNYh2SOsCADDaDhyxLk93CZ2KlpFOUQ0znVBD9QmGZ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; BN3PR01MB2148; 20:vDbxIcG51TZ2tRPXHy3T9hEPFffdnQpFpnQ/KydqTQey89375o+CvMQTgik6WBGZjPOko6SYoddbxyBCBUkDT2S+8eBdM/wfXhV2XW98IGbQHfI6cQmTE+V7ANkgAwX1UMssDmfm6sPo5IzKTHWDWN4WuJWarelAAVAa1eHmcyA= X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2016 00:09:33.5143 (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: BN3PR01MB2148 Archived-At: Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 11 Aug 2016 00:09:37 -0000 T24gOC8xMC8xNiA3OjMwIFBNLCBKb2huIEJyYWRsZXkgd3JvdGU6DQoNCj4gQ2FuIGFueW9uZSBj b21lIHVwIHdpdGggc29tZSByZWFsIHByaXZhY3kgaW5jcmVhc2UgdGhhdCB3ZSBjYW4gYWNoaWV2 ZQ0KPiB0aGF0IHdvdWxkIG5vdCBlYXNpbHkgYmUgY2lyY3VtdmVudGVkIGJ5IGFueW9uZSB3YW50 aW5nIHRvIGNvcnJlbGF0ZS4NCg0KSSB0aGluayBvbmUgcmVzcG9uc2UgaXMgdGhhdCB0aGVyZSBh cmUgcGVvcGxlIHdobyBidWlsZCB0b29scyBmb3INCmJyb3dzZXJzIHRoYXQgaW1wb3NlIHN0cm9u Z2VyIGNvbnN0cmFpbnRzIHRoYW4gdGhlIG9uZXMgdGhlIGJyb3dzZXINCnZlbmRvcnMgYXJlIHdp bGxpbmcgdG8gaW1wb3NlIHRoZW1zZWx2ZXMuDQoNCllvdSdyZSBwcm9iYWJseSByaWdodCB0aGF0 IHRoZXJlJ3MgbGl0dGxlIHBvaW50IGluIGZvcmNpbmcgZGlzY2lwbGluZSBvbg0KdGhlIHNlcnZl ciBzaWRlLCBidXQgaXQgc2VlbXMgbGlrZSB0aGUgY2xpZW50IG91Z2h0IHRvIGhhdmUgdGhlIGZy ZWVkb20NCnRvIGJlIGNvbmZpZ3VyZWQgdG8gZG8gYSBiZXR0ZXIgam9iLg0KDQpTbywgeWVzLCBJ IGNhbiBjb21lIHVwIHdpdGggYW4gaW5jcmVhc2U6IGdpdmUgbWUgYSBicm93c2VyIEkgY2FuIHRl bGwNCm5vdCB0byBtaW50IGVUTEQrMSBrZXlzIGlmIEkgd2FudCB0bywgc28gdGhhdCBpZiBJIGFs c28gd2FudCB0byB0ZWxsIGl0DQpub3QgdG8gYWNjZXB0IGVUTEQrMSBjb29raWVzLCB0aGF0IGhh c24ndCBiZWVuIHN1YnZlcnRlZC4NCg0KLS0gU2NvdHQNCg== From nobody Wed Aug 10 17:14:54 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 9DE9912D0E7 for ; Wed, 10 Aug 2016 17:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 nTWXth_btdoV for ; Wed, 10 Aug 2016 17:14:51 -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 1AF1212D0B3 for ; Wed, 10 Aug 2016 17:14:50 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id v123so18966178qkh.2 for ; Wed, 10 Aug 2016 17:14:50 -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 :content-transfer-encoding:message-id:references:to; bh=DoMgO7r5hupYpOQq2QQbYVLoHelDQe9/Ni6RQyXyAk0=; b=k+j+jvrqxc8Qd11q5hzwRyQC3/nJ/xrJr5FQDujkcyLEL+VthHCczD2B3V0DC2EQzD kkFsMgnZ+7ch3/BNf1OMzS8fhbiKdGGYOLSf4VgmB3CLABCGKke63USIkULf1PyOn7cH iteYEBx1JJ9hITQuCcptKE6tz6fBVWEs3knqb4IKbfdsUlS5vEr/MOVsdwajAjNiBYZy Rvv4mWBlXo9MBGC9wLOsvtzIY6vqzK0R/nWsD/jyVYlHwyoQHqfqAx+otAueZqiJTiw9 +jcjbU5F74URsGEdGb3oDEgowBp6CsIrJJWo+FYqOXmJ7TDW+6nPvP4ImaceasbI6qmK AwsQ== 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 :content-transfer-encoding:message-id:references:to; bh=DoMgO7r5hupYpOQq2QQbYVLoHelDQe9/Ni6RQyXyAk0=; b=h1J+ij2GhLXl2vmoKRD9Hdjdw4PQuuLIHRx+iiFwANL/KF+pfYzCHImiOyxi6yZccl zV3DxizHY5HypmQnXoyNOJr3LMbeR9bCMaYDuDpPKNmotwfSAHp38mPXMWL8aioP6GNW 3s8dc083yZZdhdUu/Q04/NQHwya83LppqCNa7//4oGz9tapGZO4nFYK4YyCujD7rJbVz bqBSLEnsOqUkScmisPYr41F4GbgAbj7zFpmbjedSBSqH12ka7zFfggeMPRJMaSpzKgu2 H2qML0gfno/Z/SSeAqDDWUIyCWv0Ol49CPh/wRv/VrPGvQri5j3KhktBBjLBLbWVFdow 9CWg== X-Gm-Message-State: AEkoousZUkw+T+8EF7LBQs+mg1iY/AH/1Vy+GPPye6vCJKz+8j07tYHY0OnG3Wnk28hfHF9g X-Received: by 10.55.64.140 with SMTP id n134mr7559374qka.63.1470874489925; Wed, 10 Aug 2016 17:14:49 -0700 (PDT) Received: from [192.168.8.100] ([181.202.149.111]) by smtp.gmail.com with ESMTPSA id l63sm24737502qkf.16.2016.08.10.17.14.48 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Aug 2016 17:14:49 -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, 10 Aug 2016 20:14:45 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <908E4C28-B9BE-4CD9-9768-B51CB8260F40@ve7jtb.com> References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <9846A6064BD102419D06814DD0D78DE1129E2F59@CIO-TNC-D2MBX02.osuad.osu.edu> <0AD23E34-8AF8-411E-8913-9B8E8DCFE53A@ve7jtb.com> <9846A6064BD102419D06814DD0D78DE1129E303A@CIO-TNC-D2MBX02.osuad.osu.edu> <84F8594F-59B1-4935-86BA-99F758BFBF0B@osu.edu> <18776400-6439-4F6C-9F41-08F61B3DC58B@ve7jtb.com> To: IETF Tokbind WG X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 11 Aug 2016 00:14:52 -0000 I can see value in tying the two together in the browser so that if the = browser doesn=E2=80=99t accept cookies with that origin then it would = restrict the token binding to same origin as well. That implementation advice for the browsers may be a reasonable idea. Letting the server signal the restriction is a bit fox in charge of the = hen house. Thanks for the input. John B. > On Aug 10, 2016, at 7:50 PM, Cantor, Scott wrote: >=20 > On 8/10/16 7:30 PM, John Bradley wrote: >=20 >> Can anyone come up with some real privacy increase that we can = achieve >> that would not easily be circumvented by anyone wanting to correlate. >=20 > I think one response is that there are people who build tools for > browsers that impose stronger constraints than the ones the browser > vendors are willing to impose themselves. >=20 > You're probably right that there's little point in forcing discipline = on > the server side, but it seems like the client ought to have the = freedom > to be configured to do a better job. >=20 > So, yes, I can come up with an increase: give me a browser I can tell > not to mint eTLD+1 keys if I want to, so that if I also want to tell = it > not to accept eTLD+1 cookies, that hasn't been subverted. >=20 > -- Scott From nobody Wed Aug 10 20:54: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 B717A12D1ED for ; Wed, 10 Aug 2016 20:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 MQfAVhoCIfnv for ; Wed, 10 Aug 2016 20:54:41 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id CE44012D115 for ; Wed, 10 Aug 2016 20:54:40 -0700 (PDT) X-IronPort-AV: E=Sophos; i="5.28,503,1464616800"; d="scan'208,217"; a="98697220" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 11 Aug 2016 13:54:37 +1000 X-IronPort-AV: E=McAfee;i="5700,7163,8253"; a="178880788" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcavi.tcif.telstra.com.au with ESMTP; 11 Aug 2016 13:54:37 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([fe80::4455:9840:ced2:23fa%12]) with mapi; Thu, 11 Aug 2016 13:54:37 +1000 From: "Manger, James" To: IETF Tokbind WG , "balfanz@google.com" Date: Thu, 11 Aug 2016 13:54:34 +1000 Thread-Topic: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) Thread-Index: AQHR8Ut8epZDh2EP4E+neKQPnf2Vr6A/GCOAgABGfQCAAAbiAIAAf3yAgAHuYQCAAKUE0IAAl15g Message-ID: <255B9BB34FB7D647A506DC292726F6E13BFE5D6DB6@WSMSG3153V.srv.dir.telstra.com> References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E13BFE5D6DB6WSMSG3153Vsrv_" MIME-Version: 1.0 Archived-At: Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 11 Aug 2016 03:54:44 -0000 --_000_255B9BB34FB7D647A506DC292726F6E13BFE5D6DB6WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 W0RpcmsgQmFsZmFueiB3cm90ZV0gSW4gY29uY2x1c2lvbiwgbW92aW5nIHRvIGFuIG9yaWdpbiBz Y29wZSBmb3IgdG9rZW4tYmluZGluZyBrZXlzIHdvdWxkIGxpa2VseSBtZWFuIGZvciBhIGNvbXBh bnkgbGlrZSBHb29nbGUsIHdoaWNoIGhhcyBiaWcgY29tcGxpY2F0ZWQgb2xkIHN5c3RlbXMgdGhh dCBhcmUgaGFyZCB0byBjaGFuZ2UsIHRoYXQgd2UgY291bGRuJ3QgaW4gcHJhY3RpY2UgZGVwbG95 IGl0Lg0KDQpUaGlzIGlzIHRoZSBzb3J0IG9mIHJlYXNvbiB0byBhY2NlcHQgZVRMRCsxIHNjb3Bp bmcuIERldGFpbHMgYWJvdXQgaG93IEdvb2dsZSB1c2UgQ2hhbm5lbCBJRHMgKHRoZSBwcmVjdXJz b3IgdG8gdGhpcyB3b3JrKSB3b3VsZCBiZSBldmVuIG1vcmUgY29tcGVsbGluZy4gRG8gbWFpbC5n b29nbGUuY29tIGFuZCBhY2NvdW50cy5nb29nbGUuY29tIHVzZSBhIHNoYXJlZCBDaGFubmVsIElE IHRvIHByb3RlY3QgbG9naW4gY29va2llcyB0b2RheT8gSSBhc3N1bWUgQ2hyb21lIHVzZXMgZVRM RCsxIHNjb3BlIGZvciBDaGFubmVsIElEcyBhcyByZWNvbW1lbmRlZCBieSBkcmFmdC1iYWxmYW56 LXRscy1jaGFubmVsaWQtMDE8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJhbGZh bnotdGxzLWNoYW5uZWxpZC0wMSNzZWN0aW9uLTg+PyBGcm9tIHRoZSBjb29raWUgZGF0YSBpbiBt eSBDaHJvbWUgYnJvd3NlciBJIHNlZSB0aGF0IGdvb2dsZS5jb20gaGFzIGEgQ2hhbm5lbCBJRCwg d2hpbGUgbWFpbC5nb29nbGUuY29tIGRvZXNu4oCZdCBtZW50aW9uIG9uZSAoYnV0IGl0IHByb2Jh Ymx5IG9ubHkgZ2V0cyBtZW50aW9uZWQgYXQgdGhlIHRvcC1sZXZlbCkuDQoNCkN1cmlvdXNseSwg ZG96ZW5zIG9mICouZ29vZ2xlYXBpcy5jb20gc2l0ZXMgdXNlIHNlcGFyYXRlIENoYW5uZWwgSURz IChldmVuIHdoZW4gdGhleSBhcmUgY2xvc2VseSByZWxhdGVkLCBlZyBtdHMwLiBhbmQgbXRzMS4p IGFzIGdvb2dsZWFwaXMuY29tIGlzIGxpc3RlZCBhcyBhIHB1YmxpYyBzdWZmaXguDQoNCg0KW0Fu ZHJlaSBQb3BvdiB3cm90ZV0gR2VuZXJhbGx5LCBJIHRoaW5rIHRoYXQgc2NvcGluZyBUQiBrZXlz IG5hcnJvd2VyIHRoYW4gdGhlIHRva2VucyB0aGV5IHByb3RlY3Qgd291bGQgY2F1c2UgcHJvYmxl bXMuDQoNClRydWUuIEJ1dCBhIG1ham9yIGNsYXNzIG9mIHRva2VucyB0byBwcm90ZWN0IGFyZSBm ZWRlcmF0ZWQgaWRlbnRpdHkgdG9rZW5zIHdob3NlIHNjb3BlIGlzIGEgcGFpciBvZiB1bnJlbGF0 ZWQgZG9tYWlucyAoSWRQICYgUlApIHNvIGV2ZW4gdGhlIGVUTEQrMSBydWxlIOKAnHdvdWxkIGNh dXNlIHByb2JsZW1z4oCdLiBUaGF0IHByb2JsZW0gaXMgc29sdmVkIGJ5IGFkZGluZyB0aGUgY29t cGxleGl0eSBvZiB0aGUgcmVmZXJyZWQtdG9rZW4gbWVjaGFuaXNtLg0KDQoNClBlcmhhcHMgdGhl IHNjb3BlIGlzc3VlIGNvdWxkIGJlIGV4cGxhaW5lZCBieSBzYXlpbmc6IOKAnEZyb20gYSBwcml2 YWN5IHBlcnNwZWN0aXZlLCB0b2tlbiBiaW5kaW5nIGlzIHZhZ3VlbHkgZXF1aXZhbGVudCB0byBh IHNlcnZlciBzZXR0aW5nIGEgY29va2llIGFzIGZvbGxvd3M6DQoNCiAgU2V0LUNvb2tpZTogaWQ9 PGNsaWVudC1jaG9zZW4tcmFuZG9tLXZhbHVlPjsgRG9tYWluPTxvbmUtbGFiZWw+LjxlVExEPjsg RXhwaXJlcz1GcmksIDMxIERlYyA5OTk5IDIzOjU5OjU5IEdNVDsgU2VjdXJlOyBIdHRwT25seQ0K DQpTdWNoIGEgY29va2llIGRvZXNu4oCZdCBmZWVsIGxpa2UgYmVzdCBwcmFjdGljZSwgYnV0IGl0 IGlzIHNpbGVudGx5IGFsbG93ZWQgYnkgYnJvd3NlcnMgc28gdXNpbmcgZVRMRCsxIGFzIHRoZSBo YXJkd2lyZWQgc2NvcGUgZm9yIFRCIGtleXMgaXMgYSByZWFzb25hYmxlIHByYWdtYXRpYyBjaG9p Y2UuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg== --_000_255B9BB34FB7D647A506DC292726F6E13BFE5D6DB6WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQg NzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLUFV IGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCc+W0RpcmsgQmFsZmFueiB3 cm90ZV0gPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVM+SW4gY29uY2x1c2lvbiwgbW92aW5nIHRvIGFu IG9yaWdpbiBzY29wZSBmb3IgdG9rZW4tYmluZGluZyBrZXlzIHdvdWxkIGxpa2VseSBtZWFuIGZv ciBhIGNvbXBhbnkgbGlrZSBHb29nbGUsIHdoaWNoIGhhcyBiaWcgY29tcGxpY2F0ZWQgb2xkIHN5 c3RlbXMgdGhhdCBhcmUgaGFyZCB0byBjaGFuZ2UsIHRoYXQgd2UgY291bGRuJ3QgaW4gcHJhY3Rp Y2UgZGVwbG95IGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCc+VGhpcyBp cyB0aGUgc29ydCBvZiByZWFzb24gdG8gYWNjZXB0IGVUTEQrMSBzY29waW5nLiBEZXRhaWxzIGFi b3V0IGhvdyBHb29nbGUgdXNlIENoYW5uZWwgSURzICh0aGUgcHJlY3Vyc29yIHRvIHRoaXMgd29y aykgd291bGQgYmUgZXZlbiBtb3JlIGNvbXBlbGxpbmcuIERvIG1haWwuZ29vZ2xlLmNvbSBhbmQg YWNjb3VudHMuZ29vZ2xlLmNvbSB1c2UgYSBzaGFyZWQgQ2hhbm5lbCBJRCB0byBwcm90ZWN0IGxv Z2luIGNvb2tpZXMgdG9kYXk/IEkgYXNzdW1lIENocm9tZSB1c2VzIGVUTEQrMSBzY29wZSBmb3Ig Q2hhbm5lbCBJRHMgYXMgcmVjb21tZW5kZWQgYnkgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWJhbGZhbnotdGxzLWNoYW5uZWxpZC0wMSNzZWN0aW9uLTgiPmRyYWZ0 LWJhbGZhbnotdGxzLWNoYW5uZWxpZC0wMTwvYT4/IEZyb20gdGhlIGNvb2tpZSBkYXRhIGluIG15 IENocm9tZSBicm93c2VyIEkgc2VlIHRoYXQgZ29vZ2xlLmNvbSBoYXMgYSBDaGFubmVsIElELCB3 aGlsZSBtYWlsLmdvb2dsZS5jb20gZG9lc27igJl0IG1lbnRpb24gb25lIChidXQgaXQgcHJvYmFi bHkgb25seSBnZXRzIG1lbnRpb25lZCBhdCB0aGUgdG9wLWxldmVsKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QnPkN1cmlvdXNseSwgZG96ZW5zIG9mICouZ29vZ2xlYXBpcy5j b20gc2l0ZXMgdXNlIHNlcGFyYXRlIENoYW5uZWwgSURzIChldmVuIHdoZW4gdGhleSBhcmUgY2xv c2VseSByZWxhdGVkLCBlZyBtdHMwLiBhbmQgbXRzMS4pIGFzIGdvb2dsZWFwaXMuY29tIGlzIGxp c3RlZCBhcyBhIHB1YmxpYyBzdWZmaXguPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QnPls8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZic+QW5kcmVpIFBvcG92IHdy b3RlXSA8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZic+R2VuZXJhbGx5LCBJIHRoaW5rIHRoYXQgc2Nv cGluZyBUQiBrZXlzIG5hcnJvd2VyIHRoYW4gdGhlIHRva2VucyB0aGV5IHByb3RlY3Qgd291bGQg Y2F1c2UgcHJvYmxlbXMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEJz5UcnVl LiBCdXQgYSBtYWpvciBjbGFzcyBvZiB0b2tlbnMgdG8gcHJvdGVjdCBhcmUgZmVkZXJhdGVkIGlk ZW50aXR5IHRva2VucyB3aG9zZSBzY29wZSBpcyBhIHBhaXIgb2YgdW5yZWxhdGVkIGRvbWFpbnMg KElkUCAmYW1wOyBSUCkgc28gZXZlbiB0aGUgZVRMRCsxIHJ1bGUg4oCcd291bGQgY2F1c2UgcHJv YmxlbXPigJ0uIFRoYXQgcHJvYmxlbSBpcyBzb2x2ZWQgYnkgYWRkaW5nIHRoZSBjb21wbGV4aXR5 IG9mIHRoZSByZWZlcnJlZC10b2tlbiBtZWNoYW5pc20uPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCc+UGVyaGFwcyB0aGUgc2NvcGUgaXNz dWUgY291bGQgYmUgZXhwbGFpbmVkIGJ5IHNheWluZzog4oCcRnJvbSBhIHByaXZhY3kgcGVyc3Bl Y3RpdmUsIHRva2VuIGJpbmRpbmcgaXMgdmFndWVseSBlcXVpdmFsZW50IHRvIGEgc2VydmVyIHNl dHRpbmcgYSBjb29raWUgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QnPsKgIFNldC1Db29raWU6IGlkPSZsdDtjbGllbnQtY2hvc2VuLXJhbmRvbS12YWx1ZSZn dDs7IERvbWFpbj0mbHQ7b25lLWxhYmVsJmd0Oy4mbHQ7ZVRMRCZndDs7IEV4cGlyZXM9RnJpLCAz MSBEZWMgOTk5OSAyMzo1OTo1OSBHTVQ7IFNlY3VyZTsgSHR0cE9ubHk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QnPlN1Y2ggYSBjb29raWUgZG9lc27igJl0IGZlZWwgbGlrZSBi ZXN0IHByYWN0aWNlLCBidXQgaXQgaXMgc2lsZW50bHkgYWxsb3dlZCBieSBicm93c2VycyBzbyB1 c2luZyBlVExEKzEgYXMgdGhlIGhhcmR3aXJlZCBzY29wZSBmb3IgVEIga2V5cyBpcyBhIHJlYXNv bmFibGUgcHJhZ21hdGljIGNob2ljZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E13BFE5D6DB6WSMSG3153Vsrv_-- From nobody Wed Aug 10 23:30: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 9F5F2126FDC for ; Wed, 10 Aug 2016 23:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.947 X-Spam-Level: X-Spam-Status: No, score=-3.947 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.247, 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 H2TW--fFRtA2 for ; Wed, 10 Aug 2016 23:30:00 -0700 (PDT) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 8380412D151 for ; Wed, 10 Aug 2016 23:29:53 -0700 (PDT) Received: by mail-wm0-x22a.google.com with SMTP id o80so12155178wme.1 for ; Wed, 10 Aug 2016 23:29:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=YO3yRxrYAq84+NC7ABV2CApcekZfDy39+Hk6fqMls3A=; b=ZzLok3JLcTFPOgZc9G6pFV9X0lgeWlzWhAJj49JEZnWteScZDBG0v61zAQkN3+9JwO dVr60NYGMlHIeZ7LxtmR/FVjmOZWON1oEf1KPhU6V76pMPZVtHIfKoXBvK94c8xjC/Yh MWWC/neo+vZeIy0bsC/N/hvNFlwWCGFX1BHb5Pf506ggBpddZNhvFfBhyUmZ9RTlo+0O iU9YP6+ez56AXkJdY/ieulFY41xeqtTW8CZr1xSpD8Sr0dQ7IfTOVNGeUhFdOh5SRIPW JWx2d+k/4I/eep6g0a+6uNEKPhguamPgIeAi5S4mWLxd+f5Su+SKtEig7cIdnnqCsW6a gSdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=YO3yRxrYAq84+NC7ABV2CApcekZfDy39+Hk6fqMls3A=; b=N2bKhhW84831OCXYZsEdYxaM9cfanWZz1+yTs2wtZocd3y4HcATaziaRw2ld2oRbK8 mqN2bviKfsD0BRwgC1LXn+Pe/Ztg/IUQTBGtpueE6QMd3dUc17XGit3kzQb/tX0aWiyZ /sN0pqJAzeyxCbJWDf2bCqpX0xzBB0aWOPcx6jCXBVthJxSuXHTA7cUogUEnviJA5YA5 kzcK116zJnKr483jlShmanDusZZpbSSDQl8aV/qBWF+uW7131hHL6GH1J5nXN7Hde6sR fUqMiFOxk1AYVP7Msi6lNXPr+Ow81E9f8fyD4JcmypEIYJPhRev2Bt3WVaodgPxPOSjZ VnYw== X-Gm-Message-State: AEkoouvhDWAnJscrY//IYsnAp3mKhXdYv7LkBEGyOsFNL8QpTTEgZpXCRCVO2NTA2/SLpF/RkVCLBClNAkzabLfZ X-Received: by 10.28.27.143 with SMTP id b137mr7811102wmb.12.1470896991907; Wed, 10 Aug 2016 23:29:51 -0700 (PDT) MIME-Version: 1.0 References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <255B9BB34FB7D647A506DC292726F6E13BFE5D6DB6@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BFE5D6DB6@WSMSG3153V.srv.dir.telstra.com> From: Dirk Balfanz Date: Thu, 11 Aug 2016 06:29:41 +0000 Message-ID: To: "Manger, James" , IETF Tokbind WG Content-Type: multipart/alternative; boundary=001a114b31ceb48eac0539c5e4ad Archived-At: Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 11 Aug 2016 06:30:02 -0000 --001a114b31ceb48eac0539c5e4ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 10, 2016 at 8:54 PM Manger, James < James.H.Manger@team.telstra.com> wrote: > [Dirk Balfanz wrote] In conclusion, moving to an origin scope for > token-binding keys would likely mean for a company like Google, which has > big complicated old systems that are hard to change, that we couldn't in > practice deploy it. > > > > This is the sort of reason to accept eTLD+1 scoping. Details about how > Google use Channel IDs (the precursor to this work) would be even more > compelling. Do mail.google.com and accounts.google.com use a shared > Channel ID to protect login cookies today? I assume Chrome uses eTLD+1 > scope for Channel IDs as recommended by draft-balfanz-tls-channelid-01 > ? > From the cookie data in my Chrome browser I see that google.com has a > Channel ID, while mail.google.com doesn=E2=80=99t mention one (but it pro= bably > only gets mentioned at the top-level). > Yes, you are correct. Chrome uses the same ChannelID key for *.google.com > Curiously, dozens of *.googleapis.com sites use separate Channel IDs > (even when they are closely related, eg mts0. and mts1.) as googleapis.co= m > is listed as a public suffix. > Again correct. googleapis.com is in the PSL, so every sub-domain gets its own ChannelID key. Fortunately, we don't set authentication cookies on those domains, or else the channel-binding team at Google would be in trouble. ;-) Dirk. [Andrei Popov wrote] Generally, I think that scoping TB keys narrower than > the tokens they protect would cause problems. > > > > True. But a major class of tokens to protect are federated identity token= s > whose scope is a pair of unrelated domains (IdP & RP) so even the eTLD+1 > rule =E2=80=9Cwould cause problems=E2=80=9D. That problem is solved by ad= ding the > complexity of the referred-token mechanism. > > > > > > Perhaps the scope issue could be explained by saying: =E2=80=9CFrom a pri= vacy > perspective, token binding is vaguely equivalent to a server setting a > cookie as follows: > > > > Set-Cookie: id=3D; Domain=3D.; > Expires=3DFri, 31 Dec 9999 23:59:59 GMT; Secure; HttpOnly > > > > Such a cookie doesn=E2=80=99t feel like best practice, but it is silently= allowed > by browsers so using eTLD+1 as the hardwired scope for TB keys is a > reasonable pragmatic choice. > > > > -- > > James Manger > --001a114b31ceb48eac0539c5e4ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed= , Aug 10, 2016 at 8:54 PM Manger, James <James.H.Manger@team.telstra.com> wrote:

[Dirk Balfanz wrote] In conclusion, moving to an origin scope for token-binding keys = would likely mean for a company like Google, which has big complicated old = systems that are hard to change, that we couldn't in practice deploy it= .

=C2=A0

This is the sort of reason to accept eTLD+1 scoping. Details a= bout how Google use Channel IDs (the precursor to this work) would be even = more compelling. Do ma= il.google.com and accounts.google.com use a shared Channel ID to protect login cookie= s today? I assume Chrome uses eTLD+1 scope for Channel IDs as recommended b= y draft-balfanz-tls-channelid-01? From the cook= ie data in my Chrome browser I see that google.com has a Channel ID, while mail.google.com doesn=E2=80=99t mention o= ne (but it probably only gets mentioned at the top-level).

=

Yes, you are correct. Chrome uses th= e same ChannelID key for *.google.com
=C2=A0

Curiously, dozens of = *.googleapis.com si= tes use separate Channel IDs (even when they are closely related, eg mts0. = and mts1.) as googleapi= s.com is listed as a public suffix.

=

Again correct. google= apis.com is in the PSL, so every sub-domain gets its own ChannelID key.= Fortunately, we don't set authentication cookies on those domains, or = else the channel-binding team at Google would be in trouble. ;-)
=
Dirk.

=C2=A0

[Andrei Popov wrote] Generally, I think that scoping TB keys narrower than the tokens t= hey protect would cause problems.

=C2=A0

True. But a major class of tok= ens to protect are federated identity tokens whose scope is a pair of unrel= ated domains (IdP & RP) so even the eTLD+1 rule =E2=80=9Cwould cause pr= oblems=E2=80=9D. That problem is solved by adding the complexity of the ref= erred-token mechanism.

=C2=A0

=C2=A0

Perhaps the scope issue could = be explained by saying: =E2=80=9CFrom a privacy perspective, token binding = is vaguely equivalent to a server setting a cookie as follows:

=C2= =A0

= =C2=A0 Set-Cookie: id=3D<client-chosen-random-value>; Domain=3D<on= e-label>.<eTLD>; Expires=3DFri, 31 Dec 9999 23:59:59 GMT; Secure; = HttpOnly

=C2=A0

Such a cookie doesn=E2=80=99t feel like best practice, = but it is silently allowed by browsers so using eTLD+1 as the hardwired sco= pe for TB keys is a reasonable pragmatic choice.

=C2=A0

--

James Mang= er

--001a114b31ceb48eac0539c5e4ad-- From nobody Wed Aug 10 23:39:57 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 3BF2012B024 for ; Wed, 10 Aug 2016 23:39:56 -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 1zsMRfk6_LDG for ; Wed, 10 Aug 2016 23:39:54 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 A0D42126FDC for ; Wed, 10 Aug 2016 23:39:54 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id n59so104733541uan.2 for ; Wed, 10 Aug 2016 23:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4vihwgWg2sKiXdwHvW+AMQbeg4tHeLwALNm9xgEKFbg=; b=AAwRflQp2UgWGA7+zYsS3r0AlR/Z4b89QqBF8wnEdhKfAuEpp2xQPfKo8SPDJGCqWr 1f6NkPUG/KxbIa/N6br4WKp5O5eAICxJYyHIkXNGkzyIk/ePdbvCmtmtX/+BQ//3vwcP WBgGK9j2ZOFfwLNYs6YAh8/ykWcPf0/pBk59NQCUT1YlCrm/8evMaZYpnqf2ETZIfOUF 7A8jXsrdXkrw2ukMs4DzeZyiCHCYtjgm5+3qCUkGMOEJosxhlMK0hTmZi3L5ryBbtopY qYvry3JJO7K6e0hPCFWzlry9BQD2G+0gXD2GxOz5c+DH9PcOEn/TFKRBRbWPovQcNH5o uREg== 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:content-transfer-encoding; bh=4vihwgWg2sKiXdwHvW+AMQbeg4tHeLwALNm9xgEKFbg=; b=EFd35sawWFaHUz+z1xvDWIRBtHbFz2WkBFuUc68A87jVKyTCpQDIAca4XlLfdJUrun tOcBJAokyJmway2Z67xr/TdiZroLeWGCcTE5Txs2tL27j9YzyR8DTYOTi2aCWRP52Q5X 85nC/NgarxsV3xAZgHlJAOB/YSP4TIo1jdggz5NyusQ3+iq3hXsOfhW+yo1iW3RO9Cul tmWs9AHdiGbxAwbgBKEEzvuF2EtpqkBBFKN1k4tBjAHYK2ynuc3mTqKFZe6VSaVNP1HH KKSlINHOQgyxeUG37/NRp32GA7UbJkMLK2MPUHWv4g4IyeJ68/XTOFa/dHJDK0woLzYY s2Zg== X-Gm-Message-State: AEkoouvcq92eUHAOIFijBVVt1ShU/e/4gEuVw1ZoexYCpq89UdjdkOtTGYAjnmxjM/r3zHZwjWiio0Ehot017A== X-Received: by 10.31.0.133 with SMTP id 127mr3271112vka.57.1470897593742; Wed, 10 Aug 2016 23:39:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.209 with HTTP; Wed, 10 Aug 2016 23:39:52 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BFE5D6DB6@WSMSG3153V.srv.dir.telstra.com> References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <255B9BB34FB7D647A506DC292726F6E13BFE5D6DB6@WSMSG3153V.srv.dir.telstra.com> From: Watson Ladd Date: Wed, 10 Aug 2016 23:39:52 -0700 Message-ID: To: "Manger, James" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF Tokbind WG , "balfanz@google.com" Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 11 Aug 2016 06:39:56 -0000 On Wed, Aug 10, 2016 at 8:54 PM, Manger, James wrote: > [Dirk Balfanz wrote] In conclusion, moving to an origin scope for > token-binding keys would likely mean for a company like Google, which has > big complicated old systems that are hard to change, that we couldn't in > practice deploy it. > > > > This is the sort of reason to accept eTLD+1 scoping. Details about how > Google use Channel IDs (the precursor to this work) would be even more > compelling. Do mail.google.com and accounts.google.com use a shared Chann= el > ID to protect login cookies today? I assume Chrome uses eTLD+1 scope for > Channel IDs as recommended by draft-balfanz-tls-channelid-01? From the > cookie data in my Chrome browser I see that google.com has a Channel ID, > while mail.google.com doesn=E2=80=99t mention one (but it probably only g= ets > mentioned at the top-level). > > > > Curiously, dozens of *.googleapis.com sites use separate Channel IDs (eve= n > when they are closely related, eg mts0. and mts1.) as googleapis.com is > listed as a public suffix. > > > > > > [Andrei Popov wrote] Generally, I think that scoping TB keys narrower tha= n > the tokens they protect would cause problems. > > > > True. But a major class of tokens to protect are federated identity token= s > whose scope is a pair of unrelated domains (IdP & RP) so even the eTLD+1 > rule =E2=80=9Cwould cause problems=E2=80=9D. That problem is solved by ad= ding the complexity > of the referred-token mechanism. Why doesn't Oauth solve this/why do we need to solve it? We should be allowed to be better cookies, and not asked to do more. Simplify, simplify, simplify. From nobody Thu Aug 11 00:13:24 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 6480512D0B6 for ; Thu, 11 Aug 2016 00:13:23 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 ZgBbM-LfzYyk for ; Thu, 11 Aug 2016 00:13:21 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECF812B031 for ; Thu, 11 Aug 2016 00:13:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,503,1464616800"; d="scan'208";a="99490839" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipoani.tcif.telstra.com.au with ESMTP; 11 Aug 2016 17:13:19 +1000 X-IronPort-AV: E=McAfee;i="5700,7163,8253"; a="166621594" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcbni.tcif.telstra.com.au with ESMTP; 11 Aug 2016 17:13:19 +1000 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3707.srv.dir.telstra.com ([fe80::ccc:aa8f:d2a6:740%28]) with mapi; Thu, 11 Aug 2016 17:13:19 +1000 From: "Manger, James" To: Watson Ladd Date: Thu, 11 Aug 2016 17:13:17 +1000 Thread-Topic: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) Thread-Index: AdHzmy024fmypqDiSM+d269C9uIr9QAA0Mgw Message-ID: <255B9BB34FB7D647A506DC292726F6E13BFE7B173D@WSMSG3153V.srv.dir.telstra.com> References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <255B9BB34FB7D647A506DC292726F6E13BFE5D6DB6@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 11 Aug 2016 07:13:23 -0000 DQo+PiBbQW5kcmVpIFBvcG92IHdyb3RlXSBHZW5lcmFsbHksIEkgdGhpbmsgdGhhdCBzY29waW5n IFRCIGtleXMgbmFycm93ZXIgDQo+PiB0aGFuIHRoZSB0b2tlbnMgdGhleSBwcm90ZWN0IHdvdWxk IGNhdXNlIHByb2JsZW1zLg0KPj4NCj4+DQo+Pg0KPj4gVHJ1ZS4gQnV0IGEgbWFqb3IgY2xhc3Mg b2YgdG9rZW5zIHRvIHByb3RlY3QgYXJlIGZlZGVyYXRlZCBpZGVudGl0eSANCj4+IHRva2VucyB3 aG9zZSBzY29wZSBpcyBhIHBhaXIgb2YgdW5yZWxhdGVkIGRvbWFpbnMgKElkUCAmIFJQKSBzbyBl dmVuIA0KPj4gdGhlIGVUTEQrMSBydWxlIOKAnHdvdWxkIGNhdXNlIHByb2JsZW1z4oCdLiBUaGF0 IHByb2JsZW0gaXMgc29sdmVkIGJ5IA0KPj4gYWRkaW5nIHRoZSBjb21wbGV4aXR5IG9mIHRoZSBy ZWZlcnJlZC10b2tlbiBtZWNoYW5pc20uDQoNCj4gV2h5IGRvZXNuJ3QgT2F1dGggc29sdmUgdGhp cy93aHkgZG8gd2UgbmVlZCB0byBzb2x2ZSBpdD8gV2Ugc2hvdWxkIGJlIGFsbG93ZWQgdG8gYmUg YmV0dGVyIGNvb2tpZXMsIGFuZCBub3QgYXNrZWQgdG8gZG8gbW9yZS4NCj4gU2ltcGxpZnksIHNp bXBsaWZ5LCBzaW1wbGlmeS4NCg0KQmVjYXVzZSBvbmUgaXRlbSBpbiB0aGUgbWFpbiBkZXNpZ24g b2JqZWN0aXZlcyBmb3IgdGhlIFRva2VuIEJpbmRpbmcgZ3JvdXAgY2hhcnRlciBbaHR0cHM6Ly90 b29scy5pZXRmLm9yZy93Zy90b2tiaW5kL2NoYXJ0ZXJzXSBpczoNCiIzLiBTdXBwb3J0IGJvdGgg Zmlyc3QtcGFydHkgYW5kIGZlZGVyYXRpb24gc2NlbmFyaW9zIg0KDQpCZWNhdXNlIHRoZSBPQXV0 aCBncm91cCBjYW5ub3QgYnVpbGQgZmVkZXJhdGlvbiBzdXBwb3J0IGlmIHRoZSBvbmx5IHByaW1p dGl2ZSBhdmFpbGFibGUgaXMgZVRMRCsxIHNjb3BlZCBjcnlwdG8gY29va2llcy4NCg0KLS0NCkph bWVzIE1hbmdlcg0K From nobody Thu Aug 11 06:20:13 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 A8A0412D0A9 for ; Thu, 11 Aug 2016 06:20:11 -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 j3_iP9qnaFxl for ; Thu, 11 Aug 2016 06:20:10 -0700 (PDT) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 0C32112B028 for ; Thu, 11 Aug 2016 06:20:10 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id n59so5598160uan.2 for ; Thu, 11 Aug 2016 06:20:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/Z1NI0dyocihgygAZNN+lyq0yDz0/x0FDqs5H3qJPL8=; b=kdw5pXBzj/2baT3i0n/NiK9v5Ku1Yt/2woW4RRx3kNbGUQY8CH3+jQ0YvFkaxl6hlE CRVt1qEOr4tUEmg7LnpPOX82+RGLLYT/aO1/vopbgkCFINnTA/xdUN8/l3U6oWjS4+0o 3JlYb/+vp/CGRUayiZ677IWkYKUZum1bnv6aOVDncoQc66NmwxMc8sWrLFts1W67QPH0 /uzn5iznG1tVUnNc9lH4AjVUUjXwXvF2hRKHvjtFGDiUOAuXJor/RydWC1xfpgfIaJdd cvLISH9OUAG6kPkRpnu8kaG86Mnl3sQ6c1vev3K0/zr70hBglkd1Lj5egT2ON9Fgctwy AeXQ== 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:content-transfer-encoding; bh=/Z1NI0dyocihgygAZNN+lyq0yDz0/x0FDqs5H3qJPL8=; b=nDV/p06inTVqG+9sXq5sxrqL4cZPA/7mO3IpENPxyIMY/8lXmf6iSiWKZF22Emln7S ePN/aTvw8CtdI4PSrTu563ZNPhi4hUPPBqyNGwMoM/KGzVtGWwnQRf0tjQSlxoHtKIJy pq19lmKRzqJfmga23RZICCIvDHZO0uKcT93MoNU3wNTTVX2Ya7qe7Do/hHJtvZtZ02L2 XIbwDDYIUqxwPf/KSJJ/QjbJtiGtihivMmCDDY3NdISdsyz6D5h68JTVCsEmQ3oUatzN cSpK2Qcjlx9gs5FCsMYFQ4ARkDyXSouzH723Hsyj7Tkj8ZUqergFWqmV0g3/83FKlCmJ lSMQ== X-Gm-Message-State: AEkoouvy2bO3w8Lh7pVG8oeOqhMFED8OZL1kt8U2Ac5PrUI2/CnEMct/XveGKaE2Ypd+H51FRoAura+XiI/Qzw== X-Received: by 10.31.108.156 with SMTP id j28mr4776889vki.68.1470921609118; Thu, 11 Aug 2016 06:20:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.209 with HTTP; Thu, 11 Aug 2016 06:20:08 -0700 (PDT) In-Reply-To: <255B9BB34FB7D647A506DC292726F6E13BFE7B173D@WSMSG3153V.srv.dir.telstra.com> References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <255B9BB34FB7D647A506DC292726F6E13BFE5D6DB6@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E13BFE7B173D@WSMSG3153V.srv.dir.telstra.com> From: Watson Ladd Date: Thu, 11 Aug 2016 06:20:08 -0700 Message-ID: To: "Manger, James" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 11 Aug 2016 13:20:11 -0000 On Thu, Aug 11, 2016 at 12:13 AM, Manger, James wrote: > >>> [Andrei Popov wrote] Generally, I think that scoping TB keys narrower >>> than the tokens they protect would cause problems. >>> >>> >>> >>> True. But a major class of tokens to protect are federated identity >>> tokens whose scope is a pair of unrelated domains (IdP & RP) so even >>> the eTLD+1 rule =E2=80=9Cwould cause problems=E2=80=9D. That problem is= solved by >>> adding the complexity of the referred-token mechanism. > >> Why doesn't Oauth solve this/why do we need to solve it? We should be al= lowed to be better cookies, and not asked to do more. >> Simplify, simplify, simplify. > > Because one item in the main design objectives for the Token Binding grou= p charter [https://tools.ietf.org/wg/tokbind/charters] is: > "3. Support both first-party and federation scenarios" > > Because the OAuth group cannot build federation support if the only primi= tive available is eTLD+1 scoped crypto cookies. Bear in mind OAuth works today, via a bunch of redirects. No reason that can't continue to work. To use with tokenbinding, switch the local session cookie to a token bound token. What's the problem? > > -- > James Manger --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu Aug 11 06:47:43 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 28CF812D59A for ; Thu, 11 Aug 2016 06:47:43 -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 EOaxXGq5d3fI for ; Thu, 11 Aug 2016 06:47:41 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 8CBA612D65F for ; Thu, 11 Aug 2016 06:47:37 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id x25so2145905qtx.2 for ; Thu, 11 Aug 2016 06:47:37 -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=Y8QKrkZBRJ2RLcYicG7e4eaQyg3hzs4LW7/ibGMG1pA=; b=YVOHJULstMbiuCSDehniPILLjOcVkfqbBAkPsLDNM/1z8cFx0zDkhcR2iIn6O10kOP njjeg311idVEr+r9K8XN9lLE5YR9CChju07dJ5z9mQ+K8Jl+CKToeiBA8nxq53tDV6xK awOs5Wozgx41Be6xJ59AQselWSJbetx2woN27pgR+F+KGTa1Fd/EpebN0+tPQi9imTOT zxsKkoEoyi4Kpv5wPhlpc9/8FXAnZYk3dCO7zMTPm/StrkSEAUiHUMw994F4tXUv/368 ETVXaeOKeIhIEMx2s4E1aJG3hnvtDasZfHadqaoQsn6d2pk5RZ1DFAtVP0ZyGECxfRm/ OwyQ== 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=Y8QKrkZBRJ2RLcYicG7e4eaQyg3hzs4LW7/ibGMG1pA=; b=cSuvQCwiNgfSb40pzzTgOeuGrEwC0psKcbiwcVwJJIQnfAHjyHCh6Fujm+mC5h8qlN kA6dGPqtnMHlPUmYJzop6ULd3uC+9WHdK4kpL7HYT8Q8rP/MPp2lFB8xh1sFFbdvRQXD QndvRPNwbLbKEwT7YHEVJKzGilBcvPjHg6ABXzLFbfXJ/lCuwdEBMDrDT5SSwFTFFNEX 17IsqmueaohuZKfFpn8Vo/QStAW8spRAu/nZWI/g/09gWPzrMHU0Y8EwK5TJ5ybbk79c P9cBHTXxbDKYdf+TkMR0j3g7ltJoKSDYyAknwBxIt5taLqDkdNY1pTFhgBLYJ/E7WtMV 8CWg== X-Gm-Message-State: AEkooutKqDS7a5M8wT34smfdURAzy7TXv3jE7YR6Y1lT5OfTUKO2AGydEE9djVnpIz2kvfqL X-Received: by 10.237.46.166 with SMTP id k35mr10499631qtd.93.1470923256543; Thu, 11 Aug 2016 06:47:36 -0700 (PDT) Received: from [192.168.1.49] ([191.115.111.163]) by smtp.gmail.com with ESMTPSA id b195sm304079qkg.9.2016.08.11.06.47.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 11 Aug 2016 06:47:35 -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: Thu, 11 Aug 2016 09:47:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9846A6064BD102419D06814DD0D78DE1129E1394@CIO-TNC-D2MBX02.osuad.osu.edu> <255B9BB34FB7D647A506DC292726F6E13BFE5D6DB6@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E13BFE7B173D@WSMSG3153V.srv.dir.telstra.com> To: Watson Ladd X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF Tokbind WG , "Manger, James" Subject: Re: [Unbearable] Revisit eTLD+1 (was Re: support for different key parameters within the same TLD+1) 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, 11 Aug 2016 13:47:43 -0000 That could conceivably work, however I suspect that that requires a = much larger reworking of web sites than just token binding the cookies. =20= I think some would argue that restricting token binding to same origin = and forcing people to use OAuth to replace eTLD+1 cookies is not really = a simplification for the application developers, though it might be for = the browser developers. It is an adoption question. John B. > On Aug 11, 2016, at 9:20 AM, Watson Ladd = wrote: >=20 > On Thu, Aug 11, 2016 at 12:13 AM, Manger, James > wrote: >>=20 >>>> [Andrei Popov wrote] Generally, I think that scoping TB keys = narrower >>>> than the tokens they protect would cause problems. >>>>=20 >>>>=20 >>>>=20 >>>> True. But a major class of tokens to protect are federated identity >>>> tokens whose scope is a pair of unrelated domains (IdP & RP) so = even >>>> the eTLD+1 rule =E2=80=9Cwould cause problems=E2=80=9D. That = problem is solved by >>>> adding the complexity of the referred-token mechanism. >>=20 >>> Why doesn't Oauth solve this/why do we need to solve it? We should = be allowed to be better cookies, and not asked to do more. >>> Simplify, simplify, simplify. >>=20 >> Because one item in the main design objectives for the Token Binding = group charter [https://tools.ietf.org/wg/tokbind/charters] is: >> "3. Support both first-party and federation scenarios" >>=20 >> Because the OAuth group cannot build federation support if the only = primitive available is eTLD+1 scoped crypto cookies. >=20 > Bear in mind OAuth works today, via a bunch of redirects. No reason > that can't continue to work. To use with tokenbinding, switch the > local session cookie to a token bound token. What's the problem? >=20 >>=20 >> -- >> James Manger >=20 >=20 >=20 > --=20 > "Man is born free, but everywhere he is in chains". > --Rousseau. >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Fri Aug 19 15:31: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 B7AAD12D0A6 for ; Fri, 19 Aug 2016 15:31: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, 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 4hW-Pcfwcq-e for ; Fri, 19 Aug 2016 15:30:57 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on070a.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::70a]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8314C12B029 for ; Fri, 19 Aug 2016 15:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qyFrWDQo4n2zfb6N7SRRrp4kalBs6bh0/POgtRVFLTo=; b=LCuF+IaU7ApRzU08b1Sr3AZHYXL5IyRTe7+b4tRRWRLROwL1HcztMWnETIT7UEB0GgNE+JedpQX0B2+ktypxhzDq/4Y+73GyesFrCjJ1uhLTZEO29rc6vsJVns0uJMqnVgfvkrv1gK9xnuy5/qPWZBwNdiDm2DSmOVnXHcJYsA8= Received: from SN2PR03MB2367.namprd03.prod.outlook.com (10.166.210.146) by SN2PR03MB2368.namprd03.prod.outlook.com (10.166.210.147) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.9; Fri, 19 Aug 2016 22:30:55 +0000 Received: from SN2PR03MB2367.namprd03.prod.outlook.com ([10.166.210.146]) by SN2PR03MB2367.namprd03.prod.outlook.com ([10.166.210.146]) with mapi id 15.01.0557.022; Fri, 19 Aug 2016 22:30:55 +0000 From: Pranav Kukreja To: "unbearable@ietfa.amsl.com" Thread-Topic: RSA padding schemes Thread-Index: AdH6aTyCahuRxvpCSzqArpxwa30Imw== Date: Fri, 19 Aug 2016 22:30:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pranavk@microsoft.com; x-originating-ip: [2001:4898:80e8:7::d5] x-ms-office365-filtering-correlation-id: 75b7ac51-8dcc-4126-0f6d-08d3c8807bff x-microsoft-exchange-diagnostics: 1; SN2PR03MB2368; 6:4GLK702WC5EjWI2YVqDFoJg3qAH5zy4GHGXjvAmOh1Abo2D93F5ASIccYLJ0/ifpCieExac6Z2iLvYsZBLEHYYwj5dJ6Ohgh1QTwmIB1iyE4sVQtPpZrMd9ASfnGGZkAXLGFDOqf8f68+TRHzUzf2olh8EXHoTM7Te5ZunAJ47DOIeXmebA4DjULcSz8w8eclG6AXfnQS52HuLyfAHIn7c3coCr08bko7Kln0MOHD5LXEWGEFJBDBVTigql8W691jbPH/1DydhK0K52Vu6fcQXxbGeN2kZULOA6hnfGxgQ3yK6gQHUagSh8EnbZI+OEe0+tg/J5r6hRfm1xSdtswTA==; 5:ZUobBNB24EiTS098Fvx51GrbU/5i/fSN2Gk4YlCGtG5r0UNhEVRNlIejc/dWcRVam1jE6Hv9czLHjcEaCMvC/ncP05/VHhG2Tl2szU4aa0q/mGKIdWdEs/ktYLqxPBSHrvQMIEx0uy/YSy/bMFJ3Lg==; 24:PwG8uGixMGmYqqmpwvfOnK2bWGOItwDUF2LVT63T/g0aELPUik1ncv3S61K1Maz/usP94YfHFiuYGAjdav+YxCpRTsA+lZb1H4/exJ9tU0k=; 7:7xZwC+hhKpAyDCZU9tgvkyJWxU0And0hnrgAa6870IONb2gEWMnE1CMSrzLdO/z5LBDDkMI1yD2Vn5H+Pu3O044uELnmUTNc9qNin/ytHU5BwsSpxQnxQNJlLivi2aRk/5FXz1FqgEncCw9UADQH6DLMaqyyZ2vn69z/hK/dxTVrwWh3rBgZIFphX3oH1OziTPE6jxIIcdWvWjUDB9bSxHGprti2ssjPyPgTI6hi5kaQTDQnUOKAVYLUPLGnPwmy x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN2PR03MB2368; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:SN2PR03MB2368; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2368; x-forefront-prvs: 0039C6E5C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(92566002)(16236675004)(76576001)(229853001)(74316002)(2906002)(3480700004)(81156014)(1730700003)(7846002)(2351001)(8676002)(5660300001)(3660700001)(81166006)(33656002)(7736002)(7696003)(86612001)(8936002)(106356001)(68736007)(19625215002)(790700001)(6116002)(102836003)(5002640100001)(9686002)(122556002)(450100001)(97736004)(8990500004)(586003)(10090500001)(10400500002)(11100500001)(2501003)(5005710100001)(99286002)(19300405004)(110136002)(105586002)(87936001)(15975445007)(3280700002)(19580395003)(77096005)(107886002)(10290500002)(189998001)(54356999)(50986999)(2900100001)(101416001)(86362001)(7116003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR03MB2368; H:SN2PR03MB2367.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2367A820D0A85626DC2A85B2B0160SN2PR03MB2367namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Aug 2016 22:30:54.8551 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2368 Archived-At: Subject: [Unbearable] RSA padding schemes 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, 19 Aug 2016 22:31:01 -0000 --_000_SN2PR03MB2367A820D0A85626DC2A85B2B0160SN2PR03MB2367namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The RSA key information about padding needs more details on Page 6. /*When an rsa2048_pkcs1.5 or rsa2048_pss key is used, TokenBinding.signature contains the signature generated using, respectively, the RSASSA-PKCS1-v1_5 or RSASSA-PSS signature scheme defined in [RFC3447]. RSAPublicKey.modulus and RSAPublicKey.publicexponent contain the length-prefixed modulus and exponent of the RSA public key represented in big-endian format.*/ Specifically we should mention that the padding hash algorithm used for bot= h RSA key types is SHA256 and we need to also close on the salt length for = PSS padding. *RFC3447* mentions the typical salt lengths, if using 0 is easier and has n= o adverse security effect, we could use that. /* 4. Typical salt lengths in octets are hLen (the length of the output of the hash function Hash) and 0. In both cases the security of RSASSA-PSS can be closely related to the hardness of inverting RSAVP1. Bellare and Rogaway [4] give a tight lower bound for the security of the original RSA-PSS scheme, which corresponds roughly to the former case, while Coron [12] gives a lower bound for the related Full Domain Hashing scheme, which corresponds roughly to the latter case. In [13] Coron provides a general treatment with various salt lengths ranging from 0 to hLen; see [27] for discussion. See also [31], which adapts the security proofs in [4][13] to address the differences between the original and the present version of RSA-PSS as listed in Note 1 above. */ Thanks Pranav --_000_SN2PR03MB2367A820D0A85626DC2A85B2B0160SN2PR03MB2367namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The RSA key information about padding needs more details o= n Page 6.

 

/*When an rsa2048_pkcs1.5 or rsa2048_pss key is used,
   TokenBinding.signature contains the signature generated u=
sing,
   respectively, the RSASSA-PKCS1-v1_5 or RSASSA-PSS signatu=
re scheme
   defined in [RFC3447].  RSAPublicKey.modulus and=

   RSAPublicKey.publicexponent contain the length-prefixed m=
odulus and
   exponent of the RSA public key represented in big-endian =
format.*/
 
Specifically we should mention that the padding hash algorithm used fo=
r both RSA key types is SHA256 and we need to also close on the salt length=
 for PSS padding.
*RFC3447* mentions the typical salt lengths, if using 0 is easier and =
has no adverse security effect, we could use that.

 

  /*

4. Typical salt lengths in octets are hLen (the length of = the output

      of the hash function Hash) = and 0.  In both cases the security of

      RSASSA-PSS can be closely r= elated to the hardness of inverting

      RSAVP1.  Bellare and R= ogaway [4] give a tight lower bound for the

      security of the original RS= A-PSS scheme, which corresponds roughly

      to the former case, while C= oron [12] gives a lower bound for the

      related Full Domain Hashing= scheme, which corresponds roughly to

      the latter case.  In [= 13] Coron provides a general treatment with

      various salt lengths rangin= g from 0 to hLen; see [27] for

      discussion.  See also = [31], which adapts the security proofs in

      [4][13] to address the diff= erences between the original and the

      present version of RSA-PSS = as listed in Note 1 above.

*/

 

Thanks

Pranav

--_000_SN2PR03MB2367A820D0A85626DC2A85B2B0160SN2PR03MB2367namp_-- From nobody Fri Aug 19 16:46:24 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 535F312B01A for ; Fri, 19 Aug 2016 16:46:22 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 eTqjEeFPGnqe for ; Fri, 19 Aug 2016 16:46:20 -0700 (PDT) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) by ietfa.amsl.com (Postfix) with SMTP id 9E34F12B016 for ; Fri, 19 Aug 2016 16:46:19 -0700 (PDT) Received: (qmail 4931 invoked by uid 0); 19 Aug 2016 23:46:18 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy9.mail.unifiedlayer.com with SMTP; 19 Aug 2016 23:46:18 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id ZBmD1t00U2UhLwi01BmGxk; Fri, 19 Aug 2016 17:46:16 -0600 X-Authority-Analysis: v=2.1 cv=aqYhV0pV c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=77f3tqhD720A:10 a=7z1cN_iqozsA:10 a=rBg2x4foAAAA:8 a=yMhMjlubAAAA:8 a=niDRw0lRAAAA:8 a=bt8Zh30PAAAA:8 a=aU_5aHkNgor5isPs0J4A:9 a=QEXdDO2ut3YA:10 a=_sisPKfVZPIchDll9nnY:22 a=BKKCjISod1eDJeS0ORpz:22 a=_t3twUByYarg8YYgHZbc:22 a=oiBpN-rYJXxenNlZAEox:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:To:Subject:From; bh=GgcuO+VZUfZEh70w0exlNhFSdgz+fvjbXyzKbt0Jvb4=; b=vAAEJwiF8nfYNsQQnkwrPv7Xr1 zHL/Rr2vhvcL1tQlhTuhY2+9gidTVZstvC5nmojIMo82RSTZbZqlMpldlE1mhHuVhjL7NhePyygw2 bgFsZX9d6OizLMkMm8soK/nhi; Received: from [173.224.162.69] (port=30378 helo=[10.225.80.63]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from ) id 1batUN-0005TJ-CJ for unbearable@ietf.org; Fri, 19 Aug 2016 17:46:15 -0600 From: =JeffH To: IETF TokBind WG Message-ID: <4966a25d-9ee2-6a3c-2b88-0770e54df774@KingsMountain.com> Date: Fri, 19 Aug 2016 16:46:15 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 173.224.162.69 authed with jeff.hodges+kingsmountain.com} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-Source-IP: 173.224.162.69 X-Exim-ID: 1batUN-0005TJ-CJ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.225.80.63]) [173.224.162.69]:30378 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 0 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Unbearable] TB APIs in (ASP).NET 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, 19 Aug 2016 23:46:22 -0000 Andrei wrote on Wednesday, April 6, 2016... > At the meeting on Monday, there were a number of questions about > platform support for TB and the APIs available to implementers. > > Here are some links to (ASP).NET TB API documentation: > > ASP.Net: > > > .NET code sample (see under “Networking enhancements”): > > > .NET TokenBinding class: > > > Native TB library API, for those who don’t believe in garbage > collectors: > thanks for sharing that, Andrei, it's useful. This class is also helpful in understanding how one would use the TokenBinding class, as it exposes the GetTlsTokenBindings() method.. A direct link to the example code (from ".NET code sample" page, above) is here.. fwiw, the above appears to be an example of server-side code that is checking the Token Binding IDs, contained within security tokens, with the TB ID of the connection the security token is received over. HTH, =JeffH From nobody Fri Aug 19 17:20: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 413FD12D1A2 for ; Fri, 19 Aug 2016 17:20:35 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=kingsmountain.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 YpFm2_D5-DYm for ; Fri, 19 Aug 2016 17:20:33 -0700 (PDT) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id A6272120727 for ; Fri, 19 Aug 2016 17:20:32 -0700 (PDT) Received: (qmail 4123 invoked by uid 0); 20 Aug 2016 00:20:31 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy8.mail.unifiedlayer.com with SMTP; 20 Aug 2016 00:20:31 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id ZCLS1t0022UhLwi01CLVFf; Fri, 19 Aug 2016 18:20:30 -0600 X-Authority-Analysis: v=2.1 cv=FKmImYYs c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=77f3tqhD720A:10 a=7z1cN_iqozsA:10 a=NEAV23lmAAAA:8 a=A1X0JdhQAAAA:8 a=TWw20LiNAAAA:8 a=0O10OBC1AAAA:8 a=v3pRx2IDDs2HAQH4duEA:9 a=QEXdDO2ut3YA:10 a=Bn2pgwyD2vrAyMmN8A2t:22 a=Df3jFdWbhGDLdZNm0fyq:22 a=vUXOqzjyz3VoZHwhwPXo:22 a=z3GBQHkLwHYAHbgLuAK9:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To; bh=G/7wxEUK5uVZvDZJGUrZVpL+luhTYKi3luwHlOYLqEE=; b=0ubvhlIrc0APz6Q8e0+oqgRm6q fxeLAG9608CvJV756bpW8nG8bWFrYON8f8fDXFIiwjzu9n34FD2/lGFY08qiioSO0P3i11L5XL39/ 5e9GK4l4WdaGIfTiPNaFiqd3z; Received: from [173.224.162.69] (port=64739 helo=[10.225.80.63]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from ) id 1bau1T-0000Yv-7O for unbearable@ietf.org; Fri, 19 Aug 2016 18:20:27 -0600 To: IETF TokBind WG From: =JeffH Message-ID: <92fe55a2-cd20-1038-f9a8-50ee598312ac@KingsMountain.com> Date: Fri, 19 Aug 2016 17:20:27 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 173.224.162.69 authed with jeff.hodges+kingsmountain.com} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-Source-IP: 173.224.162.69 X-Exim-ID: 1bau1T-0000Yv-7O X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.225.80.63]) [173.224.162.69]:64739 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 0 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance 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, 20 Aug 2016 00:20:35 -0000 Nick Harper wrote on Mon, 25 Jul 2016 15:21:15 -0700... > > I'm still concerned that the privacy concerns are not being addressed > with this proposal. Section 4.1 of the HTTPS draft states that the > common idea among the federation mechanisms is that the server > signals to the client to reveal its provided TBID to another server > (with the Include-Referred-Token-Binding-ID header being one such > mechanism). However, the wording in this pull request makes no > indication that the use of this API to set referred TBIDs would be > limited to when the referring server indicates to do so. I've added some commits to https://github.com/TokenBinding/Internet-Drafts/pull/54 addressing the above, as well as line-level comments Nick made in github. > The new section in "Privacy Considerations" ..entitled "Correlation".. > is missing some of the > cases of correlation that could happen. Suppose Example App decides > to send a referred TBID (for its connection to example.com) on every > HTTPS request it makes, and it happens to make requests to evil1.com > and evil2.com (whose operators are trying to correlate traffic > between them). This referred TBID is the same on both requests, and > the site operators can now correlate requests, whereas if the app > didn't (mis)use the API for setting referred TBIDs, the site > operators wouldn't have been able to use Token Binding to correlate > the requests. I think this example contradicts the wording that > states "If the application is already aware of these other > connections to these endpoints, then no additional information is > being exposed." In this case, the application is aware of the > connections (to evil1.com and evil2.com), yet the referred TBIDs that > it sends can be used for correlation, which is additional information > being exposed. I believe the proposed language does address the above scenario -- the app misuses the API, and ignores the advice in the "correlation" section of the spec, specifically to do a privacy analysis. > I also wouldn't mind the Privacy Considerations > section reiterating the point that a referred TBID should only be > sent when indicated to do so by the referring server. done. HTH, =JeffH From nobody Fri Aug 19 17:24:14 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 9810412D143 for ; Fri, 19 Aug 2016 17:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 L4DIUKVbkA5O for ; Fri, 19 Aug 2016 17:24:10 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0115.outbound.protection.outlook.com [104.47.34.115]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E34AC120727 for ; Fri, 19 Aug 2016 17:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hLrJJbb21KSX3bddWUUn2Q8YvAnZLUiLI9QpKzCFFPw=; b=mTQVT+4Cxq4Yi66xtIIPGFsH2aaNJiH1+DG20w3Ei95NycVFa53H64+c5ECtvPcuBdvwRCi561fYjaZS8jhn6Aj57qeS4dx6SxGeBOImV1lLrnSmPSirxoy8KvdnEY1+2msi9W2BU4YvoexyR7tPW0oYXFw/4oRuwrb3WAATok4= Received: from SN1PR0301MB1645.namprd03.prod.outlook.com (10.162.130.139) by SN1PR0301MB1646.namprd03.prod.outlook.com (10.162.130.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Sat, 20 Aug 2016 00:24:07 +0000 Received: from SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) by SN1PR0301MB1645.namprd03.prod.outlook.com ([10.162.130.139]) with mapi id 15.01.0549.029; Sat, 20 Aug 2016 00:24:07 +0000 From: Mike Jones To: =JeffH , IETF TokBind WG Thread-Topic: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance Thread-Index: AQHR+nivzhVt9tIIjUKbfHv6d99C7qBQ/Ugw Date: Sat, 20 Aug 2016 00:24:07 +0000 Message-ID: References: <92fe55a2-cd20-1038-f9a8-50ee598312ac@KingsMountain.com> In-Reply-To: <92fe55a2-cd20-1038-f9a8-50ee598312ac@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [2001:4898:80e8:8::214] x-ms-office365-filtering-correlation-id: f0f3293e-6b25-4054-9692-08d3c8904cb6 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1646; 6:0RVp6O7Q4sSQCqc0Ubu2HwIeG8NP9TW8AP+y/UUNFtbiVHJyS67uktnGQnZl0YeJMQyhgdRe9/13CkN6sKk5rEYAnvgKI8+N6bI6DCBohbbN/q1qoWpNxpa6lUfe3E+KZQJZr5w6V5mQEKagOwzSLTdg6cAr6vtmUQu3fvAliSyQrhEtyHIYTrLLtj52TX+I6Su3PMYo3fzQDq/zSfgB95/qvmrbrV19NtIQineFbIG0ceFQvuA/b2ruxP1wrD+Teg+lUonxz8Cbe7H62uSTDL2FPAH7Y77loeTVtgXu39LzM7ipaiw4E6WRlCSKfAc66uFSau/5/0JtDKW8bHIjww==; 5:YjfhGXJziahMNggYl0wszAPFqV/4KXePe96c/+wEcFZdIlO+p6Jyq0riQ7PJPL4Ira0TOL2edpffulwPgJ6+4rLB/rC6O7DZRvCs8E8nYUc0eaFUxRfIKl9cLzyfBOFnLTnS41MIxH31T8Q72PKkKw==; 24:A+anavaulPW5UQTFatVaO7nnKajpXXtjBt2mAGfOrf8qYXJzkRp/PiYAz3xqewLUrpoUJX9/gd0nSeHrB7Cc/7Z28Mve2B4LkOKU6VEZZms=; 7:ZtPjB2IKrwpDvYv8E0R7MB/7OryQggoRLGiSW0ZxDT0CRdpYssj9yEt9ZPcGeuLIe5mbGQgTfu9unCHVBzLr4J5tuyXSIfiqAdh6S4WzKWOBW2qfc+b+hv5UEq+oTNBj8ts+BOojFGJljmmmvMOl2tOiytsXGS3+X0EAXgpDUTxuZn527ppyhqfpZcXvjfiTjpOlfSverE2dIyPna8FYBMvLhFujqoQfHGtu4UEwMJ3vEyVQhFLu7Dr7o9dNYLP2 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1646; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:SN1PR0301MB1646; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1646; x-forefront-prvs: 0040126723 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(13464003)(189002)(199003)(76576001)(50986999)(86612001)(54356999)(76176999)(106356001)(106116001)(99286002)(86362001)(11100500001)(5002640100001)(7736002)(10090500001)(7696003)(7846002)(8990500004)(10400500002)(10290500002)(5005710100001)(105586002)(87936001)(74316002)(101416001)(33656002)(305945005)(561944003)(19580395003)(19580405001)(81156014)(81166006)(122556002)(15975445007)(3280700002)(2900100001)(2950100001)(8676002)(3660700001)(77096005)(8936002)(2906002)(9686002)(68736007)(102836003)(6116002)(5001770100001)(97736004)(586003)(107886002)(92566002)(189998001)(5660300001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1646; H:SN1PR0301MB1645.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 20 Aug 2016 00:24:07.5450 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1646 Archived-At: Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api guidance 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, 20 Aug 2016 00:24:12 -0000 I'm good with these changes and comments. Thanks for doing this, Jeff! -- Mike -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of =3DJeffH Sent: Friday, August 19, 2016 5:20 PM To: IETF TokBind WG Subject: Re: [Unbearable] PR#54: TBPROTO-09: address implementation/api gui= dance Nick Harper wrote on Mon, 25 Jul 2016 15:21:15 -0700... > > I'm still concerned that the privacy concerns are not being addressed >= with this proposal. Section 4.1 of the HTTPS draft states that the > comm= on idea among the federation mechanisms is that the server > signals to th= e client to reveal its provided TBID to another server > (with the Include= -Referred-Token-Binding-ID header being one such > mechanism). However, th= e wording in this pull request makes no > indication that the use of this = API to set referred TBIDs would be > limited to when the referring server = indicates to do so. I've added some commits to https://github.com/TokenBinding/Internet-Drafts/pull/54 addressing the abov= e, as well as line-level comments Nick made in github. > The new section in "Privacy Considerations" ..entitled "Correlation".. > is missing some of the > cases of correlation that could happen. Suppose Example App decides > t= o send a referred TBID (for its connection to example.com) on every > HTTP= S request it makes, and it happens to make requests to evil1.com > and evi= l2.com (whose operators are trying to correlate traffic > between them). T= his referred TBID is the same on both requests, and > the site operators c= an now correlate requests, whereas if the app > didn't (mis)use the API fo= r setting referred TBIDs, the site > operators wouldn't have been able to = use Token Binding to correlate > the requests. I think this example contra= dicts the wording that > states "If the application is already aware of th= ese other > connections to these endpoints, then no additional information= is > being exposed." In this case, the application is aware of the > con= nections (to evil1.com and evil2.com), yet the referred TBIDs that > it se= nds can be used for correlation, which is additional information > being e= xposed. I believe the proposed language does address the above scenario -- the app = misuses the API, and ignores the advice in the "correlation" section of the= spec, specifically to do a privacy analysis. > I also wouldn't mind the Privacy Considerations > section reiterating t= he point that a referred TBID should only be > sent when indicated to do s= o by the referring server. done. HTH, =3DJeffH _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable From nobody Fri Aug 19 18:45: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 0803212D1B8 for ; Fri, 19 Aug 2016 18:45:33 -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 c6JUXRoZbbC2 for ; Fri, 19 Aug 2016 18:45:30 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0700.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::700]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8E512B076 for ; Fri, 19 Aug 2016 18:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=z0wNwgqQdIYTA2Uc3KXqnkuBD+eINk5PmRDT//3QPlA=; b=A5CnTi36tQ7YjyMpz+/63wralCUmMvGwL0crPbsaaq6xo7QAuhsmxE1vvikyBh5JLRrjbN4zAj9kfuF/IaXGxA6kcwnvee5XXTymgBIDinYA2zHAyibgbi27TWU64pK3lEy5oc23qOGtAJeej1oypIL0PmE+sxS7IMLRng/n/+w= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2363.namprd03.prod.outlook.com (10.166.207.150) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Sat, 20 Aug 2016 01:45:27 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0557.027; Sat, 20 Aug 2016 01:45:27 +0000 From: Andrei Popov To: Pranav Kukreja , "unbearable@ietfa.amsl.com" Thread-Topic: RSA padding schemes Thread-Index: AdH6aTyCahuRxvpCSzqArpxwa30ImwAGuQIA Date: Sat, 20 Aug 2016 01:45:26 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:5::1d2] x-ms-office365-filtering-correlation-id: 6b05c9f1-fccd-49ff-91fa-08d3c89ba90c x-microsoft-exchange-diagnostics: 1; CY1PR03MB2363; 6:J07Z//CZc5jb2ZyyBBCS//jRhd/x+olTiTRDFOprC+qekmUbLWfEPN2vPui7eBkWhQ6PX5eZQYj50MNaTss2m61OmRk7RTqmLsNJmFGmgbrDr+WphFDC1dcSnFtFy09Cfqknd/EQ85F/PLmtf+XkT7QzrU1grqCzmeh9LT5nkptjuq9ez1j7Em/5NQrtfCoc0yCphnGz03kHCfoF1mR+vyc96s/wIHa64+zH0D0uWACOSvezdHV2et1SZuCfxqB921z4tH3nBqDZzGcKiH8klEZcwjeiZW7xCAB0p5LJ67HO3s0BwJ0M1hs5K0EOQRXtDvjdKFOMC/gpxSZuBBRT7Q==; 5:p9IbiGovtDgqi9Zwt7JasO4vvBiAWwFrceP9LQAbGCi4Q033UCa3FnVFsqp1d3UZAmgUy72Ucs59l2Jc86ddMGS8xWzhWHIiO6peyK8uWXL81c3G/DQP0cusyew4UI5iU39sdxCO2cVgB1tq4vpqkQ==; 24:3ta5zywBqBhrRIzLPFrasNhTufz0ZC8sXEm+li9YtXmX0f9RkLiUv/wwtGiy+spl1iGYci9ikCYEYPIZYcYSTltbW9hFlHSttlbxfFRKx7E=; 7:dNbTYzOZfOZphPT1p/rVTcpsnZYr/8xvXf+I2gaK6PE3850b5tnddlTiuhqffhK0TlSO/dh1My5kpVZr+ApvScLpmVlrBz0KJX+wUPdQyWKGhBdN0cneM+4pr2aLta6w0QVHoVWiS3Vd9DsUYUpe6lMbw6JzES2uKOPoZmMNxBegiIKsThRBCunxVzUuVkqo6l48mwE9sd1QqzR+RnWdxLCga8KofSPWeLCe8Y8lgN9H1fKAliZSmlFnUxrAnLCg x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2363; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2363; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2363; x-forefront-prvs: 0040126723 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(377454003)(1511001)(7696003)(189998001)(19580395003)(2501003)(19625215002)(2900100001)(3280700002)(2950100001)(3480700004)(7736002)(54356999)(102836003)(97736004)(5660300001)(10090500001)(790700001)(101416001)(76176999)(9686002)(107886002)(7846002)(5005710100001)(8990500004)(19580405001)(586003)(68736007)(11100500001)(5002640100001)(86612001)(6116002)(5001770100001)(450100001)(105586002)(86362001)(16236675004)(50986999)(76576001)(33656002)(87936001)(3660700001)(19300405004)(81166006)(2561002)(10400500002)(8936002)(106356001)(74316002)(2421001)(2906002)(10290500002)(15975445007)(8676002)(122556002)(77096005)(81156014)(92566002)(7116003)(99286002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2363; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB2155678ED1E7E8F81BEA85AE8C170CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2016 01:45:26.9480 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2363 Archived-At: Subject: Re: [Unbearable] RSA padding schemes 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, 20 Aug 2016 01:45:33 -0000 --_000_CY1PR03MB2155678ED1E7E8F81BEA85AE8C170CY1PR03MB2155namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Opened GitHub issue #70 for tracking. Cheers, Andrei From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Pranav K= ukreja Sent: Friday, August 19, 2016 3:31 PM To: unbearable@ietfa.amsl.com Subject: [Unbearable] RSA padding schemes The RSA key information about padding needs more details on Page 6. /*When an rsa2048_pkcs1.5 or rsa2048_pss key is used, TokenBinding.signature contains the signature generated using, respectively, the RSASSA-PKCS1-v1_5 or RSASSA-PSS signature scheme defined in [RFC3447]. RSAPublicKey.modulus and RSAPublicKey.publicexponent contain the length-prefixed modulus and exponent of the RSA public key represented in big-endian format.*/ Specifically we should mention that the padding hash algorithm used for bot= h RSA key types is SHA256 and we need to also close on the salt length for = PSS padding. *RFC3447* mentions the typical salt lengths, if using 0 is easier and has n= o adverse security effect, we could use that. /* 4. Typical salt lengths in octets are hLen (the length of the output of the hash function Hash) and 0. In both cases the security of RSASSA-PSS can be closely related to the hardness of inverting RSAVP1. Bellare and Rogaway [4] give a tight lower bound for the security of the original RSA-PSS scheme, which corresponds roughly to the former case, while Coron [12] gives a lower bound for the related Full Domain Hashing scheme, which corresponds roughly to the latter case. In [13] Coron provides a general treatment with various salt lengths ranging from 0 to hLen; see [27] for discussion. See also [31], which adapts the security proofs in [4][13] to address the differences between the original and the present version of RSA-PSS as listed in Note 1 above. */ Thanks Pranav --_000_CY1PR03MB2155678ED1E7E8F81BEA85AE8C170CY1PR03MB2155namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Opened GitHub issue #70 for tracking.

 

Cheers,

 

Andrei

 

From: Unbearable [mailto:unbearable-bounces@i= etf.org] On Behalf Of Pranav Kukreja
Sent: Friday, August 19, 2016 3:31 PM
To: unbearable@ietfa.amsl.com
Subject: [Unbearable] RSA padding schemes

 

The RSA key information about padding needs more details o= n Page 6.

 

/*When an rsa2048_pkcs1.5 or rsa2048_pss key is used,
   TokenBinding.signature contains the signature generated u=
sing,
   respectively, the RSASSA-PKCS1-v1_5 or RSASSA-PSS signatu=
re scheme
   defined in [RFC3447].  RSAPublicKey.modulus and=

   RSAPublicKey.publicexponent contain the length-prefixed m=
odulus and
   exponent of the RSA public key represented in big-endian =
format.*/
 
Specifically we should mention that the padding hash algorithm used fo=
r both RSA key types is SHA256 and we need to also close on the salt length=
 for PSS padding.
*RFC3447* mentions the typical salt lengths, if using 0 is easier and =
has no adverse security effect, we could use that.

 

  /*

4. Typical salt lengths in octets are hLen (the length of = the output

      of the hash function Hash) = and 0.  In both cases the security of

      RSASSA-PSS can be closely r= elated to the hardness of inverting

      RSAVP1.  Bellare and R= ogaway [4] give a tight lower bound for the

      security of the original RS= A-PSS scheme, which corresponds roughly

      to the former case, while C= oron [12] gives a lower bound for the

      related Full Domain Hashing= scheme, which corresponds roughly to

      the latter case.  In [= 13] Coron provides a general treatment with

      various salt lengths rangin= g from 0 to hLen; see [27] for

      discussion.  See also = [31], which adapts the security proofs in

      [4][13] to address the diff= erences between the original and the

      present version of RSA-PSS = as listed in Note 1 above.

*/

 

Thanks

Pranav

--_000_CY1PR03MB2155678ED1E7E8F81BEA85AE8C170CY1PR03MB2155namp_-- From nobody Tue Aug 23 09:59:34 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 BE41F12B037 for ; Tue, 23 Aug 2016 09:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 1yah4F6uAiv2 for ; Tue, 23 Aug 2016 09:59:29 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0092.outbound.protection.outlook.com [104.47.36.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3767F12D5DE for ; Tue, 23 Aug 2016 09:59:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5dkfVzjWyjNOPNc0soK1TTNY2VbdJY48vkGYh0ILuq4=; b=nxWtCQqJVYVXzrxujU0MqNvUzSswU8LYP8z2CysYFtTH+LQWoD3CSCelwkKJwfiO+hF6c245U/nfo8iT/eg5BTLIZfrq73ojWRsLeC1BG0BaEly2FA+xSYa5A5j/mpb5LlkS4KCDCuys98kSI6uUDsznOUsY5ftj35iloh0ZDNY= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2153.namprd03.prod.outlook.com (10.166.206.138) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Tue, 23 Aug 2016 16:59:26 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0587.013; Tue, 23 Aug 2016 16:59:26 +0000 From: Andrei Popov To: Martin Thomson , Bill Cox , Brian Campbell , "Nick Harper" Thread-Topic: [Unbearable] TLS extension: version field Thread-Index: AQHR8UE0hAr3fGh5LkSos3djbwbcUaA/MmwAgAAmOoCAAAGk8IAAhvMAgAAFqjCAAAO6AIAA6WmAgAATAoCAABJZgIAV3xfw Date: Tue, 23 Aug 2016 16:59:26 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: e065da5b-14c9-4ae2-d66f-08d3cb76d720 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2153; 6:FElD55hJpfF1KfIRSCc10n1IufENblXk807UIxe2wiy+uOAOiqOkX8sCOIq6ypeOyn1Yh2BvcUS5Cs7jTvV9+kuOn033CXzukz4320UYMm5cAIej7L6f6fnjo9tpt8+8yVZDYr0QSoJUsaOaEmmZrxYg/3hnoDlsT71XAWaf/wSuyYJsDk9OJ87glzuhaLVXi+hEx7MeEh7xykYFEVLtp4srFBBG5oPtpmwFCND4/lHlM7Toepn6cXQxmONa2kfuNoFGOF5MPhWOiHRTu8v+jQiytbtuCmKXR1uPFsAMoBdsylKRQ7wK6gLtfxLnXmFXbOl/Mxlvegsv2WfpAwP7qw==; 5:FN8ZfF9gwCa1LBIv4OtZWD/2erlMCaG4ODR38RAnNlbunS6ry2Iaznp9pT06W65zsPyFxh5eAi5vgb9LK4nyqJCDmSk/NslaFjOXhDirHAk0OUVfl3uP7C7EC2Y4HmmlsVIB1BSl989i/jcTXWGkiw==; 24:uNZD7isq1+MiTZczTnnZSAYWTPQcAI3lYEDTcFBscH4SkHk5PUx6e0a00MwF8GyryqJ4oDARymmVqw99jYaUcX5deGY0OInUYSW+dzfEjIA=; 7:UgJOrJgJkQ3CCpAj3+61XkNOlk4k5FfJzsWLMgolJnMsrUEe2QGF2vZDEPisOTbC5hLkUHkjGkeRv8oPc3xa/c8a+G5127RpB9Vh7islaa6MOhueQWgSUBnOhg0zTlM7WCI0gJQvOwWtvLbf8NBxLvUM5WA4JN0zL/Nf8zJxFhEV+CaYCIi4KedMW9veRbwlfNggbtYvooPib7qaM7NaC4avnTHssSGn7Z8A+WX948wjKqc1I7AbIbnrse0hQLBS x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2153; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2153; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2153; x-forefront-prvs: 004395A01C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(13464003)(24454002)(377454003)(106116001)(33656002)(76176999)(99286002)(93886004)(86612001)(16236675004)(189998001)(97736004)(5001770100001)(54356999)(19617315012)(105586002)(106356001)(19580395003)(8936002)(81166006)(7846002)(9686002)(92566002)(7736002)(7696003)(11100500001)(87936001)(81156014)(74316002)(8676002)(7906003)(50986999)(19300405004)(19609705001)(3660700001)(10290500002)(4326007)(76576001)(68736007)(3280700002)(790700001)(19580405001)(6116002)(2906002)(10090500001)(102836003)(586003)(86362001)(5660300001)(8990500004)(10400500002)(561944003)(5005710100001)(122556002)(77096005)(2900100001)(15975445007)(19625215002)(5002640100001)(2950100001)(101416001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2153; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB215544A7CB0A9BD068C9AD228CEB0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2016 16:59:26.3063 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2153 Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] TLS extension: version field 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, 23 Aug 2016 16:59:33 -0000 --_000_CY1PR03MB215544A7CB0A9BD068C9AD228CEB0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbSB0aGUgcHJhY3RpY2FsIHN0YW5kcG9pbnQsIGlmIHdlIGdvIHdpdGggb25lIFRMUyBleHRl bnNpb24gZm9yIGVhY2ggc3VwcG9ydGVkIFRCIHZlcnNpb24sIHdoYXQgVExTIGV4dGVuc2lvbiBJ RCBzaG91bGQgd2UgdXNlIHRvIGluZGljYXRlIHN1cHBvcnQgZm9yIHRoZSB1cGNvbWluZyAwLjkg ZHJhZnQ/DQoNCkFsc28sIGRvZXMgQ2hyb21lIGFscmVhZHkgdXNlIHRoZSBjdXJyZW50IGVhcmx5 IElBTkEgYXNzaWdubWVudCAoMjQpIHRvIG5lZ290aWF0ZSBUQiB2MC44Pw0KDQpGcm9tOiBCcmlh biBDYW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tXQ0KU2VudDogVHVl c2RheSwgQXVndXN0IDksIDIwMTYgMTE6NDQgQU0NClRvOiBOaWNrIEhhcnBlciA8bmhhcnBlckBn b29nbGUuY29tPg0KQ2M6IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+ OyB1bmJlYXJhYmxlQGlldGYub3JnOyBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21h aWwuY29tPjsgQmlsbCBDb3ggPHdheXdhcmRnZWVrQGdvb2dsZS5jb20+DQpTdWJqZWN0OiBSZTog W1VuYmVhcmFibGVdIFRMUyBleHRlbnNpb246IHZlcnNpb24gZmllbGQNCg0KSSB0ZW5kIHRvIGFn cmVlIHdpdGggTWFydGluIGFuZCBOaWNrJ3MgcGVyc3BlY3RpdmUgaGVyZS4gS2V5IHBhcmFtZXRl cnMsIHRva2VuIGJpbmRpbmcgdHlwZXMsIGFuZCBleHRlbnNpb25zIGFscmVhZHkgcHJvdmlkZSBm b3IgYSBmYWlyIGFtb3VudCBvZiBleHRlbnNpYmlsaXR5LiBPbmUgY2FuJ3QgcmVsaWFibHkgcHJl ZGljdCB0aGUgZnV0dXJlIGJ1dCBpdCBzZWVtcyBtb3JlIGxpa2VseSB0aGFuIG5vdCB0aGF0IHRo ZSBmaXJzdCB2ZXJzaW9uIG9mIFRCICh3aGljaCBkb2Vzbid0IGV2ZW4gZXhpc3QgeWV0KSBjb3Vs ZCB3ZWxsIGhhdmUgYSBuaWNlIGxvbmcgcnVuIGJlZm9yZSBhIG5ldyB2ZXJzaW9uIGlzIG5lZWRl ZC4gQSBuZXcgZXh0ZW5zaW9uIGNhbiBiZSBkb25lIGlmIGFuZCB3aGVuIHRoYXQgdGltZSBjb21l cyBhbmQgd29ya2luZyB3aXRoIGV4aXN0aW5nIFRMUyBleHRlbnNpb25zIGlzIG11Y2ggbW9yZSBs aWtlbHkgdG8gd29yayBpbiBwcmFjdGljZSB0aGFuIGEgdmVyc2lvbiBtZWNoYW5pc20gd2l0aGlu IHRoZSBUQiB0aGF0IHdvbnQgcmVhbGx5IGJlIGV4ZXJjaXNlZCBiZWNhdXNlIHRoZXJlJ3Mgb25s eSBvbmUgdmVyc2lvbi4gSW4gbWVhbnRpbWUgdGhlIGNsaWVudCBhbmQgc2VydmVyIGhlbGxvIGNh biB1c2UgYSBmZXcgbGVzcyBieXRlcyAobm8gdmVyc2lvbikgaW4gdGhlIG9yZGluYXJ5IGNhc2Ug b2YgbmVnb3RpYXRpbmcgdGhlIG9ubHkgdmVyc2lvbiBvZiBUQiB0aGF0IGV4aXN0cyAoZXIsIHdp bGwgZXhpc3Qgc29vbikuDQoNCg0KDQpPbiBUdWUsIEF1ZyA5LCAyMDE2IGF0IDExOjM4IEFNLCBO aWNrIEhhcnBlciA8bmhhcnBlckBnb29nbGUuY29tPG1haWx0bzpuaGFycGVyQGdvb2dsZS5jb20+ PiB3cm90ZToNCklmIHdlIGxlYXZlIGl0IGFzIGlzLCB0aGUgdmVyc2lvbiBmaWVsZCBpcyBsaWtl bHkgdG8gb3NzaWZ5IChsaWtlIGl0IGhhcyB3aXRoIGV2ZXJ5IHZlcnNpb24gb2YgU1NMIGFuZCBU TFMpLCBzbyB0aGVyZSdzIGEgZGVjZW50IGNoYW5jZSB0aGF0IGZvciBzb21lIGltcGxlbWVudGF0 aW9ucyBpdCB3b24ndCB3b3JrIChhIHZlcnNpb24gaW50b2xlcmFudCBzZXJ2ZXIgd291bGQgcmVq ZWN0IGEgY2xpZW50J3MgdjIgdG9rZW4gYmluZGluZyBuZWdvdGlhdGlvbiwgaW5zdGVhZCBvZiBm YWxsaW5nIGJhY2sgdG8gdjE7IHNlcGFyYXRlIGV4dGVuc2lvbnMgZG9uJ3QgaGF2ZSB0aGlzIHBy b2JsZW0pLg0KVGhpcyB2ZXJzaW9uIGZpZWxkIGFsc28gYXNzdW1lcyB0aGF0IHRoZSBvbmx5IHRo aW5nIChhcGFydCBmcm9tIHZlcnNpb24gbnVtYmVyKSB0aGF0IG5lZWRzIHRvIGJlIG5lZ290aWF0 ZWQgaXMgdGhlIGtleSBwYXJhbWV0ZXJzLiBJZiBhIHRva2VuIGJpbmRpbmcgdjIgaXMgYWRkZWQs IHdpbGwgaXQgd2FudCB0byBuZWdvdGlhdGUgc29tZXRoaW5nIGVsc2UgKGFuZCB0aGVuIG5lZWQg YSBuZXcgVExTIGV4dGVuc2lvbik/DQoNCkknbSB3b25kZXJpbmcgd2hhdCBmdXR1cmUgY2hhbmdl cyB0byB0b2tlbiBiaW5kaW5nIG1pZ2h0IGxvb2sgbGlrZSB0aGF0IHJlcXVpcmUgYnVtcGluZyB0 aGUgcHJvdG9jb2wgdmVyc2lvbiBudW1iZXIuIEkga25vdyB0aGF0IGtleSBhdHRlc3RhdGlvbiBp cyBzb21ldGhpbmcgdGhhdCBjb3VsZCBwb3RlbnRpYWxseSBiZSBhZGRlZC4gTXkgdW5kZXJzdGFu ZGluZyBpcyB0aGF0IHRoaXMgd291bGQgZ28gaW4gYW4gRXh0ZW5zaW9uIGluIHRoZSBUb2tlbkJp bmRpbmcgc3RydWN0LCBhbmQgd291bGRuJ3QgbmVlZCB0byBidW1wIHRoZSBwcm90b2NvbCB2ZXJz aW9uIG51bWJlci4gRm9yIHRoZSBwcm90b2NvbCB2ZXJzaW9uIG51bWJlciB0byBiZSBjaGFuZ2Vk LCBzb21ldGhpbmcgd291bGQgaGF2ZSB0byBjaGFuZ2UgdGhlIFRva2VuQmluZGluZ01lc3NhZ2Ug Zm9ybWF0IChvciB0aGUgZm9ybWF0IG9mIG9uZSBvZiBpdHMgZmllbGRzKS4gVGhlcmUncyBhbHJl YWR5IGEgZGVjZW50IGFtb3VudCBvZiBleHRlbnNpYmlsaXR5IHRoZXJlIGluIHRlcm1zIG9mIGtl eSBwYXJhbWV0ZXJzLCB0b2tlbiBiaW5kaW5nIHR5cGVzLCBhbmQgZXh0ZW5zaW9ucy4gQ2hhbmdp bmcgdGhlIHNpZ25hdHVyZSB0byBiZSBvZiBzb21ldGhpbmcgYmVzaWRlcyB0aGUgRUtNIHZhbHVl IGlzIHRoZSBvbmx5IHRoaW5nIHRoYXQgY29tZXMgdG8gbXkgbWluZCB0aGF0IHdvdWxkIGZpdCBp biB0aGlzIGZvcm1hdCBhbmQgcmVxdWlyZSBjaGFuZ2luZyB0aGUgdmVyc2lvbiBudW1iZXIuDQoN CklmIG1vcmUgc3Vic3RhbnRpYWwgY2hhbmdlcyBhcmUgbWFkZSB0byB0aGUgVG9rZW5CaW5kaW5n TWVzc2FnZSwgSSBpbWFnaW5lIHRoYXQgY2hhbmdlcyB3aWxsIG5lZWQgdG8gYmUgbWFkZSB0byBu ZWdvdGlhdGlvbiB0byBzdXBwb3J0IHRob3NlIGNoYW5nZXMuIEluIHRoYXQgY2FzZSwgdGhlIHZl cnNpb24gZmllbGQgaW4gdGhlIGN1cnJlbnQgbmVnb3RpYXRpb24gZXh0ZW5zaW9uIGlzIHVzZWxl c3MgKGEgbmV3IGV4dGVuc2lvbiB3aWxsIGJlIG5lZWRlZCBmb3IgbmVnb3RpYXRpbmcgbmV3IHRo aW5ncykuDQoNCkkgdGhpbmsgdGhlIGxpa2VsaWhvb2QgdGhhdCBhIGNoYW5nZSB3aWxsIGJlIGxh cmdlIGVub3VnaCB0byB3YXJyYW50IGEgY2hhbmdlIGluIHByb3RvY29sIHZlcnNpb24gbnVtYmVy LCB5ZXQgc21hbGwgZW5vdWdoIHRoYXQgbmVnb3RpYXRpb24gZG9lc24ndCBjaGFuZ2UsIGlzIGZh aXJseSBzbWFsbC4gVGhhdCwgYW5kIHRoZSBwb3RlbnRpYWwgb3NzaWZpY2F0aW9uIG9mIHRoZSB2 ZXJzaW9uIGZpZWxkIHNlZW0gbGlrZSBnb29kIHJlYXNvbnMgdG8gcmVtb3ZlIHRoZSB2ZXJzaW9u IGZpZWxkIGFuZCB1c2UgYSBuZXcgVExTIGV4dGVuc2lvbiBudW1iZXIgd2hlbiB0aGUgdGltZSBj b21lcy4NCg0KT24gVHVlLCBBdWcgOSwgMjAxNiBhdCA5OjQ5IEFNLCBBbmRyZWkgUG9wb3YgPEFu ZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNv bT4+IHdyb3RlOg0KVGhlIGRyYXdiYWNrcyBvZiBuZWdvdGlhdGluZyBlYWNoIFRCIHZlcnNpb24g d2l0aCBhIGN1c3RvbSBUTFMgZXh0ZW5zaW9uOg0KMS4gTW9yZSBieXRlcyBpbiB0aGUgQ2xpZW50 SGVsbG87DQoyLiBNb3JlIElFVEYgcHJvY2VzcyB3aGVuIGFkZGluZyBuZXcgVEIgdmVyc2lvbnM7 DQozLiBUTFMgdXBkYXRlIGZvciBlYWNoIFRCIHZlcnNpb24sIG9yIHRoZSBuZWVkIHRvIGFkZCAi Z2VuZXJpYyBUTFMgZXh0ZW5zaW9uIiBzdXBwb3J0LCBwdXR0aW5nIHRoZSBjYWxsZXIgb2YgdGhl IFRMUyBzdGFjayBpbiBjaGFyZ2Ugb2YgaGFuZGxpbmcgKGEgc3Vic2V0IG9mKSBUTFMgZXh0ZW5z aW9ucy4NCg0KVGhlIHBvdGVudGlhbCBiZW5lZml0czoNCmEpIEV4dGVuc2liaWxpdHkgaXMgY29u Y2VudHJhdGVkIGluIG9uZSBwbGFjZT8NCmIpIFRoZSBzZXJ2ZXIgaGFzIGEgbGlzdCBvZiBhbGwg Y2xpZW50LXN1cHBvcnRlZCBUQiB2ZXJzaW9ucyBpbiB0aGUgQ2xpZW50SGVsbG8gKHRoaXMgY2Fu IGJlIGFjaGlldmVkIHdpdGhpbiBvbmUgVExTIGV4dGVuc2lvbiwgaWYgZGVzaXJlZCkuDQoNClRv IG1lLCB0aGVzZSBkcmF3YmFja3Mgb3V0d2VpZ2ggdGhlIGJlbmVmaXRzLCBidXQgSSBjb3VsZCBs aXZlIHdpdGggZWl0aGVyIGRlc2lnbi4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcnRpbiBUaG9tc29uIFttYWlsdG86bWFydGluLnRo b21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+XQ0KU2VudDog TW9uZGF5LCBBdWd1c3QgOCwgMjAxNiA3OjM1IFBNDQpUbzogQW5kcmVpIFBvcG92IDxBbmRyZWku UG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+Pg0K Q2M6IE5pY2sgSGFycGVyIDxuaGFycGVyQGdvb2dsZS5jb208bWFpbHRvOm5oYXJwZXJAZ29vZ2xl LmNvbT4+OyBCaWxsIENveCA8d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTxtYWlsdG86d2F5d2FyZGdl ZWtAZ29vZ2xlLmNvbT4+OyB1bmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzp1bmJlYXJhYmxlQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBUTFMgZXh0ZW5zaW9uOiB2ZXJzaW9u IGZpZWxkDQpPbiA5IEF1Z3VzdCAyMDE2IGF0IDEyOjI3LCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Q b3BvdkBtaWNyb3NvZnQuY29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+IHdy b3RlOg0KPiBBbHNvLCB0aGUgcHJvcG9zYWwgcmVxdWlyZXMgdGhhdCBhIFRMUyBzdGFjayBiZSB1 cGRhdGVkIGZvciBldmVyeSBuZXcgVEIgdmVyc2lvbiwgd2hpY2ggaXMgYSByZWFsIGRyYXdiYWNr LiBXaXRoIHRoZSBjdXJyZW50IFRCIG5lZ290aWF0aW9uIGV4dGVuc2lvbiwgd2UgY2FuIGFkZCBu ZXcgVEIgdmVyc2lvbnMgd2l0aG91dCBjaGFuZ2luZyBUTFMuDQoNClRoYXQncyBhIHByb2JsZW0g dGhhdCBjYW4gYmUgc29sdmVkIHdpdGggc29mdHdhcmUsIGlmIHlvdSBjYXJlIGFib3V0IHRoYXQg c29ydCBvZiB0aGluZzoNCiAgdGxzLmFkZEdlbmVyaWNDbGllbnRIZWxsb0V4dGVuc2lvbihpZCwg YmxvYik7DQogIHRscy5hZGRHZW5lcmljU2VydmVySGVsbG9FeHRlbnNpb25IYW5kbGVyKGlkLCAo YmxvYikgPT4gey4uLn0pOw0KICBibG9iID0gdGxzLmdldEdlbmVyaWNTZXJ2ZXJIZWxsb0V4dGVu c2lvbihpZCk7DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0DQpVbmJlYXJhYmxlQGlldGYub3JnPG1haWx0 bzpVbmJlYXJhYmxlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby91bmJlYXJhYmxlDQoNCg== --_000_CY1PR03MB215544A7CB0A9BD068C9AD228CEB0CY1PR03MB2155namp_ 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 IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb20gdGhlIHByYWN0aWNhbCBzdGFuZHBvaW50LCBpZiB3 ZSBnbyB3aXRoIG9uZSBUTFMgZXh0ZW5zaW9uIGZvciBlYWNoIHN1cHBvcnRlZCBUQiB2ZXJzaW9u LCB3aGF0IFRMUyBleHRlbnNpb24gSUQgc2hvdWxkIHdlIHVzZSB0byBpbmRpY2F0ZSBzdXBwb3J0 IGZvciB0aGUgdXBjb21pbmcgMC45IGRyYWZ0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbHNvLCBkb2VzIENo cm9tZSBhbHJlYWR5IHVzZSB0aGUgY3VycmVudCBlYXJseSBJQU5BIGFzc2lnbm1lbnQgKDI0KSB0 byBuZWdvdGlhdGUgVEIgdjAuOD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IEJyaWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDksIDIwMTYgMTE6 NDQgQU08YnI+DQo8Yj5Ubzo8L2I+IE5pY2sgSGFycGVyICZsdDtuaGFycGVyQGdvb2dsZS5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBBbmRyZWkgUG9wb3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3Nv ZnQuY29tJmd0OzsgdW5iZWFyYWJsZUBpZXRmLm9yZzsgTWFydGluIFRob21zb24gJmx0O21hcnRp bi50aG9tc29uQGdtYWlsLmNvbSZndDs7IEJpbGwgQ294ICZsdDt3YXl3YXJkZ2Vla0Bnb29nbGUu Y29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIFRMUyBleHRlbnNp b246IHZlcnNpb24gZmllbGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHRlbmQgdG8gYWdyZWUgd2l0aCBNYXJ0aW4gYW5kIE5pY2sncyBwZXJzcGVjdGl2ZSBoZXJlLiBL ZXkgcGFyYW1ldGVycywgdG9rZW4gYmluZGluZyB0eXBlcywgYW5kIGV4dGVuc2lvbnMgYWxyZWFk eSBwcm92aWRlIGZvciBhIGZhaXIgYW1vdW50IG9mIGV4dGVuc2liaWxpdHkuIE9uZSBjYW4ndCBy ZWxpYWJseSBwcmVkaWN0IHRoZSBmdXR1cmUgYnV0IGl0IHNlZW1zIG1vcmUgbGlrZWx5IHRoYW4g bm90IHRoYXQNCiB0aGUgZmlyc3QgdmVyc2lvbiBvZiBUQiAod2hpY2ggZG9lc24ndCBldmVuIGV4 aXN0IHlldCkgY291bGQgd2VsbCBoYXZlIGEgbmljZSBsb25nIHJ1biBiZWZvcmUgYSBuZXcgdmVy c2lvbiBpcyBuZWVkZWQuIEEgbmV3IGV4dGVuc2lvbiBjYW4gYmUgZG9uZSBpZiBhbmQgd2hlbiB0 aGF0IHRpbWUgY29tZXMgYW5kIHdvcmtpbmcgd2l0aCBleGlzdGluZyBUTFMgZXh0ZW5zaW9ucyBp cyBtdWNoIG1vcmUgbGlrZWx5IHRvIHdvcmsgaW4gcHJhY3RpY2UNCiB0aGFuIGEgdmVyc2lvbiBt ZWNoYW5pc20gd2l0aGluIHRoZSBUQiB0aGF0IHdvbnQgcmVhbGx5IGJlIGV4ZXJjaXNlZCBiZWNh dXNlIHRoZXJlJ3Mgb25seSBvbmUgdmVyc2lvbi4gSW4gbWVhbnRpbWUgdGhlIGNsaWVudCBhbmQg c2VydmVyIGhlbGxvIGNhbiB1c2UgYSBmZXcgbGVzcyBieXRlcyAobm8gdmVyc2lvbikgaW4gdGhl IG9yZGluYXJ5IGNhc2Ugb2YgbmVnb3RpYXRpbmcgdGhlIG9ubHkgdmVyc2lvbiBvZiBUQiB0aGF0 IGV4aXN0cyAoZXIsDQogd2lsbCBleGlzdCBzb29uKS4gPGJyPg0KPGJyPg0KJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEF1ZyA5LCAy MDE2IGF0IDExOjM4IEFNLCBOaWNrIEhhcnBlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5oYXJwZXJA Z29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5oYXJwZXJAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JZiB3ZSBsZWF2ZSBpdCBhcyBpcywgdGhlIHZlcnNpb24gZmllbGQgaXMgbGlrZWx5IHRv IG9zc2lmeSAobGlrZSBpdCBoYXMgd2l0aCBldmVyeSB2ZXJzaW9uIG9mIFNTTCBhbmQgVExTKSwg c28gdGhlcmUncyBhIGRlY2VudCBjaGFuY2UgdGhhdCBmb3Igc29tZSBpbXBsZW1lbnRhdGlvbnMg aXQgd29uJ3Qgd29yayAoYSB2ZXJzaW9uIGludG9sZXJhbnQgc2VydmVyIHdvdWxkIHJlamVjdCBh IGNsaWVudCdzIHYyDQogdG9rZW4gYmluZGluZyBuZWdvdGlhdGlvbiwgaW5zdGVhZCBvZiBmYWxs aW5nIGJhY2sgdG8gdjE7IHNlcGFyYXRlIGV4dGVuc2lvbnMgZG9uJ3QgaGF2ZSB0aGlzIHByb2Js ZW0pLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgdmVy c2lvbiBmaWVsZCBhbHNvIGFzc3VtZXMgdGhhdCB0aGUgb25seSB0aGluZyAoYXBhcnQgZnJvbSB2 ZXJzaW9uIG51bWJlcikgdGhhdCBuZWVkcyB0byBiZSBuZWdvdGlhdGVkIGlzIHRoZSBrZXkgcGFy YW1ldGVycy4gSWYgYSB0b2tlbiBiaW5kaW5nIHYyIGlzIGFkZGVkLCB3aWxsIGl0IHdhbnQgdG8g bmVnb3RpYXRlIHNvbWV0aGluZyBlbHNlIChhbmQgdGhlbiBuZWVkIGEgbmV3IFRMUyBleHRlbnNp b24pPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JJ20gd29uZGVyaW5nIHdoYXQgZnV0dXJlIGNoYW5nZXMgdG8gdG9rZW4gYmluZGluZyBtaWdo dCBsb29rIGxpa2UgdGhhdCByZXF1aXJlIGJ1bXBpbmcgdGhlIHByb3RvY29sIHZlcnNpb24gbnVt YmVyLiBJIGtub3cgdGhhdCBrZXkgYXR0ZXN0YXRpb24gaXMgc29tZXRoaW5nIHRoYXQgY291bGQg cG90ZW50aWFsbHkgYmUgYWRkZWQuIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGlzIHdvdWxk IGdvIGluIGFuDQogRXh0ZW5zaW9uIGluIHRoZSBUb2tlbkJpbmRpbmcgc3RydWN0LCBhbmQgd291 bGRuJ3QgbmVlZCB0byBidW1wIHRoZSBwcm90b2NvbCB2ZXJzaW9uIG51bWJlci4gRm9yIHRoZSBw cm90b2NvbCB2ZXJzaW9uIG51bWJlciB0byBiZSBjaGFuZ2VkLCBzb21ldGhpbmcgd291bGQgaGF2 ZSB0byBjaGFuZ2UgdGhlIFRva2VuQmluZGluZ01lc3NhZ2UgZm9ybWF0IChvciB0aGUgZm9ybWF0 IG9mIG9uZSBvZiBpdHMgZmllbGRzKS4gVGhlcmUncyBhbHJlYWR5DQogYSBkZWNlbnQgYW1vdW50 IG9mIGV4dGVuc2liaWxpdHkgdGhlcmUgaW4gdGVybXMgb2Yga2V5IHBhcmFtZXRlcnMsIHRva2Vu IGJpbmRpbmcgdHlwZXMsIGFuZCBleHRlbnNpb25zLiBDaGFuZ2luZyB0aGUgc2lnbmF0dXJlIHRv IGJlIG9mIHNvbWV0aGluZyBiZXNpZGVzIHRoZSBFS00gdmFsdWUgaXMgdGhlIG9ubHkgdGhpbmcg dGhhdCBjb21lcyB0byBteSBtaW5kIHRoYXQgd291bGQgZml0IGluIHRoaXMgZm9ybWF0IGFuZCBy ZXF1aXJlIGNoYW5naW5nDQogdGhlIHZlcnNpb24gbnVtYmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBtb3JlIHN1YnN0YW50aWFsIGNo YW5nZXMgYXJlIG1hZGUgdG8gdGhlIFRva2VuQmluZGluZ01lc3NhZ2UsIEkgaW1hZ2luZSB0aGF0 IGNoYW5nZXMgd2lsbCBuZWVkIHRvIGJlIG1hZGUgdG8gbmVnb3RpYXRpb24gdG8gc3VwcG9ydCB0 aG9zZSBjaGFuZ2VzLiBJbiB0aGF0IGNhc2UsIHRoZSB2ZXJzaW9uIGZpZWxkIGluIHRoZSBjdXJy ZW50IG5lZ290aWF0aW9uIGV4dGVuc2lvbiBpcyB1c2VsZXNzIChhIG5ldw0KIGV4dGVuc2lvbiB3 aWxsIGJlIG5lZWRlZCBmb3IgbmVnb3RpYXRpbmcgbmV3IHRoaW5ncykuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlIGxpa2Vs aWhvb2QgdGhhdCBhIGNoYW5nZSB3aWxsIGJlIGxhcmdlIGVub3VnaCB0byB3YXJyYW50IGEgY2hh bmdlIGluIHByb3RvY29sIHZlcnNpb24gbnVtYmVyLCB5ZXQgc21hbGwgZW5vdWdoIHRoYXQgbmVn b3RpYXRpb24gZG9lc24ndCBjaGFuZ2UsIGlzIGZhaXJseSBzbWFsbC4gVGhhdCwgYW5kIHRoZSBw b3RlbnRpYWwgb3NzaWZpY2F0aW9uIG9mIHRoZSB2ZXJzaW9uIGZpZWxkIHNlZW0NCiBsaWtlIGdv b2QgcmVhc29ucyB0byByZW1vdmUgdGhlIHZlcnNpb24gZmllbGQgYW5kIHVzZSBhIG5ldyBUTFMg ZXh0ZW5zaW9uIG51bWJlciB3aGVuIHRoZSB0aW1lIGNvbWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwg QXVnIDksIDIwMTYgYXQgOTo0OSBBTSwgQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86 QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZA bWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhlIGRy YXdiYWNrcyBvZiBuZWdvdGlhdGluZyBlYWNoIFRCIHZlcnNpb24gd2l0aCBhIGN1c3RvbSBUTFMg ZXh0ZW5zaW9uOjxicj4NCjEuIE1vcmUgYnl0ZXMgaW4gdGhlIENsaWVudEhlbGxvOzxicj4NCjIu IE1vcmUgSUVURiBwcm9jZXNzIHdoZW4gYWRkaW5nIG5ldyBUQiB2ZXJzaW9uczs8YnI+DQozLiBU TFMgdXBkYXRlIGZvciBlYWNoIFRCIHZlcnNpb24sIG9yIHRoZSBuZWVkIHRvIGFkZCAmcXVvdDtn ZW5lcmljIFRMUyBleHRlbnNpb24mcXVvdDsgc3VwcG9ydCwgcHV0dGluZyB0aGUgY2FsbGVyIG9m IHRoZSBUTFMgc3RhY2sgaW4gY2hhcmdlIG9mIGhhbmRsaW5nIChhIHN1YnNldCBvZikgVExTIGV4 dGVuc2lvbnMuPGJyPg0KPGJyPg0KVGhlIHBvdGVudGlhbCBiZW5lZml0czo8YnI+DQphKSBFeHRl bnNpYmlsaXR5IGlzIGNvbmNlbnRyYXRlZCBpbiBvbmUgcGxhY2U/PGJyPg0KYikgVGhlIHNlcnZl ciBoYXMgYSBsaXN0IG9mIGFsbCBjbGllbnQtc3VwcG9ydGVkIFRCIHZlcnNpb25zIGluIHRoZSBD bGllbnRIZWxsbyAodGhpcyBjYW4gYmUgYWNoaWV2ZWQgd2l0aGluIG9uZSBUTFMgZXh0ZW5zaW9u LCBpZiBkZXNpcmVkKS48YnI+DQo8YnI+DQpUbyBtZSwgdGhlc2UgZHJhd2JhY2tzIG91dHdlaWdo IHRoZSBiZW5lZml0cywgYnV0IEkgY291bGQgbGl2ZSB3aXRoIGVpdGhlciBkZXNpZ24uPGJyPg0K PGJyPg0KQ2hlZXJzLDxicj4NCjxicj4NCkFuZHJlaTxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzo8YSBocmVmPSJt YWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLnRo b21zb25AZ21haWwuY29tPC9hPl08YnI+DQpTZW50OiBNb25kYXksIEF1Z3VzdCA4LCAyMDE2IDc6 MzUgUE08YnI+DQpUbzogQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBv cG92QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0 LmNvbTwvYT4mZ3Q7PGJyPg0KQ2M6IE5pY2sgSGFycGVyICZsdDs8YSBocmVmPSJtYWlsdG86bmhh cnBlckBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bmhhcnBlckBnb29nbGUuY29tPC9hPiZn dDs7IEJpbGwgQ294ICZsdDs8YSBocmVmPSJtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPndheXdhcmRnZWVrQGdvb2dsZS5jb208L2E+Jmd0OzsNCjxhIGhyZWY9 Im1haWx0bzp1bmJlYXJhYmxlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dW5iZWFyYWJsZUBp ZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFRMUyBleHRlbnNpb246 IHZlcnNpb24gZmllbGQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gOSBBdWd1c3QgMjAxNiBhdCAxMjoyNywgQW5kcmVpIFBvcG92ICZsdDs8YSBo cmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5B bmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgQWxzbywg dGhlIHByb3Bvc2FsIHJlcXVpcmVzIHRoYXQgYSBUTFMgc3RhY2sgYmUgdXBkYXRlZCBmb3IgZXZl cnkgbmV3IFRCIHZlcnNpb24sIHdoaWNoIGlzIGEgcmVhbCBkcmF3YmFjay4gV2l0aCB0aGUgY3Vy cmVudCBUQiBuZWdvdGlhdGlvbiBleHRlbnNpb24sIHdlIGNhbiBhZGQgbmV3IFRCIHZlcnNpb25z IHdpdGhvdXQgY2hhbmdpbmcgVExTLjxicj4NCjxicj4NClRoYXQncyBhIHByb2JsZW0gdGhhdCBj YW4gYmUgc29sdmVkIHdpdGggc29mdHdhcmUsIGlmIHlvdSBjYXJlIGFib3V0IHRoYXQgc29ydCBv ZiB0aGluZzo8YnI+DQombmJzcDsgdGxzLmFkZEdlbmVyaWNDbGllbnRIZWxsb0V4dGVuc2lvbihp ZCwgYmxvYik7PGJyPg0KJm5ic3A7IHRscy5hZGRHZW5lcmljU2VydmVySGVsbG9FeHRlbnNpb25I YW5kbGVyKGlkLCAoYmxvYikgPSZndDsgey4uLn0pOzxicj4NCiZuYnNwOyBibG9iID0gdGxzLmdl dEdlbmVyaWNTZXJ2ZXJIZWxsb0V4dGVuc2lvbihpZCk7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpVbmJlYXJhYmxlIG1haWxpbmcg bGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnIj5VbmJlYXJhYmxl QGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdW5iZWFyYWJsZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR03MB215544A7CB0A9BD068C9AD228CEB0CY1PR03MB2155namp_-- From nobody Tue Aug 23 10:52: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 0EE7112D1A6 for ; Tue, 23 Aug 2016 10:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 H3IK9QOlDafu for ; Tue, 23 Aug 2016 10:52:34 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 2E52212D115 for ; Tue, 23 Aug 2016 10:52:34 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id k90so257948097uak.1 for ; Tue, 23 Aug 2016 10:52:34 -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=4jkDfXMQhuNkruWHi5d6Mf7H07lCm2lXmELVcdN6Jgw=; b=j62zPgogVaZGwblTrcjqDjIrOiYBXFQdvywwJKa7MYV5XIuWYN3Pbugxvm9yhi/AGA wP48RpYFYoPogsFdgad8o3Poetncmi6eysL1WplGjzd6GdEubAKFgat/SN0hFFEfgFtW lSzfAWvFEtSK6vfLScipsy6LwTgLIghGcmVXiEJEniaCytgdTW71o/3GYr7gyMCVMRPw B2n+QPu3K2VGU4VZ74rZHL7RI0/6WXlrQSXXsLiXoGXxDrXtb/HqA7ERiAYWWTWx5K9Y vGI0KN/MpeXfYk1Sfiz6sIqzm2YYwdj3AiQpbaOpWUNqaalZ/Rws6GnNLFxz5PYHviMI aUaw== 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=4jkDfXMQhuNkruWHi5d6Mf7H07lCm2lXmELVcdN6Jgw=; b=Fw/n6CE7xwMNqnH9YENKVHj270ukJYOayVWwYIUZOCvSbykxAp8wxg2aMQ2X2HJmiS aAsTCgSOCx1pSUYy0fhtyDEh9k/u8ngNqPmhOzPKNIjPkYP4BzE7EP9mg3+jGzON08au kwwqU6VzSR5PU3MJOkyHlINkY2DrggX/c5nXwrmPad7PetmRaUWVEjSh1Fo7u41whGjn sZuMykz1IE6ga8t3Ft+2OJGcXA7pBzU/VEgI/9BeWjC3+Wl6rx1ldPu9sJxFrtrE4g96 Pozpobm5Mv98ptjYuNIWDDvoMxuL44kYU/I9jj6vjJ0dptYhefufQpMQ4xrosux27H0s heCg== X-Gm-Message-State: AEkoouuk13UViVLz8tTxqRGbGcvhVAnbsQhZ21SA6/t++B52fgjJnUB2CbZM1spElB7R9kaAeIW8mbJqA6jkhZIb X-Received: by 10.31.107.89 with SMTP id g86mr12567735vkc.52.1471974752982; Tue, 23 Aug 2016 10:52:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.209 with HTTP; Tue, 23 Aug 2016 10:52:12 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Tue, 23 Aug 2016 10:52:12 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a11478678456bb8053ac0d4ed Archived-At: Cc: "unbearable@ietf.org" , Brian Campbell , Martin Thomson , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 23 Aug 2016 17:52:37 -0000 --001a11478678456bb8053ac0d4ed Content-Type: text/plain; charset=UTF-8 Chrome is currently using the IANA assignment (24). For draft 0.9, we could use an experimental TLS extension number, or we could use 24 for TB, and send an additional extension to indicate the draft version (like how TLS 1.3 is doing with 0xff02). On Tue, Aug 23, 2016 at 9:59 AM, Andrei Popov wrote: > From the practical standpoint, if we go with one TLS extension for each > supported TB version, what TLS extension ID should we use to indicate > support for the upcoming 0.9 draft? > > > > Also, does Chrome already use the current early IANA assignment (24) to > negotiate TB v0.8? > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Tuesday, August 9, 2016 11:44 AM > *To:* Nick Harper > *Cc:* Andrei Popov ; unbearable@ietf.org; > Martin Thomson ; Bill Cox < > waywardgeek@google.com> > > *Subject:* Re: [Unbearable] TLS extension: version field > > > > I tend to agree with Martin and Nick's perspective here. Key parameters, > token binding types, and extensions already provide for a fair amount of > extensibility. One can't reliably predict the future but it seems more > likely than not that the first version of TB (which doesn't even exist yet) > could well have a nice long run before a new version is needed. A new > extension can be done if and when that time comes and working with existing > TLS extensions is much more likely to work in practice than a version > mechanism within the TB that wont really be exercised because there's only > one version. In meantime the client and server hello can use a few less > bytes (no version) in the ordinary case of negotiating the only version of > TB that exists (er, will exist soon). > > > > > > On Tue, Aug 9, 2016 at 11:38 AM, Nick Harper wrote: > > If we leave it as is, the version field is likely to ossify (like it has > with every version of SSL and TLS), so there's a decent chance that for > some implementations it won't work (a version intolerant server would > reject a client's v2 token binding negotiation, instead of falling back to > v1; separate extensions don't have this problem). > > This version field also assumes that the only thing (apart from version > number) that needs to be negotiated is the key parameters. If a token > binding v2 is added, will it want to negotiate something else (and then > need a new TLS extension)? > > > > I'm wondering what future changes to token binding might look like that > require bumping the protocol version number. I know that key attestation is > something that could potentially be added. My understanding is that this > would go in an Extension in the TokenBinding struct, and wouldn't need to > bump the protocol version number. For the protocol version number to be > changed, something would have to change the TokenBindingMessage format (or > the format of one of its fields). There's already a decent amount of > extensibility there in terms of key parameters, token binding types, and > extensions. Changing the signature to be of something besides the EKM value > is the only thing that comes to my mind that would fit in this format and > require changing the version number. > > > > If more substantial changes are made to the TokenBindingMessage, I imagine > that changes will need to be made to negotiation to support those changes. > In that case, the version field in the current negotiation extension is > useless (a new extension will be needed for negotiating new things). > > > > I think the likelihood that a change will be large enough to warrant a > change in protocol version number, yet small enough that negotiation > doesn't change, is fairly small. That, and the potential ossification of > the version field seem like good reasons to remove the version field and > use a new TLS extension number when the time comes. > > > > On Tue, Aug 9, 2016 at 9:49 AM, Andrei Popov > wrote: > > The drawbacks of negotiating each TB version with a custom TLS extension: > 1. More bytes in the ClientHello; > 2. More IETF process when adding new TB versions; > 3. TLS update for each TB version, or the need to add "generic TLS > extension" support, putting the caller of the TLS stack in charge of > handling (a subset of) TLS extensions. > > The potential benefits: > a) Extensibility is concentrated in one place? > b) The server has a list of all client-supported TB versions in the > ClientHello (this can be achieved within one TLS extension, if desired). > > To me, these drawbacks outweigh the benefits, but I could live with either > design. > > Cheers, > > Andrei > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Monday, August 8, 2016 7:35 PM > To: Andrei Popov > Cc: Nick Harper ; Bill Cox ; > unbearable@ietf.org > Subject: Re: [Unbearable] TLS extension: version field > > On 9 August 2016 at 12:27, Andrei Popov > wrote: > > Also, the proposal requires that a TLS stack be updated for every new TB > version, which is a real drawback. With the current TB negotiation > extension, we can add new TB versions without changing TLS. > > That's a problem that can be solved with software, if you care about that > sort of thing: > tls.addGenericClientHelloExtension(id, blob); > tls.addGenericServerHelloExtensionHandler(id, (blob) => {...}); > blob = tls.getGenericServerHelloExtension(id); > > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > > --001a11478678456bb8053ac0d4ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Chrome is currently using the IANA assignment (24).
For draft 0.9, we could use an experimental TLS extension numb= er, or we could use 24 for TB, and send an additional extension to indicate= the draft version (like how TLS 1.3 is doing with 0xff02).

On Tue, Aug 23, 2016 = at 9:59 AM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

From the practical standpoint, if we go with one TL= S extension for each supported TB version, what TLS extension ID should we = use to indicate support for the upcoming 0.9 draft?

=C2=A0

Also, does Chrome already use the current early IAN= A assignment (24) to negotiate TB v0.8?

=C2=A0

From: Brian Campbell [mailto:bcampbell@pin= gidentity.com]
Sent: Tuesday, August 9, 2016 11:44 AM
To: Nick Harper <nharper@google.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; unbearable@ietf.org; Martin Thomson = <martin.th= omson@gmail.com>; Bill Cox <waywardgeek@google.com>


Subject: Re: [Unbearable] TLS extension: version field=

=C2=A0

I tend to agree with Martin and Nick's perspecti= ve here. Key parameters, token binding types, and extensions already provid= e for a fair amount of extensibility. One can't reliably predict the fu= ture but it seems more likely than not that the first version of TB (which doesn't even exist yet) could well have= a nice long run before a new version is needed. A new extension can be don= e if and when that time comes and working with existing TLS extensions is m= uch more likely to work in practice than a version mechanism within the TB that wont really be exercised becau= se there's only one version. In meantime the client and server hello ca= n use a few less bytes (no version) in the ordinary case of negotiating the= only version of TB that exists (er, will exist soon).

=C2=A0

=C2=A0

On Tue, Aug 9, 2016 at 11:38 AM, Nick Harper <nharper@google.com= > wrote:

If we leave it as is, the version field is likely to= ossify (like it has with every version of SSL and TLS), so there's a d= ecent chance that for some implementations it won't work (a version int= olerant server would reject a client's v2 token binding negotiation, instead of falling back to v1; separate extensi= ons don't have this problem).

This version field also assumes that the only thing = (apart from version number) that needs to be negotiated is the key paramete= rs. If a token binding v2 is added, will it want to negotiate something els= e (and then need a new TLS extension)?

=C2=A0

I'm wondering what future changes to token bindi= ng might look like that require bumping the protocol version number. I know= that key attestation is something that could potentially be added. My unde= rstanding is that this would go in an Extension in the TokenBinding struct, and wouldn't need to bump the pr= otocol version number. For the protocol version number to be changed, somet= hing would have to change the TokenBindingMessage format (or the format of = one of its fields). There's already a decent amount of extensibility there in terms of key parameters, token b= inding types, and extensions. Changing the signature to be of something bes= ides the EKM value is the only thing that comes to my mind that would fit i= n this format and require changing the version number.

=C2=A0

If more substantial changes are made to the TokenBin= dingMessage, I imagine that changes will need to be made to negotiation to = support those changes. In that case, the version field in the current negot= iation extension is useless (a new extension will be needed for negotiating new things).

=C2=A0

I think the likelihood that a change will be large e= nough to warrant a change in protocol version number, yet small enough that= negotiation doesn't change, is fairly small. That, and the potential o= ssification of the version field seem like good reasons to remove the version field and use a new TLS extension = number when the time comes.

=C2=A0

On Tue, Aug 9, 2016 at 9:49 AM, Andrei Popov <Andrei.Popov@m= icrosoft.com> wrote:

The drawbacks of nego= tiating each TB version with a custom TLS extension:
1. More bytes in the ClientHello;
2. More IETF process when adding new TB versions;
3. TLS update for each TB version, or the need to add "generic TLS ext= ension" support, putting the caller of the TLS stack in charge of hand= ling (a subset of) TLS extensions.

The potential benefits:
a) Extensibility is concentrated in one place?
b) The server has a list of all client-supported TB versions in the ClientH= ello (this can be achieved within one TLS extension, if desired).

To me, these drawbacks outweigh the benefits, but I could live with either = design.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com]
Sent: Monday, August 8, 2016 7:35 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Nick Harper <nharper@google.com>; Bill Cox <waywardgeek@google.com>; unbearable@ietf.or= g
Subject: Re: [Unbearable] TLS extension: version field

On 9 August 2016 at 12:27, Andrei Popov <Andrei.Popov@micro= soft.com> wrote:
> Also, the proposal requires that a TLS stack be updated for every new = TB version, which is a real drawback. With the current TB negotiation exten= sion, we can add new TB versions without changing TLS.

That's a problem that can be solved with software, if you care about th= at sort of thing:
=C2=A0 tls.addGenericClientHelloExtension(id, blob);
=C2=A0 tls.addGenericServerHelloExtensionHandler(id, (blob) =3D&g= t; {...});
=C2=A0 blob =3D tls.getGenericServerHelloExtension(id);=

=C2=A0


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

=C2=A0


--001a11478678456bb8053ac0d4ed-- From nobody Tue Aug 23 11:24: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 2C6C612B016 for ; Fri, 19 Aug 2016 16:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 PiDqznQoWvZY for ; Fri, 19 Aug 2016 16:44:05 -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 8C7B412D0E3 for ; Fri, 19 Aug 2016 16:44:05 -0700 (PDT) Date: Fri, 19 Aug 2016 16:44:04 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471650244; bh=OIsSpUOKmEFB6bdgWhTXSF+iIj7Xw593S+DcQmaNyfs=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=w9SR1Jd6ONUQDUSW5gcV5yOrmjnKAwUkI75HT6nj++CXs0i8QrLrbLX6qYJGTlSnz 2ah4z6vMY6dS6zjueO5+lKm5tuRHbLPCMtBoaqrye4/fbtVjtHFgx2Hh7oAnVTBONn e8VO9hBOxqwdklJUizj33OEue2CY8ODL2aH/Icaw= From: =JeffH To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57b799c4a73b8_452c3fa654d8329c564619"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: equalsJeffH X-GitHub-Recipient: unbearable-ML X-GitHub-Reason: push X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Tue, 23 Aug 2016 11:24:27 -0700 Cc: Push Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] TBPROTO-09: address implementation/api guidance (#54) 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, 19 Aug 2016 23:44:07 -0000 ----==_mimepart_57b799c4a73b8_452c3fa654d8329c564619 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit @equalsJeffH pushed 3 commits. dc49fce fixed xref tag closure b24896a polish api guidance prose. fixes #53 c919c7b further polishing -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/TokenBinding/Internet-Drafts/pull/54/files/fb333e90a8f38d536472972d376202955ae90ce7..c919c7bfa5158d5d932f291c199c7d0d43bb8ed8 ----==_mimepart_57b799c4a73b8_452c3fa654d8329c564619 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

@equalsJeffH pushed 3 commits.

—
You are receiving this because you are subscribed to this thread.
View it on GitHub or mute the thread.

----==_mimepart_57b799c4a73b8_452c3fa654d8329c564619-- From nobody Tue Aug 23 11:24:35 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 3F1DC12D696 for ; Tue, 23 Aug 2016 11:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 R7H46gj1CXYa for ; Tue, 23 Aug 2016 11:24:25 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0113.outbound.protection.outlook.com [104.47.32.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55BCA12D674 for ; Tue, 23 Aug 2016 11:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N/mVq7wNGUdQiK7dZrTTyK45EnCpUF+rQFC8Vx7vqEE=; b=LIPgnxqO9z66kEfB4UgQmJLA31oYGxcg9TvyzuGic+9enu2uSwdUOYyLVZOSm/HzgzIJUqA4f2BLYEPFSm+CLxs/Dl3dhS7ChrLeoAkda+gYr0+sBYU2WxgJefUKe+O+NAEdHZtGoGIJVxg9kjwa7gnHFye9zvsKqYqQSigC0Ts= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2156.namprd03.prod.outlook.com (10.166.206.141) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Tue, 23 Aug 2016 18:24:22 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0587.013; Tue, 23 Aug 2016 18:24:22 +0000 From: Andrei Popov To: Nick Harper Thread-Topic: [Unbearable] TLS extension: version field Thread-Index: AQHR8UE0hAr3fGh5LkSos3djbwbcUaA/MmwAgAAmOoCAAAGk8IAAhvMAgAAFqjCAAAO6AIAA6WmAgAATAoCAABJZgIAV3xfwgAATKACAAASwAA== Date: Tue, 23 Aug 2016 18:24:22 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: 73599aa9-d713-4079-3ce4-08d3cb82b4b3 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2156; 6:0WtdXB0Hpkkjt52ll+/NJZsgqG+ChmjiFM09BjW0lKajIiauhD33ODuODC5+jyoPHtQJKU7LSd0nXT7dAADLn3Gh6pUO0PVkPkmifxuFtsnxUv/dD8gTYpNjGqG2sDbo9hxXA0/nPhHl300AtMdPPAV5Q3MQM3teiNHk2b0ZfZ8L9DQYyVabQrUnH0gK0jgKHzwqNrHPshcYIYITzxaCfkIft2Xb7X75x8s6fQeL78pNzmOUBVsmQTmUNqbAxnvgilMI+LIqSYLfm2ZPvkKK3+IvSLI8Y2qAEAHO23OU8iX+l63YP4bGn/jTDu8rcJlM+zJotds+OE+N5qBtHNKcLA==; 5:l/yoA0gQMRhUsk/UqEzXMqqQxXRxm6olJEHmx0oU8IN4VxjxaRTXOPyypKFvaZVp4znysm6hq+B8LCMT0Njydq2ZLiiNDJ3uXKc52f+WNEQNDMQjTQpK4ZeLZQHxME98DhFxmUOz07Z1Jm/iSzqH3w==; 24:3HehjhO1DEAaLzc4Ryc+fvncgKzuN9HwuaUZXrg3j7ir6jEMV9mgJpvK+nnwrY2zybaXz2MZgqMTWKXV0ehuRZXaKyDzlCpAm+XONjhhQyM=; 7:b7UwpThTTuN3HlfaukTWnHqAoQHKRi1exOp97h8V1NL9YC/8gXksDkXDDERrRWVkAZ3M3+F8PLBjKHgD3za6UK+ifchLjQ5rCA/7kMdLxlHmscbRw5t2yrzD+xNBdMBPvXXSRcnkuGnh584ZUkn1cNyUtt5N7cMy2mjUvf9HfNrxAl1iw3nQoNda8UKh7Jt9tuaF65H+AKxt3Cx6khJ5YHiPY88Wf0ubvW+2BtbMvhpd7aLuFb3syoAzebyi8pW0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2156; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2156; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2156; x-forefront-prvs: 004395A01C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(189002)(24454002)(13464003)(3660700001)(19625215002)(5660300001)(9686002)(87936001)(50986999)(54356999)(15975445007)(76176999)(4326007)(5002640100001)(10090500001)(33656002)(19617315012)(101416001)(77096005)(561944003)(10290500002)(189998001)(110136002)(19580395003)(2950100001)(86612001)(790700001)(102836003)(6116002)(7906003)(86362001)(586003)(2906002)(19580405001)(7696003)(74316002)(8990500004)(10400500002)(2900100001)(5005710100001)(7846002)(97736004)(19300405004)(7736002)(3280700002)(19609705001)(93886004)(92566002)(68736007)(76576001)(106356001)(122556002)(106116001)(105586002)(8676002)(11100500001)(8936002)(81166006)(16236675004)(99286002)(81156014)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2156; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB215532C510C58E4B638FF7FC8CEB0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2016 18:24:22.4832 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2156 Archived-At: Cc: "unbearable@ietf.org" , Brian Campbell , Martin Thomson , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 23 Aug 2016 18:24:28 -0000 --_000_CY1PR03MB215532C510C58E4B638FF7FC8CEB0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U28gdGhlIHByb3Bvc2FsIGlzIHRvIGtlZXAgdXNpbmcgVExTIGV4dGVuc2lvbiAyNCwgYW5kIHJl bW92ZSB0b2tlbl9iaW5kaW5nX3ZlcnNpb24gZmllbGQ/DQpEcmFmdCBpbXBsZW1lbnRhdGlvbnMg d2lsbCBhZGRpdGlvbmFsbHkgc3VwcGx5IGFub3RoZXIsIHByaXZhdGUgVExTIGV4dGVuc2lvbiBU QkQsIHRoYXQgd2lsbCBjb250YWluIHRoZSB0b2tlbl9iaW5kaW5nX3ZlcnNpb24gZmllbGQ/DQpG dXR1cmUgVEIgdmVyc2lvbnMgd2lsbCByZXF1aXJlIG5ldyBUTFMgZXh0ZW5zaW9ucywgaW4gYWRk aXRpb24gdG8gdGhlIGN1cnJlbnRseSBkZWZpbmVkIDI0Pw0KDQpJIGRvbuKAmXQgcmVhbGx5IGxp a2UgdGhpcywgYnV0IHRyeWluZyB0byB1bmRlcnN0YW5kIHRoZSBzdWdnZXN0ZWQgY2hhbmdlIGlu IGNhc2UgSeKAmW0gaW4gdGhlIHJvdWdoIGFuZCB0aGUgV0cgZGVjaWRlcyB0byBnbyB0aGlzIHdh eS4NCg0KRnJvbTogTmljayBIYXJwZXIgW21haWx0bzpuaGFycGVyQGdvb2dsZS5jb21dDQpTZW50 OiBUdWVzZGF5LCBBdWd1c3QgMjMsIDIwMTYgMTA6NTIgQU0NClRvOiBBbmRyZWkgUG9wb3YgPEFu ZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPg0KQ2M6IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhv bXNvbkBnbWFpbC5jb20+OyBCaWxsIENveCA8d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbT47IEJyaWFu IENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT47IHVuYmVhcmFibGVAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gVExTIGV4dGVuc2lvbjogdmVyc2lvbiBmaWVs ZA0KDQpDaHJvbWUgaXMgY3VycmVudGx5IHVzaW5nIHRoZSBJQU5BIGFzc2lnbm1lbnQgKDI0KS4N Cg0KRm9yIGRyYWZ0IDAuOSwgd2UgY291bGQgdXNlIGFuIGV4cGVyaW1lbnRhbCBUTFMgZXh0ZW5z aW9uIG51bWJlciwgb3Igd2UgY291bGQgdXNlIDI0IGZvciBUQiwgYW5kIHNlbmQgYW4gYWRkaXRp b25hbCBleHRlbnNpb24gdG8gaW5kaWNhdGUgdGhlIGRyYWZ0IHZlcnNpb24gKGxpa2UgaG93IFRM UyAxLjMgaXMgZG9pbmcgd2l0aCAweGZmMDIpLg0KDQpPbiBUdWUsIEF1ZyAyMywgMjAxNiBhdCA5 OjU5IEFNLCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPG1haWx0bzpB bmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KRnJvbSB0aGUgcHJhY3RpY2FsIHN0 YW5kcG9pbnQsIGlmIHdlIGdvIHdpdGggb25lIFRMUyBleHRlbnNpb24gZm9yIGVhY2ggc3VwcG9y dGVkIFRCIHZlcnNpb24sIHdoYXQgVExTIGV4dGVuc2lvbiBJRCBzaG91bGQgd2UgdXNlIHRvIGlu ZGljYXRlIHN1cHBvcnQgZm9yIHRoZSB1cGNvbWluZyAwLjkgZHJhZnQ/DQoNCkFsc28sIGRvZXMg Q2hyb21lIGFscmVhZHkgdXNlIHRoZSBjdXJyZW50IGVhcmx5IElBTkEgYXNzaWdubWVudCAoMjQp IHRvIG5lZ290aWF0ZSBUQiB2MC44Pw0KDQpGcm9tOiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOmJj YW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bT5dDQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgOSwgMjAxNiAxMTo0NCBBTQ0KVG86IE5pY2sgSGFy cGVyIDxuaGFycGVyQGdvb2dsZS5jb208bWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbT4+DQpDYzog QW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBv cG92QG1pY3Jvc29mdC5jb20+PjsgdW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86dW5iZWFyYWJs ZUBpZXRmLm9yZz47IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFp bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+OyBCaWxsIENveCA8d2F5d2FyZGdlZWtAZ29v Z2xlLmNvbTxtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbT4+DQoNClN1YmplY3Q6IFJlOiBb VW5iZWFyYWJsZV0gVExTIGV4dGVuc2lvbjogdmVyc2lvbiBmaWVsZA0KDQpJIHRlbmQgdG8gYWdy ZWUgd2l0aCBNYXJ0aW4gYW5kIE5pY2sncyBwZXJzcGVjdGl2ZSBoZXJlLiBLZXkgcGFyYW1ldGVy cywgdG9rZW4gYmluZGluZyB0eXBlcywgYW5kIGV4dGVuc2lvbnMgYWxyZWFkeSBwcm92aWRlIGZv ciBhIGZhaXIgYW1vdW50IG9mIGV4dGVuc2liaWxpdHkuIE9uZSBjYW4ndCByZWxpYWJseSBwcmVk aWN0IHRoZSBmdXR1cmUgYnV0IGl0IHNlZW1zIG1vcmUgbGlrZWx5IHRoYW4gbm90IHRoYXQgdGhl IGZpcnN0IHZlcnNpb24gb2YgVEIgKHdoaWNoIGRvZXNuJ3QgZXZlbiBleGlzdCB5ZXQpIGNvdWxk IHdlbGwgaGF2ZSBhIG5pY2UgbG9uZyBydW4gYmVmb3JlIGEgbmV3IHZlcnNpb24gaXMgbmVlZGVk LiBBIG5ldyBleHRlbnNpb24gY2FuIGJlIGRvbmUgaWYgYW5kIHdoZW4gdGhhdCB0aW1lIGNvbWVz IGFuZCB3b3JraW5nIHdpdGggZXhpc3RpbmcgVExTIGV4dGVuc2lvbnMgaXMgbXVjaCBtb3JlIGxp a2VseSB0byB3b3JrIGluIHByYWN0aWNlIHRoYW4gYSB2ZXJzaW9uIG1lY2hhbmlzbSB3aXRoaW4g dGhlIFRCIHRoYXQgd29udCByZWFsbHkgYmUgZXhlcmNpc2VkIGJlY2F1c2UgdGhlcmUncyBvbmx5 IG9uZSB2ZXJzaW9uLiBJbiBtZWFudGltZSB0aGUgY2xpZW50IGFuZCBzZXJ2ZXIgaGVsbG8gY2Fu IHVzZSBhIGZldyBsZXNzIGJ5dGVzIChubyB2ZXJzaW9uKSBpbiB0aGUgb3JkaW5hcnkgY2FzZSBv ZiBuZWdvdGlhdGluZyB0aGUgb25seSB2ZXJzaW9uIG9mIFRCIHRoYXQgZXhpc3RzIChlciwgd2ls bCBleGlzdCBzb29uKS4NCg0KDQoNCk9uIFR1ZSwgQXVnIDksIDIwMTYgYXQgMTE6MzggQU0sIE5p Y2sgSGFycGVyIDxuaGFycGVyQGdvb2dsZS5jb208bWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbT4+ IHdyb3RlOg0KSWYgd2UgbGVhdmUgaXQgYXMgaXMsIHRoZSB2ZXJzaW9uIGZpZWxkIGlzIGxpa2Vs eSB0byBvc3NpZnkgKGxpa2UgaXQgaGFzIHdpdGggZXZlcnkgdmVyc2lvbiBvZiBTU0wgYW5kIFRM UyksIHNvIHRoZXJlJ3MgYSBkZWNlbnQgY2hhbmNlIHRoYXQgZm9yIHNvbWUgaW1wbGVtZW50YXRp b25zIGl0IHdvbid0IHdvcmsgKGEgdmVyc2lvbiBpbnRvbGVyYW50IHNlcnZlciB3b3VsZCByZWpl Y3QgYSBjbGllbnQncyB2MiB0b2tlbiBiaW5kaW5nIG5lZ290aWF0aW9uLCBpbnN0ZWFkIG9mIGZh bGxpbmcgYmFjayB0byB2MTsgc2VwYXJhdGUgZXh0ZW5zaW9ucyBkb24ndCBoYXZlIHRoaXMgcHJv YmxlbSkuDQpUaGlzIHZlcnNpb24gZmllbGQgYWxzbyBhc3N1bWVzIHRoYXQgdGhlIG9ubHkgdGhp bmcgKGFwYXJ0IGZyb20gdmVyc2lvbiBudW1iZXIpIHRoYXQgbmVlZHMgdG8gYmUgbmVnb3RpYXRl ZCBpcyB0aGUga2V5IHBhcmFtZXRlcnMuIElmIGEgdG9rZW4gYmluZGluZyB2MiBpcyBhZGRlZCwg d2lsbCBpdCB3YW50IHRvIG5lZ290aWF0ZSBzb21ldGhpbmcgZWxzZSAoYW5kIHRoZW4gbmVlZCBh IG5ldyBUTFMgZXh0ZW5zaW9uKT8NCg0KSSdtIHdvbmRlcmluZyB3aGF0IGZ1dHVyZSBjaGFuZ2Vz IHRvIHRva2VuIGJpbmRpbmcgbWlnaHQgbG9vayBsaWtlIHRoYXQgcmVxdWlyZSBidW1waW5nIHRo ZSBwcm90b2NvbCB2ZXJzaW9uIG51bWJlci4gSSBrbm93IHRoYXQga2V5IGF0dGVzdGF0aW9uIGlz IHNvbWV0aGluZyB0aGF0IGNvdWxkIHBvdGVudGlhbGx5IGJlIGFkZGVkLiBNeSB1bmRlcnN0YW5k aW5nIGlzIHRoYXQgdGhpcyB3b3VsZCBnbyBpbiBhbiBFeHRlbnNpb24gaW4gdGhlIFRva2VuQmlu ZGluZyBzdHJ1Y3QsIGFuZCB3b3VsZG4ndCBuZWVkIHRvIGJ1bXAgdGhlIHByb3RvY29sIHZlcnNp b24gbnVtYmVyLiBGb3IgdGhlIHByb3RvY29sIHZlcnNpb24gbnVtYmVyIHRvIGJlIGNoYW5nZWQs IHNvbWV0aGluZyB3b3VsZCBoYXZlIHRvIGNoYW5nZSB0aGUgVG9rZW5CaW5kaW5nTWVzc2FnZSBm b3JtYXQgKG9yIHRoZSBmb3JtYXQgb2Ygb25lIG9mIGl0cyBmaWVsZHMpLiBUaGVyZSdzIGFscmVh ZHkgYSBkZWNlbnQgYW1vdW50IG9mIGV4dGVuc2liaWxpdHkgdGhlcmUgaW4gdGVybXMgb2Yga2V5 IHBhcmFtZXRlcnMsIHRva2VuIGJpbmRpbmcgdHlwZXMsIGFuZCBleHRlbnNpb25zLiBDaGFuZ2lu ZyB0aGUgc2lnbmF0dXJlIHRvIGJlIG9mIHNvbWV0aGluZyBiZXNpZGVzIHRoZSBFS00gdmFsdWUg aXMgdGhlIG9ubHkgdGhpbmcgdGhhdCBjb21lcyB0byBteSBtaW5kIHRoYXQgd291bGQgZml0IGlu IHRoaXMgZm9ybWF0IGFuZCByZXF1aXJlIGNoYW5naW5nIHRoZSB2ZXJzaW9uIG51bWJlci4NCg0K SWYgbW9yZSBzdWJzdGFudGlhbCBjaGFuZ2VzIGFyZSBtYWRlIHRvIHRoZSBUb2tlbkJpbmRpbmdN ZXNzYWdlLCBJIGltYWdpbmUgdGhhdCBjaGFuZ2VzIHdpbGwgbmVlZCB0byBiZSBtYWRlIHRvIG5l Z290aWF0aW9uIHRvIHN1cHBvcnQgdGhvc2UgY2hhbmdlcy4gSW4gdGhhdCBjYXNlLCB0aGUgdmVy c2lvbiBmaWVsZCBpbiB0aGUgY3VycmVudCBuZWdvdGlhdGlvbiBleHRlbnNpb24gaXMgdXNlbGVz cyAoYSBuZXcgZXh0ZW5zaW9uIHdpbGwgYmUgbmVlZGVkIGZvciBuZWdvdGlhdGluZyBuZXcgdGhp bmdzKS4NCg0KSSB0aGluayB0aGUgbGlrZWxpaG9vZCB0aGF0IGEgY2hhbmdlIHdpbGwgYmUgbGFy Z2UgZW5vdWdoIHRvIHdhcnJhbnQgYSBjaGFuZ2UgaW4gcHJvdG9jb2wgdmVyc2lvbiBudW1iZXIs IHlldCBzbWFsbCBlbm91Z2ggdGhhdCBuZWdvdGlhdGlvbiBkb2Vzbid0IGNoYW5nZSwgaXMgZmFp cmx5IHNtYWxsLiBUaGF0LCBhbmQgdGhlIHBvdGVudGlhbCBvc3NpZmljYXRpb24gb2YgdGhlIHZl cnNpb24gZmllbGQgc2VlbSBsaWtlIGdvb2QgcmVhc29ucyB0byByZW1vdmUgdGhlIHZlcnNpb24g ZmllbGQgYW5kIHVzZSBhIG5ldyBUTFMgZXh0ZW5zaW9uIG51bWJlciB3aGVuIHRoZSB0aW1lIGNv bWVzLg0KDQpPbiBUdWUsIEF1ZyA5LCAyMDE2IGF0IDk6NDkgQU0sIEFuZHJlaSBQb3BvdiA8QW5k cmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29t Pj4gd3JvdGU6DQpUaGUgZHJhd2JhY2tzIG9mIG5lZ290aWF0aW5nIGVhY2ggVEIgdmVyc2lvbiB3 aXRoIGEgY3VzdG9tIFRMUyBleHRlbnNpb246DQoxLiBNb3JlIGJ5dGVzIGluIHRoZSBDbGllbnRI ZWxsbzsNCjIuIE1vcmUgSUVURiBwcm9jZXNzIHdoZW4gYWRkaW5nIG5ldyBUQiB2ZXJzaW9uczsN CjMuIFRMUyB1cGRhdGUgZm9yIGVhY2ggVEIgdmVyc2lvbiwgb3IgdGhlIG5lZWQgdG8gYWRkICJn ZW5lcmljIFRMUyBleHRlbnNpb24iIHN1cHBvcnQsIHB1dHRpbmcgdGhlIGNhbGxlciBvZiB0aGUg VExTIHN0YWNrIGluIGNoYXJnZSBvZiBoYW5kbGluZyAoYSBzdWJzZXQgb2YpIFRMUyBleHRlbnNp b25zLg0KDQpUaGUgcG90ZW50aWFsIGJlbmVmaXRzOg0KYSkgRXh0ZW5zaWJpbGl0eSBpcyBjb25j ZW50cmF0ZWQgaW4gb25lIHBsYWNlPw0KYikgVGhlIHNlcnZlciBoYXMgYSBsaXN0IG9mIGFsbCBj bGllbnQtc3VwcG9ydGVkIFRCIHZlcnNpb25zIGluIHRoZSBDbGllbnRIZWxsbyAodGhpcyBjYW4g YmUgYWNoaWV2ZWQgd2l0aGluIG9uZSBUTFMgZXh0ZW5zaW9uLCBpZiBkZXNpcmVkKS4NCg0KVG8g bWUsIHRoZXNlIGRyYXdiYWNrcyBvdXR3ZWlnaCB0aGUgYmVuZWZpdHMsIGJ1dCBJIGNvdWxkIGxp dmUgd2l0aCBlaXRoZXIgZGVzaWduLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhv bXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT5dDQpTZW50OiBN b25kYXksIEF1Z3VzdCA4LCAyMDE2IDc6MzUgUE0NClRvOiBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Q b3BvdkBtaWNyb3NvZnQuY29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+DQpD YzogTmljayBIYXJwZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbTxtYWlsdG86bmhhcnBlckBnb29nbGUu Y29tPj47IEJpbGwgQ294IDx3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPG1haWx0bzp3YXl3YXJkZ2Vl a0Bnb29nbGUuY29tPj47IHVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOnVuYmVhcmFibGVAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFRMUyBleHRlbnNpb246IHZlcnNpb24g ZmllbGQNCk9uIDkgQXVndXN0IDIwMTYgYXQgMTI6MjcsIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBv cG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3Jv dGU6DQo+IEFsc28sIHRoZSBwcm9wb3NhbCByZXF1aXJlcyB0aGF0IGEgVExTIHN0YWNrIGJlIHVw ZGF0ZWQgZm9yIGV2ZXJ5IG5ldyBUQiB2ZXJzaW9uLCB3aGljaCBpcyBhIHJlYWwgZHJhd2JhY2su IFdpdGggdGhlIGN1cnJlbnQgVEIgbmVnb3RpYXRpb24gZXh0ZW5zaW9uLCB3ZSBjYW4gYWRkIG5l dyBUQiB2ZXJzaW9ucyB3aXRob3V0IGNoYW5naW5nIFRMUy4NCg0KVGhhdCdzIGEgcHJvYmxlbSB0 aGF0IGNhbiBiZSBzb2x2ZWQgd2l0aCBzb2Z0d2FyZSwgaWYgeW91IGNhcmUgYWJvdXQgdGhhdCBz b3J0IG9mIHRoaW5nOg0KICB0bHMuYWRkR2VuZXJpY0NsaWVudEhlbGxvRXh0ZW5zaW9uKGlkLCBi bG9iKTsNCiAgdGxzLmFkZEdlbmVyaWNTZXJ2ZXJIZWxsb0V4dGVuc2lvbkhhbmRsZXIoaWQsIChi bG9iKSA9PiB7Li4ufSk7DQogIGJsb2IgPSB0bHMuZ2V0R2VuZXJpY1NlcnZlckhlbGxvRXh0ZW5z aW9uKGlkKTsNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QNClVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRv OlVuYmVhcmFibGVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3VuYmVhcmFibGUNCg0KDQo= --_000_CY1PR03MB215532C510C58E4B638FF7FC8CEB0CY1PR03MB2155namp_ 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 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9y bWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjYxMDE2Nzk2ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6MTY5MTUwMTUwMiA5MjMxNTg1NjYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3Qg bDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo0MjU7DQoJbXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpD YWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0 IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNvIHRoZSBwcm9wb3Nh bCBpcyB0byBrZWVwIHVzaW5nIFRMUyBleHRlbnNpb24gMjQsIGFuZCByZW1vdmUgdG9rZW5fYmlu ZGluZ192ZXJzaW9uIGZpZWxkPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5EcmFmdCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBhZGRp dGlvbmFsbHkgc3VwcGx5IGFub3RoZXIsIHByaXZhdGUgVExTIGV4dGVuc2lvbiBUQkQsIHRoYXQg d2lsbCBjb250YWluIHRoZSB0b2tlbl9iaW5kaW5nX3ZlcnNpb24gZmllbGQ/DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZ1dHVy ZSBUQiB2ZXJzaW9ucyB3aWxsIHJlcXVpcmUgbmV3IFRMUyBleHRlbnNpb25zLCBpbiBhZGRpdGlv biB0byB0aGUgY3VycmVudGx5IGRlZmluZWQgMjQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG9u4oCZdCBy ZWFsbHkgbGlrZSB0aGlzLCBidXQgdHJ5aW5nIHRvIHVuZGVyc3RhbmQgdGhlIHN1Z2dlc3RlZCBj aGFuZ2UgaW4gY2FzZSBJ4oCZbSBpbiB0aGUgcm91Z2ggYW5kIHRoZSBXRyBkZWNpZGVzIHRvIGdv IHRoaXMgd2F5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4gTmljayBIYXJwZXIgW21haWx0bzpuaGFycGVyQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDIzLCAyMDE2IDEwOjUyIEFNPGJyPg0KPGI+VG86PC9i PiBBbmRyZWkgUG9wb3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxi PkNjOjwvYj4gTWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs7 IEJpbGwgQ294ICZsdDt3YXl3YXJkZ2Vla0Bnb29nbGUuY29tJmd0OzsgQnJpYW4gQ2FtcGJlbGwg Jmx0O2JjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tJmd0OzsgdW5iZWFyYWJsZUBpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIFRMUyBleHRlbnNpb246IHZlcnNp b24gZmllbGQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaHJvbWUgaXMg Y3VycmVudGx5IHVzaW5nIHRoZSBJQU5BIGFzc2lnbm1lbnQgKDI0KS48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBkcmFmdCAwLjksIHdlIGNvdWxkIHVz ZSBhbiBleHBlcmltZW50YWwgVExTIGV4dGVuc2lvbiBudW1iZXIsIG9yIHdlIGNvdWxkIHVzZSAy NCBmb3IgVEIsIGFuZCBzZW5kIGFuIGFkZGl0aW9uYWwgZXh0ZW5zaW9uIHRvIGluZGljYXRlIHRo ZSBkcmFmdCB2ZXJzaW9uIChsaWtlIGhvdyBUTFMgMS4zIGlzIGRvaW5nIHdpdGggMHhmZjAyKS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g VHVlLCBBdWcgMjMsIDIwMTYgYXQgOTo1OSBBTSwgQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJt YWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWku UG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb20gdGhlIHByYWN0aWNhbCBzdGFuZHBvaW50LCBpZiB3ZSBnbyB3aXRoIG9uZSBUTFMg ZXh0ZW5zaW9uIGZvciBlYWNoIHN1cHBvcnRlZCBUQiB2ZXJzaW9uLCB3aGF0IFRMUyBleHRlbnNp b24NCiBJRCBzaG91bGQgd2UgdXNlIHRvIGluZGljYXRlIHN1cHBvcnQgZm9yIHRoZSB1cGNvbWlu ZyAwLjkgZHJhZnQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbHNvLCBkb2VzIENocm9tZSBhbHJlYWR5 IHVzZSB0aGUgY3VycmVudCBlYXJseSBJQU5BIGFzc2lnbm1lbnQgKDI0KSB0byBuZWdvdGlhdGUg VEIgdjAuOD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxA cGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHku Y29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgOSwgMjAxNiAxMTo0 NCBBTTxicj4NCjxiPlRvOjwvYj4gTmljayBIYXJwZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpuaGFy cGVyQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5uaGFycGVyQGdvb2dsZS5jb208L2E+Jmd0 Ozxicj4NCjxiPkNjOjwvYj4gQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVp LlBvcG92QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9z b2Z0LmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj51bmJlYXJhYmxlQGlldGYub3JnPC9hPjsgTWFydGluIFRob21zb24gJmx0 OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OzsgQmlsbCBDb3ggJmx0OzxhIGhyZWY9 Im1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2F5d2FyZGdl ZWtAZ29vZ2xlLmNvbTwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJh YmxlXSBUTFMgZXh0ZW5zaW9uOiB2ZXJzaW9uIGZpZWxkPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0ZW5kIHRvIGFncmVl IHdpdGggTWFydGluIGFuZCBOaWNrJ3MgcGVyc3BlY3RpdmUgaGVyZS4gS2V5IHBhcmFtZXRlcnMs IHRva2VuIGJpbmRpbmcgdHlwZXMsIGFuZCBleHRlbnNpb25zIGFscmVhZHkgcHJvdmlkZSBmb3Ig YSBmYWlyIGFtb3VudCBvZiBleHRlbnNpYmlsaXR5LiBPbmUgY2FuJ3QgcmVsaWFibHkNCiBwcmVk aWN0IHRoZSBmdXR1cmUgYnV0IGl0IHNlZW1zIG1vcmUgbGlrZWx5IHRoYW4gbm90IHRoYXQgdGhl IGZpcnN0IHZlcnNpb24gb2YgVEIgKHdoaWNoIGRvZXNuJ3QgZXZlbiBleGlzdCB5ZXQpIGNvdWxk IHdlbGwgaGF2ZSBhIG5pY2UgbG9uZyBydW4gYmVmb3JlIGEgbmV3IHZlcnNpb24gaXMgbmVlZGVk LiBBIG5ldyBleHRlbnNpb24gY2FuIGJlIGRvbmUgaWYgYW5kIHdoZW4gdGhhdCB0aW1lIGNvbWVz IGFuZCB3b3JraW5nIHdpdGggZXhpc3RpbmcNCiBUTFMgZXh0ZW5zaW9ucyBpcyBtdWNoIG1vcmUg bGlrZWx5IHRvIHdvcmsgaW4gcHJhY3RpY2UgdGhhbiBhIHZlcnNpb24gbWVjaGFuaXNtIHdpdGhp biB0aGUgVEIgdGhhdCB3b250IHJlYWxseSBiZSBleGVyY2lzZWQgYmVjYXVzZSB0aGVyZSdzIG9u bHkgb25lIHZlcnNpb24uIEluIG1lYW50aW1lIHRoZSBjbGllbnQgYW5kIHNlcnZlciBoZWxsbyBj YW4gdXNlIGEgZmV3IGxlc3MgYnl0ZXMgKG5vIHZlcnNpb24pIGluIHRoZSBvcmRpbmFyeSBjYXNl DQogb2YgbmVnb3RpYXRpbmcgdGhlIG9ubHkgdmVyc2lvbiBvZiBUQiB0aGF0IGV4aXN0cyAoZXIs IHdpbGwgZXhpc3Qgc29vbikuIDxicj4NCjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgQXVnIDksIDIwMTYgYXQgMTE6 MzggQU0sIE5pY2sgSGFycGVyICZsdDs8YSBocmVmPSJtYWlsdG86bmhhcnBlckBnb29nbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+bmhhcnBlckBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPklmIHdlIGxlYXZlIGl0IGFzIGlzLCB0 aGUgdmVyc2lvbiBmaWVsZCBpcyBsaWtlbHkgdG8gb3NzaWZ5IChsaWtlIGl0IGhhcyB3aXRoIGV2 ZXJ5IHZlcnNpb24gb2YgU1NMIGFuZCBUTFMpLCBzbyB0aGVyZSdzIGEgZGVjZW50IGNoYW5jZSB0 aGF0IGZvciBzb21lIGltcGxlbWVudGF0aW9ucyBpdCB3b24ndCB3b3JrDQogKGEgdmVyc2lvbiBp bnRvbGVyYW50IHNlcnZlciB3b3VsZCByZWplY3QgYSBjbGllbnQncyB2MiB0b2tlbiBiaW5kaW5n IG5lZ290aWF0aW9uLCBpbnN0ZWFkIG9mIGZhbGxpbmcgYmFjayB0byB2MTsgc2VwYXJhdGUgZXh0 ZW5zaW9ucyBkb24ndCBoYXZlIHRoaXMgcHJvYmxlbSkuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIHZlcnNpb24gZmllbGQgYWxzbyBhc3N1bWVzIHRo YXQgdGhlIG9ubHkgdGhpbmcgKGFwYXJ0IGZyb20gdmVyc2lvbiBudW1iZXIpIHRoYXQgbmVlZHMg dG8gYmUgbmVnb3RpYXRlZCBpcyB0aGUga2V5IHBhcmFtZXRlcnMuIElmIGEgdG9rZW4gYmluZGlu ZyB2MiBpcyBhZGRlZCwgd2lsbCBpdCB3YW50IHRvDQogbmVnb3RpYXRlIHNvbWV0aGluZyBlbHNl IChhbmQgdGhlbiBuZWVkIGEgbmV3IFRMUyBleHRlbnNpb24pPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSdtIHdvbmRlcmluZyB3aGF0 IGZ1dHVyZSBjaGFuZ2VzIHRvIHRva2VuIGJpbmRpbmcgbWlnaHQgbG9vayBsaWtlIHRoYXQgcmVx dWlyZSBidW1waW5nIHRoZSBwcm90b2NvbCB2ZXJzaW9uIG51bWJlci4gSSBrbm93IHRoYXQga2V5 IGF0dGVzdGF0aW9uIGlzIHNvbWV0aGluZyB0aGF0IGNvdWxkIHBvdGVudGlhbGx5DQogYmUgYWRk ZWQuIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGlzIHdvdWxkIGdvIGluIGFuIEV4dGVuc2lv biBpbiB0aGUgVG9rZW5CaW5kaW5nIHN0cnVjdCwgYW5kIHdvdWxkbid0IG5lZWQgdG8gYnVtcCB0 aGUgcHJvdG9jb2wgdmVyc2lvbiBudW1iZXIuIEZvciB0aGUgcHJvdG9jb2wgdmVyc2lvbiBudW1i ZXIgdG8gYmUgY2hhbmdlZCwgc29tZXRoaW5nIHdvdWxkIGhhdmUgdG8gY2hhbmdlIHRoZSBUb2tl bkJpbmRpbmdNZXNzYWdlIGZvcm1hdA0KIChvciB0aGUgZm9ybWF0IG9mIG9uZSBvZiBpdHMgZmll bGRzKS4gVGhlcmUncyBhbHJlYWR5IGEgZGVjZW50IGFtb3VudCBvZiBleHRlbnNpYmlsaXR5IHRo ZXJlIGluIHRlcm1zIG9mIGtleSBwYXJhbWV0ZXJzLCB0b2tlbiBiaW5kaW5nIHR5cGVzLCBhbmQg ZXh0ZW5zaW9ucy4gQ2hhbmdpbmcgdGhlIHNpZ25hdHVyZSB0byBiZSBvZiBzb21ldGhpbmcgYmVz aWRlcyB0aGUgRUtNIHZhbHVlIGlzIHRoZSBvbmx5IHRoaW5nIHRoYXQgY29tZXMgdG8gbXkNCiBt aW5kIHRoYXQgd291bGQgZml0IGluIHRoaXMgZm9ybWF0IGFuZCByZXF1aXJlIGNoYW5naW5nIHRo ZSB2ZXJzaW9uIG51bWJlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPklmIG1vcmUgc3Vic3RhbnRpYWwgY2hhbmdlcyBhcmUgbWFkZSB0 byB0aGUgVG9rZW5CaW5kaW5nTWVzc2FnZSwgSSBpbWFnaW5lIHRoYXQgY2hhbmdlcyB3aWxsIG5l ZWQgdG8gYmUgbWFkZSB0byBuZWdvdGlhdGlvbiB0byBzdXBwb3J0IHRob3NlIGNoYW5nZXMuIElu IHRoYXQgY2FzZSwgdGhlIHZlcnNpb24gZmllbGQNCiBpbiB0aGUgY3VycmVudCBuZWdvdGlhdGlv biBleHRlbnNpb24gaXMgdXNlbGVzcyAoYSBuZXcgZXh0ZW5zaW9uIHdpbGwgYmUgbmVlZGVkIGZv ciBuZWdvdGlhdGluZyBuZXcgdGhpbmdzKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhpbmsgdGhlIGxpa2VsaWhvb2QgdGhhdCBh IGNoYW5nZSB3aWxsIGJlIGxhcmdlIGVub3VnaCB0byB3YXJyYW50IGEgY2hhbmdlIGluIHByb3Rv Y29sIHZlcnNpb24gbnVtYmVyLCB5ZXQgc21hbGwgZW5vdWdoIHRoYXQgbmVnb3RpYXRpb24gZG9l c24ndCBjaGFuZ2UsIGlzIGZhaXJseSBzbWFsbC4gVGhhdCwNCiBhbmQgdGhlIHBvdGVudGlhbCBv c3NpZmljYXRpb24gb2YgdGhlIHZlcnNpb24gZmllbGQgc2VlbSBsaWtlIGdvb2QgcmVhc29ucyB0 byByZW1vdmUgdGhlIHZlcnNpb24gZmllbGQgYW5kIHVzZSBhIG5ldyBUTFMgZXh0ZW5zaW9uIG51 bWJlciB3aGVuIHRoZSB0aW1lIGNvbWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUdWUsIEF1ZyA5LCAy MDE2IGF0IDk6NDkgQU0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Q b3BvdkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92QG1pY3Jvc29m dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGUgZHJhd2Jh Y2tzIG9mIG5lZ290aWF0aW5nIGVhY2ggVEIgdmVyc2lvbiB3aXRoIGEgY3VzdG9tIFRMUyBleHRl bnNpb246PGJyPg0KMS4gTW9yZSBieXRlcyBpbiB0aGUgQ2xpZW50SGVsbG87PGJyPg0KMi4gTW9y ZSBJRVRGIHByb2Nlc3Mgd2hlbiBhZGRpbmcgbmV3IFRCIHZlcnNpb25zOzxicj4NCjMuIFRMUyB1 cGRhdGUgZm9yIGVhY2ggVEIgdmVyc2lvbiwgb3IgdGhlIG5lZWQgdG8gYWRkICZxdW90O2dlbmVy aWMgVExTIGV4dGVuc2lvbiZxdW90OyBzdXBwb3J0LCBwdXR0aW5nIHRoZSBjYWxsZXIgb2YgdGhl IFRMUyBzdGFjayBpbiBjaGFyZ2Ugb2YgaGFuZGxpbmcgKGEgc3Vic2V0IG9mKSBUTFMgZXh0ZW5z aW9ucy48YnI+DQo8YnI+DQpUaGUgcG90ZW50aWFsIGJlbmVmaXRzOjxicj4NCmEpIEV4dGVuc2li aWxpdHkgaXMgY29uY2VudHJhdGVkIGluIG9uZSBwbGFjZT88YnI+DQpiKSBUaGUgc2VydmVyIGhh cyBhIGxpc3Qgb2YgYWxsIGNsaWVudC1zdXBwb3J0ZWQgVEIgdmVyc2lvbnMgaW4gdGhlIENsaWVu dEhlbGxvICh0aGlzIGNhbiBiZSBhY2hpZXZlZCB3aXRoaW4gb25lIFRMUyBleHRlbnNpb24sIGlm IGRlc2lyZWQpLjxicj4NCjxicj4NClRvIG1lLCB0aGVzZSBkcmF3YmFja3Mgb3V0d2VpZ2ggdGhl IGJlbmVmaXRzLCBidXQgSSBjb3VsZCBsaXZlIHdpdGggZWl0aGVyIGRlc2lnbi48YnI+DQo8YnI+ DQpDaGVlcnMsPGJyPg0KPGJyPg0KQW5kcmVpPGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQpGcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNv bkBnbWFpbC5jb208L2E+XTxicj4NClNlbnQ6IE1vbmRheSwgQXVndXN0IDgsIDIwMTYgNzozNSBQ TTxicj4NClRvOiBBbmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZA bWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29t PC9hPiZndDs8YnI+DQpDYzogTmljayBIYXJwZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpuaGFycGVy QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5uaGFycGVyQGdvb2dsZS5jb208L2E+Jmd0Ozsg QmlsbCBDb3ggJmx0OzxhIGhyZWY9Im1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tIiB0YXJn ZXQ9Il9ibGFuayI+d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFp bHRvOnVuYmVhcmFibGVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51bmJlYXJhYmxlQGlldGYu b3JnPC9hPjxicj4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gVExTIGV4dGVuc2lvbjogdmVy c2lvbiBmaWVsZDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIDkgQXVndXN0IDIwMTYgYXQgMTI6MjcsIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5k cmVpLlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IEFsc28sIHRo ZSBwcm9wb3NhbCByZXF1aXJlcyB0aGF0IGEgVExTIHN0YWNrIGJlIHVwZGF0ZWQgZm9yIGV2ZXJ5 IG5ldyBUQiB2ZXJzaW9uLCB3aGljaCBpcyBhIHJlYWwgZHJhd2JhY2suIFdpdGggdGhlIGN1cnJl bnQgVEIgbmVnb3RpYXRpb24gZXh0ZW5zaW9uLCB3ZSBjYW4gYWRkIG5ldyBUQiB2ZXJzaW9ucyB3 aXRob3V0IGNoYW5naW5nIFRMUy48YnI+DQo8YnI+DQpUaGF0J3MgYSBwcm9ibGVtIHRoYXQgY2Fu IGJlIHNvbHZlZCB3aXRoIHNvZnR3YXJlLCBpZiB5b3UgY2FyZSBhYm91dCB0aGF0IHNvcnQgb2Yg dGhpbmc6PGJyPg0KJm5ic3A7IHRscy5hZGRHZW5lcmljQ2xpZW50SGVsbG9FeHRlbnNpb24oaWQs IGJsb2IpOzxicj4NCiZuYnNwOyB0bHMuYWRkR2VuZXJpY1NlcnZlckhlbGxvRXh0ZW5zaW9uSGFu ZGxlcihpZCwgKGJsb2IpID0mZ3Q7IHsuLi59KTs8YnI+DQombmJzcDsgYmxvYiA9IHRscy5nZXRH ZW5lcmljU2VydmVySGVsbG9FeHRlbnNpb24oaWQpOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpVbmJlYXJh YmxlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+ DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFi bGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3VuYmVhcmFibGU8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_CY1PR03MB215532C510C58E4B638FF7FC8CEB0CY1PR03MB2155namp_-- From nobody Tue Aug 23 11:53: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 9929912D789 for ; Tue, 23 Aug 2016 11:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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; domainkeys=pass (1024-bit key) header.sender=andreipo=microsoft.com@github.com 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 Ds6DJG9W8-UO for ; Tue, 23 Aug 2016 11:53:33 -0700 (PDT) Received: from m69-170.mailgun.net (m69-170.mailgun.net [166.78.69.170]) (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 1BC7512D78A for ; Tue, 23 Aug 2016 11:53:32 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1471978411; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=TJgJXjdGNMYjJ0DmI6o/f7e6ga3ehroK9MsbBxho2IQ=; b=oYNtwNcHpanGhu3z90RiBcscRr6R6T2vjSeVouHEy4GDOc9AXw0vaVru2iTzGZ3GWv3H0q04 NXGu8cGgi1H45KNfNLUYTEPwUpV/CTJDsOdTvp0XQowzPh5bjtEeppZ86ueAuGK99kMfyBSZ pNyca7gLjnsBL33PqhFgwLWifwU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=Fclrbza/Lv3gvRnciaGtbHvHxU2abJ2kvxGs8OROd3DDaGX6JkNI07B3ZsEl5eEWldn/nq ZNYHjZe1m8MXRf5v/bWG/GNcZFdQWgTrGuFlmZJjMFubFTKQevYCYHAnFJlVjUzoVwMUA/bA pwbpWNp9zQMdrWhdhd3vI+1xKRrK8= Sender: andreipo=microsoft.com@github.com X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Received: from github.com (Unknown [192.30.252.42]) by mxa.mailgun.org with ESMTP id 57bc9ba9.7fe36a298450-in06; Tue, 23 Aug 2016 18:53:29 -0000 (UTC) Date: Tue, 23 Aug 2016 11:53:29 -0700 From: Andrei Popov To: unbearable@ietf.org Message-ID: <57bc9ba9dbca2_5f2c3fd837de11341460d7@hookshot-fe1-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_57bc9ba9db7fd_5f2c3fd837de11341459b0"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] 87d1ac: initiate TBPROTO -09 rev X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Andrei Popov 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, 23 Aug 2016 18:53:35 -0000 ----==_mimepart_57bc9ba9db7fd_5f2c3fd837de11341459b0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: 87d1aca24beef2a559a5704060ff4874dae85bb8 https://github.com/TokenBinding/Internet-Drafts/commit/87d1aca24beef2a559a5704060ff4874dae85bb8 Author: JeffH Date: 2016-07-21 (Thu, 21 Jul 2016) Changed paths: R draft-ietf-tokbind-protocol-08.xml A draft-ietf-tokbind-protocol-09.xml Log Message: ----------- initiate TBPROTO -09 rev Commit: 25ce07f31bd596a75d85ac7118713789bddf3149 https://github.com/TokenBinding/Internet-Drafts/commit/25ce07f31bd596a75d85ac7118713789bddf3149 Author: JeffH Date: 2016-07-21 (Thu, 21 Jul 2016) Changed paths: M draft-ietf-tokbind-protocol-09.xml Log Message: ----------- add impl cons and additional priv cons Commit: b2c40e10b534580fa1ab931615966563a7843a70 https://github.com/TokenBinding/Internet-Drafts/commit/b2c40e10b534580fa1ab931615966563a7843a70 Author: =JeffH Date: 2016-07-22 (Fri, 22 Jul 2016) Changed paths: M draft-ietf-tokbind-protocol-09.xml Log Message: ----------- add line breaks Commit: 25b4098735e6e1ade253e1a3dd3aee2b69da39b1 https://github.com/TokenBinding/Internet-Drafts/commit/25b4098735e6e1ade253e1a3dd3aee2b69da39b1 Author: Mike Jones Date: 2016-07-22 (Fri, 22 Jul 2016) Changed paths: M draft-ietf-tokbind-protocol-09.xml Log Message: ----------- Update draft-ietf-tokbind-protocol-09.xml Expand abbreviations Commit: 71df58b4e95382123ec8bedd39b3f525171350a4 https://github.com/TokenBinding/Internet-Drafts/commit/71df58b4e95382123ec8bedd39b3f525171350a4 Author: Mike Jones Date: 2016-07-23 (Sat, 23 Jul 2016) Changed paths: M README.md R draft-ietf-tokbind-https-05.xml A draft-ietf-tokbind-https-06.xml M draft-ietf-tokbind-protocol-09.xml Log Message: ----------- Moved Implementation Considerations and additional Privacy Considerations to tokbind-https spec Commit: 448a276e23f9c4e94dcd00f90237204f0bd6d617 https://github.com/TokenBinding/Internet-Drafts/commit/448a276e23f9c4e94dcd00f90237204f0bd6d617 Author: JeffH Date: 2016-08-01 (Mon, 01 Aug 2016) Changed paths: M draft-ietf-tokbind-https-06.xml Log Message: ----------- build upon language in HTTPSTB impl cons & priv cons Commit: fb333e90a8f38d536472972d376202955ae90ce7 https://github.com/TokenBinding/Internet-Drafts/commit/fb333e90a8f38d536472972d376202955ae90ce7 Author: JeffH Date: 2016-08-01 (Mon, 01 Aug 2016) Changed paths: M draft-ietf-tokbind-https-06.xml Log Message: ----------- fix up line breaks to be readable in github diff Commit: dc49fce9aee3c4bf6f28bfd5a6357c729f1122e7 https://github.com/TokenBinding/Internet-Drafts/commit/dc49fce9aee3c4bf6f28bfd5a6357c729f1122e7 Author: JeffH Date: 2016-08-15 (Mon, 15 Aug 2016) Changed paths: M draft-ietf-tokbind-https-06.xml Log Message: ----------- fixed xref tag closure Commit: b24896a2cdcf3d88214a6a52cc8e2175b1ae437b https://github.com/TokenBinding/Internet-Drafts/commit/b24896a2cdcf3d88214a6a52cc8e2175b1ae437b Author: JeffH Date: 2016-08-19 (Fri, 19 Aug 2016) Changed paths: M draft-ietf-tokbind-https-06.xml Log Message: ----------- polish api guidance prose. fixes #53 Commit: c919c7bfa5158d5d932f291c199c7d0d43bb8ed8 https://github.com/TokenBinding/Internet-Drafts/commit/c919c7bfa5158d5d932f291c199c7d0d43bb8ed8 Author: JeffH Date: 2016-08-19 (Fri, 19 Aug 2016) Changed paths: M draft-ietf-tokbind-https-06.xml Log Message: ----------- further polishing Commit: ea247a6ce567032aa7af9a0aa2634a594d4cc05d https://github.com/TokenBinding/Internet-Drafts/commit/ea247a6ce567032aa7af9a0aa2634a594d4cc05d Author: JeffH Date: 2016-08-19 (Fri, 19 Aug 2016) Changed paths: M draft-ietf-tokbind-https-06.xml Log Message: ----------- further polishing for #53 and Nick's comments Commit: 9e8f1a4f9b22fcce24ba1605849ccb2e8f741670 https://github.com/TokenBinding/Internet-Drafts/commit/9e8f1a4f9b22fcce24ba1605849ccb2e8f741670 Author: Andrei Popov Date: 2016-08-23 (Tue, 23 Aug 2016) Changed paths: M README.md R draft-ietf-tokbind-https-05.xml A draft-ietf-tokbind-https-06.xml R draft-ietf-tokbind-protocol-08.xml A draft-ietf-tokbind-protocol-09.xml Log Message: ----------- Merge branch 'equalsJeffH-TBPROTO-#53-apiguide' Compare: https://github.com/TokenBinding/Internet-Drafts/compare/747c8fed3bdf...9e8f1a4f9b22 ----==_mimepart_57bc9ba9db7fd_5f2c3fd837de11341459b0-- From nobody Tue Aug 23 11:59:34 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 9DE8612D7A7 for ; Tue, 23 Aug 2016 11:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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; domainkeys=pass (1024-bit key) header.sender=andreipo=microsoft.com@github.com 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 gFN8KWvIW28j for ; Tue, 23 Aug 2016 11:59:32 -0700 (PDT) Received: from m71-131.mailgun.net (m71-131.mailgun.net [166.78.71.131]) (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 D701312D7BA for ; Tue, 23 Aug 2016 11:59:24 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1471978763; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=gycDk5ne2nGC21dPoFSv6SDAE10HFAgH/8xsDXP82Kg=; b=Zr/rrkmT+M8PbLQkqfH3aTGJ5Lpqa5QUA6r+0s1Y3paIDxCkLDvYpdoJHXVQT0KF0/0lZhwG 7OTUaGSYM1rV0DJPkDeXOqR+aNQ/D4SLgHyKNB6njvc+UC7AtLatwszDvXOwO5gi+6BXlIZT VlMABi1svW/aCVL/l1RD98MyzIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=qxNtvsQI84a1HDwWpzcczckD7F6RPmUjTQ6/ud+irKeeE63J+daUwZNDe8WHXSrcexZ6A/ u3U5wiEU/xzY0nPSeKhp3hMFg1oytCwwCIOk/mJigA0XZhHQVzNdU6C8kfXs6gNROXsAVsXF GBUcYhNSp30nq95IR+2gIYaoSNBvc= Sender: andreipo=microsoft.com@github.com X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Received: from github.com (Unknown [192.30.252.46]) by mxa.mailgun.org with ESMTP id 57bc9d0a.7effe83fdcc0-in07; Tue, 23 Aug 2016 18:59:22 -0000 (UTC) Date: Tue, 23 Aug 2016 11:59:22 -0700 From: Andrei Popov To: unbearable@ietf.org Message-ID: <57bc9d0a95b46_24d83fa022e9113012502@hookshot-fe4-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_57bc9d0a956ce_24d83fa022e91130124940"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] 355962: Merging PR #54 X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Andrei Popov 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, 23 Aug 2016 18:59:34 -0000 ----==_mimepart_57bc9d0a956ce_24d83fa022e91130124940 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: 3559623fb7e67e1da7eed2ae20bd14ab803473ec https://github.com/TokenBinding/Internet-Drafts/commit/3559623fb7e67e1da7eed2ae20bd14ab803473ec Author: Andrei Popov Date: 2016-08-23 (Tue, 23 Aug 2016) Changed paths: M draft-ietf-tokbind-https-06.xml M draft-ietf-tokbind-protocol-09.xml Log Message: ----------- Merging PR #54 ----==_mimepart_57bc9d0a956ce_24d83fa022e91130124940-- From nobody Tue Aug 23 15:15:12 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 6DF5D12DBB3 for ; Tue, 23 Aug 2016 15:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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; domainkeys=pass (1024-bit key) header.sender=andreipo=microsoft.com@github.com 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 rToLKenJQwrB for ; Tue, 23 Aug 2016 15:14:58 -0700 (PDT) Received: from m69-169.mailgun.net (m69-169.mailgun.net [166.78.69.169]) (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 0EFB312DBCE for ; Tue, 23 Aug 2016 15:14:52 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1471990492; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=W0XwCE7TtSFXR3au4Al9jDvSIxz/EOb+uCEKoUjwnxg=; b=w4P9rCj/vVNurKHKX8E/DoimFKyQypzQCBXBmgzL0sbS44TwpDc9laQCB23uDWVIg0vLSB6w 6Tfupk/6+KFpaKQzQv5cCVs5oIq5XnbpxIwEQnzDFB35YJDT3lERwgFY4Yw3oU3jnVOgP446 9BUVSeQrWMwrgUoaeVnVjKNeEcQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=Ll/xOGj4Hs9FI/8pnQ2n39UiEvf3RHcuPXKcStkK4FnSTH1vznBnfEdZ7/ey8lnGvpsk09 kYSPrPJnLBpaa0k9ydEV6jmdEC0SBDikouKHq2s6t0zNu6HbfgkUPL4F0KrW4YlCqiWXMmyP ZLXKD4eSfnsJr24WPtzjmDjFrQJBE= Sender: andreipo=microsoft.com@github.com X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Received: from github.com (Unknown [192.30.252.34]) by mxa.mailgun.org with ESMTP id 57bccada.7fbfff3f49f0-in1; Tue, 23 Aug 2016 22:14:50 -0000 (UTC) Date: Tue, 23 Aug 2016 15:14:50 -0700 From: Andrei Popov To: unbearable@ietf.org Message-ID: <57bccada67787_3733fe9425db13054417@hookshot-fe2-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_57bccada6737a_3733fe9425db1305436f"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] 4c23e6: arify in HTTPSTB that base64url encoding means no ... X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Andrei Popov 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, 23 Aug 2016 22:15:03 -0000 ----==_mimepart_57bccada6737a_3733fe9425db1305436f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: 4c23e603d32649c33872aca3f68327bf85d21111 https://github.com/TokenBinding/Internet-Drafts/commit/4c23e603d32649c33872aca3f68327bf85d21111 Author: Brian Campbell Date: 2016-08-02 (Tue, 02 Aug 2016) Changed paths: M draft-ietf-tokbind-https-05.xml Log Message: ----------- arify in HTTPSTB that base64url encoding means no padding, no line breaks, etc. Commit: 68f8ee14b9bbd4555b78d2426fe2e7eaca930ed2 https://github.com/TokenBinding/Internet-Drafts/commit/68f8ee14b9bbd4555b78d2426fe2e7eaca930ed2 Author: Andrei Popov Date: 2016-08-23 (Tue, 23 Aug 2016) Changed paths: M draft-ietf-tokbind-https-06.xml Log Message: ----------- Merge branch 'nopad' of https://github.com/b---c/Internet-Drafts into b---c-nopad Commit: 20878204628cc16e7d55e514b66f2361323f7ff5 https://github.com/TokenBinding/Internet-Drafts/commit/20878204628cc16e7d55e514b66f2361323f7ff5 Author: Andrei Popov Date: 2016-08-23 (Tue, 23 Aug 2016) Changed paths: M draft-ietf-tokbind-https-06.xml Log Message: ----------- Merge branch 'b---c-nopad' Commit: d9b65d3bad15945a0433875b93e0dd0d2f094b93 https://github.com/TokenBinding/Internet-Drafts/commit/d9b65d3bad15945a0433875b93e0dd0d2f094b93 Author: Andrei Popov Date: 2016-08-23 (Tue, 23 Aug 2016) Changed paths: M draft-ietf-tokbind-https-06.xml Log Message: ----------- Merging PR #57 Compare: https://github.com/TokenBinding/Internet-Drafts/compare/3559623fb7e6...d9b65d3bad15 ----==_mimepart_57bccada6737a_3733fe9425db1305436f-- From nobody Tue Aug 23 16:20:54 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 D3A5012D1D5 for ; Tue, 23 Aug 2016 16:20: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, FREEMAIL_FROM=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 (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 oO899Vg1jp01 for ; Tue, 23 Aug 2016 16:20:51 -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 4BEE612D095 for ; Tue, 23 Aug 2016 16:20:51 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id l2so122100154qkf.3 for ; Tue, 23 Aug 2016 16:20:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kIM+5N6FNv4QMT8aCMZnQi08bwAFrf1Yb+PYpXxzT/c=; b=GuTNtngHhhj6c0T+fmNsIep5GQtB2dznAbvGKpo/yltdjkE1OHPMZG1V6gmAePPeb3 RZuTdxENWasR7+7Bxp/zOuM/f8jqngNPVyG9huaBGE6XJeQ3xCAAuaBpNryRnlaxaxNM kybVagg5AYUf9wt+7dbtuMBSg64beuGFrGl/yB4xVYBEsH3RfUNZc5HwEX9pjtxO2I6R GHzx9y5zA7vNWPQvztYVExyTBFlrPUWxs4iNy5CWChv4yhEd0xh/MEZU8GaBMRoVcsVH Au0ruHcqmWylKwWFYal/Q8Ge6oltNf3CGAw7rNvE22cbnOcD9pwPZkCKkgvnTxjCsLeR S41A== 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=kIM+5N6FNv4QMT8aCMZnQi08bwAFrf1Yb+PYpXxzT/c=; b=mz/gY1HWhaceCgZXN8dfSO0twFvXMRoAzNx6jROXeF2f3c/ABGaTSobkm8BOBDRjGB q+ev9q42hizthaTwLsNzR6VbK3ub8dpULmFlIdbjRmmOqeW1XNHgvrjkZ6CBunlifwo9 1XnlDfXrfr0UPd0rGhc2pAZv8gOdGt7v8PhyXW4LiG6T+mYiADvLqiyOAuTDDy8uKq+t q4Juv/sz8HyFFhLBt5OeuZizhKBbx0fzuonMHD9UkGKc9UKwZ/XHgBvs2B1yercugeIO nVvQnkwtbf7+CDvqKD9rRD44ub2r3nZpZl4Wb+9C4a+UKFNVn5dNakPVfGsSGiL48jee JRdg== X-Gm-Message-State: AEkoous07p/s9kRpbOARFbrt6CXk00X7c/tvYf6Xse6pVbX5VLtknme3q1IH8rgYWwIfI3m6n5mS1Yf5xti8Ag== X-Received: by 10.55.141.199 with SMTP id p190mr32862045qkd.185.1471994450411; Tue, 23 Aug 2016 16:20:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Tue, 23 Aug 2016 16:20:49 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 24 Aug 2016 09:20:49 +1000 Message-ID: To: Nick Harper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Andrei Popov , Brian Campbell , "unbearable@ietf.org" , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 23 Aug 2016 23:20:53 -0000 On 24 August 2016 at 03:52, Nick Harper wrote: > For draft 0.9, we could use an experimental TLS extension number, or we > could use 24 for TB, and send an additional extension to indicate the draft > version (like how TLS 1.3 is doing with 0xff02). Why not use the current number until you make a breaking change (as I suggested that you do), then let IANA have the number back and use a new one each time you need to make a breaking change. From nobody Tue Aug 23 16:35:34 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 DCDB612D786 for ; Tue, 23 Aug 2016 16:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Qw7YBxm1jCsE for ; Tue, 23 Aug 2016 16:35:30 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0110.outbound.protection.outlook.com [104.47.38.110]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81AAA12DC00 for ; Tue, 23 Aug 2016 16:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xlA2kmTbYcx1cJyaBoKXUOkLLzE4oORgQJANpSlNP8A=; b=Nrc5KIxMNgUrlpoZkitwa3Mjc13DPMJEltm0c+WGzdzqIh662wg2EQoYC0LaFQOhE+4IquDHnkntf9zmupxczGGG01NrDdZ7/7NN0aJepdiVb+nL9PtfdUiHxJ2niooQzE9FCf2Xy4fufHEV27p3tZjHc9ScbpQMKe9IOj3gRt0= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Tue, 23 Aug 2016 23:35:27 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0587.013; Tue, 23 Aug 2016 23:35:27 +0000 From: Andrei Popov To: Martin Thomson , Nick Harper Thread-Topic: [Unbearable] TLS extension: version field Thread-Index: AQHR8UE0hAr3fGh5LkSos3djbwbcUaA/MmwAgAAmOoCAAAGk8IAAhvMAgAAFqjCAAAO6AIAA6WmAgAATAoCAABJZgIAV3xfwgAATKACAAFvQgIAAAlRw Date: Tue, 23 Aug 2016 23:35:27 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: 3c3c9230-e158-4c97-5623-08d3cbae2a11 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2155; 6:XTecUWtPK/bRgXSxM5LBAyxVRaslqT8ZCkQTGDMHN8FlAQbG2btBA56ff76+tAS6CECsCZk6ur0pE3Z+uZKMWzYszo+SNznxjFTKids2d/BA3d+cXXru+VUBNQx8amNZ2xJM1KwBXR4VcVfUzzKram37Vexb6Usu/tDoKXKwc/J7xRPjWRuisrO6+G9NLwp4D0IMOkdHcrw2zvHEB6zHZVk6YvrHMHzMY2S5oSz/HYVSmBIy4sPe5tYm5R1L0i3Wd9loqGjusFm1ZOa/H1f46V5u/qkLXuHRqZFtr6T+OV//cj7cH+JfwJyU+bjCJ0cfwZ3dlbxnmqbUh9ZUJ3DiiQ==; 5:hSz/eHPCfvtKC0O8bVGUzVOKdZfymZMDnUucWLx/zEZpVxNH3jB8j/eIFxu5slvAWklVdzFTJWPcNIMItK0YVwicMWxcsn9gt3+DHhKh5KHDsr3RZSLX+7DzS+vGTxtdV3p+qP4wwXVj7t5acHQ9yQ==; 24:9doY1RZziz06L4ohEAbPO8QScm4Pnb6im4h3kufuk96aXC6QSG7BIID/iaSqg3sRstUcJR3GttjxO3RC6hO/CO/fhk1tu1BveH8Lsgisi3M=; 7:6vjlpe6pzwOF4iG7/8IBovs8cbP+IBP+BYY+x76vOCXq3QH9XEKTMm7bL8Hk+REvgnog5xknpSe7Z2BpRpPb14QlbEEdK9K+T1x1hoYISvUuCKpTEKON988rFWj8yenUcCWazNRcJbrVTeOPY8kcgEs2iUVIuZl4MLXFhr8BKN36vcjIvGLvG2RKC91SHgB6DPx20iakU5+suE6/pMqNrxMPG/toNhQeLfVm90gnCdk7llFbUNAcze+BvsnqlRhk x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2155; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2155; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2155; x-forefront-prvs: 004395A01C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(377454003)(24454002)(13464003)(33656002)(76176999)(2950100001)(2900100001)(5002640100001)(19580395003)(54356999)(87936001)(101416001)(99286002)(105586002)(189998001)(77096005)(81166006)(7736002)(74316002)(50986999)(7846002)(4326007)(305945005)(7696003)(19580405001)(8676002)(3660700001)(86362001)(2906002)(122556002)(11100500001)(92566002)(81156014)(68736007)(102836003)(8936002)(76576001)(9686002)(106356001)(5660300001)(10090500001)(5005710100001)(10400500002)(8990500004)(10290500002)(6116002)(3280700002)(86612001)(5001770100001)(93886004)(97736004)(106116001)(586003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2155; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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 Aug 2016 23:35:27.8167 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2155 Archived-At: Cc: "unbearable@ietf.org" , Brian Campbell , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 23 Aug 2016 23:35:33 -0000 QmVjYXVzZSB0aGUgbGFzdCB0aW1lIHdlIGFza2VkIGZvciBhIHRlbXBvcmFyeSBJQU5BIGFzc2ln bm1lbnQsIGl0IHRvb2sgbW9udGhzLiBXZSBuZWVkIGEgdmVyc2lvbiBuZWdvdGlhdGlvbiBtZXRo b2QgdGhhdCBhbGxvd3MgdXMgdG8gcXVpY2tseSBpbXBsZW1lbnQgYW5kIGRlcGxveSBUQiBkcmFm dHMuICBVbnRpbCBub3csIGl0IGhhcyBiZWVuIHRoZSB0b2tlbl9iaW5kaW5nX3ZlcnNpb24gZmll bGQgaW4gdGhlIHRva2VuX2JpbmRpbmcgZXh0ZW5zaW9uLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0 bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dIA0KU2VudDogVHVlc2RheSwgQXVndXN0IDIzLCAy MDE2IDQ6MjEgUE0NClRvOiBOaWNrIEhhcnBlciA8bmhhcnBlckBnb29nbGUuY29tPg0KQ2M6IEFu ZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+OyBCaWxsIENveCA8d2F5d2Fy ZGdlZWtAZ29vZ2xlLmNvbT47IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5 LmNvbT47IHVuYmVhcmFibGVAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gVExT IGV4dGVuc2lvbjogdmVyc2lvbiBmaWVsZA0KDQpPbiAyNCBBdWd1c3QgMjAxNiBhdCAwMzo1Miwg TmljayBIYXJwZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbT4gd3JvdGU6DQo+IEZvciBkcmFmdCAwLjks IHdlIGNvdWxkIHVzZSBhbiBleHBlcmltZW50YWwgVExTIGV4dGVuc2lvbiBudW1iZXIsIG9yIA0K PiB3ZSBjb3VsZCB1c2UgMjQgZm9yIFRCLCBhbmQgc2VuZCBhbiBhZGRpdGlvbmFsIGV4dGVuc2lv biB0byBpbmRpY2F0ZSANCj4gdGhlIGRyYWZ0IHZlcnNpb24gKGxpa2UgaG93IFRMUyAxLjMgaXMg ZG9pbmcgd2l0aCAweGZmMDIpLg0KDQoNCldoeSBub3QgdXNlIHRoZSBjdXJyZW50IG51bWJlciB1 bnRpbCB5b3UgbWFrZSBhIGJyZWFraW5nIGNoYW5nZSAoYXMgSSBzdWdnZXN0ZWQgdGhhdCB5b3Ug ZG8pLCB0aGVuIGxldCBJQU5BIGhhdmUgdGhlIG51bWJlciBiYWNrIGFuZCB1c2UgYSBuZXcgb25l IGVhY2ggdGltZSB5b3UgbmVlZCB0byBtYWtlIGEgYnJlYWtpbmcgY2hhbmdlLg0K From nobody Tue Aug 23 17:01:51 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 0CA9A12DBFF for ; Tue, 23 Aug 2016 17:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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; domainkeys=pass (1024-bit key) header.sender=andreipo=microsoft.com@github.com 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 QDqE_MktN8ez for ; Tue, 23 Aug 2016 17:01:48 -0700 (PDT) Received: from m69-169.mailgun.net (m69-169.mailgun.net [166.78.69.169]) (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 3FD2612D83E for ; Tue, 23 Aug 2016 17:01:48 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1471996907; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=ZgYLUZhjabQiKHIhZQd/yGgC5fJXz9GHLTNvdw+Pqvw=; b=ODqLyNHwAYaomp3PaDC/0CWJLi1r6VHJoMsaSpD8JrvRCilLilIOn0JzM1Dhbye9NjlKXe/q i7M3054/5Job7dDNK5fcWtgUunFZzgGXi7zwsVMwvKf+CD+BaIc2P777jNkHmjS2Flm/NIxo DCXVx51anSdOiapM3FwJsqB7j+8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=NJVGivuA5NDQ/W1l3LykWn7FpsuCrVA2l9cdCnCmQ03ViHPHUm8lrGj1FdFmDEBf7Ak/F+ f6dRUIa7KcrwRXDCBZLBPIrxnFLLTsqdAi9SA3ksLRWX5WxQm/WtN7Vp1oRESYpIgk1O6b6h B4TnBBQrtRPtcMoBe0a5d8ekHdqsQ= Sender: andreipo=microsoft.com@github.com X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Received: from github.com (Unknown [192.30.252.34]) by mxa.mailgun.org with ESMTP id 57bce3ea.7f218439d0c0-in3; Wed, 24 Aug 2016 00:01:46 -0000 (UTC) Date: Tue, 23 Aug 2016 17:01:45 -0700 From: Andrei Popov To: unbearable@ietf.org Message-ID: <57bce3e9cb688_77c23f99bcdd71347791@hookshot-fe2-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_57bce3e9cb22c_77c23f99bcdd7134778a2"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] bc9182: IANA did early assignment of 24 for the token_bind... X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Andrei Popov 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, 24 Aug 2016 00:01:50 -0000 ----==_mimepart_57bce3e9cb22c_77c23f99bcdd7134778a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: bc918294273158983de57910b8ff1da716eeeaa7 https://github.com/TokenBinding/Internet-Drafts/commit/bc918294273158983de57910b8ff1da716eeeaa7 Author: Brian Campbell Date: 2016-08-02 (Tue, 02 Aug 2016) Changed paths: M draft-ietf-tokbind-negotiation-03.xml Log Message: ----------- IANA did early assignment of 24 for the token_binding TLS extension so TBNEGO can and should use it (borrowed language from the IANA Considerations of RFC 7627) Commit: e0bcce6e8bbf215be3fb434c1cc69a93c9765b66 https://github.com/TokenBinding/Internet-Drafts/commit/e0bcce6e8bbf215be3fb434c1cc69a93c9765b66 Author: Andrei Popov Date: 2016-08-23 (Tue, 23 Aug 2016) Changed paths: M draft-ietf-tokbind-negotiation-03.xml Log Message: ----------- Merge branch '24' of https://github.com/b---c/Internet-Drafts into b---c-24 Commit: 6869c240c1e53d272165e897106a23f3b6b5dff8 https://github.com/TokenBinding/Internet-Drafts/commit/6869c240c1e53d272165e897106a23f3b6b5dff8 Author: Andrei Popov Date: 2016-08-23 (Tue, 23 Aug 2016) Changed paths: M draft-ietf-tokbind-negotiation-03.xml Log Message: ----------- Merge branch 'b---c-24' Commit: 89c56205d7659519f013a0a6174058409bfdac2b https://github.com/TokenBinding/Internet-Drafts/commit/89c56205d7659519f013a0a6174058409bfdac2b Author: Andrei Popov Date: 2016-08-23 (Tue, 23 Aug 2016) Changed paths: M README.md R draft-ietf-tokbind-negotiation-03.xml A draft-ietf-tokbind-negotiation-04.xml Log Message: ----------- Merging PR #58 Compare: https://github.com/TokenBinding/Internet-Drafts/compare/d9b65d3bad15...89c56205d765 ----==_mimepart_57bce3e9cb22c_77c23f99bcdd7134778a2-- From nobody Tue Aug 23 17:09: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 4010012DBC0 for ; Tue, 23 Aug 2016 15:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 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_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 kjuSWySYOe5F for ; Tue, 23 Aug 2016 15:15:44 -0700 (PDT) Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext8.iad.github.net [192.30.252.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F14DB12DB9A for ; Tue, 23 Aug 2016 15:15:43 -0700 (PDT) Date: Tue, 23 Aug 2016 15:15:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471990542; bh=c9qXVariTlfPUhmork+MGsr8x3mFdRVveTfBKl6f+K8=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=iug8DI7Iz+ebDeCcwejmoD5pdVLvp32nTH1LmBHX49aYk9pXp8JCTZYOkfADlOY2R hpeYOOrtH03ajZ+BkTRIrvsON9A0oJOzd4qHAY8mryXE8WcYnQq9CZQvC8fJom/8wd rwq0vvuAuRKshCIB/iqI/hYF20U3rWlLrQbpwKEg= From: Andrei-Popov To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57bccb0ee4cdd_21cd3ff02371f2c0113164"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: Andrei-Popov X-GitHub-Recipient: unbearable-ML X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Tue, 23 Aug 2016 17:09:19 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: Clarify that base64url encoding means no padding. (#56) 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: Tue, 23 Aug 2016 22:15:45 -0000 ----==_mimepart_57bccb0ee4cdd_21cd3ff02371f2c0113164 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Closed #56. -- 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/56#event-765206077 ----==_mimepart_57bccb0ee4cdd_21cd3ff02371f2c0113164 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Closed #56.

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

----==_mimepart_57bccb0ee4cdd_21cd3ff02371f2c0113164-- From nobody Tue Aug 23 17:09:24 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 0E54312DBB3 for ; Tue, 23 Aug 2016 15:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.382 X-Spam-Level: X-Spam-Status: No, score=-5.382 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_24=1.618, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 q-xVQDek6o13 for ; Tue, 23 Aug 2016 15:15:44 -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 F2AF912DBBC for ; Tue, 23 Aug 2016 15:15:43 -0700 (PDT) Date: Tue, 23 Aug 2016 15:15:42 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1471990542; bh=Hztu2w1ulYg70uqRG0xYYErCcE4srzfRsmz6nHGY7ZA=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=0zuLMu07FHM9TpCXVxb3go4pBTNtuUZ3Grjp5ff4VbBifgAFfrbINyewsu3RmNAQr WSan/g1DZhqxTVQhYzvSeN1zpvLJf40KCA41vO96oIZQkxksCe4sM6OWYIkcnmla5z RxxxqAfXRzLPqU0C7lH36ktRyFZOo3xljzyZ93DM= From: Andrei-Popov To: TokenBinding/Internet-Drafts Message-ID: In-Reply-To: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="--==_mimepart_57bccb0edcb61_3e953fd18c81f2c02878c9"; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: list X-GitHub-Sender: Andrei-Popov X-GitHub-Recipient: unbearable-ML X-Auto-Response-Suppress: All X-GitHub-Recipient-Address: unbearable@ietf.org Archived-At: X-Mailman-Approved-At: Tue, 23 Aug 2016 17:09:19 -0700 Subject: Re: [Unbearable] [TokenBinding/Internet-Drafts] HTTPSTB: Clarify that base64url encoding means no padding. (#56) 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: Tue, 23 Aug 2016 22:15:46 -0000 ----==_mimepart_57bccb0edcb61_3e953fd18c81f2c02878c9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Fixed by merging PR #57. -- 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/56#issuecomment-241897809 ----==_mimepart_57bccb0edcb61_3e953fd18c81f2c02878c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit

Fixed by merging PR #57.

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

----==_mimepart_57bccb0edcb61_3e953fd18c81f2c02878c9-- From nobody Tue Aug 23 17:12: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 AFC1312D0CD for ; Tue, 23 Aug 2016 17:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 mJhMigEIQAL5 for ; Tue, 23 Aug 2016 17:12:51 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0117.outbound.protection.outlook.com [104.47.33.117]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E09712B03F for ; Tue, 23 Aug 2016 17:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kNUJuS+YCfBfGVi9+IN0qp/TdNr4D7QLBuYwDdp5Gk0=; b=Q426RcBzmMLG5Q9gsertNaSwpTw0uiXevhGx5CcT4mb8R38fuCIa5vrjBKY2lXRiIL6UqzxnKvmqqCUTXbS7FMz8/FTj11OSfJ574NImht8JsBtVYdcTx3ROIEtMRYoRerFLKtVSmLA9fn02TY2VCn08NM9AuwUwUsRSS12KGL8= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Wed, 24 Aug 2016 00:12:48 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0587.013; Wed, 24 Aug 2016 00:12:48 +0000 From: Andrei Popov To: "unbearable@ietf.org" Thread-Topic: TB I-Ds Updated Thread-Index: AdH9m+iMpJE+K70yR6KGZ3lyc3qe+g== Date: Wed, 24 Aug 2016 00:12:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: 9b57ab13-73d5-46d0-02d8-08d3cbb361aa x-microsoft-exchange-diagnostics: 1; CY1PR03MB2155; 6:cevHMosl4tntlnNhT1XSFtM5Vo8qgk4GbrSfS+7nwuw5ri9Pi4Mt7yypRKjy3VDfL7BtPdOOCcO85pUpBUs7GYcdtGZjxhPpmevHufOc8Kt4HsQGrkpMWhHI9n0cwn1Y5iTy9SwgZyqNvjw7Sb1pXtVn0u9zXJkxyTYhQvWeqGjB0RjG7rGHhuYQG7yr6q7jPbvsNoEJZG8b+SvpAi3y8JRnZHKkq1+1KPMhDAg6iNVHttoh2gv2mnq6H3FsqRybkWJrEtlMShWSsJyOGUFymWm8BMmY7xCPqiyfaLchwX2ByTiSSg6XY8Vytl5/OBgDrxWgzeagt1kz75ny8Kmg+Q==; 5:28r8L/98rWc7RgKNE83uX8KGkSnQWWc29UxbPkx7lc+ewPhBCrq/lktVfZQLsOt998NKtsFKEj3tJJvgr/Pa9OB0nJSZE6Xridl1Hlqi8llyxnrfoLVCT1/3VznjvbpRa3XrWYYIfok8hKSl7+vBjQ==; 24:v9DNd9+3jRGP3QY6ZGJRMSdiOsZ/KPb9hbHGx7I01NtfTpgt5MdSJ5+EyiR3Adr+p4X7nb87wmIbEqwqdI8InpiZRCnCfCPXuWijtalaBs8=; 7:MZsW4Hz6bclJTmGriZJ9fRxM79EYnj3sv2xGA6MbsvQlOqDfvU5LHJG17GgLgxfIDCyxOPZNStEpiMGXYANaV7hAjYcQhBzMWi4qctg2d0Y3PlpQWBI1s+n/V2VsJV6u0ddU6kacGUQxE9Y3FzC1TGs3DOESPikd0tgBnCwzkxLKQ0cee8rGnr+XKG9Qlf7Q0K4cdCt3FLr+4TadChNoftnaf8QC8qBKQezzJ8zN8THswXRZGoR/3+9gvDEo2Jzf x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2155; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2155; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2155; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(2420400007)(33656002)(2900100001)(5002640100001)(19580395003)(54356999)(7110500001)(87936001)(16236675004)(5630700001)(19625215002)(101416001)(99286002)(5640700001)(15975445007)(105586002)(189998001)(77096005)(81166006)(7736002)(7906003)(74316002)(50986999)(7846002)(1730700003)(2501003)(7696003)(19300405004)(558084003)(8676002)(3660700001)(2906002)(86362001)(122556002)(15650500001)(11100500001)(81156014)(68736007)(92566002)(102836003)(450100001)(8936002)(3480700004)(76576001)(9686002)(106356001)(10710500007)(5660300001)(10090500001)(5005710100001)(10400500002)(8990500004)(790700001)(10290500002)(6116002)(3280700002)(86612001)(19617315012)(97736004)(107886002)(110136002)(2351001)(586003)(229853001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2155; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB21554232D296CF0700B7B04F8CEA0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 00:12:48.5246 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2155 Archived-At: Subject: [Unbearable] TB I-Ds Updated 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, 24 Aug 2016 00:12:54 -0000 --_000_CY1PR03MB21554232D296CF0700B7B04F8CEA0CY1PR03MB2155namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable An update: I've merged all 3 PRs, now working through the open issues on Gi= tHub. The latest editor's drafts are available on GitHub. Cheers, Andrei --_000_CY1PR03MB21554232D296CF0700B7B04F8CEA0CY1PR03MB2155namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

An update: I’ve merged all 3 PRs, now working = through the open issues on GitHub. The latest editor’s drafts are available on Gi= tHub.

 

Cheers,

 

Andrei

--_000_CY1PR03MB21554232D296CF0700B7B04F8CEA0CY1PR03MB2155namp_-- From nobody Tue Aug 23 17:17:23 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 9BC0E12D1B7 for ; Tue, 23 Aug 2016 17:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 CAMsM7GaQF8w for ; Tue, 23 Aug 2016 17:17:21 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 0A56D12D189 for ; Tue, 23 Aug 2016 17:17:21 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id n59so1614847uan.2 for ; Tue, 23 Aug 2016 17:17:20 -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=v2yDjPr58NN1tV2nV6IH41pbu2ORehj5p2oa9XGaN4Q=; b=CWPf4al7bgPYp9EnQCn/BWZYchKmFlxtL7wIJ2fOY+PAYW6GkbcDek4y18KedrSJ9+ 4SxXI6gugLEVKah76v7MrrWN9u4SA/EvXXbLlo9kP+O+pjrwFHjL8tn3wJ8KBeHd4E5N iZGxCj+JpF2LBt1nFSzCANr7Zb6xSbfHb0D33ihCc78Tue2qOSNA7dS8SGZQN767I1ja Qq85zQkdID3le3+d1GP7stbUmPxDwUYh1SqnDR3PWxcGD07ORMq5cHtMHzK0DJtXbyP6 ZhPxIeZ5XvXNQWB5dbVtiWltyGxVViJucclIaGSipdzUYERUX7vR6tjvD2D4XkFS/OrW 5NLg== 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=v2yDjPr58NN1tV2nV6IH41pbu2ORehj5p2oa9XGaN4Q=; b=Y8um9YigOrV0K3lmYFYxwkFsZQp0/guj/BjECnQIqMRU0TM3GHt03o9aYJuBYeTiPX gfQudjZ/CEANzm3JaY5QxOXtNnC98ZkvujX13APlUFh2Jjz55qlR1zp/YHbZsYC+vtqk s6FsFkH/3lYQUoSMCZgq2IEsOlhvnp/t+ob94rDS0ljnZ4gWXo0lUG0D46/voVQ4rx4z JzeawypSfB+mOcRWyXjzesAbQQc8ZlnslJ/gZQ1JYm5mPhv1xh4CZid9qWgV1gCoqVxY /zpSWbic6iG/jOJnt+uCbXRaH9w/iJNThXUGY1r9xNUPMP9tlLqEjYzzS0bEyIX1E7sy rTIw== X-Gm-Message-State: AEkooutBrOTNnYErdwU2QJcvQh1r9XzxzjSvg9o8DWytvfGjf+go7ZftNhblNBq4C3BXC3cXNE03R8MJP27fevKB X-Received: by 10.31.156.136 with SMTP id f130mr74300vke.45.1471997839364; Tue, 23 Aug 2016 17:17:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.209 with HTTP; Tue, 23 Aug 2016 17:16:58 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Tue, 23 Aug 2016 17:16:58 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a1140f58c53aedd053ac634f4 Archived-At: Cc: "unbearable@ietf.org" , Brian Campbell , Martin Thomson , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 24 Aug 2016 00:17:22 -0000 --001a1140f58c53aedd053ac634f4 Content-Type: text/plain; charset=UTF-8 I don't think that trying to get a new IANA-assigned number for each draft version that has breaking changes is a very practical approach. On Tue, Aug 23, 2016 at 4:35 PM, Andrei Popov wrote: > Because the last time we asked for a temporary IANA assignment, it took > months. We need a version negotiation method that allows us to quickly > implement and deploy TB drafts. Until now, it has been the > token_binding_version field in the token_binding extension. > > Cheers, > > Andrei > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Tuesday, August 23, 2016 4:21 PM > To: Nick Harper > Cc: Andrei Popov ; Bill Cox < > waywardgeek@google.com>; Brian Campbell ; > unbearable@ietf.org > Subject: Re: [Unbearable] TLS extension: version field > > On 24 August 2016 at 03:52, Nick Harper wrote: > > For draft 0.9, we could use an experimental TLS extension number, or > > we could use 24 for TB, and send an additional extension to indicate > > the draft version (like how TLS 1.3 is doing with 0xff02). > > > Why not use the current number until you make a breaking change (as I > suggested that you do), then let IANA have the number back and use a new > one each time you need to make a breaking change. > --001a1140f58c53aedd053ac634f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't think that trying to get a new IANA-assigned n= umber for each draft version that has breaking changes is a very practical = approach.

On= Tue, Aug 23, 2016 at 4:35 PM, Andrei Popov <Andrei.Popov@micro= soft.com> wrote:
Because = the last time we asked for a temporary IANA assignment, it took months. We = need a version negotiation method that allows us to quickly implement and d= eploy TB drafts.=C2=A0 Until now, it has been the token_binding_version fie= ld in the token_binding extension.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:ma= rtin.thomson@gmail.com]
Sent: Tuesday, August 23, 2016 4:21 PM
To: Nick Harper <nharper@google.co= m>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Bill Cox <<= a href=3D"mailto:waywardgeek@google.com">waywardgeek@google.com>; Br= ian Campbell <bcampbell@pi= ngidentity.com>; unbearable@i= etf.org
Subject: Re: [Unbearable] TLS extension: version field

On 24 August 2016 at 03:52, = Nick Harper <nharper@google.com> wrote:
> For draft 0.9, we could use an experimental TLS extension number, or > we could use 24 for TB, and send an additional extension to indicate > the draft version (like how TLS 1.3 is doing with 0xff02).


Why not use the current number until you make a breaking change (as I sugge= sted that you do), then let IANA have the number back and use a new one eac= h time you need to make a breaking change.

--001a1140f58c53aedd053ac634f4-- From nobody Tue Aug 23 17:42:11 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 BE18712D0FA for ; Tue, 23 Aug 2016 17:42:09 -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, FREEMAIL_FROM=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 (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 g4ON26dN_lVe for ; Tue, 23 Aug 2016 17:42:08 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::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 AEFCC12D53B for ; Tue, 23 Aug 2016 17:42:08 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id z190so1355686qkc.0 for ; Tue, 23 Aug 2016 17:42:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ahy+ZfQoSCUTdp3N9HFrbd7Aq1csRFobMkPtEsuANgg=; b=ygqoXulfOTpTaXRsrpE/kS37TgA7EnL3pKiYqFf/jkUoCsQvbbPO1ZeGJf6VREDsP0 l1XxmlREQoNIg8HXnc1a54tMBWvuSVS0PgmBrYxIYWYO/ISblG4UTDd/2oo0rhWQvaA2 w/xLft5w0UV+4PviHkjjJYVWemUXy7J2GepvCfPNw/L1mLSvd7qSU+qOW/8W3qS4WPcW ESyVvI638NdPLay+F96G13g5hO+P+gWjD50W5INLeoH3UTPA4u9PwIXdLOQYFO+wZDT9 WNC3M0iJhaensyYJsG0dr/2lQ/lrd7sY8bAzfeOSko3Rhp8b6UMY7U9mwz1oXPDEfjn7 xJRg== 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=ahy+ZfQoSCUTdp3N9HFrbd7Aq1csRFobMkPtEsuANgg=; b=INb7sKcT0gvOAeuhOqKYy/c0FAEwMd5darQgFC2XT2srzCbMTbaI1GlUDFuWo8p+WF E39uptdilLSzfvybMYwjH+SvhsWtJPRkq/MFVG95mKS3zjvPmGI1GEGjKqB/1K/3+l0Y La0P/h8F43rDwrRevDeTL5gj+rHnc0TYFqxUCcgr71zxL9EF6ZhJXMDzXLRKXsg0qllv VThpQU8hHo+4mg1+/mNl7VhJVbk0kwWvdTJYIV+/beCsBRUPaWlNZso/RKb09EeNmwL8 WXXq/vSqcoBNJX52k8U4VR4j/fYnoUkEG5DGVYqX+SxnqyjDy1rw6CL5ASqexbECb8mA w+FA== X-Gm-Message-State: AE9vXwMPq8bYZ0YvoLhVhsPUCoiAD+EovWKTPszmYtsoRFllBbfiDjb7tQqw9xmlaFeVIN+veEXH7xclVugGhw== X-Received: by 10.55.165.65 with SMTP id o62mr290068qke.282.1471999327915; Tue, 23 Aug 2016 17:42:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Tue, 23 Aug 2016 17:42:07 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 24 Aug 2016 10:42:07 +1000 Message-ID: To: Nick Harper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Andrei Popov , Brian Campbell , "unbearable@ietf.org" , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 24 Aug 2016 00:42:09 -0000 On 24 August 2016 at 10:16, Nick Harper wrote: > I don't think that trying to get a new IANA-assigned number for each draft > version that has breaking changes is a very practical approach. Were you planning on breaking things often? More seriously, most other user users of this space just grab a number and use it. Then they tell IANA when they finish with their experiments. If you think that you need to change more often, the new experimental use space is probably a better idea. From nobody Tue Aug 23 21:35: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 EF30A12B069 for ; Tue, 23 Aug 2016 21:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 Ae9ixSzELr-S for ; Tue, 23 Aug 2016 21:35:56 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 6D90312B028 for ; Tue, 23 Aug 2016 21:35:56 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id k90so9065928uak.1 for ; Tue, 23 Aug 2016 21:35:56 -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=JhJ5dPoFtE9/wJ2tef3PKJtt/pZs6YePgtnXyfm4uX8=; b=U5WzaAuReL+pQc4xCXa2PviJ/vtI1TBsTs+kzOP+2Be8ZUI+se0ycVcG0IA9IVE469 kHQfPwLrXqPxV/Uoq/kOXxSAomIgWAy5Oo/4PkwL3y/zHZG5cxnh4l6vpGG4aTbcm7V/ 51TQr5StTeFQlVULQt/glIHpz03zn8vQaj/3GOJina/JYjYJaAZtGYggz7BzNDumfbvS OdP8MwKe+MzqlV51kc/GUnI4PUhdmki1q7xrnCUFrYSYlnXcIEg4UrL+QGyh7OIkeTmI ZxVoPI1TR7X2frdus8uRcoa/cvmOk/fWKkIXfTbbGqf7ash31GlQFDaNttS9AwIlWHai eMfw== 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=JhJ5dPoFtE9/wJ2tef3PKJtt/pZs6YePgtnXyfm4uX8=; b=V/gTbN2zMFVpjO+EkoUnRORb5u86uNiafZpdUCBk931CmiSaWkUiUf4zts+9+L+vOR GYf/7kJUmxFY+FgdO30hy1j+avbg517LOOzasmqqFMkRBJIIr+/+xEyFk/1kdHVZjg4H BU5DnQfgRQZ+pQc4DBgSmUWvr3i749KR0+jaNdrDo4JrwKMXlc5+ywjTmWcmTQ81U6c7 c3C2A2A0QgN9QWBjR+VOKwFj5rD5tiB2pTJ2MRTX34QExc7bsYtuTa99OJe0Lql9I2pY fypT5RdTnC2PpVQOrH9BUc9m05FadoZlkc8byjnQA90bhR0LJTPuTTSttoSlGIOmhwXV rSWQ== X-Gm-Message-State: AEkoouuTH0rl7EZO5gr/QlyerMYpsyIL9KmTZHBPiYK5ev+ZyoXWTFis2jHwoo0CdPcsC+sX+ZJAacgaM8PqqE3G X-Received: by 10.31.180.214 with SMTP id d205mr589291vkf.140.1472013355331; Tue, 23 Aug 2016 21:35:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.97.2 with HTTP; Tue, 23 Aug 2016 21:35:54 -0700 (PDT) In-Reply-To: References: From: Bill Cox Date: Tue, 23 Aug 2016 21:35:54 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1143900a267edf053ac9d142 Archived-At: Cc: Andrei Popov , Brian Campbell , "unbearable@ietf.org" , Nick Harper Subject: Re: [Unbearable] TLS extension: version field 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, 24 Aug 2016 04:35:58 -0000 --001a1143900a267edf053ac9d142 Content-Type: text/plain; charset=UTF-8 I think I see a correlation here: those of us who have worked to build functional token binding implementations would prefer not to throw the cards in the air and with major changes, such as eliminating the version. There are times for innovation, but near the end of a standardization process is not one of them, IMO. At this point, I would rather see compatible bug-free implementations. I'll throw my vote in with Nick and Andrei for moving ahead without changing versioning. It may not be optimal, but it is good enough. This is not an issue worth delaying the roll-out of token binding. Bill On Tue, Aug 23, 2016 at 5:42 PM, Martin Thomson wrote: > On 24 August 2016 at 10:16, Nick Harper wrote: > > I don't think that trying to get a new IANA-assigned number for each > draft > > version that has breaking changes is a very practical approach. > > Were you planning on breaking things often? > > More seriously, most other user users of this space just grab a number > and use it. Then they tell IANA when they finish with their > experiments. > > If you think that you need to change more often, the new experimental > use space is probably a better idea. > --001a1143900a267edf053ac9d142 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think I see a correlation here: those of us who have wor= ked to build functional token binding implementations would prefer not to t= hrow the cards in the air and with major changes, such as eliminating the v= ersion.=C2=A0 There are times for innovation, but near the end of a standar= dization process is not one of them, IMO.=C2=A0 At this point, I would rath= er see compatible bug-free implementations.=C2=A0 I'll throw my vote in= with Nick and Andrei for moving ahead without changing versioning.=C2=A0 I= t may not be optimal, but it is good enough.=C2=A0 This is not an issue wor= th delaying the roll-out of token binding.

Bill

On Tue, Aug 23= , 2016 at 5:42 PM, Martin Thomson <martin.thomson@gmail.com>= wrote:
On 24 Aug= ust 2016 at 10:16, Nick Harper <nh= arper@google.com> wrote:
> I don't think that trying to get a new IANA-assigned number for ea= ch draft
> version that has breaking changes is a very practical approach.

Were you planning on breaking things often?

More seriously, most other user users of this space just grab a number
and use it.=C2=A0 Then they tell IANA when they finish with their
experiments.

If you think that you need to change more often, the new experimental
use space is probably a better idea.

--001a1143900a267edf053ac9d142-- From nobody Wed Aug 24 07:35: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 4ED1E12D7D9 for ; Wed, 24 Aug 2016 07:35:43 -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, 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 oR_QFIvSyTCR for ; Wed, 24 Aug 2016 07:35:38 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 CEDFA12DDEC for ; Wed, 24 Aug 2016 07:33:37 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id e63so212900641ith.1 for ; Wed, 24 Aug 2016 07:33:37 -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=qGs3LCwQm3EAk+8pnFru5pQL+LDFXQS5rZEf7EuIjlQ=; b=eAD6IdhmIe0KcXTTPj7C5IGXYxCNYU+iAZrKoLRoa4uhLEJMQfUQO0+sOYGbKeAHIc 8x9qfKHltmkCqFP8k9X2NPPeruI/0aCFU6m/15znhDJ8gDElglwrQtK6rPYLR8PMb7nI 45lxL2Ab6DPeyGA3rxaufuzsXtFNsCZ8LSooQ= 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=qGs3LCwQm3EAk+8pnFru5pQL+LDFXQS5rZEf7EuIjlQ=; b=Ktd+t0PDPqbvW62z2BvhLpNB98vrIk/TmfpnpxVl1sdwj8mMSvXiBlMaast46FmIZM P0xhkvXFgnVHmP3fgqzQQxh7lBZRwGfoEwcp9FYqE6dh2zEBwp9UsxBGwWhrvKXCwMln H7rYjWHWRXYDBZTcM9lPXxHC59d3HCwY8thWMYBC32HM64USzceOUtRzT7DSmZnWMjW8 NYwu3MyP1IJeZliOqh+qMU9QtBKYbGMNxzfWLafhMh1MwLBRnWPYrISnKyYw3oxpe22t Ve1CDnSlm7OJuBKFeTqPDpJ+IpWgli13t3+w3OO6/3evCVTsiV2WDkHnI/tC7pUUIosI GMBQ== X-Gm-Message-State: AEkoouuYUZUBr9ZC2P+BoW6K87ctIImHUEG3vs21kRe+kZW4rSIDGEkUxn6TVhz8FkMvmLhqwrToWRF1FaLO9vTa X-Received: by 10.107.8.140 with SMTP id h12mr4515861ioi.95.1472049217010; Wed, 24 Aug 2016 07:33:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Wed, 24 Aug 2016 07:33:06 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 24 Aug 2016 08:33:06 -0600 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113fb6b0ac313a053ad22a26 Archived-At: Cc: "unbearable@ietf.org" Subject: Re: [Unbearable] TLS extension: version field 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, 24 Aug 2016 14:35:43 -0000 --001a113fb6b0ac313a053ad22a26 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 23, 2016 at 6:42 PM, Martin Thomson wrote: > > Were you planning on breaking things often? > > Well, to be fair here, you have proposed several breaking changes recently. --001a113fb6b0ac313a053ad22a26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Aug 23, 2016 at 6:42 PM, Martin Thomson <martin.thomson@gma= il.com> wrote:

Were you planning on breaking things often?


Well, to be fair here, you have proposed several breaking c= hanges recently.
=C2=A0
--001a113fb6b0ac313a053ad22a26-- From nobody Wed Aug 24 10:06: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 8F21E12D5FD for ; Wed, 24 Aug 2016 10:06:41 -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 KyUbLrfFwL1f for ; Wed, 24 Aug 2016 10:06:40 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 3F11C12D5D0 for ; Wed, 24 Aug 2016 10:06:40 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id n128so45398142ith.1 for ; Wed, 24 Aug 2016 10:06:40 -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=cB4ZOEGVpsNuMrBHVjNGb884Lb4TxihwcuYk0nasvUs=; b=a4E4yMDNT3FeJf0iDUeGpfvRZ5IdxdBG2yPxrVHqFvLX5kykq8Ydzup/aAuaF96ikP XWzhp5RRijFKZ3BVpk2qr3my76D2EhAVj+EOF/xtucPmhd8gcQtukwb031lqaSmFCrPU 17yzZ2KGXuNi1IRTFbdrz7cF/97HAW3HPBY/A= 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=cB4ZOEGVpsNuMrBHVjNGb884Lb4TxihwcuYk0nasvUs=; b=Pwjg7+timeFmgkqP26i9dn8UIBS1aZVfGsXCaqQNymvnQTiWzDRGF/E1Y5KQ5S6c4e YBqAUuMlN/1Zl5v/iqANZD6NknoMDUfzvrGueQsZlo8PwJIO/OpVKTfLVvMza+BzXYIt gOtS1RgYE19pFf7Tt/z16yDDnpD7oQCcEQNu8+j3LlXzoWUPtxcvhm6AdAWJ0tc4Lebe sywxAfGA5e3HVvoiddpOmqUIw7Kzb1ARiOS49GKOKUVKBls9jOWVf87/bU5Mg+2G3hr4 9zI/EL/sNyE4+htYYa3Z7ork+22Rlk8jVObbYmowI9KFT1lAV7XVC3v0ggIs05u0irxU fYQQ== X-Gm-Message-State: AEkooutPNg37jbjjW5qQmXyjXuoERLOYqHAjrbUIdh0/clWb2nMeen9I5ZYb/mkRLSycWBm8FxZ+S/+im+K6PTRD X-Received: by 10.36.3.76 with SMTP id e73mr47953ite.42.1472058399560; Wed, 24 Aug 2016 10:06:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.123.14 with HTTP; Wed, 24 Aug 2016 10:06:08 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 24 Aug 2016 11:06:08 -0600 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a11419940feb53c053ad44d19 Archived-At: Cc: Andrei Popov , Martin Thomson , "unbearable@ietf.org" , Nick Harper Subject: Re: [Unbearable] TLS extension: version field 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, 24 Aug 2016 17:06:41 -0000 --001a11419940feb53c053ad44d19 Content-Type: text/plain; charset=UTF-8 I shouldn't speak for him but, from previous statements in this thread, it sounded like Nick is in favor of eliminating the version. I do think that the question of eliminating the token_binding_version or not should be considered independently of if/how the draft version can be communicated for testing prior to the spec(s) finalizing. On Tue, Aug 23, 2016 at 10:35 PM, Bill Cox wrote: > I think I see a correlation here: those of us who have worked to build > functional token binding implementations would prefer not to throw the > cards in the air and with major changes, such as eliminating the version. > There are times for innovation, but near the end of a standardization > process is not one of them, IMO. At this point, I would rather see > compatible bug-free implementations. I'll throw my vote in with Nick and > Andrei for moving ahead without changing versioning. It may not be > optimal, but it is good enough. This is not an issue worth delaying the > roll-out of token binding. > > Bill > > On Tue, Aug 23, 2016 at 5:42 PM, Martin Thomson > wrote: > >> On 24 August 2016 at 10:16, Nick Harper wrote: >> > I don't think that trying to get a new IANA-assigned number for each >> draft >> > version that has breaking changes is a very practical approach. >> >> Were you planning on breaking things often? >> >> More seriously, most other user users of this space just grab a number >> and use it. Then they tell IANA when they finish with their >> experiments. >> >> If you think that you need to change more often, the new experimental >> use space is probably a better idea. >> > > --001a11419940feb53c053ad44d19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I shouldn't speak for him but, from previous stat= ements in this thread, it sounded like Nick is in favor of eliminating the = version.

I do think that the question of eliminating the token= _binding_version or not should be considered independently of if/how the dr= aft version can be communicated for testing prior to the spec(s) finalizing= .
=C2=A0

On Tue, Aug 23, 2016 at 10:35 PM, Bil= l Cox <waywardgeek@google.com> wrote:
I think I see a correlation here: those o= f us who have worked to build functional token binding implementations woul= d prefer not to throw the cards in the air and with major changes, such as = eliminating the version.=C2=A0 There are times for innovation, but near the= end of a standardization process is not one of them, IMO.=C2=A0 At this po= int, I would rather see compatible bug-free implementations.=C2=A0 I'll= throw my vote in with Nick and Andrei for moving ahead without changing ve= rsioning.=C2=A0 It may not be optimal, but it is good enough.=C2=A0 This is= not an issue worth delaying the roll-out of token binding.

Bill
=
On Tue, Aug 23, 2016 at 5:42 PM, Martin Thomso= n <martin.thomson@gmail.com> wrote:
On 24 August 2016 at 10:16, Nick Harper <nharper@google.com>= wrote:
> I don't think that trying to get a new IANA-assigned number for ea= ch draft
> version that has breaking changes is a very practical approach.

Were you planning on breaking things often?

More seriously, most other user users of this space just grab a number
and use it.=C2=A0 Then they tell IANA when they finish with their
experiments.

If you think that you need to change more often, the new experimental
use space is probably a better idea.


--001a11419940feb53c053ad44d19-- From nobody Wed Aug 24 10:14: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 9D64D12D5B8 for ; Wed, 24 Aug 2016 10:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 cML8b80tSmnd for ; Wed, 24 Aug 2016 10:14:01 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0095.outbound.protection.outlook.com [104.47.37.95]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 412F312D59F for ; Wed, 24 Aug 2016 10:14:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xo1wn9eeQSK5Wd/Qt5Dl3vandV6ECLgirVQnPrkXXeQ=; b=HJcWAXSVv9vAtZq1xW4v+4MLYC7/soPjGnAw4EoG5pRazAtspgwcpyh13MYd/vWOL0kQFBgHfY9dRP4vUCiohuFsVYPi1xR7D7rkM3ScBUBnxd1wdVUP6Qlg73MiawN0RI4fRVZAHsp8Q3BkqCLaYCbDev2AQXP8+XjTaFyDeVQ= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Wed, 24 Aug 2016 17:13:59 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0587.013; Wed, 24 Aug 2016 17:13:59 +0000 From: Andrei Popov To: Brian Campbell , Bill Cox Thread-Topic: [Unbearable] TLS extension: version field Thread-Index: AQHR8UE0hAr3fGh5LkSos3djbwbcUaA/MmwAgAAmOoCAAAGk8IAAhvMAgAAFqjCAAAO6AIAA6WmAgAATAoCAABJZgIAV3xfwgAATKACAAFvQgIAAAlRwgAANXQCAAAcGgIAAQVIAgADRnQCAAADEgA== Date: Wed, 24 Aug 2016 17:13:58 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: e45ec01e-3530-486c-a9d9-08d3cc42099b x-microsoft-exchange-diagnostics: 1; CY1PR03MB2155; 6:9K8wKnmL9r/XvNL5VzTTPC+Jr7ZGdCGhfL4BMCo6qhriTxxpIICj5howeHLSTIs9QcODsG1RFcM3gZ2S2f/ZqaGz8zPw2JgNI9DEk6zqurri+q8jE3AWcBl8HRs5grUsPf7NbeqWRZE+FRMjjrGPl2lVFlX0AGevs5h7Ouv6cyv//9fzADVm/rZWX97Qyfgqhnc0sHDk+3t4GxCm5/H5+cdrwZrm5JisDL16vISlmIGrEG63Bd7m4/YFXyuo8f1IIReQQhvrD8tVsL68NQcJXswLvioufH8tkmpGRuemxodj0dBD7QWmP6puAIUZkXGtnCeCBf54Ev2PfNiGlxFTww==; 5:TJlvaeAGqtERLrPejWat5/8s8DT/XfyyD9j0HGdSBfSZLfAFXYLHczjM0bOE8ArgAufgSWPIrxw8/XgJTr5Ne5o6fyhc31e8hxwoDy4xtZSAcx2UgbXlpRDG/aoT2kag7m59aeQA7pZl590ePlV3OLEjQ1p08xkOpaRpEXsLDDY=; 24:Xgpkqm2ThXsNafvmv0zVr4OcblEardvQ49sADKLbbboJjEKTNPKCnJoE4Sp9Nrp5nPPwAKBWLbSWfJcKgEQVlYTu1J5JdR70AQqQ4pYnh+A=; 7:GFs4KDSJ+61vtLF9RJ8AHKPMxlOQwNsumpmQOobCARRoakN+IRpkChb3MZ/eE9g87wm90L/7HtuRt2SeeZNkPiJ12kFev92JqeP1yIlQmAjZq1l/BHmCS1wXunftxrgw6H75NQoVyQCF4D7mJGtbYBbUdg2ssOEfYvLVJjuJe6LtgEYxv/iYk14PkE0MrBuVe05ot+COJVd2b0zL5hvmXi3O+2i5QOcIFGhDr6xDmMqFJgCAySH4D/IFTzsRFW+G x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2155; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2155; BCL:0; PCL:0; RULEID:(304825118); SRVR:CY1PR03MB2155; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(377454003)(24454002)(3280700002)(2950100001)(2900100001)(33656002)(76176999)(5002640100001)(19580395003)(189998001)(16236675004)(87936001)(99286002)(101416001)(15975445007)(54356999)(105586002)(19625215002)(7736002)(77096005)(7696003)(50986999)(81166006)(8676002)(7846002)(4326007)(92566002)(19580405001)(19300405004)(81156014)(2906002)(86362001)(3660700001)(11100500001)(74316002)(68736007)(102836003)(8936002)(76576001)(9686002)(5660300001)(10090500001)(122556002)(10290500002)(10400500002)(8990500004)(6116002)(790700001)(106356001)(5005710100001)(5001770100001)(586003)(93886004)(97736004)(106116001)(86612001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2155; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB2155EA41137671898B8B6B0F8CEA0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 17:13:58.7944 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2155 Archived-At: Cc: "unbearable@ietf.org" , Martin Thomson , Nick Harper Subject: Re: [Unbearable] TLS extension: version field 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, 24 Aug 2016 17:14:03 -0000 --_000_CY1PR03MB2155EA41137671898B8B6B0F8CEA0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEkgZG8gdGhpbmsgdGhhdCB0aGUgcXVlc3Rpb24gb2YgZWxpbWluYXRpbmcgdGhlIHRva2Vu X2JpbmRpbmdfdmVyc2lvbiBvciBub3Qgc2hvdWxkIGJlIGNvbnNpZGVyZWQgaW5kZXBlbmRlbnRs eSBvZiBpZi9ob3cgdGhlIGRyYWZ0IHZlcnNpb24gY2FuIGJlIGNvbW11bmljYXRlZCBmb3IgdGVz dGluZyBwcmlvciB0byB0aGUgc3BlYyhzKSBmaW5hbGl6aW5nLg0KU3VyZSwgYXMgbG9uZyBhcyB3 ZSBlbmQgdXAgd2l0aCBhIHZpYWJsZSBkZXNpZ24gdGhhdCBzdXBwb3J0cyBib3RoIGV4cGVyaW1l bnRhdGlvbiBhbmQgcHJvZHVjdGlvbiBkZXBsb3ltZW50LiBBbmQgSSBkb27igJl0IGV4cGVjdCBl eHBlcmltZW50YXRpb24gaW4gdGhpcyBzcGFjZSB0byBzdG9wIG9uY2UgVEIgMS4wIHNwZWNzIGFy ZSBwdWJsaXNoZWTigKYNCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KRnJvbTogQnJpYW4gQ2FtcGJl bGwgW21haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwg QXVndXN0IDI0LCAyMDE2IDEwOjA2IEFNDQpUbzogQmlsbCBDb3ggPHdheXdhcmRnZWVrQGdvb2ds ZS5jb20+DQpDYzogTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IE5p Y2sgSGFycGVyIDxuaGFycGVyQGdvb2dsZS5jb20+OyBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3Bv dkBtaWNyb3NvZnQuY29tPjsgdW5iZWFyYWJsZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtVbmJl YXJhYmxlXSBUTFMgZXh0ZW5zaW9uOiB2ZXJzaW9uIGZpZWxkDQoNCkkgc2hvdWxkbid0IHNwZWFr IGZvciBoaW0gYnV0LCBmcm9tIHByZXZpb3VzIHN0YXRlbWVudHMgaW4gdGhpcyB0aHJlYWQsIGl0 IHNvdW5kZWQgbGlrZSBOaWNrIGlzIGluIGZhdm9yIG9mIGVsaW1pbmF0aW5nIHRoZSB2ZXJzaW9u Lg0KSSBkbyB0aGluayB0aGF0IHRoZSBxdWVzdGlvbiBvZiBlbGltaW5hdGluZyB0aGUgdG9rZW5f YmluZGluZ192ZXJzaW9uIG9yIG5vdCBzaG91bGQgYmUgY29uc2lkZXJlZCBpbmRlcGVuZGVudGx5 IG9mIGlmL2hvdyB0aGUgZHJhZnQgdmVyc2lvbiBjYW4gYmUgY29tbXVuaWNhdGVkIGZvciB0ZXN0 aW5nIHByaW9yIHRvIHRoZSBzcGVjKHMpIGZpbmFsaXppbmcuDQoNCg0KT24gVHVlLCBBdWcgMjMs IDIwMTYgYXQgMTA6MzUgUE0sIEJpbGwgQ294IDx3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPG1haWx0 bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPj4gd3JvdGU6DQpJIHRoaW5rIEkgc2VlIGEgY29ycmVs YXRpb24gaGVyZTogdGhvc2Ugb2YgdXMgd2hvIGhhdmUgd29ya2VkIHRvIGJ1aWxkIGZ1bmN0aW9u YWwgdG9rZW4gYmluZGluZyBpbXBsZW1lbnRhdGlvbnMgd291bGQgcHJlZmVyIG5vdCB0byB0aHJv dyB0aGUgY2FyZHMgaW4gdGhlIGFpciBhbmQgd2l0aCBtYWpvciBjaGFuZ2VzLCBzdWNoIGFzIGVs aW1pbmF0aW5nIHRoZSB2ZXJzaW9uLiAgVGhlcmUgYXJlIHRpbWVzIGZvciBpbm5vdmF0aW9uLCBi dXQgbmVhciB0aGUgZW5kIG9mIGEgc3RhbmRhcmRpemF0aW9uIHByb2Nlc3MgaXMgbm90IG9uZSBv ZiB0aGVtLCBJTU8uICBBdCB0aGlzIHBvaW50LCBJIHdvdWxkIHJhdGhlciBzZWUgY29tcGF0aWJs ZSBidWctZnJlZSBpbXBsZW1lbnRhdGlvbnMuICBJJ2xsIHRocm93IG15IHZvdGUgaW4gd2l0aCBO aWNrIGFuZCBBbmRyZWkgZm9yIG1vdmluZyBhaGVhZCB3aXRob3V0IGNoYW5naW5nIHZlcnNpb25p bmcuICBJdCBtYXkgbm90IGJlIG9wdGltYWwsIGJ1dCBpdCBpcyBnb29kIGVub3VnaC4gIFRoaXMg aXMgbm90IGFuIGlzc3VlIHdvcnRoIGRlbGF5aW5nIHRoZSByb2xsLW91dCBvZiB0b2tlbiBiaW5k aW5nLg0KDQpCaWxsDQoNCk9uIFR1ZSwgQXVnIDIzLCAyMDE2IGF0IDU6NDIgUE0sIE1hcnRpbiBU aG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdt YWlsLmNvbT4+IHdyb3RlOg0KT24gMjQgQXVndXN0IDIwMTYgYXQgMTA6MTYsIE5pY2sgSGFycGVy IDxuaGFycGVyQGdvb2dsZS5jb208bWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbT4+IHdyb3RlOg0K PiBJIGRvbid0IHRoaW5rIHRoYXQgdHJ5aW5nIHRvIGdldCBhIG5ldyBJQU5BLWFzc2lnbmVkIG51 bWJlciBmb3IgZWFjaCBkcmFmdA0KPiB2ZXJzaW9uIHRoYXQgaGFzIGJyZWFraW5nIGNoYW5nZXMg aXMgYSB2ZXJ5IHByYWN0aWNhbCBhcHByb2FjaC4NCg0KV2VyZSB5b3UgcGxhbm5pbmcgb24gYnJl YWtpbmcgdGhpbmdzIG9mdGVuPw0KDQpNb3JlIHNlcmlvdXNseSwgbW9zdCBvdGhlciB1c2VyIHVz ZXJzIG9mIHRoaXMgc3BhY2UganVzdCBncmFiIGEgbnVtYmVyDQphbmQgdXNlIGl0LiAgVGhlbiB0 aGV5IHRlbGwgSUFOQSB3aGVuIHRoZXkgZmluaXNoIHdpdGggdGhlaXINCmV4cGVyaW1lbnRzLg0K DQpJZiB5b3UgdGhpbmsgdGhhdCB5b3UgbmVlZCB0byBjaGFuZ2UgbW9yZSBvZnRlbiwgdGhlIG5l dyBleHBlcmltZW50YWwNCnVzZSBzcGFjZSBpcyBwcm9iYWJseSBhIGJldHRlciBpZGVhLg0KDQoN Cg== --_000_CY1PR03MB2155EA41137671898B8B6B0F8CEA0CY1PR03MB2155namp_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56 Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6NTQ3NDU0MDczOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMjY1OTE4OTA0IDE3MzU0NDYzOTQgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoxNjsNCgltc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SSBkbyB0aGluayB0aGF0 IHRoZSBxdWVzdGlvbiBvZiBlbGltaW5hdGluZyB0aGUgdG9rZW5fYmluZGluZ192ZXJzaW9uIG9y IG5vdCBzaG91bGQgYmUgY29uc2lkZXJlZCBpbmRlcGVuZGVudGx5IG9mIGlmL2hvdyB0aGUgZHJh ZnQgdmVyc2lvbiBjYW4gYmUgY29tbXVuaWNhdGVkIGZvciB0ZXN0aW5nIHByaW9yIHRvIHRoZSBz cGVjKHMpIGZpbmFsaXppbmcuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+U3VyZSwgYXMgbG9uZyBhcyB3ZSBlbmQgdXAgd2l0aCBhIHZpYWJs ZSBkZXNpZ24gdGhhdCBzdXBwb3J0cyBib3RoIGV4cGVyaW1lbnRhdGlvbiBhbmQgcHJvZHVjdGlv biBkZXBsb3ltZW50LiBBbmQgSSBkb27igJl0IGV4cGVjdCBleHBlcmltZW50YXRpb24gaW4gdGhp cyBzcGFjZSB0byBzdG9wIG9uY2UNCiBUQiAxLjAgc3BlY3MgYXJlIHB1Ymxpc2hlZOKApjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFuZHJlaTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQnJpYW4gQ2FtcGJlbGwgW21haWx0 bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNk YXksIEF1Z3VzdCAyNCwgMjAxNiAxMDowNiBBTTxicj4NCjxiPlRvOjwvYj4gQmlsbCBDb3ggJmx0 O3dheXdhcmRnZWVrQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNYXJ0aW4gVGhvbXNv biAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29tJmd0OzsgTmljayBIYXJwZXIgJmx0O25oYXJw ZXJAZ29vZ2xlLmNvbSZndDs7IEFuZHJlaSBQb3BvdiAmbHQ7QW5kcmVpLlBvcG92QG1pY3Jvc29m dC5jb20mZ3Q7OyB1bmJlYXJhYmxlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb VW5iZWFyYWJsZV0gVExTIGV4dGVuc2lvbjogdmVyc2lvbiBmaWVsZDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pkkgc2hvdWxkbid0IHNwZWFrIGZvciBoaW0gYnV0LCBmcm9tIHByZXZpb3VzIHN0YXRlbWVudHMg aW4gdGhpcyB0aHJlYWQsIGl0IHNvdW5kZWQgbGlrZSBOaWNrIGlzIGluIGZhdm9yIG9mIGVsaW1p bmF0aW5nIHRoZSB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGRvIHRoaW5rIHRoYXQgdGhlIHF1ZXN0aW9uIG9mIGVsaW1pbmF0aW5nIHRoZSB0 b2tlbl9iaW5kaW5nX3ZlcnNpb24gb3Igbm90IHNob3VsZCBiZSBjb25zaWRlcmVkIGluZGVwZW5k ZW50bHkgb2YgaWYvaG93IHRoZSBkcmFmdCB2ZXJzaW9uIGNhbiBiZSBjb21tdW5pY2F0ZWQgZm9y IHRlc3RpbmcgcHJpb3IgdG8gdGhlIHNwZWMocykgZmluYWxpemluZy4NCjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBUdWUsIEF1ZyAyMywgMjAxNiBhdCAxMDozNSBQTSwgQmlsbCBDb3ggJmx0Ozxh IGhyZWY9Im1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2F5 d2FyZGdlZWtAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIEkgc2VlIGEgY29ycmVs YXRpb24gaGVyZTogdGhvc2Ugb2YgdXMgd2hvIGhhdmUgd29ya2VkIHRvIGJ1aWxkIGZ1bmN0aW9u YWwgdG9rZW4gYmluZGluZyBpbXBsZW1lbnRhdGlvbnMgd291bGQgcHJlZmVyIG5vdCB0byB0aHJv dyB0aGUgY2FyZHMgaW4gdGhlIGFpciBhbmQgd2l0aCBtYWpvciBjaGFuZ2VzLCBzdWNoIGFzIGVs aW1pbmF0aW5nIHRoZSB2ZXJzaW9uLiZuYnNwOyBUaGVyZSBhcmUgdGltZXMgZm9yDQogaW5ub3Zh dGlvbiwgYnV0IG5lYXIgdGhlIGVuZCBvZiBhIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNzIGlzIG5v dCBvbmUgb2YgdGhlbSwgSU1PLiZuYnNwOyBBdCB0aGlzIHBvaW50LCBJIHdvdWxkIHJhdGhlciBz ZWUgY29tcGF0aWJsZSBidWctZnJlZSBpbXBsZW1lbnRhdGlvbnMuJm5ic3A7IEknbGwgdGhyb3cg bXkgdm90ZSBpbiB3aXRoIE5pY2sgYW5kIEFuZHJlaSBmb3IgbW92aW5nIGFoZWFkIHdpdGhvdXQg Y2hhbmdpbmcgdmVyc2lvbmluZy4mbmJzcDsgSXQgbWF5IG5vdA0KIGJlIG9wdGltYWwsIGJ1dCBp dCBpcyBnb29kIGVub3VnaC4mbmJzcDsgVGhpcyBpcyBub3QgYW4gaXNzdWUgd29ydGggZGVsYXlp bmcgdGhlIHJvbGwtb3V0IG9mIHRva2VuIGJpbmRpbmcuPHNwYW4gY2xhc3M9ImhvZW56YiI+PHNw YW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+ QmlsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEF1ZyAyMywgMjAxNiBhdCA1OjQyIFBNLCBN YXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDI0 IEF1Z3VzdCAyMDE2IGF0IDEwOjE2LCBOaWNrIEhhcnBlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5o YXJwZXJAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5oYXJwZXJAZ29vZ2xlLmNvbTwvYT4m Z3Q7IHdyb3RlOjxicj4NCiZndDsgSSBkb24ndCB0aGluayB0aGF0IHRyeWluZyB0byBnZXQgYSBu ZXcgSUFOQS1hc3NpZ25lZCBudW1iZXIgZm9yIGVhY2ggZHJhZnQ8YnI+DQomZ3Q7IHZlcnNpb24g dGhhdCBoYXMgYnJlYWtpbmcgY2hhbmdlcyBpcyBhIHZlcnkgcHJhY3RpY2FsIGFwcHJvYWNoLjxi cj4NCjxicj4NCldlcmUgeW91IHBsYW5uaW5nIG9uIGJyZWFraW5nIHRoaW5ncyBvZnRlbj88YnI+ DQo8YnI+DQpNb3JlIHNlcmlvdXNseSwgbW9zdCBvdGhlciB1c2VyIHVzZXJzIG9mIHRoaXMgc3Bh Y2UganVzdCBncmFiIGEgbnVtYmVyPGJyPg0KYW5kIHVzZSBpdC4mbmJzcDsgVGhlbiB0aGV5IHRl bGwgSUFOQSB3aGVuIHRoZXkgZmluaXNoIHdpdGggdGhlaXI8YnI+DQpleHBlcmltZW50cy48YnI+ DQo8YnI+DQpJZiB5b3UgdGhpbmsgdGhhdCB5b3UgbmVlZCB0byBjaGFuZ2UgbW9yZSBvZnRlbiwg dGhlIG5ldyBleHBlcmltZW50YWw8YnI+DQp1c2Ugc3BhY2UgaXMgcHJvYmFibHkgYSBiZXR0ZXIg aWRlYS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR03MB2155EA41137671898B8B6B0F8CEA0CY1PR03MB2155namp_-- From nobody Wed Aug 24 11:14:43 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 942CF12DA13 for ; Wed, 24 Aug 2016 11:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 eO2IghWy6_h3 for ; Wed, 24 Aug 2016 11:14:38 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 5168E12D96C for ; Wed, 24 Aug 2016 11:14:38 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id m60so2733362uam.3 for ; Wed, 24 Aug 2016 11:14:38 -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=AuaPdikI1a4vnaHRws81Uvjbh0pmrLjDmMNlZlrOhoI=; b=Mc4FiaNmBFV7RX2Uye3goibBW8LXoH+9mgXjgFSlUfz+hmfRGSEoNAIAxw99MIHX1S aDp4bJ0gf7khYenoh4JuOrUybCutY0yWgXloUMqkYajnwHYCbGwO7KHUuYAJbdyelpez /xOQV3Lw6ABlg5YsvSm0PcgGGXH/TsoH7YQsemS0imhWGaddSo6g7EFUJosAdsPUfzML mm46m+PW+t08GVrG/dR5B6+WYI0IzrR9/+M2MtVc+k+dzhcTRo37UeG23OTE2y43mNsU MD8n5QweIVrikwr9JtTPZDNjBggJHyh/qNwc0L1ZwmsJWteCZmzvNZt5/WN+HSOikSLc nHhQ== 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=AuaPdikI1a4vnaHRws81Uvjbh0pmrLjDmMNlZlrOhoI=; b=ELOw7jfSw6jCS4c8MrL0frTG525OgD0mbTnJnXguiR4rAcgRTGMv9XeBE1k4himZJp AUW9TmFTO/MrKQheMFAJK3hLmHYDsO+ruq6sqMo5p3gObWyMiJ8q/hgyUkCYrHvftewp B7DQKYI7lbslPtb5mH8TVXsG5XH/Dt/8VVVzOCCoAgVoWGiAQUD50M/10S2P46HKAvE0 vjRYgs6aXm57yRuav2xzoxF84x+rdht+/HvFQGHsNVPua2f9gmOlq2oHar65e+W+khCp jYbsgneQzTyU0DWZTpiuJUFUW4JAE2rhp7Xdsbq0JpaJ6kZGCl/2FOhR3h/88oSvg0DJ S9Fg== X-Gm-Message-State: AEkoouvI0Zj4x5fik/wQaJzcFznrjeS1B5G3OaaHN0ohnHW9ZtrvFV9CFYqs0IyyTdRFfTa/tqux1A4iI/00QeG0 X-Received: by 10.31.109.193 with SMTP id i184mr2118897vkc.10.1472062477199; Wed, 24 Aug 2016 11:14:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.209 with HTTP; Wed, 24 Aug 2016 11:14:16 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Wed, 24 Aug 2016 11:14:16 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=94eb2c096db40ab0fa053ad541a5 Archived-At: Cc: "unbearable@ietf.org" , Brian Campbell , Martin Thomson , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 24 Aug 2016 18:14:41 -0000 --94eb2c096db40ab0fa053ad541a5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Brian is correct that I am generally in favor of removing the version field from the extension. I think designing a system that works for production deployment of the standardized spec takes precedence over experimentation (but not to a point that would prevent experimentation). Earlier in the thread I explained why the version field won't be useful for production deployment of the standardized spec, and it's also possible to do experimentation without the version field. Andrei, For experimenting after the TB 1.0 spec is published, you have the extensions in the TokenBinding struct, which you can use without changing the version number. If extensions aren't sufficient, then I think you'll need something more in the negotiation message, meaning that you'll need a new TLS extension anyway. On Wed, Aug 24, 2016 at 10:13 AM, Andrei Popov wrote: > =C3=98 I do think that the question of eliminating the token_binding_ver= sion > or not should be considered independently of if/how the draft version can > be communicated for testing prior to the spec(s) finalizing. > > Sure, as long as we end up with a viable design that supports both > experimentation and production deployment. And I don=E2=80=99t expect > experimentation in this space to stop once TB 1.0 specs are published=E2= =80=A6 > > > > Cheers, > > > > Andrei > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Wednesday, August 24, 2016 10:06 AM > *To:* Bill Cox > *Cc:* Martin Thomson ; Nick Harper < > nharper@google.com>; Andrei Popov ; > unbearable@ietf.org > *Subject:* Re: [Unbearable] TLS extension: version field > > > > I shouldn't speak for him but, from previous statements in this thread, i= t > sounded like Nick is in favor of eliminating the version. > > I do think that the question of eliminating the token_binding_version or > not should be considered independently of if/how the draft version can be > communicated for testing prior to the spec(s) finalizing. > > > > > > On Tue, Aug 23, 2016 at 10:35 PM, Bill Cox wrote= : > > I think I see a correlation here: those of us who have worked to build > functional token binding implementations would prefer not to throw the > cards in the air and with major changes, such as eliminating the version. > There are times for innovation, but near the end of a standardization > process is not one of them, IMO. At this point, I would rather see > compatible bug-free implementations. I'll throw my vote in with Nick and > Andrei for moving ahead without changing versioning. It may not be > optimal, but it is good enough. This is not an issue worth delaying the > roll-out of token binding. > > > > Bill > > > > On Tue, Aug 23, 2016 at 5:42 PM, Martin Thomson > wrote: > > On 24 August 2016 at 10:16, Nick Harper wrote: > > I don't think that trying to get a new IANA-assigned number for each > draft > > version that has breaking changes is a very practical approach. > > Were you planning on breaking things often? > > More seriously, most other user users of this space just grab a number > and use it. Then they tell IANA when they finish with their > experiments. > > If you think that you need to change more often, the new experimental > use space is probably a better idea. > > > > > --94eb2c096db40ab0fa053ad541a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Brian is correct that I am generally in favor of removing = the version field from the extension. I think designing a system that works= for production deployment of the standardized spec takes precedence over e= xperimentation (but not to a point that would prevent experimentation). Ear= lier in the thread I explained why the version field won't be useful fo= r production deployment of the standardized spec, and it's also possibl= e to do experimentation without the version field.

= Andrei,
For experimenting after the TB 1.0 spec is published, you= have the extensions in the TokenBinding struct, which you can use without = changing the version number. If extensions aren't sufficient, then I th= ink you'll need something more in the negotiation message, meaning that= you'll need a new TLS extension anyway.

On Wed, Aug 24, 2016 at 10:13 = AM, Andrei Popov <Andrei.Popov@microsoft.com> wrote= :

=C3=98=C2=A0 I do think that the question of eliminating the= token_binding_version or not should be considered independently of if/how = the draft version can be communicated for testing prior to the spec(s) fina= lizing.

Sure, as long as we end up with a viable design tha= t supports both experimentation and production deployment. And I don=E2=80= =99t expect experimentation in this space to stop once TB 1.0 specs are published=E2=80=A6

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Brian Campbell [mailto:bcampbell@pin= gidentity.com]
Sent: Wednesday, August 24, 2016 10:06 AM
To: Bill Cox <waywardgeek@google.com>
Cc: Martin Thomson <martin.thomson@gmail.com>; Nick Harper <nharper@google.com>= ; Andrei Popov <Andrei.Popov@microsoft.com>; unbearable@ietf.org
Subject: Re: [Unbearable] TLS extension: version field=

=C2=A0

I shouldn't speak= for him but, from previous statements in this thread, it sounded like Nick= is in favor of eliminating the version.

I do think that the question of eliminating the toke= n_binding_version or not should be considered independently of if/how the d= raft version can be communicated for testing prior to the spec(s) finalizin= g.

=C2=A0

=C2=A0

On Tue, Aug 23, 2016 at 10:35 PM, Bill Cox <waywardgeek@google.c= om> wrote:

I think I see a correlation here: those of us who ha= ve worked to build functional token binding implementations would prefer no= t to throw the cards in the air and with major changes, such as eliminating= the version.=C2=A0 There are times for innovation, but near the end of a standardization process is not one of th= em, IMO.=C2=A0 At this point, I would rather see compatible bug-free implem= entations.=C2=A0 I'll throw my vote in with Nick and Andrei for moving = ahead without changing versioning.=C2=A0 It may not be optimal, but it is good enough.=C2=A0 This is not an issue worth delayi= ng the roll-out of token binding.

=C2=A0

Bill

=C2=A0

On Tue, Aug 23, 2016 at 5:42 PM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:

On 24 August 2016 at 10:16, Nick Harper <nharper@google.com>= wrote:
> I don't think that trying to get a new IANA-assigned number for ea= ch draft
> version that has breaking changes is a very practical approach.

Were you planning on breaking things often?

More seriously, most other user users of this space just grab a number
and use it.=C2=A0 Then they tell IANA when they finish with their
experiments.

If you think that you need to change more often, the new experimental
use space is probably a better idea.

=C2=A0

=C2=A0


--94eb2c096db40ab0fa053ad541a5-- From nobody Wed Aug 24 11:43:19 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 E6B0D12D66E for ; Wed, 24 Aug 2016 11:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 rzCWrEQhbo6I for ; Wed, 24 Aug 2016 11:43:14 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0100.outbound.protection.outlook.com [104.47.42.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A3F512D64F for ; Wed, 24 Aug 2016 11:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ItV8qUq3jE8eL2Du7AwYdsJ1vUAcHxg1GajiGiI486Q=; b=b6BAoPR/kPL+F2msg6c1GjCYVjOUcRb3pQrUgrA2v+R2XlaJeoRKf9oScqMEH2jMMKqcokZqqn7pdtZDs0ueDIDoWvNsxB53Nl49XXsHTFyiS8ID6r54NuXA1T25XGdNIywSjddRvaLL4A1Li5O1Sst42653bodZhdJ+MSpHzWc= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2154.namprd03.prod.outlook.com (10.166.206.139) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Wed, 24 Aug 2016 18:43:12 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0587.013; Wed, 24 Aug 2016 18:43:12 +0000 From: Andrei Popov To: Nick Harper Thread-Topic: [Unbearable] TLS extension: version field Thread-Index: AQHR8UE0hAr3fGh5LkSos3djbwbcUaA/MmwAgAAmOoCAAAGk8IAAhvMAgAAFqjCAAAO6AIAA6WmAgAATAoCAABJZgIAV3xfwgAATKACAAFvQgIAAAlRwgAANXQCAAAcGgIAAQVIAgADRnQCAAADEgIAAEkUAgAAEGBA= Date: Wed, 24 Aug 2016 18:43:12 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: 01db7e24-853a-4fbb-6f8e-08d3cc4e8068 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2154; 6:946RJwVGpNIS1yoUBtHk0v2KKnOvZcqcciE5FY3/rY1Jtht6p3Wt0PA3we5141gJEZPN+m87HDk/yXYfftrP/aeqn80xSnLQHSuhfPCRPwZrWDdLpW6PKtGWjZRABJ2khtvtSdwxNsQnd+4fc//kP8dXbELXoq8RcHYifyUod0/hj6X5w5KiHGeUc3Uf8HXP1N60wQDaKAm/WGiDw3FiLOexs4R7AYncpGk3SgSAy1zHfhNxmhZK06ZpeJgGr672UvRl6aCI9eSvfjbKlzEu/htVZM6EJFpH9kOij5da8gd1AFX+rPsMZkpLIj17AjSwmq9fFMlMJKUmGDuIgWnqmw==; 5:yES60Kaz2yajppnWdsKnm5iMI5hcxzqxo31eCANfY8W9bYO2/49Ftt6lvm6sEAytUtE49/JkHU3GHYBxii2Z3o5WfVQE8DU4+3Lszdw9fT/Q4iqJvogU1EZarLezfbgceNoZ1Izz94iiP172tPr8cg==; 24:LEWnwIKQ6MxNIEEyfVOSdFFmww6apPTuVwe0SDvYtzJA7I4kP8OhdgO0pls47vDKZmTDJ3cFc+B3BWkcTMdOI2SgoSF5+NidKa1G4Ij5A2w=; 7:Lsm0fl76C17e1mgtEVC//XPnvgKdAG6tt0Vp2HDhKacZ3IFlg1bxUzwBMAzOhC1jPGC5EJdY9pIrJNqm54s3DsKqFQERl3joaTd3E+Knp/IFCDt2qeu+MdRQ73Kn913nNJnHRhSGfrYn9BRMvjHzGpk5lymHcXzbZozWkxNOa1trrvqrRKy96FMV5NCH/0+GRXPT0amioDgAnxKUGnVGeG9O6njTh0diMxVVZhEQmrYgNcVvTfQ5osuscJG/pkPX x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2154; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2154; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2154; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(377454003)(199003)(189002)(8676002)(68736007)(2906002)(99286002)(81166006)(81156014)(9686002)(76576001)(106356001)(19580405001)(122556002)(4326007)(19580395003)(7846002)(7696003)(86362001)(74316002)(7736002)(16236675004)(3660700001)(3280700002)(8936002)(105586002)(33656002)(15975445007)(77096005)(5660300001)(10090500001)(2950100001)(586003)(2900100001)(92566002)(102836003)(11100500001)(5005710100001)(19300405004)(6116002)(790700001)(10290500002)(50986999)(10400500002)(54356999)(8990500004)(106116001)(76176999)(19609705001)(5002640100001)(101416001)(561944003)(189998001)(87936001)(19625215002)(93886004)(110136002)(97736004)(86612001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2154; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB21558670E0CFEA20D2A67EB98CEA0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 18:43:12.1573 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2154 Archived-At: Cc: "unbearable@ietf.org" , Brian Campbell , Martin Thomson , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 24 Aug 2016 18:43:17 -0000 --_000_CY1PR03MB21558670E0CFEA20D2A67EB98CEA0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGN1cnJlbnQgZGVzaWduIGlzIGRvY3VtZW50ZWQgaW4gdGhlIFRCTkVHTyBJLUQ7IGxldOKA mXMgZ2V0IGNsYXJpdHkgb24gdGhlIGNvbXBldGluZyBwcm9wb3NhbCwgc28gdGhhdCB3ZSBjYW4g Z2V0IGEgY29uc2Vuc3VzIGNhbGwgb24gdGhlIG1haWxpbmcgbGlzdCBhbmQgbGV0IHRoZSBXRyBw aWNrIG9uZSBvcHRpb24gb3IgdGhlIG90aGVyLg0KDQpNeSBjdXJyZW50IHVuZGVyc3RhbmRpbmcg b2YgdGhlIGNvbXBldGluZyBwcm9wb3NhbCBpcyBhcyBmb2xsb3dzIChwcm9wb25lbnRzIHBsZWFz ZSBjb3JyZWN0IG1lIGlmIEkgZ290IGl0IHdyb25nKToNCg0KMS4gICAgICAgUmVtb3ZlIHRoZSB0 b2tlbl9iaW5kaW5nX3ZlcnNpb24gZmllbGQgZnJvbSB0aGUgdG9rZW5fYmluZGluZyBleHRlbnNp b247DQoNCjIuICAgICAgIFBpY2sgcmFuZG9tIHVuYXNzaWduZWQgYSBUTFMgZXh0ZW5zaW9uIElE cyBmb3IgZWFjaCBkcmFmdCB2ZXJzaW9uOw0KDQozLiAgICAgICBGaW5hbGl6ZWQgVEIgMS4wIHdp bGwgdXNlIGEgbmV3IElBTkEtYXNzaWduZWQgVExTIGV4dGVuc2lvbiBjb2RlIHBvaW50IG90aGVy IHRoYW4gMjQgKGJlY2F1c2UgVExTIGV4dGVuc2lvbiAyNCBpcyBjdXJyZW50bHkgdXNlZCBieSBD aHJvbWUsIHdpdGggdG9rZW5fYmluZGluZ192ZXJzaW9uIGluIGl0KS4NCg0KRnJvbTogTmljayBI YXJwZXIgW21haWx0bzpuaGFycGVyQGdvb2dsZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEF1Z3Vz dCAyNCwgMjAxNiAxMToxNCBBTQ0KVG86IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jv c29mdC5jb20+DQpDYzogQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t PjsgQmlsbCBDb3ggPHdheXdhcmRnZWVrQGdvb2dsZS5jb20+OyBNYXJ0aW4gVGhvbXNvbiA8bWFy dGluLnRob21zb25AZ21haWwuY29tPjsgdW5iZWFyYWJsZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtVbmJlYXJhYmxlXSBUTFMgZXh0ZW5zaW9uOiB2ZXJzaW9uIGZpZWxkDQoNCkJyaWFuIGlzIGNv cnJlY3QgdGhhdCBJIGFtIGdlbmVyYWxseSBpbiBmYXZvciBvZiByZW1vdmluZyB0aGUgdmVyc2lv biBmaWVsZCBmcm9tIHRoZSBleHRlbnNpb24uIEkgdGhpbmsgZGVzaWduaW5nIGEgc3lzdGVtIHRo YXQgd29ya3MgZm9yIHByb2R1Y3Rpb24gZGVwbG95bWVudCBvZiB0aGUgc3RhbmRhcmRpemVkIHNw ZWMgdGFrZXMgcHJlY2VkZW5jZSBvdmVyIGV4cGVyaW1lbnRhdGlvbiAoYnV0IG5vdCB0byBhIHBv aW50IHRoYXQgd291bGQgcHJldmVudCBleHBlcmltZW50YXRpb24pLiBFYXJsaWVyIGluIHRoZSB0 aHJlYWQgSSBleHBsYWluZWQgd2h5IHRoZSB2ZXJzaW9uIGZpZWxkIHdvbid0IGJlIHVzZWZ1bCBm b3IgcHJvZHVjdGlvbiBkZXBsb3ltZW50IG9mIHRoZSBzdGFuZGFyZGl6ZWQgc3BlYywgYW5kIGl0 J3MgYWxzbyBwb3NzaWJsZSB0byBkbyBleHBlcmltZW50YXRpb24gd2l0aG91dCB0aGUgdmVyc2lv biBmaWVsZC4NCg0KQW5kcmVpLA0KRm9yIGV4cGVyaW1lbnRpbmcgYWZ0ZXIgdGhlIFRCIDEuMCBz cGVjIGlzIHB1Ymxpc2hlZCwgeW91IGhhdmUgdGhlIGV4dGVuc2lvbnMgaW4gdGhlIFRva2VuQmlu ZGluZyBzdHJ1Y3QsIHdoaWNoIHlvdSBjYW4gdXNlIHdpdGhvdXQgY2hhbmdpbmcgdGhlIHZlcnNp b24gbnVtYmVyLiBJZiBleHRlbnNpb25zIGFyZW4ndCBzdWZmaWNpZW50LCB0aGVuIEkgdGhpbmsg eW91J2xsIG5lZWQgc29tZXRoaW5nIG1vcmUgaW4gdGhlIG5lZ290aWF0aW9uIG1lc3NhZ2UsIG1l YW5pbmcgdGhhdCB5b3UnbGwgbmVlZCBhIG5ldyBUTFMgZXh0ZW5zaW9uIGFueXdheS4NCg0KT24g V2VkLCBBdWcgMjQsIDIwMTYgYXQgMTA6MTMgQU0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92 QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6 DQoNCj4gIEkgZG8gdGhpbmsgdGhhdCB0aGUgcXVlc3Rpb24gb2YgZWxpbWluYXRpbmcgdGhlIHRv a2VuX2JpbmRpbmdfdmVyc2lvbiBvciBub3Qgc2hvdWxkIGJlIGNvbnNpZGVyZWQgaW5kZXBlbmRl bnRseSBvZiBpZi9ob3cgdGhlIGRyYWZ0IHZlcnNpb24gY2FuIGJlIGNvbW11bmljYXRlZCBmb3Ig dGVzdGluZyBwcmlvciB0byB0aGUgc3BlYyhzKSBmaW5hbGl6aW5nLg0KU3VyZSwgYXMgbG9uZyBh cyB3ZSBlbmQgdXAgd2l0aCBhIHZpYWJsZSBkZXNpZ24gdGhhdCBzdXBwb3J0cyBib3RoIGV4cGVy aW1lbnRhdGlvbiBhbmQgcHJvZHVjdGlvbiBkZXBsb3ltZW50LiBBbmQgSSBkb27igJl0IGV4cGVj dCBleHBlcmltZW50YXRpb24gaW4gdGhpcyBzcGFjZSB0byBzdG9wIG9uY2UgVEIgMS4wIHNwZWNz IGFyZSBwdWJsaXNoZWTigKYNCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KRnJvbTogQnJpYW4gQ2Ft cGJlbGwgW21haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb20+XQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjQsIDIwMTYgMTA6 MDYgQU0NClRvOiBCaWxsIENveCA8d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTxtYWlsdG86d2F5d2Fy ZGdlZWtAZ29vZ2xlLmNvbT4+DQpDYzogTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdt YWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj47IE5pY2sgSGFycGVyIDxu aGFycGVyQGdvb2dsZS5jb208bWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbT4+OyBBbmRyZWkgUG9w b3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9z b2Z0LmNvbT4+OyB1bmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzp1bmJlYXJhYmxlQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBUTFMgZXh0ZW5zaW9uOiB2ZXJzaW9uIGZpZWxk DQoNCkkgc2hvdWxkbid0IHNwZWFrIGZvciBoaW0gYnV0LCBmcm9tIHByZXZpb3VzIHN0YXRlbWVu dHMgaW4gdGhpcyB0aHJlYWQsIGl0IHNvdW5kZWQgbGlrZSBOaWNrIGlzIGluIGZhdm9yIG9mIGVs aW1pbmF0aW5nIHRoZSB2ZXJzaW9uLg0KSSBkbyB0aGluayB0aGF0IHRoZSBxdWVzdGlvbiBvZiBl bGltaW5hdGluZyB0aGUgdG9rZW5fYmluZGluZ192ZXJzaW9uIG9yIG5vdCBzaG91bGQgYmUgY29u c2lkZXJlZCBpbmRlcGVuZGVudGx5IG9mIGlmL2hvdyB0aGUgZHJhZnQgdmVyc2lvbiBjYW4gYmUg Y29tbXVuaWNhdGVkIGZvciB0ZXN0aW5nIHByaW9yIHRvIHRoZSBzcGVjKHMpIGZpbmFsaXppbmcu DQoNCg0KT24gVHVlLCBBdWcgMjMsIDIwMTYgYXQgMTA6MzUgUE0sIEJpbGwgQ294IDx3YXl3YXJk Z2Vla0Bnb29nbGUuY29tPG1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPj4gd3JvdGU6DQpJ IHRoaW5rIEkgc2VlIGEgY29ycmVsYXRpb24gaGVyZTogdGhvc2Ugb2YgdXMgd2hvIGhhdmUgd29y a2VkIHRvIGJ1aWxkIGZ1bmN0aW9uYWwgdG9rZW4gYmluZGluZyBpbXBsZW1lbnRhdGlvbnMgd291 bGQgcHJlZmVyIG5vdCB0byB0aHJvdyB0aGUgY2FyZHMgaW4gdGhlIGFpciBhbmQgd2l0aCBtYWpv ciBjaGFuZ2VzLCBzdWNoIGFzIGVsaW1pbmF0aW5nIHRoZSB2ZXJzaW9uLiAgVGhlcmUgYXJlIHRp bWVzIGZvciBpbm5vdmF0aW9uLCBidXQgbmVhciB0aGUgZW5kIG9mIGEgc3RhbmRhcmRpemF0aW9u IHByb2Nlc3MgaXMgbm90IG9uZSBvZiB0aGVtLCBJTU8uICBBdCB0aGlzIHBvaW50LCBJIHdvdWxk IHJhdGhlciBzZWUgY29tcGF0aWJsZSBidWctZnJlZSBpbXBsZW1lbnRhdGlvbnMuICBJJ2xsIHRo cm93IG15IHZvdGUgaW4gd2l0aCBOaWNrIGFuZCBBbmRyZWkgZm9yIG1vdmluZyBhaGVhZCB3aXRo b3V0IGNoYW5naW5nIHZlcnNpb25pbmcuICBJdCBtYXkgbm90IGJlIG9wdGltYWwsIGJ1dCBpdCBp cyBnb29kIGVub3VnaC4gIFRoaXMgaXMgbm90IGFuIGlzc3VlIHdvcnRoIGRlbGF5aW5nIHRoZSBy b2xsLW91dCBvZiB0b2tlbiBiaW5kaW5nLg0KDQpCaWxsDQoNCk9uIFR1ZSwgQXVnIDIzLCAyMDE2 IGF0IDU6NDIgUE0sIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFp bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KT24gMjQgQXVndXN0IDIwMTYg YXQgMTA6MTYsIE5pY2sgSGFycGVyIDxuaGFycGVyQGdvb2dsZS5jb208bWFpbHRvOm5oYXJwZXJA Z29vZ2xlLmNvbT4+IHdyb3RlOg0KPiBJIGRvbid0IHRoaW5rIHRoYXQgdHJ5aW5nIHRvIGdldCBh IG5ldyBJQU5BLWFzc2lnbmVkIG51bWJlciBmb3IgZWFjaCBkcmFmdA0KPiB2ZXJzaW9uIHRoYXQg aGFzIGJyZWFraW5nIGNoYW5nZXMgaXMgYSB2ZXJ5IHByYWN0aWNhbCBhcHByb2FjaC4NCg0KV2Vy ZSB5b3UgcGxhbm5pbmcgb24gYnJlYWtpbmcgdGhpbmdzIG9mdGVuPw0KDQpNb3JlIHNlcmlvdXNs eSwgbW9zdCBvdGhlciB1c2VyIHVzZXJzIG9mIHRoaXMgc3BhY2UganVzdCBncmFiIGEgbnVtYmVy DQphbmQgdXNlIGl0LiAgVGhlbiB0aGV5IHRlbGwgSUFOQSB3aGVuIHRoZXkgZmluaXNoIHdpdGgg dGhlaXINCmV4cGVyaW1lbnRzLg0KDQpJZiB5b3UgdGhpbmsgdGhhdCB5b3UgbmVlZCB0byBjaGFu Z2UgbW9yZSBvZnRlbiwgdGhlIG5ldyBleHBlcmltZW50YWwNCnVzZSBzcGFjZSBpcyBwcm9iYWJs eSBhIGJldHRlciBpZGVhLg0KDQoNCg0K --_000_CY1PR03MB21558670E0CFEA20D2A67EB98CEA0CY1PR03MB2155namp_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubTY2ODYyMjk0NTUzMzY0Njc2NTNtc29saXN0cGFyYWdy YXBoLCBsaS5tNjY4NjIyOTQ1NTMzNjQ2NzY1M21zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tNjY4NjIy OTQ1NTMzNjQ2NzY1M21zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV82Njg2MjI5 NDU1MzM2NDY3NjUzbXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCnNwYW4ubTY2ODYyMjk0NTUzMzY0Njc2NTNob2VuemINCgl7bXNvLXN0 eWxlLW5hbWU6bV82Njg2MjI5NDU1MzM2NDY3NjUzaG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIw DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMTA3NTcz OTA1Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTQz MTgwMDQ2NiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs MDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5UaGUgY3VycmVudCBkZXNpZ24gaXMgZG9jdW1lbnRlZCBpbiB0aGUgVEJORUdPIEktRDsgbGV0 4oCZcyBnZXQgY2xhcml0eSBvbiB0aGUgY29tcGV0aW5nIHByb3Bvc2FsLCBzbyB0aGF0IHdlIGNh biBnZXQgYSBjb25zZW5zdXMgY2FsbCBvbiB0aGUgbWFpbGluZyBsaXN0IGFuZCBsZXQgdGhlIFdH IHBpY2sNCiBvbmUgb3B0aW9uIG9yIHRoZSBvdGhlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TXkgY3VycmVu dCB1bmRlcnN0YW5kaW5nIG9mIHRoZSBjb21wZXRpbmcgcHJvcG9zYWwgaXMgYXMgZm9sbG93cyAo cHJvcG9uZW50cyBwbGVhc2UgY29ycmVjdCBtZSBpZiBJIGdvdCBpdCB3cm9uZyk6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+UmVtb3ZlIHRoZSB0b2tlbl9iaW5kaW5nX3ZlcnNpb24gZmllbGQg ZnJvbSB0aGUgdG9rZW5fYmluZGluZyBleHRlbnNpb247PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBw dCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+UGljayByYW5kb20gdW5hc3NpZ25lZCBhIFRMUyBleHRlbnNpb24gSURzIGZvciBlYWNoIGRy YWZ0IHZlcnNpb247PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RmluYWxpemVkIFRCIDEuMCB3 aWxsIHVzZSBhIG5ldyBJQU5BLWFzc2lnbmVkIFRMUyBleHRlbnNpb24gY29kZSBwb2ludCBvdGhl ciB0aGFuIDI0IChiZWNhdXNlIFRMUyBleHRlbnNpb24gMjQgaXMgY3VycmVudGx5IHVzZWQgYnkg Q2hyb21lLCB3aXRoIHRva2VuX2JpbmRpbmdfdmVyc2lvbg0KIGluIGl0KS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE5pY2sgSGFycGVyIFttYWls dG86bmhhcnBlckBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVn dXN0IDI0LCAyMDE2IDExOjE0IEFNPGJyPg0KPGI+VG86PC9iPiBBbmRyZWkgUG9wb3YgJmx0O0Fu ZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQnJpYW4gQ2FtcGJl bGwgJmx0O2JjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tJmd0OzsgQmlsbCBDb3ggJmx0O3dheXdh cmRnZWVrQGdvb2dsZS5jb20mZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21zb25A Z21haWwuY29tJmd0OzsgdW5iZWFyYWJsZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW1VuYmVhcmFibGVdIFRMUyBleHRlbnNpb246IHZlcnNpb24gZmllbGQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CcmlhbiBpcyBjb3JyZWN0IHRoYXQgSSBhbSBnZW5l cmFsbHkgaW4gZmF2b3Igb2YgcmVtb3ZpbmcgdGhlIHZlcnNpb24gZmllbGQgZnJvbSB0aGUgZXh0 ZW5zaW9uLiBJIHRoaW5rIGRlc2lnbmluZyBhIHN5c3RlbSB0aGF0IHdvcmtzIGZvciBwcm9kdWN0 aW9uIGRlcGxveW1lbnQgb2YgdGhlIHN0YW5kYXJkaXplZCBzcGVjIHRha2VzIHByZWNlZGVuY2Ug b3ZlciBleHBlcmltZW50YXRpb24gKGJ1dCBub3QgdG8gYQ0KIHBvaW50IHRoYXQgd291bGQgcHJl dmVudCBleHBlcmltZW50YXRpb24pLiBFYXJsaWVyIGluIHRoZSB0aHJlYWQgSSBleHBsYWluZWQg d2h5IHRoZSB2ZXJzaW9uIGZpZWxkIHdvbid0IGJlIHVzZWZ1bCBmb3IgcHJvZHVjdGlvbiBkZXBs b3ltZW50IG9mIHRoZSBzdGFuZGFyZGl6ZWQgc3BlYywgYW5kIGl0J3MgYWxzbyBwb3NzaWJsZSB0 byBkbyBleHBlcmltZW50YXRpb24gd2l0aG91dCB0aGUgdmVyc2lvbiBmaWVsZC48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmRyZWksPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgZXhwZXJp bWVudGluZyBhZnRlciB0aGUgVEIgMS4wIHNwZWMgaXMgcHVibGlzaGVkLCB5b3UgaGF2ZSB0aGUg ZXh0ZW5zaW9ucyBpbiB0aGUgVG9rZW5CaW5kaW5nIHN0cnVjdCwgd2hpY2ggeW91IGNhbiB1c2Ug d2l0aG91dCBjaGFuZ2luZyB0aGUgdmVyc2lvbiBudW1iZXIuIElmIGV4dGVuc2lvbnMgYXJlbid0 IHN1ZmZpY2llbnQsIHRoZW4gSSB0aGluayB5b3UnbGwgbmVlZCBzb21ldGhpbmcgbW9yZSBpbg0K IHRoZSBuZWdvdGlhdGlvbiBtZXNzYWdlLCBtZWFuaW5nIHRoYXQgeW91J2xsIG5lZWQgYSBuZXcg VExTIGV4dGVuc2lvbiBhbnl3YXkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBdWcgMjQsIDIwMTYgYXQgMTA6MTMg QU0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3Nv ZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJtNjY4NjIyOTQ1NTMzNjQ2NzY1M21zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpXaW5nZGluZ3MiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4w cHQiPiZuYnNwOw0KPC9zcGFuPkkgZG8gdGhpbmsgdGhhdCB0aGUgcXVlc3Rpb24gb2YgZWxpbWlu YXRpbmcgdGhlIHRva2VuX2JpbmRpbmdfdmVyc2lvbiBvciBub3Qgc2hvdWxkIGJlIGNvbnNpZGVy ZWQgaW5kZXBlbmRlbnRseSBvZiBpZi9ob3cgdGhlIGRyYWZ0IHZlcnNpb24gY2FuIGJlIGNvbW11 bmljYXRlZCBmb3IgdGVzdGluZyBwcmlvciB0byB0aGUgc3BlYyhzKSBmaW5hbGl6aW5nLg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U3Vy ZSwgYXMgbG9uZyBhcyB3ZSBlbmQgdXAgd2l0aCBhIHZpYWJsZSBkZXNpZ24gdGhhdCBzdXBwb3J0 cyBib3RoIGV4cGVyaW1lbnRhdGlvbiBhbmQgcHJvZHVjdGlvbiBkZXBsb3ltZW50LiBBbmQNCiBJ IGRvbuKAmXQgZXhwZWN0IGV4cGVyaW1lbnRhdGlvbiBpbiB0aGlzIHNwYWNlIHRvIHN0b3Agb25j ZSBUQiAxLjAgc3BlY3MgYXJlIHB1Ymxpc2hlZOKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hlZXJz LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kcmVpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQnJpYW4gQ2FtcGJlbGwgW21haWx0bzo8YSBocmVm PSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBBdWd1c3QgMjQsIDIwMTYgMTA6MDYgQU08YnI+DQo8Yj5Ubzo8L2I+IEJpbGwgQ294ICZsdDs8 YSBocmVmPSJtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndh eXdhcmRnZWVrQGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTWFydGluIFRob21z b24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OzsgTmljayBIYXJwZXIgJmx0 OzxhIGhyZWY9Im1haWx0bzpuaGFycGVyQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5uaGFy cGVyQGdvb2dsZS5jb208L2E+Jmd0OzsgQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86 QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZA bWljcm9zb2Z0LmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj51bmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIFRMUyBleHRlbnNpb246IHZlcnNpb24gZmllbGQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgc2hvdWxkbid0IHNwZWFr IGZvciBoaW0gYnV0LCBmcm9tIHByZXZpb3VzIHN0YXRlbWVudHMgaW4gdGhpcyB0aHJlYWQsIGl0 IHNvdW5kZWQgbGlrZSBOaWNrIGlzIGluIGZhdm9yIG9mIGVsaW1pbmF0aW5nIHRoZSB2ZXJzaW9u LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SSBkbyB0aGluayB0aGF0IHRoZSBxdWVzdGlvbiBvZiBlbGltaW5hdGluZyB0aGUgdG9r ZW5fYmluZGluZ192ZXJzaW9uIG9yIG5vdCBzaG91bGQgYmUgY29uc2lkZXJlZCBpbmRlcGVuZGVu dGx5IG9mIGlmL2hvdyB0aGUgZHJhZnQgdmVyc2lvbiBjYW4gYmUgY29tbXVuaWNhdGVkIGZvciB0 ZXN0aW5nIHByaW9yDQogdG8gdGhlIHNwZWMocykgZmluYWxpemluZy4gPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgQXVnIDIz LCAyMDE2IGF0IDEwOjM1IFBNLCBCaWxsIENveCAmbHQ7PGEgaHJlZj0ibWFpbHRvOndheXdhcmRn ZWVrQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj53YXl3YXJkZ2Vla0Bnb29nbGUuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhp bmsgSSBzZWUgYSBjb3JyZWxhdGlvbiBoZXJlOiB0aG9zZSBvZiB1cyB3aG8gaGF2ZSB3b3JrZWQg dG8gYnVpbGQgZnVuY3Rpb25hbCB0b2tlbiBiaW5kaW5nIGltcGxlbWVudGF0aW9ucyB3b3VsZCBw cmVmZXIgbm90IHRvIHRocm93IHRoZSBjYXJkcyBpbiB0aGUgYWlyIGFuZCB3aXRoIG1ham9yIGNo YW5nZXMsDQogc3VjaCBhcyBlbGltaW5hdGluZyB0aGUgdmVyc2lvbi4mbmJzcDsgVGhlcmUgYXJl IHRpbWVzIGZvciBpbm5vdmF0aW9uLCBidXQgbmVhciB0aGUgZW5kIG9mIGEgc3RhbmRhcmRpemF0 aW9uIHByb2Nlc3MgaXMgbm90IG9uZSBvZiB0aGVtLCBJTU8uJm5ic3A7IEF0IHRoaXMgcG9pbnQs IEkgd291bGQgcmF0aGVyIHNlZSBjb21wYXRpYmxlIGJ1Zy1mcmVlIGltcGxlbWVudGF0aW9ucy4m bmJzcDsgSSdsbCB0aHJvdyBteSB2b3RlIGluIHdpdGggTmljayBhbmQgQW5kcmVpIGZvcg0KIG1v dmluZyBhaGVhZCB3aXRob3V0IGNoYW5naW5nIHZlcnNpb25pbmcuJm5ic3A7IEl0IG1heSBub3Qg YmUgb3B0aW1hbCwgYnV0IGl0IGlzIGdvb2QgZW5vdWdoLiZuYnNwOyBUaGlzIGlzIG5vdCBhbiBp c3N1ZSB3b3J0aCBkZWxheWluZyB0aGUgcm9sbC1vdXQgb2YgdG9rZW4gYmluZGluZy48bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6Izg4ODg4OCI+QmlsbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBBdWcgMjMs IDIwMTYgYXQgNTo0MiBQTSwgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFp bC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiAy NCBBdWd1c3QgMjAxNiBhdCAxMDoxNiwgTmljayBIYXJwZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpu aGFycGVyQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5uaGFycGVyQGdvb2dsZS5jb208L2E+ Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IEkgZG9uJ3QgdGhpbmsgdGhhdCB0cnlpbmcgdG8gZ2V0IGEg bmV3IElBTkEtYXNzaWduZWQgbnVtYmVyIGZvciBlYWNoIGRyYWZ0PGJyPg0KJmd0OyB2ZXJzaW9u IHRoYXQgaGFzIGJyZWFraW5nIGNoYW5nZXMgaXMgYSB2ZXJ5IHByYWN0aWNhbCBhcHByb2FjaC48 YnI+DQo8YnI+DQpXZXJlIHlvdSBwbGFubmluZyBvbiBicmVha2luZyB0aGluZ3Mgb2Z0ZW4/PGJy Pg0KPGJyPg0KTW9yZSBzZXJpb3VzbHksIG1vc3Qgb3RoZXIgdXNlciB1c2VycyBvZiB0aGlzIHNw YWNlIGp1c3QgZ3JhYiBhIG51bWJlcjxicj4NCmFuZCB1c2UgaXQuJm5ic3A7IFRoZW4gdGhleSB0 ZWxsIElBTkEgd2hlbiB0aGV5IGZpbmlzaCB3aXRoIHRoZWlyPGJyPg0KZXhwZXJpbWVudHMuPGJy Pg0KPGJyPg0KSWYgeW91IHRoaW5rIHRoYXQgeW91IG5lZWQgdG8gY2hhbmdlIG1vcmUgb2Z0ZW4s IHRoZSBuZXcgZXhwZXJpbWVudGFsPGJyPg0KdXNlIHNwYWNlIGlzIHByb2JhYmx5IGEgYmV0dGVy IGlkZWEuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR03MB21558670E0CFEA20D2A67EB98CEA0CY1PR03MB2155namp_-- From nobody Wed Aug 24 11:53: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 17FF712DCA4 for ; Wed, 24 Aug 2016 11:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 YGkbEDJAHbZ5 for ; Wed, 24 Aug 2016 11:53:06 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 DF62E12DB3C for ; Wed, 24 Aug 2016 11:53:05 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id n59so44729021uan.2 for ; Wed, 24 Aug 2016 11:53:05 -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=rn+/KCJxgArA4X32ya+fLJEZEpeuW5+v87/crkYp3yU=; b=fc3+h5RYKuGLtWgxG3c/f0r3VOKrT8Q/KUN6hyv6oSs2+VSd9oJ26cWB8iQUEvyacV 8gKSq14eYNPaP1Dfj4WxJEhR0oQb0tNn+xIcPG65chycALHNj01r4XsIqTsf6cy9xYw+ F1ldMjrHRW5TiDnnRXDQtvpRLb5gIshxlhUtGzC0DsTZW+jvwQuRCTK3SJUfCQv/FcCM 5fqJRU53a2AWCF7capmqwsneeVf0YkUpiLWm2gX52q2k8kftBTqDutsa27oGqN0/QOOj veeTheyviaiqYxcc2zO+N/EqXPf4qhwpCnWOYgItl3rxMKyC979R3k3a4svH/af/bnQ1 m82Q== 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=rn+/KCJxgArA4X32ya+fLJEZEpeuW5+v87/crkYp3yU=; b=AiDhSYANyGC3EMoZHOgHmjgtrsSHqGCN+JjbNTSy6PMwAstQIORARG9GbWRwtMQoUo 2lbZdfwB0Dz+Xim9TkBnJ56gr524FxhYmS4cXEM/KubF0pJew07e1HQ2HjQfVdn7JGrr 9QsrTqHt5pWlVTL5t0yiKGNuTsz6UaKSO8sxPUyz2yn6Goz3M5iCA1vnIM2Z+Vwyk/g1 rt+np6li2IRAfL6saoLb1OPCHMFcptSMiEOHGftrarozzuOyLEEZ47KMRDnsPQjcd/5K 7okelfOevNo8VSWjq/aYxzlq80WpeQGCbH7SiGSJb9T1XT+AqL1ZIt1ZTbMh4Qd6+wWl a/0Q== X-Gm-Message-State: AE9vXwMBD0Ie8B6HI8Vkvx2ZRdzJhbgMz0kpRLWSyq09oGb4aNi9Yw5HukfsZOVCwACLznBHjF5u4U6KKkVCm3uN X-Received: by 10.176.7.1 with SMTP id h1mr2154579uah.129.1472064784204; Wed, 24 Aug 2016 11:53:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.209 with HTTP; Wed, 24 Aug 2016 11:52:43 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Wed, 24 Aug 2016 11:52:43 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=94eb2c1248108cdc95053ad5ca9a Archived-At: Cc: "unbearable@ietf.org" , Brian Campbell , Martin Thomson , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 24 Aug 2016 18:53:12 -0000 --94eb2c1248108cdc95053ad5ca9a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 24, 2016 at 11:43 AM, Andrei Popov wrote: > The current design is documented in the TBNEGO I-D; let=E2=80=99s get cla= rity on > the competing proposal, so that we can get a consensus call on the mailin= g > list and let the WG pick one option or the other. > > > > My current understanding of the competing proposal is as follows > (proponents please correct me if I got it wrong): > > 1. Remove the token_binding_version field from the token_binding > extension; > > 2. Pick random unassigned a TLS extension IDs for each draft > version; > We don't need to do this for every draft version, only those that make breaking changes. (Of the past 8 drafts, I think there have been about 4 breaking changes.) > 3. Finalized TB 1.0 will use a new IANA-assigned TLS extension code > point other than 24 (because TLS extension 24 is currently used by Chrome= , > with token_binding_version in it). > Chrome only sends 24 when the Token Binding experiment is enabled (it defaults to off), so we can move to a new extension number for a draft version (as in #2) and stop using 24. The only case where this could be a problem is if someone manually flipped on TB and then doesn't update Chrome (with automatic updates, this seems unlikely). I don't think we need a new IANA assignment. > > > *From:* Nick Harper [mailto:nharper@google.com] > *Sent:* Wednesday, August 24, 2016 11:14 AM > *To:* Andrei Popov > *Cc:* Brian Campbell ; Bill Cox < > waywardgeek@google.com>; Martin Thomson ; > unbearable@ietf.org > > *Subject:* Re: [Unbearable] TLS extension: version field > > > > Brian is correct that I am generally in favor of removing the version > field from the extension. I think designing a system that works for > production deployment of the standardized spec takes precedence over > experimentation (but not to a point that would prevent experimentation). > Earlier in the thread I explained why the version field won't be useful f= or > production deployment of the standardized spec, and it's also possible to > do experimentation without the version field. > > > > Andrei, > > For experimenting after the TB 1.0 spec is published, you have the > extensions in the TokenBinding struct, which you can use without changing > the version number. If extensions aren't sufficient, then I think you'll > need something more in the negotiation message, meaning that you'll need = a > new TLS extension anyway. > > > > On Wed, Aug 24, 2016 at 10:13 AM, Andrei Popov > wrote: > > =C3=98 I do think that the question of eliminating the token_binding_ver= sion > or not should be considered independently of if/how the draft version can > be communicated for testing prior to the spec(s) finalizing. > > Sure, as long as we end up with a viable design that supports both > experimentation and production deployment. And I don=E2=80=99t expect > experimentation in this space to stop once TB 1.0 specs are published=E2= =80=A6 > > > > Cheers, > > > > Andrei > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Wednesday, August 24, 2016 10:06 AM > *To:* Bill Cox > *Cc:* Martin Thomson ; Nick Harper < > nharper@google.com>; Andrei Popov ; > unbearable@ietf.org > *Subject:* Re: [Unbearable] TLS extension: version field > > > > I shouldn't speak for him but, from previous statements in this thread, i= t > sounded like Nick is in favor of eliminating the version. > > I do think that the question of eliminating the token_binding_version or > not should be considered independently of if/how the draft version can be > communicated for testing prior to the spec(s) finalizing. > > > > > > On Tue, Aug 23, 2016 at 10:35 PM, Bill Cox wrote= : > > I think I see a correlation here: those of us who have worked to build > functional token binding implementations would prefer not to throw the > cards in the air and with major changes, such as eliminating the version. > There are times for innovation, but near the end of a standardization > process is not one of them, IMO. At this point, I would rather see > compatible bug-free implementations. I'll throw my vote in with Nick and > Andrei for moving ahead without changing versioning. It may not be > optimal, but it is good enough. This is not an issue worth delaying the > roll-out of token binding. > > > > Bill > > > > On Tue, Aug 23, 2016 at 5:42 PM, Martin Thomson > wrote: > > On 24 August 2016 at 10:16, Nick Harper wrote: > > I don't think that trying to get a new IANA-assigned number for each > draft > > version that has breaking changes is a very practical approach. > > Were you planning on breaking things often? > > More seriously, most other user users of this space just grab a number > and use it. Then they tell IANA when they finish with their > experiments. > > If you think that you need to change more often, the new experimental > use space is probably a better idea. > > > > > > > --94eb2c1248108cdc95053ad5ca9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 24, 2016 at 11:43 AM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

The current design is documented in the TBNEGO I-D;= let=E2=80=99s get clarity on the competing proposal, so that we can get a = consensus call on the mailing list and let the WG pick one option or the other.

=C2=A0

My current understanding of the competing proposal = is as follows (proponents please correct me if I got it wrong):

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Remove the token_binding_version field from th= e token_binding extension;

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Pick random unassigned a TLS extension IDs for= each draft version;

We don't n= eed to do this for every draft version, only those that make breaking chang= es. (Of the past 8 drafts, I think there have been about 4 breaking changes= .) =C2=A0

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Finalized TB 1.0 will use a new IANA-assigned = TLS extension code point other than 24 (because TLS extension 24 is current= ly used by Chrome, with token_binding_version in it).

Chrome only sends 24 when = the Token Binding experiment is enabled (it defaults to off), so we can mov= e to a new extension number for a draft version (as in #2) and stop using 2= 4. The only case where this could be a problem is if someone manually flipp= ed on TB and then doesn't update Chrome (with automatic updates, this s= eems unlikely). I don't think we need a new IANA assignment.
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

=C2=A0

From: Nick Harper [mailto:nharper@google.com]
Sent: Wednesday, August 24, 2016 11:14 AM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Brian Campbell <bcampbell@pingidentity.com>; Bill Cox <waywardgeek@google.com= >; Martin Thomson <martin.thomson@gmail.com>; unbearable@ietf.org


Subject: Re: [Unbearable] TLS extension: version field=

=C2=A0

Brian is correct that I am generally in favor of rem= oving the version field from the extension. I think designing a system that= works for production deployment of the standardized spec takes precedence = over experimentation (but not to a point that would prevent experimentation). Earlier in the thread I explain= ed why the version field won't be useful for production deployment of t= he standardized spec, and it's also possible to do experimentation with= out the version field.

=C2=A0

Andrei,

For experimenting after the TB 1.0 spec is published= , you have the extensions in the TokenBinding struct, which you can use wit= hout changing the version number. If extensions aren't sufficient, then= I think you'll need something more in the negotiation message, meaning that you'll need a new TLS extension = anyway.

=C2=A0

On Wed, Aug 24, 2016 at 10:13 AM, Andrei Popov <<= a href=3D"mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov= @microsoft.com> wrote:

=C3=98=C2=A0 I do think that the question of eliminating the token_binding_versio= n or not should be considered independently of if/how the draft version can= be communicated for testing prior to the spec(s) finalizing.

Sure, as long as we end up with a viable design tha= t supports both experimentation and production deployment. And I don=E2=80=99t expect experimentation in this space to stop once TB 1.0 s= pecs are published=E2=80=A6

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Brian Campbell [mailto:bcampbell@pin= gidentity.com]
Sent: Wednesday, August 24, 2016 10:06 AM
To: Bill Cox <waywardgeek@google.com>
Cc: Martin Thomson <martin.thomson@gmail.com>; Nick Harper <nharper@google.com>= ; Andrei Popov <Andrei.Popov@microsoft.com>; unbearable@ietf.or= g
Subject: Re: [Unbearable] TLS extension: version field=

=C2=A0

I shouldn't speak= for him but, from previous statements in this thread, it sounded like Nick= is in favor of eliminating the version.

I do think that the question of eliminating the toke= n_binding_version or not should be considered independently of if/how the d= raft version can be communicated for testing prior to the spec(s) finalizing.

=C2=A0

=C2=A0

On Tue, Aug 23, 2016 at 10:35 PM, Bill Cox <waywardgeek@google.c= om> wrote:

I think I see a correlation here: those of us who ha= ve worked to build functional token binding implementations would prefer no= t to throw the cards in the air and with major changes, such as eliminating the version.=C2=A0 There are times for innovation, but= near the end of a standardization process is not one of them, IMO.=C2=A0 A= t this point, I would rather see compatible bug-free implementations.=C2=A0= I'll throw my vote in with Nick and Andrei for moving ahead without changing versioning.=C2=A0 It may not be optimal, but= it is good enough.=C2=A0 This is not an issue worth delaying the roll-out = of token binding.

=C2=A0

Bill<= /u>

=C2=A0

On Tue, Aug 23, 2016 at 5:42 PM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:

On 24 August 2016 at 10:16, Nick Harper <nharper@google.com>= wrote:
> I don't think that trying to get a new IANA-assigned number for ea= ch draft
> version that has breaking changes is a very practical approach.

Were you planning on breaking things often?

More seriously, most other user users of this space just grab a number
and use it.=C2=A0 Then they tell IANA when they finish with their
experiments.

If you think that you need to change more often, the new experimental
use space is probably a better idea.

=C2=A0

=C2=A0

=C2=A0


--94eb2c1248108cdc95053ad5ca9a-- From nobody Wed Aug 24 12:07: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 B0F8712D66A for ; Wed, 24 Aug 2016 12:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2YI6rWNz1cXx for ; Wed, 24 Aug 2016 12:06:56 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0090.outbound.protection.outlook.com [104.47.37.90]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E9B12D66D for ; Wed, 24 Aug 2016 12:06:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=isVtonS/6+ewKreZfIKZYsbYZEsdpoll8KhUEYQJa6A=; b=Hia723qhO8OyQHYkqUM7iACo2HwqEPS/tRs8gjvQQD/s1IgzGg8mcIOSU4dQBtbQkzwtHh5IfwjjLcjA07oDE5Ah+WNN8js94h56zWblR5WUrB124+uqByQCbR+GtE/RZo6vRP7Q9OZ5+b3ob8jiMBqtgSpd0uXfh17OfIupsyI= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2153.namprd03.prod.outlook.com (10.166.206.138) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Wed, 24 Aug 2016 19:06:53 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0587.013; Wed, 24 Aug 2016 19:06:53 +0000 From: Andrei Popov To: Nick Harper Thread-Topic: [Unbearable] TLS extension: version field Thread-Index: AQHR8UE0hAr3fGh5LkSos3djbwbcUaA/MmwAgAAmOoCAAAGk8IAAhvMAgAAFqjCAAAO6AIAA6WmAgAATAoCAABJZgIAV3xfwgAATKACAAFvQgIAAAlRwgAANXQCAAAcGgIAAQVIAgADRnQCAAADEgIAAEkUAgAAEGBCAAAamgIAAAViQ Date: Wed, 24 Aug 2016 19:06:52 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: 474ae48c-15bb-4e39-6a8c-08d3cc51cf4a x-microsoft-exchange-diagnostics: 1; CY1PR03MB2153; 6:0QCzhhVl7eOZcMf4FC3RlOjOvh2cNdVlu+vbA1s3KSYaRyoaRMw1J44qoN11NbwjDoU4YCJaktzlmUNvSf0DyG5MS1sn9eB46KNOC/VFGga7QN55d7XXZfSCtJW1/hRGB5ToWGgbR6IQlniyxQdGkhhyyuFt0GbbVpsbf7u96FMeW5NYYKoMoBcsafk3vmMjvzLykGQKTXRsnsXWiG+IJcxWdupH4WCFrP7vL9klvqIel127q4K+u0ze/ihhYmgFAO6k9kktjF2YV4WJQInTApwdnWblwQ282OyqsQ6oTy5lcTLzNsvwKy5SvpM7vkhFiUxzSTsKYr7i2/v4cbfmYg==; 5:xpoRUbpXNSKvpYq+VbKtndm72Y2Ah+C1rTstO6A3meKe7YtsSgrZNjf3lvnYDdUVRyMwxaj9Zq7V0xnW+H1eL1l/zmUlGBb+zK0yyttqDp+1OxtSmFZEN0HnP3O6qs8K7EZkEfosREC3ZyDBYUuufQ==; 24:vnKk7kPecOWwTv4rQpC6M8bA9VMuUS33BGpFcrj9vJvqtmw4yoqZNK+1WraCs2XXKUgzwuN8y0CMlirJ31MZb3J5ReLjYLp6OG1LjqM4Vos=; 7:d7P8Ney5HVF4KWgJ8E6JvKROk4Wm4tj/gXQld4sdvYqfja0FX95myMyCiXyfocDBcvgX1rDsvTUxeC6X8B4pa2bzddF1PLpvnuRmqYMmMYKQigx8a/A8ofbCg6OLpKoKZT9EEFtQNZwFsxNA73cRYVW9H6OKKLIqiC95qsYfDT4CTqjZHXHCHFqBGutExV67yq5QZMt7tOOeic1XWMfZHwCGTURXqMBG4yACo2C6nl75/STOOIwOzfIVC3SuO2RA x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2153; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2153; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2153; x-forefront-prvs: 0044C17179 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(24454002)(199003)(6116002)(19580405001)(10090500001)(2906002)(586003)(76576001)(4326007)(102836003)(3660700001)(10290500002)(19609705001)(790700001)(68736007)(3280700002)(2950100001)(101416001)(5002640100001)(8990500004)(10400500002)(86362001)(5660300001)(15975445007)(77096005)(2900100001)(122556002)(19625215002)(189998001)(33656002)(16236675004)(86612001)(19580395003)(105586002)(106356001)(54356999)(93886004)(97736004)(110136002)(106116001)(561944003)(5005710100001)(76176999)(99286002)(19300405004)(87936001)(74316002)(7696003)(8676002)(81156014)(81166006)(9686002)(92566002)(50986999)(7846002)(8936002)(11100500001)(7736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2153; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB2155CAB1FFA33A59831186388CEA0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Aug 2016 19:06:53.0268 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2153 Archived-At: Cc: "unbearable@ietf.org" , Brian Campbell , Martin Thomson , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 24 Aug 2016 19:06:59 -0000 --_000_CY1PR03MB2155CAB1FFA33A59831186388CEA0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlbiB0aGUgcHJvcG9zYWwgc2VlbXMgdG8gYmUgYXMgZm9sbG93czoNCg0KMS4gICAgICAgICBS ZW1vdmUgdGhlIHRva2VuX2JpbmRpbmdfdmVyc2lvbiBmaWVsZCBmcm9tIHRoZSB0b2tlbl9iaW5k aW5nIGV4dGVuc2lvbjsNCg0KMi4gICAgICAgICBQaWNrIGEgcmFuZG9tIHVuYXNzaWduZWQgVExT IGV4dGVuc2lvbiBJRCBmb3IgZWFjaCBUQiBkcmFmdCB0aGF0IGJyZWFrcyBjb21wYXRpYmlsaXR5 Ow0KDQozLiAgICAgICAgIEEgVExTIGNsaWVudCBjYW4gYWR2ZXJ0aXNlIG11bHRpcGxlIG9mIHRo ZXNlIFRMUyBleHRlbnNpb24gSURzIGluIHRoZSBzYW1lIENsaWVudEhlbGxvLCB0aGUgc2VydmVy IGhhcyB0byBwaWNrIG5vIG1vcmUgdGhhbiBvbmU7DQoNCjQuICAgICAgICAgRmluYWxpemVkIFRC IDEuMCB3aWxsIHVzZSB0aGUgY3VycmVudGx5IGFzc2lnbmVkIFRMUyBleHRlbnNpb24gY29kZSBw b2ludCAyNC4NCg0KSXMgdGhpcyBzdW1tYXJ5IGNvcnJlY3Q/DQpGcm9tOiBOaWNrIEhhcnBlciBb bWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDI0LCAy MDE2IDExOjUzIEFNDQpUbzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNv bT4NCkNjOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+OyBCaWxs IENveCA8d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbT47IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhv bXNvbkBnbWFpbC5jb20+OyB1bmJlYXJhYmxlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1VuYmVh cmFibGVdIFRMUyBleHRlbnNpb246IHZlcnNpb24gZmllbGQNCg0KDQoNCk9uIFdlZCwgQXVnIDI0 LCAyMDE2IGF0IDExOjQzIEFNLCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQu Y29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KVGhlIGN1cnJl bnQgZGVzaWduIGlzIGRvY3VtZW50ZWQgaW4gdGhlIFRCTkVHTyBJLUQ7IGxldOKAmXMgZ2V0IGNs YXJpdHkgb24gdGhlIGNvbXBldGluZyBwcm9wb3NhbCwgc28gdGhhdCB3ZSBjYW4gZ2V0IGEgY29u c2Vuc3VzIGNhbGwgb24gdGhlIG1haWxpbmcgbGlzdCBhbmQgbGV0IHRoZSBXRyBwaWNrIG9uZSBv cHRpb24gb3IgdGhlIG90aGVyLg0KDQpNeSBjdXJyZW50IHVuZGVyc3RhbmRpbmcgb2YgdGhlIGNv bXBldGluZyBwcm9wb3NhbCBpcyBhcyBmb2xsb3dzIChwcm9wb25lbnRzIHBsZWFzZSBjb3JyZWN0 IG1lIGlmIEkgZ290IGl0IHdyb25nKToNCg0KMS4gICAgICAgUmVtb3ZlIHRoZSB0b2tlbl9iaW5k aW5nX3ZlcnNpb24gZmllbGQgZnJvbSB0aGUgdG9rZW5fYmluZGluZyBleHRlbnNpb247DQoNCjIu ICAgICAgIFBpY2sgcmFuZG9tIHVuYXNzaWduZWQgYSBUTFMgZXh0ZW5zaW9uIElEcyBmb3IgZWFj aCBkcmFmdCB2ZXJzaW9uOw0KV2UgZG9uJ3QgbmVlZCB0byBkbyB0aGlzIGZvciBldmVyeSBkcmFm dCB2ZXJzaW9uLCBvbmx5IHRob3NlIHRoYXQgbWFrZSBicmVha2luZyBjaGFuZ2VzLiAoT2YgdGhl IHBhc3QgOCBkcmFmdHMsIEkgdGhpbmsgdGhlcmUgaGF2ZSBiZWVuIGFib3V0IDQgYnJlYWtpbmcg Y2hhbmdlcy4pDQoNCjMuICAgICAgIEZpbmFsaXplZCBUQiAxLjAgd2lsbCB1c2UgYSBuZXcgSUFO QS1hc3NpZ25lZCBUTFMgZXh0ZW5zaW9uIGNvZGUgcG9pbnQgb3RoZXIgdGhhbiAyNCAoYmVjYXVz ZSBUTFMgZXh0ZW5zaW9uIDI0IGlzIGN1cnJlbnRseSB1c2VkIGJ5IENocm9tZSwgd2l0aCB0b2tl bl9iaW5kaW5nX3ZlcnNpb24gaW4gaXQpLg0KQ2hyb21lIG9ubHkgc2VuZHMgMjQgd2hlbiB0aGUg VG9rZW4gQmluZGluZyBleHBlcmltZW50IGlzIGVuYWJsZWQgKGl0IGRlZmF1bHRzIHRvIG9mZiks IHNvIHdlIGNhbiBtb3ZlIHRvIGEgbmV3IGV4dGVuc2lvbiBudW1iZXIgZm9yIGEgZHJhZnQgdmVy c2lvbiAoYXMgaW4gIzIpIGFuZCBzdG9wIHVzaW5nIDI0LiBUaGUgb25seSBjYXNlIHdoZXJlIHRo aXMgY291bGQgYmUgYSBwcm9ibGVtIGlzIGlmIHNvbWVvbmUgbWFudWFsbHkgZmxpcHBlZCBvbiBU QiBhbmQgdGhlbiBkb2Vzbid0IHVwZGF0ZSBDaHJvbWUgKHdpdGggYXV0b21hdGljIHVwZGF0ZXMs IHRoaXMgc2VlbXMgdW5saWtlbHkpLiBJIGRvbid0IHRoaW5rIHdlIG5lZWQgYSBuZXcgSUFOQSBh c3NpZ25tZW50Lg0KDQpGcm9tOiBOaWNrIEhhcnBlciBbbWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNv bTxtYWlsdG86bmhhcnBlckBnb29nbGUuY29tPl0NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDI0 LCAyMDE2IDExOjE0IEFNDQpUbzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0 LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+Pg0KQ2M6IEJyaWFuIENhbXBi ZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb20+PjsgQmlsbCBDb3ggPHdheXdhcmRnZWVrQGdvb2dsZS5jb208bWFpbHRvOndheXdh cmRnZWVrQGdvb2dsZS5jb20+PjsgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWls LmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj47IHVuYmVhcmFibGVAaWV0Zi5v cmc8bWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJs ZV0gVExTIGV4dGVuc2lvbjogdmVyc2lvbiBmaWVsZA0KDQpCcmlhbiBpcyBjb3JyZWN0IHRoYXQg SSBhbSBnZW5lcmFsbHkgaW4gZmF2b3Igb2YgcmVtb3ZpbmcgdGhlIHZlcnNpb24gZmllbGQgZnJv bSB0aGUgZXh0ZW5zaW9uLiBJIHRoaW5rIGRlc2lnbmluZyBhIHN5c3RlbSB0aGF0IHdvcmtzIGZv ciBwcm9kdWN0aW9uIGRlcGxveW1lbnQgb2YgdGhlIHN0YW5kYXJkaXplZCBzcGVjIHRha2VzIHBy ZWNlZGVuY2Ugb3ZlciBleHBlcmltZW50YXRpb24gKGJ1dCBub3QgdG8gYSBwb2ludCB0aGF0IHdv dWxkIHByZXZlbnQgZXhwZXJpbWVudGF0aW9uKS4gRWFybGllciBpbiB0aGUgdGhyZWFkIEkgZXhw bGFpbmVkIHdoeSB0aGUgdmVyc2lvbiBmaWVsZCB3b24ndCBiZSB1c2VmdWwgZm9yIHByb2R1Y3Rp b24gZGVwbG95bWVudCBvZiB0aGUgc3RhbmRhcmRpemVkIHNwZWMsIGFuZCBpdCdzIGFsc28gcG9z c2libGUgdG8gZG8gZXhwZXJpbWVudGF0aW9uIHdpdGhvdXQgdGhlIHZlcnNpb24gZmllbGQuDQoN CkFuZHJlaSwNCkZvciBleHBlcmltZW50aW5nIGFmdGVyIHRoZSBUQiAxLjAgc3BlYyBpcyBwdWJs aXNoZWQsIHlvdSBoYXZlIHRoZSBleHRlbnNpb25zIGluIHRoZSBUb2tlbkJpbmRpbmcgc3RydWN0 LCB3aGljaCB5b3UgY2FuIHVzZSB3aXRob3V0IGNoYW5naW5nIHRoZSB2ZXJzaW9uIG51bWJlci4g SWYgZXh0ZW5zaW9ucyBhcmVuJ3Qgc3VmZmljaWVudCwgdGhlbiBJIHRoaW5rIHlvdSdsbCBuZWVk IHNvbWV0aGluZyBtb3JlIGluIHRoZSBuZWdvdGlhdGlvbiBtZXNzYWdlLCBtZWFuaW5nIHRoYXQg eW91J2xsIG5lZWQgYSBuZXcgVExTIGV4dGVuc2lvbiBhbnl3YXkuDQoNCk9uIFdlZCwgQXVnIDI0 LCAyMDE2IGF0IDEwOjEzIEFNLCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQu Y29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KDQo+ICBJIGRv IHRoaW5rIHRoYXQgdGhlIHF1ZXN0aW9uIG9mIGVsaW1pbmF0aW5nIHRoZSB0b2tlbl9iaW5kaW5n X3ZlcnNpb24gb3Igbm90IHNob3VsZCBiZSBjb25zaWRlcmVkIGluZGVwZW5kZW50bHkgb2YgaWYv aG93IHRoZSBkcmFmdCB2ZXJzaW9uIGNhbiBiZSBjb21tdW5pY2F0ZWQgZm9yIHRlc3RpbmcgcHJp b3IgdG8gdGhlIHNwZWMocykgZmluYWxpemluZy4NClN1cmUsIGFzIGxvbmcgYXMgd2UgZW5kIHVw IHdpdGggYSB2aWFibGUgZGVzaWduIHRoYXQgc3VwcG9ydHMgYm90aCBleHBlcmltZW50YXRpb24g YW5kIHByb2R1Y3Rpb24gZGVwbG95bWVudC4gQW5kIEkgZG9u4oCZdCBleHBlY3QgZXhwZXJpbWVu dGF0aW9uIGluIHRoaXMgc3BhY2UgdG8gc3RvcCBvbmNlIFRCIDEuMCBzcGVjcyBhcmUgcHVibGlz aGVk4oCmDQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWls dG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRp dHkuY29tPl0NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDI0LCAyMDE2IDEwOjA2IEFNDQpUbzog QmlsbCBDb3ggPHdheXdhcmRnZWVrQGdvb2dsZS5jb208bWFpbHRvOndheXdhcmRnZWVrQGdvb2ds ZS5jb20+Pg0KQ2M6IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFp bHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+OyBOaWNrIEhhcnBlciA8bmhhcnBlckBnb29n bGUuY29tPG1haWx0bzpuaGFycGVyQGdvb2dsZS5jb20+PjsgQW5kcmVpIFBvcG92IDxBbmRyZWku UG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+Pjsg dW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZz4NClN1YmplY3Q6 IFJlOiBbVW5iZWFyYWJsZV0gVExTIGV4dGVuc2lvbjogdmVyc2lvbiBmaWVsZA0KDQpJIHNob3Vs ZG4ndCBzcGVhayBmb3IgaGltIGJ1dCwgZnJvbSBwcmV2aW91cyBzdGF0ZW1lbnRzIGluIHRoaXMg dGhyZWFkLCBpdCBzb3VuZGVkIGxpa2UgTmljayBpcyBpbiBmYXZvciBvZiBlbGltaW5hdGluZyB0 aGUgdmVyc2lvbi4NCkkgZG8gdGhpbmsgdGhhdCB0aGUgcXVlc3Rpb24gb2YgZWxpbWluYXRpbmcg dGhlIHRva2VuX2JpbmRpbmdfdmVyc2lvbiBvciBub3Qgc2hvdWxkIGJlIGNvbnNpZGVyZWQgaW5k ZXBlbmRlbnRseSBvZiBpZi9ob3cgdGhlIGRyYWZ0IHZlcnNpb24gY2FuIGJlIGNvbW11bmljYXRl ZCBmb3IgdGVzdGluZyBwcmlvciB0byB0aGUgc3BlYyhzKSBmaW5hbGl6aW5nLg0KDQoNCk9uIFR1 ZSwgQXVnIDIzLCAyMDE2IGF0IDEwOjM1IFBNLCBCaWxsIENveCA8d2F5d2FyZGdlZWtAZ29vZ2xl LmNvbTxtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KSSB0aGluayBJIHNl ZSBhIGNvcnJlbGF0aW9uIGhlcmU6IHRob3NlIG9mIHVzIHdobyBoYXZlIHdvcmtlZCB0byBidWls ZCBmdW5jdGlvbmFsIHRva2VuIGJpbmRpbmcgaW1wbGVtZW50YXRpb25zIHdvdWxkIHByZWZlciBu b3QgdG8gdGhyb3cgdGhlIGNhcmRzIGluIHRoZSBhaXIgYW5kIHdpdGggbWFqb3IgY2hhbmdlcywg c3VjaCBhcyBlbGltaW5hdGluZyB0aGUgdmVyc2lvbi4gIFRoZXJlIGFyZSB0aW1lcyBmb3IgaW5u b3ZhdGlvbiwgYnV0IG5lYXIgdGhlIGVuZCBvZiBhIHN0YW5kYXJkaXphdGlvbiBwcm9jZXNzIGlz IG5vdCBvbmUgb2YgdGhlbSwgSU1PLiAgQXQgdGhpcyBwb2ludCwgSSB3b3VsZCByYXRoZXIgc2Vl IGNvbXBhdGlibGUgYnVnLWZyZWUgaW1wbGVtZW50YXRpb25zLiAgSSdsbCB0aHJvdyBteSB2b3Rl IGluIHdpdGggTmljayBhbmQgQW5kcmVpIGZvciBtb3ZpbmcgYWhlYWQgd2l0aG91dCBjaGFuZ2lu ZyB2ZXJzaW9uaW5nLiAgSXQgbWF5IG5vdCBiZSBvcHRpbWFsLCBidXQgaXQgaXMgZ29vZCBlbm91 Z2guICBUaGlzIGlzIG5vdCBhbiBpc3N1ZSB3b3J0aCBkZWxheWluZyB0aGUgcm9sbC1vdXQgb2Yg dG9rZW4gYmluZGluZy4NCg0KQmlsbA0KDQpPbiBUdWUsIEF1ZyAyMywgMjAxNiBhdCA1OjQyIFBN LCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb20+PiB3cm90ZToNCk9uIDI0IEF1Z3VzdCAyMDE2IGF0IDEwOjE2LCBO aWNrIEhhcnBlciA8bmhhcnBlckBnb29nbGUuY29tPG1haWx0bzpuaGFycGVyQGdvb2dsZS5jb20+ PiB3cm90ZToNCj4gSSBkb24ndCB0aGluayB0aGF0IHRyeWluZyB0byBnZXQgYSBuZXcgSUFOQS1h c3NpZ25lZCBudW1iZXIgZm9yIGVhY2ggZHJhZnQNCj4gdmVyc2lvbiB0aGF0IGhhcyBicmVha2lu ZyBjaGFuZ2VzIGlzIGEgdmVyeSBwcmFjdGljYWwgYXBwcm9hY2guDQoNCldlcmUgeW91IHBsYW5u aW5nIG9uIGJyZWFraW5nIHRoaW5ncyBvZnRlbj8NCg0KTW9yZSBzZXJpb3VzbHksIG1vc3Qgb3Ro ZXIgdXNlciB1c2VycyBvZiB0aGlzIHNwYWNlIGp1c3QgZ3JhYiBhIG51bWJlcg0KYW5kIHVzZSBp dC4gIFRoZW4gdGhleSB0ZWxsIElBTkEgd2hlbiB0aGV5IGZpbmlzaCB3aXRoIHRoZWlyDQpleHBl cmltZW50cy4NCg0KSWYgeW91IHRoaW5rIHRoYXQgeW91IG5lZWQgdG8gY2hhbmdlIG1vcmUgb2Z0 ZW4sIHRoZSBuZXcgZXhwZXJpbWVudGFsDQp1c2Ugc3BhY2UgaXMgcHJvYmFibHkgYSBiZXR0ZXIg aWRlYS4NCg0KDQoNCg0K --_000_CY1PR03MB2155CAB1FFA33A59831186388CEA0CY1PR03MB2155namp_ 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 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpwLm0yMTQ2NDE0OTA3MDY1MzUwMzI5bXNvbGlzdHBhcmFncmFwaCwgbGkubTIx NDY0MTQ5MDcwNjUzNTAzMjltc29saXN0cGFyYWdyYXBoLCBkaXYubTIxNDY0MTQ5MDcwNjUzNTAz Mjltc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOm1fMjE0NjQxNDkwNzA2NTM1MDMy OW1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJp Zjt9DQpwLm0yMTQ2NDE0OTA3MDY1MzUwMzI5bTY2ODYyMjk0NTUzMzY0Njc2NTNtc29saXN0cGFy YWdyYXBoLCBsaS5tMjE0NjQxNDkwNzA2NTM1MDMyOW02Njg2MjI5NDU1MzM2NDY3NjUzbXNvbGlz dHBhcmFncmFwaCwgZGl2Lm0yMTQ2NDE0OTA3MDY1MzUwMzI5bTY2ODYyMjk0NTUzMzY0Njc2NTNt c29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOm1fMjE0NjQxNDkwNzA2NTM1MDMyOW02 Njg2MjI5NDU1MzM2NDY3NjUzbXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEyMjE1OTQ0MzU7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDEwMjg0OTQ2IC0y MDc1MjUxMzUwIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3 Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu LWxlZnQ6MzkuMHB0Ow0KCXRleHQtaW5kZW50Oi0yMS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFu LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXtt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K CXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxw aGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDot OS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+VGhlbiB0aGUgcHJvcG9zYWwgc2VlbXMgdG8gYmUgYXMgZm9sbG93 czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0ibTIxNDY0MTQ5MDcwNjUzNTAzMjlt c29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzkuMHB0O3RleHQtaW5kZW50Oi0y MS4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZW1vdmUgdGhlIHRva2VuX2JpbmRpbmdfdmVyc2lv biBmaWVsZCBmcm9tIHRoZSB0b2tlbl9iaW5kaW5nIGV4dGVuc2lvbjs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0ibTIxNDY0MTQ5MDcwNjUzNTAzMjltc29saXN0cGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzkuMHB0O3RleHQtaW5kZW50Oi0yMS4wcHQ7bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5QaWNrIGEgcmFuZG9tIHVuYXNzaWduZWQgVExTIGV4dGVuc2lvbiBJRCBmb3IgZWFj aCBUQiBkcmFmdCB0aGF0IGJyZWFrcyBjb21wYXRpYmlsaXR5OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJtMjE0NjQxNDkwNzA2NTM1MDMyOW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDozOS4wcHQ7dGV4dC1pbmRlbnQ6LTIxLjBwdDttc28tbGlzdDpsMCBsZXZl bDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkEgVExTIGNsaWVudCBjYW4gYWR2ZXJ0aXNlIG11bHRpcGxlIG9mIHRoZXNlIFRMUyBleHRl bnNpb24gSURzIGluIHRoZSBzYW1lIENsaWVudEhlbGxvLCB0aGUgc2VydmVyIGhhcyB0byBwaWNr IG5vIG1vcmUgdGhhbiBvbmU7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Im0yMTQ2 NDE0OTA3MDY1MzUwMzI5bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM5LjBw dDt0ZXh0LWluZGVudDotMjEuMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+NC48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RmluYWxpemVkIFRCIDEu MCB3aWxsIHVzZSB0aGUgY3VycmVudGx5IGFzc2lnbmVkIFRMUyBleHRlbnNpb24gY29kZSBwb2lu dCAyNC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0ibTIxNDY0MTQ5MDcwNjUzNTAz Mjltc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklzIHRoaXMgc3VtbWFyeSBjb3Jy ZWN0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE5pY2sgSGFycGVy IFttYWlsdG86bmhhcnBlckBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2Rh eSwgQXVndXN0IDI0LCAyMDE2IDExOjUzIEFNPGJyPg0KPGI+VG86PC9iPiBBbmRyZWkgUG9wb3Yg Jmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gQnJpYW4g Q2FtcGJlbGwgJmx0O2JjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tJmd0OzsgQmlsbCBDb3ggJmx0 O3dheXdhcmRnZWVrQGdvb2dsZS5jb20mZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRo b21zb25AZ21haWwuY29tJmd0OzsgdW5iZWFyYWJsZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogW1VuYmVhcmFibGVdIFRMUyBleHRlbnNpb246IHZlcnNpb24gZmllbGQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEF1ZyAyNCwgMjAxNiBhdCAxMTo0MyBBTSwgQW5k cmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20i IHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBjdXJyZW50IGRlc2lnbiBpcyBkb2N1bWVu dGVkIGluIHRoZSBUQk5FR08gSS1EOyBsZXTigJlzIGdldCBjbGFyaXR5IG9uIHRoZSBjb21wZXRp bmcgcHJvcG9zYWwsIHNvIHRoYXQgd2UgY2FuIGdldA0KIGEgY29uc2Vuc3VzIGNhbGwgb24gdGhl IG1haWxpbmcgbGlzdCBhbmQgbGV0IHRoZSBXRyBwaWNrIG9uZSBvcHRpb24gb3IgdGhlIG90aGVy Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+TXkgY3VycmVudCB1bmRlcnN0YW5kaW5nIG9mIHRoZSBjb21w ZXRpbmcgcHJvcG9zYWwgaXMgYXMgZm9sbG93cyAocHJvcG9uZW50cyBwbGVhc2UgY29ycmVjdCBt ZSBpZiBJIGdvdCBpdCB3cm9uZyk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0y MTQ2NDE0OTA3MDY1MzUwMzI5bXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4xLjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlbW92ZSB0aGUgdG9rZW5f YmluZGluZ192ZXJzaW9uIGZpZWxkIGZyb20gdGhlIHRva2VuX2JpbmRpbmcgZXh0ZW5zaW9uOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtMjE0NjQxNDkwNzA2NTM1MDMyOW1zb2xp c3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Mi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5QaWNrIHJhbmRvbSB1bmFzc2lnbmVkIGEgVExTIGV4dGVuc2lvbiBJ RHMgZm9yIGVhY2ggZHJhZnQgdmVyc2lvbjs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGRv bid0IG5lZWQgdG8gZG8gdGhpcyBmb3IgZXZlcnkgZHJhZnQgdmVyc2lvbiwgb25seSB0aG9zZSB0 aGF0IG1ha2UgYnJlYWtpbmcgY2hhbmdlcy4gKE9mIHRoZSBwYXN0IDggZHJhZnRzLCBJIHRoaW5r IHRoZXJlIGhhdmUgYmVlbiBhYm91dCA0IGJyZWFraW5nIGNoYW5nZXMuKSAmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im0y MTQ2NDE0OTA3MDY1MzUwMzI5bXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4zLjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZpbmFsaXplZCBUQiAxLjAg d2lsbCB1c2UgYSBuZXcgSUFOQS1hc3NpZ25lZCBUTFMgZXh0ZW5zaW9uIGNvZGUgcG9pbnQgb3Ro ZXIgdGhhbiAyNCAoYmVjYXVzZSBUTFMgZXh0ZW5zaW9uIDI0IGlzIGN1cnJlbnRseSB1c2VkIGJ5 IENocm9tZSwgd2l0aCB0b2tlbl9iaW5kaW5nX3ZlcnNpb24gaW4gaXQpLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Q2hyb21lIG9ubHkgc2VuZHMgMjQgd2hlbiB0aGUgVG9rZW4gQmluZGluZyBl eHBlcmltZW50IGlzIGVuYWJsZWQgKGl0IGRlZmF1bHRzIHRvIG9mZiksIHNvIHdlIGNhbiBtb3Zl IHRvIGEgbmV3IGV4dGVuc2lvbiBudW1iZXIgZm9yIGEgZHJhZnQgdmVyc2lvbiAoYXMgaW4gIzIp IGFuZCBzdG9wIHVzaW5nIDI0LiBUaGUgb25seSBjYXNlIHdoZXJlIHRoaXMgY291bGQgYmUgYSBw cm9ibGVtIGlzIGlmIHNvbWVvbmUNCiBtYW51YWxseSBmbGlwcGVkIG9uIFRCIGFuZCB0aGVuIGRv ZXNuJ3QgdXBkYXRlIENocm9tZSAod2l0aCBhdXRvbWF0aWMgdXBkYXRlcywgdGhpcyBzZWVtcyB1 bmxpa2VseSkuIEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCBhIG5ldyBJQU5BIGFzc2lnbm1lbnQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE5pY2sgSGFycGVyIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOm5oYXJwZXJAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5oYXJwZXJAZ29vZ2xlLmNv bTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMjQsIDIwMTYgMTE6 MTQgQU08YnI+DQo8Yj5Ubzo8L2I+IEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFu ZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92QG1p Y3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gQnJpYW4gQ2FtcGJlbGwgJmx0Ozxh IGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsi PmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDs7IEJpbGwgQ294ICZsdDs8YSBocmVm PSJtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndheXdhcmRn ZWVrQGdvb2dsZS5jb208L2E+Jmd0OzsgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0 bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNv bkBnbWFpbC5jb208L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzp1bmJlYXJhYmxlQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+dW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIFRMUyBleHRlbnNpb246IHZlcnNpb24gZmllbGQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5CcmlhbiBpcyBjb3JyZWN0IHRoYXQgSSBhbSBnZW5lcmFsbHkgaW4gZmF2b3Igb2YgcmVt b3ZpbmcgdGhlIHZlcnNpb24gZmllbGQgZnJvbSB0aGUgZXh0ZW5zaW9uLiBJIHRoaW5rIGRlc2ln bmluZyBhIHN5c3RlbSB0aGF0IHdvcmtzIGZvciBwcm9kdWN0aW9uIGRlcGxveW1lbnQgb2YgdGhl IHN0YW5kYXJkaXplZA0KIHNwZWMgdGFrZXMgcHJlY2VkZW5jZSBvdmVyIGV4cGVyaW1lbnRhdGlv biAoYnV0IG5vdCB0byBhIHBvaW50IHRoYXQgd291bGQgcHJldmVudCBleHBlcmltZW50YXRpb24p LiBFYXJsaWVyIGluIHRoZSB0aHJlYWQgSSBleHBsYWluZWQgd2h5IHRoZSB2ZXJzaW9uIGZpZWxk IHdvbid0IGJlIHVzZWZ1bCBmb3IgcHJvZHVjdGlvbiBkZXBsb3ltZW50IG9mIHRoZSBzdGFuZGFy ZGl6ZWQgc3BlYywgYW5kIGl0J3MgYWxzbyBwb3NzaWJsZSB0byBkbyBleHBlcmltZW50YXRpb24N CiB3aXRob3V0IHRoZSB2ZXJzaW9uIGZpZWxkLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbmRyZWksPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZvciBleHBlcmltZW50aW5nIGFmdGVy IHRoZSBUQiAxLjAgc3BlYyBpcyBwdWJsaXNoZWQsIHlvdSBoYXZlIHRoZSBleHRlbnNpb25zIGlu IHRoZSBUb2tlbkJpbmRpbmcgc3RydWN0LCB3aGljaCB5b3UgY2FuIHVzZSB3aXRob3V0IGNoYW5n aW5nIHRoZSB2ZXJzaW9uIG51bWJlci4gSWYgZXh0ZW5zaW9ucyBhcmVuJ3QNCiBzdWZmaWNpZW50 LCB0aGVuIEkgdGhpbmsgeW91J2xsIG5lZWQgc29tZXRoaW5nIG1vcmUgaW4gdGhlIG5lZ290aWF0 aW9uIG1lc3NhZ2UsIG1lYW5pbmcgdGhhdCB5b3UnbGwgbmVlZCBhIG5ldyBUTFMgZXh0ZW5zaW9u IGFueXdheS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBBdWcgMjQsIDIwMTYgYXQgMTA6MTMgQU0sIEFuZHJl aSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIiB0 YXJnZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTIxNDY0MTQ5MDcwNjUzNTAzMjltNjY4 NjIyOTQ1NTMzNjQ2NzY1M21zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpXaW5nZGluZ3MiPsOYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNw Ow0KPC9zcGFuPkkgZG8gdGhpbmsgdGhhdCB0aGUgcXVlc3Rpb24gb2YgZWxpbWluYXRpbmcgdGhl IHRva2VuX2JpbmRpbmdfdmVyc2lvbiBvciBub3Qgc2hvdWxkIGJlIGNvbnNpZGVyZWQgaW5kZXBl bmRlbnRseSBvZiBpZi9ob3cgdGhlIGRyYWZ0IHZlcnNpb24gY2FuIGJlIGNvbW11bmljYXRlZCBm b3IgdGVzdGluZyBwcmlvciB0byB0aGUgc3BlYyhzKSBmaW5hbGl6aW5nLg0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U3VyZSwgYXMgbG9u ZyBhcyB3ZSBlbmQgdXAgd2l0aCBhIHZpYWJsZSBkZXNpZ24gdGhhdCBzdXBwb3J0cyBib3RoIGV4 cGVyaW1lbnRhdGlvbiBhbmQgcHJvZHVjdGlvbiBkZXBsb3ltZW50LiBBbmQNCiBJIGRvbuKAmXQg ZXhwZWN0IGV4cGVyaW1lbnRhdGlvbiBpbiB0aGlzIHNwYWNlIHRvIHN0b3Agb25jZSBUQiAxLjAg c3BlY3MgYXJlIHB1Ymxpc2hlZOKApjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q2hlZXJzLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+QW5kcmVpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gQnJpYW4gQ2FtcGJlbGwgW21haWx0bzo8YSBocmVmPSJtYWlsdG86 YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGlu Z2lkZW50aXR5LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3Qg MjQsIDIwMTYgMTA6MDYgQU08YnI+DQo8Yj5Ubzo8L2I+IEJpbGwgQ294ICZsdDs8YSBocmVmPSJt YWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndheXdhcmRnZWVr QGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gTWFydGluIFRob21zb24gJmx0Ozxh IGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5t YXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OzsgTmljayBIYXJwZXIgJmx0OzxhIGhyZWY9 Im1haWx0bzpuaGFycGVyQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5uaGFycGVyQGdvb2ds ZS5jb208L2E+Jmd0OzsgQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBv cG92QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0 LmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj51bmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW1VuYmVhcmFibGVdIFRMUyBleHRlbnNpb246IHZlcnNpb24gZmllbGQ8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgc2hvdWxkbid0IHNwZWFrIGZvciBoaW0g YnV0LCBmcm9tIHByZXZpb3VzIHN0YXRlbWVudHMgaW4gdGhpcyB0aHJlYWQsIGl0IHNvdW5kZWQg bGlrZSBOaWNrIGlzIGluIGZhdm9yIG9mIGVsaW1pbmF0aW5nIHRoZSB2ZXJzaW9uLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBk byB0aGluayB0aGF0IHRoZSBxdWVzdGlvbiBvZiBlbGltaW5hdGluZyB0aGUgdG9rZW5fYmluZGlu Z192ZXJzaW9uIG9yIG5vdCBzaG91bGQgYmUgY29uc2lkZXJlZCBpbmRlcGVuZGVudGx5IG9mIGlm L2hvdyB0aGUgZHJhZnQgdmVyc2lvbiBjYW4gYmUgY29tbXVuaWNhdGVkIGZvciB0ZXN0aW5nIHBy aW9yDQogdG8gdGhlIHNwZWMocykgZmluYWxpemluZy4gPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgQXVnIDIzLCAyMDE2IGF0 IDEwOjM1IFBNLCBCaWxsIENveCAmbHQ7PGEgaHJlZj0ibWFpbHRvOndheXdhcmRnZWVrQGdvb2ds ZS5jb20iIHRhcmdldD0iX2JsYW5rIj53YXl3YXJkZ2Vla0Bnb29nbGUuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhpbmsgSSBzZWUg YSBjb3JyZWxhdGlvbiBoZXJlOiB0aG9zZSBvZiB1cyB3aG8gaGF2ZSB3b3JrZWQgdG8gYnVpbGQg ZnVuY3Rpb25hbCB0b2tlbiBiaW5kaW5nIGltcGxlbWVudGF0aW9ucyB3b3VsZCBwcmVmZXIgbm90 IHRvIHRocm93IHRoZSBjYXJkcyBpbiB0aGUgYWlyIGFuZCB3aXRoIG1ham9yIGNoYW5nZXMsDQog c3VjaCBhcyBlbGltaW5hdGluZyB0aGUgdmVyc2lvbi4mbmJzcDsgVGhlcmUgYXJlIHRpbWVzIGZv ciBpbm5vdmF0aW9uLCBidXQgbmVhciB0aGUgZW5kIG9mIGEgc3RhbmRhcmRpemF0aW9uIHByb2Nl c3MgaXMgbm90IG9uZSBvZiB0aGVtLCBJTU8uJm5ic3A7IEF0IHRoaXMgcG9pbnQsIEkgd291bGQg cmF0aGVyIHNlZSBjb21wYXRpYmxlIGJ1Zy1mcmVlIGltcGxlbWVudGF0aW9ucy4mbmJzcDsgSSds bCB0aHJvdyBteSB2b3RlIGluIHdpdGggTmljayBhbmQgQW5kcmVpIGZvcg0KIG1vdmluZyBhaGVh ZCB3aXRob3V0IGNoYW5naW5nIHZlcnNpb25pbmcuJm5ic3A7IEl0IG1heSBub3QgYmUgb3B0aW1h bCwgYnV0IGl0IGlzIGdvb2QgZW5vdWdoLiZuYnNwOyBUaGlzIGlzIG5vdCBhbiBpc3N1ZSB3b3J0 aCBkZWxheWluZyB0aGUgcm9sbC1vdXQgb2YgdG9rZW4gYmluZGluZy48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4 ODg4OCI+QmlsbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gVHVlLCBBdWcgMjMsIDIwMTYgYXQg NTo0MiBQTSwgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiAyNCBBdWd1c3Qg MjAxNiBhdCAxMDoxNiwgTmljayBIYXJwZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpuaGFycGVyQGdv b2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5uaGFycGVyQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7IEkgZG9uJ3QgdGhpbmsgdGhhdCB0cnlpbmcgdG8gZ2V0IGEgbmV3IElBTkEt YXNzaWduZWQgbnVtYmVyIGZvciBlYWNoIGRyYWZ0PGJyPg0KJmd0OyB2ZXJzaW9uIHRoYXQgaGFz IGJyZWFraW5nIGNoYW5nZXMgaXMgYSB2ZXJ5IHByYWN0aWNhbCBhcHByb2FjaC48YnI+DQo8YnI+ DQpXZXJlIHlvdSBwbGFubmluZyBvbiBicmVha2luZyB0aGluZ3Mgb2Z0ZW4/PGJyPg0KPGJyPg0K TW9yZSBzZXJpb3VzbHksIG1vc3Qgb3RoZXIgdXNlciB1c2VycyBvZiB0aGlzIHNwYWNlIGp1c3Qg Z3JhYiBhIG51bWJlcjxicj4NCmFuZCB1c2UgaXQuJm5ic3A7IFRoZW4gdGhleSB0ZWxsIElBTkEg d2hlbiB0aGV5IGZpbmlzaCB3aXRoIHRoZWlyPGJyPg0KZXhwZXJpbWVudHMuPGJyPg0KPGJyPg0K SWYgeW91IHRoaW5rIHRoYXQgeW91IG5lZWQgdG8gY2hhbmdlIG1vcmUgb2Z0ZW4sIHRoZSBuZXcg ZXhwZXJpbWVudGFsPGJyPg0KdXNlIHNwYWNlIGlzIHByb2JhYmx5IGEgYmV0dGVyIGlkZWEuPG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR03MB2155CAB1FFA33A59831186388CEA0CY1PR03MB2155namp_-- From nobody Wed Aug 24 12:12: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 0B99812D78B for ; Wed, 24 Aug 2016 12:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 6sk7FjxHfZK5 for ; Wed, 24 Aug 2016 12:12:27 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 B6DB912D6AD for ; Wed, 24 Aug 2016 12:12:26 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id m60so5553917uam.3 for ; Wed, 24 Aug 2016 12:12:26 -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=h2JxzC6Er6livTGiFNX80q0AXBnP2fDG1PeMIv+XfhQ=; b=RRMDkxUuLBnuVFTLta8yHRF5+6jXE/7RShG6fq0eQ4S682AM/XrsdZ3ZRNxUR9Vd6e HSPNy/wh4Wzn6qf1WcnzSv8i3Z/5BAoqoEByREOszYCoA5OzB2TjU2Aq3IRTlvK+5dsN n7oUs4JqUGatuu5bEkBJdnfP8vl8SwqXwMj4glRwd6doPGzpZF4JQ1eXwI0vsiUs8Z7e rYogAPASxcxMU9IjJXE7rMxv02A3AFMZ0XzgBjWibrObn7ScoE8N/fOmKkWw5L1Rq6Qu qE/W3qBhYl644Mw/sTeNixCiQ+VnzB7tqxeQIHugKe+FO1hlWd8wc2lhvWh0NquYN/FP jAqw== 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=h2JxzC6Er6livTGiFNX80q0AXBnP2fDG1PeMIv+XfhQ=; b=dUiarCKp1fIYoDAPHQDZ5gmSwY5UGoeTY1ATD1+GpfXk6TbcQ/jdWrl8YCiGTbY0OX OmbX2IEEMDoP6UIEMSs5OkLorm2IIPbz7XYe/KScjH7it1Dg0LxKIkGucFu/YOX4vskB 7Q8IJiVzwesOzfx/KDuQ8mVvAvBoDo3zmc7upKWUV9ew4Nk7aFNZI7sweIYa1C0sA10h hLPwOmvgdrGD6HBQvNCTkPrPjlWuV2dNTYs6ejl0zF0KCPoBo8mQEsFdxtGCZcWWJsT7 uEyy3IbLsZCVcbnjTFYuMfgqL/TUV6g4YLRNWjjYjr25sFH1gz9Oi6FEtOURtptE2LHO +ayQ== X-Gm-Message-State: AEkoout1U2SeWIid2pdp8/Rox5IR3n9QQEYeBVoon8ZQMJPzk/pctajqc7Fze/Mwi6f+fPfLkI3DO5GPUh2h8En7 X-Received: by 10.31.233.5 with SMTP id g5mr2691357vkh.5.1472065945703; Wed, 24 Aug 2016 12:12:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.209 with HTTP; Wed, 24 Aug 2016 12:12:24 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Wed, 24 Aug 2016 12:12:24 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a114fae3cc80b17053ad60f35 Archived-At: Cc: "unbearable@ietf.org" , Brian Campbell , Martin Thomson , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 24 Aug 2016 19:12:29 -0000 --001a114fae3cc80b17053ad60f35 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, that sounds right to me. Martin can correct if he was thinking of something else. On Wednesday, August 24, 2016, Andrei Popov wrote: > Then the proposal seems to be as follows: > > 1. Remove the token_binding_version field from the token_binding > extension; > > 2. Pick a random unassigned TLS extension ID for each TB draft > that breaks compatibility; > > 3. A TLS client can advertise multiple of these TLS extension IDs > in the same ClientHello, the server has to pick no more than one; > > 4. Finalized TB 1.0 will use the currently assigned TLS extension > code point 24. > > Is this summary correct? > > *From:* Nick Harper [mailto:nharper@google.com > ] > *Sent:* Wednesday, August 24, 2016 11:53 AM > *To:* Andrei Popov > > *Cc:* Brian Campbell >; Bill Cox < > waywardgeek@google.com > >; Martin Thomson > >; > unbearable@ietf.org > *Subject:* Re: [Unbearable] TLS extension: version field > > > > > > > > On Wed, Aug 24, 2016 at 11:43 AM, Andrei Popov > wrote: > > The current design is documented in the TBNEGO I-D; let=E2=80=99s get cla= rity on > the competing proposal, so that we can get a consensus call on the mailin= g > list and let the WG pick one option or the other. > > > > My current understanding of the competing proposal is as follows > (proponents please correct me if I got it wrong): > > 1. Remove the token_binding_version field from the token_binding > extension; > > 2. Pick random unassigned a TLS extension IDs for each draft > version; > > We don't need to do this for every draft version, only those that make > breaking changes. (Of the past 8 drafts, I think there have been about 4 > breaking changes.) > > 3. Finalized TB 1.0 will use a new IANA-assigned TLS extension code > point other than 24 (because TLS extension 24 is currently used by Chrome= , > with token_binding_version in it). > > Chrome only sends 24 when the Token Binding experiment is enabled (it > defaults to off), so we can move to a new extension number for a draft > version (as in #2) and stop using 24. The only case where this could be a > problem is if someone manually flipped on TB and then doesn't update Chro= me > (with automatic updates, this seems unlikely). I don't think we need a ne= w > IANA assignment. > > > > *From:* Nick Harper [mailto:nharper@google.com > ] > *Sent:* Wednesday, August 24, 2016 11:14 AM > *To:* Andrei Popov > > *Cc:* Brian Campbell >; Bill Cox < > waywardgeek@google.com > >; Martin Thomson > >; > unbearable@ietf.org > > > *Subject:* Re: [Unbearable] TLS extension: version field > > > > Brian is correct that I am generally in favor of removing the version > field from the extension. I think designing a system that works for > production deployment of the standardized spec takes precedence over > experimentation (but not to a point that would prevent experimentation). > Earlier in the thread I explained why the version field won't be useful f= or > production deployment of the standardized spec, and it's also possible to > do experimentation without the version field. > > > > Andrei, > > For experimenting after the TB 1.0 spec is published, you have the > extensions in the TokenBinding struct, which you can use without changing > the version number. If extensions aren't sufficient, then I think you'll > need something more in the negotiation message, meaning that you'll need = a > new TLS extension anyway. > > > > On Wed, Aug 24, 2016 at 10:13 AM, Andrei Popov > wrote: > > =C3=98 I do think that the question of eliminating the token_binding_ver= sion > or not should be considered independently of if/how the draft version can > be communicated for testing prior to the spec(s) finalizing. > > Sure, as long as we end up with a viable design that supports both > experimentation and production deployment. And I don=E2=80=99t expect > experimentation in this space to stop once TB 1.0 specs are published=E2= =80=A6 > > > > Cheers, > > > > Andrei > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com > ] > *Sent:* Wednesday, August 24, 2016 10:06 AM > *To:* Bill Cox > > *Cc:* Martin Thomson >; Nick Harper = < > nharper@google.com >; > Andrei Popov >; > unbearable@ietf.org > *Subject:* Re: [Unbearable] TLS extension: version field > > > > I shouldn't speak for him but, from previous statements in this thread, i= t > sounded like Nick is in favor of eliminating the version. > > I do think that the question of eliminating the token_binding_version or > not should be considered independently of if/how the draft version can be > communicated for testing prior to the spec(s) finalizing. > > > > > > On Tue, Aug 23, 2016 at 10:35 PM, Bill Cox > wrote: > > I think I see a correlation here: those of us who have worked to build > functional token binding implementations would prefer not to throw the > cards in the air and with major changes, such as eliminating the version. > There are times for innovation, but near the end of a standardization > process is not one of them, IMO. At this point, I would rather see > compatible bug-free implementations. I'll throw my vote in with Nick and > Andrei for moving ahead without changing versioning. It may not be > optimal, but it is good enough. This is not an issue worth delaying the > roll-out of token binding. > > > > Bill > > > > On Tue, Aug 23, 2016 at 5:42 PM, Martin Thomson > wrote: > > On 24 August 2016 at 10:16, Nick Harper > wrote: > > I don't think that trying to get a new IANA-assigned number for each > draft > > version that has breaking changes is a very practical approach. > > Were you planning on breaking things often? > > More seriously, most other user users of this space just grab a number > and use it. Then they tell IANA when they finish with their > experiments. > > If you think that you need to change more often, the new experimental > use space is probably a better idea. > > > > > > > > > --001a114fae3cc80b17053ad60f35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, that sounds right to me. Martin can correct if he was thinking of some= thing else.

On Wednesday, August 24, 2016, Andrei Popov <Andrei.Popov@microsoft.com> w= rote:

Then the proposal seems to be as follows:=

1.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Remove the token_binding_version field from th= e token_binding extension;

2.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Pick a random unassigned TLS extension ID for = each TB draft that breaks compatibility;

3.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A TLS client can advertise multiple of these T= LS extension IDs in the same ClientHello, the server has to pick no more th= an one;

4.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Finalized TB 1.0 will use the currently assign= ed TLS extension code point 24.

Is this summary correct?

From: Nick Harper [mailto:nharper@google.com]
Sent: Wednesday, August 24, 2016 11:53 AM
To: Andrei Popov <Andrei.Popov@micr= osoft.com>
Cc: Brian Campbell <bcampbell@pingi= dentity.com>; Bill Cox <waywardgeek@goo= gle.com>; Martin Thomson <martin.thom= son@gmail.com>; unbearable@ietf.org
Subject: Re: [Unbearable] TLS extension: version field=

=C2=A0

=C2=A0

=C2=A0

On Wed, Aug 24, 2016 at 11:43 AM, Andrei Popov <<= a href=3D"javascript:_e(%7B%7D,'cvml','Andrei.Popov@microsoft.c= om');" target=3D"_blank">Andrei.Popov@microsoft.com> wrote:

The current design is documented in the TBNEGO I-D;= let=E2=80=99s get clarity on the competing proposal, so that we can get a consensus call on the mailing list and let the WG pick one option or the= other.

=C2=A0

My current understanding of the competing proposal = is as follows (proponents please correct me if I got it wrong):

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Remove the token_binding_version field from the token_binding exten= sion;

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Pick random unassigned a TLS extension IDs for each draft version;<= /span>

We don't need to do this for every draft version= , only those that make breaking changes. (Of the past 8 drafts, I think the= re have been about 4 breaking changes.) =C2=A0

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Finalized TB 1.0 will use a new IANA-assigned TLS extension code po= int other than 24 (because TLS extension 24 is currently used by Chrome, wi= th token_binding_version in it).

Chrome only sends 24 when the Token Binding experime= nt is enabled (it defaults to off), so we can move to a new extension numbe= r for a draft version (as in #2) and stop using 24. The only case where thi= s could be a problem is if someone manually flipped on TB and then doesn't update Chrome (with automatic = updates, this seems unlikely). I don't think we need a new IANA assignm= ent.

=C2=A0

From: Nick Harper [mailto:nharper@google.com]
Sent: Wednesday, August 24, 2016 11:14 AM
To: Andrei Popov <Andrei.Popov@micr= osoft.com>
Cc: Brian Campbell <bcampbell@pingi= dentity.com>; Bill Cox <waywardgeek@goo= gle.com>; Martin Thomson <martin.thom= son@gmail.com>; unbearable@ietf.org


Subject: Re: [Unbearable] TLS extension: version field=

=C2=A0

Brian is correct that I am generally in favor of rem= oving the version field from the extension. I think designing a system that= works for production deployment of the standardized spec takes precedence over experimentation (but not to a point that would = prevent experimentation). Earlier in the thread I explained why the version= field won't be useful for production deployment of the standardized sp= ec, and it's also possible to do experimentation without the version field.

=C2=A0

Andrei,

For experimenting after the TB 1.0 spec is published= , you have the extensions in the TokenBinding struct, which you can use wit= hout changing the version number. If extensions aren't sufficient, then I think you'll need something more in the negotiation= message, meaning that you'll need a new TLS extension anyway.

=C2=A0

On Wed, Aug 24, 2016 at 10:13 AM, Andrei Popov <<= a href=3D"javascript:_e(%7B%7D,'cvml','Andrei.Popov@microsoft.c= om');" target=3D"_blank">Andrei.Popov@microsoft.com> wrote:

=C3=98=C2=A0 I do think that the question of eliminating the token_binding_versio= n or not should be considered independently of if/how the draft version can= be communicated for testing prior to the spec(s) finalizing.

Sure, as long as we end up with a viable design tha= t supports both experimentation and production deployment. And I don=E2=80=99t expect experimentation in this space to stop once TB 1.0 s= pecs are published=E2=80=A6

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingidentity.com]
Sent: Wednesday, August 24, 2016 10:06 AM
To: Bill Cox <waywardgeek@google.com>
Cc: Martin Thomson <martin.thomson@gm= ail.com>; Nick Harper <nharper@google.com>; Andrei Popov <Andrei.Popov@microso= ft.com>; unbearable@ietf.org
Subject: Re: [Unbearable] TLS extension: version field=

=C2=A0

I shouldn't speak= for him but, from previous statements in this thread, it sounded like Nick= is in favor of eliminating the version.

I do think that the question of eliminating the toke= n_binding_version or not should be considered independently of if/how the d= raft version can be communicated for testing prior to the spec(s) finalizing.

=C2=A0

=C2=A0

On Tue, Aug 23, 2016 at 10:35 PM, Bill Cox <waywardgeek@google.com> wrote:

I think I see a correlation here: those of us who ha= ve worked to build functional token binding implementations would prefer no= t to throw the cards in the air and with major changes, such as eliminating the version.=C2=A0 There are times for innovation, but= near the end of a standardization process is not one of them, IMO.=C2=A0 A= t this point, I would rather see compatible bug-free implementations.=C2=A0= I'll throw my vote in with Nick and Andrei for moving ahead without changing versioning.=C2=A0 It may not be optimal, but= it is good enough.=C2=A0 This is not an issue worth delaying the roll-out = of token binding.

=C2=A0

Bill<= /u>

=C2=A0

On Tue, Aug 23, 2016 at 5:42 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:<= u>

On 24 August 2016 at 10:16, Nick Harper <nharper@google.com> wrote:
> I don't think that trying to get a new IANA-assigned number for ea= ch draft
> version that has breaking changes is a very practical approach.

Were you planning on breaking things often?

More seriously, most other user users of this space just grab a number
and use it.=C2=A0 Then they tell IANA when they finish with their
experiments.

If you think that you need to change more often, the new experimental
use space is probably a better idea.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

--001a114fae3cc80b17053ad60f35-- From nobody Wed Aug 24 13:24: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 AFB3512D75D for ; Wed, 24 Aug 2016 13:24:43 -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, FREEMAIL_FROM=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 (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 pw4pTa26Pr8g for ; Wed, 24 Aug 2016 13:24:35 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 6303412B02C for ; Wed, 24 Aug 2016 13:24:35 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id z190so26936237qkc.0 for ; Wed, 24 Aug 2016 13:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nTgqUZrcOGFlkjOg1uvNz4lZBYu4h44/heHaF310oeo=; b=VZ278lDYW0gkdo+N1D8FGp/mstowhLYfSZTam5RJuCvCLvAtYkDf/WkvxaSE3ufbhp BpdMHLpLngBh5hWg3EaV6KQWZvUJqo8pO2gYO4c+qhqC4SJFJu3rh92rp8N106MK7FdS ij4cBxw0bOeN1XBQwT+besQxzDNNbmLeRYSA5FXPlt3QD3KtGZ0zZjGIaJx5DGLHJRmL Aj0l9wQ/3cytIMRpAx66Af3uKiQPim8OR5tD+kFrttNM24c3D7pEbHGF5Vgj5IL409Yk 5AStLYRWQ+VIZ0RfH//OutllwC417XqjHh4fiFv0Ii8++LE5R5QiFJA8HEqyxv8Zmcr+ AXdw== 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=nTgqUZrcOGFlkjOg1uvNz4lZBYu4h44/heHaF310oeo=; b=fX1VfgeFEWaTep7+i4kCQOROgRwhtEkY1B/FRBUXjnXE2b7rKdW/DEC36i8SA4NCE/ 7ggp5WmPmS5z6BGWKCGhGdLVCCLaFisLPqb77ZCjHa3XAMMdPqtmPHRwPa7HE8IPZnmK 435l32Ks3ysTrKEzhCPxbsR/dhWk/U3FRb2lpe1Wclk36rNQ1rQutZnsQ3JsnDdqbqtQ L1WoI85w/LyHQixFnmyHqehLy4/KkYaMsSnO5BO67/O1NoeLaYNXVVH0MsvRdEbNXR+X e+84au7Pxx3rSX8O3PVMkdzQ7qX6jeq3gRnT38hE5X4nkq7EmlXzDRtT//IcTY6dOUc9 x3oQ== X-Gm-Message-State: AE9vXwOCT1zSHQyLeDIhr8xS3Om5SgcxhXnZTETZRheZaON5Uj95wDnlkzCXGut83tiSqLcPOkJ2sDuPAM6DTw== X-Received: by 10.55.24.105 with SMTP id j102mr5577484qkh.165.1472070274594; Wed, 24 Aug 2016 13:24:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Wed, 24 Aug 2016 13:24:33 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 25 Aug 2016 06:24:33 +1000 Message-ID: To: Nick Harper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Andrei Popov , Brian Campbell , "unbearable@ietf.org" , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 24 Aug 2016 20:24:44 -0000 On 25 August 2016 at 05:12, Nick Harper wrote: > Yes, that sounds right to me. Martin can correct if he was thinking of > something else. That would work. From nobody Wed Aug 24 13:29:57 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 715FD12D764 for ; Wed, 24 Aug 2016 13:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 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_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 01WlZb9rRJsg for ; Wed, 24 Aug 2016 13:29:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E5B12D75E for ; Wed, 24 Aug 2016 13:29:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6E81EBE83; Wed, 24 Aug 2016 21:29:52 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGzReTAK-juh; Wed, 24 Aug 2016 21:29:49 +0100 (IST) Received: from [172.31.16.125] (unknown [116.6.23.1]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3A87EBE77; Wed, 24 Aug 2016 21:29:44 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1472070589; bh=YYyZ8g5gN2bdIRsQIZHQv9SH6974LDs34SvXE3ShlAw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=3AFGBBJu5O13Lz/5/zseajToY7h4XotU6GGLr/XPX1IjBQDNnKChn9xoaEqopDJhe AihJmiqlr+80ChVnGGwvxyrAHZIBMdGev8pkYcDEiPJQgt2bbpPUlRwwmCjUHU9y1W fJecFqsyVumVvf7umGhLXwsARg6mEnDzsYvE7a7M= To: Andrei Popov , Nick Harper References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 24 Aug 2016 21:29:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050003050201010301070103" Archived-At: Cc: "unbearable@ietf.org" , Brian Campbell , Martin Thomson , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 24 Aug 2016 20:29:56 -0000 This is a cryptographically signed message in MIME format. --------------ms050003050201010301070103 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all, On 24/08/16 20:06, Andrei Popov wrote: > 2. Pick a random unassigned TLS extension ID for each TB draft = that breaks compatibility; If this plan does garner consensus here, please verify it with the TLS WG - those [1] are "their" codepoints after all. Picking a random unassigned extension ID seems a bit smelly if there's no range set aside for from which one can pick, which I think is the case for [1]. If folks want to take that approach then the right thing to do would be to get such a range assigned. S. [1] https://www.iana.org/assignments/tls-extensiontype-values/tls-extensionty= pe-values.xhtml#tls-extensiontype-values-1 --------------ms050003050201010301070103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MjQy MDI5NDBaMC8GCSqGSIb3DQEJBDEiBCAA16E+dsNndFnFYy2IU3xiFDFidWcgexc1vuGnRjQ1 uTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAZvYRIcz8gk7weJSJ2zmh3gR03JlACchBfu6Afac+C/M3ABZmv+CJ2 0+DVMR1cdsUtbOJjKjFOXuB9kWY+7rT68/zGPKjzHddm5u7/M0cTToafW9+M7VLJoKZ7vW2D n6v4bZ4rwTVtvMbC9pzLiiY5D9ElwCsi+KWSgLvrgC3GMq/4IMY53ebKUkfVvj9PBbEFaCca ma1eAxHKxocBiWQ/+3NKwtK7cxrCmCKLkaIA4oQpaC4LJ4CO94gb6xF92mADF/Xh0ukSSCgZ o0QPbSMgaClzi23dWWn5T22YEiMm1fuXkODlR8Abt6lfUm7MG/uBnGLWIoywkL7nPPsjflmu AAAAAAAA --------------ms050003050201010301070103-- From nobody Wed Aug 24 13:38:26 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 2E6B712D5BE for ; Wed, 24 Aug 2016 13:38: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 4j4cy1jC8Sk9 for ; Wed, 24 Aug 2016 13:38:23 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 CAB8712D134 for ; Wed, 24 Aug 2016 13:38:22 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id l2so27307669qkf.3 for ; Wed, 24 Aug 2016 13:38: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=0LGsHSHioW+sOH5QGihDGYKwUg7qhaiT6QQGwAi/gp0=; b=RiElJgOsN9hZ5jAIS/GZdZbPCZtTw4LWODifmNDt4lt32v5Kl1a4rcZ7uUbYCFm7RZ IS2VwaJcqMyvYgc4PHT6Yttznn3JdoFOiKLeISMs1UwfQdsqOmkaFiekauyZQxgK4xUX iIBSZxm8VvkzRXE4Tl/YYd3+7SJEFFkXsXXA4VDP1CHXas3/McreEALJmES9f/ULMPqW dSUIp7kWPR16APjGjAHERZRzON+6weZXO8uy/8S7VkHczq/7p9DvyMrNBR+c32ziwQ5r MzP67gea0DIBiE1lpSCoyA0pUF5EuCSk+GhGYcsrEKhJZ2+zSK0kVnhElXVDFRcFomC8 XMLw== 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=0LGsHSHioW+sOH5QGihDGYKwUg7qhaiT6QQGwAi/gp0=; b=d70PNreCPaXJUugtozJVz1moG6FB8pOVyMf0DVuea1HY0baPTVWT22KVw5+C+WsoYb uJF2WkV6BW8RDj0+wAuLVmbyS2fPGZKzE4Hqo1a6jicdiZTgeT4lKNgvWrGt8rFZXHcs oz7/IWbUDH2vKSIPaBx0xcvYsogpofZk3MObbdhfAQnVzR/hjKgWmbWKWy93THEf/S9v guR53sN6TwvxZvA/RWO1eoax61r9zp/56YlynoCjkDsny5KRYsc7lGQ7Deco+1omOX+C BRK3SESUjjmQyvX0CXuE1S6d755/w3TF30IhWUI88mYUrhmNZmoLrVYMfn4sZtI3FzbG KWHA== X-Gm-Message-State: AE9vXwPqxW1MBMoaHX24Dmc9+RxHRBfsqjUFIyUw0hVmeydMIo0v7YDuW5fTiprodS+D9Q9b X-Received: by 10.55.203.213 with SMTP id u82mr5829911qkl.255.1472071101694; Wed, 24 Aug 2016 13:38:21 -0700 (PDT) Received: from [192.168.8.101] ([181.201.108.96]) by smtp.gmail.com with ESMTPSA id 55sm5670229qtm.36.2016.08.24.13.38.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 24 Aug 2016 13:38:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Wed, 24 Aug 2016 17:38:16 -0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Stephen Farrell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Andrei Popov , "unbearable@ietf.org" , Bill Cox , Brian Campbell , Martin Thomson , Nick Harper Subject: Re: [Unbearable] TLS extension: version field 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, 24 Aug 2016 20:38:25 -0000 For preproduction or experimental version is using the experimental = space make sense and then use 24 for the RFC version? We need something to use for interop testing. =20 John B? > On Aug 24, 2016, at 5:29 PM, Stephen Farrell = wrote: >=20 >=20 > Hi all, >=20 > On 24/08/16 20:06, Andrei Popov wrote: >> 2. Pick a random unassigned TLS extension ID for each TB = draft that breaks compatibility; >=20 > If this plan does garner consensus here, please verify it with the > TLS WG - those [1] are "their" codepoints after all. >=20 > Picking a random unassigned extension ID seems a bit smelly if > there's no range set aside for from which one can pick, which > I think is the case for [1]. >=20 > If folks want to take that approach then the right thing to do > would be to get such a range assigned. >=20 > S. >=20 > [1] > = https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontyp= e-values.xhtml#tls-extensiontype-values-1 >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable From nobody Wed Aug 24 13:45: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 D764D12B00E for ; Wed, 24 Aug 2016 13:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 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_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Q2tskNyOvvYl for ; Wed, 24 Aug 2016 13:45:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 058C912D75A for ; Wed, 24 Aug 2016 13:45:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B6FD1BE77; Wed, 24 Aug 2016 21:45:48 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HdQgIr8xdnRq; Wed, 24 Aug 2016 21:45:47 +0100 (IST) Received: from [172.31.16.125] (unknown [116.6.23.1]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 44B10BE7C; Wed, 24 Aug 2016 21:45:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1472071547; bh=JQbICCaTWaIRDfQP4ZOqEyMtvGn0X4v2x3cNdhOKf4g=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Yp5CkuBpqS1aEOlesmRuwVAtPDfruqrXLtlldgtQZsmGxjsntUGtA2lrZQICq1IQL OKm4rAH1M7mVUXROWHaFJXW/WzOAP8aovDw3Fe+Q89TqqM77CQYr8tDM8Bj2gkjaex D+7LouqCUI3XhbaF7pArIcGQfz3MHUWnClITCuDg= To: John Bradley References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <9b0f1cb3-a74b-2637-159c-e7aa3ee53ec6@cs.tcd.ie> Date: Wed, 24 Aug 2016 21:45:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040504060200020404010809" Archived-At: Cc: Andrei Popov , "unbearable@ietf.org" , Bill Cox , Brian Campbell , Martin Thomson , Nick Harper Subject: Re: [Unbearable] TLS extension: version field 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, 24 Aug 2016 20:45:52 -0000 This is a cryptographically signed message in MIME format. --------------ms040504060200020404010809 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 24/08/16 21:38, John Bradley wrote: > For preproduction or experimental version is using the experimental spa= ce make sense and then use 24 for the RFC version? >=20 There's no experimental range set aside in that registry that I can see. And folks have had issues with such, when it turns out that a codepoint from the experimental range has "escaped" into the wild to such an extent that nobody else could use it to do experiments. What I thought was being proposed here was a little different, being to set aside a range from which random assignments of still-free codepoints can be picked by this WG (or maybe this or others) and where the randomly assigned codepoint might turn into one that's permanently assigned later. So one could propose either setting aside an experimental range, or doing something new as in the paragraph above I guess. Either way, getting that agreed on the TLS list would be a good plan. Cheers S. > We need something to use for interop testing. =20 >=20 > John B? >> On Aug 24, 2016, at 5:29 PM, Stephen Farrell wrote: >> >> >> Hi all, >> >> On 24/08/16 20:06, Andrei Popov wrote: >>> 2. Pick a random unassigned TLS extension ID for each TB draf= t that breaks compatibility; >> >> If this plan does garner consensus here, please verify it with the >> TLS WG - those [1] are "their" codepoints after all. >> >> Picking a random unassigned extension ID seems a bit smelly if >> there's no range set aside for from which one can pick, which >> I think is the case for [1]. >> >> If folks want to take that approach then the right thing to do >> would be to get such a range assigned. >> >> S. >> >> [1] >> https://www.iana.org/assignments/tls-extensiontype-values/tls-extensio= ntype-values.xhtml#tls-extensiontype-values-1 >> >> _______________________________________________ >> Unbearable mailing list >> Unbearable@ietf.org >> https://www.ietf.org/mailman/listinfo/unbearable >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable >=20 --------------ms040504060200020404010809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MjQy MDQ1NDBaMC8GCSqGSIb3DQEJBDEiBCAtP2yLgC+4b5LWkJ/DDg7BAeNouMzk0hjhZK2XtcmN rzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBmjBM4eqWF2XVrSK6hSGwJMiuCGW8MHYkOy5wHbqg51SvnqHsuNVa1 ByUU3CTu5tUZ+7n2yT43pzFMV69MA5o+f9mBammZ4TfmfI3SoKRS6UO0cfGRZ/9qLxLQlJoo GOWBi71rpNKlB3SodakSmB2HexqmyMZAHr2TC1dM32+tPVHB3hZBf+L6B3Y61n0j48C6WAnQ fQ/p13sH6Ccy5GkMeAUwCngnKp+plkHEYeN64TUPsmPYIaLXglgYBC7qySFeqJlykcvBseif w4ryb7HSqOi9JFExDprpAn8OA5wchZB+IZ47PGtvgRsbJAG+xSVG5dSCZdTEuKZIpAGFqvu7 AAAAAAAA --------------ms040504060200020404010809-- From nobody Wed Aug 24 17:47:27 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 2530512D5F2 for ; Wed, 24 Aug 2016 17:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Bwr61f1a2Hyl for ; Wed, 24 Aug 2016 17:47:24 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0132.outbound.protection.outlook.com [104.47.37.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B98412D189 for ; Wed, 24 Aug 2016 17:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9/y9dfsN91QYVnk1pDN9PveOqf7smkM9qytD72CB9Fs=; b=exzDXnuRQf3WApmlcfqIKITrD7lKFs6JEdx0OCz52cgE+SDy4PLhfes3xMNuob1r7wrcRiIOsYbUbHgI9DqCV1cyjC6kM0jDW9tkTSLzTjZbpuiXshIuV3loPxWNtqtFTD/RLQmYq+04/XPudmF2qhU/duFshuaBQFDgKibaj+Y= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2154.namprd03.prod.outlook.com (10.166.206.139) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Thu, 25 Aug 2016 00:47:21 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0587.013; Thu, 25 Aug 2016 00:47:21 +0000 From: Andrei Popov To: Stephen Farrell , John Bradley , Leif Johansson Thread-Topic: [Unbearable] TLS extension: version field Thread-Index: AQHR8UE0hAr3fGh5LkSos3djbwbcUaA/MmwAgAAmOoCAAAGk8IAAhvMAgAAFqjCAAAO6AIAA6WmAgAATAoCAABJZgIAV3xfwgAATKACAAFvQgIAAAlRwgAANXQCAAAcGgIAAQVIAgADRnQCAAADEgIAAEkUAgAAEGBCAAAamgIAAAViQgAAZvwCAAAJnAIAAAhEAgAA/qZA= Date: Thu, 25 Aug 2016 00:47:20 +0000 Message-ID: References: <9b0f1cb3-a74b-2637-159c-e7aa3ee53ec6@cs.tcd.ie> In-Reply-To: <9b0f1cb3-a74b-2637-159c-e7aa3ee53ec6@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: cb16a206-fa97-49f6-f38e-08d3cc815f51 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2154; 6:6b0tdRuYpnhXSBfUeL+AVxdZ5nzqh8w+TX1Ndyhz8Nt1Cqzd5TbSacNZgrDzM9HcfsGUDmY/+GoVdkNYczVYUWppkNg8ANTAjrPDrAx8Z+RcQzaJi6N0LvU2lX5yRqSzsqFPsW2Y60CY+W6QBgp9duRaE8lUlJxujBywE1WsFsZjCGIis+wT6s/LMPAOOBJ25w16x4B0o4Gxto+ubllYBR33G+5IpnJzoL42V93QLKREsl8WHMblUOHzNmsRwKITQzMfHkaebZK7n4HSjwpjSzjlbyRMCLluHocRwwHMJ4snnhfOSnxv8QRwMHwWj5lURONBKW74vn7f0OsG5z5MRQ==; 5:/jgydhWU7mVjj1tovKOlqFvNA3b85urvXiZfTyOlE96GIJQvI+C3ELsazv6mUh9z7vA5xFEj11Kx3RVCpwfgVgJsFbd3qTMBDG2aJRzK87HuV45V3/vTNspK2QKHk1Pv/nkyUw2JtNLTYXUeCNXMZA==; 24:fD8QuFhXVH4UtH6l+rqld0p1tkuvXqb9mv2a//y0C2Q1d6nUxLCFUy+ayDdXrcimPwW2rlFN1FtTqS4WEWAfdYkml38bX3O+A6Mf11vKBls=; 7:3admZrIQBriKQeW92XCVkPdQDGdebrMIFwPkgGU1VHtS0QN5j3DJZP7R+AqP8cPcZzNHUlpgOS0iBO7C1Ib7JtTH1pVHOxK+OsdURjFOmAiAgu/cNqa1Bfy4c0nOi11vBCM42tJyAgn//FX4PNg+T5eW7I9NEkcZ+qJwwQgmTep8bgRkiQU2VCK799dsvPXEfJ+SnD8z/njTCkHZSn6WTii/PcukGD9wtNE8/hJa7nP6rVsMXkY3jcEG2XFAOzUq x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2154; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(211936372134217)(100405760836317)(1591387915157); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2154; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2154; x-forefront-prvs: 0045236D47 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(13464003)(199003)(189002)(53754006)(8676002)(68736007)(2906002)(99286002)(81156014)(81166006)(76576001)(106356001)(19580405001)(9686002)(19580395003)(4326007)(122556002)(7846002)(7696003)(86362001)(74316002)(305945005)(7736002)(3660700001)(3280700002)(8936002)(105586002)(33656002)(8990500004)(15975445007)(77096005)(5660300001)(2950100001)(586003)(2900100001)(92566002)(5005710100001)(6116002)(102836003)(11100500001)(10290500002)(54356999)(10400500002)(76176999)(106116001)(50986999)(10090500001)(5002640100001)(93886004)(101416001)(87936001)(189998001)(5001770100001)(97736004)(86612001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2154; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 25 Aug 2016 00:47:20.8643 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2154 Archived-At: Cc: "unbearable@ietf.org" , Brian Campbell , Martin Thomson , Nick Harper , Bill Cox Subject: Re: [Unbearable] TLS extension: version field 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, 25 Aug 2016 00:47:26 -0000 Pj4gUGlja2luZyBhIHJhbmRvbSB1bmFzc2lnbmVkIGV4dGVuc2lvbiBJRCBzZWVtcyBhIGJpdCBz bWVsbHkgaWYNCj4+IHRoZXJlJ3Mgbm8gcmFuZ2Ugc2V0IGFzaWRlIGZvciBmcm9tIHdoaWNoIG9u ZSBjYW4gcGljaywgd2hpY2gNCj4+IEkgdGhpbmsgaXMgdGhlIGNhc2UgZm9yIFsxXS4NClllcywg dGhpcyBpcyBvbmUgb2YgdGhlIGNvbmNlcm5zIHdpdGggdGhlIHByb3Bvc2VkIHNjaGVtZS4gQW5k IG9uZSBvZiB0aGUgcmVhc29ucyBJIHdvdWxkIHJhdGhlciBrZWVwIHRoZSBjdXJyZW50IFRCIHZl cnNpb24gbmVnb3RpYXRpb24gbWVjaGFuaXNtLg0KDQo+IEVpdGhlciB3YXksIGdldHRpbmcgdGhh dCBhZ3JlZWQgb24gdGhlIFRMUyBsaXN0IHdvdWxkIGJlIGEgZ29vZCBwbGFuLg0KV2hhdCBkbyB0 aGUgQ2hhaXJzIHRoaW5rOiBzaG91bGQgdGhlIHByb3BvbmVudHMgc3RhcnQgdGhlIGRpc2N1c3Np b24gb24gdGhlIFRMUyBXRyBsaXN0LCBvciBzaG91bGQgd2UgZ2F1Z2UgY29uc2Vuc3VzIGluIHRo ZSBUQiBXRyBmaXJzdD8NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFN0ZXBoZW4gRmFycmVsbCBbbWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBj cy50Y2QuaWVdIA0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjQsIDIwMTYgMTo0NiBQTQ0KVG86 IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+DQpDYzogQW5kcmVpIFBvcG92IDxBbmRy ZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT47IHVuYmVhcmFibGVAaWV0Zi5vcmc7IEJpbGwgQ294IDx3 YXl3YXJkZ2Vla0Bnb29nbGUuY29tPjsgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tPjsgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IE5p Y2sgSGFycGVyIDxuaGFycGVyQGdvb2dsZS5jb20+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVd IFRMUyBleHRlbnNpb246IHZlcnNpb24gZmllbGQNCg0KDQoNCk9uIDI0LzA4LzE2IDIxOjM4LCBK b2huIEJyYWRsZXkgd3JvdGU6DQo+IEZvciBwcmVwcm9kdWN0aW9uIG9yIGV4cGVyaW1lbnRhbCB2 ZXJzaW9uIGlzIHVzaW5nIHRoZSBleHBlcmltZW50YWwgc3BhY2UgbWFrZSBzZW5zZSBhbmQgdGhl biB1c2UgMjQgZm9yIHRoZSBSRkMgdmVyc2lvbj8NCj4gDQoNClRoZXJlJ3Mgbm8gZXhwZXJpbWVu dGFsIHJhbmdlIHNldCBhc2lkZSBpbiB0aGF0IHJlZ2lzdHJ5IHRoYXQNCkkgY2FuIHNlZS4gQW5k IGZvbGtzIGhhdmUgaGFkIGlzc3VlcyB3aXRoIHN1Y2gsIHdoZW4gaXQgdHVybnMNCm91dCB0aGF0 IGEgY29kZXBvaW50IGZyb20gdGhlIGV4cGVyaW1lbnRhbCByYW5nZSBoYXMgImVzY2FwZWQiDQpp bnRvIHRoZSB3aWxkIHRvIHN1Y2ggYW4gZXh0ZW50IHRoYXQgbm9ib2R5IGVsc2UgY291bGQgdXNl IGl0DQp0byBkbyBleHBlcmltZW50cy4NCg0KV2hhdCBJIHRob3VnaHQgd2FzIGJlaW5nIHByb3Bv c2VkIGhlcmUgd2FzIGEgbGl0dGxlIGRpZmZlcmVudCwNCmJlaW5nIHRvIHNldCBhc2lkZSBhIHJh bmdlIGZyb20gd2hpY2ggcmFuZG9tIGFzc2lnbm1lbnRzIG9mDQpzdGlsbC1mcmVlIGNvZGVwb2lu dHMgY2FuIGJlIHBpY2tlZCBieSB0aGlzIFdHIChvciBtYXliZSB0aGlzDQpvciBvdGhlcnMpIGFu ZCB3aGVyZSB0aGUgcmFuZG9tbHkgYXNzaWduZWQgY29kZXBvaW50IG1pZ2h0DQp0dXJuIGludG8g b25lIHRoYXQncyBwZXJtYW5lbnRseSBhc3NpZ25lZCBsYXRlci4NCg0KU28gb25lIGNvdWxkIHBy b3Bvc2UgZWl0aGVyIHNldHRpbmcgYXNpZGUgYW4gZXhwZXJpbWVudGFsDQpyYW5nZSwgb3IgZG9p bmcgc29tZXRoaW5nIG5ldyBhcyBpbiB0aGUgcGFyYWdyYXBoIGFib3ZlIEkNCmd1ZXNzLiBFaXRo ZXIgd2F5LCBnZXR0aW5nIHRoYXQgYWdyZWVkIG9uIHRoZSBUTFMgbGlzdCB3b3VsZA0KYmUgYSBn b29kIHBsYW4uDQoNCkNoZWVycw0KUy4NCg0KPiBXZSBuZWVkIHNvbWV0aGluZyB0byB1c2UgZm9y IGludGVyb3AgdGVzdGluZy4gIA0KPiANCj4gSm9obiBCPw0KPj4gT24gQXVnIDI0LCAyMDE2LCBh dCA1OjI5IFBNLCBTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdy b3RlOg0KPj4NCj4+DQo+PiBIaSBhbGwsDQo+Pg0KPj4gT24gMjQvMDgvMTYgMjA6MDYsIEFuZHJl aSBQb3BvdiB3cm90ZToNCj4+PiAyLiAgICAgICAgIFBpY2sgYSByYW5kb20gdW5hc3NpZ25lZCBU TFMgZXh0ZW5zaW9uIElEIGZvciBlYWNoIFRCIGRyYWZ0IHRoYXQgYnJlYWtzIGNvbXBhdGliaWxp dHk7DQo+Pg0KPj4gSWYgdGhpcyBwbGFuIGRvZXMgZ2FybmVyIGNvbnNlbnN1cyBoZXJlLCBwbGVh c2UgdmVyaWZ5IGl0IHdpdGggdGhlDQo+PiBUTFMgV0cgLSB0aG9zZSBbMV0gYXJlICJ0aGVpciIg Y29kZXBvaW50cyBhZnRlciBhbGwuDQo+Pg0KPj4gUGlja2luZyBhIHJhbmRvbSB1bmFzc2lnbmVk IGV4dGVuc2lvbiBJRCBzZWVtcyBhIGJpdCBzbWVsbHkgaWYNCj4+IHRoZXJlJ3Mgbm8gcmFuZ2Ug c2V0IGFzaWRlIGZvciBmcm9tIHdoaWNoIG9uZSBjYW4gcGljaywgd2hpY2gNCj4+IEkgdGhpbmsg aXMgdGhlIGNhc2UgZm9yIFsxXS4NCj4+DQo+PiBJZiBmb2xrcyB3YW50IHRvIHRha2UgdGhhdCBh cHByb2FjaCB0aGVuIHRoZSByaWdodCB0aGluZyB0byBkbw0KPj4gd291bGQgYmUgdG8gZ2V0IHN1 Y2ggYSByYW5nZSBhc3NpZ25lZC4NCj4+DQo+PiBTLg0KPj4NCj4+IFsxXQ0KPj4gaHR0cHM6Ly93 d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdGxzLWV4dGVuc2lvbnR5cGUtdmFsdWVzL3Rscy1leHRl bnNpb250eXBlLXZhbHVlcy54aHRtbCN0bHMtZXh0ZW5zaW9udHlwZS12YWx1ZXMtMQ0KPj4NCj4+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBVbmJl YXJhYmxlIG1haWxpbmcgbGlzdA0KPj4gVW5iZWFyYWJsZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBVbmJlYXJhYmxlIG1haWxp bmcgbGlzdA0KPiBVbmJlYXJhYmxlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZQ0KPiANCg0K From nobody Wed Aug 24 18:03: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 CC32812D606 for ; Wed, 24 Aug 2016 18:03:26 -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, 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 (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 m_aq4DnQwNPj for ; Wed, 24 Aug 2016 18:03:24 -0700 (PDT) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 91B7412D1D2 for ; Wed, 24 Aug 2016 18:03:24 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id 93so16131797qtg.2 for ; Wed, 24 Aug 2016 18:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MmTI8u3q3OkeIwMFAeRSBtOWBTv1PW2NoHxrElWQaA8=; b=NMvZjSexafWCcxE5kpC2/sEoB/ZSIz0JKSPe5EB5fLRMStapXaCqxL3nfxu5Xra3fs 7jM5chy8SkCpNdJU3bdjEbwanSfWioJ/fD3HwW0va/5+LfTMOYLtJXf1QD+fDFUMqodX rRSftpHrNhbrOM6mzY4xCjkM5f8m06sOyQb5W9WzVh/G4a5dTxlsLcCBARKKHFq+RXRP Njju7j3wNtZ+A4Qw/zM7muscfOb+fVCOW7am2h1UA1FdqUDUSr6X1H1x9drXYoIRkRAh 2q+WXu1+oDVGBoZBHqFQBDmCNvSePZXPbaT9DrBJoEmA5j2MNRr4+3Cvi2WRqgEFR5i9 XVyA== 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=MmTI8u3q3OkeIwMFAeRSBtOWBTv1PW2NoHxrElWQaA8=; b=jmMr/Wm1LZ5fvJVy01acpGeAgFEaw81Tsj1wGJDusWXcPtsVa7YsBU/8IKXPJuNVll nMsjkF7T0k96PZGadv7Yh+eFyWuXKX+/pCBEzO4DyKTJeCMTWCEWT5eBnc7Ra8oCaRBL 6H6T23xdxncrz0MYddNUWuUwrrdxwEKKVzQOWyGyGU/CzRjG6MJL3l8PzWloIA6nbMfZ 6TmrpIImfKK8u9UF7DK0Wnc11hNRaKkT1jD4Hx5dkhGOCedf/uWU6TQ/V1dYBhanoMbe HQkmAR5Rv9P5+kjuNeT+Yt673PhF9l9P2fuMzRm3Vt1ZX4VfGC5mL3Eg7ZXurIWkexiw wNNQ== X-Gm-Message-State: AE9vXwNlO7qe415w1Q1Mas40H3YZ2h9jP4ZPsaUJdGzqsykUN6QVU/wXp8WQmz6AN4zT91wLs+jOVIhbkUhhB1ie X-Received: by 10.200.54.243 with SMTP id b48mr7236012qtc.0.1472087003550; Wed, 24 Aug 2016 18:03:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.105.3 with HTTP; Wed, 24 Aug 2016 18:03:22 -0700 (PDT) X-Originating-IP: [181.201.49.203] Received: by 10.55.105.3 with HTTP; Wed, 24 Aug 2016 18:03:22 -0700 (PDT) In-Reply-To: References: <9b0f1cb3-a74b-2637-159c-e7aa3ee53ec6@cs.tcd.ie> From: John Bradley Date: Wed, 24 Aug 2016 22:03:22 -0300 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a1141de8cecfaf2053adaf6f5 Archived-At: Cc: "unbearable@ietf.org" , Bill Cox , Brian Campbell , Martin Thomson , Leif Johansson , Nick Harper , Stephen Farrell Subject: Re: [Unbearable] TLS extension: version field 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, 25 Aug 2016 01:03:27 -0000 --001a1141de8cecfaf2053adaf6f5 Content-Type: text/plain; charset=UTF-8 First we need to determine if there is consensus for a change. Andrei can you sunrise the current state and options to the list. Thanks. John B. On Aug 24, 2016 21:47, "Andrei Popov" wrote: > >> Picking a random unassigned extension ID seems a bit smelly if > >> there's no range set aside for from which one can pick, which > >> I think is the case for [1]. > Yes, this is one of the concerns with the proposed scheme. And one of the > reasons I would rather keep the current TB version negotiation mechanism. > > > Either way, getting that agreed on the TLS list would be a good plan. > What do the Chairs think: should the proponents start the discussion on > the TLS WG list, or should we gauge consensus in the TB WG first? > > Cheers, > > Andrei > > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Wednesday, August 24, 2016 1:46 PM > To: John Bradley > Cc: Andrei Popov ; unbearable@ietf.org; Bill > Cox ; Brian Campbell ; > Martin Thomson ; Nick Harper > > Subject: Re: [Unbearable] TLS extension: version field > > > > On 24/08/16 21:38, John Bradley wrote: > > For preproduction or experimental version is using the experimental > space make sense and then use 24 for the RFC version? > > > > There's no experimental range set aside in that registry that > I can see. And folks have had issues with such, when it turns > out that a codepoint from the experimental range has "escaped" > into the wild to such an extent that nobody else could use it > to do experiments. > > What I thought was being proposed here was a little different, > being to set aside a range from which random assignments of > still-free codepoints can be picked by this WG (or maybe this > or others) and where the randomly assigned codepoint might > turn into one that's permanently assigned later. > > So one could propose either setting aside an experimental > range, or doing something new as in the paragraph above I > guess. Either way, getting that agreed on the TLS list would > be a good plan. > > Cheers > S. > > > We need something to use for interop testing. > > > > John B? > >> On Aug 24, 2016, at 5:29 PM, Stephen Farrell > wrote: > >> > >> > >> Hi all, > >> > >> On 24/08/16 20:06, Andrei Popov wrote: > >>> 2. Pick a random unassigned TLS extension ID for each TB draft > that breaks compatibility; > >> > >> If this plan does garner consensus here, please verify it with the > >> TLS WG - those [1] are "their" codepoints after all. > >> > >> Picking a random unassigned extension ID seems a bit smelly if > >> there's no range set aside for from which one can pick, which > >> I think is the case for [1]. > >> > >> If folks want to take that approach then the right thing to do > >> would be to get such a range assigned. > >> > >> S. > >> > >> [1] > >> https://www.iana.org/assignments/tls-extensiontype- > values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1 > >> > >> _______________________________________________ > >> 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 > > > > --001a1141de8cecfaf2053adaf6f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

First we need to determine if there is consensus for a chang= e.

Andrei can you sunrise the current state and options to the = list.=C2=A0

Thanks.

John B.


On Aug 24, 2016 2= 1:47, "Andrei Popov" <Andrei.Popov@microsoft.com> wrote:
>> Picking a random unassigned extension = ID seems a bit smelly if
>> there's no range set aside for from which one can pick, which<= br> >> I think is the case for [1].
Yes, this is one of the concerns with the proposed scheme. And one of the r= easons I would rather keep the current TB version negotiation mechanism.
> Either way, getting that agreed on the TLS list would be a good plan.<= br> What do the Chairs think: should the proponents start the discussion on the= TLS WG list, or should we gauge consensus in the TB WG first?

Cheers,

Andrei

-----Original Message-----
From: Stephen Farrell [mailto:= stephen.farrell@cs.tcd.ie]
Sent: Wednesday, August 24, 2016 1:46 PM
To: John Bradley <ve7jtb@ve7jtb.com= >
Cc: Andrei Popov <Andrei.P= opov@microsoft.com>; unbearab= le@ietf.org; Bill Cox <way= wardgeek@google.com>; Brian Campbell <bcampbell@pingidentity.com>; Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com">martin.thomson@gmail.com>= ; Nick Harper <nharper@google.com<= /a>>
Subject: Re: [Unbearable] TLS extension: version field



On 24/08/16 21:38, John Bradley wrote:
> For preproduction or experimental version is using the experimental sp= ace make sense and then use 24 for the RFC version?
>

There's no experimental range set aside in that registry that
I can see. And folks have had issues with such, when it turns
out that a codepoint from the experimental range has "escaped" into the wild to such an extent that nobody else could use it
to do experiments.

What I thought was being proposed here was a little different,
being to set aside a range from which random assignments of
still-free codepoints can be picked by this WG (or maybe this
or others) and where the randomly assigned codepoint might
turn into one that's permanently assigned later.

So one could propose either setting aside an experimental
range, or doing something new as in the paragraph above I
guess. Either way, getting that agreed on the TLS list would
be a good plan.

Cheers
S.

> We need something to use for interop testing.
>
> John B?
>> On Aug 24, 2016, at 5:29 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>>
>>
>> Hi all,
>>
>> On 24/08/16 20:06, Andrei Popov wrote:
>>> 2.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pick a random unassigned T= LS extension ID for each TB draft that breaks compatibility;
>>
>> If this plan does garner consensus here, please verify it with the=
>> TLS WG - those [1] are "their" codepoints after all.
>>
>> Picking a random unassigned extension ID seems a bit smelly if
>> there's no range set aside for from which one can pick, which<= br> >> I think is the case for [1].
>>
>> If folks want to take that approach then the right thing to do
>> would be to get such a range assigned.
>>
>> S.
>>
>> [1]
>> https://www.iana.org/assignments/tls-extension= type-values/tls-extensiontype-values.xhtml#tls-extensiontype= -values-1
>>
>> _______________________________________________
>> Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.org/mailman/listinf= o/unbearable
>
> _______________________________________________
> Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbe= arable
>

--001a1141de8cecfaf2053adaf6f5-- From nobody Wed Aug 24 19:02:23 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 72C3512D635 for ; Wed, 24 Aug 2016 19:02:21 -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 2RsssvjDKq3B for ; Wed, 24 Aug 2016 19:02:18 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0131.outbound.protection.outlook.com [104.47.42.131]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48F6312D0DB for ; Wed, 24 Aug 2016 19:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WuED2TLMt+z8FFbf/ZGpXx5bHTtgs0FFoloSeAUwpXU=; b=Fd8hAAethSlCPhsJQPs29tvmIgsCPFalwcUtm4r2aKt+HDJKGRlQpXY6R0E9z9L3gkkX6jMl1XpJe7bvlRDh6Mjp3TtVRzMS4r4V7HoOtfHHPTujx9tPeK+e26YgXo4T9glz8uNQ0nVw9lQ+AyfKYUz0w5a2u5YPl4ikidB6lUY= Received: from CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) by CY1PR03MB2153.namprd03.prod.outlook.com (10.166.206.138) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Thu, 25 Aug 2016 02:02:15 +0000 Received: from CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) by CY1PR03MB2155.namprd03.prod.outlook.com ([10.166.206.140]) with mapi id 15.01.0587.013; Thu, 25 Aug 2016 02:02:15 +0000 From: Andrei Popov To: John Bradley Thread-Topic: [Unbearable] TLS extension: version field Thread-Index: AQHR8UE0hAr3fGh5LkSos3djbwbcUaA/MmwAgAAmOoCAAAGk8IAAhvMAgAAFqjCAAAO6AIAA6WmAgAATAoCAABJZgIAV3xfwgAATKACAAFvQgIAAAlRwgAANXQCAAAcGgIAAQVIAgADRnQCAAADEgIAAEkUAgAAEGBCAAAamgIAAAViQgAAZvwCAAAJnAIAAAhEAgAA/qZCAAAhXAIAABsHQ Date: Thu, 25 Aug 2016 02:02:15 +0000 Message-ID: References: <9b0f1cb3-a74b-2637-159c-e7aa3ee53ec6@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: d09f09d0-93c5-479f-7b99-08d3cc8bd656 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2153; 6:4/ejrv0ytgoa1fco8zTVOtbvNxs1/F9goYrhQMSjrEGKknsyHE5YWZb2CmpDeoUeim3MJwom3cQQh94pQQ6fol5zdL6eSKIo5HrVZh7eluuwBdYJohV9decYi2jxUn02nIdGj9NcVI29R1Emq1+bEwX2XvSvBwC6kP7g3wqKToSR2jSK6X1dIJeqn4lFmQTEQ9bvDahGGczloMVhvQ4RD98DDofPM7cDvCQ2XMoY6ewcDAym6fth8edU7u40fFShwU0fPqbXXmW3Qs5OalSwT2eS+GTduiSh1Yxg5T0rfd+Lc9L6u6Yj6oGP+quYceFXjE+XFKHsumy+zG2yQ/QSdQ==; 5:LtiNyXx7XU4ku8lZbBpwU9ZvZTwlCUfDB2VPmlGgI9oZCD3dzK5FTw5bP/STpCl2PfbbCwmVWe5IA021plOd9+NAzKZDIAW/zMgDe02N86PmuemNA+ZjGCQabAxjhsMa2m+YBYQ6FbxWwGokX9I/EQ==; 24:PNq1SJWePncDuZ7kY5742cfQa+hnJoAuuPNk328rCOZBuJgJwtmH7Iz3tpmLbEnDgpYs1HEUBKx3ASjXrOEzx4JqqqwIoxkS5Nkgjw5INzI=; 7:+oMsHDh5HzHdWpcngVcFAHN0gjDFwLqbML4aNEMh5jq0WX8s7otydHCn7Zw41+2JtJe0QNtXd2JYYf9bYwT3TPjFy4RG1R0tv2zA95pVAaRslh/0Tn4ZRnnEYaRuZp1VeF1No0h68sG0luQk2qxwPc7gE1eIxSz8LuviF1V9zC+3c1hSD7d9p0GZQgM32uU+MjEJ1lFIk5TQgfLGVfCyFLiIqRmkf0TDVSZFLSDT58Yxn8Xv7/mckQlmPNn1ctFL x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2153; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(158342451672863)(211936372134217)(100405760836317)(21748063052155)(69029272430364)(1591387915157); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR03MB2153; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2153; x-forefront-prvs: 0045236D47 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(53754006)(199003)(189002)(13464003)(24454002)(377454003)(5005710100001)(106116001)(76176999)(99286002)(110136002)(86612001)(16236675004)(189998001)(33656002)(97736004)(93886004)(19580395003)(105586002)(19617315012)(106356001)(54356999)(92566002)(8936002)(74316002)(7696003)(7846002)(11100500001)(7736002)(7906003)(50986999)(561944003)(19300405004)(81156014)(8676002)(87936001)(81166006)(9686002)(10290500002)(102836003)(3660700001)(4326007)(68736007)(3280700002)(790700001)(76576001)(19580405001)(10090500001)(586003)(2906002)(6116002)(86362001)(5660300001)(8990500004)(10400500002)(19625215002)(15975445007)(2900100001)(77096005)(122556002)(5002640100001)(101416001)(2950100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR03MB2153; H:CY1PR03MB2155.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR03MB215526D81479A2C23146A6588CED0CY1PR03MB2155namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2016 02:02:15.6152 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2153 Archived-At: Cc: "unbearable@ietf.org" , Bill Cox , Brian Campbell , Martin Thomson , Leif Johansson , Nick Harper , Stephen Farrell Subject: Re: [Unbearable] TLS extension: version field 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, 25 Aug 2016 02:02:21 -0000 --_000_CY1PR03MB215526D81479A2C23146A6588CED0CY1PR03MB2155namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEFuZHJlaSBjYW4geW91IHN1bnJpc2UgdGhlIGN1cnJlbnQgc3RhdGUgYW5kIG9wdGlvbnMg dG8gdGhlIGxpc3QuDQpHbGFkbHkuDQoNCldoYXQgd2UgaGF2ZSBub3c6DQpDdXJyZW50bHksIFRC TkVHTy0wMzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10b2tiaW5kLW5l Z290aWF0aW9uLTAzPiBzdGF0ZXMgdGhhdCB0aGUgVG9rZW4gQmluZGluZyBwcm90b2NvbCB2ZXJz aW9uIGlzIG5lZ290aWF0ZWQgdmlhIHRoZSB0b2tlbl9iaW5kaW5nIFRMUyBleHRlbnNpb24gKHRl bXBvcmFyeSBJQU5BIGNvZGUgcG9pbnQgMjQpLg0KVGhlIGNsaWVudCBvZmZlcnMgdGhlIGhpZ2hl c3Qgc3VwcG9ydGVkIFRCIHByb3RvY29sIHZlcnNpb24sIGFuZCB0aGUgc2VydmVyIHJlc3BvbmRz IHdpdGggdGhlIGxvd2VyIG9mIHRoZSBUQiBwcm90b2NvbCB2ZXJzaW9uIG9mZmVyZWQgYnkgdGhl IGNsaWVudCBhbmQgdGhlIGhpZ2hlc3QgdmVyc2lvbiBzdXBwb3J0ZWQgYnkgdGhlIHNlcnZlci4N Cg0KUHJvczoNCg0KLSAgICAgICAgICBUcmllZCBhbmQgdGVzdGVkIG1lY2hhbmlzbSwgY3VycmVu dGx5IHVzZWQgYnkgdGhlIGRyYWZ0IGltcGxlbWVudGF0aW9ucyBvZiBUQi4NCg0KLSAgICAgICAg ICBSZXF1aXJlcyBvbmUgVExTIGV4dGVuc2lvbiBmb3IgYWxsIFRCIHZlcnNpb25zLCB1bnRpbCB0 aGUgaHlwb3RoZXRpY2FsIG1vbWVudCBpbiB0aGUgZnV0dXJlLCB3aGVuIHRoZSBUQiBwcm90b2Nv bCBjaGFuZ2VzIHNvIG11Y2ggdGhhdCBhZGRpdGlvbmFsIHBhcmFtZXRlcnMgbmVlZCB0byBiZSBu ZWdvdGlhdGVkLCBvdGhlciB0aGFuIHByb3RvY29sIHZlcnNpb24gYW5kIFRCIGtleSBwYXJhbWV0 ZXJzLg0KDQotICAgICAgICAgIFRva2VuIEJpbmRpbmcgcHJvdG9jb2wgaW1wbGVtZW50YXRpb24g Y2FuIGJlIHVwZ3JhZGVkIGluZGVwZW5kZW50bHkgb2YgdGhlIFRMUyBzdGFjay4NCg0KQ29uczoN Cg0KLSAgICAgICAgICBXaGVuIHRoZSBzZXJ2ZXIgcGlja3MgYSBUQiBwcm90b2NvbCB2ZXJzaW9u IGxvd2VyIHRoYW4gdGhhdCBvZmZlcmVkIGJ5IHRoZSBjbGllbnQsIHRoZSBzZXJ2ZXIgZG9lcyBu b3Qga25vdyB3aGV0aGVyIFRCIGlzIG5lZ290aWF0ZWQsIHVudGlsIHRoZSBmaXJzdCBhcHBsaWNh dGlvbl9kYXRhIG1lc3NhZ2UgaXMgcmVjZWl2ZWQuDQoNCi0gICAgICAgICAgQnJva2VuIFRCIGlt cGxlbWVudGF0aW9ucyBtaWdodCBnZXQgVEIgdmVyc2lvbiBuZWdvdGlhdGlvbiB3cm9uZywgd2hp Y2ggd291bGQgcmVzdWx0IGluIHRoZSBjbGllbnQgYW5kIHNlcnZlciBmYWlsaW5nIHRvIG5lZ290 aWF0ZSBUQi4NCg0KQWx0ZXJuYXRpdmUgcHJvcG9zYWwgZm9yIFRCIFdHIGNvbnNpZGVyYXRpb246 DQoNCjEuICAgICAgICAgUmVtb3ZlIHRoZSB0b2tlbl9iaW5kaW5nX3ZlcnNpb24gZmllbGQgZnJv bSB0aGUgdG9rZW5fYmluZGluZyBleHRlbnNpb247DQoNCjIuICAgICAgICAgV29yayB3aXRoIHRo ZSBUTFMgV0cgdG8gc2V0IGFzaWRlIGEgcmFuZ2Ugb2YgVExTIGV4dGVuc2lvbiBjb2RlIHBvaW50 cyBmcm9tIHdoaWNoIHJhbmRvbSBhc3NpZ25tZW50cyBvZiBzdGlsbC1mcmVlIGNvZGUgcG9pbnRz IGNhbiBiZSBwaWNrZWQgYnkgdGhlIFRCIFdHOw0KDQozLiAgICAgICAgIFBpY2sgYSByYW5kb20g VExTIGV4dGVuc2lvbiBjb2RlIHBvaW50IGZyb20gdGhpcyByYW5nZSBmb3IgZWFjaCBUQiBkcmFm dCB0aGF0IGJyZWFrcyBjb21wYXRpYmlsaXR5Ow0KDQo0LiAgICAgICAgIEEgVExTIGNsaWVudCBj YW4gYWR2ZXJ0aXNlIG11bHRpcGxlIG9mIHRoZXNlIFRMUyBleHRlbnNpb24gSURzIGluIHRoZSBz YW1lIENsaWVudEhlbGxvLCB0aGUgc2VydmVyIGhhcyB0byBwaWNrIG5vIG1vcmUgdGhhbiBvbmU7 DQoNCjUuICAgICAgICAgSUFOQSB3aWxsIGV2ZW50dWFsbHkgcmVnaXN0ZXIgb25lIG9mIHRoZXNl IGNvZGUgcG9pbnRzIGZvciB1c2Ugd2l0aCB0aGUgZmluYWxpemVkIFRCIDEuMC4NClByb3M6DQoN Ci0gICAgICAgICAgVGhlIGNsaWVudCBhZHZlcnRpc2VzIGFsbCBzdXBwb3J0ZWQgVEIgdmVyc2lv bnMsIHNvIHRoZSBzZXJ2ZXIga25vd3Mgd2hldGhlciBUQiBpcyBuZWdvdGlhdGVkIGFmdGVyIHBy b2Nlc3NpbmcgdGhlIENsaWVudEhlbGxvLg0KDQotICAgICAgICAgIFNvbWUgV0cgcGFydGljaXBh bnRzIGJlbGlldmUgdGhhdCB0aGlzIG1lY2hhbmlzbSBvZiBUQiB2ZXJzaW9uIG5lZ290aWF0aW9u IGlzIGxlc3MgbGlrZWx5IHRvIGJlY29tZSB1bnVzYWJsZSBkdWUgdG8gYnJva2VuIGltcGxlbWVu dGF0aW9ucy4NCg0KQ29uczoNCg0KLSAgICAgICAgICBSZXF1aXJlcyBUTFMgV0cgdG8gYXBwcm92 ZSBhIHJhbmdlIG9mIFRMUyBleHRlbnNpb24gY29kZSBwb2ludHM7DQoNCi0gICAgICAgICAgVXNl cyBhIGxvdCBtb3JlIGJ5dGVzIGluIHRoZSBDbGllbnRIZWxsbywgd2hlbiBtdWx0aXBsZSBUQiB2 ZXJzaW9ucyBhcmUgYWR2ZXJ0aXNlZCAoYmVjYXVzZSBUQiBrZXkgcGFyYW1ldGVycyBhcmUgZHVw bGljYXRlZCBpbiBlYWNoIGV4dGVuc2lvbikuDQoNCi0gICAgICAgICAgVEIgaW1wbGVtZW50YXRp b24gdXBncmFkZSByZXF1aXJlcyBUTFMgc3RhY2sgdXBncmFkZSBvciDigJxnZW5lcmljIFRMUyBl eHRlbnNpb27igJ0gc3VwcG9ydCBpbiB0aGUgVExTIHN0YWNrIChub3QgZ2VuZXJhbGx5IGF2YWls YWJsZSBhdCB0aGUgbW9tZW50KS4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KDQpGcm9tOiBKb2hu IEJyYWRsZXkgW21haWx0bzp2ZTdqdGJAdmU3anRiLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXVn dXN0IDI0LCAyMDE2IDY6MDMgUE0NClRvOiBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNy b3NvZnQuY29tPg0KQ2M6IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bT47IEJpbGwgQ294IDx3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPjsgTmljayBIYXJwZXIgPG5oYXJw ZXJAZ29vZ2xlLmNvbT47IHVuYmVhcmFibGVAaWV0Zi5vcmc7IE1hcnRpbiBUaG9tc29uIDxtYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb20+OyBTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBj cy50Y2QuaWU+OyBMZWlmIEpvaGFuc3NvbiA8bGVpZmpAc3VuZXQuc2U+DQpTdWJqZWN0OiBSRTog W1VuYmVhcmFibGVdIFRMUyBleHRlbnNpb246IHZlcnNpb24gZmllbGQNCg0KDQpGaXJzdCB3ZSBu ZWVkIHRvIGRldGVybWluZSBpZiB0aGVyZSBpcyBjb25zZW5zdXMgZm9yIGEgY2hhbmdlLg0KDQpB bmRyZWkgY2FuIHlvdSBzdW5yaXNlIHRoZSBjdXJyZW50IHN0YXRlIGFuZCBvcHRpb25zIHRvIHRo ZSBsaXN0Lg0KDQpUaGFua3MuDQoNCkpvaG4gQi4NCg0KT24gQXVnIDI0LCAyMDE2IDIxOjQ3LCAi QW5kcmVpIFBvcG92IiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Q b3BvdkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQo+PiBQaWNraW5nIGEgcmFuZG9tIHVuYXNzaWdu ZWQgZXh0ZW5zaW9uIElEIHNlZW1zIGEgYml0IHNtZWxseSBpZg0KPj4gdGhlcmUncyBubyByYW5n ZSBzZXQgYXNpZGUgZm9yIGZyb20gd2hpY2ggb25lIGNhbiBwaWNrLCB3aGljaA0KPj4gSSB0aGlu ayBpcyB0aGUgY2FzZSBmb3IgWzFdLg0KWWVzLCB0aGlzIGlzIG9uZSBvZiB0aGUgY29uY2VybnMg d2l0aCB0aGUgcHJvcG9zZWQgc2NoZW1lLiBBbmQgb25lIG9mIHRoZSByZWFzb25zIEkgd291bGQg cmF0aGVyIGtlZXAgdGhlIGN1cnJlbnQgVEIgdmVyc2lvbiBuZWdvdGlhdGlvbiBtZWNoYW5pc20u DQoNCj4gRWl0aGVyIHdheSwgZ2V0dGluZyB0aGF0IGFncmVlZCBvbiB0aGUgVExTIGxpc3Qgd291 bGQgYmUgYSBnb29kIHBsYW4uDQpXaGF0IGRvIHRoZSBDaGFpcnMgdGhpbms6IHNob3VsZCB0aGUg cHJvcG9uZW50cyBzdGFydCB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgVExTIFdHIGxpc3QsIG9yIHNo b3VsZCB3ZSBnYXVnZSBjb25zZW5zdXMgaW4gdGhlIFRCIFdHIGZpcnN0Pw0KDQpDaGVlcnMsDQoN CkFuZHJlaQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogU3RlcGhlbiBGYXJy ZWxsIFttYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZTxtYWlsdG86c3RlcGhlbi5mYXJy ZWxsQGNzLnRjZC5pZT5dDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAyNCwgMjAxNiAxOjQ2IFBN DQpUbzogSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0 Yi5jb20+Pg0KQ2M6IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFp bHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj47IHVuYmVhcmFibGVAaWV0Zi5vcmc8bWFp bHRvOnVuYmVhcmFibGVAaWV0Zi5vcmc+OyBCaWxsIENveCA8d2F5d2FyZGdlZWtAZ29vZ2xlLmNv bTxtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbT4+OyBCcmlhbiBDYW1wYmVsbCA8YmNhbXBi ZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj47 IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbT4+OyBOaWNrIEhhcnBlciA8bmhhcnBlckBnb29nbGUuY29tPG1haWx0 bzpuaGFycGVyQGdvb2dsZS5jb20+Pg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBUTFMgZXh0 ZW5zaW9uOiB2ZXJzaW9uIGZpZWxkDQoNCg0KDQpPbiAyNC8wOC8xNiAyMTozOCwgSm9obiBCcmFk bGV5IHdyb3RlOg0KPiBGb3IgcHJlcHJvZHVjdGlvbiBvciBleHBlcmltZW50YWwgdmVyc2lvbiBp cyB1c2luZyB0aGUgZXhwZXJpbWVudGFsIHNwYWNlIG1ha2Ugc2Vuc2UgYW5kIHRoZW4gdXNlIDI0 IGZvciB0aGUgUkZDIHZlcnNpb24/DQo+DQoNClRoZXJlJ3Mgbm8gZXhwZXJpbWVudGFsIHJhbmdl IHNldCBhc2lkZSBpbiB0aGF0IHJlZ2lzdHJ5IHRoYXQNCkkgY2FuIHNlZS4gQW5kIGZvbGtzIGhh dmUgaGFkIGlzc3VlcyB3aXRoIHN1Y2gsIHdoZW4gaXQgdHVybnMNCm91dCB0aGF0IGEgY29kZXBv aW50IGZyb20gdGhlIGV4cGVyaW1lbnRhbCByYW5nZSBoYXMgImVzY2FwZWQiDQppbnRvIHRoZSB3 aWxkIHRvIHN1Y2ggYW4gZXh0ZW50IHRoYXQgbm9ib2R5IGVsc2UgY291bGQgdXNlIGl0DQp0byBk byBleHBlcmltZW50cy4NCg0KV2hhdCBJIHRob3VnaHQgd2FzIGJlaW5nIHByb3Bvc2VkIGhlcmUg d2FzIGEgbGl0dGxlIGRpZmZlcmVudCwNCmJlaW5nIHRvIHNldCBhc2lkZSBhIHJhbmdlIGZyb20g d2hpY2ggcmFuZG9tIGFzc2lnbm1lbnRzIG9mDQpzdGlsbC1mcmVlIGNvZGVwb2ludHMgY2FuIGJl IHBpY2tlZCBieSB0aGlzIFdHIChvciBtYXliZSB0aGlzDQpvciBvdGhlcnMpIGFuZCB3aGVyZSB0 aGUgcmFuZG9tbHkgYXNzaWduZWQgY29kZXBvaW50IG1pZ2h0DQp0dXJuIGludG8gb25lIHRoYXQn cyBwZXJtYW5lbnRseSBhc3NpZ25lZCBsYXRlci4NCg0KU28gb25lIGNvdWxkIHByb3Bvc2UgZWl0 aGVyIHNldHRpbmcgYXNpZGUgYW4gZXhwZXJpbWVudGFsDQpyYW5nZSwgb3IgZG9pbmcgc29tZXRo aW5nIG5ldyBhcyBpbiB0aGUgcGFyYWdyYXBoIGFib3ZlIEkNCmd1ZXNzLiBFaXRoZXIgd2F5LCBn ZXR0aW5nIHRoYXQgYWdyZWVkIG9uIHRoZSBUTFMgbGlzdCB3b3VsZA0KYmUgYSBnb29kIHBsYW4u DQoNCkNoZWVycw0KUy4NCg0KPiBXZSBuZWVkIHNvbWV0aGluZyB0byB1c2UgZm9yIGludGVyb3Ag dGVzdGluZy4NCj4NCj4gSm9obiBCPw0KPj4gT24gQXVnIDI0LCAyMDE2LCBhdCA1OjI5IFBNLCBT dGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8bWFpbHRvOnN0ZXBoZW4u ZmFycmVsbEBjcy50Y2QuaWU+PiB3cm90ZToNCj4+DQo+Pg0KPj4gSGkgYWxsLA0KPj4NCj4+IE9u IDI0LzA4LzE2IDIwOjA2LCBBbmRyZWkgUG9wb3Ygd3JvdGU6DQo+Pj4gMi4gICAgICAgICBQaWNr IGEgcmFuZG9tIHVuYXNzaWduZWQgVExTIGV4dGVuc2lvbiBJRCBmb3IgZWFjaCBUQiBkcmFmdCB0 aGF0IGJyZWFrcyBjb21wYXRpYmlsaXR5Ow0KPj4NCj4+IElmIHRoaXMgcGxhbiBkb2VzIGdhcm5l ciBjb25zZW5zdXMgaGVyZSwgcGxlYXNlIHZlcmlmeSBpdCB3aXRoIHRoZQ0KPj4gVExTIFdHIC0g dGhvc2UgWzFdIGFyZSAidGhlaXIiIGNvZGVwb2ludHMgYWZ0ZXIgYWxsLg0KPj4NCj4+IFBpY2tp bmcgYSByYW5kb20gdW5hc3NpZ25lZCBleHRlbnNpb24gSUQgc2VlbXMgYSBiaXQgc21lbGx5IGlm DQo+PiB0aGVyZSdzIG5vIHJhbmdlIHNldCBhc2lkZSBmb3IgZnJvbSB3aGljaCBvbmUgY2FuIHBp Y2ssIHdoaWNoDQo+PiBJIHRoaW5rIGlzIHRoZSBjYXNlIGZvciBbMV0uDQo+Pg0KPj4gSWYgZm9s a3Mgd2FudCB0byB0YWtlIHRoYXQgYXBwcm9hY2ggdGhlbiB0aGUgcmlnaHQgdGhpbmcgdG8gZG8N Cj4+IHdvdWxkIGJlIHRvIGdldCBzdWNoIGEgcmFuZ2UgYXNzaWduZWQuDQo+Pg0KPj4gUy4NCj4+ DQo+PiBbMV0NCj4+IGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3Rscy1leHRlbnNp b250eXBlLXZhbHVlcy90bHMtZXh0ZW5zaW9udHlwZS12YWx1ZXMueGh0bWwjdGxzLWV4dGVuc2lv bnR5cGUtdmFsdWVzLTENCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QNCj4+IFVuYmVhcmFibGVA aWV0Zi5vcmc8bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmc+DQo+PiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCj4NCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QN Cj4gVW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5iZWFyYWJsZUBpZXRmLm9yZz4NCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQo+DQo= --_000_CY1PR03MB215526D81479A2C23146A6588CED0CY1PR03MB2155namp_ 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 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9y bWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KcC5tMjE0NjQxNDkwNzA2NTM1MDMyOW1zb2xpc3RwYXJh Z3JhcGgsIGxpLm0yMTQ2NDE0OTA3MDY1MzUwMzI5bXNvbGlzdHBhcmFncmFwaCwgZGl2Lm0yMTQ2 NDE0OTA3MDY1MzUwMzI5bXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTptXzIxNDY0 MTQ5MDcwNjUzNTAzMjltc29saXN0cGFyYWdyYXBoOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3NzUzNjc3MTU7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjc3NDE1NDUwNCAtNzA2MzE1NDQ2IDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3Qt aWQ6MTIyMTU5NDQzNTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6LTEwMTAyODQ5NDYgLTIwNzUyNTEzNTAgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMg Njc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6 bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDozOS4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTIxLjBwdDt9 DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0K QGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVs Nw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxMzE3 MzM5NjIxOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczox NzM0MzY0ODgwIC00OTIwMTg5NTAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJ e21zby1sZXZlbC1zdGFydC1hdDo0Ow0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMjpsZXZlbDINCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxNjMwNjIwOTI4Ow0K CW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTc0NTMyNjQ0 NiA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2 NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30N CkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsNA0KCXtt c28tbGlzdC1pZDoxODgyNTkwNjYyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczo5MzU4NzQ1NzIgLTcwNjMxNTQ0NiA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlz dCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1i aWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw0OmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGw0OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBs NDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCkBsaXN0IGw1DQoJe21zby1saXN0LWlkOjE5MDQ2Nzg4MDI7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDE5MDczMzkyIDY3Njk4NzAzIDY3 Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4 NzEzIDY3Njk4NzE1O30NCkBsaXN0IGw1OmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGw1OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9 DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNTps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDU6bGV2 ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDU6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDU6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGw2DQoJe21zby1saXN0LWlkOjE5 MzA3NzQ1MzU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi03MTYyNzE1NDQgLTcwNjMxNTQ0NiA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcx MyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsNjpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw2OmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGw2OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K CXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsNjpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsNjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxw aGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNjpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDot OS4wcHQ7fQ0KQGxpc3QgbDY6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDY6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDY6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGw3DQoJe21zby1saXN0LWlkOjIwNzI4MDI0MjM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE3NzAyOTQ0ODQgLTkzNzY1MDQ2NiA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 Mzt9DQpAbGlzdCBsNzpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjQ7DQoJbXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iO30NCkBsaXN0IGw3OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDc6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw0DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDc6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsNzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNzpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGw3OmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJ e21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWlu ZGVudDotLjI1aW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5BbmRyZWkgY2Fu IHlvdSBzdW5yaXNlIHRoZSBjdXJyZW50IHN0YXRlIGFuZCBvcHRpb25zIHRvIHRoZSBsaXN0Ljxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5HbGFk bHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldoYXQgd2UgaGF2ZSBub3c6PG86cD48L286cD48L3NwYW4+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Q3VycmVudGx5 LA0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmlu ZC1uZWdvdGlhdGlvbi0wMyI+VEJORUdPLTAzPC9hPiBzdGF0ZXMgdGhhdCB0aGUgVG9rZW4gQmlu ZGluZyBwcm90b2NvbCB2ZXJzaW9uIGlzIG5lZ290aWF0ZWQgdmlhIHRoZSB0b2tlbl9iaW5kaW5n IFRMUyBleHRlbnNpb24gKHRlbXBvcmFyeSBJQU5BIGNvZGUgcG9pbnQgMjQpLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGNs aWVudCBvZmZlcnMgdGhlIGhpZ2hlc3Qgc3VwcG9ydGVkIFRCIHByb3RvY29sIHZlcnNpb24sIGFu ZCB0aGUgc2VydmVyIHJlc3BvbmRzIHdpdGggdGhlIGxvd2VyIG9mIHRoZSBUQiBwcm90b2NvbCB2 ZXJzaW9uIG9mZmVyZWQgYnkgdGhlIGNsaWVudCBhbmQgdGhlIGhpZ2hlc3QgdmVyc2lvbg0KIHN1 cHBvcnRlZCBieSB0aGUgc2VydmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Qcm9zOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6 LS4yNWluO21zby1saXN0Omw2IGxldmVsMSBsZm85Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VHJpZWQgYW5kIHRlc3RlZCBtZWNoYW5pc20s IGN1cnJlbnRseSB1c2VkIGJ5IHRoZSBkcmFmdCBpbXBsZW1lbnRhdGlvbnMgb2YgVEIuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDYgbGV2ZWwxIGxmbzkiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SZXF1aXJlcyBvbmUgVExTIGV4 dGVuc2lvbiBmb3IgYWxsIFRCIHZlcnNpb25zLCB1bnRpbCB0aGUgaHlwb3RoZXRpY2FsIG1vbWVu dCBpbiB0aGUgZnV0dXJlLCB3aGVuIHRoZSBUQiBwcm90b2NvbCBjaGFuZ2VzIHNvIG11Y2ggdGhh dCBhZGRpdGlvbmFsIHBhcmFtZXRlcnMgbmVlZA0KIHRvIGJlIG5lZ290aWF0ZWQsIG90aGVyIHRo YW4gcHJvdG9jb2wgdmVyc2lvbiBhbmQgVEIga2V5IHBhcmFtZXRlcnMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDot LjI1aW47bXNvLWxpc3Q6bDYgbGV2ZWwxIGxmbzkiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Ub2tlbiBCaW5kaW5nIHByb3RvY29sIGltcGxl bWVudGF0aW9uIGNhbiBiZSB1cGdyYWRlZCBpbmRlcGVuZGVudGx5IG9mIHRoZSBUTFMgc3RhY2su PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkNvbnM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDQgbGV2 ZWwxIGxmbzgiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5XaGVuIHRoZSBzZXJ2ZXIgcGlja3MgYSBUQiBwcm90b2NvbCB2ZXJzaW9uIGxvd2Vy IHRoYW4gdGhhdCBvZmZlcmVkIGJ5IHRoZSBjbGllbnQsIHRoZSBzZXJ2ZXIgZG9lcyBub3Qga25v dyB3aGV0aGVyIFRCIGlzIG5lZ290aWF0ZWQsIHVudGlsIHRoZSBmaXJzdCBhcHBsaWNhdGlvbl9k YXRhDQogbWVzc2FnZSBpcyByZWNlaXZlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDps NCBsZXZlbDEgbGZvOCI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48c3Bh biBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkJyb2tlbiBUQiBpbXBsZW1lbnRhdGlvbnMgbWlnaHQgZ2V0IFRCIHZlcnNp b24gbmVnb3RpYXRpb24gd3JvbmcsIHdoaWNoIHdvdWxkIHJlc3VsdCBpbiB0aGUgY2xpZW50IGFu ZCBzZXJ2ZXIgZmFpbGluZyB0byBuZWdvdGlhdGUgVEIuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFsdGVy bmF0aXZlIHByb3Bvc2FsIGZvciBUQiBXRyBjb25zaWRlcmF0aW9uOjxvOnA+PC9vOnA+PC9zcGFu PjwvYj48L3A+DQo8cCBjbGFzcz0ibTIxNDY0MTQ5MDcwNjUzNTAzMjltc29saXN0cGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzkuMHB0O3RleHQtaW5kZW50Oi0yMS4wcHQ7bXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzUiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5SZW1vdmUgdGhlIHRva2VuX2JpbmRpbmdfdmVyc2lvbiBmaWVsZCBmcm9tIHRo ZSB0b2tlbl9iaW5kaW5nIGV4dGVuc2lvbjs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0ibTIxNDY0MTQ5MDcwNjUzNTAzMjltc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzkuMHB0O3RleHQtaW5kZW50Oi0yMS4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzUiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Xb3JrIHdp dGggdGhlIFRMUyBXRyB0byBzZXQgYXNpZGUgYSByYW5nZSBvZiBUTFMgZXh0ZW5zaW9uIGNvZGUg cG9pbnRzIGZyb20gd2hpY2ggcmFuZG9tIGFzc2lnbm1lbnRzIG9mIHN0aWxsLWZyZWUgY29kZSBw b2ludHMgY2FuIGJlIHBpY2tlZCBieSB0aGUgVEIgV0c7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Im0yMTQ2NDE0OTA3MDY1MzUwMzI5bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM5LjBwdDt0ZXh0LWluZGVudDotMjEuMHB0O21zby1saXN0OmwxIGxldmVsMSBs Zm81Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ UGljayBhIHJhbmRvbSBUTFMgZXh0ZW5zaW9uIGNvZGUgcG9pbnQgZnJvbSB0aGlzIHJhbmdlIGZv ciBlYWNoIFRCIGRyYWZ0IHRoYXQgYnJlYWtzIGNvbXBhdGliaWxpdHk7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Im0yMTQ2NDE0OTA3MDY1MzUwMzI5bXNvbGlzdHBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM5LjBwdDt0ZXh0LWluZGVudDotMjEuMHB0O21zby1saXN0Omwx IGxldmVsMSBsZm81Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PHNw YW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+NC48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+QSBUTFMgY2xpZW50IGNhbiBhZHZlcnRpc2UgbXVsdGlwbGUgb2YgdGhlc2UgVExT IGV4dGVuc2lvbiBJRHMgaW4gdGhlIHNhbWUgQ2xpZW50SGVsbG8sIHRoZSBzZXJ2ZXIgaGFzIHRv IHBpY2sgbm8gbW9yZSB0aGFuIG9uZTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i bTIxNDY0MTQ5MDcwNjUzNTAzMjltc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzkuMHB0O3RleHQtaW5kZW50Oi0yMS4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzUiPg0KPCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj41LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JQU5BIHdpbGwg ZXZlbnR1YWxseSByZWdpc3RlciBvbmUgb2YgdGhlc2UgY29kZSBwb2ludHMgZm9yIHVzZSB3aXRo IHRoZSBmaW5hbGl6ZWQgVEIgMS4wLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+UHJvczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvNiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBjbGllbnQgYWR2ZXJ0aXNlcyBhbGwgc3VwcG9ydGVkIFRC IHZlcnNpb25zLCBzbyB0aGUgc2VydmVyIGtub3dzIHdoZXRoZXIgVEIgaXMgbmVnb3RpYXRlZCBh ZnRlciBwcm9jZXNzaW5nIHRoZSBDbGllbnRIZWxsby48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvNiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPlNvbWUgV0cgcGFydGljaXBhbnRzIGJlbGlldmUgdGhhdCB0aGlz IG1lY2hhbmlzbSBvZiBUQiB2ZXJzaW9uIG5lZ290aWF0aW9uIGlzIGxlc3MgbGlrZWx5IHRvIGJl Y29tZSB1bnVzYWJsZSBkdWUgdG8gYnJva2VuIGltcGxlbWVudGF0aW9ucy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Q29uczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvNiI+PCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJlcXVp cmVzIFRMUyBXRyB0byBhcHByb3ZlIGEgcmFuZ2Ugb2YgVExTIGV4dGVuc2lvbiBjb2RlIHBvaW50 czs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvNiI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlVzZXMgYSBsb3Qg bW9yZSBieXRlcyBpbiB0aGUgQ2xpZW50SGVsbG8sIHdoZW4gbXVsdGlwbGUgVEIgdmVyc2lvbnMg YXJlIGFkdmVydGlzZWQgKGJlY2F1c2UgVEIga2V5IHBhcmFtZXRlcnMgYXJlIGR1cGxpY2F0ZWQg aW4gZWFjaCBleHRlbnNpb24pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVs MSBsZm82Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+VEIgaW1wbGVtZW50YXRpb24gdXBncmFkZSByZXF1aXJlcyBUTFMgc3RhY2sgdXBncmFk ZSBvciDigJxnZW5lcmljIFRMUyBleHRlbnNpb27igJ0gc3VwcG9ydCBpbiB0aGUgVExTIHN0YWNr IChub3QgZ2VuZXJhbGx5IGF2YWlsYWJsZSBhdCB0aGUgbW9tZW50KS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSm9obiBCcmFkbGV5IFttYWlsdG86 dmU3anRiQHZlN2p0Yi5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3Qg MjQsIDIwMTYgNjowMyBQTTxicj4NCjxiPlRvOjwvYj4gQW5kcmVpIFBvcG92ICZsdDtBbmRyZWku UG9wb3ZAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEJyaWFuIENhbXBiZWxsICZs dDtiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSZndDs7IEJpbGwgQ294ICZsdDt3YXl3YXJkZ2Vl a0Bnb29nbGUuY29tJmd0OzsgTmljayBIYXJwZXIgJmx0O25oYXJwZXJAZ29vZ2xlLmNvbSZndDs7 IHVuYmVhcmFibGVAaWV0Zi5vcmc7IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4udGhvbXNvbkBn bWFpbC5jb20mZ3Q7OyBTdGVwaGVuIEZhcnJlbGwgJmx0O3N0ZXBoZW4uZmFycmVsbEBjcy50Y2Qu aWUmZ3Q7OyBMZWlmIEpvaGFuc3NvbiAmbHQ7bGVpZmpAc3VuZXQuc2UmZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJFOiBbVW5iZWFyYWJsZV0gVExTIGV4dGVuc2lvbjogdmVyc2lvbiBmaWVsZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHA+Rmlyc3Qgd2UgbmVlZCB0byBkZXRlcm1pbmUgaWYgdGhlcmUgaXMgY29uc2Vu c3VzIGZvciBhIGNoYW5nZS4gPG86cD48L286cD48L3A+DQo8cD5BbmRyZWkgY2FuIHlvdSBzdW5y aXNlIHRoZSBjdXJyZW50IHN0YXRlIGFuZCBvcHRpb25zIHRvIHRoZSBsaXN0LiZuYnNwOyA8bzpw PjwvbzpwPjwvcD4NCjxwPlRoYW5rcy4gPG86cD48L286cD48L3A+DQo8cD5Kb2huIEIuIDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEF1ZyAyNCwgMjAxNiAyMTo0Nywg JnF1b3Q7QW5kcmVpIFBvcG92JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92 QG1pY3Jvc29mdC5jb20iPkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mZ3Q7Jmd0OyBQaWNraW5nIGEgcmFuZG9tIHVuYXNzaWdu ZWQgZXh0ZW5zaW9uIElEIHNlZW1zIGEgYml0IHNtZWxseSBpZjxicj4NCiZndDsmZ3Q7IHRoZXJl J3Mgbm8gcmFuZ2Ugc2V0IGFzaWRlIGZvciBmcm9tIHdoaWNoIG9uZSBjYW4gcGljaywgd2hpY2g8 YnI+DQomZ3Q7Jmd0OyBJIHRoaW5rIGlzIHRoZSBjYXNlIGZvciBbMV0uPGJyPg0KWWVzLCB0aGlz IGlzIG9uZSBvZiB0aGUgY29uY2VybnMgd2l0aCB0aGUgcHJvcG9zZWQgc2NoZW1lLiBBbmQgb25l IG9mIHRoZSByZWFzb25zIEkgd291bGQgcmF0aGVyIGtlZXAgdGhlIGN1cnJlbnQgVEIgdmVyc2lv biBuZWdvdGlhdGlvbiBtZWNoYW5pc20uPGJyPg0KPGJyPg0KJmd0OyBFaXRoZXIgd2F5LCBnZXR0 aW5nIHRoYXQgYWdyZWVkIG9uIHRoZSBUTFMgbGlzdCB3b3VsZCBiZSBhIGdvb2QgcGxhbi48YnI+ DQpXaGF0IGRvIHRoZSBDaGFpcnMgdGhpbms6IHNob3VsZCB0aGUgcHJvcG9uZW50cyBzdGFydCB0 aGUgZGlzY3Vzc2lvbiBvbiB0aGUgVExTIFdHIGxpc3QsIG9yIHNob3VsZCB3ZSBnYXVnZSBjb25z ZW5zdXMgaW4gdGhlIFRCIFdHIGZpcnN0Pzxicj4NCjxicj4NCkNoZWVycyw8YnI+DQo8YnI+DQpB bmRyZWk8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IFN0 ZXBoZW4gRmFycmVsbCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3Mu dGNkLmllIj5zdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPC9hPl08YnI+DQpTZW50OiBXZWRuZXNk YXksIEF1Z3VzdCAyNCwgMjAxNiAxOjQ2IFBNPGJyPg0KVG86IEpvaG4gQnJhZGxleSAmbHQ7PGEg aHJlZj0ibWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7 PGJyPg0KQ2M6IEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBt aWNyb3NvZnQuY29tIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7Ow0KPGEgaHJl Zj0ibWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmciPnVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+OyBC aWxsIENveCAmbHQ7PGEgaHJlZj0ibWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb20iPndheXdh cmRnZWVrQGdvb2dsZS5jb208L2E+Jmd0OzsgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1h aWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j b208L2E+Jmd0OzsgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhv bXNvbkBnbWFpbC5jb20iPm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7Ow0KIE5pY2sg SGFycGVyICZsdDs8YSBocmVmPSJtYWlsdG86bmhhcnBlckBnb29nbGUuY29tIj5uaGFycGVyQGdv b2dsZS5jb208L2E+Jmd0Ozxicj4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gVExTIGV4dGVu c2lvbjogdmVyc2lvbiBmaWVsZDxicj4NCjxicj4NCjxicj4NCjxicj4NCk9uIDI0LzA4LzE2IDIx OjM4LCBKb2huIEJyYWRsZXkgd3JvdGU6PGJyPg0KJmd0OyBGb3IgcHJlcHJvZHVjdGlvbiBvciBl eHBlcmltZW50YWwgdmVyc2lvbiBpcyB1c2luZyB0aGUgZXhwZXJpbWVudGFsIHNwYWNlIG1ha2Ug c2Vuc2UgYW5kIHRoZW4gdXNlIDI0IGZvciB0aGUgUkZDIHZlcnNpb24/PGJyPg0KJmd0Ozxicj4N Cjxicj4NClRoZXJlJ3Mgbm8gZXhwZXJpbWVudGFsIHJhbmdlIHNldCBhc2lkZSBpbiB0aGF0IHJl Z2lzdHJ5IHRoYXQ8YnI+DQpJIGNhbiBzZWUuIEFuZCBmb2xrcyBoYXZlIGhhZCBpc3N1ZXMgd2l0 aCBzdWNoLCB3aGVuIGl0IHR1cm5zPGJyPg0Kb3V0IHRoYXQgYSBjb2RlcG9pbnQgZnJvbSB0aGUg ZXhwZXJpbWVudGFsIHJhbmdlIGhhcyAmcXVvdDtlc2NhcGVkJnF1b3Q7PGJyPg0KaW50byB0aGUg d2lsZCB0byBzdWNoIGFuIGV4dGVudCB0aGF0IG5vYm9keSBlbHNlIGNvdWxkIHVzZSBpdDxicj4N CnRvIGRvIGV4cGVyaW1lbnRzLjxicj4NCjxicj4NCldoYXQgSSB0aG91Z2h0IHdhcyBiZWluZyBw cm9wb3NlZCBoZXJlIHdhcyBhIGxpdHRsZSBkaWZmZXJlbnQsPGJyPg0KYmVpbmcgdG8gc2V0IGFz aWRlIGEgcmFuZ2UgZnJvbSB3aGljaCByYW5kb20gYXNzaWdubWVudHMgb2Y8YnI+DQpzdGlsbC1m cmVlIGNvZGVwb2ludHMgY2FuIGJlIHBpY2tlZCBieSB0aGlzIFdHIChvciBtYXliZSB0aGlzPGJy Pg0Kb3Igb3RoZXJzKSBhbmQgd2hlcmUgdGhlIHJhbmRvbWx5IGFzc2lnbmVkIGNvZGVwb2ludCBt aWdodDxicj4NCnR1cm4gaW50byBvbmUgdGhhdCdzIHBlcm1hbmVudGx5IGFzc2lnbmVkIGxhdGVy Ljxicj4NCjxicj4NClNvIG9uZSBjb3VsZCBwcm9wb3NlIGVpdGhlciBzZXR0aW5nIGFzaWRlIGFu IGV4cGVyaW1lbnRhbDxicj4NCnJhbmdlLCBvciBkb2luZyBzb21ldGhpbmcgbmV3IGFzIGluIHRo ZSBwYXJhZ3JhcGggYWJvdmUgSTxicj4NCmd1ZXNzLiBFaXRoZXIgd2F5LCBnZXR0aW5nIHRoYXQg YWdyZWVkIG9uIHRoZSBUTFMgbGlzdCB3b3VsZDxicj4NCmJlIGEgZ29vZCBwbGFuLjxicj4NCjxi cj4NCkNoZWVyczxicj4NClMuPGJyPg0KPGJyPg0KJmd0OyBXZSBuZWVkIHNvbWV0aGluZyB0byB1 c2UgZm9yIGludGVyb3AgdGVzdGluZy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBKb2huIEI/PGJyPg0K Jmd0OyZndDsgT24gQXVnIDI0LCAyMDE2LCBhdCA1OjI5IFBNLCBTdGVwaGVuIEZhcnJlbGwgJmx0 OzxhIGhyZWY9Im1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllIj5zdGVwaGVuLmZhcnJl bGxAY3MudGNkLmllPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IE9uIDI0LzA4 LzE2IDIwOjA2LCBBbmRyZWkgUG9wb3Ygd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7IDIuJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BpY2sgYSByYW5kb20gdW5hc3NpZ25lZCBUTFMg ZXh0ZW5zaW9uIElEIGZvciBlYWNoIFRCIGRyYWZ0IHRoYXQgYnJlYWtzIGNvbXBhdGliaWxpdHk7 PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBJZiB0aGlzIHBsYW4gZG9lcyBnYXJuZXIgY29u c2Vuc3VzIGhlcmUsIHBsZWFzZSB2ZXJpZnkgaXQgd2l0aCB0aGU8YnI+DQomZ3Q7Jmd0OyBUTFMg V0cgLSB0aG9zZSBbMV0gYXJlICZxdW90O3RoZWlyJnF1b3Q7IGNvZGVwb2ludHMgYWZ0ZXIgYWxs Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgUGlja2luZyBhIHJhbmRvbSB1bmFzc2lnbmVk IGV4dGVuc2lvbiBJRCBzZWVtcyBhIGJpdCBzbWVsbHkgaWY8YnI+DQomZ3Q7Jmd0OyB0aGVyZSdz IG5vIHJhbmdlIHNldCBhc2lkZSBmb3IgZnJvbSB3aGljaCBvbmUgY2FuIHBpY2ssIHdoaWNoPGJy Pg0KJmd0OyZndDsgSSB0aGluayBpcyB0aGUgY2FzZSBmb3IgWzFdLjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgSWYgZm9sa3Mgd2FudCB0byB0YWtlIHRoYXQgYXBwcm9hY2ggdGhlbiB0aGUg cmlnaHQgdGhpbmcgdG8gZG88YnI+DQomZ3Q7Jmd0OyB3b3VsZCBiZSB0byBnZXQgc3VjaCBhIHJh bmdlIGFzc2lnbmVkLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgUy48YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IFsxXTxicj4NCiZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmlh bmEub3JnL2Fzc2lnbm1lbnRzL3Rscy1leHRlbnNpb250eXBlLXZhbHVlcy90bHMtZXh0ZW5zaW9u dHlwZS12YWx1ZXMueGh0bWwjdGxzLWV4dGVuc2lvbnR5cGUtdmFsdWVzLTEiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3Rscy1leHRlbnNpb250eXBl LXZhbHVlcy90bHMtZXh0ZW5zaW9udHlwZS12YWx1ZXMueGh0bWwjdGxzLWV4dGVuc2lvbnR5cGUt dmFsdWVzLTE8L2E+PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7IFVuYmVhcmFibGUg bWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0 Zi5vcmciPlVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlPC9h Pjxicj4NCiZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0KJmd0OyBVbmJlYXJhYmxlIG1haWxpbmcgbGlzdDxicj4NCiZndDsg PGEgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmciPlVuYmVhcmFibGVAaWV0Zi5vcmc8 L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3VuYmVhcmFibGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3VuYmVhcmFibGU8L2E+PGJyPg0KJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR03MB215526D81479A2C23146A6588CED0CY1PR03MB2155namp_-- From nobody Thu Aug 25 05:52: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 E11A512B005 for ; Thu, 25 Aug 2016 05:52:47 -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, 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 (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 kmwFNTBdQft2 for ; Thu, 25 Aug 2016 05:52:44 -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 75CE812D0A1 for ; Thu, 25 Aug 2016 05:52:44 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id l2so44251437qkf.3 for ; Thu, 25 Aug 2016 05:52:44 -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:message-id:references :to; bh=2oCfTNFUv1Bko87/9Yr0h81zHxtX3DFxRsDEAtO/EzQ=; b=Ij1m56n74CiWVZM+9RuE7WoVbt1ip9bEw/AULzhK8pGtyifXYzetrRx7pZr3Nvag3K hPbIXfld+mUwZLT+NK19KFiq+omDES0VkvUcVRnXxXHkEyvzsXP6BxBzFN5Xj7GKwBTa FSg3OpUw1AJaMpAJ7DRLTLat/CinvzXHQOV/CRARxMUxnutDvO1WKPkBIls1oJsFUUrp ydCuZt2IhSEZ87i2qmvJ0e9tT960g4n/j283TgsJ2rDzTlsRYqCL4S42ebZYlTAFf0bd lUyBIbl8y7rssvM3h1liAMfqWyzFZIaqu5OT//gwUW6qp6y3rIv5yWZpiCZ6/kzLf6so G8ew== 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 :message-id:references:to; bh=2oCfTNFUv1Bko87/9Yr0h81zHxtX3DFxRsDEAtO/EzQ=; b=C5NP8ANhs7V6/WenW1JNLaoJdSu+YsK3IR9T4XAb+J6m/oIj3y1kXX6EaUR8mXzvRO ZZV/rUK4WQlZXL2YRUerb4plrZ7T/LVKaES3HSaulxqgbjEgt1Umw+ZUZ3OVioOD7xkj OxQq5M9rTZ1rahtmJRoB0ijRw8M2IhAuFTOiKDp0a8VJj2HwuBEg+0+k+C0wJnyhdPz4 +PUbAYRvR1IH1fHHJsjZD6cixrLQgSsoygdlyNHp+lo640QiaaMkAb9NmpyNrRQdZMwY xSnVdTL+2J5uSwxz+s1zUERmcHUBoW7KPbCfxzrgfyQEFBAQlZ+2unJiHjz6LTjEAcQ5 UP2g== X-Gm-Message-State: AE9vXwNmDuRZwUfU9OdtNy71CkF3/bbhBSN5PbJNl4eWhfmuSnummLyASpee2JdltiBk8rtW X-Received: by 10.55.160.135 with SMTP id j129mr9401736qke.167.1472129563426; Thu, 25 Aug 2016 05:52:43 -0700 (PDT) Received: from [192.168.1.42] ([191.115.74.245]) by smtp.gmail.com with ESMTPSA id 6sm7529586qke.5.2016.08.25.05.52.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 25 Aug 2016 05:52:42 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_BE1D3B7D-A900-4F03-8697-34764EA99D0A" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Thu, 25 Aug 2016 09:52:29 -0300 Message-Id: <38F8CC64-29B7-4818-B423-F1C7A2939B4D@ve7jtb.com> References: <9b0f1cb3-a74b-2637-159c-e7aa3ee53ec6@cs.tcd.ie> To: Andrei Popov X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "unbearable@ietf.org" , Bill Cox , Brian Campbell , Martin Thomson , Leif Johansson , Nick Harper , Stephen Farrell Subject: Re: [Unbearable] TLS extension: version field 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, 25 Aug 2016 12:52:48 -0000 --Apple-Mail=_BE1D3B7D-A900-4F03-8697-34764EA99D0A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 My personal preference is to stick with what we have now. =20 Needing to mess with upgrading the TLS stack for token binding upgrades = is going to be a major deployment hurdle. Looking what it will take to get TB deployed in different environments = and upgrades to the TLS stacks makes me hesitant to think that is going = to work very often. I suspect that we will find people lees likely to update versions in = that case. What do others think? John B. > On Aug 24, 2016, at 11:02 PM, Andrei Popov = wrote: >=20 > =C3=98 Andrei can you sunrise the current state and options to the = list. >=20 > Gladly. > =20 > What we have now: > Currently, TBNEGO-03 = states = that the Token Binding protocol version is negotiated via the = token_binding TLS extension (temporary IANA code point 24). > The client offers the highest supported TB protocol version, and the = server responds with the lower of the TB protocol version offered by the = client and the highest version supported by the server. > =20 > Pros: > - Tried and tested mechanism, currently used by the draft = implementations of TB. > - Requires one TLS extension for all TB versions, until the = hypothetical moment in the future, when the TB protocol changes so much = that additional parameters need to be negotiated, other than protocol = version and TB key parameters. > - Token Binding protocol implementation can be upgraded = independently of the TLS stack. > =20 > Cons: > - When the server picks a TB protocol version lower than that = offered by the client, the server does not know whether TB is = negotiated, until the first application_data message is received. > - Broken TB implementations might get TB version negotiation = wrong, which would result in the client and server failing to negotiate = TB. > =20 > Alternative proposal for TB WG consideration: > 1. Remove the token_binding_version field from the = token_binding extension; >=20 > 2. Work with the TLS WG to set aside a range of TLS extension = code points from which random assignments of still-free code points can = be picked by the TB WG; >=20 > 3. Pick a random TLS extension code point from this range for = each TB draft that breaks compatibility; >=20 > 4. A TLS client can advertise multiple of these TLS extension = IDs in the same ClientHello, the server has to pick no more than one; >=20 > 5. IANA will eventually register one of these code points for = use with the finalized TB 1.0. >=20 > Pros: > - The client advertises all supported TB versions, so the = server knows whether TB is negotiated after processing the ClientHello. > - Some WG participants believe that this mechanism of TB = version negotiation is less likely to become unusable due to broken = implementations. > =20 > Cons: > - Requires TLS WG to approve a range of TLS extension code = points; > - Uses a lot more bytes in the ClientHello, when multiple TB = versions are advertised (because TB key parameters are duplicated in = each extension). > - TB implementation upgrade requires TLS stack upgrade or = =E2=80=9Cgeneric TLS extension=E2=80=9D support in the TLS stack (not = generally available at the moment). > =20 > Cheers, > =20 > Andrei > =20 > =20 > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Wednesday, August 24, 2016 6:03 PM > To: Andrei Popov > Cc: Brian Campbell ; Bill Cox = ; Nick Harper ; = unbearable@ietf.org; Martin Thomson ; Stephen = Farrell ; Leif Johansson > Subject: RE: [Unbearable] TLS extension: version field > =20 > First we need to determine if there is consensus for a change.=20 >=20 > Andrei can you sunrise the current state and options to the list. =20 >=20 > Thanks.=20 >=20 > John B.=20 >=20 > =20 > On Aug 24, 2016 21:47, "Andrei Popov" > wrote: > >> Picking a random unassigned extension ID seems a bit smelly if > >> there's no range set aside for from which one can pick, which > >> I think is the case for [1]. > Yes, this is one of the concerns with the proposed scheme. And one of = the reasons I would rather keep the current TB version negotiation = mechanism. >=20 > > Either way, getting that agreed on the TLS list would be a good = plan. > What do the Chairs think: should the proponents start the discussion = on the TLS WG list, or should we gauge consensus in the TB WG first? >=20 > Cheers, >=20 > Andrei >=20 > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie = ] > Sent: Wednesday, August 24, 2016 1:46 PM > To: John Bradley > > Cc: Andrei Popov >; unbearable@ietf.org = ; Bill Cox >; Brian Campbell = >; Martin = Thomson >; = Nick Harper > > Subject: Re: [Unbearable] TLS extension: version field >=20 >=20 >=20 > On 24/08/16 21:38, John Bradley wrote: > > For preproduction or experimental version is using the experimental = space make sense and then use 24 for the RFC version? > > >=20 > There's no experimental range set aside in that registry that > I can see. And folks have had issues with such, when it turns > out that a codepoint from the experimental range has "escaped" > into the wild to such an extent that nobody else could use it > to do experiments. >=20 > What I thought was being proposed here was a little different, > being to set aside a range from which random assignments of > still-free codepoints can be picked by this WG (or maybe this > or others) and where the randomly assigned codepoint might > turn into one that's permanently assigned later. >=20 > So one could propose either setting aside an experimental > range, or doing something new as in the paragraph above I > guess. Either way, getting that agreed on the TLS list would > be a good plan. >=20 > Cheers > S. >=20 > > We need something to use for interop testing. > > > > John B? > >> On Aug 24, 2016, at 5:29 PM, Stephen Farrell = > wrote: > >> > >> > >> Hi all, > >> > >> On 24/08/16 20:06, Andrei Popov wrote: > >>> 2. Pick a random unassigned TLS extension ID for each TB = draft that breaks compatibility; > >> > >> If this plan does garner consensus here, please verify it with the > >> TLS WG - those [1] are "their" codepoints after all. > >> > >> Picking a random unassigned extension ID seems a bit smelly if > >> there's no range set aside for from which one can pick, which > >> I think is the case for [1]. > >> > >> If folks want to take that approach then the right thing to do > >> would be to get such a range assigned. > >> > >> S. > >> > >> [1] > >> = https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontyp= e-values.xhtml#tls-extensiontype-values-1 = > >> > >> _______________________________________________ > >> Unbearable mailing list > >> Unbearable@ietf.org > >> https://www.ietf.org/mailman/listinfo/unbearable = > > > > _______________________________________________ > > Unbearable mailing list > > Unbearable@ietf.org > > https://www.ietf.org/mailman/listinfo/unbearable = > > >=20 --Apple-Mail=_BE1D3B7D-A900-4F03-8697-34764EA99D0A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 My personal preference is to stick with what we have now. =  

Needing to = mess with upgrading the TLS stack for token binding upgrades is going to = be a major deployment hurdle.
Looking what it will = take to get TB deployed in different environments and upgrades to the = TLS stacks makes me hesitant to think that is going to work very = often.
I suspect that we will find people lees = likely to update versions in that case.

What do others think?

John B.

On Aug 24, 2016, at 11:02 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

=C3=98  Andrei = can you sunrise the current state and options to the list.

Gladly.
 
What we have = now:
Currently, TBNEGO-03 states that the Token = Binding protocol version is negotiated via the token_binding TLS = extension (temporary IANA code point 24).
The client offers the highest supported TB protocol version, = and the server responds with the lower of the TB protocol version = offered by the client and the highest version supported by the = server.
 
Pros:
-          Tried and tested mechanism, currently used by the draft = implementations of TB.
-          Requires one TLS extension for all TB versions, until the = hypothetical moment in the future, when the TB protocol changes so much = that additional parameters need to be negotiated, other than protocol = version and TB key parameters.
-          Token Binding protocol implementation can be upgraded = independently of the TLS stack.
 
Cons:
-          When the server picks a TB protocol version lower than that = offered by the client, the server does not know whether TB is = negotiated, until the first application_data message is received.
-          Broken TB implementations might get TB version negotiation = wrong, which would result in the client and server failing to negotiate = TB.
 
Alternative proposal = for TB WG consideration:

1.         Remove the token_binding_version field from the token_binding = extension;

2.         Work with the TLS WG to set aside a range of TLS extension = code points from which random assignments of still-free code points can = be picked by the TB WG;

3.         Pick a random TLS extension code point from this range for = each TB draft that breaks compatibility;

4.         A = TLS client can advertise multiple of these TLS extension IDs in the same = ClientHello, the server has to pick no more than one;

5.         IANA will eventually register one of these code points for = use with the finalized TB 1.0.

Pros:
-          The client advertises all supported TB versions, so the = server knows whether TB is negotiated after processing the = ClientHello.
-          Some WG participants believe that this mechanism of TB = version negotiation is less likely to become unusable due to broken = implementations.
 
Cons:
-          Requires TLS WG to approve a range of TLS extension code = points;
-          Uses a lot more bytes in the ClientHello, when multiple TB = versions are advertised (because TB key parameters are duplicated in = each extension).
-          TB= implementation upgrade requires TLS stack upgrade or =E2=80=9Cgeneric = TLS extension=E2=80=9D support in the TLS stack (not generally available = at the moment).
 
Cheers,
 
Andrei
 
 
From: John = Bradley [mailto:ve7jtb@ve7jtb.com] 
Sent: Wednesday, August 24, 2016 = 6:03 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Brian= Campbell <bcampbell@pingidentity.com>; Bill Cox <waywardgeek@google.com>; Nick Harper <nharper@google.com>; = unbearable@ietf.org;= Martin Thomson <martin.thomson@gmail.com>; Stephen Farrell <stephen.farrell@cs.tcd.ie>; Leif Johansson <leifj@sunet.se>
Subject: RE: [Unbearable] TLS = extension: version field
 

First we need to = determine if there is consensus for a change. 

Andrei can you = sunrise the current state and options to the list.  

Thanks. 

John B. 

 
On Aug 24, 2016 21:47, "Andrei Popov" = <Andrei.Popov@microsoft.com> wrote:

>> = Picking a random unassigned extension ID seems a bit smelly if
>> there's no range set aside for from which one can = pick, which
>> I think is the case for [1].
Yes, this is one of the concerns with the proposed scheme. = And one of the reasons I would rather keep the current TB version = negotiation mechanism.

> Either way, = getting that agreed on the TLS list would be a good plan.
What do the Chairs think: should the proponents start the = discussion on the TLS WG list, or should we gauge consensus in the TB WG = first?

Cheers,

Andrei

-----Original = Message-----
From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
Sent: Wednesday, August 24, 2016 1:46 PM
To: = John Bradley <ve7jtb@ve7jtb.com>
Cc: Andrei Popov = <Andrei.Popov@microsoft.com>; unbearable@ietf.org; Bill = Cox <waywardgeek@google.com>; Brian Campbell <bcampbell@pingidentity.com>; Martin Thomson <martin.thomson@gmail.com>; = Nick Harper <nharper@google.com>
Subject: Re: = [Unbearable] TLS extension: version field


On 24/08/16 21:38, John Bradley wrote:
> For preproduction or experimental version is using the = experimental space make sense and then use 24 for the RFC version?
>

There's no experimental = range set aside in that registry that
I can see. And folks = have had issues with such, when it turns
out that a = codepoint from the experimental range has "escaped"
into = the wild to such an extent that nobody else could use it
to = do experiments.

What I thought was being = proposed here was a little different,
being to set aside a = range from which random assignments of
still-free = codepoints can be picked by this WG (or maybe this
or = others) and where the randomly assigned codepoint might
turn= into one that's permanently assigned later.

So one could propose either setting aside an experimental
range, or doing something new as in the paragraph above I
guess. Either way, getting that agreed on the TLS list = would
be a good plan.

CheersS.

> We need something to = use for interop testing.
>
> John = B?
>> On Aug 24, 2016, at 5:29 PM, Stephen Farrell = <stephen.farrell@cs.tcd.ie> = wrote:
>>
>>
>> Hi all,
>>
>> = On 24/08/16 20:06, Andrei Popov wrote:
>>> = 2.         Pick a random unassigned TLS = extension ID for each TB draft that breaks compatibility;
>>
>> If this plan does garner = consensus here, please verify it with the
>> TLS WG = - those [1] are "their" codepoints after all.
>>
>> Picking a random unassigned extension ID seems a bit = smelly if
>> there's no range set aside for from = which one can pick, which
>> I think is the case for = [1].
>>
>> If folks want to take = that approach then the right thing to do
>> would be = to get such a range assigned.
>>
>> S.
>>
>> = [1]
>> https://www.iana.org/assignments/tls-extensiontype-values/tls-e= xtensiontype-values.xhtml#tls-extensiontype-values-1
>>
>> = _______________________________________________
>> = Unbearable mailing list
>> Unbearable@ietf.org
>> https://www.ietf.org/mailman/listinfo/unbearable
>
> = _______________________________________________
> = Unbearable mailing list
> Unbearable@ietf.org
> https://www.ietf.org/mailman/listinfo/unbearable
>


= --Apple-Mail=_BE1D3B7D-A900-4F03-8697-34764EA99D0A-- From nobody Thu Aug 25 08:16:54 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 1414312D145 for ; Thu, 25 Aug 2016 08:16:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 sA_HdwU4k0Hf for ; Thu, 25 Aug 2016 08:16:51 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 747C012D142 for ; Thu, 25 Aug 2016 08:16:50 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id n59so89117553uan.2 for ; Thu, 25 Aug 2016 08:16:50 -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=uRPbi2dj3jtyYwnYqTkslf23eg3YkRd4doKBn1GlS9Y=; b=P7ErRHX+kT7h+9I5HVKIdSjukgNkKyiu+D6dgkY/xcfy0eelU5XjJGOYAf5bYd9Nal ohizkY2hWOxLWxCIUlMfTsqJC2cr0qUQB6M/6fYK2y2PjtkTDCvvYbn7GDtRLBpdBZS6 pJMW/GwK9yl/aruaUFAtSayeWN0MtjMD7lNgyHRCx9QPwb25KEhnpJ8aefT4wNsQEuuM m8zbpgSigV9JWYKdRJF0BTHPvqCfoyhCsNikKkh49ErKUd3aKWF3w4UKui1wXskDcDLu qCozhSO6n4Svm0mNDxsIOT6vLqQoxbZqZlS/mlU4SJaLaq8mbnd1LfCsRJDLNyKNYA9p h1nA== 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=uRPbi2dj3jtyYwnYqTkslf23eg3YkRd4doKBn1GlS9Y=; b=enjoU20XhELHoSoYChf22AKSNogQpW3IuDcA1/OL2sByTVKYvtW2BcLaAp2gYQcSvH Fcxb4vbbxSligoVoIcBmEtpO79d8I6noifxOSZy+0YiQjC3a3hrtETY8J3yq5Jj3HE5R pC+kQuujoPDPkM7Zk9l6kJmdlbtgikZLsYZLZb6ifhnx/MnbjJcukGkhTjqe7YMUvLj2 QOar2ffUuYuKTQGird0AMe78kFQwfkmmhaQZKqzBY0CYnJDfYf/5PH+z7r5lLllYv1o0 FWSUDfNGUKnjic7l/hVYq6l5oodYJ9B97DCNrYwKpnzdYiz+JqzDQAE+jYiToCEEwwUr IVig== X-Gm-Message-State: AE9vXwMCnzMExaIPl9F0cM7q/+ivYnG+9zoHMvJXI+xsZUgx1gUqS6qpGbKptdmcw8HNwG7usD9Z/MyZqMEQJAgl X-Received: by 10.176.3.41 with SMTP id 38mr695645uat.113.1472138209398; Thu, 25 Aug 2016 08:16:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.97.2 with HTTP; Thu, 25 Aug 2016 08:16:48 -0700 (PDT) In-Reply-To: <38F8CC64-29B7-4818-B423-F1C7A2939B4D@ve7jtb.com> References: <9b0f1cb3-a74b-2637-159c-e7aa3ee53ec6@cs.tcd.ie> <38F8CC64-29B7-4818-B423-F1C7A2939B4D@ve7jtb.com> From: Bill Cox Date: Thu, 25 Aug 2016 08:16:48 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a113d049a0854f1053ae6e301 Archived-At: Cc: Andrei Popov , "unbearable@ietf.org" , Brian Campbell , Martin Thomson , Leif Johansson , Nick Harper , Stephen Farrell Subject: Re: [Unbearable] TLS extension: version field 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, 25 Aug 2016 15:16:53 -0000 --001a113d049a0854f1053ae6e301 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 25, 2016 at 5:52 AM, John Bradley wrote: > > What do others think? > > John B. > I agree. I think this is the sort of thing we can fix in a new extension in the future, a "token binding 2.0" extension. I think the CONs are over-stated, since sending the version field in 1.0 in no way restricts what we do next. Here is a simple question I need answered: Should Google turn on token binding globally with the current version, or hold off until the 1.0 version? We've been assuming we want to go global now. Are we wrong? I have token binding running on several dozen front-end machines, processing a few million TB headers per day with solid reliability. All I have to do is change 2 lines in a config file to turn token binding on globally. Nick has to do something similar, plus some extensive process for launching new Chrome features, and we'll have Chrome speaking TB from Chrome to Google nearly everywhere. If we make a binary incompatible change like dropping the version field, we'll have to start the whole launch process over again. Each time loses at least a month, typically more like 2. My preference is for for this WG to agree that we hope to maintain binary compatibility with the -08 version, so that I can turn on token binding globally now. I would prefer to put upgrades like this on a list of "nice to have" features. Unless the list as a whole becomes compelling enough to break compatibility with the -08 version, I think we should launch 1.0 in a -08 compatible way. BTW, this is not a minor change. As a custom extension, I'll have to have multiple callbacks in the client hello append successful version numbers negotiated to a vector, and in the callbacks for the server hello, I'll have to pick the best negotiated version and block all the rest, probably using a single callback used for each version that disables itself after being called once. Then, I'll have to write tests for all the possible combinations of versions that could be processed (Google takes testing pretty seriously in the front-end group). It is not rocket science, but given the review process here, and how we like core changes to bake for a while, it will be a few weeks before I can get this change onto live front-end machines. Bill --001a113d049a0854f1053ae6e301 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 25, 2016 at 5:52 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:

What do others think?

John= B.

I agree.=C2=A0 I think this= is the sort of thing we can fix in a new extension in the future, a "= token binding 2.0" extension.=C2=A0 I think the CONs are over-stated, = since sending the version field in 1.0 in no way restricts what we do next.=

Here is a simple question I need answered: Should= Google turn on token binding globally with the current version, or hold of= f until the 1.0 version?=C2=A0 We've been assuming we want to go global= now.=C2=A0 Are we wrong?

I have token binding run= ning on several dozen front-end machines, processing a few million TB heade= rs per day with solid reliability.=C2=A0 All I have to do is change 2 lines= in a config file to turn token binding on globally.=C2=A0 Nick has to do s= omething similar, plus some extensive process for launching new Chrome feat= ures, and we'll have Chrome speaking TB from Chrome to Google nearly ev= erywhere.=C2=A0 If we make a binary incompatible change like dropping the v= ersion field, we'll have to start the whole launch process over again.= =C2=A0 Each time loses at least a month, typically more like 2.
<= br>
My preference is for for this WG to agree that we hope to mai= ntain binary compatibility with the -08 version, so that I can turn on toke= n binding globally now.

I would prefer to put upgr= ades like this on a list of "nice to have" features.=C2=A0 Unless= the list as a whole becomes compelling enough to break compatibility with = the -08 version, I think we should launch 1.0 in a -08 compatible way.

BTW, this is not a minor change.=C2=A0 As a custom ext= ension, I'll have to have multiple callbacks in the client hello append= successful version numbers negotiated to a vector, and in the callbacks fo= r the server hello, I'll have to pick the best negotiated version and b= lock all the rest, probably using a single callback used for each version t= hat disables itself after being called once.=C2=A0 Then, I'll have to w= rite tests for all the possible combinations of versions that could be proc= essed (Google takes testing pretty seriously in the front-end group).=C2=A0= It is not rocket science, but given the review process here, and how we li= ke core changes to bake for a while, it will be a few weeks before I can ge= t this change onto live front-end machines.

Bill
--001a113d049a0854f1053ae6e301-- From nobody Thu Aug 25 10:07: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 7546112D18D for ; Thu, 25 Aug 2016 10:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 IyVPTuBdhXUI for ; Thu, 25 Aug 2016 10:07:43 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0131.outbound.protection.outlook.com [104.47.37.131]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0995F12B03A for ; Thu, 25 Aug 2016 10:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=77ezmzeZ2zU8nBA/WMj0LjM4NU5YBOhhtukpPfCfTFM=; b=a6+ufyWcGz0BlcTg7C9GaXpnUqsqczB4KuAa/uOhnzKJiVgG5vXobWCtFG7BHGigSxPZFrzZ41hkCyU2E0iPdKRV7CPIj7ulbbf6Y0Miw9RJlL8VgEXPnds6MvrbVz1bSZiwtqf7vv0N+OBwx3tHZoz12arlg6GYl2CqMZmjAzE= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0843.namprd03.prod.outlook.com (10.160.163.149) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Thu, 25 Aug 2016 17:07:40 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Thu, 25 Aug 2016 17:07:40 +0000 From: Andrei Popov To: Bill Cox , John Bradley Thread-Topic: [Unbearable] TLS extension: version field Thread-Index: AQHR8UE0hAr3fGh5LkSos3djbwbcUaA/MmwAgAAmOoCAAAGk8IAAhvMAgAAFqjCAAAO6AIAA6WmAgAATAoCAABJZgIAV3xfwgAATKACAAFvQgIAAAlRwgAANXQCAAAcGgIAAQVIAgADRnQCAAADEgIAAEkUAgAAEGBCAAAamgIAAAViQgAAZvwCAAAJnAIAAAhEAgAA/qZCAAAhXAIAABsHQgAC/X4CAAChTAIAAHF0w Date: Thu, 25 Aug 2016 17:07:40 +0000 Message-ID: References: <9b0f1cb3-a74b-2637-159c-e7aa3ee53ec6@cs.tcd.ie> <38F8CC64-29B7-4818-B423-F1C7A2939B4D@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: 6e60a079-80c7-40c0-cabe-08d3cd0a5273 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0843; 6:iomXRmoZSorbQqI42CigcxCnH3vAI7XVRS0LKFBJ65k1Bg7qJE282t22A4CUNXR2nu8BwVOd/95lRNxyeitvsy2/kCSwBpsZZ1wh47yizJGMQlMQcEi4oqnBdtW6jOzZaowY29lN2SIQgDKK4HFducer5CWQrJMQQi307GarDr2vxr9pU0/8OoI3Q2HWZhlMoZZrbfWU4dTYiF1QRB0sOtLiH33R+PAgXmowaXUC03dDwaxROGbIpCH6nNIOTfcK4a6o2pmLIPQQzifkUTR2L4SHQxRRQlcBVVPXsBqait5yHh9LQz52ZEv/xpRrM/tttNRGBsVjJeMxctpZCKSS4Q==; 5:Q+QpWmTi3S1yz4vV1rUyaR/kc07Gi4mWoOSYYSyKetT1YgkWVygJZt/UdwvlNDp4SIEShxTH/2y1pvDMW9IzpKQqvRE4N9l9q006HvNQjFkVX+pDdoS42bkVYHIphr8NunznvJZJtXI83UG3iIf/OA==; 24:Cy+40aHmo2rEhocAfHz6YFwRDEYW1/0sKpCmrA7zVFUs2AYEvqMKPl6HIsiEaP86Pt5uLOSHGsSO42rxTJlwW7DJvTba9/x8I69tN4r3iZY=; 7:8ul2wynRt4ak3EvjHaSA3QvioZbzliG1CLRr1XkNCDWrQtoxWno23B0BHbg7O2AGrgVzPIIVn3Hlb3I0QP28jVGnnP84+fMkZjuMvg47LzRzEDrLC7KITpJPAg7RBN3E7hBbSm8q4tJK/M+J3EabVgGwaUKl9bp9lkSpXt7dQIXUTqGSK7WLP8DjLLPemZWEjMKwXcBj3Nb82zeWGzNeyXalhMXXDCzzvoo+on1/yE6J50MsbellZKkBHd3Sm55J x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0843; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(158342451672863)(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0843; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0843; x-forefront-prvs: 0045236D47 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(199003)(189002)(24454002)(122556002)(19609705001)(106356001)(77096005)(8936002)(81166006)(15975445007)(10090500001)(92566002)(5660300001)(7846002)(81156014)(2950100001)(7736002)(11100500001)(7696003)(2900100001)(8676002)(9686002)(5002640100001)(10290500002)(19580405001)(8990500004)(4326007)(5001770100001)(189998001)(74316002)(5005710100001)(2906002)(97736004)(19300405004)(10400500002)(86362001)(99286002)(93886004)(6116002)(790700001)(102836003)(106116001)(16236675004)(33656002)(54356999)(76576001)(50986999)(76176999)(19580395003)(105586002)(68736007)(3280700002)(586003)(86612001)(101416001)(3660700001)(19625215002)(87936001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0843; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB084204094E5DAFEB80C341AB8CED0CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2016 17:07:40.2916 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0843 Archived-At: Cc: "unbearable@ietf.org" , Brian Campbell , Martin Thomson , Leif Johansson , Nick Harper , Stephen Farrell Subject: Re: [Unbearable] TLS extension: version field 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, 25 Aug 2016 17:07:45 -0000 --_000_CY1PR0301MB084204094E5DAFEB80C341AB8CED0CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXTigJlzIHByb2JhYmx5IHJlZHVuZGFudCBvZiBtZSB0byBzYXkgdGhpcyBhZ2FpbuKYuiwgYnV0 IEkgd291bGQgcmF0aGVyIGtlZXAgdGhlIGN1cnJlbnQgbmVnb3RpYXRpb24gbWVjaGFuaXNtLCB3 aXRoIHRoZSB2ZXJzaW9uIGZpZWxkLCBlc3BlY2lhbGx5IGF0IHRoaXMgcG9pbnQgaW4gdGhlIHN0 YW5kYXJkcyBwcm9jZXNzLg0KDQpJbiB0aGUgZnV0dXJlLCBpZiB3ZSBzZWUgdGhhdCB0aGUgdmVy c2lvbiBmaWVsZCBpbiB0aGUgdG9rZW5fYmluZGluZyBleHRlbnNpb24gaXMgcmVhbGx5IGNhdXNp bmcgcHJvYmxlbXMgd2l0aCB0aGUgZGVwbG95bWVudCBvZiBhIG5ldyBUQiBwcm90b2NvbCB2ZXJz aW9uLCB3ZSBjYW4gZGVzaWduIGEgbmV3IFRMUyBleHRlbnNpb24uDQoNClRoaXMgd2F5LCB3ZSB3 b3VsZCBvbmx5IGJlIGFwcGx5aW5nIHRoZSB3b3JrYXJvdW5kIHdoZW4gd2UgYWN0dWFsbHkgaGF2 ZSB0byBkbyBzby4NCg0KDQrDmCAgSGVyZSBpcyBhIHNpbXBsZSBxdWVzdGlvbiBJIG5lZWQgYW5z d2VyZWQ6IFNob3VsZCBHb29nbGUgdHVybiBvbiB0b2tlbiBiaW5kaW5nIGdsb2JhbGx5IHdpdGgg dGhlIGN1cnJlbnQgdmVyc2lvbiwgb3IgaG9sZCBvZmYgdW50aWwgdGhlIDEuMCB2ZXJzaW9uPw0K TVMgaGFzIHRoZSBzYW1lIGlzc3VlOiB3ZeKAmXZlIGJlZW4gcGxhbm5pbmcgdG8gdXBkYXRlIG91 ciBUQiBpbXBsZW1lbnRhdGlvbiAod2hpY2ggaXMgY3VycmVudGx5IGJhc2VkIG9uIHRoZSBlYXJs aWVzdCBUQiBkcmFmdHMpLCBidXQgYSBuZXcgbmVnb3RpYXRpb24gbWVjaGFuaXNtIHdvdWxkIHB1 dCB0aGVzZSBwbGFucyBhdCByaXNrLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBCaWxs IENveCBbbWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb21dDQpTZW50OiBUaHVyc2RheSwgQXVn dXN0IDI1LCAyMDE2IDg6MTcgQU0NClRvOiBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29t Pg0KQ2M6IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+OyBCcmlhbiBD YW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+OyBOaWNrIEhhcnBlciA8bmhhcnBl ckBnb29nbGUuY29tPjsgdW5iZWFyYWJsZUBpZXRmLm9yZzsgTWFydGluIFRob21zb24gPG1hcnRp bi50aG9tc29uQGdtYWlsLmNvbT47IFN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNz LnRjZC5pZT47IExlaWYgSm9oYW5zc29uIDxsZWlmakBzdW5ldC5zZT4NClN1YmplY3Q6IFJlOiBb VW5iZWFyYWJsZV0gVExTIGV4dGVuc2lvbjogdmVyc2lvbiBmaWVsZA0KDQpPbiBUaHUsIEF1ZyAy NSwgMjAxNiBhdCA1OjUyIEFNLCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0 bzp2ZTdqdGJAdmU3anRiLmNvbT4+IHdyb3RlOg0KDQpXaGF0IGRvIG90aGVycyB0aGluaz8NCg0K Sm9obiBCLg0KDQpJIGFncmVlLiAgSSB0aGluayB0aGlzIGlzIHRoZSBzb3J0IG9mIHRoaW5nIHdl IGNhbiBmaXggaW4gYSBuZXcgZXh0ZW5zaW9uIGluIHRoZSBmdXR1cmUsIGEgInRva2VuIGJpbmRp bmcgMi4wIiBleHRlbnNpb24uICBJIHRoaW5rIHRoZSBDT05zIGFyZSBvdmVyLXN0YXRlZCwgc2lu Y2Ugc2VuZGluZyB0aGUgdmVyc2lvbiBmaWVsZCBpbiAxLjAgaW4gbm8gd2F5IHJlc3RyaWN0cyB3 aGF0IHdlIGRvIG5leHQuDQoNCkhlcmUgaXMgYSBzaW1wbGUgcXVlc3Rpb24gSSBuZWVkIGFuc3dl cmVkOiBTaG91bGQgR29vZ2xlIHR1cm4gb24gdG9rZW4gYmluZGluZyBnbG9iYWxseSB3aXRoIHRo ZSBjdXJyZW50IHZlcnNpb24sIG9yIGhvbGQgb2ZmIHVudGlsIHRoZSAxLjAgdmVyc2lvbj8gIFdl J3ZlIGJlZW4gYXNzdW1pbmcgd2Ugd2FudCB0byBnbyBnbG9iYWwgbm93LiAgQXJlIHdlIHdyb25n Pw0KDQpJIGhhdmUgdG9rZW4gYmluZGluZyBydW5uaW5nIG9uIHNldmVyYWwgZG96ZW4gZnJvbnQt ZW5kIG1hY2hpbmVzLCBwcm9jZXNzaW5nIGEgZmV3IG1pbGxpb24gVEIgaGVhZGVycyBwZXIgZGF5 IHdpdGggc29saWQgcmVsaWFiaWxpdHkuICBBbGwgSSBoYXZlIHRvIGRvIGlzIGNoYW5nZSAyIGxp bmVzIGluIGEgY29uZmlnIGZpbGUgdG8gdHVybiB0b2tlbiBiaW5kaW5nIG9uIGdsb2JhbGx5LiAg TmljayBoYXMgdG8gZG8gc29tZXRoaW5nIHNpbWlsYXIsIHBsdXMgc29tZSBleHRlbnNpdmUgcHJv Y2VzcyBmb3IgbGF1bmNoaW5nIG5ldyBDaHJvbWUgZmVhdHVyZXMsIGFuZCB3ZSdsbCBoYXZlIENo cm9tZSBzcGVha2luZyBUQiBmcm9tIENocm9tZSB0byBHb29nbGUgbmVhcmx5IGV2ZXJ5d2hlcmUu ICBJZiB3ZSBtYWtlIGEgYmluYXJ5IGluY29tcGF0aWJsZSBjaGFuZ2UgbGlrZSBkcm9wcGluZyB0 aGUgdmVyc2lvbiBmaWVsZCwgd2UnbGwgaGF2ZSB0byBzdGFydCB0aGUgd2hvbGUgbGF1bmNoIHBy b2Nlc3Mgb3ZlciBhZ2Fpbi4gIEVhY2ggdGltZSBsb3NlcyBhdCBsZWFzdCBhIG1vbnRoLCB0eXBp Y2FsbHkgbW9yZSBsaWtlIDIuDQoNCk15IHByZWZlcmVuY2UgaXMgZm9yIGZvciB0aGlzIFdHIHRv IGFncmVlIHRoYXQgd2UgaG9wZSB0byBtYWludGFpbiBiaW5hcnkgY29tcGF0aWJpbGl0eSB3aXRo IHRoZSAtMDggdmVyc2lvbiwgc28gdGhhdCBJIGNhbiB0dXJuIG9uIHRva2VuIGJpbmRpbmcgZ2xv YmFsbHkgbm93Lg0KDQpJIHdvdWxkIHByZWZlciB0byBwdXQgdXBncmFkZXMgbGlrZSB0aGlzIG9u IGEgbGlzdCBvZiAibmljZSB0byBoYXZlIiBmZWF0dXJlcy4gIFVubGVzcyB0aGUgbGlzdCBhcyBh IHdob2xlIGJlY29tZXMgY29tcGVsbGluZyBlbm91Z2ggdG8gYnJlYWsgY29tcGF0aWJpbGl0eSB3 aXRoIHRoZSAtMDggdmVyc2lvbiwgSSB0aGluayB3ZSBzaG91bGQgbGF1bmNoIDEuMCBpbiBhIC0w OCBjb21wYXRpYmxlIHdheS4NCg0KQlRXLCB0aGlzIGlzIG5vdCBhIG1pbm9yIGNoYW5nZS4gIEFz IGEgY3VzdG9tIGV4dGVuc2lvbiwgSSdsbCBoYXZlIHRvIGhhdmUgbXVsdGlwbGUgY2FsbGJhY2tz IGluIHRoZSBjbGllbnQgaGVsbG8gYXBwZW5kIHN1Y2Nlc3NmdWwgdmVyc2lvbiBudW1iZXJzIG5l Z290aWF0ZWQgdG8gYSB2ZWN0b3IsIGFuZCBpbiB0aGUgY2FsbGJhY2tzIGZvciB0aGUgc2VydmVy IGhlbGxvLCBJJ2xsIGhhdmUgdG8gcGljayB0aGUgYmVzdCBuZWdvdGlhdGVkIHZlcnNpb24gYW5k IGJsb2NrIGFsbCB0aGUgcmVzdCwgcHJvYmFibHkgdXNpbmcgYSBzaW5nbGUgY2FsbGJhY2sgdXNl ZCBmb3IgZWFjaCB2ZXJzaW9uIHRoYXQgZGlzYWJsZXMgaXRzZWxmIGFmdGVyIGJlaW5nIGNhbGxl ZCBvbmNlLiAgVGhlbiwgSSdsbCBoYXZlIHRvIHdyaXRlIHRlc3RzIGZvciBhbGwgdGhlIHBvc3Np YmxlIGNvbWJpbmF0aW9ucyBvZiB2ZXJzaW9ucyB0aGF0IGNvdWxkIGJlIHByb2Nlc3NlZCAoR29v Z2xlIHRha2VzIHRlc3RpbmcgcHJldHR5IHNlcmlvdXNseSBpbiB0aGUgZnJvbnQtZW5kIGdyb3Vw KS4gIEl0IGlzIG5vdCByb2NrZXQgc2NpZW5jZSwgYnV0IGdpdmVuIHRoZSByZXZpZXcgcHJvY2Vz cyBoZXJlLCBhbmQgaG93IHdlIGxpa2UgY29yZSBjaGFuZ2VzIHRvIGJha2UgZm9yIGEgd2hpbGUs IGl0IHdpbGwgYmUgYSBmZXcgd2Vla3MgYmVmb3JlIEkgY2FuIGdldCB0aGlzIGNoYW5nZSBvbnRv IGxpdmUgZnJvbnQtZW5kIG1hY2hpbmVzLg0KDQpCaWxsDQo= --_000_CY1PR0301MB084204094E5DAFEB80C341AB8CED0CY1PR0301MB0842_ 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 bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3Qg RGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjgyNDU5MzQzNTsNCgltc28t bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NjMyODUxNTUyIC0xMDA1 OTU3NTM2IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3Rh cnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+SXTigJlzIHByb2JhYmx5IHJlZHVuZGFudCBvZiBtZSB0byBzYXkgdGhp cyBhZ2Fpbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpX aW5nZGluZ3MiPko8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4sDQogYnV0IEkgd291bGQgcmF0aGVy IGtlZXAgdGhlIGN1cnJlbnQgbmVnb3RpYXRpb24gbWVjaGFuaXNtLCB3aXRoIHRoZSB2ZXJzaW9u IGZpZWxkLCBlc3BlY2lhbGx5IGF0IHRoaXMgcG9pbnQgaW4gdGhlIHN0YW5kYXJkcyBwcm9jZXNz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5JbiB0aGUgZnV0dXJlLCBpZiB3ZSBzZWUgdGhhdCB0aGUgdmVyc2lv biBmaWVsZCBpbiB0aGUgdG9rZW5fYmluZGluZyBleHRlbnNpb24gaXMgcmVhbGx5IGNhdXNpbmcg cHJvYmxlbXMgd2l0aCB0aGUgZGVwbG95bWVudCBvZiBhIG5ldyBUQiBwcm90b2NvbCB2ZXJzaW9u LCB3ZSBjYW4gZGVzaWduIGENCiBuZXcgVExTIGV4dGVuc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhp cyB3YXksIHdlIHdvdWxkIG9ubHkgYmUgYXBwbHlpbmcgdGhlIHdvcmthcm91bmQgd2hlbiB3ZSBh Y3R1YWxseSBoYXZlIHRvIGRvIHNvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkhlcmUgaXMg YSBzaW1wbGUgcXVlc3Rpb24gSSBuZWVkIGFuc3dlcmVkOiBTaG91bGQgR29vZ2xlIHR1cm4gb24g dG9rZW4gYmluZGluZyBnbG9iYWxseSB3aXRoIHRoZSBjdXJyZW50IHZlcnNpb24sIG9yIGhvbGQg b2ZmIHVudGlsIHRoZSAxLjAgdmVyc2lvbj8mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+TVMg aGFzIHRoZSBzYW1lIGlzc3VlOiB3ZeKAmXZlIGJlZW4gcGxhbm5pbmcgdG8gdXBkYXRlIG91ciBU QiBpbXBsZW1lbnRhdGlvbiAod2hpY2ggaXMgY3VycmVudGx5IGJhc2VkIG9uIHRoZSBlYXJsaWVz dCBUQiBkcmFmdHMpLCBidXQgYSBuZXcgbmVnb3RpYXRpb24gbWVjaGFuaXNtIHdvdWxkIHB1dCB0 aGVzZQ0KIHBsYW5zIGF0IHJpc2suPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNoZWVycyw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+QW5kcmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBCaWxsIENveCBbbWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAyNSwgMjAxNiA4OjE3IEFNPGJyPg0KPGI+VG86PC9i PiBKb2huIEJyYWRsZXkgJmx0O3ZlN2p0YkB2ZTdqdGIuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4g QW5kcmVpIFBvcG92ICZsdDtBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSZndDs7IEJyaWFuIENh bXBiZWxsICZsdDtiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSZndDs7IE5pY2sgSGFycGVyICZs dDtuaGFycGVyQGdvb2dsZS5jb20mZ3Q7OyB1bmJlYXJhYmxlQGlldGYub3JnOyBNYXJ0aW4gVGhv bXNvbiAmbHQ7bWFydGluLnRob21zb25AZ21haWwuY29tJmd0OzsgU3RlcGhlbiBGYXJyZWxsICZs dDtzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllJmd0OzsgTGVpZiBKb2hhbnNzb24NCiAmbHQ7bGVp ZmpAc3VuZXQuc2UmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gVExT IGV4dGVuc2lvbjogdmVyc2lvbiBmaWVsZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBBdWcgMjUsIDIwMTYgYXQgNTo1MiBBTSwgSm9o biBCcmFkbGV5ICZsdDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0i X2JsYW5rIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IGRv IG90aGVycyB0aGluaz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Sm9obiBCLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUuJm5ic3A7IEkg dGhpbmsgdGhpcyBpcyB0aGUgc29ydCBvZiB0aGluZyB3ZSBjYW4gZml4IGluIGEgbmV3IGV4dGVu c2lvbiBpbiB0aGUgZnV0dXJlLCBhICZxdW90O3Rva2VuIGJpbmRpbmcgMi4wJnF1b3Q7IGV4dGVu c2lvbi4mbmJzcDsgSSB0aGluayB0aGUgQ09OcyBhcmUgb3Zlci1zdGF0ZWQsIHNpbmNlIHNlbmRp bmcgdGhlIHZlcnNpb24gZmllbGQgaW4gMS4wIGluIG5vIHdheSByZXN0cmljdHMgd2hhdCB3ZSBk byBuZXh0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IZXJlIGlzIGEgc2ltcGxlIHF1ZXN0aW9uIEkgbmVlZCBhbnN3ZXJlZDogU2hvdWxkIEdv b2dsZSB0dXJuIG9uIHRva2VuIGJpbmRpbmcgZ2xvYmFsbHkgd2l0aCB0aGUgY3VycmVudCB2ZXJz aW9uLCBvciBob2xkIG9mZiB1bnRpbCB0aGUgMS4wIHZlcnNpb24/Jm5ic3A7IFdlJ3ZlIGJlZW4g YXNzdW1pbmcgd2Ugd2FudCB0byBnbyBnbG9iYWwgbm93LiZuYnNwOyBBcmUgd2Ugd3Jvbmc/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2 ZSB0b2tlbiBiaW5kaW5nIHJ1bm5pbmcgb24gc2V2ZXJhbCBkb3plbiBmcm9udC1lbmQgbWFjaGlu ZXMsIHByb2Nlc3NpbmcgYSBmZXcgbWlsbGlvbiBUQiBoZWFkZXJzIHBlciBkYXkgd2l0aCBzb2xp ZCByZWxpYWJpbGl0eS4mbmJzcDsgQWxsIEkgaGF2ZSB0byBkbyBpcyBjaGFuZ2UgMiBsaW5lcyBp biBhIGNvbmZpZyBmaWxlIHRvIHR1cm4gdG9rZW4gYmluZGluZyBvbiBnbG9iYWxseS4mbmJzcDsg TmljayBoYXMgdG8gZG8NCiBzb21ldGhpbmcgc2ltaWxhciwgcGx1cyBzb21lIGV4dGVuc2l2ZSBw cm9jZXNzIGZvciBsYXVuY2hpbmcgbmV3IENocm9tZSBmZWF0dXJlcywgYW5kIHdlJ2xsIGhhdmUg Q2hyb21lIHNwZWFraW5nIFRCIGZyb20gQ2hyb21lIHRvIEdvb2dsZSBuZWFybHkgZXZlcnl3aGVy ZS4mbmJzcDsgSWYgd2UgbWFrZSBhIGJpbmFyeSBpbmNvbXBhdGlibGUgY2hhbmdlIGxpa2UgZHJv cHBpbmcgdGhlIHZlcnNpb24gZmllbGQsIHdlJ2xsIGhhdmUgdG8gc3RhcnQgdGhlIHdob2xlDQog bGF1bmNoIHByb2Nlc3Mgb3ZlciBhZ2Fpbi4mbmJzcDsgRWFjaCB0aW1lIGxvc2VzIGF0IGxlYXN0 IGEgbW9udGgsIHR5cGljYWxseSBtb3JlIGxpa2UgMi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgcHJlZmVyZW5jZSBpcyBmb3IgZm9yIHRo aXMgV0cgdG8gYWdyZWUgdGhhdCB3ZSBob3BlIHRvIG1haW50YWluIGJpbmFyeSBjb21wYXRpYmls aXR5IHdpdGggdGhlIC0wOCB2ZXJzaW9uLCBzbyB0aGF0IEkgY2FuIHR1cm4gb24gdG9rZW4gYmlu ZGluZyBnbG9iYWxseSBub3cuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgd291bGQgcHJlZmVyIHRvIHB1dCB1cGdyYWRlcyBsaWtlIHRoaXMg b24gYSBsaXN0IG9mICZxdW90O25pY2UgdG8gaGF2ZSZxdW90OyBmZWF0dXJlcy4mbmJzcDsgVW5s ZXNzIHRoZSBsaXN0IGFzIGEgd2hvbGUgYmVjb21lcyBjb21wZWxsaW5nIGVub3VnaCB0byBicmVh ayBjb21wYXRpYmlsaXR5IHdpdGggdGhlIC0wOCB2ZXJzaW9uLCBJIHRoaW5rIHdlIHNob3VsZCBs YXVuY2ggMS4wIGluIGEgLTA4IGNvbXBhdGlibGUgd2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CVFcsIHRoaXMgaXMgbm90IGEgbWlub3Ig Y2hhbmdlLiZuYnNwOyBBcyBhIGN1c3RvbSBleHRlbnNpb24sIEknbGwgaGF2ZSB0byBoYXZlIG11 bHRpcGxlIGNhbGxiYWNrcyBpbiB0aGUgY2xpZW50IGhlbGxvIGFwcGVuZCBzdWNjZXNzZnVsIHZl cnNpb24gbnVtYmVycyBuZWdvdGlhdGVkIHRvIGEgdmVjdG9yLCBhbmQgaW4gdGhlIGNhbGxiYWNr cyBmb3IgdGhlIHNlcnZlciBoZWxsbywgSSdsbCBoYXZlIHRvIHBpY2sgdGhlDQogYmVzdCBuZWdv dGlhdGVkIHZlcnNpb24gYW5kIGJsb2NrIGFsbCB0aGUgcmVzdCwgcHJvYmFibHkgdXNpbmcgYSBz aW5nbGUgY2FsbGJhY2sgdXNlZCBmb3IgZWFjaCB2ZXJzaW9uIHRoYXQgZGlzYWJsZXMgaXRzZWxm IGFmdGVyIGJlaW5nIGNhbGxlZCBvbmNlLiZuYnNwOyBUaGVuLCBJJ2xsIGhhdmUgdG8gd3JpdGUg dGVzdHMgZm9yIGFsbCB0aGUgcG9zc2libGUgY29tYmluYXRpb25zIG9mIHZlcnNpb25zIHRoYXQg Y291bGQgYmUgcHJvY2Vzc2VkIChHb29nbGUNCiB0YWtlcyB0ZXN0aW5nIHByZXR0eSBzZXJpb3Vz bHkgaW4gdGhlIGZyb250LWVuZCBncm91cCkuJm5ic3A7IEl0IGlzIG5vdCByb2NrZXQgc2NpZW5j ZSwgYnV0IGdpdmVuIHRoZSByZXZpZXcgcHJvY2VzcyBoZXJlLCBhbmQgaG93IHdlIGxpa2UgY29y ZSBjaGFuZ2VzIHRvIGJha2UgZm9yIGEgd2hpbGUsIGl0IHdpbGwgYmUgYSBmZXcgd2Vla3MgYmVm b3JlIEkgY2FuIGdldCB0aGlzIGNoYW5nZSBvbnRvIGxpdmUgZnJvbnQtZW5kIG1hY2hpbmVzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CaWxs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR0301MB084204094E5DAFEB80C341AB8CED0CY1PR0301MB0842_-- From nobody Thu Aug 25 10:21: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 78998127735 for ; Thu, 25 Aug 2016 10:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 8pBqQu-iVEaQ for ; Thu, 25 Aug 2016 10:21:25 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 9D91C12B03A for ; Thu, 25 Aug 2016 10:21:25 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id l94so32526251ual.0 for ; Thu, 25 Aug 2016 10:21:25 -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=jLVR8k9kmqVfhdJALta2nGoOB1rG/h/u3A9wyM7R6Z0=; b=WQNBEcDJPSzue/VUJT8gVTQ2RGflT/RubIuao89NTc/KOlOYifteS4+tTC4wKWTVZF Qn/FbZdZLB1B5eNtZQV0ef2KabvFgjPD9K30QEy4omrBPWlmfHxJsSWHGiaJVQBlWMsL DUbssnbGp4iASVzp43O54to7cQyRbZnlA9544GD+FJdoG6bPoENlPTwzs0zQVcwj7V5o x9NrjxeP4s8SaWXMcZdxIh7UQmy/xDKYi5IaPKSx8JOeDJX4HdDhXuYjVclAJnk3IQsZ 6vN7RSLo+/p1MC3IbwXVr/ApyVEaCpjptIicSknSfHkvcKpFDA/FJseLaAuiM95yk26C oUaw== 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=jLVR8k9kmqVfhdJALta2nGoOB1rG/h/u3A9wyM7R6Z0=; b=NIJgowiCfpv9ZR6Kz6o5zOIAP1bA0MO4eoBIGP5d350cbVuIayd+0cF7HO30wXExwm iie2OC0PJ0q3wbZMXoFwvDeZKbk0vvax3lanorRsD9TNZZl0PstWrECadZ8K+JIZkFz7 I6P6Dr75Yk7POi4Xl/59IDCHjwHvmL8uCLmUceU0AbRRqthcT6Y2TlDAS5eybk0zGoZ7 mzQFISFUT5lAauYpB8x3yteEARwiBxsAcqxQJIDp7iJdWooTAdEGrCwAtrINFh/o1DMb DRJ+VFsQVGVtrtZwz5jfilbDPpgyCA06TBFMFArm0ZEpaYEGVsZbzwhmXVHZVJbr3jVw 5pFQ== X-Gm-Message-State: AEkoousyDK13RJw38vqHCFvUwP3nXFa8K+imbPJpQbIEIqJMUNGPUpuCW6v9odfQSpcf8fjpwe2Zi+9tSjn/T7z9 X-Received: by 10.31.96.82 with SMTP id u79mr5508819vkb.88.1472145684419; Thu, 25 Aug 2016 10:21:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.209 with HTTP; Thu, 25 Aug 2016 10:21:03 -0700 (PDT) In-Reply-To: References: <9b0f1cb3-a74b-2637-159c-e7aa3ee53ec6@cs.tcd.ie> <38F8CC64-29B7-4818-B423-F1C7A2939B4D@ve7jtb.com> From: Nick Harper Date: Thu, 25 Aug 2016 10:21:03 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a114e62889413e0053ae8a0ee Archived-At: Cc: "unbearable@ietf.org" , Bill Cox , John Bradley , Brian Campbell , Martin Thomson , Leif Johansson , Stephen Farrell Subject: Re: [Unbearable] TLS extension: version field 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, 25 Aug 2016 17:21:27 -0000 --001a114e62889413e0053ae8a0ee Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My gut feeling is that when we need a new TB version, we'll also need to change the extension, hence my preference for not having the version in the extension. However, the version field appears to be too useful for experimentation to remove it. Given that we're bikeshedding over 2 bytes per connection, I'm fine keeping it as is and taking the view the the bytes are fixed at (1,0) once the RFC is published. (If we leave the version in, there's going to be an implementation that only expects (1,0) and will reject TB for any other version. When this happens with TLS, we begrudgingly add a(n insecure) fallback, but I haven't figured out how to do that in this case.) On Thu, Aug 25, 2016 at 10:07 AM, Andrei Popov wrote: > It=E2=80=99s probably redundant of me to say this againJ, but I would rat= her keep > the current negotiation mechanism, with the version field, especially at > this point in the standards process. > > > > In the future, if we see that the version field in the token_binding > extension is really causing problems with the deployment of a new TB > protocol version, we can design a new TLS extension. > > > > This way, we would only be applying the workaround when we actually have > to do so. > > > > =C3=98 Here is a simple question I need answered: Should Google turn on = token > binding globally with the current version, or hold off until the 1.0 > version? > > MS has the same issue: we=E2=80=99ve been planning to update our TB imple= mentation > (which is currently based on the earliest TB drafts), but a new negotiati= on > mechanism would put these plans at risk. > > > > Cheers, > > > > Andrei > > > > *From:* Bill Cox [mailto:waywardgeek@google.com] > *Sent:* Thursday, August 25, 2016 8:17 AM > *To:* John Bradley > *Cc:* Andrei Popov ; Brian Campbell < > bcampbell@pingidentity.com>; Nick Harper ; > unbearable@ietf.org; Martin Thomson ; Stephen > Farrell ; Leif Johansson > *Subject:* Re: [Unbearable] TLS extension: version field > > > > On Thu, Aug 25, 2016 at 5:52 AM, John Bradley wrote: > > > > What do others think? > > > > John B. > > > > I agree. I think this is the sort of thing we can fix in a new extension > in the future, a "token binding 2.0" extension. I think the CONs are > over-stated, since sending the version field in 1.0 in no way restricts > what we do next. > > > > Here is a simple question I need answered: Should Google turn on token > binding globally with the current version, or hold off until the 1.0 > version? We've been assuming we want to go global now. Are we wrong? > > > > I have token binding running on several dozen front-end machines, > processing a few million TB headers per day with solid reliability. All = I > have to do is change 2 lines in a config file to turn token binding on > globally. Nick has to do something similar, plus some extensive process > for launching new Chrome features, and we'll have Chrome speaking TB from > Chrome to Google nearly everywhere. If we make a binary incompatible > change like dropping the version field, we'll have to start the whole > launch process over again. Each time loses at least a month, typically > more like 2. > > > > My preference is for for this WG to agree that we hope to maintain binary > compatibility with the -08 version, so that I can turn on token binding > globally now. > > > > I would prefer to put upgrades like this on a list of "nice to have" > features. Unless the list as a whole becomes compelling enough to break > compatibility with the -08 version, I think we should launch 1.0 in a -08 > compatible way. > > > > BTW, this is not a minor change. As a custom extension, I'll have to hav= e > multiple callbacks in the client hello append successful version numbers > negotiated to a vector, and in the callbacks for the server hello, I'll > have to pick the best negotiated version and block all the rest, probably > using a single callback used for each version that disables itself after > being called once. Then, I'll have to write tests for all the possible > combinations of versions that could be processed (Google takes testing > pretty seriously in the front-end group). It is not rocket science, but > given the review process here, and how we like core changes to bake for a > while, it will be a few weeks before I can get this change onto live > front-end machines. > > > > Bill > --001a114e62889413e0053ae8a0ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My gut feeling is that when we need a new TB version, we&#= 39;ll also need to change the extension, hence my preference for not having= the version in the extension. However, the version field appears to be too= useful for experimentation to remove it. Given that we're bikeshedding= over 2 bytes per connection, I'm fine keeping it as is and taking the = view the the bytes are fixed at (1,0) once the RFC is published. (If we lea= ve the version in, there's going to be an implementation that only expe= cts (1,0) and will reject TB for any other version. When this happens with = TLS, we begrudgingly add a(n insecure) fallback, but I haven't figured = out how to do that in this case.)

On Thu, Aug 25, 2016 at 10:07 AM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

It=E2=80=99s probably redundant of me to say this a= gainJ<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= , but I would rather keep the current negotiation mechanism, with the versio= n field, especially at this point in the standards process.

=C2=A0

In the future, if we see that the version field in = the token_binding extension is really causing problems with the deployment = of a new TB protocol version, we can design a new TLS extension.

=C2=A0

This way, we would only be applying the workaround = when we actually have to do so.

=C2=A0

=C3=98=C2=A0 Here is a simple question I need answered: Shou= ld Google turn on token binding globally with the current version, or hold = off until the 1.0 version?=C2=A0

MS has the same issue: we=E2=80=99ve been planning = to update our TB implementation (which is currently based on the earliest T= B drafts), but a new negotiation mechanism would put these plans at risk.

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Bill Cox [mailto:waywardgeek@google.com]
Sent: Thursday, August 25, 2016 8:17 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Brian Campbell <bcampbell@ping= identity.com>; Nick Harper <nharper@google.com>; unbearable@ietf.org; Martin Thomson <martin.thomson@= gmail.com>; Stephen Farrell <stephen.farrell@cs.tcd.ie>; Leif Johansso= n <leifj@sunet.se= >
Subject: Re: [Unbearable] TLS extension: version field=

=C2=A0

On Thu, Aug 25, 2016 at 5:52 AM, John Bradley <ve7jtb@ve7jtb.com&= gt; wrote:

=C2=A0

What do others think?

=C2=A0

John B.

=C2=A0

I agree.=C2=A0 I think this is the sort of thing we = can fix in a new extension in the future, a "token binding 2.0" e= xtension.=C2=A0 I think the CONs are over-stated, since sending the version= field in 1.0 in no way restricts what we do next.

=C2=A0

Here is a simple question I need answered: Should Go= ogle turn on token binding globally with the current version, or hold off u= ntil the 1.0 version?=C2=A0 We've been assuming we want to go global no= w.=C2=A0 Are we wrong?

=C2=A0

I have token binding running on several dozen front-= end machines, processing a few million TB headers per day with solid reliab= ility.=C2=A0 All I have to do is change 2 lines in a config file to turn to= ken binding on globally.=C2=A0 Nick has to do something similar, plus some extensive process for launching new Chrome fe= atures, and we'll have Chrome speaking TB from Chrome to Google nearly = everywhere.=C2=A0 If we make a binary incompatible change like dropping the= version field, we'll have to start the whole launch process over again.=C2=A0 Each time loses at least a month, typical= ly more like 2.

=C2=A0

My preference is for for this WG to agree that we ho= pe to maintain binary compatibility with the -08 version, so that I can tur= n on token binding globally now.

=C2=A0

I would prefer to put upgrades like this on a list o= f "nice to have" features.=C2=A0 Unless the list as a whole becom= es compelling enough to break compatibility with the -08 version, I think w= e should launch 1.0 in a -08 compatible way.

=C2=A0

BTW, this is not a minor change.=C2=A0 As a custom e= xtension, I'll have to have multiple callbacks in the client hello appe= nd successful version numbers negotiated to a vector, and in the callbacks = for the server hello, I'll have to pick the best negotiated version and block all the rest, probably using a single ca= llback used for each version that disables itself after being called once.= =C2=A0 Then, I'll have to write tests for all the possible combinations= of versions that could be processed (Google takes testing pretty seriously in the front-end group).=C2=A0 It is not ro= cket science, but given the review process here, and how we like core chang= es to bake for a while, it will be a few weeks before I can get this change= onto live front-end machines.

=C2=A0

Bill


--001a114e62889413e0053ae8a0ee-- From nobody Thu Aug 25 10:30:25 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 CB38612D18E for ; Thu, 25 Aug 2016 10:30:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 kgLN6FKR_NZ1 for ; Thu, 25 Aug 2016 10:30:21 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0119.outbound.protection.outlook.com [104.47.42.119]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C2112D0ED for ; Thu, 25 Aug 2016 10:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Oh3/Wle6kbjhhmDyfVtHWFjSl5G7jpo7fY3MQ/UzogU=; b=HA7nLsjEZe6F20fosXVmanbZKoScqbzER5PmPp2TYbgpFYQ6maMZHSwrN4qeG0SOH0TQWvABINwixVwpWRSE3V2j9kEb7asqp++vrWlP1y1pHPd2NEuY8z/+pnu51dP9zLwqOslQgxWFhlnhWaZf+BxYJ9Mu8Bh4N8/qrP5Olx4= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Thu, 25 Aug 2016 17:30:18 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Thu, 25 Aug 2016 17:30:18 +0000 From: Andrei Popov To: Nick Harper Thread-Topic: [Unbearable] TLS extension: version field Thread-Index: AQHR8UE0hAr3fGh5LkSos3djbwbcUaA/MmwAgAAmOoCAAAGk8IAAhvMAgAAFqjCAAAO6AIAA6WmAgAATAoCAABJZgIAV3xfwgAATKACAAFvQgIAAAlRwgAANXQCAAAcGgIAAQVIAgADRnQCAAADEgIAAEkUAgAAEGBCAAAamgIAAAViQgAAZvwCAAAJnAIAAAhEAgAA/qZCAAAhXAIAABsHQgAC/X4CAAChTAIAAHF0wgAAGWoCAAACGQA== Date: Thu, 25 Aug 2016 17:30:18 +0000 Message-ID: References: <9b0f1cb3-a74b-2637-159c-e7aa3ee53ec6@cs.tcd.ie> <38F8CC64-29B7-4818-B423-F1C7A2939B4D@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: e2baf8f0-d390-4f4b-38d8-08d3cd0d7bce x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 6:a3ANMfYahSU6Ki0F3MDIZt6jm2PRkgiVWtQMp6u6NsJCHveVUThoRdu47WU9m/snbOy+nMiLr4gkHAahuHmFkidFA7pWRf7IQEg2yyWdnDFCwOxkCU/5kTWKJ8puBWyIFyfgWkMURtv70a8Zh0nPvwIW4ZTt8DlCOPA+k9Prt2YNGncklpVFcjFW91PEwdOIQXCeHgjaUQUFHDwV/Ym+kfD+LXlo0kOKkBsLw83H+N15a1DPqg5ylwACmUNdHmU+c+8XRoEGI6VY5g+zKxPi/6QSjgMIyBSJ/Tsn6mGB2NKA7jOr8LUrFnC679Z+2rtpo/fXyDr9/ALh7MzpCutgqg==; 5:/PeTZuY4z1hG5lmk9Ik7+3qdy640eOaO3aLVypYyphNkCeGTzabVL47GW8oFyL7UlOkNG7Ez87jr7a4VCpzDSd5CcXWHkyjKvE6ug/9DQdfLcXcLey3gtxDUvviI5Eod3FbvLL/qrLM2CwOXT6/qsQ==; 24:1E3Rc8odCc+bSXdMlcLc9nZ8bdZlLkoZ+/Oi/AZgxkMh1OtM2C5JjApSsYfAKVQnYISo1PjcN2RrgYO/Crwg54C3yjmcV5rcLkr5u3GaksU=; 7:O9NC4hS49Lby0PYiTm7CZhUJKo7DnelLUsrWpocCAp9YSVCst6vM9VwNZ4alUWEImOUI5ndw1BVOJGXP+WMdvlFMuQ05m/inES/tgT8SkfwW0N60sPpWnWH0nRQdSL33mP7aAZB/48mZQJ3dtbeprSQwNik7rKYtruF+T54yK2ATnr6eEpBIFPYjiyupoOX5JGjWEyCC/KxAZ73c7pc9q336+g1bEzBWUvAD4BR5tTOVPzWuoMiy8gRRNJnswFNo x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0842; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(158342451672863)(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 0045236D47 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(24454002)(189002)(199003)(105586002)(19625215002)(77096005)(15975445007)(790700001)(6116002)(102836003)(4326007)(2906002)(586003)(106356001)(5660300001)(122556002)(5002640100001)(86362001)(19580395003)(19300405004)(10290500002)(86612001)(93886004)(92566002)(110136002)(76576001)(5005710100001)(2900100001)(2950100001)(189998001)(97736004)(19580405001)(7846002)(54356999)(9686002)(8990500004)(10400500002)(7696003)(7736002)(74316002)(87936001)(50986999)(76176999)(101416001)(106116001)(3660700001)(3280700002)(81156014)(11100500001)(8936002)(8676002)(81166006)(99286002)(68736007)(16236675004)(10090500001)(33656002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB084292B8FCBA01D4DF52E99D8CED0CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2016 17:30:18.1701 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Cc: "unbearable@ietf.org" , Bill Cox , John Bradley , Brian Campbell , Martin Thomson , Leif Johansson , Stephen Farrell Subject: Re: [Unbearable] TLS extension: version field 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, 25 Aug 2016 17:30:24 -0000 --_000_CY1PR0301MB084292B8FCBA01D4DF52E99D8CED0CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIE15IGd1dCBmZWVsaW5nIGlzIHRoYXQgd2hlbiB3ZSBuZWVkIGEgbmV3IFRCIHZlcnNpb24s IHdlJ2xsIGFsc28gbmVlZCB0byBjaGFuZ2UgdGhlIGV4dGVuc2lvbuKApg0KUG9zc2libHksIGFu ZCB0aGlzIHdvdWxkIGJlIGEgZ29vZCByZWFzb24gdG8gaW50cm9kdWNlIGEgbmV3IFRMUyBleHRl bnNpb24gZm9yIFRCIG5lZ290aWF0aW9uLiBJTUhPLCB0aGlzIGh5cG90aGVzaXMgaXMgbm90IGEg Z29vZCByZWFzb24gdG8gcmVtb3ZlIHRoZSB2ZXJzaW9uIGZpZWxkIGZyb20gdGhlIGN1cnJlbnRs eSBkZWZpbmVkIGV4dGVuc2lvbi4NCg0KDQrDmCAgSWYgd2UgbGVhdmUgdGhlIHZlcnNpb24gaW4s IHRoZXJlJ3MgZ29pbmcgdG8gYmUgYW4gaW1wbGVtZW50YXRpb24gdGhhdCBvbmx5IGV4cGVjdHMg KDEsMCkgYW5kIHdpbGwgcmVqZWN0IFRCIGZvciBhbnkgb3RoZXIgdmVyc2lvbi4NClRoaXMgaXMg cG9zc2libGUgYXMgd2VsbCwgYW5kIGl0IHdpbGwgYmUgdGhlIDJuZCBnb29kIHJlYXNvbiB0byBp bnRyb2R1Y2UgYSBuZXcgVExTIGV4dGVuc2lvbi4gS2VlcGluZyB0aGUgdmVyc2lvbiBmaWVsZCBp biB0aGUgY3VycmVudCBUQiBuZWdvdGlhdGlvbiBleHRlbnNpb24gZG9lcyBub3QgcHJldmVudCB1 cyBmcm9tIG5lZ290aWF0aW5nIFRCIDIuMCB1c2luZyBhIG5ldyBUTFMgZXh0ZW5zaW9uLCByaWdo dD8NCg0KRnJvbTogTmljayBIYXJwZXIgW21haWx0bzpuaGFycGVyQGdvb2dsZS5jb21dDQpTZW50 OiBUaHVyc2RheSwgQXVndXN0IDI1LCAyMDE2IDEwOjIxIEFNDQpUbzogQW5kcmVpIFBvcG92IDxB bmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4NCkNjOiBCaWxsIENveCA8d2F5d2FyZGdlZWtAZ29v Z2xlLmNvbT47IEpvaG4gQnJhZGxleSA8dmU3anRiQHZlN2p0Yi5jb20+OyBCcmlhbiBDYW1wYmVs bCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+OyB1bmJlYXJhYmxlQGlldGYub3JnOyBNYXJ0 aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPjsgU3RlcGhlbiBGYXJyZWxsIDxz dGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPjsgTGVpZiBKb2hhbnNzb24gPGxlaWZqQHN1bmV0LnNl Pg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBUTFMgZXh0ZW5zaW9uOiB2ZXJzaW9uIGZpZWxk DQoNCk15IGd1dCBmZWVsaW5nIGlzIHRoYXQgd2hlbiB3ZSBuZWVkIGEgbmV3IFRCIHZlcnNpb24s IHdlJ2xsIGFsc28gbmVlZCB0byBjaGFuZ2UgdGhlIGV4dGVuc2lvbiwgaGVuY2UgbXkgcHJlZmVy ZW5jZSBmb3Igbm90IGhhdmluZyB0aGUgdmVyc2lvbiBpbiB0aGUgZXh0ZW5zaW9uLiBIb3dldmVy LCB0aGUgdmVyc2lvbiBmaWVsZCBhcHBlYXJzIHRvIGJlIHRvbyB1c2VmdWwgZm9yIGV4cGVyaW1l bnRhdGlvbiB0byByZW1vdmUgaXQuIEdpdmVuIHRoYXQgd2UncmUgYmlrZXNoZWRkaW5nIG92ZXIg MiBieXRlcyBwZXIgY29ubmVjdGlvbiwgSSdtIGZpbmUga2VlcGluZyBpdCBhcyBpcyBhbmQgdGFr aW5nIHRoZSB2aWV3IHRoZSB0aGUgYnl0ZXMgYXJlIGZpeGVkIGF0ICgxLDApIG9uY2UgdGhlIFJG QyBpcyBwdWJsaXNoZWQuIChJZiB3ZSBsZWF2ZSB0aGUgdmVyc2lvbiBpbiwgdGhlcmUncyBnb2lu ZyB0byBiZSBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0IG9ubHkgZXhwZWN0cyAoMSwwKSBhbmQgd2ls bCByZWplY3QgVEIgZm9yIGFueSBvdGhlciB2ZXJzaW9uLiBXaGVuIHRoaXMgaGFwcGVucyB3aXRo IFRMUywgd2UgYmVncnVkZ2luZ2x5IGFkZCBhKG4gaW5zZWN1cmUpIGZhbGxiYWNrLCBidXQgSSBo YXZlbid0IGZpZ3VyZWQgb3V0IGhvdyB0byBkbyB0aGF0IGluIHRoaXMgY2FzZS4pDQoNCk9uIFRo dSwgQXVnIDI1LCAyMDE2IGF0IDEwOjA3IEFNLCBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBt aWNyb3NvZnQuY29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0K SXTigJlzIHByb2JhYmx5IHJlZHVuZGFudCBvZiBtZSB0byBzYXkgdGhpcyBhZ2FpbuKYuiwgYnV0 IEkgd291bGQgcmF0aGVyIGtlZXAgdGhlIGN1cnJlbnQgbmVnb3RpYXRpb24gbWVjaGFuaXNtLCB3 aXRoIHRoZSB2ZXJzaW9uIGZpZWxkLCBlc3BlY2lhbGx5IGF0IHRoaXMgcG9pbnQgaW4gdGhlIHN0 YW5kYXJkcyBwcm9jZXNzLg0KDQpJbiB0aGUgZnV0dXJlLCBpZiB3ZSBzZWUgdGhhdCB0aGUgdmVy c2lvbiBmaWVsZCBpbiB0aGUgdG9rZW5fYmluZGluZyBleHRlbnNpb24gaXMgcmVhbGx5IGNhdXNp bmcgcHJvYmxlbXMgd2l0aCB0aGUgZGVwbG95bWVudCBvZiBhIG5ldyBUQiBwcm90b2NvbCB2ZXJz aW9uLCB3ZSBjYW4gZGVzaWduIGEgbmV3IFRMUyBleHRlbnNpb24uDQoNClRoaXMgd2F5LCB3ZSB3 b3VsZCBvbmx5IGJlIGFwcGx5aW5nIHRoZSB3b3JrYXJvdW5kIHdoZW4gd2UgYWN0dWFsbHkgaGF2 ZSB0byBkbyBzby4NCg0KDQo+ICBIZXJlIGlzIGEgc2ltcGxlIHF1ZXN0aW9uIEkgbmVlZCBhbnN3 ZXJlZDogU2hvdWxkIEdvb2dsZSB0dXJuIG9uIHRva2VuIGJpbmRpbmcgZ2xvYmFsbHkgd2l0aCB0 aGUgY3VycmVudCB2ZXJzaW9uLCBvciBob2xkIG9mZiB1bnRpbCB0aGUgMS4wIHZlcnNpb24/DQpN UyBoYXMgdGhlIHNhbWUgaXNzdWU6IHdl4oCZdmUgYmVlbiBwbGFubmluZyB0byB1cGRhdGUgb3Vy IFRCIGltcGxlbWVudGF0aW9uICh3aGljaCBpcyBjdXJyZW50bHkgYmFzZWQgb24gdGhlIGVhcmxp ZXN0IFRCIGRyYWZ0cyksIGJ1dCBhIG5ldyBuZWdvdGlhdGlvbiBtZWNoYW5pc20gd291bGQgcHV0 IHRoZXNlIHBsYW5zIGF0IHJpc2suDQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206IEJpbGwg Q294IFttYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTxtYWlsdG86d2F5d2FyZGdlZWtAZ29v Z2xlLmNvbT5dDQpTZW50OiBUaHVyc2RheSwgQXVndXN0IDI1LCAyMDE2IDg6MTcgQU0NClRvOiBK b2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+ DQpDYzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5k cmVpLlBvcG92QG1pY3Jvc29mdC5jb20+PjsgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5n aWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+OyBOaWNrIEhh cnBlciA8bmhhcnBlckBnb29nbGUuY29tPG1haWx0bzpuaGFycGVyQGdvb2dsZS5jb20+PjsgdW5i ZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZz47IE1hcnRpbiBUaG9t c29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWls LmNvbT4+OyBTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8bWFpbHRv OnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+PjsgTGVpZiBKb2hhbnNzb24gPGxlaWZqQHN1bmV0 LnNlPG1haWx0bzpsZWlmakBzdW5ldC5zZT4+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFRM UyBleHRlbnNpb246IHZlcnNpb24gZmllbGQNCg0KT24gVGh1LCBBdWcgMjUsIDIwMTYgYXQgNTo1 MiBBTSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxtYWlsdG86dmU3anRiQHZlN2p0 Yi5jb20+PiB3cm90ZToNCg0KV2hhdCBkbyBvdGhlcnMgdGhpbms/DQoNCkpvaG4gQi4NCg0KSSBh Z3JlZS4gIEkgdGhpbmsgdGhpcyBpcyB0aGUgc29ydCBvZiB0aGluZyB3ZSBjYW4gZml4IGluIGEg bmV3IGV4dGVuc2lvbiBpbiB0aGUgZnV0dXJlLCBhICJ0b2tlbiBiaW5kaW5nIDIuMCIgZXh0ZW5z aW9uLiAgSSB0aGluayB0aGUgQ09OcyBhcmUgb3Zlci1zdGF0ZWQsIHNpbmNlIHNlbmRpbmcgdGhl IHZlcnNpb24gZmllbGQgaW4gMS4wIGluIG5vIHdheSByZXN0cmljdHMgd2hhdCB3ZSBkbyBuZXh0 Lg0KDQpIZXJlIGlzIGEgc2ltcGxlIHF1ZXN0aW9uIEkgbmVlZCBhbnN3ZXJlZDogU2hvdWxkIEdv b2dsZSB0dXJuIG9uIHRva2VuIGJpbmRpbmcgZ2xvYmFsbHkgd2l0aCB0aGUgY3VycmVudCB2ZXJz aW9uLCBvciBob2xkIG9mZiB1bnRpbCB0aGUgMS4wIHZlcnNpb24/ICBXZSd2ZSBiZWVuIGFzc3Vt aW5nIHdlIHdhbnQgdG8gZ28gZ2xvYmFsIG5vdy4gIEFyZSB3ZSB3cm9uZz8NCg0KSSBoYXZlIHRv a2VuIGJpbmRpbmcgcnVubmluZyBvbiBzZXZlcmFsIGRvemVuIGZyb250LWVuZCBtYWNoaW5lcywg cHJvY2Vzc2luZyBhIGZldyBtaWxsaW9uIFRCIGhlYWRlcnMgcGVyIGRheSB3aXRoIHNvbGlkIHJl bGlhYmlsaXR5LiAgQWxsIEkgaGF2ZSB0byBkbyBpcyBjaGFuZ2UgMiBsaW5lcyBpbiBhIGNvbmZp ZyBmaWxlIHRvIHR1cm4gdG9rZW4gYmluZGluZyBvbiBnbG9iYWxseS4gIE5pY2sgaGFzIHRvIGRv IHNvbWV0aGluZyBzaW1pbGFyLCBwbHVzIHNvbWUgZXh0ZW5zaXZlIHByb2Nlc3MgZm9yIGxhdW5j aGluZyBuZXcgQ2hyb21lIGZlYXR1cmVzLCBhbmQgd2UnbGwgaGF2ZSBDaHJvbWUgc3BlYWtpbmcg VEIgZnJvbSBDaHJvbWUgdG8gR29vZ2xlIG5lYXJseSBldmVyeXdoZXJlLiAgSWYgd2UgbWFrZSBh IGJpbmFyeSBpbmNvbXBhdGlibGUgY2hhbmdlIGxpa2UgZHJvcHBpbmcgdGhlIHZlcnNpb24gZmll bGQsIHdlJ2xsIGhhdmUgdG8gc3RhcnQgdGhlIHdob2xlIGxhdW5jaCBwcm9jZXNzIG92ZXIgYWdh aW4uICBFYWNoIHRpbWUgbG9zZXMgYXQgbGVhc3QgYSBtb250aCwgdHlwaWNhbGx5IG1vcmUgbGlr ZSAyLg0KDQpNeSBwcmVmZXJlbmNlIGlzIGZvciBmb3IgdGhpcyBXRyB0byBhZ3JlZSB0aGF0IHdl IGhvcGUgdG8gbWFpbnRhaW4gYmluYXJ5IGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgLTA4IHZlcnNp b24sIHNvIHRoYXQgSSBjYW4gdHVybiBvbiB0b2tlbiBiaW5kaW5nIGdsb2JhbGx5IG5vdy4NCg0K SSB3b3VsZCBwcmVmZXIgdG8gcHV0IHVwZ3JhZGVzIGxpa2UgdGhpcyBvbiBhIGxpc3Qgb2YgIm5p Y2UgdG8gaGF2ZSIgZmVhdHVyZXMuICBVbmxlc3MgdGhlIGxpc3QgYXMgYSB3aG9sZSBiZWNvbWVz IGNvbXBlbGxpbmcgZW5vdWdoIHRvIGJyZWFrIGNvbXBhdGliaWxpdHkgd2l0aCB0aGUgLTA4IHZl cnNpb24sIEkgdGhpbmsgd2Ugc2hvdWxkIGxhdW5jaCAxLjAgaW4gYSAtMDggY29tcGF0aWJsZSB3 YXkuDQoNCkJUVywgdGhpcyBpcyBub3QgYSBtaW5vciBjaGFuZ2UuICBBcyBhIGN1c3RvbSBleHRl bnNpb24sIEknbGwgaGF2ZSB0byBoYXZlIG11bHRpcGxlIGNhbGxiYWNrcyBpbiB0aGUgY2xpZW50 IGhlbGxvIGFwcGVuZCBzdWNjZXNzZnVsIHZlcnNpb24gbnVtYmVycyBuZWdvdGlhdGVkIHRvIGEg dmVjdG9yLCBhbmQgaW4gdGhlIGNhbGxiYWNrcyBmb3IgdGhlIHNlcnZlciBoZWxsbywgSSdsbCBo YXZlIHRvIHBpY2sgdGhlIGJlc3QgbmVnb3RpYXRlZCB2ZXJzaW9uIGFuZCBibG9jayBhbGwgdGhl IHJlc3QsIHByb2JhYmx5IHVzaW5nIGEgc2luZ2xlIGNhbGxiYWNrIHVzZWQgZm9yIGVhY2ggdmVy c2lvbiB0aGF0IGRpc2FibGVzIGl0c2VsZiBhZnRlciBiZWluZyBjYWxsZWQgb25jZS4gIFRoZW4s IEknbGwgaGF2ZSB0byB3cml0ZSB0ZXN0cyBmb3IgYWxsIHRoZSBwb3NzaWJsZSBjb21iaW5hdGlv bnMgb2YgdmVyc2lvbnMgdGhhdCBjb3VsZCBiZSBwcm9jZXNzZWQgKEdvb2dsZSB0YWtlcyB0ZXN0 aW5nIHByZXR0eSBzZXJpb3VzbHkgaW4gdGhlIGZyb250LWVuZCBncm91cCkuICBJdCBpcyBub3Qg cm9ja2V0IHNjaWVuY2UsIGJ1dCBnaXZlbiB0aGUgcmV2aWV3IHByb2Nlc3MgaGVyZSwgYW5kIGhv dyB3ZSBsaWtlIGNvcmUgY2hhbmdlcyB0byBiYWtlIGZvciBhIHdoaWxlLCBpdCB3aWxsIGJlIGEg ZmV3IHdlZWtzIGJlZm9yZSBJIGNhbiBnZXQgdGhpcyBjaGFuZ2Ugb250byBsaXZlIGZyb250LWVu ZCBtYWNoaW5lcy4NCg0KQmlsbA0KDQo= --_000_CY1PR0301MB084292B8FCBA01D4DF52E99D8CED0CY1PR0301MB0842_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubS0zOTY3MTg4MjExNDkwNDQxMTc0bXNvbGlzdHBhcmFn cmFwaCwgbGkubS0zOTY3MTg4MjExNDkwNDQxMTc0bXNvbGlzdHBhcmFncmFwaCwgZGl2Lm0tMzk2 NzE4ODIxMTQ5MDQ0MTE3NG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6bV8tMzk2 NzE4ODIxMTQ5MDQ0MTE3NG1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERl ZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNjc1NzY1NzQwOw0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTgxOTQwNTQ3OCAtMTA3 OTUwNDk2MCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50 Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+TXkgZ3V0IGZlZWxpbmcgaXMgdGhhdCB3aGVuIHdlIG5lZWQgYSBuZXcgVEIgdmVyc2lvbiwg d2UnbGwgYWxzbyBuZWVkIHRvIGNoYW5nZSB0aGUgZXh0ZW5zaW9u4oCmPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPlBvc3NpYmx5LCBhbmQgdGhpcyB3b3VsZCBiZSBhIGdvb2QgcmVhc29uIHRvIGludHJv ZHVjZSBhIG5ldyBUTFMgZXh0ZW5zaW9uIGZvciBUQiBuZWdvdGlhdGlvbi4gSU1ITywgdGhpcyBo eXBvdGhlc2lzIGlzIG5vdCBhIGdvb2QgcmVhc29uIHRvIHJlbW92ZSB0aGUgdmVyc2lvbiBmaWVs ZCBmcm9tIHRoZQ0KIGN1cnJlbnRseSBkZWZpbmVkIGV4dGVuc2lvbi48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3Mi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5JZiB3ZSBsZWF2ZSB0aGUgdmVyc2lvbiBpbiwgdGhlcmUncyBnb2luZyB0byBi ZSBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0IG9ubHkgZXhwZWN0cyAoMSwwKSBhbmQgd2lsbCByZWpl Y3QgVEIgZm9yIGFueSBvdGhlciB2ZXJzaW9uLjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGlz IHBvc3NpYmxlIGFzIHdlbGwsIGFuZCBpdCB3aWxsIGJlIHRoZSAyPHN1cD5uZDwvc3VwPiBnb29k IHJlYXNvbiB0byBpbnRyb2R1Y2UgYSBuZXcgVExTIGV4dGVuc2lvbi4gS2VlcGluZyB0aGUgdmVy c2lvbiBmaWVsZCBpbiB0aGUgY3VycmVudCBUQiBuZWdvdGlhdGlvbiBleHRlbnNpb24NCiBkb2Vz IG5vdCBwcmV2ZW50IHVzIGZyb20gbmVnb3RpYXRpbmcgVEIgMi4wIHVzaW5nIGEgbmV3IFRMUyBl eHRlbnNpb24sIHJpZ2h0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4gTmljayBIYXJwZXIgW21haWx0bzpuaGFycGVyQGdvb2dsZS5jb21dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAyNSwgMjAxNiAxMDoyMSBBTTxicj4NCjxi PlRvOjwvYj4gQW5kcmVpIFBvcG92ICZsdDtBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSZndDs8 YnI+DQo8Yj5DYzo8L2I+IEJpbGwgQ294ICZsdDt3YXl3YXJkZ2Vla0Bnb29nbGUuY29tJmd0Ozsg Sm9obiBCcmFkbGV5ICZsdDt2ZTdqdGJAdmU3anRiLmNvbSZndDs7IEJyaWFuIENhbXBiZWxsICZs dDtiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSZndDs7IHVuYmVhcmFibGVAaWV0Zi5vcmc7IE1h cnRpbiBUaG9tc29uICZsdDttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7OyBTdGVwaGVuIEZh cnJlbGwgJmx0O3N0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUmZ3Q7OyBMZWlmIEpvaGFuc3NvbiAm bHQ7bGVpZmpAc3VuZXQuc2UmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJs ZV0gVExTIGV4dGVuc2lvbjogdmVyc2lvbiBmaWVsZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk15IGd1dCBmZWVsaW5nIGlzIHRoYXQgd2hlbiB3ZSBuZWVkIGEgbmV3IFRC IHZlcnNpb24sIHdlJ2xsIGFsc28gbmVlZCB0byBjaGFuZ2UgdGhlIGV4dGVuc2lvbiwgaGVuY2Ug bXkgcHJlZmVyZW5jZSBmb3Igbm90IGhhdmluZyB0aGUgdmVyc2lvbiBpbiB0aGUgZXh0ZW5zaW9u LiBIb3dldmVyLCB0aGUgdmVyc2lvbiBmaWVsZCBhcHBlYXJzIHRvIGJlIHRvbyB1c2VmdWwgZm9y IGV4cGVyaW1lbnRhdGlvbiB0byByZW1vdmUNCiBpdC4gR2l2ZW4gdGhhdCB3ZSdyZSBiaWtlc2hl ZGRpbmcgb3ZlciAyIGJ5dGVzIHBlciBjb25uZWN0aW9uLCBJJ20gZmluZSBrZWVwaW5nIGl0IGFz IGlzIGFuZCB0YWtpbmcgdGhlIHZpZXcgdGhlIHRoZSBieXRlcyBhcmUgZml4ZWQgYXQgKDEsMCkg b25jZSB0aGUgUkZDIGlzIHB1Ymxpc2hlZC4gKElmIHdlIGxlYXZlIHRoZSB2ZXJzaW9uIGluLCB0 aGVyZSdzIGdvaW5nIHRvIGJlIGFuIGltcGxlbWVudGF0aW9uIHRoYXQgb25seSBleHBlY3RzICgx LDApDQogYW5kIHdpbGwgcmVqZWN0IFRCIGZvciBhbnkgb3RoZXIgdmVyc2lvbi4gV2hlbiB0aGlz IGhhcHBlbnMgd2l0aCBUTFMsIHdlIGJlZ3J1ZGdpbmdseSBhZGQgYShuIGluc2VjdXJlKSBmYWxs YmFjaywgYnV0IEkgaGF2ZW4ndCBmaWd1cmVkIG91dCBob3cgdG8gZG8gdGhhdCBpbiB0aGlzIGNh c2UuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1 LCBBdWcgMjUsIDIwMTYgYXQgMTA6MDcgQU0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFp bHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmVpLlBv cG92QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5JdOKAmXMgcHJvYmFibHkgcmVkdW5kYW50IG9mIG1lIHRvIHNheSB0aGlzIGFnYWluPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+Sjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiwNCiBidXQgSSB3b3VsZCByYXRoZXIga2VlcCB0aGUgY3Vy cmVudCBuZWdvdGlhdGlvbiBtZWNoYW5pc20sIHdpdGggdGhlIHZlcnNpb24gZmllbGQsIGVzcGVj aWFsbHkgYXQgdGhpcyBwb2ludCBpbiB0aGUgc3RhbmRhcmRzIHByb2Nlc3MuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5JbiB0aGUgZnV0dXJlLCBpZiB3ZSBzZWUgdGhhdCB0aGUgdmVyc2lvbiBmaWVsZCBp biB0aGUgdG9rZW5fYmluZGluZyBleHRlbnNpb24gaXMgcmVhbGx5IGNhdXNpbmcgcHJvYmxlbXMg d2l0aCB0aGUNCiBkZXBsb3ltZW50IG9mIGEgbmV3IFRCIHByb3RvY29sIHZlcnNpb24sIHdlIGNh biBkZXNpZ24gYSBuZXcgVExTIGV4dGVuc2lvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXMgd2F5 LCB3ZSB3b3VsZCBvbmx5IGJlIGFwcGx5aW5nIHRoZSB3b3JrYXJvdW5kIHdoZW4gd2UgYWN0dWFs bHkgaGF2ZSB0byBkbyBzby48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Im0tMzk2NzE4ODIxMTQ5MDQ0MTE3NG1zb2xpc3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+w5g8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7DQo8L3NwYW4+SGVyZSBpcyBhIHNpbXBsZSBx dWVzdGlvbiBJIG5lZWQgYW5zd2VyZWQ6IFNob3VsZCBHb29nbGUgdHVybiBvbiB0b2tlbiBiaW5k aW5nIGdsb2JhbGx5IHdpdGggdGhlIGN1cnJlbnQgdmVyc2lvbiwgb3IgaG9sZCBvZmYgdW50aWwg dGhlIDEuMCB2ZXJzaW9uPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk1TIGhhcyB0aGUgc2FtZSBpc3N1ZTogd2XigJl2ZSBiZWVu IHBsYW5uaW5nIHRvIHVwZGF0ZSBvdXIgVEIgaW1wbGVtZW50YXRpb24gKHdoaWNoIGlzIGN1cnJl bnRseSBiYXNlZCBvbiB0aGUgZWFybGllc3QNCiBUQiBkcmFmdHMpLCBidXQgYSBuZXcgbmVnb3Rp YXRpb24gbWVjaGFuaXNtIHdvdWxkIHB1dCB0aGVzZSBwbGFucyBhdCByaXNrLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Q2hlZXJzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kcmVpPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQmlsbCBDb3ggW21haWx0 bzo8YSBocmVmPSJtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PndheXdhcmRnZWVrQGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBBdWd1c3QgMjUsIDIwMTYgODoxNyBBTTxicj4NCjxiPlRvOjwvYj4gSm9obiBCcmFkbGV5ICZs dDs8YSBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iIHRhcmdldD0iX2JsYW5rIj52ZTdq dGJAdmU3anRiLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBBbmRyZWkgUG9wb3YgJmx0Ozxh IGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsi PkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDs7IEJyaWFuIENhbXBiZWxsICZsdDs8 YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5r Ij5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7OyBOaWNrIEhhcnBlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5oYXJwZXJA Z29vZ2xlLmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj51bmJlYXJhYmxlQGlldGYub3JnPC9hPjsgTWFydGluIFRob21zb24g Jmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OzsgU3RlcGhlbiBGYXJyZWxsICZs dDs8YSBocmVmPSJtYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZSIgdGFyZ2V0PSJfYmxh bmsiPnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8L2E+Jmd0OzsNCiBMZWlmIEpvaGFuc3NvbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmxlaWZqQHN1bmV0LnNlIiB0YXJnZXQ9Il9ibGFuayI+bGVpZmpA c3VuZXQuc2U8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIFRM UyBleHRlbnNpb246IHZlcnNpb24gZmllbGQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUsIEF1ZyAyNSwgMjAxNiBhdCA1OjUyIEFN LCBKb2huIEJyYWRsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnZlN2p0YkB2ZTdqdGIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGF0 IGRvIG90aGVycyB0aGluaz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkpvaG4gQi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBhZ3Jl ZS4mbmJzcDsgSSB0aGluayB0aGlzIGlzIHRoZSBzb3J0IG9mIHRoaW5nIHdlIGNhbiBmaXggaW4g YSBuZXcgZXh0ZW5zaW9uIGluIHRoZSBmdXR1cmUsIGEgJnF1b3Q7dG9rZW4gYmluZGluZyAyLjAm cXVvdDsgZXh0ZW5zaW9uLiZuYnNwOyBJIHRoaW5rIHRoZSBDT05zIGFyZSBvdmVyLXN0YXRlZCwg c2luY2Ugc2VuZGluZyB0aGUgdmVyc2lvbg0KIGZpZWxkIGluIDEuMCBpbiBubyB3YXkgcmVzdHJp Y3RzIHdoYXQgd2UgZG8gbmV4dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkhlcmUgaXMgYSBzaW1wbGUgcXVlc3Rpb24gSSBuZWVkIGFu c3dlcmVkOiBTaG91bGQgR29vZ2xlIHR1cm4gb24gdG9rZW4gYmluZGluZyBnbG9iYWxseSB3aXRo IHRoZSBjdXJyZW50IHZlcnNpb24sIG9yIGhvbGQgb2ZmIHVudGlsIHRoZSAxLjAgdmVyc2lvbj8m bmJzcDsgV2UndmUgYmVlbiBhc3N1bWluZyB3ZSB3YW50DQogdG8gZ28gZ2xvYmFsIG5vdy4mbmJz cDsgQXJlIHdlIHdyb25nPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SSBoYXZlIHRva2VuIGJpbmRpbmcgcnVubmluZyBvbiBzZXZlcmFs IGRvemVuIGZyb250LWVuZCBtYWNoaW5lcywgcHJvY2Vzc2luZyBhIGZldyBtaWxsaW9uIFRCIGhl YWRlcnMgcGVyIGRheSB3aXRoIHNvbGlkIHJlbGlhYmlsaXR5LiZuYnNwOyBBbGwgSSBoYXZlIHRv IGRvIGlzIGNoYW5nZSAyIGxpbmVzIGluIGEgY29uZmlnDQogZmlsZSB0byB0dXJuIHRva2VuIGJp bmRpbmcgb24gZ2xvYmFsbHkuJm5ic3A7IE5pY2sgaGFzIHRvIGRvIHNvbWV0aGluZyBzaW1pbGFy LCBwbHVzIHNvbWUgZXh0ZW5zaXZlIHByb2Nlc3MgZm9yIGxhdW5jaGluZyBuZXcgQ2hyb21lIGZl YXR1cmVzLCBhbmQgd2UnbGwgaGF2ZSBDaHJvbWUgc3BlYWtpbmcgVEIgZnJvbSBDaHJvbWUgdG8g R29vZ2xlIG5lYXJseSBldmVyeXdoZXJlLiZuYnNwOyBJZiB3ZSBtYWtlIGEgYmluYXJ5IGluY29t cGF0aWJsZSBjaGFuZ2UgbGlrZQ0KIGRyb3BwaW5nIHRoZSB2ZXJzaW9uIGZpZWxkLCB3ZSdsbCBo YXZlIHRvIHN0YXJ0IHRoZSB3aG9sZSBsYXVuY2ggcHJvY2VzcyBvdmVyIGFnYWluLiZuYnNwOyBF YWNoIHRpbWUgbG9zZXMgYXQgbGVhc3QgYSBtb250aCwgdHlwaWNhbGx5IG1vcmUgbGlrZSAyLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ TXkgcHJlZmVyZW5jZSBpcyBmb3IgZm9yIHRoaXMgV0cgdG8gYWdyZWUgdGhhdCB3ZSBob3BlIHRv IG1haW50YWluIGJpbmFyeSBjb21wYXRpYmlsaXR5IHdpdGggdGhlIC0wOCB2ZXJzaW9uLCBzbyB0 aGF0IEkgY2FuIHR1cm4gb24gdG9rZW4gYmluZGluZyBnbG9iYWxseSBub3cuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHdvdWxkIHBy ZWZlciB0byBwdXQgdXBncmFkZXMgbGlrZSB0aGlzIG9uIGEgbGlzdCBvZiAmcXVvdDtuaWNlIHRv IGhhdmUmcXVvdDsgZmVhdHVyZXMuJm5ic3A7IFVubGVzcyB0aGUgbGlzdCBhcyBhIHdob2xlIGJl Y29tZXMgY29tcGVsbGluZyBlbm91Z2ggdG8gYnJlYWsgY29tcGF0aWJpbGl0eSB3aXRoIHRoZSAt MDggdmVyc2lvbiwNCiBJIHRoaW5rIHdlIHNob3VsZCBsYXVuY2ggMS4wIGluIGEgLTA4IGNvbXBh dGlibGUgd2F5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+QlRXLCB0aGlzIGlzIG5vdCBhIG1pbm9yIGNoYW5nZS4mbmJzcDsgQXMgYSBj dXN0b20gZXh0ZW5zaW9uLCBJJ2xsIGhhdmUgdG8gaGF2ZSBtdWx0aXBsZSBjYWxsYmFja3MgaW4g dGhlIGNsaWVudCBoZWxsbyBhcHBlbmQgc3VjY2Vzc2Z1bCB2ZXJzaW9uIG51bWJlcnMgbmVnb3Rp YXRlZCB0byBhIHZlY3RvciwgYW5kIGluDQogdGhlIGNhbGxiYWNrcyBmb3IgdGhlIHNlcnZlciBo ZWxsbywgSSdsbCBoYXZlIHRvIHBpY2sgdGhlIGJlc3QgbmVnb3RpYXRlZCB2ZXJzaW9uIGFuZCBi bG9jayBhbGwgdGhlIHJlc3QsIHByb2JhYmx5IHVzaW5nIGEgc2luZ2xlIGNhbGxiYWNrIHVzZWQg Zm9yIGVhY2ggdmVyc2lvbiB0aGF0IGRpc2FibGVzIGl0c2VsZiBhZnRlciBiZWluZyBjYWxsZWQg b25jZS4mbmJzcDsgVGhlbiwgSSdsbCBoYXZlIHRvIHdyaXRlIHRlc3RzIGZvciBhbGwgdGhlIHBv c3NpYmxlDQogY29tYmluYXRpb25zIG9mIHZlcnNpb25zIHRoYXQgY291bGQgYmUgcHJvY2Vzc2Vk IChHb29nbGUgdGFrZXMgdGVzdGluZyBwcmV0dHkgc2VyaW91c2x5IGluIHRoZSBmcm9udC1lbmQg Z3JvdXApLiZuYnNwOyBJdCBpcyBub3Qgcm9ja2V0IHNjaWVuY2UsIGJ1dCBnaXZlbiB0aGUgcmV2 aWV3IHByb2Nlc3MgaGVyZSwgYW5kIGhvdyB3ZSBsaWtlIGNvcmUgY2hhbmdlcyB0byBiYWtlIGZv ciBhIHdoaWxlLCBpdCB3aWxsIGJlIGEgZmV3IHdlZWtzIGJlZm9yZSBJDQogY2FuIGdldCB0aGlz IGNoYW5nZSBvbnRvIGxpdmUgZnJvbnQtZW5kIG1hY2hpbmVzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmlsbDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR0301MB084292B8FCBA01D4DF52E99D8CED0CY1PR0301MB0842_-- From nobody Thu Aug 25 10:40:51 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 EA01712D104 for ; Thu, 25 Aug 2016 10:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 7YlzRnTMOKJs for ; Thu, 25 Aug 2016 10:40:48 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 BC4D8126FDC for ; Thu, 25 Aug 2016 10:40:47 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id k90so96412539uak.1 for ; Thu, 25 Aug 2016 10:40:47 -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=wI7InQ0ih6Uw7Vhq7E+IJLB0bK8wo5/3eZJziwsoSf0=; b=QwTTtXwt+TLKge+bxMYPSRY3xsYDGat7hAvr5QhzJFsX7RpqfF1Qu29FMgRLzIomPx trq4VIUpNf07Lll/X0BTJjrrQLp3m6FH86i85VNovyYsy2tpaB3jwcaf4VcH914p5+fJ jCU5Ba+jqQkmpTLx0Ll5+y6l6KhrcrlFajYnDzfiC2kDKybKrI10SqdNWMjhm6+ozLbK aY/ExLB5ZsqtkjEJKp7jPowPDMg5f8K871IobGjxL3yCQG1zLsbfDykp7I2WU6Typ8sS KcImMxC54xP4vJsejDnMySCZmIFIb3KZCofpYwy6I91PJtV3bVP2FYnSEaRp9dKtBpd/ 6E4Q== 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=wI7InQ0ih6Uw7Vhq7E+IJLB0bK8wo5/3eZJziwsoSf0=; b=B4x1aTQEsaJ7LsNzXKadEabxJmoVQxLto2RJZ/LR39ezFvsrB8/K3OpH5HZcA/jEOx HUxlWG/oZJVwH65CpCA2hWiqqtkXIz27yoYPK5XksdbpITvjnNdZPYqT5LQjhBlcFXL1 8WlcFcNcBxlA0DRvr0Q1bFbdSRHFvdtA8XxJHNgUyWQiHa1bpAxAF0vtHgPPYohbY0vw m12V9tYli2NkIPhMCqrxquAfPCU8CaoQ4bfkMs6wc9g+K62bxs4ZDz0wcr6MIdQ0rBj4 N1iLKWhefhi8XqdQZwgT7Vc3VRMFiyxDWgcsTa27frWnQsz2HaMMb5DO3z6WlBQK6tL4 kKQQ== X-Gm-Message-State: AEkoouuqlnFD5Xw5078x3YBeMsi3FBYkPJZl+BPA4zE6d4yR10Agk6l7N9slPVft13qpAVYyofIEH2XIHYQfWh7w X-Received: by 10.31.96.82 with SMTP id u79mr5563014vkb.88.1472146846665; Thu, 25 Aug 2016 10:40:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.209 with HTTP; Thu, 25 Aug 2016 10:40:25 -0700 (PDT) In-Reply-To: References: <9b0f1cb3-a74b-2637-159c-e7aa3ee53ec6@cs.tcd.ie> <38F8CC64-29B7-4818-B423-F1C7A2939B4D@ve7jtb.com> From: Nick Harper Date: Thu, 25 Aug 2016 10:40:25 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a114e6288da8edf053ae8e5c2 Archived-At: Cc: "unbearable@ietf.org" , Bill Cox , John Bradley , Brian Campbell , Martin Thomson , Leif Johansson , Stephen Farrell Subject: Re: [Unbearable] TLS extension: version field 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, 25 Aug 2016 17:40:50 -0000 --001a114e6288da8edf053ae8e5c2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 25, 2016 at 10:30 AM, Andrei Popov wrote: > =C3=98 My gut feeling is that when we need a new TB version, we'll also = need > to change the extension=E2=80=A6 > > Possibly, and this would be a good reason to introduce a new TLS extensio= n > for TB negotiation. IMHO, this hypothesis is not a good reason to remove > the version field from the currently defined extension. > > > > =C3=98 If we leave the version in, there's going to be an implementation= that > only expects (1,0) and will reject TB for any other version. > > This is possible as well, and it will be the 2nd good reason to introduce > a new TLS extension. Keeping the version field in the current TB > negotiation extension does not prevent us from negotiating TB 2.0 using a > new TLS extension, right? > Correct. It seems weird to me that the final spec includes bytes that were only used for developing the spec. I acknowledge that it's difficult to remove them at this point, but maybe when we introduce the new extension for a new TB version we can avoid this. > > > *From:* Nick Harper [mailto:nharper@google.com] > *Sent:* Thursday, August 25, 2016 10:21 AM > *To:* Andrei Popov > *Cc:* Bill Cox ; John Bradley = ; > Brian Campbell ; unbearable@ietf.org; Martin > Thomson ; Stephen Farrell < > stephen.farrell@cs.tcd.ie>; Leif Johansson > > *Subject:* Re: [Unbearable] TLS extension: version field > > > > My gut feeling is that when we need a new TB version, we'll also need to > change the extension, hence my preference for not having the version in t= he > extension. However, the version field appears to be too useful for > experimentation to remove it. Given that we're bikeshedding over 2 bytes > per connection, I'm fine keeping it as is and taking the view the the byt= es > are fixed at (1,0) once the RFC is published. (If we leave the version in= , > there's going to be an implementation that only expects (1,0) and will > reject TB for any other version. When this happens with TLS, we > begrudgingly add a(n insecure) fallback, but I haven't figured out how to > do that in this case.) > > > > On Thu, Aug 25, 2016 at 10:07 AM, Andrei Popov > wrote: > > It=E2=80=99s probably redundant of me to say this againJ, but I would rat= her keep > the current negotiation mechanism, with the version field, especially at > this point in the standards process. > > > > In the future, if we see that the version field in the token_binding > extension is really causing problems with the deployment of a new TB > protocol version, we can design a new TLS extension. > > > > This way, we would only be applying the workaround when we actually have > to do so. > > > > =C3=98 Here is a simple question I need answered: Should Google turn on = token > binding globally with the current version, or hold off until the 1.0 > version? > > MS has the same issue: we=E2=80=99ve been planning to update our TB imple= mentation > (which is currently based on the earliest TB drafts), but a new negotiati= on > mechanism would put these plans at risk. > > > > Cheers, > > > > Andrei > > > > *From:* Bill Cox [mailto:waywardgeek@google.com] > *Sent:* Thursday, August 25, 2016 8:17 AM > *To:* John Bradley > *Cc:* Andrei Popov ; Brian Campbell < > bcampbell@pingidentity.com>; Nick Harper ; > unbearable@ietf.org; Martin Thomson ; Stephen > Farrell ; Leif Johansson > *Subject:* Re: [Unbearable] TLS extension: version field > > > > On Thu, Aug 25, 2016 at 5:52 AM, John Bradley wrote: > > > > What do others think? > > > > John B. > > > > I agree. I think this is the sort of thing we can fix in a new extension > in the future, a "token binding 2.0" extension. I think the CONs are > over-stated, since sending the version field in 1.0 in no way restricts > what we do next. > > > > Here is a simple question I need answered: Should Google turn on token > binding globally with the current version, or hold off until the 1.0 > version? We've been assuming we want to go global now. Are we wrong? > > > > I have token binding running on several dozen front-end machines, > processing a few million TB headers per day with solid reliability. All = I > have to do is change 2 lines in a config file to turn token binding on > globally. Nick has to do something similar, plus some extensive process > for launching new Chrome features, and we'll have Chrome speaking TB from > Chrome to Google nearly everywhere. If we make a binary incompatible > change like dropping the version field, we'll have to start the whole > launch process over again. Each time loses at least a month, typically > more like 2. > > > > My preference is for for this WG to agree that we hope to maintain binary > compatibility with the -08 version, so that I can turn on token binding > globally now. > > > > I would prefer to put upgrades like this on a list of "nice to have" > features. Unless the list as a whole becomes compelling enough to break > compatibility with the -08 version, I think we should launch 1.0 in a -08 > compatible way. > > > > BTW, this is not a minor change. As a custom extension, I'll have to hav= e > multiple callbacks in the client hello append successful version numbers > negotiated to a vector, and in the callbacks for the server hello, I'll > have to pick the best negotiated version and block all the rest, probably > using a single callback used for each version that disables itself after > being called once. Then, I'll have to write tests for all the possible > combinations of versions that could be processed (Google takes testing > pretty seriously in the front-end group). It is not rocket science, but > given the review process here, and how we like core changes to bake for a > while, it will be a few weeks before I can get this change onto live > front-end machines. > > > > Bill > > > --001a114e6288da8edf053ae8e5c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 25, 2016 at 10:30 AM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

=C3=98=C2=A0 My gut feeling is that when we need a new TB ve= rsion, we'll also need to change the extension=E2=80=A6<= /span>

Possibly, and this would be a good reason to introd= uce a new TLS extension for TB negotiation. IMHO, this hypothesis is not a = good reason to remove the version field from the currently defined extension.

=C2=A0

=C3=98=C2=A0 If we leave the version in, there's going t= o be an implementation that only expects (1,0) and will reject TB for any o= ther version.

This is possible as well, and it will be the 2= nd good reason to introduce a new TLS extension. Keeping the version = field in the current TB negotiation extension does not prevent us from negotiating TB 2.0 using a new TLS extension, rig= ht?


Correct. It seem= s weird to me that the final spec includes bytes that were only used for de= veloping the spec. I acknowledge that it's difficult to remove them at = this point, but maybe when we introduce the new extension for a new TB vers= ion we can avoid this.=C2=A0

=C2=A0

From: Nick Harper [mailto:nharper@google.com]
Sent: Thursday, August 25, 2016 10:21 AM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Bill Cox <waywardgeek@google.com>; John Bradley <ve7jtb@ve7jtb.com>; Brian Camp= bell <bc= ampbell@pingidentity.com>; unbearable@ietf.org; Martin Thomson <martin.thomson@gmail.com= >; Stephen Farrell <stephen.farrell@cs.tcd.ie>; Leif Johansson <leifj@sunet.se><= /p>


Subject: Re: [Unbearable] TLS extension: version field=

=C2=A0

My gut feeling is that when we need a new TB version= , we'll also need to change the extension, hence my preference for not = having the version in the extension. However, the version field appears to = be too useful for experimentation to remove it. Given that we're bikeshedding over 2 bytes per connection, I'm= fine keeping it as is and taking the view the the bytes are fixed at (1,0)= once the RFC is published. (If we leave the version in, there's going = to be an implementation that only expects (1,0) and will reject TB for any other version. When this happens with TLS, we b= egrudgingly add a(n insecure) fallback, but I haven't figured out how t= o do that in this case.)

=C2=A0

On Thu, Aug 25, 2016 at 10:07 AM, Andrei Popov <<= a href=3D"mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov= @microsoft.com> wrote:

It=E2=80=99s probably redundant of me to say this a= gainJ<= span style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif">= , but I would rather keep the current negotiation mechanism, with the versio= n field, especially at this point in the standards process.

=C2=A0

In the future, if we see that the version field in = the token_binding extension is really causing problems with the deployment of a new TB protocol version, we can design a new TLS extension= .

=C2=A0

This way, we would only be applying the workaround = when we actually have to do so.

=C2=A0

=C3=98=C2=A0 Here is a simple question I need answered: Should Google turn on tok= en binding globally with the current version, or hold off until the 1.0 ver= sion?=C2=A0

MS has the same issue: we=E2=80=99ve been planning = to update our TB implementation (which is currently based on the earliest TB drafts), but a new negotiation mechanism would put these plans at risk.=

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Bill Cox [mailto:waywardgeek@google.com]
Sent: Thursday, August 25, 2016 8:17 AM
To: John Bradley <ve7jtb@ve7jtb.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Brian Campbell <bcampbell@ping= identity.com>; Nick Harper <nharper@google.com>; unbearable@ietf.or= g; Martin Thomson <martin.thomson@gmail.com>; Stephen Farrell <stephen.farrell@cs.= tcd.ie>; Leif Johansson <lei= fj@sunet.se>
Subject: Re: [Unbearable] TLS extension: version field=

=C2=A0

On Thu, Aug 25, 2016 at 5:52 AM, John Bradley <ve7jtb@ve7jtb.com&= gt; wrote:

=C2=A0

What do others think?

=C2=A0

John B.

=C2=A0

I agree.=C2=A0 I think this is the sort of thing we = can fix in a new extension in the future, a "token binding 2.0" e= xtension.=C2=A0 I think the CONs are over-stated, since sending the version field in 1.0 in no way restricts what we do next.

=C2=A0

Here is a simple question I need answered: Should Go= ogle turn on token binding globally with the current version, or hold off u= ntil the 1.0 version?=C2=A0 We've been assuming we want to go global now.=C2=A0 Are we wrong?

=C2=A0

I have token binding running on several dozen front-= end machines, processing a few million TB headers per day with solid reliab= ility.=C2=A0 All I have to do is change 2 lines in a config file to turn token binding on globally.=C2=A0 Nick has to do something sim= ilar, plus some extensive process for launching new Chrome features, and we= 'll have Chrome speaking TB from Chrome to Google nearly everywhere.=C2= =A0 If we make a binary incompatible change like dropping the version field, we'll have to start the whole launch proce= ss over again.=C2=A0 Each time loses at least a month, typically more like = 2.

=C2=A0

My preference is for for this WG to agree that we ho= pe to maintain binary compatibility with the -08 version, so that I can tur= n on token binding globally now.

=C2=A0

I would prefer to put upgrades like this on a list o= f "nice to have" features.=C2=A0 Unless the list as a whole becom= es compelling enough to break compatibility with the -08 version, I think we should launch 1.0 in a -08 compatible way.

=C2=A0

BTW, this is not a minor change.=C2=A0 As a custom e= xtension, I'll have to have multiple callbacks in the client hello appe= nd successful version numbers negotiated to a vector, and in the callbacks for the server hello, I'll have to pick the best negotia= ted version and block all the rest, probably using a single callback used f= or each version that disables itself after being called once.=C2=A0 Then, I= 'll have to write tests for all the possible combinations of versions that could be processed (Google takes testing pre= tty seriously in the front-end group).=C2=A0 It is not rocket science, but = given the review process here, and how we like core changes to bake for a w= hile, it will be a few weeks before I can get this change onto live front-end machines.

=C2=A0

Bill

=C2=A0


--001a114e6288da8edf053ae8e5c2-- From nobody Thu Aug 25 10:50:56 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 B72D712B03A for ; Thu, 25 Aug 2016 10:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 0Ydx7v_2COcE for ; Thu, 25 Aug 2016 10:50:53 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 79ED812D528 for ; Thu, 25 Aug 2016 10:50:53 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id m60so56647379uam.3 for ; Thu, 25 Aug 2016 10:50:53 -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=LTU1oIsCjdxdPVz5KvKnhlj2Mte5ow2N14Wm3Uz9cEU=; b=StT8ja1JKNS9l29yrlo5ThCOr4UMOHdY/NvkeUir6lxp6qb03BZyZeTjYQvYt2px+X xuBRMjfJ3H2hKoBB5zCM1qWn0oIkbYbrSRcaU+5ozqDwFf2ssHrJ12UzcVd1FhT5lXSb kDoPO9kZtF2cv4kyaVqZQoTrUmZtZcoMUO9zoObBFVB2ANsLpVbEnPCGTVZPcJxF6dcg itI4ra/PnLdXqt6Ri4kxO5wdBFVjGryQyHhVK5LHTBu1iONAqgtleHifuthTypGjIJ6X afAWHoHrdEk7liMoFJXs/Hcj080liepXtZgBwGTLYF0UYcv60kZ+WHqHteZbtfYsuZ6y 5ARg== 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=LTU1oIsCjdxdPVz5KvKnhlj2Mte5ow2N14Wm3Uz9cEU=; b=KYwpblvvvYEbp+0P0bhYSyGrJkeBDc1EcoERKOnr8R3qpNyMUpxt2EBYn8A/khnWue pAtT2X4LOXZX2DTMM8yUDOOjkQJ82SJj8V92JtWW1gJPe/mlmpt7yuv9FPFEJ8k7YEkL NKgqQvzRVEmmivRtLdZtzRGtvMtvJ0FU6wUBl+rEZKuLfVEG1QUfTimsU1LQgCJqCN8c DJGhdIyNhWiZBSWYKdqA89zXIX9ekhLndBmljQ/HePS8G9vEl8/iD3WwgUrAFl2cVNX5 hqClVpLqvO/MSKtle96TMefbUIH8deqp3tV1WGVpJlZMw3cwGCEKCfWg6DmVSG5mfhfK SC3w== X-Gm-Message-State: AE9vXwPn/HgomrDGh2Aeelq6T7f+TZ6jkEOLsmu8dkdjP8H1gdKzMLxMFeC8G4KmkMwzfAxBBvUQIo9DSXI8593M X-Received: by 10.159.37.106 with SMTP id 97mr5672647uaz.27.1472147452217; Thu, 25 Aug 2016 10:50:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.97.2 with HTTP; Thu, 25 Aug 2016 10:50:50 -0700 (PDT) In-Reply-To: References: <9b0f1cb3-a74b-2637-159c-e7aa3ee53ec6@cs.tcd.ie> <38F8CC64-29B7-4818-B423-F1C7A2939B4D@ve7jtb.com> From: Bill Cox Date: Thu, 25 Aug 2016 10:50:50 -0700 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=94eb2c122fb6f28eab053ae9090b Archived-At: Cc: Andrei Popov , "unbearable@ietf.org" , John Bradley , Brian Campbell , Martin Thomson , Leif Johansson , Stephen Farrell Subject: Re: [Unbearable] TLS extension: version field 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, 25 Aug 2016 17:50:55 -0000 --94eb2c122fb6f28eab053ae9090b Content-Type: text/plain; charset=UTF-8 On Thu, Aug 25, 2016 at 10:40 AM, Nick Harper wrote: > > Correct. It seems weird to me that the final spec includes bytes that were > only used for developing the spec. I acknowledge that it's difficult to > remove them at this point, but maybe when we introduce the new extension > for a new TB version we can avoid this. > It seems weird to me, too. We could save 1 of those bytes by saying that the 1.0 version has a 1, and is not followed by the minor version number. Since the byte after the version is the client's preferred key parameters, it seems like we need the 1-byte separation. I'd be OK with version 1.0 being represented by the single byte 0x01, and requiring all implementations to reject TB extension 24 when the version byte is not 1. Bill --94eb2c122fb6f28eab053ae9090b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 25, 2016 at 10:40 AM, Nick Harper <nharper@google.com> wrote:

Correct. It seems weird to me that the final spec includes bytes = that were only used for developing the spec. I acknowledge that it's di= fficult to remove them at this point, but maybe when we introduce the new e= xtension for a new TB version we can avoid this.=C2=A0

It seems weird to me, too.=C2=A0 We cou= ld save 1 of those bytes by saying that the 1.0 version has a 1, and is not= followed by the minor version number.=C2=A0 Since the byte after the versi= on is the client's preferred key parameters, it seems like we need the = 1-byte separation.=C2=A0 I'd be OK with version 1.0 being represented b= y the single byte 0x01, and requiring all implementations to reject TB exte= nsion 24 when the version byte is not 1.

Bill
--94eb2c122fb6f28eab053ae9090b-- From nobody Thu Aug 25 11:14:24 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 ECE3212D5D3 for ; Thu, 25 Aug 2016 11:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 LgobDzR_ziqX for ; Thu, 25 Aug 2016 11:14:21 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0099.outbound.protection.outlook.com [104.47.41.99]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F3912D59E for ; Thu, 25 Aug 2016 11:14:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UF3mK/zgdN+FKYLerzMzMgRFsn7QFONnoVAT6Su3//Y=; b=CqE4YwAOMjNUNLMxzrKSF67Bwf3294+sqLpWX8/wN6x12X81MK1gy/z8hJqWbqujYg/06f1RUCDqegzslWVl8IqrWa9w/aC3aUVlB56L3w7x8dSkWUyyQulT1xyyaFdS5a4t2BHkeCu2Dz4OpmM2SrmASsyVtaF5l2XA6CFo8w8= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Thu, 25 Aug 2016 18:14:17 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Thu, 25 Aug 2016 18:14:17 +0000 From: Andrei Popov To: Bill Cox , Nick Harper Thread-Topic: [Unbearable] TLS extension: version field Thread-Index: AQHR8UE0hAr3fGh5LkSos3djbwbcUaA/MmwAgAAmOoCAAAGk8IAAhvMAgAAFqjCAAAO6AIAA6WmAgAATAoCAABJZgIAV3xfwgAATKACAAFvQgIAAAlRwgAANXQCAAAcGgIAAQVIAgADRnQCAAADEgIAAEkUAgAAEGBCAAAamgIAAAViQgAAZvwCAAAJnAIAAAhEAgAA/qZCAAAhXAIAABsHQgAC/X4CAAChTAIAAHF0wgAAGWoCAAACGQIAABOOAgAAC6QCAAAXLwA== Date: Thu, 25 Aug 2016 18:14:16 +0000 Message-ID: References: <9b0f1cb3-a74b-2637-159c-e7aa3ee53ec6@cs.tcd.ie> <38F8CC64-29B7-4818-B423-F1C7A2939B4D@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: 1f7a1add-e62b-49f9-5f5d-08d3cd13a0b2 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 6:cIgD8BVqnw9sJinCfHFwNXj1/xVz5M249npqV846hBxm6V3QUEpsq5ad6nAIPM9Mn6pzI2ZH9hmeLg/JtxVkYvmdguBITtSDnpbh8zkfT7HdhXv2GM0RB1VH8xYm7FyeYdS0xu4LCQa40LXIUNIaQW8MLOc+cPTdXCBGkrJbzKjNNm6hnfI9FkyTFlwGCvJMNgWYsvkx0x01Pe4fW5Yu1AOsL/AA94Ug+p+YRqzpnWoLOIEUeHiOJsB5z9r1CpDoDNFYDiJAi7xIeEN5IheuoN6alf9+zcilV4U0y+Vy9Tyws0NCKmb3lc+WlUft7HpM9Ii7Dx0mZ5ztyw+5U07P6w==; 5:iNFzdauFPJciWvgMN9xk5ToobjMDaqVo8FB0hlwzG4QcP/pKyAHNfCZb/b0mknVe3RwF3dAgNFbfsWfI8rGyW2PtWOC1wAUc3MyOFWU46nxWMKQsY/tAyGTT+Ohf3Z7zPLvWPTHberl9Phi6JZVRhQ==; 24:8CiyAxF50FeaJjEkOKSVvFe+EttJpF/EoudwSzs9yLO5RCJxdwE5ziVX+VnTKnByP2uK6KNyH4BGftBxNJFRtlhLZhSdXPuO0+i6IOFW5Dk=; 7:NA2OWleDFKUesfcDES9sqNhrnFQ4ah7IF/6ucQ/r+2CX+2fhMfBZAskGQzP9capQ5sMeOKkfLEDY/TjCTOFaguBtxKQ2LIPhRZu8VPswFdHE3uZ1JlJgz7myzO2X+PnTSrRxI2Vp0UkDH4Ky0EjzFoxzdZxGCt7wTaz5JG62xXhhEklZEIdkf6+Ld0kpqis8OohvRc1yL79K3qA+UAErfRA04IDpmpiyQ2hay04jr72HXIuGIHrAA8UKyFyRMZXi x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0842; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 0045236D47 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(377454003)(24454002)(87936001)(74316002)(101416001)(106116001)(50986999)(76176999)(7846002)(9686002)(7736002)(54356999)(8990500004)(10400500002)(7696003)(99286002)(33656002)(68736007)(16236675004)(10090500001)(3660700001)(3280700002)(8676002)(81166006)(8936002)(81156014)(19609705001)(11100500001)(5002640100001)(5660300001)(122556002)(106356001)(86362001)(5001770100001)(15975445007)(77096005)(19625215002)(105586002)(586003)(2906002)(790700001)(6116002)(102836003)(4326007)(76576001)(92566002)(19580405001)(19580395003)(2900100001)(2950100001)(5005710100001)(189998001)(97736004)(86612001)(19300405004)(10290500002)(93886004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB08422B643C578CB82770D2248CED0CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2016 18:14:17.0066 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Cc: "unbearable@ietf.org" , John Bradley , Brian Campbell , Martin Thomson , Leif Johansson , Stephen Farrell Subject: Re: [Unbearable] TLS extension: version field 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, 25 Aug 2016 18:14:24 -0000 --_000_CY1PR0301MB08422B643C578CB82770D2248CED0CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2FuIGJlIGRvbmUsIGJ1dCBkbyB5b3UgcmVhbGx5IHdhbnQgdG8gdmFyeSB0aGUgdG9rZW5fYmlu ZGluZyBleHRlbnNpb24gZm9ybWF0IGJ5IGRyYWZ0IHZzLiBmaW5hbCB2ZXJzaW9uIG51bWJlciwg YW5kIHRlc3QgdGhpcyBjb2RlIG9ubHkgdG8gc2F2ZSAxIGJ5dGU/DQoNCkZyb206IEJpbGwgQ294 IFttYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3Qg MjUsIDIwMTYgMTA6NTEgQU0NClRvOiBOaWNrIEhhcnBlciA8bmhhcnBlckBnb29nbGUuY29tPg0K Q2M6IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+OyBKb2huIEJyYWRs ZXkgPHZlN2p0YkB2ZTdqdGIuY29tPjsgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tPjsgdW5iZWFyYWJsZUBpZXRmLm9yZzsgTWFydGluIFRob21zb24gPG1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbT47IFN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRj ZC5pZT47IExlaWYgSm9oYW5zc29uIDxsZWlmakBzdW5ldC5zZT4NClN1YmplY3Q6IFJlOiBbVW5i ZWFyYWJsZV0gVExTIGV4dGVuc2lvbjogdmVyc2lvbiBmaWVsZA0KDQpPbiBUaHUsIEF1ZyAyNSwg MjAxNiBhdCAxMDo0MCBBTSwgTmljayBIYXJwZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbTxtYWlsdG86 bmhhcnBlckBnb29nbGUuY29tPj4gd3JvdGU6DQoNCkNvcnJlY3QuIEl0IHNlZW1zIHdlaXJkIHRv IG1lIHRoYXQgdGhlIGZpbmFsIHNwZWMgaW5jbHVkZXMgYnl0ZXMgdGhhdCB3ZXJlIG9ubHkgdXNl ZCBmb3IgZGV2ZWxvcGluZyB0aGUgc3BlYy4gSSBhY2tub3dsZWRnZSB0aGF0IGl0J3MgZGlmZmlj dWx0IHRvIHJlbW92ZSB0aGVtIGF0IHRoaXMgcG9pbnQsIGJ1dCBtYXliZSB3aGVuIHdlIGludHJv ZHVjZSB0aGUgbmV3IGV4dGVuc2lvbiBmb3IgYSBuZXcgVEIgdmVyc2lvbiB3ZSBjYW4gYXZvaWQg dGhpcy4NCg0KSXQgc2VlbXMgd2VpcmQgdG8gbWUsIHRvby4gIFdlIGNvdWxkIHNhdmUgMSBvZiB0 aG9zZSBieXRlcyBieSBzYXlpbmcgdGhhdCB0aGUgMS4wIHZlcnNpb24gaGFzIGEgMSwgYW5kIGlz IG5vdCBmb2xsb3dlZCBieSB0aGUgbWlub3IgdmVyc2lvbiBudW1iZXIuICBTaW5jZSB0aGUgYnl0 ZSBhZnRlciB0aGUgdmVyc2lvbiBpcyB0aGUgY2xpZW50J3MgcHJlZmVycmVkIGtleSBwYXJhbWV0 ZXJzLCBpdCBzZWVtcyBsaWtlIHdlIG5lZWQgdGhlIDEtYnl0ZSBzZXBhcmF0aW9uLiAgSSdkIGJl IE9LIHdpdGggdmVyc2lvbiAxLjAgYmVpbmcgcmVwcmVzZW50ZWQgYnkgdGhlIHNpbmdsZSBieXRl IDB4MDEsIGFuZCByZXF1aXJpbmcgYWxsIGltcGxlbWVudGF0aW9ucyB0byByZWplY3QgVEIgZXh0 ZW5zaW9uIDI0IHdoZW4gdGhlIHZlcnNpb24gYnl0ZSBpcyBub3QgMS4NCg0KQmlsbA0K --_000_CY1PR0301MB08422B643C578CB82770D2248CED0CY1PR0301MB0842_ 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 IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNhbiBiZSBkb25lLCBidXQgZG8geW91IHJlYWxseSB3YW50 IHRvIHZhcnkgdGhlIHRva2VuX2JpbmRpbmcgZXh0ZW5zaW9uIGZvcm1hdCBieSBkcmFmdCB2cy4g ZmluYWwgdmVyc2lvbiBudW1iZXIsIGFuZCB0ZXN0IHRoaXMgY29kZSBvbmx5IHRvIHNhdmUgMSBi eXRlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4g QmlsbCBDb3ggW21haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8 L2I+IFRodXJzZGF5LCBBdWd1c3QgMjUsIDIwMTYgMTA6NTEgQU08YnI+DQo8Yj5Ubzo8L2I+IE5p Y2sgSGFycGVyICZsdDtuaGFycGVyQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBBbmRy ZWkgUG9wb3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tJmd0OzsgSm9obiBCcmFkbGV5 ICZsdDt2ZTdqdGJAdmU3anRiLmNvbSZndDs7IEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGxA cGluZ2lkZW50aXR5LmNvbSZndDs7IHVuYmVhcmFibGVAaWV0Zi5vcmc7IE1hcnRpbiBUaG9tc29u ICZsdDttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7OyBTdGVwaGVuIEZhcnJlbGwgJmx0O3N0 ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUmZ3Q7OyBMZWlmIEpvaGFuc3Nvbg0KICZsdDtsZWlmakBz dW5ldC5zZSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBUTFMgZXh0 ZW5zaW9uOiB2ZXJzaW9uIGZpZWxkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEF1ZyAyNSwgMjAxNiBhdCAxMDo0MCBBTSwgTmljayBI YXJwZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpuaGFycGVyQGdvb2dsZS5jb20iIHRhcmdldD0iX2Js YW5rIj5uaGFycGVyQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Db3JyZWN0LiBJdCBzZWVtcyB3ZWlyZCB0byBtZSB0aGF0IHRoZSBmaW5hbCBzcGVjIGlu Y2x1ZGVzIGJ5dGVzIHRoYXQgd2VyZSBvbmx5IHVzZWQgZm9yIGRldmVsb3BpbmcgdGhlIHNwZWMu IEkgYWNrbm93bGVkZ2UgdGhhdCBpdCdzIGRpZmZpY3VsdCB0byByZW1vdmUgdGhlbSBhdCB0aGlz IHBvaW50LCBidXQgbWF5YmUgd2hlbiB3ZSBpbnRyb2R1Y2UgdGhlIG5ldyBleHRlbnNpb24gZm9y IGEgbmV3IFRCIHZlcnNpb24NCiB3ZSBjYW4gYXZvaWQgdGhpcy4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgc2VlbXMgd2VpcmQgdG8gbWUsIHRvby4mbmJzcDsg V2UgY291bGQgc2F2ZSAxIG9mIHRob3NlIGJ5dGVzIGJ5IHNheWluZyB0aGF0IHRoZSAxLjAgdmVy c2lvbiBoYXMgYSAxLCBhbmQgaXMgbm90IGZvbGxvd2VkIGJ5IHRoZSBtaW5vciB2ZXJzaW9uIG51 bWJlci4mbmJzcDsgU2luY2UgdGhlIGJ5dGUgYWZ0ZXIgdGhlIHZlcnNpb24gaXMgdGhlIGNsaWVu dCdzIHByZWZlcnJlZCBrZXkgcGFyYW1ldGVycywgaXQgc2VlbXMgbGlrZQ0KIHdlIG5lZWQgdGhl IDEtYnl0ZSBzZXBhcmF0aW9uLiZuYnNwOyBJJ2QgYmUgT0sgd2l0aCB2ZXJzaW9uIDEuMCBiZWlu ZyByZXByZXNlbnRlZCBieSB0aGUgc2luZ2xlIGJ5dGUgMHgwMSwgYW5kIHJlcXVpcmluZyBhbGwg aW1wbGVtZW50YXRpb25zIHRvIHJlamVjdCBUQiBleHRlbnNpb24gMjQgd2hlbiB0aGUgdmVyc2lv biBieXRlIGlzIG5vdCAxLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5CaWxsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR0301MB08422B643C578CB82770D2248CED0CY1PR0301MB0842_-- From nobody Thu Aug 25 12:27:24 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 0C18D12D549 for ; Thu, 25 Aug 2016 12:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 GXFgCPPVm8IG for ; Thu, 25 Aug 2016 12:27:20 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 9139312D11C for ; Thu, 25 Aug 2016 12:27:20 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id l94so38411738ual.0 for ; Thu, 25 Aug 2016 12:27:20 -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=0T3FQVaMqYsuJHLlQ6eU5wyIzxoj/T9oheCJqWZ2V8Q=; b=THrkQknAV8us51yBD+C7cI0OKUtnSFQ7nFC5phR2f87W0iOwlbcxluQMU8fLFZcXVo 6mPhvt+nA+8yXYHqLDP0ggQm359aQt9XbvYexICefwrxI9unNKSsD/F7BFBUiq2AS5nD sqA7qZmibt1/XAdA4eUY+0auyiabuCepOAuYAD7LpxV0oWOyYBpi9/amEzpU/l+LS8Kw X/ybVjnMZJrgAgKk4aT3+hzE51CHnTeQxp5jW14cJV6fjyEtED6oSPf0MwP7PAXEDiWV hKV9vDhWP8rcy1dki1ZNTeSrx1y2nwLYuQ1R0uAoe43rWZxw466qm2Ef93algBtq3gWJ //Xw== 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=0T3FQVaMqYsuJHLlQ6eU5wyIzxoj/T9oheCJqWZ2V8Q=; b=div58Imgy6/eVO5Rvun5bDIMZZPHxESDPu5UYi2HLBp3cw8DduHuO5PhAEWaZiKT2l JvvJuJrwzy8R8I5/QVwCJ6SWRD+rRX/ziMAYdkHO+UvQcj9y5ezvTDC535HgXTgeNbMB EtDGsTpX9M871zO+VEBeazsYAPGJPlcn0SPVW3scvZKcedkWXFG3uzE1d1qQSigqvBTO N7MtpEuTILXKa4Bepcvn8ljOhrkxDNIS8IpPM2TkyXF8mK+cV8xDlRZiZWRJbZUqggoz p51nkP6jdxXMtLlm3dcUQs69rYVJ3eVmETHo1zJXlNNEla7SRUgTHYYYVl9lHotUPlUE QmVA== X-Gm-Message-State: AEkoouvRk68qMAEQhbjO+jETJw2D1sWwU8Ud4WeIaPyABtE6Y/GOyjbfkK6nq6fbBicdq8tZUIF2Q5akSoDcBDlK X-Received: by 10.176.83.34 with SMTP id x31mr5678050uax.85.1472153239472; Thu, 25 Aug 2016 12:27:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.97.2 with HTTP; Thu, 25 Aug 2016 12:27:18 -0700 (PDT) In-Reply-To: References: <9b0f1cb3-a74b-2637-159c-e7aa3ee53ec6@cs.tcd.ie> <38F8CC64-29B7-4818-B423-F1C7A2939B4D@ve7jtb.com> From: Bill Cox Date: Thu, 25 Aug 2016 12:27:18 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=94eb2c18fcdce52237053aea622d Archived-At: Cc: "unbearable@ietf.org" , John Bradley , Brian Campbell , Martin Thomson , Leif Johansson , Nick Harper , Stephen Farrell Subject: Re: [Unbearable] TLS extension: version field 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, 25 Aug 2016 19:27:22 -0000 --94eb2c18fcdce52237053aea622d Content-Type: text/plain; charset=UTF-8 On Thu, Aug 25, 2016 at 11:14 AM, Andrei Popov wrote: > Can be done, but do you really want to vary the token_binding extension > format by draft vs. final version number, and test this code only to save 1 > byte? > I guess not. My first preference would be to just keep the version field, and kick the issue of whether to use it or not post-1.0 down the road. However, if most people want to us to switch to using new extension numbers rather than the version field, I'm OK with letting them do that, so long as we do it in a way that does not slow down deployment. Bill --94eb2c18fcdce52237053aea622d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 25, 2016 at 11:14 AM, Andrei Popov <Andrei.Popov@microsof= t.com> wrote:

Can be done, but do you really want to vary the tok= en_binding extension format by draft vs. final version number, and test thi= s code only to save 1 byte?


I guess not.=C2=A0 My first preference would be to just keep the ve= rsion field, and kick the issue of whether to use it or not post-1.0 down t= he road.=C2=A0 However, if most people want to us to switch to using new ex= tension numbers rather than the version field, I'm OK with letting them= do that, so long as we do it in a way that does not slow down deployment.<= /div>

Bill=C2=A0
--94eb2c18fcdce52237053aea622d-- From nobody Thu Aug 25 18:01:51 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 2CAF612B016 for ; Thu, 25 Aug 2016 18:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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; domainkeys=pass (1024-bit key) header.sender=andreipo=microsoft.com@github.com 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 5HEeW43kYtVY for ; Thu, 25 Aug 2016 18:01:47 -0700 (PDT) Received: from m71-131.mailgun.net (m71-131.mailgun.net [166.78.71.131]) (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 8FC0512B061 for ; Thu, 25 Aug 2016 18:01:46 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1472173306; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=Y5czNskO+HbIy4rX+bWWb9A2rFGW5R7IkjbOdiLAzzE=; b=fv3CgYJpf72FYzz+fkn6hDO5y716S2h2uHk4ggvzJy5GHZmqk5dLqx0G+5mJVs0egl5VIwvm GaIKdJzFbjiicH8Lbeviec212BHaFoUh9xqjKwHDoM6nUIewD1vcEVUwIIyTgMdemDbCSGbd KBl3u416fRVdhx6Q2j63CHGenvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=Ff3vCTXxo0hsSK9PCGwTh15ShcjO8JrrKldvz5bECTlZ12jBOWaXDRE0nAQt5Apvg4PfZu VFxWt5bCY7XXtMUeaUPQwwqRQE1HmjYT1mJgVttNv44UEPwuwt9ObvOP7HyuxMQL2QBkIny/ 2KchPzN9krp0xdsIRQcGglq9L9+go= Sender: andreipo=microsoft.com@github.com X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Received: from github.com (Unknown [192.30.252.42]) by mxa.mailgun.org with ESMTP id 57bf94f8.7f43cc964990-in07; Fri, 26 Aug 2016 01:01:44 -0000 (UTC) Date: Thu, 25 Aug 2016 18:01:44 -0700 From: Andrei Popov To: unbearable@ietf.org Message-ID: <57bf94f8d375f_1ad03f974e4cb13c879b1@hookshot-fe1-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_57bf94f8d314d_1ad03f974e4cb13c878a"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] ef5e7e: Clarified padding parameters and made signature co... X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Andrei Popov 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, 26 Aug 2016 01:01:50 -0000 ----==_mimepart_57bf94f8d314d_1ad03f974e4cb13c878a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: ef5e7e60cabf96d74888d436cb9311f694dc6e95 https://github.com/TokenBinding/Internet-Drafts/commit/ef5e7e60cabf96d74888d436cb9311f694dc6e95 Author: Andrei Popov Date: 2016-08-25 (Thu, 25 Aug 2016) Changed paths: M draft-ietf-tokbind-protocol-09.xml Log Message: ----------- Clarified padding parameters and made signature cover protocol version and TB type. ----==_mimepart_57bf94f8d314d_1ad03f974e4cb13c878a-- From nobody Fri Aug 26 10:22: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 232C412D1D7 for ; Fri, 26 Aug 2016 10:22:53 -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 3anwvOYlqfIv for ; Fri, 26 Aug 2016 10:22:51 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 C65CF12D1BC for ; Fri, 26 Aug 2016 10:22:51 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id d65so2355825ith.0 for ; Fri, 26 Aug 2016 10:22:51 -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=oMmirWrdIa+yYCFYXHpEklYWTZac0tFCI5zjlsENoSU=; b=g2CHf8H1ha2RTJQAzqHhcCt/5lJINycRHA/lclwxNW88Pu95vutbUYJWd6FXHwu86J xmBUInuVUPohBuayP2Rwe7rhQ/4DWkR0cBebsJBoQOAmb6820O0rLGT5LJ+7gvIIQouc Yu0J8ogsiWPKyu16bmGnQm3w01GzNfd1wMZrY= 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=oMmirWrdIa+yYCFYXHpEklYWTZac0tFCI5zjlsENoSU=; b=i7jelo+J3ZQUGP3Zn4r2Ucqw2Cr8uc3qNEBUwXouiSt+M23q12BL+YhzctI2+x42A1 IU0cVV6Biq2UCAUy44H3p52BG/IhzRD7Lm5cEc4HqFlQmTnjkLsvOixZw2eMyuZuyQdg IW4/2sWmdC+pNp43j4m1a+k4v3/DZRH8Lf+h2PfVTcoCD6I3CPYVnqDWzFvfnLxfT5CU wDqqWce6rBSYRcUKE/5LmY5UiIljuypU/llIUaY8LNQW5NBJIbueFuLT8in7Mv0igRmy q5Y0nefMx8oDqaOH1ai7VYrqM9YJM60Ips3b5uYI9ErIE3p2KgfMsoBGsv51WhYllZJz lYgw== X-Gm-Message-State: AE9vXwOJ9umEmi1ccRu0t6KBgvTICNy7ZxH/UvUQ/emAhd7xQTe3ADZnUf6IdYW2XZ71/qptODzTxvVcLG2t2s/0 X-Received: by 10.107.8.94 with SMTP id 91mr5271261ioi.86.1472232171125; Fri, 26 Aug 2016 10:22:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.114.20 with HTTP; Fri, 26 Aug 2016 10:22:20 -0700 (PDT) In-Reply-To: References: <9b0f1cb3-a74b-2637-159c-e7aa3ee53ec6@cs.tcd.ie> <38F8CC64-29B7-4818-B423-F1C7A2939B4D@ve7jtb.com> From: Brian Campbell Date: Fri, 26 Aug 2016 11:22:20 -0600 Message-ID: To: Nick Harper Content-Type: multipart/alternative; boundary=001a113f3a88965994053afcc3d1 Archived-At: Cc: Andrei Popov , "unbearable@ietf.org" Subject: Re: [Unbearable] TLS extension: version field 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, 26 Aug 2016 17:22:54 -0000 --001a113f3a88965994053afcc3d1 Content-Type: text/plain; charset=UTF-8 +1 FWIW On Thu, Aug 25, 2016 at 11:21 AM, Nick Harper wrote: > My gut feeling is that when we need a new TB version, we'll also need to > change the extension, hence my preference for not having the version in the > extension. However, the version field appears to be too useful for > experimentation to remove it. Given that we're bikeshedding over 2 bytes > per connection, I'm fine keeping it as is and taking the view the the bytes > are fixed at (1,0) once the RFC is published. > > --001a113f3a88965994053afcc3d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 FWIW

On Thu, Aug 25, 2016 at 11:21 AM, Nick Harper <nharper@g= oogle.com> wrote:
My gut feeling is that when we need a new TB version, we= 'll also need to change the extension, hence my preference for not havi= ng the version in the extension. However, the version field appears to be t= oo useful for experimentation to remove it. Given that we're bikesheddi= ng over 2 bytes per connection, I'm fine keeping it as is and taking th= e view the the bytes are fixed at (1,0) once the RFC is published.

=
--001a113f3a88965994053afcc3d1-- From nobody Fri Aug 26 16:02:09 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 A978912B05E for ; Fri, 26 Aug 2016 16:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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; domainkeys=pass (1024-bit key) header.sender=andreipo=microsoft.com@github.com 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 63OxoX8r8pXv for ; Fri, 26 Aug 2016 16:02:07 -0700 (PDT) Received: from m69-170.mailgun.net (m69-170.mailgun.net [166.78.69.170]) (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 31BEB126D74 for ; Fri, 26 Aug 2016 16:02:07 -0700 (PDT) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=github.com; q=dns/txt; s=mailo; t=1472252526; h=Content-Transfer-Encoding: Content-Type: Mime-Version: Subject: Message-ID: To: Reply-To: From: Date: Sender; bh=Jr601bHINAgTYeY305IbT7ALNgz+goa00Z0Moeilqiw=; b=MYeMv2r5CIzY0tjKTEPlakq2OIDsaF3EAhjqWcUIzhYZt5oWydXmx4vAMqDkuVyIiAjXHaLk K2HK5MNGqzEVfqw4CM1bsyy3XLsbalPYf7NBzGBH1RMeqslnjfE51QovVEPZj/LevZ2C9MS/ wZ2D0VeW6zQgPViFvCagrvXsIQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=github.com; s=mailo; q=dns; h=Sender: Date: From: Reply-To: To: Message-ID: Subject: Mime-Version: Content-Type: Content-Transfer-Encoding; b=txX87rb5Y7Ob0AA+WP6YuyH/i3k8h0HI7c/GZ26eilmkP5J0o7/V1hXgOM6/ZI08ztLnZU faDUctJTD5wYcM+eNa75yg8tndBrr2FvHwyv9IDwVHRAilv91LDlqysolgPWGZCJkAObcKUN NI53Nyo1OEqpMODvGi+TEH+MbpoaQ= Sender: andreipo=microsoft.com@github.com X-Mailgun-Sid: WyIzMTNlNyIsICJ1bmJlYXJhYmxlQGlldGYub3JnIiwgIjQwZiJd Received: from github.com (Unknown [192.30.252.41]) by mxa.mailgun.org with ESMTP id 57c0ca6e.7fef75369c30-in07; Fri, 26 Aug 2016 23:02:06 -0000 (UTC) Date: Fri, 26 Aug 2016 16:02:06 -0700 From: Andrei Popov To: unbearable@ietf.org Message-ID: <57c0ca6e24b85_62753fad14061138517e6@hookshot-fe5-cp1-prd.iad.github.net.mail> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="--==_mimepart_57c0ca6e2472f_62753fad1406113851625"; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Unbearable] [TokenBinding/Internet-Drafts] daa71b: Added TB key length field, included TB key paramet... X-BeenThere: unbearable@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Andrei Popov 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, 26 Aug 2016 23:02:09 -0000 ----==_mimepart_57c0ca6e2472f_62753fad1406113851625 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Branch: refs/heads/master Home: https://github.com/TokenBinding/Internet-Drafts Commit: daa71b5d7eb733ea539eb2af0eb275324752cf4a https://github.com/TokenBinding/Internet-Drafts/commit/daa71b5d7eb733ea539eb2af0eb275324752cf4a Author: Andrei Popov Date: 2016-08-26 (Fri, 26 Aug 2016) Changed paths: M draft-ietf-tokbind-https-06.xml M draft-ietf-tokbind-negotiation-04.xml M draft-ietf-tokbind-protocol-09.xml Log Message: ----------- Added TB key length field, included TB key parameters under the signature, addressed editorial comments. Commit: 21dc85a3a51fe900d803d9a02a3670fd289ae0b7 https://github.com/TokenBinding/Internet-Drafts/commit/21dc85a3a51fe900d803d9a02a3670fd289ae0b7 Author: Andrei Popov Date: 2016-08-26 (Fri, 26 Aug 2016) Changed paths: M draft-ietf-tokbind-https-06.xml M draft-ietf-tokbind-negotiation-04.xml M draft-ietf-tokbind-protocol-09.xml Log Message: ----------- Added TB key length field, included TB key parameters under the signature, addressed editorial comments. Compare: https://github.com/TokenBinding/Internet-Drafts/compare/ef5e7e60cabf...21dc85a3a51f ----==_mimepart_57c0ca6e2472f_62753fad1406113851625-- From nobody Fri Aug 26 16:14:47 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 6D4A0126D74; Fri, 26 Aug 2016 16:14:45 -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.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147225328544.28459.6514701787605476524.idtracker@ietfa.amsl.com> Date: Fri, 26 Aug 2016 16:14:45 -0700 Archived-At: Cc: unbearable@ietf.org Subject: [Unbearable] I-D Action: draft-ietf-tokbind-https-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, 26 Aug 2016 23:14:45 -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 : Token Binding over HTTP Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Jeff Hodges Filename : draft-ietf-tokbind-https-06.txt Pages : 21 Date : 2016-08-26 Abstract: This document describes a collection of mechanisms that allow HTTP servers to cryptographically bind authentication tokens (such as cookies and OAuth tokens) to TLS [RFC5246] connections. We describe both _first-party_ and _federated_ scenarios. In a first-party scenario, an HTTP server is able to cryptographically bind the security tokens it issues to a client, and which the client subsequently returns to the server, to the TLS connection between the client and server. Such bound security tokens are protected from misuse since the server can generally detect if they are replayed inappropriately, e.g., over other TLS connections. Federated token bindings, on the other hand, allow servers to cryptographically bind security tokens to a TLS connection that the client has with a _different_ server than the one issuing the token. This Internet-Draft is a companion document to The Token Binding Protocol [I-D.ietf-tokbind-protocol] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-https/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tokbind-https-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-https-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 Aug 26 16:16:33 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 2567A12D198; Fri, 26 Aug 2016 16:16:30 -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.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147225339014.28374.4579543686161081174.idtracker@ietfa.amsl.com> Date: Fri, 26 Aug 2016 16:16:30 -0700 Archived-At: Cc: unbearable@ietf.org Subject: [Unbearable] I-D Action: draft-ietf-tokbind-negotiation-04.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, 26 Aug 2016 23:16:30 -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 : Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation Authors : Andrei Popov Magnus Nyström Dirk Balfanz Adam Langley Filename : draft-ietf-tokbind-negotiation-04.txt Pages : 8 Date : 2016-08-26 Abstract: This document specifies a Transport Layer Security (TLS) [RFC5246] extension for the negotiation of Token Binding protocol [I-D.ietf-tokbind-protocol] version and key parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tokbind-negotiation/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-negotiation-04 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 Aug 26 16:17:44 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 34E4112D188; Fri, 26 Aug 2016 16:17:43 -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.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147225346321.28458.13173565689964025556.idtracker@ietfa.amsl.com> Date: Fri, 26 Aug 2016 16:17:43 -0700 Archived-At: Cc: unbearable@ietf.org Subject: [Unbearable] I-D Action: draft-ietf-tokbind-protocol-09.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, 26 Aug 2016 23:17:43 -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-09.txt Pages : 17 Date : 2016-08-26 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 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-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tokbind-protocol-09 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 Aug 26 16:49:16 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 021FD12D843 for ; Fri, 26 Aug 2016 16:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 J6xC6eu0zz54 for ; Fri, 26 Aug 2016 16:49:13 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0134.outbound.protection.outlook.com [104.47.38.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC2E912D660 for ; Fri, 26 Aug 2016 16:49:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FyYjbQX7Id+3magC6EzdAYFG16ApjwGvOdoDc8U9LZc=; b=PTIC4s+J8hNXaGja/Wl8nwxpl0X/5Bef5TXEYufC+sN1/23BVg5b2meQfZEMyKQZALTdxzT8/Kyv2hk8v3wg74JIr+0kdZNH3Jq8edeelZ4weXFeCjF+n7ne31AnXbGkL83lb3yREOUDD91874Y3raQyKJx3UOus3spWAamEWJo= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Fri, 26 Aug 2016 23:49:10 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Fri, 26 Aug 2016 23:49:10 +0000 From: Andrei Popov To: "unbearable@ietf.org" Thread-Topic: Updated Internet-Drafts Thread-Index: AdH/8FJVnFYbwGbARVSCqPVZRLNKmQ== Date: Fri, 26 Aug 2016 23:49:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:8::1d2] x-ms-office365-filtering-correlation-id: ac8b2d69-714e-4d59-d5e4-08d3ce0b938e x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 6:WgtZRaLfLHd3t4jaPoRQlWMp1jMEyrtzXZDne/wcvJygtE/bA+zpEuDcFFsNdHH5rakUuUiWt3X+jLm4fZ9eMR2ulKTMj3m/CANf8IhG8p4ZDO2JQjCDJqP//fnqm3d2PHd3F5KYMW2ChmJ+m1bqSRtSzq7hkWrD4W0Z3P6XSvvSStyHAVcH8D29LA/8GrKoiXBUghECLzwqrLjRHSgdnxr9SFMoKIR3t2dizHa3DBXuI60fXxROE4pg28V1au2TEk+6YforHsAPf83vrlQqE8JDtPP+BJx5xT9a449VaOz33fEnHyEKfMAUgfVPz75ULfTyKjrdL6TalKztyPR+0g==; 5:HykzDiQ7XnrejR6tUNLrIy3mg0uBhb0/30y+H0TR4Evn93nRnRXCpdYdoExa2eWqXKIHMKz91hrHmGc8saFMTWcGnGKA095H6si3bvg/YTWUGWKSkY3p8Az/4RhRIaMJ7EmnPELf6tAyQk4wo6CKyw==; 24:AX73r3BuwnIe8n/N7/oNx737i3pzPZc5VVwBkaN4FzXfmV7hSiDo2z9eURLpo5TptMAOqCCDaGBEzDNjcq8ZfSRcWxDvUzpgiIpRDx1z0dE=; 7:s/VaJlqvSaLRE1NndRuCxeiqp9lywO0JJPyuXLXoiSYg98qC3ePKCZa8pO1THjX+xx714guweclwDY34uPK9YFAIfFwICtPiKwOt38YapFmMLQAGcMIHF77q0NB2V5rqTe66QjXJ+OGNh8zNImH3TyOIR0KWcDp5CPwh9k8E0ZiQjLK5jYrprNVxOfRjn4kRywDy9Tx9bL8lVZuJpSEA3O47yohXfQH6aU/AhYf/msWeuErMPA56/wPgDE2tiMXa x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0842; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 00462943DE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(87936001)(74316002)(2420400007)(15650500001)(50986999)(101416001)(7846002)(8990500004)(5630700001)(10400500002)(7696003)(7906003)(9686002)(7736002)(5640700001)(54356999)(1730700003)(11100500001)(33656002)(16236675004)(68736007)(99286002)(8676002)(81156014)(8936002)(3280700002)(10090500001)(3660700001)(81166006)(5002640100001)(2501003)(106356001)(5660300001)(86362001)(10710500007)(122556002)(77096005)(76576001)(2351001)(229853001)(105586002)(19625215002)(2906002)(586003)(790700001)(6116002)(102836003)(15975445007)(110136002)(92566002)(86612001)(19300405004)(97736004)(7110500001)(189998001)(19580395003)(10290500002)(19617315012)(107886002)(2900100001)(5005710100001)(450100001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842521C3DDF54DD7E1BDE038CEC0CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2016 23:49:10.2563 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Subject: [Unbearable] Updated Internet-Drafts 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, 26 Aug 2016 23:49:15 -0000 --_000_CY1PR0301MB0842521C3DDF54DD7E1BDE038CEC0CY1PR0301MB0842_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The updated TBNEGO-04, TBPROTO-09, and HTTPSTB-06 include the accumulated PRs and address a variety of GitHub issues. Notable changes: 1. TBNEGO-04 uses the TLS extension code point 24 (temporarily assign= ed by IANA). 2. TBPROTO-09 adds TokenBindingID.key_length field, so that TB IDs wi= th unknown key parameters can be skipped. 3. TBPROTO-09 signs new parameters (label, protocol version, TB type = and TB key parameters), in addition to the EKM. 4. TBPROTO-09 clarifies the parameters of the PKCS and PSS padding al= gorithms. 5. HTTPSTB-06 further clarifies the details of base64url encoding. 6. HTTPSTB-06 explicitly states that the Include-Referred-Token-Bindi= ng-ID header is honored even when eTLD+1 of the RP is the same as that of t= he IDP. 7. HTTPSTB-06 includes the API language we discussed in Berlin. Please review the updated documents, Thanks, Andrei --_000_CY1PR0301MB0842521C3DDF54DD7E1BDE038CEC0CY1PR0301MB0842_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The updated TBNEGO-04, TBPROTO-09, and HTTPSTB-06 include the accumulated PRs and address a variety of GitHub = issues.

 

Notable changes:

1.     &= nbsp; TBNEGO-04 uses the TLS extension code point 24 (tem= porarily assigned by IANA).

2.     &= nbsp; TBPROTO-09 adds TokenBindingID.key_length field, so= that TB IDs with unknown key parameters can be skipped.

3.     &= nbsp; TBPROTO-09 signs new parameters (label, protocol ve= rsion, TB type and TB key parameters), in addition to the EKM.

4.     &= nbsp; TBPROTO-09 clarifies the parameters of the PKCS and= PSS padding algorithms.

5.     &= nbsp; HTTPSTB-06 further clarifies the details of base64u= rl encoding.

6.     &= nbsp; HTTPSTB-06 explicitly states that the Include-Refer= red-Token-Binding-ID header is honored even when eTLD+1 of the RP is th= e same as that of the IDP.

7.     &= nbsp; HTTPSTB-06 includes the API language we discussed i= n Berlin.

 

Please review the updated documents,

 

Thanks,

 

Andrei

--_000_CY1PR0301MB0842521C3DDF54DD7E1BDE038CEC0CY1PR0301MB0842_-- From nobody Tue Aug 30 10:11:48 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 6D44812D125 for ; Tue, 30 Aug 2016 10:11:47 -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, 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 Fizrrwm5-bYK for ; Tue, 30 Aug 2016 10:11:45 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 5043B12B04B for ; Tue, 30 Aug 2016 10:11:45 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id e63so177101120ith.1 for ; Tue, 30 Aug 2016 10:11:45 -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=t6sL0SNwrnGd7c6V+OvuRopE71vHYVvkgpbZxyYeoZ0=; b=OwJYXPpHgCBfCPzoaOOqvfb0uxMYnXe4htj9srMg12ckzFiQ3tuATpv8Bf0ZUM1ykz tALcmemvn8AbPfQBrXraaE7Yepm33gMCswhV8mqEELXrjQgYR3MEdWF/TvyAJkX/6+jS 9z3zio3N/yHnKKPC5drYp9K5jnwjOV0A5H0C0= 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=t6sL0SNwrnGd7c6V+OvuRopE71vHYVvkgpbZxyYeoZ0=; b=DImdx2y7HyGpDfhDg5MuQf8+2D/qGb1ybbjyyP08V+eRhct+maKEREYQw7kKePIDqr Jpj+FcDFDggdLhC5BR23Buq8jmsbtDcCKuBf5SQ9ADSfV6xvLzwQCZBzeI7hMf6onHHf WspzCuIY8mjBjx3ro9UMp8Kx4P4/luazRF8c9FSqhNeJWKO3OU5NbhTy/aaMI0JhuA/4 YTUkW1BUfbaIunmSzUbd7tExaMIR/zT+9iHtXPGnkj9qV030jRuX30g152tbOBWUhB8D cYxEh4C5P14wapN89FMvl5mpLVloRu91cUF2z8RfABfcTzOvNkhHhdiUP521c3ZbHs1f 8pBQ== X-Gm-Message-State: AE9vXwPv/a38sqaH9OwgJLKHoDJne/7S+zEWbm+DhIYt4ehux5yxAXnkEXCAx85+A6MczUE6dXKcQcdNBu9W2Bk0 X-Received: by 10.36.84.135 with SMTP id t129mr26511807ita.63.1472577104242; Tue, 30 Aug 2016 10:11:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.114.20 with HTTP; Tue, 30 Aug 2016 10:11:13 -0700 (PDT) From: Brian Campbell Date: Tue, 30 Aug 2016 11:11:13 -0600 Message-ID: To: IETF Tokbind WG Content-Type: multipart/alternative; boundary=001a1143d92234141e053b4d136a Archived-At: Subject: [Unbearable] Hashing & signatures in TBPROTO-9 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, 30 Aug 2016 17:11:47 -0000 --001a1143d92234141e053b4d136a Content-Type: text/plain; charset=UTF-8 Resulting from issues #67 and #70 (I think anyway) are some new rules for calculating the Token Binding signature (mostly in sec 3.3 of TBPROTO-9 ). The signature is now computed over the SHA256 hash of the concatenation of a few of things (label, version, type, key params, EKM). And both RSA signature schemes 'MUST use the SHA256 hash algorithm'. While, when an ecdsap256 key is used, ECDSA with P-256 is used with no hash algorithm. I guess my question is, now that the signature input is larger than just the 32 byte EKM and the RSA algs are using SHA256, wouldn't it make sense and be more consistent to use the concatenation of those items directly as the input into the signature and, when an ecdsap256 key is used, calculate the signature with ECDSA using P-256 and SHA256? That'd mean that TBPROTO wouldn't directly use SHA256 but rather the hashing is pushed into the definition of how to do the signature for each key parameters type, which is arguably more cryptographically agile. It'd also be one less round of hashing for the RSA signature schemes. Or am I off the rails here? --001a1143d92234141e053b4d136a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Resulting from issues #67 and #70 (I think anyway) are = some new rules for calculating the Token Binding signature (mostly in sec 3.3 of TBPROTO-9). The signature is now computed over the SHA256= hash of the concatenation of a few of things (label, version, type, key pa= rams, EKM). And both RSA signature schemes 'MUST use the SHA256 hash al= gorithm'. While, when an ecdsap256 key is used, ECDSA with P-256 is use= d with no hash algorithm.

I guess my question is, now tha= t the signature input is larger than just the 32 byte EKM and the RSA algs = are using SHA256, wouldn't it make sense and be more consistent to use = the concatenation of those items directly as the input into the signature a= nd, when an ecdsap256 key is used, calculate the signature with ECDSA using= P-256 and SHA256? That'd mean that TBPROTO wouldn't directly use S= HA256 but rather the hashing is pushed into the definition of how to do the= signature for each key parameters type, which is arguably more cryptograph= ically agile. It'd also be one less round of hashing for the RSA signat= ure schemes.

Or am I off the rails here?




--001a1143d92234141e053b4d136a-- From nobody Tue Aug 30 11:27: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 EFAB612D7BE for ; Tue, 30 Aug 2016 11:27:31 -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 XSz8gOZMXjJI for ; Tue, 30 Aug 2016 11:27:30 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0120.outbound.protection.outlook.com [104.47.42.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310B512D75E for ; Tue, 30 Aug 2016 11:27:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=J17vpBe0b8SE9tRtrlRtrVQxYcTqU8H/2XJbNA//QKw=; b=ldRxhHeOpxEWowBCFAe6B7pIf2z3pKqbZWQiQBGwzbaUlueKBEzDMuwHd16xeMbpUmFgkkzgLjlaU4nPKrOP86+79YCTOL+Px6OMvt5axfU/vyVPkU1wFFVbLNR8sgEyq4l/M/2nFCe7erGfIQ2ggbuBKQC/30VGxLrh39Eijiw= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0843.namprd03.prod.outlook.com (10.160.163.149) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Tue, 30 Aug 2016 18:27:26 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Tue, 30 Aug 2016 18:27:27 +0000 From: Andrei Popov To: Brian Campbell , IETF Tokbind WG Thread-Topic: [Unbearable] Hashing & signatures in TBPROTO-9 Thread-Index: AQHSAuGcxIQ0j5CaOEOdydsG7FDI+qBhz61g Date: Tue, 30 Aug 2016 18:27:27 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 801607b7-55f6-4bf5-dbc5-08d3d1034b9d x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0843; 6:EkWGntSnZ6F9Ty/4qvzNe8qZ0CawWD5uNvxV3Q6GUWgrl2fl3xQSbxNTeQ7Do4EW9zjxFcKXl0xst5faGHHV+BY/9GPkxHwwBScpvxQ0TvrvuKRFjpQGiUuSY1SIoWM3T/RCz6V5nLoeK1mrFOXsFoMWgd7B27mjSvF9/MGBNve3liwjJxsqjKbiO4fNXWkAPOJs6G9omB1NKfSPuvPQte3RYA56Rlm+JndE8pohOvkioCtN242dyIVAqeS3mCR8lV2AMJlRI8JqbJI9775NaJmcCoUSl/8hkCIhlpiB6rT70xH1do1mrzjr/G3/eji+wDLWTc50GvKpOMVSPtAWuw==; 5:2z0536BweyiHqE75sWowqp8XN5bU+kT1BVoKKcZh404eF9b9hPub0igUNUClwC4aT7g42Rx8rqqb3GzzHwOZpPDc/awIXVpJWkfQJoP1QKvephnOZLU6165kyDzkZRtKI3RBQ8jB3sDM4Ls8nDqGmQ==; 24:Se1+61u41mgLhMKDR0s/+oXZK3pjMz6seAtwM+NvCifYTLa+QC/uuaqOczBp2Kg9zqXicPS6CKNluJKHI6HlbE8NIDZ2yU1FW6Sy7BOv2WU=; 7:ms85HPH7O7jvQiKhtl4KMAZ5rCU+ahmjfBLv126JNJ4Yhx8ijq+1l3Tv0nJUu5i3B05F0+p0EFzQP7E1zyzIf2xBAtWDjIzqiTYfAV3wgIxvpCMgdH2xbrlfHGzPMUZeDFfUdYFTDjkMgs2tUOdepzTqmOeyU1TfeORONeac8D5tTTnIRpKQMhzKBfhuq4WsNi6DIpE6GtpCanru6Yomp237So34nXGKYiFEHS2c3M+7Bh/7iA4BVrOI92lwjXU7 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0843; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0843; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0843; x-forefront-prvs: 0050CEFE70 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(199003)(10090500001)(6116002)(790700001)(102836003)(5001770100001)(97736004)(74316002)(76176999)(54356999)(10290500002)(106356001)(107886002)(87936001)(586003)(50986999)(16236675004)(19625215002)(99286002)(189998001)(86362001)(10400500002)(122556002)(5005710100001)(2906002)(19580395003)(106116001)(19617315012)(33656002)(8936002)(8990500004)(9686002)(19580405001)(92566002)(105586002)(77096005)(81166006)(81156014)(68736007)(5660300001)(76576001)(2950100001)(15975445007)(19300405004)(7846002)(2900100001)(86612001)(5002640100001)(3280700002)(3660700001)(7736002)(7696003)(7906003)(101416001)(8676002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0843; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB084257DD6C3A52CB7D3EDEC38CE00CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2016 18:27:27.1204 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0843 Archived-At: Subject: Re: [Unbearable] Hashing & signatures in TBPROTO-9 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, 30 Aug 2016 18:27:32 -0000 --_000_CY1PR0301MB084257DD6C3A52CB7D3EDEC38CE00CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEFuZCBib3RoIFJTQSBzaWduYXR1cmUgc2NoZW1lcyAnTVVTVCB1c2UgdGhlIFNIQTI1NiBo YXNoIGFsZ29yaXRobScuIFdoaWxlLCB3aGVuIGFuIGVjZHNhcDI1NiBrZXkgaXMgdXNlZCwgRUNE U0Egd2l0aCBQLTI1NiBpcyB1c2VkIHdpdGggbm8gaGFzaCBhbGdvcml0aG0uDQoNClBTUyBhbmQg UEtDUyBwYWRkaW5nIHNjaGVtZXMgYXJlIGRlZmluZWQgd2l0aCBhIGxvdCBvZiBmbGV4aWJpbGl0 eSwgc28gd2UgaGF2ZSB0byBzcGVjaWZ5IHRoZSBoYXNoIGZ1bmN0aW9uIHRvIGJlIHVzZWQgYnkg dGhlc2UgcGFkZGluZyBzY2hlbWVzLg0KRUNEU0Egc2lnbmluZyBkb2VzIG5vdCByZXF1aXJlIHBh ZGRpbmcsIHNvIHRoZXJlIGlzIG5vIG5lZWQgdG8gc3BlY2lmeSB0aGUgaGFzaCBhbGdvcml0aG0u DQoNCg0Kw5ggIFRoZSBzaWduYXR1cmUgaXMgbm93IGNvbXB1dGVkIG92ZXIgdGhlIFNIQTI1NiBo YXNoIG9mIHRoZSBjb25jYXRlbmF0aW9uIG9mIGEgZmV3IG9mIHRoaW5ncyAobGFiZWwsIHZlcnNp b24sIHR5cGUsIGtleSBwYXJhbXMsIEVLTSkuDQpDb3JyZWN0LCB0aGlzIGlzIHRvIHByZXZlbnQg cG90ZW50aWFsIGF0dGFja3MgdGhhdCBmb2xrcyBoYXZlIHBvaW50ZWQgb3V0LiBUaGlzIGlzIGlu ZGVwZW5kZW50IG9mIHRoZSBzaWduYXR1cmUgYWxnb3JpdGhtcyBhbmQgcGFkZGluZyBzY2hlbWVz IHRoYXQgd2UgbmVnb3RpYXRlIHZpYSBUQiBrZXkgcGFyYW1ldGVycy4NCg0KRG9lcyB0aGlzIG1h a2Ugc2Vuc2U/DQoNCkNoZWVycywNCg0KQW5kcmVpDQoNCkZyb206IFVuYmVhcmFibGUgW21haWx0 bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBDYW1wYmVs bA0KU2VudDogVHVlc2RheSwgQXVndXN0IDMwLCAyMDE2IDEwOjExIEFNDQpUbzogSUVURiBUb2ti aW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogW1VuYmVhcmFibGVdIEhhc2hp bmcgJiBzaWduYXR1cmVzIGluIFRCUFJPVE8tOQ0KDQpSZXN1bHRpbmcgZnJvbSBpc3N1ZXMgIzY3 PGh0dHBzOi8vZ2l0aHViLmNvbS9Ub2tlbkJpbmRpbmcvSW50ZXJuZXQtRHJhZnRzL2lzc3Vlcy82 Nz4gYW5kICM3MDxodHRwczovL2dpdGh1Yi5jb20vVG9rZW5CaW5kaW5nL0ludGVybmV0LURyYWZ0 cy9pc3N1ZXMvNzA+IChJIHRoaW5rIGFueXdheSkgYXJlIHNvbWUgbmV3IHJ1bGVzIGZvciBjYWxj dWxhdGluZyB0aGUgVG9rZW4gQmluZGluZyBzaWduYXR1cmUgKG1vc3RseSBpbiBzZWMgMy4zIG9m IFRCUFJPVE8tOTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10b2tiaW5k LXByb3RvY29sLTA5I3NlY3Rpb24tMy4zPikuIFRoZSBzaWduYXR1cmUgaXMgbm93IGNvbXB1dGVk IG92ZXIgdGhlIFNIQTI1NiBoYXNoIG9mIHRoZSBjb25jYXRlbmF0aW9uIG9mIGEgZmV3IG9mIHRo aW5ncyAobGFiZWwsIHZlcnNpb24sIHR5cGUsIGtleSBwYXJhbXMsIEVLTSkuIEFuZCBib3RoIFJT QSBzaWduYXR1cmUgc2NoZW1lcyAnTVVTVCB1c2UgdGhlIFNIQTI1NiBoYXNoIGFsZ29yaXRobScu IFdoaWxlLCB3aGVuIGFuIGVjZHNhcDI1NiBrZXkgaXMgdXNlZCwgRUNEU0Egd2l0aCBQLTI1NiBp cyB1c2VkIHdpdGggbm8gaGFzaCBhbGdvcml0aG0uDQpJIGd1ZXNzIG15IHF1ZXN0aW9uIGlzLCBu b3cgdGhhdCB0aGUgc2lnbmF0dXJlIGlucHV0IGlzIGxhcmdlciB0aGFuIGp1c3QgdGhlIDMyIGJ5 dGUgRUtNIGFuZCB0aGUgUlNBIGFsZ3MgYXJlIHVzaW5nIFNIQTI1Niwgd291bGRuJ3QgaXQgbWFr ZSBzZW5zZSBhbmQgYmUgbW9yZSBjb25zaXN0ZW50IHRvIHVzZSB0aGUgY29uY2F0ZW5hdGlvbiBv ZiB0aG9zZSBpdGVtcyBkaXJlY3RseSBhcyB0aGUgaW5wdXQgaW50byB0aGUgc2lnbmF0dXJlIGFu ZCwgd2hlbiBhbiBlY2RzYXAyNTYga2V5IGlzIHVzZWQsIGNhbGN1bGF0ZSB0aGUgc2lnbmF0dXJl IHdpdGggRUNEU0EgdXNpbmcgUC0yNTYgYW5kIFNIQTI1Nj8gVGhhdCdkIG1lYW4gdGhhdCBUQlBS T1RPIHdvdWxkbid0IGRpcmVjdGx5IHVzZSBTSEEyNTYgYnV0IHJhdGhlciB0aGUgaGFzaGluZyBp cyBwdXNoZWQgaW50byB0aGUgZGVmaW5pdGlvbiBvZiBob3cgdG8gZG8gdGhlIHNpZ25hdHVyZSBm b3IgZWFjaCBrZXkgcGFyYW1ldGVycyB0eXBlLCB3aGljaCBpcyBhcmd1YWJseSBtb3JlIGNyeXB0 b2dyYXBoaWNhbGx5IGFnaWxlLiBJdCdkIGFsc28gYmUgb25lIGxlc3Mgcm91bmQgb2YgaGFzaGlu ZyBmb3IgdGhlIFJTQSBzaWduYXR1cmUgc2NoZW1lcy4NCk9yIGFtIEkgb2ZmIHRoZSByYWlscyBo ZXJlPw0KDQoNCg0KDQo= --_000_CY1PR0301MB084257DD6C3A52CB7D3EDEC38CE00CY1PR0301MB0842_ 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 OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt Y29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRp b25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNTQ4NzgzNjA7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi03Mjc5Njg0MjggLTI2Nzc2MTkyMiA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjIw NjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OY Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K b2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpX aW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT5BbmQgYm90aCBSU0Egc2lnbmF0dXJlIHNjaGVtZXMgJ01VU1Qg dXNlIHRoZSBTSEEyNTYgaGFzaCBhbGdvcml0aG0nLiBXaGlsZSwgd2hlbiBhbiBlY2RzYXAyNTYg a2V5IGlzIHVzZWQsIEVDRFNBIHdpdGggUC0yNTYgaXMgdXNlZCB3aXRoIG5vIGhhc2ggYWxnb3Jp dGhtLjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlBTUyBhbmQgUEtDUyBwYWRkaW5n IHNjaGVtZXMgYXJlIGRlZmluZWQgd2l0aCBhIGxvdCBvZiBmbGV4aWJpbGl0eSwgc28gd2UgaGF2 ZSB0byBzcGVjaWZ5IHRoZSBoYXNoIGZ1bmN0aW9uIHRvIGJlIHVzZWQgYnkgdGhlc2UgcGFkZGlu ZyBzY2hlbWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RUNEU0Egc2lnbmluZyBkb2VzIG5vdCByZXF1aXJlIHBhZGRpbmcsIHNv IHRoZXJlIGlzIG5vIG5lZWQgdG8gc3BlY2lmeSB0aGUgaGFzaCBhbGdvcml0aG0uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6V2lu Z2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+VGhlIHNpZ25hdHVyZSBpcyBub3cgY29tcHV0ZWQgb3ZlciB0aGUg U0hBMjU2IGhhc2ggb2YgdGhlIGNvbmNhdGVuYXRpb24gb2YgYSBmZXcgb2YgdGhpbmdzIChsYWJl bCwgdmVyc2lvbiwgdHlwZSwga2V5IHBhcmFtcywgRUtNKS48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Q29ycmVjdCwgdGhpcyBpcyB0byBwcmV2ZW50IHBvdGVudGlhbCBhdHRhY2tzIHRoYXQgZm9sa3Mg aGF2ZSBwb2ludGVkIG91dC4gVGhpcyBpcyBpbmRlcGVuZGVudCBvZiB0aGUgc2lnbmF0dXJlIGFs Z29yaXRobXMgYW5kIHBhZGRpbmcgc2NoZW1lcyB0aGF0IHdlIG5lZ290aWF0ZSB2aWEgVEIga2V5 DQogcGFyYW1ldGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RG9lcyB0aGlzIG1ha2Ugc2Vuc2U/PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kcmVpPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBVbmJlYXJhYmxlIFttYWlsdG86dW5i ZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBDYW1w YmVsbDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMzAsIDIwMTYgMTA6MTEgQU08 YnI+DQo8Yj5Ubzo8L2I+IElFVEYgVG9rYmluZCBXRyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1VuYmVhcmFibGVdIEhhc2hpbmcgJmFtcDsgc2lnbmF0 dXJlcyBpbiBUQlBST1RPLTk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5SZXN1bHRpbmcgZnJvbSBpc3N1ZXMg PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL1Rva2VuQmluZGluZy9JbnRlcm5ldC1EcmFmdHMv aXNzdWVzLzY3Ij4NCiM2NzwvYT4gYW5kIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9Ub2tl bkJpbmRpbmcvSW50ZXJuZXQtRHJhZnRzL2lzc3Vlcy83MCI+IzcwPC9hPiAoSSB0aGluayBhbnl3 YXkpIGFyZSBzb21lIG5ldyBydWxlcyBmb3IgY2FsY3VsYXRpbmcgdGhlIFRva2VuIEJpbmRpbmcg c2lnbmF0dXJlIChtb3N0bHkgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXRva2JpbmQtcHJvdG9jb2wtMDkjc2VjdGlvbi0zLjMiPg0Kc2VjIDMuMyBv ZiBUQlBST1RPLTk8L2E+KS4gVGhlIHNpZ25hdHVyZSBpcyBub3cgY29tcHV0ZWQgb3ZlciB0aGUg U0hBMjU2IGhhc2ggb2YgdGhlIGNvbmNhdGVuYXRpb24gb2YgYSBmZXcgb2YgdGhpbmdzIChsYWJl bCwgdmVyc2lvbiwgdHlwZSwga2V5IHBhcmFtcywgRUtNKS4gQW5kIGJvdGggUlNBIHNpZ25hdHVy ZSBzY2hlbWVzICdNVVNUIHVzZSB0aGUgU0hBMjU2IGhhc2ggYWxnb3JpdGhtJy4gV2hpbGUsIHdo ZW4gYW4gZWNkc2FwMjU2IGtleQ0KIGlzIHVzZWQsIEVDRFNBIHdpdGggUC0yNTYgaXMgdXNlZCB3 aXRoIG5vIGhhc2ggYWxnb3JpdGhtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIGd1ZXNzIG15 IHF1ZXN0aW9uIGlzLCBub3cgdGhhdCB0aGUgc2lnbmF0dXJlIGlucHV0IGlzIGxhcmdlciB0aGFu IGp1c3QgdGhlIDMyIGJ5dGUgRUtNIGFuZCB0aGUgUlNBIGFsZ3MgYXJlIHVzaW5nIFNIQTI1Niwg d291bGRuJ3QgaXQgbWFrZSBzZW5zZSBhbmQgYmUgbW9yZSBjb25zaXN0ZW50IHRvIHVzZSB0aGUg Y29uY2F0ZW5hdGlvbiBvZiB0aG9zZSBpdGVtcw0KIGRpcmVjdGx5IGFzIHRoZSBpbnB1dCBpbnRv IHRoZSBzaWduYXR1cmUgYW5kLCB3aGVuIGFuIGVjZHNhcDI1NiBrZXkgaXMgdXNlZCwgY2FsY3Vs YXRlIHRoZSBzaWduYXR1cmUgd2l0aCBFQ0RTQSB1c2luZyBQLTI1NiBhbmQgU0hBMjU2PyBUaGF0 J2QgbWVhbiB0aGF0IFRCUFJPVE8gd291bGRuJ3QgZGlyZWN0bHkgdXNlIFNIQTI1NiBidXQgcmF0 aGVyIHRoZSBoYXNoaW5nIGlzIHB1c2hlZCBpbnRvIHRoZSBkZWZpbml0aW9uIG9mIGhvdyB0byBk bw0KIHRoZSBzaWduYXR1cmUgZm9yIGVhY2gga2V5IHBhcmFtZXRlcnMgdHlwZSwgd2hpY2ggaXMg YXJndWFibHkgbW9yZSBjcnlwdG9ncmFwaGljYWxseSBhZ2lsZS4gSXQnZCBhbHNvIGJlIG9uZSBs ZXNzIHJvdW5kIG9mIGhhc2hpbmcgZm9yIHRoZSBSU0Egc2lnbmF0dXJlIHNjaGVtZXMuDQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9yIGFtIEkg b2ZmIHRoZSByYWlscyBoZXJlPyA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_CY1PR0301MB084257DD6C3A52CB7D3EDEC38CE00CY1PR0301MB0842_-- From nobody Tue Aug 30 13:41: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 E1C7A12D80F for ; Tue, 30 Aug 2016 13:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 JIDp66_akIss for ; Tue, 30 Aug 2016 13:41:43 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 4BD5412B05D for ; Tue, 30 Aug 2016 13:41:43 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id l94so54287481ual.0 for ; Tue, 30 Aug 2016 13:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=Mv51v+TECsPP/RIZ7TYDQgoile97O8RHwHlh2jMm4bk=; b=SGe6ymibWfkrwDHskU8fpXBdSWoxSpvWcJgHKC6oJBQwrpDZKdAsLsJBm6NpxDS+mq Tb37jlGXwmW4RwhXV2lYlOuRAKkBPkOglHj+VSeoXaMmGGH56BmC/R/X9B8AFMydg0x/ okOg8ITynS7GhdpRqupZGTPTm+C3iI/lNN/zxaSxBQ1u1SaOesZCcmkfs42SlMtJuifJ dF1rMHjUts9SLuf7V/ot3jPqpYljbBENvD6rIZQ/Y+a09MXgbJx6uQ13oFkU7rhzEdmK u7ALQB1dIh3zgQ6wybfdBd+JJ10lxapeQ850g/pDon6IRUIGCWFVjqLI4Y49iywRbP+u qnjA== 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=Mv51v+TECsPP/RIZ7TYDQgoile97O8RHwHlh2jMm4bk=; b=LeFa0Wn/lhN1kaq8UnJhpCIUKjoR+JYJj0G3R8ihNmE+L9UZrLwXWdeWEkx3LV0qK+ B5OkPuXJp8r1l9bjO6Ydee6rizpVqaUQUFOTEFpOdWQxS2TJBvMyK4iYyDJ5p637uTmh Q6ZE67PaeuNBstgc/Qm7M42VZ2MMFOA5tg+KjSQISjv/MkOEMcL2nBMdR/6VOs2qSBOf MV2iLCKP5CMyssWhWiUQhyCM+IV0wjyXHK5pJMIcuVL5WOZGpgM+6FlLbkdtuwfXd8BK Lc7EEpidqWEAYVD7lgaaZdTuk639fZ+/Gc0F+NUMWUhmnbn7WUXCHjyYJqNdc7loaSWv lfkQ== X-Gm-Message-State: AE9vXwMYZjPBEFKbCskt2OAbRGW2p1Mva5DdyK0AFBwUPp7sk/K9xT0ZimbN8+knGRfTQ+Y4ofSbRHRpLKiOJbZc X-Received: by 10.31.185.134 with SMTP id j128mr3529937vkf.144.1472589701962; Tue, 30 Aug 2016 13:41:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.97.2 with HTTP; Tue, 30 Aug 2016 13:41:41 -0700 (PDT) From: Bill Cox Date: Tue, 30 Aug 2016 13:41:41 -0700 Message-ID: To: Tokbind WG Content-Type: multipart/alternative; boundary=001a113ff1fc1624f5053b5002e8 Archived-At: Subject: [Unbearable] Dumb idea: add Ed25519 support? 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, 30 Aug 2016 20:41:45 -0000 --001a113ff1fc1624f5053b5002e8 Content-Type: text/plain; charset=UTF-8 I hate to offer yet another possible upgrade to TB, but I really would prefer to use Ed25519 by default. I see QUIC is already using it, and it seems a bit silly not to enable it in TB, when I've already implemented support for the other three. Should we add Ed25519-SHA256 as a 4th key parameters type? Bill --001a113ff1fc1624f5053b5002e8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I hate to offer yet another possible upgrade to TB, but I = really would prefer to use Ed25519 by default.=C2=A0 I see QUIC is already = using it, and it seems a bit silly not to enable it in TB, when I've al= ready implemented support for the other three.=C2=A0 Should we add Ed25519-= SHA256 as a 4th key parameters type?

Bill
--001a113ff1fc1624f5053b5002e8-- From nobody Tue Aug 30 13:58: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 2551712D827 for ; Tue, 30 Aug 2016 13:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, 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 (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 y_k1NAE7hRtu for ; Tue, 30 Aug 2016 13:57:40 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 E943912D81A for ; Tue, 30 Aug 2016 13:57:39 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id k90so54935289uak.1 for ; Tue, 30 Aug 2016 13:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SNy0HfqDIiS3kCA6wbIfZyFL7aBCjR19upifxHrgOBw=; b=p9k3Re9B6Ou1q8bFDzN/hXWRY8JvuBJGod3DA27TTB7V/2FUFyF+oqTw40DgbJ0M06 VMm3cwSSlJiw3I/yrGPIsiTzuMBequiJZYqsBl6yG9Va2Ca131qobMTZJ+oT9VkAtZmh 1lAf+YxjpxwqB/GF4btt/xINGSJx83ZuV/LPl7CElqP2G4Yb8Mf9JRGwiGQXKLIOvkIF m4Ez/HHuj/YoJsWw8ydGF9GZZ6l12x7L5FZeJWW/yDAxyrAf018xA1cx4Oape/Gdtpo1 YKASFHW09pGBvptxUFoXlI9kH5DwvMhuWDjBrMR59eOd1MYDgjpublrhho4QEbk7Abbi vIfA== 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=SNy0HfqDIiS3kCA6wbIfZyFL7aBCjR19upifxHrgOBw=; b=BRLH6QPWgxK/kMe7AHm0XFRpYEwObadYVmhyUwTMXheFKDXHCT+1M5y3b5XQ6inyv8 KicQTqwOuCTFerBR/tb76y1+aMeKM7tQrsbwZUAgH0t0wN42c3LCjtsjF9aZclNHrcl1 sZo9TCFeNPB0KWduhyHvuluKjkTYy8BDfDpGu/drgXojhbyLolz4JGT5EHTvVNupLrLr E9F4rB9pPEiuRizeMQSPTS/bIMWVG7DJSYUxPjY5Zg6LcQX413nm7YUqATB+96qktiY1 T78FiIegvo/9Vv613EKSrIRNVyWElCHBrLXY6mN3LJdJg3rAQ00C+4dEQOnmfU2FddXi 3D+w== X-Gm-Message-State: AE9vXwMK2eFl9NAuPUEg26xNr+qDs1OlOXSYB2aCXhAfE/MM0ujCYnlhOiRA0vOyCLtwiIT4hY66ACdSaCtX8A== X-Received: by 10.176.2.148 with SMTP id 20mr3577365uah.10.1472590659034; Tue, 30 Aug 2016 13:57:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.70.138 with HTTP; Tue, 30 Aug 2016 13:57:18 -0700 (PDT) In-Reply-To: References: From: Tony Arcieri Date: Tue, 30 Aug 2016 13:57:18 -0700 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a113ad3d021d420053b503bc3 Archived-At: Cc: Tokbind WG Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? 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, 30 Aug 2016 20:57:49 -0000 --001a113ad3d021d420053b503bc3 Content-Type: text/plain; charset=UTF-8 +1. In short order draft-irtf-cfrg-eddsa should become an informational RFC. I think it at least makes sense to at least support the new CFRG curves/signature algorithm. On Tue, Aug 30, 2016 at 1:41 PM, Bill Cox wrote: > I hate to offer yet another possible upgrade to TB, but I really would > prefer to use Ed25519 by default. I see QUIC is already using it, and it > seems a bit silly not to enable it in TB, when I've already implemented > support for the other three. Should we add Ed25519-SHA256 as a 4th key > parameters type? > > Bill > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > -- Tony Arcieri --001a113ad3d021d420053b503bc3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1.

In short order draft-irtf-cfrg-eddsa sho= uld become an informational RFC. I think it at least makes sense to at leas= t support the new CFRG curves/signature algorithm.

On Tue, Aug 30, 2016 at 1:41 PM, Bil= l Cox <waywardgeek@google.com> wrote:
I hate to offer yet another possible upgr= ade to TB, but I really would prefer to use Ed25519 by default.=C2=A0 I see= QUIC is already using it, and it seems a bit silly not to enable it in TB,= when I've already implemented support for the other three.=C2=A0 Shoul= d we add Ed25519-SHA256 as a 4th key parameters type?

Bill

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




--
Tony Arcieri
<= /div>
--001a113ad3d021d420053b503bc3-- From nobody Tue Aug 30 14:00:35 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 5921612D0B2 for ; Tue, 30 Aug 2016 14:00:33 -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 cFECs9SzpkIy for ; Tue, 30 Aug 2016 14:00:31 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0131.outbound.protection.outlook.com [104.47.42.131]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0428B12D815 for ; Tue, 30 Aug 2016 14:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Mwl4gEaGrD9KzF3X5HpqLvnGOKHeWh5MdvYI/PKXijQ=; b=WrzgZ21kBeD4Xj0r2a2O1OwajDlsuI0fm4bjy8HdzDnvef8x6wDJZ2xClcqDxNnDlFa5iXonxl5fjl8xNVvZhGg7gwRL8zKmR73AhCbnK0XDbuxt5q5es1G3uxcfD3/UaFXU7/UyzNZarBbQbj4KwDtSQx3XT6apoYx6LKu+2R4= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0843.namprd03.prod.outlook.com (10.160.163.149) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.21; Tue, 30 Aug 2016 21:00:28 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Tue, 30 Aug 2016 21:00:29 +0000 From: Andrei Popov To: Tony Arcieri , Bill Cox Thread-Topic: [Unbearable] Dumb idea: add Ed25519 support? Thread-Index: AQHSAv7vhTLhCxb7AU+usuWCAoCwYKBh/DIAgAAAgeA= Date: Tue, 30 Aug 2016 21:00: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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: dc803f20-e9bb-4786-36ff-08d3d118ac8d x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0843; 6:rrjJxj4ImRX+hHOIgRhaozkVnTh/+rw6chV4WUFdCTixC9hREiPO92JvXLYzBBQMwxCRjWbqKl/0WtNCmV5oOcYNWLpPs4dk8Lv9HeuexG9MdYS70sfxu+nZcO+Nh3k2+466IQBCh1c0xNZgb5QYZjFcxEAR6NxunXid8YEXKWXMQRF7HloZSxKqEGmmXTRyEOo6PMoEQChunpdEqJ2d0TrLdz0zjixmNqZU0DelvPTGorKeVhTnJ/2EBIbIZ6AOshYW/qx/sO5XvrxQiA+IZwRimin8HL6R3HzrAxpczYF5WhIqwx0aukKCzsN2f7n0uUpQh9X8HNHaqhhDFukkvg==; 5:Lu6nyWPSwke9NwahKT9cgXQjcgWf63nwzN4waQbLuoCL3jIsPT5EsVznwgHc8NlfT4OL/hQ1iFoMar3AhuxKg3183XoXOKEO9oa5nUKNXH2ixMBcClcGLbXCZsrGdc5xLMp7dqORzph2Iqx8fyWN0w==; 24:QtydomxpyhNmEr2GDvKwOnf3n8l/4mRotzxJ1AWevryEshlmxeI7d8OJmRebL6FdHW6qTCftpQIc5fT2kP7YrkZv1550llUM3JRHztm5hus=; 7:BZjeJ4egG4YXt0ByMYpt1SNUkawVacz0WvZOlUWRgR7jQ5cbkkLRWx6GwbZzBH8J3RR0UFl2RiXMcbK4kYiPUeouX1wjEXsjmVst3Ow18R+8uZRp9NPHlDQjCgsMuy+DkznFOD1WlFeBduAuNcBjC+K0/41SYJwWVj2ZHQZ+7nrsE52caGfa4UilE6Y7nQSXGDTVUqP2bepOV1aiZLpXEgGybIH0TAZZzMk9yNwid9LENYIta2d3rfrWPcGadn6o x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0843; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0843; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0843; x-forefront-prvs: 0050CEFE70 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(189002)(377454003)(199003)(10090500001)(6116002)(102836003)(790700001)(5001770100001)(97736004)(76176999)(74316002)(54356999)(10290500002)(106356001)(87936001)(586003)(50986999)(99286002)(189998001)(16236675004)(86362001)(4326007)(10400500002)(5005710100001)(122556002)(19609705001)(2906002)(19625215002)(19580395003)(106116001)(19617315012)(7846002)(33656002)(8936002)(9686002)(8990500004)(19580405001)(105586002)(92566002)(77096005)(81166006)(81156014)(68736007)(5660300001)(76576001)(2950100001)(19300405004)(2900100001)(15975445007)(86612001)(5002640100001)(3280700002)(3660700001)(7736002)(7696003)(7906003)(101416001)(8676002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0843; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842B2DE1F4F22221826DCA48CE00CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2016 21:00:29.1155 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0843 Archived-At: Cc: Tokbind WG Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? 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, 30 Aug 2016 21:00:33 -0000 --_000_CY1PR0301MB0842B2DE1F4F22221826DCA48CE00CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBub3Qgb3Bwb3NlIGEgUFIgYWRkaW5nIHRoaXMgbmV3IFRva2VuQmluZGluZ0tleVBh cmFtZXRlcnMgaWRlbnRpZmllciwgYWx0aG91Z2ggYXQgc29tZSBwb2ludCB3ZSBzaG91bGQgZnJl ZXplIHRoZSBleGlzdGluZyAzIHNwZWNzIGZvciBMQyBhbmQgcHV0IG5ldyBpZGVhcyBpbnRvIG5l dyBzcGVjcy4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRv OnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRvbnkgQXJjaWVyaQ0K U2VudDogVHVlc2RheSwgQXVndXN0IDMwLCAyMDE2IDE6NTcgUE0NClRvOiBCaWxsIENveCA8d2F5 d2FyZGdlZWtAZ29vZ2xlLmNvbT4NCkNjOiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBv cnQ/DQoNCisxLg0KDQpJbiBzaG9ydCBvcmRlciBkcmFmdC1pcnRmLWNmcmctZWRkc2Egc2hvdWxk IGJlY29tZSBhbiBpbmZvcm1hdGlvbmFsIFJGQy4gSSB0aGluayBpdCBhdCBsZWFzdCBtYWtlcyBz ZW5zZSB0byBhdCBsZWFzdCBzdXBwb3J0IHRoZSBuZXcgQ0ZSRyBjdXJ2ZXMvc2lnbmF0dXJlIGFs Z29yaXRobS4NCg0KT24gVHVlLCBBdWcgMzAsIDIwMTYgYXQgMTo0MSBQTSwgQmlsbCBDb3ggPHdh eXdhcmRnZWVrQGdvb2dsZS5jb208bWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb20+PiB3cm90 ZToNCkkgaGF0ZSB0byBvZmZlciB5ZXQgYW5vdGhlciBwb3NzaWJsZSB1cGdyYWRlIHRvIFRCLCBi dXQgSSByZWFsbHkgd291bGQgcHJlZmVyIHRvIHVzZSBFZDI1NTE5IGJ5IGRlZmF1bHQuICBJIHNl ZSBRVUlDIGlzIGFscmVhZHkgdXNpbmcgaXQsIGFuZCBpdCBzZWVtcyBhIGJpdCBzaWxseSBub3Qg dG8gZW5hYmxlIGl0IGluIFRCLCB3aGVuIEkndmUgYWxyZWFkeSBpbXBsZW1lbnRlZCBzdXBwb3J0 IGZvciB0aGUgb3RoZXIgdGhyZWUuICBTaG91bGQgd2UgYWRkIEVkMjU1MTktU0hBMjU2IGFzIGEg NHRoIGtleSBwYXJhbWV0ZXJzIHR5cGU/DQoNCkJpbGwNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0DQpVbmJl YXJhYmxlQGlldGYub3JnPG1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlDQoNCg0KDQotLQ0KVG9ueSBBcmNp ZXJpDQo= --_000_CY1PR0301MB0842B2DE1F4F22221826DCA48CE00CY1PR0301MB0842_ 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 CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21z by1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5JIHdvdWxkIG5vdCBvcHBvc2UgYSBQUiBhZGRpbmcgdGhpcyBuZXcgVG9rZW5CaW5kaW5n S2V5UGFyYW1ldGVycyBpZGVudGlmaWVyLCBhbHRob3VnaCBhdCBzb21lIHBvaW50IHdlIHNob3Vs ZCBmcmVlemUgdGhlIGV4aXN0aW5nIDMgc3BlY3MgZm9yIExDIGFuZCBwdXQgbmV3IGlkZWFzIGlu dG8gbmV3DQogc3BlY3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5k cmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBV bmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5Ub255IEFyY2llcmk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVndXN0 IDMwLCAyMDE2IDE6NTcgUE08YnI+DQo8Yj5Ubzo8L2I+IEJpbGwgQ294ICZsdDt3YXl3YXJkZ2Vl a0Bnb29nbGUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gVG9rYmluZCBXRyAmbHQ7dW5iZWFyYWJs ZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBEdW1i IGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBvcnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+JiM0MzsxLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J biBzaG9ydCBvcmRlciBkcmFmdC1pcnRmLWNmcmctZWRkc2Egc2hvdWxkIGJlY29tZSBhbiBpbmZv cm1hdGlvbmFsIFJGQy4gSSB0aGluayBpdCBhdCBsZWFzdCBtYWtlcyBzZW5zZSB0byBhdCBsZWFz dCBzdXBwb3J0IHRoZSBuZXcgQ0ZSRyBjdXJ2ZXMvc2lnbmF0dXJlIGFsZ29yaXRobS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXVnIDMwLCAy MDE2IGF0IDE6NDEgUE0sIEJpbGwgQ294ICZsdDs8YSBocmVmPSJtYWlsdG86d2F5d2FyZGdlZWtA Z29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndheXdhcmRnZWVrQGdvb2dsZS5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBoYXRlIHRvIG9mZmVyIHlldCBhbm90aGVyIHBvc3NpYmxlIHVwZ3JhZGUgdG8g VEIsIGJ1dCBJIHJlYWxseSB3b3VsZCBwcmVmZXIgdG8gdXNlIEVkMjU1MTkgYnkgZGVmYXVsdC4m bmJzcDsgSSBzZWUgUVVJQyBpcyBhbHJlYWR5IHVzaW5nIGl0LCBhbmQgaXQgc2VlbXMgYSBiaXQg c2lsbHkgbm90IHRvIGVuYWJsZSBpdCBpbiBUQiwgd2hlbiBJJ3ZlIGFscmVhZHkgaW1wbGVtZW50 ZWQgc3VwcG9ydCBmb3IgdGhlIG90aGVyDQogdGhyZWUuJm5ic3A7IFNob3VsZCB3ZSBhZGQgRWQy NTUxOS1TSEEyNTYgYXMgYSA0dGgga2V5IHBhcmFtZXRlcnMgdHlwZT88c3BhbiBjbGFzcz0iaG9l bnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PG86cD48L286cD48L3NwYW4+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj ODg4ODg4Ij5CaWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpVbmJlYXJhYmxl IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnIj5V bmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZTwvYT48bzpwPjwvbzpwPjwvcD4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyIGNs ZWFyPSJhbGwiPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvbnkgQXJjaWVyaTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR0301MB0842B2DE1F4F22221826DCA48CE00CY1PR0301MB0842_-- From nobody Tue Aug 30 14:19:13 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 8CB6812D0AE for ; Tue, 30 Aug 2016 14:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 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_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sunet.se 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 J4XGoZDg--_e for ; Tue, 30 Aug 2016 14:19:08 -0700 (PDT) Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [IPv6:2001:6b0:8:2::201]) (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 1A4D812B011 for ; Tue, 30 Aug 2016 14:19:07 -0700 (PDT) Received: from smtp1.sunet.se (smtp1.sunet.se [192.36.171.214]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id u7ULJ5Oc011070 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 30 Aug 2016 23:19:05 +0200 Received: from kerio.sunet.se (kerio.sunet.se [192.36.171.210]) by smtp1.sunet.se (8.14.9/8.14.9) with ESMTP id u7ULJ29W007507 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Aug 2016 21:19:04 GMT VBR-Info: md=sunet.se; mc=all; mv=swamid.se DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1472591944; bh=BCZh/gv5ELG2PM8w/yX3joL1V076hU7gUI7hHSk5Q5o=; h=Subject:To:References:From:Date:In-Reply-To; b=uzmqttfBoTx63ka/7WjiMPpmhOnBlYXQrxX+W6ursfoj2T29DswBsi+iU0wPIELGE 5bLisLWTg4E4XGr1OFrMePuVPM9BPXFmSkHbuqx/bSOWdzUxoWLqKPoVQqAZI8Lz31 ZBtmFGhZN32cjwPdGyvCfJy6hTbggjWiTIEWoOxA= X-Footer: c3VuZXQuc2U= Received: from [10.0.0.107] ([62.102.145.131]) (authenticated user leifj@sunet.se) by kerio.sunet.se (Kerio Connect 9.1.1) with ESMTPSA (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128 bits)) for unbearable@ietf.org; Tue, 30 Aug 2016 23:18:59 +0200 To: unbearable@ietf.org References: From: Leif Johansson Message-ID: <96c11d53-03c0-bcc3-92e1-ea73ce4d6a57@sunet.se> Date: Tue, 30 Aug 2016 23:18:59 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-CanIt-Geo: ip=192.36.171.210; country=SE; latitude=59.3294; longitude=18.0686; http://maps.google.com/maps?q=59.3294,18.0686&z=6 X-CanItPRO-Stream: outbound-sunet-se:outbound (inherits from outbound-sunet-se:default, sunet-se:default, base:default) X-Canit-Stats-ID: 09RBxj5fk - a8e6aee4f690 - 20160830 X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw Received-SPF: neutral (e-mailfilter01.sunet.se: 192.36.171.210 is neither permitted nor denied by domain leifj@sunet.se) receiver=e-mailfilter01.sunet.se; client-ip=192.36.171.210; envelope-from=; helo=smtp1.sunet.se; identity=mailfrom X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201 Archived-At: Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? 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, 30 Aug 2016 21:19:11 -0000 On 2016-08-30 22:41, Bill Cox wrote: > I hate to offer yet another possible upgrade to TB, but I really would > prefer to use Ed25519 by default. I see QUIC is already using it, and > it seems a bit silly not to enable it in TB, when I've already > implemented support for the other three. Should we add Ed25519-SHA256 > as a 4th key parameters type? We should certainly make sure the specs can swallow something like this as an extension but in order to hold up the specs at this point with a substantial addition I would like (with chair hat on) to see pretty strong statements of support from implementors. Cheers Leif From nobody Tue Aug 30 14:27:08 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 8AD0C12D736 for ; Tue, 30 Aug 2016 14:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 wWBD-4198ZTZ for ; Tue, 30 Aug 2016 14:27:05 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 3A7D912D7DD for ; Tue, 30 Aug 2016 14:27:02 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id k90so56146204uak.1 for ; Tue, 30 Aug 2016 14:27:02 -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=0e9lnwO5DMkLS8E5WZWtberOdbbIj4DYKlque9XGp5I=; b=XVXRIY6DwKRLMEvmYt+6x4V+Gw6HPgpzYcKtr9OmYeykEq7sWK8om2f6MPt0t2hk3v a8n7qYQ34z/Wu/qqEL200CTTZAFwTJzASYCJklphhSV/gCFKMiapKZPDco+Ec5UcIBp7 BmL98X+KvlfNLOGoXtWbzv9GOtutzSv3w6NaWKISvXYxN2FYvtNzakHwhyoblG6oEubq Oz4tFEnblsm8DnogqGTCUbZ2oCMJ2VFsoG4bR86NBUtixW5vhk7XmR9f+5Rg0kZeBLPy 3RQv9HtBvG8IA/XoRxs0+RJUkerlTggn743sXcrxf6e5oSbxZcxfFfaNxGfrMyKECp69 ZSHQ== 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=0e9lnwO5DMkLS8E5WZWtberOdbbIj4DYKlque9XGp5I=; b=m/sZXjhdMiKNwyYkLW2TWm8gomMdpXge84bu9noUI7TDcM7fnJXQLBWduPbWBtHGbS TkdzNRT4gnLfoaJKpZOKgXXseHlLbi/FCirITsOdZ/2/+UUzSD6U7filwxqueEf4m1Ky JS0h/Oo8HjWJWtWcWwwwywxNyKOLIBTk2JtvDvUwmVnwxRAcf29BkbFa3pfhP8ogqUcm j1JSfhIgKkKCcWJfmnkwl3LaZxsQQd3XIiXsh2gUBymaOMZ9MvgxzpDLFotOT9zDxU6G JL2FBaYfsm3HGxuwaQK48iyTcOVAHWVfH4q2oVYF9752tlxkmoynT7/f15dno5YXFXqo XWmg== X-Gm-Message-State: AE9vXwMYEnB9cktQ/sDuu6L23kINY+xQNe5zvCF2dBQ9OsJWzwdar5bUBXdDk4cyHeB+iO42XDIYGXsO74jYliEZ X-Received: by 10.176.2.70 with SMTP id 64mr3006085uas.79.1472592421147; Tue, 30 Aug 2016 14:27:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.97.2 with HTTP; Tue, 30 Aug 2016 14:27:00 -0700 (PDT) In-Reply-To: <96c11d53-03c0-bcc3-92e1-ea73ce4d6a57@sunet.se> References: <96c11d53-03c0-bcc3-92e1-ea73ce4d6a57@sunet.se> From: Bill Cox Date: Tue, 30 Aug 2016 14:27:00 -0700 Message-ID: To: Leif Johansson Content-Type: multipart/alternative; boundary=001a113e057c29c663053b50a48d Archived-At: Cc: Tokbind WG Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? 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, 30 Aug 2016 21:27:06 -0000 --001a113e057c29c663053b50a48d Content-Type: text/plain; charset=UTF-8 On Tue, Aug 30, 2016 at 2:18 PM, Leif Johansson wrote: > We should certainly make sure the specs can swallow something like this > as an extension but in order to hold up the specs at this point with > a substantial addition I would like (with chair hat on) to see pretty > strong statements of support from implementors. > > Cheers Leif That sounds really good to me. The changes from the -08 to -09 are going to set me back a week, most likely. BTW, why do we use SHA256 to hash all the security parameters together rather than feed them as parameters into the key export material API? It already has a "label" and a "context". This would be a smaller change, and would eliminate a SHA256 hash. Bill --001a113e057c29c663053b50a48d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Aug 30, 2016 at 2:18 PM, Leif Johansson <leifj@sunet.se> = wrote:
We should certainly make sure the = specs can swallow something like this
as an extension but in order to hold up the specs at this point with
a substantial addition I would like (with chair hat on) to see pretty
strong statements of support from implementors.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif

Tha= t sounds really good to me.=C2=A0 The changes from the -08 to -09 are going= to set me back a week, most likely.=C2=A0 BTW, why do we use SHA256 to has= h all the security parameters together rather than feed them as parameters = into the key export material API?=C2=A0 It already has a "label" = and a "context".=C2=A0 This would be a smaller change, and would = eliminate a SHA256 hash.

Bill=C2=A0
--001a113e057c29c663053b50a48d-- From nobody Tue Aug 30 14:27: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 7D86812D504 for ; Tue, 30 Aug 2016 14:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 DVwlMw2yAXSL for ; Tue, 30 Aug 2016 14:27:40 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0123.outbound.protection.outlook.com [104.47.32.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2D112D0AE for ; Tue, 30 Aug 2016 14:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lU0wSHK/RJ9IaCb8NwlswtgaN8vKvrVmKR3XA6bgNgY=; b=Jz09fCQG4jLOB6MhOxOPEITrL3TIbt4ELWM/T02lHzATCk5nlgESgqCPlHQyYXPz4D8Ky7/Pmux1RgE2GSFlCtbHwkOaG/ZTXYomS0jv2DtNDWWn8txoHfrME2eA3CQM0RZguSzkml/e5MmG8+m5cOZxFSRo5VM6okVXI9a6Tag= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0844.namprd03.prod.outlook.com (10.160.163.150) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Tue, 30 Aug 2016 21:27:34 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Tue, 30 Aug 2016 21:27:34 +0000 From: Andrei Popov To: Leif Johansson , "unbearable@ietf.org" Thread-Topic: [Unbearable] Dumb idea: add Ed25519 support? Thread-Index: AQHSAv7vhTLhCxb7AU+usuWCAoCwYKBiAkGAgAAAsKA= Date: Tue, 30 Aug 2016 21:27:33 +0000 Message-ID: References: <96c11d53-03c0-bcc3-92e1-ea73ce4d6a57@sunet.se> In-Reply-To: <96c11d53-03c0-bcc3-92e1-ea73ce4d6a57@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: ad786048-4906-4035-1de5-08d3d11c74fa x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 6:YueLNhRtt0QGDft1pZXggszU260FjWF8ExeMoL8urhRRh1+kPcisqofIAES/kFeBb5C5fD9ODCr2jOdi+AUKcjg1KnwT+epK02TYf/gQgw+U1nZYaLSZ55yMKzFP8RR3b4Zg+NwPWRuUk90bgbvnS1t1pPL53snPJ8k0s5q84QJHVLMmknp1omAqywQl5wvBqVx3GaxOsCRZmSzTvzponBZutRjahuQ3YqDnCmkDwgZxTrVKeM7LBVpwNM/KmnVSNRRD5zWi50s6AlteYSRySs4fdyQ6QnNvpzPIEvGSxGy3WDBKP9LIdYavf1c6w1Gxuo2gng73T/D+xuxj1mZxmA==; 5:aw6ow000ouI29a/ZrcuI6/0SxrEbfpmZANAI9N2tix4bpSUQf6XA00LYGYrM8Z0EYKz4nqOft6IMJ58DXOgDdAsSujkR8W6mbbWsrr3y1v6E96lbdwPBmxXjqDkAbh4cg0BQV83bAt0UAAP+yMcQBg==; 24:tL1Iktzns0hc6txLKYzdP6+fDAJeHMASMH7eBRflCooK7MGaYWKtKvs69K/tUiN/foDViPVizndnsr7RfsAEf94VNNsUUqnaWteZGbTGXA8=; 7:vHyDDAjjTD7TRQ6s+v11K0NoGeyAJN/2KRpvxBmFCaRVMa68B5o2/a1JZF/nxOTbfAsQTfeuOwOktJLoVp22ZcmWtmYtklDuYnQtBGx0mn5c/gDCNkSMhcamXzKkLLVG6gXU1wqJX7ysUlS52HkiB3Sd5jxaVvJxDgVo/+LFzMcym4R0Ix6j5AqIzbZHW4BTzKpEDTh39L2LXSv5mvQYjVVQOtjqXaQQGVpMhtK3ORdW/9is7W3pCF7Pp1SyWoZl x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0844; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844; x-forefront-prvs: 0050CEFE70 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(13464003)(24454002)(189002)(377424004)(377454003)(122556002)(305945005)(7696003)(3660700001)(5001770100001)(105586002)(7846002)(74316002)(97736004)(50986999)(106116001)(76176999)(5002640100001)(54356999)(92566002)(68736007)(107886002)(7736002)(10090500001)(77096005)(19580405001)(8676002)(99286002)(2906002)(101416001)(5660300001)(189998001)(15975445007)(81166006)(81156014)(106356001)(76576001)(86362001)(3280700002)(8936002)(2950100001)(9686002)(2900100001)(10290500002)(2501003)(86612001)(5005710100001)(11100500001)(8990500004)(102836003)(10400500002)(19580395003)(87936001)(6116002)(586003)(33656002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 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: 30 Aug 2016 21:27:33.9048 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0844 Archived-At: Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? 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, 30 Aug 2016 21:27:44 -0000 Perhaps this could be a new I-D specifying a new TokenBindingKeyParameters = identifier. Speaking as an implementer, MS has no plans to support Ed25519 TB keys in t= he foreseeable future. Cheers, Andrei -----Original Message----- From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Leif Joh= ansson Sent: Tuesday, August 30, 2016 2:19 PM To: unbearable@ietf.org Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? On 2016-08-30 22:41, Bill Cox wrote: > I hate to offer yet another possible upgrade to TB, but I really would=20 > prefer to use Ed25519 by default. I see QUIC is already using it, and=20 > it seems a bit silly not to enable it in TB, when I've already=20 > implemented support for the other three. Should we add Ed25519-SHA256=20 > as a 4th key parameters type? We should certainly make sure the specs can swallow something like this as = an extension but in order to hold up the specs at this point with a substan= tial addition I would like (with chair hat on) to see pretty strong stateme= nts of support from implementors. Cheers Leif _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable From nobody Tue Aug 30 14:34: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 CCCB112D810 for ; Tue, 30 Aug 2016 14:34:01 -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 Mt0E6lY1NKEL for ; Tue, 30 Aug 2016 14:33:59 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0123.outbound.protection.outlook.com [104.47.41.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2457112D800 for ; Tue, 30 Aug 2016 14:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gl4+rBxYsgtXS21CW6ezcARSDr5nEHa8WEQzCz1Oye0=; b=XpcG2xpXP/Qzhf+Olo0M9EzEPGBjZqui0fOyuYuDb4Nd5+GbIMWI8HhvM2iiT3GlOw0e6K1qU+b4bqE5wDjZ9o6uG7F2D0pZHdQ+b8J/0duuQIi7hMFV6Mla7EjF40cViL3Qrs1LevIO8vTuXPM7Y9viCb+iyAyHUl4K4xSQghw= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0841.namprd03.prod.outlook.com (10.160.163.147) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Tue, 30 Aug 2016 21:33:56 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Tue, 30 Aug 2016 21:33:57 +0000 From: Andrei Popov To: Bill Cox , Leif Johansson Thread-Topic: [Unbearable] Dumb idea: add Ed25519 support? Thread-Index: AQHSAv7vhTLhCxb7AU+usuWCAoCwYKBiAkGAgAACPQCAAAFN0A== Date: Tue, 30 Aug 2016 21:33:56 +0000 Message-ID: References: <96c11d53-03c0-bcc3-92e1-ea73ce4d6a57@sunet.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: d6a2855b-d89e-4300-d1ec-08d3d11d593d x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 6:fFV0l53LqR9ey/0BKX+AQqYyCuRMCYYmHK/bBZTabTTnnLNG5qm4cmwx8g0v+JMYLcvRz8FCdTNYXJmO3kQIG7fL0uLayAxKRj/Fj/i8eQbV41SBlYTIomuZgJWYREIkGHIZBne0GTorQ+q3+rqshJyGGWVkdJwf49ZqTgfdn5pZp9sCrZJbjncCb+Egf9CR4rEQzA88T9xsIbJuxxIZuyJfWZxdmGmuLv828zGuP6b0AJ5KNoE20D4b9Fgsd44HrsUdXpbArrE4qRABsJHi8iA70f+WH1nkPCvX9FroBAgBC1oGkvwIFvFrUK2DqPa7FXqCLrIUM41QcZ1S5FMWRg==; 5:5HClweFjORI+qJpgNllV3UsnBR1sF7vVszjmr0137d/Y6WK44CUBMpeCIR2fM0ByRhj1YKZiM5Tu0+uDWnBPWN7G868e9TpcwHN70UAM1PhEtKQUHYeon4NGuBG2h7zGVPptUutTOKIrGhFLaOp+NQ==; 24:YEYFlVcFM3gxsFvFUe4n3oL8gQ0Ca/ppu10qrQ1+4Ebwhsl20n/VcyZILfeFJnruJPlGYdeuBb/Omcp1o7EFSbBJihYJK0+9x5VqM06TbDo=; 7:9swngoUhbwkcQO4qGeiPjVV1aBik+auv5Mu1scDbXSc0t1K3+Xc50rP8CKeBAIhUiRcQQFo2S5MeKGgzXnDJo1jIYb1YcT8nQwwgIU9lEEHULrSp+AA/dBLxC98N6dd+dc3erWa+qsGt3fTizaqNNcUHZ7wY1qAEjc9dKtUvYnIO5B31d6/GDdF7ESOQMBkJbv5XMyu7ZiBknICbzoOLNS8eJ7tmy8xFkbq8wpHUoDabdRczV1HOtxE6wtjn+MfS x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0841; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841; x-forefront-prvs: 0050CEFE70 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(199003)(189002)(24454002)(54356999)(19625215002)(5660300001)(50986999)(76576001)(106356001)(106116001)(6116002)(790700001)(19300405004)(19580395003)(105586002)(86362001)(99286002)(19580405001)(10400500002)(19609705001)(122556002)(68736007)(5002640100001)(16236675004)(4326007)(97736004)(9686002)(3280700002)(5001770100001)(101416001)(2950100001)(2906002)(92566002)(86612001)(2900100001)(33656002)(7846002)(8990500004)(7736002)(10090500001)(8936002)(81166006)(102836003)(87936001)(74316002)(81156014)(76176999)(5005710100001)(10290500002)(586003)(77096005)(15975445007)(7696003)(3660700001)(8676002)(189998001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB084227C730B7B2B7E12FCC9B8CE00CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2016 21:33:56.8940 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0841 Archived-At: Cc: Tokbind WG Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? 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, 30 Aug 2016 21:34:02 -0000 --_000_CY1PR0301MB084227C730B7B2B7E12FCC9B8CE00CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXJlIHlvdSBzdWdnZXN0aW5nIHRoYXQgd2UgY29uY2F0ZW5hdGU6DQogICBvICBBIFByb3RvY29s VmVyc2lvbiBzdHJ1Y3R1cmUgcmVwcmVzZW50aW5nIHRoZSBuZWdvdGlhdGVkIHZlcnNpb24gb2YN CiAgICAgIHRoZSBUb2tlbiBCaW5kaW5nIHByb3RvY29sLCBlLmcuIDB4MDEgMHgwMCBmb3IgVG9r ZW4gQmluZGluZyAxLjA7DQogICBvICBUb2tlbkJpbmRpbmdUeXBlIHZhbHVlIGNvbnRhaW5lZCBp biB0aGUNCiAgICAgIFRva2VuQmluZGluZy50b2tlbmJpbmRpbmdfdHlwZSBmaWVsZDsNCiAgIG8g IFRva2VuQmluZGluZ0tleVBhcmFtZXRlcnMgdmFsdWUgY29udGFpbmVkIGluIHRoZQ0KICAgICAg VG9rZW5CaW5kaW5nSUQua2V5X3BhcmFtZXRlcnMgZmllbGQ7DQoNCkFuZCB1c2UgdGhlIHJlc3Vs dCBhcyBvdXIgRUtNIGNvbnRleHQgdmFsdWUsIGFuZCB0aGVuIGp1c3Qgc2lnbiB0aGUgcmVzdWx0 aW5nIEVLTT8NCg0KRnJvbTogVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJpbGwgQ294DQpTZW50OiBUdWVzZGF5LCBBdWd1c3QgMzAs IDIwMTYgMjoyNyBQTQ0KVG86IExlaWYgSm9oYW5zc29uIDxsZWlmakBzdW5ldC5zZT4NCkNjOiBU b2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxl XSBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBvcnQ/DQoNCk9uIFR1ZSwgQXVnIDMwLCAyMDE2 IGF0IDI6MTggUE0sIExlaWYgSm9oYW5zc29uIDxsZWlmakBzdW5ldC5zZTxtYWlsdG86bGVpZmpA c3VuZXQuc2U+PiB3cm90ZToNCldlIHNob3VsZCBjZXJ0YWlubHkgbWFrZSBzdXJlIHRoZSBzcGVj cyBjYW4gc3dhbGxvdyBzb21ldGhpbmcgbGlrZSB0aGlzDQphcyBhbiBleHRlbnNpb24gYnV0IGlu IG9yZGVyIHRvIGhvbGQgdXAgdGhlIHNwZWNzIGF0IHRoaXMgcG9pbnQgd2l0aA0KYSBzdWJzdGFu dGlhbCBhZGRpdGlvbiBJIHdvdWxkIGxpa2UgKHdpdGggY2hhaXIgaGF0IG9uKSB0byBzZWUgcHJl dHR5DQpzdHJvbmcgc3RhdGVtZW50cyBvZiBzdXBwb3J0IGZyb20gaW1wbGVtZW50b3JzLg0KDQog ICAgICAgIENoZWVycyBMZWlmDQoNClRoYXQgc291bmRzIHJlYWxseSBnb29kIHRvIG1lLiAgVGhl IGNoYW5nZXMgZnJvbSB0aGUgLTA4IHRvIC0wOSBhcmUgZ29pbmcgdG8gc2V0IG1lIGJhY2sgYSB3 ZWVrLCBtb3N0IGxpa2VseS4gIEJUVywgd2h5IGRvIHdlIHVzZSBTSEEyNTYgdG8gaGFzaCBhbGwg dGhlIHNlY3VyaXR5IHBhcmFtZXRlcnMgdG9nZXRoZXIgcmF0aGVyIHRoYW4gZmVlZCB0aGVtIGFz IHBhcmFtZXRlcnMgaW50byB0aGUga2V5IGV4cG9ydCBtYXRlcmlhbCBBUEk/ICBJdCBhbHJlYWR5 IGhhcyBhICJsYWJlbCIgYW5kIGEgImNvbnRleHQiLiAgVGhpcyB3b3VsZCBiZSBhIHNtYWxsZXIg Y2hhbmdlLCBhbmQgd291bGQgZWxpbWluYXRlIGEgU0hBMjU2IGhhc2guDQoNCkJpbGwNCg== --_000_CY1PR0301MB084227C730B7B2B7E12FCC9B8CE00CY1PR0301MB0842_ 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 IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41 aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFyZSB5b3Ugc3VnZ2Vz dGluZyB0aGF0IHdlIGNvbmNhdGVuYXRlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7IG8mbmJzcDsgQSBQcm90 b2NvbFZlcnNpb24gc3RydWN0dXJlIHJlcHJlc2VudGluZyB0aGUgbmVnb3RpYXRlZCB2ZXJzaW9u IG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7dGhlIFRva2VuIEJpbmRpbmcg cHJvdG9jb2wsIGUuZy4gMHgwMSAweDAwIGZvciBUb2tlbiBCaW5kaW5nIDEuMDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OyZuYnNwOyBvJm5ic3A7IFRva2VuQmluZGluZ1R5cGUgdmFsdWUgY29udGFpbmVkIGluIHRoZTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRva2VuQmluZGluZy50b2tlbmJpbmRp bmdfdHlwZSBmaWVsZDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFRva2VuQmluZGluZ0tleVBh cmFtZXRlcnMgdmFsdWUgY29udGFpbmVkIGluIHRoZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFRva2VuQmluZGluZ0lELmtleV9wYXJhbWV0ZXJzIGZpZWxkOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5BbmQgdXNlIHRoZSByZXN1bHQgYXMgb3VyIEVLTSBjb250ZXh0IHZhbHVlLCBhbmQgdGhl biBqdXN0IHNpZ24gdGhlIHJlc3VsdGluZyBFS00/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJsZS1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CaWxsIENveDxicj4NCjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMzAsIDIwMTYgMjoyNyBQTTxicj4NCjxiPlRvOjwvYj4g TGVpZiBKb2hhbnNzb24gJmx0O2xlaWZqQHN1bmV0LnNlJmd0Ozxicj4NCjxiPkNjOjwvYj4gVG9r YmluZCBXRyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtVbmJlYXJhYmxlXSBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBvcnQ/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEF1ZyAz MCwgMjAxNiBhdCAyOjE4IFBNLCBMZWlmIEpvaGFuc3NvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxl aWZqQHN1bmV0LnNlIiB0YXJnZXQ9Il9ibGFuayI+bGVpZmpAc3VuZXQuc2U8L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBz aG91bGQgY2VydGFpbmx5IG1ha2Ugc3VyZSB0aGUgc3BlY3MgY2FuIHN3YWxsb3cgc29tZXRoaW5n IGxpa2UgdGhpczxicj4NCmFzIGFuIGV4dGVuc2lvbiBidXQgaW4gb3JkZXIgdG8gaG9sZCB1cCB0 aGUgc3BlY3MgYXQgdGhpcyBwb2ludCB3aXRoPGJyPg0KYSBzdWJzdGFudGlhbCBhZGRpdGlvbiBJ IHdvdWxkIGxpa2UgKHdpdGggY2hhaXIgaGF0IG9uKSB0byBzZWUgcHJldHR5PGJyPg0Kc3Ryb25n IHN0YXRlbWVudHMgb2Ygc3VwcG9ydCBmcm9tIGltcGxlbWVudG9ycy48YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ2hlZXJzIExlaWY8bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQgc291bmRzIHJlYWxs eSBnb29kIHRvIG1lLiZuYnNwOyBUaGUgY2hhbmdlcyBmcm9tIHRoZSAtMDggdG8gLTA5IGFyZSBn b2luZyB0byBzZXQgbWUgYmFjayBhIHdlZWssIG1vc3QgbGlrZWx5LiZuYnNwOyBCVFcsIHdoeSBk byB3ZSB1c2UgU0hBMjU2IHRvIGhhc2ggYWxsIHRoZSBzZWN1cml0eSBwYXJhbWV0ZXJzIHRvZ2V0 aGVyIHJhdGhlciB0aGFuIGZlZWQgdGhlbSBhcyBwYXJhbWV0ZXJzIGludG8gdGhlIGtleSBleHBv cnQNCiBtYXRlcmlhbCBBUEk/Jm5ic3A7IEl0IGFscmVhZHkgaGFzIGEgJnF1b3Q7bGFiZWwmcXVv dDsgYW5kIGEgJnF1b3Q7Y29udGV4dCZxdW90Oy4mbmJzcDsgVGhpcyB3b3VsZCBiZSBhIHNtYWxs ZXIgY2hhbmdlLCBhbmQgd291bGQgZWxpbWluYXRlIGEgU0hBMjU2IGhhc2guPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJpbGwmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_CY1PR0301MB084227C730B7B2B7E12FCC9B8CE00CY1PR0301MB0842_-- From nobody Tue Aug 30 14:37:52 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 D60E212D800 for ; Tue, 30 Aug 2016 14:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 H_MxDqS3YOaM for ; Tue, 30 Aug 2016 14:37:48 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 B42F612B068 for ; Tue, 30 Aug 2016 14:37:48 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id l94so56588153ual.0 for ; Tue, 30 Aug 2016 14:37:48 -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=PtgPnCbD5aBQytwZ/v8WiXqyKIKTAzU9C/2AGP/75Vo=; b=OXzef6+IUBq1q/vc3oufEgJ4NOI5hxX//mqk1udaIO5UAeLYgQxaTyLnDYZCXv1bNb 3IAyXWtNJ/S8zs1ZelvXdqQtyUKr63+h19vhz/gEUvzPUW6HpmKYTQSVnl+P5CytRfRo Gl4zya9Xxwg6yQrKkMGmH+mJZRnTwFtTHPjV/NFFcXo7u48ce/tPyXX0YGcbZR5XaPs7 zP15rhQWub7hlFo8AMle9S7FlBHqOxSRnr4N9JhBgflRn6IT4+ACsjnC0oHC+IpKUwh9 dIKeu8x0Y8E5N6enWc7L+q87RJS9Sszolq+xTePgUNd0FdSP18tWvoXj1BHkKXZPnz2h AleA== 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=PtgPnCbD5aBQytwZ/v8WiXqyKIKTAzU9C/2AGP/75Vo=; b=kldruvQwYMWuUy3rOU9CChN3auCLthBYpfUWyFuF5SfpzX1wkmpELDyB2kJYeX1aJu 3Vuz7i2aJD1q3yMpYKdqhlTXYpMXHv7S/N51QfCfZCscqolkkhyUoZcT6I9WvOE0O+lr 1ARClH581jIdkd6UJkKaVfvkdeeYnbAbu5mpWkP3kQqz1JVarBHUQWYp8gNv1MUd8RPf e27z4NtYYM2KCfY0ptxIhVreC8UNTJnS26IK8QbOikaDBM7FRs2kpUvBw9gnux5lMbJ0 UsA39stK0dAb8AWO8rQkaxd8Nnh20lkWGCPr59Q5p5rzkjzFsuqxzE6prWo/1GgZaQTp TJtA== X-Gm-Message-State: AE9vXwO1ihLhE/tyC7AlhspU9X6F3XeW0zfGhDSGeevyi2hj8Iajg/r+SB5B5ksJtW82CyJ5D6aselg0AIWTZs5+ X-Received: by 10.31.180.195 with SMTP id d186mr3594833vkf.140.1472593067227; Tue, 30 Aug 2016 14:37:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.97.2 with HTTP; Tue, 30 Aug 2016 14:37:46 -0700 (PDT) In-Reply-To: References: <96c11d53-03c0-bcc3-92e1-ea73ce4d6a57@sunet.se> From: Bill Cox Date: Tue, 30 Aug 2016 14:37:46 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a114382ccac04fd053b50ca3f Archived-At: Cc: Tokbind WG , Leif Johansson Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? 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, 30 Aug 2016 21:37:51 -0000 --001a114382ccac04fd053b50ca3f Content-Type: text/plain; charset=UTF-8 On Tue, Aug 30, 2016 at 2:33 PM, Andrei Popov wrote: > Are you suggesting that we concatenate: > > o A ProtocolVersion structure representing the negotiated version of > > the Token Binding protocol, e.g. 0x01 0x00 for Token Binding 1.0; > > o TokenBindingType value contained in the > > TokenBinding.tokenbinding_type field; > > o TokenBindingKeyParameters value contained in the > > TokenBindingID.key_parameters field; > > > > And use the result as our EKM context value, and then just sign the > resulting EKM? > Yes, though I also hate to double-hash values. The protocol version and key parameters are already hashed into the handshake hash, which is hashed into the EKM seed. This is at least a third level of hashing, and with repeated parameters. I've heard mathematicians prefer to analyze a protocol with everything hashed at once, but in this case, hashing in parameters from the handshake really is redundant. Bill --001a114382ccac04fd053b50ca3f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Aug 30, 2016 at 2:33 PM, Andrei Popov <Andrei.Popov@microsoft= .com> wrote:

Are you suggesting that we concatenate:

=C2=A0=C2=A0 o=C2=A0 A ProtocolVersion structure re= presenting the negotiated version of

=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0the Token Binding pr= otocol, e.g. 0x01 0x00 for Token Binding 1.0;

=C2=A0=C2=A0 o=C2=A0 TokenBindingType value contain= ed in the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TokenBinding.tokenbi= nding_type field;

=C2=A0=C2=A0 o=C2=A0 TokenBindingKeyParameters valu= e contained in the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TokenBindingID.key_p= arameters field;

=C2=A0

And use the result as our EKM context value, and th= en just sign the resulting EKM?

Yes, though I also hate to double-hash values.=C2=A0 The protoc= ol version and key parameters are already hashed into the handshake hash, w= hich is hashed into the EKM seed.=C2=A0 This is at least a third level of h= ashing, and with repeated parameters.=C2=A0 I've heard mathematicians p= refer to analyze a protocol with everything hashed at once, but in this cas= e, hashing in parameters from the handshake really is redundant.
=
Bill=C2=A0
--001a114382ccac04fd053b50ca3f-- From nobody Tue Aug 30 14:49:12 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 62ED612D80F for ; Tue, 30 Aug 2016 14:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 nXhd1k-wi9Ai for ; Tue, 30 Aug 2016 14:49:09 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0094.outbound.protection.outlook.com [104.47.36.94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF25A12D1E3 for ; Tue, 30 Aug 2016 14:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=24LY6JChR+R+7TRw13VVi+WbWwmAZYhys8TOxIdlspg=; b=BmCS/DHFpBUC2sfptlNfYJxdIM3SoS6wGZj/zn48cbsxM+Yv/W6RcK+HwO4LZ10HhMRBxe8KRuXKhEOygbCgi3k88v/2+Mppr2Dl1tSZsgL55Y9b9ShrklZtR/dFYJZN0oJe0ZKJ9AXLRP59GxJc/vZrEUvwOL8l3gs539+Druk= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0844.namprd03.prod.outlook.com (10.160.163.150) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Tue, 30 Aug 2016 21:49:04 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Tue, 30 Aug 2016 21:49:04 +0000 From: Andrei Popov To: Bill Cox Thread-Topic: [Unbearable] Dumb idea: add Ed25519 support? Thread-Index: AQHSAv7vhTLhCxb7AU+usuWCAoCwYKBiAkGAgAACPQCAAAFN0IAAAbUAgAAAb1A= Date: Tue, 30 Aug 2016 21:49:04 +0000 Message-ID: References: <96c11d53-03c0-bcc3-92e1-ea73ce4d6a57@sunet.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: fb25510d-674d-47c1-e287-08d3d11f7609 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 6:4f/7HtqjamhsNtR/DFIglZyMmzw6aQhgC6R8MMxPS1tklC4BA9IwTd35mDsHoyDwi8UPUnpC+d3hlzZHmEVRkkMOByhl79zH5FvLRCL1nQjgWbcJFj4getWacUm4zJertlladQ6gLBrs+OZ0wR+Pu+ERkfFnkzZLa751RQrQGlZhMndoatsKa5glT2P1lxBeX0m09ZWbiSWa15PNsik6NrTxYSZj8N/Spit8/i38DAia+6LIQ+UC8EigHbWaJrAcp9JPtPLeavIWmIyiJsZxsghxszduqHTm5ip55oggQHiCRQtv/HAqgmtrlaLNznCuguiUwuqqloCkuXWczuZqxw==; 5:m1HRRXX+iaarxkGOLYIpcNqUxQLCHcRs4QtHB7DrZAV22sY7TKLltMqFK5+A2yyDkeFhyQV8ypUHVUeFZ/4/AifhCRhdL3fopUwU/BooCyaHP8KkWHH6kFvQTqybYkP5rvEf2SZqGP46eQeFxoiwzg==; 24:yCbNWmhm+5xPfy8iy+Agf/JP/+/mz64OJlZNCiFdRKvTgDyBuCqYsgSndAyOlNAxGFb5oPEIL6MJi1tNh8jIqti0xWfZc1LxrWIVzc1lacU=; 7:AdffUlwVtub9toqIJI8TUXfDnWNCu1O1AxFRBxjuY+psZzGKc6fEhgzqUpPn8V9N4MqbIHiJYa74Twrz1+bU54wGJSkgIpX5SBWUOrZCKnkNG6XXPzJq88/FzHOnunS6J/le/j+H8Q6vhXsDwJSLpKrHYVrTxa9pKbUoYP3/uzjVbdB0Vzwb7HBQdoQ8a0iP4bHZfxDTO5igKoQ8uTHLo8J66nHVnY5dGmQqCXivE90SdMOm2xtP5oVJaKy9yU9A x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0844; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844; x-forefront-prvs: 0050CEFE70 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(199003)(24454002)(3280700002)(19609705001)(8936002)(76576001)(106356001)(86362001)(10400500002)(790700001)(16236675004)(33656002)(19580395003)(87936001)(586003)(6116002)(2950100001)(9686002)(2900100001)(5005710100001)(102836003)(11100500001)(8990500004)(10290500002)(86612001)(54356999)(76176999)(5002640100001)(93886004)(7736002)(92566002)(68736007)(7696003)(3660700001)(122556002)(4326007)(97736004)(106116001)(50986999)(110136002)(7846002)(74316002)(105586002)(101416001)(8676002)(99286002)(2906002)(19625215002)(15975445007)(81166006)(19300405004)(81156014)(5660300001)(189998001)(10090500001)(77096005)(19580405001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB08423E8541185B5E48F1D7448CE00CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2016 21:49:04.1740 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0844 Archived-At: Cc: Tokbind WG , Leif Johansson Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? 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, 30 Aug 2016 21:49:11 -0000 --_000_CY1PR0301MB08423E8541185B5E48F1D7448CE00CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIFRva2VuQmluZGluZ0tleVBhcmFtZXRlcnMgdmFsdWUgaXMgbm90IG5lY2Vzc2FyaWx5IGlu IHRoZSBUTFMgaGFuZHNoYWtlIGhhc2ggKGUuZy4gZm9yIHJlZmVycmVkIGJpbmRpbmdzKS4NCg0K VGhlIFByb3RvY29sVmVyc2lvbiB2YWx1ZSBpcyBvbmx5IGluIHRoZSBUTFMgaGFuZHNoYWtlIGlm IHdlIGtlZXAgaXQgaW4gdGhlIHRva2VuX2JpbmRpbmcgZXh0ZW5zaW9uICh3aGljaCBJIGhvcGUg d2Ugd2lsbCkuDQoNCkkgZG9u4oCZdCBpbW1lZGlhdGVseSBzZWUgd2h5IHRoaXMgaWRlYSB3b3Vs ZG7igJl0IHdvcmssIGFuZCBpdCBlbGltaW5hdGVzIG9uZSBoYXNoIG9wZXJhdGlvbiwgYnV0IEkg dGhpbmsgd2UgaGF2ZSB0byBzdXBwbHkgYXQgbGVhc3QgVG9rZW5CaW5kaW5nVHlwZSBhbmQgVG9r ZW5CaW5kaW5nS2V5UGFyYW1ldGVycyBhcyB0aGUgRUtNIGNvbnRleHQuDQoNCkZyb206IEJpbGwg Q294IFttYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEF1Z3Vz dCAzMCwgMjAxNiAyOjM4IFBNDQpUbzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9z b2Z0LmNvbT4NCkNjOiBMZWlmIEpvaGFuc3NvbiA8bGVpZmpAc3VuZXQuc2U+OyBUb2tiaW5kIFdH IDx1bmJlYXJhYmxlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBEdW1iIGlk ZWE6IGFkZCBFZDI1NTE5IHN1cHBvcnQ/DQoNCk9uIFR1ZSwgQXVnIDMwLCAyMDE2IGF0IDI6MzMg UE0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJl aS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpBcmUgeW91IHN1Z2dlc3RpbmcgdGhhdCB3 ZSBjb25jYXRlbmF0ZToNCiAgIG8gIEEgUHJvdG9jb2xWZXJzaW9uIHN0cnVjdHVyZSByZXByZXNl bnRpbmcgdGhlIG5lZ290aWF0ZWQgdmVyc2lvbiBvZg0KICAgICAgdGhlIFRva2VuIEJpbmRpbmcg cHJvdG9jb2wsIGUuZy4gMHgwMSAweDAwIGZvciBUb2tlbiBCaW5kaW5nIDEuMDsNCiAgIG8gIFRv a2VuQmluZGluZ1R5cGUgdmFsdWUgY29udGFpbmVkIGluIHRoZQ0KICAgICAgVG9rZW5CaW5kaW5n LnRva2VuYmluZGluZ190eXBlIGZpZWxkOw0KICAgbyAgVG9rZW5CaW5kaW5nS2V5UGFyYW1ldGVy cyB2YWx1ZSBjb250YWluZWQgaW4gdGhlDQogICAgICBUb2tlbkJpbmRpbmdJRC5rZXlfcGFyYW1l dGVycyBmaWVsZDsNCg0KQW5kIHVzZSB0aGUgcmVzdWx0IGFzIG91ciBFS00gY29udGV4dCB2YWx1 ZSwgYW5kIHRoZW4ganVzdCBzaWduIHRoZSByZXN1bHRpbmcgRUtNPw0KDQpZZXMsIHRob3VnaCBJ IGFsc28gaGF0ZSB0byBkb3VibGUtaGFzaCB2YWx1ZXMuICBUaGUgcHJvdG9jb2wgdmVyc2lvbiBh bmQga2V5IHBhcmFtZXRlcnMgYXJlIGFscmVhZHkgaGFzaGVkIGludG8gdGhlIGhhbmRzaGFrZSBo YXNoLCB3aGljaCBpcyBoYXNoZWQgaW50byB0aGUgRUtNIHNlZWQuICBUaGlzIGlzIGF0IGxlYXN0 IGEgdGhpcmQgbGV2ZWwgb2YgaGFzaGluZywgYW5kIHdpdGggcmVwZWF0ZWQgcGFyYW1ldGVycy4g IEkndmUgaGVhcmQgbWF0aGVtYXRpY2lhbnMgcHJlZmVyIHRvIGFuYWx5emUgYSBwcm90b2NvbCB3 aXRoIGV2ZXJ5dGhpbmcgaGFzaGVkIGF0IG9uY2UsIGJ1dCBpbiB0aGlzIGNhc2UsIGhhc2hpbmcg aW4gcGFyYW1ldGVycyBmcm9tIHRoZSBoYW5kc2hha2UgcmVhbGx5IGlzIHJlZHVuZGFudC4NCg0K QmlsbA0K --_000_CY1PR0301MB08423E8541185B5E48F1D7448CE00CY1PR0301MB0842_ 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 IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBUb2tlbkJpbmRpbmdLZXlQYXJhbWV0ZXJzIHZhbHVl IGlzIG5vdCBuZWNlc3NhcmlseSBpbiB0aGUgVExTIGhhbmRzaGFrZSBoYXNoIChlLmcuIGZvciBy ZWZlcnJlZCBiaW5kaW5ncykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBQcm90b2NvbFZlcnNpb24gdmFs dWUgaXMgb25seSBpbiB0aGUgVExTIGhhbmRzaGFrZSBpZiB3ZSBrZWVwIGl0IGluIHRoZSB0b2tl bl9iaW5kaW5nIGV4dGVuc2lvbiAod2hpY2ggSSBob3BlIHdlIHdpbGwpLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5JIGRvbuKAmXQgaW1tZWRpYXRlbHkgc2VlIHdoeSB0aGlzIGlkZWEgd291bGRu4oCZdCB3b3Jr LCBhbmQgaXQgZWxpbWluYXRlcyBvbmUgaGFzaCBvcGVyYXRpb24sIGJ1dCBJIHRoaW5rIHdlIGhh dmUgdG8gc3VwcGx5IGF0IGxlYXN0DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Ub2tlbkJpbmRp bmdUeXBlIGFuZCBUb2tlbkJpbmRpbmdLZXlQYXJhbWV0ZXJzIGFzIHRoZSBFS00gY29udGV4dDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IEJpbGwgQ294IFttYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMzAsIDIwMTYgMjozOCBQTTxi cj4NCjxiPlRvOjwvYj4gQW5kcmVpIFBvcG92ICZsdDtBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNv bSZndDs8YnI+DQo8Yj5DYzo8L2I+IExlaWYgSm9oYW5zc29uICZsdDtsZWlmakBzdW5ldC5zZSZn dDs7IFRva2JpbmQgV0cgJmx0O3VuYmVhcmFibGVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gRHVtYiBpZGVhOiBhZGQgRWQyNTUxOSBzdXBwb3J0Pzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVl LCBBdWcgMzAsIDIwMTYgYXQgMjozMyBQTSwgQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWls dG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9w b3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHdlIGNvbmNhdGVuYXRlOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJz cDsgbyZuYnNwOyBBIFByb3RvY29sVmVyc2lvbiBzdHJ1Y3R1cmUgcmVwcmVzZW50aW5nIHRoZSBu ZWdvdGlhdGVkIHZlcnNpb24gb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNw O3RoZSBUb2tlbiBCaW5kaW5nIHByb3RvY29sLCBlLmcuIDB4MDEgMHgwMCBmb3IgVG9rZW4gQmlu ZGluZyAxLjA7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFRva2VuQmluZGluZ1R5cGUgdmFs dWUgY29udGFpbmVkIGluIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg VG9rZW5CaW5kaW5nLnRva2VuYmluZGluZ190eXBlIGZpZWxkOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsg byZuYnNwOyBUb2tlbkJpbmRpbmdLZXlQYXJhbWV0ZXJzIHZhbHVlIGNvbnRhaW5lZCBpbiB0aGU8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRva2VuQmluZGluZ0lELmtleV9w YXJhbWV0ZXJzIGZpZWxkOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kIHVzZSB0aGUgcmVzdWx0IGFz IG91ciBFS00gY29udGV4dCB2YWx1ZSwgYW5kIHRoZW4ganVzdCBzaWduIHRoZSByZXN1bHRpbmcg RUtNPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIHRob3VnaCBJIGFsc28gaGF0ZSB0 byBkb3VibGUtaGFzaCB2YWx1ZXMuJm5ic3A7IFRoZSBwcm90b2NvbCB2ZXJzaW9uIGFuZCBrZXkg cGFyYW1ldGVycyBhcmUgYWxyZWFkeSBoYXNoZWQgaW50byB0aGUgaGFuZHNoYWtlIGhhc2gsIHdo aWNoIGlzIGhhc2hlZCBpbnRvIHRoZSBFS00gc2VlZC4mbmJzcDsgVGhpcyBpcyBhdCBsZWFzdCBh IHRoaXJkIGxldmVsIG9mIGhhc2hpbmcsIGFuZCB3aXRoIHJlcGVhdGVkIHBhcmFtZXRlcnMuJm5i c3A7DQogSSd2ZSBoZWFyZCBtYXRoZW1hdGljaWFucyBwcmVmZXIgdG8gYW5hbHl6ZSBhIHByb3Rv Y29sIHdpdGggZXZlcnl0aGluZyBoYXNoZWQgYXQgb25jZSwgYnV0IGluIHRoaXMgY2FzZSwgaGFz aGluZyBpbiBwYXJhbWV0ZXJzIGZyb20gdGhlIGhhbmRzaGFrZSByZWFsbHkgaXMgcmVkdW5kYW50 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C aWxsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR0301MB08423E8541185B5E48F1D7448CE00CY1PR0301MB0842_-- From nobody Tue Aug 30 15:02: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 5F2F512D0BF for ; Tue, 30 Aug 2016 15:02:16 -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 6g1z6a7HGCjU for ; Tue, 30 Aug 2016 15:02:13 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 7F97A12B03B for ; Tue, 30 Aug 2016 15:02:13 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id g62so63707623ith.1 for ; Tue, 30 Aug 2016 15:02:13 -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=L/2SvihZwWCdjGX4PtE9rmrOUEHN7qJoJvXfw8mT85k=; b=COaAMF8sN2VmzEhXOF+cZNNbLjPqPgROMxh0Jc2stZaa/iIG7CsFRFxyXEWiKugIzL FarMsl62QM4+OiE+qko8xX/ZtWVXSXccDohJvPGTvYgFpz+fTnJkXJjSTPifzhFPbUsu 9WbBX9gJfDCK89HYdYTRSjg2Z9R/9Mbk/VeZI= 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=L/2SvihZwWCdjGX4PtE9rmrOUEHN7qJoJvXfw8mT85k=; b=XZWpHIr8DpepvJbQvCysZfmFd/QI4yY4kTKMh5kdyf6D6DHCesfLfuFCVLczUB43ww JzPvFH2qfjlnpLbS6Q5Fj4aOxfE3RV21/qY2vPvY2jLgUDddO+grAGWkzGVka1mzvIrS auzBaiZUTMKix82cc65dv/yylPwupqW7mhlS6shMxrHf0QnuOU7jBujvwv8E8fUrzD+G P689FUUNigu5roodiBHgzCPcgBJXZDyKP3M6Dd14Ah3VLvk+D9VR1xxBbVaJwfhGiXqT jOieYnWQsF+gnD9OxwDAO+fhS9PUcS9EAJM569YoYWs527/seNZDxpSvbQYF4E1pxfu9 TrJw== X-Gm-Message-State: AE9vXwNWGnqXQOJFi8He9RdfiqGXK6NmTLZpIrJvnPn1o0tTugXIRuLNO6sLtqlGFwSyimwJf03HT9Hjp2Z0gvir X-Received: by 10.36.206.129 with SMTP id v123mr28178508itg.11.1472594532809; Tue, 30 Aug 2016 15:02:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.114.20 with HTTP; Tue, 30 Aug 2016 15:01:42 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Tue, 30 Aug 2016 16:01:42 -0600 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=94eb2c0af9fc06fcee053b512236 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Hashing & signatures in TBPROTO-9 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, 30 Aug 2016 22:02:16 -0000 --94eb2c0af9fc06fcee053b512236 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 30, 2016 at 12:27 PM, Andrei Popov wrote: > =C3=98 And both RSA signature schemes 'MUST use the SHA256 hash algorith= m'. > While, when an ecdsap256 key is used, ECDSA with P-256 is used with no ha= sh > algorithm. > > PSS and PKCS padding schemes are defined with a lot of flexibility, so we > have to specify the hash function to be used by these padding schemes. > > ECDSA signing does not require padding, so there is no need to specify th= e > hash algorithm. > ECDSA can be, and generally is, used with a hash algorithm though (of similar strength). Like in JOSE or XML Signatures , for example. From the prospective of a a silly little Java programmer such as myself, I get a signature instance from the platform using the names, "SHA256withECDSA", "SHA384withECDSA", and "SHA512withECDSA" for the JOSE and "NONEwithECDSA" for TokenBinding (interop tested with Chrome). My understanding is that hash algorithm is used so that messages larger than the 'raw' signature scheme would otherwise handle can be used. To be honest, I got confused about the size ECDSA with P-256 could handle and was thinking that label + version + type + key params + EKM without hashing would be too large. And that ECDSA with P-256 with SHA256 would be needed, if the hashing of the concatenation was removed, which is what I was really aiming for. > > =C3=98 The signature is now computed over the SHA256 hash of the > concatenation of a few of things (label, version, type, key params, EKM). > > Correct, this is to prevent potential attacks that folks have pointed out= . > Including the various different bits of information in what is singed is what prevents such attacks, right? What is the hash for? > This is independent of the signature algorithms and padding schemes that > we negotiate via TB key parameters. > > > > Does this make sense? > Much of it does, yes. Thanks. But I don't understand why the hash is applied to the concatenation of the label, version, type, key params, & EKM rather than using the concatenation directly as the signing input? Similar maybe to Bill's recent question but looking at it a little different I was trying to see if we could get rid of that hashing step in the core protocol - that would give better cryto agility to the core spec and have marginally better performance. Cheers, > > > > Andrei > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Br= ian > Campbell > *Sent:* Tuesday, August 30, 2016 10:11 AM > *To:* IETF Tokbind WG > *Subject:* [Unbearable] Hashing & signatures in TBPROTO-9 > > > > Resulting from issues #67 > and #70 > (I think > anyway) are some new rules for calculating the Token Binding signature > (mostly in sec 3.3 of TBPROTO-9 > )= . > The signature is now computed over the SHA256 hash of the concatenation o= f > a few of things (label, version, type, key params, EKM). And both RSA > signature schemes 'MUST use the SHA256 hash algorithm'. While, when an > ecdsap256 key is used, ECDSA with P-256 is used with no hash algorithm. > > I guess my question is, now that the signature input is larger than just > the 32 byte EKM and the RSA algs are using SHA256, wouldn't it make sense > and be more consistent to use the concatenation of those items directly a= s > the input into the signature and, when an ecdsap256 key is used, calculat= e > the signature with ECDSA using P-256 and SHA256? That'd mean that TBPROTO > wouldn't directly use SHA256 but rather the hashing is pushed into the > definition of how to do the signature for each key parameters type, which > is arguably more cryptographically agile. It'd also be one less round of > hashing for the RSA signature schemes. > > Or am I off the rails here? > > > > > > > > > --94eb2c0af9fc06fcee053b512236 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 30, 2016 at 12:27 PM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

=C3=98=C2=A0 And both RSA signature schemes 'MUST use the SHA25= 6 hash algorithm'. While, when an ecdsap256 key is used, ECDSA with P-2= 56 is used with no hash algorithm.=C2=A0

PSS and PKCS padding schemes are defined with a l= ot of flexibility, so we have to specify the hash function to be used by th= ese padding schemes.

ECDSA signing does not require padding, so there is n= o need to specify the hash algorithm.


ECDSA can be, and generally is, used with a hash algorith= m though (of similar strength).=C2=A0 Like in JOSE or XML Signatur= es, for example. From the prospective of a a silly little Java programm= er such as myself, I get a signature instance from the platform using the n= ames, "SHA256withECDSA", "SHA384withECDSA", and "S= HA512withECDSA" for the JOSE and "NONEwithECDSA" for TokenBi= nding (interop tested with Chrome). My understanding is that hash algorithm= is used so that messages larger than the 'raw' signature scheme wo= uld otherwise handle can be used. To be honest, I got confused about the si= ze ECDSA with P-256 could handle and was thinking that label + version + ty= pe + key params + EKM without hashing would be too large. And that ECDSA wi= th P-256 with SHA256 would be needed, if the hashing of the concatenation w= as removed, which is what I was really aiming for.=C2=A0
=C2= =A0


= <= u>

=C2=A0

=C3=98= =C2=A0 The signature is now computed over the SHA256 h= ash of the concatenation of a few of things (label, version, type, key para= ms, EKM).

Correct, this is to prevent potential attacks that fo= lks have pointed out.


Including the various different bits of information in what is singed is = what prevents such attacks, right? What is the hash for?

=
=C2=A0

This = is independent of the signature algorithms and padding schemes that we nego= tiate via TB key parameters.

=C2=A0

Does this make sense?


Much of it does, yes. Thanks.

But I don'= ;t understand why the hash is applied to the concatenation of the label, ve= rsion, type, key params, & EKM rather than using the concatenation dire= ctly as the signing input? Similar maybe to Bill's recent question but looking at it a little different I was = trying to see if we could get rid of that hashing step in the core protocol= - that would give better cryto agility to the core spec and have marginall= y better performance.=C2=A0

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Tuesday, August 30, 2016 10:11 AM
To: IETF Tokbind WG <unbearable@ietf.org>
Subject: [Unbearable] Hashing & signatures in TBPROTO-9

=C2=A0

Resulting from issues <= a href=3D"https://github.com/TokenBinding/Internet-Drafts/issues/67" target= =3D"_blank"> #67 and #70 (I think anyway) are some new rules for ca= lculating the Token Binding signature (mostly in sec 3.3 of TBPROTO-9). The signature is now computed over the SHA256 ha= sh of the concatenation of a few of things (label, version, type, key param= s, EKM). And both RSA signature schemes 'MUST use the SHA256 hash algor= ithm'. While, when an ecdsap256 key is used, ECDSA with P-256 is used with no hash algorithm.

I guess my question is,= now that the signature input is larger than just the 32 byte EKM and the R= SA algs are using SHA256, wouldn't it make sense and be more consistent= to use the concatenation of those items directly as the input into the signature and, when an ecdsap256 key is use= d, calculate the signature with ECDSA using P-256 and SHA256? That'd me= an that TBPROTO wouldn't directly use SHA256 but rather the hashing is = pushed into the definition of how to do the signature for each key parameters type, which is arguably more cryptog= raphically agile. It'd also be one less round of hashing for the RSA si= gnature schemes.

Or am I off the rails here?

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--94eb2c0af9fc06fcee053b512236-- From nobody Tue Aug 30 15:07:07 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 5C8B712D0BF for ; Tue, 30 Aug 2016 15:07:06 -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 8vbQ2VUEuUYL for ; Tue, 30 Aug 2016 15:07:04 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 4C04912B044 for ; Tue, 30 Aug 2016 15:07:04 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id e124so9643229ith.0 for ; Tue, 30 Aug 2016 15:07:03 -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=SpMsW2jQuNiz3o+3LwkdDE/Vb7LsKUotnW/N9UAZMok=; b=KGPf8nYdfKxtx0oaKB9SKlT21H0w9uCqEQavx9IOPHM7lbNx1AdofpDvTeoF/QgRpd QAjHeExG/Omx3CK7vDXqxLNEYjTBqTYaXciJ3TVsi5YZrjsFdBQqgXAEZ+U4nneMzmtE P0xQChuC51sCpWpJa7q8i5DkwHdvqY1vDLjUY= 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=SpMsW2jQuNiz3o+3LwkdDE/Vb7LsKUotnW/N9UAZMok=; b=b0Q0k7JaBXxzjSMKMKzAjOoLDK4F8hyc4BwW7+7Oj/1yw9w9WkygOKW7Di0UjR8PeU yBqfsYt6HYiQ3XpKxo/B0zlyxzgS6RnPL8CGgiBG5odTwWSe7zVbN47kHSnMfQAb4Srq PtSER96nMKhw7Znf+HZxXwfL1eDZ+CBsiTLlZeNnVICa530qQZ+QpkWEp5IUHMN7IBd7 6f6jm7ioHOR2abY/tdZXQ0CVm5Nv8/J+AmVp6xVstz4xBzoZ/4o2WZminCsv8JEwKFlw YM80HcTVM/e7ZblL0VvA8Jmz22I4DFW9TbkO0cb/UGy9p5X06O/z5zEGdsm3UB19RoMq z5uQ== X-Gm-Message-State: AE9vXwPNORBQXUOdeDInA+UjUbbXdHEwlwoz22VDcBPVZg2J/LBxKUlg1u40MbbtV7yRBFOZGoYf01S+LQ8cJQrz X-Received: by 10.107.15.156 with SMTP id 28mr1775712iop.95.1472594823262; Tue, 30 Aug 2016 15:07:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.114.20 with HTTP; Tue, 30 Aug 2016 15:06:32 -0700 (PDT) In-Reply-To: References: <96c11d53-03c0-bcc3-92e1-ea73ce4d6a57@sunet.se> From: Brian Campbell Date: Tue, 30 Aug 2016 16:06:32 -0600 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a113edada56d206053b513343 Archived-At: Cc: "unbearable@ietf.org" , Leif Johansson Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? 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, 30 Aug 2016 22:07:06 -0000 --001a113edada56d206053b513343 Content-Type: text/plain; charset=UTF-8 +1 to a new I-D specifying a new TokenBindingKeyParameters identifier for Ed25519. It'd be a good proof point that the extension hooks in the core specs are correct. Likewise as an implementer, I don't envision supporting Ed25519 TB keys in the reasonably foreseeable future. On Tue, Aug 30, 2016 at 3:27 PM, Andrei Popov wrote: > Perhaps this could be a new I-D specifying a new TokenBindingKeyParameters > identifier. > > Speaking as an implementer, MS has no plans to support Ed25519 TB keys in > the foreseeable future. > > Cheers, > > Andrei > > -----Original Message----- > From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Leif > Johansson > Sent: Tuesday, August 30, 2016 2:19 PM > To: unbearable@ietf.org > Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? > > On 2016-08-30 22:41, Bill Cox wrote: > > I hate to offer yet another possible upgrade to TB, but I really would > > prefer to use Ed25519 by default. I see QUIC is already using it, and > > it seems a bit silly not to enable it in TB, when I've already > > implemented support for the other three. Should we add Ed25519-SHA256 > > as a 4th key parameters type? > > We should certainly make sure the specs can swallow something like this as > an extension but in order to hold up the specs at this point with a > substantial addition I would like (with chair hat on) to see pretty strong > statements of support from implementors. > > Cheers Leif > > > _______________________________________________ > 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 > --001a113edada56d206053b513343 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to a new I-D specifying a new TokenBindingKeyParam= eters identifier for Ed25519. It'd be a good proof point that the exten= sion hooks in the core specs are correct.

Likewise as an impl= ementer, I don't envision supporting Ed25519 TB keys in the reasonably = foreseeable future.

On Tue, Aug 30, 2016 at 3:27 PM, Andrei Popov <Andre= i.Popov@microsoft.com> wrote:
Perhaps this could be a new I-D specifying a new TokenBindingKeyParamete= rs identifier.

Speaking as an implementer, MS has no plans to support Ed25519 TB keys in t= he foreseeable future.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:unb= earable-bounces@ietf.org] On Behalf Of Leif Johansson
Sent: Tuesday, August 30, 2016 2:19 PM
To: unbearable@ietf.org
Subject: Re: [Unbearable] Dumb idea: add Ed25519 support?

On 2016-08-30 22:41, Bill Co= x wrote:
> I hate to offer yet another possible upgrade to TB, but I really would=
> prefer to use Ed25519 by default.=C2=A0 I see QUIC is already using it= , and
> it seems a bit silly not to enable it in TB, when I've already
> implemented support for the other three.=C2=A0 Should we add Ed25519-S= HA256
> as a 4th key parameters type?

We should certainly make sure the specs can swallow something like this as = an extension but in order to hold up the specs at this point with a substan= tial addition I would like (with chair hat on) to see pretty strong stateme= nts of support from implementors.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Cheers Leif


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

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

--001a113edada56d206053b513343-- From nobody Tue Aug 30 15:21: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 8BBFC12D82E for ; Tue, 30 Aug 2016 15:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 7gXerv9XOM3x for ; Tue, 30 Aug 2016 15:21:00 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (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 3DDE712D82D for ; Tue, 30 Aug 2016 15:20:58 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id i32so57982864uai.2 for ; Tue, 30 Aug 2016 15:20:58 -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=COEQ43m8Soy++4bWvEetWXGfohdW5c1jGRqt2Kg4jEM=; b=nlt1K9GsAvga8tq0MqB8uCv6VhsInEN9kDiUIjuNqOFqAfZdGFzA9252B5tr1S004J JRAMWoqPZYRJD/RBi0VZ6vIL1+v7s/3VrcWoriA4H1bE8vUHMA8WJ11VW+NCTnrbNW0g jCpXrvvyzjORM82ebobHojbiFhL23/TgcRnOSKT5qP9uvnJkG8fGtRcvD/5xdHulte4p OmTcJ2AWOCQRnQ2mTgCq78s4kJFLCgWxA7hsJpXIHHeWUwRaJ1q5pvn+dUEEJvay1gvo 3DixDI8CzY6+fazovZcdA1Ya55LVtHaY/+YavUlDAnrbzZo9wKWuhSw0N4jewqG79vi+ krFg== 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=COEQ43m8Soy++4bWvEetWXGfohdW5c1jGRqt2Kg4jEM=; b=NGjoua9nWDVZh04osF+0o4zGy42I88lB+kiMqxQh50SngrdbsHw8ARk8CW6jvXUka1 tH7P5Qo6FdW2HLehNt3qWFE+05H5IXXPqDNOTRUpvl9UqFPpKeakXXbtNeqr/egg+vo3 GCmnXwXyKPB3NqbUB/2Opt04IZTtN6QHFVJNdiZHm/24BZKQAU1mDSqUN+GMa3jruNiO l+lsUthbOGiBaxt+PmC8L819t7vehfz7Im9gt4LZ+QIt2Db8mtYRzReCRc5PoIjE2CHf 4BodHA+XO/0pd6p9+4JPrlCesRVfwEEG8uRs+8GpfeayfF0dwLlYXOsvDtSNm+Cgs9BD SusQ== X-Gm-Message-State: AE9vXwN90tzvkog9zGrMSioxWQPZbXUekoNGMD/jML165FVG5WMrnf4l6nTTUWc/UTryj3Lg8QY6uiBw6j0jUqLL X-Received: by 10.176.2.70 with SMTP id 64mr3118913uas.79.1472595657244; Tue, 30 Aug 2016 15:20:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.97.2 with HTTP; Tue, 30 Aug 2016 15:20:56 -0700 (PDT) In-Reply-To: References: <96c11d53-03c0-bcc3-92e1-ea73ce4d6a57@sunet.se> From: Bill Cox Date: Tue, 30 Aug 2016 15:20:56 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a113e057c0c8929053b5165bc Archived-At: Cc: Tokbind WG , Leif Johansson Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? 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, 30 Aug 2016 22:21:02 -0000 --001a113e057c0c8929053b5165bc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 30, 2016 at 2:49 PM, Andrei Popov wrote: > The TokenBindingKeyParameters value is not necessarily in the TLS > handshake hash (e.g. for referred bindings). > > > > The ProtocolVersion value is only in the TLS handshake if we keep it in > the token_binding extension (which I hope we will). > > > > I don=E2=80=99t immediately see why this idea wouldn=E2=80=99t work, and = it eliminates one > hash operation, but I think we have to supply at least TokenBindingType > and TokenBindingKeyParameters as the EKM context. > I guess I would prefer this, just for the reduction of one hash operation. Bill --001a113e057c0c8929053b5165bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Aug 30, 2016 at 2:49 PM, Andrei Popov <Andrei.Popov@microsoft= .com> wrote:

The TokenBindingKeyParameters value is not necessar= ily in the TLS handshake hash (e.g. for referred bindings).

=C2=A0

The ProtocolVersion value is only in the TLS handsh= ake if we keep it in the token_binding extension (which I hope we will).=

=C2=A0

I don=E2=80=99t immediately see why this idea would= n=E2=80=99t work, and it eliminates one hash operation, but I think we have= to supply at least TokenBindingType and TokenBindingKeyParameters as the EKM context.


I guess I wo= uld prefer this, just for the reduction of one hash operation.
Bill=C2=A0
--001a113e057c0c8929053b5165bc-- From nobody Tue Aug 30 15:21:14 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 5EC4F12D7DE for ; Tue, 30 Aug 2016 15:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 X9l_0EX48nmu for ; Tue, 30 Aug 2016 15:21:09 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0124.outbound.protection.outlook.com [104.47.32.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7598C12D82D for ; Tue, 30 Aug 2016 15:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9EOiGKd3EM5K0b68xBCC+W4VRx7TwcWVU7ATe1Z4jQ4=; b=i2LXR178PnQb6FhaQHYCzV6qGbHkHl3I1oKrvVnaywXymGIhubw2vDMCCQ+79Enu+E42t3AVQncy4A/9FO09+338kdcyJGb1q5QwPH/z+OcAGlcokkBykQFUzr/j6VCqC9yX4ptS+riBojTQz79cshWcYVUi8f6rSxaIxT4lLyY= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Tue, 30 Aug 2016 22:21:06 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Tue, 30 Aug 2016 22:21:06 +0000 From: Andrei Popov To: Brian Campbell Thread-Topic: [Unbearable] Hashing & signatures in TBPROTO-9 Thread-Index: AQHSAuGcxIQ0j5CaOEOdydsG7FDI+qBhz61ggAA+vgCAAAD+sA== Date: Tue, 30 Aug 2016 22:21:06 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: d4f2c71e-ff00-40c8-c865-08d3d123efef x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 6:TeS+RVm+IOPQhwqEeziRG/2HNlr5HA0ooxxqPPer9+6K2889Fj/nM1CPXOvfiztyVSfHZQE5Az4laECuiKw7Fy70PZRNCoWPGMtyIgh5lqtu2zgeixqWeDClvRrcpYZv1vNq5vQKrqsrnfERd9TNxv9BfulJ8oNwBjqkFxbTzAZwFblR/VCmMTP5sO/9tt/nz7Vv6EReRlaxRcBTMIYK0jgSV87jpiTqOAZTYfQaSQFb+bZMhH9UIq1NeBPRVOO0MdlyxPDpyeA5LU13GdBCOOWE2HMMRsQEPSpFebl0Kjg+wwL+juOwj2WjFixJSz6uloqEj9vX4syn0bVtipHtFg==; 5:qGJ/EO6ontm/78Sdg1OJmFHkrtN9vryGp8QF11d+/Ayd/x5A/PYvYpgvrMlOrKYOE2z4LHVuUiWsKccFoev6PQdU1RgNQUFBdDtIhZM/J0lLtNN8RabYoDc/KBot7zBrhEJ0b97VeqFnoO+kDxqJYg==; 24:6XrJAxYt7Look1vzaIYlyFabqRrCEAx6MQIHETF4c2z5Sp709lxipmfU4K8N5kBUzKSAjJ5YwR33lXaEj7khkCjbgVRWL0PuISvlS9kdsDo=; 7:svBM0u+1t71KbiLQwiEQL0gzrKdhbOpsmFkD6rRZwkdZQB3w14ynKEwFmzhtUvEGOV7OFcTTSOCTpQoMGIXtrv0c3+oXN9s3Bm/j6UPwYccJC8ZFpzQJjGc+G4hREWarKM2lteseAr6GIKQwg/mu7BifAAVYUWCi7Zy5qwh9H83LMNSUlJp0OioL2B7ninB65asvknNq1LxZc24+nJnZF7v2+nBIP2m1wwQ8OLY5NpqqhEJuYmrtWF0dYNxkHg0Y x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0842; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 0050CEFE70 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(377454003)(24454002)(74316002)(7906003)(10400500002)(76176999)(9686002)(7736002)(7696003)(106116001)(8990500004)(33656002)(101416001)(50986999)(7846002)(54356999)(16236675004)(11100500001)(3660700001)(561944003)(10090500001)(81166006)(8676002)(68736007)(99286002)(81156014)(19609705001)(790700001)(102836003)(5660300001)(586003)(106356001)(4326007)(6116002)(77096005)(122556002)(15975445007)(86362001)(76576001)(5002640100001)(92566002)(110136002)(19625215002)(2950100001)(8936002)(10290500002)(19300405004)(105586002)(5005710100001)(19580395003)(87936001)(86612001)(2900100001)(19617315012)(19580405001)(97736004)(3280700002)(2906002)(189998001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842B4556523D670E362A8338CE00CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2016 22:21:06.7140 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Hashing & signatures in TBPROTO-9 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, 30 Aug 2016 22:21:13 -0000 --_000_CY1PR0301MB0842B4556523D670E362A8338CE00CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGFzaGluZyBiZWZvcmUgc2lnbmluZyBpcyBnZW5lcmFsbHkgdXNlZnVsLCBiZWNhdXNlIGl0IGJy aW5ncyB0aGUgZGF0YSB0byBhbiBhY2NlcHRhYmxlIHNpemUgZm9yIHRoZSBzaWduYXR1cmUgYWxn b3JpdGhtLCBhbmQgYWxzbyBpdCBtYXkgYmUgY2hlYXBlciB0byBoYXNoIGFuZCB0aGVuIHNpZ24u DQoNCkJ1dCB0aGlzIGlzIGFsbCBtb290IGlmIHdlIGFkb3B0IEJpbGzigJlzIHByb3Bvc2FsIGFu ZCBwdXQgdGhlIGNvbmNhdGVuYXRlZCB2YWx1ZXMgaW4gdGhlIEVLTSBjb250ZXh0Lg0KDQpGcm9t OiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tXQ0KU2Vu dDogVHVlc2RheSwgQXVndXN0IDMwLCAyMDE2IDM6MDIgUE0NClRvOiBBbmRyZWkgUG9wb3YgPEFu ZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPg0KQ2M6IElFVEYgVG9rYmluZCBXRyA8dW5iZWFyYWJs ZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gSGFzaGluZyAmIHNpZ25hdHVy ZXMgaW4gVEJQUk9UTy05DQoNCg0KDQpPbiBUdWUsIEF1ZyAzMCwgMjAxNiBhdCAxMjoyNyBQTSwg QW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBv cG92QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KPiAgQW5kIGJvdGggUlNBIHNpZ25hdHVyZSBz Y2hlbWVzICdNVVNUIHVzZSB0aGUgU0hBMjU2IGhhc2ggYWxnb3JpdGhtJy4gV2hpbGUsIHdoZW4g YW4gZWNkc2FwMjU2IGtleSBpcyB1c2VkLCBFQ0RTQSB3aXRoIFAtMjU2IGlzIHVzZWQgd2l0aCBu byBoYXNoIGFsZ29yaXRobS4NClBTUyBhbmQgUEtDUyBwYWRkaW5nIHNjaGVtZXMgYXJlIGRlZmlu ZWQgd2l0aCBhIGxvdCBvZiBmbGV4aWJpbGl0eSwgc28gd2UgaGF2ZSB0byBzcGVjaWZ5IHRoZSBo YXNoIGZ1bmN0aW9uIHRvIGJlIHVzZWQgYnkgdGhlc2UgcGFkZGluZyBzY2hlbWVzLg0KRUNEU0Eg c2lnbmluZyBkb2VzIG5vdCByZXF1aXJlIHBhZGRpbmcsIHNvIHRoZXJlIGlzIG5vIG5lZWQgdG8g c3BlY2lmeSB0aGUgaGFzaCBhbGdvcml0aG0uDQoNCkVDRFNBIGNhbiBiZSwgYW5kIGdlbmVyYWxs eSBpcywgdXNlZCB3aXRoIGEgaGFzaCBhbGdvcml0aG0gdGhvdWdoIChvZiBzaW1pbGFyIHN0cmVu Z3RoKS4gIExpa2UgaW4gSk9TRTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzUxOCNz ZWN0aW9uLTMuND4gb3IgWE1MIFNpZ25hdHVyZXM8aHR0cHM6Ly93d3cudzMub3JnL1RSL3htbGRz aWctY29yZTEvI3NlYy1FQ0RTQT4sIGZvciBleGFtcGxlLiBGcm9tIHRoZSBwcm9zcGVjdGl2ZSBv ZiBhIGEgc2lsbHkgbGl0dGxlIEphdmEgcHJvZ3JhbW1lciBzdWNoIGFzIG15c2VsZiwgSSBnZXQg YSBzaWduYXR1cmUgaW5zdGFuY2UgZnJvbSB0aGUgcGxhdGZvcm0gdXNpbmcgdGhlIG5hbWVzLCAi U0hBMjU2d2l0aEVDRFNBIiwgIlNIQTM4NHdpdGhFQ0RTQSIsIGFuZCAiU0hBNTEyd2l0aEVDRFNB IiBmb3IgdGhlIEpPU0UgYW5kICJOT05Fd2l0aEVDRFNBIiBmb3IgVG9rZW5CaW5kaW5nIChpbnRl cm9wIHRlc3RlZCB3aXRoIENocm9tZSkuIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBoYXNoIGFs Z29yaXRobSBpcyB1c2VkIHNvIHRoYXQgbWVzc2FnZXMgbGFyZ2VyIHRoYW4gdGhlICdyYXcnIHNp Z25hdHVyZSBzY2hlbWUgd291bGQgb3RoZXJ3aXNlIGhhbmRsZSBjYW4gYmUgdXNlZC4gVG8gYmUg aG9uZXN0LCBJIGdvdCBjb25mdXNlZCBhYm91dCB0aGUgc2l6ZSBFQ0RTQSB3aXRoIFAtMjU2IGNv dWxkIGhhbmRsZSBhbmQgd2FzIHRoaW5raW5nIHRoYXQgbGFiZWwgKyB2ZXJzaW9uICsgdHlwZSAr IGtleSBwYXJhbXMgKyBFS00gd2l0aG91dCBoYXNoaW5nIHdvdWxkIGJlIHRvbyBsYXJnZS4gQW5k IHRoYXQgRUNEU0Egd2l0aCBQLTI1NiB3aXRoIFNIQTI1NiB3b3VsZCBiZSBuZWVkZWQsIGlmIHRo ZSBoYXNoaW5nIG9mIHRoZSBjb25jYXRlbmF0aW9uIHdhcyByZW1vdmVkLCB3aGljaCBpcyB3aGF0 IEkgd2FzIHJlYWxseSBhaW1pbmcgZm9yLg0KDQoNCg0KDQo+ICBUaGUgc2lnbmF0dXJlIGlzIG5v dyBjb21wdXRlZCBvdmVyIHRoZSBTSEEyNTYgaGFzaCBvZiB0aGUgY29uY2F0ZW5hdGlvbiBvZiBh IGZldyBvZiB0aGluZ3MgKGxhYmVsLCB2ZXJzaW9uLCB0eXBlLCBrZXkgcGFyYW1zLCBFS00pLg0K Q29ycmVjdCwgdGhpcyBpcyB0byBwcmV2ZW50IHBvdGVudGlhbCBhdHRhY2tzIHRoYXQgZm9sa3Mg aGF2ZSBwb2ludGVkIG91dC4NCg0KSW5jbHVkaW5nIHRoZSB2YXJpb3VzIGRpZmZlcmVudCBiaXRz IG9mIGluZm9ybWF0aW9uIGluIHdoYXQgaXMgc2luZ2VkIGlzIHdoYXQgcHJldmVudHMgc3VjaCBh dHRhY2tzLCByaWdodD8gV2hhdCBpcyB0aGUgaGFzaCBmb3I/DQoNCg0KDQpUaGlzIGlzIGluZGVw ZW5kZW50IG9mIHRoZSBzaWduYXR1cmUgYWxnb3JpdGhtcyBhbmQgcGFkZGluZyBzY2hlbWVzIHRo YXQgd2UgbmVnb3RpYXRlIHZpYSBUQiBrZXkgcGFyYW1ldGVycy4NCg0KRG9lcyB0aGlzIG1ha2Ug c2Vuc2U/DQoNCk11Y2ggb2YgaXQgZG9lcywgeWVzLiBUaGFua3MuDQoNCkJ1dCBJIGRvbid0IHVu ZGVyc3RhbmQgd2h5IHRoZSBoYXNoIGlzIGFwcGxpZWQgdG8gdGhlIGNvbmNhdGVuYXRpb24gb2Yg dGhlIGxhYmVsLCB2ZXJzaW9uLCB0eXBlLCBrZXkgcGFyYW1zLCAmIEVLTSByYXRoZXIgdGhhbiB1 c2luZyB0aGUgY29uY2F0ZW5hdGlvbiBkaXJlY3RseSBhcyB0aGUgc2lnbmluZyBpbnB1dD8gU2lt aWxhciBtYXliZSB0byBCaWxsJ3MgcmVjZW50IHF1ZXN0aW9uPGh0dHBzOi8vbWFpbGFyY2hpdmUu aWV0Zi5vcmcvYXJjaC9tc2cvdW5iZWFyYWJsZS8zTXc4VTJqV2M3bTJhanlFVGFfdE9CX2JEUVk+ IGJ1dCBsb29raW5nIGF0IGl0IGEgbGl0dGxlIGRpZmZlcmVudCBJIHdhcyB0cnlpbmcgdG8gc2Vl IGlmIHdlIGNvdWxkIGdldCByaWQgb2YgdGhhdCBoYXNoaW5nIHN0ZXAgaW4gdGhlIGNvcmUgcHJv dG9jb2wgLSB0aGF0IHdvdWxkIGdpdmUgYmV0dGVyIGNyeXRvIGFnaWxpdHkgdG8gdGhlIGNvcmUg c3BlYyBhbmQgaGF2ZSBtYXJnaW5hbGx5IGJldHRlciBwZXJmb3JtYW5jZS4NCg0KDQpDaGVlcnMs DQoNCkFuZHJlaQ0KDQpGcm9tOiBVbmJlYXJhYmxlIFttYWlsdG86dW5iZWFyYWJsZS1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYg T2YgQnJpYW4gQ2FtcGJlbGwNClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAzMCwgMjAxNiAxMDoxMSBB TQ0KVG86IElFVEYgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86dW5iZWFy YWJsZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbVW5iZWFyYWJsZV0gSGFzaGluZyAmIHNpZ25hdHVy ZXMgaW4gVEJQUk9UTy05DQoNClJlc3VsdGluZyBmcm9tIGlzc3VlcyAjNjc8aHR0cHM6Ly9naXRo dWIuY29tL1Rva2VuQmluZGluZy9JbnRlcm5ldC1EcmFmdHMvaXNzdWVzLzY3PiBhbmQgIzcwPGh0 dHBzOi8vZ2l0aHViLmNvbS9Ub2tlbkJpbmRpbmcvSW50ZXJuZXQtRHJhZnRzL2lzc3Vlcy83MD4g KEkgdGhpbmsgYW55d2F5KSBhcmUgc29tZSBuZXcgcnVsZXMgZm9yIGNhbGN1bGF0aW5nIHRoZSBU b2tlbiBCaW5kaW5nIHNpZ25hdHVyZSAobW9zdGx5IGluIHNlYyAzLjMgb2YgVEJQUk9UTy05PGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQtcHJvdG9jb2wtMDkj c2VjdGlvbi0zLjM+KS4gVGhlIHNpZ25hdHVyZSBpcyBub3cgY29tcHV0ZWQgb3ZlciB0aGUgU0hB MjU2IGhhc2ggb2YgdGhlIGNvbmNhdGVuYXRpb24gb2YgYSBmZXcgb2YgdGhpbmdzIChsYWJlbCwg dmVyc2lvbiwgdHlwZSwga2V5IHBhcmFtcywgRUtNKS4gQW5kIGJvdGggUlNBIHNpZ25hdHVyZSBz Y2hlbWVzICdNVVNUIHVzZSB0aGUgU0hBMjU2IGhhc2ggYWxnb3JpdGhtJy4gV2hpbGUsIHdoZW4g YW4gZWNkc2FwMjU2IGtleSBpcyB1c2VkLCBFQ0RTQSB3aXRoIFAtMjU2IGlzIHVzZWQgd2l0aCBu byBoYXNoIGFsZ29yaXRobS4NCkkgZ3Vlc3MgbXkgcXVlc3Rpb24gaXMsIG5vdyB0aGF0IHRoZSBz aWduYXR1cmUgaW5wdXQgaXMgbGFyZ2VyIHRoYW4ganVzdCB0aGUgMzIgYnl0ZSBFS00gYW5kIHRo ZSBSU0EgYWxncyBhcmUgdXNpbmcgU0hBMjU2LCB3b3VsZG4ndCBpdCBtYWtlIHNlbnNlIGFuZCBi ZSBtb3JlIGNvbnNpc3RlbnQgdG8gdXNlIHRoZSBjb25jYXRlbmF0aW9uIG9mIHRob3NlIGl0ZW1z IGRpcmVjdGx5IGFzIHRoZSBpbnB1dCBpbnRvIHRoZSBzaWduYXR1cmUgYW5kLCB3aGVuIGFuIGVj ZHNhcDI1NiBrZXkgaXMgdXNlZCwgY2FsY3VsYXRlIHRoZSBzaWduYXR1cmUgd2l0aCBFQ0RTQSB1 c2luZyBQLTI1NiBhbmQgU0hBMjU2PyBUaGF0J2QgbWVhbiB0aGF0IFRCUFJPVE8gd291bGRuJ3Qg ZGlyZWN0bHkgdXNlIFNIQTI1NiBidXQgcmF0aGVyIHRoZSBoYXNoaW5nIGlzIHB1c2hlZCBpbnRv IHRoZSBkZWZpbml0aW9uIG9mIGhvdyB0byBkbyB0aGUgc2lnbmF0dXJlIGZvciBlYWNoIGtleSBw YXJhbWV0ZXJzIHR5cGUsIHdoaWNoIGlzIGFyZ3VhYmx5IG1vcmUgY3J5cHRvZ3JhcGhpY2FsbHkg YWdpbGUuIEl0J2QgYWxzbyBiZSBvbmUgbGVzcyByb3VuZCBvZiBoYXNoaW5nIGZvciB0aGUgUlNB IHNpZ25hdHVyZSBzY2hlbWVzLg0KT3IgYW0gSSBvZmYgdGhlIHJhaWxzIGhlcmU/DQoNCg0KDQoN Cg0K --_000_CY1PR0301MB0842B4556523D670E362A8338CE00CY1PR0301MB0842_ 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 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVp biAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SGFzaGluZyBiZWZvcmUg c2lnbmluZyBpcyBnZW5lcmFsbHkgdXNlZnVsLCBiZWNhdXNlIGl0IGJyaW5ncyB0aGUgZGF0YSB0 byBhbiBhY2NlcHRhYmxlIHNpemUgZm9yIHRoZSBzaWduYXR1cmUgYWxnb3JpdGhtLCBhbmQgYWxz byBpdCBtYXkgYmUgY2hlYXBlciB0byBoYXNoIGFuZCB0aGVuIHNpZ24uPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkJ1dCB0aGlzIGlzIGFsbCBtb290IGlmIHdlIGFkb3B0IEJpbGzigJlzIHByb3Bvc2FsIGFuZCBw dXQgdGhlIGNvbmNhdGVuYXRlZCB2YWx1ZXMgaW4gdGhlIEVLTSBjb250ZXh0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQnJpYW4gQ2FtcGJlbGwg W21haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBU dWVzZGF5LCBBdWd1c3QgMzAsIDIwMTYgMzowMiBQTTxicj4NCjxiPlRvOjwvYj4gQW5kcmVpIFBv cG92ICZsdDtBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IElF VEYgVG9rYmluZCBXRyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBIYXNoaW5nICZhbXA7IHNpZ25hdHVyZXMgaW4gVEJQUk9U Ty05PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBBdWcgMzAsIDIwMTYgYXQgMTI6 MjcgUE0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNy b3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxw PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+w5g8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7DQo8L3NwYW4+QW5kIGJv dGggUlNBIHNpZ25hdHVyZSBzY2hlbWVzICdNVVNUIHVzZSB0aGUgU0hBMjU2IGhhc2ggYWxnb3Jp dGhtJy4gV2hpbGUsIHdoZW4gYW4gZWNkc2FwMjU2IGtleSBpcyB1c2VkLCBFQ0RTQSB3aXRoIFAt MjU2IGlzIHVzZWQgd2l0aCBubyBoYXNoIGFsZ29yaXRobS48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPlBTUyBhbmQgUEtDUyBwYWRkaW5nIHNjaGVtZXMgYXJlIGRlZmluZWQgd2l0aCBh IGxvdCBvZiBmbGV4aWJpbGl0eSwgc28gd2UgaGF2ZSB0byBzcGVjaWZ5IHRoZSBoYXNoIGZ1bmN0 aW9uIHRvIGJlDQogdXNlZCBieSB0aGVzZSBwYWRkaW5nIHNjaGVtZXMuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkVDRFNBIHNp Z25pbmcgZG9lcyBub3QgcmVxdWlyZSBwYWRkaW5nLCBzbyB0aGVyZSBpcyBubyBuZWVkIHRvIHNw ZWNpZnkgdGhlIGhhc2ggYWxnb3JpdGhtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FQ0RT QSBjYW4gYmUsIGFuZCBnZW5lcmFsbHkgaXMsIHVzZWQgd2l0aCBhIGhhc2ggYWxnb3JpdGhtIHRo b3VnaCAob2Ygc2ltaWxhciBzdHJlbmd0aCkuJm5ic3A7IExpa2UgaW4NCjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NTE4I3NlY3Rpb24tMy40IiB0YXJnZXQ9Il9ibGFu ayI+Sk9TRTwvYT4gb3INCjxhIGhyZWY9Imh0dHBzOi8vd3d3LnczLm9yZy9UUi94bWxkc2lnLWNv cmUxLyNzZWMtRUNEU0EiIHRhcmdldD0iX2JsYW5rIj5YTUwgU2lnbmF0dXJlczwvYT4sIGZvciBl eGFtcGxlLiBGcm9tIHRoZSBwcm9zcGVjdGl2ZSBvZiBhIGEgc2lsbHkgbGl0dGxlIEphdmEgcHJv Z3JhbW1lciBzdWNoIGFzIG15c2VsZiwgSSBnZXQgYSBzaWduYXR1cmUgaW5zdGFuY2UgZnJvbSB0 aGUgcGxhdGZvcm0gdXNpbmcgdGhlIG5hbWVzLCAmcXVvdDtTSEEyNTZ3aXRoRUNEU0EmcXVvdDss DQogJnF1b3Q7U0hBMzg0d2l0aEVDRFNBJnF1b3Q7LCBhbmQgJnF1b3Q7U0hBNTEyd2l0aEVDRFNB JnF1b3Q7IGZvciB0aGUgSk9TRSBhbmQgJnF1b3Q7Tk9ORXdpdGhFQ0RTQSZxdW90OyBmb3IgVG9r ZW5CaW5kaW5nIChpbnRlcm9wIHRlc3RlZCB3aXRoIENocm9tZSkuIE15IHVuZGVyc3RhbmRpbmcg aXMgdGhhdCBoYXNoIGFsZ29yaXRobSBpcyB1c2VkIHNvIHRoYXQgbWVzc2FnZXMgbGFyZ2VyIHRo YW4gdGhlICdyYXcnIHNpZ25hdHVyZSBzY2hlbWUgd291bGQgb3RoZXJ3aXNlIGhhbmRsZSBjYW4g YmUgdXNlZC4NCiBUbyBiZSBob25lc3QsIEkgZ290IGNvbmZ1c2VkIGFib3V0IHRoZSBzaXplIEVD RFNBIHdpdGggUC0yNTYgY291bGQgaGFuZGxlIGFuZCB3YXMgdGhpbmtpbmcgdGhhdCBsYWJlbCAm IzQzOyB2ZXJzaW9uICYjNDM7IHR5cGUgJiM0Mzsga2V5IHBhcmFtcyAmIzQzOyBFS00gd2l0aG91 dCBoYXNoaW5nIHdvdWxkIGJlIHRvbyBsYXJnZS4gQW5kIHRoYXQgRUNEU0Egd2l0aCBQLTI1NiB3 aXRoIFNIQTI1NiB3b3VsZCBiZSBuZWVkZWQsIGlmIHRoZSBoYXNoaW5nIG9mIHRoZSBjb25jYXRl bmF0aW9uDQogd2FzIHJlbW92ZWQsIHdoaWNoIGlzIHdoYXQgSSB3YXMgcmVhbGx5IGFpbWluZyBm b3IuJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5n cyI+w5g8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7DQo8L3NwYW4+ VGhlIHNpZ25hdHVyZSBpcyBub3cgY29tcHV0ZWQgb3ZlciB0aGUgU0hBMjU2IGhhc2ggb2YgdGhl IGNvbmNhdGVuYXRpb24gb2YgYSBmZXcgb2YgdGhpbmdzIChsYWJlbCwgdmVyc2lvbiwgdHlwZSwg a2V5IHBhcmFtcywgRUtNKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Db3JyZWN0LCB0aGlzIGlzIHRvIHByZXZlbnQgcG90ZW50aWFsIGF0 dGFja3MgdGhhdCBmb2xrcyBoYXZlIHBvaW50ZWQgb3V0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JbmNsdWRpbmcgdGhlIHZhcmlvdXMgZGlmZmVyZW50IGJpdHMgb2YgaW5mb3JtYXRpb24g aW4gd2hhdCBpcyBzaW5nZWQgaXMgd2hhdCBwcmV2ZW50cyBzdWNoIGF0dGFja3MsIHJpZ2h0PyBX aGF0IGlzIHRoZSBoYXNoIGZvcj88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+VGhpcyBpcyBpbmRlcGVuZGVudCBvZiB0aGUgc2lnbmF0dXJlIGFsZ29yaXRo bXMgYW5kIHBhZGRpbmcgc2NoZW1lcyB0aGF0IHdlIG5lZ290aWF0ZSB2aWEgVEIga2V5IHBhcmFt ZXRlcnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Eb2VzIHRoaXMgbWFrZSBzZW5zZT88L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+TXVjaCBvZiBpdCBkb2VzLCB5ZXMuIFRoYW5rcy4gPGJyPg0KPGJy Pg0KQnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB3aHkgdGhlIGhhc2ggaXMgYXBwbGllZCB0byB0aGUg Y29uY2F0ZW5hdGlvbiBvZiB0aGUgbGFiZWwsIHZlcnNpb24sIHR5cGUsIGtleSBwYXJhbXMsICZh bXA7IEVLTSByYXRoZXIgdGhhbiB1c2luZyB0aGUgY29uY2F0ZW5hdGlvbiBkaXJlY3RseSBhcyB0 aGUgc2lnbmluZyBpbnB1dD8gU2ltaWxhciBtYXliZSB0bw0KPGEgaHJlZj0iaHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy91bmJlYXJhYmxlLzNNdzhVMmpXYzdtMmFqeUVUYV90 T0JfYkRRWSIgdGFyZ2V0PSJfYmxhbmsiPg0KQmlsbCdzIHJlY2VudCBxdWVzdGlvbjwvYT4gYnV0 IGxvb2tpbmcgYXQgaXQgYSBsaXR0bGUgZGlmZmVyZW50IEkgd2FzIHRyeWluZyB0byBzZWUgaWYg d2UgY291bGQgZ2V0IHJpZCBvZiB0aGF0IGhhc2hpbmcgc3RlcCBpbiB0aGUgY29yZSBwcm90b2Nv bCAtIHRoYXQgd291bGQgZ2l2ZSBiZXR0ZXIgY3J5dG8gYWdpbGl0eSB0byB0aGUgY29yZSBzcGVj IGFuZCBoYXZlIG1hcmdpbmFsbHkgYmV0dGVyIHBlcmZvcm1hbmNlLiZuYnNwOw0KPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Q2hlZXJzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kcmVpPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVW5iZWFyYWJsZSBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj51bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5CcmlhbiBDYW1wYmVsbDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMzAsIDIw MTYgMTA6MTEgQU08YnI+DQo8Yj5Ubzo8L2I+IElFVEYgVG9rYmluZCBXRyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51bmJlYXJhYmxlQGll dGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1VuYmVhcmFibGVdIEhhc2hpbmcg JmFtcDsgc2lnbmF0dXJlcyBpbiBUQlBST1RPLTk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPlJlc3VsdGluZyBmcm9tIGlzc3Vlcw0KPGEgaHJlZj0iaHR0cHM6Ly9n aXRodWIuY29tL1Rva2VuQmluZGluZy9JbnRlcm5ldC1EcmFmdHMvaXNzdWVzLzY3IiB0YXJnZXQ9 Il9ibGFuayI+DQojNjc8L2E+IGFuZCA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vVG9rZW5C aW5kaW5nL0ludGVybmV0LURyYWZ0cy9pc3N1ZXMvNzAiIHRhcmdldD0iX2JsYW5rIj4NCiM3MDwv YT4gKEkgdGhpbmsgYW55d2F5KSBhcmUgc29tZSBuZXcgcnVsZXMgZm9yIGNhbGN1bGF0aW5nIHRo ZSBUb2tlbiBCaW5kaW5nIHNpZ25hdHVyZSAobW9zdGx5IGluDQo8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10b2tiaW5kLXByb3RvY29sLTA5I3NlY3Rpb24t My4zIiB0YXJnZXQ9Il9ibGFuayI+DQpzZWMgMy4zIG9mIFRCUFJPVE8tOTwvYT4pLiBUaGUgc2ln bmF0dXJlIGlzIG5vdyBjb21wdXRlZCBvdmVyIHRoZSBTSEEyNTYgaGFzaCBvZiB0aGUgY29uY2F0 ZW5hdGlvbiBvZiBhIGZldyBvZiB0aGluZ3MgKGxhYmVsLCB2ZXJzaW9uLCB0eXBlLCBrZXkgcGFy YW1zLCBFS00pLiBBbmQgYm90aCBSU0Egc2lnbmF0dXJlIHNjaGVtZXMgJ01VU1QgdXNlIHRoZSBT SEEyNTYgaGFzaCBhbGdvcml0aG0nLiBXaGlsZSwgd2hlbiBhbiBlY2RzYXAyNTYga2V5DQogaXMg dXNlZCwgRUNEU0Egd2l0aCBQLTI1NiBpcyB1c2VkIHdpdGggbm8gaGFzaCBhbGdvcml0aG0uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgZ3Vlc3MgbXkg cXVlc3Rpb24gaXMsIG5vdyB0aGF0IHRoZSBzaWduYXR1cmUgaW5wdXQgaXMgbGFyZ2VyIHRoYW4g anVzdCB0aGUgMzIgYnl0ZSBFS00gYW5kIHRoZSBSU0EgYWxncyBhcmUgdXNpbmcgU0hBMjU2LCB3 b3VsZG4ndCBpdCBtYWtlIHNlbnNlIGFuZCBiZSBtb3JlIGNvbnNpc3RlbnQgdG8gdXNlIHRoZSBj b25jYXRlbmF0aW9uDQogb2YgdGhvc2UgaXRlbXMgZGlyZWN0bHkgYXMgdGhlIGlucHV0IGludG8g dGhlIHNpZ25hdHVyZSBhbmQsIHdoZW4gYW4gZWNkc2FwMjU2IGtleSBpcyB1c2VkLCBjYWxjdWxh dGUgdGhlIHNpZ25hdHVyZSB3aXRoIEVDRFNBIHVzaW5nIFAtMjU2IGFuZCBTSEEyNTY/IFRoYXQn ZCBtZWFuIHRoYXQgVEJQUk9UTyB3b3VsZG4ndCBkaXJlY3RseSB1c2UgU0hBMjU2IGJ1dCByYXRo ZXIgdGhlIGhhc2hpbmcgaXMgcHVzaGVkIGludG8gdGhlIGRlZmluaXRpb24NCiBvZiBob3cgdG8g ZG8gdGhlIHNpZ25hdHVyZSBmb3IgZWFjaCBrZXkgcGFyYW1ldGVycyB0eXBlLCB3aGljaCBpcyBh cmd1YWJseSBtb3JlIGNyeXB0b2dyYXBoaWNhbGx5IGFnaWxlLiBJdCdkIGFsc28gYmUgb25lIGxl c3Mgcm91bmQgb2YgaGFzaGluZyBmb3IgdGhlIFJTQSBzaWduYXR1cmUgc2NoZW1lcy4NCjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PciBhbSBJ IG9mZiB0aGUgcmFpbHMgaGVyZT8NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR0301MB0842B4556523D670E362A8338CE00CY1PR0301MB0842_-- From nobody Tue Aug 30 15:25: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 7364C12D820 for ; Tue, 30 Aug 2016 15:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 qgqhIin_ZGvP for ; Tue, 30 Aug 2016 15:24:58 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0092.outbound.protection.outlook.com [104.47.32.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D3012D82F for ; Tue, 30 Aug 2016 15:24:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=947hmFxwcygooRgs8Fn08FSI9QbRW5bamBIlzaizjtg=; b=C2agcWTQTL7JIGVS1lOojrmdog2UF0vLCIUcWbmxS46EgRe87OHdaNsDRrE2IP6CAYNoBRTxYD3qdkDWaIIc0X2angNXu3vRN09LqjZG0wToGndnihgQU5k14LkDqCOv+K3qPiyHNnGID2dPnQKjfcuGosu2KmYPmFv//Qh64io= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Tue, 30 Aug 2016 22:24:55 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Tue, 30 Aug 2016 22:24:55 +0000 From: Andrei Popov To: Bill Cox Thread-Topic: [Unbearable] Dumb idea: add Ed25519 support? Thread-Index: AQHSAv7vhTLhCxb7AU+usuWCAoCwYKBiAkGAgAACPQCAAAFN0IAAAbUAgAAAb1CAAAuhAIAAABjg Date: Tue, 30 Aug 2016 22:24:55 +0000 Message-ID: References: <96c11d53-03c0-bcc3-92e1-ea73ce4d6a57@sunet.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 4f74cdd3-6732-4aa2-8dc4-08d3d1247829 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 6:XiwrFNCO9zggSv1rVX6yaJB5PkLyAbA182hAv0EhdpDD/Xr7KbGd2IWAk0mEF/LbCrPUrwLALNjVk66T8Hx47jZIzP/vvmMzP1zbeTchmc1mmS/L+R3uFDn7e15fKzSr0Tlxhked703Aoi0++gu8BqVQFZ6Qda2HfuUiqqWfze0WM7wr6KgI7Mr8ss7JF6/ycbANK08kXdFnGkFQ5oZEGchhJn+sQuGfJdrW74P7cKOMwqbwriwEQuprqNDbBKLdNY0U/2tDvFGzpjcoZbg6ayXNNR4pW2Ic+u4kKmJ/r//xtIRYwPfmklyhlwZhQm1NYEPa5ue0NcGfp6OnMXAYgQ==; 5:fF8/qzpcREmLyV4YW4LJjT4JESHuC/u8x1Qk5PH+U0iR0I0pxp6X2WzGqaov5/xMjZeI3qjbxX/nil6g4IFoPTOUwAA6QXgATjAFG/iu9hE6ED/7d3n5Y9dp9QhHiRU2dcyxmU0CNkJEJfvj6r8Beg==; 24:/oLw6AK5CaY0BLRD0nAlcWqytmRQGESmQDDaLCZoY07BJPgcr6DbN6cRrSymk2ku/rERq4YcM6ub2NB1OZ/+ug9X2bzHDwvpb+vOY8U21FQ=; 7:TmjomKRBLSfOcNWGpt6bRuSn1yELdA8gzI26RtCZH1hMNoqn22xh3dkE6Z3D3MZge4vEiClQrRedF7KKSD1aqOthaEGm5t3hLCRTmV8mRkgb3IQfxAfmGkVlYAN2/O2P2ckM4/oESQ8AAcydev3buxMU6YQ781gGWuQZyQgokZUTQ4Mnr9VBDYqyMB/KYAhTpHOYiQS0UbdceRHrXgv9W4TqxCJ/7TAc6F/A1MnLyFbxMc/qNK2JBxEq1xTbRhUZ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0842; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 0050CEFE70 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(377454003)(24454002)(74316002)(10400500002)(76176999)(9686002)(7736002)(7696003)(106116001)(8990500004)(33656002)(101416001)(50986999)(7846002)(54356999)(16236675004)(11100500001)(3660700001)(10090500001)(81166006)(8676002)(68736007)(99286002)(81156014)(19609705001)(790700001)(102836003)(93886004)(5660300001)(586003)(106356001)(4326007)(6116002)(77096005)(122556002)(15975445007)(86362001)(76576001)(5002640100001)(92566002)(110136002)(19625215002)(2950100001)(8936002)(10290500002)(19300405004)(105586002)(5005710100001)(19580395003)(87936001)(86612001)(2900100001)(19580405001)(97736004)(3280700002)(2906002)(189998001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842ADE0B5CED8CCFCA1FAA88CE00CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2016 22:24:55.1906 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Cc: Tokbind WG , Leif Johansson Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? 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, 30 Aug 2016 22:25:00 -0000 --_000_CY1PR0301MB0842ADE0B5CED8CCFCA1FAA88CE00CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VW5sZXNzIHRoZXJlIGFyZSBvYmplY3Rpb25zLCBJ4oCZbGwgcmV2IFRCUFJPVE8gb25jZSBtb3Jl IGFuZCBlbGltaW5hdGUgb25lIGhhc2ggb3BlcmF0aW9uLiBDb25jYXRlbmF0ZWQgVG9rZW5CaW5k aW5nVHlwZSBhbmQgVG9rZW5CaW5kaW5nS2V5UGFyYW1ldGVycyB3aWxsIGJlIG1peGVkIGluIGFz IEVLTSBjb250ZXh0LCBhbmQgdGhlIHJlc3VsdGluZyBFS00gd2lsbCBiZSBzaWduZWQuDQoNCkNo ZWVycywNCg0KQW5kcmVpDQoNCkZyb206IEJpbGwgQ294IFttYWlsdG86d2F5d2FyZGdlZWtAZ29v Z2xlLmNvbV0NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAzMCwgMjAxNiAzOjIxIFBNDQpUbzogQW5k cmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4NCkNjOiBMZWlmIEpvaGFuc3Nv biA8bGVpZmpAc3VuZXQuc2U+OyBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPg0KU3Vi amVjdDogUmU6IFtVbmJlYXJhYmxlXSBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBvcnQ/DQoN Ck9uIFR1ZSwgQXVnIDMwLCAyMDE2IGF0IDI6NDkgUE0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBv cG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3Jv dGU6DQpUaGUgVG9rZW5CaW5kaW5nS2V5UGFyYW1ldGVycyB2YWx1ZSBpcyBub3QgbmVjZXNzYXJp bHkgaW4gdGhlIFRMUyBoYW5kc2hha2UgaGFzaCAoZS5nLiBmb3IgcmVmZXJyZWQgYmluZGluZ3Mp Lg0KDQpUaGUgUHJvdG9jb2xWZXJzaW9uIHZhbHVlIGlzIG9ubHkgaW4gdGhlIFRMUyBoYW5kc2hh a2UgaWYgd2Uga2VlcCBpdCBpbiB0aGUgdG9rZW5fYmluZGluZyBleHRlbnNpb24gKHdoaWNoIEkg aG9wZSB3ZSB3aWxsKS4NCg0KSSBkb27igJl0IGltbWVkaWF0ZWx5IHNlZSB3aHkgdGhpcyBpZGVh IHdvdWxkbuKAmXQgd29yaywgYW5kIGl0IGVsaW1pbmF0ZXMgb25lIGhhc2ggb3BlcmF0aW9uLCBi dXQgSSB0aGluayB3ZSBoYXZlIHRvIHN1cHBseSBhdCBsZWFzdCBUb2tlbkJpbmRpbmdUeXBlIGFu ZCBUb2tlbkJpbmRpbmdLZXlQYXJhbWV0ZXJzIGFzIHRoZSBFS00gY29udGV4dC4NCg0KSSBndWVz cyBJIHdvdWxkIHByZWZlciB0aGlzLCBqdXN0IGZvciB0aGUgcmVkdWN0aW9uIG9mIG9uZSBoYXNo IG9wZXJhdGlvbi4NCg0KQmlsbA0K --_000_CY1PR0301MB0842ADE0B5CED8CCFCA1FAA88CE00CY1PR0301MB0842_ 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 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Vbmxlc3MgdGhlcmUgYXJlIG9iamVjdGlvbnMsIEnigJlsbCByZXYgVEJQ Uk9UTyBvbmNlIG1vcmUgYW5kIGVsaW1pbmF0ZSBvbmUgaGFzaCBvcGVyYXRpb24uIENvbmNhdGVu YXRlZA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG9rZW5CaW5kaW5nVHlwZSBhbmQgVG9rZW5C aW5kaW5nS2V5UGFyYW1ldGVycyB3aWxsIGJlIG1peGVkIGluIGFzIEVLTSBjb250ZXh0LCBhbmQg dGhlIHJlc3VsdGluZyBFS00gd2lsbCBiZSBzaWduZWQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kcmVpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBCaWxsIENveCBbbWFpbHRv OndheXdhcmRnZWVrQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgQXVn dXN0IDMwLCAyMDE2IDM6MjEgUE08YnI+DQo8Yj5Ubzo8L2I+IEFuZHJlaSBQb3BvdiAmbHQ7QW5k cmVpLlBvcG92QG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBMZWlmIEpvaGFuc3Nv biAmbHQ7bGVpZmpAc3VuZXQuc2UmZ3Q7OyBUb2tiaW5kIFdHICZsdDt1bmJlYXJhYmxlQGlldGYu b3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIER1bWIgaWRlYTog YWRkIEVkMjU1MTkgc3VwcG9ydD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXVnIDMwLCAyMDE2IGF0IDI6NDkgUE0sIEFuZHJlaSBQ b3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIiB0YXJn ZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgVG9rZW5CaW5kaW5nS2V5UGFyYW1ldGVycyB2YWx1 ZSBpcyBub3QgbmVjZXNzYXJpbHkgaW4gdGhlIFRMUyBoYW5kc2hha2UgaGFzaCAoZS5nLiBmb3Ig cmVmZXJyZWQgYmluZGluZ3MpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlIFByb3RvY29sVmVyc2lv biB2YWx1ZSBpcyBvbmx5IGluIHRoZSBUTFMgaGFuZHNoYWtlIGlmIHdlIGtlZXAgaXQgaW4gdGhl IHRva2VuX2JpbmRpbmcgZXh0ZW5zaW9uICh3aGljaCBJIGhvcGUNCiB3ZSB3aWxsKS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkkgZG9u4oCZdCBpbW1lZGlhdGVseSBzZWUgd2h5IHRoaXMgaWRlYSB3b3Vs ZG7igJl0IHdvcmssIGFuZCBpdCBlbGltaW5hdGVzIG9uZSBoYXNoIG9wZXJhdGlvbiwgYnV0IEkg dGhpbmsgd2UgaGF2ZSB0bw0KIHN1cHBseSBhdCBsZWFzdCBUb2tlbkJpbmRpbmdUeXBlIGFuZCBU b2tlbkJpbmRpbmdLZXlQYXJhbWV0ZXJzIGFzIHRoZSBFS00gY29udGV4dC48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBndWVzcyBJIHdvdWxkIHByZWZlciB0aGlzLCBqdXN0IGZvciB0aGUg cmVkdWN0aW9uIG9mIG9uZSBoYXNoIG9wZXJhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmlsbCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_CY1PR0301MB0842ADE0B5CED8CCFCA1FAA88CE00CY1PR0301MB0842_-- From nobody Wed Aug 31 06:25:14 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 A42B612D520 for ; Wed, 31 Aug 2016 06:25:12 -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 mTAVZqpA31Dp for ; Wed, 31 Aug 2016 06:25:08 -0700 (PDT) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 D96BB12DB51 for ; Wed, 31 Aug 2016 06:25:07 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id g62so95177591ith.1 for ; Wed, 31 Aug 2016 06:25:07 -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=p7Vzv7BLd3/lP+TVMJW4RVQVuqmfYv94x3CbyIiFvIw=; b=hizM8MBvBG11RixsSDAGhEJBRoY9tz3W4g3XnK5qjEFVEx6gppMXfysX1OsLDfCfx3 tnd1N7FLBBjugtKFfoeyqIpjyoRxzM2QSXd0NIdcQDtnWPnLfiHFrK2i/QBwpzK9dDtw 7XQArAwA4cpa9J6N25pBNrTOPyR9ELvhsMI0M= 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=p7Vzv7BLd3/lP+TVMJW4RVQVuqmfYv94x3CbyIiFvIw=; b=heXuJQm67uQbuR8NiTpQVWt63bcHk2h1cUW6wPtEGni+z3V6T6gulghvIOn8nfVWD+ l+QFrDrMiAySLlu76DmUAGduzLJMhuS28Y1FGPNLitNge/g+mXILuAz6dfsyJKoGI8GK uInToe0illY17bRH73P/MFdFx39wcBC2T70GottmRzLZfLhnGb0C4Fn41mqAMPWewdHA K2ilxqbWCnxB9IDDe9SYuA762I+UMyUkglOdwS+/tBL2DWT16bE7MeMcTNMB4tCb20de qdDfNADuIvFjSMXKCIwxWI58pwGHbZJLU08iGeeB402zQPVjZRKI53vIHZHWZ8vo2scz 9mEA== X-Gm-Message-State: AE9vXwPP34Vn5hK9okmtJ2OBfm6vZVlcIQDlhCF2iPVez5K3Z80Bqgt0jCgZi6GT+Do1qdwtXjxw7sXJ5SBgq/r2 X-Received: by 10.107.10.167 with SMTP id 39mr5351003iok.86.1472649907138; Wed, 31 Aug 2016 06:25:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.114.20 with HTTP; Wed, 31 Aug 2016 06:24:36 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 31 Aug 2016 07:24:36 -0600 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a113edc56980d8b053b5e069b Archived-At: Cc: IETF Tokbind WG Subject: Re: [Unbearable] Hashing & signatures in TBPROTO-9 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, 31 Aug 2016 13:25:13 -0000 --001a113edc56980d8b053b5e069b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Which is why signature schemes are typically used with a hash function (rather than the application of the signature doing the hashing and using a 'raw' signature). Also in this case the message size is fixed and not much larger than the hash output. But yes, it's moot if we adopt Bill=E2=80=99s proposal. Which I'm good with= . On Tue, Aug 30, 2016 at 4:21 PM, Andrei Popov wrote: > Hashing before signing is generally useful, because it brings the data to > an acceptable size for the signature algorithm, and also it may be cheape= r > to hash and then sign. > > > > But this is all moot if we adopt Bill=E2=80=99s proposal and put the conc= atenated > values in the EKM context. > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Tuesday, August 30, 2016 3:02 PM > *To:* Andrei Popov > *Cc:* IETF Tokbind WG > *Subject:* Re: [Unbearable] Hashing & signatures in TBPROTO-9 > > > > > > > > On Tue, Aug 30, 2016 at 12:27 PM, Andrei Popov > wrote: > > =C3=98 And both RSA signature schemes 'MUST use the SHA256 hash algorith= m'. > While, when an ecdsap256 key is used, ECDSA with P-256 is used with no ha= sh > algorithm. > > PSS and PKCS padding schemes are defined with a lot of flexibility, so we > have to specify the hash function to be used by these padding schemes. > > ECDSA signing does not require padding, so there is no need to specify th= e > hash algorithm. > > > > ECDSA can be, and generally is, used with a hash algorithm though (of > similar strength). Like in JOSE > or XML Signatures > , for example. From the > prospective of a a silly little Java programmer such as myself, I get a > signature instance from the platform using the names, "SHA256withECDSA", > "SHA384withECDSA", and "SHA512withECDSA" for the JOSE and "NONEwithECDSA" > for TokenBinding (interop tested with Chrome). My understanding is that > hash algorithm is used so that messages larger than the 'raw' signature > scheme would otherwise handle can be used. To be honest, I got confused > about the size ECDSA with P-256 could handle and was thinking that label = + > version + type + key params + EKM without hashing would be too large. And > that ECDSA with P-256 with SHA256 would be needed, if the hashing of the > concatenation was removed, which is what I was really aiming for. > > > > > > =C3=98 The signature is now computed over the SHA256 hash of the > concatenation of a few of things (label, version, type, key params, EKM). > > Correct, this is to prevent potential attacks that folks have pointed out= . > > > > Including the various different bits of information in what is singed is > what prevents such attacks, right? What is the hash for? > > > > > > This is independent of the signature algorithms and padding schemes that > we negotiate via TB key parameters. > > > > Does this make sense? > > > > Much of it does, yes. Thanks. > > But I don't understand why the hash is applied to the concatenation of th= e > label, version, type, key params, & EKM rather than using the concatenati= on > directly as the signing input? Similar maybe to Bill's recent question > > but looking at it a little different I was trying to see if we could get > rid of that hashing step in the core protocol - that would give better > cryto agility to the core spec and have marginally better performance. > > > > > Cheers, > > > > Andrei > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *Br= ian > Campbell > *Sent:* Tuesday, August 30, 2016 10:11 AM > *To:* IETF Tokbind WG > *Subject:* [Unbearable] Hashing & signatures in TBPROTO-9 > > > > Resulting from issues #67 > and #70 > (I think > anyway) are some new rules for calculating the Token Binding signature > (mostly in sec 3.3 of TBPROTO-9 > )= . > The signature is now computed over the SHA256 hash of the concatenation o= f > a few of things (label, version, type, key params, EKM). And both RSA > signature schemes 'MUST use the SHA256 hash algorithm'. While, when an > ecdsap256 key is used, ECDSA with P-256 is used with no hash algorithm. > > I guess my question is, now that the signature input is larger than just > the 32 byte EKM and the RSA algs are using SHA256, wouldn't it make sense > and be more consistent to use the concatenation of those items directly a= s > the input into the signature and, when an ecdsap256 key is used, calculat= e > the signature with ECDSA using P-256 and SHA256? That'd mean that TBPROTO > wouldn't directly use SHA256 but rather the hashing is pushed into the > definition of how to do the signature for each key parameters type, which > is arguably more cryptographically agile. It'd also be one less round of > hashing for the RSA signature schemes. > > Or am I off the rails here? > > > > > > > > > > > --001a113edc56980d8b053b5e069b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Which= is why signature schemes are typically used with a hash function (rather t= han the application of the signature doing the hashing and using a 'raw= ' signature). Also in this case the message size is fixed and not much = larger than the hash output.

But yes, it's moot if we adopt Bill=E2= =80=99s proposal. Which I'm good with.

On Tu= e, Aug 30, 2016 at 4:21 PM, Andrei Popov <Andrei.Popov@microsoft.= com> wrote:

Hashing before signing is generally useful, because= it brings the data to an acceptable size for the signature algorithm, and = also it may be cheaper to hash and then sign.

=C2=A0

But this is all moot if we adopt Bill=E2=80=99s pro= posal and put the concatenated values in the EKM context.

=C2=A0

From: Brian Campbell [mailto:bcampbell@pin= gidentity.com]
Sent: Tuesday, August 30, 2016 3:02 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: IETF Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] Hashing & signatures in TBPROTO-9

=C2=A0

=C2=A0

=C2=A0

On Tue, Aug 30, 2016 at 12:27 PM, Andrei Popov <<= a href=3D"mailto:Andrei.Popov@microsoft.com" target=3D"_blank">Andrei.Popov= @microsoft.com> wrote:

=C3=98=C2=A0 And both RSA signature schemes 'MUST use the SHA256 hash algorit= hm'. While, when an ecdsap256 key is used, ECDSA with P-256 is used wit= h no hash algorithm.=C2=A0

PSS and PKCS padding schemes are defined with a lot= of flexibility, so we have to specify the hash function to be used by these padding schemes.

ECDSA signing does not require padding, so there is= no need to specify the hash algorithm.

=C2=A0

ECDSA can be, and generally is, used with a hash alg= orithm though (of similar strength).=C2=A0 Like in JOSE or XML Signatures, for example. From the prospective of a a silly little= Java programmer such as myself, I get a signature instance from the platfo= rm using the names, "SHA256withECDSA", "SHA384withECDSA", and "SHA512withECDSA" for the JOSE = and "NONEwithECDSA" for TokenBinding (interop tested with Chrome)= . My understanding is that hash algorithm is used so that messages larger t= han the 'raw' signature scheme would otherwise handle can be used. To be honest, I got confused about the size ECDSA with P-256 could handle = and was thinking that label + version + type + key params + EKM without has= hing would be too large. And that ECDSA with P-256 with SHA256 would be nee= ded, if the hashing of the concatenation was removed, which is what I was really aiming for.=C2=A0

=C2=A0

=C2=A0

=C3=98=C2=A0 The signature is now computed over the SHA256 hash of the concatenat= ion of a few of things (label, version, type, key params, EKM).

Correct, this is to prevent potential attacks that = folks have pointed out.

=C2=A0

Including the various different bits of information = in what is singed is what prevents such attacks, right? What is the hash fo= r?



=C2=A0

This is independent of the signature algorithms and= padding schemes that we negotiate via TB key parameters.<= /u>

=C2=A0

Does this make sense?

=C2=A0

Much of it does, yes. Thanks.

But I don't understand why the hash is applied to the concatenation of = the label, version, type, key params, & EKM rather than using the conca= tenation directly as the signing input? Similar maybe to Bill's recent question but looking at it a little different I was t= rying to see if we could get rid of that hashing step in the core protocol = - that would give better cryto agility to the core spec and have marginally= better performance.=C2=A0


=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Tuesday, August 30, 2016 10:11 AM
To: IETF Tokbind WG <unbearable@ietf.org>
Subject: [Unbearable] Hashing & signatures in TBPROTO-9

=C2=A0

Resulting from issues #67 and #70 (I think anyway) are some new rules for calculating the Token Bindi= ng signature (mostly in sec 3.3 of TBPROTO-9). The signature is now computed over the SHA256 ha= sh of the concatenation of a few of things (label, version, type, key param= s, EKM). And both RSA signature schemes 'MUST use the SHA256 hash algor= ithm'. While, when an ecdsap256 key is used, ECDSA with P-256 is used with no hash algorithm.

I guess my question i= s, now that the signature input is larger than just the 32 byte EKM and the= RSA algs are using SHA256, wouldn't it make sense and be more consiste= nt to use the concatenation of those items directly as the input into the signature and, when an ecdsa= p256 key is used, calculate the signature with ECDSA using P-256 and SHA256= ? That'd mean that TBPROTO wouldn't directly use SHA256 but rather = the hashing is pushed into the definition of how to do the signature for each key parameters type, which is arguably= more cryptographically agile. It'd also be one less round of hashing f= or the RSA signature schemes.

Or am I off the rails here?

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--001a113edc56980d8b053b5e069b-- From nobody Wed Aug 31 10:18: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 0CC1B12D10B for ; Wed, 31 Aug 2016 10:18:32 -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 ucm6yoQYiqkl for ; Wed, 31 Aug 2016 10:18:29 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0101.outbound.protection.outlook.com [104.47.33.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F19012D12B for ; Wed, 31 Aug 2016 10:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kEKa0r0+226ITp9WHTWMXk8FpuhAzIEUHQshQ7L1I+s=; b=Wojt0nqtmruLP8cjCGBxFPpMlas6xXv+DWl9NaVu9qWYSoBZKuOn1mHhiLOauLiXgWR3U46E/ENZdOCuwPd1wR44Ifn3ZPAOu8B7ZSjL95FuU3vDwB6NO/NaDf3E32Fz9WeYQ3w1glrRvUTKfmXsFJrE4mn8tp+69PRPRZwnHYI= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0841.namprd03.prod.outlook.com (10.160.163.147) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Wed, 31 Aug 2016 17:18:27 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Wed, 31 Aug 2016 17:18:26 +0000 From: Andrei Popov To: Bill Cox Thread-Topic: [Unbearable] Dumb idea: add Ed25519 support? Thread-Index: AQHSAv7vhTLhCxb7AU+usuWCAoCwYKBiAkGAgAACPQCAAAFN0IAAAbUAgAAAb1CAAAuhAIAAABjggAE6+bA= Date: Wed, 31 Aug 2016 17:18:26 +0000 Message-ID: References: <96c11d53-03c0-bcc3-92e1-ea73ce4d6a57@sunet.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 6ba35d42-5844-4bbb-bb71-08d3d1c2d214 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 6:ADm/QBfUo21jN0tfHCk0LoCwsW7tCouCQyYYK3+82vM2tW4GwjW81FjIR3ZT3dyUk4lUKqUzXE2ocdylSZH4OPET7woYsXIKl6Q1I8dyO04gWEZ8K7dasNTccpGWl2L4y4HeuYFWd/2YGgr45klgLdHvNlx55uu69+FP7zGniFQb06bIO8ZdoLa1EJQ3OVfH3bhdF6V0y0fodW/utLmNp20m9Tl34T1T2+4DA3fqgFUp7O6bL3ibX8W8Ff0b9IAT3xMLtOwuP5vglBpJ25mIgIlHZOJUIRDvVCW/VoecEnlCq/HWlfcIQqiV6K91RZVLTMcVlq6fzjDDGwtt4UelrQ==; 5:/muTv10tazeJCu4q9DfmtmQENNu6QJlLta89rd0WfGCZAa2tjyHiYEiffsJ4FKErUGA0ZBMjeXc/xNyWv/jMy67iFOINAaY+dV0cS/UV0ekEw1nSKfkWfQiVCddAkh23UzzhMBLjqVI4S0C8po1C/w==; 24:AaLB3PN20EvXKzwAOcku/PWTSlxI7ATD5sdAHHVQ24QNlcQQHUvskKCa4i2WpNOM8ndOoCSpEkmyQLPpNYCZ5goMOrCjEYNoH3dMvOchqG4=; 7:L/n8K9dGOeBiCp7TDKIP8t5E/6AAz3eK0i6IkO/sPa/hDJ7LrwncsUmFLFAT1Fs1lCnYfrpIPQAtWLK8iVf3daBZ1z/lKHmZ62it5cdWoOCnlGPShVgwqaWV2+mXHa30iXWO/UjEGzO584KuYyzBnmAuSnCwbrJwkYgeHWfIvfaig2MM72ts4GgIN+iK5OdGXo46IWDFDUuihxozkSjKLq7VChNBSdeHIyFd8LHJPBG7khe1C6BpeYBeckm4AjwF x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0841; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(377454003)(24454002)(2906002)(7696003)(93886004)(86612001)(92566002)(2900100001)(33656002)(68736007)(3280700002)(5002640100001)(10400500002)(19609705001)(122556002)(101416001)(110136002)(97736004)(16236675004)(4326007)(9686002)(189998001)(81156014)(8936002)(74316002)(3660700001)(15975445007)(8676002)(77096005)(10290500002)(87936001)(7846002)(586003)(81166006)(102836003)(76176999)(5005710100001)(7736002)(10090500001)(3900700001)(8990500004)(5660300001)(50986999)(19625215002)(54356999)(19580395003)(6116002)(106116001)(790700001)(19580405001)(105586002)(86362001)(76576001)(99286002)(106356001)(19300405004)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB08429051BEACCAE96E2C68F48CE30CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 17:18:26.4694 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0841 Archived-At: Cc: Tokbind WG , Leif Johansson Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? 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, 31 Aug 2016 17:18:32 -0000 --_000_CY1PR0301MB08429051BEACCAE96E2C68F48CE30CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpbmtpbmcgbW9yZSBhYm91dCB0aGlzLCBnZW5lcmF0aW5nIEVLTXMgbXVsdGlwbGUgdGltZXMg cGVyIGNvbm5lY3Rpb24gd291bGQgYmUgYSBzaWduaWZpY2FudCBwZXJmIGlzc3VlIGZvciB1cy4N Cg0KRUtNIGlzIGEgcHJvZHVjdCBvZiB0aGUgVExTIG1hc3RlciBzZWNyZXQsIGFuZCBvbiBXaW5k b3dzIHdlIGtlZXAgdGhlIFRMUyBtYXN0ZXIgc2VjcmV0cyBpc29sYXRlZCBmcm9tIHRoZSBUTFMg Y2xpZW50IGFuZCBzZXJ2ZXIgYXBwbGljYXRpb25zLg0KU28gaWYgd2Ugd2VyZSB0byBnbyB3aXRo IEJpbGzigJlzIGlkZWEsIHdlIHdvdWxkIGhhdmUgdG8gZG8gZXh0cmEgSVBDIGV2ZXJ5IHRpbWUg d2UgZ2VuZXJhdGUgb3IgdmVyaWZ5IGEgYmluZGluZy4NCg0KT24gdGhlIG90aGVyIGhhbmQsIGEg aGFzaCBmdW5jdGlvbiBjYWxsIGlzIGluLXByb2MgYW5kIHZlcnkgY2hlYXAsIHNvIEnigJlkIG11 Y2ggcmF0aGVyIGtlZXAgd2hhdCB3ZSBoYXZlIGluIFRCUFJPVE8tMDkgKHBlcmhhcHMgcmVtb3Zp bmcgdGhlIFByb3RvY29sVmVyc2lvbiBmcm9tIHRoZSBjb25jYXRlbmF0aW9uLCBzaW5jZSBQcm90 b2NvbFZlcnNpb24gaXMgYWxyZWFkeSBtaXhlZCBpbiBhcyBwYXJ0IG9mIHRoZSBUTFMgc2Vzc2lv biBoYXNoKS4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KRnJvbTogQW5kcmVpIFBvcG92DQpTZW50 OiBUdWVzZGF5LCBBdWd1c3QgMzAsIDIwMTYgMzoyNSBQTQ0KVG86ICdCaWxsIENveCcgPHdheXdh cmRnZWVrQGdvb2dsZS5jb20+DQpDYzogTGVpZiBKb2hhbnNzb24gPGxlaWZqQHN1bmV0LnNlPjsg VG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbVW5iZWFyYWJs ZV0gRHVtYiBpZGVhOiBhZGQgRWQyNTUxOSBzdXBwb3J0Pw0KDQpVbmxlc3MgdGhlcmUgYXJlIG9i amVjdGlvbnMsIEnigJlsbCByZXYgVEJQUk9UTyBvbmNlIG1vcmUgYW5kIGVsaW1pbmF0ZSBvbmUg aGFzaCBvcGVyYXRpb24uIENvbmNhdGVuYXRlZCBUb2tlbkJpbmRpbmdUeXBlIGFuZCBUb2tlbkJp bmRpbmdLZXlQYXJhbWV0ZXJzIHdpbGwgYmUgbWl4ZWQgaW4gYXMgRUtNIGNvbnRleHQsIGFuZCB0 aGUgcmVzdWx0aW5nIEVLTSB3aWxsIGJlIHNpZ25lZC4NCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0K RnJvbTogQmlsbCBDb3ggW21haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tXQ0KU2VudDogVHVl c2RheSwgQXVndXN0IDMwLCAyMDE2IDM6MjEgUE0NClRvOiBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Q b3BvdkBtaWNyb3NvZnQuY29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+DQpD YzogTGVpZiBKb2hhbnNzb24gPGxlaWZqQHN1bmV0LnNlPG1haWx0bzpsZWlmakBzdW5ldC5zZT4+ OyBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzp1bmJlYXJhYmxlQGlldGYu b3JnPj4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gRHVtYiBpZGVhOiBhZGQgRWQyNTUxOSBz dXBwb3J0Pw0KDQpPbiBUdWUsIEF1ZyAzMCwgMjAxNiBhdCAyOjQ5IFBNLCBBbmRyZWkgUG9wb3Yg PEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0 LmNvbT4+IHdyb3RlOg0KVGhlIFRva2VuQmluZGluZ0tleVBhcmFtZXRlcnMgdmFsdWUgaXMgbm90 IG5lY2Vzc2FyaWx5IGluIHRoZSBUTFMgaGFuZHNoYWtlIGhhc2ggKGUuZy4gZm9yIHJlZmVycmVk IGJpbmRpbmdzKS4NCg0KVGhlIFByb3RvY29sVmVyc2lvbiB2YWx1ZSBpcyBvbmx5IGluIHRoZSBU TFMgaGFuZHNoYWtlIGlmIHdlIGtlZXAgaXQgaW4gdGhlIHRva2VuX2JpbmRpbmcgZXh0ZW5zaW9u ICh3aGljaCBJIGhvcGUgd2Ugd2lsbCkuDQoNCkkgZG9u4oCZdCBpbW1lZGlhdGVseSBzZWUgd2h5 IHRoaXMgaWRlYSB3b3VsZG7igJl0IHdvcmssIGFuZCBpdCBlbGltaW5hdGVzIG9uZSBoYXNoIG9w ZXJhdGlvbiwgYnV0IEkgdGhpbmsgd2UgaGF2ZSB0byBzdXBwbHkgYXQgbGVhc3QgVG9rZW5CaW5k aW5nVHlwZSBhbmQgVG9rZW5CaW5kaW5nS2V5UGFyYW1ldGVycyBhcyB0aGUgRUtNIGNvbnRleHQu DQoNCkkgZ3Vlc3MgSSB3b3VsZCBwcmVmZXIgdGhpcywganVzdCBmb3IgdGhlIHJlZHVjdGlvbiBv ZiBvbmUgaGFzaCBvcGVyYXRpb24uDQoNCkJpbGwNCg== --_000_CY1PR0301MB08429051BEACCAE96E2C68F48CE30CY1PR0301MB0842_ 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 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5k b3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNv bXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGlua2luZyBtb3JlIGFib3V0IHRo aXMsIGdlbmVyYXRpbmcgRUtNcyBtdWx0aXBsZSB0aW1lcyBwZXIgY29ubmVjdGlvbiB3b3VsZCBi ZSBhIHNpZ25pZmljYW50IHBlcmYgaXNzdWUgZm9yIHVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5FS00gaXMg YSBwcm9kdWN0IG9mIHRoZSBUTFMgbWFzdGVyIHNlY3JldCwgYW5kIG9uIFdpbmRvd3Mgd2Uga2Vl cCB0aGUgVExTIG1hc3RlciBzZWNyZXRzIGlzb2xhdGVkIGZyb20gdGhlIFRMUyBjbGllbnQgYW5k IHNlcnZlciBhcHBsaWNhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TbyBpZiB3ZSB3ZXJlIHRvIGdvIHdpdGggQmlsbOKA mXMgaWRlYSwgd2Ugd291bGQgaGF2ZSB0byBkbyBleHRyYSBJUEMgZXZlcnkgdGltZSB3ZSBnZW5l cmF0ZSBvciB2ZXJpZnkgYSBiaW5kaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5PbiB0aGUgb3RoZXIgaGFu ZCwgYSBoYXNoIGZ1bmN0aW9uIGNhbGwgaXMgaW4tcHJvYyBhbmQgdmVyeSBjaGVhcCwgc28gSeKA mWQgbXVjaCByYXRoZXIga2VlcCB3aGF0IHdlIGhhdmUgaW4gVEJQUk9UTy0wOSAocGVyaGFwcyBy ZW1vdmluZyB0aGUgUHJvdG9jb2xWZXJzaW9uIGZyb20gdGhlIGNvbmNhdGVuYXRpb24sDQogc2lu Y2UgUHJvdG9jb2xWZXJzaW9uIGlzIGFscmVhZHkgbWl4ZWQgaW4gYXMgcGFydCBvZiB0aGUgVExT IHNlc3Npb24gaGFzaCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5k cmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQW5kcmVpIFBvcG92DQo8YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgQXVndXN0IDMwLCAyMDE2IDM6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+ ICdCaWxsIENveCcgJmx0O3dheXdhcmRnZWVrQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBMZWlmIEpvaGFuc3NvbiAmbHQ7bGVpZmpAc3VuZXQuc2UmZ3Q7OyBUb2tiaW5kIFdHICZsdDt1 bmJlYXJhYmxlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW1VuYmVhcmFi bGVdIER1bWIgaWRlYTogYWRkIEVkMjU1MTkgc3VwcG9ydD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlVubGVzcyB0aGVyZSBh cmUgb2JqZWN0aW9ucywgSeKAmWxsIHJldiBUQlBST1RPIG9uY2UgbW9yZSBhbmQgZWxpbWluYXRl IG9uZSBoYXNoIG9wZXJhdGlvbi4gQ29uY2F0ZW5hdGVkIFRva2VuQmluZGluZ1R5cGUgYW5kIFRv a2VuQmluZGluZ0tleVBhcmFtZXRlcnMgd2lsbCBiZSBtaXhlZCBpbiBhcyBFS00NCiBjb250ZXh0 LCBhbmQgdGhlIHJlc3VsdGluZyBFS00gd2lsbCBiZSBzaWduZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNo ZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kcmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBCaWxsIENveCBbPGEgaHJlZj0ibWFpbHRvOndheXdhcmRn ZWVrQGdvb2dsZS5jb20iPm1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPC9hPl0NCjxicj4N CjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBBdWd1c3QgMzAsIDIwMTYgMzoyMSBQTTxicj4NCjxiPlRv OjwvYj4gQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jv c29mdC5jb20iPkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8 L2I+IExlaWYgSm9oYW5zc29uICZsdDs8YSBocmVmPSJtYWlsdG86bGVpZmpAc3VuZXQuc2UiPmxl aWZqQHN1bmV0LnNlPC9hPiZndDs7IFRva2JpbmQgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzp1bmJl YXJhYmxlQGlldGYub3JnIj51bmJlYXJhYmxlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBvcnQ/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBU dWUsIEF1ZyAzMCwgMjAxNiBhdCAyOjQ5IFBNLCBBbmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9Im1h aWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJlaS5Q b3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZSBUb2tlbkJpbmRpbmdL ZXlQYXJhbWV0ZXJzIHZhbHVlIGlzIG5vdCBuZWNlc3NhcmlseSBpbiB0aGUgVExTIGhhbmRzaGFr ZSBoYXNoIChlLmcuIGZvciByZWZlcnJlZCBiaW5kaW5ncykuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5U aGUgUHJvdG9jb2xWZXJzaW9uIHZhbHVlIGlzIG9ubHkgaW4gdGhlIFRMUyBoYW5kc2hha2UgaWYg d2Uga2VlcCBpdCBpbiB0aGUgdG9rZW5fYmluZGluZyBleHRlbnNpb24gKHdoaWNoIEkgaG9wZQ0K IHdlIHdpbGwpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SSBkb27igJl0IGltbWVkaWF0ZWx5IHNlZSB3 aHkgdGhpcyBpZGVhIHdvdWxkbuKAmXQgd29yaywgYW5kIGl0IGVsaW1pbmF0ZXMgb25lIGhhc2gg b3BlcmF0aW9uLCBidXQgSSB0aGluayB3ZSBoYXZlIHRvDQogc3VwcGx5IGF0IGxlYXN0IFRva2Vu QmluZGluZ1R5cGUgYW5kIFRva2VuQmluZGluZ0tleVBhcmFtZXRlcnMgYXMgdGhlIEVLTSBjb250 ZXh0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGd1ZXNzIEkgd291bGQgcHJlZmVyIHRo aXMsIGp1c3QgZm9yIHRoZSByZWR1Y3Rpb24gb2Ygb25lIGhhc2ggb3BlcmF0aW9uLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CaWxsJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR0301MB08429051BEACCAE96E2C68F48CE30CY1PR0301MB0842_-- From nobody Wed Aug 31 10:54:27 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 0E9C612D5C2 for ; Wed, 31 Aug 2016 10:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 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=-0.548, 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 U6Wuj6KuZY7i for ; Wed, 31 Aug 2016 10:54:22 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c: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 9EA8912D5B7 for ; Wed, 31 Aug 2016 10:54:21 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id d196so1202173wmd.0 for ; Wed, 31 Aug 2016 10:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=fiv+LkUgf+f/jtcgRYC1L2rkdRzrJg+eY+AAJbbZsmw=; b=cuXlgRsAj80B9AIxz1zZSIn5UeqWEOYHnxX0ZZcE1Ds36UV52qqV8lqsTIPxJ6XNUw uQHjjXAhSQSF40xxd9dnBAB0gQHMso6OHNIt0OdiBXbz3+6KJqmhD7YjxVB9NpprklIU 8XgK4q6v5R97dbQ7jEe5B9yn4q6xkwgAty7SkEH7zxi6ZGVyABg5pJSqHpI+k4lj3efQ F7q88XKNTkcqW5JrM7aQ3Fq5V7pgpz928SdnpTSIWu7mjYgZSTEgO7fdiinjJWQfSUzl aPOtzZ3hYe1Vo3z3IkIqQqvKZVEfTclAT7hMu6p4seJv99HakeG91Hp5eqxCMQHb6uS1 DfHw== 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:cc; bh=fiv+LkUgf+f/jtcgRYC1L2rkdRzrJg+eY+AAJbbZsmw=; b=IL6etXx4I2ldOtpL+zlEKbOsC3dKNMCICHb/JTU8o+/kJE1xb0NzkjjR/DKrHa7nuj vMis91grzWFmYlsgmfaBaqKVA6+kSO8DY7PHUOvT1oyU3CcFpyIedaK5slat40WETU/h Gnw6TuFM1AsNfMGpsZpfYXmu7qND0cuLlFWGK35JRMwaPaehyo5zNB4MpT4OaWd/wrNB yqQEoPDpbYSC/vhf1PdOChdOuCjaaSCvVkzRdTKk9njBWPSMQkA12acUnqHiqSBCaNG4 krY7RAg6QQf3O/FiIzGfwHwmvQeiBoLztd/qUSlfBpkmJPm84d2wvqVWyr6mUtSWW6xm koTg== X-Gm-Message-State: AE9vXwPngOr6dIPB3fgqYWoEjqR5FKmph9u298yYsAVRoH29WxHoEitumw28/uDOaJYPDiuUmZVXxQKwrRiZdSVQ X-Received: by 10.28.184.19 with SMTP id i19mr21841417wmf.43.1472666059920; Wed, 31 Aug 2016 10:54:19 -0700 (PDT) MIME-Version: 1.0 From: Dirk Balfanz Date: Wed, 31 Aug 2016 17:54:09 +0000 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a114b88686031a0053b61c906 Archived-At: Cc: Tokbind WG Subject: [Unbearable] Opaqueness of Token Binding ID 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, 31 Aug 2016 17:54:25 -0000 --001a114b88686031a0053b61c906 Content-Type: text/plain; charset=UTF-8 Hi Andrei & the rest of the Unbearables, in the FIDO (well, W3C webauthn) discussion the question came up whether Token Binding IDs should be treated as opaque blobs in other protocols. In particular, FIDO assertions are (in part) over Token Binding IDs. I had originally spec'd this out as including a JWK representation of the Token Binding key, as in: // The FIDO signature is over this: { "origin": "www.example.com", "challenge": "129843adj03948", "tokbind": { "kty":"EC", "crv":"P-256", "x":"HzQwlfXX7Q4S5MtCRMzPO9tOyWjBqRl4tJ8", "y":"XVguGFLIZx1fXg375hi4-7-BxhMljw42Ht4" } } The webauthn participants are pointing out that the latest Token Binding spec says that other applications should use an opaque representation of the Token Binding ID, as in: // The FIDO signature is over this: { "origin": "www.example.com", "challenge": "129843adj03948", "tokbind": "KJDSW34AAJSjasAKJsha-ISajj8sJSA..." } where the tokbind value would be the base64-enccoding of the TokenBindingID, as specified in ietf-tokbind-protocol. It seems to me that it is safer to explicitly surface the fact that the Token Binding ID is a public key, and what kind of key it is, to other applications, rather than asking them to string-compare two strings whose semantics they don't understand. I can't come up with a particular attack, since the Token Binding ID - just like the JWK - is an unambiguous representation of they key. Furthermore, since it is a canonical serialization, string comparison *should* be ok. It seems strange, however, that the application (in this case webauthn) shouldn't be aware of the precise semantics of the tokbind value in this dictionary. Any thoughts on this? Dirk. --001a114b88686031a0053b61c906 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Andrei & the rest of the Unbearables,=C2=A0
in the FIDO (well, W3C webauthn) discussion the question came u= p whether Token Binding IDs should be treated as opaque blobs in other prot= ocols. In particular, FIDO assertions are (in part) over Token Binding IDs.=

I had originally spec'd this out as including= a JWK representation of the Token Binding key, as in:

=
// The FIDO signature is over this:
{
=C2=A0 "origin": "www.example.com",
=C2=A0 "c= hallenge": "129843adj03948",
=C2=A0 "tokbind":= =C2=A0{
=C2=A0 =C2=A0 "kty":"EC",
=C2=A0 =C2=A0 = "crv":"P-256",
=C2=A0 =C2=A0 "x":"HzQ= wlfXX7Q4S5MtCRMzPO9tOyWjBqRl4tJ8",
=C2=A0 =C2=A0 "y":&quo= t;XVguGFLIZx1fXg375hi4-7-BxhMljw42Ht4"
=C2=A0 }
}

The webauthn participants are pointing out that the lates= t Token Binding spec says that other applications should use an opaque repr= esentation of the Token Binding ID, as in:

// The FIDO signature is over this:
{
=C2=A0 "origin": "www.example.com",
=C2=A0 "challeng= e": "129843adj03948",
=C2=A0 "tokbind": "K= JDSW34AAJSjasAKJsha-ISajj8sJSA..."
}

where the tokbind value would be the base64-enccoding of the TokenB= indingID, as specified in=C2=A0ietf-tokbind-protocol.=C2=A0

<= /div>
It seems to me that it is safer to explicitly surface the fact th= at the Token Binding ID is a public key, and what kind of key it is, to oth= er applications, rather than asking them to string-compare two strings whos= e semantics they don't understand.=C2=A0

I can= 't come up with a particular attack, since the Token Binding ID - just = like the JWK - is an unambiguous representation of they key. Furthermore, s= ince it is a canonical serialization, string comparison *should* be ok.

It seems strange, however, that the application (in t= his case webauthn) shouldn't be aware of the precise semantics of the t= okbind value in this dictionary.=C2=A0

Any thought= s on this?

Dirk.

--001a114b88686031a0053b61c906-- From nobody Wed Aug 31 11:01: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 A9C7612D5EC for ; Wed, 31 Aug 2016 11:01:19 -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 Z_IPWTS0uvpT for ; Wed, 31 Aug 2016 11:01:17 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on070c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe40::70c]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C6A412D5C9 for ; Wed, 31 Aug 2016 11:01:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JeOYq87XamBTqUVxjB9yNLyaGaKrIKsFsk2VBokEuJM=; b=oq9Rptg4d4Odogn4uuTKqx7lfNVBqqOMlqdsrDY7llJdzTCUaAZJojnUsjGN4/WZrlDGQ7xigjTOViIVAEJaxsdgZ19AMreOamkqJNgzvJFppdqxJ/V3dgTZpMOAqoGtKF0vXAE/O9HGqO7EYh/DOBEAPo3y3SxV6Dl4a2rclc4= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0843.namprd03.prod.outlook.com (10.160.163.149) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.9; Wed, 31 Aug 2016 18:00:54 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Wed, 31 Aug 2016 18:00:55 +0000 From: Andrei Popov To: Dirk Balfanz Thread-Topic: Opaqueness of Token Binding ID Thread-Index: AQHSA7C1QN5Po5xpx0Wbvq3ilbKBZaBjWm6Q Date: Wed, 31 Aug 2016 18:00:55 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: bbf007c5-a779-494e-ba48-08d3d1c8c116 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0843; 6:/+U725699a89I138NLMOKsVQzbR8tkDjjb9uYeohUXJFg658IdCWbi8zbNgBDk+V+qwbJ/ytWoUEaD3gafLoH4h5JRf8jVPnw1/QMDxqJkDjT66id/xXK21k+Hawoi8ki9m9TNWQ2w4/74x65eQJcPUEF1JT4X4ChNk8K2xA6FcNPv6RvIxrT/WXZG9kpxxWtjhkZyjZdhpSaZ5tWnqdoSzvVCXyOEdN7HNH8966quB+cdysrlX+IM52R/uirtLS6WB5yWg0byZfTImdsLbi8pAp6HmD/Gzturay/yTjpP45JUPQ0vt+HQ8KPslTONDHxTX7ada00v2MFkL4sHUFng==; 5:wwLMOEagQexnZFGoHS5tRDKnI9aW12RzRfenHMMXYntc3Qeotff/43Pu5vY7Xgcl3YIn+2k/PkWkVHwZ5YugdyQRD3PFbqTvLOsLtboQQSYuHvdusggAIRPUSIth8BI0xBojUdbrKRv/rxMZksW/9g==; 24:QH0Qquc8Gz9/59+cbDaRd+j3a9y2OX04bQXjt/uvGZsCz0d9O+RhH6ic0aGwGaqRXM6SVBLmFt3q/8z1z32GaV+IBNHjXYn93ktAGlxua3o=; 7:K5+VLnLefi4Q9DqQbmhSNj6rRHneE2pMnm+HLMfPK3M2xgp2WVhtGSXfAdP5M1f4ngX50EMTApiV17baDNP+vSVFNyPeXF0nnt1XQjAZ6AwcGMv7j+LotkSKpHqdyjGaRtp2SPB2Rg46iPMp4+XOiwSkwJY89CXQEEgYtT3vPNJEN8q37nwFN4FGb9fK0xSHkv77OOBfpqC8898sVJEeYiHvcGqCBIpXa+Pkg0ukvgMmL2mpWMvxc/rO6iSuFjTb x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0843; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(211936372134217)(21748063052155)(79290750141951); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0843; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0843; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(478694002)(189002)(199003)(377454003)(19625215002)(16236675004)(15975445007)(68736007)(77096005)(122556002)(5002640100001)(2900100001)(2950100001)(101416001)(50986999)(7696003)(33656002)(8936002)(4326007)(3660700001)(9686002)(92566002)(7846002)(1680700002)(2906002)(3280700002)(189998001)(110136002)(97736004)(19609705001)(76576001)(5005710100001)(106356001)(106116001)(10090500001)(105586002)(86362001)(10400500002)(86612001)(99286002)(19300405004)(76176999)(16601075003)(87936001)(5660300001)(19580395003)(19580405001)(54356999)(7906003)(7736002)(81156014)(8676002)(81166006)(74316002)(586003)(8990500004)(790700001)(6116002)(102836003)(10290500002)(19617315012)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0843; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842CA7998347A05F161DB718CE30CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 18:00:55.1077 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0843 Archived-At: Cc: Tokbind WG Subject: Re: [Unbearable] Opaqueness of Token Binding ID 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, 31 Aug 2016 18:01:20 -0000 --_000_CY1PR0301MB0842CA7998347A05F161DB718CE30CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VEJQUk9UTyBjdXJyZW50bHkgc2F5czoNCuKAnFRva2VuIEJpbmRpbmcgcHJvdG9jb2wgaW1wbGVt ZW50YXRpb25zIFNIT1VMRCBtYWtlIFRva2VuIEJpbmRpbmcgSURzIGF2YWlsYWJsZSB0byB0aGUg YXBwbGljYXRpb24gYXMgb3BhcXVlIGJ5dGUgc2VxdWVuY2VzLuKAnQ0KDQpUaGUgcmVhc29uIGlz IHRoYXQgYSBmdXR1cmUgVEIgdmVyc2lvbiBzaG91bGQgYmUgZnJlZSB0byByZWRlZmluZSB0aGUg Y29udGVudHMgb2YgdGhlIFRCIElEcywgd2l0aG91dCBicmVha2luZyBhcHBzIHRoYXQgcmVseSBv biBhIGNlcnRhaW4gVEIgSUQgc3RydWN0dXJlLg0KDQoNCsOYICBJdCBzZWVtcyB0byBtZSB0aGF0 IGl0IGlzIHNhZmVyIHRvIGV4cGxpY2l0bHkgc3VyZmFjZSB0aGUgZmFjdCB0aGF0IHRoZSBUb2tl biBCaW5kaW5nIElEIGlzIGEgcHVibGljIGtleSwgYW5kIHdoYXQga2luZCBvZiBrZXkgaXQgaXMs IHRvIG90aGVyIGFwcGxpY2F0aW9ucywgcmF0aGVyIHRoYW4gYXNraW5nIHRoZW0gdG8gc3RyaW5n LWNvbXBhcmUgdHdvIHN0cmluZ3Mgd2hvc2Ugc2VtYW50aWNzIHRoZXkgZG9uJ3QgdW5kZXJzdGFu ZC4NClRoZW4gdGhlIGFwcGxpY2F0aW9uIHdvdWxkIG5lZWQgdG8gYmUgYXdhcmUgb2YgdGhlIFRC IHZlcnNpb24sIGFuZCB3aWxsIGxpa2VseSBuZWVkIHRvIGJlIHVwZGF0ZWQgd2hlbiB3ZSB1cGRh dGUgdGhlIFRva2VuIEJpbmRpbmcgcHJvdG9jb2wuIFdl4oCZdmUgYWxyZWFkeSBjaGFuZ2VkIHRo ZSBjb250ZW50cy9zdHJ1Y3R1cmUgb2YgVEIgSURzIGJldHdlZW4gZHJhZnRzLg0KDQpGcm9tOiBE aXJrIEJhbGZhbnogW21haWx0bzpiYWxmYW56QGdvb2dsZS5jb21dDQpTZW50OiBXZWRuZXNkYXks IEF1Z3VzdCAzMSwgMjAxNiAxMDo1NCBBTQ0KVG86IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92 QG1pY3Jvc29mdC5jb20+DQpDYzogVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZz4NClN1 YmplY3Q6IE9wYXF1ZW5lc3Mgb2YgVG9rZW4gQmluZGluZyBJRA0KDQpIaSBBbmRyZWkgJiB0aGUg cmVzdCBvZiB0aGUgVW5iZWFyYWJsZXMsDQoNCmluIHRoZSBGSURPICh3ZWxsLCBXM0Mgd2ViYXV0 aG4pIGRpc2N1c3Npb24gdGhlIHF1ZXN0aW9uIGNhbWUgdXAgd2hldGhlciBUb2tlbiBCaW5kaW5n IElEcyBzaG91bGQgYmUgdHJlYXRlZCBhcyBvcGFxdWUgYmxvYnMgaW4gb3RoZXIgcHJvdG9jb2xz LiBJbiBwYXJ0aWN1bGFyLCBGSURPIGFzc2VydGlvbnMgYXJlIChpbiBwYXJ0KSBvdmVyIFRva2Vu IEJpbmRpbmcgSURzLg0KDQpJIGhhZCBvcmlnaW5hbGx5IHNwZWMnZCB0aGlzIG91dCBhcyBpbmNs dWRpbmcgYSBKV0sgcmVwcmVzZW50YXRpb24gb2YgdGhlIFRva2VuIEJpbmRpbmcga2V5LCBhcyBp bjoNCg0KLy8gVGhlIEZJRE8gc2lnbmF0dXJlIGlzIG92ZXIgdGhpczoNCnsNCiAgIm9yaWdpbiI6 ICJ3d3cuZXhhbXBsZS5jb208aHR0cDovL3d3dy5leGFtcGxlLmNvbT4iLA0KICAiY2hhbGxlbmdl IjogIjEyOTg0M2FkajAzOTQ4IiwNCiAgInRva2JpbmQiOiB7DQogICAgImt0eSI6IkVDIiwNCiAg ICAiY3J2IjoiUC0yNTYiLA0KICAgICJ4IjoiSHpRd2xmWFg3UTRTNU10Q1JNelBPOXRPeVdqQnFS bDR0SjgiLA0KICAgICJ5IjoiWFZndUdGTElaeDFmWGczNzVoaTQtNy1CeGhNbGp3NDJIdDQiDQog IH0NCn0NCg0KVGhlIHdlYmF1dGhuIHBhcnRpY2lwYW50cyBhcmUgcG9pbnRpbmcgb3V0IHRoYXQg dGhlIGxhdGVzdCBUb2tlbiBCaW5kaW5nIHNwZWMgc2F5cyB0aGF0IG90aGVyIGFwcGxpY2F0aW9u cyBzaG91bGQgdXNlIGFuIG9wYXF1ZSByZXByZXNlbnRhdGlvbiBvZiB0aGUgVG9rZW4gQmluZGlu ZyBJRCwgYXMgaW46DQoNCi8vIFRoZSBGSURPIHNpZ25hdHVyZSBpcyBvdmVyIHRoaXM6DQp7DQog ICJvcmlnaW4iOiAid3d3LmV4YW1wbGUuY29tPGh0dHA6Ly93d3cuZXhhbXBsZS5jb20+IiwNCiAg ImNoYWxsZW5nZSI6ICIxMjk4NDNhZGowMzk0OCIsDQogICJ0b2tiaW5kIjogIktKRFNXMzRBQUpT amFzQUtKc2hhLUlTYWpqOHNKU0EuLi4iDQp9DQoNCndoZXJlIHRoZSB0b2tiaW5kIHZhbHVlIHdv dWxkIGJlIHRoZSBiYXNlNjQtZW5jY29kaW5nIG9mIHRoZSBUb2tlbkJpbmRpbmdJRCwgYXMgc3Bl Y2lmaWVkIGluIGlldGYtdG9rYmluZC1wcm90b2NvbC4NCg0KSXQgc2VlbXMgdG8gbWUgdGhhdCBp dCBpcyBzYWZlciB0byBleHBsaWNpdGx5IHN1cmZhY2UgdGhlIGZhY3QgdGhhdCB0aGUgVG9rZW4g QmluZGluZyBJRCBpcyBhIHB1YmxpYyBrZXksIGFuZCB3aGF0IGtpbmQgb2Yga2V5IGl0IGlzLCB0 byBvdGhlciBhcHBsaWNhdGlvbnMsIHJhdGhlciB0aGFuIGFza2luZyB0aGVtIHRvIHN0cmluZy1j b21wYXJlIHR3byBzdHJpbmdzIHdob3NlIHNlbWFudGljcyB0aGV5IGRvbid0IHVuZGVyc3RhbmQu DQoNCkkgY2FuJ3QgY29tZSB1cCB3aXRoIGEgcGFydGljdWxhciBhdHRhY2ssIHNpbmNlIHRoZSBU b2tlbiBCaW5kaW5nIElEIC0ganVzdCBsaWtlIHRoZSBKV0sgLSBpcyBhbiB1bmFtYmlndW91cyBy ZXByZXNlbnRhdGlvbiBvZiB0aGV5IGtleS4gRnVydGhlcm1vcmUsIHNpbmNlIGl0IGlzIGEgY2Fu b25pY2FsIHNlcmlhbGl6YXRpb24sIHN0cmluZyBjb21wYXJpc29uICpzaG91bGQqIGJlIG9rLg0K DQpJdCBzZWVtcyBzdHJhbmdlLCBob3dldmVyLCB0aGF0IHRoZSBhcHBsaWNhdGlvbiAoaW4gdGhp cyBjYXNlIHdlYmF1dGhuKSBzaG91bGRuJ3QgYmUgYXdhcmUgb2YgdGhlIHByZWNpc2Ugc2VtYW50 aWNzIG9mIHRoZSB0b2tiaW5kIHZhbHVlIGluIHRoaXMgZGljdGlvbmFyeS4NCg0KQW55IHRob3Vn aHRzIG9uIHRoaXM/DQoNCkRpcmsuDQoNCg== --_000_CY1PR0301MB0842CA7998347A05F161DB718CE30CY1PR0301MB0842_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41 aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3Jt YWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozMTY2 OTE4NzA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjQy MzAwNjcwOCAxOTIwNTgwNTQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1m b250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iOw0KCWNvbG9yOmJsYWNrO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy 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 LHNhbnMtc2VyaWYiPlRCUFJPVE8gY3VycmVudGx5IHNheXM6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7igJw8L3NwYW4+PHNwYW4g bGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRh bmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VG9rZW4gQmluZGluZyBwcm90b2NvbCBp bXBsZW1lbnRhdGlvbnMgU0hPVUxEIG1ha2UgVG9rZW4gQmluZGluZyBJRHMgYXZhaWxhYmxlDQog dG8gdGhlIGFwcGxpY2F0aW9uIGFzIG9wYXF1ZSBieXRlIHNlcXVlbmNlcy7igJ08bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGUgcmVh c29uIGlzIHRoYXQgYSBmdXR1cmUgVEIgdmVyc2lvbiBzaG91bGQgYmUgZnJlZSB0byByZWRlZmlu ZSB0aGUgY29udGVudHMgb2YgdGhlIFRCIElEcywgd2l0aG91dCBicmVha2luZyBhcHBzIHRoYXQg cmVseSBvbiBhIGNlcnRhaW4gVEIgSUQgc3RydWN0dXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpXaW5nZGluZ3M7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5JdCBzZWVtcyB0byBtZSB0aGF0 IGl0IGlzIHNhZmVyIHRvIGV4cGxpY2l0bHkgc3VyZmFjZSB0aGUgZmFjdCB0aGF0IHRoZSBUb2tl biBCaW5kaW5nIElEIGlzIGEgcHVibGljIGtleSwgYW5kIHdoYXQga2luZCBvZiBrZXkgaXQgaXMs IHRvIG90aGVyIGFwcGxpY2F0aW9ucywgcmF0aGVyIHRoYW4gYXNraW5nIHRoZW0gdG8gc3RyaW5n LWNvbXBhcmUgdHdvIHN0cmluZ3Mgd2hvc2Ugc2VtYW50aWNzDQogdGhleSBkb24ndCB1bmRlcnN0 YW5kLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5UaGVuIHRoZSBhcHBsaWNhdGlvbiB3b3VsZCBuZWVkIHRvIGJlIGF3YXJlIG9mIHRo ZSBUQiB2ZXJzaW9uLCBhbmQgd2lsbCBsaWtlbHkgbmVlZCB0byBiZSB1cGRhdGVkIHdoZW4gd2Ug dXBkYXRlIHRoZSBUb2tlbiBCaW5kaW5nIHByb3RvY29sLiBXZeKAmXZlIGFscmVhZHkgY2hhbmdl ZCB0aGUgY29udGVudHMvc3RydWN0dXJlDQogb2YgVEIgSURzIGJldHdlZW4gZHJhZnRzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gRGlyayBCYWxm YW56IFttYWlsdG86YmFsZmFuekBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l c2RheSwgQXVndXN0IDMxLCAyMDE2IDEwOjU0IEFNPGJyPg0KPGI+VG86PC9iPiBBbmRyZWkgUG9w b3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gVG9r YmluZCBXRyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g T3BhcXVlbmVzcyBvZiBUb2tlbiBCaW5kaW5nIElEPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkgQW5kcmVpICZhbXA7IHRoZSByZXN0IG9mIHRoZSBVbmJlYXJhYmxlcywm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmluIHRo ZSBGSURPICh3ZWxsLCBXM0Mgd2ViYXV0aG4pIGRpc2N1c3Npb24gdGhlIHF1ZXN0aW9uIGNhbWUg dXAgd2hldGhlciBUb2tlbiBCaW5kaW5nIElEcyBzaG91bGQgYmUgdHJlYXRlZCBhcyBvcGFxdWUg YmxvYnMgaW4gb3RoZXIgcHJvdG9jb2xzLiBJbiBwYXJ0aWN1bGFyLCBGSURPIGFzc2VydGlvbnMg YXJlIChpbiBwYXJ0KSBvdmVyIFRva2VuIEJpbmRpbmcgSURzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhZCBvcmlnaW5hbGx5IHNwZWMn ZCB0aGlzIG91dCBhcyBpbmNsdWRpbmcgYSBKV0sgcmVwcmVzZW50YXRpb24gb2YgdGhlIFRva2Vu IEJpbmRpbmcga2V5LCBhcyBpbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij4vLyBUaGUgRklETyBzaWduYXR1cmUgaXMgb3ZlciB0aGlzOjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ezxicj4NCiZuYnNwOyAm cXVvdDtvcmlnaW4mcXVvdDs6ICZxdW90OzxhIGhyZWY9Imh0dHA6Ly93d3cuZXhhbXBsZS5jb20i Pnd3dy5leGFtcGxlLmNvbTwvYT4mcXVvdDssPGJyPg0KJm5ic3A7ICZxdW90O2NoYWxsZW5nZSZx dW90OzogJnF1b3Q7MTI5ODQzYWRqMDM5NDgmcXVvdDssPGJyPg0KJm5ic3A7ICZxdW90O3Rva2Jp bmQmcXVvdDs6Jm5ic3A7ezxicj4NCiZuYnNwOyAmbmJzcDsgJnF1b3Q7a3R5JnF1b3Q7OiZxdW90 O0VDJnF1b3Q7LCA8YnI+DQombmJzcDsgJm5ic3A7ICZxdW90O2NydiZxdW90OzomcXVvdDtQLTI1 NiZxdW90Oyw8YnI+DQombmJzcDsgJm5ic3A7ICZxdW90O3gmcXVvdDs6JnF1b3Q7SHpRd2xmWFg3 UTRTNU10Q1JNelBPOXRPeVdqQnFSbDR0SjgmcXVvdDssPGJyPg0KJm5ic3A7ICZuYnNwOyAmcXVv dDt5JnF1b3Q7OiZxdW90O1hWZ3VHRkxJWngxZlhnMzc1aGk0LTctQnhoTWxqdzQySHQ0JnF1b3Q7 PGJyPg0KJm5ic3A7IH08YnI+DQp9PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgd2ViYXV0aG4gcGFydGljaXBhbnRzIGFyZSBw b2ludGluZyBvdXQgdGhhdCB0aGUgbGF0ZXN0IFRva2VuIEJpbmRpbmcgc3BlYyBzYXlzIHRoYXQg b3RoZXIgYXBwbGljYXRpb25zIHNob3VsZCB1c2UgYW4gb3BhcXVlIHJlcHJlc2VudGF0aW9uIG9m IHRoZSBUb2tlbiBCaW5kaW5nIElELCBhcyBpbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Ly8gVGhlIEZJRE8gc2lnbmF0dXJlIGlzIG92ZXIg dGhpczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pns8YnI+DQombmJzcDsgJnF1b3Q7b3JpZ2luJnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwOi8v d3d3LmV4YW1wbGUuY29tIj53d3cuZXhhbXBsZS5jb208L2E+JnF1b3Q7LDxicj4NCiZuYnNwOyAm cXVvdDtjaGFsbGVuZ2UmcXVvdDs6ICZxdW90OzEyOTg0M2FkajAzOTQ4JnF1b3Q7LDxicj4NCiZu YnNwOyAmcXVvdDt0b2tiaW5kJnF1b3Q7OiAmcXVvdDtLSkRTVzM0QUFKU2phc0FLSnNoYS1JU2Fq ajhzSlNBLi4uJnF1b3Q7PGJyPg0KfTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53aGVyZSB0aGUgdG9rYmluZCB2YWx1 ZSB3b3VsZCBiZSB0aGUgYmFzZTY0LWVuY2NvZGluZyBvZiB0aGUgVG9rZW5CaW5kaW5nSUQsIGFz IHNwZWNpZmllZCBpbiZuYnNwO2lldGYtdG9rYmluZC1wcm90b2NvbC4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgc2VlbXMgdG8g bWUgdGhhdCBpdCBpcyBzYWZlciB0byBleHBsaWNpdGx5IHN1cmZhY2UgdGhlIGZhY3QgdGhhdCB0 aGUgVG9rZW4gQmluZGluZyBJRCBpcyBhIHB1YmxpYyBrZXksIGFuZCB3aGF0IGtpbmQgb2Yga2V5 IGl0IGlzLCB0byBvdGhlciBhcHBsaWNhdGlvbnMsIHJhdGhlciB0aGFuIGFza2luZyB0aGVtIHRv IHN0cmluZy1jb21wYXJlIHR3byBzdHJpbmdzIHdob3NlIHNlbWFudGljcyB0aGV5IGRvbid0DQog dW5kZXJzdGFuZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBjYW4ndCBjb21lIHVwIHdpdGggYSBwYXJ0aWN1bGFyIGF0dGFjaywg c2luY2UgdGhlIFRva2VuIEJpbmRpbmcgSUQgLSBqdXN0IGxpa2UgdGhlIEpXSyAtIGlzIGFuIHVu YW1iaWd1b3VzIHJlcHJlc2VudGF0aW9uIG9mIHRoZXkga2V5LiBGdXJ0aGVybW9yZSwgc2luY2Ug aXQgaXMgYSBjYW5vbmljYWwgc2VyaWFsaXphdGlvbiwgc3RyaW5nIGNvbXBhcmlzb24gKnNob3Vs ZCogYmUgb2suPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkl0IHNlZW1zIHN0cmFuZ2UsIGhvd2V2ZXIsIHRoYXQgdGhlIGFwcGxpY2F0aW9uIChp biB0aGlzIGNhc2Ugd2ViYXV0aG4pIHNob3VsZG4ndCBiZSBhd2FyZSBvZiB0aGUgcHJlY2lzZSBz ZW1hbnRpY3Mgb2YgdGhlIHRva2JpbmQgdmFsdWUgaW4gdGhpcyBkaWN0aW9uYXJ5LiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbnkg dGhvdWdodHMgb24gdGhpcz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RGlyay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR0301MB0842CA7998347A05F161DB718CE30CY1PR0301MB0842_-- From nobody Wed Aug 31 11:31:54 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 D3FD012D608 for ; Wed, 31 Aug 2016 11:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 rgB6x1bjpbQk for ; Wed, 31 Aug 2016 11:31:50 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0138.outbound.protection.outlook.com [104.47.40.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B74F412D695 for ; Wed, 31 Aug 2016 11:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dTO65UKV2CwmNLO9qWHvqX0MnftmAmTiH8uCSj+i/SA=; b=hPxh5LUYx4gFBffyu5P2pHpMEvDNgcwpP+JaeurPtx4edg8J6utVn4Ybyvqz4EOKNRTZWHJcpPNqH+6Gwwndn9X5cAOkBhxyJf0OBWLHtLcdZEzBRINEt3jC2Edbgg6VE03oK3f3Ys2UwSHVcjCnsThlNQmdvEWsw4B+FfAXJcw= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Wed, 31 Aug 2016 18:31:17 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Wed, 31 Aug 2016 18:31:17 +0000 From: Andrei Popov To: Tokbind WG Thread-Topic: Opaqueness of Token Binding ID Thread-Index: AQHSA7C1QN5Po5xpx0Wbvq3ilbKBZaBjWm6QgAAJvkA= Date: Wed, 31 Aug 2016 18:31:16 +0000 Message-ID: References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: fe699cb9-918b-4de1-65a1-08d3d1ccfeff x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 6:NWCczjxL3opgXX/C2tXbOVttBdVJ8SZRwPqO+gcLOuw5lkVJ76+FzmeJcvar2IIlSOnZRSrPBXWSIo1SbO80oZ51teO3lARkXQS9fZYimqZGgnp1WqNHD3iHLsR8VW9zCRCgg/q1qf6PGu9WWn5jQ/nsw4FzMj2IeSRxGQNDHpGg0GxqNqrLGnJ1NiwN+Pvn6ANVOrejckrUSP3URs+wfiyrg0EOhRPzXMmCrmsDIuVREJnaEq9dB1WGUCKQe4BQihh1qBp2Q55FCZtyuzGpfds843BwezADP+EZwkXWb1CFnV7C8VnptWNskCNUUCgACAUY78RRbyq95K5SZMsdqQ==; 5:iwo5+TpvvNlMMnn/1W5tt3d+xP4ZryVIpawBw0WM9/LvxIMb+WCnIo0UcM6rskYWkSpbv98fI2dz9Fvp7vq821TtFc3F1zy8nlLFEEGD7S0eaI5nIyJTQxDJCLy6TCNBJulrsMs4/DtSzECvd/x6cw==; 24:uwvwwiLBnI773z0miLZ/I6XKUXkmh31XqdUG86Lh1Hf4j0ZzbmpNjN85wMMB49ia5FfazIbYPZeyTffJ9Rqyf/b1/xxVMeRSqYJh6xrll1E=; 7:fJB8d9f+CE0F5xUOVmnKjJ8Aul4MRdPZH6nOP4yWpnsOJbDo2L9pkwM/b4dUzf0/48ILHSgeWQU1NmTQ9prjCCJlyO7+0cF1GSkYwJiWMYUPQVMZYrOqGTwt/Y7EpFp5pYMBJlEChZRtHWXbYzTCcVJINuPEuEFPL04jtOXOae1Xa9ngZ0g0pFFOA5zK5tjp/90nw4mfIQQrADMDsGTPQWnsuQWCEINxbur+C+c1fel/vQ19/SVskpozF0zrERwa x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0842; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(211936372134217)(21748063052155)(79290750141951); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(478694002)(199003)(189002)(122556002)(1680700002)(86362001)(15975445007)(77096005)(6116002)(76576001)(5002640100001)(5660300001)(106356001)(790700001)(586003)(102836003)(107886002)(3280700002)(19580405001)(16601075003)(92566002)(110136002)(19617315012)(450100001)(189998001)(105586002)(19625215002)(87936001)(8936002)(19580395003)(5005710100001)(97736004)(2900100001)(2906002)(10290500002)(19300405004)(86612001)(33656002)(101416001)(50986999)(106116001)(8990500004)(7846002)(54356999)(10400500002)(74316002)(3660700001)(9686002)(7736002)(7696003)(76176999)(68736007)(8676002)(99286002)(81166006)(19609705001)(81156014)(16236675004)(11100500001)(10090500001)(7906003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB084219708F8ADE48189A3A888CE30CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 18:31:16.8954 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Subject: Re: [Unbearable] Opaqueness of Token Binding ID 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, 31 Aug 2016 18:31:53 -0000 --_000_CY1PR0301MB084219708F8ADE48189A3A888CE30CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VEJQUk9UTyBjdXJyZW50bHkgc2F5czoNCuKAnFRva2VuIEJpbmRpbmcgcHJvdG9jb2wgaW1wbGVt ZW50YXRpb25zIFNIT1VMRCBtYWtlIFRva2VuIEJpbmRpbmcgSURzIGF2YWlsYWJsZSB0byB0aGUg YXBwbGljYXRpb24gYXMgb3BhcXVlIGJ5dGUgc2VxdWVuY2VzLuKAnQ0KDQpUaGUgcmVhc29uIGlz IHRoYXQgYSBmdXR1cmUgVEIgdmVyc2lvbiBzaG91bGQgYmUgZnJlZSB0byByZWRlZmluZSB0aGUg Y29udGVudHMgb2YgdGhlIFRCIElEcywgd2l0aG91dCBicmVha2luZyBhcHBzIHRoYXQgcmVseSBv biBhIGNlcnRhaW4gVEIgSUQgc3RydWN0dXJlLg0KDQoNCsOYICBJdCBzZWVtcyB0byBtZSB0aGF0 IGl0IGlzIHNhZmVyIHRvIGV4cGxpY2l0bHkgc3VyZmFjZSB0aGUgZmFjdCB0aGF0IHRoZSBUb2tl biBCaW5kaW5nIElEIGlzIGEgcHVibGljIGtleSwgYW5kIHdoYXQga2luZCBvZiBrZXkgaXQgaXMs IHRvIG90aGVyIGFwcGxpY2F0aW9ucywgcmF0aGVyIHRoYW4gYXNraW5nIHRoZW0gdG8gc3RyaW5n LWNvbXBhcmUgdHdvIHN0cmluZ3Mgd2hvc2Ugc2VtYW50aWNzIHRoZXkgZG9uJ3QgdW5kZXJzdGFu ZC4NClRoZW4gdGhlIGFwcGxpY2F0aW9uIHdvdWxkIG5lZWQgdG8gYmUgYXdhcmUgb2YgdGhlIFRC IHZlcnNpb24sIGFuZCB3aWxsIGxpa2VseSBuZWVkIHRvIGJlIHVwZGF0ZWQgd2hlbiB3ZSB1cGRh dGUgdGhlIFRva2VuIEJpbmRpbmcgcHJvdG9jb2wuIFdl4oCZdmUgYWxyZWFkeSBjaGFuZ2VkIHRo ZSBjb250ZW50cy9zdHJ1Y3R1cmUgb2YgVEIgSURzIGJldHdlZW4gZHJhZnRzLg0KDQpGcm9tOiBE aXJrIEJhbGZhbnogW21haWx0bzpiYWxmYW56QGdvb2dsZS5jb21dDQpTZW50OiBXZWRuZXNkYXks IEF1Z3VzdCAzMSwgMjAxNiAxMDo1NCBBTQ0KVG86IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92 QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4NCkNjOiBU b2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzp1bmJlYXJhYmxlQGlldGYub3Jn Pj4NClN1YmplY3Q6IE9wYXF1ZW5lc3Mgb2YgVG9rZW4gQmluZGluZyBJRA0KDQpIaSBBbmRyZWkg JiB0aGUgcmVzdCBvZiB0aGUgVW5iZWFyYWJsZXMsDQoNCmluIHRoZSBGSURPICh3ZWxsLCBXM0Mg d2ViYXV0aG4pIGRpc2N1c3Npb24gdGhlIHF1ZXN0aW9uIGNhbWUgdXAgd2hldGhlciBUb2tlbiBC aW5kaW5nIElEcyBzaG91bGQgYmUgdHJlYXRlZCBhcyBvcGFxdWUgYmxvYnMgaW4gb3RoZXIgcHJv dG9jb2xzLiBJbiBwYXJ0aWN1bGFyLCBGSURPIGFzc2VydGlvbnMgYXJlIChpbiBwYXJ0KSBvdmVy IFRva2VuIEJpbmRpbmcgSURzLg0KDQpJIGhhZCBvcmlnaW5hbGx5IHNwZWMnZCB0aGlzIG91dCBh cyBpbmNsdWRpbmcgYSBKV0sgcmVwcmVzZW50YXRpb24gb2YgdGhlIFRva2VuIEJpbmRpbmcga2V5 LCBhcyBpbjoNCg0KLy8gVGhlIEZJRE8gc2lnbmF0dXJlIGlzIG92ZXIgdGhpczoNCnsNCiAgIm9y aWdpbiI6ICJ3d3cuZXhhbXBsZS5jb208aHR0cDovL3d3dy5leGFtcGxlLmNvbT4iLA0KICAiY2hh bGxlbmdlIjogIjEyOTg0M2FkajAzOTQ4IiwNCiAgInRva2JpbmQiOiB7DQogICAgImt0eSI6IkVD IiwNCiAgICAiY3J2IjoiUC0yNTYiLA0KICAgICJ4IjoiSHpRd2xmWFg3UTRTNU10Q1JNelBPOXRP eVdqQnFSbDR0SjgiLA0KICAgICJ5IjoiWFZndUdGTElaeDFmWGczNzVoaTQtNy1CeGhNbGp3NDJI dDQiDQogIH0NCn0NCg0KVGhlIHdlYmF1dGhuIHBhcnRpY2lwYW50cyBhcmUgcG9pbnRpbmcgb3V0 IHRoYXQgdGhlIGxhdGVzdCBUb2tlbiBCaW5kaW5nIHNwZWMgc2F5cyB0aGF0IG90aGVyIGFwcGxp Y2F0aW9ucyBzaG91bGQgdXNlIGFuIG9wYXF1ZSByZXByZXNlbnRhdGlvbiBvZiB0aGUgVG9rZW4g QmluZGluZyBJRCwgYXMgaW46DQoNCi8vIFRoZSBGSURPIHNpZ25hdHVyZSBpcyBvdmVyIHRoaXM6 DQp7DQogICJvcmlnaW4iOiAid3d3LmV4YW1wbGUuY29tPGh0dHA6Ly93d3cuZXhhbXBsZS5jb20+ IiwNCiAgImNoYWxsZW5nZSI6ICIxMjk4NDNhZGowMzk0OCIsDQogICJ0b2tiaW5kIjogIktKRFNX MzRBQUpTamFzQUtKc2hhLUlTYWpqOHNKU0EuLi4iDQp9DQoNCndoZXJlIHRoZSB0b2tiaW5kIHZh bHVlIHdvdWxkIGJlIHRoZSBiYXNlNjQtZW5jY29kaW5nIG9mIHRoZSBUb2tlbkJpbmRpbmdJRCwg YXMgc3BlY2lmaWVkIGluIGlldGYtdG9rYmluZC1wcm90b2NvbC4NCg0KSXQgc2VlbXMgdG8gbWUg dGhhdCBpdCBpcyBzYWZlciB0byBleHBsaWNpdGx5IHN1cmZhY2UgdGhlIGZhY3QgdGhhdCB0aGUg VG9rZW4gQmluZGluZyBJRCBpcyBhIHB1YmxpYyBrZXksIGFuZCB3aGF0IGtpbmQgb2Yga2V5IGl0 IGlzLCB0byBvdGhlciBhcHBsaWNhdGlvbnMsIHJhdGhlciB0aGFuIGFza2luZyB0aGVtIHRvIHN0 cmluZy1jb21wYXJlIHR3byBzdHJpbmdzIHdob3NlIHNlbWFudGljcyB0aGV5IGRvbid0IHVuZGVy c3RhbmQuDQoNCkkgY2FuJ3QgY29tZSB1cCB3aXRoIGEgcGFydGljdWxhciBhdHRhY2ssIHNpbmNl IHRoZSBUb2tlbiBCaW5kaW5nIElEIC0ganVzdCBsaWtlIHRoZSBKV0sgLSBpcyBhbiB1bmFtYmln dW91cyByZXByZXNlbnRhdGlvbiBvZiB0aGV5IGtleS4gRnVydGhlcm1vcmUsIHNpbmNlIGl0IGlz IGEgY2Fub25pY2FsIHNlcmlhbGl6YXRpb24sIHN0cmluZyBjb21wYXJpc29uICpzaG91bGQqIGJl IG9rLg0KDQpJdCBzZWVtcyBzdHJhbmdlLCBob3dldmVyLCB0aGF0IHRoZSBhcHBsaWNhdGlvbiAo aW4gdGhpcyBjYXNlIHdlYmF1dGhuKSBzaG91bGRuJ3QgYmUgYXdhcmUgb2YgdGhlIHByZWNpc2Ug c2VtYW50aWNzIG9mIHRoZSB0b2tiaW5kIHZhbHVlIGluIHRoaXMgZGljdGlvbmFyeS4NCg0KQW55 IHRob3VnaHRzIG9uIHRoaXM/DQoNCkRpcmsuDQoNCg== --_000_CY1PR0301MB084219708F8ADE48189A3A888CE30CY1PR0301MB0842_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlZlcmRhbmE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41 aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3Jt YWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MzE2NjkxODcwOw0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo0MjMwMDY3MDggMTkyMDU4MDU0IDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjpibGFjazt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UQlBST1RPIGN1cnJl bnRseSBzYXlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+4oCcPC9zcGFuPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPlRva2VuIEJpbmRpbmcgcHJvdG9jb2wgaW1wbGVtZW50YXRpb25zIFNIT1VMRCBtYWtl IFRva2VuIEJpbmRpbmcgSURzIGF2YWlsYWJsZQ0KIHRvIHRoZSBhcHBsaWNhdGlvbiBhcyBvcGFx dWUgYnl0ZSBzZXF1ZW5jZXMu4oCdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4i IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhlIHJlYXNvbiBpcyB0aGF0IGEgZnV0dXJlIFRCIHZl cnNpb24gc2hvdWxkIGJlIGZyZWUgdG8gcmVkZWZpbmUgdGhlIGNvbnRlbnRzIG9mIHRoZSBUQiBJ RHMsIHdpdGhvdXQgYnJlYWtpbmcgYXBwcyB0aGF0IHJlbHkgb24gYSBjZXJ0YWluIFRCIElEIHN0 cnVjdHVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VmVy ZGFuYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0u MjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzO2NvbG9yOmJsYWNr Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+SXQgc2VlbXMgdG8gbWUgdGhhdCBpdCBpcyBzYWZlciB0byBleHBsaWNpdGx5 IHN1cmZhY2UgdGhlIGZhY3QgdGhhdCB0aGUgVG9rZW4gQmluZGluZyBJRCBpcyBhIHB1YmxpYyBr ZXksIGFuZCB3aGF0IGtpbmQgb2Yga2V5IGl0IGlzLCB0byBvdGhlciBhcHBsaWNhdGlvbnMsIHJh dGhlciB0aGFuIGFza2luZyB0aGVtIHRvIHN0cmluZy1jb21wYXJlIHR3byBzdHJpbmdzIHdob3Nl IHNlbWFudGljcw0KIHRoZXkgZG9uJ3QgdW5kZXJzdGFuZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlbiB0aGUgYXBwbGljYXRp b24gd291bGQgbmVlZCB0byBiZSBhd2FyZSBvZiB0aGUgVEIgdmVyc2lvbiwgYW5kIHdpbGwgbGlr ZWx5IG5lZWQgdG8gYmUgdXBkYXRlZCB3aGVuIHdlIHVwZGF0ZSB0aGUgVG9rZW4gQmluZGluZyBw cm90b2NvbC4gV2XigJl2ZSBhbHJlYWR5IGNoYW5nZWQgdGhlIGNvbnRlbnRzL3N0cnVjdHVyZQ0K IG9mIFRCIElEcyBiZXR3ZWVuIGRyYWZ0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IERpcmsgQmFsZmFueiBbPGEgaHJlZj0ibWFpbHRvOmJhbGZh bnpAZ29vZ2xlLmNvbSI+bWFpbHRvOmJhbGZhbnpAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYgMTA6NTQgQU08YnI+DQo8Yj5Ubzo8 L2I+IEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3Nv ZnQuY29tIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBUb2tiaW5kIFdHICZsdDs8YSBocmVmPSJtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZyI+dW5i ZWFyYWJsZUBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IE9wYXF1ZW5lc3Mg b2YgVG9rZW4gQmluZGluZyBJRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpIEFuZHJlaSAmYW1wOyB0aGUgcmVzdCBvZiB0aGUgVW5iZWFyYWJsZXMsJm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pbiB0aGUgRklETyAod2Vs bCwgVzNDIHdlYmF1dGhuKSBkaXNjdXNzaW9uIHRoZSBxdWVzdGlvbiBjYW1lIHVwIHdoZXRoZXIg VG9rZW4gQmluZGluZyBJRHMgc2hvdWxkIGJlIHRyZWF0ZWQgYXMgb3BhcXVlIGJsb2JzIGluIG90 aGVyIHByb3RvY29scy4gSW4gcGFydGljdWxhciwgRklETyBhc3NlcnRpb25zIGFyZSAoaW4gcGFy dCkgb3ZlciBUb2tlbiBCaW5kaW5nIElEcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYWQgb3JpZ2luYWxseSBzcGVjJ2QgdGhpcyBvdXQg YXMgaW5jbHVkaW5nIGEgSldLIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBUb2tlbiBCaW5kaW5nIGtl eSwgYXMgaW46PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Ly8gVGhlIEZJRE8gc2lnbmF0dXJlIGlzIG92ZXIgdGhpczo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPns8YnI+DQombmJzcDsgJnF1b3Q7b3JpZ2lu JnF1b3Q7OiAmcXVvdDs8YSBocmVmPSJodHRwOi8vd3d3LmV4YW1wbGUuY29tIj53d3cuZXhhbXBs ZS5jb208L2E+JnF1b3Q7LDxicj4NCiZuYnNwOyAmcXVvdDtjaGFsbGVuZ2UmcXVvdDs6ICZxdW90 OzEyOTg0M2FkajAzOTQ4JnF1b3Q7LDxicj4NCiZuYnNwOyAmcXVvdDt0b2tiaW5kJnF1b3Q7OiZu YnNwO3s8YnI+DQombmJzcDsgJm5ic3A7ICZxdW90O2t0eSZxdW90OzomcXVvdDtFQyZxdW90Oywg PGJyPg0KJm5ic3A7ICZuYnNwOyAmcXVvdDtjcnYmcXVvdDs6JnF1b3Q7UC0yNTYmcXVvdDssPGJy Pg0KJm5ic3A7ICZuYnNwOyAmcXVvdDt4JnF1b3Q7OiZxdW90O0h6UXdsZlhYN1E0UzVNdENSTXpQ Tzl0T3lXakJxUmw0dEo4JnF1b3Q7LDxicj4NCiZuYnNwOyAmbmJzcDsgJnF1b3Q7eSZxdW90Ozom cXVvdDtYVmd1R0ZMSVp4MWZYZzM3NWhpNC03LUJ4aE1sanc0Mkh0NCZxdW90Ozxicj4NCiZuYnNw OyB9PGJyPg0KfTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhlIHdlYmF1dGhuIHBhcnRpY2lwYW50cyBhcmUgcG9pbnRpbmcgb3V0 IHRoYXQgdGhlIGxhdGVzdCBUb2tlbiBCaW5kaW5nIHNwZWMgc2F5cyB0aGF0IG90aGVyIGFwcGxp Y2F0aW9ucyBzaG91bGQgdXNlIGFuIG9wYXF1ZSByZXByZXNlbnRhdGlvbiBvZiB0aGUgVG9rZW4g QmluZGluZyBJRCwgYXMgaW46PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPi8vIFRoZSBGSURPIHNpZ25hdHVyZSBpcyBvdmVyIHRoaXM6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij57PGJyPg0KJm5i c3A7ICZxdW90O29yaWdpbiZxdW90OzogJnF1b3Q7PGEgaHJlZj0iaHR0cDovL3d3dy5leGFtcGxl LmNvbSI+d3d3LmV4YW1wbGUuY29tPC9hPiZxdW90Oyw8YnI+DQombmJzcDsgJnF1b3Q7Y2hhbGxl bmdlJnF1b3Q7OiAmcXVvdDsxMjk4NDNhZGowMzk0OCZxdW90Oyw8YnI+DQombmJzcDsgJnF1b3Q7 dG9rYmluZCZxdW90OzogJnF1b3Q7S0pEU1czNEFBSlNqYXNBS0pzaGEtSVNhamo4c0pTQS4uLiZx dW90Ozxicj4NCn08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hlcmUgdGhlIHRva2JpbmQgdmFsdWUgd291bGQgYmUg dGhlIGJhc2U2NC1lbmNjb2Rpbmcgb2YgdGhlIFRva2VuQmluZGluZ0lELCBhcyBzcGVjaWZpZWQg aW4mbmJzcDtpZXRmLXRva2JpbmQtcHJvdG9jb2wuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHNlZW1zIHRvIG1lIHRoYXQgaXQg aXMgc2FmZXIgdG8gZXhwbGljaXRseSBzdXJmYWNlIHRoZSBmYWN0IHRoYXQgdGhlIFRva2VuIEJp bmRpbmcgSUQgaXMgYSBwdWJsaWMga2V5LCBhbmQgd2hhdCBraW5kIG9mIGtleSBpdCBpcywgdG8g b3RoZXIgYXBwbGljYXRpb25zLCByYXRoZXIgdGhhbiBhc2tpbmcgdGhlbSB0byBzdHJpbmctY29t cGFyZSB0d28gc3RyaW5ncyB3aG9zZSBzZW1hbnRpY3MgdGhleSBkb24ndA0KIHVuZGVyc3RhbmQu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgY2FuJ3QgY29tZSB1cCB3aXRoIGEgcGFydGljdWxhciBhdHRhY2ssIHNpbmNlIHRoZSBU b2tlbiBCaW5kaW5nIElEIC0ganVzdCBsaWtlIHRoZSBKV0sgLSBpcyBhbiB1bmFtYmlndW91cyBy ZXByZXNlbnRhdGlvbiBvZiB0aGV5IGtleS4gRnVydGhlcm1vcmUsIHNpbmNlIGl0IGlzIGEgY2Fu b25pY2FsIHNlcmlhbGl6YXRpb24sIHN0cmluZyBjb21wYXJpc29uICpzaG91bGQqIGJlIG9rLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBz ZWVtcyBzdHJhbmdlLCBob3dldmVyLCB0aGF0IHRoZSBhcHBsaWNhdGlvbiAoaW4gdGhpcyBjYXNl IHdlYmF1dGhuKSBzaG91bGRuJ3QgYmUgYXdhcmUgb2YgdGhlIHByZWNpc2Ugc2VtYW50aWNzIG9m IHRoZSB0b2tiaW5kIHZhbHVlIGluIHRoaXMgZGljdGlvbmFyeS4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW55IHRob3VnaHRzIG9u IHRoaXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkRpcmsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_CY1PR0301MB084219708F8ADE48189A3A888CE30CY1PR0301MB0842_-- From nobody Wed Aug 31 12:13: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 DFFC812D6AC for ; Wed, 31 Aug 2016 12:13:15 -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 ME15FEy8eCLV for ; Wed, 31 Aug 2016 12:13:14 -0700 (PDT) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 1C3F912D6AD for ; Wed, 31 Aug 2016 12:13:14 -0700 (PDT) Received: by mail-it0-x22f.google.com with SMTP id i184so7668532itf.1 for ; Wed, 31 Aug 2016 12:13:14 -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=PLspP63ug5sSbVc/LlGoH7eYKNWk5SGqscI96rkWRLs=; b=gs1ylTwlSS8e/FsNvCItgo9CmiP2ZJRHhIS9SHkjD4FVroQEcYui8aL+wC4iMkpJfM PTb7bP7MtnZx3PSLCFKUu1MyM59uiKax992CNKVuIl15MJeHb/qYGOlIPVaCc2vF20ta XHZxSYsXLgPix8jHjtKPZP1cHCMOUZwF+7Nwc= 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=PLspP63ug5sSbVc/LlGoH7eYKNWk5SGqscI96rkWRLs=; b=U8IHxWK5N3qJ8awHymi2Ewo8GEoO+42Q4hxfHZUjl25zoTTVdJ/bDPPv4A/1MhOvby 7oHPOwfFPm46KVk66/tIkdiOvhfeCiT7Y8dPzDPzoLpCtd8NXbWVWgqZFKZcp5YJ2FwK nKAj1ZCCuBtrKf4fYIWHiWwBgjX74jx6nax1R0caYjqlydpFEcj/SVjHTt33UyqPWN0W iTJDh/FvnRN2e/3crpJkNaOHeFaXbWModUc+1HMXlnihQsVlB/DcwoD7lt4YXcqdz32g BJoZh6lDePaFLdooWlGtTyKYLT0YkMUOmrE/B6250Je0lWIR/5Hc4uDRtmrxF7gbcJIx v1Vg== X-Gm-Message-State: AE9vXwNus90H1Zm+1VjOEZ4n439ezW848KUMQ8Y/EvThzpjFdJMl9gyOsymEP0PXpuR94mNL+KYHf9XlMNaIeMdm X-Received: by 10.36.91.213 with SMTP id g204mr15933398itb.42.1472670793054; Wed, 31 Aug 2016 12:13:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.114.20 with HTTP; Wed, 31 Aug 2016 12:12:42 -0700 (PDT) In-Reply-To: References: <96c11d53-03c0-bcc3-92e1-ea73ce4d6a57@sunet.se> From: Brian Campbell Date: Wed, 31 Aug 2016 13:12:42 -0600 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a114401007de08c053b62e3f8 Archived-At: Cc: Tokbind WG , Leif Johansson , Bill Cox Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? 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, 31 Aug 2016 19:13:16 -0000 --001a114401007de08c053b62e3f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In which case I'd again suggest that the signature input be the concatenated items directly (no hash) and that hashing or not be part of the signature scheme associated with each key parameters type. On Wed, Aug 31, 2016 at 11:18 AM, Andrei Popov wrote: > Thinking more about this, generating EKMs multiple times per connection > would be a significant perf issue for us. > > > > EKM is a product of the TLS master secret, and on Windows we keep the TLS > master secrets isolated from the TLS client and server applications. > > So if we were to go with Bill=E2=80=99s idea, we would have to do extra I= PC every > time we generate or verify a binding. > > > > On the other hand, a hash function call is in-proc and very cheap, so I= =E2=80=99d > much rather keep what we have in TBPROTO-09 (perhaps removing the > ProtocolVersion from the concatenation, since ProtocolVersion is already > mixed in as part of the TLS session hash). > > > > Cheers, > > > > Andrei > > > > *From:* Andrei Popov > *Sent:* Tuesday, August 30, 2016 3:25 PM > *To:* 'Bill Cox' > *Cc:* Leif Johansson ; Tokbind WG > *Subject:* RE: [Unbearable] Dumb idea: add Ed25519 support? > > > > Unless there are objections, I=E2=80=99ll rev TBPROTO once more and elimi= nate one > hash operation. Concatenated TokenBindingType and TokenBindingKeyParamete= rs > will be mixed in as EKM context, and the resulting EKM will be signed. > > > > Cheers, > > > > Andrei > > > > *From:* Bill Cox [mailto:waywardgeek@google.com ] > *Sent:* Tuesday, August 30, 2016 3:21 PM > *To:* Andrei Popov > *Cc:* Leif Johansson ; Tokbind WG > *Subject:* Re: [Unbearable] Dumb idea: add Ed25519 support? > > > > On Tue, Aug 30, 2016 at 2:49 PM, Andrei Popov > wrote: > > The TokenBindingKeyParameters value is not necessarily in the TLS > handshake hash (e.g. for referred bindings). > > > > The ProtocolVersion value is only in the TLS handshake if we keep it in > the token_binding extension (which I hope we will). > > > > I don=E2=80=99t immediately see why this idea wouldn=E2=80=99t work, and = it eliminates one > hash operation, but I think we have to supply at least TokenBindingType a= nd > TokenBindingKeyParameters as the EKM context. > > > > I guess I would prefer this, just for the reduction of one hash operation= . > > > > Bill > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a114401007de08c053b62e3f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In which case I'd again suggest that the signature inp= ut be the concatenated items directly (no hash) and that hashing or not be = part of the signature scheme associated with each key parameters type.
=

On Wed, Aug= 31, 2016 at 11:18 AM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

Thinking more about this, generating EKMs multiple = times per connection would be a significant perf issue for us.

=C2=A0

EKM is a product of the TLS master secret, and on W= indows we keep the TLS master secrets isolated from the TLS client and serv= er applications.

So if we were to go with Bill=E2=80=99s idea, we wo= uld have to do extra IPC every time we generate or verify a binding.=

=C2=A0

On the other hand, a hash function call is in-proc = and very cheap, so I=E2=80=99d much rather keep what we have in TBPROTO-09 = (perhaps removing the ProtocolVersion from the concatenation, since ProtocolVersion is already mixed in as part of the TLS session hash)= .

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Andrei Popov
Sent: Tuesday, August 30, 2016 3:25 PM
To: 'Bill Cox' <waywardgeek@google.com>
Cc: Leif Johansson <leifj@sunet.se>; Tokbind WG <unbearable@ietf.org>
Subject: RE: [Unbearable] Dumb idea: add Ed25519 support?<= /u>

=C2=A0

Unless there are objections, I=E2=80=99ll rev TBPRO= TO once more and eliminate one hash operation. Concatenated TokenBindingTyp= e and TokenBindingKeyParameters will be mixed in as EKM context, and the resulting EKM will be signed.

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: Bill Cox [mailto:waywardgeek@google.co= m]
Sent: Tuesday, August 30, 2016 3:21 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Leif Johansson <leifj@sunet.se>; Tokbind WG <unbearable@ietf.org>
Subject: Re: [Unbearable] Dumb idea: add Ed25519 support?<= /u>

=C2=A0

On Tue, Aug 30, 2016 at 2:49 PM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

The TokenBindingKeyParameters value is not necessar= ily in the TLS handshake hash (e.g. for referred bindings).

=C2=A0

The ProtocolVersion value is only in the TLS handsh= ake if we keep it in the token_binding extension (which I hope we will).

=C2=A0

I don=E2=80=99t immediately see why this idea would= n=E2=80=99t work, and it eliminates one hash operation, but I think we have= to supply at least TokenBindingType and TokenBindingKeyParameters as the EKM = context.

=C2=A0

I guess I would prefer this, just for the reduction = of one hash operation.

=C2=A0

Bill=C2=A0


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


--001a114401007de08c053b62e3f8-- From nobody Wed Aug 31 12:35:08 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 4BB0012D753 for ; Wed, 31 Aug 2016 12:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 ee423RXapWKo for ; Wed, 31 Aug 2016 12:35:05 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 991CF12D0BD for ; Wed, 31 Aug 2016 12:35:05 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id i32so106931377uai.2 for ; Wed, 31 Aug 2016 12:35:05 -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=/5A9JsbESINpkhTox4fN5cNN9BbDpsNK7w7S5EeQUiw=; b=Q1hwPwj7goJcHCxnp/ykLvxmchSyu6RWsAhZbEL2TEI4LcatGl4AdyWfvSLlQw3mPr eg/Q0keEv7ueKtmrUDG0JKotkA/NnaRxJ8qYe6ZPLCiMLshxIbHO4RyEW8CeoiX85ZpP N86hmFHhZVMI/teF5cADxDZfsW12jET4+6emVlbS3AMvpZs5Omg8iScWXD9sALBmEh69 wb7+JbWN99tg0symLHljduoK5j2iifKM9yqGDY3OLgAr7yINL1TXObbDT8gnq0nn/gnd xi7cbjxXH41wIiJnnmOH+c2/fcMPZZGiSLJi+wMCo8PLZbl4/QYZwos34FS+qYt6JwvN vHmQ== 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=/5A9JsbESINpkhTox4fN5cNN9BbDpsNK7w7S5EeQUiw=; b=U8bdjSqkrTkqGHfC7v3f6aGVz8sanioRcDEcJURqQ9H5jLKsQiDqQTvWi3hq0O6XWU k8U8UqfRe8vxI3M9zs5ph+fS8bFzXxrpPMJR6r0HATOhJREL2N80D+qVwWjIwGPN/QQ0 8lkGzDKvFnhW2hlFG6Q0K/t3lyCihH+BBIj2IbugzHMVZ3Hb5doidW9ZpzZnK1tpWwGv Fe/mjXaJdO60QVjYp9TbD540Pe/H64tEXfLb67H/KQzCVpS9/2GmfVb4YewFioeRYzy7 gLwKOOmFY+SsFwyMfDZe7aCSnUGp4X9s3rYSlPDMYC10+uoK8Jl4zY3H9ZxLkadpXsK1 BG7g== X-Gm-Message-State: AE9vXwNFisNj3Jkj6odRgHWh+ysYY+eZTCSO53qFA2j4UglyvnpU4GszF6yTpAPsahB/wRg9DjqIbPUXdMZwBmSw X-Received: by 10.176.5.132 with SMTP id e4mr6978485uae.34.1472672104531; Wed, 31 Aug 2016 12:35:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.97.2 with HTTP; Wed, 31 Aug 2016 12:35:03 -0700 (PDT) In-Reply-To: References: <96c11d53-03c0-bcc3-92e1-ea73ce4d6a57@sunet.se> From: Bill Cox Date: Wed, 31 Aug 2016 12:35:03 -0700 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=94eb2c04336aa9a08c053b633133 Archived-At: Cc: Andrei Popov , Tokbind WG , Leif Johansson Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? 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, 31 Aug 2016 19:35:07 -0000 --94eb2c04336aa9a08c053b633133 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell wrote: > In which case I'd again suggest that the signature input be the > concatenated items directly (no hash) and that hashing or not be part of > the signature scheme associated with each key parameters type. > Sounds good to me. It fits the standard APIs a bit better. IIUC, this result is the same either way, so this is really just a matter of how we describe it, right? According to the EKM spec (https://tools.ietf.org/html/rfc5705), a disambiguating label is required, and we're also supposed to register it so there are no name collisions. Is this something we need to worry about? For some reason, I thought we had already registered "Token Binding" as a unique EKM label. If so, we should probably pass the label to the EKM either in addition to, or instead of, hashing it in the final hash. Bill --94eb2c04336aa9a08c053b633133 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 31, 2016 at 12:12 PM, Brian Campbell <bcampbell@pingiden= tity.com> wrote:
In which case I'd again suggest that the si= gnature input be the concatenated items directly (no hash) and that hashing= or not be part of the signature scheme associated with each key parameters= type.=C2=A0

Sounds good to me.=C2=A0= It fits the standard APIs a bit better.=C2=A0 IIUC, this result is the sam= e either way, so this is really just a matter of how we describe it, right?=

According to the EKM spec (https://tools.ietf.org/html/rfc5705), a disam= biguating label is required, and we're also supposed to register it so = there are no name collisions.=C2=A0 Is this something we need to worry abou= t?=C2=A0 For some reason, I thought we had already registered "Token B= inding" as a unique EKM label.=C2=A0 If so, we should probably pass th= e label to the EKM either in addition to, or instead of, hashing it in the = final hash.

Bill=C2=A0
--94eb2c04336aa9a08c053b633133-- From nobody Wed Aug 31 13:04:11 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 2213C12D6B9 for ; Wed, 31 Aug 2016 13:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 VXvt3CZbTzMz for ; Wed, 31 Aug 2016 13:04:08 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 35E9A12B065 for ; Wed, 31 Aug 2016 13:04:08 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id l94so108522089ual.0 for ; Wed, 31 Aug 2016 13:04:07 -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=CBFRMj41r18HmpXjB++v1VoDJ+oo8UIAkuglFk9wfFo=; b=OoxIKXcL+XAmWL7UfmgkNNLkcQfut3Wbsa5Suy/QSDxdi2sDY85RflZR221dQH5vPm 4gaB6kPNIv5sEgsQTTplovrpEJpCRCOFG6pEfFLIMGn/CmlvnObVps8Gc4Cdjv2WTtdq qENUQUqhnK2W5nJyHqFknBtNS3oltzURCYc9+9y2aqr3g/i3aHTEmguhZHTK23YdpuAH yBCjSX7c1b1lV6kLQ94xKSwfQASlwCZx5SqjrzTI4x+0IG9v4nCWeRlF9DVlCpj0k9DH yfjtt3pvHj9dtPqB+diBQ644eqh5N2leGElwIYD0sLtPW1x7t1bFS66G7oeLVpRod0jZ ClKA== 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=CBFRMj41r18HmpXjB++v1VoDJ+oo8UIAkuglFk9wfFo=; b=gDz3qS1N4V8k/HYto/FvetwOTztMpFdvBnca8B8n6bxCNB+9ni0lsJw4rFyoOHZkKg fE6JYxY2mQh3LoqRLJFITaIxXNfz7Vgzr4xOEA5HUZjLKLlFOwv0om1aTlewDJGAplMt wbDXiDhVO5tIdC+nFpMj0QQQAhgBSO5ngbub8pj8wyQahH74rY8/DXWSLSqzD3tleU1f LuE7qkss0q5qAwguRyAz43kZRvuAAiXd7/F22EBJtQf5C127CQfpkmAm9QPyT1tcXsQ0 n0QaGbl1e3aXAYhs99kmXEhm48IUxr9UhS8oDj5rt7JxLIP1s4y7TAwTxOEMuv1VKR+w 8MHQ== X-Gm-Message-State: AE9vXwPk+uebrb1jp1sLwJGL0mVLoZynHHrSNoEvXoDp43ZH5qcH7B+d5q4QzkZ1LEilyqaVHBNYElAdUa/xv4eN X-Received: by 10.159.33.1 with SMTP id 1mr6786120uab.36.1472673846907; Wed, 31 Aug 2016 13:04:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.97.2 with HTTP; Wed, 31 Aug 2016 13:04:06 -0700 (PDT) In-Reply-To: References: From: Bill Cox Date: Wed, 31 Aug 2016 13:04:06 -0700 Message-ID: To: Dirk Balfanz Content-Type: multipart/alternative; boundary=94eb2c0b7746841f61053b63993a Archived-At: Cc: Andrei Popov , Tokbind WG Subject: Re: [Unbearable] Opaqueness of Token Binding ID 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, 31 Aug 2016 20:04:10 -0000 --94eb2c0b7746841f61053b63993a Content-Type: text/plain; charset=UTF-8 I prefer signing the version with the opaque TokenBindingID, though I think the application should be able to inspect the key parameters. This is easy with the API I currently have. All "encoded" key strings are actually serialized TokenBindingIDs (not base-64 encoded), and I have an API to extract the key type, which just returns *key. The application should be aware of the key type, I think, in case some key types are found to be insecure in the future. So, it should not be considered entirely opaque. Maybe some applications need to do further verification of these keys. I provide a TokenBindingID -> EVP_PKEY API for this. Bill On Wed, Aug 31, 2016 at 10:54 AM, Dirk Balfanz wrote: > Hi Andrei & the rest of the Unbearables, > > in the FIDO (well, W3C webauthn) discussion the question came up whether > Token Binding IDs should be treated as opaque blobs in other protocols. In > particular, FIDO assertions are (in part) over Token Binding IDs. > > I had originally spec'd this out as including a JWK representation of the > Token Binding key, as in: > > // The FIDO signature is over this: > { > "origin": "www.example.com", > "challenge": "129843adj03948", > "tokbind": { > "kty":"EC", > "crv":"P-256", > "x":"HzQwlfXX7Q4S5MtCRMzPO9tOyWjBqRl4tJ8", > "y":"XVguGFLIZx1fXg375hi4-7-BxhMljw42Ht4" > } > } > > The webauthn participants are pointing out that the latest Token Binding > spec says that other applications should use an opaque representation of > the Token Binding ID, as in: > > // The FIDO signature is over this: > { > "origin": "www.example.com", > "challenge": "129843adj03948", > "tokbind": "KJDSW34AAJSjasAKJsha-ISajj8sJSA..." > } > > where the tokbind value would be the base64-enccoding of the > TokenBindingID, as specified in ietf-tokbind-protocol. > > It seems to me that it is safer to explicitly surface the fact that the > Token Binding ID is a public key, and what kind of key it is, to other > applications, rather than asking them to string-compare two strings whose > semantics they don't understand. > > I can't come up with a particular attack, since the Token Binding ID - > just like the JWK - is an unambiguous representation of they key. > Furthermore, since it is a canonical serialization, string comparison > *should* be ok. > > It seems strange, however, that the application (in this case webauthn) > shouldn't be aware of the precise semantics of the tokbind value in this > dictionary. > > Any thoughts on this? > > Dirk. > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --94eb2c0b7746841f61053b63993a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I prefer signing the version with the opaque TokenBindingI= D, though I think the application should be able to inspect the key paramet= ers.=C2=A0 This is easy with the API I currently have.=C2=A0 All "enco= ded" key strings are actually serialized TokenBindingIDs (not base-64 = encoded), and I have an API to extract the key type, which just returns *ke= y.

The application should be aware of the key type, I th= ink, in case some key types are found to be insecure in the future.=C2=A0 S= o, it should not be considered entirely opaque.=C2=A0 Maybe some applicatio= ns need to do further verification of these keys.=C2=A0 I provide a TokenBi= ndingID -> EVP_PKEY API for this.

Bill

On Wed, Aug 31= , 2016 at 10:54 AM, Dirk Balfanz <balfanz@google.com> wrote= :
Hi Andrei & the re= st of the Unbearables,=C2=A0

in the FIDO (well, W3C weba= uthn) discussion the question came up whether Token Binding IDs should be t= reated as opaque blobs in other protocols. In particular, FIDO assertions a= re (in part) over Token Binding IDs.

I had origina= lly spec'd this out as including a JWK representation of the Token Bind= ing key, as in:

// The FI= DO signature is over this:
{
= =C2=A0 "origin": "www.example.com",
=C2=A0 "challenge": &qu= ot;129843adj03948",
=C2=A0 "tokbind":=C2=A0{
=C2=A0 = =C2=A0 "kty":"EC",
=C2=A0 =C2=A0 "crv":&q= uot;P-256",
=C2=A0 =C2=A0 "x":"HzQwlfXX7Q4S5MtC= RMzPO9tOyWjBqRl4tJ8",
=C2=A0 =C2=A0 "y":"XVguGF= LIZx1fXg375hi4-7-BxhMljw42Ht4"
=C2=A0 }
}
=
The webauthn participants are pointing out that the latest T= oken Binding spec says that other applications should use an opaque represe= ntation of the Token Binding ID, as in:

// The FIDO signature is over this:
{
=C2=A0 "origin": "www.example.com",
=C2=A0= "challenge": "129843adj03948",
=C2=A0 "tokbind= ": "KJDSW34AAJSjasAKJsha-ISajj8sJSA..."
}

where the tokbind value would be the base64-enc= coding of the TokenBindingID, as specified in=C2=A0ietf-tokbind-protocol.= =C2=A0

It seems to me that it is safer to explicit= ly surface the fact that the Token Binding ID is a public key, and what kin= d of key it is, to other applications, rather than asking them to string-co= mpare two strings whose semantics they don't understand.=C2=A0

I can't come up with a particular attack, since the To= ken Binding ID - just like the JWK - is an unambiguous representation of th= ey key. Furthermore, since it is a canonical serialization, string comparis= on *should* be ok.

It seems strange, however, that= the application (in this case webauthn) shouldn't be aware of the prec= ise semantics of the tokbind value in this dictionary.=C2=A0

=
Any thoughts on this?

Dirk.
_______________________________________________
Unbearable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listinfo/unbearabl= e


--94eb2c0b7746841f61053b63993a-- From nobody Wed Aug 31 13:11:19 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 EB66D12D76F for ; Wed, 31 Aug 2016 13:11:17 -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 bB4I26tRUQj1 for ; Wed, 31 Aug 2016 13:11:16 -0700 (PDT) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 DBE6F12D770 for ; Wed, 31 Aug 2016 13:11:15 -0700 (PDT) Received: by mail-it0-x235.google.com with SMTP id e124so65047363ith.0 for ; Wed, 31 Aug 2016 13:11:15 -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=eTdP/zLVYr/w212M8oPU1535XEyNd9qdye7viatpC3c=; b=gjfeSXJRokT5S6uL/tMN1sYGgP1PPmf0aEcelE1AVgliKkh4jNzN8b2/Wsfsv1/vD6 fV7KfyoiNXHIJtgGUk8FI+Uc/yRAwTUdjeRHigCXyDgBASTtaaCNe9hUlgJMBQTWeQvk Qe1ud9J+5g93/lXQ1RJxCIWBNVGKyQMvxZeC8= 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=eTdP/zLVYr/w212M8oPU1535XEyNd9qdye7viatpC3c=; b=AuVLNMiT6gZWOJANAuAyKw1v67OmmVDaRM5dTaU62GKSAcFPI5oeieD9xSTahYGGhT ZczTancIrb0mgmfOMKQ7q7vtesUb4334004TOG14SUX25vtOFuncNqyYgSCy12rsQNOd /ZyYn0WFNpQvCqxH3QUuLtc6rYwJsLt/0/ShxfI1FyjN+fxjUEjEd2EgzzR76Y0aU1ES BIspvUUoDEYvrbInbM3JojH/Tc3W1+J4R+nLty8ZWZwnTwuatdfyEe6E5ZM2OlnqFtEn RJc8Aja4+nTIwbE38LdQkQ310s751aYcEfcFWoR327X63See15Sh9aoOuWKRlzQ4qjef Avfg== X-Gm-Message-State: AE9vXwN2diirLUtbeM85r7Natq5SRB/7d0r5C0HfJbtKtuFot36ANeOB2K2bWg/UacXlBfdIWiG03tq3tpmjbDq6 X-Received: by 10.36.91.213 with SMTP id g204mr16356233itb.42.1472674275083; Wed, 31 Aug 2016 13:11:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.114.20 with HTTP; Wed, 31 Aug 2016 13:10:44 -0700 (PDT) In-Reply-To: References: <96c11d53-03c0-bcc3-92e1-ea73ce4d6a57@sunet.se> From: Brian Campbell Date: Wed, 31 Aug 2016 14:10:44 -0600 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a11440100098ee4053b63b3ba Archived-At: Cc: Andrei Popov , Tokbind WG , Leif Johansson Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? 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, 31 Aug 2016 20:11:18 -0000 --001a11440100098ee4053b63b3ba Content-Type: text/plain; charset=UTF-8 On Wed, Aug 31, 2016 at 1:35 PM, Bill Cox wrote: > On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > >> In which case I'd again suggest that the signature input be the >> concatenated items directly (no hash) and that hashing or not be part of >> the signature scheme associated with each key parameters type. >> > > Sounds good to me. It fits the standard APIs a bit better. IIUC, this > result is the same either way, so this is really just a matter of how we > describe it, right? > After playing around with some APIs yesterday, I don't think that the result is actually the same. At least as far as the actual bytes of the signature. Conceptually the idea is the same though, AFAIK, and moving the hash definition to the signature scheme associated with each key parameters type removes a hardwired dependency on SHA256 and also eliminates a round of hashing for the RSA key parameters types. > According to the EKM spec (https://tools.ietf.org/html/rfc5705), a > disambiguating label is required, and we're also supposed to register it so > there are no name collisions. Is this something we need to worry about? > I think that's already (or will be) covered with the registration request for "EXPORTER-Token-Binding" in https://tools.ietf.org/html/dr aft-ietf-tokbind-protocol-09#section-6.4 > For some reason, I thought we had already registered "Token Binding" as a > unique EKM label. If so, we should probably pass the label to the EKM > either in addition to, or instead of, hashing it in the final hash. > I may have confused things by using the term label for the ASCII string "Token Binding" that's part of the concatenation of things. It's not a label in the RFC 5705 sense but more of a disambiguater that is tacked onto the content that is singed. Andrei can perhaps explain it's purpose better. But just thinking about that makes me wonder if it's necessary. ""EXPORTER-Token-Binding" is hashed into the EKM which is then under the signature. Is another "Token Binding" string under the signature needed to prevent cross protocol attacks? Doesn't the EKM input label already do that? --001a11440100098ee4053b63b3ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Aug 31, 2016 at 1:35 PM, Bill Cox <waywardgeek@google.com> wrote:
<= div dir=3D"ltr">
On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell <bcampbell@ping= identity.com> wrote:
In which case I'd again suggest that the = signature input be the concatenated items directly (no hash) and that hashi= ng or not be part of the signature scheme associated with each key paramete= rs type.=C2=A0

Sounds good to = me.=C2=A0 It fits the standard APIs a bit better.=C2=A0 IIUC, this result i= s the same either way, so this is really just a matter of how we describe i= t, right?

=C2=A0
After playing around with some APIs yesterday, = I don't think that the result is actually the same. At least as far as = the actual bytes of the signature. Conceptually the idea is the same though= , AFAIK, and moving the hash definition to the signature scheme associated with each key parameters = type removes a hardwired dependency on SHA256 and also eliminates a = round of hashing for the RSA key parameters types.

=C2=A0
= According to the EKM spec (https://tools.ietf.org/html/rfc5705), a disambig= uating label is required, and we're also supposed to register it so the= re are no name collisions.=C2=A0 Is this something we need to worry about?= =C2=A0

I think that's already (or will be) covered w= ith the registration request for "EXPORTER-Token-Binding" in https://tools.ietf.org/html/draft-ietf-tokbind-p= rotocol-09#section-6.4

=C2=A0
For some reason, I thought we= had already registered "Token Binding" as a unique EKM label.=C2= =A0 If so, we should probably pass the label to the EKM either in addition = to, or instead of, hashing it in the final hash.

I may have confused= things by using the term label for the ASCII string "Token Binding&qu= ot; that's part of the concatenation of things. It's not a label in= the RFC 5705 sense but more of a disambiguater that is tacked onto the con= tent that is singed. Andrei can perhaps explain it's purpose better.
But just think= ing about that makes me wonder if it's necessary. ""EXPORTER-= Token-Binding" is hashed into the EKM which is then under the signatur= e. Is another "Token Binding" string under the signature needed t= o prevent cross protocol attacks? Doesn't the EKM input label already d= o that?



--001a11440100098ee4053b63b3ba-- From nobody Wed Aug 31 13:11: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 3B8FA12D76F for ; Wed, 31 Aug 2016 13:11:19 -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 ORNAchiXlBbx for ; Wed, 31 Aug 2016 13:11:15 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0130.outbound.protection.outlook.com [104.47.37.130]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E78B12D763 for ; Wed, 31 Aug 2016 13:11:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+McNQVp5d4XZrcepkTo2Ew8kuzV47qAClgke06i0UG4=; b=myB8BJ6Pg5yf9LCJnXF/ianTU0eu7y/HsEoRbvObeId4l6gMkVrGKWRtbKakCFdir/24MZTfLDbiTLi4y+5gh5k9oLLjsLNBkQk7EKwyNHA6T/vrjPraMCUB7C7pXiLBuMtdDY53D37S0BErYntCRHyi47ot+jWLVJLAJGVs/kw= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0844.namprd03.prod.outlook.com (10.160.163.150) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Wed, 31 Aug 2016 20:11:13 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Wed, 31 Aug 2016 20:11:14 +0000 From: Andrei Popov To: Bill Cox , Brian Campbell Thread-Topic: [Unbearable] Dumb idea: add Ed25519 support? Thread-Index: AQHSAv7vhTLhCxb7AU+usuWCAoCwYKBiAkGAgAACPQCAAAFN0IAAAbUAgAAAb1CAAAuhAIAAABjggAE6+bCAACKsAIAABj+AgAAJM0A= Date: Wed, 31 Aug 2016 20:11:13 +0000 Message-ID: References: <96c11d53-03c0-bcc3-92e1-ea73ce4d6a57@sunet.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [50.46.229.189] x-ms-office365-filtering-correlation-id: cbba0a89-75fd-42e3-019a-08d3d1daf587 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 6:vcTcBJLmjByq+KYHZwKsq8g9uEuFT+htQQJwO4Sx5fWOqYcyZyF7KzjpXEKEfdmZdDBvenKWd4M2/uYG9S2GCRX1w56PeqwA9I32T32pI1lmZ2xwXn3IcGjyDysqfQQWEPzusvLu9BQ14w82deqUoXI1IAPxX6t6r3FblhcsXEmH/2IJbo3lzAy1PuwQzl23gnwqEFcWOJmnzpJWkNo0noVh7K6UBPxRYqgF/6E+ws1HoDVS3rQK9gaPrxBwip6eHvlAwBfah2laRBNpVt8AlVx94ZTnGbAs9Eg5jfoDIef53aGRE49+nKBvSXNSeAK0t/YlsrusphdT3XLwAEp1xA==; 5:0fb9y6Yo4lmdmOlYB5SHTnctaDjBzAcQeQ8vgoVcvej4aXmT7NoGu4yt4QTaV1URcHzWLLSIh9DLqqO91wha4sukDf7hR5GvdpvZ6W9DzhaTmw0DW9GWuJCuK1afzHu6VtuW6gqn+ftohUfjrcF3hQ==; 24:QuROQypegIYsk1/zT+cu5+IZm5ZfTt9BE8wqlhm7h3ieUqZHMpKw5QGHFb8Q0z4YbbRwyIDKZTyFIFvmOjN66uWEj53o8xqeO7QSAE6vbpw=; 7:zdzG5L88M+BN+nEmEfrcxhmPzQ26jUa6owz25XQGEUMCrUqUKuCzapa54lRPjCiOyXYrQ+wGZH4Z/0yj73IXjJ+Sqg4OZatSeVCHEfwIfn6sVtXd/aSqxf30h9+GZ3b5dvvzhWbJLQkdt5U+LpnUN8hqFMEDfM0LZN1GAFOc0LheI8a7IViFMear78YbtdC+JEvbdMZevhLfJw/wViphkguMxIMgZX3GjFmrmC4YNUgk7LQ6lgrof0J3/MsMfHk9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0844; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(24454002)(189002)(377454003)(122556002)(99286002)(7696003)(4326007)(3660700001)(74316002)(7846002)(50986999)(106116001)(97736004)(105586002)(5001770100001)(5002640100001)(92566002)(7736002)(76176999)(68736007)(7906003)(93886004)(54356999)(19617315012)(77096005)(66066001)(81166006)(19580405001)(8676002)(19625215002)(5660300001)(2906002)(101416001)(10090500001)(189998001)(15975445007)(19300405004)(81156014)(76576001)(86362001)(106356001)(9686002)(3280700002)(19609705001)(8936002)(2950100001)(2900100001)(5005710100001)(10290500002)(6116002)(86612001)(8990500004)(102836003)(19580395003)(10400500002)(790700001)(87936001)(586003)(3846002)(16236675004)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB08424184FEB2CB585E38A59C8CE30CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 20:11:13.9581 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0844 Archived-At: Cc: Tokbind WG , Leif Johansson Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? 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, 31 Aug 2016 20:11:19 -0000 --_000_CY1PR0301MB08424184FEB2CB585E38A59C8CE30CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2XigJlyZSBhbHJlYWR5IHJlZ2lzdGVyaW5nIGFuZCBwYXNzaW5nIGEgbGFiZWwgdG8gRUtNOg0K 4oCcICAgVGhlIEVLTSBpcyBvYnRhaW5lZCB1c2luZyB0aGUgS2V5aW5nIE1hdGVyaWFsIEV4cG9y dGVycyBmb3IgVExTDQogICBkZWZpbmVkIGluIFtSRkM1NzA1XSwgYnkgc3VwcGx5aW5nIHRoZSBm b2xsb3dpbmcgaW5wdXQgdmFsdWVzOg0KDQogICBvICBMYWJlbDogVGhlIEFTQ0lJIHN0cmluZyAi RVhQT1JURVItVG9rZW4tQmluZGluZyIgd2l0aCBubw0KICAgICAgdGVybWluYXRpbmcgTlVMLuKA nQ0KDQrigJxUaGlzIGRvY3VtZW50IGFkZHMgYSByZWdpc3RyYXRpb24gZm9yIHRoZSAiRVhQT1JU RVItVG9rZW4tQmluZGluZyINCiAgIHZhbHVlIGluIHRoZSBUTFMgRXhwb3J0ZXIgTGFiZWwgUmVn aXN0cnkgdG8gY29ycmVzcG9uZCB0byB0aGlzDQogICBzcGVjaWZpY2F0aW9uLuKAnQ0KDQpDaGVl cnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBCaWxsIENveCBbbWFpbHRvOndheXdhcmRnZWVrQGdvb2ds ZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAzMSwgMjAxNiAxMjozNSBQTQ0KVG86IEJy aWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4NCkNjOiBBbmRyZWkgUG9w b3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPjsgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBp ZXRmLm9yZz47IExlaWYgSm9oYW5zc29uIDxsZWlmakBzdW5ldC5zZT4NClN1YmplY3Q6IFJlOiBb VW5iZWFyYWJsZV0gRHVtYiBpZGVhOiBhZGQgRWQyNTUxOSBzdXBwb3J0Pw0KDQpPbiBXZWQsIEF1 ZyAzMSwgMjAxNiBhdCAxMjoxMiBQTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KSW4g d2hpY2ggY2FzZSBJJ2QgYWdhaW4gc3VnZ2VzdCB0aGF0IHRoZSBzaWduYXR1cmUgaW5wdXQgYmUg dGhlIGNvbmNhdGVuYXRlZCBpdGVtcyBkaXJlY3RseSAobm8gaGFzaCkgYW5kIHRoYXQgaGFzaGlu ZyBvciBub3QgYmUgcGFydCBvZiB0aGUgc2lnbmF0dXJlIHNjaGVtZSBhc3NvY2lhdGVkIHdpdGgg ZWFjaCBrZXkgcGFyYW1ldGVycyB0eXBlLg0KDQpTb3VuZHMgZ29vZCB0byBtZS4gIEl0IGZpdHMg dGhlIHN0YW5kYXJkIEFQSXMgYSBiaXQgYmV0dGVyLiAgSUlVQywgdGhpcyByZXN1bHQgaXMgdGhl IHNhbWUgZWl0aGVyIHdheSwgc28gdGhpcyBpcyByZWFsbHkganVzdCBhIG1hdHRlciBvZiBob3cg d2UgZGVzY3JpYmUgaXQsIHJpZ2h0Pw0KDQpBY2NvcmRpbmcgdG8gdGhlIEVLTSBzcGVjIChodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTcwNSksIGEgZGlzYW1iaWd1YXRpbmcgbGFiZWwg aXMgcmVxdWlyZWQsIGFuZCB3ZSdyZSBhbHNvIHN1cHBvc2VkIHRvIHJlZ2lzdGVyIGl0IHNvIHRo ZXJlIGFyZSBubyBuYW1lIGNvbGxpc2lvbnMuICBJcyB0aGlzIHNvbWV0aGluZyB3ZSBuZWVkIHRv IHdvcnJ5IGFib3V0PyAgRm9yIHNvbWUgcmVhc29uLCBJIHRob3VnaHQgd2UgaGFkIGFscmVhZHkg cmVnaXN0ZXJlZCAiVG9rZW4gQmluZGluZyIgYXMgYSB1bmlxdWUgRUtNIGxhYmVsLiAgSWYgc28s IHdlIHNob3VsZCBwcm9iYWJseSBwYXNzIHRoZSBsYWJlbCB0byB0aGUgRUtNIGVpdGhlciBpbiBh ZGRpdGlvbiB0bywgb3IgaW5zdGVhZCBvZiwgaGFzaGluZyBpdCBpbiB0aGUgZmluYWwgaGFzaC4N Cg0KQmlsbA0K --_000_CY1PR0301MB08424184FEB2CB585E38A59C8CE30CY1PR0301MB0842_ 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 bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjQ2Nzc0MzkzNzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6LTE2ODA5NTcxODQgLTc1ODcyODc0MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjUuOHB0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7DQoJbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjYxLjhwdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJbWFyZ2luLWxlZnQ6OTcuOHB0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjEz My44cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE2OS44cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1h cmdpbi1sZWZ0OjIwNS44cHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6MjQxLjhwdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJbWFyZ2luLWxlZnQ6Mjc3LjhwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6 MzEzLjhwdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPldl4oCZcmUgYWxyZWFkeSByZWdpc3RlcmluZyBhbmQgcGFzc2luZyBhIGxhYmVs IHRvIEVLTTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPuKAnCZuYnNwOyZuYnNwOyBUaGUgRUtNIGlzIG9idGFpbmVkIHVzaW5nIHRo ZSBLZXlpbmcgTWF0ZXJpYWwgRXhwb3J0ZXJzIGZvciBUTFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyBkZWZp bmVkIGluIFtSRkM1NzA1XSwgYnkgc3VwcGx5aW5nIHRoZSBmb2xsb3dpbmcgaW5wdXQgdmFsdWVz OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsgbyZuYnNwOyBMYWJlbDogVGhlIEFTQ0lJIHN0 cmluZyAmcXVvdDtFWFBPUlRFUi1Ub2tlbi1CaW5kaW5nJnF1b3Q7IHdpdGggbm88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0ZXJtaW5hdGluZyBOVUwu4oCdPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFp bEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+4oCcVGhpcyBkb2N1bWVudCBhZGRzIGEgcmVn aXN0cmF0aW9uIGZvciB0aGUgJnF1b3Q7RVhQT1JURVItVG9rZW4tQmluZGluZyZxdW90OzxvOnA+ PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZuYnNwOyZuYnNwOyB2YWx1ZSBpbiB0aGUgVExTIEV4cG9ydGVyIExhYmVsIFJlZ2lzdHJ5 IHRvIGNvcnJlc3BvbmQgdG8gdGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7IHNwZWNpZmljYXRpb24u4oCd PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kcmVpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBCaWxsIENveCBbbWFpbHRv OndheXdhcmRnZWVrQGdvb2dsZS5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBB dWd1c3QgMzEsIDIwMTYgMTI6MzUgUE08YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIENhbXBiZWxsICZs dDtiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEFuZHJlaSBQ b3BvdiAmbHQ7QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20mZ3Q7OyBUb2tiaW5kIFdHICZsdDt1 bmJlYXJhYmxlQGlldGYub3JnJmd0OzsgTGVpZiBKb2hhbnNzb24gJmx0O2xlaWZqQHN1bmV0LnNl Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIER1bWIgaWRlYTogYWRk IEVkMjU1MTkgc3VwcG9ydD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwg QXVnIDMxLCAyMDE2IGF0IDEyOjEyIFBNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gd2hpY2ggY2FzZSBJJ2QgYWdhaW4g c3VnZ2VzdCB0aGF0IHRoZSBzaWduYXR1cmUgaW5wdXQgYmUgdGhlIGNvbmNhdGVuYXRlZCBpdGVt cyBkaXJlY3RseSAobm8gaGFzaCkgYW5kIHRoYXQgaGFzaGluZyBvciBub3QgYmUgcGFydCBvZiB0 aGUgc2lnbmF0dXJlIHNjaGVtZSBhc3NvY2lhdGVkIHdpdGggZWFjaCBrZXkgcGFyYW1ldGVycyB0 eXBlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb3VuZHMgZ29vZCB0byBtZS4mbmJzcDsgSXQgZml0cyB0 aGUgc3RhbmRhcmQgQVBJcyBhIGJpdCBiZXR0ZXIuJm5ic3A7IElJVUMsIHRoaXMgcmVzdWx0IGlz IHRoZSBzYW1lIGVpdGhlciB3YXksIHNvIHRoaXMgaXMgcmVhbGx5IGp1c3QgYSBtYXR0ZXIgb2Yg aG93IHdlIGRlc2NyaWJlIGl0LCByaWdodD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWNjb3JkaW5nIHRvIHRoZSBFS00gc3BlYyAoPGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3MDUiPmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM1NzA1PC9hPiksIGEgZGlzYW1iaWd1YXRpbmcgbGFiZWwgaXMgcmVxdWly ZWQsIGFuZCB3ZSdyZSBhbHNvIHN1cHBvc2VkIHRvIHJlZ2lzdGVyIGl0IHNvIHRoZXJlIGFyZSBu byBuYW1lIGNvbGxpc2lvbnMuJm5ic3A7IElzIHRoaXMgc29tZXRoaW5nDQogd2UgbmVlZCB0byB3 b3JyeSBhYm91dD8mbmJzcDsgRm9yIHNvbWUgcmVhc29uLCBJIHRob3VnaHQgd2UgaGFkIGFscmVh ZHkgcmVnaXN0ZXJlZCAmcXVvdDtUb2tlbiBCaW5kaW5nJnF1b3Q7IGFzIGEgdW5pcXVlIEVLTSBs YWJlbC4mbmJzcDsgSWYgc28sIHdlIHNob3VsZCBwcm9iYWJseSBwYXNzIHRoZSBsYWJlbCB0byB0 aGUgRUtNIGVpdGhlciBpbiBhZGRpdGlvbiB0bywgb3IgaW5zdGVhZCBvZiwgaGFzaGluZyBpdCBp biB0aGUgZmluYWwgaGFzaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5CaWxsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_CY1PR0301MB08424184FEB2CB585E38A59C8CE30CY1PR0301MB0842_-- From nobody Wed Aug 31 14:01: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 8DC9012D786 for ; Wed, 31 Aug 2016 14:01:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 VC7Mey8A8VB5 for ; Wed, 31 Aug 2016 14:01:15 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 113A212D752 for ; Wed, 31 Aug 2016 14:01:15 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id i32so110915495uai.2 for ; Wed, 31 Aug 2016 14:01:15 -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=Oo3oF2nUUryXZ+7u8x/+d4PViWi4fG9d5tdZJZrg+Wk=; b=OCKLBtPBL082brnmAu/qCC1d6/DWarKFo3V4fhACVqq2YEOrVIbuppEZzpU4THGy7i brQGLSy9n6U7HcqQFEu7NOxS0I8sd4h0+ACXhi7nVuVRlONiwfDYBzQlw2A2TEvM/+g3 mcyJGDpy6l4RQvrN3Tpf+C2PdrIMIzYOR3ylDbN3TIvXKvVU8yhh3nmbuMCzgZj38Hta QJz+K73BFg4YSOXHSgg72vqpYTR5IJQkiVAsYFrcCH+mHw41p2oQgYYF2yz2pOs9GP3R UcxR35auZycVPFGqba+Zp6B8hnRDcmAPXfFK34yGi3oIW/7qwRawPW6sHbtauTBJKPSf 7vBQ== 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=Oo3oF2nUUryXZ+7u8x/+d4PViWi4fG9d5tdZJZrg+Wk=; b=gVv7soHCH8XtC8M/Hrfg5Bp451ni9fhKUGCpi9J7JUCZpUE0scu8gFX1pKf+6vr4Co eCfQMIRCt2WB/YPeDPQRlgGxAttczgLRcZ7gC42x+ucc4hJ21WEGfpZZPFdSK/ZEuO9U O6pD6zSBJPWzmPOmaTQ+3ZKJo90fATfHVbvVThtnj6+9r6ZeL4JTdxbFgbBhZ/094rKd sqfniiyqJ8uwCAF9kxbe3YC2ly6ARGcgsRWvjltXMN+qEIFaX2Q6g+dclaEcEX/jK+C6 ZxScRZj9RyNW/f7wRATQ1t+jD/YZ/p8h15ox3dpV7KplHGMvklrzgc3kgMxLUUtwcg8+ +/lw== X-Gm-Message-State: AE9vXwMdTV3toIMag/IvGGcbsQdISI7rJCtMhFSh2jPe/u4ZHtIoOK2z81/0UzJSm0PrHNMJ+L+wYwf2V+YpzKX/ X-Received: by 10.176.3.41 with SMTP id 38mr7116825uat.113.1472677273567; Wed, 31 Aug 2016 14:01:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.97.2 with HTTP; Wed, 31 Aug 2016 14:01:12 -0700 (PDT) In-Reply-To: References: <96c11d53-03c0-bcc3-92e1-ea73ce4d6a57@sunet.se> From: Bill Cox Date: Wed, 31 Aug 2016 14:01:12 -0700 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=001a113d049ac3a654053b646574 Archived-At: Cc: Andrei Popov , Tokbind WG , Leif Johansson Subject: Re: [Unbearable] Dumb idea: add Ed25519 support? 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, 31 Aug 2016 21:01:17 -0000 --001a113d049ac3a654053b646574 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 31, 2016 at 1:10 PM, Brian Campbell wrote: > > On Wed, Aug 31, 2016 at 1:35 PM, Bill Cox wrote: > >> On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >>> In which case I'd again suggest that the signature input be the >>> concatenated items directly (no hash) and that hashing or not be part of >>> the signature scheme associated with each key parameters type. >>> >> >> Sounds good to me. It fits the standard APIs a bit better. IIUC, this >> result is the same either way, so this is really just a matter of how we >> describe it, right? >> > > > After playing around with some APIs yesterday, I don't think that the > result is actually the same. At least as far as the actual bytes of the > signature. Conceptually the idea is the same though, AFAIK, and moving the > hash definition to the signature scheme associated with each key > parameters type removes a hardwired dependency on SHA256 and also eliminates > a round of hashing for the RSA key parameters types. > The OpenSSL signing APIs are finicky. They really want to do a digest, and you have to know how to call them just right to sign the digest, rather than the hash of the digest. However, at one point, I was able to verify that both ways give the same result. I actually use the normal APIs now that do the SHA256 while signing. I do not think this requires a document change, other than perhaps some clarification. > According to the EKM spec (https://tools.ietf.org/html/rfc5705), a >> disambiguating label is required, and we're also supposed to register it so >> there are no name collisions. Is this something we need to worry about? >> > > I think that's already (or will be) covered with the registration request > for "EXPORTER-Token-Binding" in https://tools.ietf.org/html/dr > aft-ietf-tokbind-protocol-09#section-6.4 > OK, great. In that case, adding "Token Binding" is redundant, but since we use a 32-byte block hash anyway, I don't think it will make any difference ins speed, other than the cost of copying the data. > > >> For some reason, I thought we had already registered "Token Binding" as a >> unique EKM label. If so, we should probably pass the label to the EKM >> either in addition to, or instead of, hashing it in the final hash. >> > > I may have confused things by using the term label for the ASCII string > "Token Binding" that's part of the concatenation of things. It's not a > label in the RFC 5705 sense but more of a disambiguater that is tacked onto > the content that is singed. Andrei can perhaps explain it's purpose better. > > But just thinking about that makes me wonder if it's necessary. > ""EXPORTER-Token-Binding" is hashed into the EKM which is then under the > signature. Is another "Token Binding" string under the signature needed to > prevent cross protocol attacks? Doesn't the EKM input label already do > that? > Yes, it does, but so long as it does not cause the data to take up another 32-byte block, I'm OK with it. So, I'm OK with the -09 version. Bill > > --001a113d049ac3a654053b646574 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Aug 31, 2016 at 1:10 PM, Brian Campbell <bcampbell@pingiden= tity.com> wrote:

On Wed, Aug 31, 2016 at 1:35 PM, Bill Cox <waywardgeek@googl= e.com> wrote:
On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell = <bcampbe= ll@pingidentity.com> wrote:
In which case I'd again suggest th= at the signature input be the concatenated items directly (no hash) and tha= t hashing or not be part of the signature scheme associated with each key p= arameters type.=C2=A0

Sounds g= ood to me.=C2=A0 It fits the standard APIs a bit better.=C2=A0 IIUC, this r= esult is the same either way, so this is really just a matter of how we des= cribe it, right?

=C2=A0=
After playing around with some AP= Is yesterday, I don't think that the result is actually the same. At le= ast as far as the actual bytes of the signature. Conceptually the idea is t= he same though, AFAIK, and moving the hash definition to the signature scheme associated with each k= ey parameters type removes a hardwired dependency on SHA256 and also elimin= ates a round of hashing for the RSA key parameters types.=C2=A0
=C2=A0
The Open= SSL signing APIs are finicky.=C2=A0 They really want to do a digest, and yo= u have to know how to call them just right to sign the digest, rather than = the hash of the digest.=C2=A0 However, at one point, I was able to verify t= hat both ways give the same result.=C2=A0 I actually use the normal APIs no= w that do the SHA256 while signing.=C2=A0 I do not think this requires a do= cument change, other than perhaps some clarification.
=C2=A0
According to the EKM spec (https://tools.ietf.org/h= tml/rfc5705), a disambiguating label is required, and we're al= so supposed to register it so there are no name collisions.=C2=A0 Is this s= omething we need to worry about?=C2=A0

I think th= at's already (or will be) covered with the registration request for &qu= ot;EXPORTER-Token-Binding" in https://tools.= ietf.org/html/draft-ietf-tokbind-protocol-09#section-6.4=C2= =A0

OK, grea= t.=C2=A0 In that case, adding "Token Binding" is redundant, but s= ince we use a 32-byte block hash anyway, I don't think it will make any= difference ins speed, other than the cost of copying the data.=C2=A0
=
=
=C2=A0
For some reason, I thought we had alre= ady registered "Token Binding" as a unique EKM label.=C2=A0 If so= , we should probably pass the label to the EKM either in addition to, or in= stead of, hashing it in the final hash.

I may have confused t= hings by using the term label for the ASCII string "Token Binding"= ; that's part of the concatenation of things. It's not a label in t= he RFC 5705 sense but more of a disambiguater that is tacked onto the conte= nt that is singed. Andrei can perhaps explain it's purpose better.
=
But just thinkin= g about that makes me wonder if it's necessary. ""EXPORTER-To= ken-Binding" is hashed into the EKM which is then under the signature.= Is another "Token Binding" string under the signature needed to = prevent cross protocol attacks? Doesn't the EKM input label already do = that?

Yes, = it does, but so long as it does not cause the data to take up another 32-by= te block, I'm OK with it.

So, I'm OK with = the -09 version.

Bill=C2=A0
=C2=A0

--001a113d049ac3a654053b646574-- From nobody Wed Aug 31 14:21: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 DAC3F12D762 for ; Wed, 31 Aug 2016 14:21:01 -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 3toWqliia44t for ; Wed, 31 Aug 2016 14:20:59 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0132.outbound.protection.outlook.com [104.47.38.132]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF04312D08C for ; Wed, 31 Aug 2016 14:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WG0yaQnObCgk/H6Zmu6hG5fV3WnineysyVGElARBPW8=; b=L1nhgaW4S61+NlxPDBQUyoLzeCZ3iMm15pY/Hvx1QV1+S7FwH/MOtwfFcKkeQN3wqYIXjhsyjGLES/0aA+oC1p79dGMGuvAOI419AQltJ3Abce6Tor1ZCvn3gSZeH43fjYT/NPrx4jLwWBq3d7fvUgn/D2vilY6n1yYdnwf65qU= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0844.namprd03.prod.outlook.com (10.160.163.150) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Wed, 31 Aug 2016 21:20:55 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Wed, 31 Aug 2016 21:20:56 +0000 From: Andrei Popov To: Bill Cox , Brian Campbell Thread-Topic: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) Thread-Index: AdIDzYe/nNN4QigzR4G2nIa8+fQ4XA== Date: Wed, 31 Aug 2016 21:20:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 0b7b160c-d45e-4507-3722-08d3d1e4b229 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 6:v2FraStyRb5txENwEbEjbTsCMZpd2SPo6kO855I3kqx3MZNFE0t99LzpOuYJ3EJDb+dbY6rinavjvJaJkoiNoNxjzGzsm03Oh8X5hf6uukvWwLpPesIfjBbMKCGrA/sEray6oqr9sVxEja+qfGU5kqVFYr1q51TTagYwx6N23cES1vE/5VuvLEABpAVcvaSka981gt/hobx9YVz1TSoykFAULAIrI6oWNWYw2fYRHl8ajP1r35b3A70S32dntLYv+p7JpjbuFBVOO34rb6kupOBF+liolxNJ/YhJFm9oaIxD3BXdI+WvsMzUHVFsfhiUSF5z4zhPi8Xqi48rIBgdVA==; 5:qsTkSvWMYeATIqkW3ntHWpM36sF+9YftWkLZzSn0igJ3k8SYkW6TeJbw5KiMx00sU1+e1YP7481/JgzqsTVkD7ZBOn5s72SWofm3ofiWtyW+QCmGSm5QqwixFSR+HFHyKsuSKJogxpKnNtz2qqu19A==; 24:/mcJ1npM49O4+rhWqUB5ja16r2lkKsjDfh5Y7pa/tmF+6nNm2HN+ncb4nuNxe+xY6hD2I98sWFV5d0PuX5nYgXvMv6cuX6y7ZXKs4ANCz0U=; 7:Ms4B6Ka9v+CfagwN3Bj6NySOQH8Atl3SZ6McQjFVN0GHjNZUgOvLAK9loer/QH2ZvZupPoU+FT0chO9b51u0KKtwVwSjuMNRi3SUETqbLP6Az5nO2mhgrdUgY3zajxPa80pQLEWfO5yj5qt4MNFS1KCKOPDhwJJcFnZ0g5Tjz8jEU/itCtd/+IgNk5ROr2cPdPUmHhsPppEY43OqCIzh++C413v1A3vAoYwBV1xQ1LWgQfw0iAA9FJSreAi5lkeG x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0844; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(199003)(51444003)(52314003)(24454002)(9686002)(3280700002)(8936002)(19609705001)(86362001)(76576001)(106356001)(10400500002)(87936001)(19580395003)(33656002)(586003)(16236675004)(5005710100001)(2900100001)(102836003)(10290500002)(6116002)(86612001)(8990500004)(5002640100001)(7736002)(92566002)(54356999)(68736007)(7906003)(7696003)(3660700001)(4326007)(99286002)(122556002)(790700001)(50986999)(97736004)(105586002)(7846002)(74316002)(5001770100001)(101416001)(19625215002)(8676002)(2906002)(15975445007)(5660300001)(10090500001)(19300405004)(81156014)(189998001)(19617315012)(81166006)(19580405001)(77096005)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB084238130BACD497E791B7FA8CE30CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 21:20:55.8734 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0844 Archived-At: Cc: Tokbind WG , Leif Johansson Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) 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, 31 Aug 2016 21:21:02 -0000 --_000_CY1PR0301MB084238130BACD497E791B7FA8CE30CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG8gc3VtIHVwLCBhcmUgd2UgaW4gYWdyZWVtZW50IHRoYXQgdGhlIGNvbmNhdGVuYXRpb24gd2ls bCBvbmx5IGluY2x1ZGU6DQoNCg0KLSAgICAgICAgICBUb2tlbkJpbmRpbmdUeXBlIHZhbHVlIGNv bnRhaW5lZCBpbiB0aGUNCiAgICAgIFRva2VuQmluZGluZy50b2tlbmJpbmRpbmdfdHlwZSBmaWVs ZDsNCg0KLSAgICAgICAgICBUb2tlbkJpbmRpbmdLZXlQYXJhbWV0ZXJzIHZhbHVlIGNvbnRhaW5l ZCBpbiB0aGUNCiAgICAgIFRva2VuQmluZGluZ0lELmtleV9wYXJhbWV0ZXJzIGZpZWxkOw0KDQot ICAgICAgICAgIEV4cG9ydGVkIGtleWluZyBtYXRlcmlhbCAoRUtNKSB2YWx1ZSBvYnRhaW5lZCBm cm9tIHRoZSBjdXJyZW50IFRMUw0KICAgICAgY29ubmVjdGlvbi4NCuKApiBiZWNhdXNlIHRoZSBs YWJlbCBhbmQgdGhlIFByb3RvY29sVmVyc2lvbiBhcmUgcHJlc3VtYWJseSBhbHJlYWR5IGluIHRo ZSBFS00/DQoNCkZyb206IEJpbGwgQ294IFttYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbV0N ClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDMxLCAyMDE2IDI6MDEgUE0NClRvOiBCcmlhbiBDYW1w YmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+DQpDYzogQW5kcmVpIFBvcG92IDxBbmRy ZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT47IFRva2JpbmQgV0cgPHVuYmVhcmFibGVAaWV0Zi5vcmc+ OyBMZWlmIEpvaGFuc3NvbiA8bGVpZmpAc3VuZXQuc2U+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFi bGVdIER1bWIgaWRlYTogYWRkIEVkMjU1MTkgc3VwcG9ydD8NCg0KT24gV2VkLCBBdWcgMzEsIDIw MTYgYXQgMToxMCBQTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t PG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KDQpPbiBXZWQsIEF1 ZyAzMSwgMjAxNiBhdCAxOjM1IFBNLCBCaWxsIENveCA8d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTxt YWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KT24gV2VkLCBBdWcgMzEsIDIw MTYgYXQgMTI6MTIgUE0sIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3cm90ZToNCkluIHdoaWNoIGNh c2UgSSdkIGFnYWluIHN1Z2dlc3QgdGhhdCB0aGUgc2lnbmF0dXJlIGlucHV0IGJlIHRoZSBjb25j YXRlbmF0ZWQgaXRlbXMgZGlyZWN0bHkgKG5vIGhhc2gpIGFuZCB0aGF0IGhhc2hpbmcgb3Igbm90 IGJlIHBhcnQgb2YgdGhlIHNpZ25hdHVyZSBzY2hlbWUgYXNzb2NpYXRlZCB3aXRoIGVhY2gga2V5 IHBhcmFtZXRlcnMgdHlwZS4NCg0KU291bmRzIGdvb2QgdG8gbWUuICBJdCBmaXRzIHRoZSBzdGFu ZGFyZCBBUElzIGEgYml0IGJldHRlci4gIElJVUMsIHRoaXMgcmVzdWx0IGlzIHRoZSBzYW1lIGVp dGhlciB3YXksIHNvIHRoaXMgaXMgcmVhbGx5IGp1c3QgYSBtYXR0ZXIgb2YgaG93IHdlIGRlc2Ny aWJlIGl0LCByaWdodD8NCg0KDQpBZnRlciBwbGF5aW5nIGFyb3VuZCB3aXRoIHNvbWUgQVBJcyB5 ZXN0ZXJkYXksIEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGUgcmVzdWx0IGlzIGFjdHVhbGx5IHRoZSBz YW1lLiBBdCBsZWFzdCBhcyBmYXIgYXMgdGhlIGFjdHVhbCBieXRlcyBvZiB0aGUgc2lnbmF0dXJl LiBDb25jZXB0dWFsbHkgdGhlIGlkZWEgaXMgdGhlIHNhbWUgdGhvdWdoLCBBRkFJSywgYW5kIG1v dmluZyB0aGUgaGFzaCBkZWZpbml0aW9uIHRvIHRoZSBzaWduYXR1cmUgc2NoZW1lIGFzc29jaWF0 ZWQgd2l0aCBlYWNoIGtleSBwYXJhbWV0ZXJzIHR5cGUgcmVtb3ZlcyBhIGhhcmR3aXJlZCBkZXBl bmRlbmN5IG9uIFNIQTI1NiBhbmQgYWxzbyBlbGltaW5hdGVzIGEgcm91bmQgb2YgaGFzaGluZyBm b3IgdGhlIFJTQSBrZXkgcGFyYW1ldGVycyB0eXBlcy4NCg0KVGhlIE9wZW5TU0wgc2lnbmluZyBB UElzIGFyZSBmaW5pY2t5LiAgVGhleSByZWFsbHkgd2FudCB0byBkbyBhIGRpZ2VzdCwgYW5kIHlv dSBoYXZlIHRvIGtub3cgaG93IHRvIGNhbGwgdGhlbSBqdXN0IHJpZ2h0IHRvIHNpZ24gdGhlIGRp Z2VzdCwgcmF0aGVyIHRoYW4gdGhlIGhhc2ggb2YgdGhlIGRpZ2VzdC4gIEhvd2V2ZXIsIGF0IG9u ZSBwb2ludCwgSSB3YXMgYWJsZSB0byB2ZXJpZnkgdGhhdCBib3RoIHdheXMgZ2l2ZSB0aGUgc2Ft ZSByZXN1bHQuICBJIGFjdHVhbGx5IHVzZSB0aGUgbm9ybWFsIEFQSXMgbm93IHRoYXQgZG8gdGhl IFNIQTI1NiB3aGlsZSBzaWduaW5nLiAgSSBkbyBub3QgdGhpbmsgdGhpcyByZXF1aXJlcyBhIGRv Y3VtZW50IGNoYW5nZSwgb3RoZXIgdGhhbiBwZXJoYXBzIHNvbWUgY2xhcmlmaWNhdGlvbi4NCg0K QWNjb3JkaW5nIHRvIHRoZSBFS00gc3BlYyAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzU3MDUpLCBhIGRpc2FtYmlndWF0aW5nIGxhYmVsIGlzIHJlcXVpcmVkLCBhbmQgd2UncmUgYWxz byBzdXBwb3NlZCB0byByZWdpc3RlciBpdCBzbyB0aGVyZSBhcmUgbm8gbmFtZSBjb2xsaXNpb25z LiAgSXMgdGhpcyBzb21ldGhpbmcgd2UgbmVlZCB0byB3b3JyeSBhYm91dD8NCg0KSSB0aGluayB0 aGF0J3MgYWxyZWFkeSAob3Igd2lsbCBiZSkgY292ZXJlZCB3aXRoIHRoZSByZWdpc3RyYXRpb24g cmVxdWVzdCBmb3IgIkVYUE9SVEVSLVRva2VuLUJpbmRpbmciIGluIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQtcHJvdG9jb2wtMDkjc2VjdGlvbi02LjQNCg0K T0ssIGdyZWF0LiAgSW4gdGhhdCBjYXNlLCBhZGRpbmcgIlRva2VuIEJpbmRpbmciIGlzIHJlZHVu ZGFudCwgYnV0IHNpbmNlIHdlIHVzZSBhIDMyLWJ5dGUgYmxvY2sgaGFzaCBhbnl3YXksIEkgZG9u J3QgdGhpbmsgaXQgd2lsbCBtYWtlIGFueSBkaWZmZXJlbmNlIGlucyBzcGVlZCwgb3RoZXIgdGhh biB0aGUgY29zdCBvZiBjb3B5aW5nIHRoZSBkYXRhLg0KDQpGb3Igc29tZSByZWFzb24sIEkgdGhv dWdodCB3ZSBoYWQgYWxyZWFkeSByZWdpc3RlcmVkICJUb2tlbiBCaW5kaW5nIiBhcyBhIHVuaXF1 ZSBFS00gbGFiZWwuICBJZiBzbywgd2Ugc2hvdWxkIHByb2JhYmx5IHBhc3MgdGhlIGxhYmVsIHRv IHRoZSBFS00gZWl0aGVyIGluIGFkZGl0aW9uIHRvLCBvciBpbnN0ZWFkIG9mLCBoYXNoaW5nIGl0 IGluIHRoZSBmaW5hbCBoYXNoLg0KDQpJIG1heSBoYXZlIGNvbmZ1c2VkIHRoaW5ncyBieSB1c2lu ZyB0aGUgdGVybSBsYWJlbCBmb3IgdGhlIEFTQ0lJIHN0cmluZyAiVG9rZW4gQmluZGluZyIgdGhh dCdzIHBhcnQgb2YgdGhlIGNvbmNhdGVuYXRpb24gb2YgdGhpbmdzLiBJdCdzIG5vdCBhIGxhYmVs IGluIHRoZSBSRkMgNTcwNSBzZW5zZSBidXQgbW9yZSBvZiBhIGRpc2FtYmlndWF0ZXIgdGhhdCBp cyB0YWNrZWQgb250byB0aGUgY29udGVudCB0aGF0IGlzIHNpbmdlZC4gQW5kcmVpIGNhbiBwZXJo YXBzIGV4cGxhaW4gaXQncyBwdXJwb3NlIGJldHRlci4NCkJ1dCBqdXN0IHRoaW5raW5nIGFib3V0 IHRoYXQgbWFrZXMgbWUgd29uZGVyIGlmIGl0J3MgbmVjZXNzYXJ5LiAiIkVYUE9SVEVSLVRva2Vu LUJpbmRpbmciIGlzIGhhc2hlZCBpbnRvIHRoZSBFS00gd2hpY2ggaXMgdGhlbiB1bmRlciB0aGUg c2lnbmF0dXJlLiBJcyBhbm90aGVyICJUb2tlbiBCaW5kaW5nIiBzdHJpbmcgdW5kZXIgdGhlIHNp Z25hdHVyZSBuZWVkZWQgdG8gcHJldmVudCBjcm9zcyBwcm90b2NvbCBhdHRhY2tzPyBEb2Vzbid0 IHRoZSBFS00gaW5wdXQgbGFiZWwgYWxyZWFkeSBkbyB0aGF0Pw0KDQpZZXMsIGl0IGRvZXMsIGJ1 dCBzbyBsb25nIGFzIGl0IGRvZXMgbm90IGNhdXNlIHRoZSBkYXRhIHRvIHRha2UgdXAgYW5vdGhl ciAzMi1ieXRlIGJsb2NrLCBJJ20gT0sgd2l0aCBpdC4NCg0KU28sIEknbSBPSyB3aXRoIHRoZSAt MDkgdmVyc2lvbi4NCg0KQmlsbA0KDQoNCg== --_000_CY1PR0301MB084238130BACD497E791B7FA8CE30CY1PR0301MB0842_ 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 bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjEyNzcxNzUyOTE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi01NTA0NDAwNzQgMjA3Mjc5MzAwNCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206 MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvIHN1bSB1cCwg YXJlIHdlIGluIGFncmVlbWVudCB0aGF0IHRoZSBjb25jYXRlbmF0aW9uIHdpbGwgb25seSBpbmNs dWRlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1z by1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Ub2tlbkJpbmRpbmdUeXBlIHZhbHVlIGNvbnRhaW5lZCBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBUb2tlbkJpbmRpbmcudG9rZW5iaW5kaW5nX3R5cGUgZmllbGQ7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Ub2tlbkJpbmRpbmdL ZXlQYXJhbWV0ZXJzIHZhbHVlIGNvbnRhaW5lZCBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBUb2tlbkJpbmRpbmdJRC5rZXlfcGFyYW1ldGVycyBmaWVsZDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkV4cG9ydGVkIGtleWluZyBtYXRl cmlhbCAoRUtNKSB2YWx1ZSBvYnRhaW5lZCBmcm9tIHRoZSBjdXJyZW50IFRMUzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbm5lY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7igKYgYmVjYXVzZSB0aGUg bGFiZWwgYW5kIHRoZSBQcm90b2NvbFZlcnNpb24gYXJlIHByZXN1bWFibHkgYWxyZWFkeSBpbiB0 aGUgRUtNPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4gQmlsbCBDb3ggW21haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDMxLCAyMDE2IDI6MDEgUE08YnI+DQo8Yj5Ubzo8L2I+ IEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSZndDs8YnI+DQo8 Yj5DYzo8L2I+IEFuZHJlaSBQb3BvdiAmbHQ7QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20mZ3Q7 OyBUb2tiaW5kIFdHICZsdDt1bmJlYXJhYmxlQGlldGYub3JnJmd0OzsgTGVpZiBKb2hhbnNzb24g Jmx0O2xlaWZqQHN1bmV0LnNlJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFi bGVdIER1bWIgaWRlYTogYWRkIEVkMjU1MTkgc3VwcG9ydD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVnIDMxLCAyMDE2IGF0IDE6 MTAgUE0sIEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBdWcgMzEsIDIwMTYgYXQgMTozNSBQTSwgQmlsbCBDb3gg Jmx0OzxhIGhyZWY9Im1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFu ayI+d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFdlZCwgQXVnIDMxLCAyMDE2IGF0IDEyOjEyIFBNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNh bXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gd2hpY2ggY2FzZSBJJ2Qg YWdhaW4gc3VnZ2VzdCB0aGF0IHRoZSBzaWduYXR1cmUgaW5wdXQgYmUgdGhlIGNvbmNhdGVuYXRl ZCBpdGVtcyBkaXJlY3RseSAobm8gaGFzaCkgYW5kIHRoYXQgaGFzaGluZyBvciBub3QgYmUgcGFy dCBvZiB0aGUgc2lnbmF0dXJlIHNjaGVtZSBhc3NvY2lhdGVkIHdpdGggZWFjaCBrZXkgcGFyYW1l dGVycyB0eXBlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb3VuZHMgZ29vZCB0byBtZS4mbmJzcDsgSXQg Zml0cyB0aGUgc3RhbmRhcmQgQVBJcyBhIGJpdCBiZXR0ZXIuJm5ic3A7IElJVUMsIHRoaXMgcmVz dWx0IGlzIHRoZSBzYW1lIGVpdGhlciB3YXksIHNvIHRoaXMgaXMgcmVhbGx5IGp1c3QgYSBtYXR0 ZXIgb2YgaG93IHdlIGRlc2NyaWJlIGl0LCByaWdodD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMzg3NjFEIj5BZnRlciBwbGF5aW5nIGFyb3Vu ZCB3aXRoIHNvbWUgQVBJcyB5ZXN0ZXJkYXksIEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGUgcmVzdWx0 IGlzIGFjdHVhbGx5IHRoZSBzYW1lLiBBdCBsZWFzdCBhcyBmYXIgYXMgdGhlIGFjdHVhbCBieXRl cyBvZiB0aGUgc2lnbmF0dXJlLiBDb25jZXB0dWFsbHkgdGhlIGlkZWEgaXMgdGhlIHNhbWUgdGhv dWdoLCBBRkFJSywgYW5kIG1vdmluZw0KIHRoZSBoYXNoIGRlZmluaXRpb24gdG8gdGhlIHNpZ25h dHVyZSBzY2hlbWUgYXNzb2NpYXRlZCB3aXRoIGVhY2gga2V5IHBhcmFtZXRlcnMgdHlwZSByZW1v dmVzIGEgaGFyZHdpcmVkIGRlcGVuZGVuY3kgb24gU0hBMjU2IGFuZCBhbHNvIGVsaW1pbmF0ZXMg YSByb3VuZCBvZiBoYXNoaW5nIGZvciB0aGUgUlNBIGtleSBwYXJhbWV0ZXJzIHR5cGVzLiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg T3BlblNTTCBzaWduaW5nIEFQSXMgYXJlIGZpbmlja3kuJm5ic3A7IFRoZXkgcmVhbGx5IHdhbnQg dG8gZG8gYSBkaWdlc3QsIGFuZCB5b3UgaGF2ZSB0byBrbm93IGhvdyB0byBjYWxsIHRoZW0ganVz dCByaWdodCB0byBzaWduIHRoZSBkaWdlc3QsIHJhdGhlciB0aGFuIHRoZSBoYXNoIG9mIHRoZSBk aWdlc3QuJm5ic3A7IEhvd2V2ZXIsIGF0IG9uZSBwb2ludCwgSSB3YXMgYWJsZSB0byB2ZXJpZnkg dGhhdCBib3RoIHdheXMNCiBnaXZlIHRoZSBzYW1lIHJlc3VsdC4mbmJzcDsgSSBhY3R1YWxseSB1 c2UgdGhlIG5vcm1hbCBBUElzIG5vdyB0aGF0IGRvIHRoZSBTSEEyNTYgd2hpbGUgc2lnbmluZy4m bmJzcDsgSSBkbyBub3QgdGhpbmsgdGhpcyByZXF1aXJlcyBhIGRvY3VtZW50IGNoYW5nZSwgb3Ro ZXIgdGhhbiBwZXJoYXBzIHNvbWUgY2xhcmlmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BY2NvcmRpbmcgdG8g dGhlIEVLTSBzcGVjICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTcw NSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzA1PC9h PiksIGEgZGlzYW1iaWd1YXRpbmcgbGFiZWwgaXMgcmVxdWlyZWQsIGFuZCB3ZSdyZSBhbHNvIHN1 cHBvc2VkIHRvIHJlZ2lzdGVyIGl0IHNvIHRoZXJlIGFyZSBubyBuYW1lIGNvbGxpc2lvbnMuJm5i c3A7DQogSXMgdGhpcyBzb21ldGhpbmcgd2UgbmVlZCB0byB3b3JyeSBhYm91dD8mbmJzcDsgPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMzg3 NjFEIj5JIHRoaW5rIHRoYXQncyBhbHJlYWR5IChvciB3aWxsIGJlKSBjb3ZlcmVkIHdpdGggdGhl IHJlZ2lzdHJhdGlvbiByZXF1ZXN0IGZvciAmcXVvdDtFWFBPUlRFUi1Ub2tlbi1CaW5kaW5nJnF1 b3Q7IGluDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10 b2tiaW5kLXByb3RvY29sLTA5I3NlY3Rpb24tNi40IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10b2tiaW5kLXByb3RvY29sLTA5I3NlY3Rp b24tNi40PC9hPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T0ssIGdyZWF0LiZuYnNwOyBJbiB0aGF0IGNhc2UsIGFkZGluZyAmcXVvdDtUb2tlbiBCaW5k aW5nJnF1b3Q7IGlzIHJlZHVuZGFudCwgYnV0IHNpbmNlIHdlIHVzZSBhIDMyLWJ5dGUgYmxvY2sg aGFzaCBhbnl3YXksIEkgZG9uJ3QgdGhpbmsgaXQgd2lsbCBtYWtlIGFueSBkaWZmZXJlbmNlIGlu cyBzcGVlZCwgb3RoZXIgdGhhbiB0aGUgY29zdCBvZiBjb3B5aW5nIHRoZSBkYXRhLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkZvciBzb21lIHJlYXNvbiwgSSB0aG91Z2h0IHdlIGhhZCBhbHJlYWR5IHJlZ2lzdGVy ZWQgJnF1b3Q7VG9rZW4gQmluZGluZyZxdW90OyBhcyBhIHVuaXF1ZSBFS00gbGFiZWwuJm5ic3A7 IElmIHNvLCB3ZSBzaG91bGQgcHJvYmFibHkgcGFzcyB0aGUgbGFiZWwgdG8gdGhlIEVLTSBlaXRo ZXIgaW4gYWRkaXRpb24gdG8sIG9yIGluc3RlYWQgb2YsIGhhc2hpbmcgaXQgaW4gdGhlIGZpbmFs IGhhc2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMzg3NjFEIj5JIG1heSBoYXZl IGNvbmZ1c2VkIHRoaW5ncyBieSB1c2luZyB0aGUgdGVybSBsYWJlbCBmb3IgdGhlIEFTQ0lJIHN0 cmluZyAmcXVvdDtUb2tlbiBCaW5kaW5nJnF1b3Q7IHRoYXQncyBwYXJ0IG9mIHRoZSBjb25jYXRl bmF0aW9uIG9mIHRoaW5ncy4gSXQncyBub3QgYSBsYWJlbCBpbiB0aGUgUkZDIDU3MDUgc2Vuc2Ug YnV0IG1vcmUgb2YgYSBkaXNhbWJpZ3VhdGVyIHRoYXQgaXMgdGFja2VkIG9udG8gdGhlIGNvbnRl bnQNCiB0aGF0IGlzIHNpbmdlZC4gQW5kcmVpIGNhbiBwZXJoYXBzIGV4cGxhaW4gaXQncyBwdXJw b3NlIGJldHRlci4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzODc2MUQiPkJ1dCBqdXN0IHRoaW5r aW5nIGFib3V0IHRoYXQgbWFrZXMgbWUgd29uZGVyIGlmIGl0J3MgbmVjZXNzYXJ5LiAmcXVvdDsm cXVvdDtFWFBPUlRFUi1Ub2tlbi1CaW5kaW5nJnF1b3Q7IGlzIGhhc2hlZCBpbnRvIHRoZSBFS00g d2hpY2ggaXMgdGhlbiB1bmRlciB0aGUgc2lnbmF0dXJlLiBJcyBhbm90aGVyICZxdW90O1Rva2Vu IEJpbmRpbmcmcXVvdDsgc3RyaW5nIHVuZGVyIHRoZSBzaWduYXR1cmUgbmVlZGVkDQogdG8gcHJl dmVudCBjcm9zcyBwcm90b2NvbCBhdHRhY2tzPyBEb2Vzbid0IHRoZSBFS00gaW5wdXQgbGFiZWwg YWxyZWFkeSBkbyB0aGF0PyA8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+WWVzLCBpdCBkb2VzLCBidXQgc28gbG9uZyBhcyBpdCBkb2VzIG5vdCBjYXVzZSB0aGUg ZGF0YSB0byB0YWtlIHVwIGFub3RoZXIgMzItYnl0ZSBibG9jaywgSSdtIE9LIHdpdGggaXQuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLCBJ J20gT0sgd2l0aCB0aGUgLTA5IHZlcnNpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJpbGwmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_CY1PR0301MB084238130BACD497E791B7FA8CE30CY1PR0301MB0842_-- From nobody Wed Aug 31 14:34:35 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 2553112D08C for ; Wed, 31 Aug 2016 14:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 cQPli2Qtp06j for ; Wed, 31 Aug 2016 14:34:31 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 809D512D76A for ; Wed, 31 Aug 2016 14:34:31 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id i32so112296942uai.2 for ; Wed, 31 Aug 2016 14:34:31 -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=Aj8602vSF5e3OoTrn3+63raTWJQ9dsQ8n2EfDSJDFwQ=; b=Qrzw3p+0af33im1KIH2OTOGZk61JDHMsNqVWwCtNrrvbnSvWSlmtI9R8AoGTN0jfaD z/q8aFHLMtkLb0WoRUK60xUXLQ/Wuh1cQYIXJk6giE8cpEBkfU3S2maSToqVWbL0AnLc eTHK/42P+FetBOGutHr0sqBPSDHGsHQCTDf2COpSyCvKtkUB4bfsgjvGNG3kMv5LIw96 YXGzubJcAYTN48ft7a3Qm0dm0491+gRVIWntWlF1AnlxEASb8ecEbIXYFQtLONnlSBVN YnuW3JxrkWGtUj4n5UkhrdRVEaWQicAzMR9VUHnI/NvfUYe/sdI0Xi2YHtGZZWP0ZeAi DvaQ== 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=Aj8602vSF5e3OoTrn3+63raTWJQ9dsQ8n2EfDSJDFwQ=; b=LBZVM9eimMs8nECRwuNw8D6vIBduIfCpcwh/gHoYSU7zlock/daJF1ZEGaYYB3wu88 ZN0k9NxMO/bG7z5OJsl0SF3b9m3eh7SNaL5zK4D0shdRLvkaTkcWCNI+YyxukAHeNhcF cNoQzlNyoG+CWofadAPcDPqsEoQOigERBEVvls+O4EXe3L6oUtMH5WZxrAC0PHe6d1fB r/uD8DyYe/ioUkjCzOU5DFfOX+PnjW++lk/ldsosKqmamgugZhhbZirow42RZKbH0NAF by21QD3dgJO/2f5DAghVS1PbUWQ8p0C1Q7HT/3/2HkHyXd+phy/laXYYbrMpYacEejH5 W5fQ== X-Gm-Message-State: AE9vXwMr3rYkBqUzDW+n8eJ2W4CUh1gynNcHOj6VELb0Zl8aIDHicmvfQnvNttdr36HeTCwhIUJIxYYZcTp09mQ+ X-Received: by 10.176.82.9 with SMTP id i9mr7178571uaa.155.1472679270376; Wed, 31 Aug 2016 14:34:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.97.2 with HTTP; Wed, 31 Aug 2016 14:34:29 -0700 (PDT) In-Reply-To: References: From: Bill Cox Date: Wed, 31 Aug 2016 14:34:29 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=94eb2c191926c7c708053b64dc8e Archived-At: Cc: Tokbind WG , Brian Campbell , Leif Johansson Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) 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, 31 Aug 2016 21:34:34 -0000 --94eb2c191926c7c708053b64dc8e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Works for me. On Wed, Aug 31, 2016 at 2:20 PM, Andrei Popov wrote: > To sum up, are we in agreement that the concatenation will only include: > > > > - TokenBindingType value contained in the > > TokenBinding.tokenbinding_type field; > > - TokenBindingKeyParameters value contained in the > > TokenBindingID.key_parameters field; > > - Exported keying material (EKM) value obtained from the current > TLS > > connection. > > =E2=80=A6 because the label and the ProtocolVersion are presumably alread= y in the > EKM? > > > > *From:* Bill Cox [mailto:waywardgeek@google.com] > *Sent:* Wednesday, August 31, 2016 2:01 PM > *To:* Brian Campbell > *Cc:* Andrei Popov ; Tokbind WG < > unbearable@ietf.org>; Leif Johansson > *Subject:* Re: [Unbearable] Dumb idea: add Ed25519 support? > > > > On Wed, Aug 31, 2016 at 1:10 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > > > > On Wed, Aug 31, 2016 at 1:35 PM, Bill Cox wrote: > > On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > > In which case I'd again suggest that the signature input be the > concatenated items directly (no hash) and that hashing or not be part of > the signature scheme associated with each key parameters type. > > > > Sounds good to me. It fits the standard APIs a bit better. IIUC, this > result is the same either way, so this is really just a matter of how we > describe it, right? > > > > > After playing around with some APIs yesterday, I don't think that the > result is actually the same. At least as far as the actual bytes of the > signature. Conceptually the idea is the same though, AFAIK, and moving th= e > hash definition to the signature scheme associated with each key paramete= rs > type removes a hardwired dependency on SHA256 and also eliminates a round > of hashing for the RSA key parameters types. > > > > The OpenSSL signing APIs are finicky. They really want to do a digest, > and you have to know how to call them just right to sign the digest, rath= er > than the hash of the digest. However, at one point, I was able to verify > that both ways give the same result. I actually use the normal APIs now > that do the SHA256 while signing. I do not think this requires a documen= t > change, other than perhaps some clarification. > > > > According to the EKM spec (https://tools.ietf.org/html/rfc5705), a > disambiguating label is required, and we're also supposed to register it = so > there are no name collisions. Is this something we need to worry about? > > > > I think that's already (or will be) covered with the registration request > for "EXPORTER-Token-Binding" in https://tools.ietf.org/html/ > draft-ietf-tokbind-protocol-09#section-6.4 > > > > OK, great. In that case, adding "Token Binding" is redundant, but since > we use a 32-byte block hash anyway, I don't think it will make any > difference ins speed, other than the cost of copying the data. > > > > For some reason, I thought we had already registered "Token Binding" as a > unique EKM label. If so, we should probably pass the label to the EKM > either in addition to, or instead of, hashing it in the final hash. > > > I may have confused things by using the term label for the ASCII string > "Token Binding" that's part of the concatenation of things. It's not a > label in the RFC 5705 sense but more of a disambiguater that is tacked on= to > the content that is singed. Andrei can perhaps explain it's purpose bette= r. > > But just thinking about that makes me wonder if it's necessary. > ""EXPORTER-Token-Binding" is hashed into the EKM which is then under the > signature. Is another "Token Binding" string under the signature needed t= o > prevent cross protocol attacks? Doesn't the EKM input label already do > that? > > > > Yes, it does, but so long as it does not cause the data to take up anothe= r > 32-byte block, I'm OK with it. > > > > So, I'm OK with the -09 version. > > > > Bill > > > > > --94eb2c191926c7c708053b64dc8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Works for me.

On Wed, Aug 31, 2016 at 2:20 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

To sum up, are we in agreement that the concatenati= on will only include:

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 TokenBindingType value contained in the=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TokenBinding.tokenbi= nding_type field;

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 TokenBindingKeyParameters value contained in t= he

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TokenBindingID.key_p= arameters field;

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Exported keying material (EKM) value obtained = from the current TLS

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 connection.

=E2=80=A6 because the label and the ProtocolVersion= are presumably already in the EKM?

=C2=A0

From: Bill Cox [mailto:waywardgeek@google.com]
Sent: Wednesday, August 31, 2016 2:01 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Tokbind WG <unbearable@ietf.org&g= t;; Leif Johansson <= leifj@sunet.se>
Subject: Re: [Unbearable] Dumb idea: add Ed25519 support?<= /u>

=C2=A0

On Wed, Aug 31, 2016 at 1:10 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

=C2=A0

On Wed, Aug 31, 2016 at 1:35 PM, Bill Cox <waywardgeek@google.co= m> wrote:

On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell <= ;bcampbell@= pingidentity.com> wrote:

In which case I'd again suggest that the signatu= re input be the concatenated items directly (no hash) and that hashing or n= ot be part of the signature scheme associated with each key parameters type= .=C2=A0

=C2=A0

Sounds good to me.=C2=A0 It fits the standard APIs a= bit better.=C2=A0 IIUC, this result is the same either way, so this is rea= lly just a matter of how we describe it, right?


=C2=A0

After playing around w= ith some APIs yesterday, I don't think that the result is actually the = same. At least as far as the actual bytes of the signature. Conceptually th= e idea is the same though, AFAIK, and moving the hash definition to the signature scheme associated with each key param= eters type removes a hardwired dependency on SHA256 and also eliminates a r= ound of hashing for the RSA key parameters types.=C2=A0

=C2=A0

The OpenSSL signing APIs are finicky.=C2=A0 They rea= lly want to do a digest, and you have to know how to call them just right t= o sign the digest, rather than the hash of the digest.=C2=A0 However, at on= e point, I was able to verify that both ways give the same result.=C2=A0 I actually use the normal APIs now that do the= SHA256 while signing.=C2=A0 I do not think this requires a document change= , other than perhaps some clarification.

=C2=A0

According to the EKM spec (https://tools.ietf.org/html/r= fc5705), a disambiguating label is required, and we're also suppose= d to register it so there are no name collisions.=C2=A0 Is this something we need to worry about?=C2=A0

=C2=A0

I think that's alr= eady (or will be) covered with the registration request for "EXPORTER-= Token-Binding" in https://tools.ietf.org/html/draft-ietf-tokbind-protocol-09#sectio= n-6.4=C2=A0

=C2=A0

OK, great.=C2=A0 In that case, adding "Token Bi= nding" is redundant, but since we use a 32-byte block hash anyway, I d= on't think it will make any difference ins speed, other than the cost o= f copying the data.=C2=A0

=C2=A0

For some reason, I thought we had already registered= "Token Binding" as a unique EKM label.=C2=A0 If so, we should pr= obably pass the label to the EKM either in addition to, or instead of, hash= ing it in the final hash.


I may have confused things by using the term = label for the ASCII string "Token Binding" that's part of the= concatenation of things. It's not a label in the RFC 5705 sense but mo= re of a disambiguater that is tacked onto the content that is singed. Andrei can perhaps explain it's purpose better.

But just thinking abou= t that makes me wonder if it's necessary. ""EXPORTER-Token-Bi= nding" is hashed into the EKM which is then under the signature. Is an= other "Token Binding" string under the signature needed to prevent cross protocol attacks? Doesn't the EKM input label already= do that?

=C2=A0

Yes, it does, but so long as it does not cause the d= ata to take up another 32-byte block, I'm OK with it.

=C2=A0

So, I'm OK with the -09 version.

=C2=A0

Bill=C2=A0

=C2=A0

=C2=A0


--94eb2c191926c7c708053b64dc8e-- From nobody Wed Aug 31 14:42:41 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 51AD012D79F for ; Wed, 31 Aug 2016 14:42:38 -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 CWtCr__tQuo1 for ; Wed, 31 Aug 2016 14:42:35 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 D6FAE12D78B for ; Wed, 31 Aug 2016 14:42:34 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id i184so34217969itf.1 for ; Wed, 31 Aug 2016 14:42:34 -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=HZk8w6P/KNZu2BUKOLBNw2wwozrtzPjbUSMY4f3wjrU=; b=kGgw9wlRrbTn+Uyju08jroUP6JAg6GJMnnLdeb6GAt2rL49khiVK8MtpH8JESQ6T94 bmWCdhmTIQXFz/1isHOrP0TindaZd/4pL29F5rbPzHQo9dT8MtnS8J3EWFXCM6ubNY9I QyplxEvyTDnlf0ScnMngkSb3+K4sWpvY54qq8= 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=HZk8w6P/KNZu2BUKOLBNw2wwozrtzPjbUSMY4f3wjrU=; b=Kbi/amRywPMEqdlQiCV+4QD1a8NMWjP4+pzYGmGLCyrHcOq9Mu2XenpTiv2D2MJbDd XtnjmAyypixMjNL4FqgyPdpPSgNnqpiwl4vF/mwpuzZ4wzpPZvvy7QwCzPQsmoZBbO1d qL7AMzqv7hUA/dLENuCzyXH3YIkhOnx1cGkhY3RdaNcJQnbA1Ut7B+2buzfQQCce5LtE NKXK1E8SAWAx5kWrFGQBWqb6iiBdioQWaJ8B5HcUSfFukkOz9++VaVDP4hBUPBcPkoMv 2NDI7OSfpqXK863IxDpH2ZBLZ3K/Vxoxc/1/U7rA2bUID8N4bMogr0WGJ+JFv1U5dvpD YdjA== X-Gm-Message-State: AE9vXwPFdEODxXh9x3FMiafTgSg664b0ZOWp2hZHs9r17bZxc4grN4RcKSBSrYVqErq70Bp6o1wIJ1wvCCaibhAe X-Received: by 10.36.104.73 with SMTP id v70mr17290225itb.12.1472679754106; Wed, 31 Aug 2016 14:42:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.114.20 with HTTP; Wed, 31 Aug 2016 14:42:03 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 31 Aug 2016 15:42:03 -0600 Message-ID: To: Bill Cox Content-Type: multipart/alternative; boundary=001a113f6ad29caae7053b64f9b3 Archived-At: Cc: Andrei Popov , Tokbind WG , Leif Johansson Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) 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, 31 Aug 2016 21:42:39 -0000 --001a113f6ad29caae7053b64f9b3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Works for me too (I think). On Wed, Aug 31, 2016 at 3:34 PM, Bill Cox wrote: > Works for me. > > On Wed, Aug 31, 2016 at 2:20 PM, Andrei Popov > wrote: > >> To sum up, are we in agreement that the concatenation will only include: >> >> >> >> - TokenBindingType value contained in the >> >> TokenBinding.tokenbinding_type field; >> >> - TokenBindingKeyParameters value contained in the >> >> TokenBindingID.key_parameters field; >> >> - Exported keying material (EKM) value obtained from the >> current TLS >> >> connection. >> >> =E2=80=A6 because the label and the ProtocolVersion are presumably alrea= dy in the >> EKM? >> >> >> >> *From:* Bill Cox [mailto:waywardgeek@google.com] >> *Sent:* Wednesday, August 31, 2016 2:01 PM >> *To:* Brian Campbell >> *Cc:* Andrei Popov ; Tokbind WG < >> unbearable@ietf.org>; Leif Johansson >> *Subject:* Re: [Unbearable] Dumb idea: add Ed25519 support? >> >> >> >> On Wed, Aug 31, 2016 at 1:10 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >> >> >> On Wed, Aug 31, 2016 at 1:35 PM, Bill Cox wrote= : >> >> On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >> In which case I'd again suggest that the signature input be the >> concatenated items directly (no hash) and that hashing or not be part of >> the signature scheme associated with each key parameters type. >> >> >> >> Sounds good to me. It fits the standard APIs a bit better. IIUC, this >> result is the same either way, so this is really just a matter of how we >> describe it, right? >> >> >> >> >> After playing around with some APIs yesterday, I don't think that the >> result is actually the same. At least as far as the actual bytes of the >> signature. Conceptually the idea is the same though, AFAIK, and moving t= he >> hash definition to the signature scheme associated with each key paramet= ers >> type removes a hardwired dependency on SHA256 and also eliminates a roun= d >> of hashing for the RSA key parameters types. >> >> >> >> The OpenSSL signing APIs are finicky. They really want to do a digest, >> and you have to know how to call them just right to sign the digest, rat= her >> than the hash of the digest. However, at one point, I was able to verif= y >> that both ways give the same result. I actually use the normal APIs now >> that do the SHA256 while signing. I do not think this requires a docume= nt >> change, other than perhaps some clarification. >> >> >> >> According to the EKM spec (https://tools.ietf.org/html/rfc5705), a >> disambiguating label is required, and we're also supposed to register it= so >> there are no name collisions. Is this something we need to worry about? >> >> >> >> I think that's already (or will be) covered with the registration reques= t >> for "EXPORTER-Token-Binding" in https://tools.ietf.org/html/dr >> aft-ietf-tokbind-protocol-09#section-6.4 >> >> >> >> OK, great. In that case, adding "Token Binding" is redundant, but since >> we use a 32-byte block hash anyway, I don't think it will make any >> difference ins speed, other than the cost of copying the data. >> >> >> >> For some reason, I thought we had already registered "Token Binding" as = a >> unique EKM label. If so, we should probably pass the label to the EKM >> either in addition to, or instead of, hashing it in the final hash. >> >> >> I may have confused things by using the term label for the ASCII string >> "Token Binding" that's part of the concatenation of things. It's not a >> label in the RFC 5705 sense but more of a disambiguater that is tacked o= nto >> the content that is singed. Andrei can perhaps explain it's purpose bett= er. >> >> But just thinking about that makes me wonder if it's necessary. >> ""EXPORTER-Token-Binding" is hashed into the EKM which is then under the >> signature. Is another "Token Binding" string under the signature needed = to >> prevent cross protocol attacks? Doesn't the EKM input label already do >> that? >> >> >> >> Yes, it does, but so long as it does not cause the data to take up >> another 32-byte block, I'm OK with it. >> >> >> >> So, I'm OK with the -09 version. >> >> >> >> Bill >> >> >> >> >> > > --001a113f6ad29caae7053b64f9b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Works for me too (I think).

On Wed, Aug 31, 2016 at 3:34 PM, Bill= Cox <waywardgeek@google.com> wrote:
Works for me.
<= div class=3D"h5">

= On Wed, Aug 31, 2016 at 2:20 PM, Andrei Popov <Andrei.Popov@micro= soft.com> wrote:

To sum up, are we in agreement that the concatenati= on will only include:

=C2=A0

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TokenBindingType value contained in the=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TokenBinding.tokenbi= nding_type field;

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TokenBindingKeyParameters value contained in t= he

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TokenBindingID.key_p= arameters field;

-= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Exported keying material (EKM) value obtained = from the current TLS

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 connection.

=E2=80=A6 because the label and the ProtocolVersion= are presumably already in the EKM?

=C2=A0

From: Bill Cox [mailto:waywardgeek@google.com]
Sent: Wednesday, August 31, 2016 2:01 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Tokbind WG <unbearable@ietf.org&g= t;; Leif Johansson <= leifj@sunet.se>
Subject: Re: [Unbearable] Dumb idea: add Ed25519 support?<= /u>

=C2=A0

On Wed, Aug 31, 2016 at 1:10 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

=C2=A0

On Wed, Aug 31, 2016 at 1:35 PM, Bill Cox <waywardgeek@google.co= m> wrote:

On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell <= ;bcampbell@= pingidentity.com> wrote:

In which case I'd again suggest that the signatu= re input be the concatenated items directly (no hash) and that hashing or n= ot be part of the signature scheme associated with each key parameters type= .=C2=A0

=C2=A0

Sounds good to me.=C2=A0 It fits the standard APIs a= bit better.=C2=A0 IIUC, this result is the same either way, so this is rea= lly just a matter of how we describe it, right?


=C2=A0

After playing around w= ith some APIs yesterday, I don't think that the result is actually the = same. At least as far as the actual bytes of the signature. Conceptually th= e idea is the same though, AFAIK, and moving the hash definition to the signature scheme associated with each key param= eters type removes a hardwired dependency on SHA256 and also eliminates a r= ound of hashing for the RSA key parameters types.=C2=A0

=C2=A0

The OpenSSL signing APIs are finicky.=C2=A0 They rea= lly want to do a digest, and you have to know how to call them just right t= o sign the digest, rather than the hash of the digest.=C2=A0 However, at on= e point, I was able to verify that both ways give the same result.=C2=A0 I actually use the normal APIs now that do the= SHA256 while signing.=C2=A0 I do not think this requires a document change= , other than perhaps some clarification.

=C2=A0

According to the EKM spec (https://tools.ietf.org/html/r= fc5705), a disambiguating label is required, and we're also suppose= d to register it so there are no name collisions.=C2=A0 Is this something we need to worry about?=C2=A0

=C2=A0

I think that's alr= eady (or will be) covered with the registration request for "EXPORTER-= Token-Binding" in https://tools.ietf.org/html/draft-ietf-tokbind-protocol-09#sectio= n-6.4=C2=A0

=C2=A0

OK, great.=C2=A0 In that case, adding "Token Bi= nding" is redundant, but since we use a 32-byte block hash anyway, I d= on't think it will make any difference ins speed, other than the cost o= f copying the data.=C2=A0

=C2=A0

For some reason, I thought we had already registered= "Token Binding" as a unique EKM label.=C2=A0 If so, we should pr= obably pass the label to the EKM either in addition to, or instead of, hash= ing it in the final hash.


I may have confused things by using the term = label for the ASCII string "Token Binding" that's part of the= concatenation of things. It's not a label in the RFC 5705 sense but mo= re of a disambiguater that is tacked onto the content that is singed. Andrei can perhaps explain it's purpose better.

But just thinking abou= t that makes me wonder if it's necessary. ""EXPORTER-Token-Bi= nding" is hashed into the EKM which is then under the signature. Is an= other "Token Binding" string under the signature needed to prevent cross protocol attacks? Doesn't the EKM input label already= do that?

=C2=A0

Yes, it does, but so long as it does not cause the d= ata to take up another 32-byte block, I'm OK with it.

=C2=A0

So, I'm OK with the -09 version.

=C2=A0

Bill=C2=A0

=C2=A0

=C2=A0



--001a113f6ad29caae7053b64f9b3-- From nobody Wed Aug 31 14:47: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 CF28712D0B5 for ; Wed, 31 Aug 2016 14:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 tSPTiuqBxl2b for ; Wed, 31 Aug 2016 14:47:42 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0122.outbound.protection.outlook.com [104.47.41.122]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E7312D08C for ; Wed, 31 Aug 2016 14:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XnPF5eAsvPwp1iAqDlxX4w9A0cFYuP1TzTRLKY5vDPU=; b=Cp8vLXDex2WtxzxYws2YdMtil9b+s4hxQGXr5d8MngLogYaJbAUQ1ic4ZOiYcc3uvU48tTDEPxIP49MMgDwUQ1toah4czIMr5XV9M3xlU5oXcIS8YxataS/jMraAZt+DFn7EqKEHQW+Y7PJxPDZOI33pd6Q0YEG6uaQUrRvsIkg= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Wed, 31 Aug 2016 21:47:39 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Wed, 31 Aug 2016 21:47:39 +0000 From: Andrei Popov To: Brian Campbell , Bill Cox Thread-Topic: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) Thread-Index: AdIDzYe/nNN4QigzR4G2nIa8+fQ4XAAAex2AAABDp4AAAAco4A== Date: Wed, 31 Aug 2016 21:47:39 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 1c6abed4-e397-4e60-feb6-08d3d1e86dc8 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0842; 6:b0QEvS9j+OlvLPzvJE8PZ6mFCO428qihWRAFLMOtgvSUn+CAyMOkZYM6CaczlTj75MbjNVkVa0IuRMORmC1O2LjfvbY99zpZj5U1obk6R06n/RIOf/wu61NzW+lfk54c8a1dQq/MDYeRUCC0fU7zGZ5l/Li9mbJzONm+yZVSI+vdzM+8ojlegOCz+4IIYd0+fMvhOsPUv2hvxLXgoBuHlQWeOgqS+Q4qTktBx+mw3aokracNanfb6v1aK1Eve5C9PTMqL/4+YIEy+ontxB4lE69GPVlSXLNqu7jCzaEKbQiSfkdnt6w1GmUXsscTkAdADo15p1OQVa25YtgCpumcIg==; 5:xPU3cjuNVOKIn+9f36duIbIFOvFFwqsnBBbF20jBwFs94VS/zznWaOX/8SGrenlE4aB9uhDfuqkKFyOuZl9mf3eR9D4l1PdFs1H08u6GD6UNsmO3aBbb8pAgdHcqg1IsWjS1MWTYDm6Q8iCgUs1E+w==; 24:pXNsOGNyM5KDyh68FXC5SKL6A9KzM7piSj9RjpY+28UvyyTOaHnfWAOLS8cIBoszhGsBtC5o78kMtU1Xdicr1Yusz6mVDNAtX70fe0qnCbQ=; 7:90LTD6f8Jb7sAVlg8CX4sQMbGdcY5XQMPNPpiWFj7y1xqN3aK4wMTGYQN0GPQBFTU7nWf8ULXFUtJAdBtfleVnXNQP905ovNVNFdCxJB1V82jj1LQcuSswktzs/SP4aEPS9CYeILxpood29j1qeJ/jr9TriWFy31/UCFALxPC+m/9/rTF857RvUCEENAZz2IgX6shgKbYj6NwosjnY1jDFlIg0tn6CGZZc2xFlgQfARXX3eonrfZXwHrTfq+rAnJ x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0842; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0842; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0842; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(52314003)(51444003)(189002)(377454003)(24454002)(74316002)(3660700001)(10400500002)(7736002)(9686002)(76176999)(7696003)(8990500004)(7846002)(50986999)(33656002)(101416001)(54356999)(10090500001)(11100500001)(81156014)(7906003)(68736007)(8676002)(99286002)(16236675004)(81166006)(19609705001)(790700001)(5660300001)(106356001)(586003)(5001770100001)(102836003)(4326007)(15975445007)(76576001)(86362001)(5002640100001)(6116002)(77096005)(122556002)(87936001)(2950100001)(19625215002)(105586002)(10290500002)(19300405004)(86612001)(8936002)(5005710100001)(19580395003)(97736004)(2906002)(2900100001)(19617315012)(92566002)(19580405001)(3280700002)(189998001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0842; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842C86FDBAB0FB532B2362E8CE30CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 21:47:39.0886 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0842 Archived-At: Cc: Tokbind WG , Leif Johansson Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) 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, 31 Aug 2016 21:47:45 -0000 --_000_CY1PR0301MB0842C86FDBAB0FB532B2362E8CE30CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlYXQuDQoNClRoZW4gd2UgaGF2ZSAzNCBieXRlcyB3ZSBoYXNoIHdpdGggU0hBMjU2IGFuZCBz aWduLg0KDQpXaGVuIHdlIHNpZ24gd2l0aCBSU0EtUFNTIG9yIFJTQS1QS0NTLCB3ZSBhbHNvIHNw ZWNpZnkgdGhlIHVzZSBvZiBTSEEyNTYgaW4gdGhlIHBhZGRpbmcgYWxnb3JpdGhtLiBGb3IgRUNE U0EsIHRoZXJlIGlzIG5vIG5lZWQgdG8gcGFkLCBhbmQgdGhlcmVmb3JlIG5vIG5lZWQgKG9yIG9w cG9ydHVuaXR5KSB0byB1c2UgcGFkZGluZyBoYXNoLg0KDQpCcmlhbiwgd2hhdCBzcGVjaWZpY2Fs bHkgd291bGQgeW91IGxpa2UgdG8gY2hhbmdlIFdSVCBoYXNoaW5nPw0KDQpGcm9tOiBCcmlhbiBD YW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tXQ0KU2VudDogV2VkbmVz ZGF5LCBBdWd1c3QgMzEsIDIwMTYgMjo0MiBQTQ0KVG86IEJpbGwgQ294IDx3YXl3YXJkZ2Vla0Bn b29nbGUuY29tPg0KQ2M6IEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+ OyBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPjsgTGVpZiBKb2hhbnNzb24gPGxlaWZq QHN1bmV0LnNlPg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBXaGF0IEdldHMgU2lnbmVkICh3 YXM6IER1bWIgaWRlYTogYWRkIEVkMjU1MTkgc3VwcG9ydD8pDQoNCldvcmtzIGZvciBtZSB0b28g KEkgdGhpbmspLg0KDQpPbiBXZWQsIEF1ZyAzMSwgMjAxNiBhdCAzOjM0IFBNLCBCaWxsIENveCA8 d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTxtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbT4+IHdy b3RlOg0KV29ya3MgZm9yIG1lLg0KDQpPbiBXZWQsIEF1ZyAzMSwgMjAxNiBhdCAyOjIwIFBNLCBB bmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPG1haWx0bzpBbmRyZWkuUG9w b3ZAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KVG8gc3VtIHVwLCBhcmUgd2UgaW4gYWdyZWVtZW50 IHRoYXQgdGhlIGNvbmNhdGVuYXRpb24gd2lsbCBvbmx5IGluY2x1ZGU6DQoNCg0KLSAgICAgICAg ICBUb2tlbkJpbmRpbmdUeXBlIHZhbHVlIGNvbnRhaW5lZCBpbiB0aGUNCiAgICAgIFRva2VuQmlu ZGluZy50b2tlbmJpbmRpbmdfdHlwZSBmaWVsZDsNCg0KLSAgICAgICAgICBUb2tlbkJpbmRpbmdL ZXlQYXJhbWV0ZXJzIHZhbHVlIGNvbnRhaW5lZCBpbiB0aGUNCiAgICAgIFRva2VuQmluZGluZ0lE LmtleV9wYXJhbWV0ZXJzIGZpZWxkOw0KDQotICAgICAgICAgIEV4cG9ydGVkIGtleWluZyBtYXRl cmlhbCAoRUtNKSB2YWx1ZSBvYnRhaW5lZCBmcm9tIHRoZSBjdXJyZW50IFRMUw0KICAgICAgY29u bmVjdGlvbi4NCuKApiBiZWNhdXNlIHRoZSBsYWJlbCBhbmQgdGhlIFByb3RvY29sVmVyc2lvbiBh cmUgcHJlc3VtYWJseSBhbHJlYWR5IGluIHRoZSBFS00/DQoNCkZyb206IEJpbGwgQ294IFttYWls dG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTxtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbT5d DQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAzMSwgMjAxNiAyOjAxIFBNDQpUbzogQnJpYW4gQ2Ft cGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lk ZW50aXR5LmNvbT4+DQpDYzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNv bTxtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+PjsgVG9rYmluZCBXRyA8dW5iZWFy YWJsZUBpZXRmLm9yZzxtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZz4+OyBMZWlmIEpvaGFuc3Nv biA8bGVpZmpAc3VuZXQuc2U8bWFpbHRvOmxlaWZqQHN1bmV0LnNlPj4NClN1YmplY3Q6IFJlOiBb VW5iZWFyYWJsZV0gRHVtYiBpZGVhOiBhZGQgRWQyNTUxOSBzdXBwb3J0Pw0KDQpPbiBXZWQsIEF1 ZyAzMSwgMjAxNiBhdCAxOjEwIFBNLCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQoNCk9u IFdlZCwgQXVnIDMxLCAyMDE2IGF0IDE6MzUgUE0sIEJpbGwgQ294IDx3YXl3YXJkZ2Vla0Bnb29n bGUuY29tPG1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPj4gd3JvdGU6DQpPbiBXZWQsIEF1 ZyAzMSwgMjAxNiBhdCAxMjoxMiBQTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KSW4g d2hpY2ggY2FzZSBJJ2QgYWdhaW4gc3VnZ2VzdCB0aGF0IHRoZSBzaWduYXR1cmUgaW5wdXQgYmUg dGhlIGNvbmNhdGVuYXRlZCBpdGVtcyBkaXJlY3RseSAobm8gaGFzaCkgYW5kIHRoYXQgaGFzaGlu ZyBvciBub3QgYmUgcGFydCBvZiB0aGUgc2lnbmF0dXJlIHNjaGVtZSBhc3NvY2lhdGVkIHdpdGgg ZWFjaCBrZXkgcGFyYW1ldGVycyB0eXBlLg0KDQpTb3VuZHMgZ29vZCB0byBtZS4gIEl0IGZpdHMg dGhlIHN0YW5kYXJkIEFQSXMgYSBiaXQgYmV0dGVyLiAgSUlVQywgdGhpcyByZXN1bHQgaXMgdGhl IHNhbWUgZWl0aGVyIHdheSwgc28gdGhpcyBpcyByZWFsbHkganVzdCBhIG1hdHRlciBvZiBob3cg d2UgZGVzY3JpYmUgaXQsIHJpZ2h0Pw0KDQoNCkFmdGVyIHBsYXlpbmcgYXJvdW5kIHdpdGggc29t ZSBBUElzIHllc3RlcmRheSwgSSBkb24ndCB0aGluayB0aGF0IHRoZSByZXN1bHQgaXMgYWN0dWFs bHkgdGhlIHNhbWUuIEF0IGxlYXN0IGFzIGZhciBhcyB0aGUgYWN0dWFsIGJ5dGVzIG9mIHRoZSBz aWduYXR1cmUuIENvbmNlcHR1YWxseSB0aGUgaWRlYSBpcyB0aGUgc2FtZSB0aG91Z2gsIEFGQUlL LCBhbmQgbW92aW5nIHRoZSBoYXNoIGRlZmluaXRpb24gdG8gdGhlIHNpZ25hdHVyZSBzY2hlbWUg YXNzb2NpYXRlZCB3aXRoIGVhY2gga2V5IHBhcmFtZXRlcnMgdHlwZSByZW1vdmVzIGEgaGFyZHdp cmVkIGRlcGVuZGVuY3kgb24gU0hBMjU2IGFuZCBhbHNvIGVsaW1pbmF0ZXMgYSByb3VuZCBvZiBo YXNoaW5nIGZvciB0aGUgUlNBIGtleSBwYXJhbWV0ZXJzIHR5cGVzLg0KDQpUaGUgT3BlblNTTCBz aWduaW5nIEFQSXMgYXJlIGZpbmlja3kuICBUaGV5IHJlYWxseSB3YW50IHRvIGRvIGEgZGlnZXN0 LCBhbmQgeW91IGhhdmUgdG8ga25vdyBob3cgdG8gY2FsbCB0aGVtIGp1c3QgcmlnaHQgdG8gc2ln biB0aGUgZGlnZXN0LCByYXRoZXIgdGhhbiB0aGUgaGFzaCBvZiB0aGUgZGlnZXN0LiAgSG93ZXZl ciwgYXQgb25lIHBvaW50LCBJIHdhcyBhYmxlIHRvIHZlcmlmeSB0aGF0IGJvdGggd2F5cyBnaXZl IHRoZSBzYW1lIHJlc3VsdC4gIEkgYWN0dWFsbHkgdXNlIHRoZSBub3JtYWwgQVBJcyBub3cgdGhh dCBkbyB0aGUgU0hBMjU2IHdoaWxlIHNpZ25pbmcuICBJIGRvIG5vdCB0aGluayB0aGlzIHJlcXVp cmVzIGEgZG9jdW1lbnQgY2hhbmdlLCBvdGhlciB0aGFuIHBlcmhhcHMgc29tZSBjbGFyaWZpY2F0 aW9uLg0KDQpBY2NvcmRpbmcgdG8gdGhlIEVLTSBzcGVjIChodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNTcwNSksIGEgZGlzYW1iaWd1YXRpbmcgbGFiZWwgaXMgcmVxdWlyZWQsIGFuZCB3 ZSdyZSBhbHNvIHN1cHBvc2VkIHRvIHJlZ2lzdGVyIGl0IHNvIHRoZXJlIGFyZSBubyBuYW1lIGNv bGxpc2lvbnMuICBJcyB0aGlzIHNvbWV0aGluZyB3ZSBuZWVkIHRvIHdvcnJ5IGFib3V0Pw0KDQpJ IHRoaW5rIHRoYXQncyBhbHJlYWR5IChvciB3aWxsIGJlKSBjb3ZlcmVkIHdpdGggdGhlIHJlZ2lz dHJhdGlvbiByZXF1ZXN0IGZvciAiRVhQT1JURVItVG9rZW4tQmluZGluZyIgaW4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1wcm90b2NvbC0wOSNzZWN0aW9u LTYuNA0KDQpPSywgZ3JlYXQuICBJbiB0aGF0IGNhc2UsIGFkZGluZyAiVG9rZW4gQmluZGluZyIg aXMgcmVkdW5kYW50LCBidXQgc2luY2Ugd2UgdXNlIGEgMzItYnl0ZSBibG9jayBoYXNoIGFueXdh eSwgSSBkb24ndCB0aGluayBpdCB3aWxsIG1ha2UgYW55IGRpZmZlcmVuY2UgaW5zIHNwZWVkLCBv dGhlciB0aGFuIHRoZSBjb3N0IG9mIGNvcHlpbmcgdGhlIGRhdGEuDQoNCkZvciBzb21lIHJlYXNv biwgSSB0aG91Z2h0IHdlIGhhZCBhbHJlYWR5IHJlZ2lzdGVyZWQgIlRva2VuIEJpbmRpbmciIGFz IGEgdW5pcXVlIEVLTSBsYWJlbC4gIElmIHNvLCB3ZSBzaG91bGQgcHJvYmFibHkgcGFzcyB0aGUg bGFiZWwgdG8gdGhlIEVLTSBlaXRoZXIgaW4gYWRkaXRpb24gdG8sIG9yIGluc3RlYWQgb2YsIGhh c2hpbmcgaXQgaW4gdGhlIGZpbmFsIGhhc2guDQoNCkkgbWF5IGhhdmUgY29uZnVzZWQgdGhpbmdz IGJ5IHVzaW5nIHRoZSB0ZXJtIGxhYmVsIGZvciB0aGUgQVNDSUkgc3RyaW5nICJUb2tlbiBCaW5k aW5nIiB0aGF0J3MgcGFydCBvZiB0aGUgY29uY2F0ZW5hdGlvbiBvZiB0aGluZ3MuIEl0J3Mgbm90 IGEgbGFiZWwgaW4gdGhlIFJGQyA1NzA1IHNlbnNlIGJ1dCBtb3JlIG9mIGEgZGlzYW1iaWd1YXRl ciB0aGF0IGlzIHRhY2tlZCBvbnRvIHRoZSBjb250ZW50IHRoYXQgaXMgc2luZ2VkLiBBbmRyZWkg Y2FuIHBlcmhhcHMgZXhwbGFpbiBpdCdzIHB1cnBvc2UgYmV0dGVyLg0KQnV0IGp1c3QgdGhpbmtp bmcgYWJvdXQgdGhhdCBtYWtlcyBtZSB3b25kZXIgaWYgaXQncyBuZWNlc3NhcnkuICIiRVhQT1JU RVItVG9rZW4tQmluZGluZyIgaXMgaGFzaGVkIGludG8gdGhlIEVLTSB3aGljaCBpcyB0aGVuIHVu ZGVyIHRoZSBzaWduYXR1cmUuIElzIGFub3RoZXIgIlRva2VuIEJpbmRpbmciIHN0cmluZyB1bmRl ciB0aGUgc2lnbmF0dXJlIG5lZWRlZCB0byBwcmV2ZW50IGNyb3NzIHByb3RvY29sIGF0dGFja3M/ IERvZXNuJ3QgdGhlIEVLTSBpbnB1dCBsYWJlbCBhbHJlYWR5IGRvIHRoYXQ/DQoNClllcywgaXQg ZG9lcywgYnV0IHNvIGxvbmcgYXMgaXQgZG9lcyBub3QgY2F1c2UgdGhlIGRhdGEgdG8gdGFrZSB1 cCBhbm90aGVyIDMyLWJ5dGUgYmxvY2ssIEknbSBPSyB3aXRoIGl0Lg0KDQpTbywgSSdtIE9LIHdp dGggdGhlIC0wOSB2ZXJzaW9uLg0KDQpCaWxsDQoNCg0KDQoNCg== --_000_CY1PR0301MB0842C86FDBAB0FB532B2362E8CE30CY1PR0301MB0842_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+R3JlYXQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlRoZW4gd2UgaGF2ZSAzNCBieXRlcyB3ZSBoYXNoIHdpdGggU0hBMjU2IGFuZCBzaWduLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPldoZW4gd2Ugc2lnbiB3aXRoIFJTQS1QU1Mgb3IgUlNBLVBLQ1MsIHdlIGFs c28gc3BlY2lmeSB0aGUgdXNlIG9mIFNIQTI1NiBpbiB0aGUgcGFkZGluZyBhbGdvcml0aG0uIEZv ciBFQ0RTQSwgdGhlcmUgaXMgbm8gbmVlZCB0byBwYWQsIGFuZCB0aGVyZWZvcmUgbm8gbmVlZCAo b3Igb3Bwb3J0dW5pdHkpDQogdG8gdXNlIHBhZGRpbmcgaGFzaC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QnJp YW4sIHdoYXQgc3BlY2lmaWNhbGx5IHdvdWxkIHlvdSBsaWtlIHRvIGNoYW5nZSBXUlQgaGFzaGlu Zz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJy aWFuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYgMjo0MiBQTTxicj4NCjxiPlRv OjwvYj4gQmlsbCBDb3ggJmx0O3dheXdhcmRnZWVrQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBBbmRyZWkgUG9wb3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tJmd0OzsgVG9r YmluZCBXRyAmbHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs7IExlaWYgSm9oYW5zc29uICZsdDts ZWlmakBzdW5ldC5zZSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBX aGF0IEdldHMgU2lnbmVkICh3YXM6IER1bWIgaWRlYTogYWRkIEVkMjU1MTkgc3VwcG9ydD8pPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V29ya3MgZm9yIG1lIHRvbyAoSSB0 aGluaykuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g V2VkLCBBdWcgMzEsIDIwMTYgYXQgMzozNCBQTSwgQmlsbCBDb3ggJmx0OzxhIGhyZWY9Im1haWx0 bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2F5d2FyZGdlZWtAZ29v Z2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Xb3JrcyBmb3IgbWUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVnIDMxLCAy MDE2IGF0IDI6MjAgUE0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Q b3BvdkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92QG1pY3Jvc29m dC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UbyBzdW0gdXAs IGFyZSB3ZSBpbiBhZ3JlZW1lbnQgdGhhdCB0aGUgY29uY2F0ZW5hdGlvbiB3aWxsIG9ubHkgaW5j bHVkZTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+VG9rZW5CaW5kaW5nVHlwZSB2YWx1ZSBjb250YWluZWQgaW4gdGhlPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUb2tlbkJpbmRpbmcudG9rZW5iaW5kaW5nX3R5 cGUgZmllbGQ7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ VG9rZW5CaW5kaW5nS2V5UGFyYW1ldGVycyB2YWx1ZSBjb250YWluZWQgaW4gdGhlPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUb2tlbkJpbmRpbmdJRC5rZXlfcGFyYW1ldGVy cyBmaWVsZDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi08L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5F eHBvcnRlZCBrZXlpbmcgbWF0ZXJpYWwgKEVLTSkgdmFsdWUgb2J0YWluZWQgZnJvbSB0aGUgY3Vy cmVudCBUTFM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbm5lY3Rpb24u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPuKApiBiZWNhdXNlIHRoZSBsYWJlbCBhbmQgdGhlIFByb3RvY29sVmVyc2lvbiBhcmUg cHJlc3VtYWJseSBhbHJlYWR5IGluIHRoZSBFS00/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQmlsbCBDb3ggW21haWx0bzo8YSBocmVmPSJt YWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndheXdhcmRnZWVr QGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDMx LCAyMDE2IDI6MDEgUE08YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVm PSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBBbmRyZWkgUG9w b3YgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDs7IFRva2JpbmQgV0cg Jmx0OzxhIGhyZWY9Im1haWx0bzp1bmJlYXJhYmxlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ dW5iZWFyYWJsZUBpZXRmLm9yZzwvYT4mZ3Q7OyBMZWlmIEpvaGFuc3NvbiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmxlaWZqQHN1bmV0LnNlIiB0YXJnZXQ9Il9ibGFuayI+bGVpZmpAc3VuZXQuc2U8L2E+ Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIER1bWIgaWRlYTogYWRk IEVkMjU1MTkgc3VwcG9ydD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5PbiBXZWQsIEF1ZyAzMSwgMjAxNiBhdCAxOjEwIFBNLCBCcmlhbiBD YW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0 YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBBdWcgMzEs IDIwMTYgYXQgMTozNSBQTSwgQmlsbCBDb3ggJmx0OzxhIGhyZWY9Im1haWx0bzp3YXl3YXJkZ2Vl a0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIFdlZCwgQXVnIDMxLCAyMDE2IGF0IDEyOjEyIFBNLCBCcmlhbiBDYW1wYmVsbCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9i bGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gd2hpY2ggY2FzZSBJJ2QgYWdhaW4gc3Vn Z2VzdCB0aGF0IHRoZSBzaWduYXR1cmUgaW5wdXQgYmUgdGhlIGNvbmNhdGVuYXRlZCBpdGVtcyBk aXJlY3RseSAobm8gaGFzaCkgYW5kIHRoYXQgaGFzaGluZyBvciBub3QgYmUgcGFydCBvZiB0aGUg c2lnbmF0dXJlIHNjaGVtZSBhc3NvY2lhdGVkIHdpdGggZWFjaA0KIGtleSBwYXJhbWV0ZXJzIHR5 cGUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Tb3VuZHMgZ29vZCB0byBtZS4mbmJzcDsgSXQgZml0 cyB0aGUgc3RhbmRhcmQgQVBJcyBhIGJpdCBiZXR0ZXIuJm5ic3A7IElJVUMsIHRoaXMgcmVzdWx0 IGlzIHRoZSBzYW1lIGVpdGhlciB3YXksIHNvIHRoaXMgaXMgcmVhbGx5IGp1c3QgYSBtYXR0ZXIg b2YgaG93IHdlIGRlc2NyaWJlIGl0LCByaWdodD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGJyPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzM4NzYxRCI+QWZ0ZXIgcGxheWluZyBhcm91 bmQgd2l0aCBzb21lIEFQSXMgeWVzdGVyZGF5LCBJIGRvbid0IHRoaW5rIHRoYXQgdGhlIHJlc3Vs dCBpcyBhY3R1YWxseSB0aGUgc2FtZS4gQXQgbGVhc3QgYXMgZmFyIGFzIHRoZSBhY3R1YWwgYnl0 ZXMgb2YgdGhlIHNpZ25hdHVyZS4NCiBDb25jZXB0dWFsbHkgdGhlIGlkZWEgaXMgdGhlIHNhbWUg dGhvdWdoLCBBRkFJSywgYW5kIG1vdmluZyB0aGUgaGFzaCBkZWZpbml0aW9uIHRvIHRoZSBzaWdu YXR1cmUgc2NoZW1lIGFzc29jaWF0ZWQgd2l0aCBlYWNoIGtleSBwYXJhbWV0ZXJzIHR5cGUgcmVt b3ZlcyBhIGhhcmR3aXJlZCBkZXBlbmRlbmN5IG9uIFNIQTI1NiBhbmQgYWxzbyBlbGltaW5hdGVz IGEgcm91bmQgb2YgaGFzaGluZyBmb3IgdGhlIFJTQSBrZXkgcGFyYW1ldGVycyB0eXBlcy4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PlRoZSBPcGVuU1NMIHNpZ25pbmcgQVBJcyBhcmUgZmluaWNreS4mbmJzcDsgVGhleSByZWFsbHkg d2FudCB0byBkbyBhIGRpZ2VzdCwgYW5kIHlvdSBoYXZlIHRvIGtub3cgaG93IHRvIGNhbGwgdGhl bSBqdXN0IHJpZ2h0IHRvIHNpZ24gdGhlIGRpZ2VzdCwgcmF0aGVyIHRoYW4gdGhlIGhhc2ggb2Yg dGhlIGRpZ2VzdC4mbmJzcDsNCiBIb3dldmVyLCBhdCBvbmUgcG9pbnQsIEkgd2FzIGFibGUgdG8g dmVyaWZ5IHRoYXQgYm90aCB3YXlzIGdpdmUgdGhlIHNhbWUgcmVzdWx0LiZuYnNwOyBJIGFjdHVh bGx5IHVzZSB0aGUgbm9ybWFsIEFQSXMgbm93IHRoYXQgZG8gdGhlIFNIQTI1NiB3aGlsZSBzaWdu aW5nLiZuYnNwOyBJIGRvIG5vdCB0aGluayB0aGlzIHJlcXVpcmVzIGEgZG9jdW1lbnQgY2hhbmdl LCBvdGhlciB0aGFuIHBlcmhhcHMgc29tZSBjbGFyaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkFjY29yZGluZyB0byB0aGUgRUtNIHNwZWMgKDxhIGhyZWY9Imh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzA1IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzU3MDU8L2E+KSwgYSBkaXNhbWJpZ3VhdGluZyBsYWJlbCBpcyBy ZXF1aXJlZCwgYW5kIHdlJ3JlDQogYWxzbyBzdXBwb3NlZCB0byByZWdpc3RlciBpdCBzbyB0aGVy ZSBhcmUgbm8gbmFtZSBjb2xsaXNpb25zLiZuYnNwOyBJcyB0aGlzIHNvbWV0aGluZyB3ZSBuZWVk IHRvIHdvcnJ5IGFib3V0PyZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzM4NzYxRCI+SSB0aGluayB0aGF0J3MgYWxyZWFk eSAob3Igd2lsbCBiZSkgY292ZXJlZCB3aXRoIHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdCBmb3Ig JnF1b3Q7RVhQT1JURVItVG9rZW4tQmluZGluZyZxdW90OyBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1wcm90b2NvbC0wOSNzZWN0aW9u LTYuNCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtdG9rYmluZC1wcm90b2NvbC0wOSNzZWN0aW9uLTYuNDwvYT4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PSywgZ3JlYXQuJm5ic3A7IElu IHRoYXQgY2FzZSwgYWRkaW5nICZxdW90O1Rva2VuIEJpbmRpbmcmcXVvdDsgaXMgcmVkdW5kYW50 LCBidXQgc2luY2Ugd2UgdXNlIGEgMzItYnl0ZSBibG9jayBoYXNoIGFueXdheSwgSSBkb24ndCB0 aGluayBpdCB3aWxsIG1ha2UgYW55IGRpZmZlcmVuY2UgaW5zIHNwZWVkLCBvdGhlciB0aGFuIHRo ZQ0KIGNvc3Qgb2YgY29weWluZyB0aGUgZGF0YS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5Gb3Igc29tZSByZWFzb24sIEkgdGhvdWdodCB3ZSBoYWQgYWxyZWFkeSByZWdpc3Rl cmVkICZxdW90O1Rva2VuIEJpbmRpbmcmcXVvdDsgYXMgYSB1bmlxdWUgRUtNIGxhYmVsLiZuYnNw OyBJZiBzbywgd2Ugc2hvdWxkIHByb2JhYmx5IHBhc3MgdGhlIGxhYmVsIHRvIHRoZSBFS00gZWl0 aGVyIGluIGFkZGl0aW9uIHRvLCBvciBpbnN0ZWFkDQogb2YsIGhhc2hpbmcgaXQgaW4gdGhlIGZp bmFsIGhhc2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxzcGFuIHN0eWxl PSJjb2xvcjojMzg3NjFEIj5JIG1heSBoYXZlIGNvbmZ1c2VkIHRoaW5ncyBieSB1c2luZyB0aGUg dGVybSBsYWJlbCBmb3IgdGhlIEFTQ0lJIHN0cmluZyAmcXVvdDtUb2tlbiBCaW5kaW5nJnF1b3Q7 IHRoYXQncyBwYXJ0IG9mIHRoZSBjb25jYXRlbmF0aW9uIG9mIHRoaW5ncy4gSXQncyBub3QgYSBs YWJlbCBpbiB0aGUgUkZDIDU3MDUgc2Vuc2UgYnV0IG1vcmUgb2YgYSBkaXNhbWJpZ3VhdGVyIHRo YXQgaXMgdGFja2VkIG9udG8gdGhlIGNvbnRlbnQNCiB0aGF0IGlzIHNpbmdlZC4gQW5kcmVpIGNh biBwZXJoYXBzIGV4cGxhaW4gaXQncyBwdXJwb3NlIGJldHRlci4gPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzM4NzYxRCI+QnV0IGp1c3QgdGhpbmtpbmcgYWJvdXQgdGhhdCBtYWtlcyBtZSB3b25k ZXIgaWYgaXQncyBuZWNlc3NhcnkuICZxdW90OyZxdW90O0VYUE9SVEVSLVRva2VuLUJpbmRpbmcm cXVvdDsgaXMgaGFzaGVkIGludG8gdGhlIEVLTSB3aGljaCBpcyB0aGVuIHVuZGVyIHRoZSBzaWdu YXR1cmUuIElzDQogYW5vdGhlciAmcXVvdDtUb2tlbiBCaW5kaW5nJnF1b3Q7IHN0cmluZyB1bmRl ciB0aGUgc2lnbmF0dXJlIG5lZWRlZCB0byBwcmV2ZW50IGNyb3NzIHByb3RvY29sIGF0dGFja3M/ IERvZXNuJ3QgdGhlIEVLTSBpbnB1dCBsYWJlbCBhbHJlYWR5IGRvIHRoYXQ/DQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMsIGl0IGRvZXMsIGJ1dCBz byBsb25nIGFzIGl0IGRvZXMgbm90IGNhdXNlIHRoZSBkYXRhIHRvIHRha2UgdXAgYW5vdGhlciAz Mi1ieXRlIGJsb2NrLCBJJ20gT0sgd2l0aCBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvLCBJJ20gT0sgd2l0aCB0aGUgLTA5IHZl cnNpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5CaWxsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR0301MB0842C86FDBAB0FB532B2362E8CE30CY1PR0301MB0842_-- From nobody Wed Aug 31 15:08:40 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 EF85312D0B4 for ; Wed, 31 Aug 2016 15:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 XroyFSGjLtVc for ; Wed, 31 Aug 2016 15:08:36 -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 8E58712D0AE for ; Wed, 31 Aug 2016 15:08:35 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id z190so66745606qkc.0 for ; Wed, 31 Aug 2016 15:08:35 -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:message-id:references :to; bh=w1y5T3Tb9+eqJamzwfjDe5dMbDw8PPfUUMu82qsha7o=; b=bHmaoOZNdN63zAiOjhxW27pFuPydosroivhHIQWl4AhYmjaFvsD7F6P4o3yyv8WnaP 5jfo57+i0nbEvdcX1nWiakrxPA3wQb2yHsdcQ5nN88JQ59M5QpwQggawC9Ob4oZZfl7m JDSdYbmtotYZAy6rPTpLvotK6LKdWqCVW6Zn3yoHj5RcA2f5r8XPM0Qk42MEzUFdFZQs cXQwAIry37Lm48r9djCTbu5amaqUr0VPdk0wGv8Ci3NBWxV34l+JxMDYddCof/b9lswl Cy4xZhp1XdzyaQdzKkr22TtORXMTBK2RV8bL7k+JVLZ6cGD/nXGVFNok3qv2naV1hnaP xwJg== 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 :message-id:references:to; bh=w1y5T3Tb9+eqJamzwfjDe5dMbDw8PPfUUMu82qsha7o=; b=cIzgLo+1Rgxs3NbGBlnGgY5iPFFf5oacCPUWkoLm7efUt1kAMPQSs1yLx9Y+kO7Vxh FloglKuunhNS86N7+AcuKpy/zpPWe3yXysjI6X1/aQE5VdXZtPTxVw1YZjo/DNFtZJ5Z K+2jjV+xlJl9GFc9ur9SpmPScLYsIKG4dXIrUzX/AByqy9cnG+mhQd9LRLLbugoS4oOs Gvv1HCXetFHw/29MVnuktau2bt5pYTCgQZ1B1+bm5kknZSR0fBEkDGW0/YaMGg2w5PTh QE6haT8qcRlSf2kfrVCHWdsnbuC1o2jOgQJJ4j2msB2sds0vjt++000AP2t0jeqhaaSc ++1g== X-Gm-Message-State: AE9vXwNPDx0QLKAemPdE+93KRCZuEG/mSPnLaOwW+S17EuweHOB5ig72j5egg8CFrOc9eJnL X-Received: by 10.55.145.197 with SMTP id t188mr14174986qkd.172.1472681314913; Wed, 31 Aug 2016 15:08:34 -0700 (PDT) Received: from [192.168.1.36] ([191.115.1.17]) by smtp.gmail.com with ESMTPSA id p2sm1130291qta.15.2016.08.31.15.08.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 31 Aug 2016 15:08:33 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_214F6342-772E-48EB-90DC-FEE64C7DE104" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: John Bradley In-Reply-To: Date: Wed, 31 Aug 2016 19:08:22 -0300 Message-Id: <4F42DDB0-1BBB-43E7-A5AB-7B70C756A3CD@ve7jtb.com> References: To: Dirk Balfanz X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Andrei Popov , Tokbind WG Subject: Re: [Unbearable] Opaqueness of Token Binding ID 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, 31 Aug 2016 22:08:39 -0000 --Apple-Mail=_214F6342-772E-48EB-90DC-FEE64C7DE104 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I personally think that for fido treating the token bindingID as opaque = is the correct thing. It will keep the fido clients from breaking when = new token binding algs are added. If the server wants to introspect the key for some reason it can do = that, but in general they should be opaque. John B. > On Aug 31, 2016, at 2:54 PM, Dirk Balfanz wrote: >=20 > Hi Andrei & the rest of the Unbearables,=20 >=20 > in the FIDO (well, W3C webauthn) discussion the question came up = whether Token Binding IDs should be treated as opaque blobs in other = protocols. In particular, FIDO assertions are (in part) over Token = Binding IDs. >=20 > I had originally spec'd this out as including a JWK representation of = the Token Binding key, as in: >=20 > // The FIDO signature is over this: > { > "origin": "www.example.com ", > "challenge": "129843adj03948", > "tokbind": { > "kty":"EC",=09 > "crv":"P-256", > "x":"HzQwlfXX7Q4S5MtCRMzPO9tOyWjBqRl4tJ8", > "y":"XVguGFLIZx1fXg375hi4-7-BxhMljw42Ht4" > } > } >=20 > The webauthn participants are pointing out that the latest Token = Binding spec says that other applications should use an opaque = representation of the Token Binding ID, as in: >=20 > // The FIDO signature is over this: > { > "origin": "www.example.com ", > "challenge": "129843adj03948", > "tokbind": "KJDSW34AAJSjasAKJsha-ISajj8sJSA..." > } >=20 > where the tokbind value would be the base64-enccoding of the = TokenBindingID, as specified in ietf-tokbind-protocol.=20 >=20 > It seems to me that it is safer to explicitly surface the fact that = the Token Binding ID is a public key, and what kind of key it is, to = other applications, rather than asking them to string-compare two = strings whose semantics they don't understand.=20 >=20 > I can't come up with a particular attack, since the Token Binding ID - = just like the JWK - is an unambiguous representation of they key. = Furthermore, since it is a canonical serialization, string comparison = *should* be ok. >=20 > It seems strange, however, that the application (in this case = webauthn) shouldn't be aware of the precise semantics of the tokbind = value in this dictionary.=20 >=20 > Any thoughts on this? >=20 > Dirk. >=20 > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable --Apple-Mail=_214F6342-772E-48EB-90DC-FEE64C7DE104 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I personally think that for fido treating the token bindingID = as opaque is the correct thing.  It will keep the fido clients from = breaking when new token binding algs are added.

If the server wants to introspect the = key for some reason it can do that, but in general they should be = opaque.

John = B.

On Aug 31, 2016, at 2:54 PM, = Dirk Balfanz <balfanz@google.com> wrote:

Hi Andrei & the rest of the Unbearables, 

in the FIDO (well, W3C = webauthn) discussion the question came up whether Token Binding IDs = should be treated as opaque blobs in other protocols. In particular, = FIDO assertions are (in part) over Token Binding IDs.

I had originally spec'd = this out as including a JWK representation of the Token Binding key, as = in:

// The FIDO signature is over = this:
{  "origin": "www.example.com",
  "challenge": = "129843adj03948",
  "tokbind": {
    "kty":"EC",
    = "crv":"P-256",
    = "x":"HzQwlfXX7Q4S5MtCRMzPO9tOyWjBqRl4tJ8",
    = "y":"XVguGFLIZx1fXg375hi4-7-BxhMljw42Ht4"
  }
}

The webauthn participants are pointing out that the latest = Token Binding spec says that other applications should use an opaque = representation of the Token Binding ID, as in:

// The FIDO signature is over this:
{
  = "origin": "www.example.com",
  "challenge": = "129843adj03948",
  "tokbind": = "KJDSW34AAJSjasAKJsha-ISajj8sJSA..."
}

where the tokbind value would be the base64-enccoding of the = TokenBindingID, as specified = in ietf-tokbind-protocol. 

It seems to me that it is safer to = explicitly surface the fact that the Token Binding ID is a public key, = and what kind of key it is, to other applications, rather than asking = them to string-compare two strings whose semantics they don't = understand. 

I can't come up with a particular attack, since the Token = Binding ID - just like the JWK - is an unambiguous representation of = they key. Furthermore, since it is a canonical serialization, string = comparison *should* be ok.

It seems strange, however, that the application (in this case = webauthn) shouldn't be aware of the precise semantics of the tokbind = value in this dictionary. 

Any thoughts on this?

Dirk.

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

= --Apple-Mail=_214F6342-772E-48EB-90DC-FEE64C7DE104-- From nobody Wed Aug 31 15:20:57 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 F0CF312D0B4 for ; Wed, 31 Aug 2016 15:20:55 -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 q-OOZYV5FVge for ; Wed, 31 Aug 2016 15:20:53 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0126.outbound.protection.outlook.com [104.47.37.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B5D12D743 for ; Wed, 31 Aug 2016 15:20:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hl4sfGB4Ht7Dr9X5UJxguC1/HBFNl0jee0c0GhQ8eyA=; b=DByNE8jF9ml3xDvVJOAUya2HFxTAcMmF4WQPljpAzc5HTfD1CyUNl5i8OlA6ZDEZGIKy70DscAfxwMW4PR8m3rCG4x6ma1LR44FDwrb9nE4mWQM8QJ84LbMyfZ3iFY/eVK6ejjaKjI3ygqQwhoOL1D8VqaAUHTTxC2YJQAwmS1w= Received: from SN1PR0301MB2029.namprd03.prod.outlook.com (10.163.226.27) by CY1PR0301MB0841.namprd03.prod.outlook.com (10.160.163.147) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Wed, 31 Aug 2016 22:20:50 +0000 Received: from SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) by SN1PR0301MB2029.namprd03.prod.outlook.com ([10.163.226.27]) with mapi id 15.01.0587.013; Wed, 31 Aug 2016 22:20:48 +0000 From: Anthony Nadalin To: John Bradley , Dirk Balfanz Thread-Topic: [Unbearable] Opaqueness of Token Binding ID Thread-Index: AQHSA7C5+pX2Ji/eB0eNK1SfbjWse6BjoP4AgAADIzA= Date: Wed, 31 Aug 2016 22:20:48 +0000 Message-ID: References: <4F42DDB0-1BBB-43E7-A5AB-7B70C756A3CD@ve7jtb.com> In-Reply-To: <4F42DDB0-1BBB-43E7-A5AB-7B70C756A3CD@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tonynad@microsoft.com; x-originating-ip: [131.107.174.46] x-ms-office365-filtering-correlation-id: 045a6b29-06c0-4749-ad0f-08d3d1ed0f8c x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 6:DvuHgWqTF5cdF8MH80GtWskYnXaZ0JnpJMy0at/Z6IGSLHaLReoaXDMbKB9iWplJmodNx0FMMLqOkJNVQqPo8eZ0MKFK2HjxVaHVywdHdz26Lt7EW5Ci/NQ2sUl9BGY47fNIkRFPjJtHBaxa2iM7TioU73gK2hQkSEl67UmqKzbvCxHzQsphtv0CCz63KrqunFirxcVs1sOHovGytJMXLcKxeJ8yer0qavk0Z7yzwp4Meh0YAWVtMtfvUcYAIdmW6NPFgq/yP3bL0RxZQkzE7VIqrfQuOoGOz6SZefOe2PlFZwWYV/QqGfdBc/ts+IF1SR8oRPukVC65ECjndR24FQ==; 5:n1h6kJxzKn9d0FaI18NASDitylDqEu0H97abTeoflS+rofHTHxG1AzzB+LKU8keVpN2lDayfsIbJUO0z87niqQJ+cpkqqS0c0yqRnMIysUFNbkVkhMpKP6NyY2058T0MIfwFsmq/UmNAgkN93Un54w==; 24:Y1Po8MFcupRnr4UCEpDqHG11X3XURDitV5Limed0YzbKbqyhGp5/2skvSikJEyaSY73tI0CxH3UXTlW+dXgCvnOqtRjywQudzCaZIyDHJBc=; 7:kF2ODOhUlYVj030GFAfzTORnVcQb/1+tRLKgw+nK8KgwqhblYFlB1C5wtUfMM2pNU3pBBvCFtXeuk55SM/C8PCEKTgry91dSENx15t678xs/QCxzns3BGrx7OSYAIjjSFN6numGO7apNiHsu3YMZBSvAAYGo24+bKWGFIGZlfROfwVx0/1RSii/5FtNQUU0uH12nE9KRz3VvoLe7bg0EAAgoN9wYPi1715hdGlZ2UDOENlnxilYjUPLe5L26Oco9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0841; x-o365eop-header: O365_EOP: Allow for Unauthenticated Relay x-o365ent-eop-header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(189930954265078)(211936372134217)(219752817060721)(21748063052155)(79290750141951); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(377454003)(478694002)(24454002)(3846002)(7696003)(86612001)(2950100001)(92566002)(2900100001)(33656002)(68736007)(3280700002)(5002640100001)(10400500002)(19609705001)(122556002)(101416001)(5001770100001)(16236675004)(97736004)(4326007)(9686002)(189998001)(81156014)(8936002)(15975445007)(8676002)(7906003)(10290500002)(74316002)(3660700001)(77096005)(7846002)(586003)(87936001)(81166006)(102836003)(76176999)(10090500001)(2906002)(7736002)(8990500004)(5005710100001)(5660300001)(50986999)(19625215002)(54356999)(19580395003)(6116002)(106116001)(66066001)(790700001)(86362001)(105586002)(19617315012)(19580405001)(76576001)(106356001)(19300405004)(99286002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841; H:SN1PR0301MB2029.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB2029BDD493A9ECB390114FA9A6E30SN1PR0301MB2029_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 22:20:48.4851 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0841 Archived-At: Cc: Andrei Popov , Tokbind WG Subject: Re: [Unbearable] Opaqueness of Token Binding ID 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, 31 Aug 2016 22:20:56 -0000 --_000_SN1PR0301MB2029BDD493A9ECB390114FA9A6E30SN1PR0301MB2029_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The Token Binding Key does not have to be the Token Binding ID From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of John Bra= dley Sent: Wednesday, August 31, 2016 3:08 PM To: Dirk Balfanz Cc: Andrei Popov ; Tokbind WG Subject: Re: [Unbearable] Opaqueness of Token Binding ID I personally think that for fido treating the token bindingID as opaque is = the correct thing. It will keep the fido clients from breaking when new to= ken binding algs are added. If the server wants to introspect the key for some reason it can do that, b= ut in general they should be opaque. John B. On Aug 31, 2016, at 2:54 PM, Dirk Balfanz > wrote: Hi Andrei & the rest of the Unbearables, in the FIDO (well, W3C webauthn) discussion the question came up whether To= ken Binding IDs should be treated as opaque blobs in other protocols. In pa= rticular, FIDO assertions are (in part) over Token Binding IDs. I had originally spec'd this out as including a JWK representation of the T= oken Binding key, as in: // The FIDO signature is over this: { "origin": "www.example.com", "challenge": "129843adj03948", "tokbind": { "kty":"EC", "crv":"P-256", "x":"HzQwlfXX7Q4S5MtCRMzPO9tOyWjBqRl4tJ8", "y":"XVguGFLIZx1fXg375hi4-7-BxhMljw42Ht4" } } The webauthn participants are pointing out that the latest Token Binding sp= ec says that other applications should use an opaque representation of the = Token Binding ID, as in: // The FIDO signature is over this: { "origin": "www.example.com", "challenge": "129843adj03948", "tokbind": "KJDSW34AAJSjasAKJsha-ISajj8sJSA..." } where the tokbind value would be the base64-enccoding of the TokenBindingID= , as specified in ietf-tokbind-protocol. It seems to me that it is safer to explicitly surface the fact that the Tok= en Binding ID is a public key, and what kind of key it is, to other applica= tions, rather than asking them to string-compare two strings whose semantic= s they don't understand. I can't come up with a particular attack, since the Token Binding ID - just= like the JWK - is an unambiguous representation of they key. Furthermore, = since it is a canonical serialization, string comparison *should* be ok. It seems strange, however, that the application (in this case webauthn) sho= uldn't be aware of the precise semantics of the tokbind value in this dicti= onary. Any thoughts on this? Dirk. _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable --_000_SN1PR0301MB2029BDD493A9ECB390114FA9A6E30SN1PR0301MB2029_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The Token Binding Key does not have to be the Token= Binding ID

 

From: Unbearable [mailto:unbearable-= bounces@ietf.org] On Behalf Of John Bradley
Sent: Wednesday, August 31, 2016 3:08 PM
To: Dirk Balfanz <balfanz@google.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Tokbind WG <= unbearable@ietf.org>
Subject: Re: [Unbearable] Opaqueness of Token Binding ID<= /span>

 

I personally think that for fido treating the token = bindingID as opaque is the correct thing.  It will keep the fido clien= ts from breaking when new token binding algs are added.

 

If the server wants to introspect the key for some r= eason it can do that, but in general they should be opaque.

 

John B.

 

On Aug 31, 2016, at 2:54 PM, Dirk Balfanz <balfanz@google.com> wrote:

 

Hi Andrei & the rest of the Unbearables, 

 

in the FIDO (well, W3C webauthn) discussion the ques= tion came up whether Token Binding IDs should be treated as opaque blobs in= other protocols. In particular, FIDO assertions are (in part) over Token B= inding IDs.

 

I had originally spec'd this out as including a JWK = representation of the Token Binding key, as in:

 

= // The FIDO signature is over this:

= {
  "origin": "www.example.com",
  "challenge": "129843adj03948",
  "tokbind": {
    "kty":"EC",
    "crv":"P-256",
    "x":"HzQwlfXX7Q4S5MtCRMzPO9tOyWjBqRl4tJ8"= ,
    "y":"XVguGFLIZx1fXg375hi4-7-BxhMljw42Ht4"=
  }
}

 

The webauthn participants are pointing out that the = latest Token Binding spec says that other applications should use an opaque= representation of the Token Binding ID, as in:

 

= // The FIDO signature is over this:

= {
  "origin": "www.example.com",
  "challenge": "129843adj03948",
  "tokbind": "KJDSW34AAJSjasAKJsha-ISajj8sJSA..."<= br> }

 

where the tokbind value would be the base64-enccodin= g of the TokenBindingID, as specified in ietf-tokbind-protocol. <= o:p>

 

It seems to me that it is safer to explicitly surfac= e the fact that the Token Binding ID is a public key, and what kind of key = it is, to other applications, rather than asking them to string-compare two= strings whose semantics they don't understand. 

 

I can't come up with a particular attack, since the = Token Binding ID - just like the JWK - is an unambiguous representation of = they key. Furthermore, since it is a canonical serialization, string compar= ison *should* be ok.

 

It seems strange, however, that the application (in = this case webauthn) shouldn't be aware of the precise semantics of the tokb= ind value in this dictionary. 

 

Any thoughts on this?

 

Dirk.

 

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

 

--_000_SN1PR0301MB2029BDD493A9ECB390114FA9A6E30SN1PR0301MB2029_-- From nobody Wed Aug 31 15:21: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 3E6AE12D0B4 for ; Wed, 31 Aug 2016 15:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 T-OYcx37gd2k for ; Wed, 31 Aug 2016 15:21:19 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0138.outbound.protection.outlook.com [104.47.36.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF8012D777 for ; Wed, 31 Aug 2016 15:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vt/0NdKP5OHpHLS4PTjMI7sF0SY9nMRjqr+JXIrtUgA=; b=dQEHTDRffGrwCMKdNxR7nwm4oNP3NKoRsjTFGwnv2fs/ShgoUNOMnIrGN5XjN4Ck9A/AdzRGTRqft7ybhC/JFNBuZiFqshqFqCK06s9yx9W0mUCNeV/jbmBDDIZuW0LXQDJsTbtvKCa0Z/ayZX62OQj1K/qKm4pgbxKaDFvhDjQ= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0844.namprd03.prod.outlook.com (10.160.163.150) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.13; Wed, 31 Aug 2016 22:21:15 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Wed, 31 Aug 2016 22:21:16 +0000 From: Andrei Popov To: John Bradley , Dirk Balfanz Thread-Topic: [Unbearable] Opaqueness of Token Binding ID Thread-Index: AQHSA7C1QN5Po5xpx0Wbvq3ilbKBZaBjoP4AgAADexA= Date: Wed, 31 Aug 2016 22:21:16 +0000 Message-ID: References: <4F42DDB0-1BBB-43E7-A5AB-7B70C756A3CD@ve7jtb.com> In-Reply-To: <4F42DDB0-1BBB-43E7-A5AB-7B70C756A3CD@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: da86ca44-4998-45cd-efac-08d3d1ed1fe6 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0844; 6:DzifBz4WC42kvVTmydK4RTz5oR8sVV7OHgGYciboFMT6t/EPnRO8kOnTG0En8YBaITAMkO4GcKu2lzmXLzb5kHGGhUWngFcjiioSram588ga/ot/7vLL3eM1pRWgSSCIrVAxGgKrJVwQqaePHdfD9ZFEkirnyuF5oLilTkDDqhN8C5Fqsw3doikcZ3SbBI0N26SMd30nMuC/U+PtPPl/o5sdsPKqBk7c2ns9a6uj/62Y9HEKf2N4/ocKTnqy2y/OcZAqSFXd6vZyk2Z8M70YGy1dh7t7ZZS8sZVK7+9Wh88wBHabnurrWYtbALoESnO/puWajWf2fr6AcyI+TDpgvw==; 5:4Gxsi99jbdEdy4sAMXIcAIm1ZL/jeYE4Dkv/i2FVFP0KDEqfu4uJqCp7d7tHXTMmf3aSOV9tmSu0VTkXFbdxZAgpGUoNsoNmkjMV5mHjm6AGTooc9OlRrrZRNe7wgZDCr1vZJzSh+6+5G5NjG6PdnQ==; 24:+IvliLlvLFHeW+qtQMAsORNcsHclOkKLlazxbarByGl1dnVMY8yYtuC24dVt7UcGD0K2zOqVD4vVAtMiq0+UpaCK72LinXvColI31E1tsr0=; 7:pX+6lZdaa9OYRQBc6G02H4fYoDJxDeeJ4qL/i9pdojldqjpi9lD0YtBY/A1lg9yAeqpcRRlScvJrTWzzLsIfGlWv8RvS2FOtpcE3hN3eTm/Ycj3iAJHKvgwIdsxGwLFmvgkmfn9NBe9xbjABX5353PPH1IAtWErndymh8PzyzoziVPevxtpZfnFrohLymCZ4R6u+D2+Nc2aD4LBaNqTbQihqUfGqsGka3Na5wJkTIeueCmkb2mOQUp8DPf8meWjA x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0844; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(211936372134217)(21748063052155)(79290750141951); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0844; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0844; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(199003)(24454002)(478694002)(9686002)(3280700002)(8936002)(19609705001)(86362001)(76576001)(106356001)(10400500002)(19580395003)(87936001)(586003)(33656002)(16236675004)(2950100001)(2900100001)(5005710100001)(102836003)(10290500002)(6116002)(86612001)(8990500004)(76176999)(5002640100001)(7736002)(92566002)(54356999)(68736007)(7906003)(7696003)(3660700001)(4326007)(122556002)(790700001)(99286002)(106116001)(50986999)(97736004)(105586002)(74316002)(7846002)(5001770100001)(101416001)(19625215002)(8676002)(2906002)(15975445007)(5660300001)(19300405004)(81156014)(10090500001)(189998001)(19617315012)(81166006)(77096005)(19580405001)(1680700002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0844; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB084212A7DB0B740A4AD75CCA8CE30CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 22:21:16.1073 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0844 Archived-At: Cc: Tokbind WG Subject: Re: [Unbearable] Opaqueness of Token Binding ID 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, 31 Aug 2016 22:21:21 -0000 --_000_CY1PR0301MB084212A7DB0B740A4AD75CCA8CE30CY1PR0301MB0842_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1, to avoid coupling of apps to TB versions. From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Wednesday, August 31, 2016 3:08 PM To: Dirk Balfanz Cc: Andrei Popov ; Tokbind WG Subject: Re: [Unbearable] Opaqueness of Token Binding ID I personally think that for fido treating the token bindingID as opaque is = the correct thing. It will keep the fido clients from breaking when new to= ken binding algs are added. If the server wants to introspect the key for some reason it can do that, b= ut in general they should be opaque. John B. On Aug 31, 2016, at 2:54 PM, Dirk Balfanz > wrote: Hi Andrei & the rest of the Unbearables, in the FIDO (well, W3C webauthn) discussion the question came up whether To= ken Binding IDs should be treated as opaque blobs in other protocols. In pa= rticular, FIDO assertions are (in part) over Token Binding IDs. I had originally spec'd this out as including a JWK representation of the T= oken Binding key, as in: // The FIDO signature is over this: { "origin": "www.example.com", "challenge": "129843adj03948", "tokbind": { "kty":"EC", "crv":"P-256", "x":"HzQwlfXX7Q4S5MtCRMzPO9tOyWjBqRl4tJ8", "y":"XVguGFLIZx1fXg375hi4-7-BxhMljw42Ht4" } } The webauthn participants are pointing out that the latest Token Binding sp= ec says that other applications should use an opaque representation of the = Token Binding ID, as in: // The FIDO signature is over this: { "origin": "www.example.com", "challenge": "129843adj03948", "tokbind": "KJDSW34AAJSjasAKJsha-ISajj8sJSA..." } where the tokbind value would be the base64-enccoding of the TokenBindingID= , as specified in ietf-tokbind-protocol. It seems to me that it is safer to explicitly surface the fact that the Tok= en Binding ID is a public key, and what kind of key it is, to other applica= tions, rather than asking them to string-compare two strings whose semantic= s they don't understand. I can't come up with a particular attack, since the Token Binding ID - just= like the JWK - is an unambiguous representation of they key. Furthermore, = since it is a canonical serialization, string comparison *should* be ok. It seems strange, however, that the application (in this case webauthn) sho= uldn't be aware of the precise semantics of the tokbind value in this dicti= onary. Any thoughts on this? Dirk. _______________________________________________ Unbearable mailing list Unbearable@ietf.org https://www.ietf.org/mailman/listinfo/unbearable --_000_CY1PR0301MB084212A7DB0B740A4AD75CCA8CE30CY1PR0301MB0842_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1, to avoid coupling of apps to TB versions.

 

From: John Bradley [mailto:ve7jtb@ve= 7jtb.com]
Sent: Wednesday, August 31, 2016 3:08 PM
To: Dirk Balfanz <balfanz@google.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Tokbind WG <= unbearable@ietf.org>
Subject: Re: [Unbearable] Opaqueness of Token Binding ID<= /span>

 

I personally think that for fido treating the token = bindingID as opaque is the correct thing.  It will keep the fido clien= ts from breaking when new token binding algs are added.

 

If the server wants to introspect the key for some r= eason it can do that, but in general they should be opaque.

 

John B.

 

On Aug 31, 2016, at 2:54 PM, Dirk Balfanz <balfanz@google.com> wrote:

 

Hi Andrei & the rest of the Unbearables, 

 

in the FIDO (well, W3C webauthn) discussion the ques= tion came up whether Token Binding IDs should be treated as opaque blobs in= other protocols. In particular, FIDO assertions are (in part) over Token B= inding IDs.

 

I had originally spec'd this out as including a JWK = representation of the Token Binding key, as in:

 

= // The FIDO signature is over this:

= {
  "origin": "www.ex= ample.com",
  "challenge": "129843adj03948",
  "tokbind": {
    "kty":"EC",
    "crv":"P-256",
    "x":"HzQwlfXX7Q4S5MtCRMzPO9tOyWjBqRl4tJ8"= ,
    "y":"XVguGFLIZx1fXg375hi4-7-BxhMljw42Ht4"=
  }
}

 

The webauthn participants are pointing out that the = latest Token Binding spec says that other applications should use an opaque= representation of the Token Binding ID, as in:

 

= // The FIDO signature is over this:

= {
  "origin": "www.ex= ample.com",
  "challenge": "129843adj03948",
  "tokbind": "KJDSW34AAJSjasAKJsha-ISajj8sJSA..."<= br> }

 

where the tokbind value would be the base64-enccodin= g of the TokenBindingID, as specified in ietf-tokbind-protocol. <= o:p>

 

It seems to me that it is safer to explicitly surfac= e the fact that the Token Binding ID is a public key, and what kind of key = it is, to other applications, rather than asking them to string-compare two= strings whose semantics they don't understand. 

 

I can't come up with a particular attack, since the = Token Binding ID - just like the JWK - is an unambiguous representation of = they key. Furthermore, since it is a canonical serialization, string compar= ison *should* be ok.

 

It seems strange, however, that the application (in = this case webauthn) shouldn't be aware of the precise semantics of the tokb= ind value in this dictionary. 

 

Any thoughts on this?

 

Dirk.

 

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

 

--_000_CY1PR0301MB084212A7DB0B740A4AD75CCA8CE30CY1PR0301MB0842_-- From nobody Wed Aug 31 15:24: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 CFDF212D0B4 for ; Wed, 31 Aug 2016 15:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 jbXNzVtidNyC for ; Wed, 31 Aug 2016 15:24:23 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0112.outbound.protection.outlook.com [104.47.37.112]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C642B12D76A for ; Wed, 31 Aug 2016 15:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cOwU3BWx525m6z5O+S3bxvUSK2DNpAOaDktwpJij9HE=; b=nArxGWOIi0K9G5fYs3LIizqJsfh3DPsIxI8qZVJ8nw3M2MkO4AeRnzmhSaXVPOAtx4eiMfp5WVK1GtBp5HSdza2bKM5UIkmNrzkelUBB4yYzgSUt+thZ9TA970YMRglk4c9JjkzJnVKxb/vDSKgtoDkxVMaCwNr1byHD5aSITCc= Received: from DM2PR0301MB0637.namprd03.prod.outlook.com (10.160.96.11) by DM2PR0301MB0845.namprd03.prod.outlook.com (10.160.215.143) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Wed, 31 Aug 2016 22:24:05 +0000 Received: from DM2PR0301MB0637.namprd03.prod.outlook.com ([10.160.96.11]) by DM2PR0301MB0637.namprd03.prod.outlook.com ([10.160.96.11]) with mapi id 15.01.0599.010; Wed, 31 Aug 2016 22:24:04 +0000 From: Mike Jones To: Andrei Popov , Bill Cox , Brian Campbell Thread-Topic: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) Thread-Index: AdIDzYe/nNN4QigzR4G2nIa8+fQ4XAACHYhA Date: Wed, 31 Aug 2016 22:24:03 +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: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.91.120] x-ms-office365-filtering-correlation-id: cb959614-8b6d-46db-7121-08d3d1ed8413 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0845; 6:6epBslo+OUYeVqgrTZMmRazRAUQ7/18O6BrjD7tp61rW/sAlu9EJ3KNLScX6qh99xxwdYF7UL/zQe7TFqz9LG5enVF2ZqAKUhSeoFeC5P8UknbJ7U0+9qATGRh7vJNU4s6bKM32X4upYNgHOYQ+nS5l3kwPIV/ueuEmqe2H3jOD0lG4cxMtitQEbTk0DAW2H6JzxPwsiSMhZW6+OsWUm+6zaucc9aB3HIl2n9pTFkA2pkRqlr8urqZEyedZ1HzpzNNcVK6RwLOT/4jWLOaldndCimHTXHgGcV3nsAi2N+0996O0cj8vKDSDZcxhtNXZIaUFwKejJKBfq1HGanpJecg==; 5:V8YTMPJx8O1s3SyFffZ8Ztncqd7XBVnxF0rJ4JSHAJXg2ZDLO4KOIpKfoGb6VIKjnDyOkzeeIiVU/DETc5yocJYiOD75Ksmz1OxCXZGwKEHChX1jz59lLiRFpOvVU8IFdS4W8PxLxWC9Orn05A/iMw==; 24:CRjUPaZcdkBL8CIlKLPVACsWJM/HxuMBoDBI6o30laoRnPiuP9XUZAu4Cx5UPonmYFVKNI+SLwBkzIFRN80AYY7SZp9bUsEKl03XefRoBDc=; 7:tlwMNMEuEd+SFm2dV9B1CeMA2BaiNNZjJusC6FG58ionrx7NPJE3o1mClRHS2JQN4zfQ8DrM8cNbEodAXFWAb3vqfF2476sdgLEcpYdZ+TnufX3cqkTB38VS/lePs7X7OSPFMfzW0vSxtdJi4YrptE5Ak69QsEesN/HwU/ep78Ei5S4F2Vcwg+q4W1o1ajyHrfXWO5OyG6fkneEf2lMzmOIQJSPH3+SH44FdNGVOqGSLpKQhvBISi6z8gCMqGmLS x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0845; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0845; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0845; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(24454002)(189002)(52314003)(377454003)(51444003)(74316002)(105586002)(189998001)(19580395003)(92566002)(68736007)(10090500001)(2421001)(8936002)(81156014)(15975445007)(19300405004)(5660300001)(19580405001)(2900100001)(19609705001)(2950100001)(2561002)(5001770100001)(8990500004)(77096005)(81166006)(97736004)(8676002)(7696003)(76576001)(790700001)(6116002)(9686002)(7906003)(7846002)(2906002)(102836003)(3846002)(7736002)(87936001)(3660700001)(4326007)(5002640100001)(86612001)(86362001)(66066001)(3280700002)(122556002)(16236675004)(33656002)(101416001)(19625215002)(1511001)(54356999)(19617315012)(10290500002)(106356001)(76176999)(99286002)(586003)(50986999)(5005710100001)(10400500002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0845; H:DM2PR0301MB0637.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR0301MB0637565EA42BEE89BFA82179F5E30DM2PR0301MB0637_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 22:24:03.9560 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0845 Archived-At: Cc: Tokbind WG , Leif Johansson Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) 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, 31 Aug 2016 22:24:27 -0000 --_000_DM2PR0301MB0637565EA42BEE89BFA82179F5E30DM2PR0301MB0637_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXJlIGFsbCB0aGUgZmllbGRzIHdl4oCZcmUgY29uY2F0ZW5hdGluZyBmaXhlZCBsZW5ndGg/ICBJ IGFzayBiZWNhdXNlIGEgc3RhbmRhcmQga2luZCBvZiBhdHRhY2sgYWdhaW5zdCBjcnlwdG8gc3lz dGVtcyB1c2luZyBjb25jYXRlbmF0aW9uIGlzIHRvIG1ha2UgaXQgYXBwZWFyIHRoYXQgZGF0YSBm cm9tIG9uZSBmaWVsZCBiZWxvbmdzIGluIGFub3RoZXIgb25lIGJ5IHVzaW5nIGRpZmZlcmVudCBm aWVsZCBsZW5ndGhzLiAgSWYgdGhleSBhcmVu4oCZdCBmaXhlZCBsZW5ndGgsIGluY2x1ZGluZyBm aWVsZCBsZW5ndGggY291bnRzIG9yIGZpZWxkIGRlbGltaXRlcnMgaW4gdGhlIGNvbmNhdGVuYXRp b24gaXMgYSBzdGFuZGFyZCBzb2x1dGlvbiB0byB0aGUgcHJvYmxlbS4NCg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJv bTogVW5iZWFyYWJsZSBbbWFpbHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEFuZHJlaSBQb3Bvdg0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYgMjoy MSBQTQ0KVG86IEJpbGwgQ294IDx3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPjsgQnJpYW4gQ2FtcGJl bGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPg0KQ2M6IFRva2JpbmQgV0cgPHVuYmVhcmFi bGVAaWV0Zi5vcmc+OyBMZWlmIEpvaGFuc3NvbiA8bGVpZmpAc3VuZXQuc2U+DQpTdWJqZWN0OiBS ZTogW1VuYmVhcmFibGVdIFdoYXQgR2V0cyBTaWduZWQgKHdhczogRHVtYiBpZGVhOiBhZGQgRWQy NTUxOSBzdXBwb3J0PykNCg0KVG8gc3VtIHVwLCBhcmUgd2UgaW4gYWdyZWVtZW50IHRoYXQgdGhl IGNvbmNhdGVuYXRpb24gd2lsbCBvbmx5IGluY2x1ZGU6DQoNCg0KLSAgICAgICAgICBUb2tlbkJp bmRpbmdUeXBlIHZhbHVlIGNvbnRhaW5lZCBpbiB0aGUNCiAgICAgIFRva2VuQmluZGluZy50b2tl bmJpbmRpbmdfdHlwZSBmaWVsZDsNCg0KLSAgICAgICAgICBUb2tlbkJpbmRpbmdLZXlQYXJhbWV0 ZXJzIHZhbHVlIGNvbnRhaW5lZCBpbiB0aGUNCiAgICAgIFRva2VuQmluZGluZ0lELmtleV9wYXJh bWV0ZXJzIGZpZWxkOw0KDQotICAgICAgICAgIEV4cG9ydGVkIGtleWluZyBtYXRlcmlhbCAoRUtN KSB2YWx1ZSBvYnRhaW5lZCBmcm9tIHRoZSBjdXJyZW50IFRMUw0KICAgICAgY29ubmVjdGlvbi4N CuKApiBiZWNhdXNlIHRoZSBsYWJlbCBhbmQgdGhlIFByb3RvY29sVmVyc2lvbiBhcmUgcHJlc3Vt YWJseSBhbHJlYWR5IGluIHRoZSBFS00/DQoNCkZyb206IEJpbGwgQ294IFttYWlsdG86d2F5d2Fy ZGdlZWtAZ29vZ2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDMxLCAyMDE2IDI6MDEg UE0NClRvOiBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRv OmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4NCkNjOiBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Q b3BvdkBtaWNyb3NvZnQuY29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+OyBU b2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzp1bmJlYXJhYmxlQGlldGYub3Jn Pj47IExlaWYgSm9oYW5zc29uIDxsZWlmakBzdW5ldC5zZTxtYWlsdG86bGVpZmpAc3VuZXQuc2U+ Pg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBv cnQ/DQoNCk9uIFdlZCwgQXVnIDMxLCAyMDE2IGF0IDE6MTAgUE0sIEJyaWFuIENhbXBiZWxsIDxi Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j b20+PiB3cm90ZToNCg0KT24gV2VkLCBBdWcgMzEsIDIwMTYgYXQgMTozNSBQTSwgQmlsbCBDb3gg PHdheXdhcmRnZWVrQGdvb2dsZS5jb208bWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb20+PiB3 cm90ZToNCk9uIFdlZCwgQXVnIDMxLCAyMDE2IGF0IDEyOjEyIFBNLCBCcmlhbiBDYW1wYmVsbCA8 YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHku Y29tPj4gd3JvdGU6DQpJbiB3aGljaCBjYXNlIEknZCBhZ2FpbiBzdWdnZXN0IHRoYXQgdGhlIHNp Z25hdHVyZSBpbnB1dCBiZSB0aGUgY29uY2F0ZW5hdGVkIGl0ZW1zIGRpcmVjdGx5IChubyBoYXNo KSBhbmQgdGhhdCBoYXNoaW5nIG9yIG5vdCBiZSBwYXJ0IG9mIHRoZSBzaWduYXR1cmUgc2NoZW1l IGFzc29jaWF0ZWQgd2l0aCBlYWNoIGtleSBwYXJhbWV0ZXJzIHR5cGUuDQoNClNvdW5kcyBnb29k IHRvIG1lLiAgSXQgZml0cyB0aGUgc3RhbmRhcmQgQVBJcyBhIGJpdCBiZXR0ZXIuICBJSVVDLCB0 aGlzIHJlc3VsdCBpcyB0aGUgc2FtZSBlaXRoZXIgd2F5LCBzbyB0aGlzIGlzIHJlYWxseSBqdXN0 IGEgbWF0dGVyIG9mIGhvdyB3ZSBkZXNjcmliZSBpdCwgcmlnaHQ/DQoNCg0KQWZ0ZXIgcGxheWlu ZyBhcm91bmQgd2l0aCBzb21lIEFQSXMgeWVzdGVyZGF5LCBJIGRvbid0IHRoaW5rIHRoYXQgdGhl IHJlc3VsdCBpcyBhY3R1YWxseSB0aGUgc2FtZS4gQXQgbGVhc3QgYXMgZmFyIGFzIHRoZSBhY3R1 YWwgYnl0ZXMgb2YgdGhlIHNpZ25hdHVyZS4gQ29uY2VwdHVhbGx5IHRoZSBpZGVhIGlzIHRoZSBz YW1lIHRob3VnaCwgQUZBSUssIGFuZCBtb3ZpbmcgdGhlIGhhc2ggZGVmaW5pdGlvbiB0byB0aGUg c2lnbmF0dXJlIHNjaGVtZSBhc3NvY2lhdGVkIHdpdGggZWFjaCBrZXkgcGFyYW1ldGVycyB0eXBl IHJlbW92ZXMgYSBoYXJkd2lyZWQgZGVwZW5kZW5jeSBvbiBTSEEyNTYgYW5kIGFsc28gZWxpbWlu YXRlcyBhIHJvdW5kIG9mIGhhc2hpbmcgZm9yIHRoZSBSU0Ega2V5IHBhcmFtZXRlcnMgdHlwZXMu DQoNClRoZSBPcGVuU1NMIHNpZ25pbmcgQVBJcyBhcmUgZmluaWNreS4gIFRoZXkgcmVhbGx5IHdh bnQgdG8gZG8gYSBkaWdlc3QsIGFuZCB5b3UgaGF2ZSB0byBrbm93IGhvdyB0byBjYWxsIHRoZW0g anVzdCByaWdodCB0byBzaWduIHRoZSBkaWdlc3QsIHJhdGhlciB0aGFuIHRoZSBoYXNoIG9mIHRo ZSBkaWdlc3QuICBIb3dldmVyLCBhdCBvbmUgcG9pbnQsIEkgd2FzIGFibGUgdG8gdmVyaWZ5IHRo YXQgYm90aCB3YXlzIGdpdmUgdGhlIHNhbWUgcmVzdWx0LiAgSSBhY3R1YWxseSB1c2UgdGhlIG5v cm1hbCBBUElzIG5vdyB0aGF0IGRvIHRoZSBTSEEyNTYgd2hpbGUgc2lnbmluZy4gIEkgZG8gbm90 IHRoaW5rIHRoaXMgcmVxdWlyZXMgYSBkb2N1bWVudCBjaGFuZ2UsIG90aGVyIHRoYW4gcGVyaGFw cyBzb21lIGNsYXJpZmljYXRpb24uDQoNCkFjY29yZGluZyB0byB0aGUgRUtNIHNwZWMgKGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzA1KSwgYSBkaXNhbWJpZ3VhdGluZyBsYWJlbCBp cyByZXF1aXJlZCwgYW5kIHdlJ3JlIGFsc28gc3VwcG9zZWQgdG8gcmVnaXN0ZXIgaXQgc28gdGhl cmUgYXJlIG5vIG5hbWUgY29sbGlzaW9ucy4gIElzIHRoaXMgc29tZXRoaW5nIHdlIG5lZWQgdG8g d29ycnkgYWJvdXQ/DQoNCkkgdGhpbmsgdGhhdCdzIGFscmVhZHkgKG9yIHdpbGwgYmUpIGNvdmVy ZWQgd2l0aCB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QgZm9yICJFWFBPUlRFUi1Ub2tlbi1CaW5k aW5nIiBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10b2tiaW5kLXBy b3RvY29sLTA5I3NlY3Rpb24tNi40DQoNCk9LLCBncmVhdC4gIEluIHRoYXQgY2FzZSwgYWRkaW5n ICJUb2tlbiBCaW5kaW5nIiBpcyByZWR1bmRhbnQsIGJ1dCBzaW5jZSB3ZSB1c2UgYSAzMi1ieXRl IGJsb2NrIGhhc2ggYW55d2F5LCBJIGRvbid0IHRoaW5rIGl0IHdpbGwgbWFrZSBhbnkgZGlmZmVy ZW5jZSBpbnMgc3BlZWQsIG90aGVyIHRoYW4gdGhlIGNvc3Qgb2YgY29weWluZyB0aGUgZGF0YS4N Cg0KRm9yIHNvbWUgcmVhc29uLCBJIHRob3VnaHQgd2UgaGFkIGFscmVhZHkgcmVnaXN0ZXJlZCAi VG9rZW4gQmluZGluZyIgYXMgYSB1bmlxdWUgRUtNIGxhYmVsLiAgSWYgc28sIHdlIHNob3VsZCBw cm9iYWJseSBwYXNzIHRoZSBsYWJlbCB0byB0aGUgRUtNIGVpdGhlciBpbiBhZGRpdGlvbiB0bywg b3IgaW5zdGVhZCBvZiwgaGFzaGluZyBpdCBpbiB0aGUgZmluYWwgaGFzaC4NCg0KSSBtYXkgaGF2 ZSBjb25mdXNlZCB0aGluZ3MgYnkgdXNpbmcgdGhlIHRlcm0gbGFiZWwgZm9yIHRoZSBBU0NJSSBz dHJpbmcgIlRva2VuIEJpbmRpbmciIHRoYXQncyBwYXJ0IG9mIHRoZSBjb25jYXRlbmF0aW9uIG9m IHRoaW5ncy4gSXQncyBub3QgYSBsYWJlbCBpbiB0aGUgUkZDIDU3MDUgc2Vuc2UgYnV0IG1vcmUg b2YgYSBkaXNhbWJpZ3VhdGVyIHRoYXQgaXMgdGFja2VkIG9udG8gdGhlIGNvbnRlbnQgdGhhdCBp cyBzaW5nZWQuIEFuZHJlaSBjYW4gcGVyaGFwcyBleHBsYWluIGl0J3MgcHVycG9zZSBiZXR0ZXIu DQpCdXQganVzdCB0aGlua2luZyBhYm91dCB0aGF0IG1ha2VzIG1lIHdvbmRlciBpZiBpdCdzIG5l Y2Vzc2FyeS4gIiJFWFBPUlRFUi1Ub2tlbi1CaW5kaW5nIiBpcyBoYXNoZWQgaW50byB0aGUgRUtN IHdoaWNoIGlzIHRoZW4gdW5kZXIgdGhlIHNpZ25hdHVyZS4gSXMgYW5vdGhlciAiVG9rZW4gQmlu ZGluZyIgc3RyaW5nIHVuZGVyIHRoZSBzaWduYXR1cmUgbmVlZGVkIHRvIHByZXZlbnQgY3Jvc3Mg cHJvdG9jb2wgYXR0YWNrcz8gRG9lc24ndCB0aGUgRUtNIGlucHV0IGxhYmVsIGFscmVhZHkgZG8g dGhhdD8NCg0KWWVzLCBpdCBkb2VzLCBidXQgc28gbG9uZyBhcyBpdCBkb2VzIG5vdCBjYXVzZSB0 aGUgZGF0YSB0byB0YWtlIHVwIGFub3RoZXIgMzItYnl0ZSBibG9jaywgSSdtIE9LIHdpdGggaXQu DQoNClNvLCBJJ20gT0sgd2l0aCB0aGUgLTA5IHZlcnNpb24uDQoNCkJpbGwNCg0KDQo= --_000_DM2PR0301MB0637565EA42BEE89BFA82179F5E30DM2PR0301MB0637_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJh Z3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1z dHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3Qt aWQ6MTI3NzE3NTI5MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6LTU1MDQ0MDA3NCAyMDcyNzkzMDA0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYw Ij5BcmUgYWxsIHRoZSBmaWVsZHMgd2XigJlyZSBjb25jYXRlbmF0aW5nIGZpeGVkIGxlbmd0aD8m bmJzcDsgSSBhc2sgYmVjYXVzZSBhIHN0YW5kYXJkIGtpbmQgb2YgYXR0YWNrIGFnYWluc3QgY3J5 cHRvIHN5c3RlbXMgdXNpbmcgY29uY2F0ZW5hdGlvbiBpcyB0byBtYWtlIGl0IGFwcGVhcg0KIHRo YXQgZGF0YSBmcm9tIG9uZSBmaWVsZCBiZWxvbmdzIGluIGFub3RoZXIgb25lIGJ5IHVzaW5nIGRp ZmZlcmVudCBmaWVsZCBsZW5ndGhzLiZuYnNwOyBJZiB0aGV5IGFyZW7igJl0IGZpeGVkIGxlbmd0 aCwgaW5jbHVkaW5nIGZpZWxkIGxlbmd0aCBjb3VudHMgb3IgZmllbGQgZGVsaW1pdGVycyBpbiB0 aGUgY29uY2F0ZW5hdGlvbiBpcyBhIHN0YW5kYXJkIHNvbHV0aW9uIHRvIHRoZSBwcm9ibGVtLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBVbmJlYXJhYmxlIFtt YWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5B bmRyZWkgUG9wb3Y8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYg MjoyMSBQTTxicj4NCjxiPlRvOjwvYj4gQmlsbCBDb3ggJmx0O3dheXdhcmRnZWVrQGdvb2dsZS5j b20mZ3Q7OyBCcmlhbiBDYW1wYmVsbCAmbHQ7YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBUb2tiaW5kIFdHICZsdDt1bmJlYXJhYmxlQGlldGYub3JnJmd0Ozsg TGVpZiBKb2hhbnNzb24gJmx0O2xlaWZqQHN1bmV0LnNlJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW1VuYmVhcmFibGVdIFdoYXQgR2V0cyBTaWduZWQgKHdhczogRHVtYiBpZGVhOiBhZGQg RWQyNTUxOSBzdXBwb3J0Pyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRvIHN1bSB1cCwgYXJlIHdlIGluIGFncmVlbWVudCB0 aGF0IHRoZSBjb25jYXRlbmF0aW9uIHdpbGwgb25seSBpbmNsdWRlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0 LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Ub2tlbkJpbmRpbmdUeXBlIHZh bHVlIGNvbnRhaW5lZCBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBU b2tlbkJpbmRpbmcudG9rZW5iaW5kaW5nX3R5cGUgZmllbGQ7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Ub2tlbkJpbmRpbmdLZXlQYXJhbWV0ZXJzIHZhbHVlIGNv bnRhaW5lZCBpbiB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUb2tlbkJp bmRpbmdJRC5rZXlfcGFyYW1ldGVycyBmaWVsZDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlz dDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkV4cG9ydGVkIGtleWluZyBtYXRlcmlhbCAoRUtNKSB2YWx1ZSBvYnRh aW5lZCBmcm9tIHRoZSBjdXJyZW50IFRMUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGNvbm5lY3Rpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj7igKYgYmVjYXVzZSB0aGUgbGFiZWwgYW5kIHRoZSBQcm90b2Nv bFZlcnNpb24gYXJlIHByZXN1bWFibHkgYWxyZWFkeSBpbiB0aGUgRUtNPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQmlsbCBDb3ggWzxhIGhyZWY9 Im1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tIj5tYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xl LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYg MjowMSBQTTxicj4NCjxiPlRvOjwvYj4gQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0 bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208 L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86 QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20iPkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9h PiZndDs7IFRva2JpbmQgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzp1bmJlYXJhYmxlQGlldGYub3Jn Ij51bmJlYXJhYmxlQGlldGYub3JnPC9hPiZndDs7IExlaWYgSm9oYW5zc29uICZsdDs8YSBocmVm PSJtYWlsdG86bGVpZmpAc3VuZXQuc2UiPmxlaWZqQHN1bmV0LnNlPC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBv cnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBXZWQsIEF1ZyAzMSwgMjAxNiBhdCAxOjEwIFBNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNh bXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEF1ZyAzMSwgMjAxNiBhdCAxOjM1IFBNLCBCaWxs IENveCAmbHQ7PGEgaHJlZj0ibWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb20iIHRhcmdldD0i X2JsYW5rIj53YXl3YXJkZ2Vla0Bnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVnIDMxLCAy MDE2IGF0IDEyOjEyIFBNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkluIHdoaWNoIGNhc2UgSSdkIGFnYWluIHN1Z2dlc3QgdGhhdCB0aGUgc2lnbmF0dXJlIGlu cHV0IGJlIHRoZSBjb25jYXRlbmF0ZWQgaXRlbXMgZGlyZWN0bHkgKG5vIGhhc2gpIGFuZCB0aGF0 IGhhc2hpbmcgb3Igbm90IGJlIHBhcnQgb2YgdGhlIHNpZ25hdHVyZSBzY2hlbWUgYXNzb2NpYXRl ZCB3aXRoIGVhY2gga2V5IHBhcmFtZXRlcnMgdHlwZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U291bmRz IGdvb2QgdG8gbWUuJm5ic3A7IEl0IGZpdHMgdGhlIHN0YW5kYXJkIEFQSXMgYSBiaXQgYmV0dGVy LiZuYnNwOyBJSVVDLCB0aGlzIHJlc3VsdCBpcyB0aGUgc2FtZSBlaXRoZXIgd2F5LCBzbyB0aGlz IGlzIHJlYWxseSBqdXN0IGEgbWF0dGVyIG9mIGhvdyB3ZSBkZXNjcmliZSBpdCwgcmlnaHQ/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQombmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzM4NzYx RCI+QWZ0ZXIgcGxheWluZyBhcm91bmQgd2l0aCBzb21lIEFQSXMgeWVzdGVyZGF5LCBJIGRvbid0 IHRoaW5rIHRoYXQgdGhlIHJlc3VsdCBpcyBhY3R1YWxseSB0aGUgc2FtZS4gQXQgbGVhc3QgYXMg ZmFyIGFzIHRoZSBhY3R1YWwgYnl0ZXMgb2YgdGhlIHNpZ25hdHVyZS4gQ29uY2VwdHVhbGx5IHRo ZSBpZGVhIGlzIHRoZSBzYW1lIHRob3VnaCwgQUZBSUssIGFuZCBtb3ZpbmcNCiB0aGUgaGFzaCBk ZWZpbml0aW9uIHRvIHRoZSBzaWduYXR1cmUgc2NoZW1lIGFzc29jaWF0ZWQgd2l0aCBlYWNoIGtl eSBwYXJhbWV0ZXJzIHR5cGUgcmVtb3ZlcyBhIGhhcmR3aXJlZCBkZXBlbmRlbmN5IG9uIFNIQTI1 NiBhbmQgYWxzbyBlbGltaW5hdGVzIGEgcm91bmQgb2YgaGFzaGluZyBmb3IgdGhlIFJTQSBrZXkg cGFyYW1ldGVycyB0eXBlcy4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIE9wZW5TU0wgc2lnbmluZyBBUElzIGFyZSBmaW5pY2t5LiZu YnNwOyBUaGV5IHJlYWxseSB3YW50IHRvIGRvIGEgZGlnZXN0LCBhbmQgeW91IGhhdmUgdG8ga25v dyBob3cgdG8gY2FsbCB0aGVtIGp1c3QgcmlnaHQgdG8gc2lnbiB0aGUgZGlnZXN0LCByYXRoZXIg dGhhbiB0aGUgaGFzaCBvZiB0aGUgZGlnZXN0LiZuYnNwOyBIb3dldmVyLCBhdCBvbmUgcG9pbnQs IEkgd2FzIGFibGUgdG8gdmVyaWZ5IHRoYXQgYm90aCB3YXlzDQogZ2l2ZSB0aGUgc2FtZSByZXN1 bHQuJm5ic3A7IEkgYWN0dWFsbHkgdXNlIHRoZSBub3JtYWwgQVBJcyBub3cgdGhhdCBkbyB0aGUg U0hBMjU2IHdoaWxlIHNpZ25pbmcuJm5ic3A7IEkgZG8gbm90IHRoaW5rIHRoaXMgcmVxdWlyZXMg YSBkb2N1bWVudCBjaGFuZ2UsIG90aGVyIHRoYW4gcGVyaGFwcyBzb21lIGNsYXJpZmljYXRpb24u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BY2NvcmRpbmcgdG8gdGhlIEVLTSBzcGVjICg8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTcwNSIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzA1PC9hPiksIGEgZGlzYW1iaWd1YXRp bmcgbGFiZWwgaXMgcmVxdWlyZWQsIGFuZCB3ZSdyZSBhbHNvIHN1cHBvc2VkIHRvIHJlZ2lzdGVy IGl0IHNvIHRoZXJlIGFyZSBubyBuYW1lIGNvbGxpc2lvbnMuJm5ic3A7DQogSXMgdGhpcyBzb21l dGhpbmcgd2UgbmVlZCB0byB3b3JyeSBhYm91dD8mbmJzcDsgPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMzg3NjFEIj5JIHRoaW5rIHRoYXQn cyBhbHJlYWR5IChvciB3aWxsIGJlKSBjb3ZlcmVkIHdpdGggdGhlIHJlZ2lzdHJhdGlvbiByZXF1 ZXN0IGZvciAmcXVvdDtFWFBPUlRFUi1Ub2tlbi1CaW5kaW5nJnF1b3Q7IGluDQo8YSBocmVmPSJo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10b2tiaW5kLXByb3RvY29sLTA5 I3NlY3Rpb24tNi40IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi10b2tiaW5kLXByb3RvY29sLTA5I3NlY3Rpb24tNi40PC9hPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0ssIGdyZWF0LiZuYnNw OyBJbiB0aGF0IGNhc2UsIGFkZGluZyAmcXVvdDtUb2tlbiBCaW5kaW5nJnF1b3Q7IGlzIHJlZHVu ZGFudCwgYnV0IHNpbmNlIHdlIHVzZSBhIDMyLWJ5dGUgYmxvY2sgaGFzaCBhbnl3YXksIEkgZG9u J3QgdGhpbmsgaXQgd2lsbCBtYWtlIGFueSBkaWZmZXJlbmNlIGlucyBzcGVlZCwgb3RoZXIgdGhh biB0aGUgY29zdCBvZiBjb3B5aW5nIHRoZSBkYXRhLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Rm9yIHNvbWUgcmVhc29uLCBJIHRob3VnaHQgd2UgaGFkIGFscmVhZHkgcmVnaXN0ZXJl ZCAmcXVvdDtUb2tlbiBCaW5kaW5nJnF1b3Q7IGFzIGEgdW5pcXVlIEVLTSBsYWJlbC4mbmJzcDsg SWYgc28sIHdlIHNob3VsZCBwcm9iYWJseSBwYXNzIHRoZSBsYWJlbCB0byB0aGUgRUtNIGVpdGhl ciBpbiBhZGRpdGlvbiB0bywgb3IgaW5zdGVhZCBvZiwgaGFzaGluZyBpdCBpbiB0aGUgZmluYWwg aGFzaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMzODc2MUQiPkkgbWF5IGhhdmUg Y29uZnVzZWQgdGhpbmdzIGJ5IHVzaW5nIHRoZSB0ZXJtIGxhYmVsIGZvciB0aGUgQVNDSUkgc3Ry aW5nICZxdW90O1Rva2VuIEJpbmRpbmcmcXVvdDsgdGhhdCdzIHBhcnQgb2YgdGhlIGNvbmNhdGVu YXRpb24gb2YgdGhpbmdzLiBJdCdzIG5vdCBhIGxhYmVsIGluIHRoZSBSRkMgNTcwNSBzZW5zZSBi dXQgbW9yZSBvZiBhIGRpc2FtYmlndWF0ZXIgdGhhdCBpcyB0YWNrZWQgb250byB0aGUgY29udGVu dA0KIHRoYXQgaXMgc2luZ2VkLiBBbmRyZWkgY2FuIHBlcmhhcHMgZXhwbGFpbiBpdCdzIHB1cnBv c2UgYmV0dGVyLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzM4NzYxRCI+QnV0IGp1c3QgdGhpbmtp bmcgYWJvdXQgdGhhdCBtYWtlcyBtZSB3b25kZXIgaWYgaXQncyBuZWNlc3NhcnkuICZxdW90OyZx dW90O0VYUE9SVEVSLVRva2VuLUJpbmRpbmcmcXVvdDsgaXMgaGFzaGVkIGludG8gdGhlIEVLTSB3 aGljaCBpcyB0aGVuIHVuZGVyIHRoZSBzaWduYXR1cmUuIElzIGFub3RoZXIgJnF1b3Q7VG9rZW4g QmluZGluZyZxdW90OyBzdHJpbmcgdW5kZXIgdGhlIHNpZ25hdHVyZSBuZWVkZWQNCiB0byBwcmV2 ZW50IGNyb3NzIHByb3RvY29sIGF0dGFja3M/IERvZXNuJ3QgdGhlIEVLTSBpbnB1dCBsYWJlbCBh bHJlYWR5IGRvIHRoYXQ/IDwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5ZZXMsIGl0IGRvZXMsIGJ1dCBzbyBsb25nIGFzIGl0IGRvZXMgbm90IGNhdXNlIHRoZSBk YXRhIHRvIHRha2UgdXAgYW5vdGhlciAzMi1ieXRlIGJsb2NrLCBJJ20gT0sgd2l0aCBpdC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28sIEkn bSBPSyB3aXRoIHRoZSAtMDkgdmVyc2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmlsbCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM2PR0301MB0637565EA42BEE89BFA82179F5E30DM2PR0301MB0637_-- From nobody Wed Aug 31 15:24: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 5098112D1E3 for ; Wed, 31 Aug 2016 15:24: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, 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 bBjnhSyTJyb1 for ; Wed, 31 Aug 2016 15:24:55 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0116.outbound.protection.outlook.com [104.47.34.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876FF12D786 for ; Wed, 31 Aug 2016 15:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=b0hqXevDVOUHDZCAW+m7wjaJ4vZotbRqIATEyyLTbgI=; b=Px+eSDNXu28DpMH0uzNpRul8GaXMvrdZRBiL6cDyFOuR0p9jQhpjno3Vl6K7LE8/jPOgFiyqMUYTNOieNOMiIEAC3xwJXs5OOK0d3tRAF5W7ZMwAVTRfm6G3f4Yz7nCYBsZv95l0DbwoFB38p8MHBxOoBLRS47IMa7f7h77xUps= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0633.namprd03.prod.outlook.com (10.160.158.139) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.9; Wed, 31 Aug 2016 22:24:51 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Wed, 31 Aug 2016 22:24:50 +0000 From: Andrei Popov To: Mike Jones , Bill Cox , Brian Campbell Thread-Topic: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) Thread-Index: AdIDzYe/nNN4QigzR4G2nIa8+fQ4XAACHYhAAAAcggA= Date: Wed, 31 Aug 2016 22:24:50 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 70aeed5d-c4d2-4602-6bed-08d3d1ed9fdc x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0633; 6:gbaEMq0QTQ/0egTX34zGITi20LLv304HUz9PbRcgPjViLSWx33m6H9ioN7yAGF2g66QuXoDEC/2SiVl00ORJtMHmg9S4LY1mkynTBkhi4hoqPx+SM5PJxuRUFT8V+pVEkfyZBPUk6cEJ85hF3rdAZ40eO64zSXFBOcPbAZXBOK1b4WDQNql0eNZ42nSTaL/mmmLAF9Pym16XcQGn1yfDXf+b8ho4OF8w+Qqlx35Gjy40XCKwAt7lNEruoXFV4Jy7dXlHmur3DisfkuuYn4r8VVgdUop630+wVt1bghKQ2Xx282Y88zSKxda0YYu8rm7NPH1H6ajoC6e1CiZd7Wu66g==; 5:AjL4ZprwM1soxKKMHlxH4gT7xxMS+Q92zLsnFT02opIPfjqqR4f2yQQgBZjfpzOILNePicKaMfFOo3hZzGqHzhuoGHqcwRfrI9tyxdaOpFYaRGebhtX9+KE5eHWH/u1V8J5eX++zVXeKWnOsH3uDHw==; 24:Ci/EGF6D/dSdUTea/gxWeMaHoOlSzCc/XPzHViSLjzyDv6zaW6TltNa7LjBIid915IMGUiZMGKrha9JsBEhVBGdhbyfEW/YzhUUGCAYRz3I=; 7:O982tc4iJHSF4t5dpPIvwQDTLGhDT/aRwsPw5vlNVTCQwSdk+M1BcyfZyOpEUufme5pFsYzu9y4vCoA5SEde4iwFOqgu4NXSu+YZfRMlGZW1X8fdfjwLdwKKxNTcsqb+jcXeBP00SigNKgSjbEBH6MiMHqA3YKyJLIBXqV/lIaAujiOfFk16BDSQvYr6t+py47m1bsBSDcKoy3GN3UuaJjb29Gj53CFof3hS5qAY0+WkXomsJTXrc68YphqEoUDR x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0633; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0633; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(52314003)(189002)(24454002)(51444003)(377454003)(199003)(5001770100001)(97736004)(8676002)(4326007)(19580405001)(19580395003)(92566002)(16236675004)(5005710100001)(189998001)(86612001)(5002640100001)(10400500002)(7906003)(10290500002)(122556002)(74316002)(6116002)(102836003)(790700001)(586003)(81156014)(106356001)(105586002)(99286002)(7736002)(10090500001)(9686002)(7846002)(7696003)(81166006)(8936002)(8990500004)(2950100001)(2900100001)(15975445007)(2561002)(86362001)(3900700001)(5660300001)(2906002)(77096005)(19300405004)(3660700001)(87936001)(3280700002)(19617315012)(2421001)(1511001)(19609705001)(50986999)(33656002)(76176999)(54356999)(19625215002)(101416001)(68736007)(76576001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0633; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB08426CD99B3C838CF77B40848CE30CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 22:24:50.5196 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0633 Archived-At: Cc: Tokbind WG , Leif Johansson Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) 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, 31 Aug 2016 22:24:58 -0000 --_000_CY1PR0301MB08426CD99B3C838CF77B40848CE30CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhleSBhcmUgYWxsIGZpeGVkIGxlbmd0aC4NCg0KRnJvbTogTWlrZSBKb25lcw0KU2VudDogV2Vk bmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYgMzoyNCBQTQ0KVG86IEFuZHJlaSBQb3BvdiA8QW5kcmVp LlBvcG92QG1pY3Jvc29mdC5jb20+OyBCaWxsIENveCA8d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbT47 IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4NCkNjOiBUb2tiaW5k IFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPjsgTGVpZiBKb2hhbnNzb24gPGxlaWZqQHN1bmV0LnNl Pg0KU3ViamVjdDogUkU6IFtVbmJlYXJhYmxlXSBXaGF0IEdldHMgU2lnbmVkICh3YXM6IER1bWIg aWRlYTogYWRkIEVkMjU1MTkgc3VwcG9ydD8pDQoNCkFyZSBhbGwgdGhlIGZpZWxkcyB3ZeKAmXJl IGNvbmNhdGVuYXRpbmcgZml4ZWQgbGVuZ3RoPyAgSSBhc2sgYmVjYXVzZSBhIHN0YW5kYXJkIGtp bmQgb2YgYXR0YWNrIGFnYWluc3QgY3J5cHRvIHN5c3RlbXMgdXNpbmcgY29uY2F0ZW5hdGlvbiBp cyB0byBtYWtlIGl0IGFwcGVhciB0aGF0IGRhdGEgZnJvbSBvbmUgZmllbGQgYmVsb25ncyBpbiBh bm90aGVyIG9uZSBieSB1c2luZyBkaWZmZXJlbnQgZmllbGQgbGVuZ3Rocy4gIElmIHRoZXkgYXJl buKAmXQgZml4ZWQgbGVuZ3RoLCBpbmNsdWRpbmcgZmllbGQgbGVuZ3RoIGNvdW50cyBvciBmaWVs ZCBkZWxpbWl0ZXJzIGluIHRoZSBjb25jYXRlbmF0aW9uIGlzIGEgc3RhbmRhcmQgc29sdXRpb24g dG8gdGhlIHByb2JsZW0uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IFVuYmVhcmFibGUgW21haWx0bzp1bmJl YXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmRyZWkgUG9wb3YNClNlbnQ6 IFdlZG5lc2RheSwgQXVndXN0IDMxLCAyMDE2IDI6MjEgUE0NClRvOiBCaWxsIENveCA8d2F5d2Fy ZGdlZWtAZ29vZ2xlLmNvbTxtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbT4+OyBCcmlhbiBD YW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5n aWRlbnRpdHkuY29tPj4NCkNjOiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPG1haWx0 bzp1bmJlYXJhYmxlQGlldGYub3JnPj47IExlaWYgSm9oYW5zc29uIDxsZWlmakBzdW5ldC5zZTxt YWlsdG86bGVpZmpAc3VuZXQuc2U+Pg0KU3ViamVjdDogUmU6IFtVbmJlYXJhYmxlXSBXaGF0IEdl dHMgU2lnbmVkICh3YXM6IER1bWIgaWRlYTogYWRkIEVkMjU1MTkgc3VwcG9ydD8pDQoNClRvIHN1 bSB1cCwgYXJlIHdlIGluIGFncmVlbWVudCB0aGF0IHRoZSBjb25jYXRlbmF0aW9uIHdpbGwgb25s eSBpbmNsdWRlOg0KDQoNCi0gICAgICAgICAgVG9rZW5CaW5kaW5nVHlwZSB2YWx1ZSBjb250YWlu ZWQgaW4gdGhlDQogICAgICBUb2tlbkJpbmRpbmcudG9rZW5iaW5kaW5nX3R5cGUgZmllbGQ7DQoN Ci0gICAgICAgICAgVG9rZW5CaW5kaW5nS2V5UGFyYW1ldGVycyB2YWx1ZSBjb250YWluZWQgaW4g dGhlDQogICAgICBUb2tlbkJpbmRpbmdJRC5rZXlfcGFyYW1ldGVycyBmaWVsZDsNCg0KLSAgICAg ICAgICBFeHBvcnRlZCBrZXlpbmcgbWF0ZXJpYWwgKEVLTSkgdmFsdWUgb2J0YWluZWQgZnJvbSB0 aGUgY3VycmVudCBUTFMNCiAgICAgIGNvbm5lY3Rpb24uDQrigKYgYmVjYXVzZSB0aGUgbGFiZWwg YW5kIHRoZSBQcm90b2NvbFZlcnNpb24gYXJlIHByZXN1bWFibHkgYWxyZWFkeSBpbiB0aGUgRUtN Pw0KDQpGcm9tOiBCaWxsIENveCBbbWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb21dDQpTZW50 OiBXZWRuZXNkYXksIEF1Z3VzdCAzMSwgMjAxNiAyOjAxIFBNDQpUbzogQnJpYW4gQ2FtcGJlbGwg PGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5 LmNvbT4+DQpDYzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWls dG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+PjsgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBp ZXRmLm9yZzxtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZz4+OyBMZWlmIEpvaGFuc3NvbiA8bGVp ZmpAc3VuZXQuc2U8bWFpbHRvOmxlaWZqQHN1bmV0LnNlPj4NClN1YmplY3Q6IFJlOiBbVW5iZWFy YWJsZV0gRHVtYiBpZGVhOiBhZGQgRWQyNTUxOSBzdXBwb3J0Pw0KDQpPbiBXZWQsIEF1ZyAzMSwg MjAxNiBhdCAxOjEwIFBNLCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5j b208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQoNCk9uIFdlZCwg QXVnIDMxLCAyMDE2IGF0IDE6MzUgUE0sIEJpbGwgQ294IDx3YXl3YXJkZ2Vla0Bnb29nbGUuY29t PG1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPj4gd3JvdGU6DQpPbiBXZWQsIEF1ZyAzMSwg MjAxNiBhdCAxMjoxMiBQTSwgQnJpYW4gQ2FtcGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHku Y29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+IHdyb3RlOg0KSW4gd2hpY2gg Y2FzZSBJJ2QgYWdhaW4gc3VnZ2VzdCB0aGF0IHRoZSBzaWduYXR1cmUgaW5wdXQgYmUgdGhlIGNv bmNhdGVuYXRlZCBpdGVtcyBkaXJlY3RseSAobm8gaGFzaCkgYW5kIHRoYXQgaGFzaGluZyBvciBu b3QgYmUgcGFydCBvZiB0aGUgc2lnbmF0dXJlIHNjaGVtZSBhc3NvY2lhdGVkIHdpdGggZWFjaCBr ZXkgcGFyYW1ldGVycyB0eXBlLg0KDQpTb3VuZHMgZ29vZCB0byBtZS4gIEl0IGZpdHMgdGhlIHN0 YW5kYXJkIEFQSXMgYSBiaXQgYmV0dGVyLiAgSUlVQywgdGhpcyByZXN1bHQgaXMgdGhlIHNhbWUg ZWl0aGVyIHdheSwgc28gdGhpcyBpcyByZWFsbHkganVzdCBhIG1hdHRlciBvZiBob3cgd2UgZGVz Y3JpYmUgaXQsIHJpZ2h0Pw0KDQoNCkFmdGVyIHBsYXlpbmcgYXJvdW5kIHdpdGggc29tZSBBUElz IHllc3RlcmRheSwgSSBkb24ndCB0aGluayB0aGF0IHRoZSByZXN1bHQgaXMgYWN0dWFsbHkgdGhl IHNhbWUuIEF0IGxlYXN0IGFzIGZhciBhcyB0aGUgYWN0dWFsIGJ5dGVzIG9mIHRoZSBzaWduYXR1 cmUuIENvbmNlcHR1YWxseSB0aGUgaWRlYSBpcyB0aGUgc2FtZSB0aG91Z2gsIEFGQUlLLCBhbmQg bW92aW5nIHRoZSBoYXNoIGRlZmluaXRpb24gdG8gdGhlIHNpZ25hdHVyZSBzY2hlbWUgYXNzb2Np YXRlZCB3aXRoIGVhY2gga2V5IHBhcmFtZXRlcnMgdHlwZSByZW1vdmVzIGEgaGFyZHdpcmVkIGRl cGVuZGVuY3kgb24gU0hBMjU2IGFuZCBhbHNvIGVsaW1pbmF0ZXMgYSByb3VuZCBvZiBoYXNoaW5n IGZvciB0aGUgUlNBIGtleSBwYXJhbWV0ZXJzIHR5cGVzLg0KDQpUaGUgT3BlblNTTCBzaWduaW5n IEFQSXMgYXJlIGZpbmlja3kuICBUaGV5IHJlYWxseSB3YW50IHRvIGRvIGEgZGlnZXN0LCBhbmQg eW91IGhhdmUgdG8ga25vdyBob3cgdG8gY2FsbCB0aGVtIGp1c3QgcmlnaHQgdG8gc2lnbiB0aGUg ZGlnZXN0LCByYXRoZXIgdGhhbiB0aGUgaGFzaCBvZiB0aGUgZGlnZXN0LiAgSG93ZXZlciwgYXQg b25lIHBvaW50LCBJIHdhcyBhYmxlIHRvIHZlcmlmeSB0aGF0IGJvdGggd2F5cyBnaXZlIHRoZSBz YW1lIHJlc3VsdC4gIEkgYWN0dWFsbHkgdXNlIHRoZSBub3JtYWwgQVBJcyBub3cgdGhhdCBkbyB0 aGUgU0hBMjU2IHdoaWxlIHNpZ25pbmcuICBJIGRvIG5vdCB0aGluayB0aGlzIHJlcXVpcmVzIGEg ZG9jdW1lbnQgY2hhbmdlLCBvdGhlciB0aGFuIHBlcmhhcHMgc29tZSBjbGFyaWZpY2F0aW9uLg0K DQpBY2NvcmRpbmcgdG8gdGhlIEVLTSBzcGVjIChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjNTcwNSksIGEgZGlzYW1iaWd1YXRpbmcgbGFiZWwgaXMgcmVxdWlyZWQsIGFuZCB3ZSdyZSBh bHNvIHN1cHBvc2VkIHRvIHJlZ2lzdGVyIGl0IHNvIHRoZXJlIGFyZSBubyBuYW1lIGNvbGxpc2lv bnMuICBJcyB0aGlzIHNvbWV0aGluZyB3ZSBuZWVkIHRvIHdvcnJ5IGFib3V0Pw0KDQpJIHRoaW5r IHRoYXQncyBhbHJlYWR5IChvciB3aWxsIGJlKSBjb3ZlcmVkIHdpdGggdGhlIHJlZ2lzdHJhdGlv biByZXF1ZXN0IGZvciAiRVhQT1JURVItVG9rZW4tQmluZGluZyIgaW4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1wcm90b2NvbC0wOSNzZWN0aW9uLTYuNA0K DQpPSywgZ3JlYXQuICBJbiB0aGF0IGNhc2UsIGFkZGluZyAiVG9rZW4gQmluZGluZyIgaXMgcmVk dW5kYW50LCBidXQgc2luY2Ugd2UgdXNlIGEgMzItYnl0ZSBibG9jayBoYXNoIGFueXdheSwgSSBk b24ndCB0aGluayBpdCB3aWxsIG1ha2UgYW55IGRpZmZlcmVuY2UgaW5zIHNwZWVkLCBvdGhlciB0 aGFuIHRoZSBjb3N0IG9mIGNvcHlpbmcgdGhlIGRhdGEuDQoNCkZvciBzb21lIHJlYXNvbiwgSSB0 aG91Z2h0IHdlIGhhZCBhbHJlYWR5IHJlZ2lzdGVyZWQgIlRva2VuIEJpbmRpbmciIGFzIGEgdW5p cXVlIEVLTSBsYWJlbC4gIElmIHNvLCB3ZSBzaG91bGQgcHJvYmFibHkgcGFzcyB0aGUgbGFiZWwg dG8gdGhlIEVLTSBlaXRoZXIgaW4gYWRkaXRpb24gdG8sIG9yIGluc3RlYWQgb2YsIGhhc2hpbmcg aXQgaW4gdGhlIGZpbmFsIGhhc2guDQoNCkkgbWF5IGhhdmUgY29uZnVzZWQgdGhpbmdzIGJ5IHVz aW5nIHRoZSB0ZXJtIGxhYmVsIGZvciB0aGUgQVNDSUkgc3RyaW5nICJUb2tlbiBCaW5kaW5nIiB0 aGF0J3MgcGFydCBvZiB0aGUgY29uY2F0ZW5hdGlvbiBvZiB0aGluZ3MuIEl0J3Mgbm90IGEgbGFi ZWwgaW4gdGhlIFJGQyA1NzA1IHNlbnNlIGJ1dCBtb3JlIG9mIGEgZGlzYW1iaWd1YXRlciB0aGF0 IGlzIHRhY2tlZCBvbnRvIHRoZSBjb250ZW50IHRoYXQgaXMgc2luZ2VkLiBBbmRyZWkgY2FuIHBl cmhhcHMgZXhwbGFpbiBpdCdzIHB1cnBvc2UgYmV0dGVyLg0KQnV0IGp1c3QgdGhpbmtpbmcgYWJv dXQgdGhhdCBtYWtlcyBtZSB3b25kZXIgaWYgaXQncyBuZWNlc3NhcnkuICIiRVhQT1JURVItVG9r ZW4tQmluZGluZyIgaXMgaGFzaGVkIGludG8gdGhlIEVLTSB3aGljaCBpcyB0aGVuIHVuZGVyIHRo ZSBzaWduYXR1cmUuIElzIGFub3RoZXIgIlRva2VuIEJpbmRpbmciIHN0cmluZyB1bmRlciB0aGUg c2lnbmF0dXJlIG5lZWRlZCB0byBwcmV2ZW50IGNyb3NzIHByb3RvY29sIGF0dGFja3M/IERvZXNu J3QgdGhlIEVLTSBpbnB1dCBsYWJlbCBhbHJlYWR5IGRvIHRoYXQ/DQoNClllcywgaXQgZG9lcywg YnV0IHNvIGxvbmcgYXMgaXQgZG9lcyBub3QgY2F1c2UgdGhlIGRhdGEgdG8gdGFrZSB1cCBhbm90 aGVyIDMyLWJ5dGUgYmxvY2ssIEknbSBPSyB3aXRoIGl0Lg0KDQpTbywgSSdtIE9LIHdpdGggdGhl IC0wOSB2ZXJzaW9uLg0KDQpCaWxsDQoNCg0K --_000_CY1PR0301MB08426CD99B3C838CF77B40848CE30CY1PR0301MB0842_ 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 cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzAwMjA2MDt9DQpz cGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlk OjEyNzcxNzUyOTE7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi01NTA0NDAwNzQgMjA3Mjc5MzAwNCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZl bDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpD YWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0 IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGlu O30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZXkgYXJlIGFsbCBm aXhlZCBsZW5ndGguPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTWlrZSBKb25lcw0KPGJy Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDMxLCAyMDE2IDM6MjQgUE08YnI+DQo8 Yj5Ubzo8L2I+IEFuZHJlaSBQb3BvdiAmbHQ7QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20mZ3Q7 OyBCaWxsIENveCAmbHQ7d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbSZndDs7IEJyaWFuIENhbXBiZWxs ICZsdDtiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFRva2Jp bmQgV0cgJmx0O3VuYmVhcmFibGVAaWV0Zi5vcmcmZ3Q7OyBMZWlmIEpvaGFuc3NvbiAmbHQ7bGVp ZmpAc3VuZXQuc2UmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbVW5iZWFyYWJsZV0gV2hh dCBHZXRzIFNpZ25lZCAod2FzOiBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBvcnQ/KTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMDAyMDYwIj5BcmUgYWxsIHRoZSBmaWVsZHMgd2XigJlyZSBjb25jYXRlbmF0aW5n IGZpeGVkIGxlbmd0aD8mbmJzcDsgSSBhc2sgYmVjYXVzZSBhIHN0YW5kYXJkIGtpbmQgb2YgYXR0 YWNrIGFnYWluc3QgY3J5cHRvIHN5c3RlbXMgdXNpbmcgY29uY2F0ZW5hdGlvbiBpcyB0byBtYWtl IGl0IGFwcGVhcg0KIHRoYXQgZGF0YSBmcm9tIG9uZSBmaWVsZCBiZWxvbmdzIGluIGFub3RoZXIg b25lIGJ5IHVzaW5nIGRpZmZlcmVudCBmaWVsZCBsZW5ndGhzLiZuYnNwOyBJZiB0aGV5IGFyZW7i gJl0IGZpeGVkIGxlbmd0aCwgaW5jbHVkaW5nIGZpZWxkIGxlbmd0aCBjb3VudHMgb3IgZmllbGQg ZGVsaW1pdGVycyBpbiB0aGUgY29uY2F0ZW5hdGlvbiBpcyBhIHN0YW5kYXJkIHNvbHV0aW9uIHRv IHRoZSBwcm9ibGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBv c2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IFVuYmVhcmFibGUgWzxhIGhyZWY9Im1haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0 Zi5vcmciPm1haWx0bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5BbmRyZWkgUG9wb3Y8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1 c3QgMzEsIDIwMTYgMjoyMSBQTTxicj4NCjxiPlRvOjwvYj4gQmlsbCBDb3ggJmx0OzxhIGhyZWY9 Im1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tIj53YXl3YXJkZ2Vla0Bnb29nbGUuY29tPC9h PiZndDs7IEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdp ZGVudGl0eS5jb20iPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDs8YnI+DQo8Yj5D Yzo8L2I+IFRva2JpbmQgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzp1bmJlYXJhYmxlQGlldGYub3Jn Ij51bmJlYXJhYmxlQGlldGYub3JnPC9hPiZndDs7IExlaWYgSm9oYW5zc29uICZsdDs8YSBocmVm PSJtYWlsdG86bGVpZmpAc3VuZXQuc2UiPmxlaWZqQHN1bmV0LnNlPC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBXaGF0IEdldHMgU2lnbmVkICh3YXM6IER1bWIg aWRlYTogYWRkIEVkMjU1MTkgc3VwcG9ydD8pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UbyBzdW0gdXAsIGFyZSB3ZSBpbiBh Z3JlZW1lbnQgdGhhdCB0aGUgY29uY2F0ZW5hdGlvbiB3aWxsIG9ubHkgaW5jbHVkZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG9rZW5CaW5k aW5nVHlwZSB2YWx1ZSBjb250YWluZWQgaW4gdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgVG9rZW5CaW5kaW5nLnRva2VuYmluZGluZ190eXBlIGZpZWxkOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRl bnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG9rZW5CaW5kaW5nS2V5UGFyYW1ldGVy cyB2YWx1ZSBjb250YWluZWQgaW4gdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgVG9rZW5CaW5kaW5nSUQua2V5X3BhcmFtZXRlcnMgZmllbGQ7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1 aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5FeHBvcnRlZCBrZXlpbmcgbWF0ZXJpYWwgKEVLTSkg dmFsdWUgb2J0YWluZWQgZnJvbSB0aGUgY3VycmVudCBUTFM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBjb25uZWN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+4oCmIGJlY2F1c2UgdGhlIGxhYmVsIGFuZCB0 aGUgUHJvdG9jb2xWZXJzaW9uIGFyZSBwcmVzdW1hYmx5IGFscmVhZHkgaW4gdGhlIEVLTT88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJpbGwgQ294 IFs8YSBocmVmPSJtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbSI+bWFpbHRvOndheXdhcmRn ZWVrQGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0 IDMxLCAyMDE2IDI6MDEgUE08YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIENhbXBiZWxsICZsdDs8YSBo cmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iPmJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIj5BbmRyZWkuUG9wb3ZAbWljcm9z b2Z0LmNvbTwvYT4mZ3Q7OyBUb2tiaW5kIFdHICZsdDs8YSBocmVmPSJtYWlsdG86dW5iZWFyYWJs ZUBpZXRmLm9yZyI+dW5iZWFyYWJsZUBpZXRmLm9yZzwvYT4mZ3Q7OyBMZWlmIEpvaGFuc3NvbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmxlaWZqQHN1bmV0LnNlIj5sZWlmakBzdW5ldC5zZTwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gRHVtYiBpZGVhOiBhZGQgRWQy NTUxOSBzdXBwb3J0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gV2VkLCBBdWcgMzEsIDIwMTYgYXQgMToxMCBQTSwgQnJpYW4gQ2FtcGJlbGwg Jmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBdWcgMzEsIDIwMTYgYXQgMToz NSBQTSwgQmlsbCBDb3ggJmx0OzxhIGhyZWY9Im1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQs IEF1ZyAzMSwgMjAxNiBhdCAxMjoxMiBQTSwgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1h aWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JbiB3aGljaCBjYXNlIEknZCBhZ2FpbiBzdWdnZXN0IHRoYXQgdGhlIHNp Z25hdHVyZSBpbnB1dCBiZSB0aGUgY29uY2F0ZW5hdGVkIGl0ZW1zIGRpcmVjdGx5IChubyBoYXNo KSBhbmQgdGhhdCBoYXNoaW5nIG9yIG5vdCBiZSBwYXJ0IG9mIHRoZSBzaWduYXR1cmUgc2NoZW1l IGFzc29jaWF0ZWQgd2l0aCBlYWNoIGtleSBwYXJhbWV0ZXJzIHR5cGUuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlNvdW5kcyBnb29kIHRvIG1lLiZuYnNwOyBJdCBmaXRzIHRoZSBzdGFuZGFyZCBBUElzIGEg Yml0IGJldHRlci4mbmJzcDsgSUlVQywgdGhpcyByZXN1bHQgaXMgdGhlIHNhbWUgZWl0aGVyIHdh eSwgc28gdGhpcyBpcyByZWFsbHkganVzdCBhIG1hdHRlciBvZiBob3cgd2UgZGVzY3JpYmUgaXQs IHJpZ2h0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMzODc2MUQiPkFmdGVyIHBsYXlpbmcgYXJvdW5kIHdpdGggc29tZSBBUElzIHllc3RlcmRh eSwgSSBkb24ndCB0aGluayB0aGF0IHRoZSByZXN1bHQgaXMgYWN0dWFsbHkgdGhlIHNhbWUuIEF0 IGxlYXN0IGFzIGZhciBhcyB0aGUgYWN0dWFsIGJ5dGVzIG9mIHRoZSBzaWduYXR1cmUuIENvbmNl cHR1YWxseSB0aGUgaWRlYSBpcyB0aGUgc2FtZSB0aG91Z2gsIEFGQUlLLCBhbmQgbW92aW5nDQog dGhlIGhhc2ggZGVmaW5pdGlvbiB0byB0aGUgc2lnbmF0dXJlIHNjaGVtZSBhc3NvY2lhdGVkIHdp dGggZWFjaCBrZXkgcGFyYW1ldGVycyB0eXBlIHJlbW92ZXMgYSBoYXJkd2lyZWQgZGVwZW5kZW5j eSBvbiBTSEEyNTYgYW5kIGFsc28gZWxpbWluYXRlcyBhIHJvdW5kIG9mIGhhc2hpbmcgZm9yIHRo ZSBSU0Ega2V5IHBhcmFtZXRlcnMgdHlwZXMuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBPcGVuU1NMIHNpZ25pbmcgQVBJcyBhcmUg ZmluaWNreS4mbmJzcDsgVGhleSByZWFsbHkgd2FudCB0byBkbyBhIGRpZ2VzdCwgYW5kIHlvdSBo YXZlIHRvIGtub3cgaG93IHRvIGNhbGwgdGhlbSBqdXN0IHJpZ2h0IHRvIHNpZ24gdGhlIGRpZ2Vz dCwgcmF0aGVyIHRoYW4gdGhlIGhhc2ggb2YgdGhlIGRpZ2VzdC4mbmJzcDsgSG93ZXZlciwgYXQg b25lIHBvaW50LCBJIHdhcyBhYmxlIHRvIHZlcmlmeSB0aGF0IGJvdGggd2F5cw0KIGdpdmUgdGhl IHNhbWUgcmVzdWx0LiZuYnNwOyBJIGFjdHVhbGx5IHVzZSB0aGUgbm9ybWFsIEFQSXMgbm93IHRo YXQgZG8gdGhlIFNIQTI1NiB3aGlsZSBzaWduaW5nLiZuYnNwOyBJIGRvIG5vdCB0aGluayB0aGlz IHJlcXVpcmVzIGEgZG9jdW1lbnQgY2hhbmdlLCBvdGhlciB0aGFuIHBlcmhhcHMgc29tZSBjbGFy aWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWNjb3JkaW5nIHRvIHRoZSBFS00g c3BlYyAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3MDUiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTcwNTwvYT4pLCBhIGRp c2FtYmlndWF0aW5nIGxhYmVsIGlzIHJlcXVpcmVkLCBhbmQgd2UncmUgYWxzbyBzdXBwb3NlZCB0 byByZWdpc3RlciBpdCBzbyB0aGVyZSBhcmUgbm8gbmFtZSBjb2xsaXNpb25zLiZuYnNwOw0KIElz IHRoaXMgc29tZXRoaW5nIHdlIG5lZWQgdG8gd29ycnkgYWJvdXQ/Jm5ic3A7IDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzM4NzYxRCI+SSB0 aGluayB0aGF0J3MgYWxyZWFkeSAob3Igd2lsbCBiZSkgY292ZXJlZCB3aXRoIHRoZSByZWdpc3Ry YXRpb24gcmVxdWVzdCBmb3IgJnF1b3Q7RVhQT1JURVItVG9rZW4tQmluZGluZyZxdW90OyBpbg0K PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1w cm90b2NvbC0wOSNzZWN0aW9uLTYuNCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1wcm90b2NvbC0wOSNzZWN0aW9uLTYuNDwv YT4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9LLCBn cmVhdC4mbmJzcDsgSW4gdGhhdCBjYXNlLCBhZGRpbmcgJnF1b3Q7VG9rZW4gQmluZGluZyZxdW90 OyBpcyByZWR1bmRhbnQsIGJ1dCBzaW5jZSB3ZSB1c2UgYSAzMi1ieXRlIGJsb2NrIGhhc2ggYW55 d2F5LCBJIGRvbid0IHRoaW5rIGl0IHdpbGwgbWFrZSBhbnkgZGlmZmVyZW5jZSBpbnMgc3BlZWQs IG90aGVyIHRoYW4gdGhlIGNvc3Qgb2YgY29weWluZyB0aGUgZGF0YS4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGlu O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkZvciBzb21lIHJlYXNvbiwgSSB0aG91Z2h0IHdlIGhhZCBhbHJlYWR5 IHJlZ2lzdGVyZWQgJnF1b3Q7VG9rZW4gQmluZGluZyZxdW90OyBhcyBhIHVuaXF1ZSBFS00gbGFi ZWwuJm5ic3A7IElmIHNvLCB3ZSBzaG91bGQgcHJvYmFibHkgcGFzcyB0aGUgbGFiZWwgdG8gdGhl IEVLTSBlaXRoZXIgaW4gYWRkaXRpb24gdG8sIG9yIGluc3RlYWQgb2YsIGhhc2hpbmcgaXQgaW4g dGhlIGZpbmFsIGhhc2guPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMzg3NjFEIj5J IG1heSBoYXZlIGNvbmZ1c2VkIHRoaW5ncyBieSB1c2luZyB0aGUgdGVybSBsYWJlbCBmb3IgdGhl IEFTQ0lJIHN0cmluZyAmcXVvdDtUb2tlbiBCaW5kaW5nJnF1b3Q7IHRoYXQncyBwYXJ0IG9mIHRo ZSBjb25jYXRlbmF0aW9uIG9mIHRoaW5ncy4gSXQncyBub3QgYSBsYWJlbCBpbiB0aGUgUkZDIDU3 MDUgc2Vuc2UgYnV0IG1vcmUgb2YgYSBkaXNhbWJpZ3VhdGVyIHRoYXQgaXMgdGFja2VkIG9udG8g dGhlIGNvbnRlbnQNCiB0aGF0IGlzIHNpbmdlZC4gQW5kcmVpIGNhbiBwZXJoYXBzIGV4cGxhaW4g aXQncyBwdXJwb3NlIGJldHRlci4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzODc2MUQiPkJ1dCBq dXN0IHRoaW5raW5nIGFib3V0IHRoYXQgbWFrZXMgbWUgd29uZGVyIGlmIGl0J3MgbmVjZXNzYXJ5 LiAmcXVvdDsmcXVvdDtFWFBPUlRFUi1Ub2tlbi1CaW5kaW5nJnF1b3Q7IGlzIGhhc2hlZCBpbnRv IHRoZSBFS00gd2hpY2ggaXMgdGhlbiB1bmRlciB0aGUgc2lnbmF0dXJlLiBJcyBhbm90aGVyICZx dW90O1Rva2VuIEJpbmRpbmcmcXVvdDsgc3RyaW5nIHVuZGVyIHRoZSBzaWduYXR1cmUgbmVlZGVk DQogdG8gcHJldmVudCBjcm9zcyBwcm90b2NvbCBhdHRhY2tzPyBEb2Vzbid0IHRoZSBFS00gaW5w dXQgbGFiZWwgYWxyZWFkeSBkbyB0aGF0PyA8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+WWVzLCBpdCBkb2VzLCBidXQgc28gbG9uZyBhcyBpdCBkb2VzIG5vdCBj YXVzZSB0aGUgZGF0YSB0byB0YWtlIHVwIGFub3RoZXIgMzItYnl0ZSBibG9jaywgSSdtIE9LIHdp dGggaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlNvLCBJJ20gT0sgd2l0aCB0aGUgLTA5IHZlcnNpb24uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJpbGwmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR0301MB08426CD99B3C838CF77B40848CE30CY1PR0301MB0842_-- From nobody Wed Aug 31 15:48: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 D92B112D77D for ; Wed, 31 Aug 2016 15:48:35 -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 ICB5EUaS1Wi3 for ; Wed, 31 Aug 2016 15:48:33 -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 3EEDA12D76E for ; Wed, 31 Aug 2016 15:48:33 -0700 (PDT) Received: by mail-it0-x22b.google.com with SMTP id e124so71646207ith.0 for ; Wed, 31 Aug 2016 15:48:33 -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=QYllUYEidDu5zeQPVZtFRnblGVKqPs/8ipBLhTmNiCs=; b=HfWV80ICNtjTqyu3szXaIMbv1Dmnn3+Q1M6Xx7W/H+nSwR/afftGD2h3kvMjHSeCRQ voFeict4tjcARn8qbDGm2fJClTN6r9rGn9UalSPBd5KEUIZV03OH82uMLHMiMqGzmL2N F2VTeMZZVK1dcnQlvWfXymHMSt8SRD6hiq5KE= 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=QYllUYEidDu5zeQPVZtFRnblGVKqPs/8ipBLhTmNiCs=; b=g6IbpnATCdKcQeO4yONSTDtNh3mf8f3SNx7R5WakrmxuteTuc58JO70wh3UJ2uabkn /49ts0vgDQx6ekot7OeF+Pqs6q0eC24g/0i9tH+O/WyaoAwkH9KVzjALj0k0IClUnrrj Y62B5wbVcjddUt4VS7CgInYi3CPovQhiMnPMbIeMN6IDRbjw/OfyEtCfJ2McGSy5KKBN 6IQIRdeWAkUdxUYUhyy/Vrc//SIlDiA5NtAgzOvlVczBzuLqgokzLh6nyiSdEO649Tut eSMuxvNy5pkOf21C/3OK9y0vvqP8NstXIdCUIQVXC8dBUCvAevXMlD3zrX8Zviqg0/Xt 6FEQ== X-Gm-Message-State: AE9vXwPcIDIAEuIkND/MjF85FghBp/RvUOr9qMX5Ro9bN2svlgxzPShPTFxopvI8rMYh8eWfDes4rtT2SYcaF+uN X-Received: by 10.36.207.8 with SMTP id y8mr17491190itf.63.1472683712428; Wed, 31 Aug 2016 15:48:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.114.20 with HTTP; Wed, 31 Aug 2016 15:48:01 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 31 Aug 2016 16:48:01 -0600 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=94eb2c05cea48be7f0053b65e5fd Archived-At: Cc: Tokbind WG , Leif Johansson , Bill Cox Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) 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, 31 Aug 2016 22:48:36 -0000 --94eb2c05cea48be7f0053b65e5fd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My suggestion is to use those 34 bytes directly as the input into the signature generation/verification. And for ecdsap256 key params, to use ECDSA using P-256 and SHA-256 as the signature algorithm. Although the latter is not strictly necessary AFAICT because 'raw' ECDSA using P-256 can sign 34 bytes okay. Admittedly, I could be off base here but that's more what I would have expected to see. We seem to be talking past one another, however, in just trying to discuss it. On Wed, Aug 31, 2016 at 3:47 PM, Andrei Popov wrote: > Great. > > > > Then we have 34 bytes we hash with SHA256 and sign. > > > > When we sign with RSA-PSS or RSA-PKCS, we also specify the use of SHA256 > in the padding algorithm. For ECDSA, there is no need to pad, and therefo= re > no need (or opportunity) to use padding hash. > > > > Brian, what specifically would you like to change WRT hashing? > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Wednesday, August 31, 2016 2:42 PM > *To:* Bill Cox > *Cc:* Andrei Popov ; Tokbind WG < > unbearable@ietf.org>; Leif Johansson > *Subject:* Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 > support?) > > > > Works for me too (I think). > > > > On Wed, Aug 31, 2016 at 3:34 PM, Bill Cox wrote: > > Works for me. > > > > On Wed, Aug 31, 2016 at 2:20 PM, Andrei Popov > wrote: > > To sum up, are we in agreement that the concatenation will only include: > > > > - TokenBindingType value contained in the > > TokenBinding.tokenbinding_type field; > > - TokenBindingKeyParameters value contained in the > > TokenBindingID.key_parameters field; > > - Exported keying material (EKM) value obtained from the current > TLS > > connection. > > =E2=80=A6 because the label and the ProtocolVersion are presumably alread= y in the > EKM? > > > > *From:* Bill Cox [mailto:waywardgeek@google.com] > *Sent:* Wednesday, August 31, 2016 2:01 PM > *To:* Brian Campbell > *Cc:* Andrei Popov ; Tokbind WG < > unbearable@ietf.org>; Leif Johansson > *Subject:* Re: [Unbearable] Dumb idea: add Ed25519 support? > > > > On Wed, Aug 31, 2016 at 1:10 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > > > > On Wed, Aug 31, 2016 at 1:35 PM, Bill Cox wrote: > > On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > > In which case I'd again suggest that the signature input be the > concatenated items directly (no hash) and that hashing or not be part of > the signature scheme associated with each key parameters type. > > > > Sounds good to me. It fits the standard APIs a bit better. IIUC, this > result is the same either way, so this is really just a matter of how we > describe it, right? > > > > > After playing around with some APIs yesterday, I don't think that the > result is actually the same. At least as far as the actual bytes of the > signature. Conceptually the idea is the same though, AFAIK, and moving th= e > hash definition to the signature scheme associated with each key paramete= rs > type removes a hardwired dependency on SHA256 and also eliminates a round > of hashing for the RSA key parameters types. > > > > The OpenSSL signing APIs are finicky. They really want to do a digest, > and you have to know how to call them just right to sign the digest, rath= er > than the hash of the digest. However, at one point, I was able to verify > that both ways give the same result. I actually use the normal APIs now > that do the SHA256 while signing. I do not think this requires a documen= t > change, other than perhaps some clarification. > > > > According to the EKM spec (https://tools.ietf.org/html/rfc5705), a > disambiguating label is required, and we're also supposed to register it = so > there are no name collisions. Is this something we need to worry about? > > > > I think that's already (or will be) covered with the registration request > for "EXPORTER-Token-Binding" in https://tools.ietf.org/html/dr > aft-ietf-tokbind-protocol-09#section-6.4 > > > > OK, great. In that case, adding "Token Binding" is redundant, but since > we use a 32-byte block hash anyway, I don't think it will make any > difference ins speed, other than the cost of copying the data. > > > > For some reason, I thought we had already registered "Token Binding" as a > unique EKM label. If so, we should probably pass the label to the EKM > either in addition to, or instead of, hashing it in the final hash. > > > I may have confused things by using the term label for the ASCII string > "Token Binding" that's part of the concatenation of things. It's not a > label in the RFC 5705 sense but more of a disambiguater that is tacked on= to > the content that is singed. Andrei can perhaps explain it's purpose bette= r. > > But just thinking about that makes me wonder if it's necessary. > ""EXPORTER-Token-Binding" is hashed into the EKM which is then under the > signature. Is another "Token Binding" string under the signature needed t= o > prevent cross protocol attacks? Doesn't the EKM input label already do > that? > > > > Yes, it does, but so long as it does not cause the data to take up anothe= r > 32-byte block, I'm OK with it. > > > > So, I'm OK with the -09 version. > > > > Bill > > > > > > > > > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --94eb2c05cea48be7f0053b65e5fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My suggestion is to use those 34 bytes directly as th= e input into the signature generation/verification. And for ecdsap256 key p= arams, to use ECDSA using P-256 and SHA-256 as the signature algorithm. Alt= hough the latter is not strictly necessary AFAICT because 'raw' ECD= SA using P-256 can sign 34 bytes okay.

Admittedly, I could be off ba= se here but that's more what I would have expected to see. We seem to b= e talking past one another, however, in just trying to discuss it.=C2=A0

=C2=A0


On Wed, Aug 31, 2016 at 3:47 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

Great.

=C2=A0

Then we have 34 bytes we hash with SHA256 and sign.

=C2=A0

When we sign with RSA-PSS or RSA-PKCS, we also spec= ify the use of SHA256 in the padding algorithm. For ECDSA, there is no need= to pad, and therefore no need (or opportunity) to use padding hash.

=C2=A0

Brian, what specifically would you like to change W= RT hashing?

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingiden= tity.com]
Sent: Wednesday, August 31, 2016 2:42 PM
To: Bill Cox <waywardgeek@google.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Tokbind WG <unbearable@ietf.org&g= t;; Leif Johansson <= leifj@sunet.se>
Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: a= dd Ed25519 support?)

=C2=A0

Works for me too (I think).

=C2=A0

On Wed, Aug 31, 2016 at 3:34 PM, Bill Cox <waywardgeek@google.co= m> wrote:

Works for me.

=C2=A0

On Wed, Aug 31, 2016 at 2:20 PM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

To sum up, are we in agreement that the concatenati= on will only include:

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 TokenBindingType value contained in the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TokenBinding.tokenbi= nding_type field;

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 TokenBindingKeyParameters value contained in the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TokenBindingID.key_p= arameters field;

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Exported keying material (EKM) value obtained from the current TLS<= /span>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 connection.

=E2=80=A6 because the label and the ProtocolVersion= are presumably already in the EKM?

=C2=A0

From: Bill Cox [mailto:waywardgeek@google.com]
Sent: Wednesday, August 31, 2016 2:01 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Tokbind WG <unbearable@ietf.org&g= t;; Leif Johansson <= leifj@sunet.se>
Subject: Re: [Unbearable] Dumb idea: add Ed25519 support?<= /u>

=C2=A0

On Wed, Aug 31, 2016 at 1:10 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

=C2=A0

On Wed, Aug 31, 2016 at 1:35 PM, Bill Cox <waywardgeek@google.co= m> wrote:

On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell <= ;bcampbell@= pingidentity.com> wrote:

In which case I'd again suggest that the signatu= re input be the concatenated items directly (no hash) and that hashing or n= ot be part of the signature scheme associated with each key parameters type.=C2=A0

=C2=A0

Sounds good to me.=C2=A0 It fits the standard APIs a= bit better.=C2=A0 IIUC, this result is the same either way, so this is rea= lly just a matter of how we describe it, right?


=C2=A0

After playing around w= ith some APIs yesterday, I don't think that the result is actually the = same. At least as far as the actual bytes of the signature. Conceptually the idea is the same though, AFAIK, and moving the hash defin= ition to the signature scheme associated with each key parameters type remo= ves a hardwired dependency on SHA256 and also eliminates a round of hashing= for the RSA key parameters types.=C2=A0

=C2=A0

The OpenSSL signing APIs are finicky.=C2=A0 They rea= lly want to do a digest, and you have to know how to call them just right t= o sign the digest, rather than the hash of the digest.=C2=A0 However, at one point, I was able to verify that both ways give the same r= esult.=C2=A0 I actually use the normal APIs now that do the SHA256 while si= gning.=C2=A0 I do not think this requires a document change, other than per= haps some clarification.

=C2=A0

According to the EKM spec (https://tools.ietf.org/html/r= fc5705), a disambiguating label is required, and we're also supposed to register it so there are no name collisions.=C2=A0 Is thi= s something we need to worry about?=C2=A0

=C2=A0

I think that's alr= eady (or will be) covered with the registration request for "EXPORTER-= Token-Binding" in https://tools.ietf.org/html/draft-ietf-tokbind-protocol-09#sectio= n-6.4=C2=A0

=C2=A0

OK, great.=C2=A0 In that case, adding "Token Bi= nding" is redundant, but since we use a 32-byte block hash anyway, I d= on't think it will make any difference ins speed, other than the cost of copying the data.=C2=A0

=C2=A0

For some reason, I thought we had already registered= "Token Binding" as a unique EKM label.=C2=A0 If so, we should pr= obably pass the label to the EKM either in addition to, or instead of, hashing it in the final hash.


I may have confused things by using the term = label for the ASCII string "Token Binding" that's part of the= concatenation of things. It's not a label in the RFC 5705 sense but mo= re of a disambiguater that is tacked onto the content that is singed. Andrei can perhaps explain it's purpose better.

But just thinking abou= t that makes me wonder if it's necessary. ""EXPORTER-Token-Bi= nding" is hashed into the EKM which is then under the signature. Is another "Token Binding" string under the signature needed to pre= vent cross protocol attacks? Doesn't the EKM input label already do tha= t?

=C2=A0

Yes, it does, but so long as it does not cause the d= ata to take up another 32-byte block, I'm OK with it.

=C2=A0

So, I'm OK with the -09 version.

=C2=A0

Bill=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearabl= e


--94eb2c05cea48be7f0053b65e5fd-- From nobody Wed Aug 31 15:55: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 A2F5212D7B2 for ; Wed, 31 Aug 2016 15:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 7zqu0TeKouyW for ; Wed, 31 Aug 2016 15:54:55 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 84B7C12D763 for ; Wed, 31 Aug 2016 15:54:55 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id i32so115181744uai.2 for ; Wed, 31 Aug 2016 15:54:55 -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=lG/tdfnohRZFkQjkv6iUQVaNdRo+PxGgwQcJfgyebzI=; b=Pd9j+ZqehjzTYq4KTYa8g4CPYk/dvA9oEAgvg3CC8eS9TgIcU/DLuPTcx3IjKO94BZ GZYQ1aNBst85PkWrq1w/2q2M0hptF02SO/68L6wpUUBaryhRsBLa2AX7BOjSEBGblXaQ Pg9Yx8jVL+yA9N7HT6bmjKLwVo5gLLjrXyQKhyZa+Nxh3CZQfkSDmIB3IJiVdh2hhENu 7xyPJH9imQkiMBh+Qppssms5W0EACwmL6JffquXTzG68joCLwGXtMTpQoa5URugoN+6I rF0Qfxp5ZEzfyhK3UW3fda2J3GBUHJVZE96lAyj7+RI+Nce95JVjGUi3aPH17uMyxtQX t9og== 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=lG/tdfnohRZFkQjkv6iUQVaNdRo+PxGgwQcJfgyebzI=; b=CFcCe7xE58yqUoP8HkLHi1bYLYPOqDH4XNcGhXuNu1FbpggtZNcMNitCYA0Zxr2jPJ pW0/ew/XdgsjmcltHKMqRa5n9Y8dZd/sFteuiO4HDU53qq+tJoHvHBD0fYgu+dzipBju 939GE5JoJXT9PDMjR/9oecT2FW+TpwGct6iwntalCCeVtWf2kMcTLNimYg4Iw93QZ5YS 9hr7ulkwLSorCJf6ZGGXgOvTPv5+qfw3RUoPELLA9V94F56y8dv74Z0KY9MNJNPxBcIl c1Bnp4jOnCRiYF00UiNqnkzEjttN5hWunVvb9mDYwJw9A6J0BKblp3olB1MrVvG231rx S0GQ== X-Gm-Message-State: AE9vXwPMF8VHomHRTHZ4z2ejs62SEdKUDQ+V2zHBgAXNaBBxuxB4IUF9zzTDTkhLWe++IY2PSgPutuqmfTnXGzRN X-Received: by 10.176.82.110 with SMTP id j43mr7807068uaa.104.1472684094376; Wed, 31 Aug 2016 15:54:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.209 with HTTP; Wed, 31 Aug 2016 15:54:33 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Wed, 31 Aug 2016 15:54:33 -0700 Message-ID: To: Brian Campbell Content-Type: multipart/alternative; boundary=94eb2c191d7e5010e8053b65fce0 Archived-At: Cc: Andrei Popov , Bill Cox , Tokbind WG , Leif Johansson Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) 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, 31 Aug 2016 22:54:58 -0000 --94eb2c191d7e5010e8053b65fce0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My understanding is that P-256 can only sign a 32-byte message (hence why it makes sense to hash the message with sha-256 first). I agree with Brian that the hash function (if any) should be part of the key param, similar to the SignatureScheme combination in TLS 1.3. On Wed, Aug 31, 2016 at 3:48 PM, Brian Campbell wrote: > My suggestion is to use those 34 bytes directly as the input into the > signature generation/verification. And for ecdsap256 key params, to use > ECDSA using P-256 and SHA-256 as the signature algorithm. Although the > latter is not strictly necessary AFAICT because 'raw' ECDSA using P-256 c= an > sign 34 bytes okay. > > Admittedly, I could be off base here but that's more what I would have > expected to see. We seem to be talking past one another, however, in just > trying to discuss it. > > > > > On Wed, Aug 31, 2016 at 3:47 PM, Andrei Popov > wrote: > >> Great. >> >> >> >> Then we have 34 bytes we hash with SHA256 and sign. >> >> >> >> When we sign with RSA-PSS or RSA-PKCS, we also specify the use of SHA256 >> in the padding algorithm. For ECDSA, there is no need to pad, and theref= ore >> no need (or opportunity) to use padding hash. >> >> >> >> Brian, what specifically would you like to change WRT hashing? >> >> >> >> *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] >> *Sent:* Wednesday, August 31, 2016 2:42 PM >> *To:* Bill Cox >> *Cc:* Andrei Popov ; Tokbind WG < >> unbearable@ietf.org>; Leif Johansson >> *Subject:* Re: [Unbearable] What Gets Signed (was: Dumb idea: add >> Ed25519 support?) >> >> >> >> Works for me too (I think). >> >> >> >> On Wed, Aug 31, 2016 at 3:34 PM, Bill Cox wrote= : >> >> Works for me. >> >> >> >> On Wed, Aug 31, 2016 at 2:20 PM, Andrei Popov >> wrote: >> >> To sum up, are we in agreement that the concatenation will only include: >> >> >> >> - TokenBindingType value contained in the >> >> TokenBinding.tokenbinding_type field; >> >> - TokenBindingKeyParameters value contained in the >> >> TokenBindingID.key_parameters field; >> >> - Exported keying material (EKM) value obtained from the >> current TLS >> >> connection. >> >> =E2=80=A6 because the label and the ProtocolVersion are presumably alrea= dy in the >> EKM? >> >> >> >> *From:* Bill Cox [mailto:waywardgeek@google.com] >> *Sent:* Wednesday, August 31, 2016 2:01 PM >> *To:* Brian Campbell >> *Cc:* Andrei Popov ; Tokbind WG < >> unbearable@ietf.org>; Leif Johansson >> *Subject:* Re: [Unbearable] Dumb idea: add Ed25519 support? >> >> >> >> On Wed, Aug 31, 2016 at 1:10 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >> >> >> On Wed, Aug 31, 2016 at 1:35 PM, Bill Cox wrote= : >> >> On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell < >> bcampbell@pingidentity.com> wrote: >> >> In which case I'd again suggest that the signature input be the >> concatenated items directly (no hash) and that hashing or not be part of >> the signature scheme associated with each key parameters type. >> >> >> >> Sounds good to me. It fits the standard APIs a bit better. IIUC, this >> result is the same either way, so this is really just a matter of how we >> describe it, right? >> >> >> >> >> After playing around with some APIs yesterday, I don't think that the >> result is actually the same. At least as far as the actual bytes of the >> signature. Conceptually the idea is the same though, AFAIK, and moving t= he >> hash definition to the signature scheme associated with each key paramet= ers >> type removes a hardwired dependency on SHA256 and also eliminates a roun= d >> of hashing for the RSA key parameters types. >> >> >> >> The OpenSSL signing APIs are finicky. They really want to do a digest, >> and you have to know how to call them just right to sign the digest, rat= her >> than the hash of the digest. However, at one point, I was able to verif= y >> that both ways give the same result. I actually use the normal APIs now >> that do the SHA256 while signing. I do not think this requires a docume= nt >> change, other than perhaps some clarification. >> >> >> >> According to the EKM spec (https://tools.ietf.org/html/rfc5705), a >> disambiguating label is required, and we're also supposed to register it= so >> there are no name collisions. Is this something we need to worry about? >> >> >> >> I think that's already (or will be) covered with the registration reques= t >> for "EXPORTER-Token-Binding" in https://tools.ietf.org/html/dr >> aft-ietf-tokbind-protocol-09#section-6.4 >> >> >> >> OK, great. In that case, adding "Token Binding" is redundant, but since >> we use a 32-byte block hash anyway, I don't think it will make any >> difference ins speed, other than the cost of copying the data. >> >> >> >> For some reason, I thought we had already registered "Token Binding" as = a >> unique EKM label. If so, we should probably pass the label to the EKM >> either in addition to, or instead of, hashing it in the final hash. >> >> >> I may have confused things by using the term label for the ASCII string >> "Token Binding" that's part of the concatenation of things. It's not a >> label in the RFC 5705 sense but more of a disambiguater that is tacked o= nto >> the content that is singed. Andrei can perhaps explain it's purpose bett= er. >> >> But just thinking about that makes me wonder if it's necessary. >> ""EXPORTER-Token-Binding" is hashed into the EKM which is then under the >> signature. Is another "Token Binding" string under the signature needed = to >> prevent cross protocol attacks? Doesn't the EKM input label already do >> that? >> >> >> >> Yes, it does, but so long as it does not cause the data to take up >> another 32-byte block, I'm OK with it. >> >> >> >> So, I'm OK with the -09 version. >> >> >> >> Bill >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 > > --94eb2c191d7e5010e8053b65fce0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My understanding is that P-256 can only sign a 32-byte mes= sage (hence why it makes sense to hash the message with sha-256 first).
I agree with Brian that the hash function (if any) should b= e part of the key param, similar to the SignatureScheme combination in TLS = 1.3.

O= n Wed, Aug 31, 2016 at 3:48 PM, Brian Campbell <bcampbell@pingide= ntity.com> wrote:
My suggestion is to use those 34 bytes directly as the input = into the signature generation/verification. And for ecdsap256 key params, t= o use ECDSA using P-256 and SHA-256 as the signature algorithm. Although th= e latter is not strictly necessary AFAICT because 'raw' ECDSA using= P-256 can sign 34 bytes okay.

Admittedly, I could be off base here = but that's more what I would have expected to see. We seem to be talkin= g past one another, however, in just trying to discuss it.=C2=A0
=

=C2=A0


On Wed, Aug 31, 2016 at 3:47 PM, Andrei = Popov <Andrei.Popov@microsoft.com> wrote:
=

Great.

=C2=A0

Then we have 34 bytes we hash with SHA256 and sign.

=C2=A0

When we sign with RSA-PSS or RSA-PKCS, we also spec= ify the use of SHA256 in the padding algorithm. For ECDSA, there is no need= to pad, and therefore no need (or opportunity) to use padding hash.

=C2=A0

Brian, what specifically would you like to change W= RT hashing?

=C2=A0

From: Brian Campbell [mailto:bcampbell@pingiden= tity.com]
Sent: Wednesday, August 31, 2016 2:42 PM
To: Bill Cox <waywardgeek@google.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Tokbind WG <unbearable@ietf.org&g= t;; Leif Johansson <= leifj@sunet.se>
Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: a= dd Ed25519 support?)

=C2=A0

Works for me too (I think).

=C2=A0

On Wed, Aug 31, 2016 at 3:34 PM, Bill Cox <waywardgeek@google.co= m> wrote:

Works for me.

=C2=A0

On Wed, Aug 31, 2016 at 2:20 PM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

To sum up, are we in agreement that the concatenati= on will only include:

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 TokenBindingType value contained in the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TokenBinding.tokenbi= nding_type field;

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 TokenBindingKeyParameters value contained in the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TokenBindingID.key_p= arameters field;

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Exported keying material (EKM) value obtained from the current TLS<= /span>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 connection.

=E2=80=A6 because the label and the ProtocolVersion= are presumably already in the EKM?

=C2=A0

From: Bill Cox [mailto:waywardgeek@google.com]
Sent: Wednesday, August 31, 2016 2:01 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Tokbind WG <unbearable@ietf.org&g= t;; Leif Johansson <= leifj@sunet.se>
Subject: Re: [Unbearable] Dumb idea: add Ed25519 support?<= /u>

=C2=A0

On Wed, Aug 31, 2016 at 1:10 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

=C2=A0

On Wed, Aug 31, 2016 at 1:35 PM, Bill Cox <waywardgeek@google.co= m> wrote:

On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell <= ;bcampbell@= pingidentity.com> wrote:

In which case I'd again suggest that the signatu= re input be the concatenated items directly (no hash) and that hashing or n= ot be part of the signature scheme associated with each key parameters type.=C2=A0

=C2=A0

Sounds good to me.=C2=A0 It fits the standard APIs a= bit better.=C2=A0 IIUC, this result is the same either way, so this is rea= lly just a matter of how we describe it, right?


=C2=A0

After playing around w= ith some APIs yesterday, I don't think that the result is actually the = same. At least as far as the actual bytes of the signature. Conceptually the idea is the same though, AFAIK, and moving the hash defin= ition to the signature scheme associated with each key parameters type remo= ves a hardwired dependency on SHA256 and also eliminates a round of hashing= for the RSA key parameters types.=C2=A0

=C2=A0

The OpenSSL signing APIs are finicky.=C2=A0 They rea= lly want to do a digest, and you have to know how to call them just right t= o sign the digest, rather than the hash of the digest.=C2=A0 However, at one point, I was able to verify that both ways give the same r= esult.=C2=A0 I actually use the normal APIs now that do the SHA256 while si= gning.=C2=A0 I do not think this requires a document change, other than per= haps some clarification.

=C2=A0

According to the EKM spec (https://tools.ietf.org/html/r= fc5705), a disambiguating label is required, and we're also supposed to register it so there are no name collisions.=C2=A0 Is thi= s something we need to worry about?=C2=A0

=C2=A0

I think that's alr= eady (or will be) covered with the registration request for "EXPORTER-= Token-Binding" in https://tools.ietf.org/html/draft-ietf-tokbind-protocol-09#sectio= n-6.4=C2=A0

=C2=A0

OK, great.=C2=A0 In that case, adding "Token Bi= nding" is redundant, but since we use a 32-byte block hash anyway, I d= on't think it will make any difference ins speed, other than the cost of copying the data.=C2=A0

=C2=A0

For some reason, I thought we had already registered= "Token Binding" as a unique EKM label.=C2=A0 If so, we should pr= obably pass the label to the EKM either in addition to, or instead of, hashing it in the final hash.


I may have confused things by using the term = label for the ASCII string "Token Binding" that's part of the= concatenation of things. It's not a label in the RFC 5705 sense but mo= re of a disambiguater that is tacked onto the content that is singed. Andrei can perhaps explain it's purpose better.

But just thinking abou= t that makes me wonder if it's necessary. ""EXPORTER-Token-Bi= nding" is hashed into the EKM which is then under the signature. Is another "Token Binding" string under the signature needed to pre= vent cross protocol attacks? Doesn't the EKM input label already do tha= t?

=C2=A0

Yes, it does, but so long as it does not cause the d= ata to take up another 32-byte block, I'm OK with it.

=C2=A0

So, I'm OK with the -09 version.

=C2=A0

Bill=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


_______________________________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearabl= e



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


--94eb2c191d7e5010e8053b65fce0-- From nobody Wed Aug 31 16:02:11 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 2A52012D7C3 for ; Wed, 31 Aug 2016 16:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 EBPvTxwkNOFQ for ; Wed, 31 Aug 2016 16:02:02 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0092.outbound.protection.outlook.com [104.47.36.92]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851BC12D7B9 for ; Wed, 31 Aug 2016 16:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=c8esGudqVBy+3CtuHY2908OPQVLcgwa5t41r9+rb8Q4=; b=To1kh1QQT5wUN57FcsB7h5B41vsUX1Cba2aktjR90r3YOfo/HeX0/HuZ7GWP/IDri/hcP+f6zqpgBVm7FX43lw6dnPfYISBKHky4qlfkY345bylylSyeJkcDdMuuiQq9fLTgRrNfnwi7ueBTZr3zQ6F/vgKFfep5HaRFj9B6Pvs= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0841.namprd03.prod.outlook.com (10.160.163.147) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Wed, 31 Aug 2016 23:02:01 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Wed, 31 Aug 2016 23:02:00 +0000 From: Andrei Popov To: Nick Harper , Brian Campbell Thread-Topic: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) Thread-Index: AdIDzYe/nNN4QigzR4G2nIa8+fQ4XAAAex2AAABDp4AAAAco4AACRqKAAAA6aYAAABgK8A== Date: Wed, 31 Aug 2016 23:02:00 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 14e6b6b1-11a1-45a4-de2b-08d3d1f2d0f3 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0841; 6:rtfxX+eRZO3zma3Jwo5H+pEeKeHZ7+G/ex2itHldPUGewwGdhZrLLGIVOBY1o9SaAKbULeRdwQPWZbu+Hl7oboCyseWG/2CSG1DbULC7CFvSbqMLw7d70Nd7+b8YGA0VT2YErSKAh+dl2vou7zqYC2IQVcjWeIDmJstbBzA3d4au9ncs1GvAHMqllQKEP+4UZ7OOtcGU1cXdefO/xqooUm0+ovCbbx+5GFLL5+8VK7orQulDkyFpU3vbRd8vVBx1072OPleJFMkF+AAUSmTYimhPARlu2Pg29Zfw7rMjhRch2UXli6OAjlnj+4ldPzP5BBjGZBczx0pVtkrnE8DXgA==; 5:2A7ewaEIO3Pj5O1FwOYLzgvljXTEwxzHaoYmp5H0McnOapcivD/El6TdWp6U6/+j2N8fOigKRNqzA1knGd7V7bvxKx6iiTdvEvvsZ+v339Wt81DaokOi+gdzjAB9cjRXPP4WVHT4SNpoR1W6qoKJ+Q==; 24:tp4TXzC7ghyPDK142fQ7940wNhhRJnNQ1QjTuYaqdci8GjLaEJGPHgOblJ334cF9XDVUyYPQKH42uKAH19Yv/Hh9LrS1/Iloyhs/vqy7JXc=; 7:7khq3eQ5tNXOLo7WRjZHuDxJTggQrA3Pdlamlrac0UxI1dRPHyFO8Eame2pP5WRCAFRzIt74WZHB/YxKe5TWNnCrhUOGVljz6ynvKErv7X1VLchAy8KOJgKce3CKozsvGohc2tkM7ORH40UwVAL17A33uN3OH0qp/Rw843UF3LMUa8XOJu4gWuG0GXJh4IrbZQuBscdI4YS82ZSZ4nw+mOHFQWEeUbGJjm9bkt6xpAIJCG+fsTa6ArwCFD7RO1tK x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0841; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0841; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0841; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(51444003)(377454003)(52314003)(199003)(189002)(24454002)(54356999)(19625215002)(5660300001)(50986999)(76576001)(19300405004)(106356001)(99286002)(790700001)(19580395003)(6116002)(105586002)(86362001)(19617315012)(19580405001)(10400500002)(19609705001)(122556002)(68736007)(5002640100001)(3280700002)(9686002)(5001770100001)(101416001)(16236675004)(97736004)(4326007)(92566002)(2950100001)(7696003)(93886004)(86612001)(33656002)(2900100001)(87936001)(586003)(7846002)(8990500004)(5005710100001)(2906002)(7736002)(10090500001)(102836003)(81166006)(76176999)(8936002)(189998001)(81156014)(7906003)(10290500002)(77096005)(3660700001)(74316002)(15975445007)(8676002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0841; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB08420F479480E94C8B846F6E8CE30CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 23:02:00.5674 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0841 Archived-At: Cc: Tokbind WG , Leif Johansson , Bill Cox Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) 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, 31 Aug 2016 23:02:08 -0000 --_000_CY1PR0301MB08420F479480E94C8B846F6E8CE30CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG93IGFib3V0IHdlIHNheSBzb21ldGhpbmcgbGlrZSB0aGlzOg0K4oCcV2hlbiBhbiByc2EyMDQ4 X3BrY3MxLjUsIHJzYTIwNDhfcHNzIG9yIGVjZHNhcDI1NiBrZXkgaXMgdXNlZCwgdGhlIHNpZ25h dHVyZSBpcyBjb21wdXRlZCBvdmVyIHRoZSBTSEEyNTYgaGFzaCBvZiB0aGUgYnl0ZSBzdHJpbmcg cmVwcmVzZW50aW5nIHRoZSBjb25jYXRlbmF0aW9uIG9m4oCm4oCdPw0KDQpBIG5ldyBUQiBrZXkg cGFyYW1ldGVycyBJRCBzcGVjaWZpY2F0aW9uIGNvdWxkIGRlc2NyaWJlIGEgZGlmZmVyZW50IGNv bnN0cnVjdC4NCg0KRnJvbTogTmljayBIYXJwZXIgW21haWx0bzpuaGFycGVyQGdvb2dsZS5jb21d DQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAzMSwgMjAxNiAzOjU1IFBNDQpUbzogQnJpYW4gQ2Ft cGJlbGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPg0KQ2M6IEFuZHJlaSBQb3BvdiA8QW5k cmVpLlBvcG92QG1pY3Jvc29mdC5jb20+OyBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3Jn PjsgTGVpZiBKb2hhbnNzb24gPGxlaWZqQHN1bmV0LnNlPjsgQmlsbCBDb3ggPHdheXdhcmRnZWVr QGdvb2dsZS5jb20+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFdoYXQgR2V0cyBTaWduZWQg KHdhczogRHVtYiBpZGVhOiBhZGQgRWQyNTUxOSBzdXBwb3J0PykNCg0KTXkgdW5kZXJzdGFuZGlu ZyBpcyB0aGF0IFAtMjU2IGNhbiBvbmx5IHNpZ24gYSAzMi1ieXRlIG1lc3NhZ2UgKGhlbmNlIHdo eSBpdCBtYWtlcyBzZW5zZSB0byBoYXNoIHRoZSBtZXNzYWdlIHdpdGggc2hhLTI1NiBmaXJzdCku DQoNCkkgYWdyZWUgd2l0aCBCcmlhbiB0aGF0IHRoZSBoYXNoIGZ1bmN0aW9uIChpZiBhbnkpIHNo b3VsZCBiZSBwYXJ0IG9mIHRoZSBrZXkgcGFyYW0sIHNpbWlsYXIgdG8gdGhlIFNpZ25hdHVyZVNj aGVtZSBjb21iaW5hdGlvbiBpbiBUTFMgMS4zLg0KDQpPbiBXZWQsIEF1ZyAzMSwgMjAxNiBhdCAz OjQ4IFBNLCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRv OmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQpNeSBzdWdnZXN0aW9uIGlzIHRv IHVzZSB0aG9zZSAzNCBieXRlcyBkaXJlY3RseSBhcyB0aGUgaW5wdXQgaW50byB0aGUgc2lnbmF0 dXJlIGdlbmVyYXRpb24vdmVyaWZpY2F0aW9uLiBBbmQgZm9yIGVjZHNhcDI1NiBrZXkgcGFyYW1z LCB0byB1c2UgRUNEU0EgdXNpbmcgUC0yNTYgYW5kIFNIQS0yNTYgYXMgdGhlIHNpZ25hdHVyZSBh bGdvcml0aG0uIEFsdGhvdWdoIHRoZSBsYXR0ZXIgaXMgbm90IHN0cmljdGx5IG5lY2Vzc2FyeSBB RkFJQ1QgYmVjYXVzZSAncmF3JyBFQ0RTQSB1c2luZyBQLTI1NiBjYW4gc2lnbiAzNCBieXRlcyBv a2F5Lg0KDQpBZG1pdHRlZGx5LCBJIGNvdWxkIGJlIG9mZiBiYXNlIGhlcmUgYnV0IHRoYXQncyBt b3JlIHdoYXQgSSB3b3VsZCBoYXZlIGV4cGVjdGVkIHRvIHNlZS4gV2Ugc2VlbSB0byBiZSB0YWxr aW5nIHBhc3Qgb25lIGFub3RoZXIsIGhvd2V2ZXIsIGluIGp1c3QgdHJ5aW5nIHRvIGRpc2N1c3Mg aXQuDQoNCg0KDQpPbiBXZWQsIEF1ZyAzMSwgMjAxNiBhdCAzOjQ3IFBNLCBBbmRyZWkgUG9wb3Yg PEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0 LmNvbT4+IHdyb3RlOg0KR3JlYXQuDQoNClRoZW4gd2UgaGF2ZSAzNCBieXRlcyB3ZSBoYXNoIHdp dGggU0hBMjU2IGFuZCBzaWduLg0KDQpXaGVuIHdlIHNpZ24gd2l0aCBSU0EtUFNTIG9yIFJTQS1Q S0NTLCB3ZSBhbHNvIHNwZWNpZnkgdGhlIHVzZSBvZiBTSEEyNTYgaW4gdGhlIHBhZGRpbmcgYWxn b3JpdGhtLiBGb3IgRUNEU0EsIHRoZXJlIGlzIG5vIG5lZWQgdG8gcGFkLCBhbmQgdGhlcmVmb3Jl IG5vIG5lZWQgKG9yIG9wcG9ydHVuaXR5KSB0byB1c2UgcGFkZGluZyBoYXNoLg0KDQpCcmlhbiwg d2hhdCBzcGVjaWZpY2FsbHkgd291bGQgeW91IGxpa2UgdG8gY2hhbmdlIFdSVCBoYXNoaW5nPw0K DQpGcm9tOiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29t PG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT5dDQpTZW50OiBXZWRuZXNkYXksIEF1 Z3VzdCAzMSwgMjAxNiAyOjQyIFBNDQpUbzogQmlsbCBDb3ggPHdheXdhcmRnZWVrQGdvb2dsZS5j b208bWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb20+Pg0KQ2M6IEFuZHJlaSBQb3BvdiA8QW5k cmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29t Pj47IFRva2JpbmQgV0cgPHVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOnVuYmVhcmFibGVAaWV0 Zi5vcmc+PjsgTGVpZiBKb2hhbnNzb24gPGxlaWZqQHN1bmV0LnNlPG1haWx0bzpsZWlmakBzdW5l dC5zZT4+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFdoYXQgR2V0cyBTaWduZWQgKHdhczog RHVtYiBpZGVhOiBhZGQgRWQyNTUxOSBzdXBwb3J0PykNCg0KV29ya3MgZm9yIG1lIHRvbyAoSSB0 aGluaykuDQoNCk9uIFdlZCwgQXVnIDMxLCAyMDE2IGF0IDM6MzQgUE0sIEJpbGwgQ294IDx3YXl3 YXJkZ2Vla0Bnb29nbGUuY29tPG1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPj4gd3JvdGU6 DQpXb3JrcyBmb3IgbWUuDQoNCk9uIFdlZCwgQXVnIDMxLCAyMDE2IGF0IDI6MjAgUE0sIEFuZHJl aSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBt aWNyb3NvZnQuY29tPj4gd3JvdGU6DQpUbyBzdW0gdXAsIGFyZSB3ZSBpbiBhZ3JlZW1lbnQgdGhh dCB0aGUgY29uY2F0ZW5hdGlvbiB3aWxsIG9ubHkgaW5jbHVkZToNCg0KDQotICAgICAgICAgIFRv a2VuQmluZGluZ1R5cGUgdmFsdWUgY29udGFpbmVkIGluIHRoZQ0KICAgICAgVG9rZW5CaW5kaW5n LnRva2VuYmluZGluZ190eXBlIGZpZWxkOw0KDQotICAgICAgICAgIFRva2VuQmluZGluZ0tleVBh cmFtZXRlcnMgdmFsdWUgY29udGFpbmVkIGluIHRoZQ0KICAgICAgVG9rZW5CaW5kaW5nSUQua2V5 X3BhcmFtZXRlcnMgZmllbGQ7DQoNCi0gICAgICAgICAgRXhwb3J0ZWQga2V5aW5nIG1hdGVyaWFs IChFS00pIHZhbHVlIG9idGFpbmVkIGZyb20gdGhlIGN1cnJlbnQgVExTDQogICAgICBjb25uZWN0 aW9uLg0K4oCmIGJlY2F1c2UgdGhlIGxhYmVsIGFuZCB0aGUgUHJvdG9jb2xWZXJzaW9uIGFyZSBw cmVzdW1hYmx5IGFscmVhZHkgaW4gdGhlIEVLTT8NCg0KRnJvbTogQmlsbCBDb3ggW21haWx0bzp3 YXl3YXJkZ2Vla0Bnb29nbGUuY29tPG1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPl0NClNl bnQ6IFdlZG5lc2RheSwgQXVndXN0IDMxLCAyMDE2IDI6MDEgUE0NClRvOiBCcmlhbiBDYW1wYmVs bCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRp dHkuY29tPj4NCkNjOiBBbmRyZWkgUG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPG1h aWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+OyBUb2tiaW5kIFdHIDx1bmJlYXJhYmxl QGlldGYub3JnPG1haWx0bzp1bmJlYXJhYmxlQGlldGYub3JnPj47IExlaWYgSm9oYW5zc29uIDxs ZWlmakBzdW5ldC5zZTxtYWlsdG86bGVpZmpAc3VuZXQuc2U+Pg0KU3ViamVjdDogUmU6IFtVbmJl YXJhYmxlXSBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBvcnQ/DQoNCk9uIFdlZCwgQXVnIDMx LCAyMDE2IGF0IDE6MTAgUE0sIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5 LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3cm90ZToNCg0KT24gV2Vk LCBBdWcgMzEsIDIwMTYgYXQgMTozNSBQTSwgQmlsbCBDb3ggPHdheXdhcmRnZWVrQGdvb2dsZS5j b208bWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb20+PiB3cm90ZToNCk9uIFdlZCwgQXVnIDMx LCAyMDE2IGF0IDEyOjEyIFBNLCBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0 eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4gd3JvdGU6DQpJbiB3aGlj aCBjYXNlIEknZCBhZ2FpbiBzdWdnZXN0IHRoYXQgdGhlIHNpZ25hdHVyZSBpbnB1dCBiZSB0aGUg Y29uY2F0ZW5hdGVkIGl0ZW1zIGRpcmVjdGx5IChubyBoYXNoKSBhbmQgdGhhdCBoYXNoaW5nIG9y IG5vdCBiZSBwYXJ0IG9mIHRoZSBzaWduYXR1cmUgc2NoZW1lIGFzc29jaWF0ZWQgd2l0aCBlYWNo IGtleSBwYXJhbWV0ZXJzIHR5cGUuDQoNClNvdW5kcyBnb29kIHRvIG1lLiAgSXQgZml0cyB0aGUg c3RhbmRhcmQgQVBJcyBhIGJpdCBiZXR0ZXIuICBJSVVDLCB0aGlzIHJlc3VsdCBpcyB0aGUgc2Ft ZSBlaXRoZXIgd2F5LCBzbyB0aGlzIGlzIHJlYWxseSBqdXN0IGEgbWF0dGVyIG9mIGhvdyB3ZSBk ZXNjcmliZSBpdCwgcmlnaHQ/DQoNCg0KQWZ0ZXIgcGxheWluZyBhcm91bmQgd2l0aCBzb21lIEFQ SXMgeWVzdGVyZGF5LCBJIGRvbid0IHRoaW5rIHRoYXQgdGhlIHJlc3VsdCBpcyBhY3R1YWxseSB0 aGUgc2FtZS4gQXQgbGVhc3QgYXMgZmFyIGFzIHRoZSBhY3R1YWwgYnl0ZXMgb2YgdGhlIHNpZ25h dHVyZS4gQ29uY2VwdHVhbGx5IHRoZSBpZGVhIGlzIHRoZSBzYW1lIHRob3VnaCwgQUZBSUssIGFu ZCBtb3ZpbmcgdGhlIGhhc2ggZGVmaW5pdGlvbiB0byB0aGUgc2lnbmF0dXJlIHNjaGVtZSBhc3Nv Y2lhdGVkIHdpdGggZWFjaCBrZXkgcGFyYW1ldGVycyB0eXBlIHJlbW92ZXMgYSBoYXJkd2lyZWQg ZGVwZW5kZW5jeSBvbiBTSEEyNTYgYW5kIGFsc28gZWxpbWluYXRlcyBhIHJvdW5kIG9mIGhhc2hp bmcgZm9yIHRoZSBSU0Ega2V5IHBhcmFtZXRlcnMgdHlwZXMuDQoNClRoZSBPcGVuU1NMIHNpZ25p bmcgQVBJcyBhcmUgZmluaWNreS4gIFRoZXkgcmVhbGx5IHdhbnQgdG8gZG8gYSBkaWdlc3QsIGFu ZCB5b3UgaGF2ZSB0byBrbm93IGhvdyB0byBjYWxsIHRoZW0ganVzdCByaWdodCB0byBzaWduIHRo ZSBkaWdlc3QsIHJhdGhlciB0aGFuIHRoZSBoYXNoIG9mIHRoZSBkaWdlc3QuICBIb3dldmVyLCBh dCBvbmUgcG9pbnQsIEkgd2FzIGFibGUgdG8gdmVyaWZ5IHRoYXQgYm90aCB3YXlzIGdpdmUgdGhl IHNhbWUgcmVzdWx0LiAgSSBhY3R1YWxseSB1c2UgdGhlIG5vcm1hbCBBUElzIG5vdyB0aGF0IGRv IHRoZSBTSEEyNTYgd2hpbGUgc2lnbmluZy4gIEkgZG8gbm90IHRoaW5rIHRoaXMgcmVxdWlyZXMg YSBkb2N1bWVudCBjaGFuZ2UsIG90aGVyIHRoYW4gcGVyaGFwcyBzb21lIGNsYXJpZmljYXRpb24u DQoNCkFjY29yZGluZyB0byB0aGUgRUtNIHNwZWMgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM1NzA1KSwgYSBkaXNhbWJpZ3VhdGluZyBsYWJlbCBpcyByZXF1aXJlZCwgYW5kIHdlJ3Jl IGFsc28gc3VwcG9zZWQgdG8gcmVnaXN0ZXIgaXQgc28gdGhlcmUgYXJlIG5vIG5hbWUgY29sbGlz aW9ucy4gIElzIHRoaXMgc29tZXRoaW5nIHdlIG5lZWQgdG8gd29ycnkgYWJvdXQ/DQoNCkkgdGhp bmsgdGhhdCdzIGFscmVhZHkgKG9yIHdpbGwgYmUpIGNvdmVyZWQgd2l0aCB0aGUgcmVnaXN0cmF0 aW9uIHJlcXVlc3QgZm9yICJFWFBPUlRFUi1Ub2tlbi1CaW5kaW5nIiBpbiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10b2tiaW5kLXByb3RvY29sLTA5I3NlY3Rpb24tNi40 DQoNCk9LLCBncmVhdC4gIEluIHRoYXQgY2FzZSwgYWRkaW5nICJUb2tlbiBCaW5kaW5nIiBpcyBy ZWR1bmRhbnQsIGJ1dCBzaW5jZSB3ZSB1c2UgYSAzMi1ieXRlIGJsb2NrIGhhc2ggYW55d2F5LCBJ IGRvbid0IHRoaW5rIGl0IHdpbGwgbWFrZSBhbnkgZGlmZmVyZW5jZSBpbnMgc3BlZWQsIG90aGVy IHRoYW4gdGhlIGNvc3Qgb2YgY29weWluZyB0aGUgZGF0YS4NCg0KRm9yIHNvbWUgcmVhc29uLCBJ IHRob3VnaHQgd2UgaGFkIGFscmVhZHkgcmVnaXN0ZXJlZCAiVG9rZW4gQmluZGluZyIgYXMgYSB1 bmlxdWUgRUtNIGxhYmVsLiAgSWYgc28sIHdlIHNob3VsZCBwcm9iYWJseSBwYXNzIHRoZSBsYWJl bCB0byB0aGUgRUtNIGVpdGhlciBpbiBhZGRpdGlvbiB0bywgb3IgaW5zdGVhZCBvZiwgaGFzaGlu ZyBpdCBpbiB0aGUgZmluYWwgaGFzaC4NCg0KSSBtYXkgaGF2ZSBjb25mdXNlZCB0aGluZ3MgYnkg dXNpbmcgdGhlIHRlcm0gbGFiZWwgZm9yIHRoZSBBU0NJSSBzdHJpbmcgIlRva2VuIEJpbmRpbmci IHRoYXQncyBwYXJ0IG9mIHRoZSBjb25jYXRlbmF0aW9uIG9mIHRoaW5ncy4gSXQncyBub3QgYSBs YWJlbCBpbiB0aGUgUkZDIDU3MDUgc2Vuc2UgYnV0IG1vcmUgb2YgYSBkaXNhbWJpZ3VhdGVyIHRo YXQgaXMgdGFja2VkIG9udG8gdGhlIGNvbnRlbnQgdGhhdCBpcyBzaW5nZWQuIEFuZHJlaSBjYW4g cGVyaGFwcyBleHBsYWluIGl0J3MgcHVycG9zZSBiZXR0ZXIuDQpCdXQganVzdCB0aGlua2luZyBh Ym91dCB0aGF0IG1ha2VzIG1lIHdvbmRlciBpZiBpdCdzIG5lY2Vzc2FyeS4gIiJFWFBPUlRFUi1U b2tlbi1CaW5kaW5nIiBpcyBoYXNoZWQgaW50byB0aGUgRUtNIHdoaWNoIGlzIHRoZW4gdW5kZXIg dGhlIHNpZ25hdHVyZS4gSXMgYW5vdGhlciAiVG9rZW4gQmluZGluZyIgc3RyaW5nIHVuZGVyIHRo ZSBzaWduYXR1cmUgbmVlZGVkIHRvIHByZXZlbnQgY3Jvc3MgcHJvdG9jb2wgYXR0YWNrcz8gRG9l c24ndCB0aGUgRUtNIGlucHV0IGxhYmVsIGFscmVhZHkgZG8gdGhhdD8NCg0KWWVzLCBpdCBkb2Vz LCBidXQgc28gbG9uZyBhcyBpdCBkb2VzIG5vdCBjYXVzZSB0aGUgZGF0YSB0byB0YWtlIHVwIGFu b3RoZXIgMzItYnl0ZSBibG9jaywgSSdtIE9LIHdpdGggaXQuDQoNClNvLCBJJ20gT0sgd2l0aCB0 aGUgLTA5IHZlcnNpb24uDQoNCkJpbGwNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QNClVuYmVh cmFibGVAaWV0Zi5vcmc8bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVW5iZWFyYWJsZSBtYWlsaW5nIGxpc3QN ClVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOlVuYmVhcmFibGVAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUNCg0K --_000_CY1PR0301MB08420F479480E94C8B846F6E8CE30CY1PR0301MB0842_ 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 dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ SG93IGFib3V0IHdlIHNheSBzb21ldGhpbmcgbGlrZSB0aGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+4oCcV2hlbiBhbiByc2Ey MDQ4X3BrY3MxLjUsIHJzYTIwNDhfcHNzIG9yIGVjZHNhcDI1NiBrZXkgaXMgdXNlZCwgdGhlIHNp Z25hdHVyZSBpcyBjb21wdXRlZCBvdmVyIHRoZSBTSEEyNTYgaGFzaCBvZiB0aGUgYnl0ZSBzdHJp bmcgcmVwcmVzZW50aW5nIHRoZSBjb25jYXRlbmF0aW9uIG9m4oCm4oCdPzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5BIG5ldyBUQiBrZXkgcGFyYW1ldGVycyBJRCBzcGVjaWZpY2F0aW9uIGNvdWxkIGRlc2NyaWJl IGEgZGlmZmVyZW50IGNvbnN0cnVjdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+IE5pY2sgSGFycGVyIFttYWlsdG86bmhhcnBlckBnb29nbGUuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDMxLCAyMDE2IDM6NTUgUE08 YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGxAcGluZ2lkZW50aXR5 LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEFuZHJlaSBQb3BvdiAmbHQ7QW5kcmVpLlBvcG92QG1p Y3Jvc29mdC5jb20mZ3Q7OyBUb2tiaW5kIFdHICZsdDt1bmJlYXJhYmxlQGlldGYub3JnJmd0Ozsg TGVpZiBKb2hhbnNzb24gJmx0O2xlaWZqQHN1bmV0LnNlJmd0OzsgQmlsbCBDb3ggJmx0O3dheXdh cmRnZWVrQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJs ZV0gV2hhdCBHZXRzIFNpZ25lZCAod2FzOiBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBvcnQ/ KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IHVuZGVyc3RhbmRpbmcg aXMgdGhhdCBQLTI1NiBjYW4gb25seSBzaWduIGEgMzItYnl0ZSBtZXNzYWdlIChoZW5jZSB3aHkg aXQgbWFrZXMgc2Vuc2UgdG8gaGFzaCB0aGUgbWVzc2FnZSB3aXRoIHNoYS0yNTYgZmlyc3QpLjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhZ3JlZSB3aXRo IEJyaWFuIHRoYXQgdGhlIGhhc2ggZnVuY3Rpb24gKGlmIGFueSkgc2hvdWxkIGJlIHBhcnQgb2Yg dGhlIGtleSBwYXJhbSwgc2ltaWxhciB0byB0aGUgU2lnbmF0dXJlU2NoZW1lIGNvbWJpbmF0aW9u IGluIFRMUyAxLjMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFdlZCwgQXVnIDMxLCAyMDE2IGF0IDM6NDggUE0sIEJyaWFuIENhbXBiZWxs ICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0i X2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TXkgc3VnZ2VzdGlvbiBpcyB0byB1c2UgdGhvc2UgMzQgYnl0ZXMgZGlyZWN0bHkgYXMgdGhlIGlu cHV0IGludG8gdGhlIHNpZ25hdHVyZSBnZW5lcmF0aW9uL3ZlcmlmaWNhdGlvbi4gQW5kIGZvciBl Y2RzYXAyNTYga2V5IHBhcmFtcywgdG8gdXNlIEVDRFNBIHVzaW5nIFAtMjU2IGFuZCBTSEEtMjU2 IGFzIHRoZSBzaWduYXR1cmUgYWxnb3JpdGhtLiBBbHRob3VnaCB0aGUgbGF0dGVyIGlzIG5vdCBz dHJpY3RseQ0KIG5lY2Vzc2FyeSBBRkFJQ1QgYmVjYXVzZSAncmF3JyBFQ0RTQSB1c2luZyBQLTI1 NiBjYW4gc2lnbiAzNCBieXRlcyBva2F5Ljxicj4NCjxicj4NCkFkbWl0dGVkbHksIEkgY291bGQg YmUgb2ZmIGJhc2UgaGVyZSBidXQgdGhhdCdzIG1vcmUgd2hhdCBJIHdvdWxkIGhhdmUgZXhwZWN0 ZWQgdG8gc2VlLiBXZSBzZWVtIHRvIGJlIHRhbGtpbmcgcGFzdCBvbmUgYW5vdGhlciwgaG93ZXZl ciwgaW4ganVzdCB0cnlpbmcgdG8gZGlzY3VzcyBpdC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48YnI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBBdWcgMzEsIDIwMTYgYXQgMzo0NyBQTSwg QW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5j b20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkdyZWF0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhlbiB3ZSBoYXZlIDM0IGJ5dGVzIHdlIGhh c2ggd2l0aCBTSEEyNTYgYW5kIHNpZ24uDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldoZW4gd2Ugc2ln biB3aXRoIFJTQS1QU1Mgb3IgUlNBLVBLQ1MsIHdlIGFsc28gc3BlY2lmeSB0aGUgdXNlIG9mIFNI QTI1NiBpbiB0aGUgcGFkZGluZyBhbGdvcml0aG0uIEZvciBFQ0RTQSwgdGhlcmUNCiBpcyBubyBu ZWVkIHRvIHBhZCwgYW5kIHRoZXJlZm9yZSBubyBuZWVkIChvciBvcHBvcnR1bml0eSkgdG8gdXNl IHBhZGRpbmcgaGFzaC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkJyaWFuLCB3aGF0IHNwZWNpZmljYWxs eSB3b3VsZCB5b3UgbGlrZSB0byBjaGFuZ2UgV1JUIGhhc2hpbmc/PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQnJpYW4gQ2FtcGJlbGwgW21h aWx0bzo8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0i X2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYgMjo0MiBQTTxicj4NCjxiPlRvOjwvYj4gQmls bCBDb3ggJmx0OzxhIGhyZWY9Im1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBB bmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDs7IFRv a2JpbmQgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzp1bmJlYXJhYmxlQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+dW5iZWFyYWJsZUBpZXRmLm9yZzwvYT4mZ3Q7OyBMZWlmIEpvaGFuc3NvbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmxlaWZqQHN1bmV0LnNlIiB0YXJnZXQ9Il9ibGFuayI+bGVpZmpAc3Vu ZXQuc2U8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIFdoYXQg R2V0cyBTaWduZWQgKHdhczogRHVtYiBpZGVhOiBhZGQgRWQyNTUxOSBzdXBwb3J0Pyk8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Xb3JrcyBm b3IgbWUgdG9vIChJIHRoaW5rKS4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgQXVnIDMxLCAyMDE2IGF0IDM6MzQgUE0sIEJpbGwgQ294 ICZsdDs8YSBocmVmPSJtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPndheXdhcmRnZWVrQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V29ya3MgZm9yIG1lLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBBdWcg MzEsIDIwMTYgYXQgMjoyMCBQTSwgQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5k cmVpLlBvcG92QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWlj cm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UbyBzdW0gdXAsIGFyZSB3ZSBpbiBhZ3Jl ZW1lbnQgdGhhdCB0aGUgY29uY2F0ZW5hdGlvbiB3aWxsIG9ubHkgaW5jbHVkZTo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG9rZW5C aW5kaW5nVHlwZSB2YWx1ZSBjb250YWluZWQgaW4gdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBUb2tlbkJpbmRpbmcudG9rZW5iaW5kaW5nX3R5cGUgZmllbGQ7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG9rZW5CaW5kaW5nS2V5 UGFyYW1ldGVycyB2YWx1ZSBjb250YWluZWQgaW4gdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBUb2tlbkJpbmRpbmdJRC5rZXlfcGFyYW1ldGVycyBmaWVsZDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi08L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5FeHBvcnRlZCBrZXlpbmcg bWF0ZXJpYWwgKEVLTSkgdmFsdWUgb2J0YWluZWQgZnJvbSB0aGUgY3VycmVudCBUTFM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbm5lY3Rpb24uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuKApiBiZWNh dXNlIHRoZSBsYWJlbCBhbmQgdGhlIFByb3RvY29sVmVyc2lvbiBhcmUgcHJlc3VtYWJseSBhbHJl YWR5IGluIHRoZSBFS00/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4gQmlsbCBDb3ggW21haWx0bzo8YSBocmVmPSJtYWlsdG86d2F5d2FyZGdl ZWtAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPndheXdhcmRnZWVrQGdvb2dsZS5jb208L2E+ XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDMxLCAyMDE2IDI6MDEgUE08 YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBi ZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBBbmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9 Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJl aS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZndDs7IFRva2JpbmQgV0cgJmx0OzxhIGhyZWY9Im1h aWx0bzp1bmJlYXJhYmxlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dW5iZWFyYWJsZUBpZXRm Lm9yZzwvYT4mZ3Q7OyBMZWlmIEpvaGFuc3NvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlaWZqQHN1 bmV0LnNlIiB0YXJnZXQ9Il9ibGFuayI+bGVpZmpAc3VuZXQuc2U8L2E+Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIER1bWIgaWRlYTogYWRkIEVkMjU1MTkgc3VwcG9y dD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5PbiBXZWQsIEF1ZyAzMSwgMjAxNiBhdCAxOjEwIFBNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEg aHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBBdWcgMzEsIDIwMTYgYXQgMTozNSBQ TSwgQmlsbCBDb3ggJmx0OzxhIGhyZWY9Im1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tIiB0 YXJnZXQ9Il9ibGFuayI+d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwg QXVnIDMxLCAyMDE2IGF0IDEyOjEyIFBNLCBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SW4gd2hpY2ggY2FzZSBJJ2QgYWdhaW4gc3VnZ2VzdCB0aGF0IHRoZSBz aWduYXR1cmUgaW5wdXQgYmUgdGhlIGNvbmNhdGVuYXRlZCBpdGVtcyBkaXJlY3RseSAobm8gaGFz aCkgYW5kIHRoYXQgaGFzaGluZyBvciBub3QgYmUgcGFydCBvZiB0aGUgc2lnbmF0dXJlIHNjaGVt ZSBhc3NvY2lhdGVkIHdpdGggZWFjaA0KIGtleSBwYXJhbWV0ZXJzIHR5cGUuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5Tb3VuZHMgZ29vZCB0byBtZS4mbmJzcDsgSXQgZml0cyB0aGUgc3RhbmRhcmQg QVBJcyBhIGJpdCBiZXR0ZXIuJm5ic3A7IElJVUMsIHRoaXMgcmVzdWx0IGlzIHRoZSBzYW1lIGVp dGhlciB3YXksIHNvIHRoaXMgaXMgcmVhbGx5IGp1c3QgYSBtYXR0ZXIgb2YgaG93IHdlIGRlc2Ny aWJlIGl0LCByaWdodD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0K Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzM4NzYxRCI+QWZ0ZXIgcGxheWluZyBhcm91bmQgd2l0aCBzb21lIEFQ SXMgeWVzdGVyZGF5LCBJIGRvbid0IHRoaW5rIHRoYXQgdGhlIHJlc3VsdCBpcyBhY3R1YWxseSB0 aGUgc2FtZS4gQXQgbGVhc3QgYXMgZmFyIGFzIHRoZSBhY3R1YWwgYnl0ZXMgb2YgdGhlIHNpZ25h dHVyZS4NCiBDb25jZXB0dWFsbHkgdGhlIGlkZWEgaXMgdGhlIHNhbWUgdGhvdWdoLCBBRkFJSywg YW5kIG1vdmluZyB0aGUgaGFzaCBkZWZpbml0aW9uIHRvIHRoZSBzaWduYXR1cmUgc2NoZW1lIGFz c29jaWF0ZWQgd2l0aCBlYWNoIGtleSBwYXJhbWV0ZXJzIHR5cGUgcmVtb3ZlcyBhIGhhcmR3aXJl ZCBkZXBlbmRlbmN5IG9uIFNIQTI1NiBhbmQgYWxzbyBlbGltaW5hdGVzIGEgcm91bmQgb2YgaGFz aGluZyBmb3IgdGhlIFJTQSBrZXkgcGFyYW1ldGVycyB0eXBlcy4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBPcGVuU1NMIHNp Z25pbmcgQVBJcyBhcmUgZmluaWNreS4mbmJzcDsgVGhleSByZWFsbHkgd2FudCB0byBkbyBhIGRp Z2VzdCwgYW5kIHlvdSBoYXZlIHRvIGtub3cgaG93IHRvIGNhbGwgdGhlbSBqdXN0IHJpZ2h0IHRv IHNpZ24gdGhlIGRpZ2VzdCwgcmF0aGVyIHRoYW4gdGhlIGhhc2ggb2YgdGhlIGRpZ2VzdC4mbmJz cDsNCiBIb3dldmVyLCBhdCBvbmUgcG9pbnQsIEkgd2FzIGFibGUgdG8gdmVyaWZ5IHRoYXQgYm90 aCB3YXlzIGdpdmUgdGhlIHNhbWUgcmVzdWx0LiZuYnNwOyBJIGFjdHVhbGx5IHVzZSB0aGUgbm9y bWFsIEFQSXMgbm93IHRoYXQgZG8gdGhlIFNIQTI1NiB3aGlsZSBzaWduaW5nLiZuYnNwOyBJIGRv IG5vdCB0aGluayB0aGlzIHJlcXVpcmVzIGEgZG9jdW1lbnQgY2hhbmdlLCBvdGhlciB0aGFuIHBl cmhhcHMgc29tZSBjbGFyaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFj Y29yZGluZyB0byB0aGUgRUtNIHNwZWMgKDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM1NzA1IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzU3MDU8L2E+KSwgYSBkaXNhbWJpZ3VhdGluZyBsYWJlbCBpcyByZXF1aXJlZCwgYW5kIHdl J3JlDQogYWxzbyBzdXBwb3NlZCB0byByZWdpc3RlciBpdCBzbyB0aGVyZSBhcmUgbm8gbmFtZSBj b2xsaXNpb25zLiZuYnNwOyBJcyB0aGlzIHNvbWV0aGluZyB3ZSBuZWVkIHRvIHdvcnJ5IGFib3V0 PyZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iY29sb3I6IzM4NzYxRCI+SSB0aGluayB0aGF0J3MgYWxyZWFkeSAob3Igd2lsbCBiZSkg Y292ZXJlZCB3aXRoIHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdCBmb3IgJnF1b3Q7RVhQT1JURVIt VG9rZW4tQmluZGluZyZxdW90OyBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtdG9rYmluZC1wcm90b2NvbC0wOSNzZWN0aW9uLTYuNCIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdG9rYmluZC1w cm90b2NvbC0wOSNzZWN0aW9uLTYuNDwvYT4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5PSywgZ3JlYXQuJm5ic3A7IEluIHRoYXQgY2FzZSwgYWRk aW5nICZxdW90O1Rva2VuIEJpbmRpbmcmcXVvdDsgaXMgcmVkdW5kYW50LCBidXQgc2luY2Ugd2Ug dXNlIGEgMzItYnl0ZSBibG9jayBoYXNoIGFueXdheSwgSSBkb24ndCB0aGluayBpdCB3aWxsIG1h a2UgYW55IGRpZmZlcmVuY2UgaW5zIHNwZWVkLCBvdGhlciB0aGFuIHRoZQ0KIGNvc3Qgb2YgY29w eWluZyB0aGUgZGF0YS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gb3Igc29t ZSByZWFzb24sIEkgdGhvdWdodCB3ZSBoYWQgYWxyZWFkeSByZWdpc3RlcmVkICZxdW90O1Rva2Vu IEJpbmRpbmcmcXVvdDsgYXMgYSB1bmlxdWUgRUtNIGxhYmVsLiZuYnNwOyBJZiBzbywgd2Ugc2hv dWxkIHByb2JhYmx5IHBhc3MgdGhlIGxhYmVsIHRvIHRoZSBFS00gZWl0aGVyIGluIGFkZGl0aW9u IHRvLCBvciBpbnN0ZWFkDQogb2YsIGhhc2hpbmcgaXQgaW4gdGhlIGZpbmFsIGhhc2guPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxzcGFuIHN0eWxlPSJjb2xvcjojMzg3NjFE Ij5JIG1heSBoYXZlIGNvbmZ1c2VkIHRoaW5ncyBieSB1c2luZyB0aGUgdGVybSBsYWJlbCBmb3Ig dGhlIEFTQ0lJIHN0cmluZyAmcXVvdDtUb2tlbiBCaW5kaW5nJnF1b3Q7IHRoYXQncyBwYXJ0IG9m IHRoZSBjb25jYXRlbmF0aW9uIG9mIHRoaW5ncy4gSXQncyBub3QgYSBsYWJlbCBpbiB0aGUgUkZD IDU3MDUgc2Vuc2UgYnV0IG1vcmUgb2YgYSBkaXNhbWJpZ3VhdGVyIHRoYXQgaXMgdGFja2VkIG9u dG8gdGhlIGNvbnRlbnQNCiB0aGF0IGlzIHNpbmdlZC4gQW5kcmVpIGNhbiBwZXJoYXBzIGV4cGxh aW4gaXQncyBwdXJwb3NlIGJldHRlci4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzM4NzYxRCI+ QnV0IGp1c3QgdGhpbmtpbmcgYWJvdXQgdGhhdCBtYWtlcyBtZSB3b25kZXIgaWYgaXQncyBuZWNl c3NhcnkuICZxdW90OyZxdW90O0VYUE9SVEVSLVRva2VuLUJpbmRpbmcmcXVvdDsgaXMgaGFzaGVk IGludG8gdGhlIEVLTSB3aGljaCBpcyB0aGVuIHVuZGVyIHRoZSBzaWduYXR1cmUuIElzDQogYW5v dGhlciAmcXVvdDtUb2tlbiBCaW5kaW5nJnF1b3Q7IHN0cmluZyB1bmRlciB0aGUgc2lnbmF0dXJl IG5lZWRlZCB0byBwcmV2ZW50IGNyb3NzIHByb3RvY29sIGF0dGFja3M/IERvZXNuJ3QgdGhlIEVL TSBpbnB1dCBsYWJlbCBhbHJlYWR5IGRvIHRoYXQ/DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5ZZXMsIGl0IGRvZXMsIGJ1dCBzbyBsb25nIGFzIGl0IGRv ZXMgbm90IGNhdXNlIHRoZSBkYXRhIHRvIHRha2UgdXAgYW5vdGhlciAzMi1ieXRlIGJsb2NrLCBJ J20gT0sgd2l0aCBpdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlNvLCBJJ20gT0sgd2l0aCB0aGUgLTA5IHZlcnNpb24uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CaWxsJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhy ZWY9Im1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VW5iZWFyYWJs ZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3VuYmVhcmFibGUiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGU8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpVbmJlYXJhYmxlQGlldGYub3JnIj5VbmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFy YWJsZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_CY1PR0301MB08420F479480E94C8B846F6E8CE30CY1PR0301MB0842_-- From nobody Wed Aug 31 16:10: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 9B79512D1DA for ; Wed, 31 Aug 2016 16:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 TIiFraxQTSic for ; Wed, 31 Aug 2016 16:10:40 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0093.outbound.protection.outlook.com [104.47.33.93]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E4C212B043 for ; Wed, 31 Aug 2016 16:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+2v36am8MhonMx/FCIQJN8Ur/QT4v64PArtJVpaXTNs=; b=m2rGG38PmVfieJWHetH5NDMXetZjoTieVUHLP05aRgIUHSxil9+vl2yR1gWGNpRMY4u3tfkA3IhBHsqA/fauxD7USJPFv1aAVE6msL/noSrgIwuuMSzxbU4H97J4lATVFD54nGX57CXuQdJYmioBfDn2NZzFn3yxWuYk2Z8L6o0= Received: from DM2PR0301MB0637.namprd03.prod.outlook.com (10.160.96.11) by DM2PR0301MB0845.namprd03.prod.outlook.com (10.160.215.143) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.9; Wed, 31 Aug 2016 23:10:35 +0000 Received: from DM2PR0301MB0637.namprd03.prod.outlook.com ([10.160.96.11]) by DM2PR0301MB0637.namprd03.prod.outlook.com ([10.160.96.11]) with mapi id 15.01.0599.010; Wed, 31 Aug 2016 23:10:35 +0000 From: Mike Jones To: Andrei Popov , Nick Harper , Brian Campbell Thread-Topic: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) Thread-Index: AdIDzYe/nNN4QigzR4G2nIa8+fQ4XAAAex2AAABDp4AAAAco4AACRqKAAAA6aYAAABgK8AAAOeBQ Date: Wed, 31 Aug 2016 23:10:35 +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: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.91.120] x-ms-office365-filtering-correlation-id: ea7311b1-3a85-49d2-7b5c-08d3d1f403db x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0845; 6:gLbXNbP0CVfvkXnIrqOJzzoVDSocXrY3QVNaF59m42WreQ5qKy4svNKrsL+j/PIIe8A0+Hi3l8dU2QykkdMu64o2D0R+l/5/s3aknBNfUxPRqlYVK1A/tpG5JgDvsxdThuDEWlrefGJ1OnrnAYbu5FAoijuadu8GZuqwPrSqs9VTBHtZsWLwakmgxzodHhwYfV5wlXcM8nYkZZK92jtADdWeJY2kFKJaK0tnSgbu/tpKoagD3H6mTcDaRyosl6VCS9P1zJDV16bhy7AwOGnfNwET1cZwt7bJI4hvD7u6WAWSIHE/OplqcVpC4jT0BD/KpyhWFPEudeVcwa9M+Ca49Q==; 5:DdCaQgt4dPCDC+RQCE5qM4ZDZFfUOqC+OniKwCMOgPqxHOdAHJWZS4tIy4ryVbCZT/pX7Pcgbbsu/Uq3WFUzCLOho8RG7939RiUDEsjYTrKQo1vnr6oaxPe65IIqPH7UvFHozUQ8tSCN6H2/K62UZw==; 24:q+dDVfahR8SM+1YkPk1+DE1M6R2NYhlGtRQZrObi6mx/pRWKl2NkHGBoPn/ofWTtRKSBpnKb/MbjgDKLu0h76VHlvNl9vHvR6eFpsInB8AE=; 7:R4caVwP69qkmGXMUP4+nzW0ISgPKGGl51IPX17zYNVvnZXSdpu4+E9kSjc4+axAsT1Cvxb+/3jQUtD8bCBj2xyqSXeFYxuulLo5SCdg+X5j34cgrKxKQHmX2Ymnzk38Pvgeu2iGtfJBxWvxa3kbxxQqteBYn2SHr0bjo/KOjBg/CSSxsq1OaY2/nVEq/Z2zsY8JN/cD/Cx+7lxxvWddIrQHnsZztTaEu06LFtSSM5npFa/31/+H5JWNtCCj1vjyf x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0845; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0845; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0845; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(51444003)(199003)(189002)(24454002)(52314003)(93886004)(66066001)(86612001)(5002640100001)(86362001)(3280700002)(122556002)(790700001)(9686002)(7906003)(7696003)(6116002)(76576001)(7736002)(4326007)(3660700001)(87936001)(3846002)(7846002)(2906002)(102836003)(99286002)(586003)(50986999)(5005710100001)(19625215002)(101416001)(54356999)(1511001)(19617315012)(16236675004)(33656002)(76176999)(10290500002)(106356001)(10400500002)(19580395003)(92566002)(8936002)(81156014)(2421001)(10090500001)(68736007)(105586002)(74316002)(189998001)(15975445007)(19300405004)(5001770100001)(8990500004)(77096005)(8676002)(81166006)(97736004)(19580405001)(2900100001)(5660300001)(11100500001)(2950100001)(2561002)(19609705001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0845; H:DM2PR0301MB0637.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR0301MB06379FA5A93670F4B215D39BF5E30DM2PR0301MB0637_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 23:10:35.3911 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0845 Archived-At: Cc: Tokbind WG , Leif Johansson , Bill Cox Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) 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, 31 Aug 2016 23:10:43 -0000 --_000_DM2PR0301MB06379FA5A93670F4B215D39BF5E30DM2PR0301MB0637_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBrbm93IEnigJltIGdldHRpbmcgaW50byB0aGlzIGRpc2N1c3Npb24gbGF0ZSwgYnV0IEkgZG9u 4oCZdCB1bmRlcnN0YW5kIHdoYXQgdGhlIFNIQS0yNTYgaGFzaCBvdmVyIHRoZSBjb25jYXRlbmF0 aW9uIGlzIGZvci4gIEl0IHNlZW1zIGxpa2UgYW4gdW5uZWNlc3Nhcnkgc3RlcCB0byBtZSwgZ2l2 ZW4gdGhhdCBhbGwgdGhlIHNpZ25hdHVyZSBhbGdvcml0aG1zIGJlaW5nIGRpc2N1c3NlZCBjYW4g YWxsIHNpZ24gYXJiaXRyYXJ5IGxlbmd0aCBieXRlIHNlcXVlbmNlcy4NCg0KVGhvc2UgYWxnb3Jp dGhtcywgSSBiZWxpZXZlIGFyZSAodXNpbmcgUkZDIDc1MTggYWxnb3JpdGhtIGRlc2NyaXB0aW9u cyk6DQoNCsK3ICAgICAgIFJTQVNTQS1QS0NTMS12MV81IHVzaW5nIFNIQS0yNTYNCg0KwrcgICAg ICAgUlNBU1NBLVBTUyB1c2luZyBTSEEtMjU2IGFuZCBNR0YxIHdpdGggU0hBLTI1Ng0KDQrCtyAg ICAgICBFQ0RTQSB1c2luZyBQLTI1NiBhbmQgU0hBLTI1Ng0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBVbmJl YXJhYmxlIFttYWlsdG86dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg QW5kcmVpIFBvcG92DQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAzMSwgMjAxNiA0OjAyIFBNDQpU bzogTmljayBIYXJwZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbT47IEJyaWFuIENhbXBiZWxsIDxiY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbT4NCkNjOiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYu b3JnPjsgTGVpZiBKb2hhbnNzb24gPGxlaWZqQHN1bmV0LnNlPjsgQmlsbCBDb3ggPHdheXdhcmRn ZWVrQGdvb2dsZS5jb20+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFdoYXQgR2V0cyBTaWdu ZWQgKHdhczogRHVtYiBpZGVhOiBhZGQgRWQyNTUxOSBzdXBwb3J0PykNCg0KSG93IGFib3V0IHdl IHNheSBzb21ldGhpbmcgbGlrZSB0aGlzOg0K4oCcV2hlbiBhbiByc2EyMDQ4X3BrY3MxLjUsIHJz YTIwNDhfcHNzIG9yIGVjZHNhcDI1NiBrZXkgaXMgdXNlZCwgdGhlIHNpZ25hdHVyZSBpcyBjb21w dXRlZCBvdmVyIHRoZSBTSEEyNTYgaGFzaCBvZiB0aGUgYnl0ZSBzdHJpbmcgcmVwcmVzZW50aW5n IHRoZSBjb25jYXRlbmF0aW9uIG9m4oCm4oCdPw0KDQpBIG5ldyBUQiBrZXkgcGFyYW1ldGVycyBJ RCBzcGVjaWZpY2F0aW9uIGNvdWxkIGRlc2NyaWJlIGEgZGlmZmVyZW50IGNvbnN0cnVjdC4NCg0K RnJvbTogTmljayBIYXJwZXIgW21haWx0bzpuaGFycGVyQGdvb2dsZS5jb21dDQpTZW50OiBXZWRu ZXNkYXksIEF1Z3VzdCAzMSwgMjAxNiAzOjU1IFBNDQpUbzogQnJpYW4gQ2FtcGJlbGwgPGJjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+ DQpDYzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5k cmVpLlBvcG92QG1pY3Jvc29mdC5jb20+PjsgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9y ZzxtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZz4+OyBMZWlmIEpvaGFuc3NvbiA8bGVpZmpAc3Vu ZXQuc2U8bWFpbHRvOmxlaWZqQHN1bmV0LnNlPj47IEJpbGwgQ294IDx3YXl3YXJkZ2Vla0Bnb29n bGUuY29tPG1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPj4NClN1YmplY3Q6IFJlOiBbVW5i ZWFyYWJsZV0gV2hhdCBHZXRzIFNpZ25lZCAod2FzOiBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1 cHBvcnQ/KQ0KDQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgUC0yNTYgY2FuIG9ubHkgc2lnbiBh IDMyLWJ5dGUgbWVzc2FnZSAoaGVuY2Ugd2h5IGl0IG1ha2VzIHNlbnNlIHRvIGhhc2ggdGhlIG1l c3NhZ2Ugd2l0aCBzaGEtMjU2IGZpcnN0KS4NCg0KSSBhZ3JlZSB3aXRoIEJyaWFuIHRoYXQgdGhl IGhhc2ggZnVuY3Rpb24gKGlmIGFueSkgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGtleSBwYXJhbSwg c2ltaWxhciB0byB0aGUgU2lnbmF0dXJlU2NoZW1lIGNvbWJpbmF0aW9uIGluIFRMUyAxLjMuDQoN Ck9uIFdlZCwgQXVnIDMxLCAyMDE2IGF0IDM6NDggUE0sIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJl bGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3 cm90ZToNCk15IHN1Z2dlc3Rpb24gaXMgdG8gdXNlIHRob3NlIDM0IGJ5dGVzIGRpcmVjdGx5IGFz IHRoZSBpbnB1dCBpbnRvIHRoZSBzaWduYXR1cmUgZ2VuZXJhdGlvbi92ZXJpZmljYXRpb24uIEFu ZCBmb3IgZWNkc2FwMjU2IGtleSBwYXJhbXMsIHRvIHVzZSBFQ0RTQSB1c2luZyBQLTI1NiBhbmQg U0hBLTI1NiBhcyB0aGUgc2lnbmF0dXJlIGFsZ29yaXRobS4gQWx0aG91Z2ggdGhlIGxhdHRlciBp cyBub3Qgc3RyaWN0bHkgbmVjZXNzYXJ5IEFGQUlDVCBiZWNhdXNlICdyYXcnIEVDRFNBIHVzaW5n IFAtMjU2IGNhbiBzaWduIDM0IGJ5dGVzIG9rYXkuDQoNCkFkbWl0dGVkbHksIEkgY291bGQgYmUg b2ZmIGJhc2UgaGVyZSBidXQgdGhhdCdzIG1vcmUgd2hhdCBJIHdvdWxkIGhhdmUgZXhwZWN0ZWQg dG8gc2VlLiBXZSBzZWVtIHRvIGJlIHRhbGtpbmcgcGFzdCBvbmUgYW5vdGhlciwgaG93ZXZlciwg aW4ganVzdCB0cnlpbmcgdG8gZGlzY3VzcyBpdC4NCg0KDQoNCk9uIFdlZCwgQXVnIDMxLCAyMDE2 IGF0IDM6NDcgUE0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFp bHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpHcmVhdC4NCg0KVGhlbiB3 ZSBoYXZlIDM0IGJ5dGVzIHdlIGhhc2ggd2l0aCBTSEEyNTYgYW5kIHNpZ24uDQoNCldoZW4gd2Ug c2lnbiB3aXRoIFJTQS1QU1Mgb3IgUlNBLVBLQ1MsIHdlIGFsc28gc3BlY2lmeSB0aGUgdXNlIG9m IFNIQTI1NiBpbiB0aGUgcGFkZGluZyBhbGdvcml0aG0uIEZvciBFQ0RTQSwgdGhlcmUgaXMgbm8g bmVlZCB0byBwYWQsIGFuZCB0aGVyZWZvcmUgbm8gbmVlZCAob3Igb3Bwb3J0dW5pdHkpIHRvIHVz ZSBwYWRkaW5nIGhhc2guDQoNCkJyaWFuLCB3aGF0IHNwZWNpZmljYWxseSB3b3VsZCB5b3UgbGlr ZSB0byBjaGFuZ2UgV1JUIGhhc2hpbmc/DQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWlsdG86 YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHku Y29tPl0NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDMxLCAyMDE2IDI6NDIgUE0NClRvOiBCaWxs IENveCA8d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTxtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNv bT4+DQpDYzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86 QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+PjsgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRm Lm9yZzxtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZz4+OyBMZWlmIEpvaGFuc3NvbiA8bGVpZmpA c3VuZXQuc2U8bWFpbHRvOmxlaWZqQHN1bmV0LnNlPj4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJs ZV0gV2hhdCBHZXRzIFNpZ25lZCAod2FzOiBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBvcnQ/ KQ0KDQpXb3JrcyBmb3IgbWUgdG9vIChJIHRoaW5rKS4NCg0KT24gV2VkLCBBdWcgMzEsIDIwMTYg YXQgMzozNCBQTSwgQmlsbCBDb3ggPHdheXdhcmRnZWVrQGdvb2dsZS5jb208bWFpbHRvOndheXdh cmRnZWVrQGdvb2dsZS5jb20+PiB3cm90ZToNCldvcmtzIGZvciBtZS4NCg0KT24gV2VkLCBBdWcg MzEsIDIwMTYgYXQgMjoyMCBQTSwgQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0 LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNClRvIHN1bSB1 cCwgYXJlIHdlIGluIGFncmVlbWVudCB0aGF0IHRoZSBjb25jYXRlbmF0aW9uIHdpbGwgb25seSBp bmNsdWRlOg0KDQoNCi0gICAgICAgICAgVG9rZW5CaW5kaW5nVHlwZSB2YWx1ZSBjb250YWluZWQg aW4gdGhlDQogICAgICBUb2tlbkJpbmRpbmcudG9rZW5iaW5kaW5nX3R5cGUgZmllbGQ7DQoNCi0g ICAgICAgICAgVG9rZW5CaW5kaW5nS2V5UGFyYW1ldGVycyB2YWx1ZSBjb250YWluZWQgaW4gdGhl DQogICAgICBUb2tlbkJpbmRpbmdJRC5rZXlfcGFyYW1ldGVycyBmaWVsZDsNCg0KLSAgICAgICAg ICBFeHBvcnRlZCBrZXlpbmcgbWF0ZXJpYWwgKEVLTSkgdmFsdWUgb2J0YWluZWQgZnJvbSB0aGUg Y3VycmVudCBUTFMNCiAgICAgIGNvbm5lY3Rpb24uDQrigKYgYmVjYXVzZSB0aGUgbGFiZWwgYW5k IHRoZSBQcm90b2NvbFZlcnNpb24gYXJlIHByZXN1bWFibHkgYWxyZWFkeSBpbiB0aGUgRUtNPw0K DQpGcm9tOiBCaWxsIENveCBbbWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb208bWFpbHRvOndh eXdhcmRnZWVrQGdvb2dsZS5jb20+XQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYg MjowMSBQTQ0KVG86IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxt YWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+Pg0KQ2M6IEFuZHJlaSBQb3BvdiA8QW5k cmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29t Pj47IFRva2JpbmQgV0cgPHVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOnVuYmVhcmFibGVAaWV0 Zi5vcmc+PjsgTGVpZiBKb2hhbnNzb24gPGxlaWZqQHN1bmV0LnNlPG1haWx0bzpsZWlmakBzdW5l dC5zZT4+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIER1bWIgaWRlYTogYWRkIEVkMjU1MTkg c3VwcG9ydD8NCg0KT24gV2VkLCBBdWcgMzEsIDIwMTYgYXQgMToxMCBQTSwgQnJpYW4gQ2FtcGJl bGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbT4+IHdyb3RlOg0KDQpPbiBXZWQsIEF1ZyAzMSwgMjAxNiBhdCAxOjM1IFBNLCBCaWxs IENveCA8d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTxtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNv bT4+IHdyb3RlOg0KT24gV2VkLCBBdWcgMzEsIDIwMTYgYXQgMTI6MTIgUE0sIEJyaWFuIENhbXBi ZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb20+PiB3cm90ZToNCkluIHdoaWNoIGNhc2UgSSdkIGFnYWluIHN1Z2dlc3QgdGhhdCB0 aGUgc2lnbmF0dXJlIGlucHV0IGJlIHRoZSBjb25jYXRlbmF0ZWQgaXRlbXMgZGlyZWN0bHkgKG5v IGhhc2gpIGFuZCB0aGF0IGhhc2hpbmcgb3Igbm90IGJlIHBhcnQgb2YgdGhlIHNpZ25hdHVyZSBz Y2hlbWUgYXNzb2NpYXRlZCB3aXRoIGVhY2gga2V5IHBhcmFtZXRlcnMgdHlwZS4NCg0KU291bmRz IGdvb2QgdG8gbWUuICBJdCBmaXRzIHRoZSBzdGFuZGFyZCBBUElzIGEgYml0IGJldHRlci4gIElJ VUMsIHRoaXMgcmVzdWx0IGlzIHRoZSBzYW1lIGVpdGhlciB3YXksIHNvIHRoaXMgaXMgcmVhbGx5 IGp1c3QgYSBtYXR0ZXIgb2YgaG93IHdlIGRlc2NyaWJlIGl0LCByaWdodD8NCg0KDQpBZnRlciBw bGF5aW5nIGFyb3VuZCB3aXRoIHNvbWUgQVBJcyB5ZXN0ZXJkYXksIEkgZG9uJ3QgdGhpbmsgdGhh dCB0aGUgcmVzdWx0IGlzIGFjdHVhbGx5IHRoZSBzYW1lLiBBdCBsZWFzdCBhcyBmYXIgYXMgdGhl IGFjdHVhbCBieXRlcyBvZiB0aGUgc2lnbmF0dXJlLiBDb25jZXB0dWFsbHkgdGhlIGlkZWEgaXMg dGhlIHNhbWUgdGhvdWdoLCBBRkFJSywgYW5kIG1vdmluZyB0aGUgaGFzaCBkZWZpbml0aW9uIHRv IHRoZSBzaWduYXR1cmUgc2NoZW1lIGFzc29jaWF0ZWQgd2l0aCBlYWNoIGtleSBwYXJhbWV0ZXJz IHR5cGUgcmVtb3ZlcyBhIGhhcmR3aXJlZCBkZXBlbmRlbmN5IG9uIFNIQTI1NiBhbmQgYWxzbyBl bGltaW5hdGVzIGEgcm91bmQgb2YgaGFzaGluZyBmb3IgdGhlIFJTQSBrZXkgcGFyYW1ldGVycyB0 eXBlcy4NCg0KVGhlIE9wZW5TU0wgc2lnbmluZyBBUElzIGFyZSBmaW5pY2t5LiAgVGhleSByZWFs bHkgd2FudCB0byBkbyBhIGRpZ2VzdCwgYW5kIHlvdSBoYXZlIHRvIGtub3cgaG93IHRvIGNhbGwg dGhlbSBqdXN0IHJpZ2h0IHRvIHNpZ24gdGhlIGRpZ2VzdCwgcmF0aGVyIHRoYW4gdGhlIGhhc2gg b2YgdGhlIGRpZ2VzdC4gIEhvd2V2ZXIsIGF0IG9uZSBwb2ludCwgSSB3YXMgYWJsZSB0byB2ZXJp ZnkgdGhhdCBib3RoIHdheXMgZ2l2ZSB0aGUgc2FtZSByZXN1bHQuICBJIGFjdHVhbGx5IHVzZSB0 aGUgbm9ybWFsIEFQSXMgbm93IHRoYXQgZG8gdGhlIFNIQTI1NiB3aGlsZSBzaWduaW5nLiAgSSBk byBub3QgdGhpbmsgdGhpcyByZXF1aXJlcyBhIGRvY3VtZW50IGNoYW5nZSwgb3RoZXIgdGhhbiBw ZXJoYXBzIHNvbWUgY2xhcmlmaWNhdGlvbi4NCg0KQWNjb3JkaW5nIHRvIHRoZSBFS00gc3BlYyAo aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3MDUpLCBhIGRpc2FtYmlndWF0aW5nIGxh YmVsIGlzIHJlcXVpcmVkLCBhbmQgd2UncmUgYWxzbyBzdXBwb3NlZCB0byByZWdpc3RlciBpdCBz byB0aGVyZSBhcmUgbm8gbmFtZSBjb2xsaXNpb25zLiAgSXMgdGhpcyBzb21ldGhpbmcgd2UgbmVl ZCB0byB3b3JyeSBhYm91dD8NCg0KSSB0aGluayB0aGF0J3MgYWxyZWFkeSAob3Igd2lsbCBiZSkg Y292ZXJlZCB3aXRoIHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdCBmb3IgIkVYUE9SVEVSLVRva2Vu LUJpbmRpbmciIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2Jp bmQtcHJvdG9jb2wtMDkjc2VjdGlvbi02LjQNCg0KT0ssIGdyZWF0LiAgSW4gdGhhdCBjYXNlLCBh ZGRpbmcgIlRva2VuIEJpbmRpbmciIGlzIHJlZHVuZGFudCwgYnV0IHNpbmNlIHdlIHVzZSBhIDMy LWJ5dGUgYmxvY2sgaGFzaCBhbnl3YXksIEkgZG9uJ3QgdGhpbmsgaXQgd2lsbCBtYWtlIGFueSBk aWZmZXJlbmNlIGlucyBzcGVlZCwgb3RoZXIgdGhhbiB0aGUgY29zdCBvZiBjb3B5aW5nIHRoZSBk YXRhLg0KDQpGb3Igc29tZSByZWFzb24sIEkgdGhvdWdodCB3ZSBoYWQgYWxyZWFkeSByZWdpc3Rl cmVkICJUb2tlbiBCaW5kaW5nIiBhcyBhIHVuaXF1ZSBFS00gbGFiZWwuICBJZiBzbywgd2Ugc2hv dWxkIHByb2JhYmx5IHBhc3MgdGhlIGxhYmVsIHRvIHRoZSBFS00gZWl0aGVyIGluIGFkZGl0aW9u IHRvLCBvciBpbnN0ZWFkIG9mLCBoYXNoaW5nIGl0IGluIHRoZSBmaW5hbCBoYXNoLg0KDQpJIG1h eSBoYXZlIGNvbmZ1c2VkIHRoaW5ncyBieSB1c2luZyB0aGUgdGVybSBsYWJlbCBmb3IgdGhlIEFT Q0lJIHN0cmluZyAiVG9rZW4gQmluZGluZyIgdGhhdCdzIHBhcnQgb2YgdGhlIGNvbmNhdGVuYXRp b24gb2YgdGhpbmdzLiBJdCdzIG5vdCBhIGxhYmVsIGluIHRoZSBSRkMgNTcwNSBzZW5zZSBidXQg bW9yZSBvZiBhIGRpc2FtYmlndWF0ZXIgdGhhdCBpcyB0YWNrZWQgb250byB0aGUgY29udGVudCB0 aGF0IGlzIHNpbmdlZC4gQW5kcmVpIGNhbiBwZXJoYXBzIGV4cGxhaW4gaXQncyBwdXJwb3NlIGJl dHRlci4NCkJ1dCBqdXN0IHRoaW5raW5nIGFib3V0IHRoYXQgbWFrZXMgbWUgd29uZGVyIGlmIGl0 J3MgbmVjZXNzYXJ5LiAiIkVYUE9SVEVSLVRva2VuLUJpbmRpbmciIGlzIGhhc2hlZCBpbnRvIHRo ZSBFS00gd2hpY2ggaXMgdGhlbiB1bmRlciB0aGUgc2lnbmF0dXJlLiBJcyBhbm90aGVyICJUb2tl biBCaW5kaW5nIiBzdHJpbmcgdW5kZXIgdGhlIHNpZ25hdHVyZSBuZWVkZWQgdG8gcHJldmVudCBj cm9zcyBwcm90b2NvbCBhdHRhY2tzPyBEb2Vzbid0IHRoZSBFS00gaW5wdXQgbGFiZWwgYWxyZWFk eSBkbyB0aGF0Pw0KDQpZZXMsIGl0IGRvZXMsIGJ1dCBzbyBsb25nIGFzIGl0IGRvZXMgbm90IGNh dXNlIHRoZSBkYXRhIHRvIHRha2UgdXAgYW5vdGhlciAzMi1ieXRlIGJsb2NrLCBJJ20gT0sgd2l0 aCBpdC4NCg0KU28sIEknbSBPSyB3aXRoIHRoZSAtMDkgdmVyc2lvbi4NCg0KQmlsbA0KDQoNCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpVbmJl YXJhYmxlIG1haWxpbmcgbGlzdA0KVW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5iZWFyYWJs ZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFy YWJsZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KVW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5i ZWFyYWJsZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dW5iZWFyYWJsZQ0KDQo= --_000_DM2PR0301MB06379FA5A93670F4B215D39BF5E30DM2PR0301MB0637_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5n czsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRp di5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1z aXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHls ZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMwMDIwNjA7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlz dCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTAyODE0MzA1NTsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTU4MzgwMjI0NiA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPkkga25vdyBJ4oCZbSBnZXR0 aW5nIGludG8gdGhpcyBkaXNjdXNzaW9uIGxhdGUsIGJ1dCBJIGRvbuKAmXQgdW5kZXJzdGFuZCB3 aGF0IHRoZSBTSEEtMjU2IGhhc2ggb3ZlciB0aGUgY29uY2F0ZW5hdGlvbiBpcyBmb3IuJm5ic3A7 IEl0IHNlZW1zIGxpa2UgYW4gdW5uZWNlc3Nhcnkgc3RlcCB0bw0KIG1lLCBnaXZlbiB0aGF0IGFs bCB0aGUgc2lnbmF0dXJlIGFsZ29yaXRobXMgYmVpbmcgZGlzY3Vzc2VkIGNhbiBhbGwgc2lnbiBh cmJpdHJhcnkgbGVuZ3RoIGJ5dGUgc2VxdWVuY2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzAwMjA2MCI+VGhvc2UgYWxnb3JpdGhtcywgSSBiZWxpZXZlIGFyZSAodXNpbmcg UkZDIDc1MTggYWxnb3JpdGhtIGRlc2NyaXB0aW9ucyk6PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjojMDAyMDYwIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMw MDIwNjAiPlJTQVNTQS1QS0NTMS12MV81IHVzaW5nIFNIQS0yNTY8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMwMDIwNjAiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwMjA2MCI+UlNBU1NBLVBTUyB1c2luZyBTSEEtMjU2IGFuZCBNR0YxIHdpdGggU0hBLTI1 NjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTeW1i b2w7Y29sb3I6IzAwMjA2MCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5FQ0RTQSB1c2luZyBQLTI1NiBhbmQgU0hB LTI1Ng0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFt ZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8 bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMDAyMDYwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBVbmJlYXJhYmxlIFttYWlsdG86 dW5iZWFyYWJsZS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmRyZWkg UG9wb3Y8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYgNDowMiBQ TTxicj4NCjxiPlRvOjwvYj4gTmljayBIYXJwZXIgJmx0O25oYXJwZXJAZ29vZ2xlLmNvbSZndDs7 IEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSZndDs8YnI+DQo8 Yj5DYzo8L2I+IFRva2JpbmQgV0cgJmx0O3VuYmVhcmFibGVAaWV0Zi5vcmcmZ3Q7OyBMZWlmIEpv aGFuc3NvbiAmbHQ7bGVpZmpAc3VuZXQuc2UmZ3Q7OyBCaWxsIENveCAmbHQ7d2F5d2FyZGdlZWtA Z29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBXaGF0 IEdldHMgU2lnbmVkICh3YXM6IER1bWIgaWRlYTogYWRkIEVkMjU1MTkgc3VwcG9ydD8pPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Ib3cgYWJvdXQgd2Ugc2F5IHNvbWV0aGluZyBsaWtlIHRoaXM6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7igJxXaGVuIGFuIHJz YTIwNDhfcGtjczEuNSwgcnNhMjA0OF9wc3Mgb3IgZWNkc2FwMjU2IGtleSBpcyB1c2VkLCB0aGUg c2lnbmF0dXJlIGlzIGNvbXB1dGVkIG92ZXIgdGhlIFNIQTI1NiBoYXNoIG9mIHRoZSBieXRlIHN0 cmluZyByZXByZXNlbnRpbmcgdGhlIGNvbmNhdGVuYXRpb24gb2bigKbigJ0/PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkEgbmV3IFRCIGtleSBwYXJhbWV0ZXJzIElEIHNwZWNpZmljYXRpb24gY291bGQgZGVzY3Jp YmUgYSBkaWZmZXJlbnQgY29uc3RydWN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gTmljayBIYXJwZXIgWzxhIGhyZWY9Im1haWx0bzpuaGFycGVy QGdvb2dsZS5jb20iPm1haWx0bzpuaGFycGVyQGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFdlZG5lc2RheSwgQXVndXN0IDMxLCAyMDE2IDM6NTUgUE08YnI+DQo8Yj5Ubzo8L2I+ IEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0 eS5jb20iPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+ IEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQu Y29tIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyBUb2tiaW5kIFdHICZsdDs8 YSBocmVmPSJtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZyI+dW5iZWFyYWJsZUBpZXRmLm9yZzwv YT4mZ3Q7OyBMZWlmIEpvaGFuc3NvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlaWZqQHN1bmV0LnNl Ij5sZWlmakBzdW5ldC5zZTwvYT4mZ3Q7OyBCaWxsIENveCAmbHQ7PGEgaHJlZj0ibWFpbHRvOndh eXdhcmRnZWVrQGdvb2dsZS5jb20iPndheXdhcmRnZWVrQGdvb2dsZS5jb208L2E+Jmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW1VuYmVhcmFibGVdIFdoYXQgR2V0cyBTaWduZWQgKHdhczog RHVtYiBpZGVhOiBhZGQgRWQyNTUxOSBzdXBwb3J0Pyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5NeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgUC0yNTYgY2FuIG9ubHkgc2ln biBhIDMyLWJ5dGUgbWVzc2FnZSAoaGVuY2Ugd2h5IGl0IG1ha2VzIHNlbnNlIHRvIGhhc2ggdGhl IG1lc3NhZ2Ugd2l0aCBzaGEtMjU2IGZpcnN0KS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgd2l0aCBCcmlhbiB0aGF0IHRoZSBoYXNoIGZ1bmN0 aW9uIChpZiBhbnkpIHNob3VsZCBiZSBwYXJ0IG9mIHRoZSBrZXkgcGFyYW0sIHNpbWlsYXIgdG8g dGhlIFNpZ25hdHVyZVNjaGVtZSBjb21iaW5hdGlvbiBpbiBUTFMgMS4zLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVnIDMxLCAyMDE2IGF0 IDM6NDggUE0sIEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBp bmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk15IHN1Z2dlc3Rpb24gaXMgdG8gdXNlIHRob3NlIDM0IGJ5dGVzIGRpcmVjdGx5IGFzIHRo ZSBpbnB1dCBpbnRvIHRoZSBzaWduYXR1cmUgZ2VuZXJhdGlvbi92ZXJpZmljYXRpb24uIEFuZCBm b3IgZWNkc2FwMjU2IGtleSBwYXJhbXMsIHRvIHVzZSBFQ0RTQSB1c2luZyBQLTI1NiBhbmQgU0hB LTI1NiBhcyB0aGUgc2lnbmF0dXJlIGFsZ29yaXRobS4gQWx0aG91Z2ggdGhlIGxhdHRlciBpcyBu b3Qgc3RyaWN0bHkNCiBuZWNlc3NhcnkgQUZBSUNUIGJlY2F1c2UgJ3JhdycgRUNEU0EgdXNpbmcg UC0yNTYgY2FuIHNpZ24gMzQgYnl0ZXMgb2theS48YnI+DQo8YnI+DQpBZG1pdHRlZGx5LCBJIGNv dWxkIGJlIG9mZiBiYXNlIGhlcmUgYnV0IHRoYXQncyBtb3JlIHdoYXQgSSB3b3VsZCBoYXZlIGV4 cGVjdGVkIHRvIHNlZS4gV2Ugc2VlbSB0byBiZSB0YWxraW5nIHBhc3Qgb25lIGFub3RoZXIsIGhv d2V2ZXIsIGluIGp1c3QgdHJ5aW5nIHRvIGRpc2N1c3MgaXQuJm5ic3A7DQo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXVnIDMxLCAyMDE2IGF0IDM6NDcg UE0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3Nv ZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+R3JlYXQuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5UaGVuIHdlIGhhdmUgMzQgYnl0ZXMgd2UgaGFzaCB3aXRoIFNIQTI1NiBh bmQgc2lnbi4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+V2hlbiB3ZSBzaWduIHdpdGggUlNBLVBTUyBv ciBSU0EtUEtDUywgd2UgYWxzbyBzcGVjaWZ5IHRoZSB1c2Ugb2YgU0hBMjU2IGluIHRoZSBwYWRk aW5nIGFsZ29yaXRobS4gRm9yIEVDRFNBLCB0aGVyZQ0KIGlzIG5vIG5lZWQgdG8gcGFkLCBhbmQg dGhlcmVmb3JlIG5vIG5lZWQgKG9yIG9wcG9ydHVuaXR5KSB0byB1c2UgcGFkZGluZyBoYXNoLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+QnJpYW4sIHdoYXQgc3BlY2lmaWNhbGx5IHdvdWxkIHlvdSBsaWtl IHRvIGNoYW5nZSBXUlQgaGFzaGluZz88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBCcmlhbiBDYW1wYmVsbCBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1 Z3VzdCAzMSwgMjAxNiAyOjQyIFBNPGJyPg0KPGI+VG86PC9iPiBCaWxsIENveCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj53YXl3YXJk Z2Vla0Bnb29nbGUuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IEFuZHJlaSBQb3BvdiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFu ayI+QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0OzsgVG9rYmluZCBXRyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnVuYmVhcmFibGVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51bmJlYXJh YmxlQGlldGYub3JnPC9hPiZndDs7IExlaWYgSm9oYW5zc29uICZsdDs8YSBocmVmPSJtYWlsdG86 bGVpZmpAc3VuZXQuc2UiIHRhcmdldD0iX2JsYW5rIj5sZWlmakBzdW5ldC5zZTwvYT4mZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gV2hhdCBHZXRzIFNpZ25lZCAod2Fz OiBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBvcnQ/KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldvcmtzIGZvciBtZSB0b28gKEkgdGhp bmspLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ T24gV2VkLCBBdWcgMzEsIDIwMTYgYXQgMzozNCBQTSwgQmlsbCBDb3ggJmx0OzxhIGhyZWY9Im1h aWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2F5d2FyZGdlZWtA Z29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5Xb3JrcyBmb3IgbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQsIEF1ZyAzMSwgMjAxNiBhdCAyOjIw IFBNLCBBbmRyZWkgUG9wb3YgJmx0OzxhIGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9z b2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPlRvIHN1bSB1cCwgYXJlIHdlIGluIGFncmVlbWVudCB0aGF0IHRoZSBj b25jYXRlbmF0aW9uIHdpbGwgb25seSBpbmNsdWRlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Ub2tlbkJpbmRpbmdUeXBlIHZhbHVl IGNvbnRhaW5lZCBpbiB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRv a2VuQmluZGluZy50b2tlbmJpbmRpbmdfdHlwZSBmaWVsZDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBw dCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Ub2tlbkJpbmRpbmdLZXlQYXJhbWV0ZXJzIHZhbHVl IGNvbnRhaW5lZCBpbiB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRv a2VuQmluZGluZ0lELmtleV9wYXJhbWV0ZXJzIGZpZWxkOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkV4cG9ydGVkIGtleWluZyBtYXRlcmlhbCAoRUtNKSB2 YWx1ZSBvYnRhaW5lZCBmcm9tIHRoZSBjdXJyZW50IFRMUzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgY29ubmVjdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+4oCmIGJlY2F1c2UgdGhlIGxhYmVsIGFu ZCB0aGUgUHJvdG9jb2xWZXJzaW9uIGFyZSBwcmVzdW1hYmx5IGFscmVhZHkgaW4gdGhlIEVLTT88 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBC aWxsIENveCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tIiB0 YXJnZXQ9Il9ibGFuayI+d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50 OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYgMjowMSBQTTxicj4NCjxiPlRvOjwvYj4g QnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDs8 YnI+DQo8Yj5DYzo8L2I+IEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Q b3BvdkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92QG1pY3Jvc29m dC5jb208L2E+Jmd0OzsgVG9rYmluZCBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnVuYmVhcmFibGVA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51bmJlYXJhYmxlQGlldGYub3JnPC9hPiZndDs7IExl aWYgSm9oYW5zc29uICZsdDs8YSBocmVmPSJtYWlsdG86bGVpZmpAc3VuZXQuc2UiIHRhcmdldD0i X2JsYW5rIj5sZWlmakBzdW5ldC5zZTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb VW5iZWFyYWJsZV0gRHVtYiBpZGVhOiBhZGQgRWQyNTUxOSBzdXBwb3J0Pzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgQXVnIDMx LCAyMDE2IGF0IDE6MTAgUE0sIEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNh bXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lk ZW50aXR5LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5PbiBXZWQsIEF1ZyAzMSwgMjAxNiBhdCAxOjM1IFBNLCBCaWxsIENveCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj53 YXl3YXJkZ2Vla0Bnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBBdWcgMzEsIDIwMTYgYXQg MTI6MTIgUE0sIEJyaWFuIENhbXBiZWxsICZsdDs8YSBocmVmPSJtYWlsdG86YmNhbXBiZWxsQHBp bmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5iY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J biB3aGljaCBjYXNlIEknZCBhZ2FpbiBzdWdnZXN0IHRoYXQgdGhlIHNpZ25hdHVyZSBpbnB1dCBi ZSB0aGUgY29uY2F0ZW5hdGVkIGl0ZW1zIGRpcmVjdGx5IChubyBoYXNoKSBhbmQgdGhhdCBoYXNo aW5nIG9yIG5vdCBiZSBwYXJ0IG9mIHRoZSBzaWduYXR1cmUgc2NoZW1lIGFzc29jaWF0ZWQgd2l0 aCBlYWNoDQoga2V5IHBhcmFtZXRlcnMgdHlwZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvdW5k cyBnb29kIHRvIG1lLiZuYnNwOyBJdCBmaXRzIHRoZSBzdGFuZGFyZCBBUElzIGEgYml0IGJldHRl ci4mbmJzcDsgSUlVQywgdGhpcyByZXN1bHQgaXMgdGhlIHNhbWUgZWl0aGVyIHdheSwgc28gdGhp cyBpcyByZWFsbHkganVzdCBhIG1hdHRlciBvZiBob3cgd2UgZGVzY3JpYmUgaXQsIHJpZ2h0Pzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQombmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj Mzg3NjFEIj5BZnRlciBwbGF5aW5nIGFyb3VuZCB3aXRoIHNvbWUgQVBJcyB5ZXN0ZXJkYXksIEkg ZG9uJ3QgdGhpbmsgdGhhdCB0aGUgcmVzdWx0IGlzIGFjdHVhbGx5IHRoZSBzYW1lLiBBdCBsZWFz dCBhcyBmYXIgYXMgdGhlIGFjdHVhbCBieXRlcyBvZiB0aGUgc2lnbmF0dXJlLg0KIENvbmNlcHR1 YWxseSB0aGUgaWRlYSBpcyB0aGUgc2FtZSB0aG91Z2gsIEFGQUlLLCBhbmQgbW92aW5nIHRoZSBo YXNoIGRlZmluaXRpb24gdG8gdGhlIHNpZ25hdHVyZSBzY2hlbWUgYXNzb2NpYXRlZCB3aXRoIGVh Y2gga2V5IHBhcmFtZXRlcnMgdHlwZSByZW1vdmVzIGEgaGFyZHdpcmVkIGRlcGVuZGVuY3kgb24g U0hBMjU2IGFuZCBhbHNvIGVsaW1pbmF0ZXMgYSByb3VuZCBvZiBoYXNoaW5nIGZvciB0aGUgUlNB IGtleSBwYXJhbWV0ZXJzIHR5cGVzLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIE9wZW5TU0wgc2lnbmluZyBBUElzIGFyZSBm aW5pY2t5LiZuYnNwOyBUaGV5IHJlYWxseSB3YW50IHRvIGRvIGEgZGlnZXN0LCBhbmQgeW91IGhh dmUgdG8ga25vdyBob3cgdG8gY2FsbCB0aGVtIGp1c3QgcmlnaHQgdG8gc2lnbiB0aGUgZGlnZXN0 LCByYXRoZXIgdGhhbiB0aGUgaGFzaCBvZiB0aGUgZGlnZXN0LiZuYnNwOw0KIEhvd2V2ZXIsIGF0 IG9uZSBwb2ludCwgSSB3YXMgYWJsZSB0byB2ZXJpZnkgdGhhdCBib3RoIHdheXMgZ2l2ZSB0aGUg c2FtZSByZXN1bHQuJm5ic3A7IEkgYWN0dWFsbHkgdXNlIHRoZSBub3JtYWwgQVBJcyBub3cgdGhh dCBkbyB0aGUgU0hBMjU2IHdoaWxlIHNpZ25pbmcuJm5ic3A7IEkgZG8gbm90IHRoaW5rIHRoaXMg cmVxdWlyZXMgYSBkb2N1bWVudCBjaGFuZ2UsIG90aGVyIHRoYW4gcGVyaGFwcyBzb21lIGNsYXJp ZmljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWNjb3JkaW5nIHRvIHRoZSBF S00gc3BlYyAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3MDUiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTcwNTwvYT4pLCBh IGRpc2FtYmlndWF0aW5nIGxhYmVsIGlzIHJlcXVpcmVkLCBhbmQgd2UncmUNCiBhbHNvIHN1cHBv c2VkIHRvIHJlZ2lzdGVyIGl0IHNvIHRoZXJlIGFyZSBubyBuYW1lIGNvbGxpc2lvbnMuJm5ic3A7 IElzIHRoaXMgc29tZXRoaW5nIHdlIG5lZWQgdG8gd29ycnkgYWJvdXQ/Jm5ic3A7DQo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMzg3 NjFEIj5JIHRoaW5rIHRoYXQncyBhbHJlYWR5IChvciB3aWxsIGJlKSBjb3ZlcmVkIHdpdGggdGhl IHJlZ2lzdHJhdGlvbiByZXF1ZXN0IGZvciAmcXVvdDtFWFBPUlRFUi1Ub2tlbi1CaW5kaW5nJnF1 b3Q7IGluDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10 b2tiaW5kLXByb3RvY29sLTA5I3NlY3Rpb24tNi40IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10b2tiaW5kLXByb3RvY29sLTA5I3NlY3Rp b24tNi40PC9hPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9LLCBncmVhdC4mbmJzcDsgSW4gdGhhdCBjYXNlLCBhZGRpbmcgJnF1b3Q7VG9rZW4g QmluZGluZyZxdW90OyBpcyByZWR1bmRhbnQsIGJ1dCBzaW5jZSB3ZSB1c2UgYSAzMi1ieXRlIGJs b2NrIGhhc2ggYW55d2F5LCBJIGRvbid0IHRoaW5rIGl0IHdpbGwgbWFrZSBhbnkgZGlmZmVyZW5j ZSBpbnMgc3BlZWQsIG90aGVyIHRoYW4gdGhlDQogY29zdCBvZiBjb3B5aW5nIHRoZSBkYXRhLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZvciBzb21lIHJlYXNvbiwgSSB0aG91 Z2h0IHdlIGhhZCBhbHJlYWR5IHJlZ2lzdGVyZWQgJnF1b3Q7VG9rZW4gQmluZGluZyZxdW90OyBh cyBhIHVuaXF1ZSBFS00gbGFiZWwuJm5ic3A7IElmIHNvLCB3ZSBzaG91bGQgcHJvYmFibHkgcGFz cyB0aGUgbGFiZWwgdG8gdGhlIEVLTSBlaXRoZXIgaW4gYWRkaXRpb24gdG8sIG9yIGluc3RlYWQN CiBvZiwgaGFzaGluZyBpdCBpbiB0aGUgZmluYWwgaGFzaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMzODc2MUQiPkkgbWF5IGhhdmUgY29u ZnVzZWQgdGhpbmdzIGJ5IHVzaW5nIHRoZSB0ZXJtIGxhYmVsIGZvciB0aGUgQVNDSUkgc3RyaW5n ICZxdW90O1Rva2VuIEJpbmRpbmcmcXVvdDsgdGhhdCdzIHBhcnQgb2YgdGhlIGNvbmNhdGVuYXRp b24gb2YgdGhpbmdzLiBJdCdzIG5vdCBhIGxhYmVsIGluIHRoZSBSRkMgNTcwNSBzZW5zZSBidXQg bW9yZSBvZiBhIGRpc2FtYmlndWF0ZXIgdGhhdCBpcyB0YWNrZWQgb250byB0aGUgY29udGVudA0K IHRoYXQgaXMgc2luZ2VkLiBBbmRyZWkgY2FuIHBlcmhhcHMgZXhwbGFpbiBpdCdzIHB1cnBvc2Ug YmV0dGVyLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMzg3NjFEIj5CdXQganVzdCB0aGlua2lu ZyBhYm91dCB0aGF0IG1ha2VzIG1lIHdvbmRlciBpZiBpdCdzIG5lY2Vzc2FyeS4gJnF1b3Q7JnF1 b3Q7RVhQT1JURVItVG9rZW4tQmluZGluZyZxdW90OyBpcyBoYXNoZWQgaW50byB0aGUgRUtNIHdo aWNoIGlzIHRoZW4gdW5kZXIgdGhlIHNpZ25hdHVyZS4gSXMNCiBhbm90aGVyICZxdW90O1Rva2Vu IEJpbmRpbmcmcXVvdDsgc3RyaW5nIHVuZGVyIHRoZSBzaWduYXR1cmUgbmVlZGVkIHRvIHByZXZl bnQgY3Jvc3MgcHJvdG9jb2wgYXR0YWNrcz8gRG9lc24ndCB0aGUgRUtNIGlucHV0IGxhYmVsIGFs cmVhZHkgZG8gdGhhdD8NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPlllcywgaXQgZG9lcywgYnV0IHNvIGxvbmcgYXMgaXQgZG9lcyBub3QgY2F1c2UgdGhl IGRhdGEgdG8gdGFrZSB1cCBhbm90aGVyIDMyLWJ5dGUgYmxvY2ssIEknbSBPSyB3aXRoIGl0Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ U28sIEknbSBPSyB3aXRoIHRoZSAtMDkgdmVyc2lvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJpbGwmbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NClVuYmVhcmFibGUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlVuYmVh cmFibGVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5VbmJlYXJhYmxlQGlldGYub3JnPC9hPjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFy YWJsZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vdW5iZWFyYWJsZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClVu YmVhcmFibGUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVAaWV0 Zi5vcmciPlVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby91bmJlYXJhYmxlPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_DM2PR0301MB06379FA5A93670F4B215D39BF5E30DM2PR0301MB0637_-- From nobody Wed Aug 31 16: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 F3B4A12D52D for ; Wed, 31 Aug 2016 16:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 TZpOsnoiX-dq for ; Wed, 31 Aug 2016 16:26:07 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 BE00212B02A for ; Wed, 31 Aug 2016 16:26:06 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id l94so116403272ual.0 for ; Wed, 31 Aug 2016 16:26:06 -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=DCARQDWIegRSuBuKMRG6hzgRAg8jb2fbSXvJY4uwQuc=; b=ki+7rGMpGxeOlCLN0fsJ7/n4JvhUQohVJ3wJLlwQX0/fyM4a8wyGwZ0BRTba4vn2vF Ln5gX69l/ragiqRqMEFWr0y64bWP+oFTE70TTkDEpy1OpNjQ0Om/nk35moMy0agTgWG1 +2ykXWJMVkaZmFRx2XwGvHJMb/fStOCxjEe6cFjJI+/Pyn/5KJBMG1CdevP4fxtCB1bs CXMkHSMA4F7sZB5Og/z4+gVgCXoc3ODpKx7dfCb5sgpQy22qkQPaYJaw3TE3/otu8R45 dr7wKI3v3qG7aemofNG96apIFE9Df3WOKbpGD9jJ4UCyeBYoxrR/7hkaBGhANU+/uwga Ho+g== 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=DCARQDWIegRSuBuKMRG6hzgRAg8jb2fbSXvJY4uwQuc=; b=mISQo3/S7TDSDVLanw7QYjUBnF6u2mUgMSCVExdFYICunH/HqxaU3wqa25N+3lYT0a pvyqJ79D0uzKh0eEBuXBChRhtQFUFoMnfBvhzDWAko6Jvpuf7i9x6uJAoC3xQqibX4yN jaJhE6y5AI3pFQtohkLBY/L/Irl7FA7ekwZox8xdsL39f0Axld2Y6owwdLvn9N0EipT7 d1k0YiFzZMTGWQyAhyrsEevfvZmxPGy026GzxacySCrp94cFdTJnjdkDarhxteF4XD3u b49rWGypL9cxSlsAVyNMWG6w2ym7p30HsfoorkrJjThlG3MRbx+M0BkEbhvQ1HWTf4kj 6svg== X-Gm-Message-State: AE9vXwNvf/zPOH1DIxnW/jcWL0Oc3DHWLBF8//nbP63Zx+TRKbuHqiUYkgnrySA7pyBGHXQZbBIBD1VYh+6dS3NY X-Received: by 10.159.53.1 with SMTP id o1mr7201234uao.15.1472685965425; Wed, 31 Aug 2016 16:26:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.209 with HTTP; Wed, 31 Aug 2016 16:25:44 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Wed, 31 Aug 2016 16:25:44 -0700 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=94eb2c04cac6d5fe15053b666be6 Archived-At: Cc: Bill Cox , Andrei Popov , Brian Campbell , Tokbind WG , Leif Johansson Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) 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, 31 Aug 2016 23:26:09 -0000 --94eb2c04cac6d5fe15053b666be6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think it depends on how you define the algorithms. If you do it as Mike lists, then an algorithm takes an arbitrary-length byte sequence (the same holds true if they're defined like the SignatureSchemes in TLS 1.3). Right now, I believe Token Binding defines signature algorithms as not containing a hash algorithm, since before we started concatenating things to the EKM value, the message to be signed was short enough that it didn't need any hashing. I think we should go back to the signature algorithm including a hash algorithm (if relevant - an EdDSA algorithm doesn't need a hash function). On Wed, Aug 31, 2016 at 4:10 PM, Mike Jones wrote: > I know I=E2=80=99m getting into this discussion late, but I don=E2=80=99t= understand what > the SHA-256 hash over the concatenation is for. It seems like an > unnecessary step to me, given that all the signature algorithms being > discussed can all sign arbitrary length byte sequences. > > > > Those algorithms, I believe are (using RFC 7518 algorithm descriptions): > > =C2=B7 RSASSA-PKCS1-v1_5 using SHA-256 > > =C2=B7 RSASSA-PSS using SHA-256 and MGF1 with SHA-256 > > =C2=B7 ECDSA using P-256 and SHA-256 > > > > -- Mike > > > > *From:* Unbearable [mailto:unbearable-bounces@ietf.org] *On Behalf Of *An= drei > Popov > *Sent:* Wednesday, August 31, 2016 4:02 PM > *To:* Nick Harper ; Brian Campbell < > bcampbell@pingidentity.com> > *Cc:* Tokbind WG ; Leif Johansson ; > Bill Cox > > *Subject:* Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 > support?) > > > > How about we say something like this: > > =E2=80=9CWhen an rsa2048_pkcs1.5, rsa2048_pss or ecdsap256 key is used, t= he > signature is computed over the SHA256 hash of the byte string representin= g > the concatenation of=E2=80=A6=E2=80=9D? > > > > A new TB key parameters ID specification could describe a different > construct. > > > > *From:* Nick Harper [mailto:nharper@google.com ] > *Sent:* Wednesday, August 31, 2016 3:55 PM > *To:* Brian Campbell > *Cc:* Andrei Popov ; Tokbind WG < > unbearable@ietf.org>; Leif Johansson ; Bill Cox < > waywardgeek@google.com> > *Subject:* Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 > support?) > > > > My understanding is that P-256 can only sign a 32-byte message (hence why > it makes sense to hash the message with sha-256 first). > > > > I agree with Brian that the hash function (if any) should be part of the > key param, similar to the SignatureScheme combination in TLS 1.3. > > > > On Wed, Aug 31, 2016 at 3:48 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > > My suggestion is to use those 34 bytes directly as the input into the > signature generation/verification. And for ecdsap256 key params, to use > ECDSA using P-256 and SHA-256 as the signature algorithm. Although the > latter is not strictly necessary AFAICT because 'raw' ECDSA using P-256 c= an > sign 34 bytes okay. > > Admittedly, I could be off base here but that's more what I would have > expected to see. We seem to be talking past one another, however, in just > trying to discuss it. > > > > > > > On Wed, Aug 31, 2016 at 3:47 PM, Andrei Popov > wrote: > > Great. > > > > Then we have 34 bytes we hash with SHA256 and sign. > > > > When we sign with RSA-PSS or RSA-PKCS, we also specify the use of SHA256 > in the padding algorithm. For ECDSA, there is no need to pad, and therefo= re > no need (or opportunity) to use padding hash. > > > > Brian, what specifically would you like to change WRT hashing? > > > > *From:* Brian Campbell [mailto:bcampbell@pingidentity.com] > *Sent:* Wednesday, August 31, 2016 2:42 PM > *To:* Bill Cox > *Cc:* Andrei Popov ; Tokbind WG < > unbearable@ietf.org>; Leif Johansson > *Subject:* Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 > support?) > > > > Works for me too (I think). > > > > On Wed, Aug 31, 2016 at 3:34 PM, Bill Cox wrote: > > Works for me. > > > > On Wed, Aug 31, 2016 at 2:20 PM, Andrei Popov > wrote: > > To sum up, are we in agreement that the concatenation will only include: > > > > - TokenBindingType value contained in the > > TokenBinding.tokenbinding_type field; > > - TokenBindingKeyParameters value contained in the > > TokenBindingID.key_parameters field; > > - Exported keying material (EKM) value obtained from the current > TLS > > connection. > > =E2=80=A6 because the label and the ProtocolVersion are presumably alread= y in the > EKM? > > > > *From:* Bill Cox [mailto:waywardgeek@google.com] > *Sent:* Wednesday, August 31, 2016 2:01 PM > *To:* Brian Campbell > *Cc:* Andrei Popov ; Tokbind WG < > unbearable@ietf.org>; Leif Johansson > *Subject:* Re: [Unbearable] Dumb idea: add Ed25519 support? > > > > On Wed, Aug 31, 2016 at 1:10 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > > > > On Wed, Aug 31, 2016 at 1:35 PM, Bill Cox wrote: > > On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell < > bcampbell@pingidentity.com> wrote: > > In which case I'd again suggest that the signature input be the > concatenated items directly (no hash) and that hashing or not be part of > the signature scheme associated with each key parameters type. > > > > Sounds good to me. It fits the standard APIs a bit better. IIUC, this > result is the same either way, so this is really just a matter of how we > describe it, right? > > > > > After playing around with some APIs yesterday, I don't think that the > result is actually the same. At least as far as the actual bytes of the > signature. Conceptually the idea is the same though, AFAIK, and moving th= e > hash definition to the signature scheme associated with each key paramete= rs > type removes a hardwired dependency on SHA256 and also eliminates a round > of hashing for the RSA key parameters types. > > > > The OpenSSL signing APIs are finicky. They really want to do a digest, > and you have to know how to call them just right to sign the digest, rath= er > than the hash of the digest. However, at one point, I was able to verify > that both ways give the same result. I actually use the normal APIs now > that do the SHA256 while signing. I do not think this requires a documen= t > change, other than perhaps some clarification. > > > > According to the EKM spec (https://tools.ietf.org/html/rfc5705), a > disambiguating label is required, and we're also supposed to register it = so > there are no name collisions. Is this something we need to worry about? > > > > I think that's already (or will be) covered with the registration request > for "EXPORTER-Token-Binding" in https://tools.ietf.org/html/ > draft-ietf-tokbind-protocol-09#section-6.4 > > > > OK, great. In that case, adding "Token Binding" is redundant, but since > we use a 32-byte block hash anyway, I don't think it will make any > difference ins speed, other than the cost of copying the data. > > > > For some reason, I thought we had already registered "Token Binding" as a > unique EKM label. If so, we should probably pass the label to the EKM > either in addition to, or instead of, hashing it in the final hash. > > > I may have confused things by using the term label for the ASCII string > "Token Binding" that's part of the concatenation of things. It's not a > label in the RFC 5705 sense but more of a disambiguater that is tacked on= to > the content that is singed. Andrei can perhaps explain it's purpose bette= r. > > But just thinking about that makes me wonder if it's necessary. > ""EXPORTER-Token-Binding" is hashed into the EKM which is then under the > signature. Is another "Token Binding" string under the signature needed t= o > prevent cross protocol attacks? Doesn't the EKM input label already do > that? > > > > Yes, it does, but so long as it does not cause the data to take up anothe= r > 32-byte block, I'm OK with it. > > > > So, I'm OK with the -09 version. > > > > Bill > > > > > > > > > > > > _______________________________________________ > 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 > > > --94eb2c04cac6d5fe15053b666be6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think it depends on how you define the algorithms. If yo= u do it as Mike lists, then an algorithm takes an arbitrary-length byte seq= uence (the same holds true if they're defined like the SignatureSchemes= in TLS 1.3). Right now, I believe Token Binding defines signature algorith= ms as not containing a hash algorithm, since before we started concatenatin= g things to the EKM value, the message to be signed was short enough that i= t didn't need any hashing. I think we should go back to the signature a= lgorithm including a hash algorithm (if relevant - an EdDSA algorithm doesn= 't need a hash function).

On Wed, Aug 31, 2016 at 4:10 PM, Mike Jones <M= ichael.Jones@microsoft.com> wrote:

I know I=E2=80=99m getting into this = discussion late, but I don=E2=80=99t understand what the SHA-256 hash over = the concatenation is for.=C2=A0 It seems like an unnecessary step to me, given that all the signature algorithms being discussed can all sign a= rbitrary length byte sequences.

=C2=A0

Those algorithms, I believe are (usin= g RFC 7518 algorithm descriptions):

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 RSASSA-PKCS1-v1_5 using SHA-256<= u>

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 RSASSA-PSS using SHA-256 and MGF= 1 with SHA-256

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 ECDSA using P-256 and SHA-256

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -- Mike

=C2=A0

From: Unbearable [mailto:unbearable-bounces@ietf.org] On Behalf Of Andrei Popov
Sent: Wednesday, August 31, 2016 4:02 PM
To: Nick Harper <nharper@google.com>; Brian Campbell <bcampbell@pingidentity.com&= gt;
Cc: Tokbind WG <unbearable@ietf.org>; Leif Johansson <leifj@sunet.se>; Bill Cox <waywardgeek@google.c= om>


Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25= 519 support?)

=C2=A0

How about we say something like this:=

=E2=80=9CWhen an rsa2048_pkcs1.5, rsa2048_pss or ec= dsap256 key is used, the signature is computed over the SHA256 hash of the = byte string representing the concatenation of=E2=80=A6=E2=80=9D?<= /u>

=C2=A0

A new TB key parameters ID specification could desc= ribe a different construct.

=C2=A0

From: Nick Harper [mailto:nharper@google.com]
Sent: Wednesday, August 31, 2016 3:55 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Tokbind WG <unbearable@ietf.org&g= t;; Leif Johansson <= leifj@sunet.se>; Bill Cox <waywardgeek@google.com>
Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25= 519 support?)

=C2=A0

My understanding is that P-256 can only sign a 32-by= te message (hence why it makes sense to hash the message with sha-256 first= ).

=C2=A0

I agree with Brian that the hash function (if any) s= hould be part of the key param, similar to the SignatureScheme combination = in TLS 1.3.

=C2=A0

On Wed, Aug 31, 2016 at 3:48 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

My suggestion is to use those 34 bytes directly as t= he input into the signature generation/verification. And for ecdsap256 key = params, to use ECDSA using P-256 and SHA-256 as the signature algorithm. Al= though the latter is not strictly necessary AFAICT because 'raw' ECDSA using P-256 can sign 34 bytes= okay.

Admittedly, I could be off base here but that's more what I would have = expected to see. We seem to be talking past one another, however, in just t= rying to discuss it.=C2=A0


=C2=A0

=C2=A0

On Wed, Aug 31, 2016 at 3:47 PM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

Great.

=C2=A0

Then we have 34 bytes we hash with SHA256 and sign.

=C2=A0

When we sign with RSA-PSS or RSA-PKCS, we also spec= ify the use of SHA256 in the padding algorithm. For ECDSA, there is no need to pad, and therefore no need (or opportunity) to use padding h= ash.

=C2=A0

Brian, what specifically would you like to change W= RT hashing?

=C2=A0

From: Brian Campbell [mailto:bcampbell@pin= gidentity.com]
Sent: Wednesday, August 31, 2016 2:42 PM
To: Bill Cox <waywardgeek@google.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Tokbind WG <unbearable@ietf.org&g= t;; Leif Johansson <= leifj@sunet.se>
Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25= 519 support?)

=C2=A0

Works for me too (I think).

=C2=A0

On Wed, Aug 31, 2016 at 3:34 PM, Bill Cox <waywardgeek@google.co= m> wrote:

Works for me.

=C2=A0

On Wed, Aug 31, 2016 at 2:20 PM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

To sum up, are we in agreement that the concatenati= on will only include:

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 TokenBindingType value contained in the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TokenBinding.tokenbi= nding_type field;

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 TokenBindingKeyParameters value contained in the

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TokenBindingID.key_p= arameters field;

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Exported keying material (EKM) value obtained from the current TLS<= /span>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 connection.

=E2=80=A6 because the label and the ProtocolVersion= are presumably already in the EKM?

=C2=A0

From: Bill Cox [mailto:waywardgeek@google.com]
Sent: Wednesday, August 31, 2016 2:01 PM
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Andrei Popov <Andrei.Popov@microsoft.com>; Tokbind WG <unbearable@ietf.org&g= t;; Leif Johansson <= leifj@sunet.se>
Subject: Re: [Unbearable] Dumb idea: add Ed25519 support?<= /u>

=C2=A0

On Wed, Aug 31, 2016 at 1:10 PM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

=C2=A0

On Wed, Aug 31, 2016 at 1:35 PM, Bill Cox <waywardgeek@google.co= m> wrote:

On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell <= ;bcampbell@= pingidentity.com> wrote:

In which case I'd again suggest that the signatu= re input be the concatenated items directly (no hash) and that hashing or n= ot be part of the signature scheme associated with each key parameters type.=C2=A0

=C2=A0

Sounds good to me.=C2=A0 It fits the standard APIs a= bit better.=C2=A0 IIUC, this result is the same either way, so this is rea= lly just a matter of how we describe it, right?


=C2=A0

After playing around w= ith some APIs yesterday, I don't think that the result is actually the = same. At least as far as the actual bytes of the signature. Conceptually the idea is the same though, AFAIK, and moving the hash defin= ition to the signature scheme associated with each key parameters type remo= ves a hardwired dependency on SHA256 and also eliminates a round of hashing= for the RSA key parameters types.=C2=A0

=C2=A0

The OpenSSL signing APIs are finicky.=C2=A0 They rea= lly want to do a digest, and you have to know how to call them just right t= o sign the digest, rather than the hash of the digest.=C2=A0 However, at one point, I was able to verify that both ways give the same r= esult.=C2=A0 I actually use the normal APIs now that do the SHA256 while si= gning.=C2=A0 I do not think this requires a document change, other than per= haps some clarification.

=C2=A0

According to the EKM spec (https://tools.ietf.org/html/r= fc5705), a disambiguating label is required, and we're also supposed to register it so there are no name collisions.=C2=A0 Is thi= s something we need to worry about?=C2=A0

=C2=A0

I think that's alr= eady (or will be) covered with the registration request for "EXPORTER-= Token-Binding" in https://tools.ietf.org/html/draft-ietf-tokbind-protocol-09#sectio= n-6.4=C2=A0

=C2=A0

OK, great.=C2=A0 In that case, adding "Token Bi= nding" is redundant, but since we use a 32-byte block hash anyway, I d= on't think it will make any difference ins speed, other than the cost of copying the data.=C2=A0

=C2=A0

For some reason, I thought we had already registered= "Token Binding" as a unique EKM label.=C2=A0 If so, we should pr= obably pass the label to the EKM either in addition to, or instead of, hashing it in the final hash.


I may have confused things by using the term = label for the ASCII string "Token Binding" that's part of the= concatenation of things. It's not a label in the RFC 5705 sense but mo= re of a disambiguater that is tacked onto the content that is singed. Andrei can perhaps explain it's purpose better.

But just thinking abou= t that makes me wonder if it's necessary. ""EXPORTER-Token-Bi= nding" is hashed into the EKM which is then under the signature. Is another "Token Binding" string under the signature needed to pre= vent cross protocol attacks? Doesn't the EKM input label already do tha= t?

=C2=A0

Yes, it does, but so long as it does not cause the d= ata to take up another 32-byte block, I'm OK with it.

=C2=A0

So, I'm OK with the -09 version.

=C2=A0

Bill=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

_____________________= __________________________
Unbearable mailing list
Unbearable@ietf.or= g
https://www.ietf.org/mailman/listinfo/unbearable=

=C2=A0


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

=C2=A0


--94eb2c04cac6d5fe15053b666be6-- From nobody Wed Aug 31 16:37: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 2156512D513 for ; Wed, 31 Aug 2016 16:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 aGYf6JT7_LO1 for ; Wed, 31 Aug 2016 16:37:40 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0115.outbound.protection.outlook.com [104.47.40.115]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3013712D1A4 for ; Wed, 31 Aug 2016 16:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uTVBtznchdPpNW2e0C1D/nhkI7YvIE39SENZbuJo9fM=; b=HiQ4zzgM0yQ0Q1kBvmAInPPTsZE/UVA8zdaDttbmnlGEDI1PCCTxFlAD62JXs1bHBMMuomBDgct/33JbtjqMx8joiZS/BWXg6qY4i6cfRcRxR46elv3NuJUcsvVqajsvyHqY75YrD5mDe8MBvQTZt9sJ1b2LiByREHv7zbLholw= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0633.namprd03.prod.outlook.com (10.160.158.139) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.9; Wed, 31 Aug 2016 23:37:37 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Wed, 31 Aug 2016 23:37:37 +0000 From: Andrei Popov To: Nick Harper , Mike Jones Thread-Topic: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) Thread-Index: AdIDzYe/nNN4QigzR4G2nIa8+fQ4XAAAex2AAABDp4AAAAco4AACRqKAAAA6aYAAABgK8AAAOeBQAADE4wAAAEwGIA== Date: Wed, 31 Aug 2016 23:37: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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: c245ef35-4831-415a-3716-08d3d1f7cabe x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0633; 6:bs6AD87eLkpOjYBCQwishJAwyiBYhX7VYRGNwGpTvRVNSBWHXiCXQty9FnqhJ/k9t7lDi1S/5o110jOLCgVM/gZsHrotlSQ7QOrf7S4NqWAlhlHj0L+dY13WxfYXPeajoiS8oNgQyjPund9r9oEwtpnq0A6hGU92AHpFXOKwSACf7iMedkVCtDP0otV7YdEnKgoGXLZpjOEHjmSdT9HQ1jz8D6NExq/zlmLs+OxL+Gcge9SVW60qGqe0yVVijyhYgnPk7TRDjaLl49ITcwvZmaWpMzwloN3nynxdC+9/JepyfI407vQy5gSZOBreLhzlppko5LN8M8qaeCxAcAPcJQ==; 5:6sqswDYeS2Sn8z5banqSTh8rQVugoip3jDvvuwIdZoh4O623VK46+eoF8FquyiB1tiQSaKotXHbESj1oS6RFYBm8yxbA8E+k7bvhsjVaLBFqcePpQQEP+dAYT4cnfADbuZzebZAeRqjMtE1SkEq9J9533L5Rx5iE+3JZgk+qTE0=; 24:G8urLb8+0asA1SM7uqR+6Gchpo7Vkr+IZJumLpBHFSMan0HrtSONvjDLsKNKR17J5PHwOe2rvaH74l6J1vW65Q4rVuUmIMlD606sWsxZ7wY=; 7:YbkqCfTCiKPevdshJJEcajBn7m3xNYT2dNkr3pviDaB33Ht7e932EM7nbOE6O6Q7V29hjTlYJNtDLQW8ANzQcocB2BbevFO2ChrGSiK2S9cbbTRSvyHsyND3D/AfsmqkvhTTf20J5ClBZ6mMR7Q8QbMtGAlHjktN/WdT+C4RU/OXuShDKkBotJJscVIeR2FQsqqDE+itzXtRyVTi3+MDHRGwmB7B4c01NBDtvXSMXQywmoKrQMzbmAzEjl3NndTt x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0633; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0633; BCL:0; PCL:0; RULEID:(304825118); SRVR:CY1PR0301MB0633; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(51444003)(377454003)(199003)(52314003)(189002)(24454002)(19300405004)(2906002)(77096005)(3660700001)(87936001)(15975445007)(2561002)(86362001)(3280700002)(2900100001)(2950100001)(5660300001)(76176999)(33656002)(68736007)(76576001)(19625215002)(50986999)(54356999)(101416001)(93886004)(19617315012)(2421001)(1511001)(4326007)(19580395003)(19580405001)(16236675004)(92566002)(11100500001)(5001770100001)(97736004)(8676002)(106356001)(105586002)(99286002)(8990500004)(10090500001)(7736002)(4001450100002)(9686002)(8936002)(7846002)(7696003)(81166006)(7906003)(10400500002)(74316002)(122556002)(10290500002)(5005710100001)(189998001)(5002640100001)(86612001)(586003)(81156014)(6116002)(790700001)(102836003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0633; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB0842D1E6A87CB18387FEE34B8CE30CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 23:37:36.8525 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0633 Archived-At: Cc: Tokbind WG , Brian Campbell , Leif Johansson , Bill Cox Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) 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, 31 Aug 2016 23:37:44 -0000 --_000_CY1PR0301MB0842D1E6A87CB18387FEE34B8CE30CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEkgdGhpbmsgaXQgZGVwZW5kcyBvbiBob3cgeW91IGRlZmluZSB0aGUgYWxnb3JpdGhtcy4N CkNvcnJlY3QsIGlmIG9uZSBpbmNsdWRlcyB0aGUgaGFzaCBvcGVyYXRpb24gaW4gdGhlIGRlZmlu aXRpb24gb2YgYSBzaWduaW5nIG9wZXJhdGlvbiwgdGhlbiBvbmUgY2FuIHNpZ24gYXJiaXRyYXJ5 LWxlbmd0aCBieXRlIHN0cmluZ3PimLouDQoNCg0Kw5ggIEkgdGhpbmsgd2Ugc2hvdWxkIGdvIGJh Y2sgdG8gdGhlIHNpZ25hdHVyZSBhbGdvcml0aG0gaW5jbHVkaW5nIGEgaGFzaCBhbGdvcml0aG0g KGlmIHJlbGV2YW50IC0gYW4gRWREU0EgYWxnb3JpdGhtIGRvZXNuJ3QgbmVlZCBhIGhhc2ggZnVu Y3Rpb24pLg0KSGVyZeKAmXMgbXkgYXR0ZW1wdCBhdCBkb2luZyB0aGlzOiDigJxXaGVuIGFuIHJz YTIwNDhfcGtjczEuNSwgcnNhMjA0OF9wc3Mgb3IgZWNkc2FwMjU2IGtleSBpcyB1c2VkLCB0aGUg c2lnbmF0dXJlIGlzIGNvbXB1dGVkIG92ZXIgdGhlIFNIQTI1NiBoYXNoIG9mIHRoZSBieXRlIHN0 cmluZyByZXByZXNlbnRpbmcgdGhlIGNvbmNhdGVuYXRpb24gb2bigKbigJ0uDQpGcm9tOiBOaWNr IEhhcnBlciBbbWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgQXVn dXN0IDMxLCAyMDE2IDQ6MjYgUE0NClRvOiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20+DQpDYzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT47 IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT47IFRva2JpbmQgV0cg PHVuYmVhcmFibGVAaWV0Zi5vcmc+OyBMZWlmIEpvaGFuc3NvbiA8bGVpZmpAc3VuZXQuc2U+OyBC aWxsIENveCA8d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbT4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJs ZV0gV2hhdCBHZXRzIFNpZ25lZCAod2FzOiBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBvcnQ/ KQ0KDQpJIHRoaW5rIGl0IGRlcGVuZHMgb24gaG93IHlvdSBkZWZpbmUgdGhlIGFsZ29yaXRobXMu IElmIHlvdSBkbyBpdCBhcyBNaWtlIGxpc3RzLCB0aGVuIGFuIGFsZ29yaXRobSB0YWtlcyBhbiBh cmJpdHJhcnktbGVuZ3RoIGJ5dGUgc2VxdWVuY2UgKHRoZSBzYW1lIGhvbGRzIHRydWUgaWYgdGhl eSdyZSBkZWZpbmVkIGxpa2UgdGhlIFNpZ25hdHVyZVNjaGVtZXMgaW4gVExTIDEuMykuIFJpZ2h0 IG5vdywgSSBiZWxpZXZlIFRva2VuIEJpbmRpbmcgZGVmaW5lcyBzaWduYXR1cmUgYWxnb3JpdGht cyBhcyBub3QgY29udGFpbmluZyBhIGhhc2ggYWxnb3JpdGhtLCBzaW5jZSBiZWZvcmUgd2Ugc3Rh cnRlZCBjb25jYXRlbmF0aW5nIHRoaW5ncyB0byB0aGUgRUtNIHZhbHVlLCB0aGUgbWVzc2FnZSB0 byBiZSBzaWduZWQgd2FzIHNob3J0IGVub3VnaCB0aGF0IGl0IGRpZG4ndCBuZWVkIGFueSBoYXNo aW5nLiBJIHRoaW5rIHdlIHNob3VsZCBnbyBiYWNrIHRvIHRoZSBzaWduYXR1cmUgYWxnb3JpdGht IGluY2x1ZGluZyBhIGhhc2ggYWxnb3JpdGhtIChpZiByZWxldmFudCAtIGFuIEVkRFNBIGFsZ29y aXRobSBkb2Vzbid0IG5lZWQgYSBoYXNoIGZ1bmN0aW9uKS4NCg0KT24gV2VkLCBBdWcgMzEsIDIw MTYgYXQgNDoxMCBQTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1h aWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkkga25vdyBJ4oCZbSBn ZXR0aW5nIGludG8gdGhpcyBkaXNjdXNzaW9uIGxhdGUsIGJ1dCBJIGRvbuKAmXQgdW5kZXJzdGFu ZCB3aGF0IHRoZSBTSEEtMjU2IGhhc2ggb3ZlciB0aGUgY29uY2F0ZW5hdGlvbiBpcyBmb3IuICBJ dCBzZWVtcyBsaWtlIGFuIHVubmVjZXNzYXJ5IHN0ZXAgdG8gbWUsIGdpdmVuIHRoYXQgYWxsIHRo ZSBzaWduYXR1cmUgYWxnb3JpdGhtcyBiZWluZyBkaXNjdXNzZWQgY2FuIGFsbCBzaWduIGFyYml0 cmFyeSBsZW5ndGggYnl0ZSBzZXF1ZW5jZXMuDQoNClRob3NlIGFsZ29yaXRobXMsIEkgYmVsaWV2 ZSBhcmUgKHVzaW5nIFJGQyA3NTE4IGFsZ29yaXRobSBkZXNjcmlwdGlvbnMpOg0KDQrigKIgICAg ICAgUlNBU1NBLVBLQ1MxLXYxXzUgdXNpbmcgU0hBLTI1Ng0KDQrigKIgICAgICAgUlNBU1NBLVBT UyB1c2luZyBTSEEtMjU2IGFuZCBNR0YxIHdpdGggU0hBLTI1Ng0KDQrigKIgICAgICAgRUNEU0Eg dXNpbmcgUC0yNTYgYW5kIFNIQS0yNTYNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0KRnJvbTogVW5iZWFyYWJsZSBbbWFp bHRvOnVuYmVhcmFibGUtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dW5iZWFyYWJsZS1ib3VuY2Vz QGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEFuZHJlaSBQb3Bvdg0KU2VudDogV2VkbmVzZGF5LCBB dWd1c3QgMzEsIDIwMTYgNDowMiBQTQ0KVG86IE5pY2sgSGFycGVyIDxuaGFycGVyQGdvb2dsZS5j b208bWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbT4+OyBCcmlhbiBDYW1wYmVsbCA8YmNhbXBiZWxs QHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPj4NCkNj OiBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGlldGYub3JnPG1haWx0bzp1bmJlYXJhYmxlQGlldGYu b3JnPj47IExlaWYgSm9oYW5zc29uIDxsZWlmakBzdW5ldC5zZTxtYWlsdG86bGVpZmpAc3VuZXQu c2U+PjsgQmlsbCBDb3ggPHdheXdhcmRnZWVrQGdvb2dsZS5jb208bWFpbHRvOndheXdhcmRnZWVr QGdvb2dsZS5jb20+Pg0KDQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFdoYXQgR2V0cyBTaWdu ZWQgKHdhczogRHVtYiBpZGVhOiBhZGQgRWQyNTUxOSBzdXBwb3J0PykNCg0KSG93IGFib3V0IHdl IHNheSBzb21ldGhpbmcgbGlrZSB0aGlzOg0K4oCcV2hlbiBhbiByc2EyMDQ4X3BrY3MxLjUsIHJz YTIwNDhfcHNzIG9yIGVjZHNhcDI1NiBrZXkgaXMgdXNlZCwgdGhlIHNpZ25hdHVyZSBpcyBjb21w dXRlZCBvdmVyIHRoZSBTSEEyNTYgaGFzaCBvZiB0aGUgYnl0ZSBzdHJpbmcgcmVwcmVzZW50aW5n IHRoZSBjb25jYXRlbmF0aW9uIG9m4oCm4oCdPw0KDQpBIG5ldyBUQiBrZXkgcGFyYW1ldGVycyBJ RCBzcGVjaWZpY2F0aW9uIGNvdWxkIGRlc2NyaWJlIGEgZGlmZmVyZW50IGNvbnN0cnVjdC4NCg0K RnJvbTogTmljayBIYXJwZXIgW21haWx0bzpuaGFycGVyQGdvb2dsZS5jb21dDQpTZW50OiBXZWRu ZXNkYXksIEF1Z3VzdCAzMSwgMjAxNiAzOjU1IFBNDQpUbzogQnJpYW4gQ2FtcGJlbGwgPGJjYW1w YmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbT4+ DQpDYzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5k cmVpLlBvcG92QG1pY3Jvc29mdC5jb20+PjsgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9y ZzxtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZz4+OyBMZWlmIEpvaGFuc3NvbiA8bGVpZmpAc3Vu ZXQuc2U8bWFpbHRvOmxlaWZqQHN1bmV0LnNlPj47IEJpbGwgQ294IDx3YXl3YXJkZ2Vla0Bnb29n bGUuY29tPG1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPj4NClN1YmplY3Q6IFJlOiBbVW5i ZWFyYWJsZV0gV2hhdCBHZXRzIFNpZ25lZCAod2FzOiBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1 cHBvcnQ/KQ0KDQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgUC0yNTYgY2FuIG9ubHkgc2lnbiBh IDMyLWJ5dGUgbWVzc2FnZSAoaGVuY2Ugd2h5IGl0IG1ha2VzIHNlbnNlIHRvIGhhc2ggdGhlIG1l c3NhZ2Ugd2l0aCBzaGEtMjU2IGZpcnN0KS4NCg0KSSBhZ3JlZSB3aXRoIEJyaWFuIHRoYXQgdGhl IGhhc2ggZnVuY3Rpb24gKGlmIGFueSkgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIGtleSBwYXJhbSwg c2ltaWxhciB0byB0aGUgU2lnbmF0dXJlU2NoZW1lIGNvbWJpbmF0aW9uIGluIFRMUyAxLjMuDQoN Ck9uIFdlZCwgQXVnIDMxLCAyMDE2IGF0IDM6NDggUE0sIEJyaWFuIENhbXBiZWxsIDxiY2FtcGJl bGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+PiB3 cm90ZToNCk15IHN1Z2dlc3Rpb24gaXMgdG8gdXNlIHRob3NlIDM0IGJ5dGVzIGRpcmVjdGx5IGFz IHRoZSBpbnB1dCBpbnRvIHRoZSBzaWduYXR1cmUgZ2VuZXJhdGlvbi92ZXJpZmljYXRpb24uIEFu ZCBmb3IgZWNkc2FwMjU2IGtleSBwYXJhbXMsIHRvIHVzZSBFQ0RTQSB1c2luZyBQLTI1NiBhbmQg U0hBLTI1NiBhcyB0aGUgc2lnbmF0dXJlIGFsZ29yaXRobS4gQWx0aG91Z2ggdGhlIGxhdHRlciBp cyBub3Qgc3RyaWN0bHkgbmVjZXNzYXJ5IEFGQUlDVCBiZWNhdXNlICdyYXcnIEVDRFNBIHVzaW5n IFAtMjU2IGNhbiBzaWduIDM0IGJ5dGVzIG9rYXkuDQoNCkFkbWl0dGVkbHksIEkgY291bGQgYmUg b2ZmIGJhc2UgaGVyZSBidXQgdGhhdCdzIG1vcmUgd2hhdCBJIHdvdWxkIGhhdmUgZXhwZWN0ZWQg dG8gc2VlLiBXZSBzZWVtIHRvIGJlIHRhbGtpbmcgcGFzdCBvbmUgYW5vdGhlciwgaG93ZXZlciwg aW4ganVzdCB0cnlpbmcgdG8gZGlzY3VzcyBpdC4NCg0KDQoNCk9uIFdlZCwgQXVnIDMxLCAyMDE2 IGF0IDM6NDcgUE0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFp bHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpHcmVhdC4NCg0KVGhlbiB3 ZSBoYXZlIDM0IGJ5dGVzIHdlIGhhc2ggd2l0aCBTSEEyNTYgYW5kIHNpZ24uDQoNCldoZW4gd2Ug c2lnbiB3aXRoIFJTQS1QU1Mgb3IgUlNBLVBLQ1MsIHdlIGFsc28gc3BlY2lmeSB0aGUgdXNlIG9m IFNIQTI1NiBpbiB0aGUgcGFkZGluZyBhbGdvcml0aG0uIEZvciBFQ0RTQSwgdGhlcmUgaXMgbm8g bmVlZCB0byBwYWQsIGFuZCB0aGVyZWZvcmUgbm8gbmVlZCAob3Igb3Bwb3J0dW5pdHkpIHRvIHVz ZSBwYWRkaW5nIGhhc2guDQoNCkJyaWFuLCB3aGF0IHNwZWNpZmljYWxseSB3b3VsZCB5b3UgbGlr ZSB0byBjaGFuZ2UgV1JUIGhhc2hpbmc/DQoNCkZyb206IEJyaWFuIENhbXBiZWxsIFttYWlsdG86 YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208bWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHku Y29tPl0NClNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDMxLCAyMDE2IDI6NDIgUE0NClRvOiBCaWxs IENveCA8d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTxtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNv bT4+DQpDYzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86 QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+PjsgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRm Lm9yZzxtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZz4+OyBMZWlmIEpvaGFuc3NvbiA8bGVpZmpA c3VuZXQuc2U8bWFpbHRvOmxlaWZqQHN1bmV0LnNlPj4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJs ZV0gV2hhdCBHZXRzIFNpZ25lZCAod2FzOiBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBvcnQ/ KQ0KDQpXb3JrcyBmb3IgbWUgdG9vIChJIHRoaW5rKS4NCg0KT24gV2VkLCBBdWcgMzEsIDIwMTYg YXQgMzozNCBQTSwgQmlsbCBDb3ggPHdheXdhcmRnZWVrQGdvb2dsZS5jb208bWFpbHRvOndheXdh cmRnZWVrQGdvb2dsZS5jb20+PiB3cm90ZToNCldvcmtzIGZvciBtZS4NCg0KT24gV2VkLCBBdWcg MzEsIDIwMTYgYXQgMjoyMCBQTSwgQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0 LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNClRvIHN1bSB1 cCwgYXJlIHdlIGluIGFncmVlbWVudCB0aGF0IHRoZSBjb25jYXRlbmF0aW9uIHdpbGwgb25seSBp bmNsdWRlOg0KDQoNCi0gICAgICAgICAgVG9rZW5CaW5kaW5nVHlwZSB2YWx1ZSBjb250YWluZWQg aW4gdGhlDQogICAgICBUb2tlbkJpbmRpbmcudG9rZW5iaW5kaW5nX3R5cGUgZmllbGQ7DQoNCi0g ICAgICAgICAgVG9rZW5CaW5kaW5nS2V5UGFyYW1ldGVycyB2YWx1ZSBjb250YWluZWQgaW4gdGhl DQogICAgICBUb2tlbkJpbmRpbmdJRC5rZXlfcGFyYW1ldGVycyBmaWVsZDsNCg0KLSAgICAgICAg ICBFeHBvcnRlZCBrZXlpbmcgbWF0ZXJpYWwgKEVLTSkgdmFsdWUgb2J0YWluZWQgZnJvbSB0aGUg Y3VycmVudCBUTFMNCiAgICAgIGNvbm5lY3Rpb24uDQrigKYgYmVjYXVzZSB0aGUgbGFiZWwgYW5k IHRoZSBQcm90b2NvbFZlcnNpb24gYXJlIHByZXN1bWFibHkgYWxyZWFkeSBpbiB0aGUgRUtNPw0K DQpGcm9tOiBCaWxsIENveCBbbWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb208bWFpbHRvOndh eXdhcmRnZWVrQGdvb2dsZS5jb20+XQ0KU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYg MjowMSBQTQ0KVG86IEJyaWFuIENhbXBiZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxt YWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+Pg0KQ2M6IEFuZHJlaSBQb3BvdiA8QW5k cmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29t Pj47IFRva2JpbmQgV0cgPHVuYmVhcmFibGVAaWV0Zi5vcmc8bWFpbHRvOnVuYmVhcmFibGVAaWV0 Zi5vcmc+PjsgTGVpZiBKb2hhbnNzb24gPGxlaWZqQHN1bmV0LnNlPG1haWx0bzpsZWlmakBzdW5l dC5zZT4+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIER1bWIgaWRlYTogYWRkIEVkMjU1MTkg c3VwcG9ydD8NCg0KT24gV2VkLCBBdWcgMzEsIDIwMTYgYXQgMToxMCBQTSwgQnJpYW4gQ2FtcGJl bGwgPGJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPG1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50 aXR5LmNvbT4+IHdyb3RlOg0KDQpPbiBXZWQsIEF1ZyAzMSwgMjAxNiBhdCAxOjM1IFBNLCBCaWxs IENveCA8d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTxtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNv bT4+IHdyb3RlOg0KT24gV2VkLCBBdWcgMzEsIDIwMTYgYXQgMTI6MTIgUE0sIEJyaWFuIENhbXBi ZWxsIDxiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVu dGl0eS5jb20+PiB3cm90ZToNCkluIHdoaWNoIGNhc2UgSSdkIGFnYWluIHN1Z2dlc3QgdGhhdCB0 aGUgc2lnbmF0dXJlIGlucHV0IGJlIHRoZSBjb25jYXRlbmF0ZWQgaXRlbXMgZGlyZWN0bHkgKG5v IGhhc2gpIGFuZCB0aGF0IGhhc2hpbmcgb3Igbm90IGJlIHBhcnQgb2YgdGhlIHNpZ25hdHVyZSBz Y2hlbWUgYXNzb2NpYXRlZCB3aXRoIGVhY2gga2V5IHBhcmFtZXRlcnMgdHlwZS4NCg0KU291bmRz IGdvb2QgdG8gbWUuICBJdCBmaXRzIHRoZSBzdGFuZGFyZCBBUElzIGEgYml0IGJldHRlci4gIElJ VUMsIHRoaXMgcmVzdWx0IGlzIHRoZSBzYW1lIGVpdGhlciB3YXksIHNvIHRoaXMgaXMgcmVhbGx5 IGp1c3QgYSBtYXR0ZXIgb2YgaG93IHdlIGRlc2NyaWJlIGl0LCByaWdodD8NCg0KDQpBZnRlciBw bGF5aW5nIGFyb3VuZCB3aXRoIHNvbWUgQVBJcyB5ZXN0ZXJkYXksIEkgZG9uJ3QgdGhpbmsgdGhh dCB0aGUgcmVzdWx0IGlzIGFjdHVhbGx5IHRoZSBzYW1lLiBBdCBsZWFzdCBhcyBmYXIgYXMgdGhl IGFjdHVhbCBieXRlcyBvZiB0aGUgc2lnbmF0dXJlLiBDb25jZXB0dWFsbHkgdGhlIGlkZWEgaXMg dGhlIHNhbWUgdGhvdWdoLCBBRkFJSywgYW5kIG1vdmluZyB0aGUgaGFzaCBkZWZpbml0aW9uIHRv IHRoZSBzaWduYXR1cmUgc2NoZW1lIGFzc29jaWF0ZWQgd2l0aCBlYWNoIGtleSBwYXJhbWV0ZXJz IHR5cGUgcmVtb3ZlcyBhIGhhcmR3aXJlZCBkZXBlbmRlbmN5IG9uIFNIQTI1NiBhbmQgYWxzbyBl bGltaW5hdGVzIGEgcm91bmQgb2YgaGFzaGluZyBmb3IgdGhlIFJTQSBrZXkgcGFyYW1ldGVycyB0 eXBlcy4NCg0KVGhlIE9wZW5TU0wgc2lnbmluZyBBUElzIGFyZSBmaW5pY2t5LiAgVGhleSByZWFs bHkgd2FudCB0byBkbyBhIGRpZ2VzdCwgYW5kIHlvdSBoYXZlIHRvIGtub3cgaG93IHRvIGNhbGwg dGhlbSBqdXN0IHJpZ2h0IHRvIHNpZ24gdGhlIGRpZ2VzdCwgcmF0aGVyIHRoYW4gdGhlIGhhc2gg b2YgdGhlIGRpZ2VzdC4gIEhvd2V2ZXIsIGF0IG9uZSBwb2ludCwgSSB3YXMgYWJsZSB0byB2ZXJp ZnkgdGhhdCBib3RoIHdheXMgZ2l2ZSB0aGUgc2FtZSByZXN1bHQuICBJIGFjdHVhbGx5IHVzZSB0 aGUgbm9ybWFsIEFQSXMgbm93IHRoYXQgZG8gdGhlIFNIQTI1NiB3aGlsZSBzaWduaW5nLiAgSSBk byBub3QgdGhpbmsgdGhpcyByZXF1aXJlcyBhIGRvY3VtZW50IGNoYW5nZSwgb3RoZXIgdGhhbiBw ZXJoYXBzIHNvbWUgY2xhcmlmaWNhdGlvbi4NCg0KQWNjb3JkaW5nIHRvIHRoZSBFS00gc3BlYyAo aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3MDUpLCBhIGRpc2FtYmlndWF0aW5nIGxh YmVsIGlzIHJlcXVpcmVkLCBhbmQgd2UncmUgYWxzbyBzdXBwb3NlZCB0byByZWdpc3RlciBpdCBz byB0aGVyZSBhcmUgbm8gbmFtZSBjb2xsaXNpb25zLiAgSXMgdGhpcyBzb21ldGhpbmcgd2UgbmVl ZCB0byB3b3JyeSBhYm91dD8NCg0KSSB0aGluayB0aGF0J3MgYWxyZWFkeSAob3Igd2lsbCBiZSkg Y292ZXJlZCB3aXRoIHRoZSByZWdpc3RyYXRpb24gcmVxdWVzdCBmb3IgIkVYUE9SVEVSLVRva2Vu LUJpbmRpbmciIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2Jp bmQtcHJvdG9jb2wtMDkjc2VjdGlvbi02LjQNCg0KT0ssIGdyZWF0LiAgSW4gdGhhdCBjYXNlLCBh ZGRpbmcgIlRva2VuIEJpbmRpbmciIGlzIHJlZHVuZGFudCwgYnV0IHNpbmNlIHdlIHVzZSBhIDMy LWJ5dGUgYmxvY2sgaGFzaCBhbnl3YXksIEkgZG9uJ3QgdGhpbmsgaXQgd2lsbCBtYWtlIGFueSBk aWZmZXJlbmNlIGlucyBzcGVlZCwgb3RoZXIgdGhhbiB0aGUgY29zdCBvZiBjb3B5aW5nIHRoZSBk YXRhLg0KDQpGb3Igc29tZSByZWFzb24sIEkgdGhvdWdodCB3ZSBoYWQgYWxyZWFkeSByZWdpc3Rl cmVkICJUb2tlbiBCaW5kaW5nIiBhcyBhIHVuaXF1ZSBFS00gbGFiZWwuICBJZiBzbywgd2Ugc2hv dWxkIHByb2JhYmx5IHBhc3MgdGhlIGxhYmVsIHRvIHRoZSBFS00gZWl0aGVyIGluIGFkZGl0aW9u IHRvLCBvciBpbnN0ZWFkIG9mLCBoYXNoaW5nIGl0IGluIHRoZSBmaW5hbCBoYXNoLg0KDQpJIG1h eSBoYXZlIGNvbmZ1c2VkIHRoaW5ncyBieSB1c2luZyB0aGUgdGVybSBsYWJlbCBmb3IgdGhlIEFT Q0lJIHN0cmluZyAiVG9rZW4gQmluZGluZyIgdGhhdCdzIHBhcnQgb2YgdGhlIGNvbmNhdGVuYXRp b24gb2YgdGhpbmdzLiBJdCdzIG5vdCBhIGxhYmVsIGluIHRoZSBSRkMgNTcwNSBzZW5zZSBidXQg bW9yZSBvZiBhIGRpc2FtYmlndWF0ZXIgdGhhdCBpcyB0YWNrZWQgb250byB0aGUgY29udGVudCB0 aGF0IGlzIHNpbmdlZC4gQW5kcmVpIGNhbiBwZXJoYXBzIGV4cGxhaW4gaXQncyBwdXJwb3NlIGJl dHRlci4NCkJ1dCBqdXN0IHRoaW5raW5nIGFib3V0IHRoYXQgbWFrZXMgbWUgd29uZGVyIGlmIGl0 J3MgbmVjZXNzYXJ5LiAiIkVYUE9SVEVSLVRva2VuLUJpbmRpbmciIGlzIGhhc2hlZCBpbnRvIHRo ZSBFS00gd2hpY2ggaXMgdGhlbiB1bmRlciB0aGUgc2lnbmF0dXJlLiBJcyBhbm90aGVyICJUb2tl biBCaW5kaW5nIiBzdHJpbmcgdW5kZXIgdGhlIHNpZ25hdHVyZSBuZWVkZWQgdG8gcHJldmVudCBj cm9zcyBwcm90b2NvbCBhdHRhY2tzPyBEb2Vzbid0IHRoZSBFS00gaW5wdXQgbGFiZWwgYWxyZWFk eSBkbyB0aGF0Pw0KDQpZZXMsIGl0IGRvZXMsIGJ1dCBzbyBsb25nIGFzIGl0IGRvZXMgbm90IGNh dXNlIHRoZSBkYXRhIHRvIHRha2UgdXAgYW5vdGhlciAzMi1ieXRlIGJsb2NrLCBJJ20gT0sgd2l0 aCBpdC4NCg0KU28sIEknbSBPSyB3aXRoIHRoZSAtMDkgdmVyc2lvbi4NCg0KQmlsbA0KDQoNCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpVbmJl YXJhYmxlIG1haWxpbmcgbGlzdA0KVW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5iZWFyYWJs ZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFy YWJsZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpVbmJlYXJhYmxlIG1haWxpbmcgbGlzdA0KVW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86VW5i ZWFyYWJsZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v dW5iZWFyYWJsZQ0KDQoNCg== --_000_CY1PR0301MB0842D1E6A87CB18387FEE34B8CE30CY1PR0301MB0842_ 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 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNv TGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDou NWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9y bWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tNjk3NjYzNjM0OTM1OTg5Mzk5 M21zb2xpc3RwYXJhZ3JhcGgsIGxpLm02OTc2NjM2MzQ5MzU5ODkzOTkzbXNvbGlzdHBhcmFncmFw aCwgZGl2Lm02OTc2NjM2MzQ5MzU5ODkzOTkzbXNvbGlzdHBhcmFncmFwaA0KCXttc28tc3R5bGUt bmFtZTptXzY5NzY2MzYzNDkzNTk4OTM5OTNtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTI2OTA0NzM0 NTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTY3Mzkz MzY3NCAtMTE0NTk0NDM1NiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNv LWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRp LWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3ht bD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2 bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMCBsZXZl bDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7D mDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5i c3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SSB0aGluayBpdCBkZXBlbmRzIG9u IGhvdyB5b3UgZGVmaW5lIHRoZSBhbGdvcml0aG1zLjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Db3Jy ZWN0LCBpZiBvbmUgaW5jbHVkZXMgdGhlIGhhc2ggb3BlcmF0aW9uIGluIHRoZSBkZWZpbml0aW9u IG9mIGEgc2lnbmluZyBvcGVyYXRpb24sIHRoZW4gb25lIGNhbiBzaWduIGFyYml0cmFyeS1sZW5n dGggYnl0ZSBzdHJpbmdzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncyI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87dGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlz dHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsOYPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5JIHRoaW5r IHdlIHNob3VsZCBnbyBiYWNrIHRvIHRoZSBzaWduYXR1cmUgYWxnb3JpdGhtIGluY2x1ZGluZyBh IGhhc2ggYWxnb3JpdGhtIChpZiByZWxldmFudCAtIGFuIEVkRFNBIGFsZ29yaXRobSBkb2Vzbid0 IG5lZWQgYSBoYXNoIGZ1bmN0aW9uKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IZXJl4oCZcyBteSBhdHRlbXB0IGF0IGRvaW5nIHRoaXM6 DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7igJxXaGVuIGFuIHJzYTIwNDhfcGtjczEuNSwgcnNh MjA0OF9wc3Mgb3IgZWNkc2FwMjU2IGtleSBpcyB1c2VkLCB0aGUgc2lnbmF0dXJlIGlzIGNvbXB1 dGVkIG92ZXIgdGhlIFNIQTI1NiBoYXNoIG9mIHRoZSBieXRlIHN0cmluZyByZXByZXNlbnRpbmcg dGhlIGNvbmNhdGVuYXRpb24gb2bigKbigJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4gTmljayBIYXJwZXIgW21haWx0bzpuaGFycGVyQGdvb2dsZS5jb21dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYgNDoyNiBQTTxicj4NCjxi PlRvOjwvYj4gTWlrZSBKb25lcyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0Ozxi cj4NCjxiPkNjOjwvYj4gQW5kcmVpIFBvcG92ICZsdDtBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNv bSZndDs7IEJyaWFuIENhbXBiZWxsICZsdDtiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSZndDs7 IFRva2JpbmQgV0cgJmx0O3VuYmVhcmFibGVAaWV0Zi5vcmcmZ3Q7OyBMZWlmIEpvaGFuc3NvbiAm bHQ7bGVpZmpAc3VuZXQuc2UmZ3Q7OyBCaWxsIENveCAmbHQ7d2F5d2FyZGdlZWtAZ29vZ2xlLmNv bSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBXaGF0IEdldHMgU2ln bmVkICh3YXM6IER1bWIgaWRlYTogYWRkIEVkMjU1MTkgc3VwcG9ydD8pPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayBpdCBkZXBlbmRzIG9uIGhvdyB5b3UgZGVm aW5lIHRoZSBhbGdvcml0aG1zLiBJZiB5b3UgZG8gaXQgYXMgTWlrZSBsaXN0cywgdGhlbiBhbiBh bGdvcml0aG0gdGFrZXMgYW4gYXJiaXRyYXJ5LWxlbmd0aCBieXRlIHNlcXVlbmNlICh0aGUgc2Ft ZSBob2xkcyB0cnVlIGlmIHRoZXkncmUgZGVmaW5lZCBsaWtlIHRoZSBTaWduYXR1cmVTY2hlbWVz IGluIFRMUyAxLjMpLiBSaWdodCBub3csIEkgYmVsaWV2ZQ0KIFRva2VuIEJpbmRpbmcgZGVmaW5l cyBzaWduYXR1cmUgYWxnb3JpdGhtcyBhcyBub3QgY29udGFpbmluZyBhIGhhc2ggYWxnb3JpdGht LCBzaW5jZSBiZWZvcmUgd2Ugc3RhcnRlZCBjb25jYXRlbmF0aW5nIHRoaW5ncyB0byB0aGUgRUtN IHZhbHVlLCB0aGUgbWVzc2FnZSB0byBiZSBzaWduZWQgd2FzIHNob3J0IGVub3VnaCB0aGF0IGl0 IGRpZG4ndCBuZWVkIGFueSBoYXNoaW5nLiBJIHRoaW5rIHdlIHNob3VsZCBnbyBiYWNrIHRvIHRo ZSBzaWduYXR1cmUNCiBhbGdvcml0aG0gaW5jbHVkaW5nIGEgaGFzaCBhbGdvcml0aG0gKGlmIHJl bGV2YW50IC0gYW4gRWREU0EgYWxnb3JpdGhtIGRvZXNuJ3QgbmVlZCBhIGhhc2ggZnVuY3Rpb24p LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBB dWcgMzEsIDIwMTYgYXQgNDoxMCBQTSwgTWlrZSBKb25lcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuSm9uZXNA bWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwMjA2MCI+SSBrbm93IEnigJltIGdldHRpbmcgaW50byB0aGlzIGRpc2N1c3Npb24gbGF0 ZSwgYnV0IEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoYXQgdGhlIFNIQS0yNTYgaGFzaCBvdmVyIHRo ZQ0KIGNvbmNhdGVuYXRpb24gaXMgZm9yLiZuYnNwOyBJdCBzZWVtcyBsaWtlIGFuIHVubmVjZXNz YXJ5IHN0ZXAgdG8gbWUsIGdpdmVuIHRoYXQgYWxsIHRoZSBzaWduYXR1cmUgYWxnb3JpdGhtcyBi ZWluZyBkaXNjdXNzZWQgY2FuIGFsbCBzaWduIGFyYml0cmFyeSBsZW5ndGggYnl0ZSBzZXF1ZW5j ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+VGhvc2Ug YWxnb3JpdGhtcywgSSBiZWxpZXZlIGFyZSAodXNpbmcgUkZDIDc1MTggYWxnb3JpdGhtIGRlc2Ny aXB0aW9ucyk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im02OTc2NjM2MzQ5MzU5 ODkzOTkzbXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6U3ltYm9sO2NvbG9yOiMwMDIwNjAiPsK3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6Ny4wcHQ7Y29sb3I6IzAwMjA2MCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPlJTQVNTQS1QS0NT MS12MV81IHVzaW5nIFNIQS0yNTY8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTY5 NzY2MzYzNDkzNTk4OTM5OTNtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6IzAwMjA2MCI+wrc8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+ UlNBU1NBLVBTUyB1c2luZyBTSEEtMjU2IGFuZCBNR0YxIHdpdGggU0hBLTI1Njwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtNjk3NjYzNjM0OTM1OTg5Mzk5M21zb2xpc3RwYXJhZ3Jh cGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xv cjojMDAyMDYwIj7Ctzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMw MDIwNjAiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMDAyMDYwIj5FQ0RTQSB1c2luZyBQLTI1NiBhbmQgU0hBLTI1Ng0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBuYW1lPSJt XzY5NzY2MzYzNDkzNTk4OTM5OTNfX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzAwMjA2MCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwMjA2MCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVW5iZWFyYWJsZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzp1bmJlYXJhYmxlLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj51bmJlYXJhYmxl LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbmRyZWkgUG9wb3Y8 YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYgNDowMiBQTTxicj4N CjxiPlRvOjwvYj4gTmljayBIYXJwZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpuaGFycGVyQGdvb2ds ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5uaGFycGVyQGdvb2dsZS5jb208L2E+Jmd0OzsgQnJpYW4g Q2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDs8YnI+DQo8 Yj5DYzo8L2I+IFRva2JpbmQgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzp1bmJlYXJhYmxlQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+dW5iZWFyYWJsZUBpZXRmLm9yZzwvYT4mZ3Q7OyBMZWlmIEpv aGFuc3NvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxlaWZqQHN1bmV0LnNlIiB0YXJnZXQ9Il9ibGFu ayI+bGVpZmpAc3VuZXQuc2U8L2E+Jmd0OzsgQmlsbCBDb3ggJmx0OzxhIGhyZWY9Im1haWx0bzp3 YXl3YXJkZ2Vla0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2F5d2FyZGdlZWtAZ29vZ2xl LmNvbTwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBXaGF0 IEdldHMgU2lnbmVkICh3YXM6IER1bWIgaWRlYTogYWRkIEVkMjU1MTkgc3VwcG9ydD8pPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Ib3cgYWJvdXQgd2Ugc2F5IHNvbWV0aGluZyBs aWtlIHRoaXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPuKAnFdoZW4gYW4gcnNhMjA0OF9wa2NzMS41LCByc2EyMDQ4X3BzcyBv ciBlY2RzYXAyNTYga2V5IGlzIHVzZWQsIHRoZSBzaWduYXR1cmUgaXMgY29tcHV0ZWQgb3ZlciB0 aGUgU0hBMjU2IGhhc2ggb2YNCiB0aGUgYnl0ZSBzdHJpbmcgcmVwcmVzZW50aW5nIHRoZSBjb25j YXRlbmF0aW9uIG9m4oCm4oCdPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QSBuZXcgVEIga2V5IHBhcmFt ZXRlcnMgSUQgc3BlY2lmaWNhdGlvbiBjb3VsZCBkZXNjcmliZSBhIGRpZmZlcmVudCBjb25zdHJ1 Y3QuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4gTmljayBIYXJwZXIgWzxhIGhyZWY9Im1haWx0bzpuaGFycGVyQGdvb2dsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5tYWlsdG86bmhhcnBlckBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAzMSwgMjAxNiAzOjU1IFBNPGJyPg0KPGI+VG86PC9iPiBC cmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHku Y29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+Jmd0Ozxi cj4NCjxiPkNjOjwvYj4gQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBv cG92QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0 LmNvbTwvYT4mZ3Q7OyBUb2tiaW5kIFdHICZsdDs8YSBocmVmPSJtYWlsdG86dW5iZWFyYWJsZUBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+Jmd0OzsgTGVp ZiBKb2hhbnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpsZWlmakBzdW5ldC5zZSIgdGFyZ2V0PSJf YmxhbmsiPmxlaWZqQHN1bmV0LnNlPC9hPiZndDs7DQogQmlsbCBDb3ggJmx0OzxhIGhyZWY9Im1h aWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+d2F5d2FyZGdlZWtA Z29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0g V2hhdCBHZXRzIFNpZ25lZCAod2FzOiBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBvcnQ/KTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NeSB1bmRlcnN0YW5kaW5n IGlzIHRoYXQgUC0yNTYgY2FuIG9ubHkgc2lnbiBhIDMyLWJ5dGUgbWVzc2FnZSAoaGVuY2Ugd2h5 IGl0IG1ha2VzIHNlbnNlIHRvIGhhc2ggdGhlIG1lc3NhZ2Ugd2l0aCBzaGEtMjU2IGZpcnN0KS48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGFncmVl IHdpdGggQnJpYW4gdGhhdCB0aGUgaGFzaCBmdW5jdGlvbiAoaWYgYW55KSBzaG91bGQgYmUgcGFy dCBvZiB0aGUga2V5IHBhcmFtLCBzaW1pbGFyIHRvIHRoZSBTaWduYXR1cmVTY2hlbWUgY29tYmlu YXRpb24gaW4gVExTIDEuMy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+T24gV2VkLCBBdWcgMzEsIDIwMTYgYXQgMzo0OCBQTSwgQnJpYW4gQ2FtcGJl bGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5NeSBzdWdnZXN0aW9uIGlz IHRvIHVzZSB0aG9zZSAzNCBieXRlcyBkaXJlY3RseSBhcyB0aGUgaW5wdXQgaW50byB0aGUgc2ln bmF0dXJlIGdlbmVyYXRpb24vdmVyaWZpY2F0aW9uLiBBbmQgZm9yIGVjZHNhcDI1NiBrZXkgcGFy YW1zLCB0byB1c2UgRUNEU0EgdXNpbmcgUC0yNTYgYW5kIFNIQS0yNTYgYXMgdGhlDQogc2lnbmF0 dXJlIGFsZ29yaXRobS4gQWx0aG91Z2ggdGhlIGxhdHRlciBpcyBub3Qgc3RyaWN0bHkgbmVjZXNz YXJ5IEFGQUlDVCBiZWNhdXNlICdyYXcnIEVDRFNBIHVzaW5nIFAtMjU2IGNhbiBzaWduIDM0IGJ5 dGVzIG9rYXkuPGJyPg0KPGJyPg0KQWRtaXR0ZWRseSwgSSBjb3VsZCBiZSBvZmYgYmFzZSBoZXJl IGJ1dCB0aGF0J3MgbW9yZSB3aGF0IEkgd291bGQgaGF2ZSBleHBlY3RlZCB0byBzZWUuIFdlIHNl ZW0gdG8gYmUgdGFsa2luZyBwYXN0IG9uZSBhbm90aGVyLCBob3dldmVyLCBpbiBqdXN0IHRyeWlu ZyB0byBkaXNjdXNzIGl0LiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxicj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2VkLCBBdWcgMzEsIDIwMTYg YXQgMzo0NyBQTSwgQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92 QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5HcmVh dC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZW4gd2UgaGF2ZSAzNCBieXRlcyB3ZSBoYXNoIHdpdGgg U0hBMjU2IGFuZCBzaWduLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XaGVuIHdlIHNpZ24gd2l0aCBS U0EtUFNTIG9yIFJTQS1QS0NTLCB3ZSBhbHNvIHNwZWNpZnkgdGhlIHVzZSBvZiBTSEEyNTYgaW4g dGhlIHBhZGRpbmcgYWxnb3JpdGhtLiBGb3IgRUNEU0EsIHRoZXJlDQogaXMgbm8gbmVlZCB0byBw YWQsIGFuZCB0aGVyZWZvcmUgbm8gbmVlZCAob3Igb3Bwb3J0dW5pdHkpIHRvIHVzZSBwYWRkaW5n IGhhc2guPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Ccmlhbiwgd2hhdCBzcGVjaWZpY2FsbHkgd291bGQg eW91IGxpa2UgdG8gY2hhbmdlIFdSVCBoYXNoaW5nPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJyaWFuIENhbXBiZWxsIFttYWlsdG86PGEg aHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5naWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l c2RheSwgQXVndXN0IDMxLCAyMDE2IDI6NDIgUE08YnI+DQo8Yj5Ubzo8L2I+IEJpbGwgQ294ICZs dDs8YSBocmVmPSJtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PndheXdhcmRnZWVrQGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gQW5kcmVpIFBv cG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20iIHRhcmdl dD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyBUb2tiaW5kIFdH ICZsdDs8YSBocmVmPSJtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+Jmd0OzsgTGVpZiBKb2hhbnNzb24gJmx0OzxhIGhyZWY9 Im1haWx0bzpsZWlmakBzdW5ldC5zZSIgdGFyZ2V0PSJfYmxhbmsiPmxlaWZqQHN1bmV0LnNlPC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtVbmJlYXJhYmxlXSBXaGF0IEdldHMgU2ln bmVkICh3YXM6IER1bWIgaWRlYTogYWRkIEVkMjU1MTkgc3VwcG9ydD8pPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V29ya3MgZm9yIG1lIHRv byAoSSB0aGluaykuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5PbiBXZWQsIEF1ZyAzMSwgMjAxNiBhdCAzOjM0IFBNLCBCaWxsIENveCAmbHQ7PGEg aHJlZj0ibWFpbHRvOndheXdhcmRnZWVrQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj53YXl3 YXJkZ2Vla0Bnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPldvcmtzIGZvciBtZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgQXVnIDMxLCAyMDE2 IGF0IDI6MjAgUE0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJlaS5Qb3Bv dkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG8gc3VtIHVwLCBhcmUgd2UgaW4gYWdyZWVtZW50IHRo YXQgdGhlIGNvbmNhdGVuYXRpb24gd2lsbCBvbmx5IGluY2x1ZGU6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRva2VuQmluZGluZ1R5 cGUgdmFsdWUgY29udGFpbmVkIGluIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgVG9rZW5CaW5kaW5nLnRva2VuYmluZGluZ190eXBlIGZpZWxkOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+LTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjcuMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRva2VuQmluZGluZ0tleVBhcmFtZXRl cnMgdmFsdWUgY29udGFpbmVkIGluIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgVG9rZW5CaW5kaW5nSUQua2V5X3BhcmFtZXRlcnMgZmllbGQ7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4tPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6Ny4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RXhwb3J0ZWQga2V5aW5nIG1hdGVyaWFs IChFS00pIHZhbHVlIG9idGFpbmVkIGZyb20gdGhlIGN1cnJlbnQgVExTPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBjb25uZWN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7igKYgYmVjYXVzZSB0aGUg bGFiZWwgYW5kIHRoZSBQcm90b2NvbFZlcnNpb24gYXJlIHByZXN1bWFibHkgYWxyZWFkeSBpbiB0 aGUgRUtNPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+IEJpbGwgQ294IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOndheXdhcmRnZWVrQGdvb2ds ZS5jb20iIHRhcmdldD0iX2JsYW5rIj53YXl3YXJkZ2Vla0Bnb29nbGUuY29tPC9hPl0NCjxicj4N CjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEF1Z3VzdCAzMSwgMjAxNiAyOjAxIFBNPGJyPg0KPGI+ VG86PC9iPiBCcmlhbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJjYW1wYmVsbEBwaW5n aWRlbnRpdHkuY29tIiB0YXJnZXQ9Il9ibGFuayI+YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb208 L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86 QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZA bWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyBUb2tiaW5kIFdHICZsdDs8YSBocmVmPSJtYWlsdG86dW5i ZWFyYWJsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnVuYmVhcmFibGVAaWV0Zi5vcmc8L2E+ Jmd0OzsgTGVpZiBKb2hhbnNzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpsZWlmakBzdW5ldC5zZSIg dGFyZ2V0PSJfYmxhbmsiPmxlaWZqQHN1bmV0LnNlPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtVbmJlYXJhYmxlXSBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBvcnQ/PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gV2Vk LCBBdWcgMzEsIDIwMTYgYXQgMToxMCBQTSwgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1h aWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVs bEBwaW5naWRlbnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIFdlZCwgQXVnIDMxLCAyMDE2IGF0IDE6MzUgUE0sIEJpbGwg Q294ICZsdDs8YSBocmVmPSJtYWlsdG86d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPndheXdhcmRnZWVrQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBXZWQsIEF1ZyAzMSwg MjAxNiBhdCAxMjoxMiBQTSwgQnJpYW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpiY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJjYW1wYmVsbEBwaW5naWRl bnRpdHkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkluIHdoaWNoIGNhc2UgSSdkIGFnYWluIHN1Z2dlc3QgdGhhdCB0aGUgc2lnbmF0dXJl IGlucHV0IGJlIHRoZSBjb25jYXRlbmF0ZWQgaXRlbXMgZGlyZWN0bHkgKG5vIGhhc2gpIGFuZCB0 aGF0IGhhc2hpbmcgb3Igbm90IGJlIHBhcnQgb2YgdGhlIHNpZ25hdHVyZSBzY2hlbWUgYXNzb2Np YXRlZCB3aXRoIGVhY2gNCiBrZXkgcGFyYW1ldGVycyB0eXBlLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+U291bmRzIGdvb2QgdG8gbWUuJm5ic3A7IEl0IGZpdHMgdGhlIHN0YW5kYXJkIEFQSXMgYSBi aXQgYmV0dGVyLiZuYnNwOyBJSVVDLCB0aGlzIHJlc3VsdCBpcyB0aGUgc2FtZSBlaXRoZXIgd2F5 LCBzbyB0aGlzIGlzIHJlYWxseSBqdXN0IGEgbWF0dGVyIG9mIGhvdyB3ZSBkZXNjcmliZSBpdCwg cmlnaHQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxicj4NCiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMzODc2MUQiPkFmdGVyIHBsYXlpbmcgYXJvdW5kIHdpdGggc29tZSBBUElzIHllc3Rl cmRheSwgSSBkb24ndCB0aGluayB0aGF0IHRoZSByZXN1bHQgaXMgYWN0dWFsbHkgdGhlIHNhbWUu IEF0IGxlYXN0IGFzIGZhciBhcyB0aGUgYWN0dWFsIGJ5dGVzIG9mIHRoZSBzaWduYXR1cmUuDQog Q29uY2VwdHVhbGx5IHRoZSBpZGVhIGlzIHRoZSBzYW1lIHRob3VnaCwgQUZBSUssIGFuZCBtb3Zp bmcgdGhlIGhhc2ggZGVmaW5pdGlvbiB0byB0aGUgc2lnbmF0dXJlIHNjaGVtZSBhc3NvY2lhdGVk IHdpdGggZWFjaCBrZXkgcGFyYW1ldGVycyB0eXBlIHJlbW92ZXMgYSBoYXJkd2lyZWQgZGVwZW5k ZW5jeSBvbiBTSEEyNTYgYW5kIGFsc28gZWxpbWluYXRlcyBhIHJvdW5kIG9mIGhhc2hpbmcgZm9y IHRoZSBSU0Ega2V5IHBhcmFtZXRlcnMgdHlwZXMuJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgT3BlblNTTCBzaWduaW5nIEFQ SXMgYXJlIGZpbmlja3kuJm5ic3A7IFRoZXkgcmVhbGx5IHdhbnQgdG8gZG8gYSBkaWdlc3QsIGFu ZCB5b3UgaGF2ZSB0byBrbm93IGhvdyB0byBjYWxsIHRoZW0ganVzdCByaWdodCB0byBzaWduIHRo ZSBkaWdlc3QsIHJhdGhlciB0aGFuIHRoZSBoYXNoIG9mIHRoZSBkaWdlc3QuJm5ic3A7DQogSG93 ZXZlciwgYXQgb25lIHBvaW50LCBJIHdhcyBhYmxlIHRvIHZlcmlmeSB0aGF0IGJvdGggd2F5cyBn aXZlIHRoZSBzYW1lIHJlc3VsdC4mbmJzcDsgSSBhY3R1YWxseSB1c2UgdGhlIG5vcm1hbCBBUElz IG5vdyB0aGF0IGRvIHRoZSBTSEEyNTYgd2hpbGUgc2lnbmluZy4mbmJzcDsgSSBkbyBub3QgdGhp bmsgdGhpcyByZXF1aXJlcyBhIGRvY3VtZW50IGNoYW5nZSwgb3RoZXIgdGhhbiBwZXJoYXBzIHNv bWUgY2xhcmlmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BY2NvcmRpbmcg dG8gdGhlIEVLTSBzcGVjICg8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NTcwNSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzA1 PC9hPiksIGEgZGlzYW1iaWd1YXRpbmcgbGFiZWwgaXMgcmVxdWlyZWQsIGFuZCB3ZSdyZQ0KIGFs c28gc3VwcG9zZWQgdG8gcmVnaXN0ZXIgaXQgc28gdGhlcmUgYXJlIG5vIG5hbWUgY29sbGlzaW9u cy4mbmJzcDsgSXMgdGhpcyBzb21ldGhpbmcgd2UgbmVlZCB0byB3b3JyeSBhYm91dD8mbmJzcDsN CjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMzODc2MUQiPkkgdGhpbmsgdGhhdCdzIGFscmVhZHkgKG9yIHdpbGwgYmUpIGNvdmVyZWQg d2l0aCB0aGUgcmVnaXN0cmF0aW9uIHJlcXVlc3QgZm9yICZxdW90O0VYUE9SVEVSLVRva2VuLUJp bmRpbmcmcXVvdDsgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLXRva2JpbmQtcHJvdG9jb2wtMDkjc2VjdGlvbi02LjQiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRva2JpbmQtcHJvdG9jb2wt MDkjc2VjdGlvbi02LjQ8L2E+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+T0ssIGdyZWF0LiZuYnNwOyBJbiB0aGF0IGNhc2UsIGFkZGluZyAmcXVv dDtUb2tlbiBCaW5kaW5nJnF1b3Q7IGlzIHJlZHVuZGFudCwgYnV0IHNpbmNlIHdlIHVzZSBhIDMy LWJ5dGUgYmxvY2sgaGFzaCBhbnl3YXksIEkgZG9uJ3QgdGhpbmsgaXQgd2lsbCBtYWtlIGFueSBk aWZmZXJlbmNlIGlucyBzcGVlZCwgb3RoZXIgdGhhbiB0aGUNCiBjb3N0IG9mIGNvcHlpbmcgdGhl IGRhdGEuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Rm9yIHNvbWUgcmVhc29u LCBJIHRob3VnaHQgd2UgaGFkIGFscmVhZHkgcmVnaXN0ZXJlZCAmcXVvdDtUb2tlbiBCaW5kaW5n JnF1b3Q7IGFzIGEgdW5pcXVlIEVLTSBsYWJlbC4mbmJzcDsgSWYgc28sIHdlIHNob3VsZCBwcm9i YWJseSBwYXNzIHRoZSBsYWJlbCB0byB0aGUgRUtNIGVpdGhlciBpbiBhZGRpdGlvbiB0bywgb3Ig aW5zdGVhZA0KIG9mLCBoYXNoaW5nIGl0IGluIHRoZSBmaW5hbCBoYXNoLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IzM4NzYxRCI+SSBtYXkg aGF2ZSBjb25mdXNlZCB0aGluZ3MgYnkgdXNpbmcgdGhlIHRlcm0gbGFiZWwgZm9yIHRoZSBBU0NJ SSBzdHJpbmcgJnF1b3Q7VG9rZW4gQmluZGluZyZxdW90OyB0aGF0J3MgcGFydCBvZiB0aGUgY29u Y2F0ZW5hdGlvbiBvZiB0aGluZ3MuIEl0J3Mgbm90IGEgbGFiZWwgaW4gdGhlIFJGQyA1NzA1IHNl bnNlIGJ1dCBtb3JlIG9mIGEgZGlzYW1iaWd1YXRlciB0aGF0IGlzIHRhY2tlZCBvbnRvIHRoZSBj b250ZW50DQogdGhhdCBpcyBzaW5nZWQuIEFuZHJlaSBjYW4gcGVyaGFwcyBleHBsYWluIGl0J3Mg cHVycG9zZSBiZXR0ZXIuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMzODc2MUQiPkJ1dCBqdXN0 IHRoaW5raW5nIGFib3V0IHRoYXQgbWFrZXMgbWUgd29uZGVyIGlmIGl0J3MgbmVjZXNzYXJ5LiAm cXVvdDsmcXVvdDtFWFBPUlRFUi1Ub2tlbi1CaW5kaW5nJnF1b3Q7IGlzIGhhc2hlZCBpbnRvIHRo ZSBFS00gd2hpY2ggaXMgdGhlbiB1bmRlciB0aGUgc2lnbmF0dXJlLiBJcw0KIGFub3RoZXIgJnF1 b3Q7VG9rZW4gQmluZGluZyZxdW90OyBzdHJpbmcgdW5kZXIgdGhlIHNpZ25hdHVyZSBuZWVkZWQg dG8gcHJldmVudCBjcm9zcyBwcm90b2NvbCBhdHRhY2tzPyBEb2Vzbid0IHRoZSBFS00gaW5wdXQg bGFiZWwgYWxyZWFkeSBkbyB0aGF0Pw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+WWVzLCBpdCBkb2VzLCBidXQgc28gbG9uZyBhcyBpdCBkb2VzIG5vdCBj YXVzZSB0aGUgZGF0YSB0byB0YWtlIHVwIGFub3RoZXIgMzItYnl0ZSBibG9jaywgSSdtIE9LIHdp dGggaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5TbywgSSdtIE9LIHdpdGggdGhlIC0wOSB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmlsbCZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+X19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpVbmJlYXJhYmxlIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpVbmJlYXJhYmxlQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+VW5iZWFyYWJsZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGUiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VuYmVhcmFibGU8L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N ClVuYmVhcmFibGUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlVuYmVhcmFibGVA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5VbmJlYXJhYmxlQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5iZWFyYWJsZSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdW5i ZWFyYWJsZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR0301MB0842D1E6A87CB18387FEE34B8CE30CY1PR0301MB0842_-- From nobody Wed Aug 31 16:54:35 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 5A92212D7AF for ; Wed, 31 Aug 2016 16:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 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, RP_MATCHES_RCVD=-0.548, 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 bB-vuzKPcb40 for ; Wed, 31 Aug 2016 16:54:32 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (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 973F012D7BF for ; Wed, 31 Aug 2016 16:54:32 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id l94so117259519ual.0 for ; Wed, 31 Aug 2016 16:54:32 -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=sUq0aIbpA7f9xyk+hh4W6dIAPS8kiZdKS/9P1PilXOc=; b=O9to4yxuEONJiPAJT9FIoHoTDsYtJV85VCTg1GBF66fH1bVlg1gAc/nQXivAFmKO0W G1DUNQ9gl29czumDzlWuy9Y+d3F0tIwaekD10+2OEmTcnjIcOvGD0of8H9ECPlEtnr8Q a18mgkVNeTyiq86KUKKQ50ylmCzeKdvDBhUrXzatjqqTA1nzyeDkKpbXP4K8rIWMTjvv xiySMOfsC6kxBLREX8uhEzcR9ypJngSgBtRrq0VrNMxenDNxCFvzdbzQsDWSRSb4m79s riSIiUoAMA4s6FM9XOm1+Dw06eltDw+xBs9E/DpMqQYjdeykjdUv9oAOJaw4oPjVrTtT MGtg== 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=sUq0aIbpA7f9xyk+hh4W6dIAPS8kiZdKS/9P1PilXOc=; b=WtAo/f6BsqywuyNvjQhg+CSiDoRVwAenaKus2YU1gI8dRHabG2pLpnm/5QzjJssCmT 2cKWI//hrzl7cr0IFHp+iIat+XO1oLhOrlHlpzFgghjG7hTGztPfdcVzOSgRFHi/11Eh v2Un/ppuauVwIMD5fq/n6jGJvqE77QLdSaBQYMabbHGfP0LYtA1vanwFcrD5RaSVrYW0 xYuKrntpfRPaPjSAxxY134rdh/g7LFXjfwMyYS9OKHqipvMBWoFDmzb5kgQI+WF2xjwD L3D7SYaqgNO1Hx8zUKfw9dErndcuLwCSHR5J28iYyX96Nx4QU1oZqZP/elehTe4pYYRD 39Ow== X-Gm-Message-State: AE9vXwPZ2aJouDeizJtUBvMHdWc2yuXfzY+2+xBSMk9T/g16vkFbclk8YaAA3Um7hveBdb4WgXF7FlTl/QyunhX7 X-Received: by 10.159.53.1 with SMTP id o1mr7258032uao.15.1472687671552; Wed, 31 Aug 2016 16:54:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.67.209 with HTTP; Wed, 31 Aug 2016 16:54:11 -0700 (PDT) In-Reply-To: References: From: Nick Harper Date: Wed, 31 Aug 2016 16:54:11 -0700 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=94eb2c04cac687744a053b66d11e Archived-At: Cc: Bill Cox , Mike Jones , Brian Campbell , Tokbind WG , Leif Johansson Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) 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, 31 Aug 2016 23:54:35 -0000 --94eb2c04cac687744a053b66d11e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 31, 2016 at 4:37 PM, Andrei Popov wrote: > =C3=98 I think we should go back to the signature algorithm including a = hash > algorithm (if relevant - an EdDSA algorithm doesn't need a hash function)= . > > Here=E2=80=99s my attempt at doing this: =E2=80=9CWhen an rsa2048_pkcs1.5= , rsa2048_pss or > ecdsap256 key is used, the signature is computed over the SHA256 hash of > the byte string representing the concatenation of=E2=80=A6=E2=80=9D. > I think this wording should be split up, so something defines "the message to be signed is the concatenation of ...", and then the existing signature algorithms can specify to hash with sha256 that message (it could be one statement, like "When an rsa2048_pkcs1.5, rsa2048_pss, or ecdsap256 key is used, the signature is computed over the SHA256 hash of the message to be signed", or split into multiple statements, like how we describe rsa and p256 separately). --94eb2c04cac687744a053b66d11e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Aug 31, 2016 at 4:37 PM, Andrei Popov <Andrei.Popov@m= icrosoft.com> wrote:

=C3=98=C2=A0 I think we should go back to the signature algorithm i= ncluding a hash algorithm (if relevant - an EdDSA algorithm doesn't nee= d a hash function).

Here=E2=80=99s my attempt at doing this: =E2=80=9CWhen an rsa2048_pkcs1.5, rsa2048_pss or ecdsap256 key is u= sed, the signature is computed over the SHA256 hash of the byte string repr= esenting the concatenation of=E2=80=A6=E2=80=9D.


I think this wording should be split up, so so= mething defines "the message to be signed is the concatenation of ...&= quot;, and then the existing signature algorithms can specify to hash with = sha256 that message (it could be one statement, like "When an rsa2048_= pkcs1.5, rsa2048_pss, or ecdsap256 key is used, the signature is computed o= ver the SHA256 hash of the message to be signed", or split into multip= le statements, like how we describe rsa and p256 separately).
--94eb2c04cac687744a053b66d11e-- From nobody Wed Aug 31 16:58:54 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 3F60E12B044 for ; Wed, 31 Aug 2016 16:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 qubhOHYYvCdQ for ; Wed, 31 Aug 2016 16:58:50 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0109.outbound.protection.outlook.com [104.47.36.109]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF3D12D7AF for ; Wed, 31 Aug 2016 16:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6yoDMxi7WiHAGS1jkfmQ4sHJjaw1udmguyXPfVkUV+w=; b=DsaB8N7rTleiocqrRcDxQvmhlivJwqLncKz8xHk5HGT7j8E2mKv5cBZkxbUrU7upBlbCzBIwxZPPcJ2r/AMC9Sc9xPXolhRAUyHQAaDy56k6DmUOGnZNIdXxYHsnI73gaMgbQ5JwJ6QA0pkuwAMeoeA4r4JNmPbqhIx3Nutv53A= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0636.namprd03.prod.outlook.com (10.160.158.142) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.9; Wed, 31 Aug 2016 23:58:44 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Wed, 31 Aug 2016 23:58:44 +0000 From: Andrei Popov To: Nick Harper Thread-Topic: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) Thread-Index: AdIDzYe/nNN4QigzR4G2nIa8+fQ4XAAAex2AAABDp4AAAAco4AACRqKAAAA6aYAAABgK8AAAOeBQAADE4wAAAEwGIAAAsleAAAAhKuA= Date: Wed, 31 Aug 2016 23:58:44 +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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: ca55ade2-fb0d-4b5f-18b8-08d3d1fabdd1 x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0636; 6:Kr7+R/7RlbAYZNN7W96BYPytFTiOZQfVhd+pFjo+xyUPqEQalvZ0BkFEBG3AJ+4+4c8XSxxCX2ILgVUwhvtBzrI6h43tuBaK5IRdGDvRxJnDq4+n6DAm5yMpCfOPHkOSwU2ko1BPQHaJZmc2Uk1uRmkO6KS1jrMGoJfsXY4bIxlX+naksYzEULddsSE1GMMyL1W1l/7sRLtIaQv6MpJ93NNmNWE1COXwJyCCVZv5LBh8bLbcTFLujr6iIPpO6LgK0JmAbSFAbGQ91B3qt9JYcvdxWHD1EY0GXTKXhZvB+JzMnrV1VXK1Q5IGha5ZgDJv8TmCVgIjJdiguL8SkXCtAg==; 5:L6v2Zp+b7Gb43QYLmVwN9DvPFKRWvIlbJS8Yb1rDOmEnPksMWrj3h3wj64/R58YXSLkJ+uHBLWOCTLYqSVjSy/fpx1EfS99TI16yCqOMlutoYWX8QDa4bEcgJCqB6zPfgsKQG4B3YSbqZconG5Mibg==; 24:Zl7+beqI9K8g/Kp57dFQ6KOAfYzLmHVzEQbWHSwcnTqpGgFe7dBj9JhaPE02Hf4m1t/i3pSXk3euDo16tHiii4G86XCwGPjFtMsoC/D9gNk=; 7:Peaui8JxD5qjk70b/aGVZzr19djCn+ZdlFQX27iEsXY7+q7j9t8PQoxFcJGBPUPwZC1vDK2rucAnOU/dAV7J98uO1YypEtZEcEkljoC1lwcAwYT1ESXIPzcPkVUiJIsSB3hhqqv2z7bBHSp60H8Gdb0SnEfM6rrrLTS1NeNssU4UZf6RoqGK5Xu5E6m+Aj6pKuj2yZYPVrOS0QKddMcfT1lbYymyxGttxUjnKeryUEd+fY8lnFfsDW5tC9XEI8pX x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0636; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0636; x-forefront-prvs: 00514A2FE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(199003)(189002)(24454002)(5002640100001)(86362001)(92566002)(87936001)(74316002)(16236675004)(790700001)(6116002)(102836003)(586003)(93886004)(189998001)(122556002)(76576001)(15975445007)(2900100001)(2950100001)(97736004)(10090500001)(86612001)(33656002)(5660300001)(54356999)(77096005)(76176999)(105586002)(8936002)(3660700001)(50986999)(101416001)(4326007)(110136002)(19300405004)(19625215002)(2906002)(19580405001)(68736007)(7846002)(8676002)(19609705001)(9686002)(3280700002)(81156014)(81166006)(106356001)(10400500002)(8990500004)(19580395003)(5005710100001)(10290500002)(99286002)(7696003)(11100500001)(7736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0636; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB084256C5BCD9FB609D6C6A528CE30CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 23:58:44.3226 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0636 Archived-At: Cc: Bill Cox , Mike Jones , Brian Campbell , Tokbind WG , Leif Johansson Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) 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, 31 Aug 2016 23:58:52 -0000 --_000_CY1PR0301MB084256C5BCD9FB609D6C6A528CE30CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VyZSwgdGhpcyBzb3VuZHMgZ29vZCB0byBtZS4NCg0KRnJvbTogTmljayBIYXJwZXIgW21haWx0 bzpuaGFycGVyQGdvb2dsZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAzMSwgMjAxNiA0 OjU0IFBNDQpUbzogQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4NCkNj OiBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+OyBCcmlhbiBDYW1wYmVs bCA8YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+OyBUb2tiaW5kIFdHIDx1bmJlYXJhYmxlQGll dGYub3JnPjsgTGVpZiBKb2hhbnNzb24gPGxlaWZqQHN1bmV0LnNlPjsgQmlsbCBDb3ggPHdheXdh cmRnZWVrQGdvb2dsZS5jb20+DQpTdWJqZWN0OiBSZTogW1VuYmVhcmFibGVdIFdoYXQgR2V0cyBT aWduZWQgKHdhczogRHVtYiBpZGVhOiBhZGQgRWQyNTUxOSBzdXBwb3J0PykNCg0KDQoNCk9uIFdl ZCwgQXVnIDMxLCAyMDE2IGF0IDQ6MzcgUE0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1p Y3Jvc29mdC5jb208bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQoN Cj4gIEkgdGhpbmsgd2Ugc2hvdWxkIGdvIGJhY2sgdG8gdGhlIHNpZ25hdHVyZSBhbGdvcml0aG0g aW5jbHVkaW5nIGEgaGFzaCBhbGdvcml0aG0gKGlmIHJlbGV2YW50IC0gYW4gRWREU0EgYWxnb3Jp dGhtIGRvZXNuJ3QgbmVlZCBhIGhhc2ggZnVuY3Rpb24pLg0KSGVyZeKAmXMgbXkgYXR0ZW1wdCBh dCBkb2luZyB0aGlzOiDigJxXaGVuIGFuIHJzYTIwNDhfcGtjczEuNSwgcnNhMjA0OF9wc3Mgb3Ig ZWNkc2FwMjU2IGtleSBpcyB1c2VkLCB0aGUgc2lnbmF0dXJlIGlzIGNvbXB1dGVkIG92ZXIgdGhl IFNIQTI1NiBoYXNoIG9mIHRoZSBieXRlIHN0cmluZyByZXByZXNlbnRpbmcgdGhlIGNvbmNhdGVu YXRpb24gb2bigKbigJ0uDQoNCkkgdGhpbmsgdGhpcyB3b3JkaW5nIHNob3VsZCBiZSBzcGxpdCB1 cCwgc28gc29tZXRoaW5nIGRlZmluZXMgInRoZSBtZXNzYWdlIHRvIGJlIHNpZ25lZCBpcyB0aGUg Y29uY2F0ZW5hdGlvbiBvZiAuLi4iLCBhbmQgdGhlbiB0aGUgZXhpc3Rpbmcgc2lnbmF0dXJlIGFs Z29yaXRobXMgY2FuIHNwZWNpZnkgdG8gaGFzaCB3aXRoIHNoYTI1NiB0aGF0IG1lc3NhZ2UgKGl0 IGNvdWxkIGJlIG9uZSBzdGF0ZW1lbnQsIGxpa2UgIldoZW4gYW4gcnNhMjA0OF9wa2NzMS41LCBy c2EyMDQ4X3Bzcywgb3IgZWNkc2FwMjU2IGtleSBpcyB1c2VkLCB0aGUgc2lnbmF0dXJlIGlzIGNv bXB1dGVkIG92ZXIgdGhlIFNIQTI1NiBoYXNoIG9mIHRoZSBtZXNzYWdlIHRvIGJlIHNpZ25lZCIs IG9yIHNwbGl0IGludG8gbXVsdGlwbGUgc3RhdGVtZW50cywgbGlrZSBob3cgd2UgZGVzY3JpYmUg cnNhIGFuZCBwMjU2IHNlcGFyYXRlbHkpLg0K --_000_CY1PR0301MB084256C5BCD9FB609D6C6A528CE30CY1PR0301MB0842_ 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 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5t LTE1NDc5NjQ3NDk4MTE1MTk3NW1zb2xpc3RwYXJhZ3JhcGgsIGxpLm0tMTU0Nzk2NDc0OTgxMTUx OTc1bXNvbGlzdHBhcmFncmFwaCwgZGl2Lm0tMTU0Nzk2NDc0OTgxMTUxOTc1bXNvbGlzdHBhcmFn cmFwaA0KCXttc28tc3R5bGUtbmFtZTptXy0xNTQ3OTY0NzQ5ODExNTE5NzVtc29saXN0cGFyYWdy YXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U3VyZSwgdGhpcyBzb3VuZHMgZ29vZCB0byBt ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE5p Y2sgSGFycGVyIFttYWlsdG86bmhhcnBlckBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFdlZG5lc2RheSwgQXVndXN0IDMxLCAyMDE2IDQ6NTQgUE08YnI+DQo8Yj5Ubzo8L2I+IEFuZHJl aSBQb3BvdiAmbHQ7QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBNaWtlIEpvbmVzICZsdDtNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20mZ3Q7OyBCcmlhbiBD YW1wYmVsbCAmbHQ7YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20mZ3Q7OyBUb2tiaW5kIFdHICZs dDt1bmJlYXJhYmxlQGlldGYub3JnJmd0OzsgTGVpZiBKb2hhbnNzb24gJmx0O2xlaWZqQHN1bmV0 LnNlJmd0OzsgQmlsbCBDb3ggJmx0O3dheXdhcmRnZWVrQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbVW5iZWFyYWJsZV0gV2hhdCBHZXRzIFNpZ25lZCAod2FzOiBEdW1i IGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBvcnQ/KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFdlZCwgQXVnIDMxLCAyMDE2IGF0IDQ6MzcgUE0sIEFuZHJlaSBQb3BvdiAmbHQ7PGEgaHJlZj0i bWFpbHRvOkFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QW5kcmVp LlBvcG92QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtLTE1NDc5NjQ3NDk4MTE1MTk3NW1zb2xp c3RwYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPsOYPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOw0KPC9zcGFuPkkgdGhpbmsgd2Ug c2hvdWxkIGdvIGJhY2sgdG8gdGhlIHNpZ25hdHVyZSBhbGdvcml0aG0gaW5jbHVkaW5nIGEgaGFz aCBhbGdvcml0aG0gKGlmIHJlbGV2YW50IC0gYW4gRWREU0EgYWxnb3JpdGhtIGRvZXNuJ3QgbmVl ZCBhIGhhc2ggZnVuY3Rpb24pLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkhlcmXigJlzIG15IGF0dGVtcHQgYXQgZG9pbmcgdGhpczog4oCc V2hlbiBhbiByc2EyMDQ4X3BrY3MxLjUsIHJzYTIwNDhfcHNzIG9yIGVjZHNhcDI1NiBrZXkgaXMg dXNlZCwgdGhlIHNpZ25hdHVyZSBpcw0KIGNvbXB1dGVkIG92ZXIgdGhlIFNIQTI1NiBoYXNoIG9m IHRoZSBieXRlIHN0cmluZyByZXByZXNlbnRpbmcgdGhlIGNvbmNhdGVuYXRpb24gb2bigKbigJ0u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhpcyB3b3JkaW5nIHNob3VsZCBi ZSBzcGxpdCB1cCwgc28gc29tZXRoaW5nIGRlZmluZXMgJnF1b3Q7dGhlIG1lc3NhZ2UgdG8gYmUg c2lnbmVkIGlzIHRoZSBjb25jYXRlbmF0aW9uIG9mIC4uLiZxdW90OywgYW5kIHRoZW4gdGhlIGV4 aXN0aW5nIHNpZ25hdHVyZSBhbGdvcml0aG1zIGNhbiBzcGVjaWZ5IHRvIGhhc2ggd2l0aCBzaGEy NTYgdGhhdCBtZXNzYWdlIChpdCBjb3VsZCBiZSBvbmUgc3RhdGVtZW50LCBsaWtlDQogJnF1b3Q7 V2hlbiBhbiByc2EyMDQ4X3BrY3MxLjUsIHJzYTIwNDhfcHNzLCBvciBlY2RzYXAyNTYga2V5IGlz IHVzZWQsIHRoZSBzaWduYXR1cmUgaXMgY29tcHV0ZWQgb3ZlciB0aGUgU0hBMjU2IGhhc2ggb2Yg dGhlIG1lc3NhZ2UgdG8gYmUgc2lnbmVkJnF1b3Q7LCBvciBzcGxpdCBpbnRvIG11bHRpcGxlIHN0 YXRlbWVudHMsIGxpa2UgaG93IHdlIGRlc2NyaWJlIHJzYSBhbmQgcDI1NiBzZXBhcmF0ZWx5KS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR0301MB084256C5BCD9FB609D6C6A528CE30CY1PR0301MB0842_-- From nobody Wed Aug 31 17: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 7B17612D7CB for ; Wed, 31 Aug 2016 17:16:59 -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 ZXdee54E4uH5 for ; Wed, 31 Aug 2016 17:16:56 -0700 (PDT) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 EE42912D7AC for ; Wed, 31 Aug 2016 17:16:55 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id e124so74558490ith.0 for ; Wed, 31 Aug 2016 17:16:55 -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=eAgNdTda0Qs5nWc3ag/FzbLjk+YEk405/ErfHDqj0JQ=; b=RPTwZUtT1bQWXP9gpoyZwFOyM/hgBnBWCHioU5MSftSMNmOlUyOrw4poRQVfd93tnJ GiNgiAJTljZxVvGAbfCLNzc6SotHnHrfjFGCIpreS9LNT4voU/DTeTYp8a9p8joEySSi iWmjsAFBCXgBgva1cePaN7jLF/VrbiG5QrCcY= 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=eAgNdTda0Qs5nWc3ag/FzbLjk+YEk405/ErfHDqj0JQ=; b=TRjZ7otfwvzl6DvgnlFYGWtNH3euYQOtAQdHFgy17l3pZIrHwFNqYXcm0eoknznbLW RhJMT4ArEDzBrK4A/GZmxFjrEz1ZNAggG8lO8saPJ6wFj/QfEAel4Hp8dL0DUQmzA204 xL7sYfwX7AyKKVutIh8J4OJIVeBJSpZh+PnneyOaf/+9c4gnqBG7EZ582ScfLUHiXWAC lWtlwlMqBCVh8J6WnfQbG7AzIXEKT5k+LG1qOVsLPBrrg4JD6WMZmY+KrSgdc3fAT9Aj LSmIPaGS5dF8Vwg38impiUxYMQAkr6VlmwUe8k0VabjZEpRvWek11zEoF8yo4vFmPs+p xnbg== X-Gm-Message-State: AE9vXwOirtALGNk37UL1a7cE5+Jz2Paw9OjclF3Kv/tu5BV1Gs4T3kL2jyStyobOZBsNQxOJ2B724YpFv/T+fMyF X-Received: by 10.36.84.135 with SMTP id t129mr36440182ita.63.1472689015105; Wed, 31 Aug 2016 17:16:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.114.20 with HTTP; Wed, 31 Aug 2016 17:16:53 -0700 (PDT) Received: by 10.79.114.20 with HTTP; Wed, 31 Aug 2016 17:16:53 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Wed, 31 Aug 2016 18:16:53 -0600 Message-ID: To: Andrei Popov Content-Type: multipart/alternative; boundary=001a1143d9229c6742053b6721ac Archived-At: Cc: Tokbind WG , Mike Jones , Leif Johansson , Nick Harper , Bill Cox Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) 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, 01 Sep 2016 00:17:00 -0000 --001a1143d9229c6742053b6721ac Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'll propose some specific text, if that's okay. Tomorrow though. I'm on family duty for the rest of the evening. On Aug 31, 2016 5:58 PM, "Andrei Popov" wrote: > Sure, this sounds good to me. > > > > *From:* Nick Harper [mailto:nharper@google.com] > *Sent:* Wednesday, August 31, 2016 4:54 PM > *To:* Andrei Popov > *Cc:* Mike Jones ; Brian Campbell < > bcampbell@pingidentity.com>; Tokbind WG ; Leif > Johansson ; Bill Cox > *Subject:* Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 > support?) > > > > > > > > On Wed, Aug 31, 2016 at 4:37 PM, Andrei Popov > wrote: > > =C3=98 I think we should go back to the signature algorithm including a = hash > algorithm (if relevant - an EdDSA algorithm doesn't need a hash function)= . > > Here=E2=80=99s my attempt at doing this: =E2=80=9CWhen an rsa2048_pkcs1.5= , rsa2048_pss or > ecdsap256 key is used, the signature is computed over the SHA256 hash of > the byte string representing the concatenation of=E2=80=A6=E2=80=9D. > > > > I think this wording should be split up, so something defines "the messag= e > to be signed is the concatenation of ...", and then the existing signatur= e > algorithms can specify to hash with sha256 that message (it could be one > statement, like "When an rsa2048_pkcs1.5, rsa2048_pss, or ecdsap256 key i= s > used, the signature is computed over the SHA256 hash of the message to be > signed", or split into multiple statements, like how we describe rsa and > p256 separately). > --001a1143d9229c6742053b6721ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'll propose some specific text, if that's okay. Tom= orrow though. I'm on family duty for the rest of the evening.


On Aug 31, 2016 5= :58 PM, "Andrei Popov" <Andrei.Popov@microsoft.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Sure, this sounds good to me.<= /p>

=C2=A0

From: Nick Harper [mailto:nharper@google.com]
Sent: Wednesday, August 31, 2016 4:54 PM
To: Andrei Popov <Andrei.Popov@microsoft.com>
Cc: Mike Jones <Michael.Jones@microsoft.com>; Brian Campbell <bcampbell@ping= identity.com>; Tokbind WG <unbearable@ietf.org>; Leif Johansson <leifj@sunet.se>; Bill C= ox <waywardg= eek@google.com>
Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25= 519 support?)

=C2=A0

=C2=A0

=C2=A0

On Wed, Aug 31, 2016 at 4:37 PM, Andrei Popov <Andrei.Popov@= microsoft.com> wrote:

=C3=98=C2=A0 I think we should go back to the signature algorithm including a has= h algorithm (if relevant - an EdDSA algorithm doesn't need a hash funct= ion).

Here=E2=80=99s my attempt at doing this: =E2=80=9CW= hen an rsa2048_pkcs1.5, rsa2048_pss or ecdsap256 key is used, the signature= is computed over the SHA256 hash of the byte string representing the concaten= ation of=E2=80=A6=E2=80=9D.

=C2=A0

I think this wording should be split up, so somethin= g defines "the message to be signed is the concatenation of ...",= and then the existing signature algorithms can specify to hash with sha256= that message (it could be one statement, like "When an rsa2048_pkcs1.5, rsa2048_pss, or ecdsap256 key is used, the = signature is computed over the SHA256 hash of the message to be signed"= ;, or split into multiple statements, like how we describe rsa and p256 sep= arately).

--001a1143d9229c6742053b6721ac-- From nobody Wed Aug 31 17:18: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 8004D12D743 for ; Wed, 31 Aug 2016 17:18:44 -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 8kFdrU4ktGAz for ; Wed, 31 Aug 2016 17:18:43 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0124.outbound.protection.outlook.com [104.47.42.124]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B14012D7CB for ; Wed, 31 Aug 2016 17:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NPhZg1ow2s85rdH2WogMO2hONbnmGBYn1tL7EsoGAIM=; b=f59DFIu8+5ggl2K4y8WgjWx4EZthUP/WJ2XKysHyYBfTOsLp4GWSjYknYkWMDOSEd6G937UQOw/MnyXm2GH4Ck8wvKs0CIsmOhiIM+rLL9HQwOKsdwWnjixZpIxgkQMymC/yALDiVhip74WPQBw8L9RzGIiMF1Tw+vcMF+VqJsc= Received: from CY1PR0301MB0842.namprd03.prod.outlook.com (10.160.163.148) by CY1PR0301MB0634.namprd03.prod.outlook.com (10.160.158.140) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.9; Thu, 1 Sep 2016 00:18:37 +0000 Received: from CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) by CY1PR0301MB0842.namprd03.prod.outlook.com ([10.160.163.148]) with mapi id 15.01.0599.010; Thu, 1 Sep 2016 00:18:39 +0000 From: Andrei Popov To: Brian Campbell Thread-Topic: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) Thread-Index: AdIDzYe/nNN4QigzR4G2nIa8+fQ4XAAAex2AAABDp4AAAAco4AACRqKAAAA6aYAAABgK8AAAOeBQAADE4wAAAEwGIAAAsleAAAAhKuAAAKnKgAAACNXw Date: Thu, 1 Sep 2016 00:18: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: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-ms-office365-filtering-correlation-id: 7a08ed40-3ca9-4495-beee-08d3d1fd85de x-microsoft-exchange-diagnostics: 1; CY1PR0301MB0634; 6:t5ifYzupi8oUfrU0a+xJEU8bw/+4GtT5zIu8eZ8XeJCRJB2Jf4iDDctMpqTiU1Cxfn6Rl+7afOCBn3zR7PdZORQFEOe3KfUhBe3Qa5NaQNpE3NDFYsT7MMLdbZgg7nuN7hhNJSuYBNxypKPDrC75fNxqu8It2TRe5q2cK/Dyzb1OtLf2/Ka4EvmcvZ75RXpEE7Rt6uuZSbNBLF7dnzmi1cvWpotgNF9Pxyz/Zp+djx2M/QyxUQwDzcipJgGOjDviFU9xo0XiskCvPGAo0sRWCYl5rmCRl65djiGIIj2p3Oo3dHEZiRmQHA2o8WIlXnNmc9eu8P/aRF5f1iKgg3sLDA==; 5:/tHFX9XpPHlrVgJ4Dm4d+H5p40/tRPjo1NEpeM+Z8JVm0eYdhPj0LAI/fTCNEbgbO6QCjGr6pSnf10F2KG+frTMChiJKYHjnhZTmCl4UZzQrr1O714sh0AyCVlNgI/lqscONGF7ista6kzILG5lLQA==; 24:Hw9Qo9EyVvAQ8hUcvipRZNIczmQoLDt3KVHl9WoAvStidP9U81GfLHV06uvJarkUVz15v/CHIQgASlIvNO5IWezl7HbgNKk75yOd+ROsxlk=; 7:EIhsqRx9Y4nZniT+9gl153zOpcvqWFd/qxcPkeEuJXCYZqO3RXg++veksrr9Vg/p192TzF5kJgxWTMpvxaYDVATqXSx/dAHKn3+Z//b3kvoSuRWN2uqun7DdPASjur1o62RblIgA7GDqD+QV7GsgwPKFJv3vjUAqWd/kLhD7ZS+lRU8OIwMGbG2ib8FjxrCWrqjU9IIoOByyjMMwDhzWZLYM6gXiAZT/xJRfuGrrBS2FRYYWQuXF/hva3w+7nMu5 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0301MB0634; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155)(69029272430364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:CY1PR0301MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0634; x-forefront-prvs: 0052308DC6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(24454002)(377454003)(199003)(110136002)(76576001)(3660700001)(7736002)(7846002)(7696003)(5002640100001)(122556002)(74316002)(68736007)(3280700002)(586003)(33656002)(10290500002)(790700001)(102836003)(5005710100001)(16236675004)(8990500004)(81156014)(81166006)(6116002)(8676002)(86362001)(19580395003)(189998001)(86612001)(77096005)(19609705001)(97736004)(15975445007)(8936002)(9686002)(5660300001)(10400500002)(93886004)(87936001)(106356001)(2906002)(19625215002)(10090500001)(19300405004)(19580405001)(101416001)(4326007)(54356999)(50986999)(2900100001)(2950100001)(76176999)(99286002)(92566002)(105586002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0634; H:CY1PR0301MB0842.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR0301MB08424DF7B90AAF2E47DFBF898CE20CY1PR0301MB0842_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Sep 2016 00:18:39.0058 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0634 Archived-At: Cc: Tokbind WG , Mike Jones , Leif Johansson , Nick Harper , Bill Cox Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?) 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, 01 Sep 2016 00:18:44 -0000 --_000_CY1PR0301MB08424DF7B90AAF2E47DFBF898CE20CY1PR0301MB0842_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIHByb3Bvc2UgdGhlIHRleHQsIGl0IHdpbGwgaGVscCBhIGxvdC4NCg0KRnJvbTogQnJp YW4gQ2FtcGJlbGwgW21haWx0bzpiY2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbV0NClNlbnQ6IFdl ZG5lc2RheSwgQXVndXN0IDMxLCAyMDE2IDU6MTcgUE0NClRvOiBBbmRyZWkgUG9wb3YgPEFuZHJl aS5Qb3BvdkBtaWNyb3NvZnQuY29tPg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWlj cm9zb2Z0LmNvbT47IEJpbGwgQ294IDx3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPjsgTmljayBIYXJw ZXIgPG5oYXJwZXJAZ29vZ2xlLmNvbT47IExlaWYgSm9oYW5zc29uIDxsZWlmakBzdW5ldC5zZT47 IFRva2JpbmQgV0cgPHVuYmVhcmFibGVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW1VuYmVhcmFi bGVdIFdoYXQgR2V0cyBTaWduZWQgKHdhczogRHVtYiBpZGVhOiBhZGQgRWQyNTUxOSBzdXBwb3J0 PykNCg0KDQpJJ2xsIHByb3Bvc2Ugc29tZSBzcGVjaWZpYyB0ZXh0LCBpZiB0aGF0J3Mgb2theS4g VG9tb3Jyb3cgdGhvdWdoLiBJJ20gb24gZmFtaWx5IGR1dHkgZm9yIHRoZSByZXN0IG9mIHRoZSBl dmVuaW5nLg0KDQpPbiBBdWcgMzEsIDIwMTYgNTo1OCBQTSwgIkFuZHJlaSBQb3BvdiIgPEFuZHJl aS5Qb3BvdkBtaWNyb3NvZnQuY29tPG1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4+ IHdyb3RlOg0KU3VyZSwgdGhpcyBzb3VuZHMgZ29vZCB0byBtZS4NCg0KRnJvbTogTmljayBIYXJw ZXIgW21haWx0bzpuaGFycGVyQGdvb2dsZS5jb208bWFpbHRvOm5oYXJwZXJAZ29vZ2xlLmNvbT5d DQpTZW50OiBXZWRuZXNkYXksIEF1Z3VzdCAzMSwgMjAxNiA0OjU0IFBNDQpUbzogQW5kcmVpIFBv cG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jv c29mdC5jb20+Pg0KQ2M6IE1pa2UgSm9uZXMgPE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTxt YWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPj47IEJyaWFuIENhbXBiZWxsIDxiY2Ft cGJlbGxAcGluZ2lkZW50aXR5LmNvbTxtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20+ PjsgVG9rYmluZCBXRyA8dW5iZWFyYWJsZUBpZXRmLm9yZzxtYWlsdG86dW5iZWFyYWJsZUBpZXRm Lm9yZz4+OyBMZWlmIEpvaGFuc3NvbiA8bGVpZmpAc3VuZXQuc2U8bWFpbHRvOmxlaWZqQHN1bmV0 LnNlPj47IEJpbGwgQ294IDx3YXl3YXJkZ2Vla0Bnb29nbGUuY29tPG1haWx0bzp3YXl3YXJkZ2Vl a0Bnb29nbGUuY29tPj4NClN1YmplY3Q6IFJlOiBbVW5iZWFyYWJsZV0gV2hhdCBHZXRzIFNpZ25l ZCAod2FzOiBEdW1iIGlkZWE6IGFkZCBFZDI1NTE5IHN1cHBvcnQ/KQ0KDQoNCg0KT24gV2VkLCBB dWcgMzEsIDIwMTYgYXQgNDozNyBQTSwgQW5kcmVpIFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9z b2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCg0KPiAg SSB0aGluayB3ZSBzaG91bGQgZ28gYmFjayB0byB0aGUgc2lnbmF0dXJlIGFsZ29yaXRobSBpbmNs dWRpbmcgYSBoYXNoIGFsZ29yaXRobSAoaWYgcmVsZXZhbnQgLSBhbiBFZERTQSBhbGdvcml0aG0g ZG9lc24ndCBuZWVkIGEgaGFzaCBmdW5jdGlvbikuDQpIZXJl4oCZcyBteSBhdHRlbXB0IGF0IGRv aW5nIHRoaXM6IOKAnFdoZW4gYW4gcnNhMjA0OF9wa2NzMS41LCByc2EyMDQ4X3BzcyBvciBlY2Rz YXAyNTYga2V5IGlzIHVzZWQsIHRoZSBzaWduYXR1cmUgaXMgY29tcHV0ZWQgb3ZlciB0aGUgU0hB MjU2IGhhc2ggb2YgdGhlIGJ5dGUgc3RyaW5nIHJlcHJlc2VudGluZyB0aGUgY29uY2F0ZW5hdGlv biBvZuKApuKAnS4NCg0KSSB0aGluayB0aGlzIHdvcmRpbmcgc2hvdWxkIGJlIHNwbGl0IHVwLCBz byBzb21ldGhpbmcgZGVmaW5lcyAidGhlIG1lc3NhZ2UgdG8gYmUgc2lnbmVkIGlzIHRoZSBjb25j YXRlbmF0aW9uIG9mIC4uLiIsIGFuZCB0aGVuIHRoZSBleGlzdGluZyBzaWduYXR1cmUgYWxnb3Jp dGhtcyBjYW4gc3BlY2lmeSB0byBoYXNoIHdpdGggc2hhMjU2IHRoYXQgbWVzc2FnZSAoaXQgY291 bGQgYmUgb25lIHN0YXRlbWVudCwgbGlrZSAiV2hlbiBhbiByc2EyMDQ4X3BrY3MxLjUsIHJzYTIw NDhfcHNzLCBvciBlY2RzYXAyNTYga2V5IGlzIHVzZWQsIHRoZSBzaWduYXR1cmUgaXMgY29tcHV0 ZWQgb3ZlciB0aGUgU0hBMjU2IGhhc2ggb2YgdGhlIG1lc3NhZ2UgdG8gYmUgc2lnbmVkIiwgb3Ig c3BsaXQgaW50byBtdWx0aXBsZSBzdGF0ZW1lbnRzLCBsaWtlIGhvdyB3ZSBkZXNjcmliZSByc2Eg YW5kIHAyNTYgc2VwYXJhdGVseSkuDQo= --_000_CY1PR0301MB08424DF7B90AAF2E47DFBF898CE20CY1PR0301MB0842_ 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 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs c2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXtt c28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFy Z2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVm dDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5QbGVhc2Ug cHJvcG9zZSB0aGUgdGV4dCwgaXQgd2lsbCBoZWxwIGEgbG90LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQnJpYW4gQ2FtcGJlbGwgW21haWx0bzpi Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks IEF1Z3VzdCAzMSwgMjAxNiA1OjE3IFBNPGJyPg0KPGI+VG86PC9iPiBBbmRyZWkgUG9wb3YgJmx0 O0FuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWlrZSBKb25l cyAmbHQ7TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tJmd0OzsgQmlsbCBDb3ggJmx0O3dheXdh cmRnZWVrQGdvb2dsZS5jb20mZ3Q7OyBOaWNrIEhhcnBlciAmbHQ7bmhhcnBlckBnb29nbGUuY29t Jmd0OzsgTGVpZiBKb2hhbnNzb24gJmx0O2xlaWZqQHN1bmV0LnNlJmd0OzsgVG9rYmluZCBXRyAm bHQ7dW5iZWFyYWJsZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtVbmJl YXJhYmxlXSBXaGF0IEdldHMgU2lnbmVkICh3YXM6IER1bWIgaWRlYTogYWRkIEVkMjU1MTkgc3Vw cG9ydD8pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cD5JJ2xsIHByb3Bvc2Ugc29tZSBzcGVjaWZpYyB0ZXh0LCBpZiB0 aGF0J3Mgb2theS4gVG9tb3Jyb3cgdGhvdWdoLiBJJ20gb24gZmFtaWx5IGR1dHkgZm9yIHRoZSBy ZXN0IG9mIHRoZSBldmVuaW5nLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIEF1ZyAzMSwgMjAxNiA1OjU4IFBNLCAmcXVvdDtBbmRyZWkgUG9wb3YmcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSI+QW5kcmVpLlBvcG92QG1p Y3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TdXJl LCB0aGlzIHNvdW5kcyBnb29kIHRvIG1lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE5pY2sgSGFycGVyIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOm5oYXJwZXJAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm5oYXJwZXJAZ29vZ2xlLmNv bTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBBdWd1c3QgMzEsIDIwMTYgNDo1 NCBQTTxicj4NCjxiPlRvOjwvYj4gQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5k cmVpLlBvcG92QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWlj cm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEpvbmVzICZsdDs8YSBocmVm PSJtYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWlj aGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPC9hPiZndDs7IEJyaWFuIENhbXBiZWxsICZsdDs8YSBo cmVmPSJtYWlsdG86YmNhbXBiZWxsQHBpbmdpZGVudGl0eS5jb20iIHRhcmdldD0iX2JsYW5rIj5i Y2FtcGJlbGxAcGluZ2lkZW50aXR5LmNvbTwvYT4mZ3Q7OyBUb2tiaW5kIFdHICZsdDs8YSBocmVm PSJtYWlsdG86dW5iZWFyYWJsZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnVuYmVhcmFibGVA aWV0Zi5vcmc8L2E+Jmd0OzsNCiBMZWlmIEpvaGFuc3NvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxl aWZqQHN1bmV0LnNlIiB0YXJnZXQ9Il9ibGFuayI+bGVpZmpAc3VuZXQuc2U8L2E+Jmd0OzsgQmls bCBDb3ggJmx0OzxhIGhyZWY9Im1haWx0bzp3YXl3YXJkZ2Vla0Bnb29nbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+d2F5d2FyZGdlZWtAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbVW5iZWFyYWJsZV0gV2hhdCBHZXRzIFNpZ25lZCAod2FzOiBEdW1iIGlkZWE6IGFk ZCBFZDI1NTE5IHN1cHBvcnQ/KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24g V2VkLCBBdWcgMzEsIDIwMTYgYXQgNDozNyBQTSwgQW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJt YWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWku UG9wb3ZAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPsOYPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQiPiZuYnNwOyA8L3NwYW4+DQpJIHRoaW5rIHdlIHNob3VsZCBn byBiYWNrIHRvIHRoZSBzaWduYXR1cmUgYWxnb3JpdGhtIGluY2x1ZGluZyBhIGhhc2ggYWxnb3Jp dGhtIChpZiByZWxldmFudCAtIGFuIEVkRFNBIGFsZ29yaXRobSBkb2Vzbid0IG5lZWQgYSBoYXNo IGZ1bmN0aW9uKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5IZXJl4oCZcyBteSBhdHRlbXB0IGF0IGRvaW5nIHRoaXM6IOKAnFdoZW4gYW4g cnNhMjA0OF9wa2NzMS41LCByc2EyMDQ4X3BzcyBvciBlY2RzYXAyNTYga2V5IGlzIHVzZWQsIHRo ZSBzaWduYXR1cmUgaXMNCiBjb21wdXRlZCBvdmVyIHRoZSBTSEEyNTYgaGFzaCBvZiB0aGUgYnl0 ZSBzdHJpbmcgcmVwcmVzZW50aW5nIHRoZSBjb25jYXRlbmF0aW9uIG9m4oCm4oCdLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGluayB0aGlzIHdvcmRpbmcgc2hvdWxkIGJlIHNw bGl0IHVwLCBzbyBzb21ldGhpbmcgZGVmaW5lcyAmcXVvdDt0aGUgbWVzc2FnZSB0byBiZSBzaWdu ZWQgaXMgdGhlIGNvbmNhdGVuYXRpb24gb2YgLi4uJnF1b3Q7LCBhbmQgdGhlbiB0aGUgZXhpc3Rp bmcgc2lnbmF0dXJlIGFsZ29yaXRobXMgY2FuIHNwZWNpZnkgdG8gaGFzaA0KIHdpdGggc2hhMjU2 IHRoYXQgbWVzc2FnZSAoaXQgY291bGQgYmUgb25lIHN0YXRlbWVudCwgbGlrZSAmcXVvdDtXaGVu IGFuIHJzYTIwNDhfcGtjczEuNSwgcnNhMjA0OF9wc3MsIG9yIGVjZHNhcDI1NiBrZXkgaXMgdXNl ZCwgdGhlIHNpZ25hdHVyZSBpcyBjb21wdXRlZCBvdmVyIHRoZSBTSEEyNTYgaGFzaCBvZiB0aGUg bWVzc2FnZSB0byBiZSBzaWduZWQmcXVvdDssIG9yIHNwbGl0IGludG8gbXVsdGlwbGUgc3RhdGVt ZW50cywgbGlrZSBob3cgd2UgZGVzY3JpYmUNCiByc2EgYW5kIHAyNTYgc2VwYXJhdGVseSkuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_CY1PR0301MB08424DF7B90AAF2E47DFBF898CE20CY1PR0301MB0842_-- From nobody Wed Aug 31 23:26:06 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 7D0FE12B05D for ; Wed, 31 Aug 2016 23:26:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 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=-0.548, 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 O1r2WKa1ykj0 for ; Wed, 31 Aug 2016 23:26:02 -0700 (PDT) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 559DA12B032 for ; Wed, 31 Aug 2016 23:26:02 -0700 (PDT) Received: by mail-wm0-x22c.google.com with SMTP id v143so704640wmv.0 for ; Wed, 31 Aug 2016 23:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j/uyx5d5O+dybFJ9beOYW3wD7r3il37QeEigIXkdGl8=; b=XqCLdBPsrkIlD3NJAXQpUtKYLZ9oYiC5sofdxgM8anO5JCaVlamVHXYffUzqhsuowZ EsHenqT0RlaSPzp4Sq8M9cPFkyfScuDhlCtGktoaLy0wKY6tkM/NEI6MzJv5dqHrIqQu V4Pbvx9hEYf1KPEzYWaTFcNmlWg8qqEcP5hXSVhhw5YjQCGQDuXoadI9ofQQvImfSjWY jYU109zdtIouVwPxu+BAWgDxFdymXy16DlYDD8bWzY7fgjQjnhy4471vPOWRoZ3gQQ5H LzeOUJU5gxlFXbbopV/0D3CQ1EozWAg6mljl4ZpdJvCaWknhLSP9LD05g3f2XjJHisrd cj6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j/uyx5d5O+dybFJ9beOYW3wD7r3il37QeEigIXkdGl8=; b=YDeGN/BSsv4lrGh3/ABoWjkmkBHaQLDqsEjWuCcQmmKGtYGxQI/1ZafCG8Px9BRwaR DS1dUOF0+QIiuJz7NUmfyEOuldiyM+Lzxl/fpBsW2RWINDtIrEylEBgpZRBj4XA9ARvT XwRWiFZdFGOtxIPKLj9yx4AtqFnb6DjFjylvmHeT+kDAXIh4493/ZFqpznoqkLFOjDoy ImW/upSMa0qHtBgu3uFcxhjYRllIOaJ95Fq7JfxSfw7Si1V+mwaIstfYCGdf0taJJFcR vNFFM9gH+98Xr6nuAhWfb9wbapnlDwsPCje3qbkObMQDsSUT07vJjXHcUAqeS9Z45qXx T91Q== X-Gm-Message-State: AE9vXwOIfdqZZ3zBrpBCjVE8xtNh4eFa+UaFR0CuWII3U9oFN0dF/aSYTjywUUsEanfItLo9+hOS0OXS+bKvxe1D X-Received: by 10.28.184.19 with SMTP id i19mr24014907wmf.43.1472711160563; Wed, 31 Aug 2016 23:26:00 -0700 (PDT) MIME-Version: 1.0 References: <4F42DDB0-1BBB-43E7-A5AB-7B70C756A3CD@ve7jtb.com> In-Reply-To: <4F42DDB0-1BBB-43E7-A5AB-7B70C756A3CD@ve7jtb.com> From: Dirk Balfanz Date: Thu, 01 Sep 2016 06:25:47 +0000 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a114b8868959225053b6c494d Archived-At: Cc: Andrei Popov , Tokbind WG Subject: Re: [Unbearable] Opaqueness of Token Binding ID 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, 01 Sep 2016 06:26:04 -0000 --001a114b8868959225053b6c494d Content-Type: text/plain; charset=UTF-8 On Wed, Aug 31, 2016 at 3:08 PM John Bradley wrote: > I personally think that for fido treating the token bindingID as opaque is > the correct thing. It will keep the fido clients from breaking when new > token binding algs are added. > But isn't the flip side of that coin "it will keep fido clients from noticing when an attacker does a version rollback attack on them" ... or something like that. Again, I'm not quite sure what the attack would be. > If the server wants to introspect the key for some reason it can do that, > but in general they should be opaque. > Yeah - I think I'm being overly paranoid here. The "opaque" version has literally the same information in it as the JWK version - it's there for clients who care. If everybody else feels comfortable telling consumers of FIDO assertions "just compare the strings, it'll be ok", then I'll shut up. :-) Dirk. > > > John B. > > On Aug 31, 2016, at 2:54 PM, Dirk Balfanz wrote: > > Hi Andrei & the rest of the Unbearables, > > in the FIDO (well, W3C webauthn) discussion the question came up whether > Token Binding IDs should be treated as opaque blobs in other protocols. In > particular, FIDO assertions are (in part) over Token Binding IDs. > > I had originally spec'd this out as including a JWK representation of the > Token Binding key, as in: > > // The FIDO signature is over this: > { > "origin": "www.example.com", > "challenge": "129843adj03948", > "tokbind": { > "kty":"EC", > "crv":"P-256", > "x":"HzQwlfXX7Q4S5MtCRMzPO9tOyWjBqRl4tJ8", > "y":"XVguGFLIZx1fXg375hi4-7-BxhMljw42Ht4" > } > } > > The webauthn participants are pointing out that the latest Token Binding > spec says that other applications should use an opaque representation of > the Token Binding ID, as in: > > // The FIDO signature is over this: > { > "origin": "www.example.com", > "challenge": "129843adj03948", > "tokbind": "KJDSW34AAJSjasAKJsha-ISajj8sJSA..." > } > > where the tokbind value would be the base64-enccoding of the > TokenBindingID, as specified in ietf-tokbind-protocol. > > It seems to me that it is safer to explicitly surface the fact that the > Token Binding ID is a public key, and what kind of key it is, to other > applications, rather than asking them to string-compare two strings whose > semantics they don't understand. > > I can't come up with a particular attack, since the Token Binding ID - > just like the JWK - is an unambiguous representation of they key. > Furthermore, since it is a canonical serialization, string comparison > *should* be ok. > > It seems strange, however, that the application (in this case webauthn) > shouldn't be aware of the precise semantics of the tokbind value in this > dictionary. > > Any thoughts on this? > > Dirk. > > _______________________________________________ > Unbearable mailing list > Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > > --001a114b8868959225053b6c494d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed= , Aug 31, 2016 at 3:08 PM John Bradley <ve7jtb@ve7jtb.com> wrote:
I personally thi= nk that for fido treating the token bindingID as opaque is the correct thin= g.=C2=A0 It will keep the fido clients from breaking when new token binding= algs are added.

But isn't the fl= ip side of that coin "it will keep fido clients from noticing when an = attacker does a version rollback attack on them" ... or something like= that. Again, I'm not quite sure what the attack would be.
= =C2=A0
If the server wants to introspect the key for some reason it can do t= hat, but in general they should be opaque.
<= div>
Yeah - I think I'm being overly paranoid here. The &= quot;opaque" version has literally the same information in it as the J= WK version - it's there for clients who care.=C2=A0

If everybody else feels comfortable telling consumers of FIDO asserti= ons "just compare the strings, it'll be ok", then I'll sh= ut up. :-)

Dirk.
=C2=A0


<= /div>
John B.

<= div class=3D"gmail_msg">
On Aug 31, 2016, at 2:54 PM, D= irk Balfanz <balfanz@google.com> wrote:

Hi Andrei & the rest of the Unbearables,= =C2=A0

in the FIDO (well, W3C webauthn) discussion the question came up= whether Token Binding IDs should be treated as opaque blobs in other proto= cols. In particular, FIDO assertions are (in part) over Token Binding IDs.<= /div>

I had originally spec'd this out as including a JWK represent= ation of the Token Binding key, as in:

// The FIDO signature is over this:
{
=C2=A0 "origin": "www.example.com",
=C2=A0 "challenge": "129843adj03948"= ,
=C2=A0 "tokbind":=C2=A0{
=C2=A0 =C2=A0 "kty":"EC",
=C2=A0 =C2=A0 "crv":"P-256",
= =C2=A0 =C2=A0 "x":"HzQwlfXX7Q4S5MtCRMzPO9tOyWjBqRl4tJ8"= ,
=C2=A0 =C2=A0 "y":"XVguGFLIZx1fXg37= 5hi4-7-BxhMljw42Ht4"
=C2=A0 }
}

=
The webauthn participants are pointing out that th= e latest Token Binding spec says that other applications should use an opaq= ue representation of the Token Binding ID, as in:

// The FIDO signatur= e is over this:
{
=C2=A0 "origin": = "www.example.com",
=C2=A0 "challen= ge": "129843adj03948",
=C2=A0 "t= okbind": "KJDSW34AAJSjasAKJsha-ISajj8sJSA..."
}

where the tokbind value would be the base= 64-enccoding of the TokenBindingID, as specified in=C2=A0ietf-tokbind-proto= col.=C2=A0

It seems to me that it is safer to explicitly surface = the fact that the Token Binding ID is a public key, and what kind of key it= is, to other applications, rather than asking them to string-compare two s= trings whose semantics they don't understand.=C2=A0

I can'= ;t come up with a particular attack, since the Token Binding ID - just like= the JWK - is an unambiguous representation of they key. Furthermore, since= it is a canonical serialization, string comparison *should* be ok.

It seems strange, however, that the application (in this case webauthn) = shouldn't be aware of the precise semantics of the tokbind value in thi= s dictionary.=C2=A0

<= /div>
Any thoughts on this?

Dirk.

_______________________________________________
Unbe= arable mailing list
Unbearable@ietf.org
https://www.ietf.org/mailman/listi= nfo/unbearable
--001a114b8868959225053b6c494d--