From nobody Mon Jun 1 02:14:10 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8743A0E86 for ; Mon, 1 Jun 2020 02:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXrvLAmaWjLS for ; Mon, 1 Jun 2020 02:14:07 -0700 (PDT) Received: from weald2.air.saab.se (weald2.air.saab.se [136.163.212.4]) (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 E02913A0E85 for ; Mon, 1 Jun 2020 02:14:01 -0700 (PDT) Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald2.air.saab.se (8.14.4/8.14.4) with ESMTP id 0519DvJr014665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 1 Jun 2020 11:13:57 +0200 DKIM-Filter: OpenDKIM Filter v2.11.0 weald2.air.saab.se 0519DvJr014665 Received: from corpappl16591.corp.saab.se (corpappl16591.corp.saab.se [10.12.12.97]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id 0519DEQD031576 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Jun 2020 11:13:14 +0200 Received: from corpappl16593.corp.saab.se (10.12.12.125) by corpappl16591.corp.saab.se (10.12.12.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Mon, 1 Jun 2020 11:13:13 +0200 Received: from corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3]) by corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3%4]) with mapi id 15.01.1979.003; Mon, 1 Jun 2020 11:13:14 +0200 From: Seitz Ludwig To: Benjamin Kaduk , "ace@ietf.org" Thread-Topic: [Ace] "default value" for authz-info endpoint Thread-Index: AQHWNtLNChFP5YTUaEKWMUOOhp3jGKjDd1DQ Date: Mon, 1 Jun 2020 09:13:13 +0000 Message-ID: <61220bcd9e72401a9d04c114a3fbf2cf@combitech.se> References: <20200530223602.GF58497@kduck.mit.edu> In-Reply-To: <20200530223602.GF58497@kduck.mit.edu> Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.199] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: 0519DEQD031576 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0, required 5, autolearn=not spam, ALL_TRUSTED -1.00, SURBL_BLOCKED 1.00) X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1591607596.31395@Rw6/PnGQ9ignLuFmNChtQA X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald2.air.saab.se [136.163.212.4]); Mon, 01 Jun 2020 11:13:57 +0200 (CEST) Archived-At: Subject: Re: [Ace] "default value" for authz-info endpoint X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 09:14:10 -0000 Hi Ben, I had a look at the well-known URI list at IANA and it seems that for vanil= la OAuth 2.0 endpoints (authorization, token, introspect) there are no well= -known URI:s either. What exists is an URI used by the authorization server= to self-describe (including attributes giving the values of the endpoint's= URIs). So my interpretation would be that instead of defining a well-known URI for= authz-info, we need to define an attribute that a Resource Server can incl= ude in its well-known information to identify the authz-info endpoint URI i= t is exposing.=20 @Carsten (or other core experts): Would it make sense to define a new attri= bute in the /.well-known/core format for Resource Servers using coap? /Ludwig -----Original Message----- From: Ace On Behalf Of Benjamin Kaduk Sent: den 31 maj 2020 00:36 To: ace@ietf.org Subject: [Ace] "default value" for authz-info endpoint Hi all, I was prompted by the discussion at the interim to look more closely at wha= t we say about the "default name" for endpoint URIs, e.g., the authz-info e= ndpoint. The last paragraph of https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-5.8.1 says: The default name of this endpoint in an url-path is '/authz-info', however implementations are not required to use this name and can define their own instead. I've gotten advice from some URI experts that this doesn't give an easy/dis= coverable path (pun intended) to using a non-default value, which is proble= matic from the perspective of BCP 190 (and we should expect to get discusse= d at IESG evaluation time). This sort of issue goes away if we allocate a = well-known URI for authz-info from https://www.iana.org/assignments/well-kn= own-uris/well-known-uris.xhtml and have that be the default. In particular= , that wouldn't actually stop any deployments from using /authz-info, but i= t does mean they'd have to knowingly "opt in" to doing so. What do people think? Thanks, Ben _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Mon Jun 1 07:51:42 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9965D3A1100 for ; Mon, 1 Jun 2020 07:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H_R7RI3zO5wc for ; Mon, 1 Jun 2020 07:51:37 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D346D3A1087 for ; Mon, 1 Jun 2020 07:51:36 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49bJ5z1M6SzyrK; Mon, 1 Jun 2020 16:51:35 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <61220bcd9e72401a9d04c114a3fbf2cf@combitech.se> Date: Mon, 1 Jun 2020 16:51:34 +0200 Cc: Benjamin Kaduk , "ace@ietf.org" X-Mao-Original-Outgoing-Id: 612715894.660501-e63f8ca32b4260cab695c2c01911c400 Content-Transfer-Encoding: quoted-printable Message-Id: <5A5225C1-412A-4C95-8980-A73125D9025B@tzi.org> References: <20200530223602.GF58497@kduck.mit.edu> <61220bcd9e72401a9d04c114a3fbf2cf@combitech.se> To: Seitz Ludwig X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Ace] "default value" for authz-info endpoint X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 14:51:41 -0000 On 2020-06-01, at 11:13, Seitz Ludwig wrote: >=20 > Hi Ben, >=20 > I had a look at the well-known URI list at IANA and it seems that for = vanilla OAuth 2.0 endpoints (authorization, token, introspect) there are = no well-known URI:s either. What exists is an URI used by the = authorization server to self-describe (including attributes giving the = values of the endpoint's URIs). >=20 > So my interpretation would be that instead of defining a well-known = URI for authz-info, we need to define an attribute that a Resource = Server can include in its well-known information to identify the = authz-info endpoint URI it is exposing.=20 >=20 > @Carsten (or other core experts): Would it make sense to define a new = attribute in the /.well-known/core format for Resource Servers using = coap? It would probably not be an attribute but a link relation and/or a = resource type. I would expect the authz-info resource would usually be the same for an = entire server? This might argue for the =E2=80=9Chosts=E2=80=9D link relationship and = an rt=3D registration. Registry: Resource Type (rt=3D) Link Target Attribute Values in Constrained RESTful Environments (CoRE) Parameters If the authz-info is often different for each resource, a link from the = resource to the authz-info with an appropriate link relation would work = best. Registry: Link Relations Gr=C3=BC=C3=9Fe, Carsten >=20 > /Ludwig >=20 >=20 > -----Original Message----- > From: Ace On Behalf Of Benjamin Kaduk > Sent: den 31 maj 2020 00:36 > To: ace@ietf.org > Subject: [Ace] "default value" for authz-info endpoint >=20 > Hi all, >=20 > I was prompted by the discussion at the interim to look more closely = at what we say about the "default name" for endpoint URIs, e.g., the = authz-info endpoint. The last paragraph of > = https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-5.8.1 > says: >=20 > The default name of this endpoint in an url-path is '/authz-info', > however implementations are not required to use this name and can > define their own instead. >=20 > I've gotten advice from some URI experts that this doesn't give an = easy/discoverable path (pun intended) to using a non-default value, = which is problematic from the perspective of BCP 190 (and we should = expect to get discussed at IESG evaluation time). This sort of issue = goes away if we allocate a well-known URI for authz-info from = https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml = and have that be the default. In particular, that wouldn't actually = stop any deployments from using /authz-info, but it does mean they'd = have to knowingly "opt in" to doing so. >=20 > What do people think? >=20 > Thanks, >=20 > Ben >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon Jun 1 15:39:15 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E623A1616 for ; Mon, 1 Jun 2020 15:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEdFZgAgtm-J for ; Mon, 1 Jun 2020 15:39:09 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829423A1617 for ; Mon, 1 Jun 2020 15:39:09 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 1 Jun 2020 15:38:45 -0700 From: Jim Schaad To: 'Carsten Bormann' , 'Seitz Ludwig' CC: 'Benjamin Kaduk' , References: <20200530223602.GF58497@kduck.mit.edu> <61220bcd9e72401a9d04c114a3fbf2cf@combitech.se> <5A5225C1-412A-4C95-8980-A73125D9025B@tzi.org> In-Reply-To: <5A5225C1-412A-4C95-8980-A73125D9025B@tzi.org> Date: Mon, 1 Jun 2020 15:38:42 -0700 Message-ID: <000b01d63865$6903fe10$3b0bfa30$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQF9efR0SM552Q3cNW0LCim6tGIVRQMQOHIUAVjDSfupUo62YA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] "default value" for authz-info endpoint X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 22:39:12 -0000 We should make sure to keep draft-tiloca-core-oscore-directory in mind = for this. It has a relation link defined for the Authorization server. Jim -----Original Message----- From: Ace On Behalf Of Carsten Bormann Sent: Monday, June 1, 2020 7:52 AM To: Seitz Ludwig Cc: Benjamin Kaduk ; ace@ietf.org Subject: Re: [Ace] "default value" for authz-info endpoint On 2020-06-01, at 11:13, Seitz Ludwig wrote: >=20 > Hi Ben, >=20 > I had a look at the well-known URI list at IANA and it seems that for = vanilla OAuth 2.0 endpoints (authorization, token, introspect) there are = no well-known URI:s either. What exists is an URI used by the = authorization server to self-describe (including attributes giving the = values of the endpoint's URIs). >=20 > So my interpretation would be that instead of defining a well-known = URI for authz-info, we need to define an attribute that a Resource = Server can include in its well-known information to identify the = authz-info endpoint URI it is exposing.=20 >=20 > @Carsten (or other core experts): Would it make sense to define a new = attribute in the /.well-known/core format for Resource Servers using = coap? It would probably not be an attribute but a link relation and/or a = resource type. I would expect the authz-info resource would usually be the same for an = entire server? This might argue for the =E2=80=9Chosts=E2=80=9D link relationship and = an rt=3D registration. Registry: Resource Type (rt=3D) Link Target Attribute Values in Constrained = RESTful Environments (CoRE) Parameters If the authz-info is often different for each resource, a link from the = resource to the authz-info with an appropriate link relation would work = best. Registry: Link Relations Gr=C3=BC=C3=9Fe, Carsten >=20 > /Ludwig >=20 >=20 > -----Original Message----- > From: Ace On Behalf Of Benjamin Kaduk > Sent: den 31 maj 2020 00:36 > To: ace@ietf.org > Subject: [Ace] "default value" for authz-info endpoint >=20 > Hi all, >=20 > I was prompted by the discussion at the interim to look more closely=20 > at what we say about the "default name" for endpoint URIs, e.g., the=20 > authz-info endpoint. The last paragraph of > https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-5.8. > 1 > says: >=20 > The default name of this endpoint in an url-path is '/authz-info', > however implementations are not required to use this name and can > define their own instead. >=20 > I've gotten advice from some URI experts that this doesn't give an = easy/discoverable path (pun intended) to using a non-default value, = which is problematic from the perspective of BCP 190 (and we should = expect to get discussed at IESG evaluation time). This sort of issue = goes away if we allocate a well-known URI for authz-info from = https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml = and have that be the default. In particular, that wouldn't actually = stop any deployments from using /authz-info, but it does mean they'd = have to knowingly "opt in" to doing so. >=20 > What do people think? >=20 > Thanks, >=20 > Ben >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Mon Jun 1 16:59:01 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0F0F3A16E0 for ; Mon, 1 Jun 2020 16:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sbJkPQneCAIr for ; Mon, 1 Jun 2020 16:58:57 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 416A53A16DB for ; Mon, 1 Jun 2020 16:58:56 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 051NwiOp009264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 1 Jun 2020 19:58:47 -0400 Date: Mon, 1 Jun 2020 16:58:43 -0700 From: Benjamin Kaduk To: Seitz Ludwig Cc: "ace@ietf.org" Message-ID: <20200601235843.GH58497@kduck.mit.edu> References: <20200530223602.GF58497@kduck.mit.edu> <61220bcd9e72401a9d04c114a3fbf2cf@combitech.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61220bcd9e72401a9d04c114a3fbf2cf@combitech.se> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] "default value" for authz-info endpoint X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 23:58:59 -0000 Hi Ludwig, I'm confident that a well-known URI (or link relation) for discovery of RS configuration/parameters would address the BCP 190 concerns. What we need is an obvious path to not stomp on the server owner's namespace, and whether we do that by letting the server tell us what what path to use or by constraining ourself to a well-specified cordoned-off corner reserved for our use is up to us. Thanks for all the ideas and follow-up discussion! -Ben On Mon, Jun 01, 2020 at 09:13:13AM +0000, Seitz Ludwig wrote: > Hi Ben, > > I had a look at the well-known URI list at IANA and it seems that for vanilla OAuth 2.0 endpoints (authorization, token, introspect) there are no well-known URI:s either. What exists is an URI used by the authorization server to self-describe (including attributes giving the values of the endpoint's URIs). > > So my interpretation would be that instead of defining a well-known URI for authz-info, we need to define an attribute that a Resource Server can include in its well-known information to identify the authz-info endpoint URI it is exposing. > > @Carsten (or other core experts): Would it make sense to define a new attribute in the /.well-known/core format for Resource Servers using coap? > > /Ludwig > > > -----Original Message----- > From: Ace On Behalf Of Benjamin Kaduk > Sent: den 31 maj 2020 00:36 > To: ace@ietf.org > Subject: [Ace] "default value" for authz-info endpoint > > Hi all, > > I was prompted by the discussion at the interim to look more closely at what we say about the "default name" for endpoint URIs, e.g., the authz-info endpoint. The last paragraph of > https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-5.8.1 > says: > > The default name of this endpoint in an url-path is '/authz-info', > however implementations are not required to use this name and can > define their own instead. > > I've gotten advice from some URI experts that this doesn't give an easy/discoverable path (pun intended) to using a non-default value, which is problematic from the perspective of BCP 190 (and we should expect to get discussed at IESG evaluation time). This sort of issue goes away if we allocate a well-known URI for authz-info from https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml and have that be the default. In particular, that wouldn't actually stop any deployments from using /authz-info, but it does mean they'd have to knowingly "opt in" to doing so. > > What do people think? > > Thanks, > > Ben > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon Jun 1 22:19:31 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1E013A07AA for ; Mon, 1 Jun 2020 22:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=primekey.com header.b=FomQBA/W; dkim=pass (1024-bit key) header.d=primekey.com header.b=FomQBA/W Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj-fnIxa_T1r for ; Mon, 1 Jun 2020 22:19:26 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9963A07A9 for ; Mon, 1 Jun 2020 22:19:24 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id 303FE6AA0098 for ; Tue, 2 Jun 2020 07:19:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1591075146; bh=OKvjW3BkiklLpvqpyblE5ihpx6kW064U1G/+RkaHskg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=FomQBA/WnzXiGdbDLCffx7Bgt9dd1452WRToHh2Cy1LayfAb1OV9chtSY0Czs09v2 suXpMmihOu3sSujDzH+nV8Va+8+P05jGEIxj8YtUplISmQWZ2P3gNh+VHJpyVHivRk bv98L8bBuLMMIAVCdf/asT1gNZkv6ph6i2WRFiJk= Received: from [192.168.1.113] (unknown [85.24.187.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 01A176AA0093 for ; Tue, 2 Jun 2020 07:19:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1591075146; bh=OKvjW3BkiklLpvqpyblE5ihpx6kW064U1G/+RkaHskg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=FomQBA/WnzXiGdbDLCffx7Bgt9dd1452WRToHh2Cy1LayfAb1OV9chtSY0Czs09v2 suXpMmihOu3sSujDzH+nV8Va+8+P05jGEIxj8YtUplISmQWZ2P3gNh+VHJpyVHivRk bv98L8bBuLMMIAVCdf/asT1gNZkv6ph6i2WRFiJk= To: ace@ietf.org References: <20200530223602.GF58497@kduck.mit.edu> <61220bcd9e72401a9d04c114a3fbf2cf@combitech.se> <20200601235843.GH58497@kduck.mit.edu> From: Tomas Gustavsson Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= xsBNBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAHNMFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPsLA dwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5zsBNBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAHCwF8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: Date: Tue, 2 Jun 2020 07:19:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200601235843.GH58497@kduck.mit.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Ace] "default value" for authz-info endpoint X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 05:19:29 -0000 Hi, In most cases where I've been involved with implementing a single RFC defined .well-known URL for actually servicing all end points, it ends up being one .well-known for default configuration, and multiple other (not .well-known) URLs in order to handle other configurations in multi-tennant scenarios. I hope whatever .well-known scheme is selected will handle multi-tennancy, where thare can be differently configured service end points servicing from the same host/ip. I.e. can one host server multiple authz-info? (does that make sense?) Regards, Tomas On 2020-06-02 01:58, Benjamin Kaduk wrote: > Hi Ludwig, > > I'm confident that a well-known URI (or link relation) for discovery of RS > configuration/parameters would address the BCP 190 concerns. What we need > is an obvious path to not stomp on the server owner's namespace, and > whether we do that by letting the server tell us what what path to use or > by constraining ourself to a well-specified cordoned-off corner reserved > for our use is up to us. > > Thanks for all the ideas and follow-up discussion! > > -Ben > > On Mon, Jun 01, 2020 at 09:13:13AM +0000, Seitz Ludwig wrote: >> Hi Ben, >> >> I had a look at the well-known URI list at IANA and it seems that for vanilla OAuth 2.0 endpoints (authorization, token, introspect) there are no well-known URI:s either. What exists is an URI used by the authorization server to self-describe (including attributes giving the values of the endpoint's URIs). >> >> So my interpretation would be that instead of defining a well-known URI for authz-info, we need to define an attribute that a Resource Server can include in its well-known information to identify the authz-info endpoint URI it is exposing. >> >> @Carsten (or other core experts): Would it make sense to define a new attribute in the /.well-known/core format for Resource Servers using coap? >> >> /Ludwig >> >> >> -----Original Message----- >> From: Ace On Behalf Of Benjamin Kaduk >> Sent: den 31 maj 2020 00:36 >> To: ace@ietf.org >> Subject: [Ace] "default value" for authz-info endpoint >> >> Hi all, >> >> I was prompted by the discussion at the interim to look more closely at what we say about the "default name" for endpoint URIs, e.g., the authz-info endpoint. The last paragraph of >> https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-5.8.1 >> says: >> >> The default name of this endpoint in an url-path is '/authz-info', >> however implementations are not required to use this name and can >> define their own instead. >> >> I've gotten advice from some URI experts that this doesn't give an easy/discoverable path (pun intended) to using a non-default value, which is problematic from the perspective of BCP 190 (and we should expect to get discussed at IESG evaluation time). This sort of issue goes away if we allocate a well-known URI for authz-info from https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml and have that be the default. In particular, that wouldn't actually stop any deployments from using /authz-info, but it does mean they'd have to knowingly "opt in" to doing so. >> >> What do people think? >> >> Thanks, >> >> Ben >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > From nobody Tue Jun 2 03:09:23 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7363A07B1 for ; Tue, 2 Jun 2020 03:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6cjQAgObiRAH for ; Tue, 2 Jun 2020 03:09:19 -0700 (PDT) Received: from weald2.air.saab.se (weald2.air.saab.se [136.163.212.4]) (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 A16AA3A07B9 for ; Tue, 2 Jun 2020 03:09:17 -0700 (PDT) Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald2.air.saab.se (8.14.4/8.14.4) with ESMTP id 052A9EsC019798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 2 Jun 2020 12:09:15 +0200 DKIM-Filter: OpenDKIM Filter v2.11.0 weald2.air.saab.se 052A9EsC019798 Received: from corpappl16256.corp.saab.se (corpappl16256.corp.saab.se [10.12.13.175]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id 052A8xRf019439 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Jun 2020 12:08:59 +0200 Received: from corpappl16593.corp.saab.se (10.12.12.125) by corpappl16256.corp.saab.se (10.12.13.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 2 Jun 2020 12:08:59 +0200 Received: from corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3]) by corpappl16593.corp.saab.se ([fe80::b4c9:ca69:a80d:fa3%4]) with mapi id 15.01.1979.003; Tue, 2 Jun 2020 12:08:59 +0200 From: Seitz Ludwig To: Tomas Gustavsson , "ace@ietf.org" Thread-Topic: [Ace] "default value" for authz-info endpoint Thread-Index: AQHWNtLNChFP5YTUaEKWMUOOhp3jGKjDd1DQgADaq4CAAFmXAIAAbYqQ Date: Tue, 2 Jun 2020 10:08:58 +0000 Message-ID: <4e5ef6ea5509402c85b63a85ad619ffb@combitech.se> References: <20200530223602.GF58497@kduck.mit.edu> <61220bcd9e72401a9d04c114a3fbf2cf@combitech.se> <20200601235843.GH58497@kduck.mit.edu> In-Reply-To: Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: 052A8xRf019439 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.198, required 5, ALL_TRUSTED -1.00, KAM_ASCII_DIVIDERS 0.80, SURBL_BLOCKED 0.00, URIBL_BLOCKED 0.00) X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1591697340.32673@WjtVJpgiu6w2pF7QfUDb4g X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald2.air.saab.se [136.163.212.4]); Tue, 02 Jun 2020 12:09:15 +0200 (CEST) Archived-At: Subject: Re: [Ace] "default value" for authz-info endpoint X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2020 10:09:22 -0000 Hi Tomas, Thank you for your comment.=20 Some observations and questions:=20 I have a hard time seeing a reasonable use case where a resource server (RS= ) would need several authz-info endpoints, one could however imagine a use = case with a powerful server hosting several virtual resource servers (RS) u= nder the same IP address and thus several different authz-info endpoints (o= ne for each RS), but this does not sound like the typical Constrained Envir= onment scenario to me.=20 In order to better understand what this is about: If you have such a multi-= tenant situation with a .well-known for a default configuration, how would= clients discover the non-default configurations?=20 Also if a RS were to use the default URI (which is /authz-info), = why would it need to announce this in a .well-known? I would assume that th= is is only necessary if a non-default URI is used. @ACE: This is far away from my area of expertise and at this point I cannot= devote the necessary time to "read up" on this. Can someone help us find a= good solution that that we can move draft-ietf-oauth-authz forward? /Ludwig -----Original Message----- From: Ace On Behalf Of Tomas Gustavsson Sent: den 2 juni 2020 07:19 To: ace@ietf.org Subject: Re: [Ace] "default value" for authz-info endpoint Hi, In most cases where I've been involved with implementing a single RFC defin= ed .well-known URL for actually servicing all end points, it ends up being = one .well-known for default configuration, and multiple other (not .well-kn= own) URLs in order to handle other configurations in multi-tennant scenario= s. I hope whatever .well-known scheme is selected will handle multi-tennancy, = where thare can be differently configured service end points servicing from= the same host/ip. I.e. can one host server multiple authz-info? (does that make sense?) Regards, Tomas On 2020-06-02 01:58, Benjamin Kaduk wrote: > Hi Ludwig, >=20 > I'm confident that a well-known URI (or link relation) for discovery=20 > of RS configuration/parameters would address the BCP 190 concerns. =20 > What we need is an obvious path to not stomp on the server owner's=20 > namespace, and whether we do that by letting the server tell us what=20 > what path to use or by constraining ourself to a well-specified=20 > cordoned-off corner reserved for our use is up to us. >=20 > Thanks for all the ideas and follow-up discussion! >=20 > -Ben >=20 > On Mon, Jun 01, 2020 at 09:13:13AM +0000, Seitz Ludwig wrote: >> Hi Ben, >> >> I had a look at the well-known URI list at IANA and it seems that for va= nilla OAuth 2.0 endpoints (authorization, token, introspect) there are no w= ell-known URI:s either. What exists is an URI used by the authorization ser= ver to self-describe (including attributes giving the values of the endpoin= t's URIs). >> >> So my interpretation would be that instead of defining a well-known URI = for authz-info, we need to define an attribute that a Resource Server can i= nclude in its well-known information to identify the authz-info endpoint UR= I it is exposing.=20 >> >> @Carsten (or other core experts): Would it make sense to define a new at= tribute in the /.well-known/core format for Resource Servers using coap? >> >> /Ludwig >> >> >> -----Original Message----- >> From: Ace On Behalf Of Benjamin Kaduk >> Sent: den 31 maj 2020 00:36 >> To: ace@ietf.org >> Subject: [Ace] "default value" for authz-info endpoint >> >> Hi all, >> >> I was prompted by the discussion at the interim to look more closely=20 >> at what we say about the "default name" for endpoint URIs, e.g., the=20 >> authz-info endpoint. The last paragraph of >> https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-33#section-5.8 >> .1 >> says: >> >> The default name of this endpoint in an url-path is '/authz-info', >> however implementations are not required to use this name and can >> define their own instead. >> >> I've gotten advice from some URI experts that this doesn't give an easy/= discoverable path (pun intended) to using a non-default value, which is pro= blematic from the perspective of BCP 190 (and we should expect to get discu= ssed at IESG evaluation time). This sort of issue goes away if we allocate= a well-known URI for authz-info from https://www.iana.org/assignments/well= -known-uris/well-known-uris.xhtml and have that be the default. In particu= lar, that wouldn't actually stop any deployments from using /authz-info, bu= t it does mean they'd have to knowingly "opt in" to doing so. >> >> What do people think? >> >> Thanks, >> >> Ben >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Sun Jun 7 09:22:23 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E26B3A09B7; Sun, 7 Jun 2020 09:22:21 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ps-8xDwXRc2k; Sun, 7 Jun 2020 09:22:19 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A91273A09B5; Sun, 7 Jun 2020 09:22:19 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 7 Jun 2020 09:22:13 -0700 From: Jim Schaad To: CC: Date: Sun, 7 Jun 2020 09:22:08 -0700 Message-ID: <005b01d63ce7$cbedce80$63c96b80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdY8RN4g59y7y0TwSfGpg4nfNi820w== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Review draft-tiloca-ace-oscore-gm-admin-01 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2020 16:22:22 -0000 * Does 'joining_path' contain the path or the full URI to the joining resource. Is it possible for the Group Manager Administration to be on a different server (or via a different address) from the Group Manager itself? Path tends to me to say only path. * Section 2.3.2.1 - I think it makes more sense to make all of the defaults to the groupcomm draft from ACE for OSCORE. Since this is for managing those types of groups, it should be that document which gets to set the defaults. If it wants to refer back to the same documents that is fine, but it should be that the defaults can change based on changing that document. * Section 2.3.2.2 - I think there may be a difference between an empty string and an absent string for group_title. Just verifying that what you want is an empty string. * Section 2.4.1 - I am not sure why this is a subsection of 2.4. * Section 2.5.3 - What does "or is not fine to consider for tis OSCORE group" in bullet #4 list #2? Is this implying some type of judgement on the part of the AS based on parameters in the group definition or the expected usage of the group? * Section 2.5.3 - I think it might make sense to return at least some of the information in the return value of the POST such as the "joining_path" and the "as_uri" because just the management path is not sufficient to be able to start populating the RD. * Section 2.5.3 - An interesting question - Should it be allowable for the name to be different between the management and the group key nodes? I would like to see some type of discussion at least on the mailing list. Doing the search on the join path would result in the same answer and little additional penalty since I doubt that GM Admin clients are going to be constrained. * Section 2.5.5 - The second paragraph makes zero sense to me. The third paragraph should just be talking about the update message and not mixing the create and update messages together. * Section 2.5.5.2 - I have read this section twice and I still do not think I understand what is going on here. How much of this is needed and how much is extraneous? Is there some simplification that can be used to make this easier? Jim s/fowllowing/following/ From nobody Mon Jun 8 15:49:35 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983713A0887 for ; Mon, 8 Jun 2020 15:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbkwVdnSHuwK for ; Mon, 8 Jun 2020 15:49:32 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C23913A0885 for ; Mon, 8 Jun 2020 15:49:31 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Jun 2020 15:49:25 -0700 From: Jim Schaad To: References: In-Reply-To: Date: Mon, 8 Jun 2020 15:49:23 -0700 Message-ID: <004701d63de7$0f7a47a0$2e6ed6e0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdY9t1uc/2ioWMVyTwiC/DibhirO0gAL6h8Q Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] FW: Review draft-ietf-ace-mqtt-tls-profile-05 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 22:49:34 -0000 Let's see if I can get the mailing list right this time -----Original Message----- From: Jim Schaad Sent: Monday, June 8, 2020 3:02 PM To: 'draft-ietf-ace-mqtt-tls-profile@ietf.org' Cc: 'cose@ietf.org' Subject: Review draft-ietf-ace-mqtt-tls-profile-05 * Style Issue. "Abbreviations should be expanded in document title and upon first use in the document. Full expansion of the text should be followed by the abbreviation in parentheses." Some items such as TLS are considered to be known by everybody and thus do not need to be expanded. https://www.rfc-editor.org/materials/abbrev.expansion.txt contains both "known" and "unknown" abbreviations. (Yes this means you are going to have a really long title.) (I might argue that OASIS should be listed as well known.) * Section 1 - para 1 - Sentence two has a plurality mismatch between client and server. I think in this case server (and broker) should be pluralized. * Section 1.3 - Broker - s/publishes/publish/ The set of pluralized items seems to be too large by one. * Section 1.3 - I think we ought to define Session given that we no longer require that Clean Session be used. * Section 1.3 - I do not believe that CONNACK is always the first packet from the broker to a client. An AUTH message may be the first one. * Section 2.1 - para 3 s/the public key used by the RS/the public key to be used by the RS/ * Section 2.1 - I think (but am not sure) that we may need to do some registrations around the use of thumbprints in a confirmation claim. If I forget, please remind me to track this down. * Section 2.2.2 - para #1 - s/using client authentication/using server authentication/ If we are doing MQTT as the default then the server not the client is authenticated here. You may not want to have lost the potentially here. * Section 2.2.3 - I think that the client state MUST include the token and either the same token is supplied or a token with the same key is supplied in order to match with an existing state. * Section 6.2 - I think it makes sense to put in a note that between the fact that the server will disconnect on almost any error and is not required to keep session state between connections, clients need to make a greater effort to ensure that tokens remain valid and they do not attempt to publish to topics that they do not have permissions for. * Section 8 - The storage of tokens long term can be restricted to only current valid ones if an immediate validation of the token is done. This means that the RS spends time doing the validation, but does not need to consume memory. This is looking really good. I think we have only two technical issues open at this point. The question of registrations for hash identifications in confirmation claims and if changes to the default scope structure are to be done. Jim From nobody Mon Jun 15 07:13:31 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CECB3A0DA4 for ; Mon, 15 Jun 2020 07:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 sFq2ynx8q5ku for ; Mon, 15 Jun 2020 07:13:23 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150089.outbound.protection.outlook.com [40.107.15.89]) (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 BB29D3A0D54 for ; Mon, 15 Jun 2020 07:13:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EKQLcO/pMv3ybH+5xgwikrjOuzyb18w82JCn2Qh2HFTUFwtCLJs7DHBAHeBhXsgiywbBkftt/SrDmUW5oZMe79f3e035/9hyqYcLc5GJgjy2faxWBI8J83aMgro56jKbAwldOhz3a3v240KMQwnt5bIifOh1QpzY8cNiEpnZfpb4odHdE4c+fw8YVYs2X89tZbsvVjW9xQGdJfi9kNQXDq/l8lByoNYeI4ifeWpnb1fcTdxAcxRQHGjgPJ37kYEh1OCVx6SRyl+7+rtNEnr9n/KuUDiBIeHZZ5UZqTYZu2iVCtqQBxSNFNMHmhDRsxHZ04nES0FPDinHC1QazfVE3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t5XLrOWOq7Zcbbo43j4jlakoQ/6xLyj6e3uyAe3HL58=; b=e1C3YtLmSTDDcwCgebP9sXa5a6bqSJqP0q3cxifDEJiFJUvg+zRkezmMC8gTTESYUrqSMSY5CMWcdaONHLLO/maC2JE0UR3Uqrjf8IbEr6Au0KiKtHxp/UPTah9PC+587/JFLyKP7w8T6Axp5xBpxpbLJLTjlTSxEyxgEPNGY4Cmm3hbR6Y0LO5hJZt39z39Ftw+ddNqtT2xNpQvgZeg23DGFiKpnSmXqz0cHniBpjl2S1t4ptxH3lGWizviLNs4oi2EBQUxR7Tn/fFv3ZkXdUagQK+QKbHOZ8NnE2QKsY+m8GBQp/CswAyY8QZkLh94SGuv9mfwJEJFU5VRgVRRPQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t5XLrOWOq7Zcbbo43j4jlakoQ/6xLyj6e3uyAe3HL58=; b=pDcAibb2aUTejccq/OxUck6kn6OXZpGQ1Eyqxciwh6mS8f+gOFYdrEn9VlMPLGO3Noziib2Cn3wHet+w1vwoE9cmTttGB1prayjM3r8OveQDI20mHFBFr2AJzdOnc90azfP+vqh9b7kH1Lj+3VgFXxMFqH53+dj8YBkbn4eaYVs= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR07MB3386.eurprd07.prod.outlook.com (2603:10a6:7:2d::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.10; Mon, 15 Jun 2020 14:13:17 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3109.018; Mon, 15 Jun 2020 14:13:17 +0000 From: Francesca Palombini To: Daniel Migault , Ace Wg Thread-Topic: [Ace] questions on draft-ietf-ace-key-groupcomm-06 Thread-Index: AQHWL6CfguJRphbTsUa//m3vLkdsUqjaAH8A Date: Mon, 15 Jun 2020 14:13:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 08f3139c-406c-4eff-7d36-08d811363fe7 x-ms-traffictypediagnostic: HE1PR07MB3386: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04359FAD81 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: m9ym5PXwxFmVb2Pwo11LDEJ38diSLy78urKJTUNoFMMMNZawrOb977lUBbOiH7R5sUHo96io8yeLAa4xwho41DUlYI7z6HxNPb0gzesARKROyiYURAwt0j/Qpucg0xPUkozjupVCf0GUCAyWLY0JawHlxOI700fTQnHDqrTrVlV+1DZmkDGskxfxXnI+J0jlYtad8ilzcoKB9Un8KmSaZzs6tzUDroF3k+n81YO9oHZehRIF773DbKChuIybTQD6Wgl36uTnqXWnj9tMqbDEa5FzbNmYjVO2hCiBr0fxGNROGceAVM7wRH48CUv2iF5d8gD+Dsfd5Wz8dFXvlT62XSe/mp3n8Ze7z3Ddmit8gzoOb+MvTWMCswYhKkihunT69FiOehjfy1MwJqwRl2qsQQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(346002)(366004)(39860400002)(396003)(64756008)(110136005)(86362001)(6486002)(478600001)(2616005)(44832011)(316002)(83380400001)(966005)(33656002)(71200400001)(66476007)(2906002)(6512007)(66556008)(66446008)(8676002)(66946007)(30864003)(6506007)(76116006)(36756003)(186003)(66574014)(26005)(9326002)(166002)(8936002)(5660300002)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: LNOEnTkjIvWu3Y+V5EZsxnO9svhO7CGVl2EFPBGUPeCg/d2b/hYNCtkOEDKITFR/l9ASIM8mQ/Q7CJbBBoH+aOIoBbE9rWSROCNbPpAlVBP2VeW0oxcmi6Kode/nBvWhqcRasgHQwiYmgTktCt7Mt6YjGtZBjGqA56vnRx13K5SPCMiXRFU6jHyxANQSKV4iOUdspF+y4OiaZw7bcuuR9/qKALQ9wXi9DQnTJmKerIiVxV4X3zXJFDKac42POz6/ny69SzwUX/+jLgCplSi5C+jz3kbqKr3HAXlzmY1S5IKEVm9mqsQe31gWEnTco+wrrtewX++fRcMBuDKerS8lRr0MskGZAD74aM9d7i3FhREyI42J8nbNZBa552z62WaVYjV6I5f4RBt+UaXnmLjsPK7Xh/+TRJ4kUt9a3LtcaxLjowaNEh63lkQ2SciV9cgLNDyXHYoZBAr/esJzxOgKiX3+0xVPokPRQvrhi9s4aMuyH2MemdeNblnc4ly039lD x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DA7A15C0357E40DCBCA9D7EEEE18DA73ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 08f3139c-406c-4eff-7d36-08d811363fe7 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 14:13:17.0027 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mHyUJYResPVuvE685/QFZs0Kh57D2fnFpe6lOdjbgbPTzNeNA7ekouqlJf4v2RivRL2TSWEAgl7cwaq6heI8sXP8Ug0+whypipeg99s8wj1PkImpzsV3U0s5g+sbGq7x X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3386 Archived-At: Subject: Re: [Ace] questions on draft-ietf-ace-key-groupcomm-06 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 14:13:29 -0000 --_000_DA7A15C0357E40DCBCA9D7EEEE18DA73ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRGFuaWVsLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHJldmlldyEgV2UgaGF2 ZSBpbmNsdWRlZCB5b3VyIGNvbW1lbnRzIGluIHRoZSBsYXRlc3QgcHVsbCByZXF1ZXN0IG9uIGdp dGh1YiAoYWN0aXZlIGVkaXRvcuKAmXMgdmVyc2lvbik6IGh0dHBzOi8vZ2l0aHViLmNvbS9hY2Ut d2cvYWNlLWtleS1ncm91cGNvbW0vdHJlZS92LTA3DQoNCldlIGFsc28gaGF2ZSBzb21lIGNvbW1l bnRzIGlubGluZS4NCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCg0KDQpIaSwNCg0KUGxlYXNlIGZp bmQgc29tZSBxdWVzdGlvbnMgLyBjb21tZW50cyByZWdhcmRpbmcgdGhlIGRyYWZ0IGRyYWZ0LWll dGYtYWNlLWtleS1ncm91cGNvbW0tMDYuIEkgc3VzcGVjdCB0aGF0IG1vc3Qgb2YgdGhlIHF1ZXN0 aW9ucyBhcmUgY2xhcmlmaWNhdGlvbnMgZm9yIG1lIHRvIGJldHRlciB1bmRlcnN0YW5kIHRoZSBj b250ZXh0Lg0KDQpZb3VycywNCkRhbmllbA0KDQoNCiAgICAgICAgICAgS2V5IFByb3Zpc2lvbmlu ZyBmb3IgR3JvdXAgQ29tbXVuaWNhdGlvbiB1c2luZyBBQ0UNCiAgICAgICAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi1hY2Uta2V5LWdyb3VwY29tbS0wNg0KWy4uLl0NCg0KMi4gIE92ZXJ2aWV3DQoN CiAgICAgICArLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSsNCiAg ICAgICB8ICAgICBBUyAgICAgfCAgICAgICAgICAgICAgICAgIHwgICAgS0RDICAgIHwNCiAgICAg ICB8ICAgICAgICAgICAgfCAgICAgICAgLi0tLS0tLS0tPnwgICAgICAgICAgIHwNCiAgICAgICAr LS0tLS0tLS0tLS0tKyAgICAgICAvICAgICAgICAgICstLS0tLS0tLS0tLSsNCiAgICAgICAgICAg ICBeICAgICAgICAgICAgIC8NCiAgICAgICAgICAgICB8ICAgICAgICAgICAgLw0KICAgICAgICAg ICAgIHYgICAgICAgICAgIC8gICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0r DQogICAgICAgKy0tLS0tLS0tLS0tLSsgICAvICAgICAgKy0tLS0tLS0tLS0tLSsgICAgICAgIHwr LS0tLS0tLS0tLS0rDQogICAgICAgfCAgIENsaWVudCAgIHw8LScgICAgICAgfCBEaXNwYXRjaGVy IHwgICAgICAgIHx8Ky0tLS0tLS0tLS0tKw0KICAgICAgIHwgICAgICAgICAgICB8PC0tLS0tLS0t PnwgICAgKFJTKSAgICB8PC0tLS0tLS0+fHwgICBHcm91cCAgIHwNCiAgICAgICArLS0tLS0tLS0t LS0tKyAgICAgICAgICArLS0tLS0tLS0tLS0tKyAgICAgICAgICt8ICBtZW1iZXJzICB8DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0t LS0tLS0tKw0KDQogICAgICAgICAgICAgICAgICBGaWd1cmUgMTogS2V5IERpc3RyaWJ1dGlvbiBQ YXJ0aWNpcGFudHMNCg0KICAgVGhlIGZvbGxvd2luZyBwYXJ0aWNpcGFudHMgKHNlZSBGaWd1cmUg MSkgdGFrZSBwYXJ0IGluIHRoZQ0KICAgYXV0aG9yaXphdGlvbiBhbmQga2V5IGRpc3RyaWJ1dGlv bi4NCg0KICAgKiAgQ2xpZW50IChDKTogbm9kZSB0aGF0IHdhbnRzIHRvIGpvaW4gdGhlIGdyb3Vw IGNvbW11bmljYXRpb24uICBJdA0KICAgICAgY2FuIHJlcXVlc3Qgd3JpdGUgYW5kL29yIHJlYWQg cmlnaHRzLg0KDQogICAqICBBdXRob3JpemF0aW9uIFNlcnZlciAoQVMpOiBzYW1lIGFzIEFTIGlu IHRoZSBBQ0UgRnJhbWV3b3JrOyBpdA0KICAgICAgZW5mb3JjZXMgYWNjZXNzIHBvbGljaWVzLCBh bmQga25vd3MgaWYgYSBub2RlIGlzIGFsbG93ZWQgdG8gam9pbiBhDQogICAgICBnaXZlbiBncm91 cCB3aXRoIHdyaXRlIGFuZC9vciByZWFkIHJpZ2h0cy4NCg0KICAgKiAgS2V5IERpc3RyaWJ1dGlv biBDZW50ZXIgKEtEQyk6IG1haW50YWlucyB0aGUga2V5aW5nIG1hdGVyaWFsIHRvDQogICAgICBw cm90ZWN0IGdyb3VwIGNvbW11bmljYXRpb25zLCBhbmQgcHJvdmlkZXMgaXQgdG8gQ2xpZW50cw0K ICAgICAgYXV0aG9yaXplZCB0byBqb2luIGEgZ2l2ZW4gZ3JvdXAuICBEdXJpbmcgdGhlIGZpcnN0 IHBhcnQgb2YgdGhlDQogICAgICBleGNoYW5nZSAoU2VjdGlvbiAzKSwgaXQgdGFrZXMgdGhlIHJv bGUgb2YgdGhlIFJTIGluIHRoZSBBQ0UNCiAgICAgIEZyYW1ld29yay4gIER1cmluZyB0aGUgc2Vj b25kIHBhcnQgKFNlY3Rpb24gNCksIHdoaWNoIGlzIG5vdCBiYXNlZA0KICAgICAgb24gdGhlIEFD RSBGcmFtZXdvcmssIGl0IGRpc3RyaWJ1dGVzIHRoZSBrZXlpbmcgbWF0ZXJpYWwuICBJbg0KDQoN ClBhbG9tYmluaSAmIFRpbG9jYSAgICAgIEV4cGlyZXMgMTIgTm92ZW1iZXIgMjAyMCAgICAgICAg ICAgICAgICBbUGFnZSA0XQ0KDQpJbnRlcm5ldC1EcmFmdCAgS2V5IFByb3Zpc2lvbmluZyBmb3Ig R3JvdXAgQ29tbXVuaWNhdGlvbiAgICAgICAgTWF5IDIwMjANCg0KICAgICAgYWRkaXRpb24sIGl0 IHByb3ZpZGVzIHRoZSBsYXRlc3Qga2V5aW5nIG1hdGVyaWFsIHRvIGdyb3VwIG1lbWJlcnMNCiAg ICAgIHdoZW4gcmVxdWVzdGVkIG9yLCBpZiByZXF1aXJlZCBieSB0aGUgYXBwbGljYXRpb24sIHdo ZW4gbWVtYmVyc2hpcA0KICAgICAgY2hhbmdlcy4NCg0KPG1nbHQ+DQoNClRoZSBmaWd1cmUgaW5k aWNhdGVzIHRoZSBkaXNwYXRjaGVyIGFzIHRoZSBSUy4gIEkNCmhhdmUgdGhlIGltcHJlc3Npb24g dGhhdCBpbiBvdXIgY2FzZSB0aGUgS0RDIGNvdWxkDQpiZSBzZWVuIGFzIHRoZSBSUyB0aGF0IHBy b3ZpZGVzIHRoZSBuZWNlc3NhcnkNCm1hdGVyaWFsIHRvIGFjY2VzcyB0aGUgZGlzcGF0Y2hlci4g IEZyb20gdGhlIHRleHQNCml0IHNlZW1zIHRoYXQgbm8gYXV0aG9yaXNhdGlvbiBjb250cm9sIGlz DQpwZXJmb3JtZWQgYXQgdGhlIGRpc3BhdGNoZXIsIGFjY2VzcyBpcyBncmFudGVkIGJ5DQp0aGUg b3duZXJzaGlwIG9mIHRoZSAoc2hhcmVkKSBrZXlpbmcgbWF0ZXJpYWwuDQpGb3IgdGhhdCByZWFz b24gSSBhbSB3b25kZXJpbmcgd2h5IGRvIHdlIGNvbnNpZGVyDQp0aGUgZGlzcGF0Y2hlciBhcyB0 aGUgUlMgaW5zdGVhZCBvZiB0aGUgS0RDLg0KDQo8L21nbHQ+DQoNCkZQOiBUaGUgZGlzcGF0Y2hl ciBpcyBtYXJrZWQgYXMgdGhlIFJTIGJlY2F1c2UgaW4gcHJhY3RpY2UgaXQgZGlzdHJpYnV0ZXMg dGhlIHRhcmdldCByZXNvdXJjZSByZXByZXNlbnRhdGlvbiB0byB0aGUgY2xpZW50L2dyb3VwIG1l bWJlci4gV2UgZG8gbWVudGlvbiBpbiB0aGUgYnVsbGV0IGRlZmluaXRpb24gb2YgS0RDIHRoYXQg dGhlIEtEQyB0YWtlcyB0aGUgcm9sZSBvZiBSUyBkdXJpbmcgdGhlIEFjZSBleGNoYW5nZS4NCg0K ICAgKiAgRGlzcGF0Y2hlcjogZW50aXR5IHRocm91Z2ggd2hpY2ggdGhlIENsaWVudHMgY29tbXVu aWNhdGUgd2l0aCB0aGUNCiAgICAgIGdyb3VwIGFuZCB3aGljaCBkaXN0cmlidXRlcyBtZXNzYWdl cyB0byB0aGUgZ3JvdXAgbWVtYmVycy4NCiAgICAgIEV4YW1wbGVzIG9mIGRpc3BhdGNoZXJzIGFy ZTogdGhlIEJyb2tlciBub2RlIGluIGEgcHViLXN1YiBzZXR0aW5nOw0KICAgICAgYSByZWxheWVy IG5vZGUgZm9yIGdyb3VwIGNvbW11bmljYXRpb24gdGhhdCBkZWxpdmVycyBncm91cA0KICAgICAg bWVzc2FnZXMgYXMgbXVsdGlwbGUgdW5pY2FzdCBtZXNzYWdlcyB0byBhbGwgZ3JvdXAgbWVtYmVy czsgYW4NCiAgICAgIGltcGxpY2l0IGVudGl0eSBhcyBpbiBhIG11bHRpY2FzdCBjb21tdW5pY2F0 aW9uIHNldHRpbmcsIHdoZXJlDQogICAgICBtZXNzYWdlcyBhcmUgdHJhbnNtaXR0ZWQgdG8gYSBt dWx0aWNhc3QgSVAgYWRkcmVzcyBhbmQgZGVsaXZlcmVkDQogICAgICBvbiB0aGUgdHJhbnNwb3J0 IGNoYW5uZWwuDQoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgbWVjaGFuaXNtIGZvcjoN Cg0KICAgKiAgQXV0aG9yaXppbmcgYSBuZXcgbm9kZSB0byBqb2luIHRoZSBncm91cCAoU2VjdGlv biAzKSwgYW5kDQogICAgICBwcm92aWRpbmcgaXQgd2l0aCB0aGUgZ3JvdXAga2V5aW5nIG1hdGVy aWFsIHRvIGNvbW11bmljYXRlIHdpdGgNCiAgICAgIHRoZSBvdGhlciBncm91cCBtZW1iZXJzIChT ZWN0aW9uIDQpLg0KDQogICAqICBBIG5vZGUgdG8gbGVhdmUgdGhlIGdyb3VwIG9mIGZvciB0aGUg S0RDIHRvIHJlbW92ZSBhIGN1cnJlbnQNCiAgICAgIG1lbWJlciBvZiB0aGUgZ3JvdXAgKFNlY3Rp b24gNSkuDQoNCiAgICogIFJldHJpZXZpbmcga2V5aW5nIG1hdGVyaWFsIGFzIGEgY3VycmVudCBn cm91cCBtZW1iZXIgKFNlY3Rpb24gNC4zDQogICAgICBhbmQgU2VjdGlvbiA0LjQpLg0KDQogICAq ICBSZW5ld2luZyBhbmQgcmUtZGlzdHJpYnV0aW5nIHRoZSBncm91cCBrZXlpbmcgbWF0ZXJpYWwg KHJla2V5aW5nKQ0KICAgICAgdXBvbiBhIG1lbWJlcnNoaXAgY2hhbmdlIGluIHRoZSBncm91cCAo U2VjdGlvbiA0LjkgYW5kIFNlY3Rpb24gNSkuDQoNCiAgIEZpZ3VyZSAyIHByb3ZpZGVzIGEgaGln aCBsZXZlbCBvdmVydmlldyBvZiB0aGUgbWVzc2FnZSBmbG93IGZvciBhDQogICBub2RlIGpvaW5p bmcgYSBncm91cCBjb21tdW5pY2F0aW9uIHNldHRpbmcsIHdoaWNoIGNhbiBiZSBleHBhbmRlZCBh cw0KICAgZm9sbG93cy4NCg0KICAgMS4gIFRoZSBqb2luaW5nIG5vZGUgcmVxdWVzdHMgYW4gQWNj ZXNzIFRva2VuIGZyb20gdGhlIEFTLCBpbiBvcmRlcg0KICAgICAgIHRvIGFjY2VzcyBhIHNwZWNp ZmljIGdyb3VwLW1lbWJlcnNoaXAgcmVzb3VyY2Ugb24gdGhlIEtEQyBhbmQNCiAgICAgICBoZW5j ZSBqb2luIHRoZSBhc3NvY2lhdGVkIGdyb3VwLiAgVGhlIGpvaW5pbmcgbm9kZSB3aWxsIHN0YXJ0 IG9yDQogICAgICAgY29udGludWUgdXNpbmcgYSBzZWN1cmUgY29tbXVuaWNhdGlvbiBhc3NvY2lh dGlvbiB3aXRoIHRoZSBLREMsDQogICAgICAgYWNjb3JkaW5nIHRvIHRoZSByZXNwb25zZSBmcm9t IHRoZSBBUy4NCjxtZ2x0Pg0KDQoiY29udGludWUgdXNpbmcgYSBzZWN1cmUgY29tbXVuaWNhdGlv biIgaXMgaGVyZSBJDQp0aGluayB0byBpbmRpY2F0ZSB0aGF0IGVzdGFibGlzaG1lbnQgb2YgYSBu ZXcNCnNlY3VyZSBjb21tdW5pY2F0aW9uIGlzIG5vdCBuZWNlc3NhcnkuICBJZiB0aGF0IGlzDQpj b3JyZWN0LCB3ZSB3ZSBjb3VsZCBjbGFyaWZ5IHRoYXQgYnkgYWRkaW5nIHRoZQ0KY29tbXVuaWNh dGlvbiB0byB0aGUgQVMgaXMgc2VjdXJlZC4NCg0KPC9tZ2x0Pg0KDQpGUDogWWVzIHRoYXQgaXMg Y29ycmVjdCwgdGhlIGpvaW5pbmcgbm9kZSBtYXkgY29udGludWUgdXNpbmcgYW4gZXhpc3Rpbmcg c2VjdXJpdHkgYXNzb2NpYXRpb24gd2l0aCB0aGUgS0RDIGlmIGluc3RydWN0ZWQgYnkgQVMgKGRl dGFpbHMgdXAgdG8gcHJvZmlsZXMpLiBJIGFtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB0aGUgY2xh cmlmaWNhdGlvbiB5b3UgYXJlIHN1Z2dlc3RpbmcgdGhvdWdoOiBob3cgd291bGQgaXQgaGVscCB0 byB3cml0ZSB0aGF0IOKAnGpvaW5pbmcgbm9kZS1BUyBjb21tdW5pY2F0aW9uIGlzIHNlY3VyZeKA nSB0byBjbGFyaWZ5IHRoYXQgam9pbmluZyBub2RlLUtEQyBjb21tdW5pY2F0aW9uIG1heSB1c2Ug YW4gZXhpc3Rpbmcgc2VjdXJlIGNoYW5uZWw/DQoNCiAgIDIuICBUaGUgam9pbmluZyBub2RlIHRy YW5zZmVycyBhdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbg0KICAgICAgIGluZm9ybWF0 aW9uIHRvIHRoZSBLREMsIGJ5IHBvc3RpbmcgdGhlIG9idGFpbmVkIEFjY2VzcyBUb2tlbiB0bw0K ICAgICAgIHRoZSAvYXV0aHotaW5mbyBlbmRwb2ludCBhdCB0aGUgS0RDLiAgQWZ0ZXIgdGhhdCwg YSBqb2luaW5nIG5vZGUNCiAgICAgICBNVVNUIGhhdmUgYSBzZWN1cmUgY29tbXVuaWNhdGlvbiBh c3NvY2lhdGlvbiBlc3RhYmxpc2hlZCB3aXRoIHRoZQ0KICAgICAgIEtEQywgYmVmb3JlIHN0YXJ0 aW5nIHRvIGpvaW4gYSBncm91cCB1bmRlciB0aGF0IEtEQy4gIFBvc3NpYmxlDQogICAgICAgd2F5 cyB0byBwcm92aWRlIGEgc2VjdXJlIGNvbW11bmljYXRpb24gYXNzb2NpYXRpb24gYXJlIERUTFMN CiAgICAgICBbUkZDNjM0N10gYW5kIE9TQ09SRSBbUkZDODYxM10uDQoNCjxtZ2x0Pg0KDQpUaGUg cmVsYXRpb24gYmV0d2VlbiB0aGUgS0RDIChhcHBsaWNhdGlvbikgYW5kIHRoZQ0Kc2VjdXJlIHRy YW5zcG9ydCBvciBjb21tdW5pY2F0aW9uIGlzIG5vdCBlbnRpb3JlbHkNCmNsZWFyIHRvIG1lLiAg QSBzZWN1cmUgY29tbXVuaWNhdGlvbiBpbmNsdWRlcw0KYXV0aGVudGljYXRpb24gb2YgdGhlIHBl ZXJzIGFuZCBlbmNyeXB0aW9uIG9mIHRoZQ0KdHJhZmZpYy4gIEkgc3VwcG9zZSB0aGF0IGVuY3J5 cHRpb24gaXMgcGVyZm9ybWVkDQpieSBEVExTIG9yIE9TQ09SRSwgYnV0IEkgYW0gd29uZGVyaW5n IGlmDQphdXRoZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBhcmUgcGVyZm9ybWVkIGJ5DQp0 aGUgRFRMUyBsYXllciBvciBieSB0aGUgS0RDIGFwcGxpY2F0aW9uLiAgSSBoYXZlDQp0aGUgaW1w cmVzc2lvbiB0aGF0IEtEQyBpcyBlbnRpcmVseSByZWx5aW5nIG9uDQpEVExTL09TQ09SRSBmb3Ig ZW5jcnlwdGlvbiBhbmQNCmF1dGhlbnRpY2F0aW9uL2F1dGhvcmlzYXRpb24gYmVjYXVzZSB0aGUg dGV4dA0Kc2VlbXMgdG8gYXNzdW1lIHRoYXQgYXV0aHotaW5mbyBtYXkgYmUgbm90DQpwcm90ZWN0 ZWQuICBJIHRodXMgYXNzdW1lIGF1dGhvcml6YXRpb24gaXMNCmNoYXJhY3Rlcml6ZWQgYnkgdGhl IGFiaWxpdHkgdG8gc2V0IGEgRFRMUy9PU0NPUkUNCnNlc3Npb24uICBPZiBjb3Vyc2Ugb3RoZXIg aW5mb3JtYXRpb24gd2lsbCBiZQ0KbmVlZGVkIGJ5IHRoZSBLREMgKHNjb3BlIGZvciBleGFtcGVs KS4gIElmIHRoaXMNCnVzZSBjYXNlIG1ha2VzIHNlbnNlLCBpdCBtaWdodCBiZSBnb29kIHRvIGNs YXJpZnkNCnRoZSBpbnRlcmFjdGlvbnMgYmV0d2VlbiBkdGxzLWF1dGhvcml6ZWQgd29ya3MsIGlu DQpwYXJ0aWN1bGFyIGhvdyB0aGVzZSBhY2Nlc3MgdG9rZW5zICggdGhlIG1lcmdlZA0KYWNjZXNz IHRva2VuKSAgYXJlL2lzIHVzZWQuICBUaGUgb3RoZXIgYWx0ZXJuYXRpdmUNCmNvdWxkIGJlIHRv IHNldCBhbiB1bmF1dGhlbnRpY2F0ZWQgRFRMUy9PU0NPUkUgYW5kDQp0aGVuIHByb2NlZWQgdG8g dGhlIGNvbW11bmljYXRpb24gb2YgdGhlIGFjY2Vzcw0KdG9rZW4uDQoNCjwvbWdsdD4NCg0KRlA6 IGl0J3MgZW50aXJlbHkgdXAgdG8gdGhlIHNwZWNpZmljIHVzZWQgcHJvZmlsZSBvZiBBQ0UgdG8g ZGVzY3JpYmUgaG93IGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIGFyZSBkb25lLCB1 bHRpbWF0ZWx5IGxldmVyYWdpbmcgYW4gQWNjZXNzIFRva2VuIHdpdGggYXV0aG9yaXphdGlvbiBj cmVkZW50aWFscyB1c2VkIGFsc28gdG8gZXN0YWJsaXNoIGEgc2VjdXJlIGNoYW5uZWwuIEZvciBl eGFtcGxlLCB0aGUgT1NDT1JFIHByb2ZpbGUgZGVmaW5lcyBpdC4gSGVyZSB3ZSBtYWtlIHVzZSBv ZiB0aGVzZSDigJx0cmFuc3BvcnTigJ0gcHJvZmlsZXMsIGFuZCB3ZSBzaG91bGQgbm90IHJlLXNw ZWNpZnkgd2hhdCBpcyBhbHJlYWR5IGRlZmluZWQgdGhlcmUuDQoNClsgLi4uXQ0KDQozLiAgQXV0 aG9yaXphdGlvbiB0byBKb2luIGEgR3JvdXANCg0KICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyBp biBkZXRhaWwgdGhlIGZvcm1hdCBvZiBtZXNzYWdlcyBleGNoYW5nZWQgYnkNCiAgIHRoZSBwYXJ0 aWNpcGFudHMgd2hlbiBhIG5vZGUgcmVxdWVzdHMgYWNjZXNzIHRvIGEgZ3JvdXAuICBUaGlzDQog ICBleGNoYW5nZSBpcyBiYXNlZCBvbiBBQ0UgW0ktRC5pZXRmLWFjZS1vYXV0aC1hdXRoel0uDQoN CiAgIEFzIGRlZmluZWQgaW4gW0ktRC5pZXRmLWFjZS1vYXV0aC1hdXRoel0sIHRoZSBDbGllbnQg cmVxdWVzdHMgZnJvbQ0KICAgdGhlIEFTIGFuIGF1dGhvcml6YXRpb24gdG8gam9pbiB0aGUgZ3Jv dXAgdGhyb3VnaCB0aGUgS0RDIChzZWUNCiAgIFNlY3Rpb24gMy4xKS4gIElmIHRoZSByZXF1ZXN0 IGlzIGFwcHJvdmVkIGFuZCBhdXRob3JpemF0aW9uIGlzDQogICBncmFudGVkLCB0aGUgQVMgcHJv dmlkZXMgdGhlIENsaWVudCB3aXRoIGEgcHJvb2Ytb2YtcG9zc2Vzc2lvbiBhY2Nlc3MNCiAgIHRv a2VuIGFuZCBwYXJhbWV0ZXJzIHRvIHNlY3VyZWx5IGNvbW11bmljYXRlIHdpdGggdGhlIEtEQyAo c2VlDQogICBTZWN0aW9uIDMuMikuDQoNCiAgIENvbW11bmljYXRpb25zIGJldHdlZW4gdGhlIENs aWVudCBhbmQgdGhlIEFTIE1VU1QgYmUgc2VjdXJlZCwgYXMNCiAgIGRlZmluZWQgYnkgdGhlIHRy YW5zcG9ydCBwcm9maWxlIG9mIEFDRSB1c2VkLiAgVGhlIENvbnRlbnQtRm9ybWF0DQogICB1c2Vk IGluIHRoZSBtZXNzYWdlcyBpcyB0aGUgb25lIHNwZWNpZmllZCBieSB0aGUgdXNlZCB0cmFuc3Bv cnQNCiAgIHByb2ZpbGUgb2YgQUNFIChlLmcuIGFwcGxpY2F0aW9uL2FjZStjYm9yIGZvciB0aGUg Zmlyc3QgdHdvIG1lc3NhZ2VzDQogICBhbmQgYXBwbGljYXRpb24vY3d0IGZvciB0aGUgdGhpcmQg bWVzc2FnZSwgZGVwZW5kaW5nIG9uIHRoZSBmb3JtYXQgb2YNCiAgIHRoZSBhY2Nlc3MgdG9rZW4p Lg0KDQo8bWdsdD4NCg0KQXQgdGhhdCBwb2ludCwgSSBhc3N1bWUgdGhhdCBDbGllbnQgdG8gQVMN CmNvbW11bmljYXRpb24gaXMgc2VjdXJlZCB2aWEgYSBzdGFuZGFyZCBEVExTDQpzZXNzaW9uLiAg SSBhbSB3b25kZXJpbmcgaWYgdGhlIFBPU1QgY2FuIGJlDQp1bnNlY3VyZWQgb3IgaXMgc2VuZCBv dmVyIGEgc2VjdXJlIGNoYW5uZWwuDQoNCjwvbWdsdD4NCg0KRlA6IFRoYXQgaXMgdXAgdG8gdGhl IHRyYW5zcG9ydCBwcm9maWxlIChEVExTIG9yIE9TQ09SRSBvciBhbnkgb3RoZXIgdXNlZCBwcm9m aWxlKSB0byBkZWZpbmUuIFRoaXMgZG9jdW1lbnQgbGVhdmVzIHRoYXQgZGV0YWlsIHRvIHRoZSBw cm9maWxlIHRvIGRlZmluZS4NCg0KVGhlIHRyYW5zcG9ydCBwcm9maWxlIG9mIEFDRSBhbHNvIGRl ZmluZXMgYQ0KICAgbnVtYmVyIG9mIGRldGFpbHMgc3VjaCBhcyB0aGUgY29tbXVuaWNhdGlvbiBh bmQgc2VjdXJpdHkgcHJvdG9jb2xzDQogICB1c2VkIHdpdGggdGhlIEtEQyAoc2VlIEFwcGVuZGl4 IEMgb2YgW0ktRC5pZXRmLWFjZS1vYXV0aC1hdXRoel0pLg0KDQogICBGaWd1cmUgMyBnaXZlcyBh biBvdmVydmlldyBvZiB0aGUgZXhjaGFuZ2UgZGVzY3JpYmVkIGFib3ZlLg0KDQogICAgICAgICBD bGllbnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFTICBLREMN CiAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgICB8DQogICAgICAgICAgICB8LS0tLSBBdXRob3JpemF0aW9uIFJlcXVlc3Q6IFBPU1Qg L3Rva2VuIC0tLS0tLT58ICAgfA0KICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgIHwNCiAgICAgICAgICAgIHw8LS0tIEF1dGhvcml6 YXRpb24gUmVzcG9uc2U6IDIuMDEgKENyZWF0ZWQpIC0tLXwgICB8DQogICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgfA0KICAgICAg ICAgICAgfC0tLS0tIFBPU1QgVG9rZW46IFBPU1QgL2F1dGh6LWluZm8gLS0tLS0tLS0tLS0tLS0t PnwNCiAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAgICBGaWd1cmUgMzogTWVzc2FnZSBGbG93IG9m IEpvaW4gQXV0aG9yaXphdGlvbg0KDQozLjEuICBBdXRob3JpemF0aW9uIFJlcXVlc3QNCg0KICAg VGhlIEF1dGhvcml6YXRpb24gUmVxdWVzdCBzZW50IGZyb20gdGhlIENsaWVudCB0byB0aGUgQVMg aXMgYXMNCiAgIGRlZmluZWQgaW4gU2VjdGlvbiA1LjYuMSBvZiBbSS1ELmlldGYtYWNlLW9hdXRo LWF1dGh6XSBhbmQgTUFZDQogICBjb250YWluIHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycywgd2hp Y2gsIGlmIGluY2x1ZGVkLCBNVVNUIGhhdmUgdGhlDQogICBjb3JyZXNwb25kaW5nIHZhbHVlczoN Cg0KPG1nbHQ+DQoNCkkgYmVsaWV2ZSB0aGF0IHNvbWUgcGFyYW1ldGVycyBhcmUgbWFuZGF0b3J5 LiBJZg0KdGhhdCBpcyB0aGUgY2FzZSwgaXQgd291bGQgYmUgZ29vZCB0byBleHBsYWluDQp3aGlj aCBwYXJhbWV0ZXJzIGFyZSBvcHRpb25hbCBvciBtYW5kYXRvcnkuDQoNCjwvbWdsdD4NCg0KDQpG UDogTm90aGluZyBpcyBtYW5kYXRvcnksIGl0IGFsbCBkZXBlbmRzIG9uIHRoZSBzcGVjaWZpYyB0 cmFuc3BvcnQgcHJvZmlsZSAoRFRMUywgT1NDT1JFIGV0YykgdXNlZC4NCg0KICAgKiAgJ3Njb3Bl JywgY29udGFpbmluZyB0aGUgaWRlbnRpZmllciBvZiB0aGUgc3BlY2lmaWMgZ3JvdXAocyksIG9y DQogICAgICB0b3BpYyhzKSBpbiB0aGUgY2FzZSBvZiBwdWItc3ViLCB0aGF0IHRoZSBDbGllbnQg d2lzaGVzIHRvIGFjY2VzcywNCiAgICAgIGFuZCBvcHRpb25hbGx5IHRoZSByb2xlKHMpIHRoYXQg dGhlIENsaWVudCB3aXNoZXMgdG8gdGFrZS4NCg0KDQpQYWxvbWJpbmkgJiBUaWxvY2EgICAgICBF eHBpcmVzIDEyIE5vdmVtYmVyIDIwMjAgICAgICAgICAgICAgICAgW1BhZ2UgN10NCg0KSW50ZXJu ZXQtRHJhZnQgIEtleSBQcm92aXNpb25pbmcgZm9yIEdyb3VwIENvbW11bmljYXRpb24gICAgICAg IE1heSAyMDIwDQoNCiAgICAgIFRoaXMgdmFsdWUgaXMgYSBDQk9SIGJ5dGUgc3RyaW5nLCBlbmNv ZGluZyBhIENCT1IgYXJyYXkgb2Ygb25lIG9yDQogICAgICBtb3JlIGVudHJpZXMuDQoNCjxtZ2x0 Pg0KDQpmcm9tIHRoZSB0ZXh0IGFib3ZlIEkgdW5kZXJzdGFuZCB0aGF0IHRoZSB2YWx1ZSBpcw0K dGhlIG91dHB1dCBvZiBhIENCT1Igb2JqZWN0LCB3aGljaCBzb21laG93DQpyZXF1aXJlcyB0aGUg Q0JPUiBjb21wcmVzc2lvbiB0byBiZSBydW4gdHdpY2UuICBJDQptaWdodCBiZSBtaXNzaW5nIHNv bWV0aGluZywgYnV0IGl0IHNlZW1zIHVuY2xlYXINCnRvIG1lIHdoeSB0aGlzIHNob3VsZCBiZSBk aWZmZXJlbnQgZnJvbTogVGhpcw0KdmFsdWUgaXMgYW4gYXJyYXkgb2Ygb25lIG9yIG1vcmUgZW50 cmllcy4NCg0KVGhpcyBpcyBteSB1bmRlcnN0YW5kaW5nIGZyb20gdGhlIHRleHQ6DQpzY29wZSA9 IFsgZW50cnksIGVudHJ5IF0NCg0KZW50cnkgPSBbZ3JvdXBfaWQsIChbIHJvbGUsIHJvbGUsIF0g KV0NCjwvbWdsdD4NCg0KRlA6IFRoZSByZWFzb24gaXMgdGhhdCwgYWNjb3JkaW5nIHRvIHRoZSBB Q0UgZnJhbWV3b3JrLCB0aGUgc2NvcGUgaGFzIHRvIGJlIGVuY29kZWQgYXMgYSBDQk9SIHRleHQg c3RyaW5nIG9yIGEgQ0JPUiBieXRlIHN0cmluZywgYXMgdmFsdWUgb2YgdGhlICdzY29wZScgZmll bGQgb3IgY2xhaW0uIFRoYXQgbWVhbnMgdGhhdCB3ZSBuZWVkIHRvIGRvIHRoaXMgd3JhcHBpbmcu DQoNCiAgICAgIEFuIGVudHJ5IGhhcyBhcyB2YWx1ZSBhIENCT1IgYXJyYXksIHdoaWNoIGNvbnRh aW5zOg0KDQogICAgICAtICBBcyBmaXJzdCBlbGVtZW50LCB0aGUgaWRlbnRpZmllciBvZiB0aGUg c3BlY2lmaWMgZ3JvdXAgb3INCiAgICAgICAgIHRvcGljLg0KDQogICAgICAtICBPcHRpb25hbGx5 LCBhcyBzZWNvbmQgZWxlbWVudCwgdGhlIHJvbGUgKG9yIENCT1IgYXJyYXkgb2YNCiAgICAgICAg IHJvbGVzKSB0aGF0IHRoZSBDbGllbnQgd2lzaGVzIHRvIHRha2UgaW4gdGhlIGdyb3VwLiAgVGhp cw0KICAgICAgICAgZWxlbWVudCBpcyBvcHRpb25hbCBzaW5jZSByb2xlcyBtYXkgaGF2ZSBiZWVu IHByZS1hc3NpZ25lZCB0bw0KICAgICAgICAgdGhlIENsaWVudCwgYXMgYXNzb2NpYXRlZCB0byBp dHMgdmVyaWZpYWJsZSBpZGVudGl0eQ0KICAgICAgICAgY3JlZGVudGlhbHMuICBBbHRlcm5hdGl2 ZWx5LCB0aGUgYXBwbGljYXRpb24gbWF5IGhhdmUgZGVmaW5lZCBhDQogICAgICAgICBzaW5nbGUs IHdlbGwta25vd24gcm9sZSBmb3IgdGhlIHRhcmdldCByZXNvdXJjZShzKSBhbmQNCiAgICAgICAg IGF1ZGllbmNlKHMpLg0KDQogICAgICBJbiBlYWNoIGVudHJ5LCB0aGUgZW5jb2Rpbmcgb2YgdGhl IGdyb3VwIG9yIHRvcGljIGlkZW50aWZpZXINCiAgICAgIChSRVExKSBhbmQgb2YgdGhlIHJvbGUg aWRlbnRpZmllcnMgKFJFUTIpIGlzIGFwcGxpY2F0aW9uIHNwZWNpZmljLA0KICAgICAgYW5kIHBh cnQgb2YgdGhlIHJlcXVpcmVtZW50cyBmb3IgdGhlIGFwcGxpY2F0aW9uIHByb2ZpbGUuDQoNCjxt Z2x0Pg0KDQpNYXliZSBpdCB3b3VsZCB3b3J0aCBzcGVjaWZ5aW5nIHRoZSByZWZlcmVuY2UgdGhl DQpSRVEgcmVmZXIgdG8uDQoNCjwvbWdsdD4NCg0KRlA6IFllcywgd2UgaGF2ZSBhZGRlZCB0aGF0 IHJlZmVyZW5jZSBmb3IgdGhlIGZpcnN0IG9jY3VycmVuY2Ugb2YgUkVRIGFuZCBPUFQuDQoNClsu Li5dDQoNCjMuMi4gIEF1dGhvcml6YXRpb24gUmVzcG9uc2UNCg0KICAgVGhlIEF1dGhvcml6YXRp b24gUmVzcG9uc2Ugc2VudCBmcm9tIHRoZSBBUyB0byB0aGUgQ2xpZW50IGlzIGFzDQogICBkZWZp bmVkIGluIFNlY3Rpb24gNS42LjIgb2YgW0ktRC5pZXRmLWFjZS1vYXV0aC1hdXRoel0gYW5kIE1V U1QNCiAgIGNvbnRhaW4gdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzOg0KDQogICAqICAnYWNjZXNz X3Rva2VuJywgY29udGFpbmluZyB0aGUgcHJvb2Ytb2YtcG9zc2Vzc2lvbiBhY2Nlc3MgdG9rZW4u DQoNCiAgICogICdjbmYnIGlmIHN5bW1ldHJpYyBrZXlzIGFyZSB1c2VkLCBub3QgcHJlc2VudCBp ZiBhc3ltbWV0cmljIGtleXMNCiAgICAgIGFyZSB1c2VkLiAgVGhpcyBwYXJhbWV0ZXIgaXMgZGVm aW5lZCBpbiBTZWN0aW9uIDMuMiBvZg0KICAgICAgW0ktRC5pZXRmLWFjZS1vYXV0aC1wYXJhbXNd IGFuZCBjb250YWlucyB0aGUgc3ltbWV0cmljIHByb29mLW9mLQ0KICAgICAgcG9zc2Vzc2lvbiBr ZXkgdGhhdCB0aGUgQ2xpZW50IGlzIHN1cHBvc2VkIHRvIHVzZSB3aXRoIHRoZSBLREMuDQoNCiAg ICogICdyc19jbmYnIGlmIGFzeW1tZXRyaWMga2V5cyBhcmUgdXNlZCwgbm90IHByZXNlbnQgaWYg c3ltbWV0cmljDQogICAgICBrZXlzIGFyZSB1c2VkLiAgVGhpcyBwYXJhbWV0ZXIgaXMgYXMgZGVm aW5lZCBpbiBTZWN0aW9uIDMuMiBvZg0KICAgICAgW0ktRC5pZXRmLWFjZS1vYXV0aC1wYXJhbXNd IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiBhYm91dCB0aGUNCiAgICAgIHB1YmxpYyBrZXkgb2Yg dGhlIEtEQy4NCg0KICAgKiAgJ2V4cGlyZXNfaW4nLCBjb250YWlucyB0aGUgbGlmZXRpbWUgaW4g c2Vjb25kcyBvZiB0aGUgYWNjZXNzDQogICAgICB0b2tlbi4gIFRoaXMgcGFyYW1ldGVyIE1BWSBi ZSBvbWl0dGVkIGlmIHRoZSBhcHBsaWNhdGlvbiBkZWZpbmVzDQogICAgICBob3cgdGhlIGV4cGly YXRpb24gdGltZSBpcyBjb21tdW5pY2F0ZWQgdG8gdGhlIENsaWVudCB2aWEgb3RoZXINCiAgICAg IG1lYW5zLCBvciBpZiBpdCBlc3RhYmxpc2hlcyBhIGRlZmF1bHQgdmFsdWUuDQoNCiAgIEFkZGl0 aW9uYWxseSwgdGhlIEF1dGhvcml6YXRpb24gUmVzcG9uc2UgTUFZIGNvbnRhaW4gdGhlIGZvbGxv d2luZw0KICAgcGFyYW1ldGVycywgd2hpY2gsIGlmIGluY2x1ZGVkLCBNVVNUIGhhdmUgdGhlIGNv cnJlc3BvbmRpbmcgdmFsdWVzOg0KDQogICAqICAnc2NvcGUnIGNvbnRhaW5pbmcgdGhlIGdyYW50 ZWQgc2NvcGUsIGlmIGRpZmZlcmVudCBmcm9tIHRoZSBzY29wZQ0KICAgICAgcmVxdWVzdGVkIGJ5 IHRoZSBjbGllbnQuICBUaGlzIHBhcmFtZXRlciBoYXMgdGhlIHNhbWUgZm9ybWF0IGFuZA0KICAg ICAgZW5jb2Rpbmcgb2YgJ3Njb3BlJyBpbiB0aGUgQXV0aG9yaXphdGlvbiBSZXF1ZXN0LCBkZWZp bmVkIGluDQogICAgICBTZWN0aW9uIDMuMS4NCg0KICAgKiAgT3RoZXIgYWRkaXRpb25hbCBwYXJh bWV0ZXJzIGFzIGRlZmluZWQgaW4NCiAgICAgIFtJLUQuaWV0Zi1hY2Utb2F1dGgtYXV0aHpdLCBp ZiBuZWNlc3NhcnkuDQoNCiAgIFRoZSBwcm9vZi1vZi1wb3NzZXNzaW9uIGFjY2VzcyB0b2tlbiAo aW4gJ2FjY2Vzc190b2tlbicgYWJvdmUpIE1VU1QNCiAgIGNvbnRhaW4gdGhlIGZvbGxvd2luZyBw YXJhbWV0ZXJzOg0KDQoNCg0KUGFsb21iaW5pICYgVGlsb2NhICAgICAgRXhwaXJlcyAxMiBOb3Zl bWJlciAyMDIwICAgICAgICAgICAgICAgIFtQYWdlIDldDQoNCkludGVybmV0LURyYWZ0ICBLZXkg UHJvdmlzaW9uaW5nIGZvciBHcm91cCBDb21tdW5pY2F0aW9uICAgICAgICBNYXkgMjAyMA0KDQog ICAqICBhIGNvbmZpcm1hdGlvbiBjbGFpbSAoc2VlIGZvciBleGFtcGxlICdjbmYnIGRlZmluZWQg aW4gU2VjdGlvbiAzLjENCiAgICAgIG9mIFtSRkM4NzQ3XSBmb3IgQ1dUKTsNCg0KICAgKiAgYW4g ZXhwaXJhdGlvbiB0aW1lIGNsYWltIChzZWUgZm9yIGV4YW1wbGUgJ2V4cCcgZGVmaW5lZCBpbg0K ICAgICAgU2VjdGlvbiAzLjEuNCBvZiBbUkZDODM5Ml0gZm9yIENXVCk7DQoNCiAgICogIGEgc2Nv cGUgY2xhaW0gKHNlZSBmb3IgZXhhbXBsZSAnc2NvcGUnIHJlZ2lzdGVyZWQgaW4gU2VjdGlvbiA4 LjEzDQogICAgICBvZiBbSS1ELmlldGYtYWNlLW9hdXRoLWF1dGh6XSBmb3IgQ1dUKS4gIFRoaXMg Y2xhaW0gaGFzIHRoZSBzYW1lDQogICAgICBlbmNvZGluZyBhcyAnc2NvcGUnIHBhcmFtZXRlciBh Ym92ZS4gIEFkZGl0aW9uYWxseSwgdGhpcyBjbGFpbSBoYXMNCiAgICAgIHRoZSBzYW1lIHZhbHVl IG9mIHRoZSAnc2NvcGUnIHBhcmFtZXRlciBpZiB0aGUgcGFyYW1ldGVyIGlzDQogICAgICBwcmVz ZW50IGluIHRoZSBtZXNzYWdlLCBvciBpdCB0YWtlcyB0aGUgdmFsdWUgb2YgJ3Njb3BlJyBpbiB0 aGUNCiAgICAgIEF1dGhvcml6YXRpb24gUmVxdWVzdCBvdGhlcndpc2UuDQoNCiAgIFRoZSBhY2Nl c3MgdG9rZW4gTUFZIGFkZGl0aW9uYWxseSBjb250YWluIG90aGVyIGNsYWltcyB0aGF0IHRoZQ0K ICAgdHJhbnNwb3J0IHByb2ZpbGUgb2YgQUNFIHJlcXVpcmVzLCBvciBvdGhlciBvcHRpb25hbCBw YXJhbWV0ZXJzLg0KDQogICBBcyBpbiBbSS1ELmlldGYtYWNlLW9hdXRoLWF1dGh6XSwgdGhlc2Ug cGFyYW1ldGVycyBhcmUgaW5jbHVkZWQgaW4NCiAgIHRoZSBwYXlsb2FkLCB3aGljaCBpcyBmb3Jt YXR0ZWQgYXMgYSBDQk9SIG1hcC4gIFRoZSBDb250ZW50LUZvcm1hdA0KICAgImFwcGxpY2F0aW9u L2FjZStjYm9yIiBpcyB1c2VkLg0KDQogICBXaGVuIHJlY2VpdmluZyBhbiBBdXRob3JpemF0aW9u IFJlcXVlc3QgZnJvbSBhIENsaWVudCB0aGF0IHdhcw0KICAgcHJldmlvdXNseSBhdXRob3JpemVk LCBhbmQgZm9yIHdoaWNoIHRoZSBBUyBzdGlsbCBvd25zIGEgdmFsaWQgbm9uDQogICBleHBpcmVk IGFjY2VzcyB0b2tlbiwgdGhlIEFTIE1BWSByZXBseSB3aXRoIHRoYXQgdG9rZW4uICBOb3RlIHRo YXQgaXQNCiAgIGlzIHVwIHRvIGFwcGxpY2F0aW9uIHByb2ZpbGVzIG9mIEFDRSB0byBtYWtlIHN1 cmUgdGhhdCByZS1wb3N0aW5nIHRoZQ0KICAgc2FtZSB0b2tlbiBkb2VzIG5vdCBjYXVzZSByZS11 c2Ugb2Yga2V5aW5nIG1hdGVyaWFsIGJldHdlZW4gbm9kZXMNCiAgIChmb3IgZXhhbXBsZSwgdGhh dCBpcyBkb25lIHdpdGggdGhlIHVzZSBvZiByYW5kb20gbm9uY2VzIGluDQogICBbSS1ELmlldGYt YWNlLW9zY29yZS1wcm9maWxlXSkuDQoNCjxtZ2x0Pg0KDQpJIGFtIHdvbmRlcmluZyBpZiBpdCBp cyBleHBlY3RlZCB0aGUgY2xpZW50IHJlYWRzDQp0aGUgdmFsdWVzIGNvbnRhaW5lZCBpbiB0aGUg YWNjZXNzX3Rva2VuLiAgSQ0Kc3VwcG9zZSBub3QsIGFuZCBldmVuIHdoZW4gdGhlIGFjY2VzX3Rv a2VuIGlzIG5vdA0KZW5jcnlwdGVkIHRoZSBjbGllbnQgaXMgc3VwcG9zZWQgdG8gcGFzcyB0aGUN CmFjY2VzcyB0b2tlbiBhcyBvcGFxdWUgZGF0YSB0byB0aGUgS0RDLiAgSXMgdGhhdA0KY29ycmVj dCA/DQoNCkkgYW0gYWxzbyB3b25kZXJpbmcgaG93IHRoZSBBUyBjb3VsZCBpbmZvcm0gd2hpY2gN CnRyYW5zcG9ydCBhcmUgYXZhaWxhYmxlIHRvIHRoZSBLREMuDQoNCldoYXQgaXMgYSBsaXR0bGUg Yml0IHVuY2xlYXIgdG8gbWUgaXMgd2hlbiB0aGUNCmFjY2VzcyB0b2tlbiBpcyBjb21iaW5lZCB3 aXRoIGFub3RoZXIgYWNjZXNzIHRva2VuDQpmcm9tIHRoZSB0cmFuc3BvcnQgbGF5ZXIuIEkgc3Vw cG9zZSB0aGF0IHRoZSB0d28NCnRva2VucyBhcmUgIm1lcmdlZCIgaW4gc29tZSB3YXlzIGFuZCBJ IGFtDQp3b25kZXJpbmcgaWYgdGhlIHRyYW5zcG9ydCBhY2Nlc3MgdG9rZW4gaXMNCmV4cGVjdGVk IHRvIGluY2x1ZGUgdGhvc2Ugb2YgdGhlIHVwcGVyIGxheWVycyBpbg0Kb3VyIGNhc2UgdGhlIEtE Qy4NCg0KPC9tZ2x0Pg0KDQpGUDogQXMgZGVmaW5lZCBpbiBBQ0UsIHRoZSB0b2tlbiBpcyBvcGFx dWUgdG8gdGhlIGNsaWVudCwgd2hpY2ggZG9lcyBub3QgdW5kZXJzdGFuZCBhIGJpdCBvZiBpdC4N Cg0KQWxzbywgdGhlIHRyYW5zcG9ydCBhdmFpbGFibGUgdG8gdGhlIEtEQyBpcyBkZWZpbmVkIGlu IHRoZSB0cmFuc3BvcnQgcHJvZmlsZS4gRWl0aGVyIHRoZSBwcm9maWxlIGlzIGtub3duIGluIGFk dmFuY2UgYnkgdGhlIGNsaWVudCwgb3IgdGhlIEFTIHNpZ25hbHMgaXQgaW4gdGhlIHRva2VuIHJl c3BvbnNlLg0KDQpBYm91dCBtZXJnaW5nIHRoZSDigJx0cmFuc3BvcnTigJ0gdG9rZW4gYW5kIHRo ZSDigJx1cHBlciBsYXllcuKAnSB0b2tlbiwgSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQsIGFz IHRoaXMgaXMgZXhhY3RseSB0aGUg4oCcdHJhbnNwb3J04oCdIHRva2VuLiBUaGlzIGlzIHRoZSB0 b2tlbiB1c2VkIHRvIGVzdGFibGlzaCBhIHNlY3VyZSBjb25uZWN0aW9uIGJldHdlZW4gQ2xpZW50 IGFuZCBLREMuDQoNCg0KMy4zLiAgVG9rZW4gUG9zdA0KDQogICBUaGUgQ2xpZW50IHNlbmRzIGEg Q29BUCBQT1NUIHJlcXVlc3QgaW5jbHVkaW5nIHRoZSBhY2Nlc3MgdG9rZW4gdG8NCiAgIHRoZSBL REMsIGFzIHNwZWNpZmllZCBpbiBTZWN0aW9uIDUuOC4xIG9mIFtJLUQuaWV0Zi1hY2Utb2F1dGgt YXV0aHpdLg0KICAgSWYgdGhlIHNwZWNpZmljIHRyYW5zcG9ydCBwcm9maWxlIG9mIEFDRSBkZWZp bmVzIGl0LCB0aGUgQ2xpZW50IE1BWQ0KICAgdXNlIGEgZGlmZmVyZW50IGVuZHBvaW50IHRoYW4g L2F1dGh6LWluZm8gYXQgdGhlIEtEQyB0byBwb3N0IHRoZQ0KICAgYWNjZXNzIHRva2VuIHRvLg0K DQo8bWdsdD4NCg0KSSB0aGluayB0aGUgb3ZlcnZpZXcgc2VjdGlvbiBtZW50aW9ucw0KYXBwbGlj YXRpb24vY3d0IGlzIHVzZWQgZm9yIHRoYXQgZXhjaGFuZ2UuICBJDQp0aGluayBpdCBtaWdodCBi ZSBoZWxwZnVsIHRvIHNwZWNpZnkgdGhhdCBwb3N0DQp1c2VzIGFwcGxpY2F0aW9uL2N3dCBzaW5j ZSBsYXRlciB3ZSBpbmRpY2F0ZSB0aGF0DQphcHBsaWNhdGlvbi9hY2UrY2JvciBtYXkgY2Fycnkg YW5vdGhlciBtZWFuaW5nLg0KSXQgbWlnaHQgd29ydGggdXBkYXRpbmcgdGhpcyBzZWN0aW9uIGFz IHdlbGwuDQoNCkkgYWxzbyBoYXZlIHRoZSBpbXByZXNzaW9uIHRoYXQgdGhlIHJlc3BvbnNlIHRv DQp0aGUgcG9zdCBpcyBjYWxsZWQgIkFTIFJlcXVlc3QgQ3JlYXRpb24gSGludHMiLg0KSWYgdGhh dCBpcyBjb3JyZWN0LCB0aGUgZGVzaWduYXRpb24gaXMgbWlzbGVhZGluZywNCmFzIGhpbnRzIGFy ZSBub3QgdGFyZ2V0aW5nIHRoZSBBUyBpbiB0aGUgY2FzZS4NCk1heWJlIHRoYXQgd291bGQgYmUg Z29vZCB0byBpbmRpY2F0ZSB0aGlzIGlzIHRoaXMNCmV4Y2hhbmdlIHRoYXQgaXMgYmVpbmcgY29u c2lkZXJlZCB3aXRoIGEgZGlmZmVyZW50DQptZWFuaW5nIGFzIGl0IGhhcyBiZWVuIGRlZmluZWQg aW4gdGhlIGZyYW1ld29yay4NCklmIHRoYXQgaXMgc3RpbGwgY29ycmVjdCwgSSBhbSB3b25kZXJp bmcgaG93IHRoZQ0KY2xpZW50IGNhbiBtYWtlIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBBUw0K UmVxdWVzdCBDcmVhdGlvbiBIaW50cyBhcyBhIFJlc3BvbnNlIHRoYXQgcHJvdmlkZXMNCmFkZGl0 aW9uYWwgaW5mb3JtYXRpb24gcmVsYXRlZCB0byB0aGUgZ3JvdXANCmNvbW11bmljYXRpb24uICBJ biBwYXJ0aWN1bGFyIEkgYW0gd29uZGVyaW5nIGlmDQpwYXJhbWV0ZXJzIGFyZSB1c2VkIHRvIGRp c3Rpbmd1aXNoIHRoZXNlIHR3bw0KcmVzcG9uc2VzLg0KDQo8L21nbHQ+DQoNCkZQOiBUaGUgY29u dGVudCBmb3JtYXQgYXBwbGljYXRpb24vY3d0IGlzIGludGVuZGVkIHRvIHN1Ym1pdCB0aGUgYWNj ZXNzIHRva2VuIGFsb25lLCBhbmQgbm90aGluZyBlbHNlLiBUaGlzIGlzIHN0aWxsIGEgcG9zc2li bGUgdmFsaWQgb3B0aW9uLCBlLmcuIHdoZW4gdXNpbmcgdGhlIERUTFMgcHJvZmlsZSBhbmQgdGhl IGNsaWVudCBkb2VzIG5vdCBpbmNsdWRlIGFueSBwYXJhbWV0ZXIgZm9yIGFza2luZyB3aGF0IGFs Z29yaXRobXMgYXJlIHVzZWQgaW4gdGhlIGdyb3VwLg0KDQpGb3IgdGhlIEFTIFJlcXVlc3QgQ3Jl YXRpb24gSGludHM6IGdvb2QgcG9pbnQsIEkgaGFkIGFscmVhZHkgdGFrZW4gY2FyZSBvZiBhIHNp bWlsYXIgcG9pbnQgaW4gdGhlIE9TQ09SRSBwcm9maWxlLCB3aGVyZSBvdGhlciBwYXJhbWV0ZXJz IHdlcmUgcmVnaXN0ZXJlZCB0byBiZSB1c2VkIGluIHRoZSBUb2tlbiBSZXNwb25zZSBhcyBBUyBS ZXF1ZXN0IEhpbnRzLiBOb3cgdGhleSBhcmUgcmVnaXN0ZXJlZCBpbiB0aGUgT0F1dGggUGFyYW1l dGVycyBSZWdpc3RyeSAoYW5kIE1hcHBpbmcpLiBXZSBoYXZlIGZvbGxvd2VkIHRoYXQgZm9yIHRo ZSBwYXJhbWV0ZXJzIHJlZ2lzdGVyZWQgaGVyZS4NCg0KDQogICBPcHRpb25hbGx5LCB0aGUgQ2xp ZW50IG1pZ2h0IHdhbnQgdG8gcmVxdWVzdCBuZWNlc3NhcnkgaW5mb3JtYXRpb24NCiAgIGNvbmNl cm5pbmcgdGhlIHB1YmxpYyBrZXlzIGluIHRoZSBncm91cCwgYXMgd2VsbCBhcyBjb25jZXJuaW5n IHRoZQ0KICAgYWxnb3JpdGhtIGFuZCByZWxhdGVkIHBhcmFtZXRlcnMgZm9yIGNvbXB1dGluZyBz aWduYXR1cmVzIGluIHRoZQ0KICAgZ3JvdXAuICBJbiBzdWNoIGEgY2FzZSwgdGhlIGpvaW5pbmcg bm9kZSBNQVkgYXNrIGZvciB0aGF0IGluZm9ybWF0aW9uDQogICB0byB0aGUgS0RDIGluIHRoaXMg c2FtZSByZXF1ZXN0LiAgVG8gdGhpcyBlbmQsIGl0IHNlbmRzIHRoZSBDb0FQIFBPU1QNCiAgIHJl cXVlc3QgdG8gdGhlIC9hdXRoei1pbmZvIGVuZHBvaW50IHVzaW5nIHRoZSBDb250ZW50LUZvcm1h dA0KICAgImFwcGxpY2F0aW9uL2FjZStjYm9yIi4gIFRoZSBwYXlsb2FkIG9mIHRoZSBtZXNzYWdl IE1VU1QgYmUgZm9ybWF0dGVkDQogICBhcyBhIENCT1IgbWFwLCBpbmNsdWRpbmcgdGhlIGFjY2Vz cyB0b2tlbiBhbmQgdGhlIGZvbGxvd2luZw0KICAgcGFyYW1ldGVyczoNCg0KICAgKiAgJ3NpZ25f aW5mbycgZGVmaW5lZCBpbiBTZWN0aW9uIDMuMy4xLg0KDQoNCg0KUGFsb21iaW5pICYgVGlsb2Nh ICAgICAgRXhwaXJlcyAxMiBOb3ZlbWJlciAyMDIwICAgICAgICAgICAgICAgW1BhZ2UgMTBdDQoN CkludGVybmV0LURyYWZ0ICBLZXkgUHJvdmlzaW9uaW5nIGZvciBHcm91cCBDb21tdW5pY2F0aW9u ICAgICAgICBNYXkgMjAyMA0KDQogICAqICAncHViX2tleV9lbmMnIGRlZmluZWQgaW4gU2VjdGlv biAzLjMuMiwgZW5jb2RpbmcgdGhlIENCT1Igc2ltcGxlDQogICAgICB2YWx1ZSBOdWxsLCB0byBy ZXF1aXJlIGluZm9ybWF0aW9uIG9uIHRoZSBleGFjdCBlbmNvZGluZyBvZiBwdWJsaWMNCiAgICAg IGtleXMgdXNlZCBpbiB0aGUgZ3JvdXAuDQoNCiAgIEFsdGVybmF0aXZlbHksIHRoZSBqb2luaW5n IG5vZGUgbWF5IHJldHJpZXZlIHRoaXMgaW5mb3JtYXRpb24gYnkNCiAgIG90aGVyIG1lYW5zLg0K DQogICBBZnRlciBzdWNjZXNzZnVsIHZlcmlmaWNhdGlvbiwgdGhlIENsaWVudCBpcyBhdXRob3Jp emVkIHRvIHJlY2VpdmUNCg0KPG1nbHQ+DQoNCkkgYW0gd29uZGVyaW5nIGlmIHRoZSB2ZXJpZmlj YXRpb24gZ29lcyBiZXlvbmQgdGhlDQpzaWduYXR1cmUgdmFsaWRhdGlvbi4NClRoZSByZW1haW5p bmcgb2YgdGhlIHRleHQgc2VlbXMgYWxzbyB0byBhc3N1bWUNCnRoYXQgYWNlK2Nib3IgaXMgdXNl ZC4gSXMgdGhhdCBjb3JyZWN0ID8NCg0KPC9tZ2x0Pg0KDQpGUDogVGhlIHZlcmlmaWNhdGlvbiBn b2VzIGxpa2UgZm9yIGFueSBvdGhlciB0b2tlbnMgdGhlIFJTIHdvdWxkIHJlY2VpdmUgZnJvbSB0 aGF0IEFTLiBPZiBjb3Vyc2UgdGhlIFJTIHVuZGVyc3RhbmRzIHRoZSBpbmRpY2F0ZWQgc2NvcGUs IGFuZCBjaGVja3MgaXQgdG8gYmUgbWVhbmluZ2Z1bC4NCg0KT24gdGhlIHNlY29uZCBwYXJ0LCBk ZXRhaWxzIGNvbWUgbGF0ZXIgb246DQotIEEgc3VjY2Vzc2Z1bCByZXNwb25zZSBmcm9tIC9hdXRo ei1pbmZvIGhhcyBjdD1hcHBsaWNhdGlvbi9hY2UrY2Jvcg0KLSBUaGUgSm9pbmluZyBSZXF1ZXN0 IHRvIHRoZSBLREMgaGFzIGN0PWFwcGxpY2F0aW9uL2FjZS1ncm91cGNvbW0rY2Jvcg0KLSBUaGUg c3VjY2Vzc2Z1bCBKb2luaW5nIFJlc3BvbnNlIGZyb20gdGhlIEtEQyBoYXMgY3Q9YXBwbGljYXRp b24vYWNlLWdyb3VwY29tbStjYm9yDQotIEFuIGVycm9yIHJlc3BvbnNlIGZyb20gdGhlIEtEQyBm b2xsb3dpbmcgdGhlIEpvaW5pbmcgUmVxdWVzdCBoYXMgY3Q9YXBwbGljYXRpb24vYWNlK2Nib3IN ClRoYXQgaXMgYWxyZWFkeSBkZWZpbmVkIGluIGVhY2ggc3BlY2lmaWMgc2VjdGlvbi4NCg0KICAg dGhlIGdyb3VwIGtleWluZyBtYXRlcmlhbCBmcm9tIHRoZSBLREMgYW5kIGpvaW4gdGhlIGdyb3Vw LiAgSW4NCiAgIHBhcnRpY3VsYXIsIHRoZSBLREMgcmVwbGllcyB0byB0aGUgQ2xpZW50IHdpdGgg YSAyLjAxIChDcmVhdGVkKQ0KICAgcmVzcG9uc2UsIHVzaW5nIENvbnRlbnQtRm9ybWF0ICJhcHBs aWNhdGlvbi9hY2UrY2JvciIgZGVmaW5lZCBpbg0KICAgU2VjdGlvbiA4LjE0IG9mIFtJLUQuaWV0 Zi1hY2Utb2F1dGgtYXV0aHpdLg0KDQogICBUaGUgcGF5bG9hZCBvZiB0aGUgMi4wMSByZXNwb25z ZSBpcyBhIENCT1IgbWFwLiAgSWYgdGhlIGFjY2VzcyB0b2tlbg0KICAgY29udGFpbnMgYSByb2xl IHRoYXQgcmVxdWlyZXMgdGhlIENsaWVudCB0byBzZW5kIGl0cyBvd24gcHVibGljIGtleQ0KICAg dG8gdGhlIEtEQyB3aGVuIGpvaW5pbmcgdGhlIGdyb3VwLCB0aGUgQ0JPUiBtYXAgTVVTVCBpbmNs dWRlIHRoZQ0KICAgcGFyYW1ldGVyICdrZGNjaGFsbGVuZ2UnIGRlZmluZWQgaW4gU2VjdGlvbiBT ZWN0aW9uIDMuMy4zLCBzcGVjaWZ5aW5nDQogICBhIGRlZGljYXRlZCBjaGFsbGVuZ2UgTl9TIGdl bmVyYXRlZCBieSB0aGUgS0RDLg0KDQo8bWdsdD4NCg0KSSBhbSB3b25kZXJpbmcgaG93IHRoZSBj bGllbnQgcHJvdmlkZXMgdGhlIHB1YmxpYw0Ka2V5LCBhbmQgSSBhbSB3b25kZXJpbmcgaWYgdGhl IHB1YmxpYyBrZXkgaXMgbm90DQpwcm92aWRlZCB0aHJvdWdoIHRoZSBhY2Nlc3NfdG9rZW4gdG8g dGhlIEtEQy4gIElmDQp0aGF0IHdvdWxkIGJlIGNvcnJlY3QsIGl0IHNlZW1zIHRoZW4gdGhhdCB0 aGUga2V5DQppcyBwcm92aWRlZCBieSB0aGUgQVMgb3IgdGhlIGFjY2VzcyB0b2tlbiBpbnN0ZWFk DQpvZiB0aGUgY2xpZW50LiAgTWF5YmUgdGhlIHB1YmxpYyBrZXlzIGFyZSB0aG9zZSBvZg0KdGhl IG1lbWJlcnMgb2YgdGhlIGdyb3VwLg0KDQo8L21nbHQ+DQoNCkZQOiBBcyBhIGdlbmVyYWwgY2Fz ZSwgdGhlIHB1YmxpYyBrZXkgaXMgcHJvdmlkZWQgaW4gdGhlIEpvaW5pbmcgUmVxdWVzdCBieSB0 aGUgY2xpZW50IGl0c2VsZiwgd2l0aCB0aGUgcGFyYW1ldGVyICdjbGllbnRfY3JlZCcuDQoNClRo ZSBLREMgbWlnaHQgYWxyZWFkeSBoYXZlIGEgdmFsaWQgcHVibGljIGtleSBvZiB0aGUgY2xpZW50 LCBmcm9tIHByZXZpb3VzIGludGVyYWN0aW9ucywgc28gdGhhdCB0aGUgY2xpZW50IGRvZXMgbm90 IG5lZWQgdG8gcG9zdCBpdCBhZ2Fpbi4gT25lIHBhcnRpY3VsYXIgY2FzZSwgYXMgYW4gZXhhbXBs ZSBvZiB0aGlzLCBpcyB1c2luZyB0aGUgRFRMUyBwcm9maWxlIGluIGFzeW1tZXRyaWMgbW9kZSwg d2l0aCB0aGUgdG9rZW4gaW5jbHVkaW5nIHRoZSBwdWJsaWMga2V5IG9mIHRoZSBjbGllbnQuIEJ1 dCB0aGlzIGlzIG5vdCB0aGUgZ2VuZXJhbCBjYXNlIHRoYXQgdGhpcyAocGFydCBvZiB0aGUpIGRv Y3VtZW50IGRlZmluZXMuDQoNClllcywgdGhlIHB1YmxpYyBrZXlzIG1lbnRpb25lZCBoZXJlIGFy ZSB0aG9zZSBvZiB0aGUgbWVtYmVycyBvZiB0aGUgZ3JvdXAuDQoNCiAgIFRoZSBDbGllbnQgdXNl cyB0aGlzDQogICBjaGFsbGVuZ2UgdG8gcHJvdmUgcG9zc2Vzc2lvbiBvZiBpdHMgb3duIHByaXZh dGUga2V5IChzZWUgdGhlDQogICAnY2xpZW50X2NyZWRfdmVyaWZ5JyBwYXJhbWV0ZXIgaW4gU2Vj dGlvbiA0KS4NCg0KPG1nbHQ+DQoNCkkgaGF2ZSBub3QgeWV0IHJlYWQgc2VjdGlvbiA0LCBidXQg aXQgc2VlbXMgdGhhdA0KYWRkaXRpb25hbCBleGNoYW5nZXMgYXJlIHBlcmZvcm1lZCB0aGF0IGdv ZXMNCmJleW9uZCB0aGUgVG9rZW4gcG9zdCBleGNoYW5nZS4gIElmIG15DQp1bmRlcnN0YW5kaW5n IGlzIGNvcnJlY3QsIEkgYW0gd29uZGVyaW5nIGlmIHRoYXQNCmRlc2NyaXB0aW9uIGZpdHMgdGhl IHRpdGxlIG9mIHRoaXMgc2VjdGlvbi4NCg0KPC9tZ2x0Pg0KDQpGUDogWWVzLCBzb21lIGFkZGl0 aW9uYWwgcHJvY2Vzc2luZyB0aGFuIHRoZSB1c3VhbCBBY2UgVG9rZW4gUG9zdCBleGNoYW5nZSBw cm9jZXNzaW5nIGlzIGRlZmluZWQsIHRoYXQgd2lsbCBiZSBzcGVjaWZpZWQgaW4gdGhlIEpvaW5p bmcgZXhjaGFuZ2UuIElmIHlvdSBhcmUgdGFsa2luZyBhYm91dCB0aGUgdGl0bGUgb2YgdGhpcyBz ZWN0aW9uLCB0aGlzIGlzIHN0aWxsIFRva2VuIFBvc3QgZXhjaGFuZ2UsIHdlIG9ubHkgaW50cm9k dWNlIHRoZSBob29rcyB0aGF0IGFyZSBuZWVkZWQgZm9yIGZ1cnRoZXIgcHJvY2Vzc2luZy4NCg0K Tm90ZSB0aGF0IHRoZSBwYXlsb2FkDQogICBmb3JtYXQgb2YgdGhlIHJlc3BvbnNlIGRldmlhdGVz IGZyb20gdGhlIGRlZmF1bHQgYXMgZGVmaW5lZCBpbiB0aGUNCiAgIEFDRSBmcmFtZXdvcmsgKHNl ZSBTZWN0aW9uIDUuOC4xIG9mIFtJLUQuaWV0Zi1hY2Utb2F1dGgtYXV0aHpdKS4NCg0KICAgVGhl IEtEQyBNVVNUIHN0b3JlIHRoZSAna2RjY2hhbGxlbmdlJyB2YWx1ZSBhc3NvY2lhdGVkIHRvIHRo ZSBDbGllbnQNCiAgIGF0IGxlYXN0IHVudGlsIGl0IHJlY2VpdmVzIGEgam9pbiByZXF1ZXN0IGZy b20gaXQgKHNlZSBTZWN0aW9uIDQuMiksDQogICB0byBiZSBhYmxlIHRvIHZlcmlmeSB0aGUgcHJv b2Ygb2YgcG9zc2Vzc2lvbi4gIFRoZSBzYW1lIGNoYWxsZW5nZSBNQVkNCiAgIGJlIHJldXNlZCBz ZXZlcmFsIHRpbWVzIGJ5IHRoZSBDbGllbnQsIHRvIGdlbmVyYXRlIG5ldyBwcm9vZiBvZg0KICAg cG9zc2Vzc2lvbnMsIGUuZy4gaW4gY2FzZSBvZiB1cGRhdGUgb2YgdGhlIHB1YmxpYyBrZXksIG9y IHRvIGpvaW4gYQ0KICAgZGlmZmVyZW50IGdyb3VwIHdpdGggYSBkaWZmZXJlbnQga2V5LCBzbyBp dCBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoZQ0KICAgS0RDIGtlZXBzIHN0b3JpbmcgdGhlICdrZGNj aGFsbGVuZ2UnIGFmdGVyIHRoZSBmaXJzdCBqb2luIGlzDQogICBwcm9jZXNzZWQgYXMgd2VsbC4g IElmIHRoZSBLREMgaGFzIGFscmVhZHkgZGlzY2FyZGVkIHRoZQ0KICAgJ2tkY2NoYWxsZW5nZScs IHRoYXQgd2lsbCB0cmlnZ2VyIGFuIGVycm9yIHJlc3BvbnNlIHdpdGggYSBuZXdseQ0KICAgZ2Vu ZXJhdGVkICdrZGNjaGFsbGVuZ2UnIHRoYXQgdGhlIGNsaWVudCBjYW4gdXNlIHRvIHJlc3RhcnQg dGhlIGpvaW4NCiAgIHByb2Nlc3MsIGFzIHNwZWNpZmllZCBpbiBTZWN0aW9uIDQuMi4NCg0KICAg SWYgZWl0aGVyIG9mICdzaWduX2luZm8nIG9yICdwdWJfa2V5X2VuYycgd2VyZSBpbmNsdWRlZCBp biB0aGUNCiAgIHJlcXVlc3QsIHRoZSBLREMgTUFZIGluY2x1ZGUgdGhlICdzaWduX2luZm8nIHBh cmFtZXRlciBkZWZpbmVkIGluDQogICBTZWN0aW9uIDMuMy4xLCBvcHRpb25hbGx5IGluY2x1ZGlu ZyB0aGUgJ3B1Yl9rZXlfZW5jJyBwYXJhbWV0ZXINCiAgIFNlY3Rpb24gMy4zLjIuDQoNCiAgIFRo ZSAnc2lnbl9pbmZvJyBwYXJhbWV0ZXIgTVVTVCBiZSBwcmVzZW50IGlmIHRoZSBQT1NUIHJlcXVl c3QNCiAgIGluY2x1ZGVkIHRoZSAnc2lnbl9pbmZvJyBwYXJhbWV0ZXIgYW5kL29yIHRoZSBwdWJf a2V5X2VuYyB3aXRoIHZhbHVlDQogICBOdWxsLiAgVGhlIGVuY29kaW5nIG9mIHRoZSAnc2lnbl9p bmZvJyBwYXJhbWV0ZXIgaW4gdGhlIHJlc3BvbnNlIGlzDQogICBkZWZpbmVkIGluIFNlY3Rpb24g My4zLjIuICBOb3RlIHRoYXQgdGhlIGZpZWxkICdpZCcgdGFrZXMgdGhlIHZhbHVlDQogICBvZiB0 aGUgZ3JvdXAgaWRlbnRpZmllciBmb3Igd2hpY2ggdGhlICdzaWduX2luZm8nIGFwcGxpZXMgdG8s IGluIHRoaXMNCiAgIHNwZWNpZmljYXRpb24uDQoNCg0KDQoNClBhbG9tYmluaSAmIFRpbG9jYSAg ICAgIEV4cGlyZXMgMTIgTm92ZW1iZXIgMjAyMCAgICAgICAgICAgICAgIFtQYWdlIDExXQ0KDQpJ bnRlcm5ldC1EcmFmdCAgS2V5IFByb3Zpc2lvbmluZyBmb3IgR3JvdXAgQ29tbXVuaWNhdGlvbiAg ICAgICAgTWF5IDIwMjANCg0KICAgTm90ZSB0aGF0IHRoZSBDQk9SIG1hcCBzcGVjaWZpZWQgYXMg cGF5bG9hZCBvZiB0aGUgMi4wMSAoQ3JlYXRlZCkNCiAgIHJlc3BvbnNlIG1heSBpbmNsdWRlIGZ1 cnRoZXIgcGFyYW1ldGVycywgZS5nLiBhY2NvcmRpbmcgdG8gdGhlDQogICBzaWduYWxsZWQgdHJh bnNwb3J0IHByb2ZpbGUgb2YgQUNFLg0KDQogICBBcHBsaWNhdGlvbnMgb2YgdGhpcyBzcGVjaWZp Y2F0aW9uIE1BWSBkZWZpbmUgYWx0ZXJuYXRpdmUgc3BlY2lmaWMNCiAgIG5lZ290aWF0aW9ucyBv ZiBwYXJhbWV0ZXIgdmFsdWVzIGZvciBzaWduYXR1cmUgYWxnb3JpdGhtIGFuZA0KICAgc2lnbmF0 dXJlIGtleXMsIGlmICdzaWduX2luZm8nIGFuZCAncHViX2tleV9lbmMnIGFyZSBub3QgdXNlZCAo T1BUMikuDQoNCjMuMy4xLiAgJ3NpZ25faW5mbycgUGFyYW1ldGVyDQoNCiAgIFRoZSAnc2lnbl9p bmZvJyBwYXJhbWV0ZXIgaXMgYW4gT1BUSU9OQUwgcGFyYW1ldGVyIG9mIHRoZSBBUyBSZXF1ZXN0 DQogICBDcmVhdGlvbiBIaW50cyBtZXNzYWdlIGRlZmluZWQgaW4gU2VjdGlvbiA1LjEuMi4gb2YN CiAgIFtJLUQuaWV0Zi1hY2Utb2F1dGgtYXV0aHpdLg0KDQo8bWdsdD4NCg0KVGhlIHRleHQgY2Fu IGJlIHJlYWQgYXMgJ3NpZ25faW5mbycgaXMgZGVmaW5lZCBpbg0KU2VjdGlvbiA1LjEuMi4gIEkg YmVsaWV2ZSB0aGF0IGNsYXJpZnlpbmcgdGhlDQpyZXNwb25zZSBpcyBkZXNpZ25hdGVkIGluIHRo ZSBmcmFtZXdvcmsgYXMgQVMNClJlcXVlc3QgQ3JlYXRpb24gSGludHMgYnV0IGhhcyBhIGRpZmZl cmVudCBtZWFuaW5nDQpoZXJlIG1heSBzb2x2ZSB0aGlzIGlzc3VlLg0KDQo8L21nbHQ+DQoNCkZQ OiBZZXMsIHdlIGhhdmUgcmVtb3ZlZCB0aGUg4oCcQVMgUmVxdWVzdCBDcmVhdGlvbiBIaW50c+KA nSBtZXNzYWdlIG5hbWUsIGFuZCBwb2ludCB0byB0aGUgcmlnaHQgcmVnaXN0cnkgYXQgdGhlIHNh bWUgdGltZS4NCg0KWy4uLl0NCg0KMy4zLjIuICAncHViX2tleV9lbmMnIFBhcmFtZXRlcg0KDQog ICBUaGUgJ3B1Yl9rZXlfZW5jJyBwYXJhbWV0ZXIgaXMgYW4gT1BUSU9OQUwgcGFyYW1ldGVyIG9m IHRoZSBBUw0KICAgUmVxdWVzdCBDcmVhdGlvbiBIaW50cyBtZXNzYWdlIGRlZmluZWQgaW4gU2Vj dGlvbiA1LjEuMi4gb2YNCiAgIFtJLUQuaWV0Zi1hY2Utb2F1dGgtYXV0aHpdLiAgVGhpcyBwYXJh bWV0ZXIgY29udGFpbnMgaW5mb3JtYXRpb24NCiAgIGFib3V0IHRoZSBleGFjdCBlbmNvZGluZyBv ZiBwdWJsaWMga2V5cyB0byBiZSB1c2VkIGJldHdlZW4gdGhlIENsaWVudA0KICAgYW5kIHRoZSBS Uy4gIEl0cyBleGFjdCBjb250ZW50IGlzIGFwcGxpY2F0aW9uIHNwZWNpZmljLg0KDQogICBJbiB0 aGlzIHNwZWNpZmljYXRpb24gYW5kIGluIGFwcGxpY2F0aW9uIHByb2ZpbGVzIGJ1aWxkaW5nIG9u IGl0LA0KICAgdGhpcyBwYXJhbWV0ZXIgaXMgdXNlZCB0byBhc2sgdGhlIEtEQyBpbmZvcm1hdGlv biBhYm91dCB0aGUgZW5jb2RpbmcNCiAgIG9mIHB1YmxpYyBrZXlzIHVzZWQgaW4gdGhlIGdyb3Vw Lg0KDQogICBUaGUgQ0RETCBub3RhdGlvbiBvZiB0aGUgJ3B1Yl9rZXlfZW5jJyBwYXJhbWV0ZXIg Zm9ybWF0dGVkIGFzIGluIHRoZQ0KICAgcmVxdWVzdCBpcyBnaXZlbiBiZWxvdy4NCg0KICAgICAg cHViX2tleV9lbmNfcmVxID0gbmlsDQoNCjxtZ2x0Pg0KDQpJdCBpcyBub3QgZW50aXJlbHkgY2xl YXIgdG8gbWUgd2hhdCBwdWJfa2V5X2VuYyBpcw0KYWJvdXQuIEl0IGlzIHRoZSBmb3JtYXQgb2Yg dGhlIHB1YmxpYyBrZXkgaXRzZWxmDQpvciB0aGUgZW5jcnlwdGlvbiBhbGdvcml0aG0gPw0KDQpU aGVuIGl0IGlzIHVuY2xlYXIgdG8gbWUgd2hpY2ggcHVibGljIGtleSBpcw0KcmVmZXJyZWQgdG8u ICAicHVibGljIGtleXMgdXNlZCBpbiB0aGUgZ3JvdXAiIG1ha2UNCm1lIHRoaW5rIG9mIGEgcHJp dmF0ZS9wdWJsaWMga2V5IHRoYXQgaXMgc2hhcmVkIGJ5DQphbGwgbWVtYmVycyBvZiB0aGUgZ3Jv dXAuICBUaGlzIHB1YmxpYyBrZXkgaXMgdXNlZA0Kd2l0aCB0aGUgUlMsIHRoYXQgaXMgdGhlIGRp c3BhdGNoZXIsIG5vdCB0bw0KYXV0aGVudGljYXRlIHRoZSBjbGllbnQuIEFtIEkgY29ycmVjdCA/ DQoNCjwvbWdsdD4NCg0KRlA6ICdwdWJfa2V5X2VuYycgaW5kaWNhdGVzICJ0aGUgZXhhY3QgZW5j b2Rpbmcgb2YgcHVibGljIGtleXMgdXNlZCBpbiB0aGUgZ3JvdXAiLCBlLmcuIENPU0UgS2V5LiBU aGUgYWxnb3JpdGhtIGFuZCBvdGhlciByZWxhdGVkIGluZm9ybWF0aW9uIGFyZSBpbmRpY2F0ZWQg aW4gc2VwYXJhdGUgcGFyYW1ldGVycy4NCg0KTm8sIHRoYXQgaXMgbm90IGNvcnJlY3QuIFRob3Nl IOKAnHB1YmxpYyBrZXlz4oCdIGFyZSB0aGUgYXN5bW1ldHJpYyBrZXlzIHRoYXQgd2lsbCBiZSB1 c2VkIHRvIGNvdW50ZXJzaWduIG1lc3NhZ2VzIHNlbnQgdG8gdGhlIGdyb3VwLiBFYWNoIGpvaW5p bmcgbm9kZSBoYXMgaXRzIG93biBwcml2YXRlIC8gcHVibGljIGtleSBwYWlyLg0KDQoNCjMuMy4z LiAgJ2tkY2NoYWxsZW5nZScgUGFyYW1ldGVyDQoNCiAgIFRoZSAna2RjY2hhbGxlbmdlJyBwYXJh bWV0ZXIgaXMgYW4gT1BUSU9OQUwgcGFyYW1ldGVyIG9mIHRoZSBBUw0KICAgUmVxdWVzdCBDcmVh dGlvbiBIaW50cyBtZXNzYWdlIGRlZmluZWQgaW4gU2VjdGlvbiA1LjEuMi4gb2YNCiAgIFtJLUQu aWV0Zi1hY2Utb2F1dGgtYXV0aHpdLiAgVGhpcyBwYXJhbWV0ZXIgY29udGFpbnMgYSBjaGFsbGVu Z2UNCiAgIGdlbmVyYXRlZCBieSB0aGUgS0RDIGFuZCBwcm92aWRlZCB0byB0aGUgQ2xpZW50LiAg VGhlIENsaWVudCBtYXkgdXNlDQogICB0aGlzIGNoYWxsZW5nZSB0byBwcm92ZSBwb3NzZXNzaW9u IG9mIGl0cyBvd24gcHJpdmF0ZSBrZXkgaW4gdGhlDQogICBKb2luaW5nIFJlcXVlc3QgKChzZWUg dGhlICdjbGllbnRfY3JlZF92ZXJpZnknIHBhcmFtZXRlciBpbg0KICAgU2VjdGlvbiA0KS4NCg0K PG1nbHQ+DQoNCkkgc3VwcG9zZSB0aGF0IHdpbGwgYmUgY2xhcmlmaWVkIGluIHNlY3Rpb24gLCBi dXQNCm9mICJpdHMgb3duIHByaXZhdGUga2V5IiBtYWtlIG1lIHRoaW5rIHRoYXQgdGhlDQprZXkg aW4gcXVlc3Rpb24gaXMgdG8gYXV0aGVudGljYXRlIHRoZSBjbGllbnQsDQppbnN0ZWFkIG9mIHRo ZSBrZXkgdXNlZCBmb3IgdGhlIGdyb3VwLg0KDQpJZiB0aGF0IGlzIGNvcnJlY3QsIGl0IGlzIHVu Y2xlYXIgdG8gbWUgd2h5IHRoZXJlDQppcyBhIG5lZWQgdG8gYXV0aGVudGljYXRlIHRoZSBjbGll bnQgYW5kIHdoeSB0aGlzDQpzaG91bGQgbm90IGJlIHBlcmZvcm1lZCBpbnN0ZWFkIGJ5IHRoZSBB Uy4gIEl0DQpzZWVtcyBJIGFtIG1pc3Npbmcgc29tZXRoaW5nIGhlcmUuDQoNCjwvbWdsdD4NCg0K RlA6IEl0IGlzIGNvcnJlY3QgdGhhdCB0aGlzIGlzIG5vdCBhYm91dCBhdXRoZW50aWNhdGluZyB0 aGUgY2xpZW50Lg0KDQoiaXRzIG93biBwcml2YXRlIGtleSIgcmVmZXJzIHRvIHRoZSBzaWduYXR1 cmUga2V5IHRoYXQgdGhlIGNsaWVudCB1c2VzIGluIHRoZSBncm91cC4gVGhhdCBrZXkgbWF5IGhh dmUgbm90IHRha2VuIHBhcnQgdG8gdGhlIHByZXZpb3VzIGludGVyYWN0aW9ucyB3aXRoIHRoZSBL REMsIGUuZy4gaXQgdGhlIFRva2VuIFBPU1Qgd2FzIGJhc2VkIG9uIHRoZSBPU0NPUkUgcHJvZmls ZSBvciB0aGUgRFRMUyBwcm9maWxlIGluIHN5bW1ldHJpYyBtb2RlLg0KDQo0LiAgS2V5aW5nIE1h dGVyaWFsIFByb3Zpc2lvbmluZyBhbmQgR3JvdXAgTWVtYmVyc2hpcCBNYW5hZ2VtZW50DQoNClsu Li5dDQoNCiAgIFVwb24gcmVjZWl2aW5nIGEgcmVxdWVzdCBmcm9tIGEgQ2xpZW50LCB0aGUgS0RD IE1VU1QgY2hlY2sgdGhhdCBpdCBpcw0KICAgc3RvcmluZyBhIHZhbGlkIGFjY2VzcyB0b2tlbiBm cm9tIHRoYXQgQ2xpZW50IGZvciB0aGUgZ3JvdXANCiAgIGlkZW50aWZpZXIgYXNzaWNpYXRlZA0K PG1nbHQ+DQphc3NvY2lhdGVkDQo8L21nbHQ+DQoNCkZQOiBGaXhlZCBub3cNCg0KdG8gdGhlIGVu ZHBvaW50LiAgSWYgdGhhdCBpcyBub3QgdGhlIGNhc2UsIGkuZS4NCiAgIHRoZSBLREMgZG9lcyBu b3Qgc3RvcmUgYSB2YWxpZCBhY2Nlc3MgdG9rZW4gb3IgdGhpcyBpcyBub3QgdmFsaWQgZm9yDQog ICB0aGF0IENsaWVudCBmb3IgdGhlIGdyb3VwIGlkZW50aWZpZXIgYXQgaGFuZCwgdGhlIEtEQyBN VVNUIHJlc3BvbmQgdG8NCiAgIHRoZSBDbGllbnQgd2l0aCBhIDQuMDEgKFVuYXV0aG9yaXplZCkg ZXJyb3IgbWVzc2FnZS4NCg0KNC4xLiAgSW50ZXJmYWNlIGF0IHRoZSBLREMNCg0KICAgVGhlIEtE QyBpcyBjb25maWd1cmVkIHdpdGggdGhlIGZvbGxvd2luZyByZXNvdXJjZXMuICBOb3RlIHRoYXQg dGhlDQogICByb290IHVybC1wYXRoICJhY2UtZ3JvdXAiIGdpdmVuIGhlcmUgYXJlIGRlZmF1bHQg bmFtZXM6DQogICBpbXBsZW1lbnRhdGlvbnMgYXJlIG5vdCByZXF1aXJlZCB0byB1c2UgdGhlc2Ug bmFtZXMsIGFuZCBjYW4gZGVmaW5lDQogICB0aGVpciBvd24gaW5zdGVhZC4gIFRoZSBJbnRlcmZh Y2UgRGVzY3JpcHRpb24gKGlmPSkgTGluayBUYXJnZXQNCiAgIEF0dHJpYnV0ZSB2YWx1ZSBhY2Ut Z3JvdXAgaXMgcmVnaXN0ZXJlZCAoU2VjdGlvbiA4LjkpIGFuZCBjYW4gYmUgdXNlZA0KICAgdG8g ZGVzY3JpYmUgdGhpcyBpbmZlcmZhY2UuDQo8bWdsdD4NCmludGVyZmFjZS4NCjwvbWdsdD4NCg0K RlA6IEZpeGVkIG5vdw0KDQo= --_000_DA7A15C0357E40DCBCA9D7EEEE18DA73ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t R0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5IaSBEYW5pZWwsPGJyPg0KPGJyPg0KVGhhbmsgeW91IHZlcnkgbXVj aCBmb3IgeW91ciByZXZpZXchIFdlIGhhdmUgaW5jbHVkZWQgeW91ciBjb21tZW50cyBpbiB0aGUg bGF0ZXN0IHB1bGwgcmVxdWVzdCBvbiBnaXRodWIgKGFjdGl2ZSBlZGl0b3LigJlzIHZlcnNpb24p Og0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9hY2Utd2cvYWNlLWtleS1ncm91 cGNvbW0vdHJlZS92LTA3Ij5odHRwczovL2dpdGh1Yi5jb20vYWNlLXdnL2FjZS1rZXktZ3JvdXBj b21tL3RyZWUvdi0wNzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+V2UgYWxzbyBoYXZlIHNvbWUgY29tbWVudHMgaW5saW5lLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YnI+DQpUaGFua3Ms PGJyPg0KRnJhbmNlc2NhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkhpLCZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPlBsZWFzZSBmaW5kIHNvbWUgcXVlc3Rpb25zIC8gY29tbWVudHMg cmVnYXJkaW5nIHRoZSBkcmFmdCBkcmFmdC1pZXRmLWFjZS1rZXktZ3JvdXBjb21tLTA2LiBJIHN1 c3BlY3QgdGhhdCBtb3N0IG9mIHRoZSBxdWVzdGlvbnMgYXJlIGNsYXJpZmljYXRpb25zIGZvciBt ZSB0byBiZXR0ZXIgdW5kZXJzdGFuZCB0aGUNCiBjb250ZXh0LiZuYnNwOyZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPllvdXJzLCZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5EYW5pZWw8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO0tleSBQcm92aXNpb25pbmcgZm9yIEdyb3VwIENvbW11bmlj YXRpb24gdXNpbmcgQUNFPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO2RyYWZ0LWlldGYtYWNlLWtleS1ncm91cGNvbW0tMDY8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Wy4uLl08L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4yLiZuYnNwOyBPdmVydmlldzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS0tLS0tLS0tLS0tJiM0MzsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQz Oy0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 fCAmbmJzcDsgJm5ic3A7IEFTICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7IEtE QyZuYnNwOyAmbmJzcDsgfDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAuLS0tLS0tLS0mZ3Q7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IHw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstLS0t LS0tLS0tLS0mIzQzOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7XiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO3YgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7JiM0MzstLS0tLS0tLS0tLS0mIzQzOyAmbmJz cDsgLyZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tJiM0MzsmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfCYjNDM7LS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8ICZuYnNwOyBDbGllbnQgJm5ic3A7IHwmbHQ7LScgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfCBEaXNwYXRjaGVyIHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgfHwmIzQzOy0tLS0tLS0tLS0tJiM0Mzs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwmbHQ7 LS0tLS0tLS0mZ3Q7fCZuYnNwOyAmbmJzcDsgKFJTKSZuYnNwOyAmbmJzcDsgfCZsdDstLS0tLS0t Jmd0O3x8ICZuYnNwOyBHcm91cCAmbmJzcDsgfDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmIzQzOy0tLS0tLS0tLS0tLSYjNDM7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLSYjNDM7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmIzQzO3wmbmJzcDsgbWVtYmVycyZuYnNwOyB8PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS0tLS0tLS0tLS0mIzQzOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO0ZpZ3VyZSAxOiBLZXkgRGlzdHJpYnV0aW9uIFBhcnRpY2lwYW50 czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwO1RoZSBmb2xsb3dpbmcgcGFydGljaXBhbnRzIChzZWUgRmlndXJlIDEpIHRha2UgcGFydCBp biB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7YXV0aG9yaXphdGlvbiBhbmQga2V5IGRpc3RyaWJ1dGlvbi48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsqJm5ic3A7IENsaWVudCAoQyk6IG5vZGUgdGhhdCB3YW50cyB0byBqb2luIHRoZSBncm91cCBj b21tdW5pY2F0aW9uLiZuYnNwOyBJdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtj YW4gcmVxdWVzdCB3cml0ZSBhbmQvb3IgcmVhZCByaWdodHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7KiZuYnNwOyBBdXRob3JpemF0 aW9uIFNlcnZlciAoQVMpOiBzYW1lIGFzIEFTIGluIHRoZSBBQ0UgRnJhbWV3b3JrOyBpdDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtlbmZvcmNlcyBhY2Nlc3MgcG9saWNpZXMsIGFu ZCBrbm93cyBpZiBhIG5vZGUgaXMgYWxsb3dlZCB0byBqb2luIGE8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Z2l2ZW4gZ3JvdXAgd2l0aCB3cml0ZSBhbmQvb3IgcmVhZCByaWdodHMu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7KiZuYnNwOyBLZXkgRGlzdHJpYnV0aW9uIENlbnRlciAoS0RDKTogbWFpbnRhaW5zIHRoZSBr ZXlpbmcgbWF0ZXJpYWwgdG88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cHJvdGVj dCBncm91cCBjb21tdW5pY2F0aW9ucywgYW5kIHByb3ZpZGVzIGl0IHRvIENsaWVudHM8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YXV0aG9yaXplZCB0byBqb2luIGEgZ2l2ZW4gZ3Jv dXAuJm5ic3A7IER1cmluZyB0aGUgZmlyc3QgcGFydCBvZiB0aGU8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7ZXhjaGFuZ2UgKFNlY3Rpb24gMyksIGl0IHRha2VzIHRoZSByb2xlIG9m IHRoZSBSUyBpbiB0aGUgQUNFPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0ZyYW1l d29yay4mbmJzcDsgRHVyaW5nIHRoZSBzZWNvbmQgcGFydCAoU2VjdGlvbiA0KSwgd2hpY2ggaXMg bm90IGJhc2VkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO29uIHRoZSBBQ0UgRnJh bWV3b3JrLCBpdCBkaXN0cmlidXRlcyB0aGUga2V5aW5nIG1hdGVyaWFsLiZuYnNwOyBJbjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+UGFsb21iaW5pICZhbXA7IFRpbG9jYSZuYnNwOyAmbmJzcDsgJm5ic3A7 IEV4cGlyZXMgMTIgTm92ZW1iZXIgMjAyMCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgW1BhZ2UgNF08L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5JbnRlcm5ldC1EcmFmdCZuYnNwOyBLZXkgUHJvdmlzaW9uaW5nIGZv ciBHcm91cCBDb21tdW5pY2F0aW9uJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE1heSAyMDIw PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthZGRpdGlv biwgaXQgcHJvdmlkZXMgdGhlIGxhdGVzdCBrZXlpbmcgbWF0ZXJpYWwgdG8gZ3JvdXAgbWVtYmVy czwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt3aGVuIHJlcXVlc3RlZCBvciwgaWYg cmVxdWlyZWQgYnkgdGhlIGFwcGxpY2F0aW9uLCB3aGVuIG1lbWJlcnNoaXA8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2hhbmdlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbHQ7bWdsdCZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5UaGUgZmlndXJlIGluZGljYXRlcyB0aGUgZGlzcGF0Y2hlciBhcyB0aGUgUlMu Jm5ic3A7IEk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+aGF2ZSB0aGUgaW1wcmVzc2lvbiB0aGF0IGluIG91ciBjYXNlIHRoZSBLREMgY291bGQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+YmUg c2VlbiBhcyB0aGUgUlMgdGhhdCBwcm92aWRlcyB0aGUgbmVjZXNzYXJ5PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPm1hdGVyaWFsIHRvIGFjY2Vz cyB0aGUgZGlzcGF0Y2hlci4mbmJzcDsgRnJvbSB0aGUgdGV4dDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5pdCBzZWVtcyB0aGF0IG5vIGF1dGhv cmlzYXRpb24gY29udHJvbCBpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5wZXJmb3JtZWQgYXQgdGhlIGRpc3BhdGNoZXIsIGFjY2VzcyBpcyBn cmFudGVkIGJ5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPnRoZSBvd25lcnNoaXAgb2YgdGhlIChzaGFyZWQpIGtleWluZyBtYXRlcmlhbC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Rm9yIHRo YXQgcmVhc29uIEkgYW0gd29uZGVyaW5nIHdoeSBkbyB3ZSBjb25zaWRlcjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj50aGUgZGlzcGF0Y2hlciBh cyB0aGUgUlMgaW5zdGVhZCBvZiB0aGUgS0RDLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZsdDsvbWdsdCZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM5OTAwRkYiPkZQOiBUaGUgZGlzcGF0Y2hlciBpcyBtYXJrZWQgYXMgdGhlIFJT IGJlY2F1c2UgaW4gcHJhY3RpY2UgaXQgZGlzdHJpYnV0ZXMgdGhlIHRhcmdldCByZXNvdXJjZSBy ZXByZXNlbnRhdGlvbiB0byB0aGUgY2xpZW50L2dyb3VwIG1lbWJlci4gV2UgZG8gbWVudGlvbiBp biB0aGUgYnVsbGV0IGRlZmluaXRpb24gb2YNCiBLREMgdGhhdCB0aGUgS0RDIHRha2VzIHRoZSBy b2xlIG9mIFJTIGR1cmluZyB0aGUgQWNlIGV4Y2hhbmdlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7KiZuYnNwOyBEaXNwYXRjaGVyOiBlbnRpdHkgdGhyb3VnaCB3aGljaCB0aGUgQ2xp ZW50cyBjb21tdW5pY2F0ZSB3aXRoIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtncm91cCBhbmQgd2hpY2ggZGlzdHJpYnV0ZXMgbWVzc2FnZXMgdG8gdGhlIGdyb3VwIG1lbWJl cnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0V4YW1wbGVzIG9mIGRpc3BhdGNo ZXJzIGFyZTogdGhlIEJyb2tlciBub2RlIGluIGEgcHViLXN1YiBzZXR0aW5nOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthIHJlbGF5ZXIgbm9kZSBmb3IgZ3JvdXAgY29tbXVuaWNh dGlvbiB0aGF0IGRlbGl2ZXJzIGdyb3VwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O21lc3NhZ2VzIGFzIG11bHRpcGxlIHVuaWNhc3QgbWVzc2FnZXMgdG8gYWxsIGdyb3VwIG1lbWJl cnM7IGFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2ltcGxpY2l0IGVudGl0eSBh cyBpbiBhIG11bHRpY2FzdCBjb21tdW5pY2F0aW9uIHNldHRpbmcsIHdoZXJlPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO21lc3NhZ2VzIGFyZSB0cmFuc21pdHRlZCB0byBhIG11bHRp Y2FzdCBJUCBhZGRyZXNzIGFuZCBkZWxpdmVyZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7b24gdGhlIHRyYW5zcG9ydCBjaGFubmVsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO1RoaXMgZG9jdW1lbnQgc3BlY2lmaWVz IGEgbWVjaGFuaXNtIGZvcjo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsqJm5ic3A7IEF1dGhvcml6aW5nIGEgbmV3IG5vZGUgdG8gam9p biB0aGUgZ3JvdXAgKFNlY3Rpb24gMyksIGFuZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtwcm92aWRpbmcgaXQgd2l0aCB0aGUgZ3JvdXAga2V5aW5nIG1hdGVyaWFsIHRvIGNvbW11 bmljYXRlIHdpdGg8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlIG90aGVyIGdy b3VwIG1lbWJlcnMgKFNlY3Rpb24gNCkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7KiZuYnNwOyBBIG5vZGUgdG8gbGVhdmUgdGhlIGdy b3VwIG9mIGZvciB0aGUgS0RDIHRvIHJlbW92ZSBhIGN1cnJlbnQ8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7bWVtYmVyIG9mIHRoZSBncm91cCAoU2VjdGlvbiA1KS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsqJm5ic3A7 IFJldHJpZXZpbmcga2V5aW5nIG1hdGVyaWFsIGFzIGEgY3VycmVudCBncm91cCBtZW1iZXIgKFNl Y3Rpb24gNC4zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FuZCBTZWN0aW9uIDQu NCkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7KiZuYnNwOyBSZW5ld2luZyBhbmQgcmUtZGlzdHJpYnV0aW5nIHRoZSBncm91cCBrZXlp bmcgbWF0ZXJpYWwgKHJla2V5aW5nKTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt1 cG9uIGEgbWVtYmVyc2hpcCBjaGFuZ2UgaW4gdGhlIGdyb3VwIChTZWN0aW9uIDQuOSBhbmQgU2Vj dGlvbiA1KS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDtGaWd1cmUgMiBwcm92aWRlcyBhIGhpZ2ggbGV2ZWwgb3ZlcnZpZXcgb2YgdGhl IG1lc3NhZ2UgZmxvdyBmb3IgYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtub2RlIGpvaW5pbmcgYSBncm91cCBj b21tdW5pY2F0aW9uIHNldHRpbmcsIHdoaWNoIGNhbiBiZSBleHBhbmRlZCBhczwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDtmb2xsb3dzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwOzEuJm5ic3A7IFRoZSBqb2luaW5nIG5vZGUgcmVxdWVzdHMgYW4gQWNj ZXNzIFRva2VuIGZyb20gdGhlIEFTLCBpbiBvcmRlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDt0byBhY2Nlc3MgYSBzcGVjaWZpYyBncm91cC1tZW1iZXJzaGlwIHJlc291 cmNlIG9uIHRoZSBLREMgYW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O2hlbmNlIGpvaW4gdGhlIGFzc29jaWF0ZWQgZ3JvdXAuJm5ic3A7IFRoZSBqb2luaW5nIG5vZGUg d2lsbCBzdGFydCBvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtjb250 aW51ZSB1c2luZyBhIHNlY3VyZSBjb21tdW5pY2F0aW9uIGFzc29jaWF0aW9uIHdpdGggdGhlIEtE Qyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YWNjb3JkaW5nIHRvIHRo ZSByZXNwb25zZSBmcm9tIHRoZSBBUy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jmx0O21nbHQmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+JnF1b3Q7Y29udGludWUgdXNpbmcgYSBzZWN1cmUgY29tbXVuaWNh dGlvbiZxdW90OyBpcyBoZXJlIEk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+dGhpbmsgdG8gaW5kaWNhdGUgdGhhdCBlc3RhYmxpc2htZW50IG9m IGEgbmV3PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPnNlY3VyZSBjb21tdW5pY2F0aW9uIGlzIG5vdCBuZWNlc3NhcnkuJm5ic3A7IElmIHRoYXQg aXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Y29ycmVjdCwgd2Ugd2UgY291bGQgY2xhcmlmeSB0aGF0IGJ5IGFkZGluZyB0aGU8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Y29tbXVuaWNhdGlv biB0byB0aGUgQVMgaXMgc2VjdXJlZC4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbHQ7L21nbHQmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojOTkwMEZGIj5GUDogWWVzIHRoYXQgaXMgY29ycmVjdCwgdGhlIGpvaW5pbmcgbm9kZSBt YXkgY29udGludWUgdXNpbmcgYW4gZXhpc3Rpbmcgc2VjdXJpdHkgYXNzb2NpYXRpb24gd2l0aCB0 aGUgS0RDIGlmIGluc3RydWN0ZWQgYnkgQVMgKGRldGFpbHMgdXAgdG8gcHJvZmlsZXMpLiBJIGFt IG5vdCBzdXJlIEkgdW5kZXJzdGFuZA0KIHRoZSBjbGFyaWZpY2F0aW9uIHlvdSBhcmUgc3VnZ2Vz dGluZyB0aG91Z2g6IGhvdyB3b3VsZCBpdCBoZWxwIHRvIHdyaXRlIHRoYXQg4oCcam9pbmluZyBu b2RlLUFTIGNvbW11bmljYXRpb24gaXMgc2VjdXJl4oCdIHRvIGNsYXJpZnkgdGhhdCBqb2luaW5n IG5vZGUtS0RDIGNvbW11bmljYXRpb24gbWF5IHVzZSBhbiBleGlzdGluZyBzZWN1cmUgY2hhbm5l bD88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOzIuJm5ic3A7IFRoZSBqb2luaW5nIG5v ZGUgdHJhbnNmZXJzIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2luZm9ybWF0aW9uIHRvIHRoZSBLREMsIGJ5IHBv c3RpbmcgdGhlIG9idGFpbmVkIEFjY2VzcyBUb2tlbiB0bzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDt0aGUgL2F1dGh6LWluZm8gZW5kcG9pbnQgYXQgdGhlIEtEQy4mbmJz cDsgQWZ0ZXIgdGhhdCwgYSBqb2luaW5nIG5vZGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7TVVTVCBoYXZlIGEgc2VjdXJlIGNvbW11bmljYXRpb24gYXNzb2NpYXRpb24g ZXN0YWJsaXNoZWQgd2l0aCB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7S0RDLCBiZWZvcmUgc3RhcnRpbmcgdG8gam9pbiBhIGdyb3VwIHVuZGVyIHRoYXQgS0RDLiZu YnNwOyBQb3NzaWJsZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt3YXlz IHRvIHByb3ZpZGUgYSBzZWN1cmUgY29tbXVuaWNhdGlvbiBhc3NvY2lhdGlvbiBhcmUgRFRMUzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtbUkZDNjM0N10gYW5kIE9TQ09S RSBbUkZDODYxM10uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmx0 O21nbHQmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhlIHJl bGF0aW9uIGJldHdlZW4gdGhlIEtEQyAoYXBwbGljYXRpb24pIGFuZCB0aGU8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+c2VjdXJlIHRyYW5zcG9y dCBvciBjb21tdW5pY2F0aW9uIGlzIG5vdCBlbnRpb3JlbHk8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Y2xlYXIgdG8gbWUuJm5ic3A7IEEgc2Vj dXJlIGNvbW11bmljYXRpb24gaW5jbHVkZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+YXV0aGVudGljYXRpb24gb2YgdGhlIHBlZXJzIGFuZCBl bmNyeXB0aW9uIG9mIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj50cmFmZmljLiZuYnNwOyBJIHN1cHBvc2UgdGhhdCBlbmNyeXB0aW9uIGlz IHBlcmZvcm1lZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5ieSBEVExTIG9yIE9TQ09SRSwgYnV0IEkgYW0gd29uZGVyaW5nIGlmPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmF1dGhlbnRpY2F0 aW9uIGFuZCBhdXRob3JpemF0aW9uIGFyZSBwZXJmb3JtZWQgYnk8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+dGhlIERUTFMgbGF5ZXIgb3IgYnkg dGhlIEtEQyBhcHBsaWNhdGlvbi4mbmJzcDsgSSBoYXZlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPnRoZSBpbXByZXNzaW9uIHRoYXQgS0RDIGlz IGVudGlyZWx5IHJlbHlpbmcgb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+RFRMUy9PU0NPUkUgZm9yIGVuY3J5cHRpb24gYW5kPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmF1dGhlbnRpY2F0 aW9uL2F1dGhvcmlzYXRpb24gYmVjYXVzZSB0aGUgdGV4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5zZWVtcyB0byBhc3N1bWUgdGhhdCBhdXRo ei1pbmZvIG1heSBiZSBub3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+cHJvdGVjdGVkLiZuYnNwOyBJIHRodXMgYXNzdW1lIGF1dGhvcml6YXRp b24gaXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Y2hhcmFjdGVyaXplZCBieSB0aGUgYWJpbGl0eSB0byBzZXQgYSBEVExTL09TQ09SRTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5zZXNzaW9u LiZuYnNwOyBPZiBjb3Vyc2Ugb3RoZXIgaW5mb3JtYXRpb24gd2lsbCBiZTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5uZWVkZWQgYnkgdGhlIEtE QyAoc2NvcGUgZm9yIGV4YW1wZWwpLiZuYnNwOyBJZiB0aGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPnVzZSBjYXNlIG1ha2VzIHNlbnNlLCBp dCBtaWdodCBiZSBnb29kIHRvIGNsYXJpZnk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+dGhlIGludGVyYWN0aW9ucyBiZXR3ZWVuIGR0bHMtYXV0 aG9yaXplZCB3b3JrcywgaW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+cGFydGljdWxhciBob3cgdGhlc2UgYWNjZXNzIHRva2VucyAoIHRoZSBt ZXJnZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+YWNjZXNzIHRva2VuKSZuYnNwOyBhcmUvaXMgdXNlZC4mbmJzcDsgVGhlIG90aGVyIGFsdGVy bmF0aXZlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPmNvdWxkIGJlIHRvIHNldCBhbiB1bmF1dGhlbnRpY2F0ZWQgRFRMUy9PU0NPUkUgYW5kPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPnRoZW4g cHJvY2VlZCB0byB0aGUgY29tbXVuaWNhdGlvbiBvZiB0aGUgYWNjZXNzPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPnRva2VuLiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZsdDsvbWdsdCZndDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTAwRkYiPkZQOiBpdCdzIGVudGlyZWx5IHVw IHRvIHRoZSBzcGVjaWZpYyB1c2VkIHByb2ZpbGUgb2YgQUNFIHRvIGRlc2NyaWJlIGhvdyBhdXRo ZW50aWNhdGlvbiBhbmQgYXV0aG9yaXphdGlvbiBhcmUgZG9uZSwgdWx0aW1hdGVseSBsZXZlcmFn aW5nIGFuIEFjY2VzcyBUb2tlbiB3aXRoIGF1dGhvcml6YXRpb24gY3JlZGVudGlhbHMNCiB1c2Vk IGFsc28gdG8gZXN0YWJsaXNoIGEgc2VjdXJlIGNoYW5uZWwuIEZvciBleGFtcGxlLCB0aGUgT1ND T1JFIHByb2ZpbGUgZGVmaW5lcyBpdC4gSGVyZSB3ZSBtYWtlIHVzZSBvZiB0aGVzZSDigJx0cmFu c3BvcnTigJ0gcHJvZmlsZXMsIGFuZCB3ZSBzaG91bGQgbm90IHJlLXNwZWNpZnkgd2hhdCBpcyBh bHJlYWR5IGRlZmluZWQgdGhlcmUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5bIC4uLl08L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4zLiZuYnNwOyBBdXRob3JpemF0aW9uIHRvIEpvaW4g YSBHcm91cDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwO1RoaXMgc2VjdGlvbiBkZXNjcmliZXMgaW4gZGV0YWlsIHRoZSBmb3JtYXQgb2Yg bWVzc2FnZXMgZXhjaGFuZ2VkIGJ5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO3RoZSBwYXJ0aWNpcGFudHMgd2hl biBhIG5vZGUgcmVxdWVzdHMgYWNjZXNzIHRvIGEgZ3JvdXAuJm5ic3A7IFRoaXM8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7ZXhjaGFuZ2UgaXMgYmFzZWQgb24gQUNFIFtJLUQuaWV0Zi1hY2Utb2F1dGgtYXV0aHpd Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwO0FzIGRlZmluZWQgaW4gW0ktRC5pZXRmLWFjZS1vYXV0aC1hdXRoel0sIHRoZSBDbGllbnQg cmVxdWVzdHMgZnJvbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDt0aGUgQVMgYW4gYXV0aG9yaXphdGlvbiB0byBq b2luIHRoZSBncm91cCB0aHJvdWdoIHRoZSBLREMgKHNlZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtTZWN0aW9u IDMuMSkuJm5ic3A7IElmIHRoZSByZXF1ZXN0IGlzIGFwcHJvdmVkIGFuZCBhdXRob3JpemF0aW9u IGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwO2dyYW50ZWQsIHRoZSBBUyBwcm92aWRlcyB0aGUgQ2xpZW50IHdp dGggYSBwcm9vZi1vZi1wb3NzZXNzaW9uIGFjY2Vzczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDt0b2tlbiBhbmQg cGFyYW1ldGVycyB0byBzZWN1cmVseSBjb21tdW5pY2F0ZSB3aXRoIHRoZSBLREMgKHNlZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDtTZWN0aW9uIDMuMikuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Q29tbXVuaWNhdGlvbnMgYmV0d2VlbiB0aGUgQ2xp ZW50IGFuZCB0aGUgQVMgTVVTVCBiZSBzZWN1cmVkLCBhczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtkZWZpbmVk IGJ5IHRoZSB0cmFuc3BvcnQgcHJvZmlsZSBvZiBBQ0UgdXNlZC4mbmJzcDsgVGhlIENvbnRlbnQt Rm9ybWF0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwO3VzZWQgaW4gdGhlIG1lc3NhZ2VzIGlzIHRoZSBvbmUgc3Bl Y2lmaWVkIGJ5IHRoZSB1c2VkIHRyYW5zcG9ydDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtwcm9maWxlIG9mIEFD RSAoZS5nLiBhcHBsaWNhdGlvbi9hY2UmIzQzO2Nib3IgZm9yIHRoZSBmaXJzdCB0d28gbWVzc2Fn ZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7YW5kIGFwcGxpY2F0aW9uL2N3dCBmb3IgdGhlIHRoaXJkIG1lc3Nh Z2UsIGRlcGVuZGluZyBvbiB0aGUgZm9ybWF0IG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO3RoZSBhY2Nlc3Mg dG9rZW4pLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZsdDttZ2x0 Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkF0IHRoYXQgcG9p bnQsIEkgYXNzdW1lIHRoYXQgQ2xpZW50IHRvIEFTPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmNvbW11bmljYXRpb24gaXMgc2VjdXJlZCB2aWEg YSBzdGFuZGFyZCBEVExTPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPnNlc3Npb24uJm5ic3A7IEkgYW0gd29uZGVyaW5nIGlmIHRoZSBQT1NUIGNh biBiZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij51bnNlY3VyZWQgb3IgaXMgc2VuZCBvdmVyIGEgc2VjdXJlIGNoYW5uZWwuJm5ic3A7Jm5ic3A7 Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmx0Oy9tZ2x0 Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MDBGRiI+RlA6IFRoYXQg aXMgdXAgdG8gdGhlIHRyYW5zcG9ydCBwcm9maWxlIChEVExTIG9yIE9TQ09SRSBvciBhbnkgb3Ro ZXIgdXNlZCBwcm9maWxlKSB0byBkZWZpbmUuIFRoaXMgZG9jdW1lbnQgbGVhdmVzIHRoYXQgZGV0 YWlsIHRvIHRoZSBwcm9maWxlIHRvIGRlZmluZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5UaGUgdHJhbnNwb3J0IHByb2ZpbGUgb2YgQUNFIGFsc28gZGVmaW5lcyBh PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyZuYnNwO251bWJlciBvZiBkZXRhaWxzIHN1Y2ggYXMgdGhlIGNvbW11bmljYXRp b24gYW5kIHNlY3VyaXR5IHByb3RvY29sczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDt1c2VkIHdpdGggdGhlIEtE QyAoc2VlIEFwcGVuZGl4IEMgb2YgW0ktRC5pZXRmLWFjZS1vYXV0aC1hdXRoel0pLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO0ZpZ3Vy ZSAzIGdpdmVzIGFuIG92ZXJ2aWV3IG9mIHRoZSBleGNoYW5nZSBkZXNjcmliZWQgYWJvdmUuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Q2xpZW50Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFTJm5ic3A7IEtEQzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgfDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDt8LS0tLSBBdXRob3JpemF0aW9uIFJlcXVlc3Q6IFBPU1QgL3Rva2VuIC0tLS0tLSZn dDt8ICZuYnNwOyB8PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyB8PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3wmbHQ7LS0tIEF1dGhvcml6 YXRpb24gUmVzcG9uc2U6IDIuMDEgKENyZWF0ZWQpIC0tLXwgJm5ic3A7IHw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7 IHw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7fC0tLS0tIFBPU1QgVG9rZW46IFBPU1QgL2F1dGh6LWluZm8gLS0tLS0t LS0tLS0tLS0tJmd0O3w8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O0ZpZ3VyZSAzOiBNZXNzYWdlIEZsb3cgb2YgSm9pbiBBdXRob3JpemF0aW9uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+My4xLiZuYnNwOyBBdXRob3JpemF0aW9uIFJl cXVlc3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDtUaGUgQXV0aG9yaXphdGlvbiBSZXF1ZXN0IHNlbnQgZnJvbSB0aGUgQ2xpZW50IHRv IHRoZSBBUyBpcyBhczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtkZWZpbmVkIGluIFNlY3Rpb24gNS42LjEgb2Yg W0ktRC5pZXRmLWFjZS1vYXV0aC1hdXRoel0gYW5kIE1BWTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtjb250YWlu IHRoZSBmb2xsb3dpbmcgcGFyYW1ldGVycywgd2hpY2gsIGlmIGluY2x1ZGVkLCBNVVNUIGhhdmUg dGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwO2NvcnJlc3BvbmRpbmcgdmFsdWVzOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZsdDttZ2x0Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPkkgYmVsaWV2ZSB0aGF0IHNvbWUgcGFyYW1ldGVycyBhcmUg bWFuZGF0b3J5LiBJZjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj50aGF0IGlzIHRoZSBjYXNlLCBpdCB3b3VsZCBiZSBnb29kIHRvIGV4cGxhaW48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+d2hp Y2ggcGFyYW1ldGVycyBhcmUgb3B0aW9uYWwgb3IgbWFuZGF0b3J5LiZuYnNwOyZuYnNwOyZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZsdDsvbWdsdCZndDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MDBGRiI+RlA6IE5vdGhpbmcgaXMgbWFuZGF0b3J5LCBp dCBhbGwgZGVwZW5kcyBvbiB0aGUgc3BlY2lmaWMgdHJhbnNwb3J0IHByb2ZpbGUgKERUTFMsIE9T Q09SRSBldGMpIHVzZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7KiZuYnNwOyAnc2NvcGUnLCBjb250YWluaW5nIHRoZSBpZGVudGlm aWVyIG9mIHRoZSBzcGVjaWZpYyBncm91cChzKSwgb3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7dG9waWMocykgaW4gdGhlIGNhc2Ugb2YgcHViLXN1YiwgdGhhdCB0aGUgQ2xpZW50 IHdpc2hlcyB0byBhY2Nlc3MsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FuZCBv cHRpb25hbGx5IHRoZSByb2xlKHMpIHRoYXQgdGhlIENsaWVudCB3aXNoZXMgdG8gdGFrZS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPlBhbG9tYmluaSAmYW1wOyBUaWxvY2EmbmJzcDsgJm5ic3A7ICZuYnNw OyBFeHBpcmVzIDEyIE5vdmVtYmVyIDIwMjAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtQYWdlIDddPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+SW50ZXJuZXQtRHJhZnQmbmJzcDsgS2V5IFByb3Zpc2lvbmluZyBm b3IgR3JvdXAgQ29tbXVuaWNhdGlvbiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNYXkgMjAy MDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyB2 YWx1ZSBpcyBhIENCT1IgYnl0ZSBzdHJpbmcsIGVuY29kaW5nIGEgQ0JPUiBhcnJheSBvZiBvbmUg b3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bW9yZSBlbnRyaWVzLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZsdDttZ2x0Jmd0Ozwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmZyb20gdGhlIHRleHQgYWJvdmUgSSB1bmRl cnN0YW5kIHRoYXQgdGhlIHZhbHVlIGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPnRoZSBvdXRwdXQgb2YgYSBDQk9SIG9iamVjdCwgd2hpY2gg c29tZWhvdzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5yZXF1aXJlcyB0aGUgQ0JPUiBjb21wcmVzc2lvbiB0byBiZSBydW4gdHdpY2UuJm5ic3A7 IEk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ bWlnaHQgYmUgbWlzc2luZyBzb21ldGhpbmcsIGJ1dCBpdCBzZWVtcyB1bmNsZWFyPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPnRvIG1lIHdoeSB0 aGlzIHNob3VsZCBiZSBkaWZmZXJlbnQgZnJvbTogVGhpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj52YWx1ZSBpcyBhbiBhcnJheSBvZiBvbmUg b3IgbW9yZSBlbnRyaWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PlRoaXMgaXMgbXkgdW5kZXJzdGFuZGluZyBmcm9tIHRoZSB0ZXh0OiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5zY29wZSA9IFsgZW50 cnksIGVudHJ5IF08L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5lbnRy eSA9IFtncm91cF9pZCwgKFsgcm9sZSwgcm9sZSwgXSApXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbHQ7L21nbHQmZ3Q7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkwMEZGIj5GUDo8L3NwYW4+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkwMEZGIj5U aGUgcmVhc29uIGlzIHRoYXQsIGFjY29yZGluZyB0byB0aGUgQUNFIGZyYW1ld29yaywgdGhlIHNj b3BlIGhhcyB0byBiZSBlbmNvZGVkIGFzIGEgQ0JPUiB0ZXh0IHN0cmluZyBvciBhIENCT1IgYnl0 ZSBzdHJpbmcsIGFzIHZhbHVlIG9mIHRoZSAnc2NvcGUnIGZpZWxkIG9yIGNsYWltLiBUaGF0IG1l YW5zIHRoYXQgd2UgbmVlZCB0byBkbyB0aGlzDQogd3JhcHBpbmcuPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7QW4gZW50cnkgaGFzIGFzIHZhbHVlIGEgQ0JPUiBhcnJheSwgd2hpY2ggY29udGFpbnM6PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7LSZuYnNwOyBBcyBmaXJzdCBlbGVtZW50LCB0aGUgaWRlbnRpZmll ciBvZiB0aGUgc3BlY2lmaWMgZ3JvdXAgb3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dG9waWMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LSZuYnNwOyBP cHRpb25hbGx5LCBhcyBzZWNvbmQgZWxlbWVudCwgdGhlIHJvbGUgKG9yIENCT1IgYXJyYXkgb2Y8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7cm9sZXMp IHRoYXQgdGhlIENsaWVudCB3aXNoZXMgdG8gdGFrZSBpbiB0aGUgZ3JvdXAuJm5ic3A7IFRoaXM8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ZWxlbWVu dCBpcyBvcHRpb25hbCBzaW5jZSByb2xlcyBtYXkgaGF2ZSBiZWVuIHByZS1hc3NpZ25lZCB0bzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt0aGUgQ2xp ZW50LCBhcyBhc3NvY2lhdGVkIHRvIGl0cyB2ZXJpZmlhYmxlIGlkZW50aXR5PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2NyZWRlbnRpYWxzLiZuYnNw OyBBbHRlcm5hdGl2ZWx5LCB0aGUgYXBwbGljYXRpb24gbWF5IGhhdmUgZGVmaW5lZCBhPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3NpbmdsZSwgd2Vs bC1rbm93biByb2xlIGZvciB0aGUgdGFyZ2V0IHJlc291cmNlKHMpIGFuZDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDthdWRpZW5jZShzKS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtJbiBlYWNoIGVudHJ5LCB0aGUgZW5jb2Rpbmcgb2YgdGhlIGdyb3VwIG9y IHRvcGljIGlkZW50aWZpZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7KFJFUTEp IGFuZCBvZiB0aGUgcm9sZSBpZGVudGlmaWVycyAoUkVRMikgaXMgYXBwbGljYXRpb24gc3BlY2lm aWMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FuZCBwYXJ0IG9mIHRoZSByZXF1 aXJlbWVudHMgZm9yIHRoZSBhcHBsaWNhdGlvbiBwcm9maWxlLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZsdDttZ2x0Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPk1heWJlIGl0IHdvdWxkIHdvcnRoIHNwZWNpZnlpbmcgdGhlIHJl ZmVyZW5jZSB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+UkVRIHJlZmVyIHRvLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZsdDsvbWdsdCZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiM5OTAwRkYiPkZQOiBZZXMsIHdlIGhhdmUgYWRkZWQgdGhhdCByZWZlcmVuY2UgZm9yIHRo ZSBmaXJzdCBvY2N1cnJlbmNlIG9mIFJFUSBhbmQgT1BULjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPlsuLi5dPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+My4yLiZuYnNwOyBBdXRob3JpemF0aW9uIFJlc3BvbnNlPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIEF1dGhvcml6 YXRpb24gUmVzcG9uc2Ugc2VudCBmcm9tIHRoZSBBUyB0byB0aGUgQ2xpZW50IGlzIGFzPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwO2RlZmluZWQgaW4gU2VjdGlvbiA1LjYuMiBvZiBbSS1ELmlldGYtYWNlLW9hdXRo LWF1dGh6XSBhbmQgTVVTVDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtjb250YWluIHRoZSBmb2xsb3dpbmcgcGFy YW1ldGVyczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDsqJm5ic3A7ICdhY2Nlc3NfdG9rZW4nLCBjb250YWluaW5nIHRoZSBwcm9vZi1v Zi1wb3NzZXNzaW9uIGFjY2VzcyB0b2tlbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsqJm5ic3A7ICdjbmYnIGlmIHN5bW1ldHJpYyBr ZXlzIGFyZSB1c2VkLCBub3QgcHJlc2VudCBpZiBhc3ltbWV0cmljIGtleXM8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YXJlIHVzZWQuJm5ic3A7IFRoaXMgcGFyYW1ldGVyIGlzIGRl ZmluZWQgaW4gU2VjdGlvbiAzLjIgb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 W0ktRC5pZXRmLWFjZS1vYXV0aC1wYXJhbXNdIGFuZCBjb250YWlucyB0aGUgc3ltbWV0cmljIHBy b29mLW9mLTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwb3NzZXNzaW9uIGtleSB0 aGF0IHRoZSBDbGllbnQgaXMgc3VwcG9zZWQgdG8gdXNlIHdpdGggdGhlIEtEQy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsqJm5ic3A7 ICdyc19jbmYnIGlmIGFzeW1tZXRyaWMga2V5cyBhcmUgdXNlZCwgbm90IHByZXNlbnQgaWYgc3lt bWV0cmljPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2tleXMgYXJlIHVzZWQuJm5i c3A7IFRoaXMgcGFyYW1ldGVyIGlzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAzLjIgb2Y8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7W0ktRC5pZXRmLWFjZS1vYXV0aC1wYXJhbXNdIGFu ZCBjb250YWlucyBpbmZvcm1hdGlvbiBhYm91dCB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7cHVibGljIGtleSBvZiB0aGUgS0RDLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyombmJzcDsgJ2V4cGlyZXNfaW4nLCBj b250YWlucyB0aGUgbGlmZXRpbWUgaW4gc2Vjb25kcyBvZiB0aGUgYWNjZXNzPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Rva2VuLiZuYnNwOyBUaGlzIHBhcmFtZXRlciBNQVkgYmUg b21pdHRlZCBpZiB0aGUgYXBwbGljYXRpb24gZGVmaW5lczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtob3cgdGhlIGV4cGlyYXRpb24gdGltZSBpcyBjb21tdW5pY2F0ZWQgdG8gdGhl IENsaWVudCB2aWEgb3RoZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7bWVhbnMs IG9yIGlmIGl0IGVzdGFibGlzaGVzIGEgZGVmYXVsdCB2YWx1ZS48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtBZGRpdGlvbmFsbHksIHRo ZSBBdXRob3JpemF0aW9uIFJlc3BvbnNlIE1BWSBjb250YWluIHRoZSBmb2xsb3dpbmc8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7cGFyYW1ldGVycywgd2hpY2gsIGlmIGluY2x1ZGVkLCBNVVNUIGhhdmUgdGhlIGNv cnJlc3BvbmRpbmcgdmFsdWVzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwOyombmJzcDsgJ3Njb3BlJyBjb250YWluaW5nIHRoZSBncmFu dGVkIHNjb3BlLCBpZiBkaWZmZXJlbnQgZnJvbSB0aGUgc2NvcGU8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7cmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQuJm5ic3A7IFRoaXMgcGFyYW1l dGVyIGhhcyB0aGUgc2FtZSBmb3JtYXQgYW5kPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO2VuY29kaW5nIG9mICdzY29wZScgaW4gdGhlIEF1dGhvcml6YXRpb24gUmVxdWVzdCwgZGVm aW5lZCBpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtTZWN0aW9uIDMuMS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsq Jm5ic3A7IE90aGVyIGFkZGl0aW9uYWwgcGFyYW1ldGVycyBhcyBkZWZpbmVkIGluPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1tJLUQuaWV0Zi1hY2Utb2F1dGgtYXV0aHpdLCBpZiBu ZWNlc3NhcnkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7VGhlIHByb29mLW9mLXBvc3Nlc3Npb24gYWNjZXNzIHRva2VuIChpbiAnYWNj ZXNzX3Rva2VuJyBhYm92ZSkgTVVTVDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtjb250YWluIHRoZSBmb2xsb3dp bmcgcGFyYW1ldGVyczo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlBhbG9tYmluaSAmYW1wOyBU aWxvY2EmbmJzcDsgJm5ic3A7ICZuYnNwOyBFeHBpcmVzIDEyIE5vdmVtYmVyIDIwMjAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtQYWdlIDld PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SW50ZXJuZXQtRHJhZnQm bmJzcDsgS2V5IFByb3Zpc2lvbmluZyBmb3IgR3JvdXAgQ29tbXVuaWNhdGlvbiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBNYXkgMjAyMDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 KiZuYnNwOyBhIGNvbmZpcm1hdGlvbiBjbGFpbSAoc2VlIGZvciBleGFtcGxlICdjbmYnIGRlZmlu ZWQgaW4gU2VjdGlvbiAzLjE8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7b2YgW1JG Qzg3NDddIGZvciBDV1QpOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyombmJzcDsgYW4gZXhwaXJhdGlvbiB0aW1lIGNsYWltIChzZWUg Zm9yIGV4YW1wbGUgJ2V4cCcgZGVmaW5lZCBpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDtTZWN0aW9uIDMuMS40IG9mIFtSRkM4MzkyXSBmb3IgQ1dUKTs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsqJm5ic3A7IGEgc2Nv cGUgY2xhaW0gKHNlZSBmb3IgZXhhbXBsZSAnc2NvcGUnIHJlZ2lzdGVyZWQgaW4gU2VjdGlvbiA4 LjEzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO29mIFtJLUQuaWV0Zi1hY2Utb2F1 dGgtYXV0aHpdIGZvciBDV1QpLiZuYnNwOyBUaGlzIGNsYWltIGhhcyB0aGUgc2FtZTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtlbmNvZGluZyBhcyAnc2NvcGUnIHBhcmFtZXRlciBh Ym92ZS4mbmJzcDsgQWRkaXRpb25hbGx5LCB0aGlzIGNsYWltIGhhczwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDt0aGUgc2FtZSB2YWx1ZSBvZiB0aGUgJ3Njb3BlJyBwYXJhbWV0ZXIg aWYgdGhlIHBhcmFtZXRlciBpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwcmVz ZW50IGluIHRoZSBtZXNzYWdlLCBvciBpdCB0YWtlcyB0aGUgdmFsdWUgb2YgJ3Njb3BlJyBpbiB0 aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QXV0aG9yaXphdGlvbiBSZXF1ZXN0 IG90aGVyd2lzZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDtUaGUgYWNjZXNzIHRva2VuIE1BWSBhZGRpdGlvbmFsbHkgY29udGFpbiBv dGhlciBjbGFpbXMgdGhhdCB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7dHJhbnNwb3J0IHByb2ZpbGUgb2Yg QUNFIHJlcXVpcmVzLCBvciBvdGhlciBvcHRpb25hbCBwYXJhbWV0ZXJzLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO0FzIGluIFtJLUQu aWV0Zi1hY2Utb2F1dGgtYXV0aHpdLCB0aGVzZSBwYXJhbWV0ZXJzIGFyZSBpbmNsdWRlZCBpbjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDt0aGUgcGF5bG9hZCwgd2hpY2ggaXMgZm9ybWF0dGVkIGFzIGEgQ0JPUiBt YXAuJm5ic3A7IFRoZSBDb250ZW50LUZvcm1hdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmcXVvdDthcHBsaWNh dGlvbi9hY2UmIzQzO2Nib3ImcXVvdDsgaXMgdXNlZC48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtXaGVuIHJlY2VpdmluZyBhbiBBdXRo b3JpemF0aW9uIFJlcXVlc3QgZnJvbSBhIENsaWVudCB0aGF0IHdhczwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtw cmV2aW91c2x5IGF1dGhvcml6ZWQsIGFuZCBmb3Igd2hpY2ggdGhlIEFTIHN0aWxsIG93bnMgYSB2 YWxpZCBub248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ZXhwaXJlZCBhY2Nlc3MgdG9rZW4sIHRoZSBBUyBNQVkg cmVwbHkgd2l0aCB0aGF0IHRva2VuLiZuYnNwOyBOb3RlIHRoYXQgaXQ8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 aXMgdXAgdG8gYXBwbGljYXRpb24gcHJvZmlsZXMgb2YgQUNFIHRvIG1ha2Ugc3VyZSB0aGF0IHJl LXBvc3RpbmcgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO3NhbWUgdG9rZW4gZG9lcyBub3QgY2F1c2UgcmUt dXNlIG9mIGtleWluZyBtYXRlcmlhbCBiZXR3ZWVuIG5vZGVzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyhmb3Ig ZXhhbXBsZSwgdGhhdCBpcyBkb25lIHdpdGggdGhlIHVzZSBvZiByYW5kb20gbm9uY2VzIGluPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwO1tJLUQuaWV0Zi1hY2Utb3Njb3JlLXByb2ZpbGVdKS48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZsdDttZ2x0Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkg YW0gd29uZGVyaW5nIGlmIGl0IGlzIGV4cGVjdGVkIHRoZSBjbGllbnQgcmVhZHM8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+dGhlIHZhbHVlcyBj b250YWluZWQgaW4gdGhlIGFjY2Vzc190b2tlbi4mbmJzcDsgSTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5zdXBwb3NlIG5vdCwgYW5kIGV2ZW4g d2hlbiB0aGUgYWNjZXNfdG9rZW4gaXMgbm90PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmVuY3J5cHRlZCB0aGUgY2xpZW50IGlzIHN1cHBvc2Vk IHRvIHBhc3MgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPmFjY2VzcyB0b2tlbiBhcyBvcGFxdWUgZGF0YSB0byB0aGUgS0RDLiZuYnNwOyBJ cyB0aGF0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPmNvcnJlY3QgPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkkg YW0gYWxzbyB3b25kZXJpbmcgaG93IHRoZSBBUyBjb3VsZCBpbmZvcm0gd2hpY2g8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+dHJhbnNwb3J0IGFy ZSBhdmFpbGFibGUgdG8gdGhlIEtEQy4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5XaGF0IGlzIGEgbGl0dGxlIGJpdCB1bmNsZWFyIHRvIG1lIGlzIHdoZW4g dGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PmFjY2VzcyB0b2tlbiBpcyBjb21iaW5lZCB3aXRoIGFub3RoZXIgYWNjZXNzIHRva2VuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmZyb20gdGhl IHRyYW5zcG9ydCBsYXllci4gSSBzdXBwb3NlIHRoYXQgdGhlIHR3bzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj50b2tlbnMgYXJlICZxdW90O21l cmdlZCZxdW90OyBpbiBzb21lIHdheXMgYW5kIEkgYW08L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+d29uZGVyaW5nIGlmIHRoZSB0cmFuc3BvcnQg YWNjZXNzIHRva2VuIGlzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPmV4cGVjdGVkIHRvIGluY2x1ZGUgdGhvc2Ugb2YgdGhlIHVwcGVyIGxheWVy cyBpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5vdXIgY2FzZSB0aGUgS0RDLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZsdDsvbWdsdCZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM5OTAwRkYiPkZQOjwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTAwRkYiPkFzIGRlZmluZWQgaW4gQUNFLCB0aGUg dG9rZW4gaXMgb3BhcXVlIHRvIHRoZSBjbGllbnQsIHdoaWNoIGRvZXMgbm90IHVuZGVyc3RhbmQg YSBiaXQgb2YgaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkwMEZGIj5B bHNvLCB0aGUgdHJhbnNwb3J0IGF2YWlsYWJsZSB0byB0aGUgS0RDIGlzIGRlZmluZWQgaW4gdGhl IHRyYW5zcG9ydCBwcm9maWxlLiBFaXRoZXIgdGhlIHByb2ZpbGUgaXMga25vd24gaW4gYWR2YW5j ZSBieSB0aGUgY2xpZW50LCBvciB0aGUgQVMgc2lnbmFscyBpdCBpbiB0aGUgdG9rZW4gcmVzcG9u c2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkwMEZGIj5BYm91dCBtZXJn aW5nIHRoZSDigJx0cmFuc3BvcnTigJ0gdG9rZW4gYW5kIHRoZSDigJx1cHBlciBsYXllcuKAnSB0 b2tlbiwgSSBhbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQsIGFzIHRoaXMgaXMgZXhhY3RseSB0aGUg 4oCcdHJhbnNwb3J04oCdIHRva2VuLiBUaGlzIGlzIHRoZSB0b2tlbiB1c2VkIHRvIGVzdGFibGlz aCBhIHNlY3VyZQ0KIGNvbm5lY3Rpb24gYmV0d2VlbiBDbGllbnQgYW5kIEtEQy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjMuMy4mbmJzcDsgVG9rZW4gUG9zdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO1RoZSBDbGllbnQgc2VuZHMgYSBDb0FQ IFBPU1QgcmVxdWVzdCBpbmNsdWRpbmcgdGhlIGFjY2VzcyB0b2tlbiB0bzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDt0aGUgS0RDLCBhcyBzcGVjaWZpZWQgaW4gU2VjdGlvbiA1LjguMSBvZiBbSS1ELmlldGYtYWNl LW9hdXRoLWF1dGh6XS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7SWYgdGhlIHNwZWNpZmljIHRyYW5zcG9ydCBw cm9maWxlIG9mIEFDRSBkZWZpbmVzIGl0LCB0aGUgQ2xpZW50IE1BWTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDt1 c2UgYSBkaWZmZXJlbnQgZW5kcG9pbnQgdGhhbiAvYXV0aHotaW5mbyBhdCB0aGUgS0RDIHRvIHBv c3QgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwO2FjY2VzcyB0b2tlbiB0by48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbHQ7bWdsdCZndDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5JIHRoaW5rIHRoZSBvdmVydmlldyBzZWN0aW9uIG1lbnRpb25z PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmFw cGxpY2F0aW9uL2N3dCBpcyB1c2VkIGZvciB0aGF0IGV4Y2hhbmdlLiZuYnNwOyBJPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPnRoaW5rIGl0IG1p Z2h0IGJlIGhlbHBmdWwgdG8gc3BlY2lmeSB0aGF0IHBvc3Q8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+dXNlcyBhcHBsaWNhdGlvbi9jd3Qgc2lu Y2UgbGF0ZXIgd2UgaW5kaWNhdGUgdGhhdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5hcHBsaWNhdGlvbi9hY2UmIzQzO2Nib3IgbWF5IGNhcnJ5 IGFub3RoZXIgbWVhbmluZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+SXQgbWlnaHQgd29ydGggdXBkYXRpbmcgdGhpcyBzZWN0aW9uIGFzIHdl bGwuJm5ic3A7Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ SSBhbHNvIGhhdmUgdGhlIGltcHJlc3Npb24gdGhhdCB0aGUgcmVzcG9uc2UgdG88L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+dGhlIHBvc3QgaXMg Y2FsbGVkICZxdW90O0FTIFJlcXVlc3QgQ3JlYXRpb24gSGludHMmcXVvdDsuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPklmIHRoYXQgaXMgY29y cmVjdCwgdGhlIGRlc2lnbmF0aW9uIGlzIG1pc2xlYWRpbmcsPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmFzIGhpbnRzIGFyZSBub3QgdGFyZ2V0 aW5nIHRoZSBBUyBpbiB0aGUgY2FzZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+TWF5YmUgdGhhdCB3b3VsZCBiZSBnb29kIHRvIGluZGljYXRl IHRoaXMgaXMgdGhpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5leGNoYW5nZSB0aGF0IGlzIGJlaW5nIGNvbnNpZGVyZWQgd2l0aCBhIGRpZmZl cmVudDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5tZWFuaW5nIGFzIGl0IGhhcyBiZWVuIGRlZmluZWQgaW4gdGhlIGZyYW1ld29yay48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SWYgdGhhdCBp cyBzdGlsbCBjb3JyZWN0LCBJIGFtIHdvbmRlcmluZyBob3cgdGhlPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmNsaWVudCBjYW4gbWFrZSBhIGRp ZmZlcmVuY2UgYmV0d2VlbiB0aGUgQVM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+UmVxdWVzdCBDcmVhdGlvbiBIaW50cyBhcyBhIFJlc3BvbnNl IHRoYXQgcHJvdmlkZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+YWRkaXRpb25hbCBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIHRoZSBncm91cDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5jb21t dW5pY2F0aW9uLiZuYnNwOyBJbiBwYXJ0aWN1bGFyIEkgYW0gd29uZGVyaW5nIGlmPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPnBhcmFtZXRlcnMg YXJlIHVzZWQgdG8gZGlzdGluZ3Vpc2ggdGhlc2UgdHdvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPnJlc3BvbnNlcy4mbmJzcDsmbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbHQ7L21nbHQmZ3Q7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkwMEZGIj5GUDo8L3NwYW4+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkw MEZGIj5UaGUgY29udGVudCBmb3JtYXQgYXBwbGljYXRpb24vY3d0IGlzIGludGVuZGVkIHRvIHN1 Ym1pdCB0aGUgYWNjZXNzIHRva2VuIGFsb25lLCBhbmQgbm90aGluZyBlbHNlLiBUaGlzIGlzIHN0 aWxsIGEgcG9zc2libGUgdmFsaWQgb3B0aW9uLCBlLmcuIHdoZW4gdXNpbmcgdGhlIERUTFMgcHJv ZmlsZSBhbmQgdGhlIGNsaWVudCBkb2VzIG5vdCBpbmNsdWRlDQogYW55IHBhcmFtZXRlciBmb3Ig YXNraW5nIHdoYXQgYWxnb3JpdGhtcyBhcmUgdXNlZCBpbiB0aGUgZ3JvdXAuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkwMEZGIj5Gb3IgdGhlIEFTIFJlcXVlc3QgQ3JlYXRp b24gSGludHM6IGdvb2QgcG9pbnQsIEkgaGFkIGFscmVhZHkgdGFrZW4gY2FyZSBvZiBhIHNpbWls YXIgcG9pbnQgaW4gdGhlIE9TQ09SRSBwcm9maWxlLCB3aGVyZSBvdGhlciBwYXJhbWV0ZXJzIHdl cmUgcmVnaXN0ZXJlZCB0byBiZSB1c2VkIGluIHRoZSBUb2tlbg0KIFJlc3BvbnNlIGFzIEFTIFJl cXVlc3QgSGludHMuIE5vdyB0aGV5IGFyZSByZWdpc3RlcmVkIGluIHRoZSBPQXV0aCBQYXJhbWV0 ZXJzIFJlZ2lzdHJ5IChhbmQgTWFwcGluZykuIFdlIGhhdmUgZm9sbG93ZWQgdGhhdCBmb3IgdGhl IHBhcmFtZXRlcnMgcmVnaXN0ZXJlZCBoZXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7T3B0aW9uYWxseSwgdGhlIENsaWVudCBtaWdodCB3YW50IHRvIHJlcXVlc3QgbmVj ZXNzYXJ5IGluZm9ybWF0aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO2NvbmNlcm5pbmcgdGhlIHB1YmxpYyBr ZXlzIGluIHRoZSBncm91cCwgYXMgd2VsbCBhcyBjb25jZXJuaW5nIHRoZTwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDthbGdvcml0aG0gYW5kIHJlbGF0ZWQgcGFyYW1ldGVycyBmb3IgY29tcHV0aW5nIHNpZ25hdHVy ZXMgaW4gdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO2dyb3VwLiZuYnNwOyBJbiBzdWNoIGEgY2FzZSwgdGhl IGpvaW5pbmcgbm9kZSBNQVkgYXNrIGZvciB0aGF0IGluZm9ybWF0aW9uPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw O3RvIHRoZSBLREMgaW4gdGhpcyBzYW1lIHJlcXVlc3QuJm5ic3A7IFRvIHRoaXMgZW5kLCBpdCBz ZW5kcyB0aGUgQ29BUCBQT1NUPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO3JlcXVlc3QgdG8gdGhlIC9hdXRoei1p bmZvIGVuZHBvaW50IHVzaW5nIHRoZSBDb250ZW50LUZvcm1hdDwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmcXVv dDthcHBsaWNhdGlvbi9hY2UmIzQzO2Nib3ImcXVvdDsuJm5ic3A7IFRoZSBwYXlsb2FkIG9mIHRo ZSBtZXNzYWdlIE1VU1QgYmUgZm9ybWF0dGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO2FzIGEgQ0JPUiBtYXAs IGluY2x1ZGluZyB0aGUgYWNjZXNzIHRva2VuIGFuZCB0aGUgZm9sbG93aW5nPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwO3BhcmFtZXRlcnM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7KiZuYnNwOyAnc2lnbl9pbmZvJyBkZWZpbmVkIGluIFNlY3Rpb24g My4zLjEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5QYWxvbWJpbmkgJmFtcDsgVGlsb2NhJm5i c3A7ICZuYnNwOyAmbmJzcDsgRXhwaXJlcyAxMiBOb3ZlbWJlciAyMDIwICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBbUGFnZSAxMF08L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JbnRlcm5ldC1EcmFmdCZuYnNwOyBLZXkgUHJv dmlzaW9uaW5nIGZvciBHcm91cCBDb21tdW5pY2F0aW9uJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IE1heSAyMDIwPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsqJm5ic3A7ICdwdWJf a2V5X2VuYycgZGVmaW5lZCBpbiBTZWN0aW9uIDMuMy4yLCBlbmNvZGluZyB0aGUgQ0JPUiBzaW1w bGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7dmFsdWUgTnVsbCwgdG8gcmVxdWly ZSBpbmZvcm1hdGlvbiBvbiB0aGUgZXhhY3QgZW5jb2Rpbmcgb2YgcHVibGljPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO2tleXMgdXNlZCBpbiB0aGUgZ3JvdXAuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7QWx0ZXJuYXRp dmVseSwgdGhlIGpvaW5pbmcgbm9kZSBtYXkgcmV0cmlldmUgdGhpcyBpbmZvcm1hdGlvbiBieTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDtvdGhlciBtZWFucy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtBZnRlciBzdWNjZXNzZnVsIHZlcmlmaWNhdGlv biwgdGhlIENsaWVudCBpcyBhdXRob3JpemVkIHRvIHJlY2VpdmU8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbHQ7bWdsdCZndDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5JIGFtIHdvbmRlcmluZyBpZiB0aGUgdmVyaWZpY2F0aW9uIGdv ZXMgYmV5b25kIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj5zaWduYXR1cmUgdmFsaWRhdGlvbi4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhlIHJlbWFpbmluZyBvZiB0aGUg dGV4dCBzZWVtcyBhbHNvIHRvIGFzc3VtZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj50aGF0IGFjZSYjNDM7Y2JvciBpcyB1c2VkLiBJcyB0aGF0 IGNvcnJlY3QgPyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiZsdDsvbWdsdCZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTAwRkYi PkZQOjwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiM5OTAwRkYiPlRoZSB2ZXJpZmljYXRpb24gZ29lcyBsaWtlIGZvciBh bnkgb3RoZXIgdG9rZW5zIHRoZSBSUyB3b3VsZCByZWNlaXZlIGZyb20gdGhhdCBBUy4gT2YgY291 cnNlIHRoZSBSUyB1bmRlcnN0YW5kcyB0aGUgaW5kaWNhdGVkIHNjb3BlLCBhbmQgY2hlY2tzIGl0 IHRvIGJlIG1lYW5pbmdmdWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkw MEZGIj5PbiB0aGUgc2Vjb25kIHBhcnQsIGRldGFpbHMgY29tZSBsYXRlciBvbjo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkwMEZGIj4tIEEgc3VjY2Vz c2Z1bCByZXNwb25zZSBmcm9tIC9hdXRoei1pbmZvIGhhcyBjdD1hcHBsaWNhdGlvbi9hY2UmIzQz O2Nib3I8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkw MEZGIj4tIFRoZSBKb2luaW5nIFJlcXVlc3QgdG8gdGhlIEtEQyBoYXMgY3Q9YXBwbGljYXRpb24v YWNlLWdyb3VwY29tbSYjNDM7Y2Jvcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM5OTAwRkYiPi0gVGhlIHN1Y2Nlc3NmdWwgSm9pbmluZyBSZXNwb25zZSBm cm9tIHRoZSBLREMgaGFzIGN0PWFwcGxpY2F0aW9uL2FjZS1ncm91cGNvbW0mIzQzO2Nib3I8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkwMEZGIj4tIEFu IGVycm9yIHJlc3BvbnNlIGZyb20gdGhlIEtEQyBmb2xsb3dpbmcgdGhlIEpvaW5pbmcgUmVxdWVz dCBoYXMgY3Q9YXBwbGljYXRpb24vYWNlJiM0MztjYm9yPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MDBGRiI+VGhhdCBpcyBhbHJlYWR5IGRlZmluZWQg aW4gZWFjaCBzcGVjaWZpYyBzZWN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 dGhlIGdyb3VwIGtleWluZyBtYXRlcmlhbCBmcm9tIHRoZSBLREMgYW5kIGpvaW4gdGhlIGdyb3Vw LiZuYnNwOyBJbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtwYXJ0aWN1bGFyLCB0aGUgS0RDIHJlcGxpZXMgdG8g dGhlIENsaWVudCB3aXRoIGEgMi4wMSAoQ3JlYXRlZCk8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVzcG9uc2Us IHVzaW5nIENvbnRlbnQtRm9ybWF0ICZxdW90O2FwcGxpY2F0aW9uL2FjZSYjNDM7Y2JvciZxdW90 OyBkZWZpbmVkIGluPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO1NlY3Rpb24gOC4xNCBvZiBbSS1ELmlldGYtYWNl LW9hdXRoLWF1dGh6XS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDtUaGUgcGF5bG9hZCBvZiB0aGUgMi4wMSByZXNwb25zZSBpcyBhIENC T1IgbWFwLiZuYnNwOyBJZiB0aGUgYWNjZXNzIHRva2VuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO2NvbnRhaW5z IGEgcm9sZSB0aGF0IHJlcXVpcmVzIHRoZSBDbGllbnQgdG8gc2VuZCBpdHMgb3duIHB1YmxpYyBr ZXk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7dG8gdGhlIEtEQyB3aGVuIGpvaW5pbmcgdGhlIGdyb3VwLCB0aGUg Q0JPUiBtYXAgTVVTVCBpbmNsdWRlIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtwYXJhbWV0ZXIgJ2tkY2No YWxsZW5nZScgZGVmaW5lZCBpbiBTZWN0aW9uIFNlY3Rpb24gMy4zLjMsIHNwZWNpZnlpbmc8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7YSBkZWRpY2F0ZWQgY2hhbGxlbmdlIE5fUyBnZW5lcmF0ZWQgYnkgdGhlIEtE Qy4mbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m bHQ7bWdsdCZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JIGFt IHdvbmRlcmluZyBob3cgdGhlIGNsaWVudCBwcm92aWRlcyB0aGUgcHVibGljPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmtleSwgYW5kIEkgYW0g d29uZGVyaW5nIGlmIHRoZSBwdWJsaWMga2V5IGlzIG5vdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5wcm92aWRlZCB0aHJvdWdoIHRoZSBhY2Nl c3NfdG9rZW4gdG8gdGhlIEtEQy4mbmJzcDsgSWY8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+dGhhdCB3b3VsZCBiZSBjb3JyZWN0LCBpdCBzZWVt cyB0aGVuIHRoYXQgdGhlIGtleTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5pcyBwcm92aWRlZCBieSB0aGUgQVMgb3IgdGhlIGFjY2VzcyB0b2tl biBpbnN0ZWFkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPm9mIHRoZSBjbGllbnQuJm5ic3A7IE1heWJlIHRoZSBwdWJsaWMga2V5cyBhcmUgdGhv c2Ugb2Y8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+dGhlIG1lbWJlcnMgb2YgdGhlIGdyb3VwLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPiZsdDsvbWdsdCZndDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM5OTAwRkYiPkZQOjwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTAwRkYiPkFzIGEgZ2VuZXJhbCBj YXNlLCB0aGUgcHVibGljIGtleSBpcyBwcm92aWRlZCBpbiB0aGUgSm9pbmluZyBSZXF1ZXN0IGJ5 IHRoZSBjbGllbnQgaXRzZWxmLCB3aXRoIHRoZSBwYXJhbWV0ZXIgJ2NsaWVudF9jcmVkJy48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTAwRkYiPlRoZSBLREMgbWlnaHQgYWxy ZWFkeSBoYXZlIGEgdmFsaWQgcHVibGljIGtleSBvZiB0aGUgY2xpZW50LCBmcm9tIHByZXZpb3Vz IGludGVyYWN0aW9ucywgc28gdGhhdCB0aGUgY2xpZW50IGRvZXMgbm90IG5lZWQgdG8gcG9zdCBp dCBhZ2Fpbi4gT25lIHBhcnRpY3VsYXIgY2FzZSwgYXMgYW4gZXhhbXBsZSBvZg0KIHRoaXMsIGlz IHVzaW5nIHRoZSBEVExTIHByb2ZpbGUgaW4gYXN5bW1ldHJpYyBtb2RlLCB3aXRoIHRoZSB0b2tl biBpbmNsdWRpbmcgdGhlIHB1YmxpYyBrZXkgb2YgdGhlIGNsaWVudC4gQnV0IHRoaXMgaXMgbm90 IHRoZSBnZW5lcmFsIGNhc2UgdGhhdCB0aGlzIChwYXJ0IG9mIHRoZSkgZG9jdW1lbnQgZGVmaW5l cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTAwRkYiPlllcywgdGhlIHB1 YmxpYyBrZXlzIG1lbnRpb25lZCBoZXJlIGFyZSB0aG9zZSBvZiB0aGUgbWVtYmVycyBvZiB0aGUg Z3JvdXAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7VGhlIENsaWVudCB1c2VzIHRoaXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Y2hhbGxlbmdlIHRv IHByb3ZlIHBvc3Nlc3Npb24gb2YgaXRzIG93biBwcml2YXRlIGtleSAoc2VlIHRoZTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsnY2xpZW50X2NyZWRfdmVyaWZ5JyBwYXJhbWV0ZXIgaW4gU2VjdGlvbiA0KS4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbHQ7bWdsdCZndDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JIGhhdmUgbm90IHlldCBy ZWFkIHNlY3Rpb24gNCwgYnV0IGl0IHNlZW1zIHRoYXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+YWRkaXRpb25hbCBleGNoYW5nZXMgYXJlIHBl cmZvcm1lZCB0aGF0IGdvZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+YmV5b25kIHRoZSBUb2tlbiBwb3N0IGV4Y2hhbmdlLiZuYnNwOyBJZiBt eTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj51 bmRlcnN0YW5kaW5nIGlzIGNvcnJlY3QsIEkgYW0gd29uZGVyaW5nIGlmIHRoYXQ8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ZGVzY3JpcHRpb24g Zml0cyB0aGUgdGl0bGUgb2YgdGhpcyBzZWN0aW9uLiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZsdDsvbWdsdCZndDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM5OTAwRkYiPkZQOjwvc3Bhbj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTAwRkYiPlllcywgc29tZSBh ZGRpdGlvbmFsIHByb2Nlc3NpbmcgdGhhbiB0aGUgdXN1YWwgQWNlIFRva2VuIFBvc3QgZXhjaGFu Z2UgcHJvY2Vzc2luZyBpcyBkZWZpbmVkLCB0aGF0IHdpbGwgYmUgc3BlY2lmaWVkIGluIHRoZSBK b2luaW5nIGV4Y2hhbmdlLiBJZiB5b3UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIHRpdGxlIG9mIHRo aXMgc2VjdGlvbiwgdGhpcw0KIGlzIHN0aWxsIFRva2VuIFBvc3QgZXhjaGFuZ2UsIHdlIG9ubHkg aW50cm9kdWNlIHRoZSBob29rcyB0aGF0IGFyZSBuZWVkZWQgZm9yIGZ1cnRoZXIgcHJvY2Vzc2lu Zy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5Ob3RlIHRoYXQgdGhl IHBheWxvYWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Zm9ybWF0IG9mIHRoZSByZXNwb25zZSBkZXZpYXRlcyBm cm9tIHRoZSBkZWZhdWx0IGFzIGRlZmluZWQgaW4gdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO0FDRSBmcmFt ZXdvcmsgKHNlZSBTZWN0aW9uIDUuOC4xIG9mIFtJLUQuaWV0Zi1hY2Utb2F1dGgtYXV0aHpdKS48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDtUaGUgS0RDIE1VU1Qgc3RvcmUgdGhlICdrZGNjaGFsbGVuZ2UnIHZhbHVlIGFzc29jaWF0ZWQg dG8gdGhlIENsaWVudDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDthdCBsZWFzdCB1bnRpbCBpdCByZWNlaXZlcyBh IGpvaW4gcmVxdWVzdCBmcm9tIGl0IChzZWUgU2VjdGlvbiA0LjIpLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDt0 byBiZSBhYmxlIHRvIHZlcmlmeSB0aGUgcHJvb2Ygb2YgcG9zc2Vzc2lvbi4mbmJzcDsgVGhlIHNh bWUgY2hhbGxlbmdlIE1BWTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtiZSByZXVzZWQgc2V2ZXJhbCB0aW1lcyBi eSB0aGUgQ2xpZW50LCB0byBnZW5lcmF0ZSBuZXcgcHJvb2Ygb2Y8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7cG9z c2Vzc2lvbnMsIGUuZy4gaW4gY2FzZSBvZiB1cGRhdGUgb2YgdGhlIHB1YmxpYyBrZXksIG9yIHRv IGpvaW4gYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtkaWZmZXJlbnQgZ3JvdXAgd2l0aCBhIGRpZmZlcmVudCBr ZXksIHNvIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO0tEQyBrZWVw cyBzdG9yaW5nIHRoZSAna2RjY2hhbGxlbmdlJyBhZnRlciB0aGUgZmlyc3Qgam9pbiBpczwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDtwcm9jZXNzZWQgYXMgd2VsbC4mbmJzcDsgSWYgdGhlIEtEQyBoYXMgYWxyZWFk eSBkaXNjYXJkZWQgdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOydrZGNjaGFsbGVuZ2UnLCB0aGF0IHdpbGwg dHJpZ2dlciBhbiBlcnJvciByZXNwb25zZSB3aXRoIGEgbmV3bHk8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Z2Vu ZXJhdGVkICdrZGNjaGFsbGVuZ2UnIHRoYXQgdGhlIGNsaWVudCBjYW4gdXNlIHRvIHJlc3RhcnQg dGhlIGpvaW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7cHJvY2VzcywgYXMgc3BlY2lmaWVkIGluIFNlY3Rpb24g NC4yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwO0lmIGVpdGhlciBvZiAnc2lnbl9pbmZvJyBvciAncHViX2tleV9lbmMnIHdlcmUgaW5j bHVkZWQgaW4gdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO3JlcXVlc3QsIHRoZSBLREMgTUFZIGluY2x1ZGUg dGhlICdzaWduX2luZm8nIHBhcmFtZXRlciBkZWZpbmVkIGluPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO1NlY3Rp b24gMy4zLjEsIG9wdGlvbmFsbHkgaW5jbHVkaW5nIHRoZSAncHViX2tleV9lbmMnIHBhcmFtZXRl cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDtTZWN0aW9uIDMuMy4yLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO1RoZSAnc2lnbl9pbmZvJyBwYXJhbWV0 ZXIgTVVTVCBiZSBwcmVzZW50IGlmIHRoZSBQT1NUIHJlcXVlc3Q8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7aW5j bHVkZWQgdGhlICdzaWduX2luZm8nIHBhcmFtZXRlciBhbmQvb3IgdGhlIHB1Yl9rZXlfZW5jIHdp dGggdmFsdWU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7TnVsbC4mbmJzcDsgVGhlIGVuY29kaW5nIG9mIHRoZSAn c2lnbl9pbmZvJyBwYXJhbWV0ZXIgaW4gdGhlIHJlc3BvbnNlIGlzPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO2Rl ZmluZWQgaW4gU2VjdGlvbiAzLjMuMi4mbmJzcDsgTm90ZSB0aGF0IHRoZSBmaWVsZCAnaWQnIHRh a2VzIHRoZSB2YWx1ZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtvZiB0aGUgZ3JvdXAgaWRlbnRpZmllciBmb3Ig d2hpY2ggdGhlICdzaWduX2luZm8nIGFwcGxpZXMgdG8sIGluIHRoaXM8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 c3BlY2lmaWNhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlBhbG9tYmluaSAm YW1wOyBUaWxvY2EmbmJzcDsgJm5ic3A7ICZuYnNwOyBFeHBpcmVzIDEyIE5vdmVtYmVyIDIwMjAg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtQYWdlIDEx XTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkludGVybmV0LURyYWZ0 Jm5ic3A7IEtleSBQcm92aXNpb25pbmcgZm9yIEdyb3VwIENvbW11bmljYXRpb24mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgTWF5IDIwMjA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNw O05vdGUgdGhhdCB0aGUgQ0JPUiBtYXAgc3BlY2lmaWVkIGFzIHBheWxvYWQgb2YgdGhlIDIuMDEg KENyZWF0ZWQpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO3Jlc3BvbnNlIG1heSBpbmNsdWRlIGZ1cnRoZXIgcGFy YW1ldGVycywgZS5nLiBhY2NvcmRpbmcgdG8gdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO3NpZ25hbGxlZCB0 cmFuc3BvcnQgcHJvZmlsZSBvZiBBQ0UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7QXBwbGljYXRpb25zIG9mIHRoaXMgc3BlY2lmaWNh dGlvbiBNQVkgZGVmaW5lIGFsdGVybmF0aXZlIHNwZWNpZmljPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO25lZ290 aWF0aW9ucyBvZiBwYXJhbWV0ZXIgdmFsdWVzIGZvciBzaWduYXR1cmUgYWxnb3JpdGhtIGFuZDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsmbmJzcDtzaWduYXR1cmUga2V5cywgaWYgJ3NpZ25faW5mbycgYW5kICdwdWJfa2V5 X2VuYycgYXJlIG5vdCB1c2VkIChPUFQyKS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4zLjMuMS4mbmJzcDsgJ3NpZ25faW5mbycgUGFyYW1ldGVyPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlICdzaWdu X2luZm8nIHBhcmFtZXRlciBpcyBhbiBPUFRJT05BTCBwYXJhbWV0ZXIgb2YgdGhlIEFTIFJlcXVl c3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Q3JlYXRpb24gSGludHMgbWVzc2FnZSBkZWZpbmVkIGluIFNlY3Rp b24gNS4xLjIuIG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO1tJLUQuaWV0Zi1hY2Utb2F1dGgtYXV0aHpdLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZsdDttZ2x0Jmd0Ozwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoZSB0ZXh0IGNhbiBiZSByZWFk IGFzICdzaWduX2luZm8nIGlzIGRlZmluZWQgaW48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+U2VjdGlvbiA1LjEuMi4mbmJzcDsgSSBiZWxpZXZl IHRoYXQgY2xhcmlmeWluZyB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+cmVzcG9uc2UgaXMgZGVzaWduYXRlZCBpbiB0aGUgZnJhbWV3b3Jr IGFzIEFTPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPlJlcXVlc3QgQ3JlYXRpb24gSGludHMgYnV0IGhhcyBhIGRpZmZlcmVudCBtZWFuaW5nPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmhlcmUg bWF5IHNvbHZlIHRoaXMgaXNzdWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jmx0Oy9tZ2x0Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5 MDBGRiI+RlA6Jm5ic3A7WWVzLCB3ZSBoYXZlIHJlbW92ZWQgdGhlIOKAnEFTIFJlcXVlc3QgQ3Jl YXRpb24gSGludHPigJ0gbWVzc2FnZSBuYW1lLCBhbmQgcG9pbnQgdG8gdGhlIHJpZ2h0IHJlZ2lz dHJ5IGF0IHRoZSBzYW1lIHRpbWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5bLi4uXTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjMuMy4yLiZuYnNwOyAncHViX2tleV9lbmMnIFBhcmFt ZXRlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwO1RoZSAncHViX2tleV9lbmMnIHBhcmFtZXRlciBpcyBhbiBPUFRJT05BTCBwYXJhbWV0 ZXIgb2YgdGhlIEFTPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO1JlcXVlc3QgQ3JlYXRpb24gSGludHMgbWVzc2Fn ZSBkZWZpbmVkIGluIFNlY3Rpb24gNS4xLjIuIG9mPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO1tJLUQuaWV0Zi1h Y2Utb2F1dGgtYXV0aHpdLiZuYnNwOyBUaGlzIHBhcmFtZXRlciBjb250YWlucyBpbmZvcm1hdGlv bjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDthYm91dCB0aGUgZXhhY3QgZW5jb2Rpbmcgb2YgcHVibGljIGtleXMg dG8gYmUgdXNlZCBiZXR3ZWVuIHRoZSBDbGllbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7YW5kIHRoZSBSUy4m bmJzcDsgSXRzIGV4YWN0IGNvbnRlbnQgaXMgYXBwbGljYXRpb24gc3BlY2lmaWMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7SW4gdGhp cyBzcGVjaWZpY2F0aW9uIGFuZCBpbiBhcHBsaWNhdGlvbiBwcm9maWxlcyBidWlsZGluZyBvbiBp dCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhpcyBwYXJhbWV0ZXIgaXMgdXNlZCB0byBhc2sgdGhlIEtEQyBp bmZvcm1hdGlvbiBhYm91dCB0aGUgZW5jb2Rpbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7b2YgcHVibGljIGtl eXMgdXNlZCBpbiB0aGUgZ3JvdXAuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhlIENEREwgbm90YXRpb24gb2YgdGhlICdwdWJfa2V5 X2VuYycgcGFyYW1ldGVyIGZvcm1hdHRlZCBhcyBpbiB0aGU8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7cmVxdWVz dCBpcyBnaXZlbiBiZWxvdy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtwdWJfa2V5X2VuY19yZXEgPSBu aWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbHQ7bWdsdCZndDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5JdCBpcyBub3QgZW50aXJl bHkgY2xlYXIgdG8gbWUgd2hhdCBwdWJfa2V5X2VuYyBpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5hYm91dC4gSXQgaXMgdGhlIGZvcm1hdCBv ZiB0aGUgcHVibGljIGtleSBpdHNlbGY8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+b3IgdGhlIGVuY3J5cHRpb24gYWxnb3JpdGhtID88L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5UaGVuIGl0IGlzIHVuY2xlYXIgdG8g bWUgd2hpY2ggcHVibGljIGtleSBpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5yZWZlcnJlZCB0by4mbmJzcDsgJnF1b3Q7cHVibGljIGtleXMg dXNlZCBpbiB0aGUgZ3JvdXAmcXVvdDsgbWFrZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5tZSB0aGluayBvZiBhIHByaXZhdGUvcHVibGljIGtl eSB0aGF0IGlzIHNoYXJlZCBieTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5hbGwgbWVtYmVycyBvZiB0aGUgZ3JvdXAuJm5ic3A7IFRoaXMgcHVi bGljIGtleSBpcyB1c2VkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPndpdGggdGhlIFJTLCB0aGF0IGlzIHRoZSBkaXNwYXRjaGVyLCBub3QgdG88 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+YXV0 aGVudGljYXRlIHRoZSBjbGllbnQuIEFtIEkgY29ycmVjdCA/PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+Jmx0Oy9tZ2x0Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6Izk5MDBGRiI+RlA6PC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MDBGRiI+J3B1Yl9rZXlfZW5j JyBpbmRpY2F0ZXMgJnF1b3Q7dGhlIGV4YWN0IGVuY29kaW5nIG9mIHB1YmxpYyBrZXlzIHVzZWQg aW4gdGhlIGdyb3VwJnF1b3Q7LCBlLmcuIENPU0UgS2V5LiBUaGUgYWxnb3JpdGhtIGFuZCBvdGhl ciByZWxhdGVkIGluZm9ybWF0aW9uIGFyZSBpbmRpY2F0ZWQgaW4gc2VwYXJhdGUgcGFyYW1ldGVy cy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTAwRkYiPk5vLCB0aGF0IGlz IG5vdCBjb3JyZWN0LiBUaG9zZSDigJxwdWJsaWMga2V5c+KAnSBhcmUgdGhlIGFzeW1tZXRyaWMg a2V5cyB0aGF0IHdpbGwgYmUgdXNlZCB0byBjb3VudGVyc2lnbiBtZXNzYWdlcyBzZW50IHRvIHRo ZSBncm91cC4gRWFjaCBqb2luaW5nIG5vZGUgaGFzIGl0cyBvd24gcHJpdmF0ZSAvIHB1YmxpYw0K IGtleSBwYWlyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+My4zLjMuJm5ic3A7ICdrZGNjaGFsbGVuZ2Un IFBhcmFtZXRlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwO1RoZSAna2RjY2hhbGxlbmdlJyBwYXJhbWV0ZXIgaXMgYW4gT1BUSU9OQUwg cGFyYW1ldGVyIG9mIHRoZSBBUzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtSZXF1ZXN0IENyZWF0aW9uIEhpbnRz IG1lc3NhZ2UgZGVmaW5lZCBpbiBTZWN0aW9uIDUuMS4yLiBvZjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtbSS1E LmlldGYtYWNlLW9hdXRoLWF1dGh6XS4mbmJzcDsgVGhpcyBwYXJhbWV0ZXIgY29udGFpbnMgYSBj aGFsbGVuZ2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Z2VuZXJhdGVkIGJ5IHRoZSBLREMgYW5kIHByb3ZpZGVk IHRvIHRoZSBDbGllbnQuJm5ic3A7IFRoZSBDbGllbnQgbWF5IHVzZTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDt0 aGlzIGNoYWxsZW5nZSB0byBwcm92ZSBwb3NzZXNzaW9uIG9mIGl0cyBvd24gcHJpdmF0ZSBrZXkg aW4gdGhlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwO0pvaW5pbmcgUmVxdWVzdCAoKHNlZSB0aGUgJ2NsaWVudF9j cmVkX3ZlcmlmeScgcGFyYW1ldGVyIGluPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO1NlY3Rpb24gNCkuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmx0O21nbHQmZ3Q7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SSBzdXBwb3NlIHRoYXQgd2lsbCBiZSBj bGFyaWZpZWQgaW4gc2VjdGlvbiAsIGJ1dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5vZiAmcXVvdDtpdHMgb3duIHByaXZhdGUga2V5JnF1b3Q7 IG1ha2UgbWUgdGhpbmsgdGhhdCB0aGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+a2V5IGluIHF1ZXN0aW9uIGlzIHRvIGF1dGhlbnRpY2F0ZSB0 aGUgY2xpZW50LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj5pbnN0ZWFkIG9mIHRoZSBrZXkgdXNlZCBmb3IgdGhlIGdyb3VwLiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPklmIHRoYXQgaXMgY29ycmVjdCwg aXQgaXMgdW5jbGVhciB0byBtZSB3aHkgdGhlcmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+aXMgYSBuZWVkIHRvIGF1dGhlbnRpY2F0ZSB0aGUg Y2xpZW50IGFuZCB3aHkgdGhpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5zaG91bGQgbm90IGJlIHBlcmZvcm1lZCBpbnN0ZWFkIGJ5IHRoZSBB Uy4mbmJzcDsgSXQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+c2VlbXMgSSBhbSBtaXNzaW5nIHNvbWV0aGluZyBoZXJlLiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZsdDsvbWdsdCZndDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5OTAwRkYiPkZQOiBJdCBpcyBjb3JyZWN0IHRoYXQg dGhpcyBpcyBub3QgYWJvdXQgYXV0aGVudGljYXRpbmcgdGhlIGNsaWVudC48L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOiM5OTAwRkYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojOTkwMEZGIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojOTkwMEZGIj4mcXVvdDtpdHMgb3du IHByaXZhdGUga2V5JnF1b3Q7IHJlZmVycyB0byB0aGUgc2lnbmF0dXJlIGtleSB0aGF0IHRoZSBj bGllbnQgdXNlcyBpbiB0aGUgZ3JvdXAuIFRoYXQga2V5IG1heSBoYXZlIG5vdCB0YWtlbiBwYXJ0 IHRvIHRoZSBwcmV2aW91cyBpbnRlcmFjdGlvbnMgd2l0aCB0aGUgS0RDLCBlLmcuIGl0IHRoZSBU b2tlbg0KIFBPU1Qgd2FzIGJhc2VkIG9uIHRoZSBPU0NPUkUgcHJvZmlsZSBvciB0aGUgRFRMUyBw cm9maWxlIGluIHN5bW1ldHJpYyBtb2RlLjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Izk5MDBG RiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj40LiZuYnNwOyBLZXlpbmcgTWF0ZXJpYWwgUHJvdmlzaW9uaW5nIGFu ZCBHcm91cCBNZW1iZXJzaGlwIE1hbmFnZW1lbnQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5bLi4uXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyZuYnNwO1Vwb24gcmVjZWl2aW5nIGEgcmVxdWVzdCBmcm9tIGEgQ2xp ZW50LCB0aGUgS0RDIE1VU1QgY2hlY2sgdGhhdCBpdCBpczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtzdG9yaW5n IGEgdmFsaWQgYWNjZXNzIHRva2VuIGZyb20gdGhhdCBDbGllbnQgZm9yIHRoZSBncm91cDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDtpZGVudGlmaWVyIGFzc2ljaWF0ZWQmbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmx0O21nbHQmZ3Q7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmFzc29jaWF0ZWQ8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmx0 Oy9tZ2x0Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MDBGRiI+RlA6 PC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6Izk5MDBGRiI+Rml4ZWQgbm93PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+dG8gdGhlIGVuZHBvaW50LiZuYnNwOyBJZiB0aGF0IGlzIG5vdCB0aGUg Y2FzZSwgaS5lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDt0aGUgS0RDIGRvZXMgbm90IHN0b3JlIGEgdmFsaWQg YWNjZXNzIHRva2VuIG9yIHRoaXMgaXMgbm90IHZhbGlkIGZvcjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDt0aGF0 IENsaWVudCBmb3IgdGhlIGdyb3VwIGlkZW50aWZpZXIgYXQgaGFuZCwgdGhlIEtEQyBNVVNUIHJl c3BvbmQgdG88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7dGhlIENsaWVudCB3aXRoIGEgNC4wMSAoVW5hdXRob3Jp emVkKSBlcnJvciBtZXNzYWdlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPjQuMS4mbmJzcDsgSW50ZXJmYWNlIGF0IHRoZSBLREM8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtUaGUgS0RDIGlzIGNvbmZpZ3Vy ZWQgd2l0aCB0aGUgZm9sbG93aW5nIHJlc291cmNlcy4mbmJzcDsgTm90ZSB0aGF0IHRoZTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsmbmJzcDtyb290IHVybC1wYXRoICZxdW90O2FjZS1ncm91cCZxdW90OyBnaXZlbiBoZXJl IGFyZSBkZWZhdWx0IG5hbWVzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDtpbXBsZW1lbnRhdGlvbnMgYXJlIG5v dCByZXF1aXJlZCB0byB1c2UgdGhlc2UgbmFtZXMsIGFuZCBjYW4gZGVmaW5lPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZu YnNwO3RoZWlyIG93biBpbnN0ZWFkLiZuYnNwOyBUaGUgSW50ZXJmYWNlIERlc2NyaXB0aW9uIChp Zj0pIExpbmsgVGFyZ2V0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwO0F0dHJpYnV0ZSB2YWx1ZSBhY2UtZ3JvdXAg aXMgcmVnaXN0ZXJlZCAoU2VjdGlvbiA4LjkpIGFuZCBjYW4gYmUgdXNlZDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDt0byBkZXNjcmliZSB0aGlzIGluZmVyZmFjZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmx0O21nbHQmZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPmludGVyZmFjZS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jmx0Oy9tZ2x0Jmd0 Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Izk5MDBGRiI+RlA6IEZpeGVkIG5v dzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DA7A15C0357E40DCBCA9D7EEEE18DA73ericssoncom_-- From nobody Thu Jun 18 01:47:20 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2DD3A1010; Thu, 18 Jun 2020 01:47:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159247003837.19671.16885248195136414057@ietfa.amsl.com> Date: Thu, 18 Jun 2020 01:47:18 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-07.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 08:47:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Key Provisioning for Group Communication using ACE Authors : Francesca Palombini Marco Tiloca Filename : draft-ietf-ace-key-groupcomm-07.txt Pages : 57 Date : 2020-06-18 Abstract: This document defines message formats and procedures for requesting and distributing group keying material using the ACE framework, to protect communications between group members. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-07 https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-07 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 Thu Jun 18 02:05:41 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAFC3A10A0; Thu, 18 Jun 2020 02:05:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159247114013.7249.6944930695005700028@ietfa.amsl.com> Date: Thu, 18 Jun 2020 02:05:40 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-oscore-07.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 09:05:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Key Management for OSCORE Groups in ACE Authors : Marco Tiloca Jiye Park Francesca Palombini Filename : draft-ietf-ace-key-groupcomm-oscore-07.txt Pages : 42 Date : 2020-06-18 Abstract: This specification defines an application profile of the ACE framework for Authentication and Authorization, to request and provision keying material in group communication scenarios that are based on CoAP and secured with Group Object Security for Constrained RESTful Environments (OSCORE). This application profile delegates the authentication and authorization of Clients that join an OSCORE group through a Resource Server acting as Group Manager for that group. This application profile leverages protocol-specific transport profiles of ACE to achieve communication security, server authentication and proof-of-possession for a key owned by the Client and bound to an OAuth 2.0 access token. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm-oscore/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-07 https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-oscore-07 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 Thu Jun 18 05:26:15 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9272B3A09F7; Thu, 18 Jun 2020 05:26:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159248316955.3616.2386972527908140377@ietfa.amsl.com> Date: Thu, 18 Jun 2020 05:26:09 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-dtls-authorize-11.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 12:26:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) Authors : Stefanie Gerdes Olaf Bergmann Carsten Bormann Göran Selander Ludwig Seitz Filename : draft-ietf-ace-dtls-authorize-11.txt Pages : 26 Date : 2020-06-18 Abstract: This specification defines a profile of the ACE framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS version 1.2 for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource- constrained server can use this protocol to delegate management of authorization information to a trusted host with less severe limitations regarding processing power and memory. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-dtls-authorize/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-dtls-authorize-11 https://datatracker.ietf.org/doc/html/draft-ietf-ace-dtls-authorize-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-dtls-authorize-11 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 Thu Jun 18 05:39:01 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D473A0CEB; Thu, 18 Jun 2020 05:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhKT0j8reHSY; Thu, 18 Jun 2020 05:38:57 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 829D93A0A1D; Thu, 18 Jun 2020 05:38:56 -0700 (PDT) Received: from wangari.tzi.org (p54bded4c.dip0.t-ipconnect.de [84.189.237.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49nhM20n8YzyhN; Thu, 18 Jun 2020 14:38:54 +0200 (CEST) From: Olaf Bergmann To: Benjamin Kaduk Cc: draft-ietf-ace-dtls-authorize.all@ietf.org, ace@ietf.org Date: Thu, 18 Jun 2020 14:38:32 +0200 References: <20200102234020.GI35479@kduck.mit.edu> <87pnca9gyx.fsf@wangari> <20200429011210.GC27494@kduck.mit.edu> <87mu6bn6zy.fsf@wangari> <20200527234227.GD58497@kduck.mit.edu> Message-ID: <87r1uczgyq.fsf@wangari> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 12:39:01 -0000 Hi Benjamin, Benjamin Kaduk writes: > Thanks! I think we will probably need an -11 fairly soon, though, given > the remaining comments I have. We have just submitted -11 that addresses your comments. See below for detailed responses. I have trimmed-down the email thread context a bit to improved readability and focus on the recent comments. > A couple general remarks looking at the -09-to-10 diff (not all new in > the -10, so I guess I missed it the first time around): > > In Section 3.2.1, I suggest applying: > > OLD: > [...] If CBOR web tokens [RFC8392] are used as recommended in > [I-D.ietf-ace-oauth-authz] [...] > > NEW: > [...] If CBOR web tokens [RFC8392] are used (as recommended in > [I-D.ietf-ace-oauth-authz]) [...] > > Making this a parenthetical statement makes it clear that the > conditional for "keys MUST be encoded" is "CWT are used" and separate > from the recommendation to do so. Done > Also in 3.2.1, we now have these two statements in fairly close > proximity: > > [RFC8747]. The resource server MUST use its own raw public key in > the DTLS handshake with the client. If the resource server has > several raw public keys, it must already know which key it is > supposed to use with this client. How this is achieved is not part > of this profile. > > The resource server MUST use the keying material that the > authorizations server has specified in the "cnf" parameter in the > access token for the DTLS handshake with the client. Thus, the > > which seems a bit redundant and potentially in conflict. Can we > consolidate this requirement a bit? Yes, the wording is a bit confusing. The following proposal states the intention more clearly, I think: NEW:=20 The raw public key used in the DTLS handshake with the client MUST belong to the resource server. If the resource server has several raw public keys, it needs to determine which key to use. The authorization server can help with this decision by including a `cnf` parameter in the access token that is associated with this communication. In this case, the resource server MUST use the information from the `cnf` field to select the proper keying material. > In Section 3.3: > > To convey the same secret to the resource server, the authorization > server either includes it directly in the access token by means of > the "cnf" claim or it provides sufficient information to enable the > resource server to derive the key from the access token using key > derivation. > > This text could be read as prohibiting using token introspection to > obtain the C/RS shared key (if I remember correctly about "claim" being > a CWT thing and not a more generic term for a parameter associated with > a token). I don't think that's the intent, so perhaps a wording tweak > is in order. This now has been changed to: NEW: To convey the same secret to the resource server, the authorization server can include it directly in the access token by means of the `cnf` claim or provide sufficient information to enable the resource server to derive the shared secret from the access token. As an alternative, the resource server MAY use token introspection to retrieve the keying material for this access token directly from the authorization server. > In Section 3.3.1: > > If a resource server receives a ClientKeyExchange message that > contains a "psk_identity" with a length greater than zero, it MUST > process the contents of the "psk_identity" field as access token that > is stored with the authorization information endpoint, before > continuing the DTLS handshake. If the contents of the "psk_identity" > do not yield a valid access token for the requesting client, the > resource server aborts the DTLS handshake with an "illegal_parameter" > alert. > > The way this was reworded seems to imply that any "psk_identity" with > positive length is a full access token (as would have been uploaded to > the authz-info endpoint), which prevents the case previously described > where the identity is just a COSE_Key with the 'kid' from "rs_cnf". So > I think we still need some kind of description of two potential > interpretations of the "psk_identity". Yes, this is misleading. We have changed it as follows to indicate the two (non-exclusive) processing steps: OLD: If a resource server receives a ClientKeyExchange message that contains a `psk_identity` with a length greater than zero, it MUST process the contents of the `psk_identity` field as access token that is stored with the authorization information endpoint, before continuing the DTLS handshake. If the contents of the `psk_identity` do not yield a valid access token for the requesting client, the resource server aborts the DTLS handshake with an `illegal_parameter` alert. NEW: If a resource server receives a ClientKeyExchange message that contains a `psk_identity` with a length greater than zero, it MUST parse the contents of the `psk_identity` field as CBOR data structure and process the contents as following: * If the data contains a `cnf` field with a `COSE_Key` structure with a `kid`, the resource server continues the DTLS handshake with the stored key associated with this kid. * If the data comprises additional CWT information, this information must be stored as access token for this DTLS association before continuing with the DTLS handshake. If the contents of the `psk_identity` do not yield sufficient information to select a valid access token for the requesting client, the resource server aborts the DTLS handshake with an `illegal_parameter` alert. > In section 3.4, we updated the text about "a common understanding" > between RS and AS about how access tokens are ordered, and reworded the > text about checking authorization on every request. I think we could > say a little bit more about how there is not a strict guarantee of > processing order for requests and authorization updates, so requests > that occur around the time of an authorization update might be processed > using either the old or new authorization rules. Even just referencing > Section 7.2 would be enough. This now has been clarified as follows, introducing another forward reference: OLD: The client MUST ascertain that its keying material is still valid before sending a request or processing a response. If the client gets an error response NEW: The client MUST ascertain that its keying material is still valid before sending a request or processing a response. If the client recently has updated the access token (see Section 4), it must be prepared that its request is still handled according to the previous authorization rules as there is no strict ordering between access token uploads and resource access messages. See also Section 7.2 for a discussion of access token processing. > (more inline) > >> > On Tue, Apr 14, 2020 at 06:20:38PM +0200, Olaf Bergmann wrote: >> >> Ben, >> >>=20 >> >> Thanks again for the thorough review of the ACE DTLS profile and my >> >> sincere apologies for the long time it took to process. Please find o= ur >> >> comments inline. As this comprises a lot of changes, the proposed text >> >> already has been included in the Editor's copy [1]. Our proposals for >> >> new text are in the section-by-section comments. >> >>=20 >> >> [1] https://ace-wg.github.io/ace-dtls-profile/ >> >>=20 >> >> Benjamin Kaduk writes: >> >>=20 >> >> > Hi all, >> >> > >> >> > Some high-level remarks before delving into the section-by-section >> >> > comments: >> >> > >> >> > This document is pretty clearly DTLS 1.2-specific -- it talks about >> >> > particular protocol messages, message fields, and cipher suites that >> >> > simply do not apply to DTLS 1.3. In order to use this profile with= DTLS >> >> > 1.3, we'd need to specify the analogous behavior/requirements to th= ese >> >> > (including standalone signature schemes and key-exchange groups, wh= ich >> >> > are now both separately negotiated from the cipher suite). >> >> > Given that DTLS 1.3 is past WGLC and only a few documents behind th= is >> >> > one in my review queue, it seems fairly prudent to spend some time = and >> >> > cover how DTLS 1.3 would work here, since otherwise this document w= ill >> >> > become stale shortly after (or even before!) its publication as an = RFC. > > Is anyone working on a DTLS 1.3 version? Steffi and I have been in the process of starting to take a closer look :-) >> > I think we need to give some guidance about what the semantics are if/= when >> > it happens. My inclination would be to say that DTLS resumption can be >> > used to amortize the cost of a handshake, but DTLS 1.2 resumption does= not >> > provide forward secrecy and also does not provide an opportunity for t= he >> > client to prove possession of the PoP key, so servers will want to >> > periodically force a full handshake according to their authentication >> > requirements. I'd also be inclined to forbid renegotiation entirely. >>=20 >> True, especially because RFC 7925 requires resumption to be >> implemented. The security considerations now advise against session >> resumptions and renegotiation as you have suggested. The Security >> Considerations section now has been structured in sub-sections for >> clarity. > > The discussion in the -10 is reasonable (and the stated motivation of > having a fresh proof of possession is fairly compelling), though to be > clear, my initial "inclination" above was just to forbid renegotiation > but allow resumption. Sorry, I had misinterpreted that. Actually, I am not entirely convinced by the "fresh PoP" argument anymore. When the access token made its way to the server through the client, there is no significant difference between keeping the DTLS session open and session resumption. Additional security against breaching the encryption of the (encrypted part of the) access token would be provided only by token introspection. But in that case, session resumption again would not harm security as we do not need to store precious information in the session ticket. Are you in favor of allowing session resumption? >> >> NEW: >> >>=20 >> >> The authorization server must ascertain that the keying material >> >> for the client that it provides to the resource server actually is >> >> associated with this client. Malicious clients may hand over >> >> access tokens containing their own access permissions to other >> >> entities. This problem cannot be completely >> >> eliminated. Nevertheless, in RPK mode it should not be possible >> >> for clients to request access tokens for arbitrary public keys, >> >> since that would allow the client to relay tokens without the need >> >> to share its own credentials with others. The authorization server >> > >> > I think this sentence could probably be wordsmithed some more, though I >> > don't have a concrete proposal at the moment. It does seem like we mi= ght >> > want to discuss this scenario more in terms of "identity misbinding" t= han >> > "relay tokens", though. (We had a SAAG talk at IETF 104 about misbind= ing >> > attacks on device pairing, which is not quite the same, but shares som= e of >> > the concepts.) >>=20 >> Okay. This is the only comment I did not yet address in the text. We >> might want to keep this in mind for -11. > > Looking at it again, perhaps: > > % eliminated. Nevertheless, in RPK mode it should not be possible > % for clients to request access tokens for arbitrary public keys: if the > % client can cause the AS to issue a token for a public key without > % proving possession of the corresponding private key, this allows for > % identity misbinding attacks where the issued token is usable by an > % entity other than the intended one. [...] Very good, thank you. >> >> OLD: >> >>=20 >> >> The response also contains an access token and an "rs_cnf" >> >> parameter containing information about the public key that is used >> >> by the resource server. AS MUST ascertain that the RPK specified >> >> in "rs_cnf" belongs to the resource server that C wants to >> >> communicate with. >> >>=20 >> >> NEW: >> >>=20 >> >> The response also contains an access token with information about >> >> the public key that is used by the resource server. The >> > >> > This sounds like "the information[...]" is part of the access token; m= aybe >> > "along with"? >>=20 >> What is meant here is that the information is contained in the access >> token. The misleading part is that the AT contains information about the >> client's RPK that the resource server uses to recognize the client in >> the subsequent communication. >>=20 >> I have changed this sentence to: >>=20 >> NEW: >>=20 >> The response also contains an access token with information for the >> resource server about the client's public key. > > That should help a lot; thanks! > >> >> > The fields in the context information "COSE_KDF_Context" >> >> > (Section 11.2 of [RFC8152]) have the following values: >> >> > >> >> > o AlgorithmID =3D "ACE-CoAP-DTLS-key-derivation" >> >> > >> >> > RFC 8152 says that these AlgorithmID values come from the COSE >> >> > Algorithms registry, which this does not (unless we register it the= re, >> >> > which we don't currently). Also, since the output is used directly= for >> >> > DTLS PSK, I don't think the "key-derivation" portion is needed. >> >> > >> >> > o PartyUInfo =3D PartyVInfo =3D ( null, null, null ) >> >> > >> >> > (8152 seems to prefer "nil" over "null".) >> >> > >> >> > o keyDataLength needs to be defined by the application >> >> > >> >> > o protected MUST be a zero length bstr >> >> > >> >> > o other is a zero length bstr >> >> > >> >> > (These three are all members of the "SuppPubInfo" field, which is n= ot >> >> > very clear from how we include them in the same list as top-level >> >> > fields.) >> >>=20 >> >> The example now has updated and rephrased according to HKDF usage. >> > >> > The formatting/discussion looks good, but I'll need to cross-check the= data >> > structures once the new revision is uploaded. > > I do like the presentation with HKDF and the structured input to it. > > However, I think we may have over-corrected w.r.t. key-id uniqueness: > > In order to generate a new symmetric key to be used by client and > resource server, the authorization server generates a new key > identifier which MUST be unique among all key identifiers used by the > authorization server. The authorization server then uses the key > > I think this requirement for uniqueness global to the AS may be too > strong; couldn't key identifiers be reused for different RSes? > Having the kid be part of the input to HKDF keyed by a unique AS/RS > shared key also helps a great deal to avoid accidental key collisions. True, uniqueness for each individual RS would be sufficient: OLD: MUST be unique among all key identifiers used by the authorization server. NEW: MUST be unique among all key identifiers used by the authorization server for this resource server. > To ensure uniqueness of the derived shared secret, the authorization > server SHOULD generate a sufficiently random kid value and include > the claims "iat" and either "exp" or "exi" in the access token. > > I don't think I understand the motivation for all these statements (and > in fact that they may not be entirely correct). It is permitted to use > the 'info' parameter to HKDF for domain separation, so even having the > unique kid mentioned above is enough to ensure a unique derived shared > secret (and this holds even if the kid uniqueness requirement is > weakendt to be per-RS and not per-AS). Including "iat", "exp", and/or > "exi" also helps to ensure uniqueness and should be recommended, but the > interrelationships are not stated well here. Perhaps: > > % Use of a unique (per RS) "kid" and the use of a unique per-AS/RS key > % derivation IKM as specified above will ensure that the derived key is > % not shared across multiple clients. However, to additionally provide > % variation in the derived key across different tokens used by the same > % client, it is additionally RECOMMENDED to include the "iat" claim and > % either the "exp" or "exi" claims in the access token. Okay, changed as suggested. >> > Up in Section 3.3 we talk about a case where the AS and RS are assumed= to >> > share a key derivation key that's used to derive symmetric keys for th= e RS >> > to share with the client. The KDF input is the IKM and the 'info' (si= nce >> > 'salt' is empty), and the IKM is just that same "key derivation key". = So >> > the only input to HKDF that changes for different clients (and the sam= e RS) >> > is the 'info'. The 'info', in turn contains a string constant 'type' = plus >> > the 'kid' and (presumably fixed) output length. If I'm reading this >> > correctly, the 'kid' is the only HKDF input that varies between client= s, so >> > if the 'kid' was reused for different clients, the AS and RS would der= ive >> > the same symmetric key for those distinct client/RS pairs. Furthermor= e, >> > since the AS returns the actual symmetric key to the client in the tok= en >> > response, that means that the symmetric key is shared by *three* parti= es >> > (vs. just client and RS, ignoring in the count the AS which knows >> > everything). I guess technically this is not the scenario forbidden b= y the >> > core framework (which is to have the same symmetric key used at multip= le >> > RSes, but it still is bad hygeine and would let one client impersonate= the >> > other. >> > >> > In cases not using the KDF, the 'kid' is just a hint to finding the ac= tual >> > key, and the actual key is assumed to be constructed uniquely by the AS >> > each time. >>=20 >> Thank you, this is absolutely true. I have now changed the input for the >> key derivation mechanism in the sense of what originally has been >> specified in draft-gerdes-ace-dcaf-authorize, i.e., including the access >> token as input to the KDF. This enables the authorization server to >> include a certain amount of unifying attributes in the info parameter, >> esp. with a randomly generated kid and the iat claim. I would have loved >> to have a claim type for carrying a nonce in the access token=E2=80=A6 > > Hmm, we say that "access_token is the decrypted access_token as > transferred from the AS to the RS", but it's supposed to be a CBOR map; > is this intended to just be the claims set from the CWT? If so, we > should say that. I do not see the difference: The access token is comprised of a CWT claim set which is represented on the wire as a CBOR map.=20 Unfortunately, this is not explained in draft-ietf-ace-oauth-params. To avoid confusion here, the following clarification has been added: NEW: The decrypted access token usually denotes a CWT claim set represented as CBOR map. >> As there is no guidance so far on how permission sets in access tokens >> are to be combined properly it seems to be wise at least to advise >> against. > > I agree that's the right advice to give; what is less clear to me is > whether this document needs to be the place to give that advice (vs. the > framework doing so). But I don't have a strong stance on this at the > moment, and am happy to move forward with the text as-is if you want. Okay, to avoid last-minute changes to the framework document I leave it as it is. >> >> > I think RFCs 7250, 7251, and 8422 need to be normative. >> >>=20 >> >> done >>=20 >> Actually, I had to revert this for the informational RFC 7251 as the >> idnits tool did not allow the downref from normative. > > idnits is just a tool to raise potential issues that a human can look > at and think about; in this case, idnits is wrong: 7251 is listed at > https://datatracker.ietf.org/doc/downref/ and is perfectly fine to use > as a normative reference. Oh, sorry, I was not aware of that. This now has been reverted. Gr=C3=BC=C3=9Fe Olaf From nobody Thu Jun 18 05:41:06 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847DC3A0CFC for ; Thu, 18 Jun 2020 05:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQz0CZL0UmDj for ; Thu, 18 Jun 2020 05:41:04 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C003A0CFA for ; Thu, 18 Jun 2020 05:41:03 -0700 (PDT) Received: from wangari.tzi.org (p54bded4c.dip0.t-ipconnect.de [84.189.237.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49nhPV16fMzyTG for ; Thu, 18 Jun 2020 14:41:02 +0200 (CEST) From: Olaf Bergmann To: ace@ietf.org References: <159248316955.3616.2386972527908140377@ietfa.amsl.com> Date: Thu, 18 Jun 2020 14:41:01 +0200 In-Reply-To: <159248316955.3616.2386972527908140377@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Thu, 18 Jun 2020 05:26:09 -0700") Message-ID: <87h7v8zgv6.fsf@wangari> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-dtls-authorize-11.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 12:41:06 -0000 Dear ACE mailing list, we have submitted version 11 of the DTLS profile for ACE addressing Ben's last review comments (see my other email to this list). Gr=C3=BC=C3=9Fe Olaf internet-drafts@ietf.org writes: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Authentication and Authorization for Con= strained Environments WG of the IETF. > > Title : Datagram Transport Layer Security (DTLS) Profil= e for Authentication and Authorization for Constrained Environments (ACE) > Authors : Stefanie Gerdes > Olaf Bergmann > Carsten Bormann > G=C3=B6ran Selander > Ludwig Seitz > Filename : draft-ietf-ace-dtls-authorize-11.txt > Pages : 26 > Date : 2020-06-18 > > Abstract: > This specification defines a profile of the ACE framework that allows > constrained servers to delegate client authentication and > authorization. The protocol relies on DTLS version 1.2 for > communication security between entities in a constrained network > using either raw public keys or pre-shared keys. A resource- > constrained server can use this protocol to delegate management of > authorization information to a trusted host with less severe > limitations regarding processing power and memory. From nobody Thu Jun 18 14:52:29 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0BD3A0FEF; Thu, 18 Jun 2020 14:52:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159251714390.17708.667849157897216802@ietfa.amsl.com> Date: Thu, 18 Jun 2020 14:52:23 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oscore-profile-11.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 21:52:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : OSCORE profile of the Authentication and Authorization for Constrained Environments Framework Authors : Francesca Palombini Ludwig Seitz Göran Selander Martin Gunnarsson Filename : draft-ietf-ace-oscore-profile-11.txt Pages : 31 Date : 2020-06-18 Abstract: This memo specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security, server authentication, and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oscore-profile-11 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oscore-profile-11 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 Thu Jun 18 14:55:14 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F4B3A0CD7 for ; Thu, 18 Jun 2020 14:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 lc0Yd4q1DakQ for ; Thu, 18 Jun 2020 14:55:12 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50082.outbound.protection.outlook.com [40.107.5.82]) (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 CECE13A0C82 for ; Thu, 18 Jun 2020 14:55:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QM8tuyd+gVeHZlIBBrGhC6Zv0YSjABNTwrVuc8dW4x9i6t6JzN1dWBzPyRM57tGcA4iBcvQhMW0Ji+3UT2L9SopnBs/AUcfgbNe/twLbxnfSl8wofj8MuYES8B+WmXh8zSiTLygZR5xTwEZwqLxQ7Eoy6quJtXFMRXwGhMYna93qIgZUcFXUwBFjVoPglQAgBvjF3CGmjPcs/nHTUaBfxiYrbBJotgZG3m+b/i2PKYLh1ufPQSNZ1A18QiEOkL+lfHQSlqrpf9Vq7S75BQphViFXNrn/BK+cGdzGwaH5AeQkw1Oo/AiSAGDqsTOeeI6BYy8ahWBBRRSGcNO8cf9FuQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Sx/t9o16tfS/Uoemd9s/h54TCu2Ix5YtT/vjFFlci3s=; b=f4934AInFGGIcQ+i13yRyQCDTc99uGiB/v88g8OH8pMoRwOHUzn+++Mhnkfpqx+Jr/WTeMDJiPt0CGlBQz7rvyKIsDz41jOcUKVrxhuA7zUz2aSNOT6w4DDtuWB1H8KvmaEG/PqFrm8gUvn3ZruQS7UyGU88XvOB2TohFZkwHEpwio1PiA5CV24mZXwwrd77Jnl4+hYlZ3Aa2cX59PvnhJbKw9WK23sBGIp+IU4xH1sEg6Xnpie1k8wGuzQLsGbbnZGjzwJPgGoGAg7xw17r0XqK7uWBnDtQCckzcqtjboVxAdpjHqXd6kbS6NdAgtiQ3xxqy+jZFPi13FgF8HJDBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Sx/t9o16tfS/Uoemd9s/h54TCu2Ix5YtT/vjFFlci3s=; b=pUyCP5yycCRMuPgWDwGq4e8X+CR/gIT82dhgqWxZ2LQtVKD+O57yzL/H31EJ0N7o25CtSD1VKLbEpI8D2rxqwIiy7i0ujEcorWHsozYvHRSBlc5n8/nN27yBq4ImEApwNbFqqHnwY6ieAhcqFLtlJaWWgAF0hnJo32B0Ej8j1Tw= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0701MB2250.eurprd07.prod.outlook.com (2603:10a6:3:2c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.12; Thu, 18 Jun 2020 21:55:06 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3109.018; Thu, 18 Jun 2020 21:55:06 +0000 From: Francesca Palombini To: "ace@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-oscore-profile-11.txt Thread-Index: AQHWRbrjxf0631p2F0KcqmRU9KNRX6jfDFGA Date: Thu, 18 Jun 2020 21:55:05 +0000 Message-ID: <1E45E3AC-02B5-4B1C-9B4B-25512D99F7C4@ericsson.com> References: <159251714390.17708.667849157897216802@ietfa.amsl.com> In-Reply-To: <159251714390.17708.667849157897216802@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 37876254-fd2b-4952-0485-08d813d24300 x-ms-traffictypediagnostic: HE1PR0701MB2250: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0438F90F17 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: v4fALyujNeR9gFNeFtPtKVU/RIUce32KWH3iMZ4JOU4IJHAz/loyhRHzXrH4kycsaMGFXbuzT2FflahWs/fzV8KZuCQHrvVKL0f9I6vLB2iJXOUMdNo1tSTz/npqQ1yrmKoduzQ3F7RIlFv/tV7EjmxeAZfVi/Aw/HACD+3BX/teLFizinE6+PrpeJbfkZisqlN3nGejtNMo6tJPChkfDYLUrDuLk9SJW9gOKGdcB5pbOUJwpBY1GTTw+qjuNy4FEQRrBvRHWON8SLrLFitTAzEPNnHApYdj8HwUDKa3Fxwv+VRcP06oHjn+fg5M0YmSn9lI1tZfAw+E0RCKU8iN5p6xe+VP9Zq4L+VT6haI3AUEMXoAkEj8vIuifmHV4bzA4UsEnqhRUyQNWNb83hSubg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(39860400002)(136003)(376002)(396003)(346002)(316002)(26005)(186003)(71200400001)(83380400001)(66574015)(6486002)(33656002)(44832011)(8936002)(5660300002)(6506007)(2906002)(6512007)(66446008)(64756008)(66476007)(66556008)(2616005)(6916009)(966005)(478600001)(8676002)(36756003)(86362001)(76116006)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: rmtsKKlq1l+HKNbybfkvdoKL6Oje95UyzmfNBqjVDLN9POzTPVhgT5BpH0Jd1bjXChF+DTYipgfjChun6MJU1ZvRo9GRku1wwGwfQvYNYJtyFipM28wWwlIlbZ1bwpQhSCZywHdp+4r57xGVIr9cWsv9KIBddE2oknk+b7m8Dgg8UdjHOMTB+owQ2UzbMXLWMEKLjWchIKkdIYAUttKBlxCTx8kXrTEDUgwhLSSMjoAWkpnVJ+sUgDH66OD0z91uCq3iSFkzL9QGVj+53d9EWCeVclNCHmS8gPdHu0qmpPlRoe5pbdnfoe7AoRb0ycGWxHqyQZhwRtMJOmtKxhvmGeTODSJ1csqpOsnMes/R5gD8KUA5wz3g1Ewn/zya0MVIsYT7kSFVG5fSsd4nO0RTupJ1yntSCinA/14lLS2aLchLzur9fwzGwwx7tPnHsU0WWmt35sDeRU6NcE6pkAuhl199AlYFk+wf4A9QO7eteYRvN0OVyNqkkk9pTF9+X2XF x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <91A70C97FBE621429A24B58F94BED5C6@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 37876254-fd2b-4952-0485-08d813d24300 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jun 2020 21:55:05.9540 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fTnGnVdRLxHT8YPQcE4/fm8V5R0UvEVwF0iUqGT6feZB98uUS0XUtbzkA0TkZ2rmqjO4wanPgoyj4/JSkCnf8f5CqtluCv8H3Xb59N18T0DqNMYitjvDoOXG3XT0pUIK X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2250 Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-oscore-profile-11.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2020 21:55:14 -0000 SGksDQoNCldlIGhhdmUganVzdCBzdWJtaXR0ZWQgdi0xMSBvZiB0aGUgT1NDT1JFIHByb2ZpbGUu IFdpdGggdGhpcyB1cGRhdGUsIGEgY291cGxlIG1pbm9yIGNsYXJpZmljYXRpb25zIHRoYXQgY2Ft ZSBhcyBjb21tZW50cyBmcm9tIE9DRiBhcmUgaW5jbHVkZWQsIGFuZCB0aGUgdGV4dCBhYm91dCB1 cGRhdGUgb2YgYWNjZXNzIHJpZ2h0cyBhZ3JlZWQgZHVyaW5nIHRoZSBsYXN0IGludGVyaW0gaXMg YWxzbyBhZGRlZC4NCg0KQ29tbWVudHMgYXJlIHdlbGNvbWUuDQpUaGFua3MsDQpGcmFuY2VzY2EN Cg0K77u/T24gMTgvMDYvMjAyMCwgMjM6NTMsICJBY2Ugb24gYmVoYWxmIG9mIGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyIgPGFjZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQoNCiAgICBBIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMu DQogICAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQXV0aGVudGljYXRpb24gYW5k IEF1dGhvcml6YXRpb24gZm9yIENvbnN0cmFpbmVkIEVudmlyb25tZW50cyBXRyBvZiB0aGUgSUVU Ri4NCg0KICAgICAgICAgICAgVGl0bGUgICAgICAgICAgIDogT1NDT1JFIHByb2ZpbGUgb2YgdGhl IEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIGZvciBDb25zdHJhaW5lZCBFbnZpcm9u bWVudHMgRnJhbWV3b3JrDQogICAgICAgICAgICBBdXRob3JzICAgICAgICAgOiBGcmFuY2VzY2Eg UGFsb21iaW5pDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMdWR3aWcgU2VpdHoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEfDtnJhbiBTZWxhbmRlcg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgTWFydGluIEd1bm5hcnNzb24NCiAgICAJRmlsZW5hbWUgICAgICAg IDogZHJhZnQtaWV0Zi1hY2Utb3Njb3JlLXByb2ZpbGUtMTEudHh0DQogICAgCVBhZ2VzICAgICAg ICAgICA6IDMxDQogICAgCURhdGUgICAgICAgICAgICA6IDIwMjAtMDYtMTgNCg0KICAgIEFic3Ry YWN0Og0KICAgICAgIFRoaXMgbWVtbyBzcGVjaWZpZXMgYSBwcm9maWxlIGZvciB0aGUgQXV0aGVu dGljYXRpb24gYW5kDQogICAgICAgQXV0aG9yaXphdGlvbiBmb3IgQ29uc3RyYWluZWQgRW52aXJv bm1lbnRzIChBQ0UpIGZyYW1ld29yay4gIEl0DQogICAgICAgdXRpbGl6ZXMgT2JqZWN0IFNlY3Vy aXR5IGZvciBDb25zdHJhaW5lZCBSRVNUZnVsIEVudmlyb25tZW50cw0KICAgICAgIChPU0NPUkUp IHRvIHByb3ZpZGUgY29tbXVuaWNhdGlvbiBzZWN1cml0eSwgc2VydmVyIGF1dGhlbnRpY2F0aW9u LA0KICAgICAgIGFuZCBwcm9vZi1vZi1wb3NzZXNzaW9uIGZvciBhIGtleSBvd25lZCBieSB0aGUg Y2xpZW50IGFuZCBib3VuZCB0byBhbg0KICAgICAgIE9BdXRoIDIuMCBhY2Nlc3MgdG9rZW4uDQoN Cg0KICAgIFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlz Og0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYWNlLW9z Y29yZS1wcm9maWxlLw0KDQogICAgVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZh aWxhYmxlIGF0Og0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFj ZS1vc2NvcmUtcHJvZmlsZS0xMQ0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2h0bWwvZHJhZnQtaWV0Zi1hY2Utb3Njb3JlLXByb2ZpbGUtMTENCg0KICAgIEEgZGlmZiBmcm9t IHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCiAgICBodHRwczovL3d3dy5p ZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1hY2Utb3Njb3JlLXByb2ZpbGUtMTENCg0K DQogICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZy b20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCiAgICBJbnRlcm5l dC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAgZnRw Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KDQogICAgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBBY2UgbWFpbGluZyBsaXN0DQog ICAgQWNlQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9hY2UNCg0K From nobody Sat Jun 20 07:38:50 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04AA03A0029 for ; Sat, 20 Jun 2020 07:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 IeK68l8m3x3c for ; Sat, 20 Jun 2020 07:38:46 -0700 (PDT) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 A841F3A0028 for ; Sat, 20 Jun 2020 07:38:46 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id r11so7214821vsj.5 for ; Sat, 20 Jun 2020 07:38:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wXJAJzS7iCsdgKaa+1OJQxmIsr+q+07GTfhdfVY3O0c=; b=DnZ+9B2aXfUwOOV/+cgXHmW+JGp2qVSvJo+E+5fWZ/9XihwrbVTVWmJLgTFqlXpvLg HjKpf4EKR2LbmoQheR5VmUEYBI01IdEsnd3Iqp6AGWkN8SmOejy9bHmrGFhLPHrbzhGE QkLnb8x0t06liCzxXxLZHaG9kAeddQcOAzjhg2OVudKartU2lj5+3nxQkMOK9mDAxwEf wB/oTkwHOKdHmGnmm8uQz2ivblhbkCbA8gvmUKu1khI2CHODWArhp4Ub8S8t81clA/kq 5jKH1Y5CI93UnViqYjsVqzR7Wkd+65WPlhu5h+qvx7jC5BOmFehb5sOZ5GmFkMFZFGdu cgrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=wXJAJzS7iCsdgKaa+1OJQxmIsr+q+07GTfhdfVY3O0c=; b=MT6tr83t+K5+QinzSiwmG79oaec+cYI3jz+t6EgLpJdG1hZVNiHdcFVb/JIRfpkl4e jYzyroo9j5VOWpX5SDClYbUNlYbP/HQzUZAETK9Sr8wSyWAcCehHb92jIGu3npkrT6kx 3rfmk3Q5dqms1qD2xag7BzN1AqQHBEBa8hZ2PByBuHqcEK7DOP651Wytnmd1/giIIGqS tPbIUHLzJBLL+H/Hz8xJlkC4P799VdvwYNA8Z9AZ4DzQYgGbL384eQviLCFOuhGZXhJ3 qAq4T7ZPfuQCdVcEw+JlLRP5xiwSZl9Rar7kbJqafoUCE5FlRfGJXC52Y60R/SAROlTw YxnA== X-Gm-Message-State: AOAM533RSoE8dnQL9hC14qHQbDyYLJvhLjDzez3LJ5++nvltGFM4lTNs k1007OMSn8u2vlJqvcQbHyPAAWcCxVVQ4XT00qZzWrjp X-Google-Smtp-Source: ABdhPJzsMlkPoMsm/LY+GGAaRAcxm7BP6FBvREwVw/CWvRFYBV1KmxAjTrL8Vt7G2DzA/cjPaJjbOOw5ItefAUnAiqY= X-Received: by 2002:a67:e0d7:: with SMTP id m23mr11832002vsl.221.1592663925538; Sat, 20 Jun 2020 07:38:45 -0700 (PDT) MIME-Version: 1.0 References: <004701d63de7$0f7a47a0$2e6ed6e0$@augustcellars.com> In-Reply-To: <004701d63de7$0f7a47a0$2e6ed6e0$@augustcellars.com> From: Cigdem Sengul Date: Sat, 20 Jun 2020 15:38:34 +0100 Message-ID: To: Jim Schaad , Ace Wg Content-Type: multipart/alternative; boundary="0000000000008743a805a884f735" Archived-At: Subject: Re: [Ace] FW: Review draft-ietf-ace-mqtt-tls-profile-05 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2020 14:38:49 -0000 --0000000000008743a805a884f735 Content-Type: text/plain; charset="UTF-8" Hello Jim, Thank you for the comments. Responses inline. Changes in this commit On Mon, Jun 8, 2020 at 11:49 PM Jim Schaad wrote: > Let's see if I can get the mailing list right this time > > -----Original Message----- > From: Jim Schaad > Sent: Monday, June 8, 2020 3:02 PM > To: 'draft-ietf-ace-mqtt-tls-profile@ietf.org' > > Cc: 'cose@ietf.org' > Subject: Review draft-ietf-ace-mqtt-tls-profile-05 > > * Style Issue. "Abbreviations should be expanded in document title and upon > first use in the document. Full expansion of the text should be followed > by > the abbreviation in parentheses." Some items such as TLS are considered to > be known by everybody and thus do not need to be expanded. > https://www.rfc-editor.org/materials/abbrev.expansion.txt contains both > "known" and "unknown" abbreviations. (Yes this means you are going to have > a really long title.) (I might argue that OASIS should be listed as well > known.) > [CS] Fixed (All style issues are in https://github.com/ace-wg/mqtt-tls-profile/issues/53) > > * Section 1 - para 1 - Sentence two has a plurality mismatch between client > and server. I think in this case server (and broker) should be pluralized. > > [CS] Fixed. > * Section 1.3 - Broker - s/publishes/publish/ The set of pluralized items > seems to be too large by one. > [CS] Fixed > > * Section 1.3 - I think we ought to define Session given that we no longer > require that Clean Session be used. > [CS] Added https://github.com/ace-wg/mqtt-tls-profile/issues/55 > > * Section 1.3 - I do not believe that CONNACK is always the first packet > from the broker to a client. An AUTH message may be the first one. > > [CS] Removed that sentence. > * Section 2.1 - para 3 s/the public key used by the RS/the public key to be > used by the RS/ > [CS] Fixed. > > * Section 2.1 - I think (but am not sure) that we may need to do some > registrations around the use of thumbprints in a confirmation claim. If I > forget, please remind me to track this down. > [CS] Opened Github issue so that I do not forget. https://github.com/ace-wg/mqtt-tls-profile/issues/54 > > * Section 2.2.2 - para #1 - s/using client authentication/using server > authentication/ If we are doing MQTT as the default then the server not > the > client is authenticated here. You may not want to have lost the > potentially > here. > [CS] What I meant here was this: Given that the client pushed the token using authz-info, we expect it to use authenticate itself over TLS next time it connects (otherwise it would have carried the token in the MQTT connect). I will fix it as using client authentication over TLS (i.e, TLS:Known(RPK/PSK)-MQTT:none) but wanted to check first if I missed your meaning. https://github.com/ace-wg/mqtt-tls-profile/issues/56 > * Section 2.2.3 - I think that the client state MUST include the token and > either the same token is supplied or a token with the same key is supplied > in order to match with an existing state. > I used a MAY because: 1) MQTT originally identifies resuming client with only client id. 2) The client MUST still provide a token when reconnecting and continuing a session, and the broker MUST perform a validation. If the broker additionally keeps the former token then it can identify the client better. However, the client may have gotten a new token, as it may know its token has expired, or it just expanded its permissions between sessions. Also, the CONNECT message does not specify how clients can push a historical and a new token. It may be seen as an issue that the broker authorises the current session (not the continuation of the session) and uses the MQTT way to access the session state by only the Client ID. A problem may be that client A uses client_id1, disconnects and then client B connects with client_id1, both using session continuation. Then, the risk is client A's subscribed topics may be delivered to client B because client B's token has the same set of permissions. I think this is acceptable as client B's token already covers those topics (although it may mean QoS issues for client A). https://github.com/ace-wg/mqtt-tls-profile/issues/57 > > * Section 6.2 - I think it makes sense to put in a note that between the > fact that the server will disconnect on almost any error and is not > required > to keep session state between connections, clients need to make a greater > effort to ensure that tokens remain valid and they do not attempt to > publish > to topics that they do not have permissions for. [CS] Added. https://github.com/ace-wg/mqtt-tls-profile/issues/58 > > * Section 8 - The storage of tokens long term can be restricted to only > current valid ones if an immediate validation of the token is done. This > means that the RS spends time doing the validation, but does not need to > consume memory. > [CS] Just want to confirm; when you say storage of tokens restricted to current valid ones. -> do you mean RS stores the valid tokens and does not store introspection/validation result, and hence validate each time. https://github.com/ace-wg/mqtt-tls-profile/issues/59 > > This is looking really good. I think we have only two technical issues > open > at this point. The question of registrations for hash identifications in > confirmation claims and if changes to the default scope structure are to be > done. > > Thank you, Jim. > Jim > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --0000000000008743a805a884f735 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Jim,=C2=A0

Thank= you for the comments. Responses inline.
Changes in this commit=C2=A0

On Mon, Jun 8, 2020 at 11:49 PM J= im Schaad <ietf@augustcellars.= com> wrote:
Let's see if I can get the mailing list right this time

-----Original Message-----
From: Jim Schaad <ietf@augustcellars.com>
Sent: Monday, June 8, 2020 3:02 PM
To: 'draft-ietf-ace-mqtt-tls-profile@ietf.org'
<draft-ietf-ace-mqtt-tls-profile@ietf.org>
Cc: 'cose@ietf.org' <cose@ietf.or= g>
Subject: Review draft-ietf-ace-mqtt-tls-profile-05

* Style Issue. "Abbreviations should be expanded in document title and= upon
first use in the document.=C2=A0 Full expansion of the text should be follo= wed by
the abbreviation in parentheses."=C2=A0 Some items such as TLS are con= sidered to
be known by everybody and thus do not need to be expanded.
https://www.rfc-editor.org/materials/abbr= ev.expansion.txt contains both
"known" and "unknown" abbreviations.=C2=A0 (Yes this me= ans you are going to have
a really long title.)=C2=A0 (I might argue that=C2=A0 OASIS should be liste= d as well
known.)

[CS] Fixed (All style issues ar= e in=C2=A0= https://github.com/ace-wg/mqtt-tls-profile/issues/53)=C2=A0

* Section 1 - para 1 - Sentence two has a plurality mismatch between client=
and server.=C2=A0 I think in this case server (and broker) should be plural= ized.

[CS] Fixed.
=C2=A0
* Section 1.3 - Broker - s/publishes/publish/=C2=A0 The set of pluralized i= tems
seems to be too large by one.

[CS] Fixe= d=C2=A0

* Section 1.3 - I think we ought to define Session given that we no longer<= br> require that Clean Session be used.

=C2= =A0[CS] Added

* Section 1.3 - I do not believe that CONNACK is always the first packet from the broker to a client.=C2=A0 An AUTH message may be the first one.
[CS] Removed that sentence.
=C2=A0
* Section 2.1 - para 3 s/the public key used by the RS/the public key to be=
used by the RS/

[CS] Fixed.=C2=A0
=

* Section 2.1 - I think (but am not sure) that we may need to do some
registrations around the use of thumbprints in a confirmation claim.=C2=A0 = If I
forget, please remind me to track this down.

[CS] Opened Github issue so that I do not forget.=C2=A0

* Section 2.2.2 - para #1 - s/using client authentication/using server
authentication/=C2=A0 If we are doing MQTT as the default then the server n= ot the
client is authenticated here.=C2=A0 You may not want to have lost the poten= tially
here.

[CS] What I meant here was this: = Given that the client pushed the token using authz-info,
we expec= t it to use authenticate itself over TLS next time it connects (otherwise i= t would have carried the token in the MQTT connect). I will fix it as using= client authentication over TLS (i.e,=C2=A0TLS:Known(RPK/PSK)-MQTT:none) but wanted to check firs= t if I missed your meaning.


* Section 2.2.3 - I think that the client state MUST include the token and<= br> either the same token is supplied or a token with the same key is supplied<= br> in order to match with an existing state.

I used a MAY because:
1) MQTT originally identifies resuming c= lient with only client id.=C2=A0
2) The client MUST=C2=A0still provide a token when rec= onnecting and continuing a session, and the broker MUST perform a validatio= n.=C2=A0

If the broker additionally keeps the former token then it can identify = the client better.

However, the client may have gotten = a new token, as it may know its token has expired, or it just expanded its = permissions between sessions.=C2=A0
Also, the CONNECT message does= not specify how clients can push a historical and a new token.=C2=A0

It may be seen as an issue that the broke= r authorises the current session (not the continuation of the session) and = uses the MQTT way to access the session state by only the Client ID.=C2=A0<= /div>
A problem may be that client A uses client_id1, disconnects and t= hen client B connects with client_id1, both using session continuation.=C2= =A0=C2=A0
Then, the risk is client A's subscribed topics may = be delivered to client B because client B's token has the same set of p= ermissions.=C2=A0
I think this is acceptable as client B's to= ken already covers those topics (although it may mean QoS issues for client= A).=C2=A0


* Section 6.2 - I think it makes sense to put in a note that between the fact that the server will disconnect on almost any error and is not require= d
to keep session state between connections, clients need to make a greater effort to ensure that tokens remain valid and they do not attempt to publis= h
to topics that they do not have permissions for.

[CS] Added.=C2=A0
=C2=A0

* Section 8 - The storage of tokens long term can be restricted to only
current valid ones if an immediate validation of the token is done.=C2=A0 T= his
means that the RS spends time doing the validation, but does not need to consume memory.

[CS] Just want to confi= rm; when you say storage of tokens restricted to current valid ones.=C2=A0<= /div>
=C2=A0-> do you mean RS stores the valid tokens and does not s= tore introspection/validation result, and hence validate each time.
https:/= /github.com/ace-wg/mqtt-tls-profile/issues/59=C2=A0=C2=A0

This is looking really good.=C2=A0 I think we have only two technical issue= s open
at this point.=C2=A0 The question of registrations for hash identifications= in
confirmation claims and if changes to the default scope structure are to be=
done.

Thank you, Jim.=C2=A0

=C2=A0=
Jim


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--0000000000008743a805a884f735-- From nobody Mon Jun 22 08:56:34 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 604FE3A0E5F for ; Mon, 22 Jun 2020 08:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1ZYszIuTjL4 for ; Mon, 22 Jun 2020 08:56:30 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 626BC3A0D94 for ; Mon, 22 Jun 2020 08:56:29 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49rDY34G6Czyf5; Mon, 22 Jun 2020 17:56:23 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 614534183.24673-692656d0db942504b9fc28ddee0ec9fd Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Mon, 22 Jun 2020 17:56:23 +0200 Message-Id: <12DAD36B-5445-4807-B63D-295E6618E5E7@tzi.org> To: ace@ietf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Ace] IANA considerations for authz-info RT X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 15:56:33 -0000 Marco and I still have to do the bike shedding on the actual name = (=E2=80=9Cace.ai=E2=80=9D below), but we can look at my proposed text = already anyway: 8. IANA Considerations 8.NN. CoRE Resource Type registry IANA is requested to register a new Resource Type (rt=3D) Link Target Attribute in the "Resource Type (rt=3D) Link Target Attribute Values" subregistry under the "Constrained RESTful Environments (CoRE) Parameters" {{?IANA.core-parameters}} registry: rt=3D"ace.ai". This resource type describes an ACE-OAuth authz-info endpoint resource. Specific ACE-OAuth profiles can use this common resource type for defining their profile-specific discovery processes. Have I captured the discussion today? Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jun 22 09:59:27 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461813A0FFE for ; Mon, 22 Jun 2020 09:59:26 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsypxRXuCltx for ; Mon, 22 Jun 2020 09:59:25 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9286A3A0DBD for ; Mon, 22 Jun 2020 09:59:20 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 22 Jun 2020 09:59:14 -0700 From: Jim Schaad To: 'Francesca Palombini' , 'Cigdem Sengul' CC: Date: Mon, 22 Jun 2020 09:59:13 -0700 Message-ID: <008f01d648b6$7687d730$63978590$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AdZItj1OiFAPgOm+RU6u9aexJzYRpQ== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] AIF followup comment X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 16:59:26 -0000 Francesca, Cigdem, One of the things that you might want to consider as part of you problem with adapting to AIF is that the profile may want to re-define the bit string so that instead of using the CoAP request codes, you use your set of options allowing for a tighter encoding. Jim From nobody Mon Jun 22 12:12:02 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F190F3A113F for ; Mon, 22 Jun 2020 12:11:55 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ybam7mPPb2Ap for ; Mon, 22 Jun 2020 12:11:55 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424F83A1151 for ; Mon, 22 Jun 2020 12:11:52 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 22 Jun 2020 12:11:46 -0700 From: Jim Schaad To: Date: Mon, 22 Jun 2020 12:11:44 -0700 Message-ID: <009401d648c8$f9bed2e0$ed3c78a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AdZIyO04Ni9CZD29SZuWe0IxzW3ybA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Minutes Posted X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 19:12:01 -0000 I have posted the minutes for the meeting today. If you want to make any change let me know. Jim From nobody Mon Jun 22 12:25:22 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AE83A07EC for ; Mon, 22 Jun 2020 12:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC78I1mqYuwC for ; Mon, 22 Jun 2020 12:25:19 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD90B3A07D8 for ; Mon, 22 Jun 2020 12:25:18 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 22 Jun 2020 12:25:13 -0700 From: Jim Schaad To: 'Carsten Bormann' , References: <12DAD36B-5445-4807-B63D-295E6618E5E7@tzi.org> In-Reply-To: <12DAD36B-5445-4807-B63D-295E6618E5E7@tzi.org> Date: Mon, 22 Jun 2020 12:25:12 -0700 Message-ID: <009f01d648ca$db375ac0$91a61040$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQFrGbhmIuOCEEXvf5DMZnitm4ktG6m7YjaA X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] IANA considerations for authz-info RT X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 19:25:20 -0000 That corresponds to what I expected to see. > -----Original Message----- > From: Ace On Behalf Of Carsten Bormann > Sent: Monday, June 22, 2020 8:56 AM > To: ace@ietf.org > Subject: [Ace] IANA considerations for authz-info RT >=20 > Marco and I still have to do the bike shedding on the actual name = (=E2=80=9Cace.ai=E2=80=9D > below), but we can look at my proposed text already anyway: >=20 > 8. IANA Considerations >=20 > 8.NN. CoRE Resource Type registry >=20 > IANA is requested to register a new Resource Type (rt=3D) Link = Target > Attribute in the "Resource Type (rt=3D) Link Target Attribute = Values" > subregistry under the "Constrained RESTful Environments (CoRE) > Parameters" {{?IANA.core-parameters}} registry: >=20 > rt=3D"ace.ai". This resource type describes an ACE-OAuth = authz-info > endpoint resource. >=20 > Specific ACE-OAuth profiles can use this common resource type for > defining their profile-specific discovery processes. >=20 > Have I captured the discussion today? >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Mon Jun 22 13:31:13 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD21B3A115C for ; Mon, 22 Jun 2020 13:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 kpdmTqvdzvge for ; Mon, 22 Jun 2020 13:31:10 -0700 (PDT) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (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 5BF963A115B for ; Mon, 22 Jun 2020 13:31:10 -0700 (PDT) Received: by mail-vs1-xe2c.google.com with SMTP id t132so10434101vst.2 for ; Mon, 22 Jun 2020 13:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=YiAR1tZh10RQcHpHTsUTwxUxfdew9Qnkrestyt++A8E=; b=XBJ/M+EoYJUGXbX1xDhPLpGKU7i8UzocTxeW53pl5B+OvUVy4B49+NDgUyUqOwhcUI tKa4Z8+sKTanEpbS2zBEb/o3YkLVN+OgwfouPrweBCP0nC4wq7LSj/0/gZbjwE1qEkE3 B0Th61z38tf9dDPzIjeATQz7hOC2LiatbROG+A3EaiYk7PstlX+Qs+1GZRPC/dcNV6ow LASoDvakn4I75/q3Q/icCFX1aqMDXxvg9HAhHcHnw6CeodbyBBg90izyeP9q4T8RblBw DzPR+SSSLvJlHKkdZhplZ0oFt9UqFEnY/u/BJqBwG/X+L7B9ovA5YMrGvq2u6LaFl//b 8nIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YiAR1tZh10RQcHpHTsUTwxUxfdew9Qnkrestyt++A8E=; b=UCaq4YUfOKFnTSL/aXb6fVza8RRa3ReYNgSJuhqD7DRZY2M1ipNwhkBvD6Hb16zIvc +4ChGDXFD/lvzUtcWvMwveK+jvBVHEhmVKrGMAc9A5JlUvTSMFxWlE11c9HpyWxBiO0z aW1UB/ao7IG6HlBw4vTM7mfUn0DyYzRNI7rjCWdwb0fb4LumZOcD9HG3Tsop+q4yQDin gvl9gWh0OAwH0qkQc5Go+By4ivzVu3c22ZA7ioVo6KEiUoSwF1N7KKW7eG1KE2sdT2RO zl/Hm/enJ8CrTYgEY91c3m06MZyF1/sVWp3oegj/YN40n9r9Yz5T5aGKewQWWRepnhTQ 0ydw== X-Gm-Message-State: AOAM530kZ86r/b4e1XX4Yqzf8FkHCmuXu7WTtpdvuxmc0gzP1CclzYD7 6Xw/fDwgYTZkZ7Q9QuqOn1FINgUW1nCkgO+DhOP4K7tk X-Google-Smtp-Source: ABdhPJxhQJG/ih8mRjysSoDVDtg1PD6fBL4wWdUNC/YOWpYa9Z2hUg5T68dncj9aDMgtG3vEj1BMxyBvaYQTqLPVRng= X-Received: by 2002:a67:fe12:: with SMTP id l18mr8096955vsr.169.1592857869153; Mon, 22 Jun 2020 13:31:09 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Mon, 22 Jun 2020 16:30:58 -0400 Message-ID: To: Ace Wg Content-Type: multipart/alternative; boundary="00000000000077fa0f05a8b21fb2" Archived-At: Subject: [Ace] Call for adoption draft-tiloca-ace-oscore-gm-admin X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 20:31:12 -0000 --00000000000077fa0f05a8b21fb2 Content-Type: text/plain; charset="UTF-8" Hi, Following the interim meeting this morning, this email starts a call for adoption of "Admin Interface for the OSCORE Group Manager"[1]. Please state your opinion by July 6 2020 whether the WG should adopt or not this document. Yours, Jim and Daniel [1] https://datatracker.ietf.org/doc/draft-tiloca-ace-oscore-gm-admin/ -- Daniel Migault Ericsson --00000000000077fa0f05a8b21fb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Following the interim meeting this morning, this email = starts a call for adoption of "Admin Interface for the OSCORE Group Manager&qu= ot;[1]. Please state your opinion by July 6 2020 whether the=C2=A0WG=C2=A0s= hould=C2=A0adopt or not this document.

Yours,=C2=A0
Jim and D= aniel

[1] https://datatracker.ietf.org/doc/dra= ft-tiloca-ace-oscore-gm-admin/

--=
Danie= l Migault
Ericsson
--00000000000077fa0f05a8b21fb2-- From nobody Mon Jun 22 13:57:51 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4DE3A1197; Mon, 22 Jun 2020 13:57:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159285947001.4648.463483690674687734@ietfa.amsl.com> Date: Mon, 22 Jun 2020 13:57:50 -0700 Archived-At: Subject: [Ace] The ACE WG has placed draft-tiloca-ace-oscore-gm-admin in state "Call For Adoption By WG Issued" X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 20:57:50 -0000 The ACE WG has placed draft-tiloca-ace-oscore-gm-admin in state Call For Adoption By WG Issued (entered by Jim Schaad) The document is available at https://datatracker.ietf.org/doc/draft-tiloca-ace-oscore-gm-admin/ From nobody Mon Jun 22 13:58:27 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 661473A1199; Mon, 22 Jun 2020 13:58:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159285950540.15849.11686507825496654165@ietfa.amsl.com> Date: Mon, 22 Jun 2020 13:58:25 -0700 Archived-At: Subject: [Ace] The ACE WG has placed draft-bormann-core-ace-aif in state "Candidate for WG Adoption" X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 20:58:26 -0000 The ACE WG has placed draft-bormann-core-ace-aif in state Candidate for WG Adoption (entered by Jim Schaad) The document is available at https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ From nobody Mon Jun 22 15:12:28 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6014D3A11F2; Mon, 22 Jun 2020 15:12:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159286394732.28803.9776136105746750769@ietfa.amsl.com> Date: Mon, 22 Jun 2020 15:12:27 -0700 Archived-At: Subject: [Ace] I-D Action: draft-bormann-core-ace-aif-08.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 22:12:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : An Authorization Information Format (AIF) for ACE Author : Carsten Bormann Filename : draft-bormann-core-ace-aif-08.txt Pages : 9 Date : 2020-06-22 Abstract: Constrained Devices as they are used in the "Internet of Things" need security. One important element of this security is that devices in the Internet of Things need to be able to decide which operations requested of them should be considered authorized, need to ascertain that the authorization to request the operation does apply to the actual requester, and need to ascertain that other devices they place requests on are the ones they intended. To transfer detailed authorization information from an authorization manager (such as an ACE-OAuth Authorization Server) to a device, a representation format is needed. This document provides a suggestion for such a format, the Authorization Information Format (AIF). AIF is defined both as a general structure that can be used for many different applications and as a specific refinement that describes REST resources and the permissions on them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-bormann-core-ace-aif-08 https://datatracker.ietf.org/doc/html/draft-bormann-core-ace-aif-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-bormann-core-ace-aif-08 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 Mon Jun 22 15:17:01 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0D43A11F5 for ; Mon, 22 Jun 2020 15:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id riwiNHb3vcx6 for ; Mon, 22 Jun 2020 15:16:57 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 076C03A11F3 for ; Mon, 22 Jun 2020 15:16:56 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49rP072lmXzyXw; Tue, 23 Jun 2020 00:16:55 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <159286394732.28803.9776136105746750769@ietfa.amsl.com> Date: Tue, 23 Jun 2020 00:16:54 +0200 X-Mao-Original-Outgoing-Id: 614557014.575776-cf93e3c68acb86bbb291136180626081 Content-Transfer-Encoding: quoted-printable Message-Id: <1A09E8B0-7330-4208-885A-D66C2FD0513B@tzi.org> References: <159286394732.28803.9776136105746750769@ietfa.amsl.com> To: Ace Wg X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Ace] AIF as discussed today (Re: I-D Action: draft-bormann-core-ace-aif-08.txt) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2020 22:17:00 -0000 I went ahead and quickly implemented what we had discussed today. https://www.ietf.org/id/draft-bormann-core-ace-aif-08.html Lots more editing to do, but the gist of what I was trying to say should = be there. Comments welcome! Gr=C3=BC=C3=9Fe, Carsten > On 2020-06-23, at 00:12, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Authentication and Authorization for = Constrained Environments WG of the IETF. >=20 > Title : An Authorization Information Format (AIF) for = ACE > Author : Carsten Bormann > Filename : draft-bormann-core-ace-aif-08.txt > Pages : 9 > Date : 2020-06-22 >=20 > Abstract: > Constrained Devices as they are used in the "Internet of Things" = need > security. One important element of this security is that devices in > the Internet of Things need to be able to decide which operations > requested of them should be considered authorized, need to ascertain > that the authorization to request the operation does apply to the > actual requester, and need to ascertain that other devices they = place > requests on are the ones they intended. >=20 > To transfer detailed authorization information from an authorization > manager (such as an ACE-OAuth Authorization Server) to a device, a > representation format is needed. This document provides a = suggestion > for such a format, the Authorization Information Format (AIF). AIF > is defined both as a general structure that can be used for many > different applications and as a specific refinement that describes > REST resources and the permissions on them. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-bormann-core-ace-aif-08 > https://datatracker.ietf.org/doc/html/draft-bormann-core-ace-aif-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-core-ace-aif-08 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jun 22 23:24:50 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D91383A17A2; Mon, 22 Jun 2020 23:24:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.3.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159289348878.30138.17940026065093466121@ietfa.amsl.com> Date: Mon, 22 Jun 2020 23:24:48 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-34.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 06:24:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-34.txt Pages : 87 Date : 2020-06-22 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-34 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-34 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-34 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 Mon Jun 22 23:29:40 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A47D3A17A9 for ; Mon, 22 Jun 2020 23:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FEf2ldL8BiC for ; Mon, 22 Jun 2020 23:29:35 -0700 (PDT) Received: from weald2.air.saab.se (weald2.air.saab.se [136.163.212.4]) (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 C35983A17A7 for ; Mon, 22 Jun 2020 23:29:33 -0700 (PDT) Received: from mailhub1.air.saab.se ([136.163.213.4]) by weald2.air.saab.se (8.14.4/8.14.4) with ESMTP id 05N6TViT020587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 23 Jun 2020 08:29:31 +0200 DKIM-Filter: OpenDKIM Filter v2.11.0 weald2.air.saab.se 05N6TViT020587 Received: from corpappl16256.corp.saab.se (corpappl16256.corp.saab.se [10.12.13.175]) by mailhub1.air.saab.se (8.13.8/8.13.8) with ESMTP id 05N6TIoS001507 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 23 Jun 2020 08:29:18 +0200 Received: from corpappl16595.corp.saab.se (10.12.12.127) by corpappl16256.corp.saab.se (10.12.13.175) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Tue, 23 Jun 2020 08:29:18 +0200 Received: from corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f]) by corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f%4]) with mapi id 15.01.1979.003; Tue, 23 Jun 2020 08:29:18 +0200 From: Seitz Ludwig To: "ace@ietf.org" Thread-Topic: New Version Notification for draft-ietf-ace-oauth-authz-34.txt Thread-Index: AQHWSScL5TYjEKU5jUSk7WqmugOH4qjlvHYA Date: Tue, 23 Jun 2020 06:29:18 +0000 Message-ID: <3750fa6a18424a78832d4f2dc9ae3ee1@combitech.se> References: <159289348907.30138.7684581017014397560@ietfa.amsl.com> In-Reply-To: <159289348907.30138.7684581017014397560@ietfa.amsl.com> Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.198] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: 05N6TIoS001507 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.381, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -0.50, SURBL_BLOCKED 0.12, URIBL_BLOCKED 0.00) X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1593498559.11212@npbm0XAjXE8r+1wxGdC7cA X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald2.air.saab.se [136.163.212.4]); Tue, 23 Jun 2020 08:29:31 +0200 (CEST) Archived-At: Subject: [Ace] FW: New Version Notification for draft-ietf-ace-oauth-authz-34.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 06:29:38 -0000 SGVsbG8gQWNlLA0KDQpBcyBkaXNjdXNzZWQgaW4gdGhlIGludGVyaW0gbWVldGluZyB5ZXN0ZXJk YXksIHRoaXMgdXBkYXRlIGludHJvZHVjZXMgc2VjdGlvbiA4LjIgY29udHJpYnV0ZWQgYnkgQ2Fy c3RlbiBCb3JtYW5uICh0aGFuayB5b3UhKS4gSXQgZGVmaW5lcyBhIGNvcmUgcmVzb3VyY2UgdHlw ZSBmb3IgYWR2ZXJ0aXNpbmcgdGhlIGF1dGh6LWluZm8gZW5kcG9pbnQgVVJJIGEgUlMgaXMgdXNp bmcuDQoNCi9MdWR3aWcNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiANClNlbnQ6IGRl biAyMyBqdW5pIDIwMjAgMDg6MjUNClRvOiBTYW11ZWwgRXJkdG1hbiA8ZXJkdG1hbkBzcG90aWZ5 LmNvbT47IFNlaXR6IEx1ZHdpZyA8bHVkd2lnLnNlaXR6QGNvbWJpdGVjaC5zZT47IEdvZXJhbiBT ZWxhbmRlciA8Z29yYW4uc2VsYW5kZXJAZXJpY3Nzb24uY29tPjsgSGFubmVzIFRzY2hvZmVuaWcg PGhhbm5lcy50c2Nob2ZlbmlnQGFybS5jb20+OyBFcmlrIFdhaGxzdHJvZW0gPGVyaWtAd2FobHN0 cm9tc3Rla25pc2thLnNlPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoei0zNC50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHotMzQudHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgTHVkd2lnIFNlaXR6IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3Np dG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6DQpSZXZpc2lvbjoJMzQN ClRpdGxlOgkJQXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gZm9yIENvbnN0cmFpbmVk IEVudmlyb25tZW50cyAoQUNFKSB1c2luZyB0aGUgT0F1dGggMi4wIEZyYW1ld29yayAoQUNFLU9B dXRoKQ0KRG9jdW1lbnQgZGF0ZToJMjAyMC0wNi0yMw0KR3JvdXA6CQlhY2UNClBhZ2VzOgkJODcN ClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHotMzQudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHovDQpIdG1s aXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYWNlLW9h dXRoLWF1dGh6LTM0DQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoeg0KRGlmZjogICAgICAgICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRo ei0zNA0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgZnJhbWV3 b3JrIGZvciBhdXRoZW50aWNhdGlvbiBhbmQNCiAgIGF1dGhvcml6YXRpb24gaW4gSW50ZXJuZXQg b2YgVGhpbmdzIChJb1QpIGVudmlyb25tZW50cyBjYWxsZWQgQUNFLQ0KICAgT0F1dGguICBUaGUg ZnJhbWV3b3JrIGlzIGJhc2VkIG9uIGEgc2V0IG9mIGJ1aWxkaW5nIGJsb2NrcyBpbmNsdWRpbmcN CiAgIE9BdXRoIDIuMCBhbmQgdGhlIENvbnN0cmFpbmVkIEFwcGxpY2F0aW9uIFByb3RvY29sIChD b0FQKSwgdGh1cw0KICAgdHJhbnNmb3JtaW5nIGEgd2VsbC1rbm93biBhbmQgd2lkZWx5IHVzZWQg YXV0aG9yaXphdGlvbiBzb2x1dGlvbiBpbnRvDQogICBhIGZvcm0gc3VpdGFibGUgZm9yIElvVCBk ZXZpY2VzLiAgRXhpc3Rpbmcgc3BlY2lmaWNhdGlvbnMgYXJlIHVzZWQNCiAgIHdoZXJlIHBvc3Np YmxlLCBidXQgZXh0ZW5zaW9ucyBhcmUgYWRkZWQgYW5kIHByb2ZpbGVzIGFyZSBkZWZpbmVkIHRv DQogICBiZXR0ZXIgc2VydmUgdGhlIElvVCB1c2UgY2FzZXMuDQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1p bnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRG IFNlY3JldGFyaWF0DQoNCg0K From nobody Tue Jun 23 06:45:01 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ECDE3A0E16 for ; Tue, 23 Jun 2020 06:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 VRP-xwfZIFos for ; Tue, 23 Jun 2020 06:44:57 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10047.outbound.protection.outlook.com [40.107.1.47]) (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 016313A0E12 for ; Tue, 23 Jun 2020 06:44:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EPx8WRcqA2xhMQDYn5+BXXzHUg/N/CTH90u+bXPtTwkxCnXvXZ04fAg4FsbH4WYhqqT4N3bM/1QJZPhfpi/luJzeEPNNWyjZHnWIxmK7Bjuyv1Wc5uzo1tWlTFtcXSLOd76JkIckA5LLDpIQCl76LqtdqYRJY4IzRAzffLlpB44XbnYzZfop2cFxlUrf83AYZ7RkB92+BXU62lNQxiOXWw4izuVFOyik6RuHiNoeqK6gf5WbGs9nl7lKxLKG9wdVmjZjMQm1kjY/Q6hr2bQQfo3yRgZlGLL7uk2KwZdnnX8zyWTk56paxLbEeWIIBquvewuupDlaa14dn8ZOpbtJYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1zV5elUSCn5IL9RYn7Ld8U6DXSqluA12fMTGV1SYszc=; b=EF2vJOmY3kBkQBZZ+QQeyE3PokqzT8PPhATklw1OQZzQrrD/nCjnjgq5mYUMqvuCaaoClkDSnDMUTbhPjnOUKgkjVs3hFuDd6pgFc9oZNky5hbo7bhs8VY1K6Mimxz5BQdCJyrHEAeBJwBJ6hxy2hYSr147ze70kdHBrpcRQkFT+tXdjwnYf7goO9DbzhDpHwaWFSQnzHopcIUqfl03BxkGbkwfZb9lSMbC2WBpj5cjJW9Ncw4qvbdBlDgbCfzNg6BbsVW8aKxruuhVANYGjtlEo+jFssa+TLxWnXRHI3T+wZxLlGuD8sHNKAXM1orLs4Cvt8Z3G9UpO/qZenzYK9w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1zV5elUSCn5IL9RYn7Ld8U6DXSqluA12fMTGV1SYszc=; b=WkdqaiGAMfogzqkSUeriY4/nkP7RCantomwTOEkreNFhdiXCLwzhyRRmwcOMFMudGnoCUVbGxlZ4BoOzZJglNMD4x1odXNUMpCOd4pR72O51Qn1CAUUwaqQpsFCDUsZWMJ6mRjcbbJUj4NZM+ebbfyL1ZxhBUpNIxLoO2x2dhcw= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0701MB2667.eurprd07.prod.outlook.com (2603:10a6:3:98::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.12; Tue, 23 Jun 2020 13:44:54 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3131.018; Tue, 23 Jun 2020 13:44:54 +0000 From: Francesca Palombini To: Carsten Bormann , Ace Wg CC: Marco Tiloca Thread-Topic: [Ace] AIF as discussed today (Re: I-D Action: draft-bormann-core-ace-aif-08.txt) Thread-Index: AQHWSOLgKk4cuMmMrEKOGFTCzidFv6jmWLOA Date: Tue, 23 Jun 2020 13:44:54 +0000 Message-ID: References: <159286394732.28803.9776136105746750769@ietfa.amsl.com> <1A09E8B0-7330-4208-885A-D66C2FD0513B@tzi.org> In-Reply-To: <1A09E8B0-7330-4208-885A-D66C2FD0513B@tzi.org> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: tzi.org; dkim=none (message not signed) header.d=none;tzi.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: df8efdc9-98ca-45c4-7692-08d8177b9c49 x-ms-traffictypediagnostic: HE1PR0701MB2667: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04433051BF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xKS5K92YN1UU030kbV7ViQp+3J8QcTaT7uz6Dtoq54gp/BWiOoIJEnOwQC7QVCjxcZVz1uww9D0NPgVfmn12bQpHd/oI5cJC9Ktv+/V6Gx4fDP3ISVVCdye0Te4CUnb1A2fpjW83UlpqpcKN3NLlxM989UXgAvGxtjYOt5bugUSg8P5SVx+FQzInEWkTXcaMK6kCMr5ojHO05lAgGxpEm4S3BNH3cOeCZ9mxiIGs8dE2/YHEfH3Lt3z3M9CXOAdJ3g72rqBy5maK3rBZXbe7iPavXz11Tx3DmYEVnff15OsUWecPFxoy3qx+iBnLgi5TPlNjF/0WHTVZacpcCm82h7U/a1D7Ig/1WNtB9E72jOQbbflRPAwR5Z+KZv8CWMiFDiwYAIxwj4+DiiuyfHxjpQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(366004)(346002)(39860400002)(136003)(396003)(76116006)(83380400001)(8676002)(316002)(6512007)(33656002)(2616005)(478600001)(2906002)(86362001)(8936002)(110136005)(66946007)(53546011)(36756003)(66446008)(64756008)(66556008)(66476007)(26005)(5660300002)(6506007)(66574015)(44832011)(966005)(6486002)(71200400001)(186003)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: SQlmiqXiAvvgNCU3yJm3TO5UZsGysFgUHxQX+5IdwF27s5iPxNpCkGWlXt605nZml95lKCGTxLrNNb0RmROcFF3+n1GjQ7y0tJGF2hKnSjNBXM6u4C4Vh5+Prrj14fNcTSS/0aDOUkyHF6C1JQTx17aqLgJbJP+DZDdSyTbViwUiFZT9eFMASidM4DjJ2CsofsQG5mmtsIXERFv7hGpX3ATW3vq3oQcus9XzmyKQSP1I5FAdmWqyl5JE5fAJY/D1YmAEMMc/HSFVTdk/YMAs7x9GqUOiHZnNqEwpfn1xZVJYsMGzpP6SLfIHSGD/G76u0P0wn9zfVdfoqnjAD9IE1xyPFdxdpinjsKFyooqCNx9Yueaot4B3ybBMa0+fb5kF2JXEJD1gUgeLPXmfwKdF00+2KwV3sk0e++dmKa8++xJLfFk835PswphYdCU1vesAT+f1flVIp+FeJN7kqlS5pDfvbQxeQ7mY9WA0Wgfjr0uMCY2ZgPTamFZfwEl4ZBMn x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: df8efdc9-98ca-45c4-7692-08d8177b9c49 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2020 13:44:54.1212 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: o5qpffw1+boI44vfagTDTDMAfmNI2MJCT9RG8KLPCdHZO3L6wDbn8eWDdwloZz6f5+hzGs/IGz1EpPEGihtxGqOO+4uPiVQVV30LiM6BscKN/oKG8NVavAZQlKa0OB42 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2667 Archived-At: Subject: Re: [Ace] AIF as discussed today (Re: I-D Action: draft-bormann-core-ace-aif-08.txt) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 13:44:59 -0000 SGkgQ2Fyc3RlbiwNCg0KVGhhbmtzIGZvciB0aGlzIHF1aWNrIHVwZGF0ZSEgSnVzdCBzb21lIHNo b3J0IGhpZ2ggbGV2ZWwgY29tbWVudHMsIHRvIG1ha2Ugc3VyZSB3ZSBjYW4gdXNlIHRoaXMgZm9y IGFjZS1rZXktZ3JvdXBjb21tLW9zY29yZS4NCg0KSW4gYWNlLWtleS1ncm91cGNvbW0tb3Njb3Jl LCB3ZSB3b3VsZCBzYXkgdGhhdCBUb2lkIGlzIHRoZSBpZGVudGlmaWVyIG9mIHRoZSBPU0NPUkUg Z3JvdXAsIHNvIHRoZSBPU0NPUkUgImdyb3VwIG5hbWUiLCB3aGljaCBpcyBlbmNvZGVkIGFzIGEg YnN0ci4gRm9yIFRwZXJtLCBpdCdzIGEgYml0IGZ1cnRoZXIgYXdheSBmcm9tIHdoYXQgdGhlIGFp ZiBkb2N1bWVudCBzcGVjaWZpZXMgKHdoaWNoIGlzIHdoeSBJIHdhbnQgdG8gY2hlY2sgd2l0aCB5 b3UpLCBidXQgd2Ugd291bGQgZ28gZm9yIGFycmF5IG9mIHRzdHIsIHNpbmNlIHdlIGNhbid0IHJl YWxseSBlbmNvZGUgdGhlIHBlcm1pc3Npb24gdG8gYmUgYSAibW9uaXRvciIgbm9kZSAoZm9yIGV4 YW1wbGUpIGJ5IGluZGljYXRpbmcgYSBSRVNUIG1ldGhvZC4gVGhpcyBpcyBhIGJpdCBzdHJldGNo ZWQgZnJvbSB0aGUgZG9jdW1lbnQgcmlnaHQgbm93LCBidXQgaXQgc2hvdWxkIHdvcmsuDQoNCldl IHdvdWxkIGhhdmUgdG8gcmVnaXN0ZXIgYSBtZWRpYSB0eXBlIChhbmQgY29udGVudCBmb3JtYXQp IGZvciB0aGlzLCBzbyB3aGF0IHdvdWxkIHRoaXMgYmU/IFlvdSB1c2UgYWlmK2Nib3IgZm9yIHRo ZSBkZWZhdWx0LCBzbyBtYXliZSBzb21ldGhpbmcgbGlrZSAiYWlmLWFjZS1ncm91cCtjYm9yIi4g Rm9yIHNlY3Rpb24gNS4zLCB3ZSB3b3VsZCBoYXZlIHRvIHJlZ2lzdGVyIFRvaWQgYW5kIFRwZXJt IHdpdGggc29tZXRoaW5nIGxpa2U6DQoNClRvaWQgcmVnaXN0cnk6DQoqIG5hbWU6IGduYW1lDQoq IGRlc2NyaXB0aW9uOiBncm91cCBuYW1lIG9mIHRoZSBPU0NPUkUgZ3JvdXAgYXMgc3BlY2lmaWVk IGluIGFjZS1rZXktZ3JvdXBjb21tLW9zY29yZQ0KDQpUcGVybSByZWdpc3RyeToNCiogbmFtZTog cm9sZXMNCiogZGVzY3JpcHRpb246IHJvbGUgb2YgdGhlIGdyb3VwIG1lbWJlciBhcyBzcGVjaWZp ZWQgaW4gYWNlLWtleS1ncm91cGNvbW0tb3Njb3JlDQoNCkkgdGhpbmsgd2UgYXJlIG1pc3Npbmcg c29tZSBmb3JtIG9mICJlbmNvZGluZyIgY29sdW1uIGluIHRoZSByZWdpc3RyaWVzIGFib3ZlLiBJ biB0aGF0IGNhc2UgaXQgd291bGQgYmUgImJzdHIiIGZvciBUb2lkIGduYW1lIGFuZCAiQ0JPUiBh cnJheSBvZiB0c3RyIiBmb3IgVHBlcm0gcm9sZS4gSXQgd291bGQgYWxzbyBiZSAidHN0ciIgZm9y IGxvY2FsLXBhcnQgVG9pZCBhbmQgImludCIgZm9yIFRwZXJtIFJFU1QtbWV0aG9kLXNldC4gKGFs c28sIG1pbm9yLCBidXQgeW91IHNvbWV0aW1lcyB1c2UgImxvY2FsLXBhcnQiIGFuZCBzb21ldGlt ZXMgImxvY2FsLXVyaSIsIHNlZSBzZWN0aW9uIDQpLiBFdmVuIGJldHRlciwgdGhlIGRlc2NyaXB0 aW9uIG9yIHRoZSBlbmNvZGluZyBpbiB0aGUgcmVnaXN0cnkgY291bGQgcG9pbnQgdG8gInBhdGgi IGFuZCAicGVybWlzc2lvbnMiIGNkZGwsIGZvciB0aGUgZGVmYXVsdCB2YWx1ZXMgaW4gdGhlIGFp ZiBkb2MuDQoNClVzaW5nICJhcnJheSBvZiB0c3RyIiBmb3Igcm9sZXMgYWxsb3dzIHVzIHRvIGV4 cHJlc3Mgd2hhdCB3ZSBuZWVkIGZvciAic2V0IG9mIHJvbGVzIi4gSSBkb24ndCBzZWUgdGhpcyBi ZWluZyBpbiBjb250cmFzdCB3aXRoIHRoZSBhaWYgZG9jdW1lbnQgcmlnaHQgbm93Lg0KDQpTbyBh bGwgaW4gYWxsLCBJIHRoaW5rIHRoaXMgY2FuIHdvcmsgZm9yIGFjZS1rZXktZ3JvdXBjb21tLW9z Y29yZS4gUGxlYXNlIGxldCBtZSBrbm93IGlmIHlvdSBzZWUgYW55dGhpbmcgdGhhdCBib3RoZXJz IHlvdSBpbiBteSBzdW1tYXJ5Lg0KDQpUaGFua3MsDQpGcmFuY2VzY2EgDQoNCu+7v09uIDIzLzA2 LzIwMjAsIDAwOjE3LCAiQWNlIG9uIGJlaGFsZiBvZiBDYXJzdGVuIEJvcm1hbm4iIDxhY2UtYm91 bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgY2Fib0B0emkub3JnPiB3cm90ZToNCg0KICAgIEkg d2VudCBhaGVhZCBhbmQgcXVpY2tseSBpbXBsZW1lbnRlZCB3aGF0IHdlIGhhZCBkaXNjdXNzZWQg dG9kYXkuDQoNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1ib3JtYW5uLWNvcmUt YWNlLWFpZi0wOC5odG1sDQoNCiAgICBMb3RzIG1vcmUgZWRpdGluZyB0byBkbywgYnV0IHRoZSBn aXN0IG9mIHdoYXQgSSB3YXMgdHJ5aW5nIHRvIHNheSBzaG91bGQgYmUgdGhlcmUuDQogICAgQ29t bWVudHMgd2VsY29tZSENCg0KICAgIEdyw7zDn2UsIENhcnN0ZW4NCg0KDQogICAgPiBPbiAyMDIw LTA2LTIzLCBhdCAwMDoxMiwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KICAgID4g DQogICAgPiANCiAgICA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRo ZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCiAgICA+IFRoaXMgZHJhZnQg aXMgYSB3b3JrIGl0ZW0gb2YgdGhlIEF1dGhlbnRpY2F0aW9uIGFuZCBBdXRob3JpemF0aW9uIGZv ciBDb25zdHJhaW5lZCBFbnZpcm9ubWVudHMgV0cgb2YgdGhlIElFVEYuDQogICAgPiANCiAgICA+ ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBBbiBBdXRob3JpemF0aW9uIEluZm9ybWF0aW9uIEZv cm1hdCAoQUlGKSBmb3IgQUNFDQogICAgPiAgICAgICAgQXV0aG9yICAgICAgICAgIDogQ2Fyc3Rl biBCb3JtYW5uDQogICAgPiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtYm9ybWFubi1jb3JlLWFj ZS1haWYtMDgudHh0DQogICAgPiAJUGFnZXMgICAgICAgICAgIDogOQ0KICAgID4gCURhdGUgICAg ICAgICAgICA6IDIwMjAtMDYtMjINCiAgICA+IA0KICAgID4gQWJzdHJhY3Q6DQogICAgPiAgIENv bnN0cmFpbmVkIERldmljZXMgYXMgdGhleSBhcmUgdXNlZCBpbiB0aGUgIkludGVybmV0IG9mIFRo aW5ncyIgbmVlZA0KICAgID4gICBzZWN1cml0eS4gIE9uZSBpbXBvcnRhbnQgZWxlbWVudCBvZiB0 aGlzIHNlY3VyaXR5IGlzIHRoYXQgZGV2aWNlcyBpbg0KICAgID4gICB0aGUgSW50ZXJuZXQgb2Yg VGhpbmdzIG5lZWQgdG8gYmUgYWJsZSB0byBkZWNpZGUgd2hpY2ggb3BlcmF0aW9ucw0KICAgID4g ICByZXF1ZXN0ZWQgb2YgdGhlbSBzaG91bGQgYmUgY29uc2lkZXJlZCBhdXRob3JpemVkLCBuZWVk IHRvIGFzY2VydGFpbg0KICAgID4gICB0aGF0IHRoZSBhdXRob3JpemF0aW9uIHRvIHJlcXVlc3Qg dGhlIG9wZXJhdGlvbiBkb2VzIGFwcGx5IHRvIHRoZQ0KICAgID4gICBhY3R1YWwgcmVxdWVzdGVy LCBhbmQgbmVlZCB0byBhc2NlcnRhaW4gdGhhdCBvdGhlciBkZXZpY2VzIHRoZXkgcGxhY2UNCiAg ICA+ICAgcmVxdWVzdHMgb24gYXJlIHRoZSBvbmVzIHRoZXkgaW50ZW5kZWQuDQogICAgPiANCiAg ICA+ICAgVG8gdHJhbnNmZXIgZGV0YWlsZWQgYXV0aG9yaXphdGlvbiBpbmZvcm1hdGlvbiBmcm9t IGFuIGF1dGhvcml6YXRpb24NCiAgICA+ICAgbWFuYWdlciAoc3VjaCBhcyBhbiBBQ0UtT0F1dGgg QXV0aG9yaXphdGlvbiBTZXJ2ZXIpIHRvIGEgZGV2aWNlLCBhDQogICAgPiAgIHJlcHJlc2VudGF0 aW9uIGZvcm1hdCBpcyBuZWVkZWQuICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGEgc3VnZ2VzdGlv bg0KICAgID4gICBmb3Igc3VjaCBhIGZvcm1hdCwgdGhlIEF1dGhvcml6YXRpb24gSW5mb3JtYXRp b24gRm9ybWF0IChBSUYpLiAgQUlGDQogICAgPiAgIGlzIGRlZmluZWQgYm90aCBhcyBhIGdlbmVy YWwgc3RydWN0dXJlIHRoYXQgY2FuIGJlIHVzZWQgZm9yIG1hbnkNCiAgICA+ICAgZGlmZmVyZW50 IGFwcGxpY2F0aW9ucyBhbmQgYXMgYSBzcGVjaWZpYyByZWZpbmVtZW50IHRoYXQgZGVzY3JpYmVz DQogICAgPiAgIFJFU1QgcmVzb3VyY2VzIGFuZCB0aGUgcGVybWlzc2lvbnMgb24gdGhlbS4NCiAg ICA+IA0KICAgID4gDQogICAgPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3Ig dGhpcyBkcmFmdCBpczoNCiAgICA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWJvcm1hbm4tY29yZS1hY2UtYWlmLw0KICAgID4gDQogICAgPiBUaGVyZSBhcmUgYWxzbyBo dG1saXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQogICAgPiBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtYm9ybWFubi1jb3JlLWFjZS1haWYtMDgNCiAgICA+IGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYm9ybWFubi1jb3JlLWFjZS1haWYtMDgN CiAgICA+IA0KICAgID4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxh YmxlIGF0Og0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWJv cm1hbm4tY29yZS1hY2UtYWlmLTA4DQogICAgPiANCiAgICA+IA0KICAgID4gUGxlYXNlIG5vdGUg dGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3Vi bWlzc2lvbg0KICAgID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2 YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICA+IA0KICAgID4gSW50ZXJuZXQtRHJhZnRz IGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KICAgID4gZnRwOi8vZnRw LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCiAgICA+IA0KICAgID4gDQogICAgPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gSS1ELUFubm91 bmNlIG1haWxpbmcgbGlzdA0KICAgID4gSS1ELUFubm91bmNlQGlldGYub3JnDQogICAgPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KICAgID4gSW50 ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwN CiAgICA+IG9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQoNCiAg ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIEFj ZSBtYWlsaW5nIGxpc3QNCiAgICBBY2VAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KDQo= From nobody Tue Jun 23 06:45:55 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B67E3A0E16 for ; Tue, 23 Jun 2020 06:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 l-rBg_Rgvjva for ; Tue, 23 Jun 2020 06:45:53 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10045.outbound.protection.outlook.com [40.107.1.45]) (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 7E2063A0E12 for ; Tue, 23 Jun 2020 06:45:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZQePt/U9C4XyXp273/qOa6jEBLOl+H9NTeaAz5UaW/2X+uLzluL9vIE1B3SretMy2toiKszQfqwKaZc3g8pstR1kZ5XNL2pUsgRgdPG3AZUezvf199PBmrL/JudILn26y3h2Gw0v4oi9olGfsdFxRK+H/LNO23imrDrKOyGhF29PbtTsiUd1OAxsdFx04Bsk+HrzMHRvziUCC4J/hATppIcWadmaOWjyG8ZsFf690pZIRzGOwE3qPyvHmmXxYBRF2QMn/6abYLdQQ4mpMd6RWhyiO687sZmJmSgyJvglHO84l8I38bb061e7FNwH+tiqd+2ORKqNK6a7xhPlrQVZhA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1cWAM7Ud5gmQLc39yNNU/T5foubBinc4+ja8C6QPb2Q=; b=Z6Iu/mLCBxPKlHKjcQtDErQFB79Y+JmqAWZl+cO7ULPiMpwrKEj40VBsLs381HqpWtaydoIwNxL+UOPnETAnoptFEnSdM0FIOi1WIIztm7x+EgDKTPn5j0dBJVfF/NgIF/eHwvBU8XoO9tkq//nLG55N11qA6SrQjj81UbKH8yAbBTlTcV/1sfVo0w+0p9y+OFcfPfsXwYll2OpkT4Bh+tInkbZJoJd7P44cKTgSlL7wui3rWYanw3IRoDlrjrbADZKxd1bedBi2SL7NghFOPiRTREApAaeU2jXTh1F5UgPsz8rnxP/Gp1Z2z2rYJgab8talTDmow46P5uIQd/MV1w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1cWAM7Ud5gmQLc39yNNU/T5foubBinc4+ja8C6QPb2Q=; b=GSsPBnOjDt/rALf6s+vkPhREQggU+kwBvnGl9WP8DbwHMxczDdqtWAUTXZhrgjPGddnss/0DP7FAKVbZGP0TxF6yWsI6E4jzsC+p+ngEkDDWV7xEBwoXT4gltTIRWSEriERcJ3H8dmMG6VfjOm00v1r4y7odgTeTUmqBDztYzyo= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0701MB2667.eurprd07.prod.outlook.com (2603:10a6:3:98::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.12; Tue, 23 Jun 2020 13:45:49 +0000 Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f]) by HE1PR0702MB3818.eurprd07.prod.outlook.com ([fe80::a1fa:7949:3b5:b72f%7]) with mapi id 15.20.3131.018; Tue, 23 Jun 2020 13:45:49 +0000 From: Francesca Palombini To: Daniel Migault , Ace Wg Thread-Topic: [Ace] Call for adoption draft-tiloca-ace-oscore-gm-admin Thread-Index: AQHWSNQYm2GsSKxBDkmzaPLKzx0o7ajmWROA Date: Tue, 23 Jun 2020 13:45:49 +0000 Message-ID: <9FA64FFA-7887-433A-B96F-A953F73145D9@ericsson.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.37.20051002 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [158.174.219.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dbfd9c26-2741-4e94-0ac8-08d8177bbd66 x-ms-traffictypediagnostic: HE1PR0701MB2667: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 04433051BF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uljcU0d9K3swrp6GhjA+imnAJ2H+DMZNJmmvGaz9oGTI7ErjTlfKxQcJr4jVVbQA5f5S2AOnF+Rt1tR8d7vE9fFTcpDc8upFfo6pCX4MtosIt/R+GbJOf4HARvZzYU9vfs+gJJ6/toEcjo0iYELJZhEVEXDddBefAJmj1NcWSFfpc7bx/1ZZC3B6SKPbEt0XNOAf4zkOc8tHsBJk0A1VEYvw7oxR+e2xtVFgnlu9gqX8gx8JJV1ZAMwzJOUAH0zwT2JJzINgnFeGJcqJvZ1pQcv6/4kgpVwNReB9Nuy3BO5uLlz7ucS5QAvHLa8ZA1wxV6+hGYHrs2HfIIX3tEOeES82S4GVH56ZTGmsaBl+imIVi5kTqklmPoyJJ/XU4N1aL5EXrZjVZwFBjb7Jc69quA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3818.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(136003)(346002)(39860400002)(366004)(376002)(6506007)(4744005)(5660300002)(66946007)(110136005)(166002)(66446008)(64756008)(66556008)(66476007)(26005)(53546011)(36756003)(71200400001)(186003)(966005)(44832011)(6486002)(316002)(76116006)(83380400001)(8676002)(8936002)(86362001)(2906002)(9326002)(478600001)(6512007)(2616005)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: K5VcblJajDjfqpgUYOMZUcEsU9MzHP/yyRPDdygD3jD5EtMzg9+uxcT6NZnKBiXW7ghxkv9exxay9wQEyBgNHhpRxv/O6zlBUso+TvOIklQGm02EsRwkcb9Ty4SN2DjuIUbBlFy+Szo/IzVjJGpolHPedgxXmQa9nVeMfQJpKIgb9VIEGaaqgvR3nJTRsb1bSGj1PSei9rbzdejwfpqg1E9Bsdw17BHPZT9Q1rCbuI4D54zNuDkCcqbBkiqhDaLbcZBDBnnD/mkgzgpGokEUGNgalj8zYOKltmKCF9resrsVPshhuEpSjhrlPaoF7PkertwTFEQTHDZtHUC+2bdLpBSefNrrKPntoVA11sWpobb0Iydeh0ZtPECbRH28PQ33GlAIZoRdtYK7n9LWKmiS4rSx6rAHaxXSwJwbOlEUIpm1G/er4I8Wjebpn3pniNJHnT9E0zbNWbxJIoX9c9DkSsffxv5jcDJWJsAH8mAYbvt4kdNZI52yDEpH6jqRNOCe x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_9FA64FFA7887433AB96FA953F73145D9ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3818.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dbfd9c26-2741-4e94-0ac8-08d8177bbd66 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2020 13:45:49.7603 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DcVwcvVH2ducoQjJpYbGhR6ikHAwTs66Z99Uiyc5vSMzLGZbmPy4ZfwvvbUniLBaMd8DqyccciwNu/sWc970Ti6/OtTjuC+7KzEiccJmU2nL5Q2Vh7I0ZkxEcY9BYY8S X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2667 Archived-At: Subject: Re: [Ace] Call for adoption draft-tiloca-ace-oscore-gm-admin X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 13:45:55 -0000 --_000_9FA64FFA7887433AB96FA953F73145D9ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGUgZG9jdW1lbnQgYW5kIEkgYmVsaWV2ZSB0aGlzIHdp bGwgYmUgaGVscGZ1bCBmb3IgdGhlIHdvcmsgd2UgYXJlIGRvaW5nIGluIEFjZS4gKzEgZm9yIGFk b3B0aW9uLg0KDQpUaGFua3MsDQpGcmFuY2VzY2ENCg0KRnJvbTogQWNlIDxhY2UtYm91bmNlc0Bp ZXRmLm9yZz4gb24gYmVoYWxmIG9mIERhbmllbCBNaWdhdWx0IDxtZ2x0LmlldGZAZ21haWwuY29t Pg0KRGF0ZTogTW9uZGF5LCAyMiBKdW5lIDIwMjAgYXQgMjI6MzENClRvOiBBY2UgV2cgPGFjZUBp ZXRmLm9yZz4NClN1YmplY3Q6IFtBY2VdIENhbGwgZm9yIGFkb3B0aW9uIGRyYWZ0LXRpbG9jYS1h Y2Utb3Njb3JlLWdtLWFkbWluDQoNCkhpLA0KDQpGb2xsb3dpbmcgdGhlIGludGVyaW0gbWVldGlu ZyB0aGlzIG1vcm5pbmcsIHRoaXMgZW1haWwgc3RhcnRzIGEgY2FsbCBmb3IgYWRvcHRpb24gb2Yg IkFkbWluIEludGVyZmFjZSBmb3IgdGhlIE9TQ09SRSBHcm91cCBNYW5hZ2VyIlsxXS4gUGxlYXNl IHN0YXRlIHlvdXIgb3BpbmlvbiBieSBKdWx5IDYgMjAyMCB3aGV0aGVyIHRoZSBXRyBzaG91bGQg YWRvcHQgb3Igbm90IHRoaXMgZG9jdW1lbnQuDQoNCllvdXJzLA0KSmltIGFuZCBEYW5pZWwNCg0K WzFdIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRpbG9jYS1hY2Utb3Nj b3JlLWdtLWFkbWluLw0KDQotLQ0KRGFuaWVsIE1pZ2F1bHQNCkVyaWNzc29uDQo= --_000_9FA64FFA7887433AB96FA953F73145D9ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <09C0ACE224C37E4DBDBD559170DC6BD8@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0Ii IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkkgaGF2ZSByZXZpZXdlZCB0aGUgZG9jdW1lbnQgYW5kIEkgYmVsaWV2 ZSB0aGlzIHdpbGwgYmUgaGVscGZ1bCBmb3IgdGhlIHdvcmsgd2UgYXJlIGRvaW5nIGluIEFjZS4g JiM0MzsxIGZvciBhZG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtzLDxicj4NCkZyYW5jZXNjYTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5BY2UgJmx0O2FjZS1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgRGFuaWVs IE1pZ2F1bHQgJmx0O21nbHQuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1v bmRheSwgMjIgSnVuZSAyMDIwIGF0IDIyOjMxPGJyPg0KPGI+VG86IDwvYj5BY2UgV2cgJmx0O2Fj ZUBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W0FjZV0gQ2FsbCBmb3IgYWRvcHRp b24gZHJhZnQtdGlsb2NhLWFjZS1vc2NvcmUtZ20tYWRtaW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SGksJm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Rm9sbG93 aW5nIHRoZSBpbnRlcmltIG1lZXRpbmcgdGhpcyBtb3JuaW5nLCB0aGlzIGVtYWlsIHN0YXJ0cyBh IGNhbGwgZm9yIGFkb3B0aW9uIG9mICZxdW90OzxzcGFuIHN0eWxlPSJjb2xvcjpibGFjaztiYWNr Z3JvdW5kOiNGRkZERjUiPkFkbWluIEludGVyZmFjZSBmb3IgdGhlIE9TQ09SRSBHcm91cA0KIE1h bmFnZXImcXVvdDtbMV0uIFBsZWFzZSBzdGF0ZSB5b3VyIG9waW5pb24gYnkgSnVseSA2IDIwMjAg d2hldGhlciB0aGUmbmJzcDtXRyZuYnNwO3Nob3VsZCZuYnNwO2Fkb3B0IG9yIG5vdCB0aGlzIGRv Y3VtZW50Ljwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj5Zb3VycywmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Smlt IGFuZCBEYW5pZWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPlsxXQ0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt dGlsb2NhLWFjZS1vc2NvcmUtZ20tYWRtaW4vIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC10aWxvY2EtYWNlLW9zY29yZS1nbS1hZG1pbi88L2E+PGJyIGNsZWFyPSJhbGwi Pg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+LS0NCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5EYW5pZWwgTWlnYXVsdDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmIj5Fcmljc3Nvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9FA64FFA7887433AB96FA953F73145D9ericssoncom_-- From nobody Tue Jun 23 08:47:16 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B0D3A0F6E for ; Tue, 23 Jun 2020 08:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SUujNw3hAUt for ; Tue, 23 Jun 2020 08:47:01 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA5933A1027 for ; Tue, 23 Jun 2020 08:47:00 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Jun 2020 08:46:54 -0700 From: Jim Schaad To: 'Francesca Palombini' , 'Carsten Bormann' , 'Ace Wg' CC: 'Marco Tiloca' References: <159286394732.28803.9776136105746750769@ietfa.amsl.com> <1A09E8B0-7330-4208-885A-D66C2FD0513B@tzi.org> In-Reply-To: Date: Tue, 23 Jun 2020 08:46:53 -0700 Message-ID: <00ea01d64975$860fc4f0$922f4ed0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQJ8tg4m1AxG4a73qr+EP0ScytilYQGGbjn7AfzzVkunfWFLIA== X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] AIF as discussed today (Re: I-D Action: draft-bormann-core-ace-aif-08.txt) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 15:47:14 -0000 > -----Original Message----- > From: Ace On Behalf Of Francesca Palombini > Sent: Tuesday, June 23, 2020 6:45 AM > To: Carsten Bormann ; Ace Wg > Cc: Marco Tiloca > Subject: Re: [Ace] AIF as discussed today (Re: I-D Action: = draft-bormann-core- > ace-aif-08.txt) >=20 > Hi Carsten, >=20 > Thanks for this quick update! Just some short high level comments, to = make > sure we can use this for ace-key-groupcomm-oscore. >=20 > In ace-key-groupcomm-oscore, we would say that Toid is the identifier = of the > OSCORE group, so the OSCORE "group name", which is encoded as a bstr. = For > Tperm, it's a bit further away from what the aif document specifies = (which is > why I want to check with you), but we would go for array of tstr, = since we can't > really encode the permission to be a "monitor" node (for example) by > indicating a REST method. This is a bit stretched from the document = right now, > but it should work. >=20 > We would have to register a media type (and content format) for this, = so what > would this be? You use aif+cbor for the default, so maybe something = like "aif- > ace-group+cbor". For section 5.3, we would have to register Toid and = Tperm > with something like: >=20 > Toid registry: > * name: gname > * description: group name of the OSCORE group as specified in ace-key- > groupcomm-oscore >=20 > Tperm registry: > * name: roles > * description: role of the group member as specified in = ace-key-groupcomm- > oscore >=20 > I think we are missing some form of "encoding" column in the = registries above. > In that case it would be "bstr" for Toid gname and "CBOR array of = tstr" for > Tperm role. It would also be "tstr" for local-part Toid and "int" for = Tperm REST- > method-set. (also, minor, but you sometimes use "local-part" and = sometimes > "local-uri", see section 4). Even better, the description or the = encoding in the > registry could point to "path" and "permissions" cddl, for the default = values in > the aif doc. >=20 > Using "array of tstr" for roles allows us to express what we need for = "set of > roles". I don't see this being in contrast with the aif document right = now. This follows what I would expect, for MQTT I would see AIF-MQTT =3D AIF_Generic filter =3D tstr permissions =3D [ +permission ] permission =3D "publish" / "subscribe" For the group comm draft, I think that AIF-GROUP-COM =3D AIF_Generic path =3D tstr ; group name permissions =3D uint . bits methods methods =3D &( requester =3D 1, responder =3D 2, monitor =3D 3, verifier =3D 4 ) This does require a registry if we ever expect this to grow. =20 > So all in all, I think this can work for ace-key-groupcomm-oscore. = Please let me > know if you see anything that bothers you in my summary. >=20 > Thanks, > Francesca >=20 > =EF=BB=BFOn 23/06/2020, 00:17, "Ace on behalf of Carsten Bormann" = bounces@ietf.org on behalf of cabo@tzi.org> wrote: >=20 > I went ahead and quickly implemented what we had discussed today. >=20 > https://www.ietf.org/id/draft-bormann-core-ace-aif-08.html >=20 > Lots more editing to do, but the gist of what I was trying to say = should be > there. > Comments welcome! >=20 > Gr=C3=BC=C3=9Fe, Carsten >=20 >=20 > > On 2020-06-23, at 00:12, internet-drafts@ietf.org wrote: > > > > > > A New Internet-Draft is available from the on-line = Internet-Drafts > directories. > > This draft is a work item of the Authentication and = Authorization for > Constrained Environments WG of the IETF. > > > > Title : An Authorization Information Format = (AIF) for ACE > > Author : Carsten Bormann > > Filename : draft-bormann-core-ace-aif-08.txt > > Pages : 9 > > Date : 2020-06-22 > > > > Abstract: > > Constrained Devices as they are used in the "Internet of = Things" need > > security. One important element of this security is that = devices in > > the Internet of Things need to be able to decide which = operations > > requested of them should be considered authorized, need to = ascertain > > that the authorization to request the operation does apply to = the > > actual requester, and need to ascertain that other devices = they place > > requests on are the ones they intended. > > > > To transfer detailed authorization information from an = authorization > > manager (such as an ACE-OAuth Authorization Server) to a = device, a > > representation format is needed. This document provides a = suggestion > > for such a format, the Authorization Information Format (AIF). = AIF > > is defined both as a general structure that can be used for = many > > different applications and as a specific refinement that = describes > > REST resources and the permissions on them. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-bormann-core-ace-aif-08 > > = https://datatracker.ietf.org/doc/html/draft-bormann-core-ace-aif-08 > > > > A diff from the previous version is available at: > > = https://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-core-ace-aif-08 > > > > > > 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/ > > > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace >=20 > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace From nobody Tue Jun 23 13:27:35 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9F63A0900 for ; Tue, 23 Jun 2020 13:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 9hfjEqSmM3O7 for ; Tue, 23 Jun 2020 13:27:31 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 DD8703A0901 for ; Tue, 23 Jun 2020 13:27:30 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id m62so112566vsd.4 for ; Tue, 23 Jun 2020 13:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c1bJLty2o4b40NoOirCC7KPmrDkgukgDSAOwECzSstg=; b=DIUB2eenaf7dAtQClQxqbZKaE+RWIpCVaIWJsqg+esigcjcBZg4Ex2cSoGxziQ1sxZ oXBXjeRePbjG7I7KHbrXdbUAcFjVfHro2KuUtNIzsmmOFc6hvVGpDNBX/wsqbsoYBs2a Vx/A4CmS9mox02cHF8WW5Zi365CWD6DuHrGmwdyWNWx9F9wS6sSb/GUFBySCTGMcEdH5 ujI9vlZxXfgp+UQEa2KM+3WU5LVJ+yfqPj9TSN1Q8S6UqKoC++ccP2WDeJMNyPsU6UjY sGRdha4WPEDeN/ZQXr7AOW9LNVo1Ir0hy7Np5juCKA2t9IxG/nhs4bfXuWpYuMC7IGB8 V9iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c1bJLty2o4b40NoOirCC7KPmrDkgukgDSAOwECzSstg=; b=AQTNwT0rV+xHfq8/bR7bz1AABqU9z1Z/DybQk6DjbEjute5hgO2ZfZ2U21IjSLj6wC F18Nc0zZixGUrmkKNmBuTbzxgww0wj9mXZJOCNFKdDvfHUXF93B5qBgkbudJrRFVADv5 yosa/x6W0ZDaIPHJQaFMFof5MHNl4OgTLXsxonqUIeVI79Qri52ZS48PPQRq4S56+VXO u2wtA27t3gpv3bWbJPRKhBJWtWE5aAmkFERXX9oriDYrLRWc2PFxuNBeU5gWakzo72JA nUfGLE5lXVb0Zwmtia1F7chGF+Op345HDsLYVswNUscdMWa50fNmQaJHnzcVdblhaVbL 8tnQ== X-Gm-Message-State: AOAM5327vnJXFBi5cZNSIcMDEjdEcL8Mn/HshMXpmeeSJHuA4syjLGWi BKqfDhNcUoHdF/zb4/7YnOmtCL8cJ2oGAv+e2SE= X-Google-Smtp-Source: ABdhPJwqapL+vjVbYlNKzaxQ/PdlZAU3g277qCQmcVGEangaN7mp5lBEjqw8JFdvUz+ZaMglQ/l9UVNUbVvpDqT6Gxk= X-Received: by 2002:a67:8e45:: with SMTP id q66mr23463653vsd.62.1592944049829; Tue, 23 Jun 2020 13:27:29 -0700 (PDT) MIME-Version: 1.0 References: <159286394732.28803.9776136105746750769@ietfa.amsl.com> <1A09E8B0-7330-4208-885A-D66C2FD0513B@tzi.org> <00ea01d64975$860fc4f0$922f4ed0$@augustcellars.com> In-Reply-To: <00ea01d64975$860fc4f0$922f4ed0$@augustcellars.com> From: Cigdem Sengul Date: Tue, 23 Jun 2020 21:27:19 +0100 Message-ID: To: Jim Schaad Cc: Francesca Palombini , Carsten Bormann , Ace Wg , Marco Tiloca Content-Type: multipart/alternative; boundary="0000000000003cbdbb05a8c63029" Archived-At: Subject: Re: [Ace] AIF as discussed today (Re: I-D Action: draft-bormann-core-ace-aif-08.txt) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 20:27:34 -0000 --0000000000003cbdbb05a8c63029 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This looks what I expected from the MQTT point of view. Thanks, Jim. I will look into adding the change to the profile document now. Kind regards, --Cigdem On Tue, Jun 23, 2020 at 4:48 PM Jim Schaad wrote: > > > > -----Original Message----- > > From: Ace On Behalf Of Francesca Palombini > > Sent: Tuesday, June 23, 2020 6:45 AM > > To: Carsten Bormann ; Ace Wg > > Cc: Marco Tiloca > > Subject: Re: [Ace] AIF as discussed today (Re: I-D Action: > draft-bormann-core- > > ace-aif-08.txt) > > > > Hi Carsten, > > > > Thanks for this quick update! Just some short high level comments, to > make > > sure we can use this for ace-key-groupcomm-oscore. > > > > In ace-key-groupcomm-oscore, we would say that Toid is the identifier o= f > the > > OSCORE group, so the OSCORE "group name", which is encoded as a bstr. F= or > > Tperm, it's a bit further away from what the aif document specifies > (which is > > why I want to check with you), but we would go for array of tstr, since > we can't > > really encode the permission to be a "monitor" node (for example) by > > indicating a REST method. This is a bit stretched from the document > right now, > > but it should work. > > > > We would have to register a media type (and content format) for this, s= o > what > > would this be? You use aif+cbor for the default, so maybe something lik= e > "aif- > > ace-group+cbor". For section 5.3, we would have to register Toid and > Tperm > > with something like: > > > > Toid registry: > > * name: gname > > * description: group name of the OSCORE group as specified in ace-key- > > groupcomm-oscore > > > > Tperm registry: > > * name: roles > > * description: role of the group member as specified in > ace-key-groupcomm- > > oscore > > > > I think we are missing some form of "encoding" column in the registries > above. > > In that case it would be "bstr" for Toid gname and "CBOR array of tstr" > for > > Tperm role. It would also be "tstr" for local-part Toid and "int" for > Tperm REST- > > method-set. (also, minor, but you sometimes use "local-part" and > sometimes > > "local-uri", see section 4). Even better, the description or the > encoding in the > > registry could point to "path" and "permissions" cddl, for the default > values in > > the aif doc. > > > > Using "array of tstr" for roles allows us to express what we need for > "set of > > roles". I don't see this being in contrast with the aif document right > now. > > This follows what I would expect, for MQTT I would see > > AIF-MQTT =3D AIF_Generic > filter =3D tstr > permissions =3D [ +permission ] > permission =3D "publish" / "subscribe" > > For the group comm draft, I think that > > AIF-GROUP-COM =3D AIF_Generic > path =3D tstr ; group name > permissions =3D uint . bits methods > methods =3D &( > requester =3D 1, > responder =3D 2, > monitor =3D 3, > verifier =3D 4 > ) > > This does require a registry if we ever expect this to grow. > > > So all in all, I think this can work for ace-key-groupcomm-oscore. > Please let me > > know if you see anything that bothers you in my summary. > > > > Thanks, > > Francesca > > > > =EF=BB=BFOn 23/06/2020, 00:17, "Ace on behalf of Carsten Bormann" > bounces@ietf.org on behalf of cabo@tzi.org> wrote: > > > > I went ahead and quickly implemented what we had discussed today. > > > > https://www.ietf.org/id/draft-bormann-core-ace-aif-08.html > > > > Lots more editing to do, but the gist of what I was trying to say > should be > > there. > > Comments welcome! > > > > Gr=C3=BC=C3=9Fe, Carsten > > > > > > > On 2020-06-23, at 00:12, internet-drafts@ietf.org wrote: > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Draft= s > > directories. > > > This draft is a work item of the Authentication and Authorization > for > > Constrained Environments WG of the IETF. > > > > > > Title : An Authorization Information Format (AIF= ) > for ACE > > > Author : Carsten Bormann > > > Filename : draft-bormann-core-ace-aif-08.txt > > > Pages : 9 > > > Date : 2020-06-22 > > > > > > Abstract: > > > Constrained Devices as they are used in the "Internet of Things= " > need > > > security. One important element of this security is that > devices in > > > the Internet of Things need to be able to decide which operatio= ns > > > requested of them should be considered authorized, need to > ascertain > > > that the authorization to request the operation does apply to t= he > > > actual requester, and need to ascertain that other devices they > place > > > requests on are the ones they intended. > > > > > > To transfer detailed authorization information from an > authorization > > > manager (such as an ACE-OAuth Authorization Server) to a device= , > a > > > representation format is needed. This document provides a > suggestion > > > for such a format, the Authorization Information Format (AIF). > AIF > > > is defined both as a general structure that can be used for man= y > > > different applications and as a specific refinement that > describes > > > REST resources and the permissions on them. > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ > > > > > > There are also htmlized versions available at: > > > https://tools.ietf.org/html/draft-bormann-core-ace-aif-08 > > > > https://datatracker.ietf.org/doc/html/draft-bormann-core-ace-aif-08 > > > > > > A diff from the previous version is available at: > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-core-ace-aif-08 > > > > > > > > > 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/ > > > > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --0000000000003cbdbb05a8c63029 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This looks what=C2=A0I expected from the MQTT point of vie= w. Thanks, Jim.=C2=A0
I will look into adding the change to the profile= document now.=C2=A0
Kind regards,=C2=A0
--Cigdem=C2=A0=


On Tue, Jun 23, 2020 at 4:48 PM Jim Schaad <ietf@augustcellars.com> wrote= :


> -----Original Message-----
> From: Ace <ace-bounces@ietf.org> On Behalf Of Francesca Palombini
> Sent: Tuesday, June 23, 2020 6:45 AM
> To: Carsten Bormann <cabo@tzi.org>; Ace Wg <ace@ietf.org>
> Cc: Marco Tiloca <marco.tiloca@ri.se>
> Subject: Re: [Ace] AIF as discussed today (Re: I-D Action: draft-borma= nn-core-
> ace-aif-08.txt)
>
> Hi Carsten,
>
> Thanks for this quick update! Just some short high level comments, to = make
> sure we can use this for ace-key-groupcomm-oscore.
>
> In ace-key-groupcomm-oscore, we would say that Toid is the identifier = of the
> OSCORE group, so the OSCORE "group name", which is encoded a= s a bstr. For
> Tperm, it's a bit further away from what the aif document specifie= s (which is
> why I want to check with you), but we would go for array of tstr, sinc= e we can't
> really encode the permission to be a "monitor" node (for exa= mple) by
> indicating a REST method. This is a bit stretched from the document ri= ght now,
> but it should work.
>
> We would have to register a media type (and content format) for this, = so what
> would this be? You use aif+cbor for the default, so maybe something li= ke "aif-
> ace-group+cbor". For section 5.3, we would have to register Toid = and Tperm
> with something like:
>
> Toid registry:
> * name: gname
> * description: group name of the OSCORE group as specified in ace-key-=
> groupcomm-oscore
>
> Tperm registry:
> * name: roles
> * description: role of the group member as specified in ace-key-groupc= omm-
> oscore
>
> I think we are missing some form of "encoding" column in the= registries above.
> In that case it would be "bstr" for Toid gname and "CBO= R array of tstr" for
> Tperm role. It would also be "tstr" for local-part Toid and = "int" for Tperm REST-
> method-set. (also, minor, but you sometimes use "local-part"= and sometimes
> "local-uri", see section 4). Even better, the description or= the encoding in the
> registry could point to "path" and "permissions" c= ddl, for the default values in
> the aif doc.
>
> Using "array of tstr" for roles allows us to express what we= need for "set of
> roles". I don't see this being in contrast with the aif docum= ent right now.

This follows what I would expect, for MQTT I would see

AIF-MQTT =3D AIF_Generic<filter, permissions>
filter =3D tstr
permissions =3D [ +permission ]
permission =3D "publish" / "subscribe"

For the group comm draft, I think that

AIF-GROUP-COM =3D AIF_Generic<path, permisions>
path =3D tstr=C2=A0 ; group name
permissions =3D uint . bits methods
methods =3D &(
=C2=A0 =C2=A0 requester =3D 1,
=C2=A0 =C2=A0responder =3D 2,
=C2=A0 =C2=A0monitor =3D 3,
=C2=A0 =C2=A0verifier =3D 4
)

This does require a registry if we ever expect this to grow.

> So all in all, I think this can work for ace-key-groupcomm-oscore. Ple= ase let me
> know if you see anything that bothers you in my summary.
>
> Thanks,
> Francesca
>
> =EF=BB=BFOn 23/06/2020, 00:17, "Ace on behalf of Carsten Bormann&= quot; <ace-
> bounces@ietf.org= on behalf of cabo@tz= i.org> wrote:
>
>=C2=A0 =C2=A0 =C2=A0I went ahead and quickly implemented what we had di= scussed today.
>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.o= rg/id/draft-bormann-core-ace-aif-08.html
>
>=C2=A0 =C2=A0 =C2=A0Lots more editing to do, but the gist of what I was= trying to say should be
> there.
>=C2=A0 =C2=A0 =C2=A0Comments welcome!
>
>=C2=A0 =C2=A0 =C2=A0Gr=C3=BC=C3=9Fe, Carsten
>
>
>=C2=A0 =C2=A0 =C2=A0> On 2020-06-23, at 00:12, internet-drafts@ietf.org wrote= :
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> A New Internet-Draft is available from the on-= line Internet-Drafts
> directories.
>=C2=A0 =C2=A0 =C2=A0> This draft is a work item of the Authenticatio= n and Authorization for
> Constrained Environments WG of the IETF.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0: An Authorization Information Format (AIF) for = ACE
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 : Carsten Bormann
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2= =A0 =C2=A0 =C2=A0 =C2=A0 : draft-bormann-core-ace-aif-08.txt
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 9
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2020-06-22
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Abstract:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0Constrained Devices as they are us= ed in the "Internet of Things" need
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0security.=C2=A0 One important elem= ent of this security is that devices in
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0the Internet of Things need to be = able to decide which operations
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0requested of them should be consid= ered authorized, need to ascertain
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0that the authorization to request = the operation does apply to the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0actual requester, and need to asce= rtain that other devices they place
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0requests on are the ones they inte= nded.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0To transfer detailed authorization= information from an authorization
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0manager (such as an ACE-OAuth Auth= orization Server) to a device, a
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0representation format is needed.= =C2=A0 This document provides a suggestion
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0for such a format, the Authorizati= on Information Format (AIF).=C2=A0 AIF
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0is defined both as a general struc= ture that can be used for many
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0different applications and as a sp= ecific refinement that describes
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0REST resources and the permissions= on them.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The IETF datatracker status page for this draf= t is:
>=C2=A0 =C2=A0 =C2=A0> https://dat= atracker.ietf.org/doc/draft-bormann-core-ace-aif/
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> There are also htmlized versions available at:=
>=C2=A0 =C2=A0 =C2=A0> https://tools.= ietf.org/html/draft-bormann-core-ace-aif-08
>=C2=A0 =C2=A0 =C2=A0> http= s://datatracker.ietf.org/doc/html/draft-bormann-core-ace-aif-08
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> A diff from the previous version is available = at:
>=C2=A0 =C2=A0 =C2=A0> http= s://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-core-ace-aif-08
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Please note that it may take a couple of minut= es from the time of
> submission
>=C2=A0 =C2=A0 =C2=A0> until the htmlized version and diff are availa= ble at tools.ietf.org.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Internet-Drafts are also available by anonymou= s FTP at:
>=C2=A0 =C2=A0 =C2=A0> ftp://ftp.ietf.org/internet-drafts/<= /a>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> ______________________________________________= _
>=C2=A0 =C2=A0 =C2=A0> I-D-Announce mailing list
>=C2=A0 =C2=A0 =C2=A0> I-D-Announce@ietf.org
>=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/= mailman/listinfo/i-d-announce
>=C2=A0 =C2=A0 =C2=A0> Internet-Draft directories: http://www.i= etf.org/shadow.html
>=C2=A0 =C2=A0 =C2=A0> or ftp://ftp.ietf.org/ietf/1sh= adow-sites.txt
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0Ace mailing list
>=C2=A0 =C2=A0 =C2=A0A= ce@ietf.org
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listin= fo/ace
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--0000000000003cbdbb05a8c63029-- From nobody Tue Jun 23 13:42:23 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C973A0B80 for ; Tue, 23 Jun 2020 13:42:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.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 p5nz_So0szDT for ; Tue, 23 Jun 2020 13:42:11 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20077.outbound.protection.outlook.com [40.107.2.77]) (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 740583A0A34 for ; Tue, 23 Jun 2020 13:42:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gXDZQxPgD/33T+XM0VxqP12I5g5DlgkQEz8cDwMKdnZdvCWBegHrq2ogsGMMxQRb9QIHwZZUInr9ASPhSTBlBBsiJcXmii4bN40twZOq0Rqdz8EWrFFCpp89jAZXv4a+Ar4l7jVEd6KvRyDa9PPg7cSVvkvnyea+wPw/2WCiQF6SX+HadT8A4CvIjvzpfIQ+ydOIUdmZRmnYdTz3FUv8XPufNsKWMI+zsStKrGaStJ1XoPPpCITzyZrHLOqsWS/7PtyKGSjrQRKrWXUrHne30jNqsqA38YfkAaKf1apHejCU+MS3+SZK+oefh0aym7mZq6EZM7fstX0oBt6Sfe/Bew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mV+v8NlzdZ3jrbTCN1utXuO4r0zOdp/PBAHbTUxzfes=; b=MeuVPyNvc6GxU3Bo16xXv4ZTFBmrUMhNi5rGdnRZcmeZtnZrZ4HE2kzEyC4bqyGSnwpz2UEBUuT2CUUX8BuznziEX3+eziufNqy71WOUVv2/sGkGXuHcJ5HBE0yI6A3MQi0NFhG9oRL3sLCBSGP6BBlfE86N7Z9bmee4eNCUDwHJ/lRdusCE2YcggYb22yVocOIwe7Lt3vhWLzWuTUYnkgBsbFoWtZHpiqGf2gpNNEM2L28rGKd2PgTQ9XCnoYw+hRoXvU2Ipc5/CQWM0/saTGXJSwDYyekd4ygWbDcX1h8feYFWROJhrAPbGQ12ww9b7hqkwaqFswkV+62RbIFQXA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mV+v8NlzdZ3jrbTCN1utXuO4r0zOdp/PBAHbTUxzfes=; b=f4lcbTKJQTWBHH9wVxST2Qphp0693xdZHRIl31oxqeLGSgSisiOfaRKdvfo0KeXQzu54Mm/dWVgHOVUiFGFUv597d2VfgexT3gHGsk+110GOdSZCUR853u5387TZ+Rwhp5o0wc3QoW7r3BOSmBYTCHDZz1lW7hkAytDm3gR3q/w= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se; Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) by VI1P189MB0414.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3109.27; Tue, 23 Jun 2020 20:42:06 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::e88f:edb5:5074:e481]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::e88f:edb5:5074:e481%6]) with mapi id 15.20.3109.027; Tue, 23 Jun 2020 20:42:06 +0000 To: Cigdem Sengul , Jim Schaad Cc: Francesca Palombini , Carsten Bormann , Ace Wg References: <159286394732.28803.9776136105746750769@ietfa.amsl.com> <1A09E8B0-7330-4208-885A-D66C2FD0513B@tzi.org> <00ea01d64975$860fc4f0$922f4ed0$@augustcellars.com> From: Marco Tiloca Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA== Message-ID: Date: Tue, 23 Jun 2020 22:41:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wnG0I2rBzGt58A1BKfy5Uky9YEc0oqVb9" X-ClientProxiedBy: HE1PR0401CA0047.eurprd04.prod.outlook.com (2603:10a6:3:19::15) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.8.17] (213.232.87.177) by HE1PR0401CA0047.eurprd04.prod.outlook.com (2603:10a6:3:19::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20 via Frontend Transport; Tue, 23 Jun 2020 20:42:05 +0000 X-Originating-IP: [213.232.87.177] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a552ed76-1902-450e-494a-08d817b5e479 X-MS-TrafficTypeDiagnostic: VI1P189MB0414: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 04433051BF X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: uLXucSiZOuEsyJYtSRN5ILHJBoeaTqkp6BaK+VMlOPlCzS2BDK9dMpf5RdXFs/SltSvV2H/I1Rg6vS9ei1+bCph5w1D8Ob9rYBhwHDdMir6pRW82Wb++hWvPCVu74GZnBWLdVT/u+AIZjb5JL3DNZ/gveastkXBSR8PsAChnMYViSR60+SYcnliWdSnrxDNENAP4FEU7/lIWTkvBcRCEL8nch/DpnvU2utolK8rapcyfneF55/oWvO9IO0jeICkgkM3nz0KE1h2RxWgMkq72NFny0DwxKBzL1bC/3Ed7r4k+an8xCRkzmxBRGeunA3tm03DWid+q0b8q046wjW9JqxLKjROb5oyK/KyH6Cnrxze5xs4O1e7X3DZlW6mzxZux/35QQcjUeaap4gNORyC4oZWkfDj2OQHrkRQ3qmrcF2A1q67sFE+m33RMzBfE4bI+33IVkbM8da/A2uVv9oqcMA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1P189MB0398.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(136003)(376002)(366004)(39840400004)(396003)(31686004)(36756003)(2906002)(44832011)(4326008)(31696002)(2616005)(52116002)(956004)(33964004)(66556008)(66476007)(966005)(54906003)(316002)(8936002)(478600001)(21615005)(110136005)(16576012)(186003)(86362001)(16526019)(8676002)(66574015)(26005)(5660300002)(53546011)(21480400003)(83380400001)(30864003)(6666004)(166002)(235185007)(6486002)(66946007)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: LPTnCnCKlWVDCxxmKfguhigRpzC+7GgX2KtvUxV30HNEEBessNDA0qcmFX7NWYKKrGelUATdXIRCyrw2sGFv5mA1BHwQjEE9ksDCrzWTnjpy3o5WHsRPH6Gvx4r6V4cmmWXzCb2hZCGIlnpsQhltXAs1Neu5JbpAZ0xmjPMrB/ahBSI6BWXDRwIsDe5OekyOY6NA2c4S1MLDxxQ0DDe9qIBdyYwV5yRQSbxTQWqVPFgG5UjmhHUWU47y/uooCf9SrdQkGXkqIdGAKNTH5/a8qiAs2khpaZbJrxpkMpE2Cc/vs06sRART/6d+jcoNPSVdMCVZsmdeXSq5KhwB8e4AblcQV1MpZKfHwFkLH//y12ADDUPqaRoE6pehI4En3a5xFTvyV+bjh+M3ci7DpzeBmQFYfVLJTyGArYdUDO+0Y5nGOYdzdG+YheA5AeoWcChFs6hBw8t6rayVM903kakrso3hkJny4R3fhStueWCn2/8rTxkQjTqBAc6XAIxumZqd X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: a552ed76-1902-450e-494a-08d817b5e479 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Jun 2020 20:42:06.5816 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: s9nlMpxXxS3Nc/udO4lAPzxv/U+wqkBnkg8TlZpz0XrkhlZ9ydum8U0fU2ncXM+MdFuWPsgu8ycFpNoBZYWKqg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0414 Archived-At: Subject: Re: [Ace] AIF as discussed today (Re: I-D Action: draft-bormann-core-ace-aif-08.txt) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 20:42:22 -0000 --wnG0I2rBzGt58A1BKfy5Uky9YEc0oqVb9 Content-Type: multipart/mixed; boundary="bHR44HTNFaIRXVjsmHbFo07zzAjH7dHOD" --bHR44HTNFaIRXVjsmHbFo07zzAjH7dHOD Content-Type: multipart/alternative; boundary="------------0EC18240B25422F4D4A0BAED" Content-Language: en-US This is a multi-part message in MIME format. --------------0EC18240B25422F4D4A0BAED Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I think AIF-GROUP-COM as defined below works well for ace-key-groupcomm-oscore. It sounds safe to also have a register for the role integer values. Thanks, /Marco On 2020-06-23 22:27, Cigdem Sengul wrote: > This looks what=C2=A0I expected from the MQTT point of view. Thanks, Ji= m.=C2=A0 > I will look into adding the change to the profile document now.=C2=A0 > Kind regards,=C2=A0 > --Cigdem=C2=A0 > > > On Tue, Jun 23, 2020 at 4:48 PM Jim Schaad > wrote: > > > > > -----Original Message----- > > From: Ace > > On Behalf Of Francesca Palombini > > Sent: Tuesday, June 23, 2020 6:45 AM > > To: Carsten Bormann >; Ace Wg > > > > Cc: Marco Tiloca >= > > Subject: Re: [Ace] AIF as discussed today (Re: I-D Action: > draft-bormann-core- > > ace-aif-08.txt) > > > > Hi Carsten, > > > > Thanks for this quick update! Just some short high level > comments, to make > > sure we can use this for ace-key-groupcomm-oscore. > > > > In ace-key-groupcomm-oscore, we would say that Toid is the > identifier of the > > OSCORE group, so the OSCORE "group name", which is encoded as a > bstr. For > > Tperm, it's a bit further away from what the aif document > specifies (which is > > why I want to check with you), but we would go for array of > tstr, since we can't > > really encode the permission to be a "monitor" node (for example)= by > > indicating a REST method. This is a bit stretched from the > document right now, > > but it should work. > > > > We would have to register a media type (and content format) for > this, so what > > would this be? You use aif+cbor for the default, so maybe > something like "aif- > > ace-group+cbor". For section 5.3, we would have to register Toid > and Tperm > > with something like: > > > > Toid registry: > > * name: gname > > * description: group name of the OSCORE group as specified in > ace-key- > > groupcomm-oscore > > > > Tperm registry: > > * name: roles > > * description: role of the group member as specified in > ace-key-groupcomm- > > oscore > > > > I think we are missing some form of "encoding" column in the > registries above. > > In that case it would be "bstr" for Toid gname and "CBOR array > of tstr" for > > Tperm role. It would also be "tstr" for local-part Toid and > "int" for Tperm REST- > > method-set. (also, minor, but you sometimes use "local-part" and > sometimes > > "local-uri", see section 4). Even better, the description or the > encoding in the > > registry could point to "path" and "permissions" cddl, for the > default values in > > the aif doc. > > > > Using "array of tstr" for roles allows us to express what we > need for "set of > > roles". I don't see this being in contrast with the aif document > right now. > > This follows what I would expect, for MQTT I would see > > AIF-MQTT =3D AIF_Generic > filter =3D tstr > permissions =3D [ +permission ] > permission =3D "publish" / "subscribe" > > For the group comm draft, I think that > > AIF-GROUP-COM =3D AIF_Generic > path =3D tstr=C2=A0 ; group name > permissions =3D uint . bits methods > methods =3D &( > =C2=A0 =C2=A0 requester =3D 1, > =C2=A0 =C2=A0responder =3D 2, > =C2=A0 =C2=A0monitor =3D 3, > =C2=A0 =C2=A0verifier =3D 4 > ) > > This does require a registry if we ever expect this to grow. > > > So all in all, I think this can work for > ace-key-groupcomm-oscore. Please let me > > know if you see anything that bothers you in my summary. > > > > Thanks, > > Francesca > > > > =EF=BB=BFOn 23/06/2020, 00:17, "Ace on behalf of Carsten Bormann"= > bounces@ietf.org on behalf of > cabo@tzi.org > wrote: > > > >=C2=A0 =C2=A0 =C2=A0I went ahead and quickly implemented what we h= ad discussed > today. > > > >=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/id/draft-bormann-core-ace= -aif-08.html > > > >=C2=A0 =C2=A0 =C2=A0Lots more editing to do, but the gist of what = I was trying > to say should be > > there. > >=C2=A0 =C2=A0 =C2=A0Comments welcome! > > > >=C2=A0 =C2=A0 =C2=A0Gr=C3=BC=C3=9Fe, Carsten > > > > > >=C2=A0 =C2=A0 =C2=A0> On 2020-06-23, at 00:12, internet-drafts@iet= f.org > wrote: > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> A New Internet-Draft is available from the o= n-line > Internet-Drafts > > directories. > >=C2=A0 =C2=A0 =C2=A0> This draft is a work item of the Authenticat= ion and > Authorization for > > Constrained Environments WG of the IETF. > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0: An Authorization Information > Format (AIF) for ACE > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 : Carsten Bormann > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename=C2= =A0 =C2=A0 =C2=A0 =C2=A0 : draft-bormann-core-ace-aif-08.txt > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 9 > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2020-06-22 > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> Abstract: > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0Constrained Devices as they are = used in the "Internet of > Things" need > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0security.=C2=A0 One important el= ement of this security is > that devices in > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0the Internet of Things need to b= e able to decide which > operations > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0requested of them should be cons= idered authorized, need > to ascertain > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0that the authorization to reques= t the operation does > apply to the > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0actual requester, and need to as= certain that other > devices they place > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0requests on are the ones they in= tended. > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0To transfer detailed authorizati= on information from an > authorization > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0manager (such as an ACE-OAuth Au= thorization Server) to a > device, a > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0representation format is needed.= =C2=A0 This document provides > a suggestion > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0for such a format, the Authoriza= tion Information Format > (AIF).=C2=A0 AIF > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0is defined both as a general str= ucture that can be used > for many > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0different applications and as a = specific refinement that > describes > >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0REST resources and the permissio= ns on them. > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> The IETF datatracker status page for this dr= aft is: > >=C2=A0 =C2=A0 =C2=A0> https://datatracker.ietf.org/doc/draft-borma= nn-core-ace-aif/ > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> There are also htmlized versions available a= t: > >=C2=A0 =C2=A0 =C2=A0> https://tools.ietf.org/html/draft-bormann-co= re-ace-aif-08 > >=C2=A0 =C2=A0 =C2=A0> > https://datatracker.ietf.org/doc/html/draft-bormann-core-ace-aif-08= > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> A diff from the previous version is availabl= e at: > >=C2=A0 =C2=A0 =C2=A0> > https://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-core-ace-aif-08 > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> Please note that it may take a couple of min= utes from the > time of > > submission > >=C2=A0 =C2=A0 =C2=A0> until the htmlized version and diff are avai= lable at > tools.ietf.org . > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> Internet-Drafts are also available by anonym= ous FTP at: > >=C2=A0 =C2=A0 =C2=A0> ftp://ftp.ietf.org/internet-drafts/ > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> > >=C2=A0 =C2=A0 =C2=A0> ____________________________________________= ___ > >=C2=A0 =C2=A0 =C2=A0> I-D-Announce mailing list > >=C2=A0 =C2=A0 =C2=A0> I-D-Announce@ietf.org > >=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/mailman/listinfo/i-d-an= nounce > >=C2=A0 =C2=A0 =C2=A0> Internet-Draft directories: http://www.ietf.= org/shadow.html > >=C2=A0 =C2=A0 =C2=A0> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt= > > > >=C2=A0 =C2=A0 =C2=A0______________________________________________= _ > >=C2=A0 =C2=A0 =C2=A0Ace mailing list > >=C2=A0 =C2=A0 =C2=A0Ace@ietf.org > >=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/ace > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --=20 Marco Tiloca Ph.D., Senior Researcher RISE Research Institutes of Sweden Division ICT Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --------------0EC18240B25422F4D4A0BAED Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi,

I think AIF-GROUP-COM as defined below works well for ace-key-groupcomm-oscore.

It sounds safe to also have a register for the role integer values.
Thanks,
/Marco

On 2020-06-23 22:27, Cigdem Sengul wrote:
This looks what=C2=A0I expected from the MQTT poin= t of view. Thanks, Jim.=C2=A0
I will look into adding the change to the profile document now.=C2=A0
Kind regards,=C2=A0
--Cigdem=C2=A0


On Tue, Jun 23, 2020 at 4:4= 8 PM Jim Schaad <ietf@augustcellars.com> wrote= :
=

> -----Original Message-----
> From: Ace <ace-bounces@ietf.o= rg> On Behalf Of Francesca Palombini
> Sent: Tuesday, June 23, 2020 6:45 AM
> To: Carsten Bormann <cabo@tzi.org&g= t;; Ace Wg <ace@ietf.org>
> Cc: Marco Tiloca <marco.tiloca@ri.se= >
> Subject: Re: [Ace] AIF as discussed today (Re: I-D Action: draft-bormann-core-
> ace-aif-08.txt)
>
> Hi Carsten,
>
> Thanks for this quick update! Just some short high level comments, to make
> sure we can use this for ace-key-groupcomm-oscore.
>
> In ace-key-groupcomm-oscore, we would say that Toid is the identifier of the
> OSCORE group, so the OSCORE "group name", which is encoded as a bstr. For
> Tperm, it's a bit further away from what the aif document specifies (which is
> why I want to check with you), but we would go for array of tstr, since we can't
> really encode the permission to be a "monitor" node (for example) by
> indicating a REST method. This is a bit stretched from the document right now,
> but it should work.
>
> We would have to register a media type (and content format) for this, so what
> would this be? You use aif+cbor for the default, so maybe something like "aif-
> ace-group+cbor". For section 5.3, we would have to register Toid and Tperm
> with something like:
>
> Toid registry:
> * name: gname
> * description: group name of the OSCORE group as specified in ace-key-
> groupcomm-oscore
>
> Tperm registry:
> * name: roles
> * description: role of the group member as specified in ace-key-groupcomm-
> oscore
>
> I think we are missing some form of "encoding" column in the registries above.
> In that case it would be "bstr" for Toid gname and "CBOR array of tstr" for
> Tperm role. It would also be "tstr" for local-part Toid and "int" for Tperm REST-
> method-set. (also, minor, but you sometimes use "local-part" and sometimes
> "local-uri", see section 4). Even better, the description or the encoding in the
> registry could point to "path" and "permissions" cddl, for the default values in
> the aif doc.
>
> Using "array of tstr" for roles allows us to express what we need for "set of
> roles". I don't see this being in contrast with the aif document right now.

This follows what I would expect, for MQTT I would see

AIF-MQTT =3D AIF_Generic<filter, permissions>
filter =3D tstr
permissions =3D [ +permission ]
permission =3D "publish" / "subscribe"

For the group comm draft, I think that

AIF-GROUP-COM =3D AIF_Generic<path, permisions>
path =3D tstr=C2=A0 ; group name
permissions =3D uint . bits methods
methods =3D &(
=C2=A0 =C2=A0 requester =3D 1,
=C2=A0 =C2=A0responder =3D 2,
=C2=A0 =C2=A0monitor =3D 3,
=C2=A0 =C2=A0verifier =3D 4
)

This does require a registry if we ever expect this to grow.
> So all in all, I think this can work for ace-key-groupcomm-oscore. Please let me
> know if you see anything that bothers you in my summary. >
> Thanks,
> Francesca
>
> =EF=BB=BFOn 23/06/2020, 00:17, "Ace on behalf of Carsten B= ormann" <ace-
> bounces@ietf.org on behalf of cabo@tzi.org> wrote:
>
>=C2=A0 =C2=A0 =C2=A0I went ahead and quickly implemented wh= at we had discussed today.
>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/id/draft-bormann-core-ace-aif-08.html
>
>=C2=A0 =C2=A0 =C2=A0Lots more editing to do, but the gist o= f what I was trying to say should be
> there.
>=C2=A0 =C2=A0 =C2=A0Comments welcome!
>
>=C2=A0 =C2=A0 =C2=A0Gr=C3=BC=C3=9Fe, Carsten
>
>
>=C2=A0 =C2=A0 =C2=A0> On 2020-06-23, at 00:12, internet-drafts@ietf.org wrote:<= br> >=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> A New Internet-Draft is available = from the on-line Internet-Drafts
> directories.
>=C2=A0 =C2=A0 =C2=A0> This draft is a work item of the A= uthentication and Authorization for
> Constrained Environments WG of the IETF.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: An Authorization Information Format (AIF) for ACE
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Carsten Bormann
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0F= ilename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-bormann-core-ace-aif-08.txt
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0P= ages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 9
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0D= ate=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2020-06-22
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Abstract:
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0Constrained Devices as= they are used in the "Internet of Things" need
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0security.=C2=A0 One im= portant element of this security is that devices in
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0the Internet of Things= need to be able to decide which operations
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0requested of them shou= ld be considered authorized, need to ascertain
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0that the authorization= to request the operation does apply to the
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0actual requester, and = need to ascertain that other devices they place
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0requests on are the on= es they intended.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0To transfer detailed a= uthorization information from an authorization
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0manager (such as an AC= E-OAuth Authorization Server) to a device, a
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0representation format = is needed.=C2=A0 This document provides a suggestion
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0for such a format, the= Authorization Information Format (AIF).=C2=A0 AIF
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0is defined both as a g= eneral structure that can be used for many
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0different applications= and as a specific refinement that describes
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0REST resources and the= permissions on them.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> The IETF datatracker status page f= or this draft is:
>=C2=A0 =C2=A0 =C2=A0> https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> There are also htmlized versions a= vailable at:
>=C2=A0 =C2=A0 =C2=A0> https://tools.ietf.org/html/draft-bormann-core-ace-aif-08
>=C2=A0 =C2=A0 =C2=A0> https://datatracker.ietf.org/doc/html/draft-bormann-core-ace-aif-08<= br> >=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> A diff from the previous version i= s available at:
>=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/rfcdiff?url2=3Ddraft-bormann-core-ace-aif-08 >=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Please note that it may take a cou= ple of minutes from the time of
> submission
>=C2=A0 =C2=A0 =C2=A0> until the htmlized version and dif= f are available at tools.ietf.org= =2E
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> Internet-Drafts are also available= by anonymous FTP at:
>=C2=A0 =C2=A0 =C2=A0> ftp://ftp.ietf.org/internet-drafts/
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> __________________________________= _____________
>=C2=A0 =C2=A0 =C2=A0> I-D-Announce mailing list
>=C2=A0 =C2=A0 =C2=A0> I-D-Announce@ietf.= org
>=C2=A0 =C2=A0 =C2=A0> https://www.ietf.org/mailman/listinfo/i-d-announce
>=C2=A0 =C2=A0 =C2=A0> Internet-Draft directories: http://www.ietf.or= g/shadow.html
>=C2=A0 =C2=A0 =C2=A0> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________= ________
>=C2=A0 =C2=A0 =C2=A0Ace mailing list
>=C2=A0 =C2=A0 =C2=A0Ace@ietf.org
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/ace
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace

--=20
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistag=C3=A5ngen 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www=
=2Eri.se
--------------0EC18240B25422F4D4A0BAED-- --bHR44HTNFaIRXVjsmHbFo07zzAjH7dHOD-- --wnG0I2rBzGt58A1BKfy5Uky9YEc0oqVb9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl7yaRYACgkQ7iZktA5Y 2kPqqgf9HSe29yidkUvjNzvGdDV+n5jfBXsVp4EWdMcFal8T6jOuQM50R/ZEI+/O Hd7hNGCvbWLx6QnTnmB1X9aYn+U/2CzhinjL6Iw3rY69vGGvmRNDk1yezXHqJP79 kMm2vn/BHzcM/hSvxvR62nHaSEemqfTxh1tfF3Hj0wIPHhNCHaCUptbiI6oUZQQh iOpJ9CBDpl+sFoCVAfmu7mCsdnUZbgmQYL0HljC8DeaZPjgjMx49WBk7og9Zlmrr 5ZEr9N6AUb+d2mdTd1HZmgB4qBwRIY6lTH4gvvEmKHaamPw6Fv6srRAtF0Aqvn4T Kx/ixWZd/QX9dKCOCYp+AEtKl6z3sA== =y5Ny -----END PGP SIGNATURE----- --wnG0I2rBzGt58A1BKfy5Uky9YEc0oqVb9-- From nobody Tue Jun 23 19:49:39 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3E83A0112; Tue, 23 Jun 2020 19:49: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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEjILb7N6qtz; Tue, 23 Jun 2020 19:49:37 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA45A3A011B; Tue, 23 Jun 2020 19:49:36 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Jun 2020 19:49:29 -0700 From: Jim Schaad To: CC: 'Ace Wg' Date: Tue, 23 Jun 2020 19:49:28 -0700 Message-ID: <013701d649d2$16105fe0$42311fa0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AdZJg4vX2cf40W+ES0yFIolQeLHTHg== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Review of draft-bormann-core-ace-aif-08 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 02:49:38 -0000 This is a clean review so the last one most likely still applies. * From my review of the group comm document. There needs to be an easy way to talk about a single entry in the array of all permissions. Some times you only want to ask for one thing and not deal with permissions for any other Toid. Perhaps also define an AIF-Generic-One<> * Section 3 - I think you might want to highlight that the first bullet implies that once a Toid is found, then there is no need to continue searching. The array allows this because it is an ordered list. Optional to toss the authorization set if a duplicate Toid is found. (And no, I don't want to switch to a map.) * Section 3 - the previous statement is correct for this data model. Should it be a requirement for all data models encoded with this? (I think yes) * Section 3 - I am happy that you are pushing the JSON encoding as a text string!!! * Section 2.1 - I think it would be better to use one of the URI naming parts than using local-part as the identifier assigned here. My problem is that local-part is a term I associate with email addresses. Perhaps "path-query" with or without a leading uri would be a better name. * Section 2.2 - Some of the implementations might be avoided by making a single operation into a series of steps which can then be checked. Thus "opening an unlocked door" becomes two steps "unlock a door" and "open a door" with different permissions set for each. * Section ?? - We should probably say something about the use of "0" for permissions in this model. Is this legal and means nothing else? Jim From nobody Wed Jun 24 01:49:45 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E88A33A0C7D; Wed, 24 Jun 2020 01:49:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.4.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159298857990.29068.5028390336512857943@ietfa.amsl.com> Date: Wed, 24 Jun 2020 01:49:39 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-35.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 08:49:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-35.txt Pages : 87 Date : 2020-06-24 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-35 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-35 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-oauth-authz-35 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 Wed Jun 24 01:54:01 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 224083A0C9C for ; Wed, 24 Jun 2020 01:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rx33v-Jw7dp2 for ; Wed, 24 Jun 2020 01:53:57 -0700 (PDT) Received: from weald.air.saab.se (weald.air.saab.se [136.163.212.3]) (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 5090D3A0C9B for ; Wed, 24 Jun 2020 01:53:56 -0700 (PDT) Received: from mailhub2.air.saab.se ([136.163.213.5]) by weald.air.saab.se (8.14.4/8.14.4) with ESMTP id 05O8rsmb010091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 24 Jun 2020 10:53:54 +0200 DKIM-Filter: OpenDKIM Filter v2.11.0 weald.air.saab.se 05O8rsmb010091 Received: from corpappl16596.corp.saab.se (corpappl16596.corp.saab.se [10.12.12.128]) by mailhub2.air.saab.se (8.13.8/8.13.8) with ESMTP id 05O8qjGL026072 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 24 Jun 2020 10:52:45 +0200 Received: from corpappl16595.corp.saab.se (10.12.12.127) by corpappl16596.corp.saab.se (10.12.12.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1979.3; Wed, 24 Jun 2020 10:52:45 +0200 Received: from corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f]) by corpappl16595.corp.saab.se ([fe80::3c3e:6470:4c56:a86f%4]) with mapi id 15.01.1979.003; Wed, 24 Jun 2020 10:52:45 +0200 From: Seitz Ludwig To: "ace@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-oauth-authz-35.txt Thread-Index: AQHWSgSczDpgwxnDCUetZOFDK+96UajndThA Date: Wed, 24 Jun 2020 08:52:44 +0000 Message-ID: <7a74047cc17d408fb878bcf4d797c880@combitech.se> References: <159298857990.29068.5028390336512857943@ietfa.amsl.com> In-Reply-To: <159298857990.29068.5028390336512857943@ietfa.amsl.com> Accept-Language: en-SE, sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.12.13.199] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Saab-MailScanner-Information: Please contact the ISP for more information X-Saab-MailScanner-ID: 05O8qjGL026072 X-Saab-MailScanner: Found to be clean X-Saab-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-0.881, required 5, autolearn=not spam, ALL_TRUSTED -1.00, SURBL_BLOCKED 0.12, URIBL_BLOCKED 0.00) X-Saab-MailScanner-From: ludwig.seitz@combitech.se X-Saab-MailScanner-Watermark: 1593593566.35183@NHI7UcElVqi9XNyJGBBB5w X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (weald.air.saab.se [136.163.212.3]); Wed, 24 Jun 2020 10:53:54 +0200 (CEST) Archived-At: Subject: [Ace] FW: I-D Action: draft-ietf-ace-oauth-authz-35.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2020 08:54:00 -0000 Hello ACE, Sadly my -34 update contained an unintended change that we earlier discusse= d and rejected. -35 reverts this mistaken update. Sorry for that. (Note to self: check diffs before submitting) /Ludwig -----Original Message----- From: Ace On Behalf Of internet-drafts@ietf.org Sent: den 24 juni 2020 10:50 To: i-d-announce@ietf.org Cc: ace@ietf.org Subject: [Ace] I-D Action: draft-ietf-ace-oauth-authz-35.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Authentication and Authorization for Const= rained Environments WG of the IETF. Title : Authentication and Authorization for Constrained = Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth) Authors : Ludwig Seitz Goeran Selander Erik Wahlstroem Samuel Erdtman Hannes Tschofenig Filename : draft-ietf-ace-oauth-authz-35.txt Pages : 87 Date : 2020-06-24 Abstract: This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oauth-authz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-35 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oauth-authz-35 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ace-oauth-authz-35 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace From nobody Thu Jun 25 21:01:58 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769BE3A1107; Thu, 25 Jun 2020 21:01:56 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NklTPt7v9ZsY; Thu, 25 Jun 2020 21:01:54 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEDF43A1106; Thu, 25 Jun 2020 21:01:53 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 25 Jun 2020 21:01:47 -0700 From: Jim Schaad To: CC: Date: Thu, 25 Jun 2020 21:01:45 -0700 Message-ID: <023501d64b6e$83ea3b60$8bbeb220$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AdZHAmDAxxC2glJWS92Qm/d7WHm5Hg== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Review of ietf-ace-key-groupcomm-07 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2020 04:01:57 -0000 * Section 1 para 1 - I have a vague memory of deciding that we were going to become CBOR only with this document per the argument from Carsten. I did not find this in the minutes so this could easily be some other document that I am thinking of. * Section 2 - I have a problem with Figure 1 in terms of what is labeled as an RS. The text below calls the KDC and RS and not the Dispatcher. * Section 2 - update DTLS reference * Section 2 - I think you might want the last sentence to refer to step 3 rather than section - The pointer to the section has already been provided but pointing back to the figure makes a degree of sense. * Section 2 - KDC - This is the first time that I have heard about the fact that this is a two part protocol - You should tell me about the phases before you get here. * Section 2 - "Leaving or removing" this is a sentence which does not read well. (Also why is this current when no other line is.) * Section 2 - You should probably have a numbered item that corresponds to the secure group communication line in the picture. * Section 3 - The content format application/ace+cbor is not defined by the transport profiles but by the framework. * Section 3.1 - Given that a role is defined as a tstr, that format is not usable if one wishes to assign an integer abbreviation per OPT7. * Section 3.1 - the "Other additional" seems to be a strange thing to have in this list because it does not match the lead in paragraph. * Section 3.1 - Is there a reason that a gid is a bstr and not a tstr. I assume that this is the same as GROUPNAME which much be a text string to be in a url-path. * Section 3.2 - s/non expired/non-expired/ * Section 3.2 - the def of scope seems odd because it is not well defined if it would be the same as the requested scope. (AS response) * Section 3.2 - the text w/ scope can be simplified to the scope that the AS grants access to and skip the last sentence. * Section 3.2 - ditto w/ above on "other additional" * Section 3.3 - s/request necessary information/request information/ * Section 3.3 - Am I supposed to know why I care about public keys at this point? * Section 3.3 - last sentence of the text implies that sign_info and pub_key_enc are required. Last sentence of para 2 needs to be re-written * Section 3.3 - should identify what sign_info is for. * Section 3.3 - are you imposing a new requirement that the token be validated prior to returning the response to a token post? As I remember it, this is not required to happen prior to the response being returned just before access is granted. (I.e. you can validate the token in parallel) (After successful verification...) * Section 3.3 - "payload of response deviates" I don't believe that this is a true statement. However, you should state at tis point how it deviates if you believe it does. I assume that you mean that there is a payload as oppose to no payload. * Section 3.3 - You would not be able to reuse the same kdcchallenge value with a different key. It would not have any way of being associated with that key and would look like somebody else was attempting to use the value. * Section 3.3 - s/were included in the request/are included in the request/ present tense. * Section 3.3 - Do you really mean to say "request includes pub_key_enc", "response does not include pub_key_enc"? That seems to be wrong in the general case. Also seems to say the same thing about 'sign_info'. Also seems to contradict the next paragraph. * Section 3.3 - The forward reference for sign_info is incorrect - it should be 3.3.1. (I also don't know if you need this two paragraphs in a row.) * Same paragraph - group identifier or group name? You need to do a detailed pass through the document and look at every instance of this string and either make it an identifier or a name and perhaps add these to the terminology section so that one can quickly look back to distinguish them. Perhaps you should be using context identifier rather than group identifier just to make it clearer the difference between what goes into the different locations. The problem with that is it is OSCORE specific so it may not work well. * Section 3.3 - last paragraph - should this be referring to applications or profiles? -- really a global question. Consider - is the OSCORE profile attached to a specific application or to a set of unknown applications? * Section 3.3.1 - s/one ore more/one or more/ * Section 3.3.1 - s/is lower or at most equal to/is at most/ - also what happen if the response would include zero elements? You asked and nothing needs to be returned? * Section 3.3.1 - second bullet - kill the "if included" text. This is covered above. * Section 3.3.1 - s/sign_info/sign_info/ * Section 3.3.1 - This is looking really complicated and I don't know why you don't just simplify it down to a single request/response pair. Define a value for use when the server either does not know or does not want to share a value and so forth. The size of data if sign_info were to be omitted is almost the same size as if it where present so that does not seem to be much of a win. Making the answer one byte longer for adding the pub_key_enc_res field does not seem to be a huge problem for a one-time message. * Section 3.3.1 - The first paragraph implies that pub_key_enc would be in the reply but don't have any information about what that would look like. See also previous item. * Section 3.3.3 - s/((/(/ * Section 4 - why are you calling this the first exchange with the KDC - who was I talking to in section 3? * Section 4 - are the policies new or just retrieved? May want to swap order. * Section 4 - are we still specifying a group to join or is that implicit in the URL? Tell me how it is specified? * Section 4 - I don't think that the (re-) is helping understanding here. * Section 4 - what type of individual key is being obtained in bullet 2 - how is this different than getting the current keying material? * Section 4 - Who is enforcing the policies? Just retrieve the policies. * Section 4 - I don't think the e.g. in getting public keys serves a purpose here. * Section 4 - I am not sure what the "at hand" is supposed to be providing. /for the requested group identifier/ * Section 4.1 - do we want to make the if value be a dot tree? ace.group * Section 4.1 - The bullet for /ace-group seems to indicate that the name is fixed which is the opposite of what the previous paragraph says. I find this confusing. I really find it confusing that this document is specifying a url-path name is being specified, and the oscore document immediately uses a different value. * Section 4.1 - what does it mean for a sub-resource to be "fixed". Does that mean it never changes? * Section 4.1 - a brief description of what is in the resource would be helpful here. "pub-key: this resource contains the public keys of all group members. The resource supports the GET and FETCH methods." * Section 4.1 - Yes but what is a NODENAME and why do I care about it? * Section 4.1.2.1 - It would be useful in the first paragraph to re-iterate that this is the "join" operation The current description seems to be really odd. * Section 4.1.2.1 - get_pub_keys - One consideration that needs to be highlighted for a constrained device is that this may result in a large return value and it may be better to get them only as needed. * Section 4.1.2.1 - It would be nice to be able to use get_pub_keys with a filter so that only responders are returned. * Section 4.1.2.1 - 'client_cred' the description of when this field is used does not seem to include a server which only responds to an individual. It could be said in that case that it is not sending messages "to the group" but only to a member of the group. * Section 4.1.2.1 - 'conce' why bother pointing to ACE for a description of this document. This is not a framework message so I am not sure why this is interesting. * Section 4.1.2.1 - Which scope is being used, the one in this message (assuming it exists) or the one in the token? If the message does not have one then what happens? Deterministic encoding? * Section 4.1.2.1 - s/token is not being posted/token was not posted/ * Section 4.1.2.1 - formatting - the follow on paragraph to 'client_cred_verify' should be indented a level * Section 4.1.2.1 - You missed the merge of sign_info and pub_key_enc in the error handling paragraph. * Section 4.1.2.1 - What is the reasoning behind returning the sign_info_res field if the group is not in the scope. This is not related to the failure in any way. Seems more like this would return a pointer to the AS rather than anything else. * Section 4.1.2.1 - How much can I just ignore rather than error? If you send me a public key and I don't care about it why can I not just ignore that fact and go forward? I both agree and disagree with the idea that erroring on unknown fields is the correct way to proceed. * Section 4.1.2.1 /succed/succeeded/ * Section 4.1.2.1 - (para before bullet) I don't like the idea that if you send me a public key, I would use the stored one before looking at the one that is in the join message. This seems to be backwards behavior. Note the paragraph following the bullets is saying exactly the opposite thing a this one is. * Section 4.1.2.1 - I am not clear on the following situation: Key P1 is associated with groupX, I do a second join and send key P1 but have a cred verify that would fail. Am I expected to detect this and error or say that because you have already verified P1 it does not matter? * Section 4.1.2.1 - both bullets are talking about failed verification - kill the redundancy. * Section 4.1.2.1 - 'num' the rule on the initial value of num should be put into a section about setting up a group not here. * Section 4.1.2.1 - 'num' vs 'ctx-num' should be harmonized. * Section 4.1.2.1 - exp_delta should specify a default if it is not in the message. I there a reason that this is not a policy for the group? * Section 4.1.2.2 - Ditto to above on the field being returned in the event of 4.01 * Section 4.1.2.2 - I don't understand the need for 'gkty' as that I should know from the join and it should never change in the life of the group. I would also expect that 'exp' is something that at least SHOULD be included as that does change and is useful to have. * Section 4.1.2.2 - Is the 'key' value expected to be modified for the requester? * Section 4.1.3.1 - What is the reason for having a map in this request type. Why not just have the array itself? * Section 4.1.3.1 - Looks like a formatting error 2 paragraphs after figure 7 * Section 4.1.3.1 - The text on the first selection criteria has me really messed up because I am not sure that * Section 4.1.3.1 - If not storing keys, should this return either resource not found or not supported as an error code instead of an empty response? * Section 4.1.3.1 - s/resource handlers only verify/resource handler only verifies/ Unless you move it up one level. * Section 4.1.4.1 - can we get rid of the map? * Section 4.1.6.1 - I have no idea from the text why I would use this method. * Section 4.1.6.3 - para 2 - the first sentence does not make any sense to me. How could the handler accept a request for a node does not match "NODENAME" as that is the url-path? * Section 4.2 - "retrieve individual or group keying material" What individual material? * Section 4.3 - /target the URI path possibly provided by/ This text either needs to be a definitive method or some type of alternative method needs to be provided. * Section 4.3 - I am worried about congestion in more places than just for Observe. If a server is sending lots of messages out to clients on a one-to-one basis it could easily flood the network. * Section 4.4 - What does the first sentence even mean? It seems to be almost a circular argument. * Section 4.4 - I find the title of 4.4 to be somewhat misleading. As far as I can tell this is only talking about one type of renewal, but even that is not clear to me. * Section 4.4 - Why would it require an error in the event that a full rekey is going to be done by the server, can't it just do the full renewal and return the answer to the PUT? * Section 4.5 - Is the second paragraph in the wrong place? I don't really care what the client does only what the server does. * Section 4.6 - /After distributing the new group keying material/ This should be done before doing that - it should also be committed long term storage if one expects the KDC to restart w/o a forced rekey event. And even then it potentially should have a new context number. * Section 5 - see previous comment * Section 5 - Does the use of the DELETE method to inform a client that it is no longer part of the group imply that a different control path is needed for every group that the client joins? I don't know that I was expecting that. Section 7 - / end of the rekeying process and the next loss of security state/ This is not what I was trying to get at and it makes no sense to me. The question is the interval between the end of the last rekey process and the client joining the group. If that is small enough then replay will not work. Section 7 /the Observations up to that point/ this does not make any sense. You can lose who I currently doing the observation but you have already tossed all of the observations themselves even without a reboot. Section 7 - I don't understand the conditions you have laid out for doing delayed rekeying I would expect that it is a minimum number OR a maximum interval. But I don't think that is what this says. Section 7 - This is a tic that I am trying to stop in my own writing. Look at all instances of "In fact," and they can probably be removed. The other one that I use a lot is "Actually," Section 7 - s/initiating rekeys/initiating rekey events/ Section 7.1 - Para 2 - it would not be a second try as the KID context field would be different in general. Jim From nobody Sat Jun 27 00:36:39 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB9D3A0112; Sat, 27 Jun 2020 00:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 qOi9UTV0ETF8; Sat, 27 Jun 2020 00:36:30 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D98E3A02BE; Sat, 27 Jun 2020 00:36:30 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49v5Cw3B9zzyWX; Sat, 27 Jun 2020 09:36:28 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 614936187.9916019-bef90aaa2d26cc00a43c1ed5be064893 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Sat, 27 Jun 2020 09:36:28 +0200 Message-Id: To: Ace Wg , core@ietf.org, cose@ietf.org, cbor@ietf.org, t2trg@irtf.org X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Ace] Constrained Node/Network Cluster @ IETF108: DRAFT AGENDA X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 07:36:35 -0000 Here is my usual eclectic condensed agenda based on the DRAFT AGENDA for IETF108. Remember that there is still quite some potential for changes. Conflicts that meet the eye: LAKE/SUIT (!). ACE/RATS. (I think 6LO/COSE can be ignored.) HACKATHON is on top of CORE, but I don't know what that slot on Friday is supposed to be. All times appear to be in UTC, even though nothing says so; https://datatracker.ietf.org/meeting/agenda-utc gives the same times. Gr=C3=BC=C3=9Fe, Carsten MONDAY, July 27, 2020 1100-1240 Session I Rm 1 ART dispatch Dispatch WG Rm 5 IRTF pearg Privacy Enhancements and Assessments = Research Group Rm 2 SEC *** teep Trusted Execution Environment = Provisioning WG 1300-1350 Session II Rm 4 ART *** cbor Concise Binary Object Representation = Maintenance and Extensions WG Rm 6 INT intarea Internet Area Working Group WG Rm 2 RTG babel Babel routing protocol WG Rm 5 RTG detnet Deterministic Networking WG 1410-1550 Session III Rm 5 ART webtrans WebTransport WG Rm 4 IRTF qirg Quantum Internet Research Group Rm 2 SEC gnap Grant Negotiation and Authorization = Protocol WG TUESDAY, July 28, 2020 1100-1240 Session I Rm 1 ART *** asdf A Semantic Definition Format for Data = and Interactions of Things BOF Rm 2 INT 6man IPv6 Maintenance WG Rm 3 IRTF irtfopen IRTF Open Meeting Rm 8 TSV masque Multiplexed Application Substrate over = QUIC Encryption WG 1300-1350 Session II Rm 4 SEC mls Messaging Layer Security WG Rm 3 SEC *** rats Remote ATtestation ProcedureS WG 1410-1550 Session III Rm 4 SEC *** lake Lightweight Authenticated Key Exchange = WG Rm 3 SEC *** suit Software Updates for Internet of Things = WG Rm 2 TSV loops Local Optimizations on Path Segments BOF WEDNESDAY, July 29, 2020 1100-1240 Session I Rm 5 RTG bier Bit Indexed Explicit Replication WG Rm 4 SEC *** ace Authentication and Authorization for = Constrained Environments WG Rm 3 SEC *** rats Remote ATtestation ProcedureS WG Rm 2 TSV quic QUIC WG 1300-1350 Session II Rm 6 ART webtrans WebTransport WG Rm 2 INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Rm 4 RTG rift Routing In Fat Trees WG Rm 5 SEC *** cose CBOR Object Signing and Encryption WG Rm 1 TSV tsvarea Transport Area Open Meeting THURSDAY, July 30, 2020 1100-1240 Session I Rm 6 OPS anima Autonomic Networking Integrated Model = and Approach WG Rm 4 RTG raw Reliable and Available Wireless WG Rm 5 SEC secdispatch Security Dispatch WG Rm 2 TSV tsvwg Transport Area Working Group WG 1300-1350 Session II Rm 3 INT *** lpwan IPv6 over Low Power Wide-Area Networks = WG Rm 2 SEC saag Security Area Open Meeting 1410-1550 Session III Rm 6 INT add Adaptive DNS Discovery WG Rm 7 INT *** drip Drone Remote ID Protocol WG Rm 4 SEC acme Automated Certificate Management = Environment WG FRIDAY, July 31, 2020 1100-1240 Session I Rm 8 ART *** core Constrained RESTful Environments WG Rm 6 GEN hackathon Hackathon Rm 2 SEC tls Transport Layer Security WG Rm 1 TSV tsvwg Transport Area Working Group WG 1300-1350 Session II Rm 3 ART wpack Web Packaging WG Rm 4 INT 6man IPv6 Maintenance WG Rm 6 SEC emu EAP Method Update WG 1410-1550 Session III Rm 1 ART *** core Constrained RESTful Environments WG Rm 7 IRTF coinrg Computing in the Network Research Group Rm 3 SEC privacypass Privacy Pass WG From nobody Sat Jun 27 14:33:58 2020 Return-Path: X-Original-To: ace@ietf.org Delivered-To: ace@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C5163A080E; Sat, 27 Jun 2020 14:33:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.5.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159329363144.23981.7211703354609936998@ietfa.amsl.com> Date: Sat, 27 Jun 2020 14:33:51 -0700 Archived-At: Subject: [Ace] I-D Action: draft-bormann-core-ace-aif-09.txt X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 21:33:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Authentication and Authorization for Constrained Environments WG of the IETF. Title : An Authorization Information Format (AIF) for ACE Author : Carsten Bormann Filename : draft-bormann-core-ace-aif-09.txt Pages : 11 Date : 2020-06-27 Abstract: Constrained Devices as they are used in the "Internet of Things" need security. One important element of this security is that devices in the Internet of Things need to be able to decide which operations requested of them should be considered authorized, need to ascertain that the authorization to request the operation does apply to the actual requester, and need to ascertain that other devices they place requests on are the ones they intended. To transfer detailed authorization information from an authorization manager (such as an ACE-OAuth Authorization Server) to a device, a representation format is needed. This document provides a suggestion for such a format, the Authorization Information Format (AIF). AIF is defined both as a general structure that can be used for many different applications and as a specific refinement that describes REST resources and the permissions on them. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-bormann-core-ace-aif-09 https://datatracker.ietf.org/doc/html/draft-bormann-core-ace-aif-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-bormann-core-ace-aif-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 Sat Jun 27 14:44:17 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3FA3A0808 for ; Sat, 27 Jun 2020 14:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVhlhKRQO03R for ; Sat, 27 Jun 2020 14:44:13 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20AA3A0044 for ; Sat, 27 Jun 2020 14:44:12 -0700 (PDT) Received: from [192.168.217.116] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49vS232jTHzyZD; Sat, 27 Jun 2020 23:44:11 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <1A09E8B0-7330-4208-885A-D66C2FD0513B@tzi.org> Date: Sat, 27 Jun 2020 23:44:10 +0200 X-Mao-Original-Outgoing-Id: 614987050.637791-c7a8cbb57a10a19fb260dec6b1787f65 Content-Transfer-Encoding: quoted-printable Message-Id: <0D4BD2DD-81AE-4D99-9C60-EF70F1E5B4F0@tzi.org> References: <159286394732.28803.9776136105746750769@ietfa.amsl.com> <1A09E8B0-7330-4208-885A-D66C2FD0513B@tzi.org> To: Ace Wg X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: [Ace] AIF-09 (Re: AIF as discussed today (Re: I-D Action: draft-bormann-core-ace-aif-08.txt)) X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 21:44:15 -0000 Instead of working on the (great) comments in the reviews, I went ahead = and added permissions for dynamic resources. Enjoy: Html: = https://www.ietf.org/id/draft-bormann-core-ace-aif-09.html Htmlized: = https://tools.ietf.org/html/draft-bormann-core-ace-aif-09 Diff: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-bormann-core-ace-aif-09.txt (Yes, the comments are next, I just had to dump the results of recent = discussions into the draft first. EBRAINFULL) Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Jun 29 15:45:49 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 598873A0DCD; Mon, 29 Jun 2020 15:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWz4IgxlplSG; Mon, 29 Jun 2020 15:45:43 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 5E1B73A0DCE; Mon, 29 Jun 2020 15:45:42 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05TMjb4p031324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Jun 2020 18:45:40 -0400 Date: Mon, 29 Jun 2020 15:45:37 -0700 From: Benjamin Kaduk To: Olaf Bergmann Cc: draft-ietf-ace-dtls-authorize.all@ietf.org, ace@ietf.org Message-ID: <20200629224537.GX58278@kduck.mit.edu> References: <20200102234020.GI35479@kduck.mit.edu> <87pnca9gyx.fsf@wangari> <20200429011210.GC27494@kduck.mit.edu> <87mu6bn6zy.fsf@wangari> <20200527234227.GD58497@kduck.mit.edu> <87r1uczgyq.fsf@wangari> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87r1uczgyq.fsf@wangari> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 22:45:47 -0000 Hi Olaf, Thanks for the updated -11! Some minor replies below, though in general the proposals look good. On Thu, Jun 18, 2020 at 02:38:32PM +0200, Olaf Bergmann wrote: > Hi Benjamin, > > Benjamin Kaduk writes: > > > Thanks! I think we will probably need an -11 fairly soon, though, given > > the remaining comments I have. > > We have just submitted -11 that addresses your comments. See below for > detailed responses. I have trimmed-down the email thread context a bit > to improved readability and focus on the recent comments. > > > A couple general remarks looking at the -09-to-10 diff (not all new in > > the -10, so I guess I missed it the first time around): > > > > In Section 3.2.1, I suggest applying: > > > > OLD: > > [...] If CBOR web tokens [RFC8392] are used as recommended in > > [I-D.ietf-ace-oauth-authz] [...] > > > > NEW: > > [...] If CBOR web tokens [RFC8392] are used (as recommended in > > [I-D.ietf-ace-oauth-authz]) [...] > > > > Making this a parenthetical statement makes it clear that the > > conditional for "keys MUST be encoded" is "CWT are used" and separate > > from the recommendation to do so. > > Done > > > Also in 3.2.1, we now have these two statements in fairly close > > proximity: > > > > [RFC8747]. The resource server MUST use its own raw public key in > > the DTLS handshake with the client. If the resource server has > > several raw public keys, it must already know which key it is > > supposed to use with this client. How this is achieved is not part > > of this profile. > > > > The resource server MUST use the keying material that the > > authorizations server has specified in the "cnf" parameter in the > > access token for the DTLS handshake with the client. Thus, the > > > > which seems a bit redundant and potentially in conflict. Can we > > consolidate this requirement a bit? > > Yes, the wording is a bit confusing. The following proposal states > the intention more clearly, I think: > > NEW: > > The raw public key used in the DTLS handshake with the client MUST > belong to the resource server. If the resource server has several (Someone might complain that this first sentence is tautological, but I think we should leave it for now.) > raw public keys, it needs to determine which key to use. The > authorization server can help with this decision by including a > `cnf` parameter in the access token that is associated with this > communication. In this case, the resource server MUST use the > information from the `cnf` field to select the proper keying > material. > > > In Section 3.3: > > > > To convey the same secret to the resource server, the authorization > > server either includes it directly in the access token by means of > > the "cnf" claim or it provides sufficient information to enable the > > resource server to derive the key from the access token using key > > derivation. > > > > This text could be read as prohibiting using token introspection to > > obtain the C/RS shared key (if I remember correctly about "claim" being > > a CWT thing and not a more generic term for a parameter associated with > > a token). I don't think that's the intent, so perhaps a wording tweak > > is in order. > > This now has been changed to: > > NEW: > > To convey the same secret to the resource server, the > authorization server can include it directly in the access token > by means of the `cnf` claim or provide sufficient information to > enable the resource server to derive the shared secret from the > access token. As an alternative, the resource server MAY use token > introspection to retrieve the keying material for this access > token directly from the authorization server. > > > In Section 3.3.1: > > > > If a resource server receives a ClientKeyExchange message that > > contains a "psk_identity" with a length greater than zero, it MUST > > process the contents of the "psk_identity" field as access token that > > is stored with the authorization information endpoint, before > > continuing the DTLS handshake. If the contents of the "psk_identity" > > do not yield a valid access token for the requesting client, the > > resource server aborts the DTLS handshake with an "illegal_parameter" > > alert. > > > > The way this was reworded seems to imply that any "psk_identity" with > > positive length is a full access token (as would have been uploaded to > > the authz-info endpoint), which prevents the case previously described > > where the identity is just a COSE_Key with the 'kid' from "rs_cnf". So > > I think we still need some kind of description of two potential > > interpretations of the "psk_identity". > > Yes, this is misleading. We have changed it as follows to indicate the > two (non-exclusive) processing steps: > > OLD: > If a resource server receives a ClientKeyExchange message that > contains a `psk_identity` with a length greater than zero, it MUST > process the contents of the `psk_identity` field as access token > that is stored with the authorization information endpoint, before > continuing the DTLS handshake. If the contents of the > `psk_identity` do not yield a valid access token for the requesting > client, the resource server aborts the DTLS handshake with an > `illegal_parameter` alert. > > NEW: > > If a resource server receives a ClientKeyExchange message that > contains a `psk_identity` with a length greater than zero, it MUST > parse the contents of the `psk_identity` field as CBOR data > structure and process the contents as following: > > * If the data contains a `cnf` field with a `COSE_Key` structure > with a `kid`, the resource server continues the DTLS handshake > with the stored key associated with this kid. Maybe "corresponding" or "associated" stored key, since there is not necessarily a unique kid/key relationship? > * If the data comprises additional CWT information, this > information must be stored as access token for this DTLS nit: "as an" > association before continuing with the DTLS handshake. > > If the contents of the `psk_identity` do not yield sufficient > information to select a valid access token for the requesting > client, the resource server aborts the DTLS handshake with an > `illegal_parameter` alert. > > > In section 3.4, we updated the text about "a common understanding" > > between RS and AS about how access tokens are ordered, and reworded the > > text about checking authorization on every request. I think we could > > say a little bit more about how there is not a strict guarantee of > > processing order for requests and authorization updates, so requests > > that occur around the time of an authorization update might be processed > > using either the old or new authorization rules. Even just referencing > > Section 7.2 would be enough. > > This now has been clarified as follows, introducing another forward > reference: > > OLD: > The client MUST ascertain that its keying material is still valid > before sending a request or processing a response. If the client > gets an error response > > NEW: > > The client MUST ascertain that its keying material is still valid > before sending a request or processing a response. If the client > recently has updated the access token (see Section 4), it must be > prepared that its request is still handled according to the > previous authorization rules as there is no strict ordering > between access token uploads and resource access messages. See > also Section 7.2 for a discussion of access token > processing. > > > (more inline) > > > >> > On Tue, Apr 14, 2020 at 06:20:38PM +0200, Olaf Bergmann wrote: > >> >> Ben, > >> >> > >> >> Thanks again for the thorough review of the ACE DTLS profile and my > >> >> sincere apologies for the long time it took to process. Please find our > >> >> comments inline. As this comprises a lot of changes, the proposed text > >> >> already has been included in the Editor's copy [1]. Our proposals for > >> >> new text are in the section-by-section comments. > >> >> > >> >> [1] https://ace-wg.github.io/ace-dtls-profile/ > >> >> > >> >> Benjamin Kaduk writes: > >> >> > >> >> > Hi all, > >> >> > > >> >> > Some high-level remarks before delving into the section-by-section > >> >> > comments: > >> >> > > >> >> > This document is pretty clearly DTLS 1.2-specific -- it talks about > >> >> > particular protocol messages, message fields, and cipher suites that > >> >> > simply do not apply to DTLS 1.3. In order to use this profile with DTLS > >> >> > 1.3, we'd need to specify the analogous behavior/requirements to these > >> >> > (including standalone signature schemes and key-exchange groups, which > >> >> > are now both separately negotiated from the cipher suite). > >> >> > Given that DTLS 1.3 is past WGLC and only a few documents behind this > >> >> > one in my review queue, it seems fairly prudent to spend some time and > >> >> > cover how DTLS 1.3 would work here, since otherwise this document will > >> >> > become stale shortly after (or even before!) its publication as an RFC. > > > > Is anyone working on a DTLS 1.3 version? > > Steffi and I have been in the process of starting to take a closer look :-) I'm happy to hear it :) > > >> > I think we need to give some guidance about what the semantics are if/when > >> > it happens. My inclination would be to say that DTLS resumption can be > >> > used to amortize the cost of a handshake, but DTLS 1.2 resumption does not > >> > provide forward secrecy and also does not provide an opportunity for the > >> > client to prove possession of the PoP key, so servers will want to > >> > periodically force a full handshake according to their authentication > >> > requirements. I'd also be inclined to forbid renegotiation entirely. > >> > >> True, especially because RFC 7925 requires resumption to be > >> implemented. The security considerations now advise against session > >> resumptions and renegotiation as you have suggested. The Security > >> Considerations section now has been structured in sub-sections for > >> clarity. > > > > The discussion in the -10 is reasonable (and the stated motivation of > > having a fresh proof of possession is fairly compelling), though to be > > clear, my initial "inclination" above was just to forbid renegotiation > > but allow resumption. > > Sorry, I had misinterpreted that. Actually, I am not entirely > convinced by the "fresh PoP" argument anymore. When the access token > made its way to the server through the client, there is no significant > difference between keeping the DTLS session open and session > resumption. Additional security against breaching the encryption of > the (encrypted part of the) access token would be provided only by token > introspection. But in that case, session resumption again would not > harm security as we do not need to store precious information in the > session ticket. > > Are you in favor of allowing session resumption? I think it would be safe to allow resumption, but I personally am indifferent about whether or not we should do so. > >> >> NEW: > >> >> > >> >> The authorization server must ascertain that the keying material > >> >> for the client that it provides to the resource server actually is > >> >> associated with this client. Malicious clients may hand over > >> >> access tokens containing their own access permissions to other > >> >> entities. This problem cannot be completely > >> >> eliminated. Nevertheless, in RPK mode it should not be possible > >> >> for clients to request access tokens for arbitrary public keys, > >> >> since that would allow the client to relay tokens without the need > >> >> to share its own credentials with others. The authorization server > >> > > >> > I think this sentence could probably be wordsmithed some more, though I > >> > don't have a concrete proposal at the moment. It does seem like we might > >> > want to discuss this scenario more in terms of "identity misbinding" than > >> > "relay tokens", though. (We had a SAAG talk at IETF 104 about misbinding > >> > attacks on device pairing, which is not quite the same, but shares some of > >> > the concepts.) > >> > >> Okay. This is the only comment I did not yet address in the text. We > >> might want to keep this in mind for -11. > > > > Looking at it again, perhaps: > > > > % eliminated. Nevertheless, in RPK mode it should not be possible > > % for clients to request access tokens for arbitrary public keys: if the > > % client can cause the AS to issue a token for a public key without > > % proving possession of the corresponding private key, this allows for > > % identity misbinding attacks where the issued token is usable by an > > % entity other than the intended one. [...] > > Very good, thank you. > > >> >> OLD: > >> >> > >> >> The response also contains an access token and an "rs_cnf" > >> >> parameter containing information about the public key that is used > >> >> by the resource server. AS MUST ascertain that the RPK specified > >> >> in "rs_cnf" belongs to the resource server that C wants to > >> >> communicate with. > >> >> > >> >> NEW: > >> >> > >> >> The response also contains an access token with information about > >> >> the public key that is used by the resource server. The > >> > > >> > This sounds like "the information[...]" is part of the access token; maybe > >> > "along with"? > >> > >> What is meant here is that the information is contained in the access > >> token. The misleading part is that the AT contains information about the > >> client's RPK that the resource server uses to recognize the client in > >> the subsequent communication. > >> > >> I have changed this sentence to: > >> > >> NEW: > >> > >> The response also contains an access token with information for the > >> resource server about the client's public key. > > > > That should help a lot; thanks! > > > >> >> > The fields in the context information "COSE_KDF_Context" > >> >> > (Section 11.2 of [RFC8152]) have the following values: > >> >> > > >> >> > o AlgorithmID = "ACE-CoAP-DTLS-key-derivation" > >> >> > > >> >> > RFC 8152 says that these AlgorithmID values come from the COSE > >> >> > Algorithms registry, which this does not (unless we register it there, > >> >> > which we don't currently). Also, since the output is used directly for > >> >> > DTLS PSK, I don't think the "key-derivation" portion is needed. > >> >> > > >> >> > o PartyUInfo = PartyVInfo = ( null, null, null ) > >> >> > > >> >> > (8152 seems to prefer "nil" over "null".) > >> >> > > >> >> > o keyDataLength needs to be defined by the application > >> >> > > >> >> > o protected MUST be a zero length bstr > >> >> > > >> >> > o other is a zero length bstr > >> >> > > >> >> > (These three are all members of the "SuppPubInfo" field, which is not > >> >> > very clear from how we include them in the same list as top-level > >> >> > fields.) > >> >> > >> >> The example now has updated and rephrased according to HKDF usage. > >> > > >> > The formatting/discussion looks good, but I'll need to cross-check the data > >> > structures once the new revision is uploaded. > > > > I do like the presentation with HKDF and the structured input to it. > > > > However, I think we may have over-corrected w.r.t. key-id uniqueness: > > > > In order to generate a new symmetric key to be used by client and > > resource server, the authorization server generates a new key > > identifier which MUST be unique among all key identifiers used by the > > authorization server. The authorization server then uses the key > > > > I think this requirement for uniqueness global to the AS may be too > > strong; couldn't key identifiers be reused for different RSes? > > Having the kid be part of the input to HKDF keyed by a unique AS/RS > > shared key also helps a great deal to avoid accidental key collisions. > > True, uniqueness for each individual RS would be sufficient: > > OLD: > MUST be unique among all key identifiers used by the authorization > server. > > NEW: > MUST be unique among all key identifiers used by the authorization > server for this resource server. > > > To ensure uniqueness of the derived shared secret, the authorization > > server SHOULD generate a sufficiently random kid value and include > > the claims "iat" and either "exp" or "exi" in the access token. > > > > I don't think I understand the motivation for all these statements (and > > in fact that they may not be entirely correct). It is permitted to use > > the 'info' parameter to HKDF for domain separation, so even having the > > unique kid mentioned above is enough to ensure a unique derived shared > > secret (and this holds even if the kid uniqueness requirement is > > weakendt to be per-RS and not per-AS). Including "iat", "exp", and/or > > "exi" also helps to ensure uniqueness and should be recommended, but the > > interrelationships are not stated well here. Perhaps: > > > > % Use of a unique (per RS) "kid" and the use of a unique per-AS/RS key > > % derivation IKM as specified above will ensure that the derived key is > > % not shared across multiple clients. However, to additionally provide > > % variation in the derived key across different tokens used by the same > > % client, it is additionally RECOMMENDED to include the "iat" claim and > > % either the "exp" or "exi" claims in the access token. > > Okay, changed as suggested. > > >> > Up in Section 3.3 we talk about a case where the AS and RS are assumed to > >> > share a key derivation key that's used to derive symmetric keys for the RS > >> > to share with the client. The KDF input is the IKM and the 'info' (since > >> > 'salt' is empty), and the IKM is just that same "key derivation key". So > >> > the only input to HKDF that changes for different clients (and the same RS) > >> > is the 'info'. The 'info', in turn contains a string constant 'type' plus > >> > the 'kid' and (presumably fixed) output length. If I'm reading this > >> > correctly, the 'kid' is the only HKDF input that varies between clients, so > >> > if the 'kid' was reused for different clients, the AS and RS would derive > >> > the same symmetric key for those distinct client/RS pairs. Furthermore, > >> > since the AS returns the actual symmetric key to the client in the token > >> > response, that means that the symmetric key is shared by *three* parties > >> > (vs. just client and RS, ignoring in the count the AS which knows > >> > everything). I guess technically this is not the scenario forbidden by the > >> > core framework (which is to have the same symmetric key used at multiple > >> > RSes, but it still is bad hygeine and would let one client impersonate the > >> > other. > >> > > >> > In cases not using the KDF, the 'kid' is just a hint to finding the actual > >> > key, and the actual key is assumed to be constructed uniquely by the AS > >> > each time. > >> > >> Thank you, this is absolutely true. I have now changed the input for the > >> key derivation mechanism in the sense of what originally has been > >> specified in draft-gerdes-ace-dcaf-authorize, i.e., including the access > >> token as input to the KDF. This enables the authorization server to > >> include a certain amount of unifying attributes in the info parameter, > >> esp. with a randomly generated kid and the iat claim. I would have loved > >> to have a claim type for carrying a nonce in the access token… > > > > Hmm, we say that "access_token is the decrypted access_token as > > transferred from the AS to the RS", but it's supposed to be a CBOR map; > > is this intended to just be the claims set from the CWT? If so, we > > should say that. > > I do not see the difference: The access token is comprised of a CWT > claim set which is represented on the wire as a CBOR map. The Message of the CWT is a CBOR map, but the access token itself is not just the Message, and "the decrypted access_token" is perhaps a bit informal of language for what we wang. (I think I was a bit confused when I wrote the original comment, though, as for JWT the structure is a bit different and the Claims Set a much more distinct object.) > Unfortunately, this is not explained in draft-ietf-ace-oauth-params. > > To avoid confusion here, the following clarification has been added: > > NEW: > > The decrypted access token usually denotes a CWT claim set > represented as CBOR map. Thanks. > >> As there is no guidance so far on how permission sets in access tokens > >> are to be combined properly it seems to be wise at least to advise > >> against. > > > > I agree that's the right advice to give; what is less clear to me is > > whether this document needs to be the place to give that advice (vs. the > > framework doing so). But I don't have a strong stance on this at the > > moment, and am happy to move forward with the text as-is if you want. > > Okay, to avoid last-minute changes to the framework document I leave > it as it is. > > >> >> > I think RFCs 7250, 7251, and 8422 need to be normative. > >> >> > >> >> done > >> > >> Actually, I had to revert this for the informational RFC 7251 as the > >> idnits tool did not allow the downref from normative. > > > > idnits is just a tool to raise potential issues that a human can look > > at and think about; in this case, idnits is wrong: 7251 is listed at > > https://datatracker.ietf.org/doc/downref/ and is perfectly fine to use > > as a normative reference. > > Oh, sorry, I was not aware of that. This now has been reverted. Thanks for all the updates! I did have just a few nits from looking at the diff from -09 to -11; we can probably address those along with other IETF LC feedback (though fixing them earlier is not discouraged). Section 3.2 An example access token response from the authorization to the client is depicted in Figure 4. Here, the contents of the "access_token" nit: s/authorization/authorization server/ Section 3.3 I guess if we want the AS and RS to get the same key-derivation output we need to say that the encoding for 'L' is the minimum-length encoding Section 7 valid access tokens. The protection of access tokens that are stored in the authorization information endpoint depends on the keying material that is used between the authorization server and the resource server: The resource server must ensure that it processes only access tokens that are encrypted and integrity-protected by an authorization server that is authorized to provide access tokens for the resource server. We may want to put "encrypted and" in parentheses, as we don't require the use of encrypted CWTs. Section 7.1 nit: s/renogiation/renegotiation/ -Ben From nobody Tue Jun 30 03:19:49 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7F503A1175; Tue, 30 Jun 2020 03:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1gmAY8sOng3; Tue, 30 Jun 2020 03:19:44 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE0A73A1176; Tue, 30 Jun 2020 03:19:43 -0700 (PDT) Received: from wangari.tzi.org (p54bded4c.dip0.t-ipconnect.de [84.189.237.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49x0hs69W7zyXR; Tue, 30 Jun 2020 12:19:41 +0200 (CEST) From: Olaf Bergmann To: Benjamin Kaduk Cc: draft-ietf-ace-dtls-authorize.all@ietf.org, ace@ietf.org References: <20200102234020.GI35479@kduck.mit.edu> <87pnca9gyx.fsf@wangari> <20200429011210.GC27494@kduck.mit.edu> <87mu6bn6zy.fsf@wangari> <20200527234227.GD58497@kduck.mit.edu> <87r1uczgyq.fsf@wangari> <20200629224537.GX58278@kduck.mit.edu> Date: Tue, 30 Jun 2020 12:19:41 +0200 In-Reply-To: <20200629224537.GX58278@kduck.mit.edu> (Benjamin Kaduk's message of "Mon, 29 Jun 2020 15:45:37 -0700") Message-ID: <87mu4konya.fsf@wangari> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 10:19:48 -0000 Hi Ben, Thank you for the quick followup and another set of very useful comments. I have created a working copy with updates as listed inline. If you want me to, I can submit these as -12. Benjamin Kaduk writes: > Hi Olaf, > > Thanks for the updated -11! > Some minor replies below, though in general the proposals look good. > > On Thu, Jun 18, 2020 at 02:38:32PM +0200, Olaf Bergmann wrote: >> Hi Benjamin, >>=20 >> Benjamin Kaduk writes: >>=20 >> > Thanks! I think we will probably need an -11 fairly soon, though, giv= en >> > the remaining comments I have. >>=20 >> We have just submitted -11 that addresses your comments. See below for >> detailed responses. I have trimmed-down the email thread context a bit >> to improved readability and focus on the recent comments. >>=20 >> > A couple general remarks looking at the -09-to-10 diff (not all new in >> > the -10, so I guess I missed it the first time around): >> > >> > In Section 3.2.1, I suggest applying: >> > >> > OLD: >> > [...] If CBOR web tokens [RFC8392] are used as recommended in >> > [I-D.ietf-ace-oauth-authz] [...] >> > >> > NEW: >> > [...] If CBOR web tokens [RFC8392] are used (as recommended in >> > [I-D.ietf-ace-oauth-authz]) [...] >> > >> > Making this a parenthetical statement makes it clear that the >> > conditional for "keys MUST be encoded" is "CWT are used" and separate >> > from the recommendation to do so. >>=20 >> Done >>=20 >> > Also in 3.2.1, we now have these two statements in fairly close >> > proximity: >> > >> > [RFC8747]. The resource server MUST use its own raw public key in >> > the DTLS handshake with the client. If the resource server has >> > several raw public keys, it must already know which key it is >> > supposed to use with this client. How this is achieved is not part >> > of this profile. >> > >> > The resource server MUST use the keying material that the >> > authorizations server has specified in the "cnf" parameter in the >> > access token for the DTLS handshake with the client. Thus, the >> > >> > which seems a bit redundant and potentially in conflict. Can we >> > consolidate this requirement a bit? >>=20 >> Yes, the wording is a bit confusing. The following proposal states >> the intention more clearly, I think: >>=20 >> NEW:=20 >>=20 >> The raw public key used in the DTLS handshake with the client MUST >> belong to the resource server. If the resource server has several > > (Someone might complain that this first sentence is tautological, but I > think we should leave it for now.) Okay. >> OLD: >> If a resource server receives a ClientKeyExchange message that >> contains a `psk_identity` with a length greater than zero, it MUST >> process the contents of the `psk_identity` field as access token >> that is stored with the authorization information endpoint, before >> continuing the DTLS handshake. If the contents of the >> `psk_identity` do not yield a valid access token for the requesting >> client, the resource server aborts the DTLS handshake with an >> `illegal_parameter` alert. >>=20 >> NEW: >>=20 >> If a resource server receives a ClientKeyExchange message that >> contains a `psk_identity` with a length greater than zero, it MUST >> parse the contents of the `psk_identity` field as CBOR data >> structure and process the contents as following: >>=20 >> * If the data contains a `cnf` field with a `COSE_Key` structure >> with a `kid`, the resource server continues the DTLS handshake >> with the stored key associated with this kid. > > Maybe "corresponding" or "associated" stored key, since there is not > necessarily a unique kid/key relationship? Hm, I was hoping that this is sufficiently expressed by "the stored key associated with this kid". My assumption is that we have a mapping from kids to keys where a kid is mapped to at most one key. (Usually, this would be a bijection but there might be cases where a kid is known and the key is not yet known or has expired. How about this: OLD: continues the DTLS handshake with the stored key associated with this kid. NEW: continues the DTLS handshake with the associated key that corresponds to this kid. >> * If the data comprises additional CWT information, this >> information must be stored as access token for this DTLS > > nit: "as an" Fixed, thanks! >> >> > I think we need to give some guidance about what the semantics are = if/when >> >> > it happens. My inclination would be to say that DTLS resumption ca= n be >> >> > used to amortize the cost of a handshake, but DTLS 1.2 resumption d= oes not >> >> > provide forward secrecy and also does not provide an opportunity fo= r the >> >> > client to prove possession of the PoP key, so servers will want to >> >> > periodically force a full handshake according to their authenticati= on >> >> > requirements. I'd also be inclined to forbid renegotiation entirel= y. >> >>=20 >> >> True, especially because RFC 7925 requires resumption to be >> >> implemented. The security considerations now advise against session >> >> resumptions and renegotiation as you have suggested. The Security >> >> Considerations section now has been structured in sub-sections for >> >> clarity. >> > >> > The discussion in the -10 is reasonable (and the stated motivation of >> > having a fresh proof of possession is fairly compelling), though to be >> > clear, my initial "inclination" above was just to forbid renegotiation >> > but allow resumption. >>=20 >> Sorry, I had misinterpreted that. Actually, I am not entirely >> convinced by the "fresh PoP" argument anymore. When the access token >> made its way to the server through the client, there is no significant >> difference between keeping the DTLS session open and session >> resumption. Additional security against breaching the encryption of >> the (encrypted part of the) access token would be provided only by token >> introspection. But in that case, session resumption again would not >> harm security as we do not need to store precious information in the >> session ticket. >>=20 >> Are you in favor of allowing session resumption? > > I think it would be safe to allow resumption, but I personally am > indifferent about whether or not we should do so. Okay. Currently, the section has a discussion that concludes in a NOT RECOMMENDED. If someone argues for generally allowing session resumption we would not have to do much more than just removing that conclusion. >> >> > Up in Section 3.3 we talk about a case where the AS and RS are assu= med to >> >> > share a key derivation key that's used to derive symmetric keys for= the RS >> >> > to share with the client. The KDF input is the IKM and the 'info' = (since >> >> > 'salt' is empty), and the IKM is just that same "key derivation key= ". So >> >> > the only input to HKDF that changes for different clients (and the = same RS) >> >> > is the 'info'. The 'info', in turn contains a string constant 'typ= e' plus >> >> > the 'kid' and (presumably fixed) output length. If I'm reading this >> >> > correctly, the 'kid' is the only HKDF input that varies between cli= ents, so >> >> > if the 'kid' was reused for different clients, the AS and RS would = derive >> >> > the same symmetric key for those distinct client/RS pairs. Further= more, >> >> > since the AS returns the actual symmetric key to the client in the = token >> >> > response, that means that the symmetric key is shared by *three* pa= rties >> >> > (vs. just client and RS, ignoring in the count the AS which knows >> >> > everything). I guess technically this is not the scenario forbidde= n by the >> >> > core framework (which is to have the same symmetric key used at mul= tiple >> >> > RSes, but it still is bad hygeine and would let one client imperson= ate the >> >> > other. >> >> > >> >> > In cases not using the KDF, the 'kid' is just a hint to finding the= actual >> >> > key, and the actual key is assumed to be constructed uniquely by th= e AS >> >> > each time. >> >>=20 >> >> Thank you, this is absolutely true. I have now changed the input for = the >> >> key derivation mechanism in the sense of what originally has been >> >> specified in draft-gerdes-ace-dcaf-authorize, i.e., including the acc= ess >> >> token as input to the KDF. This enables the authorization server to >> >> include a certain amount of unifying attributes in the info parameter, >> >> esp. with a randomly generated kid and the iat claim. I would have lo= ved >> >> to have a claim type for carrying a nonce in the access token=E2=80=A6 >> > >> > Hmm, we say that "access_token is the decrypted access_token as >> > transferred from the AS to the RS", but it's supposed to be a CBOR map; >> > is this intended to just be the claims set from the CWT? If so, we >> > should say that. >>=20 >> I do not see the difference: The access token is comprised of a CWT >> claim set which is represented on the wire as a CBOR map.=20 > > The Message of the CWT is a CBOR map, but the access token itself is not > just the Message, and "the decrypted access_token" is perhaps a bit > informal of language for what we wang. (I think I was a bit confused when > I wrote the original comment, though, as for JWT the structure is a bit > different and the Claims Set a much more distinct object.) Maybe this is a bit more specific without adding a more detailed explanation of how this is supposed to work below the bullet list: OLD: access_token is the decrypted access_token as transferred from the authorization server to the resource server. NEW: access_token is the decrypted content of the access_token field as transferred from the authorization server to the resource server. >> Unfortunately, this is not explained in draft-ietf-ace-oauth-params. >>=20 >> To avoid confusion here, the following clarification has been added: >>=20 >> NEW: >>=20 >> The decrypted access token usually denotes a CWT claim set >> represented as CBOR map. > > Thanks. > >> >> As there is no guidance so far on how permission sets in access tokens >> >> are to be combined properly it seems to be wise at least to advise >> >> against. >> > >> > I agree that's the right advice to give; what is less clear to me is >> > whether this document needs to be the place to give that advice (vs. t= he >> > framework doing so). But I don't have a strong stance on this at the >> > moment, and am happy to move forward with the text as-is if you want. >>=20 >> Okay, to avoid last-minute changes to the framework document I leave >> it as it is. >>=20 >> >> >> > I think RFCs 7250, 7251, and 8422 need to be normative. >> >> >>=20 >> >> >> done >> >>=20 >> >> Actually, I had to revert this for the informational RFC 7251 as the >> >> idnits tool did not allow the downref from normative. >> > >> > idnits is just a tool to raise potential issues that a human can look >> > at and think about; in this case, idnits is wrong: 7251 is listed at >> > https://datatracker.ietf.org/doc/downref/ and is perfectly fine to use >> > as a normative reference. >>=20 >> Oh, sorry, I was not aware of that. This now has been reverted. > > Thanks for all the updates! > > I did have just a few nits from looking at the diff from -09 to -11; we c= an > probably address those along with other IETF LC feedback (though fixing > them earlier is not discouraged). That sounds as if shipping -12 now would be okay :-) > Section 3.2 > > An example access token response from the authorization to the client > is depicted in Figure 4. Here, the contents of the "access_token" > > nit: s/authorization/authorization server/ Fixed, thanks! > Section 3.3 > > I guess if we want the AS and RS to get the same key-derivation output we > need to say that the encoding for 'L' is the minimum-length encoding Good point. As this is also true for the length encoding of the text string in the type field, I have added the following clarification: NEW: All CBOR data types are encoded in canonical CBOR as defined in Section 3.9 of {{RFC7049}}. This implies in particular that the `type` and `L` components use the minimum length encoding. (This unfortunately imposes additional restrictions on the access_token which would not be required for key derivation. But IIRC there has been some implicit agreement that the access_token should be encoded in canonical CBOR as well. > Section 7 > > valid access tokens. The protection of access tokens that are stored > in the authorization information endpoint depends on the keying > material that is used between the authorization server and the > resource server: The resource server must ensure that it processes > only access tokens that are encrypted and integrity-protected by an > authorization server that is authorized to provide access tokens for > the resource server. > > We may want to put "encrypted and" in parentheses, as we don't require the > use of encrypted CWTs. Done. However, the only situation where encryption is not a MUST is in case of key derivation. > Section 7.1 > > nit: s/renogiation/renegotiation/ Thanks. I had to read this word several times to spot the difference :-) Gr=C3=BC=C3=9Fe Olaf From nobody Tue Jun 30 07:21:40 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8585E3A0965; Tue, 30 Jun 2020 07:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnxUYIJ9bocG; Tue, 30 Jun 2020 07:21:36 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C09B3A0962; Tue, 30 Jun 2020 07:21:36 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49x63y4PXzzyXP; Tue, 30 Jun 2020 16:21:34 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <87mu4konya.fsf@wangari> Date: Tue, 30 Jun 2020 16:21:34 +0200 Cc: Benjamin Kaduk , draft-ietf-ace-dtls-authorize.all@ietf.org, ace@ietf.org X-Mao-Original-Outgoing-Id: 615219694.0701981-1c3b89af0560d8dcd7db6e9a4960b3f0 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200102234020.GI35479@kduck.mit.edu> <87pnca9gyx.fsf@wangari> <20200429011210.GC27494@kduck.mit.edu> <87mu6bn6zy.fsf@wangari> <20200527234227.GD58497@kduck.mit.edu> <87r1uczgyq.fsf@wangari> <20200629224537.GX58278@kduck.mit.edu> <87mu4konya.fsf@wangari> To: Olaf Bergmann X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 14:21:39 -0000 On 2020-06-30, at 12:19, Olaf Bergmann wrote: >=20 > NEW: >=20 > All CBOR data types are encoded in canonical CBOR as defined in > Section 3.9 of {{RFC7049}}. This implies in particular that the > `type` and `L` components use the minimum length encoding Note that 7049bis, which has been submitted to IESG already, all but = deprecates this and replaces this with =E2=80=9Cdeterministic = encoding=E2=80=9D. There is only one actual technical change, which is = about map ordering. Also, please check whether =E2=80=9Cpreferred = encoding=E2=80=9D would actually be enough. I would generally prefer to avoid the need for deterministic/canonical = encoding =E2=80=94 is there really a need to re-encode the token? Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 30 07:43:31 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 700DA3A0A20; Tue, 30 Jun 2020 07:43:29 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14gPiYZmvQNH; Tue, 30 Jun 2020 07:43:28 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92F843A0A0E; Tue, 30 Jun 2020 07:43:27 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Jun 2020 07:43:21 -0700 From: Jim Schaad To: CC: Date: Tue, 30 Jun 2020 07:43:20 -0700 Message-ID: <039a01d64eec$ce5abdb0$6b103910$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AdZO7D+D5UDgLvz2RcGdoJdfIgCinQ== X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Extended REST model comment X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 14:43:30 -0000 In trying to formalize a policy for the RD testing, I ended up with something that I think needs to be noted in this section. There is a difference between the following statements: Access is granted to resources created by the client. Access is granted to resources that could have been created by the client. The first is what the text seems to cover. This make sense in for the coffeepot where only the person who created the order should be able to cancel it. (Well maybe an administrator might need to as well.) However it does not cover the case where an installer created a number of entries in the RD. A QA person then comes through to make sure the installation was done correctly. When he finds a problem, the first statement requires that the original installer come out to fix it while the second statement allows the QA person to make the fix. Jim From nobody Tue Jun 30 08:35:33 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0243A0AE8; Tue, 30 Jun 2020 08:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpmdCtuDNLrx; Tue, 30 Jun 2020 08:35:29 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5F373A0ADB; Tue, 30 Jun 2020 08:35:28 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49x7j71qYxz107y; Tue, 30 Jun 2020 17:35:23 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <039a01d64eec$ce5abdb0$6b103910$@augustcellars.com> Date: Tue, 30 Jun 2020 17:35:22 +0200 Cc: draft-bormann-core-ace-aif@ietf.org, ace@ietf.org X-Mao-Original-Outgoing-Id: 615224122.738447-b096d2578528d87fa36e5424c040539b Content-Transfer-Encoding: quoted-printable Message-Id: <0E078421-C692-475E-880B-30295F520D88@tzi.org> References: <039a01d64eec$ce5abdb0$6b103910$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Ace] Extended REST model comment X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 15:35:31 -0000 On 2020-06-30, at 16:43, Jim Schaad wrote: >=20 > In trying to formalize a policy for the RD testing, I ended up with > something that I think needs to be noted in this section. There is a > difference between the following statements: >=20 > Access is granted to resources created by the client. > Access is granted to resources that could have been created by the = client. >=20 > The first is what the text seems to cover. This make sense in for the > coffeepot where only the person who created the order should be able = to > cancel it. (Well maybe an administrator might need to as well.) = However it > does not cover the case where an installer created a number of entries = in > the RD. A QA person then comes through to make sure the installation = was > done correctly. When he finds a problem, the first statement requires = that > the original installer come out to fix it while the second statement = allows > the QA person to make the fix. Hi Jim, interesting. I was thinking about #1 =E2=80=94 I can make a coffee, I = can cancel making it, you can make a coffee, but you can=E2=80=99t = cancel my coffee. Or delete my RD entry, etc. So making the resource confers ownership = (really: a separate set of permission bits) that is bound to the = subject. In my view of how permission systems usually work, the other alternative = requires creating a group. The inherited permission would then be = attached to the group. Since AIF is about capability lists, not about subject identities, I = think we are covered =E2=80=94 just have the capability list on the = group. NFSv4 permissions probably also have a way to handle this kind of = inheritance, but I=E2=80=99ll not have time to look that up today... Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 30 09:25:23 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC443A0D2C; Tue, 30 Jun 2020 09:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdCPPmgUQZWk; Tue, 30 Jun 2020 09:25:11 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 D35643A0D32; Tue, 30 Jun 2020 09:24:39 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05UGOYU1002966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jun 2020 12:24:37 -0400 Date: Tue, 30 Jun 2020 09:24:34 -0700 From: Benjamin Kaduk To: Carsten Bormann Cc: Olaf Bergmann , draft-ietf-ace-dtls-authorize.all@ietf.org, ace@ietf.org Message-ID: <20200630162434.GM58278@kduck.mit.edu> References: <20200102234020.GI35479@kduck.mit.edu> <87pnca9gyx.fsf@wangari> <20200429011210.GC27494@kduck.mit.edu> <87mu6bn6zy.fsf@wangari> <20200527234227.GD58497@kduck.mit.edu> <87r1uczgyq.fsf@wangari> <20200629224537.GX58278@kduck.mit.edu> <87mu4konya.fsf@wangari> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 16:25:22 -0000 On Tue, Jun 30, 2020 at 04:21:34PM +0200, Carsten Bormann wrote: > On 2020-06-30, at 12:19, Olaf Bergmann wrote: > > > > NEW: > > > > All CBOR data types are encoded in canonical CBOR as defined in > > Section 3.9 of {{RFC7049}}. This implies in particular that the > > `type` and `L` components use the minimum length encoding > > Note that 7049bis, which has been submitted to IESG already, all but deprecates this and replaces this with “deterministic encoding”. There is only one actual technical change, which is about map ordering. Also, please check whether “preferred encoding” would actually be enough. > > I would generally prefer to avoid the need for deterministic/canonical encoding — is there really a need to re-encode the token? My original comment was in the context of a novel data structure being used as HKDF input, which has 'type' and 'L' fields unrelated to any preexisting token. Using the 'access_token' map as transmitted would be helpful, but is not sufficient. -Ben From nobody Tue Jun 30 11:17:07 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1113A08C6; Tue, 30 Jun 2020 11:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Q5rcx6YnrQB; Tue, 30 Jun 2020 11:17:02 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422C43A08AA; Tue, 30 Jun 2020 11:17:01 -0700 (PDT) Received: from wangari.tzi.org (p54bded4c.dip0.t-ipconnect.de [84.189.237.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49xCHc0mBWz108G; Tue, 30 Jun 2020 20:17:00 +0200 (CEST) From: Olaf Bergmann To: Carsten Bormann Cc: ace@ietf.org, Benjamin Kaduk , draft-ietf-ace-dtls-authorize.all@ietf.org References: <20200102234020.GI35479@kduck.mit.edu> <87pnca9gyx.fsf@wangari> <20200429011210.GC27494@kduck.mit.edu> <87mu6bn6zy.fsf@wangari> <20200527234227.GD58497@kduck.mit.edu> <87r1uczgyq.fsf@wangari> <20200629224537.GX58278@kduck.mit.edu> <87mu4konya.fsf@wangari> Date: Tue, 30 Jun 2020 20:16:59 +0200 In-Reply-To: (Carsten Bormann's message of "Tue, 30 Jun 2020 16:21:34 +0200") Message-ID: <87mu4kl8pw.fsf@wangari> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 18:17:05 -0000 Carsten Bormann writes: > On 2020-06-30, at 12:19, Olaf Bergmann wrote: >>=20 >> NEW: >>=20 >> All CBOR data types are encoded in canonical CBOR as defined in >> Section 3.9 of {{RFC7049}}. This implies in particular that the >> `type` and `L` components use the minimum length encoding > > Note that 7049bis, which has been submitted to IESG already, all but > deprecates this and replaces this with =E2=80=9Cdeterministic encoding=E2= =80=9D. > There is only one actual technical change, which is about map > ordering. Also, please check whether =E2=80=9Cpreferred encoding=E2=80= =9D would > actually be enough. > > I would generally prefer to avoid the need for deterministic/canonical > encoding =E2=80=94 is there really a need to re-encode the token? There is no need to re-encode the token, and I do not expect that this would happen if the authorization server has used a finite length. I am more than happy to get rid of the ordering constraints on CBOR maps but I am not sure about referencing the -bis. Can we do that at this stage? Note: Up to now, we could even do without a normative reference to RFC 7049. Gr=C3=BC=C3=9Fe Olaf From nobody Tue Jun 30 11:36:03 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D6C3A0C99; Tue, 30 Jun 2020 11:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZ-8810HxLHU; Tue, 30 Jun 2020 11:35:59 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1283A0C95; Tue, 30 Jun 2020 11:35:58 -0700 (PDT) Received: from [172.16.42.112] (p5089ae91.dip0.t-ipconnect.de [80.137.174.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49xCjT3RxszyT7; Tue, 30 Jun 2020 20:35:57 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Carsten Bormann In-Reply-To: <87mu4kl8pw.fsf@wangari> Date: Tue, 30 Jun 2020 20:35:56 +0200 Cc: Ace Wg , Benjamin Kaduk , draft-ietf-ace-dtls-authorize.all@ietf.org X-Mao-Original-Outgoing-Id: 615234956.9434561-8edbf34e147e4b4574e462c0e444d6c7 Content-Transfer-Encoding: quoted-printable Message-Id: <8E863F96-241D-477F-97C1-BCBD6742452D@tzi.org> References: <20200102234020.GI35479@kduck.mit.edu> <87pnca9gyx.fsf@wangari> <20200429011210.GC27494@kduck.mit.edu> <87mu6bn6zy.fsf@wangari> <20200527234227.GD58497@kduck.mit.edu> <87r1uczgyq.fsf@wangari> <20200629224537.GX58278@kduck.mit.edu> <87mu4konya.fsf@wangari> <87mu4kl8pw.fsf@wangari> To: Olaf Bergmann X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 18:36:02 -0000 >>=20 >> I would generally prefer to avoid the need for = deterministic/canonical >> encoding =E2=80=94 is there really a need to re-encode the token? >=20 > There is no need to re-encode the token, and I do not expect that this > would happen if the authorization server has used a finite length. So would we be better off with: info =3D [ type : tstr, L : uint, access_token: bytes ] Where access_token is the token in original encoding? No need to = re-encode the token then. > I am more than happy to get rid of the ordering constraints on CBOR = maps > but I am not sure about referencing the -bis. Can we do that at this > stage? Both documents are in IESG processing, specifically: dtls-authorize: AD Evaluation::External Party 7049bis: Publication Requested Potential emergency escape: reference Section 10 of rfc8152bis-struct = (which is even further along at IESG Evaluation::Revised I-D Needed). > Note: Up to now, we could even do without a normative reference to RFC = 7049. Yes, but that=E2=80=99s cheating (indirect normative reference through = 8610). Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 30 12:11:40 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A513A00C0; Tue, 30 Jun 2020 12:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br_HsKaN1QQc; Tue, 30 Jun 2020 12:11:36 -0700 (PDT) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B945C3A00B2; Tue, 30 Jun 2020 12:11:35 -0700 (PDT) Received: from wangari.tzi.org (p54bded4c.dip0.t-ipconnect.de [84.189.237.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 49xDVZ03FkzyXw; Tue, 30 Jun 2020 21:11:33 +0200 (CEST) From: Olaf Bergmann To: Carsten Bormann Cc: Ace Wg , Benjamin Kaduk , draft-ietf-ace-dtls-authorize.all@ietf.org Date: Tue, 30 Jun 2020 21:11:07 +0200 References: <20200102234020.GI35479@kduck.mit.edu> <87pnca9gyx.fsf@wangari> <20200429011210.GC27494@kduck.mit.edu> <87mu6bn6zy.fsf@wangari> <20200527234227.GD58497@kduck.mit.edu> <87r1uczgyq.fsf@wangari> <20200629224537.GX58278@kduck.mit.edu> <87mu4konya.fsf@wangari> <87mu4kl8pw.fsf@wangari> <8E863F96-241D-477F-97C1-BCBD6742452D@tzi.org> Message-ID: <875zb8l66y.fsf@wangari> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 19:11:39 -0000 Carsten Bormann writes: >>>=20 >>> I would generally prefer to avoid the need for deterministic/canonical >>> encoding =E2=80=94 is there really a need to re-encode the token? >>=20 >> There is no need to re-encode the token, and I do not expect that this >> would happen if the authorization server has used a finite length. > > So would we be better off with: > > > info =3D [ > type : tstr, > L : uint, > access_token: bytes > ] > > Where access_token is the token in original encoding? No need to re-enco= de the token then. That is what I wanted to hear. >> I am more than happy to get rid of the ordering constraints on CBOR maps >> but I am not sure about referencing the -bis. Can we do that at this >> stage? > > Both documents are in IESG processing, specifically: > dtls-authorize: AD Evaluation::External Party > 7049bis: Publication Requested Looking at the deterministic encoding (Section 4.2 of draft-ietf-cbor-7049bis-14), I am happy referencing that instead of canonical CBOR. Any objections? Gr=C3=BC=C3=9Fe Olaf From nobody Tue Jun 30 12:23:57 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ECC73A02C1; Tue, 30 Jun 2020 12:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhOoNyLHi-tM; Tue, 30 Jun 2020 12:23:54 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7133A0112; Tue, 30 Jun 2020 12:23:53 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Jun 2020 12:23:46 -0700 From: Jim Schaad To: 'Carsten Bormann' CC: , References: <039a01d64eec$ce5abdb0$6b103910$@augustcellars.com> <0E078421-C692-475E-880B-30295F520D88@tzi.org> In-Reply-To: <0E078421-C692-475E-880B-30295F520D88@tzi.org> Date: Tue, 30 Jun 2020 12:23:46 -0700 Message-ID: <03ac01d64f13$fb297760$f17c6620$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQJc5zWSw/4mzXPqMjE0jHzkpw47ggHd4fTPp9VqPfA= X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Extended REST model comment X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 19:23:55 -0000 > -----Original Message----- > From: Carsten Bormann > Sent: Tuesday, June 30, 2020 8:35 AM > To: Jim Schaad > Cc: draft-bormann-core-ace-aif@ietf.org; ace@ietf.org > Subject: Re: [Ace] Extended REST model comment >=20 > On 2020-06-30, at 16:43, Jim Schaad wrote: > > > > In trying to formalize a policy for the RD testing, I ended up with > > something that I think needs to be noted in this section. There is = a > > difference between the following statements: > > > > Access is granted to resources created by the client. > > Access is granted to resources that could have been created by the = client. > > > > The first is what the text seems to cover. This make sense in for = the > > coffeepot where only the person who created the order should be able > > to cancel it. (Well maybe an administrator might need to as well.) > > However it does not cover the case where an installer created a = number > > of entries in the RD. A QA person then comes through to make sure = the > > installation was done correctly. When he finds a problem, the first > > statement requires that the original installer come out to fix it > > while the second statement allows the QA person to make the fix. >=20 > Hi Jim, >=20 > interesting. I was thinking about #1 =E2=80=94 I can make a coffee, I = can cancel > making it, you can make a coffee, but you can=E2=80=99t cancel my = coffee. > Or delete my RD entry, etc. So making the resource confers ownership = (really: > a separate set of permission bits) that is bound to the subject. >=20 > In my view of how permission systems usually work, the other = alternative > requires creating a group. The inherited permission would then be = attached to > the group. > Since AIF is about capability lists, not about subject identities, I = think we are > covered =E2=80=94 just have the capability list on the group. [JLS] I would agree that there is no need to make any changes in the AIF = structure. I would just like to see some text discussing that policy = can enforce this in either way. Jim >=20 > NFSv4 permissions probably also have a way to handle this kind of = inheritance, > but I=E2=80=99ll not have time to look that up today... >=20 > Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jun 30 12:27:23 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CE53A043D; Tue, 30 Jun 2020 12:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v24DrQ11MQi2; Tue, 30 Jun 2020 12:27:16 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7D2E3A040F; Tue, 30 Jun 2020 12:27:10 -0700 (PDT) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 30 Jun 2020 12:26:46 -0700 From: Jim Schaad To: 'Benjamin Kaduk' , 'Carsten Bormann' CC: 'Olaf Bergmann' , , References: <20200102234020.GI35479@kduck.mit.edu> <87pnca9gyx.fsf@wangari> <20200429011210.GC27494@kduck.mit.edu> <87mu6bn6zy.fsf@wangari> <20200527234227.GD58497@kduck.mit.edu> <87r1uczgyq.fsf@wangari> <20200629224537.GX58278@kduck.mit.edu> <87mu4konya.fsf@wangari> <20200630162434.GM58278@kduck.mit.edu> In-Reply-To: <20200630162434.GM58278@kduck.mit.edu> Date: Tue, 30 Jun 2020 12:26:45 -0700 Message-ID: <03ad01d64f14$66b0a080$3411e180$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us thread-index: AQHGCRF5nmwiv9SPGwzqJ8qbQfLFcAHgMQg8AaMeee8CTdx1OgCvp4izAnkzCqgBoEnbuAKNZ0TDAQGsCtsB3iEDHqiRtLaw X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 19:27:21 -0000 > -----Original Message----- > From: Benjamin Kaduk > Sent: Tuesday, June 30, 2020 9:25 AM > To: Carsten Bormann > Cc: Olaf Bergmann ; draft-ietf-ace-dtls- > authorize.all@ietf.org; ace@ietf.org > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 >=20 > On Tue, Jun 30, 2020 at 04:21:34PM +0200, Carsten Bormann wrote: > > On 2020-06-30, at 12:19, Olaf Bergmann wrote: > > > > > > NEW: > > > > > > All CBOR data types are encoded in canonical CBOR as defined in > > > Section 3.9 of {{RFC7049}}. This implies in particular that the > > > `type` and `L` components use the minimum length encoding > > > > Note that 7049bis, which has been submitted to IESG already, all but > deprecates this and replaces this with =E2=80=9Cdeterministic = encoding=E2=80=9D. There is only > one actual technical change, which is about map ordering. Also, = please check > whether =E2=80=9Cpreferred encoding=E2=80=9D would actually be enough. > > > > I would generally prefer to avoid the need for = deterministic/canonical > encoding =E2=80=94 is there really a need to re-encode the token? >=20 > My original comment was in the context of a novel data structure being = used as > HKDF input, which has 'type' and 'L' fields unrelated to any = preexisting token. > Using the 'access_token' map as transmitted would be helpful, but is = not > sufficient. If you are not doing a re-encoding of the token, then I believe that = preferred serialization and deterministic serialization are going to = generate the same answer. With the map being used then this is not = true, and it is also true that the change in map ordering will hit this. = This is a piece of the document that I have never implemented because I = just don't believe that this option is a reasonable thing to require = being done so I missed the fact that the original encoded token is not = being used. =20 There is a possible DOS attack by a MITM changing the encoding on the = token since it is not protected when posted to the RS. If this is going = to be changed, I would say use the binary string encoding from the bstr = of the inner most COSE wrapping layer as the input to minimize this. Jim >=20 > -Ben From nobody Tue Jun 30 18:19:35 2020 Return-Path: X-Original-To: ace@ietfa.amsl.com Delivered-To: ace@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059993A0870; Tue, 30 Jun 2020 18:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 055wi-VBLRaN; Tue, 30 Jun 2020 18:19:29 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 6A7583A086D; Tue, 30 Jun 2020 18:19:29 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0611JOjN006445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 30 Jun 2020 21:19:26 -0400 Date: Tue, 30 Jun 2020 18:19:23 -0700 From: Benjamin Kaduk To: Olaf Bergmann Cc: draft-ietf-ace-dtls-authorize.all@ietf.org, ace@ietf.org Message-ID: <20200701011923.GA58278@kduck.mit.edu> References: <20200102234020.GI35479@kduck.mit.edu> <87pnca9gyx.fsf@wangari> <20200429011210.GC27494@kduck.mit.edu> <87mu6bn6zy.fsf@wangari> <20200527234227.GD58497@kduck.mit.edu> <87r1uczgyq.fsf@wangari> <20200629224537.GX58278@kduck.mit.edu> <87mu4konya.fsf@wangari> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87mu4konya.fsf@wangari> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 X-BeenThere: ace@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2020 01:19:34 -0000 Hi Olaf, On Tue, Jun 30, 2020 at 12:19:41PM +0200, Olaf Bergmann wrote: > Hi Ben, > > Thank you for the quick followup and another set of very useful > comments. I have created a working copy with updates as listed > inline. If you want me to, I can submit these as -12. If it's easy for you, please go ahead. Inline. > Benjamin Kaduk writes: > > > Hi Olaf, > > > > Thanks for the updated -11! > > Some minor replies below, though in general the proposals look good. > > > > On Thu, Jun 18, 2020 at 02:38:32PM +0200, Olaf Bergmann wrote: > >> Hi Benjamin, > >> > >> Benjamin Kaduk writes: > >> > >> > Thanks! I think we will probably need an -11 fairly soon, though, given > >> > the remaining comments I have. > >> > >> We have just submitted -11 that addresses your comments. See below for > >> detailed responses. I have trimmed-down the email thread context a bit > >> to improved readability and focus on the recent comments. > >> > >> > A couple general remarks looking at the -09-to-10 diff (not all new in > >> > the -10, so I guess I missed it the first time around): > >> > > >> > In Section 3.2.1, I suggest applying: > >> > > >> > OLD: > >> > [...] If CBOR web tokens [RFC8392] are used as recommended in > >> > [I-D.ietf-ace-oauth-authz] [...] > >> > > >> > NEW: > >> > [...] If CBOR web tokens [RFC8392] are used (as recommended in > >> > [I-D.ietf-ace-oauth-authz]) [...] > >> > > >> > Making this a parenthetical statement makes it clear that the > >> > conditional for "keys MUST be encoded" is "CWT are used" and separate > >> > from the recommendation to do so. > >> > >> Done > >> > >> > Also in 3.2.1, we now have these two statements in fairly close > >> > proximity: > >> > > >> > [RFC8747]. The resource server MUST use its own raw public key in > >> > the DTLS handshake with the client. If the resource server has > >> > several raw public keys, it must already know which key it is > >> > supposed to use with this client. How this is achieved is not part > >> > of this profile. > >> > > >> > The resource server MUST use the keying material that the > >> > authorizations server has specified in the "cnf" parameter in the > >> > access token for the DTLS handshake with the client. Thus, the > >> > > >> > which seems a bit redundant and potentially in conflict. Can we > >> > consolidate this requirement a bit? > >> > >> Yes, the wording is a bit confusing. The following proposal states > >> the intention more clearly, I think: > >> > >> NEW: > >> > >> The raw public key used in the DTLS handshake with the client MUST > >> belong to the resource server. If the resource server has several > > > > (Someone might complain that this first sentence is tautological, but I > > think we should leave it for now.) > > Okay. > > >> OLD: > >> If a resource server receives a ClientKeyExchange message that > >> contains a `psk_identity` with a length greater than zero, it MUST > >> process the contents of the `psk_identity` field as access token > >> that is stored with the authorization information endpoint, before > >> continuing the DTLS handshake. If the contents of the > >> `psk_identity` do not yield a valid access token for the requesting > >> client, the resource server aborts the DTLS handshake with an > >> `illegal_parameter` alert. > >> > >> NEW: > >> > >> If a resource server receives a ClientKeyExchange message that > >> contains a `psk_identity` with a length greater than zero, it MUST > >> parse the contents of the `psk_identity` field as CBOR data > >> structure and process the contents as following: > >> > >> * If the data contains a `cnf` field with a `COSE_Key` structure > >> with a `kid`, the resource server continues the DTLS handshake > >> with the stored key associated with this kid. > > > > Maybe "corresponding" or "associated" stored key, since there is not > > necessarily a unique kid/key relationship? Rereading, my suggestion of "associated" doesn't make much sense, sorry. > Hm, I was hoping that this is sufficiently expressed by "the stored > key associated with this kid". My assumption is that we have a mapping > from kids to keys where a kid is mapped to at most one key. (Usually, > this would be a bijection but there might be cases where a kid is known > and the key is not yet known or has expired. > > How about this: > > OLD: > > continues the DTLS handshake with the stored key associated with > this kid. > > NEW: > > continues the DTLS handshake with the associated key that corresponds > to this kid. I think this is better, thanks. > >> * If the data comprises additional CWT information, this > >> information must be stored as access token for this DTLS > > > > nit: "as an" > > Fixed, thanks! > > >> >> > I think we need to give some guidance about what the semantics are if/when > >> >> > it happens. My inclination would be to say that DTLS resumption can be > >> >> > used to amortize the cost of a handshake, but DTLS 1.2 resumption does not > >> >> > provide forward secrecy and also does not provide an opportunity for the > >> >> > client to prove possession of the PoP key, so servers will want to > >> >> > periodically force a full handshake according to their authentication > >> >> > requirements. I'd also be inclined to forbid renegotiation entirely. > >> >> > >> >> True, especially because RFC 7925 requires resumption to be > >> >> implemented. The security considerations now advise against session > >> >> resumptions and renegotiation as you have suggested. The Security > >> >> Considerations section now has been structured in sub-sections for > >> >> clarity. > >> > > >> > The discussion in the -10 is reasonable (and the stated motivation of > >> > having a fresh proof of possession is fairly compelling), though to be > >> > clear, my initial "inclination" above was just to forbid renegotiation > >> > but allow resumption. > >> > >> Sorry, I had misinterpreted that. Actually, I am not entirely > >> convinced by the "fresh PoP" argument anymore. When the access token > >> made its way to the server through the client, there is no significant > >> difference between keeping the DTLS session open and session > >> resumption. Additional security against breaching the encryption of > >> the (encrypted part of the) access token would be provided only by token > >> introspection. But in that case, session resumption again would not > >> harm security as we do not need to store precious information in the > >> session ticket. > >> > >> Are you in favor of allowing session resumption? > > > > I think it would be safe to allow resumption, but I personally am > > indifferent about whether or not we should do so. > > Okay. Currently, the section has a discussion that concludes in a NOT > RECOMMENDED. If someone argues for generally allowing session resumption > we would not have to do much more than just removing that conclusion. Okay. > >> >> > Up in Section 3.3 we talk about a case where the AS and RS are assumed to > >> >> > share a key derivation key that's used to derive symmetric keys for the RS > >> >> > to share with the client. The KDF input is the IKM and the 'info' (since > >> >> > 'salt' is empty), and the IKM is just that same "key derivation key". So > >> >> > the only input to HKDF that changes for different clients (and the same RS) > >> >> > is the 'info'. The 'info', in turn contains a string constant 'type' plus > >> >> > the 'kid' and (presumably fixed) output length. If I'm reading this > >> >> > correctly, the 'kid' is the only HKDF input that varies between clients, so > >> >> > if the 'kid' was reused for different clients, the AS and RS would derive > >> >> > the same symmetric key for those distinct client/RS pairs. Furthermore, > >> >> > since the AS returns the actual symmetric key to the client in the token > >> >> > response, that means that the symmetric key is shared by *three* parties > >> >> > (vs. just client and RS, ignoring in the count the AS which knows > >> >> > everything). I guess technically this is not the scenario forbidden by the > >> >> > core framework (which is to have the same symmetric key used at multiple > >> >> > RSes, but it still is bad hygeine and would let one client impersonate the > >> >> > other. > >> >> > > >> >> > In cases not using the KDF, the 'kid' is just a hint to finding the actual > >> >> > key, and the actual key is assumed to be constructed uniquely by the AS > >> >> > each time. > >> >> > >> >> Thank you, this is absolutely true. I have now changed the input for the > >> >> key derivation mechanism in the sense of what originally has been > >> >> specified in draft-gerdes-ace-dcaf-authorize, i.e., including the access > >> >> token as input to the KDF. This enables the authorization server to > >> >> include a certain amount of unifying attributes in the info parameter, > >> >> esp. with a randomly generated kid and the iat claim. I would have loved > >> >> to have a claim type for carrying a nonce in the access token… > >> > > >> > Hmm, we say that "access_token is the decrypted access_token as > >> > transferred from the AS to the RS", but it's supposed to be a CBOR map; > >> > is this intended to just be the claims set from the CWT? If so, we > >> > should say that. > >> > >> I do not see the difference: The access token is comprised of a CWT > >> claim set which is represented on the wire as a CBOR map. > > > > The Message of the CWT is a CBOR map, but the access token itself is not > > just the Message, and "the decrypted access_token" is perhaps a bit > > informal of language for what we wang. (I think I was a bit confused when > > I wrote the original comment, though, as for JWT the structure is a bit > > different and the Claims Set a much more distinct object.) > > Maybe this is a bit more specific without adding a more detailed > explanation of how this is supposed to work below the bullet list: > > OLD: > > access_token is the decrypted access_token as transferred from the > authorization server to the resource server. > > NEW: > > access_token is the decrypted content of the access_token field > as transferred from the authorization server to the resource > server. Okay. (I note also the further discussion downthread regarding "innermost COSE message" and such.) > >> Unfortunately, this is not explained in draft-ietf-ace-oauth-params. > >> > >> To avoid confusion here, the following clarification has been added: > >> > >> NEW: > >> > >> The decrypted access token usually denotes a CWT claim set > >> represented as CBOR map. > > > > Thanks. > > > >> >> As there is no guidance so far on how permission sets in access tokens > >> >> are to be combined properly it seems to be wise at least to advise > >> >> against. > >> > > >> > I agree that's the right advice to give; what is less clear to me is > >> > whether this document needs to be the place to give that advice (vs. the > >> > framework doing so). But I don't have a strong stance on this at the > >> > moment, and am happy to move forward with the text as-is if you want. > >> > >> Okay, to avoid last-minute changes to the framework document I leave > >> it as it is. > >> > >> >> >> > I think RFCs 7250, 7251, and 8422 need to be normative. > >> >> >> > >> >> >> done > >> >> > >> >> Actually, I had to revert this for the informational RFC 7251 as the > >> >> idnits tool did not allow the downref from normative. > >> > > >> > idnits is just a tool to raise potential issues that a human can look > >> > at and think about; in this case, idnits is wrong: 7251 is listed at > >> > https://datatracker.ietf.org/doc/downref/ and is perfectly fine to use > >> > as a normative reference. > >> > >> Oh, sorry, I was not aware of that. This now has been reverted. > > > > Thanks for all the updates! > > > > I did have just a few nits from looking at the diff from -09 to -11; we can > > probably address those along with other IETF LC feedback (though fixing > > them earlier is not discouraged). > > That sounds as if shipping -12 now would be okay :-) Right :) > > Section 3.2 > > > > An example access token response from the authorization to the client > > is depicted in Figure 4. Here, the contents of the "access_token" > > > > nit: s/authorization/authorization server/ > > Fixed, thanks! > > > Section 3.3 > > > > I guess if we want the AS and RS to get the same key-derivation output we > > need to say that the encoding for 'L' is the minimum-length encoding > > Good point. As this is also true for the length encoding of the text > string in the type field, I have added the following clarification: > > NEW: > > All CBOR data types are encoded in canonical CBOR as defined in > Section 3.9 of {{RFC7049}}. This implies in particular that the > `type` and `L` components use the minimum length encoding. > > > (This unfortunately imposes additional restrictions on the > access_token which would not be required for key derivation. But IIRC > there has been some implicit agreement that the access_token should be > encoded in canonical CBOR as well. [this is handled downthread] > > Section 7 > > > > valid access tokens. The protection of access tokens that are stored > > in the authorization information endpoint depends on the keying > > material that is used between the authorization server and the > > resource server: The resource server must ensure that it processes > > only access tokens that are encrypted and integrity-protected by an > > authorization server that is authorized to provide access tokens for > > the resource server. > > > > We may want to put "encrypted and" in parentheses, as we don't require the > > use of encrypted CWTs. > > Done. However, the only situation where encryption is not a MUST is in > case of key derivation. > > > Section 7.1 > > > > nit: s/renogiation/renegotiation/ > > Thanks. I had to read this word several times to spot the difference :-) :) Thanks, Ben