From nobody Wed Jul 1 01:25: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 39AE13A0AD1; Wed, 1 Jul 2020 01:25: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 oDM4PqobhHu7; Wed, 1 Jul 2020 01:25: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 2066B3A0AD7; Wed, 1 Jul 2020 01:25:29 -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 49xZ6c3bj7zyy6; Wed, 1 Jul 2020 10:25:28 +0200 (CEST) From: Olaf Bergmann To: Jim Schaad Cc: "'Benjamin Kaduk'" , "'Carsten Bormann'" , ace@ietf.org, 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> <20200630162434.GM58278@kduck.mit.edu> <03ad01d64f14$66b0a080$3411e180$@augustcellars.com> Date: Wed, 01 Jul 2020 10:25:27 +0200 Message-ID: <87imf7tzew.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: Wed, 01 Jul 2020 08:25:33 -0000 Hi Jim, Jim Schaad writes: > 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. There seems to be agreement on this, and therefore I will change the text following Carsten's proposal (use bytes for the access_tocken and state that preferred serialization and deterministic serialization should be used for the CBOR serialization. > 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. You haven't missed anything=E2=80=94the intention always was to use the ori= ginal encoded token as transferred on the wire. The issue was introduced in this last unpublished change that should have clarified the serialization of the data structure that is used as input for the HKDF. > 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. Yes, this is inherent to the upload mechanism and unrelated to key derivation. My intention is to access-protect the token endpoint in my implementation such that only authorized clients can upload an access token. > 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. Now you have lost me. The innermost COSE wrapping layer would be the one in the contents of the cnf claim, given that we do not invent claims that also can include COSE structures? Gr=C3=BC=C3=9Fe Olaf From nobody Wed Jul 1 20:12: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 BBE063A0982; Wed, 1 Jul 2020 20:12:12 -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 7hc7pHXPvJ9Z; Wed, 1 Jul 2020 20:12: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 540E23A0979; Wed, 1 Jul 2020 20:12:11 -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 0623C2Om031009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 1 Jul 2020 23:12:04 -0400 Date: Wed, 1 Jul 2020 20:12:01 -0700 From: Benjamin Kaduk To: Olaf Bergmann Cc: Jim Schaad , "'Carsten Bormann'" , ace@ietf.org, draft-ietf-ace-dtls-authorize.all@ietf.org Message-ID: <20200702031201.GN58278@kduck.mit.edu> References: <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> <03ad01d64f14$66b0a080$3411e180$@augustcellars.com> <87imf7tzew.fsf@wangari> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87imf7tzew.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: Thu, 02 Jul 2020 03:12:13 -0000 On Wed, Jul 01, 2020 at 10:25:27AM +0200, Olaf Bergmann wrote: > Hi Jim, > > Jim Schaad writes: > > > 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. > > There seems to be agreement on this, and therefore I will change the > text following Carsten's proposal (use bytes for the access_tocken and > state that preferred serialization and deterministic serialization > should be used for the CBOR serialization. > > > 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. > > You haven't missed anything—the intention always was to use the original > encoded token as transferred on the wire. The issue was introduced in > this last unpublished change that should have clarified the > serialization of the data structure that is used as input for the HKDF. > > > 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. > > Yes, this is inherent to the upload mechanism and unrelated to key > derivation. My intention is to access-protect the token endpoint in my > implementation such that only authorized clients can upload an access > token. > > > 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. > > Now you have lost me. The innermost COSE wrapping layer would be the one > in the contents of the cnf claim, given that we do not invent claims > that also can include COSE structures? I think the intention is the "innermost COSE structure protecting the [entire] access token", to accomodate the fact that the access token might be COSE_Mac(), COSE_Encrypt(COSE_Mac()), etc., and not necessarily a fixed number of layers of COSE protection between the access token ciphertext and the CWT claim set. -Ben From nobody Wed Jul 1 21:19:43 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 97DBB3A0C50; Wed, 1 Jul 2020 21:19:42 -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 Pm4RvdLG6Nnv; Wed, 1 Jul 2020 21:19:39 -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 996813A0C4F; Wed, 1 Jul 2020 21:19:39 -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; Wed, 1 Jul 2020 21:19:32 -0700 From: Jim Schaad To: 'Olaf Bergmann' CC: 'Benjamin Kaduk' , 'Carsten Bormann' , , 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> <03ad01d64f14$66b0a080$3411e180$@augustcellars.com> <87imf7tzew.fsf@wangari> In-Reply-To: <87imf7tzew.fsf@wangari> Date: Wed, 1 Jul 2020 21:19:30 -0700 Message-ID: <048101d65027$fdaf2970$f90d7c50$@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: AQHGCRF5nmwiv9SPGwzqJ8qbQfLFcAHgMQg8AaMeee8CTdx1OgCvp4izAnkzCqgBoEnbuAKNZ0TDAQGsCtsB3iEDHgHXdTMvAlAL37iocsVMYA== 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: Thu, 02 Jul 2020 04:19:43 -0000 > -----Original Message----- > From: Olaf Bergmann > Sent: Wednesday, July 1, 2020 1:25 AM > To: Jim Schaad > Cc: 'Benjamin Kaduk' ; 'Carsten Bormann' = ; > ace@ietf.org; draft-ietf-ace-dtls-authorize.all@ietf.org > Subject: Re: [Ace] AD review of draft-ietf-ace-dtls-authorize-09 >=20 > Hi Jim, >=20 > Jim Schaad writes: >=20 > > 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. >=20 > There seems to be agreement on this, and therefore I will change the = text > following Carsten's proposal (use bytes for the access_tocken and = state that > preferred serialization and deterministic serialization should be used = for the > CBOR serialization. >=20 > > 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 > You haven't missed anything=E2=80=94the intention always was to use = the original > encoded token as transferred on the wire. The issue was introduced in = this last > unpublished change that should have clarified the serialization of the = data > structure that is used as input for the HKDF. >=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. >=20 > Yes, this is inherent to the upload mechanism and unrelated to key = derivation. > My intention is to access-protect the token endpoint in my = implementation such > that only authorized clients can upload an access token. >=20 > > 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. >=20 > Now you have lost me. The innermost COSE wrapping layer would be the = one in > the contents of the cnf claim, given that we do not invent claims that = also can > include COSE structures? Yes this is the binary string that holds the claims. It would be = possible to have multiple COSE layers - i.e. encrypt and signing layers, = and you would want to make sure that you agree on where you are pulling = the content. Using the token itself however is fine and you don't need to try and = deal with this. Jim >=20 > Gr=C3=BC=C3=9Fe > Olaf From nobody Thu Jul 2 00:35:54 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 23BA53A0DDC; Thu, 2 Jul 2020 00:35:52 -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 HkzPdZWciG_c; Thu, 2 Jul 2020 00:35:49 -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 36F793A0DCD; Thu, 2 Jul 2020 00:35:48 -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 49y8yq152FzyT1; Thu, 2 Jul 2020 09:35:47 +0200 (CEST) From: Olaf Bergmann To: Jim Schaad , "'Benjamin Kaduk'" Cc: "'Carsten Bormann'" , , 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> <03ad01d64f14$66b0a080$3411e180$@augustcellars.com> <87imf7tzew.fsf@wangari> <048101d65027$fdaf2970$f90d7c50$@augustcellars.com> Date: Thu, 02 Jul 2020 09:35:46 +0200 In-Reply-To: <048101d65027$fdaf2970$f90d7c50$@augustcellars.com> (Jim Schaad's message of "Wed, 1 Jul 2020 21:19:30 -0700") Message-ID: <87mu4is71p.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, 02 Jul 2020 07:35:52 -0000 Jim, Ben, Jim Schaad writes: [decrypted access_token as HKDF input] >> Now you have lost me. The innermost COSE wrapping layer would be the one= in >> the contents of the cnf claim, given that we do not invent claims that a= lso can >> include COSE structures? > > Yes this is the binary string that holds the claims. It would be > possible to have multiple COSE layers - i.e. encrypt and signing > layers, and you would want to make sure that you agree on where you > are pulling the content. I understand. I got a bit confused because when using key derivation, the access token does not necessarily have to be encrypted. > Using the token itself however is fine and you don't need to try and deal= with this. Actually, I would prefer that. For some reason, I was under the impression that the access token needs to be decrypted before key derivation can be done. Maybe this was in the very first version where only the kid was used as input. Gr=C3=BC=C3=9Fe Olaf From nobody Thu Jul 2 17:23:34 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 03C493A0A66; Thu, 2 Jul 2020 17:21:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: kaduk@mit.edu, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159373569899.29538.4713744900025652158@ietfa.amsl.com> Date: Thu, 02 Jul 2020 17:21:39 -0700 Archived-At: Subject: [Ace] ace - Requested session has been scheduled for IETF 108 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: Fri, 03 Jul 2020 00:21:47 -0000 Dear Daniel Migault, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ace Session 1 (1:40 requested) Wednesday, 29 July 2020, Session I 1100-1240 Room Name: Room 5 size: 5 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/108/sessions/ace.ics Request Information: --------------------------------------------------------- Working Group Name: Authentication and Authorization for Constrained Environments Area Name: Security Area Session Requester: Daniel Migault Number of Sessions: 1 Length of Session(s): 100 Minutes Number of Attendees: 15 Conflicts to Avoid: Chair Conflict: lamps calext drip Technology Overlap: lake tls oauth homenet t2trg suit core cose People who must be present: Daniel Migault Jim Schaad Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jul 2 22:28:45 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 E5B253A0CA9; Thu, 2 Jul 2020 22:28:43 -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 hGdR2K-CrVCs; Thu, 2 Jul 2020 22:28:41 -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 6C22D3A0CA6; Thu, 2 Jul 2020 22:28:40 -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 49yk5f24r0zyTZ; Fri, 3 Jul 2020 07:28:38 +0200 (CEST) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mao-Original-Outgoing-Id: 615446917.9053921-b5c3f4f63088f5577dd523c75f704e63 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Fri, 3 Jul 2020 07:28:37 +0200 Message-Id: <46C68869-C5F5-4AB0-A605-4E5224352D0F@tzi.org> To: Ace Wg , core , 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: FINAL 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: Fri, 03 Jul 2020 05:28:44 -0000 Here is my usual eclectic condensed agenda based on the FINAL AGENDA for IETF108. Remember that, occasionally, further agenda changes do happen. There has been no change from the DRAFT AGENDA in the Conflicts I noted: LAKE/SUIT (!). ACE/RATS. (I think 6LO/COSE can be ignored.) The only significant change is that LAKE/SUIT/LOOPS has been exchanged with CORE/TLS/TSVWG (Tuesday 1410Z vs. Friday 1100Z). Also, the mysterious HACKATHON has vanished. All times appear to be in UTC, even though nothing says so in the text agenda; https://datatracker.ietf.org/meeting/agenda-utc gives the same times. This time, I have focused on the events in Week 31; please see the original agenda for Week 30 preliminaries. Gr=C3=BC=C3=9Fe, Carsten MONDAY, July 27, 2020 1100-1240 Session I Rm 1 ART dispatch Dispatch WG - Joint with ARTAREA Rm 2 IRTF pearg Privacy Enhancements and Assessments Research = Group Rm 5 SEC *** teep Trusted Execution Environment Provisioning WG 1300-1350 Session II Rm 2 ART *** cbor Concise Binary Object Representation Maintenance = and Extensions WG Rm 3 INT intarea Internet Area Working Group WG Rm 6 RTG babel Babel routing protocol WG Rm 7 RTG detnet Deterministic Networking WG 1410-1550 Session III Rm 1 ART webtrans WebTransport WG Rm 3 IRTF qirg Quantum Internet Research Group Rm 7 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 7 SEC mls Messaging Layer Security WG Rm 8 SEC *** rats Remote ATtestation ProcedureS WG 1410-1550 Session III Rm 1 ART *** core Constrained RESTful Environments WG Rm 6 SEC tls Transport Layer Security WG Rm 7 TSV tsvwg Transport Area Working Group WG WEDNESDAY, July 29, 2020 1100-1240 Session I Rm 4 RTG bier Bit Indexed Explicit Replication WG Rm 5 SEC *** ace Authentication and Authorization for Constrained = Environments WG Rm 6 SEC *** rats Remote ATtestation ProcedureS WG Rm 7 TSV quic QUIC WG 1300-1350 Session II Rm 1 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 6 TSV tsvarea Transport Area Open Meeting 1410-1550 IETF Plenary - Plenary THURSDAY, July 30, 2020 1100-1240 Session I Rm 3 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 6 TSV tsvwg Transport Area Working Group WG 1300-1350 Session II Rm 4 INT *** lpwan IPv6 over Low Power Wide-Area Networks WG Rm 7 SEC saag Security Area Open Meeting 1410-1550 Session III Rm 2 INT add Adaptive DNS Discovery WG Rm 3 INT *** drip Drone Remote ID Protocol WG Rm 6 SEC acme Automated Certificate Management Environment WG FRIDAY, July 31, 2020 1100-1240 Session I Rm 5 SEC *** lake Lightweight Authenticated Key Exchange WG Rm 6 SEC *** suit Software Updates for Internet of Things WG Rm 7 TSV loops Local Optimizations on Path Segments BOF 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 4 IRTF coinrg Computing in the Network Research Group Rm 7 SEC privacypass Privacy Pass WG From nobody Thu Jul 2 23:56:08 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 E54683A0D5C for ; Thu, 2 Jul 2020 23:56:06 -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 mcctnQyEEYxE for ; Thu, 2 Jul 2020 23:56:05 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFD63A0D5A for ; Thu, 2 Jul 2020 23:56:04 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 783E9406AE for ; Fri, 3 Jul 2020 08:56:01 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id C8AC1AB for ; Fri, 3 Jul 2020 08:55:59 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a474:524e:673d:d8f5]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 7002164 for ; Fri, 3 Jul 2020 08:55:59 +0200 (CEST) Received: (nullmailer pid 696368 invoked by uid 1000); Fri, 03 Jul 2020 06:55:58 -0000 Date: Fri, 3 Jul 2020 08:55:58 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: ace@ietf.org Message-ID: <20200703065558.GA559393@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Ace] Call for adoption draft-tiloca-ace-oscore-gm-admin (with some review items) 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, 03 Jul 2020 06:56:07 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello ACE, I've read through draft-tiloca-ace-oscore-gm-admin. Its value is in that it fixes a gap in the set of current drafts on the topic: Without (something like) this, group deployment applications need application specific group managers, and as the GM is not trivial to implement, I'd expect that they would bundle the GM with their on-at-deployment-time tools rather than ship a constrained and well-specified always-on GM that's just managed by their deployment tools -- leading to much more error prone deployments that can't leverage OSCORE group communication in full. I don't quite see myself in a position to advocate adoption in this WG I haven't actively contributed to before, but I do support this document being processed somewhere in the IETF. Best regards Christian PS: Small by-catch issues for the authors: The pct-encoded names in the group name sound odd to me. What do those names have to do with URI components? The "is fixed" and "is a default name" terminology around resources is probably confusing to people who don't know ahead of time what it's supposed to mean; moreover, demanding that the URI be fixed is a pretty harsh requirement for something that may move around in the network; furthermore, while an I-D should avoid creating URI aliasing, it shouldn't rule out that the server may do that either. (And if it supports different transports, right now it needs to). Later in 2.5.3, it even sounds like the path is prescribed. Other than this being an ACE document, is there a particular reason "Getting Access to the Group Manager" is prescribed to use ACE? The whole 2.1 section sounds quite repetitive when read in the context of ACE, and unnecessary when different methods are employed. Maybe if there were talk about different admins and whether they may change each other's groups that'd be conveniently be expressed in terms of ACE scopes (not sure), but as of now it isn't. Why is "Update a Group Configuration" a PUT and not a PATCH? It does not replace the resource, it just modifies it. --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl7+1nkACgkQOY0REtOk veE+zBAAj1ZOCMT+aVzwxJUEpniRqDFDQCCoBSToiCOWSf5M8IgElk4u7ar5b+nh WCfKEMix8eh2eitE2ZwWS8Ssk9c+dcCDVM7AAq4Mco5Prv8dN0d+HlPJEU8gMDBg BCsnQoyd4BBMnb6xrXgCUFsaHWT+qXXVtFavRFnWu1URf7DOGFXY+T4BUsC8l3Sq 5sxetMyF5kSdMIfPoh+4l2WBC2w4ME9cJrem8IlXvWyjzCT2kt9GX9wiNJjJeTC0 6Lh6mctuW4J5iKKKdG/SuS1IPmnfUmvLXQIkTGN8aqC0cE15wal42mie2tPB67zl eX1+5ZwqJu/PnfPygO9t5ZVoFTgn5k9fn1WazVcQey+PquWm2NADvG0fn+Uzoo64 vDFCIpGD4oQtcOj3oRerVuFtc1cA8d6WwCQXNLOVNwdSePN1alfev/WPn0yVLZQo rJsOHXOdP4gn+X02FEh+y8BVNzJBqOdbuyV2hbQwUFLCc1yvwFnyOazdzeD88Qtp 0wPOxUJHgzhiieG+67pVrkC9f7+aXlsWZ+XO7VBMeYeKFWTCSsDx6L5CRhgPxNLo IMtbOvAd4aAyc13U9zur8l8qo/SONFgC/dAVCqGhnmLGLe8Zvd5A8qiboQpR+vS5 o/ynjMVXHbtQsNX1JcWuqczxCOSEGc7bzxnZ22SFXD3pW+Fq0LI= =HP9f -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr-- From nobody Fri Jul 3 00:11: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 E0BF13A0DBD for ; Fri, 3 Jul 2020 00:11:28 -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 tmR1nMW9Cg-m for ; Fri, 3 Jul 2020 00:11:27 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2066.outbound.protection.outlook.com [40.107.20.66]) (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 0E9703A0DB4 for ; Fri, 3 Jul 2020 00:11:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fCu58QC8wjHYXIUqtCW78fhkCL0PC97lOycpx5JchQ4cLX91XAvOFOU2CuzhUSPQAjDpM0dFCQrP68totKNEsOfFeboIyB+4sj2+IoBSLjvp6jZGEzc/r+nJFc9tWuzNGFnRSwELZqLDkWp/IGoo0vwtDRnKuFT6qe6XzFmOPDieOVHGFHawEDvM6omr4g1yj0mqDwH8iQ27lJdiXn4boZ4uQ+RScv+rF66Xd920zNIkcdJ8QaoPPNtfrrPHlXUxM0Fogo10wAht5MOToUu6VE534yaoXFO0yCYjTqkY2DEizQs421mL7CBrtRAUl8jfWbmRuQxsWmtKdUfe98zbBQ== 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=s8qvGTfcBgMlPObUXEByi6xUzhgI2RaOCO8HTGPW6NE=; b=fCEPgo5ifrPkHwd64bSUd0sPRn427oExdRf+FMxmsrqTYsskAx6w3+nCGWbREKG4Z9R19+1+eTffFQ/1GLkQe/Zu88rIHChC+BuVOTq9M9YbMFCFNbb2OK4EvLcm+n9knQvRxAeYlQMWLllnee4Cths5Ur9KnH3SUnWQXHtgIdH1WAB/9z4Tcvz8lYlYAJ6hDuHJDs3sBjMfs5tA+JVWFDNo8LMAcr/Q33PlDsGqf1HED1bMGY0oXO/KdQ1B5IhnnqzmSgbHc9aJrua3Ygk1v4/yMpzCXM94b6qvIvm8PnOvMMohFLffLvawbaX6cwO/AaOeCY0Z3Hc8pxQrC0yIug== 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=s8qvGTfcBgMlPObUXEByi6xUzhgI2RaOCO8HTGPW6NE=; b=mVd/SZ7bWPCrhMNqdAe+pa8talerwP0Ato+KyP3BxbymqUMCL1HcCT+wr/wIcxsRjh2VudEV32iPrCgCSNizQ4QOwrF50fThc9K639zDuF0K2KqiFgYN5Af4vSiTSkwVGUAG3w0G4jQufHdJEBiu+sdVhhlqZiman2vrAtYskAA= Received: from AM0PR0702MB3665.eurprd07.prod.outlook.com (2603:10a6:208:1e::21) by AM0PR07MB6260.eurprd07.prod.outlook.com (2603:10a6:20b:15a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.10; Fri, 3 Jul 2020 07:11:25 +0000 Received: from AM0PR0702MB3665.eurprd07.prod.outlook.com ([fe80::75ea:232a:4132:452e]) by AM0PR0702MB3665.eurprd07.prod.outlook.com ([fe80::75ea:232a:4132:452e%4]) with mapi id 15.20.3153.028; Fri, 3 Jul 2020 07:11:25 +0000 From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= To: "ace@ietf.org" Thread-Topic: [Ace] Call for adoption draft-tiloca-ace-oscore-gm-admin (with some review items) Thread-Index: AQHWUQcOALKntCrXyUOckpzNX7iTSKj1kcsA Date: Fri, 3 Jul 2020 07:11:24 +0000 Message-ID: <0402CE8F-001C-4333-8C64-662B1C13E6F0@ericsson.com> References: <20200703065558.GA559393@hephaistos.amsuess.com> In-Reply-To: <20200703065558.GA559393@hephaistos.amsuess.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.38.20061401 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: [83.251.145.232] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d12a6999-73a3-4e21-60aa-08d81f204c2d x-ms-traffictypediagnostic: AM0PR07MB6260: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 045315E1EE x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: plTjQrj+w8pSIrTPVyW7G+x0wzcL2VzXPwr+vDR97QCg0nzvohkKHX9ExDeswv+PN/NWsBpubqbWVageCL7d2Jbj2S8SU/Fz8ES2CC9DQqatkhld1IKs2sGn2+IG/FQmSbMWqnocJjpB78z72huin4fDT+xIbb4uN5kEYfv4IF8I8xXIqFHuSJaVM6tKUbewiY9zeX+M2I0T0p/Fb0mRT4XeJO7DveUpNkPIf/sL5WSxnQCi3veAJbkkCn5+/6k1rdKVrtqcdFVBmfFTjLAEVUYCaom2nQvEW25GBrGCWyt734MAVMEa0aCg9k2bvE/TkobPCqW5K/nQvU5gsldPaQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0702MB3665.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(136003)(346002)(396003)(376002)(478600001)(33656002)(66556008)(186003)(5660300002)(66476007)(2616005)(83380400001)(91956017)(66574015)(76116006)(66946007)(6486002)(71200400001)(316002)(8676002)(8936002)(64756008)(85182001)(86362001)(6916009)(6506007)(6512007)(2906002)(66446008)(85202003)(26005)(36756003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: NOWnuMBTCiRkNzcXCrLCPTq23w8vD74WlIFCc/l3czlLfFEQtbZ7awrArlGZMOT1wl+BtQxNw/6i9j1rJOkysZBUyw6E15hMUyFPVXx7kMu9xK6q8qC3GslItPzm49Zo3oObeDXiDw7xDMEoz6xVeVzfWura78V8Jh6FjTlZu2o84TJYl2/tEMBgTObwsXBiRv6NXer2AfxR7QkGbzuRPkVVurv6AeGyw1GUoi3T/wzWW31CHJVUXzBLAzMbXidWWZJoUrnIbINw9YRonyMsiFhgBOW8oHOQ/wbrkHoKVH1OfEpJsWFViA79rOxZVTcWOzP4GG7ty7z/B33Et1+yKhQZwkqP3+/HyWIRZf8A0fXr/VdW7GDhzyJABRE+BVDD1xkNGwvIFSs1rtLD4jes/8d+qZ7KWjab5DrKr3xNttYk284XfTbUmBD4m9Hkx1JS0tFcZNY4/c34Ar9uePuA56q0mGj8Rb7zRFM2xxlfA0V6dsNI5zb/wYBqzYZhMnGv x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <794F979D03E0B6448F30E9596A63F47C@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: AM0PR0702MB3665.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d12a6999-73a3-4e21-60aa-08d81f204c2d X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2020 07:11:24.9922 (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: E+WpzNfWEblotD5ewiMMcBdcOT57CSQN5oATQdw/I76i+EtLKgC+YjO5UGpqV6+ddkn7CpXFISyEooBCRZEZNBwXqCnQcTmyWlVlHvW33y4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6260 Archived-At: Subject: Re: [Ace] Call for adoption draft-tiloca-ace-oscore-gm-admin (with some review items) 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, 03 Jul 2020 07:11:29 -0000 PiAgICBJJ3ZlIHJlYWQgdGhyb3VnaCBkcmFmdC10aWxvY2EtYWNlLW9zY29yZS1nbS1hZG1pbi4g SXRzIHZhbHVlIGlzIGluIHRoYXQNCj4gICAgaXQgZml4ZXMgYSBnYXAgaW4gdGhlIHNldCBvZiBj dXJyZW50IGRyYWZ0cyBvbiB0aGUgdG9waWM6DQoNCj4gICAgV2l0aG91dCAoc29tZXRoaW5nIGxp a2UpIHRoaXMsIGdyb3VwIGRlcGxveW1lbnQgYXBwbGljYXRpb25zIG5lZWQNCj4gICAgYXBwbGlj YXRpb24gc3BlY2lmaWMgZ3JvdXAgbWFuYWdlcnMsIGFuZCBhcyB0aGUgR00gaXMgbm90IHRyaXZp YWwgdG8NCj4gICAgaW1wbGVtZW50LCBJJ2QgZXhwZWN0IHRoYXQgdGhleSB3b3VsZCBidW5kbGUg dGhlIEdNIHdpdGggdGhlaXINCj4gICAgb24tYXQtZGVwbG95bWVudC10aW1lIHRvb2xzIHJhdGhl ciB0aGFuIHNoaXAgYSBjb25zdHJhaW5lZCBhbmQNCj4gICAgd2VsbC1zcGVjaWZpZWQgYWx3YXlz LW9uIEdNIHRoYXQncyBqdXN0IG1hbmFnZWQgYnkgdGhlaXIgZGVwbG95bWVudA0KPiAgICB0b29s cyAtLSBsZWFkaW5nIHRvIG11Y2ggbW9yZSBlcnJvciBwcm9uZSBkZXBsb3ltZW50cyB0aGF0IGNh bid0DQo+ICAgIGxldmVyYWdlIE9TQ09SRSBncm91cCBjb21tdW5pY2F0aW9uIGluIGZ1bGwuDQoN CisxIA0KDQpJIHN1cHBvcnQgYWRvcHRpb24uDQoNCkfDtnJhbg0KDQoNCg0K77u/T24gMjAyMC0w Ny0wMywgMDg6NTYsICJBY2Ugb24gYmVoYWxmIG9mIENocmlzdGlhbiBBbXPDvHNzIiA8YWNlLWJv dW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNocmlzdGlhbkBhbXN1ZXNzLmNvbT4gd3JvdGU6 DQoNCiAgICBIZWxsbyBBQ0UsDQoNCiAgICBJJ3ZlIHJlYWQgdGhyb3VnaCBkcmFmdC10aWxvY2Et YWNlLW9zY29yZS1nbS1hZG1pbi4gSXRzIHZhbHVlIGlzIGluIHRoYXQNCiAgICBpdCBmaXhlcyBh IGdhcCBpbiB0aGUgc2V0IG9mIGN1cnJlbnQgZHJhZnRzIG9uIHRoZSB0b3BpYzoNCg0KICAgIFdp dGhvdXQgKHNvbWV0aGluZyBsaWtlKSB0aGlzLCBncm91cCBkZXBsb3ltZW50IGFwcGxpY2F0aW9u cyBuZWVkDQogICAgYXBwbGljYXRpb24gc3BlY2lmaWMgZ3JvdXAgbWFuYWdlcnMsIGFuZCBhcyB0 aGUgR00gaXMgbm90IHRyaXZpYWwgdG8NCiAgICBpbXBsZW1lbnQsIEknZCBleHBlY3QgdGhhdCB0 aGV5IHdvdWxkIGJ1bmRsZSB0aGUgR00gd2l0aCB0aGVpcg0KICAgIG9uLWF0LWRlcGxveW1lbnQt dGltZSB0b29scyByYXRoZXIgdGhhbiBzaGlwIGEgY29uc3RyYWluZWQgYW5kDQogICAgd2VsbC1z cGVjaWZpZWQgYWx3YXlzLW9uIEdNIHRoYXQncyBqdXN0IG1hbmFnZWQgYnkgdGhlaXIgZGVwbG95 bWVudA0KICAgIHRvb2xzIC0tIGxlYWRpbmcgdG8gbXVjaCBtb3JlIGVycm9yIHByb25lIGRlcGxv eW1lbnRzIHRoYXQgY2FuJ3QNCiAgICBsZXZlcmFnZSBPU0NPUkUgZ3JvdXAgY29tbXVuaWNhdGlv biBpbiBmdWxsLg0KDQogICAgSSBkb24ndCBxdWl0ZSBzZWUgbXlzZWxmIGluIGEgcG9zaXRpb24g dG8gYWR2b2NhdGUgYWRvcHRpb24gaW4gdGhpcyBXRyBJDQogICAgaGF2ZW4ndCBhY3RpdmVseSBj b250cmlidXRlZCB0byBiZWZvcmUsIGJ1dCBJIGRvIHN1cHBvcnQgdGhpcyBkb2N1bWVudA0KICAg IGJlaW5nIHByb2Nlc3NlZCBzb21ld2hlcmUgaW4gdGhlIElFVEYuDQoNCiAgICBCZXN0IHJlZ2Fy ZHMNCiAgICBDaHJpc3RpYW4NCg0KDQogICAgUFM6IFNtYWxsIGJ5LWNhdGNoIGlzc3VlcyBmb3Ig dGhlIGF1dGhvcnM6DQoNCiAgICBUaGUgcGN0LWVuY29kZWQgbmFtZXMgaW4gdGhlIGdyb3VwIG5h bWUgc291bmQgb2RkIHRvIG1lLiBXaGF0IGRvIHRob3NlDQogICAgbmFtZXMgaGF2ZSB0byBkbyB3 aXRoIFVSSSBjb21wb25lbnRzPw0KDQogICAgVGhlICJpcyBmaXhlZCIgYW5kICJpcyBhIGRlZmF1 bHQgbmFtZSIgdGVybWlub2xvZ3kgYXJvdW5kIHJlc291cmNlcyBpcw0KICAgIHByb2JhYmx5IGNv bmZ1c2luZyB0byBwZW9wbGUgd2hvIGRvbid0IGtub3cgYWhlYWQgb2YgdGltZSB3aGF0IGl0J3MN CiAgICBzdXBwb3NlZCB0byBtZWFuOyBtb3Jlb3ZlciwgZGVtYW5kaW5nIHRoYXQgdGhlIFVSSSBi ZSBmaXhlZCBpcyBhIHByZXR0eQ0KICAgIGhhcnNoIHJlcXVpcmVtZW50IGZvciBzb21ldGhpbmcg dGhhdCBtYXkgbW92ZSBhcm91bmQgaW4gdGhlIG5ldHdvcms7DQogICAgZnVydGhlcm1vcmUsIHdo aWxlIGFuIEktRCBzaG91bGQgYXZvaWQgY3JlYXRpbmcgVVJJIGFsaWFzaW5nLCBpdA0KICAgIHNo b3VsZG4ndCBydWxlIG91dCB0aGF0IHRoZSBzZXJ2ZXIgbWF5IGRvIHRoYXQgZWl0aGVyLiAoQW5k IGlmIGl0DQogICAgc3VwcG9ydHMgZGlmZmVyZW50IHRyYW5zcG9ydHMsIHJpZ2h0IG5vdyBpdCBu ZWVkcyB0bykuIExhdGVyIGluIDIuNS4zLA0KICAgIGl0IGV2ZW4gc291bmRzIGxpa2UgdGhlIHBh dGggaXMgcHJlc2NyaWJlZC4NCg0KICAgIE90aGVyIHRoYW4gdGhpcyBiZWluZyBhbiBBQ0UgZG9j dW1lbnQsIGlzIHRoZXJlIGEgcGFydGljdWxhciByZWFzb24NCiAgICAiR2V0dGluZyBBY2Nlc3Mg dG8gdGhlIEdyb3VwIE1hbmFnZXIiIGlzIHByZXNjcmliZWQgdG8gdXNlIEFDRT8gVGhlDQogICAg d2hvbGUgMi4xIHNlY3Rpb24gc291bmRzIHF1aXRlIHJlcGV0aXRpdmUgd2hlbiByZWFkIGluIHRo ZSBjb250ZXh0IG9mDQogICAgQUNFLCBhbmQgdW5uZWNlc3Nhcnkgd2hlbiBkaWZmZXJlbnQgbWV0 aG9kcyBhcmUgZW1wbG95ZWQuIE1heWJlIGlmIHRoZXJlDQogICAgd2VyZSB0YWxrIGFib3V0IGRp ZmZlcmVudCBhZG1pbnMgYW5kIHdoZXRoZXIgdGhleSBtYXkgY2hhbmdlIGVhY2gNCiAgICBvdGhl cidzIGdyb3VwcyB0aGF0J2QgYmUgY29udmVuaWVudGx5IGJlIGV4cHJlc3NlZCBpbiB0ZXJtcyBv ZiBBQ0UNCiAgICBzY29wZXMgKG5vdCBzdXJlKSwgYnV0IGFzIG9mIG5vdyBpdCBpc24ndC4NCg0K ICAgIFdoeSBpcyAiVXBkYXRlIGEgR3JvdXAgQ29uZmlndXJhdGlvbiIgYSBQVVQgYW5kIG5vdCBh IFBBVENIPyBJdCBkb2VzIG5vdA0KICAgIHJlcGxhY2UgdGhlIHJlc291cmNlLCBpdCBqdXN0IG1v ZGlmaWVzIGl0Lg0KDQogICAgLS0gDQogICAgVG8gdXNlIHJhdyBwb3dlciBpcyB0byBtYWtlIHlv dXJzZWxmIGluZmluaXRlbHkgdnVsbmVyYWJsZSB0byBncmVhdGVyIHBvd2Vycy4NCiAgICAgIC0t IEJlbmUgR2Vzc2VyaXQgYXhpb20NCg0K From nobody Fri Jul 3 04:41:38 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 966833A0CD4; Fri, 3 Jul 2020 04:41:37 -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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159377649754.13236.16318214637537912909@ietfa.amsl.com> Date: Fri, 03 Jul 2020 04:41:37 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-pubsub-profile-01.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: Fri, 03 Jul 2020 11:41:38 -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 : Pub-Sub Profile for Authentication and Authorization for Constrained Environments (ACE) Author : Francesca Palombini Filename : draft-ietf-ace-pubsub-profile-01.txt Pages : 21 Date : 2020-07-03 Abstract: This specification defines an application profile for authentication and authorization for publishers and subscribers in a pub-sub setting scenario in a constrained environment, using the ACE framework. This profile relies on transport layer or application layer security to authorize the publisher to the broker. Moreover, it relies on application layer security for publisher-broker and subscriber-broker communication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-pubsub-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-pubsub-profile-01 https://datatracker.ietf.org/doc/html/draft-ietf-ace-pubsub-profile-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-pubsub-profile-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 3 05:02:41 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 53E583A0CFE; Fri, 3 Jul 2020 05:02:40 -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 crziXyMjwQuA; Fri, 3 Jul 2020 05:02:39 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00045.outbound.protection.outlook.com [40.107.0.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 98B9D3A0CFC; Fri, 3 Jul 2020 05:02:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XlivwaQYnC+k8G4LgzJMf2u+3dJfZeQNoiVTYJsgxrXVNFclIeTBAXbmdr51HtfqTnlsXceSvGa+R2WUcfwWfPuxhDg0oP1rQWqh+rQvjjkv3zG6Jbr/6KJ8ip+y91ah9zJDVQdMcF+aCK+hYe6w59fyhwxttHK8QloQri62PdoAz44OjLmwBCemQFc0apnO6LkV36YllqCgxILA5c00YDmK+f+03+O0U24QfNQRJsEw4+02tK+SlnXy1U8scxlYWTS6ZZ2VR+PfplblLz3zBnRI28PiRstESVGahM7Tt95MDQqpTWXxU9bWaXFUUStR9Ze8QUiFkKEmuic+YHW1Eg== 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=JTsiRBkk2X+1KGZm+xhLkPkT7H+dD7BgpSIF2vN/oDU=; b=WGRbncALtUVOR2e6Ko/OEWhmEZ5N7XPdXKCatN0z3P/SiFJhIow/C/fVbnoR3F3EqeBxfK+Gth1+t7yzmeFr8zklm/ZFI2RCwRqBtBGU2dLJ7k+NJoLJj7JAMCx8R8+7dqLUyjiXVZMNhoowTQFtDrsQvwEX5DTaDRn/jedsQ4wm1QV2fU8E9pgt3AUq0kl9fLgryhb3H/HKTzov+prPIeUX2QF63HrrURDu5a49ezT6yWgRlLkuX/g+QjehM4bEhrGLimug2t7x1jnKDXWmeOWpFFCpBVh9hQ3icwXGBCs2K71czdMRDj9/+fgsT1li5RLMc7g4f6HZIfuB2Gmzrg== 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=JTsiRBkk2X+1KGZm+xhLkPkT7H+dD7BgpSIF2vN/oDU=; b=XPsLQe+G3Z8mjRqvkgUQpiSqXdSs6mcN05iHrnZpLO3Rhid2mhEn5wTJ9moJFBEcxrslPvRGPqbrJIquc0/tY3TrGov8qPdOWKxsweUE+Dvtk30A1CiyKOXAgascgzbR6Fjx8fFV++nhpTNJ8cuZ0uhNv8HMcT0y/DWAXTMYxkA= Received: from VI1PR0702MB3824.eurprd07.prod.outlook.com (2603:10a6:803:c::15) by VI1PR07MB3069.eurprd07.prod.outlook.com (2603:10a6:802:20::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.8; Fri, 3 Jul 2020 12:02:36 +0000 Received: from VI1PR0702MB3824.eurprd07.prod.outlook.com ([fe80::81e4:f15:6912:d9bd]) by VI1PR0702MB3824.eurprd07.prod.outlook.com ([fe80::81e4:f15:6912:d9bd%4]) with mapi id 15.20.3153.024; Fri, 3 Jul 2020 12:02:36 +0000 From: Francesca Palombini To: "ace@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [Ace] I-D Action: draft-ietf-ace-pubsub-profile-01.txt Thread-Index: AQHWUS7v5WcmYdLW5UGIRU/0tO1TfKj14taA Date: Fri, 3 Jul 2020 12:02:35 +0000 Message-ID: References: <159377649754.13236.16318214637537912909@ietfa.amsl.com> In-Reply-To: <159377649754.13236.16318214637537912909@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: e239e4ed-4575-40e6-768d-08d81f48f9eb x-ms-traffictypediagnostic: VI1PR07MB3069: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BteaZSjMDuSBJ5+rd8Pla3PRgo1+IkvCJLmdka+iLl8dz/cV2LMCwrbjwHn9Qbc01PLjbcjlfvP5zbpeFVX6suLr2SrkJII36kOByac32u6ufO6M/jjQKm5mHE0nezfTsbIluIIX0iJOKwx+s9JryhPAIGe19AMX5g+4MyDmIMQW0QOtSZmGVTa5O/Xmx+6dy2kkIVOJnYOwIhn9YUDoaZC9TmNVnlZZ4lvD3/7c3F6++t7fAvN55t9C5BLt2uevbc7BvzY/RC434nvUBpEZspEsNwqVPLh6Zz5xVE4b6hBMgFo8gUUVs1rZSwQAkowRA50nR30rzV8wGOTqoL+JTz6MIqgAjkbew26nHA/B7fyS1zYQk6M+LFsM1SZtVhXEskh15XCcRx5YRNpM7B3NJQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0702MB3824.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(39860400002)(346002)(396003)(366004)(6486002)(8676002)(5660300002)(33656002)(2906002)(8936002)(186003)(6506007)(86362001)(26005)(44832011)(66574015)(91956017)(76116006)(36756003)(478600001)(71200400001)(316002)(64756008)(110136005)(66446008)(66476007)(2616005)(66946007)(66556008)(83380400001)(966005)(450100002)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: C7FBOk/OnNrJJwNPHZNpiiQbLFA+T5sMvYR+4BfoxNDCcJdi8DfMOxVsVXeNd/LuFw0rO37KND2yBVJSFoBuRT0ArVEEWmwSaemBX1y2GTij+4rLmcK1SbuQp/+GKON7unoxsaz9uh/Mlzo2bJtOqJz+IIKaytJxToLlC2PlLll51dlWYis170LRcjh6RtBVJtICznHdzuU7IDn4IqXThlg/IXiggZPJKdQKrKa1He8Nej1ubh7CbDfDCNTGdzOb67FxXxrdQHYlz3vRWhPC7Eml+Abo9JLd+QhZJ6C9OQLxPZt4MBqCQnkNPEvcD95CWTGwhM+FXvsgJuvimmaVIMyLviVKuNnDXn4FRZGHClGGk5mly/hMpKDnUX0K4QMfg5ABnWEX7qDsvjLMUUGuXSm/9EMcoF+E6ragCMiu58Dff5qiBYkZlZQx7+oHgiJe59cOCd2gXxpYiZgr1vtmiznN2uvTtRj2nGFp/yq/Qrk4gc9u6XhKoky523m+yBee x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <24C2C17661A61241AF94B4AA21DFAA85@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: VI1PR0702MB3824.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e239e4ed-4575-40e6-768d-08d81f48f9eb X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2020 12:02:35.9832 (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: YJDpcDfFEGGoFMNUAlkQQug9TktHgGmAWn6GinCOVRmjjDP/sVWy3unSJI+DF3Xbn/hw6Tmmmk5LCsuPYox4CggltWsgsPWfoc3j+/dHFP4XwHsTCWlmMOo0q6YJ8fd3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3069 Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-pubsub-profile-01.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: Fri, 03 Jul 2020 12:02:40 -0000 SGksDQoNClRoaXMgdXBkYXRlIGNvbnZlcnRzIHRoZSBkb2N1bWVudCB0byB0aGUgbW9yZSBnZW5l cmFsIHN0cnVjdHVyZSB0byBjb3ZlciBmb3IgTVFUVCBhcyB3ZWxsLiBUaGVyZSBpcyBzb21lIFRP RE9zIGxlZnQgZm9yIHRoZSBNUVRUIHBhcnRzLCB0aGF0IHdlIHBsYW4gdG8gdXBkYXRlLg0KDQpU aGFua3MsDQpGcmFuY2VzY2ENCg0K77u/T24gMDMvMDcvMjAyMCwgMTM6NDEsICJBY2Ugb24gYmVo YWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGFjZS1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IHdyb3RlOg0KDQoNCiAgICBBIE5l dyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1E cmFmdHMgZGlyZWN0b3JpZXMuDQogICAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUg QXV0aGVudGljYXRpb24gYW5kIEF1dGhvcml6YXRpb24gZm9yIENvbnN0cmFpbmVkIEVudmlyb25t ZW50cyBXRyBvZiB0aGUgSUVURi4NCg0KICAgICAgICAgICAgVGl0bGUgICAgICAgICAgIDogUHVi LVN1YiBQcm9maWxlIGZvciBBdXRoZW50aWNhdGlvbiBhbmQgQXV0aG9yaXphdGlvbiBmb3IgQ29u c3RyYWluZWQgRW52aXJvbm1lbnRzIChBQ0UpDQogICAgICAgICAgICBBdXRob3IgICAgICAgICAg OiBGcmFuY2VzY2EgUGFsb21iaW5pDQogICAgCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYt YWNlLXB1YnN1Yi1wcm9maWxlLTAxLnR4dA0KICAgIAlQYWdlcyAgICAgICAgICAgOiAyMQ0KICAg IAlEYXRlICAgICAgICAgICAgOiAyMDIwLTA3LTAzDQoNCiAgICBBYnN0cmFjdDoNCiAgICAgICBU aGlzIHNwZWNpZmljYXRpb24gZGVmaW5lcyBhbiBhcHBsaWNhdGlvbiBwcm9maWxlIGZvciBhdXRo ZW50aWNhdGlvbg0KICAgICAgIGFuZCBhdXRob3JpemF0aW9uIGZvciBwdWJsaXNoZXJzIGFuZCBz dWJzY3JpYmVycyBpbiBhIHB1Yi1zdWIgc2V0dGluZw0KICAgICAgIHNjZW5hcmlvIGluIGEgY29u c3RyYWluZWQgZW52aXJvbm1lbnQsIHVzaW5nIHRoZSBBQ0UgZnJhbWV3b3JrLiAgVGhpcw0KICAg ICAgIHByb2ZpbGUgcmVsaWVzIG9uIHRyYW5zcG9ydCBsYXllciBvciBhcHBsaWNhdGlvbiBsYXll ciBzZWN1cml0eSB0bw0KICAgICAgIGF1dGhvcml6ZSB0aGUgcHVibGlzaGVyIHRvIHRoZSBicm9r ZXIuICBNb3Jlb3ZlciwgaXQgcmVsaWVzIG9uDQogICAgICAgYXBwbGljYXRpb24gbGF5ZXIgc2Vj dXJpdHkgZm9yIHB1Ymxpc2hlci1icm9rZXIgYW5kIHN1YnNjcmliZXItYnJva2VyDQogICAgICAg Y29tbXVuaWNhdGlvbi4NCg0KDQogICAgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQgaXM6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1hY2UtcHVic3ViLXByb2ZpbGUvDQoNCiAgICBUaGVyZSBhcmUgYWxzbyBodG1s aXplZCB2ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtYWNlLXB1YnN1Yi1wcm9maWxlLTAxDQogICAgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLWFjZS1wdWJzdWItcHJvZmlsZS0wMQ0K DQogICAgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0K ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWFjZS1wdWJz dWItcHJvZmlsZS0wMQ0KDQoNCiAgICBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQogICAgdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9y Zy4NCg0KICAgIEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3Vz IEZUUCBhdDoNCiAgICBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQoNCiAg ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIEFj ZSBtYWlsaW5nIGxpc3QNCiAgICBBY2VAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2FjZQ0KDQo= From nobody Mon Jul 6 03:07: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 2B1263A12CB; Mon, 6 Jul 2020 03:07:25 -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.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159403004507.14441.987009020414761740@ietfa.amsl.com> Date: Mon, 06 Jul 2020 03:07:25 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-dtls-authorize-12.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, 06 Jul 2020 10:07:25 -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-12.txt Pages : 27 Date : 2020-07-06 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-12 https://datatracker.ietf.org/doc/html/draft-ietf-ace-dtls-authorize-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-dtls-authorize-12 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 Jul 6 03:09:45 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 8E0D73A12D2 for ; Mon, 6 Jul 2020 03:09:43 -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 tkSd7lzBj6n0 for ; Mon, 6 Jul 2020 03:09:41 -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 485243A12D0 for ; Mon, 6 Jul 2020 03:09:41 -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 4B0hBW5f3tzyhD for ; Mon, 6 Jul 2020 12:09:39 +0200 (CEST) From: Olaf Bergmann To: ace@ietf.org References: <159403004507.14441.987009020414761740@ietfa.amsl.com> Date: Mon, 06 Jul 2020 12:09:39 +0200 In-Reply-To: <159403004507.14441.987009020414761740@ietfa.amsl.com> (internet-drafts@ietf.org's message of "Mon, 06 Jul 2020 03:07:25 -0700") Message-ID: <87zh8duf8c.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-12.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, 06 Jul 2020 10:09:44 -0000 Dear ACE mailing list, we have submitted version -12 of the DTLS profile for ACE, addressing the latest review comments from Ben, Jim, and Carsten (see discussion thread on this mailing 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-12.txt > Pages : 27 > Date : 2020-07-06 > > 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 Mon Jul 6 06:37:38 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 2720E3A148C; Mon, 6 Jul 2020 06:37:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk CC: Jim Schaad , ace-chairs@ietf.org, kaduk@mit.edu, ietf@augustcellars.com, ace@ietf.org, draft-ietf-ace-dtls-authorize@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159404264470.27211.9903993410588380842@ietfa.amsl.com> Date: Mon, 06 Jul 2020 06:37:25 -0700 Archived-At: Subject: [Ace] Last Call: (Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)) to Proposed Standard 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, 06 Jul 2020 13:37:25 -0000 The IESG has received a request from the Authentication and Authorization for Constrained Environments WG (ace) to consider the following document: - 'Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-07-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ace-dtls-authorize/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/3112/ From nobody Mon Jul 6 06:57:39 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 6FBEF3A150D; Mon, 6 Jul 2020 06:57:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk CC: ietf@augustcellars.com, draft-ietf-ace-oscore-profile@ietf.org, ace@ietf.org, Jim Schaad , kaduk@mit.edu, ace-chairs@ietf.org Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <159404385192.27645.4383941149844505052@ietfa.amsl.com> Date: Mon, 06 Jul 2020 06:57:32 -0700 Archived-At: Subject: [Ace] Last Call: (OSCORE profile of the Authentication and Authorization for Constrained Environments Framework) to Proposed Standard 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, 06 Jul 2020 13:57:33 -0000 The IESG has received a request from the Authentication and Authorization for Constrained Environments WG (ace) to consider the following document: - 'OSCORE profile of the Authentication and Authorization for Constrained Environments Framework' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-07-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-profile/ No IPR declarations have been submitted directly on this I-D. From nobody Mon Jul 13 01:17: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 640B93A0B18; Mon, 13 Jul 2020 01:17:24 -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.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159462824437.20882.7289165136459426376@ietfa.amsl.com> Date: Mon, 13 Jul 2020 01:17:24 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-mqtt-tls-profile-06.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, 13 Jul 2020 08:17: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 : MQTT-TLS profile of ACE Authors : Cigdem Sengul Anthony Kirby Paul Fremantle Filename : draft-ietf-ace-mqtt-tls-profile-06.txt Pages : 30 Date : 2020-07-13 Abstract: This document specifies a profile for the ACE (Authentication and Authorization for Constrained Environments) framework to enable authorization in an Message Queuing Telemetry Transport (MQTT)-based publish-subscribe messaging system. Proof-of-possession keys, bound to OAuth2.0 access tokens, are used to authenticate and authorize MQTT Clients. The protocol relies on TLS for confidentiality and MQTT server (broker) authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-06 https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 13 01:28:30 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 DB89E3A0BF7 for ; Mon, 13 Jul 2020 01:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[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 zG5NnFCUkX6O for ; Mon, 13 Jul 2020 01:28:27 -0700 (PDT) Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 4E85D3A0BF2 for ; Mon, 13 Jul 2020 01:28:27 -0700 (PDT) Received: by mail-vk1-xa33.google.com with SMTP id s192so2609787vkh.3 for ; Mon, 13 Jul 2020 01:28:27 -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=va69hVzc+gdpZMc6I1UJca5fHWQnDHNYa1Da/C33j+I=; b=Gfqhkw70d2Vh+yz2DyFOqQ9es/++SDMPa9m8NvKAydgAgNijqQwKeOtwHQlCrk4yPk 6hCxyDZach6GG58bEvL6tVWksjVC5McANeGKep8neFVQGf5XWfyw1sIoWuRsAtKt5OEL R30PEtu3g9/mDfxeqsoYJcrSmKB5VWCJSuktdym5was4gvPsE9frulD3XblBKkE+lWnw jXex6iwssywcH7+ith/fL3EoHbl4bt1LeDUjOSHlh3kztjHaevEk1T7ZR6DXrb8KpiWX EqhpoREHb001w6ybFrHrJpbfn4zS/KZnSQyygZvgALX6XZmIBFD22CnADLghDAvBWf0t 4XJA== 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=va69hVzc+gdpZMc6I1UJca5fHWQnDHNYa1Da/C33j+I=; b=Afaku1E1yd8wO0aFzvSifbPj38EJyD3dVjv7bd8QoL9XEbXYHfsFjOeXCiNKmZBI8r XsDU5/oQe4Zb3vwYon3aO1uikyRcsQSgkthCLwcvRumvBYwxTKkqqWzCT5v1gaekAFmu eX3/iHezhRaULNBwEZGqmafQlxtIVYT2Qde3lMDCT3MKR/bnzFf5VykMM4hjpy7HwekD CV1PAB8l82073/CfEUlcRpFtd+N1hHXAjSPYk9BO9VnZwFZdrUyFhBS4/DhLo8btrsFx HhZrs9Vcxd9q3bcNSP8SX46Ks2diXIdK/SH5TtpagdvMRzGf8jAxK2GRw5YsTfhXxz00 PKfg== X-Gm-Message-State: AOAM5339V8Xm7JBn8f0GCQMDMo93hnDRnAwgZmUV46nH3g9HfxxoK9CC Ag2tS6Hf+YBEcjBCT2n4amq0wITr6aPCGT/OZBm717Uv X-Google-Smtp-Source: ABdhPJw0SFzEDHJjA2F6R2BMschlkXZ3lIkbJV3ZuxRdlaIUQNfGR7cf1b5eecobKQgMY4JuWSI/SKmUcRlmtF8k2QU= X-Received: by 2002:a1f:bf85:: with SMTP id p127mr48670398vkf.70.1594628906100; Mon, 13 Jul 2020 01:28:26 -0700 (PDT) MIME-Version: 1.0 References: <159462824437.20882.7289165136459426376@ietfa.amsl.com> In-Reply-To: <159462824437.20882.7289165136459426376@ietfa.amsl.com> From: Cigdem Sengul Date: Mon, 13 Jul 2020 09:28:16 +0100 Message-ID: To: Ace Wg Content-Type: multipart/alternative; boundary="0000000000007f29be05aa4e79cd" Archived-At: Subject: Re: [Ace] I-D Action: draft-ietf-ace-mqtt-tls-profile-06.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, 13 Jul 2020 08:28:29 -0000 --0000000000007f29be05aa4e79cd Content-Type: text/plain; charset="UTF-8" Hello, I've submitted a new version in preparation for the next meeting. This version implements the change from the originally proposed scope format to AIF. There are 1-2 issues outstanding (regarding session continuation), which will be discussed in the WG meeting. Thanks, --Cigdem On Mon, Jul 13, 2020 at 9:18 AM 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 : MQTT-TLS profile of ACE > Authors : Cigdem Sengul > Anthony Kirby > Paul Fremantle > Filename : draft-ietf-ace-mqtt-tls-profile-06.txt > Pages : 30 > Date : 2020-07-13 > > Abstract: > This document specifies a profile for the ACE (Authentication and > Authorization for Constrained Environments) framework to enable > authorization in an Message Queuing Telemetry Transport (MQTT)-based > publish-subscribe messaging system. Proof-of-possession keys, bound > to OAuth2.0 access tokens, are used to authenticate and authorize > MQTT Clients. The protocol relies on TLS for confidentiality and > MQTT server (broker) authentication. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ace-mqtt-tls-profile/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ace-mqtt-tls-profile-06 > https://datatracker.ietf.org/doc/html/draft-ietf-ace-mqtt-tls-profile-06 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-mqtt-tls-profile-06 > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --0000000000007f29be05aa4e79cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I've submit= ted a new version in preparation for the next meeting.=C2=A0
This= version implements the change from the originally proposed scope format to= AIF.=C2=A0
There are 1-2 issues outstanding (regarding session c= ontinuation), which will be discussed in the WG meeting.=C2=A0
Thanks,=C2=A0
--Cigdem=C2=A0

On Mon, Jul 13, 20= 20 at 9:18 AM <internet-draf= ts@ietf.org> wrote:

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.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= MQTT-TLS profile of ACE
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Cigd= em Sengul
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Anthony Kirby
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Paul Fremantle
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ace-mqtt-tls-profile-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 30
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-07-13

Abstract:
=C2=A0 =C2=A0This document specifies a profile for the ACE (Authentication = and
=C2=A0 =C2=A0Authorization for Constrained Environments) framework to enabl= e
=C2=A0 =C2=A0authorization in an Message Queuing Telemetry Transport (MQTT)= -based
=C2=A0 =C2=A0publish-subscribe messaging system.=C2=A0 Proof-of-possession = keys, bound
=C2=A0 =C2=A0to OAuth2.0 access tokens, are used to authenticate and author= ize
=C2=A0 =C2=A0MQTT Clients.=C2=A0 The protocol relies on TLS for confidentia= lity and
=C2=A0 =C2=A0MQTT server (broker) authentication.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-ietf-ace-mqtt-tls-profile/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf= -ace-mqtt-tls-profile-06
https://datatracker.ietf.org= /doc/html/draft-ietf-ace-mqtt-tls-profile-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-ace-mqtt-tls-profile-06


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
--0000000000007f29be05aa4e79cd-- From nobody Mon Jul 13 08:12: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 A7F703A132D for ; Mon, 13 Jul 2020 08:12:47 -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 mLidR5tduoNk for ; Mon, 13 Jul 2020 08:12:45 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17413A133C for ; Mon, 13 Jul 2020 08:12:34 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 7E4284000F for ; Mon, 13 Jul 2020 17:12:32 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 901A7AB for ; Mon, 13 Jul 2020 17:12:31 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [91.112.68.252]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 48FC264 for ; Mon, 13 Jul 2020 17:12:31 +0200 (CEST) Received: (nullmailer pid 1135105 invoked by uid 1000); Mon, 13 Jul 2020 15:12:26 -0000 Date: Mon, 13 Jul 2020 17:12:26 +0200 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: ace@ietf.org Message-ID: <20200713151226.GA1047142@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline Archived-At: Subject: [Ace] 4.01 Get A Token From There, discovery-/form-driven applications and tokens opaque to the client 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, 13 Jul 2020 15:12:48 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello ACE, piecing together parts of the big picture of Resource Directory, CoRAL forms and ACE, I was wondering where in the whole story the client should tie its intention to the key material it uses to authorize an action. Take this -- admittedly contrived, but hopefully illustrative example: * We have a device (C) inside example.com that coordinates a lot of actions (and thus has a good standing with the AS and gets almost all the tokens it asks for. * The device would ike to register its management interface with the RD. * A malicious attacker intercepts the discovery process, and tells C that there is an RD at `;rt=3Dcore.rd` (which is a perfectly legitimate service we're running there for commercial purposes; its interface is that you submit POST a link there in link-format, and then it ties up the link target with endless requests). * The device tries to register to the local RD by POSTing some data there, but as it has no token to the attack server, it receives a 4.01 Unauthorized Get your token from coap://as.example.com, scope launch-attack, audience attack.example.com * The client takes those pieces to the AS, which grants it a token (after all, C would be authorized to launch an attack, given it's known to be a coordinator -- it just doesn't mean to). * C sends the token to the RS attack, and sends its POST again, with th link to its own management interface. * The attack server brings C to a grinding halt, because it was tricked to shoot its own foot. (Admittedly it's good practice for foot- and other guns to not just silently ignore query parameters like ep=3Dthe-coordinator<=3D3600, but A) other interfaces may be more accidentally-compatible, and B) CoRAL forms would widen the range of craftable requests enormously). My question here is: Where did this go wrong? Should C have verified with attack.example.com that it really has the resource type core.rd? Should it have understood the scope of the action? Should it have a different security association with the AS for every action it asks tokens for? And does the answer still hold if it has already obtained a token to launch attacks (but just didn't notice that the RD it was sent to happens to have the very URI its attack forces use)? Kind regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl8MedYACgkQOY0REtOk veE+wQ/+JkEziUzxl6XqZ1mfWJRzdmD9Qn7tT0OxmI9NpGaO2otClheAbdySJOIU UAFFJ796CvWCFhvhLmRF3xYm4JeOLG0h9Xpnm1DDrmAEF6eXfA3aBaugXuEDAiEq 7gENXImT4IRpe1EzItXQQsz0E9oINbB2G66rulevOqYoZBmHqiq+/Fd/jNy9p4z8 DBfg3QJacihVxDueIM4J6YK1aN661RsCKYOKTz9uk5x8cQqh2jw2GEeIP9vPw/V7 GyCVa1qiZcehszcs9M/cx3vPdlOEIUuzd1ycINLCBPxkVheh58AR3BFQ35RBjHg5 aeVLYcwl5jlx+Kth8AB7k9PzqFcs7lCwlLn9q6ZgXvPBHvKhWPy/l+j3NtTNXUMc LdtKx4LaRwVk9FY+URkLv7lzifSM28xD3LWDMr0MywZDS+Z3SWjlse0XqpDxPm6o g0PAKTqdKUOhVld0a8z6AME5GspIngSP9ynddFMJModb8Y+Ml5tEOaDX4jUkWWq3 ltlBvc0bl1/w8n6hUDAHQCl9V+q+6XrWhlVDeIkcETOBii4AAzeWlrPux3UO6CH8 BVfNbpUMtBCK+ccIQ2cJdNjqI/AvzvLFiX2r9ZijAD9NRU327l0XD071zFUk+ZxG n+j82QBP03TsUcDK06E2AG4OGvunUfXzaiTTMKtJetr7MtbDOXA= =+0Sx -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- From nobody Mon Jul 13 09:09: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 6CCC13A1408 for ; Mon, 13 Jul 2020 09:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.022 X-Spam-Level: X-Spam-Status: No, score=-0.022 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 m_JlUr8N97Fq for ; Mon, 13 Jul 2020 09:09:03 -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 5144D3A13FB for ; Mon, 13 Jul 2020 09:09:02 -0700 (PDT) Received: from [192.168.0.57] (p54bded4c.dip0.t-ipconnect.de [84.189.237.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4B57qw6CP4zySN; Mon, 13 Jul 2020 18:09:00 +0200 (CEST) To: =?UTF-8?Q?Christian_Ams=c3=bcss?= , ace@ietf.org References: <20200713151226.GA1047142@hephaistos.amsuess.com> From: Stefanie Gerdes Message-ID: Date: Mon, 13 Jul 2020 18:08:53 +0200 User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20200713151226.GA1047142@hephaistos.amsuess.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ace] 4.01 Get A Token From There, discovery-/form-driven applications and tokens opaque to the client 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, 13 Jul 2020 16:09:05 -0000 Hi Christian, On 07/13/2020 05:12 PM, Christian Amsüss wrote: > > * A malicious attacker intercepts the discovery process, and tells C > that there is an RD at > `;rt=core.rd` > (which is a perfectly legitimate service we're running there for > commercial purposes; its interface is that you submit POST a link > there in link-format, and then it ties up the link target with endless > requests). I would say that C would need to ascertain that C's owner allowed C to communicate with this RD. Viele Gruesse Steffi From nobody Mon Jul 13 10:00:48 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 A82683A159F; Mon, 13 Jul 2020 10:00:46 -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.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159465964665.25041.14840339928200580815@ietfa.amsl.com> Date: Mon, 13 Jul 2020 10:00:46 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-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, 13 Jul 2020 17:00:47 -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-08.txt Pages : 58 Date : 2020-07-13 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. Discussion Venues This note is to be removed before publishing as an RFC. Source for this draft and an issue tracker can be found at https://github.com/ace-wg/ace-key-groupcomm. 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-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 Jul 13 10:27:10 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 BD5953A15D8; Mon, 13 Jul 2020 10:27:05 -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.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159466122573.850.29426382161353057@ietfa.amsl.com> Date: Mon, 13 Jul 2020 10:27:05 -0700 Archived-At: Subject: [Ace] I-D Action: draft-tiloca-ace-oscore-gm-admin-02.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, 13 Jul 2020 17:27:06 -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 : Admin Interface for the OSCORE Group Manager Authors : Marco Tiloca Rikard Hoeglund Peter van der Stok Francesca Palombini Klaus Hartke Filename : draft-tiloca-ace-oscore-gm-admin-02.txt Pages : 29 Date : 2020-07-13 Abstract: Group communication for CoAP can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible to handle the joining of new group members, as well as to manage and distribute the group key material. This document defines a RESTful admin interface at the Group Manager, that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of-possession and server authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-tiloca-ace-oscore-gm-admin/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-tiloca-ace-oscore-gm-admin-02 https://datatracker.ietf.org/doc/html/draft-tiloca-ace-oscore-gm-admin-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-tiloca-ace-oscore-gm-admin-02 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 Jul 13 11:11:02 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 79ED53A173C; Mon, 13 Jul 2020 11:10:56 -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.8.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159466385644.1589.16997782156088779952@ietfa.amsl.com> Date: Mon, 13 Jul 2020 11:10:56 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-key-groupcomm-oscore-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, 13 Jul 2020 18:11:01 -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-08.txt Pages : 50 Date : 2020-07-13 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-08 https://datatracker.ietf.org/doc/html/draft-ietf-ace-key-groupcomm-oscore-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-key-groupcomm-oscore-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 Jul 13 11:34:30 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 00FE93A16D6; Mon, 13 Jul 2020 11:34: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 gLz46SdP7BPb; Mon, 13 Jul 2020 11:34: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 A84593A0775; Mon, 13 Jul 2020 11:34: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; Mon, 13 Jul 2020 11:34:22 -0700 From: Jim Schaad To: CC: Date: Mon, 13 Jul 2020 11:34:19 -0700 Message-ID: <000501d65944$3a527920$aef76b60$@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: AdZZQ8/IFmwOFA6XT0OlGy09AcRHsg== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Agenda for IETF 108 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, 13 Jul 2020 18:34:29 -0000 We are collecting agenda items for IETF 108. We have a 100 minute slot at the meeting and I am sure that it will be overflowing. If you want to be on the agenda please let the chairs know. Please include the following data in your agenda request: 1. The document(s) that the presentation applies to 2. Who is giving the presentation 3. How long do you expect the presentation to take. 4. Are there any ordering issues that need to be noted. Jim & Daniel From nobody Mon Jul 13 15:06: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 E2B933A0F97; Mon, 13 Jul 2020 15:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 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, T_SPF_TEMPERROR=0.01, 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 KNs3zJ5ZISFh; Mon, 13 Jul 2020 15:06:29 -0700 (PDT) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 C40183A0F28; Mon, 13 Jul 2020 15:06:15 -0700 (PDT) Received: by mail-io1-xd34.google.com with SMTP id i4so15177819iov.11; Mon, 13 Jul 2020 15:06:15 -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=Kjka8CMKATro5Q8U9NTyKFn8XrGTUrQn9GE9Y3CiFqI=; b=Wz4hwTTB9TDGCqs7q31q753YmIvPKbW0lcoswL9N58iLP89pBKI1XWZs5SomJ07pN0 giEOkIHzQ7izbNGEldg0bVXQAEekldTZn6j0kiabVg43beCvBebMsNdKbxwKAkKk+rvR APIFRGnfK41DEHz/bQ/VbytSZyCgPdYK1HaC4d81gBPtl7he5pyFj0k2padvGrfykZbt Y5HLu5BXCNG5WmjritaddRx99DNNRnrxQ2RnPbxZX6nKJAHkW7ENLA1YWphq7og9wHzq gQ7hnc+R8PynE7WMJzQcvShcXakHwlcMlrVzz4OtyQM48v52xEvOD7XgleWulN8UuFLa /keQ== 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=Kjka8CMKATro5Q8U9NTyKFn8XrGTUrQn9GE9Y3CiFqI=; b=f3mWtEijrbdEkqBXotEnEhOj5T3VxO8uaUtveSvxoWu0Gup6Im8T9lY07MtS126DR1 l7/na6JOLQd3LEVCxOio6BHQtxheg6Bs9icVkZF3v61E1EU12LG3hUeL8PM55+oou/Y1 3lQEYdLjkxjej3RySWbqOI8+XPCDpvR31vAbaIRlS8+E+f57xM1K7plXX4tjaQ8ybLws D7QCVDdcO0peZLi2K8VlF7VqYxKYhhROaK3tqb2boUdmWahAIUr//cmY9kLKwGw4fHv2 P9c3yqhUQmVu4RbdAng+FOQCdCTE7Mp6p40EPUVyUZb+CABCdE2jgV0gle6uPTa8aXio lcpg== X-Gm-Message-State: AOAM532FbjFadi4dbMRDd3Dfp5ZBOSdaTNKOIET02eAgjArOtPZ2RUoH TqtoP9tISprNcVgGnzkLi8Oz8PmR27GkHVbzBRA= X-Google-Smtp-Source: ABdhPJzi0kwmwabLDCmkkc2tWEhKsIJRKpSu0IgY1p0RtUSzriD5PZVcsNWmDWcQoTFJsz8TQTBj5OE8c7p45axYzSM= X-Received: by 2002:a02:a008:: with SMTP id a8mr2397227jah.68.1594677974010; Mon, 13 Jul 2020 15:06:14 -0700 (PDT) MIME-Version: 1.0 References: <1978e1d6-ae62-1b85-1e70-062aee0fcc89@primekey.se> <000101d63ba8$d9cd4020$8d67c060$@augustcellars.com> In-Reply-To: From: Mohit Sahni Date: Mon, 13 Jul 2020 15:06:03 -0700 Message-ID: To: Jim Schaad Cc: LAMPS WG , ace@ietf.org, "Brockhaus, Hendrik" Content-Type: multipart/alternative; boundary="0000000000002c129605aa59e666" Archived-At: Subject: Re: [Ace] [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport 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, 13 Jul 2020 22:06:39 -0000 --0000000000002c129605aa59e666 Content-Type: text/plain; charset="UTF-8" Hi All I have published the first draft for the document here is the link to the draft https://datatracker.ietf.org/doc/draft-msahni-ace-cmpv2-coap-transport/ . As Jim mentioned that adopting this might need change in the ACE WG charter can we please discuss that in IETF 108 ? Thanks Mohit On Sat, Jun 6, 2020 at 10:01 AM Mohit Sahni wrote: > Hi Jim, > Thanks for the feedback. I will go over the EST document and update > sections around DTLS and proxying and address your other comments. Once > ready, I will post the draft in ACE WG. > > Regards, > Mohit > > > On Fri, Jun 5, 2020 at 7:19 PM Jim Schaad wrote: > >> I suppose that this could go into the ACE working group, but it will >> require a charter change to do so. >> >> >> >> I would suggest that you review the EST document with special attention >> to the sections on DTLS and proxying. It would also help to have some idea >> of guidance for when coap or coaps is going to be used. I am not sure that >> this strongly exists in CMP as my very vague memory was that it was assumed >> that all transactions where going to be done over TLS with server >> validation as a minimum. >> >> >> >> Jim >> >> >> >> >> >> *From:* Spasm *On Behalf Of *Mohit Sahni >> *Sent:* Thursday, June 4, 2020 10:49 PM >> *To:* Tomas Gustavsson >> *Cc:* LAMPS WG >> *Subject:* Re: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport >> >> >> >> Hi Tomas >> >> Thanks for the feedback, I was trying to write it in a way so that it can >> work for both CMPv2 and LightWeight CMP, I have noted it your feedback and >> I will try to make it more clear. >> >> >> >> -Mohit >> >> >> >> On Thu, Jun 4, 2020 at 10:40 PM Tomas Gustavsson > > wrote: >> >> Hi, >> >> I noticed that section 4, Proxy Support (good section btw), mentions >> Announcement messages. These are excluded from the Lightweight >> specification. Since the LIghtweight specification is mentioned in the >> beginning, I'm not sure if that's worth mentioning here? >> >> Cheers, >> Tomas >> >> On 2020-06-04 20:03, Mohit Sahni wrote: >> > Hi Jim, >> > There were some discussions about using CoAP as transport for the >> > Lightweight CMP profile in the last LAMPS WG meeting. After having some >> > discussions with Hendrik, David, and Andreas I have written an >> > internet-draft for using CoAP as transport for CMPv2 / Light Weight CMP >> > Profile. If I am not mistaken, the recommendation was to present this >> > draft to ACE WG for the review instead of Lamps group, can you please >> > advice on that? >> > >> > Here is the link to the internet-draft that I wrote >> > https://www.ietf.org/id/draft-msahni-tbd-cmpv2-coap-transport-00.txt >> > >> > Thanks >> > Mohit >> > >> > _______________________________________________ >> > Spasm mailing list >> > Spasm@ietf.org >> > https://www.ietf.org/mailman/listinfo/spasm >> > >> >> _______________________________________________ >> Spasm mailing list >> Spasm@ietf.org >> https://www.ietf.org/mailman/listinfo/spasm >> >> --0000000000002c129605aa59e666 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All
I have published the first dra= ft for the document here is the link to the draft=C2=A0https://dat= atracker.ietf.org/doc/draft-msahni-ace-cmpv2-coap-transport/=C2=A0. As = Jim mentioned that adopting=C2=A0this might need change in the ACE WG chart= er can we please discuss that in IETF 108 ?

Thanks=
Mohit=C2=A0

On Sat, Jun 6, 2020 at 10:01 AM = Mohit Sahni <mohit06jan@gmail.co= m> wrote:
Hi Jim,
Thanks for the feedback. I will go over= the EST document and update sections around DTLS and proxying and address = your other comments. Once ready, I will post the draft in ACE WG.
=
Regards,
Mohit=C2=A0


On Fri, Jun 5, 2020 at 7:19 PM Jim Schaad <ietf@augustcellars.com> wrote:
<= div>

I suppose that this could go into the ACE workin= g group, but it will require a charter change to do so.=C2=A0

=C2=A0

= I would suggest that you review the EST document with special attention to = the sections on DTLS and proxying.=C2=A0 It would also help to have some id= ea of guidance for when coap or coaps is going to be used.=C2=A0 I am not s= ure that this strongly exists in CMP as my very vague memory was that it wa= s assumed that all transactions where going to be done over TLS with server= validation as a minimum.

= =C2=A0

Jim

=C2=A0

=C2=A0

From: Spasm <spasm-bounces@ietf.org> On Behalf Of Mohit Sahni=
Sent: Thursday, June 4, 2020 10:49 PM
To: Tomas Gustav= sson <tomas@prime= key.se>
Cc: LAMPS WG <spasm@ietf.org>
Subject: Re: [lamps] CM= Pv2/LightWeiight-CMP profile over CoAP transport

=C2=A0

Hi= =C2=A0Tomas

Thanks for the fee= dback, I was trying=C2=A0to write it in a way so that it can work for both = CMPv2 and LightWeight CMP, I have noted it your=C2=A0feedback and I will tr= y to make it more clear.

=C2=A0

-Mohit=C2=A0<= /u>

=C2=A0

On Thu, Jun 4, 2020 at 10:40 PM Tomas Gustav= sson <tomas@prime= key..se> wrote:

Hi,

I noticed that section 4, Proxy Support (good s= ection btw), mentions
Announcement messages. These are excluded from the= Lightweight
specification. Since the LIghtweight specification is menti= oned in the
beginning, I'm not sure if that's worth mentioning h= ere?

Cheers,
Tomas

On 2020-06-04 20:03, Mohit Sahni wrote:=
> Hi Jim,
> There were some discussions about using CoAP as tr= ansport for the
> Lightweight CMP profile in the last LAMPS WG meetin= g. After having some
> discussions with Hendrik, David, and=C2=A0Andr= eas I have written an
> internet-draft for using CoAP as transport fo= r CMPv2 / Light Weight CMP
> Profile. If I am not=C2=A0mistaken, the= =C2=A0recommendation was to present this
> draft to ACE WG for the re= view instead of Lamps group, can you please
> advice on that?
>=
> Here is the link to the internet-draft that I wrote
> https://www.ietf.org/id/draft-msahni-tbd-cmpv2-coap-tran= sport-00.txt=C2=A0
>
> Thanks
> Mohit=C2=A0=C2=A0>
> _______________________________________________
> Spas= m mailing list
> = Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm>

_______________________________________________
Spasm mai= ling list
Spasm@ietf= .org
https://www.ietf.org/mailman/listinfo/spasm

--0000000000002c129605aa59e666-- From nobody Mon Jul 13 22:54:25 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 A35F33A10E8; Mon, 13 Jul 2020 22:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=siemens.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txbsi_uovHrl; Mon, 13 Jul 2020 22:53:59 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2045.outbound.protection.outlook.com [40.107.20.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 5E34A3A10E7; Mon, 13 Jul 2020 22:53:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Bip6AtsySOpFZ8kqdrkydnNlXoZUJAYD4VWmDzur8cX/QMp3LPR5K6iD9LToYKBiAOdZm3ep5IqPji2StrJLF852HN0rOCfqPtneHTvPR1HTUznV5hifhe4fjlPO6R1io1u9D2Byqcs3mlku/33lBlQ8t2ZHRRLT3eC2WEObFsCZMtOgbnwpW51ZpoBc+9fu6Z19ZegvipvGXAOT3vk0ontHmlDfViPoUQe5BZcvciThbQtyQBjiAVHgq9oG2QUp0tV7VFAhHAoqogaOD7jwYegsOq6PrDKao7ZGpyw+2sFawhr2wh6JuIcJETJVyC52+qpFUVB9b1rdEPhjKVRLpw== 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=n/h1JZ+pzd94bbMFu/sw4q0kbse6IBxxSHGWsW+jKzI=; b=ZaK9pUhSbQT2e8stE7Kk/1op/fxqh1bOkU0xuW3KZHizDpk/gIcR7vz3NIuVXgvJkJKrBCE0O5RVmkRGLWZIhmVf++N1si+5lxOZA0nfZbHq0nuw1tD7PvzVdA6R/NjoIKa4p9N3epPTrev6q7nhKhPIXrHyO6CxWZ1TihdSC/SIAcZzxJKi2i0Zo2Ov/ca3Yjj7MS8bQjBvLJY+4Wm4LYLPHMpR3vrA7Qb3b48V2g/lzpu3xAmPnW+fCMczPR18IOGH46/NQ5XWzL1V9GkBqFhPPJ76pwT7JfuuW/+ngGsntaxemgYtAW9QGJSEz2xWwNFYEWBBKxJnUHalEHI7cw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n/h1JZ+pzd94bbMFu/sw4q0kbse6IBxxSHGWsW+jKzI=; b=M1RokqOLvsVXHSy5LzdwUonJJ6XTIhxpf7Z9Xi9C6mq7bi34f6S/09jONRCdsIIlEpGPDHg0dqyIPh855iejdXEcHeaP1q6cBV4OmhP670RD23VSXQxFVkTusEzmADZv9OK2kIwLiM9XAwCYZCOh59eGA3qYbUFsvu/5s1lstWM= Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:184::10) by AM0PR10MB2931.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:160::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21; Tue, 14 Jul 2020 05:53:57 +0000 Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::c5d3:8347:4ebd:93da]) by AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::c5d3:8347:4ebd:93da%3]) with mapi id 15.20.3174.026; Tue, 14 Jul 2020 05:53:57 +0000 From: "Brockhaus, Hendrik" To: Mohit Sahni , Jim Schaad CC: LAMPS WG , "ace@ietf.org" Thread-Topic: [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport Thread-Index: AQHWOpqMTaopCwilUkGOk9vnrw2MI6jJgmkAgAACSACAAVfKAIAA9m0AgDp7e4CAAIG8UA== Date: Tue, 14 Jul 2020 05:53:57 +0000 Message-ID: References: <1978e1d6-ae62-1b85-1e70-062aee0fcc89@primekey.se> <000101d63ba8$d9cd4020$8d67c060$@augustcellars.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.178] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 73310bb0-af22-4d8b-ebe7-08d827ba4c6f x-ms-traffictypediagnostic: AM0PR10MB2931: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: m5jF4NKPB3DnJfU6sdJ0B3/W2RUJ61D5SISskW2pcHOG7NQSlRe4MI7jReHUHXBrYD4k3TbuMwuf5s+mAFdxTeaP6/dO1/5JKKIHiuiXeIKrBoo52zYsbHisZLSyTqyeuvm/Grmq0NBCtnBepsxeICd4Bc5GwkbXYV8MMHXLzEH2QY0FWxRt+Ui3OQ4W4qsYNPq18lHpgWXYzoJyPqnS8wa+9vFoRhISD6suxaQE54OmgCYhYzt02D7DWtzAYyaT8gremb1UHTddEAN30WUj4RKHoontoV8Jic4exC+jcdeEkFHRmmQFXiebHZRl9ybuhx3kgeQNAjDCJFTix9QnzOs6g0jtp43vy9vGGh+2R+9UP7uaoxiOYiv6UTjAK0mho5r9tIHphLIW1mr+1tMWqA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(136003)(366004)(396003)(376002)(26005)(186003)(66946007)(66476007)(4326008)(64756008)(966005)(76116006)(19627235002)(66556008)(66446008)(7696005)(86362001)(316002)(6506007)(110136005)(53546011)(54906003)(55236004)(2906002)(83380400001)(8676002)(8936002)(9686003)(55016002)(33656002)(66574015)(45080400002)(71200400001)(478600001)(5660300002)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: PMBYUcI76eBwB5zcZmWt4b1XFNkIlX0mwJWnX2XfYqEZDJcEri3iJgFzhv8l7FReLIUXB4YeRKR67jKkpttMaHdQTjnftKHRlwDsEThDhcuNKf80p/pZSPEN2XYn1gNeQMpJ7qtdcvZTUN5FRbsOSaglVSjkPI4Sa7zSEGpMEOjHuqh5R/KbCt/SqyUcVLmbAcbOgtW3OEBDGNaA2PgYsX2c44eXnGkfJKgnZAOupm0kgYkS6KBSubF4BlMQvqAEvYWjgVTcRu6qgxnGXqJVr9EWyrOCAJXiaE0ZbZoTLVMeeiE0BUjj6s6Z2Mt58NZG+sMWqOAGudeDlxYOsBa4vfS0c9N6GQlyeU2Ul2JIn1zO/AHEAucwf3Iof1vls2dx1vphhFNNMlFAm7zuDhKv5gKrj00diwb/UpolWJVlbDZy73njtN/zyE5LFA84LPt0L+vCtxKEYkbAG+9BF562DKXZddPSfZgsf9X5Q3VlSeICLMCqpkEd0FU+DvGV6eQz x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 73310bb0-af22-4d8b-ebe7-08d827ba4c6f X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2020 05:53:57.2260 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dFT8SPeV5LiICKSEpgXoimgrN1+uaTbGGPoaphW9tC8XuIG3SM9x8fDATl00kLU3ylEB4FLyHl6CMTOKtg7znSqms++yuUbIHhzA8JSNarU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2931 Archived-At: Subject: Re: [Ace] [lamps] CMPv2/LightWeiight-CMP profile over CoAP transport 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, 14 Jul 2020 05:54:02 -0000 TW9oaXQNClRoYW5rcyBmb3IgdGhlIHVwZGF0ZS4gSSdtIGxvb2tpbmcgZm9yd2FyZCB0byB0aGUg ZGlzY3Vzc2lvbiBpbiBBQ0UuDQoNCkhlbmRyaWsNCg0KVm9uOiBNb2hpdCBTYWhuaSA8bW9oaXQw NmphbkBnbWFpbC5jb20+IA0KR2VzZW5kZXQ6IERpZW5zdGFnLCAxNC4gSnVsaSAyMDIwIDAwOjA2 DQoNCkhpIEFsbA0KSSBoYXZlIHB1Ymxpc2hlZCB0aGUgZmlyc3QgZHJhZnQgZm9yIHRoZSBkb2N1 bWVudCBoZXJlIGlzIHRoZSBsaW5rIHRvIHRoZSBkcmFmdCBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1tc2FobmktYWNlLWNtcHYyLWNvYXAtdHJhbnNwb3J0Ly4gQXMgSmlt IG1lbnRpb25lZCB0aGF0IGFkb3B0aW5nwqB0aGlzIG1pZ2h0IG5lZWQgY2hhbmdlIGluIHRoZSBB Q0UgV0cgY2hhcnRlciBjYW4gd2UgcGxlYXNlIGRpc2N1c3MgdGhhdCBpbiBJRVRGIDEwOCA/DQoN ClRoYW5rcw0KTW9oaXTCoA0KDQpPbiBTYXQsIEp1biA2LCAyMDIwIGF0IDEwOjAxIEFNIE1vaGl0 IFNhaG5pIDxtYWlsdG86bW9oaXQwNmphbkBnbWFpbC5jb20+IHdyb3RlOg0KSGkgSmltLA0KVGhh bmtzIGZvciB0aGUgZmVlZGJhY2suIEkgd2lsbCBnbyBvdmVyIHRoZSBFU1QgZG9jdW1lbnQgYW5k IHVwZGF0ZSBzZWN0aW9ucyBhcm91bmQgRFRMUyBhbmQgcHJveHlpbmcgYW5kIGFkZHJlc3MgeW91 ciBvdGhlciBjb21tZW50cy4gT25jZSByZWFkeSwgSSB3aWxsIHBvc3QgdGhlIGRyYWZ0IGluIEFD RSBXRy4NCg0KUmVnYXJkcywNCk1vaGl0wqANCg0KDQpPbiBGcmksIEp1biA1LCAyMDIwIGF0IDc6 MTkgUE0gSmltIFNjaGFhZCA8bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20+IHdyb3RlOg0K SSBzdXBwb3NlIHRoYXQgdGhpcyBjb3VsZCBnbyBpbnRvIHRoZSBBQ0Ugd29ya2luZyBncm91cCwg YnV0IGl0IHdpbGwgcmVxdWlyZSBhIGNoYXJ0ZXIgY2hhbmdlIHRvIGRvIHNvLsKgIA0KwqANCkkg d291bGQgc3VnZ2VzdCB0aGF0IHlvdSByZXZpZXcgdGhlIEVTVCBkb2N1bWVudCB3aXRoIHNwZWNp YWwgYXR0ZW50aW9uIHRvIHRoZSBzZWN0aW9ucyBvbiBEVExTIGFuZCBwcm94eWluZy7CoCBJdCB3 b3VsZCBhbHNvIGhlbHAgdG8gaGF2ZSBzb21lIGlkZWEgb2YgZ3VpZGFuY2UgZm9yIHdoZW4gY29h cCBvciBjb2FwcyBpcyBnb2luZyB0byBiZSB1c2VkLsKgIEkgYW0gbm90IHN1cmUgdGhhdCB0aGlz IHN0cm9uZ2x5IGV4aXN0cyBpbiBDTVAgYXMgbXkgdmVyeSB2YWd1ZSBtZW1vcnkgd2FzIHRoYXQg aXQgd2FzIGFzc3VtZWQgdGhhdCBhbGwgdHJhbnNhY3Rpb25zIHdoZXJlIGdvaW5nIHRvIGJlIGRv bmUgb3ZlciBUTFMgd2l0aCBzZXJ2ZXIgdmFsaWRhdGlvbiBhcyBhIG1pbmltdW0uDQrCoA0KSmlt DQrCoA0KwqANCkZyb206IFNwYXNtIDxtYWlsdG86c3Bhc20tYm91bmNlc0BpZXRmLm9yZz4gT24g QmVoYWxmIE9mIE1vaGl0IFNhaG5pDQpTZW50OiBUaHVyc2RheSwgSnVuZSA0LCAyMDIwIDEwOjQ5 IFBNDQpUbzogVG9tYXMgR3VzdGF2c3NvbiA8bWFpbHRvOnRvbWFzQHByaW1la2V5LnNlPg0KQ2M6 IExBTVBTIFdHIDxtYWlsdG86c3Bhc21AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2xhbXBzXSBD TVB2Mi9MaWdodFdlaWlnaHQtQ01QIHByb2ZpbGUgb3ZlciBDb0FQIHRyYW5zcG9ydA0KwqANCkhp wqBUb21hcw0KVGhhbmtzIGZvciB0aGUgZmVlZGJhY2ssIEkgd2FzIHRyeWluZ8KgdG8gd3JpdGUg aXQgaW4gYSB3YXkgc28gdGhhdCBpdCBjYW4gd29yayBmb3IgYm90aCBDTVB2MiBhbmQgTGlnaHRX ZWlnaHQgQ01QLCBJIGhhdmUgbm90ZWQgaXQgeW91csKgZmVlZGJhY2sgYW5kIEkgd2lsbCB0cnkg dG8gbWFrZSBpdCBtb3JlIGNsZWFyLg0KwqANCi1Nb2hpdMKgDQrCoA0KT24gVGh1LCBKdW4gNCwg MjAyMCBhdCAxMDo0MCBQTSBUb21hcyBHdXN0YXZzc29uIDxtYWlsdG86dG9tYXNAcHJpbWVrZXku c2U+IHdyb3RlOg0KSGksDQoNCkkgbm90aWNlZCB0aGF0IHNlY3Rpb24gNCwgUHJveHkgU3VwcG9y dCAoZ29vZCBzZWN0aW9uIGJ0dyksIG1lbnRpb25zDQpBbm5vdW5jZW1lbnQgbWVzc2FnZXMuIFRo ZXNlIGFyZSBleGNsdWRlZCBmcm9tIHRoZSBMaWdodHdlaWdodA0Kc3BlY2lmaWNhdGlvbi4gU2lu Y2UgdGhlIExJZ2h0d2VpZ2h0IHNwZWNpZmljYXRpb24gaXMgbWVudGlvbmVkIGluIHRoZQ0KYmVn aW5uaW5nLCBJJ20gbm90IHN1cmUgaWYgdGhhdCdzIHdvcnRoIG1lbnRpb25pbmcgaGVyZT8NCg0K Q2hlZXJzLA0KVG9tYXMNCg0KT24gMjAyMC0wNi0wNCAyMDowMywgTW9oaXQgU2Fobmkgd3JvdGU6 DQo+IEhpIEppbSwNCj4gVGhlcmUgd2VyZSBzb21lIGRpc2N1c3Npb25zIGFib3V0IHVzaW5nIENv QVAgYXMgdHJhbnNwb3J0IGZvciB0aGUNCj4gTGlnaHR3ZWlnaHQgQ01QIHByb2ZpbGUgaW4gdGhl IGxhc3QgTEFNUFMgV0cgbWVldGluZy4gQWZ0ZXIgaGF2aW5nIHNvbWUNCj4gZGlzY3Vzc2lvbnMg d2l0aCBIZW5kcmlrLCBEYXZpZCwgYW5kwqBBbmRyZWFzIEkgaGF2ZSB3cml0dGVuIGFuDQo+IGlu dGVybmV0LWRyYWZ0IGZvciB1c2luZyBDb0FQIGFzIHRyYW5zcG9ydCBmb3IgQ01QdjIgLyBMaWdo dCBXZWlnaHQgQ01QDQo+IFByb2ZpbGUuIElmIEkgYW0gbm90wqBtaXN0YWtlbiwgdGhlwqByZWNv bW1lbmRhdGlvbiB3YXMgdG8gcHJlc2VudCB0aGlzDQo+IGRyYWZ0IHRvIEFDRSBXRyBmb3IgdGhl IHJldmlldyBpbnN0ZWFkIG9mIExhbXBzIGdyb3VwLCBjYW4geW91IHBsZWFzZQ0KPiBhZHZpY2Ug b24gdGhhdD8NCj4gDQo+IEhlcmUgaXMgdGhlIGxpbmsgdG8gdGhlIGludGVybmV0LWRyYWZ0IHRo YXQgSSB3cm90ZQ0KPiBodHRwczovL2V1cjAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZpZCUyRmRyYWZ0LW1zYWhuaS10 YmQtY21wdjItY29hcC10cmFuc3BvcnQtMDAudHh0JmRhdGE9MDIlN0MwMSU3Q2hlbmRyaWsuYnJv Y2toYXVzJTQwc2llbWVucy5jb20lN0M3NTUzZDhhZjI2MDM0MzYwMzExMjA4ZDgyNzc4ZjZhMCU3 QzM4YWUzYmNkOTU3OTRmZDRhZGRhYjQyZTE0OTVkNTVhJTdDMSU3QzAlN0M2MzczMDI3NDc3Njk4 NzU1MTAmc2RhdGE9JTJCVWhUTUpqZ0g4SjNnVlZ5VmE4ZVlaZTBjTk84QUtaTks4QXhpNVJaQWdj JTNEJnJlc2VydmVkPTDCoA0KPiANCj4gVGhhbmtzDQo+IE1vaGl0wqDCoA0KPiANCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gU3Bhc20gbWFpbGlu ZyBsaXN0DQo+IG1haWx0bzpTcGFzbUBpZXRmLm9yZw0KPiBodHRwczovL2V1cjAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmcl MkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcGFzbSZkYXRhPTAyJTdDMDElN0NoZW5kcmlrLmJyb2Nr aGF1cyU0MHNpZW1lbnMuY29tJTdDNzU1M2Q4YWYyNjAzNDM2MDMxMTIwOGQ4Mjc3OGY2YTAlN0Mz OGFlM2JjZDk1Nzk0ZmQ0YWRkYWI0MmUxNDk1ZDU1YSU3QzElN0MwJTdDNjM3MzAyNzQ3NzY5ODg1 NDY3JnNkYXRhPVNCREphNlA3JTJGZDVPU1E0d25kOG8lMkZ1TzJQSmc1ZXNZblh0S21IbEJjVGFv JTNEJnJlc2VydmVkPTANCj4gDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpTcGFzbSBtYWlsaW5nIGxpc3QNCm1haWx0bzpTcGFzbUBpZXRmLm9yZw0K aHR0cHM6Ly9ldXIwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGc3Bhc20mZGF0YT0w MiU3QzAxJTdDaGVuZHJpay5icm9ja2hhdXMlNDBzaWVtZW5zLmNvbSU3Qzc1NTNkOGFmMjYwMzQz NjAzMTEyMDhkODI3NzhmNmEwJTdDMzhhZTNiY2Q5NTc5NGZkNGFkZGFiNDJlMTQ5NWQ1NWElN0Mx JTdDMCU3QzYzNzMwMjc0Nzc2OTg5MDQzNyZzZGF0YT1oNWlCdU0lMkJ4dWNqR05BRVN6b0FJUTI2 VG81NWl6ZWtsRmV1WUdVa1hZZmMlM0QmcmVzZXJ2ZWQ9MA0K From nobody Tue Jul 14 03:49: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 BA6853A09A3 for ; Tue, 14 Jul 2020 03:49:38 -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=ham 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 tWZ8s47JT0pe for ; Tue, 14 Jul 2020 03:49:35 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150057.outbound.protection.outlook.com [40.107.15.57]) (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 94AB13A099B for ; Tue, 14 Jul 2020 03:49:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KikZEGAl6pS6vs49PtvJRVX2dwLk8uyVpx/KFFQZP/x3flSXuffzE4H4Z/+yMcAKY01R6Z6A213Xfx5qyciOhDgEikF+SgxL9n8Djy8t/9/ANA+yCbgSNvLTjk+n+P0BV9VF/IfFRdoUK/uv7VzCNAahoO8SjWB1N3fyzjR1Dfen/qikc3m2wFBoe+R/zzahqy/ASo1Y6Nqx3uS3kkD14tPNDZ+dMgEFEtvSS+E98frQP15KEyLcfofMvP+Agye2OPXBwgMXyrT01njdQnUgGkpRsD0032fG1j8haIpkA9K62CTFp1XLTsPjuSfInwjEF98pNyR0QPL/TRNYsPOLrQ== 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=cffnkIqykWi/dbxHBlWzQt9HnQn6CANbVLEt31M2gxo=; b=Igl5r5MQZAbxmT6483FWM1QgiEYmaywphccOJiaZ9w0p5sGCbMu/Wl+mcK4MnvnO8UjacAfttO+PU9Dz0to3v/wUZJuDk82RuiYMaos1e02qVc3GqRM21PgVvKwSNyz+s8kmtAgsF5TfwEPoLT7IG0YmW8pNr9RbDMI/r+VTbsv7o/La5aMnD47SmCGFp5m0RQIaQQQZ4+FrDrKyAJ8CgTnTLJuovB61wwCgtvfhWtUpwaaI8Js2zh1FXCb0agYvyX7wmUpUZeGu9EYTI8gO74Smhb11jriVJuKj0vPuwyqMzS71z4tnImhURVbqsxCVTB6ITNh28nWQAUQ9+JzLyA== 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=cffnkIqykWi/dbxHBlWzQt9HnQn6CANbVLEt31M2gxo=; b=Ex/0J5/FqoqhyDDf9+dpY9SBPhXmrHeW20PSsZjs45bnto3h9JFSOxL2Dj+WT+E3ZWPaaT9ELphDOODVrriJyhYvVBqYplzPNw7bWbKGIyTVHzWtHvSQupFGfWLRTmJpBHIOovIN+QgnEfnB7b9HsHmPToB+Vr9ESYrGN2oKb2A= 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 VI1P18901MB0093.EURP189.PROD.OUTLOOK.COM (2603:10a6:801:e::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.22; Tue, 14 Jul 2020 10:49:32 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2%6]) with mapi id 15.20.3174.025; Tue, 14 Jul 2020 10:49:32 +0000 References: <159466103225.28477.14586704329355377501@ietfa.amsl.com> To: Ace Wg 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== X-Forwarded-Message-Id: <159466103225.28477.14586704329355377501@ietfa.amsl.com> Message-ID: Date: Tue, 14 Jul 2020 12:49:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <159466103225.28477.14586704329355377501@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="lqXzBYoGqGatvcHALZhEKEOWKJDU8VD7T" X-ClientProxiedBy: HE1PR0902CA0024.eurprd09.prod.outlook.com (2603:10a6:3:e5::34) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.9] (31.13.191.152) by HE1PR0902CA0024.eurprd09.prod.outlook.com (2603:10a6:3:e5::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.22 via Frontend Transport; Tue, 14 Jul 2020 10:49:31 +0000 X-Forwarded-Message-Id: <159466103225.28477.14586704329355377501@ietfa.amsl.com> X-Originating-IP: [31.13.191.152] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9c372f79-b78e-4bf3-14e7-08d827e39717 X-MS-TrafficTypeDiagnostic: VI1P18901MB0093: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2733; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IC9Ch7P84RJ9jV8EMLv68m3HY4vsz0iJ17bxT+oojV0TgQjdg/nQUVf4ksIX5nVrtGL+FixH48oTwNK54vCL3QdMB7Alvuyg5MdeBUrdmCSgvHYs5KiCD5j4y4K/mXoza/RRArhJr8BE1oyHucIE051OSIpDWI6xiuRuHyDzvRR7Oj7VQRGtsS0jyfrmy78Wr7CelCqBVx4RnND1/2HEa8hmLGDe7VdxNVGH3bSMBVLnqx88/b4zRBrnilQqsefr0vERBMr80XX71V0+U7bkag4+Itqbpf+vicGkZSpQSCfGTA213sLAtgkgC/XcMb6skeIbAWGlKmeNAr5eiJV2aoYY1taYJGpdeD6HxxFytR18u6bcA5gKrrjcwGz1E8hp8IUV+FH31AYN8uxRrC4mY/3rA5T46K/xWBQSNj5HBqucnNROFkFJ/GRF/RLBlyWM8AdDj/eucuPDPjrDHf5QGQ== 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)(396003)(39850400004)(366004)(346002)(376002)(136003)(52116002)(6486002)(2906002)(33964004)(316002)(21480400003)(86362001)(66574015)(2616005)(44832011)(31696002)(956004)(83380400001)(66556008)(15650500001)(186003)(66476007)(166002)(8676002)(16526019)(16576012)(966005)(66946007)(36756003)(235185007)(6916009)(31686004)(26005)(478600001)(8936002)(5660300002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: /GOxUv5fbFcr7WxmYfLztg9ynlXohRbS9l1ZAAPk/HDvSUNnA2ROZpELv7L0j+jDQ5Xm/o8hc2QDTPd/9fTYAtJldUUEZO9NWted2o0AADRHGD/breIFbkErutO+NvnQRGgQeLV5T2i4WDfZvr0tbmp9rJG1IiPtpW+vImLzFNIR4f9O7eTK9BNZsOQC1DNxCw6Yo41K3sxNGnakeH467OzVLuQ61bMYgo6rsLAohXzXYpP9Mjd/ZXWEA5VSjoPGVoWmuvDAuD/LMLkTEgHUffJbm0CcoYOJQVyXF+eTFtKWwyYHEJfk85pXNAO2E7hA2/6ciid0v7CyYcoX3JmB9A5t0a4pbVaGTipPJdb2HUTIPehPJ93zoXpKPYy4DKOMgo+57pZgpXJafp5qyqRvVctzsCB3KE2bZlZS10gZiz0hnqcUEC7kb7o0fxNQp0ziEJiTvDIftrKCJCFnY9VcbtOGgo3WPF4gxUad+4jN6SY= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 9c372f79-b78e-4bf3-14e7-08d827e39717 X-MS-Exchange-CrossTenant-AuthSource: VI1P189MB0398.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2020 10:49:32.0815 (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: RDh3CcC9H8gpPsa6K3SrieLvxvL6qgJ6m0PcKkeHWP2AvtOuORP3E7pGUuVbNCOUalJt+TMzgMGMlAZz5AcyjQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P18901MB0093 Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-tiloca-ace-group-oscore-profile-03.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, 14 Jul 2020 10:49:39 -0000 --lqXzBYoGqGatvcHALZhEKEOWKJDU8VD7T Content-Type: multipart/mixed; boundary="3izW5D5SWcC7LEDDl4hiV33SxwXnQt0Ub" --3izW5D5SWcC7LEDDl4hiV33SxwXnQt0Ub Content-Type: multipart/alternative; boundary="------------6B6ACAC4421B7F397C2D2630" Content-Language: en-US This is a multi-part message in MIME format. --------------6B6ACAC4421B7F397C2D2630 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello ACE, We have submitted an updated version of draft-tiloca-ace-group-oscore-profile https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-03 The document describes a profile of ACE where client and server communicate with Group OSCORE. This supports fine-grained access control in group communication environments, where different group members have different access rights to the resources of the servers in the group. This version builds on the major update of v -02, with the profile now focused on Group OSCORE as only security protocol, and further adds: 1) Clearer motivation in the introduction, with access control to the secure group communication channel (addressed in [1]) separated from access control to the resources of the servers in the group (addressed in this document). 2) Achievement of proof-of-possession discussed for both the group mode and the pairwise mode of Group OSCORE. Comments are very welcome! Best, /Marco [1] https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore -------- Forwarded Message -------- Subject: New Version Notification for draft-tiloca-ace-group-oscore-profile-03.txt Date: Mon, 13 Jul 2020 10:23:52 -0700 From: internet-drafts@ietf.org To: Ludwig Seitz , Rikard Hoeglund , Francesca Palombini , Marco Tiloca A new version of I-D, draft-tiloca-ace-group-oscore-profile-03.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-ace-group-oscore-profile Revision: 03 Title: Group OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework Document date: 2020-07-13 Group: Individual Submission Pages: 53 URL: https://www.ietf.org/internet-drafts/draft-tiloca-ace-group-oscore-profil= e-03.txt Status: https://datatracker.ietf.org/doc/draft-tiloca-ace-group-oscore-profile/ Htmlized: https://tools.ietf.org/html/draft-tiloca-ace-group-oscore-profile-03 Htmlized: https://datatracker.ietf.org/doc/html/draft-tiloca-ace-group-oscore-profi= le Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-tiloca-ace-group-oscore-profile= -03 Abstract: This document specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. The profile uses Group OSCORE to provide communication security between a Client and a (set of) Resource Server(s) as members of an OSCORE Group. The profile securely binds an OAuth 2.0 Access Token with the public key of the Client associated to the signing private key used in the OSCORE group. The profile uses Group OSCORE to achieve server authentication, as well as proof-of-possession for the Client public key. Also, it provides proof of Client's membership to the correct OSCORE group, by binding the Access Token to information from the Group OSCORE Security Context, thus allowing the Resource Server(s) to verify the Client's membership upon receiving a message protected with Group OSCORE from the Client. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------6B6ACAC4421B7F397C2D2630 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello ACE,

We have submitted an updated version of draft-tiloca-ace-group-oscore-profile

https://tools.ietf.org/html/d= raft-tiloca-ace-group-oscore-profile-03

The document describes a profile of ACE where client and server communicate with Group OSCORE. This supports fine-grained access control in group communication environments, where different group members have different access rights to the resources of the servers in the group.

This version builds on the major update of v -02, with the profile now focused on Group OSCORE as only security protocol, and further adds:

1) Clearer motivation in the introduction, with access control to the secure group communication channel (addressed in [1]) separated from access control to the resources of the servers in the group (addressed in this document).

2) Achievement of proof-of-possession discussed for both the group mode and the pairwise mode of Group OSCORE.

Comments are very welcome!

Best,
/Marco

[1] https://tools.ietf.org/html/dr= aft-ietf-ace-key-groupcomm-oscore


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-ace-group-oscore-profile-03.txt
Dat= e: Mon, 13 Jul 2020 10:23:52 -0700
Fro= m: internet-drafts@ietf.org
To:= Ludwig Seitz <ludwig.seitz@combitech.se>, R= ikard Hoeglund <rikard.hoglund@ri.se>, Francesca Palombi= ni <francesca.palombini@ericsson.com>, = Marco Tiloca <marco.tiloca@ri.se>



A new version of I-D, draft-tiloca-ace-group-oscore-profile-03.txt<= br> has been successfully submitted by Marco Tiloca and posted to the IETF repository.

Name: draft-tiloca-ace-group-oscore-profile
Revision: 03
Title: Group OSCORE Profile of the Authentication and Authorization for Constrained Environments Framework
Document date: 2020-07-13
Group: Individual Submission
Pages: 53
URL: https://www.ietf.org= /internet-drafts/draft-tiloca-ace-group-oscore-profile-03.txt
Status: https://datatracker.ie= tf.org/doc/draft-tiloca-ace-group-oscore-profile/
Htmlized: https://tools.ietf.org/html= /draft-tiloca-ace-group-oscore-profile-03
Htmlized: https://datatracker.ietf.o= rg/doc/html/draft-tiloca-ace-group-oscore-profile
Diff: https://www.ietf.org/rfcd= iff?url2=3Ddraft-tiloca-ace-group-oscore-profile-03

Abstract:
This document specifies a profile for the Authentication and
Authorization for Constrained Environments (ACE) framework. The
= profile uses Group OSCORE to provide communication security between a
Client and a (set of) Resource Server(s) as members of an OSCORE Group. The profile securely binds an OAuth 2.0 Access Token with the
public key of the Client associated to the signing private key used
in the OSCORE group. The profile uses Group OSCORE to achieve server
authentication, as well as proof-of-possession for the Client public
key. Also, it provides proof of Client's membership to the correct<= br> OSCORE group, by binding the Access Token to information from the Group OSCORE Security Context, thus allowing the Resource Server(s)
to verify the Client's membership upon receiving a message protected
with Group OSCORE from the Client.



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.

The IETF Secretariat


--------------6B6ACAC4421B7F397C2D2630-- --3izW5D5SWcC7LEDDl4hiV33SxwXnQt0Ub-- --lqXzBYoGqGatvcHALZhEKEOWKJDU8VD7T Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl8NjboACgkQ7iZktA5Y 2kMt4AgApMdMjJI3U7v+b4GlbTPIK0LxPzT536i57jmaf078fAH5XNcSsOVrWjb7 flwG9ljqO7oMcDdo8cjvyWpTxT9DR34qu7Kd/lorF4x5AxRmC3eREA3rSULWLpaq q9TC46EDQo8QJ4vk+zh8zxSur1ljowLRfhN2FIBcRjEgOr8H6lae2V0SaItf3arg oI85ZF55Q4QGwy6lU+l7dp0em3/miFCnWa48C3Le/5DFrnLpa6I+IAwYKlnjSl6V JehIfZWZGiZZc2n1H34b34Vr2IuUi5QA1UIztY9HVkd6Wcf5llPFB1XHI8qpakoU 4k/lmPb+kZEJa6dCGS5gDL890JE/Fg== =4P7U -----END PGP SIGNATURE----- --lqXzBYoGqGatvcHALZhEKEOWKJDU8VD7T-- From nobody Tue Jul 14 03:50: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 25C3D3A09AA for ; Tue, 14 Jul 2020 03:50:26 -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=ham 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 wwSvVkMa42Ih for ; Tue, 14 Jul 2020 03:50:22 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00044.outbound.protection.outlook.com [40.107.0.44]) (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 1A49B3A09A8 for ; Tue, 14 Jul 2020 03:50:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nb6hVeGq8Fm7FWUjP5I1TA2g22KN64kPil+lppMEyfW+lK9Je6jmL0A7RwP6kk7kKnU/ilBD0cNH6M9Dd/D8ilv7QwUJLwWIvwN1d2gEL7DQIf1CDuB3qH9xSfulSNbz9qK4rRmWb5QBJ50HQRBPNPZLEIYbCvQ3QHrGqePobKPX6mWctk384hh2dV2trfy6kzu+oxe0J8SbGXx2zgM3Hansl5Yjzy/ojeDuq/c72H4w6nEdE1LGGTU0/Pa3QWZvLnVMDf1UKMItWSimsjJfXhOLgR/1M8GzYjjV0chLpgnC7JyzY/K8yCf5e+0DY7s7Fe8xxP71q/vEJcO/vd3tLA== 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=AzcqJHrj21cNuk+UQ2yzaVfqMTLWBNQsyInaARniYh8=; b=DXoXXrOxf84sZTncfSszn0Xuph3TAHfRJ6WdJhd+aJGa2YtohsM4dyECwP4qGR+aUqV9mPGJsoQAG810anLaqa4C0tmU56xjBKyyVNmtvOGd0jEaurwRY21vqnRg3zzpdp3T1jrfC73JMEhqwOnf2EEAHNNM9uPfyIRjBUYh8ONkcocvynSPhacPmiPBvMsecUUJrhhCp2rS4KHDQ85XWyWXYoSEbBdDY7AbcYLldZw735loxtL1yHco7uPp/ZlovvDw+UaLidB+LkvzswgM7lvXJQMLSC4GYhbUG8XoncGnzuWmBpf11VOnfsoiGG1vBTyVobsqKY69FTGojbeUfQ== 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=AzcqJHrj21cNuk+UQ2yzaVfqMTLWBNQsyInaARniYh8=; b=YbTqwy1Q8zqK8xyZ65IdavU7Yc4kEu8A/pQMKscxRpEtCz0oyaQZgO9t3ifgtqtSw77jH5ZGdAoUPM0FIe3EFA/lMXfIvh/TsCd26DdXb/tFuft62Un8ZUE2dXT3c9dR++q1f3dcMHe1vBUq8zkemyxz0kiPOWYGmEMqOwZjknc= 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 VI1P18901MB0061.EURP189.PROD.OUTLOOK.COM (2603:10a6:801:f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21; Tue, 14 Jul 2020 10:50:17 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2%6]) with mapi id 15.20.3174.025; Tue, 14 Jul 2020 10:50:17 +0000 References: <159466122589.850.16081436540156093467@ietfa.amsl.com> To: Ace Wg 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== X-Forwarded-Message-Id: <159466122589.850.16081436540156093467@ietfa.amsl.com> Message-ID: <8e1e734e-4368-8384-59b3-975a54d25590@ri.se> Date: Tue, 14 Jul 2020 12:50:14 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <159466122589.850.16081436540156093467@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="p7xVpbsNQZkGnNwxo7QO6Owcmo9t8dIKn" X-ClientProxiedBy: HE1PR0902CA0004.eurprd09.prod.outlook.com (2603:10a6:3:e5::14) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.9] (31.13.191.152) by HE1PR0902CA0004.eurprd09.prod.outlook.com (2603:10a6:3:e5::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21 via Frontend Transport; Tue, 14 Jul 2020 10:50:16 +0000 X-Forwarded-Message-Id: <159466122589.850.16081436540156093467@ietfa.amsl.com> X-Originating-IP: [31.13.191.152] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f476113b-2ff6-4046-fff9-08d827e3b1f8 X-MS-TrafficTypeDiagnostic: VI1P18901MB0061: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: n/ECOdlLq6thpFcKRT7BKw/InjUepqTBLKkQOuMjUxYFDAj6eIVcQZTNQQF6IBCVB2u382uTQ9PhrbDjE5ScPcRcSH/9GkptU5wVWo3stLKFHaL8bgXbg0OxkbSf8e+6nTzQtA25Tu+FT5QdFfbdwBRNny5ZJum8cCgSBQMKXHsSGWXcvqh5nDg9dxBzX7Ut0X8q2F0gMPcLXiSxSGzosGKyBYlRJTCH7aIuaM5phar6q+TGe9LmL7DyBm0hOBVXWJaBqVwmBuBYVSnejdZWnw94Ye93cN1GMGO3ycGGFptSssctLFZevQf32xoBOgAge/MA0/WA3fVjqKY1NQeO1YBWvrs2r2XScjTsEq7SRKhAB2XZ25azyyadOcOdXziO/pMY56HnPdAwd9lstpS2J7/3IvqjoqlsTMm2LZslusUOo4rw6JJ4yxUVCJskPzbjC4MY/bCu+Zuc3aurl7bz0Q== 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)(376002)(136003)(366004)(39850400004)(396003)(346002)(66476007)(235185007)(21480400003)(66946007)(186003)(66556008)(966005)(52116002)(36756003)(66574015)(31696002)(83380400001)(44832011)(316002)(8676002)(15650500001)(16526019)(5660300002)(33964004)(31686004)(478600001)(26005)(16576012)(8936002)(2906002)(166002)(956004)(2616005)(6916009)(86362001)(6486002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: IfpSkhfHFjsME2U9WXHjGDZqA0nkGjelBrsplxCfT06s48RNiP32hsJ3qPnXiJ+uXG5TkCq04sSRvVuIwISPsjAU5ZzKhFVm66/DIY6LIvv0PY3WjVmtCAp4hV7Ls0u2qoH4i4xLdP15Wn8MGnohw756V+WQQRO70CdFBhd9FfG0+mB3tlL1X0ZoY5qLJ3+/hwOT7g1IKD/UnMZOc+9wCPWVGiQEZy1t7cRFCdd2wH+Jx7DxyxywuOTCHD3GP8qc6LVZv3M50Wet+nEJnDOeCILZ0Xlx1305PW0CQlEYPPdreji9uLVjtGOnZhal5RNi8hyggQgvPnGkkOkTBqtRS9CFBU2O02bddp8yx4tjdhGaAAAzCPTsXbjk5cWraiWumaWaMAasBfp8K6gTuDBuRF2VxvLh0s/h86BR0W+GIFL848up89eXSarep9ccD+NRdRBJzskaGJM1BFR4bkrLIyWko/zgHEBRon7ubvu3kZU= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: f476113b-2ff6-4046-fff9-08d827e3b1f8 X-MS-Exchange-CrossTenant-AuthSource: VI1P189MB0398.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2020 10:50:17.1169 (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: 8SpyHpY/G/3QV0863YiWujT0kZGqlfbLLyeuXb7fBrY9wZGXRwkb+Obl5FhV29VhAFcGs0hQXh8XgMH73TElDw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P18901MB0061 Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-tiloca-ace-oscore-gm-admin-02.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, 14 Jul 2020 10:50:26 -0000 --p7xVpbsNQZkGnNwxo7QO6Owcmo9t8dIKn Content-Type: multipart/mixed; boundary="IEp4PDnSbjsxQDPOOLn5oS5zs2SStkYVy" --IEp4PDnSbjsxQDPOOLn5oS5zs2SStkYVy Content-Type: multipart/alternative; boundary="------------7CBA3BE78E37949CF685DC6E" Content-Language: en-US This is a multi-part message in MIME format. --------------7CBA3BE78E37949CF685DC6E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello ACE, We have submitted an updated version of draft-tiloca-ace-oscore-gm-admin https://tools.ietf.org/html/draft-tiloca-ace-oscore-gm-admin-02 The document describes a RESTful interface on the OSCORE Group Manager (resource server), intended for an Administrator (client) to create and delete OSCORE groups, as well as set, retrieve and update their configuration. This interface is aligned and consistent with the other RESTful interface on the Group Manager used in [1] and rather intended for joining nodes and current group members. This update is especially about: 1) Addressing most of the review at [2] from Jim (thanks!) 2) Addressing comments from Christian at [3] (thanks!) 3) Improved examples both in CBOR and in CoRAL. Comments are very welcome. Best, /Marco [1] https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore [2] https://mailarchive.ietf.org/arch/msg/ace/q55WDjJLdEMVvI0bV7k_VrzRgIY= / [3] https://mailarchive.ietf.org/arch/msg/ace/gLr5NgAURoi5P9f6RcgHkL2jFr8= / -------- Forwarded Message -------- Subject: New Version Notification for draft-tiloca-ace-oscore-gm-admin-02.txt Date: Mon, 13 Jul 2020 10:27:05 -0700 From: internet-drafts@ietf.org To: Marco Tiloca , Rikard Hoeglund , Klaus Hartke , Francesca Palombini , Peter van der Stok A new version of I-D, draft-tiloca-ace-oscore-gm-admin-02.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-ace-oscore-gm-admin Revision: 02 Title: Admin Interface for the OSCORE Group Manager Document date: 2020-07-13 Group: ace Pages: 29 URL: https://www.ietf.org/internet-drafts/draft-tiloca-ace-oscore-gm-admin-02.= txt Status: https://datatracker.ietf.org/doc/draft-tiloca-ace-oscore-gm-admin= / Htmlized: https://tools.ietf.org/html/draft-tiloca-ace-oscore-gm-admin-02= Htmlized: https://datatracker.ietf.org/doc/html/draft-tiloca-ace-oscore-gm-admin Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-tiloca-ace-oscore-gm-admi= n-02 Abstract: Group communication for CoAP can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible to handle the joining of new group members, as well as to manage and distribute the group key material. This document defines a RESTful admin interface at the Group Manager, that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of-possession and server authentication. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------7CBA3BE78E37949CF685DC6E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello ACE,

We have submitted an updated version of draft-tiloca-ace-oscore-gm-admin

https://tools.ietf.org/html/draft-= tiloca-ace-oscore-gm-admin-02

The document describes a RESTful interface on the OSCORE Group Manager (resource server), intended for an Administrator (client) to create and delete OSCORE groups, as well as set, retrieve and update their configuration.

This interface is aligned and consistent with the other RESTful interface on the Group Manager used in [1] and rather intended for joining nodes and current group members.

This update is especially about:

1) Addressing most of the review at [2] from Jim (thanks!)

2) Addressing comments from Christian at [3] (thanks!)

3) Improved examples both in CBOR and in CoRAL.

Comments are very welcome.

Best,
/Marco

[1] https://tools.ietf.org/html/dr= aft-ietf-ace-key-groupcomm-oscore
[2] https://mailarchive.ietf.or= g/arch/msg/ace/q55WDjJLdEMVvI0bV7k_VrzRgIY/
[3] https://mailarchive.ietf.or= g/arch/msg/ace/gLr5NgAURoi5P9f6RcgHkL2jFr8/


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-ace-oscore-gm-admin-02.txt
Dat= e: Mon, 13 Jul 2020 10:27:05 -0700
Fro= m: internet-drafts@ietf.org
To:= Marco Tiloca <marco.tiloca@ri.se>, Rikard Hoeglund= <rikard.hoglund@ri.se>, Klaus Hartke <klaus.hartke@ericsson.com>, Francesca Palomb= ini <francesca.palombini@ericsson.com>, = Peter van der Stok <consultancy@vanderstok.org>



A new version of I-D, draft-tiloca-ace-oscore-gm-admin-02.txt
has been successfully submitted by Marco Tiloca and posted to the IETF repository.

Name: draft-tiloca-ace-oscore-gm-admin
Revision: 02
Title: Admin Interface for the OSCORE Group Manager
Document date: 2020-07-13
Group: ace
Pages: 29
URL: https://www.ietf.org/inte= rnet-drafts/draft-tiloca-ace-oscore-gm-admin-02.txt
Status: https://datatracker.ietf.or= g/doc/draft-tiloca-ace-oscore-gm-admin/
Htmlized: https://tools.ietf.org/html/draf= t-tiloca-ace-oscore-gm-admin-02
Htmlized: https://datatracker.iet= f.org/doc/html/draft-tiloca-ace-oscore-gm-admin
Diff: https://www.ietf.org/rfc= diff?url2=3Ddraft-tiloca-ace-oscore-gm-admin-02

Abstract:
Group communication for CoAP can be secured using Group Object
Security for Constrained RESTful Environments (Group OSCORE). A
= Group Manager is responsible to handle the joining of new group
= members, as well as to manage and distribute the group key material.
This document defines a RESTful admin interface at the Group Manager,
that allows an Administrator entity to create and delete OSCORE
= groups, as well as to retrieve and update their configuration. The<= br> ACE framework for Authentication and Authorization is used to enforce
authentication and authorization of the Administrator at the Group<= br> Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of-possession and server
authentication.



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.

The IETF Secretariat


--------------7CBA3BE78E37949CF685DC6E-- --IEp4PDnSbjsxQDPOOLn5oS5zs2SStkYVy-- --p7xVpbsNQZkGnNwxo7QO6Owcmo9t8dIKn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl8NjeYACgkQ7iZktA5Y 2kMI/QgAiYYELtGq8J3oki86tx17G8Bsby891u1Z5CblDnb+ttO2AoKqCV5bivyL cY247v2WEJrWkmXqp5BwUfXLxM6T7mhlEUEWGzcEdiIOEr5PGSn/aVnRKR+hG3O7 CHiN3FkywsrQ7ln4aEBnMV2mtnFprmQJUlKXCuUMY2a2ySMg3TN7zgLiovR9L+rS QiPre9BLcZHYGBp+gDU4lAwxkQ032LmNk0NQk33Sa5LKz6PmkHImRiQY2227XGf0 G0KyRQFjDqpNh/B+YFr0ypboNm2M6BLn+00nBCNN44zWtVjBQbTUleeRCvPlYBvF Y6b0g7MPLMh5hSTYx5t7WhLlJtrspw== =aNKJ -----END PGP SIGNATURE----- --p7xVpbsNQZkGnNwxo7QO6Owcmo9t8dIKn-- From nobody Tue Jul 14 03:51: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 48CBB3A09A8 for ; Tue, 14 Jul 2020 03:51:37 -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=ham 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 q41U7Gt0JHqT for ; Tue, 14 Jul 2020 03:51:34 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00079.outbound.protection.outlook.com [40.107.0.79]) (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 056843A09A3 for ; Tue, 14 Jul 2020 03:51:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IMKk/0hDIWg3FS9Tl/TRTOTlJV1Iz3XG0gRQc711eI597395Ff4JfLWi6VjKNx2LMqcUvobFswwo9KFPpGIvEIOqMEot0ao2ilynpB7PyQl+MtY7df3gXVZ4wUDz/LPH9H31OvLjWUdnPYtWTX3xc2wDQs0aqM/X/1LRze3FZyX421CzbNMkSFrfk33cGmIrtZ77yWhcTGzAUaIkk+/tcrLXmdldm07Y40QcTM1+x0yl56rqXu3CB8y14+Pfe/eAFl2PEz+dGrm1n6oYILwFeiKIzJNuANWgfIYIcWQdAhrAuZRZqF/LJyZSd2l2dAhESWCP+IR8gTM9v17oBuQcmQ== 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=WEvoGo+Y1Xxq7mbRVuHZwr8Adj09p04EcxawirAunO0=; b=YUskPtQ25O/Ru6bAonQgdPdS0Tv78j950PgSTa3BhT9YBuZtmdLiihcyJbAVOQRfOUA3uw6PC5iLTA7t45czSInkuqYzglC4CQnFnM61BVCL1rR1NUzaDEbKzn9jv26Hg6w4HiRYkM+LJJdu0qYl6P2JflYd9UGwOFUSOeLnNJiYrXyMvfgO14vg+Ww4wTpNFim72gf3YEGicG9OpwvVqcMbJPLhKKnX+VnXCpyeujF7w29m8xKigRX04rdphi1fNS5/M2YYQdfL+mfwETNVEunIGrQT3vR/NH2YC4Zu8y17blsOqp4J7YjSHh+HqqF3bbY4ER8Tjt7jjA2DRAdBmw== 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=WEvoGo+Y1Xxq7mbRVuHZwr8Adj09p04EcxawirAunO0=; b=YhHCRl8HWDShWvw2snv8vJfq8qJs7ddj39Z1LEiMh/JXaCmdEua9wSNBYvgJG/RzlY8eaVEWBQL5vK9kCsZY2M2kBodKNnUXf/SiohAIGrEfW0h+8eSWJ7gdtBdXVFMDhEt585JSPCgY26D7yjWs2WTuy5Xh1yDwgDQaEPhdSpQ= 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 VI1P18901MB0061.EURP189.PROD.OUTLOOK.COM (2603:10a6:801:f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21; Tue, 14 Jul 2020 10:51:31 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2%6]) with mapi id 15.20.3174.025; Tue, 14 Jul 2020 10:51:31 +0000 References: <159466146525.5331.6614510033704238174@ietfa.amsl.com> To: Ace Wg 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== X-Forwarded-Message-Id: <159466146525.5331.6614510033704238174@ietfa.amsl.com> Message-ID: <5a6455af-b0f8-7421-3a67-1f6c9ccb7f88@ri.se> Date: Tue, 14 Jul 2020 12:51:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <159466146525.5331.6614510033704238174@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="gi6wIwkU0smxe2Kx30juDTzOr9uirSegh" X-ClientProxiedBy: HE1PR0902CA0010.eurprd09.prod.outlook.com (2603:10a6:3:e5::20) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.3.9] (31.13.191.152) by HE1PR0902CA0010.eurprd09.prod.outlook.com (2603:10a6:3:e5::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.21 via Frontend Transport; Tue, 14 Jul 2020 10:51:31 +0000 X-Forwarded-Message-Id: <159466146525.5331.6614510033704238174@ietfa.amsl.com> X-Originating-IP: [31.13.191.152] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 30a6d21a-c168-42a1-e44f-08d827e3de5e X-MS-TrafficTypeDiagnostic: VI1P18901MB0061: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: ItiY3cAIoFksudNLeeLUYp/VVoDqdhlc2oR27Anlysyt4AbBVadqsFtRQ4d4fvXMP49L0KoyGSBNGsKg0A31LCgo5K2tYNckiDXGeueECNY/8M9YPpo5O8i279QWFYdfCfGnKqBBCfvz7Flp1l5aSQhgfuiQl8S8YhbRnfqiSnLbRYL2B8UWRcGPD1z4bom+n4TcSbMtHiNHJ9qddwOUIDROYKRIhsKgisV54FIG4MFF3LVe7ZAa6JmkZhrAelISvpyBkNceLk33yQfCXmU2mghQAeSHnxLYFGQu4ya8EpHVPBY1PKH//GsZBgoiptLMyeICdRocqXNdBs/Vq/Xig7RAMRVGLb9VTZCb5WWv9UE/L0IFmG8vu3WmJ8AUiIRo++OTqB3hAEppA0eonjPda05FnEtk0kcgZm8/E8KGvQKonvI7+PlFqJIyND2ACy73+1TyOnV70WuwKGNpTX8Kvw== 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)(376002)(136003)(366004)(39850400004)(396003)(346002)(66476007)(235185007)(21480400003)(66946007)(186003)(66556008)(966005)(52116002)(36756003)(66574015)(31696002)(83380400001)(44832011)(316002)(8676002)(15650500001)(16526019)(5660300002)(33964004)(31686004)(478600001)(26005)(16576012)(8936002)(2906002)(166002)(956004)(2616005)(6916009)(86362001)(6486002)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: W0RTifCzGqMVfAYNENDmdvTO2svuC2a7dY1whZQcg8ewZgWGq2xIzpgCI3ScODvfz4adJYE31W8XJxZy4nonf5LSG3Wuyyew62RQcbY84gNnrwxIgbG9AtbjRO2MAuN+Qqzh4w/JY4Oi7xhIi9BtWfz6Zwnmyqz7LNQp7vV4ynMO7Bg+Ex4jZ8xpBVsWDe9f4SVCBrKLC7SpVBhTBjzEHWvzIlO220vRlFzM3qpyciWS7EJ9BhXfW+BdiAV7K31uwvpL/k3WvQjU4272PfGiMh2lJlVMp3MUVjiCd/wrtEJh46aP7FmVZLn7m6Sz82iLYKUC2uFI6qh3LOpbyyl2UGZw8M0+VMGEu3mGEjCZgEPYKbg9RXrNPSbQh+9/jcTr4MUMU1J1t8SY/YW6MoG2zbpjm3zSDSsEGmVqbb878DLXK1UaNykrRUJ8674EaPcNvbTHtPLk0ubNXdqFL7PJWjlDIF+UqJYMXRZHE4OrUF4= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 30a6d21a-c168-42a1-e44f-08d827e3de5e X-MS-Exchange-CrossTenant-AuthSource: VI1P189MB0398.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2020 10:51:31.6054 (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: AUzUOV15n2FXWQLTtkEVN8Gb5pvTQHDyxAi6iNnfQPTchL/oX7tsJYdQ8v9L8Tk5I4Ef9S+dzxGgx17u4r4uYQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P18901MB0061 Archived-At: Subject: [Ace] Fwd: New Version Notification for draft-tiloca-ace-revoked-token-notification-02.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, 14 Jul 2020 10:51:37 -0000 --gi6wIwkU0smxe2Kx30juDTzOr9uirSegh Content-Type: multipart/mixed; boundary="xlCClgSmP1asyoPXvDZOJRPv4iYJWPvNT" --xlCClgSmP1asyoPXvDZOJRPv4iYJWPvNT Content-Type: multipart/alternative; boundary="------------4840EBCB73C6261812B3D1E1" Content-Language: en-US This is a multi-part message in MIME format. --------------4840EBCB73C6261812B3D1E1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello ACE, We have submitted an updated version of draft-tiloca-ace-revoked-token-notification https://tools.ietf.org/html/draft-tiloca-ace-revoked-token-notification-0= 2 The document describes how an Authorization Server can notify Clients and Resource Servers of revoked but yet not expired Access Tokens. This is achieved by means of a Token Revocation List (TRL) resource at the AS, that a device can access and observe by using resource observation for CoAP. The approach complements token introspection at the AS, and does not require additional endpoints on Clients and Resource Servers. This update is especially about: 1) Addressing the review at [1] from Carsten and additional input from Ben during the latest interim (thank you both!). 2) Clarifications and examples on how the token hash is built. 3) Simplified interface and payload format for the diff query mode. 4) Building on Carsten's suggestion and Ben's input, the new Appendix A and Appendix B describing how to use the Series Transfer Pattern [2] to further improve the diff query mode. Comments are very welcome. Best, /Marco [1] https://mailarchive.ietf.org/arch/msg/ace/ZoEJ6DulqJQcaMRrOdGkmbeFwwk= / [2] https://tools.ietf.org/html/draft-bormann-t2trg-stp -------- Forwarded Message -------- Subject: New Version Notification for draft-tiloca-ace-revoked-token-notification-02.txt Date: Mon, 13 Jul 2020 10:31:05 -0700 From: internet-drafts@ietf.org To: Sebastian Echeverria , Ludwig Seitz , Francesca Palombini , Marco Tiloca , Grace Lewis A new version of I-D, draft-tiloca-ace-revoked-token-notification-02.txt has been successfully submitted by Marco Tiloca and posted to the IETF repository. Name: draft-tiloca-ace-revoked-token-notification Revision: 02 Title: Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework Document date: 2020-07-13 Group: Individual Submission Pages: 24 URL: https://www.ietf.org/internet-drafts/draft-tiloca-ace-revoked-token-notif= ication-02.txt Status: https://datatracker.ietf.org/doc/draft-tiloca-ace-revoked-token-notificat= ion/ Htmlized: https://tools.ietf.org/html/draft-tiloca-ace-revoked-token-notification-0= 2 Htmlized: https://datatracker.ietf.org/doc/html/draft-tiloca-ace-revoked-token-noti= fication Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-tiloca-ace-revoked-token-notifi= cation-02 Abstract: This document specifies a method of the Authentication and Authorization for Constrained Environments (ACE) framework, which allows an Authorization Server to notify Clients and Resource Servers (i.e., registered devices) about revoked Access Tokens. The method relies on resource observation for the Constrained Application Protocol (CoAP), with Clients and Resource Servers observing a Token Revocation List on the Authorization Server. Resulting unsolicited notifications of revoked Access Tokens complement alternative approaches such as token introspection, while not requiring additional endpoints on Clients and Resource Servers. Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------4840EBCB73C6261812B3D1E1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello ACE,

We have submitted an updated version of draft-tiloca-ace-revoked-token-notification

https://tools.ietf.org/html= /draft-tiloca-ace-revoked-token-notification-02

The document describes how an Authorization Server can notify Clients and Resource Servers of revoked but yet not expired Access Tokens. This is achieved by means of a Token Revocation List (TRL) resource at the AS, that a device can access and observe by using resource observation for CoAP. The approach complements token introspection at the AS, and does not require additional endpoints on Clients and Resource Servers.

This update is especially about:

1) Addressing the review at [1] from Carsten and additional input from Ben during the latest interim (thank you both!).

2) Clarifications and examples on how the token hash is built.

3) Simplified interface and payload format for the diff query mode.
4) Building on Carsten's suggestion and Ben's input, the new Appendix A and Appendix B describing how to use the Series Transfer Pattern [2] to further improve the diff query mode.


Comments are very welcome.

Best,
/Marco

[1] https://mailarchive.ietf.or= g/arch/msg/ace/ZoEJ6DulqJQcaMRrOdGkmbeFwwk/
[2] https://tools.ietf.org/html/draft-bormann-= t2trg-stp


-------- Forwarded Message --------
Sub= ject: New Version Notification for draft-tiloca-ace-revoked-token-notification-02.txt
Dat= e: Mon, 13 Jul 2020 10:31:05 -0700
Fro= m: internet-drafts@ietf.org
To:= Sebastian Echeverria <secheverria@sei.cmu.edu>, Ludwig Seitz <ludwig.seitz@combitech.se>, Fra= ncesca Palombini <francesca.palombini@ericsson.com&g= t;, Marco Tiloca <marco.tiloca@ri.se>, Grace Lewis <glewis@sei.cmu.edu>



A new version of I-D, draft-tiloca-ace-revoked-token-notification-02.txt
has been successfully submitted by Marco Tiloca and posted to the IETF repository.

Name: draft-tiloca-ace-revoked-token-notification
Revision: 02
Title: Notification of Revoked Access Tokens in the Authentication and Authorization for Constrained Environments (ACE) Framework
Document date: 2020-07-13
Group: Individual Submission
Pages: 24
URL: https://www.ie= tf.org/internet-drafts/draft-tiloca-ace-revoked-token-notification-02.txt=
Status: https://datatracker.ietf= =2Eorg/doc/draft-tiloca-ace-revoked-token-notification/
Htmlized: https://tools.ietf.org/html= /draft-tiloca-ace-revoked-token-notification-02
Htmlized: https://datatracker.= ietf.org/doc/html/draft-tiloca-ace-revoked-token-notification
Diff: https://www.ietf.or= g/rfcdiff?url2=3Ddraft-tiloca-ace-revoked-token-notification-02

Abstract:
This document specifies a method of the Authentication and
Authorization for Constrained Environments (ACE) framework, which allows an Authorization Server to notify Clients and Resource Servers
(i.e., registered devices) about revoked Access Tokens. The method<= br> relies on resource observation for the Constrained Application
Protocol (CoAP), with Clients and Resource Servers observing a Token
Revocation List on the Authorization Server. Resulting unsolicited<= br> notifications of revoked Access Tokens complement alternative
approaches such as token introspection, while not requiring
additional endpoints on Clients and Resource Servers.



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.

The IETF Secretariat


--------------4840EBCB73C6261812B3D1E1-- --xlCClgSmP1asyoPXvDZOJRPv4iYJWPvNT-- --gi6wIwkU0smxe2Kx30juDTzOr9uirSegh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl8NjjEACgkQ7iZktA5Y 2kNRkAf+INcws6gDDZPaCzdPQnIJn/5Pmv0FEofDCaWgpOAH3otOYK3PeYzVSN2o jHr64QblfZOh69K1txRW+CR0Zf5j8sCGcNgS0cSqvBjqaN7AG/Xef/fLVLtbtOQ/ L2MmEfnyunqGocqxxf/uKCDE96B3NnC+UOsBjVeStmfdfD/Z4w3mE6+2fPkQj/SP XYVwUSzYBYVw64senwFfnH8GludMNDY5f4rre4ihYv0doR3ilWm+1OR4TnZ0hPtp +vqDHz6KDn64E4DY5V9HhhSHZn8ehm8KS0IRqMscx/mC69h27mJKLGh7A53or0Qx LncSOXEJ6JRF7qnLyzoBRqxIUp1bDA== =utwD -----END PGP SIGNATURE----- --gi6wIwkU0smxe2Kx30juDTzOr9uirSegh-- From nobody Tue Jul 14 09:53: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 2F42E3A0A93 for ; Tue, 14 Jul 2020 09:53:26 -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 5DlcDflr9UfQ for ; Tue, 14 Jul 2020 09:53:24 -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 4DC9A3A0A64 for ; Tue, 14 Jul 2020 09:53:24 -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, 14 Jul 2020 09:53:17 -0700 From: Jim Schaad To: =?iso-8859-1?Q?'Christian_Ams=FCss'?= , References: <20200713151226.GA1047142@hephaistos.amsuess.com> In-Reply-To: <20200713151226.GA1047142@hephaistos.amsuess.com> Date: Tue, 14 Jul 2020 09:53:14 -0700 Message-ID: <009101d659ff$45cd3fe0$d167bfa0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLYFdEwaH/mes3ozBFZvKDhdWDjwacCl3ug Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] 4.01 Get A Token From There, discovery-/form-driven applications and tokens opaque to the client 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, 14 Jul 2020 16:53:26 -0000 > -----Original Message----- > From: Ace On Behalf Of Christian Ams=FCss > Sent: Monday, July 13, 2020 8:12 AM > To: ace@ietf.org > Subject: [Ace] 4.01 Get A Token From There, discovery-/form-driven > applications and tokens opaque to the client >=20 > Hello ACE, >=20 > piecing together parts of the big picture of Resource Directory, CoRAL forms > and ACE, I was wondering where in the whole story the client should = tie its > intention to the key material it uses to authorize an action. >=20 > Take this -- admittedly contrived, but hopefully illustrative example: >=20 > * We have a device (C) inside example.com that coordinates a lot of > actions (and thus has a good standing with the AS and gets almost = all > the tokens it asks for. >=20 > * The device would ike to register its management interface with the = RD. >=20 > * A malicious attacker intercepts the discovery process, and tells C > that there is an RD at > `;rt=3Dcore.rd` > (which is a perfectly legitimate service we're running there for > commercial purposes; its interface is that you submit POST a link > there in link-format, and then it ties up the link target with = endless > requests). >=20 > * The device tries to register to the local RD by POSTing some data > there, but as it has no token to the attack server, it receives a >=20 > 4.01 Unauthorized > Get your token from coap://as.example.com, scope launch-attack, > audience attack.example.com >=20 > * The client takes those pieces to the AS, which grants it a token > (after all, C would be authorized to launch an attack, given it's > known to be a coordinator -- it just doesn't mean to). >=20 > * C sends the token to the RS attack, and sends its POST again, with = th > link to its own management interface. >=20 > * The attack server brings C to a grinding halt, because it was = tricked > to shoot its own foot. >=20 > (Admittedly it's good practice for foot- and other guns to not just silently ignore > query parameters like ep=3Dthe-coordinator<=3D3600, but A) other = interfaces > may be more accidentally-compatible, and B) CoRAL forms would widen = the > range of craftable requests enormously). >=20 > My question here is: Where did this go wrong? Should C have verified = with > attack.example.com that it really has the resource type core.rd? > Should it have understood the scope of the action? Should it have a different > security association with the AS for every action it asks tokens for? = And does the > answer still hold if it has already obtained a token to launch attacks (but just > didn't notice that the RD it was sent to happens to have the very URI = its attack > forces use)? I would have expected that the C would have two different keys to talk = to the AS. One for dealing with any attack servers and one for dealing = with things inside the company. I would also expect that C would know which = of those keys are to be used for any given operation. Thus if it is doing registration it will ask for a token using the inside key and not the = attack key. This would then be denied by the AS. In terms of an existing = token, the token should be associated with which key was used to obtain it and = thus an existing attacker token would not be used for talking to the RD. That being said, we need to come up with some better answers for getting information from the RS to the client in some type of protected manner. Either that or we need to decide that the client is suddenly going to = have to understand everything. At one point I was thinking that talking to = an RD over multicast should be done using group keying but I am not sure that = is reasonable. However it could be reasonable that every C would know the audience for the RD it wants to talk to. The problem with that is that = if there are two of them then you would end up with needing to know either = the pattern for RD audience strings or all of the possible audience strings. You do have the benefit that if you get the answer back from a specific address, then you are going to talk to that address. Which works great = for unicast but does not solve any problems with multicast discovery. =20 One possible answer is that there needs to be some pre-configuration for directory services. It may be that one or more audiences are needed to = be known to the end entity so that it can talk securely to an directory and thus the first step would not be possible. Jim >=20 > Kind regards > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Tue Jul 14 14:25:20 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 5CA073A011B; Tue, 14 Jul 2020 14:25:18 -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 7EqJDfmktPFB; Tue, 14 Jul 2020 14:25:15 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80059.outbound.protection.outlook.com [40.107.8.59]) (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 926AF3A0112; Tue, 14 Jul 2020 14:25:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QJ54N6IWqcqII8Jq7Ugivcl8asWp2uJ2Ne3ZqdmH4b+IzkFO6dATLYBELluFnes23rKZpwvJ18Y5ceATlIxO0Pv8jG+LWOCHwRya9IS+XoHBoZ/gJEvp2tE4mMzydZvn4GDbXOr/R/qsbdfi/EuIt6PmcKSNveeaeNkKe17sNafeHmzaka0o6ua0eCsiH5xgVL5ncpUYzNP5Sg+iE0MtTtWSV/oRLviQu7DJPcw0iR6WBZcpWV8DreUCQv/AJKj/mBrIp6+yM7zuBHIoL3p0nXkcquUHgyfxVs5QDf4aSqKUrHIaVv7De1TDqd9NHUBwGvBc3f4kq8lngwbZ8aFcyw== 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=V8ZCU3ifEMvI1nBdETJTUs7e6DhuXmW1FFSHiSTY4KI=; b=NEvThdCNxOnYhwvhZcdOOF+2HeEd9QHtFgmmbtiUohua8hbj/XWM5ZL237Pekn79t8Wh87rqW4wJ2mxN3zfi1WU2jwwJXVyD4CuDat/p01/SJOkXLFIGgIV3PNYHL7iFTkT5rpGSkAI4EX7cxXNOWISNwlZKFtBqJs6hicMEKrUGFBeiXV3ClPjzNzJftGMzPliPIcT04SAmlVdLtWlkXYb+0v0nPeYCsMditO7weqjr9M8WK+1OjjxG3FmdFwACYuogDuZK+rD15BQqxDYmrWumpydD18KGKj6KPX8L1kLke+YOzYwcrNc1n9AyAZnLazOawlFW2jDajyKBj8pvug== 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=V8ZCU3ifEMvI1nBdETJTUs7e6DhuXmW1FFSHiSTY4KI=; b=Gk6hCH9dWvmuiwRxjHLTP02h0DglHEprRVeb/Xj5ZxEOXMMD8ywX7HnePHvMRhqetT19Sbc/Z8NCH4x7z3bEWpqPMhi7zR+1373jaqgQw8qPeucX+a6KHUS4+O1WUcmVsQRBOvogrpFz65g6eI0InFoxzKkiveS2mb+pY2I9Rb8= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR07MB3146.eurprd07.prod.outlook.com (2603:10a6:7:2c::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.11; Tue, 14 Jul 2020 21:25:07 +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.3174.022; Tue, 14 Jul 2020 21:25:07 +0000 From: Francesca Palombini To: Jim Schaad , "draft-ietf-ace-key-groupcomm@ietf.org" CC: "ace@ietf.org" Thread-Topic: Review of ietf-ace-key-groupcomm-07 Thread-Index: AdZHAmDAxxC2glJWS92Qm/d7WHm5HgTM6EcA Date: Tue, 14 Jul 2020 21:25:07 +0000 Message-ID: <8D4E3757-5AE5-4216-B13C-76F5916AD3D3@ericsson.com> References: <023501d64b6e$83ea3b60$8bbeb220$@augustcellars.com> In-Reply-To: <023501d64b6e$83ea3b60$8bbeb220$@augustcellars.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: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [79.12.182.121] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 62f39a56-f314-437c-669b-08d8283c618d x-ms-traffictypediagnostic: HE1PR07MB3146: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SMNbJpH3mOtlGKcm58on2eEKrT4Z5/vkKaoXwB46hHkYZtEvJUEvLQpYF088oyyd8iGm/tHsrA/gzddIXEcw5d9LK9ZQK+EAdHeWSoVzwmduxi0EW1Np45n/48PLT+/Qgk/TFzizIuGB2TpwBy2Jo9vit3+oVkcol7yoelj/qLb1Ex+lkenkTdXxIIY4Xunh4/MBwFvirH1TjY6UREEwJG4TBcpjzZollVBoWEiyrvyYsqHQiWP368BmkABv+ZnrPBVt+40DHQIL6S/VNv2dP07NliTjEWwfKyATtIaws3tvlsaSxba1Xamtn82362mlziHbg2yNRpI9ypB9N1O6fK0FfcHvokpaFXpsIDqj2dECH6350ARCGTlKesoWRDLWDxRoKSIGpAXlXr+lGy7Ac7Giz5z0nTv91jfjaQZ0FpINZo3+ChcdAtSKB8EtSnEMN/kxRa8qZNgLTETk4mXHiw== 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)(39860400002)(346002)(396003)(376002)(366004)(4326008)(6486002)(71200400001)(316002)(64756008)(66556008)(66946007)(91956017)(66446008)(76116006)(66476007)(19627235002)(966005)(86362001)(36756003)(5660300002)(30864003)(2906002)(6512007)(8936002)(83380400001)(8676002)(26005)(186003)(6506007)(33656002)(110136005)(478600001)(2616005)(44832011)(4444003)(579004)(559001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: lg2Gnd+YQm5f0JZU374cIjW0n/XW/mj2XEcMD9FFqLSph/c/ii5yGPYHjcg1P6qqCbj1dhEU0XmaPNCI8Dl9XMoV3dA8mwuWcEO/yo14xUqsVRtTul6IIqfbJ6fMnArAkSiaPnY3680J2X4zx5gxEyST0J201q5WYr93H4agDO2Ic2b0NsG4RAIy20z2/paJFG8iuiouE9YTXTztCwAtywD9f3SXJEGDqwkr2vmUI2+ZyNho3C8x6KUCEY1TuZOL7Dy1wW7W74gUj5nURqWGZhD1XtAPnJ+0tWZcEQgLfdW0jBqBvWNmVQhCrcL3aZ+9+ClQY8A0hNWJa0Wxu/T13PoT2Z45GzBsYAB1v2m7SBR8IA02MSESzdISbBBxWxUty60/zug92ROjf7JNcz6mDfeTAAfsRFCagK+gSrQcSGKfgbQGZAl9JrbQ3ShksUzAhz1fwQDOgN5R0HonO0x36Ht/2o2VmcKs+9Qrj/fxJmQ= 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: 62f39a56-f314-437c-669b-08d8283c618d X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2020 21:25:07.1271 (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: BD3C97qPcLTIGgXSM+4YlVqxH2FgEdnE3PwT76so2uswh3Kz6gm3/S3an10hvDNcxmNVmgFZASIrr3/2S87GVdNuRk4EIqSmO1vkOuF0hdq0y4Zr5KV3ZU7kQojMjPsG X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3146 Archived-At: Subject: Re: [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: Tue, 14 Jul 2020 21:25:18 -0000 SGkgSmltLA0KDQpUaGFuayB5b3Ugc28gbXVjaCBmb3IgYW5vdGhlciBleHRlbnNpdmUgcmV2aWV3 ISBXZSBoYXZlIHN1Ym1pdHRlZCB2LTA4IG9mIHRoZSBkcmFmdCB0byBhbnN3ZXIgaXQuDQpDb21t ZW50cyBpbmxpbmUuIElmIHRoZXJlIGlzIGFueSBhbnN3ZXIvdXBkYXRlIHRoYXQgZG9lcyBub3Qg c2F0aXNmeSB5b3UsIGhvcGVmdWxseSB3ZSBjYW4gY29udGludWUgdGhlIGRpc2N1c3Npb24gYnkg bWFpbCBhbmQgZmlndXJlIG91dCB0aGUgbWFqb3IgcG9pbnRzIHRvIGRpc2N1c3MgZHVyaW5nIElF VEYxMDguDQoNClRoYW5rcywNCkZyYW5jZXNjYSBhbmQgTWFyY28NCg0K77u/T24gMjYvMDYvMjAy MCwgMDY6MDIsICJKaW0gU2NoYWFkIiA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4gd3JvdGU6DQoN CiAgICAqIFNlY3Rpb24gMSBwYXJhIDEgLSBJIGhhdmUgYSB2YWd1ZSBtZW1vcnkgb2YgZGVjaWRp bmcgdGhhdCB3ZSB3ZXJlIGdvaW5nIHRvDQogICAgYmVjb21lIENCT1Igb25seSB3aXRoIHRoaXMg ZG9jdW1lbnQgcGVyIHRoZSBhcmd1bWVudCBmcm9tIENhcnN0ZW4uICBJIGRpZA0KICAgIG5vdCBm aW5kIHRoaXMgaW4gdGhlIG1pbnV0ZXMgc28gdGhpcyBjb3VsZCBlYXNpbHkgYmUgc29tZSBvdGhl ciBkb2N1bWVudA0KICAgIHRoYXQgSSBhbSB0aGlua2luZyBvZi4NCg0KRlA6IFllcywgYW5kIHdl IGFyZSBpbiBmYWN0IGxpbWl0aW5nIHRoaXMgZG9jdW1lbnQgdG8gQ0JPUiwgc2luY2Ugd2UgZG9u 4oCZdCBoYXZlIGFueSBKU09OIG1lZGlhLXR5cGUgcmVnaXN0ZXJlZCBhbnltb3JlICh0aGVyZSB1 c2VkIHRvIGJlKS4gVGhpcyBzZW50ZW5jZSB3YXMgaW5jbHVkZWQganVzdCB0byBtZW50aW9uIHRo YXQgYSBjb252ZXJzaW9uIHRvIEpTT04gaXMgcG9zc2libGUgdG8sIHdoaWxlIG5vdCBleHBsaWNp dGx5IHN1cHBvcnRlZCBoZXJlLg0KDQogICAgKiBTZWN0aW9uIDIgLSBJIGhhdmUgYSBwcm9ibGVt IHdpdGggRmlndXJlIDEgaW4gdGVybXMgb2Ygd2hhdCBpcyBsYWJlbGVkIGFzDQogICAgYW4gUlMu ICBUaGUgdGV4dCBiZWxvdyBjYWxscyB0aGUgS0RDIGFuZCBSUyBhbmQgbm90IHRoZSBEaXNwYXRj aGVyLiAgDQoNCkZQOiA6IFllcywgaW4gdGVybXMgb2YgQUNFIHRoZSBLREMgaXMgdGhlIFJTLiBJ biBnZW5lcmFsIHRlcm1zLCB0aGUgUlMgY2FuIGJlIGEgZGlzcGF0Y2hlciAoZS5nLiBwdWJzdWIp IG9yIHRoZSBncm91cCBtZW1iZXJzIChlLmcuIG11bHRpY2FzdCkuIEJ1dCBJIGFncmVlIHRoaXMg aXMgY29uZnVzaW5nLCB3ZSBoYXZlIHJlbW92ZWQgdGhlIOKAnFJT4oCdIGZyb20gdGhlIERpc3Bh dGNoZXIgaW4gdGhlIHBpY3R1cmUuDQoNCiAgICAqIFNlY3Rpb24gMiAtIHVwZGF0ZSBEVExTIHJl ZmVyZW5jZQ0KDQpGUDogVGhlIEFjZSBwcm9maWxlIG9mIERUTFMgaXMgZGVmaW5lZCB0byBzZXQg dXAgRFRMUyAxLjIsIHRoZXJlIGlzIG5vIHByb2ZpbGUgZGVmaW5lZCB0byBzZXQgdXAgRFRMUyAx LjMsIHNvIEkgZG9u4oCZdCB0aGluayB3ZSBzaG91bGQgdXBkYXRlIHRvIDEuMyBoZXJlLg0KDQog ICAgKiBTZWN0aW9uIDIgLSBJIHRoaW5rIHlvdSBtaWdodCB3YW50IHRoZSBsYXN0IHNlbnRlbmNl IHRvIHJlZmVyIHRvIHN0ZXAgMw0KICAgIHJhdGhlciB0aGFuIHNlY3Rpb24gIC0gVGhlIHBvaW50 ZXIgdG8gdGhlIHNlY3Rpb24gaGFzIGFscmVhZHkgYmVlbiBwcm92aWRlZA0KICAgIGJ1dCBwb2lu dGluZyBiYWNrIHRvIHRoZSBmaWd1cmUgbWFrZXMgYSBkZWdyZWUgb2Ygc2Vuc2UuDQoNCkZQOiBP aywgZml4ZWQgbm93Lg0KDQogICAgKiBTZWN0aW9uIDIgLSBLREMgLSBUaGlzIGlzIHRoZSBmaXJz dCB0aW1lIHRoYXQgSSBoYXZlIGhlYXJkIGFib3V0IHRoZSBmYWN0DQogICAgdGhhdCB0aGlzIGlz IGEgdHdvIHBhcnQgcHJvdG9jb2wgLSBZb3Ugc2hvdWxkIHRlbGwgbWUgYWJvdXQgdGhlIHBoYXNl cw0KICAgIGJlZm9yZSB5b3UgZ2V0IGhlcmUuDQoNCkZQOiBPaywgd2UgaGF2ZSBhZGRlZCBzb21l IHRleHQgaW4gdGhlIGJlZ2lubmluZyBvZiBTZWN0aW9uIDIsIGJlZm9yZSB0aGUgZmlndXJlLg0K DQogICAgKiBTZWN0aW9uIDIgLSAiTGVhdmluZyBvciByZW1vdmluZyIgdGhpcyBpcyBhIHNlbnRl bmNlIHdoaWNoIGRvZXMgbm90IHJlYWQNCiAgICB3ZWxsLiAgKEFsc28gd2h5IGlzIHRoaXMgY3Vy cmVudCB3aGVuIG5vIG90aGVyIGxpbmUgaXMuKQ0KDQpGUDogT2ssIHdlIGhhdmUgdHJpZWQgcmVw aHJhc2luZyB0aGUgYnVsbGV0IGxpc3QgYWdhaW4uDQoNCiAgICAqIFNlY3Rpb24gMiAtIFlvdSBz aG91bGQgcHJvYmFibHkgaGF2ZSBhIG51bWJlcmVkIGl0ZW0gdGhhdCBjb3JyZXNwb25kcyB0bw0K ICAgIHRoZSBzZWN1cmUgZ3JvdXAgY29tbXVuaWNhdGlvbiBsaW5lIGluIHRoZSBwaWN0dXJlLg0K DQpGUDogT2ssIHdlIGhhdmUgYWRkZWQgdGhhdCBhbmQgYWRkZWQgdGhlIDIgcGFyYWdyYXBocyBh ZnRlciB0aGUgcGljdHVyZSB0byB0aGUgYnVsbGV0ZWQgbGlzdCwgYXMgd2UgZmVsdCBpdCBmaXR0 ZWQgYmV0dGVyIHRoZXJlLg0KDQogICAgKiBTZWN0aW9uIDMgLSBUaGUgY29udGVudCBmb3JtYXQg YXBwbGljYXRpb24vYWNlK2Nib3IgaXMgbm90IGRlZmluZWQgYnkgdGhlDQogICAgdHJhbnNwb3J0 IHByb2ZpbGVzIGJ1dCBieSB0aGUgZnJhbWV3b3JrLg0KDQpGUDogVGhlIHBvaW50IGlzIHRoYXQg dGhlIHByb2ZpbGVzIG1pZ2h0IGNoYW5nZSB0aGUgY29udGVudCBmb3JtYXQsIHNvIGV2ZW4gaWYg dGhpcyBzcGVjaWZpYyBvbmUgYWNlK2Nib3IgaXMgZGVmaW5lZCBpbiBBY2UsIHByb2ZpbGVzIG1p Z2h0IGRlZmluZSBhbmQgdXNlIG90aGVyIG9uZXMuIFJlcGhyYXNlZCB0byBjbGFyaWZ5Lg0KDQog ICAgKiBTZWN0aW9uIDMuMSAtIEdpdmVuIHRoYXQgYSByb2xlIGlzIGRlZmluZWQgYXMgYSB0c3Ry LCB0aGF0IGZvcm1hdCBpcyBub3QNCiAgICB1c2FibGUgaWYgb25lIHdpc2hlcyB0byBhc3NpZ24g YW4gaW50ZWdlciBhYmJyZXZpYXRpb24gcGVyIE9QVDcuDQoNCkZQOiBJIHRyaWVkIHRvIHJlZm9y bXVsYXRlIGhlcmUgdGhhdCB0aGUgYWlmIGlzIHRoZSBkZWZhdWx0IGVuY29kaW5nLCBhbmQgc3Bl Y2lmeSB0aGF0IHRoZSBvdGhlciBmb3JtYXQgZGVmaW5lZCBpcyBhbiBleGFtcGxlLiBJbiB0aGUg ZW5kIGl0IGlzIHVwIHRvIHRoZSBhcHBsaWNhdGlvbiBwcm9maWxlIHRvIHNwZWNpZnkgdGhlIGZv cm1hdCBvZiBzY29wZS4NCg0KICAgICogU2VjdGlvbiAzLjEgLSB0aGUgIk90aGVyIGFkZGl0aW9u YWwiIHNlZW1zIHRvIGJlIGEgc3RyYW5nZSB0aGluZyB0byBoYXZlDQogICAgaW4gdGhpcyBsaXN0 IGJlY2F1c2UgaXQgZG9lcyBub3QgbWF0Y2ggdGhlIGxlYWQgaW4gcGFyYWdyYXBoLg0KDQpGUDog UmlnaHQsIHdlIGhhdmUgbW92ZWQgaXQgb3V0IG9mIHRoZSBsaXN0Lg0KDQogICAgKiBTZWN0aW9u IDMuMSAtIElzIHRoZXJlIGEgcmVhc29uIHRoYXQgYSBnaWQgaXMgYSBic3RyIGFuZCBub3QgYSB0 c3RyLiAgSQ0KICAgIGFzc3VtZSB0aGF0IHRoaXMgaXMgdGhlIHNhbWUgYXMgR1JPVVBOQU1FIHdo aWNoIG11Y2ggYmUgYSB0ZXh0IHN0cmluZyB0byBiZQ0KICAgIGluIGEgdXJsLXBhdGguDQoNCkZQ OiBXZSBoYXZlIG1vZGlmaWVkIHRoYXQgdG8gYmUgdHN0ciB0byBiZSBjb25zaXN0ZW50IHdpdGgg YWNlIGtleSBncm91cGNvbW0gb3Njb3JlLCBidXQgcGxlYXNlIG5vdGUgdGhpcyBpcyBvbmx5IGFu IGV4YW1wbGUuDQoNCiAgICAqIFNlY3Rpb24gMy4yIC0gcy9ub24gZXhwaXJlZC9ub24tZXhwaXJl ZC8NCg0KRlA6IEZpeGVkLg0KDQogICAgKiBTZWN0aW9uIDMuMiAtIHRoZSBkZWYgb2Ygc2NvcGUg c2VlbXMgb2RkIGJlY2F1c2UgaXQgaXMgbm90IHdlbGwgZGVmaW5lZCBpZg0KICAgIGl0IHdvdWxk IGJlIHRoZSBzYW1lIGFzIHRoZSByZXF1ZXN0ZWQgc2NvcGUuIChBUyByZXNwb25zZSkNCg0KRlA6 ICBJIG5lZWQgbW9yZSBjbGFyaWZpY2F0aW9uczogSXMgaXQgdGhlIGZvbGxvd2luZyB0aGF0IGlz IHN0cmFuZ2Ug4oCcJ3Njb3BlJyBjb250YWluaW5nIHRoZSBncmFudGVkIHNjb3BlLCBpZiBkaWZm ZXJlbnQgZnJvbSB0aGUgc2NvcGUgcmVxdWVzdGVkIGJ5IHRoZSBjbGllbnQuIOKAnCA/IE5vdGUg dGhhdCB0aGUgdGVybWlub2xvZ3kg4oCccmVxdWVzdGVkIGFuZCBncmFudGVkIHNjb3Bl4oCdIGNv bWVzICBmcm9tIE9BdXRoOiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0 aW9uLTMuMy4gSSByZW1vdmVkIHRoZSBzZWNvbmQgcGFydCBvZiB0aGUgc2VudGVuY2UgYXMgcGVy IGNvbW1lbnQgYmVsb3cuDQoNCiAgICAqIFNlY3Rpb24gMy4yIC0gdGhlIHRleHQgdy8gc2NvcGUg Y2FuIGJlIHNpbXBsaWZpZWQgdG8gdGhlIHNjb3BlIHRoYXQgdGhlIEFTDQogICAgZ3JhbnRzIGFj Y2VzcyB0byBhbmQgc2tpcCB0aGUgbGFzdCBzZW50ZW5jZS4NCg0KRlA6IE9rLCBzaW1wbGlmaWVk LiBJIGtlcHQgdGhlIGxhc3Qgc2VudGVuY2UgYXMgaXQgaXMgbW9yZSBwcmVjaXNlIGluIG15IG9w aW5pb24gdG8ga2VlcCB0aGUgcG9pbnRlciB0byB0aGUgZW5jb2RpbmcuDQoNCiAgICAqIFNlY3Rp b24gMy4yIC0gZGl0dG8gdy8gYWJvdmUgb24gIm90aGVyIGFkZGl0aW9uYWwiDQoNCkZQOiBPaywg Zml4ZWQuDQoNCiAgICAqIFNlY3Rpb24gMy4zIC0gcy9yZXF1ZXN0IG5lY2Vzc2FyeSBpbmZvcm1h dGlvbi9yZXF1ZXN0IGluZm9ybWF0aW9uLw0KDQpGUDogT2ssIGZpeGVkLg0KDQogICAgKiBTZWN0 aW9uIDMuMyAtIEFtIEkgc3VwcG9zZWQgdG8ga25vdyB3aHkgSSBjYXJlIGFib3V0IHB1YmxpYyBr ZXlzIGF0IHRoaXMNCiAgICBwb2ludD8NCg0KRlA6ICBJIHRob3VnaHQgdGhpcyBzZW50ZW5jZSB3 YXMgc3VwcG9zZWQgdG8gY292ZXIgaXQgKHNlY29uZCBwYXJhZ3JhcGggb2YgMy4zKTog4oCcT3B0 aW9uYWxseSwgdGhlIENsaWVudCBtaWdodCB3YW50IHRvIHJlcXVlc3QgbmVjZXNzYXJ5IGluZm9y bWF0aW9uIGNvbmNlcm5pbmcgdGhlIHB1YmxpYyBrZXlzIGluIHRoZSBncm91cCwgYXMgd2VsbCBh cyBjb25jZXJuaW5nIHRoZSBhbGdvcml0aG0gYW5kIHJlbGF0ZWQgcGFyYW1ldGVycyBmb3IgY29t cHV0aW5nIHNpZ25hdHVyZXMgaW4gdGhlIGdyb3VwLuKAnSBXaGF04oCZcyBtaXNzaW5nPw0KDQog ICAgKiBTZWN0aW9uIDMuMyAtIGxhc3Qgc2VudGVuY2Ugb2YgdGhlIHRleHQgaW1wbGllcyB0aGF0 IHNpZ25faW5mbyBhbmQNCiAgICBwdWJfa2V5X2VuYyBhcmUgcmVxdWlyZWQuICBMYXN0IHNlbnRl bmNlIG9mIHBhcmEgMiBuZWVkcyB0byBiZSByZS13cml0dGVuDQoNCkZQOiBSaWdodCwgZml4ZWQg bm93Lg0KDQogICAgKiBTZWN0aW9uIDMuMyAtIHNob3VsZCBpZGVudGlmeSB3aGF0IHNpZ25faW5m byBpcyBmb3IuDQoNCkZQOiBPaywgZml4ZWQuDQoNCiAgICAqIFNlY3Rpb24gMy4zIC0gYXJlIHlv dSBpbXBvc2luZyBhIG5ldyByZXF1aXJlbWVudCB0aGF0IHRoZSB0b2tlbiBiZQ0KICAgIHZhbGlk YXRlZCBwcmlvciB0byByZXR1cm5pbmcgdGhlIHJlc3BvbnNlIHRvIGEgdG9rZW4gcG9zdD8gIEFz IEkgcmVtZW1iZXINCiAgICBpdCwgdGhpcyBpcyBub3QgcmVxdWlyZWQgdG8gaGFwcGVuIHByaW9y IHRvIHRoZSByZXNwb25zZSBiZWluZyByZXR1cm5lZCBqdXN0DQogICAgYmVmb3JlIGFjY2VzcyBp cyBncmFudGVkLiAgKEkuZS4geW91IGNhbiB2YWxpZGF0ZSB0aGUgdG9rZW4gaW4gcGFyYWxsZWwp DQogICAgKEFmdGVyIHN1Y2Nlc3NmdWwgdmVyaWZpY2F0aW9uLi4uKQ0KDQpGUDogSXQgc2VlbXMg dG8gdXMgdGhpcyBpcyBhbHJlYWR5IGRlZmluZWQgaW4gdGhlIGZyYW1ld29yazogZnJvbSBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHotMzUjc2Vj dGlvbi01LjguMQ0K4oCcV2hlbiBhbiBSUyByZWNlaXZlcyBhbiBhY2Nlc3MgdG9rZW4sIGl0IE1V U1QgdmVyaWZ5IGl0IGJlZm9yZSBzdG9yaW5nIGl0LuKAnQ0KQW5kIGxhdGVyDQrigJxJZiB0b2tl biBvciBjbGFpbSB2ZXJpZmljYXRpb24gZmFpbHMsIHRoZSBSUyBNVVNUIGRpc2NhcmQgdGhlIHRv a2VuIGFuZCwgaWYgdGhpcyB3YXMgYW4gaW50ZXJhY3Rpb24gd2l0aCBhdXRoei1pbmZvLCByZXR1 cm4gYW4gZXJyb3IgbWVzc2FnZSB3aXRoIGEgcmVzcG9uc2UgY29kZSBlcXVpdmFsZW50IHRvIHRo ZSBDb0FQIGNvZGUgNC4wMSAoVW5hdXRob3JpemVkKS7igJ0NCg0KICAgICogU2VjdGlvbiAzLjMg LSAicGF5bG9hZCBvZiByZXNwb25zZSBkZXZpYXRlcyIgIEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRo aXMgaXMNCiAgICBhIHRydWUgc3RhdGVtZW50LiAgSG93ZXZlciwgeW91IHNob3VsZCBzdGF0ZSBh dCB0aXMgcG9pbnQgaG93IGl0IGRldmlhdGVzIGlmDQogICAgeW91IGJlbGlldmUgaXQgZG9lcy4g IEkgYXNzdW1lIHRoYXQgeW91IG1lYW4gdGhhdCB0aGVyZSBpcyBhIHBheWxvYWQgYXMNCiAgICBv cHBvc2UgdG8gbm8gcGF5bG9hZC4NCg0KRlA6IFllcywgaXTigJlzIGFib3V0IGhhdmluZyBhIHBh eWxvYWQuIFRoaXMgY2xhcmlmaWNhdGlvbiB3YXMgcmVxdWVzdGVkIGJ5IEx1ZHdpZyBpbiBhIHBy ZXZpb3VzIHJldmlldy4gV2UgaGF2ZSB0cmllZCB0byBjbGFyaWZ5IHRoYXQg4oCcYXMgb3Bwb3Nl ZCB0byBubyBwYXlsb2Fk4oCdLg0KDQogICAgKiBTZWN0aW9uIDMuMyAtIFlvdSB3b3VsZCBub3Qg YmUgYWJsZSB0byByZXVzZSB0aGUgc2FtZSBrZGNjaGFsbGVuZ2UgdmFsdWUNCiAgICB3aXRoIGEg ZGlmZmVyZW50IGtleS4gIEl0IHdvdWxkIG5vdCBoYXZlIGFueSB3YXkgb2YgYmVpbmcgYXNzb2Np YXRlZCB3aXRoDQogICAgdGhhdCBrZXkgYW5kIHdvdWxkIGxvb2sgbGlrZSBzb21lYm9keSBlbHNl IHdhcyBhdHRlbXB0aW5nIHRvIHVzZSB0aGUgdmFsdWUuDQoNCkZQOiBOb3Qgc3VyZSB3ZSB1bmRl cnN0YW5kIHRoZSBwcm9ibGVtIGhlcmUuIERvZXMg4oCcZGlmZmVyZW50IGtleeKAnSByZWZlciB0 byBhIGZvbGxvd2luZyBuZXcgcHVibGljIGtleSB0aGF0IHRoZSBjbGllbnQgd2FudHMgdG8gdXBs b2FkPyBUaGVyZSBpcyBpbiBmYWN0IG5vIGFzc29jaWF0aW9uIGJldHdlZW4g4oCYa2RjY2hhbGxl bmdl4oCZIGFuZCB0aGUgcHVibGljIGtleSBpdHNlbGYsIG5vdCBldmVuIHdpdGggdGhlIGZpcnN0 IG9uZSB0aGF0IHRoZSBjbGllbnQgcHJvdmlkZXMgYXQgaXRzIGZpcnN0IGpvaW5pbmcgKGFuZCBp dCBpcyBhbHNvIHVua25vd24gdG8gdGhlIEtEQyBhdCB0aGUgdGltZSB3aGVuIOKAmGtkY2NoYWxs ZW5nZeKAmSBpcyBpc3N1ZWQpLiBJdOKAmXMgaW1wb3J0YW50IHRoZSDigJhrZGNjaGFsbGVuZ2Xi gJkgaXMgYXNzb2NpYXRlZCB0byB0aGF0IGV4YWN0IGNsaWVudCwgbWVhbmluZyB0byB0aGF0IGV4 YWN0IFRva2VuIGFuZCBQb1Aga2V5Lg0KDQogICAgKiBTZWN0aW9uIDMuMyAtIHMvd2VyZSBpbmNs dWRlZCBpbiB0aGUgcmVxdWVzdC9hcmUgaW5jbHVkZWQgaW4gdGhlIHJlcXVlc3QvDQogICAgcHJl c2VudCB0ZW5zZS4NCg0KRlA6IE9rLCBmaXhlZC4NCg0KICAgICogU2VjdGlvbiAzLjMgLSBEbyB5 b3UgcmVhbGx5IG1lYW4gdG8gc2F5ICJyZXF1ZXN0IGluY2x1ZGVzIHB1Yl9rZXlfZW5jIiwNCiAg ICAicmVzcG9uc2UgZG9lcyBub3QgaW5jbHVkZSBwdWJfa2V5X2VuYyI/ICBUaGF0IHNlZW1zIHRv IGJlIHdyb25nIGluIHRoZQ0KICAgIGdlbmVyYWwgY2FzZS4gIEFsc28gc2VlbXMgdG8gc2F5IHRo ZSBzYW1lIHRoaW5nIGFib3V0ICdzaWduX2luZm8nLiAgQWxzbw0KICAgIHNlZW1zIHRvIGNvbnRy YWRpY3QgdGhlIG5leHQgcGFyYWdyYXBoLg0KDQpGUDogWW91IGFyZSByaWdodCwgdGhlcmUgd2Fz IGEgY29udHJhZGljdGlvbiBiZXR3ZWVuIHRoZSB0d28gcGFyYWdyYXBocy4gV2UgaGF2ZSB0cmll ZCB0byBjbGFyaWZ5IGFuZCBoYXZlIG9ubHkga2VwdCB0aGUgTUFZLiBUaGUgcmVhc29uIGJlaW5n IHRoYXQgdGhlIGZpbmFsIGRlY2lzaW9uIG9mIGluY2x1ZGluZyBvciBub3QgdGhvc2UgcGFyYW1l dGVycyBpcyB0YWtlbiBieSB0aGUgS0RDLg0KDQogICAgKiBTZWN0aW9uIDMuMyAtIFRoZSBmb3J3 YXJkIHJlZmVyZW5jZSBmb3Igc2lnbl9pbmZvIGlzIGluY29ycmVjdCAtIGl0IHNob3VsZA0KICAg IGJlIDMuMy4xLiAgKEkgYWxzbyBkb24ndCBrbm93IGlmIHlvdSBuZWVkIHRoaXMgdHdvIHBhcmFn cmFwaHMgaW4gYSByb3cuKQ0KDQpGUDogT2ssIG1lcmdlZCB0byBzaW1wbGlmeS4NCg0KICAgICog U2FtZSBwYXJhZ3JhcGggLSBncm91cCBpZGVudGlmaWVyIG9yIGdyb3VwIG5hbWU/ICBZb3UgbmVl ZCB0byBkbyBhDQogICAgZGV0YWlsZWQgcGFzcyB0aHJvdWdoIHRoZSBkb2N1bWVudCBhbmQgbG9v ayBhdCBldmVyeSBpbnN0YW5jZSBvZiB0aGlzIHN0cmluZw0KICAgIGFuZCBlaXRoZXIgbWFrZSBp dCBhbiBpZGVudGlmaWVyIG9yIGEgbmFtZSBhbmQgcGVyaGFwcyBhZGQgdGhlc2UgdG8gdGhlDQog ICAgdGVybWlub2xvZ3kgc2VjdGlvbiBzbyB0aGF0IG9uZSBjYW4gcXVpY2tseSBsb29rIGJhY2sg dG8gZGlzdGluZ3Vpc2ggdGhlbS4NCiAgICBQZXJoYXBzIHlvdSBzaG91bGQgYmUgdXNpbmcgY29u dGV4dCBpZGVudGlmaWVyIHJhdGhlciB0aGFuIGdyb3VwIGlkZW50aWZpZXINCiAgICBqdXN0IHRv IG1ha2UgaXQgY2xlYXJlciB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIHdoYXQgZ29lcyBpbnRvIHRo ZSBkaWZmZXJlbnQNCiAgICBsb2NhdGlvbnMuICBUaGUgcHJvYmxlbSB3aXRoIHRoYXQgaXMgaXQg aXMgT1NDT1JFIHNwZWNpZmljIHNvIGl0IG1heSBub3QNCiAgICB3b3JrIHdlbGwuDQoNCkZQOiBS aWdodCwgd2UgZGVmaW5pdGVseSB3YW50IHRvIGF2b2lkIGFsbCBPU0NPUkUgc3BlY2lmaWMgdGVy bXMsIHNvIGNvbnRleHQgaWRlbnRpZmllciBpcyBub3QgYSBnb29kIGlkZWEuIEluIHRoaXMgZG9j dW1lbnQgd2UgdXNlZCBncm91cCBpZGVudGlmaWVyIGFzIGdyb3VwIG5hbWUgIOKAnHRoZSBncm91 cCBpZGVudGlmaWVyIGhhcyB2YWx1ZSAiR1JPVVBOQU1FIuKAnSAoYW5kIGlzIGRpZmZlcmVudCBm cm9tIE9TQ09SRSBncm91cCBpZCkuIEkgcmVwbGFjZWQgaXQgZXZlcnl3aGVyZSB3aXRoIGdyb3Vw IG5hbWUsIGZvciBjbGFyaXR5Lg0KDQogICAgKiBTZWN0aW9uIDMuMyAtIGxhc3QgcGFyYWdyYXBo IC0gc2hvdWxkIHRoaXMgYmUgcmVmZXJyaW5nIHRvIGFwcGxpY2F0aW9ucyBvcg0KICAgIHByb2Zp bGVzPyAgLS0gcmVhbGx5IGEgZ2xvYmFsIHF1ZXN0aW9uLiAgQ29uc2lkZXIgLSBpcyB0aGUgT1ND T1JFIHByb2ZpbGUNCiAgICBhdHRhY2hlZCB0byBhIHNwZWNpZmljIGFwcGxpY2F0aW9uIG9yIHRv IGEgc2V0IG9mIHVua25vd24gYXBwbGljYXRpb25zPw0KDQpGUDogSGVyZSB3ZSBtZWFudCBhcHBs aWNhdGlvbiBwcm9maWxlcyBvZiB0aGlzIGRvYyBzdWNoIGFzIOKAnGFjZS1rZXktZ3JvdXBjb21t LW9zY29yZeKAnS4gSSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIHNlY29uZCBwYXJ0IG9mIGhpcyBj b21tZW50LCBjb3VsZCB5b3UgZXhwbGFpbj8NCg0KICAgICogU2VjdGlvbiAzLjMuMSAtIHMvb25l IG9yZSBtb3JlL29uZSBvciBtb3JlLw0KDQpGUDogT2sgZml4ZWQuDQoNCiAgICAqIFNlY3Rpb24g My4zLjEgLSBzL2lzIGxvd2VyIG9yIGF0IG1vc3QgZXF1YWwgdG8vaXMgYXQgbW9zdC8gLSBhbHNv IHdoYXQNCiAgICBoYXBwZW4gaWYgdGhlIHJlc3BvbnNlIHdvdWxkIGluY2x1ZGUgemVybyBlbGVt ZW50cz8gIFlvdSBhc2tlZCBhbmQgbm90aGluZw0KICAgIG5lZWRzIHRvIGJlIHJldHVybmVkPw0K DQpGUDogWWVzLCB0aGUgS0RDIGNhbiBlc3NlbnRpYWxseSBpZ25vcmUgb3IgcGFydGlhbGx5IGln bm9yZSB0aGUgcmVxdWVzdCBmb3IgaW5mb3JtYXRpb24gZnJvbSB0aGUgQ2xpZW50LiBJIHRoaW5r IHdlIHdhbnQgdG8gbGV0IHRoZSBLREMgYmUgYWJsZSB0byBkbyB0aGF0Lg0KDQogICAgKiBTZWN0 aW9uIDMuMy4xIC0gc2Vjb25kIGJ1bGxldCAtIGtpbGwgdGhlICJpZiBpbmNsdWRlZCIgdGV4dC4g IFRoaXMgaXMNCiAgICBjb3ZlcmVkIGFib3ZlLg0KDQpGUDogSSBkb27igJl0IHRoaW5rIHdlIGNh biByZW1vdmUgdGhlIOKAnGlmIGluY2x1ZGVk4oCdIHRleHQgYXMgaXQgZ2l2ZXMgaW5mb3JtYXRp b24gYWJvdXQgdGhlIGVuY29kaW5nOiANCi0gSWYgaW5jbHVkZWQgaW4gdGhlIHJlcXVlc3QsIHNp Z25faW5mbyBpbiB0aGUgcmVzcG9uc2UgZW5jb2RlcyBsaWtlIHRoaXMgLi4uDQotIElmIG5vdCBp bmNsdWRlZCBpbiB0aGUgcmVxdWVzdCwgc2lnbl9pbmZvIGluIHRoZSByZXNwb25zZSBlbmNvZGVz IGxpa2UgdGhpcyAuLi4NClRoYXQgaXMgbm90IGNvdmVyZWQgYWJvdmUuDQoNCiAgICAqIFNlY3Rp b24gMy4zLjEgLSBzL3NpZ25faW5mby9zaWduX2luZm8vDQoNCkZQOiBGaXhlZCBzaW5nX2luZm8u DQoNCiAgICAqIFNlY3Rpb24gMy4zLjEgLSBUaGlzIGlzIGxvb2tpbmcgcmVhbGx5IGNvbXBsaWNh dGVkIGFuZCBJIGRvbid0IGtub3cgd2h5DQogICAgeW91IGRvbid0IGp1c3Qgc2ltcGxpZnkgaXQg ZG93biB0byBhIHNpbmdsZSByZXF1ZXN0L3Jlc3BvbnNlIHBhaXIuICBEZWZpbmUgYQ0KICAgIHZh bHVlIGZvciB1c2Ugd2hlbiB0aGUgc2VydmVyIGVpdGhlciBkb2VzIG5vdCBrbm93IG9yIGRvZXMg bm90IHdhbnQgdG8gc2hhcmUNCiAgICBhIHZhbHVlIGFuZCBzbyBmb3J0aC4gIFRoZSBzaXplIG9m IGRhdGEgaWYgc2lnbl9pbmZvIHdlcmUgdG8gYmUgb21pdHRlZCBpcw0KICAgIGFsbW9zdCB0aGUg c2FtZSBzaXplIGFzIGlmIGl0IHdoZXJlIHByZXNlbnQgc28gdGhhdCBkb2VzIG5vdCBzZWVtIHRv IGJlIG11Y2gNCiAgICBvZiBhIHdpbi4gIE1ha2luZyB0aGUgYW5zd2VyIG9uZSBieXRlIGxvbmdl ciBmb3IgYWRkaW5nIHRoZSBwdWJfa2V5X2VuY19yZXMNCiAgICBmaWVsZCBkb2VzIG5vdCBzZWVt IHRvIGJlIGEgaHVnZSBwcm9ibGVtIGZvciBhIG9uZS10aW1lIG1lc3NhZ2UuDQoNCkZQOiBUaGFu ayB5b3UgZm9yIHlvdXIgc3VnZ2VzdGlvbiwgd2UgZG8gYWdyZWUgdGhhdCBzaW1wbGlmeWluZyBp cyBhIGdvb2QgaW1wcm92ZW1lbnQuIFdlIGhhdmUgbWFkZSB0aGUgZm9sbG93aW5nIGNoYW5nZXM6 IHNpZ25faW5mbyBpbiB0aGUgcmVxdWVzdCBpbXBsaWVzIHRoYXQgdGhlIGNsaWVudCB3YW50cyB0 byBrbm93IGVuY29kaW5nIG9mIHB1YiBrZXlzIHRvby4gUHViX2tleV9lbmMgaXMgYWx3YXlzIGlu Y2x1ZGVkIGluIHRoZSBzaWduX2luZm8gaW4gdGhlIHJlc3BvbnNlLCB3aXRoIHZhbHVlIG51bGwg aWYgdGhlIEtEQyBjYW7igJl0IHByb3ZpZGUgdGhhdCBpbmZvcm1hdGlvbi4gQXMgYSBjb25zZXF1 ZW5jZSwgd2UgZG8gbm90IG5lZWQgdG8gcmVnaXN0ZXIgdGhlIOKAnHB1Yl9rZXlfZW5j4oCdIHBh cmFtZXRlciBhcyBhIGFjZSBwYXJhbWV0ZXIuDQoNCiAgICAgKiBTZWN0aW9uIDMuMy4xIC0gVGhl IGZpcnN0IHBhcmFncmFwaCBpbXBsaWVzIHRoYXQgcHViX2tleV9lbmMgd291bGQgYmUgaW4NCiAg ICB0aGUgcmVwbHkgYnV0IGRvbid0IGhhdmUgYW55IGluZm9ybWF0aW9uIGFib3V0IHdoYXQgdGhh dCB3b3VsZCBsb29rIGxpa2UuDQogICAgU2VlIGFsc28gcHJldmlvdXMgaXRlbS4NCg0KRlA6IFNp bmNlIHdlIGltcGxlbWVudGVkIHRoZSBwcmV2aW91cyBjaGFuZ2UsIHdlIGRvIG5vdCBuZWVkIHRv IGhhdmUgYSBzZXBhcmF0ZSBzZWN0aW9uIGZvciBwdWJfa2V5X2VuYywgc2luY2UgaW4gcHJhY3Rp Y2UgIHRoYXQgcGFyYW1ldGVyIGlzIG5vdyBwYXJ0IG9mIHRoZSBzaWduX2luZm8gcGFyYW1ldGVy LCBhbmQgZGVmaW5lZCBpbiB0aGF0IHNlY3Rpb24uDQoNCiAgICAqIFNlY3Rpb24gMy4zLjMgLSBz LygoLygvDQoNCkZQOiBGaXhlZC4NCg0KICAgICogU2VjdGlvbiA0IC0gd2h5IGFyZSB5b3UgY2Fs bGluZyB0aGlzIHRoZSBmaXJzdCBleGNoYW5nZSB3aXRoIHRoZSBLREMgLSB3aG8NCiAgICB3YXMg SSB0YWxraW5nIHRvIGluIHNlY3Rpb24gMz8NCg0KRlA6IFRoZSByZWFzb24gZm9yIGNhbGxpbmcg aXQg4oCcdGhlIGZpcnN0IGV4Y2hhbmdl4oCdIHdhcyB0byBoaWdobGlnaHQgdGhlIGZhY3QgdGhh dCB0aGUgam9pbmluZyBwcm9jZXNzIGhhcHBlbnMgZmlyc3QsIGFuZCBtb3JlIHJlcXVlc3RzIGNh biBmb2xsb3cgd2l0aCBkaWZmZXJlbnQgZ29hbHMgKHVwZGF0ZSBvZiBrZXlzIGV0YykuIFdlIGhh dmUgbm93IGNsYXJpZmllZCB0aGF0IHRoaXMgaXMgdGhlIOKAnGZpcnN0IGV4Y2hhbmdlIGFmdGVy IHBvc3RpbmcgdGhlIFRva2Vu4oCdLg0KDQogICAgKiBTZWN0aW9uICA0IC0gYXJlIHRoZSBwb2xp Y2llcyBuZXcgb3IganVzdCByZXRyaWV2ZWQ/ICBNYXkgd2FudCB0byBzd2FwDQogICAgb3JkZXIu DQoNCkZQOiBSaWdodCwganVzdCByZXRyaWV2ZWQuIEZpeGVkIHRoZSBvcmRlci4NCg0KICAgICog U2VjdGlvbiA0IC0gYXJlIHdlIHN0aWxsIHNwZWNpZnlpbmcgYSBncm91cCB0byBqb2luIG9yIGlz IHRoYXQgaW1wbGljaXQgaW4NCiAgICB0aGUgVVJMPyAgVGVsbCBtZSBob3cgaXQgaXMgc3BlY2lm aWVkPw0KDQpGUDogSXTigJlzIHNwZWNpZmllZCBpbiB0aGUg4oCYc2NvcGXigJkgb2YgdGhlIEpv aW5pbmcgUmVxdWVzdCwgYXMgdGhlIGdyb3VwIG5hbWUgaW4gdGhlIHNpbmdsZSBzY29wZV9lbnRy eSBmb3IgdGhhdCBKb2luaW5nIFJlcXVlc3QuIEkgdGhpbmsgaXTigJlzIGdvb2Qgbm90IHRvIG1h bmRhdGUgdGhhdCB0aGUgVVJJIHJlZmxlY3RzIHRoZSBncm91cCBuYW1lIGluIHRoZSBwYXRoICh0 aG91Z2ggaXQgbWFrZXMgc2Vuc2UgYW5kIHdlIGRvIGl0IGluIHRoZSBleGFtcGxlcykuDQoNCiAg ICAqIFNlY3Rpb24gNCAtIEkgZG9uJ3QgdGhpbmsgdGhhdCB0aGUgKHJlLSkgaXMgaGVscGluZyB1 bmRlcnN0YW5kaW5nIGhlcmUuDQoNCkZQOiAgVGhlIHBvaW50IHdlIHdlcmUgdHJ5aW5nIHRvIG1h a2UgY2xlYXIgd2l0aCB0aGF0IChyZS0pIGlzIHRoYXQgaXQgY2FuIGJlIHVzZWQgdG8gcmV0cmll dmUgdGhvc2Ugc2V2ZXJhbCBmb2xsb3dpbmcgdGltZXMsIG5vdCBvbmx5IG9uY2UuIEJ1dCBJIGRv buKAmXQga25vdyBob3cgdG8gZXhwcmVzcyB0aGF0IGNsZWFybHksIGFuZCBzaW5jZSB0aGF0IGRv ZXMgbm90IGhlbHAgdW5kZXJzdGFuZGluZyB3ZSBoYXZlIHJlbW92ZWQgdGhlbS4NCg0KICAgICog U2VjdGlvbiAgNCAtIHdoYXQgdHlwZSBvZiBpbmRpdmlkdWFsIGtleSBpcyBiZWluZyBvYnRhaW5l ZCBpbiBidWxsZXQgMiAtDQogICAgaG93IGlzIHRoaXMgZGlmZmVyZW50IHRoYW4gZ2V0dGluZyB0 aGUgY3VycmVudCBrZXlpbmcgbWF0ZXJpYWw/DQoNCkZQOiBUaGUgaW5kaXZpZHVhbCBrZXkgaXMg dGhlIGVxdWl2YWxlbnQgb2YgdGhlIFNlbmRlciBLZXkgaW4gT1NDT1JFIChvciBpbnB1dCBtYXRl cmlhbCB0byBkZXJpdmUgaXQsIGkuZS4gdGhlIFNlbmRlciBJRCksIHZzIHRoZSBncm91cCBrZXlp bmcgbWF0ZXJpYWwgc3VjaCBhcyB0aGUgbWFzdGVyIHNlY3JldCwgbWFzdGVyIHNhbHQsIGNvbnRl eHQgaWQuIFRoZSBkaWZmZXJlbmNlIGlzIHRoYXQgdXNpbmcgYnVsbGV0IDIgb25seSB0aGUgcGVy c29uYWwgbm9kZeKAmXMga2V5aW5nIG1hdGVyaWFsIGlzIHVwZGF0ZWQsIG5vdCB0aGUgZ3JvdXAg a2V5aW5nIG1hdGVyaWFsLiBXZeKAmWQgd2VsY29tZSBwcm9wb3NhbHMgb24gaG93IHRvIGNsYXJp ZnkgaXQgd2l0aG91dCBnb2luZyBpbnRvIE9TQ09SRSBkZXRhaWxzLg0KDQogICAgKiBTZWN0aW9u ICA0IC0gV2hvIGlzIGVuZm9yY2luZyB0aGUgcG9saWNpZXM/ICBKdXN0IHJldHJpZXZlIHRoZSBw b2xpY2llcy4NCg0KRlA6IE9rLCBmaXhlZC4NCg0KICAgICogU2VjdGlvbiA0IC0gSSBkb24ndCB0 aGluayB0aGUgZS5nLiBpbiBnZXR0aW5nIHB1YmxpYyBrZXlzIHNlcnZlcyBhIHB1cnBvc2UNCiAg ICBoZXJlLg0KDQpGUDogT2ssIGZpeGVkLg0KDQogICAgKiBTZWN0aW9uIDQgLSBJIGFtIG5vdCBz dXJlIHdoYXQgdGhlICJhdCBoYW5kIiBpcyBzdXBwb3NlZCB0byBiZSBwcm92aWRpbmcuDQogICAg L2ZvciB0aGUgcmVxdWVzdGVkIGdyb3VwIGlkZW50aWZpZXIvDQoNCkZQOiBPaywgZml4ZWQuDQoN CiAgICAqIFNlY3Rpb24gIDQuMSAtIGRvIHdlIHdhbnQgdG8gbWFrZSB0aGUgaWYgdmFsdWUgYmUg YSBkb3QgdHJlZT8gIGFjZS5ncm91cA0KDQpGUDogT2ssIGNoYW5nZWQgdG8gYWNlLmdyb3VwLg0K DQogICAgKiBTZWN0aW9uIDQuMSAtIFRoZSBidWxsZXQgZm9yIC9hY2UtZ3JvdXAgc2VlbXMgdG8g aW5kaWNhdGUgdGhhdCB0aGUgbmFtZSBpcw0KICAgIGZpeGVkIHdoaWNoIGlzIHRoZSBvcHBvc2l0 ZSBvZiB3aGF0IHRoZSBwcmV2aW91cyBwYXJhZ3JhcGggc2F5cy4gIEkgZmluZA0KICAgIHRoaXMg Y29uZnVzaW5nLiAgSSByZWFsbHkgZmluZCBpdCBjb25mdXNpbmcgdGhhdCB0aGlzIGRvY3VtZW50 IGlzIHNwZWNpZnlpbmcNCiAgICBhIHVybC1wYXRoIG5hbWUgaXMgYmVpbmcgc3BlY2lmaWVkLCBh bmQgdGhlIG9zY29yZSBkb2N1bWVudCBpbW1lZGlhdGVseSB1c2VzDQogICAgYSBkaWZmZXJlbnQg dmFsdWUuDQoNCkZQOiAgVGhlIHBhcnQgYWJvdXQg4oCcZml4ZWTigJ0gd2FzIG1lYW50IHRvIHNh eSB0aGF0IG9uY2UgZGVmaW5lZCBpdCB3aWxsIG5vdCBjaGFuZ2UsIHdoYXRldmVyIHRoZSBhcHBs aWNhdGlvbiBwcm9maWxlcyBkZWZpbmUgdG8gdXNlLCBlaXRoZXIgdGhlIGRlZmF1bHQgb3Igb3Ro ZXIsIG9wcG9zZWQgdG8gdGhlIC9hY2UtZ3JvdXAvR1JPVVBOQU1FIGZvciBleGFtcGxlLCB3aGlj aCBoYXZlIGEgdmFyaWFibGUgcGFydC4gU2luY2UgdGhhdCB3YXMgbm90IGNsZWFyLCBhbmQgbm90 IHRvIG1ha2UgaXQgaW5jb25zaXN0ZW50LCB3ZSBoYXZlIHJlbW92ZWQgdGhlIHRlcm0gZml4ZWQu DQpBYm91dCBPU0NPUkUgdXNpbmcgYSBkaWZmZXJlbnQgcmVzb3VyY2UgbmFtZTogc2hvdWxkIHdl IHRoZW4gc3BlY2lmeSBhcyBhIHJlcXVpcmVtZW50IHRoYXQgdGhlIHByb2ZpbGVzIE1VU1Qgc2V0 IHRoZSByb290IHVyaS1wYXRoLCByYXRoZXIgdGhhbiBwcm92aWRpbmcgYSBkZWZhdWx0Pw0KDQog ICAgKiBTZWN0aW9uIDQuMSAtIHdoYXQgZG9lcyBpdCBtZWFuIGZvciBhIHN1Yi1yZXNvdXJjZSB0 byBiZSAiZml4ZWQiLiAgRG9lcw0KICAgIHRoYXQgbWVhbiBpdCBuZXZlciBjaGFuZ2VzPw0KDQpG UDogU2VlIHByZXZpb3VzIGFuc3dlci4gWWVzIGl0IG1lYW5zIHRoYXQgb25jZSBkZWZpbmVkIGl0 IGRvZXMgbm90IGNoYW5nZSBkZXBlbmRpbmcgb24gb3RoZXIgcGFyYW1ldGVycyAoc3VjaCBhcyBH Uk9VUE5BTUUgb3IgTk9ERU5BTUUpLiBXZSBoYXZlIHJlbW92ZWQgaXQgbm93IGFzIGl0IHdhcyBu b3QgY2xlYXIuDQoNCiAgICAqIFNlY3Rpb24gNC4xIC0gYSBicmllZiBkZXNjcmlwdGlvbiBvZiB3 aGF0IGlzIGluIHRoZSByZXNvdXJjZSB3b3VsZCBiZQ0KICAgIGhlbHBmdWwgaGVyZS4gICJwdWIt a2V5OiB0aGlzIHJlc291cmNlIGNvbnRhaW5zIHRoZSBwdWJsaWMga2V5cyBvZiBhbGwgZ3JvdXAN CiAgICBtZW1iZXJzLiAgVGhlIHJlc291cmNlIHN1cHBvcnRzIHRoZSBHRVQgYW5kIEZFVENIIG1l dGhvZHMuIg0KDQpGUDogT2ssIHdlIGhhdmUgYWRkZWQgc29tZSB0ZXh0IGFib3V0IHRoYXQuDQoN CiAgICAqIFNlY3Rpb24gNC4xIC0gWWVzIGJ1dCB3aGF0IGlzIGEgTk9ERU5BTUUgYW5kIHdoeSBk byBJIGNhcmUgYWJvdXQgaXQ/DQoNCkZQOiBIb3BlZnVsbHkgYWRkaW5nIHRoZSBmb2xsb3dpbmcg 4oCcRWFjaCByZXNvdXJjZSBjb250YWlucyB0aGUgaW5kaXZpZHVhbCBrZXlpbmcgbWF0ZXJpYWwg Zm9yIHRoYXQgbm9kZS4g4oCcIGdpdmVzIGFuIGludHVpdGlvbiB3aHkgdGhlIE5PREVOQU1FIGlz IHVzZWQuIFRoZSBmYWN0IHRoYXQgaXQgaXMgYSBub2RlIGlkZW50aWZpZXIgc2hvdWxkIGJlIGNs ZWFyIGJ5IHRoZSBmb2xsb3dpbmcgc2VudGVuY2U6IOKAnCBUaGVzZSByZXNvdXJjZXMgYXJlIGlk ZW50aWZpZWQgYnkgdGhlIG5vZGUgbmFtZSAoaW4gdGhpcyBleGFtcGxlLCB0aGUgbm9kZSBuYW1l IGhhcyB2YWx1ZSAiTk9ERU5BTUUiKeKAnSBNb3JlIGRldGFpbHMgYWJvdXQgaG93IHByZWNpc2Vs eSBOT0RFTkFNRSBpcyB1c2VkIHRvIHZlcmlmeSB0aGUgcmVxdWVzdCBhcmUgZ2l2ZW4gaW4gNC4x LjIuMSwgYnV0IHdlIG9ubHkgd2FudCB0byB0YWxrIGFib3V0IGl0IGhpZ2ggbGV2ZWwgaGVyZS4N Cg0KICAgICogU2VjdGlvbiA0LjEuMi4xIC0gSXQgd291bGQgYmUgdXNlZnVsIGluIHRoZSBmaXJz dCBwYXJhZ3JhcGggdG8gcmUtaXRlcmF0ZQ0KICAgIHRoYXQgdGhpcyBpcyB0aGUgImpvaW4iIG9w ZXJhdGlvbiAgVGhlIGN1cnJlbnQgZGVzY3JpcHRpb24gc2VlbXMgdG8gYmUNCiAgICByZWFsbHkg b2RkLg0KDQpGUDogT2ssIEkgYWRkZWQgYSBub3RlIGFib3V0IHRoYXQuIFRoZSBpZGVhIHdhcyB0 aGF0IHRoaXMgc2VjdGlvbiBpcyByZWFsbHkgYWJvdXQgdGhlIGhhbmRsZXIsIGFuZCB0aGUgam9p bmluZyBpcyBkZXNjcmliZWQgdXNpbmcgdGhpcyBoYW5kbGVyIGxhdGVyIG9uLCBpbiBzZWN0aW9u IDQuMi4NCg0KICAgICogU2VjdGlvbiA0LjEuMi4xIC0gZ2V0X3B1Yl9rZXlzIC0gT25lIGNvbnNp ZGVyYXRpb24gdGhhdCBuZWVkcyB0byBiZQ0KICAgIGhpZ2hsaWdodGVkIGZvciBhIGNvbnN0cmFp bmVkIGRldmljZSBpcyB0aGF0IHRoaXMgbWF5IHJlc3VsdCBpbiBhIGxhcmdlDQogICAgcmV0dXJu IHZhbHVlIGFuZCBpdCBtYXkgYmUgYmV0dGVyIHRvIGdldCB0aGVtIG9ubHkgYXMgbmVlZGVkLg0K DQpGUDogT2ssIGFkZGVkIHRoZSBmb2xsb3dpbmcgc2VudGVuY2U6IOKAnE5vdGUgdGhhdCBpbmNs dWRpbmcgdGhpcyBwYXJhbWV0ZXIgbWF5IHJlc3VsdCBpbiBhIGxhcmdlIG1lc3NhZ2Ugc2l6ZSBm b3IgdGhlIGZvbGxvd2luZyByZXNwb25zZSwgd2hpY2ggY2FuIGJlIGluY29udmVuaWVudCBmb3Ig cmVzb3VyY2UtY29uc3RyYWluZWQgZGV2aWNlcy7igJ0gQW55dGhpbmcgbW9yZSB3ZSBuZWVkIHRv IGFkZD8NCg0KICAgICogU2VjdGlvbiA0LjEuMi4xIC0gSXQgd291bGQgYmUgbmljZSB0byBiZSBh YmxlIHRvIHVzZSBnZXRfcHViX2tleXMgd2l0aCBhDQogICAgZmlsdGVyIHNvIHRoYXQgb25seSBy ZXNwb25kZXJzIGFyZSByZXR1cm5lZC4NCg0KRlA6IE9rLCB3ZSBoYXZlIG1vdmVkIHRoZSBmb3Jt YXQgb2YgZ2V0X3B1Yl9rZXlzIHRoYXQgd2FzIHVzZWQgaW4gdGhlIC9wdWIta2V5IHJlc291cmNl LCBhbmQgdXNlIHRoYXQgaW4gdGhlIGpvaW4gYXMgd2VsbC4gV2UgaGF2ZSBhbHNvIGNsYXJpZmll ZCB3aGF0IGlkIGFuZCByb2xlIGFyZSB1c2VkIGZvci4NCg0KICAgICogU2VjdGlvbiA0LjEuMi4x IC0gJ2NsaWVudF9jcmVkJyB0aGUgZGVzY3JpcHRpb24gb2Ygd2hlbiB0aGlzIGZpZWxkIGlzIHVz ZWQNCiAgICBkb2VzIG5vdCBzZWVtIHRvIGluY2x1ZGUgYSBzZXJ2ZXIgd2hpY2ggb25seSByZXNw b25kcyB0byBhbiBpbmRpdmlkdWFsLiBJdA0KICAgIGNvdWxkIGJlIHNhaWQgaW4gdGhhdCBjYXNl IHRoYXQgaXQgaXMgbm90IHNlbmRpbmcgbWVzc2FnZXMgInRvIHRoZSBncm91cCINCiAgICBidXQg b25seSB0byBhIG1lbWJlciBvZiB0aGUgZ3JvdXAuDQoNCkZQOiBPaywgcmVwaHJhc2VkIGluIOKA nHRvIG9uZSBvciBtb3JlIGdyb3VwIG1lbWJlcnPigJ0uDQoNCiAgICAqIFNlY3Rpb24gNC4xLjIu MSAtICdjb25jZScgd2h5IGJvdGhlciBwb2ludGluZyB0byBBQ0UgZm9yIGEgZGVzY3JpcHRpb24g b2YNCiAgICB0aGlzIGRvY3VtZW50LiAgVGhpcyBpcyBub3QgYSBmcmFtZXdvcmsgbWVzc2FnZSBz byBJIGFtIG5vdCBzdXJlIHdoeSB0aGlzIGlzDQogICAgaW50ZXJlc3RpbmcuDQoNCkZQOiBXZSBk byB0aGF0IHRvIHBvaW50IHRoZSByZWFkZXIgb24gd2hlcmUgdG8gZmluZCB0aGUgZW5jb2Rpbmcg KHdoaWNoIGlzIHRoZSBzYW1lIGFzIGluIEFjZSkuDQoNCiAgICAqIFNlY3Rpb24gNC4xLjIuMSAt IFdoaWNoIHNjb3BlIGlzIGJlaW5nIHVzZWQsIHRoZSBvbmUgaW4gdGhpcyBtZXNzYWdlDQogICAg KGFzc3VtaW5nIGl0IGV4aXN0cykgb3IgdGhlIG9uZSBpbiB0aGUgdG9rZW4/ICBJZiB0aGUgbWVz c2FnZSBkb2VzIG5vdCBoYXZlDQogICAgb25lIHRoZW4gd2hhdCBoYXBwZW5zPyAgRGV0ZXJtaW5p c3RpYyBlbmNvZGluZz8NCg0KRlA6IEJ5IOKAnHVzZWTigJ0gSSBhc3N1bWUgeW91IG1lYW4gYnkg dGhlIEtEQz8gVGhlIEtEQyBleHRyYWN0IHRoZSBncmFudGVkIHNjb3BlIGZyb20gdGhlIFRva2Vu LCBhbmQgY2hlY2tzIHRoaXMgcmVxdWVzdGVkIG9uZSBhZ2FpbnN0IHRoZSB0b2tlbiBvbmUuIElm IHRoaXMgam9pbiBtZXNzYWdlIGRvZXMgbm90IGhhdmUgb25lIHdlIGFyZSBpbiB0aGUgY2FzZSB3 aGVyZSB0aGUgS0RDIHVuZGVyc3RhbmRzIHdoaWNoIGdyb3VwIGFuZCByb2xlIHRoZSBDbGllbnQg aXMgcmVxdWVzdGluZyAoc2F5IHRoZXJlIGlzIG9ubHkgb25lIHRoYXQgdGhlIGNsaWVudCBoYXMg YmVlbiBncmFudGVkKS4gV2hhdCBhcmUgd2UgbWlzc2luZz8NCg0KICAgICogU2VjdGlvbiA0LjEu Mi4xIC0gcy90b2tlbiBpcyBub3QgYmVpbmcgcG9zdGVkL3Rva2VuIHdhcyBub3QgcG9zdGVkLw0K DQpGUDogT2ssIGZpeGVkLg0KDQogICAgKiBTZWN0aW9uIDQuMS4yLjEgLSBmb3JtYXR0aW5nIC0g dGhlIGZvbGxvdyBvbiBwYXJhZ3JhcGggdG8NCiAgICAnY2xpZW50X2NyZWRfdmVyaWZ5JyBzaG91 bGQgYmUgaW5kZW50ZWQgYSBsZXZlbA0KDQpGUDogT2ssIGZpeGVkLg0KDQogICAgKiBTZWN0aW9u IDQuMS4yLjEgLSBZb3UgbWlzc2VkIHRoZSBtZXJnZSBvZiBzaWduX2luZm8gYW5kIHB1Yl9rZXlf ZW5jIGluIHRoZQ0KICAgIGVycm9yIGhhbmRsaW5nIHBhcmFncmFwaC4NCg0KRlA6IEkgdGhpbmsg dGhpcyBzaG91bGQgYmUgZml4ZWQgd2l0aCB0aGUgcHJldmlvdXMgbW9kaWZpY2F0aW9ucyBvZiBz aWduX2luZm8gYW5kIHB1Yl9rZXlfZW5jLCBidXQgaWYgaXTigJlzIG5vdCBwbGVhc2UgbGV0IHVz IGtub3cuDQoNCiAgICAqIFNlY3Rpb24gNC4xLjIuMSAtIFdoYXQgaXMgdGhlIHJlYXNvbmluZyBi ZWhpbmQgcmV0dXJuaW5nIHRoZSBzaWduX2luZm9fcmVzDQogICAgZmllbGQgaWYgdGhlIGdyb3Vw IGlzIG5vdCBpbiB0aGUgc2NvcGUuICBUaGlzIGlzIG5vdCByZWxhdGVkIHRvIHRoZSBmYWlsdXJl DQogICAgaW4gYW55IHdheS4gIFNlZW1zIG1vcmUgbGlrZSB0aGlzIHdvdWxkIHJldHVybiBhIHBv aW50ZXIgdG8gdGhlIEFTIHJhdGhlcg0KICAgIHRoYW4gYW55dGhpbmcgZWxzZS4NCg0KRlA6IFRo ZSByZWFzb25pbmcgd2FzIHRoYXQgd2Ugd2FudGVkIHRvIHNheTog4oCcaWYgdmVyaWZpY2F0aW9u IGZhaWxzLCByZXR1cm4gdGhlIHNhbWUgZXJyb3IgYXMgdGhlIFRva2VuIHBvc3QgZXJyb3LigJ0u IEJ1dCBpdOKAmXMgdHJ1ZSBpdCBkb2VzIG5vdCBtYWtlIHNlbnNlIHRvIHJldHVybiBzaWduX2lu Zm8gaGVyZS4gV2UgaGF2ZSBtb2RpZmllZCB0aGlzIHRvIE1BWSByZXR1cm4gQVMgQ3JlYXRpb24g SGludHMgbWVzc2FnZSwgYXMgZGVmaW5lZCBpbiBBY2UuDQoNCiAgICAqIFNlY3Rpb24gNC4xLjIu MSAtIEhvdyBtdWNoIGNhbiBJIGp1c3QgaWdub3JlIHJhdGhlciB0aGFuIGVycm9yPyAgSWYgeW91 DQogICAgc2VuZCBtZSBhIHB1YmxpYyBrZXkgYW5kIEkgZG9uJ3QgY2FyZSBhYm91dCBpdCB3aHkg Y2FuIEkgbm90IGp1c3QgaWdub3JlDQogICAgdGhhdCBmYWN0IGFuZCBnbyBmb3J3YXJkPyAgSSBi b3RoIGFncmVlIGFuZCBkaXNhZ3JlZSB3aXRoIHRoZSBpZGVhIHRoYXQNCiAgICBlcnJvcmluZyBv biB1bmtub3duIGZpZWxkcyBpcyB0aGUgY29ycmVjdCB3YXkgdG8gcHJvY2VlZC4NCg0KRlA6IE9r LCB3ZSBoYXZlIGNoYW5nZWQgdGhhdCB0byDigJxpZiByZXF1aXJlZCBwYXJhbWV0ZXJzIGFyZSBu b3QgZm9ybWF0dGVkIGNvcnJlY3RseSwgZXJyb3IuIElmIHVua25vd24gb3Igbm9uLWV4cGVjdGVk IHBhcmFtZXRlcnMsIHRoZW4gaWdub3JlIGFuZCBjb250aW51ZSBwcm9jZXNzaW5n4oCdLg0KDQog ICAgKiBTZWN0aW9uIDQuMS4yLjEgL3N1Y2NlZC9zdWNjZWVkZWQvDQoNCkZQOiBPaywgZml4ZWQN Cg0KICAgICogU2VjdGlvbiA0LjEuMi4xIC0gKHBhcmEgYmVmb3JlIGJ1bGxldCkgSSBkb24ndCBs aWtlIHRoZSBpZGVhIHRoYXQgaWYgeW91DQogICAgc2VuZCBtZSBhIHB1YmxpYyBrZXksIEkgd291 bGQgdXNlIHRoZSBzdG9yZWQgb25lIGJlZm9yZSBsb29raW5nIGF0IHRoZSBvbmUNCiAgICB0aGF0 IGlzIGluIHRoZSBqb2luIG1lc3NhZ2UuICBUaGlzIHNlZW1zIHRvIGJlIGJhY2t3YXJkcyBiZWhh dmlvci4gIE5vdGUgdGhlDQogICAgcGFyYWdyYXBoIGZvbGxvd2luZyB0aGUgYnVsbGV0cyBpcyBz YXlpbmcgZXhhY3RseSB0aGUgb3Bwb3NpdGUgdGhpbmcgYSB0aGlzDQogICAgb25lIGlzLg0KDQpG UDogR29vZCBwb2ludCwgd2UgaGF2ZSBub3cgc3dhcHBlZCB0aGUgb3JkZXI6IGZpcnN0IGNoZWNr IGlmIGluIG1lc3NhZ2UsIGFuZCBwb3NzaWJseSBvdmVyd3JpdGUgdGhlIG9uZSBpbiBtZW1vcnku IElmIG5vdCBpbiBtZXNzYWdlLCBjaGVjayBleGlzdGluZyBhc3NvY2lhdGlvbi4gSWYgbm8gcHVi IGtleSBpcyBwcm92aWRlZCBvciByZXRyaWV2YWJsZSwgdGhlbiByZXNwb25kIHdpdGggNC4wMCBC YWQgUmVxdWVzdCBlcnJvciBtZXNzYWdlLg0KDQogICAgKiBTZWN0aW9uIDQuMS4yLjEgLSBJIGFt IG5vdCBjbGVhciBvbiB0aGUgZm9sbG93aW5nIHNpdHVhdGlvbjogIEtleSBQMSBpcw0KICAgIGFz c29jaWF0ZWQgd2l0aCBncm91cFgsICBJIGRvIGEgc2Vjb25kIGpvaW4gYW5kIHNlbmQga2V5IFAx IGJ1dCBoYXZlIGEgY3JlZA0KICAgIHZlcmlmeSB0aGF0IHdvdWxkIGZhaWwuICBBbSBJIGV4cGVj dGVkIHRvIGRldGVjdCB0aGlzIGFuZCBlcnJvciBvciBzYXkgdGhhdA0KICAgIGJlY2F1c2UgeW91 IGhhdmUgYWxyZWFkeSB2ZXJpZmllZCBQMSBpdCBkb2VzIG5vdCBtYXR0ZXI/DQoNCkZQOiBGb2xs b3dpbmcgdGhlIHByZXZpb3VzIHBvaW50LCB3ZSBoYXZlIGNsYXJpZmllZCB0aGF0IGluIHRoZSB0 ZXh0LCBpdCB3b3VsZCBmYWlsIGlmIHRoZSBjcmVkIHZlcmlmeSBmYWlscy4gQnV0IHdlIHdlbGNv bWUgbW9yZSBvcGluaW9ucyBvbiB0aGlzLg0KDQogICAgKiBTZWN0aW9uIDQuMS4yLjEgLSBib3Ro IGJ1bGxldHMgYXJlIHRhbGtpbmcgYWJvdXQgZmFpbGVkIHZlcmlmaWNhdGlvbiAtDQogICAga2ls bCB0aGUgcmVkdW5kYW5jeS4NCg0KRlA6IFllcywgYnV0IHRoZSBlcnJvciBwcm9jZXNzaW5nIGlz IGRpZmZlcmVudCBpbiB0aGUgMiBidWxsZXRzOiBpbiBjYXNlIHRoZSB2ZXJpZmljYXRpb24gZmFp bHMgYmVjYXVzZSBjbGllbnRfY3JlZF92ZXJpZnkgZmFpbHMsIHdlIHNwZWNpZnkgd2hhdCB0aGUg aGFuZGxlciBuZWVkcyB0byBkbyB3aXRoIHJlZ2FyZCB0byB0aGUga2RjY2hhbGxlbmdlLiBTbyBp dCBpcyBub3QgcmVhbGx5IHJlZHVuZGFudC4gV2UgaGF2ZW7igJl0IG1hZGUgYW55IGNoYW5nZXMs IGJ1dCBwbGVhc2UgbGV0IHVzIGtub3cgaWYgeW91IGhhdmUgaWRlYXMgb24gaG93IHRvIGltcHJv dmUuDQoNCiAgICAqIFNlY3Rpb24gNC4xLjIuMSAtICdudW0nIHRoZSBydWxlIG9uIHRoZSBpbml0 aWFsIHZhbHVlIG9mIG51bSBzaG91bGQgYmUgcHV0DQogICAgaW50byBhIHNlY3Rpb24gYWJvdXQg c2V0dGluZyB1cCBhIGdyb3VwIG5vdCBoZXJlLg0KDQpGUDogT2ssIHdlIGhhdmUgYWRkZWQgYSBy ZXF1aXJlbWVudCB0aGF0IGl0IGlzIHVwIHRvIHRoZSBhcHBsaWNhdGlvbiBwcm9maWxlIHRvIHNw ZWNpZnkgd2hhdCB0aGUgaW5pdGlhbCB2YWx1ZSBzaG91bGQgYmUuIEZvciBPU0NPUkUsIHRoaXMg Y2FuIGJlIGRlZmluZWQgaW4gZHJhZnQtdGlsb2NhLWFjZS1vc2NvcmUtZ20tYWRtaW4gYW5kIHJl ZmVyZW5jZWQgaW4gdGhlIHByb2ZpbGUuDQoNCiAgICAqIFNlY3Rpb24gNC4xLjIuMSAtICdudW0n IHZzICdjdHgtbnVtJyBzaG91bGQgYmUgaGFybW9uaXplZC4NCg0KRlA6IFRoZXkgd2VyZSBub3Qg dGhlIHNhbWUgdGhpbmcgKHVyaS1wYXRoIHZzIGFjZS1ncm91cGNvbW0gcGFyYW1ldGVyKSBzbyBp dCB3YXMgbm90IG5lY2Vzc2FyaWx5IHdyb25nIHRoYXQgdGhleSB3ZXJlIGRpZmZlcmVudC4gQnV0 IGZvciBjb25zaXN0ZW5jeSwgd2UgaGF2ZSBjaGFuZ2VkIHRoZSBjdHgtbnVtIGZvciBudW0uDQoN CiAgICAqIFNlY3Rpb24gNC4xLjIuMSAtIGV4cF9kZWx0YSBzaG91bGQgc3BlY2lmeSBhIGRlZmF1 bHQgaWYgaXQgaXMgbm90IGluIHRoZQ0KICAgIG1lc3NhZ2UuICBJIHRoZXJlIGEgcmVhc29uIHRo YXQgdGhpcyBpcyBub3QgYSBwb2xpY3kgZm9yIHRoZSBncm91cD8NCg0KRlA6IE9rLCB3ZSBoYXZl IG1vdmVkIHRoaXMgdG8gdGhlIHBvbGljaWVzLiBJdCBpcyB3b3J0aCBub3RpbmcgdGhvdWdoIHRo YXQgdGhlIGdyb3VwX3BvbGljaWVzIHBhcmFtZXRlciBpcyBvcHRpb25hbCAobWVhbmluZyB0aGUg S0RDIG1pZ2h0IG5vdCBzZW5kIHRoaXMgaW5mbyBpbiB0aGUgbWVzc2FnZSksIHdlIGhhdmUgZXhw bGljaXRseSBhZGRlZCB0aGF0IHRoZSBkZWZhdWx0IHZhbHVlcyBNVVNUIGJlIHNwZWNpZmllZCBi eSB0aGUgYXBwbGljYXRpb24gcHJvZmlsZXMuDQoNCiAgICAqIFNlY3Rpb24gNC4xLjIuMiAtIERp dHRvIHRvIGFib3ZlIG9uIHRoZSBmaWVsZCBiZWluZyByZXR1cm5lZCBpbiB0aGUgZXZlbnQNCiAg ICBvZiA0LjAxDQoNCkZQOiBZZXMsIHdlIGhhdmUgZG9uZSB0aGUgc2FtZSBtb2RpZmljYXRpb24g YXMgYWJvdmUuDQoNCiAgICAqIFNlY3Rpb24gNC4xLjIuMiAtIEkgZG9uJ3QgdW5kZXJzdGFuZCB0 aGUgbmVlZCBmb3IgJ2drdHknIGFzIHRoYXQgSSBzaG91bGQNCiAgICBrbm93IGZyb20gdGhlIGpv aW4gYW5kIGl0IHNob3VsZCBuZXZlciBjaGFuZ2UgaW4gdGhlIGxpZmUgb2YgdGhlIGdyb3VwLiAg SQ0KICAgIHdvdWxkIGFsc28gZXhwZWN0IHRoYXQgJ2V4cCcgaXMgc29tZXRoaW5nIHRoYXQgYXQg bGVhc3QgU0hPVUxEIGJlIGluY2x1ZGVkDQogICAgYXMgdGhhdCBkb2VzIGNoYW5nZSBhbmQgaXMg dXNlZnVsIHRvIGhhdmUuDQoNCkZQOiBPayBmb3IgZXhwLCB3ZSBjaGFuZ2VkIGl0IHRvIFNIT1VM RC4gQWJvdXQgZ2t0eSBpbiB0aGUgR0VUIHJlc3BvbnNlLCBpdCBhbGxvd3MgYSBub2RlIGFjdGlu ZyBhcyDigJxtb25pdG9y4oCdIHRvIG9ubHkgcmVxdWVzdCB0aGUgZ3JvdXAga2V5IGFuZCBnZXQg YWxsIHRoZSBpbmZvcm1hdGlvbiBpdCBuZWVkcyB3aXRob3V0IG5lZWRpbmcgdG8gZG8gdGhlIGZ1 bGwgUE9TVCwgZXNwZWNpYWxseSBpZiB0aGUgS0RDIG1haW50YWlucyB0aGUgcHViIGtleXMgYW5k IHdvdWxkIGZhaWwgaXRzIHJlcXVlc3QgaWYgaXQgZG9lcyBub3QgY29udGFpbiBhIHB1YiBrZXku IFdlIGNvdWxkIG1ha2UgZ2t0eSBvcHRpb25hbCBpbiB0aGUgcmVzcG9uc2UgdG8gR0VULCBidXQg SSB0aGluayB0aGF0IHdvdWxkIGp1c3QgYmUgbW9yZSBjb21wbGljYXRlZCAod2hlbiBkb2VzIHRo ZSBLREMgc2VuZHMgaXQ/IFdoZW4gbm90PykgSSBkb27igJl0IHRoaW5rIHRoZSBzYXZpbmcgMiBi eXRlcyBpcyBtb3RpdmF0aW9uIGVub3VnaCBmb3IgcmVtb3ZpbmcgaXQsIGdpdmVuIHRoYXQgd2Ug aGF2ZSBhIHJlYXNvbiBmb3IgaGF2aW5nIGl0Lg0KDQogICAgKiBTZWN0aW9uIDQuMS4yLjIgLSBJ cyB0aGUgJ2tleScgdmFsdWUgZXhwZWN0ZWQgdG8gYmUgbW9kaWZpZWQgZm9yIHRoZQ0KICAgIHJl cXVlc3Rlcj8NCg0KRlA6IFllcywg4oCYa2V54oCZIGNvbnRhaW5zIHRoZSBlcXVpdmFsZW50IG9m IHRoZSB3aG9sZSBPU0NPUkUgU2VjdXJpdHkgQ29udGV4dCBpbiB0aGUgT1NDT1JFIHByb2ZpbGUg b2YgdGhpcyBzcGVjLCBpbmNsdWRpbmcgdGhlIFNlbmRlciBJRCwgd2hpY2ggaXMgdW5pcXVlIHRv IHRoZSByZXF1ZXN0ZXIuIEFsc28gaWYgdGhlIEtEQyByZWtleXMgdGhlIGdyb3VwLCB0aGVuIOKA mGtleeKAmSBpcyB0aGUgbmV3IGtleWluZyBtYXRlcmlhbCBkaXN0cmlidXRlZCB3aXRoIHJla2V5 aW5nLg0KDQogICAgKiBTZWN0aW9uIDQuMS4zLjEgLSBXaGF0IGlzIHRoZSByZWFzb24gZm9yIGhh dmluZyBhIG1hcCBpbiB0aGlzIHJlcXVlc3QNCiAgICB0eXBlLiAgV2h5IG5vdCBqdXN0IGhhdmUg dGhlIGFycmF5IGl0c2VsZj8NCg0KRlA6IE1hcCBpbiB0aGlzIGNhc2UgaXMgbm90IHN0cmljdGx5 IG5lY2Vzc2FyeSBiZWNhdXNlIHdlIGRvbuKAmXQgaGF2ZSBvcHRpb25hbCBwYXJhbWV0ZXJzLCBi dXQgdG8ga2VlcCB0aGUgY29uc2lzdGVuY3kgd2l0aCBvdGhlciBtZXNzYWdlcyB0byB0aGUgcmVz dCBvZiB0aGUgaW50ZXJmYWNlIHdoZXJlIG1hcCBpcyBuZWNlc3NhcnkgYmVjYXVzZSBvZiBvcHRp b25hbCBwYXJhbWV0ZXJzLCBJIHdvdWxkIGtlZXAgdGhpcyBhcyBhIG1hcCB3aXRoIHRoZSBzYW1l IGNvbnRlbnQgZm9ybWF0Lg0KDQogICAgKiBTZWN0aW9uIDQuMS4zLjEgLSBMb29rcyBsaWtlIGEg Zm9ybWF0dGluZyBlcnJvciAyIHBhcmFncmFwaHMgYWZ0ZXIgZmlndXJlDQogICAgNw0KDQpGUDog UmlnaHQsIGZpeGVkLg0KDQogICAgKiBTZWN0aW9uIDQuMS4zLjEgLSBUaGUgdGV4dCBvbiB0aGUg Zmlyc3Qgc2VsZWN0aW9uIGNyaXRlcmlhIGhhcyBtZSByZWFsbHkNCiAgICBtZXNzZWQgdXAgYmVj YXVzZSBJIGFtIG5vdCBzdXJlIHRoYXQgDQoNCkZQOiBCcm9rZW4gY29tbWVudC4gQnV0IHdlIGhh dmUgYXNzdW1lZCB0aGlzIHdhcyBhYm91dCB0aGUgcGFyZW50aGVzaXMgKGluY2x1ZGluZyB0aGUg ZXhhY3QgY29tYmluYXRpb24gb2Ygcm9sZXMgcmVxdWVzdGVkKSBhbmQgaGF2ZSB0cmllZCB0byBy ZXBocmFzZSB0byBjbGFyaWZ5Lg0KDQogICAgKiBTZWN0aW9uIDQuMS4zLjEgLSBJZiBub3Qgc3Rv cmluZyBrZXlzLCBzaG91bGQgdGhpcyByZXR1cm4gZWl0aGVyIHJlc291cmNlDQogICAgbm90IGZv dW5kIG9yIG5vdCBzdXBwb3J0ZWQgYXMgYW4gZXJyb3IgY29kZSBpbnN0ZWFkIG9mIGFuIGVtcHR5 IHJlc3BvbnNlPw0KDQpGUDogR29vZCBwb2ludC4gV2UgaGF2ZSBhZGRlZCBhIHNlbnRlbmNlIHRo YXQgc3BlY2lmaWVzIHRoYXQgYW55IHJlcXVlc3QgcmV0dXJucyA0LjA1IE1ldGhvZCBOb3QgQWxs b3dlZCBpbiBjYXNlIHRoZSBLREMgZG9lcyBub3QgbWFpbnRhaW4ga2V5cy4gSHR0cCAoYW5kIHN1 YnNlcXVlbnRseSBDb0FQKSBkZWZpbmVzOiAiNDA1IE1ldGhvZCBOb3QgQWxsb3dlZCByZXNwb25z ZSBzdGF0dXMgY29kZSBpbmRpY2F0ZXMgdGhhdCB0aGUgcmVxdWVzdCBtZXRob2QgaXMga25vd24g YnkgdGhlIHNlcnZlciBidXQgaXMgbm90IHN1cHBvcnRlZCBieSB0aGUgdGFyZ2V0IHJlc291cmNl LiINCiBUaGUgTm90IGZvdW5kIGlzIGFub3RoZXIgb3B0aW9uIGlmIHdlIG1ha2UgdGhhdCByZXNv dXJjZSBlbmRwb2ludCBvcHRpb25hbCB0byBpbXBsZW1lbnQsIHdoaWNoIGlzIG5vdCB0aGUgY2Fz ZSByaWdodCBub3cuIFdlIHByZWZlciB0aGlzIG9wdGlvbiwgYnV0IGlmIHRoZSBXRyB0aGlua3Mg Tm90IEZvdW5kIGlzIGJldHRlciB3ZSBjYW4gZ28gZm9yIHRoYXQgdG9vLg0KDQogICAgKiBTZWN0 aW9uIDQuMS4zLjEgLSBzL3Jlc291cmNlIGhhbmRsZXJzIG9ubHkgdmVyaWZ5L3Jlc291cmNlIGhh bmRsZXIgb25seQ0KICAgIHZlcmlmaWVzLyAgVW5sZXNzIHlvdSBtb3ZlIGl0IHVwIG9uZSBsZXZl bC4NCg0KRlA6IE9rLCBmaXhlZC4NCg0KICAgICogU2VjdGlvbiA0LjEuNC4xIC0gY2FuIHdlIGdl dCByaWQgb2YgdGhlIG1hcD8NCg0KRlA6IEFnYWluLCBJ4oCZZCByYXRoZXIgbm90IGZvciB0aGUg c2FtZSByZWFzb25zIGFib3ZlLg0KDQogICAgKiBTZWN0aW9uIDQuMS42LjEgLSBJIGhhdmUgbm8g aWRlYSBmcm9tIHRoZSB0ZXh0IHdoeSBJIHdvdWxkIHVzZSB0aGlzDQogICAgbWV0aG9kLg0KDQpG UDogSXTigJlzIGRpZmZpY3VsdCB0byBnaXZlIGEgY2xlYXJlciBpZGVhIGF2b2lkaW5nIHByb2Zp bGUtc3BlY2lmaWMgZGV0YWlscy4gV291bGQgaXQgaGVscCB0byBoYXZlIGFuIGluZm9ybWF0aW9u YWwgcmVmZXJlbmNlIHRvIGtleSBncm91cGNvbW0gb3Njb3JlIHRvIGdpdmUgYW4gZXhhbXBsZT8g KEnigJlkIHJhdGhlciBhdm9pZCB0aGUgY2lyY3VsYXIgZGVwZW5kZW5jeSwgc28gaWYgeW91IGhh dmUgb3RoZXIgaWRlYXMgb24gaG93IHRvIGltcHJvdmUsIEnigJlsbCB0YWtlIHRoZW0pLg0KDQog ICAgKiBTZWN0aW9uIDQuMS42LjMgLSBwYXJhIDIgLSB0aGUgZmlyc3Qgc2VudGVuY2UgZG9lcyBu b3QgbWFrZSBhbnkgc2Vuc2UgdG8NCiAgICBtZS4gIEhvdyBjb3VsZCB0aGUgaGFuZGxlciBhY2Nl cHQgYSByZXF1ZXN0IGZvciBhIG5vZGUgZG9lcyBub3QgbWF0Y2gNCiAgICAiTk9ERU5BTUUiIGFz IHRoYXQgaXMgdGhlIHVybC1wYXRoPw0KDQpGUDogVGhlIHBvaW50IGlzIHRoYXQgdGhlIEtEQyBN VVNUIE5PVCBhY2NlcHQgYSByZXF1ZXN0IGZyb20gYSBub2RlIE4xIHNlbmRpbmcgYSBERUxFVEUg dG8gYWNlLWdyb3VwL0dST1VQTkFNRS9ub2Rlcy9OMi5UaGUgS0RDIGNhbiBpZGVudGlmeSB0aGUg bm9kZSBuYW1lIGZyb20gdGhlIHNlY3VyZSBzZXNzaW9uIGl0IGhhcyBzZXQgdXAgd2l0aCBpdCAo aXQgaGFzIGdpdmVuIHRoZSBub2RlIGEgbmFtZSBhbmQgYXNzb2NpYXRlZCBpdCB0byB0aGUgc2Vj dXJlIGNoYW5uZWwgb25jZSB0aGUgbm9kZSBoYXMgZG9uZSB0aGUgam9pbiBwcm9jZXNzKS4gV2Ug aGF2ZSB0cmllZCB0byByZWZvcm11bGF0ZSB0byBjbGFyaWZ5Lg0KDQogICAgKiBTZWN0aW9uIDQu MiAtICJyZXRyaWV2ZSBpbmRpdmlkdWFsIG9yIGdyb3VwIGtleWluZyBtYXRlcmlhbCIgIFdoYXQN CiAgICBpbmRpdmlkdWFsIG1hdGVyaWFsPw0KDQpGUDogU2FtZSBhbnN3ZXIgYXMgYmVmb3JlOiB0 aGlzIGNvdWxkIGJlIGZvciBleGFtcGxlIHRoZSBzZW5kZXIgSUQgdG8gZGVyaXZlIHRoZSBTZW5k ZXIgS2V5IGluIE9TQ09SRS4gSXTigJlzIGRpZmZpY3VsdCB0byBnaXZlIGEgY2xlYXJlciBpZGVh IGF2b2lkaW5nIHByb2ZpbGUtc3BlY2lmaWMgZGV0YWlscy4gV291bGQgaXQgaGVscCB0byBoYXZl IGFuIGluZm9ybWF0aW9uYWwgcmVmZXJlbmNlIHRvIGtleSBncm91cGNvbW0gb3Njb3JlIHRvIGdp dmUgYW4gZXhhbXBsZT8gKEnigJlkIHJhdGhlciBhdm9pZCB0aGUgY2lyY3VsYXIgZGVwZW5kZW5j eSwgc28gaWYgeW91IGhhdmUgb3RoZXIgaWRlYXMgb24gaG93IHRvIGltcHJvdmUsIEnigJlsbCB0 YWtlIHRoZW0pLg0KDQogICAgKiBTZWN0aW9uIDQuMyAtIC90YXJnZXQgdGhlIFVSSSBwYXRoIHBv c3NpYmx5IHByb3ZpZGVkIGJ5LyBUaGlzIHRleHQgZWl0aGVyDQogICAgbmVlZHMgdG8gYmUgYSBk ZWZpbml0aXZlIG1ldGhvZCBvciBzb21lIHR5cGUgb2YgYWx0ZXJuYXRpdmUgbWV0aG9kIG5lZWRz IHRvDQogICAgYmUgcHJvdmlkZWQuDQoNCkZQOiBPaywgdGhpcyB3YXMgYW4gZWRpdG9yaWFsIG1p c3Rha2UsIGFzIHdlIGluY2x1ZGVkIOKAnHBvc3NpYmx54oCdIGJlY2F1c2UgdGhpcyBtZXRob2Qg b2Yga2V5aW5nIG1hdGVyaWFsIGRpc3RyaWJ1dGlvbiBpcyBhbiBvcHRpb25hbCBtZXRob2QsIGFu ZCB0aGUgY29udHJvbF9wYXRoIGlzIGluIGdlbmVyYWwgb3B0aW9uYWwuIEJ1dCBpZiB0aGlzIG1l dGhvZCBpcyB1c2VkLCB0aGVuIHllcyB0aGUgY29udHJvbF9wYXRoIGlzIG5vdCBvcHRpb25hbC4g V2UgaGF2ZSByZW1vdmVkIOKAnHBvc3NpYmx54oCdLg0KDQogICAgKiBTZWN0aW9uIDQuMyAtIEkg YW0gd29ycmllZCBhYm91dCBjb25nZXN0aW9uIGluIG1vcmUgcGxhY2VzIHRoYW4ganVzdCBmb3IN CiAgICBPYnNlcnZlLiAgSWYgYSBzZXJ2ZXIgaXMgc2VuZGluZyBsb3RzIG9mIG1lc3NhZ2VzIG91 dCB0byBjbGllbnRzIG9uIGENCiAgICBvbmUtdG8tb25lIGJhc2lzIGl0IGNvdWxkIGVhc2lseSBm bG9vZCB0aGUgbmV0d29yay4NCg0KRlA6IFdlIGhhZCBhZGRlZCBzb21lIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb25zIGFib3V0IGl0LCByZWZlcmVuY2luZyB0byBTZWN0aW9uIDQuNyBvZiA3MjUyLiBO b3cgd2UgYWRkZWQgdGhpcyByZWZlcmVuY2UgaW4gdGhpcyBzZWN0aW9uIGFzIHdlbGwuIElzIHRo YXQgZW5vdWdoIG9yIHdoYXQgaXMgbWlzc2luZz8NCg0KICAgICogU2VjdGlvbiA0LjQgLSBXaGF0 IGRvZXMgdGhlIGZpcnN0IHNlbnRlbmNlIGV2ZW4gbWVhbj8gIEl0IHNlZW1zIHRvIGJlDQogICAg YWxtb3N0IGEgY2lyY3VsYXIgYXJndW1lbnQuICANCg0KRlA6IFRyaWVkIHJlcGhyYXNpbmcgYXMg Zm9sbG93czog4oCcQmVzaWRlIHBvc3NpYmxlIGV4cGlyYXRpb24sIHRoZSBjbGllbnQgbWF5IG5l ZWQgdG8gY29tbXVuaWNhdGUgdG8gdGhlIEtEQyBpdHMgbmVlZCBmb3IgcGFydCBvZiB0aGUga2V5 aW5nIG1hdGVyaWFsIHRvIGJlIHJlbmV3ZWQuIOKAnCBMZXQgdXMga25vdyBpZiB0aGlzIGlzIHN0 aWxsIHVuY2xlYXIuDQoNCiAgICAqIFNlY3Rpb24gNC40IC0gSSBmaW5kIHRoZSB0aXRsZSBvZiA0 LjQgdG8gYmUgc29tZXdoYXQgbWlzbGVhZGluZy4gIEFzIGZhcg0KICAgIGFzIEkgY2FuIHRlbGwg dGhpcyBpcyBvbmx5IHRhbGtpbmcgYWJvdXQgb25lIHR5cGUgb2YgcmVuZXdhbCwgYnV0IGV2ZW4g dGhhdA0KICAgIGlzIG5vdCBjbGVhciB0byBtZS4NCg0KRlA6IE9rLCB3ZSB0cmllZCBjaGFuZ2lu ZyB0byDigJxSZXRyaWV2YWwgb2YgTmV3IEluZGl2aWR1YWwgS2V5aW5nIE1hdGVyaWFs4oCdIElz IHRoaXMgYmV0dGVyPw0KDQogICAgKiBTZWN0aW9uIDQuNCAtIFdoeSB3b3VsZCBpdCByZXF1aXJl IGFuIGVycm9yIGluIHRoZSBldmVudCB0aGF0IGEgZnVsbCByZWtleQ0KICAgIGlzIGdvaW5nIHRv IGJlIGRvbmUgYnkgdGhlIHNlcnZlciwgY2FuJ3QgaXQganVzdCBkbyB0aGUgZnVsbCByZW5ld2Fs IGFuZA0KICAgIHJldHVybiB0aGUgYW5zd2VyIHRvIHRoZSBQVVQ/DQoNCkZQOiBPaywgd2UgaGF2 ZSByZXBocmFzZWQgdG8gZXhwcmVzcyB0aGF0LiBXZSBoYXZlIGtlcHQgdGhlIHBvc3NpYmlsaXR5 IHRvIHBlcmZvcm0gdGhlIHJla2V5IGJlZm9yZSBvciBhZnRlciByZXBseWluZywgc28gdGhhdCBp dCBpcyB1cCB0byB0aGUgYXBwbGljYXRpb24gcHJvZmlsZSB0byBkZWZpbmUgdGhhdDoNCk9MRDoN CkZ1cnRoZXJtb3JlLCBwb2xpY2llcyBjYW4gYmUgc2V0IHVwIHNvIHRoYXQsIHVwb24gcmVjZWl2 aW5nIGEgS2V5IFJlbmV3YWwgUmVxdWVzdCwgdGhlIEtEQyByZXBsaWVzIHRvIHRoZSBjbGllbnQg d2l0aCBhbiBlcnJvciByZXNwb25zZSwgYW5kIHRoZW4gcGVyZm9ybXMgYSBjb21wbGV0ZSBncm91 cCByZWtleWluZyAoT1BUOCkuDQpORVc6DQpGdXJ0aGVybW9yZSwgcG9saWNpZXMgY2FuIGJlIHNl dCB1cCBzbyB0aGF0LCB1cG9uIHJlY2VpdmluZyBhIEtleSBSZW5ld2FsIFJlcXVlc3QsIHRoZSBL REMgcGVyZm9ybXMgYSBjb21wbGV0ZSBncm91cCByZWtleWluZyBiZWZvcmUgb3IgYWZ0ZXIgcmVw bHlpbmcgdG8gdGhlIGNsaWVudCAoT1BUOCkuDQoNCiAgICAqIFNlY3Rpb24gNC41IC0gSXMgdGhl IHNlY29uZCBwYXJhZ3JhcGggaW4gdGhlIHdyb25nIHBsYWNlPyAgSSBkb24ndCByZWFsbHkNCiAg ICBjYXJlIHdoYXQgdGhlIGNsaWVudCBkb2VzIG9ubHkgd2hhdCB0aGUgc2VydmVyIGRvZXMuDQoN CkZQOiBXaHk/IEl0IGlzIGltcG9ydGFudCB0aGF0IHRoZSBjbGllbnQgcHJvY2Vzc2VzIHRoZSBy ZXNwb25zZSBjb3JyZWN0bHkuIEl0IG1ha2VzIHNlbnNlIHRoaXMgd291bGQgbm90IGJlIGluIHRo ZSDigJxoYW5kbGVy4oCdIHNlY3Rpb24sIGJ1dCBoZXJlIHdlIHRoaW5rIHdlIHNob3VsZCBoYXZl IHRoaXMgdHlwZSBvZiBkZXRhaWxzLiBXb3VsZCBpdCBiZSBiZXR0ZXIgdG8gaGF2ZSB0aGlzIHBh cmFncmFwaCBhZnRlciB0aGUgZmlndXJlPw0KDQogICAgKiBTZWN0aW9uIDQuNiAtIC9BZnRlciBk aXN0cmlidXRpbmcgdGhlIG5ldyBncm91cCBrZXlpbmcgbWF0ZXJpYWwvIFRoaXMNCiAgICBzaG91 bGQgYmUgZG9uZSBiZWZvcmUgZG9pbmcgdGhhdCAtIGl0IHNob3VsZCBhbHNvIGJlIGNvbW1pdHRl ZCBsb25nIHRlcm0NCiAgICBzdG9yYWdlIGlmIG9uZSBleHBlY3RzIHRoZSBLREMgdG8gcmVzdGFy dCB3L28gYSBmb3JjZWQgcmVrZXkgZXZlbnQuICBBbmQNCiAgICBldmVuIHRoZW4gaXQgcG90ZW50 aWFsbHkgc2hvdWxkIGhhdmUgYSBuZXcgY29udGV4dCBudW1iZXIuDQoNCkZQOiBPaywgd2UgaGF2 ZSBtb2RpZmllZCBldmVyeXdoZXJlICg0LjYgYnV0IGFsc28gNC4xLjUuMSwgNC44IGFuZCA1KSBz byB0aGF0IHRoZSB2ZXJzaW9uIG51bWJlciBpcyBpbmNyZW1lbnRlZCBiZWZvcmUgdGhlIGtleWlu ZyBtYXRlcmlhbCBpcyBkaXN0cmlidXRlZC4NCg0KICAgICogU2VjdGlvbiA1IC0gc2VlIHByZXZp b3VzIGNvbW1lbnQNCg0KRlA6IFllcywgZml4ZWQuDQoNCiAgICAqIFNlY3Rpb24gNSAtIERvZXMg dGhlIHVzZSBvZiB0aGUgREVMRVRFIG1ldGhvZCB0byBpbmZvcm0gYSBjbGllbnQgdGhhdCBpdA0K ICAgIGlzIG5vIGxvbmdlciBwYXJ0IG9mIHRoZSBncm91cCBpbXBseSB0aGF0IGEgZGlmZmVyZW50 IGNvbnRyb2wgcGF0aCBpcyBuZWVkZWQNCiAgICBmb3IgZXZlcnkgZ3JvdXAgdGhhdCB0aGUgY2xp ZW50IGpvaW5zPyAgSSBkb24ndCBrbm93IHRoYXQgSSB3YXMgZXhwZWN0aW5nDQogICAgdGhhdC4N Cg0KRlA6IFRoYXTigJlzIGNvcnJlY3QuIEFuIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRoYXQgdGhl IEtEQyBzZW5kcyBhIFBPU1QsIGluZGljYXRpbmcgdGhlIGdyb3VwIG5hbWUgaW4gdGhlIHBheWxv YWQuIFRoaXMgd291bGQgYmUgc2VudCB0byBhIHNpbmdsZSByZXNvdXJjZSBvbiB0aGUgQ2xpZW50 IHVzZWQgZm9yIGFueSBqb2luZWQgZ3JvdXAgdW5kZXIgYW55IEtEQy4gV291bGQgeW91IHByZWZl ciB0aGlzPyAobm90IGltcGxlbWVudGVkIHJpZ2h0IG5vdykNCg0KICAgIFNlY3Rpb24gNyAtIC8g ZW5kIG9mIHRoZSByZWtleWluZyBwcm9jZXNzIGFuZCB0aGUgbmV4dCBsb3NzIG9mIHNlY3VyaXR5 DQogICAgc3RhdGUvICBUaGlzIGlzIG5vdCB3aGF0IEkgd2FzIHRyeWluZyB0byBnZXQgYXQgYW5k IGl0IG1ha2VzIG5vIHNlbnNlIHRvIG1lLg0KICAgIFRoZSBxdWVzdGlvbiBpcyB0aGUgaW50ZXJ2 YWwgYmV0d2VlbiB0aGUgZW5kIG9mIHRoZSBsYXN0IHJla2V5IHByb2Nlc3MgYW5kDQogICAgdGhl IGNsaWVudCBqb2luaW5nIHRoZSBncm91cC4gIElmIHRoYXQgaXMgc21hbGwgZW5vdWdoIHRoZW4g cmVwbGF5IHdpbGwgbm90DQogICAgd29yay4NCg0KRlA6IE9rLCB3ZSBoYXZlIHJlcGhyYXNlZCBp biB0aGUgZm9sbG93aW5nIHdheToNCk9MRA0KSWYgdGhlIGdyb3VwIGhhcyByZW5ld2VkIGl0cyBn cm91cCBrZXlpbmcgbWF0ZXJpYWwsIHRoZSB0aW1lIHdpbmRvdyBiZXR3ZWVuIHRoZSBlbmQgb2Yg dGhlIHJla2V5aW5nIHByb2Nlc3MgYW5kIHRoZSBuZXh0IGxvc3Mgb2Ygc2VjdXJpdHkgc3RhdGUg aXMgc2FmZSBmb3IgcmVjaXBpZW50cywgYXMgcmVwbGF5ZWQgb2xkZXIgbWVzc2FnZXMgcHJvdGVj dGVkIHdpdGggcHJldmlvdXMga2V5aW5nIG1hdGVyaWFsIHdpbGwgbm90IGJlIGFjY2VwdGVkLg0K TkVXDQpCZXNpZGVzLCBpZiB0aGUgS0RDIGhhcyByZW5ld2VkIHRoZSBncm91cCBrZXlpbmcgbWF0 ZXJpYWwsIGFuZCB0aGUgdGltZSBpbnRlcnZhbCBiZXR3ZWVuIHRoZSBlbmQgb2YgdGhlIHJla2V5 aW5nIHByb2Nlc3MgYW5kIHRoZSBqb2luaW5nIG9mIHRoZSBDbGllbnQgaXMgc3VmZmljaWVudGx5 IHNtYWxsLCB0aGF0IENsaWVudCBpcyBhbHNvIG9uIHRoZSBzYWZlIHNpZGUsIHNpbmNlIHJlcGxh eWVkIG9sZGVyIG1lc3NhZ2VzIHByb3RlY3RlZCB3aXRoIHRoZSBwcmV2aW91cyBrZXlpbmcgbWF0 ZXJpYWwgd2lsbCBub3QgYmUgYWNjZXB0ZWQuDQoNCiAgICBTZWN0aW9uIDcgL3RoZSBPYnNlcnZh dGlvbnMgdXAgdG8gdGhhdCBwb2ludC8gdGhpcyBkb2VzIG5vdCBtYWtlIGFueSBzZW5zZS4NCiAg ICBZb3UgY2FuIGxvc2Ugd2hvIEkgY3VycmVudGx5IGRvaW5nIHRoZSBvYnNlcnZhdGlvbiBidXQg eW91IGhhdmUgYWxyZWFkeQ0KICAgIHRvc3NlZCBhbGwgb2YgdGhlIG9ic2VydmF0aW9ucyB0aGVt c2VsdmVzIGV2ZW4gd2l0aG91dCBhIHJlYm9vdC4NCg0KRlA6IE9rLCB3ZSBoYXZlIHJlcGhyYXNl ZDoNCk9MRA0KdGhlIE9ic2VydmF0aW9ucyB1cCB0byB0aGF0IHBvaW50DQpORVcNCmFsbCB0aGUg Y3VycmVudCBvbmdvaW5nIE9ic2VydmF0aW9ucyB3aXRoIHRoZSBncm91cCBtZW1iZXJzDQpJcyB0 aGlzIGJldHRlcj8NCg0KICAgIFNlY3Rpb24gNyAtIEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgY29u ZGl0aW9ucyB5b3UgaGF2ZSBsYWlkIG91dCBmb3IgZG9pbmcNCiAgICBkZWxheWVkIHJla2V5aW5n ICBJIHdvdWxkIGV4cGVjdCB0aGF0IGl0IGlzIGEgbWluaW11bSBudW1iZXIgT1IgYSBtYXhpbXVt DQogICAgaW50ZXJ2YWwuICBCdXQgSSBkb24ndCB0aGluayB0aGF0IGlzIHdoYXQgdGhpcyBzYXlz Lg0KDQpGUDogV2UgaGF2ZSByZXBocmFzZWQgaW4gdGhlIGZvbGxvd2luZyB3YXk6DQpPTEQNCklu c3RlYWQsIHRoZSBLREMgbWF5IHJla2V5IHRoZSBncm91cCBhZnRlciBhIG1pbmltdW0gbnVtYmVy IG9mIGdyb3VwIG1lbWJlcnMgaGF2ZSBqb2luZWQgb3IgbGVmdCB3aXRoaW4gYSBnaXZlbiB0aW1l IGludGVydmFsLCBvciBkdXJpbmcgcHJlZGljdGFibGUgbmV0d29yayBpbmFjdGl2aXR5IHBlcmlv ZHMuDQpORVcNClRoZSBLREMgbWF5IHJla2V5IHRoZSBncm91cCBhZnRlciBhIG1pbmltdW0gbnVt YmVyIG9mIGdyb3VwIG1lbWJlcnMgaGF2ZSBqb2luZWQgb3IgbGVmdCB3aXRoaW4gYSBnaXZlbiB0 aW1lIGludGVydmFsLCBvciBhZnRlciBtYXhpbXVtIGFtb3VudCBvZiB0aW1lIHNpbmNlIHRoZSBs YXN0IHJla2V5aW5nIHdhcyBjb21wbGV0ZWQsIG9yIHlldCBkdXJpbmcgcHJlZGljdGFibGUgbmV0 d29yayBpbmFjdGl2aXR5IHBlcmlvZHMuDQoNCiAgICBTZWN0aW9uIDcgLSBUaGlzIGlzIGEgdGlj IHRoYXQgSSBhbSB0cnlpbmcgdG8gc3RvcCBpbiBteSBvd24gd3JpdGluZy4gIExvb2sNCiAgICBh dCBhbGwgaW5zdGFuY2VzIG9mICJJbiBmYWN0LCIgYW5kIHRoZXkgY2FuIHByb2JhYmx5IGJlIHJl bW92ZWQuICBUaGUgb3RoZXINCiAgICBvbmUgdGhhdCBJIHVzZSBhIGxvdCBpcyAiQWN0dWFsbHks Ig0KDQpGUDogVGhhbmtzLCB3ZSBoYXZlIHJlbW92ZWQgYWxsIGluc3RhbmNlcyBvZiBJbiBmYWN0 IGFuZCBBY3R1YWxseSB0aGF0IHdlIGNvdWxkIGZpbmQuDQoNCiAgICBTZWN0aW9uIDcgLSBzL2lu aXRpYXRpbmcgcmVrZXlzL2luaXRpYXRpbmcgcmVrZXkgZXZlbnRzLw0KDQpGUDogT2ssIGZpeGVk Lg0KDQogICAgU2VjdGlvbiA3LjEgLSBQYXJhIDIgLSBpdCB3b3VsZCBub3QgYmUgYSBzZWNvbmQg dHJ5IGFzIHRoZSBLSUQgY29udGV4dCBmaWVsZA0KICAgIHdvdWxkIGJlIGRpZmZlcmVudCBpbiBn ZW5lcmFsLg0KDQpGUDogT2ssIHJlbW92ZWQg4oCcYXMgc2Vjb25kIGF0dGVtcHTigJ0uDQoNCiAg ICBKaW0NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQo= From nobody Wed Jul 15 13:51:52 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 8B9363A0805 for ; Wed, 15 Jul 2020 13:51:50 -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 YYDgO7dhYoMO for ; Wed, 15 Jul 2020 13:51:49 -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 A19493A0788 for ; Wed, 15 Jul 2020 13:51:48 -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; Wed, 15 Jul 2020 13:51:41 -0700 From: Jim Schaad To: Date: Wed, 15 Jul 2020 13:51:39 -0700 Message-ID: <010101d65ae9$bdffb520$39ff1f60$@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: AdZa6NLXkAXyBQ7aQr2DDV5usE+aKQ== Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: [Ace] Working Group Adoption Call for draft-bormann-core-ace-aif 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, 15 Jul 2020 20:51:51 -0000 I had been holding off doing an adoption call waiting for a formal request to adopt it. However, given that this is now a dependency for three different WG documents I think we need to do this now. Adoption call for https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ This document provides a template for an authorization information format (AIF) using a CDDL generic. Questions to be answered: 1. Do you think the ACE WG should adopt this document? If not please provide some reasoning. 2. If adopted are you willing to review the document? 3. Would you have any implementation plans? Currently this is referenced by the MQTT-TLS document, the Group KDC documents. Adoption call ends on July 28. Jim & Daniel From nobody Wed Jul 15 23:25:29 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 DEFB43A0F7C for ; Wed, 15 Jul 2020 23:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 t2l6jqVt9dVv for ; Wed, 15 Jul 2020 23:25:25 -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 5F7D33A0F7B for ; Wed, 15 Jul 2020 23:25:04 -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 4B6kkk4fJMzyvB; Thu, 16 Jul 2020 08:25:02 +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: <010101d65ae9$bdffb520$39ff1f60$@augustcellars.com> Date: Thu, 16 Jul 2020 08:25:02 +0200 Cc: ace@ietf.org X-Mao-Original-Outgoing-Id: 616573501.852074-ef3dedd3545eff061458becdde372b47 Content-Transfer-Encoding: quoted-printable Message-Id: References: <010101d65ae9$bdffb520$39ff1f60$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Ace] Working Group Adoption Call for draft-bormann-core-ace-aif 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, 16 Jul 2020 06:25:28 -0000 On 2020-07-15, at 22:51, Jim Schaad wrote: >=20 > I had been holding off doing an adoption call waiting for a formal = request > to adopt it. =20 Sorry about that =E2=80=94 I was still thinking we should finish the = discussion about the new dynamic permissions. But I realize now that = these have been around for a month and that they really are not that = relevant for the adoption questions. > However, given that this is now a dependency for three > different WG documents I think we need to do this now. Great. Since I didn=E2=80=99t ask to initiate the call, I can reply to = it! It seems this draft is becoming a useful little shared component for = other work, so we indeed should adopt it. (And while everyone else is rereading -09 to see whether we should adopt = it =E2=80=94 do you have any opinion on the new dynamic permissions?) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jul 16 14:01: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 875413A0CE7; Thu, 16 Jul 2020 14:01:37 -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 f72mOwbrdg8X; Thu, 16 Jul 2020 14:01:34 -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 667533A0CE8; Thu, 16 Jul 2020 14:01:33 -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, 16 Jul 2020 14:01:27 -0700 From: Jim Schaad To: 'Francesca Palombini' , CC: References: <023501d64b6e$83ea3b60$8bbeb220$@augustcellars.com> <8D4E3757-5AE5-4216-B13C-76F5916AD3D3@ericsson.com> In-Reply-To: <8D4E3757-5AE5-4216-B13C-76F5916AD3D3@ericsson.com> Date: Thu, 16 Jul 2020 14:01:25 -0700 Message-ID: <004f01d65bb4$46c20690$d44613b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHrkDtHCrrJyDPNrRhUQsxYXvvw2gE/Sm55qNXuokA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [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: Thu, 16 Jul 2020 21:01:38 -0000 > -----Original Message----- > From: Francesca Palombini > Sent: Tuesday, July 14, 2020 2:25 PM > To: Jim Schaad ; draft-ietf-ace-key- > groupcomm@ietf.org > Cc: ace@ietf.org > Subject: Re: Review of ietf-ace-key-groupcomm-07 >=20 > Hi Jim, >=20 > Thank you so much for another extensive review! We have submitted v-08 = of > the draft to answer it. > Comments inline. If there is any answer/update that does not satisfy = you, > hopefully we can continue the discussion by mail and figure out the = major > points to discuss during IETF108. >=20 > Thanks, > Francesca and Marco >=20 > =EF=BB=BFOn 26/06/2020, 06:02, "Jim Schaad" = wrote: >=20 >=20 > * Section 2 - update DTLS reference >=20 > FP: The Ace profile of DTLS is defined to set up DTLS 1.2, there is no = profile > defined to set up DTLS 1.3, so I don=E2=80=99t think we should update = to 1.3 here. [JLS] Fine - but be prepared for pushback from the IESG on this. >=20 > * Section 3 - The content format application/ace+cbor is not = defined by the > transport profiles but by the framework. >=20 > FP: The point is that the profiles might change the content format, so = even if > this specific one ace+cbor is defined in Ace, profiles might define = and use other > ones. Rephrased to clarify. [JLS] No, the profile can dictate the media type between C and RS, but = between C and AS is set by the framework. >=20 > * 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. >=20 > FP: I tried to reformulate here that the aif is the default encoding, = and specify > that the other format defined is an example. In the end it is up to = the > application profile to specify the format of scope. Sure, but why not express figure 4 in terms of AIF rather than as = something that looks like a new structure? >=20 > * 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. >=20 > FP: We have modified that to be tstr to be consistent with ace key = groupcomm > oscore, but please note this is only an example. [JLS] Yes I know it is an example, but the gname cannot be anything = other than a tstr unless you are going to completely break the = connection between this value and the name in the URI. > * 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) >=20 > FP: I need more clarifications: Is it the following that is strange = =E2=80=9C'scope' > containing the granted scope, if different from the scope requested by = the > client. =E2=80=9C ? Note that the terminology =E2=80=9Crequested and = granted scope=E2=80=9D comes > from OAuth: https://tools.ietf.org/html/rfc6749#section-3.3. I removed = the > second part of the sentence as per comment below. [JLS] What seems odd is that if it is absent, then it is not clear what = the grants are. I don't know if you need to specify that the grant is = the same as the request when it is not present. On the other hand this = is duplicating information in the framework document. >=20 > * Section 3.3 - Am I supposed to know why I care about public keys = at this > point? >=20 > FP: I thought this sentence was supposed to cover it (second = paragraph of 3.3): > =E2=80=9COptionally, the Client might want to request necessary = information concerning > the public keys in the group, as well as concerning the algorithm and = related > parameters for computing signatures in the group.=E2=80=9D = What=E2=80=99s missing? [JLS] Well - lets start with the use of the singular group in the text. = There are a number of problems here: 1. It would make sense that this = refer to the public key usage from group comm document. 2. The term = "information concerning the public keys in the group" to me reads - get = the public keys. 3. There is no motivation about why you are getting = this from the token post rather than from the group descriptor. > * 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...) >=20 > FP: It seems to us this is already defined in the framework: from > = https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-35#section-5.8.1 > =E2=80=9CWhen an RS receives an access token, it MUST verify it before = storing it.=E2=80=9D > And later > =E2=80=9CIf token or claim verification fails, the RS MUST discard the = token and, if this > was an interaction with authz-info, return an error message with a = response > code equivalent to the CoAP code 4.01 (Unauthorized).=E2=80=9D [JLS] That text does not say that one cannot do the following: 1) Get = the token from the POST, 2) immediately return a success indicator, 3) = do the validation of the token, including introspection if necessary, 4) = Keep or discard the token depending on the outcome of the validation = process.=20 I was working to get this in because I did not want to have no response = go back to the client while waiting for the token to be validated in the = event of needing to do introspection. There is nothing really bad = happening if I return a OSCORE nonce in the event that you send me a = DTLS token because you would just ignore that as not being useful. = However, if I have to have the entire content of the token before I can = respond then introspection is going to be harder to deal with. > * 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. >=20 > FP: Not sure we understand the problem here. Does =E2=80=9Cdifferent = key=E2=80=9D refer to a > following new public key that the client wants to upload? There is in = fact no > association between =E2=80=98kdcchallenge=E2=80=99 and the public key = itself, not even with the > first one that the client provides at its first joining (and it is = also unknown to the > KDC at the time when =E2=80=98kdcchallenge=E2=80=99 is issued). = It=E2=80=99s important the > =E2=80=98kdcchallenge=E2=80=99 is associated to that exact client, = meaning to that exact Token > and PoP key. [JLS] Let's start with which "different key" you are referring to. Is = this a different signing key or a different POP key? Depending on how = you read this is completely changes the meaning of what you are saying = to do in this paragraph. A different POP key (token) will not be using = the same kdcchallenge as a different POP key. You might be able to use = it for a different signing key for a second group in the same token. = But that is not how I read it. > * 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? >=20 > FP: Here we meant application profiles of this doc such as = =E2=80=9Cace-key- > groupcomm-oscore=E2=80=9D. I don=E2=80=99t understand the second part = of his comment, could > you explain? [JLS] My problem is that application is a really overloaded term. Just = think of three different lighting applications: Theater Lighting, = Building Lighting and Emergency Lighting. These are three different = applications that are all going to use an OSCORE group keying protocol = as part of their implementation. Now you are saying that the profile is = an application. I am getting really confused about what is an = application and what isn't. > * Section 4 - are we still specifying a group to join or is that = implicit in > the URL? Tell me how it is specified? >=20 > FP: It=E2=80=99s specified in the =E2=80=98scope=E2=80=99 of the = Joining Request, as the group name in the > single scope_entry for that Joining Request. I think it=E2=80=99s good = not to mandate > that the URI reflects the group name in the path (though it makes = sense and we > do it in the examples). [JLS] I don't agree. >=20 > * Section 4 - I don't think that the (re-) is helping = understanding here. >=20 > FP: The point we were trying to make clear with that (re-) is that it = can be used > to retrieve those several following times, not only once. But I = don=E2=80=99t know how to > express that clearly, and since that does not help understanding we = have > removed them. [JLS] Still and instance in section 1.1=20 >=20 > * Section 4 - what type of individual key is being obtained in = bullet 2 - > how is this different than getting the current keying material? >=20 > FP: The individual key is the equivalent of the Sender Key in OSCORE = (or input > material to derive it, i.e. the Sender ID), vs the group keying = material such as > the master secret, master salt, context id. The difference is that = using bullet 2 > only the personal node=E2=80=99s keying material is updated, not the = group keying > material. We=E2=80=99d welcome proposals on how to clarify it without = going into > OSCORE details. [JLS] Is this trying to say that a new clientId can be issued as oppose = to the current set of material? I would think that you always get = material to derive it and never directly get a key. >=20 > * 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. >=20 > FP: The part about =E2=80=9Cfixed=E2=80=9D was meant to say that once = defined it will not > change, whatever the application profiles define to use, either the = default or > other, opposed to the /ace-group/GROUPNAME for example, which have a > variable part. Since that was not clear, and not to make it = inconsistent, we have > removed the term fixed. > About OSCORE using a different resource name: should we then specify = as a > requirement that the profiles MUST set the root uri-path, rather than = providing > a default? [JLS] That would make more sense to me. I am not sure why you care = about getting a new root however as a single root could, in theory = support multiple KDC profiles. >=20 > * Section 4.1 - what does it mean for a sub-resource to be = "fixed". Does > that mean it never changes? >=20 > FP: See previous answer. Yes it means that once defined it does not = change > depending on other parameters (such as GROUPNAME or NODENAME). We > have removed it now as it was not clear. [JLS] The term normally used is "invariant once established" for that = type of meaning. Fixed would seem to imply that it is fixed prior to = that. >=20 > * Section 4.1 - Yes but what is a NODENAME and why do I care about = it? >=20 > FP: Hopefully adding the following =E2=80=9CEach resource contains the = individual > keying material for that node. =E2=80=9C gives an intuition why the = NODENAME is used. > The fact that it is a node identifier should be clear by the following = sentence: =E2=80=9C > These resources are identified by the node name (in this example, the = node > name has value "NODENAME")=E2=80=9D More details about how precisely = NODENAME > is used to verify the request are given in 4.1.2.1, but we only want = to talk about > it high level here. [JLS] This is the first time that I have seen the term in the document. = Using it without any type of definition is not very useful. Even = defining it in the terminology section would be helpful. >=20 > * 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. >=20 > FP: Ok, I added a note about that. The idea was that this section is = really about > the handler, and the joining is described using this handler later on, = in section > 4.2. [JLS] Yes that is the sort of thing I was looking for. Getting a = correspondence between the resources and the operations is always = helpful. >=20 > * 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. >=20 > FP: Ok, added the following sentence: =E2=80=9CNote that including = this parameter may > result in a large message size for the following response, which can = be > inconvenient for resource-constrained devices.=E2=80=9D Anything more = we need to > add? [JLS] I don't think so. The details on blockwise and ETag should be = clear already. >=20 > * 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. >=20 > FP: We do that to point the reader on where to find the encoding = (which is the > same as in Ace). [JLS] Ok - that seems a bit odd because this is not the same media-type. >=20 > * 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? >=20 > FP: By =E2=80=9Cused=E2=80=9D I assume you mean by the KDC? The KDC = extract the granted > scope from the Token, and checks this requested one against the token = one. If > this join message does not have one we are in the case where the KDC > understands which group and role the Client is requesting (say there = is only one > that the client has been granted). What are we missing? [JLS] That explanation > * Section 4.1.2.1 - both bullets are talking about failed = verification - > kill the redundancy. >=20 > FP: Yes, but the error processing is different in the 2 bullets: in = case the > verification fails because client_cred_verify fails, we specify what = the handler > needs to do with regard to the kdcchallenge. So it is not really = redundant. We > haven=E2=80=99t made any changes, but please let us know if you have = ideas on how to > improve. [JLS] But I don't see any reason why I could not return a payload w/ a = new kdcchallenge in the first case as well. >=20 > * 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. >=20 > FP: Ok, we have added a requirement that it is up to the application = profile to > specify what the initial value should be. For OSCORE, this can be = defined in > draft-tiloca-ace-oscore-gm-admin and referenced in the profile. [JLS] Do you want a normative reference to the admin document? > * 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? >=20 > FP: Ok, we have moved this to the policies. It is worth noting though = that the > group_policies parameter is optional (meaning the KDC might not send = this info > in the message), we have explicitly added that the default values MUST = be > specified by the application profiles. [JLS] Yes, but you would use an exp_delta of 0 if you did not retrieve = it from the policy. > * 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. >=20 > FP: Ok for exp, we changed it to SHOULD. About gkty in the GET = response, it > allows a node acting as =E2=80=9Cmonitor=E2=80=9D to only request the = group key and get all the > information it needs without needing to do the full POST, especially = if the KDC > maintains the pub keys and would fail its request if it does not = contain a pub > key. We could make gkty optional in the response to GET, but I think = that would > just be more complicated (when does the KDC sends it? When not?) I = don=E2=80=99t > think the saving 2 bytes is motivation enough for removing it, given = that we > have a reason for having it. [JLS] I think that is probably reasonable. > * Section 4.1.3.1 - The text on the first selection criteria has = me really > messed up because I am not sure that >=20 > FP: Broken comment. But we have assumed this was about the parenthesis > (including the exact combination of roles requested) and have tried to = rephrase > to clarify. I am not sure what the matching rules are supposed to be for role = identifiers. It looks like this might have been clarified > * Section 4.1.6.1 - I have no idea from the text why I would use = this > method. >=20 > FP: It=E2=80=99s difficult to give a clearer idea avoiding = profile-specific details. Would it > help to have an informational reference to key groupcomm oscore to = give an > example? (I=E2=80=99d rather avoid the circular dependency, so if you = have other ideas > on how to improve, I=E2=80=99ll take them). [JLS] This handler is used by a node either to 1) get a new identifier = within the current group or 2) force a rekeying of the group. This is = normally done due to usage limits on the AEAD algorithm. >=20 > * 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? >=20 > FP: The point is that the KDC MUST NOT accept a request from a node N1 > sending a DELETE to ace-group/GROUPNAME/nodes/N2.The KDC can identify > the node name from the secure session it has set up with it (it has = given the > node a name and associated it to the secure channel once the node has = done > the join process). We have tried to reformulate to clarify. [JLS] The text in 4.1.6.2 was clearer about that. >=20 > * Section 4.2 - "retrieve individual or group keying material" = What > individual material? >=20 > FP: Same answer as before: this could be for example the sender ID to = derive > the Sender Key in OSCORE. It=E2=80=99s difficult to give a clearer = idea avoiding profile- > specific details. Would it help to have an informational reference to = key > groupcomm oscore to give an example? (I=E2=80=99d rather avoid the = circular > dependency, so if you have other ideas on how to improve, I=E2=80=99ll = take them). [JLS] Retrieve group keying material for the individual >=20 > * 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. >=20 > FP: We had added some security considerations about it, referencing to = Section > 4.7 of 7252. Now we added this reference in this section as well. Is = that enough > or what is missing? [JLS] I would have just put the text into the security considerations or = network considerations sections and not bothered to have it here. No = big deal >=20 > * Section 4.4 - What does the first sentence even mean? It seems = to be > almost a circular argument. >=20 > FP: Tried rephrasing as follows: =E2=80=9CBeside possible expiration, = the client may > need to communicate to the KDC its need for part of the keying = material to be > renewed. =E2=80=9C Let us know if this is still unclear. [JLS] I would not bother with 'part of' And putting in text about why = this is needed (i.e. AEAD integrity/confidentially limits) is going to = motivate things better. >=20 > * 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. >=20 > FP: Ok, we tried changing to =E2=80=9CRetrieval of New Individual = Keying Material=E2=80=9D Is > this better? [JLS] Not really - that would seem to imply that I would not get "new" = material in section 4.3 either. =20 4.3 - Retrieval of keying material 4.4 - Requesting a change of keying material >=20 > * 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. >=20 > FP: Why? It is important that the client processes the response = correctly. It > makes sense this would not be in the =E2=80=9Chandler=E2=80=9D = section, but here we think we > should have this type of details. Would it be better to have this = paragraph after > the figure? [JLS] What about a client which retrieves the key, verifies the one = signature and promptly forgets the key w/o any long term storage? I'm = going to sleep almost immediately and it will have probably changed by = the time I wake up again. > * 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. >=20 > FP: That=E2=80=99s correct. An alternative would be that the KDC sends = a POST, > indicating the group name in the payload. This would be sent to a = single > resource on the Client used for any joined group under any KDC. Would = you > prefer this? (not implemented right now) [JLS] I don't know, but probably yes. >=20 > 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. >=20 > FP: Ok, we have rephrased in the following way: > OLD > If the group has renewed its group keying material, the time window = between > the end of the rekeying process and the next loss of security state is = safe for > recipients, as replayed older messages protected with previous keying = material > will not be accepted. > NEW > Besides, if the KDC has renewed the group keying material, and the = time > interval between the end of the rekeying process and the joining of = the Client is > sufficiently small, that Client is also on the safe side, since = replayed older > messages protected with the previous keying material will not be = accepted. [JLS] Better >=20 > 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. >=20 > FP: Ok, we have rephrased: > OLD > the Observations up to that point > NEW > all the current ongoing Observations with the group members Is this = better? [JLS] Yeah, better Jim >=20 > Jim >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 From nobody Fri Jul 17 15:21:41 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 460183A09D3 for ; Fri, 17 Jul 2020 15:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 JwoPvtYoemz6 for ; Fri, 17 Jul 2020 15:21:38 -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 89E9F3A09D1 for ; Fri, 17 Jul 2020 15:21:38 -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 06HMLUNP001583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 17 Jul 2020 18:21:32 -0400 Date: Fri, 17 Jul 2020 15:21:30 -0700 From: Benjamin Kaduk To: Jim Schaad Cc: ace@ietf.org Message-ID: <20200717222130.GB41010@kduck.mit.edu> References: <010101d65ae9$bdffb520$39ff1f60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010101d65ae9$bdffb520$39ff1f60$@augustcellars.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] Working Group Adoption Call for draft-bormann-core-ace-aif 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, 17 Jul 2020 22:21:40 -0000 On Wed, Jul 15, 2020 at 01:51:39PM -0700, Jim Schaad wrote: > I had been holding off doing an adoption call waiting for a formal request > to adopt it. However, given that this is now a dependency for three > different WG documents I think we need to do this now. > > Adoption call for > https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ > > This document provides a template for an authorization information format > (AIF) using a CDDL generic. Questions to be answered: > > 1. Do you think the ACE WG should adopt this document? If not please > provide some reasoning. Refreshing my memory of the WG charter, it seems like this can be in scope, but we should be sure to consider what analogues already exist in non-constrained systems, and whether we are in fact creating something generally new and broadly useful. -Ben From nobody Fri Jul 17 16:07:53 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 DD1803A0AC8 for ; Fri, 17 Jul 2020 16:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 9iP48KiJVyyx for ; Fri, 17 Jul 2020 16:07:49 -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 B81F83A0ACB for ; Fri, 17 Jul 2020 16:07:48 -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 4B7mxD2cz1zyNv; Sat, 18 Jul 2020 01:07:44 +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: <20200717222130.GB41010@kduck.mit.edu> Date: Sat, 18 Jul 2020 01:07:44 +0200 Cc: Jim Schaad , ace@ietf.org X-Mao-Original-Outgoing-Id: 616720064.227856-c1d633a13b345f628752f7750c63e063 Content-Transfer-Encoding: quoted-printable Message-Id: References: <010101d65ae9$bdffb520$39ff1f60$@augustcellars.com> <20200717222130.GB41010@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [Ace] Working Group Adoption Call for draft-bormann-core-ace-aif 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, 17 Jul 2020 23:07:52 -0000 On 2020-07-18, at 00:21, Benjamin Kaduk wrote: >=20 > Refreshing my memory of the WG charter, it seems like this can be in = scope, > but we should be sure to consider what analogues already exist in > non-constrained systems, and whether we are in fact creating something > generally new and broadly useful. Good point. The simplistic model of AIF caters to servers where authorization can be = described in terms of static resources (now also resources created from = static resources) and CoAP methods that can be performed on them. CoAP methods can be related to HTTP methods. But I would expect most big-Web applications to have a more = sophisticated authorization model, e.g., based on server-side = information (user information in a database etc.). E.g., an OAuth AS in the big Web wouldn=E2=80=99t say =E2=80=9Cgive C = access to these 10537 photos=E2=80=9D and list them all, but =E2=80=9Cgive= C access to Peter=E2=80=99s photos=E2=80=9D. So I think the design of AIF is a bit specialized to devices where = resources mostly correspond to physical traits of those devices that = don=E2=80=99t go away or come anew, with action resources (which are now = handled with dynamic permissions) maybe an exception. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Jul 19 15:30:08 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 453383A08FD; Sun, 19 Jul 2020 15:30:00 -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 wBgYR-9EaAxV; Sun, 19 Jul 2020 15:29:58 -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 F1CA33A08FA; Sun, 19 Jul 2020 15:29:57 -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, 19 Jul 2020 15:29:51 -0700 From: Jim Schaad To: 'Paul Kyzivat' , CC: 'General Area Review Team' , References: <8c2725a3-f89f-7ea1-dda9-681edd463a32@alum.mit.edu> In-Reply-To: <8c2725a3-f89f-7ea1-dda9-681edd463a32@alum.mit.edu> Date: Sun, 19 Jul 2020 15:29:48 -0700 Message-ID: <000001d65e1c$1eed9430$5cc8bc90$@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: AQHl0TW2xBQNibu5hPYR+rhuY3INLqjwer3g Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12 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, 19 Jul 2020 22:30:00 -0000 > -----Original Message----- > From: Paul Kyzivat > Sent: Sunday, July 19, 2020 1:24 PM > To: draft-ietf-ace-dtls-authorize.all@ietf.org > Cc: General Area Review Team > Subject: Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12 > > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for > the IETF Chair. Please treat these comments just like any other last call > comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-ace-dtls-authorize-12 > Reviewer: Paul Kyzivat > Review Date: 2020-07-19 > IETF LC End Date: 2020-07-20 > IESG Telechat date: ? > > Summary: > > This draft is on the right track but has open issues, described in the review. > > General: > > TBD > > Issues: > > Major: 2 > Minor: 1 > Nits: 1 > > 1) MAJOR: Management of token storage in RS > > There seems to be an expectation that when the client uploads an access token > that the RS will retain it until the client attempts to establish a DTLS > association. This seems to require some sort of management of token lifetime > in the RS. The only discussion I can find of this issue is the following in section 7: > > ... A similar issue exists with the > unprotected authorization information endpoint where the resource > server needs to keep valid access tokens until their expiry. > Adversaries can fill up the constrained resource server's internal > storage for a very long time with interjected or otherwise retrieved > valid access tokens. > > This seems to imply a normative requirement to keep tokens until their expiry. > But I find no supporting normative requirements about this. And, this section > only presents it as a DoS attack, rather than a potential problem with valid > usage. > > ISTM that there is an implied requirement that the RS have the capacity to > store one access token for every PoP key of every authorized client. > If so, that ought to be stated. If not, then some other way of bounding storage > ought to be discussed. In section 5.8.1 of draft-ietf-ace-oauth-authz is the sentence "The RS MUST be prepared to store at least one access token for future use." When this was put in, this is exactly what we were discussing. There is no requirement that an RS needs to store two access tokens for future use. I think this means that there is a strongly bounded requirement on storage. Authors - It might be worthwhile to re-iterate this requirement in both of the profile documents. > > 2) MAJOR: Missing normative language > > I found several places where the text seems to suggest required behavior but > fails to do so using normative language: > > * In section 3.3: > > ... Instead of > providing the keying material in the access token, the authorization > server includes the key identifier in the "kid" parameter, see > Figure 7. This key identifier enables the resource server to > calculate the symmetric key used for the communication with the > client using the key derivation key and a KDF to be defined by the > application, for example HKDF-SHA-256. The key identifier picked by > the authorization server needs to be unique for each access token > where a unique symmetric key is required. > ... > Use of a unique (per resource server) "kid" and the use of a key > derivation IKM that is unique per authorization server/resource > server pair as specified above will ensure that the derived key is > not shared across multiple clients. > > The uniqueness seems to be a requirement. Perhaps "needs to be unique" > should be "MUST be unique". (And something similar for the IKM.) > > * Also in section 3.3: > > All CBOR data types are encoded in CBOR using preferred serialization > and deterministic encoding as specified in Section 4 of > [I-D.ietf-cbor-7049bis]. This implies in particular that the "type" > and "L" components use the minimum length encoding. The content of > the "access_token" field is treated as opaque data for the purpose of > key derivation. > > IIUC the type of serialization and encoding is a requirement. Will need some > rewording to make it so. > > * In section 3.3.1: > > ... To > be consistent with the recommendations in [RFC7252] a client is > expected to offer at least the ciphersuite TLS_PSK_WITH_AES_128_CCM_8 > [RFC6655] to the resource server. > > I think "is expected" should be "MUST". The rule would be MUST implement not MUST offer. A client could offer a completely different ciphersuite that is consistently used in the group and that would be fine. > > * Also in section 3.3.1: > > ... This > specification assumes that the access token is a PoP token as > described in [I-D.ietf-ace-oauth-authz] unless specifically stated > otherwise. > > I think "assumes ... unless" should be "MUST ... unless". > > * Also in section 3.3.1: > > ... New access tokens issued by the > authorization server are supposed to replace previously issued access > tokens for the respective client. > > Is this normative? Should "are supposed to" be "MUST"? > > 3) MINOR: Insufficient specification > > (I'm waffling whether this is minor or major.) > > There are a couple of places where what seem to be requirements are stated > too vaguely to be implemented consistently: > > * In the previously mentioned paragraph in 3.3.1: > > ... This > specification assumes that the access token is a PoP token as > described in [I-D.ietf-ace-oauth-authz] unless specifically stated > otherwise. > > The "unless specifically stated otherwise" is too vague to be normative. > How would the alternative be indicated? Is this an escape hatch for future > extensions? If so, it needs more work to make that clear and to open a path for > that future work. > > * Also in section 3.3.1: > > ... The resource server therefore must > have a common understanding with the authorization server how access > tokens are ordered. > > The last statement ("must have a common understanding") is mysterious. > IIUC section 4 is covering the same topic in a less mysterious way. I am seeing this in section 3.4 - did I miss something? > > 4) NIT: Subsection organization > > Both 3.2 and 3.3 share a common structure: > > * The section begins with discussion of the interaction between the client and > the AS. > > * it is followed by a subsection discussing the interaction between the client > and the RS. > > It is odd to have a section with a single subsection. And the structure isn't easily > discerned from the TOC. > > I suggest it would be clearer if each of these sections had *two* subsections, > one covering the AS interactions and the other the RS interactions. IOW, put the > material covering the AS interactions into a new subsection. From nobody Sun Jul 19 20:16: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 7DB843A0DD0; Sun, 19 Jul 2020 20:16:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Linda Dunbar via Datatracker To: Cc: draft-ietf-ace-oscore-profile.all@ietf.org, ace@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159521497745.9074.17834135527258230957@ietfa.amsl.com> Reply-To: Linda Dunbar Date: Sun, 19 Jul 2020 20:16:17 -0700 Archived-At: Subject: [Ace] Opsdir last call review of draft-ietf-ace-oscore-profile-11 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, 20 Jul 2020 03:16:18 -0000 Reviewer: Linda Dunbar Review result: Has Nits I have reviewed this document as part of the Ops area directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Ops area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes how to set specific parameters in using the Authentication and Authorization for Constrained Environments (ACE) framework [I-D.ietf-ace-oauth-authz]. The document is written clear, except some minor issues: Section 4.1.1 states that Nonce Parameter must be sent from the client to RS. What would be the problem if the client doesn't include the "NONCE"? Page 12: It asks RFC editor to validate the numbers listed in Figure 7. There is no explanation or comments for those values. It will be very difficult for RFC editor to validate. It seems to me there are 4 columns but I can't understand the meaning of the values under 1st, 2nd, and 3rd columns. it is kind of difficult to validate the correctness by just reading through the document. It would be better to have an implementation report of the proposed "Profile". Best Regards, Linda Dunbar From nobody Mon Jul 20 00:48:38 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 BE63B3A082A; Mon, 20 Jul 2020 00:48:36 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-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=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 LuuK9rq79wOx; Mon, 20 Jul 2020 00:48:33 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2080.outbound.protection.outlook.com [40.107.22.80]) (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 E321F3A0826; Mon, 20 Jul 2020 00:48:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KVcbc8ZJv28JyZUqUYPPFIsL8O1dk14evv+mclFP/48pHKyx2ojDkpzWTysqM24vbZTf5uEPY9KyK4ko9pshS/bztnyudojY5v+klA4tOS6cLmcQhhcv55ZFsvY6v4bIrQ1lHAPrW+FEAE2SVYW9hVpzuQUhiugSMIF0+qCQrRYaZvbDknd2GErpgv7EE+hYiF95LmefwP7ssTquPD794NH1NP8bwgF4k8ZPXq2hxDmnIh0EWEjNk163cB6QpPyfLbfX+f4ElExhhvvZ5ZZE4GAhIyhyvrgRkxlttE917/w6ICMnUfdYuUjh4Pj1A7z0gnxls7AtHg50H/v5jPGC7w== 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=d97oSA1iST0KJascRWSLySgI6CpwTM4nVAC1I45os6E=; b=f29tj0BiGGPasQjxIJ09CLPtN/RlmbJDOiio6zt7jd6CqXyxmM8ajxKr/bhlMn/KZBoM/rJ4i8J6rk+s3oI4MBfVSnDUpFv2Z43LMm8ES9sA0ivBnvpQtIQqGyhCMPuW3EdBXbOUCJDnqz2cKaORq47X8FLpTdJAu0D9Gw0ggIQ34t14eaKbNP6xfBg/sUUqbXoD2obU+3k12P/eA2vqMjf3+3fRoksOKdgNpBJsksqnmCq/yOkP8ltGzBWwk9d/hZgBDoXdt1KnBoULQdEKB6UZoVZIRmYzGrw6BsLN/UpWEnnWHIj2s0VrGijv5KmBXf3leiIstLAuLyBoVuFkMw== 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=d97oSA1iST0KJascRWSLySgI6CpwTM4nVAC1I45os6E=; b=cXcA3U9YJCZHYSEDsGliKqctKBKHOsjErNAp5yEE71fM+/0cBR5HNLim47RNjdDLU03rNN+ur3tx00gET6hOALugwOhl/Oroxj3J1dvcwZU2pcPzXKkGNc4l8F+lgzOYzRHOJZrJZXQGxqtSgdpBMhJ25QGRBl7uv0JifRM2ifg= 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 VI1P18901MB0111.EURP189.PROD.OUTLOOK.COM (2603:10a6:801:e::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.17; Mon, 20 Jul 2020 07:48:29 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2%6]) with mapi id 15.20.3195.024; Mon, 20 Jul 2020 07:48:29 +0000 To: Jim Schaad , draft-tiloca-ace-oscore-gm-admin@ietf.org Cc: ace@ietf.org References: <005b01d63ce7$cbedce80$63c96b80$@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: <0274c577-4d8b-14c3-ea39-f754bceb1674@ri.se> Date: Mon, 20 Jul 2020 09:48:22 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <005b01d63ce7$cbedce80$63c96b80$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GGkDQnboQjeoiYo4Nrjvhznj8IW3WxoXI" X-ClientProxiedBy: AM6PR08CA0047.eurprd08.prod.outlook.com (2603:10a6:20b:c0::35) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.3] (37.120.131.76) by AM6PR08CA0047.eurprd08.prod.outlook.com (2603:10a6:20b:c0::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.18 via Frontend Transport; Mon, 20 Jul 2020 07:48:29 +0000 X-Originating-IP: [37.120.131.76] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7af4ce22-2aef-49c1-36c7-08d82c814b0b X-MS-TrafficTypeDiagnostic: VI1P18901MB0111: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: bo605krjkrseV3njNeWTz/dkDx4+6bXHZYSKgK8jsxuU8CAksz4g1ftVV1Ug3wsiQbbnAvEKZpAHORBivPykBMrciyQ50TEEz+XTxW3WWS7KRjEiQbzNQgwgl39bJnzcYioJ4f9BNtZueMhffGPvZiABri9aDhgcNNk/ReiNYsruIBCuUzsYHfCBZpZhvz+2mYBjj6RWoLTpy+Yi71t1G+E/4Eo3QmJht/bp+MgKvHyCmCkzCTFGyWTwgZjRgv8N6nhIaLoGRAgyrL2m3jIv84kCG1yJIAdLY0OEcVfAanidwF9oB06pwCM2nYD8O8rjq3pXsKZOJCosePBNDyTTdWt2q6MAyAWUoQvefQQ4KWFR9WPy8WimMo5BrEAL/KuOxWTK+1xZXEL/W45Py4jNEJIFG12N3VDQxHm9ZrxkOnZeA2btGl7sewhv/WRJaCmab4rvaEv4ZIhPunsf/Vqycw== 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)(376002)(366004)(346002)(136003)(396003)(39850400004)(52116002)(5660300002)(186003)(235185007)(66574015)(8936002)(33964004)(478600001)(8676002)(31686004)(36756003)(53546011)(26005)(966005)(4326008)(16526019)(16576012)(21480400003)(316002)(31696002)(86362001)(44832011)(2906002)(66556008)(66476007)(66946007)(6666004)(6486002)(83380400001)(2616005)(956004)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: MWYKa2q5GqrSJrBao3u6ZF92pKRefggd5Bk1Y9YV+SBlfi9cFeejmsM/wQiObcLC2qEvrc6ibIwvP3FA7f3kQet8+wo0kkhPkVig8XiBHNHFhdZz13zLXIg3suI1kxV0Qxd18GC+T8uylV49ZlwdQfYYML0EdisdRmRfAQxN+CTVglaY7XysROR42iZSOPlztyF7piQbVq8FqOdXaihLti3hBE01GhfMgjFdzRkUixueX6un/ecNihSD2cp+0LJ71bJ86Vp5xBBKa8vQVAm/GjUpOiGd1JlaGwBHLmwMvW78DDSzz7EzhmKCX1WsQmo7FSOWl2U7IQQMCM+e/HGJteqe+zxdY0rRgKzYQBXbvy9B/oURqQp7fAIfZ26u+94FQO+cdHRNPUjJPAYmaLVtG+cUJ08Njj/AXSFVW80l5T3r7scFdgh+q/Q4KtIWT3hncB0dxRyHQCMmbtRUX/nsmdIVvphXkds3p8jbMBdlJ6U= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 7af4ce22-2aef-49c1-36c7-08d82c814b0b X-MS-Exchange-CrossTenant-AuthSource: VI1P189MB0398.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2020 07:48:29.6403 (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: 1rClCbYcaHYFhNe9+fzYjQES2As270XuyawGlS1H7qAkCmPZfNCB7zxiVi70eDiiLJPfbAw+ifXpn3SiJn0n+Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P18901MB0111 Archived-At: Subject: Re: [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: Mon, 20 Jul 2020 07:48:37 -0000 --GGkDQnboQjeoiYo4Nrjvhznj8IW3WxoXI Content-Type: multipart/mixed; boundary="akVThksettACpsxXrVzw4MBtsuBS0x4nY" --akVThksettACpsxXrVzw4MBtsuBS0x4nY Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Jim, Thanks for this review! We have processed your comments in the latest version -02, with one open point left for discussion. Please, see our replies in line. Best, /Marco On 2020-06-07 18:22, Jim Schaad wrote: > * 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 it= self? > Path tends to me to say only path. =3D=3D>MT Right, it's intended as full URI. And yes, the Administrator and the Group Manager can be in totally different machines. We have renamed the parameter as 'joining_uri'. <=3D=3D > * Section 2.3.2.1 - I think it makes more sense to make all of the defa= ults > 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 docume= nt. =3D=3D>MT We have moved the default values of the configuration parameters to a new section in ace-key-groupcomm-oscore , while we keep here the default values of the status parameters in Section 2.3.2.2. <=3D=3D > > * 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. =3D=3D>MT We have updated the parameter definition to be the CBOR simple value Null, if no description is provided for the group. The default value defined in this section has also been update to be Null. <=3D=3D > > * Section 2.4.1 - I am not sure why this is a subsection of 2.4. =3D=3D>MT It should in fact be a self-standing Section 2.5. Now fixed. <=3D=3D > > * 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 o= n the > part of the AS based on parameters in the group definition or the expec= ted > usage of the group? =3D=3D>MT No, we don't mean anything so specific. We wanted to capture that the Group Manager may still trust the suggested AS, but already has a different associated AS to use. We have updated the text in current Section 2.6.3, limiting the error cause to not trusting the suggested AS while at same time not having any alternative AS to consider for this OSCORE group. <=3D=3D > > * Section 2.5.3 - I think it might make sense to return at least some o= f 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 a= ble > to start populating the RD. =3D=3D>MT We have updated current Section 2.6.3 accordingly, and further included 'group_name' to the list of parameters included in the response. Along the same lines, we have also updated the response to a PUT request updating the current configuration, in current Section 2.6.5. This applies at least to the case where the Administrator specifies a new AS, and the Group Manager rejects it but has a better one to use instead, and indicates it in the response to the PUT request. In both sections mentioned above, we have also added text describing how a registration/update in the RD can follow, for the link to the group-membership resource of the created/updated OSCORE group. <=3D=3D > > * 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 l= ittle > additional penalty since I doubt that GM Admin clients are going to be > constrained. =3D=3D>MT It is possible to have two separate parameters here, i.e. 'group_name_admin' and 'group_name_members'. They would both point at the same OSCORE group, but: - The Administrator can use either of the two to retrieve the same group configuration. - The Administrator uses 'group_name_members' for publication/advertisement or for registering a link to the group-membership resource in the RD (where that group name will be the value of the attribute 'sec-gp'). - The candidate group members end up using the group name 'group_name_members'. So, it's true that there is no real penalty in doing this, but what's the actual advantage in having this distinction? Is it about making it allowable for future use cases? <=3D=3D > > * Section 2.5.5 - The second paragraph makes zero sense to me. The th= ird > paragraph should just be talking about the update message and not mixin= g the > create and update messages together. =3D=3D>MT In current Section 2.6.5, we have rephrased the second paragraph explicitly mentioning the error handling on the request payload, analogous to the one for the POST request for creating a new OSCORE group= =2E On the third paragraph, not sure where we referred to group creation. We have anyway pointed more clearly only at the PUT request for updating the group configuration. <=3D=3D > > * Section 2.5.5.2 - I have read this section twice and I still do not t= hink > 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 t= his > easier? =3D=3D>MT We have shortened and revised the text (current Section 2.6.5.2). Please, have a look. <=3D=3D > > Jim > > s/fowllowing/following/ =3D=3D>MT Done. Thanks a lot again! Best, /Marco <=3D=3D > > --=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 --akVThksettACpsxXrVzw4MBtsuBS0x4nY-- --GGkDQnboQjeoiYo4Nrjvhznj8IW3WxoXI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl8VTEYACgkQ7iZktA5Y 2kMg4gf/aKfpC3bv9/OQT5nzrroudp3n+kKfdBVA7T/UEdRc+RXIr4m8lDJ5uXGr UABvx0dxDyfs/AE3meeebA9a4G4An0dxs6QKTnDG++cDi5adNwQZpWbRGy4zU2LA RVcRRmM8ImTmoklgyJb8vIsAHkdMA/OlpyDsG0ELOkEy9cCrTz3Ha1nQkmS/eeFQ NWIksjkcFVfVkqB/MFEhpydoINTy4aWgs877KK8auS0wOImMlhgNYMoeL8+gqJfM 5GICPcEZLXP3l869dlRaHReUZQfm28ZjdhXzQY+BkyYndwg8PHdvHlNpN9W2nwju +hG3EB7yZpfCytbFYt/lHoz/HIDwOw== =K2uC -----END PGP SIGNATURE----- --GGkDQnboQjeoiYo4Nrjvhznj8IW3WxoXI-- From nobody Mon Jul 20 00:59:25 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 AE5E93A0033 for ; Mon, 20 Jul 2020 00:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-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=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 29iexkz1FZmY for ; Mon, 20 Jul 2020 00:59:20 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2089.outbound.protection.outlook.com [40.107.22.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 07A913A0029 for ; Mon, 20 Jul 2020 00:59:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SCuqXesMKbT0YaAW2qGoLIAIWI6XbY5E0egO5/HPL8xMTfBXEbCgz75A4J7mjlIW9Eh53u+wotcmTgnv+ScHft9Z0L8AH/d1k1Yw7TURC1jutS5pTtT0UyXOmLgXyGYb5l/7m4YJb9Vpx8bpAFEw0+Zz4eBnKUTTgXiAFnIGT2/RwU9KmRWn40prVYzY4xIO4LNdzHEWPwkbKOHj+DPLDfhBi/PGoRWTTaXcTPmrVJGxpBSDn0/GxyQJdqJt2mIJ1QlyFj1ijA/fq/DFQk37oMCaD6TpKmHhuxu/wNyxqhw1FhFqDmTzxPjlv+RUhQVOQVYzMi/4V3JakWIAvEDJfg== 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=66GlW1uCx4nrahzM15KWFPFNctwsRsnPVJn7VHJ7tGA=; b=ZTFOWO/rl2cFUuTDApGUKCObOsljkh7qnggV3CNZZEqLM5DHk5joR4ZWAwinakDzlD3ompZvSd9RKtIryC8EHAIPFpch3j9FLcdjqpTleTnzKoLqmAaTx0zXvux/3MmziCsMWu5loQ/73inI//8KNfSI/RKhbOzzsASm8gyyxGi68IHlQxQQ8ekPz/vmRgv7goRJ7E5oPi7JSEBwChuLcjr9ZAHq28NxblpFlHPlK/keYltcwzDuAbOG1Weq1tZu67zOGbCu2SoH4ZezwOHHl+ZTac+YOtTSJLrk5JehFLt5D7kgneVyX9hrMDJ6PRMLnkTwS19xYDfXOUVZn2ktZw== 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=66GlW1uCx4nrahzM15KWFPFNctwsRsnPVJn7VHJ7tGA=; b=AmnxPp2SXsVFWXQGH1UsA/3pNcJaX1W4w6ssKv2vx5TT/XbBA3EPUO3XoXcB7FYTOSgqDOssJe/bSjaD88O7INDOMBNhCYrigSzy6ohq6So4DfD21Y1NA+O29ZOhqaMwnMoo+sE5YGom8wZ63KCLYdgWLZhGE/W3MtGIA7vDo9E= 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 VI1P18901MB0784.EURP189.PROD.OUTLOOK.COM (2603:10a6:800:127::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.23; Mon, 20 Jul 2020 07:59:16 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2%6]) with mapi id 15.20.3195.024; Mon, 20 Jul 2020 07:59:15 +0000 To: =?UTF-8?Q?Christian_Ams=c3=bcss?= , ace@ietf.org References: <20200703065558.GA559393@hephaistos.amsuess.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: <882de884-c1d8-96b0-3281-39a2965c4519@ri.se> Date: Mon, 20 Jul 2020 09:59:08 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <20200703065558.GA559393@hephaistos.amsuess.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="m1mmPUNhBLOFVLkfJhOWtc8sL3Df7u06w" X-ClientProxiedBy: AM6PR02CA0029.eurprd02.prod.outlook.com (2603:10a6:20b:6e::42) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.3] (37.120.131.76) by AM6PR02CA0029.eurprd02.prod.outlook.com (2603:10a6:20b:6e::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.18 via Frontend Transport; Mon, 20 Jul 2020 07:59:15 +0000 X-Originating-IP: [37.120.131.76] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 363f76ed-0821-41a0-f68a-08d82c82cc36 X-MS-TrafficTypeDiagnostic: VI1P18901MB0784: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: SLmadX5NMS4rWzfgbkrVX7BkKVyzG62zoxvOWpRlJUzkN0LZN9SvTQBxTa7keLM7aiyHbBJpmZdloTGpaC4DtXc1RwYwURNFuBwfl6Ol1SqbYUk5n8Chdkl6ic/KNJ82rl6+b+GHfkrpU3J5x9SxqC7MEBf+Fio8BjQz3Rha/vdct49jJAtXC6JVVE3Qe/Z/f3cBmW7dXpofHc6pRrNN13aKeRfW19YotG/uRJ8qqq8xyc57tunJE2DsvnJMouQmNzI2qYevHA5PDMy9zyVxaBs9gx2d2O5Fm4tmHdWYakNPaRnFibpbzTJUxmSOoY2zcs84Z562BZCEF/Xs6pKn+vD8HGs1PnxEIDCynIppZsxck7qxj/jLJ8ln/Aws0hoLlNBihv8KU4eUnW6N6K9suEoSPMSgvfi70s+uz+NwSDYKRNOk40BuNp/dxQPi8MmOXir8HKxzm8kzZEdRDkjrMg== 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)(396003)(376002)(136003)(346002)(366004)(39850400004)(53546011)(186003)(16526019)(66476007)(316002)(2906002)(6486002)(8936002)(478600001)(26005)(21480400003)(2616005)(86362001)(5660300002)(235185007)(44832011)(31696002)(66556008)(66946007)(16576012)(956004)(52116002)(66574015)(966005)(6666004)(31686004)(36756003)(166002)(8676002)(83380400001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: pLAryEhnDXb769Nqkkl+HYMqnY8BHs5pd9VHX8PZ2NkHRAvV1LY4TwX942Q1rHHZu12FGrxZy1ZwmGDO4LbiDa10EPxZUI3dlzS2E0MKquNTmuHJAkC/0evyoz2JbAITDgmeQHm2Yf0ZoH3A6WG8temjwf1zqsgF4CqR2iQX1MIKWZx40hhcCa1eHIPZxFRPA44bmFwGLXr7BXL5WW04KO/rU1xV3K6hnmIDBkNUAspFU3TyFEgR3BwNynoJB+EpdJz1I4F3qUnacGeKcz07iov5HIl9EUXJ2CKXFwGzyF93UmGuaMxxLG7pHoz2KebDz4WssRrnexwP3LLXykLiZ7w3EYaNmKOqP3R6zCxPwdPtfo4VJwHhs3CaRbF8fkB/h3ufz7kxOR+dPue+5+vcT41uc+N5etT4vNGJJBVge2KT779cr7cWmky5jizOhsb+9cmeUEXDIs47xaxgbRCXptfy/9Ut+G0IC3eM3Cz9jKc= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 363f76ed-0821-41a0-f68a-08d82c82cc36 X-MS-Exchange-CrossTenant-AuthSource: VI1P189MB0398.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2020 07:59:15.8848 (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: Y8QMGGmY4SFCd9La1fv4V3KQm7mrnRjGPYprJCffkMZzH23d36GPlm4xQ8P9Q9R60+kt6Hl4Cm4d1n/tAMyuEA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P18901MB0784 Archived-At: Subject: Re: [Ace] Call for adoption draft-tiloca-ace-oscore-gm-admin (with some review items) 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, 20 Jul 2020 07:59:24 -0000 --m1mmPUNhBLOFVLkfJhOWtc8sL3Df7u06w Content-Type: multipart/mixed; boundary="dodrX1ubN35lIS1NTkCzZwLHM7AYaVY4V" --dodrX1ubN35lIS1NTkCzZwLHM7AYaVY4V Content-Type: multipart/alternative; boundary="------------39777E5C0D7D0E794919E579" Content-Language: en-US This is a multi-part message in MIME format. --------------39777E5C0D7D0E794919E579 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Christian, Thanks for your support and comments! We have processed some of your comments in the latest version -02, while some are still open to cover in the next version. Please, see our replies in line. Best, /Marco On 2020-07-03 08:55, Christian Ams=FCss wrote: > Hello ACE, > > I've read through draft-tiloca-ace-oscore-gm-admin. Its value is in tha= t > it fixes a gap in the set of current drafts on the topic: > > Without (something like) this, group deployment applications need > application specific group managers, and as the GM is not trivial to > implement, I'd expect that they would bundle the GM with their > on-at-deployment-time tools rather than ship a constrained and > well-specified always-on GM that's just managed by their deployment > tools -- leading to much more error prone deployments that can't > leverage OSCORE group communication in full. =3D=3D>MT Right, we have added some text in the introduction, based also on a related input received from Carsten during the ACE interim in June. <=3D=3D > > I don't quite see myself in a position to advocate adoption in this WG = I > haven't actively contributed to before, but I do support this document > being processed somewhere in the IETF. > > Best regards > Christian > > > PS: Small by-catch issues for the authors: > > The pct-encoded names in the group name sound odd to me. What do those > names have to do with URI components? =3D=3D>MT This slipped through in the latest update. We'll remove the statement in the next version, i.e. the sentence can end with "... that are valid for a URI path segment". <=3D=3D > > The "is fixed" and "is a default name" terminology around resources is > probably confusing to people who don't know ahead of time what it's > supposed to mean; moreover, demanding that the URI be fixed is a pretty= > harsh requirement for something that may move around in the network; > furthermore, while an I-D should avoid creating URI aliasing, it > shouldn't rule out that the server may do that either. (And if it > supports different transports, right now it needs to). Later in 2.5.3, > it even sounds like the path is prescribed. =3D=3D>MT That's actually intended for the uri-path . We have updated the text, avoiding to talk about fixed resources and default names. OLD: The URI of the group-collection resource is fixed and has /manage as last path segment. The url-path /manage is a default name: implementations are not required to use this name, and can define their own instead. NEW: As an example, this document uses /manage as the url-path of the group-collection resource; implementations are not required to use this name, and can define their own instead. <=3D=3D > > Other than this being an ACE document, is there a particular reason > "Getting Access to the Group Manager" is prescribed to use ACE? The > whole 2.1 section sounds quite repetitive when read in the context of > ACE, and unnecessary when different methods are employed. Maybe if ther= e > were talk about different admins and whether they may change each > other's groups that'd be conveniently be expressed in terms of ACE > scopes (not sure), but as of now it isn't. =3D=3D>MT Yes, we can explore more about different administrators managing common groups. More generally, this management process is supposed to work side by side with the joining process, for which the Group Manager uses ACE. So, it just felt natural to think of the Administrator as also another ACE Client at the Group Manager. <=3D=3D > > Why is "Update a Group Configuration" a PUT and not a PATCH? It does no= t > replace the resource, it just modifies it. =3D=3D>MT Everything that is not specified in the request is completed considering default values. We will extend this to support PATCH and selectively update only some parameters. Thanks a lot again! <=3D=3D > > > _______________________________________________ > 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=E5ngen 16 SE-164 40 Kista (Sweden) Phone: +46 (0)70 60 46 501 https://www.ri.se --------------39777E5C0D7D0E794919E579 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Christian,

Thanks for your support and comments!

We have processed some of your comments in the latest version -02, while some are still open to cover in the next version.

Please, see our replies in line.

Best,
/Marco

On 2020-07-03 08:55, Christian Ams=FCs= s wrote:
Hello ACE,

I've read through draft-tiloca-ace-oscore-gm-admin. Its value is in that
it fixes a gap in the set of current drafts on the topic:

Without (something like) this, group deployment applications need
application specific group managers, and as the GM is not trivial to
implement, I'd expect that they would bundle the GM with their
on-at-deployment-time tools rather than ship a constrained and
well-specified always-on GM that's just managed by their deployment
tools -- leading to much more error prone deployments that can't
leverage OSCORE group communication in full.

=3D=3D>MT
Right, we have added some text in the introduction, based also on a related input received from Carsten during the ACE interim in June. <=3D=3D


I don't quite see myself in a position to advocate adoption in this WG I
haven't actively contributed to before, but I do support this document
being processed somewhere in the IETF.

Best regards
Christian


PS: Small by-catch issues for the authors:

The pct-encoded names in the group name sound odd to me. What do those
names have to do with URI components?

=3D=3D>MT
This slipped through in the latest update. We'll remove the statement in the next version, i.e. the sentence can end with "... that are valid for a URI path segment".
<=3D=3D


The "is fixed" and "is a default name" terminology around resources is
probably confusing to people who don't know ahead of time what it's
supposed to mean; moreover, demanding that the URI be fixed is a pretty
harsh requirement for something that may move around in the network;
furthermore, while an I-D should avoid creating URI aliasing, it
shouldn't rule out that the server may do that either. (And if it
supports different transports, right now it needs to). Later in 2.5.3,
it even sounds like the path is prescribed.

=3D=3D>MT
That's actually intended for the uri-path . We have updated the text, avoiding to talk about fixed resources and default names.

OLD: The URI of the group-collection resource is fixed and has /manage as last path segment. The url-path /manage is a default name: implementations are not required to use this name, and can define their own instead.

NEW: As an example, this document uses /manage as the url-path of the group-collection resource; implementations are not required to use this name, and can define their own instead.
<=3D=3D


Other than this being an ACE document, is there a particular reason
"Getting Access to the Group Manager" is prescribed to use ACE? The
whole 2.1 section sounds quite repetitive when read in the context of
ACE, and unnecessary when different methods are employed. Maybe if there
were talk about different admins and whether they may change each
other's groups that'd be conveniently be expressed in terms of ACE
scopes (not sure), but as of now it isn't.

=3D=3D>MT
Yes, we can explore more about different administrators managing common groups.

More generally, this management process is supposed to work side by side with the joining process, for which the Group Manager uses ACE. So, it just felt natural to think of the Administrator as also another ACE Client at the Group Manager.
<=3D=3D


Why is "Update a Group Configuration" a PUT and not a PATCH? It does not
replace the resource, it just modifies it.

=3D=3D>MT
Everything that is not specified in the request is completed considering default values.

We will extend this to support PATCH and selectively update only some parameters.


Thanks a lot again!
<=3D=3D




____________________________=
___________________
Ace mailing list
Ace@ie=
tf.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=E5ngen 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www=
=2Eri.se
--------------39777E5C0D7D0E794919E579-- --dodrX1ubN35lIS1NTkCzZwLHM7AYaVY4V-- --m1mmPUNhBLOFVLkfJhOWtc8sL3Df7u06w Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl8VTswACgkQ7iZktA5Y 2kM4HQf+MIvaNC6GuzSmSZsXWSqqB9xZKYIxB7MdbFhni3jCI6Zb6zGQ8bD3mIaZ dwnBlog1PXn4DHbPH+g4WX1hGElhqwHB+K75vNH4z7wjTmyyWkiNebeYQhDocw8F xLwmM5WvGHmFUYEliGfXA4jg8G9KAgbHNZiiYZVQj280uWMRMg70bJVrms7wJVfO +bWhNCRUCk/gtygOTqZ1dsPl9BiA2akRh0xBTPnXYsFTZhW/WkrYldVIix1TRUmK WHIDATRYo4nniTPlZiCz4SQ2TCDkI6mOg9I2gq+FOr5rteZyeGKA3sB678u0jvID RtqoHAc6smcChFa5HAjEtLdc2xD/Ag== =CJAN -----END PGP SIGNATURE----- --m1mmPUNhBLOFVLkfJhOWtc8sL3Df7u06w-- From nobody Mon Jul 20 01:11:48 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 C9C873A0764 for ; Mon, 20 Jul 2020 01:11:46 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-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=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 QQaAEHyI7Ai3 for ; Mon, 20 Jul 2020 01:11:44 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2065.outbound.protection.outlook.com [40.107.20.65]) (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 89DE63A0744 for ; Mon, 20 Jul 2020 01:11:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cl3r5Xaa3IQ8TdGN3MYJeONCJc3ayNI3SmH1O3vb72H3zWYhep4n4TeFPYVptIEWObiA30R/Lq87NAbFpPErmynQ52TVbV9qIA+aKJHD0p5jdawU55sfES21aja6wN8lPS71RVZKUQtp+HJ0Q7iVP5YGCdJhCRv2bkyPXc3EQTGOjCBa6QbJOFn1oOkPAm2Sf2kCZ9W1oPouP5XIDykZsRC2nvOclPqFrfsAUiBb7igOJp3iyMNnvR+LMr0Sjiiw4QuEwWptBRVfL+ubJj8aKc4JCEsSZ9e5It/izbb4+3JkdHpPJf49+XlscZ2lLPyHeefR3Nl805sDKKweB83d4Q== 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=tn0+JrsKlRjHBBN80KQKBraYVZ5Jne28aL0mnU5jp3o=; b=Zb7wYShwSBbCujVKELh4nq2DVVcfAMwv+D14oiZ0DqtDBPhEyLRSet78rdZG/ijM1nS93KPMADKNqC6mCAdA6UEWXknSqYY/HpgpFTXiZasaN/y87I9eq1QIMRWH7srAg4B6LUOY5kTMF7PGt2uR2vPwBBPw5XhXMBQyMPvFjuLzBi/au7FyR2rn27VNt28QMtgTEE423qi1tnhFG2rA4c1D+I4Jg9af8yT54ZqgWid88eTtT5JKITsIDaF+RE8Agyi8UqpPwx2jfJXVkbCTf2jQSB7sx7ZoGM+tGhSed3h8MrUMn0leD1tswCGy2fAkoOMEXvVuNSzS8MImpz2wag== 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=tn0+JrsKlRjHBBN80KQKBraYVZ5Jne28aL0mnU5jp3o=; b=Ye8Q/j6H8Cy0tFDEBb+e1thJAQlj+SXGlQGSAm8Fuc37VKZmi++uRG+Uw+kf3xxt6GB1eD0yYj/QlqwtPYT5d+fCcKcV0wP4XhpJ1TRkbwAb3tXlfoQSJy6AYggUBZa1xOmGtW/wGnJLSgHeOLKGsPMGRIkX323AfW5rQxDN4+I= 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 VI1P18901MB0671.EURP189.PROD.OUTLOOK.COM (2603:10a6:800:11c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.24; Mon, 20 Jul 2020 08:11:40 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2%6]) with mapi id 15.20.3195.024; Mon, 20 Jul 2020 08:11:40 +0000 To: Carsten Bormann Cc: Ace Wg References: <158378192037.5591.12867128151701682367@ietfa.amsl.com> <2553abc4-aa8d-2c51-f0fe-1e14cd6ac1e9@ri.se> 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: <96efdc92-834b-d854-13c0-03a2350640ed@ri.se> Date: Mon, 20 Jul 2020 10:11:30 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bi6TFZjBXl4Ww115ShGuuiP4xnQE9HMro" X-ClientProxiedBy: AM6P191CA0004.EURP191.PROD.OUTLOOK.COM (2603:10a6:209:8b::17) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.3] (37.120.131.76) by AM6P191CA0004.EURP191.PROD.OUTLOOK.COM (2603:10a6:209:8b::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.17 via Frontend Transport; Mon, 20 Jul 2020 08:11:39 +0000 X-Originating-IP: [37.120.131.76] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a1a68933-abec-4d35-8cf3-08d82c8487e7 X-MS-TrafficTypeDiagnostic: VI1P18901MB0671: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 6ze7HFQY3JVt+2JnbFdSq79veDKDTMiIkCbo70zIK8WQZkI5ZOduVye8I5KMt68Xe6YWnCGAyHWA0NIlduf7TPQcwJjUX35zfajSkPpicamOtXww1dz94sO8ZI8PaT4UNYFxkCHNegkZdFgwkL/EbyknwKIH1NBftVf1If6AMDW9pdoDe2OESH0zs6CZl6rJouVD/ehp/tMCjQhkNDognloPa/9fPGEi6i9O2JCKul5YasFabG4AjtmX50hEGX72VQocgt92maWCNFspE1ad5OEEdZT9597CumMUWl1OzC+D6OmCdKWefyqDTFyAJwAYrs7t5RvL4KXX4IH1FX7XuoQo9CIdWhQ0POTMF/mKwngsfO3ug+YRJB1Kl1t9Csz7foHSEL/xWK23J8Fu1CYFMJSJQEQfzLI2jHDfpZtjVHYAwxn/gKNYV3mfPqgrbHXFes8HpTv6kIrtaCLGhqcjVA== 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)(396003)(39850400004)(366004)(136003)(346002)(376002)(186003)(86362001)(52116002)(6666004)(16526019)(4326008)(26005)(478600001)(966005)(6916009)(21480400003)(15650500001)(31686004)(6486002)(31696002)(8676002)(66476007)(66556008)(66946007)(316002)(16576012)(5660300002)(235185007)(956004)(8936002)(66574015)(33964004)(44832011)(2906002)(83380400001)(2616005)(53546011)(36756003)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: fDDFww+rgx0vsbUkcw2UFZzwNA2ME8/CYNJjCevxYKzuMOYD+jABKyEWJmZ3a51XPSmodBXRPpDf8gkeTg3B0LMEs9CZpu/zcEHzkA1zegsjR07u7Qk0ApFIuKowngvK/qbM7KRFtEkZXcrYJxcIf/re6+U7piEgvqk6WFuOrCFXCUNSch6jzZlklZDssj7QPFrPRqFVbqiH3jbVnqHtDskhZ3M35+uFzrB9lVB0tPJoeZoDa9ykCDDcVmeZl0CvtE9icHile9SdhczrSfZV7zT0bd+ESMwHF3Uu4c/Ix4hMIpUnI7V1c7r4WXJSJUjC9/mMRTIUnAQkZ+ycGwtgkjfd1F7DB2L0ZMKuXCXbgcLzdcO9cX8bhpf0uMBjCJQ8kOuHBE4EW+1bkWngoLi2T8X1BAhbhMbtTZwdi+aPfPLtkvtorBaG3D+eVsKUki35BgNwsH4y/MCgFRqIUqThA6L3/tDYQMil9gEMVH0K6Lw= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: a1a68933-abec-4d35-8cf3-08d82c8487e7 X-MS-Exchange-CrossTenant-AuthSource: VI1P189MB0398.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Jul 2020 08:11:40.2358 (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: AJpSpu/PluhFRLEs6Su2v5GjOw2qa6a9WrtObwTj71UAyUnSzHNGc3f2LnAa4SQp0bfHB45VM2tom6G1mzf5lA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P18901MB0671 Archived-At: Subject: Re: [Ace] [ace] Fwd: New Version Notification for draft-tiloca-ace-revoked-token-notification-01.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, 20 Jul 2020 08:11:47 -0000 --bi6TFZjBXl4Ww115ShGuuiP4xnQE9HMro Content-Type: multipart/mixed; boundary="mkrxG7DXFDnHyzlb01TqvTFjxJqpVxahp" --mkrxG7DXFDnHyzlb01TqvTFjxJqpVxahp Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Carsten, Thank you for this review! We have addressed your comments in the latest version -02. Please, see also our replies in line. Best, /Marco On 2020-05-18 13:40, Carsten Bormann wrote: >> Comments are very welcome. > (1) I can=E2=80=99t parse > > the binary > representation of the String value of ENCODED_TOKEN, which > would depend on the used charset. > > What charset? JSON does not have a charset. (I=E2=80=99m probably mis= reading this.) > What *is* the =E2=80=9CString value of ENCODED_TOKEN=E2=80=9D? =3D=3D>MT We have revised Section 3 on the computation of token hashes, now giving more step-by-step details and providing examples. Hopefully it is clearer now. <=3D=3D > > (2) query parameters: diff=3Dtrue and N=3DI are a bit redundant to each= other. If you have N, you need to have diff=3Dtrue, which therefore can= be omitted. diff=3DI or diff (no equals sign) would therefore be simp= ler forms of this. =3D=3D>MT We have followed your "diff=3DI" suggestion and revised the interface accordingly. <=3D=3D > > (3) Re CDDL: I read this as > > token-hash =3D bytes > trl =3D [* token-hash] > diff-entry =3D {removed =3D> trl, added =3D> trl} > diff =3D [* diff-entry] > > removed =3D 0 > added =3D 1 > > I would simplify diff-entry as a record instead of a struct ( https://t= ools.ietf.org/html/rfc8610#section-2 ): > > diff-entry =3D [removed: trl, added: trl] > > i.e., leave out the labels and rely on the order in the array. =3D=3D>MT We have redefined the payload format in Section 5.2 to use a record as diff-entry, according to your suggestion. <=3D=3D > > I didn=E2=80=99t make up CDDL for the registration response, as I don=E2= =80=99t know what the =E2=80=9C=E2=80=A6=E2=80=9D is. =3D=3D>MT We are considering the details of the registration procedure and its response as out of scope. ACE does not detail the registration procedure either [1][2], while OAuth gives non-normative examples [3]. [1] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-35#section-5.3= [2] https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-35#section-5.6= =2E2 [3] https://tools.ietf.org/html/rfc7591#section-3 <=3D=3D > > > (4) Why do we need all that precision what was added and removed when? =3D=3D>MT This was the result of a design discussion with Jim. It is a robust way to handle Non Confirmable notifications, as the AS would not know for sure whether notifications were successfully delivered. <=3D=3D > > (5) On the diff stream, please see also STP:=20 > > https://tools.ietf.org/html/draft-bormann-t2trg-stp-03 =3D=3D>MT We did and, combined with the input from Ben at the June interim, it was very inspiring! We have added: - The new Appendix A, discussing how the diff-query mode is a usage example of the STP. - The new Appendix B, discussing how the diff-query mode can be further improved according to Ben's suggestion, by using the "Cursor" pattern from the STP document. As mentioned at the June interim, it can be worth considering this as a third mode of operation of its own. Thanks a lot again! <=3D=3D > > Gr=C3=BC=C3=9Fe, Carsten > --=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 --mkrxG7DXFDnHyzlb01TqvTFjxJqpVxahp-- --bi6TFZjBXl4Ww115ShGuuiP4xnQE9HMro Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl8VUbIACgkQ7iZktA5Y 2kOGEQf+IjoKzqPWhScM9xiB0uSrDUVIm7rN6xm9OeRdh1SsRbuq4drJLDK0B+gZ wfpdsYZBZEeqRlfE/YQDWxLuWlVIDfs7Hobgp3KmACmgS1D8vj6UNjziFHwmadYS mwGFmceBChAg5Px+i1iwBPcDdqUzxIGkAjdgPudvO5ohOOycYcDFnJcsRvi2ocQV /l6dTBvZN+VK2PsoXgvNJL+WMlq26O6z534LI0ys3FI1uNxr4NyGm56rpJXuGv38 28Jk6zoEDoT+b3pag2TaQYX79/oEyXojMUDdakwaaP5vsNX7BpjAOH8hBcSltBwF 84qoVNcVheGYJfmM+4M8cQMJruqPag== =p370 -----END PGP SIGNATURE----- --bi6TFZjBXl4Ww115ShGuuiP4xnQE9HMro-- From nobody Tue Jul 21 08:59:37 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 CF89B3A0B54 for ; Tue, 21 Jul 2020 08:59:35 -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 S8BmJhz-g2Tf for ; Tue, 21 Jul 2020 08:59:34 -0700 (PDT) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 7F1043A0B50 for ; Tue, 21 Jul 2020 08:59:34 -0700 (PDT) Received: by mail-ua1-x92a.google.com with SMTP id i24so788558uak.3 for ; Tue, 21 Jul 2020 08:59:34 -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=djmtg25uEzKulLOdKAQso6s8hYXN/cm3ob+LkENH4RY=; b=gtRieNoAdwXBMj1y/m5BkAvusLKUfkebFg13wd3gAfkq38/OVGm7Q11M3lZZoi25E+ pR5CCaIP7aL96W+IX9dyzkUhOL95ge2uUi1rz3yfABR4REkJIS1gaYDNRlGm+TUgrJRF b4k/2BKoPELA7Wm7PGbB27hfUYhcriW5x/a0+CJoLLiHrMXo3aFwjknaLDpjkR3xBiTE 8EmP9uCxFQev+pxm35u8PC4m/J3sHOJTaLH8Z6UT4V+HFOzX6VsTUTcpPTdcT27S7obs Sfr0uXUgEbrRodmMa4bXf6G7uYA45ax2AGPRaF6QmPcfWj2vQgNCiL7mXhrmE8wTapI8 DJYQ== 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=djmtg25uEzKulLOdKAQso6s8hYXN/cm3ob+LkENH4RY=; b=iEs3JVLW2QhW2kRK8gDrp2G+vPOZpjGD7FCd3ICOqFR09eGNx2EnOS0ynK7vPQb0rG YoLEJV0rz272quQodnuwo4U6RUPJyuLvW0i/swBT37bZuysSrr1vYdReXc0uxeAs2cSf 9Y0rJy/2u+rUaxQ3cNSPe2pgyyEkjNN6Rr3nnux4pzyg/sVfZnCqoJ8JY9nryBcSnXG6 bWfPbu0vveHFho338YzK9AvaGzYGJ5+z2RX+dzZQMxDvwdu030CnO+0pFhTPba/sOmKu iBhgwPZ5CifcBOnnFuE8QvJN5d4NKsXl69QILkYut9Ihcv5PvJ+cP8DZ9k7wjV8PkYol fT/g== X-Gm-Message-State: AOAM533emmmj8nJBWszsSXSLCwHYkiixeA+8HS8Kup38EyH/QWhdR+AY 1XHUalSpq496e+1M5V917oHImOtv4KuRpzVADnywVA1c X-Google-Smtp-Source: ABdhPJz4DKv2EqhPB8va0uBunEztd3WuF60OkPN8cf4iWPgdYNUIhPBoA519KDJQHCmD9xjTS3UozW8wRpy/wY23PJ4= X-Received: by 2002:ab0:48c8:: with SMTP id y8mr19770865uac.114.1595347173261; Tue, 21 Jul 2020 08:59:33 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Tue, 21 Jul 2020 11:59:22 -0400 Message-ID: To: Ace Wg Content-Type: multipart/alternative; boundary="0000000000008e46ba05aaf5b5f4" Archived-At: Subject: [Ace] interim meeting planification 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, 21 Jul 2020 15:59:36 -0000 --0000000000008e46ba05aaf5b5f4 Content-Type: text/plain; charset="UTF-8" Hi, Please find a doodle [1] with two time slots for the interim meetings that are planned 1 per month the first week of the month 10 AM - 11 AM EST. The two proposed days are Monday and Thursday. Please select your preferred day by July 26. I am sending the calendar serie to the ace list so everyone can better see how it matches its calendar. Yours, Jim and Daniel [1] https://doodle.com/poll/x2dghwiqmqei6cc8 -- Daniel Migault Ericsson --0000000000008e46ba05aaf5b5f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Please find a doodle= [1] with two time slots for the interim meetings that are planned 1 per mo= nth the first week of the month 10 AM - 11 AM EST. The two proposed days ar= e Monday and Thursday. Please select your preferred=C2=A0day by July 26.=C2= =A0
=C2=A0
I am sending the calendar serie to the ace l= ist so everyone can better see how it matches its calendar.=C2=A0 =C2=A0

Yours,=C2=A0

Jim and Daniel=

--
Daniel Migault
Er= icsson
--0000000000008e46ba05aaf5b5f4-- From nobody Tue Jul 21 09:00:00 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 6634C3A0B54 for ; Tue, 21 Jul 2020 08:59: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 XnshmwuoM8-M for ; Tue, 21 Jul 2020 08:59:54 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2053.outbound.protection.outlook.com [40.107.244.53]) (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 918143A0B50 for ; Tue, 21 Jul 2020 08:59:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JCEr62pHnUoc6FvRrhRcY6/EIdYbYHRA2M1l6qv2Oss0lqemPvFEw/WpwshS331emLSjEbn8+LmXCYppTT7QcBa0TuAx3Yv4qNNDMF6T0To0dSrLJRrkXs4hBbV7WwR/+MRdD+FTbV9H2dVLnZQ6PRDSvgppGJ56hVo3Pr6NiNPrwEa82CEpKJ1naQZunrErrVk6fOOax7xwnb6lr6adr4EIV5CO0ub3TMBScYb+0bJRpErvtjc0zICYqEM6t8B4ryBCbBxJSWhIE/5opStJbiwylVl3fEAJkGfGB3NYzdPTX9X8pq3cFm5ZvYqZhuH5cJqhAZx1W9MrKvSO+nYkJg== 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=o+uwCo3cEb09YgDwkxRuFo4hLFAb6Eut+G8Ao3XS5ms=; b=bxqI8vJPvpo9Yfi+8xUBDrhtpvO6VeOoYz5rwKh+VKmNXCyRZZOrYPpOCTyJxdHOq1fB6rwshL9tQB3M5bjvfc5PmcIUEbrf0z+Og9vpVGcNH3sDuOqBWyb7CbwNBSupGohCJWbrZCZkccWhIIPzc7/UhzdybsFSXMu6KjFZsqPk4bXpbtBfcMhGjE/cIBZtmotUAIE+Jut6AcrTgj5VBc+kqbphEMKQXvOUbEosjyF5zCBOdsHZY0NMv6zUI8+/V1Kaes9iiZRKmqpiHzZch5kpLjGLWtsQdlGFq0p1aLD814JVTF39QkImvvzz/05/xEY1k6pGrlA7CPSxWEqJxA== 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=o+uwCo3cEb09YgDwkxRuFo4hLFAb6Eut+G8Ao3XS5ms=; b=hs1lXcDk0vNAG3YRumBgnTCvoFuPCE/MEkw7S54QTnDawVOd+ExIxvac5Wsy7N/bkSAtBRFp71MRNUYYucLplNl7BnuI0CWYLl/souTe75iLwaCSrzKE+GFiKI8wrG0SOJECWAFtrHIRcbr+JbzYv9DyWFCacNnpsc9I4OyM5DE= Received: from SA0PR15MB3791.namprd15.prod.outlook.com (2603:10b6:806:8d::10) by SN6PR1501MB2192.namprd15.prod.outlook.com (2603:10b6:805:12::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.23; Tue, 21 Jul 2020 15:59:53 +0000 Received: from SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::3005:5e4b:252f:e9d1]) by SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::3005:5e4b:252f:e9d1%4]) with mapi id 15.20.3174.030; Tue, 21 Jul 2020 15:59:52 +0000 From: Daniel Migault To: Ace Wg Thread-Topic: ACE interim meeting tentative (Option2) Thread-Index: AQHWX3f4+ExZH1PwtkmFRgVQ81IInA== Date: Tue, 21 Jul 2020 15:59:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAAAAADB1MlLcV/WAQAAAAAAAAAAEAAAAAoo6O6QeX1Plnwd9W37qJ0= x-originating-ip: [96.22.11.129] x-ms-office365-filtering-correlation-id: 2ea86390-3825-48f9-5ac5-08d82d8f1aff x-ms-traffictypediagnostic: SN6PR1501MB2192:MeetingMessage x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1728; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8tYwWGqYc1qF0oUa1YP+FA7ylYkZRmop9RfROgVxLSWlXxzn6tuTypRVOjK4P+7+HRcDxzZigc7V4FCrY1+Lup2+pgoGFtFI8ahs26/XWMD7cqFb4t+x54eNcrU4Zb+aKRamQjW7iR/FVs4wY5jCWx0OUKeQ0yx/n+0KO7PjKUTnZGvaHyDdryPPwLyIn5vR x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR15MB3791.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(136003)(346002)(366004)(396003)(39850400004)(6506007)(186003)(478600001)(26005)(66476007)(2906002)(8936002)(9686003)(55016002)(316002)(91956017)(76116006)(33656002)(86362001)(44832011)(52536014)(66446008)(64756008)(66556008)(66946007)(73894004)(621065003)(6916009)(7696005)(4270600006)(71200400001)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: EOjkU8ZYm63PO7Q8k20/Kraf9yCNn4VHj6BPBC+PABW/HHGn1TNn0JjhhFeSrOPnqVshg2cfBdBA5MvfdrLdAlz+v2JupiVF89Ow+53Lax6OPLhXsI7SBt/ilb8rqggWaVb9+klbedKdgbVrE3h4RxhYLIsIM91AuYPSJyNj7wSLa66sVv1+WiBzSTFjDA90Zwk938TzMDobnKOsVW59WNl3A4cdFw5Rq4qbj47vP3AJ+0iwsYWDv3jzqW6THUG8PWfIlnOQ+rbd3pKg0kVb7zhNhHvKerXMn3wfkjO1VR4EOE1DIE4vAHb4oc7Wkd2mzqnZQ0Wxy/QzXk2BKK5TQ9yrXJrQeewr/bzGh1kG/kvUplkaVQZFXt3zTOodXZXcOsUmTFQG/MwWGz5qtlG2eerhXeO0wFsn2wtxKl7bLq4cbxLuto/A0Q1KEjAOVcoTONfZTZ1MdV2Zsrp2esURgjuhYuCTidyFYqzGGFVr2lc= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA0PR15MB37918CC860B18D17B0DDFB85E3780SA0PR15MB3791namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR15MB3791.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2ea86390-3825-48f9-5ac5-08d82d8f1aff X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2020 15:59:52.6075 (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: nI28O2gut88Xi6JTr3pbT39d5axze/yzjxf/DjuU/WJvqDcyuF66nzT/onEB9QMRvoJ/M5UoTlwaXqVf7H69f7TXZL6lEne+uU6wbU5qLtg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR1501MB2192 Archived-At: Subject: [Ace] ACE interim meeting tentative (Option2) 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, 21 Jul 2020 15:59:59 -0000 --_000_SA0PR15MB37918CC860B18D17B0DDFB85E3780SA0PR15MB3791namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --_000_SA0PR15MB37918CC860B18D17B0DDFB85E3780SA0PR15MB3791namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --_000_SA0PR15MB37918CC860B18D17B0DDFB85E3780SA0PR15MB3791namp_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpFYXN0ZXJu IFN0YW5kYXJkIFRpbWUNCkJFR0lOOlNUQU5EQVJEDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0K VFpPRkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJ TlRFUlZBTD0xO0JZREFZPTFTVTtCWU1PTlRIPTExDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRBWUxJ R0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNF VFRPOi0wNDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPTJTVTtCWU1PTlRI PTMNCkVORDpEQVlMSUdIVA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpPUkdBTklaRVI7 Q049RGFuaWVsIE1pZ2F1bHQ6bWFpbHRvOmRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbQ0KQVRU RU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJV RTtDTj1BY2UgV2c6bWFpDQogbHRvOmFjZUBpZXRmLm9yZw0KREVTQ1JJUFRJT047TEFOR1VBR0U9 ZW4tVVM6XG4NClJSVUxFOkZSRVE9TU9OVEhMWTtVTlRJTD0yMDIxMTEwNlQxNDAwMDBaO0lOVEVS VkFMPTE7QllEQVk9MVRIDQpVSUQ6MDQwMDAwMDA4MjAwRTAwMDc0QzVCNzEwMUE4MkUwMDgwMDAw MDAwMEMxRDRDOTRCNzE1RkQ2MDEwMDAwMDAwMDAwMDAwMDANCiAwMTAwMDAwMDAwQTI4RThFRTkw Nzk3RDRGOTY3QzFERjU2REZCQTg5RA0KU1VNTUFSWTtMQU5HVUFHRT1lbi1VUzpBQ0UgaW50ZXJp bSBtZWV0aW5nIHRlbnRhdGl2ZSAoT3B0aW9uMikNCkRUU1RBUlQ7VFpJRD1FYXN0ZXJuIFN0YW5k YXJkIFRpbWU6MjAyMDA5MDNUMTAwMDAwDQpEVEVORDtUWklEPUVhc3Rlcm4gU3RhbmRhcmQgVGlt ZToyMDIwMDkwM1QxMTAwMDANCkNMQVNTOlBVQkxJQw0KUFJJT1JJVFk6NQ0KRFRTVEFNUDoyMDIw MDcyMVQxNTU5NTJaDQpUUkFOU1A6T1BBUVVFDQpTVEFUVVM6Q09ORklSTUVEDQpTRVFVRU5DRToy DQpMT0NBVElPTjtMQU5HVUFHRT1lbi1VUzoNClgtTUlDUk9TT0ZULUNETy1BUFBULVNFUVVFTkNF OjINClgtTUlDUk9TT0ZULUNETy1PV05FUkFQUFRJRDoyMTE4NjI1NzI5DQpYLU1JQ1JPU09GVC1D RE8tQlVTWVNUQVRVUzpURU5UQVRJVkUNClgtTUlDUk9TT0ZULUNETy1JTlRFTkRFRFNUQVRVUzpC VVNZDQpYLU1JQ1JPU09GVC1DRE8tQUxMREFZRVZFTlQ6RkFMU0UNClgtTUlDUk9TT0ZULUNETy1J TVBPUlRBTkNFOjENClgtTUlDUk9TT0ZULUNETy1JTlNUVFlQRToxDQpYLU1JQ1JPU09GVC1ET05P VEZPUldBUkRNRUVUSU5HOkZBTFNFDQpYLU1JQ1JPU09GVC1ESVNBTExPVy1DT1VOVEVSOkZBTFNF DQpYLU1JQ1JPU09GVC1MT0NBVElPTlM6W10NCkJFR0lOOlZBTEFSTQ0KREVTQ1JJUFRJT046UkVN SU5ERVINClRSSUdHRVI7UkVMQVRFRD1TVEFSVDotUFQxNU0NCkFDVElPTjpESVNQTEFZDQpFTkQ6 VkFMQVJNDQpFTkQ6VkVWRU5UDQpFTkQ6VkNBTEVOREFSDQo= --_000_SA0PR15MB37918CC860B18D17B0DDFB85E3780SA0PR15MB3791namp_-- From nobody Tue Jul 21 09:00:45 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 E44A03A0B97 for ; Tue, 21 Jul 2020 09:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, MIME_HTML_MOSTLY=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 qU15Ge71pGZJ for ; Tue, 21 Jul 2020 09:00:39 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2082.outbound.protection.outlook.com [40.107.244.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 9E2DD3A0B8B for ; Tue, 21 Jul 2020 09:00:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IzOhk5KW4RPvXEe/C8GCBWwFEyWLpOdcae7nu+Jb88c2bWHy6LZ+ycBaLUL73c53R3hDY39wBfAvxhaFURLMXq3Wk/2+tsR/I0gLi2rXwpiHfu8k9FOaRZI/KAGiUXwkErwFlQpMdVYuwh0ZkR6/ZjM06WckCegH7Qu9m/gGjNyaaJ0S6dNK62L8imeZzorRpBYxt3YPYwxPzMpy9YfJ6HIQYZNfI3lJn4VOoV7/SRl3fJHpN7G+InB1IP76AYbJSQrhh1qj9u0PnPUBAswb6o+JqqpaucxQt+pA7URZuhK0B161UssQx7tEY4Vm5LQp2Lexo5VoRIMoLopmzLRCsg== 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=1snvNjx1ECDoFejY3n/lZ7uAikqmGkG4cdeDxIZKNo0=; b=dvg/yb4WSDTO18o7njwx34PjDLABtptjWpV2us6Sy5CrGmPg/a6MPRoq8pjN6e/rbOGsX6Ix3czc6YzcEYS2dyARafBkGzDnbQxjxU6FTUIwNif3T+0vmfCs4SS3BgGgUg5tswihqswb8ztIqHrOG8tjiNsbReg3IqvazOVHV3+RtkU1/CC1g+RKNnp441npzuwd63UjEAyihL+Rglb/XoA8fYdXEfLO8VFe7AHdJsVj/PSr6AEPCnpRnaoSvEoW2lYAy46zOU+mqXO7DhiNZcxYMN+Ed152iK7tDvVK8nwFe9huLp4HQ+XeyJugD1Vb0GTDt91cJjB6rvbMu3Yt5g== 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=1snvNjx1ECDoFejY3n/lZ7uAikqmGkG4cdeDxIZKNo0=; b=JP139QwG7qHFM6YZTPI90MA0yHTovr4908a+huTyD+kWfz/yYU1SF47qzJS/bvjsGsYNzNzxpfiFjJCCX5hy/LrHvWmTTczSHrslD8ghGFrtWUZ8FQP5WfPq1df43T2oLVCJjPoIFBxrvsHdeVm1rHVhHMQZbsdtfFQ4vhp2ku4= Received: from SA0PR15MB3791.namprd15.prod.outlook.com (2603:10b6:806:8d::10) by SN6PR1501MB2192.namprd15.prod.outlook.com (2603:10b6:805:12::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.23; Tue, 21 Jul 2020 16:00:38 +0000 Received: from SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::3005:5e4b:252f:e9d1]) by SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::3005:5e4b:252f:e9d1%4]) with mapi id 15.20.3174.030; Tue, 21 Jul 2020 16:00:38 +0000 From: Daniel Migault To: Ace Wg Thread-Topic: ACE tentative interim meeting (option 1) Thread-Index: AdZfcQBfklwz96USX0COojDilmydoQ== Date: Tue, 21 Jul 2020 16:00:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAAAAADs4U4AcV/WAQAAAAAAAAAAEAAAAGUhLlqCxhlMu4V6ZsN+2kY= x-originating-ip: [96.22.11.129] x-ms-office365-filtering-correlation-id: 51c4916b-6376-4aee-887d-08d82d8f3641 x-ms-traffictypediagnostic: SN6PR1501MB2192:MeetingMessage x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1728; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2n59IP689xoW9WkiWxcwJA5adStdnMHfD+BAtFCT314YpikR0hUogovhyB3TTXCapq/Yw5SK1un7CvxHFJy8xmaLNxx39ubPNCIEfNapIqFx0V5mNEFpRSjp+bARg8CljAx20dTDr+nYlZQQ0Vu8gWN8EYx0C54I0wpTTz9LQRL+Je5HhRnsluaHkhJ53C7V x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR15MB3791.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(136003)(346002)(366004)(396003)(39850400004)(6506007)(186003)(478600001)(26005)(66476007)(2906002)(8936002)(9686003)(55016002)(316002)(91956017)(76116006)(33656002)(86362001)(5660300002)(44832011)(52536014)(66446008)(64756008)(66556008)(66946007)(73894004)(6916009)(7696005)(4270600006)(71200400001)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: jlDAGLU2ECHjE2K7j7CKsfc3R+cbTPiZCedvvsCP/ymMSkKlLq/Ro9n/myNxS7Z1PEGFbuVPf8mByngl0PJt+OHjrCDy460MWb3j1waR3OEnxy2ovLhjfJS0ikficJEQ9jbooRiytEG9UK7Rgv6rSmYGDyxT4eEXQeRvH/CeOEDznt1/Grc9nGYPj91FOkqM+mFLRP/7EcN0Ge2tf+dgh8NOQ5G3zE6D5U+/1FHu34Sd7/G/Ggy35L8PoXFJczGHMs/AqAKu3nFkN8lWl2Opfg1QuRmBnL2+6l0lZpcpjCJ5bBtPCQyt8hqMNy1XXqGSy7uFpoxDxYMUsatdFaJB2UYj9giAvNb4rYFf4VZcNFP7H+2cMcBSSJldnvUVvuUSop9w+kjWUjNraaYrFcLvrNYwAHTrNZHQ+yCKGSjoP0SEdy3voLgmijSEfgG1De86hu1hT5vOBT5OwUl7NprCQUN2QX4joTnool+gmfN6Aqk= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA0PR15MB379124C0A0F03570E4644922E3780SA0PR15MB3791namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR15MB3791.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 51c4916b-6376-4aee-887d-08d82d8f3641 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2020 16:00:38.5677 (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: VQLjji0uZWAEb/anFp3hZ8ruxcC0JmjUUX/1VaUhVsF2+mBUG0DK9TIJKptEpUsMjXjh104qQUEeR3krN6G61nDvrDdQ9qTwgZnwEBSrCnE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR1501MB2192 Archived-At: Subject: [Ace] ACE tentative interim meeting (option 1) 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, 21 Jul 2020 16:00:45 -0000 --_000_SA0PR15MB379124C0A0F03570E4644922E3780SA0PR15MB3791namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --_000_SA0PR15MB379124C0A0F03570E4644922E3780SA0PR15MB3791namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

--_000_SA0PR15MB379124C0A0F03570E4644922E3780SA0PR15MB3791namp_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpFYXN0ZXJu IFN0YW5kYXJkIFRpbWUNCkJFR0lOOlNUQU5EQVJEDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0K VFpPRkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJ TlRFUlZBTD0xO0JZREFZPTFTVTtCWU1PTlRIPTExDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRBWUxJ R0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNF VFRPOi0wNDAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPTJTVTtCWU1PTlRI PTMNCkVORDpEQVlMSUdIVA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpPUkdBTklaRVI7 Q049RGFuaWVsIE1pZ2F1bHQ6bWFpbHRvOmRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbQ0KQVRU RU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJV RTtDTj1BY2UgV2c6bWFpDQogbHRvOmFjZUBpZXRmLm9yZw0KREVTQ1JJUFRJT047TEFOR1VBR0U9 ZW4tVVM6XG4NClJSVUxFOkZSRVE9TU9OVEhMWTtVTlRJTD0yMDIwMTEwMVQxNDAwMDBaO0lOVEVS VkFMPTE7QllEQVk9MU1PDQpVSUQ6MDQwMDAwMDA4MjAwRTAwMDc0QzVCNzEwMUE4MkUwMDgwMDAw MDAwMEVDRTE0RTAwNzE1RkQ2MDEwMDAwMDAwMDAwMDAwMDANCiAwMTAwMDAwMDA2NTIxMkU1QTgy QzYxOTRDQkI4NTdBNjZDMzdFREE0Ng0KU1VNTUFSWTtMQU5HVUFHRT1lbi1VUzpBQ0UgdGVudGF0 aXZlIGludGVyaW0gbWVldGluZyAob3B0aW9uIDEpDQpEVFNUQVJUO1RaSUQ9RWFzdGVybiBTdGFu ZGFyZCBUaW1lOjIwMjAwOTA3VDEwMDAwMA0KRFRFTkQ7VFpJRD1FYXN0ZXJuIFN0YW5kYXJkIFRp bWU6MjAyMDA5MDdUMTEwMDAwDQpDTEFTUzpQVUJMSUMNClBSSU9SSVRZOjUNCkRUU1RBTVA6MjAy MDA3MjFUMTYwMDM4Wg0KVFJBTlNQOk9QQVFVRQ0KU1RBVFVTOkNPTkZJUk1FRA0KU0VRVUVOQ0U6 Mw0KTE9DQVRJT047TEFOR1VBR0U9ZW4tVVM6DQpYLU1JQ1JPU09GVC1DRE8tQVBQVC1TRVFVRU5D RTozDQpYLU1JQ1JPU09GVC1DRE8tT1dORVJBUFBUSUQ6MjExODYyNzA1Mg0KWC1NSUNST1NPRlQt Q0RPLUJVU1lTVEFUVVM6VEVOVEFUSVZFDQpYLU1JQ1JPU09GVC1DRE8tSU5URU5ERURTVEFUVVM6 QlVTWQ0KWC1NSUNST1NPRlQtQ0RPLUFMTERBWUVWRU5UOkZBTFNFDQpYLU1JQ1JPU09GVC1DRE8t SU1QT1JUQU5DRToxDQpYLU1JQ1JPU09GVC1DRE8tSU5TVFRZUEU6MQ0KWC1NSUNST1NPRlQtRE9O T1RGT1JXQVJETUVFVElORzpGQUxTRQ0KWC1NSUNST1NPRlQtRElTQUxMT1ctQ09VTlRFUjpGQUxT RQ0KWC1NSUNST1NPRlQtTE9DQVRJT05TOltdDQpCRUdJTjpWQUxBUk0NCkRFU0NSSVBUSU9OOlJF TUlOREVSDQpUUklHR0VSO1JFTEFURUQ9U1RBUlQ6LVBUMTVNDQpBQ1RJT046RElTUExBWQ0KRU5E OlZBTEFSTQ0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K --_000_SA0PR15MB379124C0A0F03570E4644922E3780SA0PR15MB3791namp_-- From nobody Tue Jul 21 11: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 453D13A0E03 for ; Tue, 21 Jul 2020 11:22:21 -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 NI4EC0yiAZkr for ; Tue, 21 Jul 2020 11:22:20 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 088353A0DFF for ; Tue, 21 Jul 2020 11:22:20 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id d198so10924949vsc.1 for ; Tue, 21 Jul 2020 11:22:19 -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=yfupelSRf7dU9bJuAAC28LkTshEBeWFlrpgnuFGiOeE=; b=sG3BKL1Ra60XOL63M4QN3jTxvAiJWOYp3/opbcV5fV/QXsaHqaReCnRgi17l51Qeu1 tAb6irYhhYO6GR7q6SVd6lT5t/gmX59jTIfY8kMjWUrcdqRWpuu8ko206UZtDF8bSwm9 AtqaDRHMz2VFVygLlGkW/jpFDbGMKDhSv9h+yiy3XFAzxrN/1ntJJI6HwBfz55oovqja 1P0azYUPrenYeIuUg6rRNfZueqJETPAAr4PJZP8l71XUxzW2l6OBYwLMJXZhFcD3teAg +upe+YVbYDGYwSrR/8F/gxr50+93FK8DekSoA+DhdppCIYqbBkOdCYdqGGwWASRBXq9h /uzQ== 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=yfupelSRf7dU9bJuAAC28LkTshEBeWFlrpgnuFGiOeE=; b=hmGcSFchQUzai3NlDi4Xvlh0VmR3DjMKbkEeolzjVtZvUnR+gYA2pEsfhFu+4JRL7H M1/HKV98gxj050BVBH78Gori6+X6iDI8c9KvZnTgT26X1zVe9NjHO4s12w2GBLmlLpXx OMa4u5ckR+rG/oTQnS34kKdpGLtrNm1u10CHLaGE2Rx3fqlLG6V898QwsXse06uOvUEp ZWKyVKfcsX3nRv2e5lHQZH44NF+M3/bj6FRARNccEL6ZOuC7PVvo+7NlLWGIJjQhclCX LYbmXzFYDrFHFF+MfFnt04eFjMhVbkgujD6eHZHkhE6pLMPqk+ob8hoNbj4YvExI4qKv FiHA== X-Gm-Message-State: AOAM530a5iCIGK8Z1eCislXQH6yig/YVPdRXpdgykpCLho3Nsro7LXVZ +l1NbRBkwiHHxVsQM5Dk4LjK7ClzLwL+ftcD/arGMXeb X-Google-Smtp-Source: ABdhPJw7mPzD30lo2bH0TiuEC42xsnJ2TxLTXkfC+WCnPEj4ABArDJPaH+hBNZgqnAJ6/xfN+42d3GgVonqAMW999zo= X-Received: by 2002:a67:1b01:: with SMTP id b1mr15805022vsb.69.1595355738904; Tue, 21 Jul 2020 11:22:18 -0700 (PDT) MIME-Version: 1.0 From: Daniel Migault Date: Tue, 21 Jul 2020 14:22:08 -0400 Message-ID: To: Ace Wg Content-Type: multipart/alternative; boundary="0000000000001b9c4f05aaf7b422" Archived-At: Subject: [Ace] IETF 108 tentative agenda and presentations 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, 21 Jul 2020 18:22:21 -0000 --0000000000001b9c4f05aaf7b422 Content-Type: text/plain; charset="UTF-8" Hi, Please find the tentative agenda [1] of ACE WG at the IETf 108 Wed July 29, 2020 11:00 UTC. Please upload your presentations by July 27 here: https://datatracker.ietf.org/meeting/108/session/ace Yours, Jim and Daniel [1] https://codimd.ietf.org/notes-ietf-108-ace -- Daniel Migault Ericsson --0000000000001b9c4f05aaf7b422 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Please find the tentative age= nda [1] of ACE WG at the IETf 108=C2=A0Wed July 29, 2020 11:00 UTC.=C2=A0

Please upload=C2=A0your presentations by July 27 he= re:
=
Yours,=C2=A0
Jim and Daniel

[1]=C2=A0https://= codimd.ietf.org/notes-ietf-108-ace

--
Daniel Migault
Ericsso= n
--0000000000001b9c4f05aaf7b422-- From nobody Tue Jul 21 12:58:36 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 7DF8A3A08EB for ; Tue, 21 Jul 2020 12:58:35 -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 Rju0ZuVQCpe5 for ; Tue, 21 Jul 2020 12:58:33 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 7AD2D3A08E9 for ; Tue, 21 Jul 2020 12:58:33 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id a12so22731947ion.13 for ; Tue, 21 Jul 2020 12:58:33 -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=ItQmeVSIZ4bpKPXl96CFpVhSlYGDiOP/5Sw/FxuJDsg=; b=lKPgMHOcmbjWPGOOrzJaWf3oldTD99meTjfvh7GON3aAzJ6QrAM2G88V+qox+4MWBA WKgMQhuY6UmXu7YggU6Jv4m5jRXC7BR1nsTnJRta1TRu5d050Yrh4G/leXPbK6kDepbO UtEMBJPTrrKgrRHfO+CrxR0vrSe9lYsE9LLhHqbkd7wS0D+WdOJot2Hw0eXEQbM9qEe5 8L96YG6f7HpLuvkBy0MnE3y1xVbjBP0k4x02qZh2ofHtDPMVm1PcRR4U+GXqUS4nyYPL 1GJ/832caNYlj3fGem3oIdyEQ9qHImR+wlXV2+f7ofW7zwGG8OfrsEcRmc9VAGGk/1Vc F/JA== 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=ItQmeVSIZ4bpKPXl96CFpVhSlYGDiOP/5Sw/FxuJDsg=; b=s6wdoVASkz14qwahwfdSA88qN/agAD0axz8sKExDgxwxRdk7GoV55Loj7FrG5DE0xP wOIG3dGgE2pSSSqqpTBxcHtNywghwnDd9p1T0TCaBlBbSqxD+Hkz7fFAwMOzghVAkDR4 4q/zb4xbovj9tm1lGFs+lZfjybupzC1Uf0qmhP+R08KoXqMN994XC/cQgeZIYKoNEL9S kYZacq8UzKR7QE1lCOquJchoOxiV5ZVC+wWmqrY60HeUzO6JuTMEGruNMm2stvmY8T3y dAr5Xs2hD3pmY/vXTctpg/ZMeyBnlbwdT6lsvJkkcCpeqNHe2kduRpfLfj+EyUryHgwh k2BQ== X-Gm-Message-State: AOAM530Pgbt+L3GmV7PBt8+HExHYwL0QyLnR1i3rqz+DmkRMXzNkLGq+ MuNy2nYnsPjSwcd76GUEQVgoPOdQ+8vBJvEh2FLt+ly6 X-Google-Smtp-Source: ABdhPJx5fHCUXBFmjifO2bmTOaZZ1Su4oaf+n5iQ9wl3IVxD0YD9fGDzuTMB31TmKJbtwRAcxHD+N0V9HQIVVrr7PoA= X-Received: by 2002:a6b:d809:: with SMTP id y9mr29926901iob.209.1595361512220; Tue, 21 Jul 2020 12:58:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mohit Sahni Date: Tue, 21 Jul 2020 12:58:21 -0700 Message-ID: To: ace@ietf.org Content-Type: multipart/alternative; boundary="000000000000396ab605aaf90c46" Archived-At: Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) 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, 21 Jul 2020 19:58:36 -0000 --000000000000396ab605aaf90c46 Content-Type: text/plain; charset="UTF-8" Hi Daniel, I had requested, in an earlier email, some time to discuss what changes are required in the ACE WG charter to adopt my draft for "CMPv2/Lightweight CMP profile over CoAP transport" ( https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00). Would it be possible for you to add it to the tentative agenda? To give some background, this draft is an extension of Light Weight CMP Profile ( https://tools.ietf.org/html/draft-ietf-lamps-lightweight-cmp-profile-02) draft currently under development in the LAMPS WG. We discussed the "CMPv2 over CoAP" draft in the LAMPS WG and figured out that ACE WG is a more appropriate place for this draft. However, Jim suggested that we will need to modify the charter of the ACE WG to adopt this draft. Thanks Mohit On Tue, Jul 21, 2020 at 11:22 AM wrote: > Send Ace mailing list submissions to > ace@ietf.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ietf.org/mailman/listinfo/ace > or, via email, send a message with subject or body 'help' to > ace-request@ietf.org > > You can reach the person managing the list at > ace-owner@ietf.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Ace digest..." > Today's Topics: > > 1. interim meeting planification (Daniel Migault) > 2. ACE interim meeting tentative (Option2) (Daniel Migault) > 3. ACE tentative interim meeting (option 1) (Daniel Migault) > 4. IETF 108 tentative agenda and presentations (Daniel Migault) > > > > ---------- Forwarded message ---------- > From: Daniel Migault > To: Ace Wg > Cc: > Bcc: > Date: Tue, 21 Jul 2020 11:59:22 -0400 > Subject: [Ace] interim meeting planification > Hi, > > Please find a doodle [1] with two time slots for the interim meetings that > are planned 1 per month the first week of the month 10 AM - 11 AM EST. The > two proposed days are Monday and Thursday. Please select your preferred day > by July 26. > > I am sending the calendar serie to the ace list so everyone can better see > how it matches its calendar. > > Yours, > > Jim and Daniel > > [1] https://doodle.com/poll/x2dghwiqmqei6cc8 > -- > Daniel Migault > Ericsson > > > > ---------- Forwarded message ---------- > From: Daniel Migault > To: Ace Wg > Cc: > Bcc: > Date: Tue, 21 Jul 2020 15:59:52 +0000 > Subject: [Ace] ACE interim meeting tentative (Option2) > > > > ---------- Forwarded message ---------- > From: Daniel Migault > To: Ace Wg > Cc: > Bcc: > Date: Tue, 21 Jul 2020 16:00:38 +0000 > Subject: [Ace] ACE tentative interim meeting (option 1) > > > > > ---------- Forwarded message ---------- > From: Daniel Migault > To: Ace Wg > Cc: > Bcc: > Date: Tue, 21 Jul 2020 14:22:08 -0400 > Subject: [Ace] IETF 108 tentative agenda and presentations > Hi, > > Please find the tentative agenda [1] of ACE WG at the IETf 108 Wed July > 29, 2020 11:00 UTC. > > Please upload your presentations by July 27 here: > https://datatracker.ietf.org/meeting/108/session/ace > > Yours, > Jim and Daniel > > [1] https://codimd.ietf.org/notes-ietf-108-ace > > > -- > Daniel Migault > Ericsson > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --000000000000396ab605aaf90c46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Daniel,
I had requested, in an earlier e= mail, some time to discuss what changes are required in the ACE WG charter = to=C2=A0adopt my draft for "CMPv2/Lightweight CMP profile over CoAP tr= ansport" (https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coa= p-transport-00). Would it be possible for you to add it to the tentativ= e agenda?

To give some background, this draft is a= n extension of Light Weight CMP Profile (https://tools.ietf.org/ht= ml/draft-ietf-lamps-lightweight-cmp-profile-02) draft currently under d= evelopment in the LAMPS WG. We discussed the "CMPv2 over CoAP" dr= aft in the LAMPS WG and figured out that ACE WG is a more appropriate place= for this draft. However, Jim suggested that we will need to modify the cha= rter=C2=A0 of the ACE WG to adopt this draft.

Than= ks
Mohit

On Tue, Jul 21, 2020 at 11:22 AM <ace-request@ietf.org> wrote:
Send Ace mailing list submissions t= o
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ace@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/li= stinfo/ace
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ace-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ace-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ace digest..."
Today's Topics:

=C2=A0 =C2=A01. interim meeting planification (Daniel Migault)
=C2=A0 =C2=A02. ACE interim meeting tentative (Option2) (Daniel Migault) =C2=A0 =C2=A03. ACE tentative interim meeting (option 1) (Daniel Migault) =C2=A0 =C2=A04. IETF 108 tentative agenda and presentations (Daniel Migault= )



---------- Forwarded message ----------
From:=C2=A0Daniel Mi= gault <mglt.iet= f@gmail.com>
To:=C2=A0Ace Wg <ace@ietf.org>
Cc:=C2=A0
Bcc:=C2=A0
Date:= =C2=A0Tue, 21 Jul 2020 11:59:22 -0400
Subject:=C2=A0[Ace] interim meetin= g planification
Hi,

P= lease find a doodle [1] with two time slots for the interim meetings that a= re planned 1 per month the first week of the month 10 AM - 11 AM EST. The t= wo proposed days are Monday and Thursday. Please select your preferred=C2= =A0day by July 26.=C2=A0
=C2=A0
I am sending the calend= ar serie to the ace list so everyone can better see how it matches its cale= ndar.=C2=A0 =C2=A0

Yours,=C2=A0

Jim and Daniel

--
=
Daniel Migault
Ericsson



---------- Forwarded message ----------
From:=C2=A0Daniel Mi= gault <= daniel.migault@ericsson.com>
To:=C2=A0Ace Wg <ace@ietf.org>
Cc:=C2=A0
Bcc:= =C2=A0
Date:=C2=A0Tue, 21 Jul 2020 15:59:52 +0000
Subject:=C2=A0[Ace]= ACE interim meeting tentative (Option2)



---------- Forwarde= d message ----------
From:=C2=A0Daniel Migault <daniel.migault@ericsson.com= >
To:=C2=A0Ace Wg <ace@ietf.org>
Cc:=C2=A0
Bcc:=C2=A0
Date:=C2=A0Tue, 21 Ju= l 2020 16:00:38 +0000
Subject:=C2=A0[Ace] ACE tentative interim meeting = (option 1)




---------- Forwarded message ----------
From:=C2=A0Daniel Mi= gault <mglt.iet= f@gmail.com>
To:=C2=A0Ace Wg <ace@ietf.org>
Cc:=C2=A0
Bcc:=C2=A0
Date:= =C2=A0Tue, 21 Jul 2020 14:22:08 -0400
Subject:=C2=A0[Ace] IETF 108 tenta= tive agenda and presentations
Hi,=C2=A0

<= div>Please find the tentative agenda [1] of ACE WG at the IETf 108=C2=A0Wed= July 29, 2020 11:00 UTC.=C2=A0

Please upload=C2= =A0your presentations by July 27 here:

Yours,= =C2=A0
Jim and Daniel



=
--
Daniel Migault
Ericsson
_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--000000000000396ab605aaf90c46-- From nobody Tue Jul 21 13:31: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 703153A0972 for ; Tue, 21 Jul 2020 13:31:08 -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 0MvtezQvoE_C for ; Tue, 21 Jul 2020 13:31:07 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E1B3A096E for ; Tue, 21 Jul 2020 13:31:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5E1E238A23; Tue, 21 Jul 2020 16:10:40 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id OnbWRnaoDs-Q; Tue, 21 Jul 2020 16:10:39 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 83BF038A10; Tue, 21 Jul 2020 16:10:39 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 051FB3F; Tue, 21 Jul 2020 16:31:05 -0400 (EDT) From: Michael Richardson To: Mohit Sahni cc: ace@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) 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, 21 Jul 2020 20:31:09 -0000 --=-=-= Content-Type: text/plain Mohit Sahni wrote: > To give some background, this draft is an extension of Light Weight CMP > Profile ( > https://tools.ietf.org/html/draft-ietf-lamps-lightweight-cmp-profile-02) > draft currently under development in the LAMPS WG. We discussed the "CMPv2 > over CoAP" draft in the LAMPS WG and figured out that ACE WG is a more > appropriate place for this draft. However, Jim suggested that we will need > to modify the charter of the ACE WG to adopt this draft. We did est-over-coaps [still in the queue], why shouldn't we do cmp-over-coap(s)? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8XUIgACgkQgItw+93Q 3WWYwAf/Yj7uK07+px3IU1bUfabCnr3PQNESuto+daBmCDOVv0Ygk81ahdIvlxvs FVvCIH8GzduIjnyB98AAVsk6ofkonyTsd0R2O6Rx2Emdhr962ZUqFzizCskRYmEx WODM4elfMOc+zIXHPYhrNG4PGAn19SFdm2C+HtJKO6jLpP4b8uVnPsF338rR+IcL fgin6QKF56M+kIF5GnrNjvO0JzqNfPU6dvsA0lGs799zLl4Rpv1cseR5yWwyjUAW z6g2ChlpmjXq3xDc8bnDdM5i+DJm2L2/dcay548o/GTy68SjPb2wd4YRf86JglyW xwPiYJfHSJrMlu4bD66VKtbvWwz/Kg== =Iwmt -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jul 21 14:58:36 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 B78D43A0AE0 for ; Tue, 21 Jul 2020 14:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 uQ4lGLXTTA46 for ; Tue, 21 Jul 2020 14:58:33 -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 714203A0ADE for ; Tue, 21 Jul 2020 14:58:33 -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 06LLwQJR013672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jul 2020 17:58:29 -0400 Date: Tue, 21 Jul 2020 14:58:25 -0700 From: Benjamin Kaduk To: Michael Richardson Cc: Mohit Sahni , ace@ietf.org Message-ID: <20200721215825.GB41010@kduck.mit.edu> References: <9794.1595363465@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9794.1595363465@localhost> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) 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, 21 Jul 2020 21:58:35 -0000 On Tue, Jul 21, 2020 at 04:31:05PM -0400, Michael Richardson wrote: > > Mohit Sahni wrote: > > To give some background, this draft is an extension of Light Weight CMP > > Profile ( > > https://tools.ietf.org/html/draft-ietf-lamps-lightweight-cmp-profile-02) > > draft currently under development in the LAMPS WG. We discussed the "CMPv2 > > over CoAP" draft in the LAMPS WG and figured out that ACE WG is a more > > appropriate place for this draft. However, Jim suggested that we will need > > to modify the charter of the ACE WG to adopt this draft. > > We did est-over-coaps [still in the queue], why shouldn't we do cmp-over-coap(s)? It may just be that "est-over-coaps is so obviously us" that I didn't check the charter carefully at that time. But, at this point, we're probably overdue for a recharter anyway, as the core framework is making its way to the IESG. -Ben From nobody Tue Jul 21 15:56:09 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 BEE103A0766; Tue, 21 Jul 2020 15:56:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Elwyn Davies via Datatracker To: Cc: draft-ietf-ace-oscore-profile.all@ietf.org, ace@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.9.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159537216772.11664.11256578694810978706@ietfa.amsl.com> Reply-To: Elwyn Davies Date: Tue, 21 Jul 2020 15:56:07 -0700 Archived-At: Subject: [Ace] Genart last call review of draft-ietf-ace-oscore-profile-11 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, 21 Jul 2020 22:56:08 -0000 Reviewer: Elwyn Davies Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-ace-oscore-profile-11 Reviewer: Elwyn Davies Review Date: 2020-07-21 IETF LC End Date: 2020-07-20 IESG Telechat date: Not scheduled for a telechat Summary:  Almost ready.  There is one minor issue that needs sorting out and a fair number of nits.  Overall I have to say that I found it difficult to keep clear in my mind what messages were fully encrypted and which ones were sent en clair and which are in some intermediate class.  The authors might wish to go back over the document from the point of a naive reader to ensure that it is clear for implementers. Major issues: None Minor issues: s2, para 5:  Where does the 'input salt' come from?  The term is not used anywhere else in this document and  isn't defined or mentioned in either dreft-ace-oauth-authz or RFC 8613. Nits/editorial comments: s1:  Need to expand CoAP on first use. s1: Need to expand CBOR on first use. s1.2, CDDL:  It would useful to mention that the predefined type names from CDDL, especially bstr for byte strings and tstr for text strings,  are used extensively in the document. s2, para 1: s/overview on how/overview of how/ s2, para 1: s/as well as OSCORE setup/as well as the OSCORE setup/ s2, para 2: s/that's/that is/ s2, para 8: Need to expand AEAD on first use. s2 and Figure 1:  It would be helpful to the reader if Figure 1 and its descriptive paragraph was placed closer to the beginning of s2.  Otherwise things like Client C' need more explanation to point the reader at the figure. s2, para 3: This says: To determine the AS in charge of a resource hosted at the RS, the client C MAY send an initial Unauthorized Resource Request message to the RS. The RS then denies the request and sends the address of its AS back to the client C as specified in section 5.1 of [I-D.ietf-ace-oauth-authz]. The access token request and response MUST be confidentiality-protected and ensure authenticity I found the combination of the Unauthorized Requst and the confidentiality-protected etc confusing.  If the last sentence does apply to the Unuthorized Request it would be helpful to make it clear that this is not just a generic statement but does apply to the Unauthorized Request as well. Figure1:  For consistency the first line should say Unauthorized Rsource Request.  I would also suggest explaining the mapping between what is said in the text and the terms 'Ceation Hints' and 'Access Information' used in the figure. s3.1, para after Figure 2:  The term 'audience' appears in this paragraph without any context indicating what it means .  Later in s3.2 it appears that audience is associated with CBOR web tokens (RFC 8392).  But it may also might also be realted to draft-oauth-token exchange.  The appropriate reference ahould be added and should be explained in s3.1. Figure 3:  Should IdContext be ContextId?  ContextId is used evrywhere else. s3.2: Expand HKDF on first use ( in second set of bullets). s3.2, para after 2nd set of bullets:  I think the four instances of 'may'  ought to be 'MAY'. s3.2.1:  It would be helpful to provide references to the online versions of the  IANA registries (3 places). s4.2, para 1:   A foward reference to s5 where the comunication mechanisms needed for introspection are described. s4.1, para 2: s/from what described/from what is described/ s4.2, para 5: s/that's/that is/ s4.2, last para; s/This simplifies for the RS track/This simplies the process needed by the RS to keep track/ s8, para 6: s/tasked of/tasked with/ s9.3:  I don't think the Value Type for nonce is 'IESG'! lol From nobody Wed Jul 22 00:50: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 C9D923A0F73 for ; Wed, 22 Jul 2020 00:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=siemens.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWQpqIMqt5k6 for ; Wed, 22 Jul 2020 00:50:48 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30084.outbound.protection.outlook.com [40.107.3.84]) (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 3EAD23A0F6F for ; Wed, 22 Jul 2020 00:50:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FBkqyMw131dUMnqmr81Ho1eA99oTGDvXhEEnaGnfphWqqPIQMc7NCvzsioNiCu76ZC1FTRcbJNF747No+scsiI/ioEMZ64q5oZwnexrRyQeBU1MNqy4GwFK4P7HYSgOJsFfWkLleys8axM2YAdWWOEbQtt5N//OyQJlkWGfkKlp2U0qQIRL2HgXNjccj7/t+nx7q1dBjgtL6/BRZB8C+j//k/DxFFjEDrDvksRBOLJDwhRNnmuDtUuWtt7jDcmE7rPFpB+ag68Hfh8LU7LcQZZRRoGBvd2lHgFtqcXvn9RnFvr69o5NA29AKNWtS5p8khrOGDNn3ZI+ZxORxEKHIVw== 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=+AGByOnO6n6+fv3MfceZXm8BJ2HdbBQrA2oy3ANSmb0=; b=Hbhe9zt/0Nqyctbpl2P8aO/R8juYcEcjL2pZiUWA18KoIkq+evr1xQ6r8AqyyNSMLhBZTa/ILiXW0TdQJhxRPYWhUlzc/vey4YqzNo4cWb7/vCK7n+BNDDZpkSkaAiGPbzCD/EjQX3fy3u6kuxPhlzqhg738q9QRe26QhrLpsjCiWS8mnwU430NCJGAqvcYkEBG6nCZUTXQu4secx/xh88PNgVVmJbLKsaohhAl4egm3/iV8wnZ3jtG66H5Nkcr1yedPULN70U0jB7Uf9hUAWCa2kET21M04q927Y7R5VBjINPu6Ly7mbu9IWgFWs7/am+sWDFBey9F0pHsIofdybw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+AGByOnO6n6+fv3MfceZXm8BJ2HdbBQrA2oy3ANSmb0=; b=k5ZkRA4wz8wwO3xEXRtvrUob2bZakETJE8OnmtFNPOoFJv9bbtu5oBocmwp+KIa9WgEOo8LWuS7NoEoW5LYnpKIQuDh7PCkddOdrMJNDqMIWejhFSICj4gYjzTXN9yzkTuOb0s+DJ2lmoITHk40O7zmhRGCo5VdFVF0noZfsA1w= Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:184::10) by AM0PR10MB3698.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:20b:158::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21; Wed, 22 Jul 2020 07:50:45 +0000 Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0]) by AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0%9]) with mapi id 15.20.3195.028; Wed, 22 Jul 2020 07:50:45 +0000 From: "Brockhaus, Hendrik" To: Benjamin Kaduk , Michael Richardson CC: Mohit Sahni , "ace@ietf.org" , "steffen.fries@siemens.com" Thread-Topic: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) Thread-Index: AQHWX5lapX1JlGFGAU2aq0XyrzvJB6kSfISAgAAYZoCAAKL0AA== Date: Wed, 22 Jul 2020 07:50:45 +0000 Message-ID: References: <9794.1595363465@localhost> <20200721215825.GB41010@kduck.mit.edu> In-Reply-To: <20200721215825.GB41010@kduck.mit.edu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=853d4b82-15da-4ce2-9193-0000a3646129; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-07-22T07:41:39Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; x-document-confidentiality: NotClassified authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.158] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 257128dd-95be-453c-a734-08d82e13f13b x-ms-traffictypediagnostic: AM0PR10MB3698: x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XVgz+SCNNDOQL1HKXlkDQEkhZkj2n6vvdyRGrVux7ol7yKTWEBF1Ck6IqrNonsG3hAF8u81mIu4LNvPJmuR2r0ULvHUcJBXrgAdpgA6sHv31hk+wtGUqNwzI9vOx9kP+XSN0Hl08XvMRq6SzbnfzhKvvt337pVHdiiS79GEGIqp7AoYE91xEcFMpDQHuZbLw8gZqaPl45bUpoGfqODVEqkcbYL8E6Z/mG9L0CqLNG35CNwCjutcTtN8XshSRyn/yH1hCYtKYPIK8CMTvU3S2gu7A7EjyM92bwAXznQLzXWDSpfOOCVjVYSgA6BjvvmU1z7KXbBn2aI7rKCoRsx6wN2AQ5GkWhZUk56bW8eAhLKt6SONlXJ1J/caxBEXIUr5c12kChKimuj3f641P1TnrMg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(376002)(346002)(136003)(39860400002)(33656002)(966005)(478600001)(5660300002)(76116006)(2906002)(45080400002)(52536014)(55016002)(107886003)(66946007)(9686003)(66446008)(64756008)(66556008)(66476007)(7696005)(54906003)(110136005)(316002)(6506007)(55236004)(186003)(71200400001)(8676002)(86362001)(26005)(83080400001)(8936002)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ocQAO5S3B1NHpZSCsBzBHriMDniv2NwFQ0XeCh2noiy1zplEbJpxGydd8ncUJ/cBJw2b8iCjSlvXWzfyvjnHSHe3vQ9XPaKtXHkkaFo0wF4nOVVrCMKcMeuG18QvtvhBtw0iNvZ67pqR/Pa9G5y/0aJb41knLyMP7exWOoCE4USKFwpdw8Nc01s5eKactB6iaGWF/ZpfDiqn1UYs4CZWtkoQNUnt+davNjZO3dOw2VoDvXNw8wI4qCZhS3PQO7HV3U/6n+Q5lvLWbUVoTJEo9699PupCLa8Dvk6gDRKGJRqkeJgX/XspZW4e4yBOBmAWMVtPbv8wz0VK1CV1mKE3FMHY3R2zytt4SOWLQKuZL0E5LH9yAlG1NoOtuqjhuLw/RZHnXFN7sJFRkxU2f4/90EK63JuAUFDrGuT9tJn0FMwKMettSaDuV4rty+WKNHz9BsKSwNGW4iImLjG/yLVCJxlMHOB1FcOUhY8O/J1tqOJso73Mu+oiCL1iZlkniWZb Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 257128dd-95be-453c-a734-08d82e13f13b X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 07:50:45.8006 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: g4AxovJ2AIC7T02VEMnUFUbDaC1Oy5W9zueCL/1WT2Die38bydnW+MqqY9l7vzwIhlcjUB/3LNO8bDaKdawhCc3QAXDQmfflb1Y1e2YJOIs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB3698 Archived-At: Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) 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, 22 Jul 2020 07:50:52 -0000 > Von: Ace Im Auftrag von Benjamin Kaduk >=20 > On Tue, Jul 21, 2020 at 04:31:05PM -0400, Michael Richardson wrote: > > > > Mohit Sahni wrote: > > > To give some background, this draft is an extension of Light Weig= ht CMP > > > Profile ( > > > > https://eur01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf. > org%2Fhtml%2Fdraft-ietf-lamps-lightweight-cmp-profile- > 02&data=3D02%7C01%7Chendrik.brockhaus%40siemens.com%7Cc3b352cdfd > 174b0a7e2008d82dc1484f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C > 0%7C637309655452109222&sdata=3DQWHu3IEwf4TIIpaW0cvKuMiGXixV1AX > dws6g0vBQJPY%3D&reserved=3D0) > > > draft currently under development in the LAMPS WG. We discussed t= he > "CMPv2 > > > over CoAP" draft in the LAMPS WG and figured out that ACE WG is a > more > > > appropriate place for this draft. However, Jim suggested that we = will > need > > > to modify the charter of the ACE WG to adopt this draft. > > > > We did est-over-coaps [still in the queue], why shouldn't we do cmp-ove= r- > coap(s)? >=20 > It may just be that "est-over-coaps is so obviously us" that I didn't che= ck the > charter carefully at that time. But, at this point, we're probably overd= ue for a > recharter anyway, as the core framework is making its way to the IESG. >=20 Steffen and I discussed this with Jim last year in Prague, if I remember co= rrectly, and he recommended to submit cmp-over-coap to ACE and not to LAMPS= . As est-over-coaps was in scope of ACE, I also think it is quite obvious to = discuss cmp-over-coap in ACE. Looking into Mohits draft, cmp-over-coap is much simpler than est-over-coap= s, as CMP does not need any binding to an underlying (D)TLS handshake. If you think this needs rechartering, we should go for it. - Hendrik From nobody Wed Jul 22 06:08:28 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 71EA13A0971 for ; Wed, 22 Jul 2020 06:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.621 X-Spam-Level: X-Spam-Status: No, score=-9.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=RyRY+6s6; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=wCcXUr14 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udpB3HL3rXHs for ; Wed, 22 Jul 2020 06:08:24 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A8C83A0970 for ; Wed, 22 Jul 2020 06:08:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9337; q=dns/txt; s=iport; t=1595423304; x=1596632904; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=abGfjC6FK3glkRcWiHOD+CWjZHOPPYUVhoAyAC1ALtk=; b=RyRY+6s62YyOgcV4m7RMFFXvhFILCECwD3CiEP1ydtTMVb0MNUiK5XDf 2ry0DlwIIuoYV3G4Ab0agdc9vSIL3bliGNnN9Ln2RIu1IpOh5SRtBLJOA 6/XG3Do6Qo8+Lr6LScmwbFWF/ZA9mdOVmuOnQrAX9vu0w8XDrZDqSeATa I=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3AS0sh1xGI/WEzG7dH6F8L251GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401Q+bRoTW7v9CkKzdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutfFzfp3C09ngZHR?= =?us-ascii?q?CsfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBAABNORhf/5JdJa1gDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQESAQEBAQEBAQEBAQEBQIFKgVJRB28rLS8sCodvA41JigK?= =?us-ascii?q?OXIJTA1UEBwEBAQkDAQEYDQgCBAEBgW2CXwKCDAIkOBMCAwEBCwEBBQEBAQI?= =?us-ascii?q?BBgRthVwMhXEBAQEDAQEBEC4BASwCCQEEBwQCAQgRBAEBAS4CHwYLHQgCBAE?= =?us-ascii?q?NBQgGFIJ/BAKBfk0DDhEPAQ6iAAKBOYhhdIE0gwEBAQWFIAMKC4IHBwMGgTg?= =?us-ascii?q?BgVKBF4YEhAQagUE/gRFDgh8uPoEEgRZCAQECARaBSBWDMoItj1KCS4hPmhl?= =?us-ascii?q?NCoJdhDOCWIFLjB2FFJ9RkgaNCJF/AgQCBAUCDgEBBYFqIw2BSnAVO4JpUBc?= =?us-ascii?q?CDY4eDBeDToUUhQQ+dAIBATMCBggBAQMJfI4WAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.75,381,1589241600"; d="p7s'?scan'208";a="516086862" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jul 2020 13:08:23 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 06MD8Mxq029149 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Jul 2020 13:08:23 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 22 Jul 2020 08:08:22 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 22 Jul 2020 08:08:22 -0500 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 22 Jul 2020 09:08:21 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VNC3fJv3VxukHERAPnXGGynqL1DpHuuDPVcEOCbTmF3ks1gYx6wK0w+2iOa58KrXS9lMAEH/UYlx4c4ZoPhkRBrELQy+A2JEy+Ot9V0gYVdEptc4aesqgCl7PvPo0yZ34TSTOWE8X2OhqW8esHfDtew1cFWgVx1umW38ObBn99hEqHudXMvXdKwP9ENlc7Ehs15Vq0YDQVJWLh+DekSHjNIxVTvji1b4bh8YE3k18RKOlsFCVHqQLWn6BYLd2KcDi/5FrkMxxC5VnVLin51ArCgFo/K1LIp4USQVsQvfWx5IB4qzU8m5kfrupTwe1+atVqdBo+Tic1SFyaWzDUh8GA== 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=w9qOisay4VNyiVX4NXTZ4eZTwHrswoncILjPkZ4eGn4=; b=ZBmIx5nPvWmRA23CU+NHKvQIBLOUv+KtiZX6iKPU432Eqsrml3Eq4Z1bku8Uyo2zLoEfwn73Ka6IAkCsg48PBxJMhaNi/aiIEWvNlNPw8rzD9TNCaag1SiismNGQrBYnQAGyiKvMKizZNf3nrCwwg/oAvC3jFfnSudAGzZkxIGmbQfqt/Jxl6Hbmy+g7pPI1IDHDsQ+r57sIXI51OFBg6EUAZkBXWxIzojKKxQ6GmDMNl4AgtyWY6g5CNg4FXUlOZoCIFaAa8iZtlr1m9HQKgANnskDDDvdiVCl8ykPJWgUew2hNpWH9DCZFggko0SSHOPM/fL1yB7MJfkUxlUSauA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w9qOisay4VNyiVX4NXTZ4eZTwHrswoncILjPkZ4eGn4=; b=wCcXUr14J8KFFS/hHsDuIhsbwfHOP+xgnJ1FOjtobE/z7Pxh5+s9+zYwZQTmAQpz5cLPNb1JvEuj3R2tCsrKP0fmG/a7KZybFPh6H/k0YvjyoEhG/g3wcCCcgNoGzAm0oUD9Us0pqrzCTffOjDAS2HZexgRC0KmLrKLRh+yzh5Y= Received: from DM6PR11MB2555.namprd11.prod.outlook.com (2603:10b6:5:c5::33) by DM6PR11MB2748.namprd11.prod.outlook.com (2603:10b6:5:c8::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.23; Wed, 22 Jul 2020 13:08:20 +0000 Received: from DM6PR11MB2555.namprd11.prod.outlook.com ([fe80::75c7:27bf:b5af:a483]) by DM6PR11MB2555.namprd11.prod.outlook.com ([fe80::75c7:27bf:b5af:a483%5]) with mapi id 15.20.3216.020; Wed, 22 Jul 2020 13:08:20 +0000 From: "Panos Kampanakis (pkampana)" To: "Brockhaus, Hendrik" , Benjamin Kaduk , Michael Richardson CC: Mohit Sahni , "steffen.fries@siemens.com" , "ace@ietf.org" Thread-Topic: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) Thread-Index: AQHWX5lj2xo5I7eQAk6wCDCWveBOMqkSfISAgAAYZoCAAKV/gIAAVHbw Date: Wed, 22 Jul 2020 13:08:20 +0000 Message-ID: References: <9794.1595363465@localhost> <20200721215825.GB41010@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=853d4b82-15da-4ce2-9193-0000a3646129; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-07-22T07:41:39Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; authentication-results: siemens.com; dkim=none (message not signed) header.d=none;siemens.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [68.93.142.48] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0afa9660-79c6-4739-030c-08d82e404ed7 x-ms-traffictypediagnostic: DM6PR11MB2748: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ODYSU2GxrjPuf6KiVfldNX67l0lOrQbSPM0V0yc7q50vWeVpmXf6/J7eacUjDeCjLFjY2n9G6rAkcvDP8SQeuWPXpOUzLCpuMWBaTWdxqvui2Dcm+W9MDgGXi+mKzvLfOjqGH73GFts1t/yVcnPCrHJ5k4Rtn4uw6w1mMAFAlbXj9+Lp3lCK5uw1OZrXuEFbFLLWr2SBtdOqZaEE40GzeP00cg91fmq64KWqZXBd4jqL7ZVBHpJpPnXwTXttIL1x9NkD2s59VPJJYHVTFEf2fFIiXWf2DzJ9uKNkW62ZY2XuCMSOAGwUFudL/pI4r8xX4A8KtDVdHFbyX3lTnng/szq8dKJCC4F1KHoYotE1zEiPA8EFvfEJctE7kIOGuKfSzquApN322LmfcZHeTaeFlQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB2555.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(396003)(376002)(39860400002)(136003)(346002)(83380400001)(45080400002)(5660300002)(9686003)(86362001)(8936002)(71200400001)(33656002)(54906003)(7696005)(6506007)(110136005)(2906002)(316002)(66946007)(8676002)(478600001)(66616009)(76116006)(52536014)(4326008)(64756008)(66446008)(99936003)(966005)(66556008)(26005)(186003)(53546011)(83080400001)(55016002)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: LD5gQyhbfgwT3UaenOnuPt4vIZX8azsTGjhvsLEKsIQYqu/xiemSRcKs6xCrL/4UXs0o4JaXSPBBlmalDrF1ENAw+joePMyDyOpotYzJFDjcPCrUwXmEr3pAWEN75/3mJw66dbxwzmSpXJ9LrPAuqg7CI3DEEdGPQyb8ofM6CLvBgt95GXiAoHaU7VUyFpboebRYeY8S2yZznFgYSrDr0leByKRb+6K3jWNvBRWNQ1abw8h0TSfHGds18/v7sBxnH+4rUqesv06gIXspHf5OAgJ11kDMtRep66/ivLZYaHdRiRNEpE/vLmowCMMk5v0mO1zUgY3yUxmRDHMwIOACANtQtIxxDxTNYJVUfsLJraIwpZI3WwjVVCVdhn09oQ35FLv/2wgMty4XBvBFS5bfFcqwkRWSBIBzffsdw+KEg26RhBEoNMFuthHj1W9d6lh3c84LBzcuT0rTx8Rio2JRPLjCeTV929VCRYmAMaKZFpA= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0005_01D66007.A3F5A270" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB2555.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0afa9660-79c6-4739-030c-08d82e404ed7 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 13:08:20.6814 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: y7/gxW0u0DJrOHvUQph9RGVDkPRk1lD9DZSRrcCmflo3GgHoPUYbXlYuKfyNRtAvd0PeCxaFRetoMaF+VVTdyw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2748 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) 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, 22 Jul 2020 13:08:26 -0000 ------=_NextPart_000_0005_01D66007.A3F5A270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, > Looking into Mohits draft, cmp-over-coap is much simpler than est-over-coaps, as CMP does not need any binding to an underlying (D)TLS handshake. Not sure that is accurate. And EST does not bind to the tunnel protocol either unless proof of possession is used. For now the cmp-over-coap draft says When the end to end secrecy is desired for CoAP transport, CoAP over DTLS [RFC6347] as a transport medium SHOULD be used. COAP can run over DTLS or plain UDP and in rare cases TCP, TLS and maybe Websockets. I am not sure someone would run cmp-over-coap over TCP because then he could just run CMP natively without COAP in the middle. Any application layer protocol (CMP etc) can run over any transport but I am not sure there are more transports than the usual ones for cmp-over-coap anyway. I agree that if this gets picked up it should be by ACE. I would like to understand what gaps it is filling compared to est-over-coaps which took a lot of work and where it will be used and implemented in. Panos -----Original Message----- From: Ace On Behalf Of Brockhaus, Hendrik Sent: Wednesday, July 22, 2020 3:51 AM To: Benjamin Kaduk ; Michael Richardson Cc: Mohit Sahni ; steffen.fries@siemens.com; ace@ietf.org Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) > Von: Ace Im Auftrag von Benjamin Kaduk > > On Tue, Jul 21, 2020 at 04:31:05PM -0400, Michael Richardson wrote: > > > > Mohit Sahni wrote: > > > To give some background, this draft is an extension of Light Weight CMP > > > Profile ( > > > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf . > org%2Fhtml%2Fdraft-ietf-lamps-lightweight-cmp-profile- > 02&data=02%7C01%7Chendrik.brockhaus%40siemens.com%7Cc3b352cdfd > 174b0a7e2008d82dc1484f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C > 0%7C637309655452109222&sdata=QWHu3IEwf4TIIpaW0cvKuMiGXixV1AX > dws6g0vBQJPY%3D&reserved=0) > > > draft currently under development in the LAMPS WG. We > > discussed the > "CMPv2 > > > over CoAP" draft in the LAMPS WG and figured out that ACE WG > > is a > more > > > appropriate place for this draft. However, Jim suggested that > > we will > need > > > to modify the charter of the ACE WG to adopt this draft. > > > > We did est-over-coaps [still in the queue], why shouldn't we do > > cmp-over- > coap(s)? > > It may just be that "est-over-coaps is so obviously us" that I didn't > check the charter carefully at that time. But, at this point, we're > probably overdue for a recharter anyway, as the core framework is making its way to the IESG. > Steffen and I discussed this with Jim last year in Prague, if I remember correctly, and he recommended to submit cmp-over-coap to ACE and not to LAMPS. As est-over-coaps was in scope of ACE, I also think it is quite obvious to discuss cmp-over-coap in ACE. Looking into Mohits draft, cmp-over-coap is much simpler than est-over-coaps, as CMP does not need any binding to an underlying (D)TLS handshake. If you think this needs rechartering, we should go for it. - Hendrik _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace ------=_NextPart_000_0005_01D66007.A3F5A270 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjAwNzIyMTMwODE4WjAvBgkqhkiG9w0BCQQxIgQgklZ5tpG0OVC3H3vtHQJFd5wJfSaorHov XUkKj15HAaEwSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA iNNTm/TXn+ZqEHmPaHk6lqJMSv0Y4p1M8l2nluBoHkEXneAT04SUMxwuyIN+v0u1Eerf7X5VdD8A cnss84gQbXKWwRpCqVg0iNOotoLJv3d/P74zYWksO5Je0SoauMX3EtR6Pld1vp0py4vgaacQEbQ5 q0B70EkUcsqOXgMKw1pWGJk1cC6Z1+hefbo0brj4ihsbQjO1FFZLwgmqe4jFrphEohzJSPxVkYQO zG29nj3ioJRkOOLhnztIxKjNCQLDl93KXTR5llak86TazzMECDveMoJSiA3ASNzWpSzOpwCCTWlL gVfTOojK6ySLyRJ+tZwvNUXobjQG488dNDSEpQAAAAAAAA== ------=_NextPart_000_0005_01D66007.A3F5A270-- From nobody Wed Jul 22 06:42:32 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 691F33A0835 for ; Wed, 22 Jul 2020 06:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=siemens.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5v37hciIjVC8 for ; Wed, 22 Jul 2020 06:42:30 -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 938C93A0832 for ; Wed, 22 Jul 2020 06:42:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BsPxke0RfnxgbojXaTEvbLzNIvk4ENrRrMbYg8Cx8dA5MprH7rJsyRTgEB49qo9ZIIBZeEs3kVPd2uXGxf1ogkoJcF2sWCizdIeaTniWhWXvBofzArYZzLhTNPxfDTjpnOoU1fAAhUemGTQiiLJOEggJe/1epIFX+pSlQJmcwerXBM6iMpXcqSvu9Mvo84PjZNp+Nia/hmgUCWeQZhC+g/WwUMLjm71oEYWpPP1cBQOt0RyAFSiJeB1ArXdUkVtqIUeYYkgmZwxLZ8NzFIWrUjRSE0FhEsmKeW6ACMyAG1021KTJEx41N/s1IJd1JsXZSPDA0Ud/8Dafz6VowAZiWA== 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=2RDW3W5vgY1cYbrPzatD2UBgTSAdlEHBybt81xq3mw0=; b=SepnjaiaXhuqffVRauPbye7/sPf6YRRwv0H0rNJTCpaL0KvTQ1CvRcYbDyFiMhcayFI1wibnzQNbP+6C9OGrnTrD6a7Ul8xbK228l7/8iAuXO84VMiyG6Ar3cwvbRgoK72LnXAesBmgPHgJ36Yh7e0sOCLrmMtlnlBGujFx2gTs52isQUrwIy2gOBQQxllIWB84HrpKznCFoOO5FS5cAmhoIW2btvSUj6++qfV2lJhfy3Uk69Wb/+PKxr9gcD/nOEaoIXjgFB8hkoBAerBhRCj1GcveWa9WtO+RtwE3h/VxkKsO2gSpNHYCXsLRkxtWvBFAJ3p9OXQ/QnAjbiuyI0w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2RDW3W5vgY1cYbrPzatD2UBgTSAdlEHBybt81xq3mw0=; b=ARjmzT18O0Z8cyiKcVkayKt7nVP2O0O1qX17CO7SQoyX3z5h/LsGjSCcdGGY751VoNqNsrknyXbt3MiCPbnURpxQnpBHSBp51eYIEDpNSbyufDkAfRDGBH5GscDsTzQ/STNoYtkd8E7x6R+QkqznbiA3WGgWHGGQD6TdKQ+brmA= Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:184::10) by AM0PR10MB2098.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:4a::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3195.23; Wed, 22 Jul 2020 13:42:26 +0000 Received: from AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0]) by AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM ([fe80::288b:3b52:cf90:8fc0%9]) with mapi id 15.20.3195.028; Wed, 22 Jul 2020 13:42:26 +0000 From: "Brockhaus, Hendrik" To: "Panos Kampanakis (pkampana)" , Benjamin Kaduk , Michael Richardson CC: Mohit Sahni , "steffen.fries@siemens.com" , "ace@ietf.org" Thread-Topic: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) Thread-Index: AQHWX5lapX1JlGFGAU2aq0XyrzvJB6kSfISAgAAYZoCAAKL0AIAAW0cAgAACj1A= Date: Wed, 22 Jul 2020 13:42:25 +0000 Message-ID: References: <9794.1595363465@localhost> <20200721215825.GB41010@kduck.mit.edu> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=853d4b82-15da-4ce2-9193-0000a3646129; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-07-22T07:41:39Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=siemens.com; x-originating-ip: [165.225.200.158] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 90600f02-165d-4117-c5b0-08d82e4511f2 x-ms-traffictypediagnostic: AM0PR10MB2098: x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6vaOpPM33/+pxYAP5biEInH7+TF2K2Oc2W9cdeUYyc478oC3kao7FY69b4c1QIffsRrkCxAGkIQsJ7wwx3Cw65xQeJKoV+KVyFO7v21HJu39GRYdl5Dna++FRtafcWYWaZ/NiyTpOdHOijNGQf8M5nEayLu/tp1HMtWIB8XyPXLmSxWlgFMHKKSvLnfhZtl13pPq3xuKGzUkHmOxoNjIwcV/9kt72+8f/6tB8PZMznyfwFGOhnEiXJsaRKSE2tnFZJSC8ugo6P08zVYN81G3i85oajS1aN3vzvT349sQG4xM9FtFQzudGt+dlsW+UN2nHE+iIWvmkLqGyJD3b6BdRQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(39860400002)(136003)(396003)(376002)(9686003)(7696005)(99936003)(6506007)(478600001)(8936002)(4326008)(83380400001)(33656002)(26005)(52536014)(66616009)(64756008)(66476007)(2906002)(66946007)(76116006)(55016002)(86362001)(66446008)(66556008)(110136005)(55236004)(316002)(186003)(8676002)(54906003)(71200400001)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: WHgy/6iUcdRie51dT8xli1+ixi0Cy0ibqpAz7P9SGFh4voDWorATOs5APs5wl8v3sfxTKGN6DfkdQKRqjY3wtJXxa2731QNzhsHC364TgYMjnLJYnlX/TlMhfjKeL+iell5pVajYboO/j8hhIHRA+JqIuuehdxh44KHJVYRmi2mRqZqLTP3T2J6Hg/UBDaeItO16tYhOrohaCrrP371/9m37h6vw3HRV2ItqiEpgDE73ISyPVQbfLE2B1Am8GbcYBygPbuHa5RPdwLDMj8oVa9HgHH00mhelpxjCKOoOBZ7XMlLmdlRGqnxlZVdfKTDB0W6CpbFEOkffwTTke9nPwjpAChdvJWTo9WVSZbtLse6ZKDLRrrBsWtROKdvjlhTbfEqx0K+VZtrELdqhmDQQQLmp1RW0hx5F9jca6cACbCr1tqJxe+tt74B0BIumpIkQOvHnVZ7lOVG433EHJMx7TDrDufsf0WUIPDUf+968ji4LpnXraiFXW7DEEgnx+N+k Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0005_01D6603E.54979F30" MIME-Version: 1.0 X-OriginatorOrg: siemens.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB3153.EURPRD10.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 90600f02-165d-4117-c5b0-08d82e4511f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2020 13:42:26.0414 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3G9iJck2bO/yK3pUHP2lHBKFg3o7rVNOPCPvSSb1waH46CRCJmLvE5RVocPVe3g4+0xYDa0XmR/SMmb3RGaHdLBs+Lb227j3/a3bNEfBlMY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR10MB2098 Archived-At: Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) 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, 22 Jul 2020 13:42:31 -0000 ------=_NextPart_000_0005_01D6603E.54979F30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Panos, thnaks for you feedback. > Von: Panos Kampanakis (pkampana) > > Hi, > > > Looking into Mohits draft, cmp-over-coap is much simpler than > est-over-coaps, as CMP does not need any binding to an underlying (D)TLS > handshake. > > Not sure that is accurate. And EST does not bind to the tunnel protocol > either unless proof of possession is used. For now the cmp-over-coap draft > says > > When the end to end secrecy is desired for CoAP transport, CoAP over > DTLS [RFC6347] as a transport medium SHOULD be used. > > COAP can run over DTLS or plain UDP and in rare cases TCP, TLS and maybe > Websockets. I am not sure someone would run cmp-over-coap over TCP > because > then he could just run CMP natively without COAP in the middle. Any > application layer protocol (CMP etc) can run over any transport but I am not > sure there are more transports than the usual ones for cmp-over-coap anyway. It is not needed to run CMP over CoAP over TCP. UDP as transport protocol is fine. Actually CMP over CoAP also does not need DTLS underneath. But it also does not hinder to have a second line of defense. As I understand EST, proof-of-possession is purely provided by the self-signature in PKCS#10. But EST provides the proof-of-identity of the requesting party by the (D)TLS client authentication bound to the PKCS#10 (tls-unique copied in the P10 password filed). Is this correct? Such binding is not required for CMP. CMP does not have any requirements in this regard and provides prove-of-identity by signing the CMP messages. The advantage is that this prove-of-identity can be end-to-end and not only on the first hop to the (D)TLS server, like with EST. > > > I agree that if this gets picked up it should be by ACE. > > I would like to understand what gaps it is filling compared to > est-over-coaps which took a lot of work and where it will be used and > implemented in. I am uncertain if I understand your question correctly. Est-over-coaps described EST transport and not CMP transport on top of CoAP. One prototypic implementation can be found on github.com/siemens/embeddedCMP. - Hendrik ------=_NextPart_000_0005_01D6603E.54979F30 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCKzww ggVgMIIDSKADAgECAhQu9ZsCKKfbev/Vo6nuvQOgzxJqHTANBgkqhkiG9w0BAQsFADBIMQswCQYD VQQGEwJCTTEZMBcGA1UEChMQUXVvVmFkaXMgTGltaXRlZDEeMBwGA1UEAxMVUXVvVmFkaXMgUm9v dCBDQSAzIEczMB4XDTEyMDExMjIwMjYzMloXDTQyMDExMjIwMjYzMlowSDELMAkGA1UEBhMCQk0x GTAXBgNVBAoTEFF1b1ZhZGlzIExpbWl0ZWQxHjAcBgNVBAMTFVF1b1ZhZGlzIFJvb3QgQ0EgMyBH MzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBALPLDhBnjuoUl6cyKgpWNn9oTMezbzoj FJH/GX+lyqzus3adeumLG6trMdv6C1NMr8WlGnk8ikz/rN8l3k7ZgjILRN7K24yso24WgzumZEsy ifsWFjh+60Pi03RKwmIKcwrdSbNX0rAKhZ1xPN6jy8Ay8wE5IEMbNdFTs7HuxZNpgj4WtShGod7q iQntQ7gFRoqG9VlHvhtvASEQuf2p0ijKEDkJyhM2z5ytrUB0eSsCPzT/+iBpfdPuYfW6s+cw0Dcj hnJhRSlIWWhvd6Yugb4HTW+vzsRFE5EUcAaPH5/4h2mxDu/DiRnr6hxh/HpsitzWAwueJroS3dRU OasmozPqdYHaLc0PT+QD0e8VlxtrkMUCkJNmAiGxR96LmkqAuVWPtaIvwNYzZ9p+xKe0BETrR/vm WLn3DPB7K7HAcCnDQGItO0hp3CM8SOt7CXmpbdqoMJjPgHIDiKZbRq5yeXwIAyFlrrfhHKWxKqIx 3mYE98B06HHe/z1ZzJYmEouFlVcaq2t1C0Q9ESg8e2G34o9nT+XsPExggGlXOB4BW41V6MffwMx3 IzRJdXz2mBHrLd7tQS4UBQJ/4P4g6zXnEawizlc93skwbRADhc3x/4wWtcGyPohsYH+QT5X39i2t ATkHBPp1gH2/SVDt78nEfBzrgH7bttDdE/7J05zXspepAgMBAAGjQjBAMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTGF9C8qOoCQ/IbBpldK5Agudec5DANBgkqhkiG 9w0BAQsFAAOCAgEANGHZVrUSh1VN3aM1MUa7pAdyvF9hYuil+ws3sTy2s/opnX8C9aTJqJO3enEo aY9z4VKQ2tW+OuW3dmpWgCHfXebpOp7lPvaiaccqCrAYR9wgcH1Soz5ZfMG6ycgVQGHKctZwrNK3 8Bzkhinwzu9oY9C1IIoVYZp+hpi0ycJ2+8y6MBbMo2HGdBPla++jFeoD/hOLZOTTwdLohPtJ0RBN eWbrqv30jTEecBSt3N5nE0yBFWG8t9mRd3EZgWC78FiltZwL948iVSfASwFtO5kN1B2bY2cv0O4N yma8lE+mre387mOsVz9lJc+yho/QCP+4dhRu3uUn7Kt4tVO5tj/oIPnSqL5hRsqHjITz+fGgaJsi HoEmmxAEkXHABh/coNO5VqfjmC1/g53fjCucMo4ylPABPCIqn0PCLsOYOQc4e/xeAEIf8zImeYOE 9uXwwVESwAseBCMMVKVML0nFStG2bmANa/xri4UkZLeJDqslR1s8z35JvcfpCsba934OFwjTSJfQ cZLwDzk+NGocfdjyIq67afQztKZIVdEPDibo7LYLLaeFNc39Wcif0c0+Wik0uT2EzrFl1FmRkVZ1 IcF3nvl64WCd060EGPR8616Tj1NKIin4SCs+TYasW3/LBplZYNhYZZWNRNH3f34nf32ugPUHTLY+ nHFUmQRL/Vj5mPQwggaPMIIEd6ADAgECAhQMIWOkSST/t/zbZ1rNyu5yCMypWjANBgkqhkiG9w0B AQsFADBIMQswCQYDVQQGEwJCTTEZMBcGA1UEChMQUXVvVmFkaXMgTGltaXRlZDEeMBwGA1UEAxMV UXVvVmFkaXMgUm9vdCBDQSAzIEczMB4XDTE2MDYwNjE0NDM1OVoXDTMxMDYwNjE0NDM1OVowVDEL MAkGA1UEBhMCQk0xGTAXBgNVBAoMEFF1b1ZhZGlzIExpbWl0ZWQxKjAoBgNVBAMMIVF1b1ZhZGlz IEVudGVycHJpc2UgVHJ1c3QgQ0EgMyBHMzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AKDQr9a8kNTqqWTbSb/ABorCqUtKPZOVCnndOfZYMlpGnzwNziaqyM8wjLkcOxT7xVfOpLqYIMZJ s3jPKhNH6mPc8NYTwGTkIAcn65v+3TR5i0Z6ltS9CTYyHQYKGU7BgQcUUqEhFs2aAu9gaQcO2Rq6 pc6AG11dKYGAULWziUdTdcMesfNN2rOKMGAiJZWuGk8kuoZvRaIUr87uox1x1SZSNinHvf8CBgV3 5d8s08jFW80xP/3AkdLSDR+rQpd4TUDeiSKEyxzdKLqfqDc1TotD52Hjav1bv2qPWdz6gv/pl7Yb 9FbNcrvBRMUzQWz0BE6V2ch5Cd6hG/LoS+sCfF74izNdmun0T4NUAvjyTp0L4OjOaKsq558QyXQE sQoCbTLkl5BcOL5qJOJmp1WE7kcFBEF7GnVHt1fbCYfRKxwykc0KGsb31+7hzwRSHhvhY1kc+S4p X6vEKG1RVQZrPlI0ho1crBv0OsuponO8oz5My8CoPWb7ZNgbeJcAPLuxg7LH275aU8AGgrINSLZH u9TOEQKsQ+Zi3jTJYaxaL9Q7vhSinOvyCaifMyswSYNSJZ1LALfq9pUnEnPm8czWqjZCQPn7Xk4p OD3/aFh84uX/dX0bT7XkOCTeAhsVOK68kmZOW0lUH4hMUxTAZsBo1nR0uDERMFLFYoj5xcX9+OEr AgMBAAGjggFjMIIBXzAPBgNVHRMBAf8EBTADAQH/MEkGA1UdIARCMEAwPgYEVR0gADA2MDQGCCsG AQUFBwIBFihodHRwOi8vd3d3LnF1b3ZhZGlzZ2xvYmFsLmNvbS9yZXBvc2l0b3J5MHQGCCsGAQUF BwEBBGgwZjAqBggrBgEFBQcwAYYeaHR0cDovL29jc3AucXVvdmFkaXNnbG9iYWwuY29tMDgGCCsG AQUFBzAChixodHRwOi8vdHJ1c3QucXVvdmFkaXNnbG9iYWwuY29tL3F2cmNhM2czLmNydDAOBgNV HQ8BAf8EBAMCAQYwHwYDVR0jBBgwFoAUxhfQvKjqAkPyGwaZXSuQILnXnOQwOwYDVR0fBDQwMjAw oC6gLIYqaHR0cDovL2NybC5xdW92YWRpc2dsb2JhbC5jb20vcXZyY2EzZzMuY3JsMB0GA1UdDgQW BBTwFmAimDWJL4b8zdmHHA1jVW06RzANBgkqhkiG9w0BAQsFAAOCAgEAJ3C6bK6r2BE5pdemBIiZ IvbJ3B5BQnGq9wofNSaVvKGAD5pOnu40wdxzXvatWWyy6rY72lC3wSrYgTbXNhwaK+FESOzdmhIs ezTiBI/yY0HvuLsQyGYeAJiN5vuA199dz1EKyR00INsEWXmG7JsaGacnu3l7VXM9n6w2NaCY1dxe n3Pw1QkGg9mSbd/wLue0mQ33gQdJJyr+Fs5Jwyf2VoMm2i5Ltb4DMP3WvdHipTSDo9g86dNBorBl FHtLgLUeBUyb8Ik9nVqIud/pPF18u6ivTeRim1lKPjztcKwbawXFgcbiSDcn4qvDt64sVpmKmjOC 1AZX0zYNd5j2YHP8m355ida/zIMMacXFlmZ7QCoThQXJn73n8N4yf40VLGj9iiJHl5MPMao1COyh xSZx220rW6bI94viPGJmM+NWwOV7eH8O7PPfubtWfYtMkYLglkeUcSSRnmvw7S8NpaxSATAvxS3D rvBY2RFKQs7yA1nGhT4KTn0l8hBiOBcuE3QK+5seyWo6xHwfYN9cYKG4j3wwWCwuSXyzgnKuKmHc J5E57JoyWiws6QNI/ilj/TaLcCS2l32GYOEgnFM12GHEEsaltl4iH0+sXj1Pido/SdJhpMwCGFK9 HLiqnOzD12zkZOu4Rl+nPWGpqhL3oXvGTIe6vgERWyQsJwMVYpBHCkkwggdcMIIFRKADAgECAgQy VcMtMA0GCSqGSIb3DQEBCwUAMIGeMQswCQYDVQQGEwJERTEPMA0GA1UECAwGQmF5ZXJuMREwDwYD VQQHDAhNdWVuY2hlbjEQMA4GA1UECgwHU2llbWVuczERMA8GA1UEBRMIWlpaWlpaQTMxHTAbBgNV BAsMFFNpZW1lbnMgVHJ1c3QgQ2VudGVyMScwJQYDVQQDDB5TaWVtZW5zIElzc3VpbmcgQ0EgRUUg RW5jIDIwMTYwHhcNMTkwNjExMTE1NzA4WhcNMjIwNjExMTE1NzA4WjBnMREwDwYDVQQFEwhaMDAw MlYzVTEQMA4GA1UEKgwHSGVuZHJpazESMBAGA1UEBAwJQnJvY2toYXVzMRAwDgYDVQQKDAdTaWVt ZW5zMRowGAYDVQQDDBFCcm9ja2hhdXMgSGVuZHJpazCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALfosFMescI35DnhoAOHk+1RhJCKnE9nZOCHxy51rgnFvKhAJubydU9qBnb5NcaCSyeS U43VfSo6Yh0qyCXxV9HbfBKZCUe40W1ezKtc1nL547irfftZGKDHvSf8HnKhwEmTHjaNPLWK/HRz ZjFuWZziUhZkZCB6v19I6P0d91174YSsj5uzu6ePHZLNm2X3qhTbv01Io0zsex+bRHXqYNqZg9Tr 9I7d+SAYG0Si7hGRn271uXxczRlRIrMw0/YEwjKPMz1UMn2e7BNcJwyvo/Uxy0JRL1IIrSrcbomN nW7o3V2WYtAAQBcbdkNhu1G6gEh8vkb8fDjFDT7F2LuX3vECAwEAAaOCAtYwggLSMIIBBAYIKwYB BQUHAQEEgfcwgfQwMgYIKwYBBQUHMAKGJmh0dHA6Ly9haC5zaWVtZW5zLmNvbS9wa2k/WlpaWlpa QTMuY3J0MEEGCCsGAQUFBzAChjVsZGFwOi8vYWwuc2llbWVucy5uZXQvQ049WlpaWlpaQTMsTD1Q S0k/Y0FDZXJ0aWZpY2F0ZTBJBggrBgEFBQcwAoY9bGRhcDovL2FsLnNpZW1lbnMuY29tL0NOPVpa WlpaWkEzLG89VHJ1c3RjZW50ZXI/Y0FDZXJ0aWZpY2F0ZTAwBggrBgEFBQcwAYYkaHR0cDovL29j c3AucGtpLXNlcnZpY2VzLnNpZW1lbnMuY29tMB8GA1UdIwQYMBaAFKGrLG6gevDTwk3qH/EeIYr8 DK3vMAwGA1UdEwEB/wQCMAAwRQYDVR0gBD4wPDA6Bg0rBgEEAaFpBwICAwEDMCkwJwYIKwYBBQUH AgEWG2h0dHA6Ly93d3cuc2llbWVucy5jb20vcGtpLzCBygYDVR0fBIHCMIG/MIG8oIG5oIG2hiZo dHRwOi8vY2guc2llbWVucy5jb20vcGtpP1paWlpaWkEzLmNybIZBbGRhcDovL2NsLnNpZW1lbnMu bmV0L0NOPVpaWlpaWkEzLEw9UEtJP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3SGSWxkYXA6Ly9j bC5zaWVtZW5zLmNvbS9DTj1aWlpaWlpBMyxvPVRydXN0Y2VudGVyP2NlcnRpZmljYXRlUmV2b2Nh dGlvbkxpc3QwLAYDVR0lBCUwIwYIKwYBBQUHAwQGCisGAQQBgjcKAwQGCysGAQQBgjcKAwQBMA4G A1UdDwEB/wQEAwIEMDAoBgNVHREEITAfgR1oZW5kcmlrLmJyb2NraGF1c0BzaWVtZW5zLmNvbTAd BgNVHQ4EFgQUIuav9f/gldx+iX/SVlewSqmTGIQwDQYJKoZIhvcNAQELBQADggIBAG3gXIH+UP8w Wgn0fJ7OVOq+n5fEAb7YKVmm3E2KoN+4nFFjxoHfaZ1MSMf5uDOTfaaQu+Ix7+h7SLPb+kvFWoTr MsstpL5HlGH3hK9UUbUrrPk5Ihw6hKf+dbMWkIpwbs+nmmJHfGyY+vBcQXYRHlG/yFPe0jXqpkXR uWN3KRn7TN7ka/YDUguQXHr4rZw7moUyU7Jh6Cb4bVfUFELVV+OnrEo60hGP9MOZl8a0lynefibg V/e57TmHxOZdt1M3AyLyPesz3Eoak7cWzKCnJ4PQYmml5FAV9ZogYbh+QwPGylAko1FqD+EIhSfA HYMIvjcOLMaurSSH39hS9kPXo28Ty0TknA1R6kmNBBR6+JXp6p8vPWXUPE3RP85HRK9ulXRfIVyv vw4L/anpol13bbll4cGWSuHsz/LFGSp9jLRjbuf3kGXQFyKcssk6Q09S4Pn9q9mHF0c0SZ0lEbbO eVARVC/SUaqiGmSNowAYvOe5Erf4EbevBpQctHdBGqeif70eP7BFsdYPORiELpu9jSWuV05IdeGz jRXNqcSrapr7w6MyCX5qPRnZCjtzyHcA6LkAdcbbp/lbK/XTulDUiWft+9ojYQ3GyKxfxeH3Lx2M R0XFk1/fYTVVaYrwmJrqdP0lrHdqNcBxsBnD+upuL6oyDthkxYaePHFOnUPu0T3CMIIHcjCCBVqg AwIBAgIUH4eK79p11uy6f6YePUidYHxqGOgwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCQk0x GTAXBgNVBAoMEFF1b1ZhZGlzIExpbWl0ZWQxKjAoBgNVBAMMIVF1b1ZhZGlzIEVudGVycHJpc2Ug VHJ1c3QgQ0EgMyBHMzAeFw0xNjA4MDQxNTM1NTNaFw0yMjA4MDQxNTM1NTNaMIGeMQswCQYDVQQG EwJERTEPMA0GA1UECAwGQmF5ZXJuMREwDwYDVQQHDAhNdWVuY2hlbjEQMA4GA1UECgwHU2llbWVu czERMA8GA1UEBRMIWlpaWlpaQTMxHTAbBgNVBAsMFFNpZW1lbnMgVHJ1c3QgQ2VudGVyMScwJQYD VQQDDB5TaWVtZW5zIElzc3VpbmcgQ0EgRUUgRW5jIDIwMTYwggIiMA0GCSqGSIb3DQEBAQUAA4IC DwAwggIKAoICAQDLP2LOvaPLcdihJQJ8m+ojJYYd2QJqqzZ+nNtqr7UyvHKkrVlqwn/1OzuvnY48 8t4FoL39Qs8LCifPntBSvxMC9CGqrpoxwh/Ok6gbeToQogs8LOOElaz3lm2gOvIl9pgRKDsk8wR0 QueeN9WopjkgZiKXSTyWvU9qVsgCHNKgIQvE194FwlqT1HARrzYZ3zOf9CMmakT1VY1DehsmLItB qt0p6fZgNsWtoUfDv7DeiRxGgqYP5aFox5q3fZ9GcZwmIcDUbf4W7HsZ9SPRjdBRGoYITEJ/imOT /GGYbjzNTiSQe5Kh7DedjgE0dk83B8Z9v3r5GhdgDGC5cPW80OmMtEeLZI7fzlW3Xys7vpKfryon xrRX1ATMlbSrEeYfQZmtYbiQfUzacpf1zMTDruqRuWvFRm3Qbec9VRQdZpMsHnZDYpbDAEbWIb9A tEqoSZ60QER7fxbn1L4LzQ9Q45Zn3uW4+beDAoClZ8l77TdCniENGr46gWOAELmNBB86kNXfL/bf FIOT97n133f6zimxqg3A2OEiiCcbBnsrdKPg1xc7p36XrIhfghQ3w7IEFxHvjadmd9WqT3+on/yH +g1x/5R20HO+0n12ujNn3n5d40WBXk/emrl6f1vdzcgRShdci7LQrVMgxIIAK9x5rs3xKh/8/USz FP8K004TO8vV/wIDAQABo4IB7zCCAeswgYEGCCsGAQUFBwEBBHUwczA6BggrBgEFBQcwAoYuaHR0 cDovL3RydXN0LnF1b3ZhZGlzZ2xvYmFsLmNvbS9xdmVudGNhM2czLmNydDA1BggrBgEFBQcwAYYp aHR0cDovL3F2ZW50Y2EzZzMub2NzcC5xdW92YWRpc2dsb2JhbC5jb20wHQYDVR0OBBYEFKGrLG6g evDTwk3qH/EeIYr8DK3vMBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYDVR0jBBgwFoAU8BZgIpg1iS+G /M3ZhxwNY1VtOkcwgYkGA1UdIASBgTB/MEYGDCsGAQQBvlgAA44IADA2MDQGCCsGAQUFBwIBFiho dHRwOi8vd3d3LnF1b3ZhZGlzZ2xvYmFsLmNvbS9yZXBvc2l0b3J5MDUGCCsGAQQBoWkHMCkwJwYI KwYBBQUHAgEWG2h0dHA6Ly93d3cuc2llbWVucy5jb20vcGtpLzA9BgNVHR8ENjA0MDKgMKAuhixo dHRwOi8vY3JsLnF1b3ZhZGlzZ2xvYmFsLmNvbS9xdmVudGNhM2czLmNybDAOBgNVHQ8BAf8EBAMC AQYwNgYDVR0lBC8wLQYIKwYBBQUHAwQGCysGAQQBgjcKAwQBBgorBgEEAYI3CgMEBggrBgEFBQcD CTANBgkqhkiG9w0BAQsFAAOCAgEAJA4iSilLZxsyCEkItAJAy9v3D+L8MXAMHP+SvIAMaS7fOXJg oDMkg2paTuU/3Wm5lfBQnz/FbNW1n9Ffezf9mBV/rIhfbzbOL0wkzLSEEd/VtBrNGuPmDkc+S2wy QhrZWeRj95OWc09moGqPUPNwRSAWdBE9PByi66gUgiZIovAev9R6Z2CD4AnJ4mlwSbd0B0WN7jUX xMenzbGnSL/ul2iqp0F0PRbmbW7FZDNKqQFjD+RcS7nTsjX/rw6E4230LLgqvk/wuW1xqeGeHwuE uGgSxJDd/0Vr6k2/szdMAXyxOnFNc7e56+RMJrB00hx1X1zhXYfySNE482n1rKmLRP4vzuWmMWDt h010YSj39fY08mzAW9uviSDoLD9OuvwMgS9lVepLqcZxx/Vk4lqQHFFBeZFp8uOuyRFhDGEOBQzn FvWAM3eehkQ8+RtumpU47f+N/p4WJjXmN1pHKhTv/XGyDvFOvWkli+fpVfKQOwPjXpUn+ZIl3/h6 3N6lg+8ygaeV3OImsOfFgA5vu0iYhdqi1d6itCcAUW2IhqHIyY6qt15pqDsf7pOQId/YNkk/0H0j 75dounsHmgSJ9+AIP/BA9x61qN3zoHcP3s4dam8CC3fbanIvNGTfCiuoELcRt75u7KM4Xnv6sbAq dfhv6ToLpqaPIOawNXGriDV4uNQwggeJMIIFcaADAgECAgR4pci3MA0GCSqGSIb3DQEBCwUAMIGf MQswCQYDVQQGEwJERTEPMA0GA1UECAwGQmF5ZXJuMREwDwYDVQQHDAhNdWVuY2hlbjEQMA4GA1UE CgwHU2llbWVuczERMA8GA1UEBRMIWlpaWlpaQTIxHTAbBgNVBAsMFFNpZW1lbnMgVHJ1c3QgQ2Vu dGVyMSgwJgYDVQQDDB9TaWVtZW5zIElzc3VpbmcgQ0EgRUUgQXV0aCAyMDE2MB4XDTE5MDYxMTEx NTUyM1oXDTIyMDYxMTExNTUyM1owZzERMA8GA1UEBRMIWjAwMDJWM1UxEDAOBgNVBCoMB0hlbmRy aWsxEjAQBgNVBAQMCUJyb2NraGF1czEQMA4GA1UECgwHU2llbWVuczEaMBgGA1UEAwwRQnJvY2to YXVzIEhlbmRyaWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCCQC3UAdhcMjgeyjlv g7GImv1nixMrrjkTcTX0a1rEEDi4WE6NNMdg72K015iJah8czYk1HqnD3SEWJEl65GPFHeAnsSF5 SaCiAEllW3Zp3NKfPUVrL2qmHXhP730EzUWluhjj6Poh4KqJRlja3lO0TJ3AlfwQ2LI3L+HjS9I5 Qi5x+niNUIGwNsEiNmc8LuWWcIoMSdFjKsnJFpDBmTzyOnZvXqyiMhNcYV5MZE2FhX0TBBxVlSlB FP7g/ctu9aVJnAzuhxbq3J49MgPXDV9E+0r8EG/EfmjRIsv4pBIZ4PyOiOV0Y/hmBAo+q6nonshc y3+cJHLQHXWzWd03ubKJAgMBAAGjggMCMIIC/jAdBgNVHQ4EFgQU1I8OEojQ1TCErPF/C2H4dKco h6IwVwYDVR0RBFAwTqAtBgorBgEEAYI3FAIDoB8MHWhlbmRyaWsuYnJvY2toYXVzQHNpZW1lbnMu Y29tgR1oZW5kcmlrLmJyb2NraGF1c0BzaWVtZW5zLmNvbTAOBgNVHQ8BAf8EBAMCB4AwKQYDVR0l BCIwIAYIKwYBBQUHAwIGCCsGAQUFBwMEBgorBgEEAYI3FAICMIHKBgNVHR8EgcIwgb8wgbyggbmg gbaGJmh0dHA6Ly9jaC5zaWVtZW5zLmNvbS9wa2k/WlpaWlpaQTIuY3JshkFsZGFwOi8vY2wuc2ll bWVucy5uZXQvQ049WlpaWlpaQTIsTD1QS0k/Y2VydGlmaWNhdGVSZXZvY2F0aW9uTGlzdIZJbGRh cDovL2NsLnNpZW1lbnMuY29tL0NOPVpaWlpaWkEyLG89VHJ1c3RjZW50ZXI/Y2VydGlmaWNhdGVS ZXZvY2F0aW9uTGlzdDBFBgNVHSAEPjA8MDoGDSsGAQQBoWkHAgIDAQEwKTAnBggrBgEFBQcCARYb aHR0cDovL3d3dy5zaWVtZW5zLmNvbS9wa2kvMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUvb0q QyI9SEpXfpgxF6lwne6fqJkwggEEBggrBgEFBQcBAQSB9zCB9DAyBggrBgEFBQcwAoYmaHR0cDov L2FoLnNpZW1lbnMuY29tL3BraT9aWlpaWlpBMi5jcnQwQQYIKwYBBQUHMAKGNWxkYXA6Ly9hbC5z aWVtZW5zLm5ldC9DTj1aWlpaWlpBMixMPVBLST9jQUNlcnRpZmljYXRlMEkGCCsGAQUFBzAChj1s ZGFwOi8vYWwuc2llbWVucy5jb20vQ049WlpaWlpaQTIsbz1UcnVzdGNlbnRlcj9jQUNlcnRpZmlj YXRlMDAGCCsGAQUFBzABhiRodHRwOi8vb2NzcC5wa2ktc2VydmljZXMuc2llbWVucy5jb20wDQYJ KoZIhvcNAQELBQADggIBAAc+cUPL7VNeN5GTpmG1ziAaRQkFNF/L/WuJ4UPlv3BCMlNSv4Ib7EHg GMQzaUuOb1y4WaIxcyHNLd4wubO8AqSDzepKIKvq4gV473P4GyjKT48PmuenQqPA4Ptvk4U8b0XU 2BbLoqpld4MLKLt1wmWvOgQnxq22EXX12aV61c+nGPARPUqWE8jOUzvFxinKKDlBCK9ndoGEq4ti /zPk8ZiHSGZQxXGBeyyEoK3+G7NRzZVhBtvcm6xH2iwM2gLRuiiE2jbU79fNG4IyYYA71yh3iEQe xj5JNBXUUOBBz7NqtwHpRfQqsC6C1xNIdssg6Dn9F9+F7E+NmXuM4i6SpX3lL0ImjJI8G1/CQlE1 /fo3q6Nx01yiZiC2JIVOGMoeRI+FI4+siQy6jASYUjTiv0UD8yVYt1SDxw2vnSttMXkVHBz5uE17 PuArDxJ0RUOnZGOsfukVh+ZjWpKlFp7Ofk2PLq7h88gWsP5vQ1CErxRj4j93afghvRSTrHK6ciU+ b4kasV0X9TB0CoQ7o/5ozfJ1n7uCpGW+3eZQIfyk4sCig8DDm51EpbaCxPYpRpCExs1mliHhrvHd HUCJDe0YY0rb9yghB46T1KBOkxRVlsbrynwXd2sPL+hsftVeSz4X2Qf3Ktfnrawx86ioN57xsBng ZvZdeJuMM3LVljZx4wu8MIII3jCCBsagAwIBAgIUdvQRtLDJQnfSl7x3GeF1RfDEwFEwDQYJKoZI hvcNAQELBQAwVDELMAkGA1UEBhMCQk0xGTAXBgNVBAoMEFF1b1ZhZGlzIExpbWl0ZWQxKjAoBgNV BAMMIVF1b1ZhZGlzIEVudGVycHJpc2UgVHJ1c3QgQ0EgMyBHMzAeFw0xODA3MjUxODUxMjBaFw0y MjA4MDQxNTMzMDZaMIGfMQswCQYDVQQGEwJERTEPMA0GA1UECAwGQmF5ZXJuMREwDwYDVQQHDAhN dWVuY2hlbjEQMA4GA1UECgwHU2llbWVuczERMA8GA1UEBRMIWlpaWlpaQTIxHTAbBgNVBAsMFFNp ZW1lbnMgVHJ1c3QgQ2VudGVyMSgwJgYDVQQDDB9TaWVtZW5zIElzc3VpbmcgQ0EgRUUgQXV0aCAy MDE2MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAy1aUq88DjZYPge0vZnAr3KJHmMi0 o5mphy54Xr592Vtf8u/B3TCyD+iGCYANPYUq4sG18qXcVxGadz7zeEm6RI7jKKl3URAvzFGiYFor ZE0JKxwo956T/diLLpH1vHEQDbp8AjNK7aGoltZnm/Jn6IVQy9iBY0SElRIBhUlppS4/J2PHtKEv QVYJfkAwTtHuGpvPaesoJ8bHA0KhEZ4+/kIYQebaNDf0ltTmXd4Z8zeUhE25d9MzoFnQUg+F01ew Mfc0OsEFheKWP6dmo0MSLWARXxjI3K2RTHtJU5hxjb/+SA2wlfpqwNIAkTECDBfqYxHReAT8Peez vzEkNZ9RrXl9qj0Cm2iZAjY1SL+asuxrGvFwEW/ZKJ2ARY/ot1cHh/I79srzh/jFieShVHbT6s6f yKXmkUjBOEnybUKUqcvNuOXnwEiJ/9jKT5UVBWTDxbEQucAarVNFBEf557o9ievbT+VAZKZ8F4tJ ge6jl2y19eppflresr7Xui9wekK2LYcLOF3X/MOCFq/9VyQDyE7X9KNGtEx74V6J2QpbbRJryvav h3b0eQEtqDc65eiEaP8awqOErN8EEYh7Gdx4Um3QFcm1TBhkZTdQdLlWv4LvIBnXiBEWRczQYEIm 5wv5ZkyPwdL39Xwc72esPPBu8FtQFVcQlRdGI2t5Ywefq48CAwEAAaOCA1owggNWMIGBBggrBgEF BQcBAQR1MHMwOgYIKwYBBQUHMAKGLmh0dHA6Ly90cnVzdC5xdW92YWRpc2dsb2JhbC5jb20vcXZl bnRjYTNnMy5jcnQwNQYIKwYBBQUHMAGGKWh0dHA6Ly9xdmVudGNhM2czLm9jc3AucXVvdmFkaXNn bG9iYWwuY29tMB0GA1UdDgQWBBS9vSpDIj1ISld+mDEXqXCd7p+omTASBgNVHRMBAf8ECDAGAQH/ AgEAMB8GA1UdIwQYMBaAFPAWYCKYNYkvhvzN2YccDWNVbTpHMIIB9gYDVR0gBIIB7TCCAekwRgYM KwYBBAG+WAADjggAMDYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cucXVvdmFkaXNnbG9iYWwuY29t L3JlcG9zaXRvcnkwOgYNKwYBBAGhaQcCAgMCATApMCcGCCsGAQUFBwIBFhtodHRwOi8vd3d3LnNp ZW1lbnMuY29tL3BraS8wOgYNKwYBBAGhaQcCAgMBATApMCcGCCsGAQUFBwIBFhtodHRwOi8vd3d3 LnNpZW1lbnMuY29tL3BraS8wOgYNKwYBBAGhaQcCAgQBATApMCcGCCsGAQUFBwIBFhtodHRwOi8v d3d3LnNpZW1lbnMuY29tL3BraS8wOgYNKwYBBAGhaQcCAgMCAjApMCcGCCsGAQUFBwIBFhtodHRw Oi8vd3d3LnNpZW1lbnMuY29tL3BraS8wOgYNKwYBBAGhaQcCAgMBAjApMCcGCCsGAQUFBwIBFhto dHRwOi8vd3d3LnNpZW1lbnMuY29tL3BraS8wOgYNKwYBBAGhaQcCAgQBAjApMCcGCCsGAQUFBwIB FhtodHRwOi8vd3d3LnNpZW1lbnMuY29tL3BraS8wNwYKKwYBBAGhaQcCBTApMCcGCCsGAQUFBwIB FhtodHRwOi8vd3d3LnNpZW1lbnMuY29tL3BraS8wPQYDVR0fBDYwNDAyoDCgLoYsaHR0cDovL2Ny bC5xdW92YWRpc2dsb2JhbC5jb20vcXZlbnRjYTNnMy5jcmwwDgYDVR0PAQH/BAQDAgEGMDMGA1Ud JQQsMCoGCCsGAQUFBwMCBggrBgEFBQcDBAYKKwYBBAGCNxQCAgYIKwYBBQUHAwkwDQYJKoZIhvcN AQELBQADggIBACctJARW7dANu7cI0rb5sDbWJGp+xoe2Hd7HZwUcIBj1rsg2XFQZeGGZntwtSZkc 1ckgiDXemHHFKfXdvi8/JRM7Iy7WM7pGY4cou3c1DGW1KAXUqIOlMYHs2gK9jq/U0+CvqNrmocwQ 7hUivkb/VpFxHxfAEBz9aJbOBhWzrAyUUgwlqUaf0kNwSqZO8Mglw6bTO1LHpglb5COqZRIBkGtH Emmj71sNFQG5KI/SxMgm3hCAbuodu6XdZfjFAFmSdYjsyoOBQGDcUw+7srCdtHQxCkh3eRGeU4+W YA5sRjHhBAYNFxXbRQZEgoD7/UD6SWlfcVb+35gs4bm76Q3wZf6ALmNnoFvMoYm2JjJ3u17MgcZu cINXqGNt7LtxKubjoix6jzOC6SZCqkcRfhReTplHXocGIXCjrHNZMOqUlcwtkUB/lPVs+bgXbYt/ JaXVgvhNsqWpUD3TGYfdAcx5xbm0ItExh35b9YSkxjzeH0nl33Gh5qQbq7xTrlhBNfa+9XWCtbwC X8M5CBf/kOVdO/HTuBgta/ddEGs7m0Y8ytKzJmo4R/QWseDVEXMGcEIiPye76IJF2k/GktELO1jw J6uPhamxO6tqlvwh1YZFGxz+WL2CN0eYZpbzT+dYBEZIP1jDNQp+nlWbqaNheUg5jDXuaNZuSlMk cbPChd+vfWvqMYIELTCCBCkCAQEwgagwgZ8xCzAJBgNVBAYTAkRFMQ8wDQYDVQQIDAZCYXllcm4x ETAPBgNVBAcMCE11ZW5jaGVuMRAwDgYDVQQKDAdTaWVtZW5zMREwDwYDVQQFEwhaWlpaWlpBMjEd MBsGA1UECwwUU2llbWVucyBUcnVzdCBDZW50ZXIxKDAmBgNVBAMMH1NpZW1lbnMgSXNzdWluZyBD QSBFRSBBdXRoIDIwMTYCBHilyLcwDQYJYIZIAWUDBAIBBQCgggJVMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTIwMDcyMjEzMzk0N1owLwYJKoZIhvcNAQkEMSIEIOmC rwTv/gtP/kWTNx/VZxWkNlnrTsCodeQQCxaQB0+rMHIGCSqGSIb3DQEJDzFlMGMwCwYJYIZIAWUD BAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwCwYJYIZIAWUDBAIBMAsG CWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowgbgGCSsGAQQBgjcQBDGBqjCBpzCBnjEL MAkGA1UEBhMCREUxDzANBgNVBAgMBkJheWVybjERMA8GA1UEBwwITXVlbmNoZW4xEDAOBgNVBAoM B1NpZW1lbnMxETAPBgNVBAUTCFpaWlpaWkEzMR0wGwYDVQQLDBRTaWVtZW5zIFRydXN0IENlbnRl cjEnMCUGA1UEAwweU2llbWVucyBJc3N1aW5nIENBIEVFIEVuYyAyMDE2AgQyVcMtMIG6BgsqhkiG 9w0BCRACCzGBqqCBpzCBnjELMAkGA1UEBhMCREUxDzANBgNVBAgMBkJheWVybjERMA8GA1UEBwwI TXVlbmNoZW4xEDAOBgNVBAoMB1NpZW1lbnMxETAPBgNVBAUTCFpaWlpaWkEzMR0wGwYDVQQLDBRT aWVtZW5zIFRydXN0IENlbnRlcjEnMCUGA1UEAwweU2llbWVucyBJc3N1aW5nIENBIEVFIEVuYyAy MDE2AgQyVcMtMA0GCSqGSIb3DQEBAQUABIIBAC0Qrt9GVWh3cN/Z0j2gZJ9GIf/DBDnpEl8kHjNc m2PdEpwkYAoUjryNhBFY80m0i4Gx/RdVQR5DmJ9orxk3q37vhOOhgH0Pw/8u3R8hvFHCbW7DOOIB aKdJBBJXBIBfKAhegRo6uHwAQ8MUmA9/r9Jzw1Rw0dzeZg+Jzew7GGsN8M89UlE1XZ0MCHLG2VUD KYIt6slRrBW2af6RvOYnh4klYJe+uhOGSsqaR0vzsV5qErG8H4lDxxAqWbrwabriQWFwrUSxY0qR HhVbmJYkCgQTonGyl0Egv1OpVTlBz9FyJG5NJ6RC8Mr3+847qfgr0nAlTSGI3F/+ezCugFvmahoA AAAAAAA= ------=_NextPart_000_0005_01D6603E.54979F30-- From nobody Wed Jul 22 10:40: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 8AFCA3A086C for ; Wed, 22 Jul 2020 10:40: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=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 upWbNTaCjhno for ; Wed, 22 Jul 2020 10:40:32 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 267983A0872 for ; Wed, 22 Jul 2020 10:40:32 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id d198so1636941vsc.1 for ; Wed, 22 Jul 2020 10:40:32 -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=usHFq29KYLDGTMdhxkHl1V+B8M5beA82oSt9TkIQwkc=; b=ZCvwP9h3CVupcUy5Oa4PpnFOQOODipXYjsZc9D0V2x5BVqE/5LxGtCCYKtsHEZuzYV QvmiVzXV1Y3H/+68dzdkjlNvyWvnUS5+ry9xyNXaz6UclkWTmCyFHYcmIZln0RDxScte ab023A9vZC+2XJ+KerYhNuYiHe0sx4/7K1tbUURVbju67/nUZEksZZpecuvprm1P5OIi rwlGh76TpAiy8xJhj+F8/SF8l71qXmQbMV/j0QE5Sj/h/IjyeOpcKtZekjUhEYWgUXIV /TFVWWvdywWakeRly+MiVgk/FdnwGbVpxYhB6+pEElD4moJiHjVeYUaFpLyZbhS8ApKR Pnjw== 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=usHFq29KYLDGTMdhxkHl1V+B8M5beA82oSt9TkIQwkc=; b=ZkxyWtGwatQYGRqhQqwC+FPR7THrBzbZ2eGuNtiZKwd4hiijn0gVhnUPr2oZTcUNnD Xcr0CwxHd9GFjWl0dtvihroqVuvypK1TMkx7BOak95WJCwdvuZLCiP00ojsjoskyVbji a4o0FM923fP1L+E38/Z2Q472qYLwtwfxM+OjT2MmtRkVwGVyW7+htwuCMm4Ds/PFuiEe 5h3ogjIWnVuhGg+AKYE4pViHwkafQIOQEQ/ZaNJ3W9OiRddsj/DjHNGhpI123F5tWKUF 1ylEmR6na6s5KFepd70zPkqXQpYm4jM+Hlkw1byKkZ/Kncqyt7Cx+zxRkNUdE99raC0M 3jHg== X-Gm-Message-State: AOAM530ZzdVpizIMfTILzYjKppdVxc+4jq1hF1/sOInzpR3bza3Vdn7Z gmq8d8usvE1l4CpIMOI7hz2qerB0To5vgZCp9d8= X-Google-Smtp-Source: ABdhPJxabTCdRVRON1oG360ULqwy/JppRQpuSCeNg2c40ClHbvTKYBidsN1kLvS3teZCuqpOnQ5begUIuZb/kKjdBKU= X-Received: by 2002:a05:6102:31bc:: with SMTP id d28mr1005479vsh.180.1595439631261; Wed, 22 Jul 2020 10:40:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Wed, 22 Jul 2020 13:40:20 -0400 Message-ID: To: Mohit Sahni Cc: Ace Wg Content-Type: multipart/alternative; boundary="0000000000007b64e005ab0b3c30" Archived-At: Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) 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, 22 Jul 2020 17:40:35 -0000 --0000000000007b64e005ab0b3c30 Content-Type: text/plain; charset="UTF-8" Hi Mohit, We apology for missing your request and thank you for reiterating the request. We gave you a 15 min [1], if that is not enough, please let us know. Yours, Daniel [1] https://codimd.ietf.org/notes-ietf-108-ace On Tue, Jul 21, 2020 at 3:58 PM Mohit Sahni wrote: > Hi Daniel, > I had requested, in an earlier email, some time to discuss what changes > are required in the ACE WG charter to adopt my draft for "CMPv2/Lightweight > CMP profile over CoAP transport" ( > https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00). > Would it be possible for you to add it to the tentative agenda? > > To give some background, this draft is an extension of Light Weight CMP > Profile ( > https://tools.ietf.org/html/draft-ietf-lamps-lightweight-cmp-profile-02) > draft currently under development in the LAMPS WG. We discussed the "CMPv2 > over CoAP" draft in the LAMPS WG and figured out that ACE WG is a more > appropriate place for this draft. However, Jim suggested that we will need > to modify the charter of the ACE WG to adopt this draft. > > Thanks > Mohit > > On Tue, Jul 21, 2020 at 11:22 AM wrote: > >> Send Ace mailing list submissions to >> ace@ietf.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://www.ietf.org/mailman/listinfo/ace >> or, via email, send a message with subject or body 'help' to >> ace-request@ietf.org >> >> You can reach the person managing the list at >> ace-owner@ietf.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of Ace digest..." >> Today's Topics: >> >> 1. interim meeting planification (Daniel Migault) >> 2. ACE interim meeting tentative (Option2) (Daniel Migault) >> 3. ACE tentative interim meeting (option 1) (Daniel Migault) >> 4. IETF 108 tentative agenda and presentations (Daniel Migault) >> >> >> >> ---------- Forwarded message ---------- >> From: Daniel Migault >> To: Ace Wg >> Cc: >> Bcc: >> Date: Tue, 21 Jul 2020 11:59:22 -0400 >> Subject: [Ace] interim meeting planification >> Hi, >> >> Please find a doodle [1] with two time slots for the interim meetings >> that are planned 1 per month the first week of the month 10 AM - 11 AM EST. >> The two proposed days are Monday and Thursday. Please select your >> preferred day by July 26. >> >> I am sending the calendar serie to the ace list so everyone can better >> see how it matches its calendar. >> >> Yours, >> >> Jim and Daniel >> >> [1] https://doodle.com/poll/x2dghwiqmqei6cc8 >> -- >> Daniel Migault >> Ericsson >> >> >> >> ---------- Forwarded message ---------- >> From: Daniel Migault >> To: Ace Wg >> Cc: >> Bcc: >> Date: Tue, 21 Jul 2020 15:59:52 +0000 >> Subject: [Ace] ACE interim meeting tentative (Option2) >> >> >> >> ---------- Forwarded message ---------- >> From: Daniel Migault >> To: Ace Wg >> Cc: >> Bcc: >> Date: Tue, 21 Jul 2020 16:00:38 +0000 >> Subject: [Ace] ACE tentative interim meeting (option 1) >> >> >> >> >> ---------- Forwarded message ---------- >> From: Daniel Migault >> To: Ace Wg >> Cc: >> Bcc: >> Date: Tue, 21 Jul 2020 14:22:08 -0400 >> Subject: [Ace] IETF 108 tentative agenda and presentations >> Hi, >> >> Please find the tentative agenda [1] of ACE WG at the IETf 108 Wed July >> 29, 2020 11:00 UTC. >> >> Please upload your presentations by July 27 here: >> https://datatracker.ietf.org/meeting/108/session/ace >> >> Yours, >> Jim and Daniel >> >> [1] https://codimd.ietf.org/notes-ietf-108-ace >> >> >> -- >> Daniel Migault >> Ericsson >> _______________________________________________ >> 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 > -- Daniel Migault Ericsson --0000000000007b64e005ab0b3c30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mohit,

We apology for missing your r= equest and thank you for reiterating the request. We gave you a 15 min [1],= if that is not enough, please let us know.=C2=A0

= Yours,=C2=A0
Daniel


On Tue, Jul 21, 2020 at 3:58 PM Mohit Sahn= i <mohit06jan@gmail.com> = wrote:
Hi Daniel,
I had requested, in an earlier email, so= me time to discuss what changes are required in the ACE WG charter to=C2=A0= adopt my draft for "CMPv2/Lightweight CMP profile over CoAP transport&= quot; (https://tools.ietf.org/html/draft-msahni-ace= -cmpv2-coap-transport-00). Would it be possible for you to add it to th= e tentative agenda?

To give some background, this = draft is an extension of Light Weight CMP Profile (https://tools.ietf.org/html/draft-ietf-lamps-lightweight-cmp-profile-02<= /a>) draft currently under development in the LAMPS WG. We discussed the &q= uot;CMPv2 over CoAP" draft in the LAMPS WG and figured out that ACE WG= is a more appropriate place for this draft. However, Jim suggested that we= will need to modify the charter=C2=A0 of the ACE WG to adopt this draft.

Thanks
Mohit

On Tue, Jul 21, 2020 at 11:22= AM <ace-reque= st@ietf.org> wrote:
Send Ace mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ace@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/li= stinfo/ace
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ace-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ace-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ace digest..."
Today's Topics:

=C2=A0 =C2=A01. interim meeting planification (Daniel Migault)
=C2=A0 =C2=A02. ACE interim meeting tentative (Option2) (Daniel Migault) =C2=A0 =C2=A03. ACE tentative interim meeting (option 1) (Daniel Migault) =C2=A0 =C2=A04. IETF 108 tentative agenda and presentations (Daniel Migault= )



---------- Forwarded message ----------
From:=C2=A0Daniel Mi= gault <mglt.iet= f@gmail.com>
To:=C2=A0Ace Wg <ace@ietf.org>
Cc:=C2=A0
Bcc:=C2=A0
Date:= =C2=A0Tue, 21 Jul 2020 11:59:22 -0400
Subject:=C2=A0[Ace] interim meetin= g planification
Hi,

P= lease find a doodle [1] with two time slots for the interim meetings that a= re planned 1 per month the first week of the month 10 AM - 11 AM EST. The t= wo proposed days are Monday and Thursday. Please select your preferred=C2= =A0day by July 26.=C2=A0
=C2=A0
I am sending the calend= ar serie to the ace list so everyone can better see how it matches its cale= ndar.=C2=A0 =C2=A0

Yours,=C2=A0

Jim and Daniel

--
=
Daniel Migault
Ericsson



---------- Forwarded message ----------
From:=C2=A0Daniel Mi= gault <= daniel.migault@ericsson.com>
To:=C2=A0Ace Wg <ace@ietf.org>
Cc:=C2=A0
Bcc:= =C2=A0
Date:=C2=A0Tue, 21 Jul 2020 15:59:52 +0000
Subject:=C2=A0[Ace]= ACE interim meeting tentative (Option2)



---------- Forwarde= d message ----------
From:=C2=A0Daniel Migault <daniel.migault@ericsson.com= >
To:=C2=A0Ace Wg <ace@ietf.org>
Cc:=C2=A0
Bcc:=C2=A0
Date:=C2=A0Tue, 21 Ju= l 2020 16:00:38 +0000
Subject:=C2=A0[Ace] ACE tentative interim meeting = (option 1)




---------- Forwarded message ----------
From:=C2=A0Daniel Mi= gault <mglt.iet= f@gmail.com>
To:=C2=A0Ace Wg <ace@ietf.org>
Cc:=C2=A0
Bcc:=C2=A0
Date:= =C2=A0Tue, 21 Jul 2020 14:22:08 -0400
Subject:=C2=A0[Ace] IETF 108 tenta= tive agenda and presentations
Hi,=C2=A0

<= div>Please find the tentative agenda [1] of ACE WG at the IETf 108=C2=A0Wed= July 29, 2020 11:00 UTC.=C2=A0

Please upload=C2= =A0your presentations by July 27 here:

Yours,= =C2=A0
Jim and Daniel



=
--
Daniel Migault
Ericsson
_______________________________________________
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


--
Daniel Migault
Ericsson
--0000000000007b64e005ab0b3c30-- From nobody Wed Jul 22 10:42:28 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 02FE83A0895 for ; Wed, 22 Jul 2020 10:42:27 -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 SC1xsegbAkdm for ; Wed, 22 Jul 2020 10:42:25 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 DAE273A088A for ; Wed, 22 Jul 2020 10:42:24 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id p205so3437125iod.8 for ; Wed, 22 Jul 2020 10:42:24 -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=avYPXqC/yNtxeAgovzDZGx6QGddazfylNFK3pXngwgk=; b=nxCp4nVRCo8zkUzBmW7jViBJ8R9oKK9PicMSNs3WVFOPqFURChgQAFJfs8v7wCotKW UApQBJzpGTFqhKHw0IufJH0SZ58yQG0PvlZ5TXMMeQt3Q8yjcK8n91fgSOeWZUfnkBLV AZ+/7UV0PvbdsNsFVlKgGiyxvM4+DRF6QWJt4efJJdkZ5tY0AMGBB6AoeYi9wqfD+vmh yTPtUv8W5b5VmotmJ206kJrmVT+Jy9DRSy8nbCvNv8BpEF/G6L2lbDvt8BdQRewJYzCh vYmnV6Mb8rB0oJmZ54KS3O3YIByIsKpjBirjEjJ9B3cq4D9Z51KixjX4pJjTCXNmfga2 lB5g== 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=avYPXqC/yNtxeAgovzDZGx6QGddazfylNFK3pXngwgk=; b=YMgD1rRq8ZQ02ekbuNaq6dl9lffMjdyzd9RKlBHUXhhBwaRsWMp/JxKdHQedFqNyYn HvYLpfn7TGNBPOVcazGDzBtOMeFw0iu4cVLGGGNYCnxubt7uLRF3KGRQ2xbyNg6JvLsJ 9dDd+rO3NuGEISpfGGbzP23TQzLlnrrp8anNnhpljkVkKpV38/HD5UIe06Ggex5UEWW9 Vdyjf3Co//rZz0hiDkFfh/Tyh0Awsj7uqVPA+kCvVob77fAwajh6LLJxRSSmMpCYtzJB g9Ah/Oj3NR7ojjTEQpfXnVZR+ZbcRaLhDe88/w0ksC35cvx6C5bUPcha355OuVKplmuk 3TFQ== X-Gm-Message-State: AOAM530PJwECFT38jjumnd56lzgGjD4AgPVHW+LaNjAxd1AIGZu7a5EZ zqDXemhMHGXGrBhJhu448WcuA3V4FnYcK7FYdQ4= X-Google-Smtp-Source: ABdhPJybOz1TGfTxJerrevCRuERwy24M92rfsJWxuGgOyk1OSpI2zsEI33MTeo9w/Ueg7O9DN12jZOV6iKnJw0bqt2E= X-Received: by 2002:a6b:5c0a:: with SMTP id z10mr848465ioh.131.1595439744221; Wed, 22 Jul 2020 10:42:24 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mohit Sahni Date: Wed, 22 Jul 2020 10:42:13 -0700 Message-ID: To: Daniel Migault Cc: Ace Wg Content-Type: multipart/alternative; boundary="00000000000037087005ab0b43e7" Archived-At: Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) 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, 22 Jul 2020 17:42:27 -0000 --00000000000037087005ab0b43e7 Content-Type: text/plain; charset="UTF-8" Hi Daniel Thanks for adding this to the agenda. 15 Minutes should be good. Regards Mohit On Wed, Jul 22, 2020 at 10:40 AM Daniel Migault wrote: > Hi Mohit, > > We apology for missing your request and thank you for reiterating the > request. We gave you a 15 min [1], if that is not enough, please let us > know. > > Yours, > Daniel > > [1] https://codimd.ietf.org/notes-ietf-108-ace > > > On Tue, Jul 21, 2020 at 3:58 PM Mohit Sahni wrote: > >> Hi Daniel, >> I had requested, in an earlier email, some time to discuss what changes >> are required in the ACE WG charter to adopt my draft for "CMPv2/Lightweight >> CMP profile over CoAP transport" ( >> https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-transport-00). >> Would it be possible for you to add it to the tentative agenda? >> >> To give some background, this draft is an extension of Light Weight CMP >> Profile ( >> https://tools.ietf.org/html/draft-ietf-lamps-lightweight-cmp-profile-02) >> draft currently under development in the LAMPS WG. We discussed the "CMPv2 >> over CoAP" draft in the LAMPS WG and figured out that ACE WG is a more >> appropriate place for this draft. However, Jim suggested that we will need >> to modify the charter of the ACE WG to adopt this draft. >> >> Thanks >> Mohit >> >> On Tue, Jul 21, 2020 at 11:22 AM wrote: >> >>> Send Ace mailing list submissions to >>> ace@ietf.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://www.ietf.org/mailman/listinfo/ace >>> or, via email, send a message with subject or body 'help' to >>> ace-request@ietf.org >>> >>> You can reach the person managing the list at >>> ace-owner@ietf.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of Ace digest..." >>> Today's Topics: >>> >>> 1. interim meeting planification (Daniel Migault) >>> 2. ACE interim meeting tentative (Option2) (Daniel Migault) >>> 3. ACE tentative interim meeting (option 1) (Daniel Migault) >>> 4. IETF 108 tentative agenda and presentations (Daniel Migault) >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Daniel Migault >>> To: Ace Wg >>> Cc: >>> Bcc: >>> Date: Tue, 21 Jul 2020 11:59:22 -0400 >>> Subject: [Ace] interim meeting planification >>> Hi, >>> >>> Please find a doodle [1] with two time slots for the interim meetings >>> that are planned 1 per month the first week of the month 10 AM - 11 AM EST. >>> The two proposed days are Monday and Thursday. Please select your >>> preferred day by July 26. >>> >>> I am sending the calendar serie to the ace list so everyone can better >>> see how it matches its calendar. >>> >>> Yours, >>> >>> Jim and Daniel >>> >>> [1] https://doodle.com/poll/x2dghwiqmqei6cc8 >>> -- >>> Daniel Migault >>> Ericsson >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Daniel Migault >>> To: Ace Wg >>> Cc: >>> Bcc: >>> Date: Tue, 21 Jul 2020 15:59:52 +0000 >>> Subject: [Ace] ACE interim meeting tentative (Option2) >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Daniel Migault >>> To: Ace Wg >>> Cc: >>> Bcc: >>> Date: Tue, 21 Jul 2020 16:00:38 +0000 >>> Subject: [Ace] ACE tentative interim meeting (option 1) >>> >>> >>> >>> >>> ---------- Forwarded message ---------- >>> From: Daniel Migault >>> To: Ace Wg >>> Cc: >>> Bcc: >>> Date: Tue, 21 Jul 2020 14:22:08 -0400 >>> Subject: [Ace] IETF 108 tentative agenda and presentations >>> Hi, >>> >>> Please find the tentative agenda [1] of ACE WG at the IETf 108 Wed July >>> 29, 2020 11:00 UTC. >>> >>> Please upload your presentations by July 27 here: >>> https://datatracker.ietf.org/meeting/108/session/ace >>> >>> Yours, >>> Jim and Daniel >>> >>> [1] https://codimd.ietf.org/notes-ietf-108-ace >>> >>> >>> -- >>> Daniel Migault >>> Ericsson >>> _______________________________________________ >>> 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 >> > > > -- > Daniel Migault > Ericsson > --00000000000037087005ab0b43e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Daniel
Thanks for ad= ding this to the agenda. 15 Minutes should be good.=C2=A0

Regards=C2=A0
Mohi= t

On Wed, Jul 22, 2020 at 10:40 AM Daniel Migault <mglt.ietf@gmail.com> wrote:
Hi Mohit,

We apol= ogy for missing your request and thank you for reiterating the request. We = gave you a 15 min [1], if that is not enough, please let us know.=C2=A0

Yours,=C2=A0
Daniel

=

= On Tue, Jul 21, 2020 at 3:58 PM Mohit Sahni <mohit06jan@gmail.com> wrote:
Hi= Daniel,
I had requested, in an earlier email, some time to discu= ss what changes are required in the ACE WG charter to=C2=A0adopt my draft f= or "CMPv2/Lightweight CMP profile over CoAP transport" (https://tools.ietf.org/html/draft-msahni-ace-cmpv2-coap-tr= ansport-00). Would it be possible for you to add it to the tentative ag= enda?

To give some background, this draft is an ex= tension of Light Weight CMP Profile (https://too= ls.ietf.org/html/draft-ietf-lamps-lightweight-cmp-profile-02) draft cur= rently under development in the LAMPS WG. We discussed the "CMPv2 over= CoAP" draft in the LAMPS WG and figured out that ACE WG is a more app= ropriate place for this draft. However, Jim suggested that we will need to = modify the charter=C2=A0 of the ACE WG to adopt this draft.

<= /div>
Thanks
Mohit

On Tue, Jul 21, 2020 at 11:22 AM <ace-request@ietf.org> wrote:
Sen= d Ace mailing list submissions to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ace@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/li= stinfo/ace
or, via email, send a message with subject or body 'help' to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ace-request@ietf.org

You can reach the person managing the list at
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ace-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Ace digest..."
Today's Topics:

=C2=A0 =C2=A01. interim meeting planification (Daniel Migault)
=C2=A0 =C2=A02. ACE interim meeting tentative (Option2) (Daniel Migault) =C2=A0 =C2=A03. ACE tentative interim meeting (option 1) (Daniel Migault) =C2=A0 =C2=A04. IETF 108 tentative agenda and presentations (Daniel Migault= )



---------- Forwarded message ----------
From:=C2=A0Daniel Mi= gault <mglt.iet= f@gmail.com>
To:=C2=A0Ace Wg <ace@ietf.org>
Cc:=C2=A0
Bcc:=C2=A0
Date:= =C2=A0Tue, 21 Jul 2020 11:59:22 -0400
Subject:=C2=A0[Ace] interim meetin= g planification
Hi,

P= lease find a doodle [1] with two time slots for the interim meetings that a= re planned 1 per month the first week of the month 10 AM - 11 AM EST. The t= wo proposed days are Monday and Thursday. Please select your preferred=C2= =A0day by July 26.=C2=A0
=C2=A0
I am sending the calend= ar serie to the ace list so everyone can better see how it matches its cale= ndar.=C2=A0 =C2=A0

Yours,=C2=A0

Jim and Daniel

--
=
Daniel Migault
Ericsson



---------- Forwarded message ----------
From:=C2=A0Daniel Mi= gault <= daniel.migault@ericsson.com>
To:=C2=A0Ace Wg <ace@ietf.org>
Cc:=C2=A0
Bcc:= =C2=A0
Date:=C2=A0Tue, 21 Jul 2020 15:59:52 +0000
Subject:=C2=A0[Ace]= ACE interim meeting tentative (Option2)



---------- Forwarde= d message ----------
From:=C2=A0Daniel Migault <daniel.migault@ericsson.com= >
To:=C2=A0Ace Wg <ace@ietf.org>
Cc:=C2=A0
Bcc:=C2=A0
Date:=C2=A0Tue, 21 Ju= l 2020 16:00:38 +0000
Subject:=C2=A0[Ace] ACE tentative interim meeting = (option 1)




---------- Forwarded message ----------
From:=C2=A0Daniel Mi= gault <mglt.iet= f@gmail.com>
To:=C2=A0Ace Wg <ace@ietf.org>
Cc:=C2=A0
Bcc:=C2=A0
Date:= =C2=A0Tue, 21 Jul 2020 14:22:08 -0400
Subject:=C2=A0[Ace] IETF 108 tenta= tive agenda and presentations
Hi,=C2=A0

<= div>Please find the tentative agenda [1] of ACE WG at the IETf 108=C2=A0Wed= July 29, 2020 11:00 UTC.=C2=A0

Please upload=C2= =A0your presentations by July 27 here:

Yours,= =C2=A0
Jim and Daniel



=
--
Daniel Migault
Ericsson
_______________________________________________
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


--
Daniel Migault
Ericsson
--00000000000037087005ab0b43e7-- From nobody Thu Jul 23 04:59:21 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 6E5F13A09B8; Thu, 23 Jul 2020 04:59:20 -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 GwVQIBZEhogs; Thu, 23 Jul 2020 04:59:04 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50066.outbound.protection.outlook.com [40.107.5.66]) (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 187593A09AD; Thu, 23 Jul 2020 04:59:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iB2TFNaTvxlOXjVBL9P8dxvnanRtxXQ6r68leoo++LY+yVT4K/kaGgywgaK6Icju1h8N4qKQviRo3Ak01y18jdqhl9HPba4Ole+VtPNJAWecPFtsHDYRzAKFO9hQD0rK7L+dPqiF6NPYw9SK9zPg4Iv/igmVP5kLhiILWJ3V5YdDTKmapi0LwNCzjrGoocL6Cm/NfdoZJPQPAm5FE43FbGyA137EqWMwtfu4+AX0Kx+meglueCnLi3A3mHx8bIU+dju5EbtwBwaVMtz4VuskWawNN7t5XsmRbeMLtTO3Tk4brGlY4Xg+qbNJXaOjLejVJTnJNjAR/B7R48esIJb43Q== 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=zrS7OpmnwwsOp+WdAuHdY3iqTlYrFhdTzsJL2IoEJIc=; b=WwevTGT6uUkAO/ANDCCEM3FnWYwxwRrww81ueqmPNyodBhVwK5p9gnM8BqnVf5JqvK2F2NYsc4FBzPhO2cdnuu7eXkwPWS4G4mDoEZOgwF4rdcnOwN/XWkkYBeBZG51XqvfTiDS9N5WHRoGh1tI/T19pv6P7ECdDs1QPWq1ZkAtmDNCDNgZ9Wwk7QWcVG446g6vtU2p1ibK5LQUthVEAl7LBVHMTPrG+e0wg0dWtb9OcH7NYhxLTmTqic23ROMnEFLpv9JQyhwopS329NzbSqEC06pso2T2vwqZbuK0diwXjvvJIqQq9RXGLjdvd5xJOOEfrF6VH1WC6t1wSeVKUjA== 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=zrS7OpmnwwsOp+WdAuHdY3iqTlYrFhdTzsJL2IoEJIc=; b=LYu2mq24M5OrL7WKzlEzsiyXFhyX7djSFdsaqMgThl6Ytq3MMKfGSr/OD/goWYuOWw2u8ObRT9kTf4iFqn0evrIbt8ZfVvucbJUmR1kQFu4Ra20k0FaM8/I+3MFsGdEgBps/eH5AWI1CcF74cMi3yviBfRwS8kre+G9wVb57Z+Y= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR07MB3195.eurprd07.prod.outlook.com (2603:10a6:7:2f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.15; Thu, 23 Jul 2020 11:58:59 +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.3216.015; Thu, 23 Jul 2020 11:58:59 +0000 From: Francesca Palombini To: Jim Schaad , "draft-ietf-ace-key-groupcomm@ietf.org" CC: "Ace@ietf.org" Thread-Topic: Review of ietf-ace-key-groupcomm-07 Thread-Index: AdZHAmDAxxC2glJWS92Qm/d7WHm5HgTM6EcAAF+QlIABTRiDzA== Date: Thu, 23 Jul 2020 11:58:59 +0000 Message-ID: <6941B542-FF52-4479-A0B2-0B3D61382E58@ericsson.com> References: <023501d64b6e$83ea3b60$8bbeb220$@augustcellars.com> <8D4E3757-5AE5-4216-B13C-76F5916AD3D3@ericsson.com>, <004f01d65bb4$46c20690$d44613b0$@augustcellars.com> In-Reply-To: <004f01d65bb4$46c20690$d44613b0$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [90.232.168.192] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 198e055a-668e-4af5-091c-08d82effc911 x-ms-traffictypediagnostic: HE1PR07MB3195: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: nmzE7qOWDcnsVZLvWbu9RfHFBrIgYyFeOBdDxLKnNI1u7F5RlrieGIUlIYPQGYdyIfs46KRkjFHxRCCASzZKILITAF8CSOUYMo57MJRpB7pVcDvHi109YIeolLGBbwAa7l+kUBJ5bd9JekKYwrNQvH/X9ZOUFpE5Onq+cy/NgSAthOqDkp7AlCcnqDmIXDLXm7TbXzZBojZkki4JXHUsa69ZktQg0gQ0GFzZ2a/VOeNdGs4eYzoiZGbVI947CmiOSf8PUYR1Yu5kb2EwpYVgaENJpvI7Kn8CY9FlgKCtItwOjv/O+7M5wLOrW38Au81EKIZhmB4FBc6ZcLTeqHXAsUTWs7XkcPX34gugwnm2SiGcbwF1d0ZVn1Mp/doDHF482rDDqgAq1p9TGcjudPBrPg== 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)(366004)(39860400002)(376002)(136003)(346002)(36756003)(66556008)(2616005)(66446008)(966005)(5660300002)(478600001)(66946007)(66476007)(64756008)(6486002)(44832011)(76116006)(71200400001)(166002)(91956017)(26005)(6506007)(4326008)(6512007)(316002)(2906002)(33656002)(8936002)(8676002)(186003)(30864003)(83380400001)(110136005)(53546011)(86362001)(19627235002)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 9QK2LNEXqu6EHNL2hfJD2sN9yyRQmNEQQrLPbX/QTuzB1MqO/kbsomiy6f7EkzGtDjHiYTP3L76r10G/LTgeRpBsk4JY3ljHkQ+O7VHwvs58xIsVakOTbRabHdp5ysYgkaxOeu3poR8NIW3oXR68MDFuP35a+bkOV+jLVzRcarxwmxoT2UEixwCCc5WcB7TCxjoYbPTVZHZHTbsKCAxx/99l8u5jlW9XhoX9xgKMVbNomaL5tOU8+Hq3Zp7ypGPmeVgsxf159hg7ygFZkeCUv1NGdCYeMvpVgQUYqNksQOy1cHbmFwitiocyV5UcNvf4T/3ANqej+lrGXrv7o31KuIA1XpQulNrkh/ofWh7x/+nmqhnS8rPdTr157skxfF3ESZPsJXefUAPNdcAzeq+ABupQRDR3eKXbE/6P5A7uTRTpOi2h1/unQi9/1Z6I30aTG88c3bAoFnIMvOCpjjRFKnrEkVJz/KBaUl6zhxDcW+nS/QH2gW9T/WGGNxU/3SxP x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_6941B542FF524479A0B20B3D61382E58ericssoncom_" 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: 198e055a-668e-4af5-091c-08d82effc911 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2020 11:58:59.6141 (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: bm6a+8CEAOLydT5Bly1GHGogqQLCDXz8XUshgoqmbKB9KyAeBNqPWEnk8wY3z/3OroRRdvIOy1dEDRIHQkiIQufaIxQ1nSTEG4teD9AUO3F7FG4fggrJojhnFwhu//IJ X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3195 Archived-At: Subject: Re: [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: Thu, 23 Jul 2020 11:59:21 -0000 --_000_6941B542FF524479A0B20B3D61382E58ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmltLA0KDQpUaGFua3MgZm9yIHlvdXIgcmVwbHkhIENvbW1lbnRzIGlubGluZS4NCg0KRnJh bmNlc2NhDQoNCg0KDQoNCg0KT24gMTYgSnVseSAyMDIwIGF0IDIzOjAxOjQ3IENFU1QsIEppbSBT Y2hhYWQgPGlldGZAYXVndXN0Y2VsbGFycy5jb20+IHdyb3RlOg0KDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRnJhbmNlc2NhIFBhbG9tYmluaSA8ZnJhbmNlc2NhLnBh bG9tYmluaUBlcmljc3Nvbi5jb20+DQo+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTQsIDIwMjAgMjoy NSBQTQ0KPiBUbzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT47IGRyYWZ0LWll dGYtYWNlLWtleS0NCj4gZ3JvdXBjb21tQGlldGYub3JnDQo+IENjOiBhY2VAaWV0Zi5vcmcNCj4g U3ViamVjdDogUmU6IFJldmlldyBvZiBpZXRmLWFjZS1rZXktZ3JvdXBjb21tLTA3DQo+DQo+IEhp IEppbSwNCj4NCj4gVGhhbmsgeW91IHNvIG11Y2ggZm9yIGFub3RoZXIgZXh0ZW5zaXZlIHJldmll dyEgV2UgaGF2ZSBzdWJtaXR0ZWQgdi0wOCBvZg0KPiB0aGUgZHJhZnQgdG8gYW5zd2VyIGl0Lg0K PiBDb21tZW50cyBpbmxpbmUuIElmIHRoZXJlIGlzIGFueSBhbnN3ZXIvdXBkYXRlIHRoYXQgZG9l cyBub3Qgc2F0aXNmeSB5b3UsDQo+IGhvcGVmdWxseSB3ZSBjYW4gY29udGludWUgdGhlIGRpc2N1 c3Npb24gYnkgbWFpbCBhbmQgZmlndXJlIG91dCB0aGUgbWFqb3INCj4gcG9pbnRzIHRvIGRpc2N1 c3MgZHVyaW5nIElFVEYxMDguDQo+DQo+IFRoYW5rcywNCj4gRnJhbmNlc2NhIGFuZCBNYXJjbw0K Pg0KPiDvu79PbiAyNi8wNi8yMDIwLCAwNjowMiwgIkppbSBTY2hhYWQiIDxpZXRmQGF1Z3VzdGNl bGxhcnMuY29tPiB3cm90ZToNCj4NCj4NCj4gICAgICogU2VjdGlvbiAyIC0gdXBkYXRlIERUTFMg cmVmZXJlbmNlDQo+DQo+IEZQOiBUaGUgQWNlIHByb2ZpbGUgb2YgRFRMUyBpcyBkZWZpbmVkIHRv IHNldCB1cCBEVExTIDEuMiwgdGhlcmUgaXMgbm8gcHJvZmlsZQ0KPiBkZWZpbmVkIHRvIHNldCB1 cCBEVExTIDEuMywgc28gSSBkb27igJl0IHRoaW5rIHdlIHNob3VsZCB1cGRhdGUgdG8gMS4zIGhl cmUuDQoNCltKTFNdIEZpbmUgLSBidXQgYmUgcHJlcGFyZWQgZm9yIHB1c2hiYWNrIGZyb20gdGhl IElFU0cgb24gdGhpcy4NCg0KRlA6IEEgcG9zc2libGUgYWx0ZXJuYXRpdmUgaXMgdG8gcmVwaHJh c2UgdG8gbWVudGlvbiB0aGUgcHJvZmlsZXMgcmF0aGVyIHRoYW4gdGhlIHByb3RvY29scy4gRm9y IGV4YW1wbGU6DQoNCk9MRDoNCuKAnFBvc3NpYmxlIHdheXMgdG8gcHJvdmlkZSBhIHNlY3VyZSBj b21tdW5pY2F0aW9uIGFzc29jaWF0aW9uIGFyZSBEVExTIFtSRkM2MzQ3XSBhbmQgT1NDT1JFIFtS RkM4NjEzXS7igJ0NCg0KTkVXOg0K4oCcUG9zc2libGUgd2F5cyB0byBwcm92aWRlIGEgc2VjdXJl IGNvbW11bmljYXRpb24gYXNzb2NpYXRpb24gYXJlIGRlc2NyaWJlZCBpbiB0aGUgRFRMUyB0cmFu c3BvcnQgcHJvZmlsZSBbSS1ELmlldGYtYWNlLWR0bHMtYXV0aG9yaXplXSBhbmQgT1NDT1JFIHRy YW5zcG9ydCBwcm9maWxlIFtJLUQuaWV0Zi1hY2Utb3Njb3JlLXByb2ZpbGVdIG9mIEFDRS7igJ0N Cg0KV291bGQgdGhhdCBiZSBiZXR0ZXI/DQoNCj4NCj4gICAgICogU2VjdGlvbiAzIC0gVGhlIGNv bnRlbnQgZm9ybWF0IGFwcGxpY2F0aW9uL2FjZStjYm9yIGlzIG5vdCBkZWZpbmVkIGJ5IHRoZQ0K PiAgICAgdHJhbnNwb3J0IHByb2ZpbGVzIGJ1dCBieSB0aGUgZnJhbWV3b3JrLg0KPg0KPiBGUDog VGhlIHBvaW50IGlzIHRoYXQgdGhlIHByb2ZpbGVzIG1pZ2h0IGNoYW5nZSB0aGUgY29udGVudCBm b3JtYXQsIHNvIGV2ZW4gaWYNCj4gdGhpcyBzcGVjaWZpYyBvbmUgYWNlK2Nib3IgaXMgZGVmaW5l ZCBpbiBBY2UsIHByb2ZpbGVzIG1pZ2h0IGRlZmluZSBhbmQgdXNlIG90aGVyDQo+IG9uZXMuIFJl cGhyYXNlZCB0byBjbGFyaWZ5Lg0KDQpbSkxTXSBObywgdGhlIHByb2ZpbGUgY2FuIGRpY3RhdGUg dGhlIG1lZGlhIHR5cGUgYmV0d2VlbiBDIGFuZCBSUywgYnV0IGJldHdlZW4gQyBhbmQgQVMgaXMg c2V0IGJ5IHRoZSBmcmFtZXdvcmsuDQoNCkZQOiBBaCwgSSBzZWUgd2hhdCB5b3UgbWVhbi4gSSBj aGVja2VkIGFnYWluIGluIHRoZSBmcmFtZXdvcmssIGFuZCB0byBiZSBuaXRwaWNraW5nIGl0IGRv ZXMgc2F5cyDigJxQcm9maWxlcyB0aGF0IHVzZSBDQk9SIGVuY29kaW5nIG9mIHByb3RvY29sIG1l c3NhZ2UgcGFyYW1ldGVycyBhdCB0aGUNCm91dGVybW9zdCBlbmNvZGluZyBsYXllciBNVVNUIHVz ZSB0aGUgbWVkaWEgZm9ybWF0ICdhcHBsaWNhdGlvbi8NCmFjZStjYm9yJy4gU28gaW4gc29tZSBz ZW5zZSB0aGUgY29udGVudC1mb3JtYXQgZGVwZW5kcyBvbiBpZiB0aGUgcHJvZmlsZSB1c2VzIENC T1Igb3Igbm90LiBUaGF0IGRvZXMgbm90IGNoYW5nZSB0aGUgZmFjdCB0aGF0IHdlIG5lZWQgdG8g cmVwaHJhc2Ugb3VyIHRleHQgaGVyZSB0byBiZSBjb21wbGV0ZWx5IGNvcnJlY3QuDQoNCk9MRDoN ClRoZSBDb250ZW50LUZvcm1hdA0KdXNlZCBpbiB0aGUgbWVzc2FnZSBpcyB0aGUgb25lIGluZGlj YXRlZCBieSB0aGUgdXNlZCB0cmFuc3BvcnQNCnByb2ZpbGUgb2YgQUNFLiBGb3IgZXhhbXBsZSwg Li4uDQpORVc6DQpUaGUgQ29udGVudC1Gb3JtYXQNCnVzZWQgaW4gdGhlIG1lc3NhZ2UgZGVwZW5k cyBvbiB0aGUgdXNlZCB0cmFuc3BvcnQNCnByb2ZpbGUgb2YgQUNFLiBGb3IgZXhhbXBsZSwgLi4u DQoNCg0KPg0KPiAgICAgKiBTZWN0aW9uIDMuMSAtIEdpdmVuIHRoYXQgYSByb2xlIGlzIGRlZmlu ZWQgYXMgYSB0c3RyLCB0aGF0IGZvcm1hdCBpcyBub3QNCj4gICAgIHVzYWJsZSBpZiBvbmUgd2lz aGVzIHRvIGFzc2lnbiBhbiBpbnRlZ2VyIGFiYnJldmlhdGlvbiBwZXIgT1BUNy4NCj4NCj4gRlA6 IEkgdHJpZWQgdG8gcmVmb3JtdWxhdGUgaGVyZSB0aGF0IHRoZSBhaWYgaXMgdGhlIGRlZmF1bHQg ZW5jb2RpbmcsIGFuZCBzcGVjaWZ5DQo+IHRoYXQgdGhlIG90aGVyIGZvcm1hdCBkZWZpbmVkIGlz IGFuIGV4YW1wbGUuIEluIHRoZSBlbmQgaXQgaXMgdXAgdG8gdGhlDQo+IGFwcGxpY2F0aW9uIHBy b2ZpbGUgdG8gc3BlY2lmeSB0aGUgZm9ybWF0IG9mIHNjb3BlLg0KDQpTdXJlLCBidXQgd2h5IG5v dCBleHByZXNzIGZpZ3VyZSA0IGluIHRlcm1zIG9mIEFJRiByYXRoZXIgdGhhbiBhcyBzb21ldGhp bmcgdGhhdCBsb29rcyBsaWtlIGEgbmV3IHN0cnVjdHVyZT8NCg0KRlA6IFdlIGNhbiBkbyB0aGF0 LCB3ZSB3aWxsIHBvcnQgdGhlIGV4YW1wbGUgZnJvbSB0aGUgT1NDT1JFIGFwcGxpY2F0aW9uIHBy b2ZpbGUgKHRoZSBvbmUgaW4gc2VjdGlvbiAzIG9mIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWFjZS1rZXktZ3JvdXBjb21tLW9zY29yZS0wOCApLg0KDQoNCj4NCj4gICAg ICogU2VjdGlvbiAzLjEgLSBJcyB0aGVyZSBhIHJlYXNvbiB0aGF0IGEgZ2lkIGlzIGEgYnN0ciBh bmQgbm90IGEgdHN0ci4gIEkNCj4gICAgIGFzc3VtZSB0aGF0IHRoaXMgaXMgdGhlIHNhbWUgYXMg R1JPVVBOQU1FIHdoaWNoIG11Y2ggYmUgYSB0ZXh0IHN0cmluZyB0bw0KPiBiZQ0KPiAgICAgaW4g YSB1cmwtcGF0aC4NCj4NCj4gRlA6IFdlIGhhdmUgbW9kaWZpZWQgdGhhdCB0byBiZSB0c3RyIHRv IGJlIGNvbnNpc3RlbnQgd2l0aCBhY2Uga2V5IGdyb3VwY29tbQ0KPiBvc2NvcmUsIGJ1dCBwbGVh c2Ugbm90ZSB0aGlzIGlzIG9ubHkgYW4gZXhhbXBsZS4NCg0KW0pMU10gWWVzIEkga25vdyBpdCBp cyBhbiBleGFtcGxlLCBidXQgdGhlIGduYW1lIGNhbm5vdCBiZSBhbnl0aGluZyBvdGhlciB0aGFu IGEgdHN0ciB1bmxlc3MgeW91IGFyZSBnb2luZyB0byBjb21wbGV0ZWx5IGJyZWFrIHRoZSBjb25u ZWN0aW9uIGJldHdlZW4gdGhpcyB2YWx1ZSBhbmQgdGhlIG5hbWUgaW4gdGhlIFVSSS4NCg0KRlA6 IFRoaXMgaXMgYSBnb29kIHBvaW50LCB3ZSBtaWdodCB3YW50IHRvIHNwZWNpZnkgdGhhdCBpZiBp dOKAmXMgbm90IGEgdHN0ciB0aGVyZSBuZWVkcyB0byBiZSBzb21ldGhpbmcgaW4gcGxhY2UgdG8g bWFrZSB0aGUgdHJhbnNsYXRpb24gYmV0d2VlbiB0aGUgZ3JvdXAgbmFtZSBhbmQgR1JPVVBOQU1F IHVzZWQgaW4gdGhlIFVSSSAoZXg6IGJzdHIgZ2V0cyB0cmFuc2xhdGVkIGludG8gdHN0ciAweDAx MjMgYmVjb21lcyDigJwwMTIz4oCdKQ0KDQoNCj4gICAgICogU2VjdGlvbiAzLjIgLSB0aGUgZGVm IG9mIHNjb3BlIHNlZW1zIG9kZCBiZWNhdXNlIGl0IGlzIG5vdCB3ZWxsIGRlZmluZWQgaWYNCj4g ICAgIGl0IHdvdWxkIGJlIHRoZSBzYW1lIGFzIHRoZSByZXF1ZXN0ZWQgc2NvcGUuIChBUyByZXNw b25zZSkNCj4NCj4gRlA6ICBJIG5lZWQgbW9yZSBjbGFyaWZpY2F0aW9uczogSXMgaXQgdGhlIGZv bGxvd2luZyB0aGF0IGlzIHN0cmFuZ2Ug4oCcJ3Njb3BlJw0KPiBjb250YWluaW5nIHRoZSBncmFu dGVkIHNjb3BlLCBpZiBkaWZmZXJlbnQgZnJvbSB0aGUgc2NvcGUgcmVxdWVzdGVkIGJ5IHRoZQ0K PiBjbGllbnQuIOKAnCA/IE5vdGUgdGhhdCB0aGUgdGVybWlub2xvZ3kg4oCccmVxdWVzdGVkIGFu ZCBncmFudGVkIHNjb3Bl4oCdIGNvbWVzDQo+IGZyb20gT0F1dGg6IGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM2NzQ5I3NlY3Rpb24tMy4zLiBJIHJlbW92ZWQgdGhlDQo+IHNlY29uZCBw YXJ0IG9mIHRoZSBzZW50ZW5jZSBhcyBwZXIgY29tbWVudCBiZWxvdy4NCg0KW0pMU10gV2hhdCBz ZWVtcyBvZGQgaXMgdGhhdCBpZiBpdCBpcyBhYnNlbnQsIHRoZW4gaXQgaXMgbm90IGNsZWFyIHdo YXQgdGhlIGdyYW50cyBhcmUuICBJIGRvbid0IGtub3cgaWYgeW91IG5lZWQgdG8gc3BlY2lmeSB0 aGF0IHRoZSBncmFudCBpcyB0aGUgc2FtZSBhcyB0aGUgcmVxdWVzdCB3aGVuIGl0IGlzIG5vdCBw cmVzZW50LiAgT24gdGhlIG90aGVyIGhhbmQgdGhpcyBpcyBkdXBsaWNhdGluZyBpbmZvcm1hdGlv biBpbiB0aGUgZnJhbWV3b3JrIGRvY3VtZW50Lg0KDQpGUDogWWVzLCB0aGF0IHdhcyB0aGUgaWRl YSwgdGhhdCBpZiBpdOKAmXMgbm90IHByZXNlbnQgdGhlIGdyYW50ZWQgc2NvcGUgaXMgdGhlIHNh bWUgYXMgdGhlIHJlcXVlc3RlZCBvbmUuIEkgYW0gbm90IGFnYWluc3QgZHVwbGljYXRpbmcgaW5m b3JtYXRpb24gaWYgaXQgbWlnaHQgbWFrZSB0aGluZ3MgY2xlYXJlci4NCg0KPg0KPiAgICAgKiBT ZWN0aW9uIDMuMyAtIEFtIEkgc3VwcG9zZWQgdG8ga25vdyB3aHkgSSBjYXJlIGFib3V0IHB1Ymxp YyBrZXlzIGF0IHRoaXMNCj4gICAgIHBvaW50Pw0KPg0KPiBGUDogIEkgdGhvdWdodCB0aGlzIHNl bnRlbmNlIHdhcyBzdXBwb3NlZCB0byBjb3ZlciBpdCAoc2Vjb25kIHBhcmFncmFwaCBvZiAzLjMp Og0KPiDigJxPcHRpb25hbGx5LCB0aGUgQ2xpZW50IG1pZ2h0IHdhbnQgdG8gcmVxdWVzdCBuZWNl c3NhcnkgaW5mb3JtYXRpb24gY29uY2VybmluZw0KPiB0aGUgcHVibGljIGtleXMgaW4gdGhlIGdy b3VwLCBhcyB3ZWxsIGFzIGNvbmNlcm5pbmcgdGhlIGFsZ29yaXRobSBhbmQgcmVsYXRlZA0KPiBw YXJhbWV0ZXJzIGZvciBjb21wdXRpbmcgc2lnbmF0dXJlcyBpbiB0aGUgZ3JvdXAu4oCdIFdoYXTi gJlzIG1pc3Npbmc/DQoNCltKTFNdIFdlbGwgLSBsZXRzIHN0YXJ0IHdpdGggdGhlIHVzZSBvZiB0 aGUgc2luZ3VsYXIgZ3JvdXAgaW4gdGhlIHRleHQuICBUaGVyZSBhcmUgYSBudW1iZXIgb2YgcHJv YmxlbXMgaGVyZTogIDEuICBJdCB3b3VsZCBtYWtlIHNlbnNlIHRoYXQgdGhpcyByZWZlciB0byB0 aGUgcHVibGljIGtleSB1c2FnZSBmcm9tIGdyb3VwIGNvbW0gZG9jdW1lbnQuICAyLiBUaGUgdGVy bSAiaW5mb3JtYXRpb24gY29uY2VybmluZyB0aGUgcHVibGljIGtleXMgaW4gdGhlIGdyb3VwIiB0 byBtZSByZWFkcyAtIGdldCB0aGUgcHVibGljIGtleXMuICAzLiAgVGhlcmUgaXMgbm8gbW90aXZh dGlvbiBhYm91dCB3aHkgeW91IGFyZSBnZXR0aW5nIHRoaXMgZnJvbSB0aGUgdG9rZW4gcG9zdCBy YXRoZXIgdGhhbiBmcm9tIHRoZSBncm91cCBkZXNjcmlwdG9yLg0KDQpGUDogMS4gUmlnaHQsIHdl IGNhbiBhZGQgYSByZWZlcmVuY2UgdG8gaXQuIDIuIEkgc2VlLCBpbnN0ZWFkIGF0IHRoaXMgcG9p bnQgd2Ugd291bGQgbGlrZSB0byBnZXQgaW5mbyBhYm91dCBmb3IgZXhhbXBsZSBlbmNvZGluZywg bm90IHB1YmxpYyBrZXlzIHRoZW1zZWx2ZXMuIDMuIFJpZ2h0LCBzbyB3aGF0IHdlIG5lZWQgdG8g YWRkIGhlcmUgaXMgdGhhdCB0aGlzIGluZm9ybWF0aW9uIGlzIHNlbnQgYmVmb3JlIHRoZSBqb2lu aW5nIGV4Y2hhbmdlIHNvIHRoYXQgdGhlIGpvaW5pbmcgbm9kZSBjYW4gc2VuZCBpdHMgb3duIHB1 YmxpYyBrZXkgZGlyZWN0bHkgaW4gdGhlIGpvaW5pbmcgcmVxdWVzdCBhbmQgZG9lcyBub3QgbmVl ZCB0byBkbyBhIHNlcGFyYXRlIGV4Y2hhbmdlIGZvciB0aGF0Lg0KDQpPTEQ6DQpPcHRpb25hbGx5 LCB0aGUgQ2xpZW50IG1pZ2h0IHdhbnQgdG8gcmVxdWVzdCBpbmZvcm1hdGlvbiBjb25jZXJuaW5n DQp0aGUgcHVibGljIGtleXMgaW4gdGhlIGdyb3VwLCBhcyB3ZWxsIGFzIGNvbmNlcm5pbmcgdGhl IGFsZ29yaXRobSBhbmQNCnJlbGF0ZWQgcGFyYW1ldGVycyBmb3IgY29tcHV0aW5nIHNpZ25hdHVy ZXMgaW4gdGhlIGdyb3VwLiBJbiBzdWNoIGENCmNhc2UsIHRoZSBqb2luaW5nIG5vZGUgTUFZIGFz ayBmb3IgdGhhdCBpbmZvcm1hdGlvbiB0byB0aGUgS0RDIGluDQp0aGlzIHNhbWUgcmVxdWVzdC4g VG8gdGhpcyBlbmQsIGl0IHNlbmRzIHRoZSBDb0FQIFBPU1QgcmVxdWVzdCB0bw0KdGhlIC9hdXRo ei1pbmZvIGVuZHBvaW50IHVzaW5nIHRoZSBDb250ZW50LUZvcm1hdCAiYXBwbGljYXRpb24vDQph Y2UrY2JvciIuDQoNCk5FVzoNCk9wdGlvbmFsbHksIHRoZSBDbGllbnQgbWlnaHQgd2FudCB0byBy ZXF1ZXN0IGVuY29kaW5nIGluZm9ybWF0aW9uIGFib3V0DQp0aGUgcHVibGljIGtleXMgaW4gdGhl IGdyb3VwLCBhcyB3ZWxsIGFzIGFib3V0IHRoZSBhbGdvcml0aG0gYW5kDQpyZWxhdGVkIHBhcmFt ZXRlcnMgZm9yIGNvbXB1dGluZyBzaWduYXR1cmVzIGluIHRoZSBncm91cCwgaWYgdGhvc2UgYXJl IHVzZWQsIGFzIGZvciBleGFtcGxlIGluIFtJLUQuaWV0Zi1jb3JlLWdyb3VwY29tbS1iaXNdLiBJ biBzdWNoIGENCmNhc2UsIHRoZSBqb2luaW5nIG5vZGUgTUFZIGFzayBmb3IgdGhhdCBpbmZvcm1h dGlvbiB0byB0aGUgS0RDIGluDQp0aGlzIHNhbWUgcmVxdWVzdCwgc28gdG8gZ2V0IHRoZSBpbmZv cm1hdGlvbiBiZWZvcmUgdGhlIGpvaW5pbmcgZXhjaGFuZ2UgaXRzZWxmIChzZWUgU2VjdGlvbiA0 LjIpLiBUbyB0aGlzIGVuZCwgaXQgc2VuZHMgdGhlIENvQVAgUE9TVCByZXF1ZXN0IHRvDQp0aGUg L2F1dGh6LWluZm8gZW5kcG9pbnQgdXNpbmcgdGhlIENvbnRlbnQtRm9ybWF0ICJhcHBsaWNhdGlv bi8NCmFjZStjYm9yIi4NCg0KDQo+ICAgICAqIFNlY3Rpb24gMy4zIC0gYXJlIHlvdSBpbXBvc2lu ZyBhIG5ldyByZXF1aXJlbWVudCB0aGF0IHRoZSB0b2tlbiBiZQ0KPiAgICAgdmFsaWRhdGVkIHBy aW9yIHRvIHJldHVybmluZyB0aGUgcmVzcG9uc2UgdG8gYSB0b2tlbiBwb3N0PyAgQXMgSSByZW1l bWJlcg0KPiAgICAgaXQsIHRoaXMgaXMgbm90IHJlcXVpcmVkIHRvIGhhcHBlbiBwcmlvciB0byB0 aGUgcmVzcG9uc2UgYmVpbmcgcmV0dXJuZWQganVzdA0KPiAgICAgYmVmb3JlIGFjY2VzcyBpcyBn cmFudGVkLiAgKEkuZS4geW91IGNhbiB2YWxpZGF0ZSB0aGUgdG9rZW4gaW4gcGFyYWxsZWwpDQo+ ICAgICAoQWZ0ZXIgc3VjY2Vzc2Z1bCB2ZXJpZmljYXRpb24uLi4pDQo+DQo+IEZQOiBJdCBzZWVt cyB0byB1cyB0aGlzIGlzIGFscmVhZHkgZGVmaW5lZCBpbiB0aGUgZnJhbWV3b3JrOiBmcm9tDQo+ IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1vYXV0aC1hdXRoei0z NSNzZWN0aW9uLTUuOC4xDQo+IOKAnFdoZW4gYW4gUlMgcmVjZWl2ZXMgYW4gYWNjZXNzIHRva2Vu LCBpdCBNVVNUIHZlcmlmeSBpdCBiZWZvcmUgc3RvcmluZyBpdC7igJ0NCj4gQW5kIGxhdGVyDQo+ IOKAnElmIHRva2VuIG9yIGNsYWltIHZlcmlmaWNhdGlvbiBmYWlscywgdGhlIFJTIE1VU1QgZGlz Y2FyZCB0aGUgdG9rZW4gYW5kLCBpZiB0aGlzDQo+IHdhcyBhbiBpbnRlcmFjdGlvbiB3aXRoIGF1 dGh6LWluZm8sIHJldHVybiBhbiBlcnJvciBtZXNzYWdlIHdpdGggYSByZXNwb25zZQ0KPiBjb2Rl IGVxdWl2YWxlbnQgdG8gdGhlIENvQVAgY29kZSA0LjAxIChVbmF1dGhvcml6ZWQpLuKAnQ0KDQpb SkxTXSBUaGF0IHRleHQgZG9lcyBub3Qgc2F5IHRoYXQgb25lIGNhbm5vdCBkbyB0aGUgZm9sbG93 aW5nOiAgMSkgR2V0IHRoZSB0b2tlbiBmcm9tIHRoZSBQT1NULCAgMikgaW1tZWRpYXRlbHkgcmV0 dXJuIGEgc3VjY2VzcyBpbmRpY2F0b3IsIDMpIGRvIHRoZSB2YWxpZGF0aW9uIG9mIHRoZSB0b2tl biwgaW5jbHVkaW5nIGludHJvc3BlY3Rpb24gaWYgbmVjZXNzYXJ5LCA0KSBLZWVwIG9yIGRpc2Nh cmQgdGhlIHRva2VuIGRlcGVuZGluZyBvbiB0aGUgb3V0Y29tZSBvZiB0aGUgdmFsaWRhdGlvbiBw cm9jZXNzLg0KDQpJIHdhcyB3b3JraW5nIHRvIGdldCB0aGlzIGluIGJlY2F1c2UgSSBkaWQgbm90 IHdhbnQgdG8gaGF2ZSBubyByZXNwb25zZSBnbyBiYWNrIHRvIHRoZSBjbGllbnQgd2hpbGUgd2Fp dGluZyBmb3IgdGhlIHRva2VuIHRvIGJlIHZhbGlkYXRlZCBpbiB0aGUgZXZlbnQgb2YgbmVlZGlu ZyB0byBkbyBpbnRyb3NwZWN0aW9uLiAgVGhlcmUgaXMgbm90aGluZyByZWFsbHkgYmFkIGhhcHBl bmluZyBpZiBJIHJldHVybiBhIE9TQ09SRSBub25jZSBpbiB0aGUgZXZlbnQgdGhhdCB5b3Ugc2Vu ZCBtZSBhIERUTFMgdG9rZW4gYmVjYXVzZSB5b3Ugd291bGQganVzdCBpZ25vcmUgdGhhdCBhcyBu b3QgYmVpbmcgdXNlZnVsLiAgSG93ZXZlciwgaWYgSSBoYXZlIHRvIGhhdmUgdGhlIGVudGlyZSBj b250ZW50IG9mIHRoZSB0b2tlbiBiZWZvcmUgSSBjYW4gcmVzcG9uZCB0aGVuIGludHJvc3BlY3Rp b24gaXMgZ29pbmcgdG8gYmUgaGFyZGVyIHRvIGRlYWwgd2l0aC4NCg0KRlA6IEkgc2VlLCBJIHBl cnNvbmFsbHkgZG8gbm90IHRoaW5rIHRoZSBwcm9jZWR1cmUgeW91IGRlc2NyaWJlIGlzIHZhbGlk IGZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIGZyYW1ld29yaywgaW4gcGFydGljdWxhciwg U2VjdGlvbiA1LjguMSBzYXlzOg0KDQpUaGUgUlMNCnJlY2VpdmluZyB0aGUgdG9rZW4gTVVTVCB2 ZXJpZnkgdGhlIHZhbGlkaXR5IG9mIHRoZSB0b2tlbi4gSWYgdGhlDQp0b2tlbiBpcyB2YWxpZCwg dGhlIFJTIE1VU1QgcmVzcG9uZCB0byB0aGUgUE9TVCByZXF1ZXN0IHdpdGggMi4wMQ0KKENyZWF0 ZWQpLiBTZWN0aW9uIFNlY3Rpb24gNS44LjEuMSBvdXRsaW5lcyBob3cgYW4gUlMgTVVTVCBwcm9j ZWVkDQp0byB2ZXJpZnkgdGhlIHZhbGlkaXR5IG9mIGFuIGFjY2VzcyB0b2tlbi4NCg0KQWx0aG91 Z2ggaXQgZG9lcyBub3Qgc2F5IHRoYXQgaXQgTVVTVCBOT1QgcmVzcG9uZCB3aXRoIDIuMDEgdW5s ZXNzIHRoZSB0b2tlbiBpcyB2YWxpZCwgSSBkbyBpbnRlcnByZXQgdGhlIHByZXZpb3VzIHBhcmFn cmFwaCB0aGF0IHdheS4gSSB3b3VsZCB0aGluayB0aGF0IDIuMDEgbWVhbnMg4oCcdGhlIHRva2Vu IGhhcyBiZWVuIHZlcmlmaWVkIGFuZCBwYXNzZWQgdmVyaWZpY2F0aW9u4oCdIHJhdGhlciB0aGFu IOKAnEkgcmVjZWl2ZWQgdGhlIHRva2Vu4oCdLiBUaGlzIGZvbGxvd2luZyBwYXJhZ3JhcGggKGZy b20gdGhlIGZyYW1ld29yaykgc2hvdWxkIGNvdmVyIHRoZSBjYXNlIHlvdSBhcmUgdGFsa2luZyBh Ym91dDoNCg0KVGhlIFJTIE1BWSBtYWtlIGFuIGludHJvc3BlY3Rpb24gcmVxdWVzdCB0byB2YWxp ZGF0ZSB0aGUgdG9rZW4gYmVmb3JlDQpyZXNwb25kaW5nIHRvIHRoZSBQT1NUIHJlcXVlc3QgdG8g dGhlIGF1dGh6LWluZm8gZW5kcG9pbnQsIGUuZy4gaWYNCnRoZSB0b2tlbiBpcyBhbiBvcGFxdWUg cmVmZXJlbmNlLiBTb21lIHRyYW5zcG9ydCBwcm90b2NvbHMgbWF5DQpwcm92aWRlIGEgd2F5IHRv IGluZGljYXRlIHRoYXQgdGhlIFJTIGlzIGJ1c3kgYW5kIHRoZSBjbGllbnQgc2hvdWxkDQpyZXRy eSBhZnRlciBhbiBpbnRlcnZhbDsgdGhpcyB0eXBlIG9mIHN0YXR1cyB1cGRhdGUgd291bGQgYmUN CmFwcHJvcHJpYXRlIHdoaWxlIHRoZSBSUyBpcyB3YWl0aW5nIGZvciBhbiBpbnRyb3NwZWN0aW9u IHJlc3BvbnNlLg0KDQpJIHN0aWxsIGludGVycHJldCB0aGlzIGFzIOKAnG9ubHkgcmVzcG9uZCB3 aXRoIHN1Y2Nlc3Mgd2hlbiB0aGUgdG9rZW4gaXMgdmFsaWRhdGVk4oCdLiBJIGRvbuKAmXQga25v dyB3aGF0IHdheSB0byBpbmRpY2F0ZSB0aGF0IHRoZSBSUyBpcyBidXN5IGNvdWxkIGJlIHVzZWQg aW4gQ29BUC4NCg0KQWxzbywgaW4gY2FzZSB0aGUgcHJvY2VkdXJlIHlvdSBkZXNjcmliZSB3b3Vs ZCBiZSBhbGxvd2VkLCBzYXkgdGhlIHRva2VuIGRvZXMgbm90IHZlcmlmeSBhbmQgdGhlIFJTIHdh bnRzIHRvIHNlbmQgYW4gZXJyb3IgcmVzcG9uc2UsIHRoYXQgd291bGQgYmUgbG9zdCBhdCB0aGUg Q2xpZW50IHdoaWNoIGhhcyBhbHJlYWR5IHJlY2VpdmVkIGEgMi4wMS4NCg0KQW55d2F5LCBJIGRv IHRoaW5rIHRoaXMgaXMgYSB2YWxpZCBkaXNjdXNzaW9uIGZvciB0aGUgZnJhbWV3b3JrIGFuZCBJ IGRvIG5vdCB3YW50IG91ciBkcmFmdCB0byBhZGQgYW55IHJlcXVpcmVtZW50cyB0byB3aGF0IHRo ZSBmcmFtZXdvcmsgZGVmaW5lcy4gSSB0aGluayB3ZSBjb3VsZCByZXBocmFzZSB0aGUgZm9sbG93 aW5nIHRvIHJlbW92ZSBhbnkgaW1wbGljaXQgY29uc2VxdWVuY2U6DQoNCk9MRDoNCkFmdGVyIHN1 Y2Nlc3NmdWwgdmVyaWZpY2F0aW9uLCB0aGUgQ2xpZW50IGlzIGF1dGhvcml6ZWQgdG8gcmVjZWl2 ZQ0KdGhlIGdyb3VwIGtleWluZyBtYXRlcmlhbCBmcm9tIHRoZSBLREMgYW5kIGpvaW4gdGhlIGdy b3VwLiBJbg0KcGFydGljdWxhciwgdGhlIEtEQyByZXBsaWVzIHRvIHRoZSBDbGllbnQgd2l0aCBh IDIuMDEgKENyZWF0ZWQpDQpyZXNwb25zZSwgdXNpbmcgQ29udGVudC1Gb3JtYXQgImFwcGxpY2F0 aW9uL2FjZStjYm9yIiBkZWZpbmVkIGluDQpTZWN0aW9uIDguMTQgb2YgW0ktRC5pZXRmLWFjZS1v YXV0aC1hdXRoel0uDQpORVc6DQpBZnRlciBzdWNjZXNzZnVsIHZlcmlmaWNhdGlvbiwgdGhlIENs aWVudCBpcyBhdXRob3JpemVkIHRvIHJlY2VpdmUNCnRoZSBncm91cCBrZXlpbmcgbWF0ZXJpYWwg ZnJvbSB0aGUgS0RDIGFuZCBqb2luIHRoZSBncm91cC4NCg0KVGhlIEtEQyByZXBsaWVzIHRvIHRo ZSBDbGllbnQgd2l0aCBhIDIuMDEgKENyZWF0ZWQpDQpyZXNwb25zZSwgdXNpbmcgQ29udGVudC1G b3JtYXQgImFwcGxpY2F0aW9uL2FjZStjYm9yIiBkZWZpbmVkIGluDQpTZWN0aW9uIDguMTQgb2Yg W0ktRC5pZXRmLWFjZS1vYXV0aC1hdXRoel0uDQoNCg0KPiAgICAgKiBTZWN0aW9uIDMuMyAtIFlv dSB3b3VsZCBub3QgYmUgYWJsZSB0byByZXVzZSB0aGUgc2FtZSBrZGNjaGFsbGVuZ2UgdmFsdWUN Cj4gICAgIHdpdGggYSBkaWZmZXJlbnQga2V5LiAgSXQgd291bGQgbm90IGhhdmUgYW55IHdheSBv ZiBiZWluZyBhc3NvY2lhdGVkIHdpdGgNCj4gICAgIHRoYXQga2V5IGFuZCB3b3VsZCBsb29rIGxp a2Ugc29tZWJvZHkgZWxzZSB3YXMgYXR0ZW1wdGluZyB0byB1c2UgdGhlIHZhbHVlLg0KPg0KPiBG UDogTm90IHN1cmUgd2UgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbSBoZXJlLiBEb2VzIOKAnGRpZmZl cmVudCBrZXnigJ0gcmVmZXIgdG8gYQ0KPiBmb2xsb3dpbmcgbmV3IHB1YmxpYyBrZXkgdGhhdCB0 aGUgY2xpZW50IHdhbnRzIHRvIHVwbG9hZD8gVGhlcmUgaXMgaW4gZmFjdCBubw0KPiBhc3NvY2lh dGlvbiBiZXR3ZWVuIOKAmGtkY2NoYWxsZW5nZeKAmSBhbmQgdGhlIHB1YmxpYyBrZXkgaXRzZWxm LCBub3QgZXZlbiB3aXRoIHRoZQ0KPiBmaXJzdCBvbmUgdGhhdCB0aGUgY2xpZW50IHByb3ZpZGVz IGF0IGl0cyBmaXJzdCBqb2luaW5nIChhbmQgaXQgaXMgYWxzbyB1bmtub3duIHRvIHRoZQ0KPiBL REMgYXQgdGhlIHRpbWUgd2hlbiDigJhrZGNjaGFsbGVuZ2XigJkgaXMgaXNzdWVkKS4gSXTigJlz IGltcG9ydGFudCB0aGUNCj4g4oCYa2RjY2hhbGxlbmdl4oCZIGlzIGFzc29jaWF0ZWQgdG8gdGhh dCBleGFjdCBjbGllbnQsIG1lYW5pbmcgdG8gdGhhdCBleGFjdCBUb2tlbg0KPiBhbmQgUG9QIGtl eS4NCg0KW0pMU10gTGV0J3Mgc3RhcnQgd2l0aCB3aGljaCAiZGlmZmVyZW50IGtleSIgeW91IGFy ZSByZWZlcnJpbmcgdG8uICBJcyB0aGlzIGEgZGlmZmVyZW50IHNpZ25pbmcga2V5IG9yIGEgZGlm ZmVyZW50IFBPUCBrZXk/ICBEZXBlbmRpbmcgb24gaG93IHlvdSByZWFkIHRoaXMgaXMgY29tcGxl dGVseSBjaGFuZ2VzIHRoZSBtZWFuaW5nIG9mIHdoYXQgeW91IGFyZSBzYXlpbmcgdG8gZG8gaW4g dGhpcyBwYXJhZ3JhcGguICBBIGRpZmZlcmVudCBQT1Aga2V5ICh0b2tlbikgd2lsbCBub3QgYmUg dXNpbmcgdGhlIHNhbWUga2RjY2hhbGxlbmdlIGFzIGEgZGlmZmVyZW50IFBPUCBrZXkuICBZb3Ug bWlnaHQgYmUgYWJsZSB0byB1c2UgaXQgZm9yIGEgZGlmZmVyZW50IHNpZ25pbmcga2V5IGZvciBh IHNlY29uZCBncm91cCBpbiB0aGUgc2FtZSB0b2tlbi4gIEJ1dCB0aGF0IGlzIG5vdCBob3cgSSBy ZWFkIGl0Lg0KDQpGUDogUmlnaHQsIHdlIGRpZCBtZWFuIGEgZGlmZmVyZW50IHNpZ25pbmcga2V5 LiBXZSB3aWxsIGNsYXJpZnkgdGhhdC4NCg0KDQo+ICAgICAqIFNlY3Rpb24gMy4zIC0gbGFzdCBw YXJhZ3JhcGggLSBzaG91bGQgdGhpcyBiZSByZWZlcnJpbmcgdG8gYXBwbGljYXRpb25zIG9yDQo+ ICAgICBwcm9maWxlcz8gIC0tIHJlYWxseSBhIGdsb2JhbCBxdWVzdGlvbi4gIENvbnNpZGVyIC0g aXMgdGhlIE9TQ09SRSBwcm9maWxlDQo+ICAgICBhdHRhY2hlZCB0byBhIHNwZWNpZmljIGFwcGxp Y2F0aW9uIG9yIHRvIGEgc2V0IG9mIHVua25vd24gYXBwbGljYXRpb25zPw0KPg0KPiBGUDogSGVy ZSB3ZSBtZWFudCBhcHBsaWNhdGlvbiBwcm9maWxlcyBvZiB0aGlzIGRvYyBzdWNoIGFzIOKAnGFj ZS1rZXktDQo+IGdyb3VwY29tbS1vc2NvcmXigJ0uIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSBz ZWNvbmQgcGFydCBvZiBoaXMgY29tbWVudCwgY291bGQNCj4geW91IGV4cGxhaW4/DQoNCltKTFNd ICBNeSBwcm9ibGVtIGlzIHRoYXQgYXBwbGljYXRpb24gaXMgYSByZWFsbHkgb3ZlcmxvYWRlZCB0 ZXJtLiAgSnVzdCB0aGluayBvZiB0aHJlZSBkaWZmZXJlbnQgbGlnaHRpbmcgYXBwbGljYXRpb25z OiAgVGhlYXRlciBMaWdodGluZywgQnVpbGRpbmcgTGlnaHRpbmcgYW5kIEVtZXJnZW5jeSBMaWdo dGluZy4gIFRoZXNlIGFyZSB0aHJlZSBkaWZmZXJlbnQgYXBwbGljYXRpb25zIHRoYXQgYXJlIGFs bCBnb2luZyB0byB1c2UgYW4gT1NDT1JFIGdyb3VwIGtleWluZyBwcm90b2NvbCBhcyBwYXJ0IG9m IHRoZWlyIGltcGxlbWVudGF0aW9uLiAgTm93IHlvdSBhcmUgc2F5aW5nIHRoYXQgdGhlIHByb2Zp bGUgaXMgYW4gYXBwbGljYXRpb24uICBJIGFtIGdldHRpbmcgcmVhbGx5IGNvbmZ1c2VkIGFib3V0 IHdoYXQgaXMgYW4gYXBwbGljYXRpb24gYW5kIHdoYXQgaXNuJ3QuDQoNCkZQOiBZb3UgYXJlIHJp Z2h0LCB3ZSBzaG91bGQgaGF2ZSB1c2VkIHRoZSB0ZXJtIOKAnGFwcGxpY2F0aW9uIHByb2ZpbGVz 4oCdLCBjb25zaXN0ZW50bHkgd2l0aCB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQgYW5kIHVzaW5n IHRoZSB0ZXJtIGRlZmluZWQgaW4gdGhlIHRlcm1pbm9sb2d5LCB0byBhdm9pZCBjb25mdXNpb25z LiBXZSBkaWQgbWVhbiDigJxhcHBsaWNhdGlvbiBwcm9maWxlc+KAnSwgYW5kIG5vdCBhcHBsaWNh dGlvbnMuDQoNCg0KPiAgICAgKiBTZWN0aW9uIDQgLSBhcmUgd2Ugc3RpbGwgc3BlY2lmeWluZyBh IGdyb3VwIHRvIGpvaW4gb3IgaXMgdGhhdCBpbXBsaWNpdCBpbg0KPiAgICAgdGhlIFVSTD8gIFRl bGwgbWUgaG93IGl0IGlzIHNwZWNpZmllZD8NCj4NCj4gRlA6IEl04oCZcyBzcGVjaWZpZWQgaW4g dGhlIOKAmHNjb3Bl4oCZIG9mIHRoZSBKb2luaW5nIFJlcXVlc3QsIGFzIHRoZSBncm91cCBuYW1l IGluIHRoZQ0KPiBzaW5nbGUgc2NvcGVfZW50cnkgZm9yIHRoYXQgSm9pbmluZyBSZXF1ZXN0LiBJ IHRoaW5rIGl04oCZcyBnb29kIG5vdCB0byBtYW5kYXRlDQo+IHRoYXQgdGhlIFVSSSByZWZsZWN0 cyB0aGUgZ3JvdXAgbmFtZSBpbiB0aGUgcGF0aCAodGhvdWdoIGl0IG1ha2VzIHNlbnNlIGFuZCB3 ZQ0KPiBkbyBpdCBpbiB0aGUgZXhhbXBsZXMpLg0KDQpbSkxTXSBJIGRvbid0IGFncmVlLg0KDQpG UDogVGhpcyBjb21tZW50IGlzIHJlbGF0ZWQgdG8gdGhlIG9uZSBhYm92ZSB3aGVyZSB5b3Ugc2F5 IGdyb3VwIG5hbWUgc2hvdWxkIGJlIGEgdHN0ciB0byBtYXAgdG8gdGhlIFVSSS4gSSB0aG91Z2h0 IHRoZSBmbGV4aWJpbGl0eSB3b3VsZCBiZSBnb29kIGFuZCB3b3VsZCBub3QgYWRkIG11Y2ggdG8g dGhlIGNvbXBsZXhpdHkgb2YgaW1wbGVtZW50YXRpb25zLiBJIG1pZ2h0IGJyaW5nIHRoaXMgdXAg aW4gdGhlIFdHLCBtYXliZSB5b3UgY291bGQgZXhwYW5kIG9uIHdoeSB0aGF0IGZsZXhpYmlsaXR5 IHdvdWxkIGJlIGEgYmFkIGlkZWE/DQoNCg0KPg0KPiAgICAgKiBTZWN0aW9uIDQgLSBJIGRvbid0 IHRoaW5rIHRoYXQgdGhlIChyZS0pIGlzIGhlbHBpbmcgdW5kZXJzdGFuZGluZyBoZXJlLg0KPg0K PiBGUDogIFRoZSBwb2ludCB3ZSB3ZXJlIHRyeWluZyB0byBtYWtlIGNsZWFyIHdpdGggdGhhdCAo cmUtKSBpcyB0aGF0IGl0IGNhbiBiZSB1c2VkDQo+IHRvIHJldHJpZXZlIHRob3NlIHNldmVyYWwg Zm9sbG93aW5nIHRpbWVzLCBub3Qgb25seSBvbmNlLiBCdXQgSSBkb27igJl0IGtub3cgaG93IHRv DQo+IGV4cHJlc3MgdGhhdCBjbGVhcmx5LCBhbmQgc2luY2UgdGhhdCBkb2VzIG5vdCBoZWxwIHVu ZGVyc3RhbmRpbmcgd2UgaGF2ZQ0KPiByZW1vdmVkIHRoZW0uDQoNCltKTFNdIFN0aWxsIGFuZCBp bnN0YW5jZSBpbiBzZWN0aW9uIDEuMQ0KDQpGUDogV2lsbCByZW1vdmUgaXQuDQoNCg0KPg0KPiAg ICAgKiBTZWN0aW9uICA0IC0gd2hhdCB0eXBlIG9mIGluZGl2aWR1YWwga2V5IGlzIGJlaW5nIG9i dGFpbmVkIGluIGJ1bGxldCAyIC0NCj4gICAgIGhvdyBpcyB0aGlzIGRpZmZlcmVudCB0aGFuIGdl dHRpbmcgdGhlIGN1cnJlbnQga2V5aW5nIG1hdGVyaWFsPw0KPg0KPiBGUDogVGhlIGluZGl2aWR1 YWwga2V5IGlzIHRoZSBlcXVpdmFsZW50IG9mIHRoZSBTZW5kZXIgS2V5IGluIE9TQ09SRSAob3Ig aW5wdXQNCj4gbWF0ZXJpYWwgdG8gZGVyaXZlIGl0LCBpLmUuIHRoZSBTZW5kZXIgSUQpLCB2cyB0 aGUgZ3JvdXAga2V5aW5nIG1hdGVyaWFsIHN1Y2ggYXMNCj4gdGhlIG1hc3RlciBzZWNyZXQsIG1h c3RlciBzYWx0LCBjb250ZXh0IGlkLiBUaGUgZGlmZmVyZW5jZSBpcyB0aGF0IHVzaW5nIGJ1bGxl dCAyDQo+IG9ubHkgdGhlIHBlcnNvbmFsIG5vZGXigJlzIGtleWluZyBtYXRlcmlhbCBpcyB1cGRh dGVkLCBub3QgdGhlIGdyb3VwIGtleWluZw0KPiBtYXRlcmlhbC4gV2XigJlkIHdlbGNvbWUgcHJv cG9zYWxzIG9uIGhvdyB0byBjbGFyaWZ5IGl0IHdpdGhvdXQgZ29pbmcgaW50bw0KPiBPU0NPUkUg ZGV0YWlscy4NCg0KW0pMU10gSXMgdGhpcyB0cnlpbmcgdG8gc2F5IHRoYXQgYSBuZXcgY2xpZW50 SWQgY2FuIGJlIGlzc3VlZCBhcyBvcHBvc2UgdG8gdGhlIGN1cnJlbnQgc2V0IG9mIG1hdGVyaWFs PyAgIEkgd291bGQgdGhpbmsgdGhhdCB5b3UgYWx3YXlzIGdldCBtYXRlcmlhbCB0byBkZXJpdmUg aXQgYW5kIG5ldmVyIGRpcmVjdGx5IGdldCBhIGtleS4NCg0KRlA6IGZvciBPU0NPUkUgeWVzLCBi dXQgd2UgZG9u4oCZdCBrbm93IHRoYXQgdGhpcyBpbmRpdmlkdWFsIGtleSB3b3VsZCBhbHdheXMg YmUgZGVyaXZlZCBmcm9tIGFuIGlkZW50aWZpZXIgc3VjaCBhcyB0aGUgY2xpZW50SWQsIGhlbmNl IHRoZSDigJxuZXcgaW5wdXQgbWF0ZXJpYWwgdG8gZGVyaXZlIGl04oCdIHRlcm1pbm9sb2d5IChy YXRoZXIgdGhhbiBDbGllbnQgSWRldGlmaWVyKS4gV2UgY2FuIGNoYW5nZSB0aGUgYnVsbGV0IGFz IGZvbGxvd3M6DQpPTEQNCiogVGhlIENsaWVudCBjYW4gcmV0cmlldmUgYSBuZXcgaW5kaXZpZHVh bCBrZXksIG9yIG5ldyBpbnB1dA0KbWF0ZXJpYWwgdG8gZGVyaXZlIGl0LiBUaGlzIGlzIGRlc2Ny aWJlZCBpbiBTZWN0aW9uIDQuNC4NCk5FVw0KKiBUaGUgQ2xpZW50IGNhbiByZXRyaWV2ZSBuZXcg aW5wdXQNCm1hdGVyaWFsIHRvIGRlcml2ZSBhIG5ldyBpbmRpdmlkdWFsIGtleS4gVGhpcyBpcyBk ZXNjcmliZWQgaW4gU2VjdGlvbiA0LjQuDQoNCkJ1dCBzdGlsbCBkb27igJl0IHNlZSBob3cgdG8g Y2xhcmlmeSB3aGF0IGFuIOKAnGluZGl2aWR1YWwga2V54oCdIGlzIHdpdGhvdXQgZ29pbmcgaW50 byBkZXRhaWxzIHRoYXQgZG9u4oCZdCBiZWxvbmcgaGVyZS4NCg0KDQo+DQo+ICAgICAqIFNlY3Rp b24gNC4xIC0gVGhlIGJ1bGxldCBmb3IgL2FjZS1ncm91cCBzZWVtcyB0byBpbmRpY2F0ZSB0aGF0 IHRoZSBuYW1lIGlzDQo+ICAgICBmaXhlZCB3aGljaCBpcyB0aGUgb3Bwb3NpdGUgb2Ygd2hhdCB0 aGUgcHJldmlvdXMgcGFyYWdyYXBoIHNheXMuICBJIGZpbmQNCj4gICAgIHRoaXMgY29uZnVzaW5n LiAgSSByZWFsbHkgZmluZCBpdCBjb25mdXNpbmcgdGhhdCB0aGlzIGRvY3VtZW50IGlzIHNwZWNp ZnlpbmcNCj4gICAgIGEgdXJsLXBhdGggbmFtZSBpcyBiZWluZyBzcGVjaWZpZWQsIGFuZCB0aGUg b3Njb3JlIGRvY3VtZW50IGltbWVkaWF0ZWx5DQo+IHVzZXMNCj4gICAgIGEgZGlmZmVyZW50IHZh bHVlLg0KPg0KPiBGUDogIFRoZSBwYXJ0IGFib3V0IOKAnGZpeGVk4oCdIHdhcyBtZWFudCB0byBz YXkgdGhhdCBvbmNlIGRlZmluZWQgaXQgd2lsbCBub3QNCj4gY2hhbmdlLCB3aGF0ZXZlciB0aGUg YXBwbGljYXRpb24gcHJvZmlsZXMgZGVmaW5lIHRvIHVzZSwgZWl0aGVyIHRoZSBkZWZhdWx0IG9y DQo+IG90aGVyLCBvcHBvc2VkIHRvIHRoZSAvYWNlLWdyb3VwL0dST1VQTkFNRSBmb3IgZXhhbXBs ZSwgd2hpY2ggaGF2ZSBhDQo+IHZhcmlhYmxlIHBhcnQuIFNpbmNlIHRoYXQgd2FzIG5vdCBjbGVh ciwgYW5kIG5vdCB0byBtYWtlIGl0IGluY29uc2lzdGVudCwgd2UgaGF2ZQ0KPiByZW1vdmVkIHRo ZSB0ZXJtIGZpeGVkLg0KPiBBYm91dCBPU0NPUkUgdXNpbmcgYSBkaWZmZXJlbnQgcmVzb3VyY2Ug bmFtZTogc2hvdWxkIHdlIHRoZW4gc3BlY2lmeSBhcyBhDQo+IHJlcXVpcmVtZW50IHRoYXQgdGhl IHByb2ZpbGVzIE1VU1Qgc2V0IHRoZSByb290IHVyaS1wYXRoLCByYXRoZXIgdGhhbiBwcm92aWRp bmcNCj4gYSBkZWZhdWx0Pw0KDQpbSkxTXSBUaGF0IHdvdWxkIG1ha2UgbW9yZSBzZW5zZSB0byBt ZS4gIEkgYW0gbm90IHN1cmUgd2h5IHlvdSBjYXJlIGFib3V0IGdldHRpbmcgYSBuZXcgcm9vdCBo b3dldmVyIGFzIGEgc2luZ2xlIHJvb3QgY291bGQsIGluIHRoZW9yeSBzdXBwb3J0IG11bHRpcGxl IEtEQyBwcm9maWxlcy4NCg0KRlA6IFNheSB5b3UgaGF2ZSBib3RoIGFjZSBrZXkgZ3JvdXBjb21t IE9TQ09SRSBhbmQgcHVic3ViIGFwcGxpY2F0aW9uIHByb2ZpbGVzIGltcGxlbWVudGVkIG9uIHRo ZSBzYW1lIEtEQy4gRWl0aGVyIHRoZSBLREMga25vd3Mgd2hhdCB0byByZXR1cm4gYmFzZWQgb24g dGhlIFVSaSByb290ICjigJxncm91cC1vc2NvcmXigJ0gdnMgc29tZXRoaW5nIGxpa2Ug4oCccHVi c3Vi4oCdKSwgb3IgaXQgbmVlZHMgdG8gaGF2ZSB0aGUgaW5mb3JtYXRpb24gYWJvdXQgd2hhdCBw cm9maWxlIGl0IGlzIHRvZ2V0aGVyIHdpdGggdGhlIGdyb3VwIGtleWluZyBtYXRlcmlhbC4gUmln aHQgbm93IG91ciBkb2N1bWVudCBkb2VzIHRoZSBmaXJzdCBhbmQgbm90IHRoZSBzZWNvbmQuIEFy ZSB5b3Ugc2F5aW5nIHlvdSB3b3VsZCBsaWtlIHVzIHRvIGNoYW5nZSB0aGF0PyBPciBhbGxvdyBi b3RoPyBUaGlzIGlzIGFsc28gc29tZXRoaW5nIEkgd291bGQgYnJpbmcgdG8gdGhlIFdHIHRvIGRp c2N1c3MuDQoNCg0KPg0KPiAgICAgKiBTZWN0aW9uIDQuMSAtIHdoYXQgZG9lcyBpdCBtZWFuIGZv ciBhIHN1Yi1yZXNvdXJjZSB0byBiZSAiZml4ZWQiLiAgRG9lcw0KPiAgICAgdGhhdCBtZWFuIGl0 IG5ldmVyIGNoYW5nZXM/DQo+DQo+IEZQOiBTZWUgcHJldmlvdXMgYW5zd2VyLiBZZXMgaXQgbWVh bnMgdGhhdCBvbmNlIGRlZmluZWQgaXQgZG9lcyBub3QgY2hhbmdlDQo+IGRlcGVuZGluZyBvbiBv dGhlciBwYXJhbWV0ZXJzIChzdWNoIGFzIEdST1VQTkFNRSBvciBOT0RFTkFNRSkuIFdlDQo+IGhh dmUgcmVtb3ZlZCBpdCBub3cgYXMgaXQgd2FzIG5vdCBjbGVhci4NCg0KW0pMU10gVGhlIHRlcm0g bm9ybWFsbHkgdXNlZCBpcyAiaW52YXJpYW50IG9uY2UgZXN0YWJsaXNoZWQiIGZvciB0aGF0IHR5 cGUgb2YgbWVhbmluZy4gIEZpeGVkIHdvdWxkIHNlZW0gdG8gaW1wbHkgdGhhdCBpdCBpcyBmaXhl ZCBwcmlvciB0byB0aGF0Lg0KDQpGUDogVGhhbmtzISBXaWxsIGNoYW5nZS4NCg0KPg0KPiAgICAg KiBTZWN0aW9uIDQuMSAtIFllcyBidXQgd2hhdCBpcyBhIE5PREVOQU1FIGFuZCB3aHkgZG8gSSBj YXJlIGFib3V0IGl0Pw0KPg0KPiBGUDogSG9wZWZ1bGx5IGFkZGluZyB0aGUgZm9sbG93aW5nIOKA nEVhY2ggcmVzb3VyY2UgY29udGFpbnMgdGhlIGluZGl2aWR1YWwNCj4ga2V5aW5nIG1hdGVyaWFs IGZvciB0aGF0IG5vZGUuIOKAnCBnaXZlcyBhbiBpbnR1aXRpb24gd2h5IHRoZSBOT0RFTkFNRSBp cyB1c2VkLg0KPiBUaGUgZmFjdCB0aGF0IGl0IGlzIGEgbm9kZSBpZGVudGlmaWVyIHNob3VsZCBi ZSBjbGVhciBieSB0aGUgZm9sbG93aW5nIHNlbnRlbmNlOiDigJwNCj4gVGhlc2UgcmVzb3VyY2Vz IGFyZSBpZGVudGlmaWVkIGJ5IHRoZSBub2RlIG5hbWUgKGluIHRoaXMgZXhhbXBsZSwgdGhlIG5v ZGUNCj4gbmFtZSBoYXMgdmFsdWUgIk5PREVOQU1FIinigJ0gTW9yZSBkZXRhaWxzIGFib3V0IGhv dyBwcmVjaXNlbHkgTk9ERU5BTUUNCj4gaXMgdXNlZCB0byB2ZXJpZnkgdGhlIHJlcXVlc3QgYXJl IGdpdmVuIGluIDQuMS4yLjEsIGJ1dCB3ZSBvbmx5IHdhbnQgdG8gdGFsayBhYm91dA0KPiBpdCBo aWdoIGxldmVsIGhlcmUuDQoNCltKTFNdIFRoaXMgaXMgdGhlIGZpcnN0IHRpbWUgdGhhdCBJIGhh dmUgc2VlbiB0aGUgdGVybSBpbiB0aGUgZG9jdW1lbnQuICBVc2luZyBpdCB3aXRob3V0IGFueSB0 eXBlIG9mIGRlZmluaXRpb24gaXMgbm90IHZlcnkgdXNlZnVsLiAgRXZlbiBkZWZpbmluZyBpdCBp biB0aGUgdGVybWlub2xvZ3kgc2VjdGlvbiB3b3VsZCBiZSBoZWxwZnVsLg0KDQpGUDogT2ssIHdl IHdpbGwgYWRkIGl0IHRvIHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uLg0KDQo+DQo+ICAgICAqIFNl Y3Rpb24gNC4xLjIuMSAtIEl0IHdvdWxkIGJlIHVzZWZ1bCBpbiB0aGUgZmlyc3QgcGFyYWdyYXBo IHRvIHJlLWl0ZXJhdGUNCj4gICAgIHRoYXQgdGhpcyBpcyB0aGUgImpvaW4iIG9wZXJhdGlvbiAg VGhlIGN1cnJlbnQgZGVzY3JpcHRpb24gc2VlbXMgdG8gYmUNCj4gICAgIHJlYWxseSBvZGQuDQo+ DQo+IEZQOiBPaywgSSBhZGRlZCBhIG5vdGUgYWJvdXQgdGhhdC4gVGhlIGlkZWEgd2FzIHRoYXQg dGhpcyBzZWN0aW9uIGlzIHJlYWxseSBhYm91dA0KPiB0aGUgaGFuZGxlciwgYW5kIHRoZSBqb2lu aW5nIGlzIGRlc2NyaWJlZCB1c2luZyB0aGlzIGhhbmRsZXIgbGF0ZXIgb24sIGluIHNlY3Rpb24N Cj4gNC4yLg0KDQpbSkxTXSBZZXMgdGhhdCBpcyB0aGUgc29ydCBvZiB0aGluZyBJIHdhcyBsb29r aW5nIGZvci4gIEdldHRpbmcgYSBjb3JyZXNwb25kZW5jZSBiZXR3ZWVuIHRoZSByZXNvdXJjZXMg YW5kIHRoZSBvcGVyYXRpb25zIGlzIGFsd2F5cyBoZWxwZnVsLg0KDQpGUDogT2ssIHRoYW5rcyBm b3IgY29uZmlybWluZy4NCg0KDQo+DQo+ICAgICAqIFNlY3Rpb24gNC4xLjIuMSAtIGdldF9wdWJf a2V5cyAtIE9uZSBjb25zaWRlcmF0aW9uIHRoYXQgbmVlZHMgdG8gYmUNCj4gICAgIGhpZ2hsaWdo dGVkIGZvciBhIGNvbnN0cmFpbmVkIGRldmljZSBpcyB0aGF0IHRoaXMgbWF5IHJlc3VsdCBpbiBh IGxhcmdlDQo+ICAgICByZXR1cm4gdmFsdWUgYW5kIGl0IG1heSBiZSBiZXR0ZXIgdG8gZ2V0IHRo ZW0gb25seSBhcyBuZWVkZWQuDQo+DQo+IEZQOiBPaywgYWRkZWQgdGhlIGZvbGxvd2luZyBzZW50 ZW5jZTog4oCcTm90ZSB0aGF0IGluY2x1ZGluZyB0aGlzIHBhcmFtZXRlciBtYXkNCj4gcmVzdWx0 IGluIGEgbGFyZ2UgbWVzc2FnZSBzaXplIGZvciB0aGUgZm9sbG93aW5nIHJlc3BvbnNlLCB3aGlj aCBjYW4gYmUNCj4gaW5jb252ZW5pZW50IGZvciByZXNvdXJjZS1jb25zdHJhaW5lZCBkZXZpY2Vz LuKAnSBBbnl0aGluZyBtb3JlIHdlIG5lZWQgdG8NCj4gYWRkPw0KDQpbSkxTXSBJIGRvbid0IHRo aW5rIHNvLiAgVGhlIGRldGFpbHMgb24gYmxvY2t3aXNlIGFuZCBFVGFnIHNob3VsZCBiZSBjbGVh ciBhbHJlYWR5Lg0KDQpGUDogR29vZCwgdGhhbmtzLg0KDQo+DQo+ICAgICAqIFNlY3Rpb24gNC4x LjIuMSAtICdjb25jZScgd2h5IGJvdGhlciBwb2ludGluZyB0byBBQ0UgZm9yIGEgZGVzY3JpcHRp b24gb2YNCj4gICAgIHRoaXMgZG9jdW1lbnQuICBUaGlzIGlzIG5vdCBhIGZyYW1ld29yayBtZXNz YWdlIHNvIEkgYW0gbm90IHN1cmUgd2h5IHRoaXMgaXMNCj4gICAgIGludGVyZXN0aW5nLg0KPg0K PiBGUDogV2UgZG8gdGhhdCB0byBwb2ludCB0aGUgcmVhZGVyIG9uIHdoZXJlIHRvIGZpbmQgdGhl IGVuY29kaW5nICh3aGljaCBpcyB0aGUNCj4gc2FtZSBhcyBpbiBBY2UpLg0KDQpbSkxTXSBPayAt IHRoYXQgc2VlbXMgYSBiaXQgb2RkIGJlY2F1c2UgdGhpcyBpcyBub3QgdGhlIHNhbWUgbWVkaWEt dHlwZS4NCg0KRlA6IFRoYXTigJlzIHJpZ2h0LiBXZSBjb3VsZCBqdXN0IHJlcGVhdCB0aGUgZW5j b2RpbmcsIGJ1dCB3ZSB0aG91Z2h0IGl0IHdhcyBnb29kIHRvIG1ha2UgdGhlIHBhcmFsbGVsLg0K DQoNCj4NCj4gICAgICogU2VjdGlvbiA0LjEuMi4xIC0gV2hpY2ggc2NvcGUgaXMgYmVpbmcgdXNl ZCwgdGhlIG9uZSBpbiB0aGlzIG1lc3NhZ2UNCj4gICAgIChhc3N1bWluZyBpdCBleGlzdHMpIG9y IHRoZSBvbmUgaW4gdGhlIHRva2VuPyAgSWYgdGhlIG1lc3NhZ2UgZG9lcyBub3QgaGF2ZQ0KPiAg ICAgb25lIHRoZW4gd2hhdCBoYXBwZW5zPyAgRGV0ZXJtaW5pc3RpYyBlbmNvZGluZz8NCj4NCj4g RlA6IEJ5IOKAnHVzZWTigJ0gSSBhc3N1bWUgeW91IG1lYW4gYnkgdGhlIEtEQz8gVGhlIEtEQyBl eHRyYWN0IHRoZSBncmFudGVkDQo+IHNjb3BlIGZyb20gdGhlIFRva2VuLCBhbmQgY2hlY2tzIHRo aXMgcmVxdWVzdGVkIG9uZSBhZ2FpbnN0IHRoZSB0b2tlbiBvbmUuIElmDQo+IHRoaXMgam9pbiBt ZXNzYWdlIGRvZXMgbm90IGhhdmUgb25lIHdlIGFyZSBpbiB0aGUgY2FzZSB3aGVyZSB0aGUgS0RD DQo+IHVuZGVyc3RhbmRzIHdoaWNoIGdyb3VwIGFuZCByb2xlIHRoZSBDbGllbnQgaXMgcmVxdWVz dGluZyAoc2F5IHRoZXJlIGlzIG9ubHkgb25lDQo+IHRoYXQgdGhlIGNsaWVudCBoYXMgYmVlbiBn cmFudGVkKS4gV2hhdCBhcmUgd2UgbWlzc2luZz8NCg0KW0pMU10gVGhhdCBleHBsYW5hdGlvbg0K DQpGUDogWW91IGFyZSByaWdodCwgdGhhdCBpcyBtaXNzaW5nLiBXZSB3aWxsIGNsYXJpZnkuDQoN Cg0KPiAgICAgKiBTZWN0aW9uIDQuMS4yLjEgLSBib3RoIGJ1bGxldHMgYXJlIHRhbGtpbmcgYWJv dXQgZmFpbGVkIHZlcmlmaWNhdGlvbiAtDQo+ICAgICBraWxsIHRoZSByZWR1bmRhbmN5Lg0KPg0K PiBGUDogWWVzLCBidXQgdGhlIGVycm9yIHByb2Nlc3NpbmcgaXMgZGlmZmVyZW50IGluIHRoZSAy IGJ1bGxldHM6IGluIGNhc2UgdGhlDQo+IHZlcmlmaWNhdGlvbiBmYWlscyBiZWNhdXNlIGNsaWVu dF9jcmVkX3ZlcmlmeSBmYWlscywgd2Ugc3BlY2lmeSB3aGF0IHRoZSBoYW5kbGVyDQo+IG5lZWRz IHRvIGRvIHdpdGggcmVnYXJkIHRvIHRoZSBrZGNjaGFsbGVuZ2UuIFNvIGl0IGlzIG5vdCByZWFs bHkgcmVkdW5kYW50LiBXZQ0KPiBoYXZlbuKAmXQgbWFkZSBhbnkgY2hhbmdlcywgYnV0IHBsZWFz ZSBsZXQgdXMga25vdyBpZiB5b3UgaGF2ZSBpZGVhcyBvbiBob3cgdG8NCj4gaW1wcm92ZS4NCg0K W0pMU10gQnV0IEkgZG9uJ3Qgc2VlIGFueSByZWFzb24gd2h5IEkgY291bGQgbm90IHJldHVybiBh IHBheWxvYWQgdy8gYSBuZXcga2RjY2hhbGxlbmdlIGluIHRoZSBmaXJzdCBjYXNlIGFzIHdlbGwu DQoNCkZQOiBPaywgYWx0aG91Z2ggaXQgaXMgbm90IG5lY2Vzc2FyaWx5IG5lZWRlZCwgaWYgdGhl IHNpbXBsaWZpY2F0aW9uIGhlbHBzLCB3ZSBjYW4gbWFrZSB0aGUgY2hhbmdlLg0KDQoNCj4NCj4g ICAgICogU2VjdGlvbiA0LjEuMi4xIC0gJ251bScgdGhlIHJ1bGUgb24gdGhlIGluaXRpYWwgdmFs dWUgb2YgbnVtIHNob3VsZCBiZSBwdXQNCj4gICAgIGludG8gYSBzZWN0aW9uIGFib3V0IHNldHRp bmcgdXAgYSBncm91cCBub3QgaGVyZS4NCj4NCj4gRlA6IE9rLCB3ZSBoYXZlIGFkZGVkIGEgcmVx dWlyZW1lbnQgdGhhdCBpdCBpcyB1cCB0byB0aGUgYXBwbGljYXRpb24gcHJvZmlsZSB0bw0KPiBz cGVjaWZ5IHdoYXQgdGhlIGluaXRpYWwgdmFsdWUgc2hvdWxkIGJlLiBGb3IgT1NDT1JFLCB0aGlz IGNhbiBiZSBkZWZpbmVkIGluDQo+IGRyYWZ0LXRpbG9jYS1hY2Utb3Njb3JlLWdtLWFkbWluIGFu ZCByZWZlcmVuY2VkIGluIHRoZSBwcm9maWxlLg0KW0pMU10gRG8geW91IHdhbnQgYSBub3JtYXRp dmUgcmVmZXJlbmNlIHRvIHRoZSBhZG1pbiBkb2N1bWVudD8NCg0KRlA6IE5vLCBJIHRoaW5rIHdl IGRvbuKAmXQgbmVlZCBpdC4gV2UgZ2l2ZSBpdCBhcyBhbiBleGFtcGxlLg0KDQoNCj4gICAgICog U2VjdGlvbiA0LjEuMi4xIC0gZXhwX2RlbHRhIHNob3VsZCBzcGVjaWZ5IGEgZGVmYXVsdCBpZiBp dCBpcyBub3QgaW4gdGhlDQo+ICAgICBtZXNzYWdlLiAgSSB0aGVyZSBhIHJlYXNvbiB0aGF0IHRo aXMgaXMgbm90IGEgcG9saWN5IGZvciB0aGUgZ3JvdXA/DQo+DQo+IEZQOiBPaywgd2UgaGF2ZSBt b3ZlZCB0aGlzIHRvIHRoZSBwb2xpY2llcy4gSXQgaXMgd29ydGggbm90aW5nIHRob3VnaCB0aGF0 IHRoZQ0KPiBncm91cF9wb2xpY2llcyBwYXJhbWV0ZXIgaXMgb3B0aW9uYWwgKG1lYW5pbmcgdGhl IEtEQyBtaWdodCBub3Qgc2VuZCB0aGlzIGluZm8NCj4gaW4gdGhlIG1lc3NhZ2UpLCB3ZSBoYXZl IGV4cGxpY2l0bHkgYWRkZWQgdGhhdCB0aGUgZGVmYXVsdCB2YWx1ZXMgTVVTVCBiZQ0KPiBzcGVj aWZpZWQgYnkgdGhlIGFwcGxpY2F0aW9uIHByb2ZpbGVzLg0KDQpbSkxTXSBZZXMsIGJ1dCB5b3Ug d291bGQgdXNlIGFuIGV4cF9kZWx0YSBvZiAwIGlmIHlvdSBkaWQgbm90IHJldHJpZXZlIGl0IGZy b20gdGhlIHBvbGljeS4NCg0KRlA6IE5vLCB5b3Ugd291bGQgdXNlIHdoYXRldmVyIGRlZmF1bHQg dGhlIGFwcGxpY2F0aW9uIHByb2ZpbGVzIHNwZWNpZmllcy4gSXQgaXMgUkVRVUlSRUQgb2YgYXBw bGljYXRpb24gcHJvZmlsZXMgdG8gc3BlY2lmeSB3aGF0IGlzIHRoZSBkZWZhdWx0IHZhbHVlIG9m IGl04oCZcyBub3Qgc2VudC4NCg0KPiAgICAgKiBTZWN0aW9uIDQuMS4yLjIgLSBJIGRvbid0IHVu ZGVyc3RhbmQgdGhlIG5lZWQgZm9yICdna3R5JyBhcyB0aGF0IEkgc2hvdWxkDQo+ICAgICBrbm93 IGZyb20gdGhlIGpvaW4gYW5kIGl0IHNob3VsZCBuZXZlciBjaGFuZ2UgaW4gdGhlIGxpZmUgb2Yg dGhlIGdyb3VwLiAgSQ0KPiAgICAgd291bGQgYWxzbyBleHBlY3QgdGhhdCAnZXhwJyBpcyBzb21l dGhpbmcgdGhhdCBhdCBsZWFzdCBTSE9VTEQgYmUgaW5jbHVkZWQNCj4gICAgIGFzIHRoYXQgZG9l cyBjaGFuZ2UgYW5kIGlzIHVzZWZ1bCB0byBoYXZlLg0KPg0KPiBGUDogT2sgZm9yIGV4cCwgd2Ug Y2hhbmdlZCBpdCB0byBTSE9VTEQuIEFib3V0IGdrdHkgaW4gdGhlIEdFVCByZXNwb25zZSwgaXQN Cj4gYWxsb3dzIGEgbm9kZSBhY3RpbmcgYXMg4oCcbW9uaXRvcuKAnSB0byBvbmx5IHJlcXVlc3Qg dGhlIGdyb3VwIGtleSBhbmQgZ2V0IGFsbCB0aGUNCj4gaW5mb3JtYXRpb24gaXQgbmVlZHMgd2l0 aG91dCBuZWVkaW5nIHRvIGRvIHRoZSBmdWxsIFBPU1QsIGVzcGVjaWFsbHkgaWYgdGhlIEtEQw0K PiBtYWludGFpbnMgdGhlIHB1YiBrZXlzIGFuZCB3b3VsZCBmYWlsIGl0cyByZXF1ZXN0IGlmIGl0 IGRvZXMgbm90IGNvbnRhaW4gYSBwdWINCj4ga2V5LiBXZSBjb3VsZCBtYWtlIGdrdHkgb3B0aW9u YWwgaW4gdGhlIHJlc3BvbnNlIHRvIEdFVCwgYnV0IEkgdGhpbmsgdGhhdCB3b3VsZA0KPiBqdXN0 IGJlIG1vcmUgY29tcGxpY2F0ZWQgKHdoZW4gZG9lcyB0aGUgS0RDIHNlbmRzIGl0PyBXaGVuIG5v dD8pIEkgZG9u4oCZdA0KPiB0aGluayB0aGUgc2F2aW5nIDIgYnl0ZXMgaXMgbW90aXZhdGlvbiBl bm91Z2ggZm9yIHJlbW92aW5nIGl0LCBnaXZlbiB0aGF0IHdlDQo+IGhhdmUgYSByZWFzb24gZm9y IGhhdmluZyBpdC4NCg0KW0pMU10gSSB0aGluayB0aGF0IGlzIHByb2JhYmx5IHJlYXNvbmFibGUu DQoNCkZQOiBPaywgc28gd2Ugd29u4oCZdCBkbyBhbnkgY2hhbmdlIGhlcmUuDQoNCj4gICAgICog U2VjdGlvbiA0LjEuMy4xIC0gVGhlIHRleHQgb24gdGhlIGZpcnN0IHNlbGVjdGlvbiBjcml0ZXJp YSBoYXMgbWUgcmVhbGx5DQo+ICAgICBtZXNzZWQgdXAgYmVjYXVzZSBJIGFtIG5vdCBzdXJlIHRo YXQNCj4NCj4gRlA6IEJyb2tlbiBjb21tZW50LiBCdXQgd2UgaGF2ZSBhc3N1bWVkIHRoaXMgd2Fz IGFib3V0IHRoZSBwYXJlbnRoZXNpcw0KPiAoaW5jbHVkaW5nIHRoZSBleGFjdCBjb21iaW5hdGlv biBvZiByb2xlcyByZXF1ZXN0ZWQpIGFuZCBoYXZlIHRyaWVkIHRvIHJlcGhyYXNlDQo+IHRvIGNs YXJpZnkuDQoNCkkgYW0gbm90IHN1cmUgd2hhdCB0aGUgbWF0Y2hpbmcgcnVsZXMgYXJlIHN1cHBv c2VkIHRvIGJlIGZvciByb2xlIGlkZW50aWZpZXJzLiAgIEl0IGxvb2tzIGxpa2UgdGhpcyBtaWdo dCBoYXZlIGJlZW4gY2xhcmlmaWVkDQoNCkZQOiBHb29kLg0KDQoNCj4gICAgICogU2VjdGlvbiA0 LjEuNi4xIC0gSSBoYXZlIG5vIGlkZWEgZnJvbSB0aGUgdGV4dCB3aHkgSSB3b3VsZCB1c2UgdGhp cw0KPiAgICAgbWV0aG9kLg0KPg0KPiBGUDogSXTigJlzIGRpZmZpY3VsdCB0byBnaXZlIGEgY2xl YXJlciBpZGVhIGF2b2lkaW5nIHByb2ZpbGUtc3BlY2lmaWMgZGV0YWlscy4gV291bGQgaXQNCj4g aGVscCB0byBoYXZlIGFuIGluZm9ybWF0aW9uYWwgcmVmZXJlbmNlIHRvIGtleSBncm91cGNvbW0g b3Njb3JlIHRvIGdpdmUgYW4NCj4gZXhhbXBsZT8gKEnigJlkIHJhdGhlciBhdm9pZCB0aGUgY2ly Y3VsYXIgZGVwZW5kZW5jeSwgc28gaWYgeW91IGhhdmUgb3RoZXIgaWRlYXMNCj4gb24gaG93IHRv IGltcHJvdmUsIEnigJlsbCB0YWtlIHRoZW0pLg0KDQpbSkxTXSBUaGlzIGhhbmRsZXIgaXMgdXNl ZCBieSBhIG5vZGUgZWl0aGVyIHRvIDEpIGdldCBhIG5ldyBpZGVudGlmaWVyIHdpdGhpbiB0aGUg Y3VycmVudCBncm91cCBvciAyKSBmb3JjZSBhIHJla2V5aW5nIG9mIHRoZSBncm91cC4gIFRoaXMg aXMgbm9ybWFsbHkgZG9uZSBkdWUgdG8gdXNhZ2UgbGltaXRzIG9uIHRoZSBBRUFEIGFsZ29yaXRo bS4NCg0KRlA6IFRoYW5rcyBmb3IgdGhlIHN1Z2dlc3Rpb24hIEFzIG1lbnRpb25lZCBhYm92ZSB0 aG91Z2ggSSB3b3VsZCBub3QgdGFsayBhYm91dCBpZGVudGlmaWVycywgdGhlIG1vcmUgcHJlY2lz ZSB0ZXJtIHdvdWxkIGJlIOKAnGlucHV0IG1hdGVyaWFsIHRvIGdlbmVyYXRlIGFuIGluZGl2aWR1 YWwga2V5IHRvIHByb3RlY3Qgb3V0Z29pbmcgbWVzc2FnZXPigJ0sIHdvdWxkIHRoYXQgYmUgb2s/ IE9yIGlzIGl0IHN0aWxsIG5vdCBjbGVhciBlbm91Z2g/DQoNCg0KPg0KPiAgICAgKiBTZWN0aW9u IDQuMS42LjMgLSBwYXJhIDIgLSB0aGUgZmlyc3Qgc2VudGVuY2UgZG9lcyBub3QgbWFrZSBhbnkg c2Vuc2UgdG8NCj4gICAgIG1lLiAgSG93IGNvdWxkIHRoZSBoYW5kbGVyIGFjY2VwdCBhIHJlcXVl c3QgZm9yIGEgbm9kZSBkb2VzIG5vdCBtYXRjaA0KPiAgICAgIk5PREVOQU1FIiBhcyB0aGF0IGlz IHRoZSB1cmwtcGF0aD8NCj4NCj4gRlA6IFRoZSBwb2ludCBpcyB0aGF0IHRoZSBLREMgTVVTVCBO T1QgYWNjZXB0IGEgcmVxdWVzdCBmcm9tIGEgbm9kZSBOMQ0KPiBzZW5kaW5nIGEgREVMRVRFIHRv IGFjZS1ncm91cC9HUk9VUE5BTUUvbm9kZXMvTjIuVGhlIEtEQyBjYW4gaWRlbnRpZnkNCj4gdGhl IG5vZGUgbmFtZSBmcm9tIHRoZSBzZWN1cmUgc2Vzc2lvbiBpdCBoYXMgc2V0IHVwIHdpdGggaXQg KGl0IGhhcyBnaXZlbiB0aGUNCj4gbm9kZSBhIG5hbWUgYW5kIGFzc29jaWF0ZWQgaXQgdG8gdGhl IHNlY3VyZSBjaGFubmVsIG9uY2UgdGhlIG5vZGUgaGFzIGRvbmUNCj4gdGhlIGpvaW4gcHJvY2Vz cykuIFdlIGhhdmUgdHJpZWQgdG8gcmVmb3JtdWxhdGUgdG8gY2xhcmlmeS4NCg0KW0pMU10gVGhl IHRleHQgaW4gNC4xLjYuMiB3YXMgY2xlYXJlciBhYm91dCB0aGF0Lg0KDQpGUDogT2ssIHdlIHdp bGwgcmV2ZXJ0IHRvIHRoYXQgYW5kIHJlbW92ZSB0aGUgZmlyc3QgcGFydCBvZiB0aGUgcGFyYWdy YXBoLCB3aGljaCBkb2VzIG5vdCBzZWVtIHRvIGhlbHAgYW55d2F5Og0KDQpPTEQNClRoZSBoYW5k bGVyIG9ubHkgYWNjZXB0cyBhIHJlcXVlc3QgZnJvbSB0aGUgbm9kZSBpZGVudGlmaWVkIGJ5DQoi Tk9ERU5BTUUiIHZpYSB0aGUgc2VjdXJlIHNlc3Npb24sIHdoZXJlIE5PREVOQU1FIGlzIHVzZWQg aW4gVXJpLQ0KUGF0aCwgYW5kIHRoYXQgaXMgcGFydCBvZiB0aGUgIkdST1VQTkFNRSIgZ3JvdXA6 IHRoZSBoYW5kbGVyIHZlcmlmaWVzDQp0aGF0IHRoZSBncm91cCBuYW1lICJHUk9VUE5BTUUiIGlz IGEgc3Vic2V0IG9mIHRoZSAnc2NvcGUnIHN0b3JlZCBpbg0KdGhlIGFjY2VzcyB0b2tlbiBhc3Nv Y2lhdGVkIHRvIHRoaXMgY2xpZW50LCBhbmQgdGhhdCB0aGlzIGNsaWVudCBpcw0KaWRlbnRpZmll ZCBieSAiTk9ERU5BTUUiLiBJZiB2ZXJpZmljYXRpb24gZmFpbHMsIHRoZSBLREMgTVVTVA0KcmVz cG9uZCB3aXRoIGEgNC4wMSAoVW5hdXRob3JpemVkKSBlcnJvciBtZXNzYWdlLg0KTkVXDQpUaGUg aGFuZGxlciB2ZXJpZmllcyB0aGF0IHRoZSBncm91cCBuYW1lIG9mIHRoZSAvYWNlLWdyb3VwL0dS T1VQTkFNRQ0KcGF0aCBpcyBhIHN1YnNldCBvZiB0aGUgJ3Njb3BlJyBzdG9yZWQgaW4gdGhlIGFj Y2VzcyB0b2tlbiBhc3NvY2lhdGVkDQp0byB0aGlzIGNsaWVudCwgaWRlbnRpZmllZCBieSAiTk9E RU5BTUUiLiBJZiB2ZXJpZmljYXRpb24gZmFpbHMsIHRoZQ0KS0RDIE1VU1QgcmVzcG9uZCB3aXRo IGEgNC4wMSAoVW5hdXRob3JpemVkKSBlcnJvciBtZXNzYWdlLg0KDQoNCj4NCj4gICAgICogU2Vj dGlvbiA0LjIgLSAicmV0cmlldmUgaW5kaXZpZHVhbCBvciBncm91cCBrZXlpbmcgbWF0ZXJpYWwi ICBXaGF0DQo+ICAgICBpbmRpdmlkdWFsIG1hdGVyaWFsPw0KPg0KPiBGUDogU2FtZSBhbnN3ZXIg YXMgYmVmb3JlOiB0aGlzIGNvdWxkIGJlIGZvciBleGFtcGxlIHRoZSBzZW5kZXIgSUQgdG8gZGVy aXZlDQo+IHRoZSBTZW5kZXIgS2V5IGluIE9TQ09SRS4gSXTigJlzIGRpZmZpY3VsdCB0byBnaXZl IGEgY2xlYXJlciBpZGVhIGF2b2lkaW5nIHByb2ZpbGUtDQo+IHNwZWNpZmljIGRldGFpbHMuIFdv dWxkIGl0IGhlbHAgdG8gaGF2ZSBhbiBpbmZvcm1hdGlvbmFsIHJlZmVyZW5jZSB0byBrZXkNCj4g Z3JvdXBjb21tIG9zY29yZSB0byBnaXZlIGFuIGV4YW1wbGU/IChJ4oCZZCByYXRoZXIgYXZvaWQg dGhlIGNpcmN1bGFyDQo+IGRlcGVuZGVuY3ksIHNvIGlmIHlvdSBoYXZlIG90aGVyIGlkZWFzIG9u IGhvdyB0byBpbXByb3ZlLCBJ4oCZbGwgdGFrZSB0aGVtKS4NCg0KW0pMU10gUmV0cmlldmUgZ3Jv dXAga2V5aW5nIG1hdGVyaWFsIGZvciB0aGUgaW5kaXZpZHVhbA0KDQpGUDogT2ssIEkgdGhpbmsg d2UgY2FuIHNpbXBsaWZ5IGhlcmUgYW5kIG5vdCB0YWxrIGFib3V0IHRoZSDigJxpbmRpdmlkdWFs IGtleWluZyBtYXRlcmlhbOKAnSBidXQgb25seSB0YWxrIGFib3V0IGdyb3VwIGtleWluZyBtYXRl cmlhbC4NCg0KDQo+DQo+ICAgICAqIFNlY3Rpb24gNC4zIC0gSSBhbSB3b3JyaWVkIGFib3V0IGNv bmdlc3Rpb24gaW4gbW9yZSBwbGFjZXMgdGhhbiBqdXN0IGZvcg0KPiAgICAgT2JzZXJ2ZS4gIElm IGEgc2VydmVyIGlzIHNlbmRpbmcgbG90cyBvZiBtZXNzYWdlcyBvdXQgdG8gY2xpZW50cyBvbiBh DQo+ICAgICBvbmUtdG8tb25lIGJhc2lzIGl0IGNvdWxkIGVhc2lseSBmbG9vZCB0aGUgbmV0d29y ay4NCj4NCj4gRlA6IFdlIGhhZCBhZGRlZCBzb21lIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFi b3V0IGl0LCByZWZlcmVuY2luZyB0byBTZWN0aW9uDQo+IDQuNyBvZiA3MjUyLiBOb3cgd2UgYWRk ZWQgdGhpcyByZWZlcmVuY2UgaW4gdGhpcyBzZWN0aW9uIGFzIHdlbGwuIElzIHRoYXQgZW5vdWdo DQo+IG9yIHdoYXQgaXMgbWlzc2luZz8NCg0KW0pMU10gSSB3b3VsZCBoYXZlIGp1c3QgcHV0IHRo ZSB0ZXh0IGludG8gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIG9yIG5ldHdvcmsgY29uc2lk ZXJhdGlvbnMgc2VjdGlvbnMgYW5kIG5vdCBib3RoZXJlZCB0byBoYXZlIGl0IGhlcmUuICBObyBi aWcgZGVhbA0KDQpGUDogV2UgaGFkIHRob3NlIGFscmVhZHkgaW50byB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMsIGFuZCB3ZSB0aG91Z2h0IHlvdSB3YW50ZWQgbW9yZSB0ZXh0IGhlcmUgc3Bl Y2lmaWNhbGx5LiBXZSBjYW4gcmVtb3ZlIHRoZW0gZnJvbSBoZXJlLCBhcyB3ZSBkb27igJl0IHdh bnQgZHVwbGljYXRlIHRleHQuDQoNCg0KPg0KPiAgICAgKiBTZWN0aW9uIDQuNCAtIFdoYXQgZG9l cyB0aGUgZmlyc3Qgc2VudGVuY2UgZXZlbiBtZWFuPyAgSXQgc2VlbXMgdG8gYmUNCj4gICAgIGFs bW9zdCBhIGNpcmN1bGFyIGFyZ3VtZW50Lg0KPg0KPiBGUDogVHJpZWQgcmVwaHJhc2luZyBhcyBm b2xsb3dzOiDigJxCZXNpZGUgcG9zc2libGUgZXhwaXJhdGlvbiwgdGhlIGNsaWVudCBtYXkNCj4g bmVlZCB0byBjb21tdW5pY2F0ZSB0byB0aGUgS0RDIGl0cyBuZWVkIGZvciBwYXJ0IG9mIHRoZSBr ZXlpbmcgbWF0ZXJpYWwgdG8gYmUNCj4gcmVuZXdlZC4g4oCcIExldCB1cyBrbm93IGlmIHRoaXMg aXMgc3RpbGwgdW5jbGVhci4NCg0KW0pMU10gSSB3b3VsZCBub3QgYm90aGVyIHdpdGggJ3BhcnQg b2YnIEFuZCBwdXR0aW5nIGluIHRleHQgYWJvdXQgd2h5IHRoaXMgaXMgbmVlZGVkIChpLmUuIEFF QUQgaW50ZWdyaXR5L2NvbmZpZGVudGlhbGx5IGxpbWl0cykgaXMgZ29pbmcgdG8gbW90aXZhdGUg dGhpbmdzIGJldHRlci4NCg0KRlA6IE9rLCB3ZSB3aWxsIGFkZCBzb21ldGhpbmcgYWJvdXQgdGhh dC4NCg0KPg0KPiAgICAgKiBTZWN0aW9uIDQuNCAtIEkgZmluZCB0aGUgdGl0bGUgb2YgNC40IHRv IGJlIHNvbWV3aGF0IG1pc2xlYWRpbmcuICBBcyBmYXINCj4gICAgIGFzIEkgY2FuIHRlbGwgdGhp cyBpcyBvbmx5IHRhbGtpbmcgYWJvdXQgb25lIHR5cGUgb2YgcmVuZXdhbCwgYnV0IGV2ZW4gdGhh dA0KPiAgICAgaXMgbm90IGNsZWFyIHRvIG1lLg0KPg0KPiBGUDogT2ssIHdlIHRyaWVkIGNoYW5n aW5nIHRvIOKAnFJldHJpZXZhbCBvZiBOZXcgSW5kaXZpZHVhbCBLZXlpbmcgTWF0ZXJpYWzigJ0g SXMNCj4gdGhpcyBiZXR0ZXI/DQoNCltKTFNdIE5vdCByZWFsbHkgLSB0aGF0IHdvdWxkIHNlZW0g dG8gaW1wbHkgdGhhdCBJIHdvdWxkIG5vdCBnZXQgIm5ldyIgbWF0ZXJpYWwgaW4gc2VjdGlvbiA0 LjMgZWl0aGVyLg0KNC4zIC0gUmV0cmlldmFsIG9mIGtleWluZyBtYXRlcmlhbA0KNC40IC0gUmVx dWVzdGluZyBhIGNoYW5nZSBvZiBrZXlpbmcgbWF0ZXJpYWwNCg0KRlA6IEkgd291bGQgYmUgYWdh aW5zdCByZW5hbWluZyBzZWN0aW9uIDQuNCBzbyBiZWNhdXNlIGl0IHNlZW1zIHRvIGltcGx5IGEg Z3JvdXAgcmVrZXksIHdoaWxlIHRoYXQgaXMgbm90IHdoYXQgdGhpcyBleGNoYW5nZSBpcy4gSSB0 aGluayB3ZSBzdGlsbCBuZWVkIHNvbWV0aGluZyBpbiB0aGUgdGl0bGUgd2l0aCDigJxpbmRpdmlk dWFs4oCdLCBhcyBvcHBvc2VkIHRvIOKAnGdyb3VwIGtleWluZ+KAnS4NCg0KDQo+DQo+ICAgICAq IFNlY3Rpb24gNC41IC0gSXMgdGhlIHNlY29uZCBwYXJhZ3JhcGggaW4gdGhlIHdyb25nIHBsYWNl PyAgSSBkb24ndCByZWFsbHkNCj4gICAgIGNhcmUgd2hhdCB0aGUgY2xpZW50IGRvZXMgb25seSB3 aGF0IHRoZSBzZXJ2ZXIgZG9lcy4NCj4NCj4gRlA6IFdoeT8gSXQgaXMgaW1wb3J0YW50IHRoYXQg dGhlIGNsaWVudCBwcm9jZXNzZXMgdGhlIHJlc3BvbnNlIGNvcnJlY3RseS4gSXQNCj4gbWFrZXMg c2Vuc2UgdGhpcyB3b3VsZCBub3QgYmUgaW4gdGhlIOKAnGhhbmRsZXLigJ0gc2VjdGlvbiwgYnV0 IGhlcmUgd2UgdGhpbmsgd2UNCj4gc2hvdWxkIGhhdmUgdGhpcyB0eXBlIG9mIGRldGFpbHMuIFdv dWxkIGl0IGJlIGJldHRlciB0byBoYXZlIHRoaXMgcGFyYWdyYXBoIGFmdGVyDQo+IHRoZSBmaWd1 cmU/DQoNCltKTFNdIFdoYXQgYWJvdXQgYSBjbGllbnQgd2hpY2ggcmV0cmlldmVzIHRoZSBrZXks IHZlcmlmaWVzIHRoZSBvbmUgc2lnbmF0dXJlIGFuZCBwcm9tcHRseSBmb3JnZXRzIHRoZSBrZXkg dy9vIGFueSBsb25nIHRlcm0gc3RvcmFnZT8gIEknbSBnb2luZyB0byBzbGVlcCBhbG1vc3QgaW1t ZWRpYXRlbHkgYW5kIGl0IHdpbGwgaGF2ZSBwcm9iYWJseSBjaGFuZ2VkIGJ5IHRoZSB0aW1lIEkg d2FrZSB1cCBhZ2Fpbi4NCg0KRlA6IFJpZ2h0LCB0aGF0IG1ha2VzIHNlbnNlLiB3aWxsIHJlbW92 ZS4NCg0KPiAgICAgKiBTZWN0aW9uIDUgLSBEb2VzIHRoZSB1c2Ugb2YgdGhlIERFTEVURSBtZXRo b2QgdG8gaW5mb3JtIGEgY2xpZW50IHRoYXQgaXQNCj4gICAgIGlzIG5vIGxvbmdlciBwYXJ0IG9m IHRoZSBncm91cCBpbXBseSB0aGF0IGEgZGlmZmVyZW50IGNvbnRyb2wgcGF0aCBpcyBuZWVkZWQN Cj4gICAgIGZvciBldmVyeSBncm91cCB0aGF0IHRoZSBjbGllbnQgam9pbnM/ICBJIGRvbid0IGtu b3cgdGhhdCBJIHdhcyBleHBlY3RpbmcNCj4gICAgIHRoYXQuDQo+DQo+IEZQOiBUaGF04oCZcyBj b3JyZWN0LiBBbiBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB0aGF0IHRoZSBLREMgc2VuZHMgYSBQT1NU LA0KPiBpbmRpY2F0aW5nIHRoZSBncm91cCBuYW1lIGluIHRoZSBwYXlsb2FkLiBUaGlzIHdvdWxk IGJlIHNlbnQgdG8gYSBzaW5nbGUNCj4gcmVzb3VyY2Ugb24gdGhlIENsaWVudCB1c2VkIGZvciBh bnkgam9pbmVkIGdyb3VwIHVuZGVyIGFueSBLREMuIFdvdWxkIHlvdQ0KPiBwcmVmZXIgdGhpcz8g KG5vdCBpbXBsZW1lbnRlZCByaWdodCBub3cpDQoNCltKTFNdIEkgZG9uJ3Qga25vdywgYnV0IHBy b2JhYmx5IHllcy4NCg0KRlA6IE9rLCB3ZSBjYW4gbWFrZSB0aGlzIGNoYW5nZSBmb3IgdGhlIG5l eHQgdXBkYXRlLg0KDQo+DQo+ICAgICBTZWN0aW9uIDcgLSAvIGVuZCBvZiB0aGUgcmVrZXlpbmcg cHJvY2VzcyBhbmQgdGhlIG5leHQgbG9zcyBvZiBzZWN1cml0eQ0KPiAgICAgc3RhdGUvICBUaGlz IGlzIG5vdCB3aGF0IEkgd2FzIHRyeWluZyB0byBnZXQgYXQgYW5kIGl0IG1ha2VzIG5vIHNlbnNl IHRvIG1lLg0KPiAgICAgVGhlIHF1ZXN0aW9uIGlzIHRoZSBpbnRlcnZhbCBiZXR3ZWVuIHRoZSBl bmQgb2YgdGhlIGxhc3QgcmVrZXkgcHJvY2VzcyBhbmQNCj4gICAgIHRoZSBjbGllbnQgam9pbmlu ZyB0aGUgZ3JvdXAuICBJZiB0aGF0IGlzIHNtYWxsIGVub3VnaCB0aGVuIHJlcGxheSB3aWxsIG5v dA0KPiAgICAgd29yay4NCj4NCj4gRlA6IE9rLCB3ZSBoYXZlIHJlcGhyYXNlZCBpbiB0aGUgZm9s bG93aW5nIHdheToNCj4gT0xEDQo+IElmIHRoZSBncm91cCBoYXMgcmVuZXdlZCBpdHMgZ3JvdXAg a2V5aW5nIG1hdGVyaWFsLCB0aGUgdGltZSB3aW5kb3cgYmV0d2Vlbg0KPiB0aGUgZW5kIG9mIHRo ZSByZWtleWluZyBwcm9jZXNzIGFuZCB0aGUgbmV4dCBsb3NzIG9mIHNlY3VyaXR5IHN0YXRlIGlz IHNhZmUgZm9yDQo+IHJlY2lwaWVudHMsIGFzIHJlcGxheWVkIG9sZGVyIG1lc3NhZ2VzIHByb3Rl Y3RlZCB3aXRoIHByZXZpb3VzIGtleWluZyBtYXRlcmlhbA0KPiB3aWxsIG5vdCBiZSBhY2NlcHRl ZC4NCj4gTkVXDQo+IEJlc2lkZXMsIGlmIHRoZSBLREMgaGFzIHJlbmV3ZWQgdGhlIGdyb3VwIGtl eWluZyBtYXRlcmlhbCwgYW5kIHRoZSB0aW1lDQo+IGludGVydmFsIGJldHdlZW4gdGhlIGVuZCBv ZiB0aGUgcmVrZXlpbmcgcHJvY2VzcyBhbmQgdGhlIGpvaW5pbmcgb2YgdGhlIENsaWVudCBpcw0K PiBzdWZmaWNpZW50bHkgc21hbGwsIHRoYXQgQ2xpZW50IGlzIGFsc28gb24gdGhlIHNhZmUgc2lk ZSwgc2luY2UgcmVwbGF5ZWQgb2xkZXINCj4gbWVzc2FnZXMgcHJvdGVjdGVkIHdpdGggdGhlIHBy ZXZpb3VzIGtleWluZyBtYXRlcmlhbCB3aWxsIG5vdCBiZSBhY2NlcHRlZC4NCg0KW0pMU10gQmV0 dGVyDQoNCkZQOiAgT2ssIHRoYW5rcy4NCg0KDQo+DQo+ICAgICBTZWN0aW9uIDcgL3RoZSBPYnNl cnZhdGlvbnMgdXAgdG8gdGhhdCBwb2ludC8gdGhpcyBkb2VzIG5vdCBtYWtlIGFueSBzZW5zZS4N Cj4gICAgIFlvdSBjYW4gbG9zZSB3aG8gSSBjdXJyZW50bHkgZG9pbmcgdGhlIG9ic2VydmF0aW9u IGJ1dCB5b3UgaGF2ZSBhbHJlYWR5DQo+ICAgICB0b3NzZWQgYWxsIG9mIHRoZSBvYnNlcnZhdGlv bnMgdGhlbXNlbHZlcyBldmVuIHdpdGhvdXQgYSByZWJvb3QuDQo+DQo+IEZQOiBPaywgd2UgaGF2 ZSByZXBocmFzZWQ6DQo+IE9MRA0KPiB0aGUgT2JzZXJ2YXRpb25zIHVwIHRvIHRoYXQgcG9pbnQN Cj4gTkVXDQo+IGFsbCB0aGUgY3VycmVudCBvbmdvaW5nIE9ic2VydmF0aW9ucyB3aXRoIHRoZSBn cm91cCBtZW1iZXJzIElzIHRoaXMgYmV0dGVyPw0KDQpbSkxTXSBZZWFoLCBiZXR0ZXINCg0KRlA6 IEdvb2QuDQoNCkppbQ0KDQoNCj4NCj4gICAgIEppbQ0KPg0KPg0KPg0KPg0KPg0KPg0KPg0KPg0K Pg0KPg0KPg0KPg0KPg0KDQoNCg== --_000_6941B542FF524479A0B20B3D61382E58ericssoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBkaXI9Imx0 ciI+SGkgSmltLA0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzIGZvciB5b3VyIHJlcGx5 ISBDb21tZW50cyBpbmxpbmUuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5GcmFuY2Vz Y2E8L2Rpdj4NCjwvZGl2Pg0KPHNwYW4gaWQ9ImRyYWZ0LWJyZWFrIj48L3NwYW4+PGJyPg0KPGJy Pg0KPGJyPg0KPHNwYW4gaWQ9ImRyYWZ0LWJyZWFrIj48L3NwYW4+PGJyPg0KPGJyPg0KPGRpdj4N CjxkaXYgY2xhc3M9Im51bGwiIGRpcj0iYXV0byI+T24gMTYgSnVseSAyMDIwIGF0IDIzOjAxOjQ3 IENFU1QsIEppbSBTY2hhYWQgJmx0O2lldGZAYXVndXN0Y2VsbGFycy5jb20mZ3Q7IHdyb3RlOjxi ciBjbGFzcz0ibnVsbCI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJi b3JkZXItbGVmdC1zdHlsZTpzb2xpZDtib3JkZXItd2lkdGg6MXB4O21hcmdpbi1sZWZ0OjBweDtw YWRkaW5nLWxlZnQ6MTBweDsiIGNsYXNzPSJudWxsIj4NCjxkaXYgY2xhc3M9Im51bGwiIGRpcj0i YXV0byI+DQo8ZGl2IGNsYXNzPSJudWxsIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciIgY2xhc3M9Im51bGwiPg0KPCEtLSBjb252ZXJ0 ZWQgZnJvbSB0ZXh0IC0tPg0KPGRpdiBjbGFzcz0ibnVsbCI+PGZvbnQgc2l6ZT0iMiIgY2xhc3M9 Im51bGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiIGNsYXNzPSJudWxsIj4NCjxkaXYg Y2xhc3M9Im51bGwiPjxiciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IEZyb206IEZy YW5jZXNjYSBQYWxvbWJpbmkgJmx0O2ZyYW5jZXNjYS5wYWxvbWJpbmlAZXJpY3Nzb24uY29tJmd0 OzxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTQsIDIwMjAgMjoy NSBQTTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IFRvOiBKaW0gU2NoYWFkICZsdDtpZXRmQGF1Z3Vz dGNlbGxhcnMuY29tJmd0OzsgZHJhZnQtaWV0Zi1hY2Uta2V5LTxiciBjbGFzcz0ibnVsbCI+DQom Z3Q7IGdyb3VwY29tbUBpZXRmLm9yZzxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IENjOiBhY2VAaWV0 Zi5vcmc8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBTdWJqZWN0OiBSZTogUmV2aWV3IG9mIGlldGYt YWNlLWtleS1ncm91cGNvbW0tMDc8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51 bGwiPg0KJmd0OyBIaSBKaW0sPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgPGJyIGNsYXNzPSJudWxs Ij4NCiZndDsgVGhhbmsgeW91IHNvIG11Y2ggZm9yIGFub3RoZXIgZXh0ZW5zaXZlIHJldmlldyEg V2UgaGF2ZSBzdWJtaXR0ZWQgdi0wOCBvZjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IHRoZSBkcmFm dCB0byBhbnN3ZXIgaXQuPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgQ29tbWVudHMgaW5saW5lLiBJ ZiB0aGVyZSBpcyBhbnkgYW5zd2VyL3VwZGF0ZSB0aGF0IGRvZXMgbm90IHNhdGlzZnkgeW91LDxi ciBjbGFzcz0ibnVsbCI+DQomZ3Q7IGhvcGVmdWxseSB3ZSBjYW4gY29udGludWUgdGhlIGRpc2N1 c3Npb24gYnkgbWFpbCBhbmQgZmlndXJlIG91dCB0aGUgbWFqb3I8YnIgY2xhc3M9Im51bGwiPg0K Jmd0OyBwb2ludHMgdG8gZGlzY3VzcyBkdXJpbmcgSUVURjEwOC48YnIgY2xhc3M9Im51bGwiPg0K Jmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBUaGFua3MsPGJyIGNsYXNzPSJudWxsIj4NCiZn dDsgRnJhbmNlc2NhIGFuZCBNYXJjbzxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDxiciBjbGFzcz0i bnVsbCI+DQomZ3Q7IO+7v09uIDI2LzA2LzIwMjAsIDA2OjAyLCAmcXVvdDtKaW0gU2NoYWFkJnF1 b3Q7ICZsdDtpZXRmQGF1Z3VzdGNlbGxhcnMuY29tJmd0OyB3cm90ZTo8YnIgY2xhc3M9Im51bGwi Pg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqIFNlY3Rpb24gMiAtIHVwZGF0ZSBEVExTIHJlZmVyZW5j ZTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IEZQOiBUaGUg QWNlIHByb2ZpbGUgb2YgRFRMUyBpcyBkZWZpbmVkIHRvIHNldCB1cCBEVExTIDEuMiwgdGhlcmUg aXMgbm8gcHJvZmlsZTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IGRlZmluZWQgdG8gc2V0IHVwIERU TFMgMS4zLCBzbyBJIGRvbuKAmXQgdGhpbmsgd2Ugc2hvdWxkIHVwZGF0ZSB0byAxLjMgaGVyZS48 YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxsIj4NCltKTFNdIEZpbmUgLSBidXQgYmUg cHJlcGFyZWQgZm9yIHB1c2hiYWNrIGZyb20gdGhlIElFU0cgb24gdGhpcy48YnIgY2xhc3M9Im51 bGwiPg0KPGJyPg0KRlA6PHNwYW4+Jm5ic3A7QSBwb3NzaWJsZSBhbHRlcm5hdGl2ZSBpcyB0byBy ZXBocmFzZSB0byBtZW50aW9uIHRoZSBwcm9maWxlcyByYXRoZXIgdGhhbiB0aGUgcHJvdG9jb2xz LiBGb3IgZXhhbXBsZTo8YnI+DQo8YnI+DQpPTEQ6PGJyPg0K4oCcUG9zc2libGUgd2F5cyB0byBw cm92aWRlIGEgc2VjdXJlIGNvbW11bmljYXRpb24gYXNzb2NpYXRpb24gYXJlIERUTFMgW1JGQzYz NDddIGFuZCBPU0NPUkUgW1JGQzg2MTNdLuKAnTxicj4NCjxicj4NCk5FVzo8YnI+DQrigJxQb3Nz aWJsZSB3YXlzIHRvIHByb3ZpZGUgYSBzZWN1cmUgY29tbXVuaWNhdGlvbiBhc3NvY2lhdGlvbiBh cmUgZGVzY3JpYmVkIGluIHRoZSBEVExTIHRyYW5zcG9ydCBwcm9maWxlIFtJLUQuaWV0Zi1hY2Ut ZHRscy1hdXRob3JpemVdIGFuZCBPU0NPUkUgdHJhbnNwb3J0IHByb2ZpbGUgW0ktRC5pZXRmLWFj ZS1vc2NvcmUtcHJvZmlsZV0gb2YgQUNFLuKAnTxicj4NCjwvc3Bhbj48YnI+DQpXb3VsZCB0aGF0 IGJlIGJldHRlcj88YnI+DQo8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwi Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqIFNlY3Rpb24gMyAtIFRoZSBjb250ZW50 IGZvcm1hdCBhcHBsaWNhdGlvbi9hY2UrY2JvciBpcyBub3QgZGVmaW5lZCBieSB0aGU8YnIgY2xh c3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0cmFuc3BvcnQgcHJvZmls ZXMgYnV0IGJ5IHRoZSBmcmFtZXdvcmsuPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgPGJyIGNsYXNz PSJudWxsIj4NCiZndDsgRlA6IFRoZSBwb2ludCBpcyB0aGF0IHRoZSBwcm9maWxlcyBtaWdodCBj aGFuZ2UgdGhlIGNvbnRlbnQgZm9ybWF0LCBzbyBldmVuIGlmPGJyIGNsYXNzPSJudWxsIj4NCiZn dDsgdGhpcyBzcGVjaWZpYyBvbmUgYWNlK2Nib3IgaXMgZGVmaW5lZCBpbiBBY2UsIHByb2ZpbGVz IG1pZ2h0IGRlZmluZSBhbmQgdXNlIG90aGVyPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgb25lcy4g UmVwaHJhc2VkIHRvIGNsYXJpZnkuPGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+ DQpbSkxTXSBObywgdGhlIHByb2ZpbGUgY2FuIGRpY3RhdGUgdGhlIG1lZGlhIHR5cGUgYmV0d2Vl biBDIGFuZCBSUywgYnV0IGJldHdlZW4gQyBhbmQgQVMgaXMgc2V0IGJ5IHRoZSBmcmFtZXdvcmsu PGJyIGNsYXNzPSJudWxsIj4NCjxicj4NCkZQOiZuYnNwOzxzcGFuPkFoLCBJIHNlZSB3aGF0IHlv dSBtZWFuLiBJIGNoZWNrZWQgYWdhaW4gaW4gdGhlIGZyYW1ld29yaywgYW5kIHRvIGJlIG5pdHBp Y2tpbmcgaXQgZG9lcyBzYXlzIOKAnFByb2ZpbGVzIHRoYXQgdXNlIENCT1IgZW5jb2Rpbmcgb2Yg cHJvdG9jb2wgbWVzc2FnZSBwYXJhbWV0ZXJzIGF0IHRoZTxicj4NCm91dGVybW9zdCBlbmNvZGlu ZyBsYXllciBNVVNUIHVzZSB0aGUgbWVkaWEgZm9ybWF0ICdhcHBsaWNhdGlvbi88YnI+DQphY2Ur Y2JvcicuIFNvIGluIHNvbWUgc2Vuc2UgdGhlIGNvbnRlbnQtZm9ybWF0IGRlcGVuZHMgb24gaWYg dGhlIHByb2ZpbGUgdXNlcyBDQk9SIG9yIG5vdC4gVGhhdCBkb2VzIG5vdCBjaGFuZ2UgdGhlIGZh Y3QgdGhhdCB3ZSBuZWVkIHRvIHJlcGhyYXNlIG91ciB0ZXh0IGhlcmUgdG8gYmUgY29tcGxldGVs eSBjb3JyZWN0Ljxicj4NCjxicj4NCk9MRDo8YnI+DQpUaGUgQ29udGVudC1Gb3JtYXQ8YnI+DQp1 c2VkIGluIHRoZSBtZXNzYWdlIGlzIHRoZSBvbmUgaW5kaWNhdGVkIGJ5IHRoZSB1c2VkIHRyYW5z cG9ydDxicj4NCnByb2ZpbGUgb2YgQUNFLiBGb3IgZXhhbXBsZSwgLi4uPGJyPg0KTkVXOjxicj4N ClRoZSBDb250ZW50LUZvcm1hdDxicj4NCnVzZWQgaW4gdGhlIG1lc3NhZ2UgZGVwZW5kcyBvbiB0 aGUgdXNlZCB0cmFuc3BvcnQ8YnI+DQpwcm9maWxlIG9mIEFDRS4gRm9yIGV4YW1wbGUsIC4uLjxi cj4NCjwvc3Bhbj48YnI+DQo8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwi Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqIFNlY3Rpb24gMy4xIC0gR2l2ZW4gdGhh dCBhIHJvbGUgaXMgZGVmaW5lZCBhcyBhIHRzdHIsIHRoYXQgZm9ybWF0IGlzIG5vdDxiciBjbGFz cz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHVzYWJsZSBpZiBvbmUgd2lz aGVzIHRvIGFzc2lnbiBhbiBpbnRlZ2VyIGFiYnJldmlhdGlvbiBwZXIgT1BUNy48YnIgY2xhc3M9 Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBGUDogSSB0cmllZCB0byByZWZv cm11bGF0ZSBoZXJlIHRoYXQgdGhlIGFpZiBpcyB0aGUgZGVmYXVsdCBlbmNvZGluZywgYW5kIHNw ZWNpZnk8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyB0aGF0IHRoZSBvdGhlciBmb3JtYXQgZGVmaW5l ZCBpcyBhbiBleGFtcGxlLiBJbiB0aGUgZW5kIGl0IGlzIHVwIHRvIHRoZTxiciBjbGFzcz0ibnVs bCI+DQomZ3Q7IGFwcGxpY2F0aW9uIHByb2ZpbGUgdG8gc3BlY2lmeSB0aGUgZm9ybWF0IG9mIHNj b3BlLjxiciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KU3VyZSwgYnV0IHdoeSBu b3QgZXhwcmVzcyBmaWd1cmUgNCBpbiB0ZXJtcyBvZiBBSUYgcmF0aGVyIHRoYW4gYXMgc29tZXRo aW5nIHRoYXQgbG9va3MgbGlrZSBhIG5ldyBzdHJ1Y3R1cmU/PC9kaXY+DQo8ZGl2IGNsYXNzPSJu dWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPkZQOiZuYnNwOzxzcGFuPldlIGNh biBkbyB0aGF0LCB3ZSB3aWxsIHBvcnQgdGhlIGV4YW1wbGUgZnJvbSB0aGUgT1NDT1JFIGFwcGxp Y2F0aW9uIHByb2ZpbGUgKHRoZSBvbmUgaW4gc2VjdGlvbiAzIG9mIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWFjZS1rZXktZ3JvdXBjb21tLW9zY29yZS0wOCApLjxicj4N Cjwvc3Bhbj48YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgPGJyIGNs YXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiBTZWN0aW9uIDMuMSAt IElzIHRoZXJlIGEgcmVhc29uIHRoYXQgYSBnaWQgaXMgYSBic3RyIGFuZCBub3QgYSB0c3RyLiZu YnNwOyBJPGJyIGNsYXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXNz dW1lIHRoYXQgdGhpcyBpcyB0aGUgc2FtZSBhcyBHUk9VUE5BTUUgd2hpY2ggbXVjaCBiZSBhIHRl eHQgc3RyaW5nIHRvPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgYmU8YnIgY2xhc3M9Im51bGwiPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpbiBhIHVybC1wYXRoLjxiciBjbGFzcz0ibnVs bCI+DQomZ3Q7IDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IEZQOiBXZSBoYXZlIG1vZGlmaWVkIHRo YXQgdG8gYmUgdHN0ciB0byBiZSBjb25zaXN0ZW50IHdpdGggYWNlIGtleSBncm91cGNvbW08YnIg Y2xhc3M9Im51bGwiPg0KJmd0OyBvc2NvcmUsIGJ1dCBwbGVhc2Ugbm90ZSB0aGlzIGlzIG9ubHkg YW4gZXhhbXBsZS48YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxsIj4NCltKTFNdIFll cyBJIGtub3cgaXQgaXMgYW4gZXhhbXBsZSwgYnV0IHRoZSBnbmFtZSBjYW5ub3QgYmUgYW55dGhp bmcgb3RoZXIgdGhhbiBhIHRzdHIgdW5sZXNzIHlvdSBhcmUgZ29pbmcgdG8gY29tcGxldGVseSBi cmVhayB0aGUgY29ubmVjdGlvbiBiZXR3ZWVuIHRoaXMgdmFsdWUgYW5kIHRoZSBuYW1lIGluIHRo ZSBVUkkuPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 Im51bGwiPkZQOiZuYnNwOzxzcGFuPlRoaXMgaXMgYSBnb29kIHBvaW50LCB3ZSBtaWdodCB3YW50 IHRvIHNwZWNpZnkgdGhhdCBpZiBpdOKAmXMgbm90IGEgdHN0ciB0aGVyZSBuZWVkcyB0byBiZSBz b21ldGhpbmcgaW4gcGxhY2UgdG8gbWFrZSB0aGUgdHJhbnNsYXRpb24gYmV0d2VlbiB0aGUgZ3Jv dXAgbmFtZSBhbmQgR1JPVVBOQU1FIHVzZWQgaW4gdGhlIFVSSSAoZXg6IGJzdHIgZ2V0cyB0cmFu c2xhdGVkIGludG8gdHN0ciAweDAxMjMgYmVjb21lcw0KIOKAnDAxMjPigJ0pPGJyPg0KPGJyPg0K PC9zcGFuPjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICog U2VjdGlvbiAzLjIgLSB0aGUgZGVmIG9mIHNjb3BlIHNlZW1zIG9kZCBiZWNhdXNlIGl0IGlzIG5v dCB3ZWxsIGRlZmluZWQgaWY8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBpdCB3b3VsZCBiZSB0aGUgc2FtZSBhcyB0aGUgcmVxdWVzdGVkIHNjb3BlLiAoQVMg cmVzcG9uc2UpPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgPGJyIGNsYXNzPSJudWxsIj4NCiZndDsg RlA6Jm5ic3A7IEkgbmVlZCBtb3JlIGNsYXJpZmljYXRpb25zOiBJcyBpdCB0aGUgZm9sbG93aW5n IHRoYXQgaXMgc3RyYW5nZSDigJwnc2NvcGUnPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgY29udGFp bmluZyB0aGUgZ3JhbnRlZCBzY29wZSwgaWYgZGlmZmVyZW50IGZyb20gdGhlIHNjb3BlIHJlcXVl c3RlZCBieSB0aGU8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBjbGllbnQuIOKAnCA/IE5vdGUgdGhh dCB0aGUgdGVybWlub2xvZ3kg4oCccmVxdWVzdGVkIGFuZCBncmFudGVkIHNjb3Bl4oCdIGNvbWVz PGJyIGNsYXNzPSJudWxsIj4NCiZndDsgZnJvbSBPQXV0aDogPGEgaHJlZj0iaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzY3NDkjc2VjdGlvbi0zLjMiIHRhcmdldD0iX0JMQU5LIiBjbGFz cz0ibnVsbCI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNjc0OSNzZWN0aW9uLTMu MzwvYT4uIEkgcmVtb3ZlZCB0aGU8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBzZWNvbmQgcGFydCBv ZiB0aGUgc2VudGVuY2UgYXMgcGVyIGNvbW1lbnQgYmVsb3cuPGJyIGNsYXNzPSJudWxsIj4NCjxi ciBjbGFzcz0ibnVsbCI+DQpbSkxTXSBXaGF0IHNlZW1zIG9kZCBpcyB0aGF0IGlmIGl0IGlzIGFi c2VudCwgdGhlbiBpdCBpcyBub3QgY2xlYXIgd2hhdCB0aGUgZ3JhbnRzIGFyZS4mbmJzcDsgSSBk b24ndCBrbm93IGlmIHlvdSBuZWVkIHRvIHNwZWNpZnkgdGhhdCB0aGUgZ3JhbnQgaXMgdGhlIHNh bWUgYXMgdGhlIHJlcXVlc3Qgd2hlbiBpdCBpcyBub3QgcHJlc2VudC4mbmJzcDsgT24gdGhlIG90 aGVyIGhhbmQgdGhpcyBpcyBkdXBsaWNhdGluZyBpbmZvcm1hdGlvbiBpbiB0aGUgZnJhbWV3b3Jr DQogZG9jdW1lbnQuPGJyIGNsYXNzPSJudWxsIj4NCjxicj4NCkZQOiZuYnNwOzxzcGFuPlllcywg dGhhdCB3YXMgdGhlIGlkZWEsIHRoYXQgaWYgaXTigJlzIG5vdCBwcmVzZW50IHRoZSBncmFudGVk IHNjb3BlIGlzIHRoZSBzYW1lIGFzIHRoZSByZXF1ZXN0ZWQgb25lLiBJIGFtIG5vdCBhZ2FpbnN0 IGR1cGxpY2F0aW5nIGluZm9ybWF0aW9uIGlmIGl0IG1pZ2h0IG1ha2UgdGhpbmdzIGNsZWFyZXIu PC9zcGFuPjxicj4NCjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDxiciBjbGFzcz0ibnVsbCI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICogU2VjdGlvbiAzLjMgLSBBbSBJIHN1cHBvc2Vk IHRvIGtub3cgd2h5IEkgY2FyZSBhYm91dCBwdWJsaWMga2V5cyBhdCB0aGlzPGJyIGNsYXNzPSJu dWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcG9pbnQ/PGJyIGNsYXNzPSJudWxs Ij4NCiZndDsgPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgRlA6Jm5ic3A7IEkgdGhvdWdodCB0aGlz IHNlbnRlbmNlIHdhcyBzdXBwb3NlZCB0byBjb3ZlciBpdCAoc2Vjb25kIHBhcmFncmFwaCBvZiAz LjMpOjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IOKAnE9wdGlvbmFsbHksIHRoZSBDbGllbnQgbWln aHQgd2FudCB0byByZXF1ZXN0IG5lY2Vzc2FyeSBpbmZvcm1hdGlvbiBjb25jZXJuaW5nPGJyIGNs YXNzPSJudWxsIj4NCiZndDsgdGhlIHB1YmxpYyBrZXlzIGluIHRoZSBncm91cCwgYXMgd2VsbCBh cyBjb25jZXJuaW5nIHRoZSBhbGdvcml0aG0gYW5kIHJlbGF0ZWQ8YnIgY2xhc3M9Im51bGwiPg0K Jmd0OyBwYXJhbWV0ZXJzIGZvciBjb21wdXRpbmcgc2lnbmF0dXJlcyBpbiB0aGUgZ3JvdXAu4oCd IFdoYXTigJlzIG1pc3Npbmc/PGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+DQpb SkxTXSBXZWxsIC0gbGV0cyBzdGFydCB3aXRoIHRoZSB1c2Ugb2YgdGhlIHNpbmd1bGFyIGdyb3Vw IGluIHRoZSB0ZXh0LiZuYnNwOyBUaGVyZSBhcmUgYSBudW1iZXIgb2YgcHJvYmxlbXMgaGVyZTom bmJzcDsgMS4mbmJzcDsgSXQgd291bGQgbWFrZSBzZW5zZSB0aGF0IHRoaXMgcmVmZXIgdG8gdGhl IHB1YmxpYyBrZXkgdXNhZ2UgZnJvbSBncm91cCBjb21tIGRvY3VtZW50LiZuYnNwOyAyLiBUaGUg dGVybSAmcXVvdDtpbmZvcm1hdGlvbiBjb25jZXJuaW5nIHRoZSBwdWJsaWMga2V5cyBpbg0KIHRo ZSBncm91cCZxdW90OyB0byBtZSByZWFkcyAtIGdldCB0aGUgcHVibGljIGtleXMuJm5ic3A7IDMu Jm5ic3A7IFRoZXJlIGlzIG5vIG1vdGl2YXRpb24gYWJvdXQgd2h5IHlvdSBhcmUgZ2V0dGluZyB0 aGlzIGZyb20gdGhlIHRva2VuIHBvc3QgcmF0aGVyIHRoYW4gZnJvbSB0aGUgZ3JvdXAgZGVzY3Jp cHRvci48L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i bnVsbCI+RlA6Jm5ic3A7PHNwYW4+MS4gUmlnaHQsIHdlIGNhbiBhZGQgYSByZWZlcmVuY2UgdG8g aXQuIDIuIEkgc2VlLCBpbnN0ZWFkIGF0IHRoaXMgcG9pbnQgd2Ugd291bGQgbGlrZSB0byBnZXQg aW5mbyBhYm91dCBmb3IgZXhhbXBsZSBlbmNvZGluZywgbm90IHB1YmxpYyBrZXlzIHRoZW1zZWx2 ZXMuIDMuIFJpZ2h0LCBzbyB3aGF0IHdlIG5lZWQgdG8gYWRkIGhlcmUgaXMgdGhhdCB0aGlzIGlu Zm9ybWF0aW9uIGlzIHNlbnQgYmVmb3JlDQogdGhlIGpvaW5pbmcgZXhjaGFuZ2Ugc28gdGhhdCB0 aGUgam9pbmluZyBub2RlIGNhbiBzZW5kIGl0cyBvd24gcHVibGljIGtleSBkaXJlY3RseSBpbiB0 aGUgam9pbmluZyByZXF1ZXN0IGFuZCBkb2VzIG5vdCBuZWVkIHRvIGRvIGEgc2VwYXJhdGUgZXhj aGFuZ2UgZm9yIHRoYXQuDQo8YnI+DQo8YnI+DQpPTEQ6PGJyPg0KT3B0aW9uYWxseSwgdGhlIENs aWVudCBtaWdodCB3YW50IHRvIHJlcXVlc3QgaW5mb3JtYXRpb24gY29uY2VybmluZzxicj4NCnRo ZSBwdWJsaWMga2V5cyBpbiB0aGUgZ3JvdXAsIGFzIHdlbGwgYXMgY29uY2VybmluZyB0aGUgYWxn b3JpdGhtIGFuZDxicj4NCnJlbGF0ZWQgcGFyYW1ldGVycyBmb3IgY29tcHV0aW5nIHNpZ25hdHVy ZXMgaW4gdGhlIGdyb3VwLiBJbiBzdWNoIGE8YnI+DQpjYXNlLCB0aGUgam9pbmluZyBub2RlIE1B WSBhc2sgZm9yIHRoYXQgaW5mb3JtYXRpb24gdG8gdGhlIEtEQyBpbjxicj4NCnRoaXMgc2FtZSBy ZXF1ZXN0LiBUbyB0aGlzIGVuZCwgaXQgc2VuZHMgdGhlIENvQVAgUE9TVCByZXF1ZXN0IHRvPGJy Pg0KdGhlIC9hdXRoei1pbmZvIGVuZHBvaW50IHVzaW5nIHRoZSBDb250ZW50LUZvcm1hdCAmcXVv dDthcHBsaWNhdGlvbi88YnI+DQphY2UrY2JvciZxdW90Oy48YnI+DQo8YnI+DQpORVc6PGJyPg0K T3B0aW9uYWxseSwgdGhlIENsaWVudCBtaWdodCB3YW50IHRvIHJlcXVlc3QgZW5jb2RpbmcgaW5m b3JtYXRpb24gYWJvdXQ8YnI+DQp0aGUgcHVibGljIGtleXMgaW4gdGhlIGdyb3VwLCBhcyB3ZWxs IGFzIGFib3V0IHRoZSBhbGdvcml0aG0gYW5kPGJyPg0KcmVsYXRlZCBwYXJhbWV0ZXJzIGZvciBj b21wdXRpbmcgc2lnbmF0dXJlcyBpbiB0aGUgZ3JvdXAsIGlmIHRob3NlIGFyZSB1c2VkLCBhcyBm b3IgZXhhbXBsZSBpbiBbSS1ELmlldGYtY29yZS1ncm91cGNvbW0tYmlzXS4gSW4gc3VjaCBhPGJy Pg0KY2FzZSwgdGhlIGpvaW5pbmcgbm9kZSBNQVkgYXNrIGZvciB0aGF0IGluZm9ybWF0aW9uIHRv IHRoZSBLREMgaW48YnI+DQp0aGlzIHNhbWUgcmVxdWVzdCwgc28gdG8gZ2V0IHRoZSBpbmZvcm1h dGlvbiBiZWZvcmUgdGhlIGpvaW5pbmcgZXhjaGFuZ2UgaXRzZWxmIChzZWUgU2VjdGlvbiA0LjIp LiBUbyB0aGlzIGVuZCwgaXQgc2VuZHMgdGhlIENvQVAgUE9TVCByZXF1ZXN0IHRvPGJyPg0KdGhl IC9hdXRoei1pbmZvIGVuZHBvaW50IHVzaW5nIHRoZSBDb250ZW50LUZvcm1hdCAmcXVvdDthcHBs aWNhdGlvbi88YnI+DQphY2UrY2JvciZxdW90Oy48YnI+DQo8L3NwYW4+PGJyIGNsYXNzPSJudWxs Ij4NCjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICogU2Vj dGlvbiAzLjMgLSBhcmUgeW91IGltcG9zaW5nIGEgbmV3IHJlcXVpcmVtZW50IHRoYXQgdGhlIHRv a2VuIGJlPGJyIGNsYXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdmFs aWRhdGVkIHByaW9yIHRvIHJldHVybmluZyB0aGUgcmVzcG9uc2UgdG8gYSB0b2tlbiBwb3N0PyZu YnNwOyBBcyBJIHJlbWVtYmVyPGJyIGNsYXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgaXQsIHRoaXMgaXMgbm90IHJlcXVpcmVkIHRvIGhhcHBlbiBwcmlvciB0byB0aGUg cmVzcG9uc2UgYmVpbmcgcmV0dXJuZWQganVzdDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGJlZm9yZSBhY2Nlc3MgaXMgZ3JhbnRlZC4mbmJzcDsgKEkuZS4g eW91IGNhbiB2YWxpZGF0ZSB0aGUgdG9rZW4gaW4gcGFyYWxsZWwpPGJyIGNsYXNzPSJudWxsIj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKEFmdGVyIHN1Y2Nlc3NmdWwgdmVyaWZpY2F0 aW9uLi4uKTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IEZQ OiBJdCBzZWVtcyB0byB1cyB0aGlzIGlzIGFscmVhZHkgZGVmaW5lZCBpbiB0aGUgZnJhbWV3b3Jr OiBmcm9tPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtYWNlLW9hdXRoLWF1dGh6LTM1I3NlY3Rpb24tNS44LjEiIHRh cmdldD0iX0JMQU5LIiBjbGFzcz0ibnVsbCI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1hY2Utb2F1dGgtYXV0aHotMzUjc2VjdGlvbi01LjguMTwvYT48YnIgY2xhc3M9 Im51bGwiPg0KJmd0OyDigJxXaGVuIGFuIFJTIHJlY2VpdmVzIGFuIGFjY2VzcyB0b2tlbiwgaXQg TVVTVCB2ZXJpZnkgaXQgYmVmb3JlIHN0b3JpbmcgaXQu4oCdPGJyIGNsYXNzPSJudWxsIj4NCiZn dDsgQW5kIGxhdGVyPGJyIGNsYXNzPSJudWxsIj4NCiZndDsg4oCcSWYgdG9rZW4gb3IgY2xhaW0g dmVyaWZpY2F0aW9uIGZhaWxzLCB0aGUgUlMgTVVTVCBkaXNjYXJkIHRoZSB0b2tlbiBhbmQsIGlm IHRoaXM8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyB3YXMgYW4gaW50ZXJhY3Rpb24gd2l0aCBhdXRo ei1pbmZvLCByZXR1cm4gYW4gZXJyb3IgbWVzc2FnZSB3aXRoIGEgcmVzcG9uc2U8YnIgY2xhc3M9 Im51bGwiPg0KJmd0OyBjb2RlIGVxdWl2YWxlbnQgdG8gdGhlIENvQVAgY29kZSA0LjAxIChVbmF1 dGhvcml6ZWQpLuKAnTxiciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KW0pMU10g VGhhdCB0ZXh0IGRvZXMgbm90IHNheSB0aGF0IG9uZSBjYW5ub3QgZG8gdGhlIGZvbGxvd2luZzom bmJzcDsgMSkgR2V0IHRoZSB0b2tlbiBmcm9tIHRoZSBQT1NULCZuYnNwOyAyKSBpbW1lZGlhdGVs eSByZXR1cm4gYSBzdWNjZXNzIGluZGljYXRvciwgMykgZG8gdGhlIHZhbGlkYXRpb24gb2YgdGhl IHRva2VuLCBpbmNsdWRpbmcgaW50cm9zcGVjdGlvbiBpZiBuZWNlc3NhcnksIDQpIEtlZXAgb3Ig ZGlzY2FyZCB0aGUgdG9rZW4gZGVwZW5kaW5nIG9uIHRoZQ0KIG91dGNvbWUgb2YgdGhlIHZhbGlk YXRpb24gcHJvY2Vzcy4gPGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+DQpJIHdh cyB3b3JraW5nIHRvIGdldCB0aGlzIGluIGJlY2F1c2UgSSBkaWQgbm90IHdhbnQgdG8gaGF2ZSBu byByZXNwb25zZSBnbyBiYWNrIHRvIHRoZSBjbGllbnQgd2hpbGUgd2FpdGluZyBmb3IgdGhlIHRv a2VuIHRvIGJlIHZhbGlkYXRlZCBpbiB0aGUgZXZlbnQgb2YgbmVlZGluZyB0byBkbyBpbnRyb3Nw ZWN0aW9uLiZuYnNwOyBUaGVyZSBpcyBub3RoaW5nIHJlYWxseSBiYWQgaGFwcGVuaW5nIGlmIEkg cmV0dXJuIGEgT1NDT1JFIG5vbmNlIGluIHRoZSBldmVudA0KIHRoYXQgeW91IHNlbmQgbWUgYSBE VExTIHRva2VuIGJlY2F1c2UgeW91IHdvdWxkIGp1c3QgaWdub3JlIHRoYXQgYXMgbm90IGJlaW5n IHVzZWZ1bC4mbmJzcDsgSG93ZXZlciwgaWYgSSBoYXZlIHRvIGhhdmUgdGhlIGVudGlyZSBjb250 ZW50IG9mIHRoZSB0b2tlbiBiZWZvcmUgSSBjYW4gcmVzcG9uZCB0aGVuIGludHJvc3BlY3Rpb24g aXMgZ29pbmcgdG8gYmUgaGFyZGVyIHRvIGRlYWwgd2l0aC48L2Rpdj4NCjxkaXYgY2xhc3M9Im51 bGwiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVsbCI+RlA6Jm5ic3A7PHNwYW4+SSBzZWUs IEkgcGVyc29uYWxseSBkbyBub3QgdGhpbmsgdGhlIHByb2NlZHVyZSB5b3UgZGVzY3JpYmUgaXMg dmFsaWQgZnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgZnJhbWV3b3JrLCBpbiBwYXJ0aWN1 bGFyLCBTZWN0aW9uIDUuOC4xIHNheXM6DQo8YnI+DQo8YnI+DQpUaGUgUlM8YnI+DQpyZWNlaXZp bmcgdGhlIHRva2VuIE1VU1QgdmVyaWZ5IHRoZSB2YWxpZGl0eSBvZiB0aGUgdG9rZW4uIElmIHRo ZTxicj4NCnRva2VuIGlzIHZhbGlkLCB0aGUgUlMgTVVTVCByZXNwb25kIHRvIHRoZSBQT1NUIHJl cXVlc3Qgd2l0aCAyLjAxPGJyPg0KKENyZWF0ZWQpLiBTZWN0aW9uIFNlY3Rpb24gNS44LjEuMSBv dXRsaW5lcyBob3cgYW4gUlMgTVVTVCBwcm9jZWVkPGJyPg0KdG8gdmVyaWZ5IHRoZSB2YWxpZGl0 eSBvZiBhbiBhY2Nlc3MgdG9rZW4uPGJyPg0KPGJyPg0KQWx0aG91Z2ggaXQgZG9lcyBub3Qgc2F5 IHRoYXQgaXQgTVVTVCBOT1QgcmVzcG9uZCB3aXRoIDIuMDEgdW5sZXNzIHRoZSB0b2tlbiBpcyB2 YWxpZCwgSSBkbyBpbnRlcnByZXQgdGhlIHByZXZpb3VzIHBhcmFncmFwaCB0aGF0IHdheS4gSSB3 b3VsZCB0aGluayB0aGF0IDIuMDEgbWVhbnMg4oCcdGhlIHRva2VuIGhhcyBiZWVuIHZlcmlmaWVk IGFuZCBwYXNzZWQgdmVyaWZpY2F0aW9u4oCdIHJhdGhlciB0aGFuIOKAnEkgcmVjZWl2ZWQgdGhl IHRva2Vu4oCdLiBUaGlzDQogZm9sbG93aW5nIHBhcmFncmFwaCAoZnJvbSB0aGUgZnJhbWV3b3Jr KSBzaG91bGQgY292ZXIgdGhlIGNhc2UgeW91IGFyZSB0YWxraW5nIGFib3V0Ojxicj4NCjxicj4N ClRoZSBSUyBNQVkgbWFrZSBhbiBpbnRyb3NwZWN0aW9uIHJlcXVlc3QgdG8gdmFsaWRhdGUgdGhl IHRva2VuIGJlZm9yZTxicj4NCnJlc3BvbmRpbmcgdG8gdGhlIFBPU1QgcmVxdWVzdCB0byB0aGUg YXV0aHotaW5mbyBlbmRwb2ludCwgZS5nLiBpZjxicj4NCnRoZSB0b2tlbiBpcyBhbiBvcGFxdWUg cmVmZXJlbmNlLiBTb21lIHRyYW5zcG9ydCBwcm90b2NvbHMgbWF5PGJyPg0KcHJvdmlkZSBhIHdh eSB0byBpbmRpY2F0ZSB0aGF0IHRoZSBSUyBpcyBidXN5IGFuZCB0aGUgY2xpZW50IHNob3VsZDxi cj4NCnJldHJ5IGFmdGVyIGFuIGludGVydmFsOyB0aGlzIHR5cGUgb2Ygc3RhdHVzIHVwZGF0ZSB3 b3VsZCBiZTxicj4NCmFwcHJvcHJpYXRlIHdoaWxlIHRoZSBSUyBpcyB3YWl0aW5nIGZvciBhbiBp bnRyb3NwZWN0aW9uIHJlc3BvbnNlLjxicj4NCjxicj4NCkkgc3RpbGwgaW50ZXJwcmV0IHRoaXMg YXMg4oCcb25seSByZXNwb25kIHdpdGggc3VjY2VzcyB3aGVuIHRoZSB0b2tlbiBpcyB2YWxpZGF0 ZWTigJ0uIEkgZG9u4oCZdCBrbm93IHdoYXQgd2F5IHRvIGluZGljYXRlIHRoYXQgdGhlIFJTIGlz IGJ1c3kgY291bGQgYmUgdXNlZCBpbiBDb0FQLg0KPGJyPg0KPGJyPg0KQWxzbywgaW4gY2FzZSB0 aGUgcHJvY2VkdXJlIHlvdSBkZXNjcmliZSB3b3VsZCBiZSBhbGxvd2VkLCBzYXkgdGhlIHRva2Vu IGRvZXMgbm90IHZlcmlmeSBhbmQgdGhlIFJTIHdhbnRzIHRvIHNlbmQgYW4gZXJyb3IgcmVzcG9u c2UsIHRoYXQgd291bGQgYmUgbG9zdCBhdCB0aGUgQ2xpZW50IHdoaWNoIGhhcyBhbHJlYWR5IHJl Y2VpdmVkIGEgMi4wMS48YnI+DQo8YnI+DQpBbnl3YXksIEkgZG8gdGhpbmsgdGhpcyBpcyBhIHZh bGlkIGRpc2N1c3Npb24gZm9yIHRoZSBmcmFtZXdvcmsgYW5kIEkgZG8gbm90IHdhbnQgb3VyIGRy YWZ0IHRvIGFkZCBhbnkgcmVxdWlyZW1lbnRzIHRvIHdoYXQgdGhlIGZyYW1ld29yayBkZWZpbmVz LiBJIHRoaW5rIHdlIGNvdWxkIHJlcGhyYXNlIHRoZSBmb2xsb3dpbmcgdG8gcmVtb3ZlIGFueSBp bXBsaWNpdCBjb25zZXF1ZW5jZTo8YnI+DQo8YnI+DQpPTEQ6PGJyPg0KQWZ0ZXIgc3VjY2Vzc2Z1 bCB2ZXJpZmljYXRpb24sIHRoZSBDbGllbnQgaXMgYXV0aG9yaXplZCB0byByZWNlaXZlPGJyPg0K dGhlIGdyb3VwIGtleWluZyBtYXRlcmlhbCBmcm9tIHRoZSBLREMgYW5kIGpvaW4gdGhlIGdyb3Vw LiBJbjxicj4NCnBhcnRpY3VsYXIsIHRoZSBLREMgcmVwbGllcyB0byB0aGUgQ2xpZW50IHdpdGgg YSAyLjAxIChDcmVhdGVkKTxicj4NCnJlc3BvbnNlLCB1c2luZyBDb250ZW50LUZvcm1hdCAmcXVv dDthcHBsaWNhdGlvbi9hY2UrY2JvciZxdW90OyBkZWZpbmVkIGluPGJyPg0KU2VjdGlvbiA4LjE0 IG9mIFtJLUQuaWV0Zi1hY2Utb2F1dGgtYXV0aHpdLjxicj4NCk5FVzo8YnI+DQpBZnRlciBzdWNj ZXNzZnVsIHZlcmlmaWNhdGlvbiwgdGhlIENsaWVudCBpcyBhdXRob3JpemVkIHRvIHJlY2VpdmU8 YnI+DQp0aGUgZ3JvdXAga2V5aW5nIG1hdGVyaWFsIGZyb20gdGhlIEtEQyBhbmQgam9pbiB0aGUg Z3JvdXAuIDxicj4NCjxicj4NClRoZSBLREMgcmVwbGllcyB0byB0aGUgQ2xpZW50IHdpdGggYSAy LjAxIChDcmVhdGVkKTxicj4NCnJlc3BvbnNlLCB1c2luZyBDb250ZW50LUZvcm1hdCAmcXVvdDth cHBsaWNhdGlvbi9hY2UrY2JvciZxdW90OyBkZWZpbmVkIGluPGJyPg0KU2VjdGlvbiA4LjE0IG9m IFtJLUQuaWV0Zi1hY2Utb2F1dGgtYXV0aHpdLjxicj4NCjwvc3Bhbj48YnIgY2xhc3M9Im51bGwi Pg0KPGJyIGNsYXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiBTZWN0 aW9uIDMuMyAtIFlvdSB3b3VsZCBub3QgYmUgYWJsZSB0byByZXVzZSB0aGUgc2FtZSBrZGNjaGFs bGVuZ2UgdmFsdWU8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyB3aXRoIGEgZGlmZmVyZW50IGtleS4mbmJzcDsgSXQgd291bGQgbm90IGhhdmUgYW55IHdheSBv ZiBiZWluZyBhc3NvY2lhdGVkIHdpdGg8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB0aGF0IGtleSBhbmQgd291bGQgbG9vayBsaWtlIHNvbWVib2R5IGVsc2Ug d2FzIGF0dGVtcHRpbmcgdG8gdXNlIHRoZSB2YWx1ZS48YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8 YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBGUDogTm90IHN1cmUgd2UgdW5kZXJzdGFuZCB0aGUgcHJv YmxlbSBoZXJlLiBEb2VzIOKAnGRpZmZlcmVudCBrZXnigJ0gcmVmZXIgdG8gYTxiciBjbGFzcz0i bnVsbCI+DQomZ3Q7IGZvbGxvd2luZyBuZXcgcHVibGljIGtleSB0aGF0IHRoZSBjbGllbnQgd2Fu dHMgdG8gdXBsb2FkPyBUaGVyZSBpcyBpbiBmYWN0IG5vPGJyIGNsYXNzPSJudWxsIj4NCiZndDsg YXNzb2NpYXRpb24gYmV0d2VlbiDigJhrZGNjaGFsbGVuZ2XigJkgYW5kIHRoZSBwdWJsaWMga2V5 IGl0c2VsZiwgbm90IGV2ZW4gd2l0aCB0aGU8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBmaXJzdCBv bmUgdGhhdCB0aGUgY2xpZW50IHByb3ZpZGVzIGF0IGl0cyBmaXJzdCBqb2luaW5nIChhbmQgaXQg aXMgYWxzbyB1bmtub3duIHRvIHRoZTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IEtEQyBhdCB0aGUg dGltZSB3aGVuIOKAmGtkY2NoYWxsZW5nZeKAmSBpcyBpc3N1ZWQpLiBJdOKAmXMgaW1wb3J0YW50 IHRoZTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IOKAmGtkY2NoYWxsZW5nZeKAmSBpcyBhc3NvY2lh dGVkIHRvIHRoYXQgZXhhY3QgY2xpZW50LCBtZWFuaW5nIHRvIHRoYXQgZXhhY3QgVG9rZW48YnIg Y2xhc3M9Im51bGwiPg0KJmd0OyBhbmQgUG9QIGtleS48YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNs YXNzPSJudWxsIj4NCltKTFNdIExldCdzIHN0YXJ0IHdpdGggd2hpY2ggJnF1b3Q7ZGlmZmVyZW50 IGtleSZxdW90OyB5b3UgYXJlIHJlZmVycmluZyB0by4mbmJzcDsgSXMgdGhpcyBhIGRpZmZlcmVu dCBzaWduaW5nIGtleSBvciBhIGRpZmZlcmVudCBQT1Aga2V5PyZuYnNwOyBEZXBlbmRpbmcgb24g aG93IHlvdSByZWFkIHRoaXMgaXMgY29tcGxldGVseSBjaGFuZ2VzIHRoZSBtZWFuaW5nIG9mIHdo YXQgeW91IGFyZSBzYXlpbmcgdG8gZG8gaW4gdGhpcyBwYXJhZ3JhcGguJm5ic3A7IEEgZGlmZmVy ZW50IFBPUCBrZXkNCiAodG9rZW4pIHdpbGwgbm90IGJlIHVzaW5nIHRoZSBzYW1lIGtkY2NoYWxs ZW5nZSBhcyBhIGRpZmZlcmVudCBQT1Aga2V5LiZuYnNwOyBZb3UgbWlnaHQgYmUgYWJsZSB0byB1 c2UgaXQgZm9yIGEgZGlmZmVyZW50IHNpZ25pbmcga2V5IGZvciBhIHNlY29uZCBncm91cCBpbiB0 aGUgc2FtZSB0b2tlbi4mbmJzcDsgQnV0IHRoYXQgaXMgbm90IGhvdyBJIHJlYWQgaXQuPC9kaXY+ DQo8ZGl2IGNsYXNzPSJudWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPkZQOiZu YnNwOzxzcGFuPlJpZ2h0LCB3ZSBkaWQgbWVhbiBhIGRpZmZlcmVudCBzaWduaW5nIGtleS4gV2Ug d2lsbCBjbGFyaWZ5IHRoYXQuPGJyPg0KPC9zcGFuPjxiciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xh c3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqIFNlY3Rpb24gMy4zIC0g bGFzdCBwYXJhZ3JhcGggLSBzaG91bGQgdGhpcyBiZSByZWZlcnJpbmcgdG8gYXBwbGljYXRpb25z IG9yPGJyIGNsYXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJvZmls ZXM/Jm5ic3A7IC0tIHJlYWxseSBhIGdsb2JhbCBxdWVzdGlvbi4mbmJzcDsgQ29uc2lkZXIgLSBp cyB0aGUgT1NDT1JFIHByb2ZpbGU8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBhdHRhY2hlZCB0byBhIHNwZWNpZmljIGFwcGxpY2F0aW9uIG9yIHRvIGEgc2V0 IG9mIHVua25vd24gYXBwbGljYXRpb25zPzxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDxiciBjbGFz cz0ibnVsbCI+DQomZ3Q7IEZQOiBIZXJlIHdlIG1lYW50IGFwcGxpY2F0aW9uIHByb2ZpbGVzIG9m IHRoaXMgZG9jIHN1Y2ggYXMg4oCcYWNlLWtleS08YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBncm91 cGNvbW0tb3Njb3Jl4oCdLiBJIGRvbuKAmXQgdW5kZXJzdGFuZCB0aGUgc2Vjb25kIHBhcnQgb2Yg aGlzIGNvbW1lbnQsIGNvdWxkPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgeW91IGV4cGxhaW4/PGJy IGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+DQpbSkxTXSZuYnNwOyBNeSBwcm9ibGVt IGlzIHRoYXQgYXBwbGljYXRpb24gaXMgYSByZWFsbHkgb3ZlcmxvYWRlZCB0ZXJtLiZuYnNwOyBK dXN0IHRoaW5rIG9mIHRocmVlIGRpZmZlcmVudCBsaWdodGluZyBhcHBsaWNhdGlvbnM6Jm5ic3A7 IFRoZWF0ZXIgTGlnaHRpbmcsIEJ1aWxkaW5nIExpZ2h0aW5nIGFuZCBFbWVyZ2VuY3kgTGlnaHRp bmcuJm5ic3A7IFRoZXNlIGFyZSB0aHJlZSBkaWZmZXJlbnQgYXBwbGljYXRpb25zIHRoYXQgYXJl IGFsbCBnb2luZyB0byB1c2UgYW4gT1NDT1JFDQogZ3JvdXAga2V5aW5nIHByb3RvY29sIGFzIHBh cnQgb2YgdGhlaXIgaW1wbGVtZW50YXRpb24uJm5ic3A7IE5vdyB5b3UgYXJlIHNheWluZyB0aGF0 IHRoZSBwcm9maWxlIGlzIGFuIGFwcGxpY2F0aW9uLiZuYnNwOyBJIGFtIGdldHRpbmcgcmVhbGx5 IGNvbmZ1c2VkIGFib3V0IHdoYXQgaXMgYW4gYXBwbGljYXRpb24gYW5kIHdoYXQgaXNuJ3QuPC9k aXY+DQo8ZGl2IGNsYXNzPSJudWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPkZQ OiZuYnNwOzxzcGFuPllvdSBhcmUgcmlnaHQsIHdlIHNob3VsZCBoYXZlIHVzZWQgdGhlIHRlcm0g 4oCcYXBwbGljYXRpb24gcHJvZmlsZXPigJ0sIGNvbnNpc3RlbnRseSB3aXRoIHRoZSByZXN0IG9m IHRoZSBkb2N1bWVudCBhbmQgdXNpbmcgdGhlIHRlcm0gZGVmaW5lZCBpbiB0aGUgdGVybWlub2xv Z3ksIHRvIGF2b2lkIGNvbmZ1c2lvbnMuIFdlIGRpZCBtZWFuIOKAnGFwcGxpY2F0aW9uIHByb2Zp bGVz4oCdLCBhbmQgbm90IGFwcGxpY2F0aW9ucy48YnI+DQo8L3NwYW4+PGJyIGNsYXNzPSJudWxs Ij4NCjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICogU2Vj dGlvbiA0IC0gYXJlIHdlIHN0aWxsIHNwZWNpZnlpbmcgYSBncm91cCB0byBqb2luIG9yIGlzIHRo YXQgaW1wbGljaXQgaW48YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB0aGUgVVJMPyZuYnNwOyBUZWxsIG1lIGhvdyBpdCBpcyBzcGVjaWZpZWQ/PGJyIGNsYXNz PSJudWxsIj4NCiZndDsgPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgRlA6IEl04oCZcyBzcGVjaWZp ZWQgaW4gdGhlIOKAmHNjb3Bl4oCZIG9mIHRoZSBKb2luaW5nIFJlcXVlc3QsIGFzIHRoZSBncm91 cCBuYW1lIGluIHRoZTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IHNpbmdsZSBzY29wZV9lbnRyeSBm b3IgdGhhdCBKb2luaW5nIFJlcXVlc3QuIEkgdGhpbmsgaXTigJlzIGdvb2Qgbm90IHRvIG1hbmRh dGU8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyB0aGF0IHRoZSBVUkkgcmVmbGVjdHMgdGhlIGdyb3Vw IG5hbWUgaW4gdGhlIHBhdGggKHRob3VnaCBpdCBtYWtlcyBzZW5zZSBhbmQgd2U8YnIgY2xhc3M9 Im51bGwiPg0KJmd0OyBkbyBpdCBpbiB0aGUgZXhhbXBsZXMpLjxiciBjbGFzcz0ibnVsbCI+DQo8 YnIgY2xhc3M9Im51bGwiPg0KW0pMU10gSSBkb24ndCBhZ3JlZS48L2Rpdj4NCjxkaXYgY2xhc3M9 Im51bGwiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVsbCI+RlA6Jm5ic3A7PHNwYW4+VGhp cyBjb21tZW50IGlzIHJlbGF0ZWQgdG8gdGhlIG9uZSBhYm92ZSB3aGVyZSB5b3Ugc2F5IGdyb3Vw IG5hbWUgc2hvdWxkIGJlIGEgdHN0ciB0byBtYXAgdG8gdGhlIFVSSS4gSSB0aG91Z2h0IHRoZSBm bGV4aWJpbGl0eSB3b3VsZCBiZSBnb29kIGFuZCB3b3VsZCBub3QgYWRkIG11Y2ggdG8gdGhlIGNv bXBsZXhpdHkgb2YgaW1wbGVtZW50YXRpb25zLiBJIG1pZ2h0IGJyaW5nIHRoaXMgdXAgaW4gdGhl DQogV0csIG1heWJlIHlvdSBjb3VsZCBleHBhbmQgb24gd2h5IHRoYXQgZmxleGliaWxpdHkgd291 bGQgYmUgYSBiYWQgaWRlYT88YnI+DQo8L3NwYW4+PGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFz cz0ibnVsbCI+DQomZ3Q7IDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICogU2VjdGlvbiA0IC0gSSBkb24ndCB0aGluayB0aGF0IHRoZSAocmUtKSBpcyBoZWxw aW5nIHVuZGVyc3RhbmRpbmcgaGVyZS48YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9 Im51bGwiPg0KJmd0OyBGUDombmJzcDsgVGhlIHBvaW50IHdlIHdlcmUgdHJ5aW5nIHRvIG1ha2Ug Y2xlYXIgd2l0aCB0aGF0IChyZS0pIGlzIHRoYXQgaXQgY2FuIGJlIHVzZWQ8YnIgY2xhc3M9Im51 bGwiPg0KJmd0OyB0byByZXRyaWV2ZSB0aG9zZSBzZXZlcmFsIGZvbGxvd2luZyB0aW1lcywgbm90 IG9ubHkgb25jZS4gQnV0IEkgZG9u4oCZdCBrbm93IGhvdyB0bzxiciBjbGFzcz0ibnVsbCI+DQom Z3Q7IGV4cHJlc3MgdGhhdCBjbGVhcmx5LCBhbmQgc2luY2UgdGhhdCBkb2VzIG5vdCBoZWxwIHVu ZGVyc3RhbmRpbmcgd2UgaGF2ZTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IHJlbW92ZWQgdGhlbS48 YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxsIj4NCltKTFNdIFN0aWxsIGFuZCBpbnN0 YW5jZSBpbiBzZWN0aW9uIDEuMSZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVsbCI+PGJyPg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj5GUDombmJzcDs8c3Bhbj5XaWxsIHJlbW92ZSBpdC48 YnI+DQo8L3NwYW4+PGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDxi ciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICogU2VjdGlvbiZu YnNwOyA0IC0gd2hhdCB0eXBlIG9mIGluZGl2aWR1YWwga2V5IGlzIGJlaW5nIG9idGFpbmVkIGlu IGJ1bGxldCAyIC08YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBob3cgaXMgdGhpcyBkaWZmZXJlbnQgdGhhbiBnZXR0aW5nIHRoZSBjdXJyZW50IGtleWluZyBt YXRlcmlhbD88YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBG UDogVGhlIGluZGl2aWR1YWwga2V5IGlzIHRoZSBlcXVpdmFsZW50IG9mIHRoZSBTZW5kZXIgS2V5 IGluIE9TQ09SRSAob3IgaW5wdXQ8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBtYXRlcmlhbCB0byBk ZXJpdmUgaXQsIGkuZS4gdGhlIFNlbmRlciBJRCksIHZzIHRoZSBncm91cCBrZXlpbmcgbWF0ZXJp YWwgc3VjaCBhczxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IHRoZSBtYXN0ZXIgc2VjcmV0LCBtYXN0 ZXIgc2FsdCwgY29udGV4dCBpZC4gVGhlIGRpZmZlcmVuY2UgaXMgdGhhdCB1c2luZyBidWxsZXQg MjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IG9ubHkgdGhlIHBlcnNvbmFsIG5vZGXigJlzIGtleWlu ZyBtYXRlcmlhbCBpcyB1cGRhdGVkLCBub3QgdGhlIGdyb3VwIGtleWluZzxiciBjbGFzcz0ibnVs bCI+DQomZ3Q7IG1hdGVyaWFsLiBXZeKAmWQgd2VsY29tZSBwcm9wb3NhbHMgb24gaG93IHRvIGNs YXJpZnkgaXQgd2l0aG91dCBnb2luZyBpbnRvPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgT1NDT1JF IGRldGFpbHMuPGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+DQpbSkxTXSBJcyB0 aGlzIHRyeWluZyB0byBzYXkgdGhhdCBhIG5ldyBjbGllbnRJZCBjYW4gYmUgaXNzdWVkIGFzIG9w cG9zZSB0byB0aGUgY3VycmVudCBzZXQgb2YgbWF0ZXJpYWw/Jm5ic3A7Jm5ic3A7IEkgd291bGQg dGhpbmsgdGhhdCB5b3UgYWx3YXlzIGdldCBtYXRlcmlhbCB0byBkZXJpdmUgaXQgYW5kIG5ldmVy IGRpcmVjdGx5IGdldCBhIGtleS48L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPjxicj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0ibnVsbCI+RlA6Jm5ic3A7PHNwYW4+Zm9yIE9TQ09SRSB5ZXMsIGJ1dCB3 ZSBkb27igJl0IGtub3cgdGhhdCB0aGlzIGluZGl2aWR1YWwga2V5IHdvdWxkIGFsd2F5cyBiZSBk ZXJpdmVkIGZyb20gYW4gaWRlbnRpZmllciBzdWNoIGFzIHRoZSBjbGllbnRJZCwgaGVuY2UgdGhl IOKAnG5ldyBpbnB1dCBtYXRlcmlhbCB0byBkZXJpdmUgaXTigJ0gdGVybWlub2xvZ3kgKHJhdGhl ciB0aGFuIENsaWVudCBJZGV0aWZpZXIpLiBXZSBjYW4gY2hhbmdlIHRoZQ0KIGJ1bGxldCBhcyBm b2xsb3dzOjxicj4NCk9MRDxicj4NCiogVGhlIENsaWVudCBjYW4gcmV0cmlldmUgYSBuZXcgaW5k aXZpZHVhbCBrZXksIG9yIG5ldyBpbnB1dDxicj4NCm1hdGVyaWFsIHRvIGRlcml2ZSBpdC4gVGhp cyBpcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjQuPGJyPg0KTkVXPGJyPg0KKiBUaGUgQ2xpZW50 IGNhbiByZXRyaWV2ZSBuZXcgaW5wdXQ8YnI+DQptYXRlcmlhbCB0byBkZXJpdmUgYSBuZXcgaW5k aXZpZHVhbCBrZXkuIFRoaXMgaXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC40Ljxicj4NCjxicj4N CkJ1dCBzdGlsbCBkb27igJl0IHNlZSBob3cgdG8gY2xhcmlmeSB3aGF0IGFuIOKAnGluZGl2aWR1 YWwga2V54oCdIGlzIHdpdGhvdXQgZ29pbmcgaW50byBkZXRhaWxzIHRoYXQgZG9u4oCZdCBiZWxv bmcgaGVyZS48YnI+DQo8L3NwYW4+PGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+ DQomZ3Q7IDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICog U2VjdGlvbiA0LjEgLSBUaGUgYnVsbGV0IGZvciAvYWNlLWdyb3VwIHNlZW1zIHRvIGluZGljYXRl IHRoYXQgdGhlIG5hbWUgaXM8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBmaXhlZCB3aGljaCBpcyB0aGUgb3Bwb3NpdGUgb2Ygd2hhdCB0aGUgcHJldmlvdXMg cGFyYWdyYXBoIHNheXMuJm5ic3A7IEkgZmluZDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoaXMgY29uZnVzaW5nLiZuYnNwOyBJIHJlYWxseSBmaW5kIGl0 IGNvbmZ1c2luZyB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgc3BlY2lmeWluZzxiciBjbGFzcz0ibnVs bCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGEgdXJsLXBhdGggbmFtZSBpcyBiZWlu ZyBzcGVjaWZpZWQsIGFuZCB0aGUgb3Njb3JlIGRvY3VtZW50IGltbWVkaWF0ZWx5PGJyIGNsYXNz PSJudWxsIj4NCiZndDsgdXNlczxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGEgZGlmZmVyZW50IHZhbHVlLjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDxiciBj bGFzcz0ibnVsbCI+DQomZ3Q7IEZQOiZuYnNwOyBUaGUgcGFydCBhYm91dCDigJxmaXhlZOKAnSB3 YXMgbWVhbnQgdG8gc2F5IHRoYXQgb25jZSBkZWZpbmVkIGl0IHdpbGwgbm90PGJyIGNsYXNzPSJu dWxsIj4NCiZndDsgY2hhbmdlLCB3aGF0ZXZlciB0aGUgYXBwbGljYXRpb24gcHJvZmlsZXMgZGVm aW5lIHRvIHVzZSwgZWl0aGVyIHRoZSBkZWZhdWx0IG9yPGJyIGNsYXNzPSJudWxsIj4NCiZndDsg b3RoZXIsIG9wcG9zZWQgdG8gdGhlIC9hY2UtZ3JvdXAvR1JPVVBOQU1FIGZvciBleGFtcGxlLCB3 aGljaCBoYXZlIGE8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyB2YXJpYWJsZSBwYXJ0LiBTaW5jZSB0 aGF0IHdhcyBub3QgY2xlYXIsIGFuZCBub3QgdG8gbWFrZSBpdCBpbmNvbnNpc3RlbnQsIHdlIGhh dmU8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyByZW1vdmVkIHRoZSB0ZXJtIGZpeGVkLjxiciBjbGFz cz0ibnVsbCI+DQomZ3Q7IEFib3V0IE9TQ09SRSB1c2luZyBhIGRpZmZlcmVudCByZXNvdXJjZSBu YW1lOiBzaG91bGQgd2UgdGhlbiBzcGVjaWZ5IGFzIGE8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBy ZXF1aXJlbWVudCB0aGF0IHRoZSBwcm9maWxlcyBNVVNUIHNldCB0aGUgcm9vdCB1cmktcGF0aCwg cmF0aGVyIHRoYW4gcHJvdmlkaW5nPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgYSBkZWZhdWx0Pzxi ciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KW0pMU10gVGhhdCB3b3VsZCBtYWtl IG1vcmUgc2Vuc2UgdG8gbWUuJm5ic3A7IEkgYW0gbm90IHN1cmUgd2h5IHlvdSBjYXJlIGFib3V0 IGdldHRpbmcgYSBuZXcgcm9vdCBob3dldmVyIGFzIGEgc2luZ2xlIHJvb3QgY291bGQsIGluIHRo ZW9yeSBzdXBwb3J0IG11bHRpcGxlIEtEQyBwcm9maWxlcy48L2Rpdj4NCjxkaXYgY2xhc3M9Im51 bGwiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVsbCI+RlA6Jm5ic3A7PHNwYW4+U2F5IHlv dSBoYXZlIGJvdGggYWNlIGtleSBncm91cGNvbW0gT1NDT1JFIGFuZCBwdWJzdWIgYXBwbGljYXRp b24gcHJvZmlsZXMgaW1wbGVtZW50ZWQgb24gdGhlIHNhbWUgS0RDLiBFaXRoZXIgdGhlIEtEQyBr bm93cyB3aGF0IHRvIHJldHVybiBiYXNlZCBvbiB0aGUgVVJpIHJvb3QgKOKAnGdyb3VwLW9zY29y ZeKAnSB2cyBzb21ldGhpbmcgbGlrZSDigJxwdWJzdWLigJ0pLCBvciBpdCBuZWVkcyB0byBoYXZl IHRoZQ0KIGluZm9ybWF0aW9uIGFib3V0IHdoYXQgcHJvZmlsZSBpdCBpcyB0b2dldGhlciB3aXRo IHRoZSBncm91cCBrZXlpbmcgbWF0ZXJpYWwuIFJpZ2h0IG5vdyBvdXIgZG9jdW1lbnQgZG9lcyB0 aGUgZmlyc3QgYW5kIG5vdCB0aGUgc2Vjb25kLiBBcmUgeW91IHNheWluZyB5b3Ugd291bGQgbGlr ZSB1cyB0byBjaGFuZ2UgdGhhdD8gT3IgYWxsb3cgYm90aD8gVGhpcyBpcyBhbHNvIHNvbWV0aGlu ZyBJIHdvdWxkIGJyaW5nIHRvIHRoZSBXRyB0byBkaXNjdXNzLjxicj4NCjwvc3Bhbj48YnIgY2xh c3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgPGJyIGNsYXNzPSJudWxsIj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiBTZWN0aW9uIDQuMSAtIHdoYXQgZG9lcyBpdCBt ZWFuIGZvciBhIHN1Yi1yZXNvdXJjZSB0byBiZSAmcXVvdDtmaXhlZCZxdW90Oy4mbmJzcDsgRG9l czxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgbWVh biBpdCBuZXZlciBjaGFuZ2VzPzxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDxiciBjbGFzcz0ibnVs bCI+DQomZ3Q7IEZQOiBTZWUgcHJldmlvdXMgYW5zd2VyLiBZZXMgaXQgbWVhbnMgdGhhdCBvbmNl IGRlZmluZWQgaXQgZG9lcyBub3QgY2hhbmdlPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgZGVwZW5k aW5nIG9uIG90aGVyIHBhcmFtZXRlcnMgKHN1Y2ggYXMgR1JPVVBOQU1FIG9yIE5PREVOQU1FKS4g V2U8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBoYXZlIHJlbW92ZWQgaXQgbm93IGFzIGl0IHdhcyBu b3QgY2xlYXIuPGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+DQpbSkxTXSBUaGUg dGVybSBub3JtYWxseSB1c2VkIGlzICZxdW90O2ludmFyaWFudCBvbmNlIGVzdGFibGlzaGVkJnF1 b3Q7IGZvciB0aGF0IHR5cGUgb2YgbWVhbmluZy4mbmJzcDsgRml4ZWQgd291bGQgc2VlbSB0byBp bXBseSB0aGF0IGl0IGlzIGZpeGVkIHByaW9yIHRvIHRoYXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSJu dWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPkZQOiBUPHNwYW4+aGFua3MhIFdp bGwgY2hhbmdlLjwvc3Bhbj48YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxsIj4NCiZn dDsgPGJyIGNsYXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiBTZWN0 aW9uIDQuMSAtIFllcyBidXQgd2hhdCBpcyBhIE5PREVOQU1FIGFuZCB3aHkgZG8gSSBjYXJlIGFi b3V0IGl0PzxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IEZQ OiBIb3BlZnVsbHkgYWRkaW5nIHRoZSBmb2xsb3dpbmcg4oCcRWFjaCByZXNvdXJjZSBjb250YWlu cyB0aGUgaW5kaXZpZHVhbDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IGtleWluZyBtYXRlcmlhbCBm b3IgdGhhdCBub2RlLiDigJwgZ2l2ZXMgYW4gaW50dWl0aW9uIHdoeSB0aGUgTk9ERU5BTUUgaXMg dXNlZC48YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBUaGUgZmFjdCB0aGF0IGl0IGlzIGEgbm9kZSBp ZGVudGlmaWVyIHNob3VsZCBiZSBjbGVhciBieSB0aGUgZm9sbG93aW5nIHNlbnRlbmNlOiDigJw8 YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBUaGVzZSByZXNvdXJjZXMgYXJlIGlkZW50aWZpZWQgYnkg dGhlIG5vZGUgbmFtZSAoaW4gdGhpcyBleGFtcGxlLCB0aGUgbm9kZTxiciBjbGFzcz0ibnVsbCI+ DQomZ3Q7IG5hbWUgaGFzIHZhbHVlICZxdW90O05PREVOQU1FJnF1b3Q7KeKAnSBNb3JlIGRldGFp bHMgYWJvdXQgaG93IHByZWNpc2VseSBOT0RFTkFNRTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IGlz IHVzZWQgdG8gdmVyaWZ5IHRoZSByZXF1ZXN0IGFyZSBnaXZlbiBpbiA0LjEuMi4xLCBidXQgd2Ug b25seSB3YW50IHRvIHRhbGsgYWJvdXQ8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBpdCBoaWdoIGxl dmVsIGhlcmUuPGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+DQpbSkxTXSBUaGlz IGlzIHRoZSBmaXJzdCB0aW1lIHRoYXQgSSBoYXZlIHNlZW4gdGhlIHRlcm0gaW4gdGhlIGRvY3Vt ZW50LiZuYnNwOyBVc2luZyBpdCB3aXRob3V0IGFueSB0eXBlIG9mIGRlZmluaXRpb24gaXMgbm90 IHZlcnkgdXNlZnVsLiZuYnNwOyBFdmVuIGRlZmluaW5nIGl0IGluIHRoZSB0ZXJtaW5vbG9neSBz ZWN0aW9uIHdvdWxkIGJlIGhlbHBmdWwuPGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVs bCI+DQpGUDombmJzcDs8c3Bhbj5Paywgd2Ugd2lsbCBhZGQgaXQgdG8gdGhlIHRlcm1pbm9sb2d5 IHNlY3Rpb24uPGJyPg0KPC9zcGFuPjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDxiciBjbGFzcz0i bnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICogU2VjdGlvbiA0LjEuMi4xIC0g SXQgd291bGQgYmUgdXNlZnVsIGluIHRoZSBmaXJzdCBwYXJhZ3JhcGggdG8gcmUtaXRlcmF0ZTxi ciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgdGhpcyBp cyB0aGUgJnF1b3Q7am9pbiZxdW90OyBvcGVyYXRpb24mbmJzcDsgVGhlIGN1cnJlbnQgZGVzY3Jp cHRpb24gc2VlbXMgdG8gYmU8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyByZWFsbHkgb2RkLjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDxiciBjbGFzcz0ibnVs bCI+DQomZ3Q7IEZQOiBPaywgSSBhZGRlZCBhIG5vdGUgYWJvdXQgdGhhdC4gVGhlIGlkZWEgd2Fz IHRoYXQgdGhpcyBzZWN0aW9uIGlzIHJlYWxseSBhYm91dDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7 IHRoZSBoYW5kbGVyLCBhbmQgdGhlIGpvaW5pbmcgaXMgZGVzY3JpYmVkIHVzaW5nIHRoaXMgaGFu ZGxlciBsYXRlciBvbiwgaW4gc2VjdGlvbjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDQuMi48YnIg Y2xhc3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxsIj4NCltKTFNdIFllcyB0aGF0IGlzIHRoZSBz b3J0IG9mIHRoaW5nIEkgd2FzIGxvb2tpbmcgZm9yLiZuYnNwOyBHZXR0aW5nIGEgY29ycmVzcG9u ZGVuY2UgYmV0d2VlbiB0aGUgcmVzb3VyY2VzIGFuZCB0aGUgb3BlcmF0aW9ucyBpcyBhbHdheXMg aGVscGZ1bC48L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0ibnVsbCI+RlA6Jm5ic3A7PHNwYW4+T2ssIHRoYW5rcyBmb3IgY29uZmlybWluZy48YnI+DQo8 L3NwYW4+PGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDxiciBjbGFz cz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICogU2VjdGlvbiA0LjEuMi4x IC0gZ2V0X3B1Yl9rZXlzIC0gT25lIGNvbnNpZGVyYXRpb24gdGhhdCBuZWVkcyB0byBiZTxiciBj bGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGhpZ2hsaWdodGVkIGZv ciBhIGNvbnN0cmFpbmVkIGRldmljZSBpcyB0aGF0IHRoaXMgbWF5IHJlc3VsdCBpbiBhIGxhcmdl PGJyIGNsYXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcmV0dXJuIHZh bHVlIGFuZCBpdCBtYXkgYmUgYmV0dGVyIHRvIGdldCB0aGVtIG9ubHkgYXMgbmVlZGVkLjxiciBj bGFzcz0ibnVsbCI+DQomZ3Q7IDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IEZQOiBPaywgYWRkZWQg dGhlIGZvbGxvd2luZyBzZW50ZW5jZTog4oCcTm90ZSB0aGF0IGluY2x1ZGluZyB0aGlzIHBhcmFt ZXRlciBtYXk8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyByZXN1bHQgaW4gYSBsYXJnZSBtZXNzYWdl IHNpemUgZm9yIHRoZSBmb2xsb3dpbmcgcmVzcG9uc2UsIHdoaWNoIGNhbiBiZTxiciBjbGFzcz0i bnVsbCI+DQomZ3Q7IGluY29udmVuaWVudCBmb3IgcmVzb3VyY2UtY29uc3RyYWluZWQgZGV2aWNl cy7igJ0gQW55dGhpbmcgbW9yZSB3ZSBuZWVkIHRvPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgYWRk PzxiciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KW0pMU10gSSBkb24ndCB0aGlu ayBzby4mbmJzcDsgVGhlIGRldGFpbHMgb24gYmxvY2t3aXNlIGFuZCBFVGFnIHNob3VsZCBiZSBj bGVhciBhbHJlYWR5LjxiciBjbGFzcz0ibnVsbCI+DQo8YnI+DQpGUDombmJzcDs8c3Bhbj5Hb29k LCB0aGFua3MuPGJyPg0KPC9zcGFuPjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDxiciBjbGFzcz0i bnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICogU2VjdGlvbiA0LjEuMi4xIC0g J2NvbmNlJyB3aHkgYm90aGVyIHBvaW50aW5nIHRvIEFDRSBmb3IgYSBkZXNjcmlwdGlvbiBvZjxi ciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoaXMgZG9jdW1l bnQuJm5ic3A7IFRoaXMgaXMgbm90IGEgZnJhbWV3b3JrIG1lc3NhZ2Ugc28gSSBhbSBub3Qgc3Vy ZSB3aHkgdGhpcyBpczxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGludGVyZXN0aW5nLjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDxiciBjbGFzcz0ibnVsbCI+ DQomZ3Q7IEZQOiBXZSBkbyB0aGF0IHRvIHBvaW50IHRoZSByZWFkZXIgb24gd2hlcmUgdG8gZmlu ZCB0aGUgZW5jb2RpbmcgKHdoaWNoIGlzIHRoZTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IHNhbWUg YXMgaW4gQWNlKS48YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxsIj4NCltKTFNdIE9r IC0gdGhhdCBzZWVtcyBhIGJpdCBvZGQgYmVjYXVzZSB0aGlzIGlzIG5vdCB0aGUgc2FtZSBtZWRp YS10eXBlLjwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVsbCI+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSJudWxsIj5GUDombmJzcDs8c3Bhbj5UaGF04oCZcyByaWdodC4gV2UgY291bGQganVzdCByZXBl YXQgdGhlIGVuY29kaW5nLCBidXQgd2UgdGhvdWdodCBpdCB3YXMgZ29vZCB0byBtYWtlIHRoZSBw YXJhbGxlbC48YnI+DQo8L3NwYW4+PGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+ DQomZ3Q7IDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICog U2VjdGlvbiA0LjEuMi4xIC0gV2hpY2ggc2NvcGUgaXMgYmVpbmcgdXNlZCwgdGhlIG9uZSBpbiB0 aGlzIG1lc3NhZ2U8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAoYXNzdW1pbmcgaXQgZXhpc3RzKSBvciB0aGUgb25lIGluIHRoZSB0b2tlbj8mbmJzcDsgSWYg dGhlIG1lc3NhZ2UgZG9lcyBub3QgaGF2ZTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IG9uZSB0aGVuIHdoYXQgaGFwcGVucz8mbmJzcDsgRGV0ZXJtaW5pc3Rp YyBlbmNvZGluZz88YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0 OyBGUDogQnkg4oCcdXNlZOKAnSBJIGFzc3VtZSB5b3UgbWVhbiBieSB0aGUgS0RDPyBUaGUgS0RD IGV4dHJhY3QgdGhlIGdyYW50ZWQ8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBzY29wZSBmcm9tIHRo ZSBUb2tlbiwgYW5kIGNoZWNrcyB0aGlzIHJlcXVlc3RlZCBvbmUgYWdhaW5zdCB0aGUgdG9rZW4g b25lLiBJZjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IHRoaXMgam9pbiBtZXNzYWdlIGRvZXMgbm90 IGhhdmUgb25lIHdlIGFyZSBpbiB0aGUgY2FzZSB3aGVyZSB0aGUgS0RDPGJyIGNsYXNzPSJudWxs Ij4NCiZndDsgdW5kZXJzdGFuZHMgd2hpY2ggZ3JvdXAgYW5kIHJvbGUgdGhlIENsaWVudCBpcyBy ZXF1ZXN0aW5nIChzYXkgdGhlcmUgaXMgb25seSBvbmU8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyB0 aGF0IHRoZSBjbGllbnQgaGFzIGJlZW4gZ3JhbnRlZCkuIFdoYXQgYXJlIHdlIG1pc3Npbmc/PGJy IGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+DQpbSkxTXSBUaGF0IGV4cGxhbmF0aW9u PC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwi PkZQOiZuYnNwOzxzcGFuPllvdSBhcmUgcmlnaHQsIHRoYXQgaXMgbWlzc2luZy4gV2Ugd2lsbCBj bGFyaWZ5Ljxicj4NCjwvc3Bhbj48YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxsIj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiBTZWN0aW9uIDQuMS4yLjEgLSBib3RoIGJ1 bGxldHMgYXJlIHRhbGtpbmcgYWJvdXQgZmFpbGVkIHZlcmlmaWNhdGlvbiAtPGJyIGNsYXNzPSJu dWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsga2lsbCB0aGUgcmVkdW5kYW5jeS48 YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBGUDogWWVzLCBi dXQgdGhlIGVycm9yIHByb2Nlc3NpbmcgaXMgZGlmZmVyZW50IGluIHRoZSAyIGJ1bGxldHM6IGlu IGNhc2UgdGhlPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgdmVyaWZpY2F0aW9uIGZhaWxzIGJlY2F1 c2UgY2xpZW50X2NyZWRfdmVyaWZ5IGZhaWxzLCB3ZSBzcGVjaWZ5IHdoYXQgdGhlIGhhbmRsZXI8 YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBuZWVkcyB0byBkbyB3aXRoIHJlZ2FyZCB0byB0aGUga2Rj Y2hhbGxlbmdlLiBTbyBpdCBpcyBub3QgcmVhbGx5IHJlZHVuZGFudC4gV2U8YnIgY2xhc3M9Im51 bGwiPg0KJmd0OyBoYXZlbuKAmXQgbWFkZSBhbnkgY2hhbmdlcywgYnV0IHBsZWFzZSBsZXQgdXMg a25vdyBpZiB5b3UgaGF2ZSBpZGVhcyBvbiBob3cgdG88YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBp bXByb3ZlLjxiciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KW0pMU10gQnV0IEkg ZG9uJ3Qgc2VlIGFueSByZWFzb24gd2h5IEkgY291bGQgbm90IHJldHVybiBhIHBheWxvYWQgdy8g YSBuZXcga2RjY2hhbGxlbmdlIGluIHRoZSBmaXJzdCBjYXNlIGFzIHdlbGwuPC9kaXY+DQo8ZGl2 IGNsYXNzPSJudWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPkZQOiZuYnNwOzxz cGFuPk9rLCBhbHRob3VnaCBpdCBpcyBub3QgbmVjZXNzYXJpbHkgbmVlZGVkLCBpZiB0aGUgc2lt cGxpZmljYXRpb24gaGVscHMsIHdlIGNhbiBtYWtlIHRoZSBjaGFuZ2UuPGJyPg0KPC9zcGFuPjxi ciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwi Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqIFNlY3Rpb24gNC4xLjIuMSAtICdudW0n IHRoZSBydWxlIG9uIHRoZSBpbml0aWFsIHZhbHVlIG9mIG51bSBzaG91bGQgYmUgcHV0PGJyIGNs YXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaW50byBhIHNlY3Rpb24g YWJvdXQgc2V0dGluZyB1cCBhIGdyb3VwIG5vdCBoZXJlLjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7 IDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IEZQOiBPaywgd2UgaGF2ZSBhZGRlZCBhIHJlcXVpcmVt ZW50IHRoYXQgaXQgaXMgdXAgdG8gdGhlIGFwcGxpY2F0aW9uIHByb2ZpbGUgdG88YnIgY2xhc3M9 Im51bGwiPg0KJmd0OyBzcGVjaWZ5IHdoYXQgdGhlIGluaXRpYWwgdmFsdWUgc2hvdWxkIGJlLiBG b3IgT1NDT1JFLCB0aGlzIGNhbiBiZSBkZWZpbmVkIGluPGJyIGNsYXNzPSJudWxsIj4NCiZndDsg ZHJhZnQtdGlsb2NhLWFjZS1vc2NvcmUtZ20tYWRtaW4gYW5kIHJlZmVyZW5jZWQgaW4gdGhlIHBy b2ZpbGUuPGJyIGNsYXNzPSJudWxsIj4NCltKTFNdIERvIHlvdSB3YW50IGEgbm9ybWF0aXZlIHJl ZmVyZW5jZSB0byB0aGUgYWRtaW4gZG9jdW1lbnQ/PC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj48 YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPkZQOiZuYnNwOzxzcGFuPk5vLCBJIHRoaW5r IHdlIGRvbuKAmXQgbmVlZCBpdC4gV2UgZ2l2ZSBpdCBhcyBhbiBleGFtcGxlLjxicj4NCjwvc3Bh bj48YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgKiBTZWN0aW9uIDQuMS4yLjEgLSBleHBfZGVsdGEgc2hvdWxkIHNwZWNpZnkg YSBkZWZhdWx0IGlmIGl0IGlzIG5vdCBpbiB0aGU8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBtZXNzYWdlLiZuYnNwOyBJIHRoZXJlIGEgcmVhc29uIHRoYXQg dGhpcyBpcyBub3QgYSBwb2xpY3kgZm9yIHRoZSBncm91cD88YnIgY2xhc3M9Im51bGwiPg0KJmd0 OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBGUDogT2ssIHdlIGhhdmUgbW92ZWQgdGhpcyB0byB0 aGUgcG9saWNpZXMuIEl0IGlzIHdvcnRoIG5vdGluZyB0aG91Z2ggdGhhdCB0aGU8YnIgY2xhc3M9 Im51bGwiPg0KJmd0OyBncm91cF9wb2xpY2llcyBwYXJhbWV0ZXIgaXMgb3B0aW9uYWwgKG1lYW5p bmcgdGhlIEtEQyBtaWdodCBub3Qgc2VuZCB0aGlzIGluZm88YnIgY2xhc3M9Im51bGwiPg0KJmd0 OyBpbiB0aGUgbWVzc2FnZSksIHdlIGhhdmUgZXhwbGljaXRseSBhZGRlZCB0aGF0IHRoZSBkZWZh dWx0IHZhbHVlcyBNVVNUIGJlPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgc3BlY2lmaWVkIGJ5IHRo ZSBhcHBsaWNhdGlvbiBwcm9maWxlcy48YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxs Ij4NCltKTFNdIFllcywgYnV0IHlvdSB3b3VsZCB1c2UgYW4gZXhwX2RlbHRhIG9mIDAgaWYgeW91 IGRpZCBub3QgcmV0cmlldmUgaXQgZnJvbSB0aGUgcG9saWN5LjwvZGl2Pg0KPGRpdiBjbGFzcz0i bnVsbCI+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj5GUDombmJzcDs8c3Bhbj5Obywg eW91IHdvdWxkIHVzZSB3aGF0ZXZlciBkZWZhdWx0IHRoZSBhcHBsaWNhdGlvbiBwcm9maWxlcyBz cGVjaWZpZXMuIEl0IGlzIFJFUVVJUkVEIG9mIGFwcGxpY2F0aW9uIHByb2ZpbGVzIHRvIHNwZWNp Znkgd2hhdCBpcyB0aGUgZGVmYXVsdCB2YWx1ZSBvZiBpdOKAmXMgbm90IHNlbnQuPC9zcGFuPjxi ciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAqIFNlY3Rpb24gNC4xLjIuMiAtIEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUgbmVlZCBm b3IgJ2drdHknIGFzIHRoYXQgSSBzaG91bGQ8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBrbm93IGZyb20gdGhlIGpvaW4gYW5kIGl0IHNob3VsZCBuZXZlciBj aGFuZ2UgaW4gdGhlIGxpZmUgb2YgdGhlIGdyb3VwLiZuYnNwOyBJPGJyIGNsYXNzPSJudWxsIj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd291bGQgYWxzbyBleHBlY3QgdGhhdCAnZXhw JyBpcyBzb21ldGhpbmcgdGhhdCBhdCBsZWFzdCBTSE9VTEQgYmUgaW5jbHVkZWQ8YnIgY2xhc3M9 Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhcyB0aGF0IGRvZXMgY2hhbmdl IGFuZCBpcyB1c2VmdWwgdG8gaGF2ZS48YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9 Im51bGwiPg0KJmd0OyBGUDogT2sgZm9yIGV4cCwgd2UgY2hhbmdlZCBpdCB0byBTSE9VTEQuIEFi b3V0IGdrdHkgaW4gdGhlIEdFVCByZXNwb25zZSwgaXQ8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBh bGxvd3MgYSBub2RlIGFjdGluZyBhcyDigJxtb25pdG9y4oCdIHRvIG9ubHkgcmVxdWVzdCB0aGUg Z3JvdXAga2V5IGFuZCBnZXQgYWxsIHRoZTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IGluZm9ybWF0 aW9uIGl0IG5lZWRzIHdpdGhvdXQgbmVlZGluZyB0byBkbyB0aGUgZnVsbCBQT1NULCBlc3BlY2lh bGx5IGlmIHRoZSBLREM8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBtYWludGFpbnMgdGhlIHB1YiBr ZXlzIGFuZCB3b3VsZCBmYWlsIGl0cyByZXF1ZXN0IGlmIGl0IGRvZXMgbm90IGNvbnRhaW4gYSBw dWI8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBrZXkuIFdlIGNvdWxkIG1ha2UgZ2t0eSBvcHRpb25h bCBpbiB0aGUgcmVzcG9uc2UgdG8gR0VULCBidXQgSSB0aGluayB0aGF0IHdvdWxkPGJyIGNsYXNz PSJudWxsIj4NCiZndDsganVzdCBiZSBtb3JlIGNvbXBsaWNhdGVkICh3aGVuIGRvZXMgdGhlIEtE QyBzZW5kcyBpdD8gV2hlbiBub3Q/KSBJIGRvbuKAmXQ8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyB0 aGluayB0aGUgc2F2aW5nIDIgYnl0ZXMgaXMgbW90aXZhdGlvbiBlbm91Z2ggZm9yIHJlbW92aW5n IGl0LCBnaXZlbiB0aGF0IHdlPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgaGF2ZSBhIHJlYXNvbiBm b3IgaGF2aW5nIGl0LjxiciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KW0pMU10g SSB0aGluayB0aGF0IGlzIHByb2JhYmx5IHJlYXNvbmFibGUuPC9kaXY+DQo8ZGl2IGNsYXNzPSJu dWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPkZQOiZuYnNwOzxzcGFuPk9rLCBz byB3ZSB3b27igJl0IGRvIGFueSBjaGFuZ2UgaGVyZS48L3NwYW4+PGJyIGNsYXNzPSJudWxsIj4N CjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICogU2VjdGlv biA0LjEuMy4xIC0gVGhlIHRleHQgb24gdGhlIGZpcnN0IHNlbGVjdGlvbiBjcml0ZXJpYSBoYXMg bWUgcmVhbGx5PGJyIGNsYXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg bWVzc2VkIHVwIGJlY2F1c2UgSSBhbSBub3Qgc3VyZSB0aGF0PGJyIGNsYXNzPSJudWxsIj4NCiZn dDsgPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgRlA6IEJyb2tlbiBjb21tZW50LiBCdXQgd2UgaGF2 ZSBhc3N1bWVkIHRoaXMgd2FzIGFib3V0IHRoZSBwYXJlbnRoZXNpczxiciBjbGFzcz0ibnVsbCI+ DQomZ3Q7IChpbmNsdWRpbmcgdGhlIGV4YWN0IGNvbWJpbmF0aW9uIG9mIHJvbGVzIHJlcXVlc3Rl ZCkgYW5kIGhhdmUgdHJpZWQgdG8gcmVwaHJhc2U8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyB0byBj bGFyaWZ5LjxiciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KSSBhbSBub3Qgc3Vy ZSB3aGF0IHRoZSBtYXRjaGluZyBydWxlcyBhcmUgc3VwcG9zZWQgdG8gYmUgZm9yIHJvbGUgaWRl bnRpZmllcnMuJm5ic3A7Jm5ic3A7IEl0IGxvb2tzIGxpa2UgdGhpcyBtaWdodCBoYXZlIGJlZW4g Y2xhcmlmaWVkPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9Im51bGwiPkZQOiZuYnNwOzxzcGFuPkdvb2QuPGJyPg0KPC9zcGFuPjxiciBjbGFzcz0ibnVs bCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqIFNl Y3Rpb24gNC4xLjYuMSAtIEkgaGF2ZSBubyBpZGVhIGZyb20gdGhlIHRleHQgd2h5IEkgd291bGQg dXNlIHRoaXM8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBt ZXRob2QuPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgRlA6 IEl04oCZcyBkaWZmaWN1bHQgdG8gZ2l2ZSBhIGNsZWFyZXIgaWRlYSBhdm9pZGluZyBwcm9maWxl LXNwZWNpZmljIGRldGFpbHMuIFdvdWxkIGl0PGJyIGNsYXNzPSJudWxsIj4NCiZndDsgaGVscCB0 byBoYXZlIGFuIGluZm9ybWF0aW9uYWwgcmVmZXJlbmNlIHRvIGtleSBncm91cGNvbW0gb3Njb3Jl IHRvIGdpdmUgYW48YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBleGFtcGxlPyAoSeKAmWQgcmF0aGVy IGF2b2lkIHRoZSBjaXJjdWxhciBkZXBlbmRlbmN5LCBzbyBpZiB5b3UgaGF2ZSBvdGhlciBpZGVh czxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IG9uIGhvdyB0byBpbXByb3ZlLCBJ4oCZbGwgdGFrZSB0 aGVtKS48YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxsIj4NCltKTFNdIFRoaXMgaGFu ZGxlciBpcyB1c2VkIGJ5IGEgbm9kZSBlaXRoZXIgdG8gMSkgZ2V0IGEgbmV3IGlkZW50aWZpZXIg d2l0aGluIHRoZSBjdXJyZW50IGdyb3VwIG9yIDIpIGZvcmNlIGEgcmVrZXlpbmcgb2YgdGhlIGdy b3VwLiZuYnNwOyBUaGlzIGlzIG5vcm1hbGx5IGRvbmUgZHVlIHRvIHVzYWdlIGxpbWl0cyBvbiB0 aGUgQUVBRCBhbGdvcml0aG0uPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj48YnI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9Im51bGwiPkZQOiZuYnNwOzxzcGFuPlRoYW5rcyBmb3IgdGhlIHN1Z2dlc3Rp b24hIEFzIG1lbnRpb25lZCBhYm92ZSB0aG91Z2ggSSB3b3VsZCBub3QgdGFsayBhYm91dCBpZGVu dGlmaWVycywgdGhlIG1vcmUgcHJlY2lzZSB0ZXJtIHdvdWxkIGJlIOKAnGlucHV0IG1hdGVyaWFs IHRvIGdlbmVyYXRlIGFuIGluZGl2aWR1YWwga2V5IHRvIHByb3RlY3Qgb3V0Z29pbmcgbWVzc2Fn ZXPigJ0sIHdvdWxkIHRoYXQgYmUgb2s/IE9yIGlzIGl0IHN0aWxsDQogbm90IGNsZWFyIGVub3Vn aD88YnI+DQo8L3NwYW4+PGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7 IDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICogU2VjdGlv biA0LjEuNi4zIC0gcGFyYSAyIC0gdGhlIGZpcnN0IHNlbnRlbmNlIGRvZXMgbm90IG1ha2UgYW55 IHNlbnNlIHRvPGJyIGNsYXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg bWUuJm5ic3A7IEhvdyBjb3VsZCB0aGUgaGFuZGxlciBhY2NlcHQgYSByZXF1ZXN0IGZvciBhIG5v ZGUgZG9lcyBub3QgbWF0Y2g8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmcXVvdDtOT0RFTkFNRSZxdW90OyBhcyB0aGF0IGlzIHRoZSB1cmwtcGF0aD88YnIg Y2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBGUDogVGhlIHBvaW50 IGlzIHRoYXQgdGhlIEtEQyBNVVNUIE5PVCBhY2NlcHQgYSByZXF1ZXN0IGZyb20gYSBub2RlIE4x PGJyIGNsYXNzPSJudWxsIj4NCiZndDsgc2VuZGluZyBhIERFTEVURSB0byBhY2UtZ3JvdXAvR1JP VVBOQU1FL25vZGVzL04yLlRoZSBLREMgY2FuIGlkZW50aWZ5PGJyIGNsYXNzPSJudWxsIj4NCiZn dDsgdGhlIG5vZGUgbmFtZSBmcm9tIHRoZSBzZWN1cmUgc2Vzc2lvbiBpdCBoYXMgc2V0IHVwIHdp dGggaXQgKGl0IGhhcyBnaXZlbiB0aGU8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBub2RlIGEgbmFt ZSBhbmQgYXNzb2NpYXRlZCBpdCB0byB0aGUgc2VjdXJlIGNoYW5uZWwgb25jZSB0aGUgbm9kZSBo YXMgZG9uZTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IHRoZSBqb2luIHByb2Nlc3MpLiBXZSBoYXZl IHRyaWVkIHRvIHJlZm9ybXVsYXRlIHRvIGNsYXJpZnkuPGJyIGNsYXNzPSJudWxsIj4NCjxiciBj bGFzcz0ibnVsbCI+DQpbSkxTXSBUaGUgdGV4dCBpbiA0LjEuNi4yIHdhcyBjbGVhcmVyIGFib3V0 IHRoYXQuPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 Im51bGwiPkZQOiZuYnNwOzxzcGFuPk9rLCB3ZSB3aWxsIHJldmVydCB0byB0aGF0IGFuZCByZW1v dmUgdGhlIGZpcnN0IHBhcnQgb2YgdGhlIHBhcmFncmFwaCwgd2hpY2ggZG9lcyBub3Qgc2VlbSB0 byBoZWxwIGFueXdheTo8YnI+DQo8YnI+DQpPTEQ8YnI+DQpUaGUgaGFuZGxlciBvbmx5IGFjY2Vw dHMgYSByZXF1ZXN0IGZyb20gdGhlIG5vZGUgaWRlbnRpZmllZCBieTxicj4NCiZxdW90O05PREVO QU1FJnF1b3Q7IHZpYSB0aGUgc2VjdXJlIHNlc3Npb24sIHdoZXJlIE5PREVOQU1FIGlzIHVzZWQg aW4gVXJpLTxicj4NClBhdGgsIGFuZCB0aGF0IGlzIHBhcnQgb2YgdGhlICZxdW90O0dST1VQTkFN RSZxdW90OyBncm91cDogdGhlIGhhbmRsZXIgdmVyaWZpZXM8YnI+DQp0aGF0IHRoZSBncm91cCBu YW1lICZxdW90O0dST1VQTkFNRSZxdW90OyBpcyBhIHN1YnNldCBvZiB0aGUgJ3Njb3BlJyBzdG9y ZWQgaW48YnI+DQp0aGUgYWNjZXNzIHRva2VuIGFzc29jaWF0ZWQgdG8gdGhpcyBjbGllbnQsIGFu ZCB0aGF0IHRoaXMgY2xpZW50IGlzPGJyPg0KaWRlbnRpZmllZCBieSAmcXVvdDtOT0RFTkFNRSZx dW90Oy4gSWYgdmVyaWZpY2F0aW9uIGZhaWxzLCB0aGUgS0RDIE1VU1Q8YnI+DQpyZXNwb25kIHdp dGggYSA0LjAxIChVbmF1dGhvcml6ZWQpIGVycm9yIG1lc3NhZ2UuPGJyPg0KTkVXPGJyPg0KVGhl IGhhbmRsZXIgdmVyaWZpZXMgdGhhdCB0aGUgZ3JvdXAgbmFtZSBvZiB0aGUgL2FjZS1ncm91cC9H Uk9VUE5BTUU8YnI+DQpwYXRoIGlzIGEgc3Vic2V0IG9mIHRoZSAnc2NvcGUnIHN0b3JlZCBpbiB0 aGUgYWNjZXNzIHRva2VuIGFzc29jaWF0ZWQ8YnI+DQp0byB0aGlzIGNsaWVudCwgaWRlbnRpZmll ZCBieSAmcXVvdDtOT0RFTkFNRSZxdW90Oy4gSWYgdmVyaWZpY2F0aW9uIGZhaWxzLCB0aGU8YnI+ DQpLREMgTVVTVCByZXNwb25kIHdpdGggYSA0LjAxIChVbmF1dGhvcml6ZWQpIGVycm9yIG1lc3Nh Z2UuPGJyPg0KPC9zcGFuPjxiciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KJmd0 OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAqIFNlY3Rp b24gNC4yIC0gJnF1b3Q7cmV0cmlldmUgaW5kaXZpZHVhbCBvciBncm91cCBrZXlpbmcgbWF0ZXJp YWwmcXVvdDsmbmJzcDsgV2hhdDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IGluZGl2aWR1YWwgbWF0ZXJpYWw/PGJyIGNsYXNzPSJudWxsIj4NCiZndDsgPGJy IGNsYXNzPSJudWxsIj4NCiZndDsgRlA6IFNhbWUgYW5zd2VyIGFzIGJlZm9yZTogdGhpcyBjb3Vs ZCBiZSBmb3IgZXhhbXBsZSB0aGUgc2VuZGVyIElEIHRvIGRlcml2ZTxiciBjbGFzcz0ibnVsbCI+ DQomZ3Q7IHRoZSBTZW5kZXIgS2V5IGluIE9TQ09SRS4gSXTigJlzIGRpZmZpY3VsdCB0byBnaXZl IGEgY2xlYXJlciBpZGVhIGF2b2lkaW5nIHByb2ZpbGUtPGJyIGNsYXNzPSJudWxsIj4NCiZndDsg c3BlY2lmaWMgZGV0YWlscy4gV291bGQgaXQgaGVscCB0byBoYXZlIGFuIGluZm9ybWF0aW9uYWwg cmVmZXJlbmNlIHRvIGtleTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IGdyb3VwY29tbSBvc2NvcmUg dG8gZ2l2ZSBhbiBleGFtcGxlPyAoSeKAmWQgcmF0aGVyIGF2b2lkIHRoZSBjaXJjdWxhcjxiciBj bGFzcz0ibnVsbCI+DQomZ3Q7IGRlcGVuZGVuY3ksIHNvIGlmIHlvdSBoYXZlIG90aGVyIGlkZWFz IG9uIGhvdyB0byBpbXByb3ZlLCBJ4oCZbGwgdGFrZSB0aGVtKS48YnIgY2xhc3M9Im51bGwiPg0K PGJyIGNsYXNzPSJudWxsIj4NCltKTFNdIFJldHJpZXZlIGdyb3VwIGtleWluZyBtYXRlcmlhbCBm b3IgdGhlIGluZGl2aWR1YWw8L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPjxicj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0ibnVsbCI+RlA6Jm5ic3A7PHNwYW4+T2ssIEkgdGhpbmsgd2UgY2FuIHNpbXBs aWZ5IGhlcmUgYW5kIG5vdCB0YWxrIGFib3V0IHRoZSDigJxpbmRpdmlkdWFsIGtleWluZyBtYXRl cmlhbOKAnSBidXQgb25seSB0YWxrIGFib3V0IGdyb3VwIGtleWluZyBtYXRlcmlhbC48YnI+DQo8 L3NwYW4+PGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDxiciBjbGFz cz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICogU2VjdGlvbiA0LjMgLSBJ IGFtIHdvcnJpZWQgYWJvdXQgY29uZ2VzdGlvbiBpbiBtb3JlIHBsYWNlcyB0aGFuIGp1c3QgZm9y PGJyIGNsYXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgT2JzZXJ2ZS4m bmJzcDsgSWYgYSBzZXJ2ZXIgaXMgc2VuZGluZyBsb3RzIG9mIG1lc3NhZ2VzIG91dCB0byBjbGll bnRzIG9uIGE8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBv bmUtdG8tb25lIGJhc2lzIGl0IGNvdWxkIGVhc2lseSBmbG9vZCB0aGUgbmV0d29yay48YnIgY2xh c3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBGUDogV2UgaGFkIGFkZGVk IHNvbWUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYWJvdXQgaXQsIHJlZmVyZW5jaW5nIHRvIFNl Y3Rpb248YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA0Ljcgb2YgNzI1Mi4gTm93IHdlIGFkZGVkIHRo aXMgcmVmZXJlbmNlIGluIHRoaXMgc2VjdGlvbiBhcyB3ZWxsLiBJcyB0aGF0IGVub3VnaDxiciBj bGFzcz0ibnVsbCI+DQomZ3Q7IG9yIHdoYXQgaXMgbWlzc2luZz88YnIgY2xhc3M9Im51bGwiPg0K PGJyIGNsYXNzPSJudWxsIj4NCltKTFNdIEkgd291bGQgaGF2ZSBqdXN0IHB1dCB0aGUgdGV4dCBp bnRvIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBvciBuZXR3b3JrIGNvbnNpZGVyYXRpb25z IHNlY3Rpb25zIGFuZCBub3QgYm90aGVyZWQgdG8gaGF2ZSBpdCBoZXJlLiZuYnNwOyBObyBiaWcg ZGVhbDwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVsbCI+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJu dWxsIj5GUDombmJzcDs8c3Bhbj5XZSBoYWQgdGhvc2UgYWxyZWFkeSBpbnRvIHRoZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucywgYW5kIHdlIHRob3VnaHQgeW91IHdhbnRlZCBtb3JlIHRleHQgaGVy ZSBzcGVjaWZpY2FsbHkuIFdlIGNhbiByZW1vdmUgdGhlbSBmcm9tIGhlcmUsIGFzIHdlIGRvbuKA mXQgd2FudCBkdXBsaWNhdGUgdGV4dC48YnI+DQo8L3NwYW4+PGJyIGNsYXNzPSJudWxsIj4NCjxi ciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICogU2VjdGlvbiA0LjQgLSBXaGF0IGRvZXMgdGhlIGZpcnN0IHNlbnRlbmNl IGV2ZW4gbWVhbj8mbmJzcDsgSXQgc2VlbXMgdG8gYmU8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBhbG1vc3QgYSBjaXJjdWxhciBhcmd1bWVudC48YnIgY2xh c3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBGUDogVHJpZWQgcmVwaHJh c2luZyBhcyBmb2xsb3dzOiDigJxCZXNpZGUgcG9zc2libGUgZXhwaXJhdGlvbiwgdGhlIGNsaWVu dCBtYXk8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBuZWVkIHRvIGNvbW11bmljYXRlIHRvIHRoZSBL REMgaXRzIG5lZWQgZm9yIHBhcnQgb2YgdGhlIGtleWluZyBtYXRlcmlhbCB0byBiZTxiciBjbGFz cz0ibnVsbCI+DQomZ3Q7IHJlbmV3ZWQuIOKAnCBMZXQgdXMga25vdyBpZiB0aGlzIGlzIHN0aWxs IHVuY2xlYXIuPGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+DQpbSkxTXSBJIHdv dWxkIG5vdCBib3RoZXIgd2l0aCAncGFydCBvZicgQW5kIHB1dHRpbmcgaW4gdGV4dCBhYm91dCB3 aHkgdGhpcyBpcyBuZWVkZWQgKGkuZS4gQUVBRCBpbnRlZ3JpdHkvY29uZmlkZW50aWFsbHkgbGlt aXRzKSBpcyBnb2luZyB0byBtb3RpdmF0ZSB0aGluZ3MgYmV0dGVyLjwvZGl2Pg0KPGRpdiBjbGFz cz0ibnVsbCI+PGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj5GUDombmJzcDs8c3Bhbj5P aywgd2Ugd2lsbCBhZGQgc29tZXRoaW5nIGFib3V0IHRoYXQuPC9zcGFuPjxiciBjbGFzcz0ibnVs bCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAqIFNlY3Rpb24gNC40IC0gSSBmaW5kIHRoZSB0aXRsZSBvZiA0 LjQgdG8gYmUgc29tZXdoYXQgbWlzbGVhZGluZy4mbmJzcDsgQXMgZmFyPGJyIGNsYXNzPSJudWxs Ij4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYXMgSSBjYW4gdGVsbCB0aGlzIGlzIG9u bHkgdGFsa2luZyBhYm91dCBvbmUgdHlwZSBvZiByZW5ld2FsLCBidXQgZXZlbiB0aGF0PGJyIGNs YXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgaXMgbm90IGNsZWFyIHRv IG1lLjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IEZQOiBP aywgd2UgdHJpZWQgY2hhbmdpbmcgdG8g4oCcUmV0cmlldmFsIG9mIE5ldyBJbmRpdmlkdWFsIEtl eWluZyBNYXRlcmlhbOKAnSBJczxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IHRoaXMgYmV0dGVyPzxi ciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KW0pMU10gTm90IHJlYWxseSAtIHRo YXQgd291bGQgc2VlbSB0byBpbXBseSB0aGF0IEkgd291bGQgbm90IGdldCAmcXVvdDtuZXcmcXVv dDsgbWF0ZXJpYWwgaW4gc2VjdGlvbiA0LjMgZWl0aGVyLiZuYnNwOw0KPGJyIGNsYXNzPSJudWxs Ij4NCjQuMyAtIFJldHJpZXZhbCBvZiBrZXlpbmcgbWF0ZXJpYWw8YnIgY2xhc3M9Im51bGwiPg0K NC40IC0gUmVxdWVzdGluZyBhIGNoYW5nZSBvZiBrZXlpbmcgbWF0ZXJpYWw8L2Rpdj4NCjxkaXYg Y2xhc3M9Im51bGwiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVsbCI+RlA6Jm5ic3A7PHNw YW4+SSB3b3VsZCBiZSBhZ2FpbnN0IHJlbmFtaW5nIHNlY3Rpb24gNC40IHNvIGJlY2F1c2UgaXQg c2VlbXMgdG8gaW1wbHkgYSBncm91cCByZWtleSwgd2hpbGUgdGhhdCBpcyBub3Qgd2hhdCB0aGlz IGV4Y2hhbmdlIGlzLiBJIHRoaW5rIHdlIHN0aWxsIG5lZWQgc29tZXRoaW5nIGluIHRoZSB0aXRs ZSB3aXRoIOKAnGluZGl2aWR1YWzigJ0sIGFzIG9wcG9zZWQgdG8g4oCcZ3JvdXAga2V5aW5n4oCd Ljxicj4NCjwvc3Bhbj48YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxsIj4NCiZndDsg PGJyIGNsYXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiBTZWN0aW9u IDQuNSAtIElzIHRoZSBzZWNvbmQgcGFyYWdyYXBoIGluIHRoZSB3cm9uZyBwbGFjZT8mbmJzcDsg SSBkb24ndCByZWFsbHk8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBjYXJlIHdoYXQgdGhlIGNsaWVudCBkb2VzIG9ubHkgd2hhdCB0aGUgc2VydmVyIGRvZXMu PGJyIGNsYXNzPSJudWxsIj4NCiZndDsgPGJyIGNsYXNzPSJudWxsIj4NCiZndDsgRlA6IFdoeT8g SXQgaXMgaW1wb3J0YW50IHRoYXQgdGhlIGNsaWVudCBwcm9jZXNzZXMgdGhlIHJlc3BvbnNlIGNv cnJlY3RseS4gSXQ8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBtYWtlcyBzZW5zZSB0aGlzIHdvdWxk IG5vdCBiZSBpbiB0aGUg4oCcaGFuZGxlcuKAnSBzZWN0aW9uLCBidXQgaGVyZSB3ZSB0aGluayB3 ZTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IHNob3VsZCBoYXZlIHRoaXMgdHlwZSBvZiBkZXRhaWxz LiBXb3VsZCBpdCBiZSBiZXR0ZXIgdG8gaGF2ZSB0aGlzIHBhcmFncmFwaCBhZnRlcjxiciBjbGFz cz0ibnVsbCI+DQomZ3Q7IHRoZSBmaWd1cmU/PGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0i bnVsbCI+DQpbSkxTXSBXaGF0IGFib3V0IGEgY2xpZW50IHdoaWNoIHJldHJpZXZlcyB0aGUga2V5 LCB2ZXJpZmllcyB0aGUgb25lIHNpZ25hdHVyZSBhbmQgcHJvbXB0bHkgZm9yZ2V0cyB0aGUga2V5 IHcvbyBhbnkgbG9uZyB0ZXJtIHN0b3JhZ2U/Jm5ic3A7IEknbSBnb2luZyB0byBzbGVlcCBhbG1v c3QgaW1tZWRpYXRlbHkgYW5kIGl0IHdpbGwgaGF2ZSBwcm9iYWJseSBjaGFuZ2VkIGJ5IHRoZSB0 aW1lIEkgd2FrZSB1cCBhZ2Fpbi48L2Rpdj4NCjxkaXYgY2xhc3M9Im51bGwiPjxicj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0ibnVsbCI+RlA6Jm5ic3A7PHNwYW4+UmlnaHQsIHRoYXQgbWFrZXMgc2Vu c2UuIHdpbGwgcmVtb3ZlLjwvc3Bhbj48YnIgY2xhc3M9Im51bGwiPg0KPGJyIGNsYXNzPSJudWxs Ij4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKiBTZWN0aW9uIDUgLSBEb2VzIHRoZSB1 c2Ugb2YgdGhlIERFTEVURSBtZXRob2QgdG8gaW5mb3JtIGEgY2xpZW50IHRoYXQgaXQ8YnIgY2xh c3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpcyBubyBsb25nZXIgcGFy dCBvZiB0aGUgZ3JvdXAgaW1wbHkgdGhhdCBhIGRpZmZlcmVudCBjb250cm9sIHBhdGggaXMgbmVl ZGVkPGJyIGNsYXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZm9yIGV2 ZXJ5IGdyb3VwIHRoYXQgdGhlIGNsaWVudCBqb2lucz8mbmJzcDsgSSBkb24ndCBrbm93IHRoYXQg SSB3YXMgZXhwZWN0aW5nPGJyIGNsYXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgdGhhdC48YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0 OyBGUDogVGhhdOKAmXMgY29ycmVjdC4gQW4gYWx0ZXJuYXRpdmUgd291bGQgYmUgdGhhdCB0aGUg S0RDIHNlbmRzIGEgUE9TVCw8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBpbmRpY2F0aW5nIHRoZSBn cm91cCBuYW1lIGluIHRoZSBwYXlsb2FkLiBUaGlzIHdvdWxkIGJlIHNlbnQgdG8gYSBzaW5nbGU8 YnIgY2xhc3M9Im51bGwiPg0KJmd0OyByZXNvdXJjZSBvbiB0aGUgQ2xpZW50IHVzZWQgZm9yIGFu eSBqb2luZWQgZ3JvdXAgdW5kZXIgYW55IEtEQy4gV291bGQgeW91PGJyIGNsYXNzPSJudWxsIj4N CiZndDsgcHJlZmVyIHRoaXM/IChub3QgaW1wbGVtZW50ZWQgcmlnaHQgbm93KTxiciBjbGFzcz0i bnVsbCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KW0pMU10gSSBkb24ndCBrbm93LCBidXQgcHJvYmFi bHkgeWVzLjxiciBjbGFzcz0ibnVsbCI+DQo8YnI+DQpGUDombmJzcDs8c3Bhbj5Paywgd2UgY2Fu IG1ha2UgdGhpcyBjaGFuZ2UgZm9yIHRoZSBuZXh0IHVwZGF0ZS48YnI+DQo8L3NwYW4+PGJyIGNs YXNzPSJudWxsIj4NCiZndDsgPGJyIGNsYXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgU2VjdGlvbiA3IC0gLyBlbmQgb2YgdGhlIHJla2V5aW5nIHByb2Nlc3MgYW5kIHRo ZSBuZXh0IGxvc3Mgb2Ygc2VjdXJpdHk8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBzdGF0ZS8mbmJzcDsgVGhpcyBpcyBub3Qgd2hhdCBJIHdhcyB0cnlpbmcg dG8gZ2V0IGF0IGFuZCBpdCBtYWtlcyBubyBzZW5zZSB0byBtZS48YnIgY2xhc3M9Im51bGwiPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgcXVlc3Rpb24gaXMgdGhlIGludGVydmFs IGJldHdlZW4gdGhlIGVuZCBvZiB0aGUgbGFzdCByZWtleSBwcm9jZXNzIGFuZDxiciBjbGFzcz0i bnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSBjbGllbnQgam9pbmluZyB0 aGUgZ3JvdXAuJm5ic3A7IElmIHRoYXQgaXMgc21hbGwgZW5vdWdoIHRoZW4gcmVwbGF5IHdpbGwg bm90PGJyIGNsYXNzPSJudWxsIj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd29yay48 YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBGUDogT2ssIHdl IGhhdmUgcmVwaHJhc2VkIGluIHRoZSBmb2xsb3dpbmcgd2F5OjxiciBjbGFzcz0ibnVsbCI+DQom Z3Q7IE9MRDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IElmIHRoZSBncm91cCBoYXMgcmVuZXdlZCBp dHMgZ3JvdXAga2V5aW5nIG1hdGVyaWFsLCB0aGUgdGltZSB3aW5kb3cgYmV0d2VlbjxiciBjbGFz cz0ibnVsbCI+DQomZ3Q7IHRoZSBlbmQgb2YgdGhlIHJla2V5aW5nIHByb2Nlc3MgYW5kIHRoZSBu ZXh0IGxvc3Mgb2Ygc2VjdXJpdHkgc3RhdGUgaXMgc2FmZSBmb3I8YnIgY2xhc3M9Im51bGwiPg0K Jmd0OyByZWNpcGllbnRzLCBhcyByZXBsYXllZCBvbGRlciBtZXNzYWdlcyBwcm90ZWN0ZWQgd2l0 aCBwcmV2aW91cyBrZXlpbmcgbWF0ZXJpYWw8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyB3aWxsIG5v dCBiZSBhY2NlcHRlZC48YnIgY2xhc3M9Im51bGwiPg0KJmd0OyBORVc8YnIgY2xhc3M9Im51bGwi Pg0KJmd0OyBCZXNpZGVzLCBpZiB0aGUgS0RDIGhhcyByZW5ld2VkIHRoZSBncm91cCBrZXlpbmcg bWF0ZXJpYWwsIGFuZCB0aGUgdGltZTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IGludGVydmFsIGJl dHdlZW4gdGhlIGVuZCBvZiB0aGUgcmVrZXlpbmcgcHJvY2VzcyBhbmQgdGhlIGpvaW5pbmcgb2Yg dGhlIENsaWVudCBpczxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IHN1ZmZpY2llbnRseSBzbWFsbCwg dGhhdCBDbGllbnQgaXMgYWxzbyBvbiB0aGUgc2FmZSBzaWRlLCBzaW5jZSByZXBsYXllZCBvbGRl cjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IG1lc3NhZ2VzIHByb3RlY3RlZCB3aXRoIHRoZSBwcmV2 aW91cyBrZXlpbmcgbWF0ZXJpYWwgd2lsbCBub3QgYmUgYWNjZXB0ZWQuPGJyIGNsYXNzPSJudWxs Ij4NCjxiciBjbGFzcz0ibnVsbCI+DQpbSkxTXSBCZXR0ZXI8L2Rpdj4NCjxkaXYgY2xhc3M9Im51 bGwiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibnVsbCI+RlA6Jm5ic3A7PHNwYW4+IE9rLCB0 aGFua3MuPGJyPg0KPC9zcGFuPjxiciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwiPg0K Jmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZWN0 aW9uIDcgL3RoZSBPYnNlcnZhdGlvbnMgdXAgdG8gdGhhdCBwb2ludC8gdGhpcyBkb2VzIG5vdCBt YWtlIGFueSBzZW5zZS48YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBZb3UgY2FuIGxvc2Ugd2hvIEkgY3VycmVudGx5IGRvaW5nIHRoZSBvYnNlcnZhdGlvbiBi dXQgeW91IGhhdmUgYWxyZWFkeTxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHRvc3NlZCBhbGwgb2YgdGhlIG9ic2VydmF0aW9ucyB0aGVtc2VsdmVzIGV2ZW4g d2l0aG91dCBhIHJlYm9vdC48YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwi Pg0KJmd0OyBGUDogT2ssIHdlIGhhdmUgcmVwaHJhc2VkOjxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7 IE9MRDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IHRoZSBPYnNlcnZhdGlvbnMgdXAgdG8gdGhhdCBw b2ludDxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IE5FVzxiciBjbGFzcz0ibnVsbCI+DQomZ3Q7IGFs bCB0aGUgY3VycmVudCBvbmdvaW5nIE9ic2VydmF0aW9ucyB3aXRoIHRoZSBncm91cCBtZW1iZXJz IElzIHRoaXMgYmV0dGVyPzxiciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51bGwiPg0KW0pM U10gWWVhaCwgYmV0dGVyPC9kaXY+DQo8ZGl2IGNsYXNzPSJudWxsIj48YnI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9Im51bGwiPkZQOiBHb29kLjxiciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9Im51 bGwiPg0KSmltPGJyIGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+DQo8YnIgY2xhc3M9 Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBKaW08YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8 YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9 Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0K Jmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIg Y2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51 bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KJmd0OyA8YnIgY2xhc3M9Im51bGwiPg0KPGJy IGNsYXNzPSJudWxsIj4NCjxiciBjbGFzcz0ibnVsbCI+DQo8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+ PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_6941B542FF524479A0B20B3D61382E58ericssoncom_-- From nobody Thu Jul 23 10:46:52 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 B4BE23A0D16; Thu, 23 Jul 2020 10:46:39 -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, HTML_MESSAGE=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 Zq17mxbX1z3c; Thu, 23 Jul 2020 10:46:33 -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 45E7F3A0C8A; Thu, 23 Jul 2020 10:46:29 -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, 23 Jul 2020 10:46:22 -0700 From: Jim Schaad To: 'Francesca Palombini' , CC: References: <023501d64b6e$83ea3b60$8bbeb220$@augustcellars.com> <8D4E3757-5AE5-4216-B13C-76F5916AD3D3@ericsson.com>, <004f01d65bb4$46c20690$d44613b0$@augustcellars.com> <6941B542-FF52-4479-A0B2-0B3D61382E58@ericsson.com> In-Reply-To: <6941B542-FF52-4479-A0B2-0B3D61382E58@ericsson.com> Date: Thu, 23 Jul 2020 10:46:21 -0700 Message-ID: <025501d66119$2ec99d90$8c5cd8b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0256_01D660DE.826FF5B0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHrkDtHCrrJyDPNrRhUQsxYXvvw2gE/Sm55AUXjassB9GrKyKjHG2Fg Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [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: Thu, 23 Jul 2020 17:46:45 -0000 ------=_NextPart_000_0256_01D660DE.826FF5B0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: Francesca Palombini =20 Sent: Thursday, July 23, 2020 4:59 AM To: Jim Schaad ; = draft-ietf-ace-key-groupcomm@ietf.org Cc: Ace@ietf.org Subject: RE: Review of ietf-ace-key-groupcomm-07 =20 Hi Jim,=20 =20 Thanks for your reply! Comments inline. =20 Francesca On 16 July 2020 at 23:01:47 CEST, Jim Schaad > wrote: > -----Original Message----- > From: Francesca Palombini > > Sent: Tuesday, July 14, 2020 2:25 PM > To: Jim Schaad = >; draft-ietf-ace-key- > groupcomm@ietf.org =20 > Cc: ace@ietf.org =20 > Subject: Re: Review of ietf-ace-key-groupcomm-07 >=20 > Hi Jim, >=20 > Thank you so much for another extensive review! We have submitted v-08 = of > the draft to answer it. > Comments inline. If there is any answer/update that does not satisfy = you, > hopefully we can continue the discussion by mail and figure out the = major > points to discuss during IETF108. >=20 > Thanks, > Francesca and Marco >=20 > =EF=BB=BFOn 26/06/2020, 06:02, "Jim Schaad" > wrote: >=20 >=20 > * Section 2 - update DTLS reference >=20 > FP: The Ace profile of DTLS is defined to set up DTLS 1.2, there is no = profile > defined to set up DTLS 1.3, so I don=E2=80=99t think we should update = to 1.3 here. [JLS] Fine - but be prepared for pushback from the IESG on this. FP: A possible alternative is to rephrase to mention the profiles rather = than the protocols. For example: OLD: =E2=80=9CPossible ways to provide a secure communication association are = DTLS [RFC6347] and OSCORE [RFC8613].=E2=80=9D NEW: =E2=80=9CPossible ways to provide a secure communication association are = described in the DTLS transport profile [I-D.ietf-ace-dtls-authorize] = and OSCORE transport profile [I-D.ietf-ace-oscore-profile] of = ACE.=E2=80=9D Would that be better? =20 [JLS] Yes =E2=80=93 just pointing to the profile with out specifying the = details of which version of DTLS seems just fine. >=20 > * Section 3 - The content format application/ace+cbor is not = defined by the > transport profiles but by the framework. >=20 > FP: The point is that the profiles might change the content format, so = even if > this specific one ace+cbor is defined in Ace, profiles might define = and use other > ones. Rephrased to clarify. [JLS] No, the profile can dictate the media type between C and RS, but = between C and AS is set by the framework. FP: Ah, I see what you mean. I checked again in the framework, and to be = nitpicking it does says =E2=80=9CProfiles that use CBOR encoding of = protocol message parameters at the outermost encoding layer MUST use the media format 'application/ ace+cbor'. So in some sense the content-format depends on if the profile = uses CBOR or not. That does not change the fact that we need to rephrase = our text here to be completely correct. OLD: The Content-Format used in the message is the one indicated by the used transport profile of ACE. For example, ... NEW: The Content-Format used in the message depends on the used transport profile of ACE. For example, ... [JLS] Yes you are right that it depends on the encoding, I have = application/ace+json defined and running in my AS for the MQTT code.=20 >=20 > * 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. >=20 > FP: I tried to reformulate here that the aif is the default encoding, = and specify > that the other format defined is an example. In the end it is up to = the > application profile to specify the format of scope. Sure, but why not express figure 4 in terms of AIF rather than as = something that looks like a new structure? =20 FP: We can do that, we will port the example from the OSCORE application = profile (the one in section 3 of = https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-08 ). >=20 > * 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. >=20 > FP: We have modified that to be tstr to be consistent with ace key = groupcomm > oscore, but please note this is only an example. [JLS] Yes I know it is an example, but the gname cannot be anything = other than a tstr unless you are going to completely break the = connection between this value and the name in the URI. =20 FP: This is a good point, we might want to specify that if it=E2=80=99s = not a tstr there needs to be something in place to make the translation = between the group name and GROUPNAME used in the URI (ex: bstr gets = translated into tstr 0x0123 becomes =E2=80=9C0123=E2=80=9D) > * 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) >=20 > FP: I need more clarifications: Is it the following that is strange = =E2=80=9C'scope' > containing the granted scope, if different from the scope requested by = the > client. =E2=80=9C ? Note that the terminology =E2=80=9Crequested and = granted scope=E2=80=9D comes > from OAuth: https://tools.ietf.org/html/rfc6749#section-3.3. I removed = the > second part of the sentence as per comment below. [JLS] What seems odd is that if it is absent, then it is not clear what = the grants are. I don't know if you need to specify that the grant is = the same as the request when it is not present. On the other hand this = is duplicating information in the framework document. FP: Yes, that was the idea, that if it=E2=80=99s not present the granted = scope is the same as the requested one. I am not against duplicating = information if it might make things clearer. [JLS] It should only take a couple of words to do that. >=20 > * Section 3.3 - Am I supposed to know why I care about public keys = at this > point? >=20 > FP: I thought this sentence was supposed to cover it (second = paragraph of 3.3): > =E2=80=9COptionally, the Client might want to request necessary = information concerning > the public keys in the group, as well as concerning the algorithm and = related > parameters for computing signatures in the group.=E2=80=9D = What=E2=80=99s missing? [JLS] Well - lets start with the use of the singular group in the text. = There are a number of problems here: 1. It would make sense that this = refer to the public key usage from group comm document. 2. The term = "information concerning the public keys in the group" to me reads - get = the public keys. 3. There is no motivation about why you are getting = this from the token post rather than from the group descriptor. =20 FP: 1. Right, we can add a reference to it. 2. I see, instead at this = point we would like to get info about for example encoding, not public = keys themselves. 3. Right, so what we need to add here is that this = information is sent before the joining exchange so that the joining node = can send its own public key directly in the joining request and does not = need to do a separate exchange for that.=20 OLD: Optionally, the Client might want to request information concerning the public keys in the group, as well as concerning the algorithm and related parameters for computing signatures in the group. In such a case, the joining node MAY ask for that information to the KDC in this same request. To this end, it sends the CoAP POST request to the /authz-info endpoint using the Content-Format "application/ ace+cbor". NEW: Optionally, the Client might want to request encoding information about the public keys in the group, as well as about the algorithm and related parameters for computing signatures in the group, if those are = used, as for example in [I-D.ietf-core-groupcomm-bis]. In such a case, the joining node MAY ask for that information to the KDC in this same request, so to get the information before the joining exchange = itself (see Section 4.2). To this end, it sends the CoAP POST request to the /authz-info endpoint using the Content-Format "application/ ace+cbor". [JLS] That seems long winded and potentially misses the point: =20 Optionally, the Client might want to request encoding information about = the public keys in the group, used for source authentication, as well as = any other group parameters. The joining node MAY ask for this = information from the KDC in the same message as it uses to POST the = token to the RS. =20 * I am not sure if you need to give the content format as this is = covered in many other places. > * 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...) >=20 > FP: It seems to us this is already defined in the framework: from > = https://tools.ietf.org/html/draft-ietf-ace-oauth-authz-35#section-5.8.1 > =E2=80=9CWhen an RS receives an access token, it MUST verify it before = storing it.=E2=80=9D > And later > =E2=80=9CIf token or claim verification fails, the RS MUST discard the = token and, if this > was an interaction with authz-info, return an error message with a = response > code equivalent to the CoAP code 4.01 (Unauthorized).=E2=80=9D [JLS] That text does not say that one cannot do the following: 1) Get = the token from the POST, 2) immediately return a success indicator, 3) = do the validation of the token, including introspection if necessary, 4) = Keep or discard the token depending on the outcome of the validation = process.=20 I was working to get this in because I did not want to have no response = go back to the client while waiting for the token to be validated in the = event of needing to do introspection. There is nothing really bad = happening if I return a OSCORE nonce in the event that you send me a = DTLS token because you would just ignore that as not being useful. = However, if I have to have the entire content of the token before I can = respond then introspection is going to be harder to deal with. =20 FP: I see, I personally do not think the procedure you describe is valid = from the point of view of the framework, in particular, Section 5.8.1 = says:=20 The RS receiving the token MUST verify the validity of the token. If the token is valid, the RS MUST respond to the POST request with 2.01 (Created). Section Section 5.8.1.1 outlines how an RS MUST proceed to verify the validity of an access token. Although it does not say that it MUST NOT respond with 2.01 unless the = token is valid, I do interpret the previous paragraph that way. I would = think that 2.01 means =E2=80=9Cthe token has been verified and passed = verification=E2=80=9D rather than =E2=80=9CI received the = token=E2=80=9D. This following paragraph (from the framework) should = cover the case you are talking about: The RS MAY make an introspection request to validate the token before responding to the POST request to the authz-info endpoint, e.g. if the token is an opaque reference. Some transport protocols may provide a way to indicate that the RS is busy and the client should retry after an interval; this type of status update would be appropriate while the RS is waiting for an introspection response. I still interpret this as =E2=80=9Conly respond with success when the = token is validated=E2=80=9D. I don=E2=80=99t know what way to indicate = that the RS is busy could be used in CoAP.=20 Also, in case the procedure you describe would be allowed, say the token = does not verify and the RS wants to send an error response, that would = be lost at the Client which has already received a 2.01. Anyway, I do think this is a valid discussion for the framework and I do = not want our draft to add any requirements to what the framework = defines. I think we could rephrase the following to remove any implicit = consequence: OLD: After successful verification, the Client is authorized to receive the group keying material from the KDC and join the group. In particular, the KDC replies to the Client with a 2.01 (Created) response, using Content-Format "application/ace+cbor" defined in Section 8.14 of [I-D.ietf-ace-oauth-authz]. NEW: After successful verification, the Client is authorized to receive the group keying material from the KDC and join the group.=20 The KDC replies to the Client with a 2.01 (Created) response, using Content-Format "application/ace+cbor" defined in Section 8.14 of [I-D.ietf-ace-oauth-authz]. [JLS] Probably better. > * 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. >=20 > FP: Not sure we understand the problem here. Does =E2=80=9Cdifferent = key=E2=80=9D refer to a > following new public key that the client wants to upload? There is in = fact no > association between =E2=80=98kdcchallenge=E2=80=99 and the public key = itself, not even with the > first one that the client provides at its first joining (and it is = also unknown to the > KDC at the time when =E2=80=98kdcchallenge=E2=80=99 is issued). = It=E2=80=99s important the > =E2=80=98kdcchallenge=E2=80=99 is associated to that exact client, = meaning to that exact Token > and PoP key. [JLS] Let's start with which "different key" you are referring to. Is = this a different signing key or a different POP key? Depending on how = you read this is completely changes the meaning of what you are saying = to do in this paragraph. A different POP key (token) will not be using = the same kdcchallenge as a different POP key. You might be able to use = it for a different signing key for a second group in the same token. = But that is not how I read it. =20 FP: Right, we did mean a different signing key. We will clarify that. > * 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? >=20 > FP: Here we meant application profiles of this doc such as = =E2=80=9Cace-key- > groupcomm-oscore=E2=80=9D. I don=E2=80=99t understand the second part = of his comment, could > you explain? [JLS] My problem is that application is a really overloaded term. Just = think of three different lighting applications: Theater Lighting, = Building Lighting and Emergency Lighting. These are three different = applications that are all going to use an OSCORE group keying protocol = as part of their implementation. Now you are saying that the profile is = an application. I am getting really confused about what is an = application and what isn't. =20 FP: You are right, we should have used the term =E2=80=9Capplication = profiles=E2=80=9D, consistently with the rest of the document and using = the term defined in the terminology, to avoid confusions. We did mean = =E2=80=9Capplication profiles=E2=80=9D, and not applications. > * Section 4 - are we still specifying a group to join or is that = implicit in > the URL? Tell me how it is specified? >=20 > FP: It=E2=80=99s specified in the =E2=80=98scope=E2=80=99 of the = Joining Request, as the group name in the > single scope_entry for that Joining Request. I think it=E2=80=99s good = not to mandate > that the URI reflects the group name in the path (though it makes = sense and we > do it in the examples). [JLS] I don't agree. =20 FP: This comment is related to the one above where you say group name = should be a tstr to map to the URI. I thought the flexibility would be = good and would not add much to the complexity of implementations. I = might bring this up in the WG, maybe you could expand on why that = flexibility would be a bad idea? [JLS] Per our discussions today. Note that when Marco and I were = talking about the admin interface we may have come up with a good reason = to be able to do this. >=20 > * Section 4 - I don't think that the (re-) is helping = understanding here. >=20 > FP: The point we were trying to make clear with that (re-) is that it = can be used > to retrieve those several following times, not only once. But I = don=E2=80=99t know how to > express that clearly, and since that does not help understanding we = have > removed them. [JLS] Still and instance in section 1.1=20 =20 FP: Will remove it. >=20 > * Section 4 - what type of individual key is being obtained in = bullet 2 - > how is this different than getting the current keying material? >=20 > FP: The individual key is the equivalent of the Sender Key in OSCORE = (or input > material to derive it, i.e. the Sender ID), vs the group keying = material such as > the master secret, master salt, context id. The difference is that = using bullet 2 > only the personal node=E2=80=99s keying material is updated, not the = group keying > material. We=E2=80=99d welcome proposals on how to clarify it without = going into > OSCORE details. [JLS] Is this trying to say that a new clientId can be issued as oppose = to the current set of material? I would think that you always get = material to derive it and never directly get a key. =20 FP: for OSCORE yes, but we don=E2=80=99t know that this individual key = would always be derived from an identifier such as the clientId, hence = the =E2=80=9Cnew input material to derive it=E2=80=9D terminology = (rather than Client Idetifier). We can change the bullet as follows: OLD * The Client can retrieve a new individual key, or new input material to derive it. This is described in Section 4.4. NEW * The Client can retrieve new input material to derive a new individual key. This is described in Section = 4.4. But still don=E2=80=99t see how to clarify what an =E2=80=9Cindividual = key=E2=80=9D is without going into details that don=E2=80=99t belong = here. [JLS] The Client can retrieve new keying material for itself. This is = described in Section 4.4 >=20 > * 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. >=20 > FP: The part about =E2=80=9Cfixed=E2=80=9D was meant to say that once = defined it will not > change, whatever the application profiles define to use, either the = default or > other, opposed to the /ace-group/GROUPNAME for example, which have a > variable part. Since that was not clear, and not to make it = inconsistent, we have > removed the term fixed. > About OSCORE using a different resource name: should we then specify = as a > requirement that the profiles MUST set the root uri-path, rather than = providing > a default? [JLS] That would make more sense to me. I am not sure why you care = about getting a new root however as a single root could, in theory = support multiple KDC profiles. =20 FP: Say you have both ace key groupcomm OSCORE and pubsub application = profiles implemented on the same KDC. Either the KDC knows what to = return based on the URi root (=E2=80=9Cgroup-oscore=E2=80=9D vs = something like =E2=80=9Cpubsub=E2=80=9D), or it needs to have the = information about what profile it is together with the group keying = material. Right now our document does the first and not the second. Are = you saying you would like us to change that? Or allow both? This is also = something I would bring to the WG to discuss. [JLS] As discussed today. >=20 > * Section 4.1 - what does it mean for a sub-resource to be = "fixed". Does > that mean it never changes? >=20 > FP: See previous answer. Yes it means that once defined it does not = change > depending on other parameters (such as GROUPNAME or NODENAME). We > have removed it now as it was not clear. [JLS] The term normally used is "invariant once established" for that = type of meaning. Fixed would seem to imply that it is fixed prior to = that. =20 FP: Thanks! Will change. >=20 > * Section 4.1 - Yes but what is a NODENAME and why do I care about = it? >=20 > FP: Hopefully adding the following =E2=80=9CEach resource contains the = individual > keying material for that node. =E2=80=9C gives an intuition why the = NODENAME is used. > The fact that it is a node identifier should be clear by the following = sentence: =E2=80=9C > These resources are identified by the node name (in this example, the = node > name has value "NODENAME")=E2=80=9D More details about how precisely = NODENAME > is used to verify the request are given in 4.1.2.1, but we only want = to talk about > it high level here. [JLS] This is the first time that I have seen the term in the document. = Using it without any type of definition is not very useful. Even = defining it in the terminology section would be helpful. FP: Ok, we will add it to the terminology section. >=20 > * 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. >=20 > FP: Ok, I added a note about that. The idea was that this section is = really about > the handler, and the joining is described using this handler later on, = in section > 4.2. [JLS] Yes that is the sort of thing I was looking for. Getting a = correspondence between the resources and the operations is always = helpful. =20 FP: Ok, thanks for confirming. >=20 > * 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. >=20 > FP: Ok, added the following sentence: =E2=80=9CNote that including = this parameter may > result in a large message size for the following response, which can = be > inconvenient for resource-constrained devices.=E2=80=9D Anything more = we need to > add? [JLS] I don't think so. The details on blockwise and ETag should be = clear already. FP: Good, thanks. >=20 > * 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. >=20 > FP: We do that to point the reader on where to find the encoding = (which is the > same as in Ace). [JLS] Ok - that seems a bit odd because this is not the same media-type. =20 FP: That=E2=80=99s right. We could just repeat the encoding, but we = thought it was good to make the parallel. [JLS] The problem is you start asking questions like is it the same = identifier and it may not be. >=20 > * 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? >=20 > FP: By =E2=80=9Cused=E2=80=9D I assume you mean by the KDC? The KDC = extract the granted > scope from the Token, and checks this requested one against the token = one. If > this join message does not have one we are in the case where the KDC > understands which group and role the Client is requesting (say there = is only one > that the client has been granted). What are we missing? [JLS] That explanation =20 FP: You are right, that is missing. We will clarify. > * Section 4.1.2.1 - both bullets are talking about failed = verification - > kill the redundancy. >=20 > FP: Yes, but the error processing is different in the 2 bullets: in = case the > verification fails because client_cred_verify fails, we specify what = the handler > needs to do with regard to the kdcchallenge. So it is not really = redundant. We > haven=E2=80=99t made any changes, but please let us know if you have = ideas on how to > improve. [JLS] But I don't see any reason why I could not return a payload w/ a = new kdcchallenge in the first case as well. =20 FP: Ok, although it is not necessarily needed, if the simplification = helps, we can make the change. >=20 > * 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. >=20 > FP: Ok, we have added a requirement that it is up to the application = profile to > specify what the initial value should be. For OSCORE, this can be = defined in > draft-tiloca-ace-oscore-gm-admin and referenced in the profile. [JLS] Do you want a normative reference to the admin document? =20 FP: No, I think we don=E2=80=99t need it. We give it as an example. [JLS] I was originally thinking about if a section was needed about = initializing groups. You might get pushback on this, but maybe not. > * 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? >=20 > FP: Ok, we have moved this to the policies. It is worth noting though = that the > group_policies parameter is optional (meaning the KDC might not send = this info > in the message), we have explicitly added that the default values MUST = be > specified by the application profiles. [JLS] Yes, but you would use an exp_delta of 0 if you did not retrieve = it from the policy. =20 FP: No, you would use whatever default the application profiles = specifies. It is REQUIRED of application profiles to specify what is the = default value of it=E2=80=99s not sent. =20 [JLS] Not intuitive to me, but ok. > * 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. >=20 > FP: Ok for exp, we changed it to SHOULD. About gkty in the GET = response, it > allows a node acting as =E2=80=9Cmonitor=E2=80=9D to only request the = group key and get all the > information it needs without needing to do the full POST, especially = if the KDC > maintains the pub keys and would fail its request if it does not = contain a pub > key. We could make gkty optional in the response to GET, but I think = that would > just be more complicated (when does the KDC sends it? When not?) I = don=E2=80=99t > think the saving 2 bytes is motivation enough for removing it, given = that we > have a reason for having it. [JLS] I think that is probably reasonable. =20 FP: Ok, so we won=E2=80=99t do any change here. > * Section 4.1.3.1 - The text on the first selection criteria has = me really > messed up because I am not sure that >=20 > FP: Broken comment. But we have assumed this was about the parenthesis > (including the exact combination of roles requested) and have tried to = rephrase > to clarify. I am not sure what the matching rules are supposed to be for role = identifiers. It looks like this might have been clarified =20 FP: Good. > * Section 4.1.6.1 - I have no idea from the text why I would use = this > method. >=20 > FP: It=E2=80=99s difficult to give a clearer idea avoiding = profile-specific details. Would it > help to have an informational reference to key groupcomm oscore to = give an > example? (I=E2=80=99d rather avoid the circular dependency, so if you = have other ideas > on how to improve, I=E2=80=99ll take them). [JLS] This handler is used by a node either to 1) get a new identifier = within the current group or 2) force a rekeying of the group. This is = normally done due to usage limits on the AEAD algorithm. =20 FP: Thanks for the suggestion! As mentioned above though I would not = talk about identifiers, the more precise term would be =E2=80=9Cinput = material to generate an individual key to protect outgoing = messages=E2=80=9D, would that be ok? Or is it still not clear enough? >=20 > * 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? >=20 > FP: The point is that the KDC MUST NOT accept a request from a node N1 > sending a DELETE to ace-group/GROUPNAME/nodes/N2.The KDC can identify > the node name from the secure session it has set up with it (it has = given the > node a name and associated it to the secure channel once the node has = done > the join process). We have tried to reformulate to clarify. [JLS] The text in 4.1.6.2 was clearer about that. =20 FP: Ok, we will revert to that and remove the first part of the = paragraph, which does not seem to help anyway: OLD The handler only accepts a request from the node identified by "NODENAME" via the secure session, where NODENAME is used in Uri- Path, and that is part of the "GROUPNAME" group: the handler verifies that the group name "GROUPNAME" is a subset of the 'scope' stored in the access token associated to this client, and that this client is identified by "NODENAME". If verification fails, the KDC MUST respond with a 4.01 (Unauthorized) error message. NEW The handler verifies that the group name of the /ace-group/GROUPNAME path is a subset of the 'scope' stored in the access token associated to this client, identified by "NODENAME". If verification fails, the KDC MUST respond with a 4.01 (Unauthorized) error message. >=20 > * Section 4.2 - "retrieve individual or group keying material" = What > individual material? >=20 > FP: Same answer as before: this could be for example the sender ID to = derive > the Sender Key in OSCORE. It=E2=80=99s difficult to give a clearer = idea avoiding profile- > specific details. Would it help to have an informational reference to = key > groupcomm oscore to give an example? (I=E2=80=99d rather avoid the = circular > dependency, so if you have other ideas on how to improve, I=E2=80=99ll = take them). [JLS] Retrieve group keying material for the individual =20 FP: Ok, I think we can simplify here and not talk about the = =E2=80=9Cindividual keying material=E2=80=9D but only talk about group = keying material. >=20 > * 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. >=20 > FP: We had added some security considerations about it, referencing to = Section > 4.7 of 7252. Now we added this reference in this section as well. Is = that enough > or what is missing? [JLS] I would have just put the text into the security considerations or = network considerations sections and not bothered to have it here. No = big deal =20 FP: We had those already into the security considerations, and we = thought you wanted more text here specifically. We can remove them from = here, as we don=E2=80=99t want duplicate text. >=20 > * Section 4.4 - What does the first sentence even mean? It seems = to be > almost a circular argument. >=20 > FP: Tried rephrasing as follows: =E2=80=9CBeside possible expiration, = the client may > need to communicate to the KDC its need for part of the keying = material to be > renewed. =E2=80=9C Let us know if this is still unclear. [JLS] I would not bother with 'part of' And putting in text about why = this is needed (i.e. AEAD integrity/confidentially limits) is going to = motivate things better. =20 FP: Ok, we will add something about that. >=20 > * 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. >=20 > FP: Ok, we tried changing to =E2=80=9CRetrieval of New Individual = Keying Material=E2=80=9D Is > this better? [JLS] Not really - that would seem to imply that I would not get "new" = material in section 4.3 either. =20 4.3 - Retrieval of keying material 4.4 - Requesting a change of keying material =20 FP: I would be against renaming section 4.4 so because it seems to imply = a group rekey, while that is not what this exchange is. I think we still = need something in the title with =E2=80=9Cindividual=E2=80=9D, as = opposed to =E2=80=9Cgroup keying=E2=80=9D. [JLS] But section 4.4 could be about a group rekeying. It is going to = be profile based how this is responded to. A profile for which = identifiers are fixed is going to re-key the entire group. One for = which they are fluid can just change the identifier. =20 =20 Jim =20 >=20 > * 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. >=20 > FP: Why? It is important that the client processes the response = correctly. It > makes sense this would not be in the =E2=80=9Chandler=E2=80=9D = section, but here we think we > should have this type of details. Would it be better to have this = paragraph after > the figure? [JLS] What about a client which retrieves the key, verifies the one = signature and promptly forgets the key w/o any long term storage? I'm = going to sleep almost immediately and it will have probably changed by = the time I wake up again. =20 FP: Right, that makes sense. will remove. > * 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. >=20 > FP: That=E2=80=99s correct. An alternative would be that the KDC sends = a POST, > indicating the group name in the payload. This would be sent to a = single > resource on the Client used for any joined group under any KDC. Would = you > prefer this? (not implemented right now) [JLS] I don't know, but probably yes. FP: Ok, we can make this change for the next update. >=20 > 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. >=20 > FP: Ok, we have rephrased in the following way: > OLD > If the group has renewed its group keying material, the time window = between > the end of the rekeying process and the next loss of security state is = safe for > recipients, as replayed older messages protected with previous keying = material > will not be accepted. > NEW > Besides, if the KDC has renewed the group keying material, and the = time > interval between the end of the rekeying process and the joining of = the Client is > sufficiently small, that Client is also on the safe side, since = replayed older > messages protected with the previous keying material will not be = accepted. [JLS] Better =20 FP: Ok, thanks. >=20 > 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. >=20 > FP: Ok, we have rephrased: > OLD > the Observations up to that point > NEW > all the current ongoing Observations with the group members Is this = better? [JLS] Yeah, better =20 FP: Good. Jim >=20 > Jim >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 ------=_NextPart_000_0256_01D660DE.826FF5B0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

From: = Francesca Palombini <francesca.palombini@ericsson.com> =
Sent: Thursday, July 23, 2020 4:59 AM
To: Jim = Schaad <ietf@augustcellars.com>; = draft-ietf-ace-key-groupcomm@ietf.org
Cc: = Ace@ietf.org
Subject: RE: Review of = ietf-ace-key-groupcomm-07

 

Hi Jim, =

 

Thanks for your reply! Comments = inline.

 

Francesca





<= p class=3DMsoNormal>On 16 July 2020 at 23:01:47 CEST, Jim Schaad <ietf@augustcellars.com> = wrote:



> -----Original = Message-----
> From: Francesca Palombini <francesca.palombini@eric= sson.com>
> Sent: Tuesday, July 14, 2020 2:25 PM
> = To: Jim Schaad <ietf@augustcellars.com>; = draft-ietf-ace-key-
> groupcomm@ietf.org
> Cc: ace@ietf.org
> Subject: Re: = Review of ietf-ace-key-groupcomm-07
>
> Hi Jim,
> =
> Thank you so much for another extensive review! We have = submitted v-08 of
> the draft to answer it.
> Comments = inline. If there is any answer/update that does not satisfy you,
> = hopefully we can continue the discussion by mail and figure out the = major
> points to discuss during IETF108.
>
> = Thanks,
> Francesca and Marco
>
> =EF=BB=BFOn = 26/06/2020, 06:02, "Jim Schaad" <ietf@augustcellars.com> = wrote:
>
>
>     * Section 2 - = update DTLS reference
>
> FP: The Ace profile of DTLS is = defined to set up DTLS 1.2, there is no profile
> defined to set = up DTLS 1.3, so I don=E2=80=99t think we should update to 1.3 = here.

[JLS] Fine - but be prepared for pushback from the IESG on = this.

FP: A possible alternative is to rephrase to mention = the profiles rather than the protocols. For = example:

OLD:
=E2=80=9CPossible ways to provide a secure = communication association are DTLS [RFC6347] and OSCORE = [RFC8613].=E2=80=9D

NEW:
=E2=80=9CPossible ways to provide a = secure communication association are described in the DTLS transport = profile [I-D.ietf-ace-dtls-authorize] and OSCORE transport profile = [I-D.ietf-ace-oscore-profile] of ACE.=E2=80=9D

Would that be = better?

 

[JLS] Yes =E2=80=93 just pointing to the = profile with out specifying the details of which version of DTLS seems = just fine.



> =
>     * Section 3 - The content format = application/ace+cbor is not defined by = the
>     transport profiles but by the = framework.
>
> FP: The point is that the profiles might = change the content format, so even if
> this specific one ace+cbor = is defined in Ace, profiles might define and use other
> ones. = Rephrased to clarify.

[JLS] No, the profile can dictate the media = type between C and RS, but between C and AS is set by the = framework.

FP: Ah, I see what you mean. I checked again in = the framework, and to be nitpicking it does says =E2=80=9CProfiles that = use CBOR encoding of protocol message parameters at the
outermost = encoding layer MUST use the media format 'application/
ace+cbor'. So = in some sense the content-format depends on if the profile uses CBOR or = not. That does not change the fact that we need to rephrase our text = here to be completely correct.

OLD:
The Content-Format
used = in the message is the one indicated by the used transport
profile of = ACE. For example, ...
NEW:
The Content-Format
used in the = message depends on the used transport
profile of ACE. For example, = ...

[JLS] Yes you are right that it depends on = the encoding, I have application/ace+json defined and running in my AS = for the MQTT code.



> =
>     * 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.
> =
> FP: I tried to reformulate here that the aif is the default = encoding, and specify
> that the other format defined is an = example. In the end it is up to the
> application profile to = specify the format of scope.

Sure, but why not express figure 4 = in terms of AIF rather than as something that looks like a new = structure?

 

FP: We can do that, we will port the example from = the OSCORE application profile (the one in section 3 of https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-08= ).


>
>     * 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.
>
> FP: = We have modified that to be tstr to be consistent with ace key = groupcomm
> oscore, but please note this is only an = example.

[JLS] Yes I know it is an example, but the gname cannot = be anything other than a tstr unless you are going to completely break = the connection between this value and the name in the = URI.

 

FP: This is a good point, we might want to = specify that if it=E2=80=99s not a tstr there needs to be something in = place to make the translation between the group name and GROUPNAME used = in the URI (ex: bstr gets translated into tstr 0x0123 becomes = =E2=80=9C0123=E2=80=9D)


>     * = 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)
>
> FP:  I need more = clarifications: Is it the following that is strange = =E2=80=9C'scope'
> containing the granted scope, if different from = the scope requested by the
> client. =E2=80=9C ? Note that the = terminology =E2=80=9Crequested and granted scope=E2=80=9D comes
> = from OAuth: https://tools.ietf.org/html/rfc6749#section-3.= 3. I removed the
> second part of the sentence as per comment = below.

[JLS] What seems odd is that if it is absent, then it is = not clear what the grants are.  I don't know if you need to specify = that the grant is the same as the request when it is not present.  = On the other hand this is duplicating information in the framework = document.

FP: Yes, that was the idea, that if it=E2=80=99s = not present the granted scope is the same as the requested one. I am not = against duplicating information if it might make things = clearer.

[JLS] It should only take a couple of words = to do that.


> =
>     * Section 3.3 - Am I supposed to know = why I care about public keys at this
>     = point?
>
> FP:  I thought this sentence was supposed = to cover it (second paragraph of 3.3):
> =E2=80=9COptionally, the = Client might want to request necessary information concerning
> = the public keys in the group, as well as concerning the algorithm and = related
> parameters for computing signatures in the = group.=E2=80=9D What=E2=80=99s missing?

[JLS] Well - lets start = with the use of the singular group in the text.  There are a number = of problems here:  1.  It would make sense that this refer to = the public key usage from group comm document.  2. The term = "information concerning the public keys in the group" to me = reads - get the public keys.  3.  There is no motivation about = why you are getting this from the token post rather than from the group = descriptor.

 

FP: 1. Right, we can add a reference to it. 2. I = see, instead at this point we would like to get info about for example = encoding, not public keys themselves. 3. Right, so what we need to add = here is that this information is sent before the joining exchange so = that the joining node can send its own public key directly in the = joining request and does not need to do a separate exchange for that. =

OLD:
Optionally, the Client might want to request information = concerning
the public keys in the group, as well as concerning the = algorithm and
related parameters for computing signatures in the = group. In such a
case, the joining node MAY ask for that information = to the KDC in
this same request. To this end, it sends the CoAP POST = request to
the /authz-info endpoint using the Content-Format = "application/
ace+cbor".

NEW:
Optionally, the = Client might want to request encoding information about
the public = keys in the group, as well as about the algorithm and
related = parameters for computing signatures in the group, if those are used, as = for example in [I-D.ietf-core-groupcomm-bis]. In such a
case, the = joining node MAY ask for that information to the KDC in
this same = request, so to get the information before the joining exchange itself = (see Section 4.2). To this end, it sends the CoAP POST request to
the = /authz-info endpoint using the Content-Format = "application/
ace+cbor".

[JLS] That seems long = winded and potentially misses the point:

 

Optionally, the Client = might want to request encoding information about the public keys in the = group, used for source authentication, as well as any other group = parameters.=C2=A0 The joining node MAY ask for this information from the = KDC in the same message as it uses to POST the token to the = RS.

 

  • I am not sure if you need to = give the content format as this is covered in many other = places.



>     * 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...)
>
> FP: It seems to us this is already = defined in the framework: from
> https://tools.ietf.org/html/draft-ietf-ace-oau= th-authz-35#section-5.8.1
> =E2=80=9CWhen an RS receives an = access token, it MUST verify it before storing it.=E2=80=9D
> And = later
> =E2=80=9CIf token or claim verification fails, the RS MUST = discard the token and, if this
> was an interaction with = authz-info, return an error message with a response
> code = equivalent to the CoAP code 4.01 (Unauthorized).=E2=80=9D

[JLS] = That text does not say that one cannot do the following:  1) Get = the token from the POST,  2) immediately return a success = indicator, 3) do the validation of the token, including introspection if = necessary, 4) Keep or discard the token depending on the outcome of the = validation process.

I was working to get this in because I did = not want to have no response go back to the client while waiting for the = token to be validated in the event of needing to do introspection.  = There is nothing really bad happening if I return a OSCORE nonce in the = event that you send me a DTLS token because you would just ignore that = as not being useful.  However, if I have to have the entire content = of the token before I can respond then introspection is going to be = harder to deal with.

 

FP: I see, I personally do not think the = procedure you describe is valid from the point of view of the framework, = in particular, Section 5.8.1 says:

The RS
receiving the token = MUST verify the validity of the token. If the
token is valid, the RS = MUST respond to the POST request with 2.01
(Created). Section Section = 5.8.1.1 outlines how an RS MUST proceed
to verify the validity of an = access token.

Although it does not say that it MUST NOT respond = with 2.01 unless the token is valid, I do interpret the previous = paragraph that way. I would think that 2.01 means =E2=80=9Cthe token has = been verified and passed verification=E2=80=9D rather than =E2=80=9CI = received the token=E2=80=9D. This following paragraph (from the = framework) should cover the case you are talking about:

The RS = MAY make an introspection request to validate the token = before
responding to the POST request to the authz-info endpoint, = e.g. if
the token is an opaque reference. Some transport protocols = may
provide a way to indicate that the RS is busy and the client = should
retry after an interval; this type of status update would = be
appropriate while the RS is waiting for an introspection = response.

I still interpret this as =E2=80=9Conly respond with = success when the token is validated=E2=80=9D. I don=E2=80=99t know what = way to indicate that the RS is busy could be used in CoAP.

Also, = in case the procedure you describe would be allowed, say the token does = not verify and the RS wants to send an error response, that would be = lost at the Client which has already received a 2.01.

Anyway, I = do think this is a valid discussion for the framework and I do not want = our draft to add any requirements to what the framework defines. I think = we could rephrase the following to remove any implicit = consequence:

OLD:
After successful verification, the Client is = authorized to receive
the group keying material from the KDC and join = the group. In
particular, the KDC replies to the Client with a 2.01 = (Created)
response, using Content-Format = "application/ace+cbor" defined in
Section 8.14 of = [I-D.ietf-ace-oauth-authz].
NEW:
After successful verification, = the Client is authorized to receive
the group keying material from = the KDC and join the group.

The KDC replies to the Client with a = 2.01 (Created)
response, using Content-Format = "application/ace+cbor" defined in
Section 8.14 of = [I-D.ietf-ace-oauth-authz].

[JLS] Probably better.



>     * 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.
>
> FP: Not = sure we understand the problem here. Does =E2=80=9Cdifferent = key=E2=80=9D refer to a
> following new public key that the client = wants to upload? There is in fact no
> association between = =E2=80=98kdcchallenge=E2=80=99 and the public key itself, not even with = the
> first one that the client provides at its first joining (and = it is also unknown to the
> KDC at the time when = =E2=80=98kdcchallenge=E2=80=99 is issued). It=E2=80=99s important = the
> =E2=80=98kdcchallenge=E2=80=99 is associated to that exact = client, meaning to that exact Token
> and PoP key.

[JLS] = Let's start with which "different key" you are referring = to.  Is this a different signing key or a different POP key?  = Depending on how you read this is completely changes the meaning of what = you are saying to do in this paragraph.  A different POP key = (token) will not be using the same kdcchallenge as a different POP = key.  You might be able to use it for a different signing key for a = second group in the same token.  But that is not how I read = it.

 

FP: Right, we did mean a different signing key. = We will clarify that.


>     * 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?
>
> FP: = Here we meant application profiles of this doc such as = =E2=80=9Cace-key-
> groupcomm-oscore=E2=80=9D. I don=E2=80=99t = understand the second part of his comment, could
> you = explain?

[JLS]  My problem is that application is a really = overloaded term.  Just think of three different lighting = applications:  Theater Lighting, Building Lighting and Emergency = Lighting.  These are three different applications that are all = going to use an OSCORE group keying protocol as part of their = implementation.  Now you are saying that the profile is an = application.  I am getting really confused about what is an = application and what isn't.

 

FP: You are right, we should have used the term = =E2=80=9Capplication profiles=E2=80=9D, consistently with the rest of = the document and using the term defined in the terminology, to avoid = confusions. We did mean =E2=80=9Capplication profiles=E2=80=9D, and not = applications.


>     * Section 4 - are = we still specifying a group to join or is that implicit = in
>     the URL?  Tell me how it is = specified?
>
> FP: It=E2=80=99s specified in the = =E2=80=98scope=E2=80=99 of the Joining Request, as the group name in = the
> single scope_entry for that Joining Request. I think = it=E2=80=99s good not to mandate
> that the URI reflects the group = name in the path (though it makes sense and we
> do it in the = examples).

[JLS] I don't agree.

 

FP: This comment is related to the one above = where you say group name should be a tstr to map to the URI. I thought = the flexibility would be good and would not add much to the complexity = of implementations. I might bring this up in the WG, maybe you could = expand on why that flexibility would be a bad = idea?

[JLS] Per our discussions today.=C2=A0 Note = that when Marco and I were talking about the admin interface we may have = come up with a good reason to be able to do this.



>
>     * = Section 4 - I don't think that the (re-) is helping understanding = here.
>
> FP:  The point we were trying to make clear = with that (re-) is that it can be used
> to retrieve those several = following times, not only once. But I don=E2=80=99t know how to
> = express that clearly, and since that does not help understanding we = have
> removed them.

[JLS] Still and instance in section = 1.1 

 

FP: Will remove it.


> =
>     * Section  4 - what type of = individual key is being obtained in bullet 2 = -
>     how is this different than getting the = current keying material?
>
> FP: The individual key is the = equivalent of the Sender Key in OSCORE (or input
> material to = derive it, i.e. the Sender ID), vs the group keying material such = as
> the master secret, master salt, context id. The difference is = that using bullet 2
> only the personal node=E2=80=99s keying = material is updated, not the group keying
> material. We=E2=80=99d = welcome proposals on how to clarify it without going into
> OSCORE = details.

[JLS] Is this trying to say that a new clientId can be = issued as oppose to the current set of material?   I would = think that you always get material to derive it and never directly get a = key.

 

FP: for OSCORE yes, but we don=E2=80=99t know = that this individual key would always be derived from an identifier such = as the clientId, hence the =E2=80=9Cnew input material to derive = it=E2=80=9D terminology (rather than Client Idetifier). We can change = the bullet as follows:
OLD
* The Client can retrieve a new = individual key, or new input
material to derive it. This is described = in Section 4.4.
NEW
* The Client can retrieve new = input
material to derive a new individual key. This is described in = Section 4.4.

But still don=E2=80=99t see how to clarify what an = =E2=80=9Cindividual key=E2=80=9D is without going into details that = don=E2=80=99t belong here.

[JLS] The Client can retrieve new keying = material for itself.=C2=A0 This is described in Section = 4.4



> =
>     * 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.
>
> = FP:  The part about =E2=80=9Cfixed=E2=80=9D was meant to say that = once defined it will not
> change, whatever the application = profiles define to use, either the default or
> other, opposed to = the /ace-group/GROUPNAME for example, which have a
> variable = part. Since that was not clear, and not to make it inconsistent, we = have
> removed the term fixed.
> About OSCORE using a = different resource name: should we then specify as a
> requirement = that the profiles MUST set the root uri-path, rather than = providing
> a default?

[JLS] That would make more sense to = me.  I am not sure why you care about getting a new root however as = a single root could, in theory support multiple KDC = profiles.

 

FP: Say you have both ace key groupcomm OSCORE = and pubsub application profiles implemented on the same KDC. Either the = KDC knows what to return based on the URi root = (=E2=80=9Cgroup-oscore=E2=80=9D vs something like = =E2=80=9Cpubsub=E2=80=9D), or it needs to have the information about = what profile it is together with the group keying material. Right now = our document does the first and not the second. Are you saying you would = like us to change that? Or allow both? This is also something I would = bring to the WG to discuss.

[JLS] As discussed today.



>
>     * = Section 4.1 - what does it mean for a sub-resource to be = "fixed".  Does
>     that mean = it never changes?
>
> FP: See previous answer. Yes it means = that once defined it does not change
> depending on other = parameters (such as GROUPNAME or NODENAME). We
> have removed it = now as it was not clear.

[JLS] The term normally used is = "invariant once established" for that type of meaning.  = Fixed would seem to imply that it is fixed prior to = that.

 

FP: Thanks! Will change.

> =
>     * Section 4.1 - Yes but what is a = NODENAME and why do I care about it?
>
> FP: Hopefully = adding the following =E2=80=9CEach resource contains the = individual
> keying material for that node. =E2=80=9C gives an = intuition why the NODENAME is used.
> The fact that it is a node = identifier should be clear by the following sentence: =E2=80=9C
> = These resources are identified by the node name (in this example, the = node
> name has value "NODENAME")=E2=80=9D More details = about how precisely NODENAME
> is used to verify the request are = given in 4.1.2.1, but we only want to talk about
> it high level = here.

[JLS] This is the first time that I have seen the term in = the document.  Using it without any type of definition is not very = useful.  Even defining it in the terminology section would be = helpful.

FP: Ok, we will add it to the terminology = section.

>
>     * 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.
>
> FP: Ok, = I added a note about that. The idea was that this section is really = about
> the handler, and the joining is described using this = handler later on, in section
> 4.2.

[JLS] Yes that is the = sort of thing I was looking for.  Getting a correspondence between = the resources and the operations is always = helpful.

 

FP: Ok, thanks for confirming.


> =
>     * 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.
>
> FP: Ok, added the following = sentence: =E2=80=9CNote that including this parameter may
> result = in a large message size for the following response, which can be
> = inconvenient for resource-constrained devices.=E2=80=9D Anything more we = need to
> add?

[JLS] I don't think so.  The details on = blockwise and ETag should be clear already.

FP: Good, = thanks.

>
>     * 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.
>
> FP: We = do that to point the reader on where to find the encoding (which is = the
> same as in Ace).

[JLS] Ok - that seems a bit odd = because this is not the same media-type.

 

FP: That=E2=80=99s right. We could just repeat = the encoding, but we thought it was good to make the = parallel.

[JLS] The problem is you start asking = questions like is it the same identifier and it may not = be.



> =
>     * 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?
>
> FP: By =E2=80=9Cused=E2=80=9D I = assume you mean by the KDC? The KDC extract the granted
> scope = from the Token, and checks this requested one against the token one. = If
> this join message does not have one we are in the case where = the KDC
> understands which group and role the Client is = requesting (say there is only one
> that the client has been = granted). What are we missing?

[JLS] That = explanation

 

FP: You are right, that is missing. We will = clarify.


>     * Section 4.1.2.1 - = both bullets are talking about failed verification = -
>     kill the redundancy.
>
> = FP: Yes, but the error processing is different in the 2 bullets: in case = the
> verification fails because client_cred_verify fails, we = specify what the handler
> needs to do with regard to the = kdcchallenge. So it is not really redundant. We
> haven=E2=80=99t = made any changes, but please let us know if you have ideas on how = to
> improve.

[JLS] But I don't see any reason why I could = not return a payload w/ a new kdcchallenge in the first case as = well.

 

FP: Ok, although it is not necessarily needed, if = the simplification helps, we can make the change.


> =
>     * 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.
>
> FP: = Ok, we have added a requirement that it is up to the application profile = to
> specify what the initial value should be. For OSCORE, this = can be defined in
> draft-tiloca-ace-oscore-gm-admin and = referenced in the profile.
[JLS] Do you want a normative reference to = the admin document?

 

FP: No, I think we don=E2=80=99t need it. We give = it as an example.

[JLS] I was originally thinking about if a = section was needed about initializing groups.=C2=A0 You might get = pushback on this, but maybe not.



>     * 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?
>
> FP: Ok, we have = moved this to the policies. It is worth noting though that the
> = group_policies parameter is optional (meaning the KDC might not send = this info
> in the message), we have explicitly added that the = default values MUST be
> specified by the application = profiles.

[JLS] Yes, but you would use an exp_delta of 0 if you = did not retrieve it from the policy.

 

FP: No, you would use whatever default the = application profiles specifies. It is REQUIRED of application profiles = to specify what is the default value of it=E2=80=99s not = sent.

 

[JLS] Not intuitive to me, but = ok.



>     * 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.
>
> FP: Ok for exp, we changed it to = SHOULD. About gkty in the GET response, it
> allows a node acting = as =E2=80=9Cmonitor=E2=80=9D to only request the group key and get all = the
> information it needs without needing to do the full POST, = especially if the KDC
> maintains the pub keys and would fail its = request if it does not contain a pub
> key. We could make gkty = optional in the response to GET, but I think that would
> just be = more complicated (when does the KDC sends it? When not?) I = don=E2=80=99t
> think the saving 2 bytes is motivation enough for = removing it, given that we
> have a reason for having = it.

[JLS] I think that is probably = reasonable.

 

FP: Ok, so we won=E2=80=99t do any change = here.

>     * Section 4.1.3.1 - The text = on the first selection criteria has me = really
>     messed up because I am not sure = that
>
> FP: Broken comment. But we have assumed this was = about the parenthesis
> (including the exact combination of roles = requested) and have tried to rephrase
> to clarify.

I am = not sure what the matching rules are supposed to be for role = identifiers.   It looks like this might have been = clarified

 

FP: Good.


>     = * Section 4.1.6.1 - I have no idea from the text why I would use = this
>     method.
>
> FP: = It=E2=80=99s difficult to give a clearer idea avoiding profile-specific = details. Would it
> help to have an informational reference to key = groupcomm oscore to give an
> example? (I=E2=80=99d rather avoid = the circular dependency, so if you have other ideas
> on how to = improve, I=E2=80=99ll take them).

[JLS] This handler is used by a = node either to 1) get a new identifier within the current group or 2) = force a rekeying of the group.  This is normally done due to usage = limits on the AEAD algorithm.

 

FP: Thanks for the suggestion! As = mentioned above though I would not talk about identifiers, the more = precise term would be =E2=80=9Cinput material to generate an individual = key to protect outgoing messages=E2=80=9D, would that be ok? Or is it = still not clear enough?


>
>     = * 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?
>
> FP: The point is that the KDC MUST NOT = accept a request from a node N1
> sending a DELETE to = ace-group/GROUPNAME/nodes/N2.The KDC can identify
> the node name = from the secure session it has set up with it (it has given the
> = node a name and associated it to the secure channel once the node has = done
> the join process). We have tried to reformulate to = clarify.

[JLS] The text in 4.1.6.2 was clearer about = that.

 

FP: Ok, we will revert to that and remove the = first part of the paragraph, which does not seem to help = anyway:

OLD
The handler only accepts a request from the node = identified by
"NODENAME" via the secure session, where = NODENAME is used in Uri-
Path, and that is part of the = "GROUPNAME" group: the handler verifies
that the group name = "GROUPNAME" is a subset of the 'scope' stored in
the access = token associated to this client, and that this client is
identified = by "NODENAME". If verification fails, the KDC MUST
respond = with a 4.01 (Unauthorized) error message.
NEW
The handler verifies = that the group name of the /ace-group/GROUPNAME
path is a subset of = the 'scope' stored in the access token associated
to this client, = identified by "NODENAME". If verification fails, the
KDC = MUST respond with a 4.01 (Unauthorized) error message.


> =
>     * Section 4.2 - "retrieve = individual or group keying material"  = What
>     individual material?
> =
> FP: Same answer as before: this could be for example the sender = ID to derive
> the Sender Key in OSCORE. It=E2=80=99s difficult to = give a clearer idea avoiding profile-
> specific details. Would it = help to have an informational reference to key
> groupcomm oscore = to give an example? (I=E2=80=99d rather avoid the circular
> = dependency, so if you have other ideas on how to improve, I=E2=80=99ll = take them).

[JLS] Retrieve group keying material for the = individual

 

FP: Ok, I think we can simplify here and not talk = about the =E2=80=9Cindividual keying material=E2=80=9D but only talk = about group keying material.


> =
>     * 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.
>
> FP: We had added some security = considerations about it, referencing to Section
> 4.7 of 7252. Now = we added this reference in this section as well. Is that enough
> = or what is missing?

[JLS] I would have just put the text into the = security considerations or network considerations sections and not = bothered to have it here.  No big deal

 

FP: We had those already into the security = considerations, and we thought you wanted more text here specifically. = We can remove them from here, as we don=E2=80=99t want duplicate = text.


>
>     * Section 4.4 - = What does the first sentence even mean?  It seems to = be
>     almost a circular argument.
> =
> FP: Tried rephrasing as follows: =E2=80=9CBeside possible = expiration, the client may
> need to communicate to the KDC its = need for part of the keying material to be
> renewed. =E2=80=9C = Let us know if this is still unclear.

[JLS] I would not bother = with 'part of' And putting in text about why this is needed (i.e. AEAD = integrity/confidentially limits) is going to motivate things = better.

 

FP: Ok, we will add something about = that.

>
>     * 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.
>
> FP: Ok, we tried changing to = =E2=80=9CRetrieval of New Individual Keying Material=E2=80=9D Is
> = this better?

[JLS] Not really - that would seem to imply that I = would not get "new" material in section 4.3 either.  =
4.3 - Retrieval of keying material
4.4 - Requesting a change of = keying material

 

FP: I would be against renaming section 4.4 so = because it seems to imply a group rekey, while that is not what this = exchange is. I think we still need something in the title with = =E2=80=9Cindividual=E2=80=9D, as opposed to =E2=80=9Cgroup = keying=E2=80=9D.

[JLS] But section 4.4 could be about a group = rekeying.=C2=A0 It is going to be profile based how this is responded = to.=C2=A0 =C2=A0A profile for which identifiers are fixed is going to = re-key the entire group.=C2=A0 One for which they are fluid can just = change the identifier.

 

 

Jim

 


>
>     * 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.
>
> FP: Why? It is important that the = client processes the response correctly. It
> makes sense this = would not be in the =E2=80=9Chandler=E2=80=9D section, but here we think = we
> should have this type of details. Would it be better to have = this paragraph after
> the figure?

[JLS] What about a = client which retrieves the key, verifies the one signature and promptly = forgets the key w/o any long term storage?  I'm going to sleep = almost immediately and it will have probably changed by the time I wake = up again.

 

FP: Right, that makes sense. will = remove.

>     * 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.
>
> FP: = That=E2=80=99s correct. An alternative would be that the KDC sends a = POST,
> indicating the group name in the payload. This would be = sent to a single
> resource on the Client used for any joined = group under any KDC. Would you
> prefer this? (not implemented = right now)

[JLS] I don't know, but probably = yes.

FP: Ok, we can make this change for the next = update.

>
>     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.
>
> FP: Ok, = we have rephrased in the following way:
> OLD
> If the group = has renewed its group keying material, the time window between
> = the end of the rekeying process and the next loss of security state is = safe for
> recipients, as replayed older messages protected with = previous keying material
> will not be accepted.
> = NEW
> Besides, if the KDC has renewed the group keying material, = and the time
> interval between the end of the rekeying process = and the joining of the Client is
> sufficiently small, that Client = is also on the safe side, since replayed older
> messages = protected with the previous keying material will not be = accepted.

[JLS] Better

 

FP:  Ok, thanks.


> =
>     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.
>
> FP: Ok, we have = rephrased:
> OLD
> the Observations up to that point
> = NEW
> all the current ongoing Observations with the group members = Is this better?

[JLS] Yeah, better

 

FP: Good.

Jim


> =
>     Jim
>
>
>
> =
>
>
>
>
>
>
>
> =
> =

<= /div> ------=_NextPart_000_0256_01D660DE.826FF5B0-- From nobody Thu Jul 23 14:07:34 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 6668E3A0DC2 for ; Thu, 23 Jul 2020 14:07:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.10.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159553845241.22359.2413764145527891632@ietfa.amsl.com> Date: Thu, 23 Jul 2020 14:07:32 -0700 From: IETF Secretariat Archived-At: Subject: [Ace] Milestones changed for ace WG 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, 23 Jul 2020 21:07:33 -0000 Changed milestone "WGLC for Group Communications", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/ace/about/ From nobody Fri Jul 24 07:04: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 0C1AD3A0883 for ; Fri, 24 Jul 2020 07:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.621 X-Spam-Level: X-Spam-Status: No, score=-9.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=kJFhtFLa; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=cisco.onmicrosoft.com header.b=kvH4wlyn Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nGwFfrOc8QQq for ; Fri, 24 Jul 2020 07:04:46 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B878F3A07D7 for ; Fri, 24 Jul 2020 07:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9529; q=dns/txt; s=iport; t=1595599485; x=1596809085; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ConewezViPx+7kum+O70TZ4Hs4W7+1kwOmDaLoTEwAQ=; b=kJFhtFLatvW56uMSjBPYt2qqnS32HHdEU0njCc0x/NfDpdKmBdH+G/Fc lQQqM1WjQwshvKy43Q+zDCBs87gY7/dCubz7bzUfQPySSvk/R5sU8MA+e gq1+aV69dyI0P5lJmdMQOMKvdkBa+GoJ2NYotMf7Hopx1Ig1BhnnmKzOj U=; X-Files: smime.p7s : 4024 IronPort-PHdr: =?us-ascii?q?9a23=3AJ8CPMx9nZvd7jv9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRyN/vRgiVLPRsPQ7PcXw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoKklYHcv4fBvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYBQCr6Rpf/5hdJa1XCQ4OAQEBAQE?= =?us-ascii?q?BBwEBEgEBBAQBAUCBSoFSIy4HbystLywKh28DjVaKA45cglMDVQQHAQEBCQM?= =?us-ascii?q?BARsSAgQBAYRMAoIiAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcQEBAQMBEi4?= =?us-ascii?q?BAS4JAQQHBAIBCBEEAQEZFgIfER0IAgQBDQUIBhSDBYF+TQMOEQ8BojcCgTm?= =?us-ascii?q?IYXSBNIMBAQEFhS0NC4IHBwmBOIFTgRmGBIJmgR4agUE/gRFDgX0iLj6BBIE?= =?us-ascii?q?WQgKBMxQaPBGCeoItkiKIUYoSkBROCoJdhDOCWIFLjCGFFoQcm0OSFIhchDG?= =?us-ascii?q?SBwIEAgQFAg4BAQWBaiOBV3AVgyQJRxcCDY4eg3GKGD50NwIGCAEBAwl8jSC?= =?us-ascii?q?BDwGBEAEB?= X-IronPort-AV: E=Sophos;i="5.75,391,1589241600"; d="p7s'?scan'208";a="786469191" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jul 2020 14:04:41 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 06OE4ewJ018473 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 24 Jul 2020 14:04:41 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Jul 2020 09:04:40 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 24 Jul 2020 10:04:40 -0400 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 24 Jul 2020 10:04:39 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oLSZsrXA2s+mr3Yf8Lf+WC/K+xRkSPdmm6Eq6koLduXxq3qWzb4BJQy0r3EI7dhlYkW1yYgPSy5HH+fR5dkn9QeH+9dOtKaL3NeLm4F/34jzkYiOeAggerkiIXWSyrTdXtbZR+JV/YrBMPCKrpkDOICDfg9e8mIJt314CTVBZPM/FFt5HWwLBf18A8csnQ+hqWFWG3lKvRs/OWWh7mmFDlr3V128voLF7b2jIIVniOKu/ll71zpEf4sMhMfufqx8wyMfk17+R2SnmJ4s3/5I4SPfmnO82Uq6WiIL3RaRSniOFpc6sWVinPwHG2f9v1Yo8VdsJteZzsGEGgh8pwGNSQ== 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=MeCx325bAGHHwuAALSM1FfggTb1mJRrXCKsunIYZgW0=; b=fA9Vx8zpEYv1sjESvjidqJyDZXOqfvzYOrAkFDMRqSpyUIdJKG4BwsHzcADcmSO35vWxWsD32dJ0DGtLU0i2byVYPuv5G/HGRvzmwS0VTGXdlSkbb/6hEK/e1lXpn90+oPWQro+YjyrihdygVi5ktkqTqm7oxpe6HCnVficXupGlHqGPx4ywSkHf7J9fh8wwlvBMZ40sjjFzGriJAcXzPkb2V5vwXXk5c5Bt1JhKOm2TwtZWMcRZZHmdjyc30JPxDUqMzSD6dU5LWhorhpx2VBmZkFIW3b79XmAW8QOo4EbCkkrJ9323VQTJV/JgowrWWoOdjDfS0v0vzc284Iy4gA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MeCx325bAGHHwuAALSM1FfggTb1mJRrXCKsunIYZgW0=; b=kvH4wlynNNDfOgcEex4aR0lllqFVPAXLfTDmuLbUhMynArAwhYsuXf4+tDerXo2y54mxS8W/G01DxPfyaOTo4MkqWSE92CStUSptgEVlir6Z9UuTCAsLFCRiLKkL61G+BWSXdbkXAZ4OZ35hjngtKSWGUgunfTPgbruhW54T+zw= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (2603:10b6:406:af::18) by BN7PR11MB2836.namprd11.prod.outlook.com (2603:10b6:406:ad::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.20; Fri, 24 Jul 2020 14:04:38 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::b582:dfb0:1136:8535]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::b582:dfb0:1136:8535%4]) with mapi id 15.20.3216.026; Fri, 24 Jul 2020 14:04:38 +0000 From: "Panos Kampanakis (pkampana)" To: "Brockhaus, Hendrik" , Benjamin Kaduk , Michael Richardson CC: Mohit Sahni , "steffen.fries@siemens.com" , "ace@ietf.org" Thread-Topic: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) Thread-Index: AQHWX5lj2xo5I7eQAk6wCDCWveBOMqkSfISAgAAYZoCAAKV/gIAAVHbwgAANy4CAAyBysA== Date: Fri, 24 Jul 2020 14:04:38 +0000 Message-ID: References: <9794.1595363465@localhost> <20200721215825.GB41010@kduck.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=853d4b82-15da-4ce2-9193-0000a3646129; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2020-07-22T07:41:39Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; authentication-results: siemens.com; dkim=none (message not signed) header.d=none;siemens.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [68.93.142.48] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a959aa01-8a10-49ec-888f-08d82fda80c6 x-ms-traffictypediagnostic: BN7PR11MB2836: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zSp4vKkd0xCfaghadjKfCv37zUfBB7g/E3H2O7GBH4VKW0CPVTgvMn1XvwbX4OOanFhryu7myWU4+HqnSDBTounN8WvnhveXAKpADPIHklecDJ0kf/QlkOOneQeU+Xoegy8j532QtwFrrBkgC/WoZtR4Fkw8CvrM9MaB/RtgspFKkEZFjIjwp58vHqQjgUoM8pbHLm3RRI05J6n0lSkxbhCucHEbXVs0cFk2D/PgCf7g0/eAoPw5iXCx5KFMyjL3wCtFms53Xw/LMJtVDOQZmcELB6kEypKpL4VAGD6StbXsq7OxcnLXP/kHCLNfV0oD2WAt3agyYkHD2XcgjpDBOA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2547.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(366004)(136003)(376002)(396003)(66616009)(99936003)(8676002)(52536014)(316002)(110136005)(76116006)(2906002)(9686003)(66446008)(66556008)(66476007)(64756008)(33656002)(66946007)(54906003)(8936002)(4326008)(478600001)(186003)(71200400001)(86362001)(53546011)(83380400001)(5660300002)(55016002)(26005)(7696005)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: KunwShmXCVWm2kIeBW2mYQ3NFXfTc14p30NOG67I+1wmtYcVuXg41NvnT6nztwcuXiLKazDZ0n0hP8K0/jSicIBAlryO7UzUgLaIqio7wHqZ9z1nlJAY+8Y2ELzlhhkzHGXelN04Ex/W+sjOzjSWah3peOBeSp5SdXLbmys+Of+1byL5fOsaX/MH7P2wmrBDAp2BTWlPXRMhtzVFCv+YLXVb3S5H09sJTYcNSdpS0EVC9UWFYVvdw6y4uh3uXP9w8MbHROFdZzcjdPie+xakXUwryBbSy/LDnThq10mse1JI06HklTBGaKfJCRzJjlWXJMp5XCR6eXgFbThlE6fjcdUcBJXgNU2o2cwjIaMjZedoUg9jxXFcfznlqVlNXYghwChAsvEFADGaAgXqk6Bb5YemYgrOLi65UxwTDcLKxGjnjqP1Kgs7ynnPk6T1O8QIaPez7cpVEV0iuCydKp6rOZg+0LaAjH9DBvhaG0zobwM= x-ms-exchange-transport-forked: True Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0023_01D661A1.D65E46E0" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN7PR11MB2547.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a959aa01-8a10-49ec-888f-08d82fda80c6 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2020 14:04:38.2286 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HzoLkZj/5c88zaeTse8QtKI499+UVqYN7EfjEwLzMW4hiZXBg1H6lB28mgWz8jC70ZgzK10cd5aCRwnwUpm5CA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2836 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) 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, 24 Jul 2020 14:04:48 -0000 ------=_NextPart_000_0023_01D661A1.D65E46E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Hendrik, Thank you. Understood about the end-to-end protection of CMP and POP. I would argue that establishing the end-to-end keys to offer the application level protection functionality in a scalable way does not come easily. On the other hand, even CMP allows for an RA trust model instead of end-to-end POP like EST-coaps does. > I am uncertain if I understand your question correctly. Est-over-coaps described EST transport and not CMP transport on top of CoAP. I meant why do we need two enrollment protocols to run over COAP? est-over-coaps took a long time and a lot of work. The reason we pursued it is because we were getting requests from vendors that wanted to enroll certs in constrained environments in the energy sector and industrial automation and EST was standardized in IEC 62351. Is the cmp-over-coap argument that you could run it over plan UDP and use out-of-band established, end-to-end protection the sole motivating reason? Rgs, Panos -----Original Message----- From: Ace On Behalf Of Brockhaus, Hendrik Sent: Wednesday, July 22, 2020 9:42 AM To: Panos Kampanakis (pkampana) ; Benjamin Kaduk ; Michael Richardson Cc: Mohit Sahni ; steffen.fries@siemens.com; ace@ietf.org Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) Hi Panos, thnaks for you feedback. > Von: Panos Kampanakis (pkampana) > > Hi, > > > Looking into Mohits draft, cmp-over-coap is much simpler than > est-over-coaps, as CMP does not need any binding to an underlying > (D)TLS handshake. > > Not sure that is accurate. And EST does not bind to the tunnel > protocol either unless proof of possession is used. For now the > cmp-over-coap draft says > > When the end to end secrecy is desired for CoAP transport, CoAP over > DTLS [RFC6347] as a transport medium SHOULD be used. > > COAP can run over DTLS or plain UDP and in rare cases TCP, TLS and > maybe Websockets. I am not sure someone would run cmp-over-coap over > TCP because then he could just run CMP natively without COAP in the > middle. Any application layer protocol (CMP etc) can run over any > transport but I am not > sure there are more transports than the usual ones for cmp-over-coap anyway. It is not needed to run CMP over CoAP over TCP. UDP as transport protocol is fine. Actually CMP over CoAP also does not need DTLS underneath. But it also does not hinder to have a second line of defense. As I understand EST, proof-of-possession is purely provided by the self-signature in PKCS#10. But EST provides the proof-of-identity of the requesting party by the (D)TLS client authentication bound to the PKCS#10 (tls-unique copied in the P10 password filed). Is this correct? Such binding is not required for CMP. CMP does not have any requirements in this regard and provides prove-of-identity by signing the CMP messages. The advantage is that this prove-of-identity can be end-to-end and not only on the first hop to the (D)TLS server, like with EST. > > > I agree that if this gets picked up it should be by ACE. > > I would like to understand what gaps it is filling compared to > est-over-coaps which took a lot of work and where it will be used and > implemented in. I am uncertain if I understand your question correctly. Est-over-coaps described EST transport and not CMP transport on top of CoAP. One prototypic implementation can be found on github.com/siemens/embeddedCMP. - Hendrik ------=_NextPart_000_0023_01D661A1.D65E46E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCDGkw ggNDMIICK6ADAgECAhBf+HsoK1TcjUKjFbVoya3/MA0GCSqGSIb3DQEBBQUAMDUxFjAUBgNVBAoT DUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNpc2NvIFJvb3QgQ0EgMjA0ODAeFw0wNDA1MTQyMDE3 MTJaFw0yOTA1MTQyMDI1NDJaMDUxFjAUBgNVBAoTDUNpc2NvIFN5c3RlbXMxGzAZBgNVBAMTEkNp c2NvIFJvb3QgQ0EgMjA0ODCCASAwDQYJKoZIhvcNAQEBBQADggENADCCAQgCggEBALCauaunrwp3 p+JxtrRmYpR4iEfGYlWEQDK/wKsupRxx1rxue6iqum7SFYhIRZ2i/IPQzLmM4CZocEp43yEXnvRh BckVyM8W2jVhiZRDqISoMZh4m7lObyxTEmzNHa0rJLsxxCv/g0Rvtj0kdwnqvyqoH2pW9iAPEVSX gXWnJc5ZaoJl77fq5+KNdYtu8t1Ppl5inM8QCmTQTm3OK8xb9WClJ0eNafR/zhtw3nAbINZuzaYB qDwS0qk/oGteu44gi3qR47Vo7qDnxAF0qFMLK0qaD2USDoJNjmP97+ubGttTphNgr8J918dsFyXU c/tHZFCBgJRM4b+uSxzfku0uBd8CAQOjUTBPMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/ MB0GA1UdDgQWBBQn88gVHm6aAgkWrSugiWBf2nsvqjAQBgkrBgEEAYI3FQEEAwIBADANBgkqhkiG 9w0BAQUFAAOCAQEAnZ2EhKNBqXx3DLdTyk5EUGLvVHzTdRcc6ODGSEu2/kw6GYFWsFbuGZZiqlqj ZMH2TlQzxnf+xRy65V0lyvXwk5qDES7my/h0Rf7nBbir59/LS+E3hNq5i5dwHvDii9ew2A6dsWnW KpF7qUlPfuaOldiDJzzVaEkO1J32LuunvuswpKwfRPyVqzMG+31gCt60imOwnKnypLlTAYfQaKQn f6v/6frJQDiIZ7Q5xoRvV8lT27qO7sBDsvgJg27/Zs8+7xezWBglCTRe48vWFLbs8pJvdOQvgSrV kpHg4Jc8MmgFhUvR91fiUh2TGlSfBXDASnFgHkMLYB7+o86BGeELNTCCBG4wggNWoAMCAQICCmEQ gG0AAAAAAA4wDQYJKoZIhvcNAQEFBQAwNTEWMBQGA1UEChMNQ2lzY28gU3lzdGVtczEbMBkGA1UE AxMSQ2lzY28gUm9vdCBDQSAyMDQ4MB4XDTE0MDQwNDIwMjQxOFoXDTI5MDUxNDIwMjU0MlowLDEO MAwGA1UEChMFQ2lzY28xGjAYBgNVBAMTEUNpc2NvIEVtcGxveWVlIENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAyt9+FkxTFfsjVs3GuWUKBJXl3kxFZ4wMxwbgqx9tXzcqe+fto62A fxHI84Lr7p9Q2cm/PaEvuzwRBzXvuKXZUU7ZsPdToJSALCySZa0Qb6GGa19ACpmlUEQakE3P5kz7 RgaNSOMH1+GtY9fV6CcAFb9uB7JDu2UGL332WV2bEsUsfb3rRLBS4cL8Hu2dWfcdk6erMaZCQjkn 04FixlQsJozbPRTQqI4V6iikG/69rDyeTdbVTK+My/9LnwVsD3GBMiRh7RmrvupxtGiMu8j05Is/ d1OifhWecwvjV3Reg9Lok8bMNJEMAped1weTdVS0X4MsAheosJBld9lS5O4idwIDAQABo4IBhzCC AYMwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFJ+VNrSOXdVLwwrBpymTQ1EG/YlRMBkGCSsG AQQBgjcUAgQMHgoAUwB1AGIAQwBBMAsGA1UdDwQEAwIBhjASBgNVHRMBAf8ECDAGAQH/AgEAMB8G A1UdIwQYMBaAFCfzyBUebpoCCRatK6CJYF/aey+qMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly93 d3cuY2lzY28uY29tL3NlY3VyaXR5L3BraS9jcmwvY3JjYTIwNDguY3JsMFAGCCsGAQUFBwEBBEQw QjBABggrBgEFBQcwAoY0aHR0cDovL3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL2NlcnRzL2Ny Y2EyMDQ4LmNlcjBcBgNVHSAEVTBTMFEGCisGAQQBCRUBFQAwQzBBBggrBgEFBQcCARY1aHR0cDov L3d3dy5jaXNjby5jb20vc2VjdXJpdHkvcGtpL3BvbGljaWVzL2luZGV4Lmh0bWwwDQYJKoZIhvcN AQEFBQADggEBAD5OviMaRgKNXmvbigI0C2Ob5QE8Jl2McLIk62Be7IqEZC4bWRWjZxrhFuP94E19 RJojKNLttveiH+dEze1t6oYhVCisbGG8+8hlUARAiiqL/J9uGJ71xT6loqkcAK5xphe7STJLSlgT k0w26fcvDeiA6zhdVHnKhVKkpOJWd9MNByFOnCQyDOK+pcNxLU6IN9TwL1ZoRkdFa11QiCX3Oimk 8YhBrVN+VzGGKtbgZ4fYU6uBo3V3vtshyDpHtGkn1e7f9/TWcY26etFzL33dzaZ4lChlw4l3XkLq 6AfCEDF5djpBdiCRjwpBUIIbCSmyESBvA+sL4j8i1vo/uEartrAwggSsMIIDlKADAgECAgoBhhEi QTzquitVMA0GCSqGSIb3DQEBCwUAMCwxDjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBF bXBsb3llZSBDQTAeFw0xOTEyMjAxOTQ5MDJaFw0yMTEyMTkxOTU5MDJaMIGfMSQwIgYDVQQDExtQ YW5vcyBLYW1wYW5ha2lzIChwa2FtcGFuYSkxFDASBgNVBAsTC0Npc2NvIFVzZXJzMRIwEAYDVQQL EwlFbXBsb3llZXMxEzARBgoJkiaJk/IsZAEZEwNjb20xFTATBgoJkiaJk/IsZAEZEwVjaXNjbzEh MB8GCSqGSIb3DQEJAQwScGthbXBhbmFAY2lzY28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAmIHTLIzoAnuMUiHMx8V+PF9JpAcB7zrNHOY1Vj1R1Vx7ty7m9yo9G991T2n7zHo4 UzF6tnB9NxzQOKCY54oqP5KjVGYOPPo+qZ+2rx1GABzdKUF4LwUUKOTf9uXAtvsvIRUc5J/csShT jcUIvtVmiAzWXWRfMYShjBYBVtx/h8fDqAqfFAzd6HG0TcdsN/BRb9k6QEW1afHjPKlRUaDRELyj nFGJZd2OsUJ7/aKMdFmQFd2CAJYzsuwLYjeqJsuGNzBc/k6mzQPf6FW17nz17G41KReU0UdZf2yZ jvimkwCQ/yW8SVTOcGBP+Zk+Lq5EYEGQMu1qtNK/97bXMc5kuwIDAQABo4IBWjCCAVYwDgYDVR0P AQH/BAQDAgTwMAwGA1UdEwEB/wQCMAAwegYIKwYBBQUHAQEEbjBsMDwGCCsGAQUFBzAChjBodHRw Oi8vd3d3LmNpc2NvLmNvbS9zZWN1cml0eS9wa2kvY2VydHMvY2VjYS5jZXIwLAYIKwYBBQUHMAGG IGh0dHA6Ly9wa2ljdnMuY2lzY28uY29tL3BraS9vY3NwMB8GA1UdIwQYMBaAFJ+VNrSOXdVLwwrB pymTQ1EG/YlRMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jaXNjb2NlcnRzLmNpc2NvLmNvbS9m aWxlL2NlY2EuY3JsMB0GA1UdEQQWMBSBEnBrYW1wYW5hQGNpc2NvLmNvbTAdBgNVHQ4EFgQUjrl7 6Mrrdw3ZYFiTpZBdtrUm5P4wHwYDVR0lBBgwFgYKKwYBBAGCNwoDDAYIKwYBBQUHAwQwDQYJKoZI hvcNAQELBQADggEBAMhR6xCTygu68lppjWebXTXYznix5961hcmwiJRkPtUIGQ5JQwXyCwq/Juuq yc5ebeq9cQEO5iqyxik/UAQ35BlmKb7SNLi75RtFE/AIZrRsEjTUoO2EtCMQOEMcenWa2XE8fEID BkwzreKeaOchCbDd4L9PvKFht6nDDFtb6VZdWs4ort+J3iFeilVf3oI5MSVi+qroWaFLnLYTQGTn qEjWANfKw3RRBAMdoPCZ+N4eftAk1TWVS08nOsPoKWXtIqX6y0ZPs/EZjBSk57v1TPLpYhEqYGXI oGJlIvzIAfYNoUg8yP8toG5T7x+7hRz0MMUGWcCDsS9PMFxH6SnrUSMxggMNMIIDCQIBATA6MCwx DjAMBgNVBAoTBUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTAN BglghkgBZQMEAgEFAKCCAaQwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMjAwNzI0MTQwNDM2WjAvBgkqhkiG9w0BCQQxIgQgK0VpZbjC3fiJfIquWVt8rwh78ApD2IwV cXGYpMvSTq0wSQYJKwYBBAGCNxAEMTwwOjAsMQ4wDAYDVQQKEwVDaXNjbzEaMBgGA1UEAxMRQ2lz Y28gRW1wbG95ZWUgQ0ECCgGGESJBPOq6K1UwSwYLKoZIhvcNAQkQAgsxPKA6MCwxDjAMBgNVBAoT BUNpc2NvMRowGAYDVQQDExFDaXNjbyBFbXBsb3llZSBDQQIKAYYRIkE86rorVTCBoAYJKoZIhvcN AQkPMYGSMIGPMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUD BAECMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDALBglghkgBZQMEAgEwCwYJKoZIhvcN AQEKMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwBwYFKw4DAhowDQYJKoZIhvcNAQEBBQAEggEA BjMZ7hRJYVNVEua/4xLsobu3W795mz1XdUV/v0Mo9XyL85IkfVF/EyzLRpSnsz/FsNRvtTa+9WCf oF84UO0JNswBSVXs+HKIc47frqj7JBJ3P2+PEtzeJ0JCrSQtdUMRTlICCxYHXtrU5S0w5trCihWv kZzKo6+SXMhvtAPcsrPh4uSVJEJxtPIjF27l3XkbnqdhMwNU1WX7eTOmtFnSSmbS1XLJU7hWNj/y /wi1aM/TEOL0nyVzrM8J8hD8LbQLl09Jy7sF8oG6ysEGmn5pQNRkm24ZzhPpxA5G1cqQfqcfNJDv UOqXYCMBUE47XCXPDXWwZF6H+AFdVzei9ICTrgAAAAAAAA== ------=_NextPart_000_0023_01D661A1.D65E46E0-- From nobody Fri Jul 24 07:33: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 018C33A0A2C for ; Fri, 24 Jul 2020 07:33:09 -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 6eSh_nM_Yhyv for ; Fri, 24 Jul 2020 07:33:07 -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 34C273A0A26 for ; Fri, 24 Jul 2020 07:33:07 -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; Fri, 24 Jul 2020 07:32:59 -0700 From: Jim Schaad To: "'Panos Kampanakis (pkampana)'" , "'Brockhaus, Hendrik'" , 'Benjamin Kaduk' , 'Michael Richardson' CC: 'Mohit Sahni' , , References: <9794.1595363465@localhost> <20200721215825.GB41010@kduck.mit.edu> In-Reply-To: Date: Fri, 24 Jul 2020 07:32:58 -0700 Message-ID: <031b01d661c7$55e3b1a0$01ab14e0$@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: AQJDOCht90xMMdcWXdaGmJSaoGyAUwGmUsTZAiZ3QyQBjyIiHwIWdmgAAsOmbfoCcGA7TwGonbgIp8ql7gA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) 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, 24 Jul 2020 14:33:09 -0000 > -----Original Message----- > From: Ace On Behalf Of Panos Kampanakis > (pkampana) > Sent: Friday, July 24, 2020 7:05 AM > To: Brockhaus, Hendrik ; Benjamin Kaduk > ; Michael Richardson > Cc: Mohit Sahni ; steffen.fries@siemens.com; > ace@ietf.org > Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel Migault) > > Hi Hendrik, > > Thank you. Understood about the end-to-end protection of CMP and POP. > > I would argue that establishing the end-to-end keys to offer the application > level protection functionality in a scalable way does not come easily. On the > other hand, even CMP allows for an RA trust model instead of end-to-end POP > like EST-coaps does. [JLS] EST-coaps does allow for an RA trust model for POP as well. The RA is the terminator for the coaps connection. Jim > > > I am uncertain if I understand your question correctly. Est-over-coaps > described EST transport and not CMP transport on top of CoAP. > > I meant why do we need two enrollment protocols to run over COAP? > est-over-coaps took a long time and a lot of work. The reason we pursued it is > because we were getting requests from vendors that wanted to enroll certs in > constrained environments in the energy sector and industrial automation and > EST was standardized in IEC 62351. Is the cmp-over-coap argument that you > could run it over plan UDP and use out-of-band established, end-to-end > protection the sole motivating reason? > > Rgs, > Panos > > > -----Original Message----- > From: Ace On Behalf Of Brockhaus, Hendrik > Sent: Wednesday, July 22, 2020 9:42 AM > To: Panos Kampanakis (pkampana) ; Benjamin Kaduk > ; Michael Richardson > Cc: Mohit Sahni ; steffen.fries@siemens.com; > ace@ietf.org > Subject: Re: [Ace] IETF 108 tentative agenda and presentations (Daniel > Migault) > > Hi Panos, > > thnaks for you feedback. > > > Von: Panos Kampanakis (pkampana) > > > > Hi, > > > > > Looking into Mohits draft, cmp-over-coap is much simpler than > > est-over-coaps, as CMP does not need any binding to an underlying > > (D)TLS handshake. > > > > Not sure that is accurate. And EST does not bind to the tunnel > > protocol either unless proof of possession is used. For now the > > cmp-over-coap draft says > > > > When the end to end secrecy is desired for CoAP transport, CoAP over > > DTLS [RFC6347] as a transport medium SHOULD be used. > > > > COAP can run over DTLS or plain UDP and in rare cases TCP, TLS and > > maybe Websockets. I am not sure someone would run cmp-over-coap over > > TCP because then he could just run CMP natively without COAP in the > > middle. Any application layer protocol (CMP etc) can run over any > > transport but I am > not > > sure there are more transports than the usual ones for cmp-over-coap > anyway. > > It is not needed to run CMP over CoAP over TCP. UDP as transport protocol is > fine. Actually CMP over CoAP also does not need DTLS underneath. But it also > does not hinder to have a second line of defense. > As I understand EST, proof-of-possession is purely provided by the > self-signature in PKCS#10. But EST provides the proof-of-identity of the > requesting party by the (D)TLS client authentication bound to the PKCS#10 > (tls-unique copied in the P10 password filed). Is this correct? > Such binding is not required for CMP. CMP does not have any requirements in > this regard and provides prove-of-identity by signing the CMP messages. The > advantage is that this prove-of-identity can be end-to-end and not only on > the first hop to the (D)TLS server, like with EST. > > > > > > > I agree that if this gets picked up it should be by ACE. > > > > I would like to understand what gaps it is filling compared to > > est-over-coaps which took a lot of work and where it will be used and > > implemented in. > > I am uncertain if I understand your question correctly. Est-over-coaps > described EST transport and not CMP transport on top of CoAP. > One prototypic implementation can be found on > github.com/siemens/embeddedCMP. > > - Hendrik From nobody Mon Jul 27 11: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 6D48C3A1B94; Mon, 27 Jul 2020 11:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 otWviUKgdzM9; Mon, 27 Jul 2020 11:01:54 -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 C58523A1B40; Mon, 27 Jul 2020 11:01:50 -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 06RI1fcJ010082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jul 2020 14:01:44 -0400 Date: Mon, 27 Jul 2020 11:01:41 -0700 From: Benjamin Kaduk To: Elwyn Davies Cc: gen-art@ietf.org, draft-ietf-ace-oscore-profile.all@ietf.org, ace@ietf.org, last-call@ietf.org Message-ID: <20200727180141.GF41010@kduck.mit.edu> References: <159537216772.11664.11256578694810978706@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <159537216772.11664.11256578694810978706@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] Genart last call review of draft-ietf-ace-oscore-profile-11 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, 27 Jul 2020 18:01:58 -0000 On Tue, Jul 21, 2020 at 03:56:07PM -0700, Elwyn Davies via Datatracker wrote: > Reviewer: Elwyn Davies > Review result: Almost Ready > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-ace-oscore-profile-11 > Reviewer: Elwyn Davies > Review Date: 2020-07-21 > IETF LC End Date: 2020-07-20 > IESG Telechat date: Not scheduled for a telechat > > Summary:  Almost ready.  There is one minor issue that needs sorting out and a > fair number of nits.  Overall I have to say that I found it difficult to keep > clear in my mind what messages were fully encrypted and which ones were sent en > clair and which are in some intermediate class.  The authors might wish to go > back over the document from the point of a naive reader to ensure that it is > clear for implementers. > > Major issues: > None > > Minor issues: > s2, para 5:  Where does the 'input salt' come from?  The term is not used > anywhere else in this document and  isn't defined or mentioned in either > dreft-ace-oauth-authz or RFC 8613. Hmm, it looks like this was introduced in the -09 as a result of one of my review comments (as the formulation in the -08 implicitly had the name "Master Salt" refer to both the string with and without N1+N2). I think I forgot enough of how this works that the authors will need to chime in with an appropriate clarification of where the original ("input") salt comes from. Thanks for spotting that (as well as the other comments), Ben From nobody Mon Jul 27 11:07:56 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 8CD963A1B6B; Mon, 27 Jul 2020 11:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 57uVxjFMhMGi; Mon, 27 Jul 2020 11:07:49 -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 0E8FF3A1B5D; Mon, 27 Jul 2020 11:07:48 -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 06RI7hsk012246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Jul 2020 14:07:45 -0400 Date: Mon, 27 Jul 2020 11:07:42 -0700 From: Benjamin Kaduk To: Linda Dunbar Cc: ops-dir@ietf.org, draft-ietf-ace-oscore-profile.all@ietf.org, ace@ietf.org, last-call@ietf.org Message-ID: <20200727180742.GG41010@kduck.mit.edu> References: <159521497745.9074.17834135527258230957@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <159521497745.9074.17834135527258230957@ietfa.amsl.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [Ace] Opsdir last call review of draft-ietf-ace-oscore-profile-11 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, 27 Jul 2020 18:07:51 -0000 Hi Linda, On Sun, Jul 19, 2020 at 08:16:17PM -0700, Linda Dunbar via Datatracker wrote: > Reviewer: Linda Dunbar > Review result: Has Nits > > I have reviewed this document as part of the Ops area directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the Ops area directors. > Document editors and WG chairs should treat these comments just like any other > last call comments. > > This document describes how to set specific parameters in using the > Authentication and Authorization for Constrained Environments (ACE) framework > [I-D.ietf-ace-oauth-authz]. The document is written clear, except some minor > issues: > > Section 4.1.1 states that Nonce Parameter must be sent from the client to RS. > What would be the problem if the client doesn't include the "NONCE"? There's a little more discussion of the N1 in the previous section, but in essence, this nonce is required to protect the client against replayed responses. Since the token contents (including key derivation material) would be unchanged across security contexts, the nonce is used to make each one different; it has to be client-generated so that the client is sure that this security context is "fresh" (vs. replayed). > Page 12: It asks RFC editor to validate the numbers listed in Figure 7. There > is no explanation or comments for those values. It will be very difficult for > RFC editor to validate. It seems to me there are 4 columns but I can't > understand the meaning of the values under 1st, 2nd, and 3rd columns. I think this is just a note that the RFC Editor should make sure that someone has checked the values (i.e., the authors). The RFC Editor does not need to be the one actually doing the checking. Thanks for the review, Ben > it is kind of difficult to validate the correctness by just reading through the > document. It would be better to have an implementation report of the proposed > "Profile". > > Best Regards, > Linda Dunbar > > > From nobody Tue Jul 28 03:50:32 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 3D6633A0ACD for ; Tue, 28 Jul 2020 03:50:31 -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 Pakk7EkWwBVj for ; Tue, 28 Jul 2020 03:50:29 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30072.outbound.protection.outlook.com [40.107.3.72]) (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 272A93A0AB0 for ; Tue, 28 Jul 2020 03:50:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RgmXpi5yj9DL8cnWYchKzVpjz6jxuSnR8y1J4jfKdixEwQgR821FPlndVdbDyKoEMOk2vEi34cg7wD1rMMBlOJkQcsOu9XtvEjW1kTatbPzMuH3cV+b4zlq1lLB7PjVLZa6rXR7CKHKxik7jIuukp1Ak46IyvmiSLmlDs3+sc94go281Cf2ZfKO7CT0MRgEHfo96G5BYLbk9XXWt4568RKMxZS3ql/HPkPYaF57G5LSC0HTHGTAHjKyfmUX9LMjnHsrxDK5JAEn44Dkm0K04e5psuqoe2AI1yPIFPw31FW3qbySskxOIgy5E/Risab7UBK7VC4/eC3wugXbfxOx/Gw== 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=TVQPPbStdikmJUE4sjpiHZPx4e2HDjxWuih6x+uM/bc=; b=h1VrCs8oii5jC4G/9ZYETTdG5p1LltXhTDv52c5Nngp0dIBDC2niR7XgYh21ZyL2wiSIdmVEi6rBIkJWUFfiffG6PbCkiAgwRpXf0xYQwWStbaqCrVxKdvg2jInyGxQMuFH78o5BLGXWZjfwy1QHXncPkrXKAuLiMillnEuIg4HDR+c16QgX+09LjDH4qmWsvB3Bcf/6mHPLzelDJaaGhodjcI719VGjuD9BbdApp4KsOPTdn52S37EUmrIs7i9bDHh+Ltgq3NKb4/blI5sa/Nk532Ke0wtSJTwG75sU43PxLmMsaFh0zxRcgq6Bfe8gXldkRMB84ENn4pb+PUZejg== 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=TVQPPbStdikmJUE4sjpiHZPx4e2HDjxWuih6x+uM/bc=; b=Tal9bE1tvpSaL0FofpC8Lot2tGsK7KEqUfn3H881TUTWxXc4UfUvOc/62qCH+zycbse4o64PoOY9+9/12A8q/o1/ryjB5d2Yf2YSIvmcOIUW+QO33Te5EFsa3qL7MYCOlolCLAisoJdIP4Y+tZ4zin8bZTSklxyVtNJGdFAZ0ZY= Received: from HE1PR0702MB3818.eurprd07.prod.outlook.com (2603:10a6:7:8c::18) by HE1PR0701MB2874.eurprd07.prod.outlook.com (2603:10a6:3:4b::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9; Tue, 28 Jul 2020 10:50:26 +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.3239.015; Tue, 28 Jul 2020 10:50:26 +0000 From: Francesca Palombini To: Jim Schaad , "ace@ietf.org" Thread-Topic: [Ace] Working Group Adoption Call for draft-bormann-core-ace-aif Thread-Index: AdZa6NLXkAXyBQ7aQr2DDV5usE+aKQJ9NdYA Date: Tue, 28 Jul 2020 10:50:26 +0000 Message-ID: References: <010101d65ae9$bdffb520$39ff1f60$@augustcellars.com> In-Reply-To: <010101d65ae9$bdffb520$39ff1f60$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [79.12.182.121] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 15603557-05b9-4651-91a7-08d832e409b6 x-ms-traffictypediagnostic: HE1PR0701MB2874: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5Um9tkjNLJVtoau1fRvSI5tMJDEc/XMCW14Bif2/cQ/dWKubtRnnK0eMIYS7Jn1OYLzbunlQqU2WoESKhvBjnsFFOouH+eqv+o8SF8MK53Yrrq0CGU4Swa1wEzGM51Jesa+8Uvxd54cI4L57kq+HW5BYxcp/2E4kOL6Iv+bJjhgmvSkFLMGFVuHjnXJPKEIeFKQOQiQtwu3984fnJ3NHXwFICSmvPJqPBv7HvMsUO2psMPp63gyFfPQJb1Ljye/drfqqhJLcvDzV8dq/j33N9gFaVpC+qy2tfoq+8hdRXsi8z51f4JEpKxN6uBGL/DDoDJlGsrltEwAEFSzFZJpHj6Zr5sZUb3qu13PyOEhsUA86VvC+ToWNEOh4Rr77cAC9LJ1srg0D0Sh/UAPmdbs0bg== 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)(39860400002)(396003)(346002)(136003)(376002)(366004)(966005)(6512007)(83380400001)(6486002)(8936002)(86362001)(186003)(2906002)(33656002)(478600001)(8676002)(5660300002)(2616005)(26005)(66446008)(66556008)(64756008)(66946007)(6506007)(66476007)(76116006)(91956017)(71200400001)(44832011)(110136005)(316002)(36756003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: +dH5zcx+mmyioFoOyGx4e17h8u+Yq8PwB1SaYIP92F+taKJJTwm1BKgNEQxPoK86chEssFP3UybNmNHnUHuNKsd+30M9Ea4qVflcl/BVyLurE7X6Azzt5zB5KJJE4KnobCbQ51OlkvQIGk87Tkt3TzSfGDv0evT1rUZWbOEIKRbNkl9zJi+OZTlDnQOE2dW9nxZN4pd1AXE1buUOAD2pdfZgIqEQowH81QMxAL31aiLGVHkTuDlkKXSfs2CiZ5z6Zw1pPOXPlasKT3bO91UyLJy6LNIKKGQ7edSh3ekMQa5avI/EoHlp+rc7kEmEyAzNTzY5y1RsFLXUpqu+WAsVDAYP2eU8zFbUgGrJ8qHZ556z5TOmd9bcdv/30f858BC6mwe8OOfawpRw1koiZ+Jbtgx6pH0A1y7jlDSLqQ5ZHEHUywysMLyQA+Z1vERavPvhC2huPj386S1cvJ/yITP4XMLJr/r1iZja4nrbc7NH3+nnWpN7pVdH9/zPOT/TnP4wjUBpaP4TitZeDtaSnt2V2LKvem/XQgtI6uYPAa/FoU779Pef4jED8K/g2xlkLAKAIujp1qvtD2kH2G/sSB4RB80dzAhRbMan12/vuDGn9YfrVK2wB4myDIb0oYDAQ6i2uwMrRv8CQaX6fFcIcV4kfA== 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: 15603557-05b9-4651-91a7-08d832e409b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 10:50:26.8677 (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: DbbYkNmhuRZRgHjfKJp79sngHk5Ob6h47NkQDXRxy+4zhwRXnvo+S3Lg/GjdCHZ1/57bwKQk34mmCsM6HmhpIU1IXzQDzCMLZLVmqXRkYp9OobqBqifQVCSaiU5hdwra X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2874 Archived-At: Subject: Re: [Ace] Working Group Adoption Call for draft-bormann-core-ace-aif 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, 28 Jul 2020 10:50:31 -0000 SGksDQoNCkkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50LCBhbmQgYmVsaWV2ZSBB Y2Ugc2hvdWxkIGFkb3B0IGl0LiBJIGFtIHdpbGxpbmcgdG8gcmV2aWV3LCBidXQgSSBkb24ndCBo YXZlIGFueSBpbXBsZW1lbnRhdGlvbiBwbGFucy4NCg0KVGhhbmtzLA0KRnJhbmNlc2NhDQoNCu+7 v09uIDE1LzA3LzIwMjAsIDIyOjUyLCAiQWNlIG9uIGJlaGFsZiBvZiBKaW0gU2NoYWFkIiA8YWNl LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGlldGZAYXVndXN0Y2VsbGFycy5jb20+IHdy b3RlOg0KDQogICAgSSBoYWQgYmVlbiBob2xkaW5nIG9mZiBkb2luZyBhbiBhZG9wdGlvbiBjYWxs IHdhaXRpbmcgZm9yIGEgZm9ybWFsIHJlcXVlc3QNCiAgICB0byBhZG9wdCBpdC4gIEhvd2V2ZXIs IGdpdmVuIHRoYXQgdGhpcyBpcyBub3cgYSBkZXBlbmRlbmN5IGZvciB0aHJlZQ0KICAgIGRpZmZl cmVudCBXRyBkb2N1bWVudHMgSSB0aGluayB3ZSBuZWVkIHRvIGRvIHRoaXMgbm93Lg0KDQogICAg QWRvcHRpb24gY2FsbCBmb3INCiAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1ib3JtYW5uLWNvcmUtYWNlLWFpZi8gDQoNCiAgICBUaGlzIGRvY3VtZW50IHByb3ZpZGVz IGEgdGVtcGxhdGUgZm9yIGFuIGF1dGhvcml6YXRpb24gaW5mb3JtYXRpb24gZm9ybWF0DQogICAg KEFJRikgdXNpbmcgYSBDRERMIGdlbmVyaWMuICBRdWVzdGlvbnMgdG8gYmUgYW5zd2VyZWQ6DQoN CiAgICAxLiAgRG8geW91IHRoaW5rIHRoZSBBQ0UgV0cgc2hvdWxkIGFkb3B0IHRoaXMgZG9jdW1l bnQ/ICBJZiBub3QgcGxlYXNlDQogICAgcHJvdmlkZSBzb21lIHJlYXNvbmluZy4NCg0KICAgIDIu ICBJZiBhZG9wdGVkIGFyZSB5b3Ugd2lsbGluZyB0byByZXZpZXcgdGhlIGRvY3VtZW50Pw0KDQog ICAgMy4gIFdvdWxkIHlvdSBoYXZlIGFueSBpbXBsZW1lbnRhdGlvbiBwbGFucz8gIEN1cnJlbnRs eSB0aGlzIGlzIHJlZmVyZW5jZWQNCiAgICBieSB0aGUgTVFUVC1UTFMgZG9jdW1lbnQsIHRoZSBH cm91cCBLREMgZG9jdW1lbnRzLg0KDQogICAgQWRvcHRpb24gY2FsbCBlbmRzIG9uIEp1bHkgMjgu DQoNCiAgICBKaW0gJiBEYW5pZWwNCg0KDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCiAgICBBY2UgbWFpbGluZyBsaXN0DQogICAgQWNlQGlldGYu b3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hY2UNCg0K From nobody Tue Jul 28 06:25: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 4CBCC3A0C15 for ; Tue, 28 Jul 2020 06:25:44 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-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=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 rG492Xv1PbP8 for ; Tue, 28 Jul 2020 06:25:40 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2058.outbound.protection.outlook.com [40.107.22.58]) (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 37FC23A0C1C for ; Tue, 28 Jul 2020 06:25:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fL0XQ+Jj/1q8/YVMArh51R8W4GUdM1v4haP/SEb7xth1oYlqpm4GN0HVfzbgmZAryVq8HcC8UaKEij08Ohid4tRDKNerM9imebGgpUY6ngBNxy3EtbtuKQSyjzi+Y7/O1VDAEOXMBT2f5K7w95D/UnJfUlbnAtNq48YZ1VC8qSnPJY9ocPUXzaPBuMR3X/DpYv9CcXi10N1J6SYhdsnF7UA6MMYlbQLT4vc/HiAU0WBv9W+iwSx6mVlkPsTGghoZDwZTCG+NtMGcd7y+u76AJzoEDQAdI+xsWuhgclCOeKWKvCPlGCi6vTDhA4atq4OTaY01DVZ/hbVBn5lFg6iRqA== 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=LmGQNfNoXGyMqSUWGzi0elrfgmNMxemxmd3cdf/bH50=; b=Ywn+90f7CSlSGE/vtyRoP6E+ycVOjgRuBV/b9Lsa7NMxEL8hI14t8ToZFMmVyFBNx/iDtTgXr+TtCJrDRIl+s0fLAi+ujHyEpVWvVICbn2NsaUoqBAp2te7QvkRA2j9X/bZE1oUU7Tksf938OUYwVliUhEBB+1xni8IsmG9Qya/MZTtjAMtkS9N07I2mieeyGkyNgwRWep/v0wrVak+KLHU3bg3toMtfKTZDjlc81OgK702UG0McPk9EdKfFCXZc7KbMQIhRuvf5X0fsMvuM5/S7Z9akfvy1iMA1f4AR3w/RkXHANal5w+lfQaBuWhll1EH6EnNbxy1PUqxybGBx1Q== 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=LmGQNfNoXGyMqSUWGzi0elrfgmNMxemxmd3cdf/bH50=; b=I4JYmJGjissazDyjH0ZVL3xGbgz9NsiiYzcz1/ADUuKtzbTi5QGddessqW8W+eslWskrK49DVXyDo1Sskel/yMIURBtlME1rk9G1tUvR2qO2UIM+1Sw1Zh4OGd45lAgFZ4q9tGU+vPh9LZmjuXlY86oCjVfLgq7nabR8LvJfPkA= 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 VI1P189MB0429.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:30::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.26; Tue, 28 Jul 2020 13:25:23 +0000 Received: from VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2]) by VI1P189MB0398.EURP189.PROD.OUTLOOK.COM ([fe80::2124:eed3:60cd:95a2%6]) with mapi id 15.20.3216.026; Tue, 28 Jul 2020 13:25:23 +0000 To: Jim Schaad , ace@ietf.org References: <010101d65ae9$bdffb520$39ff1f60$@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, 28 Jul 2020 15:25:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 In-Reply-To: <010101d65ae9$bdffb520$39ff1f60$@augustcellars.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="NkT2CvxnXOeqaqOK0Drg0YlI15GMDJwJl" X-ClientProxiedBy: HE1PR05CA0381.eurprd05.prod.outlook.com (2603:10a6:7:94::40) To VI1P189MB0398.EURP189.PROD.OUTLOOK.COM (2603:10a6:802:35::31) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.8.0.18] (86.106.103.100) by HE1PR05CA0381.eurprd05.prod.outlook.com (2603:10a6:7:94::40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Tue, 28 Jul 2020 13:25:22 +0000 X-Originating-IP: [86.106.103.100] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cbdd6d2d-bf52-401f-18d7-08d832f9ae9f X-MS-TrafficTypeDiagnostic: VI1P189MB0429: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YXgpY4+DRZoaoqCTlSntRGPL7/QUI/oJTMujDFMMBEH7ece+BwdZXFtch3DNAE38mg1Gslld+c0tUAMtpM6k8xn4AjYHMa1pZv5SW46mNzy1lGm7pV7yMOM0qslNFnNz2KlKwCuNin/oIgeg4e8cBFz6YnfKgaRngU2HpHlrgrD3yjhz6GeUVPMURS1NzkLA2v06I9vhIdbIFmZP0heQ3D9ZyIvCahJi4t5kzThajRswj/ejoSUD4XT5MsNpjM8Yk8CD2CZ4cleOZ0joENtVFLVXDh8RJbSg7tLrKGgnqC6BWcsMpukn//WlN2glF18ax4D5kS0DkTq120lOtu3QdlsRBys920mYljWdty6ZuLbDj5+D7yKbUV7XX20DLZo7j+PejYtpVwLntYEesPvKaYrlOnXhKQ3/PS+SvgrQFIPSu2Fnqprmbc45RtQ9N+wOMhW2wnHj7l+rsPg1zUvZGg== 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)(396003)(39850400004)(376002)(366004)(31696002)(44832011)(2616005)(66574015)(52116002)(478600001)(8676002)(956004)(6486002)(26005)(83380400001)(33964004)(53546011)(16526019)(186003)(316002)(2906002)(21480400003)(8936002)(966005)(36756003)(31686004)(66556008)(16576012)(86362001)(66476007)(66946007)(5660300002)(235185007)(6666004)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: Qi8keS1cn194Stl5qJndzRJvJJ6nFvg+gGCW+bZrsP2suYYfp6aCDtqTT8P94UqdZutf1B7n9fLMOrhTNJhjGVGPDeJB2jAwg9oIFX5fc5ZG8iJAYHZA+CEAj9VsHIPZiqUGyfqET4fpt9rwiXl6e357xY8WzoNxTakWBTTK8Jv3/jTj7fvEEYFjTfMru+D4JwMYfDi7wQjPfrgXwHI8E1MPgJQn6Ys++EBGPo6gt9amEkwsTPCghPw3PPf1g50yFfxaomclS37Z+9UW8Z6xd++glolE87hIuGiDMrrecMg9duJhIcqV70kHy+AW82cPJjfKYnnklQCfkTtsKQXbWNS8gcmXc0It0k0V7dl+afBuYaacmmYcBL97/3Xk0U8WAa5/SBafCyDnP6Aob4JF1+5XIQKqjjcohOB2sz6R0kKo7fnDhH9iW98aafu0Enmyv75bDWgUzeGd5xbDfC/udlXW1/+/Xnb4d5m7/Zrslwc= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: cbdd6d2d-bf52-401f-18d7-08d832f9ae9f X-MS-Exchange-CrossTenant-AuthSource: VI1P189MB0398.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2020 13:25:23.3141 (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: Kau0n0v/4Bxy7sQO9rw06QknMJH4Rj4Isica7AAZ6pcNKs9xjjOtNmeJAdKiY0vZK/paDraDLgCTlZSScxNnQw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1P189MB0429 Archived-At: Subject: Re: [Ace] Working Group Adoption Call for draft-bormann-core-ace-aif 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, 28 Jul 2020 13:25:44 -0000 --NkT2CvxnXOeqaqOK0Drg0YlI15GMDJwJl Content-Type: multipart/mixed; boundary="IinkoW1IVd6Z2u1AM6IGEayZGmaAEvNOw" --IinkoW1IVd6Z2u1AM6IGEayZGmaAEvNOw Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi all, I support adoption of this document and I am willing to review it. The approach in ace-key-groupcomm-oscore for joining OSCORE groups is now using an AIF specific data model, also included in our ACE implementation for Californium. I plan to extend the implementation to support the Extended REST-specific model. Best, /Marco On 2020-07-15 22:51, Jim Schaad wrote: > I had been holding off doing an adoption call waiting for a formal requ= est > to adopt it. However, given that this is now a dependency for three > different WG documents I think we need to do this now. > > Adoption call for > https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/=20 > > This document provides a template for an authorization information form= at > (AIF) using a CDDL generic. Questions to be answered: > > 1. Do you think the ACE WG should adopt this document? If not please > provide some reasoning. > > 2. If adopted are you willing to review the document? > > 3. Would you have any implementation plans? Currently this is referen= ced > by the MQTT-TLS document, the Group KDC documents. > > Adoption call ends on July 28. > > Jim & Daniel > > > _______________________________________________ > 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 --IinkoW1IVd6Z2u1AM6IGEayZGmaAEvNOw-- --NkT2CvxnXOeqaqOK0Drg0YlI15GMDJwJl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAl8gJzwACgkQ7iZktA5Y 2kOD+gf+O7luMIzNKC7qBQk1ZoP4FlkqcTt2yZLl8HfMcrN0aoWatIjpbnIadhDF GLp5nbv6Ysst01zTH7iIT8ea9PcWHXeDn0h4cPOdur2//0Nf6JZBqcKkx2HXt0MX LEk7iehjsUMjbiYRYFGFidvQM3Okqh23+fJxhZTNX5Kqd5UGSeemRtH1JKn3p2JA 3jXRPxTMbvaudJJ1cXjTClG7S25lNGxQ1eVddm3u92Buomgeucj9G6NiMctMG4GG Ig1lLNHMvkUlLTW/ZBhQRhC7NZY024Bk+En+FxvhCEYoh4KV9Vl8OWAuJspuPz59 tVMeFOG3fa1pmnUYV00Cna2QctjPXA== =KGH/ -----END PGP SIGNATURE----- --NkT2CvxnXOeqaqOK0Drg0YlI15GMDJwJl-- From nobody Tue Jul 28 06:31:05 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 C0B833A0C22 for ; Tue, 28 Jul 2020 06:31:03 -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 UoBtkB5Y9YBD for ; Tue, 28 Jul 2020 06:31:01 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 A76CE3A0C1B for ; Tue, 28 Jul 2020 06:31:01 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id 1so5499059vsl.1 for ; Tue, 28 Jul 2020 06:31:01 -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=85duXvML/AmSompBPsqrx1hJuHITAQedllWVVGfDWVI=; b=PP82aQ7oI8/IPpv1smJbM9lkgfc36/vHS1qgeYmeMo7KvzM8m7sOSb2VdePv01bI2s pnsISoaGq8MKCepqoE9zcn4ASSE5+JTvwsmcbxEZJVwmm2z4s+39hdJuDdYurSIYdCTi OWY3oQEZRD21MT22hMPpODEYfPZpod1Lznh0A9Lha5IUxXicqpwXEkfNr3XXEGw6TT6E 8Hwp07IfN6/cQuE4m443JfUEUq9OmJQtN9goziWPEK0qPeYWg/ejceRdLDssSi/TfPA1 9J2oSP0XaRuhlLg9yIXQDpFBWR5MZWujM9GrHu5gWgfKu/PUTLPYz8yW1qJLNs7trqFR RqMQ== 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=85duXvML/AmSompBPsqrx1hJuHITAQedllWVVGfDWVI=; b=uJpI7b15G3YCoFo4xcRS5UZHcC9VPYmnxylqMWdti78aoN58alRGUlcGHRnkT4XOfb iDewNgkYL/JdpFNizYbOGOYF6S0WH/9HJO0tJkaTnPYhk0jFq4qa0+o6rviwQ5znWSSl TybLb93ABmjqVdh7jvymDzG30xGpxDZJG7LjU3yA+EkNmeT+vG/pTsmAuxTqZ4Zn9aaU GTZki3IeAKgBOwK6BzyNgtS7fWW0QuGc/2AUcquKY0fL6BQc+0c4qOcQwUs0RT+Sahqf yE3VNLx5ZSlzl/d1CPpmGaLOaIkiCz2w+vmDXFPJ/dGj9JVo0L3L2tpYbLJlDqpz0tDX +PlQ== X-Gm-Message-State: AOAM533EkR0XJ05LFtSjTEfu1lVV/Y6CVak6Suctm0IMVkkJBrQhBN2B ruv+ajw6cTqEkqFz2IDYfUAECK9g6WBCMoFUaBExFZ9fiAE= X-Google-Smtp-Source: ABdhPJy4gCMiHK9nHIpfPDFgfK9XLUBAkoPrMND9IGsTuJ6GNSNLhIqnjB0IlZnIeqH+hWJRtaRosxqhWXndthceL2o= X-Received: by 2002:a05:6102:22f3:: with SMTP id b19mr19646905vsh.191.1595943058132; Tue, 28 Jul 2020 06:30:58 -0700 (PDT) MIME-Version: 1.0 References: <010101d65ae9$bdffb520$39ff1f60$@augustcellars.com> In-Reply-To: From: Cigdem Sengul Date: Tue, 28 Jul 2020 14:30:46 +0100 Message-ID: To: Ace Wg Content-Type: multipart/alternative; boundary="0000000000000fd38105ab8073c7" Archived-At: Subject: Re: [Ace] Working Group Adoption Call for draft-bormann-core-ace-aif 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, 28 Jul 2020 13:31:04 -0000 --0000000000000fd38105ab8073c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I support the adoption as well. As Jim said, the MQTT-TLS profile has adopted the AIF-MQTT for the scope. Thanks, --Cigdem On Tue, Jul 28, 2020 at 2:25 PM Marco Tiloca wrote: > Hi all, > > I support adoption of this document and I am willing to review it. > > The approach in ace-key-groupcomm-oscore for joining OSCORE groups is > now using an AIF specific data model, also included in our ACE > implementation for Californium. > > I plan to extend the implementation to support the Extended > REST-specific model. > > Best, > /Marco > > On 2020-07-15 22:51, Jim Schaad wrote: > > I had been holding off doing an adoption call waiting for a formal > request > > to adopt it. However, given that this is now a dependency for three > > different WG documents I think we need to do this now. > > > > Adoption call for > > https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ > > > > This document provides a template for an authorization information form= at > > (AIF) using a CDDL generic. Questions to be answered: > > > > 1. Do you think the ACE WG should adopt this document? If not please > > provide some reasoning. > > > > 2. If adopted are you willing to review the document? > > > > 3. Would you have any implementation plans? Currently this is > referenced > > by the MQTT-TLS document, the Group KDC documents. > > > > Adoption call ends on July 28. > > > > Jim & Daniel > > > > > > _______________________________________________ > > Ace mailing list > > Ace@ietf.org > > https://www.ietf.org/mailman/listinfo/ace > > -- > 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 > > > _______________________________________________ > Ace mailing list > Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace > --0000000000000fd38105ab8073c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I support the adoption as well. As Jim= said, the MQTT-TLS profile has adopted the=C2=A0AIF-MQTT=C2=A0for the scope.

Thanks,
--Cigdem

On Tue, Jul 28, 2020= at 2:25 PM Marco Tiloca <marco.ti= loca@ri.se> wrote:
Hi all,

I support adoption of this document and I am willing to review it.

The approach in ace-key-groupcomm-oscore for joining OSCORE groups is
now using an AIF specific data model, also included in our ACE
implementation for Californium.

I plan to extend the implementation to support the Extended
REST-specific model.

Best,
/Marco

On 2020-07-15 22:51, Jim Schaad wrote:
> I had been holding off doing an adoption call waiting for a formal req= uest
> to adopt it.=C2=A0 However, given that this is now a dependency for th= ree
> different WG documents I think we need to do this now.
>
> Adoption call for
> https://datatracker.ietf.org/doc/dr= aft-bormann-core-ace-aif/
>
> This document provides a template for an authorization information for= mat
> (AIF) using a CDDL generic.=C2=A0 Questions to be answered:
>
> 1.=C2=A0 Do you think the ACE WG should adopt this document?=C2=A0 If = not please
> provide some reasoning.
>
> 2.=C2=A0 If adopted are you willing to review the document?
>
> 3.=C2=A0 Would you have any implementation plans?=C2=A0 Currently this= is referenced
> by the MQTT-TLS document, the Group KDC documents.
>
> Adoption call ends on July 28.
>
> Jim & Daniel
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

--
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


_______________________________________________
Ace mailing list
Ace@ietf.org
https://www.ietf.org/mailman/listinfo/ace
--0000000000000fd38105ab8073c7-- From nobody Tue Jul 28 08:23: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 1BCF33A0DC1; Tue, 28 Jul 2020 08:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-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=alum.mit.edu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7cat1fKYMH9v; Tue, 28 Jul 2020 08:22:54 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760044.outbound.protection.outlook.com [40.107.76.44]) (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 C05483A0E3B; Tue, 28 Jul 2020 08:22:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dddRTVJc6oRcriSHXyJjOdvCHPzFlZSe6Sw8x0vgn+P8Gv3vBe9PO4Xb1azgHerwmdl0JoQJ1jZCIjF4quHfTHv7I4JSygTKobILcoPLR7dp7vj9Czb+pxistuRRzcnZmJYnX76aGaUlezBy509qY3ZS88lNZgXum5nCMhyZVYRgfL6i36ue2kOqMKkreFfvteK5MgIvTO6JWn1OSF7moR60L2UnCqNhoi/woItmCpyFHtLYEH0jIISd8lI1SvlwTZwzXvvRUwFBuN/3UEHcdU+M/Z31rNdLpGI7UjYE4m66eRyIk+9j1ZvHnu86ATTAsTsP4j4L9HAruKFC+riuYg== 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=fA39s6EohXd/mqteI8QlcbScsZNB8ztSpB7gpGDUcxw=; b=C4QB+vXdPbKH+DbaIglRQCH6baZuSxDd6eYzkfEfzlrWD2Ly3omb4kf0F5ydYWQIaHnoQJJag76W3TfUvzU/d8R1dROlFtnJUtfpA3TZoL85k58mEb3v3bm7nXHBzYBYIUxxwCG0/siVFHGEr8Ca1IjvG9LYvgXiVare9xcFjOMa8NGAku3GvS06qvXKhD+7BFTQDGhYPsZDqmCiSNT2CoN7FO3YIRcO+UipIvQo3kDN9F0qnqoQHq+4YczhZaUEu0YEG8ei6yWkuS0SjSkOGQk5EfxoRJlGhMwwqRLipy1v5d6sCQm2w5dMsiOzIRZdaEJgAifu5atp32a7oZVN/g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=augustcellars.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fA39s6EohXd/mqteI8QlcbScsZNB8ztSpB7gpGDUcxw=; b=SOo03GwCES9SSI/TDhP40XfX2WpQKNLpAbh3BpWs7sCi1/ty5GxxK37YIiQ6WDS/a23chrMFpAkfuPVRsDB1goh5vK6fCG0nOkukrPiI+LHb6qaEDdX+ZjttZSFqHFZ6koDd8QRlXBSE8LEaZfdTtGVqt/PbMeXbf3Qiwz8TTU4= Received: from CY4PR13CA0041.namprd13.prod.outlook.com (2603:10b6:903:99::27) by CH2PR12MB4054.namprd12.prod.outlook.com (2603:10b6:610:a6::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.23; Tue, 28 Jul 2020 15:22:48 +0000 Received: from CY1NAM02FT013.eop-nam02.prod.protection.outlook.com (2603:10b6:903:99:cafe::98) by CY4PR13CA0041.outlook.office365.com (2603:10b6:903:99::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.9 via Frontend Transport; Tue, 28 Jul 2020 15:22:48 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; augustcellars.com; dkim=none (message not signed) header.d=none;augustcellars.com; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by CY1NAM02FT013.mail.protection.outlook.com (10.152.75.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.10 via Frontend Transport; Tue, 28 Jul 2020 15:22:47 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 06SFMj0B011083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Jul 2020 11:22:45 -0400 To: Jim Schaad , draft-ietf-ace-dtls-authorize.all@ietf.org Cc: "'General Area Review Team'" , ace@ietf.org References: <8c2725a3-f89f-7ea1-dda9-681edd463a32@alum.mit.edu> <000001d65e1c$1eed9430$5cc8bc90$@augustcellars.com> From: Paul Kyzivat Message-ID: <8aa8ff52-8237-6609-28fb-39f0485d978d@alum.mit.edu> Date: Tue, 28 Jul 2020 11:22:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <000001d65e1c$1eed9430$5cc8bc90$@augustcellars.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1ba16125-ce70-41e5-d806-08d8330a159c X-MS-TrafficTypeDiagnostic: CH2PR12MB4054: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: FkjQpOgW1uyzQECS9xX4sTQMFeeJdD+g3SpvDrLKrWb0KxKQ+cPD/ymF6s7Bsb0HP0aDUm8hO3LVAd59fMA8bpzVMl2E94i0R3ru4XBi33/oJtRTV+Z6pCtJTMGkqnDctwtH9WsK0qhNkvsmVhFiICQ8w1EBTRfnDy3tNZJ7J3co2YYtXBUDFoqDPFF3EK3OxuF8udq9/zQbU4UsvhXj8m2HzJ5URCPi0YHwNHb72Oiy1ZwemkzDqJkvf9hNG2WoYROfORxsoEPZrEPhPa9HwW/Fq9ExabYVYq72il0bv4DV5aDHjI/MGf1Jx+SDHTQ20uCbcCJLaxqhGyeJG8ChoG3C+KFNyzHKmkJ1uptEUQlJoz4XujuAx6AF3t/Nlyffd/T4Yt5RbxcGM8CcS907ddLBVaHnUoArY+sfEbq1kVprg7YXOSGCqTQGsC6dms8V7b391t6OhYVVKQ1fCX1dFx82kuKi1329IY/5x4iTayLhr2BMYHX6w9nOwxBYJ73s X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(39860400002)(136003)(346002)(396003)(376002)(46966005)(356005)(8676002)(75432002)(956004)(70206006)(82310400002)(2616005)(86362001)(83380400001)(2906002)(5660300002)(70586007)(8936002)(336012)(186003)(36906005)(786003)(316002)(53546011)(31696002)(82740400003)(47076004)(26005)(478600001)(31686004)(4326008)(7596003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jul 2020 15:22:47.6034 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1ba16125-ce70-41e5-d806-08d8330a159c X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-AuthSource: CY1NAM02FT013.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4054 Archived-At: Subject: Re: [Ace] Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12 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, 28 Jul 2020 15:23:02 -0000 Jim, Sorry - I forgot to respond sooner. Please see comments inline. Thanks, Paul On 7/19/20 6:29 PM, Jim Schaad wrote: > > >> -----Original Message----- >> From: Paul Kyzivat >> Sent: Sunday, July 19, 2020 1:24 PM >> To: draft-ietf-ace-dtls-authorize.all@ietf.org >> Cc: General Area Review Team >> Subject: Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12 >> >> I am the assigned Gen-ART reviewer for this draft. The General Area Review >> Team (Gen-ART) reviews all IETF documents being processed by the IESG for >> the IETF Chair. Please treat these comments just like any other last call >> comments. >> >> For more information, please see the FAQ at >> >> . >> >> Document: draft-ietf-ace-dtls-authorize-12 >> Reviewer: Paul Kyzivat >> Review Date: 2020-07-19 >> IETF LC End Date: 2020-07-20 >> IESG Telechat date: ? >> >> Summary: >> >> This draft is on the right track but has open issues, described in the > review. >> >> General: >> >> TBD >> >> Issues: >> >> Major: 2 >> Minor: 1 >> Nits: 1 >> >> 1) MAJOR: Management of token storage in RS >> >> There seems to be an expectation that when the client uploads an access > token >> that the RS will retain it until the client attempts to establish a DTLS >> association. This seems to require some sort of management of token > lifetime >> in the RS. The only discussion I can find of this issue is the following > in section 7: >> >> ... A similar issue exists with the >> unprotected authorization information endpoint where the resource >> server needs to keep valid access tokens until their expiry. >> Adversaries can fill up the constrained resource server's internal >> storage for a very long time with interjected or otherwise retrieved >> valid access tokens. >> >> This seems to imply a normative requirement to keep tokens until their > expiry. >> But I find no supporting normative requirements about this. And, this > section >> only presents it as a DoS attack, rather than a potential problem with > valid >> usage. >> >> ISTM that there is an implied requirement that the RS have the capacity to >> store one access token for every PoP key of every authorized client. >> If so, that ought to be stated. If not, then some other way of bounding > storage >> ought to be discussed. > > In section 5.8.1 of draft-ietf-ace-oauth-authz is the sentence "The RS MUST > be prepared to store at least one access token for future use." When this > was put in, this is exactly what we were discussing. There is no > requirement that an RS needs to store two access tokens for future use. I > think this means that there is a strongly bounded requirement on storage. When I read that, it seems that the stated requirement is to store one token *in total*, yet the context implies that it ought to be one token *per* client. The procedures defined aren't going to work unless there is one per client. > Authors - It might be worthwhile to re-iterate this requirement in both of > the profile documents. > >> >> 2) MAJOR: Missing normative language >> >> I found several places where the text seems to suggest required behavior > but >> fails to do so using normative language: >> >> * In section 3.3: >> >> ... Instead of >> providing the keying material in the access token, the authorization >> server includes the key identifier in the "kid" parameter, see >> Figure 7. This key identifier enables the resource server to >> calculate the symmetric key used for the communication with the >> client using the key derivation key and a KDF to be defined by the >> application, for example HKDF-SHA-256. The key identifier picked by >> the authorization server needs to be unique for each access token >> where a unique symmetric key is required. >> ... >> Use of a unique (per resource server) "kid" and the use of a key >> derivation IKM that is unique per authorization server/resource >> server pair as specified above will ensure that the derived key is >> not shared across multiple clients. >> >> The uniqueness seems to be a requirement. Perhaps "needs to be unique" >> should be "MUST be unique". (And something similar for the IKM.) >> >> * Also in section 3.3: >> >> All CBOR data types are encoded in CBOR using preferred serialization >> and deterministic encoding as specified in Section 4 of >> [I-D.ietf-cbor-7049bis]. This implies in particular that the "type" >> and "L" components use the minimum length encoding. The content of >> the "access_token" field is treated as opaque data for the purpose of >> key derivation. >> >> IIUC the type of serialization and encoding is a requirement. Will need > some >> rewording to make it so. >> >> * In section 3.3.1: >> >> ... To >> be consistent with the recommendations in [RFC7252] a client is >> expected to offer at least the ciphersuite TLS_PSK_WITH_AES_128_CCM_8 >> [RFC6655] to the resource server. >> >> I think "is expected" should be "MUST". > > The rule would be MUST implement not MUST offer. A client could offer a > completely different ciphersuite that is consistently used in the group and > that would be fine. That implies that the client be configured to *know* that the server supports something else. I guess that is ok. >> * Also in section 3.3.1: >> >> ... This >> specification assumes that the access token is a PoP token as >> described in [I-D.ietf-ace-oauth-authz] unless specifically stated >> otherwise. >> >> I think "assumes ... unless" should be "MUST ... unless". >> >> * Also in section 3.3.1: >> >> ... New access tokens issued by the >> authorization server are supposed to replace previously issued access >> tokens for the respective client. >> >> Is this normative? Should "are supposed to" be "MUST"? >> >> 3) MINOR: Insufficient specification >> >> (I'm waffling whether this is minor or major.) >> >> There are a couple of places where what seem to be requirements are stated >> too vaguely to be implemented consistently: >> >> * In the previously mentioned paragraph in 3.3.1: >> >> ... This >> specification assumes that the access token is a PoP token as >> described in [I-D.ietf-ace-oauth-authz] unless specifically stated >> otherwise. >> >> The "unless specifically stated otherwise" is too vague to be normative. >> How would the alternative be indicated? Is this an escape hatch for future >> extensions? If so, it needs more work to make that clear and to open a > path for >> that future work. >> >> * Also in section 3.3.1: >> >> ... The resource server therefore must >> have a common understanding with the authorization server how access >> tokens are ordered. >> >> The last statement ("must have a common understanding") is mysterious. >> IIUC section 4 is covering the same topic in a less mysterious way. > > I am seeing this in section 3.4 - did I miss something? I'm sorry. This issue should have referred to that passage in 3.4, not 3.3.1. >> 4) NIT: Subsection organization >> >> Both 3.2 and 3.3 share a common structure: >> >> * The section begins with discussion of the interaction between the client > and >> the AS. >> >> * it is followed by a subsection discussing the interaction between the > client >> and the RS. >> >> It is odd to have a section with a single subsection. And the structure > isn't easily >> discerned from the TOC. >> >> I suggest it would be clearer if each of these sections had *two* > subsections, >> one covering the AS interactions and the other the RS interactions. IOW, > put the >> material covering the AS interactions into a new subsection. > From nobody Tue Jul 28 11:00:14 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 2EE193A0AA0; Tue, 28 Jul 2020 11:00:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Jaeggli via Datatracker To: Cc: last-call@ietf.org, draft-ietf-ace-dtls-authorize.all@ietf.org, ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159595920908.22877.13039350127212126333@ietfa.amsl.com> Reply-To: Joel Jaeggli Date: Tue, 28 Jul 2020 11:00:09 -0700 Archived-At: Subject: [Ace] Opsdir last call review of draft-ietf-ace-dtls-authorize-12 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, 28 Jul 2020 18:00:09 -0000 Reviewer: Joel Jaeggli Review result: Ready Greetings, I have reviewed draft-ietf-ace-dtls-authorize for operational considerations related to constrained authentication and authorization. While fall back to proxies becomes a bottleneck for passing security information to devices. The apprach described here appears to be comprehensive and probably the best that is achievable under the circumstances. the recognition of the limitations of some of the weaker cipher suites employed seem both well understood and adequately mitigated when used, they are still weaker then some of the alternatives that are enumerated where possible but seem adequate. From nobody Tue Jul 28 13:25:41 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 B455D3A0B48 for ; Tue, 28 Jul 2020 13:25:39 -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 hGU1MrKI2jBH for ; Tue, 28 Jul 2020 13:25:38 -0700 (PDT) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 497323A0B46 for ; Tue, 28 Jul 2020 13:25:38 -0700 (PDT) Received: by mail-vs1-xe35.google.com with SMTP id a17so10886867vsq.6 for ; Tue, 28 Jul 2020 13:25:38 -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=CsZyvnRh2cY97EGQn1h6gkLj387OvGHbYvZ+G8foiFY=; b=dicBXfivDfRrPmz95nzRm1D8piMrEamaEJPIfcQ/qF4x9X4PQnNcCsax/6Y3/OrdVV W84floiMOycTvby/lBBpZfzofFWDEs9srnfvSaiIuySwPBnSyt1CMt9+q4PClrmy+/2c gtu1jY0TchOrZDls3I4TtAYpLS1uUwsVSOWkuPwSn0QdZ09E8Ma8GsUxvTaHgZPo3WhH GVjQpHoUGctjITGg83uZUAx6hbcZBqeLMqtIUV6En8pexMmOBwAuarK4vHd4meJabXja yVcyu5RaKCoHc4qUoX1p8k40Edn04Cdlj9czzFoYaWkjpUyAOJUsIlD87lspXSk34pWA rQ7A== 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=CsZyvnRh2cY97EGQn1h6gkLj387OvGHbYvZ+G8foiFY=; b=bMAv26yRKV26H9lRVEEGOUvYJq9eWDRXUHvQa9vkCz1AA51o6r7eXDcqW5XJWmKKzu i8N3Tfud7tzXmPM+rQ7rX7SdxI/VRd+BmdN4uDMRqybBDaNjKCllJaIz1bmbOUU6ccwp CcFoFrwl5rjicaTTWoZBf2WZfsofuq+aF0OZ/dFQcQ788m+RIOsA0StOoaK4DD55feeX KXTjx1A6ZR1zavfmTpvVvwFSpkDZsMdBM073QpKca6F7xO657amdAlt6DDJUWMWN3oag LFUDyKBS9bnhjmWwleBBPBPaIhkdB4vyk0Z0RFKEBL0ScWjwEibJGAYkVerarTJMSSUo dsZg== X-Gm-Message-State: AOAM532qFLMH2W4HjD4Ag2WxzcOssClDRoe/PajCgH3ape1VITAlLiKv Vpxhm3hIdx/8LNr9xGfku4ELw8mQLT9TCTL6pimD0j1p X-Google-Smtp-Source: ABdhPJxgC0dk38WkIFePqAq8t8dSgECG23WUg1lz5M59ifP3xqv5LwiWQQEVgem5K4kpl2eLOQH9Kls8siGhPggA0xM= X-Received: by 2002:a67:f696:: with SMTP id n22mr22893616vso.169.1595967937144; Tue, 28 Jul 2020 13:25:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Daniel Migault Date: Tue, 28 Jul 2020 16:25:26 -0400 Message-ID: To: Ace Wg Content-Type: multipart/alternative; boundary="000000000000f76cb405ab863d44" Archived-At: Subject: Re: [Ace] interim meeting planification 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, 28 Jul 2020 20:25:40 -0000 --000000000000f76cb405ab863d44 Content-Type: text/plain; charset="UTF-8" Hi, >From the doodle [1] it seems that the first option was more convenient to the majority of you, as a result our interim meetings will take place from Every first Monday of the month 10AM - 11AM EST until IETF109. Yours, Daniel [1] https://doodle.com/poll/x2dghwiqmqei6cc8 On Tue, Jul 21, 2020 at 11:59 AM Daniel Migault wrote: > Hi, > > Please find a doodle [1] with two time slots for the interim meetings that > are planned 1 per month the first week of the month 10 AM - 11 AM EST. The > two proposed days are Monday and Thursday. Please select your preferred day > by July 26. > > I am sending the calendar serie to the ace list so everyone can better see > how it matches its calendar. > > Yours, > > Jim and Daniel > > [1] https://doodle.com/poll/x2dghwiqmqei6cc8 > -- > Daniel Migault > Ericsson > -- Daniel Migault Ericsson --000000000000f76cb405ab863d44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

From the doodle [1] it seems = that the first option was more convenient to the majority of you, as a resu= lt our interim meetings will take place from=C2=A0Eve= ry first Monday of the month 10AM - 11AM EST until IETF109.

Yours,= =C2=A0
Daniel

<= /div>



On Tue, Jul 21, 2020 at 11:59 AM Daniel Migault <mglt.ietf@gmail.com> wrote:
Hi,

Please find a doodle [1] with two time slots for the inter= im meetings that are planned 1 per month the first week of the month 10 AM = - 11 AM EST. The two proposed days are Monday and Thursday. Please select y= our preferred=C2=A0day by July 26.=C2=A0
=C2=A0
I am se= nding the calendar serie to the ace list so everyone can better see how it = matches its calendar.=C2=A0 =C2=A0

Yours,=C2=A0

Jim and Daniel

--
<= div dir=3D"ltr">
Daniel Migault
Ericsson=


--
Daniel Migault
Ericsson
--000000000000f76cb405ab863d44-- From nobody Tue Jul 28 13:27:09 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 D41AB3A0B5B for ; Tue, 28 Jul 2020 13:27:07 -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 VaINuL6bnTAE for ; Tue, 28 Jul 2020 13:27:06 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700070.outbound.protection.outlook.com [40.107.70.70]) (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 C4BCB3A0B51 for ; Tue, 28 Jul 2020 13:27:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hsKRDW2tZKheSLWfQoEpFPlBWc4WnZYaalLKXSqYdg1ANISnqial0IYm36EaBEYjv9zWjr0UuJxLaT/A2eLTp08jCSOK/42dM6AlfwPp9hlFwJ7fLuAtE+9g7PLoxyaevjyePn0z7pqU9DZL7PzJrrwN8BLwIfWlp1dtEevpkJQ1WgON2FfLJmK37N70GzPv2ei6JHMhTj/70UvSGUrJmuR5cWcSh46MO3M4WoMRLLw/j78jxqEOIz/82vvMK1VkbHK4ObfFEb7saIKmDdaob4PWMpGbvxcvn8zSbg+hL18xtamYrLEEH2KB370Adi52JkbQC8NzDPx3U8GDhRaiVg== 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=d2R0mUdaYct8r31RaJpL9MwKeBENnPpb15Hq2ojyK/Q=; b=lzn13SKH1iqbYqW1Pv3d/H9zM72sfP8nWn4DwEBvTtst26ByGJhxOWFHwKHo5vyoKvNp+5L9k0dAMaJptNFaeye82DchqH8wQvrp4cD0Sn9Nlw72Bz5SpssThJYl7g13Z4lhaWlFKr1QwpXZPrjrLdxT9J48VMYD4sqMHVdqhyBagwiWwW2G7Yrcf25FBcGm66x03j7Vk4DYuwlnjDPJs/hkzkNZgIw17iGsPfzUGk/cr+gLsjET22QUlckV/X0OgXyOnmG44ati3HKYUBuTb7iDOLa5j7cbVGQ28JxNdkSvH3reaynZr5Pnb8Aq5wUqSOEDng0aQ//SvKrv9a3K2g== 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=d2R0mUdaYct8r31RaJpL9MwKeBENnPpb15Hq2ojyK/Q=; b=SyncPkRULHuSXvqelUDZFitxdFOdL/g3me564KaN5Th5xu0FfY3eFt3r9qHr7LnBqsbmJsYTNmgxzzM4H25gJ8aMq1gvzirwmk2Eh0qLwKWSJxSSV9sGB05j5toOsfLwk9gOpFbPAflbnmthx1jtaCL1MeJQwvZXGhn1TR6EgfE= Received: from SA0PR15MB3791.namprd15.prod.outlook.com (2603:10b6:806:8d::10) by SN6PR15MB2447.namprd15.prod.outlook.com (2603:10b6:805:21::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21; Tue, 28 Jul 2020 20:27:05 +0000 Received: from SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::3005:5e4b:252f:e9d1]) by SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::3005:5e4b:252f:e9d1%4]) with mapi id 15.20.3216.033; Tue, 28 Jul 2020 20:27:05 +0000 From: Daniel Migault To: Ace Wg CC: "Ross, Michael D (54510) CIV USN NIWC ATLANTIC SC (USA)" , "Simon, Jonathan" , "Eliot Lear (elear)" , "Kedalagudde, Meghashree Dattatri" , "JP Vasseur (jvasseur)" , "cabocabo@gmail.com" Thread-Topic: ACE interim meeting tentative (Option2) Thread-Index: AdZfcUvc+ExZH1PwtkmFRgVQ81IInA== Date: Tue, 28 Jul 2020 20:27:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAfkCQPB1MlLcV/WAQAAAAAAAAAAEAAAAAoo6O6QeX1Plnwd9W37qJ0= x-originating-ip: [96.22.11.129] x-ms-office365-filtering-correlation-id: 1f3e4dc8-92fb-4f49-c678-08d8333497e9 x-ms-traffictypediagnostic: SN6PR15MB2447:MeetingMessage x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1728; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ENkCowq5sMqjIJGsNbjW/aahm/nAil9OeeL92EOutRah+OnTzCiFZH6B89fY626rk6dIb65sZBlwavF5z9/7eMl1PFhIw6IzO/q3XZ0Du3ovVJaJrEHNoa2aYBT0lzcGXGAD8GbDQ00DtAzrhybWf4axcCzygn6ty9SDNJwFfgm26JFj5E2wGMadFNex8qvt x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR15MB3791.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(346002)(396003)(136003)(376002)(64756008)(66946007)(66446008)(66556008)(66476007)(52536014)(621065003)(8676002)(44832011)(478600001)(86362001)(73894004)(55016002)(76116006)(9686003)(7696005)(6506007)(316002)(54906003)(91956017)(4326008)(71200400001)(26005)(8936002)(186003)(33656002)(4270600006)(2906002)(6916009); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: z9Hx/TbNddXxg+3rxhR1LAV6/JST2qesNQUwyjf+D0vNtEIZzeLVzqYtSbyxeOPy6r3l3ewOXB/BVKxaLraSyaetWQaYpODFWLwRwXl8DqLDXcIvKRj/AOqMERQyfbD+t8MOf/aEqE9FihbI/ECCZuZteTMNW++eMt6YsC9pu0k02MYZI2B/y69YuMcxKl1LP6INeI/MuOJheJXWEHjiPaXoU0woxaKV00+vibhHZkgTq4+GFLoFYC6l1ikfP6vaDeiWPUAvcepcn+huKpvFaGtCs5NnR0VV4BThFnIN2Q4Hl+b38ybkJEhyG4dup8/8Itr2N5pa8nHTviEcrqOpx0Mn6feqLZomVHB6Z4BwE83E4n4MH71p/ZM6ZVxfL27nQ7I/FEm7Np/e3LIjiw8L86BS5pJsg5xmfonnC/6dRtwu4Azsxs9LBy1lR71oaMwrXpvuU7fE2TRxkJIww99nZVz3o1irMa00KTDqqLF+0MU= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA0PR15MB3791DBF23B1C5E1C789E8692E3730SA0PR15MB3791namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR15MB3791.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1f3e4dc8-92fb-4f49-c678-08d8333497e9 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 20:27:05.1169 (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: 93ul2vLSDfLQH+dXvWKrb79gnaYLZy+wcKsg0Gvn2ZMfa2kOfDkvKzLcPpvXHeTC5l0X6P+UMvsT8WVrjXttdvp02wybHB9/IOR/yLCQJrg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR15MB2447 Archived-At: Subject: [Ace] Canceled: ACE interim meeting tentative (Option2) 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, 28 Jul 2020 20:27:08 -0000 --_000_SA0PR15MB3791DBF23B1C5E1C789E8692E3730SA0PR15MB3791namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --_000_SA0PR15MB3791DBF23B1C5E1C789E8692E3730SA0PR15MB3791namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --_000_SA0PR15MB3791DBF23B1C5E1C789E8692E3730SA0PR15MB3791namp_ Content-Type: text/calendar; charset="utf-8"; method=CANCEL Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6Q0FOQ0VMDQpQUk9ESUQ6TWljcm9zb2Z0IEV4Y2hhbmdl IFNlcnZlciAyMDEwDQpWRVJTSU9OOjIuMA0KQkVHSU46VlRJTUVaT05FDQpUWklEOkVhc3Rlcm4g U3RhbmRhcmQgVGltZQ0KQkVHSU46U1RBTkRBUkQNCkRUU1RBUlQ6MTYwMTAxMDFUMDIwMDAwDQpU Wk9GRlNFVEZST006LTA0MDANClRaT0ZGU0VUVE86LTA1MDANClJSVUxFOkZSRVE9WUVBUkxZO0lO VEVSVkFMPTE7QllEQVk9MVNVO0JZTU9OVEg9MTENCkVORDpTVEFOREFSRA0KQkVHSU46REFZTElH SFQNCkRUU1RBUlQ6MTYwMTAxMDFUMDIwMDAwDQpUWk9GRlNFVEZST006LTA1MDANClRaT0ZGU0VU VE86LTA0MDANClJSVUxFOkZSRVE9WUVBUkxZO0lOVEVSVkFMPTE7QllEQVk9MlNVO0JZTU9OVEg9 Mw0KRU5EOkRBWUxJR0hUDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCk9SR0FOSVpFUjtD Tj1EYW5pZWwgTWlnYXVsdDptYWlsdG86ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tDQpBVFRF TkRFRTtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVF O0NOPUFjZSBXZzptYWkNCiBsdG86YWNlQGlldGYub3JnDQpBVFRFTkRFRTtST0xFPU9QVC1QQVJU SUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPSJSb3NzLCBNaWNoDQog YWVsIEQgKDU0NTEwKSBDSVYgVVNOIE5JV0MgQVRMQU5USUMgU0MgKFVTQSkiOm1haWx0bzptaWNo YWVsLmQucm9zczJAbmF2eS5tDQogaWwNCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BB UlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049IlNpbW9uLCBKb24NCiBhdGhhbiI6bWFp bHRvOkpvbmF0aGFuLlNpbW9uQGFuYWxvZy5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQ QU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049RWxpb3QgTGVhcg0KICAoZWxl YXIpOm1haWx0bzplbGVhckBjaXNjby5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5U O1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049IktlZGFsYWd1ZGQNCiBlLCBNZWdo YXNocmVlIERhdHRhdHJpIjptYWlsdG86bWVnaGFzaHJlZS5kYXR0YXRyaS5rZWRhbGFndWRkZUBp bnRlbC5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFD VElPTjtSU1ZQPVRSVUU7Q049SlAgVmFzc2V1cg0KICAoanZhc3NldXIpOm1haWx0bzpqdmFzc2V1 ckBjaXNjby5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURT LUFDVElPTjtSU1ZQPVRSVUU7Q049Y2Fib2NhYm9AZw0KIG1haWwuY29tOm1haWx0bzpjYWJvY2Fi b0BnbWFpbC5jb20NCkRFU0NSSVBUSU9OO0xBTkdVQUdFPWVuLVVTOlxuDQpVSUQ6MDQwMDAwMDA4 MjAwRTAwMDc0QzVCNzEwMUE4MkUwMDgwMDAwMDAwMEMxRDRDOTRCNzE1RkQ2MDEwMDAwMDAwMDAw MDAwMDANCiAwMTAwMDAwMDAwQTI4RThFRTkwNzk3RDRGOTY3QzFERjU2REZCQTg5RA0KUkVDVVJS RU5DRS1JRDtUWklEPUVhc3Rlcm4gU3RhbmRhcmQgVGltZToyMDIwMDkwM1QxMDAwMDANClNVTU1B Ulk7TEFOR1VBR0U9ZW4tVVM6Q2FuY2VsZWQ6IEFDRSBpbnRlcmltIG1lZXRpbmcgdGVudGF0aXZl IChPcHRpb24yKQ0KRFRTVEFSVDtUWklEPUVhc3Rlcm4gU3RhbmRhcmQgVGltZToyMDIwMDkwM1Qx MDAwMDANCkRURU5EO1RaSUQ9RWFzdGVybiBTdGFuZGFyZCBUaW1lOjIwMjAwOTAzVDExMDAwMA0K Q0xBU1M6UFVCTElDDQpQUklPUklUWTo1DQpEVFNUQU1QOjIwMjAwNzI4VDIwMjcwNFoNClRSQU5T UDpUUkFOU1BBUkVOVA0KU1RBVFVTOkNBTkNFTExFRA0KU0VRVUVOQ0U6Mw0KTE9DQVRJT047TEFO R1VBR0U9ZW4tVVM6DQpYLU1JQ1JPU09GVC1DRE8tQVBQVC1TRVFVRU5DRTozDQpYLU1JQ1JPU09G VC1DRE8tT1dORVJBUFBUSUQ6MjExODYyNTcyOQ0KWC1NSUNST1NPRlQtQ0RPLUJVU1lTVEFUVVM6 RlJFRQ0KWC1NSUNST1NPRlQtQ0RPLUlOVEVOREVEU1RBVFVTOkZSRUUNClgtTUlDUk9TT0ZULUNE Ty1BTExEQVlFVkVOVDpGQUxTRQ0KWC1NSUNST1NPRlQtQ0RPLUlNUE9SVEFOQ0U6MQ0KWC1NSUNS T1NPRlQtQ0RPLUlOU1RUWVBFOjMNClgtTUlDUk9TT0ZULURPTk9URk9SV0FSRE1FRVRJTkc6RkFM U0UNClgtTUlDUk9TT0ZULURJU0FMTE9XLUNPVU5URVI6RkFMU0UNCkVORDpWRVZFTlQNCkVORDpW Q0FMRU5EQVINCg== --_000_SA0PR15MB3791DBF23B1C5E1C789E8692E3730SA0PR15MB3791namp_-- From nobody Tue Jul 28 13:27: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 512533A0B51 for ; Tue, 28 Jul 2020 13:27:08 -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 2l98yXK59yAs for ; Tue, 28 Jul 2020 13:27:07 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700070.outbound.protection.outlook.com [40.107.70.70]) (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 F2EDF3A0B5A for ; Tue, 28 Jul 2020 13:27:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gvwXTe8cjGyOULn9CwV3j+77Y0mOh37ap0OWgJ4rul7i9m2XjYZv5eTMm2z+lLddmaF38PFwbWAo/9wTsTRsbodkYjndLrbyAikxJLUhK2c9TM1YTboL1wD0Kx6u7xdbldepsf2mDVox65PRnK5KkJUDGWF5b/oxagFHChK2RtjoGkKOM8Pgk7U+DbjZLukl8+aco1TntpIMkC9mQtNXl6Cn0fRSakjGLCVpkGSfL+tPEsTHqzvJA+D82ZstJcIYIzKLPRAfnhPJuN7KvdPLB+gBrBN9uozDZHxWrtJ0ICwkMcf9LFmhgXKNuqWIzDe7cPK4XZB1y6/OdUH7mppP2w== 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=Onpy1kkRICWFxoA9oo7egE+pqFVirCjboQuWK7dhRQs=; b=dTDMT8oYZs/8vu8tkzvgMG8mX+ySbKPh7JEQe/x2oF67QylGwlxjcGLvgQSigZelJ4tsoitWyKo4RMiYYZCs/gqdsbztFoJhELNOHQ37lKgjH6KswnNyhEYdsSb74Bl77D9E1XY8OSl/Ej87E/VVpteMHy0zvwtxqhiGXQXeGOA0TfPbhlHOoS7iE/7hjmXA1lbsIrsFxk56o+RzQnnRffw85DLk9bow+rhA2wGsV2ZBHXB6dxVOyrMnB5mhQGe+P+Y9aKPDk4RgFAOTRHwcgCRW3DKg0JpAZ3k/ThE+1TbppICFSNLXWcA56zCHAe4DQkxE2zurjvMkTYWy1RcIbg== 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=Onpy1kkRICWFxoA9oo7egE+pqFVirCjboQuWK7dhRQs=; b=lqhnKLkPwMTLhzJMClzmX2q0obIkVO6bVYTauBlrT8YfJ0ae2QBaw8exBzbtLU+EehjKdv2r9/wLMGdxBySO5FvHeTYd4v6ce6PsTSg+jlMhh3+yUm9MKLrjRPmF9nF19V3cOz5CC2Zjo2A/lKklJ2amQj3QLlglb42xm5V1wts= Received: from SA0PR15MB3791.namprd15.prod.outlook.com (2603:10b6:806:8d::10) by SN6PR15MB2447.namprd15.prod.outlook.com (2603:10b6:805:21::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3216.21; Tue, 28 Jul 2020 20:27:05 +0000 Received: from SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::3005:5e4b:252f:e9d1]) by SA0PR15MB3791.namprd15.prod.outlook.com ([fe80::3005:5e4b:252f:e9d1%4]) with mapi id 15.20.3216.033; Tue, 28 Jul 2020 20:27:05 +0000 From: Daniel Migault To: Ace Wg CC: "Ross, Michael D (54510) CIV USN NIWC ATLANTIC SC (USA)" , "Simon, Jonathan" , "Eliot Lear (elear)" , "Kedalagudde, Meghashree Dattatri" , "JP Vasseur (jvasseur)" Thread-Topic: ACE interim meeting tentative (Option2) Thread-Index: AdZfcUvc+ExZH1PwtkmFRgVQ81IInA== Importance: high X-Priority: 1 Date: Tue, 28 Jul 2020 20:27:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAAAAADB1MlLcV/WAQAAAAAAAAAAEAAAAAoo6O6QeX1Plnwd9W37qJ0= x-originating-ip: [96.22.11.129] x-ms-office365-filtering-correlation-id: e543dc7a-5b60-45ae-6826-08d833349837 x-ms-traffictypediagnostic: SN6PR15MB2447:MeetingMessage x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4303; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dRzj6z1Qd5/0LGP9IAYHRMOyjco9bpkvT97z1Z0/KoKiD9b0aw3HewQg6IySgJ6/eDgGbBqvaqY5hkr0Wjpqt/1OMwLrgBRLrxfP7mq5V9DK4ej8p41MCu8d+t5uTzUNfL2BlnTIHy0M9Qe2MrCThXY1vuC2B1CPeMVTQbdSAAQ+PEZ2he9fzBBTgDQm02OV2G8wY+LFONu7dnurxFEShNTC+EeFtwciR9AtPwWCOS1mulOvBVBBJTPYSa9ix5oWwdoa6a62ysrosXycyKvPZkOdILiKCEP6bVeNtedjLjcHtTDNRBrSmN++QCC+djitBRPYiAk3PjyZudWxfXp0WA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA0PR15MB3791.namprd15.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(366004)(346002)(396003)(136003)(376002)(64756008)(66946007)(66446008)(66556008)(66476007)(5660300002)(52536014)(558084003)(8676002)(44832011)(478600001)(86362001)(55016002)(76116006)(9686003)(7696005)(6506007)(316002)(54906003)(91956017)(4326008)(71200400001)(26005)(8936002)(186003)(33656002)(2906002)(6916009); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: boKyYr/p4zBAD4kbUnw3CtX559UAQ4HF4TkbLe+KfeTwLkleuL/g3D4OAtmXcXtqrL96BPTSEf7JreEjLNDN7BgzCZ+FM6HUM8zEr5Nnu6ow/Ww7la07dV1fUxzlgNrGrvHK/g8AirVa2ym8hzotB9XxO38KHLNTyEcPzlaWOov3VRWyKVvbax7oy7qQkVRGP/oiCCye2mQaZb/qdqG8cma82HZnFhCdWHISmSee/G+7aaSy1NxdkEBNF2y31fiphHezHGB/fnliARKSFrOitgvYAkCbLuOcOETWa+HF/gCKjTtWZsMmFDX9KM3krorYAc9g/3rFOQBtMrCNb0O0fGt4PZ+BjyqhL7IMhK4xT13lTCTEUnjsBTZ+T6pnpNlQHUWXGGuFSH107Er1udBkh5AMy2qxirc+5cq753wytvBAR1w+uksA4Kb+UrEacrc+dD8/JcHqGFKa1r69kZzIQh91o37L9xFafH4ZYUjRI9g= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA0PR15MB3791C8FDB6B73E401D1832CFE3730SA0PR15MB3791namp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR15MB3791.namprd15.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e543dc7a-5b60-45ae-6826-08d833349837 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2020 20:27:05.4922 (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: 6mN3IxKbBG/wExSpECK9BiF9Y5IAPmlVDsMEjTK6+vwCW19g4RoDsBz7NpciVuBLyHcbUtnZeUPdJaMvYc9dr99X/vvEJ7XE4wmrNgAx2ik= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR15MB2447 Archived-At: Subject: [Ace] Canceled: ACE interim meeting tentative (Option2) 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, 28 Jul 2020 20:27:08 -0000 --_000_SA0PR15MB3791C8FDB6B73E401D1832CFE3730SA0PR15MB3791namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Option 2 has not been selected by the WG. --_000_SA0PR15MB3791C8FDB6B73E401D1832CFE3730SA0PR15MB3791namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Option 2 has not been selected by the WG.
--_000_SA0PR15MB3791C8FDB6B73E401D1832CFE3730SA0PR15MB3791namp_ Content-Type: text/calendar; charset="utf-8"; method=CANCEL Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6Q0FOQ0VMDQpQUk9ESUQ6TWljcm9zb2Z0IEV4Y2hhbmdl IFNlcnZlciAyMDEwDQpWRVJTSU9OOjIuMA0KQkVHSU46VlRJTUVaT05FDQpUWklEOkVhc3Rlcm4g U3RhbmRhcmQgVGltZQ0KQkVHSU46U1RBTkRBUkQNCkRUU1RBUlQ6MTYwMTAxMDFUMDIwMDAwDQpU Wk9GRlNFVEZST006LTA0MDANClRaT0ZGU0VUVE86LTA1MDANClJSVUxFOkZSRVE9WUVBUkxZO0lO VEVSVkFMPTE7QllEQVk9MVNVO0JZTU9OVEg9MTENCkVORDpTVEFOREFSRA0KQkVHSU46REFZTElH SFQNCkRUU1RBUlQ6MTYwMTAxMDFUMDIwMDAwDQpUWk9GRlNFVEZST006LTA1MDANClRaT0ZGU0VU VE86LTA0MDANClJSVUxFOkZSRVE9WUVBUkxZO0lOVEVSVkFMPTE7QllEQVk9MlNVO0JZTU9OVEg9 Mw0KRU5EOkRBWUxJR0hUDQpFTkQ6VlRJTUVaT05FDQpCRUdJTjpWRVZFTlQNCk9SR0FOSVpFUjtD Tj1EYW5pZWwgTWlnYXVsdDptYWlsdG86ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tDQpBVFRF TkRFRTtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVF O0NOPUFjZSBXZzptYWkNCiBsdG86YWNlQGlldGYub3JnDQpBVFRFTkRFRTtST0xFPU9QVC1QQVJU SUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPSJSb3NzLCBNaWNoDQog YWVsIEQgKDU0NTEwKSBDSVYgVVNOIE5JV0MgQVRMQU5USUMgU0MgKFVTQSkiOm1haWx0bzptaWNo YWVsLmQucm9zczJAbmF2eS5tDQogaWwNCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BB UlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049IlNpbW9uLCBKb24NCiBhdGhhbiI6bWFp bHRvOkpvbmF0aGFuLlNpbW9uQGFuYWxvZy5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQ QU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049RWxpb3QgTGVhcg0KICAoZWxl YXIpOm1haWx0bzplbGVhckBjaXNjby5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5U O1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049IktlZGFsYWd1ZGQNCiBlLCBNZWdo YXNocmVlIERhdHRhdHJpIjptYWlsdG86bWVnaGFzaHJlZS5kYXR0YXRyaS5rZWRhbGFndWRkZUBp bnRlbC5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFD VElPTjtSU1ZQPVRSVUU7Q049SlAgVmFzc2V1cg0KICAoanZhc3NldXIpOm1haWx0bzpqdmFzc2V1 ckBjaXNjby5jb20NCkRFU0NSSVBUSU9OO0xBTkdVQUdFPWVuLVVTOk9wdGlvbiAyIGhhcyBub3Qg YmVlbiBzZWxlY3RlZCBieSB0aGUgV0cuXG4NClJSVUxFOkZSRVE9TU9OVEhMWTtVTlRJTD0yMDIx MTEwNlQxNDAwMDBaO0lOVEVSVkFMPTE7QllEQVk9MVRIDQpVSUQ6MDQwMDAwMDA4MjAwRTAwMDc0 QzVCNzEwMUE4MkUwMDgwMDAwMDAwMEMxRDRDOTRCNzE1RkQ2MDEwMDAwMDAwMDAwMDAwMDANCiAw MTAwMDAwMDAwQTI4RThFRTkwNzk3RDRGOTY3QzFERjU2REZCQTg5RA0KU1VNTUFSWTtMQU5HVUFH RT1lbi1VUzpDYW5jZWxlZDogQUNFIGludGVyaW0gbWVldGluZyB0ZW50YXRpdmUgKE9wdGlvbjIp DQpEVFNUQVJUO1RaSUQ9RWFzdGVybiBTdGFuZGFyZCBUaW1lOjIwMjAwOTAzVDEwMDAwMA0KRFRF TkQ7VFpJRD1FYXN0ZXJuIFN0YW5kYXJkIFRpbWU6MjAyMDA5MDNUMTEwMDAwDQpDTEFTUzpQVUJM SUMNClBSSU9SSVRZOjENCkRUU1RBTVA6MjAyMDA3MjhUMjAyNzA1Wg0KVFJBTlNQOlRSQU5TUEFS RU5UDQpTVEFUVVM6Q0FOQ0VMTEVEDQpTRVFVRU5DRTo0DQpMT0NBVElPTjtMQU5HVUFHRT1lbi1V UzoNClgtTUlDUk9TT0ZULUNETy1BUFBULVNFUVVFTkNFOjQNClgtTUlDUk9TT0ZULUNETy1PV05F UkFQUFRJRDoyMTE4NjI1NzI5DQpYLU1JQ1JPU09GVC1DRE8tQlVTWVNUQVRVUzpGUkVFDQpYLU1J Q1JPU09GVC1DRE8tSU5URU5ERURTVEFUVVM6RlJFRQ0KWC1NSUNST1NPRlQtQ0RPLUFMTERBWUVW RU5UOkZBTFNFDQpYLU1JQ1JPU09GVC1DRE8tSU1QT1JUQU5DRToyDQpYLU1JQ1JPU09GVC1DRE8t SU5TVFRZUEU6MQ0KWC1NSUNST1NPRlQtRE9OT1RGT1JXQVJETUVFVElORzpGQUxTRQ0KWC1NSUNS T1NPRlQtRElTQUxMT1ctQ09VTlRFUjpGQUxTRQ0KRU5EOlZFVkVOVA0KRU5EOlZDQUxFTkRBUg0K --_000_SA0PR15MB3791C8FDB6B73E401D1832CFE3730SA0PR15MB3791namp_-- From nobody Tue Jul 28 15:10:18 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 BDCDA3A091B; Tue, 28 Jul 2020 15:10:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159597421553.9501.5726884437980430214@ietfa.amsl.com> Date: Tue, 28 Jul 2020 15:10:15 -0700 Archived-At: Subject: [Ace] Authentication and Authorization for Constrained Environments (ace) WG Virtual Meeting: 2020-09-07 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, 28 Jul 2020 22:10:16 -0000 The Authentication and Authorization for Constrained Environments (ace) WG will hold a virtual interim meeting on 2020-09-07 from 10:00 to 11:00 America/New_York (14:00 to 15:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/webappng/sites/ietf/meeting/info/168045235929099520?MTID=m1f34280a8246b00df47684851bb987f7 From nobody Tue Jul 28 15:10:37 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 3DE9D3A0A81; Tue, 28 Jul 2020 15:10:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: ace@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159597423020.8462.8580841649262510880@ietfa.amsl.com> Date: Tue, 28 Jul 2020 15:10:30 -0700 Archived-At: Subject: [Ace] Authentication and Authorization for Constrained Environments (ace) WG Virtual Meeting: 2020-10-05 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, 28 Jul 2020 22:10:36 -0000 The Authentication and Authorization for Constrained Environments (ace) WG will hold a virtual interim meeting on 2020-10-05 from 10:00 to 11:00 America/New_York (14:00 to 15:00 UTC). Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/webappng/sites/ietf/meeting/info/168045408910584965?MTID=mfe71dc1bf187784b04a3a63b589d7c26 From nobody Wed Jul 29 12:10:56 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 7B1373A0E36 for ; Wed, 29 Jul 2020 12:10:53 -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 iHep05p4LOOW for ; Wed, 29 Jul 2020 12:10:51 -0700 (PDT) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 857023A0E39 for ; Wed, 29 Jul 2020 12:10:51 -0700 (PDT) Received: by mail-ua1-x930.google.com with SMTP id r63so7946407uar.9 for ; Wed, 29 Jul 2020 12:10:51 -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=e8i3RgqapsFq9dG4OrXJlDTxCsWqPyT92FtMwrSInfc=; b=Vwdi3eLAml0LfV8Nw1shQsdTqm8+HxYzGMVBn+Hd00E+GDldrXiU7nIo/QSAAsa8vH UQjCOO5pECEBtPZB4j9I/rNNMBNKdU7LI9MwxRNwUN5xv7nfAbzuXIHHVJT2ftOkylAw QKprNil2O8OOTHFi4+I2dDrD30T2V9g8/snTzbjfPDx6TS3nyZ+FVaTHPiHQsczlQQ8p NLEYy6XxxW3hc9uVHMbxEQh1MMfd+/FjdWqzCQLkf6VTUft4wgUFrP7DRcoHUqthMXk/ WEjA5G99WnnC2lvgzStN4GIBBWzp15JrAg52altvnkiQpnpSHD/LTWh79AQNTvYq8U+O GNQQ== 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=e8i3RgqapsFq9dG4OrXJlDTxCsWqPyT92FtMwrSInfc=; b=cvPH3m9QIcyaGtA14cKtNLP7tsEVcpPqYDIOpn07rE9jEaxnQhgWs8W6txl3+XIr3e kLjCKWiZd0yVQcLdIBnErOrAXtUxPyEI/BYXdSLsMNa8egx8QXuJjO5Ps1s0svEOcG5v OVb1yedN+1YUMJniZxpDueJYbqU36LnPeBNiZufaPx2TaQ8N/kpkxxT9O4IcTGiJ62Xn ctjq8JCaqZSKRwXjLgAARLEaOmy0y8EmFukZLbjkb8ldmA0V7ed/G6lDinptrLNESbEF 2E9rdSeMChbvdX71HwJAULDm40EsDqJ3vSrTkj2Uurjqs/LKwhXvYySJlDRPmzWOAtz/ Ya7A== X-Gm-Message-State: AOAM531qho2deFzYsFne//OZuElcfRXrv9fOU/aX7e9i+B4O28ahupUR xllzA0qV8CfvTaknnu7UHgJvgZuw/IHJW4iIIkeEZA== X-Google-Smtp-Source: ABdhPJyXI9XsMo8/CNRHnReMztQBqtcZjazxqToMdLr+bmj/erVfrQOJD2cqNcH4swSmBrGje7bvLO1u9r+IknWTG58= X-Received: by 2002:ab0:2b08:: with SMTP id e8mr24544732uar.119.1596049850411; Wed, 29 Jul 2020 12:10:50 -0700 (PDT) MIME-Version: 1.0 References: <010101d65ae9$bdffb520$39ff1f60$@augustcellars.com> In-Reply-To: From: Daniel Migault Date: Wed, 29 Jul 2020 15:10:39 -0400 Message-ID: To: Cigdem Sengul Cc: Ace Wg Content-Type: multipart/alternative; boundary="00000000000060ad7f05ab9950a7" Archived-At: Subject: Re: [Ace] Working Group Adoption Call for draft-bormann-core-ace-aif 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, 29 Jul 2020 19:10:54 -0000 --00000000000060ad7f05ab9950a7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, This email closes the call for adoption. The document as been adopted as WG document. Please upload the document as an ietf wg document. Yours, Daniel On Tue, Jul 28, 2020 at 9:31 AM Cigdem Sengul wrote: > Hello, > > I support the adoption as well. As Jim said, the MQTT-TLS profile has > adopted the AIF-MQTT for the scope. > > Thanks, > --Cigdem > > On Tue, Jul 28, 2020 at 2:25 PM Marco Tiloca wrote: > >> Hi all, >> >> I support adoption of this document and I am willing to review it. >> >> The approach in ace-key-groupcomm-oscore for joining OSCORE groups is >> now using an AIF specific data model, also included in our ACE >> implementation for Californium. >> >> I plan to extend the implementation to support the Extended >> REST-specific model. >> >> Best, >> /Marco >> >> On 2020-07-15 22:51, Jim Schaad wrote: >> > I had been holding off doing an adoption call waiting for a formal >> request >> > to adopt it. However, given that this is now a dependency for three >> > different WG documents I think we need to do this now. >> > >> > Adoption call for >> > https://datatracker.ietf.org/doc/draft-bormann-core-ace-aif/ >> > >> > This document provides a template for an authorization information >> format >> > (AIF) using a CDDL generic. Questions to be answered: >> > >> > 1. Do you think the ACE WG should adopt this document? If not please >> > provide some reasoning. >> > >> > 2. If adopted are you willing to review the document? >> > >> > 3. Would you have any implementation plans? Currently this is >> referenced >> > by the MQTT-TLS document, the Group KDC documents. >> > >> > Adoption call ends on July 28. >> > >> > Jim & Daniel >> > >> > >> > _______________________________________________ >> > Ace mailing list >> > Ace@ietf.org >> > https://www.ietf.org/mailman/listinfo/ace >> >> -- >> 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 >> >> >> _______________________________________________ >> 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 Daniel Migault Ericsson --00000000000060ad7f05ab9950a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

This email closes the call fo= r adoption. The document as been adopted as WG document. Please upload the = document as an ietf wg document.=C2=A0

Yours,=C2= =A0
Daniel=C2=A0

On Tue, Jul 28, 2020 at 9:31 AM Cigdem Seng= ul <cigdem.sengul@gmail.com> wrote:
Hello,

I support the adoption as well. As Jim s= aid, the MQTT-TLS profile has adopted the=C2=A0AIF-MQTT=C2=A0for the scope.
=

Thanks,
--Cigdem

On Tue, Jul 28, 2020 at= 2:25 PM Marco Tiloca <marco.tiloca@ri.se> wrote:
Hi all,

I support adoption of this document and I am willing to review it.

The approach in ace-key-groupcomm-oscore for joining OSCORE groups is
now using an AIF specific data model, also included in our ACE
implementation for Californium.

I plan to extend the implementation to support the Extended
REST-specific model.

Best,
/Marco

On 2020-07-15 22:51, Jim Schaad wrote:
> I had been holding off doing an adoption call waiting for a formal req= uest
> to adopt it.=C2=A0 However, given that this is now a dependency for th= ree
> different WG documents I think we need to do this now.
>
> Adoption call for
> https://datatracker.ietf.org/doc/dr= aft-bormann-core-ace-aif/
>
> This document provides a template for an authorization information for= mat
> (AIF) using a CDDL generic.=C2=A0 Questions to be answered:
>
> 1.=C2=A0 Do you think the ACE WG should adopt this document?=C2=A0 If = not please
> provide some reasoning.
>
> 2.=C2=A0 If adopted are you willing to review the document?
>
> 3.=C2=A0 Would you have any implementation plans?=C2=A0 Currently this= is referenced
> by the MQTT-TLS document, the Group KDC documents.
>
> Adoption call ends on July 28.
>
> Jim & Daniel
>
>
> _______________________________________________
> Ace mailing list
> Ace@ietf.org
> https://www.ietf.org/mailman/listinfo/ace

--
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


_______________________________________________
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


--
Daniel Migault
Ericsson
--00000000000060ad7f05ab9950a7-- From nobody Wed Jul 29 12:12:45 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 3846E3A0E3C for ; Wed, 29 Jul 2020 12:12:43 -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 hYzl2LWSZ0bN for ; Wed, 29 Jul 2020 12:12:41 -0700 (PDT) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 ADEE03A0FA8 for ; Wed, 29 Jul 2020 12:12:20 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id o184so12684446vsc.0 for ; Wed, 29 Jul 2020 12:12:20 -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=UPYV0u0qnqfQv92HU+Y91GJKfNuWAT3lOIwpNRBhEvM=; b=VLRJjATr/TB6cJeSx2/x67tv3JoUlktCDt2QPjEZclr83Mtrp8ZK797Z4i+vwqPCbb Y2IowB1E8YRcJDuoA2HDZBMiTPESmynlmW9HNVgnrhFMvv02tOVjnd+L0z4StMzdvHvH 7b8asUYCsdKqKYPvUAq2bDh0KBLy52nKWZrU2AoWZDA4+WMVEW1s9tNVC+pgcbIUoy13 Q8wdWJF8OmFjmvEtN0zqWV0AOr6MjTPFhCbj9PD/3flbZmaHAaJR9RSdR45g6wqSEMZA CsK6FU3Nf75ze2G139nulhasYehCsJHpEQPWm89IKoZDoRqxsVuB6jvekLKudINkkFn2 EOxg== 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=UPYV0u0qnqfQv92HU+Y91GJKfNuWAT3lOIwpNRBhEvM=; b=VgUCj3hSfLI+IOHa7YqkviTUWyRVftLCpHM2iQC3aYgh4GSHLXBuDM9U9M1gPIrDzm e7OkWAWBhMDjIrTSBiP+eu3UA5QKCzW+1lnfhIUn6hu1CFji11RSsiIo6WIjJaFe+/xb an5EK89bldM2E1Uf3zU6C6MtQGGP+fYEqzX2/fffQHM89fu4gqXAIdZqhdjQWEZX65KX lZ76fGmJHyUVYMyEw9wnplUouq56kFydOWPCI7JEhDpmA1UBS0qMpr1dpH6kmALFx36l guPbGtWvcBDaCreXKGr9Uhia9sEgs2wXisV0f1zId7fP+UY1ii/f9FowindvFdyLSRqF K/Lg== X-Gm-Message-State: AOAM531pAqIGR0BM02QODqsB30I2um2Zlixwi5Q13vMXY2PjqfJ1g+9+ kNCaHaxjklDw3C4Hedza2j7YkdqC2I00yQA0lioR1w== X-Google-Smtp-Source: ABdhPJzGTjT+H4JkxW0SElcdt8ZevlYVChas/iwBlF4WdxPPhXebG2hTFmfaepWNdZcPWXPx7zPAbjS/vodvDmBrc+U= X-Received: by 2002:a05:6102:3183:: with SMTP id c3mr2735277vsh.97.1596049939699; Wed, 29 Jul 2020 12:12:19 -0700 (PDT) MIME-Version: 1.0 References: <9FA64FFA-7887-433A-B96F-A953F73145D9@ericsson.com> In-Reply-To: <9FA64FFA-7887-433A-B96F-A953F73145D9@ericsson.com> From: Daniel Migault Date: Wed, 29 Jul 2020 15:12:09 -0400 Message-ID: To: Francesca Palombini Cc: Ace Wg Content-Type: multipart/alternative; boundary="000000000000b31c4c05ab995521" 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: Wed, 29 Jul 2020 19:12:43 -0000 --000000000000b31c4c05ab995521 Content-Type: text/plain; charset="UTF-8" This email closes the call for adoption. The document has been adopted. Please upload the document as an IETf WG document. Yours, Daniel On Tue, Jun 23, 2020 at 9:45 AM Francesca Palombini < francesca.palombini@ericsson.com> wrote: > Hi, > > > > I have reviewed the document and I believe this will be helpful for the > work we are doing in Ace. +1 for adoption. > > > > Thanks, > Francesca > > > > *From: *Ace on behalf of Daniel Migault < > mglt.ietf@gmail.com> > *Date: *Monday, 22 June 2020 at 22:31 > *To: *Ace Wg > *Subject: *[Ace] Call for adoption draft-tiloca-ace-oscore-gm-admin > > > > 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 > -- Daniel Migault Ericsson --000000000000b31c4c05ab995521 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This email closes the call for adoption. The document has = been adopted. Please upload the document as an IETf WG document.
Yours,= =C2=A0
Daniel

On Tue, Jun 23, 2020 at 9:45 AM Francesca Palombini &= lt;francesca.palombini@= ericsson.com> wrote:

Hi,

=C2=A0

I have reviewed the document and I believe thi= s will be helpful for the work we are doing in Ace. +1 for adoption.=

=C2=A0

Thanks,
Francesca

=C2=A0

From: Ace <ace-bounces@ietf.org> o= n behalf of Daniel Migault <mglt.ietf@gmail.com>
Date: Monday, 22 June 2020 at 22:31
To: Ace Wg <ace= @ietf.org>
Subject: [Ace] Call for adoption draft-tiloca-ace-oscore-gm-admin=

=C2=A0

Hi,=C2=A0

=C2=A0

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=C2= =A0WG=C2=A0should=C2=A0adopt or not this document.<= /u>

=C2=A0

Yours,=C2=A0

Jim and Daniel

=C2=A0

[1] https://datatracker.ietf.org/doc/draft-tiloca-ace-osc= ore-gm-admin/

=C2=A0

--

Daniel Migault

Ericsson



--
Daniel Migault
Ericsson
--000000000000b31c4c05ab995521-- From nobody Wed Jul 29 14:10: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 89CE53A0FF6; Wed, 29 Jul 2020 14:10:42 -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.11.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159605704242.25955.10874624468182331554@ietfa.amsl.com> Date: Wed, 29 Jul 2020 14:10:42 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-aif-00.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, 29 Jul 2020 21:10: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 : An Authorization Information Format (AIF) for ACE Author : Carsten Bormann Filename : draft-ietf-ace-aif-00.txt Pages : 11 Date : 2020-07-29 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-ietf-ace-aif/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-aif-00 https://datatracker.ietf.org/doc/html/draft-ietf-ace-aif-00 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 Jul 30 05:39: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 3DB913A10E3; Thu, 30 Jul 2020 05:39: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.12.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ace@ietf.org Message-ID: <159611278018.23310.2788448148978735051@ietfa.amsl.com> Date: Thu, 30 Jul 2020 05:39:40 -0700 Archived-At: Subject: [Ace] I-D Action: draft-ietf-ace-oscore-gm-admin-00.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, 30 Jul 2020 12:39: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 : Admin Interface for the OSCORE Group Manager Authors : Marco Tiloca Rikard Hoeglund Peter van der Stok Francesca Palombini Klaus Hartke Filename : draft-ietf-ace-oscore-gm-admin-00.txt Pages : 29 Date : 2020-07-30 Abstract: Group communication for CoAP can be secured using Group Object Security for Constrained RESTful Environments (Group OSCORE). A Group Manager is responsible to handle the joining of new group members, as well as to manage and distribute the group key material. This document defines a RESTful admin interface at the Group Manager, that allows an Administrator entity to create and delete OSCORE groups, as well as to retrieve and update their configuration. The ACE framework for Authentication and Authorization is used to enforce authentication and authorization of the Administrator at the Group Manager. Protocol-specific transport profiles of ACE are used to achieve communication security, proof-of-possession and server authentication. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ace-oscore-gm-admin/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ace-oscore-gm-admin-00 https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-gm-admin-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jul 31 02:28: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 F17CA3A1168; Fri, 31 Jul 2020 02:28:30 -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 yBtDLgFx47Ud; Fri, 31 Jul 2020 02:28:28 -0700 (PDT) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286A03A1165; Fri, 31 Jul 2020 02:28:26 -0700 (PDT) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id CFE6940752; Fri, 31 Jul 2020 11:28:24 +0200 (CEST) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 88F58AB; Fri, 31 Jul 2020 11:28:23 +0200 (CEST) Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:4ccb:b950:f051:b4e2]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 38EC0180; Fri, 31 Jul 2020 11:28:23 +0200 (CEST) Received: (nullmailer pid 2762114 invoked by uid 1000); Fri, 31 Jul 2020 09:28:22 -0000 Date: Fri, 31 Jul 2020 11:28:22 +0200 From: christian@amsuess.com To: ace@ietf.org, draft-ietf-ace-key-groupcomm@ietf.org Message-ID: <20200731092822.GA2614928@hephaistos.amsuess.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="45Z9DzgjV8m4Oswq" Content-Disposition: inline Archived-At: Subject: [Ace] Review of ietf-ace-key-groupcomm-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: Fri, 31 Jul 2020 09:28:32 -0000 --45Z9DzgjV8m4Oswq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Francesca, Marco and ACE, I've had a bit of a hard time working through ace-key-groupcomm (and the associated OSCORE adaption); here's what I think makes it difficult: (It may be worth pointing out that my perspective in reading was joining a group as a monitor device, which may explain my points of attention or lack thereof) * Some example exchange ... somewhere would make it easier to digest. I'm not saying that every step needs one here (and am aware that I have a tendency to overdo it myself), but skimming through examples often allows getting a rough idea much more quickly than having it develop while going through the text. * The way groupcomm-specific data is exchanged in the token phase violates the layering of ACE as I see it. The whole section 3 (Authorization to Join a Group) should be expressible a few paragraphs. Figure 2 already indicates that ("Defined in the ACE framework"), yet it spans 7 pages. The part where outlines how scope is expressed w/rt groups is good, that needs to be there. Then there are sign_info and kdcchallenge, which are for the next bullet. Apart from that, it largely reads like a repetition of general ACE. That may be justified by the intention to make it usable for readers who didn't go through the rest of ACE before, but then please mark it as such. (To illustrate: In 3.2 around rs_cnf I started wondering whether that might apply when asymmetric keys are used in the group because I never had to deal with rs_cnf, just to realize that it's some ACE transport profiles that use it. I've only used ACE-OSCORE so far, and sure there's several generic ACE mechanisms I haven't used, but why is this piece of information occupying my time here?). * Join components in the Token phase I understand sign_info and kdcchallenge to be process optimizations that allow joining the group with fewer round-trips. The point they are introduced at does not make this obvious, though -- the reader is right in the middle of going through the ACE part and possibly trying to figure out what they already have implemented and what's changed here. Frankly, if there were a better way to bundle compressed requests ("and by the way, of the things I'm now authorized to see, give me the sign_info") or unsolicited responses ("and by the way, if you tried to register with a public key, you'd fail because you don't have a kdcchallenge, so here's one to get started"), I'd suggest it here, but I don't have anything written I could refer you to. But from a teaching and understanding point of view, I think that it'd be better structured about like this: * In the very short ACE section, add an item that "Parts of the following group joining process can be rolled into the token exchange. They manifest in a sign_info entry in the token request, and a kdcchallenge in the token response (which is then an application/ace+cbor representation rather than empty). These can be added by the parties to save round-trips and are described in detail in appendix X. While it is RECOMMENDED that they are used when adaequate, parties MAY ignore them (but MUST NOT fail the process just because they find them in a message)." * Then explain the process from a client not having a kdcchallenge (or having a stale one, or not even having sign_info) with the clear separation of ACE tasks and interactions with the protected resource (the join resource). Here may be a place for a note about the option to optimize away the step by using appendix X. * Then, in the appendix, use the established knowledge of what sign_info and the challenge do to concisely map the data items piggy-backed on the token exchange into information populating the client's cache of the groups. * On the AIF: The first parameter of the AIF is said to be "the identifier of the specific group or topic". I suppose the identifier cleanup will make this clearer. As it's described as a default, how is that overridden, and how does the client know whether it can just construct a scope or has to try first and wait for the KDC to give it a good value in a 4.01? * 4.1.2.2 GET handler of /ace-group/GROUPNAME: Why MUST requests from authorized (as per third paragraph) but non-member (as per fourth) clients turned down with 4.00?=20 The only reason I can think of to deny that would be running an audit trail of which authorized clients actually joined (to see when to rekey after a compromise), but as that sounds like it's within range of the permissive side effects a GET could have just as well (as per RFC7231 Section 4.2.1), so rather than refusing, the GET could just be served and the audit entry created. (Otherwise, my gut feeling says this should be a 4.01 response as well, but maybe we don't need to have that discussion in the first place). * If, of course, the client's scope is only to get public keys of the group but not the cryptographic material (as might be for scenarios where there is a verifier), then that client would not be allowed to GET that data, and should be 4.01'd no matter whether it has actually joined the group nor not. That case seems not to be covered well in the 4.1.2.2 GET handler description: Neither check ("group is in scope", "is a current member") really accounts for that. (The 'signature verifier' role of -oscore says "does not join [...] as an *actual* member", but I wouldn't count on everyone reading that as "not a member at all" for the purpose of the above paragraph). * 4.1.3.1 and 4.1.3.2 (/ace-group/GROUPNAME/pub-key FETCH):=20 The "The handler verifies that" and "Note that this resource handler" appear to contradict each other (or the latter overrides the former); it would be easier to understand if they were rolled in one. The former reads like boilerplate text; I'd rather see that avoided ("For all resources, X and Y apply") or referenced if the reader can't be trusted to read the whole document ("General authentication requirements per Section X apply."). Defined terminology may help there as well ("is Authenticated As a group member", "is Authenticated As the group member identified by NODENAME" in other places). * 4.1.3.1 and 4.1.3.2 (/ace-group/GROUPNAME/pub-key GET and FETCH):=20 The GET text reads like a duplicate of the FETCH text. Can't this be a simple "GET requests are served just like FETCH requests but without any filtering"? * GROUPNAME/num: Is there a particular reason this is a dedicated resource and not just accessed through GROUPNAME? * request latest keying material "To this end, the Client sends a CoAP GET request to the /ace-group/GROUPNAME/nodes/NODENAME endpoint at the KDC, formatted as specified in Section 4.1.6.2." What's the purpose of the node observing its own resource rather than the the whole group? After all, its own keys won't change out of the blue, just the group's material. * I'm a bit uncertain about the change of keys mid-blockwise, but can't put a finger on it yet. Do you have any use case examples that'd help me figure out what such an operation would look like in the first place? * IANA File Extension: Why? * I've only skimmed section 8. Kind regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --45Z9DzgjV8m4Oswq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAl8j5DIACgkQOY0REtOk veHjpRAAlvuA40pVNiX3BjA0IbpEO3BpOmw4DZ8msGLUoVZpu4G1ss4g0yPJ3Jve KZnBDp+0FiGbSkpVHuXyoadDEUnlB/IzL7x/OzNORs6EL1km+YR92Uxfx6jKG2vr DR4jHpufwMz9R5PtkAiZAGCJAJcqDP2+HNJ6M4HxaH3xW6lvUS7piWWkfcoWczfy 4KsVbLXU9W+Y2qos+B7pA9U63YJID59X3xL6MiWWmskcdK3kpN4bItOSgBiFcuKm lT0BesGu4IUppS3qDdHsvBrdnsS934i9x9d6gcb/McBTFo2OttrfoxkIa8RxO71L wH3Yku6jqkeYExvpuSB3DdJs16IcKFYij4akTZoB4VMA+vzccrYoM87xjDqeVR1m jzIH8FuRFrW74/SreR8uh+qxUiaeicnEFTUbFFfzyGmme5Py2mlEGprWytF9wDhu GKd/XEysvnmCQ1kDe6INCxGqlwVDDun4sMS8xb3UcXDDk5wWEGkHotmk90pdeVas Tt5buju0W4ZB+NZ3YLG4USddO44fbKxhw/9jA19MBZJsNQhH4qnnWEGTA0awzoY+ mMgZW+bYmv2PsLvlDwnsjI6DP2CdDRze4+plrY3a5APGn8owPqfpLIhcKS+VbtFm /b++9mPaAsQyY2+0hDEd7XVvicUAFrzKnkh5eIrgaw7oB4MDezA= =pKWu -----END PGP SIGNATURE----- --45Z9DzgjV8m4Oswq--