From nobody Thu Aug 1 11:02:48 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BDC01200E0; Thu, 1 Aug 2019 11:02:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alissa Cooper via Datatracker To: "The IESG" Cc: draft-ietf-anima-autonomic-control-plane@ietf.org, Sheng Jiang , anima-chairs@ietf.org, jiangsheng@huawei.com, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Alissa Cooper Message-ID: <156468256649.19179.7770603612379264669.idtracker@ietfa.amsl.com> Date: Thu, 01 Aug 2019 11:02:46 -0700 Archived-At: Subject: [Anima] Alissa Cooper's No Objection on draft-ietf-anima-autonomic-control-plane-20: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 18:02:47 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-anima-autonomic-control-plane-20: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. Original COMMENT is left below. General: Please address the Gen-ART reviewer's latest round of comments. There are a bunch of places in this document where it seems like there is a tension between specifying a limited set of functionality here and being able to support a wider variety of deployment scenarios. This is noted in Section 1 but I think in general it would be clearer if uses of the term "future" throughout the document could be more surgical as well as more specific about whether they mean "people might deploy this differently in the future" or "standards would need to be developed in the future." I've made a few suggestions about some of these turns of phrase below but would suggest someone do a full edit pass with this in mind because there are a large number of mentions of "future work." Of course there is always more work to do, but every bit of "future work" need not be mentioned in this document, and in cases where it is mentioned I think there should be a specific reason for doing so that bears on people implementing this specification. I don't think this fits in the DISCUSS criteria but for a document that intends to be published on the standards track I would expect it to be crisper about the dividing line between the normative behavior being specified here versus changes or extensions that may or may not be made in the future. "Intent" is used both capitalized and in lower case throughout the document and I'm unclear if this is meant to signify a distinction or not. Section 2: Please remove the -->"..."() notation. Please use the exact boilerplate from RFC 8174, not a variation. It seems like RFC citations should appear for IKEv2 and DTLS upon first use in this section. Otherwise, it seems they are first cited at different future points in the document (Section 6.3 and 6.7, respectively). Section 3.3: "The ACP provides reachability that is independent of the Data-Plane (except for the dependency discussed in Section 6.12.2 which can be removed through future work)," Isn't this kind of a big exception, given that there is meant to be a secure channel between pairs of nodes in the ACP and that developing future encapsulations is non-trivial? It seems like phrasing this the other way around (the ACP is dependent on the Data-Plane for but is otherwise independent of it) would be more accurate. Section 6: "Indestructible" seems like an overstatement. Maybe "resilient" would be more accurate? Section 6.1.1: s/Such methods are subject to future work though./No such methods have been defined at the time of publication of this document./ s/to build ACP channel/to build ACP channels/ s/that intends to be equally unique/that it intends to be equally unique/ ""rsub" is optional; its syntax is defined in this document, but its semantics are for further study. Understanding the benefits of using rsub may depend on the results of future work on enhancing routing for the ACP." What is the point of defining this now when it is unclear if or how it will be used? There are already means for nodes to do error handling, so it seems like defining a new field in the future if/when it is needed would work fine and be cleaner. Appendix A.7 seems to assume some semantics for this field, which makes the way it is specified here even more confusing IMO. "In this specification, the "acp-address" field is REQUIRED, but future variations (see Appendix A.8) may use local information to derive the ACP address. In this case, "acp-address" could be empty. Such a variation would be indicated by an appropriate "extension". If "acp-address" is empty, and "rsub" is empty too, the "local-part" will have the format "rfcSELF + + extension(s)". The two plus characters are necessary so the node can unambiguously parse that both "acp-address" and "rsub" are empty." This seems contradictory. Either "acp-address" is REQUIRED in which case there are no exceptions, or it's not; if it's not, then the expected syntax for cases when it's not present should be specified. Section 6.1.2: s/If the node certificates indicates/If the node certificate indicates/ Section 6.3: It seems odd to provide a citation/discussion for IKEv2 here but not for DTLS. Section 6.4: This is a good example of a section where the blurring between the specified behavior and expectations for the future is unhelpful IMO. Why specify the current default and then spend a lot of words (including Appendix A.7) talking about how it will be different in the future? Section 6.10.3.1: s/We do not think this is required at this point/This is not currently required/ Section 6.12.2: s/may specify additional layer 2 or layer encapsulations/may specify additional layer 2 or layer 3 encapsulations/ (I think?) Section 8.2.1: This seems extraneous: "Future work could transform this into a YANG ([RFC7950]) data model." Appendix A.8: "Secure channels may even be replaced by simple neighbor authentication to create simplified ACP variations for environments where no real security is required but just protection against non-malicious misconfiguration." I think experience has shown that even environments where it is assumed that security is not required prove to need it. I would suggest removing this text or changing this implication. From nobody Thu Aug 1 11:23:20 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01033120168; Thu, 1 Aug 2019 11:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, RCVD_IN_DNSWL_MED=-2.3, 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 VRstrcKFguJZ; Thu, 1 Aug 2019 11:23:10 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47ADB12013E; Thu, 1 Aug 2019 11:23:10 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 56F6E54800E; Thu, 1 Aug 2019 20:23:05 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 46157440041; Thu, 1 Aug 2019 20:23:05 +0200 (CEST) Date: Thu, 1 Aug 2019 20:23:05 +0200 From: Toerless Eckert To: Alissa Cooper Cc: The IESG , anima-chairs@ietf.org, draft-ietf-anima-autonomic-control-plane@ietf.org, anima@ietf.org, jiangsheng@huawei.com Message-ID: <20190801182305.hmfpkzbnblyarouh@faui48f.informatik.uni-erlangen.de> References: <156468256649.19179.7770603612379264669.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <156468256649.19179.7770603612379264669.idtracker@ietfa.amsl.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Alissa Cooper's No Objection on draft-ietf-anima-autonomic-control-plane-20: (with COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2019 18:23:13 -0000 Thank you ! On Thu, Aug 01, 2019 at 11:02:46AM -0700, Alissa Cooper via Datatracker wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-anima-autonomic-control-plane-20: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for addressing my DISCUSS. Original COMMENT is left below. > > General: > > Please address the Gen-ART reviewer's latest round of comments. > > There are a bunch of places in this document where it seems like there is a > tension between specifying a limited set of functionality here and being able > to support a wider variety of deployment scenarios. This is noted in Section 1 > but I think in general it would be clearer if uses of the term "future" > throughout the document could be more surgical as well as more specific about > whether they mean "people might deploy this differently in the future" or > "standards would need to be developed in the future." I've made a few > suggestions about some of these turns of phrase below but would suggest someone > do a full edit pass with this in mind because there are a large number of > mentions of "future work." Of course there is always more work to do, but every > bit of "future work" need not be mentioned in this document, and in cases where > it is mentioned I think there should be a specific reason for doing so that > bears on people implementing this specification. I don't think this fits in the > DISCUSS criteria but for a document that intends to be published on the > standards track I would expect it to be crisper about the dividing line between > the normative behavior being specified here versus changes or extensions that > may or may not be made in the future. > > "Intent" is used both capitalized and in lower case throughout the document and > I'm unclear if this is meant to signify a distinction or not. > > Section 2: > > Please remove the -->"..."() notation. > > Please use the exact boilerplate from RFC 8174, not a variation. > > It seems like RFC citations should appear for IKEv2 and DTLS upon first use in > this section. Otherwise, it seems they are first cited at different future > points in the document (Section 6.3 and 6.7, respectively). > > Section 3.3: > > "The ACP provides reachability that is independent of the Data-Plane > (except for the dependency discussed in Section 6.12.2 which can be > removed through future work)," > > Isn't this kind of a big exception, given that there is meant to be a secure > channel between pairs of nodes in the ACP and that developing future > encapsulations is non-trivial? It seems like phrasing this the other way around > (the ACP is dependent on the Data-Plane for but is otherwise independent > of it) would be more accurate. > > Section 6: > > "Indestructible" seems like an overstatement. Maybe "resilient" would be more > accurate? > > Section 6.1.1: > > s/Such methods are subject to future work though./No such methods have been > defined at the time of publication of this document./ > > s/to build ACP channel/to build ACP channels/ > > s/that intends to be equally unique/that it intends to be equally unique/ > > ""rsub" is optional; its syntax is defined in this document, > but its semantics are for further study. Understanding the benefits > of using rsub may depend on the results of future work on enhancing > routing for the ACP." > > What is the point of defining this now when it is unclear if or how it will be > used? There are already means for nodes to do error handling, so it seems like > defining a new field in the future if/when it is needed would work fine and be > cleaner. Appendix A.7 seems to assume some semantics for this field, which > makes the way it is specified here even more confusing IMO. > > "In this specification, the "acp-address" field is REQUIRED, but > future variations (see Appendix A.8) may use local information to > derive the ACP address. In this case, "acp-address" could be empty. > Such a variation would be indicated by an appropriate "extension". > If "acp-address" is empty, and "rsub" is empty too, the "local-part" > will have the format "rfcSELF + + extension(s)". The two plus > characters are necessary so the node can unambiguously parse that > both "acp-address" and "rsub" are empty." > > This seems contradictory. Either "acp-address" is REQUIRED in which case there > are no exceptions, or it's not; if it's not, then the expected syntax for cases > when it's not present should be specified. > > Section 6.1.2: > > s/If the node certificates indicates/If the node certificate indicates/ > > Section 6.3: > > It seems odd to provide a citation/discussion for IKEv2 here but not for DTLS. > > Section 6.4: > > This is a good example of a section where the blurring between the specified > behavior and expectations for the future is unhelpful IMO. Why specify the > current default and then spend a lot of words (including Appendix A.7) talking > about how it will be different in the future? > > Section 6.10.3.1: > > s/We do not think this is required at this point/This is not currently required/ > > Section 6.12.2: > > s/may specify additional layer 2 or layer encapsulations/may specify additional > layer 2 or layer 3 encapsulations/ (I think?) > > Section 8.2.1: > > This seems extraneous: "Future work could transform this into a YANG > ([RFC7950]) data > model." > > Appendix A.8: > > "Secure channels may > even be replaced by simple neighbor authentication to create > simplified ACP variations for environments where no real security is > required but just protection against non-malicious misconfiguration." > > I think experience has shown that even environments where it is assumed that > security is not required prove to need it. I would suggest removing this text > or changing this implication. > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Fri Aug 2 11:09:50 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB811207BB; Fri, 2 Aug 2019 11:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Fg32Qi7srGvr; Fri, 2 Aug 2019 11:09:40 -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 58B2E1207BF; Fri, 2 Aug 2019 11:09:39 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id k8so154137616iot.1; Fri, 02 Aug 2019 11:09:39 -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=x9TJOy1J/7OPrnppbDwqr5cEa1thV2lb1btdX4Gpdck=; b=qiste6FYq5FKNSjXLMPNN1KOvvpDt9k5DnIViQdABkK8BexHDhnoTUflZ5MqLu7GT4 fXxHJ5Q4DsVh7lYoxaLKCfZSQCQodEMm7pei5EX4afL1KKj5C+Waw0zfXkX07rvvVU42 fKdY+SFI1zuT012MK59wqQXCHUc+Boo6A7v9/oo6DevEmseSYI0Cdk1exjXCBjJ9TTh7 dOH1fUZRKnhR/BUXam7j3vhFrMDrb+9pFd1/y6/X36DuvdT4y56LTf9I5z2YZJMY+TLc nlDpNQAb5xHYSRHfa1W/Fgy8i/SlbwpFZaxHQjR452aNN2fqHFBVRG99SEeIyZ/8SWnD UwUg== 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=x9TJOy1J/7OPrnppbDwqr5cEa1thV2lb1btdX4Gpdck=; b=WE+mfU5FWCKzpHpzM0pQHnl/RcCDl85JNWNE3g1nAb7IVKDcMa3KkNhQGi4/3jqNWJ iqYW12MG7qtNYgw7YllCEDig2FWdm//rQnka6jGzvuRBULslpe3VbqdDFTQfAPThj29U rQ3lJ48ap+c2AQ+Nx1PO2NFqNgpRqDIoqUjlk7hq49vg2o+D6Tcw9WWCSEXsO8hziQCt vuvt36yYU8+LSt7DjIWBNR0+qohG2KO1QTY27nbdx032JMTuYuU6wXdpzR7KNEtwWQSf SI+K31nezeKUgX1URolz7fdHwWrIcpvMTaFBDa2j2NZkEBIoEl72ffl1mgQZjuCBE7pf yvkg== X-Gm-Message-State: APjAAAX9ZftR6OnJzT96SMCMFZqflrvEwcXub27hg5sCHN1uhbxjN5Du ExUMzwVwQKgpN2lc3Si3u728d0LurAA4s1yhTMClLDUWxEE= X-Google-Smtp-Source: APXvYqynr9Rc51Wquxr0HGj0I1kH0UPOD0W+05SlAd6YFncFe2X76DhLDldpp7/SHaXHd2LnqyN72LcBuI4dbrIBTHg= X-Received: by 2002:a05:6638:3d2:: with SMTP id r18mr666750jaq.13.1564769378301; Fri, 02 Aug 2019 11:09:38 -0700 (PDT) MIME-Version: 1.0 From: Rifaat Shekh-Yusef Date: Fri, 2 Aug 2019 14:09:29 -0400 Message-ID: To: anima@ietf.org, iot-onboarding@ietf.org Content-Type: multipart/alternative; boundary="000000000000f2fad2058f2642da" Archived-At: Subject: [Anima] Device Certificate Deployment Automation with ACME using BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2019 18:09:43 -0000 --000000000000f2fad2058f2642da Content-Type: text/plain; charset="UTF-8" All, During the last IETF meeting in Montreal we had a side meeting to discuss the deployment automation of ACME issued certificates to devices, and the potential use of the BRSKI mechanism to help with this. It was clear from the discussion that BRSKI can be used to help address this use case, and that further discussion is needed to define the needed enhancements to BRSKI. The current BRSKI mechanism only briefly discusses the Cloud Registrar option in section 2.7, which could be used to help address this use case. Michael Richardson and I had another meeting over lunch yesterday to further discuss this and we decided to work on a new draft to describe the issue and define a solution. Because of vacations and other commitments, we will try to publish the first version of the draft early October. Regards, Rifaat & Michael --000000000000f2fad2058f2642da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

During the last IETF meeting in Montreal we had a side meeting to discu= ss the=C2=A0
deployment automation of ACME issued certificates to devices, and t= he potential=C2=A0
use of the BRSKI mechanism to help with this. It was clear fr= om the discussion=C2=A0
that BRSKI can be used to help address this use case, an= d that further discussion is=C2=A0
needed to define the needed enhancements to B= RSKI.

<= span style=3D"color:rgb(0,0,0)">The current BRSKI mechanism only briefly di= scusses the Cloud Registrar option in=C2=A0
section 2.7, which could be used to = help address this use case.

Michael Richardson a= nd I had another meeting over lunch yesterday to further=C2=A0
discuss this and = we decided to work on a new draft to describe the issue and=C2=A0define a solut= ion.

Because of vacations and other commitments, = we will try to publish the first=C2=A0
version of the draft early October.

Regards,
=C2=A0Rifaat & Michael=C2=A0=C2=A0
=
--000000000000f2fad2058f2642da-- From nobody Mon Aug 5 20:07:16 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92C84120111; Mon, 5 Aug 2019 20:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 3VRughD3004I; Mon, 5 Aug 2019 20:07:13 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 E3BF9120115; Mon, 5 Aug 2019 20:07:12 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id A2B4EE875A96C31EC22A; Tue, 6 Aug 2019 04:07:10 +0100 (IST) Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 6 Aug 2019 04:07:10 +0100 Received: from lhreml708-chm.china.huawei.com (10.201.108.57) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 6 Aug 2019 04:07:10 +0100 Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml708-chm.china.huawei.com (10.201.108.57) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Tue, 6 Aug 2019 04:07:09 +0100 Received: from NKGEML515-MBS.china.huawei.com ([169.254.5.242]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0439.000; Tue, 6 Aug 2019 11:06:55 +0800 From: Sheng Jiang To: "anima@ietf.org" CC: "anima-chairs@ietf.org" , "Liguangpeng (Roc, Network Technology Laboratory)" , "Liubing (Leo)" Thread-Topic: ANIMA minutes - IETF105 Montreal, Canada Thread-Index: AdVMA/5QLaU4zcPAT46IMbZrDsEvTg== Date: Tue, 6 Aug 2019 03:06:54 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9299A80D70@NKGEML515-MBS.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.185.119] Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B9299A80D70NKGEML515MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Anima] ANIMA minutes - IETF105 Montreal, Canada X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 03:07:15 -0000 --_000_5D36713D8A4E7348A7E10DF7437A4B9299A80D70NKGEML515MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, all, The minutes for the ANIMA sessions at IETF105 in Montrealcan be found at: https://datatracker.ietf.org/doc/minutes-105-anima/ Many thanks to Guangpeng Li, Bing Liu for taking minutes. Please send any corrections to the chairs. Best regards, Sheng --_000_5D36713D8A4E7348A7E10DF7437A4B9299A80D70NKGEML515MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Hi, all,
 
The minutes for the ANIMA sessions a=
t IETF105 in Montrealcan be found at:
 

https://datatracker.ietf.org/doc/minutes-1= 05-anima/

 
Many thanks to Guangpeng Li, Bing Li=
u for taking minutes.
 
Please send any corrections to the c=
hairs.
 
Best regards,

 


Sheng
--_000_5D36713D8A4E7348A7E10DF7437A4B9299A80D70NKGEML515MBSchi_-- From nobody Tue Aug 6 06:05:35 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE856120182; Tue, 6 Aug 2019 06:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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=h8zbGema; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=usSMb//+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gozgpRjbRcdd; Tue, 6 Aug 2019 06:05:29 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B98C12013E; Tue, 6 Aug 2019 06:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35545; q=dns/txt; s=iport; t=1565096729; x=1566306329; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Qj6K71pRIp2teNpXMhSYBUCEQheaeEV0PEIJvDIgfOA=; b=h8zbGemaCXlX928mRkGm9bxxcEyF3CnfjF5WpY8E+OtsPcfDfHApRouN yU7PmCZ324hWDSwYV3cJ05C+604szpRZz5rXo96yzI152NTo5uBLjfxe5 cOGkAd2f3KOWa9rxxiyiUluYarLL5+Y4FGrD1OYPEd05a3NayzEX+kpTB c=; X-Files: draft-friel-brski-cloud.md : 16965 IronPort-PHdr: =?us-ascii?q?9a23=3AaGYHxxHpOvQ9xyVacsROrZ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w3Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efnkdS03GOxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CNAABiekld/4UNJK1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBUwcBAQsBgRUvJCwDbVUgBAsqCoQUg0cDhFKGXkyCD5MEhFeBLoEkA1Q?= =?us-ascii?q?CBwEBAQkDAQEtAgEBhD8CF4InIzQJDgEDAQEBBAEBAgEGbYUnDIVKAQEBAQM?= =?us-ascii?q?SEQoTAQE4DwIBCBEEAQErAgICMB0IAgQBEggGDQeDAYEcTgMdAQKhCQKBOIh?= =?us-ascii?q?gcYEygnoBAQWFDBiCDAcJgTQBgVCIUYFBF4FAP4ERRoIeLj6ERoMJMoImjCK?= =?us-ascii?q?CaIUGgQQJlg8JAoIcgy2CII5vmCyEGokvl3ICBAIEBQIOAQEFgVA4gVhwFYM?= =?us-ascii?q?ngkI3gzqKU3KBKYwKAYEgAQE?= X-IronPort-AV: E=Sophos;i="5.64,353,1559520000"; d="md'?scan'208,217";a="313474558" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Aug 2019 13:05:28 +0000 Received: from XCH-ALN-016.cisco.com (xch-aln-016.cisco.com [173.36.7.26]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x76D5SrJ026846 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Aug 2019 13:05:28 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-016.cisco.com (173.36.7.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 6 Aug 2019 08:05:27 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 6 Aug 2019 08:05:26 -0500 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 6 Aug 2019 08:05:26 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M+Gu2GK2dJFkHn/mWPGp0V2XFhv+M0+wKDo5ZA+Hf1br/pcbNdyDyIUcBEPYIA59u93bcRSIb6nNx9BPhxV9QOK7ptkvTWgHQofMWJ7z02BOzZOemfHkDNBG46yeV27mtQk5ewjNSQ6tFPHILbxCQ4dVPvZHMinzGad1zGvVfpkE96gE+rPzSUwp4hpJ+aSatUFfUMk0li2fO99Ry7/iyfUddb4gXQKJZWL+3olIxG1j0ErqBPRjN8cMNRKTUHN0XB/L+bmHmsmUqps0Cizs8F1xTcSqHYmdYsV5FQphi3cSmokxwaDCU8/6C4QIk64F7kZfeW2nyIJEs115zH5hvA== 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=0dHXpNmefEH9eMb80vfzhOeAfaxq59lx3O3mIaX3yQY=; b=MZbGyMTpIaChqLkWNt1gOmPKGU+P2QR8Xq2oPkYfukY00YCIhz9w3VzkpH9tuOi4VhicoJUyXdZNs6QNn9GKqF3cqA56t8oVSJedDPm2HVyfcuR+cdqSEhBbUgpp8vrpzkFrconIHDAshFXhpxyPWLDu5C+/MaZjHPLPFGEDpKT7lQfsgB9ORniF8Ivsuisdyw6pN72/3ML4X6IMJrR5WOv3wkXkZ0ii4+nrEPtFVgZbKE2CybDnaxRSlDpFqSq/lSOoW9b0eTvjV+VjFnxh9gos63kblN7VjU+teX0rqsvSgwn077AawrnhDJpvyEPHcwb7bOmZwOF04YnLAgnwgQ== 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=0dHXpNmefEH9eMb80vfzhOeAfaxq59lx3O3mIaX3yQY=; b=usSMb//+U3PfyJzUfSrkBXrSb4E+uAfm7hqobpK0WjuuRbgfZfRd+9p091x0Ovar2/r2NCrkQqE8l6OUXC7lTVt1he+G8qYg+SdGelUguCa28GemlaS4TbCR9BF9o7EY0aEqoI/3925t6or0dVa6LZ/MbfxqsV7nbElIEX6k5ig= Received: from DM6PR11MB3385.namprd11.prod.outlook.com (20.176.123.12) by DM6PR11MB3737.namprd11.prod.outlook.com (20.179.16.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.13; Tue, 6 Aug 2019 13:05:25 +0000 Received: from DM6PR11MB3385.namprd11.prod.outlook.com ([fe80::21d7:6788:7090:d0ae]) by DM6PR11MB3385.namprd11.prod.outlook.com ([fe80::21d7:6788:7090:d0ae%7]) with mapi id 15.20.2115.005; Tue, 6 Aug 2019 13:05:24 +0000 From: "Owen Friel (ofriel)" To: Rifaat Shekh-Yusef , "anima@ietf.org" , "iot-onboarding@ietf.org" Thread-Topic: [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI Thread-Index: AQHVSV2H3NB63QcBKUu8AXFFCSgthabuGrdw Date: Tue, 6 Aug 2019 13:05:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [64.103.40.24] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c458845f-376d-4475-06aa-08d71a6ebef0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:DM6PR11MB3737; x-ms-traffictypediagnostic: DM6PR11MB3737: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(136003)(366004)(396003)(376002)(199004)(189003)(52536014)(81156014)(8676002)(478600001)(6436002)(81166006)(11346002)(256004)(7736002)(5024004)(9686003)(2501003)(74316002)(6306002)(54896002)(55016002)(33656002)(53936002)(8936002)(71200400001)(71190400001)(14454004)(66066001)(66556008)(66476007)(66616009)(476003)(64756008)(66446008)(66946007)(76116006)(25786009)(229853002)(110136005)(5660300002)(486006)(2906002)(316002)(99286004)(6506007)(53546011)(6246003)(2201001)(186003)(68736007)(86362001)(446003)(76176011)(3846002)(102836004)(6116002)(790700001)(7696005)(99936001)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB3737; H:DM6PR11MB3385.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ZJta8tqk8HsJpSlK1y+P4UCU8Ujzo0JNBa79Lh2PAZYsLKlhiYI9DO+jZ5Max7HvXkblhBZXZu7ihQM2UmpW0KJfsYMuHKJ52ZuCc/ZAz4m7FIcyqJrL2CHZTCGZZmlXbKUtGplpJW8ZNeT5Do2UFKJ4eN3jzaSh4P7WeQ4vzXucWXatu6RoTQENOx40oAWQNObbL49dPCI4NIqYSY96bRPYnlouX0I952VFW+tK1RP9X3JdQYd+jXBT4/Q3MdJ+zJUXg067FWbik+XE9FZzHg0cgzAiExTMnrtJ0l4pIrVe187jPzdySZTRMioaetBMhJDN0blBV57VRUWq36ZB2SzXlb0Ssg60TJti/pMyuLgqxG3yt7FrUnh+zWtaOX9tGHnDnpmhPbRlVSnd0hk2wAAu+aTvPX5TaVWDSd5Y4/Y= Content-Type: multipart/mixed; boundary="_004_DM6PR11MB3385FD834E826E25160B53AADBD50DM6PR11MB3385namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c458845f-376d-4475-06aa-08d71a6ebef0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2019 13:05:24.7621 (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: ofriel@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3737 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.26, xch-aln-016.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 13:05:32 -0000 --_004_DM6PR11MB3385FD834E826E25160B53AADBD50DM6PR11MB3385namp_ Content-Type: multipart/alternative; boundary="_000_DM6PR11MB3385FD834E826E25160B53AADBD50DM6PR11MB3385namp_" --_000_DM6PR11MB3385FD834E826E25160B53AADBD50DM6PR11MB3385namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgZ3V5cywNCg0KQWZ0ZXIgdGhlIG1lZXRpbmcgYW5kIGZyb20gY29ycmlkb3IgY29udmVyc2F0 aW9ucyB3aXRoIFRvZXJsZXNzLCBJIGhhZCBhY3R1YWxseSBhbHJlYWR5IHN0YXJ0ZWQgb24gc3Vj aCBhIGRyYWZ0Lg0KDQpXaGF0IEkgaGF2ZSBzdGFydGVkIHNvIGZhciBpcyBhdHRhY2hlZC4gSXRz IG5vdCBvbiBhIHB1YmxpYyByZXBvIHlldCwgYnV0IHdpbGwgcHV0IGl0IHRoZXJlLiBZb3UgYXJl IGFscmVhZHkgbmFtZWQgb24gaXQgUmlmYWF0LCBoYXBweSB0byBhZGQgeW91IHRvbyBNaWNoYWVs IGFuZCB5b3UgY2FuIGhlbHAgZmlndXJlIG91dCBzb21lIG9mIHRoZSBvcGVuIHJlZGlyZWN0IG9w dGlvbnMgb3V0bGluZWQgaW4gaXQg4pi6DQoNCk15IGhpZ2ggbGV2ZWwgdGhvdWdodHMgb24gdGhp cyB3ZXJlIHRvIGtlZXAgdGhlIEFDTUUgc3BlY2lmaWNzIG91dCBvZiB0aGUgZHJhZnQsIGFuZCB1 c2UgdGhlIGRyYWZ0IHRvIGRlZmluZSB0aGUgY2xvdWQgUkEgYmVoYXZpb3VyLCBhbmQgdGhlIHBs ZWRnZSBiZWhhdmlvdXIgd2hlbiBpbnRlcmFjdGluZyB3aXRoIHRoZSBjbG91ZCBSQSwgYW5kIHRo ZSB2YXJpb3VzIGNlcnQsIENBLCBUTFMsIHJlZGlyZWN0LCBldGMuIGRldGFpbHMuIFRoZSBmYWN0 IHRoYXQgdGhlIFJBICh3aGV0aGVyIGNsb3VkIG9yIGxvY2FsKSAqbWF5KiB1c2UgQUNNRSB0byB0 YWxrIHRvIHRoZSBDQSBpcyB0cmFuc3BhcmVudCB0byB0aGUgcGxlZGdlLg0KDQpJIHdhcyB0aGlu a2luZyB0aGF0IHRoZSBBQ01FIHNwZWNpZmljcyBjb3VsZCBiZSBjb3ZlcmVkIGluIGEgZGlmZmVy ZW50IGRyYWZ0IGJhc2VkIG9uIG1lcmdpbmcgZHJhZnQteXVzZWYtYWNtZS0zcmQtcGFydHktZGV2 aWNlLWF0dGVzdGF0aW9uIGFuZCBkcmFmdC1mcmllbC1hY21lLWludGVncmF0aW9ucywgYnV0IGxl YXZlIHRoZSBCUlNLSSBjbGFyaWZpY2F0aW9ucy9zcGVjaWZpY3MgaW4gdGhpcyBvbmUuDQoNClRo b3VnaHRzPw0KT3dlbg0KDQoNCg0KDQpGcm9tOiBJb3Qtb25ib2FyZGluZyA8aW90LW9uYm9hcmRp bmctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFJpZmFhdCBTaGVraC1ZdXNlZg0KU2Vu dDogMDIgQXVndXN0IDIwMTkgMTk6MDkNClRvOiBhbmltYUBpZXRmLm9yZzsgaW90LW9uYm9hcmRp bmdAaWV0Zi5vcmcNClN1YmplY3Q6IFtJb3Qtb25ib2FyZGluZ10gRGV2aWNlIENlcnRpZmljYXRl IERlcGxveW1lbnQgQXV0b21hdGlvbiB3aXRoIEFDTUUgdXNpbmcgQlJTS0kNCg0KQWxsLA0KDQpE dXJpbmcgdGhlIGxhc3QgSUVURiBtZWV0aW5nIGluIE1vbnRyZWFsIHdlIGhhZCBhIHNpZGUgbWVl dGluZyB0byBkaXNjdXNzIHRoZQ0KZGVwbG95bWVudCBhdXRvbWF0aW9uIG9mIEFDTUUgaXNzdWVk IGNlcnRpZmljYXRlcyB0byBkZXZpY2VzLCBhbmQgdGhlIHBvdGVudGlhbA0KdXNlIG9mIHRoZSBC UlNLSSBtZWNoYW5pc20gdG8gaGVscCB3aXRoIHRoaXMuIEl0IHdhcyBjbGVhciBmcm9tIHRoZSBk aXNjdXNzaW9uDQp0aGF0IEJSU0tJIGNhbiBiZSB1c2VkIHRvIGhlbHAgYWRkcmVzcyB0aGlzIHVz ZSBjYXNlLCBhbmQgdGhhdCBmdXJ0aGVyIGRpc2N1c3Npb24gaXMNCm5lZWRlZCB0byBkZWZpbmUg dGhlIG5lZWRlZCBlbmhhbmNlbWVudHMgdG8gQlJTS0kuDQoNClRoZSBjdXJyZW50IEJSU0tJIG1l Y2hhbmlzbSBvbmx5IGJyaWVmbHkgZGlzY3Vzc2VzIHRoZSBDbG91ZCBSZWdpc3RyYXIgb3B0aW9u IGluDQpzZWN0aW9uIDIuNywgd2hpY2ggY291bGQgYmUgdXNlZCB0byBoZWxwIGFkZHJlc3MgdGhp cyB1c2UgY2FzZS4NCg0KTWljaGFlbCBSaWNoYXJkc29uIGFuZCBJIGhhZCBhbm90aGVyIG1lZXRp bmcgb3ZlciBsdW5jaCB5ZXN0ZXJkYXkgdG8gZnVydGhlcg0KZGlzY3VzcyB0aGlzIGFuZCB3ZSBk ZWNpZGVkIHRvIHdvcmsgb24gYSBuZXcgZHJhZnQgdG8gZGVzY3JpYmUgdGhlIGlzc3VlIGFuZA0K ZGVmaW5lIGEgc29sdXRpb24uDQoNCkJlY2F1c2Ugb2YgdmFjYXRpb25zIGFuZCBvdGhlciBjb21t aXRtZW50cywgd2Ugd2lsbCB0cnkgdG8gcHVibGlzaCB0aGUgZmlyc3QNCnZlcnNpb24gb2YgdGhl IGRyYWZ0IGVhcmx5IE9jdG9iZXIuDQoNClJlZ2FyZHMsDQogUmlmYWF0ICYgTWljaGFlbA0K --_000_DM6PR11MB3385FD834E826E25160B53AADBD50DM6PR11MB3385namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWln aHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIGd1eXMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFmdGVyIHRoZSBtZWV0 aW5nIGFuZCBmcm9tIGNvcnJpZG9yIGNvbnZlcnNhdGlvbnMgd2l0aCBUb2VybGVzcywgSSBoYWQg YWN0dWFsbHkgYWxyZWFkeSBzdGFydGVkIG9uIHN1Y2ggYSBkcmFmdC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2hhdCBJIGhh dmUgc3RhcnRlZCBzbyBmYXIgaXMgYXR0YWNoZWQuIEl0cyBub3Qgb24gYSBwdWJsaWMgcmVwbyB5 ZXQsIGJ1dCB3aWxsIHB1dCBpdCB0aGVyZS4gWW91IGFyZSBhbHJlYWR5IG5hbWVkIG9uIGl0IFJp ZmFhdCwgaGFwcHkgdG8gYWRkIHlvdSB0b28gTWljaGFlbCBhbmQgeW91IGNhbiBoZWxwIGZpZ3Vy ZSBvdXQgc29tZSBvZiB0aGUNCiBvcGVuIHJlZGlyZWN0IG9wdGlvbnMgb3V0bGluZWQgaW4gaXQg PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3M7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPko8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+TXkgaGlnaCBsZXZlbCB0aG91Z2h0cyBvbiB0aGlzIHdlcmUgdG8ga2VlcCB0 aGUgQUNNRSBzcGVjaWZpY3Mgb3V0IG9mIHRoZSBkcmFmdCwgYW5kIHVzZSB0aGUgZHJhZnQgdG8g ZGVmaW5lIHRoZSBjbG91ZCBSQSBiZWhhdmlvdXIsIGFuZCB0aGUgcGxlZGdlIGJlaGF2aW91ciB3 aGVuIGludGVyYWN0aW5nIHdpdGggdGhlIGNsb3VkIFJBLCBhbmQNCiB0aGUgdmFyaW91cyBjZXJ0 LCBDQSwgVExTLCByZWRpcmVjdCwgZXRjLiBkZXRhaWxzLiBUaGUgZmFjdCB0aGF0IHRoZSBSQSAo d2hldGhlciBjbG91ZCBvciBsb2NhbCkgKjxiPm1heTwvYj4qIHVzZSBBQ01FIHRvIHRhbGsgdG8g dGhlIENBIGlzIHRyYW5zcGFyZW50IHRvIHRoZSBwbGVkZ2UuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgd2FzIHRoaW5raW5n IHRoYXQgdGhlIEFDTUUgc3BlY2lmaWNzIGNvdWxkIGJlIGNvdmVyZWQgaW4gYSBkaWZmZXJlbnQg ZHJhZnQgYmFzZWQgb24gbWVyZ2luZw0KPC9zcGFuPmRyYWZ0LXl1c2VmLWFjbWUtM3JkLXBhcnR5 LWRldmljZS1hdHRlc3RhdGlvbiBhbmQgZHJhZnQtZnJpZWwtYWNtZS1pbnRlZ3JhdGlvbnMsIGJ1 dCBsZWF2ZSB0aGUgQlJTS0kgY2xhcmlmaWNhdGlvbnMvc3BlY2lmaWNzIGluIHRoaXMgb25lLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaG91Z2h0cz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk93ZW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PGI+PHNw YW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IElvdC1v bmJvYXJkaW5nICZsdDtpb3Qtb25ib2FyZGluZy1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24g QmVoYWxmIE9mIDwvYj5SaWZhYXQgU2hla2gtWXVzZWY8YnI+DQo8Yj5TZW50OjwvYj4gMDIgQXVn dXN0IDIwMTkgMTk6MDk8YnI+DQo8Yj5Ubzo8L2I+IGFuaW1hQGlldGYub3JnOyBpb3Qtb25ib2Fy ZGluZ0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbSW90LW9uYm9hcmRpbmddIERldmlj ZSBDZXJ0aWZpY2F0ZSBEZXBsb3ltZW50IEF1dG9tYXRpb24gd2l0aCBBQ01FIHVzaW5nIEJSU0tJ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5BbGwsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5EdXJpbmcgdGhlIGxhc3QgSUVURiBtZWV0aW5n IGluIE1vbnRyZWFsIHdlIGhhZCBhIHNpZGUgbWVldGluZyB0byBkaXNjdXNzIHRoZSZuYnNwOzxi cj4NCmRlcGxveW1lbnQgYXV0b21hdGlvbiBvZiBBQ01FIGlzc3VlZCBjZXJ0aWZpY2F0ZXMgdG8g ZGV2aWNlcywgYW5kIHRoZSBwb3RlbnRpYWwmbmJzcDs8YnI+DQp1c2Ugb2YgdGhlIEJSU0tJIG1l Y2hhbmlzbSB0byBoZWxwIHdpdGggdGhpcy4gSXQgd2FzIGNsZWFyIGZyb20gdGhlIGRpc2N1c3Np b24mbmJzcDs8YnI+DQp0aGF0IEJSU0tJIGNhbiBiZSB1c2VkIHRvIGhlbHAgYWRkcmVzcyB0aGlz IHVzZSBjYXNlLCBhbmQgdGhhdCBmdXJ0aGVyIGRpc2N1c3Npb24gaXMmbmJzcDs8YnI+DQpuZWVk ZWQgdG8gZGVmaW5lIHRoZSBuZWVkZWQgZW5oYW5jZW1lbnRzIHRvIEJSU0tJLjxicj4NCjxicj4N ClRoZSBjdXJyZW50IEJSU0tJIG1lY2hhbmlzbSBvbmx5IGJyaWVmbHkgZGlzY3Vzc2VzIHRoZSBD bG91ZCBSZWdpc3RyYXIgb3B0aW9uIGluJm5ic3A7PGJyPg0Kc2VjdGlvbiAyLjcsIHdoaWNoIGNv dWxkIGJlIHVzZWQgdG8gaGVscCBhZGRyZXNzIHRoaXMgdXNlIGNhc2UuPGJyPg0KPGJyPg0KTWlj aGFlbCBSaWNoYXJkc29uIGFuZCBJIGhhZCBhbm90aGVyIG1lZXRpbmcgb3ZlciBsdW5jaCB5ZXN0 ZXJkYXkgdG8gZnVydGhlciZuYnNwOzxicj4NCmRpc2N1c3MgdGhpcyBhbmQgd2UgZGVjaWRlZCB0 byB3b3JrIG9uIGEgbmV3IGRyYWZ0IHRvIGRlc2NyaWJlIHRoZSBpc3N1ZSBhbmQmbmJzcDs8YnI+ DQpkZWZpbmUgYSBzb2x1dGlvbi48YnI+DQo8YnI+DQpCZWNhdXNlIG9mIHZhY2F0aW9ucyBhbmQg b3RoZXIgY29tbWl0bWVudHMsIHdlIHdpbGwgdHJ5IHRvIHB1Ymxpc2ggdGhlIGZpcnN0Jm5ic3A7 PGJyPg0KdmVyc2lvbiBvZiB0aGUgZHJhZnQgZWFybHkgT2N0b2Jlci48YnI+DQo8YnI+DQpSZWdh cmRzLDxicj4NCiZuYnNwO1JpZmFhdCAmYW1wOyBNaWNoYWVsPC9zcGFuPiZuYnNwOyZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM6PR11MB3385FD834E826E25160B53AADBD50DM6PR11MB3385namp_-- --_004_DM6PR11MB3385FD834E826E25160B53AADBD50DM6PR11MB3385namp_ Content-Type: application/octet-stream; name="draft-friel-brski-cloud.md" Content-Description: draft-friel-brski-cloud.md Content-Disposition: attachment; filename="draft-friel-brski-cloud.md"; size=16965; creation-date="Tue, 06 Aug 2019 13:00:13 GMT"; modification-date="Tue, 06 Aug 2019 12:58:56 GMT" Content-Transfer-Encoding: base64 LS0tCgp0aXRsZTogIkJSU0tJIENsb3VkIFJlZ2lzdHJhciIKYWJicmV2OiBCUlNLSS1DTE9VRApk b2NuYW1lOiBkcmFmdC1mcmllbC1icnNraS1jbG91ZApjYXRlZ29yeTogc3RkCgpzdGFuZF9hbG9u ZTogeWVzCnBpOiBbdG9jLCBzb3J0cmVmcywgc3ltcmVmc10KCmF1dGhvcjoKIC0KICAgIGluczog Ty4gRnJpZWwKICAgIG5hbWU6IE93ZW4gRnJpZWwKICAgIG9yZzogQ2lzY28KICAgIGVtYWlsOiBv ZnJpZWxAY2lzY28uY29tCiAtCiAgICBpbnM6IFIuIFNoZWtoLVl1c2VmCiAgICBuYW1lOiBSaWZh YXQgU2hla2gtWXVzZWYKICAgIG9yZzogQXZheWEKICAgIGVtYWlsOiByaWZhYXQuaWV0ZkBnbWFp bC5jb20KCmluZm9ybWF0aXZlOgogIElFRUU4MDIuMUFSOgogICAgdGl0bGU6IFNlY3VyZSBEZXZp Y2UgSWRlbnRpdHkKICAgIGF1dGhvcjoKIyAgICAgIC0KICAgICAgICBpbnM6IElFRUUKICAgICAg ICBuYW1lOiBJRUVFCiAgICAgICAgb3JnOiBJRUVFCiAgICBkYXRlOiAyMDE3CgotLS0gYWJzdHJh Y3QKClRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBiZWhhdmlvdXIgb2YgYSBCUlNLSSBDbG91 ZCBSZWdpc3RyYXIsIGFuZCBob3cgYSBwbGVkZ2UgY2FuIGludGVyYWN0IHdpdGggYSBCUlNLSSBD bG91ZCBSZWdpc3RyYXIgd2hlbiBib290c3RyYXBwaW5nLgoKLS0tIG1pZGRsZQoKIyBJbnRyb2R1 Y3Rpb24KCkJvb3RzdHJhcHBpbmcgUmVtb3RlIFNlY3VyZSBLZXkgSW5mcmFzdHJ1Y3R1cmVzIChC UlNLSSkge3s/SS1ELmlldGYtYW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYX19IHNwZWNpZmll cyBhdXRvbWF0ZWQgYm9vdHN0cmFwcGluZyBvZiBhbiBBdXRvbm9taWMgQ29udHJvbCBQbGFuZS4g QlJTS0kgU2VjdGlvbiAyLjcgZGVzY3JpYmVzIGhvdyBhIHBsZWRnZSAiTUFZIGNvbnRhY3QgYSB3 ZWxsIGtub3duIFVSSSBvZiBhIGNsb3VkIHJlZ2lzdHJhciBpZiBhIGxvY2FsIHJlZ2lzdHJhciBj YW5ub3QgYmUgZGlzY292ZXJlZCBvciBpZiB0aGUgcGxlZGdlJ3MgdGFyZ2V0IHVzZSBjYXNlcyBk byBub3QgaW5jbHVkZSBhIGxvY2FsIHJlZ2lzdHJhciIuCgpUaGlzIGRvY3VtZW50IGZ1cnRoZXIg c3BlY2lmaWVzIHVzZSBvZiBhIEJSU0tJIGNsb3VkIHJlZ2lzdHJhciBhbmQgY2xhcmlmaWVzIG9w ZXJhdGlvbnMgdGhhdCBhcmUgbm90IHN1ZmZpY2llbnRseSBzcGVjaWZpZWQgaW4gQlJTS0kuCgpU d28gaGlnaCBsZXZlbCBkZXBsb3ltZW50IG1vZGVscyBhcmUgZG9jdW1lbnRlZCBoZXJlOgoKLSBM b2NhbCBEb21haW4gUmVnaXN0cmFyIERpc2NvdmVyeTogdGhlIGNsb3VkIHJlZ2lzdHJhciBpcyB1 c2VkIGJ5IHRoZSBwbGVkZ2UgdG8gZGlzY292ZXIgdGhlIGxvY2FsIGRvbWFpbiByZWdpc3RyYXIu IFRoZSBjbG91ZCByZWdpc3RyYXIgcmVkaXJlY3RzIHRoZSBwbGVkZ2UgdG8gdGhlIGxvY2FsIGRv bWFpbiByZWdpc3RyYXIsIGFuZCB0aGUgcGxlZGdlIGNvbXBsZXRlcyBib290c3RyYXAgYWdhaW5z dCB0aGUgbG9jYWwgZG9tYWluIHJlZ2lzdHJhci4KCi0gQ2xvdWQgUmVnaXN0cmFyIEJhc2VkIEJv b3N0cmFwOiB0aGVyZSBpcyBubyBsb2NhbCBkb21haW4gcmVnaXN0cmFyIGFuZCB0aGUgcGxlZGdl IGNvbXBsZXRlcyBib29zdHJhcCB1c2luZyB0aGUgY2xvdWQgcmVnaXN0cmFyLiBBcyBwYXJ0IG9m IGJvb3N0cmFwLCB0aGUgY2xvdWQgcmVnaXN0cmFyIG1heSBuZWVkIHRvIHRlbGwgdGhlIGNsaWVu dCB0aGUgZG9tYWluIHRvIHVzZSBmb3IgYWNjZXNzaW5nIHNlcnZpY2VzLgoKIyBBcmNoaXRlY3R1 cmUKClRoZSBoaWdoIGxldmVsIGFyY2hpdGVjdHVyZSBpcyBpbGx1c3RyYXRlZCBpbiB7e2FyY2hp dGVjdHVyZX19LiBUaGUgcGxlZGdlIGNvbm5lY3RzIHRvIHRoZSBjbG91ZCByZWdpc3RyYXIgZHVy aW5nIGJvb3RzdHJhcC4gVGhlIGNsb3VkIHJlZ2lzdHJhciBtYXkgcmVkaXJlY3QgdGhlIHBsZWRn ZSB0byBhIGxvY2FsIHJlZ2lzdHJhciBpbiBvcmRlciB0byBjb21wbGV0ZSBib290c3RyYXAgYWdh aW5zdCB0aGUgbG9jYWwgcmVnaXN0cmFyLiBJZiB0aGUgY2xvdWQgcmVnaXN0cmFyIGhhbmRsZXMg dGhlIGJvb3RzdHJhcCBwcm9jZXNzIGl0c2VsZiB3aXRob3V0IHJlZGlyZWN0aW5nIHRoZSBwbGVk Z2UgdG8gYSBsb2NhbCByZWdpc3RyYXIsIHRoZSBjbG91ZCByZWdpc3RyYXIgbWF5IG5lZWQgdG8g aW5mb3JtIHRoZSBwbGVkZ2Ugd2hhdCBkb21haW4gdG8gdXNlIGZvciBhY2Nlc3Npbmcgc2Vydmlj ZXMgb25jZSBib290c3RyYXAgaXMgY29tbHBldGUuCgpGaW5hbGx5LCB3aGVuIGJvb3RzdHJhcHBp bmcgYWdhaW5zdCBhIGxvY2FsIHJlZ2lzdHJhciwgdGhlIHJlZ2lzdHJhciBtYXkgaW50ZXJhY3Qg d2l0aCBhIGJhY2tlbmQgQ0EgdG8gYXNzaXN0IGluIGlzc3VpbmcgY2VydGlmaWNhdGVzIHRvIHRo ZSBwbGVkZ2UuIFRoZSBtZWNoYW5pc21zIGFuZCBwcm90b2NvbHMgYnkgd2hpY2ggdGhlIHJlZ2lz dHJhciBpbnRlcmFjdHMgd2l0aCB0aGUgQ0EgYXJlIHRyYW5zcGFyZW50IHRvIHRoZSBwbGVkZ2Ug YW5kIGFyZSBvdXQtb2Ytc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4KCn5+fgorLS0tLS0tLS0rICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rCnwgUGxl ZGdlIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgQ2xvdWQgICAg IHwKKy0tLS0tLS0tKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBS ZWdpc3RyYXIgfAogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICArLS0tLS0tLS0tLS0rCiAgICB8CiAgICB8ICAgICAgICAgICAgICAgICArLS0tLS0tLS0t LS0rICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSsKICAgICstLS0tLS0tLS0tLS0tLS0tPnwg TG9jYWwgICAgIHwtLS0tLS0tLS0tLS0tLS0+fCAgIE1BU0EgICAgfAogICAgfCAgICAgICAgICAg ICAgICAgfCBSZWdpc3RyYXIgfCAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rCiAgICB8ICAg ICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgIAogICAgfCAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0rCiAgICB8 ICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgICAgQ0EgICAg IHwKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tKwogICAgfAogICAgfCAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKwogICAg Ky0tLS0tLS0tLS0tLS0tLS0+fCBTZXJ2aWNlcyAgfAogICAgICAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tKwp+fn4KezogI2FyY2hpdGVjdHVyZSB0aXRsZT1IaWdoIExldmVsIEFyY2hpdGVj dHVyZSJ9CgojIEluaXRpYWwgVm91Y2hlciBSZXF1ZXN0CgojIyBDbG91ZCBSZWdpc3RyYXIgRGlz Y292ZXJ5CgpCUlNLSSBkZWZpbmVzIGhvdyBhIHBsZWRnZSBNQVkgY29udGFjdCBhIHdlbGwga25v d24gVVJJIG9mIGEgY2xvdWQgcmVnaXN0cmFyIGlmIGEgbG9jYWwgcmVnaXN0cmFyIGNhbm5vdCBi ZSBkaXNjb3ZlcmVkLiBBZGRpdGlvbmFsbHksIGNlcnRhaW4gcGxlZGdlIHR5cGVzIG1heSBuZXZl ciBhdHRlbXB0IHRvIGRpc2NvdmVyIGEgbG9jYWwgcmVnaXN0cmFyIGFuZCBtYXkgYXV0b21hdGlj YWxseSBib290c3RyYXAgYWdhaW5zdCBhIGNsb3VkIHJlZ2lzdHJhci4gVGhlIGRldGFpbHMgb2Yg dGhlIFVSSSBhcmUgbWFudWZhY3R1cmVyIHNwZWNpZmljLCB3aXRoIEJSU0tJIGdpdmluZyB0aGUg ZXhhbXBsZSAiYnJza2ktcmVnaXN0cmFyLm1hbnVmYWN0dXJlci5leGFtcGxlLmNvbSIuCgojIyBQ bGVkZ2UgLSBDbG91ZCBSZWdpc3RyYXIgVExTIEVzdGFibGlzaG1lbnQgRGV0YWlscwoKVGhlIHBs ZWRnZSBNVVNUIHVzZSBhbiBJbXBsaWNpdCBUcnVzdCBBbmNob3IgZGF0YWJhc2UgKHNlZSB7ez9S RkM3MDMwfX0pIHRvIGF1dGhlbnRpY2F0ZSB0aGUgY2xvdWQgcmVnaXN0cmFyIHNlcnZpY2UgYXMg ZGVzY3JpYmVkIGluIHt7P1JGQzYxMjV9fS4gVGhlIHBsZWRnZSBNVVNUIE5PVCBlc3RhYmxpc2gg YSBwcm92aXNpb25hbCBUTFMgY29ubmVjdGlvbiAoc2VlIEJSU0tJIHNlY2V0aW9uIDUuMSkgd2l0 aCB0aGUgY2xvdWQgcmVnaXN0cmFyLgoKVGhlIGNsb3VkIHJlZ2lzdHJhciBNVVNUIHZhbGlkYXRl IHRoZSBpZGVudGl0eSBvZiB0aGUgcGxlZGdlIGJ5IHNlbmRpbmcgYSBUTFMgQ2VydGlmaWNhdGVS ZXF1ZXN0IG1lc3NhZ2UgdG8gdGhlIHBsZWRnZSBkdXJpbmcgVExTIHNlc3Npb24gZXN0YWJsaXNo bWVudC4gVGhlIGNsb3VkIHJlZ2lzdHJhciBNQVkgaW5jbHVkZSBhIGNlcnRpZmljYXRlX2F1dGhv cml0aWVzIGZpZWxkIGluIHRoZSBtZXNzYWdlIHRvIHNwZWNpZnkgdGhlIHNldCBvZiBhbGxvd2Vk IElEZXZJRCBpc3N1aW5nIENBcyB0aGF0IHBsZWRnZXMgbWF5IHVzZSB3aGVuIGVzdGFibGlzaGlu ZyBjb25uZWN0aW9ucyB3aXRoIHRoZSBjbG91ZCByZWdpc3RyYXIuCgpUaGUgY2xvdWQgcmVnaXN0 cmFyIE1BWSBvbmx5IGFsbG93IGNvbm5lY3Rpb25zIGZyb20gcGxlZGdlcyB0aGF0IGhhdmUgYW4g SURldklEIHRoYXQgaXMgc2lnbmVkIGJ5IG9uZSBvZiBhIHNwZWNpZmljIHNldCBvZiBDQXMsIGUu Zy4gSURldklEcyBpc3N1ZWQgYnkgY2VydGFpbiBtYW51ZmFjdHVyZXJzLiAKClRoZSBjbG91ZCBy ZWdpc3RyYXIgTUFZIGFsbG93IHBsZWRnZXMgdG8gY29ubmVjdCB1c2luZyBzZWxmLXNpZ25lZCBp ZGVudGl0eSBjZXJ0aWZpY2F0ZXMuIAoKIyMgUGxlZGdlIFJlcXVlc3RzIFZvdWNoZXIgZnJvbSB0 aGUgQ2xvdWQgUmVnaXN0cmFyCgpBZnRlciB0aGUgcGxlZGdlIGhhcyBlc3RhYmxpc2hlZCBhIGZ1 bGwgVExTIGNvbm5lY3Rpb24gd2l0aCB0aGUgY2xvdWQgcmVnaXN0cmFyIGFuZCBoYXMgdmVyaWZp ZWQgdGhlIGNsb3VkIHJlZ2lzdHJhciBQS0kgaWRlbnRpdHksIHRoZSBwbGVkZ2UgZ2VuZXJhdGVz IGEgdm91Y2hlciByZXF1ZXN0IG1lc3NhZ2UgYXMgb3V0bGluZWQgaW4gQlJTS0kgc2VjdGlvbiA1 LjIsIGFuZCBzZW5kcyB0aGUgdm91Y2hlciByZXF1ZXN0IG1lc3NhZ2UgdG8gdGhlIGNsb3VkIHJl Z2lzdHJhci4KCiMgQ2xvdWQgUmVnaXN0cmFyIFZvdWNoZXIgUmVxdWVzdCBPcGVyYXRpb24KCldo ZW4gdGhlIGNsb3VkIHJlZ2lzdHJhciBoYXMgdmVyaWZpZWQgdGhlIGlkZW50aXR5IG9mIHRoZSBw bGVkZ2UsIGRldGVybWluZWQgdGhlIHBsZWRnZSBvd25lcnNoaXAgYW5kIGhhcyByZWNlaXZlZCB0 aGUgdm91Y2hlciByZXF1ZXN0LCB0aGVyZSBhcmUgdHdvIG1haW4gb3B0aW9ucyBmb3IgaGFuZGxp bmcgdGhlIHJlcXVlc3QuCgotIHRoZSBjbG91ZCByZWdpc3RyYXIgY2FuIHJlZGlyZWN0IHRoZSB2 b3VjaGVyIHJlcXVlc3QgdG8gYSBsb2NhbCBkb21haW4gcmVnaXN0cmFyCgotIHRoZSBjbG91ZCBy ZWdpc3RyYXIgY2FuIGhhbmRsZSB0aGUgdm91Y2hlciByZXF1ZXN0IGRpcmVjdGx5IGJ5IGVpdGhl ciBpc3N1aW5nIGEgdm91Y2hlciBvciBkZWNsaW5pbmcgdGhlIHJlcXVlc3QKCiMjIFBsZWRnZSBP d25lcnNoaXAgTG9va3VwCgpUaGUgY2xvdWQgcmVnaXN0cmFyIG5lZWRzIHNvbWUgc3VpdGFibGUg bWVjaGFuaXNtIGZvciBrbm93aW5nIHRoZSBjb3JyZWN0IG93bmVyIG9mIGEgY29ubmVjdGluZyBw bGVkZ2UgYmFzZWQgb24gdGhlIHByZXNlbnRlZCBpZGVudGl0eSBjZXJ0aWZpY2F0ZS4gRm9yIGV4 YW1wbGUsIGlmIHRoZSBwbGVkZ2UgZXN0YWJsaXNoZXMgVExTIHVzaW5nIGFuIElEZXZJRCB0aGF0 IGlzIHNpZ25lZCBieSBhIGtub3duIG1hbnVmYWN0dXJpbmcgQ0EsIHRoZSByZWdpc3RyYXIgY291 bGQgZXh0cmFjdCB0aGUgc2VyaWFsIG51bWJlciBmcm9tIHRoZSBJRGV2SUQgYW5kIHVzZSB0aGlz IHRvIGxvb2t1cCBhIGRhdGFiYXNlIG9mIHBsZWRnZSBJRGV2SUQgc2VyaWFsIG51bWJlcnMgdG8g b3duZXJzLgoKQWx0ZXJuYXRpdmVseSwgaWYgdGhlIGNsb3VkIHJlZ2lzdHJhciBhbGxvd3MgcGxl ZGdlcyB0byBjb25uZWN0IHVzaW5nIHNlbGYtc2lnbmVkIGNlcnRpZmljYXRlcywgdGhlIHJlZ2lz dHJhciBjb3VsZCB1c2UgdGhlIHRodW1icHJpbnQgb2YgdGhlIHNlbGYtc2lnbmVkIGNlcnRpZmlj YXRlIHRvIGxvb2t1cCBhIGRhdGFiYXNlIG9mIHBsZWRnZSBzZWxmLXNpZ25lZCBjZXJ0aWZpY2F0 ZSB0aHVtYnByaW50cyB0byBvd25lcnMuCgpUaGUgbWVjaGFuaXNtIGJ5IHdoaWNoIHRoZSBjbG91 ZCByZWdpc3RyYXIgZGV0ZXJtaW5lcyBwbGVkZ2Ugb3duZXJzaGlwIGlzIG91dC1vZi1zY29wZSBv ZiB0aGlzIGRvY3VtZW50LgoKIyBWb3VjaGVyIFJlcXVlc3QgUmVkaXJlY3RlZCB0byBMb2NhbCBE b21haW4gUmVnaXN0cmFyCgpPbmNlIHRoZSBjbG91ZCByZWdpc3RhciBoYXMgZGV0ZXJtaW5lZCBw bGVkZ2Ugb3duZXJzaGlwLCB0aGUgY2xvdWQgcmVnaXN0cmFyIG1heSByZWRpcmVjdCB0aGUgcGxl ZGdlIHRvIHRoZSBvd25lcidzIGxvY2FsIGRvbWFpbiByZWdpc3RyYXIgaW4gb3JkZXIgdG8gY29t cGxldGUgYm9vdHN0cmFwLiBPd25lcnNoaXAgcmVnaXN0cmF0aW9uIHdpbGwgcmVxdWlyZSB0aGUg b3duZXIgdG8gcmVnaXN0ZXIgdGhlaXIgbG9jYWwgZG9tYWluLCBhbmQgdGhlIG1lY2hhbmlzbSBi eSB3aGljaCBwbGVkZ2Ugb3duZXJzIHJlZ2lzdGVyIHRoZWlyIGRvbWFpbiB3aXRoIHRoZSBjbG91 ZCByZWdpc3RyYXIgaXMgb3V0LW9mLXNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuCgpUaGUgY2xvdWQg cmVnaXN0cmFyIHJlcGxpZXMgdG8gdGhlIHZvdWNoZXIgcmVxdWVzdCB3aXRoIGEgc3VpdGFibGUg SFRUUCAzeHggcmVzcG9uc2UgY29kZSBhcyBwZXIge3s/SS1ELmlldGYtaHR0cGJpcy1iY3A1NmJp c319LCBpbmNsdWRpbmcgdGhlIG93bmVyJ3MgbG9jYWwgZG9tYWluIGluIHRoZSBIVFRQIExvY2F0 aW9uIGhlYWRlci4KCiMjIyBQbGVkZ2UgaGFuZGxpbmcgb2YgUmVkaXJlY3QKClRoZSBwbGVkZ2Ug c2hvdWxkIGNvbXBsZXRlIEJSU0tJIGJvb3RzdHJhcCBhcyBwZXIgc3RhbmRhcmQgQlJTS0kgb3Bl cmF0aW9uLiBUaGUgcGxlZGdlIHNob3VsZCBlc3RhYmxpc2ggYSBwcm92aXNpb25hbCBUTFMgY29u bmVjdGlvbiB3aXRoIHNwZWNpZmllZCBsb2NhbCBkb21haW4gcmVnaXN0cmFyLiBUaGUgcGxlZGdl IHNob3VsZCBub3QgdXNlIGl0cyBJbXBsaWNpdCBUcnVzdCBBbmNob3IgZGF0YWJhc2UgZm9yIHZh bGlkYXRpbmcgdGhlIGxvY2FsIGRvbWFpbiByZWdpc3RyYXIgaWRlbnRpdHkuIFRoZSBwbGVkZ2Ug c2hvdWxkIHNlbmQgYSB2b3VjaGVyIHJlcXVlc3QgbWVzc2FnZSB2aWEgdGhlIGxvY2FsIGRvbWFp biByZWdpc3RyYXIuIFdoZW4gdGhlIHBsZWRnZSBkb3dubG9hZHMgYSB2b3VjaGVyLCBpdCBjYW4g dmFsaWRhdGUgdGhlIFRMUyBjb25uZWN0aW9uIHRvIHRoZSBsb2NhbCBkb21haW4gcmVnaXN0cmFy IGFuZCBjb250aW51ZSB3aXRoIGVucm9sbG1lbnQgYW5kIGJvb3RzdHJhcC4KCiMjIFZvdWNoZXIg UmVxdWVzdCBIYW5kbGVkIGJ5IENsb3VkIFJlZ2lzdHJhcgoKSWYgdGhlIGNsb3VkIHJlZ2lzdHJh ciBpc3N1ZXMgYSB2b3VjaGVyLCBpdCByZXR1cm5zIHRoZSB2b3VjaGVyIGluIGEgSFRUUCByZXNw b25zZSB3aXRoIGEgc3VpdGFibGUgMnh4IHJlc3BvbnNlIGNvZGUgYXMgcGVyIHt7P0ktRC5pZXRm LWh0dHBiaXMtYmNwNTZiaXN9fS4KCltbIFRPRE8gXV0gVGhlcmUgYXJlIGEgZmV3IG9wdGlvbnMg aGVyZToKCi0gT3B0aW9uIDE6IHRoZSBwbGVkZ2UgY29tcGxldGVzIEVTVCBlbnJvbGwgYWdhaW5z dCB0aGUgY2xvdWQgcmVnaXN0cmFyLiBPbmNlIEVTVCBlbnJvbCBpcyBjb21wbGV0ZSwgd2UgbmVl ZCBhIG1lY2hhbmlzbSB0byB0ZWxsIHRoZSBwbGVkZ2Ugd2hhdCBpdHMgc2VydmljZSBkb21haW4g aXMuIFRoaXMgY291bGQgYmUgYnkgaW5jbHVkaW5nIGEgc2VydmljZSBkb21haW4gaW4gdGhlIHZv dWNoZXIuCgotIE9wdGlvbiAyOiB0aGUgcGxlZGdlIGF0dGVtcHRzIEVTVCBlbnJvbCBhZ2FpbnN0 IHRoZSBjbG91ZCByZWdpc3RyYXIgYW5kIHRoZSBjbG91ZCByZWdpc3RyYXIgdGhlbiBkb2VzIGEg M3h4IHRvIHRoZSBsb2NhbCBkb21haW4gUkEgdG8gY29tcGxldGUgY2VydCBlbnJvbC4gVGhlIHBs ZWRnZSBhc3N1bWVzIHRoYXQgc2VydmljZXMgYXJlIG9mZiB0aGUgbG9jYWwgZG9tYWluLiBUaGlz IGRvZXMgbm90IHJlcXVpcmUgYWRkaW5nIGFuIEZRRE4gdG8gdGhlIHZvdWNoZXIuCgotIE9wdGlv biAzOiB3ZSByZWRlZmluZSB0aGUgdm91Y2hlciB0byBpbmNsdWRlIGxvY2FsIFJBIGRvbWFpbiBp bmZvLCBhbmQgdGhlIHBsZWRnZSBpbXBsaWNpdGx5IGtub3dzIHRoYXQgaXQgZ290IGEgdm91Y2hl ciBmcm9tIHRoZSBjbG9kdSByZWdpc3RyYXIsIHRoYXQgdm91Y2hlciBpbmNsdWRlZCBhIGxvY2Fs IGRvbWFpbiBGUUROLCB0aGUgcGxlZGdlIGtub3dzIHRvIGRvIEVTVCBlbnJvbGwgYWdhaW5zdCB0 aGUgbG9jYWwgZG9tYWluLiBpLmUuIGl0IGdvdCBhIDIwME9LIGZyb20gdGhlIGNsb3VkIHJlZ2lz dHJhciwgYW5kIGtub3dzIHRvIHNlbmQgdGhlIG5leHQgSFRUUCByZXF1ZXN0IHRvIGEgZGlmZmVy ZW50IGRvbWFpbi4gVGhlIHBsZWRnZSBhc3N1bWVzIHRoYXQgc2VydmljZXMgYXJlIG9mZiB0aGUg bG9jYWwgZG9tYWluIHNwZWNpZmllZCBpbiB0aGUgdm91Y2hlci4KCiMgUHJvdG9jb2wgRGV0YWls cwoKW1sgVE9ETyBdXSAgTWlzc2luZyBkZXRhaWxlZCBCUlNLSSBzdGVwcyBlLmcuIENTUiBhdHRy aWJ1dGVzLCBsb2dnaW5nLCBldGMuCgojIyBWb3VjaGVyIFJlcXVlc3QgUmVkaXJlY3RlZCB0byBM b2NhbCBEb21haW4gUmVnaXN0cmFyCgp+fn4KKy0tLS0tLS0tKyAgICAgICAgICAgICstLS0tLS0t LS0tLSsgICAgICAgICAgICAgICstLS0tLS0tLS0tKwp8IFBsZWRnZSB8ICAgICAgICAgICAgfCBM b2NhbCAgICAgfCAgICAgICAgICAgICAgfCBDbG91ZCBSQSB8CnwgICAgICAgIHwgICAgICAgICAg ICB8IFJlZ2lzdHJhciB8ICAgICAgICAgICAgICB8IC8gTUFTQSAgIHwKKy0tLS0tLS0tKyAgICAg ICAgICAgICstLS0tLS0tLS0tLSsgICAgICAgICAgICAgICstLS0tLS0tLS0tKwogICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8IDEuIEZ1 bGwgVExTICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHw8LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fAogICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8IDIuIFZvdWNo ZXIgUmVxdWVzdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fAogICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8IDMuIDN4eCBMb2Nh dGlvbjogbG9jYWxyYS5leGFtcGxlLmNvbSAgICAgICAgICAgIHwgICAgCiAgICB8PC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwKICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCA0LiBQcm92aXNp b25hbCBUTFMgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8PC0tLS0tLS0tLS0t LS0tLS0tLS0tPnwgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCA1LiBWb3VjaGVyIFJl cXVlc3QgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8LS0tLS0tLS0tLS0tLS0t LS0tLS0tPnwgNi4gVm91Y2hlciBSZXF1ZXN0ICAgICAgIHwKICAgIHwgICAgICAgICAgICAgICAg ICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fAogICAgfCAgICAgICAgICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8ICAgICAgICAgICAgICAgICAg ICAgIHwgNy4gVm91Y2hlciBSZXNwb25zZSAgICAgIHwKICAgIHwgICAgICAgICAgICAgICAgICAg ICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAgfCA4LiBWb3VjaGVyIFJlc3BvbnNl ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0t LXwgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCA5LiBWYWxpZGF0ZSBUTFMgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tPnwg ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwgICAgICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCAxMC4gZXRjLiAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgICAg ICAgICAgICAgICAgICAgICAgICAgIHwKfn5+CgojIyBWb3VjaGVyIFJlcXVlc3QgSGFuZGxlZCBi eSBDbG91ZCBSZWdpc3RyYXIKCiMjIyBPcHRpb24gMTogRVNUIGVucm9sbCBjb21wbGV0ZWQgYWdh aW5zdCBjbG91ZCByZWdpc3RyYXIKClRoZSBWb3VjaGVyIGluY2x1ZGVzIHRoZSBzZXJ2aWNlIGRv bWFpbiB0byB1c2UgYWZ0ZXIgRVNUIGVucm9sbCBpcyBjb21wbGV0ZS4KCn5+fgorLS0tLS0tLS0r ICAgICAgICAgICAgKy0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgKy0tLS0tLS0tLS0rCnwgUGxl ZGdlIHwgICAgICAgICAgICB8IExvY2FsICAgICB8ICAgICAgICAgICAgICB8IENsb3VkIFJBIHwK fCAgICAgICAgfCAgICAgICAgICAgIHwgU2VydmljZSAgIHwgICAgICAgICAgICAgIHwgLyBNQVNB ICAgfAorLS0tLS0tLS0rICAgICAgICAgICAgKy0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgKy0t LS0tLS0tLS0rCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwKICAgIHwgMS4gRnVsbCBUTFMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLT58CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwKICAgIHwgMi4gVm91Y2hlciBSZXF1ZXN0ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfAogICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LT58CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgIHwgMy4gVm91Y2hlciBSZXNwb25zZSB7c2VydmljZTpmcWRufSAgICAgICAgICAgICAg fAogICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18 IAogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICB8IDQuIEVTVCBlbnJvbGwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fAog ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAg ICB8IDUuIENlcnRpZmljYXRlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg IHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAogICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8 IDYuIEZ1bGwgVExTICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHw8 LS0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8IDcu IFNlcnZpY2UgQWNjZXNzICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwtLS0t LS0tLS0tLS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgICAgICAgICAgICAgfAp+fn4KCiMjIyBP cHRpb24gMjogRVNUIHJlZGlyZWN0IGJ5IGNsb3VkIHJlZ2lzdHJhcgoKQXMgdHJ1c3QgaXMgYWxy ZWFkeSBlc3RhYmxpc2hlZCB2aWEgdGhlIFZvdWNoZXIsIHRoZSBwbGVkZ2UgZG9lcyBhIGZ1bGwg VExTIGhhbmRzaGFrZSBhZ2FpbnN0IHRoZSBsb2NhbCBSQS4KCn5+fgorLS0tLS0tLS0rICAgICAg ICAgICAgKy0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgKy0tLS0tLS0tLS0rCnwgUGxlZGdlIHwg ICAgICAgICAgICB8IExvY2FsICAgICB8ICAgICAgICAgICAgICB8IENsb3VkIFJBIHwKfCAgICAg ICAgfCAgICAgICAgICAgIHwgUmVnaXN0cmFyIHwgICAgICAgICAgICAgIHwgLyBNQVNBICAgfAor LS0tLS0tLS0rICAgICAgICAgICAgKy0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgKy0tLS0tLS0t LS0rCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgIHwgMS4gRnVsbCBUTFMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58 CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgIHwgMi4gVm91Y2hlciBSZXF1ZXN0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog ICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58CiAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAg IHwgMy4gVm91Y2hlciBSZXNwb25zZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAg fDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18IAogICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8 IDQuIEVTVCBlbnJvbGwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fAogICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8IDUu IDN4eCBMb2NhdGlvbjogbG9jYWxyYS5leGFtcGxlLmNvbSAgICAgICAgICAgIHwKICAgIHw8LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfCAKICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCA2LiBG dWxsIFRMUyAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8PC0tLS0t LS0tLS0tLS0tLS0tLS0tPnwgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCA3LiBFU1Qg RW5yb2wgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8LS0tLS0tLS0t LS0tLS0tLS0tLS0tPnwgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwgICAgICAgICAg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCA4LiBDZXJ0aWZp Y2F0ZSAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8PC0tLS0tLS0tLS0t LS0tLS0tLS0tLXwgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwgICAgICAgICAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCA5LiBldGMuICAgICAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8LS0tLS0tLS0tLS0tLS0t LS0tLS0tPnwgICAgICAgICAgICAgICAgICAgICAgICAgIHwKfn5+CgojIyMgT3B0aW9uIDM6IFZv dWNoZXIgaW5jbHVkZXMgRVNUIGRvbWFpbgoKVGhlIFZvdWNoZXIgaW5jbHVkZXMgdGhlIEVTVCBk b21haW4gdG8gdXNlIGZvciBFU1QgZW5yb2xsLiBJdCBpcyBhc3N1bWVkIHNlcnZpY2VzIGFyZSBh Y2Nlc3NlZCBhdCB0aGF0IGRvbWFpbiB0b28uCkFzIHRydXN0IGlzIGFscmVhZHkgZXN0YWJsaXNo ZWQgdmlhIHRoZSBWb3VjaGVyLCB0aGUgcGxlZGdlIGRvZXMgYSBmdWxsIFRMUyBoYW5kc2hha2Ug YWdhaW5zdCB0aGUgbG9jYWwgUkEuCgp+fn4KKy0tLS0tLS0tKyAgICAgICAgICAgICstLS0tLS0t LS0tLSsgICAgICAgICAgICAgICstLS0tLS0tLS0tKwp8IFBsZWRnZSB8ICAgICAgICAgICAgfCBM b2NhbCAgICAgfCAgICAgICAgICAgICAgfCBDbG91ZCBSQSB8CnwgICAgICAgIHwgICAgICAgICAg ICB8IFJlZ2lzdHJhciB8ICAgICAgICAgICAgICB8IC8gTUFTQSAgIHwKKy0tLS0tLS0tKyAgICAg ICAgICAgICstLS0tLS0tLS0tLSsgICAgICAgICAgICAgICstLS0tLS0tLS0tKwogICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8IDEuIEZ1 bGwgVExTICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHw8LS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fAogICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8IDIuIFZvdWNo ZXIgUmVxdWVzdCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fAogICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8IDMuIFZvdWNoZXIg UmVzcG9uc2UgIHtsb2NhbHJhOmZxZG59ICAgICAgICAgICAgIHwKICAgIHw8LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfCAKICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCA0LiBGdWxsIFRMUyAg ICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8PC0tLS0tLS0tLS0tLS0t LS0tLS0tPnwgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwgICAgICAgICAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCA1LiBFU1QgRW5yb2wgICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8LS0tLS0tLS0tLS0tLS0tLS0t LS0tPnwgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwgICAgICAgICAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCA2LiBDZXJ0aWZpY2F0ZSAgICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0t LXwgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwgICAgICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCA3LiBldGMuICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwg ICAgICAgICAgICAgICAgICAgICAgICAgIHwKfn5+CgojIFBsZWRnZSBDZXJ0aWZpY2F0ZSBJZGVu dGl0eSBDb25zaWRlcmF0aW9ucwoKQlJTS0kgc2VjdGlvbiA1LjkuMiBzcGVjaWZpZXMgdGhhdCB0 aGUgcGxlZGdlIE1VU1Qgc2VuZCBhIENTUiBBdHRyaWJ1dGVzIHJlcXVlc3QgdG8gdGhlIHJlZ2lz dHJhci4gVGhlIHJlZ2lzdHJhciBNQVkgdXNlIHRoaXMgbWVjaGFuaXNtIHRvIGluc3RydWN0IHRo ZSBwbGVkZ2UgYWJvdXQgdGhlIGlkZW50aXRpZXMgaXQgc2hvdWxkIGluY2x1ZGUgaW4gdGhlIENT UiByZXF1ZXN0IGl0IHNlbmRzIGFzIHBhcnQgb2YgZW5yb2xsbWVudC4gVGhlIHJlZ2lzdHJhciBt YXkgdXNlIHRoaXMgbWVjaGFuaXNtIHRvIHRlbGwgdGhlIHBsZWRnZSB3aGF0IFN1YmplY3Qgb3Ig U3ViamVjdCBBbHRlcm5hdGl2ZSBOYW1lIGlkZW50aXR5IGluZm9ybWF0aW9uIHRvIGluY2x1ZGUg aW4gaXRzIENTUiByZXF1ZXN0LiBUaGlzIGNhbiBiZSB1c2VmdWwgaWYgdGhlIFN1YmplY3QgbXVz dCBoYXZlIGEgc3BlY2lmaWMgdmFsdWUgaW4gb3JkZXIgdG8gY29tcGxldGUgZW5yb2xsbWVudCB3 aXRoIHRoZSBDQS4KCkZvciBleGFtcGxlLCB0aGUgcGxlZGdlIG1heSBvbmx5IGJlIGF3YXJlIG9m IGl0cyBJRGV2SUQgU3ViamVjdCB3aGljaCBpbmNsdWRlcyBhIG1hbnVmYWN0dXJlciBzZXJpYWwg bnVtYmVyLCBidXQgbXVzdCBpbmNsdWRlIGEgc3BlY2lmaWMgZnVsbHkgcXVhbGlmaWVkIGRvbWFp biBuYW1lIGluIHRoZSBDU1IgaW4gb3JkZXIgdG8gY29tcGxldGUgZG9tYWluIG93bmVyc2hpcCBw cm9vZnMgcmVxdWlyZWQgYnkgdGhlIENBLiBBcyBhbm90aGVyIGV4YW1wbGUsIHRoZSByZWdpc3Ry YXIgbWF5IGRlZW0gdGhlIG1hbnVmYWN0dXJlciBzZXJpYWwgbnVtYmVyIGluIGFuIElEZXZJRCBh cyBwZXJzb25hbGx5IGlkZW50aWZpYWJsZSBpbmZvcm1hdGlvbiwgYW5kIG1heSB3YW50IHRvIHNw ZWNpZnkgYSBuZXcgcmFuZG9tIG9wYXF1ZSBpZGVudGlmaWVyIHRoYXQgdGhlIHBsZWRnZSBzaG91 bGQgdXNlIGluIGl0cyBDU1IuCgojIElBTkEgQ29uc2lkZXJhdGlvbnMKCltbIFRPRE8gXV0KCiMg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCltbIFRPRE8gXV0K --_004_DM6PR11MB3385FD834E826E25160B53AADBD50DM6PR11MB3385namp_-- From nobody Tue Aug 6 07:38:02 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C3F120224; Tue, 6 Aug 2019 07:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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=jaS3wYX8; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cQyAG7Yu Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jhw51zh19E3d; Tue, 6 Aug 2019 07:37:51 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6F51201F2; Tue, 6 Aug 2019 07:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14730; q=dns/txt; s=iport; t=1565102266; x=1566311866; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=2P+Xn56Xzn2gbJgc+MV1x4dY6qLoHN8XghIsvyQXD50=; b=jaS3wYX8AUxedqBdtf2lW39AvWlUG1uFSrVz2qTBjpFnT8TOCTKDz/cO HXcj38hRywuaTX1wOX3KCcLCcDoT2SGwgF5ddFLnaYO/pakc54I+gG+7x Jpy6RA9wUUG6j+DJU03bcC9R/qgqu77Zd0mtJ59zzaysKDaKBvuokQ4AA 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AVxLSgh/vhTg47/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/bR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcmLE0z2KNbhbjcxG4JJU1o2t3w=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CNAACgj0ld/4gNJK1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBUwcBAQsBgRUvJCwDbVUgBAsXEwqEFINHA4RShl1Mgg+JWYkrhFeBLoE?= =?us-ascii?q?kA1QJAQEBDAEBHw4CAQGEPwIXgicjNAkOAQQBAQQBAQIBBm2FJwyFSgEBAQE?= =?us-ascii?q?DEhEKEwEBOA8CAQgRBAEBKAMCAgIfERQJCAIEARIIEweDAYEdTQMdAQIMoF4?= =?us-ascii?q?CgTiIYHGBMoJ6AQEFhQ0NC4ITAwaBNAGLYheBQD+BEUaCHi4+ghpHAoFjKwm?= =?us-ascii?q?CVTKCJowigmiFBpZcQAkCghyGXIlOhBKYLIQaiS+HWYF4jiECBAIEBQIOAQE?= =?us-ascii?q?FgVA4gVhwFYMngkI3gzqKU3KBKYwKAYEgAQE?= X-IronPort-AV: E=Sophos;i="5.64,353,1559520000"; d="scan'208,217";a="305663094" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Aug 2019 14:37:45 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x76EbjVI001641 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Aug 2019 14:37:45 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 6 Aug 2019 09:37:44 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 6 Aug 2019 09:37:43 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 6 Aug 2019 09:37:43 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jvaNtj4NZgEMN+1LZvN1uhG6fzxhCX2lzl9s/zBZBW0845Vy34cGzqLcX70txoym+i/RiqhkQESfYE9nPHVgSByCr0XkeW1stuDrYvjnlZOZxJLlh90It/eLuFYEVujyfuULgShwJIvMxAFCSQm7cXTSm+ELsQIAMa5sVz2YY2r5VTyYOARCmcsTo63cVgbDpbqZWeI9u7158d/OKM0PtarsEgE73jRolfHr3q4WMvwjrWY4ofbgsqPFhKh/4JZW0IIDYwX3J9ZAIcuj9JP9vllRm2RtIHiHR4UAQRvekIVs/2CTBSk5TdiQ8fJX7HTABknXYHnxkSPQcbewz6EZZA== 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=2P+Xn56Xzn2gbJgc+MV1x4dY6qLoHN8XghIsvyQXD50=; b=GWSJQu88Sf+rZui2GvywV/duU559BKnDc6y1NyzIp1XgjL7fNvzmoyaF8V804zzk/3pBgRX03B3+PhmD8WZmzkv6xCrjbPG9iONmcxi4OYpykhR921VpksoJtN6Y5iKgKRRRMhybIdk4IHHitUgMxjTJuto791/AO8Q/Sl6Kh5XmSnjqogXl+S6hFrJGmCMNjUvHLb5KMR7B75nux6mK08Jw+ri4SdAH254DSPrsjuuS8ICb3a4tqrqt17i2cGwh1uJBbBPsMDrzyE1aLCdpGI+1nBAo/fB5geTMyf6eaAjS8sEms/PxMQ7GXCgB36Smw68hCl1UKwqSnYBxD62idA== 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=2P+Xn56Xzn2gbJgc+MV1x4dY6qLoHN8XghIsvyQXD50=; b=cQyAG7YuqKqeDsft3pykMAgFOIx2DwzAAezJPSTQ1IdPUbrB56efLG2NdZQHmK9DNqyg4I+tGcJ1DOvThRJFkpI1TUBRXwLczh0oJGkhe4kxFhB2LNjndrtmJZghbEZmrMaVQUPZvPZ685/jkyxB1PbNoU1/y4Hsmoi9aWRNhAQ= Received: from DM6PR11MB3385.namprd11.prod.outlook.com (20.176.123.12) by DM6PR11MB2842.namprd11.prod.outlook.com (20.176.98.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Tue, 6 Aug 2019 14:37:41 +0000 Received: from DM6PR11MB3385.namprd11.prod.outlook.com ([fe80::21d7:6788:7090:d0ae]) by DM6PR11MB3385.namprd11.prod.outlook.com ([fe80::21d7:6788:7090:d0ae%7]) with mapi id 15.20.2115.005; Tue, 6 Aug 2019 14:37:41 +0000 From: "Owen Friel (ofriel)" To: "Owen Friel (ofriel)" , Rifaat Shekh-Yusef , "anima@ietf.org" , "iot-onboarding@ietf.org" Thread-Topic: [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI Thread-Index: AQHVSV2H3NB63QcBKUu8AXFFCSgthabuGrdwgAAbXGA= Date: Tue, 6 Aug 2019 14:37:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [64.103.40.24] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c272d1c9-e1f4-4bf0-98dd-08d71a7ba322 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM6PR11MB2842; x-ms-traffictypediagnostic: DM6PR11MB2842: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(396003)(346002)(136003)(366004)(189003)(199004)(5024004)(25786009)(256004)(8936002)(74316002)(5660300002)(66946007)(66476007)(66556008)(64756008)(66446008)(478600001)(966005)(81166006)(81156014)(52536014)(33656002)(8676002)(7736002)(14454004)(2501003)(68736007)(26005)(7696005)(102836004)(6506007)(186003)(53546011)(76176011)(110136005)(316002)(2940100002)(606006)(99286004)(66066001)(6436002)(2201001)(229853002)(2906002)(55016002)(6246003)(6306002)(54896002)(9686003)(236005)(53936002)(11346002)(446003)(476003)(486006)(790700001)(3846002)(6116002)(76116006)(86362001)(71200400001)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR11MB2842; H:DM6PR11MB3385.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Qx/5SOd/dqK43p6U/6hs/DGT1eArpPyV7sgyUEUB1oEL1kDP6lIp243sp/1HR4EAXO8ehXfoc5tgBs3ZCjaXWiVPoD97pX/vs1CNANr+WVQayjTNjegsUqY/rbA8abK0hrUOzgzcTn2QP4N/qfryveYChHF3OLHt7bMh4Ro6HJ6K9FMyuUMdLU3jMjkl1MFHMLDcK6nPL5ErzN3rE4o6S3P5+/H76AAV+MM0cI4qfFj7arLfK87KTHkGih6rlbfa9EB2c1uerlOvuezasrD/XcegAMnNOXlYtK6xxDCVWjOOW3gMId6UkLZ/cb0oHQfDBR2ZxvPeZZtxXHtkBU+udcX0dzoZ7LoT6J9Hx58GU8dWDS/RLo8gu9NJx7CcIOeaEudACC4axqaIi+5/AD2gI9g/8/wpKWSYqam7c+d/Tlc= Content-Type: multipart/alternative; boundary="_000_DM6PR11MB33851A9026943624FC5BD478DBD50DM6PR11MB3385namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c272d1c9-e1f4-4bf0-98dd-08d71a7ba322 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2019 14:37:41.4858 (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: ofriel@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2842 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 14:37:53 -0000 --_000_DM6PR11MB33851A9026943624FC5BD478DBD50DM6PR11MB3385namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RllJLCBJdHMgdXAgb24gZ2l0aHViIG5vdzoNCg0KaHR0cHM6Ly9naXRodWIuY29tL3Vwcm9zL2Jy c2tpLWNsb3VkDQoNCg0KRnJvbTogQW5pbWEgPGFuaW1hLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJl aGFsZiBPZiBPd2VuIEZyaWVsIChvZnJpZWwpDQpTZW50OiAwNiBBdWd1c3QgMjAxOSAxNDowNQ0K VG86IFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPjsgYW5pbWFAaWV0 Zi5vcmc7IGlvdC1vbmJvYXJkaW5nQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0FuaW1hXSBbSW90 LW9uYm9hcmRpbmddIERldmljZSBDZXJ0aWZpY2F0ZSBEZXBsb3ltZW50IEF1dG9tYXRpb24gd2l0 aCBBQ01FIHVzaW5nIEJSU0tJDQoNCkhpIGd1eXMsDQoNCkFmdGVyIHRoZSBtZWV0aW5nIGFuZCBm cm9tIGNvcnJpZG9yIGNvbnZlcnNhdGlvbnMgd2l0aCBUb2VybGVzcywgSSBoYWQgYWN0dWFsbHkg YWxyZWFkeSBzdGFydGVkIG9uIHN1Y2ggYSBkcmFmdC4NCg0KV2hhdCBJIGhhdmUgc3RhcnRlZCBz byBmYXIgaXMgYXR0YWNoZWQuIEl0cyBub3Qgb24gYSBwdWJsaWMgcmVwbyB5ZXQsIGJ1dCB3aWxs IHB1dCBpdCB0aGVyZS4gWW91IGFyZSBhbHJlYWR5IG5hbWVkIG9uIGl0IFJpZmFhdCwgaGFwcHkg dG8gYWRkIHlvdSB0b28gTWljaGFlbCBhbmQgeW91IGNhbiBoZWxwIGZpZ3VyZSBvdXQgc29tZSBv ZiB0aGUgb3BlbiByZWRpcmVjdCBvcHRpb25zIG91dGxpbmVkIGluIGl0IOKYug0KDQpNeSBoaWdo IGxldmVsIHRob3VnaHRzIG9uIHRoaXMgd2VyZSB0byBrZWVwIHRoZSBBQ01FIHNwZWNpZmljcyBv dXQgb2YgdGhlIGRyYWZ0LCBhbmQgdXNlIHRoZSBkcmFmdCB0byBkZWZpbmUgdGhlIGNsb3VkIFJB IGJlaGF2aW91ciwgYW5kIHRoZSBwbGVkZ2UgYmVoYXZpb3VyIHdoZW4gaW50ZXJhY3Rpbmcgd2l0 aCB0aGUgY2xvdWQgUkEsIGFuZCB0aGUgdmFyaW91cyBjZXJ0LCBDQSwgVExTLCByZWRpcmVjdCwg ZXRjLiBkZXRhaWxzLiBUaGUgZmFjdCB0aGF0IHRoZSBSQSAod2hldGhlciBjbG91ZCBvciBsb2Nh bCkgKm1heSogdXNlIEFDTUUgdG8gdGFsayB0byB0aGUgQ0EgaXMgdHJhbnNwYXJlbnQgdG8gdGhl IHBsZWRnZS4NCg0KSSB3YXMgdGhpbmtpbmcgdGhhdCB0aGUgQUNNRSBzcGVjaWZpY3MgY291bGQg YmUgY292ZXJlZCBpbiBhIGRpZmZlcmVudCBkcmFmdCBiYXNlZCBvbiBtZXJnaW5nIGRyYWZ0LXl1 c2VmLWFjbWUtM3JkLXBhcnR5LWRldmljZS1hdHRlc3RhdGlvbiBhbmQgZHJhZnQtZnJpZWwtYWNt ZS1pbnRlZ3JhdGlvbnMsIGJ1dCBsZWF2ZSB0aGUgQlJTS0kgY2xhcmlmaWNhdGlvbnMvc3BlY2lm aWNzIGluIHRoaXMgb25lLg0KDQpUaG91Z2h0cz8NCk93ZW4NCg0KDQoNCg0KRnJvbTogSW90LW9u Ym9hcmRpbmcgPGlvdC1vbmJvYXJkaW5nLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlvdC1vbmJv YXJkaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgUmlmYWF0IFNoZWtoLVl1c2Vm DQpTZW50OiAwMiBBdWd1c3QgMjAxOSAxOTowOQ0KVG86IGFuaW1hQGlldGYub3JnPG1haWx0bzph bmltYUBpZXRmLm9yZz47IGlvdC1vbmJvYXJkaW5nQGlldGYub3JnPG1haWx0bzppb3Qtb25ib2Fy ZGluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFtJb3Qtb25ib2FyZGluZ10gRGV2aWNlIENlcnRpZmlj YXRlIERlcGxveW1lbnQgQXV0b21hdGlvbiB3aXRoIEFDTUUgdXNpbmcgQlJTS0kNCg0KQWxsLA0K DQpEdXJpbmcgdGhlIGxhc3QgSUVURiBtZWV0aW5nIGluIE1vbnRyZWFsIHdlIGhhZCBhIHNpZGUg bWVldGluZyB0byBkaXNjdXNzIHRoZQ0KZGVwbG95bWVudCBhdXRvbWF0aW9uIG9mIEFDTUUgaXNz dWVkIGNlcnRpZmljYXRlcyB0byBkZXZpY2VzLCBhbmQgdGhlIHBvdGVudGlhbA0KdXNlIG9mIHRo ZSBCUlNLSSBtZWNoYW5pc20gdG8gaGVscCB3aXRoIHRoaXMuIEl0IHdhcyBjbGVhciBmcm9tIHRo ZSBkaXNjdXNzaW9uDQp0aGF0IEJSU0tJIGNhbiBiZSB1c2VkIHRvIGhlbHAgYWRkcmVzcyB0aGlz IHVzZSBjYXNlLCBhbmQgdGhhdCBmdXJ0aGVyIGRpc2N1c3Npb24gaXMNCm5lZWRlZCB0byBkZWZp bmUgdGhlIG5lZWRlZCBlbmhhbmNlbWVudHMgdG8gQlJTS0kuDQoNClRoZSBjdXJyZW50IEJSU0tJ IG1lY2hhbmlzbSBvbmx5IGJyaWVmbHkgZGlzY3Vzc2VzIHRoZSBDbG91ZCBSZWdpc3RyYXIgb3B0 aW9uIGluDQpzZWN0aW9uIDIuNywgd2hpY2ggY291bGQgYmUgdXNlZCB0byBoZWxwIGFkZHJlc3Mg dGhpcyB1c2UgY2FzZS4NCg0KTWljaGFlbCBSaWNoYXJkc29uIGFuZCBJIGhhZCBhbm90aGVyIG1l ZXRpbmcgb3ZlciBsdW5jaCB5ZXN0ZXJkYXkgdG8gZnVydGhlcg0KZGlzY3VzcyB0aGlzIGFuZCB3 ZSBkZWNpZGVkIHRvIHdvcmsgb24gYSBuZXcgZHJhZnQgdG8gZGVzY3JpYmUgdGhlIGlzc3VlIGFu ZA0KZGVmaW5lIGEgc29sdXRpb24uDQoNCkJlY2F1c2Ugb2YgdmFjYXRpb25zIGFuZCBvdGhlciBj b21taXRtZW50cywgd2Ugd2lsbCB0cnkgdG8gcHVibGlzaCB0aGUgZmlyc3QNCnZlcnNpb24gb2Yg dGhlIGRyYWZ0IGVhcmx5IE9jdG9iZXIuDQoNClJlZ2FyZHMsDQogUmlmYWF0ICYgTWljaGFlbA0K --_000_DM6PR11MB33851A9026943624FC5BD478DBD50DM6PR11MB3385namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6 bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1HQiIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+RllJLCBJdHMgdXAgb24gZ2l0aHViIG5vdzo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS91cHJvcy9icnNraS1jbG91ZCI+aHR0 cHM6Ly9naXRodWIuY29tL3Vwcm9zL2Jyc2tpLWNsb3VkPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48Yj48c3BhbiBsYW5n PSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gQW5pbWEgJmx0O2Fu aW1hLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk93ZW4gRnJpZWwg KG9mcmllbCk8YnI+DQo8Yj5TZW50OjwvYj4gMDYgQXVndXN0IDIwMTkgMTQ6MDU8YnI+DQo8Yj5U bzo8L2I+IFJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7cmlmYWF0LmlldGZAZ21haWwuY29tJmd0Ozsg YW5pbWFAaWV0Zi5vcmc7IGlvdC1vbmJvYXJkaW5nQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBbQW5pbWFdIFtJb3Qtb25ib2FyZGluZ10gRGV2aWNlIENlcnRpZmljYXRlIERlcGxv eW1lbnQgQXV0b21hdGlvbiB3aXRoIEFDTUUgdXNpbmcgQlJTS0k8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPkhpIGd1eXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkFmdGVyIHRoZSBtZWV0aW5nIGFuZCBmcm9tIGNvcnJpZG9y IGNvbnZlcnNhdGlvbnMgd2l0aCBUb2VybGVzcywgSSBoYWQgYWN0dWFsbHkgYWxyZWFkeSBzdGFy dGVkIG9uIHN1Y2ggYSBkcmFmdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+V2hhdCBJIGhhdmUgc3RhcnRlZCBzbyBmYXIgaXMgYXR0 YWNoZWQuIEl0cyBub3Qgb24gYSBwdWJsaWMgcmVwbyB5ZXQsIGJ1dCB3aWxsIHB1dCBpdCB0aGVy ZS4gWW91IGFyZSBhbHJlYWR5IG5hbWVkIG9uIGl0IFJpZmFhdCwgaGFwcHkgdG8gYWRkIHlvdSB0 b28gTWljaGFlbCBhbmQgeW91IGNhbg0KIGhlbHAgZmlndXJlIG91dCBzb21lIG9mIHRoZSBvcGVu IHJlZGlyZWN0IG9wdGlvbnMgb3V0bGluZWQgaW4gaXQgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpXaW5nZGluZ3M7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPko8L3NwYW4+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TXkgaGlnaCBsZXZlbCB0 aG91Z2h0cyBvbiB0aGlzIHdlcmUgdG8ga2VlcCB0aGUgQUNNRSBzcGVjaWZpY3Mgb3V0IG9mIHRo ZSBkcmFmdCwgYW5kIHVzZSB0aGUgZHJhZnQgdG8gZGVmaW5lIHRoZSBjbG91ZCBSQSBiZWhhdmlv dXIsIGFuZCB0aGUgcGxlZGdlIGJlaGF2aW91ciB3aGVuIGludGVyYWN0aW5nDQogd2l0aCB0aGUg Y2xvdWQgUkEsIGFuZCB0aGUgdmFyaW91cyBjZXJ0LCBDQSwgVExTLCByZWRpcmVjdCwgZXRjLiBk ZXRhaWxzLiBUaGUgZmFjdCB0aGF0IHRoZSBSQSAod2hldGhlciBjbG91ZCBvciBsb2NhbCkgKjxi Pm1heTwvYj4qIHVzZSBBQ01FIHRvIHRhbGsgdG8gdGhlIENBIGlzIHRyYW5zcGFyZW50IHRvIHRo ZSBwbGVkZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkkgd2FzIHRoaW5raW5nIHRoYXQgdGhlIEFDTUUgc3BlY2lmaWNzIGNvdWxk IGJlIGNvdmVyZWQgaW4gYSBkaWZmZXJlbnQgZHJhZnQgYmFzZWQgb24gbWVyZ2luZw0KPC9zcGFu PmRyYWZ0LXl1c2VmLWFjbWUtM3JkLXBhcnR5LWRldmljZS1hdHRlc3RhdGlvbiBhbmQgZHJhZnQt ZnJpZWwtYWNtZS1pbnRlZ3JhdGlvbnMsIGJ1dCBsZWF2ZSB0aGUgQlJTS0kgY2xhcmlmaWNhdGlv bnMvc3BlY2lmaWNzIGluIHRoaXMgb25lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaG91Z2h0cz88 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPk93ZW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IElvdC1vbmJvYXJkaW5nICZs dDs8YSBocmVmPSJtYWlsdG86aW90LW9uYm9hcmRpbmctYm91bmNlc0BpZXRmLm9yZyI+aW90LW9u Ym9hcmRpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJp ZmFhdCBTaGVraC1ZdXNlZjxicj4NCjxiPlNlbnQ6PC9iPiAwMiBBdWd1c3QgMjAxOSAxOTowOTxi cj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmFuaW1hQGlldGYub3JnIj5hbmltYUBpZXRm Lm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzppb3Qtb25ib2FyZGluZ0BpZXRmLm9yZyI+DQppb3Qt b25ib2FyZGluZ0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0lvdC1vbmJvYXJk aW5nXSBEZXZpY2UgQ2VydGlmaWNhdGUgRGVwbG95bWVudCBBdXRvbWF0aW9uIHdpdGggQUNNRSB1 c2luZyBCUlNLSTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+QWxsLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDo3Mi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RHVyaW5nIHRoZSBsYXN0IElF VEYgbWVldGluZyBpbiBNb250cmVhbCB3ZSBoYWQgYSBzaWRlIG1lZXRpbmcgdG8gZGlzY3VzcyB0 aGUmbmJzcDs8YnI+DQpkZXBsb3ltZW50IGF1dG9tYXRpb24gb2YgQUNNRSBpc3N1ZWQgY2VydGlm aWNhdGVzIHRvIGRldmljZXMsIGFuZCB0aGUgcG90ZW50aWFsJm5ic3A7PGJyPg0KdXNlIG9mIHRo ZSBCUlNLSSBtZWNoYW5pc20gdG8gaGVscCB3aXRoIHRoaXMuIEl0IHdhcyBjbGVhciBmcm9tIHRo ZSBkaXNjdXNzaW9uJm5ic3A7PGJyPg0KdGhhdCBCUlNLSSBjYW4gYmUgdXNlZCB0byBoZWxwIGFk ZHJlc3MgdGhpcyB1c2UgY2FzZSwgYW5kIHRoYXQgZnVydGhlciBkaXNjdXNzaW9uIGlzJm5ic3A7 PGJyPg0KbmVlZGVkIHRvIGRlZmluZSB0aGUgbmVlZGVkIGVuaGFuY2VtZW50cyB0byBCUlNLSS48 YnI+DQo8YnI+DQpUaGUgY3VycmVudCBCUlNLSSBtZWNoYW5pc20gb25seSBicmllZmx5IGRpc2N1 c3NlcyB0aGUgQ2xvdWQgUmVnaXN0cmFyIG9wdGlvbiBpbiZuYnNwOzxicj4NCnNlY3Rpb24gMi43 LCB3aGljaCBjb3VsZCBiZSB1c2VkIHRvIGhlbHAgYWRkcmVzcyB0aGlzIHVzZSBjYXNlLjxicj4N Cjxicj4NCk1pY2hhZWwgUmljaGFyZHNvbiBhbmQgSSBoYWQgYW5vdGhlciBtZWV0aW5nIG92ZXIg bHVuY2ggeWVzdGVyZGF5IHRvIGZ1cnRoZXImbmJzcDs8YnI+DQpkaXNjdXNzIHRoaXMgYW5kIHdl IGRlY2lkZWQgdG8gd29yayBvbiBhIG5ldyBkcmFmdCB0byBkZXNjcmliZSB0aGUgaXNzdWUgYW5k Jm5ic3A7PGJyPg0KZGVmaW5lIGEgc29sdXRpb24uPGJyPg0KPGJyPg0KQmVjYXVzZSBvZiB2YWNh dGlvbnMgYW5kIG90aGVyIGNvbW1pdG1lbnRzLCB3ZSB3aWxsIHRyeSB0byBwdWJsaXNoIHRoZSBm aXJzdCZuYnNwOzxicj4NCnZlcnNpb24gb2YgdGhlIGRyYWZ0IGVhcmx5IE9jdG9iZXIuPGJyPg0K PGJyPg0KUmVnYXJkcyw8YnI+DQombmJzcDtSaWZhYXQgJmFtcDsgTWljaGFlbDwvc3Bhbj4mbmJz cDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_DM6PR11MB33851A9026943624FC5BD478DBD50DM6PR11MB3385namp_-- From nobody Tue Aug 6 08:01:23 2019 Return-Path: <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@amazonses.watsen.net> X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC1812019B; Tue, 6 Aug 2019 08:01:22 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLJf-LyJo56z; Tue, 6 Aug 2019 08:01:20 -0700 (PDT) Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 143AB12018A; Tue, 6 Aug 2019 08:01:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1565103678; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=10RPUjtxgY/Jx9PmgQE0WMM0xMAnbX5UNPbYvNcONno=; b=Q9FB6YAakSEXaJ1Th8u2rF+ijo+9DpV1v8EMHMBRxfrDsEGFRmWSqYRmNqTZ2jQi GbO1iCDNT2dLzXK2U7U8qZ9WcIypn0EKRZ0oZoLCfUOyL112ZQbYkdK6y6DB2+YQk0g 1tDJRBNwT5JJiP4VO7QpvtEhkESXq/VIIHn5Xy5w= From: Kent Watsen Message-ID: <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2D5531B2-9AD8-4829-8137-2C9730C89108" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 6 Aug 2019 15:01:18 +0000 In-Reply-To: Cc: Rifaat Shekh-Yusef , "anima@ietf.org" , "iot-onboarding@ietf.org" To: "Owen Friel (ofriel)" References: X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.08.06-54.240.8.31 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 15:01:22 -0000 --Apple-Mail=_2D5531B2-9AD8-4829-8137-2C9730C89108 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Skimming quickly, I see now the direction to go to a cloud registrar to = be redirected to a local registrar. I feel compelled to point out that = this is exactly what SZTP (RFC 8572) does, or at least, supports. = Actually, as a more general statement, it was originally said that the = two WG's approaches were different, but they are now becoming more and = more alike. Well, since SZTP is published already, it's more like the = ANIMA approach is becoming more like SZTP, albeit seemingly with more = complexity. Regarding ACME integration during bootstrap, I think the basic desire is = to configure a device to obtain a certificate via ACME, configuration = which so happens to be provided at the time of the bootstrap event, but = could also happen at anytime thereafter. Support for such = configuration should be added to = https://tools.ietf.org/html/draft-ietf-netconf-keystore = . =20 Kent > On Aug 6, 2019, at 10:37 AM, Owen Friel (ofriel) = wrote: >=20 > FYI, Its up on github now: > =20 > https://github.com/upros/brski-cloud = > =20 > =20 > From: Anima > = On Behalf Of Owen Friel (ofriel) > Sent: 06 August 2019 14:05 > To: Rifaat Shekh-Yusef >; anima@ietf.org ; = iot-onboarding@ietf.org > Subject: Re: [Anima] [Iot-onboarding] Device Certificate Deployment = Automation with ACME using BRSKI > =20 > Hi guys, > =20 > After the meeting and from corridor conversations with Toerless, I had = actually already started on such a draft. > =20 > What I have started so far is attached. Its not on a public repo yet, = but will put it there. You are already named on it Rifaat, happy to add = you too Michael and you can help figure out some of the open redirect = options outlined in it J > =20 > My high level thoughts on this were to keep the ACME specifics out of = the draft, and use the draft to define the cloud RA behaviour, and the = pledge behaviour when interacting with the cloud RA, and the various = cert, CA, TLS, redirect, etc. details. The fact that the RA (whether = cloud or local) *may* use ACME to talk to the CA is transparent to the = pledge. > =20 > I was thinking that the ACME specifics could be covered in a different = draft based on mergingdraft-yusef-acme-3rd-party-device-attestation and = draft-friel-acme-integrations, but leave the BRSKI = clarifications/specifics in this one. > =20 > Thoughts? > Owen > =20 > =20 > =20 > =20 > From: Iot-onboarding > On Behalf Of Rifaat = Shekh-Yusef > Sent: 02 August 2019 19:09 > To: anima@ietf.org ; iot-onboarding@ietf.org = > Subject: [Iot-onboarding] Device Certificate Deployment Automation = with ACME using BRSKI > =20 > All, > =20 > During the last IETF meeting in Montreal we had a side meeting to = discuss the=20 > deployment automation of ACME issued certificates to devices, and the = potential=20 > use of the BRSKI mechanism to help with this. It was clear from the = discussion=20 > that BRSKI can be used to help address this use case, and that further = discussion is=20 > needed to define the needed enhancements to BRSKI. >=20 > The current BRSKI mechanism only briefly discusses the Cloud Registrar = option in=20 > section 2.7, which could be used to help address this use case. >=20 > Michael Richardson and I had another meeting over lunch yesterday to = further=20 > discuss this and we decided to work on a new draft to describe the = issue and=20 > define a solution. >=20 > Because of vacations and other commitments, we will try to publish the = first=20 > version of the draft early October. >=20 > Regards, > Rifaat & Michael =20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima = --Apple-Mail=_2D5531B2-9AD8-4829-8137-2C9730C89108 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Skimming quickly, I see = now the direction to go to a cloud registrar to be redirected to a local = registrar.  I feel compelled to point out that this is exactly what = SZTP (RFC 8572) does, or at least, supports.  Actually, as a more = general statement, it was originally said that the two WG's approaches = were different, but they are now becoming more and more alike. =  Well, since SZTP is published already, it's more like the ANIMA = approach is becoming more like SZTP, albeit seemingly with more = complexity.

Regarding ACME integration during bootstrap, I think the = basic desire is to configure a device to obtain a certificate via ACME, = configuration which so happens to be provided at the time of the = bootstrap event, but could also happen at anytime thereafter.   = Support for such configuration should be added to https://tools.ietf.org/html/draft-ietf-netconf-keystore.&nb= sp;  

Kent



On Aug 6, 2019, at 10:37 AM, Owen Friel (ofriel) <ofriel@cisco.com> = wrote:

FYI, Its up on github now:
 
 
 
From: Anima = <anima-bounces@ietf.org> On Behalf = Of Owen Friel = (ofriel)
Sent: 06 August 2019 14:05
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>; anima@ietf.org; iot-onboarding@ietf.org
Subject: Re: [Anima] = [Iot-onboarding] Device Certificate Deployment Automation with ACME = using BRSKI
 
Hi guys,
 
After the meeting and from = corridor conversations with Toerless, I had actually already started on = such a draft.
 
What I have started so far is attached. Its = not on a public repo yet, but will put it there. You are already named = on it Rifaat, happy to add you too Michael and you can help figure out = some of the open redirect options outlined in it J
 
My high level thoughts on this = were to keep the ACME specifics out of the draft, and use the draft to = define the cloud RA behaviour, and the pledge behaviour when interacting = with the cloud RA, and the various cert, CA, TLS, redirect, etc. = details. The fact that the RA (whether cloud or local) *may* use ACME to talk to the CA is transparent to the = pledge.
 
I was thinking that = the ACME specifics could be covered in a different draft based on = mergingdraft-yusef-acme-3rd-party-device-attestation and = draft-friel-acme-integrations, but leave the BRSKI = clarifications/specifics in this one.
 
Thoughts?
Owen
 
 
 
 
From: Iot-onboarding <iot-onboarding-bounces@ietf.org> On Behalf = Of Rifaat = Shekh-Yusef
Sent: 02 August 2019 19:09
To: anima@ietf.org; iot-onboarding@ietf.org
Subject: [Iot-onboarding] Device = Certificate Deployment Automation with ACME using BRSKI
 
All,
 
During the = last IETF meeting in Montreal we had a side meeting to discuss = the 
deployment automation of ACME issued = certificates to devices, and the potential 
use of = the BRSKI mechanism to help with this. It was clear from the = discussion 
that BRSKI can be used to help address = this use case, and that further discussion is 
needed = to define the needed enhancements to BRSKI.

The current BRSKI mechanism only briefly discusses the Cloud = Registrar option in 
section 2.7, which could be used = to help address this use case.

Michael = Richardson and I had another meeting over lunch yesterday to = further 
discuss this and we decided to work on a new = draft to describe the issue and 
define a = solution.

Because of vacations and other = commitments, we will try to publish the first 
version = of the draft early October.

Regards,
 Rifaat & Michael  
_______________________________________________
Anima mailing = list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

= --Apple-Mail=_2D5531B2-9AD8-4829-8137-2C9730C89108-- From nobody Tue Aug 6 08:53:23 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EFD1203C4; Tue, 6 Aug 2019 08:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 v7Zd4KgAOqWs; Tue, 6 Aug 2019 08:52:59 -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 967FA12037B; Tue, 6 Aug 2019 08:52:59 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id AAC013818C; Tue, 6 Aug 2019 11:52:21 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D1DBF70D; Tue, 6 Aug 2019 11:52:56 -0400 (EDT) From: Michael Richardson To: Kent Watsen cc: "Owen Friel (ofriel)" , "iot-onboarding@ietf.org" , Rifaat Shekh-Yusef , "anima@ietf.org" In-Reply-To: <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@email.amazonses.com> References: <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@email.amazonses.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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 Date: Tue, 06 Aug 2019 11:52:56 -0400 Message-ID: <16869.1565106776@localhost> Archived-At: Subject: Re: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 15:53:11 -0000 Kent Watsen wrote: > Skimming quickly, I see now the direction to go to a cloud registrar to > be redirected to a local registrar. I feel compelled to point out that > this is exactly what SZTP (RFC 8572) does, or at least, supports. > Actually, as a more general statement, it was originally said that the > two WG's approaches were different, but they are now becoming more and > more alike. Well, since SZTP is published already, it's more like the > ANIMA approach is becoming more like SZTP, albeit seemingly with more > complexity. Yes, I had hoped to push towards this view. > Regarding ACME integration during bootstrap, I think the basic desire > is to configure a device to obtain a certificate via ACME, > configuration which so happens to be provided at the time of the > bootstrap event, but could also happen at anytime thereafter. Support > for such configuration should be added to > https://tools.ietf.org/html/draft-ietf-netconf-keystore agreed. From nobody Tue Aug 6 10:24:14 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF5912027C for ; Tue, 6 Aug 2019 10:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 nQnlU1RPpWm4 for ; Tue, 6 Aug 2019 10:24:10 -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 A6D0812024E for ; Tue, 6 Aug 2019 10:24:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E74E33818C for ; Tue, 6 Aug 2019 13:23:27 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 1726C266 for ; Tue, 6 Aug 2019 13:24:03 -0400 (EDT) From: Michael Richardson To: "anima\@ietf.org" X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] comments on draft-ietf-anima-grasp-api X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 17:24:12 -0000 --=-=-= Content-Type: text/plain I read draft-ietf-anima-grasp-api from the expired drafts list. I think that the event-loop architecture is different than a polling architecture. I agree that given an event-loop architecture, that one can build a polled architecture, but the converse is not true. The event-loop mechanism needs something to send events, while the polling system does not. section 2.3.1.3: If you are going to insert C structures, why not use a real example? https://github.com/PJK/libcbor/blob/master/src/cbor/data.h#L164 cbor_value -> cbor_item_t I don't understand what the asa_nonce is for. Is this something that the underlying GRASP library is supposed to use internally to sort out which ASA is which? Maybe this should be either a UUID, or an opaque type, which might in some cases, be a file handle, or contain one. (a la FILE *) 2.3.3 Discovery. 1) I would prefer to be able to ask for the list of cached locators for an objective directly. 2) Rather than flush them explicitely (because there might be other ASAs depending upon them), I'd like to do a discovery that asks for objectives that are at at most X miliseconds old. Flush is therefore X=0. 3) In both threaded and event-loop situations, I'd like to be able have a function called when there are new answers, otherwise, I have to poll. (And, if a function is called, then the question as to which thread does the calling is important; specifically one needs to know which other functions one call at that point answer may well be none. The answer depends upon how locking of structures is done. The answer is easier in event-loop version) 2.3.4 Negotiation. Since the session_nonce is returned by the function, how can the dryrun/run ever be mixed in a single session? maybe I don't know what a session is. Ah, it's a value/result parameters. So, please put it into the input section too. listen_negotiate. I think that this call is wrong in both threaded and event-loop use. I think that in threaded version, I really want a new thread spawned off that does the right things (negotiate_wait, etc.), so I want to provide a function for that thread to run the negotiation. In event-loop, I think that I want the same thing, but in the function, I can't do synchronous calls, so the function has to be called each time. negotiate_step: It says: Threaded implementation: Called in the same thread as the preceding 'request_negotiate' or 'listen_negotiate', with the same value of 'session_nonce'. but if it's in the same thread as listen_negotiate(), then I can only handle negotiation with a single peer in that thread, I think? and I don't think I'd want to call listen_negotiate() for the same objective. negotiate_wait: no idea why I'd use this. Summary: I do not object to this document going forward as Informational, as it represents an explanation of one implementation, and that is what Informational is about. It would be nice to have the view of multiple implementators, but there is no energy for that. While I do not object, I do not see great utility in this document. nits: 2.3.1.3: s/neg/negotiate/ I found the "NEG" term in GRASP confusing, because it seems like NEGative, rather then NEGotiate. I'd prefer it was spelt out in the API. s/dry/dryrun/ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1Jt7IACgkQgItw+93Q 3WV16Qf+Pb6/ZeN93ziDm+01lPxzNanlFYfB3lcjD6Ncfhd4t1SfRyoWfe/4a4wD +0P7T1X5YEjOpgzgiUeRrjvz8M5c2QmVvdC1G5nhxZcWHNq+l6R3ywalde1+t3wR JlxIJK3KIhlnhwheHJvvRM9oGd38vftwh+hdq6ZDqbohDjCsTstwBbfuYzAcSrw9 /+Os1N30LSSth13sIJm3nPgvMP4IUcgRepn/WabMQrWZf7jF3bTk1pQ13QlIrhbM NQ5jdQ/IOZMaLEI8CJpBfBqDN6YJx3mqe4aPXM1PVJR+6tHn5Tvx0cC+oxF0k25B Axem1XJtUx9eVeH36isd8QepDcN34Q== =z49r -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 6 15:12:52 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9A312008B; Tue, 6 Aug 2019 15:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, RCVD_IN_DNSWL_MED=-2.3, 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 NEPUSrQHqq9G; Tue, 6 Aug 2019 15:12:49 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6D67120033; Tue, 6 Aug 2019 15:12:48 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C2446548002; Wed, 7 Aug 2019 00:12:42 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id AE4CB440041; Wed, 7 Aug 2019 00:12:42 +0200 (CEST) Date: Wed, 7 Aug 2019 00:12:42 +0200 From: Toerless Eckert To: Kent Watsen Cc: "Owen Friel (ofriel)" , "iot-onboarding@ietf.org" , Rifaat Shekh-Yusef , "anima@ietf.org" Message-ID: <20190806221242.4j7eprxeklup5c3m@faui48f.informatik.uni-erlangen.de> References: <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@email.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@email.amazonses.com> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 22:12:51 -0000 On Tue, Aug 06, 2019 at 03:01:18PM +0000, Kent Watsen wrote: > Skimming quickly, I see now the direction to go to a cloud registrar to be redirected to a local registrar. I feel compelled to point out that this is exactly what SZTP (RFC 8572) does, or at least, supports. Actually, as a more general statement, it was originally said that the two WG's approaches were different, but they are now becoming more and more alike. Well, since SZTP is published already, it's more like the ANIMA approach is becoming more like SZTP, albeit seemingly with more complexity. I ranted about the need to better describe the common architecture already in prior emails to the anima list. Complexity is in the eye of the beholder. I like the modularity/flexibility that NetConf provides, but of try to find someone who understands how to duplicate the full enrolment process of BRSKI+EST with equivalent NetConf supported Yang object models (especially for TA and Cert enrollment). And then find more constrained devices that would more happily go with that more (IMHO) flexible model. But given how constrained devices also do not like TLS of BRSKI, it would be great if we could come up with a single preferred transport to use with either server-controlle workflow (like SZTP/Netconf) and client-side controlled (like BRSKI). > Regarding ACME integration during bootstrap, I think the basic desire is to configure a device to obtain a certificate via ACME, configuration which so happens to be provided at the time of the bootstrap event, but could also happen at anytime thereafter. Support for such configuration should be added to https://tools.ietf.org/html/draft-ietf-netconf-keystore . I think what you say is not specific to ACME but true for any RA<->CA protocol. The fact that NetConf/SZTP allows to enrol the certificate any time later is a key difference. I think architecturally, you want to make it as soon as possible, but for example you may still want to first do some additional attestation before the key enrollment. This is where BRSKI+EST is a lot less flexible in design, but given how i think there is no model for attestation in IETF, its hard t make the point now. The only ACME specific thing i can think of are the mechanisms for the RA to prove to the CA posession of a domain-name/prefix. That i think is independent of the key-store. More related to the ability of the RA to create DNS entries. No idea if there is a yang model for that (would be nice). Cheers Toerless > Kent > > > > > On Aug 6, 2019, at 10:37 AM, Owen Friel (ofriel) wrote: > > > > FYI, Its up on github now: > > > > https://github.com/upros/brski-cloud > > > > > > From: Anima > On Behalf Of Owen Friel (ofriel) > > Sent: 06 August 2019 14:05 > > To: Rifaat Shekh-Yusef >; anima@ietf.org ; iot-onboarding@ietf.org > > Subject: Re: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI > > > > Hi guys, > > > > After the meeting and from corridor conversations with Toerless, I had actually already started on such a draft. > > > > What I have started so far is attached. Its not on a public repo yet, but will put it there. You are already named on it Rifaat, happy to add you too Michael and you can help figure out some of the open redirect options outlined in it J > > > > My high level thoughts on this were to keep the ACME specifics out of the draft, and use the draft to define the cloud RA behaviour, and the pledge behaviour when interacting with the cloud RA, and the various cert, CA, TLS, redirect, etc. details. The fact that the RA (whether cloud or local) *may* use ACME to talk to the CA is transparent to the pledge. > > > > I was thinking that the ACME specifics could be covered in a different draft based on mergingdraft-yusef-acme-3rd-party-device-attestation and draft-friel-acme-integrations, but leave the BRSKI clarifications/specifics in this one. > > > > Thoughts? > > Owen > > > > > > > > > > From: Iot-onboarding > On Behalf Of Rifaat Shekh-Yusef > > Sent: 02 August 2019 19:09 > > To: anima@ietf.org ; iot-onboarding@ietf.org > > Subject: [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI > > > > All, > > > > During the last IETF meeting in Montreal we had a side meeting to discuss the > > deployment automation of ACME issued certificates to devices, and the potential > > use of the BRSKI mechanism to help with this. It was clear from the discussion > > that BRSKI can be used to help address this use case, and that further discussion is > > needed to define the needed enhancements to BRSKI. > > > > The current BRSKI mechanism only briefly discusses the Cloud Registrar option in > > section 2.7, which could be used to help address this use case. > > > > Michael Richardson and I had another meeting over lunch yesterday to further > > discuss this and we decided to work on a new draft to describe the issue and > > define a solution. > > > > Because of vacations and other commitments, we will try to publish the first > > version of the draft early October. > > > > Regards, > > Rifaat & Michael From nobody Tue Aug 6 15:31:04 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FB612008B; Tue, 6 Aug 2019 15:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, RCVD_IN_DNSWL_MED=-2.3, 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 pNWPrs_4FeXR; Tue, 6 Aug 2019 15:31:00 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB26412006E; Tue, 6 Aug 2019 15:30:59 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id D7FF854802C; Wed, 7 Aug 2019 00:30:52 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id AEBFF440041; Wed, 7 Aug 2019 00:30:52 +0200 (CEST) Date: Wed, 7 Aug 2019 00:30:52 +0200 From: Toerless Eckert To: "Randy Armstrong (OPC)" Cc: Eliot Lear , "iot-onboarding@ietf.org" , anima@ietf.org Message-ID: <20190806223052.md5lp6yeleuvuf5l@faui48f.informatik.uni-erlangen.de> References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 22:31:03 -0000 On Tue, Aug 06, 2019 at 09:32:45PM +0000, Randy Armstrong (OPC) wrote: > OPC is layered to separate the application from the choice of network protocol. TLS/WebSockets is an option but the primary protocol that will be used by low end devices is UA TCP which provides complete message based security framework. These devices do not need TLS to have security and requiring it would require duplication of code. Sure, need to understand how TCP UA works wih the minimum amount of message authentication to allow for BRSKI. Main challenge may be the need for pledges to receive messages from registrar that are authenticated by the registar, but where the pledge has to wait until it can actually perform the authentication later. Depending on how you built TCP UA message layer authentication this may be piece of cake / free or not. > 2) At some point, the thing decides which part gets an IP address or at least is responsible for the phy. Can that process be leveraged to establish identity? > > Machines may have a separate network for internal Devices which IPs assigned by the machine???s DHCP service. Some of these devices may interact with external equipment via a NAT router which assigns a unique port to each device. This means the individual Devices need to be granted access to the operators network when the machine is installed even though the operator cannot provide them with IPs. > > I need to consult with our machine experts to better explain this use case. Primary questions seem to be whether this is just about authentication at the TCP UA layer or further below at some implied NAC mechanism. > 3) One possible view here is that the MASA may be offline, and may have provided a voucher via offline means to the join registrar. This of course would be nonceless with a lengthy expiry time. In addition, I posited during BRSKI???s review that perhaps the device should be able to generate its own certificate via a higher level interface. > > OPC already has APIs needed to manage Certificates on a Device. The link to something like the MASA is what we are missing. Nonceless vouchers that do not expire should allow local registrar to emulate a MASA when the MASA is no longer available. I wanted to make sure that this mode of operation is allowed BRSKI. Yes it is, it may just not be fully specified in the current targeted BRSKI RFC that we feel everybody who wants to implement it has everything to do so, but thats would just be subjet to future small RFC to close any possible gaps. > 4) Can you say more about what mechanisms OPC is interested in pursuing? > > With OPC we assume that network selection and IP assignment are out of scope. Wired devices are the primary market at this time but 5G could change that. BRSKI also does not care about Addressing. Only ACP does, so you can ignore that part if you're not interested in. We have tried to separate out ACP specific aspects in the BRSKI document as good as possible with the somewhat convoluted process we had in the IETF how to drive those documents. Cheers Toerless > Regards, > > Randy > > From: Eliot Lear > Sent: August 6, 2019 1:47 PM > To: Randy Armstrong (OPC) > Cc: iot-onboarding@ietf.org > Subject: Re: [Iot-onboarding] OPC and BRSKI > > Hi Randy, > > Thanks for this. It???s a great starting point. I would propose that we do a call so we can get some high bandwidth discussion going. Please now see below. > > > On 6 Aug 2019, at 20:58, Randy Armstrong (OPC) > wrote: > > I will start with the main trouble spots. Some of these may be already covered by BRKSI but I missed the implications of some of the text: > > 1) Low end devices that only support OPC; this means no TLS client capabilities and no ability to initiate network communication (i.e. server only mode); > > > How does OPC handle such devices? I think this is also coming up elsewhere. One question is whether TLS is required. Without TLS one does lose confidentiality, but so long as the client can sign the request, maybe that???s all you use. > > > > 2) Machine builders that combine devices into a machine that is sold as a unit. These device still have a unique network identity but the effective manufacturer has changed; How to deal with the DeviceID? > > > At some point, the thing decides which part gets an IP address or at least is responsible for the phy. Can that process be leveraged to establish identity? > > > > > 3) Devices may be reset to factory defaults and sold/transferred to another organization. This needs to be possible even if the MASA is no longer available (i.e. the original manufacturer has gone out of business). > > One possible view here is that the MASA may be offline, and may have provided a voucher via offline means to the join registrar. This of course would be nonceless with a lengthy expiry time. In addition, I posited during BRSKI???s review that perhaps the device should be able to generate its own certificate via a higher level interface. > > > > 4) Offline operation is the norm with pre-issued vouchers delivered out of band. The pre-issued vouchers will need to have reasonably long lifetime (i.e. years not hours). > > The lifecycle of a device is shown in the following diagram. The expectation is we would need to add links to the MASA at each step in the lifetime > > > Thank you for that. For wired it seems to me that a permissive MASA model (logging only) could provide you a way forward. For wireless, this is not an option because proper network selection needs to occur. Another question is whether we need another mechanism is necessary to validate the voucher (aka, a PSK w/ proof of knowledge, or DPP, etc). > > Can you say more about what mechanisms OPC is interested in pursuing? > > Eliot > > -- > Iot-onboarding mailing list > Iot-onboarding@ietf.org > https://www.ietf.org/mailman/listinfo/iot-onboarding -- --- tte@cs.fau.de From nobody Tue Aug 6 16:17:17 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A23B812006E; Tue, 6 Aug 2019 16:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=opcfoundation.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 21rAHo7plIMb; Tue, 6 Aug 2019 16:17:11 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770089.outbound.protection.outlook.com [40.107.77.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 86E8A12008B; Tue, 6 Aug 2019 16:17:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b5xNway+iV3ps/0+4bp3PhXjM+mZzqUmByxuS86hbjqKhw6F8/lbWg+iZhmSFY0gy0do7X4B8OaAeE+mzMaimRhUsi6jiquyz8LY+6noohU8yqUiJfxOlh7j76/bp58P7TwOZiJu8nqoV0Qu3fgmtFB2X2Tq5zxWD+Ym3d6whNLDUv7l4tg2Wj5KR60NyFWSaMuXUQV0HjJwVAi3MVo7F07FJ03TKZjt9d8aeAo1m6AagCwgL5iuP+oBqnkzAlLRY6Tr5P0JubRJb7Ye7Zn5bJuevVBg1itgtkKijjs1xqUmDPIaHTRUkbAU0IM4pAcdZ5DOUmU/aG/W3Nm3c5ycQw== 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=Mw/7yIgwLIb9jcAilWiA1a+8/5nK5q5b1B/8wdxwxAk=; b=mHOMqhsRwYmzdyqAxxZxpN1F8+aTiNkJ87VU6cr0W3CYknuEVTiQUgJx8i5yYwyU0fLjwB0XhsCPUDOBVigDJAotQt7j3iQv419yMgMmnLZKkyZ7WNbZrC6F8JrqHdCuDx5OeBClcggusl2HC+x9fiYCvGm3KW2HZwZsel1mPpjmia+95tYkebXFoewQv/NtiohTqdfNmjavDE2nNmZaRnqXayNLttRYLQAvqT1698WfwIkK9eRsbxB3Hpncp6AoFoc09dUN2k0LUQ/XiRBja11vPO+v43WzUxNrDixr2NWEIpQcsSQOOCblaQvQhqkktdPjcjRxRnrGe+0vLqWAsg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=opcfoundation.org;dmarc=pass action=none header.from=opcfoundation.org;dkim=pass header.d=opcfoundation.org;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opcfoundation.onmicrosoft.com; s=selector1-opcfoundation-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Mw/7yIgwLIb9jcAilWiA1a+8/5nK5q5b1B/8wdxwxAk=; b=f8ohHuSjl+kG5t/8K7P24pZIc0ZPEopIzHcUhACWJvdtfAUrA/5RbM9DFhUL9f13MdzlsGEBj0NBk2rqwIaNQOqtY7CjqpwfMShcGE9LLQEe7EijgZQHEtYY6Wz3AF9X/Pn5vxHrr0WEBoFFxPe/vjINykwPk67CBd7waDvbDPk= Received: from BYAPR08MB4903.namprd08.prod.outlook.com (20.176.255.96) by BYAPR08MB5975.namprd08.prod.outlook.com (20.179.89.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Tue, 6 Aug 2019 23:17:08 +0000 Received: from BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53]) by BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53%4]) with mapi id 15.20.2094.017; Tue, 6 Aug 2019 23:17:08 +0000 From: "Randy Armstrong (OPC)" To: Toerless Eckert CC: Eliot Lear , "iot-onboarding@ietf.org" , "anima@ietf.org" Thread-Topic: [Iot-onboarding] OPC and BRSKI Thread-Index: AdVMZzs5EDHMP+c/QWCVcWuK34MU/QAGrJ8AAADfarAABKcngAAAO+sQAANovwAAARHHUA== Date: Tue, 6 Aug 2019 23:17:08 +0000 Message-ID: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <20190806223052.md5lp6yeleuvuf5l@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20190806223052.md5lp6yeleuvuf5l@faui48f.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=randy.armstrong@opcfoundation.org; x-originating-ip: [24.80.80.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 705e3eef-1cb7-4d63-de5c-08d71ac433ee x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:BYAPR08MB5975; x-ms-traffictypediagnostic: BYAPR08MB5975: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400004)(366004)(376002)(346002)(396003)(136003)(13464003)(199004)(189003)(76116006)(54906003)(7696005)(4326008)(6916009)(68736007)(8936002)(76176011)(25786009)(6506007)(86362001)(966005)(508600001)(53546011)(102836004)(606006)(14444005)(71190400001)(71200400001)(81156014)(9326002)(14454004)(8676002)(256004)(3846002)(99286004)(2906002)(81166006)(6116002)(790700001)(55016002)(99936001)(476003)(6246003)(229853002)(74316002)(446003)(486006)(11346002)(66066001)(66574012)(6436002)(66446008)(53936002)(316002)(64756008)(26005)(6306002)(733005)(66556008)(52536014)(186003)(7736002)(66476007)(54896002)(54556002)(66576008)(33656002)(66946007)(9686003)(5660300002)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR08MB5975; H:BYAPR08MB4903.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: opcfoundation.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hEuPzG30XnmmSzupwVenRRkAAw4ZEQoSg6a3BF/7/7YnUdbD3Gyj/mNiiuVQl9f+Ha9DhrXgODXmMmOhibv/C2YNA8sLD3H3I3kFJ4LBvupWP31eVHcl+fdUZrFt88MZOgZhHCXPXUZHWR6LlSLoTzy98N0hsgfsouiCoDjNWf2OEHFKFIdhrNe8+qAmOAEoDh+jpF6SXwIyo4dNbBWzHhwQqxoohtr9qX9IifHvibMlbv7GtuVHHW6Nm3/Vbog3aND7B/JMw2phQskZOK880TDp46vXnQEGlEGufnYhZYfId/wN55Sil6fHLZvqrrqqeEbpQHeURmhBhe1WbqmRAXhfeLoapG/Q8nu8VFAdPg0PhLpmZiHp7r48TqBiGqo/UJgF3KKnsFKZmd46eOlWVZP8Lg9clYGjnikp7wSNhUE= Content-Type: multipart/related; boundary="_008_BYAPR08MB4903CED7FFDB7D11EFDB49FAFAD50BYAPR08MB4903namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: opcfoundation.org X-MS-Exchange-CrossTenant-Network-Message-Id: 705e3eef-1cb7-4d63-de5c-08d71ac433ee X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2019 23:17:08.1270 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2d8ef4e4-d41c-489c-8004-bb99304b60fe X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: randy.armstrong@opcfoundation.org X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB5975 Archived-At: Subject: Re: [Anima] [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 23:17:16 -0000 --_008_BYAPR08MB4903CED7FFDB7D11EFDB49FAFAD50BYAPR08MB4903namp_ Content-Type: multipart/alternative; boundary="_000_BYAPR08MB4903CED7FFDB7D11EFDB49FAFAD50BYAPR08MB4903namp_" --_000_BYAPR08MB4903CED7FFDB7D11EFDB49FAFAD50BYAPR08MB4903namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi 1) Sure, need to understand how TCP UA works wih the minimum amount of mess= age authentication to allow for BRSKI. Main challenge may be the need for p= ledges to receive messages from registrar that are authenticated by the reg= istar, but where the pledge has to wait until it can actually perform the a= uthentication later. Depending on how you built TCP UA message layer authen= tication this may be piece of cake / free or not. It would be easy to drop in a OPC UA aware registrar and implement all of t= he BRKSI flows back to the MASA. The only nuisance factor is the 'prior-sig= ned-voucher-request'. If MASA's are willing allow this field to be omitted = and to trust the Registrar then nothing more needs to done. If MASA's need = this field then we could get it from the Device via OPC UA but producing th= e CMS message adds an additional burden on low end devices (i.e. the need t= o pull in libraries that provide the same functionality as OPC UA but do it= in different format). The 2 modes of operation with a OPC UA aware registrar (the Certificate Man= ager is an OPC UA defined entity). Pull (device initiated) [cid:image002.png@01D54C72.640B69F0] Push (Registrar initiated) [cid:image004.png@01D54C72.640B69F0] Regards, Randy -----Original Message----- From: Toerless Eckert Sent: August 6, 2019 3:31 PM To: Randy Armstrong (OPC) Cc: Eliot Lear ; iot-onboarding@ietf.org; anima@ietf.org Subject: Re: [Iot-onboarding] OPC and BRSKI On Tue, Aug 06, 2019 at 09:32:45PM +0000, Randy Armstrong (OPC) wrote: > OPC is layered to separate the application from the choice of network pro= tocol. TLS/WebSockets is an option but the primary protocol that will be us= ed by low end devices is UA TCP which provides complete message based secur= ity framework. These devices do not need TLS to have security and requirin= g it would require duplication of code. Sure, need to understand how TCP UA works wih the minimum amount of message= authentication to allow for BRSKI. Main challenge may be the need for pled= ges to receive messages from registrar that are authenticated by the regist= ar, but where the pledge has to wait until it can actually perform the auth= entication later. Depending on how you built TCP UA message layer authentic= ation this may be piece of cake / free or not. > 2) At some point, the thing decides which part gets an IP address or at l= east is responsible for the phy. Can that process be leveraged to establis= h identity? > > Machines may have a separate network for internal Devices which IPs assig= ned by the machine???s DHCP service. Some of these devices may interact wit= h external equipment via a NAT router which assigns a unique port to each d= evice. This means the individual Devices need to be granted access to the o= perators network when the machine is installed even though the operator can= not provide them with IPs. > > I need to consult with our machine experts to better explain this use cas= e. Primary questions seem to be whether this is just about authentication at t= he TCP UA layer or further below at some implied NAC mechanism. > 3) One possible view here is that the MASA may be offline, and may have p= rovided a voucher via offline means to the join registrar. This of course = would be nonceless with a lengthy expiry time. In addition, I posited duri= ng BRSKI???s review that perhaps the device should be able to generate its = own certificate via a higher level interface. > > OPC already has APIs needed to manage Certificates on a Device. The link = to something like the MASA is what we are missing. Nonceless vouchers that = do not expire should allow local registrar to emulate a MASA when the MASA = is no longer available. I wanted to make sure that this mode of operation i= s allowed BRSKI. Yes it is, it may just not be fully specified in the current targeted BRSKI= RFC that we feel everybody who wants to implement it has everything to do = so, but thats would just be subjet to future small RFC to close any possibl= e gaps. > 4) Can you say more about what mechanisms OPC is interested in pursuing? > > With OPC we assume that network selection and IP assignment are out of sc= ope. Wired devices are the primary market at this time but 5G could change = that. BRSKI also does not care about Addressing. Only ACP does, so you can ignore= that part if you're not interested in. We have tried to separate out ACP s= pecific aspects in the BRSKI document as good as possible with the somewhat= convoluted process we had in the IETF how to drive those documents. Cheers Toerless > Regards, > > Randy > > From: Eliot Lear > > Sent: August 6, 2019 1:47 PM > To: Randy Armstrong (OPC) > > Cc: iot-onboarding@ietf.org > Subject: Re: [Iot-onboarding] OPC and BRSKI > > Hi Randy, > > Thanks for this. It???s a great starting point. I would propose that we= do a call so we can get some high bandwidth discussion going. Please now = see below. > > > On 6 Aug 2019, at 20:58, Randy Armstrong (OPC) >> wrote: > > I will start with the main trouble spots. Some of these may be already co= vered by BRKSI but I missed the implications of some of the text: > > 1) Low end devices that only support OPC; this means no TLS client > capabilities and no ability to initiate network communication (i.e. > server only mode); > > > How does OPC handle such devices? I think this is also coming up elsewhe= re. One question is whether TLS is required. Without TLS one does lose co= nfidentiality, but so long as the client can sign the request, maybe that??= ?s all you use. > > > > 2) Machine builders that combine devices into a machine that is sold as a= unit. These device still have a unique network identity but the effective = manufacturer has changed; How to deal with the DeviceID? > > > At some point, the thing decides which part gets an IP address or at leas= t is responsible for the phy. Can that process be leveraged to establish i= dentity? > > > > > 3) Devices may be reset to factory defaults and sold/transferred to anoth= er organization. This needs to be possible even if the MASA is no longer av= ailable (i.e. the original manufacturer has gone out of business). > > One possible view here is that the MASA may be offline, and may have prov= ided a voucher via offline means to the join registrar. This of course wou= ld be nonceless with a lengthy expiry time. In addition, I posited during = BRSKI???s review that perhaps the device should be able to generate its own= certificate via a higher level interface. > > > > 4) Offline operation is the norm with pre-issued vouchers delivered out o= f band. The pre-issued vouchers will need to have reasonably long lifetime = (i.e. years not hours). > > The lifecycle of a device is shown in the following diagram. The > expectation is we would need to add links to the MASA at each step in > the lifetime > > > Thank you for that. For wired it seems to me that a permissive MASA mode= l (logging only) could provide you a way forward. For wireless, this is no= t an option because proper network selection needs to occur. Another quest= ion is whether we need another mechanism is necessary to validate the vouch= er (aka, a PSK w/ proof of knowledge, or DPP, etc). > > Can you say more about what mechanisms OPC is interested in pursuing? > > Eliot > > -- > Iot-onboarding mailing list > Iot-onboarding@ietf.org > https://www.ietf.org/mailman/listinfo/iot-onboarding -- --- tte@cs.fau.de --_000_BYAPR08MB4903CED7FFDB7D11EFDB49FAFAD50BYAPR08MB4903namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

1) Sure, need to understand how TCP UA works wih = the minimum amount of message authentication to allow for BRSKI. Main chall= enge may be the need for pledges to receive messages from registrar that ar= e authenticated by the registar, but where the pledge has to wait until it can actually perform the authenticat= ion later. Depending on how you built TCP UA message layer authentication t= his may be piece of cake / free or not.

 

It would be easy to = drop in a OPC UA aware registrar and implement all of the BRKSI flows back = to the MASA. The only nuisance factor is the 'prior-signed-voucher-request'= . If MASA's are willing allow this field to be omitted and to trust the Registrar then nothing more needs to done. = If MASA's need this field then we could get it from the Device via OPC UA b= ut producing the CMS message adds an additional burden on low end devices (= i.e. the need to pull in libraries that provide the same functionality as OPC UA but do it in different forma= t).

 

The 2 modes of operation with a OPC UA aware regi= strar (the Certificate Manager is an OPC UA defined entity).

 

Pull (device initiated)

 

 

Push (Registrar initiated)

 

 

Regards,

 

Randy

 

-----Original Message----- From: Toerless Eckert <tte@cs.fau.de>
Sent: August 6, 2019 3:31 PM
To: Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org>
Cc: Eliot Lear <lear@cisco.com>; iot-onboarding@ietf.org; anima@ietf.= org
Subject: Re: [Iot-onboarding] OPC and BRSKI

 

On Tue, Aug 06, 2019 at 09:32:45PM +0000, Ran= dy Armstrong (OPC) wrote:

> OPC is layered to separate the application f= rom the choice of network protocol. TLS/WebSockets is an option but the pri= mary protocol that will be used by low end devices is UA TCP which provides= complete message based security framework.  These devices do not need TLS to have security and requiring it would requ= ire duplication of code.

 

Sure, need to understand how TCP UA works wih the= minimum amount of message authentication to allow for BRSKI. Main challeng= e may be the need for pledges to receive messages from registrar that are a= uthenticated by the registar, but where the pledge has to wait until it can actually perform the authenticat= ion later. Depending on how you built TCP UA message layer authentication t= his may be piece of cake / free or not.

 

> 2) At some point, the thing decides which pa= rt gets an IP address or at least is responsible for the phy.  Can tha= t process be leveraged to establish identity?

>

> Machines may have a separate network for int= ernal Devices which IPs assigned by the machine???s DHCP service. Some of t= hese devices may interact with external equipment via a NAT router which as= signs a unique port to each device. This means the individual Devices need to be granted access to the operators ne= twork when the machine is installed even though the operator cannot provide= them with IPs.

>

> I need to consult with our machine experts t= o better explain this use case.

 

Primary questions seem to be whether this is just= about authentication at the TCP UA layer or further below at some implied = NAC mechanism.

 

> 3) One possible view here is that the MASA m= ay be offline, and may have provided a voucher via offline means to the joi= n registrar.  This of course would be nonceless with a lengthy expiry = time.  In addition, I posited during BRSKI???s review that perhaps the device should be able to generate its own certific= ate via a higher level interface.

>

> OPC already has APIs needed to manage Certif= icates on a Device. The link to something like the MASA is what we are miss= ing. Nonceless vouchers that do not expire should allow local registrar to = emulate a MASA when the MASA is no longer available. I wanted to make sure that this mode of operation is allowed BR= SKI.

 

Yes it is, it may just not be fully specified in = the current targeted BRSKI RFC that we feel everybody who wants to implemen= t it has everything to do so, but thats would just be subjet to future smal= l RFC to close any possible gaps.

 

> 4) Can you say more about what mechanisms OP= C is interested in pursuing?

>

> With OPC we assume that network selection an= d IP assignment are out of scope. Wired devices are the primary market at t= his time but 5G could change that.

 

BRSKI also does not care about Addressing. Only A= CP does, so you can ignore that part if you're not interested in. We have t= ried to separate out ACP specific aspects in the BRSKI document as good as = possible with the somewhat convoluted process we had in the IETF how to drive those documents.

 

Cheers

    Toerless

 

> Regards,

>

> Randy

>

> From: Eliot Lear <lear@cisco= .com>

> Sent: August 6, 2019 1:47 PM

> To: Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org>

> Cc: iot-onboarding@iet= f.org

> Subject: Re: [Iot-onboarding] OPC and BRSKI<= o:p>

>

> Hi Randy,

>

> Thanks for this.  It???s a great starti= ng point.  I would propose that we do a call so we can get some high b= andwidth discussion going.  Please now see below.

>

>

> On 6 Aug 2019, at 20:58, Randy Armstrong (OP= C) <randy.armstrong@opcfoundation.org<mailto:randy.armstrong@opcfound= ation.org>> wrote:

>

> I will start with the main trouble spots. So= me of these may be already covered by BRKSI but I missed the implications o= f some of the text:

>

> 1) Low end devices that only support OPC; th= is means no TLS client

> capabilities and no ability to initiate netw= ork communication (i.e.

> server only mode);

>

>

> How does OPC handle such devices?  I th= ink this is also coming up elsewhere.  One question is whether TLS is = required.  Without TLS one does lose confidentiality, but so long as t= he client can sign the request, maybe that???s all you use.

>

>

>

> 2) Machine builders that combine devices int= o a machine that is sold as a unit. These device still have a unique networ= k identity but the effective manufacturer has changed; How to deal with the= DeviceID?

>

>

> At some point, the thing decides which part = gets an IP address or at least is responsible for the phy.  Can that p= rocess be leveraged to establish identity?

>

>

>

>

> 3) Devices may be reset to factory defaults = and sold/transferred to another organization. This needs to be possible eve= n if the MASA is no longer available (i.e. the original manufacturer has go= ne out of business).

>

> One possible view here is that the MASA may = be offline, and may have provided a voucher via offline means to the join r= egistrar.  This of course would be nonceless with a lengthy expiry tim= e.  In addition, I posited during BRSKI???s review that perhaps the device should be able to generate its own certific= ate via a higher level interface.

>

>

>

> 4) Offline operation is the norm with pre-is= sued vouchers delivered out of band. The pre-issued vouchers will need to h= ave reasonably long lifetime (i.e. years not hours).

>

> The lifecycle of a device is shown in the fo= llowing diagram. The

> expectation is we would need to add links to= the MASA at each step in

> the lifetime

>

>

> Thank you for that.  For wired it seems= to me that a permissive MASA model (logging only) could provide you a way = forward.  For wireless, this is not an option because proper network s= election needs to occur.  Another question is whether we need another mechanism is necessary to validate the voucher (aka, a PSK= w/ proof of knowledge, or DPP, etc).

>

> Can you say more about what mechanisms OPC i= s interested in pursuing?

>

> Eliot

>

 

> --

> Iot-onboarding mailing list

> <= span style=3D"color:windowtext;text-decoration:none">Iot-onboarding@ietf.or= g

> https://www.ietf.org/= mailman/listinfo/iot-onboarding

 

 

--

---

tte@cs.fau.de

--_000_BYAPR08MB4903CED7FFDB7D11EFDB49FAFAD50BYAPR08MB4903namp_-- --_008_BYAPR08MB4903CED7FFDB7D11EFDB49FAFAD50BYAPR08MB4903namp_ Content-Type: application/octet-stream; name="image001.emz" Content-Description: image001.emz Content-Disposition: inline; filename="image001.emz"; size=17008; creation-date="Tue, 06 Aug 2019 23:17:07 GMT"; modification-date="Tue, 06 Aug 2019 23:17:07 GMT" Content-ID: Content-Transfer-Encoding: base64 H4sIAAAAAAACC+ydD5RU1Z3nX3e/+tP9qrqruxELQaCbP40dzkJYJAQrTVGQDlHMKlHTujHiv6Ak xn/QCJadBpFIwqj5u5LMUXc8J8zonDGTJURJ2XYIh9GMOzHJxpCzOmYGspzEnQ1xDWeafcH9fF/V 7frX1CtpkLTHd/j2u/fVvb/3/d37ffe9d39VlxrLsj4L4mASuKLWsj5UQyK3fWWhZb001bKmfvji bsuqsV6aXmN9I2RZdaaA2TdY1mMBy7qc+pcU1NfH4Un1Vv/UgIUBazaYCjD3vppkjXfOGPna2OD/ VLVVOajsQ2ALUNm5yVorRtoGltW/uDNpWdNJibfy3q4kPS9p1cinmHc896d/4jKrf9fSaurbScuK 5Kq1sQ+Di0ASzAW46/ki3kIMmO1ztMPNOpjbTL6dvGy+xSYfHwbbgXyckczayPpoWVOSdcPnb0/a w+nJyfrhdFsyNJwu9mkwhdncNpja8Y/R1NGNm1INSavftJs4GIovr/newMtrzl/MvquNWvL1OiCu KqM6Am39IW9XksZdqwPEgbGJea/UDP4aOyaN/f4rOD4XTAOTwWqwBKhd59Yeqplba9u3BQWlD9WY usiv36Qp6vmT46bqua1/OC1uautVELsMqK07k/76qabMTOzEsG0Dbe9EH4aTVm2Cc80Fum7YWQ/o D9uTT3Qm5K+BjpkyJN8KJ2vqlpNQfR1XWxdu0oDyOS0MZNPf8/ZeuZqamk0kzkrWFPmt9s/1wQn1 cQ1lFgJx016b2Us1Me9I+R/T16pn0vAe1k8bxyeBm0EKyKdS7Shv6p6MfmZhUxoWB2lJOlo+prRk WZ+e/cpC8DT0rVf+7YveeCAtrSCfBEYn/4Rf3vY/xnXL30LouPJsS+iCpKlD3tPWbBJTgY7nypHL br9til3opdBQqX5M++rUb0dLKm80ZPZWbQ1qGnkzGtDnHSAOSnmaMjreCky/X0A6DCaCGOjhorfB goL8WvI95OcDs2mc1RbkQI+9wb7MTtuXgIvAcvLL7bW2sbE8Z7OSDcpQ1627BFwG4GH32LatC6+U 374SfvO5OCrZ7rE/GLjMTgQuAReB5eSX2/MDhfxks5KN5fYg/DL4mMHXDNwGwb4R+W2Bj7Gt9nzT l98Q/Fz4ufBz4TYE3iziJ5uV+fVTN42NNLbSgR67H2wJjNR+y+i0Qn67yFey3WM/E8TnIL4HaYPg cvLL7V1BY0P9K5uVbCy3k9RNYCOBrUSwh3yPvSw4Ej+bwczYVvutJV/JNvoL4XMI30O0QQj9gbUh Y0P8ZLOSDcpQ14WfCz8XblYI/YVG4revhN/8cGXb6C+Mz2F8D9MGYfQH5ocL+clmZX6D8MvgYwZf M3AbBPtG5LcFPsa22u9NX35D8HPh58LPhdsQeLOIn2xW5tdP3TQ20thKh3vsfrAlPFL7Lasv5reL fCXb6K8en+vxvZ42qEd/YFe98VH9K5uVbKA/6iawkcBWoh79gWX1I/Gzee43ttV+a8lXso3+GvC5 Ad8baIMG9AfWNhgb4ieblWxQhrou/Fz4uXCzGtBfw0j89pXwm+9Uto3+HHx28N2hDRz0B+Y7hfxk szK/Qfhl8DGDrxm4DYJ9I/LbAh9jW+33pi+/Ifi58HPh58JtCLxZxE82K/Prp24aG2lspZ0eux9s cUZqv2Xc/Ar57SJfyTb6i+BzBN8jtEEE/YFdEWND/SublWygP+omsJHAViKC/sCyyEj87Ggxv7Xk K9lGf1F8juJ7lDaIoj+wNlrITzYr2cAH6rrwc+Hnws2Kor/oSPz2lfCb31jZNvprxOdGfG+kDRrR H5jfWMhPNivzG4RfBh8z+JqB2yDYNyK/LfAxtj39+fIbgp8LPxd+LtyGwJtF/GSzMr9+6qaxkcZW urHH7gdbGkdqv2VNxfx2ka9kG/014XMTvjfRBk3oD+xqMj56+vOxgf6om8BGAluJJvQHljWNxM+O FfNbS74yvw0xfI7he4w2iKE/sDZWyE82K9nAB+q68HPh58LNiqG/2Ej89pXwm99c2Tb6a8bnZnxv pg2a0R+Y31zITzYr8xuEXwYfM/iagdsg2Dcivy3wMbY9/fnyG4KfCz8Xfi7chsCbRfxkszK/fuqm sZHGVrq5x+4HW5pHar9lLcX8dpGvZBv9teBzC7630AYt6A/sajE+evrzsYH+qJvARgJbiRb0B5a1 jMTP5gXF2Fb7rSVfmd+GVnxuxfdW2qAV/YG1rcaG+MlmJRuUoa4LPxd+LtysVvTXavglrOx7yGL2 cbAUdIGPgA/W5N+pSA6/z5McntPh8a6qOZ1ZVOJW4r3rdbM/Ag6BsTq/w0zrEr85ur/6yWpvjs74 rnfU6TnQbOqC3JZPq0wHUF8orY3XUW8/g79qQx036TCGriA/F0wAk8HtYAng1cp6uOZQzcM1PPCH BKXfm5szfRdOWqdtbk59T/NbOQ0MKK15W+297RTMzemaXJgzZ/bVzM0VXstoZFg/0twkcAdIgax+ irUjLRnt6do3aYq/7XGgnUrSs+ZbNCYcAC+CsTMmFMcyks2Xpma3zUvZyaxfuGK1gTBQu2p/EUiC uUDtOxWoP4QYMJuJQZTmC8YPT1/Zz/sXm3PXckBtGst+4P3lFagov5L8bZxQ5/yjGVy8kpaVkQE2 2wq0L0EJN1vXejEnHVP5wu2VHf8nruLxDf8W3/CBB9e/8mDmfZb1dP1gE7pcNccrvv2qOTUvbf3K +gNXhq8+zrmOXDmn5jvTHlz/SSreBA7UPV3/PMdmX55Y9+TDl65PTWt7dQv5mn7L+gH5wvMp/enn fzRuF59/d2+2rFpYdVLTmOPlXDdt+fj6exFynDR3mXjPJ+fU8Apt1Y4XLn5LfP+94Y462Xqs/luN 2qemvSoJvrXibqy9WjN83LKyx//9D0fi98btX8iO6tq/sCyd4974L4br2b+wh+3eQLlw9Kqzb+j1 unx4rFaDQMPrH6pbLbm0jiuvfmOrvYw/t4H5oB1cDuYAcS/dghxYUXLQI8WfHo4vs260eunF69mH yau8oAaQ/pSeAXTuKNfwrFxanHRuHZe9bvZTOTgOlF+fxfEro8XO5KmJ21RjZybnisHRBtpmJIvz o4vPFV/nv/5vS1KzL7vxjFzn5tzSgvomBsx25q7zS885E9f5n84rv86z1+XL3nX+65O4zv90nj2k 61x17SHL0jn+dN6Qd0lpfLCHbO8ztfkNYLTXeRobc8F/AFeCC8BI17mu3RWgcPNI8eeTHJxlXcI4 fSOcVvP3PO864P7sXefmmlfeXPvVXvMLud5nV3HNG11Wc62eqjKn95ovHtMmN6aW+j3vjzYmb/pE /W/S9Pvw89kPOT5ZfUh/LGEfABMih2omRGz7qpig9HvP96avTufz/TsRe6ebT+nz/SD2JoEwhlPs s/op1o60ZLTHeNFv0hR/28/3emYY67H3mS03eNe9tKTxNwlqc9/jOJOxd40R03Oga044l3ANZRaK c27PblhT1cTeVa8DxIH0WLgZbeh4K4gAldc9jHFrOPae4im7MPauvF/sPdW4we5qTNuLwPlgHvl5 jfnY+7yczR7OMx+YzdwTdZ+jDHXdukWgC3BeO9VYHnsXn8LYu/J+sfdU4wcDXY2JwCJwPphHfl5j PvbOuT2blfkNwi+Djxl8zcBtEJTH3sWnMPauvF/sPdU4BD8Xfi78XLgNgXzsXfz8Yu/zGvupm8ZG GlvpQIp8qrE89i4+hbF35f1i76nGZ4L4HMT3IG0QnEd+XmM+9i5+frH3eY1J6iawkcBWIpgin2os j72Lj+LkC9BEDCi/lnylvkF/IXwO4XuINgihP5CPvYufbFayQRnquvBz4efCzQqhv7LYtvjsK+Hn F3tHf2F8DuN7mDYIoz+Qj72Ln2xW5jcIvww+ZvA1A7dBUB57F7/C2LvyfrF39Ac/F34u/Fy4DYF8 7F38/GLv6I+6aWyksZUOoz9QHnsXn8LYu/J+sXf0V4/P9fheTxvUoz+Qj72Ln1/sHf1RN4GNBLYS 9egPlMfexUdx8iL9ka/UN+ivAZ8b8L2BNmhAfyAfexc/v9g7Zajrws+Fnws3qwH9lcW2xa8w9q68 X+wd/Tn47OC7Qxs46A/kY++c27NZycd5jYPwy+BjBl8zcBsE5bF38SmMvSvvF3tHf/Bz4efCz4Xb EMjH3sXPL/aO/qibxkYaW2kH/YHy2Lv4FMbelfeLvaO/CD5H8D1CG0TQH8jH3sXPL/aO/qibwEYC W4kI+gPlsXfxUZy8SH/kK/UN+ovicxTfo7RBFP2BfOxd/Pxi75Shrgs/F34u3Kwo+iuLbYtfYexd eb/YO/prxOdGfG+kDRrRH8jH3jm3Z7OSj+gPfhl8zOBrBm6DoDz2Lj6FsXfl3wSVbKM/+Lnwc+Hn wm0I5GPv4ucXe0d/1E1jI42tdCP6A+Wxd/EpjL0r7xd7R39N+NyE7020QRP6A/nYu/jJZiUf0R91 E9hIYCvRhP5AeexdfBQnL9If+Uq20V8Mn2P4HqMNYugP5GPv4ucXe6cMdV34ufBz4WbF0F9MD8th MBFAw3seKIy9i69f7B39NeNzM7430wbN6A/kY+/i5xd7R3/wy+BjBl8zcBsE5bF38SmMvSv/ZrNf +w3Bz4WfCz8XbkMgH3sXP7/YO/qjbhobaWylm9EfKI+9i09h7F15v9g7+mvB5xZ8b6ENWtAfyMfe xU82K2kE/VE3gY0EthIt6A+Ux97FpzD2rrxf7B39teJzK7630gat6A/kY+/i5xd7pwx1Xfi58HPh ZrWivxPG3v8VLXaB/wVOR+xd72bd4Ag4BMrn8YvnuSnibZ1J/3n8d3IubuG3FvrOxZXG3vWOWs37 cgfl4sC86/I+SS4/H6fj5r2XMWR4bu5pjk8GMQosYR8Am51DNZsd2/5DTFD6vbk503enc27unYi9 61paCLSZvVQT846U/zGaUT2TRiPD+tnNcc3NNaOfFPusfoq1Iy2ZurzanfTcnDi0A83XaL5EY8IB 8CIYO2NC8Vh1184VS/92z0VnJCZnzq12VZvGgNl4zSvKryR/G32ssqOJvcu+bPy5xd5rx5fH5LIx tGNeTO75k4jJ1Y63Vyomp7o2Dahz1I5f6U31eTG5lbb3mdrkBjBSTE5tRTWvf+LsW3JpuqIs9r6F Y/8dzAL/D5wPVL90E6cVJQc9UvxZxfGVROJWE3u/01rLNymu9b5XE+Z4MAfF4JW2czBpc43zijYc j9f524H0pXN0s682Nmf02Zn0v4+fqjIzOVcMjvJN24xkcX508fji2NzgazXL3qnYnPRi+oe+HB6/ Q3SQ7v8r2C9hHwC3TT1Uc9tU2/776YLS793/TV+dzvv/OxGb0/W4EGgz+9Hc/wMYnISti9mn2Gf1 U6wdaclob7T3f40fYz02t3dVg3fdS0sah5Og9s8gNqcxYnoODBGabsht+TTdbJnYnMobDZl9NbE5 1TPvK7JXuBmd6Hil2NyOdsZoBukFlIsB5f1iczvaN9hfb0/bXwbbwTby29rzsbltOZs92JsPzGbu jbrPUYa6bt2XwdcB57V3tJfH5sSnMDanvF9sbkf7BwNfb08Evgy2g23kt7XnY3Oc2zc2t619EH4Z fMzgawZug6A8Nic+hbE55f1iczvah+Dnws+Fnwu3IZCPzYmfX2xuW3s/ddPYSGMrHdhBfkd7eWxO fApjc8r7xeZ2tD8TxOcgvgdpg+A28tva87E58fOLzW1rT1I3gY0EthLBHeR3tJfH5sRHcbQi/ZGv pB30F8LnEL6HaIMQ+gP52Jz4+cXmKENdF34u/Fy4WSH0VxabE7/C2JzyfrE59BfG5zC+h2mDMPoD +dgc5/aNzaE/+GXwMYOvGbgNgvLYnPgUxuaU94vNoT/4ufBz4efCbQjkY3Pi5xebQ3/UTWMjja10 GP2B8tic+BTG5pT3i82hv3p8rsf3etqgHv2BfGxO/Pxic+iPuglsJLCVqEd/oDw2Jz6FsTnl1/LS 5qO/BnxuwPcG2qAB/YF8bE78/GJzlKGuCz8Xfi7crAb0VxabE5/C2JzyfrE59Ofgs4PvDm3goD+Q j81xbt/YHPqDXwYfM/iagdsgKI/NiU9hbE55v9gc+oOfCz8Xfi7chkA+Nid+frE59EfdNDbS2Eo7 6A+Ux+bEpzA2p7xfbA79RfA5gu8R2iCC/kA+Nid+frE59EfdBDYS2EpE0B8oj82JT2FsTvm1vPj5 6C+Kz1F8j9IGUfQH8rE58fOLzVGGui78XPi5cLOi6K8sNic+hbE55f1ic+ivEZ8b8b2RNmhEfyAf m+PcvrE59Ae/DD5m8DUDt0FQHpsTn8LYnPJ+sTn0Bz8Xfi78XLgNgXxsTvz8YnPoj7ppbKSxlW5E f6A8Nic+hbE55f1ic+ivCZ+b8L2JNmhCfyAfmxM/v9gc+qNuAhsJbCWa0B8oj82JT2FsTvm1MV/9 xfA5hu8x2iCG/kA+Nid+sllJw5Shrgs/F34u3KwY+iuLzYmP4miFzwd+sTn014zPzfjeTBs0oz+Q j82Jn2xW5jcIvww+ZvA1A7dBUB6bE7/C2JzyfrE59Ac/F34u/Fy4DYF8bE78/GJz6I+6aWyksZVu Rn+gPDYnPoWxOeX9YnPorwWfW/C9hTZoQX8gH5sTP7/YHPqjbgIbCWwlWtAfKI/NiU9hbE55v9jc jvYNrfjciu+ttEEr+gP52Jz4+cXmKENdF34u/Fy4Wa3o74SxuY7abGzufexPR2xO73Ld4Ag4BMbO PHzxXFwk+Nbbjs3RpFW9L5e+6/I+Sc38fJzsmPfecMHc3J9oXM3Nab3DJew1t/KrKYdqfjXFtpfP EJR+b27O9N3pnJt7J2JzupYWAm1mX83cnOoZ/aCR4bldlw80N6f1NlPss/op1o60ZOry+nrSsTlx aAeF8/wHyL8Ixs6YUBybG7wzuOxMxebMuek6r01j7M3Ga96IsTn1wbsxNnfi38V+fDS/i31FcTDv d7GvmN/FvuJN9XmxuVdO7e9ib+Bc59CZs9gvZH8+e/Vt6caU5gljc5fx2cXcCT4OxD0MuGY9mGu4 MPY20jX5WQ6uAuXXZPH90OivM/luib3RUNbgXpBS6ovLvpG6+9lLlvqtVWpZjy1Wee2fP/iHZ5Uy e6Wt3HoI45I1/TGy6j+JqI29+uc6oDFRfTE9B4bZE86tm36UNsz8t+qa49gcHt9FrAdcBH4KAuBJ 1oh6knUG/1gnKG1HTV2N7yPZpFp/Abcl5HNb/3BafPScF4dMBJTrp3jsNBaq0c/MZHGMdUZJfnQx VzEZqd+tk15Do3Rd0YK2O2G/VoyZVPH9G5p8WAP087AGdMIrwMXgZ6AaDRg9ULyqfp9FQaNhaWAZ ZBTDHzsaKB7bdO3/cNW+1GifF2fTFlNBbck6tDO/+sKzX/3D9xdrr/Hhz0Evn4CndPpRIL38ElwF dF1rvLgwuiVgdKFxwqT5+KQ0MvbGiRNppLYuQSPMBepnm722b75v9+Jn7j934Pr/vM/rZ+V3nzf3 WXOcft80Llk7fE+gylvmOlKbVzNmdFAuDlS+cDN9o+Mjjefh3Pggff4crAT/DD4FxP/86JzAa/T3 +dFfgTlF/T6SPapUpQGNDUfAITBWx4bDq3+T+kjtN1MNyazPan/dzzX+Wg986UPW317/of4ftyy2 7g93zeKQxsWT7U/MyurwuC47pm9NH87l2F3gUvAdoPtIAGwPTQ5sD70e+FODoPTkon40dihaVd+1 U1C+yFf14wHwIhg7/Vj8/PGBe95Irf+X75+R71Wac6s/1aYxYLa38+72kCc6XbOB9qXeekY38zyp tY1YCezqOTUH/nr2LSoivPSNN+J/DaxPzakJvn/2LbH/8kZ8Pml0ZHnHrcif2Vonr45mrRPv/cdb 6wT/st/T9KTrrYXEUuWndK2T+znHBrASPAU0jqpvSzf17YqSg7qetK3i+C2savQx3t6msubJHdat 9OWNnh9BPuOe613Xsqu8xmld50prb67nKNfzLPLSlfq9PZfWOXTd/iUHpZvy67b4/mY02pl8d7zf 6f8dwH1vU/onn/7U0h+uetN7xlOfJIHu3ypw8usf1NXNpv5UUPrMZz3/1D+cd8GTL2iffear8657 9aM202fq3zYQBtcB04/TSQt0r+87hGwYZ82+mu9dqZ55pkAiRZvRl46bZwCVvwCI60QQA68hwAhi XZDL35rL95CfD8wmPWqTftdEI6HV0XpgAyu0JuoGbwXGhmy6FKxk4yDlD1P3MDYOY+sgNl8DaqxC flNK+D1FA4tvJdtPRCKhnZF6YAMr9ETEDT4FDD/Z9OM3DX4d8OuAXwf8psFtygj8rsnxMbZ/7/jz +50TCR126gG+O1bod44b/D0wNmTTj9/1+LMa31bj42p8vR6frwGl7fdojo+xPacKfp3w64BfB/w6 4NcJtzkF/GTTj9/jlN9J3Z3Y2Imtx7H5KCjl9xqDbJH+cvlK/bumAf01oL8GfG9Afw3oDxgfZdOP 30HKH6buYWwcxtZBbL4GSvlNKeH3FBN1vvqrR3/16K8e3+vRXz36A4afbPrxmwa/Dvh1wK8DftPg NmUEftfk+Bjbv+fi8eP3uzD6C6O/ML6H0V8Y/QFjQzb9+F2PP6vxbTU+rsbX6/H5GlDafo/m+Bjb c6rg1wm/Dvh1wK8Dfp1wm1PATzb9+D1O+Z3U3YmNndh6HJuPglJ+rzGWFOkvl+9hHDrh+BdCfyH0 F8L3EPoLoT9gfJRNP34HKX+YuoexcRhbB7H5GijlN6WE31NB//59Ioj+gugviO9B9BdEf8Dwk00/ ftPg1wG/Dvh1wG8a3KaMwO+aHB9j+/c83PjqL4D+AugvgO8B9BdAf8DYkE0/ftfjz2p8W42Pq/H1 eny+BpS236M5Psb2nCr4dcKvA34d8OuAXyfc5hTwk00/fo9Tfid1d2JjJ7Yex+ajoJTfa3ax/p7M 5Svp79t2JPS4jU3bBlbo2/x/Kk8C46Ns+vE7SPnD1D2MjcPYOojN14Dhl8jdhxezj4OPgs+BX4M7 gHmm0PPFDMAtS1u/SSOxqt5TZ1FJdfVs0g1WYDAJyp93i98HKeptnUn/592ZlIlRmmbxthnJ4vzo 5qOLn8MLn1PVhnOBeU59gLQ2//9vra5uPuXUNqpbp0pszEU9l5ujek5zkcprjmqk59PplBdO+vmT t5GYV7/8j+lj9ZlJBzjRJ8iLs7RyM1D+LiD+lweeQqN26PLAlSFTRxoxaYqclF6OUPEQGKt6+buB A8xP/bji/NTgX8wvmp/SNVdN/3ZQLg5UXhuP797etLmOm3SY9r+C/Fyg61v9932wHgRAR+gR7gef CV3nCEo/EjR1T6Yf27Gp617vFLruD4AXwdjpx+Lx6PjPf8P81OEzMj9lzq3rUW0aA2bjUbMov5L8 bXS8ypZ+t+ChnFCqmZ/qf/CNeA8w81ODpM38lHcc+2diLd7a8Wi+ZM3t7HxSzWh+93tlPf54v/u9 krbjHLXjr5R0s/NTV57a3/1+jXPdCdaA3aAXqL9KN/X1ipKDHin+3MDx/PzUEu7dn2OGap23/rZ8 CQKu26I5Kh0TdL1rb+f25jqPMkbM4pjOKz7tubTO2U16O/rpB+XXcPE90ui1M+l/7z5VZWZyrhgc 5ZO2Gcni/Kl8BlA88tq5LXwX4eRj0voew2x4TgV6Bijsf794ZBt1wuA6oL6iS6q6XygWsRDoXNpr M3tZiXlHyv8YfaieSaMh73lgOsc+CraCX4IvApUjRhkmRhk25U/mHjILO0aL0t+7IUaZ1Y09ihil 3R+jLXI6H45RVquBDrUjUPnCzfSTjo/07B+mv6/gM2n252Az+GegZ15xIS4ZJkYZJkYJ5hT1+0j2 qFLV86D6/Qg4BMrHneJ7NEW8rTPpP+7MpEyM0rl2PK3jxeFvf5dnwGMVnwGTzX/xjj4DaizYBH4M HgRcz9bRwOTw0cDr4a9GBKUnF/Wj0QhFq+q7dgrq+jX3jwOkXwRjpx+L9fWBzHOpHxxxltrJrF+4 MhwbmESaa+S0/b8r5twaW9WmMWC2BhIxk2G/EtzGhayyo3kGvOubb8QvAeYZ8GnS5hnQO25NajoT z4An/n7pVaP5fulBPTd53y89aL5felDSzT4DHvT/fqnaezxQ/8RBSy6tMVV5HWfz/t+Vl0isApvB C0DjqOqXbrK3ouSgR4o/d3G88H9jmGpdkXsGvIlI5R3WVG9lmNt5KrzRWxsmSHmdQ9e60toLdQV5 HdeYaD5XWnWUN8fMXp8JZlzwe378LA2xCpRf/8XPj0brnUn/cfxUlZnJuWL4In+0ndrnR1nMf6cx /ezNS7PfZQ3ULeeTBNAzoPqieHtscTZf4busdXV145KB/hgFxV3aaGMfBtcBaY4mr+r50PSjyo90 z8am9wwwl89fBT3gd+CnQNy/xpqrX2Pdbn1X6bWo0u99l3Xkfj/594azkoEinU6n3QW6RlO7uS2f 1rV7qp/7r8DmXPAKUPp18DNQjQaMxihe1TPELApKw/KjG0xHnHoPKB9Diu/VFPW2zqT/GDKTMjFK 6/rRdjqv/Yf/0Vl297MLeXf0u/b7u7Js+rvM99fN3juu77GPcO1XowfTB9Vc59No+Mc44Rz2z7BX H7/O799fZw2BBR6U3uIYm3rPG2nsoFpV/a0+HnvveZAuGN/zffzuuM7b6PtH8PD97Pewr0YDRg8U r6rfS6/zsf6ddd3jr53bOco5okDFOaJD778omf/O+pm/L3yCztb4cxhIL5PQy1+xZ6dng4b/2mY3 GF1onDBpPj4pjYy9caL4OTevkeCI80GHP3ZhUvHAFz99qdfPyiseaI4TF+Q768HhZz/a8YzMB8Xp 4G9y8unsv81e99HtbU/V6/6wve1K8FS96etTcX84gv1DYOw8AxT3+42px5dOqzlraUMyq/s4vui5 Xfdj8531qf93xzs6H6S4/A5O/0P2O9kHwAvjHql/YdxnGmomCUo/UtSPpk8pWtX1205BPcvJV93n D4AXwdjpx+JnzGe+8O2lPzgy7YzMB5lza2xVm8aA2U7XfNDyB96ITwVmPuh+0mY+yDtufe7P7Dvr h0bznfWQ5oO876wzaGVjjCFJNzsfFPL/zrr6ZjxQ/+gab8mldZ0rr+Ns3nyQxrOL+UDj6HPsNY6q fuk2gQMrSg56pPjTz/HytYD9ZoUeWxKknq53QXNBGr/NXseUFxeVM9AxU6/wc5U3x7U3tmaQlr9+ c0R/ie8PgfIxoXgMNfrvTPq/352qMjM5Vwwf5JO2Gcni/GhijKXfh//ffwwvu//lJd7zo/qbU3lz ROxG8X14+4TPk5uSf/MPS7+14Mf9/2l37vvwdpGvsziv+o+uGZ7zvq7g2HTSglXFPIRsLPTK5vfV fB9e9TpAHJReG0ZfOm7eP5W+AITBRBADC9p5NnHy34ff35bN9/DZfGA2c01Jw3vbtjsDbfeDLaDf 2duWdvaDBXwWA7KZxmYlG4tYO66LteO6eFfuat/mLGrf7iwAmrQp5Neb42NsB6vgVwu/41PvB1vA 551auAUL+MmmH7+NlO9r+zzYAu53NmKzF5Ty2z3Vsr5U0H7duXwl31NTv+R0wa9r6r3g805q6t1O NzA+yubdPu23h/ID1B3AxgC29mBzNyjld3RKMb+tuXwlfpunfMnpm/IFcC/oczZPudvZCgw/2fTj d4zyx6d8HtwLvuAcw+ZRUMpvQQm//ZOJmfv4vnfyF52ByV8Am0Gfs3fyRmc/MPxk04/fIvh14VsX /LrgtwhuC0bg15vjY2wHq+BXC7/j524Fm8E9Ti3cggX8ZHOjj48bKd+Hb3342IevG7HZC0rbb/e5 2fYy/LrJb/OxnTp3m9MFv65zN4F7nNS5G5xuYGzIph+/PedudAaoO4CPA9jac+4Xnd2glN/RSVk+ xvbWXL6i/iZtc/om3Qc2gXuczZM2OFuBsSGbG3x8PEb549Q9jo3jk7Y6x7B5FJTyW1DCb/9E//bb O3GbMzDxPrAJpJ29Ezc4+4HhJ5t+/BbBr2sSYyD8uvB1EdwWjMCvFz7346uxHczlK7Vf7UTGvnPu A/0g7dROvMsJAmNDNu/CZiUbGynfh299E/vBfc5GbPaC0vbbfU4xv+5cvpLt1DmMfecw7sOv65y7 ndQ5dzndwPCTTT9+eyg/gG8D2BjA1h5s7gal/I7ygFjYflvJf8HH980TGPsmMO5PYPyfcLezecJ6 Zysw/GTTj9+xCXc5x6l7fAJ9gK1jE+53joJSfgtyfIzt/XF/fnvjjH1xxv044398o7M3vt7ZD4wN 2Vzv4+Mi/OmCXxc+dsFvET4vAKX8enN8jO0g+a0+tmvjjH1nM+6f3Qc2OrXxXicIjA3Z9OO3EX/6 8K0PH/vwdSM+94JSfrvPzvIxtrtz+R6eI070/JI6m7Hv7M2A8R9+qbN7nW5gbMhmr4+Peyg/QN0B bAzg6x5s7gal/I6OL+a3NZevxG/z+K1O33jG/fGM/+M3OJvH9zpbgeEnm378jlH+OHWPY+M4to5h 8ygo5bcAW/fhq7G9/6xsvhK/vWcx9p3FuH8W4/9ZG5y9Z61z9gNjQzbX+bTfovHrnC74dY2/B2x2 Fo2/z1kASvn15vgY28Eq+NXC7/g4xv1xjP/j7nJq4RYs4Cebfvw2Ur4P3/rwse+sTc5GbPaCUn67 xxW3Xzd5vzWUU+MY++DXNY7xH36pcWudbmB8lE0/fnvGrXMGqDuAjwPY2jPuPmc3KOV3lIf/wnWi t+bylfp3cytjXyvjfivjf+t6Z3PrWmcrMPxkc61P/x6j/PFWxkBsHG/d5BzD5lFQym9BCb/9LXzX xMf23hbGvhbG/RaegVvWO3tb7nT2A8NPNv34LYJfF751wa8LXxfBbcEI/HpzfIztYBX8auF3vJln 32bG/+b1Ti3cggX8ZPNOHx83Ur4P3/rwsQ9fN2KzF5S23+7mbHsZft25fKX+TTXzzAu/Lvh1Nfc6 qeY7nW5gbMimH789lB+g7gA2BrC1B5u7QSm/ozH9f3z58WVrLl+J3+YYY1+McT/G+B/rdTbH7nC2 AsNPNu/wab9jlD9O3ePYOI6tY9g8Ckr5LSjht78py7cSv71NjH1NjPtNjP9N65y9TXc4+4HhJ5t+ /BbBrwt+XfDrivU5i+C2YAR+vTk+xnaQ/CYf32ubGPsaGfcbGf8b1zm1Tbc7QWBsyKYfv43404dv ffjYh68b8bkXlLbf7sYsH2P7a7l8pfZ7qHGTs73xHrABrHMearzd+RowNmTzdh8f91B+gLoD2BjA 1z3Y3A0Mv4SVnUdYzD4ODoPdYEZtNmbLEDE8fzMjl2Y3HIMLkZ7OAYHkEm9XksaU9/uvCPsa0A0U N0iC8vm64rlyinpbZ9J/vm4mZWKUtoG2Gcni/Gjm2azceoKeYdKF82xqw7lA38XS5w/oD5v/7/ns EX/P9y8rLhycHmxT/G7w9aafPnvkkgsH/25KV+73fMXzawVtry7NbSN/j0dtvzBXwuzVI7HcsdKd 6W/VM+kAnfwJ8rOAtPIdcBQ8B+rA4qbpaJTnlaafFH23w9SnyEnp5QgVD4Gxqpc/Nu1eeuHO2SPH 7m7YlV1vavHerndyvam1dOzf06Y72Kv/6FsrdXac5/zfONsmCErHR9WP7djUda95UV33B8CLYOz0 Y/F4dPGFe5b+6zcuOCOxO3Nujadq0xgwWwOJmMmwXwluo1/5N6rvcvvH7pgH53d1L239yvoDV4av Pk4/H7lyTs13pj24/pMQvQkcqHu6/nmOzb48se7Jhy9dn5rW9uoW8jX9lvUD8lAs2j79/I/G7eLz 7+7NllXkQHVS0yxrOee6acvH19eO53414u/5wqP5Pd+qeph4v+dbxXjOOWrHr/Km9L21glf5/55P 7U01r3/i7FtyaR1XXv3G5sXu7iKxjg++y17X4IA+AKVbiAMrSg56pPjzSY4Xf3v72t8GOSboejZQ XuPzDCAOUcbhWbm0uLXn0rLbTbraeJrRZGfS//58qsqczvt8aTxNv9u/du5Vpzie9t76UloLKgIW oLUYuDWX7yE9H5jN6Fz6ZX2pKOtLARtYUdaXirC+VMTYkE0XcVeywfpSEdaXirK+FKiPsr5UlPWl yv5fIa0FVcjPW1+KY5Vss75UlPWlgA2sKOtLRVhfapifbPrxY32pCOtLRVlfCtRHWV8qyvpSZfy8 9aWwZ3z31pfy4cf6UlHWlwL47lhR1peKsL7UMD9vfSmf9mN9qQjrS0VZXwrUR1lfKsr6UmX8vPWl Cvh560v58GN9qSjrSwF8hx/rS0VYX2qYn7e+lA8/1peK7KQu60uB+ijrS0VZX6qMn7e+VAG/W7mB qr8r9S/rS0VZXwrgewP6a0B/wPSBbPr1L+tLRVhfKsr6UgD9YZP1pcr4aS2oIv1xY/Lj90Q9+qtH f/X4Xo/+6tEfMPxk048f60tFWF8qyvpSAP3BjfWlyvh560sVtJ+3vpRP+7G+VJT1pQC+h9FfGP0B w89bX8qnf1lfKsL6UlHWlwLoD59ZX6qMn7e+VAE/b30pH36sLxVlfSmA7/BjfakI60sN8/PWl/Lh x/pSEdaXirK+FEB/2GR9qTJ+3vpSBfxu5Sbv179rQugvhP5C+B5CfyH0B0z7yaZf/7K+VOQwdVlf CqA/bLK+VBk/rQVVpL+gPz/Wl4qyvhTA9yD6C6I/YPjJph8/1peKdMCP9aUA+oMb60uV8fPWlypo v9/zoOPXfr8LoL8A+gvgewD9BdAfMPy89aV8+pf1pSKsLxVlfSmA/vCZ9aXK+GktqML2m1MFP9aX irK+FMB3+LG+VIT1pYb5yaZf+7G+VIT1paKsLwXQHzZZX6qMn7e+VEH7eetL+VwfrC8VZX0pYAMr yvpSEdaXGubnrS/l036sLxU5TF3WlwLoD5usLzXML8F9PgzMfNRHSf8T+DX4GTjV81F63u4GY30+ qvA5VW04F7z9+aixv77UC/j9CXAA6H2H9aXQqB1lfami/x9jBp8hVW1vaz7K6OUIFcfyfNRz//HN 1LSaD7+t+Si9J07PgWb7EMnclk+rfTpAHKi8Np7hvb1pcx03aa71/ivIzwWbgfpvJ/glYLiz2sKP RNrCn4ne1CAo/UjE1A1R16QpWlU/tlNQ/W7ec6WTF8FYnY968IFavkv+8TMyH2XOrT5Xm8aA2XjU LMqvJK/5KJUdzdoC/utLZeeieq7Kz0W1bHxw/fL1t5/jBRw4/2XkzXyUZX3MyJRP2JL5bI01zlK9 auajTry2wLUnXFvg6W2Z92kOq27Dg+t16uz+Fo+n5tF0TGzEYflLX+0UbqP8GzfvWSfeX2f/5IZX w+L89K4djpW0rBt6vdvn8PWl9h4P1D+6JltyadlVXsfZhuej7iXzY6Br8GV9AEo3rru3MR+V/+63 rmeDIOkTzUfpnO1A3Mx1uhDCs0H5dVr8/W6jyc7ku2M+qjTu9JHrv+v7/1e+vOb8xS+v+V5XG+0X BtcBtaX6vJrx24ypKm/S2Bkep2/gg8l89jfsl7BXn354/KGaD4+37fvOEZQ+VGPqnsw43Y3NVdi/ DJT3efGcPEW9rZo+n5nMjkt2rs6MkvypjBGavgonT/73vH7/b5n6Wq7k+lxTyKS/5+2V5rd+NZvY jeb/JtL1uFC22Mxeaop5R8r/mH5XPZNGI8P6uY4+ncRnT7BPsecz9FOsHeVN3ZPRzyxsSvPiIC1J R8vB2NGSZWkuGjwNfevCG3/kXffS0grySWCe70/+/zk48VpymLd+2xS7UHtpqFQ/pn1p0qrGlGso J+2ovPbazP6d+g3HLXG+G8CFv4Bzx4Dya8n3kJ4PzKZ7jjbdo26Jb7DXxNP2jeBacDX5q+NrbWPj 6pzNSjYoQ1237kawBnBe+5a4besBOgwmghgQn30l/OZzcVSyfUv8g4E18UTgRnAtuJr81fH5gf/f 3vnHtnHeZ5yWSYkSJfLIk0QGSoLYsGPP8xZ7EFK3lRM6EtwGcgst3Oyuntc6jZN4sQ0XEZqlEFYF kYEMWlNtBKJs3h9tUWDp1nXAIKzOpjXKIAzBFGxCWMAG3G4Z7C0YvA5qbDRVx2H7PKd7Jd7pdMdY clQZPeHR+4Pv+9zzfd/ve3z53stjrT5xhnEcK0yhbxIbJ7F1Em1TYDpQ3wh6DLf03ojUN4++Kvqq 6KuibR7c8OgTZ7i+YeoOwTEE11DidGEYjCSC2q+PTqvVN0E6jPt04dVGbG7E9kbaoPEY6WOFicVn ZtN3MXGGcRwrFKnbA0cPXD2Np0mfLvQ1BumLczGr1TdIOowb/2vC5iZsb6INmvA/MNhkOKRPnGEc lKFuFX1V9FXRFmvC/5qC9E379HUnw7nxvyQ2J7E9SRsk8T/QnazVJ85wfVPom8TGSWydRNsUmA7U N4Iew40dsRuR+ubRV0VfFX1VtM2DGx594vwU42+la8CxwjB1h+AYgmsoif+BkWRQ+/WxTl+rb4J0 GDf+14zNzdjeTBs0439gotlwqH/FGcaB/1G3B44euHqa8T/Q1xykL97i1TdIOowb/2vB5hZsb6EN WvA/MNhSq0+cYRzYQN0q+qroq6It1oL/tQTpm/bp647Y34b/pbA5he0p2iCF/4HuxT1yaj9xhuub Qt8kNk5i6yTapsB0oL7aPcLYEbsRqW8efVX0VdFXRds8uOHRJ85wfcPUHYJjCK6hFP4Hlu8Rlp4+ Jj2mb5SeIB3Gjf+1YnMrtrfSBq34H5hYXNNV+4kzjAP/o24PHD1w9bTif6CvNah/421efYOkw7jx vzZsbsP2NtqgDf8Dg23GRukTZxgHZahbRV8VfVW0xdrwv8U1Z8/7r09fdzqcG/9LY3Ma29O0QRr/ A93pWn3Tkfqm0DeJjZPYOom2KTAdqG8EPYYbO2I3IvXNo6+Kvir6qmibBzc8+sQZ3n7D1B2CYwiu oTT+B0bS+7lmJkFt+/VlvPomSIdx438ZbM5ge4Y2yOB/YCJjbFT/ijOMA/+jbg8cPXD1ZPA/0JcJ 0he3vPoGSYdx438WNlvYbtEGFv4HBq1afeIM48AG6lbRV0VfFW0xC/+zgvRN+/R1Z8O58b8sNmex PUsbZPE/0J2t1SfOcH1T6JvExklsnUTbFJgO1DeCHsPt+F+kvnn0VdFXRV8VbfPghkefOMP1DVN3 CI4huIay+B8YyQa1X1/Oq2+CdBg3/pfD5hy252iDHP4HJnLGRsf/IjjwP+r2wNEDV08O/wN9uSB9 cW5gGW613yDpcH3P2thsY7tNG9j4Hxi0DYf0iTOMgzLUraKvir4q2mI2/mcbfT0x7z23kU2x2APk vUD4YQD94vrRdjdOsLj2zvSurrX3nTU8B4nPgatg43wm9641fu+bfxG5Fvf1f37CWYsztjdg7zYX NJu6wD2W4iqzA9C1i+uvfBx1ypn2VxkTT9asrXya/rqb1/6K8AAhH61i3+64uunbHfH4XV2C4j9f mzN9l2Q9Rf6/B5j1lBeJ64jev78p9Dms6nvxuD7wXcXXem2Obl5cR9mnEzhH9Nqc6hn/wUcW1+Z+ gxfu5LUJwocIF/zH6zvyJVNXY9/EKf6+rwNbqcT0cnGd/xLxN8HGuSZ416L/5NN/3bt7y688FC8u 2IUpi889UbsyVmP9oAj2ALXvPUD9IVjAHGcY5CeV6R4mXXP9cPxr4eXhB825qea0qeXWU8BHIA/3 I6TPwi16//24SRFwxGOJrQd4HvRJ5zeJF/Jq5Cxk8F/FC8/+sPDsh77yzPe/MvmLsdiF5inmbPs+ e59TfD32h+u5S/794bpH93zh2mqe7ZTmo/jCs53S5tlOaWet0Nkfno6v6e8Rj3Eu/fDzVsKvEt5H 6HYNsaUjRfTQUtKJOaL49xipXuep3oP04+Pgc/TmIDnDD8oXG0EcbHZh4soXlK/QjPE2xvhO0hqz 6lxpU1znO0h4D5ntYPn49b53Gl/dVbxd7tN5rwPV0xd6d//aiXW5Dphzy1fUNxYwx/pdB9bnmf8N ncuvAwvPZMus5nsiJ3QdcL4ncoIxyTkaOk84Q865DpxY+++JfJ4x9cucU9/L+Chh0HWA9+IVrwO/ yWufYOSfAU8414PY4m+Sa3wLqq9Q14B6x/sp9Hy2jvFufPL2Ge80Us2zm//p8ZceSr08zvdEwueE vPO779nFB81zuU0oRnO/tr24adgiqb6QY20h1PX6UWCuvduIC1ySV/wcYfpR/hL0OQ7OxbmfhP0H 0PxE79wJwm/Fr+W+FX8q/ePNguLXcoZTc78gTqrVNQ88SMGN9yxeRAf2+81/jvDfW62nXz+Din2A blrT+b8c6d/BJ8DeOn3A+ANV6ur3nRQ0Piwf2MZ55AfL5wze91SKOseuYvSc4V7KWJSOAx3bi970 6vZ5iHHpdzle6P2H3ls59uvxB9MH9YzzYdpa4/zLhGacv164lnu98FQ65UDxn4/z4D6+Pcb5l+h7 jfMXCc04j/IB42NUu6lx3se59oGNM869n1n0Hv8/Xz+7ymfzr7znRs/kf+3pj9c8m39hHcdcw+q5 Dqz1+8IROlvnfRjIX56l//6TUNcZzQueyT+VNn6h+YCJ8/JN+cjGmw+s5CObA5/N//djH3Oezf+n r3zS6Wel9Wx+k8/877n24ubFuR/tuPhsfrV5PT6wg3IFoPK1h+mbqPeI3VT6Av38b4TPEf6QUD54 PN/pvD8cz7+eVtzwqd9XOw+cg/8q2KjXhre6u3u/+/TR4O9TvDjqPN9j6jusB7+QfMDMf262P/k4 QEstfUYTj+mLJH1xmPQe8DfgbZCjD/+bMAG+kUqkv5F6K21nBcUTnn40PBSta/xupaDmcvqMornc JfAm2Dj96J1jfvG1j/Qe/txvr8v3Kcy51Z9qUwuY4/2s24zR3zq0ftvrrN2e5HOj1nFjsdlj9226 9MpuLSs6nx1mX3q38Aowz+a3xpeeze/kxwbW5dn8K3+f4vEVv08hH9T6y5YfbIp9tfk8K7Q6fqDs //vJj+YKzxfic1q3cX6rcc78VuOc87qzbjMX/VuNardOoP7RNTbnxpWvtPI5nO9TTBP5W/A2yFLg vwjVt/6jnYxDvkxHFP8Gya99Nv/C7zMeiJ3l79Tiau5Jfr/xTKyRshrjgtZt426ofKUFxU05paWn to7ylFaZ7UD2tHEt2OnGZedWNy6NB4n/Ppn6TLF8zHvfG41/7ypGf35bqzL3ci4LjWoLHduL3vTq Pgd67dP88Hd/dWSV88OGzbvReQ9oCPh9b+/8sMFj2xbqJMGjQP1Gl9Q1X7iVc8b/RYPmjJuAfI31 o8wz+WsZ41uaO5g4L9f1nlPri/K/22HOuOA3m1YxZ1xaL6RJ1m3OOM/JNWdMAI254/mXMqnCtczx /AFLcdPX6neb142fmnyy6vIB9fscuAqWX3e87+kUcY56rikf5PXiC5s1Z3w6dM4Ye+3JD3zO+BNa S3PGRvUj8a+lzmW+lnrE6swKip/z9OP77Tv/+8clzvEm2Dj96PWvu1/8SO+f731uXeaM5ty6tmos WcAct2rOuLPMfFH4rfs2Ne7dffpJ4ub3nJz82Bt3/Gzd8//Rau75d2jO6PyeU4e559/hTM+cOWPH 2t7zn+JcmjNqDGrOGAfqW/+ha+chX6Yjin+D5Je4x3+cOf8gsZPc8TvD/zOEmksu/bL3wvjWnE/z PYW6ZmvM65wKla+4QpP2h6qjutuBfDBqvqh7mGNg+Xj3zqeMb9dz3V6rMrfy+u9/ttyel6d6X/6X P1zjZ8s1rTh/jL3xlx/78f3d/6hQ9xk7ik2e+eNOt//U31tAEjzq5tFd72suKY59QIcJ6/men+rt AAWgc9Yexr+UL/+Xr6n8R4G0dgELpKh8Pbe0z/Z8fiH9KV7rBuYw40W+PZ6/nivn58A18E5uPH8l dx7cz2sWEOcVOMM4rMKVnF14B1wDczmrcD2XAvupnwRGX7+rx3Bf7ozWd7Hzeq7SOQeugXdyFzuv 5C4DwyHOKH0D2FPCthI2lrB1AJv7gV/fqKvHcHfVoS+PPht9Nvps9OXR1lWjT5xR+sYoX6ZuGY4y XGNwjgK/vpkOb/8eddNhfXOk43qu1DEHsL3jndyRjiu5o8DYKM4ofbOUr1C3AkcFrlk4Z4BfX8qn 73x7dP+Ot+N/7fhfO7a343/t+B8w+sQZpc9Cn40+G302+iy0pQL09bt6DPdlBtP1CN++aON/Nv5n Y7uN/9n4HzAc4ozSN4A9JWwrYWMJWwewuR/422/U1WO4u+rQl0efjT4bfTb68mjrqtEnzih9Y5Qv U7cMRxmuMThHgV/fDG2l9jL6jrrpUP/L4X85/C+H7Tn8L4f/AcMhzih9s5SvULcCRwWuWThngF9f yqfvfDa6f8ez+F8W/8tiexb/y+J/wOgTZ5Q+C302+mz02eiz0JYK0Nfv6jHcl7nAqj3D2u+ihf9Z +J+F7Rb+Z+F/wHCIM0rfAPaUsK2EjSVsHcDmfuBvv1FXj+HuqkNfHn02+mz02ejLo62rRp84o/SN Ub5M3TIcZbjG4BwFfn0zGZ//uemw9juSwf8y+F8G2zP4Xwb/A8ZGcUbpm6V8hboVOCpwzcI5A/z6 Uj59WomN6t/xNP6Xxv/S2J7G/9L4HzD6xBmlz0KfjT4bfTb6LLSlAvT1u3oM9+W2aH0X2/C/Nvyv Ddvb8L82/A8YDnFG6RvAnhK2lbCxhK0D2NwP/O036uox3F116Mujz0afjT4bfXm0ddXoE2eUvjHK l6lbhqMM1xico8Cvb4aJl/rT6DvqpkP9rxX/a8X/WrG9Ff9rxf+A4RBnlL5ZyleoW4GjAtcsnDPA ry/l03c+Fd2/4yn8L4X/pbA9hf+l8D9g9IkzSp+FPht9Nvps9FloSwXo63f1GO7LfFBXe4a138UW /K8F/2vB9hb8rwX/A4ZDnFH6BrCnhG0lbCxh6wA29wN/+426egx3Vx368uiz0Wejz0ZfHm1dNfrE GaVvjPJl6pbhKMM1Buco8Oub4QO52svoO+qmw9rvSDP+14z/NWN7M/7XjP8BwyHOKH2zlK9QtwJH Ba5ZOGeAX1/Kp+98Mrp/x5P4XxL/S2J7Ev9L4n/A6BNnlD4LfTb6bPTZ6LPQlgrQ1+/qMdyXm6L1 XWzC/5rwvyZsb8L/mvA/YDjEGaVvAHtK2FbCxhK2DmBzP/C336irx3B31aEvjz4bfTb6bPTl0dZV o0+cUfrGKF+mbhmOMlxjcI4Cv76ZRp//uelQ/2vE/xrxv0Zsb8T/GvE/YGwUZ5S+WcpXqFuBowLX LJwzwK8v5dN3PhHdv+MJ/C+B/yWwPYH/JfA/YPSJM0qfhT4bfTb6bPRZaEsF6Ot39Rjuy/FofRfj +F8c/2P/cSWO/8XxP2A4xBmlbwB7SthWwsYStg5gcz8w7dcTW/ic/iBhARwCv8Riw/NgL+AjROD9 iu1uPi5W172LnW75BsKD4BDcRbB8Pcy7zkxR59hVjL5/ei9lLErTtM6xvehNr+V9z9p1LLXhHqB7 lwSxF/WPI/q7lE2Bv4XEvqgp9kftZ7/UFPvj9iv96gt3PRC0frWN8wh0g7rUPZbiau/PgH1AcYU6 TKgVJ8vJWf7P9LHqmTgut/hbSA+Tv4M+PEJ4P+FmwsOJl5z98ocTB2xTRz5i4hS5KX+Zo+JVsFH9 5fO/9+Hef331D0Lve0093O+570WT1rX+uINyBaDyOljjc0LT5so38STtf5j0HvAa2MmLrUD9lyD9 09S53E9Tj9h/ZwmKn/N898HwULSuftxKQaaRt81eqTvai9z3+qN1ue9lzq3xqDa1gDmYanrSj5A+ S5+qrP+7rmPk66hnr1Ty5XcLb7M/ytz3+jhpc9/LyYdnPe57NXTi84G/hdS5mu+4nWLKufAdt1O0 Hedo6DzlLJk7971ORX/HTe1NNad/NCZzblxNrrT6jcPZK3WByBTQGEyBbqD6/kMch3yZZh3/LPnm bteJ2GOxe1b45qvGtrgVNtaEyjNpvW8KytO1XFBadUxoxn9bbGl/lMpvBbJNug4S1rs/yvj0rmL0 +/talbmXc1lolE06buU8YWF/1Ngq90fFV7y/tXz/vPe3ErdgXxI8CtQ/uFhd7ym3Ys6wjXNrztCB CO2PugPId9hTn2VPfdb41lrMF26P/VHym8Qq9kclhi3a1/Xzxf1R9fqAf14BlXOYfhJP0OcD/M2Z Y+zmde2p1z3958BdQFrYR5/lO1dZ9tSDTk+/B/FRpa65hq47c+Aq2KjzxLe+v5d54rnweeKHBj/Q eeJ3aE+LvmsHdwO9H3wpleCXnd/K7ssKiic8/Wh8hKJ19Z3//eMSFd8EG6cfvZ9bv/jEPuaJX16X eaI5t66tuuZbwBy3ap74O3/8bmEAmHniBeJmnujkx3p+xvbUn17Nnvr3NE909tS/Z/bUv7c0T3wv ek+9+qYTqH8KIOfGGV7L5onT5F0AGoM2uBOovv9oJ+OQL9PMEwfJP+jshzoZezr25OKcMWiHlMa3 +DUvVKi0geaEQXGVVb5CE48TF7YD2Rk1Z/weZd4Ay8e8d4+U8e9dxfWbMyaLybj6TXY1uOs+tI3V XUw6eWQH7idS/zwG7gB3gV+ngffTnya9n/QW0r8Q+zNeNYf32mJyVwq38oJ0mbn4ncQtoHZtKC68 RjLG7Tt+7WPhsNz4/wPiCIos0CQBAA== --_008_BYAPR08MB4903CED7FFDB7D11EFDB49FAFAD50BYAPR08MB4903namp_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=11790; creation-date="Tue, 06 Aug 2019 23:17:07 GMT"; modification-date="Tue, 06 Aug 2019 23:17:07 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAk8AAAEvCAYAAABc2yWpAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAC2OSURBVHja 7Z1/iCTXndgbI6H9Y22P15J2EXvWJFozwpbkXu2PEcXaaXzDZG0GIx8sI7Te80LuXkwww3AjMwqJ b0eQrPqPhS0OJmaDYRRHuTMJ7Ib8UWuO4+YODs5wHPPPBRs6eHKBWIa7sNHJ0loxdqW+1V1Vr169 6h/TP+pHfwo+0k71q9dV1a+/9enve6+q8cYbbzQAAAAAYDg4CQAAAADIEwAAAADyBAAAAIA8AQAA ACBPAAAAAMgTAAAAAHASAAAAAJAnAAAAAOQJAAAAoDrytLGx8ez169db/bh69epqsGxCl7W1td8Z dM6E7e3tBRqjnXa7fWyYcyjnmjaXEHwX1wadM/lO08bemHQMXKP9jR4D5XtOGyMmVikmDlUouLif On78+MPl5eUH/Th//vyHL774on/u3Llfw7lfN5vNX1+8ePEf+p2zz3zmM+997nOf+1OCgp3Pf/7z //6ZZ555v985lHMs55o21yX4Dsr/fzno+yrfaflu084mFwPlvPfOPwwZA+X7Ld9z2hkxsUoxcagP a2tra/Gpp556z2eZ+LK/v+8vLS0dEBTsBEHgv+zt7dFQprDId1q+27QzYmCRi3y/5XtOOyMmVikm EjgKXpAnAkUVAgXyRAyc1oI8EROrGBMJHAUvyBOBogqBAnkiBk5rQZ6IiVWMiQSOghfkiUBRhUCB PBEDp7UgT8TEKsZEAkfBC/JEoKhCoECeiIHTWpAnYmIVY2I5A0fH9Z1Gw2/EOL7yOmPXp7zyfVjI E4GiCoECeZp0DOz4rnKSGOco3z1CiOt4rq9cLxPjOq4Tx07XGy/+xe8xpQV5IiZWMSaWWp7SgcA5 UnAp+4I8ESiqECiQp0nGwECcHBEm1+/448S4Xj0ZK8pbP8a+KuSJmEhMrJw8+b7nq+BvR48sntKy U5KZ8oyApG2TkbFkWydY2bHWNxtTQ54IFFUIFMjTBGNgEGsGipI1HvVimlJGZj5ByoVxMM5oBfFw mPgXvmWSCXOUxFFLXVOIk8gTMbGKMbEi8mT8+olf735xO1EwcrWgpAcovT7L+igYZeqbgT8hTwSK KgQK5GlyMXBglikvvnW68pT8QNTiYipm5sXLnPgnf8j6qN5U/LO9x2TjJPJETKxiTKykPCX9+eav riTb5CktyGj1dbdVvpcJZrb6pn+oyBOBogqBAnmanTwNim9JF9ro8mSLf/H7ytgm5cSZJbOuacVJ 5ImYWMWYWMluu37BpytNyleO1s03lDwVM6YKeSJQVCFQIE+T7rbLl478eGQOX5icPEXvKVmlTmr/ THmafJxEnoiJVYyJlZCnTHo47m7TM1G9gND74tvKJ2nrqO70GAJrfVNekCcCRRUCBfI0wwHjufFt fHmyxr8oU9+LeVGGKVNXv7g7xoI8EROrGBNLLU/9blVgDlxMfg1ZZof0HTDZDWD59U13QZ4KCBSZ 9pVcEMapb1AV057yPc1AgTzN4FYFWoyzx6PsxBmzK22gPOXEP/07Ef+YTGX6u7LnTSFOIk8VkCe9 fegfurY+6U3urdN+HOjtPjUxwWxAfbdFnli0BXkqTp7iL/uAbpSJXSynPOV7moECeSIGTmtBnqol T9mMaVqeUvcYMw1I60WydQP33bZkMZHAUfCCPJVAnvRZR9qX3DYlO/nV7oSDa8Og4eb/su/e/NAy 5Tsz7VzF9aUyApZyk9Iv5Al5KsOCPFVHnpTKzsTsrkt3BTeCdcqWWeo7Q3PAtjNYkKcKLchTCTNP fW+FEa2PxokY8mSIWDLr08w8GdPOc6eKm9PTiwkUyBMxcFoL8lQhefLM+yfqcTEdS/VxdMnSi2fB dvo9xsw4bN92+gvyVKEFeSrDmCcnEKD8cSRxNsgxBshGX/ZU5ikKDlGAcH3PvF+OHkS0bjz7VPFs uSICBfJEDJzWgjxVSZ6SyQ6exMnejVNT0pP6EWgbDtEd9+QY3XPDbTvdBXmq0II8FZx5snTZ5U3J zswusspTNziEIuTo/fd2eTJvv5GdKu5NLYWNPCFPZViQpyrJU/rHZXyDVf0+ZCa5BqTHtlG3nc5S UXmSk2d0VaRmQ2VveDl81WNYbJSanFL3K/JUfLddRpbypmR7o3fbdeK73veXp/yp4shT7eVplJlM yBMxsWB5Stql/jSPKDOfvlaa3W/x38Yd7m0/WIvouqukPKVSduYFQ78gzVqepjxLCnkqwZgnaxea fUq2PhskHijpZu9L5li6BPUp352cNp6dKo48zZM8DZrJhDxB4fIUP/PQvLeiZWxmJFZx/PLCG1hb n6E4cFvkyWY3xgXC/nf2ZnD+aLOivPz1/eua3k0zkacSBorcZqqMKbmqsCm1sw4UyNP05WnQTCbP NhtTez5ndFGKMqbW8v5RYuD0ZnwiTxWPiTVbqidPAx7Hkpt5GjArqru91r2icrpd+tXV8ac6eA15 qlag0C9I5kBz5Al5Gi/+9ZnJpHJmY0ZZq97Mpbj7w80p7x0lBk5vxifyhDwhT+NdkYxf8LYxT17O Q36HnxWVO1vKG/Bw4KN0FSJPBIoaBQrkaRby1H8mk3U2pjnhQb8JoaV87qQHb5QHEk92QZ6IiVWM iaWWJ2tfZ0aehp8VNViecrpgkCcCxZwHCuRpFvKUP5MpGoybmY2ZI0/d7rhs+cHyNMwDiSe7IE/E xCrGxGp02+WVzZsVlQooo3Xb5T9seDpjW5AnAkUVAgXyNBt5ypvJ1GjkzMbMkSfHySnvHSUGIk/E RGJiOeVp4IDxnEDj95sVlTdg3DJbamBdDBgnUMx3oECeZiRPOTOZohmdmdmYed123hAP+h06BiJP xERiYknlqfeFnvaTlI80W4pbFRAoCBTIU01uklnCGaPIEzGxijGxRIFDv0nmNGPHiLOluEkmgYJA gTzV6A7jZZsxijwRE6sYE+cucJRtQZ4IFFUIFMgTMXBaC/JETKxiTCRwFLwgTwSKKgQK5IkYOK0F eSImVjEmEjgKXpAnAkUVAgXyRAyc1oI8EROrGBMJHAUvyBOBogqBAnkiBk5rQZ6IiVWMiUMHjk9+ 8pMfyIUeJsvt27eRpwGB4vXXX6etTAH5TiNPbxADC0a+38gTMbFqMXGoD6vdbh974YUX/kQu8v1Y XFz825MnT35QNMEJ+OWTTz75YdH7cerUqZ9/+tOf/ptB521tbe1fEhTsXLly5dqg8yfnWM510Z/3 E0888YsTJ078qgzfgU996lM/HXTe5Dst323a2eRioJz3Mnz+0g6lPVYlBsr3nHZGTKxSTKxl42o2 m3tf/epXr/NFg1ly/fr1VvADYp9zAUUj7VDaI+cCiInTAXkCIFAA8gRATESekCcgUADyxLkAYiLy hDwBgQIAeQJiIvKEPAGBAgB5AmIi8oQ8AYECAHkCYiLyVB2uXLnyysbGxrM0Xpgl29vbp9bW1r7B uYCikXYo7ZFzAcRE5AkAAAAAeQIAAABAngAAAACQp+qwvb29wIcLtD2gHQLQFpGnITl//vx3ZNA4 DRdmiVLqpTNnztznXEDRSDuU9si5AGIi8jQ03KoAioBbFUBZ4FYFQExEnpAnIFAAIE9ATESekCcg UAAgT0BMRJ6QJyBQIE+APAEgT8hT0dy6dWtxb2+vVUfk2AgUAMgTIE/IE/I0Ufb393f8mi5ybAQK AOQJkCfkqWDW19df3traqk1GA3maHQsLC4dHFW95jhO3yIAyIO2QZ9tB0cg9nuo6hIYPGHlCnvQv RKPhC+NIFAAA1BtOQq3kyfNV7+LfxfHdTrLe6f4RLB3fdaLX5N+98o7rd/rVl3m9z9JxfWeI8mWV JyQKAACQp3mRJ11YPBUIgArWynrHd8J/p+Wp4zqJVAXllWfKU7SNvNwwXq+/PCFRAABQO3mSAWkm 6+vrv5Wz/mXb+rJz7969t0IZUSrJBCnXkjEy5MmP5MgN13uxKGmZp1iw8jJZFnnS96VnU/JaLBuy LpQnEbZs1kr2KS67+u3/UaZznSdPpkRtbGw8O0rba7fbxwg4MCsY7wS0ReQpFxkU+fjjjz9cXl5+ oHPu3LkPL1y48L65/iMf+civZOR/1XBd9zCUkVhkut1pXW/Ru+D6y1Mn3E7K6ttEAjVEt12Udkrt S297bdtQstx0mbR4Jar2z53Fd0+cfvqvynKuB8mTIOVOnDjx92fPnn1Xb18XL15878UXX/yl2e6k jZK1glkizxNjth0UjTzbjtl2JUQuSK+++up7ww7DkQtfFY8z7LZLSYfIjy4m/eVJedp6EZ0wa6XJ U0q0OrmZp7wuOXO78G+l7GUiUdM4d3VnrTRfiAHSFF2Qnnzyyb87PDwcqt1JG0WeYJZwqwIoA9yq AHmqpjzFGSJ9fTRAvLtNsu3R5akrZEmpOPNkZqO8bNkqjHmyXYiQJ0CeAJAn5Kku8pS68GvdfJmB 5L1tQsEyy48oT8OMeTLkKtnHz35weePG2TLKU78LEPIEyBMA8oQ8lV2earqUMfM0zIUHeQLkCQB5 Qp6QJ+Sp92UfphzyBMgTAPKEPJUYeYCuSEYdkWOr4meCPAHyBIA8IU8AyBPUBLmnnTxXjHMBRSJt UNoi8oQ8ASBPAABzDvIEgDwBAADyhDwB8gQAAMgT8gTIE8AQbG1tLXIegLaIPCFPgDwBDAmz7aAM MNsOeQJAngB5AkCekCcA5AmQJwDkCXlCngB5AuQJeQLkCXlCngB5AkCeAHlCnpAng93d3aY8rgT2 Wnfu3HkJeQJAngB5Qp4qIk9SbxGBJ7gY7/ss4fLgwYND5AkAeQLkCXkquTxJfQsLC4fNZnOviOdC IU/IE8Ak4Nl2UAZ4tl3N5UmXpiJv6IU8IU8AAIA8lVae2u32sdXV1c3jx4+/U7Q0jS5Pnq+CY2nE OL7bSdY73T+CpeO7TvSa/LtX3nH9jqXWjuvkvoY8IU8AADCn8hRJk2SalpeXb29vb58qy/GMJE+6 5HgqODYVrJX1ju+E/07Lk4hRLFVBeeVl1CkoG6xXDctryBPyBAAAcytPjz322IPTp0//ZavV+rZZ nwxuC5YdGyJc0y4fylPH9R2lksySci0ZI0Oe/EiO3HC9F4uSlnmKBSvPx1R3GykX2VNmXwasD6vR MmKyXspq++qpKBOWLtst6iTbfu3tD/XzY5MP6UvPO5/TLn/ixIn3kCcoKxsbG8/KD0XOBRSNUqqJ PNVEnp555pkffPGLX/zXZnDpd7FcWVl5fdrlf/KTn/x5KBux5HS74bpuonfB9ZenTridlNW3iQTK 3m2XSE03A+VFktTQ1/f+nbde6k+JUrDvbo486ZIWC1ny93/82rlfPHPhn9zpJ6Py+Y8ir5Ms/4lP fOLnyBOUFWbbQRlgtl2N5Em66aS7Trrt5IJZpl9nSebJS3WleRnBscuT8rT1oZy4aXlKiVanzxiq nrDlZY1y1pv1hn8rNVTZWOw0zl3dWStr26PbDpAnAORpbuQp2raMEnVkeYqzVfr6aIB4dxu9u8wm Lqm/o30YUZ7MbFI282RkqfTMk/E3Y54AkCdAnpCnkslTGSVqJHlKZWm0br7MQHK9q80snx2HlGSi gnXeiPJkG/OUWhdIm5M/5im1bePiry5v3DiLPAEgT4A8IU8lk6cySRT3efLJPAEgT4A8IU9VkSdT oq5cufIK8oQ8IU+APAEgT8hTiY/n7t271/f393dgf+f+/fubyBMA8gTIE/KEPEFNQJ6g7Bctnm0H RSPDX65du3YZeUKeAJAnAIA5B3kCQJ4AAAB5Qp4AeQIAAOQJeQLkCWAIeLYdlAWebYc8ASBPUAmY bQdlgNl2yBMA8gTIEwDyhDwBIE+APAEgT8gT8gTIEyBPyBMgT8gT8gTIEwDyBMgT8lQLeeKRKvP5 qBfkCZAnAOQJeToiPMy3/MsoDxmWB0MjT4A8ASBPyBPyhDwN+Xk+8sgjD5eXl28PkijkCcqMUuol 7vMERSNtUNoi8oQ8IU81lydpI8IgiUKeAADmF+RpIvLk+ap30Q1xXL8TvqOsV8F/By0d33Uc3+0c RQ0s23Zc34n34YjLJOowz4vy/CKWo8jTIIlCngAAkCfkaWx5SiTJUw2/6wmzkCfxHMd3tI3NvwuV p7iO8Y7xiAcRvKfy//ODB//rqPKUJ1HIEwAA8jQ38tRqtXYmycHBweEw8iRCY2ZgpFx3XSA7sVjY s1i27e2ik5aU5D162xlS5Cl7WeW64T45lvfM7IvUqVR3v1P7li9PeceT7ENQn+ybl7+/2Tr0cyfn NDmej5258MfDfJ558mRKVCBP/wd5grLCmCcoA4x5Qp6GkCdb91RPnkK50AUhEABXGeV6UuCpOGsk cqC8nhyZ2xsZnHidLkdBXY2UeERSZJERT6XFR+qJ9kkXH9u+iOBYM2xpmYn3Oe94PMs5yZOnnHOa zrh1M09vv/POu8N+nsgT1AFm20EZYLZdjeRp0vtg67ZLy0OwXqTAuAiHWZ3EJrSsjC4cvTot22eG D/WkS++ys3bnKWWVkUxXX6ePZJn74uZ18SWZpzBLFO10zvGk96F3TrwR9sPTslFd66TbDpAnAOQJ eaqsPJm249kzT3G2Kbdsv/FFKkDL8BjbZTNPmrTZMk/DZKj6jo/K6bbLO56Bmach6kiN+/LC8m/+ 9YOfHlWeGDAOyBMA8oQ8FSFP5tijUJREBIzxPZYxT1EmJru9zT0aqW4665in3LFWtjFPg8dGNSxd a3Z5SmeW7Mejn5Nk34bZX3lNzmHDyNpFZX5j9Ztbo8gTtyoA5AkAeUKe/Grc5yk9niktH/O1TG52 HjfJBOQJAHlCnmosT+ZYnoJujTS38sTjWQB5AkCekKcpy9Pu7m5zb2+vBeXlzp07E58qizwB8gSA PCFPAMgT1ATu8wRlgPs8IU8AyBMAACBPAMgTAAAgT8gTIE8AAIA8IU+APAEMiwzU3d7eXuBcQJHI mKdr165dRp6QJwDkCUoPs+2gLBLPbDvkCQB5AuQJAHlCngCQJ0CeAJAn5Al5AuQJkCfkCZAn5Al5 AuQJAHkC5Al5Qp4AeYKZcv/+/c39/f2dOtNsNg9v3779Vt2PUx6PRZtGnpAn5AmQJ5gy8qBov+ZL q9XyA7mo+2H6d+/e5Xs1Zba2thaRJ+QJeQLkCXmqvTz96Ec/8h8+fIg8wfiSEFw3m83m3lElSilV y+wg8gSAPCFPLMgT5MpTxDgShTwhTwDIU+XlyfOVdlFoKG/Ey7Zsr3xvKkrQ8V3H8d2Ovsr1Hcf1 O2NXPYl6xj13yFNV5QmJQp4AkKd5l6dYIiyyMpb4jC9VHdfxHW2HzL8Ll6epnLvRzzHyVIw8IVHI E8DU5elLX/rS+0tLS/+11WrtQPH87Gc/e9BPAERU0lkVI9MSbqdnnozXezhKhaioHhEXM2Mj6/Qy VslJ75+nLFkfQ4raa5/13/zrB5nyypVyTrIf2ntmjjtv30Y6d/r7B3WpXlljf73eetv26fMb7LuT HM+n1rb+hjY9XfrJky5RKysrr5nbfuELX/g3zz///Nu2eqsuXcgTwJTl6Stf+crPkacSypN2QY4z J6EwJKIQXtRdFWd95OLefVmTJ09pWSEt8xTKUl4WqleuTxnPJhrBezVS0tHo7o8hIy889XH/m2/v d8ubUhYfryY+tuP28vZttHOXlqA+8uRZtu+Y5zd9jt98802+VwXL02OPPfZAyj3xxBN/v7m56d+4 cWMggVB9WPVsPPIEQLfdXHfbhdmO6KItsmFcHJSny4KebUrEIs6YKDctT6kuMrno63X35CmvG60n DXqXXW53Xo48Zbr7cjI+1uN28/Zt+HMXZrlSYtlHnlzbuTfPr0e3XUm67SJp2t7eXpjHmIg8ASBP cy1PqYu6malJZZvM7Es2KxNd5G2CYM1Q9R2DJPuoArTsjrF/9sxTxz/z8T6Zpzx5Mg+yM1ieBp27 9Lq8zFOvDlcNHHzelUEvfk/kafbydPz48XdWVlZej6RpXmMi8gSAPM25PKUzOqkxReHFPj2mqVsu kafUOJ1wXI825iklH+bYnUHy1NsX43XrmKfUesf/eCRP1jFPFnmyHbc3jDwNOnd6ts0JM1HZ90vW Z7fPnl9P23bpn/2779OmZyNPIk2rq6ub7Xb7GDEReQJAnuZSnoZfdMEwxaGsSznvMD75mXlknqbP IGlCnpAnAOQJebLZk3UcDvKEPM0Dg6QJeUKeAJCnOeDOnTsv7e3tterM0tLSwfb29mbdjzO4sJ+i TRMTkSfkCQgUAGPDIzSAmIg8IU9AoAAAICYiT8gTECgAAIiJyBPyBAQK5AkAiInIE/IEgDxBlVhf X3/ZvIkhADEReUKegEABkMPi4uL+9evXW5wLICYiT8gTECgAkCcgJiJPyBMQKACQJyAmIk/IExAo kCdAnoCYiDwhTwDIEyBPAMRE5AmgJIFCKdW8dOnSm5zf+UWe1eZPYJnks+34XAB5Qp4IBFC6QCHS tLS0dO/kyZMH165du8z5RZ7GXS5fvow8AfKEPCFPUL9AoUuT3JeH8wqTkqd33nnHn9TC5wLIE/JE IIDCAwXSBPnydOcbruP4bkdrQB3XdxzX74xrQUesh88FkCfkiUAAhQUKpAmGyTx1XMd3NHsy/0ae AHlCnpAnqH2gWFlZ+eD48eM/DXgnaLNX9XrkERqtVmsnD/MRG/K3zKLKo91uH5tmefM8TLu87F9R 5QPZfWnc8keRp7TkdHw9E+WpRhjHQpRnlSJPdcvrZcOiYblAxIztRc6sdSrlK1l37tX/wHcekCfk iYYOMw0UzWbzF48++uj7p0+f/suvf/3rv6nXI9mofvIkr+vl5SIt09Dz2NjYeHaa5be2thb18pJB m2R583hlAP00y1+5cuWVUc7PqOUlRsViYvDII488DGTylF7+1q1bf6gLUEqMPOU3UpKkS1Fann77 t3/Tb3ztP2UzT41IxHpS5okkeXGR1Ps2lO/14qaNxx577IEp96urq5ujHG+/8vJjw5T75eXl26Ps j3yHRt3/vM/2zJkz9839CX4YvT7N8rL/eeUli23GpWmXl9nAeeWD8/nB2bNn3w0+owca//fChQvv G+sePP744w+RJ+QJkKeBv7LW1tZ+VwLzwsLCoVwAzIsIQJx56omSdNXpXXa53XkWeXrqqY/7n/3m 23277UJRclVGKkwh43PJR77HfTKRzXHLy4+PMpWXHwd55eWHkblOYp4MUxgm6408IU+APOWmqCVg IFEwUJ58z1eOCtAGj0vmKZUlsmWeuhmlM2ee8htr7eHkSavTVpbPBY5KlMmu47EhTwAzlKcIJAr6 y1NvzJIxwNs65im13gnHNZ1ZbvnttfxsUt7YqEYj213I5wLIE/JEIIBSyBMSBYPkaZyFO4wD8oQ8 IU9QW3kyJUoGjXJ+kSfkCZAn5Al5AuSJBwPDEHzve9+7HLSr/XGRGU3f//73DyZRF58LIE/IE/IE yBPUHslg2u5rBTBL5N5nyBPyBIA8QSVg7BzQFpEn5AmQJwAAQJ6QJ0CeAAAAeUKeAHlCngAAkCfk CQB5giqxtrb2DcY9QdFIG5S2iDwhTwDIE5QemeHEbDsoGm5VgDwBIE+APAEgT8gTAPIEyBMA8oQ8 IU+APAHyhDwB8oQ8IU+APAEgT4A8IU/I0wRpt9unJvEcq0myu7vbRJ6QJ0CeAHlCnmouT9GHvb6+ /nKVzsWtW7cW/ZIte3t7tQ3eyBOUGXm2nTxXjHMBRSJtUNoi8lRjeYqkqaq/2JAn5AkgYnt7e4Hz ALRF5Glq8lR1aUrk6cZnXcfx3Y52wB3XdxzX74xrQUesB3lCngAAkKcayVNdpCmRp1uLHdfxHc2e zL+RJ+QJAACQp5HlqW7SpMtTWnI6vp6J8lQjPP4Q5VmlyFPd8nrZsGhYLhAxY3uRM2udSvlK1n3h 936APCFPAADIU4m4cuXKK48//vjD5eXlBzoXLlx4/+LFi/9grg8u8r9+5JFHHp48efJABrGZfbHy DJ5IrEzKXj4a8xQJUEqMPOU3UpKkS5EhT65KREjPPDUiEetJmSeSlJRLvW9D+fLK5ubmW3n7v7S0 dM/8PFut1k5Vyh87duz9s2fPvmu0sXfPnz//gdnupI1KWyXgwKzg2XZQBni2XYmR7JGJiIXjOG1z /crKyu+JOAlf/vKX/4Xtg7bVJ9hmrpSpfDxgPBAl6arTu+xyu/Ms8qSUpasvT7IajRSmkO3u7r7S Z/+b5vFubW0tVqX81atXv2yuW11d3ZS2ZStPIIVZwq0KoCzXZ25VUCGazeZev26SOnbdJbPtPF85 KkAbPO6ls0n2zFMvo5SXeRomQ2WUrfOYp3kLFIA8ARAT51yezA9WsgVVu69Tvjz1xiwZA7ytY55S 651wXFP+mKf+Y6MajWx3IfIEgDwB8oQ81UyeIqTLRsa8VFmiuM8TgQIAeQJiIvI0M3mySZRtDAzy hDwhT4A8ARATkacciUKekCcCBSBPAMTEuZGn8+fPf6fqY5igesgMSNstDwBmjbRDnm0HJYiJTZ5t VyHa7fYxGi7Q9oB2CEBbRJ4AAAAAkCcAAAAA5AkAAAAAeaoK8iydjY2NZ/mAYZbI41zkES2cCyga aYfSHjkXUCTyiLGVlZXXkaeKMO6tCgCOArcqgLLArQqAmIg8IU9AoABAnoCYiDwhT0CgAECegJiI PCFPMEXkjuVl5ubNm5vr6+sHZd9Pk93d3SbtC3kCQJ6QJ+SphpTt8TN1WQ4PD8mWlYzt7e0F5AmQ J+QJeQLkCXmCIWm1WjvjCBDyBMgT8jQyy8vLt3m2HfLEgjxVWZ4ajYYvHEWEes+2a3IuoUikDdb1 eZ98wFAhefJ81bughChvRE2Q7ZXvTUlCOq7jNxzX7xxpa33fxtnP0bdFnsotT+NIFAAgT4A8+SqW k47vOo7vdiamPkF944hVd3ulGr7yZiM9k9p35Kka8oREASBPE0Ge1ix3L5VAMwwXL178g2HLQvno J09h1ieVkTKyVOF2ZnYnet3xHScp6wSVZusL38R3lOpuZxqSp8Lt5P/W8vE+5K23Z548lexXWK1s a2Tf9DKO66YkTH8t3C/zvYN1BwcHh7SvcvH000//WZ486RJ19erV1VFiIMMZAJCncDDa6dOnH964 ccMfBgk4BOaKy5MmPHHWKRQCT/OY4DW3JzM9seq+rAmKl7yeyd7Y6utE4mLP8MRlzHoMkUkEyFxv kSddxPpmnPTMU/oY9W7E8H1ceW99Xx3/tf928L9pX9WTp4WFhcOzZ89+9/nnn/9wlBjIhQ8AeWot Ly8/GLZ7gsBRn267MDMUiYVIgnFh6cpI9Ld9LFGcXeoaTSIg1vp60mMd02RkuXLKy/uFwmZd72bk yY3KZ4RJf698eeoY24d/K5V6b5G+39//n39F+6pOt51IUzSbWP7/6quvvkcMhDIiz1eUtow8IU9Q EnlKddtZMjRJtmnwuKKuZHh964szXDZ5MrNYUebKKJ/KPGXWD5l5Sr2XnnmKsklG5imVQetlnpCn SsqTLk0RyBOU/RrNrQqQJyiVPKUzK6mxPWG3VDob1C2Xzso0jMxUVIeUzdaXL09Jl50uacE6Lzs+ KZarzPohxzxlxmqZ+z7EmCfkqVLyZJMm5AmQJ+QJeYIh5WmEuWspoUlL18yWvExVbvdfMQuz7cop T/2kCXkC5Al5Qp5g4vJkjltSXgFWgjzBEZGxIsOUQ54AeUKekCfoy/7+/k6ZuXfv3luu6x6WfT9N 7t69e532VU2QJ0CekCfkCQgUAMgTEBORJ+QJ5oU6P8cJkCcAYiLyBACAPAEA8kTgAADkiRgIgDwh TwAAyBMA8oQ8AQAgTwDIE/IEc83Gxsazly5depNzAcgTQPd+ZcE1+jbyhDwB9G2P3KoAkCeA+sdE 5AmAQAHIEwAxEXkicACBApAnYiAQE5En5GmOuXXr1iKPZ5ketDHkCQB5Qp4IHDVjb2+v5bNMbaGN lYvt7e1TyBMgT8gT8gTIE/IEQ9JqtXZOnjx5sL6+/jLyBMgT8oQ8AfKEPMEQ8iTxSugnUcgTlBm5 fctzzz33R8gT8gSFylPHd53uBaXhuMFfk1hsdXq+aqjgv6MsR92m996C8vyiFtpYeeWpn0QhTwDI E/IEfeWp4zq+4/aUyVN+1zVEfkaRlnR5e52zWgJ5ioVN9svx3c4s3z85F7Sx8suTTaKQJwDkaSby JEEJqsfm5uZbIjcNI7vjqeSi4ijlO7ZMTscNX1PGRSiUJkudSRbJyAyJ6Jh1xbbV26bv60ZdfeRJ pM48juRYg/pVr6y8n5aF83rrbdun9yGQRifZn4+dufDHtLPy8PTTT/9ZnjzpEnXx4sU/QJ4AkCfk CfLlqZcdSnex5WWetPUiGLEgWcpn6uyJULA+ykqJjIQOEtYVSY4uPJo82V631WXITJx1CgXM03Yv eM1VhgT1kSfPsr2xD+Y5oo0hTwCAPBE4athtl1KjuLtNlyFt/FIvQxPL00DZ0uu0ZZ5sdWliostT 7utGXVrmKcwURcITyZyeJXO07kVdymzv52a3T5JwjpaNotuObjuA6cGz7ZAnKIE8JSJiypMts2Jk nnK6x+x1dkXIjTNEKcM6kjx1bHXlddt5Kjt43Bsm89Srw1UDB593j9WL35M2Vn55YsA4VPEaza0K kCcoOvMUdomZ2ZtkLJDjusaYnrxskTbmyVqnfcxTXH7szFMjkTStrD54XR/L1e3S07NqTpiJSgQw uz67vTEOqnesUbnfWP3mFu2snPLErQoAeUKekCc4ujzNeNGzUqboFFnXNGbm0cbKJ0/cJBOQJ+QJ eYLKyZM59mis2xhMsi7kqfbweBZAnpAn5AnGZmdnZ0EEqszcvHlzc319/aDs+2mDNlZNkCdAnpAn 5AkIFADIExATkSfkCeYFeY7T+fPnv8O5AOQJoN4xEXkCAECeAAB5InAAAPJEDARAnpAnAADkCQB5 Qp4AAJAnAOQJeYI5hAHjgDwBzEdMRJ4AJtgeuVUBIE8A9Y+JyBMAgQKQJwBiIvJE4AACBSBPxEAg JiJPyNMcsru729zf39+pAvfu3XvLdd3DquyvDXkMDu0OeQJAnpAnAkeFuXv37nWfZWbLrVu3Fml3 xbO1tbXYbrePIU+APCFPyBMgT8gTDEGr1do5fvz4O6urq5v9JAp5AuQJeUKeAHlCnqAnTxKvhH4S hTxBmZEManCNvo08IU9QiDx5vupdSEKU53fXKd/L/bT7vN5xfcdx/U56pe86vfrj1wa9x4jv23cb 8/iQJ+RJaxM5EoU8ASBPyBPky1NGdsZYLPLUcR3fcXtrPOXP1l/04xOJc3y3M8v3l/fsCh/yVF55 skkU8gSAPM1EnqT/FarDa6+99iO7PPUyPCJCSiWZm9h6ogyQntXpSUkoT4Es6dsEwtTIZIz0LJKR HZL9sb63tk3u60Y9feRJpM7MSHkq2j6oW+nHlJwjT/WrI31OHCfZn4/943N/S7srnoWFhcM8edIl 6vnnn//D9fV15AkAeZquPMk2UB2++93vtk3h6GaINHmKpCglHr3XAylyzDRO3jahQOV022n1iIyE DmKtx5An83XXUo9N8GL5SnQuFKJg+7QgDpCnnDrS5yTJPH3rW996hXZXPC+88MJbg+RpaWnpXqvV +n0yTwDIE912MGS3nSZP1oxLIjFx5iWSiD5ZmnQXXl7mSZOjTD2GPFlfN+rRji/c12g/I5nTxdHR uhd18cs7JksdUn36nNBtV6VuO5EmpVRTytFtB2VGnm333HPP/RHyhDxBBeUpI0WWbRyjq8yUpyRL lD92ahh5km627HiqnG47T2UHj3vDZJ4G1JE5J15cHnkqrzzp0hSBPEHZr9HcqgB5ggrKk6uP9+mX EfLcZAxUKttkH/OUJ2GjZZ60LkitnD54PRnfFHXpabMCG2npS8rmre++JgJnnpOozD/66r/6t7S7 csmTTZqQJ0CekCfkCQbIU/FLumvv6LP/JlWPbxlcPomFzFN55KmfNCFPgDwhT8gTlF6ezLFDR76V waTqQZ5qzTCPZkGeAHlCnpAnyLuInNrb22tVgZs3b26ur68fVGV/bQx70YZygDwB8oQ8IU9AoABA noCYiDwhTzAvyLTcS5cuvcm5AOQJgGfbIU8AAMgTACBPAADIEwAgTwQOAECeiIEAyBPyBACAPAEg T8gT1Ay5oaHc2JBzAcgTQDcm8mw75AlgYHvkVgWAPAHUPyYiTwAECkCeAIiJyBOBAwgUgDwRA4GY iDwhT5BBnn23v7+/Uwbu3bv3luu6h2XZHxu7u7tN2g3yBIA8IU8Tlado0K8EJRp/+Tk8PNz3WYZe RDZpN8gTAPKEPE1EniJpOnny5MH6+vrLNHzkCXkC5AkAeUKeLIEDaUKekCdAngAmjzzbrtVq7SBP NZInpKlO8tTxXacRfr4Nxw3+ksXzVUMF/53kIu/j+G7HXO36TqP3/mO9Z7TPyfEob7LHgTwhT5w3 AORpZHlCmuonTx3X8Z3IaDwVCMe08jY2eRK50daJSA29A1KfRYykjlgCj7KP+bKFPCFPnDcA5Kl1 /PjxX4hADYMEjoWFhUORpkuXLr0pfbE2ms3mnvlekywvr5nlpQ7Kj17+hz/84QMRpmzGJ8rYyP+j rFAvMxUKjkrWa7IjItYw1nsq2j6QNFOe5L1zZClTl/6+wd9JvY2e/Bn7Gu9/cmz6NsrVM155dRr7 sfrtv2i328fkB0Te+V9dXd3Uz33R5a9cufKKXn57e/vUmTNn7lN+cf/JJ5/87x/96Ec/HDYGPvro o/+PCx/AnMtTJFDDsra29juScZJALQKVV06yU+b7bGxsPDup8vKaWV7qoPzo5X/84x8fxBJj67YL 1usSEXpO2M0WSZCWTTKyRp4K1ru6HBlZpl6djtuxmVO2Lk/eV5c8M0vU2+dU5kmTpz6iltRl1Gns x7f/6dIPLm/cOBucz5fyzr+MU7Cc/8LKizyM8r2ft/JBLPutYWOg7bsFAHMoTzaCX1i3+3XJyWuR RNnEB6qDOWA8kRlb5qknFUa3WCg2HU3ANCTTlMiRpdsuT2gsdYWZolR33GjylBU1baxXfHxGnZb9 OHd1Z422U2+IbVAG6vy8z1p+YNLFM8x9mpCoeshTLD8WeXKjbFOfMUUpeTILe/0zT9l1wd9S3lZX xyZPxrajZJ60rFo686TVaWzDmKf5QLr0JNPEuYAi4VYFNZUnJKommSfrbDf7mKdQNvLkyRhT1Ail SM/uqECMBs2261OXlx0IHpVJZcvy5Mkc8+Tpxybjsbrl0nWa+7H0nnTb0XaQJwDkCXkaS55sEmUb lwEllad+k/+Vkdk58iy2eixknpAnAOQJeZqoPOkSReCphzyZY36mdxsD5AmQJwDkaY7lCaqDPOh2 b2+vVQZu3ry5GYj3QVn2x0a73T5Fu0GeAJAn5Al5AgIFAPIExETkaRzW1ta+wf1MYNbIODnzBpAA RSDtkHGbUDRyz7KVlZXXkScAAACAOYeTAAAAAIA8AQAAACBPAAAAAMgTAAAAAPIEAAAAgDwBAAAA ACcBAAAAAHkCAAAAQJ4AAAAAkCcAAACAKvH/AZDfex4+/DiRAAAAAElFTkSuQmCC --_008_BYAPR08MB4903CED7FFDB7D11EFDB49FAFAD50BYAPR08MB4903namp_ Content-Type: application/octet-stream; name="image003.emz" Content-Description: image003.emz Content-Disposition: inline; filename="image003.emz"; size=14597; creation-date="Tue, 06 Aug 2019 23:17:07 GMT"; modification-date="Tue, 06 Aug 2019 23:17:07 GMT" Content-ID: Content-Transfer-Encoding: base64 H4sIAAAAAAACC+ydC3QU153mS6LUakndrZIEuHkYJPEQQ9hBniUsdtpyIxisGROHENtRcrLB+BEc x0nAo+Dg9LLCZjzIq8mQOMkBk+A43rN4zMywkxDGjzbReJgMTtgsm+OTkJ2c4501Oz6xsxN2h3hH PmW8v69UV139UFcHAbI4Ls7Hvbf63n99/3u/qrp1/9WtKsuy7gFJMBvcUm1Z11aR8bcvr7Csk62W 1fq7719jWVXWx6ZWWWciljXFVDBpvWV9s8aybqb9ukB7fRydXWf1t9ZYGLCWgFaAufdUpau8YzqU q52hv1ezW32o7m6wE6huZ7racsjbwLL6r1uctqz55MRbZS8pyP9O2qqST4633/+vf9Zqq//wqkra 22nLivnN2kij4AaQBp0Adz1fxFtwgNk+Qz98Ujv9zZTbKcvm22zycQ8YBPJxQXrExoiPljU3PWX0 +O1pezQ/J103mm9L147m830a6sasvw117/1hvPuN+3d016etftNv4mAo/uTu7x79yd3vvY60q41W 8vU2IK6qozYCfX2tlxTkcddaAPz+6jd57PTfwv5OMA/MAZvASqD+66w+XdVZbdubI4Lyp6tM21ra mjxVPd4+BzX3t/7RvDioT2+F8E1AfZrfJ6V1Ukmdhen8sbkUYxVNW9Up/OkEOj9IrC/qP7aDTy1O yV8D7TN1yL4dTVdN6SGj9tqvvg5uGmuV/TE/OpL/rpd69aqqqnaQmZauCpx3lelgA+1WAIbAS0lG U+11tKPEZsZa7Uwe3qP6aWP/bPBJ0A3kU6F2VDZtz0c/i7ApDYuDtCQd9YDJoyXL+sSSn68AT0Pf +vn/ftg776WltZTTwOjkR3JS20tT1xgdmVS7lWdbyRCkTRvKnraWkGkF2u/XozSy/aLR+X0vh4Yu uH6qq7yxMccKpmbc5VYHSIJCbqaO9rcAjbXy7wNRMAs4oNfmXgOWB8p9lHspLwNm0zVUW4QdvfY2 +yY7Y68DN4Aeyj12n21s9Pg2y9mgDm3dKevATQAedq9t27roFvI7VsBvGSdEOdu99tU1N9mpmnXg BtBDucdeVhPkJ5vlbPTYQ/DL4mMWX7NwGwLHSvLbCR9jW/15NpTfMPxc+Lnwc+E2DM7m8ZPN8vz6 aZvBRgZbmZpeux/srCnVf6sZtCC/w5TL2e61n4ngcwTfI/RBpIdyj304YmxofGWznI0eO03bFDZS 2EpFein32qsjpfjZXMCMbfVfH+VyttFfLT7X4nstfVCL/kBfrbEhfrJZzgZ1aOvCz4WfCzerFv3V luJ3rIDfsmh52+gvis9RfI/SB1H0B5ZFg/xkszy/Ifhl8TGLr1m4DYFjJfnthI+xrf47G8pvGH4u /Fz4uXAbBmfz+MlmeX79tM1gI4OtTLTX7gc7o6X6b3VdPr/DlMvZRn91+FyH73X0QR36A4frjI8a X9ksZwP90TaFjRS2UnXoD6yuK8XPZk5vbKv/+iiXs43+6vG5Ht/r6YN69Af66o0N8ZPNcjaoQ1sX fi78XLhZ9eivvhS/YwX8ljWUt43+GvC5Ad8b6IMG9AeWNQT5yWZ5fkPwy+JjFl+zcBsCx0ry2wkf Y1v9dzaU3zD8XPi58HPhNgzO5vGTzfL8+mmbwUYGW5mGXrsf7Gwo1X+rufkF+R2mXM42+ovhcwzf Y/RBDP2BwzFjQ+Mrm+VsoD/aprCRwlYqhv7A6lgpfnY8n18f5XK20V8cn+P4HqcP4ugP9MWD/GSz nA18oK0LPxd+LtysOPqLl+J3rIDfskR52+gvgc8JfE/QBwn0B5Ylgvxkszy/Ifhl8TGLr1m4DYFj JfnthI+x7ekvlN8w/Fz4ufBz4TYMzubxk83y/Pppm8FGBluZRK/dD3YmSvXf6sZ8focpl7ON/hrx uRHfG+mDRvQHDjcaHz39hdhAf7RNYSOFrVQj+gOrG0vxs518fn2Uy/Pb5uCzg+8OfeCgP9DnBPnJ Zjkb+EBbF34u/Fy4WQ76c0rxO1bAb1lTedvorwmfm/C9iT5oQn9gWVOQn2yW5zcEvyw+ZvE1C7ch cKwkv53wMbY9/YXyG4afCz8Xfi7chsHZPH6yWZ5fP20z2MhgK9PUa/eDnU2l+m91cz6/w5TL2UZ/ zfjcjO/N9EEz+gOHm42Pnv5CbKA/2qawkcJWqhn9gdXNpfjZPKAY2+q/Psrl+W1rwecWfG+hD1rQ H+hrMTbETzbL2aAObV34ufBz4Wa1oL8Wwy9ljTyHXEeaBKtAF7geXF2Ve6YiO/oMT3Z0HYfpXUXr OItoxK1k9Dn8DPnTYPI8h+evv7GKujJs/e1b/3WTt/5mfNdz6XwfdJuGwN9yedXpABoL5bXxOOql C/hffaj9Jh/F0C2UO8EMMAdsASsBj1bWnqrTVXuqmPDXCsq/ux5nxi6ati7aepzGnu63fA0cVV5r skq97R24HifNzQb3gm4wop987UhLRns6902e6r/xdaCdRtKz1lvWkJ4CJ8DkuSYUrD/PinWfePY9 3XZ6xC9csdoA56jXr0pvAGnQCdS/raDKh0NqNhNfKCwHrh+evkY+h4d/7Gp2qE+dkQ+8/3kEyiuv p7yZg+q4Z8zFxatpWVkZYLOtmvZV1kZiSZ8kbnCvt0Y78kng/89VVU2huBJD2/7Nn9znfjjxx5a1 tG6o0bKerH3Eq+hWPWKdfOjL9931s8ib5zjWrZT9rT+YLrk59bmDez5439NXtQ2ctR6xqvj0Ocp+ ndGkY/0zN83HxrdfGKmrHlabp6+yrKfZf9fOD933jSWWtcs7zoPJ41MesXiEtjYi7o3Jr74t9zpj P9JQWK32+malT181IAm+3TkdawNVo/sta2R/+rsPJr+xxI7LjtrqmUPH+MaS+Gg7O26P2r2Dej3O L6bfsdUb+tFrtfqbQ3jjAx1LB9dYab/KyrNV38R/u8E8MBtsAr8N/KEhl9t4fLTW5opeziPFf+Kx yrqT0etj/D4BbmdE+9gzokn5Iw1GgO3nlaqsDjLpAvLihtv9i/y8OLf7eR1vDflWdhJOLHH+Ftw7 fa0uTo/cD+U7pvP17O2zrAtVZ2H6YsZ78rmn75vT/Wd/9PkJuQ6YY0srGjMHmG3irgM3zpiI68AV TIYKrwMj523Cuw4kz+M6cMUce6XOG7W1V1qWjnHFnJXeKafrh73S9j5Tn+v8G+914PPYWASWgtsB hyx5HeBePOZ14GN89n7O/M+ATd71wLIS7IuWgM75Ss/3FZzrSyo4340mL9S5XImdi3u+51/PmuvW rAp7FrhQsXid12Z8GL/Ruf/fsh8pWvWMhzRSAz4SO131kZhtP+oIyr879zdjdTHn/pMxFn8MvcwG MfTTPaqffO1IS0Z74537a74w2WPxM+N3eee9tLQWf9JA8XMSayJi8Ys4ru75ukbM98ElYsx1hg3U WeHXV6rNpFYFcXkdpwMkAbLJ24xOtL8FGF7vIx8Fs4ADdnAjCsblVQ6Ly+9IbLO3JzL2NvA5sIXy lkQuLr/Ft9mL/WXAbN5Nmv90j6MObd0p28B2wHHtHYniuLz4BOPyKofF5Xckrq7ZnkjVbAOfA1so b0nk4vIc27NZnt8Q/LL4mMXXLNyGQHFcXnyCcXmVw+LyOxLD8HPh58LPhdswyMXlxS8sLr8l0U/b DDYy2MrU7KC8I1EclxefYFxe5bC4/I7EMxF8juB7hD6IbKG8JZGLy4tfWFx+SyJN2xQ2UthKRXZQ 3pEojsuLj2Loy9GEA1Tuo1xubNBfLT7X4nstfVCL/kAuLi9+slnOBnVo68LPhZ8LN6sW/RXFvcVH MfQgv7C4PPqL4nMU36P0QRT9gVxcXvxkszy/Ifhl8TGLr1m4DYHiuLz4BePyKofF5dEf/Fz4ufBz 4TYMcnF58QuLy6M/2mawkcFWJor+QHFcXnyCcXmVw+Ly6K8On+vwvY4+qEN/IBeXF7+wuDz6o20K GylsperQHyiOy4uPYujB8e2jXG5s0F89Ptfjez19UI/+QC4uL36yWc4GdWjrws+Fnws3qx79FcW9 xU8x9CC/sLg8+mvA5wZ8b6APGtAfyMXlxU82y/Mbgl8WH7P4moXbECiOy4tfMC6vclhcHv3Bz4Wf Cz8XbsMgF5cXv7C4PPqjbQYbGWxlGtAfKI7Li08wLq9yWFwe/cXwOYbvMfoghv5ALi4vfmFxefRH 2xQ2UthKxdAfKI7Li4/Ws4Lj20e53Nigvzg+x/E9Th/E0R/IxeXFTzbL2aAObV34ufBz4WbF0V9R 3Fv8jhXwC4vLo78EPifwPUEfJNAfyMXlxU82y/Mbgl8WH7P4moXbECiOy4tfMC6v8llQzjb6g58L Pxd+LtyGQS4uL35hcXn0R9sMNjLYyiTQHyiOy4tPMC6vclhcHv014nMjvjfSB43oD+Ti8uInm+V8 RH+0TWEjha1UI/oDxXF58VEMPU9/lMvZRn8OPjv47tAHDvoDubi8+MlmORvUoa0LPxd+LtwsB/0V xb3FTzH0IL+wuDz6a8LnJnxvog+a0B/IxeXFTzbL8xuCXxYfs/iahdsQKI7Li18wLq/y2abyttEf /Fz4ufBz4TYMcnF58QuLy6M/2mawkcFWpgn9geK4vPgE4/Iqh8Xl0V8zPjfjezN90Iz+QC4uL36y Wb7/0rRNYSOFrVQz+gPFcXnxCcblVQ6Ly6O/FnxuwfcW+qAF/YFcXF78wuLy1KGtCz8Xfi7crBb0 N2Zc/h+tkbj8a6QXIy6vZ7k14Aw4DSZPDC5/LW7J11Kha3GFcXk9o1byvNxBvSQwz7o8SlLKrcdp v3nujQbW5rLsnwMUG1lJqrW5FxpOV73QYNtXNQnKv7s2Z8YuynpKij7qBGY95YvktY33ezKXIi6v c2mFxzaXSjWOv68wMZpRO5NHI6Nru8+yfzaYhn66SUf0k68dacm05dGu3+Sp/hvF5cWhHWi9Rusl uiacAifA5Lkm5Mfj3P/+wVUTFZc3x1a/qk8dYDYegfLK6ylvZoxVd1xxeeudGZdXDL4wHjcSP+v2 4nHWecTjNibtRxWPU1v7URPnf1TS9eL59qO295mq3AFKxePU39OBxgeKZePym/n8x2A2eAv8NlD7 wi3CjrUFOz1S/NfL/tXE4bZ6Efk7Lekg6gO2ZePuOlY7EFfZ0/nZimYqibsbLS5OX55x919+Z+2q iYq7m2NrfDQ2DjDbxJ3n352QuPvY79/sG8/7N82j7980m/dvmr1Tyou7N4e/f6OxqfQ8z1D3vwDF 3adwfq0kVfvCTeftWOf5x/hskbWOd6ju5NqjyPtvefdu+TEFqK3y5tzXfd3ct1me6F9EWVrScdv9 vDnnK429G10uTl8u53z+fP+bHzgcOt+/ULF3ZDA6PozZ6PzsLj7Q/P7PfZ1oHB+Yfrrqgem2/Tcz BeXfnd+bsYqmL978/lLE3nU+rgDaTDqe+f0n0M1sbP0FaTfpiH7ytSMtmWvDeOf3mjNM9tj7Ex/8 23dk7J0hrGgtwcTeVd9oyKSVxN7VzqxHSI/BzehE+8vF3g8mWadiwrmceg5QOSz2fjC5zT6QzNhP gP1gH+V9yVzsfZ9vsxd7y4DZvBs1/0XYQR3aulOeAAcAx7UPJotj7+ITjL2rHBZ7P5i8uuZAMlXz BNgP9lHel8zF3jl2aOx9X3IIfll8zOJrFm5DoDj2Lj7B2LvKYbH3g8lh+Lnwc+Hnwm0Y5GLv4hcW e9+X7KdtBhsZbGVqDlI+mCyOvYtPMPaucljs/WDymQg+R/A9Qh9E9lHel8zF3sUvLPa+L5mmbQob KWylIgcpH0wWx97FR3HyPP1R7kUjY2kH/dXicy2+19IHtegP5GLv4hcWe6cObV34ufBz4WbVor+i 2Lv4BWPvKofF3tFfFJ+j+B6lD6LoD+Ri7xw7NPaO/uCXxccsvmbhNgSKY+/iE4y9qxwWe0d/8HPh 58LPhdswyMXexS8s9o7+aJvBRgZbmSj6A8Wxd/EJxt5VDou9o786fK7D9zr6oA79gVzsXfzCYu/o j7YpbKSwlapDf6A49i4+ipPn6Y9yb3n91eNzPb7X0wf16A/kYu/iFxZ7pw5tXfi58HPhZtWjv6LY u/gFY+8qh8Xe0V8DPjfgewN90ID+QC72zrFDY+/oD35ZfMziaxZuQ6A49i4+wdi7ymGxd/QHPxd+ LvxcuA2DXOxd/MJi7+iPthlsZLCVaUB/oDj2Lj7B2LvKYbF39BfD5xi+x+iDGPoDudi7+IXF3tEf bVPYSGErFUN/oDj2Lj6Kk+fpj3Jvef3F8TmO73H6II7+QC72Ln5hsXfq0NaFnws/F25WHP0Vxd7F Lxh7Vzks9o7+EvicwPcEfZBAfyAXe+fYobF39Ae/LD5m8TULtyFQHHsXn2DsXeWw2Dv6g58LPxd+ LtyGQS72Ln5hsXf0R9sMNjLYyiTQHyiOvYtPMPaucljsHf014nMjvjfSB43oD+Ri7+IXFntHf7RN YSOFrVQj+gPFsXfxCcbeVe5zQvXn4LOD7w594KA/kIu9i59s9pbRMHVo68LPhZ8LN8tBf0Wxd/FR nDx4foTF3tFfEz434XsTfdCE/kAu9i5+slme3xD8sviYxdcs3IZAcexd/IKxd5XDYu/oD34u/Fz4 uXAbBrnYu/iFxd7RH20z2MhgK9OE/kBx7F18grF3lcNi7+ivGZ+b8b2ZPmhGfyAXexe/sNg7+qNt ChspbKWa0R8ojr2LTzD2rnJY7P1gclsLPrfgewt90IL+QC72Ln5hsXfq0NaFnws/F25WC/obM/a+ i4etLvQ8SHoxYu96llsDzoDTYPLE2fLX4pZ87VDoWlxh7F3PqPN9sKR2LVl/y+VVp/BZl0dJr17w Wdfko4G1uY/TuVqbO0K6krQGvD7tdNXr02z7o7ME5d9dmzNjdzHX5i5F7F3n0gqgzaSVrM2pndEP Ghld2/23fKC1uadJu0lH9JOvHWnJtOXx9bxj7+LQDrTmb9b5T5E/ASbPNSE/9r5nw5FV97Stn5Dv wppj6/qhPnWA2XjMyyuvp6zYu8bgcoy9j/1d2JbxfBf2esWvvO/CXm++C3u9t9TnxeSuv7Dfhd3J sT7NAC0kfZJU57fGtnATp7UFOz1S/Hcr+9cTidtE7P0P+C78vXwn9l72BeNwNuWID53vUT9vzvFg bE56aQfSlzlnV7Czku/FGn0uTl+esbmhl6tWT/T3YmsRiO7/a0lXkmo8N7eertrcatt/OV9Q/t37 vxmri3n/vxSxOZ2Pui5oM+l47v816GY2tt5P2k06op987UhL5tow3vu/ngMme2zuhVvrvfNeWtJ1 OA3Me5zvfi925F4hnZaLze1t5zmWG9Fy6jlA5bDY3N72bfZX2zP2l8AgGKA80J6LzQ34NnuxtwyY zdwbdc+jDm3dKV8CXwUc197bXhybE59gbE7lsNjc3vara77anqr5EhgEA5QH2nOxOY4dGpsbaB+C XxYfs/iahdsQKI7NiU8wNqdyWGxub/sw/Fz4ufBz4TYMcrE58QuLzQ2099M2g40MtjI1eynvbS+O zYlPMDanclhsbm/7MxF8juB7hD6IDFAeaM/F5sQvLDY30J6mbQobKWylInsp720vjs2JTzA2p3If F7dy2kF/tfhci++19EEt+gO52Jz4hcXmqENbF34u/Fy4WbXoryg2Jz7B2JzKYbE59BfF5yi+R+mD KPoDudgcxw6NzaE/+GXxMYuvWbgNgeLYnPgEY3Mqh8Xm0B/8XPi58HPhNgxysTnxC4vNoT/aZrCR wVYmiv5AcWxOfIKxOZXDYnPorw6f6/C9jj6oQ38gF5sTv7DYHPqjbQobKWyl6tAfKI7NiU8wNqdy Hw9tIfqrx+d6fK+nD+rRH8jF5sQvLDZHHdq68HPh58LNqkd/RbE58QnG5lQOi82hvwZ8bsD3Bvqg Af2BXGyOY4fG5tAf/LL4mMXXLNyGQHFsTnyCsTmVw2Jz6A9+Lvxc+LlwGwa52Jz4hcXm0B9tM9jI YCvTgP5AcWxOfIKxOZXDYnPoL4bPMXyP0Qcx9AdysTnxC4vNoT/aprCRwlYqhv5AcWxOfIKxOZX7 QmJzXP/i+BzH9zh9EEd/IBebE7+w2Bx1aOvCz4WfCzcrjv6KYnPiE4zNqRwWm0N/CXxO4HuCPkig P5CLzXHs0Ngc+oNfFh+z+JqF2xAojs2JTzA2p3JYbA79wc+Fnws/F27DIBebE7+w2Bz6o20GGxls ZRLoDxTH5sQnGJtTOSw2h/4a8bkR3xvpg0b0B3KxOfELi82hP9qmsJHCVqoR/YHi2Jz4KI6WN/+j 3Mscbay5G/pz8NnBd4c+cNAfyMXmxC8sNkcd2rrwc+Hnws1y0F9RbE78grE5lcNic+ivCZ+b8L2J PmhCfyAXm+PYobE59Ae/LD5m8TULtyFQHJsTn2BsTuWw2Bz6g58LPxd+LtyGQS42J35hsTn0R9sM NjLYyjShP1AcmxOfYGxO5bDYHPprxudmfG+mD5rRH8jF5sQvLDaH/mibwkYKW6lm9AeKY3PiE4zN qRwWm0N/Lfjcgu8t9EEL+gO52Jz4hcXmqENbF34u/Fy4WS3ob8zYXEf1SGzuPaQXIzaH2csiNheL vP0bx+b0jDrfRyWxOdXXxvOkl5o1Ee03+WggtvIWH2htTn9jcCWp1lZ+Nvd01c/m2nbPAkH5d9fm zNhdzLW5SxGb07m0AmgzaSVrc2pn9INGRmNzLvrR2pz+xmU36Yh+8rUjLZm241mbE4d2EFznP0X5 BJissblsd83qiYrNmWOrX9WnDjAbj3l55fWUFZtT3csxNrcxOdb3YnvG873YxxXT8r4X+7j5Xuzj 3lKfF5t7nMVF//u2d1BtvN+LlY1pDNBC0mtJdX5rvAo3jjpmbO4mPns/d4IPgQR56YBz1kvNORyM vcl+Owiek/egk1tB8TmZ/66K0d/i9OUSe6MjrKEXQLdyD6/+WvfRj+9ZFfZ3QznT0qqv9Pgr/+d5 5UyqPF8l9/5u6NR0Vb9DUeMnEbWRRsFtQP1Pl1c0VzDjqPpm/Vt5sx+bo9f369jfC24AV1GphvQg f7vkIH//79dTBOXtFtNW1/dSNmnWP5//BLIrvaQgX015DUhynBgo1k/+ew3GRiX6WZgeuZ6p77Qt SOeXx/d3gWWx1Lhb5/0bGuP5G5/qxxWixGbS8dzjr8XOLeD94Hcq1IDRA00qGvdFVJSGjQbmcxzp YLJqYMvTn171heejFZz7lk4xbdeZc96k3t4xzv3AuaTh8bf89/XMGNCNoef5P1CnF/wTGAA6z1/i txxBzdwRKB81Nt89z/n92tExvjzO8//BmOs8/xV4GFSiAaMHqp/Xeb4acepdnclznufPYXSP/+tb z3aP97lwCR3YCqoL/vbzwkdefH5p+vnrlGoe8E64L3wYnrr+/B74DNCPbd8LdO1mLlD7cNyuNbrQ dcLk+fi8NDL55gNjaaR6SopO6AQaZzMXWX7/c9c9s+vKo2//6YveOKt85Lc6nzf7GfcdU9PVo3M/ mr9t7pecOt5YaDzo3jHvBR18mgSqH9zM2Gh/qXlbFKO6JkifPwV3g/8JtgLx74sfiszlN5P74h8B hyLGnsa9lD2aVKSBNVQ8A06DyXptmP3Pz3VfX/2D7vr0iM/qf83bvTH44n+41vqz269Nv/mH11m7 ol2L+Ezzn/MdT8zSOjeHlx0zFmYMO9l3B/gkeBHcB2rAysj+yMrIp2p3xQTl9+eNo7FD1YrGrp2K 8kW+ahxPgRNg8oxj/nPGPdEXu+/7h1cn5P1pc2xdW9WnDjCbns0dUyBdDzYz8Kr7ayMI//Pdnuh0 zhb/TbF0zSPWqSeX6LVeT3+dZx9MRsFm9keuWvLpzeT/I3l0ZGk/I9s0EX9LaOzfNPrWeH7TaEYd fnXqt8tmmN80miHpjvx22YwL+5tGxzjWnUDX0eNA11GNV+E2lR1rC3Z6pPivj/2ruOPeyXvT+kti t1iftT7HXya6i/y93pvVWyjf6b1bHaHuFKBU57rJm7JSO/B5MF9YR23NtSDOtWARZWlS/Nv9vDiu IV/pGpDR9+L0yH0McbHln3/eLv67UHUWpvOf/RcUlC/kWsAHOo7zHHgXz4FTpvTgQwro3q+xyN/S /nNgutxzYP/U9JTReYD6ug0jUXAb0FjoHJ7vg34ccz5gxlH1S92nsend9zv5fCeVvkmqa8gvSMX9 Lb5r+xbfl+/xoPzOhLF5Ie79k2/OR6cE1oBy4z6eZ8Mp3vVd56S2SsZ1A/VWAJ2TSrWZVOpwvD3F /5mxUzuTZ5xHNfAgY7+fz75M+hopn4VqwNihakXzhkVUNNcTXUMm+xrQnh82rP7C8+sqOPf7u3CX rb/LrP2Y1Ns9sgZUdO5XogczBgxb6Hk+j8F/mnpLSf8bqcb4dd57ep13x5Z7UN6OG5vvnuf8befR Mb48zvM2xv4I434V6Y8r1IDRA9XP6zyf7GtAutZv7OzmPD9/DWh+sIQObAWaH9D9o5vWfv7v2qcD a0ATf1/4MOx0/fkiFxbpZTaEnyUVb+YCDY+37WwwutB1wuT5+Lw0MvnmA/lrQDmN2CXXgIYfOuKt Ab1w5Jg3ziprDcjsH1kDskfnfvTjhKwBJRngb3Pw+aRHSTU3GWxb6t0fBtt+1qC8GesLcX84g/3T YPKsHeSP+1/844lV86r+1ar69Ijuk/iiebvux5a/BtT6z3sv6RrQYxz8Lzn8VMbwe6Q14NyMOQ3n Zrze8N42Qfk5eeNoxpSqFZ2/7VTUXE6+ai53CpwAk2cc859Bq5ecXPXcmfetstMjfuEKf/V85Nlr tp8qRp4GnUB92groag8Oqdl+078rb47NcHl96hhDpPUgWF5PeTMHVd2LuwZ0ZEJ+13rs79DPHM93 6G/UGpD3HfobzXfob5R0R9aAbgz/Dr36ezqQ5nWON/t5jb/K2s/m/V15Xc++yQffJm2moa6jal+4 sRw15hpQP58Vf4e+1cpfC2otWA1avTFCO2lT0HqOrt8m1T6VxUX1DLTPtAt+rvpmv1JjawF5+Ru2 RvR1+mA3KL4m5F9Djf4Xp0fmHOpPLkP+ekl+/kLVWZi+eGtEn1jy8xVirU35X/46unpj50e9+eNa 9qWB5oAk4/gbtjVjziet44f+7qcPH3xR6UhMsSZvnWERx9X4SbttIApuA2bffPICYzDm+pJZh5AN 46xJreoqz7ZnouA/ox216wBJUHhumDrab9aulH8fENdZwAHL2+GMCJf75e/jjMq9lJcBs3knOv9J wy+0xeJH2+qADaz4C21u7PvA2JBNl44oZ+MavjPUxXeGunhW7mqvi1/THosvB+qsIL+tPh9jO1IB v2r4nWutAzaw4tVwiwT4yWYYv/upvx3ftuPjdny9H5tbQSG/I635/bfGL5fzvbs1Fu+CXxf8uuDX 3erG1gDjo2yG8XuW+kdpexQbR7H1LDaPgEJ+b8zN5/eQXy7H74G5sfj2uXUA3+da8QfmurGHgOEn m2H83qT+Odqew8Y5bL2JzTdAIb/lBfy+P6cC/c1Bf3PQ3xx8n4P+5qA/YPjJZhi/a+DXBb8u+HXB 7xq4LS/Bb6vPx9iOVMCvGn7nrkR/V+L7legPbpEAP9kM43c/9bfj23Z83I6v92NzKyjsvyNX5o/v Gr9cbny7r0R/8OuCXxf8uq9Ef8D4KJth/J6l/lHaHsXGUWw9i80joJDfG7Pz+T3kl8vxe2A2+puN /mbj+2z0Nxv9AcNPNsP4vUn9c7Q9h41z2HoTm2+AQn7LC/h9nwtj6PVvFvqbhf5m4fss9DcL/QHD TzbD+F0Dvy74dcGvC37XwG15CX5bfT7GdqQCftXwOzcT/c3E95noD26RAD/ZDON3P/W349t2fNyO r/djcyso7L8jM/PHd41fLje+3TPRH/y64NcFv+6Z6A8YH2UzjN+z1D9K26PYOIqtZ7F5BBTye4MJ YvD+9pBfLsfvgRnobwb6m4HvM9DfDPQHDD/ZDOP3JvXP0fYcNs5h601svgEK+S0v4PdWMlx/w8lY /NfJOmADKz7Mb+O+BQw/2Qzjdw38uuDXBb8u+F0Dt+UBfin/PnwdKZS8NawfkS5gEvFjUjOnqNI+ EANso2tYteQDc6CVIx97VUbzmLIWAbWVnTVgLZk0KJ7vnv9cdmH64s1TLf89dqizDXUH56nqw05g 5qlfJK8t/G8D1kzR3Et9o7Z69tDGOtf39A4U61/f03qnylr/KjU/DfS9JOdvubmo+n4DWAHU90q1 mVR7HW9P8X9mvNXO5GsY7w9TFmetd75IqmeXU6Ti/+SMQ2jUjj854yN5sRHTnirnpZczNDwNJqte rj38Mmtfv1t67euOw977T/3XvdAVfP9JY1fJ+HZQLwlUXxvTdy81fa79Jh+l/2+h3An+zh+/X5L+ lDJja22dvT+2dfan4s/PEZTfHzNtda6bPFUrGsd2Kuq813OFznvp5ASYPOOYfz366j+9wtrXhyZk 7cscW+OpPnWA2cZa+2Jox7X2tft/PZi8C5j3n06SN+8/ab+OPxHvP23kyKX/duMHvLUv812yVnt9 szg+fdWAJOitYbUNVFlmP2/4e/vT330wyd9ufLJOlfX+05PmO2pPjrazn7S9z1TlDlDqO2rq7+lA 46PO0cGV136VlWfz1r4+T+Y4H/yAVOfgT/QBKNw478Zc+/oYn+Wvcy1bEWGfoPPZQGVdn835G+f8 XUTZcGv383J2DXld03eD4vM0fz3KaHJx+vJcjzq28bZVGzubL/B6VKTsetQv//5QYD0qUnI9Sjpp A1FwGzDjWMn9wswHZGMF0GbSStaj1M7cc5BI3mb0pf1m7qj67wPiyiOJ58/cBLEydiz3y4cQpMq9 lJcBs3knH/9Jv0/FB6MH4gNgJ+iPPhXPRA8BY0M2MyE25iUy0Y5EP9gJBqLzEoPRuaBwvr7B52Ns /4oODuP3Wmww+mpsAOwE/dHXYpnor4CxIZth/G7Hn034tgkfN+Hr7fi8ARTye8znY2wvrYDfYvh1 wK8Dfh3wWwy3pQF+shnG7wnqH6DtAWwcwNYT2HwMFPJ7uSF/fD/rl8uN790Ng9FNDQMA3xv6o3c3 ZKKfBcZH2Qzj9wr1X6Xtq9h4FVuvYPNlUMhvbgG/Q9xAw8b3qXr0V4/+6vG9Hv3Voz9g+MlmGL95 8OuAXwf8OuA3D25zS/Db4PMxtn/FjSmM32t16K8O/dXhex36q0N/wNiQzTB+t+PPJnzbhI+b8PV2 fN4ACvvvMZ+Psb20An6L4dcBvw74dcBvMdyWBvjJZhi/J6h/gLYHsHEAW09g8zFQyO9lrgPqL8Pv s365rP6i6C+K/qL4HkV/UfQHjA3ZDOP3CvVfpe2r2HgVW69g82VQyG+uz8fYPsRNXnzL8XuqFv3V or9afK9Ff7XoDxgbshnGbx78OuDXAb8O+M2D29wS/Db4fIztX0XC+b0WQX8R9BfB9wj6i6A/YGzI Zhi/2/FnE75twsdN+Ho7Pm8Ahf33mM/H2F5aAb/F8OuAXwf8OuC3GG5LA/xkM4zfE9Q/QNsD2DiA rSew+Rgo5PcyEy+Np+H3Wb9cbnzvrkF/NeivBt9r0F8N+gPGhmyG8XuF+q/S9lVsvIqtV7D5Mijk N7eA3yGmtuJbjt9TNvqz0Z+N7zb6s9EfMPxkM4zfPPh1wK8Dfh3wmwe3uQF+Ke7z0LDMetTvkX8I nAYPAzOn0PxiAeCWpW30uRSJVfRcuohGaqu5yRqwFoNpUDzfzX/+o6q3LU6Hz3cXUsehNl3rbQvS +eXxvVufPw8PzlPVh53gN1+PipRcj+K7d956FN/J89ajVM6tR+XPT+dzXIFhkOT8LZdXf5edf1aw HiUbZuyR3Oh6lLSyA3wY7AZ63rm5ZmmU32eI3lzzs7zva5v2VDkvvZyh4WkwWfXy88eP8H28N8t/ H6/pjy/pu1gb6U+N3wnwJ4CxtaZH5kSnR16PficmKD9nXOPYjk2d9+Y59xR5HW/yjGP+9WjJX/1N 93NnGiZkPcocW+ej+tQBZmOqmVdeT3kz11fVHc+7WLdaO5MrgFmP+iZ5sx6l/Tr+RKxHfWNJ8XqU 1qg2Jv/UW4/Sd+rEzaw7VbIe9Y0lditT4pHv47Wa7+O1eo/EndO5r7Re2O/jneRYt4EHwA+B4hga r8KNQ4+5HvV5Pltn3cM37u7gb5rcaYW9hRWhvo6hc115pYKu3aasVPdQU1ZebVQ2+0yqz4QFQJqM c31f5OfVpt3Pm/N/EE32g+LzP//+arS+OB1+379QdRZyLAe+8kfbxZ4//PWtx8b52w3VY65rKY5l 5g8jcazqPN/a8C8KbgMaN4bEm0fMJ2WELulcQsfUXOIWcBp8FEg7+u0X/daT0ZbmmibPx+c1j7gc 5p3j103pOGj5eWf+e3oas4nQiq4t0soHgeadtwJ/3ulphXnnBdXLGexLk8XXq/x5AVW8rZJr0cL0 pbvOuHN+yrzz0bLzzv5/v8qbd1Yypub80/XC5LmOjMY4t7BfY/Mc0HNHDZhZO6dmZu3rNYcaBOXn jGuMCu8ppzjGCTB5xihfO2uXneY3Hv5qQn7jwRxb11vdBxxgtos1pzz1/x5M/mdg5pTJf8nFOLXf sr7zDnu/v2087/ffrDml937/zeb9/ptzc8qbL+z7/V/nWPeC9eBZ8HGgsS3cmKeNOae8i88+ba22 buSXOFutlfzO0me8X3n4DL/zcCefyR/N/7gfe+e37KtsoHNeeaUGC8hLXxdqfmh0uzh9ec4P9dte GzsXj/N7nXbZ+eF77RvSud/2st/x88P96OffceP5Fqk0x+991X/nCrveaOtCzA8n+3c9c7op/Xtf K9p+P6133a68+oPe2KustUWzn2eFHe+E3/vaxjg/yhj/Iel/IrXB/isO1ek3P/Zf8RFwqC447i18 rusL1UfnJWQrekZYQ8UzYDLP82q+voT33aaVft/N/N7XJV5f/DZ9uhdcyaAcINW94D0N++ve0/Cp +uNNgvL788bRjClVKxq7dipq3M36wmSfC/75wn/N+27zJmR90Rxb11b1qQPMdrHmguHvu10/IXPB sd93u2U877sd0tzJe9/tkHnf7VBuLqig4AX8TfaTHOo7QNfR2f51VGNbuE1nx9qCnR4p/vs8+yfT +uLX8XM3KH4WzF9fNFq/XOaPhd/r/JcvvLBqY+e9F/g9urF/J0Tf57znD5b/IPe9zvzfCVmEjsz9 uY18FNwW2FfJ2oOJYzK8o+/PrSDvbZfoe509SeL2vPe2nIM64NQVI+Ve8suA2cz5E2HHS1cMJk5e MQB2gv7ES1dkEqeAsSGbGWyWs7E2mUmsS/aDnWAgsTY5mOgBWqiNglnAAbt8PsZ2sgJ+U+HnwM+B nwO/qXBLBvjJZhi/Qervpu1ubOzG1iA2d4FCfsen5/dfr18u5/tN0wcT66YPAHyf3p+4aXom0QuM j7IZxu8E9U/S9iQ2TmLrBDaPg0J+0QJ+e6aFj+9Xpg0mdk8bAPg+rT/xlWmZxB5g+MlmGL8Y/Bz4 OfBz4BeDW7QEvx6fj7F9amo4v5emor+p6G8qvk9Ff1PRHzA2ZDOM31r8WYdv6/BxHb6uxeceUNh/ u3w+xnayAn5T4efAz4GfA7+pcEsG+MlmGL9B6u+m7W5s7MbWIDZ3gUJ+x3lQGAycv71+uaz+WtBf C/prwfcW9NeC/oDxUTbD+J2g/knansTGSWydwOZxUMgvWsBvT3P4+H6lGf01o79mfG9Gf83oDxh+ shnGLwY/B34O/Bz4xeAWLcGvx+djbJ9qCuf3UhP6a0J/TfjehP6a0B8wNmQzjN9a/FmHb+vwcR2+ rsXnHlDYf7t8PsZ2sgJ+U+HnwM+BnwO/qXBLBvjJZhi/Qervpu1ubOzG1iA2d4FCfse5SA8G9eeX y+rPQX8O+nPw3UF/DvoDxkfZDON3gvonaXsSGyexdQKbx0Ehv2gBvz2N4eP7lUb014j+GvG9Ef01 oj9g+MlmGL8Y/Bz4OfBz4BeDW7QEvx6fj7F9ir5Uf5brv5cS6C+B/hL4nkB/CfQHjA3ZDOO3Fn/W 4ds6fFyHr2vxuQcU9t8un4+xnayA31T4OfBz4OfAbyrckgF+shnGb5D6u2m7Gxu7sTXIv12gkN/x eIH+/HK5/rspjv7i6C+O73H0F0d/wPgom2H8TlD/JG1PYuMktk5g8/j/L+/cQuO4zji+sfYyklbr 0SXu1rRqJHRxRKIopbR9cOjiBKHCBpYSXx7kXNQ4lDo0olUggTwo2A1K2dJt8IP7EBMohNI8uA/F eenFFJOKdh8WqjYqfXGMCQHTVFBI2kJKf//Z+bQ7syvN2itrI3fgv+cyZ775n/N9c+Y7M+fsgDA/ J8TvPE5jlH7PpbG/NPaXpu5p7C+N/QHjJ5lR/NLwc+Hnws+FXxpuThN+cz4fk73OHPQofmu92F8v 9tdL3Xuxv17sD5gMyYzil6c+BepWoI4F6pqnznMg3H4rPh+TnW2B3xD8XPi58HPhNwS3bB0/yYzi V6R8iWNLyCghq4jMFRDmt8qDBLWX8Tvhp7e1vx7srwf766HuPdhfD/YHTIZkRvErU77CsRVkVJBV RuYqCPNzQvzOM2AX3+34nevG/rqxv27q3o39dWN/wPhJZhS/NPxc+Lnwc+GXhpvThN+cz8dkrzvR /NYc7M/B/hzq7mB/DvYHTIZkRvHLU58CdStQxwJ1zVPnORBuvxWfj8nOtsBvCH4u/Fz4ufAbglu2 jp9kRvErUr7EsSVklJBVROYKCPNbTYXsz0+fiG09fnsshf2lsL8UdU9hfynsD1gdJTOKX5nyFY6t IKOCrDIyV0GYnxPidz4Zrd9zSewvif0lqXsS+0tif8D4SWYUvzT8XPi58HPhl4ab04TfnM/HZK8n ovmtJbC/BPaXoO4J7C+B/QGTIZlR/PLUp0DdCtSxQF3z1HkOhNtvxedjsrMt8BuCnws/F34u/Ibg lq3jJ5lR/IqUL3FsCRklZBWRuQLC/FbjQft7y09vZ39vxouZn8ZfBWfBcubN+EuZt4DVUTKj+JUp X+HYCjIqyCojcxUYv8PYP5dZ7GsgC74O3gev3FX9z22GEJvPb8b9OMHmfCxMrKXn9Yfq5MwS3+vz seqfs6kNZ8DNrwPoaroOgHdyl/13dZf1nlbp2jqA4PO1Mc4roAap1N9q8X3kPAG+ClBp4/Mzcl3y m22mbx1ncS6JwDqA99h3HGyALsA6AGz0bIb5WBk7RjZicYrckr1I/nXQ+Hw3OKeGIt42lau2i2ya U8q8/a0Wn8hVn53F/T3jofROrhtZXHiU93Qnm7+n69D/UvyZekt//wH/AOg2dqxvOHOs70bm9f2C 4sNt6XEUmbi5d8x7unvePcp7utMdeU9n59Y1rTZ1gW24moH0N0gvcuHq2m1nHUD2wzPZjb/X5myd IG3rAJSv83+61gH8op11AJO4xNV1AJO2DmCy9p5uMnodgNr7AJB+1DgDflz5SiufbfN/Kf5C4hrQ NfihdoDwRv+55Xu6efYF/5finx8nyRN0PRuUVv88DsShj07xkB8Xt1E/rsrOEi+SuQwa+9vg+zSz yalcdH+7U2V2s9/WvJqZ7PfbnI+19f9Q6P4e/NZicJ3fCLpwwAKQ3qSrMR9oaFfv+Tqv/MP/gr8B Xr3ZfCyX7y+6Zls7cb+/E+ZjVe2m+X/v23cWt//+YnzZpZ19/2Tzv/fVR7RiA3RhXp8T7lNMT8pv 5t9jb9687vvY/y5Q33QNJNG3uPDNxf18f9Hl+4vg4n6TJ703k8chLfl86nc2wHXQ2O/U/DbEbfpz rfQpE7nd8/PWXvztkbG7nm/u5/nzsd6YfTmw3vNW9UlXTUvV+nTJMV2YDmfIOwX+DX4PUugwQXgy eWH/yeRp99m0oPiFgB5NDkVb0t0oBdU/2f1jnXgZ7B091mxK9jX2o/KRx//1ckf8PDu39Kk2dYFt t8vPi17veaYj87G2/u/9Q+3MzZ+Xn+fNzZ+3ufnzMl3vf8vi89Fz83UfPgCknywY8OPKV1r5bJ6f d4XIM0D96DtA/ah0G96GyMiHMj1S/CyRP8tXVL8Dvhf7Vsjn07/y176/qOtb8pN+qLSgtFCfVjzu 59k+C5UvjAPVJ8pnfJZ6PQkar/mgz2j2PZW7U3xGGqfuO3z6RvtvHj+Pz7iva449h4GeDamtQ5vd x7b7/mKsfl627GEEIQ5YANILTd6SP2B6lG00u08j07vvz7D/PSDBGpM8SCjua5n4IHB17weKD5rM nbj37z2fT410+XfgiGI1vcf2SeczQHon8NZ4K4z6r9q7c8H1umMcI6CaXfP1j3G2GXAVyNfXs6Ev tmgDZg8c0pLfcIiCZsOzxPf6d9mq48Uftzle3H59d3C82Hl7OY7eZKMaGx7ATmTwBwnVz/AsuP8H fWf7zS7UT1ic3bdkI3uvnwje/2o20tX0u2ytjQ1r3+SlHTs2NhxAz9cgMEwoX2Gp74F+1u/3L/X9 FTwQ0Huze06rNqC+YQNcB43+RdB3p4i3TeWi/YsJyriUFndt47lgeiffATwy+faR15Zf2XZs+OQT xV0dGz5FnfvR3R8Jv0CYIDyYHO4/mLzRfzEtKD4c0OPNXr+jyFQfL99FelwHZbB39Bi0r3OHrzA2 /GFHxoZ2bvWtalMX2Ha7xoY/u3Emuwxs3fYHxO0dgPL5GmdHxoZbr9U52c5anUsaG3prdS7ZWp1L Mt3q2PASPUXEWh0uo5bHhroWFoD60T8Qqh+VbsPbZ8jIhzI9Uvy8RP7DrP4+FXsqtsTvw2CJceIz 4Jt+XnCEuHgqyTFdQKGu+fq47VOeID4qI6ifVGjH1Yfap/LjQLYZNV5s9R2D2Xwr/flOlZnIBe8D t/O+UPUHXm/TZ0x13Ueb3wM05qi3ocZ3DKnAPW+EYxwgO5TeMEHPnxsjxEXbtXHHcf+88iOnISE/ UuMO1YU134O8YwiMN83O2P1/7EfKbhJt+JGJZZcG1LXL1jE/cgo9X4PAlwnFhfcKA3rGwDsGcHHA dJ1C14PsNzu1fLJasoFZCm6A62Dv+B/B8cPS0p/wI1/b1o/MzT66q37kc7Tnveju14RfIUwQfpK8 MPBJ8vRguVdQ/EJAjzeru1FkSu+670mPuneWwd7RY9CPvPLqVfzIn3TEj7Rzq29Vm7rAttvlR77x 0ZnsC8D8yKvEzY9Ufiz27Y74kVv/p+Tb7cwlmZYfOaNvnEzbXJJpz2WbOUAfN72zc0l+ybkWgfrR XxGqH5Vuw1s/GflQpkeKn0XyjyLl6To/8rsNnuQj99MHB3xA9de63s0XVNp8x638R7v2o3zENWSt gsZrPNgnmj1P5aLH/DtVZoJzuXBTfbU5OSeOEXvXkz33pf7ul3KOl6cyIyoHFoCuO9Tk6eNpws+C z4OjKO4hdlj6IdIjpO+N/Zy9tgX7EsvdKhxlh84nXavv/Bxwgdp1X666j2QsA4YUYXOB4v8D+bjq rFwUAQA= --_008_BYAPR08MB4903CED7FFDB7D11EFDB49FAFAD50BYAPR08MB4903namp_ Content-Type: image/png; name="image004.png" Content-Description: image004.png Content-Disposition: inline; filename="image004.png"; size=11835; creation-date="Tue, 06 Aug 2019 23:17:07 GMT"; modification-date="Tue, 06 Aug 2019 23:17:07 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAk8AAAEvCAYAAABc2yWpAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAC27SURBVHja 7Z1/iCXHndgfYmXJsM7NyiutLK+lBcleoV8eSSut0sh4QMsgjolZn1nGSOiyOKZisFmWrI9RDo4d /WNPEoFacI5xMIwRRtJFZAWGa9lxuAlRwALjG3IJnEKHTC7gMzh/7CmKtXYUqdPffq9fV9er6u73 Xr/X/fp9Cj5aTU91d3W9etWf+VZ1de+5557rAQAAAEA1qAQAAAAA5AkAAAAAeQIAAABAngAAAACQ JwAAAADkCQAAAACoBAAAAADkCQAAAAB5AgAAAFgcebpw4cLd58+fXyvi6aefXo/TReizsbHx1bI6 E7a2tlZojNWQuqpSp1L3tMEM+W6W1Zl8x2lj1VFKPVZWp5ubm39A+8v4whe+8IdVvr+0Lzc7Ozs3 0gdO1Adu1NkHVr1h3Xr48OFrp0+fvlrEqVOnfvfQQw9FDz/88Ifw8Ierq6sfPvroo/+7qM7uueee dz/72c/+BZ1CNaSupM6K6lTqXOqeNthHvpPy3Sz7/sp3XL7rtLNyYik6e/To0dI+Ma77D+LPgD5R 6xPjenmnqM6OHz9+TW52tDM7n/vc5/7VnXfe+Rv6wLH6QPn3/Tr7wEof1qVLl07cdttt70ak2tPe 3l508uTJfTqFakhdSZ2R6k/yHZfvOu2snC9+8Yvnn3rqKfrEGaTLly9Ha2tr27QzO7EYvba7u0tD abgP7Kg8hZGvvKjX68WoKAjbW1LkCXlaxI4DeUKeZpWQJ+RpEfrA2clTGETKSwUmxlORPxOJic+T StJwk8rO2/Pi81rytCQhT22Sp1i6vZ7Wdvp4ngh4XY23vW0ReUKe2pCQJ+RpEfrA2chTTl50prth hH5fxrychY3ejALVM/LVd8Oyl2HyhDy1X55SVC22gzwhT6SihDwhT4vQB85AntKbQ0x8t0kVIwz8 SHmzkCdLCVSdN7vJylA1IU9tlCdPi5KGcXvyapH/LnUcyBPyNKuEPCFPi9AH1i9Pw6hTwY0mDOKb VNGQ3uAm5vna3CVXJED/S94SOYiPEVr/2g9zx/YGohfEcuTl9k/LZo9KDAWt9JrsCXlquzzlP/vy z9uSV/9eKFW5LU7appAn5Al5Qp5ICyZPaWSm5wz7aJEp55Be8fDJ9PLkEiFH2ZJjFMlTlWtCnhZX nsyh4OLP2/YdyKKhU7bFGUa/kCfkCXlCnpCntspT+hd4IiT9m8foMJv217t2Fxt3zlN2PCOPHh0L 0zJ4cf5YkYJsqDE+4cixrWWodE3IU2fkqfTzNtpb3I684c8V26KavE0hT8gT8oQ8kRZMnsqG7YZy VTgh134Tq12eLHeh0FeR57n/2reVodo1IU9dGbar8nnrbTDfZqq1xWnaFPKEPCFPyBNp0eTJMWG8 v3RBfMMY+au9+k2sdnnytL/2/eyvfS/dceLIU/WEPLVdniwTxqt83kMp8o1jjtcWJ2lT8+g4kCfk aVYJeUKemkqNL1Xg/qtZH7aoMufJLk/uOU/pfatEnhxlGN6weuWRJ+Y8dVmeyiI+VT5vI89Qgiq2 ReY8IU/IE20NeVoueUpuQ4Ex/CVPCqVLfZsLaFaUp+RG4+mLX04qT2kZesYTTnqUoV9mpSw3xZEy VLkm5Gkx5ckbLJI50sBLP++0HU7WFidvU8hT2+XJsRir8mt8G0J71xNDntouT/n26fmWFqSv5WiJ jutBBus0gwqLaJceo6vyRKqWkKc2ydNyJ+SpWXmqd5i2ujzVvXbdtAl5apc8jbahst8bUfMR8yl6 qr3qMZrvA5GnhhPyhDy1JSFP85YnPXKdPpHpRfN2GOQJeXK1T8+2Zl3aVq1r1kXDqJRErPrHsf9e lyVZRNvT5ansGC3oA5GnhhPyhDy1JSFPbZCn/HBu4SKpMjWiNzrM7JrOkDxJrB1L3tfoXrvOslBx /Av3IsLufcZNyFN75Mn3R58GTmV7dM26tFlm7dC6vMqwrfflyKbspcdoQR+IPDWckCfkqS0JeWp+ 2G70fZyOBwa0G1AledKe6pQHY2S+iV9FnnJDJ6pkuMW2D/K00PIUpu3I1q5s8jTYlrYJx1IsgfHm EE9/Mr/iMZAn5Al5Qp6QJ+QpPzG3bCHW4bBGmMvvfBn6yJIYWmmsw3a2hYrLFhG2L248bkKe2iRP jgWC+41wVJ6c7XB0ODoceSAm31arHKPJPhB5ajghT8hTWxLy1NCwXZhFmbIl5koWSXVEnoqe6jSf JC5cu865XEzRIsLuFfrHSchTu+Rp2NaS4dhqT7oXR1XN0wVD6ZY8Ex2jgT4QeWo4IU/IU1sS8tTc nKehLJlDFa6n70JzWM8zoj2up+36i7DqN6LK8hSULSKMPHVSnsxI6Zhr1pn7SXtLhun0uXLD6JZf 6Rht6AORp4YT8oQ8tSUhT83J0+jQRJWXTxdJSv7G1o8YpfOdelZ5ss95GpUn98KtyFM35SnfRkqH hp1LE/SPV7iIdsVjtKEPRJ4aTshTc/IUqHG/jNMuPFjzwoVaOL2O/gR5alKetCGPYWSnYJFULfLk ed4AbSFi58upHRN0Rxb+LXtVkW0RYeSpq/JkX0oj38aKnorLzZsatCPPskBs9WMsjTxNv2Ip8gS1 ypNFPGxj7fnVxVsmTzXdrJCnecvT9CkVfxU3zjAMB5Nvm1knqu6EPDUtT8ubWi9P469Y2t2EPDUj T6PzPIrea+eeIDnmLa/2V2bUucAh8rQo8lTUVhe/70SekKemUovlacIVSzuckKdm5Gl0yE57zHr4 GFJgzA9pnzzVOXSHPC1O5Mk2pGd9B+MCJuQJeWoqtVqexl2xtOqKtoGxeu5w+ZPC/aOSVXqjklV+ p19RF3lqQp5sEuOQp9wkWnMeSckK0GF+Lonyfeu6KJO3P9e1IE+dl6cOJ+QJeUKebPI01oqlwfgr 2ubylOxfeZXesqdLJl9RF3lqnzy5P29bWx2jbUy8SnTR0Ex9856QJ+QJeUKekKfWytM4K5ZWX9F2 +I6c3DuiSvYvW6W3bJXfGlbURZ4akCfrUJdNdrzhUyAj0lXWNvR26Hp/2dTtD3lCnpAn5Im0NPI0 zoql469oa1vfZLy//Cuv8lvDjQt5ap88uYOHWdvyy9qGdb2S4sfHx29/yBPyhDwhT6TlkaeqK5ZO tKLtaHTAuX/ZKr1lq/wiT92e81S0X+kK0KORp9CMPE3d/uppg5N0HMgT8jSrhDwhT02lBZCnMVcs 7U0YeSrZv/oqvbNbURd5WlB5qmHO0/Ttz3UtyBPyhDwhT6ROylOVFUsnW9FWP0bJ/qWr9EbFq/wi TwsqT1HB3KGq8lTWNiLL03bpCzDran8RSxUgT8gT8kTqrjy1M7VhlV7kqRl5qnNxySbbH4tkIk9d S8gT8tRUmok8ffzjH39Pblrd4YfR1+91DatsRDtzKscLL7yAPI0pT1JnU9f9D78e3Suf9b1fj364 sO0vPca90dd/OH2Z5DuOPFWXpyeeeKJjfWI7OH/+PPJUIk/PPvssbWUGjNMHVvqwdnZ2bnzggQf+ ndy4ijhx4sTfHDt27L2miSvg/VtuueV3pXmP/t61j15//Qf6jev66z/6we8dPXatjnLceuut/+fT n/70fymrt42NjX9Kp1ANqauy+pQ6l7ov+3xWPtr7f73e9dHHjh777Sza4c033/zbm2666YOZtb+j H/vt9bLf9R/74Oix4n3ku1lWb/Idl+867aycCxcu3B3X2S/K6vT48eO/bkOfeOTIkQ+PHaunX5uG T3ziE+/G9fKfyuotFqg12pmdc+fOPVNXHzhrSvvAOXL77bf/bZ19YCcb1+rq6q78ZcgXDZpEbgCx tOxRF9A0KysrB0QVgT6wPpAnADoOQJ4A6AORJ+QJ6DgAkCegD0SekCeg4wBAnoA+EHlCnoCOAwB5 AvpA5Al5AkCeAHkC+kDkaXE4d+7cl+VRYhovNMnW1tatGxsbX6MuoGnOnDnzLMtQAH0g8gQAAACA PAEAAAAgTwAAAADIU7vZ2tpa4cMF2iIA7RBoe8hTRU6dOvVdmTROw4UmUUo9dtddd71BXUDTHD16 9K9l8i51AfSByJMTliqANsBSBdAWWKoA6AORJ+QJ6DgAkCegD0SekCeg4wBAnoA+EHlCnoCOA3kC 5AnoA5En5GkWvPjii3fv7u6ugRupIzoOAOQJ6AORpxbK0+bm5ln50OdZ5v39/d2IVJikjug4AJAn oA9EnmaAyM8kHYXsd+zYsf2TJ0++Pu+OBnnqnjzJo+EsmQFtQN4vxrvtoIE+cKWrU2j4gA1pUkqt NlEG5Kl78gQAAN0EaWpYmsaXpyBSvV7UG+JFfpht9/o/xCmMfC/9nfz/IL/nR6HlqKHvOX+HPAEA ACy5PLVJmiaSJ11yAhVLkYq3ynYv8pL/z8uTiNFQquL8KhhRpzhvvF31LL9DngAAADolTzIhzSSW oz+wbf/85z//3JEjR8Lbb7/9zY2Nja/a8jTFm2+++UZsOZGnVBZZUr4lYmTIU5TKkZ9sD4aipEWe hoLl8jHV30fypfY0UpaS7clhtIiYbJe8WlkDNSiP4xj6/tnpvOyY/+Bf/LJNn5nR5s6O0xbpfGCe 8GoWoO0hT0NkMu7Ro0evnT59+qrOww8//LtHHnnkN+b2+Ab84aFDh67dcsst/1meAGgTr7322q8S qRhKTn8Yri8R+hBcsTyFyX6SV98nFSj7sN1QagYRqCCVpJ6+XRMf23Y5fk6U4rL7BfJkHsNXORHL RC3b9sdnTv7mpuN3/Lxtn51w3XXXfWC2t0cfffTdhx566H1zu7RZJpLDPJGn7RAomDfybjuetmsh Mov/qaeeerfqsE8S0VBqVYbrZNhOogVtuZZk2C4nC5rI5ATHLk8q0LYnESQ/L0850QoL5lANhK0o amTZbh43+VmpysdQyiyXJnwaDz+9vdHKL1JctqpJ2iyLuMK85YmlCmDesFRBh+RJM+JWSdTE8jSM Vunb0wni/X2yfS3ylA7ZmdGeMeUpN+RnjTwZ0SvzGLbIk3HMNs95Qp4AeQJAnjovT22TqLHkKReN 0Yb5RiaS68NkZn7zuHokKt4WjClPtjlPuW2xtHnFx7DNecods/fZ3z554fKDyBMA8gTIE/LUoDy1 RaJY52mxn7ZDngB5AkCelk6eTIma980NeUKeAJAnQJ6Qp4WUp6Z4+eWXz+7t7W2DG6kj5AkAeQLk CXlCnqALXyTkCVqMLI3Bu+1g3si77dr0VDvyhDwB8gQAAMgT8gTIEwAAIE/IEyBPyBMAAPKEPAEg T7A4MFkcaHvIE/IEyBPAGPC0HTQBT9shTwDIEyBPAMgT8gSAPAHyBIA8IU/IEyBPAMgTIE/IE/IE yBMA8gTIE/LUSXmSVXx3d3fXoD1sb2+vIE+APCFPgDwhTy2Vp+eff/5ERGpVEoGaVISrvtICeQLk CQB5Qp6Qp6WXJ7nZHD58+Ffr6+sXyyQKeYI2w7vtoAl4tx3yhDwtqTxJmxHKJAp5AgBYHpCnWclT 6Efe4Mbb66komKkehJHveZEf6pvi83t+FE512GmOEURqeP0xarY1MGt5KpMo5AkAAHlCnqaSJxEH TWZEQqaSB5GjYgELfS/yNHsyf25Enob7WuRu5imrszrlySVRyBMAAPLUWXlaW1vbniWbm5t+FCh7 pCWRKNWPyMS/F8EZiczkIlb97YHKfhYhcu7nkBV9/yS/IUWBsudVvuTzsvJo1zRSBuPaiuTJVv7s vPEx0vI4ymm9/lykKy6zl13HJz7/D38+yWd5+vRp3yVPpkQhT9BmlFKr1APQ9pCnVsuTM+qTiNEg gmREo3SBGY2eaJGngv0Cm3SIyOUEJJUiizyZ0peUNz2+JkC2MgTatVlkxhWFS/b1lSFBBfIUOK4/ Lnu+zrM6u3jx4g9mJU+HDh26Fud7AXmCNsPTdtAEPG3XIXmadZmSYbuiyJMuNcaNuL+L3PT17YY8 OffLBEKXN+twnlLOiE5OQMICyTLL4JtDfFnkKYkUpYW07JtEtzK7ykuaeX7fff3DiFSyYbbDdqk0 bW1t3Zp8kZAnQJ4AkCfkaQp5Muc8yc/mcJlLsHIRFD3y5IgOjcwzUjHauY38o5GngmOHFSNU1vlR jmE7275BlcjT4Bi+Kp183pfAYHjOOuXJlKbhFwl5AuQJAHlCnqaRJ3PukiuSot+YU+Ex5+70oydp XhEr+37aMY1J3iNznnLbvCTy457zVD43KilDUCRP+ajWaPn1aJurPNl22/Xn5kH18nV251P/7LvT ypNLmpAnQJ4AkCfkqS55Ik2Y6n8yb5rIU5k0IU+APAEgT8gT8oQ8DZBlCMqkCXkC5AkAeUKepkRe Qru3t7cN7UGEduZfJOQJkCcA5Al5AkCeoBt09f1i0G4kev/MM888iTwhTwDIEwDAsvf5yBMA8gQA AMgT8gTIEwAAIE/IEyBPAOPDu+2Atoc8IU+APAGMAU/bQRPwtB3yBIA8AfIEgDwhTwDIEyBPAMgT 8oQ8AfIEgDwB8oQ8IU+APAEgT4A8IU+dkqc33njjIq9CaTfyGSFPgDwBIE/IU83ytLW1tbK2trY9 7pLyV69ePYhIrU7yGSFPgDwBIE/IU03ylEqTdDLyr7yTB3lCnpAn6MpNjHqAeSP3UaXUY8hTB+XJ lCb5eZKyIE/IE/IEALAcLK081SVNeXkKIhWfo5fi+VGYnFm2q/i/ZSmMfM+L/HASNbDsG/qRNyzD hKmOY5j1ooKoiYQ8AQAA8jSBPNUtTaPylElSoHpR3xPmIU/iOV7kaTubPzcqT8NjTHeNE15EfE4V /eurV/8n8gQAAMjTmPJ0ww03XL3jjjv+ved5OyJPKWfOnHnWnOck8wT0PEX5q8qTCI0ZgZF8/W2x 7AzFwh7Fsu1vF528pGTnGOxnSFGg7HmV7ydl8iznHCmLHFOpfrlzZXPLk+t6sjLEx5OyBe7yjh5D rzup0+x6PrX+jUvpZ7a5uXnW9fna5Ea2ufLLsS9fvlyJ+++//3fIE8wT5jxBEzDnCXkaQ55sw1MD eUrkQheEWAB8ZeQbSEGghlEjkQMVDOTI3N+I4Ay36XIUH6uXE49UiiwyEqi8+Mhx0jLp4mMriwiO NcKWl5lhmV3XE1jqxCVPjjrNR9zskac65enBBx/8vrntgQce+EEa4TSpK+IJUAWetoOmpJ2n7Toi T/MctsvLQ7xdpECXq5gkqpPZhBaV0YVjcEzL/iPThwbSpQ/ZWYfzlLLKyMhQX1ggWWZZfNcQXxZ5 SqJEaaEd15Mvw6BOgjHKEWjRqL51znzYbtk6DkCeAJCnJZKndN/ZTRgvkSfTdgJ75GkYbXLmLZpf pGK0CI+x32jkSZM2W+SpSoSqcH6UY9jOdT2lkacKx8jN+wqS/N/+xdW/peMA5AmAPhB5atVSBSXy ZM49SkRJRMCY32OZ85RGYkb3t7lHLzdMZ53z5JxrZZvzVD43qmcZWrPLUz6yZL8evU6yslUpr/xO 6rBnRO3SPPqcJzoOQJ4A6AORpwnkySVRTS+SmZ/PlJeP5Ur1PZ03y6UKkCdAngCQp6WTJ1OiGn89 izGXp6GlkZAnOg5AngDoA5Gn2ZTle9/73mO7u7tr0F7kM6LjAOQJgD4QeWqJPAGYdHmNE1i8mxj1 APSByBPyBAAAAMgT8gQAAADIE/IEAAAAyBPyBFCGPLnJXBNoA/IqIuoB5o3MeRr3yXXkCXmCJYen 7aAt8LQd0AciT8gT0HEAIE9AH4g8IU9AxwGAPAF9IPKEPAEdB/IEyBPQByJPyBMA8gTIEwDyhDxB 47z88stn9/b2trvC66+//gPf9w+6dE0CbRV5AkCekCdoCfv7+7vL+vrjRUq01fkzrfggT4A8IU/I E/JEQp6WCrkBCZOuG6aUWqUeoQm62vaQJ0CeSMjTAsiT9F/CNBIFAMgT8tRJeQoiNbhJJHh+FCaf nmxX8X/LUhj5nhf54SRaYNk39CNvWIYJUx3HMOtFBVFTibbarDwhUQDIE/IEFnnKJClQvajvCfOQ J/EcL/K0nc2fG5Wn4TGmu8YJLyI+Z7/+aavtkCckCgB5mps8ra2tbUM7+fGPf7xfRZ5EaMwIjOTr b4tlZygW9iiWbX+76OQlJTvHYD9DigJlz6t8PymTZznnSFnkmEr1y50rm1ueXNeTlSE+npQtcJd3 9Bh63UmdZtfz9+565N/SXueLTPh2yZMuURsbG1+17X/PPfe8atvOO+9glvBuO+QJ5ipPtuGpgTwl cqELQiwAvjLyDaQgUMOokciBCgZyZO5vRHCG23Q5io/Vy4lHKkUWGQlUXnzkOGmZdPGxlUUExxph y8vMsMyu6wksdeKSJ0ed5iNuWeSJttpOeVpdXd194IEH/vzs2bPR5cuXSzl//nx08uTJfW7yMCt4 2o5hO2ho2C4vD/F2kQLjppFEdTKb0KIyunAMjmnZf2T60EC69CE763CeUlYZGRnqCwskyyyL7xri yyJPSZQoLbTjevJlGNRJMEY5Ai0a1bdOhu1aOmwn0pQuQ/Doo4++tru7W6k/3NvbQ54AeUKekKel kSfTdgJ75GkYbXLmLZpfpGK0CI+x32jkSZM2W+SpSoSqcH6UY9jOdT2lkacKx8jN+wqG+Wmr7ZAn XZpSkCdAnpAn5Al5GpUnc+5RIkoiAsb8HsucpzQSM7q/zT16uWE665wn51wr25yn8rlRPcvQml2e 8pEl+/XodZKVrUp55XdShz0japfm+dT6Ny7RXpuTJ5s0IU+APCFPyNNSy1N9KT+fKS8fy5XqfTqP ttqMPBVJE/IEyBPyhDwhT3XZU/HcJuQJeVoQtra2VqrkQ54AeUKekKcl48UXX7w77vjXusK3vvWt i5ubm/tduiaBttpekCdAnpAn5AkWHl7GCsgT0AciT8gTAADyBLDUIE8AAMgTACBPyBMAIE/IEwDy hDzBQiFPSPHuMECegD4QeUKeACrS5SdNAHkCWOY+EHkCoOMA5AmAPhB5Qp6AjgOQJ+QJ6AORJ+QJ 6DgAkCegD0SekCeg4wBAnoA+EHlCngCQJ+i8PF25cuV8fJxtWHxefvnls/SByBPyBK2Qp7vuuusN 6gK6Kk8HBwd7EakTSV7M7urHJm0fSqnHkCfkCWBstra2bqUeAHkiLao8yX1TBGhSiepqH4g8AQAg T1PIUxCpuG/tpahgzNu27K+iYGZaEEa+50V+qG/yI8/zo3DqQ9dxnGnrb/bylDKNRCFPyBMAAPKk y9NQICyiMrX4TC9Woe9FnlYo8+fG5Wlm9Ve9jv90f//PyuQJiUKeAACQpxnLk0hKPqJiRFmS/fTI k/77WHC8LK+nVIJKjyXiYkZsZJuexyo5+TIGyhL1MaQoUPb8ypd8XlYO7Zwj1+4q21j1p58/PlZa Lkd5bfsX1fGn1r9xqYo8IVHIE8DMkLH+c+fOfZm6gDbK009+8pPo8OHDfyc3wEl56623rpo342HU JJGFTBKSG7qvhhEfubH3f63JU6CMiJAWeUpkyRWFGuQryBPYRCM+Xy8nHb1+mVzyJPlNKRtesyY+ tmsPXGUbr/7yElQgT4Fl/9Bdx3/82mu/tn3GRfKkS9Qjjzzyisi4zmc+85m/uuOOO/7G3B7ziwsX LtyNPCFPACOwVAG0PfIU39j+q7TTSXn77bf39chJEulIb9giGsZNVgW6KOjRpkwqhtGSvsXk5Sk3 RCa/048/kCfXMNpAGvQhO+dwXkEkJyceRZJlXrvvKlv1+kuiXJld5WXNLIdvq393HT//5pt/YfuM y8RpZWXlQO7Ft9xyy/965ZVXknZVxhNPPPGe7IM8IU8AyBMsnDzNdNjOjNLkok1m5GU0ItMXlcAp CPkIihZ5cs5BknKqGC26Y5TRHnkquKaqEarC+VHV6y+/zRV5GhzDV6WTz/U6/qMf/eWPrJJQIk1p PpGnuD1Uanty30aekCcA5AmQJzN6Y84nSm70+TlP/XyZPOXm6Ay2pcdI5jzl5MOcu1MmT4NjGb+3 znnKbfeSiI97zlP53Kjk2oMq8lRWf3q0zVWubPvo/sV1XGXOkylNyBPyBIA8AfI0tjxVT7pcmNJA GjfV+2Re2VIFLmlCnpAnAOQJkKcZypM5j6ehJY2QpzHkqUyakCfkCQB5AuRplvJEam1yyVNVkCfk CaA2eeLddtBlefrOd76zGp9vDRafF198caqlA5An5AmgNni3HXRZngCQJ+QJAAB5AkCekCfkCQCQ J+QJkCfkCXkCAECeAHlCnpAn6BYy32ljY+Nr1AUgT4A8IU/IE0AFWKoAkCdAnpAn5AkAeQLkCQB5 Qp4AkCdAngCQJ+QJeQLkCZAn5AmQJ+QJeQLkCQB5AuQJeUKeAHkCQJ5qRl4dI+/eaxM7OzudfeMA 8oQ8AdSCUuox3m0Hiy5P0s+urKwcxO15dZHqQt7XFrUsPf/88yeQJ+QJeQIoYWtra4V6gEWUp1Sa VldXdy9durRwN33kCXlCnpAnAIC5yNOiS1MmT//8933Pi/xQu+jQjzzPj8JpLWjC4yBPyBPyBADQ IXnqijTpkafQ9yJPsyfzZ+QJeUKekCcAQJ7GlqeuSZMuT3nJCSM9EhWoXnJPSFCBVYoC1c+v502y JvliETP2FzmzHlOpSMm2v6/+DfKEPCFPAAXwbjtoszy9+uqr0XXXXffBDTfc8M7x48d/Jg83mHP0 pP3KE6M22p4/nfOUClBOjAIV9XKSpEuRIU++ykRIjzz1UhEbSFkgkpTly523pyL5zebmpu8qfyyy r5uf59ra2vai5L/xxht/8+CDD75z+vTpqxrvnDp16j1j29WjR49eO3fu3JeRJ+QJYASWKoC2R55u vvnmXx45ciS8/fbb3/zSl770jO0PAGnHNuRp0jbnH04Yj0VJhur0ITvncJ5FnpSyDPW5JKvXy2EK 2fb29uMF5V81r1cigYuS/+mnn/59c9v6+vrFY8eO7dvyL/p3DXkCQJ5gSeUpnfO0ubl5Vm5yEm1Y tCUJXGRP2wWR8lSMNnk8yEeT7JGnQUTJFXmqEqEy8nZ5ztOy9YHIEwAdByy5PKV0SaL0pQqSOUvG BG/rnKfcdi+Z1+Se81Q8N6rXGx0uRJ6QJ+QJAHmCjslTlySKdZ7oA5En5AnoOADmJk82iVq0BV+R J/pA5Al5AjoOgLnLky5RyBPyRB+IPAHMHHn6x/a4L8CiyRPAhH3galff74k8AcyQnZ2dG6kHQJ6A PhB5Qp4AAJAngKUFeQIAQJ4AAHlCngAAeUKeAJAn5AkWCnmVgbyegLoA5AmWEXmdzpkzZ55FnpAn gMqwVAEgT0AfyFIFyBMAHQcgTwDIE/IEQMcByBMAfSDyhDwBHQcgT8gT0AciT8gT0HEAIE9AH4g8 tVSeWBl6uTk4ONiblrfffnv/rbfeulrHsV566aUn+VwAeQLkCXlqpTzJMVdWVg6eeeYZblZLTNSy dOXKlfN8LoA8wSIh77br6vs9kSdDmlZXV3dlfR4aPvKEPAHyBADIk0WekCawy1MY+Z4X+aHWgEI/ 8jw/CqexoAmPgTwB8gSAPDUuT0gTFMuTeI4XeZo9mT8jT4A8ASBPSyFPSBNUlae86OQjUYHqJe0p QQVWMQpUP7+eV/mSJ5YwY18RM+vxlIqUbFv/k//I5wLIEwDy1Ig8Cffcc89r+nG2trZWbrjhhqvD m5fB2traNvmbyy+fs57/woULdx86dOjaLPNHhgDlxChQUS8nSbEUBQ558lUmQ6kQ9VIJGwhZIJKU 5cmds6ci+c1XvvKV/9uW+pEnaFx5Bfk9+ZvJf911171fdCyT+++//yfcCGFWSIDC7O+RpwWVJ4k4 SeTJvCEAjESeBqIkQ3X6kJ1zOM8iT0oZQ30uwTJuaqaMMWwH0yB9HpF2mDcsVdAheUptGImCSvIU BZHyVIw2eTzIR5PskadBVMkWeSqLTlnyIk+APAHyhDw1Kk8pSBSUy9NgzpIxyds65ym33UvmNtnn PBXPi+r1RocKkSdAngB5Qp5aIU9IFFSRJ9Z5AuQJAHlCnhzoEiUro9L4kSfkCZAnAOQJeapwXOlk 6GiQJ+QJkCcA5Al5GuPFwADT0uX3OsFicfz48Z9tbW3dSl0AfSDyhDwBAAAA8oQ8AQAAAPKEPAEA AADyhDwBAAAA8oQ8AdSEvDPu8ccf/zZ1AU0jS7DIOySpC5gn8oTn6dOnX0CekCeAynT5MV1YLFiq AOgDkSfkCeg4AJAnoA9EnpAnoOMAQJ6APhB5Qp6AjgN5AuQJ6AORJ+QJAHkC5AkAeUKeauall156 8uDgYA+aQz4DOg4A5AnoA5GnBZEneZFr214uu2xp2pfpyrvA1tfXL+7s7Nw4yf7yXid5RJxOFJpG bmAsVQDzRpZrue+++15BnpAn5GmJ5En+Upc2c/jw4V9NI1EAAIA8IU+V5SmIVHzOXooKov42FQXO Uhb8PvQjz/OjMNsQ+Z4X+WFRngnTVMexXffiylMKEgUAAMjTPOSpDpEpEJrQ9yJPsyfz58bkabiv RfBmmuR8ffmsW56QKAAAQJ4akadBZEnkRKksQjOMzqSRJz16M5CPRGhiOdL3yUlOXlQCZYn+GFIU qH5+PW+S1XYuTdB6ZhnSa0mja5YyjewXmeWMjyHlCexltJ7bqCfPy67j5D/6l6/OQp6QKAAA5Gmp 5GlenD9/fmT4qh8R0uQplaKc9Ax+H6jRCJJjn6Fc6GIU79/LCYguRYaY+Gp0aM1VvkSUdPEZyE5u qNEhfuZ+4aCcOXEskCfbMXyznrLIk3wG8/is5UmmT37yk/+jav6PfOQj7yulHqMDgnnBu+2gCXi3 HZGn2USerNGVbM7TMMpSEjWKBqKlD9k5h/Msx5Boj1XUHOcyZUD55hBfdt3JNUj5bfsFZjkHkhaM ce7ArKfZD9ulHDp06Jp0DPJUnvxcNUmblbZL5wrzgqUKoAlYqgB5akSeqojPcJ9YGJQ+tyhQI0Nj o5Gngay4Ik8ugSnJax22s50jqhJ50qJegSqcfN6vp2CYf1bypEvT8IuEPAHyBIA8IU/NypOvz+1J ZSp0zwVK5g0Z57LOecpt95J5Te45TwXn0oflgiJ5yuRvZL/hkGBRebJttnNL1MyspzRP3XOebNKE PAHyBIA8IU+1yhNpvFTvk3l1RZ6KpAl5AuQJAHlCnpAn5GmAyFKZNCFPgDwBIE/IE/LUmTStPI31 RUKeAHkCQJ6QJwDkCbrByZMnX2epApg38m67U6dOfRd5Qp4AkCcAgGXv85EnAOQJAACQJ+QJkCcA AECekCdAngAAAHlCngB5ApgpTBiHJmDCOPIEgDzBwsJSBdAELFWAPAEgT4A8ASBPyBMA8gTIEwDy hDwhT4A8ASBPgDwhT8gTIE8AyBMgT8hTp+Rpb29vOyK1Ou3v7+8iT4A8ASBPyBPyRJqRPG1tbd16 +vTpF+Rf5AkWGZYqgCYQYZc+FHlCnpCnJZIn+eJLmzl06NC1MolCngAAlgfkqW55Cv3Ii8/TS1BR MA8rmOicQaSGecPI9/r7q0DfXleSY6bli1FzqZXa5CmlSKKQJwAA5Al5mkieRBK8yA81qZlKFERq ykRmnHM6jif7eH4UzrKMw+NLfq28c0n9Mv7p/v6fTSNPRRKFPAEAIE/I0yTyFCh7VCURGtWPvsS/ D31vNAqTix71twcq+9mLbcO6n+Octrz54/mDCJMeFUp/7suQnj85RIUy2s/tlqficsZ1pgZ5DcEL BtutdZK7Ji/eLyvjp9a/cWlaebJJFPIEAIA8dVaeZsX29nZyI/dsIZVEOgbRGSMylEqAPZqjRXUc +1nP6TyHHiXShudyYjLY7hLBojI6z52XGVeULMnrK0OCCuQpcFxnXPZ8nfTL+E92d2fy2cuTTMgT tBl54okJ4zBv5N1299133yvIE5GnySNP6Y1f8hg33/4u2byjLAqkiYlrP9s5C89RTZ58qwiWlNF5 7izylESK9KiZkdfz9PNqUSqbPPmu69QiUv2QWa3DdimHDx/+1fr6+sWdnZ0bkSdoMyxVAE3AUgXI UzV5Mucfyc9y8zblySZYuWiJHtXJoin2SJDlnM5J2fqQ2QSRp7IyOq/PMWznEr/SyNPgGL4qnXze j8wFSf4/+tFf/qgOedKlafhFQp4AeQJAnpCnSeTJnBfkiproN2NdZvR5Ovl5RyIt9v3s53TlzY7n F8uTbc5ThTLar0+Xp/xQ42hePbrlJZEos+z6dtt15uZBGdcyzZwnmzQhT4A8ASBPyNO08kSqMdX7 ZN6kSxUUSRPyBMgTAPKEPCFPyNMAeYquTJqQJ0CeAJAn5GlCrly5cv7g4GAP2stPf/rTZ2f2RUKe AHkCQJ6QJwDkCbrB6urqLksVwLzh3XbIEwDyBAAAyBMA8gQAAMgT8gTIEwAAIE/IEyBPAACAPCFP gDwBzIHjx4//TJbeoC5gniilVnm3HfIEgDzBQsJSBdAELFWAPAEgT4A8ASBPyBMA8gTIEwDyhDwh T4A8ASBPgDwhT8gTIE8AyBMgT8gT8vRc/514EWmsJC9hRp4AkCdAnpAn5InUMnmSm428E6zKTQd5 gjYj7xfj3XYwb6TvXFtba90fu8gT8oQ8zfiLL21GKJMo5AkAYHlAnlohT0GkPD8KhyUNI9/zIj+s clXj5C06jB95A1Ho9VRcoklSfB3DfaVc/eOpQN++mPJUJlHIEwAA8oQ8dUae5Pdl4iJyox1DREpV VR3H8eUYuWsay+QKy9ykPLkkCnkCAECeFkaennjiiffim2lUBbnByQS2NvH9739/p1CeEpFRsdwM btyDfIFKb+ReLClaXv0mHwtQlq8XeQM7Cn0vlyfO1P/XGpAy8urlGTm+P4gwBVl5hz/3ZUjPn5xy kjKv/8l/m8dnc+7cuS+75MmUKPn/qu1Q2izyBACAPDWCUuqxkydP/iJmX+e222779YkTJ/67uf3I kSO/lJn/beKb3/zmX5fKkzbkJWIRX7cmO0bUaCR6Y0RxjKhSoLz4eN5QUkaiR0ZeP8iXJx8l0obn cpGnwfYCSRunzP/YO/HOTcfv+PmsPxt5H1iZPAnyJFPcvv6D2d7uvPPOt48dO/Z35nZps9J26YBg XvBuO2joHr0a93evI08LgkQDFuUv+9JhO2P4K43AZLKjD9tl84yyqI8hIiIwxs0/L2P6aJ4lr28O x1WXJ9+3SdpkZX746e2NWX82RcN2qTQVtbMuP6YLiwVLFUATsFQB8jRjeeoLxNBf9GiTIU+FkadY MvJSlYqIFpmyRn/M6FX8s2s4L7TJU7rvBJGnCcrc9JynMmlCngB5AkCekKeZy5M598eYvG3MCcpH a1Qy7JbJiz4XKj/PKJUUfU7R8FyO84/kDUYngmfH94vlyTbnaaIy3/vekxcuPzhveaoqTcgTIE8A yBPyNA95KlpCYOKn1rqZ5h15GleakCdAngCQJ+QJeVpKeZIJttO0I+QJkCdAnpAn5GkGvPTSS08e HBzsQXVEOOk4AJAnoA9EnmpkY2PjaxcuXLibxgtNIjer9fX1i9QFNM3jjz/+7Z2dnRupC5gnEr0/ c+bMs8gTAAAAwJJDJQAAAAAgTwAAAADIEwAAAADyBAAAAIA8AQAAACBPAAAAAEAlAAAAACBPAAAA AMgTAAAAAPIEAAAAsEj8f5e2lwPgBrn2AAAAAElFTkSuQmCC --_008_BYAPR08MB4903CED7FFDB7D11EFDB49FAFAD50BYAPR08MB4903namp_ Content-Type: application/octet-stream; name="oledata.mso" Content-Description: oledata.mso Content-Disposition: inline; filename="oledata.mso"; size=60358; creation-date="Tue, 06 Aug 2019 23:17:07 GMT"; modification-date="Tue, 06 Aug 2019 23:17:07 GMT" Content-ID: Content-Transfer-Encoding: base64 APIAAHic7NZ1TB5hmy9g3L04vLi7FC/u7vbiUtxdXqwUK+5Qiru7u0NxWty9xbXF2fl2v012T3Ky +/15kvObXJnJzDxzZ3I/82RmZ7C38+uJd6D+j4hAwUK9viFDIfyXc9D/9O/BggKuv7394/A/9//I 2//P/1N5Afyjf7BA7+AA8IB/9BwRgARABqAAUAFoAHQABgDzP6YAFDYAB/AOgAvAA+ADCACEACIA MYAEQAoAAcgA5AAKACWACkANoAHQAugA9AAGACOACcAMYAGwAtgA7AAOACeAC8ANeA/gAfAC+AD8 AAGAIEDon/NU+N/nNhSUKEAMIA6QAEgCpADSABmALEAOIA9QACgClADKABWAKkANoA7QAGgCtADa AB2ALkAPoA8AAwwAhgAjgDHABGAKMAOYAywAloCPACuANcAGYAuwA9gDHACOACeAM8AF4ApwA7gD PACeAC+A9z/f93+KBvAkZ2AkBfDmTsDeDcoX6l8JPjBj/vNZ0P/DvZcprljVSgvQ/3W9MAE6yAt0 kBfYOIEucgMd4/gX6hNCwUD/ozYM1H+sPf+bMf+4N87t/16f81+r/9/WvP/NmA+AIa9/ocj/kH+1 /n9LHBSUz7fTr55apBNZfxG9Udko29DOOeBa8yh9KNpOtnHWkfHXWW0+wf8N2T7vN4Lt39jJXl8P 2PIPvMgR9v+bK+z/J/AIUlFZ6a+yonmnpft3mWH6uFQhiaevV44QCtEHIgFN8UqLfqj6igV8lk9H D3s/fvzopRV9KXxT9wumurMmf4WBJn5bOJJTS8jPExMP+4QAD0JBwFVi0OtVhgqGPSDCNWTwUbvM xxKj/CwBF0aIgoyrwWCpliNJGXENgwKPq8CgpVaWPyuWHyaBGEaGAosrwyDGoKSWkV8nZhY2gBAG QkHEVWEwVGvLvxTbCRtADCP/AoWLhSvOwJ6P9GK2BhWMhKvOYK42lC8nlvisKPTsnIgChfYiIPkk gWKKKCwI8+HVk+keUxpK7L7X4nUJEqwK8yT72LqVXvzmx/5kb3DKFcZI2GZCH6RCwxG8BEUS/Hvr +02tBHzfwHOzyNvK286LrxYCIUwM9OLs7HOvFoqDzWtvxXWlytvK804+7tNL3KAYKyZaHfyy5Fo/ kuld603QH+uXnTeZ197vJ7fWz1czgU9bVn/ffrXmtUBFP7dWn9e23N7DRTyu/Xn1PH37+obHGgvq VzHltkZBV6RX5AgrKszPKs5+IBfZ80ZBxGQWCqsIy+8u/0G+uR+vtSh6YXGwDf0NVUvgGZE2+CnI PinotrWYBRMxHvHuvtchGAcrEovZAdNxWuizCRmISEcWxuHIwe6oqvYQ+ozMSMfbgOSLoY9eOCnU aZB3/9tcUK0dDkKq4Ep9cY3xBqJT/RgrDpyZwRQ1pMgzkPq5+kuP0rHIYd4d50QIjVhTngEkSsZp y/0nTaGrhW7oDJxkRj8xkrmMwuXgHJRO0KZ+m7PDWGFiUyF0+mMEuUbMmVMOcbchtlh4boGmO920 Pa81RmEzRfraUwuTNerKiO8VFkVfBwRWyL5/03Q1MVxJtm+HczEo1mLBTvqAs7fnSFkxh25167eF Q1EOBf/grEo1JwfrS0bo3+fkIltuYXeqryX4BYw4Xw7SsmwSrf82CVW/qQ3KtniPDPF+xEvy+AhO +2tWil4bYpffron8zpqwy3NrqzgO436WZFYzufAChLLPMIyO4+gusLufrZ4eH+iAJXasd/OJftB+ JacaM+NUePO7G1GCZza9f0PDvr/9Mb5116TzEPziy6IbhPTr/h2nJqFQzfgmjDFhm2Q3b4sfpUDK YaqmlXJWaNj99yQVh84KEgb9a9zmBrFD3ak1qTf7/OdbuL/ssDwwjrhRUIJqsqZBrFOJZncgZcdv y3pBYW9os0G3iomuZ24upMuUstCyy3Gy1J47Zuuo2GMJmFuJCU9/z7x+ueyxsOqmNRM2e59+nuR3 zumLf4ljGw1pHIGdg3a1HpavC0nx35XOEm1xZM8snsxJT+LeHxpHE1BhramLXI7vpt4Cn1thpJ8k d5IKiufJ0UfEbCvmO+PhO1zTkLwV1VXk+G0mGuQoX3HgcZMalhVLCgmwP1do5FlvKNIHBH5djm55 jPklSGq2kCtZWSIIrz0q14gV8f6dpcREkl8xV5KF4RcwQRM90dVnkjvi2OfqaQ5kQceRP1NmKA6r ssERD9yalTLTyoOFITa+4Y0GKnwIpQ7LQsN3BdHeK9oilqnV2nyoqKRTklmm7yJyYX6ebTjwVgcH ORM63se4zkuSw5M+B4kOd7yC/esyg2ONHPKNL9I715YWXMHbtdfY6r3++XSRPCYlYNv0oZJjsPX8 xfGCpkkWZ0Z/KajPYTSPqrbgtmGqlIhuGoaEmo1Vu75Uv3w55phLi3j6UxYNytxe16u9/DT8lN/S aBy6rsvcpw1E/087EXvJCJEslITuPVXo1xwPUocBaIMP/SzC2L5JFNA8gXtJmq4yQ3g/nQfL8nW1 A+zOEyiIdhxU1BCI+cAkqc8hnw79OouWdAL8TNR5L+WKNBN0o0+DpPBqytNb2H3N1yXv8ESHH1C0 otY/pddm3CJ9MbpVzzDWoajMLYfQ+qpyY776KBQTG/CnJVxcF6ChJUJH9s+RVK8gfDvxZcQ/E4Su S+gQOpC+LBFql0pQlAxKeLSSbwsg5ufOE3lpV1I5x2mn4hYokbwHNSwG3t+XLGVjlMqZ4FkbZSLE /IxhUmBbG90OYxPYUaUnVTiHnNWLPoJ3I3GeqsiSIny9egZJqgfy7SrbTh+xm0CEs34iG4man2gu OShqC2KWxHdIZKtpWHB2P6/KnpemdsSV2s+AQMHfrg8YhYauA+t/r/peXZapjJ4hBlz0R0/MWXCU 816++3CEVfzAmMYvl5dpzzJGHOPSJ3r5fqne7da1P+PsPkx9bf6JoFXA/oTahh2LUGV+CS0Obf3s bLSKspNNV847JD7iDI+tse54yAGL6p1UV7DizCEi4c5iNAYC4ZjTy9P07y/lliZ8oDb7RBETmL/x 32Us2N1YlQSKmOOx2IZmtthZjzgQd8wysfJPgtklGXYZDnoWpycxEaOGuXqhebjikSssCcYHpQ6i bN7tooxpIfPJ2otmNf8oXlGLSWaLIm0ka3rXICRpVfqx9CxfYjHndzPr2GEtnnBj7iU2vHT6AKTx p9iDTBeiDfKpN/2v6U6odvoNPvpImw9d7a/8Zbznq3ACTbC9gV8tJpixRKKaQrcdB7G0BbhAh0zh YUoNHUkxY/wJvqWbLZQTZEqbTJ4H3Qn2dtO6Dkexn34yxZ2ZvL3HnrjsqaBhcbJG1E9OVZ4Z2Xgp C+DNblShpAtNazD4+FEJf+KyMIw28TT7sMz8mshgIJ3v5wxLozxtecEN3Cc8DnETfBEowcFlg48o rL/MuyuabcrIlI4pxZdiy+iXl1Sjx9IMlBCSyz+PMQ6m+Vwjk5ZpsN2ezderVykFJJccbRyQME2+ U3KIjOJJc3ruv6BpjvG42SPColtyC6gDBSrAKTyJ3jFyfDQ0xUezESQjKpGfKZ/CSe4M9zoGQWew Qpit7lHkVX7UCChIMj0eYmZ8AbEKKrVfnI/mO25OYrXGhDKLz4iq5yhuveqDx8eIdHhn4AqPm3TU kySGWYbk+nDOV8coBrol+XaEK+Ndhz8tEVRtZI6PUDt865QfNjWvYrmem0if65qjCZ9p7O72Q/4x 3EjiNGe1vIlsNJop9HOI1m6sw/QhhTmdOk6hnwm7wAxRK+3aHUe2bpD6Jnp3LWZfZ+hO8erd8da3 DiLhv4XnA3iuJneiPXcBPbfXgdTJLkXdnQjKJlZTXqIesivlEyFS6Oycr3EjSJulrMwu7a6t+XTx dtO0eavJNSc9whud54NxF0S7RmT5uvZarT66wymUSGFOP/1NpPghc91ONKJCHNU4B7RlqwnJ9HqQ W4+XtSck1W3S0z6QdoVJtkbOLtaXUfeNtSUtFd3ys7oOlx7dzxhNJ1xh6tz8KP34ZxlNKKf81Alp 0TVLU5fjfDJaTff2v+nNdpTGo1aMrMfR9JXI0O5/x7WdwKFUdbj2p+KfsTKemyQVXn/1N7PEWS2E 64b9zG0y4AyxqByXhCxvIJZM5R1i6aNWeOQUdpQgLzXTZSPtphCbG2aIJuPBJad+jFZ3A9FW1ElM ut6KKsnjptEYnq/uhLcjJmCUbXj0EzWu84WnYFZFellzHIzxBE23LCUyY09H+fvQZ9mAtdRNc8q+ 7heYP/Lqtx+7f34yywxfB/mx6lOoNO3IRL3XO3Q50vK+hNXv4ppaF1gi+EMgY4ZPl63gwS8bZX6o IQKStOvcKZbgOZaknmc5F7gbfkjxNqpFj9zQH/TzyvhDWl/Q+ChnaelVtqq7I5oo1TDsS9ShPh+7 cv5Niu6pjjqW/NewQ629B+eDbsGdi+uA1OPXvtUNCtJYKZwmenQThPjNIB4cMlsyZkNxUlWZg6Z2 zX5Zr6oAOh49PicU6lUEFhkYMhXRT5XNM6b1L19hubDuDfCkXJCh/qQbetpPjqoYzh/BjOBO2SML hhkUfOHmELWpbhrcIjEkwvWirZ34EjhjcutVeH3UrzSiyj453FTXMOfUfCJHXBKds09fQGvovyWA K1DTIQBewa49yMkmrkKe5LFi10lWUMDcK3duauXFqkENVP08oQl3bMe3NrT4LkEyDb+q7a/XSFlJ LsvEB0P71ptsPLTvc16NR7l4k5iJx/vzWYJxiF3cknybpBKVnQaCEIcgy435O/evOibD7TIDNXms 3ahnEIiWCJV1Uxzx1exzkUrA/CJ/tCtqL51LyVQtuskTh52wzjgkO0aUy3UDx8nT+SqSZ6IhbSFd evpSwFs6XLc7A3ZSLbGRIl3TwfYl1mg1pThrWps1RlaUrsVAV6xhQ4wNH28OK0o/zry1sy11hmWw 8tlrUVgwHd9Idfl5+V4Ps7/jW1qSVgW/d97KKX7hZgm8aL4+BXSC+Ee1AQIlIRHJu2XR1ZBlix/E 66Xl29+xGp630dO1TW6S3ghTuHtlqUyIzTNMMEJzTHFiRxjHney6Pd7Qh3Eo6g02BwJWeI2gvZNa wJ7b0ROm3kk9fqBU72XCaSot7/trt6y3rP7wM0mM7faTV+hH7RujMuvtves9sMAoRq8EFZEFRhya 2jrPuIdaCzYNApp8Si9xUPaHxLeV3jy/CRJ8GEV9OSuePXyxuKKwVb99LSXlJJzaaGq6SkYjwlmE ypJXZKH6P9puwTDrH76iCKJIvrezpN47P1aA9poldJdBYzKaxmfRYVZbu5HE+V1MgBDmhfy4NgVC DmXWjokgp2lV5bYgYwg3/OnbvCyf2swQ3bgFy6o1PsULyySlxuRfcMlt7CLzNvaTq65f+SmkyhId q18p+jyjuAGmWR6Jln3f41kLG6ZngDSeSHwPueUqF5chduADTzxIXkNaJFtIuwDUIjV8U4Y8ZpEz zyXC9OawI7JP05IffiY9+KY/5vTRt+HI+lwGOkkp11DbahEMx3G4wS/Ywhj74P2B/pHiuCipiF9g n5IW0u42zuOqnUIoOaHWdZ6rhXTg8nLPzJFnqu55evJq7aKfgQI3JQyO5VF836fblXmpAXpl792J j+8g4bdAuvOtD9N44hcUyKfYSNGt22CCWC8WjfCvYWamI2tW2RRt/R6vhjqbpE/y6SyL5xs/9x9E 2kxHg9wgLyWV69ZEpcmYnjH4gFmpFIjVLlUJyqg7fgVE2Yyb1Hw0OXCeq04ADQy6PCFNpKqe4x3e uyFooxZtg9kfuMeyDrNrGOgyofSRirNSqdnpOMDSUAbNf1bFCG3xJd4nSbcHBLUP+imGnSxKNcLo 4jdjjrKTDI5ZFyCCpdKQuVa980hNTMfYkCv2Peq8S5oOPT8GOQv9lf8zrINrjSCuyKDL2psrSFvu M/rOfKHkCWqT1goeekImpWaB2+CLhueX9Z1YZCmjKxocrMVAh0MRf+d3ctPRsQ8vA64c/nA8LYHq d1WB2AhhP1GRZDWbtsfPW3GjoO8kTgnzITnoMF3ocRO2D2rcvWaJ3HuJQlDHOzv9SEp9u/sSA2zj aPeHxtjrJFZ//cI3kQ5ZLzdKXfVyiLRWFyM9X5S/Q4h3lZ6YUhZmFKva9bMr3WY8jq5C4w3xsqfh 9VjdFrVT3pfy++PtL/Db1KTRxlBhe7fBG1lrdhoNNljDR1bqT9P6OiPC3C8kLbkzGQgzeIyOZ9W1 HaHSPRHF9YlxZ76P0/J0X2XUNC9d8K5c8vTaRbFTKdGEwWXs4gZhuBIEsB4/ZWDahN47Tuej3Q7Z 5EWR+0Bhei5DGuNaw745CqNvS4n6jbnsddLAblAZ0vy4wCFW920I93qfZMlGrF8Uectn4CNx4bO/ 5E2Q5YAhoMG1K88or+nMfyrCf4JgfW7TUWKlv4pnx2+VHD4D+z3b3JunsOedvSpPBnz4fVeN00Bm dFErBJRLu2laGD5BZqC6nnRldZTQiU07HSGRNoVg5E6ZcN7G5Msma+a0LiNAnhn2ZLDeXaQP3mU4 tX5WUCIMV+iKoCKG0J5UUaH+9ca3JJg8rQ1XvdIoLjeOmIJNRHBMHYy2VyWKXlUCj8bxUceMzxnV bxf/GdCQE3XDQ2kLW/O0/C4Ph4LpDLaLpDaXTXD3+kPWk7tQMeDTUbc3Sc3kQPbpqYtDitNlLGyk 3kacosUyymb2/YLm9/NizXuB9Ms6fF0HVxOVfK6GUApcmXPZSE1uzkZFEoW9wOwRZVNpHDOuRuGd cGqYA+PUor/wp0TfAtG/3CBv/e0uT/7wEEYAS28oTF6TShpaqT8ZRtDbYsXTA88b/qG5le3psIoQ vf9ZKqhwBd1nNmTIX/ricNAtvdf6S6CiqYZaNy/JUMPXH1XiFIN70Whwrb0MpsyzapUyguXOJj6K xqdCDddXCdPefzldjZ3LbUqXZbRzEhW2rhBnvvtlJLVwcdqtlGOZL6XmUgTFLJ4X1009tdOLIuM1 +B9K3rfU++TNSDrUXC8KyMKGrhSaNVkTWWoyGheLzbHE31zXPaKP7rDqb844XbvK/Xy5HvA23cWJ /hpuHJ3F0wjH/O7GOpEPvKThUwMVVz2MION7qAS/k80e3NN9SzH8B6NaYH9gSFbSJGiLnb7+5Ar7 DpMDvjrvlVike3KqI0zIlswkhkOW9qBZbQuvNzvJ51YmJZVNf3Gzqlj43M7h8iuXfwjkvUS18Uby r/QOj9CYFN4+vLBAjYrp4E9KVBlRTQyudIvS9AspOAR/uiZx6931ZyZ7xKyRugs9fcZUa0RiCTcb BZo3hCSspfJbCk6OBpD8rPaG1aZPBxgErQwtJhij4QtWNCKJ/EOm+f1GxQooO/cIvOpYCAYtQHyG Az2GwrDhuORoaoboVmjEw17RGXnaXdAH+ba8yk6I94hg1nShwRTfjnyL0cykcNoTMAc7j+N0gFs0 jqOhmwCTdJo3KbtqIbxSu+7ju2st3F9Fq2FaiT1xenLSuoeTtUdWu/y1haHc9Y0B4fTBEt9L5U4g ulDmHJzcywz6DZ9AeSFDn2mDDmDQR9WI58Yy/mpTjnv6l3XgZZ6UE7mbF8EcRErOuT9l4JP8lOV+ eVq2b3OJtPgT/2N3qq2NqTqOpK1TssYd1nmbQmwmzWzlKIlH+4pixLL/xpkzNDeBC0GcONKx1usZ dZRsdLheiQZTl+uOKyDSg7xzkHSedKDobEvI7hgy+NYFnr3QCvliNqa9T5r0y7czsz7ywxFDBpl4 Wd5DmrT/h5uAxZQTkrubYEupuyu9RtZF0lJvnSbXetKZD9H6KSCkx9mfpDaPSIy46e7VzO/g2Nes aY4qi3CrI1FX5qtHWSJmvY71lHKT+RJppstGG2zLFtXGy8tG0JPSOSqGFO0+HIFvlvVIBScyQAWO tI/lVQSMa+BJHeriSroHEcVKOJPqWrRUvoaHtioPDmujQOYVOokCu0C/6D+Q8irZiviW9Umt2E4O uu8fu7dpj63LzaOsG6K/+/9wIOl+uQm96+l4bjxjvAv8TbBLXAx+so3S9rKBKFkp4k4cNMJZXzNH KYJ4/HcHp3DGY6oQf3S5jad5OWAXsRrMuEqzqdUihz/omVn5CIGjNn8f+XcrE/F5mrlbELOgxUf9 GhDDotY2pYXrFT846wmpisCNWQnWPpjkvCpAHV+v/drODOPEc/ZcE6NkZA6XndVEEPagI0mPo2q7 YcR468LNZb90ysQdvcbj4bhkSBV+xVECQuQkuqP3r+mSe+Ek0ybG2kZAvJs7sQhGDvfDuStg4k/x f84xyC1env8lP7pDRDN5Ke2vrOrWqhtZtMg5X/rkrOmPrTG2aXRpczsrbCkw6/iTCZTMjcsrXF07 QiI0k6a14AQx5NfDrK+eDOjQGiFpfSWC98os/9n2p0BHf93wfSHpQiEmVyyTPPmcTq2ZLSxTlCnh bXy8sLraHeemmQf5cGEQlSWWTlPQRW+PepErio/Y4E13zbHx1TcDUbtGgf75yk6Mj5rdJu1c0kQ7 mXXPmx28ritD5dSifa1vHMk+e74PbXwu7PsP++aPGfC+4KV1NpXSkfCL3G3UeHlstPPPZixuNuMU xVGPj0nUvN5hsguFnyc1OOYKLTeavzELj3o8HWhKx9TK58KY33vf6TA13pC3LVFbjCSauO4xSErn sEGEi9UjasBh74QtVvWk5wuMmx0nFk9yDzoha+Co4qBLIrF7cwUujxQlkz9zas6roVjXZz8+5ebv PD2cd6XY6bhVL37O7xKBllBVQucKtq2gfi7hQImugWfXKFOmckVotpZOcIeWSQqRTRJRwexGpfya u9ODmhromRGdA6c7JdJgqg6v7DhfOiLNOGA3D48H57lruvsZLdaZY3qBG+RK3dyXj9cymAPiUe05 gwcvVVJiHw36DxDwOAsdFCCO4L+bHL40GMXQgdhNOrg81dXsGKl+Al3YGhqgQyOFiGKkm35c7ru3 MDET5qbU4xCB+VZtaizD7v+TCXFqOKw0ueFidBD29vF05WkmIog0/n0sG1X5l8gBLPMi2280K4TN zYXSLQw5hPi1a9MDo9lQd1wFPTVxWH3mVlcOoERey4rWumJdtHOlnrNrDBozFClVYWWrttl1LzE+ SPMhER9nH9XvsMGvimLpS8YDbcTPZTAdW3ioCbEpqr1qf8Qhm8+P6gWeGqAfXvvoPSj3iBwn4eN5 4c5bd8d6QzAgj+qAGKXGLrCBydvJxsNbb/VYW8hbOzQ2VF3+2wv05IWjtIEkvbWmbGmQ0Gt9Z1n1 Scp0/FFA0SVu26lTf48IYUFCyMNuQymYt2c0//Vcu1hZHg4DvDD/OraHt79SFZROW2NqVXJWJ5Ew nq+m+aPS86nnFb6F2wdfX/iARhcix9GzL6WQQvsLKpLu+VAARmrsaeeIDi9BNKxh11NK4GhEsf83 cUWVHmbzV8fzxNYzD9b7hVhhjzaatpYGjmNDPC98a7Mwt84cIqpRq6EGDidQKZkRNlyo9H1SwMkG 0YNlwR/B0IYZ0oEKzRFFCxa/YqSOG0UlOEKT5nk0vd0fyXC/vZjjeQwY5E+cslW+irorEEomNicM 7lkhJdjl2tsyqaqAzTA7rJehv+ZKd9CCNZGZ/O6PdrV1+mnV3z38KfvMg7CWKX9Ir3w9cUBKu78e D/l1itHmfNvYf1aAauHEjnNH5fIL7B3xIDF9uBwMnaVN6D4qhsVAZSxRFdl1XlX0TWsqEiOfg3De 1GM02z90Mc7x2+f2SvKbDw7GgREkohxXjhYZTxPclxQXBaGUNnmIEawK4Zxt4jhX5dZeESYspZ/H 9MhUJw6ExSN5y/OWFXRB9yLxEnAM3qVH9LjtWtYLs5fancit/MSKyPt2zEOvhkcKrQWs38izd4ID SZ2fMou6PWo5Wdi8rtIs3ffq5G2xuw99YDp8E7q56ahXfsN8qMx14jXqPTeOXAI/3tZU2ZB+sMRc dh1EXD2UuESALPzaWJivIFBC0TJ0a5KOtCP+hTF9MAcSnya15Sdf4mRezUg/r/7RrA/FiEtd7zXd 3olUtAv/kLYZ1zk2qUW8aNb3+8MFi1cjX5BNzZzLcuOmV5c15vsMsrz3GfvYNOAorkQCHhp27vuo 80PS+7RHrS1tVFScjS5LXO4GSVEsu0yKfSUGStPA64KBu0ydgIIgk8TaiIjNxDBWTns8CM6i5mrI MCea86r9uerf9PAVLWBwlK59hdaa8rgCN99HrpRJugxvvHRw1RmBsnkUebV2T6VKIyrk23KxHEOp enqinO2sdJkGKi3ZeGxXeuMPy8C5lVC9i53Tbc0bOz6Gc8sP1BWd32TlMEzhB++vM5tfgf8osvAi 8nAzm+3Q5VnWOGU5+B5jz4Jhl6G0Dg0NCVsCpAlO2yhhnV6JaFayE2W80GNzQkvXGan3BMiwl+W4 uAlpiVaWmalhDjs12zl3g5rOKbiBD05Eqga1F7RvqSlqMXJbgkXQmwvBD3sEPTM6zVfiU4ty3+97 9CFIIww/C1+La0XHydWz7T2qMDhEmhlU7SAFN5mz9xXsXhQEci4mp1tnP1BX2j8L2YcYfKDpIVgh 3TnxbNpNbW9vF9Ac+UkIVsaftfdXVaL7Qo3Q+AvNvieCbJo+prXmYF4pt0WuWIuNxMUOTRBuk5Cj MzHNt/omQKX2xVK2x5mW3V/WyenJNY5EQHglBUEHVny0aIQjWNpxkFJsLKVkDCGbhaofgRD6Iusv b786jnIDz0h3tjxsfTi9QIsO+7oXwbVjq8D0p/vmfIyh1F+kBTH1fbWG4d26XS42Y4PZnF4uriSg F1Pj/usPqALZw2ut00012urK87GlxzDs+peLmRKI5SghsfFHl+plqnsnnT/2HAlkusVHk+NsUYSx jdHUpB7tDwUoLMwZnfEtReTpQkcIozdQ2hcFKYKYHGv5R5GZOwiyaIY6zJBla8z6CApfXSTTQkn8 BU9wNzaTvzwFOj/3pffEuUv80lI8RhGW63hOiLfiRK9H69nadKbMlJn/IWtNhfhJ+ROsHoQC3M1z eB4NbQ+sqmIiUdiH38LbF8Zp0lIozftySOY84snvOdYhPp/iDbzhH9JNfPHJp1HVC+4RMz/bGPks vS0jr1B1V5Xkdz2WSFB3XlqZOXVVkXb9GwAJIPbfekt9RYHCw9jnS4NSlphDjfrzgUxPuUuoWFb8 x/iBNC6JFx7sz8xbamcDxlN4ZkUxKdiCkp4vsElqE8mGCxdoEuQnUoyaPGZBahtAgbL2kXLRkXLJ KVC0lycTnMUqcoFyyNS1Sx4zb47vXLG+rItIwSAY/ZDu48Q8Pyan5sNbHXr8ixW30herrgpkDQ9e jTpngmL7l4JyqXtRMYU1qQzMb1pwulllUNxWzjh8zMMP7NKHppaPm607CD3C66r4r4WrbkRveJqP Oi9BD7x178TOA+grIK2Mat5FZWlZWyVJ1k3FRzveUyi2XOwHrkSXZeavVHr8D/rBKc0+/YIVQlsy 94AGQ0+bdixn8AP+mehV1hPPrjDpzQ1/zwP6/rLwpt3oIgR7yWnL/NUwzrkCgTawWDAe8kxJlPtj 707WPTgbY6kE2L3b9u++RSuRuxzzgjpCf4Tf33/+dnf2huamTr/DX64uQ00XPM+O551d8xTDJ8Lj IEwBg1OMWYPxweezZfPlOAah0XAl14Lo3Nds2wlW5HlZz4iDDaePo0J8eWfJaR6kMeGoWXljvX1w euEIWyVkZRenzBLLN9dnReMYb/1P0dNKyNS1+ToplE0ReN74KMozJmhZteG5UCTJa4tXfArhCrMn QuD5RHZwhLk1bjsO4GuRp7TOTWTbLC5ICXfUhZsJgb+CQ4m0yFNRr3kTbfuZREU8mgQFdRNxbPbL udkkWarbu1iSQyeT4OzgvvQv/dqWb+oXzHp9MoX5lCiO/DvqGFC4iDxXWOmlMf4PnVYdFtW7rQWk pEFgwEFEJKSboQWkpLs7RkKQ7hxKujtFQJAGB6QUBhhg6O7u7gYv4u+ce+7znPvffva3vrXe911r 71n7m9UJB7b7PM23D/U0JmyXOT/oqk85ra4jXXwViaY91c3A8Gi393WI2D5TUexFIseZqzM669UH 7ufyfuz7VqwH6Pob3QldyvOKHmR9Q6AticUX5G30oEAf9PriGliHDzndrRM+WDsCR3DLJNyqssmA hXhDCr3DB2BhHJpXR8m32WV5Ei+e7Y1dWyCwr2MFxFt6uswlSwQ8G2r70l2zdlSla8LQNda251s+ OP+x1voXMfb8srf4AotJB+OVnHOLTPX4tFCNYmr40TozV09bKarWpWFZ+XphzLAz7L3MidTE9SQk NRrc/XWOYrymiY951Hk3ddDQum6B8UznczxS+MfnPjT5JEf6IraizsyOk/Q5NdQWqrx0AjG09bUm 271yS5WXPvJfKIBwAYKMdMaCd1K/3lZAbUa2nfGeyJ9MRZTJHPrf9n06e42e2RCbsB/vVeFt/DbN UmSpUp9/znt7CwnOC53jBO7U+6IUpvsK7ikQzrlLGQmSRweMCR6vDtnBZyfQe+LF6ztjM5j1mF2n AkYu8P5ruVKZ7IAf5t2R/44j/y3XvxMU//nX78M0xZfYFisYG3bwPqQJMuitPNQCyFOwgxjInj/q cCEanuBIshyvLQeQWXdM5NNRk/lm+1g3XUbE81+2+scFl1mKXpp1BXG9v5j4KdIUsGQVx0lEU764 RMZzuwzzWKdTXSWIpqomfGeCY1p6iRO7u5G3GFyl6OCYQyifWIWdEimU1rJc/MGwYoYjx5BtdMyS Xvcc28q3y+SuPaqFxIR/pEOlTTXmEfLuFM3Tfio+/uo3cmReo2y85KlYB3arW8LmSV68reUqDrLH Ipau2WrNDd0kvg59OBn9dtwsZ2OGSP9NG+SAp89G7q/Mkf+OY//fzvWvRv/Rvz5IVBOHsIK9wZY4 D7qD5XgzTWNSJURUM5o9G8IDdIQJtR0bcQWu7VNjBNUn7DQ2YmQ6ok5RNt9+sU2YbM/JLbJSemqz ow/g8soU0RRQ0pPb6H2KYllHBMv19J3Ofs8hkeTm9ClRCdkaICtDGWojdRT8LYW+c4WwmlfC5Dkb mSc3irHuuG7PT7KB3pStCetOuA/OlpeiyR3srG+t81CF4ZnQXAbwxUBBlriy1dPuVjb3nM+LqeOJ I8g38xMsxjaGZOk0Eb2MyxaYy2vw0Or1jef/tWKiYak7dfdXWEh/h9b/8wX3V5N/v+YeFNHr73/S yoaNdtCwIJAwo8+L97LKhddYcxCdXn8nbJsy7eXVWUf6MUDMx7DZxy1IQrAyRlFZdLzmBdsU1+XG 05my9VmCx+pEdNVfQp/MSbNt7Bb8XDBhoBzc4cTUePk6xbqX7nVXHwCb+7XpSq9QohFDdHuXzQ4M lHANFeo8svYzSDXJeJpgv/VGbz41/vfOwgeZhL3vla87C9eRI1x2yVcFQ5hSlioYLhT0Yaz+I016 6gP/fcYogjK4cfT+EXIo+v+/Ytj/zkh8cJzmIbzz4TynnHBZe8XLLn+gviOxORGX6dYXpy8rs8M6 bmwmvZRKy/1qteP2tNYt7004NEHtdVjDinjdZz/Ug4+V4eiMkHKfO6dkwDmIdYlpFxpj+R07Q6Eq HZTprItwqJ+3JBP5eXc9b4Dz+XObO6usbEZSENLo0OfptOTVpUIIxIQD7qpsPNceL8hYZWmpUNUA seGPpLtYEEZbRYcG7UAa6BV0S/YUL3V2bfxVBwR6jxq+MvUwZdsT39pUNUIsRD+tUq6APr3bsGWP JkUdPVOtDKWtm9ZZqft1KWTb5MOdJoWld/DNfmof2pjE7qP1pojXHapXE1ENas87ovIXUECAPsWb nVpGiCSOFo6Xe4BkIoxrnQkKNZmXvWvNUxU2HicROyGPixksIL/bry9tyXFWYvTulQ2hGD9T2nAV DFezob+han693uhk5OxF+YP+o03Dcl0zvW2Gk24eX0f+pi+8W7a0qf3QxiBszr1sWYtRSJ7cDVWm XZsnVuoiAnfqKjpps2vZfLQ9Rhn/xbxjYJxVjxl+ySb8FG9YO2Dykdl3OpnGha8izb3TcXaGSy/v KPCq0tHkB1qmESUR784o4rYp5iHepyK0Ta+yZo4UYsqyDIF4cLjmMl4h7CxLb7EGkD9oAlzl7FFO /rkLEyQzO6/jjY5PB0IGIaMj5IK/LyhNok7Clcr4e1iOmNJbH+uVO5HkVw8LN0UP37pSV0zbbnNl Ik7nl8zY+0gOA0k8KUl/GugZ6KfHX866ilxoLIAcFg2gbp2MsCJhst2uLFGLEnZ8zqkN88uXiM0e TpxlfIvHpVoAr6HZlKol4SxJxBegFKWUOVo1TjDeGqFOVogSOhXCxWuaxAKTB9RKxFHYxeSJ7giw ODA/e3b5eG5ZyFHxo6Jc27ly1QpepUWA38xsgBDuUCrKgPJr8t7qeVw6c0mn8m2kn+hEFxs3N3LP 22m9vfUSLuPObqKthBYwRnJe7PH0Ew70DvohyqWtih2kTLLs4VQxNGeDIO3JkUlXuflTL5Eaa1q3 UV8jEiyfPbL2RtegLg8a97jtd/4boSerxCO6vLvW9uNJlG9Y382rRevciXlwwLNfvJr1E8leeux1 tdXCK/aE9o0JfDgG92P9l1nTjpfOGermUDnw3Iab15APBCEr+IHoGzfjs2lPPkFKkWbNY8omvqyZ pWcyuvoQwQkfvbeU8cUVI/mywNmMwi4UTWpvx7S4OqzvYz/5W6tBq8oxPbI/iuJXqHSTRj6UagKl qo2d4FzdiVFJ5qn5dPgQS4rLb8pJyb9bS3xXfD68I2yopLEuy6EDkR+txKFBZ1VjGEQ8SI54p4UJ iqIE637/WB8CmRqZFPQIHMtw7kG/eHZsElfmJqrOdtCJei9NpOmhc+d6I2qEFgXexwhYjm+njP+W 7vbdu17IRYMkL13Vye0inS83GlMhuT4bI1C3KeuNgpmnNi0ONp4FrUR9BQMsOjCZTJNl1Hiv0DaE xzPHQ+jTqc83zbQ7NPP6qUJsOF90Hlrrl7qXIjlUbU/EDqJOi5KmkXznb0PFaXF0ETId5JEEexbI RkQZcrf1zvLZ6nrwo6cicfNTvcfIqvU8gKZVKMDftu1cqIuv3MxS12aWO+oP51vQPcZpwXLBMWjX y8aqyDJ3CR08/BZc5+wSNZ3U3Icl9zZSAYM8gHTveWOpV+Z+ylN+n1F8vhpHHiTZ2d0KrF5clGgs /s+1jmJI08s2jtd8dqQXBfKNFD+3MGb6LgOr8xu2JwqkehUw/tr42DyDbTv1xACe3xvM9vEF1ZRe z2TgCLEpBWTiOz22W88wkT2ICZLL9qN7TNEyzVc6Qd74C7tokypclr+11tGkktmrk5vCylNvgKAx szr8Q0s18zAYSveKYnGa7+cEuXDzBzkWcmTwfoa+DVbG8oEZKmFc1MFulkGJw0A/s0YM0VEgKqnT 431GpQgG/99MbmWsKiRiQwTN5b/YoZD+au05ZHtRqQO1SuwVZ7e1z3FOgYpk/QdCSY1+2cPK9wsJ hxGPDk8efL5eJhP95QA4sFZg2MDI4sgatHcnQcGUkbq4t8H36RTjYyHletyv3MEtlg3mWNBclxsi EFbXg0GNtrMmsu6ZKhKPV5TGFHIy3G9Rs8d55s6US3XPWLWd22Z67XXkuwdzlLu50FWuwBxqt+K6 4N06wUJlGf7WwjDrCRYTPhyq+7gMZcYNSP2WaveAipbIoXDfxD/014uXyKCKd28jyhKCvlB7dbsF 71dnBPei3rvv4EQOWeeyodrEyObIIgi8sWOvu/fe7SYJX+bD0ZW+9x4BDuRBWE7cCyxoLki9c5AR zHyvrmo7JxBh/k/QrMUXbY7kifeui92CIchJw/gBwQvu9xBNBf4N8Zf/G6bCfxgB4et8ke+mSJpP Iblq2aCFos/AKOvqkWB8aLsS/504n1sxfchysOD3v1sdQFlwlWdi9/HVE2CHBIof/rB7nQf0Ccnn AbL8EbuboE7w+yLGH7GVo3BFLgP0uB73aUry8iMpfgDdp1PY3InaScsKBVcwPyDqPtqzMvPDEUma e8730HWEZT9g/EnyIXYyEENKtf4fHljg1sFQxgfAnAsJNvZTCTH36Sfu/7j4HuSxkvCQsv6PXYsf e/b/pPl+O2lfiOmGvaj4AfJ9YmnAbewngX9c1QVjwdsGRcbx72O/XiZfyQFZeD6A0oPhaSvAVv+5 XfPv2yh94XlSSj8eFNeDAAFwG8WHRFj/SrU/wWBIxuIPuBfUbWUHZOWZ+DcC+BCS2CUhvsB/D1wq KtzUhe5vjgRBrFHPfWj/shAUWOD7W0iCMAjn8gZlEeZf3tFAMvhN1l96Bws9oLThP1iLlsie83FE Tf574QQEnVp+QEu20vkvtIIofRF/WYv9AUsGH1x+eBrIP1oAey3d/kWC7P+QyCR/TvpQ8gddk/Yj Z//UPKVCdN6/yngxvno5ZRfz74IbjRDC8iFH9jjZGRT/uAqzvrgRGjs50kQru6RYPKaPpqXpW8wP OdA4/+4aEN2NfkfrUeNB5ZJXgKXEhchrv8GUL9zslckgpfEVuL0yHBfz5xT0PrtGuPH41v8C+DKw Vi19fALj06HFNGDtnjOZn/jNC2qAmePaNfreGJwYuxDSYe7XnpCWwnaYFOyHbwcFr0sPfciZ0/Z+ V0XQ1Xr/sjulcQccDB2KukTDybZVUfJi56vP/rQyImNztixz0SxNaAfMtIAqE2ycOUKy8PdFlpeU WhTzUixPgCDTIfvb04KioJOPcQCY7bZsuq0Ov6/2cAyb46Limmbi6nNHwKs8W79cYxqGbTfyA5E5 JxiDgq0OgJGjnCe3mcGDOVIjDfn4vX/4eLnkilXGWQOzW81yCOoedKM0SZQJcuVvizVHL7PWukWU 6vinLWsb/hk6/MFgRzjNVC9tzhUo42aXw9X0Bp33JZFCZUgyvVo/Z0wuPn+g8XiiUq+NRiqjrFbt Au8+Luv1bsui+rNYecTh4egFzNL3BiqUZcrR0dQk9MOuhL2sdos0m9JhX8MDk5Xaav55drO7AImH 4cvt2K1qmyoaj8ivlVvTj8axJ4z5l3F/rskoxLm1ZH+NQPnBbFF/ssFiT/A7Cn1SHuIq2Ay3nPyd ckJ44D4zH8u7kHHfhJHtwFxwtv+35+mYLdwMSlqnGhHtrKLQOsXsyVc4qWoXN0CN2IofzNohgwbZ mOIrHpV0FuQPIo4kkqTMM/ILjIEB6HnEWNRw1L79w0gZNKFWIpUAt9q5ggpM2PqY//PbPKEmAFFQ /9s8u0G1ujjjM+Y0n/ACX6aY3+6DJ34dcnxpYhVT3lwSZRT8UbVHnm2QMGmtdtTwWywx3grxyQ+y uaPftxZlQSraVOFPWfFnn8efdg4m1htj6TjoMzrNKmm0fX6xgzsKbAC+NdYf/FBpUki3O5oW1HuX PCb72HPrFKCHl6DClJMZk17+KPbaACuhxp0Af1XFUAh4R5w3XbswjO+F/z128bKOeW1SQOtZyisQ hUI3U3kqT8ouWLVJNsPGyLOAOb2gZq+YgG+g+hOCe9N4e22di1u5WlIed3PNMS0tNLHGgejbeKRH 2o0HJMtI1TcN6p3uRnxDYhlfXMA8kLZPDJkusfIWr/ihmF5f08w59hVMPfX1NfUsVWn45ssOqLY6 zCB48qsV9cJXy+rPMqO0KUrx3uOAzSROXO4U18zEJxkzkd5WFQeS6s+IuVNBFbSEzpcd4/GemN85 FG1elnyNVaptBuc7UO6CkAp0HtFRp3vKd5xPbqMbYz8Wq3Rgs+a8rTDxI5b39rA8+jyknJ4hFUD1 cxt6Bf5u/q6pcm6di7Z/8i6eeSBKcO3rNtZM37jWgkZ65BG/wuO5K5YGwRQr4wY88PiFAn5gFk4D yuOz3rCebe8LGEB7FrqtO8heOeBk9dss8iiNNGk4ChXhNm+/M7ANevRK0Hyj5WrqWurilr/kUiDr wnDsByKo4pMNpQ/TlmvMfoNoqNgPxcRPY41LmoYvYRe2nsoclwdJaVYffLx0hXWXMGXsLxQ7A0ey WklSY8BJ/Q8t817pLWb4e/c1NkqWS76sxxN1gWWRBm+R3R5FkzYdBTQbu1fOkdZvXmmFN2YYGupy nUiQD1rl+c46wlbmbsfe5q3bUi6SfXlsACzk1fRE5x6qcJj8iPZkOsVVaAtZO99aZfNKOT/R1OVL 8oDs3HEywr5BXmcazLx/O+0jKmxY3T9+8MPCusrQNkWpKrzU2XH0y8Et9/zF+3hjdY94xtkQygo0 DfyrqF3YnTxd4IdXWu+BUXghUMGo5COAuePUbLAQSgwr61a6BNIKRMPUZJr3JckYxAnHpli5h7z+ cf4k6TeNUGybbclL8SSkF3jpYyH5b3b1D/udhxvLTv0vBvOmtT3EiW/Z8n9vQPy4+hZSLD8vXcOq z86lBldcksCIk4JkGu272zksNdXz/JYtpnfgQpvM4D8fSFOQYScWvOSCGEvaKLdwUbW1Q7qp7TRP rcSXlo29+VGFqlqTpOlYWWaWl2qvh3LDvwaWeL3zbLNE91471daisXz/Y2tYQYXnN2m6zveQJgm1 stWLZrPhd7gfcWreueDNiHZLMnr9Wu58jd7o7MHav554brxl/aikyBAvmIle7Er3LXw0UlTNr4uQ Fw0TsXTq+1/PheY7uQlD7y+hnv//WQDHn7OAmcyHswD4/HyPN/rcTM+gpXXYI+mATonNOpcZD9qj Omh89fwMjmIBkwKNmPiQe52i4YHoklgC8Y/rtXq7OCZUppbV7HDKzO9nvdGGSVjrqjoJqX1wlmOv cZnjIp/OI3jltVpvlOn45eGu4e8ji7gEdZ2MrcZ3x8VOPTWNwIbjYp2m55Hdm4L6tPm1PQVBLKcl RwUefEPV2jzyUtkcy15t3h1SiFeIWZe9bRM23fKhmYvMTZNUtfzCcHhfe2qWMHOvZSSRCDnx5sui HgeEO5ThmV05Qp1DHr5XLI2ouUiot5uf6YlX13HxFSAFm/I6ZU6XM3IWX3Y6z4HdPVS99VOoW537 qts/19oOs452eFyvcekzZSAqPRNXXcuOK6Piw5YGSN9JzydXYuutwyYy5SKyKz1PVK/eo/n8ZvGt 8+Re2ut0+Oj7FXI91XKbBPE1xxttPF5wJLDfQ49D9y8voZm58fD2dFJjXajT7/nme7xvfd38fT/y 9gnLTjKXZ4ZmpOm8KZMFtpuhIbAu5tyjHjN4P0iXc4xo6z0X411fhH+hdWFt7oGQiJoPhvevy91u KEXGSnR4Tbg4vXfRyxbqogCtrrXnGTNZeg5uLSK/jH7lZ7BWqXuq3u7CZq8WFrdreu6SFU7EPR2s 3z3bvK0lDawga9YQx5eMXQrDJAhh5x0f6MbELh/3rdi/UuCF/CBtazbyD7sJZWyfxO0HbzK566jV dvnaMTRZFaROn/YwIzHWj2gGjXHGv55ybgE1KR7Bw6vX3NIofessbbslhENMfby7C35yK2rf0mdt BbHoSDWf9pzAtsAnfsZrlz4D2XgAN9u4SSTY1qh8XHFnM3b5sMFMrVRTeu+QpbqPp1ETdF0ytXCd 9+AXB2Dkqtpan0b93MnGVwMMdcXTvv6qy+krQ/pNt6m7oFfdp6f7t57+/Kzn8OWRnW+01+uSdIdi TcNw+e4Jrb7Bk0RVsAe4ag4zQ1W/xGnQzKbfXkGO9gNtkkJyCWWjRyQvLRNt4bj2GaRrkRZiuN3/ 3dwlOnr3zCyqlOgQbnY4op+TqBnxIvnb2ZRVIfUy7GbyEqpgwlPVKGTuWjxdiRXFR+pqOo4O1hPx fMFsSzfLM6zNrg/GrxAoOSZrZAdrV1KjpuZtXy4UfTuvWMPV/rG+UjQkUmhhx50ef4oUIZ0Zxfrd 0fZsvFBiCP1r1EkUAszacCPske9ay/ikf4/xtL6+Quv4TgTWim58KPQ6ezaMtS+a3PhmufJqHXT0 FpR6MwAEBQd/Jyvfv8pW4V4yX6xUo14QH5TwD7UKoDDGzEYHyXJHeDrkkb8fUJa/qDrQKq50eaRT /MklMIgyxTqFw2gWgabj5ERtSPJCljfOFvrJNdA8XG9iTT1nzqfUCybOOoGBTu7klGdA/kKWL6zM YQIrd5wwyihrRzXKfDA2yv3jFWksigEW02pKl9+q5QcNG+mOtfVP6BxRoULQLr6BF68yqMj3I6OZ ga02PcEfG3nZNPowkVk3HKPMCeL6YqLPJTuTcI3fWIiLzT0DyPLn7renZ6DgiLWSIR/NXUy0Usl1 2oR2eqKYYkl5lPTzUdVgyIA7Oz2pzWSlBleBUaIr0m5NDjmiUqA1kdQ70Iv0LjOkVNNHfCoG2Ako zGJDLS846CI6gZBOjqOLYMccUWkQ4M1a4IPJmsHEOhDx8hUF9st0FZz6aWK02OUJ1b/BWx5xaDoF UbP5lYhFn/PBqzakpYzwJ+Vo0x3lEgfD5yhKxh3WOFmnXlH83Y/VGsrEFtrjtVkkvDtBS3VoxKaN 32Hm32LWgax44o6uE/gF0mImCohHRYsnO2/CWKFAvHr1HJsBSyLZFRmbgRMXgcz7u4A6/RGky4JD Ww5XKYXpMZM4z09HZDmxpRY/hzeABJSn9Fio4bG5EtL8ADlcDFMHv9aVF1UMcczxMW5sOUB8tNVH qN25l+oddxRYD+FW3gyuZuIHdRljI+JSzYcIFEP9zTlTmZhC6LWixJRSenL+eFLDxcxzCBUz7zKy 5Kj+E+uXgzQgSfwpkyxmWDzZvdTokG4qYzVc5a9A9ArBVO0/1Iz41Jzc6cRaqjjmb4d+gkXDo5xe YjPc667MJ5ZbFWb06V+e3gKSqLGZHA39Xpo/qMQgFajM15rDcU7MpAqV/08TkgCxf5mEsexLYzM4 9hkXVX0YIohu+1WVKkeSRIOWxBctWlp1XzG4aIk0xmo8hoAbOGLmB4ZRadUHQkI8tCQaY60kei1c wFf1tYEHV7KtX5nucUtrfet5EKmCiVh/7pNyBfBsVKDxNy/FZBtAjie+y8QhonWlE729Cz7DgfkJ HaWb3VgpSjkHKJGjkSoeHuPElgIk6lgBBHWp/NIxP85E/PqTOXp4oCifpH+V2v8aMdY35imlAEMq NFJ1aSkO6bGZ7iUx1s410rZX+tbzkDc1jUDlSSc/8Rs57fYHsz9qahMEmwf5my+i52hMVj0IXsBI NcuMBekOYNf6ZpMe2AbxN8/fCAu5BOiQyAWYmCM+51EcC1mwTk/ssi7xVP++KQKDseDfvkg/Dzfj 5l0s0gXY1to0dlL2VX/eqZ/ae+9lhdaoCPYU+Tl3UscVGYsupL1tkaZZL5ia2tcpIsRMsjkwnkWS IFLokarRrulacSSrX8tPwePYOOLMOqQPt1u7Ou5bdh9ydgpiqBuRnx/iJPrpozKOesSvL3dSeKJR iyC36rdinXSuKMqs1ZzyLEquP6taLkUrW3/DKtDpu5Efe/8Dh83uDif2Hkbgv4p8I0ddeipv3uBp ZBv5A319k1vYil9tPFK2gXaMuuHybHr+v7YvLTgSwolojx45Pv3/2xfOP+1Lo5auY7rkU599ud8o 8uCwBHqMAaHKjJZ6RRptibbYLA5A6SurNg4/m28/m8GuSLtPduynLN0rpBrAP493f8BGk9chdEKf 2Rwq5xO5JRJpVgTclq8ayrwiaimnq05Wr9azyyxcnuZVhNwCLu1ftbCLbHVfg3CF1b/FVkuhC6jg lhEtYdiZtreEMMzZ6qOrU+o/Kt8qLtDEg24jdnYK2VzJ0TvRZ5hx8VyAr0EzNPjeO0C8HJI3Ixbc b7MoUGbf76MRSFw/RYVC6h3wP2MERUs3N+vs7T6S6PK1HNrvxtGuUkCSHmTWTqsX1umgw9PQqeJy Etq/QYj1259tXxWHCCqmua4GbZebbUZNFA3b8I7oFI6pjGo0qCfnl+u786BklAleWaXcqmyi7b65 gf2aL+lWb2LSRM04jV4swey7IlxPb/h0/lRafYu5yUBT4NSjofT7NMXHaRrq1hVqU5oKMmrX2mgi ALNr5Y5k8UsblytVJIuwzB7h4s/jafVlFl/43fkTbjzVLZ/msG1/DZuyHD+VLIBispFRSAqgG10I 4FUiPrZazeOPYAvxGpUF+vW/COlw4usACiD13+yiMTNI5FReuQuycIsvXmvslcu6aFAfPnUpnSvh TeuNykpdVcnY9GLvAdkvqYeVMmY0UWGEVcjg07x18LFYbKVS3CV6At74GN3aljVTcAokdWvIs9LJ G3uvosuMnmScCjH+9DQS3zNWbMjKnzrZrNzIIrjja2aTgd1W2pSt1dWzhYRTmhfZQJxDJJ+P00ES 9uCOYjMcjbFamXny5BKhl0yIxI7ruTncRJq6U0JtaUAn/2JuymM7wZSIDo0nWv6MKpLJRqSWw4TP k9oxB5/6Bwoayhtl+n85G3Y6NE7IWnbs0AOuOwYfs+cIf3QdvVA1Kwd79tWyh9P52EU0/mr13x4o FeC9ambTtG6fpPS5/F4E3WY2qAuBqKYQ5+wkqzl0E26SDTHtvlbBC0HCtdzVfNXllyaHJ6micsb7 BE8QHry+d/PsJgMMOooK5UKpzzsufKHN/GaWhr1cedrbEIfZkYMcp2dogeBqwAojlQVESLidDWxo +l2d0gFUnJUaEbnkqVF77+A64OiW5tiIwT4nlty3P3hnsWTaM/WM6P1RIRWVzHkeBwSscYXq9qQS W5A3avf6S8YTZF+g/rq/izTyCOy5BbeYKqp1Vru0rzcEQD+3UMiLgZtb0EgvCWLeAawRp/B83ezj 9uFg8g6iEk19SxsWnWs4yKhzOZQsCViii7s6cYuspShdc8reO9wVZw7MNWF7YaaPBphJI31F+E7S 6SjTIV+jKDyh7x2nCoNicTT0bDCc+dqHbNmPQJWc4vvgQA0UTYFqFvShJWZRdiWGXM4i7QsI1mm2 RFf1i9RSSx5MOWbWFynEeKrXIo2lNAXtR80g0hFVo8MepqKCvZRk2CG5MR8H+zV+JiVI4I6uRGZO eAvhD/5hZpkqa8pDzwzvMHnzzk2nEZHout+dWNkg4yku4XTKL0GUMVTtrQKe0HdfjakP8TPP/BTw hfJd297b4ic+fj8/hb81FJWqosDYbtONV9fU4KPMhIgPsmTVLDeV+QUaB+DExhRgFC72Cc+Hngyk T09vYmkKzNNglsi8hV2jcrGIga6f+jHF1mbm0le5mvUpwqpjAJhopnOsvXbM7PPdxLaAu95wEXE9 3sDv+jc/GPkvuTUOwhzhc7lPXluK/WR5zHBSK1rNhdzT9j+UenVUHO+yLa7BAgGCu7s7IbgTIAT3 oAGCuxPcSWBwt+Du7sFdAsHdHQZ7Dfm9dc9966xz7/und3fVrl31Ncy3p3tNQAJcCumT1HqY9YHo wbpR950/KQWp1BCk6Hw5x/uKkNpC6disrrchJQjTxXWSI9ALX6U8BtY+Xi0FX4Srfj8vCjkYLjlO PXvLejoga7hgHsCQlWuDtWakPOPyUfQYxqq0zrkFyiq+Jfk3fLzXfWayEYGRNwJz+Hf4tppug3t+ w/t+MH1hvY/c4jencsUU+8RQTG92h67gz7wcIYsOKFAq1Z6Oy0O9WWQ+OQr4WgXw3JKjoq7Fn26i 0IUyeAKadNnSjSaKCq0C4hUlXrdlJA2f2kWl17eT+H7v3Ef6jW2IGO/R1J5qL7f9TUj9ioCM4ozR pa43qr8zvKSXUmMi3oVZ1ynzQj6VipRdGkqG6bvfnuvYPT8nzpDNmDJosvDz2adbnEBTI7qEDu2Y +1F5xV8ybvTyGogi55U/ulUs3faCUiYnkIVc5La+jMlk4e/sEEtZBV1y3x4FqU8jvd960heXPMCx +sis/8MzaEAINUQIM/CK+y583Rb1ks7TmQRa7gy2lM6Lt/kR/995WdPK/CtfwMv4/oOXcfxfL8vm wn3+cTH0kpD+sRvryp1CCmHfdeFhfbvJYT6h3+dkOHK4r6+vZ6/jYNQ7KeK+5G+Svs1WlJRcPpTS 9vQUcpkgRyLHudPRUFHVeN/qz13atv+rz+WugVFWr8z7YdPCWpIV6W4uKoZY8rXceXZpc9T6imwN Hq+7Qzn55gofaeQJlxqBR8Ha4Yyj0uU47MnPUgu3S/2m1qEtL0Rmk3WIW5+mntWOSHLYoCYYQ5/U dch4WPQaDZQY07533AtNImLjrWK+hxmlBAE071fJY8vKhloIM2humeXhdRpIZWdoIej5KGTZZyVN PM5W5GXjJUq3U701dnhHvHT0LmO2pcNKmx0efjAsYQg7Jh0Gau5Paf5csKjbq7wooR/d9pn80bfs 1puh2ijCz/LEccFdZPeRefAjpOmDUApnh8a2bWtTsouir1CRTEvu7L5Fvq5NXY1TE7TtoAqZqhC7 JlQqop3zHWitINSpouqLbEPHiD5V+1B5HC/CzU5NXmnR26IRSmKZp+yfHEj6IG9V8cPqfTdy8mkY UDjauifk2LkzkWHTavi0iKK6yUYDJDJVjgcc797w0Oo3nfdbH/mhxY+WzSK5dye0mxNHaSl1Vj2g Yn4txnKbWraCzFJ4Eel7Zr6ryc/+rnGr+mPGxe+GwSWd3X1DNsagx7OR6Pl+lYDw6APoJg6/Om09 66uzqrzlFJ78HoO92SWDEQ9dTCuGIbOy1GdG241YKOz7oRXcOvu5fXkdld/y8t7QKZUj0Gn70LFy Hj7EX5zNPyy62nysDKTfv3PQl5eZIcKI35RZN/K2CQpFtB0mR6aEdqQWwIpbkQ+cPO2WgaQvF/9F g9aLgzolL+uiTkgtpgITe+4h6nv9iuIyPS8MLfuCIF2WijuVGY+p3wfcfvhx3TSmovWQd5maIfOm AvEMChm+VDToaHGnb0K95I2p983hdd5CaZ3ruhCqgsGMX6We8gCtrBhXjisdvTLxs6PdfaIohLdK VAjPyTm3wSJy8XVPazq3OTmn7KpwFhND2wkeGfWzqIFwTKBokfC8NuKsDN91EeCQ6ZKMzppGkNFB oFCdGZUDHK0I1As1uijJwXPLVUC3s0jYj6po75tA2quFvjfISmcLJ9QrtwoSiUtHgZWGiV54la5x jrNCG/DWxZrg97W08JtXjwKNI9BvpKGm+ohM5AFDs0kbDu5u7XiF/WxouJEZ+c1mgKEd4kYyfF2B mK2A68xx5aPz9Lf3Y4t4hUUs2pb1qdpOKL6FpVsx52L3Au+Yf2Fkl4dw/RKwNGmSETboV9YRBCEB ysx8twoNykVT4jLb4s+GZuHz19D+hNu2B9NGRC6YmWlq+Weg8ypw4tItiqHudmyox3GY8nC+vQlp XknmaJaPEpb7zGM+6iY4yzqB+h3pusHfXoJeylKmAiG8vlCJ+eawVCUgoToLXUTjHJe+PJMBr7pb Q0lukMX93GAg5SJedKJ78kqn1ONGqVRuUf4n6hvWuX0seQTZ5SvpfIPTFZygNUGY4qNXWBShNBij mEV0YlCPVCKvs2GTjPmj56Sb84pKi+0+8OUHZW2mqZ7r6vlQGPqhNERjI9Z1pqYeIbiRF+wMHx4e fCtJvY7NmeHIQtQNpuKJPFeEDA5pPiQQj2khD3rgEBntzqBaln5lTet8gKeKUIDopiVVyqIpqPkZ Q58Ktd/GO/KefBiVrxytIioK41g+MJoCvRCFRzVCxggL3yy5NjrHnMGa8TRiLALsviGQgRLUXUfg NeCLH5M2Kvctz4bE3X7fPX/QIw28kfapAKvaMULUQ27hddtUP7+v3OV1acLr9YWAz8fYV75v0IR3 t3D75og7UqPOVoLkCHq9SXqjmr1zo+OVJJvGUK+kv55947jkJucOV4+oDPDDJ5JEe2VidrdXH0No GQoRK/T793vOZQJBNB3Dlk7v8BPIHtIDzlEP35AZ5WWEcXJJpLYMHMbyhj5FbcNoMZlVx28oyA0w ZR5NJCnIcpdeEGmC+QgDHsilfTcYGqCK6Xoyo0oyLG9dsYlBLsb3W7Ew37/QwE4zvwsr7dGGWC6X M/iQX9qwONh2IsBvakc5dFn/tHh9YRa7EZdXHFDsOi+7VsyZetm60864eZbd4yByyXPJdjIu3NFS AHm8jNXsPP7zDeXwk0hYWqzehVpLsNoVK+VdN7Rde9Nu/n0XBq+p+4+0pwEMittotTfCELqAZf0b 3/rz5/V4PhkEhHYL5L/9lfA/PyXTs19sLPE+lmvrujIfTeSqLHjaM54ckFeYGErJIfp9WJM+csMT 2kLoPru0lEP9cIETq/aa9j2HtEiztKQnb0QzGQICzDso4ZNbPS/3ej0PWqe7S6cqTbZRPabQ4eGr dTf7Jk0vIQ+3eEYcb9fTu2VB4ZZWRl0r7iBD+znmldxhr5pmfgKiJw+7yrYGeqLS6z9dYJO6JRth wubkw66Bq8n8S3nbs88ooukwQsgKRKWzyZ8fjtKdJ37/7jOEXvdaOCIqRXO3aWoSRD11cz+/hezv JPGyq6Q/KkNjmX9YAtvqRVxtP6xfyldoCh2FelbcKTPoCQi3NXkxXPU9Mf1pgRuJD0ObRetZ/jTY 9gAeXdsqr9fzpjuaTc7yihRovQEj+LcuWQkLM+Ecl10HQW0RtK+Uhd7d9QRNnzm0NGgzPVZognX3 8l1ffxMhqBSI8DN2Jbs/+AnW2OlYfhAw9kIv51EUffz01PToUs8fGX9nO6Se9s0Vz5gh7Hb5obll dUfCNrrXNq0rKg4hUJfpT3H8MZfzJv52O2V/YYr57ZLTb3fQ3fzV8ib0zShzuFHuqiinbpfT8FBV exg7do4XVbntLZjeY02G6meFgj4Uc1o6Qf5c+n5e2q1tI870fbJpmHMCydeuwtkNmT8xHXKbGQTh s2iEmXTwyLTz4TTwYbTwsjTwsrTwgzTwg7TwRnmy+i6XdlSihRFDDpno0Rw6CjAU8jiEkNKTudLv JhwgMYHQFhCKgISUVokTeTcxVR5O/ba+TsjXfR/zvwE0qStOzD6MCUxYd8sl4qJWejsAS1rpY/8Z QgBm//8AAHPuP4M0wOz+HwBgTr0AcYHYV0+epMY6oUL3/bj/Dg11Qol/QendxgLY+KgETdWWd3ui 5XIAkBn6C4sALL2Ab5L07D6bs42n3fUM9X/BGWIJmm6Mu3NLU6vvmak67WcUqzaoaxRVnE+cbczO +/vureq3Hg/EBWWlP301jr0HYb8bpuuetHnVeLo0M3vxt82XEKOdZTjakvF11fVcZfIctDL9biC0 9PQOhDoOs3rArWJUzr1UYqUQRjdhTSMqSL4RP/292nOe3LdurKjbzNT6Lvf+2Pu6a9fz9LT2BuPn oeIe8YDjQYfdB5y8T94WSJNF3sXx97FVBa/rHkcC9Y5ykpj0UtG+7XdpnxbhrdKZakTnfd0a9ORv vVpKKpKu+RQvkhMLaWOC/lb/8kkeFvO+mXFe8UxgCJROIbIi+XVCianz+th1gNPm1CVgzFQDFCiS tO3D6qMioDAxfCyuDRXmecMg/XrLlYCyvHDlzw1RG0q5QHF6s2DtI9cQsp0w4npw5tqhEHxQ00pA qGcgdeB9+lotdHlBO97wnLCVUJLqSMeoVotlJtni9zZPwRUTs12Dk6jpa+MIxoIn5PLcLZHP1JY3 EyReA/6N90gLFCKgn2072SAoZjmP3k6ayGyByEypOPRuGGqDRbOsCnRHtCt7aBlDeMPXfZYOGjNy 1m7+JFS2xY+mG1OwEJ9Q9AsjE9EXxyf5+cJTOIMH9FkYlJU9KSi/wITFF8O7u20bt29NupP5d9yM IdfFwvmfYozuAOcGF/rNZfiCILhgaayFk71NuUBlfM53chsU8gmYkAl5YZE+ObsTFCTmjT6IUklM 9lCxeb0+PjmFAyQk5hbqvXFTEKwfkqFQ0DF5pa9nJKG7xUZy3fezIQ3Jnv/vgI8SMZBq0F96Qc4E PBIqu9ijkii44JAU2f+X73kAYNaWMhBUONt1YPt3iuMQrDH2u3/AZj6gggagd0ycg40nBzCudqPw 9d/k4+LforvUhL9t+Jn/pbfR8yC8Cf8e/1ek/y/y/1IRs1eIcCKwrP+By4Bk8RWj7JCnYjeRSL2Q 6itzOMNOuD0xel/QCIRCufBBqTPdxWt8NL3XnDFxy/T7zAJ4rd0IJ7LLghKBEfAsIcu1tKfk8CyI WdYFwaAAIh9EEuybHroZvm1cbbWsUAkyUBqYR7E9YpEMdDKASgaC82ZaF2ulF18Zys51zxRl8dXr tNE/mztVRPBDfMyK0g9t4Qh0z3u/PLp2dpYT3kdQo9Z9hpf3tkNVl3w6I0kzw9FIqM9fJO2gi4RJ mXKo6wJCihe0uyUDHDIj7FgmUWKAgz/2pn5eMi5wCCL/1SHHTfSrwwRm8nSP19aKS0JkV3Daj1PH AdimE6iAnRtWDti5E4GdmxMOCMnDATt3F1vaRrh+Uj94CCGvEGb/zzOGtG4CIZly4P5FWIIKyJvf dnD8ANdHeQLKYsvK63hUe4685KA8cPyRUTqQG69LwZBTQZzxPGD/Gx39y7STYJGnVL/OH2H3M/9p s+u1zUkOogLHA1d0HY2jrsNAx9bcu5RZoNmO1shL/8dFU6DogtEUZlLVz9H76F8FLWiXQVOquPKh nLh6ho8lJKA/bQLehTDMHW9Eu3CR/gyi/YEip9rnGX/w9ktge6N1rykxx6fbSkFiITWXpGoac/fR 7gf6jT2hGMLloexandWMLjK/C7YLRR3z89/z3tk/IWPkQ8XJjWDBZV9ih+xTBM59jG9Chq03tK6b q726d4NQcV3y1gLlI+IasZrsY3D65NiU4jkFkj+PsSseLJR1ncZcyS1Cc/u1ff0Ok0wVA+prCC2L xSU4C5T2tg7iUBPyD49q9UyvUsG7g1XECsLa91+9PmHBRz1k+iMftgxuKM6tF230EbtGq4nnSKCw MCuskwYiStmqv7O3xh1BwWwwt3mH3MxQvi4uH3xdTcg1uNJbCPmgJMpOkRE/TMP2HjkelFPwK6Rf S2Kd9ObHPMmc8pceGmq/VLPkqE746GHt8PzOIMsZ/5NVBXYEC/zvyqsPlQ80uJ2/VD+Uy6aH973D wuYulcl8l+/z6DjJVQRffkXR1Z9kyYmv4VgSGPNj1gJXwxM4uZw1wYXJNuIMX+zrt8DFY5Q4YVWr yhw33KAiKpofM2P1465IQonAhufQDNcX/AJ6b51RgRcoERaTbFhsIprdg0DUacEF5BabDTnxn6th uapErAUBTi82ec0DIBVCQwbEreEqDEOBMrDzi6rdZODwl+gF+yIDs2rchs2/GlN2WsOBVEwS1hHl SSjy2uFTEs/XWe+sDcoTUZQTvnC+khfzXfTRBxpphU/dag4/9+BGUn9BxyqgceOtFoqoUVhM0keg y5xhDn/r9BezL6zK0BYvNQ7JdcBaGCUs6KxM/B3c6l6GvAwHhqzokdp2+FsjNAYMU4u7K2bNjp/D NQrcE6AQ8p/CJWDRgH7pwt+aQ9CL/rlnUrbnslJU08yInaMchDh135/U47CHR3Ctmd3yofB4N3cZ k9Ua/usmg40gjfi7mHSqMTexkTvSXRtxuMulrUhFMudUE35lAyLRpNT8i6tj5lHdJyUT3/TpQitS DEaT3kmKSw0icem0POlwys0kxDCNs3VLA6wNV6Q3EjpeKnL68C3GrnGXh4Jte5sJDV8aRAIbuHdy qSq49IhcMkc9zMrx8khVyXwuibboMcIg/IwWBNDT9WDXz7daSJk5pR88HmrmWpiJvBidBnuE1WTT P1FEH/dYe7q732vpuF4ObiaHVTnbLD86ODE4QLg+XuTOETAtNy97YX1HEMs792K7eOyxCXKavvnz AdFIWDoLtElyVUrpmO11IpH/cBKaTq2BuzH2CmdGk+ukVy/s8nAp02QZOYvmV5dAOHt8BY1PT4gy xqwkrqRGdywCUuh6+6c2lU/ON0TIfhDYqrFbXkf5n41uIqPVZ7/OWR13UKVZPbXclGvGR2wr1t05 fvSdVPQjU+Zb9ToH02MdftfTkAUlKLXbqSJZWzu61VXFL2rDazG0LXvRMtUO/jRnsonH17hxxYY9 kY9juJKdD8rFRnI1bnUUxibmpro02+bJ4zQzY1EZabyHwCnaVFGRrlponFUptDpqQpvetoLpbh5c iRLKGV1tCFVhuCElIEI+FBfpPBChvzV3Pj/MUVv6dnIC7rpdc6h7qNmxCMZQRApb35EeDe3aXjIZ dxs7O7WY9w4Ff/TCGdMMHpl/e/tR/Md0hp7nzDjeunp6zf7YUFXkybtxH/hQMTQKF7VvAW7W2g6W CUndmqMLIV08hgj4rd1Sa3RYt1DKNYI+v6SW9hq9mjOkQzurUN0k5Ef5dhJdRxfMM0MsYb1xqDWw KXhvWmHownlwOlzXT1s5kTxYXDGQyQseXnlWy2DNFRLaGR1Q25aCMngk7eddPh04Bzu0El/TJfNH HkpsIBH/cQ3t0Bf53dap7UdLyHB4Uxn0w9h8z1DPmuv3KLcFNTI/h22T5se9adSrHZsi6gL73MXq 97bXSojnGfa5pyWpzG9rzD8eHYnp2b9Fu8lQvxDxs/mIULCtdRhc0+ooNjT2vfS6FvSw4DhSt2c/ HYbLIf3hZkZkuWBXC96T/VhLi3HKuUR/uZNB7oxBXwMiuWvXqQQR+gLvQOMhRQQLH6XhK3zaGwzM bQPNvtD7g6arotjcdZDTgVoi9RF9EXvJgFOJkUSCzk8KiUPB/Zevxer30AR7OhVaKW+ewNoHaL8e 9k9/UvEMHOgr6obo/GyxPCbd03dFXViin9vuNkXf7LWFMa2hXMzgR7OAsrhxrPK8dRpTuhkSP+5x +1NUcd6y7ZnQ2SBz09+IX/sng/BCJkUsHfeYLkYx06SAV+xo/Chd3V5I2TZNOBQLx9AZovroItSd 62vQD/mzIOGpogomrmwSePf7eTCrIdYI7N0BCbVJnujJYFXHISg78YZmwQvrMaPoLaxsG81nsnxE z1EXdN5pnTS9pF9qIxgL4WxGWb/sd1r3RkEF3nWmF7FfjC9rWJXkZvSSDUzkpk4S/MLxE8p/Tiiq kcUflk2zVELW4klwdah1jZmdhofgqbW9xcyNBrbzIA5NAaOswDYsu6CQiJZE1g9IGJMvDGzW775K AVDsVDKkhniMkeZra28xOe9zM1YxegxB/0IDDsr9wPYpmsr5LRNIdOnRZVf0/FOWBlyTAQek5w0V glZpbs0GE/NHnbiJx8TdjapcVJfog5zLQW7FqN/YNTvE/AbEG7XPnYkJfVueIvCVCvJpOmLOLByj 0/e1vz7MNvB6bLV8sS5bK6TFM1o7L1rNYjUZk1MhqC5RcvdTT0asMyigBR9N7nwE2Sd+1eOvWDba RlTOZl+F1sySq/2V+DX5w4acy0quOYEoihiU4ywEn5GwoNFYVIvo1PznPunAH12k+Gmb4RHDNHad vSZYtzm/TbDmQ+bCye7Qkz+UpzSIQxFbUlqwhxevqMkNUAcAN5KGJXtcXyK7U58QXBH044vZd9yB lN9DcAMpgPUY55pX4+5SWfRgRWCTL4mVPDukFPeHF8uL5a1LRJmQn3o2WVSABhSwiv9X+jnzbILG I8/ehFnzYrLWWS8GGj3UAPgMWWjw35Dc+H9Xk2gMAbwQyL3QXgbgxE+q/weXCP+LmxQM9TcYDAW0 f/HNlymNnnUB/2TbBhYIeGBywYuvAYUvtvei/y/coQbAvIFB/jMXWIfxSEngs0++rHHOkMLe+q8P Y9b8K9co0T55lwUQsksp3YxYhEaJfAIfaiRJFn2eTMv18Nsacs01H1+P2e5j9Q/EMIBAuZjAdeOV SuygMhj27X+TONtxxZCJk8MweB5N+ZaDGYa7J2bChu5XM0X4OY3iGgNSlwBO4C7GtvKBL47ILNIO JghKW0jBoKvzAw77YYsTZYL5ZJr4EJlebugVAxJkDPo62yEix5rURCXtF7xOqwKk1jPfvKw1e3GV D56l3aRNwPm5EC3A9T/8+M6YT17cPjUvq+Q1WzyFAZw0Xc6U2A7tLwEltQIFX6da83hjV56T3ptW U0QHtfM4mkFfBIc/hGQbGfxhDJSlitK/U8Qf35DJNqaZ7jGlVMb40c464qd+3toTTUJN0AlTLjFJ z8QRTUhrZaSwTH7P10zgOvierk2dPLRScle/arRqzanl+fmGqkXl1+NkX62xYYJi2a1s24PpJfwU 8lnMHQ+zerzKppIZ3BW3NFRBxSqjzSiGY8u3dNLOfYHSVvwAp69qXixXxQ/iKpxvLsJdyt7J7rRk LRXncJvNQqnKF1/6V3pvf5HXYodbZnjlzwI/Lh6DZvVdVhz4JoN0nL0p2GhzHXBnRs60bNlIYUIK uuCgfWhe3IIXiGx5qudzcknLgzUpKmUcTNnAn2CLW4zSDMqkbi3KK8rLO9gRGJqUL8rmGFi9chNG sRP2geZbUS5AUb2j6Q74amhhPHDfPoob5lEur4H9mRCDXdKkH4UiS8z0aw/fL81WjLnziFSjqkD8 owft6Ird4o1DoYFit2UYgcAV7jKetpBgGafuYKpg8pm0emYCf3OHRuXLPSEuARVOPn+7SFJTz/uw g+JVNPBI4/6CyVip1jzslzkN5+rWKqelLzt48DNNbO9PZhZSJ8BaxlZ2JW3WWmwSjoPWcV6FxeZJ M/vlnj1u1x5fvfTSOSvmf+dysYaeGBxsOZZz0y5rqVYNX3ATyFX/mnSU3BTQx6EhaRPNouIbfQpY ji+W3r/mZ+f3skFcjZnbaVxIiD5klA6S1E6ioBjKvnTeWBgpbBJfs2l7rKrnZTiaTQ+9u8w7+bX/ fU8tZU7P4vrCqe7hvl67ue0PceiSxYBpP5a7tALnbx8iJ1/0pw6NAmIYhpHJvbXYXkXnJvHlwaLz +TOyJI5+3BzFhnGx6g9YCclKPOjDVTBHxRhjiilqIkHsp7q4wRxeHbGMP0+TEmdWZ9jrsUiNRPZE K6OSdZtQPRU51Z60Qu2X2iU1uxzZ/AkXNrTaHPoJu+gLl/CVwY8Xi/Bw69PZux1mgiCCmEh9FV0n crj1c6Ts+Y0oUwm0QMq8YmGIeOMaoleyyhpogWQOqtkoZboj/Ej4yuapY29fWcXmDYb4yE6KSwJP r+avozl02p8faHmBp1ejd+8mpozRgeydU1slDsDts82drcm23dRk187W5CZrsu0m27ZtTZps7rQz 3v97PsG5OJdnfYJ1tdazLtbzg9cLcz+r/sw/poliDOi/2rf5TombKGN+OnL99omvQLa3Z9xMdBE6 SpzmdEFsL1RQa7U7QnTInJgyjNfFkNYc0TDdoYsdpzCPtuE+ad6A1sGYZ1RhHHnfDSOJq7Zv0QDn pVOSP1WME+YCqcpheV6DOAcdwNGLH5rXlqcUgvlVIFYXdzT1lK77hr4EY9xsEDW8bCbSpzchpoNm 8/NG5I4OeXLHl/lTS9VxvwCSWYMX9eH9G+xFLPn8km665cBMgk2FcgTtsmHymeQTNxvNT8yLW97n 7XvWvI8QXWCA6joReZVIT8LMuW+gyLAngQCCBmuygHNIIB6uNXIOXJbiQfl4hvPcusZ7QON/cTqD atQ8vTskQaimUyvFRPeQ5hb33YGj30n1BI7RKhc7ih7sC9r1D1vArkZjCRqwsfgp4a38Ynka5PLk TcbZ/U8gr39Ju6qshjf8idYdCPXx6YYX9NzugfmhuPkDpYjMuXUiYDriE6EjAP48Mq1iBnxEpP3W KmoriXNEt+v96hr3k9YvzIfH+qpzZqurpCB1IfKnM+gTwYB99bjwbdfX280m6PlxivEzHv2Vm4gZ qJdZothVFWJBM9hStVmYVYHj1sLLjXkkKvWb/YJ1++VhLM0VrzCp78l5THIVKPThpxWkAHeP5HjZ ZYGKrDhQaArXiEBcoMMUif5t/a3LGvMq5cBJIiSXuI4WZrdBaiKYiHNCgN0Z305w3WPfrNWhL8Bo 8aBL1LW3xSL7Wl+4uvsyhFpVSEHFpZruNlKdykim5NzAIg4oYghEpXBAOGz5Q0Z2dyWw424zHHeN nVpeBu5FdiAjzc4woGARIB1r0vAeTLwXeDIJ+IlatW2u9mgGnSiLByzSVsFRbd1yBBpbIMh5WjaM S8j5fVWTbS837ULmIT6up6vTAnXGCxzIZmnXiuLlPYFi3zBUlDxxQ6UfA5II1TmUKSHgJVeD3dV3 QSYaoaVaGiv87tGEY3Dlq9TROjjqXH2V4T8Na4rlkyvLxzlzcGHPE+0L+1MJHO5zI3hdVOU8UkvE zHb2C93xzhKHjBTZ7CvTiqT+LXrhVMUNWkrhDV36vuWQKZmaRh8qXtmlxwCiSmWW2l52lWbRlToo n3us8i3LdmT7Y/m8d9EeBDr4bdtQ+Na/28YVMhO0V9l3C7zb8OaoeqITUrE8bNhgBnc9s+Fz/OTF xxL9Kesf+XdxGf+GHkxu2zSXxVD9zuVx8q0Nm5smRrP4Kw6QhrCMMpxS7ItBZlo7D7Bq5/xNR9oH qUlD8S9SWUxzgWvyh8c1zwq7ippS03Mhlw7VV7UKSQ/GvEJgrKed+pYw2c1aQMgo/XBqUBph+8vG t2s9rO7LpPsMxE0p9x8Gpw4y+lBuEPAmvNSxwkbbeBLeWmPKDkJjywZBa5tl01Mwlcjy9UDuTZj5 Iwb7MEgnRSwCw0/0hpeltWFBRbYXigbLljMfELFxsKEx6sq2ZeZEwAmeyVxEVuR3e7iwufcC5HEm BO0hVCgOT3HbpEizOaTYlHljzhid3TQIDqlRVo7x2QCLYqrPSb4GEdYA3DJCbbRCZkw80SJr2o1P O/4opYOkLcerv7Uj3T7inQGYyROBAkGhzNdfNiCBkCy9NmsISUwMBqTFyAcgLkyxHMgQoccTKviB sFINu2IRhmGRgpyeRFwsgTIiSjUqEOdMGoX9bv7teGDm3nsn9xdoLLuDUXQ2U/FxI5lV8MRXMLkn LXci0xRCJP35GjAAKR+XYrvJ8BrWMjLPe8lZsSVZTjvjvN9ZNPNstbqHdj/pFqP7ezNpyWNXOkyJ 7uEIXOcxRBJZsfRhRC47JsjhpC7nWVqLmolQkNvWBzZ7dRk8fWSPNkr8Vj7saTKnqgTcnFC4MBHN AzTnzSBir6O4cli8N0xihac3o50Ynx6C6Ha6+zpOfD+eqdj2bk7p4wjFuQdaz6B6EVl/PIkgvzFf PMHgclK1RJJuJsR6oRycZozELQ29vPvoppchEKZnCURKC/R50Gbd2XKChn2JoZ0s6XZ3MlOpWiq0 QJcbTTDVNOOeaAxhYzKeZUhtKWEF0tupKFDkUlyg4YNW6fyV2m0qRXX4/2aE1wAmv2ES9nAJFFXB PmCuxjGlg8Wv6kcVMtLtWq/jl13HDieGeMjn2Tj9gT1pEo93rk6hD9jb6nZwLnEsEG1i+nfuOHAI fYqYsLcvpQaGa5vMFGkqV8GGhdJAOaJynWCu/tYfpxs7avu8qX6tycY2fnSMOyeutCee/7ZoYhV3 IDfCL+VQeskaPP3+gCMYu55pXVOmGz3ZPW8/+CYMI5yerANwfFyXDj64zRj8vs4FszyKODShqXCK SMczhuZdp2g1V9aVVZ655WAjWPRxlVPv3iSg7e9TJiW0S2JC9XXiWFFO9yMTdQ/F1Q3v4zENobdD MT7vCaQlqeOML/dsvFKj0o3ftlNtr02oMczIyiAQr3FAuKNrqE2WbcgHe+LH0y/5O+ZDJZr0FKXt bxXE2FGO3WtzDe+NW30deiwCpW86+Jii4l9UoqaebfKvztkqIALVErMDTQotJt2ikT/fIYR2CouV g4zwquH1slT2mli309O14fcK3dg0v99xC7n/Ytbx+3uEpqwzl2hKsy3KIo2twKqsuhvovbdL3loD rxX4A+hkVDpPTKsDruhe8hFHS5A39/qKSL9OkBghVPLu4wpiYE1/gOM0od2NfEsHx5pKRIUdDMiM 9VEceMkQUfy4RtjeOxl8QAcnk6x1+A6DbrUABz2GJ1jCBaOtdpyvypBbDEi43xO9J6gXDP7ZJ1XL 3WsQvcQgqjfTKn8p+XeHsRfl8TRLW2/O27OMmMZYuydO6AUBccYdJk/gFEZbmVjE7WLwqPeHWnDt LEbgxqwapPkB7cmOPEWntqYjDbcDDuVP8sy2UjWP1jGEP8mHr7WgkmMyfM/wpsDNYfxQgn0msDG4 TmY5JHJtErniOWdiBN2yBBYW+cLUrNFAG5kaX8Kefuc+27YDbzdBJs26nf+FIsivSN6ga0tDfmEz 0LbczDyWbm7Kj/7k6oroNEYg6fvB6rx4gcRdQ0s1WksmWA3Tn2JPmjwPcmb3xr+obeG32X0BNmlR fW1TzwqeCQgVwSuNFIytzXvdi/xDotM1z9NGInjhh3D29vwdfydTUk4NXNdJrw8jZVkTfeFD1FAT 2Fk0i2h0T+YcW3ACC0NWXqJKDkQs1M677h9WvgTvGwJ80JVcROnAW6Ohls7O5YbZVWw2TJ7Og1fu hZy84t790wLiReGhGj49POkbPh3wkIOJZRdEdMVfLbm5u5Yu9mHb3gzylM0pY12vfOUzw+/U5b5M INYGkYFkBnZhiWZRrCypqZsxTUUY87Px8VMPG5MofeAV25IweJHj/+zR9bHBmwbezjRWzqVz3nb1 i4eKsHudbJiTjLj/ZFX2OQ0eCRYfmupS/LlrVkq6Qiy1TvLn2pXe6Qs+oOa+6so2KyKS+qANSXKy ecm1fvtSOLw17g9u7FtvxELgXObq316lAMCd2AXOBa5Uu/BfdPTvdWg+OvJI4g6n0dGZN6itYGEH KWfddWSu60Tptruo8LE6B0iLZ4e3kzuzyOHSbyxQZyKlF0r7qvj5jVrax4XMXP1zCIc0JbtpD3b7 3M1457+nKlHOMJ0ZMsUgn0BEBo6+TsWFjCd98+XZBkx0Tn0vWCb9MtQp/grbNCSiWf2WmUv1gfoV ly/p5l2NDSYlzPioJgnmUkjZnX/UyAyO8wIGhBuDwjXgvMi1KecM4HjKGjahLtmet9SkauV+9W+H V7VNpM0WI+RbYLWAVN2Blil++1SWyUlJtTj4I/oGtnMcGLuDJGyZ8iELEFT0kZOK1tFRlzOMf62g RLl7G1e9aAfqyS6WbOEmDWeaXNLAsCcVjXiZ3DJagJGmXYq6dnbhk/2kPw580McMXfunabTh8sMn esdYX3oicayl/jNq7irkzA3KasAuLQ1x3EGZlNek9AeoIC62vy4EFK/jA8BYyY7RwcGheze9x2ME UlzTmbuLud9JfylWsuriZ43b+5LCsQQoMrgfDNWZ3nmV2Km8OhPUrnH89RcFfgz6eYQzN7rVch+C 1zjPJIJCKr/dLRFj9v4XrpHVS9bfFsMsiUfwRwz9WAWMnGaYE9QMy6gSmDQH6q4rtsbnnmbwpV2M kiWEtQ9CE22F3k/Ldr8jEnebBvgoFmYMMtdQUDQhbXktvLZYxzqXj3vKs9uJ53JuPbO2XYt8EE7N T7radU/TQPPWxeb9al6QAj6tQIfQX4inRt5ov+EsteI+rgqg42+j29cZoliLw4DKm7OzFU1ee1o1 2IpF9VNGMl+a04qaSPqdaBf6mKPym8JJhkHhammGLrljC9/oLw9MEf65GlCziOUPDyADWhEbA3UR JA4kLE3QCQjok5zQjtP/dTZ5dowWZPec2KRzK6XjJqb0IvakWFuzPTSMLD/Uk7WNmxAjKeKIHr3b fgKn9lgqmmw511M32scp2cIZiS5cowGxwQJz6Ux5sQ/4QahuPuD8EYJkFlhnfT+gnw27pVabnUj+ Ns/8WZwa2uNj/lcpSXZ/0MM/H6I6tXHmMzSjga67QJyImAas+c+zMdAMzbpmMDRE+b5fQFkonweG fi4RhrITpP446luAnuX+z+23zVIupFpkcQ51aWXX6glAm0KvagnL8UNWewfHrIO1Xi2B+cUL4i2P 72jBK4b6Vctkr9riMZiPh/80Rj92RN+DiwG5psiohACXFSg9WzJa0akT49PVEhl8L9mWYx2mzBQR hav4faX13azfXxuiALspBEoivWlIS3B2MNk5uFE8w2ikE6WFeg6aaP4WL6O8LgYjoo2AI5XZTL0L 6SatIIeaNVtuLZbEApW3sMz9vDHTiD6nDlI29tGDrfJQbaPr7/Uca3Sda6bWsryGDp6ldHbfsR1P cew7feCGE0FDN+ftNSoyev1dDfJmOe62lDd83z0/R2Z9BB1Q/B0d6aemLxLaYc0T3UijgNU/l+Tm TZ1H4nTqCj+d/Ax6rKRzqBNjdd7j+y31LJNDou9AxeLvEwDzkRQ9FMPqT//0WwbX3mcHk6Cq+xDJ q9HbTW9LDQ6z6RLyPV+YIrdhtrLmhJCHmcdv8VV2CfIEX4L/yrHUZavIX51IhLPwUt9CbHKgkCQI 9w+JG2207XBJM1jBzj8yzkppeS6lQwUgWd2F/irghda7Mx17Er8/GPmcaVITzsV9S39d9qy7wB5x uDp78XQgo5Ltm4JmkFuUeZQJK82UZC5NgluVYh+ynNBjcTEdF3LQLQhOL5+XxvG7GVxNGzKYtz35 +z4ipJEXhQ8XUx0TceEwQfANVz4e4IQPHi8HvQXm0JHiHHbOfkSa+OPOG/XMy1pKEmDlyZuWSLmP dqlmR2tLdDDjCWXbllQ3GutLq16u4Jt6BTVPFB4coYwUWLd2pPcdxxDShXM35T4QS4BVSIif/fnw Xvaqk3FXz+ATw6SkOVs/U1TY2YhyvlqSXFy6Ng6rcGytRR5CiNHZ45VsCYMxslAeKOn7zryNJIMu HEOymeCTI6xlA1B/ssUrANV+ZTwa7Mfqk+UmwkvfXudqICvYQZDLHslNWQ5lndKYRqLqzbLWtlKh x3KkL6JRSXQ3bgBsa6vc5Ppax5uH1svluntQhNPrDFs0GpPk7jUEVTAbJfqb88iQWGexBK2EVuMH nNF0HYKeEeyuy9TmotiH9MsvMtSYkOBfiFxyJBWEK08nUkNrDmI25lDYhDA0M36gnF8tvQQ/SCuV sLa6cPgfp2n3XK8swfu59V3hXUBGhSuvgr/3rxTKOv3KomzTbOXLyEXKYusIKUcko5kqfent4nSN ClkKzE/to5Qr2Lgobxe+8QdQ5re37jw8BrV/faDyyRyRuK7SBXMtEMFYc7R+hFeSoJ2Xdpa6ZJIv jZSRSsdaPHtG60w1YrO9RXWQb16s+0Ny7FNhZV821xz0OFXrRhD/Ni9BlM+r0k3g3T5X6/sWeq3I 0Mbhu0dgpr8pKw4l28bX8DwmGxJjMzBvxeVow7IKt4d8MnYkCrJkqUKDfFF7yX/0b6+oSGuKbc+f 4AZwbnD9GanhfiCQ+oPLV/WbXcpX53SS+y2CR8IWT6J1ww2MO2UTHF06zF2S3ug7R2ed572gnMS5 hIsr0Q6XPCu40qMg32QpHBk/d09eQTJt1Hh5R7Ok6jMm4ETf6r9C7T+0qwQtBcJjLPTecJa3tHsO no6K+kwwd61DrbMKOlGiP7LomGEZOY9No6HjF52no/nyOzemAiSjE7A5XU8eLZKPQYfs6UVRMkgj gxi0uPNZQ9Vk0iO1702wYI1q+ewWtV4RlhtytplniUmcT1Tm9aD+0htNy7nh/uL+XjIzHPaafgKB xkK2Gz/d1XCLzehkH7yTjZQvta76kl8PGEUbblUVHqX9nFPUbDho+MCKK1B8Qn6CsSe0Jzk3M4D6 CPrGzQPbynPDjqfzJcUAyEbSV3gC8F1+Zdaz8FC1olyxl/N/GqTgZaPqb4MBxTl9GD4jpQNaYfyj sLdGp8PGS8bK1mQHsZesxy0NNvXhB3Gqxe/Rqvz2hJe6v80ybD4GDqF4YD3UvQoBPZ/d0sOWQ9el cQX+B3Q9uB7PIP2UZIx7OIjPGpMBtK8P2htqel/l0C/X7xEkH28+p/IJ8DmKn3WClXECGF/wLwtm d/QW3zF2nd7jA+Hn4dYgDCAqIdADoSHu0g8Y4mpTwulu8o9gIG6+XEpFR41mvnZGv1w/AyDcaYfu /98xMf+//i+V9H/4nxvuKsT6m+Q3A9ztXUPGIZIJuwNbW1sk//vqCMambv/+0xMR6x/2P2YMXzre p82et7/6Rn6eXy+2niDJj06fWRT3H0+JZWV2pb1/nI5XsewhP2m2If5AzLEiQKz1pYi/n8WLQUOQ f/l+vN/d3ZGNsH4Nf2newtDe/i/9E1rkc+Xkp/GNMYJxhLGc8bhxXb9Kv0oAOiSEAAAOQAvAA/AA 0AAsAFKACAASQAHABLADEAEMAAIAPwAWQAPABXADUAHMABIARgxpDGQMZgxiDAEKzCjUKNIo3Cja KOQo4ijsKOoo9CNhDH4MegyZ4m58AyoEQjBiEGJIZGBkcGRQZEjPxxT4OUA4BRJtV1T7p1EE9OWA j1Xgah8L7JfNLoTx58l/dUJqjC32qbr98XbVFvBRTVFGpVdySQyzXIcfwEKNAQEbyNx/6bTysioG IybxDvb9rPoKB58AMY1h2CDXAtvwvmRrxKBXvy40/HOXAlr8revPEnbGMHYTTyDqofmC60LY+1+d VuNvT14kv2JfA1pWj+YOTkTfrr7Sbz+V30GQpMgJNwE+yx/uTMJ9YhSfpD5fAk8BNV8uWrSzaCxo x7Xm51osWmjmprMypFqPeAGHMTs01TnTTObf0mTiLFkCzJNFFTK/3ok5Gel2X93/c7AIVf7lrnyn /H6lkhIUPApl9W5kFkgMYfAlcY7Um/Na38chIFQcVx7SU5XZUxVUid/u85AhfGU/ISIhuXgESf7V RfSfrScZyckIXzJkvdNM865TnpAH20o+oRP5frRuMQ6DmYYUVIFyx6tDmC9s/ndtQHGulEDZSTr8 o/z6wPpko/cPUhWUezlUoBAHfNt4QfvyK+npD+PhMZUuy/UkR5jfXyFCnNY334hoeY3eKBJVm+G4 XwzpHgLjMYtKHG2akQ4sE+P215T5SCBuGXXizSVMC9j82TV4fMX3IN3b9nIslUH//PewK7Ln/Jnc F3twU5fxMOQ5Y/kM3YAcblHf33eWLK8JCn8//ZZ2MyrS6eS3xpofzGgEPXKU78JqqvYxXwornykV JQeczhFtRTPIRLdUVSCyaz0WHSeD0sIMR/RnVTErixVMUlvoi73epHTB5A3eJE8vMJPleDK7YcFS Rxn1Jyxv64Z7Ip8Hzm92tTpp04Mjk1fmjk/Rzu9UdJWrotIlvkfZl54j/y7L9twPyg4bpQX/zuc2 Rv05XC5W+RsH7aVjPKjZgXKN0udh6GUlwc8iirV0COXPXK/yxaFblNDbvxdId0F9WLfp6iUHbcWp j49xX3clmvyQ/4y7ECm8qFK9K0/oFXbsy7OOQzDbgAW7g3mLi+Z/uOafD8e5MGlrZohd3uPEajzr 8bR/I7R/6UHabM1BSJThpZmGRCDlT31n4+O0eh2m+i+nPTiUhVXV9N8vR/cQ+XlnhXRzK79AdjVv nVfLd6gwpuRiMyx94l9l7dbZnDOHCdOd/nHtT2aaLOtLBu9Scg2laODLO6KJjdWQHV83jvSTW7/y i7obf5lBe7h6W57lMqpzgB1OEbblfZYap1+7Zt40Z4WYPZIIVrT3QIyqGOXCYia5WOnsRo+gUvh0 BLSXrnGGblu9A1Fu7OjkvOFW06/5jkMJkXG/twdJ3rbZ9PLWpmtHi98tDr6bA8tnN9wWcxDjrdg3 oFLMPek/3DDPF/21XyCnxuu+a1GxUjRaR4/d6SfGI5KLs/bqm+UXpErhhMq7AhbtyuXOlVff8ire ZJvX2W3djqKuTZFYk3PqrD8kZ+9X12OTjFwN5FPPdQet9heOkzkZLcHEMBKwS2nEQ36GIPDwNxvs Su+KbR0frvu84rCluJ9SyaPMZOvbGZ41W3XVCCJ+60iSVIxsNUvoJw2YLGC3tyyzBjd+NxcOq8mY JTOHEBZRsywOoDaDZhu9ExAkt5Ci33QGFPYxhUcyb2Ctw2ZKE2WDJXS6m5iOGNPmoQE26R1u9s+b 1+WWRyEOzWpcOfKrtwn5/Q0bcXutNLJXFJYUvLowxMJlzvtWXQh8MT6XHkdHVO4PUXWSs/d4mwmz 4whfdMWUKiTTu5BLwi5snplzwii9s2UO/PwufrBsEA4xZ5vManPpKcksjd4OLwKqT/31iJBXFoPQ zXZApmQIG3gValxY0A6jJKg6/Q8EsS37qZ0vwp9bJE1cnePobGiY7zrR0PBt/cw9B2O97g/l9r0d pYxmos521UoMEsOApHCk6mQfJrGGODEteNX+JazkZJzqDVOg54HGU+XCvwVcdrG6lAxHEi+sF4m9 mD3hCi/h8Opr3Vrh9SjId5caw+07BWwjDPAslOwrvd8MDyZKu9lmQ9s8BlO4TM3lJ/bKi8mJZik7 VCeS5uf+OuVrtvQUuvDkXkXWw+JFqPgNTBzwDUSYuOBLrYuLdkXYX0DS6fsLxG7NFCA+26/yvZfr ZAbg0ovz+j1WzqsRwSpF+W8kr+ff2XTiKtsaE5dKAonMFoB1lA9yzKkLusWZNiMvFywC0flstgDp 4sfgUENMrQn8NE3SVF7zYYemhF+PhAlxBHmBnJJrTOchyFa+kJlW+6qLd1ad2xR1pt9z7X2ilR14 5sYYlmatgU7Zv01k946Rtag2FSORCXOLGuGt+lzH3WWeCGDwt3V6yz5GCZV6LNnUzTMINjglY0+u D7RktR6f8/7sZJWYJgXSRnXavK1XcbU3hMq62BI28tWYZooF23KZamcROpoMHL1tcSdlgg3a1+5I f0g8ezL+uitmexkiinKEujttgvlrQVgZ6+waFvo0y/hKGd9JkbfX469JQZy6xo2vsTd/0BWjtlwE Q0Gmn8zEGL6yVN/G+gzqnRGEnElf3ocu0Sd6bpTaVtFY685MVEDh49PGQjkRm8QnVXvlZ5pKAIcU W1tO7+dYcCyEbz/iIjkl/HTdHI186yprIZ7teIYV0KUK7U9BFIQuwUFUPC5O7GlnjpvmuQ29WHMT 2s6DecLxD23LIcZcQtAYXqkwR4FjTDLFoT12q5A3+CRfK/25oWlbMwP6N++AbfN0C4JtlJSft4PN 11hi5QGz2vdNZ+WlFB74EhDc3VRY9MSVX7v4nuciQ/0qWSS30S0p33Y8p+TxAJ6pOXS6iCcexEqr 0a6EZz+/sdKDLzlk2Hznr7Q75CBfFkoLfZLujCJGw2fXOmKZYhQfEGuHDIyF70ax7HGIpC84FTAy GSMZexxV+726fgnC/ZubjU3dK1JeLgArtmEk0qASN8ghp8PzLyMM/gDVlMdFU4iQ49IRAGv9N16B bNw6IJl7qQfuDVS786GqYjXyv10aBu2/clf2TIhH3P+5uE1RkdYo694iU1mKVuTIc94SlPGRrL/P c9NvZ7P4WHpWKWSRMT5KmAF/KmouvrKofzGNlMCkhTmRj6X6e/ztTN5/Ss5iUEJRr4V1acrzdppT sbOR2YuRZRgZ+nf7zwebP2pP1D+vZCs/F+8o4hp3rylvMrdaobkSRurvXzWXSS0i7wNCsvVdT5Mf ZtPK/GrUXAa/4wz2zRq2zqE914Sc0dS4Xtr0S2pclE+wqWlEZGNpGKt55p6ONy7ThXvVSJyCmOwi umTbUe35fJX7HmikNadIXgbUPloy8eSYwfBQ7st+z8B4Z/8h/CN2l25mpifFi4tSB5YzToeXqwf/ AxzYAcVhxjsMvETesVIA/utz7TlA84zsFIw1/Z5NmZ6mYKxSt6JOqCgvCeAycU0QcdmOb62Fw50H ov0oarMljHxh5EDd53BbFvqjeu1q6BMGbDCHud4MoTbMAVhKdH5Q9B6wQsLBXpBnkUELMw0yoY55 gHyYW7l0ItEzDdGzUlmioRK1BSxGUH2/jZSyXhm0QKivJIZDJjrEsgr8WfaAeLBsURE2pr/qL8TH qr8WHE+lyZuzoEy7gNKXpd8xLY29W8Hekf8y69VFzBE+r21GZ5O113+pJnPOk9U25KVK4q1bnjjf 0mNTL0VJ7Ei187Hzyort4E8kB+PhQfelPL/AM89RRnnWwy7aljIjZs1myhnWh7coGr1xKHCgLexx 3E9s5iYvFG6hgkhbEadxK93cGkPyGlfvuyERce9YfxluS9QVQj1uTLVaL4jGH6D+iKXi/mWlXCta V3R5+uJKupDf9BkqWVRaexOGrGcEEqGF3ICZaUtXTqV55zJ2Qfemel83IJOn/FZ3VoKL58o0DwLj mc0HZ50/tSuzftoByjCr4CGDHp5Aff8DCSD23ykXEVyFQiLdV0KXZdTCIpuozivbGssMcP4IjGY8 HSVHhFWJVGWB5zZUgpQCqf/o4Py+7TI3NO+CZTewueMCKwh9plazq41xqVRIX9ZuU7zhODaoI9yS KYrQDYRsMlfRxHgPnMnt5bc1nNjVCfcpMg0zPljbWNj0khkLgnKALFuLbewnwHt7SNAtJFX8mUwU WqVp/gtqVjwsS/Ip/fDMuc0rPrRqBOaNZ+6AbzhdCLEbPBk55YszJkeTs4aRUMhc63OoiCxGQ6fz htX1HjUrZyenxMeaQbF9qiMJkAROhRTbcJJVWcnluIXGmtqtcUZcaTTirxizmc40phjQjGcUmzsx r3m6lc/fV5fmWObRPFAEJlZFy8L4wZSUiZDT2yQww3yAbcAtxMNQJMLWdFGZ6ekaI4M30vQkx5YV GoMJzv4YOa//cSdUwAAqfJpeBuf1Pdrik6roS0vo8wunq77I4viwJVOwma4dJDcXEtlyYV+0LtoN LXnq59pAUb7Bi3ZM9mg7kSv+HiuozaGeKSU8DTHRPY+SPWdCVU29MgmYEUqCGa/8QUcxP96QxmnR Z8a6ER9k4Tca67WFXnIBFKSgTToZzvnlNgZ6ApIH3SlebGhShFjLuOXm24ba4n1Hku6WykTbcpu7 j4hUGhxIYvgj+JyDwTBbETtlRYUYkPUqIYkMSp+nVCFNNZcpxWtbJQOOhJwHbv3lyRWxxbesYyEU UGni9EwqdJftMbCpMuUDKbaESDaj9vf4WVpDSQrXx7bCc1dXdXsPWkDHUW8wOcfmJMf4H/JP0Y0x K26gnzSx5qH1+JQLqqvotbmlg0CGYX5q+IsK6Ef7uJHz0yXd4vyopL3IfcotwHP2IZyC58UhsldD 2Eix82iV6emzNbDiGwaG2jOi8Eqxe9oQMmEjz6mS2Y5xweVIwwGUYX0s2/pyk0PCA0r0cMYVOKTj e4C2tN4l9v6sDZJ1agPTJtmwbe+8xoT3AFoEti8h4zJxhFsRishQzFTvMvdbpPEYMOEkcOvMbeBM 5lOZMq6V1un6rHq8eVRkKDWxL8mpHh3IOGM+RRudAWym+fXait6OEPRqw1BoCU7qTVEXhuZfdZMs jaBcVZQPlbOER603+ZCPfwvvX7igepWmBSU5LeFQUfVd3qfJaJz8C1ADfpiELcMJKfIiHXasRYK9 ezc3BLj3HgDjcWu/BxA+PdAb9Yw4avZ5Lm4zE28eGsNkDWLErpq6QObErfeoQPFOK+waFpWUquPd MiXuUWrTERMI60mham1gQNw4Cd09cNGdEhooyuosMzNOSygxljwNCkvhJMibPV40ssBZIfc1tmEz 10mPsP2RAnVRwjwgbCLKR17wUcCV1LJxrDBJaX1DddzOatBUPTtJNc1iPMAl4PtKawSr0kSa2l6A 4bIu0pDUPGWSeC3fOIhR45GN+GOWKeO+VK4KYFsNIT4DweLD6KP2904lyJxrrk/OWoFu2fJEydPI WpyxNCF3CWhOHFpevnhZ22kq145zjBEWzkeXLUOGHLSCIlxstyaPGB9aEfmmy4/Z2GcfZbO33whi NULo7lHMVhNYsTWUOU3AvnrKMXejrMNXmMmhEQhxXCqhMaRwYPd8XTC1YeWMSfUklKi/iFfVBCe3 aQaqF/5QV7CUJ4mubelPfRcxzsGQC6PI8I0IUtEYeK8gRZ81z68w7Uw2xZOhZZiQsQNkixHLQWtU Q0ndyMNSI9xRkfcb8cnfmo4qQIF9gAv8KCc2HjeEP5vFJ869JV+UL5xrfsnBQA4VLo66tGXiJ2DL uBTy8o77gxLyit4uxFc7czSz2w8hmvYcUXmnHFA1a9Y26pqdTCqq00i3y1Fk9u7UxZpvjaL6AEUu fS1ryKmtG8G67jrlj8KaY1EyOJ+jLloCF6Q+3B/CHEIZNCC4XjR/PZq7KJBZIR29qB+M+CnvHOLC 9InkVMPgyzpjim7fi6HBmeCUQ+0uwC20pNw44LlyPSLHhKYUEFO+FGmSCqN1oMvDZQTFs1+VNKA0 QRo4SngucSBTij13LPwod26fGnaYe3U75FHQ5fosbVd9oOKqxlVahJUAarkKdXASo2UqQQ5RvyN5 /827m5hIsuLam5S549ivmxyI4kviEWiwL4Xd9SypVOJ8j6eLVf/CMtQxqe9cLlU6Q1OvhO9xu1SC 5/E+VumHcdz+xlvfMzvrlNFTLHoGh7YHzlTyNGycr7l0jI8UiCth6XVc9qMYMrRJqO/oAZf3NEYq NSzyXIF2RX6LmVsG1j6FP7e/2VUrlFbLs53EaNC2nNx2Kk0YQH3MwlT9ubXBTXZ/SCVq38vtlDhW a/HCO8HYT8iDJXuQaCJcmXYkqFh2RKNJuwvqFpgaY3OR+XBAF56p1ZxSOTt61N9SOV4XjwCxO88W ZOQAYv88w2QOu7Vubi5UpDOBHNixNr7ZOcBkUaytaTxhZxE6ufrOXPH4xAIWbkRX+A6HA8rFXpQ9 fabSEnZre5QFr0V1sbkQH8tPJwNC2r1IJzn14woAm7wMkK6TjBPeJn6QVOyTPR3GsGZ11dMt3Oig ce8/2cEHCz9S96p/DMSRaq93eTzV9jZv9fTeQz2YusVSYwLD37p9sTuKYHGmUlZQdCnm08CJLCwd /oxORgreO50kCLZmLoTIrOBXmcUY90/KmFh17DUX7605IcwS9SX7Z4+ipdhNw/FGWPHrjgOUnda/ Lh0u486ly4oWRyoPkgfRXSIu+M5dWZCxIa/JisFS8bXvFi5NylYQ8DPL1ZJ37hs+C1WPkjg4K8Oh Vz4Wyo/uoAqwbDvvQ+zVRaT0gDDe5QEb/BqmoPATHjw+aXwijQW9GA/wnPCIUfIItJQzbSKpns/s E1WIiC6OA5OMdnLfZCSRkuucmrtcBH6gLxdnaJ0dr19mLovUP5/Jo383U/EIIxsrUynGxvbWWKER hn4S0iuAPhb6DrJwhNCVKfVy6M3PDEkdrhIppr5rM5dXvDFeEGvFRVl9ogYFrnrYd8ac4gwfqTip W45rMyg4pUznWDFzuCflsvf6zZkvBhTDXFlp7so6p2DdlNAPvIwr1RXJuekXWU57m+uYgyJBRaAl nDDTxspZ6vG1ykHxYeoqczNVjuL4GLdvRfyIlmJlohhSj4p786DvQyPLY81+73kWexab/TN/iOhX aB5npDjbI3Ez7K6SrVcswl6NraasdTdkiky09SUDmU/muUaTrexBUYTtO8SYgj8Qf8JONDNDLHD1 duDpGhT6aKVPm7mBPCjHiiPjo/pfwQgTyjLjOigicg3c6zv1KVs2cQPN2OAQJVRQ2l/0CDSFnxi4 u72d6niHiXlVmOxzCc9FD6TvMPh/3RxNTiyfNy/KzRmWVzWdFw+4R8LatJiFJVdbnaHAvmeo6TFA 9DA09LqL2kJRDmE7ttlHkaSnMCXeqyZy2xe/MqXMAJgNV0DutzDqf30kLJBsN2Ln1RK8+gxICitv GRxdLNxgnzTtmEdYhxpQvTUg8rmMRvFWa3J/dGrTW61hUr/eIImkeCfXcRFzyjuPWM1NMSA3KYdz +egmojnf2npQqSa+cq3mdG8FkIgNfYZDF5ZfcqDzjTOF7xC6sAqcRcIi7XL4CHUNUnzsGcPxuzWL 6rqtG9jwW/pG2i574beRRu25IFmt9BAqs3I0eswI3Ki5NdDYPVt6qGa4uj1+Wki58755jjL4UG4f K4RGpbBBJ2L8jIWCWpg1eOFsH8/RedkvFum7ILsT41y4probE9nWMmkbmJp99dgn+5xAzo5Pp6xx F5k+nauwyScaB+yUlwwlen5ceDnRBrJsPNwn35D56flyECb4TiTZd+1KZfqPdVEq3D+lIymPcaRv gBSWifraK66Y3wX0NUD09V43REmwWujx1/gAP0gkuDDfEFXwAEbZd+CH/TC0W6dsUVGW6Nl5FG4M EQ5kCBl7XFMN0Adp3XCR/M2O5SgM6sMbq/Lxtd2DM1U0E5eHp3RPP0YtxdiVBpZF9xJJyzNsAlqX bIyk9nixD2+jHlhp5tbj7twj1vQeULP5Xgbg7CZrEgvYOLh3tBRDQK4PzaSVWivQl1BvAvR8cIgE Iyq5kfMMz1e7dDb3dyoh79UMq69uybtBCoO3E7xBqPLCXKeB3g+CnSkEnVp3WIi7SR1Ds8D2+lP2 256vqIrdEkHFau3UmYsO55BJhno+6WWehFwB2+2RuBbfGT5fhfgH7cndPRDYW2CfjdEcO997Jjpu 5A2OkokWP1JLX1l5EIniKf/MKWxwZk/Q768vDBmxPLdG9MzvSkbxg403TPw2s8ufnCs8dJr0En/m miJa/rpM5PBEd6DeESLaHS57kvkZLqaHqxOHHyJiwfPk5KTr3z4wbCLykBSDAwD0WH//vOX3A0M7 IxdXM2eX/9j/8dwwY82lgAeje+OT9TPcume6YX9aQCmPjo/XUOMIDSGti3cccqrdiXEEzFLO6tzz 2QpGE1QEu9SxrN4asyo+1eyaNafIo6XTfd+CeFWFoxb6W7iyadGyQKtBmuBJ2MNEBU4FNV8e75fT a4pKnnAgmUJ5AO9e+8+SIzWuoaiGQyZJ9bpIOS+QCVK23CeqvvtIf7U1sdBSkLLInPatyZ1kJnZ6 4BqQARdY/a4iy062n1GHmWXHEPrHD4w9IJxg+WsgvdWJiVohPkmJeASDblXNu6YLFfwBqDnVlNxZ mE7ikjQD3z58DWe2gdf5mmpv1RoqeHRsJwkbt9kD0UjVWuiXPm5C/SAYewusTk6mr7D3T0G87jLE 8jkFcrswioxJpe5OcQ1Ie1X3b5mGvGiKNNT2FiPqB8gXnXuNYqeaycD/MNXqNUPbRQhZ/PRh/zGi LieJiCGLsUY52RZWr5oFvp4Txo6R8BA4NRA9zXqHKgbXjuLMVvCxno0eF/hld0tPL4yBWcwhSmrU ZktHuhuE3vNCYdqqj4VPIDKMw1foFRGT91VCn6MhHjPDr0w6Xb3RByMfQN5V/eENgXXT1kAGbmBi gM9QOOMXVhHS7WplFOKPffzZPZqQqG8SRqD7AMHGAlP2p4gHR0sHarx9318P6r4OQ4u900OhFbKX vHzsdA/qutQ7Oebo9ap65FcMuewaDv6itsNu+UP3S2PC1uemMMa+G2K1FuISXNyydfW74BHbyaLY 6XrdBQ/ZBSefbR5Y5DIJ+u93pu9fZ6unv7RaDbHw9wkVz3HLmbYVr9lu6t9vKGuLdjhEjD33wQcq MbT5M244o7eejZCEfWPT65vCJy2BLXjb32Vfc/Bu9tQ3Aj07CRQcZ6XNr46r99pi6czxbNtxwx5a jL9vbOzKXFRnxFNr2/Hh3GFkPfZNn9hVyHbwhoC9iph3V/klr8/IgCbqvi3hRjGuiMigI/wtCUOR UwGwJmKIsyqD3CYi65MrV2QRffHyCR7sqVAIHedE9J5VgF+vh426vKFx0JiPt5NvXaGp9Pm2aQ+N 8XxG9rahNQI5P/ptZ7qCfBNmOAtXKD7KLhzroYMRW3DpeUaluJ1SZZV0O4Un0+lVienAK8wLmIgT u8vXE2lu4TqdCy7ZrpINeUHCiw4EgYlEGd/m+fmwi7dY0aGF8aClWCIDDRI5vwamw9ST4fWCwvvl vwZu4tZCvUZLXWHEs5OOCeLwMIjLo/M1hAwuwveKNvWClYPFdarBgdTQf0Iy1jMYav0pY9DlB1fE QGx9Xo2CMWSH2s43qYnmuosSt/kieixiQxFm3pbW1eFLNDoZif7ItfLg4WACVwH/qXvVFlHiAfP4 TXAN5so7Fp65HSyndzEuRY+SNFCNRHLbtgULCo84rUt8rkiG6jpSx94ZyzmJVhA6ilg8MGWBQLa1 BEMFK8esvE+QacFy/rWOciri9D9jsIA7iKVYj9gWMp35bN3zyu/mvRmW2RKHCe8xGsbTptRn4gqM 0GycSMUziClFrx4QZoxno56o8N/BIhoI68Dyo7ur3F80mP3IgcOe1oVq0v/oHKdAbOtWAwPifuX+ QlKT8rWZv91LL3KhTrm9prH76CxGOLfuBlNm3rowcWC+XmPjKjyJ5Wb4bZ/I9yz/hrduOlg8t5be oyIyjjanjkiNLTHP86tNMbh3U3U1c8kSLB6FIam+s23fq/v1KQQoYgnP9I3yscvDsK3so4RtIPBJ at6/Ir8/OsIIiq2bugSMC1xDTAqGCBf7tC0HCU+iBDGTjVGuL+WM655gW0JMZQpHWvD0aV5K/YSU vNDjZos2+ojfmRSejFYYX4FnZbRPm2O0nH/QTk+97ZFMQX7SvToZYD3xCGv9xrktWZFQ+FkCmG9H sx8sdOMLAaL7RsCpLLJ3sMZMy3GvRqV4Vi9IgcqYxI9egFUnGX9gzaLWfyl3OOaatRvBqnBXJ6/R +DZ4fNBuxoqJty3Q9YamdLmBcmPdGk7bXaxYsXXu3iNNy/bDs5PDs7T5LVBLYLYlk60oxtfVqmq3 vgkBe+IFldFjFwWZqOTpyrh5hw/CfcjOLeMoSFLuwKW2fuA0aJG4bm6XxPrNgEdq+ulNUcs9X2fb oI+WshlooOd+2D7gUsd5I+xm1Yh0qRPQsQ/TwN0gpr5xZKNuGJZxotOJ825Q8cp4KJLxE+mQ6AM2 EFhfINAS6rUvrS/hfbjhBOEo4W07wre6UmXs/vn2fq4wjOPyi0l0GDpP+/rA6fBiB/rpnTO+8i10 zki2vPiF4WL5BALmyQlwNcng4bhPwCPMW9hNot5rhE5H/YvoxtXMBtwTPyWyroSiwSXk9ZXdykGb OsU8md4ECpMO0tPwPMUsEY3RDGqipg/DzTeHLt7ro6nqh5ujrWYDnWvM6mQ9X9TO05NL7zBBN+H6 oNS+voXfbTg/aG2TGq6EzpfafSDTCDLrrJazA5V1MHfRpom7dzcDVS38IP5d6t0djH/xhQQAAmB+ /9L0d+p1NLIwc/m9/ZV2s1TlXJZZ0Do8il96uLONx0gN+wzZgLLa5sND/VIZRNiUNcV129KQIn7v NXqlJoRmP6wznsyuNDt4CPD6VbY050uzA52x7vG8VJOde/rpJWzq+cfiPd48P1q5yqirevvj8Eqk sE6wwLtqTWdYdpkXJWozxxiM8saPUTNY1fwPOq06LKp3W9MhDQIDDlLS3UMLSEl3d4xDSkj3EEpL NygCgjQ4IKV0DB3S3d1dF/F3zj33ec79bz97r2+t933X2nvW980y+0X2ChQZlMYZeOYYtrXx3e4r wlyeJh/XVLLNmLqi1Y/SQs6XQdeBnzMAqoUsv9908o/iMEGiyaX5tJ6FdyjnCaSvYWzV0vP5dn0k 9iOhccxnsLW3nDVujboVokBniD3v2oAxYqJH+jrGEKlKjWlEm4uHD4PaGjk/LH155gNjt75l3ZMG yedKJMEqw8PVl/tSc0Im9dRjPbpB9y51BWVrt7zPlRjX506NF9xhnMRfutXmVbzI+odBW9KLVORt jKBgv1w7LbKwqFte5atNqv5KALLIjnmETUWjHjsfnwpu5C1nbwu+rJO483D8yAY4TOwa4KDkPvd9 FPS8jakDkkQP2snDVCSuXtsqSjcv6iLp2PPPrjA58RtXTT7IGWTfF0Zy5xl41W6cwoQCOfOqlzDo MUwS33vTajajH5B4v7pm7fdE0EggI7HNJ9g3RbTFr4Gzv3cPVLDbByksteXIuDUcwapYcmQS4jEl 6G9VUCcvvNvqpBgzgtMYyEso1Ju7ba1ZyhJH7mXOePGkeGDPOxJBSDsPlb/gH6BUuqIovnAckWk0 FlAFmP8ur+NsRz8TZphSxxVy/5YyoXLUfIr6PthefKnCSKjJd38LsVOnaY4HOFPnDzVN93/qXvZ+ Y5QgQHZZbTAN3cTharcO6pvgbdNFIqheFQJf/cwmF+OP/N8Kltp8B/w4W4/0d/T5b8H+ndT4z7+Y H6c2vnxstmnlxA7dhzZCh3zVhpsBucqOUGOFc4QON6KRCe4kyHhNGYDMtmMij4GWzD/bz7bxMjJe 6LIlMC60FCJxadkdwvvmYuKneGPQkk0cDxFd2eISGf/tcqvXOoPGKkEMdRXha3Mci5JLnI+7G7mL oZUqzi45hEqJldgpUaJpzctF9iblM9w5JpxjvyGMBufYNv7d5nft0c0k5kKjHeptGrEISLtTdE8H qAWFql4qkvmMcQqQp2IdOK5uiVkl+Qi0lKk7KxyLQ9yzNZvqe0j8nftxMgYc+djPfpv815cZl7aQ dOrhahzp7+j3/+2j/2r0H930o0TVw31/JPp1eG26b+pqkvBlF5D3RyPZB43UiKoukOEJZ7ssAKhV 5Izz0477bGwxoKOfuk7PjvngoCYf4xP+M3ZscrGBfQ7HnNqUwXQmtOG3DKEW5zeuFzndT3+05SoU fyHUbdV9PUVbSdH9rNT8MxVDckojE/caYnyFiTWV3fYV8fE+mmtVvtAp+VHhfIDQfHyX/9TcJFDQ +LVVbue3eHS56sJ1tQS+J1aQFBHVoQNRR2Y9rAP/CiMpu+Q2a5wKPUJ32/f1dE71obW3BE5nFPXo /3WPEdOaulP7cIWF+HdM/j8/dH+V+ffn7lEXw4GBJy2c2GgH9QvCCTNGAng0lW4CZjpD6IxGO+Hb lGk0V2cd6ccAST+TJj+PEGmRilgVNYnxairOKd7LjaczpeuzBChaRAxVX94/mZPj3NjN/7lgzkw5 tMODqU3DlGLbx8DU3Q/A5mOyWOkTTTRljmnvtttpBSVcw0S7jmwDjFPNM54mOG29NJxPjb/fWbCX T9j7XsHUVbCOFOm2S74qEsaaslTOfKFs1MoRONpoqDVI+V9ZR1KGNozhISA4F/7/OyuuvxMZ9i7T /IR3fjznlBNuay8EuJQOtHakNyfiMj3644wU5Hc4xs0s5ZZS6flerHbcntZ45L6MgCVoMoXXr0jV fg5APXhbEYHOAi3zu3NNBpyDOJZYd2GxkO/YGcqV6aDMdwZw57p5CJn4z7vreWOcz5/bPDkUFDKS QhDHhj9PpyWvLhVAoebcne5qZnPt8SIslRCIcmU91E4oiuFiQQxtFR0WsgOtZ1Q2KN5TudTftQvU GBTuO6r/ytrLmu1EfGtX2QC1lviwSrkC+vB6w4ErhhR17Eyj4j197bT+Su2vS1GHRj++NFksw4Nv TlP7sIYkLj/dl4UCnjDD6sgqUHvuEXWgsDIc9CHe8hQSKZ44VjBe5gWSjzSreUdQoMO27Ftjlaq8 gZJE7Io0Lmm8gPR6v66kOeedKotvn0IYxfiZ6oa7SISmHeMNdRPTeoOr6Tsfyh+Mb+3ql2ubGB0y XA1yBTvyNv07exRKGtsP7YzD5zxLl3VZRJXIPVDl2/X4P8peROJOXcUkbXYvW421x6rhU827BMfZ 9FriF292nuKN6AVNIlh+Z5BvWPgq3tQ3HedoskRzR4FXmY6mNNg8DS+OfH1GEbdNMQ/1PRWnb3yR NXOkHFuaZQLE6+zUWcYraD3LMlysBuQNmQNXeXrVkn/utoqQWZ7XCsTEpwOhQ9CxUXKR+wtK8+iT CNVSoV72I9b0FhTDMleSvKoRscaYkVt32vJph23eTPjp/JIlVz/JYTCJNyXpT2NDY6P0+MtZd/EL 7QWQ86IxzKOLpbVQjGy3O0vCupgLn2dqw+qSBr7Zy4OzjG+NUqIL8BmeTalcEsuSgX8BylLKWqFV 4YTirRHqZ4WpolPD3XymSawx+UEtRNwF3aze6C4A6wOrs2eXKHPLoi4qb1UU287VKlfwKqyDAmZm g0Rxh1ORB9WYyPuq5nEZrGRcy7YRf6ITXWzc3Cg+b6f39TVMuIw7u4mxEV3AGM2h2uMfIBzsGwqA l8nZFDnLmmc5dVLH0p0NgfQmRyfdFedPfcSrbek9xvxNSbD89sjaG9xDur3oPOO2XwduvD9ZJR41 ENi1dRpPonzJ8XpeM0b/TtKLuzOb6sVsgHj2EorP1VazgOQT+pfmnSOxuG/rvsxadNC8y9CygimC 5zY8fIb9oHAFEXuib3wsz6a9BUUoxZt0jikbBbNmlp7JGxhBRSb8DF9RxheVj+YpAGczCrqRdWh9 XdLiarG+//4p1FIFWlWL7VX4URi/Qm2QNGpfogOUrTJz7eTtSYxOskrNY8CHQiguv6klJd+3FPuv +Nm/JqyvoLMtzWEAkR+txKHBZjVimcW9SI4EpsUICqNFau9/rA+DLEzN83uFj+V59mBfvDs2iSs+ JWrMdjBI+C5NpBmi833yhVeLLgq/iRWGjG+njN/L9fjvXS98QoMmL13VKu4ini83mFEjuj/7TaBl V9oX3WqV2rg41HAWshL9FQyw7sBktUiW1xS4QtsQG88cD2NMpz3ftNTr0MkdoA6z46HqOrQ1KvEs QXSu3J74OIQ6LUGaRvJdqA0Vp9nFTdRiiF8G7J2vEBltwtfWNyvoYOAlhJ6KyCdE/QYjq8b7AJZW rtz5qm3nQktq5WaWtiazzMVoJM+aAQWnGcsNx7jdMBurPMvK7f3Q4bfQ2ndu0dNJTf1Yiq+ilDHI g0j3njeU+GTupzwV8hvDF6x24UdUmN0tx+rDRY7BEvpc4yKJOL1s53It6Eh6ka/UQPFzC2Om/zK4 Kq9+eyJftk8Z46+Nn92z1m3X3ljA8weD2X7BkOqS65kMHFFO1aBMfFcUx/UMc4WD2BDF7AAGFIrm acGSCfKGX9iFm9QRCkItNS7mFWw+XXwUNt6GgwQNmVUR9s1VbCNgGMMLisVpwZ8T5GJN9ors5Ejg /QwjO6yM5QNLVMK46IPdLONi58EBNu1YoqNgVFJXlH0W1UjmwHtWj1IOdRLJYYKmsl9cMOhAld4c kpOE7IFmBfbKO4+1z3GuwSpkAweiSQ0B2SNqDw8SDiMRDk8efTItk0n8cgYc2Cozb2BkcWcNOXmS IGPKy1482OD7dUkKspPyogyodfBJZoO5F3TWFYcJxLQMW2Gm21kTWQ9MVYjHy0tiC3iYH5ZoOuE8 82T9RP3AWKOdz256jSnq9aM58t3cACkg1t/7Vd7gHFqPotrQ3VqRAjV5oZaCcNsJdnNBHOqHuMyl ZvWIAxDNB0CFS+SwTv/EP/TXi5bIYCp3ryJLE0K+0Pr0eITuV2WE9qE+uO/gQQpb57Wj3sTI5s4i CL5x5Kp98N7jIdO5LIhjIPfgPRIczA+HTDwILGIlQrtzkBHK9qCuRjsPEG71T9CsRao2F/LEB9dF HqFQpKQR/KDQBc8HiBbC/4b4K/Ala8E/jICd64JRr6dImk6hnzSzQQuFn4HRtlWjofiwdlWhOylB jyLGsOVQke9/lzqDsjrVn0k+xNdKaD0kULH/w44pF+gXlscPZP8jdg9Brcj3RYw/YqtF44pfBhny ovTryAgIIarYgx7SKWblSuuqa4OMK5IXFP0Q7Vmp1eGoDN0D5wfo+mIK9hh/knyInQzEkNWo+4cH Frhl6D3LI2CehQQ7p6mE2If0Ew+8XXwD8lpJeEzZwNvuxbe9+3/S/LCctD/MYsNJQuoA6SGxdOA2 rpPgP65qQ7E624bEx/EfYjMtk6/kgKy9H0EZtuLpKbeu/nO7+t+3kfsjcmVVfzwqbggFAjrtVB4T Yfsr1ekEgzkZSyjoQVCPlR2QjXfi3wjgQ2hit7TUgtADcNnoCAs3hr85EgFxRD/3o//LQkR4QfBv IYm0QnmWNygLMf/yjgGSdd5k/aV3sNALShv5g7Vwiey5IHf05L8fnIBgU8uPaMlWuv6FVgS5P/Iv a8k/YMk6h5Yf3wbyt9bAPojHv0iQ/R8SmeTPSR9L/qB70mn07J+ap1SOyf1XGS/GVy2n7GL+feBB JwqHPObICSc7g+IfV+G2Fzeiv0+OdNBKLykWjxlj6On6F/PCDrTPv7sHxfSg39F7VXtRu+XmY6ny wnPbbzCVCjb75DNI6fyFb69MxiUDeUR8z67hHvz+db8A/swclUtvn7QK6tNjGnP0zJnPT9wLgOpb rXAdG/xvjE/M3AgZMPdrTkhLWndYlZ1GbodErksO/cjZ0vbuKyMZanx/OZ7SeQIOhg8l3GI6ybY1 kHM/zled/WllxH/PObDPxbA3oh2w0QMqzbFx5gjJIt4UQi4pdSnmZdmfAEEWw063p/mFISdv4wCt DtsK6Q76Qv56I7GcLosqazqJq89dAC9yHQI+mdExb3uQH4jPubYyKzvoA1i4y/g/NTF7sUVppyEd vwmMGC+TWbHJOKtn86heDkPdg22UJEmwQq8CHbDmGOXXWraIUl3+tGVtIz/fj9gb74ilWRimzbkD 5T0cc3gbX6IL0BApV4QlM2oO8MR+whcKNhtPVO2z005lUdCtWRDYx+W43m1e1Hr2UQl+eDh20Qrx v4GJZllwdzQ2iv5wLOYqrdkizaZ03tf2wuSgtZl/nt3kKUziZUKz/XGryq6Szivqa8XWNMI49oSZ 0DLuzzV55TiP5uyvkcg/2KzrTjbYnQjuo9EnlaDuIk2dkMn7lBPCA8+Z+Y8CCxkPTRjZTqsbzvb/ 9jwdswWbIUnr1KMSXZUUuqeYvXnKJ5XtUsaokVvxQ1k7ZLAQOwt8laPirvy8IfiRdJKsVUZevhkw CD2XGIu2E7V//zBKHk20hUg9yKNmLr8cs3X9d+Dz21zRRgBRyMCrXMchzdo4szO2NL+IfH/W2HvP oZOADkXBNMnyKV9e6VIKoeiaI+82aLicbjtqxC2WpEC51KS9wqex71uLCiB1PeqIpxz4s8/jT7uG EuvMsPSdjVhcZ1W12z5T7eCOAeuBr8yMhuwrzAsYdsfSQvrukn8roHhvnQIM8RLUWXMyY9PLED5e G2MlVHsS4K+qm4gC74hzp2sWRvB98L9/XLysZVubFNZ9lvICRKHcw1qWyp+yC9ZoVMiwM/XOZ0vP r94rIhAcrPoA59s0215b5+VTq5JRwt1cc0lLe59Y7Uz0bTzKK+3GC5plquGfBvNN9yC+IYHEF+Wz DabtE0Oni218pcp/qKTXVTfx/P4Kpp36ykQ7S10SsUnTAdPTajUOnfxqQ7vwFVL1WX6MPkU13ncc sJnEg8uX4p6Z+CRjJsrXpvxARusZMV8qqJye8N1lx3i8N+Z3bhU7muKvH1VrmsB5zpS7IMR8fQQG 2nRvpY7zyW10M2wUyQpnTlue23LzAGIlXy/I0edhtfQM2SDqn9uwK/B3q9eNFXPrvPQDk3fxbIPR Imtft7Fm+sd1F7TTo46ElFHmrtjrRVJszOrxwOMXyvjBWTj1yChnfeG9274XrQC9Wdi2wRBXxaCr zb1l1FEaadJINCrcY95pZ3AbhPBCxGqj+WrqWvbiVqj4UjjrwuT3D3hI+Qc7Sj/WLffY/XqJ95I/ VBI//G5Y0jGhab1w8FbjvjxISrOx9/MxEDNYwpR3ulDpCh7NaiFJjQUnDTy2zHslt5gRbzzXOCnZ LwWzUCZqg0ujjF8heSDEkDYeBTWZeVbMkdZtXulGNGSYmBjwnkiTD9nk+s+6tK7M3f5+lbvuQLlI 9gXFGFggoOONzjdc7jz5Fu3JdIq76BaSXp6t+uaVWl6ihduX5EGFueNkuFO9kv40mG3/dtpPQsyk amD84Ie1baWJQ4pqZUTJO5exLwe3fPMXb+LNtLziWWbDKMvRtPGvondb75QYgu1f6L4BRuOFwUSi k48AVi5Ts6GiyLEcHFvp0ogrUG0L82kBGpLfUFccuyK1XvI6lLxJ0m/a77HttmUupZIQqfDSf4fl vdw1Ohx4N9JQehp4MZQ7reclRXzLmXe/AQ3g7V9IgXxeum6tOjuXHVpxSwLDT/KT6fTubuewNDXO 85q3WF+DC+wyQ/9skKagI67seMn5sRD6aI8ICc21Q4ap7TRv3UQaSENfXnSBhu4kaTpWliXkUpNp +FPE1+Bin9febRB037VTPV06yJsfWyPK6vz3pOn638MapTVLVy+aLEde477FqX7thjcj0SPD4vNr uYsJveGdF8fAeuK52ZYtQnGhCV4oK6PklcGrzrEoCc2AbkIBNEz40ul/P+qd7+IjfP9wCfP+/88C uP+cBcxkPp4FdM7P9/qiz830DkFswxHkgrqkN2vdZrzoj2ph8VXzMzgq+azKdJJSw561KiYHEkuS CcQ/rtfqHONYUVmbV7MjKDO/n/XFmCRhrWvoJ6T2d7If+4zLHxf6dR11Vlxr9kVbjF8e7prcH1nH JWjpZ2w1vD4ucu2tbgDWHxfpNz6P6tkUMaLPq+nND2E/LT7K9xIcrtLjV5LN5l72afPtkIW/gM+6 7W2bcxqUDc9cZG6ap2rmFUR09renZomx9UGiiMTJiTdpCnud4Z4w5meOZXAtbqXOvSI5ePVFQp3j /ExvvJa+m78wKdhCwDVzuoyFp+iy690c2NNLw9cohbblXX9V++cahxGOsQ6v6zVeI9YMeIV34qp7 6XFFdHz40iDpa7n55Apsw/XWiUzFyOwK7xONqzdofvfs/rXefEt7Xc5v/b9Cr6eab5Og/lZ4Yw3H Cy4ETnvoceiBZcV0Mzdevt6umhwLtUa93/yP922vm77vR90+Yd9J5vXO0ImymLdgtcb2MDEB1sae e9Vhhu6HGPD8Jtp6w8ty1x8ZWGBbUPPpQFRc0w/D99flbg+MImMlJqI6QorRt5CmmbYwSLd77XnG TJahs0ez+C/TX3kZHJVa3hq3u62zVwuL29W9d8nKJ1Lezravn23e1pAGl5M1aUvhy3xcCsckCOMS GB/swcQuG/cv379SFoD+IG1rMg0Mv3nP0j6JOwDeZPXU16zp9ndkbrTJT50+7WVDZKkb1Qn5zRPP NPWuGdSoctQZUbXmkUbpXwtx6JEWC7Pw8+3J/8mnonfLmLUVwq4v23Tae9K6BT4JMFu79BvMxgN4 OMRNIrZujSnFFXU1YZeNGM/UyDam9w1DtPy8TRth6zKpBesCB7+4AaNXVbZGdFrnrnb+2mCYO57e 9VcDHn950m8GjT35fVp+vT33hkbzs94jl0eO/jE+TMXpzkU6JhFKPRO6/UMniRpgL3DlHGaGhlGx 65Cl3YCTsiK9PX2ScnIxZYNXlAA9K33BuN4ZtHuRHmqyPfDdyi0mZvfMMrqE6LDT8nDUKCdRJ5Iq +dvZlE0B7XLrzeQlTNmcv7JB1Mq9aLoCK1qQ1N1iHB1sKO5NxebAMMs/osdlBMYvFy4+JmvgAutV 0KKm5m5fLhR+Oy9fw9X7sb5SOCxeYO3Ilx5/ihgplxnN8d3F4Wy8QHoY/Wv0STQczFF/I+aV517D 8mRgj+W0rq5c9/hOvLUF3exQlCl7NpyjP4bc7Ga54moddPQKlHozCASFhn4nK9u/ylbnW7JarNCk XZAakg58bxNEYYaZjQ5S4Iv0ds4lfzOopnRReaBbVOGGoF/0wS04hDLFNoXbdBaOpu/qSmtCQqUg EOcA++AebBVhOLGmlTPnV+LTKsUxgYFO7uqaa0xOpSAYXuo8gfVpnDDaNGtHI9pq6GO059sr0o/I xlisqyndAasQe207uY619Q/o3NHvRWHdgoNULzKoyfejYtiALXa9oW8bBDi1+zGRODZcoq0I4vpj Y85lupJwzV5aS0nOPQMoCH3ab0/PQMaRbCFDOpq7mGihVuyye9/ljWyBJetVPCBIXY0hD+7q8qa1 VJAdWgVGS6zIeTQ650jIgtbEU+9AVOndloipFgiC6sbYCchsksPNVNwMkV1AaBf30UWoS46EHAjw ci340WTNeGIdCKd5QYFNk66OUzdNjPZxeULjb/BmBG4d1xBazoBiyZhzwc7KDTlZU/xJRfp0F8XE oYg5iuJx5zUejqkXFH/XY7W8Z+V83+uzWSi2O0FPfWjKqYffYRnYbNmBpHLiia4f/AXabCkBiEdF iyc7b8RYoYC/ePEcmxlLOtkdCZuZBxeOJHCfT5uOAO225tZTxFVNYUVhleL/6YKkKLnUHOD8EpCA /JQRCzXi4ydpOSGAIi6GhXNAywpVJXMcW3ysB2cOEB9tFQG159OlVscdBdZjuJWXQ6uZ+CHdZtjw uFSrYQKV94FWPKmsrGGMutGSqim9OX88aeJi5jq/l7TqNoVwV/2J9ctZDpAk9ZRVATM8nuxBanRo D7WZJq7aVyB6uUiq3h9qpoKarp4Mks2V3PO3wz/BEhHRrjTYzA+6qwlKfqoMN/3wL0+vAEm02Kwu JgE0Vo8qMcsGqwm25HCfE7NqwJT+04QkSPJfJuHs+3LYzC79ZoWV9sMEMW2/KlMVSZLo0JIEYyRK Kh8qBhctkc5Mk98EcNMJn/mBYVpSaU9IiIeWRGemm8Soiwv4qrU2+OhKoeUr6wNuOd1vvY8ilbMS G819UCsHno0JN9wLUEy2ART547vNnSNbVrrQ27s7Z7gxP6Aj93CZqUar5QClc7RTpSJiXTlTgEQd K4CQbvVf+lbHmfBffzLH2BksISgTWKn5v0YsdQ25qinAsHLtVAN6ikNGbNYHScz0PpnqOal+633M m6Z2sNqka4DUjaJe+6PZHzX1CEKtQgKtFtFztCcrHwXPZ6GeZcOC9gRx6X6zSw9ugwZa5W2Eh10C 9EkUg8yt4J9zKY5FrTmmJ3Y5lvir7m8KwWCszm9f5J5HWPIJLBYaABxq7Bq6KPurPu/UTe298bFB a1ABe4v/nDup5Y36iC6qt22dplMnkpra3yUuykayOTieRZIgXuCVqt2u415+pGBUI0TB79Iw+o5j 2KjTce3quH/Zc/idawhz7ajS/DAP0U8/9XHUIyEjxZOCE+0aOLnNgA3H5LvywswanSnvwuS6s8rl ErTS9Zccwl3+G3kfH37gsLk8O4l9R+D4L6JeKtKWnCpZ1XubOkT9QF/f5BOzEdIcj1Kop/9NW395 Nj3/X9uXZhxpsUQ0BASXp/9/+8Lzp31p0DVwSZd56reveI+sBA5PYMQYFK3IaK5TodOTbvuYxQ0o eWHTxh1g9+1nE9gdcffJjtMUxLNcth7883j3R+tY8jqUQfQzp3PFfCKfdCLdirDH8lV9qU9kDeV0 5cnq1Xp2qbXb09zysFvApdOLZi7xrZ5rEK6Y1rePVbLowuq4pURLGI4W7c1hzHMORuhalEYIZVtF +Tp4sG34zk4Bpzs5ehf6DBsunhuQCTRDh++7A8TLIXk5as33KosCefbNPhqB9PVTVBi0zhn/M0ZI jFxTk/7eLoJ0tz9keL8HR69SGVFuiE0vrU5Mv4MBT1u/ktdVdP8GLjngdLZ9VRQmopLmvhqyXWa5 GT1ROGInMKpf8Ft9TLteKzmvzMiTHzmjVOTKJuVWfRNt9+VN66/54h6tRlYd1IzTmMVizP4rwvX0 +g/nT+W0ttgajXWET73qS75PU7ydpqNtWaG1oCsno3WviSECsLlX7MgU0di5XWkgWodn9ooVfR5P qyu1/iLkKZRw460FeZrDuf01fAoyfiqTD8PkJKOQEUY3vRDGq4C/bbGZxx/FFhUwLQ0OGKAK63AV 7OqmszRO5FFbuQux9ogvWmvoU8y6qNcaOXUrmSsWSOuLzkpdVc/Y9OHqBTktaYWXsGQ0UmOEl8vj 071y9rNebKFW2SV6At54G9PSljWTfwok9ajPtdHP/f1G3YANPcksFWr24WkUvvdHyWGbQNpkyzJT 69COr5mNxo5baVMONlfPFhJO6aiygTiHiH5vp0OkncAdRZY42r9r5OfJk4tFaVjhiR3Xc3O4iXS1 p4R6coAuocVPKSiOIimRHdpPdANZ1GWSTUkhI4TPk9oxh54GBouYKJlmBn45G3E9NEvIWnbpMASu u4Qec+WIvXUfu9CwLAN799dwRTD4OUY2/GoJ3B4sERa4auLUsW2fpPS7/F4I22Yzrg2DaqQQ5+wk azr3EG6SDbPuMqnjhSHiQnZ1XnQHpCniyairnwk8wRPpDF3fu3l2kwEGHUW/50Wuyz0uoNJjezlL x1WmNu1rgsPmwk2O0zu8QHA1aIORyg4iJNzOBtY33leldABVZmVHxS/5qzXfOLsPunikuTRgcM1J JvfvD91ZL1n0Tj0jenNUQE0tf57LDQVrX6F6PKnAFhGI3r3+kvEEyR9otB7oJoc02vrcmk9SA9U2 q13O3xcKYJxbKBDAwP2U38AoA2LbAawRp/B/3ezn8+Nm9Q2hlkh9RR8e88lkiEX/cjhZBrDEEHd1 4hFVQ1Gy5pq9d7grxRb8yZyTytIIDTCTRvqC8LWM61Gmc552YURC/2sedWaVohjY2VAE27Uf2XIA gQY5xfehwWoYmjL1LMi+OXZRYSWWXNE67QuotctyiaHyFylEVwlM+duyP0qU5dSwWQ5LdQo2gJpB pC+hyYA9Qk3dSiPDvENyYzUODmj4TEqQwBdTgcSW8AoqFPrDEpKqYMHPyNbZYf7ytYd+AzzRfb8n saJe3ltK2vVUSJooY7jKVx08YeS5GlsXFmCV+SHoC+Xrtr1XRU/8An5+iHhlIiFbSYGx3WYQr6Wj LUiZCZUaYs+qXm78H9a9MiquZk03wZ3g7u4SHAJBGncIFiw4SfBAY427BBoI7hrcg0NwCE5o3N0h aPDbhHO+OWfud+/MrDX/er+P1Nu7ateza63uMp+Ad37o4Oh8pIKVYdGlkLPRlLm5HVRt4SU65BI5 qc4beB52CYEbXB9WcF1aFmMV0GxYpbM6mhAZwXSRY8iOjWvpB54t4f1QuJikPn9ArcFtA4vQFa/W cZhT72IWCpO1RBs7HPNZnXg1D8xgV0ACQirVg+xauO2+5P6aadeNPxUtlezgc8mZCh6JytBvhXIx 2Z1EoaVIkJI6mWHYWXtZz/7VNxcLIWcRmnGnxaH7Q6VHaSdEXL/6FUxmrQNYs/PscFdN1Sdd30ge wdmU1QFbYGziW1LmEOO9brNSTElNvZE4IuIQ22q73t0Km9z2XbMU1vsozge6VKikOiWF4Xi//NQZ Yi7IEzr/CR1GowbkvDTYk03tk6tM8vYrIr/MiKRbifbvqBeimQIBTYbcGabjxYU2AfEq0thtmclD vxyjMuq/U/rGdeyhzOGbIMd7Nn1Pc1LcChTVuSClpj1hc63rierriCjtodMdj3flMHTJOlNKo6d6 KQcjzx7nt+s2eivMSzBoN6qe+LPQ/ET7iiDI0pQ5oV0ffDuipPJD3p1FSRdZ/LTqS5fGB/fd4NSf 46iiroqbH0fls0m2tylkbYLP+a8Og3UgKBKbD8YAmX0Cmzccxl9Awf2iGKGiOEEX/DcRaw4Y58wg ICWs4gl8GbOXYPM9yd9lWdPyDJovNMuE/j9ZxvPPLMvhIwQ9ZtmCqPGRO9fyjXIqWe9l4UH9d4uD AjI/8xQEGgR77Mupy1g4nQ7a2I8FG1REOSoyMksHsvogkKjrOA0KDcGNga6Gpq5Eqz9/Wdvej17X mwY2BaNy77uN97YyXCg301FgChlsxdOcsuaotWWFWmJBj08VNBvLQlSfj/m0SD2/rh5MOquej8Ef F5W9dz83bmod3PRC5rBYe3bl09S90v6ZBj64Cc7EJ23teTz8i1pddLBl72v+2SZxqbFWKd+DzDLS AEaJFZqY8vLBFrJMxisOJUSDBiqFSaZnLEK0Ci+nZCw8T5aVFOKly7bSvHW3BYe9DIzOwVty4WXN n+6+sC5giTknHwTp7U3oFc2+r9utOitlGdny+fmld8m9J1OzUVyY84HnjL/Y8Q3HwJvnlneiqbzt ulsOrU0priq+osXyLXlTe+8LDO3qal2aYB0GNKg1RV/qwaQhOwJvEle/hrlUVn9UaGgfNqb/PlgR K4j0e7s2v6yYqHiYjkL+IaeIB8U40VsTcFCz505DA4FLjMBcAz0fPQWSmzStREDEVXQs1hueo9Ln eiII7g4NrgQaSGy+EYYFHC5ZfebfGddvThphojNY8YQB/5iP4bf80JpolSqIzNI9GaelNDVX6169 aMUn7I7FJ5fT9Zt6lNVIYD0JJLFCSnaolvg7lqQmfS3bHqip9GGCWGmX1cnqnNVUgBncimXCoS5r zuawHgODfzu4TFjnNL2nZKAxp6TkDZtaNQybvgcbo+jpQ/ERaK0272b3piqIZe/mk7GS/CQ5VvyG /Jqpt11wGLLDEA0qHawzgwhu7LJS0M9fXfLPWSoAPxgxewgwJpQUXHXIGKQ04GJOPSV9L9FozzPy wzFzzkgzFOj50ziI2ft8rr8fvFmzBFe2HgguMbBm/a5EPoFBRSyTDD6c3+4d1ynFs/T+fXCZP1tW 57YmiqH8btKvyki9n0lBii/XjZlFneIx0W60aQsRbZKUI3JzT+1wyV19PdKbTu2OT+k6K4FSUpjb IcMjfu9rnzkn0LZIgy5NeasidlxFeOQ7ZaKzIUjyBki0mpMjitBEK07sgRmZl+ERuOL7yrw9T9aH oeLkm0DV8/bF7gAXswOCaI/iSqJ4bAY6vBxc9Cxahu4pwTJTAJGrLencpZwYHtq9SOMwLJ4czEQv uYUSNNDs0odCulrb0fAfA43wc2ZBsxU00A4IP7PaLz+bqkToyHUTYgb5O/lxR6LhUki2ZWvXOIrG t3B2qeSe7ZwRHwnPDu8IkK2dQyNNjnKYGxbNNpI0NECdQ+hKuUG9eAIgvwV4DLT3Pk+Bthjh8D2E KfLzrJWV3lv/zBeCyryEzPNSGDvt6zqxPJYCvES/Q5uXU3ialaLEFM0FrEfcX01xjWPEoVw2+DtJ s8h+kK9EiqgvVOX4fVCmEZBQk/1CXPeUkKUii5W4pktXVXGA0+P0XX/qWbzkeNfPC4Myz9+qZYrz SkUYeFzTe7hKSApLF3IF734tEwSvvoIrOUTDpQ1jxBrBKWaWgrmnF8fOgU82E46elmvOLy4rcVQT KgjO3kjXPDU08qE18UNviMZHrutISztEcqf5uj10cLAfWJp2GZM7yZONbBhCL/D5VOV5SGjzASkA 3EITfMcjPtKVSb8kh2bLBNwn1kT6iuz+VraMU++VnjmWMT1Gn53351uaIQyhCszKqCisI6WgaNoX hegCmpHyprgkVinfonOtWW3ZfkWORl57rItkogd31ZF69fuSgNNHFAPz7Sg9nPY8CgY806/X07W/ 4tY4R0p6Ks5it030Cfsqnl+WJWCvzQaYH+Ff+OJhiu1sEvZOU7SnRZ0sByuS9nhT9kQ1e+dFx6vK NI1iXMjZnwTynPPT8EfoRFYF+JGQy2CiWVjd7NaDyT6EPYsRnZuT4F0ifYVpYNLS4R1x/Lybap93 xNM3dFJ9CWmMRgalLZOAraKhV0XfJFpKfsU5EB21Aa7cs4kyFVXx3OtZ+qsCpH5P1LLe31i6iZWQ emrTKmpcb0Op8QE+NonNGLi4j4zwEI7X4WXd+s+WKhTfqRWUNcwPtB2LCFs60g2e1z/MX55ZxazH 5pcElLjNKKyW8Kadt25/Z9s4yen+JH4ucM59PCbW3vL1+dESbjNwrAiPbuhBPDw9xuhMqyVE64KL 7qYL1vF7007BbSeWoKXHl/SHfizaq2gtPLFnhg9/++NLo4cN4rj/4gzG+8/cmn06g/knD2tGv6AK 9TBJBTeoPNdQJXX90WfyHCJRDA6wud7zuKCuRK3qtS6A+L/aT7+7mHO6GpbXNkq/bD0JyZ7uFH/L y2PwRnV5tZbg49wu1Yznx6IfCXsZ3o3JAg5+2RgY2Li0lTADfvWlhzG0t5rsvYcYB2k6cx62AabN cjwERwOu1b/0Nb3OnjV/3A3SXRQ2zKyqzcgOhwhIPV+2ta8Bxuh0jsVLfqr0mO789ix7agDrJA1u u0eYI4JptkDgk/6EVidSN6O71O45xGQrgHHz4YtaXemkZrdokDGgQNN8H94KTAoitP4qv3R695OD 5BXDTPleMcYJyHxWy9KwQvOL8GqBVovuT5ZSeckpkiHpN29av0H64exnd5eLeY/wUfitUDcp3Nvd dVlTALWsKyVeaJYAe60tgaVm56qc141aNomQosUirRSlnJmP4tPDRFj0FEQsoUMv3OYMOt5FhPub M4zzWldByBQ4Tfct7sd4q9X5lV7RQBpzJfvbpmr1MFBOP5ftlFpASsznJp/T53RaGT3TAAUg+t9p n5TZ5/SrXKzNtbluJahSleiwjAZ9aN42mHbgLp8dUtu/C6R3TbNlk0ppSO1tUuMassjTK5/cPY9P atiYTz24MklG3qQtwp2bgPOWxF5/F0u7KsW+OjgOeE0uLIOrNHpPDpjP6Mi9S12XasojkS5VL9Yw YnP/Zj7icQeDFYl0Uyn9432QaZRm+fqfU1i2YWlK0GIJySbJcg1EMFOHlPcKegqbTVJyYJisMr6M v6hTmyLH3yejZg3Pm70ZHg6tgQ84J9VlJvwqtPN4CpsmQQ9yQdHxo1GX3jK2NP8ZTa7VnWoV9lrd UBOH0JKy8AFNw4swb2tdk8tyoDsZywTtK2aHLroDXtKeQOuNTd+JXCoJtViNw3bDp93h8LaRzYEv m4cXbbd6U+L8gDUMjCg1+tczHHnL+HjjL+PkZjXiMD5LkKodTOF2wyjlo5oGDtzr4fgWTJ+02Nj7 Z3AQYdzCUg/5DCeuMjNqkajWiWyh7zYdDbS+okBHaHHLukQCWc0EyyfAIAeeq8QvLD4kqZiG9S7S 7JLDIuox8zQIbwtSDzGlAwjtMhWMhsfu+XqDA2r5LVQJtCXFYw5lbNxHFK/poIcwJBCHXKoHe0FM OwXiCCiTLOaZc0VUkjRh4/pQLNFOuR2nf+TU7x30INBoHMEQUkFS7HcQvC3JhDNDJMU5qtFKTGbk qqA8hpoqt4L0L5F4LdwVBvXrT26AM7I3TkIqW10XWVsd9kih7Qe3EXAFZt2939nimfOKFHdqrKXl mbPZZwUQxSrTbgB+ktKKxbVnekOcyQhwgZ/WauAlAzmiFXgS563rBTq/WH/O6PNhHOdMXgTpxAry XijuwrfLwjPazDE8J4iIj4akvnOX66sIiXVsCiT0hSAvO+YQYNV8CakMMGAMJWazl0VB6u9I5yiR K68g1KsmBx9rNofnAY/C8rLqlD0k5aAv2YBYv3EHmOyX+yWrm6qNN9FvFkgDmymYu466itAcfNpE pBxLMmkE2XN5oyatZrScqaQL1kcjqhkOXMvtXo9Hm0rS59JR79tvpSpLuT8m1u/AnLThDpwPuD/P hgGxXYBjFYw+mKsU5DBTS4XDK2v3TWyafmOlpsCdUrapt5W0+kHep7Ej0VO81h9TPG0HxL0i8ZpX 5yuBX/XlgybKnXwd12zGmCOfxzYdz/vi4JJaeY2FGgTAeoZ0u3LCpft1kdkz7REgMCblKO1iswv5 xU6H5FqkkTlSjCZTV+YzysfXm0+Fy40Y56uLD4KrW9Fv18wBETAnMYkuxNZYX1rFAzD1J7tKr++x ZvUtt64Em2aGXXb3da9Cw20x5Pz8RZs51clXJ2Bk+o9CftGslcetojE7kAiufEbcasaVaW88AnAV O1phE9R94CTMGSo+Pd3Xi0P87jw760M+T+pJ8SfLfI7J6bBSz1OvcGMNh2DZtvkaYuAE3/N1h5N5 rXLRMUljMwXy8/KxbWCjwSsrCxQkLhI0Ls9ohEUP1q0sEItRk7z8FqRq1swWqiZyJLGTIgSNM2wM eYw4v+SEzISjCT/hxQoFW6WC9AaRH232IsWyWX7w0EOYgYpJevqP0fiYuLZ9OjdIWNl11jLPYCom eQ7TwRYM2SnsmAuht8a+V8gbOgbze0yts7C77PIiwZKqI86ZXipBi/G8uyEuHNdU9RbFJbI++CBv X5YBI4zyB4S/izI6C3hrPspnz1qrnv/tH1/+8avovdg5vpiH9KJbzEYV+d1J4laKwoi6ZpdUpzc9 W1UMgkMFpTNcr3JYotZjzYxul+w0cGV9rCReF4cqvb/qJ5ffRZz+zevjtdzbdn//2+Eib/ZQK+V8 Q0Qf7lS3tnWu2aj0iGMr45IiHfd0xijD62Yoys72qHgr5bxV7wj48veYO1DQe/pI7M7eobLJ4yu5 HTC8F7LgUj3nOc1xyBdFkIJJoQWEdCfgRbeG+HE2ujYblG4N2XlPv29b9CyafH3ZaXHj2rTExjd3 QxNKkNI0EvUdPwRupvvbtWsT4jsgZrFKE2wthUuG7VHRwFWBTW3xN6Oiq58US6/mvYpcer0tyw19 LE5n9uZ6d6cGrrwf1ryLm+7213Ylzx1qy5K3+tb2yjN8tkfmhrZUTmcgB7ZGvoNYL7wNQbcCHiBB 72o9jq3qJfatdmrME26FVcbITm6V7I9eWZ4Hm8e1rs8zEM1JEdRw883JB5auMyA3d51gPaJca8J4 gP6mGhZ+4W2LER8Qe4k28oSHTeG3Y/yznav9jY1byHXWfbfwKHZPYXyNl93ckEz03cHmwx7i8ciS pBxeVnBoumqT2qZcjWw45w9/CTXTq1WW5tXOxEQrA59nKt7NAmHTCc4Lsl64l9eUba58HrUBz4G4 Le+09z6/cCJDpOGaEf2IAJFl3dR8uUIb74g9IBC6kdqFomxCx1A56oyCNmKIzB0xSdiojIsQX/Yz 1DdvL9fUeEeIl0inUdn4sZTqm8dCyFnxKRANevXdUXSgT+xa6n6M4SRKFOx9Fnqbo7JOATKWWyzt s8G3QIvt+guthKJ3OSr7FCCTh22cG5mMabHrLih08Re0SgHCftiO/S2TAVXRQqFfUaKh3mdyt39B 1zIZE2LXuVDoPEq0EApBVbsUIPW/IDModBolmuR91g9VbVKAuKHQlUzG4F9QAxSCqg4pQJQ47Zcr VtAPjlAOtJ95set1KOcySjTQ+4wJKl+Bcnz7+K9x78cQq+qbP+xQgFAetjWg/XWIXcfdjxWcRYnm eZ/5psotnVY9fWaCWkNp8lDa5xBRK+nDEchm5axd2/Dc/Jwp/QFHtCioxZrc9KX2gCm5PG8c8rvT XzxZysd7u5d3P7cgLm1+Z6dzoPMDfu26D30GSxIYN90rkrTCIskjyZ+OJFfrZS9Fbx0EE9BnuC+v V481BB9I1auDBftcwu0ZO6l/OAlA4npV1qITBfoswuy/n/QCENA8W5Suhn9ws3dQDmQzyhoXCPl7 Xhez6LL/YhHMeIXRQT28xsih0KcWrEEph/kLxFv+ShFWVWhgtUoxFg0/b5zjrBLer9OUZQS/anOF mtmfVTn2BV6rhtaPsASpnjgR8RM7CEjb0Fg+j6DGW68N2P/Br7zOrlZpPUEqvggx5JSCIoy+uz6l bNWG70GiP8jVvuJIckeaT7OxUsArG89ugmI6wU4qnBbppwjTCQ/zONq3ao3zng4zxzsg4wyKZnKI fGT+NBxTvb3Bj+TqcbIEO2mTRBzhVy9gnekSaWhwnAy4iSGfDNCIQ/sXxxB8IrrMZFz5uGa20pQU XWgscVKK+EfDeFd+RHzutxLL+i+XcaG7Ke1ZUhF/D7EOdHlCl8xj4fQfhQ+PVyXAHe+Dl2/sIs7Y C3YjKxEmH4Y/FC0S7hlcL7kpQUhoWh49SnzP206Ti/il3ROg30UHdu9hwu2JJHaZ9K/lecu/Lxcc P+m5M/7Frcc94R5oCKVQVLmvAc7hbTF+X6QcLXqWLC5pL6Uw82cymghcGrlkxTc8uF+7vVulnGPt aC9zzOFxiE7YQgoWA24g0HYQG2aQZlIVe2UPmzAvqB7WWKmnzMjzZ1refq8lQf0FNmxW8zYxagGz +nEHKnDHMEaOc6LiDO+iWy1TQvy+8sq/ZxeLo1qDvOxq4td075TLiHH1B9p9rUmG2y2DCW5xhzXl V6VxaOya9p3e2UVHNCkgiMfoUqZIEHwh3ILnTEnvIdtc0u6buI82Qk9/01Id2p++/tEEH0Kym4n+ uOcMOqOX4QRCt5tPJtB52iGEzpMSdGZwEqElHkvjHRQENFYDKn/orFWkjoxnu/uTgFgPF40toQ8b axH/dC308cMH2lV8+Pdr+w/WDpcIwgoPHyjCmx6rbReV9R7+Bv+vQn1tDfQqLe+hNqp7gWRf79ro Rme+pb3sPxdK8wDn/23bXXRbNrY/vXofmELbaYq/n/pHs/9e+N/sFtrfv9iqtbQPjz/M9q4eoruw 3ZX/4xb9e5MubDL6N5lEDV2LN+0SLdyw+J2ShUG2QDvjAKF2zKkPzYEpqC43B6W/OiKPb0n4J4DF UzavOawkbXw/lsnatFfar3V140R/tDWmEpYJAGg0ZL2nGu9c3rPB+RgvzI8LgCPgzWgBbiHQrrQ1 p7bpiU0QHfdtp3vv9DBBHlS/kNRX+CfYonm1gEq9jxX4O1be8nfJyG4E/Wwh2aFW8ecM88+UDa9f bwGaFs0nKgAdavj5Qwu9vbBv+z34J5iMFe2AC7+JQxvYmSO79PmLpU3KUMVpuKbQ88GJ++gjfOgz R2lKg87t5ppORfMCk7bFTho+fmP8SYiTzuNcFZ/SkqFLi4ETVmHKevj7OB4adO1JIMAqaBsLZmxo NnBhXyt+ITFFL/E+S2L+86BuPD6ojzuBbcQ5O/Rm5v+IBC8+Mie/P+4EUHKLwoNweaGjaS5QEEri rbgfeSRVLuY9OGX8X+W/tNCdgPnPk/4/KtOk33yCf6HOcS72bqMHUg0cUQTaBGwZfcuiJ6c2hw8s zJYwzKPBw4sHkGwZ1UEnhbvz/jeAJNrX4qs22BKJu9HlnFljrMfrxnlxc47i6FV0eMmZGfDbHl+m WnW97drMgtf5hkvbbEmKTILTFbKj+fCGvuGiwpHYf7zxUOfFKL68swcjihNtuMUQAIjbeburjTi2 tLUducC/wZ7nKDV05PfZ+gW47BJrwAcEiOUHsPPnsPvNmbmjxebW+8MFyTcHBCven8yxm7q50e79 XrUh+x+1JZTDCFZYn+T5A5ILJJmrOWOLIpCI0Rlzd2FZiW2yAVhYtVzcMSKm/Muqktz2XLKZXxKk UM9aUn6O636lxMHn0sqhvFajwl23xumUlUhPiwR16ndaRILDWrPzVMc6YVc6dHFnklADU0O353Ts Xw9rmo0wSDkU+GkmPCNvajGvv9neiYKhjMoW+DmKzkeZiDIxcgGgAo+hE7z4qcuwYM+k+akTHWkT Zs8YZIZ0kU3CUTJCegDgN7AkljWAgf8Ifksta/Zpjw48VpogJV1niE204Cln9ukGWjh4LBhBCwFM ZtG3LthEZD5yZq4lApuVJrRGqbm4UXg0ZFdy48c6XDHeSjFBvWFgjEtc6+h5S2wichbpxoHY3JV2 E9qERFp0THyahVko05grJkUBjLATp0zd6d8ta8gqR0zOKi0U9cQcifvDTGt+YtbJQZnZSn+Yw7R/ mI3qT0xE8B+mQTrTOOWVNy23iE7EJx16uUemKNmTJ/4TUyzyD5PMB8psePfEXKL7wyzDe/KcifnD BIZSo4/LxUsFIYaDm6lieB6ZFk9Mcownz7RH5iqncdgw/GeX+Y2Z7VCaUVhpTBBHl4bgNcjViuJZ FL7ci3w39XVrzVyiekAhR37IRE0hxYsfFBgIFCnWYRTOv+xE4qhaGYLbEDvwVovVz0gS3kbKWL4/ FhaVtof08lcSM8dLLI3BjMPsSywxD+WRFfMdK6nSd31BfmPO6HCUzmwhbdnb4jDHieB2bg2gzOZw QPg4whh2SMKoeQav3Cj7kxNNw4oC5YrSDevhLHdY2Qk1fafML7Ck9Rk1WtuhAJLUWTemb8ghD5JU 9LRAIEq4ueSR9SvPPXJwj+JcWpjtbJzDGFuSRGC3/dhy/U19RaJtn0mTrGcqZ6Osayq07DIW5DZ8 xGhSadCXYpwYGR3fJx4I70yDPxep85EgNAynhN2ifSGx2wUcLQB4rOpCq8EaPFA+LbEyGKoH6wiI 49PiKmd1QH0pU6lRww+o39mHsbLWh8O1M1VVLLNjwzD0+Ul9Z9LUsScI9dYwe6d7RD1m94fR1frE uMrv6/Brkp1PoUTFvshXfdduQLutBA6EB4Kj+QH4+PMAmEVcXagcGYhjJp69gMv8qG180u48aVNT qFFRD6nVbJ+M65GrKKlsUfAetfNPWjvo0FDj+ifjUT5o21VKWY9a/X9obZ60NU/GY3+MdURSKBVD AqqVzCLGPgpEgEA3OpBfJe/rmlrKMczfn9OcIxP3xpfmsa0HoQzx9Fdzo/oJhDgy8kzkmFNHeFoI kOhsWKN4dgiojMNpLWEXZ3iDLi66gc5ml3I4pVq7RRAdoOH6OZ6vtda6GnnwC/cpGE8JM6YT9Ddh uuQB5jFdcpodLX6jx1k3acTPo9zPl6jZFzxsI3xJqO9ZB3MZBRjjJPC8koPdkmnl0R2i3pQEXcSa 8oioZyzR+q/Ye5RqxigoaLXNe5V+04asiRUdeF7MbYhsf5kystO+vOwdSZ5TeGj1dLu7gIyIPZxd 6DRhcuwUcEDc2zzdat3KE7HQkoaO1rKWjB5a7RgwEjVMgwAxPdZJCcbKC0NfO+6XCQxEEXmYGLOr kLBdlRwIv4N578MfirQuMW+k7wBxtHJECVz6aHoByHDax0tfX9KydeaiZWf2vUQKsbRyQnhRegXe 1n4hrRb3DHvdXBXBDYRnVxCVXF6xZCsqYZzHPu4NEiwvvwRVz5RiGNCd2YfzKdo7lBCmb4SXj4Zk ew1p5TQEkD+XKY42+8CNLjQfZ0a2/82p9krdwC45iPRkVyICoIofLPgFz1oV08uz/hAf1/YtTqIH cFuHwdqmvUsiRe9jsSj1u4Um8Y6F/Kue4qngSxZpRn3WnIeSWM5lN1D1UXTR9Unwl+bW/KMos5fP zSqF3ZrUhPUF7zzfLhwWL/FlHJEXHcztPohqN4Gm+pDk8PfY6w4as1l3J+kjgw9eSaWVlLwOx+un ZvxZIdue++xr9bXXtu370IZRd2296jhfak9xg+5gQhssqlYWQSV9R0hhwCvLpPDPFLunKfrOzOod OlYZnNJmk0IKYRIdzueuJM1mnKkHluRNOCW0Vjm1CkQV2OaNCnGY6OFmnh/dVVS/VqSSbm+b6slT jFWWR4kAAkUPbYjXITxpKI62lOXy3a/2uIkvIeJ8hmW0FTiwuFQRLn4HjfOFmUzv4LhFtMLpA7Fy 29ESXiO8NIAhGnRBNnuxlscTJ46WKBHUGzI2z3lZKR7bifSYFB3fEyjRo/BykE3grF1LCJWwaGQ7 TbutYgjFH/fTn13zeeKnXY9MwiFcKOTfbVX2B/rsBiUT0DB2Q8kdiU08Vj2EvmhQH0HTPz5DxE8+ i1ByOh58suAmO3qykDRlZ3X269hepPHjEsbRMy4/HhEWFB7fCEpoAOQwmUGVFYRK1E4JCEPUNNHQ HZ8n6glKeoKG6J464EuCjidE5IsGhZDNn1RMT5A60VPfP5AeAypZ53FYXeiwUMj2CaoeeIKMpKOh OTKG9hJoPYr7EoYICsUOPkEWT5DUS7/HiMlPxnpMH5GZQQNSkbnB1wWoSTS/7GWtBfNT+rOO1jRq 3VBEaqKCC+xbKV5HBVEyjlMHaZaora5YKap01UNc6883qKDvmom25Tiy9Ksr0PUw+AKzTrka5U22 goKFjUhqtqpQpmoRM5xIsmKCZFCIgVhiqxCDDldXpxoLV48gl8qKMsDoUApV9oPiypBl9Cwhnrms tWG2MAZ+1bRjn4HlYFS9Rju+5KEmJ8eqMvxblAaNds8QYTweR2XKTtMlq/VUykjb0Tgt8WhHOnOy sAn5rUV8qij4YBH6iAtNKjSuKKwcsBP0FvQJ/pk+sBP0O2tFSA8jP740EAsyQO9q16PJ4zT8kxjR Op3pw/gEdv8H+Hi3SE8fVUBtlMhUnL5/Opg+kf7VfiFPnGYLulSh0++oHB1kCfD9MyR0VfQJ/lkx f7nPGxD/+S7/eaSnHo0fR0tA+DOaMdfftvQ/If6zrX8R/R1RZnihu51mC0Eov0+Q9CG0r8Fqgprc OVJvl8FqUJ+PuDCoOSIbTb6vswTtlFRRYtdwvElCipkuePwhq+/DkYxjRhjPMIpVacxrscQKnySm Ssf3EzF4coSWbmjvhrjlqGQyP9SPr5VNpAZnWmDnypFaqvJyPMj/n/auKyiqbds2GSQpOSMZEUmS c5YgNlkEQaDJ0DRIajKSpREkSpYcBAUEyUGSoEjOTU6Sk0QJ8prrqYunn8dzT9X7eVV39MfeVbvn mGt3zd57jaq1xnxWfqd+xm08V8Hb3mpg7moSK18M48b2HGrVjVy8aBrRGfYs+ECh9ni5fKYa7PiU VVRqhq6A+UV8kTC83EwOrGvcYQcvj5Vr3HpnbR3OAzPeiylqIJDfqu+1HSBqZ8nOkwa+qOsIe1wn eOuBbq5MPAkLjzIBfpR632m59QphzGCJvP1A/zkVX5IXWP+e4IOVWe3x6mw0yxsK8vz4K/AGvQNg QVd6QEsuhBR0TqL49XiO+jiPPWBQr4wirGaj0/g8tnLozKZyesresp2O4zaMlePqW6I3W+B353WG PfqE0NOFxxFefqKy7js+b5j4zbT3H2osYb/cwwI22XkCj9CpLJ4/NKm5foLXp5yNtX2Wy6JCTtZC kUgby1I2TM6K+wpGjmMiAfG6neJpURxbY6On/3bOISjgzed+UoIazTFSV13oJ/J+6ucCOL5NprFG pgmoCS+aGw65nbWww8Ln8vyA2cKvMF+P0pBye09qMcxrNwrcvO/irJ67aeRSWw8SdJo+p5HqoyX2 Mt5KeP9AXd+aalOFX5Q1wihp/65GsnVSRVw/Hf4baPZBCgnlp7O0mJaVXoJD5YPQipXe+qWzibVh 3qGIJDhz+T55fYOl3JuPCrfizJaSBpe8uTtmkzCTTfRrcpssUrxHFqbUbofBhG/CsGtsZHtUykMB Cb2piVZrcUHmeswl3pwtVXcZkjEcWd93tAi+Ti42HOljILTiTfOifld6Yj3ckIEFjZ4yHTJZhn+s ZkA3AZTnRCTNsM4Ywwb6+PrbacEQnte0G8mRQycnn8zlsEUUmrckx70NpyXshNa6llJHyQTpZXmv HVOuei+C1l0NlPYaYnc1WilyAtQqwRmr3reASj3bDRvf0uBp1b6x7GDcrBrv9V7KxxCDfKINAuKh JW8Lzqn7E5UTkL4uhzKnyIX+6KGXwycE7v2bxsx6JOY4bMczhFk8HVkAgpW+rM7dVG7nRq5d9tdi gy0yugB1GN8xufB0pqQw8X7gxjXraYWsABGRqS7Qu2kfF/GnQzTcTjdtjY7JIkYyEvfnYSNbFj3D M6IjbnHWL3Fxcpunw2Lu7+TDJIaB6tNhH+iyFFBHbi0oR+VpRMkGQEWYR8azK0rbrUyW/SdONEI4 effGuVp42N9S+Ec6Tuo0wijhtcMOUW048rTEVXSoKhzmjBLD/bkHKV0vrTwmd0mDc0c+7Kx803FJ riw3Gz7WsfLAjxqksD/qkMPuGN4fnkw/0NsnkBnf9z+mcZwVCnklSo6Yp03ayHhPWbbN6mIJ5cQn 6xfuDg9jalWFoYg2Em5Qi82HoNX51t56LamScH+oMYgT7ajulchmPogkdCI23Mn+9jzGw9VMGYZx rpi4us21PRkqx0gcc7zmpf1u1zY2+Jj9GcoqSl86aBqNAxuO+A2x+I1se080sFCBz6PWeuFTGM2m igdPEldVPNdZuKHBZezyaSqETbgCQAX4Q6qQjvVEzsR399R3Nz+9Sm8vXHJoESxTOpthDdcZ8jOY xzIk0bLmep3oCG2WAVqs4GBJFDyuG0+a6yNtXiWebOurhHXlR5JCBxfbU7SF5u/aHH/VxI4In8v1 I5x4JZj2ci6nWIzDLKVIIk5hlHdoa504MnuDwgvHRXHZNdx5kDK6AnQGOrRo8XZxSWg8aAilshDH LQuZczThvp5XxdSSth8IKzEfEc3+fmNzNoLXMY1ZJLpBiWjPAQq4iQ55ZEzu1nytzqD9PdhNmYxF AZOcuLl6sreJlvbri3ZBrhsTKJRNOREKRugm8QTgMvGUq4xZzPVFB6FXv1HxJTScBkq23XEkLhpp XVGgK1pwYcsgjH4XCa3WL3YlPKjslblWPtqpZHjYqpWzZnR21YX6LSo4EG+sZRlW4rqLeufUZhTr i04l/gqYvuZB5HQ7i/rrxADTucw2hETsj0AnfxgEcmkvxQuY15X39iHGXPUwbPZ5PnEwLBiXL3Ab 59vQrvaoWnMyDwezqxjHWvJU96cZgewXbphMN5L1a0KK6kM1PVyrRLmka+xv7NPcEXu8Wbl0NzBP UbOdVoWe1t1V0AllrS/E3JSyXdnoJl90XI9c62cXOh8RMyCrvw5QVNVfJ1WEWMZgA/Hu52CbLDDO 3biHcRvsxlFjPU/QZNVh9ULC7YEeHvlG6RIXLmwlk/YgxVyGer1ay6TUsLw+rZaTswImOOL0QuGO STOetMFadWezf40V6CLIgRxcuMSJC9fpSb2Cu5kpsT9hjtBc5VkXQVWwgwGnFwjt1Wfv0f02vWtv ogAhs0joVQtU52gwxmYoz/jhyj2GCJWpcLKM4DSttSK/4LQj38i44JRFcMI2MvH3EJwPbqdv7P44 dv1xfP3H8dkuYrQnXxCjRSS2/SPx5x+JI9w3L6QdnLvnAVm5YZrYhTxMXrwYf61VofiP8ccibhox dPDXH0NXTivjtIoUd7uQnK4dP2i+Q3/Q0PYYXohTz3mRTv+KD055FzSgP2hgP2jUdn7QsPwYiFCr ExnmVojQ3dxOr2Hu6EJcnojX5PDo2HmmG1hX0tKb7Mb04caCN7BUYNZMbHSM3yeCyk9Kz3Phh6c0 +c3vDcN8bEXUcx665aKXDIVK0GQoj7Fpbo/VuMi9Ukx+kdkF3HJvzFOnDhr+ULui9JhGVABvMsu6 szMBBcNfjz8arVvKu2D4ZLGzsOtka5E3xklvI9p1hvztrLyjNqsJ1UJve0kgAC36C1qjsBQGB24Z c4h4aRW2yrIjloKWhwUWz/Gh2pPH60DAUhaYKNY8UvjwAH3RxEeQrYjWQ4WSLHP3GSiO2ZYjtsHO mKW4OOjEavwuFS/JBx+XnsqhjQYPo4379Lpu21IwexcH9Rz33Hmmj7ebYvokYhi+WfGMvZLSfZiG oypxzSfqS6L2xpFEjBXH4C6j0kt6DfZ0lVj2p10WPWYf1yLXE/0VKMlNUtB71d35PxMOA8BxVzqQ I/c1pZSmmHtzlPubuYbIkqPmTO7j2xhFiqGN5iyNaO6jaSPmKPcdc+TIyNmYtYiva77P6/knntfz +R8+P79f9TxcuuCU8S6FKww4jvrzvZib28fwzNi6TEQNycnrqWz+uOwJmYDbo02IyaEbuhULMtld LIDkWf07HBNEt8sbSxQwsT4rKknL3ma6wFWfu8zuHB/jI8DtLglvmCCrXx2xC3GcBP8Mp11xySSK Bf4lHC8HCDp9W1o2PViKIG0MZ9ZUDZcyyCEsyG36yPuRAy77TqdxxF1N66/d0PwrsN9pCmsunyKu KK2FIWMc8/ZOGtS7wVN1E80gT5QsXqtX+D2UFMUDiODpU3n369KIDbBLaP6fA9cr9jWczbCGMRfJ cq2NkplX41efXfUGGPdMCes/eXXusNDHwfMvoosGxgjUcQS5rJNGICbXBdh0Fe5Aj36fqd8V944x EbkUCXEkDNldZwBzpvNwZXTgjMMkxbKUvoS4ICFQqpl5IipVDx4hurx4ylUKdP6bu/OLF1cVJuRm 1qfzRJOCDsoiJSlmcuCXbaAkPoIklN/X7axjOp+HCXXeKLt1wvPeTU3YjkpBcM9NXNx3+oQp7Hir IESY0pDTwmXc4nsOGDBthdGmxrfMzX1AEgqupPHz3lJJJAfDHwUUbUwSOWnRm6ATnb6Ixx3+lFoJ DtAGZm1VN9xO7L1p3H4OLS7/lsr1rFEqTjiu0ovceJFn8DhdY/OCVelv7PZHCI8mCDyfsl+RyPvU O2DQIUmD6yNNapjFRvRMSk2E5ncE7Vgh4YSm88qv9e+Eedg32geefq+VSAJMdyBiY+ZNzV8/6ba/ e5EWWU0SMDDsKef6kHGSZ33dbVVKrmqTZFDOupqXBVsdbBD40o9Hxb9dbWQip6ctLigDCvpczYrH 3lVf6KuevyoA2xf6p4MhUFMirtmrcZ1imG5jAe3W2HRVM8hsrULOPx6+6L1+Hze3m56wqWqptz81 nKrk9/6Q6MrzNkTzijaqC8NaKu7b+UEPy7ML9OgBPM1iaRaTK08wwkc0Je1utgQEaZoMeyQCPjFQ cX629Zp1Qs4pujMnDteijxfrQ+rIOgkNR/3oYRXiWEviSVu20B9+vjf3FY1/0mSl840OxIDCiqxr ZLeVCMNoZeVj1t0tWGB6RNOBcaf4tcqqR9ZKotZduj/ggr4deyjKYUUagdD0XTcQ/yKW2v3U2kVQ tXjyLXPhLnBSCJ31jBexXjdFVIvTPtPyGkZX65m3M2p/BrNpdo9UsJI4v9brGVNr6Dt2XBs+HHy+ hU2N/lWv52bzNZHZhg0mh7xA6VopvzLhl21GK+VhMCD5gAGBw+X80UU+05VCDo4+X4kodNp9Xs6y G891dUMSFDCDx2tcqV/esmlD/U9HpNtC5DMK/MgCyo8BHv6fqmzSFSK5cOhT8koNDz5U97Vv+GsP ktSa/3yG73irhUe5/2hyti37av8BOqvMi/o71yhG0J2CHzLw5z740GsNa1df2Q5Ffd9c+Tu7omhT 7yAfzUW88CzTgUsDNWpZ6M1Jv8cS4Y9nN/30+8lSQjs7Nm2qTBmOG74UH61kKkBEmGNV7anjw67Y ec46dfS9uOxtykM6mxQ+igVqXxK16x0K6kVYK9al3SFALQVLJ8taIA6yShR5urWUSmDjjCsnedYj FTt1D8L4iY4Z83nwYFf97O3J6jc95R20j16QlsO+W0nvG2vlhEwUxNf9dD6NpUVU09c7+svqV6Is LX63FElXjwv38El4+KjVmpQSgX4vv5XW0XKaS3ZyGhIiDyeoUT0OUxJLTRArAeiLT92tA1KL0GuR Mg4utW80gt93i5xP2c+qvZGwqNL0G+dZFT5JDaHNVEFDV6YqlhEHjq2oV4rzVK3YhDTVBtjsI4xX kiK8pqxeJNTNwaXcy07463mQD6fz6sj6QZlY2CDou9baDNzlB5vd35xbftbrqkkScHSNo20cXzHT 8XmhtROVLMpQOgiRpyC/wJTR0uToz66ipYKiP6yzrRFczxv5F522z4BD1K33bF8euBoF8NK7moCw dLuu7I2mRcVg75jtz4F8er1j9tvvuo3ELi+IpFArMduHWvNExyz+Ar3Rap1LKO8unw7uLVhSEVTE Eiwqw/T3e3VWZLlXJqccO2M316Ynldo/EnFHeqCtWJ4jKw3Em+bh/E/ukGcvP23J0tB/gH+U68Ap wpwAS09+0Vam7EXO5w4KNKAur7trD46G3GHjaoeYc5rzotc6PR9VimdJpexdFFy6Ieehc9q58DbN e/mdE5PPmLbKbhQfGDXBffjMg3xeIugMAersbmrlrnaqpG3hbBSl/UrEVsUf3nA6dE1BN5pFFtge afaxZY4KxooOsCwtcoBQvReGrxWw8C5Q7eN/xswb+xV7RNpjSOIH+sRUkI2atLU3JSgV0XmMj21l 8yQfM6xyZSL26mw7ZT+EGByvptmhu2JnJgFn0y2jBPJGBiFvzYz9P7PZGFulUuSCiXkwQXbAoD0k tKZmnETOjJ63qc6hjvrigPIZAYZR9QZ/oMU665TQNjJWNSacKMjcDfI+BcSXg9tsBYaXqzfJYKAh pLjxcoY4Z0z4fn9Eouv7dtGXScb1FgfO7bt4+e3rNkNCv+KOBbKvoEEfH60Unpr+AjmPAMeUzPoW +hd4Krxq860d88bfgz3JxQ26YmVjI0uxfaca8Rsr1y/NKhIHLW/r/PIce8bZneEM55Jh1qFHSOgS 6/IMymUmvlV94mfYKd7Mj+cWzPBjcNBNT6NUpOM+G6C88SNgCVIk0cuLENwRccI1qQV2hpJQOWEw h1t7+9rABXOf4KDlkmjZ3cazkh82Hw/M6VEf69V/w+3/6k/ebIArIUrcTKALYonOO7javI7Qd0CX Bmmk+0m3PiuHAp0dc5ypNLIfAup83iuptDJ4mMSLqp4Ve13EA52vvgV3/mtqn/tb1o4v2HRLeWtG h5rVb6/3HWdfYQm/d18LYAWWU5d1PUxORJBfi84FjF+/29sAqlY2FuxtDi9ayz8NGl0xS/ytfw1D aoImETvFUt8Qcm6/wdR2RiQGT7qbJyNkk+EVMDFwWLa661T/rTUGZ12vzLUUUZonkjWws/NL5TT2 7fJM62XCldJ6jmwS8kH5izkp2HPzHAkSmp8bnNRc96l5S/FR1Mmwy+0pfWZK/4S1b+NZ0jD2DZKt xVnTQGFUssGAu1aq+UuLTcmw0+J02jbGiGAU2dpqCll0/3tB0UHhIN3dOGE5aLY3vQzLaFLl9D4a HqCkS6Vb16iycAzmtdr0KexgsepCP1vmoR9CGgEoh7Y9i1u0TLRK2DgZclosl9ZgokBVCOps5skd DdJeuUBVYKY2mu420zZeGROM3DJjk03zW+8UvbR6Wqmj+pS+v0s/lyvgUngvfoghgRQAHw4TV308 TDifHF+Kx7Yf69ccSrnrx545fpCVLHu06swa/sZig/da3Qfo5ZI5EtnJwvj1JAtjImAezy3AwZPD FcDRxxH95ATHb8xispBtxhb+v2qw2nEIobXrxuBxXNrx8N7xSYYUw/N/LOj+X/cvTDjuew== --_008_BYAPR08MB4903CED7FFDB7D11EFDB49FAFAD50BYAPR08MB4903namp_-- From nobody Tue Aug 6 16:20:08 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F44120099; Tue, 6 Aug 2019 16:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=opcfoundation.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 MjkJVHf4TCHa; Tue, 6 Aug 2019 16:20:02 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820057.outbound.protection.outlook.com [40.107.82.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 12D4C1203E1; Tue, 6 Aug 2019 16:20:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Nhcn3r0B5x1bpL0lLQDma6x71Gbac9VUCSGafQckUkclo8vC/fhYJBFIMN7DJWmdQn/X1yoBl2C7zWURqb1iZXkHH2CCA8jcBPYak87HmI70+mcpf+2onXTXTbUpYHjjcnXOxlTjGkhfNMjToqKTRNeAJqlNOfeAN2ZD3Q596Xo7M0qefu71ltayjnR/IXTJxQoYY7PjxLxvebmw/EzPtDOb8hdPxex6BqVDyk3HGK4pipl5gv/PJe7d9kRbSxPlf4gHALFYyv1xoHHZbu4AYUf8OvGBZGSeJl+kW/r8tlsrRElveL/vviDt3mG+BX5pyU7upxIrf8/t4+lXQ3eVrw== 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=DEMiJ6h/2Yvuuu14/cgtKgdv3XLtHMRvNOOnrscznBM=; b=bXfASHQOavg+UfsH5X5snayS3BMNAS95mmxMiIxku31v05jRr0pNBHzv8x5Kv/J1dhkb5fazoSngQvW4YRSrYqumenGjNTKnQxS2uummyBhWwQAlWNA0uWKROrydR3z1HG3bmWWeUbN+d4wLTJg1jodX4ZfxdMMOyTzRg2EgoNOisc7yEjsjhLVNbV23k0HE6z8bT11wRxDq5V7hBH/sVyis5YcyyyHchKGbTWVg/UH5VBUOGgSanAV+dGJpGtY0+I7D1fW/JwNCZEFrR9XzOoSgDkLt7lH1Y/wO4aVlIZjol754DjFjSwmdls2uZ12lcYN538wLEGtgFWzcR89DxA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=opcfoundation.org; dmarc=pass action=none header.from=opcfoundation.org; dkim=pass header.d=opcfoundation.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opcfoundation.onmicrosoft.com; s=selector1-opcfoundation-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DEMiJ6h/2Yvuuu14/cgtKgdv3XLtHMRvNOOnrscznBM=; b=rUPvaoIMwVwthZGn6eY9Vb0iEI6/WyTYzgOcTMXScDbC5GTDB9AT1qimPCarmsl2VB3bFwfHpISE4Gb5coN9A306atAO9VgoLQQG71tYhfPtlaS6Kqc91LV3PX7p2TqZC26X9X1OgLWqE/EQp2EOVU9xIid//Yx4PYfg80Cfpks= Received: from BYAPR08MB4903.namprd08.prod.outlook.com (20.176.255.96) by BYAPR08MB3959.namprd08.prod.outlook.com (52.135.194.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.14; Tue, 6 Aug 2019 23:19:59 +0000 Received: from BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53]) by BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53%4]) with mapi id 15.20.2094.017; Tue, 6 Aug 2019 23:19:59 +0000 From: "Randy Armstrong (OPC)" To: "Randy Armstrong (OPC)" , Toerless Eckert CC: "iot-onboarding@ietf.org" , "anima@ietf.org" , Eliot Lear Thread-Topic: [Iot-onboarding] OPC and BRSKI Thread-Index: AdVMZzs5EDHMP+c/QWCVcWuK34MU/QAGrJ8AAADfarAABKcngAAAO+sQAANovwAAARHHUAAAmp+Q Date: Tue, 6 Aug 2019 23:19:59 +0000 Message-ID: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <20190806223052.md5lp6yeleuvuf5l@faui48f.informatik.uni-erlangen.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=randy.armstrong@opcfoundation.org; x-originating-ip: [24.80.80.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bec28443-536c-4e21-8425-08d71ac49a11 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:BYAPR08MB3959; x-ms-traffictypediagnostic: BYAPR08MB3959: x-ms-exchange-purlcount: 3 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39840400004)(346002)(396003)(136003)(376002)(199004)(189003)(13464003)(66946007)(316002)(8936002)(606006)(2940100002)(74316002)(14454004)(25786009)(6506007)(71200400001)(790700001)(68736007)(3846002)(86362001)(53546011)(76176011)(2906002)(71190400001)(7736002)(4326008)(99286004)(66576008)(8676002)(6116002)(81156014)(7696005)(81166006)(733005)(110136005)(54906003)(5660300002)(6436002)(64756008)(66446008)(66476007)(66556008)(256004)(76116006)(478600001)(966005)(99936001)(54896002)(52536014)(66574012)(476003)(486006)(6306002)(186003)(53936002)(54556002)(26005)(102836004)(55016002)(446003)(33656002)(236005)(6246003)(14444005)(66066001)(11346002)(9686003)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR08MB3959; H:BYAPR08MB4903.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: opcfoundation.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: RHxP9DdV0XEq4orVZ8Xq834pGBMi1EUDy1EOF1rCzVfUxgugPx/C5Tl/S9n9ZaR/cmKHbqghBV9wQ+ohUx3zSP8znKfRxtqx9AuTR/BF5SYwomIu9BIvA9CwPpShajjG3yUmkkzDd60WFE9Ej9pY3vguRPbQDHYSlE/VjaciN8Xix24G2EDhA0OBUxgn7xkwkAkh7Z06XlC9MWe+JnwBT4Sg32XgKe2AaqmNle+FGEORovN1x/7LAHmecDPU/K+B9Xhh0pERQ6O9yaFmWWxQL4sgi6Ae2UjctgXdQFZa4I+pR+obisSv4JiB61XUPq8kUTovCrMtFw0KLX7SNw+EvWtIDXAl2/A+jAYQBN2Bywg9FGKp0boL2kTc6ndtmcJCraZUtN1aN1Gf1NSLWxMmzjf45FXtPgWgs/J70p1iJZw= Content-Type: multipart/related; boundary="_005_BYAPR08MB4903E91A2E9FC117755443C1FAD50BYAPR08MB4903namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: opcfoundation.org X-MS-Exchange-CrossTenant-Network-Message-Id: bec28443-536c-4e21-8425-08d71ac49a11 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2019 23:19:59.5816 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2d8ef4e4-d41c-489c-8004-bb99304b60fe X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: randy.armstrong@opcfoundation.org X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB3959 Archived-At: Subject: Re: [Anima] [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2019 23:20:06 -0000 --_005_BYAPR08MB4903E91A2E9FC117755443C1FAD50BYAPR08MB4903namp_ Content-Type: multipart/alternative; boundary="_000_BYAPR08MB4903E91A2E9FC117755443C1FAD50BYAPR08MB4903namp_" --_000_BYAPR08MB4903E91A2E9FC117755443C1FAD50BYAPR08MB4903namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Push should be "Certificate Manager initiated" From: Iot-onboarding On Behalf Of Randy A= rmstrong (OPC) Sent: August 6, 2019 4:17 PM To: Toerless Eckert Cc: iot-onboarding@ietf.org; anima@ietf.org; Eliot Lear Subject: Re: [Iot-onboarding] OPC and BRSKI Hi 1) Sure, need to understand how TCP UA works wih the minimum amount of mess= age authentication to allow for BRSKI. Main challenge may be the need for p= ledges to receive messages from registrar that are authenticated by the reg= istar, but where the pledge has to wait until it can actually perform the a= uthentication later. Depending on how you built TCP UA message layer authen= tication this may be piece of cake / free or not. It would be easy to drop in a OPC UA aware registrar and implement all of t= he BRKSI flows back to the MASA. The only nuisance factor is the 'prior-sig= ned-voucher-request'.. If MASA's are willing allow this field to be omitted= and to trust the Registrar then nothing more needs to done. If MASA's need= this field then we could get it from the Device via OPC UA but producing t= he CMS message adds an additional burden on low end devices (i.e. the need = to pull in libraries that provide the same functionality as OPC UA but do i= t in different format). The 2 modes of operation with a OPC UA aware registrar (the Certificate Man= ager is an OPC UA defined entity). Pull (device initiated) [cid:image005.png@01D54C72.CA661C90] Push (Registrar initiated) [cid:image006.png@01D54C72.CA661C90] Regards, Randy -----Original Message----- From: Toerless Eckert > Sent: August 6, 2019 3:31 PM To: Randy Armstrong (OPC) > Cc: Eliot Lear >; iot-onboarding@ietf= .org; anima@ietf.org Subject: Re: [Iot-onboarding] OPC and BRSKI On Tue, Aug 06, 2019 at 09:32:45PM +0000, Randy Armstrong (OPC) wrote: > OPC is layered to separate the application from the choice of network pro= tocol. TLS/WebSockets is an option but the primary protocol that will be us= ed by low end devices is UA TCP which provides complete message based secur= ity framework. These devices do not need TLS to have security and requirin= g it would require duplication of code. Sure, need to understand how TCP UA works wih the minimum amount of message= authentication to allow for BRSKI. Main challenge may be the need for pled= ges to receive messages from registrar that are authenticated by the regist= ar, but where the pledge has to wait until it can actually perform the auth= entication later. Depending on how you built TCP UA message layer authentic= ation this may be piece of cake / free or not. > 2) At some point, the thing decides which part gets an IP address or at l= east is responsible for the phy. Can that process be leveraged to establis= h identity? > > Machines may have a separate network for internal Devices which IPs assig= ned by the machine???s DHCP service. Some of these devices may interact wit= h external equipment via a NAT router which assigns a unique port to each d= evice. This means the individual Devices need to be granted access to the o= perators network when the machine is installed even though the operator can= not provide them with IPs. > > I need to consult with our machine experts to better explain this use cas= e. Primary questions seem to be whether this is just about authentication at t= he TCP UA layer or further below at some implied NAC mechanism. > 3) One possible view here is that the MASA may be offline, and may have p= rovided a voucher via offline means to the join registrar. This of course = would be nonceless with a lengthy expiry time. In addition, I posited duri= ng BRSKI???s review that perhaps the device should be able to generate its = own certificate via a higher level interface. > > OPC already has APIs needed to manage Certificates on a Device. The link = to something like the MASA is what we are missing. Nonceless vouchers that = do not expire should allow local registrar to emulate a MASA when the MASA = is no longer available. I wanted to make sure that this mode of operation i= s allowed BRSKI. Yes it is, it may just not be fully specified in the current targeted BRSKI= RFC that we feel everybody who wants to implement it has everything to do = so, but thats would just be subjet to future small RFC to close any possibl= e gaps. > 4) Can you say more about what mechanisms OPC is interested in pursuing? > > With OPC we assume that network selection and IP assignment are out of sc= ope. Wired devices are the primary market at this time but 5G could change = that. BRSKI also does not care about Addressing. Only ACP does, so you can ignore= that part if you're not interested in. We have tried to separate out ACP s= pecific aspects in the BRSKI document as good as possible with the somewhat= convoluted process we had in the IETF how to drive those documents. Cheers Toerless > Regards, > > Randy > > From: Eliot Lear > > Sent: August 6, 2019 1:47 PM > To: Randy Armstrong (OPC) > > Cc: iot-onboarding@ietf.org > Subject: Re: [Iot-onboarding] OPC and BRSKI > > Hi Randy, > > Thanks for this. It???s a great starting point. I would propose that we= do a call so we can get some high bandwidth discussion going. Please now = see below. > > > On 6 Aug 2019, at 20:58, Randy Armstrong (OPC) >> wrote: > > I will start with the main trouble spots. Some of these may be already co= vered by BRKSI but I missed the implications of some of the text: > > 1) Low end devices that only support OPC; this means no TLS client > capabilities and no ability to initiate network communication (i.e. > server only mode); > > > How does OPC handle such devices? I think this is also coming up elsewhe= re. One question is whether TLS is required. Without TLS one does lose co= nfidentiality, but so long as the client can sign the request, maybe that??= ?s all you use. > > > > 2) Machine builders that combine devices into a machine that is sold as a= unit. These device still have a unique network identity but the effective = manufacturer has changed; How to deal with the DeviceID? > > > At some point, the thing decides which part gets an IP address or at leas= t is responsible for the phy. Can that process be leveraged to establish i= dentity? > > > > > 3) Devices may be reset to factory defaults and sold/transferred to anoth= er organization. This needs to be possible even if the MASA is no longer av= ailable (i.e. the original manufacturer has gone out of business). > > One possible view here is that the MASA may be offline, and may have prov= ided a voucher via offline means to the join registrar. This of course wou= ld be nonceless with a lengthy expiry time. In addition, I posited during = BRSKI???s review that perhaps the device should be able to generate its own= certificate via a higher level interface. > > > > 4) Offline operation is the norm with pre-issued vouchers delivered out o= f band. The pre-issued vouchers will need to have reasonably long lifetime = (i.e. years not hours). > > The lifecycle of a device is shown in the following diagram. The > expectation is we would need to add links to the MASA at each step in > the lifetime > > > Thank you for that. For wired it seems to me that a permissive MASA mode= l (logging only) could provide you a way forward. For wireless, this is no= t an option because proper network selection needs to occur. Another quest= ion is whether we need another mechanism is necessary to validate the vouch= er (aka, a PSK w/ proof of knowledge, or DPP, etc). > > Can you say more about what mechanisms OPC is interested in pursuing? > > Eliot > > -- > Iot-onboarding mailing list > Iot-onboarding@ietf.org > https://www.ietf.org/mailman/listinfo/iot-onboarding -- --- tte@cs.fau.de --_000_BYAPR08MB4903E91A2E9FC117755443C1FAD50BYAPR08MB4903namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Push should be “Certificate Manager initiated&= #8221;

 

From: Iot-onboarding <iot-onboarding-bounces@ietf.org> On Behalf Of Randy Armstrong (OPC)
Sent: August 6, 2019 4:17 PM
To: Toerless Eckert <tte@cs.fau.de>
Cc: iot-onboarding@ietf.org; anima@ietf.org; Eliot Lear <lear@cis= co.com>
Subject: Re: [Iot-onboarding] OPC and BRSKI

 

Hi

 

1) Sure, need to understand how TCP UA works wih = the minimum amount of message authentication to allow for BRSKI. Main chall= enge may be the need for pledges to receive messages from registrar that ar= e authenticated by the registar, but where the pledge has to wait until it can actually perform the authenticat= ion later. Depending on how you built TCP UA message layer authentication t= his may be piece of cake / free or not.

 

It would be easy to = drop in a OPC UA aware registrar and implement all of the BRKSI flows back = to the MASA. The only nuisance factor is the 'prior-signed-voucher-request'= .. If MASA's are willing allow this field to be omitted and to trust the Registrar then nothing more needs to = done. If MASA's need this field then we could get it from the Device via OP= C UA but producing the CMS message adds an additional burden on low end dev= ices (i.e. the need to pull in libraries that provide the same functionality as OPC UA but do it in different forma= t).

 

The 2 modes of operation with a OPC UA aware regi= strar (the Certificate Manager is an OPC UA defined entity).

 

Pull (device initiated)

 

 

Push (Registrar initiated)

 

 

Regards,

 

Randy

 

-----Original Message----- From: Toerless Eckert <tte@cs.fau.de>
Sent: August 6, 2019 3:31 PM
To: Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org>
Cc: Eliot Lear <lear@cisco.com>= ; iot-onboarding@ietf.org; anima@ietf.o= rg
Subject: Re: [Iot-onboarding] OPC and BRSKI

 

On Tue, Aug 06, 2019 at 09:32:45PM +0000, Ran= dy Armstrong (OPC) wrote:

> OPC is layered to separate the application f= rom the choice of network protocol. TLS/WebSockets is an option but the pri= mary protocol that will be used by low end devices is UA TCP which provides= complete message based security framework.  These devices do not need TLS to have security and requiring it would requ= ire duplication of code.

 

Sure, need to understand how TCP UA works wih the= minimum amount of message authentication to allow for BRSKI. Main challeng= e may be the need for pledges to receive messages from registrar that are a= uthenticated by the registar, but where the pledge has to wait until it can actually perform the authenticat= ion later. Depending on how you built TCP UA message layer authentication t= his may be piece of cake / free or not.

 

> 2) At some point, the thing decides which pa= rt gets an IP address or at least is responsible for the phy.  Can tha= t process be leveraged to establish identity?

>

> Machines may have a separate network for int= ernal Devices which IPs assigned by the machine???s DHCP service. Some of t= hese devices may interact with external equipment via a NAT router which as= signs a unique port to each device. This means the individual Devices need to be granted access to the operators ne= twork when the machine is installed even though the operator cannot provide= them with IPs.

>

> I need to consult with our machine experts t= o better explain this use case.

 

Primary questions seem to be whether this is just= about authentication at the TCP UA layer or further below at some implied = NAC mechanism.

 

> 3) One possible view here is that the MASA m= ay be offline, and may have provided a voucher via offline means to the joi= n registrar.  This of course would be nonceless with a lengthy expiry = time.  In addition, I posited during BRSKI???s review that perhaps the device should be able to generate its own certific= ate via a higher level interface.

>

> OPC already has APIs needed to manage Certif= icates on a Device. The link to something like the MASA is what we are miss= ing. Nonceless vouchers that do not expire should allow local registrar to = emulate a MASA when the MASA is no longer available. I wanted to make sure that this mode of operation is allowed BR= SKI.

 

Yes it is, it may just not be fully specified in = the current targeted BRSKI RFC that we feel everybody who wants to implemen= t it has everything to do so, but thats would just be subjet to future smal= l RFC to close any possible gaps.

 

> 4) Can you say more about what mechanisms OP= C is interested in pursuing?

>

> With OPC we assume that network selection an= d IP assignment are out of scope. Wired devices are the primary market at t= his time but 5G could change that.

 

BRSKI also does not care about Addressing. Only A= CP does, so you can ignore that part if you're not interested in. We have t= ried to separate out ACP specific aspects in the BRSKI document as good as = possible with the somewhat convoluted process we had in the IETF how to drive those documents.

 

Cheers

    Toerless

 

> Regards,

>

> Randy

>

> From: Eliot Lear <lear@cisco= ..com>

> Sent: August 6, 2019 1:47 PM

> To: Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org>

> Cc: iot-onboarding@iet= f.org

> Subject: Re: [Iot-onboarding] OPC and BRSKI<= o:p>

>

> Hi Randy,

>

> Thanks for this.  It???s a great starti= ng point.  I would propose that we do a call so we can get some high b= andwidth discussion going.  Please now see below.

>

>

> On 6 Aug 2019, at 20:58, Randy Armstrong (OP= C) <randy.armstrong@opcfoundation.org<mailto:randy.armstrong@opcfound= ation.org>> wrote:

>

> I will start with the main trouble spots. So= me of these may be already covered by BRKSI but I missed the implications o= f some of the text:

>

> 1) Low end devices that only support OPC; th= is means no TLS client

> capabilities and no ability to initiate netw= ork communication (i.e.

> server only mode);

>

>

> How does OPC handle such devices?  I th= ink this is also coming up elsewhere.  One question is whether TLS is = required.  Without TLS one does lose confidentiality, but so long as t= he client can sign the request, maybe that???s all you use.

>

>

>

> 2) Machine builders that combine devices int= o a machine that is sold as a unit. These device still have a unique networ= k identity but the effective manufacturer has changed; How to deal with the= DeviceID?

>

>

> At some point, the thing decides which part = gets an IP address or at least is responsible for the phy.  Can that p= rocess be leveraged to establish identity?

>

>

>

>

> 3) Devices may be reset to factory defaults = and sold/transferred to another organization. This needs to be possible eve= n if the MASA is no longer available (i.e. the original manufacturer has go= ne out of business).

>

> One possible view here is that the MASA may = be offline, and may have provided a voucher via offline means to the join r= egistrar.  This of course would be nonceless with a lengthy expiry tim= e.  In addition, I posited during BRSKI???s review that perhaps the device should be able to generate its own certific= ate via a higher level interface.

>

>

>

> 4) Offline operation is the norm with pre-is= sued vouchers delivered out of band. The pre-issued vouchers will need to h= ave reasonably long lifetime (i.e. years not hours).

>

> The lifecycle of a device is shown in the fo= llowing diagram. The

> expectation is we would need to add links to= the MASA at each step in

> the lifetime

>

>

> Thank you for that.  For wired it seems= to me that a permissive MASA model (logging only) could provide you a way = forward.  For wireless, this is not an option because proper network s= election needs to occur.  Another question is whether we need another mechanism is necessary to validate the voucher (aka, a PSK= w/ proof of knowledge, or DPP, etc).

>

> Can you say more about what mechanisms OPC i= s interested in pursuing?

>

> Eliot

>

 

> --

> Iot-onboarding mailing list

> <= span style=3D"color:windowtext;text-decoration:none">Iot-onboarding@ietf.or= g

> https://www.ietf.org/= mailman/listinfo/iot-onboarding

 

 

--

---

tte@cs.fau.de

--_000_BYAPR08MB4903E91A2E9FC117755443C1FAD50BYAPR08MB4903namp_-- --_005_BYAPR08MB4903E91A2E9FC117755443C1FAD50BYAPR08MB4903namp_ Content-Type: image/png; name="image005.png" Content-Description: image005.png Content-Disposition: inline; filename="image005.png"; size=11790; creation-date="Tue, 06 Aug 2019 23:19:59 GMT"; modification-date="Tue, 06 Aug 2019 23:19:59 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAk8AAAEvCAYAAABc2yWpAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAC2OSURBVHja 7Z1/iCTXndgbI6H9Y22P15J2EXvWJFozwpbkXu2PEcXaaXzDZG0GIx8sI7Te80LuXkwww3AjMwqJ b0eQrPqPhS0OJmaDYRRHuTMJ7Ib8UWuO4+YODs5wHPPPBRs6eHKBWIa7sNHJ0loxdqW+1V1Vr169 6h/TP+pHfwo+0k71q9dV1a+/9enve6+q8cYbbzQAAAAAYDg4CQAAAADIEwAAAADyBAAAAIA8AQAA ACBPAAAAAMgTAAAAAHASAAAAAJAnAAAAAOQJAAAAoDrytLGx8ez169db/bh69epqsGxCl7W1td8Z dM6E7e3tBRqjnXa7fWyYcyjnmjaXEHwX1wadM/lO08bemHQMXKP9jR4D5XtOGyMmVikmDlUouLif On78+MPl5eUH/Th//vyHL774on/u3Llfw7lfN5vNX1+8ePEf+p2zz3zmM+997nOf+1OCgp3Pf/7z //6ZZ555v985lHMs55o21yX4Dsr/fzno+yrfaflu084mFwPlvPfOPwwZA+X7Ld9z2hkxsUoxcagP a2tra/Gpp556z2eZ+LK/v+8vLS0dEBTsBEHgv+zt7dFQprDId1q+27QzYmCRi3y/5XtOOyMmVikm EjgKXpAnAkUVAgXyRAyc1oI8EROrGBMJHAUvyBOBogqBAnkiBk5rQZ6IiVWMiQSOghfkiUBRhUCB PBEDp7UgT8TEKsZEAkfBC/JEoKhCoECeiIHTWpAnYmIVY2I5A0fH9Z1Gw2/EOL7yOmPXp7zyfVjI E4GiCoECeZp0DOz4rnKSGOco3z1CiOt4rq9cLxPjOq4Tx07XGy/+xe8xpQV5IiZWMSaWWp7SgcA5 UnAp+4I8ESiqECiQp0nGwECcHBEm1+/448S4Xj0ZK8pbP8a+KuSJmEhMrJw8+b7nq+BvR48sntKy U5KZ8oyApG2TkbFkWydY2bHWNxtTQ54IFFUIFMjTBGNgEGsGipI1HvVimlJGZj5ByoVxMM5oBfFw mPgXvmWSCXOUxFFLXVOIk8gTMbGKMbEi8mT8+olf735xO1EwcrWgpAcovT7L+igYZeqbgT8hTwSK KgQK5GlyMXBglikvvnW68pT8QNTiYipm5sXLnPgnf8j6qN5U/LO9x2TjJPJETKxiTKykPCX9+eav riTb5CktyGj1dbdVvpcJZrb6pn+oyBOBogqBAnmanTwNim9JF9ro8mSLf/H7ytgm5cSZJbOuacVJ 5ImYWMWYWMluu37BpytNyleO1s03lDwVM6YKeSJQVCFQIE+T7rbLl478eGQOX5icPEXvKVmlTmr/ THmafJxEnoiJVYyJlZCnTHo47m7TM1G9gND74tvKJ2nrqO70GAJrfVNekCcCRRUCBfI0wwHjufFt fHmyxr8oU9+LeVGGKVNXv7g7xoI8EROrGBNLLU/9blVgDlxMfg1ZZof0HTDZDWD59U13QZ4KCBSZ 9pVcEMapb1AV057yPc1AgTzN4FYFWoyzx6PsxBmzK22gPOXEP/07Ef+YTGX6u7LnTSFOIk8VkCe9 fegfurY+6U3urdN+HOjtPjUxwWxAfbdFnli0BXkqTp7iL/uAbpSJXSynPOV7moECeSIGTmtBnqol T9mMaVqeUvcYMw1I60WydQP33bZkMZHAUfCCPJVAnvRZR9qX3DYlO/nV7oSDa8Og4eb/su/e/NAy 5Tsz7VzF9aUyApZyk9Iv5Al5KsOCPFVHnpTKzsTsrkt3BTeCdcqWWeo7Q3PAtjNYkKcKLchTCTNP fW+FEa2PxokY8mSIWDLr08w8GdPOc6eKm9PTiwkUyBMxcFoL8lQhefLM+yfqcTEdS/VxdMnSi2fB dvo9xsw4bN92+gvyVKEFeSrDmCcnEKD8cSRxNsgxBshGX/ZU5ikKDlGAcH3PvF+OHkS0bjz7VPFs uSICBfJEDJzWgjxVSZ6SyQ6exMnejVNT0pP6EWgbDtEd9+QY3XPDbTvdBXmq0II8FZx5snTZ5U3J zswusspTNziEIuTo/fd2eTJvv5GdKu5NLYWNPCFPZViQpyrJU/rHZXyDVf0+ZCa5BqTHtlG3nc5S UXmSk2d0VaRmQ2VveDl81WNYbJSanFL3K/JUfLddRpbypmR7o3fbdeK73veXp/yp4shT7eVplJlM yBMxsWB5Stql/jSPKDOfvlaa3W/x38Yd7m0/WIvouqukPKVSduYFQ78gzVqepjxLCnkqwZgnaxea fUq2PhskHijpZu9L5li6BPUp352cNp6dKo48zZM8DZrJhDxB4fIUP/PQvLeiZWxmJFZx/PLCG1hb n6E4cFvkyWY3xgXC/nf2ZnD+aLOivPz1/eua3k0zkacSBorcZqqMKbmqsCm1sw4UyNP05WnQTCbP NhtTez5ndFGKMqbW8v5RYuD0ZnwiTxWPiTVbqidPAx7Hkpt5GjArqru91r2icrpd+tXV8ac6eA15 qlag0C9I5kBz5Al5Gi/+9ZnJpHJmY0ZZq97Mpbj7w80p7x0lBk5vxifyhDwhT+NdkYxf8LYxT17O Q36HnxWVO1vKG/Bw4KN0FSJPBIoaBQrkaRby1H8mk3U2pjnhQb8JoaV87qQHb5QHEk92QZ6IiVWM iaWWJ2tfZ0aehp8VNViecrpgkCcCxZwHCuRpFvKUP5MpGoybmY2ZI0/d7rhs+cHyNMwDiSe7IE/E xCrGxGp02+WVzZsVlQooo3Xb5T9seDpjW5AnAkUVAgXyNBt5ypvJ1GjkzMbMkSfHySnvHSUGIk/E RGJiOeVp4IDxnEDj95sVlTdg3DJbamBdDBgnUMx3oECeZiRPOTOZohmdmdmYed123hAP+h06BiJP xERiYknlqfeFnvaTlI80W4pbFRAoCBTIU01uklnCGaPIEzGxijGxRIFDv0nmNGPHiLOluEkmgYJA gTzV6A7jZZsxijwRE6sYE+cucJRtQZ4IFFUIFMgTMXBaC/JETKxiTCRwFLwgTwSKKgQK5IkYOK0F eSImVjEmEjgKXpAnAkUVAgXyRAyc1oI8EROrGBMJHAUvyBOBogqBAnkiBk5rQZ6IiVWMiUMHjk9+ 8pMfyIUeJsvt27eRpwGB4vXXX6etTAH5TiNPbxADC0a+38gTMbFqMXGoD6vdbh974YUX/kQu8v1Y XFz825MnT35QNMEJ+OWTTz75YdH7cerUqZ9/+tOf/ptB521tbe1fEhTsXLly5dqg8yfnWM510Z/3 E0888YsTJ078qgzfgU996lM/HXTe5Dst323a2eRioJz3Mnz+0g6lPVYlBsr3nHZGTKxSTKxl42o2 m3tf/epXr/NFg1ly/fr1VvADYp9zAUUj7VDaI+cCiInTAXkCIFAA8gRATESekCcgUADyxLkAYiLy hDwBgQIAeQJiIvKEPAGBAgB5AmIi8oQ8AYECAHkCYiLyVB2uXLnyysbGxrM0Xpgl29vbp9bW1r7B uYCikXYo7ZFzAcRE5AkAAAAAeQIAAABAngAAAACQp+qwvb29wIcLtD2gHQLQFpGnITl//vx3ZNA4 DRdmiVLqpTNnztznXEDRSDuU9si5AGIi8jQ03KoAioBbFUBZ4FYFQExEnpAnIFAAIE9ATESekCcg UAAgT0BMRJ6QJyBQIE+APAEgT8hT0dy6dWtxb2+vVUfk2AgUAMgTIE/IE/I0Ufb393f8mi5ybAQK AOQJkCfkqWDW19df3traqk1GA3maHQsLC4dHFW95jhO3yIAyIO2QZ9tB0cg9nuo6hIYPGHlCnvQv RKPhC+NIFAAA1BtOQq3kyfNV7+LfxfHdTrLe6f4RLB3fdaLX5N+98o7rd/rVl3m9z9JxfWeI8mWV JyQKAACQp3mRJ11YPBUIgArWynrHd8J/p+Wp4zqJVAXllWfKU7SNvNwwXq+/PCFRAABQO3mSAWkm 6+vrv5Wz/mXb+rJz7969t0IZUSrJBCnXkjEy5MmP5MgN13uxKGmZp1iw8jJZFnnS96VnU/JaLBuy LpQnEbZs1kr2KS67+u3/UaZznSdPpkRtbGw8O0rba7fbxwg4MCsY7wS0ReQpFxkU+fjjjz9cXl5+ oHPu3LkPL1y48L65/iMf+civZOR/1XBd9zCUkVhkut1pXW/Ru+D6y1Mn3E7K6ttEAjVEt12Udkrt S297bdtQstx0mbR4Jar2z53Fd0+cfvqvynKuB8mTIOVOnDjx92fPnn1Xb18XL15878UXX/yl2e6k jZK1glkizxNjth0UjTzbjtl2JUQuSK+++up7ww7DkQtfFY8z7LZLSYfIjy4m/eVJedp6EZ0wa6XJ U0q0OrmZp7wuOXO78G+l7GUiUdM4d3VnrTRfiAHSFF2Qnnzyyb87PDwcqt1JG0WeYJZwqwIoA9yq AHmqpjzFGSJ9fTRAvLtNsu3R5akrZEmpOPNkZqO8bNkqjHmyXYiQJ0CeAJAn5Kku8pS68GvdfJmB 5L1tQsEyy48oT8OMeTLkKtnHz35weePG2TLKU78LEPIEyBMA8oQ8lV2earqUMfM0zIUHeQLkCQB5 Qp6QJ+Sp92UfphzyBMgTAPKEPJUYeYCuSEYdkWOr4meCPAHyBIA8IU8AyBPUBLmnnTxXjHMBRSJt UNoi8oQ8ASBPAABzDvIEgDwBAADyhDwB8gQAAMgT8gTIE8AQbG1tLXIegLaIPCFPgDwBDAmz7aAM MNsOeQJAngB5AkCekCcA5AmQJwDkCXlCngB5AuQJeQLkCXlCngB5AkCeAHlCnpAng93d3aY8rgT2 Wnfu3HkJeQJAngB5Qp4qIk9SbxGBJ7gY7/ss4fLgwYND5AkAeQLkCXkquTxJfQsLC4fNZnOviOdC IU/IE8Ak4Nl2UAZ4tl3N5UmXpiJv6IU8IU8AAIA8lVae2u32sdXV1c3jx4+/U7Q0jS5Pnq+CY2nE OL7bSdY73T+CpeO7TvSa/LtX3nH9jqXWjuvkvoY8IU8AADCn8hRJk2SalpeXb29vb58qy/GMJE+6 5HgqODYVrJX1ju+E/07Lk4hRLFVBeeVl1CkoG6xXDctryBPyBAAAcytPjz322IPTp0//ZavV+rZZ nwxuC5YdGyJc0y4fylPH9R2lksySci0ZI0Oe/EiO3HC9F4uSlnmKBSvPx1R3GykX2VNmXwasD6vR MmKyXspq++qpKBOWLtst6iTbfu3tD/XzY5MP6UvPO5/TLn/ixIn3kCcoKxsbG8/KD0XOBRSNUqqJ PNVEnp555pkffPGLX/zXZnDpd7FcWVl5fdrlf/KTn/x5KBux5HS74bpuonfB9ZenTridlNW3iQTK 3m2XSE03A+VFktTQ1/f+nbde6k+JUrDvbo486ZIWC1ny93/82rlfPHPhn9zpJ6Py+Y8ir5Ms/4lP fOLnyBOUFWbbQRlgtl2N5Em66aS7Trrt5IJZpl9nSebJS3WleRnBscuT8rT1oZy4aXlKiVanzxiq nrDlZY1y1pv1hn8rNVTZWOw0zl3dWStr26PbDpAnAORpbuQp2raMEnVkeYqzVfr6aIB4dxu9u8wm Lqm/o30YUZ7MbFI282RkqfTMk/E3Y54AkCdAnpCnkslTGSVqJHlKZWm0br7MQHK9q80snx2HlGSi gnXeiPJkG/OUWhdIm5M/5im1bePiry5v3DiLPAEgT4A8IU8lk6cySRT3efLJPAEgT4A8IU9VkSdT oq5cufIK8oQ8IU+APAEgT8hTiY/n7t271/f393dgf+f+/fubyBMA8gTIE/KEPEFNQJ6g7Bctnm0H RSPDX65du3YZeUKeAJAnAIA5B3kCQJ4AAAB5Qp4AeQIAAOQJeQLkCWAIeLYdlAWebYc8ASBPUAmY bQdlgNl2yBMA8gTIEwDyhDwBIE+APAEgT8gT8gTIEyBPyBMgT8gT8gTIEwDyBMgT8lQLeeKRKvP5 qBfkCZAnAOQJeToiPMy3/MsoDxmWB0MjT4A8ASBPyBPyhDwN+Xk+8sgjD5eXl28PkijkCcqMUuol 7vMERSNtUNoi8oQ8IU81lydpI8IgiUKeAADmF+RpIvLk+ap30Q1xXL8TvqOsV8F/By0d33Uc3+0c RQ0s23Zc34n34YjLJOowz4vy/CKWo8jTIIlCngAAkCfkaWx5SiTJUw2/6wmzkCfxHMd3tI3NvwuV p7iO8Y7xiAcRvKfy//ODB//rqPKUJ1HIEwAA8jQ38tRqtXYmycHBweEw8iRCY2ZgpFx3XSA7sVjY s1i27e2ik5aU5D162xlS5Cl7WeW64T45lvfM7IvUqVR3v1P7li9PeceT7ENQn+ybl7+/2Tr0cyfn NDmej5258MfDfJ558mRKVCBP/wd5grLCmCcoA4x5Qp6GkCdb91RPnkK50AUhEABXGeV6UuCpOGsk cqC8nhyZ2xsZnHidLkdBXY2UeERSZJERT6XFR+qJ9kkXH9u+iOBYM2xpmYn3Oe94PMs5yZOnnHOa zrh1M09vv/POu8N+nsgT1AFm20EZYLZdjeRp0vtg67ZLy0OwXqTAuAiHWZ3EJrSsjC4cvTot22eG D/WkS++ys3bnKWWVkUxXX6ePZJn74uZ18SWZpzBLFO10zvGk96F3TrwR9sPTslFd66TbDpAnAOQJ eaqsPJm249kzT3G2Kbdsv/FFKkDL8BjbZTNPmrTZMk/DZKj6jo/K6bbLO56Bmach6kiN+/LC8m/+ 9YOfHlWeGDAOyBMA8oQ8FSFP5tijUJREBIzxPZYxT1EmJru9zT0aqW4665in3LFWtjFPg8dGNSxd a3Z5SmeW7Mejn5Nk34bZX3lNzmHDyNpFZX5j9Ztbo8gTtyoA5AkAeUKe/Grc5yk9niktH/O1TG52 HjfJBOQJAHlCnmosT+ZYnoJujTS38sTjWQB5AkCekKcpy9Pu7m5zb2+vBeXlzp07E58qizwB8gSA PCFPAMgT1ATu8wRlgPs8IU8AyBMAACBPAMgTAAAgT8gTIE8AAIA8IU+APAEMiwzU3d7eXuBcQJHI mKdr165dRp6QJwDkCUoPs+2gLBLPbDvkCQB5AuQJAHlCngCQJ0CeAJAn5Al5AuQJkCfkCZAn5Al5 AuQJAHkC5Al5Qp4AeYKZcv/+/c39/f2dOtNsNg9v3779Vt2PUx6PRZtGnpAn5AmQJ5gy8qBov+ZL q9XyA7mo+2H6d+/e5Xs1Zba2thaRJ+QJeQLkCXmqvTz96Ec/8h8+fIg8wfiSEFw3m83m3lElSilV y+wg8gSAPCFPLMgT5MpTxDgShTwhTwDIU+XlyfOVdlFoKG/Ey7Zsr3xvKkrQ8V3H8d2Ovsr1Hcf1 O2NXPYl6xj13yFNV5QmJQp4AkKd5l6dYIiyyMpb4jC9VHdfxHW2HzL8Ll6epnLvRzzHyVIw8IVHI E8DU5elLX/rS+0tLS/+11WrtQPH87Gc/e9BPAERU0lkVI9MSbqdnnozXezhKhaioHhEXM2Mj6/Qy VslJ75+nLFkfQ4raa5/13/zrB5nyypVyTrIf2ntmjjtv30Y6d/r7B3WpXlljf73eetv26fMb7LuT HM+n1rb+hjY9XfrJky5RKysrr5nbfuELX/g3zz///Nu2eqsuXcgTwJTl6Stf+crPkacSypN2QY4z J6EwJKIQXtRdFWd95OLefVmTJ09pWSEt8xTKUl4WqleuTxnPJhrBezVS0tHo7o8hIy889XH/m2/v d8ubUhYfryY+tuP28vZttHOXlqA+8uRZtu+Y5zd9jt98802+VwXL02OPPfZAyj3xxBN/v7m56d+4 cWMggVB9WPVsPPIEQLfdXHfbhdmO6KItsmFcHJSny4KebUrEIs6YKDctT6kuMrno63X35CmvG60n DXqXXW53Xo48Zbr7cjI+1uN28/Zt+HMXZrlSYtlHnlzbuTfPr0e3XUm67SJp2t7eXpjHmIg8ASBP cy1PqYu6malJZZvM7Es2KxNd5G2CYM1Q9R2DJPuoArTsjrF/9sxTxz/z8T6Zpzx5Mg+yM1ieBp27 9Lq8zFOvDlcNHHzelUEvfk/kafbydPz48XdWVlZej6RpXmMi8gSAPM25PKUzOqkxReHFPj2mqVsu kafUOJ1wXI825iklH+bYnUHy1NsX43XrmKfUesf/eCRP1jFPFnmyHbc3jDwNOnd6ts0JM1HZ90vW Z7fPnl9P23bpn/2779OmZyNPIk2rq6ub7Xb7GDEReQJAnuZSnoZfdMEwxaGsSznvMD75mXlknqbP IGlCnpAnAOQJebLZk3UcDvKEPM0Dg6QJeUKeAJCnOeDOnTsv7e3tterM0tLSwfb29mbdjzO4sJ+i TRMTkSfkCQgUAGPDIzSAmIg8IU9AoAAAICYiT8gTECgAAIiJyBPyBAQK5AkAiInIE/IEgDxBlVhf X3/ZvIkhADEReUKegEABkMPi4uL+9evXW5wLICYiT8gTECgAkCcgJiJPyBMQKACQJyAmIk/IExAo kCdAnoCYiDwhTwDIEyBPAMRE5AmgJIFCKdW8dOnSm5zf+UWe1eZPYJnks+34XAB5Qp4IBFC6QCHS tLS0dO/kyZMH165du8z5RZ7GXS5fvow8AfKEPCFPUL9AoUuT3JeH8wqTkqd33nnHn9TC5wLIE/JE IIDCAwXSBPnydOcbruP4bkdrQB3XdxzX74xrQUesh88FkCfkiUAAhQUKpAmGyTx1XMd3NHsy/0ae AHlCnpAnqH2gWFlZ+eD48eM/DXgnaLNX9XrkERqtVmsnD/MRG/K3zKLKo91uH5tmefM8TLu87F9R 5QPZfWnc8keRp7TkdHw9E+WpRhjHQpRnlSJPdcvrZcOiYblAxIztRc6sdSrlK1l37tX/wHcekCfk iYYOMw0UzWbzF48++uj7p0+f/suvf/3rv6nXI9mofvIkr+vl5SIt09Dz2NjYeHaa5be2thb18pJB m2R583hlAP00y1+5cuWVUc7PqOUlRsViYvDII488DGTylF7+1q1bf6gLUEqMPOU3UpKkS1Fann77 t3/Tb3ztP2UzT41IxHpS5okkeXGR1Ps2lO/14qaNxx577IEp96urq5ujHG+/8vJjw5T75eXl26Ps j3yHRt3/vM/2zJkz9839CX4YvT7N8rL/eeUli23GpWmXl9nAeeWD8/nB2bNn3w0+owca//fChQvv G+sePP744w+RJ+QJkKeBv7LW1tZ+VwLzwsLCoVwAzIsIQJx56omSdNXpXXa53XkWeXrqqY/7n/3m 23277UJRclVGKkwh43PJR77HfTKRzXHLy4+PMpWXHwd55eWHkblOYp4MUxgm6408IU+APOWmqCVg IFEwUJ58z1eOCtAGj0vmKZUlsmWeuhmlM2ee8htr7eHkSavTVpbPBY5KlMmu47EhTwAzlKcIJAr6 y1NvzJIxwNs65im13gnHNZ1ZbvnttfxsUt7YqEYj213I5wLIE/JEIIBSyBMSBYPkaZyFO4wD8oQ8 IU9QW3kyJUoGjXJ+kSfkCZAn5Al5AuSJBwPDEHzve9+7HLSr/XGRGU3f//73DyZRF58LIE/IE/IE yBPUHslg2u5rBTBL5N5nyBPyBIA8QSVg7BzQFpEn5AmQJwAAQJ6QJ0CeAAAAeUKeAHlCngAAkCfk CQB5giqxtrb2DcY9QdFIG5S2iDwhTwDIE5QemeHEbDsoGm5VgDwBIE+APAEgT8gTAPIEyBMA8oQ8 IU+APAHyhDwB8oQ8IU+APAEgT4A8IU/I0wRpt9unJvEcq0myu7vbRJ6QJ0CeAHlCnmouT9GHvb6+ /nKVzsWtW7cW/ZIte3t7tQ3eyBOUGXm2nTxXjHMBRSJtUNoi8lRjeYqkqaq/2JAn5AkgYnt7e4Hz ALRF5Glq8lR1aUrk6cZnXcfx3Y52wB3XdxzX74xrQUesB3lCngAAkKcayVNdpCmRp1uLHdfxHc2e zL+RJ+QJAACQp5HlqW7SpMtTWnI6vp6J8lQjPP4Q5VmlyFPd8nrZsGhYLhAxY3uRM2udSvlK1n3h 936APCFPAADIU4m4cuXKK48//vjD5eXlBzoXLlx4/+LFi/9grg8u8r9+5JFHHp48efJABrGZfbHy DJ5IrEzKXj4a8xQJUEqMPOU3UpKkS5EhT65KREjPPDUiEetJmSeSlJRLvW9D+fLK5ubmW3n7v7S0 dM/8PFut1k5Vyh87duz9s2fPvmu0sXfPnz//gdnupI1KWyXgwKzg2XZQBni2XYmR7JGJiIXjOG1z /crKyu+JOAlf/vKX/4Xtg7bVJ9hmrpSpfDxgPBAl6arTu+xyu/Ms8qSUpasvT7IajRSmkO3u7r7S Z/+b5vFubW0tVqX81atXv2yuW11d3ZS2ZStPIIVZwq0KoCzXZ25VUCGazeZev26SOnbdJbPtPF85 KkAbPO6ls0n2zFMvo5SXeRomQ2WUrfOYp3kLFIA8ARAT51yezA9WsgVVu69Tvjz1xiwZA7ytY55S 651wXFP+mKf+Y6MajWx3IfIEgDwB8oQ81UyeIqTLRsa8VFmiuM8TgQIAeQJiIvI0M3mySZRtDAzy hDwhT4A8ARATkacciUKekCcCBSBPAMTEuZGn8+fPf6fqY5igesgMSNstDwBmjbRDnm0HJYiJTZ5t VyHa7fYxGi7Q9oB2CEBbRJ4AAAAAkCcAAAAA5AkAAAAAeaoK8iydjY2NZ/mAYZbI41zkES2cCyga aYfSHjkXUCTyiLGVlZXXkaeKMO6tCgCOArcqgLLArQqAmIg8IU9AoABAnoCYiDwhT0CgAECegJiI PCFPMEXkjuVl5ubNm5vr6+sHZd9Pk93d3SbtC3kCQJ6QJ+SphpTt8TN1WQ4PD8mWlYzt7e0F5AmQ J+QJeQLkCXmCIWm1WjvjCBDyBMgT8jQyy8vLt3m2HfLEgjxVWZ4ajYYvHEWEes+2a3IuoUikDdb1 eZ98wFAhefJ81bughChvRE2Q7ZXvTUlCOq7jNxzX7xxpa33fxtnP0bdFnsotT+NIFAAgT4A8+SqW k47vOo7vdiamPkF944hVd3ulGr7yZiM9k9p35Kka8oREASBPE0Ge1ix3L5VAMwwXL178g2HLQvno J09h1ieVkTKyVOF2ZnYnet3xHScp6wSVZusL38R3lOpuZxqSp8Lt5P/W8vE+5K23Z548lexXWK1s a2Tf9DKO66YkTH8t3C/zvYN1BwcHh7SvcvH000//WZ486RJ19erV1VFiIMMZAJCncDDa6dOnH964 ccMfBgk4BOaKy5MmPHHWKRQCT/OY4DW3JzM9seq+rAmKl7yeyd7Y6utE4mLP8MRlzHoMkUkEyFxv kSddxPpmnPTMU/oY9W7E8H1ceW99Xx3/tf928L9pX9WTp4WFhcOzZ89+9/nnn/9wlBjIhQ8AeWot Ly8/GLZ7gsBRn267MDMUiYVIgnFh6cpI9Ld9LFGcXeoaTSIg1vp60mMd02RkuXLKy/uFwmZd72bk yY3KZ4RJf698eeoY24d/K5V6b5G+39//n39F+6pOt51IUzSbWP7/6quvvkcMhDIiz1eUtow8IU9Q EnlKddtZMjRJtmnwuKKuZHh964szXDZ5MrNYUebKKJ/KPGXWD5l5Sr2XnnmKsklG5imVQetlnpCn SsqTLk0RyBOU/RrNrQqQJyiVPKUzK6mxPWG3VDob1C2Xzso0jMxUVIeUzdaXL09Jl50uacE6Lzs+ KZarzPohxzxlxmqZ+z7EmCfkqVLyZJMm5AmQJ+QJeYIh5WmEuWspoUlL18yWvExVbvdfMQuz7cop T/2kCXkC5Al5Qp5g4vJkjltSXgFWgjzBEZGxIsOUQ54AeUKekCfoy/7+/k6ZuXfv3luu6x6WfT9N 7t69e532VU2QJ0CekCfkCQgUAMgTEBORJ+QJ5oU6P8cJkCcAYiLyBACAPAEA8kTgAADkiRgIgDwh TwAAyBMA8oQ8AQAgTwDIE/IEc83Gxsazly5depNzAcgTQPd+ZcE1+jbyhDwB9G2P3KoAkCeA+sdE 5AmAQAHIEwAxEXkicACBApAnYiAQE5En5GmOuXXr1iKPZ5ketDHkCQB5Qp4IHDVjb2+v5bNMbaGN lYvt7e1TyBMgT8gT8gTIE/IEQ9JqtXZOnjx5sL6+/jLyBMgT8oQ8AfKEPMEQ8iTxSugnUcgTlBm5 fctzzz33R8gT8gSFylPHd53uBaXhuMFfk1hsdXq+aqjgv6MsR92m996C8vyiFtpYeeWpn0QhTwDI E/IEfeWp4zq+4/aUyVN+1zVEfkaRlnR5e52zWgJ5ioVN9svx3c4s3z85F7Sx8suTTaKQJwDkaSby JEEJqsfm5uZbIjcNI7vjqeSi4ijlO7ZMTscNX1PGRSiUJkudSRbJyAyJ6Jh1xbbV26bv60ZdfeRJ pM48juRYg/pVr6y8n5aF83rrbdun9yGQRifZn4+dufDHtLPy8PTTT/9ZnjzpEnXx4sU/QJ4AkCfk CfLlqZcdSnex5WWetPUiGLEgWcpn6uyJULA+ykqJjIQOEtYVSY4uPJo82V631WXITJx1CgXM03Yv eM1VhgT1kSfPsr2xD+Y5oo0hTwCAPBE4athtl1KjuLtNlyFt/FIvQxPL00DZ0uu0ZZ5sdWliostT 7utGXVrmKcwURcITyZyeJXO07kVdymzv52a3T5JwjpaNotuObjuA6cGz7ZAnKIE8JSJiypMts2Jk nnK6x+x1dkXIjTNEKcM6kjx1bHXlddt5Kjt43Bsm89Srw1UDB593j9WL35M2Vn55YsA4VPEaza0K kCcoOvMUdomZ2ZtkLJDjusaYnrxskTbmyVqnfcxTXH7szFMjkTStrD54XR/L1e3S07NqTpiJSgQw uz67vTEOqnesUbnfWP3mFu2snPLErQoAeUKekCc4ujzNeNGzUqboFFnXNGbm0cbKJ0/cJBOQJ+QJ eYLKyZM59mis2xhMsi7kqfbweBZAnpAn5AnGZmdnZ0EEqszcvHlzc319/aDs+2mDNlZNkCdAnpAn 5AkIFADIExATkSfkCeYFeY7T+fPnv8O5AOQJoN4xEXkCAECeAAB5InAAAPJEDARAnpAnAADkCQB5 Qp4AAJAnAOQJeYI5hAHjgDwBzEdMRJ4AJtgeuVUBIE8A9Y+JyBMAgQKQJwBiIvJE4AACBSBPxEAg JiJPyNMcsru729zf39+pAvfu3XvLdd3DquyvDXkMDu0OeQJAnpAnAkeFuXv37nWfZWbLrVu3Fml3 xbO1tbXYbrePIU+APCFPyBMgT8gTDEGr1do5fvz4O6urq5v9JAp5AuQJeUKeAHlCnqAnTxKvhH4S hTxBmZEManCNvo08IU9QiDx5vupdSEKU53fXKd/L/bT7vN5xfcdx/U56pe86vfrj1wa9x4jv23cb 8/iQJ+RJaxM5EoU8ASBPyBPky1NGdsZYLPLUcR3fcXtrPOXP1l/04xOJc3y3M8v3l/fsCh/yVF55 skkU8gSAPM1EnqT/FarDa6+99iO7PPUyPCJCSiWZm9h6ogyQntXpSUkoT4Es6dsEwtTIZIz0LJKR HZL9sb63tk3u60Y9feRJpM7MSHkq2j6oW+nHlJwjT/WrI31OHCfZn4/943N/S7srnoWFhcM8edIl 6vnnn//D9fV15AkAeZquPMk2UB2++93vtk3h6GaINHmKpCglHr3XAylyzDRO3jahQOV022n1iIyE DmKtx5An83XXUo9N8GL5SnQuFKJg+7QgDpCnnDrS5yTJPH3rW996hXZXPC+88MJbg+RpaWnpXqvV +n0yTwDIE912MGS3nSZP1oxLIjFx5iWSiD5ZmnQXXl7mSZOjTD2GPFlfN+rRji/c12g/I5nTxdHR uhd18cs7JksdUn36nNBtV6VuO5EmpVRTytFtB2VGnm333HPP/RHyhDxBBeUpI0WWbRyjq8yUpyRL lD92ahh5km627HiqnG47T2UHj3vDZJ4G1JE5J15cHnkqrzzp0hSBPEHZr9HcqgB5ggrKk6uP9+mX EfLcZAxUKttkH/OUJ2GjZZ60LkitnD54PRnfFHXpabMCG2npS8rmre++JgJnnpOozD/66r/6t7S7 csmTTZqQJ0CekCfkCQbIU/FLumvv6LP/JlWPbxlcPomFzFN55KmfNCFPgDwhT8gTlF6ezLFDR76V waTqQZ5qzTCPZkGeAHlCnpAnyLuInNrb22tVgZs3b26ur68fVGV/bQx70YZygDwB8oQ8IU9AoABA noCYiDwhTzAvyLTcS5cuvcm5AOQJgGfbIU8AAMgTACBPAADIEwAgTwQOAECeiIEAyBPyBACAPAEg T8gT1Ay5oaHc2JBzAcgTQDcm8mw75AlgYHvkVgWAPAHUPyYiTwAECkCeAIiJyBOBAwgUgDwRA4GY iDwhT5BBnn23v7+/Uwbu3bv3luu6h2XZHxu7u7tN2g3yBIA8IU8Tlado0K8EJRp/+Tk8PNz3WYZe RDZpN8gTAPKEPE1EniJpOnny5MH6+vrLNHzkCXkC5AkAeUKeLIEDaUKekCdAngAmjzzbrtVq7SBP NZInpKlO8tTxXacRfr4Nxw3+ksXzVUMF/53kIu/j+G7HXO36TqP3/mO9Z7TPyfEob7LHgTwhT5w3 AORpZHlCmuonTx3X8Z3IaDwVCMe08jY2eRK50daJSA29A1KfRYykjlgCj7KP+bKFPCFPnDcA5Kl1 /PjxX4hADYMEjoWFhUORpkuXLr0pfbE2ms3mnvlekywvr5nlpQ7Kj17+hz/84QMRpmzGJ8rYyP+j rFAvMxUKjkrWa7IjItYw1nsq2j6QNFOe5L1zZClTl/6+wd9JvY2e/Bn7Gu9/cmz6NsrVM155dRr7 sfrtv2i328fkB0Te+V9dXd3Uz33R5a9cufKKXn57e/vUmTNn7lN+cf/JJ5/87x/96Ec/HDYGPvro o/+PCx/AnMtTJFDDsra29juScZJALQKVV06yU+b7bGxsPDup8vKaWV7qoPzo5X/84x8fxBJj67YL 1usSEXpO2M0WSZCWTTKyRp4K1ru6HBlZpl6djtuxmVO2Lk/eV5c8M0vU2+dU5kmTpz6iltRl1Gns x7f/6dIPLm/cOBucz5fyzr+MU7Cc/8LKizyM8r2ft/JBLPutYWOg7bsFAHMoTzaCX1i3+3XJyWuR RNnEB6qDOWA8kRlb5qknFUa3WCg2HU3ANCTTlMiRpdsuT2gsdYWZolR33GjylBU1baxXfHxGnZb9 OHd1Z422U2+IbVAG6vy8z1p+YNLFM8x9mpCoeshTLD8WeXKjbFOfMUUpeTILe/0zT9l1wd9S3lZX xyZPxrajZJ60rFo686TVaWzDmKf5QLr0JNPEuYAi4VYFNZUnJKommSfrbDf7mKdQNvLkyRhT1Ail SM/uqECMBs2261OXlx0IHpVJZcvy5Mkc8+Tpxybjsbrl0nWa+7H0nnTb0XaQJwDkCXkaS55sEmUb lwEllad+k/+Vkdk58iy2eixknpAnAOQJeZqoPOkSReCphzyZY36mdxsD5AmQJwDkaY7lCaqDPOh2 b2+vVQZu3ry5GYj3QVn2x0a73T5Fu0GeAJAn5Al5AgIFAPIExETkaRzW1ta+wf1MYNbIODnzBpAA RSDtkHGbUDRyz7KVlZXXkScAAACAOYeTAAAAAIA8AQAAACBPAAAAAMgTAAAAAPIEAAAAgDwBAAAA ACcBAAAAAHkCAAAAQJ4AAAAAkCcAAACAKvH/AZDfex4+/DiRAAAAAElFTkSuQmCC --_005_BYAPR08MB4903E91A2E9FC117755443C1FAD50BYAPR08MB4903namp_ Content-Type: image/png; name="image006.png" Content-Description: image006.png Content-Disposition: inline; filename="image006.png"; size=11835; creation-date="Tue, 06 Aug 2019 23:19:59 GMT"; modification-date="Tue, 06 Aug 2019 23:19:59 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAk8AAAEvCAYAAABc2yWpAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAC27SURBVHja 7Z1/iCXHndgfYmXJsM7NyiutLK+lBcleoV8eSSut0sh4QMsgjolZn1nGSOiyOKZisFmWrI9RDo4d /WNPEoFacI5xMIwRRtJFZAWGa9lxuAlRwALjG3IJnEKHTC7gMzh/7CmKtXYUqdPffq9fV9er6u73 Xr/X/fp9Cj5aTU91d3W9etWf+VZ1de+5557rAQAAAEA1qAQAAAAA5AkAAAAAeQIAAABAngAAAACQ JwAAAADkCQAAAACoBAAAAADkCQAAAAB5AgAAAFgcebpw4cLd58+fXyvi6aefXo/TReizsbHx1bI6 E7a2tlZojNWQuqpSp1L3tMEM+W6W1Zl8x2lj1VFKPVZWp5ubm39A+8v4whe+8IdVvr+0Lzc7Ozs3 0gdO1Adu1NkHVr1h3Xr48OFrp0+fvlrEqVOnfvfQQw9FDz/88Ifw8Ierq6sfPvroo/+7qM7uueee dz/72c/+BZ1CNaSupM6K6lTqXOqeNthHvpPy3Sz7/sp3XL7rtLNyYik6e/To0dI+Ma77D+LPgD5R 6xPjenmnqM6OHz9+TW52tDM7n/vc5/7VnXfe+Rv6wLH6QPn3/Tr7wEof1qVLl07cdttt70ak2tPe 3l508uTJfTqFakhdSZ2R6k/yHZfvOu2snC9+8Yvnn3rqKfrEGaTLly9Ha2tr27QzO7EYvba7u0tD abgP7Kg8hZGvvKjX68WoKAjbW1LkCXlaxI4DeUKeZpWQJ+RpEfrA2clTGETKSwUmxlORPxOJic+T StJwk8rO2/Pi81rytCQhT22Sp1i6vZ7Wdvp4ngh4XY23vW0ReUKe2pCQJ+RpEfrA2chTTl50prth hH5fxrychY3ejALVM/LVd8Oyl2HyhDy1X55SVC22gzwhT6SihDwhT4vQB85AntKbQ0x8t0kVIwz8 SHmzkCdLCVSdN7vJylA1IU9tlCdPi5KGcXvyapH/LnUcyBPyNKuEPCFPi9AH1i9Pw6hTwY0mDOKb VNGQ3uAm5vna3CVXJED/S94SOYiPEVr/2g9zx/YGohfEcuTl9k/LZo9KDAWt9JrsCXlquzzlP/vy z9uSV/9eKFW5LU7appAn5Al5Qp5ICyZPaWSm5wz7aJEp55Be8fDJ9PLkEiFH2ZJjFMlTlWtCnhZX nsyh4OLP2/YdyKKhU7bFGUa/kCfkCXlCnpCntspT+hd4IiT9m8foMJv217t2Fxt3zlN2PCOPHh0L 0zJ4cf5YkYJsqDE+4cixrWWodE3IU2fkqfTzNtpb3I684c8V26KavE0hT8gT8oQ8kRZMnsqG7YZy VTgh134Tq12eLHeh0FeR57n/2reVodo1IU9dGbar8nnrbTDfZqq1xWnaFPKEPCFPyBNp0eTJMWG8 v3RBfMMY+au9+k2sdnnytL/2/eyvfS/dceLIU/WEPLVdniwTxqt83kMp8o1jjtcWJ2lT8+g4kCfk aVYJeUKemkqNL1Xg/qtZH7aoMufJLk/uOU/pfatEnhxlGN6weuWRJ+Y8dVmeyiI+VT5vI89Qgiq2 ReY8IU/IE20NeVoueUpuQ4Ex/CVPCqVLfZsLaFaUp+RG4+mLX04qT2kZesYTTnqUoV9mpSw3xZEy VLkm5Gkx5ckbLJI50sBLP++0HU7WFidvU8hT2+XJsRir8mt8G0J71xNDntouT/n26fmWFqSv5WiJ jutBBus0gwqLaJceo6vyRKqWkKc2ydNyJ+SpWXmqd5i2ujzVvXbdtAl5apc8jbahst8bUfMR8yl6 qr3qMZrvA5GnhhPyhDy1JSFP85YnPXKdPpHpRfN2GOQJeXK1T8+2Zl3aVq1r1kXDqJRErPrHsf9e lyVZRNvT5ansGC3oA5GnhhPyhDy1JSFPbZCn/HBu4SKpMjWiNzrM7JrOkDxJrB1L3tfoXrvOslBx /Av3IsLufcZNyFN75Mn3R58GTmV7dM26tFlm7dC6vMqwrfflyKbspcdoQR+IPDWckCfkqS0JeWp+ 2G70fZyOBwa0G1AledKe6pQHY2S+iV9FnnJDJ6pkuMW2D/K00PIUpu3I1q5s8jTYlrYJx1IsgfHm EE9/Mr/iMZAn5Al5Qp6QJ+QpPzG3bCHW4bBGmMvvfBn6yJIYWmmsw3a2hYrLFhG2L248bkKe2iRP jgWC+41wVJ6c7XB0ODoceSAm31arHKPJPhB5ajghT8hTWxLy1NCwXZhFmbIl5koWSXVEnoqe6jSf JC5cu865XEzRIsLuFfrHSchTu+Rp2NaS4dhqT7oXR1XN0wVD6ZY8Ex2jgT4QeWo4IU/IU1sS8tTc nKehLJlDFa6n70JzWM8zoj2up+36i7DqN6LK8hSULSKMPHVSnsxI6Zhr1pn7SXtLhun0uXLD6JZf 6Rht6AORp4YT8oQ8tSUhT83J0+jQRJWXTxdJSv7G1o8YpfOdelZ5ss95GpUn98KtyFM35SnfRkqH hp1LE/SPV7iIdsVjtKEPRJ4aTshTc/IUqHG/jNMuPFjzwoVaOL2O/gR5alKetCGPYWSnYJFULfLk ed4AbSFi58upHRN0Rxb+LXtVkW0RYeSpq/JkX0oj38aKnorLzZsatCPPskBs9WMsjTxNv2Ip8gS1 ypNFPGxj7fnVxVsmTzXdrJCnecvT9CkVfxU3zjAMB5Nvm1knqu6EPDUtT8ubWi9P469Y2t2EPDUj T6PzPIrea+eeIDnmLa/2V2bUucAh8rQo8lTUVhe/70SekKemUovlacIVSzuckKdm5Gl0yE57zHr4 GFJgzA9pnzzVOXSHPC1O5Mk2pGd9B+MCJuQJeWoqtVqexl2xtOqKtoGxeu5w+ZPC/aOSVXqjklV+ p19RF3lqQp5sEuOQp9wkWnMeSckK0GF+Lonyfeu6KJO3P9e1IE+dl6cOJ+QJeUKebPI01oqlwfgr 2ubylOxfeZXesqdLJl9RF3lqnzy5P29bWx2jbUy8SnTR0Ex9856QJ+QJeUKekKfWytM4K5ZWX9F2 +I6c3DuiSvYvW6W3bJXfGlbURZ4akCfrUJdNdrzhUyAj0lXWNvR26Hp/2dTtD3lCnpAn5Im0NPI0 zoql469oa1vfZLy//Cuv8lvDjQt5ap88uYOHWdvyy9qGdb2S4sfHx29/yBPyhDwhT6TlkaeqK5ZO tKLtaHTAuX/ZKr1lq/wiT92e81S0X+kK0KORp9CMPE3d/uppg5N0HMgT8jSrhDwhT02lBZCnMVcs 7U0YeSrZv/oqvbNbURd5WlB5qmHO0/Ttz3UtyBPyhDwhT6ROylOVFUsnW9FWP0bJ/qWr9EbFq/wi TwsqT1HB3KGq8lTWNiLL03bpCzDran8RSxUgT8gT8kTqrjy1M7VhlV7kqRl5qnNxySbbH4tkIk9d S8gT8tRUmok8ffzjH39Pblrd4YfR1+91DatsRDtzKscLL7yAPI0pT1JnU9f9D78e3Suf9b1fj364 sO0vPca90dd/OH2Z5DuOPFWXpyeeeKJjfWI7OH/+PPJUIk/PPvssbWUGjNMHVvqwdnZ2bnzggQf+ ndy4ijhx4sTfHDt27L2miSvg/VtuueV3pXmP/t61j15//Qf6jev66z/6we8dPXatjnLceuut/+fT n/70fymrt42NjX9Kp1ANqauy+pQ6l7ov+3xWPtr7f73e9dHHjh777Sza4c033/zbm2666YOZtb+j H/vt9bLf9R/74Oix4n3ku1lWb/Idl+867aycCxcu3B3X2S/K6vT48eO/bkOfeOTIkQ+PHaunX5uG T3ziE+/G9fKfyuotFqg12pmdc+fOPVNXHzhrSvvAOXL77bf/bZ19YCcb1+rq6q78ZcgXDZpEbgCx tOxRF9A0KysrB0QVgT6wPpAnADoOQJ4A6AORJ+QJ6DgAkCegD0SekCeg4wBAnoA+EHlCnoCOAwB5 AvpA5Al5AkCeAHkC+kDkaXE4d+7cl+VRYhovNMnW1tatGxsbX6MuoGnOnDnzLMtQAH0g8gQAAACA PAEAAAAgTwAAAADIU7vZ2tpa4cMF2iIA7RBoe8hTRU6dOvVdmTROw4UmUUo9dtddd71BXUDTHD16 9K9l8i51AfSByJMTliqANsBSBdAWWKoA6AORJ+QJ6DgAkCegD0SekCeg4wBAnoA+EHlCnoCOA3kC 5AnoA5En5GkWvPjii3fv7u6ugRupIzoOAOQJ6AORpxbK0+bm5ln50OdZ5v39/d2IVJikjug4AJAn oA9EnmaAyM8kHYXsd+zYsf2TJ0++Pu+OBnnqnjzJo+EsmQFtQN4vxrvtoIE+cKWrU2j4gA1pUkqt NlEG5Kl78gQAAN0EaWpYmsaXpyBSvV7UG+JFfpht9/o/xCmMfC/9nfz/IL/nR6HlqKHvOX+HPAEA ACy5PLVJmiaSJ11yAhVLkYq3ynYv8pL/z8uTiNFQquL8KhhRpzhvvF31LL9DngAAADolTzIhzSSW oz+wbf/85z//3JEjR8Lbb7/9zY2Nja/a8jTFm2+++UZsOZGnVBZZUr4lYmTIU5TKkZ9sD4aipEWe hoLl8jHV30fypfY0UpaS7clhtIiYbJe8WlkDNSiP4xj6/tnpvOyY/+Bf/LJNn5nR5s6O0xbpfGCe 8GoWoO0hT0NkMu7Ro0evnT59+qrOww8//LtHHnnkN+b2+Ab84aFDh67dcsst/1meAGgTr7322q8S qRhKTn8Yri8R+hBcsTyFyX6SV98nFSj7sN1QagYRqCCVpJ6+XRMf23Y5fk6U4rL7BfJkHsNXORHL RC3b9sdnTv7mpuN3/Lxtn51w3XXXfWC2t0cfffTdhx566H1zu7RZJpLDPJGn7RAomDfybjuetmsh Mov/qaeeerfqsE8S0VBqVYbrZNhOogVtuZZk2C4nC5rI5ATHLk8q0LYnESQ/L0850QoL5lANhK0o amTZbh43+VmpysdQyiyXJnwaDz+9vdHKL1JctqpJ2iyLuMK85YmlCmDesFRBh+RJM+JWSdTE8jSM Vunb0wni/X2yfS3ylA7ZmdGeMeUpN+RnjTwZ0SvzGLbIk3HMNs95Qp4AeQJAnjovT22TqLHkKReN 0Yb5RiaS68NkZn7zuHokKt4WjClPtjlPuW2xtHnFx7DNecods/fZ3z554fKDyBMA8gTIE/LUoDy1 RaJY52mxn7ZDngB5AkCelk6eTIma980NeUKeAJAnQJ6Qp4WUp6Z4+eWXz+7t7W2DG6kj5AkAeQLk CXlCnqALXyTkCVqMLI3Bu+1g3si77dr0VDvyhDwB8gQAAMgT8gTIEwAAIE/IEyBPyBMAAPKEPAEg T7A4MFkcaHvIE/IEyBPAGPC0HTQBT9shTwDIEyBPAMgT8gSAPAHyBIA8IU/IEyBPAMgTIE/IE/IE yBMA8gTIE/LUSXmSVXx3d3fXoD1sb2+vIE+APCFPgDwhTy2Vp+eff/5ERGpVEoGaVISrvtICeQLk CQB5Qp6Qp6WXJ7nZHD58+Ffr6+sXyyQKeYI2w7vtoAl4tx3yhDwtqTxJmxHKJAp5AgBYHpCnWclT 6Efe4Mbb66komKkehJHveZEf6pvi83t+FE512GmOEURqeP0xarY1MGt5KpMo5AkAAHlCnqaSJxEH TWZEQqaSB5GjYgELfS/yNHsyf25Enob7WuRu5imrszrlySVRyBMAAPLUWXlaW1vbniWbm5t+FCh7 pCWRKNWPyMS/F8EZiczkIlb97YHKfhYhcu7nkBV9/yS/IUWBsudVvuTzsvJo1zRSBuPaiuTJVv7s vPEx0vI4ymm9/lykKy6zl13HJz7/D38+yWd5+vRp3yVPpkQhT9BmlFKr1APQ9pCnVsuTM+qTiNEg gmREo3SBGY2eaJGngv0Cm3SIyOUEJJUiizyZ0peUNz2+JkC2MgTatVlkxhWFS/b1lSFBBfIUOK4/ Lnu+zrM6u3jx4g9mJU+HDh26Fud7AXmCNsPTdtAEPG3XIXmadZmSYbuiyJMuNcaNuL+L3PT17YY8 OffLBEKXN+twnlLOiE5OQMICyTLL4JtDfFnkKYkUpYW07JtEtzK7ykuaeX7fff3DiFSyYbbDdqk0 bW1t3Zp8kZAnQJ4AkCfkaQp5Muc8yc/mcJlLsHIRFD3y5IgOjcwzUjHauY38o5GngmOHFSNU1vlR jmE7275BlcjT4Bi+Kp183pfAYHjOOuXJlKbhFwl5AuQJAHlCnqaRJ3PukiuSot+YU+Ex5+70oydp XhEr+37aMY1J3iNznnLbvCTy457zVD43KilDUCRP+ajWaPn1aJurPNl22/Xn5kH18nV251P/7LvT ypNLmpAnQJ4AkCfkqS55Ik2Y6n8yb5rIU5k0IU+APAEgT8gT8oQ8DZBlCMqkCXkC5AkAeUKepkRe Qru3t7cN7UGEduZfJOQJkCcA5Al5AkCeoBt09f1i0G4kev/MM888iTwhTwDIEwDAsvf5yBMA8gQA AMgT8gTIEwAAIE/IEyBPAOPDu+2Atoc8IU+APAGMAU/bQRPwtB3yBIA8AfIEgDwhTwDIEyBPAMgT 8oQ8AfIEgDwB8oQ8IU+APAEgT4A8IU+dkqc33njjIq9CaTfyGSFPgDwBIE/IU83ytLW1tbK2trY9 7pLyV69ePYhIrU7yGSFPgDwBIE/IU03ylEqTdDLyr7yTB3lCnpAn6MpNjHqAeSP3UaXUY8hTB+XJ lCb5eZKyIE/IE/IEALAcLK081SVNeXkKIhWfo5fi+VGYnFm2q/i/ZSmMfM+L/HASNbDsG/qRNyzD hKmOY5j1ooKoiYQ8AQAA8jSBPNUtTaPylElSoHpR3xPmIU/iOV7kaTubPzcqT8NjTHeNE15EfE4V /eurV/8n8gQAAMjTmPJ0ww03XL3jjjv+ved5OyJPKWfOnHnWnOck8wT0PEX5q8qTCI0ZgZF8/W2x 7AzFwh7Fsu1vF528pGTnGOxnSFGg7HmV7ydl8iznHCmLHFOpfrlzZXPLk+t6sjLEx5OyBe7yjh5D rzup0+x6PrX+jUvpZ7a5uXnW9fna5Ea2ufLLsS9fvlyJ+++//3fIE8wT5jxBEzDnCXkaQ55sw1MD eUrkQheEWAB8ZeQbSEGghlEjkQMVDOTI3N+I4Ay36XIUH6uXE49UiiwyEqi8+Mhx0jLp4mMriwiO NcKWl5lhmV3XE1jqxCVPjjrNR9zskac65enBBx/8vrntgQce+EEa4TSpK+IJUAWetoOmpJ2n7Toi T/MctsvLQ7xdpECXq5gkqpPZhBaV0YVjcEzL/iPThwbSpQ/ZWYfzlLLKyMhQX1ggWWZZfNcQXxZ5 SqJEaaEd15Mvw6BOgjHKEWjRqL51znzYbtk6DkCeAJCnJZKndN/ZTRgvkSfTdgJ75GkYbXLmLZpf pGK0CI+x32jkSZM2W+SpSoSqcH6UY9jOdT2lkacKx8jN+wqS/N/+xdW/peMA5AmAPhB5atVSBSXy ZM49SkRJRMCY32OZ85RGYkb3t7lHLzdMZ53z5JxrZZvzVD43qmcZWrPLUz6yZL8evU6yslUpr/xO 6rBnRO3SPPqcJzoOQJ4A6AORpwnkySVRTS+SmZ/PlJeP5Ur1PZ03y6UKkCdAngCQp6WTJ1OiGn89 izGXp6GlkZAnOg5AngDoA5Gn2ZTle9/73mO7u7tr0F7kM6LjAOQJgD4QeWqJPAGYdHmNE1i8mxj1 APSByBPyBAAAAMgT8gQAAADIE/IEAAAAyBPyBFCGPLnJXBNoA/IqIuoB5o3MeRr3yXXkCXmCJYen 7aAt8LQd0AciT8gT0HEAIE9AH4g8IU9AxwGAPAF9IPKEPAEdB/IEyBPQByJPyBMA8gTIEwDyhDxB 47z88stn9/b2trvC66+//gPf9w+6dE0CbRV5AkCekCdoCfv7+7vL+vrjRUq01fkzrfggT4A8IU/I E/JEQp6WCrkBCZOuG6aUWqUeoQm62vaQJ0CeSMjTAsiT9F/CNBIFAMgT8tRJeQoiNbhJJHh+FCaf nmxX8X/LUhj5nhf54SRaYNk39CNvWIYJUx3HMOtFBVFTibbarDwhUQDIE/IEFnnKJClQvajvCfOQ J/EcL/K0nc2fG5Wn4TGmu8YJLyI+Z7/+aavtkCckCgB5mps8ra2tbUM7+fGPf7xfRZ5EaMwIjOTr b4tlZygW9iiWbX+76OQlJTvHYD9DigJlz6t8PymTZznnSFnkmEr1y50rm1ueXNeTlSE+npQtcJd3 9Bh63UmdZtfz9+565N/SXueLTPh2yZMuURsbG1+17X/PPfe8atvOO+9glvBuO+QJ5ipPtuGpgTwl cqELQiwAvjLyDaQgUMOokciBCgZyZO5vRHCG23Q5io/Vy4lHKkUWGQlUXnzkOGmZdPGxlUUExxph y8vMsMyu6wksdeKSJ0ed5iNuWeSJttpOeVpdXd194IEH/vzs2bPR5cuXSzl//nx08uTJfW7yMCt4 2o5hO2ho2C4vD/F2kQLjppFEdTKb0KIyunAMjmnZf2T60EC69CE763CeUlYZGRnqCwskyyyL7xri yyJPSZQoLbTjevJlGNRJMEY5Ai0a1bdOhu1aOmwn0pQuQ/Doo4++tru7W6k/3NvbQ54AeUKekKel kSfTdgJ75GkYbXLmLZpfpGK0CI+x32jkSZM2W+SpSoSqcH6UY9jOdT2lkacKx8jN+wqG+Wmr7ZAn XZpSkCdAnpAn5Al5GpUnc+5RIkoiAsb8HsucpzQSM7q/zT16uWE665wn51wr25yn8rlRPcvQml2e 8pEl+/XodZKVrUp55XdShz0japfm+dT6Ny7RXpuTJ5s0IU+APCFPyNNSy1N9KT+fKS8fy5XqfTqP ttqMPBVJE/IEyBPyhDwhT3XZU/HcJuQJeVoQtra2VqrkQ54AeUKekKcl48UXX7w77vjXusK3vvWt i5ubm/tduiaBttpekCdAnpAn5AkWHl7GCsgT0AciT8gTAADyBLDUIE8AAMgTACBPyBMAIE/IEwDy hDzBQiFPSPHuMECegD4QeUKeACrS5SdNAHkCWOY+EHkCoOMA5AmAPhB5Qp6AjgOQJ+QJ6AORJ+QJ 6DgAkCegD0SekCeg4wBAnoA+EHlCngCQJ+i8PF25cuV8fJxtWHxefvnls/SByBPyBK2Qp7vuuusN 6gK6Kk8HBwd7EakTSV7M7urHJm0fSqnHkCfkCWBstra2bqUeAHkiLao8yX1TBGhSiepqH4g8AQAg T1PIUxCpuG/tpahgzNu27K+iYGZaEEa+50V+qG/yI8/zo3DqQ9dxnGnrb/bylDKNRCFPyBMAAPKk y9NQICyiMrX4TC9Woe9FnlYo8+fG5Wlm9Ve9jv90f//PyuQJiUKeAACQpxnLk0hKPqJiRFmS/fTI k/77WHC8LK+nVIJKjyXiYkZsZJuexyo5+TIGyhL1MaQoUPb8ypd8XlYO7Zwj1+4q21j1p58/PlZa Lkd5bfsX1fGn1r9xqYo8IVHIE8DMkLH+c+fOfZm6gDbK009+8pPo8OHDfyc3wEl56623rpo342HU JJGFTBKSG7qvhhEfubH3f63JU6CMiJAWeUpkyRWFGuQryBPYRCM+Xy8nHb1+mVzyJPlNKRtesyY+ tmsPXGUbr/7yElQgT4Fl/9Bdx3/82mu/tn3GRfKkS9Qjjzzyisi4zmc+85m/uuOOO/7G3B7ziwsX LtyNPCFPACOwVAG0PfIU39j+q7TTSXn77bf39chJEulIb9giGsZNVgW6KOjRpkwqhtGSvsXk5Sk3 RCa/048/kCfXMNpAGvQhO+dwXkEkJyceRZJlXrvvKlv1+kuiXJld5WXNLIdvq393HT//5pt/YfuM y8RpZWXlQO7Ft9xyy/965ZVXknZVxhNPPPGe7IM8IU8AyBMsnDzNdNjOjNLkok1m5GU0ItMXlcAp CPkIihZ5cs5BknKqGC26Y5TRHnkquKaqEarC+VHV6y+/zRV5GhzDV6WTz/U6/qMf/eWPrJJQIk1p PpGnuD1Uanty30aekCcA5AmQJzN6Y84nSm70+TlP/XyZPOXm6Ay2pcdI5jzl5MOcu1MmT4NjGb+3 znnKbfeSiI97zlP53Kjk2oMq8lRWf3q0zVWubPvo/sV1XGXOkylNyBPyBIA8AfI0tjxVT7pcmNJA GjfV+2Re2VIFLmlCnpAnAOQJkKcZypM5j6ehJY2QpzHkqUyakCfkCQB5AuRplvJEam1yyVNVkCfk CaA2eeLddtBlefrOd76zGp9vDRafF198caqlA5An5AmgNni3HXRZngCQJ+QJAAB5AkCekCfkCQCQ J+QJkCfkCXkCAECeAHlCnpAn6BYy32ljY+Nr1AUgT4A8IU/IE0AFWKoAkCdAnpAn5AkAeQLkCQB5 Qp4AkCdAngCQJ+QJeQLkCZAn5AmQJ+QJeQLkCQB5AuQJeUKeAHkCQJ5qRl4dI+/eaxM7OzudfeMA 8oQ8AdSCUuox3m0Hiy5P0s+urKwcxO15dZHqQt7XFrUsPf/88yeQJ+QJeQIoYWtra4V6gEWUp1Sa VldXdy9durRwN33kCXlCnpAnAIC5yNOiS1MmT//8933Pi/xQu+jQjzzPj8JpLWjC4yBPyBPyBADQ IXnqijTpkafQ9yJPsyfzZ+QJeUKekCcAQJ7GlqeuSZMuT3nJCSM9EhWoXnJPSFCBVYoC1c+v502y JvliETP2FzmzHlOpSMm2v6/+DfKEPCFPAAXwbjtoszy9+uqr0XXXXffBDTfc8M7x48d/Jg83mHP0 pP3KE6M22p4/nfOUClBOjAIV9XKSpEuRIU++ykRIjzz1UhEbSFkgkpTly523pyL5zebmpu8qfyyy r5uf59ra2vai5L/xxht/8+CDD75z+vTpqxrvnDp16j1j29WjR49eO3fu3JeRJ+QJYASWKoC2R55u vvnmXx45ciS8/fbb3/zSl770jO0PAGnHNuRp0jbnH04Yj0VJhur0ITvncJ5FnpSyDPW5JKvXy2EK 2fb29uMF5V81r1cigYuS/+mnn/59c9v6+vrFY8eO7dvyL/p3DXkCQJ5gSeUpnfO0ubl5Vm5yEm1Y tCUJXGRP2wWR8lSMNnk8yEeT7JGnQUTJFXmqEqEy8nZ5ztOy9YHIEwAdByy5PKV0SaL0pQqSOUvG BG/rnKfcdi+Z1+Se81Q8N6rXGx0uRJ6QJ+QJAHmCjslTlySKdZ7oA5En5AnoOADmJk82iVq0BV+R J/pA5Al5AjoOgLnLky5RyBPyRB+IPAHMHHn6x/a4L8CiyRPAhH3galff74k8AcyQnZ2dG6kHQJ6A PhB5Qp4AAJAngKUFeQIAQJ4AAHlCngAAeUKeAJAn5AkWCnmVgbyegLoA5AmWEXmdzpkzZ55FnpAn gMqwVAEgT0AfyFIFyBMAHQcgTwDIE/IEQMcByBMAfSDyhDwBHQcgT8gT0AciT8gT0HEAIE9AH4g8 tVSeWBl6uTk4ONiblrfffnv/rbfeulrHsV566aUn+VwAeQLkCXlqpTzJMVdWVg6eeeYZblZLTNSy dOXKlfN8LoA8wSIh77br6vs9kSdDmlZXV3dlfR4aPvKEPAHyBADIk0WekCawy1MY+Z4X+aHWgEI/ 8jw/CqexoAmPgTwB8gSAPDUuT0gTFMuTeI4XeZo9mT8jT4A8ASBPSyFPSBNUlae86OQjUYHqJe0p QQVWMQpUP7+eV/mSJ5YwY18RM+vxlIqUbFv/k//I5wLIEwDy1Ig8Cffcc89r+nG2trZWbrjhhqvD m5fB2traNvmbyy+fs57/woULdx86dOjaLPNHhgDlxChQUS8nSbEUBQ558lUmQ6kQ9VIJGwhZIJKU 5cmds6ci+c1XvvKV/9uW+pEnaFx5Bfk9+ZvJf911171fdCyT+++//yfcCGFWSIDC7O+RpwWVJ4k4 SeTJvCEAjESeBqIkQ3X6kJ1zOM8iT0oZQ30uwTJuaqaMMWwH0yB9HpF2mDcsVdAheUptGImCSvIU BZHyVIw2eTzIR5PskadBVMkWeSqLTlnyIk+APAHyhDw1Kk8pSBSUy9NgzpIxyds65ym33UvmNtnn PBXPi+r1RocKkSdAngB5Qp5aIU9IFFSRJ9Z5AuQJAHlCnhzoEiUro9L4kSfkCZAnAOQJeapwXOlk 6GiQJ+QJkCcA5Al5GuPFwADT0uX3OsFicfz48Z9tbW3dSl0AfSDyhDwBAAAA8oQ8AQAAAPKEPAEA AADyhDwBAAAA8oQ8AdSEvDPu8ccf/zZ1AU0jS7DIOySpC5gn8oTn6dOnX0CekCeAynT5MV1YLFiq AOgDkSfkCeg4AJAnoA9EnpAnoOMAQJ6APhB5Qp6AjgN5AuQJ6AORJ+QJAHkC5AkAeUKeauall156 8uDgYA+aQz4DOg4A5AnoA5GnBZEneZFr214uu2xp2pfpyrvA1tfXL+7s7Nw4yf7yXid5RJxOFJpG bmAsVQDzRpZrue+++15BnpAn5GmJ5En+Upc2c/jw4V9NI1EAAIA8IU+V5SmIVHzOXooKov42FQXO Uhb8PvQjz/OjMNsQ+Z4X+WFRngnTVMexXffiylMKEgUAAMjTPOSpDpEpEJrQ9yJPsyfz58bkabiv RfBmmuR8ffmsW56QKAAAQJ4akadBZEnkRKksQjOMzqSRJz16M5CPRGhiOdL3yUlOXlQCZYn+GFIU qH5+PW+S1XYuTdB6ZhnSa0mja5YyjewXmeWMjyHlCexltJ7bqCfPy67j5D/6l6/OQp6QKAAA5Gmp 5GlenD9/fmT4qh8R0uQplaKc9Ax+H6jRCJJjn6Fc6GIU79/LCYguRYaY+Gp0aM1VvkSUdPEZyE5u qNEhfuZ+4aCcOXEskCfbMXyznrLIk3wG8/is5UmmT37yk/+jav6PfOQj7yulHqMDgnnBu+2gCXi3 HZGn2USerNGVbM7TMMpSEjWKBqKlD9k5h/Msx5Boj1XUHOcyZUD55hBfdt3JNUj5bfsFZjkHkhaM ce7ArKfZD9ulHDp06Jp0DPJUnvxcNUmblbZL5wrzgqUKoAlYqgB5akSeqojPcJ9YGJQ+tyhQI0Nj o5Gngay4Ik8ugSnJax22s50jqhJ50qJegSqcfN6vp2CYf1bypEvT8IuEPAHyBIA8IU/NypOvz+1J ZSp0zwVK5g0Z57LOecpt95J5Te45TwXn0oflgiJ5yuRvZL/hkGBRebJttnNL1MyspzRP3XOebNKE PAHyBIA8IU+1yhNpvFTvk3l1RZ6KpAl5AuQJAHlCnpAn5GmAyFKZNCFPgDwBIE/IE/LUmTStPI31 RUKeAHkCQJ6QJwDkCbrByZMnX2epApg38m67U6dOfRd5Qp4AkCcAgGXv85EnAOQJAACQJ+QJkCcA AECekCdAngAAAHlCngB5ApgpTBiHJmDCOPIEgDzBwsJSBdAELFWAPAEgT4A8ASBPyBMA8gTIEwDy hDwhT4A8ASBPgDwhT8gTIE8AyBMgT8hTp+Rpb29vOyK1Ou3v7+8iT4A8ASBPyBPyRJqRPG1tbd16 +vTpF+Rf5AkWGZYqgCYQYZc+FHlCnpCnJZIn+eJLmzl06NC1MolCngAAlgfkqW55Cv3Ii8/TS1BR MA8rmOicQaSGecPI9/r7q0DfXleSY6bli1FzqZXa5CmlSKKQJwAA5Al5mkieRBK8yA81qZlKFERq ykRmnHM6jif7eH4UzrKMw+NLfq28c0n9Mv7p/v6fTSNPRRKFPAEAIE/I0yTyFCh7VCURGtWPvsS/ D31vNAqTix71twcq+9mLbcO6n+Octrz54/mDCJMeFUp/7suQnj85RIUy2s/tlqficsZ1pgZ5DcEL BtutdZK7Ji/eLyvjp9a/cWlaebJJFPIEAIA8dVaeZsX29nZyI/dsIZVEOgbRGSMylEqAPZqjRXUc +1nP6TyHHiXShudyYjLY7hLBojI6z52XGVeULMnrK0OCCuQpcFxnXPZ8nfTL+E92d2fy2cuTTMgT tBl54okJ4zBv5N1299133yvIE5GnySNP6Y1f8hg33/4u2byjLAqkiYlrP9s5C89RTZ58qwiWlNF5 7izylESK9KiZkdfz9PNqUSqbPPmu69QiUv2QWa3DdimHDx/+1fr6+sWdnZ0bkSdoMyxVAE3AUgXI UzV5Mucfyc9y8zblySZYuWiJHtXJoin2SJDlnM5J2fqQ2QSRp7IyOq/PMWznEr/SyNPgGL4qnXze j8wFSf4/+tFf/qgOedKlafhFQp4AeQJAnpCnSeTJnBfkiproN2NdZvR5Ovl5RyIt9v3s53TlzY7n F8uTbc5ThTLar0+Xp/xQ42hePbrlJZEos+z6dtt15uZBGdcyzZwnmzQhT4A8ASBPyNO08kSqMdX7 ZN6kSxUUSRPyBMgTAPKEPCFPyNMAeYquTJqQJ0CeAJAn5GlCrly5cv7g4GAP2stPf/rTZ2f2RUKe AHkCQJ6QJwDkCbrB6urqLksVwLzh3XbIEwDyBAAAyBMA8gQAAMgT8gTIEwAAIE/IEyBPAACAPCFP gDwBzIHjx4//TJbeoC5gniilVnm3HfIEgDzBQsJSBdAELFWAPAEgT4A8ASBPyBMA8gTIEwDyhDwh T4A8ASBPgDwhT8gTIE8AyBMgT8gT8vRc/514EWmsJC9hRp4AkCdAnpAn5InUMnmSm428E6zKTQd5 gjYj7xfj3XYwb6TvXFtba90fu8gT8oQ8zfiLL21GKJMo5AkAYHlAnlohT0GkPD8KhyUNI9/zIj+s clXj5C06jB95A1Ho9VRcoklSfB3DfaVc/eOpQN++mPJUJlHIEwAA8oQ8dUae5Pdl4iJyox1DREpV VR3H8eUYuWsay+QKy9ykPLkkCnkCAECeFkaennjiiffim2lUBbnByQS2NvH9739/p1CeEpFRsdwM btyDfIFKb+ReLClaXv0mHwtQlq8XeQM7Cn0vlyfO1P/XGpAy8urlGTm+P4gwBVl5hz/3ZUjPn5xy kjKv/8l/m8dnc+7cuS+75MmUKPn/qu1Q2izyBACAPDWCUuqxkydP/iJmX+e222779YkTJ/67uf3I kSO/lJn/beKb3/zmX5fKkzbkJWIRX7cmO0bUaCR6Y0RxjKhSoLz4eN5QUkaiR0ZeP8iXJx8l0obn cpGnwfYCSRunzP/YO/HOTcfv+PmsPxt5H1iZPAnyJFPcvv6D2d7uvPPOt48dO/Z35nZps9J26YBg XvBuO2joHr0a93evI08LgkQDFuUv+9JhO2P4K43AZLKjD9tl84yyqI8hIiIwxs0/L2P6aJ4lr28O x1WXJ9+3SdpkZX746e2NWX82RcN2qTQVtbMuP6YLiwVLFUATsFQB8jRjeeoLxNBf9GiTIU+FkadY MvJSlYqIFpmyRn/M6FX8s2s4L7TJU7rvBJGnCcrc9JynMmlCngB5AkCekKeZy5M598eYvG3MCcpH a1Qy7JbJiz4XKj/PKJUUfU7R8FyO84/kDUYngmfH94vlyTbnaaIy3/vekxcuPzhveaoqTcgTIE8A yBPyNA95KlpCYOKn1rqZ5h15GleakCdAngCQJ+QJeVpKeZIJttO0I+QJkCdAnpAn5GkGvPTSS08e HBzsQXVEOOk4AJAnoA9EnmpkY2PjaxcuXLibxgtNIjer9fX1i9QFNM3jjz/+7Z2dnRupC5gnEr0/ c+bMs8gTAAAAwJJDJQAAAAAgTwAAAADIEwAAAADyBAAAAIA8AQAAACBPAAAAAEAlAAAAACBPAAAA AMgTAAAAAPIEAAAAsEj8f5e2lwPgBrn2AAAAAElFTkSuQmCC --_005_BYAPR08MB4903E91A2E9FC117755443C1FAD50BYAPR08MB4903namp_-- From nobody Tue Aug 6 17:09:48 2019 Return-Path: <0100016c6968e7a2-4acac184-768f-4971-8b4f-459165f0aa4f-000000@amazonses.watsen.net> X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4E512008B; Tue, 6 Aug 2019 17:09:41 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6fagzRD6A41; Tue, 6 Aug 2019 17:09:40 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE08D12008C; Tue, 6 Aug 2019 17:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1565136578; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=UnXFNJS55Ymwpi2+3Vz5qBiJwwJt+q/MOjHmTUYaMW8=; b=bFVL8pKf5tX5VA0fb3hEoJ/1RIOkLN64zcPkGCM/jjyQzwTl/mpPIXlY6nEc4fvO t3M/svEVBDNJ4wtvUq8yq2BNISteKDDQfaPp7ndMKRrLivyx/RlAzzBkOLMvyQsSaVD lmze86h+OWaibGu2z06oiGQdAP1K4EpJT24Ox57E= From: Kent Watsen Message-ID: <0100016c6968e7a2-4acac184-768f-4971-8b4f-459165f0aa4f-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3AA43111-30A7-42A0-A294-21085464AAF1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 7 Aug 2019 00:09:38 +0000 In-Reply-To: <20190806221242.4j7eprxeklup5c3m@faui48f.informatik.uni-erlangen.de> Cc: "Owen Friel (ofriel)" , "iot-onboarding@ietf.org" , Rifaat Shekh-Yusef , "anima@ietf.org" To: Toerless Eckert References: <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@email.amazonses.com> <20190806221242.4j7eprxeklup5c3m@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.08.07-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 00:09:42 -0000 --Apple-Mail=_3AA43111-30A7-42A0-A294-21085464AAF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Toerless, > I ranted about the need to better describe the common architecture=20 > already in prior emails to the anima list. Good. =20 > Complexity is in the eye of the beholder. True, but it seems that getting a domain certificate and getting an = initial configuration are at least two distinct steps in ANIMA, whereas = they're rolled into one step with SZTP. =20 While the comparison may not apply perfectly, for a long time in = filesystems, the redundancy layer (e.g., RAID-6) and the volume = management layer were distinct, but ZFS collapsed them into one layer, = for the better. I wonder if we might not have something like that = here... > I like the modularity/flexibility that NetConf provides, but of > try to find someone who understands how to duplicate the full > enrolment process of BRSKI+EST with equivalent NetConf > supported Yang object models (especially for TA and Cert enrollment). > And then find more constrained devices that would more happily=20 > go with that more (IMHO) flexible model.=20 That paragraph didn't parse completely for me, but I get the sense that = there is an incomplete view, in both directions, for how things work. = Ideally, I would be more active in ANIMA but, I've been so busy that I = haven't had time. Perhaps we could schedule a call to go over = where/how SZTP can fit into the ANIMA model? > But given how constrained devices also do not like TLS of > BRSKI, it would be great if we could come up with a single > preferred transport to use with either server-controlle workflow > (like SZTP/Netconf) and client-side controlled (like BRSKI). Regarding TLS, SZTP depends on TLS in a soft way, other bindings could = be defined if needed. Regarding which side controls the flow, I'm unsure if SZTP is = server-controlled, at least, it is the device the initiates the = connection to the server, but perhaps you mean what I'd refer to a = post-bootstrapping steps that are needed to complete the full bringup. >> Regarding ACME integration during bootstrap, I think the basic desire = is to configure a device to obtain a certificate via ACME, configuration = which so happens to be provided at the time of the bootstrap event, but = could also happen at anytime thereafter. Support for such = configuration should be added to = https://tools.ietf.org/html/draft-ietf-netconf-keystore = . =20 >=20 > I think what you say is not specific to ACME but true for any RA<->CA = protocol. Yes. > The fact that NetConf/SZTP allows to enrol the certificate any time = later > is a key difference. I think architecturally, you want to make it as > soon as possible, but for example you may still want to first do > some additional attestation before the key enrollment. This is where > BRSKI+EST is a lot less flexible in design, but given how i think > there is no model for attestation in IETF, its hard t make the point = now. I'm quasi-working with Henk on RATS... > The only ACME specific thing i can think of are the mechanisms for the > RA to prove to the CA posession of a domain-name/prefix. That i think > is independent of the key-store. More related to the ability of the > RA to create DNS entries. No idea if there is a yang model for that > (would be nice). The keystore relation here is threefold: 1) when shipped from manufacturing, the keystore may be pre-populated with the device's, e.g., TPM-protected asymmetric key and = associated IDevID certificate. 2) when deployed, an alternate LDevID certificate may be configured in the keystore. 3) ACME or equivalent could be used to auto-update certificates as needed (the keystore model doesn't support this yet) I'm not aware of a YANG model to configure a DNS server as of yet. Kent --Apple-Mail=_3AA43111-30A7-42A0-A294-21085464AAF1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Toerless,


I ranted about = the need to better describe the common architecture
already= in prior emails to the anima list.

Good. =  


Complexity is = in the eye of the beholder.

True, = but it seems that getting a domain certificate and getting an initial = configuration are at least two distinct steps in ANIMA, whereas they're = rolled into one step with SZTP.   

While the comparison may not apply perfectly, for = a long time in filesystems, the redundancy layer (e.g., RAID-6) and the = volume management layer were distinct, but ZFS collapsed them into one = layer, for the better.  I wonder if we might not have something = like that here...


I like the modularity/flexibility that NetConf provides, but = of
try to find someone who understands how to duplicate = the full
enrolment process of BRSKI+EST with equivalent = NetConf
supported Yang object models (especially for TA = and Cert enrollment).
And then find more constrained = devices that would more happily
go with that more (IMHO) = flexible model.

That paragraph didn't parse completely for me, but = I get the sense that there is an incomplete view, in both directions, = for how things work.   Ideally, I would be more active in ANIMA = but, I've been so busy that I haven't had time.   Perhaps we could = schedule a call to go over where/how SZTP can fit into the ANIMA = model?


But given how constrained devices also do not like TLS of
BRSKI, it would be great if we could come up with a single
preferred transport to use with either server-controlle = workflow
(like SZTP/Netconf) and  client-side = controlled (like BRSKI).

Regarding TLS, SZTP depends on TLS in a soft way, = other bindings could be defined if needed.

Regarding which side controls the flow, I'm unsure = if SZTP is server-controlled, at least, it is the device the initiates = the connection to the server, but perhaps you mean what I'd refer to a = post-bootstrapping steps that are needed to complete the full = bringup.


Regarding ACME integration during bootstrap, I = think the basic desire is to configure a device to obtain a certificate = via ACME, configuration which so happens to be provided at the time of = the bootstrap event, but could also happen at anytime thereafter. =   Support for such configuration should be added to https://tools.ietf.org/html/draft-ietf-netconf-keystore = <https://tools.ietf.org/html/draft-ietf-netconf-keystore>= .   

I think what = you say is not specific to ACME but true for any RA<->CA = protocol.

Yes.


The fact that NetConf/SZTP allows to enrol the certificate = any time later
is a key difference. I think = architecturally, you want to make it as
soon as possible, = but for example you may still want to first do
some = additional attestation before the key enrollment. This is where
BRSKI+EST is a lot less flexible in design, but given how i = think
there is no model for attestation in IETF, its hard = t make the point now.

I'm quasi-working with Henk on = RATS...


The only ACME = specific thing i can think of are the mechanisms for the
RA = to prove to the CA posession of a domain-name/prefix. That i think
is independent of the key-store. More related to the ability = of the
RA to create DNS entries. No idea if there is a = yang model for that
(would be nice).


The keystore relation here is = threefold:

  1) when shipped = from manufacturing, the keystore may be pre-populated
  =     with the device's, e.g., TPM-protected asymmetric key and = associated
      IDevID = certificate.

  2) when = deployed, an alternate LDevID certificate may be configured = in
      the keystore.

  3) ACME or equivalent could be used to = auto-update certificates as
      needed (the = keystore model doesn't support this yet)


I'm not aware of a YANG = model to configure a DNS server as of yet.


Kent


= --Apple-Mail=_3AA43111-30A7-42A0-A294-21085464AAF1-- From nobody Tue Aug 6 19:28:43 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64C5120091 for ; Tue, 6 Aug 2019 19:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 QE7j5K1ZMw8z for ; Tue, 6 Aug 2019 19:28:38 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 5DE5312000E for ; Tue, 6 Aug 2019 19:28:38 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id m9so38500342pls.8 for ; Tue, 06 Aug 2019 19:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ik3j6PXFqxUBQwuvzr+jHwcEPC5rwL+jqAtLuW0uJl4=; b=sB2h1hUUl5irM8/fCLkTaBRg/bUf4xomC/ErOYH9tv8L/UB72UKLpIq6X7T085btP1 +FbveBe2nQ0SKcNcOYNLtpsJBRkPyTQEdlMq6QB99n48F3Rx4CW7acyUQoohvtJeDDnV 5Kq9VOUW2RvIyhSxtrLWjy/jrHNp7Qc6/bPM/vPCWWX82M0K2nDnF31Dyd9teZonlasw tLseEYcRrmuF474nYM1+5ze51FRVfmKq2PgObead9nYwTHxQJ0nWKtLMBfejyQutdcl7 WNbYa1XgiykaUX2hgy3LhtKjH5a2vzNhgRsJcXy0XNwZychZHpmh1rSLrZdaLHMiaygL 4Cwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ik3j6PXFqxUBQwuvzr+jHwcEPC5rwL+jqAtLuW0uJl4=; b=a03D4DFvoFWkMCE732wAe3PHUe64Gdc30LD+mgHiZBajQU3JS9M0H0v86cSvQqYdmD u91KSyh22Hc2lKCqwXuciHb1ddHk4x5wzscM3xmPdKMl+PeJi8AI/B2Jer6I18VmKUjy ni7ee2E4jCJ1VlklZX8mrWsbvfDVwp1x18qww3R+uSGZzRg3z/DFarQCe6mkNjjHypXl PUPD1erLH3yqUYfnqCFx1m9BXZAukb+9NgybQTbuBa4nPJQ1Q7oZJYGZxf9N1UPDET9i IwMD2PP5MNrQkHNPoSb9/RnufPMWX/1ernqAFLbJal8MQcJwL6AGd+ZcP+Et64bTV+1c hIlA== X-Gm-Message-State: APjAAAUBB5TiTLRpefrrw0EXaTG88DcW1Zj90Ozm1pquOxvHr0o0azMf rVUFxLShGheqh+W99tgSxBQIvUSwG9w= X-Google-Smtp-Source: APXvYqy/l5LUVwice/LIh7jz5UkWcdHdCjzf+8jtYhFt/PMqXEV3JfpiwdyvySXsmeLzInUnu0Lgzg== X-Received: by 2002:a17:902:4683:: with SMTP id p3mr5574027pld.31.1565144917496; Tue, 06 Aug 2019 19:28:37 -0700 (PDT) Received: from [130.216.36.184] (sc-cs-567-laptop.uoa.auckland.ac.nz. [130.216.36.184]) by smtp.gmail.com with ESMTPSA id u6sm20924456pjx.23.2019.08.06.19.28.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Aug 2019 19:28:36 -0700 (PDT) To: Michael Richardson , "anima@ietf.org" References: <5523.1565112243@localhost> From: Brian E Carpenter Message-ID: <17032fd8-b316-6225-5ddd-cdfc9c1ce2ea@gmail.com> Date: Wed, 7 Aug 2019 14:28:31 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <5523.1565112243@localhost> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] comments on draft-ietf-anima-grasp-api X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 02:28:41 -0000 Thanks very much Michael. Some partial responses below. On 07-Aug-19 05:24, Michael Richardson wrote: > > I read draft-ietf-anima-grasp-api from the expired drafts list. Right, the -03 draft expired while we were in Montreal. Our plan is to make the next update after the two promised reviews arrive. > I think that the event-loop architecture is different than a > polling architecture. I agree that given an event-loop architecture, > that one can build a polled architecture, but the converse is not true. > The event-loop mechanism needs something to send events, while the polling > system does not. My understanding is limited, but the diagram at https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/ seems to say something different: the loop detects events by polling. (Yes, OK, that's talking about Javascript but the fundamentals are the same, surely?) > section 2.3.1.3: > If you are going to insert C structures, why not use a real example? > https://github.com/PJK/libcbor/blob/master/src/cbor/data.h#L164 > cbor_value -> cbor_item_t Yes, we can look at that. There are various CBOR libraries in C. > I don't understand what the asa_nonce is for. OK, then we need more text. > Is this something that the underlying GRASP library is supposed to use > internally to sort out which ASA is which? Maybe this should be > either a UUID, or an opaque type, which might in some cases, be a file > handle, or contain one. (a la FILE *) Yes, it should probably be opaque. In fact the documentation of the concrete Python API says so: "Note - the ASA must store the asa_nonce (an opaque Python object) and use it in every subsequent GRASP call." > > 2.3.3 Discovery. > 1) I would prefer to be able to ask for the list of cached > locators for an objective directly. OK, I can see that might be useful. > 2) Rather than flush them explicitely (because there might be > other ASAs depending upon them), I'd like to do a discovery > that asks for objectives that are at at most X miliseconds old. > Flush is therefore X=0. Hmm. I think we assumed you would only flush if you had reason to believe they were stale. But certainly adding an age limit seems reasonable. > 3) In both threaded and event-loop situations, I'd like to be able > have a function called when there are new answers, otherwise, > I have to poll. Right, that's a callback in event loop terminology. It's a matter of preference; I have an aversion to side effects so I don't like callbacks. However, you're probably right that it should be an option. > (And, if a function is called, then the question as to which > thread does the calling is important; specifically one needs > to know which other functions one call at that point > answer may well be none. The answer depends upon how locking > of structures is done. The answer is easier in event-loop > version) Yes; callbacks are a Bad Idea in a multithreaded version. > 2.3.4 Negotiation. > Since the session_nonce is returned by the function, how > can the dryrun/run ever be mixed in a single session? maybe > I don't know what a session is. > Ah, it's a value/result parameters. So, please put it into > the input section too. OK will think about that. > > listen_negotiate. > I think that this call is wrong in both threaded and event-loop > use. I think that in threaded version, I really want a new > thread spawned off that does the right things (negotiate_wait, etc.), You do need a new thread. But I don't have time right now to explain how that works in my example use cases. And my explanation would be Pythonesque. > so I want to provide a function for that thread to run the negotiation. > In event-loop, I think that I want the same thing, but in the > function, I can't do synchronous calls, so the function has to > be called each time. Sure. You have to insert a new event in the loop for each new negotiation. > negotiate_step: > It says: > Threaded implementation: Called in the same thread as > the preceding 'request_negotiate' or 'listen_negotiate', with the > same value of 'session_nonce'. > but if it's in the same thread as listen_negotiate(), then I can > only handle negotiation with a single peer in that thread, I think? Yes. Threads galore. A new thread for each new negotiation. > and I don't think I'd want to call listen_negotiate() for the > same objective. Actually that will depend on the use case, but if you do so, you need locks and atomicity. I put all of that into the prefix assignment demo, I think. https://github.com/becarpenter/graspy/blob/master/pfxm3.py > negotiate_wait: no idea why I'd use this. That simply refelects a GRASP feature: tell the other end to wait longer. > > Summary: I do not object to this document going forward as Informational, as > it represents an explanation of one implementation, and that is > what Informational is about. All the same, I'd like to capture as much generality as possible. > It would be nice to have the view of multiple implementators, but > there is no energy for that. Yes, that's what we need. Regards Brian > While I do not object, I do not see great utility in this document. > > nits: > 2.3.1.3: s/neg/negotiate/ > I found the "NEG" term in GRASP confusing, because it seems like > NEGative, rather then NEGotiate. I'd prefer it was spelt out in > the API. > s/dry/dryrun/ > > > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > From nobody Wed Aug 7 00:33:32 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 640601201FA; Wed, 7 Aug 2019 00:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.49 X-Spam-Level: X-Spam-Status: No, score=-14.49 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5l5ZqZae1KMw; Wed, 7 Aug 2019 00:33:26 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F011120043; Wed, 7 Aug 2019 00:33:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43910; q=dns/txt; s=iport; t=1565163205; x=1566372805; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=czWOeU+n4n3exT5wvmljlMLtdUd6zkvVCPHULUEeNpA=; b=eYfSz+YEi7ZFSTE2ZGu/WEFzrB98L0mFr0gFJ0VPvjo/J/uAdHE/3sbb qN0BFjj4Xnb76xESxOgedJwPz3nXO1W3N4p3CNVxV3UeEQvM7BnU8UydM LJ0QUyPEXP0bwU8cutga7GHF7zhA1zuCwNol/92NLhF+R84COAS1I+m8Y g=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAABkfkpd/xbLJq1dCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVMEAQEBAQELAYEVU4EcUQEyKoQeiBxgiFqHN5FSFIF?= =?us-ascii?q?nAgcBAQEJAwEBGAEKDAEBhD8CgmI0CQ4BBAEBBAEBAgEGbYUnDIVKAQEBAQI?= =?us-ascii?q?BAQEhSAMLBQcECxEEAQEBIAEGAwICJx8JCAYKCYMiAYF7Dw+qBoEyhUmEcwo?= =?us-ascii?q?GgTQBgVCKKYF/gREnH4FOfj6CYQEBAoEjEhMBTIJVMoImBIwNIBqIRpYdCYI?= =?us-ascii?q?egh+BDpB0G4IvhyyDa4ZQhBeefIMygw4CBAYFAhWBUDgqgS4zGggbFTsqAYJ?= =?us-ascii?q?BPoENiXyFQT0DMAEBi14rgiUBAQ?= X-IronPort-AV: E=Sophos;i="5.64,356,1559520000"; d="asc'?scan'208,217";a="15180434" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Aug 2019 07:33:22 +0000 Received: from [10.61.221.4] ([10.61.221.4]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x777XLTj001409 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Aug 2019 07:33:21 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_670022E0-FBEC-4F9F-B0B7-714E175AD8B6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 7 Aug 2019 09:33:19 +0200 In-Reply-To: Cc: Toerless Eckert , "iot-onboarding@ietf.org" , "anima@ietf.org" To: "Randy Armstrong (OPC)" References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <20190806223052.md5lp6yeleuvuf5l@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.221.4, [10.61.221.4] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Anima] [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 07:33:31 -0000 --Apple-Mail=_670022E0-FBEC-4F9F-B0B7-714E175AD8B6 Content-Type: multipart/alternative; boundary="Apple-Mail=_2FBD00A8-C190-44C7-8422-61DE740C7548" --Apple-Mail=_2FBD00A8-C190-44C7-8422-61DE740C7548 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Randy, Thanks. We have irregular calls, but I will poll for one in the 3rd = week of August to discuss your use case. In an OPC UA environment, might one expect that the join registrar and = the certificate manager be co-resident? This would be where EST/SCEP = would happen (BRSKI can be viewed as an extension to EST - RFC 7030). = There is no "push mode" for EST. However, my understanding is that the = same capability roughly speaking resides in CIP. My bigger question is whether you want to use all of this for network = authentication to avoid unauthorized devices joining the network in the = first place, or whether this is intended solely for application = authentication. Eliot > On 7 Aug 2019, at 01:19, Randy Armstrong (OPC) = wrote: >=20 > Push should be =E2=80=9CCertificate Manager initiated=E2=80=9D >=20 > From: Iot-onboarding > On Behalf Of Randy Armstrong = (OPC) > Sent: August 6, 2019 4:17 PM > To: Toerless Eckert > > Cc: iot-onboarding@ietf.org ; = anima@ietf.org ; Eliot Lear > > Subject: Re: [Iot-onboarding] OPC and BRSKI >=20 > Hi >=20 > 1) Sure, need to understand how TCP UA works wih the minimum amount of = message authentication to allow for BRSKI. Main challenge may be the = need for pledges to receive messages from registrar that are = authenticated by the registar, but where the pledge has to wait until it = can actually perform the authentication later. Depending on how you = built TCP UA message layer authentication this may be piece of cake / = free or not. >=20 > It would be easy to drop in a OPC UA aware registrar and implement all = of the BRKSI flows back to the MASA. The only nuisance factor is the = 'prior-signed-voucher-request'.. If MASA's are willing allow this field = to be omitted and to trust the Registrar then nothing more needs to = done. If MASA's need this field then we could get it from the Device via = OPC UA but producing the CMS message adds an additional burden on low = end devices (i.e. the need to pull in libraries that provide the same = functionality as OPC UA but do it in different format). >=20 > The 2 modes of operation with a OPC UA aware registrar (the = Certificate Manager is an OPC UA defined entity). >=20 > Pull (device initiated) >=20 > >=20 > Push (Registrar initiated) >=20 > >=20 > Regards, >=20 > Randy >=20 > -----Original Message----- > From: Toerless Eckert > > Sent: August 6, 2019 3:31 PM > To: Randy Armstrong (OPC) > > Cc: Eliot Lear >; = iot-onboarding@ietf.org ; anima@ietf.org = > Subject: Re: [Iot-onboarding] OPC and BRSKI >=20 > On Tue, Aug 06, 2019 at 09:32:45PM +0000, Randy Armstrong (OPC) wrote: > > OPC is layered to separate the application from the choice of = network protocol. TLS/WebSockets is an option but the primary protocol = that will be used by low end devices is UA TCP which provides complete = message based security framework. These devices do not need TLS to have = security and requiring it would require duplication of code. >=20 > Sure, need to understand how TCP UA works wih the minimum amount of = message authentication to allow for BRSKI. Main challenge may be the = need for pledges to receive messages from registrar that are = authenticated by the registar, but where the pledge has to wait until it = can actually perform the authentication later. Depending on how you = built TCP UA message layer authentication this may be piece of cake / = free or not. >=20 > > 2) At some point, the thing decides which part gets an IP address or = at least is responsible for the phy. Can that process be leveraged to = establish identity? > > > > Machines may have a separate network for internal Devices which IPs = assigned by the machine???s DHCP service. Some of these devices may = interact with external equipment via a NAT router which assigns a unique = port to each device. This means the individual Devices need to be = granted access to the operators network when the machine is installed = even though the operator cannot provide them with IPs. > > > > I need to consult with our machine experts to better explain this = use case. >=20 > Primary questions seem to be whether this is just about authentication = at the TCP UA layer or further below at some implied NAC mechanism. >=20 > > 3) One possible view here is that the MASA may be offline, and may = have provided a voucher via offline means to the join registrar. This = of course would be nonceless with a lengthy expiry time. In addition, I = posited during BRSKI???s review that perhaps the device should be able = to generate its own certificate via a higher level interface. > > > > OPC already has APIs needed to manage Certificates on a Device. The = link to something like the MASA is what we are missing. Nonceless = vouchers that do not expire should allow local registrar to emulate a = MASA when the MASA is no longer available. I wanted to make sure that = this mode of operation is allowed BRSKI. >=20 > Yes it is, it may just not be fully specified in the current targeted = BRSKI RFC that we feel everybody who wants to implement it has = everything to do so, but thats would just be subjet to future small RFC = to close any possible gaps. >=20 > > 4) Can you say more about what mechanisms OPC is interested in = pursuing? > > > > With OPC we assume that network selection and IP assignment are out = of scope. Wired devices are the primary market at this time but 5G could = change that. >=20 > BRSKI also does not care about Addressing. Only ACP does, so you can = ignore that part if you're not interested in. We have tried to separate = out ACP specific aspects in the BRSKI document as good as possible with = the somewhat convoluted process we had in the IETF how to drive those = documents. >=20 > Cheers > Toerless >=20 > > Regards, > > > > Randy > > > > From: Eliot Lear > > > Sent: August 6, 2019 1:47 PM > > To: Randy Armstrong (OPC) > > > Cc: iot-onboarding@ietf.org > > Subject: Re: [Iot-onboarding] OPC and BRSKI > > > > Hi Randy, > > > > Thanks for this. It???s a great starting point. I would propose = that we do a call so we can get some high bandwidth discussion going. = Please now see below. > > > > > > On 6 Aug 2019, at 20:58, Randy Armstrong (OPC) = >> wrote: > > > > I will start with the main trouble spots. Some of these may be = already covered by BRKSI but I missed the implications of some of the = text: > > > > 1) Low end devices that only support OPC; this means no TLS client > > capabilities and no ability to initiate network communication (i.e. > > server only mode); > > > > > > How does OPC handle such devices? I think this is also coming up = elsewhere. One question is whether TLS is required. Without TLS one = does lose confidentiality, but so long as the client can sign the = request, maybe that???s all you use. > > > > > > > > 2) Machine builders that combine devices into a machine that is sold = as a unit. These device still have a unique network identity but the = effective manufacturer has changed; How to deal with the DeviceID? > > > > > > At some point, the thing decides which part gets an IP address or at = least is responsible for the phy. Can that process be leveraged to = establish identity? > > > > > > > > > > 3) Devices may be reset to factory defaults and sold/transferred to = another organization. This needs to be possible even if the MASA is no = longer available (i.e. the original manufacturer has gone out of = business). > > > > One possible view here is that the MASA may be offline, and may have = provided a voucher via offline means to the join registrar. This of = course would be nonceless with a lengthy expiry time. In addition, I = posited during BRSKI???s review that perhaps the device should be able = to generate its own certificate via a higher level interface. > > > > > > > > 4) Offline operation is the norm with pre-issued vouchers delivered = out of band. The pre-issued vouchers will need to have reasonably long = lifetime (i.e. years not hours). > > > > The lifecycle of a device is shown in the following diagram. The > > expectation is we would need to add links to the MASA at each step = in > > the lifetime > > > > > > Thank you for that. For wired it seems to me that a permissive MASA = model (logging only) could provide you a way forward. For wireless, = this is not an option because proper network selection needs to occur. = Another question is whether we need another mechanism is necessary to = validate the voucher (aka, a PSK w/ proof of knowledge, or DPP, etc). > > > > Can you say more about what mechanisms OPC is interested in = pursuing? > > > > Eliot > > >=20 > > -- > > Iot-onboarding mailing list > > Iot-onboarding@ietf.org > > https://www.ietf.org/mailman/listinfo/iot-onboarding = >=20 >=20 > -- > --- > tte@cs.fau.de --Apple-Mail=_2FBD00A8-C190-44C7-8422-61DE740C7548 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Randy,

Thanks.  We have irregular calls, but I will poll for = one in the 3rd week of August to discuss your use case.

In an OPC UA = environment, might one expect that the join registrar and the = certificate manager be co-resident?  This would be where EST/SCEP = would happen (BRSKI can be viewed as an extension to EST - RFC 7030). =  There is no "push mode" for EST.  However, my understanding = is that the same capability roughly speaking resides in CIP.

My bigger question is = whether you want to use all of this for network authentication to avoid = unauthorized devices joining the network in the first place, or whether = this is intended solely for application authentication.

Eliot


On 7 Aug = 2019, at 01:19, Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org> wrote:

Push = should be =E2=80=9CCertificate Manager initiated=E2=80=9D
 
From: Iot-onboarding <iot-onboarding-bounces@ietf.org> On Behalf = Of Randy Armstrong = (OPC)
Sent: August 6, 2019 4:17 PM
To: Toerless Eckert <tte@cs.fau.de>
Cc: iot-onboarding@ietf.org; anima@ietf.org; Eliot Lear = <lear@cisco.com>
Subject: Re: [Iot-onboarding] OPC = and BRSKI
 
Hi 
 
1) Sure, = need to understand how TCP UA works wih the minimum amount of message = authentication to allow for BRSKI. Main challenge may be the need for = pledges to receive messages from registrar that are authenticated by the = registar, but where the pledge has to wait until it can actually perform = the authentication later. Depending on how you built TCP UA message = layer authentication this may be piece of cake / free or not.
 
It = would be easy to drop in a OPC UA aware registrar and implement all of = the BRKSI flows back to the MASA. The only nuisance factor is the = 'prior-signed-voucher-request'.. If MASA's are willing allow this field = to be omitted and to trust the Registrar then nothing more needs to = done. If MASA's need this field then we could get it from the Device via = OPC UA but producing the CMS message adds an additional burden on low = end devices (i.e. the need to pull in libraries that provide the same = functionality as OPC UA but do it in different format).
 
The 2 = modes of operation with a OPC UA aware registrar (the Certificate = Manager is an OPC UA defined entity).
 
Pull (device initiated)
 
<image005.png>
 
Push = (Registrar initiated)
 
<image006.png>
 
Regards,
 
Randy
 
-----Original Message-----
From: Toerless Eckert <tte@cs.fau.de> 
Sent: August = 6, 2019 3:31 PM
To: Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org>
Cc: = Eliot Lear <lear@cisco.com>; iot-onboarding@ietf.org; anima@ietf.org
Subject: Re: [Iot-onboarding] OPC and BRSKI
 
On Tue, = Aug 06, 2019 at 09:32:45PM +0000, Randy Armstrong (OPC) wrote:
> OPC = is layered to separate the application from the choice of network = protocol. TLS/WebSockets is an option but the primary protocol that will = be used by low end devices is UA TCP which provides complete message = based security framework.  These devices do not need TLS to have = security and requiring it would require duplication of code.
 
Sure, = need to understand how TCP UA works wih the minimum amount of message = authentication to allow for BRSKI. Main challenge may be the need for = pledges to receive messages from registrar that are authenticated by the = registar, but where the pledge has to wait until it can actually perform = the authentication later. Depending on how you built TCP UA message = layer authentication this may be piece of cake / free or not.
 
> 2) = At some point, the thing decides which part gets an IP address or at = least is responsible for the phy.  Can that process be leveraged to = establish identity?
> 
> = Machines may have a separate network for internal Devices which IPs = assigned by the machine???s DHCP service. Some of these devices may = interact with external equipment via a NAT router which assigns a unique = port to each device. This means the individual Devices need to be = granted access to the operators network when the machine is installed = even though the operator cannot provide them with IPs.
> 
> I = need to consult with our machine experts to better explain this use = case.
 
Primary = questions seem to be whether this is just about authentication at the = TCP UA layer or further below at some implied NAC mechanism.
 
> 3) = One possible view here is that the MASA may be offline, and may have = provided a voucher via offline means to the join registrar.  This = of course would be nonceless with a lengthy expiry time.  In = addition, I posited during BRSKI???s review that perhaps the device = should be able to generate its own certificate via a higher level = interface.
> 
> OPC = already has APIs needed to manage Certificates on a Device. The link to = something like the MASA is what we are missing. Nonceless vouchers that = do not expire should allow local registrar to emulate a MASA when the = MASA is no longer available. I wanted to make sure that this mode of = operation is allowed BRSKI.
 
Yes it is, it may just not be fully = specified in the current targeted BRSKI RFC that we feel everybody who = wants to implement it has everything to do so, but thats would just be = subjet to future small RFC to close any possible gaps.
 
> 4) = Can you say more about what mechanisms OPC is interested in = pursuing?
> 
> With = OPC we assume that network selection and IP assignment are out of scope. = Wired devices are the primary market at this time but 5G could change = that.
 
BRSKI = also does not care about Addressing. Only ACP does, so you can ignore = that part if you're not interested in. We have tried to separate out ACP = specific aspects in the BRSKI document as good as possible with the = somewhat convoluted process we had in the IETF how to drive those = documents.
 
Cheers
    Toerless
 
> Regards,
> 
> = Randy
> 
> = From: Eliot Lear <lear@cisco..com>
> Sent: August 6, 2019 1:47 PM
> To: = Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org>
> = Cc: iot-onboarding@ietf.org
> = Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> Hi = Randy,
> 
> = Thanks for this.  It???s a great starting point.  I would = propose that we do a call so we can get some high bandwidth discussion = going.  Please now see below.
> 
> 
> On 6 = Aug 2019, at 20:58, Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org<mailto:randy.armstrong@opc= foundation.org>> wrote:
> 
> I = will start with the main trouble spots. Some of these may be already = covered by BRKSI but I missed the implications of some of the text:
> 
> 1) = Low end devices that only support OPC; this means no TLS client
> = capabilities and no ability to initiate network communication (i.e.
> = server only mode);
> 
> 
> How = does OPC handle such devices?  I think this is also coming up = elsewhere.  One question is whether TLS is required.  Without = TLS one does lose confidentiality, but so long as the client can sign = the request, maybe that???s all you use.
> 
> 
> 
> 2) = Machine builders that combine devices into a machine that is sold as a = unit. These device still have a unique network identity but the = effective manufacturer has changed; How to deal with the DeviceID?
> 
> 
> At = some point, the thing decides which part gets an IP address or at least = is responsible for the phy.  Can that process be leveraged to = establish identity?
> 
> 
> 
> 
> 3) = Devices may be reset to factory defaults and sold/transferred to another = organization. This needs to be possible even if the MASA is no longer = available (i.e. the original manufacturer has gone out of business).
> 
> One = possible view here is that the MASA may be offline, and may have = provided a voucher via offline means to the join registrar.  This = of course would be nonceless with a lengthy expiry time.  In = addition, I posited during BRSKI???s review that perhaps the device = should be able to generate its own certificate via a higher level = interface.
> 
> 
> 
> 4) = Offline operation is the norm with pre-issued vouchers delivered out of = band. The pre-issued vouchers will need to have reasonably long lifetime = (i.e. years not hours).
> 
> The = lifecycle of a device is shown in the following diagram. The
> = expectation is we would need to add links to the MASA at each step = in
> the = lifetime
> 
> 
> = Thank you for that.  For wired it seems to me that a permissive = MASA model (logging only) could provide you a way forward.  For = wireless, this is not an option because proper network selection needs = to occur.  Another question is whether we need another mechanism is = necessary to validate the voucher (aka, a PSK w/ proof of knowledge, or = DPP, etc).
> 
> Can = you say more about what mechanisms OPC is interested in pursuing?
> 
> = Eliot
> 
 
> = --
> = Iot-onboarding mailing list
> Iot-onboarding@ietf.org
> https://www.ietf.org/mailman/listinfo/iot-onboarding=
 
 
-- 
---
tte@cs.fau.de
= --Apple-Mail=_2FBD00A8-C190-44C7-8422-61DE740C7548-- --Apple-Mail=_670022E0-FBEC-4F9F-B0B7-714E175AD8B6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXUp+vwAKCRBugA9nE248 uMCrAJ4jHRlMaRmDRc/rBrAVZn6e1aHDkgCfU0hGr4/Vd8Lemp0DySDiz2VLrRE= =Cr4j -----END PGP SIGNATURE----- --Apple-Mail=_670022E0-FBEC-4F9F-B0B7-714E175AD8B6-- From nobody Wed Aug 7 01:32:50 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19143120303; Wed, 7 Aug 2019 01:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=opcfoundation.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 4FbBWmwqWbO8; Wed, 7 Aug 2019 01:32:37 -0700 (PDT) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700043.outbound.protection.outlook.com [40.107.70.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 898C8120043; Wed, 7 Aug 2019 01:32:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZxHO3TsfNA1H0wsHicetw1INhNaWM63ZTnmCtTHgHwBcmfLfmoQXNNbciiiIrS+NCr5DBff6LRKaZhydlPmhaJtxFDkggaL0XXQ5RcolHsAjEMcFs6kt6KNSJ2nFYhng0iE1x0D9VMm1to6La9UaR8JgwxeilbOq5qpFm3E82HJRRvTsIh5ofiFpgqb5aqs6yxAumBK5Y40iKDxMdaIioPGR4mFCxAbdtYVshA6j4yTPTVZLAbuJJ0DYfIT/t+BqB68HcevDOoRWUKpH7TrSSppof5HwjaYrzeU7ho+2FZ/rQMipsAoeo5YpzssGwsScipY/iY6U3ffo3mnNh4QWLA== 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=2oo5M7Qfo7F/Yr0Fz6BN0YJoOurHYttI36s8bG4FXUw=; b=KGEvdAPrqKBoDu3Rz/Vl0WOZFezqvM+/A6cb7o5QbYNMvDzK6mQslXDMtOwv4bufDfDHyne5gYvco04TEwoIKiOD9pBg15IjcssogF/2QL2HCdxqZVMo+WdPSSm2zU3bloVkkl7IgNj177c7f1uuBiKLxZxNDINO7Iq0QtzJGHvyZ2ZmEvXyMTfA1rzWMYhh732+iccpWouXGq3VBdzhFTncmG6cYwE9tTV3owcddqj2l+eV9oWWlKGw/RgIxVVu7g6McmcM4OLRpeWeoSCuwLfufIMeBZBNoIq1nnlBc0soC/LxnR5TnNX4UdYcxXdOLYq3vKJw0j3LQq8mtZQClQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=opcfoundation.org;dmarc=pass action=none header.from=opcfoundation.org;dkim=pass header.d=opcfoundation.org;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opcfoundation.onmicrosoft.com; s=selector1-opcfoundation-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2oo5M7Qfo7F/Yr0Fz6BN0YJoOurHYttI36s8bG4FXUw=; b=icXGAYBVodou1Ix6HiSTaNTGZSn/DM56BOp12wolk8rcLP8BuZn5B0gFyUBxVk5iXvR1G+xwmARCI28PbT5F/dQOYgtmhNo22HGufqK/K0yYGc+UbQvKPrdtyZLs6bdCdiH14tAKHl8Ym2JMVXCKXj/ZhRTBR9ZIpth8/DciZJk= Received: from BYAPR08MB4903.namprd08.prod.outlook.com (20.176.255.96) by BYAPR08MB3877.namprd08.prod.outlook.com (52.135.193.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.17; Wed, 7 Aug 2019 08:32:34 +0000 Received: from BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53]) by BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53%4]) with mapi id 15.20.2157.015; Wed, 7 Aug 2019 08:32:34 +0000 From: "Randy Armstrong (OPC)" To: Eliot Lear CC: Toerless Eckert , "iot-onboarding@ietf.org" , "anima@ietf.org" Thread-Topic: [Iot-onboarding] OPC and BRSKI Thread-Index: AdVMZzs5EDHMP+c/QWCVcWuK34MU/QAGrJ8AAADfarAABKcngAAAO+sQAANovwAAARHHUAAAmp+QABFFfIAAAX6+0A== Date: Wed, 7 Aug 2019 08:32:33 +0000 Message-ID: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <20190806223052.md5lp6yeleuvuf5l@faui48f.informatik.uni-erlangen.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=randy.armstrong@opcfoundation.org; x-originating-ip: [24.80.80.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 64b3c915-58a2-4483-3119-08d71b11cbb4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR08MB3877; x-ms-traffictypediagnostic: BYAPR08MB3877: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2887; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(136003)(346002)(366004)(39840400004)(189003)(199004)(13464003)(3846002)(76176011)(26005)(6916009)(66066001)(33656002)(4326008)(186003)(14444005)(66446008)(446003)(476003)(74316002)(11346002)(14454004)(966005)(64756008)(790700001)(486006)(6116002)(5660300002)(66476007)(6246003)(66574012)(76116006)(2906002)(52536014)(256004)(66946007)(66556008)(86362001)(71200400001)(236005)(53936002)(508600001)(8936002)(8676002)(316002)(229853002)(6436002)(9326002)(81166006)(81156014)(7736002)(9686003)(54906003)(25786009)(54896002)(55016002)(68736007)(71190400001)(102836004)(6306002)(53546011)(6506007)(99286004)(7696005)(606006); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR08MB3877; H:BYAPR08MB4903.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: opcfoundation.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: CvT2JWEFRekxtlTAmHpSg+oS1lL5RhQypTbU6juTMI1g58sWGAnf28hSmHknEe8RCwKDRG0Gzz5XAPi2DgKsd38n7nTE97FxuR8UuB9QMu3NYkDoGD0I85ka7b05SXhOApPvXZUhpNSwMwzUo9d2qRBepVGta/q1u2WoVmi6RAXTLH97KhQ7oBvIwjgkkYMlFQj8Wh7xRdKh5370SeB1e3MF6Xt9sIXtq5M3Wnz9p/uS17d4GUR5ADILLRAV+Nnc0NZpBLQz9yAXt6iVXmRRryEZ6JbGuxmnxMGtKqz/8XrOF/U6EoZlHKMRpVAybE2+nZad5Kgfe8Yv84hYbu8nnyoH/3fuWecGFSTWpSDQ7BASE+CtuDe1ERtOqo0dWX96CKnU1aZljDwy3Pg+X1OJk5QMdBy+gsQIoZc9FVZWWfw= Content-Type: multipart/alternative; boundary="_000_BYAPR08MB4903C95973435BA06FC3C080FAD40BYAPR08MB4903namp_" MIME-Version: 1.0 X-OriginatorOrg: opcfoundation.org X-MS-Exchange-CrossTenant-Network-Message-Id: 64b3c915-58a2-4483-3119-08d71b11cbb4 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2019 08:32:33.7624 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2d8ef4e4-d41c-489c-8004-bb99304b60fe X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Sbg3DTl9H4S4pBCPOkrX0PbMfIJaasB2+924KBkE9CqbrJeJ5knZWMDrdecKyQdeNg8qvjU79gbsnv0i0cukxz4QW5B+s60SerpIOh7dHV9s0N8Tdw/uVHOcNYIvq2Ok X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB3877 Archived-At: Subject: Re: [Anima] [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 08:32:41 -0000 --_000_BYAPR08MB4903C95973435BA06FC3C080FAD40BYAPR08MB4903namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRWxpb3QsDQoNCjEpIEluIGFuIE9QQyBVQSBlbnZpcm9ubWVudCwgbWlnaHQgb25lIGV4cGVj dCB0aGF0IHRoZSBqb2luIHJlZ2lzdHJhciBhbmQgdGhlIGNlcnRpZmljYXRlIG1hbmFnZXIgYmUg Y28tcmVzaWRlbnQ/DQoNClllcyB0aGF0IGlzIHRoZSBleHBlY3RhdGlvbi4NCg0KMikgTXkgYmln Z2VyIHF1ZXN0aW9uIGlzIHdoZXRoZXIgeW91IHdhbnQgdG8gdXNlIGFsbCBvZiB0aGlzIGZvciBu ZXR3b3JrIGF1dGhlbnRpY2F0aW9uIHRvIGF2b2lkIHVuYXV0aG9yaXplZCBkZXZpY2VzIGpvaW5p bmcgdGhlIG5ldHdvcmsgaW4gdGhlIGZpcnN0IHBsYWNlLCBvciB3aGV0aGVyIHRoaXMgaXMgaW50 ZW5kZWQgc29sZWx5IGZvciBhcHBsaWNhdGlvbiBhdXRoZW50aWNhdGlvbi4NCg0KQ291bnRlcmZl aXQgZGV2aWNlcyBhcmUgaHVnZSBpc3N1ZSBpbiBpbmR1c3RyaWFsIGF1dG9tYXRpb24uIFdlIG5l ZWQgdGhpcyBpbmZyYXN0cnVjdHVyZSBzbyB0aGUgT3BlcmF0b3JzIGNhbiBhc3N1cmUgdGhlbXNl bHZlcyB0aGF0IHRoZSBEZXZpY2VzIHRoZXkgcGx1ZyBpbnRvIHRoZWlyIG5ldHdvcmsgYXJlIGdl bnVpbmUuDQoNCk9UT0gsIE9wZXJhdG9ycyBkb27igJl0IG5lZWQgdG8gcHJvdmUgdGhlaXIgcmln aHQgdG8gdXNlIGEgRGV2aWNlLiBJZiBhbiBPcGVyYXRvciBoYXMgYSBEZXZpY2UgdGhleSBhcmUg ZW50aXRsZWQgdG8gdXNlIGl0IChpLmUuIERldmljZXMgY2FuIGJlIHNvbGQvdHJhbnNmZXJyZWQg d2l0aG91dCBhcHByb3ZhbCBmcm9tIHRoZSBtYW51ZmFjdHVyZXIpLg0KDQpSZWdhcmRzLA0KDQpS YW5keQ0KDQoNCkZyb206IEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPg0KU2VudDogQXVndXN0 IDcsIDIwMTkgMTI6MzMgQU0NClRvOiBSYW5keSBBcm1zdHJvbmcgKE9QQykgPHJhbmR5LmFybXN0 cm9uZ0BvcGNmb3VuZGF0aW9uLm9yZz4NCkNjOiBUb2VybGVzcyBFY2tlcnQgPHR0ZUBjcy5mYXUu ZGU+OyBpb3Qtb25ib2FyZGluZ0BpZXRmLm9yZzsgYW5pbWFAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbSW90LW9uYm9hcmRpbmddIE9QQyBhbmQgQlJTS0kNCg0KUmFuZHksDQoNClRoYW5rcy4gIFdl IGhhdmUgaXJyZWd1bGFyIGNhbGxzLCBidXQgSSB3aWxsIHBvbGwgZm9yIG9uZSBpbiB0aGUgM3Jk IHdlZWsgb2YgQXVndXN0IHRvIGRpc2N1c3MgeW91ciB1c2UgY2FzZS4NCg0KSW4gYW4gT1BDIFVB IGVudmlyb25tZW50LCBtaWdodCBvbmUgZXhwZWN0IHRoYXQgdGhlIGpvaW4gcmVnaXN0cmFyIGFu ZCB0aGUgY2VydGlmaWNhdGUgbWFuYWdlciBiZSBjby1yZXNpZGVudD8gIFRoaXMgd291bGQgYmUg d2hlcmUgRVNUL1NDRVAgd291bGQgaGFwcGVuIChCUlNLSSBjYW4gYmUgdmlld2VkIGFzIGFuIGV4 dGVuc2lvbiB0byBFU1QgLSBSRkMgNzAzMCkuICBUaGVyZSBpcyBubyAicHVzaCBtb2RlIiBmb3Ig RVNULiAgSG93ZXZlciwgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBzYW1lIGNhcGFiaWxp dHkgcm91Z2hseSBzcGVha2luZyByZXNpZGVzIGluIENJUC4NCg0KTXkgYmlnZ2VyIHF1ZXN0aW9u IGlzIHdoZXRoZXIgeW91IHdhbnQgdG8gdXNlIGFsbCBvZiB0aGlzIGZvciBuZXR3b3JrIGF1dGhl bnRpY2F0aW9uIHRvIGF2b2lkIHVuYXV0aG9yaXplZCBkZXZpY2VzIGpvaW5pbmcgdGhlIG5ldHdv cmsgaW4gdGhlIGZpcnN0IHBsYWNlLCBvciB3aGV0aGVyIHRoaXMgaXMgaW50ZW5kZWQgc29sZWx5 IGZvciBhcHBsaWNhdGlvbiBhdXRoZW50aWNhdGlvbi4NCg0KRWxpb3QNCg0KDQoNCk9uIDcgQXVn IDIwMTksIGF0IDAxOjE5LCBSYW5keSBBcm1zdHJvbmcgKE9QQykgPHJhbmR5LmFybXN0cm9uZ0Bv cGNmb3VuZGF0aW9uLm9yZzxtYWlsdG86cmFuZHkuYXJtc3Ryb25nQG9wY2ZvdW5kYXRpb24ub3Jn Pj4gd3JvdGU6DQoNClB1c2ggc2hvdWxkIGJlIOKAnENlcnRpZmljYXRlIE1hbmFnZXIgaW5pdGlh dGVk4oCdDQoNCkZyb206IElvdC1vbmJvYXJkaW5nIDxpb3Qtb25ib2FyZGluZy1ib3VuY2VzQGll dGYub3JnPG1haWx0bzppb3Qtb25ib2FyZGluZy1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxm IE9mIFJhbmR5IEFybXN0cm9uZyAoT1BDKQ0KU2VudDogQXVndXN0IDYsIDIwMTkgNDoxNyBQTQ0K VG86IFRvZXJsZXNzIEVja2VydCA8dHRlQGNzLmZhdS5kZTxtYWlsdG86dHRlQGNzLmZhdS5kZT4+ DQpDYzogaW90LW9uYm9hcmRpbmdAaWV0Zi5vcmc8bWFpbHRvOmlvdC1vbmJvYXJkaW5nQGlldGYu b3JnPjsgYW5pbWFAaWV0Zi5vcmc8bWFpbHRvOmFuaW1hQGlldGYub3JnPjsgRWxpb3QgTGVhciA8 bGVhckBjaXNjby5jb208bWFpbHRvOmxlYXJAY2lzY28uY29tPj4NClN1YmplY3Q6IFJlOiBbSW90 LW9uYm9hcmRpbmddIE9QQyBhbmQgQlJTS0kNCg0KSGkNCg0KMSkgU3VyZSwgbmVlZCB0byB1bmRl cnN0YW5kIGhvdyBUQ1AgVUEgd29ya3Mgd2loIHRoZSBtaW5pbXVtIGFtb3VudCBvZiBtZXNzYWdl IGF1dGhlbnRpY2F0aW9uIHRvIGFsbG93IGZvciBCUlNLSS4gTWFpbiBjaGFsbGVuZ2UgbWF5IGJl IHRoZSBuZWVkIGZvciBwbGVkZ2VzIHRvIHJlY2VpdmUgbWVzc2FnZXMgZnJvbSByZWdpc3RyYXIg dGhhdCBhcmUgYXV0aGVudGljYXRlZCBieSB0aGUgcmVnaXN0YXIsIGJ1dCB3aGVyZSB0aGUgcGxl ZGdlIGhhcyB0byB3YWl0IHVudGlsIGl0IGNhbiBhY3R1YWxseSBwZXJmb3JtIHRoZSBhdXRoZW50 aWNhdGlvbiBsYXRlci4gRGVwZW5kaW5nIG9uIGhvdyB5b3UgYnVpbHQgVENQIFVBIG1lc3NhZ2Ug bGF5ZXIgYXV0aGVudGljYXRpb24gdGhpcyBtYXkgYmUgcGllY2Ugb2YgY2FrZSAvIGZyZWUgb3Ig bm90Lg0KDQpJdCB3b3VsZCBiZSBlYXN5IHRvIGRyb3AgaW4gYSBPUEMgVUEgYXdhcmUgcmVnaXN0 cmFyIGFuZCBpbXBsZW1lbnQgYWxsIG9mIHRoZSBCUktTSSBmbG93cyBiYWNrIHRvIHRoZSBNQVNB LiBUaGUgb25seSBudWlzYW5jZSBmYWN0b3IgaXMgdGhlICdwcmlvci1zaWduZWQtdm91Y2hlci1y ZXF1ZXN0Jy4uIElmIE1BU0EncyBhcmUgd2lsbGluZyBhbGxvdyB0aGlzIGZpZWxkIHRvIGJlIG9t aXR0ZWQgYW5kIHRvIHRydXN0IHRoZSBSZWdpc3RyYXIgdGhlbiBub3RoaW5nIG1vcmUgbmVlZHMg dG8gZG9uZS4gSWYgTUFTQSdzIG5lZWQgdGhpcyBmaWVsZCB0aGVuIHdlIGNvdWxkIGdldCBpdCBm cm9tIHRoZSBEZXZpY2UgdmlhIE9QQyBVQSBidXQgcHJvZHVjaW5nIHRoZSBDTVMgbWVzc2FnZSBh ZGRzIGFuIGFkZGl0aW9uYWwgYnVyZGVuIG9uIGxvdyBlbmQgZGV2aWNlcyAoaS5lLiB0aGUgbmVl ZCB0byBwdWxsIGluIGxpYnJhcmllcyB0aGF0IHByb3ZpZGUgdGhlIHNhbWUgZnVuY3Rpb25hbGl0 eSBhcyBPUEMgVUEgYnV0IGRvIGl0IGluIGRpZmZlcmVudCBmb3JtYXQpLg0KDQpUaGUgMiBtb2Rl cyBvZiBvcGVyYXRpb24gd2l0aCBhIE9QQyBVQSBhd2FyZSByZWdpc3RyYXIgKHRoZSBDZXJ0aWZp Y2F0ZSBNYW5hZ2VyIGlzIGFuIE9QQyBVQSBkZWZpbmVkIGVudGl0eSkuDQoNClB1bGwgKGRldmlj ZSBpbml0aWF0ZWQpDQoNCjxpbWFnZTAwNS5wbmc+DQoNClB1c2ggKFJlZ2lzdHJhciBpbml0aWF0 ZWQpDQoNCjxpbWFnZTAwNi5wbmc+DQoNClJlZ2FyZHMsDQoNClJhbmR5DQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBUb2VybGVzcyBFY2tlcnQgPHR0ZUBjcy5mYXUuZGU8bWFp bHRvOnR0ZUBjcy5mYXUuZGU+Pg0KU2VudDogQXVndXN0IDYsIDIwMTkgMzozMSBQTQ0KVG86IFJh bmR5IEFybXN0cm9uZyAoT1BDKSA8cmFuZHkuYXJtc3Ryb25nQG9wY2ZvdW5kYXRpb24ub3JnPG1h aWx0bzpyYW5keS5hcm1zdHJvbmdAb3BjZm91bmRhdGlvbi5vcmc+Pg0KQ2M6IEVsaW90IExlYXIg PGxlYXJAY2lzY28uY29tPG1haWx0bzpsZWFyQGNpc2NvLmNvbT4+OyBpb3Qtb25ib2FyZGluZ0Bp ZXRmLm9yZzxtYWlsdG86aW90LW9uYm9hcmRpbmdAaWV0Zi5vcmc+OyBhbmltYUBpZXRmLm9yZzxt YWlsdG86YW5pbWFAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0lvdC1vbmJvYXJkaW5nXSBPUEMg YW5kIEJSU0tJDQoNCk9uIFR1ZSwgQXVnIDA2LCAyMDE5IGF0IDA5OjMyOjQ1UE0gKzAwMDAsIFJh bmR5IEFybXN0cm9uZyAoT1BDKSB3cm90ZToNCj4gT1BDIGlzIGxheWVyZWQgdG8gc2VwYXJhdGUg dGhlIGFwcGxpY2F0aW9uIGZyb20gdGhlIGNob2ljZSBvZiBuZXR3b3JrIHByb3RvY29sLiBUTFMv V2ViU29ja2V0cyBpcyBhbiBvcHRpb24gYnV0IHRoZSBwcmltYXJ5IHByb3RvY29sIHRoYXQgd2ls bCBiZSB1c2VkIGJ5IGxvdyBlbmQgZGV2aWNlcyBpcyBVQSBUQ1Agd2hpY2ggcHJvdmlkZXMgY29t cGxldGUgbWVzc2FnZSBiYXNlZCBzZWN1cml0eSBmcmFtZXdvcmsuICBUaGVzZSBkZXZpY2VzIGRv IG5vdCBuZWVkIFRMUyB0byBoYXZlIHNlY3VyaXR5IGFuZCByZXF1aXJpbmcgaXQgd291bGQgcmVx dWlyZSBkdXBsaWNhdGlvbiBvZiBjb2RlLg0KDQpTdXJlLCBuZWVkIHRvIHVuZGVyc3RhbmQgaG93 IFRDUCBVQSB3b3JrcyB3aWggdGhlIG1pbmltdW0gYW1vdW50IG9mIG1lc3NhZ2UgYXV0aGVudGlj YXRpb24gdG8gYWxsb3cgZm9yIEJSU0tJLiBNYWluIGNoYWxsZW5nZSBtYXkgYmUgdGhlIG5lZWQg Zm9yIHBsZWRnZXMgdG8gcmVjZWl2ZSBtZXNzYWdlcyBmcm9tIHJlZ2lzdHJhciB0aGF0IGFyZSBh dXRoZW50aWNhdGVkIGJ5IHRoZSByZWdpc3RhciwgYnV0IHdoZXJlIHRoZSBwbGVkZ2UgaGFzIHRv IHdhaXQgdW50aWwgaXQgY2FuIGFjdHVhbGx5IHBlcmZvcm0gdGhlIGF1dGhlbnRpY2F0aW9uIGxh dGVyLiBEZXBlbmRpbmcgb24gaG93IHlvdSBidWlsdCBUQ1AgVUEgbWVzc2FnZSBsYXllciBhdXRo ZW50aWNhdGlvbiB0aGlzIG1heSBiZSBwaWVjZSBvZiBjYWtlIC8gZnJlZSBvciBub3QuDQoNCj4g MikgQXQgc29tZSBwb2ludCwgdGhlIHRoaW5nIGRlY2lkZXMgd2hpY2ggcGFydCBnZXRzIGFuIElQ IGFkZHJlc3Mgb3IgYXQgbGVhc3QgaXMgcmVzcG9uc2libGUgZm9yIHRoZSBwaHkuICBDYW4gdGhh dCBwcm9jZXNzIGJlIGxldmVyYWdlZCB0byBlc3RhYmxpc2ggaWRlbnRpdHk/DQo+DQo+IE1hY2hp bmVzIG1heSBoYXZlIGEgc2VwYXJhdGUgbmV0d29yayBmb3IgaW50ZXJuYWwgRGV2aWNlcyB3aGlj aCBJUHMgYXNzaWduZWQgYnkgdGhlIG1hY2hpbmU/Pz9zIERIQ1Agc2VydmljZS4gU29tZSBvZiB0 aGVzZSBkZXZpY2VzIG1heSBpbnRlcmFjdCB3aXRoIGV4dGVybmFsIGVxdWlwbWVudCB2aWEgYSBO QVQgcm91dGVyIHdoaWNoIGFzc2lnbnMgYSB1bmlxdWUgcG9ydCB0byBlYWNoIGRldmljZS4gVGhp cyBtZWFucyB0aGUgaW5kaXZpZHVhbCBEZXZpY2VzIG5lZWQgdG8gYmUgZ3JhbnRlZCBhY2Nlc3Mg dG8gdGhlIG9wZXJhdG9ycyBuZXR3b3JrIHdoZW4gdGhlIG1hY2hpbmUgaXMgaW5zdGFsbGVkIGV2 ZW4gdGhvdWdoIHRoZSBvcGVyYXRvciBjYW5ub3QgcHJvdmlkZSB0aGVtIHdpdGggSVBzLg0KPg0K PiBJIG5lZWQgdG8gY29uc3VsdCB3aXRoIG91ciBtYWNoaW5lIGV4cGVydHMgdG8gYmV0dGVyIGV4 cGxhaW4gdGhpcyB1c2UgY2FzZS4NCg0KUHJpbWFyeSBxdWVzdGlvbnMgc2VlbSB0byBiZSB3aGV0 aGVyIHRoaXMgaXMganVzdCBhYm91dCBhdXRoZW50aWNhdGlvbiBhdCB0aGUgVENQIFVBIGxheWVy IG9yIGZ1cnRoZXIgYmVsb3cgYXQgc29tZSBpbXBsaWVkIE5BQyBtZWNoYW5pc20uDQoNCj4gMykg T25lIHBvc3NpYmxlIHZpZXcgaGVyZSBpcyB0aGF0IHRoZSBNQVNBIG1heSBiZSBvZmZsaW5lLCBh bmQgbWF5IGhhdmUgcHJvdmlkZWQgYSB2b3VjaGVyIHZpYSBvZmZsaW5lIG1lYW5zIHRvIHRoZSBq b2luIHJlZ2lzdHJhci4gIFRoaXMgb2YgY291cnNlIHdvdWxkIGJlIG5vbmNlbGVzcyB3aXRoIGEg bGVuZ3RoeSBleHBpcnkgdGltZS4gIEluIGFkZGl0aW9uLCBJIHBvc2l0ZWQgZHVyaW5nIEJSU0tJ Pz8/cyByZXZpZXcgdGhhdCBwZXJoYXBzIHRoZSBkZXZpY2Ugc2hvdWxkIGJlIGFibGUgdG8gZ2Vu ZXJhdGUgaXRzIG93biBjZXJ0aWZpY2F0ZSB2aWEgYSBoaWdoZXIgbGV2ZWwgaW50ZXJmYWNlLg0K Pg0KPiBPUEMgYWxyZWFkeSBoYXMgQVBJcyBuZWVkZWQgdG8gbWFuYWdlIENlcnRpZmljYXRlcyBv biBhIERldmljZS4gVGhlIGxpbmsgdG8gc29tZXRoaW5nIGxpa2UgdGhlIE1BU0EgaXMgd2hhdCB3 ZSBhcmUgbWlzc2luZy4gTm9uY2VsZXNzIHZvdWNoZXJzIHRoYXQgZG8gbm90IGV4cGlyZSBzaG91 bGQgYWxsb3cgbG9jYWwgcmVnaXN0cmFyIHRvIGVtdWxhdGUgYSBNQVNBIHdoZW4gdGhlIE1BU0Eg aXMgbm8gbG9uZ2VyIGF2YWlsYWJsZS4gSSB3YW50ZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhpcyBt b2RlIG9mIG9wZXJhdGlvbiBpcyBhbGxvd2VkIEJSU0tJLg0KDQpZZXMgaXQgaXMsIGl0IG1heSBq dXN0IG5vdCBiZSBmdWxseSBzcGVjaWZpZWQgaW4gdGhlIGN1cnJlbnQgdGFyZ2V0ZWQgQlJTS0kg UkZDIHRoYXQgd2UgZmVlbCBldmVyeWJvZHkgd2hvIHdhbnRzIHRvIGltcGxlbWVudCBpdCBoYXMg ZXZlcnl0aGluZyB0byBkbyBzbywgYnV0IHRoYXRzIHdvdWxkIGp1c3QgYmUgc3ViamV0IHRvIGZ1 dHVyZSBzbWFsbCBSRkMgdG8gY2xvc2UgYW55IHBvc3NpYmxlIGdhcHMuDQoNCj4gNCkgQ2FuIHlv dSBzYXkgbW9yZSBhYm91dCB3aGF0IG1lY2hhbmlzbXMgT1BDIGlzIGludGVyZXN0ZWQgaW4gcHVy c3Vpbmc/DQo+DQo+IFdpdGggT1BDIHdlIGFzc3VtZSB0aGF0IG5ldHdvcmsgc2VsZWN0aW9uIGFu ZCBJUCBhc3NpZ25tZW50IGFyZSBvdXQgb2Ygc2NvcGUuIFdpcmVkIGRldmljZXMgYXJlIHRoZSBw cmltYXJ5IG1hcmtldCBhdCB0aGlzIHRpbWUgYnV0IDVHIGNvdWxkIGNoYW5nZSB0aGF0Lg0KDQpC UlNLSSBhbHNvIGRvZXMgbm90IGNhcmUgYWJvdXQgQWRkcmVzc2luZy4gT25seSBBQ1AgZG9lcywg c28geW91IGNhbiBpZ25vcmUgdGhhdCBwYXJ0IGlmIHlvdSdyZSBub3QgaW50ZXJlc3RlZCBpbi4g V2UgaGF2ZSB0cmllZCB0byBzZXBhcmF0ZSBvdXQgQUNQIHNwZWNpZmljIGFzcGVjdHMgaW4gdGhl IEJSU0tJIGRvY3VtZW50IGFzIGdvb2QgYXMgcG9zc2libGUgd2l0aCB0aGUgc29tZXdoYXQgY29u dm9sdXRlZCBwcm9jZXNzIHdlIGhhZCBpbiB0aGUgSUVURiBob3cgdG8gZHJpdmUgdGhvc2UgZG9j dW1lbnRzLg0KDQpDaGVlcnMNCiAgICBUb2VybGVzcw0KDQo+IFJlZ2FyZHMsDQo+DQo+IFJhbmR5 DQo+DQo+IEZyb206IEVsaW90IExlYXIgPGxlYXJAY2lzY28uLmNvbTxtYWlsdG86bGVhckBjaXNj by5jb20+Pg0KPiBTZW50OiBBdWd1c3QgNiwgMjAxOSAxOjQ3IFBNDQo+IFRvOiBSYW5keSBBcm1z dHJvbmcgKE9QQykgPHJhbmR5LmFybXN0cm9uZ0BvcGNmb3VuZGF0aW9uLm9yZzxtYWlsdG86cmFu ZHkuYXJtc3Ryb25nQG9wY2ZvdW5kYXRpb24ub3JnPj4NCj4gQ2M6IGlvdC1vbmJvYXJkaW5nQGll dGYub3JnPG1haWx0bzppb3Qtb25ib2FyZGluZ0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtJ b3Qtb25ib2FyZGluZ10gT1BDIGFuZCBCUlNLSQ0KPg0KPiBIaSBSYW5keSwNCj4NCj4gVGhhbmtz IGZvciB0aGlzLiAgSXQ/Pz9zIGEgZ3JlYXQgc3RhcnRpbmcgcG9pbnQuICBJIHdvdWxkIHByb3Bv c2UgdGhhdCB3ZSBkbyBhIGNhbGwgc28gd2UgY2FuIGdldCBzb21lIGhpZ2ggYmFuZHdpZHRoIGRp c2N1c3Npb24gZ29pbmcuICBQbGVhc2Ugbm93IHNlZSBiZWxvdy4NCj4NCj4NCj4gT24gNiBBdWcg MjAxOSwgYXQgMjA6NTgsIFJhbmR5IEFybXN0cm9uZyAoT1BDKSA8cmFuZHkuYXJtc3Ryb25nQG9w Y2ZvdW5kYXRpb24ub3JnPG1haWx0bzpyYW5keS5hcm1zdHJvbmdAb3BjZm91bmRhdGlvbi5vcmc8 bWFpbHRvOnJhbmR5LmFybXN0cm9uZ0BvcGNmb3VuZGF0aW9uLm9yZyUzY21haWx0bzpyYW5keS5h cm1zdHJvbmdAb3BjZm91bmRhdGlvbi5vcmc+Pj4gd3JvdGU6DQo+DQo+IEkgd2lsbCBzdGFydCB3 aXRoIHRoZSBtYWluIHRyb3VibGUgc3BvdHMuIFNvbWUgb2YgdGhlc2UgbWF5IGJlIGFscmVhZHkg Y292ZXJlZCBieSBCUktTSSBidXQgSSBtaXNzZWQgdGhlIGltcGxpY2F0aW9ucyBvZiBzb21lIG9m IHRoZSB0ZXh0Og0KPg0KPiAxKSBMb3cgZW5kIGRldmljZXMgdGhhdCBvbmx5IHN1cHBvcnQgT1BD OyB0aGlzIG1lYW5zIG5vIFRMUyBjbGllbnQNCj4gY2FwYWJpbGl0aWVzIGFuZCBubyBhYmlsaXR5 IHRvIGluaXRpYXRlIG5ldHdvcmsgY29tbXVuaWNhdGlvbiAoaS5lLg0KPiBzZXJ2ZXIgb25seSBt b2RlKTsNCj4NCj4NCj4gSG93IGRvZXMgT1BDIGhhbmRsZSBzdWNoIGRldmljZXM/ICBJIHRoaW5r IHRoaXMgaXMgYWxzbyBjb21pbmcgdXAgZWxzZXdoZXJlLiAgT25lIHF1ZXN0aW9uIGlzIHdoZXRo ZXIgVExTIGlzIHJlcXVpcmVkLiAgV2l0aG91dCBUTFMgb25lIGRvZXMgbG9zZSBjb25maWRlbnRp YWxpdHksIGJ1dCBzbyBsb25nIGFzIHRoZSBjbGllbnQgY2FuIHNpZ24gdGhlIHJlcXVlc3QsIG1h eWJlIHRoYXQ/Pz9zIGFsbCB5b3UgdXNlLg0KPg0KPg0KPg0KPiAyKSBNYWNoaW5lIGJ1aWxkZXJz IHRoYXQgY29tYmluZSBkZXZpY2VzIGludG8gYSBtYWNoaW5lIHRoYXQgaXMgc29sZCBhcyBhIHVu aXQuIFRoZXNlIGRldmljZSBzdGlsbCBoYXZlIGEgdW5pcXVlIG5ldHdvcmsgaWRlbnRpdHkgYnV0 IHRoZSBlZmZlY3RpdmUgbWFudWZhY3R1cmVyIGhhcyBjaGFuZ2VkOyBIb3cgdG8gZGVhbCB3aXRo IHRoZSBEZXZpY2VJRD8NCj4NCj4NCj4gQXQgc29tZSBwb2ludCwgdGhlIHRoaW5nIGRlY2lkZXMg d2hpY2ggcGFydCBnZXRzIGFuIElQIGFkZHJlc3Mgb3IgYXQgbGVhc3QgaXMgcmVzcG9uc2libGUg Zm9yIHRoZSBwaHkuICBDYW4gdGhhdCBwcm9jZXNzIGJlIGxldmVyYWdlZCB0byBlc3RhYmxpc2gg aWRlbnRpdHk/DQo+DQo+DQo+DQo+DQo+IDMpIERldmljZXMgbWF5IGJlIHJlc2V0IHRvIGZhY3Rv cnkgZGVmYXVsdHMgYW5kIHNvbGQvdHJhbnNmZXJyZWQgdG8gYW5vdGhlciBvcmdhbml6YXRpb24u IFRoaXMgbmVlZHMgdG8gYmUgcG9zc2libGUgZXZlbiBpZiB0aGUgTUFTQSBpcyBubyBsb25nZXIg YXZhaWxhYmxlIChpLmUuIHRoZSBvcmlnaW5hbCBtYW51ZmFjdHVyZXIgaGFzIGdvbmUgb3V0IG9m IGJ1c2luZXNzKS4NCj4NCj4gT25lIHBvc3NpYmxlIHZpZXcgaGVyZSBpcyB0aGF0IHRoZSBNQVNB IG1heSBiZSBvZmZsaW5lLCBhbmQgbWF5IGhhdmUgcHJvdmlkZWQgYSB2b3VjaGVyIHZpYSBvZmZs aW5lIG1lYW5zIHRvIHRoZSBqb2luIHJlZ2lzdHJhci4gIFRoaXMgb2YgY291cnNlIHdvdWxkIGJl IG5vbmNlbGVzcyB3aXRoIGEgbGVuZ3RoeSBleHBpcnkgdGltZS4gIEluIGFkZGl0aW9uLCBJIHBv c2l0ZWQgZHVyaW5nIEJSU0tJPz8/cyByZXZpZXcgdGhhdCBwZXJoYXBzIHRoZSBkZXZpY2Ugc2hv dWxkIGJlIGFibGUgdG8gZ2VuZXJhdGUgaXRzIG93biBjZXJ0aWZpY2F0ZSB2aWEgYSBoaWdoZXIg bGV2ZWwgaW50ZXJmYWNlLg0KPg0KPg0KPg0KPiA0KSBPZmZsaW5lIG9wZXJhdGlvbiBpcyB0aGUg bm9ybSB3aXRoIHByZS1pc3N1ZWQgdm91Y2hlcnMgZGVsaXZlcmVkIG91dCBvZiBiYW5kLiBUaGUg cHJlLWlzc3VlZCB2b3VjaGVycyB3aWxsIG5lZWQgdG8gaGF2ZSByZWFzb25hYmx5IGxvbmcgbGlm ZXRpbWUgKGkuZS4geWVhcnMgbm90IGhvdXJzKS4NCj4NCj4gVGhlIGxpZmVjeWNsZSBvZiBhIGRl dmljZSBpcyBzaG93biBpbiB0aGUgZm9sbG93aW5nIGRpYWdyYW0uIFRoZQ0KPiBleHBlY3RhdGlv biBpcyB3ZSB3b3VsZCBuZWVkIHRvIGFkZCBsaW5rcyB0byB0aGUgTUFTQSBhdCBlYWNoIHN0ZXAg aW4NCj4gdGhlIGxpZmV0aW1lDQo+DQo+DQo+IFRoYW5rIHlvdSBmb3IgdGhhdC4gIEZvciB3aXJl ZCBpdCBzZWVtcyB0byBtZSB0aGF0IGEgcGVybWlzc2l2ZSBNQVNBIG1vZGVsIChsb2dnaW5nIG9u bHkpIGNvdWxkIHByb3ZpZGUgeW91IGEgd2F5IGZvcndhcmQuICBGb3Igd2lyZWxlc3MsIHRoaXMg aXMgbm90IGFuIG9wdGlvbiBiZWNhdXNlIHByb3BlciBuZXR3b3JrIHNlbGVjdGlvbiBuZWVkcyB0 byBvY2N1ci4gIEFub3RoZXIgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBuZWVkIGFub3RoZXIgbWVj aGFuaXNtIGlzIG5lY2Vzc2FyeSB0byB2YWxpZGF0ZSB0aGUgdm91Y2hlciAoYWthLCBhIFBTSyB3 LyBwcm9vZiBvZiBrbm93bGVkZ2UsIG9yIERQUCwgZXRjKS4NCj4NCj4gQ2FuIHlvdSBzYXkgbW9y ZSBhYm91dCB3aGF0IG1lY2hhbmlzbXMgT1BDIGlzIGludGVyZXN0ZWQgaW4gcHVyc3Vpbmc/DQo+ DQo+IEVsaW90DQo+DQoNCj4gLS0NCj4gSW90LW9uYm9hcmRpbmcgbWFpbGluZyBsaXN0DQo+IElv dC1vbmJvYXJkaW5nQGlldGYub3JnPG1haWx0bzpJb3Qtb25ib2FyZGluZ0BpZXRmLm9yZz4NCj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pb3Qtb25ib2FyZGluZw0KDQoN Ci0tDQotLS0NCnR0ZUBjcy5mYXUuZGU8bWFpbHRvOnR0ZUBjcy5mYXUuZGU+DQoNCg== --_000_BYAPR08MB4903C95973435BA06FC3C080FAD40BYAPR08MB4903namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJZdSBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNCAwIDAgMCAw IDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFl1IEdv dGhpYyI7DQoJcGFub3NlLTE6MiAxMSA0IDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tQ0EiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEVsaW90LDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4xKSBJbiBhbiBPUEMgVUEgZW52aXJvbm1lbnQsIG1pZ2h0IG9uZSBleHBlY3QgdGhh dCB0aGUgam9pbiByZWdpc3RyYXIgYW5kIHRoZSBjZXJ0aWZpY2F0ZSBtYW5hZ2VyIGJlIGNvLXJl c2lkZW50PyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50 OjM2LjBwdCI+WWVzIHRoYXQgaXMgdGhlIGV4cGVjdGF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4yKSBNeSBiaWdnZXIgcXVlc3Rpb24gaXMgd2hldGhlciB5b3Ugd2FudCB0byB1c2UgYWxs IG9mIHRoaXMgZm9yIG5ldHdvcmsgYXV0aGVudGljYXRpb24gdG8gYXZvaWQgdW5hdXRob3JpemVk IGRldmljZXMgam9pbmluZyB0aGUgbmV0d29yayBpbiB0aGUgZmlyc3QgcGxhY2UsIG9yIHdoZXRo ZXIgdGhpcyBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIGFwcGxpY2F0aW9uIGF1dGhlbnRpY2F0aW9u LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Db3Vu dGVyZmVpdCBkZXZpY2VzIGFyZSBodWdlIGlzc3VlIGluIGluZHVzdHJpYWwgYXV0b21hdGlvbi4g V2UgbmVlZCB0aGlzIGluZnJhc3RydWN0dXJlIHNvIHRoZSBPcGVyYXRvcnMgY2FuIGFzc3VyZSB0 aGVtc2VsdmVzIHRoYXQgdGhlIERldmljZXMgdGhleSBwbHVnIGludG8gdGhlaXIgbmV0d29yayBh cmUgZ2VudWluZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T1RPSCwgT3BlcmF0b3JzIGRvbuKAmXQg bmVlZCB0byBwcm92ZSB0aGVpciByaWdodCB0byB1c2UgYSBEZXZpY2UuIElmIGFuIE9wZXJhdG9y IGhhcyBhIERldmljZSB0aGV5IGFyZSBlbnRpdGxlZCB0byB1c2UgaXQgKGkuZS4gRGV2aWNlcyBj YW4gYmUgc29sZC90cmFuc2ZlcnJlZCB3aXRob3V0IGFwcHJvdmFsIGZyb20gdGhlIG1hbnVmYWN0 dXJlcikuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJhbmR5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi PiBFbGlvdCBMZWFyICZsdDtsZWFyQGNpc2NvLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBB dWd1c3QgNywgMjAxOSAxMjozMyBBTTxicj4NCjxiPlRvOjwvYj4gUmFuZHkgQXJtc3Ryb25nIChP UEMpICZsdDtyYW5keS5hcm1zdHJvbmdAb3BjZm91bmRhdGlvbi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBUb2VybGVzcyBFY2tlcnQgJmx0O3R0ZUBjcy5mYXUuZGUmZ3Q7OyBpb3Qtb25ib2FyZGlu Z0BpZXRmLm9yZzsgYW5pbWFAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJb3Qt b25ib2FyZGluZ10gT1BDIGFuZCBCUlNLSTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlJhbmR5LDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzLiAmbmJzcDtXZSBoYXZlIGlycmVndWxhciBjYWxscywgYnV0IEkg d2lsbCBwb2xsIGZvciBvbmUgaW4gdGhlIDNyZCB3ZWVrIG9mIEF1Z3VzdCB0byBkaXNjdXNzIHlv dXIgdXNlIGNhc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkluIGFuIE9QQyBVQSBlbnZpcm9ubWVudCwgbWlnaHQgb25lIGV4cGVjdCB0aGF0 IHRoZSBqb2luIHJlZ2lzdHJhciBhbmQgdGhlIGNlcnRpZmljYXRlIG1hbmFnZXIgYmUgY28tcmVz aWRlbnQ/ICZuYnNwO1RoaXMgd291bGQgYmUgd2hlcmUgRVNUL1NDRVAgd291bGQgaGFwcGVuIChC UlNLSSBjYW4gYmUgdmlld2VkIGFzIGFuIGV4dGVuc2lvbiB0byBFU1QgLSBSRkMgNzAzMCkuICZu YnNwO1RoZXJlIGlzIG5vICZxdW90O3B1c2ggbW9kZSZxdW90Ow0KIGZvciBFU1QuICZuYnNwO0hv d2V2ZXIsIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgc2FtZSBjYXBhYmlsaXR5IHJvdWdo bHkgc3BlYWtpbmcgcmVzaWRlcyBpbiBDSVAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IGJpZ2dlciBxdWVzdGlvbiBpcyB3aGV0aGVyIHlv dSB3YW50IHRvIHVzZSBhbGwgb2YgdGhpcyBmb3IgbmV0d29yayBhdXRoZW50aWNhdGlvbiB0byBh dm9pZCB1bmF1dGhvcml6ZWQgZGV2aWNlcyBqb2luaW5nIHRoZSBuZXR3b3JrIGluIHRoZSBmaXJz dCBwbGFjZSwgb3Igd2hldGhlciB0aGlzIGlzIGludGVuZGVkIHNvbGVseSBmb3IgYXBwbGljYXRp b24gYXV0aGVudGljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkVsaW90PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDcgQXVnIDIwMTksIGF0IDAxOjE5LCBSYW5k eSBBcm1zdHJvbmcgKE9QQykgJmx0OzxhIGhyZWY9Im1haWx0bzpyYW5keS5hcm1zdHJvbmdAb3Bj Zm91bmRhdGlvbi5vcmciPnJhbmR5LmFybXN0cm9uZ0BvcGNmb3VuZGF0aW9uLm9yZzwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UHVz aCBzaG91bGQgYmUg4oCcQ2VydGlmaWNhdGUgTWFuYWdlciBpbml0aWF0ZWTigJ08bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPklvdC1vbmJvYXJkaW5nICZs dDs8YSBocmVmPSJtYWlsdG86aW90LW9uYm9hcmRpbmctYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4g c3R5bGU9ImNvbG9yOiM5NTRGNzIiPmlvdC1vbmJvYXJkaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L3Nw YW4+PC9hPiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGI+T24NCiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PC9iPlJhbmR5IEFybXN0cm9uZyAoT1BDKTxicj4NCjxiPlNlbnQ6PC9iPjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5BdWd1c3QgNiwg MjAxOSA0OjE3IFBNPGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5Ub2VybGVzcyBFY2tlcnQgJmx0OzxhIGhyZWY9Im1haWx0bzp0 dGVAY3MuZmF1LmRlIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+dHRlQGNzLmZhdS5kZTwv c3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlvdC1vbmJvYXJkaW5nQGlldGYu b3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aW90LW9uYm9hcmRpbmdAaWV0Zi5vcmc8 L3NwYW4+PC9hPjs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOmFuaW1hQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1 NEY3MiI+YW5pbWFAaWV0Zi5vcmc8L3NwYW4+PC9hPjsNCiBFbGlvdCBMZWFyICZsdDs8YSBocmVm PSJtYWlsdG86bGVhckBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5sZWFy QGNpc2NvLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW0lvdC1vbmJvYXJkaW5n XSBPUEMgYW5kIEJSU0tJPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGk8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEpIFN1cmUsIG5lZWQgdG8gdW5kZXJzdGFuZCBo b3cgVENQIFVBIHdvcmtzIHdpaCB0aGUgbWluaW11bSBhbW91bnQgb2YgbWVzc2FnZSBhdXRoZW50 aWNhdGlvbiB0byBhbGxvdyBmb3IgQlJTS0kuIE1haW4gY2hhbGxlbmdlIG1heSBiZSB0aGUgbmVl ZCBmb3IgcGxlZGdlcyB0byByZWNlaXZlIG1lc3NhZ2VzIGZyb20gcmVnaXN0cmFyIHRoYXQgYXJl IGF1dGhlbnRpY2F0ZWQgYnkgdGhlIHJlZ2lzdGFyLCBidXQNCiB3aGVyZSB0aGUgcGxlZGdlIGhh cyB0byB3YWl0IHVudGlsIGl0IGNhbiBhY3R1YWxseSBwZXJmb3JtIHRoZSBhdXRoZW50aWNhdGlv biBsYXRlci4gRGVwZW5kaW5nIG9uIGhvdyB5b3UgYnVpbHQgVENQIFVBIG1lc3NhZ2UgbGF5ZXIg YXV0aGVudGljYXRpb24gdGhpcyBtYXkgYmUgcGllY2Ugb2YgY2FrZSAvIGZyZWUgb3Igbm90Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3b3VsZCBiZSBlYXN5IHRvIGRyb3AgaW4gYSBPUEMg VUEgYXdhcmUgcmVnaXN0cmFyIGFuZCBpbXBsZW1lbnQgYWxsIG9mIHRoZSBCUktTSSBmbG93cyBi YWNrIHRvIHRoZSBNQVNBLiBUaGUgb25seSBudWlzYW5jZSBmYWN0b3IgaXMgdGhlICdwcmlvci1z aWduZWQtdm91Y2hlci1yZXF1ZXN0Jy4uIElmIE1BU0EncyBhcmUgd2lsbGluZyBhbGxvdyB0aGlz IGZpZWxkIHRvIGJlIG9taXR0ZWQgYW5kIHRvIHRydXN0DQogdGhlIFJlZ2lzdHJhciB0aGVuIG5v dGhpbmcgbW9yZSBuZWVkcyB0byBkb25lLiBJZiBNQVNBJ3MgbmVlZCB0aGlzIGZpZWxkIHRoZW4g d2UgY291bGQgZ2V0IGl0IGZyb20gdGhlIERldmljZSB2aWEgT1BDIFVBIGJ1dCBwcm9kdWNpbmcg dGhlIENNUyBtZXNzYWdlIGFkZHMgYW4gYWRkaXRpb25hbCBidXJkZW4gb24gbG93IGVuZCBkZXZp Y2VzIChpLmUuIHRoZSBuZWVkIHRvIHB1bGwgaW4gbGlicmFyaWVzIHRoYXQgcHJvdmlkZSB0aGUg c2FtZSBmdW5jdGlvbmFsaXR5DQogYXMgT1BDIFVBIGJ1dCBkbyBpdCBpbiBkaWZmZXJlbnQgZm9y bWF0KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlIDIgbW9kZXMgb2Ygb3BlcmF0aW9uIHdpdGggYSBPUEMgVUEgYXdhcmUgcmVnaXN0cmFy ICh0aGUgQ2VydGlmaWNhdGUgTWFuYWdlciBpcyBhbiBPUEMgVUEgZGVmaW5lZCBlbnRpdHkpLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QdWxs IChkZXZpY2UgaW5pdGlhdGVkKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbHQ7aW1hZ2UwMDUucG5nJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QdXNoIChSZWdpc3RyYXIgaW5pdGlh dGVkKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbHQ7aW1hZ2UwMDYucG5nJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SYW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBUb2VybGVzcyBFY2tlcnQgJmx0OzxhIGhyZWY9 Im1haWx0bzp0dGVAY3MuZmF1LmRlIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+dHRlQGNz LmZhdS5kZTwvc3Bhbj48L2E+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YnI+DQpTZW50OiBBdWd1c3QgNiwgMjAxOSAzOjMxIFBNPGJyPg0KVG86 IFJhbmR5IEFybXN0cm9uZyAoT1BDKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJhbmR5LmFybXN0cm9u Z0BvcGNmb3VuZGF0aW9uLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPnJhbmR5LmFy bXN0cm9uZ0BvcGNmb3VuZGF0aW9uLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCkNjOiBFbGlvdCBM ZWFyICZsdDs8YSBocmVmPSJtYWlsdG86bGVhckBjaXNjby5jb20iPjxzcGFuIHN0eWxlPSJjb2xv cjojOTU0RjcyIj5sZWFyQGNpc2NvLmNvbTwvc3Bhbj48L2E+Jmd0Ozs8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlvdC1vbmJv YXJkaW5nQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aW90LW9uYm9hcmRp bmdAaWV0Zi5vcmc8L3NwYW4+PC9hPjs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmFuaW1hQGlldGYub3JnIj48c3BhbiBzdHls ZT0iY29sb3I6Izk1NEY3MiI+YW5pbWFAaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NClN1YmplY3Q6 IFJlOiBbSW90LW9uYm9hcmRpbmddIE9QQyBhbmQgQlJTS0k8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgQXVnIDA2LCAy MDE5IGF0IDA5OjMyOjQ1UE0gJiM0MzswMDAwLCBSYW5keSBBcm1zdHJvbmcgKE9QQykgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 IE9QQyBpcyBsYXllcmVkIHRvIHNlcGFyYXRlIHRoZSBhcHBsaWNhdGlvbiBmcm9tIHRoZSBjaG9p Y2Ugb2YgbmV0d29yayBwcm90b2NvbC4gVExTL1dlYlNvY2tldHMgaXMgYW4gb3B0aW9uIGJ1dCB0 aGUgcHJpbWFyeSBwcm90b2NvbCB0aGF0IHdpbGwgYmUgdXNlZCBieSBsb3cgZW5kIGRldmljZXMg aXMgVUEgVENQIHdoaWNoIHByb3ZpZGVzIGNvbXBsZXRlIG1lc3NhZ2UgYmFzZWQgc2VjdXJpdHkg ZnJhbWV3b3JrLiZuYnNwOw0KIFRoZXNlIGRldmljZXMgZG8gbm90IG5lZWQgVExTIHRvIGhhdmUg c2VjdXJpdHkgYW5kIHJlcXVpcmluZyBpdCB3b3VsZCByZXF1aXJlIGR1cGxpY2F0aW9uIG9mIGNv ZGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlN1cmUsIG5lZWQgdG8gdW5kZXJzdGFuZCBob3cgVENQIFVBIHdvcmtzIHdpaCB0aGUgbWluaW11 bSBhbW91bnQgb2YgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiB0byBhbGxvdyBmb3IgQlJTS0kuIE1h aW4gY2hhbGxlbmdlIG1heSBiZSB0aGUgbmVlZCBmb3IgcGxlZGdlcyB0byByZWNlaXZlIG1lc3Nh Z2VzIGZyb20gcmVnaXN0cmFyIHRoYXQgYXJlIGF1dGhlbnRpY2F0ZWQgYnkgdGhlIHJlZ2lzdGFy LCBidXQgd2hlcmUNCiB0aGUgcGxlZGdlIGhhcyB0byB3YWl0IHVudGlsIGl0IGNhbiBhY3R1YWxs eSBwZXJmb3JtIHRoZSBhdXRoZW50aWNhdGlvbiBsYXRlci4gRGVwZW5kaW5nIG9uIGhvdyB5b3Ug YnVpbHQgVENQIFVBIG1lc3NhZ2UgbGF5ZXIgYXV0aGVudGljYXRpb24gdGhpcyBtYXkgYmUgcGll Y2Ugb2YgY2FrZSAvIGZyZWUgb3Igbm90LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IDIpIEF0IHNvbWUgcG9pbnQsIHRoZSB0aGluZyBk ZWNpZGVzIHdoaWNoIHBhcnQgZ2V0cyBhbiBJUCBhZGRyZXNzIG9yIGF0IGxlYXN0IGlzIHJlc3Bv bnNpYmxlIGZvciB0aGUgcGh5LiZuYnNwOyBDYW4gdGhhdCBwcm9jZXNzIGJlIGxldmVyYWdlZCB0 byBlc3RhYmxpc2ggaWRlbnRpdHk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmd0OyBNYWNoaW5lcyBtYXkgaGF2ZSBhIHNlcGFyYXRlIG5ldHdvcmsgZm9yIGlu dGVybmFsIERldmljZXMgd2hpY2ggSVBzIGFzc2lnbmVkIGJ5IHRoZSBtYWNoaW5lPz8/cyBESENQ IHNlcnZpY2UuIFNvbWUgb2YgdGhlc2UgZGV2aWNlcyBtYXkgaW50ZXJhY3Qgd2l0aCBleHRlcm5h bCBlcXVpcG1lbnQgdmlhIGEgTkFUIHJvdXRlciB3aGljaCBhc3NpZ25zIGEgdW5pcXVlIHBvcnQg dG8gZWFjaCBkZXZpY2UuIFRoaXMNCiBtZWFucyB0aGUgaW5kaXZpZHVhbCBEZXZpY2VzIG5lZWQg dG8gYmUgZ3JhbnRlZCBhY2Nlc3MgdG8gdGhlIG9wZXJhdG9ycyBuZXR3b3JrIHdoZW4gdGhlIG1h Y2hpbmUgaXMgaW5zdGFsbGVkIGV2ZW4gdGhvdWdoIHRoZSBvcGVyYXRvciBjYW5ub3QgcHJvdmlk ZSB0aGVtIHdpdGggSVBzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZndDsgSSBuZWVkIHRvIGNvbnN1bHQgd2l0aCBvdXIgbWFjaGluZSBleHBlcnRzIHRvIGJl dHRlciBleHBsYWluIHRoaXMgdXNlIGNhc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlByaW1hcnkgcXVlc3Rpb25zIHNlZW0gdG8gYmUgd2hl dGhlciB0aGlzIGlzIGp1c3QgYWJvdXQgYXV0aGVudGljYXRpb24gYXQgdGhlIFRDUCBVQSBsYXll ciBvciBmdXJ0aGVyIGJlbG93IGF0IHNvbWUgaW1wbGllZCBOQUMgbWVjaGFuaXNtLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IDMpIE9u ZSBwb3NzaWJsZSB2aWV3IGhlcmUgaXMgdGhhdCB0aGUgTUFTQSBtYXkgYmUgb2ZmbGluZSwgYW5k IG1heSBoYXZlIHByb3ZpZGVkIGEgdm91Y2hlciB2aWEgb2ZmbGluZSBtZWFucyB0byB0aGUgam9p biByZWdpc3RyYXIuJm5ic3A7IFRoaXMgb2YgY291cnNlIHdvdWxkIGJlIG5vbmNlbGVzcyB3aXRo IGEgbGVuZ3RoeSBleHBpcnkgdGltZS4mbmJzcDsgSW4gYWRkaXRpb24sIEkgcG9zaXRlZCBkdXJp bmcgQlJTS0k/Pz9zDQogcmV2aWV3IHRoYXQgcGVyaGFwcyB0aGUgZGV2aWNlIHNob3VsZCBiZSBh YmxlIHRvIGdlbmVyYXRlIGl0cyBvd24gY2VydGlmaWNhdGUgdmlhIGEgaGlnaGVyIGxldmVsIGlu dGVyZmFjZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 IE9QQyBhbHJlYWR5IGhhcyBBUElzIG5lZWRlZCB0byBtYW5hZ2UgQ2VydGlmaWNhdGVzIG9uIGEg RGV2aWNlLiBUaGUgbGluayB0byBzb21ldGhpbmcgbGlrZSB0aGUgTUFTQSBpcyB3aGF0IHdlIGFy ZSBtaXNzaW5nLiBOb25jZWxlc3Mgdm91Y2hlcnMgdGhhdCBkbyBub3QgZXhwaXJlIHNob3VsZCBh bGxvdyBsb2NhbCByZWdpc3RyYXIgdG8gZW11bGF0ZSBhIE1BU0Egd2hlbiB0aGUgTUFTQSBpcyBu byBsb25nZXINCiBhdmFpbGFibGUuIEkgd2FudGVkIHRvIG1ha2Ugc3VyZSB0aGF0IHRoaXMgbW9k ZSBvZiBvcGVyYXRpb24gaXMgYWxsb3dlZCBCUlNLSS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzIGl0IGlzLCBpdCBtYXkganVzdCBub3Qg YmUgZnVsbHkgc3BlY2lmaWVkIGluIHRoZSBjdXJyZW50IHRhcmdldGVkIEJSU0tJIFJGQyB0aGF0 IHdlIGZlZWwgZXZlcnlib2R5IHdobyB3YW50cyB0byBpbXBsZW1lbnQgaXQgaGFzIGV2ZXJ5dGhp bmcgdG8gZG8gc28sIGJ1dCB0aGF0cyB3b3VsZCBqdXN0IGJlIHN1YmpldCB0byBmdXR1cmUgc21h bGwgUkZDIHRvIGNsb3NlIGFueSBwb3NzaWJsZSBnYXBzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IDQpIENhbiB5b3Ugc2F5IG1vcmUg YWJvdXQgd2hhdCBtZWNoYW5pc21zIE9QQyBpcyBpbnRlcmVzdGVkIGluIHB1cnN1aW5nPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgV2l0aCBPUEMgd2Ug YXNzdW1lIHRoYXQgbmV0d29yayBzZWxlY3Rpb24gYW5kIElQIGFzc2lnbm1lbnQgYXJlIG91dCBv ZiBzY29wZS4gV2lyZWQgZGV2aWNlcyBhcmUgdGhlIHByaW1hcnkgbWFya2V0IGF0IHRoaXMgdGlt ZSBidXQgNUcgY291bGQgY2hhbmdlIHRoYXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJSU0tJIGFsc28gZG9lcyBub3QgY2FyZSBhYm91dCBB ZGRyZXNzaW5nLiBPbmx5IEFDUCBkb2VzLCBzbyB5b3UgY2FuIGlnbm9yZSB0aGF0IHBhcnQgaWYg eW91J3JlIG5vdCBpbnRlcmVzdGVkIGluLiBXZSBoYXZlIHRyaWVkIHRvIHNlcGFyYXRlIG91dCBB Q1Agc3BlY2lmaWMgYXNwZWN0cyBpbiB0aGUgQlJTS0kgZG9jdW1lbnQgYXMgZ29vZCBhcyBwb3Nz aWJsZSB3aXRoIHRoZSBzb21ld2hhdCBjb252b2x1dGVkDQogcHJvY2VzcyB3ZSBoYWQgaW4gdGhl IElFVEYgaG93IHRvIGRyaXZlIHRob3NlIGRvY3VtZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsgVG9l cmxlc3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0OyBSZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZndDsgUmFuZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mZ3Q7IEZyb206IEVsaW90IExlYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsZWFyQGNpc2NvLmNv bSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmxl YXJAY2lzY28uLmNvbTwvc3Bhbj48L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBTZW50OiBBdWd1c3QgNiwgMjAxOSAxOjQ3IFBN PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 IFRvOiBSYW5keSBBcm1zdHJvbmcgKE9QQykgJmx0OzxhIGhyZWY9Im1haWx0bzpyYW5keS5hcm1z dHJvbmdAb3BjZm91bmRhdGlvbi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3Rl eHQtZGVjb3JhdGlvbjpub25lIj5yYW5keS5hcm1zdHJvbmdAb3BjZm91bmRhdGlvbi5vcmc8L3Nw YW4+PC9hPiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsgQ2M6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppb3Qtb25ib2FyZGluZ0BpZXRmLm9yZyI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmlvdC1vbmJvYXJkaW5n QGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDsgU3ViamVjdDogUmU6IFtJb3Qtb25ib2FyZGluZ10gT1BDIGFu ZCBCUlNLSTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsg SGkgUmFuZHksPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OyBUaGFua3MgZm9yIHRoaXMuJm5ic3A7IEl0Pz8/cyBhIGdyZWF0IHN0YXJ0aW5nIHBvaW50LiZu YnNwOyBJIHdvdWxkIHByb3Bvc2UgdGhhdCB3ZSBkbyBhIGNhbGwgc28gd2UgY2FuIGdldCBzb21l IGhpZ2ggYmFuZHdpZHRoIGRpc2N1c3Npb24gZ29pbmcuJm5ic3A7IFBsZWFzZSBub3cgc2VlIGJl bG93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IE9uIDYgQXVnIDIw MTksIGF0IDIwOjU4LCBSYW5keSBBcm1zdHJvbmcgKE9QQykgJmx0OzxhIGhyZWY9Im1haWx0bzpy YW5keS5hcm1zdHJvbmdAb3BjZm91bmRhdGlvbi5vcmclM2NtYWlsdG86cmFuZHkuYXJtc3Ryb25n QG9wY2ZvdW5kYXRpb24ub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRl Y29yYXRpb246bm9uZSI+cmFuZHkuYXJtc3Ryb25nQG9wY2ZvdW5kYXRpb24ub3JnJmx0O21haWx0 bzpyYW5keS5hcm1zdHJvbmdAb3BjZm91bmRhdGlvbi5vcmc8L3NwYW4+PC9hPiZndDsmZ3Q7DQog d3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJ IHdpbGwgc3RhcnQgd2l0aCB0aGUgbWFpbiB0cm91YmxlIHNwb3RzLiBTb21lIG9mIHRoZXNlIG1h eSBiZSBhbHJlYWR5IGNvdmVyZWQgYnkgQlJLU0kgYnV0IEkgbWlzc2VkIHRoZSBpbXBsaWNhdGlv bnMgb2Ygc29tZSBvZiB0aGUgdGV4dDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mZ3Q7IDEpIExvdyBlbmQgZGV2aWNlcyB0aGF0IG9ubHkgc3VwcG9ydCBPUEM7 IHRoaXMgbWVhbnMgbm8gVExTIGNsaWVudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBjYXBhYmlsaXRpZXMgYW5kIG5vIGFiaWxpdHkgdG8g aW5pdGlhdGUgbmV0d29yayBjb21tdW5pY2F0aW9uIChpLmUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IHNlcnZlciBvbmx5IG1vZGUpOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0Ozxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEhvdyBkb2VzIE9QQyBoYW5k bGUgc3VjaCBkZXZpY2VzPyZuYnNwOyBJIHRoaW5rIHRoaXMgaXMgYWxzbyBjb21pbmcgdXAgZWxz ZXdoZXJlLiZuYnNwOyBPbmUgcXVlc3Rpb24gaXMgd2hldGhlciBUTFMgaXMgcmVxdWlyZWQuJm5i c3A7IFdpdGhvdXQgVExTIG9uZSBkb2VzIGxvc2UgY29uZmlkZW50aWFsaXR5LCBidXQgc28gbG9u ZyBhcyB0aGUgY2xpZW50IGNhbiBzaWduIHRoZSByZXF1ZXN0LCBtYXliZSB0aGF0Pz8/cyBhbGwg eW91DQogdXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyAyKSBNYWNoaW5lIGJ1 aWxkZXJzIHRoYXQgY29tYmluZSBkZXZpY2VzIGludG8gYSBtYWNoaW5lIHRoYXQgaXMgc29sZCBh cyBhIHVuaXQuIFRoZXNlIGRldmljZSBzdGlsbCBoYXZlIGEgdW5pcXVlIG5ldHdvcmsgaWRlbnRp dHkgYnV0IHRoZSBlZmZlY3RpdmUgbWFudWZhY3R1cmVyIGhhcyBjaGFuZ2VkOyBIb3cgdG8gZGVh bCB3aXRoIHRoZSBEZXZpY2VJRD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0OyBBdCBzb21lIHBvaW50LCB0aGUgdGhpbmcgZGVjaWRlcyB3aGljaCBwYXJ0IGdldHMgYW4g SVAgYWRkcmVzcyBvciBhdCBsZWFzdCBpcyByZXNwb25zaWJsZSBmb3IgdGhlIHBoeS4mbmJzcDsg Q2FuIHRoYXQgcHJvY2VzcyBiZSBsZXZlcmFnZWQgdG8gZXN0YWJsaXNoIGlkZW50aXR5PzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDsgMykgRGV2aWNlcyBtYXkgYmUgcmVzZXQgdG8gZmFjdG9yeSBk ZWZhdWx0cyBhbmQgc29sZC90cmFuc2ZlcnJlZCB0byBhbm90aGVyIG9yZ2FuaXphdGlvbi4gVGhp cyBuZWVkcyB0byBiZSBwb3NzaWJsZSBldmVuIGlmIHRoZSBNQVNBIGlzIG5vIGxvbmdlciBhdmFp bGFibGUgKGkuZS4gdGhlIG9yaWdpbmFsIG1hbnVmYWN0dXJlciBoYXMgZ29uZSBvdXQgb2YgYnVz aW5lc3MpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsg T25lIHBvc3NpYmxlIHZpZXcgaGVyZSBpcyB0aGF0IHRoZSBNQVNBIG1heSBiZSBvZmZsaW5lLCBh bmQgbWF5IGhhdmUgcHJvdmlkZWQgYSB2b3VjaGVyIHZpYSBvZmZsaW5lIG1lYW5zIHRvIHRoZSBq b2luIHJlZ2lzdHJhci4mbmJzcDsgVGhpcyBvZiBjb3Vyc2Ugd291bGQgYmUgbm9uY2VsZXNzIHdp dGggYSBsZW5ndGh5IGV4cGlyeSB0aW1lLiZuYnNwOyBJbiBhZGRpdGlvbiwgSSBwb3NpdGVkIGR1 cmluZyBCUlNLST8/P3MgcmV2aWV3DQogdGhhdCBwZXJoYXBzIHRoZSBkZXZpY2Ugc2hvdWxkIGJl IGFibGUgdG8gZ2VuZXJhdGUgaXRzIG93biBjZXJ0aWZpY2F0ZSB2aWEgYSBoaWdoZXIgbGV2ZWwg aW50ZXJmYWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyA0KSBPZmZsaW5lIG9w ZXJhdGlvbiBpcyB0aGUgbm9ybSB3aXRoIHByZS1pc3N1ZWQgdm91Y2hlcnMgZGVsaXZlcmVkIG91 dCBvZiBiYW5kLiBUaGUgcHJlLWlzc3VlZCB2b3VjaGVycyB3aWxsIG5lZWQgdG8gaGF2ZSByZWFz b25hYmx5IGxvbmcgbGlmZXRpbWUgKGkuZS4geWVhcnMgbm90IGhvdXJzKS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFRoZSBsaWZlY3ljbGUgb2YgYSBk ZXZpY2UgaXMgc2hvd24gaW4gdGhlIGZvbGxvd2luZyBkaWFncmFtLiBUaGU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgZXhwZWN0YXRpb24g aXMgd2Ugd291bGQgbmVlZCB0byBhZGQgbGlua3MgdG8gdGhlIE1BU0EgYXQgZWFjaCBzdGVwIGlu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 IHRoZSBsaWZldGltZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFRo YW5rIHlvdSBmb3IgdGhhdC4mbmJzcDsgRm9yIHdpcmVkIGl0IHNlZW1zIHRvIG1lIHRoYXQgYSBw ZXJtaXNzaXZlIE1BU0EgbW9kZWwgKGxvZ2dpbmcgb25seSkgY291bGQgcHJvdmlkZSB5b3UgYSB3 YXkgZm9yd2FyZC4mbmJzcDsgRm9yIHdpcmVsZXNzLCB0aGlzIGlzIG5vdCBhbiBvcHRpb24gYmVj YXVzZSBwcm9wZXIgbmV0d29yayBzZWxlY3Rpb24gbmVlZHMgdG8gb2NjdXIuJm5ic3A7IEFub3Ro ZXIgcXVlc3Rpb24gaXMgd2hldGhlcg0KIHdlIG5lZWQgYW5vdGhlciBtZWNoYW5pc20gaXMgbmVj ZXNzYXJ5IHRvIHZhbGlkYXRlIHRoZSB2b3VjaGVyIChha2EsIGEgUFNLIHcvIHByb29mIG9mIGtu b3dsZWRnZSwgb3IgRFBQLCBldGMpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZndDsgQ2FuIHlvdSBzYXkgbW9yZSBhYm91dCB3aGF0IG1lY2hhbmlzbXMgT1BD IGlzIGludGVyZXN0ZWQgaW4gcHVyc3Vpbmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0OyBFbGlvdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0OyAtLTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJb3Qtb25ib2FyZGluZyBtYWlsaW5nIGxpc3Q8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv OklvdC1vbmJvYXJkaW5nQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0 ZXh0LWRlY29yYXRpb246bm9uZSI+SW90LW9uYm9hcmRpbmdAaWV0Zi5vcmc8L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0Ozxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lvdC1vbmJvYXJkaW5nIj48c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pb3Qtb25ib2FyZGluZzwvc3Bhbj48L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS08 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS08bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0 bzp0dGVAY3MuZmF1LmRlIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29y YXRpb246bm9uZSI+dHRlQGNzLmZhdS5kZTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BYAPR08MB4903C95973435BA06FC3C080FAD40BYAPR08MB4903namp_-- From nobody Wed Aug 7 01:50:32 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECAF7120043; Wed, 7 Aug 2019 01:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.49 X-Spam-Level: X-Spam-Status: No, score=-14.49 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzymkxpRa3Fm; Wed, 7 Aug 2019 01:50:25 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0CED1202C6; Wed, 7 Aug 2019 01:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57068; q=dns/txt; s=iport; t=1565167825; x=1566377425; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=M1Cbyi3G1++/BZe6/trPqIo4LR8qJH02Mc5MiEHBNUw=; b=WcCLFKHaNkf4M6PnvCGWBVhS+vnNKuIdPGYOcAgdOXZN5uFk+TQO90ZV w2iB8xerqKgQYiadkT2JPGCj5wmqt+JFDnnkwVZy7EGNioDpFJHDCRPYe GBX/Aj7l9FSSCGu5zWkls+DGDiOAKpsiXuf9UkMnhnnGm5+yacLevueXe U=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAACBkEpd/xbLJq1dCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVMEAQEBAQELAYEVU4EcUiASKoQeiBxgiFqHN5FUFIF?= =?us-ascii?q?jBAIHAQEBCQMBARgBCgwBAYQ/AoJiNAkOAQQBAQQBAQIBBm2FJwyFSgEBAQE?= =?us-ascii?q?CAQEBGAlIAwsFBwQLEQQBAQEgAQYDAgInHwkIBgoJgyIBgXsPD6opgTKFSYR?= =?us-ascii?q?zCgaBNAGBUIoqgX+BEScfgU5+PoJhAQECgSMSEwFMglUygiYEjA0gGohGh3i?= =?us-ascii?q?OJwmCHoIfgQ+QdBuCL4cug2uGUYQYnwGDMoMOAgQGBQIVgVA4KoEuMxoIGxU?= =?us-ascii?q?7KgGCQT6BDYl8hUE9AzABAYxSK4IlAQE?= X-IronPort-AV: E=Sophos;i="5.64,357,1559520000"; d="asc'?scan'208,217";a="15182752" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Aug 2019 08:50:21 +0000 Received: from [10.61.221.4] ([10.61.221.4]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x778oKRe031089 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Aug 2019 08:50:21 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_19E25135-3EFB-4DFE-90BE-86883FF221E4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 7 Aug 2019 10:50:19 +0200 In-Reply-To: Cc: Toerless Eckert , "iot-onboarding@ietf.org" , "anima@ietf.org" To: "Randy Armstrong (OPC)" References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <20190806223052.md5lp6yeleuvuf5l@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.221.4, [10.61.221.4] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Anima] [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 08:50:30 -0000 --Apple-Mail=_19E25135-3EFB-4DFE-90BE-86883FF221E4 Content-Type: multipart/alternative; boundary="Apple-Mail=_94A57D11-99F6-47CF-95E7-76E116BE3AE7" --Apple-Mail=_94A57D11-99F6-47CF-95E7-76E116BE3AE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Randy, Thanks again for your comments. Please see below. > On 7 Aug 2019, at 10:32, Randy Armstrong (OPC) = wrote: >=20 > Hi Eliot, >=20 > 1) In an OPC UA environment, might one expect that the join registrar = and the certificate manager be co-resident? >=20 > Yes that is the expectation. >=20 > 2) My bigger question is whether you want to use all of this for = network authentication to avoid unauthorized devices joining the network = in the first place, or whether this is intended solely for application = authentication. >=20 > Counterfeit devices are huge issue in industrial automation. We need = this infrastructure so the Operators can assure themselves that the = Devices they plug into their network are genuine. >=20 > OTOH, Operators don=E2=80=99t need to prove their right to use a = Device. If an Operator has a Device they are entitled to use it (i.e. = Devices can be sold/transferred without approval from the manufacturer). The purpose, as I see it, of the voucher, is simply to provide = zero-touch network provisioning. I was asking a slightly different = question: for purposes of network connectivity will operators want to = know that only devices they authorized are connecting (e.g., 802.1X and = then like)? This is a natural assumption in the wireless world, but = less so in wired. Eliot >=20 > Regards, >=20 > Randy >=20 >=20 > From: Eliot Lear > Sent: August 7, 2019 12:33 AM > To: Randy Armstrong (OPC) > Cc: Toerless Eckert ; iot-onboarding@ietf.org; = anima@ietf.org > Subject: Re: [Iot-onboarding] OPC and BRSKI >=20 > Randy, >=20 > Thanks. We have irregular calls, but I will poll for one in the 3rd = week of August to discuss your use case. >=20 > In an OPC UA environment, might one expect that the join registrar and = the certificate manager be co-resident? This would be where EST/SCEP = would happen (BRSKI can be viewed as an extension to EST - RFC 7030). = There is no "push mode" for EST. However, my understanding is that the = same capability roughly speaking resides in CIP. >=20 > My bigger question is whether you want to use all of this for network = authentication to avoid unauthorized devices joining the network in the = first place, or whether this is intended solely for application = authentication. >=20 > Eliot >=20 >=20 >=20 > On 7 Aug 2019, at 01:19, Randy Armstrong (OPC) = > wrote: >=20 > Push should be =E2=80=9CCertificate Manager initiated=E2=80=9D >=20 > From: Iot-onboarding > On Behalf Of Randy Armstrong = (OPC) > Sent: August 6, 2019 4:17 PM > To: Toerless Eckert > > Cc: iot-onboarding@ietf.org ; = anima@ietf.org ; Eliot Lear > > Subject: Re: [Iot-onboarding] OPC and BRSKI >=20 > Hi >=20 > 1) Sure, need to understand how TCP UA works wih the minimum amount of = message authentication to allow for BRSKI. Main challenge may be the = need for pledges to receive messages from registrar that are = authenticated by the registar, but where the pledge has to wait until it = can actually perform the authentication later. Depending on how you = built TCP UA message layer authentication this may be piece of cake / = free or not. >=20 > It would be easy to drop in a OPC UA aware registrar and implement all = of the BRKSI flows back to the MASA. The only nuisance factor is the = 'prior-signed-voucher-request'.. If MASA's are willing allow this field = to be omitted and to trust the Registrar then nothing more needs to = done. If MASA's need this field then we could get it from the Device via = OPC UA but producing the CMS message adds an additional burden on low = end devices (i.e. the need to pull in libraries that provide the same = functionality as OPC UA but do it in different format). >=20 > The 2 modes of operation with a OPC UA aware registrar (the = Certificate Manager is an OPC UA defined entity). >=20 > Pull (device initiated) >=20 > >=20 > Push (Registrar initiated) >=20 > >=20 > Regards, >=20 > Randy >=20 > -----Original Message----- > From: Toerless Eckert > > Sent: August 6, 2019 3:31 PM > To: Randy Armstrong (OPC) > > Cc: Eliot Lear >; = iot-onboarding@ietf.org ; anima@ietf.org = > Subject: Re: [Iot-onboarding] OPC and BRSKI >=20 > On Tue, Aug 06, 2019 at 09:32:45PM +0000, Randy Armstrong (OPC) wrote: > > OPC is layered to separate the application from the choice of = network protocol. TLS/WebSockets is an option but the primary protocol = that will be used by low end devices is UA TCP which provides complete = message based security framework. These devices do not need TLS to have = security and requiring it would require duplication of code. >=20 > Sure, need to understand how TCP UA works wih the minimum amount of = message authentication to allow for BRSKI. Main challenge may be the = need for pledges to receive messages from registrar that are = authenticated by the registar, but where the pledge has to wait until it = can actually perform the authentication later. Depending on how you = built TCP UA message layer authentication this may be piece of cake / = free or not. >=20 > > 2) At some point, the thing decides which part gets an IP address or = at least is responsible for the phy. Can that process be leveraged to = establish identity? > > > > Machines may have a separate network for internal Devices which IPs = assigned by the machine???s DHCP service. Some of these devices may = interact with external equipment via a NAT router which assigns a unique = port to each device. This means the individual Devices need to be = granted access to the operators network when the machine is installed = even though the operator cannot provide them with IPs. > > > > I need to consult with our machine experts to better explain this = use case. >=20 > Primary questions seem to be whether this is just about authentication = at the TCP UA layer or further below at some implied NAC mechanism. >=20 > > 3) One possible view here is that the MASA may be offline, and may = have provided a voucher via offline means to the join registrar. This = of course would be nonceless with a lengthy expiry time. In addition, I = posited during BRSKI???s review that perhaps the device should be able = to generate its own certificate via a higher level interface. > > > > OPC already has APIs needed to manage Certificates on a Device. The = link to something like the MASA is what we are missing. Nonceless = vouchers that do not expire should allow local registrar to emulate a = MASA when the MASA is no longer available. I wanted to make sure that = this mode of operation is allowed BRSKI. >=20 > Yes it is, it may just not be fully specified in the current targeted = BRSKI RFC that we feel everybody who wants to implement it has = everything to do so, but thats would just be subjet to future small RFC = to close any possible gaps. >=20 > > 4) Can you say more about what mechanisms OPC is interested in = pursuing? > > > > With OPC we assume that network selection and IP assignment are out = of scope. Wired devices are the primary market at this time but 5G could = change that. >=20 > BRSKI also does not care about Addressing. Only ACP does, so you can = ignore that part if you're not interested in. We have tried to separate = out ACP specific aspects in the BRSKI document as good as possible with = the somewhat convoluted process we had in the IETF how to drive those = documents. >=20 > Cheers > Toerless >=20 > > Regards, > > > > Randy > > > > From: Eliot Lear > > > Sent: August 6, 2019 1:47 PM > > To: Randy Armstrong (OPC) > > > Cc: iot-onboarding@ietf.org > > Subject: Re: [Iot-onboarding] OPC and BRSKI > > > > Hi Randy, > > > > Thanks for this. It???s a great starting point. I would propose = that we do a call so we can get some high bandwidth discussion going. = Please now see below. > > > > > > On 6 Aug 2019, at 20:58, Randy Armstrong (OPC) = >> wrote: > > > > I will start with the main trouble spots. Some of these may be = already covered by BRKSI but I missed the implications of some of the = text: > > > > 1) Low end devices that only support OPC; this means no TLS client > > capabilities and no ability to initiate network communication (i.e. > > server only mode); > > > > > > How does OPC handle such devices? I think this is also coming up = elsewhere. One question is whether TLS is required. Without TLS one = does lose confidentiality, but so long as the client can sign the = request, maybe that???s all you use. > > > > > > > > 2) Machine builders that combine devices into a machine that is sold = as a unit. These device still have a unique network identity but the = effective manufacturer has changed; How to deal with the DeviceID? > > > > > > At some point, the thing decides which part gets an IP address or at = least is responsible for the phy. Can that process be leveraged to = establish identity? > > > > > > > > > > 3) Devices may be reset to factory defaults and sold/transferred to = another organization. This needs to be possible even if the MASA is no = longer available (i.e. the original manufacturer has gone out of = business). > > > > One possible view here is that the MASA may be offline, and may have = provided a voucher via offline means to the join registrar. This of = course would be nonceless with a lengthy expiry time. In addition, I = posited during BRSKI???s review that perhaps the device should be able = to generate its own certificate via a higher level interface. > > > > > > > > 4) Offline operation is the norm with pre-issued vouchers delivered = out of band. The pre-issued vouchers will need to have reasonably long = lifetime (i.e. years not hours). > > > > The lifecycle of a device is shown in the following diagram. The > > expectation is we would need to add links to the MASA at each step = in > > the lifetime > > > > > > Thank you for that. For wired it seems to me that a permissive MASA = model (logging only) could provide you a way forward. For wireless, = this is not an option because proper network selection needs to occur. = Another question is whether we need another mechanism is necessary to = validate the voucher (aka, a PSK w/ proof of knowledge, or DPP, etc). > > > > Can you say more about what mechanisms OPC is interested in = pursuing? > > > > Eliot > > >=20 > > -- > > Iot-onboarding mailing list > > Iot-onboarding@ietf.org > > https://www.ietf.org/mailman/listinfo/iot-onboarding = >=20 >=20 > -- > --- > tte@cs.fau.de --Apple-Mail=_94A57D11-99F6-47CF-95E7-76E116BE3AE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Randy,

Thanks again = for your comments.  Please see below.

On 7 Aug = 2019, at 10:32, Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org> wrote:

Hi = Eliot,
 
1) In an OPC UA environment, might one expect that the join = registrar and the certificate manager be co-resident?  
 
Yes that is the expectation.
 
2) My bigger question is whether you = want to use all of this for network authentication to avoid unauthorized = devices joining the network in the first place, or whether this is = intended solely for application authentication.
 
Counterfeit devices are huge issue in industrial automation. = We need this infrastructure so the Operators can assure themselves that = the Devices they plug into their network are genuine.
 
OTOH,= Operators don=E2=80=99t need to prove their right to use a Device. If = an Operator has a Device they are entitled to use it (i.e. Devices can = be sold/transferred without approval from the = manufacturer).


The purpose, as I see = it, of the voucher, is simply to provide zero-touch network = provisioning.  I was asking a slightly different question: for = purposes of network connectivity will operators want to know that only = devices they authorized are connecting (e.g., = 802.1X and then like)?  This is a natural assumption in the = wireless world, but less so in wired.

Eliot

 
Regards,
 
Randy
 
 
From: Eliot Lear = <lear@cisco.com> 
Sent: August 7, 2019 12:33 AM
To: Randy Armstrong (OPC) = <randy.armstrong@opcfoundation.org>
Cc: Toerless Eckert <tte@cs.fau.de>; iot-onboarding@ietf.org; anima@ietf.org
Subject: Re: [Iot-onboarding] OPC = and BRSKI
 
Randy,
 
Thanks.  We have irregular calls, but I will poll for = one in the 3rd week of August to discuss your use case.
 
In an OPC UA environment, might one = expect that the join registrar and the certificate manager be = co-resident?  This would be where EST/SCEP would happen (BRSKI can = be viewed as an extension to EST - RFC 7030).  There is no "push = mode" for EST.  However, my understanding is that the same = capability roughly speaking resides in CIP.
 
My bigger question is whether you want = to use all of this for network authentication to avoid unauthorized = devices joining the network in the first place, or whether this is = intended solely for application authentication.
 
Eliot
 


On 7 Aug 2019, at 01:19, Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org> wrote:
 
Push should be =E2=80=9CCertificate = Manager initiated=E2=80=9D
 
From: Iot-onboarding <iot-onboarding-bounces@ietf.org> On Behalf = Of Randy Armstrong = (OPC)
Sent: August 6, 2019 4:17 PM
To: Toerless Eckert <tte@cs.fau.de>
Cc: iot-onboarding@ietf.org; anima@ietf.org; Eliot Lear <lear@cisco.com>
Subject: Re: [Iot-onboarding] OPC = and BRSKI
 
Hi 
 
1) Sure, need to understand how TCP UA = works wih the minimum amount of message authentication to allow for = BRSKI. Main challenge may be the need for pledges to receive messages = from registrar that are authenticated by the registar, but where the = pledge has to wait until it can actually perform the authentication = later. Depending on how you built TCP UA message layer authentication = this may be piece of cake / free or not.
 
It would be easy to drop in a OPC UA aware registrar and = implement all of the BRKSI flows back to the MASA. The only nuisance = factor is the 'prior-signed-voucher-request'.. If MASA's are willing = allow this field to be omitted and to trust the Registrar then nothing = more needs to done. If MASA's need this field then we could get it from = the Device via OPC UA but producing the CMS message adds an additional = burden on low end devices (i.e. the need to pull in libraries that = provide the same functionality as OPC UA but do it in different = format).
 
The 2 modes of operation with a OPC UA aware registrar (the = Certificate Manager is an OPC UA defined entity).
 
Pull (device initiated)
 
<image005.png>
 
Push (Registrar initiated)
 
<image006.png>
 
Regards,
 
Randy
 
-----Original Message-----
From: Toerless = Eckert <tte@cs.fau.de> 
Sent: August = 6, 2019 3:31 PM
To: Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org>
Cc: Eliot Lear <lear@cisco.com>; iot-onboarding@ietf.org; anima@ietf.org
Subject: Re: = [Iot-onboarding] OPC and BRSKI
 
On Tue, Aug 06, 2019 at 09:32:45PM = +0000, Randy Armstrong (OPC) wrote:
> OPC is layered to = separate the application from the choice of network protocol. = TLS/WebSockets is an option but the primary protocol that will be used = by low end devices is UA TCP which provides complete message based = security framework.  These devices do not need TLS to have security = and requiring it would require duplication of code.
 
Sure, need to understand how TCP UA = works wih the minimum amount of message authentication to allow for = BRSKI. Main challenge may be the need for pledges to receive messages = from registrar that are authenticated by the registar, but where the = pledge has to wait until it can actually perform the authentication = later. Depending on how you built TCP UA message layer authentication = this may be piece of cake / free or not.
 
> 2) At some point, the thing = decides which part gets an IP address or at least is responsible for the = phy.  Can that process be leveraged to establish identity?
> 
> Machines may have a separate network for internal = Devices which IPs assigned by the machine???s DHCP service. Some of = these devices may interact with external equipment via a NAT router = which assigns a unique port to each device. This means the individual = Devices need to be granted access to the operators network when the = machine is installed even though the operator cannot provide them with = IPs.
> 
> I need to consult with our machine experts to better = explain this use case.
 
Primary questions seem to be whether this is just about = authentication at the TCP UA layer or further below at some implied NAC = mechanism.
 
> 3) One possible view here is that the MASA may be = offline, and may have provided a voucher via offline means to the join = registrar.  This of course would be nonceless with a lengthy expiry = time.  In addition, I posited during BRSKI???s review that perhaps = the device should be able to generate its own certificate via a higher = level interface.
> 
> OPC already has APIs needed to manage Certificates on a = Device. The link to something like the MASA is what we are missing. = Nonceless vouchers that do not expire should allow local registrar to = emulate a MASA when the MASA is no longer available. I wanted to make = sure that this mode of operation is allowed BRSKI.
 
Yes it is, it may just not be fully = specified in the current targeted BRSKI RFC that we feel everybody who = wants to implement it has everything to do so, but thats would just be = subjet to future small RFC to close any possible gaps.
 
> 4) Can you say more about what = mechanisms OPC is interested in pursuing?
> 
> With OPC we assume that network selection and IP = assignment are out of scope. Wired devices are the primary market at = this time but 5G could change that.
 
BRSKI also does not care about Addressing. Only ACP does, so = you can ignore that part if you're not interested in. We have tried to = separate out ACP specific aspects in the BRSKI document as good as = possible with the somewhat convoluted process we had in the IETF how to = drive those documents.
 
Cheers
    Toerless
 
> Regards,
> 
> Randy
> 
> From: Eliot Lear <lear@cisco..com>
> Sent: August 6, 2019 1:47 PM
> To: Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org>
> Subject: Re: [Iot-onboarding] OPC and BRSKI
> 
> Hi Randy,
> 
> Thanks for this.  It???s a great starting = point.  I would propose that we do a call so we can get some high = bandwidth discussion going.  Please now see below.
> 
> 
> On 6 Aug 2019, at 20:58, Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org<mailto:randy.armstrong@opc= foundation.org>> wrote:
> 
> I will start with the main trouble spots. Some of these = may be already covered by BRKSI but I missed the implications of some of = the text:
> 
> 1) Low end devices that only support OPC; this means no = TLS client
> capabilities and no ability to = initiate network communication (i.e.
> server only = mode);
> 
> 
> How does OPC handle such devices?  I think this is = also coming up elsewhere.  One question is whether TLS is = required.  Without TLS one does lose confidentiality, but so long = as the client can sign the request, maybe that???s all you use.
> 
> 
> 
> 2) Machine builders that combine devices into a machine = that is sold as a unit. These device still have a unique network = identity but the effective manufacturer has changed; How to deal with = the DeviceID?
> 
> 
> At some point, the thing decides which part gets an IP = address or at least is responsible for the phy.  Can that process = be leveraged to establish identity?
> 
> 
> 
> 
> 3) Devices may be reset to factory defaults and = sold/transferred to another organization. This needs to be possible even = if the MASA is no longer available (i.e. the original manufacturer has = gone out of business).
> 
> One possible view here is that the MASA may be offline, = and may have provided a voucher via offline means to the join = registrar.  This of course would be nonceless with a lengthy expiry = time.  In addition, I posited during BRSKI???s review that perhaps = the device should be able to generate its own certificate via a higher = level interface.
> 
> 
> 
> 4) Offline operation is the norm with pre-issued = vouchers delivered out of band. The pre-issued vouchers will need to = have reasonably long lifetime (i.e. years not hours).
> 
> The lifecycle of a device is shown in the following = diagram. The
> expectation is we would need to = add links to the MASA at each step in
> the lifetime
> 
> 
> Thank you for that.  For wired it seems to me that = a permissive MASA model (logging only) could provide you a way = forward.  For wireless, this is not an option because proper = network selection needs to occur.  Another question is whether we = need another mechanism is necessary to validate the voucher (aka, a PSK = w/ proof of knowledge, or DPP, etc).
> 
> Can you say more about what mechanisms OPC is interested = in pursuing?
> 
> Eliot
> 
 
> --
> Iot-onboarding mailing list
 
 
-- 
---
tte@cs.fau.de

= --Apple-Mail=_94A57D11-99F6-47CF-95E7-76E116BE3AE7-- --Apple-Mail=_19E25135-3EFB-4DFE-90BE-86883FF221E4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXUqQywAKCRBugA9nE248 uB+3AKCCrRC5F/HZCJhApPPZk/t6UDIcowCfRy6nCn/x4Ps7DRhG073nBqf5hY0= =oQQ8 -----END PGP SIGNATURE----- --Apple-Mail=_19E25135-3EFB-4DFE-90BE-86883FF221E4-- From nobody Wed Aug 7 01:58:05 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD08120316; Wed, 7 Aug 2019 01:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=opcfoundation.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 sdXyS_Oksjep; Wed, 7 Aug 2019 01:57:56 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780075.outbound.protection.outlook.com [40.107.78.75]) (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 E2F8B12030A; Wed, 7 Aug 2019 01:57:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EHKxRJQWRZe46Wo8u+Tp1yB0eWkQWdHmSxuIxjZ2fI+tdPDkAY8jMqdbFU+0Wxtga5lPtfw1pjuU2IW8g6C6gwIs5ZIPN5MKSzY4XWxXqLx1tsW0R/TWp8091VLeCaEQSCf+8iKeICNQMFskr+sBIF0aVFqY8DaohJUHFHMXJ6/dF6ajTNkxRUkptgJlyMIn8SQDuezAxfKeBsRo/mq9WrJjj8bla5FRWEKZ33HBetjzYPGL+2llMEzKeXdiY/x3AWsh5fH22QNBCqmW6RIHguCxL1g5lOKgh3SyN2SMdy8DuN+I2laZIh/947w83N1azHt5RpXCjdye6d9a9fQ90w== 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=SCwbbCM5G14y82mpEl0t1epxYZ05XscygeWAT9ujJ+Y=; b=LGMKikcawLLWq07LfASmMfFa+g8rYniYjTKzSO7EljqUa/LKfUpm1vnWIO9ADu8IcD2oSne0TLb5OeqtuwGWq4XfodRSIwDvoeD+MaDnK+mwDv8/cbnaA8IgzRC2UxEdZt84JO1NJ5UXe/ERI5KAc5qFzx3n6WydNx12/zt8fce09jhb8eie+Pf5rstS95kO9XG+RpsJxRqCO6Z/rQ6W+WW5FmT4uFaPMAUVM/lgfEZmAnN/wylVMID5xu+H6Ym6wOkSuaNZmgCUiyGg+3dQLHhyRHXbFzVESVTuMsRrP/6jZaFdxM+dbhpPeJGsOUffOZOsjbNQ3pNZjb2Lo3y/kw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=opcfoundation.org;dmarc=pass action=none header.from=opcfoundation.org;dkim=pass header.d=opcfoundation.org;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opcfoundation.onmicrosoft.com; s=selector1-opcfoundation-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SCwbbCM5G14y82mpEl0t1epxYZ05XscygeWAT9ujJ+Y=; b=E49GhFEugSfXAT1hr6XU81vKnKKb/xb4A3CSVQPC/dMZuxdGJKHqWUz4V0Z93gRkIyguj4Nl58VKFlaplWDbILbYYmxkD8xo5GvyM0GUVnLmCLl62tp3P2TTfoQd03m3q2hG/i8eMRVlsEcqTUZYDgnfb+qGlh9A31lgpVEKoP4= Received: from BYAPR08MB4903.namprd08.prod.outlook.com (20.176.255.96) by BYAPR08MB4934.namprd08.prod.outlook.com (20.176.255.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.15; Wed, 7 Aug 2019 08:57:53 +0000 Received: from BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53]) by BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53%4]) with mapi id 15.20.2157.015; Wed, 7 Aug 2019 08:57:53 +0000 From: "Randy Armstrong (OPC)" To: Eliot Lear CC: Toerless Eckert , "iot-onboarding@ietf.org" , "anima@ietf.org" Thread-Topic: [Iot-onboarding] OPC and BRSKI Thread-Index: AdVMZzs5EDHMP+c/QWCVcWuK34MU/QAGrJ8AAADfarAABKcngAAAO+sQAANovwAAARHHUAAAmp+QABFFfIAAAX6+0AABMbGAAAAWWhA= Date: Wed, 7 Aug 2019 08:57:53 +0000 Message-ID: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <20190806223052.md5lp6yeleuvuf5l@faui48f.informatik.uni-erlangen.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=randy.armstrong@opcfoundation.org; x-originating-ip: [24.80.80.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 438e9c70-4d4a-49e4-435e-08d71b155558 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR08MB4934; x-ms-traffictypediagnostic: BYAPR08MB4934: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(136003)(366004)(39840400004)(199004)(189003)(13464003)(508600001)(33656002)(4326008)(14454004)(966005)(25786009)(6246003)(8936002)(81166006)(81156014)(8676002)(7736002)(606006)(6916009)(229853002)(74316002)(54896002)(6306002)(55016002)(236005)(9686003)(6436002)(53936002)(66066001)(66574012)(2906002)(86362001)(5660300002)(30864003)(102836004)(99286004)(76176011)(71190400001)(71200400001)(316002)(186003)(54906003)(26005)(446003)(486006)(11346002)(476003)(68736007)(6506007)(53546011)(7696005)(66946007)(76116006)(256004)(14444005)(66446008)(3846002)(52536014)(64756008)(6116002)(66556008)(790700001)(66476007); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR08MB4934; H:BYAPR08MB4903.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: opcfoundation.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: aQBVQy6JcAFscf8y+O7WkjbUULavR7NYFUmruEyOoR5De4CQoy5s2tcR2gTuSuPCYok+D1khf3iyDynGl7dkQ6ixCBNLULWtZnAyApam/dS55DVRA42+rtIOED2IG/WrTCraTDt6JLFhlNnnXUtmS6Itp5gq3WfcmNBMCHDqmgh3NO+ZtJK5qk6txhOkkTIaUKPxWfq1DIYd/FDSO6Pxx19hMJtebRFC088cS5n1rur/85SZvYfRX2PbyveuWqurb1aK910+ohiDh7E72AkVddu3KgduQwzCjH4aJyp0XvvnVVzzGq7zBTn/LPT9EX9aPuDibb+EVDxwcUzSfP5sTncOqHiOQXbU70BYVCCIEaxPwkZ2xDa7NHPjlPVoS2U1dHb6N6MM+uAkE/obpypCnryp5COO09C1MwTTYqZQkxQ= Content-Type: multipart/alternative; boundary="_000_BYAPR08MB4903DC283780FC3519F4432BFAD40BYAPR08MB4903namp_" MIME-Version: 1.0 X-OriginatorOrg: opcfoundation.org X-MS-Exchange-CrossTenant-Network-Message-Id: 438e9c70-4d4a-49e4-435e-08d71b155558 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2019 08:57:53.5316 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2d8ef4e4-d41c-489c-8004-bb99304b60fe X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rAupcO8mKMvr5qYiA06OdNQjtX/Zf2Ex4cr3UooJpHLeHxpOLiuu36lq9P/PHT9xheiaO/Bkd8LqXEpyIROMHi9VV6BREtzWZXG5g6cMU/z7rPL0tZrBzarUJ06I8TOO X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4934 Archived-At: Subject: Re: [Anima] [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 08:58:02 -0000 --_000_BYAPR08MB4903DC283780FC3519F4432BFAD40BYAPR08MB4903namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SEkgRWxpb3QsDQoNClllcywgdGhlIE9wZXJhdG9yIG5lZWRzIHRvIGVuc3VyZSB0aGF0IG9ubHkg RGV2aWNlcyB0aGV5IGF1dGhvcml6ZSBjYW4gY29ubmVjdCBhbmQgdGhlIHplcm8gdG91Y2ggcHJv dmlzaW9uaW5nIGlzIGEgZmVhdHVyZSB3ZSBkZXNpcmUuDQoNClJlZ2FyZHMsDQoNClJhbmR5DQoN CkZyb206IEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPg0KU2VudDogQXVndXN0IDcsIDIwMTkg MTo1MCBBTQ0KVG86IFJhbmR5IEFybXN0cm9uZyAoT1BDKSA8cmFuZHkuYXJtc3Ryb25nQG9wY2Zv dW5kYXRpb24ub3JnPg0KQ2M6IFRvZXJsZXNzIEVja2VydCA8dHRlQGNzLmZhdS5kZT47IGlvdC1v bmJvYXJkaW5nQGlldGYub3JnOyBhbmltYUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtJb3Qtb25i b2FyZGluZ10gT1BDIGFuZCBCUlNLSQ0KDQpIaSBSYW5keSwNCg0KVGhhbmtzIGFnYWluIGZvciB5 b3VyIGNvbW1lbnRzLiAgUGxlYXNlIHNlZSBiZWxvdy4NCg0KDQpPbiA3IEF1ZyAyMDE5LCBhdCAx MDozMiwgUmFuZHkgQXJtc3Ryb25nIChPUEMpIDxyYW5keS5hcm1zdHJvbmdAb3BjZm91bmRhdGlv bi5vcmc8bWFpbHRvOnJhbmR5LmFybXN0cm9uZ0BvcGNmb3VuZGF0aW9uLm9yZz4+IHdyb3RlOg0K DQpIaSBFbGlvdCwNCg0KMSkgSW4gYW4gT1BDIFVBIGVudmlyb25tZW50LCBtaWdodCBvbmUgZXhw ZWN0IHRoYXQgdGhlIGpvaW4gcmVnaXN0cmFyIGFuZCB0aGUgY2VydGlmaWNhdGUgbWFuYWdlciBi ZSBjby1yZXNpZGVudD8NCg0KWWVzIHRoYXQgaXMgdGhlIGV4cGVjdGF0aW9uLg0KDQoyKSBNeSBi aWdnZXIgcXVlc3Rpb24gaXMgd2hldGhlciB5b3Ugd2FudCB0byB1c2UgYWxsIG9mIHRoaXMgZm9y IG5ldHdvcmsgYXV0aGVudGljYXRpb24gdG8gYXZvaWQgdW5hdXRob3JpemVkIGRldmljZXMgam9p bmluZyB0aGUgbmV0d29yayBpbiB0aGUgZmlyc3QgcGxhY2UsIG9yIHdoZXRoZXIgdGhpcyBpcyBp bnRlbmRlZCBzb2xlbHkgZm9yIGFwcGxpY2F0aW9uIGF1dGhlbnRpY2F0aW9uLg0KDQpDb3VudGVy ZmVpdCBkZXZpY2VzIGFyZSBodWdlIGlzc3VlIGluIGluZHVzdHJpYWwgYXV0b21hdGlvbi4gV2Ug bmVlZCB0aGlzIGluZnJhc3RydWN0dXJlIHNvIHRoZSBPcGVyYXRvcnMgY2FuIGFzc3VyZSB0aGVt c2VsdmVzIHRoYXQgdGhlIERldmljZXMgdGhleSBwbHVnIGludG8gdGhlaXIgbmV0d29yayBhcmUg Z2VudWluZS4NCg0KT1RPSCwgT3BlcmF0b3JzIGRvbuKAmXQgbmVlZCB0byBwcm92ZSB0aGVpciBy aWdodCB0byB1c2UgYSBEZXZpY2UuIElmIGFuIE9wZXJhdG9yIGhhcyBhIERldmljZSB0aGV5IGFy ZSBlbnRpdGxlZCB0byB1c2UgaXQgKGkuZS4gRGV2aWNlcyBjYW4gYmUgc29sZC90cmFuc2ZlcnJl ZCB3aXRob3V0IGFwcHJvdmFsIGZyb20gdGhlIG1hbnVmYWN0dXJlcikuDQoNCg0KVGhlIHB1cnBv c2UsIGFzIEkgc2VlIGl0LCBvZiB0aGUgdm91Y2hlciwgaXMgc2ltcGx5IHRvIHByb3ZpZGUgemVy by10b3VjaCBuZXR3b3JrIHByb3Zpc2lvbmluZy4gIEkgd2FzIGFza2luZyBhIHNsaWdodGx5IGRp ZmZlcmVudCBxdWVzdGlvbjogZm9yIHB1cnBvc2VzIG9mIG5ldHdvcmsgY29ubmVjdGl2aXR5IHdp bGwgb3BlcmF0b3JzIHdhbnQgdG8ga25vdyB0aGF0IG9ubHkgZGV2aWNlcyB0aGV5IGF1dGhvcml6 ZWQgYXJlIGNvbm5lY3RpbmcgKGUuZy4sIDgwMi4xWCBhbmQgdGhlbiBsaWtlKT8gIFRoaXMgaXMg YSBuYXR1cmFsIGFzc3VtcHRpb24gaW4gdGhlIHdpcmVsZXNzIHdvcmxkLCBidXQgbGVzcyBzbyBp biB3aXJlZC4NCg0KRWxpb3QNCg0KDQoNClJlZ2FyZHMsDQoNClJhbmR5DQoNCg0KRnJvbTogRWxp b3QgTGVhciA8bGVhckBjaXNjby5jb208bWFpbHRvOmxlYXJAY2lzY28uY29tPj4NClNlbnQ6IEF1 Z3VzdCA3LCAyMDE5IDEyOjMzIEFNDQpUbzogUmFuZHkgQXJtc3Ryb25nIChPUEMpIDxyYW5keS5h cm1zdHJvbmdAb3BjZm91bmRhdGlvbi5vcmc8bWFpbHRvOnJhbmR5LmFybXN0cm9uZ0BvcGNmb3Vu ZGF0aW9uLm9yZz4+DQpDYzogVG9lcmxlc3MgRWNrZXJ0IDx0dGVAY3MuZmF1LmRlPG1haWx0bzp0 dGVAY3MuZmF1LmRlPj47IGlvdC1vbmJvYXJkaW5nQGlldGYub3JnPG1haWx0bzppb3Qtb25ib2Fy ZGluZ0BpZXRmLm9yZz47IGFuaW1hQGlldGYub3JnPG1haWx0bzphbmltYUBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbSW90LW9uYm9hcmRpbmddIE9QQyBhbmQgQlJTS0kNCg0KUmFuZHksDQoNClRo YW5rcy4gIFdlIGhhdmUgaXJyZWd1bGFyIGNhbGxzLCBidXQgSSB3aWxsIHBvbGwgZm9yIG9uZSBp biB0aGUgM3JkIHdlZWsgb2YgQXVndXN0IHRvIGRpc2N1c3MgeW91ciB1c2UgY2FzZS4NCg0KSW4g YW4gT1BDIFVBIGVudmlyb25tZW50LCBtaWdodCBvbmUgZXhwZWN0IHRoYXQgdGhlIGpvaW4gcmVn aXN0cmFyIGFuZCB0aGUgY2VydGlmaWNhdGUgbWFuYWdlciBiZSBjby1yZXNpZGVudD8gIFRoaXMg d291bGQgYmUgd2hlcmUgRVNUL1NDRVAgd291bGQgaGFwcGVuIChCUlNLSSBjYW4gYmUgdmlld2Vk IGFzIGFuIGV4dGVuc2lvbiB0byBFU1QgLSBSRkMgNzAzMCkuICBUaGVyZSBpcyBubyAicHVzaCBt b2RlIiBmb3IgRVNULiAgSG93ZXZlciwgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBzYW1l IGNhcGFiaWxpdHkgcm91Z2hseSBzcGVha2luZyByZXNpZGVzIGluIENJUC4NCg0KTXkgYmlnZ2Vy IHF1ZXN0aW9uIGlzIHdoZXRoZXIgeW91IHdhbnQgdG8gdXNlIGFsbCBvZiB0aGlzIGZvciBuZXR3 b3JrIGF1dGhlbnRpY2F0aW9uIHRvIGF2b2lkIHVuYXV0aG9yaXplZCBkZXZpY2VzIGpvaW5pbmcg dGhlIG5ldHdvcmsgaW4gdGhlIGZpcnN0IHBsYWNlLCBvciB3aGV0aGVyIHRoaXMgaXMgaW50ZW5k ZWQgc29sZWx5IGZvciBhcHBsaWNhdGlvbiBhdXRoZW50aWNhdGlvbi4NCg0KRWxpb3QNCg0KDQoN Cg0KT24gNyBBdWcgMjAxOSwgYXQgMDE6MTksIFJhbmR5IEFybXN0cm9uZyAoT1BDKSA8cmFuZHku YXJtc3Ryb25nQG9wY2ZvdW5kYXRpb24ub3JnPG1haWx0bzpyYW5keS5hcm1zdHJvbmdAb3BjZm91 bmRhdGlvbi5vcmc+PiB3cm90ZToNCg0KUHVzaCBzaG91bGQgYmUg4oCcQ2VydGlmaWNhdGUgTWFu YWdlciBpbml0aWF0ZWTigJ0NCg0KRnJvbTogSW90LW9uYm9hcmRpbmcgPGlvdC1vbmJvYXJkaW5n LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlvdC1vbmJvYXJkaW5nLWJvdW5jZXNAaWV0Zi5vcmc+ PiBPbiBCZWhhbGYgT2YgUmFuZHkgQXJtc3Ryb25nIChPUEMpDQpTZW50OiBBdWd1c3QgNiwgMjAx OSA0OjE3IFBNDQpUbzogVG9lcmxlc3MgRWNrZXJ0IDx0dGVAY3MuZmF1LmRlPG1haWx0bzp0dGVA Y3MuZmF1LmRlPj4NCkNjOiBpb3Qtb25ib2FyZGluZ0BpZXRmLm9yZzxtYWlsdG86aW90LW9uYm9h cmRpbmdAaWV0Zi5vcmc+OyBhbmltYUBpZXRmLm9yZzxtYWlsdG86YW5pbWFAaWV0Zi5vcmc+OyBF bGlvdCBMZWFyIDxsZWFyQGNpc2NvLmNvbTxtYWlsdG86bGVhckBjaXNjby5jb20+Pg0KU3ViamVj dDogUmU6IFtJb3Qtb25ib2FyZGluZ10gT1BDIGFuZCBCUlNLSQ0KDQpIaQ0KDQoxKSBTdXJlLCBu ZWVkIHRvIHVuZGVyc3RhbmQgaG93IFRDUCBVQSB3b3JrcyB3aWggdGhlIG1pbmltdW0gYW1vdW50 IG9mIG1lc3NhZ2UgYXV0aGVudGljYXRpb24gdG8gYWxsb3cgZm9yIEJSU0tJLiBNYWluIGNoYWxs ZW5nZSBtYXkgYmUgdGhlIG5lZWQgZm9yIHBsZWRnZXMgdG8gcmVjZWl2ZSBtZXNzYWdlcyBmcm9t IHJlZ2lzdHJhciB0aGF0IGFyZSBhdXRoZW50aWNhdGVkIGJ5IHRoZSByZWdpc3RhciwgYnV0IHdo ZXJlIHRoZSBwbGVkZ2UgaGFzIHRvIHdhaXQgdW50aWwgaXQgY2FuIGFjdHVhbGx5IHBlcmZvcm0g dGhlIGF1dGhlbnRpY2F0aW9uIGxhdGVyLiBEZXBlbmRpbmcgb24gaG93IHlvdSBidWlsdCBUQ1Ag VUEgbWVzc2FnZSBsYXllciBhdXRoZW50aWNhdGlvbiB0aGlzIG1heSBiZSBwaWVjZSBvZiBjYWtl IC8gZnJlZSBvciBub3QuDQoNCkl0IHdvdWxkIGJlIGVhc3kgdG8gZHJvcCBpbiBhIE9QQyBVQSBh d2FyZSByZWdpc3RyYXIgYW5kIGltcGxlbWVudCBhbGwgb2YgdGhlIEJSS1NJIGZsb3dzIGJhY2sg dG8gdGhlIE1BU0EuIFRoZSBvbmx5IG51aXNhbmNlIGZhY3RvciBpcyB0aGUgJ3ByaW9yLXNpZ25l ZC12b3VjaGVyLXJlcXVlc3QnLi4gSWYgTUFTQSdzIGFyZSB3aWxsaW5nIGFsbG93IHRoaXMgZmll bGQgdG8gYmUgb21pdHRlZCBhbmQgdG8gdHJ1c3QgdGhlIFJlZ2lzdHJhciB0aGVuIG5vdGhpbmcg bW9yZSBuZWVkcyB0byBkb25lLiBJZiBNQVNBJ3MgbmVlZCB0aGlzIGZpZWxkIHRoZW4gd2UgY291 bGQgZ2V0IGl0IGZyb20gdGhlIERldmljZSB2aWEgT1BDIFVBIGJ1dCBwcm9kdWNpbmcgdGhlIENN UyBtZXNzYWdlIGFkZHMgYW4gYWRkaXRpb25hbCBidXJkZW4gb24gbG93IGVuZCBkZXZpY2VzIChp LmUuIHRoZSBuZWVkIHRvIHB1bGwgaW4gbGlicmFyaWVzIHRoYXQgcHJvdmlkZSB0aGUgc2FtZSBm dW5jdGlvbmFsaXR5IGFzIE9QQyBVQSBidXQgZG8gaXQgaW4gZGlmZmVyZW50IGZvcm1hdCkuDQoN ClRoZSAyIG1vZGVzIG9mIG9wZXJhdGlvbiB3aXRoIGEgT1BDIFVBIGF3YXJlIHJlZ2lzdHJhciAo dGhlIENlcnRpZmljYXRlIE1hbmFnZXIgaXMgYW4gT1BDIFVBIGRlZmluZWQgZW50aXR5KS4NCg0K UHVsbCAoZGV2aWNlIGluaXRpYXRlZCkNCg0KPGltYWdlMDA1LnBuZz4NCg0KUHVzaCAoUmVnaXN0 cmFyIGluaXRpYXRlZCkNCg0KPGltYWdlMDA2LnBuZz4NCg0KUmVnYXJkcywNCg0KUmFuZHkNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFRvZXJsZXNzIEVja2VydCA8dHRlQGNz LmZhdS5kZTxtYWlsdG86dHRlQGNzLmZhdS5kZT4+DQpTZW50OiBBdWd1c3QgNiwgMjAxOSAzOjMx IFBNDQpUbzogUmFuZHkgQXJtc3Ryb25nIChPUEMpIDxyYW5keS5hcm1zdHJvbmdAb3BjZm91bmRh dGlvbi5vcmc8bWFpbHRvOnJhbmR5LmFybXN0cm9uZ0BvcGNmb3VuZGF0aW9uLm9yZz4+DQpDYzog RWxpb3QgTGVhciA8bGVhckBjaXNjby5jb208bWFpbHRvOmxlYXJAY2lzY28uY29tPj47IGlvdC1v bmJvYXJkaW5nQGlldGYub3JnPG1haWx0bzppb3Qtb25ib2FyZGluZ0BpZXRmLm9yZz47IGFuaW1h QGlldGYub3JnPG1haWx0bzphbmltYUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbSW90LW9uYm9h cmRpbmddIE9QQyBhbmQgQlJTS0kNCg0KT24gVHVlLCBBdWcgMDYsIDIwMTkgYXQgMDk6MzI6NDVQ TSArMDAwMCwgUmFuZHkgQXJtc3Ryb25nIChPUEMpIHdyb3RlOg0KPiBPUEMgaXMgbGF5ZXJlZCB0 byBzZXBhcmF0ZSB0aGUgYXBwbGljYXRpb24gZnJvbSB0aGUgY2hvaWNlIG9mIG5ldHdvcmsgcHJv dG9jb2wuIFRMUy9XZWJTb2NrZXRzIGlzIGFuIG9wdGlvbiBidXQgdGhlIHByaW1hcnkgcHJvdG9j b2wgdGhhdCB3aWxsIGJlIHVzZWQgYnkgbG93IGVuZCBkZXZpY2VzIGlzIFVBIFRDUCB3aGljaCBw cm92aWRlcyBjb21wbGV0ZSBtZXNzYWdlIGJhc2VkIHNlY3VyaXR5IGZyYW1ld29yay4gIFRoZXNl IGRldmljZXMgZG8gbm90IG5lZWQgVExTIHRvIGhhdmUgc2VjdXJpdHkgYW5kIHJlcXVpcmluZyBp dCB3b3VsZCByZXF1aXJlIGR1cGxpY2F0aW9uIG9mIGNvZGUuDQoNClN1cmUsIG5lZWQgdG8gdW5k ZXJzdGFuZCBob3cgVENQIFVBIHdvcmtzIHdpaCB0aGUgbWluaW11bSBhbW91bnQgb2YgbWVzc2Fn ZSBhdXRoZW50aWNhdGlvbiB0byBhbGxvdyBmb3IgQlJTS0kuIE1haW4gY2hhbGxlbmdlIG1heSBi ZSB0aGUgbmVlZCBmb3IgcGxlZGdlcyB0byByZWNlaXZlIG1lc3NhZ2VzIGZyb20gcmVnaXN0cmFy IHRoYXQgYXJlIGF1dGhlbnRpY2F0ZWQgYnkgdGhlIHJlZ2lzdGFyLCBidXQgd2hlcmUgdGhlIHBs ZWRnZSBoYXMgdG8gd2FpdCB1bnRpbCBpdCBjYW4gYWN0dWFsbHkgcGVyZm9ybSB0aGUgYXV0aGVu dGljYXRpb24gbGF0ZXIuIERlcGVuZGluZyBvbiBob3cgeW91IGJ1aWx0IFRDUCBVQSBtZXNzYWdl IGxheWVyIGF1dGhlbnRpY2F0aW9uIHRoaXMgbWF5IGJlIHBpZWNlIG9mIGNha2UgLyBmcmVlIG9y IG5vdC4NCg0KPiAyKSBBdCBzb21lIHBvaW50LCB0aGUgdGhpbmcgZGVjaWRlcyB3aGljaCBwYXJ0 IGdldHMgYW4gSVAgYWRkcmVzcyBvciBhdCBsZWFzdCBpcyByZXNwb25zaWJsZSBmb3IgdGhlIHBo eS4gIENhbiB0aGF0IHByb2Nlc3MgYmUgbGV2ZXJhZ2VkIHRvIGVzdGFibGlzaCBpZGVudGl0eT8N Cj4NCj4gTWFjaGluZXMgbWF5IGhhdmUgYSBzZXBhcmF0ZSBuZXR3b3JrIGZvciBpbnRlcm5hbCBE ZXZpY2VzIHdoaWNoIElQcyBhc3NpZ25lZCBieSB0aGUgbWFjaGluZT8/P3MgREhDUCBzZXJ2aWNl LiBTb21lIG9mIHRoZXNlIGRldmljZXMgbWF5IGludGVyYWN0IHdpdGggZXh0ZXJuYWwgZXF1aXBt ZW50IHZpYSBhIE5BVCByb3V0ZXIgd2hpY2ggYXNzaWducyBhIHVuaXF1ZSBwb3J0IHRvIGVhY2gg ZGV2aWNlLiBUaGlzIG1lYW5zIHRoZSBpbmRpdmlkdWFsIERldmljZXMgbmVlZCB0byBiZSBncmFu dGVkIGFjY2VzcyB0byB0aGUgb3BlcmF0b3JzIG5ldHdvcmsgd2hlbiB0aGUgbWFjaGluZSBpcyBp bnN0YWxsZWQgZXZlbiB0aG91Z2ggdGhlIG9wZXJhdG9yIGNhbm5vdCBwcm92aWRlIHRoZW0gd2l0 aCBJUHMuDQo+DQo+IEkgbmVlZCB0byBjb25zdWx0IHdpdGggb3VyIG1hY2hpbmUgZXhwZXJ0cyB0 byBiZXR0ZXIgZXhwbGFpbiB0aGlzIHVzZSBjYXNlLg0KDQpQcmltYXJ5IHF1ZXN0aW9ucyBzZWVt IHRvIGJlIHdoZXRoZXIgdGhpcyBpcyBqdXN0IGFib3V0IGF1dGhlbnRpY2F0aW9uIGF0IHRoZSBU Q1AgVUEgbGF5ZXIgb3IgZnVydGhlciBiZWxvdyBhdCBzb21lIGltcGxpZWQgTkFDIG1lY2hhbmlz bS4NCg0KPiAzKSBPbmUgcG9zc2libGUgdmlldyBoZXJlIGlzIHRoYXQgdGhlIE1BU0EgbWF5IGJl IG9mZmxpbmUsIGFuZCBtYXkgaGF2ZSBwcm92aWRlZCBhIHZvdWNoZXIgdmlhIG9mZmxpbmUgbWVh bnMgdG8gdGhlIGpvaW4gcmVnaXN0cmFyLiAgVGhpcyBvZiBjb3Vyc2Ugd291bGQgYmUgbm9uY2Vs ZXNzIHdpdGggYSBsZW5ndGh5IGV4cGlyeSB0aW1lLiAgSW4gYWRkaXRpb24sIEkgcG9zaXRlZCBk dXJpbmcgQlJTS0k/Pz9zIHJldmlldyB0aGF0IHBlcmhhcHMgdGhlIGRldmljZSBzaG91bGQgYmUg YWJsZSB0byBnZW5lcmF0ZSBpdHMgb3duIGNlcnRpZmljYXRlIHZpYSBhIGhpZ2hlciBsZXZlbCBp bnRlcmZhY2UuDQo+DQo+IE9QQyBhbHJlYWR5IGhhcyBBUElzIG5lZWRlZCB0byBtYW5hZ2UgQ2Vy dGlmaWNhdGVzIG9uIGEgRGV2aWNlLiBUaGUgbGluayB0byBzb21ldGhpbmcgbGlrZSB0aGUgTUFT QSBpcyB3aGF0IHdlIGFyZSBtaXNzaW5nLiBOb25jZWxlc3Mgdm91Y2hlcnMgdGhhdCBkbyBub3Qg ZXhwaXJlIHNob3VsZCBhbGxvdyBsb2NhbCByZWdpc3RyYXIgdG8gZW11bGF0ZSBhIE1BU0Egd2hl biB0aGUgTUFTQSBpcyBubyBsb25nZXIgYXZhaWxhYmxlLiBJIHdhbnRlZCB0byBtYWtlIHN1cmUg dGhhdCB0aGlzIG1vZGUgb2Ygb3BlcmF0aW9uIGlzIGFsbG93ZWQgQlJTS0kuDQoNClllcyBpdCBp cywgaXQgbWF5IGp1c3Qgbm90IGJlIGZ1bGx5IHNwZWNpZmllZCBpbiB0aGUgY3VycmVudCB0YXJn ZXRlZCBCUlNLSSBSRkMgdGhhdCB3ZSBmZWVsIGV2ZXJ5Ym9keSB3aG8gd2FudHMgdG8gaW1wbGVt ZW50IGl0IGhhcyBldmVyeXRoaW5nIHRvIGRvIHNvLCBidXQgdGhhdHMgd291bGQganVzdCBiZSBz dWJqZXQgdG8gZnV0dXJlIHNtYWxsIFJGQyB0byBjbG9zZSBhbnkgcG9zc2libGUgZ2Fwcy4NCg0K PiA0KSBDYW4geW91IHNheSBtb3JlIGFib3V0IHdoYXQgbWVjaGFuaXNtcyBPUEMgaXMgaW50ZXJl c3RlZCBpbiBwdXJzdWluZz8NCj4NCj4gV2l0aCBPUEMgd2UgYXNzdW1lIHRoYXQgbmV0d29yayBz ZWxlY3Rpb24gYW5kIElQIGFzc2lnbm1lbnQgYXJlIG91dCBvZiBzY29wZS4gV2lyZWQgZGV2aWNl cyBhcmUgdGhlIHByaW1hcnkgbWFya2V0IGF0IHRoaXMgdGltZSBidXQgNUcgY291bGQgY2hhbmdl IHRoYXQuDQoNCkJSU0tJIGFsc28gZG9lcyBub3QgY2FyZSBhYm91dCBBZGRyZXNzaW5nLiBPbmx5 IEFDUCBkb2VzLCBzbyB5b3UgY2FuIGlnbm9yZSB0aGF0IHBhcnQgaWYgeW91J3JlIG5vdCBpbnRl cmVzdGVkIGluLiBXZSBoYXZlIHRyaWVkIHRvIHNlcGFyYXRlIG91dCBBQ1Agc3BlY2lmaWMgYXNw ZWN0cyBpbiB0aGUgQlJTS0kgZG9jdW1lbnQgYXMgZ29vZCBhcyBwb3NzaWJsZSB3aXRoIHRoZSBz b21ld2hhdCBjb252b2x1dGVkIHByb2Nlc3Mgd2UgaGFkIGluIHRoZSBJRVRGIGhvdyB0byBkcml2 ZSB0aG9zZSBkb2N1bWVudHMuDQoNCkNoZWVycw0KICAgIFRvZXJsZXNzDQoNCj4gUmVnYXJkcywN Cj4NCj4gUmFuZHkNCj4NCj4gRnJvbTogRWxpb3QgTGVhciA8bGVhckBjaXNjby4uY29tPG1haWx0 bzpsZWFyQGNpc2NvLmNvbT4+DQo+IFNlbnQ6IEF1Z3VzdCA2LCAyMDE5IDE6NDcgUE0NCj4gVG86 IFJhbmR5IEFybXN0cm9uZyAoT1BDKSA8cmFuZHkuYXJtc3Ryb25nQG9wY2ZvdW5kYXRpb24ub3Jn PG1haWx0bzpyYW5keS5hcm1zdHJvbmdAb3BjZm91bmRhdGlvbi5vcmc+Pg0KPiBDYzogaW90LW9u Ym9hcmRpbmdAaWV0Zi5vcmc8bWFpbHRvOmlvdC1vbmJvYXJkaW5nQGlldGYub3JnPg0KPiBTdWJq ZWN0OiBSZTogW0lvdC1vbmJvYXJkaW5nXSBPUEMgYW5kIEJSU0tJDQo+DQo+IEhpIFJhbmR5LA0K Pg0KPiBUaGFua3MgZm9yIHRoaXMuICBJdD8/P3MgYSBncmVhdCBzdGFydGluZyBwb2ludC4gIEkg d291bGQgcHJvcG9zZSB0aGF0IHdlIGRvIGEgY2FsbCBzbyB3ZSBjYW4gZ2V0IHNvbWUgaGlnaCBi YW5kd2lkdGggZGlzY3Vzc2lvbiBnb2luZy4gIFBsZWFzZSBub3cgc2VlIGJlbG93Lg0KPg0KPg0K PiBPbiA2IEF1ZyAyMDE5LCBhdCAyMDo1OCwgUmFuZHkgQXJtc3Ryb25nIChPUEMpIDxyYW5keS5h cm1zdHJvbmdAb3BjZm91bmRhdGlvbi5vcmc8bWFpbHRvOnJhbmR5LmFybXN0cm9uZ0BvcGNmb3Vu ZGF0aW9uLm9yZzxtYWlsdG86cmFuZHkuYXJtc3Ryb25nQG9wY2ZvdW5kYXRpb24ub3JnJTNjbWFp bHRvOnJhbmR5LmFybXN0cm9uZ0BvcGNmb3VuZGF0aW9uLm9yZz4+PiB3cm90ZToNCj4NCj4gSSB3 aWxsIHN0YXJ0IHdpdGggdGhlIG1haW4gdHJvdWJsZSBzcG90cy4gU29tZSBvZiB0aGVzZSBtYXkg YmUgYWxyZWFkeSBjb3ZlcmVkIGJ5IEJSS1NJIGJ1dCBJIG1pc3NlZCB0aGUgaW1wbGljYXRpb25z IG9mIHNvbWUgb2YgdGhlIHRleHQ6DQo+DQo+IDEpIExvdyBlbmQgZGV2aWNlcyB0aGF0IG9ubHkg c3VwcG9ydCBPUEM7IHRoaXMgbWVhbnMgbm8gVExTIGNsaWVudA0KPiBjYXBhYmlsaXRpZXMgYW5k IG5vIGFiaWxpdHkgdG8gaW5pdGlhdGUgbmV0d29yayBjb21tdW5pY2F0aW9uIChpLmUuDQo+IHNl cnZlciBvbmx5IG1vZGUpOw0KPg0KPg0KPiBIb3cgZG9lcyBPUEMgaGFuZGxlIHN1Y2ggZGV2aWNl cz8gIEkgdGhpbmsgdGhpcyBpcyBhbHNvIGNvbWluZyB1cCBlbHNld2hlcmUuICBPbmUgcXVlc3Rp b24gaXMgd2hldGhlciBUTFMgaXMgcmVxdWlyZWQuICBXaXRob3V0IFRMUyBvbmUgZG9lcyBsb3Nl IGNvbmZpZGVudGlhbGl0eSwgYnV0IHNvIGxvbmcgYXMgdGhlIGNsaWVudCBjYW4gc2lnbiB0aGUg cmVxdWVzdCwgbWF5YmUgdGhhdD8/P3MgYWxsIHlvdSB1c2UuDQo+DQo+DQo+DQo+IDIpIE1hY2hp bmUgYnVpbGRlcnMgdGhhdCBjb21iaW5lIGRldmljZXMgaW50byBhIG1hY2hpbmUgdGhhdCBpcyBz b2xkIGFzIGEgdW5pdC4gVGhlc2UgZGV2aWNlIHN0aWxsIGhhdmUgYSB1bmlxdWUgbmV0d29yayBp ZGVudGl0eSBidXQgdGhlIGVmZmVjdGl2ZSBtYW51ZmFjdHVyZXIgaGFzIGNoYW5nZWQ7IEhvdyB0 byBkZWFsIHdpdGggdGhlIERldmljZUlEPw0KPg0KPg0KPiBBdCBzb21lIHBvaW50LCB0aGUgdGhp bmcgZGVjaWRlcyB3aGljaCBwYXJ0IGdldHMgYW4gSVAgYWRkcmVzcyBvciBhdCBsZWFzdCBpcyBy ZXNwb25zaWJsZSBmb3IgdGhlIHBoeS4gIENhbiB0aGF0IHByb2Nlc3MgYmUgbGV2ZXJhZ2VkIHRv IGVzdGFibGlzaCBpZGVudGl0eT8NCj4NCj4NCj4NCj4NCj4gMykgRGV2aWNlcyBtYXkgYmUgcmVz ZXQgdG8gZmFjdG9yeSBkZWZhdWx0cyBhbmQgc29sZC90cmFuc2ZlcnJlZCB0byBhbm90aGVyIG9y Z2FuaXphdGlvbi4gVGhpcyBuZWVkcyB0byBiZSBwb3NzaWJsZSBldmVuIGlmIHRoZSBNQVNBIGlz IG5vIGxvbmdlciBhdmFpbGFibGUgKGkuZS4gdGhlIG9yaWdpbmFsIG1hbnVmYWN0dXJlciBoYXMg Z29uZSBvdXQgb2YgYnVzaW5lc3MpLg0KPg0KPiBPbmUgcG9zc2libGUgdmlldyBoZXJlIGlzIHRo YXQgdGhlIE1BU0EgbWF5IGJlIG9mZmxpbmUsIGFuZCBtYXkgaGF2ZSBwcm92aWRlZCBhIHZvdWNo ZXIgdmlhIG9mZmxpbmUgbWVhbnMgdG8gdGhlIGpvaW4gcmVnaXN0cmFyLiAgVGhpcyBvZiBjb3Vy c2Ugd291bGQgYmUgbm9uY2VsZXNzIHdpdGggYSBsZW5ndGh5IGV4cGlyeSB0aW1lLiAgSW4gYWRk aXRpb24sIEkgcG9zaXRlZCBkdXJpbmcgQlJTS0k/Pz9zIHJldmlldyB0aGF0IHBlcmhhcHMgdGhl IGRldmljZSBzaG91bGQgYmUgYWJsZSB0byBnZW5lcmF0ZSBpdHMgb3duIGNlcnRpZmljYXRlIHZp YSBhIGhpZ2hlciBsZXZlbCBpbnRlcmZhY2UuDQo+DQo+DQo+DQo+IDQpIE9mZmxpbmUgb3BlcmF0 aW9uIGlzIHRoZSBub3JtIHdpdGggcHJlLWlzc3VlZCB2b3VjaGVycyBkZWxpdmVyZWQgb3V0IG9m IGJhbmQuIFRoZSBwcmUtaXNzdWVkIHZvdWNoZXJzIHdpbGwgbmVlZCB0byBoYXZlIHJlYXNvbmFi bHkgbG9uZyBsaWZldGltZSAoaS5lLiB5ZWFycyBub3QgaG91cnMpLg0KPg0KPiBUaGUgbGlmZWN5 Y2xlIG9mIGEgZGV2aWNlIGlzIHNob3duIGluIHRoZSBmb2xsb3dpbmcgZGlhZ3JhbS4gVGhlDQo+ IGV4cGVjdGF0aW9uIGlzIHdlIHdvdWxkIG5lZWQgdG8gYWRkIGxpbmtzIHRvIHRoZSBNQVNBIGF0 IGVhY2ggc3RlcCBpbg0KPiB0aGUgbGlmZXRpbWUNCj4NCj4NCj4gVGhhbmsgeW91IGZvciB0aGF0 LiAgRm9yIHdpcmVkIGl0IHNlZW1zIHRvIG1lIHRoYXQgYSBwZXJtaXNzaXZlIE1BU0EgbW9kZWwg KGxvZ2dpbmcgb25seSkgY291bGQgcHJvdmlkZSB5b3UgYSB3YXkgZm9yd2FyZC4gIEZvciB3aXJl bGVzcywgdGhpcyBpcyBub3QgYW4gb3B0aW9uIGJlY2F1c2UgcHJvcGVyIG5ldHdvcmsgc2VsZWN0 aW9uIG5lZWRzIHRvIG9jY3VyLiAgQW5vdGhlciBxdWVzdGlvbiBpcyB3aGV0aGVyIHdlIG5lZWQg YW5vdGhlciBtZWNoYW5pc20gaXMgbmVjZXNzYXJ5IHRvIHZhbGlkYXRlIHRoZSB2b3VjaGVyIChh a2EsIGEgUFNLIHcvIHByb29mIG9mIGtub3dsZWRnZSwgb3IgRFBQLCBldGMpLg0KPg0KPiBDYW4g eW91IHNheSBtb3JlIGFib3V0IHdoYXQgbWVjaGFuaXNtcyBPUEMgaXMgaW50ZXJlc3RlZCBpbiBw dXJzdWluZz8NCj4NCj4gRWxpb3QNCj4NCg0KPiAtLQ0KPiBJb3Qtb25ib2FyZGluZyBtYWlsaW5n IGxpc3QNCj4gSW90LW9uYm9hcmRpbmdAaWV0Zi5vcmc8bWFpbHRvOklvdC1vbmJvYXJkaW5nQGll dGYub3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lvdC1vbmJv YXJkaW5nDQoNCg0KLS0NCi0tLQ0KdHRlQGNzLmZhdS5kZTxtYWlsdG86dHRlQGNzLmZhdS5kZT4N Cg0K --_000_BYAPR08MB4903DC283780FC3519F4432BFAD40BYAPR08MB4903namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJZdSBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNCAwIDAgMCAw IDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFl1IEdv dGhpYyI7DQoJcGFub3NlLTE6MiAxMSA0IDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1DQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SEkgRWxpb3QsPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlllcywgdGhlIE9wZXJhdG9yIG5lZWRzIHRvIGVuc3VyZSB0aGF0IG9u bHkgRGV2aWNlcyB0aGV5IGF1dGhvcml6ZSBjYW4gY29ubmVjdCBhbmQgdGhlIHplcm8gdG91Y2gg cHJvdmlzaW9uaW5nIGlzIGEgZmVhdHVyZSB3ZSBkZXNpcmUuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJhbmR5PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gRWxpb3QgTGVhciAm bHQ7bGVhckBjaXNjby5jb20mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gQXVndXN0IDcsIDIwMTkg MTo1MCBBTTxicj4NCjxiPlRvOjwvYj4gUmFuZHkgQXJtc3Ryb25nIChPUEMpICZsdDtyYW5keS5h cm1zdHJvbmdAb3BjZm91bmRhdGlvbi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBUb2VybGVzcyBF Y2tlcnQgJmx0O3R0ZUBjcy5mYXUuZGUmZ3Q7OyBpb3Qtb25ib2FyZGluZ0BpZXRmLm9yZzsgYW5p bWFAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtJb3Qtb25ib2FyZGluZ10gT1BD IGFuZCBCUlNLSTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpIFJhbmR5LDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzIGFnYWluIGZvciB5b3VyIGNvbW1lbnRzLiAmbmJzcDtQbGVhc2Ugc2VlIGJlbG93Ljxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNyBBdWcgMjAx OSwgYXQgMTA6MzIsIFJhbmR5IEFybXN0cm9uZyAoT1BDKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJh bmR5LmFybXN0cm9uZ0BvcGNmb3VuZGF0aW9uLm9yZyI+cmFuZHkuYXJtc3Ryb25nQG9wY2ZvdW5k YXRpb24ub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSBFbGlvdCw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkgSW4gYW4gT1BDIFVBIGVudmlyb25tZW50LCBtaWdodCBv bmUgZXhwZWN0IHRoYXQgdGhlIGpvaW4gcmVnaXN0cmFyIGFuZCB0aGUgY2VydGlmaWNhdGUgbWFu YWdlciBiZSBjby1yZXNpZGVudD8gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWluZGVudDozNi4wcHQiPlllcyB0 aGF0IGlzIHRoZSBleHBlY3RhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgTXkgYmlnZ2VyIHF1ZXN0aW9uIGlzIHdoZXRoZXIgeW91 IHdhbnQgdG8gdXNlIGFsbCBvZiB0aGlzIGZvciBuZXR3b3JrIGF1dGhlbnRpY2F0aW9uIHRvIGF2 b2lkIHVuYXV0aG9yaXplZCBkZXZpY2VzIGpvaW5pbmcgdGhlIG5ldHdvcmsgaW4gdGhlIGZpcnN0 IHBsYWNlLCBvciB3aGV0aGVyIHRoaXMgaXMgaW50ZW5kZWQgc29sZWx5IGZvciBhcHBsaWNhdGlv biBhdXRoZW50aWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q291bnRlcmZlaXQgZGV2 aWNlcyBhcmUgaHVnZSBpc3N1ZSBpbiBpbmR1c3RyaWFsIGF1dG9tYXRpb24uIFdlIG5lZWQgdGhp cyBpbmZyYXN0cnVjdHVyZSBzbyB0aGUgT3BlcmF0b3JzIGNhbiBhc3N1cmUgdGhlbXNlbHZlcyB0 aGF0IHRoZSBEZXZpY2VzIHRoZXkgcGx1ZyBpbnRvIHRoZWlyIG5ldHdvcmsgYXJlIGdlbnVpbmUu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9UT0gs IE9wZXJhdG9ycyBkb27igJl0IG5lZWQgdG8gcHJvdmUgdGhlaXIgcmlnaHQgdG8gdXNlIGEgRGV2 aWNlLiBJZiBhbiBPcGVyYXRvciBoYXMgYSBEZXZpY2UgdGhleSBhcmUgZW50aXRsZWQgdG8gdXNl IGl0IChpLmUuIERldmljZXMgY2FuIGJlIHNvbGQvdHJhbnNmZXJyZWQgd2l0aG91dCBhcHByb3Zh bCBmcm9tIHRoZSBtYW51ZmFjdHVyZXIpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHB1cnBv c2UsIGFzIEkgc2VlIGl0LCBvZiB0aGUgdm91Y2hlciwgaXMgc2ltcGx5IHRvIHByb3ZpZGUgemVy by10b3VjaCBuZXR3b3JrIHByb3Zpc2lvbmluZy4gJm5ic3A7SSB3YXMgYXNraW5nIGEgc2xpZ2h0 bHkgZGlmZmVyZW50IHF1ZXN0aW9uOiBmb3IgcHVycG9zZXMgb2YgbmV0d29yayBjb25uZWN0aXZp dHkgd2lsbCBvcGVyYXRvcnMgd2FudCB0byBrbm93IHRoYXQgb25seSBkZXZpY2VzDQo8Yj50aGV5 PC9iPiZuYnNwO2F1dGhvcml6ZWQgYXJlIGNvbm5lY3RpbmcgKGUuZy4sIDgwMi4xWCBhbmQgdGhl biBsaWtlKT8gJm5ic3A7VGhpcyBpcyBhIG5hdHVyYWwgYXNzdW1wdGlvbiBpbiB0aGUgd2lyZWxl c3Mgd29ybGQsIGJ1dCBsZXNzIHNvIGluIHdpcmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FbGlvdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJhbmR5PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPkVsaW90IExlYXIgJmx0Ozxh IGhyZWY9Im1haWx0bzpsZWFyQGNpc2NvLmNvbSI+bGVhckBjaXNjby5jb208L2E+Jmd0OzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50 OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+QXVn dXN0IDcsIDIwMTkgMTI6MzMgQU08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJhbmR5IEFybXN0cm9uZyAoT1BDKSAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJhbmR5LmFybXN0cm9uZ0BvcGNmb3VuZGF0aW9uLm9yZyI+cmFuZHkuYXJt c3Ryb25nQG9wY2ZvdW5kYXRpb24ub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRvZXJsZXNzIEVja2VydCAm bHQ7PGEgaHJlZj0ibWFpbHRvOnR0ZUBjcy5mYXUuZGUiPnR0ZUBjcy5mYXUuZGU8L2E+Jmd0OzsN CjxhIGhyZWY9Im1haWx0bzppb3Qtb25ib2FyZGluZ0BpZXRmLm9yZyI+aW90LW9uYm9hcmRpbmdA aWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86YW5pbWFAaWV0Zi5vcmciPg0KYW5pbWFAaWV0 Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbSW90LW9uYm9hcmRpbmddIE9QQyBhbmQgQlJTS0k8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5SYW5keSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcy4gJm5i c3A7V2UgaGF2ZSBpcnJlZ3VsYXIgY2FsbHMsIGJ1dCBJIHdpbGwgcG9sbCBmb3Igb25lIGluIHRo ZSAzcmQgd2VlayBvZiBBdWd1c3QgdG8gZGlzY3VzcyB5b3VyIHVzZSBjYXNlLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JbiBhbiBPUEMgVUEgZW52aXJvbm1lbnQsIG1pZ2h0IG9uZSBleHBl Y3QgdGhhdCB0aGUgam9pbiByZWdpc3RyYXIgYW5kIHRoZSBjZXJ0aWZpY2F0ZSBtYW5hZ2VyIGJl IGNvLXJlc2lkZW50PyAmbmJzcDtUaGlzIHdvdWxkIGJlIHdoZXJlIEVTVC9TQ0VQIHdvdWxkIGhh cHBlbiAoQlJTS0kgY2FuIGJlIHZpZXdlZCBhcyBhbiBleHRlbnNpb24gdG8gRVNUIC0gUkZDIDcw MzApLiAmbmJzcDtUaGVyZSBpcyBubyAmcXVvdDtwdXNoIG1vZGUmcXVvdDsNCiBmb3IgRVNULiAm bmJzcDtIb3dldmVyLCBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIHNhbWUgY2FwYWJpbGl0 eSByb3VnaGx5IHNwZWFraW5nIHJlc2lkZXMgaW4gQ0lQLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5NeSBiaWdnZXIgcXVlc3Rpb24gaXMgd2hldGhlciB5b3Ugd2FudCB0byB1c2UgYWxsIG9m IHRoaXMgZm9yIG5ldHdvcmsgYXV0aGVudGljYXRpb24gdG8gYXZvaWQgdW5hdXRob3JpemVkIGRl dmljZXMgam9pbmluZyB0aGUgbmV0d29yayBpbiB0aGUgZmlyc3QgcGxhY2UsIG9yIHdoZXRoZXIg dGhpcyBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIGFwcGxpY2F0aW9uIGF1dGhlbnRpY2F0aW9uLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FbGlvdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA3IEF1ZyAyMDE5LCBhdCAwMToxOSwg UmFuZHkgQXJtc3Ryb25nIChPUEMpICZsdDs8YSBocmVmPSJtYWlsdG86cmFuZHkuYXJtc3Ryb25n QG9wY2ZvdW5kYXRpb24ub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5yYW5keS5hcm1z dHJvbmdAb3BjZm91bmRhdGlvbi5vcmc8L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5QdXNoIHNob3VsZCBiZSDigJxDZXJ0aWZpY2F0ZSBNYW5hZ2VyIGluaXRpYXRlZOKA nTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+SW90LW9uYm9hcmRpbmcgJmx0OzxhIGhyZWY9Im1haWx0 bzppb3Qtb25ib2FyZGluZy1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6Izk1 NEY3MiI+aW90LW9uYm9hcmRpbmctYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5Pbg0KIEJlaGFs ZiBPZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+ UmFuZHkgQXJtc3Ryb25nIChPUEMpPGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkF1Z3VzdCA2LCAyMDE5IDQ6MTcgUE08YnI+ DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPlRvZXJsZXNzIEVja2VydCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR0ZUBjcy5mYXUuZGUiPjxz cGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj50dGVAY3MuZmF1LmRlPC9zcGFuPjwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJtYWlsdG86aW90LW9uYm9hcmRpbmdAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSJjb2xvcjojOTU0RjcyIj5pb3Qtb25ib2FyZGluZ0BpZXRmLm9yZzwvc3Bhbj48L2E+OzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWls dG86YW5pbWFAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5hbmltYUBpZXRm Lm9yZzwvc3Bhbj48L2E+Ow0KIEVsaW90IExlYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsZWFyQGNp c2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmxlYXJAY2lzY28uY29tPC9zcGFu PjwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbSW90LW9uYm9hcmRpbmddIE9QQyBhbmQgQlJTS0k8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaTxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+MSkgU3VyZSwgbmVlZCB0byB1bmRlcnN0YW5kIGhvdyBUQ1AgVUEgd29y a3Mgd2loIHRoZSBtaW5pbXVtIGFtb3VudCBvZiBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIHRvIGFs bG93IGZvciBCUlNLSS4gTWFpbiBjaGFsbGVuZ2UgbWF5IGJlIHRoZSBuZWVkIGZvciBwbGVkZ2Vz IHRvIHJlY2VpdmUgbWVzc2FnZXMgZnJvbSByZWdpc3RyYXIgdGhhdCBhcmUgYXV0aGVudGljYXRl ZCBieSB0aGUgcmVnaXN0YXIsIGJ1dA0KIHdoZXJlIHRoZSBwbGVkZ2UgaGFzIHRvIHdhaXQgdW50 aWwgaXQgY2FuIGFjdHVhbGx5IHBlcmZvcm0gdGhlIGF1dGhlbnRpY2F0aW9uIGxhdGVyLiBEZXBl bmRpbmcgb24gaG93IHlvdSBidWlsdCBUQ1AgVUEgbWVzc2FnZSBsYXllciBhdXRoZW50aWNhdGlv biB0aGlzIG1heSBiZSBwaWVjZSBvZiBjYWtlIC8gZnJlZSBvciBub3QuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIGJlIGVhc3kg dG8gZHJvcCBpbiBhIE9QQyBVQSBhd2FyZSByZWdpc3RyYXIgYW5kIGltcGxlbWVudCBhbGwgb2Yg dGhlIEJSS1NJIGZsb3dzIGJhY2sgdG8gdGhlIE1BU0EuIFRoZSBvbmx5IG51aXNhbmNlIGZhY3Rv ciBpcyB0aGUgJ3ByaW9yLXNpZ25lZC12b3VjaGVyLXJlcXVlc3QnLi4gSWYgTUFTQSdzIGFyZSB3 aWxsaW5nIGFsbG93IHRoaXMgZmllbGQgdG8gYmUgb21pdHRlZCBhbmQgdG8gdHJ1c3QNCiB0aGUg UmVnaXN0cmFyIHRoZW4gbm90aGluZyBtb3JlIG5lZWRzIHRvIGRvbmUuIElmIE1BU0EncyBuZWVk IHRoaXMgZmllbGQgdGhlbiB3ZSBjb3VsZCBnZXQgaXQgZnJvbSB0aGUgRGV2aWNlIHZpYSBPUEMg VUEgYnV0IHByb2R1Y2luZyB0aGUgQ01TIG1lc3NhZ2UgYWRkcyBhbiBhZGRpdGlvbmFsIGJ1cmRl biBvbiBsb3cgZW5kIGRldmljZXMgKGkuZS4gdGhlIG5lZWQgdG8gcHVsbCBpbiBsaWJyYXJpZXMg dGhhdCBwcm92aWRlIHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkNCiBhcyBPUEMgVUEgYnV0IGRvIGl0 IGluIGRpZmZlcmVudCBmb3JtYXQpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgMiBt b2RlcyBvZiBvcGVyYXRpb24gd2l0aCBhIE9QQyBVQSBhd2FyZSByZWdpc3RyYXIgKHRoZSBDZXJ0 aWZpY2F0ZSBNYW5hZ2VyIGlzIGFuIE9QQyBVQSBkZWZpbmVkIGVudGl0eSkuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlB1bGwgKGRldmljZSBpbml0aWF0ZWQpPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZsdDtpbWFnZTAwNS5wbmcmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlB1c2ggKFJlZ2lzdHJhciBpbml0aWF0ZWQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZs dDtpbWFnZTAwNi5wbmcmZ3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJhbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IFRvZXJsZXNzIEVja2VydCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR0ZUBjcy5mYXUuZGUiPjxzcGFu IHN0eWxlPSJjb2xvcjojOTU0RjcyIj50dGVAY3MuZmF1LmRlPC9zcGFuPjwvYT4mZ3Q7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NClNlbnQ6IEF1 Z3VzdCA2LCAyMDE5IDM6MzEgUE08YnI+DQpUbzogUmFuZHkgQXJtc3Ryb25nIChPUEMpICZsdDs8 YSBocmVmPSJtYWlsdG86cmFuZHkuYXJtc3Ryb25nQG9wY2ZvdW5kYXRpb24ub3JnIj48c3BhbiBz dHlsZT0iY29sb3I6Izk1NEY3MiI+cmFuZHkuYXJtc3Ryb25nQG9wY2ZvdW5kYXRpb24ub3JnPC9z cGFuPjwvYT4mZ3Q7PGJyPg0KQ2M6IEVsaW90IExlYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsZWFy QGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPmxlYXJAY2lzY28uY29tPC9z cGFuPjwvYT4mZ3Q7OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YSBocmVmPSJtYWlsdG86aW90LW9uYm9hcmRpbmdAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSJjb2xvcjojOTU0RjcyIj5pb3Qtb25ib2FyZGluZ0BpZXRmLm9yZzwvc3Bhbj48L2E+OzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWls dG86YW5pbWFAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5hbmltYUBpZXRm Lm9yZzwvc3Bhbj48L2E+PGJyPg0KU3ViamVjdDogUmU6IFtJb3Qtb25ib2FyZGluZ10gT1BDIGFu ZCBCUlNLSTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBBdWcgMDYs IDIwMTkgYXQgMDk6MzI6NDVQTSAmIzQzOzAwMDAsIFJhbmR5IEFybXN0cm9uZyAoT1BDKSB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZndDsgT1BDIGlzIGxheWVyZWQgdG8gc2VwYXJhdGUgdGhlIGFwcGxpY2F0 aW9uIGZyb20gdGhlIGNob2ljZSBvZiBuZXR3b3JrIHByb3RvY29sLiBUTFMvV2ViU29ja2V0cyBp cyBhbiBvcHRpb24gYnV0IHRoZSBwcmltYXJ5IHByb3RvY29sIHRoYXQgd2lsbCBiZSB1c2VkIGJ5 IGxvdyBlbmQgZGV2aWNlcyBpcyBVQSBUQ1Agd2hpY2ggcHJvdmlkZXMgY29tcGxldGUgbWVzc2Fn ZSBiYXNlZCBzZWN1cml0eSBmcmFtZXdvcmsuJm5ic3A7DQogVGhlc2UgZGV2aWNlcyBkbyBub3Qg bmVlZCBUTFMgdG8gaGF2ZSBzZWN1cml0eSBhbmQgcmVxdWlyaW5nIGl0IHdvdWxkIHJlcXVpcmUg ZHVwbGljYXRpb24gb2YgY29kZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3VyZSwgbmVl ZCB0byB1bmRlcnN0YW5kIGhvdyBUQ1AgVUEgd29ya3Mgd2loIHRoZSBtaW5pbXVtIGFtb3VudCBv ZiBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIHRvIGFsbG93IGZvciBCUlNLSS4gTWFpbiBjaGFsbGVu Z2UgbWF5IGJlIHRoZSBuZWVkIGZvciBwbGVkZ2VzIHRvIHJlY2VpdmUgbWVzc2FnZXMgZnJvbSBy ZWdpc3RyYXIgdGhhdCBhcmUgYXV0aGVudGljYXRlZCBieSB0aGUgcmVnaXN0YXIsIGJ1dCB3aGVy ZQ0KIHRoZSBwbGVkZ2UgaGFzIHRvIHdhaXQgdW50aWwgaXQgY2FuIGFjdHVhbGx5IHBlcmZvcm0g dGhlIGF1dGhlbnRpY2F0aW9uIGxhdGVyLiBEZXBlbmRpbmcgb24gaG93IHlvdSBidWlsdCBUQ1Ag VUEgbWVzc2FnZSBsYXllciBhdXRoZW50aWNhdGlvbiB0aGlzIG1heSBiZSBwaWVjZSBvZiBjYWtl IC8gZnJlZSBvciBub3QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgMikgQXQgc29t ZSBwb2ludCwgdGhlIHRoaW5nIGRlY2lkZXMgd2hpY2ggcGFydCBnZXRzIGFuIElQIGFkZHJlc3Mg b3IgYXQgbGVhc3QgaXMgcmVzcG9uc2libGUgZm9yIHRoZSBwaHkuJm5ic3A7IENhbiB0aGF0IHBy b2Nlc3MgYmUgbGV2ZXJhZ2VkIHRvIGVzdGFibGlzaCBpZGVudGl0eT88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mZ3Q7IE1hY2hpbmVzIG1heSBoYXZlIGEgc2VwYXJhdGUgbmV0d29yayBmb3IgaW50ZXJuYWwg RGV2aWNlcyB3aGljaCBJUHMgYXNzaWduZWQgYnkgdGhlIG1hY2hpbmU/Pz9zIERIQ1Agc2Vydmlj ZS4gU29tZSBvZiB0aGVzZSBkZXZpY2VzIG1heSBpbnRlcmFjdCB3aXRoIGV4dGVybmFsIGVxdWlw bWVudCB2aWEgYSBOQVQgcm91dGVyIHdoaWNoIGFzc2lnbnMgYSB1bmlxdWUgcG9ydCB0byBlYWNo IGRldmljZS4gVGhpcw0KIG1lYW5zIHRoZSBpbmRpdmlkdWFsIERldmljZXMgbmVlZCB0byBiZSBn cmFudGVkIGFjY2VzcyB0byB0aGUgb3BlcmF0b3JzIG5ldHdvcmsgd2hlbiB0aGUgbWFjaGluZSBp cyBpbnN0YWxsZWQgZXZlbiB0aG91Z2ggdGhlIG9wZXJhdG9yIGNhbm5vdCBwcm92aWRlIHRoZW0g d2l0aCBJUHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJIG5lZWQgdG8gY29uc3VsdCB3aXRoIG91 ciBtYWNoaW5lIGV4cGVydHMgdG8gYmV0dGVyIGV4cGxhaW4gdGhpcyB1c2UgY2FzZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+UHJpbWFyeSBxdWVzdGlvbnMgc2VlbSB0byBiZSB3aGV0aGVy IHRoaXMgaXMganVzdCBhYm91dCBhdXRoZW50aWNhdGlvbiBhdCB0aGUgVENQIFVBIGxheWVyIG9y IGZ1cnRoZXIgYmVsb3cgYXQgc29tZSBpbXBsaWVkIE5BQyBtZWNoYW5pc20uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDsgMykgT25lIHBvc3NpYmxlIHZpZXcgaGVyZSBpcyB0aGF0IHRo ZSBNQVNBIG1heSBiZSBvZmZsaW5lLCBhbmQgbWF5IGhhdmUgcHJvdmlkZWQgYSB2b3VjaGVyIHZp YSBvZmZsaW5lIG1lYW5zIHRvIHRoZSBqb2luIHJlZ2lzdHJhci4mbmJzcDsgVGhpcyBvZiBjb3Vy c2Ugd291bGQgYmUgbm9uY2VsZXNzIHdpdGggYSBsZW5ndGh5IGV4cGlyeSB0aW1lLiZuYnNwOyBJ biBhZGRpdGlvbiwgSSBwb3NpdGVkIGR1cmluZyBCUlNLST8/P3MNCiByZXZpZXcgdGhhdCBwZXJo YXBzIHRoZSBkZXZpY2Ugc2hvdWxkIGJlIGFibGUgdG8gZ2VuZXJhdGUgaXRzIG93biBjZXJ0aWZp Y2F0ZSB2aWEgYSBoaWdoZXIgbGV2ZWwgaW50ZXJmYWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsg T1BDIGFscmVhZHkgaGFzIEFQSXMgbmVlZGVkIHRvIG1hbmFnZSBDZXJ0aWZpY2F0ZXMgb24gYSBE ZXZpY2UuIFRoZSBsaW5rIHRvIHNvbWV0aGluZyBsaWtlIHRoZSBNQVNBIGlzIHdoYXQgd2UgYXJl IG1pc3NpbmcuIE5vbmNlbGVzcyB2b3VjaGVycyB0aGF0IGRvIG5vdCBleHBpcmUgc2hvdWxkIGFs bG93IGxvY2FsIHJlZ2lzdHJhciB0byBlbXVsYXRlIGEgTUFTQSB3aGVuIHRoZSBNQVNBIGlzIG5v IGxvbmdlcg0KIGF2YWlsYWJsZS4gSSB3YW50ZWQgdG8gbWFrZSBzdXJlIHRoYXQgdGhpcyBtb2Rl IG9mIG9wZXJhdGlvbiBpcyBhbGxvd2VkIEJSU0tJLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5ZZXMgaXQgaXMsIGl0IG1heSBqdXN0IG5vdCBiZSBmdWxseSBzcGVjaWZpZWQgaW4gdGhlIGN1 cnJlbnQgdGFyZ2V0ZWQgQlJTS0kgUkZDIHRoYXQgd2UgZmVlbCBldmVyeWJvZHkgd2hvIHdhbnRz IHRvIGltcGxlbWVudCBpdCBoYXMgZXZlcnl0aGluZyB0byBkbyBzbywgYnV0IHRoYXRzIHdvdWxk IGp1c3QgYmUgc3ViamV0IHRvIGZ1dHVyZSBzbWFsbCBSRkMgdG8gY2xvc2UgYW55IHBvc3NpYmxl IGdhcHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgNCkgQ2FuIHlvdSBzYXkgbW9y ZSBhYm91dCB3aGF0IG1lY2hhbmlzbXMgT1BDIGlzIGludGVyZXN0ZWQgaW4gcHVyc3Vpbmc/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0OyBXaXRoIE9QQyB3ZSBhc3N1bWUgdGhhdCBuZXR3b3JrIHNlbGVj dGlvbiBhbmQgSVAgYXNzaWdubWVudCBhcmUgb3V0IG9mIHNjb3BlLiBXaXJlZCBkZXZpY2VzIGFy ZSB0aGUgcHJpbWFyeSBtYXJrZXQgYXQgdGhpcyB0aW1lIGJ1dCA1RyBjb3VsZCBjaGFuZ2UgdGhh dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QlJTS0kgYWxzbyBkb2VzIG5vdCBjYXJlIGFi b3V0IEFkZHJlc3NpbmcuIE9ubHkgQUNQIGRvZXMsIHNvIHlvdSBjYW4gaWdub3JlIHRoYXQgcGFy dCBpZiB5b3UncmUgbm90IGludGVyZXN0ZWQgaW4uIFdlIGhhdmUgdHJpZWQgdG8gc2VwYXJhdGUg b3V0IEFDUCBzcGVjaWZpYyBhc3BlY3RzIGluIHRoZSBCUlNLSSBkb2N1bWVudCBhcyBnb29kIGFz IHBvc3NpYmxlIHdpdGggdGhlIHNvbWV3aGF0IGNvbnZvbHV0ZWQNCiBwcm9jZXNzIHdlIGhhZCBp biB0aGUgSUVURiBob3cgdG8gZHJpdmUgdGhvc2UgZG9jdW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5DaGVlcnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyZuYnNwOyBUb2VybGVzczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0OyBSYW5keTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgRnJvbTogRWxpb3QgTGVhciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmxlYXJAY2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bGVhckBjaXNjby4uY29tPC9zcGFuPjwvYT4mZ3Q7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7IFNlbnQ6IEF1Z3VzdCA2LCAyMDE5IDE6NDcgUE08bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsg VG86IFJhbmR5IEFybXN0cm9uZyAoT1BDKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJhbmR5LmFybXN0 cm9uZ0BvcGNmb3VuZGF0aW9uLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4 dC1kZWNvcmF0aW9uOm5vbmUiPnJhbmR5LmFybXN0cm9uZ0BvcGNmb3VuZGF0aW9uLm9yZzwvc3Bh bj48L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBDYzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlvdC1vbmJvYXJkaW5nQGlldGYu b3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ aW90LW9uYm9hcmRpbmdAaWV0Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBTdWJqZWN0 OiBSZTogW0lvdC1vbmJvYXJkaW5nXSBPUEMgYW5kIEJSU0tJPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OyBIaSBSYW5keSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFRoYW5rcyBmb3IgdGhpcy4mbmJzcDsg SXQ/Pz9zIGEgZ3JlYXQgc3RhcnRpbmcgcG9pbnQuJm5ic3A7IEkgd291bGQgcHJvcG9zZSB0aGF0 IHdlIGRvIGEgY2FsbCBzbyB3ZSBjYW4gZ2V0IHNvbWUgaGlnaCBiYW5kd2lkdGggZGlzY3Vzc2lv biBnb2luZy4mbmJzcDsgUGxlYXNlIG5vdyBzZWUgYmVsb3cuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZndDsgT24gNiBBdWcgMjAxOSwgYXQgMjA6NTgsIFJhbmR5IEFybXN0cm9uZyAoT1BDKSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnJhbmR5LmFybXN0cm9uZ0BvcGNmb3VuZGF0aW9uLm9yZyUzY21h aWx0bzpyYW5keS5hcm1zdHJvbmdAb3BjZm91bmRhdGlvbi5vcmciPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5yYW5keS5hcm1zdHJvbmdAb3BjZm91 bmRhdGlvbi5vcmcmbHQ7bWFpbHRvOnJhbmR5LmFybXN0cm9uZ0BvcGNmb3VuZGF0aW9uLm9yZzwv c3Bhbj48L2E+Jmd0OyZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEkgd2lsbCBz dGFydCB3aXRoIHRoZSBtYWluIHRyb3VibGUgc3BvdHMuIFNvbWUgb2YgdGhlc2UgbWF5IGJlIGFs cmVhZHkgY292ZXJlZCBieSBCUktTSSBidXQgSSBtaXNzZWQgdGhlIGltcGxpY2F0aW9ucyBvZiBz b21lIG9mIHRoZSB0ZXh0OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgMSkgTG93IGVuZCBkZXZpY2Vz IHRoYXQgb25seSBzdXBwb3J0IE9QQzsgdGhpcyBtZWFucyBubyBUTFMgY2xpZW50PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mZ3Q7IGNhcGFiaWxpdGllcyBhbmQgbm8gYWJpbGl0eSB0byBpbml0aWF0ZSBuZXR3b3JrIGNv bW11bmljYXRpb24gKGkuZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgc2VydmVyIG9ubHkgbW9kZSk7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSG93IGRvZXMgT1BDIGhhbmRsZSBzdWNoIGRldmljZXM/ Jm5ic3A7IEkgdGhpbmsgdGhpcyBpcyBhbHNvIGNvbWluZyB1cCBlbHNld2hlcmUuJm5ic3A7IE9u ZSBxdWVzdGlvbiBpcyB3aGV0aGVyIFRMUyBpcyByZXF1aXJlZC4mbmJzcDsgV2l0aG91dCBUTFMg b25lIGRvZXMgbG9zZSBjb25maWRlbnRpYWxpdHksIGJ1dCBzbyBsb25nIGFzIHRoZSBjbGllbnQg Y2FuIHNpZ24gdGhlIHJlcXVlc3QsIG1heWJlIHRoYXQ/Pz9zIGFsbCB5b3UNCiB1c2UuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IDIpIE1hY2hpbmUgYnVpbGRlcnMgdGhhdCBj b21iaW5lIGRldmljZXMgaW50byBhIG1hY2hpbmUgdGhhdCBpcyBzb2xkIGFzIGEgdW5pdC4gVGhl c2UgZGV2aWNlIHN0aWxsIGhhdmUgYSB1bmlxdWUgbmV0d29yayBpZGVudGl0eSBidXQgdGhlIGVm ZmVjdGl2ZSBtYW51ZmFjdHVyZXIgaGFzIGNoYW5nZWQ7IEhvdyB0byBkZWFsIHdpdGggdGhlIERl dmljZUlEPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEF0IHNvbWUgcG9pbnQsIHRoZSB0 aGluZyBkZWNpZGVzIHdoaWNoIHBhcnQgZ2V0cyBhbiBJUCBhZGRyZXNzIG9yIGF0IGxlYXN0IGlz IHJlc3BvbnNpYmxlIGZvciB0aGUgcGh5LiZuYnNwOyBDYW4gdGhhdCBwcm9jZXNzIGJlIGxldmVy YWdlZCB0byBlc3RhYmxpc2ggaWRlbnRpdHk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmd0OyAzKSBEZXZpY2VzIG1heSBiZSByZXNldCB0byBmYWN0b3J5IGRlZmF1bHRz IGFuZCBzb2xkL3RyYW5zZmVycmVkIHRvIGFub3RoZXIgb3JnYW5pemF0aW9uLiBUaGlzIG5lZWRz IHRvIGJlIHBvc3NpYmxlIGV2ZW4gaWYgdGhlIE1BU0EgaXMgbm8gbG9uZ2VyIGF2YWlsYWJsZSAo aS5lLiB0aGUgb3JpZ2luYWwgbWFudWZhY3R1cmVyIGhhcyBnb25lIG91dCBvZiBidXNpbmVzcyku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBPbmUgcG9zc2libGUgdmlldyBoZXJlIGlzIHRoYXQgdGhl IE1BU0EgbWF5IGJlIG9mZmxpbmUsIGFuZCBtYXkgaGF2ZSBwcm92aWRlZCBhIHZvdWNoZXIgdmlh IG9mZmxpbmUgbWVhbnMgdG8gdGhlIGpvaW4gcmVnaXN0cmFyLiZuYnNwOyBUaGlzIG9mIGNvdXJz ZSB3b3VsZCBiZSBub25jZWxlc3Mgd2l0aCBhIGxlbmd0aHkgZXhwaXJ5IHRpbWUuJm5ic3A7IElu IGFkZGl0aW9uLCBJIHBvc2l0ZWQgZHVyaW5nIEJSU0tJPz8/cyByZXZpZXcNCiB0aGF0IHBlcmhh cHMgdGhlIGRldmljZSBzaG91bGQgYmUgYWJsZSB0byBnZW5lcmF0ZSBpdHMgb3duIGNlcnRpZmlj YXRlIHZpYSBhIGhpZ2hlciBsZXZlbCBpbnRlcmZhY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0Ozxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mZ3Q7IDQpIE9mZmxpbmUgb3BlcmF0aW9uIGlzIHRoZSBub3JtIHdpdGggcHJlLWlz c3VlZCB2b3VjaGVycyBkZWxpdmVyZWQgb3V0IG9mIGJhbmQuIFRoZSBwcmUtaXNzdWVkIHZvdWNo ZXJzIHdpbGwgbmVlZCB0byBoYXZlIHJlYXNvbmFibHkgbG9uZyBsaWZldGltZSAoaS5lLiB5ZWFy cyBub3QgaG91cnMpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgVGhlIGxpZmVjeWNsZSBvZiBhIGRl dmljZSBpcyBzaG93biBpbiB0aGUgZm9sbG93aW5nIGRpYWdyYW0uIFRoZTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OyBleHBlY3RhdGlvbiBpcyB3ZSB3b3VsZCBuZWVkIHRvIGFkZCBsaW5rcyB0byB0aGUgTUFTQSBh dCBlYWNoIHN0ZXAgaW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgdGhlIGxpZmV0aW1lPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZndDsgVGhhbmsgeW91IGZvciB0aGF0LiZuYnNwOyBGb3Igd2lyZWQgaXQgc2Vl bXMgdG8gbWUgdGhhdCBhIHBlcm1pc3NpdmUgTUFTQSBtb2RlbCAobG9nZ2luZyBvbmx5KSBjb3Vs ZCBwcm92aWRlIHlvdSBhIHdheSBmb3J3YXJkLiZuYnNwOyBGb3Igd2lyZWxlc3MsIHRoaXMgaXMg bm90IGFuIG9wdGlvbiBiZWNhdXNlIHByb3BlciBuZXR3b3JrIHNlbGVjdGlvbiBuZWVkcyB0byBv Y2N1ci4mbmJzcDsgQW5vdGhlciBxdWVzdGlvbiBpcyB3aGV0aGVyDQogd2UgbmVlZCBhbm90aGVy IG1lY2hhbmlzbSBpcyBuZWNlc3NhcnkgdG8gdmFsaWRhdGUgdGhlIHZvdWNoZXIgKGFrYSwgYSBQ U0sgdy8gcHJvb2Ygb2Yga25vd2xlZGdlLCBvciBEUFAsIGV0YykuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0OyBDYW4geW91IHNheSBtb3JlIGFib3V0IHdoYXQgbWVjaGFuaXNtcyBPUEMgaXMgaW50ZXJl c3RlZCBpbiBwdXJzdWluZz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEVsaW90PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m Z3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IC0tPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IElvdC1vbmJvYXJk aW5nIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86SW90LW9uYm9hcmRpbmdAaWV0 Zi5vcmciPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l Ij5Jb3Qtb25ib2FyZGluZ0BpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaW90LW9uYm9hcmRpbmciPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lvdC1vbmJvYXJkaW5nPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLTxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tLTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGEgaHJlZj0ibWFpbHRvOnR0ZUBjcy5mYXUuZGUiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj50dGVAY3MuZmF1LmRlPC9zcGFuPjwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_BYAPR08MB4903DC283780FC3519F4432BFAD40BYAPR08MB4903namp_-- From nobody Wed Aug 7 03:01:55 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8D91204E0; Wed, 7 Aug 2019 03:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.49 X-Spam-Level: X-Spam-Status: No, score=-14.49 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxaRhImezy_4; Wed, 7 Aug 2019 03:01:41 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C75FA12051C; Wed, 7 Aug 2019 03:01:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=67180; q=dns/txt; s=iport; t=1565172101; x=1566381701; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=1sHFlwbVcbpp6dsOm5NecmiePUyd5mbKu9/wDGZK89c=; b=Beo2WNl7nJNKEhYxQVitWSsxkYjFuzXLb/sMW+F0SJ7EPfY/c/EzP+Rm sPLGoye6LAzjlvBHJy6UY8eM/31yVF7uogC6b7Hc4ife399eYPAQdGmL9 sYVnI6LHy8iXZ5SZwgqzt6TrBfryRg65OL20hPVyZVvwrM09C1x2NV1/I s=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAAAFoUpd/xbLJq1dCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVQDAQEBAQELAYEVU4EcUiASKoQeiHyIWoc3kVQUgWM?= =?us-ascii?q?EAgQDAQEBCQMBARgBCgwBAYQ/AoJkNQgOAQQBAQQBAQIBBm2FJwyFSgEBAQE?= =?us-ascii?q?CAQEBGAlIAwsFBwQLEQQBAQEgAQYDAgInHwkIBgoJgyIBgXsPD6h3AYE+gTK?= =?us-ascii?q?FSYRxCgY1fwGBUIoqgX+BEScfgU5+PoJhAQECgSMSEwFMglUygiYEjA0gGoh?= =?us-ascii?q?Gh3iOJwmCHoIfgQ+QdBuCL4cug2uGUYQYnwGDMoMOAgQGBQIVgVIBNSqBLjM?= =?us-ascii?q?aCBsVOyoBgkE+gQ2JfIVBPQMwAQGMUiuCJQEB?= X-IronPort-AV: E=Sophos;i="5.64,357,1559520000"; d="asc'?scan'208,217";a="15185654" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Aug 2019 10:01:38 +0000 Received: from [10.61.221.4] ([10.61.221.4]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x77A1an6002676 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Aug 2019 10:01:37 GMT From: Eliot Lear Message-Id: <49C13ED8-EF8A-4C1B-9FD6-CF57C0B01F4A@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_102B1FA0-5A45-41CF-BA87-2BA649C4D4C5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 7 Aug 2019 12:01:35 +0200 In-Reply-To: Cc: Toerless Eckert , "iot-onboarding@ietf.org" , "anima@ietf.org" To: "Randy Armstrong (OPC)" References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <20190806223052.md5lp6yeleuvuf5l@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.221.4, [10.61.221.4] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Anima] [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 10:01:46 -0000 --Apple-Mail=_102B1FA0-5A45-41CF-BA87-2BA649C4D4C5 Content-Type: multipart/alternative; boundary="Apple-Mail=_BEEF571D-BD3B-4422-8E98-9835F0B37BEA" --Apple-Mail=_BEEF571D-BD3B-4422-8E98-9835F0B37BEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Randy, Thanks. I will be away on holiday for the next week. However, before I = go I will kick off a doodle for the week of the 19th for on onboarding = meeting to discuss this. Please everyone indicate your interest in = participating by answering the doodle poll. Eliot > On 7 Aug 2019, at 10:57, Randy Armstrong (OPC) = wrote: >=20 > HI Eliot, >=20 > Yes, the Operator needs to ensure that only Devices they authorize can = connect and the zero touch provisioning is a feature we desire. >=20 > Regards, >=20 > Randy >=20 > From: Eliot Lear > Sent: August 7, 2019 1:50 AM > To: Randy Armstrong (OPC) > Cc: Toerless Eckert ; iot-onboarding@ietf.org; = anima@ietf.org > Subject: Re: [Iot-onboarding] OPC and BRSKI >=20 > Hi Randy, >=20 > Thanks again for your comments. Please see below. >=20 >=20 > On 7 Aug 2019, at 10:32, Randy Armstrong (OPC) = > wrote: >=20 > Hi Eliot, >=20 > 1) In an OPC UA environment, might one expect that the join registrar = and the certificate manager be co-resident? >=20 > Yes that is the expectation. >=20 > 2) My bigger question is whether you want to use all of this for = network authentication to avoid unauthorized devices joining the network = in the first place, or whether this is intended solely for application = authentication. >=20 > Counterfeit devices are huge issue in industrial automation. We need = this infrastructure so the Operators can assure themselves that the = Devices they plug into their network are genuine. >=20 > OTOH, Operators don=E2=80=99t need to prove their right to use a = Device. If an Operator has a Device they are entitled to use it (i.e. = Devices can be sold/transferred without approval from the manufacturer). >=20 >=20 > The purpose, as I see it, of the voucher, is simply to provide = zero-touch network provisioning. I was asking a slightly different = question: for purposes of network connectivity will operators want to = know that only devicesthey authorized are connecting (e.g., 802.1X and = then like)? This is a natural assumption in the wireless world, but = less so in wired. >=20 > Eliot >=20 >=20 >=20 > Regards, >=20 > Randy >=20 >=20 > From: Eliot Lear > > Sent: August 7, 2019 12:33 AM > To: Randy Armstrong (OPC) > > Cc: Toerless Eckert >; = iot-onboarding@ietf.org ; anima@ietf.org = > Subject: Re: [Iot-onboarding] OPC and BRSKI >=20 > Randy, >=20 > Thanks. We have irregular calls, but I will poll for one in the 3rd = week of August to discuss your use case. >=20 > In an OPC UA environment, might one expect that the join registrar and = the certificate manager be co-resident? This would be where EST/SCEP = would happen (BRSKI can be viewed as an extension to EST - RFC 7030). = There is no "push mode" for EST. However, my understanding is that the = same capability roughly speaking resides in CIP. >=20 > My bigger question is whether you want to use all of this for network = authentication to avoid unauthorized devices joining the network in the = first place, or whether this is intended solely for application = authentication. >=20 > Eliot >=20 >=20 >=20 >=20 > On 7 Aug 2019, at 01:19, Randy Armstrong (OPC) = > wrote: >=20 > Push should be =E2=80=9CCertificate Manager initiated=E2=80=9D >=20 > From: Iot-onboarding > On Behalf Of Randy Armstrong = (OPC) > Sent: August 6, 2019 4:17 PM > To: Toerless Eckert > > Cc: iot-onboarding@ietf.org ; = anima@ietf.org ; Eliot Lear > > Subject: Re: [Iot-onboarding] OPC and BRSKI >=20 > Hi >=20 > 1) Sure, need to understand how TCP UA works wih the minimum amount of = message authentication to allow for BRSKI. Main challenge may be the = need for pledges to receive messages from registrar that are = authenticated by the registar, but where the pledge has to wait until it = can actually perform the authentication later. Depending on how you = built TCP UA message layer authentication this may be piece of cake / = free or not. >=20 > It would be easy to drop in a OPC UA aware registrar and implement all = of the BRKSI flows back to the MASA. The only nuisance factor is the = 'prior-signed-voucher-request'.. If MASA's are willing allow this field = to be omitted and to trust the Registrar then nothing more needs to = done. If MASA's need this field then we could get it from the Device via = OPC UA but producing the CMS message adds an additional burden on low = end devices (i.e. the need to pull in libraries that provide the same = functionality as OPC UA but do it in different format). >=20 > The 2 modes of operation with a OPC UA aware registrar (the = Certificate Manager is an OPC UA defined entity). >=20 > Pull (device initiated) >=20 > >=20 > Push (Registrar initiated) >=20 > >=20 > Regards, >=20 > Randy >=20 > -----Original Message----- > From: Toerless Eckert > > Sent: August 6, 2019 3:31 PM > To: Randy Armstrong (OPC) > > Cc: Eliot Lear >; = iot-onboarding@ietf.org ; anima@ietf.org = > Subject: Re: [Iot-onboarding] OPC and BRSKI >=20 > On Tue, Aug 06, 2019 at 09:32:45PM +0000, Randy Armstrong (OPC) wrote: > > OPC is layered to separate the application from the choice of = network protocol. TLS/WebSockets is an option but the primary protocol = that will be used by low end devices is UA TCP which provides complete = message based security framework. These devices do not need TLS to have = security and requiring it would require duplication of code. >=20 > Sure, need to understand how TCP UA works wih the minimum amount of = message authentication to allow for BRSKI. Main challenge may be the = need for pledges to receive messages from registrar that are = authenticated by the registar, but where the pledge has to wait until it = can actually perform the authentication later. Depending on how you = built TCP UA message layer authentication this may be piece of cake / = free or not. >=20 > > 2) At some point, the thing decides which part gets an IP address or = at least is responsible for the phy. Can that process be leveraged to = establish identity? > > > > Machines may have a separate network for internal Devices which IPs = assigned by the machine???s DHCP service. Some of these devices may = interact with external equipment via a NAT router which assigns a unique = port to each device. This means the individual Devices need to be = granted access to the operators network when the machine is installed = even though the operator cannot provide them with IPs. > > > > I need to consult with our machine experts to better explain this = use case. >=20 > Primary questions seem to be whether this is just about authentication = at the TCP UA layer or further below at some implied NAC mechanism. >=20 > > 3) One possible view here is that the MASA may be offline, and may = have provided a voucher via offline means to the join registrar. This = of course would be nonceless with a lengthy expiry time. In addition, I = posited during BRSKI???s review that perhaps the device should be able = to generate its own certificate via a higher level interface. > > > > OPC already has APIs needed to manage Certificates on a Device. The = link to something like the MASA is what we are missing. Nonceless = vouchers that do not expire should allow local registrar to emulate a = MASA when the MASA is no longer available. I wanted to make sure that = this mode of operation is allowed BRSKI. >=20 > Yes it is, it may just not be fully specified in the current targeted = BRSKI RFC that we feel everybody who wants to implement it has = everything to do so, but thats would just be subjet to future small RFC = to close any possible gaps. >=20 > > 4) Can you say more about what mechanisms OPC is interested in = pursuing? > > > > With OPC we assume that network selection and IP assignment are out = of scope. Wired devices are the primary market at this time but 5G could = change that. >=20 > BRSKI also does not care about Addressing. Only ACP does, so you can = ignore that part if you're not interested in. We have tried to separate = out ACP specific aspects in the BRSKI document as good as possible with = the somewhat convoluted process we had in the IETF how to drive those = documents. >=20 > Cheers > Toerless >=20 > > Regards, > > > > Randy > > > > From: Eliot Lear > > > Sent: August 6, 2019 1:47 PM > > To: Randy Armstrong (OPC) > > > Cc: iot-onboarding@ietf.org > > Subject: Re: [Iot-onboarding] OPC and BRSKI > > > > Hi Randy, > > > > Thanks for this. It???s a great starting point. I would propose = that we do a call so we can get some high bandwidth discussion going. = Please now see below. > > > > > > On 6 Aug 2019, at 20:58, Randy Armstrong (OPC) = >> wrote: > > > > I will start with the main trouble spots. Some of these may be = already covered by BRKSI but I missed the implications of some of the = text: > > > > 1) Low end devices that only support OPC; this means no TLS client > > capabilities and no ability to initiate network communication (i.e. > > server only mode); > > > > > > How does OPC handle such devices? I think this is also coming up = elsewhere. One question is whether TLS is required. Without TLS one = does lose confidentiality, but so long as the client can sign the = request, maybe that???s all you use. > > > > > > > > 2) Machine builders that combine devices into a machine that is sold = as a unit. These device still have a unique network identity but the = effective manufacturer has changed; How to deal with the DeviceID? > > > > > > At some point, the thing decides which part gets an IP address or at = least is responsible for the phy. Can that process be leveraged to = establish identity? > > > > > > > > > > 3) Devices may be reset to factory defaults and sold/transferred to = another organization. This needs to be possible even if the MASA is no = longer available (i.e. the original manufacturer has gone out of = business). > > > > One possible view here is that the MASA may be offline, and may have = provided a voucher via offline means to the join registrar. This of = course would be nonceless with a lengthy expiry time. In addition, I = posited during BRSKI???s review that perhaps the device should be able = to generate its own certificate via a higher level interface. > > > > > > > > 4) Offline operation is the norm with pre-issued vouchers delivered = out of band. The pre-issued vouchers will need to have reasonably long = lifetime (i.e. years not hours). > > > > The lifecycle of a device is shown in the following diagram. The > > expectation is we would need to add links to the MASA at each step = in > > the lifetime > > > > > > Thank you for that. For wired it seems to me that a permissive MASA = model (logging only) could provide you a way forward. For wireless, = this is not an option because proper network selection needs to occur. = Another question is whether we need another mechanism is necessary to = validate the voucher (aka, a PSK w/ proof of knowledge, or DPP, etc). > > > > Can you say more about what mechanisms OPC is interested in = pursuing? > > > > Eliot > > >=20 > > -- > > Iot-onboarding mailing list > > Iot-onboarding@ietf.org > > https://www.ietf.org/mailman/listinfo/iot-onboarding = >=20 >=20 > -- > --- > tte@cs.fau.de --Apple-Mail=_BEEF571D-BD3B-4422-8E98-9835F0B37BEA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Randy,

Thanks.  I will be away on holiday for the next week. =  However, before I go I will kick off a doodle for the week of the = 19th for on onboarding meeting to discuss this.  Please everyone = indicate your interest in participating by answering the doodle = poll.

Eliot

On 7 Aug 2019, at 10:57, Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org> wrote:

HI = Eliot,
 
Yes, the Operator needs to ensure that only Devices they = authorize can connect and the zero touch provisioning is a feature we = desire.
 
Regards,
 
Randy
 
From: Eliot Lear = <lear@cisco.com> 
Sent: August 7, 2019 1:50 AM
To: Randy Armstrong (OPC) = <randy.armstrong@opcfoundation.org>
Cc: Toerless Eckert <tte@cs.fau.de>; iot-onboarding@ietf.org; anima@ietf.org
Subject: Re: [Iot-onboarding] OPC = and BRSKI
 
Hi Randy,
 
Thanks again for your comments.  Please see below.


On 7 Aug 2019, at 10:32, Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org> wrote:
 
Hi Eliot,
 
1) In an OPC UA environment, might one = expect that the join registrar and the certificate manager be = co-resident?  
 
Yes that is the expectation.
 
2) My bigger question is whether you = want to use all of this for network authentication to avoid unauthorized = devices joining the network in the first place, or whether this is = intended solely for application authentication.
 
Counterfeit devices are huge issue in industrial automation. = We need this infrastructure so the Operators can assure themselves that = the Devices they plug into their network are genuine.
 
OTOH, Operators don=E2=80=99= t need to prove their right to use a Device. If an Operator has a Device = they are entitled to use it (i.e. Devices can be sold/transferred = without approval from the manufacturer).
 
 
The purpose, as I see it, of the = voucher, is simply to provide zero-touch network provisioning.  I = was asking a slightly different question: for purposes of network = connectivity will operators want to know that only devicesthey authorized are connecting (e.g., 802.1X and = then like)?  This is a natural assumption in the wireless world, = but less so in wired.
 
Eliot


 
Regards,
 
Randy
 
 
From: Eliot = Lear <lear@cisco.com> 
Sent: August 7, 2019 12:33 AM
To: Randy Armstrong (OPC) = <randy.armstrong@opcfoundation.org>
Cc: Toerless Eckert <tte@cs.fau.de>; iot-onboarding@ietf.org; anima@ietf.org
Subject: Re: [Iot-onboarding] OPC = and BRSKI
 
Randy,
 
Thanks.  We have irregular calls, = but I will poll for one in the 3rd week of August to discuss your use = case.
 
In an OPC UA environment, might one = expect that the join registrar and the certificate manager be = co-resident?  This would be where EST/SCEP would happen (BRSKI can = be viewed as an extension to EST - RFC 7030).  There is no "push = mode" for EST.  However, my understanding is that the same = capability roughly speaking resides in CIP.
 
My bigger question is whether you want = to use all of this for network authentication to avoid unauthorized = devices joining the network in the first place, or whether this is = intended solely for application authentication.
 
Eliot
 



On 7 Aug = 2019, at 01:19, Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org> = wrote:
 
Push should be = =E2=80=9CCertificate Manager initiated=E2=80=9D
 
From: Iot-onboarding <iot-onboarding-bounces@ietf.org> On Behalf = Of Randy Armstrong = (OPC)
Sent: August 6, 2019 4:17 PM
To: Toerless Eckert <tte@cs.fau.de>
Cc: iot-onboarding@ietf.org; anima@ietf.org; Eliot Lear <lear@cisco.com>
Subject: Re: [Iot-onboarding] OPC = and BRSKI
 
Hi 
 
1) Sure, need to understand how TCP UA = works wih the minimum amount of message authentication to allow for = BRSKI. Main challenge may be the need for pledges to receive messages = from registrar that are authenticated by the registar, but where the = pledge has to wait until it can actually perform the authentication = later. Depending on how you built TCP UA message layer authentication = this may be piece of cake / free or not.
 
It would = be easy to drop in a OPC UA aware registrar and implement all of the = BRKSI flows back to the MASA. The only nuisance factor is the = 'prior-signed-voucher-request'.. If MASA's are willing allow this field = to be omitted and to trust the Registrar then nothing more needs to = done. If MASA's need this field then we could get it from the Device via = OPC UA but producing the CMS message adds an additional burden on low = end devices (i.e. the need to pull in libraries that provide the same = functionality as OPC UA but do it in different format).
 
The 2 modes of operation with a OPC UA = aware registrar (the Certificate Manager is an OPC UA defined = entity).
 
Pull (device initiated)
 
<image005.png>
 
Push (Registrar initiated)
 
<image006.png>
 
Regards,
 
Randy
 
-----Original Message-----
From: Toerless = Eckert <tte@cs.fau.de> 
Sent: August = 6, 2019 3:31 PM
To: Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org>
Cc: Eliot Lear <lear@cisco.com>; iot-onboarding@ietf.org; anima@ietf.org
Subject: Re: = [Iot-onboarding] OPC and BRSKI
 
On Tue, Aug 06, 2019 at 09:32:45PM = +0000, Randy Armstrong (OPC) wrote:
> OPC is layered to separate the = application from the choice of network protocol. TLS/WebSockets is an = option but the primary protocol that will be used by low end devices is = UA TCP which provides complete message based security framework.  = These devices do not need TLS to have security and requiring it would = require duplication of code.
 
Sure, need to understand how TCP UA = works wih the minimum amount of message authentication to allow for = BRSKI. Main challenge may be the need for pledges to receive messages = from registrar that are authenticated by the registar, but where the = pledge has to wait until it can actually perform the authentication = later. Depending on how you built TCP UA message layer authentication = this may be piece of cake / free or not.
 
> 2) At some point, the thing = decides which part gets an IP address or at least is responsible for the = phy.  Can that process be leveraged to establish identity?
> 
> Machines may have a separate = network for internal Devices which IPs assigned by the machine???s DHCP = service. Some of these devices may interact with external equipment via = a NAT router which assigns a unique port to each device. This means the = individual Devices need to be granted access to the operators network = when the machine is installed even though the operator cannot provide = them with IPs.
> 
> I need to consult with our machine = experts to better explain this use case.
 
Primary questions seem to be whether = this is just about authentication at the TCP UA layer or further below = at some implied NAC mechanism.
 
> 3) One possible view here is that = the MASA may be offline, and may have provided a voucher via offline = means to the join registrar.  This of course would be nonceless = with a lengthy expiry time.  In addition, I posited during = BRSKI???s review that perhaps the device should be able to generate its = own certificate via a higher level interface.
> 
> OPC already has APIs needed to = manage Certificates on a Device. The link to something like the MASA is = what we are missing. Nonceless vouchers that do not expire should allow = local registrar to emulate a MASA when the MASA is no longer available. = I wanted to make sure that this mode of operation is allowed BRSKI.
 
Yes it is, it may just not be fully = specified in the current targeted BRSKI RFC that we feel everybody who = wants to implement it has everything to do so, but thats would just be = subjet to future small RFC to close any possible gaps.
 
> 4) Can you say more about what = mechanisms OPC is interested in pursuing?
> 
> With OPC we assume that network = selection and IP assignment are out of scope. Wired devices are the = primary market at this time but 5G could change that.
 
BRSKI also does not care about = Addressing. Only ACP does, so you can ignore that part if you're not = interested in. We have tried to separate out ACP specific aspects in the = BRSKI document as good as possible with the somewhat convoluted process = we had in the IETF how to drive those documents.
 
Cheers
    Toerless
 
> Regards,
> 
> Randy
> 
> From: Eliot Lear <lear@cisco..com>
> Sent: August 6, 2019 1:47 PM
> To: Randy Armstrong (OPC) <randy.armstrong@opcfoundation.org>
> Cc: iot-onboarding@ietf.org
> Subject: Re: [Iot-onboarding] OPC = and BRSKI
> 
> Hi Randy,
> 
> Thanks for this.  It???s a = great starting point.  I would propose that we do a call so we can = get some high bandwidth discussion going.  Please now see = below.
> 
> 
> On 6 Aug 2019, at 20:58, Randy = Armstrong (OPC) <randy.armstrong@opcfoundation.org<mailto:randy.armstrong@opc= foundation.org>> wrote:
> 
> I will start with the main trouble = spots. Some of these may be already covered by BRKSI but I missed the = implications of some of the text:
> 
> 1) Low end devices that only = support OPC; this means no TLS client
> capabilities and no ability to = initiate network communication (i.e.
> server only mode);
> 
> 
> How does OPC handle such = devices?  I think this is also coming up elsewhere.  One = question is whether TLS is required.  Without TLS one does lose = confidentiality, but so long as the client can sign the request, maybe = that???s all you use.
> 
> 
> 
> 2) Machine builders that combine = devices into a machine that is sold as a unit. These device still have a = unique network identity but the effective manufacturer has changed; How = to deal with the DeviceID?
> 
> 
> At some point, the thing decides = which part gets an IP address or at least is responsible for the = phy.  Can that process be leveraged to establish identity?
> 
> 
> 
> 
> 3) Devices may be reset to factory = defaults and sold/transferred to another organization. This needs to be = possible even if the MASA is no longer available (i.e. the original = manufacturer has gone out of business).
> 
> One possible view here is that the = MASA may be offline, and may have provided a voucher via offline means = to the join registrar.  This of course would be nonceless with a = lengthy expiry time.  In addition, I posited during BRSKI???s = review that perhaps the device should be able to generate its own = certificate via a higher level interface.
> 
> 
> 
> 4) Offline operation is the norm = with pre-issued vouchers delivered out of band. The pre-issued vouchers = will need to have reasonably long lifetime (i.e. years not hours).
> 
> The lifecycle of a device is shown = in the following diagram. The
> = expectation is we would need to add links to the MASA at each step = in
> the lifetime
> 
> 
> Thank you for that.  For = wired it seems to me that a permissive MASA model (logging only) could = provide you a way forward.  For wireless, this is not an option = because proper network selection needs to occur.  Another question = is whether we need another mechanism is necessary to validate the = voucher (aka, a PSK w/ proof of knowledge, or DPP, etc).
> 
> Can you say more about what = mechanisms OPC is interested in pursuing?
> 
> Eliot
> 
 
> --
> Iot-onboarding mailing list
> Iot-onboarding@ietf.org
> https://www.ietf.org/mailman/listinfo/iot-onboarding=
 
 
-- 
---
tte@cs.fau.de
= --Apple-Mail=_BEEF571D-BD3B-4422-8E98-9835F0B37BEA-- --Apple-Mail=_102B1FA0-5A45-41CF-BA87-2BA649C4D4C5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXUqhfwAKCRBugA9nE248 uFnWAKDdWzGyJPzewVHzpvi6GiLIDCL25ACfecfoEwOcPAQ/I/MAwM79CruLsh4= =m9TU -----END PGP SIGNATURE----- --Apple-Mail=_102B1FA0-5A45-41CF-BA87-2BA649C4D4C5-- From nobody Wed Aug 7 03:13:46 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5BF112066A; Wed, 7 Aug 2019 03:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id slr9TOkisXY8; Wed, 7 Aug 2019 03:13:42 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 455AF120669; Wed, 7 Aug 2019 03:13:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2465; q=dns/txt; s=iport; t=1565172819; x=1566382419; h=from:mime-version:date:subject:message-id:to; bh=A00/LYd1Q6pguDLWy7jrHZ8ueAbXJ3utc7XQ/faelzg=; b=OabhZg0iiqJYDFJ62bDPFhnJsIlN/thmhJ/YhEjZIcByDA7PhXsE1xwV 1wfRnLb1akTX+fVipWDojYbi3d1ZLoryWGxY6L/5IU/tJlOpnJ9uRS2yq VTigP2YqcQoh0THsePrvKt/KbNl4+fWt1h0zdhKu8O0t/8Vv3iFocc0q/ M=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAD/o0pd/xbLJq1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwQBAQEBAQsBgwRSIBKESIgcYJtehgeBewIEAwEBAQk?= =?us-ascii?q?DAQEjDAEBhDoDgmg0CQ4BBAEBBAEBAgEGbYUnDIVBM3QBPgJggzQBggoPqQE?= =?us-ascii?q?BgT6BMoQ0AYYFCgY1fwGBUIoqgX+BOB+CHog7MoImBIwfiG6WHwmCHgOCHIE?= =?us-ascii?q?Pgy+NRRuCL4cug2uKaY1Nh1qNDIMOAgQGBQIVgVA4gVgzGggbFWUBgkI9hXW?= =?us-ascii?q?KVT0Dj1QBAQ?= X-IronPort-AV: E=Sophos;i="5.64,357,1559520000"; d="asc'?scan'208,217";a="15185964" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Aug 2019 10:13:36 +0000 Received: from [10.61.221.4] ([10.61.221.4]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x77ADad3016654 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 7 Aug 2019 10:13:36 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_4B20E6B2-F304-44A5-8FA2-A36A36CA5512"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 7 Aug 2019 12:13:34 +0200 Message-Id: <556E7BDA-A5A7-423B-89A2-C99ECA40CE51@cisco.com> To: iot-onboarding@ietf.org, anima@ietf.org X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.221.4, [10.61.221.4] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Anima] Doodle poll for IoT Onboarding Meeting X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 10:13:44 -0000 --Apple-Mail=_4B20E6B2-F304-44A5-8FA2-A36A36CA5512 Content-Type: multipart/alternative; boundary="Apple-Mail=_EE8A8E0B-5588-4A48-BD05-F65DAF613796" --Apple-Mail=_EE8A8E0B-5588-4A48-BD05-F65DAF613796 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone, Please if you could, respond to the doodle poll below by the 12th. = While I will be on holiday next week, I=E2=80=99ll be sure to send along = the meeting details for the meeting once the poll has closed. Proposed Agenda: OPC use case BRSKI IESG review status Other draft status https://doodle.com/poll/9htegcxviwcg2hq2 Thanks, Eliot --Apple-Mail=_EE8A8E0B-5588-4A48-BD05-F65DAF613796 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = everyone,

Please if = you could, respond to the doodle poll below by the 12th.  While I = will be on holiday next week, I=E2=80=99ll be sure to send along the = meeting details for the meeting once the poll has closed.

Proposed = Agenda:
  • OPC = use case
  • BRSKI IESG review status
  • Other draft status

https://doodle.com/poll/9htegcxviwcg2hq2

Thanks,

Eliot
= --Apple-Mail=_EE8A8E0B-5588-4A48-BD05-F65DAF613796-- --Apple-Mail=_4B20E6B2-F304-44A5-8FA2-A36A36CA5512 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXUqkTgAKCRBugA9nE248 uFyZAJ0ZB48NP98kjhikFRw+NIOU/M5GCQCg/ape6rUxsPrMvPMus7hyekOGdEI= =KqDm -----END PGP SIGNATURE----- --Apple-Mail=_4B20E6B2-F304-44A5-8FA2-A36A36CA5512-- From nobody Wed Aug 7 09:45:54 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 475EB120437 for ; Wed, 7 Aug 2019 09:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 XvQbZg5X03Pr for ; Wed, 7 Aug 2019 09:45:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 365C1120689 for ; Wed, 7 Aug 2019 09:45:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1C297380BE; Wed, 7 Aug 2019 12:45:10 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C76743F; Wed, 7 Aug 2019 12:45:46 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter cc: "anima\@ietf.org" In-Reply-To: <17032fd8-b316-6225-5ddd-cdfc9c1ce2ea@gmail.com> References: <5523.1565112243@localhost> <17032fd8-b316-6225-5ddd-cdfc9c1ce2ea@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] comments on draft-ietf-anima-grasp-api X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 16:45:53 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > On 07-Aug-19 05:24, Michael Richardson wrote: >> >> I read draft-ietf-anima-grasp-api from the expired drafts list. > Right, the -03 draft expired while we were in Montreal. Our plan is to > make the next update after the two promised reviews arrive. >> I think that the event-loop architecture is different than a polling >> architecture. I agree that given an event-loop architecture, that one >> can build a polled architecture, but the converse is not true. The >> event-loop mechanism needs something to send events, while the polling >> system does not. > My understanding is limited, but the diagram at > https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/ seems > to say something different: the loop detects events by polling. (Yes, > OK, that's talking about Javascript but the fundamentals are the same, > surely?) I see some of the confusion. poll(2) is a poorly named system call (that replaces select(2)), which retrieves the next event from the kernel. It doesn't really poll :-) I think that the important point is that: 1) you can't see events in the queue. 2) you can't ask of an action is done, only find out that it finished. >> I don't understand what the asa_nonce is for. > OK, then we need more text. >> Is this something that the underlying GRASP library is supposed to use >> internally to sort out which ASA is which? Maybe this should be >> either a UUID, or an opaque type, which might in some cases, be a file >> handle, or contain one. (a la FILE *) > Yes, it should probably be opaque. In fact the documentation of the > concrete Python API says so: "Note - the ASA must store the asa_nonce > (an opaque Python object) and use it in every subsequent GRASP call." Good, we agree. The GRASP library should create and manage these handles. Nonce is the wrong term and will be confused with the protocol and cryptographic things; handle is a better term. >> 2.3.3 Discovery. 1) I would prefer to be able to ask for the list of >> cached locators for an objective directly. > OK, I can see that might be useful. >> 2) Rather than flush them explicitely (because there might be other >> ASAs depending upon them), I'd like to do a discovery that asks for >> objectives that are at at most X miliseconds old. Flush is therefore >> X=0. > Hmm. I think we assumed you would only flush if you had reason to > believe they were stale. But certainly adding an age limit seems > reasonable. The age limit means that I never explicitely flush, thus ASA-1 doesn't mess with the cache for ASA-2. >> 3) In both threaded and event-loop situations, I'd like to be able >> have a function called when there are new answers, otherwise, I have >> to poll. > Right, that's a callback in event loop terminology. It's a matter of > preference; I have an aversion to side effects so I don't like > callbacks. However, you're probably right that it should be an option. In a threaded environment, I really want a thread per negotiation. That means, on the server side (the side giving out resources), that I need a thread per client, which means something has to spawn off these threads. >> (And, if a function is called, then the question as to which thread >> does the calling is important; specifically one needs to know which >> other functions one call at that point answer may well be none. The >> answer depends upon how locking of structures is done. The answer is >> easier in event-loop version) > Yes; callbacks are a Bad Idea in a multithreaded version. Not a bad idea, just an idea that must be clearly defined. >> listen_negotiate. I think that this call is wrong in both threaded >> and event-loop use. I think that in threaded version, I really want a >> new thread spawned off that does the right things (negotiate_wait, >> etc.), > You do need a new thread. But I don't have time right now to explain > how that works in my example use cases. And my explanation would be > Pythonesque. So the API has to perhaps return something that says to the ASA, "new negotiation here", rather than attempting to actually ever do anything. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1LADoACgkQgItw+93Q 3WVudwf/Xg4j7AOlexphXIhnHrl7aIf27iUe7q0Y9qnuOlDC+GbSZcklQXXljc4Y vsB2fbc5dL5SikMa1XQffkqtikusBWN5IjRuV+4yLLqujqgkMLIA1PEsgelYo0+M JseJsDBYdBm/pQYg8WRnMWQ+MU3mPk6SsLiWF9A5Pt8AHiX9rtZDan109X2tnAUZ Q/DLUGdv6s1n7rUqKD/fHG6bWUAUcOqhXS8AjVDxkPtJLR3SEGmMvPPHLbyE50zI Kz2eXCqN/jHdqWJj+f/TxpDCEi7RpJvCquNCIUZ/URMzD8a7ZaM8twyUgVi7Wxxh UXPo7at1TPBS7/0/h7uHaKqOz+jZ0Q== =7KpG -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 7 10:23:08 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A154312070E; Wed, 7 Aug 2019 10:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, RCVD_IN_DNSWL_MED=-2.3, 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 e6mhUtjde9nj; Wed, 7 Aug 2019 10:22:58 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E614D12068E; Wed, 7 Aug 2019 10:22:57 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id E7455548014; Wed, 7 Aug 2019 19:22:52 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id D7438440041; Wed, 7 Aug 2019 19:22:52 +0200 (CEST) Date: Wed, 7 Aug 2019 19:22:52 +0200 From: Toerless Eckert To: Michael Richardson Cc: Eliot Lear , "Randy Armstrong (OPC)" , "iot-onboarding@ietf.org" , anima@ietf.org Message-ID: <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11781.1565189957@localhost> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 17:23:01 -0000 On Wed, Aug 07, 2019 at 10:59:17AM -0400, Michael Richardson wrote: > > How does OPC handle such devices? I think this is also coming up > > elsewhere. One question is whether TLS is required. Without TLS one > > does lose confidentiality, but so long as the client can sign the > > request, maybe that???s all you use. > > The TLS encryption provides confidentiality, yes, and I agree that it > is not critical to onboarding. The TLS Client and ServerCertificate and > resulting channel is critical though as it provides the cryptographic > hook on which the voucher is attached. Thats what i referred to in my prior email: We would need to understand how to most easily duplicate the mutual authentication with certificates during TLS connection setup with OPC TCP UA messages.: | Sure, need to understand how TCP UA works wih the minimum | amount of message authentication to allow for BRSKI. Main | challenge may be the need for pledges to receive messages | from registrar that are authenticated by the registar, | but where the pledge has to wait until it can actually | perform the authentication later. Depending on how you | built TCP UA message layer authentication this may be | piece of cake / free or not. Cheers Toerless > >> 4) Offline operation is the norm with pre-issued vouchers delivered > >> out of band. The pre-issued vouchers will need to have reasonably long > >> lifetime (i.e. years not hours). > >> > >> The lifecycle of a device is shown in the following diagram. The > >> expectation is we would need to add links to the MASA at each step in > >> the lifetime > > > Thank you for that. For wired it seems to me that a permissive MASA > > model (logging only) could provide you a way forward. For wireless, > > this is not an option because proper network selection needs to occur. > > Another question is whether we need another mechanism is necessary to > > validate the voucher (aka, a PSK w/ proof of knowledge, or DPP, etc). > > > Can you say more about what mechanisms OPC is interested in pursuing? > > +1 > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > -- > Iot-onboarding mailing list > Iot-onboarding@ietf.org > https://www.ietf.org/mailman/listinfo/iot-onboarding -- --- tte@cs.fau.de From nobody Wed Aug 7 12:43:15 2019 Return-Path: <0100016c6d9b4c92-77a6c841-c195-4323-b467-169c4bfabdee-000000@amazonses.watsen.net> X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB05120306; Wed, 7 Aug 2019 12:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9aKryZjjpyr; Wed, 7 Aug 2019 12:43:11 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978711201C9; Wed, 7 Aug 2019 12:43:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1565206990; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=L5mQV2E1h01McuZB2q1VUD7cdTH2nB2vBZ9Qe26HzhY=; b=ROfdxtrLCIv5tImceKlzkmemKsm7lwtE7b1X6FJOsED7mZkkSdfe/4aXHiB20OFH Lbodz09reVhpOdMLCAAAY9C+QkR6Vz0T4V0xycn14EjwlrBSDCGDyf5Xh3Y2JyFR9NN B8gxdjESLpRaq2NZNV6XNHRtnHMHlMKaDvXtQ2Ao= From: Kent Watsen Message-ID: <0100016c6d9b4c92-77a6c841-c195-4323-b467-169c4bfabdee-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_FF25FBD7-5763-4FD4-BDF6-F935026B27F3" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 7 Aug 2019 19:43:10 +0000 In-Reply-To: Cc: "Randy Armstrong (OPC)" , "iot-onboarding@ietf.org" , Toerless Eckert , "anima@ietf.org" To: Eliot Lear References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <20190806223052.md5lp6yeleuvuf5l@faui48f.informatik.uni-erlangen.de> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.08.07-54.240.8.88 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [Anima] [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 19:43:13 -0000 --Apple-Mail=_FF25FBD7-5763-4FD4-BDF6-F935026B27F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 7, 2019, at 4:50 AM, Eliot Lear wrote: >=20 > The purpose, as I see it, of the voucher, is simply to provide = zero-touch network provisioning. I was asking a slightly different = question: for purposes of network connectivity will operators want to = know that only devices they authorized are connecting (e.g., 802.1X and = then like)? This is a natural assumption in the wireless world, but = less so in wired. More specifically, the voucher enables the device to trust the network, = i.e., the entity claiming to be the device's owner. Without the = voucher, there is the TOFU (trust on first use), a.k.a. "resurrecting = duckling" problem. Kent --Apple-Mail=_FF25FBD7-5763-4FD4-BDF6-F935026B27F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Aug 7, 2019, at 4:50 AM, Eliot Lear <lear@cisco.com> = wrote:

The purpose, as I see it, of the voucher, is simply to = provide zero-touch network provisioning.  I was asking a slightly = different question: for purposes of network connectivity will operators = want to know that only devices they authorized are connecting (e.g., 802.1X and = then like)?  This is a natural assumption in the wireless world, = but less so in wired.

More specifically, the voucher enables the device = to trust the network, i.e., the entity claiming to be the device's = owner.  Without the voucher, there is the TOFU (trust on first = use), a.k.a. "resurrecting duckling" problem.

Kent

= --Apple-Mail=_FF25FBD7-5763-4FD4-BDF6-F935026B27F3-- From nobody Wed Aug 7 14:08:07 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB8A120059; Wed, 7 Aug 2019 14:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 NHPgbhFczVXN; Wed, 7 Aug 2019 14:07:56 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C17112003F; Wed, 7 Aug 2019 14:07:56 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id C73A83818D; Wed, 7 Aug 2019 17:07:17 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BBB31479; Wed, 7 Aug 2019 17:07:54 -0400 (EDT) From: Michael Richardson To: "iot-onboarding\@ietf.org" , "anima\@ietf.org" Reply-to: iot-onboarding@ietf.org In-Reply-To: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <20190806223052.md5lp6yeleuvuf5l@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 21:07:59 -0000 --=-=-= Content-Type: text/plain Randy Armstrong (OPC) wrote: > It would be easy to drop in a OPC UA aware registrar and implement all > of the BRKSI flows back to the MASA. The only nuisance factor is the > 'prior-signed-voucher-request'. If MASA's are willing allow this field > to be omitted and to trust the Registrar then nothing more needs to > done. If MASA's need this field then we could get it from the Device > via OPC UA but producing the CMS message adds an additional burden on > low end devices (i.e. the need to pull in libraries that provide the > same functionality as OPC UA but do it in different format). Please spend some time reading RFC8366 and RFC8572 (SZTP). prior-signed-voucher-request is how BRSKI establishes proximity over a local TLS connection, and you seem to want to avoid that technology. That's not the only kind of *voucher request*, and RFC8366 allows vouchers to have other kinds of assertions. It sounds like you would be very happy with supply-chain integration of vouchers, and the RFC8572 use of "verified" vouchers would fit well. In order to support resale, some mechanism of updating the trust anchors would have to be profiled. RFC8572 uses CMS signed JSON for vouchers, and for some configuration assertions, and while RESTCONF is an option, it's not the only option. I have downloaded the OPC documents, and I'll skim them tomorrow. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1LPaoACgkQgItw+93Q 3WWSnQf/UdD99SEguJwiee3fPXLqeGTFRHZZlHgvDPA5Z0JJL3BexLmfyBrESqn6 +za/L1jO1MntvuyYV66ebHR9WFL1oa4FeQZRPAqytPN38Q1W2ktStDAibt8BbxaD mKlgsKw5X3mvwNuJ/ZfHOLXIWV1tREtlT+9gwz3Ge9JAqVk93OnlSv51nFNwi03P nnNcRKDp2cHDa+h/bckeFfmfGgQQ1cSbXAzgNCZOibh56PZgWATV3hH+dd4PyQgL A4napapb992CgTuhAO+ltyeqcVYTFGEegXrSTQMq+WClShVw724MDy6XaUGj6dkh 72NzvmXJVeyS/RQ/TV1HN8aS/HtXng== =UiGS -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 7 14:15:32 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8417C1200DF; Wed, 7 Aug 2019 14:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ov8x98wfNhO7; Wed, 7 Aug 2019 14:15:28 -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 560A9120059; Wed, 7 Aug 2019 14:15:28 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9085D3818D; Wed, 7 Aug 2019 17:14:49 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 94D5A479; Wed, 7 Aug 2019 17:15:26 -0400 (EDT) From: Michael Richardson To: "iot-onboarding\@ietf.org" , "anima\@ietf.org" In-Reply-To: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <20190806223052.md5lp6yeleuvuf5l@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 21:15:31 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Randy Armstrong (OPC) wrote: > Counterfeit devices are huge issue in industrial automation. We need > this infrastructure so the Operators can assure themselves that the > Devices they plug into their network are genuine. So, just to inject some existential angst: If the MASA goes away or is compromised, then all the devices from that manufacturer can not be proved to not be counterfeit. Note that the MASA going away is not the same as the Manufacturer going awa= y. > OTOH, Operators don=E2=80=99t need to prove their right to use a Devi= ce. If an > Operator has a Device they are entitled to use it (i.e. Devices can be > sold/transferred without approval from the manufacturer). I'm not sure you really mean to say it this way :-) That would lead to the conclusion that it is okay for the operator in the next suite (or next cabinet in a DC, or adjacent distillation tower in a refiner), to use the device in my suite/cabinet/tower. The key problem is the verb "has" needs to be made very clear. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1LP24ACgkQgItw+93Q 3WVTPQgAhpgNdZ5FIiGhmZ9kL86kiWlf25t0PbASIBuK4RAWS2kaNBO/QP3X/qIN RBLBPwDbbW7WxN2Ew+uSA4+1RcJ7cqR9VIGk4ALHaQzwY+YWc3mvxpvq7eZPYJXM pigVJBbEGYD3wrHne5Zgs8kDllABaeqBFgw1ngSkRz8Fd/+OiSefIlrzRVt8twdQ rGx+Gt0Cj/KQEvRX+pOnt2T6yJd8WPFEsOn7X5z0eBPuZnDqH6+5xwRumLE/TXSW ZtnLNtJ24nSh+YjYNaNDv/DoOXE/QgYirN0tzgulVF84F+NvjBGhLngwHXDD3v+E 95XeT0+POHxoMa/PH0asY/8STT88Sg== =wVB3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 7 14:22:30 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFA11200DF; Wed, 7 Aug 2019 14:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 8wtD1pqGPBMT; Wed, 7 Aug 2019 14:22:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A46912003F; Wed, 7 Aug 2019 14:22:25 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 30CE63818D; Wed, 7 Aug 2019 17:21:47 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 32C7D479; Wed, 7 Aug 2019 17:22:24 -0400 (EDT) From: Michael Richardson To: Kent Watsen cc: "Owen Friel \(ofriel\)" , "iot-onboarding\@ietf.org" , Rifaat Shekh-Yusef , "anima\@ietf.org" In-Reply-To: <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@email.amazonses.com> References: <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@email.amazonses.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 21:22:28 -0000 --=-=-= Content-Type: text/plain Kent Watsen wrote: > Skimming quickly, I see now the direction to go to a cloud registrar to > be redirected to a local registrar. I feel compelled to point out that > this is exactly what SZTP (RFC 8572) does, or at least, supports. > Actually, as a more general statement, it was originally said that the > two WG's approaches were different, but they are now becoming more and > more alike. Well, since SZTP is published already, it's more like the > ANIMA approach is becoming more like SZTP, albeit seemingly with more > complexity. SZTP does not directly result in the same mutually authenticated TLS (EST) connection to a Registrar that BRSKI does. This was not an explicit SZTP goal. What it could do though, is to provide a source of (secure) bootstrap configuration in which such a connection could be initiated. In my mind, I see a fragment of signed JUNOS, IOS (CISCO, not Apple), etc. CLI configuration that initiates the connection. Such a thing would not be standardized. But, I would think that this is exactly the kind of thing that could be encoded in YANG. My understanding of https://tools.ietf.org/html/draft-ietf-netconf-keystore is that it would provided for Registrar initiated (PUSH) updating of device certificates, but would not provide a way for a device to initiate (PULL) to a securely identified EST server. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1LQQ8ACgkQgItw+93Q 3WWI/gf/bwVjAfF8vN9e02GdUOnmrLrhdhHAiRJFOjGJymFThOVX/mAtkRIeGUy7 sbOV5700wMKS5pesDEu/8VVsu+FXxu++XjuEMRRMiW3kg5XuknAzBSrEdCKANBO9 OH/LbfKXZME92odX2U1us42YlxUNh5C94lJB1A+rLP6ZLXIJRsINzXbG+a3Bxj0z DMDBbp5yvNKx2ljKnikQ7s2tEtbQJEH/Kyn75vd1WQtTWDqF0n7yK3K7FFCNXdug Dqc0wXERzBP1Ux5gzcSOyCzHzNA7y2zZ51Sxtkg6RMhxNkOTGQzeFl2Yn7diKrPJ QxjmC0u9xh6QULzRt4Mflbw++U7zVQ== =pS42 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 7 14:24:47 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA4F12003F; Wed, 7 Aug 2019 14:24:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 mqeht_KpHsVS; Wed, 7 Aug 2019 14:24:39 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC321200DF; Wed, 7 Aug 2019 14:24:39 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 491933818F; Wed, 7 Aug 2019 17:24:01 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 54FE9479; Wed, 7 Aug 2019 17:24:38 -0400 (EDT) From: Michael Richardson To: Kent Watsen cc: Toerless Eckert , "iot-onboarding\@ietf.org" , "Owen Friel \(ofriel\)" , Rifaat Shekh-Yusef , "anima\@ietf.org" In-Reply-To: <0100016c6968e7a2-4acac184-768f-4971-8b4f-459165f0aa4f-000000@email.amazonses.com> References: <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@email.amazonses.com> <20190806221242.4j7eprxeklup5c3m@faui48f.informatik.uni-erlangen.de> <0100016c6968e7a2-4acac184-768f-4971-8b4f-459165f0aa4f-000000@email.amazonses.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 21:24:42 -0000 --=-=-= Content-Type: text/plain Kent Watsen wrote: > True, but it seems that getting a domain certificate and getting an > initial configuration are at least two distinct steps in ANIMA, whereas > they're rolled into one step with SZTP. I'm missing where SZTP gets a domain certificate in a standard way. I totally see how it gets initial configuration though. I also see how that initial configuration can be caused to do an enrollment, by leveraging some specific, vendor-specific, configuration command. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1LQZUACgkQgItw+93Q 3WUW2Qf9EFefi35i9ivIj0ihX/kNm1rOLTV71+xs48IztYV/mYawMm+6191I3H0s NfoGSCtmLe/vFKIYofA3kdATWOXY9aj6rGhkbsm1gOp9XWRF0sRIGhX+LIrjzmKm hhBRa+vRpz9l7RQO/qluNtqrbUMCGonEeO/7bqn/MIguMH3+LvHh1e9ZW/Efe0rX N3Vs1kA1S4NeS2FBBl7MmqJThSWrPYPrB5VOpO9Z+IxVrT/UgmP+NY+vhLp6p0GC Q9ArDdUKRGQxHyoIPk1HuRBozyjgAfy1vo6PNmfeKmaFPDcgST/5d/JM1FH6Wt7s fOpVn0LMzdDRrI6WZ2BCBlLkojUE/w== =s+8Z -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 7 14:30:28 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1041120116; Wed, 7 Aug 2019 14:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=opcfoundation.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 oVSin7Qc05qM; Wed, 7 Aug 2019 14:30:24 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820054.outbound.protection.outlook.com [40.107.82.54]) (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 9458F1200DF; Wed, 7 Aug 2019 14:30:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VpKv8u930rPoCyyTfJT39toDwP6Sd2GLcWfs5ERJtiIWzwBXEgHuJkg4U9tdJYdTJbjm++sFqhY6PcnSmJ1bInYrIkceYuLa/ZHozXE33dTPWz8k1jahWd6ZostJVhmPeEMwY/GsDHOZkzyLBolIijhuHykunnTthy+537JtyR+6+m+bVXSiU+8tQP/sMGkkqsnLUElF56uzv5BjuUQ0bxkUhdOnlS4C0uvhR9i7t1ulefRSvvFsH6iZuwV7YWi3xPmLciOWUsqAnqun6LC3ONL0wgT+iK4bA0s+XgckkBzzEBJ3g62N/eL1wmXIciCqnrq39ToONNSgKlzCe0nrsg== 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=dFvCS4ojxMzeL0riqqTcc/YalZlKW3mgiDJHXPnI1XQ=; b=FQqJ2vlW4qOBkLd+JmWanklI+b+qhGCQDqmkMFTdARPblkAdsKJEGV7K0MHQnlGOd3blzK6+ouu7N9vpBviyhbKDGZNVrxJVLBxEHon3wrIumfRPXpyb75FZ1rIxlJR8rKVgcA5EUKni6R86zCD2geLosPSxXpYOsDr11vihzHAN/UlcE6yzS6lufGUIw80KhWxHTqQJR51ZmxvqNIFxYHuCHuNWupxsNl7H4N2uxgnFr2fUGgHORiSI2OVGpCQOqzysvn1irsRA5NMksaEOI7drpaDisAalagKFPzGmco2zW0xui+EHgPPLu52wY8IDIqopEe320qtK6N9pr2pt6w== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=opcfoundation.org;dmarc=pass action=none header.from=opcfoundation.org;dkim=pass header.d=opcfoundation.org;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opcfoundation.onmicrosoft.com; s=selector1-opcfoundation-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dFvCS4ojxMzeL0riqqTcc/YalZlKW3mgiDJHXPnI1XQ=; b=hj/uGgzG94FcumAgZg4U0ce4Qu9jjlicNi54xe0D98RsCzWI0R/a0Rlm7/dfz52DjqV9T8EWe1UcW+VE7bTfoILfqcwh5n+hsG2luPJCTY4R4cuRZ7FLVLF/i93UfapsBivzok8oBz9s7aPhVBxLOIAgVL8SmBroVz+4y9kLIv4= Received: from BYAPR08MB4903.namprd08.prod.outlook.com (20.176.255.96) by BYAPR08MB4549.namprd08.prod.outlook.com (52.135.234.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.14; Wed, 7 Aug 2019 21:30:21 +0000 Received: from BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53]) by BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53%4]) with mapi id 15.20.2157.015; Wed, 7 Aug 2019 21:30:21 +0000 From: "Randy Armstrong (OPC)" To: Michael Richardson , "iot-onboarding@ietf.org" , "anima@ietf.org" Thread-Topic: [Iot-onboarding] OPC and BRSKI Thread-Index: AdVMZzs5EDHMP+c/QWCVcWuK34MU/QAGrJ8AAADfarAABKcngAAAO+sQAANovwAAARHHUAAAmp+QABFFfIAAAX6+0AAbN40AAAAVERA= Date: Wed, 7 Aug 2019 21:30:21 +0000 Message-ID: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <20190806223052.md5lp6yeleuvuf5l@faui48f.informatik.uni-erlangen.de> <1669.1565212526@localhost> In-Reply-To: <1669.1565212526@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=randy.armstrong@opcfoundation.org; x-originating-ip: [24.80.80.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 293cb250-f093-4dc1-defc-08d71b7e73c5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR08MB4549; x-ms-traffictypediagnostic: BYAPR08MB4549: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(366004)(136003)(39840400004)(346002)(199004)(189003)(13464003)(256004)(64756008)(76176011)(66476007)(66946007)(486006)(66556008)(14444005)(66446008)(74316002)(53546011)(25786009)(7736002)(316002)(86362001)(8676002)(6436002)(26005)(508600001)(76116006)(305945005)(81166006)(81156014)(8936002)(9686003)(55016002)(14454004)(186003)(2906002)(71200400001)(229853002)(71190400001)(476003)(446003)(11346002)(6506007)(99286004)(53936002)(33656002)(102836004)(6246003)(5660300002)(3846002)(7696005)(110136005)(52536014)(66066001)(2501003)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR08MB4549; H:BYAPR08MB4903.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: opcfoundation.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: zZNUsHJL57A1SF5MCmK8XJzDMpF/SNadCHksmA9dxEBsxauZvS7xQw3VjpjJ/V28TaLwGaWgiJslIHZ2RAixGa5Vc1FfwXggc2AGeOfPIo5LBySIOFBkE9HjOgm5s16IQlsvy/3GUd9OW3uezPnqJ4J8JO2mubzoX4/CabcMi0ubEukxDnrEQaJUhohSitsQIR11Gzs1NOdx+Dsm2rlVlA62mluiXYfHDiH/lSs5+QKANNcQ36zMGMMfR1G12dpx2r8anVXOidFeqPsjRcv5Yx4IkD4+svYtQVC5MzvvbpvgFTd4KkqiYOq6w4y3izyVuT4rR6CiLuOYGaNdoCAjf3SO/NP7CNzBS6dO5afKmda3uMawWMimjpkmNxxSNavqIIDktABRPOcbZWp6AlXySqHWFJzz46zKMczAFprL92I= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: opcfoundation.org X-MS-Exchange-CrossTenant-Network-Message-Id: 293cb250-f093-4dc1-defc-08d71b7e73c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2019 21:30:21.6622 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2d8ef4e4-d41c-489c-8004-bb99304b60fe X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VuVUJaPU4G7CEcPBoMxR6QAwx2reefBDnWPQccEmfHiAwev8DFWzH8d+wW000jHn/OmEOdJER1ne46Ut1PwaLpL5gwBKU++NJapCHfaQ+/vrAnaaa5vq7Fhd7ZyEqBKO X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4549 Archived-At: Subject: Re: [Anima] [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 21:30:27 -0000 PiBJZiB0aGUgTUFTQSBnb2VzIGF3YXkgb3IgaXMgY29tcHJvbWlzZWQsIHRoZW4gYWxsIHRoZSBk ZXZpY2VzDQo+ICBmcm9tIHRoYXQgbWFudWZhY3R1cmVyIGNhbiBub3QgYmUgcHJvdmVkIHRvIG5v dCBiZSBjb3VudGVyZmVpdC4NCg0KSWYgZWFjaCBEZXZpY2UgaGFzIGEgbWFudWZhY3R1cmVyIGlz c3VlZCBDZXJ0aWZpY2F0ZSB3aXRoIHRoZSBwcml2YXRlIGtleSBpbiBzZWN1cmUgc3RvcmFnZSBs aWtlIGEgVFBNIHRoZW4gdGhlIHZlcmlmaWNhdGlvbiBvZiBhIERldmljZSBjYW4gaGFwcGVuIGFz IGxvbmcgYXMgdGhlIE9wZXJhdG9yIGhhcyBhIGNvcHkgb2YgdGhlIE1hbnVmYWN0dXJlciBDQS4N ClRoaXMgd2FzIG91ciBvcmlnaW5hbCBtb2RlbCB1bnRpbCBzb21lb25lIHJhaXNlZCBCUlNLSS4N Cg0KID4gVGhhdCB3b3VsZCBsZWFkIHRvIHRoZSBjb25jbHVzaW9uIHRoYXQgaXQgaXMgb2theSBm b3IgdGhlIG9wZXJhdG9yIGluIHRoZQ0KID4gbmV4dCBzdWl0ZSAob3IgbmV4dCBjYWJpbmV0IGlu IGEgREMsIG9yIGFkamFjZW50IGRpc3RpbGxhdGlvbiB0b3dlciBpbiBhDQogPiByZWZpbmVyKSwg dG8gdXNlIHRoZSBkZXZpY2UgaW4gbXkgc3VpdGUvY2FiaW5ldC90b3dlci4NCg0KVGhlIE9wZXJh dG9yIGRlY2lkZXMgd2hhdCBEZXZpY2VzIGdvIG9uIHRoZSBuZXR3b3JrcyB0aGUgT3BlcmF0b3Ig Y29udHJvbHMuDQpBcyBsb25nIGFzIGEgc3lzdGVtIGlzIGluIHBsYWNlIHRvIGFsbG93IHRoZSBP cGVyYXRvciAobm90IHRoZSBNYW51ZmFjdHVyZXIgb3IgTUFTQSkgdG8gYmxvY2sgYWNjZXNzIHRv IGEgbmV0d29yayB0aGVuIHRoZSBuZXR3b3JrIGlzIHNlY3VyZS4NClRoZSBvbmUgcmlzayB3aGlj aCBleGlzdHMgaXMgdGhlZnQuIGkuZS4gYSB0aGllZiBjYW4ndCBiZSBwcmV2ZW50ZWQgZnJvbSB1 c2luZyBhIHN0b2xlbiBkZXZpY2UuDQpJIGNhbiBzZWUgdGhpcyBiZWluZyBhIGhpZ2ggcHJpb3Jp dHkgcmVxdWlyZW1lbnQgZm9yIG1vYmlsZSBwaG9uZXMgYnV0IG5vdCBmb3IgUExDcy4NCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElvdC1vbmJvYXJkaW5nIDxpb3Qtb25ib2Fy ZGluZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWljaGFlbCBSaWNoYXJkc29uDQpT ZW50OiBBdWd1c3QgNywgMjAxOSAyOjE1IFBNDQpUbzogaW90LW9uYm9hcmRpbmdAaWV0Zi5vcmc7 IGFuaW1hQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0lvdC1vbmJvYXJkaW5nXSBPUEMgYW5kIEJS U0tJDQoNCg0KUmFuZHkgQXJtc3Ryb25nIChPUEMpIDxyYW5keS5hcm1zdHJvbmdAb3BjZm91bmRh dGlvbi5vcmc+IHdyb3RlOg0KICAgID4gQ291bnRlcmZlaXQgZGV2aWNlcyBhcmUgaHVnZSBpc3N1 ZSBpbiBpbmR1c3RyaWFsIGF1dG9tYXRpb24uIFdlIG5lZWQNCiAgICA+IHRoaXMgaW5mcmFzdHJ1 Y3R1cmUgc28gdGhlIE9wZXJhdG9ycyBjYW4gYXNzdXJlIHRoZW1zZWx2ZXMgdGhhdCB0aGUNCiAg ICA+IERldmljZXMgdGhleSBwbHVnIGludG8gdGhlaXIgbmV0d29yayBhcmUgZ2VudWluZS4NCg0K U28sIGp1c3QgdG8gaW5qZWN0IHNvbWUgZXhpc3RlbnRpYWwgYW5nc3Q6DQogICBJZiB0aGUgTUFT QSBnb2VzIGF3YXkgb3IgaXMgY29tcHJvbWlzZWQsIHRoZW4gYWxsIHRoZSBkZXZpY2VzDQogICBm cm9tIHRoYXQgbWFudWZhY3R1cmVyIGNhbiBub3QgYmUgcHJvdmVkIHRvIG5vdCBiZSBjb3VudGVy ZmVpdC4NCg0KTm90ZSB0aGF0IHRoZSBNQVNBIGdvaW5nIGF3YXkgaXMgbm90IHRoZSBzYW1lIGFz IHRoZSBNYW51ZmFjdHVyZXIgZ29pbmcgYXdheS4NCg0KICAgID4gT1RPSCwgT3BlcmF0b3JzIGRv buKAmXQgbmVlZCB0byBwcm92ZSB0aGVpciByaWdodCB0byB1c2UgYSBEZXZpY2UuIElmIGFuDQog ICAgPiBPcGVyYXRvciBoYXMgYSBEZXZpY2UgdGhleSBhcmUgZW50aXRsZWQgdG8gdXNlIGl0IChp LmUuIERldmljZXMgY2FuIGJlDQogICAgPiBzb2xkL3RyYW5zZmVycmVkIHdpdGhvdXQgYXBwcm92 YWwgZnJvbSB0aGUgbWFudWZhY3R1cmVyKS4NCg0KSSdtIG5vdCBzdXJlIHlvdSByZWFsbHkgbWVh biB0byBzYXkgaXQgdGhpcyB3YXkgOi0pDQogIFRoYXQgd291bGQgbGVhZCB0byB0aGUgY29uY2x1 c2lvbiB0aGF0IGl0IGlzIG9rYXkgZm9yIHRoZSBvcGVyYXRvciBpbiB0aGUNCiAgbmV4dCBzdWl0 ZSAob3IgbmV4dCBjYWJpbmV0IGluIGEgREMsIG9yIGFkamFjZW50IGRpc3RpbGxhdGlvbiB0b3dl ciBpbiBhDQogIHJlZmluZXIpLCB0byB1c2UgdGhlIGRldmljZSBpbiBteSBzdWl0ZS9jYWJpbmV0 L3Rvd2VyLg0KDQpUaGUga2V5IHByb2JsZW0gaXMgdGhlIHZlcmIgImhhcyIgbmVlZHMgdG8gYmUg bWFkZSB2ZXJ5IGNsZWFyLg0KDQotLQ0KTWljaGFlbCBSaWNoYXJkc29uIDxtY3IrSUVURkBzYW5k ZWxtYW4uY2E+LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MgIC09IElQdjYgSW9UIGNvbnN1bHRp bmcgPS0NCg0KDQoNCg== From nobody Wed Aug 7 17:47:08 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895DB120099; Wed, 7 Aug 2019 17:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=opcfoundation.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 7MrFHCTV0GIM; Wed, 7 Aug 2019 17:46:59 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720089.outbound.protection.outlook.com [40.107.72.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0AC0120033; Wed, 7 Aug 2019 17:46:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BqCvybJoA/bAJ1ychCE3uQ+b/et3ahm8kHWgmLzqTG9oE8BRYcwnxc35fHHFxpEI1YFMLBqcFJ4PqNKfkGb3MFmWQLzexGJADx7oDd/uAjCUoQnCDpz2A2pGug7/DiSPxV2ACBDMhuhqqzHxKyoDPbyMqrWuGv/pi95xYKCviGy5Emn7Gzsu1x0PWR1y8boe7Db0gKKFj4bY7GBsZW6R20SMd4ygmYOpB5B/F8kjdSGusOrki0hFuNQgBECKl9C5HhMp9D9yof7SWvMfZql1r+zOCf48ZzkNaSClID9as5MWMrCo+Ipx9G0DLxySJ8ZC6q+IBalu6js7ubjAM2kxZg== 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=EvhfTd6G8J6Ene2jOfV4HWiE2Cimiir0JW4xDDvnMn8=; b=aEAAz9in5G7eWoq3ZDQtNEdVFr6TzHHiWeOzApbFyRKPjYsBjZQyHuoyJxwGGspsuZ4GO9pi9aF2b5AiN2WVQq9wzcqVxi0ySzKc8RGNZ2FFA2WYw9xuHB0z+LU74nXMtsGfgrRDnmUyzF6SgRMq3NIBT+qgsA9U6uvN0mB4W5Fwkqej3gp9GcoEaSJta+2M9RiW4jngUO/vyyKHVIBFgSMDjKRgj8LanJ/Wr3TDyCvcAzDUfHQKZ1DZlDwYsUpI2N8a4ajW5JiKmoE02wpulrEqc3WXh2Eo4FLVpEVFkNt4Pa6iVocfrNkVX7QULtw82+uh4zqS99RpXhWG6BtcPA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=opcfoundation.org;dmarc=pass action=none header.from=opcfoundation.org;dkim=pass header.d=opcfoundation.org;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opcfoundation.onmicrosoft.com; s=selector1-opcfoundation-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EvhfTd6G8J6Ene2jOfV4HWiE2Cimiir0JW4xDDvnMn8=; b=dBVbp9Efwa7K413LlPe6zuNYjp0Bo1XiITomVkEsN1RzILnfM1ZWKW5CBMlJwsaGfErEtODQ8aWC3SZg76t4spNbEYr9fI9KxPqNKKANpLNpKezP89kY6AWbxj/1l+qXgAOOtIJe7bvJaP/cJodXlcKVIxQ5qAMzSfO1MQpKpQA= Received: from BYAPR08MB4903.namprd08.prod.outlook.com (20.176.255.96) by BYAPR08MB4550.namprd08.prod.outlook.com (52.135.234.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.12; Thu, 8 Aug 2019 00:46:56 +0000 Received: from BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53]) by BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53%4]) with mapi id 15.20.2157.015; Thu, 8 Aug 2019 00:46:56 +0000 From: "Randy Armstrong (OPC)" To: Toerless Eckert , Michael Richardson CC: Eliot Lear , "iot-onboarding@ietf.org" , "anima@ietf.org" Thread-Topic: [Iot-onboarding] OPC and BRSKI Thread-Index: AdVMZzs5EDHMP+c/QWCVcWuK34MU/QAGrJ8AAADfarAABKcngAAmKcyAAAUDvQAADyfMUA== Date: Thu, 8 Aug 2019 00:46:56 +0000 Message-ID: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=randy.armstrong@opcfoundation.org; x-originating-ip: [24.80.80.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a4f81e50-8ca6-4cda-c3e6-08d71b99e9f9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(2017052603328)(7193020); SRVR:BYAPR08MB4550; x-ms-traffictypediagnostic: BYAPR08MB4550: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39840400004)(346002)(136003)(396003)(366004)(13464003)(189003)(199004)(6116002)(71190400001)(256004)(26005)(33656002)(81166006)(4326008)(81156014)(8936002)(8676002)(6506007)(66946007)(508600001)(64756008)(55016002)(186003)(446003)(71200400001)(76176011)(102836004)(66556008)(6306002)(476003)(5660300002)(53546011)(6436002)(74316002)(76116006)(99286004)(11346002)(316002)(66476007)(14454004)(66446008)(14444005)(66066001)(6246003)(9686003)(305945005)(5024004)(52536014)(229853002)(53936002)(54906003)(2906002)(86362001)(966005)(25786009)(486006)(110136005)(7696005)(3846002)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR08MB4550; H:BYAPR08MB4903.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: opcfoundation.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: pfqtvRelpwsgBkB4u6v6WezvtNl5TtuYtkAmLEtdXWO+pS1NSBFlCqUzSwQNIeGUEhqOskvMl6FWn4Ko310UxokzhzyQip3xwftzk1i/QWfhmFkU5a+qBhopibkhF8sLUgtwN0ytQLNRgYip26YivbkOwhm2g5PLT/X35iQX7ZJTwcLtZ90ua5BWVDdH5crsLrfdzAB4418XsQgdm9sHOq7eeKUe4ApUeNL426x4+qSpYQxS+yZqnGtXtOLmsuBTIUsOkn8rpnyPSNvi0JfljlhQzFig1e8ZpK75YV0L1K/W+pN55VdfmRVzawIySwzuxqPRB7JlUvQA+MHwx1ftWnAssT8qDW8JGDFPfSC/ZamOkyLosnzTgS7kbRG/tMNwKy6J6+KeKJiZDi/dUZeGG44NwXFcymiEW88aVU70Ph0= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: opcfoundation.org X-MS-Exchange-CrossTenant-Network-Message-Id: a4f81e50-8ca6-4cda-c3e6-08d71b99e9f9 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2019 00:46:56.3401 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2d8ef4e4-d41c-489c-8004-bb99304b60fe X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WEFkvRR0GXl91xAe2/oiN1NG15bUkChjviUg99iJnjJfhl2NIJ/TpxheH19gl/+zyCrVvOIHQF6KpFZiI+Zil0TgnkGD7Bo+aGjdrDvkoAEajYA9FtkhPQidHXU4PLdv X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4550 Archived-At: Subject: Re: [Anima] [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 00:47:02 -0000 Toerless, > Thats what i referred to in my prior email: We would need to understand h= ow to most easily duplicate the mutual authentication with certificates dur= ing TLS connection setup with OPC TCP UA messages.: OPC UA CP requires mutual authentication with Certificates bound to the app= lication rather than the machine. It provides everything that you get from = TLS. So when the Pledge Device connects to the Registrar or the Certificate Mana= ger using UA the Device proves it has possession of the Device private key.= =20 That said, the KeyPair used for communication does not need to be the same = as the KeyPair used to authenticate.=20 Regards, Randy -----Original Message----- From: Toerless Eckert =20 Sent: August 7, 2019 10:23 AM To: Michael Richardson Cc: Eliot Lear ; Randy Armstrong (OPC) ; iot-onboarding@ietf.org; anima@ietf.org Subject: Re: [Iot-onboarding] OPC and BRSKI On Wed, Aug 07, 2019 at 10:59:17AM -0400, Michael Richardson wrote: > > How does OPC handle such devices? I think this is also coming up > > elsewhere. One question is whether TLS is required. Without TLS o= ne > > does lose confidentiality, but so long as the client can sign the > > request, maybe that???s all you use. >=20 > The TLS encryption provides confidentiality, yes, and I agree that it=20 > is not critical to onboarding. The TLS Client and ServerCertificate=20 > and resulting channel is critical though as it provides the=20 > cryptographic hook on which the voucher is attached. Thats what i referred to in my prior email: We would need to understand how= to most easily duplicate the mutual authentication with certificates durin= g TLS connection setup with OPC TCP UA messages.: | Sure, need to understand how TCP UA works wih the minimum amount of=20 | message authentication to allow for BRSKI. Main challenge may be the=20 | need for pledges to receive messages from registrar that are=20 | authenticated by the registar, but where the pledge has to wait until=20 | it can actually perform the authentication later. Depending on how you=20 | built TCP UA message layer authentication this may be piece of cake /=20 | free or not. Cheers Toerless > >> 4) Offline operation is the norm with pre-issued vouchers delivere= d > >> out of band. The pre-issued vouchers will need to have reasonably = long > >> lifetime (i.e. years not hours). > >> > >> The lifecycle of a device is shown in the following diagram. The > >> expectation is we would need to add links to the MASA at each step= in > >> the lifetime >=20 > > Thank you for that. For wired it seems to me that a permissive MAS= A > > model (logging only) could provide you a way forward. For wireless= , > > this is not an option because proper network selection needs to occ= ur. > > Another question is whether we need another mechanism is necessary = to > > validate the voucher (aka, a PSK w/ proof of knowledge, or DPP, etc= ). >=20 > > Can you say more about what mechanisms OPC is interested in pursuin= g? >=20 > +1 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works =20 > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > -- > Iot-onboarding mailing list > Iot-onboarding@ietf.org > https://www.ietf.org/mailman/listinfo/iot-onboarding --=20 --- tte@cs.fau.de From nobody Wed Aug 7 21:31:38 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A35120094; Wed, 7 Aug 2019 21:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=Ab0DJOWl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qDHiVmtL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9NhE4EZK1lv; Wed, 7 Aug 2019 21:31:35 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D16612000E; Wed, 7 Aug 2019 21:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4458; q=dns/txt; s=iport; t=1565238695; x=1566448295; h=from:to:subject:date:message-id:mime-version; bh=niyKMCwXpK9JNWV3uXUuAdfJoo1IWcSshTD/ZkULewo=; b=Ab0DJOWlB74l2+0WBtspMejLcsixXk/QJrqdQHlsvzeX//DChbIRVkH2 DJOETeaHrIQviWjgD4V6hyU5L8INE4ZP9GCW9OBDNm/jkwfzBcEE3fGUZ RNqXT3537KdzEyxuDMBOAiLFrLLUuPRAfP+kTgO440LJctyw4C4uIF0l3 E=; IronPort-PHdr: =?us-ascii?q?9a23=3AZ/dLmR9CwGvjk/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/bB7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcOBBEThBPXrdCc9Ws9FUQwt8g=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAADwpEtd/49dJa1MFwMaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFTBQEBAQELAYFEUANtVSAECyqEHlmCbgOEUoZfTJlsgS6?= =?us-ascii?q?BJANUCQEBAQkDAQElCAIBAYQ/AheCOyM0CQ4BBAEBBAEBAwEKbYUnDIVNFhE?= =?us-ascii?q?dAQEkFA0EATQEBQcGAgQZFyQCAQEDARIIGoMBgWoDHQECDDmgBwKBOIhgcYE?= =?us-ascii?q?ygnoBAQVEhEwYgg0HAwYFgS8BhVGGEheBQD+BEUaCHoNNBBh9OxFFCII8MoI?= =?us-ascii?q?mjwuFBn+WIAkCghwDhlqNYYIwhy6OVI1Nh1qQGgIEAgQFAg4BAQWBUDiBWHA?= =?us-ascii?q?VgycTgi8MF4Evgh+KU3IBgSiLUoIuAQE?= X-IronPort-AV: E=Sophos;i="5.64,360,1559520000"; d="scan'208";a="616123769" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Aug 2019 04:31:33 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x784VXFk009679 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Aug 2019 04:31:33 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 7 Aug 2019 23:31:33 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 8 Aug 2019 00:31:32 -0400 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 7 Aug 2019 23:31:32 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hf6qXxDytYB4gGyIo3VhVLBQxel4PwuzxHDeFV/5/Xqu6ZVHXP7HibbZIXg9+6htVgY8sbTloz/o0oufePPZV+okDUV1CpY0ttaBFzwVn7SdDrt/wZQqR3XsALbmQ2fEw+5wubsK2nojnlUyDj/MAvH8G03lpBc0K75dNVJ+A4yeOv4D6H8UP2C3nrzJYAtx/sth1Z219pg8pwgzTSkQWRTFIn9/suXitpUsj8JQN7K3wyBj0xmxTyBL+/SWEyxH8l+E83/aNBiDvqip5CIZXMCx7cRTY0jYY1pihJMsoBnO+0EMed8am940dW+XTp02WJgcEfh/FRN1jArwW0nxnA== 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=D4CknoI6tQPV6VYv2qn5lGbb5BwAC2G9A17FPgfFHrc=; b=GG5gcLu3UEdupXW0qeKJzATEdnLo8Bjnq3twvjsmUYA81dm6NmzkrJ78Wafry1qzaJtVP759dQ3w4Y4aDJfD1eVw7p6a6XsRcuYi3BmmoWW8+B4/6l+mYz+31MXAHGOXiNlJR/s0ltk7tTGm/gEIKMamZrRcEjYG9yb4HR84oPMiYmj3fVjnlt30Wc9grkamx4Z+Kyh7T4MBl44O89Akt4CBvdLvbdrFPA7QaXqCmSmE3dKcWT3Ahu7V/t2SmZMWS4bzXYhUH07sBgtXjC4MhwwUR1awg15qU2QQA3nMyeJfjrI/WvB3v63p0pGAxjGIG3w0ewzcek+4PR7uwkAj1A== 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=D4CknoI6tQPV6VYv2qn5lGbb5BwAC2G9A17FPgfFHrc=; b=qDHiVmtL5vWnB4XIXx2KidgLWB7m0t3BgP/wu0dn3jzzAvM0BD7+Bla0YXM8smYYBJ6IO6r3Y8wO1TtCs72HLd6lGdWdMYemHrncR3VtiatBSZCsswoBBAvCJdc3YqVoibYvHVUUNOKRKgDCOKLvW5gmf4N2aMxtzRjX/WHLG54= Received: from BYAPR11MB3814.namprd11.prod.outlook.com (20.178.239.88) by BYAPR11MB2789.namprd11.prod.outlook.com (52.135.228.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2136.16; Thu, 8 Aug 2019 04:31:30 +0000 Received: from BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::c5e6:22b8:9d47:2fbb]) by BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::c5e6:22b8:9d47:2fbb%5]) with mapi id 15.20.2157.011; Thu, 8 Aug 2019 04:31:30 +0000 From: "Eliot Lear (elear)" To: "iot-onboarding@ietf.org" , "anima@ietf.org" Thread-Topic: Hold for IoT Onboarding Virtual Meeting Thread-Index: AdVNoiZpR8Ihba17XUiDYm03RShw7g== Date: Thu, 8 Aug 2019 04:31:30 +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: spf=none (sender IP is ) smtp.mailfrom=elear@cisco.com; x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAAAAAAAAAAAAAAAAAAAAAAAAAAAMQAAAHZDYWwtVWlkAQAAAEZDMjY2MTNDLTkwOTYtNEQwNC05QjgwLTZCQTg3N0EyN0EyQQA= x-originating-ip: [2001:420:c0c0:1003::2b3] x-ms-office365-filtering-correlation-id: 6cf29bf1-e138-46b6-ccf1-08d71bb94953 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2789; x-ms-traffictypediagnostic: BYAPR11MB2789:MeetingMessage x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(366004)(376002)(39860400002)(346002)(136003)(497574002)(199004)(189003)(110136005)(25786009)(14444005)(8936002)(256004)(33656002)(186003)(46003)(305945005)(81156014)(81166006)(486006)(476003)(7696005)(14454004)(99286004)(102836004)(4744005)(5660300002)(966005)(8676002)(7736002)(6116002)(6506007)(76116006)(91956017)(74316002)(71190400001)(52536014)(66476007)(66556008)(64756008)(66446008)(478600001)(71200400001)(66946007)(53936002)(450100002)(55016002)(6306002)(316002)(6436002)(2501003)(16799955002)(86362001)(9686003)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2789; H:BYAPR11MB3814.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: XxlnUec6/mG44oA1ZDBH9zTWzLs59fg18g9ynoVVQyQHu5lMeDKohG7zIZ14ZCnaqU95LJ3BTbufy/pk9QVqcsbXFH+Nr+juvHNS3KkF8rmRypisN/4mNtopHwY5RWEVm1P/nnUQwfO4EoohwL/m13kc9ReyTyKsf8WF4CTuN2W6vojNf+xKaj1YoX8XhD0OeDwXPmTf96zL7k8g1zBhYgnV48pdDiMBi9jMNxxtVl7aCux9PTn+25/h/sQEgLumWf5N9FFjmUwZz5RyPhQCYsAhAaXyHmjEKb8uOU/jfgtpyeRZjUQz6TdLjDZS8gZLBaE9cqXTZo3MoTGe40/CSj75rk22R2go0hRMS18JII4qEV7DT4BZB6nDNmr469xqrxMStguWaQ7oqp0zGirIIuAW5DnSvvQS1YqlosPTBYY= Content-Type: multipart/alternative; boundary="_002_BYAPR11MB38142E3CA85751BFD7CB8A53BFD70BYAPR11MB3814namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6cf29bf1-e138-46b6-ccf1-08d71bb94953 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2019 04:31:30.7773 (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: JjAHNy3O5dF6kD2YYKegadjA4eioTT4dBRd3endF3DARRtWTLR1K9IvrlxKvvQb0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2789 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: [Anima] Hold for IoT Onboarding Virtual Meeting X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 04:31:37 -0000 --_002_BYAPR11MB38142E3CA85751BFD7CB8A53BFD70BYAPR11MB3814namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please hold this time for the onboarding discussion (I'm on vacation and am= sending this a bit early). This is an IoT Onboarding virtual meeting.=0A= =0A= Tentative Agenda:=0A= =0A= - OPC UA use case=0A= - updates on drafts=0A= - AOB=0A= =0A= =0A= =0A= =0A= Meeting Information=0A= =0A= Meeting link:=0A= https://cisco.webex.com/cisco/j.php?MTID=3Dm16f8e0d12f6d12c3c37984c73f2= 0efb8=0A= Meeting number:=0A= 207 046 128=0A= Password:=0A= c3wvus3x (23988739 from phones)=0A= Host key:=0A= 735404 =0A= =0A= More ways to join=0A= =0A= Join by video system=0A= Dial 207046128@cisco.webex.com=0A= You can also dial 173.243.2.68 and enter your meeting number.=0A= =0A= Join by phone=0A= +1-866-432-9903 Call-in toll-free number (US/Canada)=0A= +1-408-525-6800 Call-in number (US/Canada)=0A= Access code: 207 046 128=0A= =0A= Global call-in numbers | Toll-free calling restrictions = --_002_BYAPR11MB38142E3CA85751BFD7CB8A53BFD70BYAPR11MB3814namp_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpXLiBFdXJv cGUgU3RhbmRhcmQgVGltZQ0KQkVHSU46U1RBTkRBUkQNCkRUU1RBUlQ6MTYwMTAxMDFUMDMwMDAw DQpUWk9GRlNFVEZST006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClJSVUxFOkZSRVE9WUVBUkxZ O0lOVEVSVkFMPTE7QllEQVk9LTFTVTtCWU1PTlRIPTEwDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRB WUxJR0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9G RlNFVFRPOiswMjAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllN T05USD0zDQpFTkQ6REFZTElHSFQNCkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0KT1JHQU5J WkVSO0NOPUVsaW90IExlYXIgKGVsZWFyKTpNQUlMVE86ZWxlYXJAY2lzY28uY29tDQpBVFRFTkRF RTtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NO PWlvdC1vbmJvYXINCiBkaW5nQGlldGYub3JnOk1BSUxUTzppb3Qtb25ib2FyZGluZ0BpZXRmLm9y Zw0KQVRURU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JT VlA9VFJVRTtDTj1hbmltYUBpZXRmDQogLm9yZzpNQUlMVE86YW5pbWFAaWV0Zi5vcmcNCkRFU0NS SVBUSU9OO0xBTkdVQUdFPWVuLVVTOlBsZWFzZSBob2xkIHRoaXMgdGltZSBmb3IgdGhlIG9uYm9h cmRpbmcgZGlzY3Vzcw0KIGlvbiAoSSdtIG9uIHZhY2F0aW9uIGFuZCBhbSBzZW5kaW5nIHRoaXMg YSBiaXQgZWFybHkpLiAgVGhpcyBpcyBhbiBJb1QgT25iDQogb2FyZGluZyB2aXJ0dWFsIG1lZXRp bmcuXG5cblRlbnRhdGl2ZSBBZ2VuZGE6XG5cbiAtIE9QQyBVQSB1c2UgY2FzZVxuIC0gdXANCiBk YXRlcyBvbiBkcmFmdHNcbiAtIEFPQlxuXG5cblxuXG5NZWV0aW5nIEluZm9ybWF0aW9uXG5cbk1l ZXRpbmcgbGluazpcbiAgIA0KICBodHRwczovL2Npc2NvLndlYmV4LmNvbS9jaXNjby9qLnBocD9N VElEPW0xNmY4ZTBkMTJmNmQxMmMzYzM3OTg0YzczZjIwZWZiDQogOFxuTWVldGluZyBudW1iZXI6 XG4gICAgMjA3IDA0NiAxMjhcblBhc3N3b3JkOlxuICAgIGMzd3Z1czN4ICgyMzk4ODczOSBmcm8N CiBtIHBob25lcylcbkhvc3Qga2V5OlxuICAgIDczNTQwNCBcblxuTW9yZSB3YXlzIHRvIGpvaW5c blxuSm9pbiBieSB2aWRlbyBzeQ0KIHN0ZW1cbiAgICBEaWFsIDIwNzA0NjEyOEBjaXNjby53ZWJl eC5jb21cbiAgICBZb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuDQogNjggYW5kIGVudGVyIHlv dXIgbWVldGluZyBudW1iZXIuXG5cbkpvaW4gYnkgcGhvbmVcbiAgICArMS04NjYtNDMyLTk5MDMg Q2ENCiBsbC1pbiB0b2xsLWZyZWUgbnVtYmVyIChVUy9DYW5hZGEpXG4gICAgKzEtNDA4LTUyNS02 ODAwIENhbGwtaW4gbnVtYmVyIChVUw0KIC9DYW5hZGEpXG4gICAgQWNjZXNzIGNvZGU6IDIwNyAw NDYgMTI4XG5cbiAgICBHbG9iYWwgY2FsbC1pbiBudW1iZXJzIHwgVG9sDQogbC1mcmVlIGNhbGxp bmcgcmVzdHJpY3Rpb25zIA0KVUlEOkZDMjY2MTNDLTkwOTYtNEQwNC05QjgwLTZCQTg3N0EyN0Ey QQ0KU1VNTUFSWTtMQU5HVUFHRT1lbi1VUzpIb2xkIGZvciBJb1QgT25ib2FyZGluZyBWaXJ0dWFs IE1lZXRpbmcNCkRUU1RBUlQ7VFpJRD1XLiBFdXJvcGUgU3RhbmRhcmQgVGltZToyMDE5MDgyOVQx NzAwMDANCkRURU5EO1RaSUQ9Vy4gRXVyb3BlIFN0YW5kYXJkIFRpbWU6MjAxOTA4MjlUMTgwMDAw DQpDTEFTUzpQVUJMSUMNClBSSU9SSVRZOjUNCkRUU1RBTVA6MjAxOTA4MDhUMDQzMTMwWg0KVFJB TlNQOk9QQVFVRQ0KU1RBVFVTOkNPTkZJUk1FRA0KU0VRVUVOQ0U6MA0KWC1NSUNST1NPRlQtQ0RP LUFQUFQtU0VRVUVOQ0U6MA0KWC1NSUNST1NPRlQtQ0RPLU9XTkVSQVBQVElEOjIxMTc2MTY0ODMN ClgtTUlDUk9TT0ZULUNETy1CVVNZU1RBVFVTOlRFTlRBVElWRQ0KWC1NSUNST1NPRlQtQ0RPLUlO VEVOREVEU1RBVFVTOkJVU1kNClgtTUlDUk9TT0ZULUNETy1BTExEQVlFVkVOVDpGQUxTRQ0KWC1N SUNST1NPRlQtQ0RPLUlNUE9SVEFOQ0U6MQ0KWC1NSUNST1NPRlQtQ0RPLUlOU1RUWVBFOjANClgt TUlDUk9TT0ZULURPTk9URk9SV0FSRE1FRVRJTkc6RkFMU0UNClgtTUlDUk9TT0ZULURJU0FMTE9X LUNPVU5URVI6RkFMU0UNCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== --_002_BYAPR11MB38142E3CA85751BFD7CB8A53BFD70BYAPR11MB3814namp_-- From nobody Thu Aug 8 08:47:18 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195C21201D7; Thu, 8 Aug 2019 08:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 gjuEayODWZU8; Thu, 8 Aug 2019 08:47:14 -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 452DF12019D; Thu, 8 Aug 2019 08:47:14 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 648103818F; Thu, 8 Aug 2019 11:46:34 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 96014CC; Thu, 8 Aug 2019 11:47:12 -0400 (EDT) From: Michael Richardson To: "Randy Armstrong \(OPC\)" , "iot-onboarding\@ietf.org" , "anima\@ietf.org" In-Reply-To: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 15:47:16 -0000 --=-=-= Content-Type: text/plain Randy Armstrong (OPC) wrote: >> Thats what i referred to in my prior email: We would need to understand how to most easily duplicate the mutual authentication with certificates during TLS connection setup with OPC TCP UA messages.: > OPC UA CP requires mutual authentication with Certificates bound to the > application rather than the machine. It provides everything that you > get from TLS. Based upon my reading of the diagram, it is not obvious that it provides PFS, but I don't think PFS is particularly important for BRSKI. It seems to support client certificates and server certificates, and that's enough. We need an equivalent to tls-unique in order to properly bind the EST channel to the UA CP SecureChannel, but that's all I think. > So when the Pledge Device connects to the Registrar or the Certificate > Manager using UA the Device proves it has possession of the Device > private key. > That said, the KeyPair used for communication does not need to be the > same as the KeyPair used to authenticate. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1MRAAACgkQgItw+93Q 3WUVRggAikZ8EgU7TOH5ssmWvdVtcWokXLlysGJBY98bEKlTPGbOT0EhAhI1mgjn dpThgoX66Cc8XO88u0zn0o8efiey0hwsYrVi9rT7ku4K7iBAJv79lfFUKkaGxOh+ fDsXvfn74GOtsH9QLCNogHVeKUkdeGej/HohWz/OFCeR0bmc3/OpxEiZCFPzIvY7 Jl7iZH5Ai2aVXuYdKm++bvEYApBqRmf+7Qhqro57LfI5Yb5oDXqc1fFDT2FwmL2w K2Ej7WvoWNORTe6x67X+NxKu+ELQ8KSE1+Wk5UUnCr0UepRPx0EgotS2P43KV/67 9N167T54MalxqJmoj/DnSwcjK14MdQ== =jdHK -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 8 09:06:15 2019 Return-Path: <0100016c71fac426-ec2033bc-fe7d-4540-8ec4-0a2812b818ac-000000@amazonses.watsen.net> X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE531201E3; Thu, 8 Aug 2019 09:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFs5TbdAYFgx; Thu, 8 Aug 2019 09:06:01 -0700 (PDT) Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6C57120203; Thu, 8 Aug 2019 09:05:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1565280355; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=Wt+sYj3pnuZch9lEzOBp14s7/KqLK0H39/NSuak8aZk=; b=ZkKQjgQdI++MjntMk5C95Y9OcagdTggfd+ud/XMia0dC7PBbuCNHlYj+pxaXqlXE JOn1qpALwphKqCVWcwNXwzJsbSm9SGae8SEXS78+er6BpnPRrE7Y3COu8zAQ63d9LCE DMutJfgGHXkdP8L9HTRwyTLA784exyNSkddDFwr4= From: Kent Watsen Message-ID: <0100016c71fac426-ec2033bc-fe7d-4540-8ec4-0a2812b818ac-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_08A9911B-5DA5-49F6-9908-84BBF4ABE67C" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 8 Aug 2019 16:05:55 +0000 In-Reply-To: <3508.1565212944@localhost> Cc: "Owen Friel (ofriel)" , "iot-onboarding@ietf.org" , Rifaat Shekh-Yusef , "anima@ietf.org" To: Michael Richardson References: <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@email.amazonses.com> <3508.1565212944@localhost> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.08.08-54.240.8.83 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 16:06:07 -0000 --Apple-Mail=_08A9911B-5DA5-49F6-9908-84BBF4ABE67C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Michael, >> Skimming quickly, I see now the direction to go to a cloud registrar = to >> be redirected to a local registrar. I feel compelled to point out = that >> this is exactly what SZTP (RFC 8572) does, or at least, supports. >> Actually, as a more general statement, it was originally said that = the >> two WG's approaches were different, but they are now becoming more = and >> more alike. Well, since SZTP is published already, it's more like = the >> ANIMA approach is becoming more like SZTP, albeit seemingly with more >> complexity. >=20 > SZTP does not directly result in the same mutually authenticated TLS = (EST) > connection to a Registrar that BRSKI does. This was not an explicit = SZTP goal. It's true that EST isn't used, but there is a mutually-authenticated TLS = connection to the SZTP bootstrap server, which is effectively the same = as BRSKI's Registrar. =20 > What it could do though, is to provide a source of (secure) bootstrap > configuration in which such a connection could be initiated. In my = mind, > I see a fragment of signed JUNOS, IOS (CISCO, not Apple), etc. CLI > configuration that initiates the connection. Such a thing would not be > standardized. > But, I would think that this is exactly the kind of thing that could > be encoded in YANG. Indeed, this what RFC 8572 describes (in section 5.6 and also in C.3, = item #3) and the primary motivation behind = https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server = = and https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server = . > My understanding of = https://tools.ietf.org/html/draft-ietf-netconf-keystore > is that it would provided for Registrar initiated (PUSH) updating of = device > certificates, but would not provide a way for a device to initiate = (PULL) to > a securely identified EST server. Sounds correct, but clarifying: 1) the current keystore model is all about enabling a controller/NMS = application to configure/set/push keys and associated end-entity = certificates to a device. 2) there is a suggestion that the keystore model could/should be = extended to support ACME (or similar), in which case one might claim = that the device had "pulled" an end-entity certificate from a "securely = identified server" (dropping the "EST" part). 3) the truststore model (draft-ietf-netconf-trust-anchors) can be used = by a controller/NMS application to configure/set/push trust-anchor certs = used, e.g., to verify a remote server's end-entity certificate. Cheers, Kent --Apple-Mail=_08A9911B-5DA5-49F6-9908-84BBF4ABE67C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Michael,


Skimming quickly, I see = now the direction to go to a cloud registrar to
be = redirected to a local registrar.  I feel compelled to point out = that
this is exactly what SZTP (RFC 8572) does, or at = least, supports.
Actually, as a more general statement, it = was originally said that the
two WG's approaches were = different, but they are now becoming more and
more alike. =  Well, since SZTP is published already, it's more like the
ANIMA approach is becoming more like SZTP, albeit seemingly = with more
complexity.

SZTP does not directly result in the same mutually = authenticated TLS (EST)
connection to a Registrar that = BRSKI does.  This was not an explicit SZTP goal.

It's = true that EST isn't used, but there is a mutually-authenticated TLS = connection to the SZTP bootstrap server, which is effectively the same = as BRSKI's Registrar.   


What it could do though, is to provide a source of (secure) = bootstrap
configuration in which such a connection could = be initiated.  In my mind,
I see a fragment of signed = JUNOS, IOS (CISCO, not Apple), etc. CLI
configuration that = initiates the connection. Such a thing would not be
standardized.
But, I would think that this is = exactly the kind of thing that could
be encoded in = YANG.

Indeed, this what RFC 8572 describes (in section = 5.6 and also in C.3, item #3) and the primary motivation behind https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-= server and https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-s= erver.



My understanding of https://tools.ietf.org/html/draft-ietf-netconf-keystore
is that it would provided for Registrar initiated (PUSH) = updating of device
certificates, but would not provide a = way for a device to initiate (PULL) to
a securely = identified EST server.

Sounds correct, but clarifying:

1) the current keystore model is all about = enabling a controller/NMS application to configure/set/push keys and = associated end-entity certificates to a device.

2) there is a suggestion that the keystore model = could/should be extended to support ACME (or similar), in which case one = might claim that the device had "pulled" an end-entity certificate from = a "securely identified server" (dropping the "EST" part).

3) the truststore model = (draft-ietf-netconf-trust-anchors) can be used by a controller/NMS = application to configure/set/push trust-anchor certs used, e.g., to = verify a remote server's end-entity certificate.


Cheers,
Kent

= --Apple-Mail=_08A9911B-5DA5-49F6-9908-84BBF4ABE67C-- From nobody Thu Aug 8 09:54:44 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9E6120271; Thu, 8 Aug 2019 09:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=opcfoundation.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 HqIrt-ymqjAs; Thu, 8 Aug 2019 09:54:12 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780055.outbound.protection.outlook.com [40.107.78.55]) (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 5F9EC120254; Thu, 8 Aug 2019 09:54:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CyeJf9za4RyZ+PVXCupy7TXyMOhKKwmVPGhyiX2LZUQi7begU2RCmbhj8jfgOjxCB3b+nRLzfmTLYnhniVfFtkNLnnVJqJI5Tt6JLRlSVUqAzee9PDU2GefzS8y430DaorgWFREMRMlPf7nnECF71NJXqwHaU13FeBXOPrF0ZchX00U0SN9WntIQHVZBXbcROP1eKCBPNYrTtjtOcIvWPZJ3DJADMVjwCZ+m/OVHMQuaoEvrvkrKayDo0Y4wQILD8OkfEQyZSbz7p/bw+gtL8OIDdBzc9knJEUo3PLN6c/9+mr/FsJNLVTv43uR1HALIfOfmvwl/AkdSpETqOMapAw== 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=IdyFi8h48TRfo07z+S0UjJCH9sNYvggziaYwvKuW7qY=; b=g7EmWu3td9o9dDZ5qKjFwPr7aN2NKsu5D3uxHMnX1TrX6X+M71M4mBu6FTI4LcOTRAvMBnhiabxGBDbcExwLaZarGN3UlcDbGHhYi2yWClFrz+R49FWbnynY44ncD7yZejIWiQwrCvQiu0hbk1MPwVu7J78LBTouOjNwYjDpGnxw0Vn3zS2lPkmGEWCbxnMuznI+IftAOr+YUehCBYOu5jKsbjvLb7L+s37jctZWJvNe0Q16Zbew2Xaoo4En7eZoqJKcE4kbN/XZUWeGv2iVorsKt3l0dlL2HVTdUvoQ9KhbDrqCUH0PJgtfQ0pE7uFb+7ZuuGKX2W8wqXReHQ+fJQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=opcfoundation.org;dmarc=pass action=none header.from=opcfoundation.org;dkim=pass header.d=opcfoundation.org;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opcfoundation.onmicrosoft.com; s=selector1-opcfoundation-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IdyFi8h48TRfo07z+S0UjJCH9sNYvggziaYwvKuW7qY=; b=gbOV7GrU27SM4Amcnuf1FMPVUoLJpPZjRGIsoJjhg7UCbwJDSXkftCQeNpDjZTTLBYmyN8qu3a0yG/uc5knJ0PwR1Ns+L5nnbKwd/jo2cgpLfIO+w/AkyN7TA+49d4jCGGHl4GAFqxP7sgo31h/Bmo36Xtf/Kwsh7Pl/1gft2Rs= Received: from BYAPR08MB4903.namprd08.prod.outlook.com (20.176.255.96) by BYAPR08MB4680.namprd08.prod.outlook.com (52.135.234.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.15; Thu, 8 Aug 2019 16:54:11 +0000 Received: from BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53]) by BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53%4]) with mapi id 15.20.2157.015; Thu, 8 Aug 2019 16:54:11 +0000 From: "Randy Armstrong (OPC)" To: Michael Richardson , "iot-onboarding@ietf.org" , "anima@ietf.org" Thread-Topic: [Iot-onboarding] OPC and BRSKI Thread-Index: AdVMZzs5EDHMP+c/QWCVcWuK34MU/QAGrJ8AAADfarAABKcngAAmKcyAAAUDvQAADyfMUAAfy3oAAAGXgVA= Date: Thu, 8 Aug 2019 16:54:11 +0000 Message-ID: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> <4671.1565279232@localhost> In-Reply-To: <4671.1565279232@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=randy.armstrong@opcfoundation.org; x-originating-ip: [24.80.80.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f113d9f6-cbe8-4622-16ed-08d71c210970 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR08MB4680; x-ms-traffictypediagnostic: BYAPR08MB4680: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(136003)(346002)(39840400004)(366004)(13464003)(189003)(199004)(2906002)(86362001)(508600001)(76116006)(6116002)(966005)(66446008)(33656002)(66476007)(446003)(66556008)(5660300002)(11346002)(64756008)(81166006)(229853002)(71200400001)(476003)(52536014)(7736002)(8936002)(256004)(486006)(53936002)(110136005)(26005)(6436002)(81156014)(8676002)(2501003)(305945005)(316002)(6246003)(74316002)(71190400001)(55016002)(7696005)(186003)(6306002)(6506007)(14444005)(99286004)(53546011)(66066001)(25786009)(76176011)(14454004)(3846002)(102836004)(9686003)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR08MB4680; H:BYAPR08MB4903.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: opcfoundation.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: TLCzIVP1SELp9d6eqAX5vftD6xTv8mY3su5vyR+x5a/0YXQZy64x7lmHZ7wX3LK6MyVMQg7XJZcs2FoL6xTcaq2fYwVh/iYnwam3mYGK7g+gzVUGsQQ5WJdtUkLRUU4Oepcs6dfj5jW2HHk0a1/mfdQIrLo3FvuvQrehb3KYSuR8yMpK8JELaI6hWI0bwM6heElKXeDy+lOKmBon0jKAUHLjOhcsCYa8THHRcBHMFrWj+jRmo1rn190hfkNs4RgV4vPgloEPlAuZNhGB98bVyRJb4wtQCQjDbUaZdeq8MSVmOMCLaT2WQ6vX+CWwtzU6n0ONVk4x4XtSwfZY9XbtBv35/+L3rmNI5RsXO16EFauGgHfniCIthLHfrYwdu2m/JLwGWDbLnLqEjkwOIG7xoA8JAK+E5XyY1kORwvE55Iw= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: opcfoundation.org X-MS-Exchange-CrossTenant-Network-Message-Id: f113d9f6-cbe8-4622-16ed-08d71c210970 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2019 16:54:11.2764 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2d8ef4e4-d41c-489c-8004-bb99304b60fe X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +iPcHQb8Ox/JfRqlgGqUa9xhAxSgLsKq+WEV3L3j2tk54MCpC6Qy7iJ0660MDeU3pW3i0VbEZVfbux+Z3P+eDknMwvtZto7Kh8xxhLxiFvOccgu30X5n4aU1CNKBZ0v0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4680 Archived-At: Subject: Re: [Anima] [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 16:54:20 -0000 Hi Michael, OPC UA uses SecurityProfiles to specify the exact algorithms. The based RSA= profiles do not have PFS but the ECC profiles do. We expect the ECC profiles (not released yet) to be most interesting to low= end device makers. https://opcfoundation.github.io/UA-TypeRepository/Core/docs/Part7/6.6.164/ It is not clear which tls-unique attribute you are interested in. Do you need a unique identifier for the negotiated keys? If so the SecureChannelId + TokenId would provide that. https://opcfoundation.github.io/UA-TypeRepository/Core/docs/Part6/6.7.2/#Ta= ble43 Regards, Randy -----Original Message----- From: Michael Richardson =20 Sent: August 8, 2019 8:47 AM To: Randy Armstrong (OPC) ; iot-onboardi= ng@ietf.org; anima@ietf.org Subject: Re: [Iot-onboarding] OPC and BRSKI Randy Armstrong (OPC) wrote: >> Thats what i referred to in my prior email: We would need to underst= and how to most easily duplicate the mutual authentication with certificate= s during TLS connection setup with OPC TCP UA messages.: > OPC UA CP requires mutual authentication with Certificates bound to t= he > application rather than the machine. It provides everything that you > get from TLS. Based upon my reading of the diagram, it is not obvious that it provides PF= S, but I don't think PFS is particularly important for BRSKI. It seems to = support client certificates and server certificates, and that's enough. We need an equivalent to tls-unique in order to properly bind the EST chann= el to the UA CP SecureChannel, but that's all I think. > So when the Pledge Device connects to the Registrar or the Certificat= e > Manager using UA the Device proves it has possession of the Device > private key. > That said, the KeyPair used for communication does not need to be the > same as the KeyPair used to authenticate. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Thu Aug 8 10:02:11 2019 Return-Path: <0100016c722e3073-8d7451d2-d6cd-41af-bf6a-98734e3b4fbd-000000@amazonses.watsen.net> X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0DAE12006D; Thu, 8 Aug 2019 10:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8CZO7LyHpuh; Thu, 8 Aug 2019 10:02:07 -0700 (PDT) Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 020C61200C4; Thu, 8 Aug 2019 10:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1565283725; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=Oue/clS/LTRKf5aXgzvLBnnLpYHRAIHLhgwt2MDJ5vQ=; b=TwFSCvp4tlZKyepdLobZY6ll+4Fy4OlyT+YC/Ad9Nw2lbbfADLQMURlzHOj9op8Q ljRn3hObwW/YEMpCdgqQzttJpbf7TkckRpSeleA8D/VJq1apEIa72rPHhHjE7h7/Xil h2nGsNnj+chRsG44q/zHLz56Czefggwvu9H9ga68= From: Kent Watsen Message-ID: <0100016c722e3073-8d7451d2-d6cd-41af-bf6a-98734e3b4fbd-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F008E744-8ACA-4B87-85ED-C14379605C01" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 8 Aug 2019 17:02:05 +0000 In-Reply-To: <4129.1565213078@localhost> Cc: "iot-onboarding@ietf.org" , "anima@ietf.org" , Toerless Eckert , Rifaat Shekh-Yusef , "Owen Friel (ofriel)" To: Michael Richardson References: <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@email.amazonses.com> <20190806221242.4j7eprxeklup5c3m@faui48f.informatik.uni-erlangen.de> <0100016c6968e7a2-4acac184-768f-4971-8b4f-459165f0aa4f-000000@email.amazonses.com> <4129.1565213078@localhost> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.08.08-54.240.8.96 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 17:02:10 -0000 --Apple-Mail=_F008E744-8ACA-4B87-85ED-C14379605C01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > Kent Watsen wrote: >> True, but it seems that getting a domain certificate and getting an >> initial configuration are at least two distinct steps in ANIMA, = whereas >> they're rolled into one step with SZTP. >=20 > I'm missing where SZTP gets a domain certificate in a standard way. >=20 > I totally see how it gets initial configuration though. > I also see how that initial configuration can be caused to do an = enrollment, > by leveraging some specific, vendor-specific, configuration command. I think your understanding is complete. =20 There isn't a single "domain certificate". Instead, there are: 1) certificates pledges use during bootstrap process, which may be: a) = used to authenticate bootstrap servers. These certificates are learned = via SZTP "redirect information" or b) used to authenticate = owner-certificates. These certificates are learned via the ownership = voucher (RFC 8366). 2) certificates pledges use to authenticate subsequent (e.g., = management) connections. These certificates may be configured, e.g., = via the keystore and truststore models over NETCONF, RESTCONF, or COAP. So, rather than a single certificate or a single protocol, there's a = collection of each, yet all defined (once all is published) via = standards (not vendor-specific, configuration commands). Makes sense? Kent --Apple-Mail=_F008E744-8ACA-4B87-85ED-C14379605C01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Kent = Watsen <kent+ietf@watsen.net> wrote:
True, but it seems that = getting a domain certificate and getting an
initial = configuration are at least two distinct steps in ANIMA, whereas
they're rolled into one step with SZTP.

I'm missing where SZTP gets a = domain certificate in a standard way.

I = totally see how it gets initial configuration though.
I = also see how that initial configuration can be caused to do an = enrollment,
by leveraging some specific, vendor-specific, = configuration command.

I think your understanding is complete. =  

There = isn't a single "domain certificate".   Instead, there = are:

1) = certificates pledges use during bootstrap process, which may be: a) used = to authenticate bootstrap servers.  These certificates are learned = via SZTP "redirect information" or b) used to authenticate = owner-certificates.  These certificates are learned via = the ownership voucher (RFC 8366).

2) certificates pledges use to = authenticate subsequent (e.g., management) connections.  These = certificates may be configured, e.g., via the keystore and truststore = models over NETCONF, RESTCONF, or COAP.

So, rather than a single certificate or = a single protocol, there's a collection of each, yet all defined (once = all is published) via standards (not vendor-specific, configuration = commands).

Makes= sense?

Kent

= --Apple-Mail=_F008E744-8ACA-4B87-85ED-C14379605C01-- From nobody Thu Aug 8 11:22:09 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA801200E7; Thu, 8 Aug 2019 11:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, RCVD_IN_DNSWL_MED=-2.3, 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 xwGoUgkfa2WO; Thu, 8 Aug 2019 11:21:58 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFEFD1200C5; Thu, 8 Aug 2019 11:21:57 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6D1CC54802C; Thu, 8 Aug 2019 20:21:52 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5B9FC440041; Thu, 8 Aug 2019 20:21:52 +0200 (CEST) Date: Thu, 8 Aug 2019 20:21:52 +0200 From: Toerless Eckert To: "Eliot Lear (elear)" Cc: "iot-onboarding@ietf.org" , "anima@ietf.org" Message-ID: <20190808182152.csrqbf4tv77kwl3g@faui48f.informatik.uni-erlangen.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Hold for IoT Onboarding Virtual Meeting X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 18:22:01 -0000 THanks, Eliot Now i am trying to figure out the non-mentioned meeting time by clicking on the Webex URL: > IoT Onboarding Meeting > Hosted by Eliot Lear > 5:00 pm - 6:00 pm Thursday, Aug 29 2019 (UTC+01:00) Amsterdam, Berlin, > Bern, Rome, Stockholm, Vienna And webex continues to confuse me, because UTC+1 is NOT the local time on Aug 29 in Amsterdam/Berlin because of DST, so is the meeting at 5 PM UTC+1 or at 5 PM local time in Amsterdam/Berlin (UTC+2) ? Best to wait for EU to get rid of DST to fix this webex bug *sigh*. Cheers Toerless On Thu, Aug 08, 2019 at 04:31:30AM +0000, Eliot Lear (elear) wrote: > Please hold this time for the onboarding discussion (I'm on vacation and am sending this a bit early). This is an IoT Onboarding virtual meeting. > > Tentative Agenda: > > - OPC UA use case > - updates on drafts > - AOB > > > > > Meeting Information > > Meeting link: > https://cisco.webex.com/cisco/j.php?MTID=m16f8e0d12f6d12c3c37984c73f20efb8 > Meeting number: > 207 046 128 > Password: > c3wvus3x (23988739 from phones) > Host key: > 735404 > > More ways to join > > Join by video system > Dial 207046128@cisco.webex.com > You can also dial 173.243.2.68 and enter your meeting number. > > Join by phone > +1-866-432-9903 Call-in toll-free number (US/Canada) > +1-408-525-6800 Call-in number (US/Canada) > Access code: 207 046 128 > > Global call-in numbers | Toll-free calling restrictions > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima From nobody Thu Aug 8 11:39:00 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99755120220; Thu, 8 Aug 2019 11:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=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 lJ7z2oO_szYB; Thu, 8 Aug 2019 11:38:50 -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 1A1CC12023C; Thu, 8 Aug 2019 11:38:38 -0700 (PDT) Received: from [192.168.217.120] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (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 464HFS4HvmzyxN; Thu, 8 Aug 2019 20:38:36 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Carsten Bormann In-Reply-To: <20190808182152.csrqbf4tv77kwl3g@faui48f.informatik.uni-erlangen.de> Date: Thu, 8 Aug 2019 20:38:35 +0200 Cc: "Eliot Lear (elear)" , "iot-onboarding@ietf.org" , "anima@ietf.org" X-Mao-Original-Outgoing-Id: 586982314.400864-2fff8729ac4ad2749d1f1f1416f7c6b2 Content-Transfer-Encoding: quoted-printable Message-Id: <832011CC-F194-49D8-B78D-672C82B42006@tzi.org> References: <20190808182152.csrqbf4tv77kwl3g@faui48f.informatik.uni-erlangen.de> To: Toerless Eckert X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Anima] Hold for IoT Onboarding Virtual Meeting X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 18:38:53 -0000 On Aug 8, 2019, at 20:21, Toerless Eckert wrote: >=20 >> 5:00 pm - 6:00 pm Thursday, Aug 29 2019 (UTC+01:00) Amsterdam, = Berlin, >> Bern, Rome, Stockholm, Vienna >=20 > And webex continues to confuse me, Webex is just following the great tradition of certain other widely used = calendaring tools: foist the confusion of the people that designed it on = all of its users. > because UTC+1 is NOT the local time > on Aug 29 in Amsterdam/Berlin because of DST, The =E2=80=9CUTC+1=E2=80=9D is just a lame way of saying what the time = in Amsterdam/Berlin normally is, for people who don=E2=80=99t know where = those weird settlements might be. > so is the meeting at > 5 PM UTC+1 or at 5 PM local time in Amsterdam/Berlin (UTC+2) ? Webex is trying to tell you the meeting is at 17:00 (5 pm for people who = get their time from sundials) at Amsterdam/Berlin local time, which = happens to be UTC+0200 on that date. You can always look up whether DST = applies on timeanddate.com; this is none of Webex=E2=80=99s business. = Webex only tells you where Amsterdam/Berlin approximately are, because = you are not expected to know that. > Best to wait for EU to get rid of DST to fix this webex bug *sigh*. Actually, that is probably true. But if some countries go for permanent = DST, Webex will then always show the wrong time and not just half the = year. The real fix is to announce all meetings in Reykjavik time (UTC+0000 the = whole year). Log in at ietf.webex.com, use the menu to go to = preferences, and set the time zone to Monrovia/Reykjavik. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Aug 8 12:21:00 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338F8120236; Thu, 8 Aug 2019 12:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, RCVD_IN_DNSWL_MED=-2.3, 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 GSrsvtiBBE1r; Thu, 8 Aug 2019 12:20:49 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83933120167; Thu, 8 Aug 2019 12:20:49 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0768C548342; Thu, 8 Aug 2019 21:20:45 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id E81C8440041; Thu, 8 Aug 2019 21:20:44 +0200 (CEST) Date: Thu, 8 Aug 2019 21:20:44 +0200 From: Toerless Eckert To: Carsten Bormann Cc: "Eliot Lear (elear)" , "iot-onboarding@ietf.org" , "anima@ietf.org" Message-ID: <20190808192044.env74qlyz7azzpcp@faui48f.informatik.uni-erlangen.de> References: <20190808182152.csrqbf4tv77kwl3g@faui48f.informatik.uni-erlangen.de> <832011CC-F194-49D8-B78D-672C82B42006@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <832011CC-F194-49D8-B78D-672C82B42006@tzi.org> User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] Hold for IoT Onboarding Virtual Meeting X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 19:20:51 -0000 Sorry, but i continue to think its not just lame, its wrong. Either leave UTC+x away, or make it correct for the given date (UTC+2), or write something like CETDST. On Thu, Aug 08, 2019 at 08:38:35PM +0200, Carsten Bormann wrote: > On Aug 8, 2019, at 20:21, Toerless Eckert wrote: > > > >> 5:00 pm - 6:00 pm Thursday, Aug 29 2019 (UTC+01:00) Amsterdam, Berlin, > >> Bern, Rome, Stockholm, Vienna > > > > And webex continues to confuse me, > > Webex is just following the great tradition of certain other widely used calendaring tools: foist the confusion of the people that designed it on all of its users. > > > because UTC+1 is NOT the local time > > on Aug 29 in Amsterdam/Berlin because of DST, > > The ???UTC+1??? is just a lame way of saying what the time in Amsterdam/Berlin normally is, for people who don???t know where those weird settlements might be. > > > so is the meeting at > > 5 PM UTC+1 or at 5 PM local time in Amsterdam/Berlin (UTC+2) ? > > Webex is trying to tell you the meeting is at 17:00 (5 pm for people who get their time from sundials) at Amsterdam/Berlin local time, which happens to be UTC+0200 on that date. You can always look up whether DST applies on timeanddate.com; this is none of Webex???s business. Webex only tells you where Amsterdam/Berlin approximately are, because you are not expected to know that. > > > Best to wait for EU to get rid of DST to fix this webex bug *sigh*. > > Actually, that is probably true. But if some countries go for permanent DST, Webex will then always show the wrong time and not just half the year. > > The real fix is to announce all meetings in Reykjavik time (UTC+0000 the whole year). Log in at ietf.webex.com, use the menu to go to preferences, and set the time zone to Monrovia/Reykjavik. > > Grüße, Carsten -- --- tte@cs.fau.de From nobody Thu Aug 8 13:50:49 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C15120234; Thu, 8 Aug 2019 13:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 vCtfvIZD06By; Thu, 8 Aug 2019 13:50:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C623C120183; Thu, 8 Aug 2019 13:50:45 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 6BED73818F; Thu, 8 Aug 2019 16:50:05 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 00E5FCC; Thu, 8 Aug 2019 16:50:43 -0400 (EDT) From: Michael Richardson To: Kent Watsen , "iot-onboarding\@ietf.org" , "anima\@ietf.org" In-Reply-To: <0100016c71fac426-ec2033bc-fe7d-4540-8ec4-0a2812b818ac-000000@email.amazonses.com> References: <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@email.amazonses.com> <3508.1565212944@localhost> <0100016c71fac426-ec2033bc-fe7d-4540-8ec4-0a2812b818ac-000000@email.amazonses.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 20:50:49 -0000 --=-=-= Content-Type: text/plain Kent Watsen wrote: >>> Skimming quickly, I see now the direction to go to a cloud registrar to >>> be redirected to a local registrar. I feel compelled to point out that >>> this is exactly what SZTP (RFC 8572) does, or at least, supports. >>> Actually, as a more general statement, it was originally said that the >>> two WG's approaches were different, but they are now becoming more and >>> more alike. Well, since SZTP is published already, it's more like the >>> ANIMA approach is becoming more like SZTP, albeit seemingly with more >>> complexity. >> >> SZTP does not directly result in the same mutually authenticated TLS (EST) >> connection to a Registrar that BRSKI does. This was not an explicit SZTP goal. > It's true that EST isn't used, but there is a mutually-authenticated > TLS connection to the SZTP bootstrap server, which is effectively the > same as BRSKI's Registrar. It's not clear to me that this always occurs in the USB or DHCP cases :-) >> What it could do though, is to provide a source of (secure) bootstrap >> configuration in which such a connection could be initiated. In my mind, >> I see a fragment of signed JUNOS, IOS (CISCO, not Apple), etc. CLI >> configuration that initiates the connection. Such a thing would not be >> standardized. >> But, I would think that this is exactly the kind of thing that could >> be encoded in YANG. > Indeed, this what RFC 8572 describes (in section 5.6 and also in C.3, > item #3) and the primary motivation behind > https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server > > and > https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server > . Got it. >> My understanding of https://tools.ietf.org/html/draft-ietf-netconf-keystore >> is that it would provided for Registrar initiated (PUSH) updating of device >> certificates, but would not provide a way for a device to initiate (PULL) to >> a securely identified EST server. > Sounds correct, but clarifying: > 1) the current keystore model is all about enabling a controller/NMS > application to configure/set/push keys and associated end-entity > certificates to a device. > 2) there is a suggestion that the keystore model could/should be > extended to support ACME (or similar), in which case one might claim > that the device had "pulled" an end-entity certificate from a "securely > identified server" (dropping the "EST" part). > 3) the truststore model (draft-ietf-netconf-trust-anchors) can be used > by a controller/NMS application to configure/set/push trust-anchor > certs used, e.g., to verify a remote server's end-entity certificate. But, more interestingly, it can be used to update the trust anchors, to enable a resale/transfer of ownership! -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1MiyMACgkQgItw+93Q 3WXMGwf/TE8XTldSDlxmCUhkmrFqZMm8wdqQ5IcrMOT2B9DKvhka/XTfnpHelj8Z Oq2n1HVn4taVZ+161SEV+sVSW88HF6tZL3CzBJrHktMocn55AsCGP6hqUqNi63y3 kRwndqDxP6BFZ7ScNlN+1kxp5g+sIBGYdTfJD0T+nuvYWY3+g5b9sg1pPe0bxJGh c5xvZZnoBe/2H82ETuvM/wY7E66PHAoPx3OzF1qkoLD+jH/YpM8abpFNB5vRe14m fJwAfMJyMjh+mYr1VXZ59EDPo9tp4La7iKF/dcMYELtFKYtAmflVtTwbl49tYfJU d9F9umNe6X14t7uzF27PfXK+P0Oi+A== =GNnU -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 8 14:26:43 2019 Return-Path: <0100016c73206135-bb6429cc-539e-4166-b54f-552e79c9f221-000000@amazonses.watsen.net> X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A7E1200E5; Thu, 8 Aug 2019 14:26:41 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIud-0zDF7Ik; Thu, 8 Aug 2019 14:26:39 -0700 (PDT) Received: from a8-32.smtp-out.amazonses.com (a8-32.smtp-out.amazonses.com [54.240.8.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2729C120098; Thu, 8 Aug 2019 14:26:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1565299597; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=8AumYJScPhJXlNl/sxKoNYFugakiBCbGvPZQ0p3T1tw=; b=hmZAb1rZeIustsreINA1OzU7d2lOCcCiEsgWrC3BB01g/BUhH6zN9f73xdT05Rs5 KEplfQV0ryOgGFOubOY4N5q4OvYWiZWJRqRBdZR8fj9MYUp0lfO7WSz2GKWvg7xzO4R KEkuMaYzf6KxqdZLQNn/4dQwZp8xU3wrIiTK/E1Q= From: Kent Watsen Message-ID: <0100016c73206135-bb6429cc-539e-4166-b54f-552e79c9f221-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_0F4F2115-A0C1-4F37-AF0B-416B2F6318F9" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 8 Aug 2019 21:26:37 +0000 In-Reply-To: <16648.1565297443@localhost> Cc: "iot-onboarding@ietf.org" , "anima@ietf.org" To: Michael Richardson References: <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@email.amazonses.com> <3508.1565212944@localhost> <0100016c71fac426-ec2033bc-fe7d-4540-8ec4-0a2812b818ac-000000@email.amazonses.com> <16648.1565297443@localhost> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.08.08-54.240.8.32 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 21:26:41 -0000 --Apple-Mail=_0F4F2115-A0C1-4F37-AF0B-416B2F6318F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >> It's true that EST isn't used, but there is a mutually-authenticated >> TLS connection to the SZTP bootstrap server, which is effectively the >> same as BRSKI's Registrar. >=20 > It's not clear to me that this always occurs in the USB or DHCP cases = :-) To your smiley-face, the ultimate USB use-case entails using no network = at all, so you're right that there is no mutually-authenticated TLS = connection then! For all other cases, it's actually possible that the bootstrapping event = may lead to a mutually-authenticated TLS connection. It entails the = device consuming "signed data", which means it needs also an "ownership = voucher" as well as an "owner certificate". [note: terms in "quotes" = are defined in RFC 8572] >> Sounds correct, but clarifying: >=20 >> 1) the current keystore model is all about enabling a controller/NMS >> application to configure/set/push keys and associated end-entity >> certificates to a device. >=20 >> 2) there is a suggestion that the keystore model could/should be >> extended to support ACME (or similar), in which case one might claim >> that the device had "pulled" an end-entity certificate from a = "securely >> identified server" (dropping the "EST" part). >=20 >> 3) the truststore model (draft-ietf-netconf-trust-anchors) can be = used >> by a controller/NMS application to configure/set/push trust-anchor >> certs used, e.g., to verify a remote server's end-entity certificate. >=20 > But, more interestingly, it can be used to update the trust anchors, = to > enable a resale/transfer of ownership! I think I see a smiley-face here too ;) But, seriously, no. It's expected that decommissioning will returned a = device back to its factory default state. No manufacturer will agree = that it is anything other than the state of the device when it was = manufactured. Anything other than that could be leveraged to mount an = attack. Change in ownership-assignment needs to occur through some = other means, of which there are many but, in the end, if the 2nd-owner = cares about the security (not just the convenience) of bootstrapping, = then they are strongly advised to purchase never before used equipment. Kent --Apple-Mail=_0F4F2115-A0C1-4F37-AF0B-416B2F6318F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

It's = true that EST isn't used, but there is a mutually-authenticated
TLS connection to the SZTP bootstrap server, which is = effectively the
same as BRSKI's Registrar.

It's not clear to me that this = always occurs in the USB or DHCP cases :-)

To= your smiley-face, the ultimate USB use-case entails using no network at = all, so you're right that there is no mutually-authenticated TLS = connection then!

For = all other cases, it's actually possible that the bootstrapping event may = lead to a mutually-authenticated TLS connection. =  It entails the device consuming "signed data", which = means it needs also an "ownership voucher" as well as an "owner = certificate".   [note: terms in "quotes" are defined in RFC = 8572]



Sounds correct, but = clarifying:

1) the current keystore model is all about = enabling a controller/NMS
application to = configure/set/push keys and associated end-entity
certificates to a device.

2) there is a suggestion = that the keystore model could/should be
extended to = support ACME (or similar), in which case one might claim
that the device had "pulled" an end-entity certificate from a = "securely
identified server" (dropping the "EST" part).

3) the truststore model (draft-ietf-netconf-trust-anchors) = can be used
by a controller/NMS application to = configure/set/push trust-anchor
certs used, e.g., to = verify a remote server's end-entity certificate.

But, more interestingly, it can = be used to update the trust anchors, to
enable a = resale/transfer of ownership!

I= think I see a smiley-face here too  ;)

But, seriously, no.  It's expected = that decommissioning will returned a device back to its factory default = state.  No manufacturer will agree that it is anything other than = the state of the device when it was manufactured.   Anything other = than that could be leveraged to mount an attack.  Change in = ownership-assignment needs to occur through some other means, of which = there are many but, in the end, if the 2nd-owner cares about the = security (not just the convenience) of bootstrapping, then they are = strongly advised to purchase never before used equipment.


Kent

= --Apple-Mail=_0F4F2115-A0C1-4F37-AF0B-416B2F6318F9-- From nobody Thu Aug 8 14:46:20 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 850AB120098; Thu, 8 Aug 2019 14:46:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156530077142.7566.15699683098565124331@ietfa.amsl.com> Date: Thu, 08 Aug 2019 14:46:11 -0700 Archived-At: Subject: [Anima] Autonomic Networking Integrated Model and Approach (anima) WG Virtual Meeting: 2019-08-29 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2019 21:46:12 -0000 The Autonomic Networking Integrated Model and Approach (anima) Working Group will hold a virtual interim meeting on 2019-08-29 from 17:00 to 19:00 Europe/Amsterdam. Agenda: Discuss onboarding for additional classes of devices ("IOT") - OPC UA use case - updates on drafts - AOB Information about remote participation: Password: c3wvus3x Phone: 23988739 URL: https://cisco.webex.com/cisco/j.php?MTID=m16f8e0d12f6d12c3c37984c73f20efb8 From nobody Fri Aug 9 08:16:37 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4921712016F; Fri, 9 Aug 2019 08:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 7bl0Tv25Ss_m; Fri, 9 Aug 2019 08:16:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F62120052; Fri, 9 Aug 2019 08:16:25 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6C62E3818F; Fri, 9 Aug 2019 11:15:44 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2C6D91027; Fri, 9 Aug 2019 11:16:24 -0400 (EDT) From: Michael Richardson To: Kent Watsen cc: "iot-onboarding\@ietf.org" , "anima\@ietf.org" In-Reply-To: <0100016c73206135-bb6429cc-539e-4166-b54f-552e79c9f221-000000@email.amazonses.com> References: <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@email.amazonses.com> <3508.1565212944@localhost> <0100016c71fac426-ec2033bc-fe7d-4540-8ec4-0a2812b818ac-000000@email.amazonses.com> <16648.1565297443@localhost> <0100016c73206135-bb6429cc-539e-4166-b54f-552e79c9f221-000000@email.amazonses.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 15:16:36 -0000 --=-=-= Content-Type: text/plain Kent Watsen wrote: >> But, more interestingly, it can be used to update the trust anchors, to >> enable a resale/transfer of ownership! > I think I see a smiley-face here too ;) Sadly, no. > But, seriously, no. It's expected that decommissioning will returned a > device back to its factory default state. No manufacturer will agree > that it is anything other than the state of the device when it was > manufactured. Anything other than that could be leveraged to mount an > attack. Change in ownership-assignment needs to occur through some > other means, of which there are many but, in the end, if the 2nd-owner > cares about the security (not just the convenience) of bootstrapping, > then they are strongly advised to purchase never before used > equipment. This is indeed the tussle the BRSKI document has been dealing with in its IESG review. If we can't change the trust anchors used to verify the voucher, then how can the device be onboarded after the MASA has gone away? I don't understand how RFC8572 slipped through the IESG without resolving this. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1NjkcACgkQgItw+93Q 3WVsDwf+L2rqxtiZqUeqSKWCbo8XmjSF3h+8q2TnM6chRae3E/IWsctCPIYjxUPf ZGLTXYUk024ffLFNH0ZHpcWZl9pFfOzLcYJvh4oSFZE+bAyMZ6SstcMYelG0ao+8 ijGWvPK0SJ4L98FmbnNs+JnhmAiLkypqDHpISUhtXbxfAW354MQVNKrzT6DpQFNh UAf6F2iFiKWljaG0jRPcWedQxuzON7jYRikh98xmWLbxNhHazmceS+MGWWDIF2Ug T0nMyYQWmMuDLSNmVwt0DVCnKMunpwcbEWMg1iMmoT4d3aXnovIIYrC6k9coKOsd Zmy5tUT1vvPiGjslDVDLlYh8zSTBvg== =8xJK -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 9 09:16:56 2019 Return-Path: <0100016c772b24b7-7ece8b90-1343-4579-9f11-73809b33755e-000000@amazonses.watsen.net> X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE96F120020; Fri, 9 Aug 2019 09:16:55 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyYirVQhc8jY; Fri, 9 Aug 2019 09:16:53 -0700 (PDT) Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872F4120019; Fri, 9 Aug 2019 09:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1565367412; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=JdRFJ7M+VfNKDYWQ2vzVEUwqWpmRvIaFBpnGBfVHcTM=; b=EwgY2LVPBoS27Zf8e6Ey6efQHubStQhnHFgqn5X9vC/Yo1IYtDuzKCzth//U23qq YsUDvXqlb0IYaS2YDXozAFyknb/8jvXRi21GkNu9p6Qyc9H7cqCAXMYqb9RBkrad3FN GzsyWkkpC9f792sixSqi8wA6yL/lBjQ7chEQNtjg= From: Kent Watsen Message-ID: <0100016c772b24b7-7ece8b90-1343-4579-9f11-73809b33755e-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6BEACBD8-C205-4145-9141-92C040E4514E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 9 Aug 2019 16:16:51 +0000 In-Reply-To: <18641.1565363784@localhost> Cc: "iot-onboarding@ietf.org" , "anima@ietf.org" To: Michael Richardson References: <0100016c6772e4e8-8ce5598b-2c2a-488e-b7c2-414d9003e46b-000000@email.amazonses.com> <3508.1565212944@localhost> <0100016c71fac426-ec2033bc-fe7d-4540-8ec4-0a2812b818ac-000000@email.amazonses.com> <16648.1565297443@localhost> <0100016c73206135-bb6429cc-539e-4166-b54f-552e79c9f221-000000@email.amazonses.com> <18641.1565363784@localhost> X-Mailer: Apple Mail (2.3445.104.11) X-SES-Outgoing: 2019.08.09-54.240.8.64 Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES Archived-At: Subject: Re: [Anima] [Iot-onboarding] Device Certificate Deployment Automation with ACME using BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 16:16:56 -0000 --Apple-Mail=_6BEACBD8-C205-4145-9141-92C040E4514E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Aug 9, 2019, at 11:16 AM, Michael Richardson = wrote: >=20 >=20 > Kent Watsen wrote: >>> But, more interestingly, it can be used to update the trust anchors, = to >>> enable a resale/transfer of ownership! >=20 >> But, seriously, no. It's expected that decommissioning will returned = a >> device back to its factory default state. No manufacturer will agree >> that it is anything other than the state of the device when it was >> manufactured. Anything other than that could be leveraged to mount = an >> attack. Change in ownership-assignment needs to occur through some >> other means, of which there are many but, in the end, if the = 2nd-owner >> cares about the security (not just the convenience) of bootstrapping, >> then they are strongly advised to purchase never before used >> equipment. >=20 > This is indeed the tussle the BRSKI document has been dealing with > in its IESG review. If we can't change the trust anchors used to = verify > the voucher, then how can the device be onboarded after the MASA > has gone away? Oh, wait, my prior response wasn't wholly accurate. The factory default state reflects zero remnants, but it doesn't = necessarily mean the same OS-version as the day the device left the = factory. Many devices don't have enough NV storage to keep the = original OS forever, not to mention that it would be rather silly as, = better, would be to keep what's considered the last known-good OS image = (which may not be the same thing). Many devices will effectively = overwrite the previous OS image ("don't touch the power button during = install!") and thus what happens when pressing the "reset to factory = default" button is a reflection of what "factory default" means to the = new OS image. The good news is that new OS images can contain new CA = certificates, for authenticating well-known services (e.g., MASA, OVIS, = etc.). What cannot change is the IDevID certificate (LDevIDs are = wiped). Of course, all this assumes the manufacturer is still around to release = OS updates, but this is simply part of the business decision that = customers need to consider when purchasing equipment. The probability = of a successful bootstrap shortly after fresh purchase directly from the = manufacturer is very high, but lowers over time as risks around = businesses going belly-up start to creep in. A device sitting on a = shelf for a decade, or devices bought on eBay, may not bootstrap without = an OS upgrade. None of the above reflects how to support change in ownership, though. = A device reset to factory default has no "owner", just some trust = anchors that can be used to verify an entity claiming to be its owner. = What backend sale-channel integration or customer-handoff protocol might = be used to support change in ownership is out of scope. > I don't understand how RFC8572 slipped through the IESG without = resolving this. Perhaps because BRSKI leads with ephemeral vouchers and hence the need = for online MASAs (with offline support tacked on the side), whereas SZTP = leads with optional use of vouchers but, when used, they're mostly = non-ephemeral and accessible at time or purchase (with ephemeral voucher = support tacked on the side). The shift in emphasis begs the question, = so they're asking it. Still, it seems more like a customer/business = issue than something IESG should worry about. Kent --Apple-Mail=_6BEACBD8-C205-4145-9141-92C040E4514E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Aug 9, 2019, at 11:16 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Kent Watsen <kent+ietf@watsen.net> wrote:
But, more = interestingly, it can be used to update the trust anchors, to
enable a resale/transfer of ownership!

But, seriously, no.  It's expected that = decommissioning will returned a
device back to its factory = default state.  No manufacturer will agree
that it is = anything other than the state of the device when it was
manufactured.   Anything other than that could be = leveraged to mount an
attack.  Change in = ownership-assignment needs to occur through some
other = means, of which there are many but, in the end, if the 2nd-owner
cares about the security (not just the convenience) of = bootstrapping,
then they are strongly advised to purchase = never before used
equipment.

This is indeed the tussle the BRSKI document has been dealing = with
in its IESG review.  If we can't change the = trust anchors used to verify
the voucher, then how can the = device be onboarded after the MASA
has gone away?

Oh, = wait, my prior response wasn't wholly accurate.

The factory default state reflects zero remnants, = but it doesn't necessarily mean the same OS-version as the day the = device left the factory.   Many devices don't have enough NV = storage to keep the original OS forever, not to mention that it would be = rather silly as, better, would be to keep what's considered the last = known-good OS image (which may not be the same thing).   Many = devices will effectively overwrite the previous OS image ("don't touch = the power button during install!") and thus what happens when pressing = the "reset to factory default" button is a reflection of what "factory = default" means to the new OS image.   The good news is that new OS = images can contain new CA certificates, for authenticating well-known = services (e.g., MASA, OVIS, etc.).  What cannot change is the = IDevID certificate (LDevIDs are wiped).

Of course, all this assumes the manufacturer is = still around to release OS updates, but this is simply part of the = business decision that customers need to consider when purchasing = equipment.   The probability of a successful bootstrap shortly = after fresh purchase directly from the manufacturer is very high, but = lowers over time as risks around businesses going belly-up start to = creep in.  A device sitting on a shelf for a decade, or devices = bought on eBay, may not bootstrap without an OS upgrade.

None of the above reflects how to support change = in ownership, though.   A device reset to factory default has no = "owner", just some trust anchors that can be used to verify an entity = claiming to be its owner.  What backend sale-channel integration or = customer-handoff protocol might be used to support change in ownership = is out of scope.



I don't understand how RFC8572 slipped = through the IESG without resolving this.

Perhaps= because BRSKI leads with ephemeral vouchers and hence the need for = online MASAs (with offline support tacked on the side), whereas SZTP = leads with optional use of vouchers but, when used, they're mostly = non-ephemeral and accessible at time or purchase (with ephemeral voucher = support tacked on the side).   The shift in emphasis begs the = question, so they're asking it.  Still, it seems more like a = customer/business issue than something IESG should worry = about.


Kent


= --Apple-Mail=_6BEACBD8-C205-4145-9141-92C040E4514E-- From nobody Fri Aug 9 11:15:54 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76BC12002F; Fri, 9 Aug 2019 11:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 oQyS88Lg0IMF; Fri, 9 Aug 2019 11:15:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A34B120019; Fri, 9 Aug 2019 11:15:50 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 1A68C3818F; Fri, 9 Aug 2019 14:15:09 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0B6141027; Fri, 9 Aug 2019 14:15:49 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] What does PKIX refer to: Re: Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 18:15:53 -0000 --=-=-= Content-Type: text/plain I hoping for some discussion about this comment that I previously responded to, but it probably got buried. > Section 2.3 > Pledge authentication and pledge voucher-request signing is via a > PKIX certificate installed during the manufacturing process. This is > (As noted elsewhere, "PKIX" may not be the best term here.) ... > (10) The term PKIX seems to be incorrectly used a few times; it refers > to the Internet PKI, and so things like a private PKI internal to a > manufacturer would probably not be best described as such. Such > private PKIs can of course still reuse the protocols and mechanisms > developed for PKIX, and it's accurate to describe them as such. I would never call the Internet PKI "PKIX". I'd call it WebPKI, or CAB. PKIX is the set of IETF specifications that made X509v3 useful. (I try never to use "X509", because the ITU left us with an unuseable mess, and I don't think they deserve any credit) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1NuFQACgkQgItw+93Q 3WVFfQgAgpZdsv1GYgmZRksxYN69+d5QXnoSLg1V5p8zSjxqQfg9zS/PVxdenEJL kBh49zKu2rYjUoM9QrwTyK+fX7+nXkMF0ySTps9lysA0K4ZFMKUiDFP5q1HzhOc6 8gYHv8ZsK9Z0pE/5YHZ2Z4KPVCSjy2NhzDzVD4TFmL9orBo0fEi8YKVaSckKC0NP UBLbV2NO7mfFP9RA3lK4qpa3CheqPbpUH/+mDHnuFgXTHLVaZuBgLNNs8M1ed8+m QaexE9rPGpgSFY4phS2b1G+VRCTYI5gnNTS8LT0+cCzwYidxWWFFuxnvY9xEKiA0 f2z+hqIIH5yATBfO14TBqZxiv1f41A== =up5i -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 9 11:24:57 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08A41200F1; Fri, 9 Aug 2019 11:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 mCd08T14CzSX; Fri, 9 Aug 2019 11:24:53 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95EB51200E6; Fri, 9 Aug 2019 11:24:53 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id A5D6B3818F; Fri, 9 Aug 2019 14:24:11 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9D2671027; Fri, 9 Aug 2019 14:24:51 -0400 (EDT) From: Michael Richardson to: Benjamin Kaduk , "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <27223.1565374549@localhost> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <27223.1565374549@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] What does PKIX refer to: Re: Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 18:24:56 -0000 --=-=-= Content-Type: text/plain Michael Richardson wrote: > I hoping for some discussion about this comment that I previously > responded to, but it probably got buried. Actually, you did respond on July 20, in an email that I thought to re-read after pushing send. In it you said: mcr> I would never call the Internet PKI "PKIX". mcr> I'd call it WebPKI, or CAB. mcr> PKIX is the set of IETF specifications that made X509v3 useful. mcr> (And why I try never to use "X509"...) mcr> mcr> I couldn't find a reference to private PKI, so maybe I mis-understand. doc> This document details protocols and messages to answer the above doc> questions. It uses a TLS connection and an PKIX (X.509v3) doc> certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer doc> points 1 and 2. It uses a new artifact called a "voucher" that the doc> [...] doc> Pledge authentication and pledge voucher-request signing is via a doc> PKIX certificate installed during the manufacturing process. This is bk> The comment about private PKI was me making an assumption; I could be bk> wrong. But I don't really expect all manufacturers that do this to have bk> their IDevID signing CA be part of the Internet PKI; I expect them to be bk> standalone CAs with the root baked into hardware and nothing else that bk> uses that root. Does that help clarify? It helps to clarify where you think I'm referring to the Internet PKI. I don't think of "PKIX" as referring to the Internet PKI/WebPKI as managed by the CAB-Forum. Yes, it will be a private CA 96% of the time. A 1988 era X509v3 certificate isn't good enough; it has to be the IETF PKIX WG profile of X509v3. 801.1AR mostly says that. If you feel that my use of PKIX here is too confusing, I will change it. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1NunMACgkQgItw+93Q 3WXQAQf/QeurJ1wCQkWs4b2zs5Rc1tN8xFe9sYqItSbC+p6BELuSh+30qfEOmSL3 qQcWN724Bk+Hx58OiFQeu9CK+6h8wuaS1E9i0mPFxX29sbb/5BNRzmJPvw5gAwKH xo2sQir1osmFfeIhO/LFOZ9sbveSVKocBFrdAG3d46FuHzgP0ooNbqhu1f4GyujR muJIGFvkyA+weLwsJ7go8WFkoFzuFxYjvxoI69iQ/ft8rzId+bvLWcPtTD4p9hY9 tOYuAOxHLCZLiS9EcZ+qG/VLkPb8jFW9Gg3UsvHghTKkXQFrqDidtmcQHbwvbecX RGpOxdM1qYZGB57Pp72AoMmmnKHLeA== =m/m7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 9 11:52:08 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65BA1201EC; Fri, 9 Aug 2019 11:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 6zP3HceUpvuM; Fri, 9 Aug 2019 11:51:58 -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 D40A01201D4; Fri, 9 Aug 2019 11:51:57 -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 x79IpiPo021088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 9 Aug 2019 14:51:48 -0400 Date: Fri, 9 Aug 2019 13:51:43 -0500 From: Benjamin Kaduk To: Michael Richardson Cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org Message-ID: <20190809185143.GS59807@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <27223.1565374549@localhost> <29229.1565375091@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <29229.1565375091@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] What does PKIX refer to: Re: Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 18:52:00 -0000 On Fri, Aug 09, 2019 at 02:24:51PM -0400, Michael Richardson wrote: > > Michael Richardson wrote: > > I hoping for some discussion about this comment that I previously > > responded to, but it probably got buried. > > Actually, you did respond on July 20, in an email that I thought to re-read > after pushing send. > > In it you said: > > mcr> I would never call the Internet PKI "PKIX". > mcr> I'd call it WebPKI, or CAB. > mcr> PKIX is the set of IETF specifications that made X509v3 useful. > mcr> (And why I try never to use "X509"...) > mcr> > mcr> I couldn't find a reference to private PKI, so maybe I mis-understand. > > doc> This document details protocols and messages to answer the above > doc> questions. It uses a TLS connection and an PKIX (X.509v3) > doc> certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer > doc> points 1 and 2. It uses a new artifact called a "voucher" that the > doc> [...] > doc> Pledge authentication and pledge voucher-request signing is via a > doc> PKIX certificate installed during the manufacturing process. This is > > bk> The comment about private PKI was me making an assumption; I could be > bk> wrong. But I don't really expect all manufacturers that do this to have > bk> their IDevID signing CA be part of the Internet PKI; I expect them to be > bk> standalone CAs with the root baked into hardware and nothing else that > bk> uses that root. Does that help clarify? > > It helps to clarify where you think I'm referring to the Internet PKI. > > I don't think of "PKIX" as referring to the Internet PKI/WebPKI as managed by > the CAB-Forum. Yes, it will be a private CA 96% of the time. > A 1988 era X509v3 certificate isn't good enough; it has to be the IETF PKIX > WG profile of X509v3. 801.1AR mostly says that. I mean, PKIX closed before I was really doing much of anything in the IETF, so all I have are vague impressions shaped by what I've picked up from inferences made observing discourse among others. So I did have to check with someone who was actually there to confirm my sense that PKIX is the Internet PKI. (Not SPKI!) And sure, anything can be connected to the Internet, and presumably the BRSKI cases will be talking to the MASA over the Internet in some fashion, but it's hard to say that the PKI used to do so is a core part of the capital-I Internet. > If you feel that my use of PKIX here is too confusing, I will change it. I'm still open to pushback, but something like "PKIX-compatible" or "PKIX-conformant" would make me happier. -Ben From nobody Fri Aug 9 12:43:51 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59E4D1201CE; Fri, 9 Aug 2019 12:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.201, RCVD_IN_DNSWL_MED=-2.3, 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 s3dG6w89iyov; Fri, 9 Aug 2019 12:43:36 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5528120241; Fri, 9 Aug 2019 12:43:32 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 52F5654814B; Fri, 9 Aug 2019 21:43:28 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 40F9A440041; Fri, 9 Aug 2019 21:43:28 +0200 (CEST) Date: Fri, 9 Aug 2019 21:43:28 +0200 From: Toerless Eckert To: Brian E Carpenter , draft-ietf-anima-grasp-api@ietf.org Cc: "anima@ietf.org" Message-ID: <20190809194328.6232pr2w2giuq2ur@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] comments on draft-ietf-anima-grasp-api X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 19:43:49 -0000 Hi Brian, * I have right now primarily a high level comment: The problem i have with the three layers of GRASP is that there is no good justification why they exist and why the API document needs to bother about them. The doc really only talks about the library of the GRASP Library. This is not to say that i do not like the idea to talk about the modularity of a GRASP implementation, its just not well motivated and executed i feel. So, one way to solve this is to also talk about the other APIs. For the extended function module, one could for example say any extensions to GRASP that are CAN BE implemented on top the GRASP API defined in this document SHOULD be implemented as a GRASP Function Module. And examples could be the functions suggested in my DNS drafts, or ther drafts you have that fit. So, thats the simple part. More interestingly, i would be a great fan of talking about the API between library and core, to justify why we want to think about this modularity. This is where the outline could be something like the following: Any peer-to-peer GRASP connection could and should be implemented in the context of the ASA, such as in a library compiled into the application. The reason is that this allows for greater confidentiality and mutual authentication then if it went through the GRASP core. Aka: any unicast message can ultimately have an originator authentication if the security and transport substrate used supports this. Which ACP does (TLS for ACP GRASP unicsast). On the other hand, all the multicast messages and the hop-by hop flooded unicast replies will have to be seen by each intervening nodes non-ASA specific GRASP core code and hence needs to be implemented in a common component called he GRASP core. For examplanation, the terms "system level" or "daemon" could be used. So as far as GRASP messages are concerned: ASA(GRASP-library)<->GRASP_core -link- GRASP-core -link- ... ASA M_FLOOD: hop-by-hop 'multicast' M_DISCOVERY: (constrained) hop-by-hop multicast M_RESPONSE: hop-by-hop unicast ASA(GRASP-library)<-...(TLS)...->ASA(GRASP-library) all unicasted messages except M_RESPONSE sent in reply to a multicast received M_DISCOVERY. So, there is a bit of work to do to go through the remainder of the document and figure out what to say about how each of the proposed API calls would operate at the GRASP API layer and at the GRASP_CORE layer. The way i imagine it, the API would be the same for both GRASP Core and GRASP Library except that i think we need to check which of the API calls need another (optional) locator parameter, because the whole goal of the exercise is that the GRASP library would create its own unicast GRASP socket(s) (e.g.: TLS) and that socket locator would need to be passed on via the API calls to the GRASP core where needed. And when that locator option is not given on the according API calls, then the unicast would go across unicast sockets created and kept only inside the GRASP Core . Which means that the GRASP libary would also be optional, but if an ASA runs directly on top of GRASP core only, then it would expose all potentially confidential objective value stuff to that shared GRASP core code. Also: When an ASA runs in an environment where it has cached its relevant peers locators, then it can operate without relying on the discovery service parts of GRASP and hence also without any GRASP cores involved, arguably making a service built on such ASA more resilient and maybe less prone to attacks. So, let me know if we can get this IMHO important high level aspect into the doc. If not, and if also can not find another reason to talk about a standardized API to the GRASP core then that text should better be moved to a non-specification section (informative only, appendix, etc. pp.) Cheers Toerless From nobody Fri Aug 9 12:55:51 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1022120180; Fri, 9 Aug 2019 12:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ra.rockwell.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60Ue8mR7Y7_u; Fri, 9 Aug 2019 12:55:32 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750081.outbound.protection.outlook.com [40.107.75.81]) (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 4722712018E; Fri, 9 Aug 2019 12:55:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Z4XM8rWhHHaXu3M8kGfF4Oafiz9S+fwT1MJsJQjRlTNP80g+tFwf5DaCz/FLHcz4CK0JYCHyBrSTi5JTBO7QC5xDirhH2OIaK8UJAWCR5PpTlwI9r/54ZBphi1vaFhymKSuBEzfE/gwXrQWnWmMescM84DXeuNsNG5n898Ww5xtT6GDCtd1nS3e8hlWPop4CS+msdGtP47b0/Ys5Stkzy1iUG9EAJXqsbbQw0YDflbkRCdq7JKPSnIdbacf3QQ6vzPfnWnYxsHjfC9/4K0apoJq+qeYth9U8c5Va9ivz9B8RfAhWlBNlP3L8ItLDFwfsw3aEGvVjC1iUoSRr/J26KQ== 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=jHEU8iPATovkVs5t1zAP59KNsiRdj+HcL6FUsEmRtaY=; b=ZHIJ+eWXZfqOSgQ1lKVSXFKUNTdgET2tXrEBG1H6UYkBVwkv+pHomSxzce6DHe07F4Wx8x80zwG8IiVL6vZvj12LLqQEIYSleW3yGyYPRrQEmNIIo9/YPe8FVOIcl4kAhFthq9kTd3cVZuFdvoRmxX3KsZYkdPLUHFe2cloaiuV7Ja9EyU5xmJI7Fo3ZEn8iTed59mibZKOz0KO2fs6vD+guiDmO5EWHoJ8sx0iZ4wCxVcmN8IHqtPs6WcbMV51zMCpxQrw0QkBRlG2xi48j1HqljXfOSwNINimWSvsVuLMch5EqLQAyzGrVxcKaX58ybe6UunEjW73yXt0QRa1w6g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ra.rockwell.com; dmarc=pass action=none header.from=ra.rockwell.com; dkim=pass header.d=ra.rockwell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ra.rockwell.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jHEU8iPATovkVs5t1zAP59KNsiRdj+HcL6FUsEmRtaY=; b=HK4+ghJYauN/UUjqq/7m/OmN5+KxK7i3awI5+AiFi83/RbVtcD+pMx6YbGeD/P3KQIAt7Y9XGMgJzmtBI5Vk+IspMu+Oqhdwo7W60+Yofyxps7s6svn7XS0HVw0l9lZM31Gr+UPRmiNIILlY9lLoTvh/1sPh91XJUMiVU9jeU9U= Received: from DM5PR2201MB1340.namprd22.prod.outlook.com (10.172.46.145) by DM5PR2201MB1724.namprd22.prod.outlook.com (10.164.253.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.18; Fri, 9 Aug 2019 19:55:24 +0000 Received: from DM5PR2201MB1340.namprd22.prod.outlook.com ([fe80::ad07:c135:5d24:2d31]) by DM5PR2201MB1340.namprd22.prod.outlook.com ([fe80::ad07:c135:5d24:2d31%5]) with mapi id 15.20.2157.015; Fri, 9 Aug 2019 19:55:24 +0000 From: Jack Visoky To: "Randy Armstrong (OPC)" , Michael Richardson , "iot-onboarding@ietf.org" , "anima@ietf.org" Thread-Topic: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI Thread-Index: AQHVTUS+OPIhCz2qG029dL1PCmEs9qbwawQAgAD7iACAABK3gIABwB5A Date: Fri, 9 Aug 2019 19:55:24 +0000 Message-ID: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> <4671.1565279232@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jmvisoky@ra.rockwell.com; x-originating-ip: [205.175.250.244] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7e41bbad-2f79-4f69-dbf4-08d71d0384bc x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM5PR2201MB1724; x-ms-traffictypediagnostic: DM5PR2201MB1724: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 01244308DF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(346002)(39860400002)(396003)(366004)(53754006)(189003)(199004)(13464003)(966005)(229853002)(256004)(14454004)(14444005)(5024004)(99286004)(316002)(66476007)(66556008)(110136005)(66446008)(64756008)(2906002)(81166006)(81156014)(25786009)(6306002)(55016002)(9686003)(8676002)(478600001)(6436002)(74316002)(7736002)(8936002)(71200400001)(71190400001)(305945005)(3846002)(6116002)(6246003)(486006)(53936002)(33656002)(2501003)(186003)(76176011)(66946007)(86362001)(76116006)(7696005)(6506007)(53546011)(26005)(102836004)(446003)(5660300002)(66066001)(476003)(52536014)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR2201MB1724; H:DM5PR2201MB1340.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ra.rockwell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: CyDrLUwbEm+k9c6jEMM14swikKTEgyFC0FFyFcFBWe/gcp+W0VcDSfdFeJgHUc1hevg/rO9UmLEtrZsNZGbraSL3hTtxgPljOArTwdv68XTLjhvB3XWsg0xkWnj4YPmjLAOTea0GeXlyju4bpcuEXiz8ZtvSEQUYJfMasCtWh8Dh+dUJO38wWFnyNq/SxVL3L496TI5bqhR5zY+blN7mRy/Tg6tbR9/TOmHZHpXIMoIuD7HdiP/p6DAqHJUVoNd++7zVFaYWMhOo/T3sF/SBTcZYO8iJdy/gAuZRdxPPSn5ZXb6NwnJlHPcdTLCr7f+KOwmrmihQJBAcHwRfbSXLQw+nHrw7uRCglgMCu5uk0ytKi3Cb3eTte+wcuaoiq0CzRjlI6QmcCmjqg/ezI3HwV7YDjpybS88ICZeR2aclCb0= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ra.rockwell.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7e41bbad-2f79-4f69-dbf4-08d71d0384bc X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2019 19:55:24.3172 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 855b093e-7340-45c7-9f0c-96150415893e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: y6dJt/5RQ4Hn8XKTsEO6NlYt3j9oMAekMOjWIf7FdQOevsRHeuEV9n6tjlYYSvaunqRtejFhLHTb5dKLdZ4I+11mse2ANaJ+oUJ8VocAyQI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2201MB1724 Archived-At: Subject: Re: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 19:55:49 -0000 Hi Everyone, I am also involved with OPC-UA and would like to provide my/my company's pe= rspective. One of the major drivers of this engagement with the ANIMA grou= p was a contentious point around whether or not TLS and EST are required fo= r support of BRSKI. Some of us had taken the position that these technolog= ies are an integral part of BRSKI and shouldn't be replaced with OPC specif= ic methods, especially given the benefit of using highly adopted security t= echnologies, as well as the tight coupling of BRSKI to these. So, I think = the idea that OPC should just use these technologies is very much a viable = answer. Also, I would strongly push back on any claims that low end OPC devices can= not support TLS. Other industrial protocols have already added TLS support= and are shipping products, including those with TLS client functionality. = TLS is no more heavy-weight than existing, OPC-specific security mechanism= s. In any event I will be sure to join the call that has been set up for later= in August. Thanks and Best Regards, --Jack Visoky -----Original Message----- From: Anima On Behalf Of Randy Armstrong (OPC) Sent: Thursday, August 8, 2019 12:54 PM To: Michael Richardson ; iot-onboarding@ietf.org; an= ima@ietf.org Subject: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI [Use caution with links & attachments] Hi Michael, OPC UA uses SecurityProfiles to specify the exact algorithms. The based RSA= profiles do not have PFS but the ECC profiles do. We expect the ECC profiles (not released yet) to be most interesting to low= end device makers. https://opcfoundation.github.io/UA-TypeRepository/Core/docs/Part7/6.6.164/ It is not clear which tls-unique attribute you are interested in. Do you need a unique identifier for the negotiated keys? If so the SecureChannelId + TokenId would provide that. https://opcfoundation.github.io/UA-TypeRepository/Core/docs/Part6/6.7.2/#Ta= ble43 Regards, Randy -----Original Message----- From: Michael Richardson Sent: August 8, 2019 8:47 AM To: Randy Armstrong (OPC) ; iot-onboardi= ng@ietf.org; anima@ietf.org Subject: Re: [Iot-onboarding] OPC and BRSKI Randy Armstrong (OPC) wrote: >> Thats what i referred to in my prior email: We would need to underst= and how to most easily duplicate the mutual authentication with certificate= s during TLS connection setup with OPC TCP UA messages.: > OPC UA CP requires mutual authentication with Certificates bound to t= he > application rather than the machine. It provides everything that you > get from TLS. Based upon my reading of the diagram, it is not obvious that it provides PF= S, but I don't think PFS is particularly important for BRSKI. It seems to = support client certificates and server certificates, and that's enough. We need an equivalent to tls-unique in order to properly bind the EST chann= el to the UA CP SecureChannel, but that's all I think. > So when the Pledge Device connects to the Registrar or the Certificat= e > Manager using UA the Device proves it has possession of the Device > private key. > That said, the KeyPair used for communication does not need to be the > same as the KeyPair used to authenticate. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Fri Aug 9 13:17:37 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD8212022A; Fri, 9 Aug 2019 13:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 QUuFAu44DrgG; Fri, 9 Aug 2019 13:17:19 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 865A412025C; Fri, 9 Aug 2019 13:17:19 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7E7933818D; Fri, 9 Aug 2019 16:16:37 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 3151A1002; Fri, 9 Aug 2019 16:17:17 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 20:17:35 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable https://tinyurl.com/yylruorn contains a diff against -24. Benjamin Kaduk via Datatracker wrote: > [disclaimer: some of these comments get pretty blunt at the end; it's= a > long document and I'm tired. Please try not to get too annoyed if I'm > failing to see something that's right in front of me.] > I concur with the directorate reviewers that expected a > high-level security analysis of what information flows where, and what > policy choices can be made that affect it. At a *very* high level > (skipping over a lot of things that I would expect to see), this would > be structured like: > On initial bootstrap, a new device uses local service autodiscovery to > locate a (proxy to a) local registrar. Having found a candidate I have included an edited version of this text. It was very well done, thank you! > Abstract > (side note?) Is there a quick explanation of why bootstrapping can > complete with just installation of the PKI (trust anchor?) and > provisioning a locally issued certificate is not mandatory? I don't think that we can fit a quick explanation into the Abstract. I did split up the last sentence. The hard thing that BRSKI provides is the trust of the network by the pledg= e. The trust of the device by the network is generally an "easy" problem solved by use of 802.1AR/IDevID. This is presently done in many existing EST and C= MP users. So I'm not sure what further to do here. > Section 1 > This document describes how pledges discover (or be discovered by) an > element of the network domain to which the pledge belongs to perform > the bootstrap. [...] > nit: s/be/are/, IIUC. > I think there's also something funky with the wording of "to perform = the > bootstrap"; we may be looking for an element "that will perform the > bootstrap". yes, done. > 4. Pledge authorizing the registrar: "Should I join it?" > nit: what is "it"? Surely not the registrar, and presumably the > "network domain" in question? yes, it =3D "network" > This document details protocols and messages to answer the above > questions. It uses a TLS connection and an PKIX (X.509v3) > certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer > points 1 and 2. It uses a new artifact called a "voucher" that the > I'm kind of confused by "[IDevID] LDevID", since my understanding was > that the LDevID is issued only after all four steps are complete. Yes, that seems to be a typo. > Also, following the IDevID link lands me at a page that claims to be = for > a standard of status "superseded". Yes, the IEEE apparently put out 802.1AR-2018 replacing -2009 last year. I don't have a copy, and the getieee program just goes in loops of logging in, or results in servlet errors. I even emailed support, and they were basically useless. {fetching coffee to avoid rant} > nit: one can use X.509v3 without being PKIX, and it's not entirely cl= ear > that the IDevIDs will chain up to the Internet PKI. You didn't respond to my suggestion that PKIX!=3DInternet PKI. I do think that we want many things the IETF PKIX WG has produced since X.509v3, so I don't think that X.509v3 is an appropriate noun to describe things. > Section 1.2 > RFC 8174 has an updated version of the BCP 14 boilerplate. done already. > I'd suggest adding "MASA Audit Log" as a defined term to give advance > warning that this is an explicit protocol feature. added. > domainID: The domain IDentity is the 160-bit SHA-1 hash of the BIT > STRING of the subjectPublicKey of the pinned-domain-cert leaf, > i.e. the Registrars' certificate. This is consistent with the > subject key identifier (Section 4.2.1.2 [RFC5280]). > What would it take to move away from SHA-1 for this purpose? It's > unclear how long it will be before finding a second preimage of the S= PKI > hash is feasible and thus using it as an identifier no longer serves = to > uniquely identify something. This was asked by Eric as well. It's the Subject Key Identifier that we want. https://tools.ietf.org/html/rfc5280#section-4.2.1.2 It's only guaranteed to exist in CA certificates. Do you think we can demand that the extension be present in IDevID? If so, we could just use that value in the MASA Audit Log. But, if we did, it would often still be the SHA-1 hash of the public key, b= ut RFC5280 says: "Other methods of generating unique numbers are also acceptable." When https://tools.ietf.org/html/rfc5758 defined SHA-2 usage, it didn't specify a way to identify keys with SHA-2, although the mechanism is pretty clear. > enrollment: The process where a device presents key material to a > network and acquires a network specific identity. For example > nit: hyphenate "network-specific". ok. > Section 1.4 > As a result of the protocol described herein, the bootstrapped > devices have the Domain CA trust anchor in common. An end entity > certificate has optionally been issued from the Domain CA. [...] > This end-entity certificate is supposed "to authenticate each > bootstrapped device to other parties in the domain", right? > The major beneficiary is that it possible to use the credentials > deployed by this protocol to secure the Autonomic Control Plane (ACP) > ([I-D.ietf-anima-autonomic-control-plane]). > I might humbly suggest "major intended beneficiary", as there seem to= be > many possibilities involving BRSKI. ok > Section 1.5 > The pledge must perform discovery of the proxy as described in > Section 4.1 using GRASP M_FLOOD announcements. > Is this DULL GRASP or full-on ACP GRASP flooding? DULL GRASP, word inserted. > Upon successfully validating a voucher artiface, a status telemetry > MUST be returned. See Section 5.7. > nit: artifact (right?) previously fixed. > The ANI Join Registrar ASA MUST support all the BRSKI and above > listed EST operations. > nit: probably need to expand ASA the first time. done. > Section 2 > The text following Figure 1 suggests that the Domain Registrar is not > always (also) a PKI RA, but the parentheticals in the figure itself a= re > easy to read as a clarification and not an optional thing, especially > since parentheticals are used in a different manner for the Key > Infrastructure box. text: Optionally the registrar also acts as a PKI Registration Authority. I think that the text should read: Optionally the registrar also acts as a PKI Certification Authority. > Section 2.1 > 3. Request to join the discovered registrar. A unique nonce is > included ensuring that any responses can be associated with this > particular bootstrapping attempt. > But the nonce is not always present! I have been thinking hard about this problem, and I agree it is hard to understand here. Part of the issue is that the decision as to when and how to accept nonceless non-expiring ("offline") vouchers is a complex question, but it's also a private decision between the manufacturer's MASA and the manufacturer's device. The non-expiring nonceless voucher is a bit like kryptonite: once the manufacturer signs such a thing, it pretty much trumps everything else. I think that we need to add a section on nonce-less offline operation. > 5. Enroll. After imprint an authenticated TLS (HTTPS) connection > exists between pledge and registrar. Enrollment over Secure > Transport (EST) [RFC7030] is then used to obtain a domain > certificate from a registrar. > Isn't this step optional? so, I can change the word to "can" rather than "is" > Section 2.2 > A voucher is a cryptographically protected artifact (a digital > signature) to the pledge device authorizing a zero-touch imprint on > the registrar domain. > nit: "using a digital signature" ok. > Vouchers provide a signed but non-encrypted communication channel > among the pledge, the MASA, and the registrar. The registrar > maintains control over the transport and policy decisions allowing > the local security policy of the domain network to be enforced. > nit: is there supposed to be a comma after "policy decisions" (in that > both the transport and policy decisions allow for policy enforcement)? okay. > 1. Uniquely identifying the pledge by the Distinguished Name (DN) > and subjectAltName (SAN) parameters in the IDevID. The unique > identification of a pledge in the voucher objects are derived > from those parameters as described below. > These unique identifiers can (by design) be used for tracking, so let= 's > be sure that we talk about any privacy considerations with them, late= r. > I see a mention in passing in Section 10.2, at least... Are you asking for a forward reference to 10.2? I will add this. I think that section 10.2 is pretty clear about this. I don't think it's mentioned just in passing. > 3. Secure auto-discovery of the pledge's MASA by the registrar (see > Section 2.8). > I don't think this is an ironclad property, since the crypto chain is > slightly limited and you are in effect trusting the pledge to hand you > something that says "use this issuer" but without as much crypto to b= ack > that up as we might want. We have to know that the given manufacturer > that signed the IDevID actually is associated with the device we're > trying to bootstrap, which can probably be arranged but I don't remem= ber > being called out explicitly. There are two issues here. One is the question of what is the list of acceptable manufacturers (below). The second part is whether a pledge could provide a fake IDevID to the Registrar. The pledge is doing TLS ClientCertificate, so the TLS has proven that the pledge has the private key corresponding to the certificate presented. I conclude that an arbitrary IDevID can not be provided by the Pledge; it has to be linked to SOME manufacturer. Some manufacturer A could point it's product at MASA B, but I don't see how this is an issue if MASA B will issues vouchers that pledge A can verify. (The pledge could have a variety of certificates from a variety of sources, perhaps all bound to the same public key, I guess, and since the Registrar sends it's certificate first, the pledge could present different identities to different networks. I think that this is a feature, not a bug. It reminds that "Kenmore" brand appliances were made by a varie= ty of manufacturers, but I don't see my dishwasher can know what identity to use until after there is communication with the MASA) The question then becomes how the Registrar comes to trust/verify the pledge's IDevID. We had a long discussion about this during the directorate reviews and going back to Feb. 2018. I thought that we resolved this. Issues https://github.com/anima-wg/anima-bootstrap/issues/120 https://github.com/anima-wg/anima-bootstrap/issues/43 https://github.com/anima-wg/anima-bootstrap/issues/46 A thread starts here: https://mailarchive.ietf.org/arch/msg/anima/p7pUw1HKq6Ot0gV8JPeRWhwvQTs Some changes that we made for this: https://github.com/anima-wg/anima-bootstrap/commit/e5ffec4cc703626012d62c= 0b3138d851b61a2f54 > Section 7.2.13 of [IDevID] discusses keyUsage and extendedKeyUsage > extensions in the IDevID certificate. Any restrictions included > I only got my hands on the 2018 rev of [IDevID], but that one does not > actually talk about extendedKeyUsage. Max was the editor of the 2009 edition, and we pointed at it. I don't seem to be able to get the 2018 edition. 7.2.13: 7.2.13 extensions The optional extensions field defined in RFC 5280 shall not be used for critical extensions in any IDevID credential with the exception of the keyUsage extension. The non-critical extensions included are specified in 7.2.5 (authorityKeyIdentifier) and 7.2.9 (subjectAltName). The key usage field defined in RFC 5280 is intended to restrict the associated key material to only the specified usages. The intention of an IDevID is to provide a long lived credential useful for identifying the device in any future protocol uses. Restrictions applied during issuance = may limit the future usefulness of the DevID. If a critical keyUsage extension is included in the IDevID, it shall include digitalSignature as defined in RFC 5280. The keyUsage extension may include keyEncipherment. The optional extensions field defined in RFC 5280 should not be used for critical extensions in any LDevID credential. As specified in RFC 5280 a network solution that uses the LDe= vID credentials and encounters a critical extension it does not understand will signal an error and fail validation of the LDevID credential. I don't know why this advice against EKU is gone from the 2018 edition. > Section 2.3.1 > In the context of BRSKI, pledges are uniquely identified by a > "serial-number". This serial-number is used both in the "serial- > number" field of voucher or voucher-requests (see Section 3) and in > local policies on registrar or MASA (see Section 5). > (editorial) if the IDevID is supposed to be a unique identifier, why = do > we need another one? The pledge extracts it from it's IDevID. The registrar extracts it again from the IDevID that it sees. It's seems hard to construct an attack where the provisional TLS connection is MITM (replacing the certificates). So I'm gonna claim belt-and-suspenders here.... the cross-check seems useful, but maybe in the end, it's a left-ov= er From=20when voucher-requests could be unsigned. > o The subject field's DN encoding MUST include the "serialNumber" > attribute with the device's unique serial number. (from [IDevID] > section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard > attributes) > side note: I had to think a bit to convince myself that DN is the ri= ght > thing here; when we use dnsNames it's preferred to put them in > subjectAltName to avoid having to pick a preferred/privileged one, but > the serial number does seem to be in a privileged position for > distinguishing the subject. The dnsNames are hard to use when we have no FQDN to attach to :-) > o The subject-alt field's encoding MAY include a non-critical > version of the RFC4108 defined HardwareModuleName. (from [IDevID] > section 7.2.9) If the IDevID is stored in a Trusted Platform > Module (TPM), then this field MAY contain the TPM identification > rather than the device's serial number. If both fields are > present, then the subject field takes precedence. > "if both fields are present", but the subject field MUST be present, = so > this field can never take precedence. I'm willing to drop, because I never got proper clarification. We were told by implementors that if the IDevID is contained in a TPM that the resulting IDevID often has the serialNumber of the TPM,not the device itself. *** MAX *** > 1. [RFC4519] section 2.31 provides an example ("WI-3005") of the > Distinguished Name "serialNumber" attribute. [RFC4514] indicates > this is a printable string so no encoding is necessary. > I don't understand why these references were chosen. Why are LDAP sp= ecs > authoritative about what the encoding format for the serialNumber DN > attribute is? E.g., one could look at RFC 5280 to see that > X520SerialNumber is a PrintableString. *** MAX *** > 2. The HardwareModuleName hwSerialNum OCTET STRING. This value is > base64 encoded to convert it to a printable string format. > Please cite Section 4 of RFC 4648 (unless you mean base64url, in which > case use Section 5). > Also, it might be nice to somehow (maybe enumerate the first list in = the same > way) tie these two items to the respective subject ND/subjectAltName > fields, to clarify why these are the only two choices. > As explained in Section 5.5 the Registrar MUST extract the serial- > number again itself from the pledge's TLS certificate. [...] > To be clear, this is still the device's IDevID certificate, that just > happens to be getting used as a TLS client certificate. Yes, that's right. > Section 2.3.2 > nit: maybe put a blank line after the IMPORTS are over? done. > Section 2.4 > In Figure 3, I had to think a bit to figure out whether the text that > did not fit mid-arrow was supposed to apply to the arrow above or bel= ow > the text (e.g., "optional: mDNS query RFC6763/RFC6762"). Yes... we did struggle to fit it into a single page. It applies to both the arrow above and below, and there are M_FLOOD and mDNS possible here. Do you have suggestions on making it clearer. > [Hmm, so we send our TLS client cert on the provisional connection, > meaning that we have to trust the proxy and registrar to be doing the > right thing w.r.t. broadcasting our identity to the world] Yes. TLS1.3 makes the certificate less visible to onlookers, but still a MI= TM would be able to collect it. We spent some time considering if we could turn the connection around so th= at the Registrar spoke first, giving the Pledge the opportunity to decide whether to provide it's identity or not. But, how would it decide? In the ANI case, we are likely doing this over wired links (long-haul fiber or internal to DC), but in the anticipated TEAP-BRSKI use case or 6tisch use, this would be WIFI / 802.15.4. What is needed is a three-party zero-knowledge proof, but how would the Registrar identify the third party (the MASA)? You are right to worry, but I don't know what to do about this. > Section 2.5.1 > The pledge is the device that is attempting to join. Until the > pledge completes the enrollment process, it has link-local network > connectivity only to the proxy. > nit(?): I think there is a subtle difference in meaning between "only > has link-local network connectivity to the proxy" and this text, and = I'm > not sure which is intended. I'm confused. > Section 2.5.3 > This may just be my personal preference (so feel free to ignore), but > talking about a "trust store used to authenticate the MASA" and "trust > store used to authenticate the pledge" would feel more readable than > "trust anchor database for authenticating the [thing] TLS connection > [thing] certificate". > It may be worth some comment about how this requirement for out-of-ba= nd > distribution of implicit trust anchors is something that BRSKI is > designed to avoid, but that distributing to just the registrar is a m= uch > more manageable task than distributing them to all devices/pledges. I think that the words "Implicit Trust Anchor" are supposed to invoke RFC7030's section 3.6.2. *** MAX *** I'm okay with your text too. > Section 2.5.5 > The Public Key Infrastructure (PKI) administers certificates for the > domain of concerns, providing the trust anchor(s) for it and allowing > nit: "domain of concern" singular fixed. > The voucher provides a method for the distribution of a single PKI > trust anchor (as the "pinned-domain-cert"). A distribution of the > Earlier we talked about the "pinned-domain-cert leaf" in the domainID > definition. Was that supposed to be "leaf" in the YANG sense and not > in the PKIX "leaf certificate"/"end-entity certificate" sense? Yes. I'll change "leaf" above to "attribute" > The expectations of the PKI are unchanged from EST [[RFC7030]]. This > Which parts of RFC 7030 talk about its expectations of the PKI? The fact that the public key infrastructure can enroll new end-entity certificates? I agree that 7030 doesn't really set out the expectations in one place. *** MAX *** > Section 2.6.1 > Many devices when bootstrapping do not have knowledge of the current > time. Mechanisms such as Network Time Protocols cannot be secured > until bootstrapping is complete. Therefore bootstrapping is defined > in a method that does not require knowledge of the current time. A > nit: I'd suggest maybe "framework", "scenario", or "environment" rath= er > than "method". done. > Section 2.6.2 > [RFC5280] explains that long lived pledge certificates "SHOULD be > assigned the GeneralizedTime value of 99991231235959Z". Registrars > This misses the important "for the notAfter field" part. > Why is 3 years the relevant cutoff here? That's a good question. *** MAX *** > Section 2.7 > There exist operationally open network wherein devices gain > nit: "networks" plural fixed. > unauthenticated access to the internet at large. In these use cases > the management domain for the device needs to be discovered within > the larger internet. These are less likely within the anima scope > but may be more important in the future. > nit: less likely than what? changed to: The case where a device can boot and get access to larger Internet are less likely within the ANIMA ACP scope but may be more important in the future. In the ANIMA ACP scope, new devices will be quarantined behind a Join Proxy. > In order to support these scenarios, the pledge MAY contact a well > known URI of a cloud registrar if a local registrar cannot be > discovered or if the pledge's target use cases do not include a local > registrar. ben> I don't see the connection between "configure itself to become the ben> local registrar" and "contact a well-known URI of a cloud registra= r". In a completely Greenfield situation, where there is no local infrastructure at all, given an appropriately magic "Intent" (remember where this WG started...), then a cloud registrar could inform a device that it is to become the Registrar. How this would work depends upon the details of the magic unicorn Intent (see failed SUPA WG). > If the pledge uses a well known URI for contacting a cloud registrar > an Implicit Trust Anchor database (see [RFC7030]) MUST be used to > authenticate service as described in [RFC6125]. This is consistent ben> Would this be more likely to be installed by the manufacturer or ben> device owner? Manufacturer, as it's implicit. That's how EST works today. > nit: "service" needs an article. add "that" > Section 2.8 > approach if they ensure a single MASA URL works for all pledge's > associated with each trust anchor. > nit: "pledges" non-possessive Seems pledges should be plural to be. Changed to: This is useful for Registrars which are servicing pledges on direct= ly connected networks.or plural > Section 3 > A pledge forms the "pledge voucher-request" and submits it to the > registrar. already fixed. > The "proximity-registrar-cert" leaf is used in the pledge voucher- > requests. This provides a method for the pledge to assert the > registrar's proximity. > "proximity" in what sense? How much verification/confidence needs to= be > done? (Also, I would have expected the assertion to go the other way; > that the registrar asserts the pledge's proximity -- how does the ple= dge > have a way to know that the registrar is nearby when the proxy is > transparent?) There is a TLS connection between them. Yes, it could go anywhere. The proxy was link-local, and the proxy pointed the connection at the Registrar. I guess it would be useful if the proxy was stateful, and contributed another cryptographic layer for non-ACP cases. In the ACP case, the Registrar knows it can trust the proxy because it's on the ACP, and is connecting from an ULA address that is part of the ACP. Yes, the Registrar could be anywhere, but the proxy makes it appear to be on the local link. I'm not sure what else I can add to the text. > Section 3.3 > Example (1) The following example illustrates a pledge voucher- > request. The assertion leaf is indicated as 'proximity' > and the registrar's TLS server certificate is included > in the 'proximity-registrar-cert' leaf. See > Section 5.2. > { > "ietf-voucher-request:voucher": { > "nonce": "62a2e7693d82fcda2624de58fb6722e5", > "created-on": "2017-01-01T00:00:00.000Z", > "proximity-registrar-cert": "base64encodedvalue=3D=3D" > } > } > I do not see an 'assertion' leaf populated. added. > Example (2) The following example illustrates a registrar voucher- > request. The 'prior-signed-voucher-request' leaf is > populated with the pledge's voucher-request (such as the > prior example). The pledge's voucher-request is a > binary object. In the JSON encoding used here it must > Why is it a binary object? We just saw a previous example with a JSON > (non-binary) encoding. (Hint: CMS-signed,but we didn't say that.) okay, I'll say that. > There is (again) no assertion, and the created-on does not match > exactly. added. > Section 3.4 > The RFC 8174 version of the BCP 14 boilerplate could be used in the > module, too. > Also, is the 2017 copyright still correct, especially given that it i= s a > 2018-02-14 revision? already fixed. fixing date. > For example, a pledge might sign a voucher request > with a proximity-registrar-cert, and the registrar > then includes it in the prior-signed-voucher-request field. > nit: maybe "includes it" could be disambiguated (perhaps s/in/as/)? okay. > This is a simple mechanism for a chain of trusted > parties to change a voucher request, while > maintaining the prior signature information. > "chain" seems to admit the possibility of more than one > modification/resigning event, but the architecture as described seems= to > only have the registrar doing this. Yes. prior-signed-voucher-request could be used in new ways. > registrar agree on proximity assertions. The MASA SHOULD > remove all prior-signed-voucher-request information when > signing a voucher for imprinting so as to minimize the > final voucher size."; > (side note?) This removal would open up some minor exotic attacks in > cases where a pledge reuses an existing nonce (potentially from a > different device), but is probably an okay tradeoff to make. agreed. > The first certificate in the Registrar TLS server > certificate_list sequence (see [RFC5246]) presented by > the Registrar to the Pledge. This MUST be populated in a > Pledge's voucher request if a proximity assertion is > requested."; > 5246 is replaced by 8446. okay. Annoying to have references in the YANG module itself. > It might be simplest to just say the "end-entity TLS certificate", at > least for TLS practitioners. (Maybe nof for a different audience, > though.) > How do I know that a proximity assertion is requested? That is, How does the pledge knows it wants one? Because it's been programmed that way. I have removed "if", and replaced it with "when". I have added the words "end-entity TLS certificate" to hammer the point. > Section 4 > The role of the proxy is to facilitate communications. The proxy > forwards packets between the pledge and a registrar that has been > provisioned to the proxy via GRASP discovery. > [same DULL question as above] It's not DULL, because this is the Proxy speaking within the ACP. I will write "full GRASP". > The proxy does not terminate the TLS handshake: it passes streams of > bytes onward without examination. A proxy MUST NOT assume any > specific TLS version. > Passing bytes without examination is by definition not assuming any > version of TLS. So while I think it would make the most sense to j= ust > remove that sentence, if it's going to say it might be worth also > noting the TLS invariants discussed in > https://tools.ietf.org/html/rfc8446#section-9.3 . added reference. > Section 4.1 > through a proxy. The proxy is transparent to the pledge. The > communication between the pledge is over IPv6 Link-Local addresses. > nit: between the pledge and what? Join Proxy added. > M_FLOOD. The active methods SHOULD exponentially back-off to a > maximum of one hour to avoid overloading the network with discovery > attempts. Detection of change of physical link status (ethernet > carrier for instance) SHOULD reset the exponential back off. > Mathematically, "exponential" requires to specify the base of the > exponent (or just say "by doubling"). (Also later in the section.) Well, of course the base should be "e" :-) I'll write doubling. > Once all discovered services are attempted (assuming that none > succeeded) the device MUST return to listening for GRASP M_FLOOD. It > SHOULD periodically retry the manufacturer specific mechanisms. The > pledge MAY prioritize selection order as appropriate for the > anticipated environment. > nit: "manufacturer-specific" takes a hyphen > not-nit: what are "the manufacturer-specific mechanisms"? (I don't > remember such discussion yet.) 1) Appendix A and Appendix B. 2) a bunch of manufacturers have proprietary equivalent of BRSKI. I think that this includes both Cisco and Juniper. > Section 4.1.1 > Is Figure 6b supposed to be using JSON diagnostic notation for CBOR or > some other notation? > Also, I'm not sure that picking an arbitrary (representative) session= -id > value, LL address, and port is helpful when describing the formatting= of > the message. Maybe some different introductory text would change > things. I have placed the example after the CDDL. > Section 4.3 > If we're only defining an EST-TLS objective, how will proxies know th= at > the registrar supports BRSKI? > It's a little weird to put the reference for GRASP but not ACP. Eith= er > none or both would feel more natural (given that we've seen both alre= ady > a couple times). The name is "AN_join_registrar", which implies BRSKI. The objective-value of "EST-TLS" means EST. (vs CMP or some other enrollment mechanism that people have asked for). There could be many announcements From=20different things. This announcement and the Join Proxy described here only applies to ACP. Added: This section applies is normative for uses with an ANIMA ACP. The use of GRASP mechanism part of the ACP. Other users of BRSKI will need to define an equivalent proxy mechanism, and an equivalent mechanism to configure the proxy. the beginning of section 4. > Section 5 > MASA URI is "https://" iauthority "/.well-known/est". > nit: "The MASA URI". > Is this always the case, with no opportunity for modification, even as > included in an IDevID certificate extension? Either just the iauthority (now "authority") is present in the IDevID, or t= he entire URL (with ports numbers and paths) is present. I think that is what you want. > BRSKI uses JSON [RFC7159] for all new operations defined here, and > RFC 7159 is obsoleted by RFC 8259. already fixed. > While EST section 3.2 does not insist upon use of HTTP 1.1 persistent > connections, BRSKI-EST connections SHOULD use persistent connections. > The intention of this guidance is to ensure the provisional TLS state > occurs only once, and that the subsequent resolution of the provision > state is not subject to a MITM attack during a critical phase. > I think we probably want a requirement that if persistent connections > are not used (and what about HTTP/2 or HTTP/3 ones?), the pledge MUST > check that the exact same certificate is used to authenticate the > registrar for all transactions. If the signature in the handshake is > valid but you can only chain the certificate up to your trust anchor > once you finish imprinting, you still know that the entire session's > data has been talking to the now-authenticated party (as opposed to t= he > TLS case where you try to add a new certificate mid-connection, where > that boundary is unclear), but things are much easier to reason about= if > you are sure that each EST transaction is talking to the same peer. We had a conversation two years ago about what we might need to say about HTTP/2, and aside from being unable to handle QUIC (due to proxy), we don't see any issue. I have added: If non-persistent connections are used, then both the pledge and the registrar MUST remember the certificates seen, and also sent for the first connection. They MUST check each subsequent connections for the same certificates, and each end MUST use the same certificates as well. This places a difficult restricti= on on rolling certificates on the Registrar. But, that's why we have SHOULD, and the SHOULD (vs MUST) part was really to allow for some fancy HTTP/3 we know nothing about :-) > o In the language of [RFC6125] this provides for a SERIALNUM-ID > category of identifier that can be included in a certificate and > therefore that can also be used for matching purposes. The > SERIALNUM-ID whitelist is collated according to manufacturer trust > anchor since serial numbers are not globally unique. > RFC 6125 does not define a SERIALNUM-ID, so maybe we could reword to = "in > the model of RFC 6125" or "provides a new SERIAL-ID category" or > similar. I have an open request to *** MAX *** to clarify this part. > o The registrar performs log verifications in addition to local > authorization checks before accepting optional pledge device > enrollment requests. > Maybe give us a section reference to what the "log validations" are? We decided that we did not have enough experience to write normative langua= ge here. (It's not an Internet Standard) > Section 5.1 > Establishment of the BRSKI-EST TLS connection is as specified in EST > [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" > [RFC7030] wherein the client is authenticated with the IDevID > certificate, and the EST server (the registrar) is provisionally > authenticated with an unverified server certificate. > I'd consider noting that the signature (or other operation) made by t= he > certificate must be validated, and that the received certificate and > chain must be retained for later validation. Added: The signatures in the certificate MUST be validated even if a signing key can not (yet) be validated. The certificate (or chain) MUST be retained for later validation. A self-signed certificate for the Registrar is acceptable as the voucher will validate it. > The pledge maintains a security paranoia concerning the provisional > state, and all data received, until a voucher is received and > verified as specified in Section 5.6.1 > Since section 5.6.1 just talks about the voucher verification process= , I > think we need to say more about what "security paranoia" entails: > acknowledging that all data transmitted is sent to an unauthenticated > peer, with corresponding privacy considerations, and that all received > data is not authenticated by the TLS connection and must be > self-authenticating or otherwise considered untrusted. The pledge code needs to be written with the assumption that all data is being transmitted at this point to an unauthenticated peer, and that received data, while inside a TLS connection, MUST be considered untrusted. This particularly applies to HTTP headers and CMS structures that make up the voucher. > A pledge that can not maintain as many connections as there are > eligible proxies. If no connection is making process after 5 seconds > nit: that's not a complete sentence. already fixed to: A pledge that can not maintain as many connections as there a= re eligible proxies will need to rotate among the various choice= s, terminating connections that do not appear to be making progress. stopping here for today. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1N1MwACgkQgItw+93Q 3WXy5Af+KZ+2Fweg/NyPm/sZQxFj5Wkcf78ueFAqFylMuHtEZV5YdWMhAQKdIWui yBxf2pn2QfIei+jFgCOt9T6MO1Yep0WyoEnT+uEuLmobpWppZKfhhQmv8+D4A9tv 2JJ2CvS8728q9cUjUzVvfNI3ZACOuq1y5LGDpDWYTxho+YDsB348GBH8VlCBbaef 5Tj7rCDlqZRt+jbw/Zey/rDg4rHR6Y9WJvHqllN2u36lnrNECVRKylvU2EMRyXJ+ 1kQyslHnDKCJHW0TVXwmWG+c92dIogpUBfwBGnsKLy65ERbUzbFXSzc/b0rdHuO7 +8pAk7hjjMqz3V+uKwaCBj0M+if4Kg== =MBD2 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 9 15:56:06 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 870FB120086; Fri, 9 Aug 2019 15:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 ovOn9f7FVX-x; Fri, 9 Aug 2019 15:55:58 -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 2AE60120019; Fri, 9 Aug 2019 15:55:57 -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 x79MtguL016606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 9 Aug 2019 18:55:44 -0400 Date: Fri, 9 Aug 2019 17:55:41 -0500 From: Benjamin Kaduk To: Michael Richardson Cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org Message-ID: <20190809225540.GV59807@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <23257.1565381837@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23257.1565381837@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 22:56:04 -0000 On Fri, Aug 09, 2019 at 04:17:17PM -0400, Michael Richardson wrote: > > https://tinyurl.com/yylruorn contains a diff against -24. > > Benjamin Kaduk via Datatracker wrote: > > [disclaimer: some of these comments get pretty blunt at the end; it's a > > long document and I'm tired. Please try not to get too annoyed if I'm > > failing to see something that's right in front of me.] > > > I concur with the directorate reviewers that expected a > > high-level security analysis of what information flows where, and what > > policy choices can be made that affect it. At a *very* high level > > (skipping over a lot of things that I would expect to see), this would > > be structured like: > > > On initial bootstrap, a new device uses local service autodiscovery to > > locate a (proxy to a) local registrar. Having found a candidate > > I have included an edited version of this text. It was very well done, thank > you! > > > Abstract > > > (side note?) Is there a quick explanation of why bootstrapping can > > complete with just installation of the PKI (trust anchor?) and > > provisioning a locally issued certificate is not mandatory? > > I don't think that we can fit a quick explanation into the Abstract. > I did split up the last sentence. This was a side note, so for my own edification more than the good of the document... > The hard thing that BRSKI provides is the trust of the network by the pledge. > The trust of the device by the network is generally an "easy" problem solved > by use of 802.1AR/IDevID. This is presently done in many existing EST and CMP > users. > So I'm not sure what further to do here. ...and this helps; thank you! > > Section 1 > > > This document describes how pledges discover (or be discovered by) an > > element of the network domain to which the pledge belongs to perform > > the bootstrap. [...] > > > nit: s/be/are/, IIUC. > > I think there's also something funky with the wording of "to perform the > > bootstrap"; we may be looking for an element "that will perform the > > bootstrap". > > yes, done. > > > 4. Pledge authorizing the registrar: "Should I join it?" > > > nit: what is "it"? Surely not the registrar, and presumably the > > "network domain" in question? > > yes, it = "network" > > > This document details protocols and messages to answer the above > > questions. It uses a TLS connection and an PKIX (X.509v3) > > certificate (an IEEE 802.1AR [IDevID] LDevID) of the pledge to answer > > points 1 and 2. It uses a new artifact called a "voucher" that the > > > I'm kind of confused by "[IDevID] LDevID", since my understanding was > > that the LDevID is issued only after all four steps are complete. > > Yes, that seems to be a typo. > > > Also, following the IDevID link lands me at a page that claims to be for > > a standard of status "superseded". > > Yes, the IEEE apparently put out 802.1AR-2018 replacing -2009 last year. > I don't have a copy, and the getieee program just goes in loops of logging > in, or results in servlet errors. > I even emailed support, and they were basically useless. > {fetching coffee to avoid rant} > > > nit: one can use X.509v3 without being PKIX, and it's not entirely clear > > that the IDevIDs will chain up to the Internet PKI. > > You didn't respond to my suggestion that PKIX!=Internet PKI. > I do think that we want many things the IETF PKIX WG has produced > since X.509v3, so I don't think that X.509v3 is an appropriate noun > to describe things. I think this discussion is continuing in the other thread, right? > > Section 1.2 > > > RFC 8174 has an updated version of the BCP 14 boilerplate. > > done already. > > > I'd suggest adding "MASA Audit Log" as a defined term to give advance > > warning that this is an explicit protocol feature. > > added. > > > domainID: The domain IDentity is the 160-bit SHA-1 hash of the BIT > > STRING of the subjectPublicKey of the pinned-domain-cert leaf, > > i.e. the Registrars' certificate. This is consistent with the > > subject key identifier (Section 4.2.1.2 [RFC5280]). > > > What would it take to move away from SHA-1 for this purpose? It's > > unclear how long it will be before finding a second preimage of the SPKI > > hash is feasible and thus using it as an identifier no longer serves to > > uniquely identify something. > > This was asked by Eric as well. > It's the Subject Key Identifier that we want. > https://tools.ietf.org/html/rfc5280#section-4.2.1.2 > > It's only guaranteed to exist in CA certificates. > Do you think we can demand that the extension be present in IDevID? I'm doubtful that we have enough leverage to make that stick. > If so, we could just use that value in the MASA Audit Log. > But, if we did, it would often still be the SHA-1 hash of the public key, but > RFC5280 says: > "Other methods of generating unique numbers are also acceptable." > > When https://tools.ietf.org/html/rfc5758 defined SHA-2 usage, > it didn't specify a way to identify keys with SHA-2, although the mechanism > is pretty clear. So, if all we're going for is "consistent with the 5280 SKI", then "the SHA-256 hash of the BIT STRING of the [...] certificate" is still going to meet that bar. I guess the pithy version of my stance here is that "from a standards point of view it's easy to move to SHA-2, and we should only think about sticking with SHA-1 if there's an implemnetation or deployment reason to do so". > > enrollment: The process where a device presents key material to a > > network and acquires a network specific identity. For example > > > nit: hyphenate "network-specific". > > ok. > > > Section 1.4 > > > As a result of the protocol described herein, the bootstrapped > > devices have the Domain CA trust anchor in common. An end entity > > certificate has optionally been issued from the Domain CA. [...] > > > This end-entity certificate is supposed "to authenticate each > > bootstrapped device to other parties in the domain", right? > > > The major beneficiary is that it possible to use the credentials > > deployed by this protocol to secure the Autonomic Control Plane (ACP) > > ([I-D.ietf-anima-autonomic-control-plane]). > > > > > I might humbly suggest "major intended beneficiary", as there seem to be > > many possibilities involving BRSKI. > > ok > > > Section 1.5 > > > The pledge must perform discovery of the proxy as described in > > Section 4.1 using GRASP M_FLOOD announcements. > > > Is this DULL GRASP or full-on ACP GRASP flooding? > > DULL GRASP, word inserted. > > > Upon successfully validating a voucher artiface, a status telemetry > > MUST be returned. See Section 5.7. > > > nit: artifact (right?) > > previously fixed. > > > The ANI Join Registrar ASA MUST support all the BRSKI and above > > listed EST operations. > > > nit: probably need to expand ASA the first time. > > done. > > > Section 2 > > > The text following Figure 1 suggests that the Domain Registrar is not > > always (also) a PKI RA, but the parentheticals in the figure itself are > > easy to read as a clarification and not an optional thing, especially > > since parentheticals are used in a different manner for the Key > > Infrastructure box. > > text: Optionally the registrar also acts as a PKI Registration > Authority. > > I think that the text should read: > Optionally the registrar also acts as a PKI Certification > Authority. > > > > > Section 2.1 > > > 3. Request to join the discovered registrar. A unique nonce is > > included ensuring that any responses can be associated with this > > particular bootstrapping attempt. > > > But the nonce is not always present! > > I have been thinking hard about this problem, and I agree it is hard to > understand here. Part of the issue is that the decision as to when and how > to accept nonceless non-expiring ("offline") vouchers is a complex question, > but it's also a private decision between the manufacturer's MASA and > the manufacturer's device. > > The non-expiring nonceless voucher is a bit like kryptonite: once the > manufacturer signs such a thing, it pretty much trumps everything else. > > I think that we need to add a section on nonce-less offline operation. > > > 5. Enroll. After imprint an authenticated TLS (HTTPS) connection > > exists between pledge and registrar. Enrollment over Secure > > Transport (EST) [RFC7030] is then used to obtain a domain > > certificate from a registrar. > > > Isn't this step optional? > > so, I can change the word to "can" rather than "is" (and fix up the grammar, but) sure > > Section 2.2 > > > A voucher is a cryptographically protected artifact (a digital > > signature) to the pledge device authorizing a zero-touch imprint on > > the registrar domain. > > > nit: "using a digital signature" > > ok. > > > Vouchers provide a signed but non-encrypted communication channel > > among the pledge, the MASA, and the registrar. The registrar > > maintains control over the transport and policy decisions allowing > > the local security policy of the domain network to be enforced. > > > nit: is there supposed to be a comma after "policy decisions" (in that > > both the transport and policy decisions allow for policy enforcement)? > > okay. > > > 1. Uniquely identifying the pledge by the Distinguished Name (DN) > > and subjectAltName (SAN) parameters in the IDevID. The unique > > identification of a pledge in the voucher objects are derived > > from those parameters as described below. > > > These unique identifiers can (by design) be used for tracking, so let's > > be sure that we talk about any privacy considerations with them, later. > > I see a mention in passing in Section 10.2, at least... > > Are you asking for a forward reference to 10.2? I will add this. > I think that section 10.2 is pretty clear about this. > I don't think it's mentioned just in passing. It looks like the main coverage here is: o the identity of the device being enrolled (down to the serial- number!). and the discussion in the last three paragraphs or so. I do appreciate the importance of distinguishing between the high-end router and the human users (and we will have a long hard think about it again when BRSKI profiles for IoT use come through, I'm sure), so thank you for that. But I'm not sure that we clearly draw the connection to "the manufacturer knows the identity of the device being enrolled" to "and can guess where it is, and definitely knows who the owner is, and can potentially follow that over time if the device has to reenroll". Now, for the high-end router case there is literally nothing new here -- the vendor is assumed to already be doing inventory tracking of which customers have which routers! But I think it's important to make the connection from "knows identity" to "tracking", since this topic will come up for any use of BRSKI in other situations. > > 3. Secure auto-discovery of the pledge's MASA by the registrar (see > > Section 2.8). > > > I don't think this is an ironclad property, since the crypto chain is > > slightly limited and you are in effect trusting the pledge to hand you > > something that says "use this issuer" but without as much crypto to back > > that up as we might want. We have to know that the given manufacturer > > that signed the IDevID actually is associated with the device we're > > trying to bootstrap, which can probably be arranged but I don't remember > > being called out explicitly. > > There are two issues here. > > One is the question of what is the list of acceptable manufacturers (below). > The second part is whether a pledge could provide a fake IDevID to > the Registrar. The pledge is doing TLS ClientCertificate, so the TLS > has proven that the pledge has the private key corresponding to the > certificate presented. I conclude that an arbitrary IDevID can not be > provided by the Pledge; it has to be linked to SOME manufacturer. Some Well, it has to be linked to some entity that signed the IDevID. That may or may not be a manufacturer, but the Registrar does have the capability to look at what signed the IDevID and apply a whitelist of known, verified, manufacturers. > manufacturer A could point it's product at MASA B, but I don't see how this > is an issue if MASA B will issues vouchers that pledge A can verify. > > (The pledge could have a variety of certificates from > a variety of sources, perhaps all bound to the same public key, I guess, and > since the Registrar sends it's certificate first, the pledge could present > different identities to different networks. I think that this is a feature, > not a bug. It reminds that "Kenmore" brand appliances were made by a variety > of manufacturers, but I don't see my dishwasher can know what identity > to use until after there is communication with the MASA) Sure, that is probably a feature at least in some cases. But can we assume that a given pledge has a single distinguished MASA? The pledge gives the registrar a thing that says "go here for my MASA", and the registrar can do a fair bit of validation on that, but there's still potentially some control in the pledge's hands about where the registrar goes to, and lots of room for attack by hostile pledges if the registrar is buggy. It's not like there's a single authoritative (global) database of (device, MASA) pairs that we can query and have unconditional trust is giving the right result (and validating what device we're looking up, even). Things are fragmented, and at the protocol level, we can't be confident that we wouldn't get a different (valid!) answer if we asked somewhere else, or asked a slightly different question. (And, given the track record of Web PKI CAs, I expect some baseline level of bogus IDevIDs to be out there.) > The question then becomes how the Registrar comes to trust/verify the > pledge's IDevID. We had a long discussion about this during the directorate > reviews and going back to Feb. 2018. I thought that we resolved this. > Issues > https://github.com/anima-wg/anima-bootstrap/issues/120 > https://github.com/anima-wg/anima-bootstrap/issues/43 > https://github.com/anima-wg/anima-bootstrap/issues/46 > A thread starts here: > https://mailarchive.ietf.org/arch/msg/anima/p7pUw1HKq6Ot0gV8JPeRWhwvQTs > > Some changes that we made for this: > https://github.com/anima-wg/anima-bootstrap/commit/e5ffec4cc703626012d62c0b3138d851b61a2f54 Maybe, "Configuration or distribution of these trust anchor databases is out-of-scope of this specification. Note that the trust anchors in/excluded from the database will affect which manufacturers' devices are acceptable to the registrar as pledges, and can also be used to limit the set of MASAs that are trusted for enrollment."? > > Section 7.2.13 of [IDevID] discusses keyUsage and extendedKeyUsage > > extensions in the IDevID certificate. Any restrictions included > > > I only got my hands on the 2018 rev of [IDevID], but that one does not > > actually talk about extendedKeyUsage. > > Max was the editor of the 2009 edition, and we pointed at it. > I don't seem to be able to get the 2018 edition. I think we could probably reword this to just acknowledge that [IDevID] acknowledges that adding restrictions in the certificate can limit applicability, and since these are long-lived, usually you don't want to throw random extra restrictions into them. > 7.2.13: > > 7.2.13 extensions > > The optional extensions field defined in RFC 5280 shall not be used for > critical extensions in any IDevID credential with the exception of the > keyUsage extension. The non-critical extensions included are specified > in 7.2.5 (authorityKeyIdentifier) and 7.2.9 (subjectAltName). > The key usage field defined in RFC 5280 is intended to restrict the > associated key material to only the > specified usages. The intention of an IDevID is to provide a long lived > credential useful for identifying the > device in any future protocol uses. Restrictions applied during issuance may > limit the future usefulness of > the DevID. If a critical keyUsage extension is included in the IDevID, it > shall include digitalSignature as > defined in RFC 5280. The keyUsage extension may include keyEncipherment. > The optional extensions field defined in RFC 5280 should not be used for > critical extensions in any LDevID > credential. As specified in RFC 5280 a network solution that uses the LDevID > credentials and encounters a > critical extension it does not understand will signal an error and fail > validation of the LDevID credential. > > I don't know why this advice against EKU is gone from the 2018 edition. "Which part is the advice against EKU?" > > Section 2.3.1 > > > In the context of BRSKI, pledges are uniquely identified by a > > "serial-number". This serial-number is used both in the "serial- > > number" field of voucher or voucher-requests (see Section 3) and in > > local policies on registrar or MASA (see Section 5). > > > (editorial) if the IDevID is supposed to be a unique identifier, why do > > we need another one? > > The pledge extracts it from it's IDevID. > The registrar extracts it again from the IDevID that it sees. > It's seems hard to construct an attack where the provisional TLS connection > is MITM (replacing the certificates). So I'm gonna claim belt-and-suspenders > here.... the cross-check seems useful, but maybe in the end, it's a left-over > From when voucher-requests could be unsigned. I don't actually have a big complaint, here (and am definitely not asking to change the wire bits!). Perhaps we could go easy on "unique" or maybe just acknowledge that there's supposed to be a 1:1 map between serial number and IDevID. (Or not, of course.) > > o The subject field's DN encoding MUST include the "serialNumber" > > attribute with the device's unique serial number. (from [IDevID] > > section 7.2.8, and [RFC5280] section 4.1.2.4's list of standard > > attributes) > > > side note: I had to think a bit to convince myself that DN is the right > > thing here; when we use dnsNames it's preferred to put them in > > subjectAltName to avoid having to pick a preferred/privileged one, but > > the serial number does seem to be in a privileged position for > > distinguishing the subject. > > The dnsNames are hard to use when we have no FQDN to attach to :-) > > > o The subject-alt field's encoding MAY include a non-critical > > version of the RFC4108 defined HardwareModuleName. (from [IDevID] > > section 7.2.9) If the IDevID is stored in a Trusted Platform > > Module (TPM), then this field MAY contain the TPM identification > > rather than the device's serial number. If both fields are > > present, then the subject field takes precedence. > > > "if both fields are present", but the subject field MUST be present, so > > this field can never take precedence. > > I'm willing to drop, because I never got proper clarification. > We were told by implementors that if the IDevID is contained in a TPM that > the resulting IDevID often has the serialNumber of the TPM,not the device > itself. > > *** MAX *** > > > 1. [RFC4519] section 2.31 provides an example ("WI-3005") of the > > Distinguished Name "serialNumber" attribute. [RFC4514] indicates > > this is a printable string so no encoding is necessary. > > > I don't understand why these references were chosen. Why are LDAP specs > > authoritative about what the encoding format for the serialNumber DN > > attribute is? E.g., one could look at RFC 5280 to see that > > X520SerialNumber is a PrintableString. > > *** MAX *** > > > 2. The HardwareModuleName hwSerialNum OCTET STRING. This value is > > base64 encoded to convert it to a printable string format. > > > Please cite Section 4 of RFC 4648 (unless you mean base64url, in which > > case use Section 5). > > Also, it might be nice to somehow (maybe enumerate the first list in the same > > way) tie these two items to the respective subject ND/subjectAltName > > fields, to clarify why these are the only two choices. > > > As explained in Section 5.5 the Registrar MUST extract the serial- > > number again itself from the pledge's TLS certificate. [...] > > > To be clear, this is still the device's IDevID certificate, that just > > happens to be getting used as a TLS client certificate. > > Yes, that's right. > > > Section 2.3.2 > > > nit: maybe put a blank line after the IMPORTS are over? > > done. > > > Section 2.4 > > > In Figure 3, I had to think a bit to figure out whether the text that > > did not fit mid-arrow was supposed to apply to the arrow above or below > > the text (e.g., "optional: mDNS query RFC6763/RFC6762"). > > Yes... we did struggle to fit it into a single page. > It applies to both the arrow above and below, and there are M_FLOOD > and mDNS possible here. Do you have suggestions on making it clearer. Hmm, maybe give each one a unique symbol (+*&$#?) and put that in the middle of the relevant arrows as well as in the text? > > [Hmm, so we send our TLS client cert on the provisional connection, > > meaning that we have to trust the proxy and registrar to be doing the > > right thing w.r.t. broadcasting our identity to the world] > > Yes. TLS1.3 makes the certificate less visible to onlookers, but still a MITM > would be able to collect it. > > We spent some time considering if we could turn the connection around so that > the Registrar spoke first, giving the Pledge the opportunity to decide > whether to provide it's identity or not. > But, how would it decide? Indeed. > In the ANI case, we are likely doing this over wired links (long-haul fiber > or internal to DC), but in the anticipated TEAP-BRSKI use case or 6tisch > use, this would be WIFI / 802.15.4. > > What is needed is a three-party zero-knowledge proof, but how would the > Registrar identify the third party (the MASA)? > > You are right to worry, but I don't know what to do about this. I don't, either. Well, I do: "document it and move on", but that still leaves a bad taste in my mouth. > > Section 2.5.1 > > > The pledge is the device that is attempting to join. Until the > > pledge completes the enrollment process, it has link-local network > > connectivity only to the proxy. > > > nit(?): I think there is a subtle difference in meaning between "only > > has link-local network connectivity to the proxy" and this text, and I'm > > not sure which is intended. > > I'm confused. The current text asserts that it has link-local connectivity, and further that the extent of this connectivity is limited to the proxy. My alternative asserts that it can only talk to the proxy over this link-local connectivity, but leaves open the possibility of other avenues of communication (e.g., a WWAN card). > > Section 2.5.3 > > > This may just be my personal preference (so feel free to ignore), but > > talking about a "trust store used to authenticate the MASA" and "trust > > store used to authenticate the pledge" would feel more readable than > > "trust anchor database for authenticating the [thing] TLS connection > > [thing] certificate". > > > It may be worth some comment about how this requirement for out-of-band > > distribution of implicit trust anchors is something that BRSKI is > > designed to avoid, but that distributing to just the registrar is a much > > more manageable task than distributing them to all devices/pledges. > > I think that the words "Implicit Trust Anchor" are supposed to invoke > RFC7030's section 3.6.2. *** MAX *** > I'm okay with your text too. I have no way to tell what is just my personal preference and what is objectively better, so feel free to ignore. > > Section 2.5.5 > > > The Public Key Infrastructure (PKI) administers certificates for the > > domain of concerns, providing the trust anchor(s) for it and allowing > > > nit: "domain of concern" singular > > fixed. > > > The voucher provides a method for the distribution of a single PKI > > trust anchor (as the "pinned-domain-cert"). A distribution of the > > > Earlier we talked about the "pinned-domain-cert leaf" in the domainID > > definition. Was that supposed to be "leaf" in the YANG sense and not > > in the PKIX "leaf certificate"/"end-entity certificate" sense? > > Yes. > I'll change "leaf" above to "attribute" > > > The expectations of the PKI are unchanged from EST [[RFC7030]]. This > > Which parts of RFC 7030 talk about its expectations of the PKI? > > The fact that the public key infrastructure can enroll new > end-entity certificates? I agree that 7030 doesn't really set out > the expectations in one place. > *** MAX *** > > > Section 2.6.1 > > > Many devices when bootstrapping do not have knowledge of the current > > time. Mechanisms such as Network Time Protocols cannot be secured > > until bootstrapping is complete. Therefore bootstrapping is defined > > in a method that does not require knowledge of the current time. A > > > nit: I'd suggest maybe "framework", "scenario", or "environment" rather > > than "method". > > done. > > > Section 2.6.2 > > > [RFC5280] explains that long lived pledge certificates "SHOULD be > > assigned the GeneralizedTime value of 99991231235959Z". Registrars > > > This misses the important "for the notAfter field" part. (The above and below were separate comments; not sure if that came through.) > > Why is 3 years the relevant cutoff here? > > That's a good question. *** MAX *** > > > Section 2.7 > > > There exist operationally open network wherein devices gain > > > nit: "networks" plural > > fixed. > > > unauthenticated access to the internet at large. In these use cases > > the management domain for the device needs to be discovered within > > the larger internet. These are less likely within the anima scope > > but may be more important in the future. > > > nit: less likely than what? > > changed to: > The case where a device can boot and get access to > larger Internet are less likely within the ANIMA ACP scope but may > be more important in the future. > In the ANIMA ACP scope, new > devices will be quarantined behind a Join Proxy. > > > In order to support these scenarios, the pledge MAY contact a well > > known URI of a cloud registrar if a local registrar cannot be > > discovered or if the pledge's target use cases do not include a local > > registrar. > > ben> I don't see the connection between "configure itself to become the > ben> local registrar" and "contact a well-known URI of a cloud registrar". > > In a completely Greenfield situation, where there is no local infrastructure > at all, given an appropriately magic "Intent" (remember where this WG > started...), then a cloud registrar could inform a device that it is > to become the Registrar. How this would work depends upon the details > of the magic unicorn Intent (see failed SUPA WG). Ah. So the cloud registrar is an extra-featureful registrar that can do more than just register things. I get it now, but am not sure how to best word it. > > If the pledge uses a well known URI for contacting a cloud registrar > > an Implicit Trust Anchor database (see [RFC7030]) MUST be used to > > authenticate service as described in [RFC6125]. This is consistent > > ben> Would this be more likely to be installed by the manufacturer or > ben> device owner? > > Manufacturer, as it's implicit. That's how EST works today. So you think "implicit" is enough and adding something like "burned-in" or "manufacturer-assigned" is overkill? > > nit: "service" needs an article. > > add "that" > > > Section 2.8 > > > approach if they ensure a single MASA URL works for all pledge's > > associated with each trust anchor. > > > nit: "pledges" non-possessive > > Seems pledges should be plural to be. > Changed to: > This is useful for Registrars which are servicing pledges on directly > connected networks.or plural > > > Section 3 > > > A pledge forms the "pledge voucher-request" and submits it to the > > registrar. > > already fixed. > > > The "proximity-registrar-cert" leaf is used in the pledge voucher- > > requests. This provides a method for the pledge to assert the > > registrar's proximity. > > > "proximity" in what sense? How much verification/confidence needs to be > > done? (Also, I would have expected the assertion to go the other way; > > that the registrar asserts the pledge's proximity -- how does the pledge > > have a way to know that the registrar is nearby when the proxy is > > transparent?) > > There is a TLS connection between them. Yes, it could go anywhere. > The proxy was link-local, and the proxy pointed the connection at the > Registrar. I guess it would be useful if the proxy was stateful, and > contributed another cryptographic layer for non-ACP cases. > > In the ACP case, the Registrar knows it can trust the proxy because it's on > the ACP, and is connecting from an ULA address that is part of the ACP. > > Yes, the Registrar could be anywhere, but the proxy makes it appear > to be on the local link. > > I'm not sure what else I can add to the text. "There is a TLS connection between a and b" says almost nothing without some additional context -- there are millions of machines I can make a TLS connection to from here. I assume that the unstated context here is that the pledge is expected to be in a limited-connectivity environment, so the fact that the network allowed the connection through to the registrar conveys meaning. But I don't remember anything in this document that actually validates that the pledge really is in a limited network environment. Could some rogue node ("attacker") be trying to talk to a proxy or registrar directly, from somewhere else in the network? How would we tell? > > Section 3.3 > > > Example (1) The following example illustrates a pledge voucher- > > request. The assertion leaf is indicated as 'proximity' > > and the registrar's TLS server certificate is included > > in the 'proximity-registrar-cert' leaf. See > > Section 5.2. > > > { > > "ietf-voucher-request:voucher": { > > "nonce": "62a2e7693d82fcda2624de58fb6722e5", > > "created-on": "2017-01-01T00:00:00.000Z", > > "proximity-registrar-cert": "base64encodedvalue==" > > } > > } > > > I do not see an 'assertion' leaf populated. > > added. > > > Example (2) The following example illustrates a registrar voucher- > > request. The 'prior-signed-voucher-request' leaf is > > populated with the pledge's voucher-request (such as the > > prior example). The pledge's voucher-request is a > > binary object. In the JSON encoding used here it must > > > Why is it a binary object? We just saw a previous example with a JSON > > (non-binary) encoding. (Hint: CMS-signed,but we didn't say that.) > > okay, I'll say that. > > > There is (again) no assertion, and the created-on does not match > > exactly. > > added. > > > Section 3.4 > > > The RFC 8174 version of the BCP 14 boilerplate could be used in the > > module, too. > > Also, is the 2017 copyright still correct, especially given that it is a > > 2018-02-14 revision? > > already fixed. > fixing date. > > > For example, a pledge might sign a voucher request > > with a proximity-registrar-cert, and the registrar > > then includes it in the prior-signed-voucher-request field. > > > nit: maybe "includes it" could be disambiguated (perhaps s/in/as/)? > > okay. > > > This is a simple mechanism for a chain of trusted > > parties to change a voucher request, while > > maintaining the prior signature information. > > > "chain" seems to admit the possibility of more than one > > modification/resigning event, but the architecture as described seems to > > only have the registrar doing this. > > Yes. prior-signed-voucher-request could be used in new ways. > > > registrar agree on proximity assertions. The MASA SHOULD > > remove all prior-signed-voucher-request information when > > signing a voucher for imprinting so as to minimize the > > final voucher size."; > > > (side note?) This removal would open up some minor exotic attacks in > > cases where a pledge reuses an existing nonce (potentially from a > > different device), but is probably an okay tradeoff to make. > > agreed. > > > The first certificate in the Registrar TLS server > > certificate_list sequence (see [RFC5246]) presented by > > the Registrar to the Pledge. This MUST be populated in a > > Pledge's voucher request if a proximity assertion is > > requested."; > > > 5246 is replaced by 8446. > > okay. Annoying to have references in the YANG module itself. > > > It might be simplest to just say the "end-entity TLS certificate", at > > least for TLS practitioners. (Maybe nof for a different audience, > > though.) > > How do I know that a proximity assertion is requested? > > That is, How does the pledge knows it wants one? > Because it's been programmed that way. > I have removed "if", and replaced it with "when". > I have added the words "end-entity TLS certificate" to hammer the point. > > > Section 4 > > > The role of the proxy is to facilitate communications. The proxy > > forwards packets between the pledge and a registrar that has been > > provisioned to the proxy via GRASP discovery. > > > [same DULL question as above] > > It's not DULL, because this is the Proxy speaking within the ACP. > I will write "full GRASP". > > > The proxy does not terminate the TLS handshake: it passes streams of > > bytes onward without examination. A proxy MUST NOT assume any > > specific TLS version. > > > Passing bytes without examination is by definition not assuming any > > version of TLS. So while I think it would make the most sense to just > > remove that sentence, if it's going to say it might be worth also > > noting the TLS invariants discussed in > > https://tools.ietf.org/html/rfc8446#section-9.3 . > > added reference. > > > Section 4.1 > > > through a proxy. The proxy is transparent to the pledge. The > > communication between the pledge is over IPv6 Link-Local addresses. > > > nit: between the pledge and what? > > Join Proxy added. > > > M_FLOOD. The active methods SHOULD exponentially back-off to a > > maximum of one hour to avoid overloading the network with discovery > > attempts. Detection of change of physical link status (ethernet > > carrier for instance) SHOULD reset the exponential back off. > > > Mathematically, "exponential" requires to specify the base of the > > exponent (or just say "by doubling"). (Also later in the section.) > > Well, of course the base should be "e" :-) > I'll write doubling. > > > Once all discovered services are attempted (assuming that none > > succeeded) the device MUST return to listening for GRASP M_FLOOD. It > > SHOULD periodically retry the manufacturer specific mechanisms. The > > pledge MAY prioritize selection order as appropriate for the > > anticipated environment. > > > nit: "manufacturer-specific" takes a hyphen > > not-nit: what are "the manufacturer-specific mechanisms"? (I don't > > remember such discussion yet.) > > 1) Appendix A and Appendix B. > 2) a bunch of manufacturers have proprietary equivalent of BRSKI. > I think that this includes both Cisco and Juniper. > > > Section 4.1.1 > > > Is Figure 6b supposed to be using JSON diagnostic notation for CBOR or > > some other notation? > > Also, I'm not sure that picking an arbitrary (representative) session-id > > value, LL address, and port is helpful when describing the formatting of > > the message. Maybe some different introductory text would change > > things. > > I have placed the example after the CDDL. > > > Section 4.3 > > > If we're only defining an EST-TLS objective, how will proxies know that > > the registrar supports BRSKI? > > > It's a little weird to put the reference for GRASP but not ACP. Either > > none or both would feel more natural (given that we've seen both already > > a couple times). > > The name is "AN_join_registrar", which implies BRSKI. > The objective-value of "EST-TLS" means EST. (vs CMP or some other enrollment > mechanism that people have asked for). There could be many announcements > From different things. Ah, I was misparsing the diagnostic notation, sorry. > This announcement and the Join Proxy described here only applies to ACP. > > Added: > > This section applies is normative for uses with an ANIMA ACP. > The use of GRASP mechanism part of the ACP. > Other users of BRSKI will need to define an equivalent proxy > mechanism, and an equivalent mechanism to configure the proxy. > > > the beginning of section 4. and thank you for the clarification! > > Section 5 > > > MASA URI is "https://" iauthority "/.well-known/est". > > > nit: "The MASA URI". > > Is this always the case, with no opportunity for modification, even as > > included in an IDevID certificate extension? > > Either just the iauthority (now "authority") is present in the IDevID, or the > entire URL (with ports numbers and paths) is present. I think that is what > you want. > > > BRSKI uses JSON [RFC7159] for all new operations defined here, and > > > RFC 7159 is obsoleted by RFC 8259. > > already fixed. > > > While EST section 3.2 does not insist upon use of HTTP 1.1 persistent > > connections, BRSKI-EST connections SHOULD use persistent connections. > > The intention of this guidance is to ensure the provisional TLS state > > occurs only once, and that the subsequent resolution of the provision > > state is not subject to a MITM attack during a critical phase. > > > I think we probably want a requirement that if persistent connections > > are not used (and what about HTTP/2 or HTTP/3 ones?), the pledge MUST > > check that the exact same certificate is used to authenticate the > > registrar for all transactions. If the signature in the handshake is > > valid but you can only chain the certificate up to your trust anchor > > once you finish imprinting, you still know that the entire session's > > data has been talking to the now-authenticated party (as opposed to the > > TLS case where you try to add a new certificate mid-connection, where > > that boundary is unclear), but things are much easier to reason about if > > you are sure that each EST transaction is talking to the same peer. > > We had a conversation two years ago about what we might need to say about > HTTP/2, and aside from being unable to handle QUIC (due to proxy), we don't > see any issue. > > I have added: > > If non-persistent connections are used, then both the pledge and > the registrar MUST remember the certificates seen, and also sent > for the first connection. They MUST check each subsequent > connections for the same certificates, and each end MUST use > the same certificates as well. This places a difficult restriction > on rolling certificates on the Registrar. > > > But, that's why we have SHOULD, and the SHOULD (vs MUST) part was really to > allow for some fancy HTTP/3 we know nothing about :-) :) Do we still want to say "HTTP 1.1 persistent connections" vs. "HTTP persistent connections", though? > > o In the language of [RFC6125] this provides for a SERIALNUM-ID > > category of identifier that can be included in a certificate and > > therefore that can also be used for matching purposes. The > > SERIALNUM-ID whitelist is collated according to manufacturer trust > > anchor since serial numbers are not globally unique. > > > RFC 6125 does not define a SERIALNUM-ID, so maybe we could reword to "in > > the model of RFC 6125" or "provides a new SERIAL-ID category" or > > similar. > > I have an open request to *** MAX *** to clarify this part. > > > o The registrar performs log verifications in addition to local > > authorization checks before accepting optional pledge device > > enrollment requests. > > > Maybe give us a section reference to what the "log validations" are? > > We decided that we did not have enough experience to write normative language > here. (It's not an Internet Standard) It doesn't have to be normative, but some discussion of things that might come into consideration during that process could still be useful. -Ben > > Section 5.1 > > > Establishment of the BRSKI-EST TLS connection is as specified in EST > > [RFC7030] section 4.1.1 "Bootstrap Distribution of CA Certificates" > > [RFC7030] wherein the client is authenticated with the IDevID > > certificate, and the EST server (the registrar) is provisionally > > authenticated with an unverified server certificate. > > > I'd consider noting that the signature (or other operation) made by the > > certificate must be validated, and that the received certificate and > > chain must be retained for later validation. > > Added: > > The signatures in the certificate MUST be validated even if a > signing key can not (yet) be validated. The certificate (or > chain) MUST be retained for later validation. > > > A self-signed > certificate for the Registrar is acceptable as the voucher > will validate it. > > > > > The pledge maintains a security paranoia concerning the provisional > > state, and all data received, until a voucher is received and > > verified as specified in Section 5.6.1 > > > Since section 5.6.1 just talks about the voucher verification process, I > > think we need to say more about what "security paranoia" entails: > > acknowledging that all data transmitted is sent to an unauthenticated > > peer, with corresponding privacy considerations, and that all received > > data is not authenticated by the TLS connection and must be > > self-authenticating or otherwise considered untrusted. > > > The pledge code needs to be written with the assumption that > all data is being transmitted at this point to an > unauthenticated peer, and that received data, while inside a > TLS connection, MUST be considered untrusted. This > particularly applies to HTTP headers and CMS structures that > make up the voucher. > > > > > A pledge that can not maintain as many connections as there are > > eligible proxies. If no connection is making process after 5 seconds > > > nit: that's not a complete sentence. > > already fixed to: > > A pledge that can not maintain as many connections as there are > eligible proxies will need to rotate among the various choices, > terminating connections that do not appear to be making > progress. > > stopping here for today. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > From nobody Fri Aug 9 16:23:28 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09D1120059; Fri, 9 Aug 2019 16:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 5tbkDOCYW8M3; Fri, 9 Aug 2019 16:23:25 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (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 5B63E120048; Fri, 9 Aug 2019 16:23:25 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id l21so46562894pgm.3; Fri, 09 Aug 2019 16:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mRvP4fxDkqwc47GeG2Gj1s7lTKTDoIvCIvMoDBv7gqc=; b=aNhdvlr766Sxw6m8rFFhuMNcr7DazVs//mCbxUiYPr1YV+l0dCfKKfJXDUgg2MMYOy JSsAy8vzgS4pu9RhiRyijGLiyEmy5xHKYSJcX3PPmYOILCmzuS1yJ0EtptCPtVB0B5ie qRkUNkwNKm0QZkVplaNEGhqrNV/SzzSSm319QFQf0jjsa425/P0gSOKzBWBVwqhjA0qh swyxfzXQ9nccuRITmrA/Jqp31QVp5g4hNtotm4IWb1Yosz+yEAPLSC9a4B7ciRz7qGQ6 hEa1X2L5wuBRFbognjPJgOn4jugPtds2ViyN/Ov7OanPF5l9EOiuhCkQYGJ6EkUmo7S1 O/PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mRvP4fxDkqwc47GeG2Gj1s7lTKTDoIvCIvMoDBv7gqc=; b=bG721vH+LS0Qb+dFQAOKGVwmKiPqm+8kmRK0FZq5157trlWVOZ/2Yi5vb2a102kPVe RQuwkRO956jOZ395+LS8y1Bdyh6RUK9+e8FUA+OFNVGi1d5WmT1yM4OtN3V7GrWteKV2 13SSIjAQJXVjxPiW+juK8s51KqszgGKloE2rqj+LQeIS23KYm0gRKT85wuJ6AZr87CgK j2CKu8RUul8yLh3oo9EPnqOaTsTFFKMG4Z8hExrwkntgHQCnjaSiQ/3WHYSogahbAzrf 3W4rC/YTQLKuA1Efs4uyNTF+UA6hg4vDqKYHYVHCf8cSMAOl8eGulQeuGSl1Ywr0MZts c3CA== X-Gm-Message-State: APjAAAWKldBUTL59xI0sDw22UShypNVwVC3wYJikp5xu6rjpPcyDCnYg H4mjGpbB6UV5mTRRaAaBarpbZFz8 X-Google-Smtp-Source: APXvYqyhfS6lDuutU4Zl74SGq6bKrVR9e9aLM5HVb3hYQiKRzYMsXUyOgrzTd23P4yqLXBGpxLnWEA== X-Received: by 2002:a05:6a00:5d:: with SMTP id i29mr1216738pfk.57.1565393004408; Fri, 09 Aug 2019 16:23:24 -0700 (PDT) Received: from [192.168.178.30] ([118.148.73.254]) by smtp.gmail.com with ESMTPSA id 10sm4433257pfv.63.2019.08.09.16.23.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Aug 2019 16:23:23 -0700 (PDT) To: Toerless Eckert , draft-ietf-anima-grasp-api@ietf.org Cc: "anima@ietf.org" References: <20190809194328.6232pr2w2giuq2ur@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: Date: Sat, 10 Aug 2019 11:23:20 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190809194328.6232pr2w2giuq2ur@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Anima] comments on draft-ietf-anima-grasp-api X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2019 23:23:28 -0000 Hi Toerless, Jus to focus on what to me is a key point: > More interestingly, i would be a great fan of talking about the > API between library and core, to justify why we want to think about > this modularity. If there was only one operating system in the world, I guess we could describe this. The challenge I see is that the way to solve this may be drastically different in different o/s environments, depending on what sort of IPC is available between contexts. So apart from saying that an implementation needs to do this, I'm not sure how much we can say= =2E I did try to build an IPC interface into my Python implementation, but the only way I could see that produced portable code was to use a standard socket as the IPC mechanism. That works, but it's pretty clumsy and seems very inefficient for production use. However, it did show me that you are correct. There are some GRASP functions that really need to be in a daemon** because they run on their own even if there's no ASA in the node, and others that need to be callable from multiple ASAs. The API as currently defined only concerns those callable functions. You're actually asking for the scope of the API draft to be expanded. 2nd level however: The daemon and the callable functions need to share some common stateful data structures, which I suppose are somewhat implementation-dependent, but the ones I found necessary are: _asa_registry =E2=80=93 where ASAs are registered _obj_registry =E2=80=93 where objectives are registered _discovery_cache =E2=80=93 where locators for discovered objectives are c= ached _session_id_cache =E2=80=93 where GRASP sesssion ids and ASA nonces are c= ached. _flood_cache =E2=80=93 where flooded objectives and their values are cach= ed. ** In fact I needed to provide a way to activate such a daemon, because Michael and Bill discovered that they needed to do so by hand during the hackathon last month. It's called gremlin.py and contains 4 lines of code. Thanks Brian P.S. We'll wait for Guangpeng's promised review before we revise the draft. On 10-Aug-19 07:43, Toerless Eckert wrote: >=20 > Hi Brian, * >=20 > I have right now primarily a high level comment: >=20 > The problem i have with the three layers of GRASP is that there > is no good justification why they exist and why the API document > needs to bother about them. The doc really only talks about the > library of the GRASP Library. >=20 > This is not to say that i do not like the idea to talk about the > modularity of a GRASP implementation, its just not well motivated > and executed i feel. >=20 > So, one way to solve this is to also talk about the other APIs. >=20 > For the extended function module, one could for example say > any extensions to GRASP that are CAN BE implemented on top the > GRASP API defined in this document SHOULD be implemented as > a GRASP Function Module. And examples could be the functions > suggested in my DNS drafts, or ther drafts you have that fit. > So, thats the simple part. >=20 > More interestingly, i would be a great fan of talking about the > API between library and core, to justify why we want to think about > this modularity. >=20 > This is where the outline could be something like the following: >=20 > Any peer-to-peer GRASP connection could and should be implemented > in the context of the ASA, such as in a library compiled into the > application. The reason is that this allows for greater=20 > confidentiality and mutual authentication then if it went through > the GRASP core. Aka: any unicast message can ultimately have > an originator authentication if the security and transport substrate > used supports this. Which ACP does (TLS for ACP GRASP unicsast). >=20 > On the other hand, all the multicast messages and the hop-by > hop flooded unicast replies will have to be seen by each intervening > nodes non-ASA specific GRASP core code and hence needs to be implemente= d > in a common component called he GRASP core. For examplanation, the > terms "system level" or "daemon" could be used. >=20 > So as far as GRASP messages are concerned: > ASA(GRASP-library)<->GRASP_core -link- GRASP-core -link- ... ASA > M_FLOOD: hop-by-hop 'multicast' > M_DISCOVERY: (constrained) hop-by-hop multicast > M_RESPONSE: hop-by-hop unicast >=20 > ASA(GRASP-library)<-...(TLS)...->ASA(GRASP-library) > all unicasted messages except M_RESPONSE sent in > reply to a multicast received M_DISCOVERY. >=20 > So, there is a bit of work to do to go through the remainder > of the document and figure out what to say about how each of > the proposed API calls would operate at the GRASP API layer and > at the GRASP_CORE layer. The way i imagine it, the API would > be the same for both GRASP Core and GRASP Library except that > i think we need to check which of the API calls need another > (optional) locator parameter, because the whole goal of the exercise > is that the GRASP library would create its own unicast GRASP socket(s) > (e.g.: TLS) and that socket locator would need to be passed on via the > API calls to the GRASP core where needed. >=20 > And when that locator option is not given on the according API > calls, then the unicast would go across unicast sockets created and > kept only inside the GRASP Core . Which means that the GRASP > libary would also be optional, but if an ASA runs directly > on top of GRASP core only, then it would expose all > potentially confidential objective value stuff to that > shared GRASP core code. >=20 > Also: When an ASA runs in an environment where it has cached > its relevant peers locators, then it can operate without > relying on the discovery service parts of GRASP and hence also > without any GRASP cores involved, arguably making a service > built on such ASA more resilient and maybe less prone to attacks. >=20 > So, let me know if we can get this IMHO important high level aspect > into the doc. If not, and if also can not find another reason to > talk about a standardized API to the GRASP core then that text > should better be moved to a non-specification section (informative > only, appendix, etc. pp.) >=20 > Cheers > Toerless >=20 From nobody Sat Aug 10 14:16:12 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4DD120121; Sat, 10 Aug 2019 14:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 fFEt5D9I6-Be; Sat, 10 Aug 2019 14:16:00 -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 274CC12007A; Sat, 10 Aug 2019 14:15:59 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id E17F73818F; Sat, 10 Aug 2019 17:15:15 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8CA72C00; Sat, 10 Aug 2019 17:15:57 -0400 (EDT) From: Michael Richardson To: Jack Visoky , "Randy Armstrong \(OPC\)" , "iot-onboarding\@ietf.org" , "anima\@ietf.org" In-Reply-To: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> <4671.1565279232@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Aug 2019 21:16:02 -0000 --=-=-= Content-Type: text/plain Jack Visoky wrote: > I am also involved with OPC-UA and would like to provide my/my > company's perspective. One of the major drivers of this engagement > with the ANIMA group was a contentious point around whether or not TLS > and EST are required for support of BRSKI. Some of us had taken the > position that these technologies are an integral part of BRSKI and > shouldn't be replaced with OPC specific methods, especially given the > benefit of using highly adopted security technologies, as well as the > tight coupling of BRSKI to these. So, I think the idea that OPC should > just use these technologies is very much a viable answer. If the device is powered or has enough battery to do 802.11, then it probably has enough power and code space to do TLS (particularly mbedtls from ARM). If it's on a very low duty cycle on battery, and/or it does 802.15.4, then the question is still open. The IETF may start work on a 802.15.4 specific AKE, (see lake@ietf.org). We believe we need these for 6tisch (TSCH mode of 802.15.4 for deterministic industrial networks) It appears that the OPC UA methods provide enough security to do BRSKI, but there are significant benefits to not maintaining your own protocols, and significant benefits to getting the extensive review that TLS gets. > Also, I would strongly push back on any claims that low end OPC devices > cannot support TLS. Other industrial protocols have already added TLS > support and are shipping products, including those with TLS client > functionality. TLS is no more heavy-weight than existing, OPC-specific > security mechanisms. The OPC-specific mechanism appears to avoid a DH operation and therefore lacks PFS. I understand it uses RSA, which means that it's significantly more expensive than TLS with ECDSA (and ECDH) would be, and most SOCs have hardware acceleration for ECDSA's secp256v1, fewer have RSA acceleration. > In any event I will be sure to join the call that has been set up for > later in August. Awesome. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1PNA0ACgkQgItw+93Q 3WUVxggAnMgKkTMu3ibzjZfZ5TwJmVje7JiEe3U3t24cKMFswvCxrBGz/dy4e0U4 Fn4rhBT+8VAljawf3G6bpWpb920TJhCiJRl9/T5RpgrxTUZnGInGmZakRmaGi5bF M0kXDZgHSxFyCXWWPPzYD99zc//G2S3k8i2uZqubKwiDsF5uG3YrChiWWkIdTPKL 0VEgARGuefnILbXkfBhgmNHO6iqNG1H/7ukx6AZ6LHc1YdjuNA2szIDd/KF36FHx hTjVHD8QAr2v062SCFmWm2pEs8Vg2u9Wcgbgaq8/+aoIc6wqn6SjAyd3cSJq5Ffm 3Qufd07qtW+p0/JTHBgGm6p1PmYwAg== =ITj9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 10 17:57:33 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59425120945; Sat, 10 Aug 2019 17:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=opcfoundation.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 kLAx9CtjHyY3; Sat, 10 Aug 2019 17:56:01 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760054.outbound.protection.outlook.com [40.107.76.54]) (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 5420F1208A5; Sat, 10 Aug 2019 16:26:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bsuWzhON0P6+P4vyJ7obQt/z36SgNnZaI6RLm+EhokYW2jphcoQwRliDEfgkdggStBsNDvT8WMvZ+7MIcR3OnDpS3DVIkxJ6lEKWEgpseIftSmNeDBafSG2ePEad1hFdxPc7xhs9r2YjzZ+eVObWuJ1/OciZ1u+rXoFz+S1pSu0tMsuOBa7yErpQHC+LYxL6vm2iZYVnBhMFNSCxM52Y2ulHfX9F6EUgzmgU7RCsyH/yusmvtGIJosFeHGVqMA+PxIEIssY7edBX0gGrgzvBnN7JgRgd89ZwqbJYt5vDcDTUh3HuK9EGvksR0r4/MbrBT0sBfVBudrEPEgZbVbSHVw== 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=B8j+JKEyw+RbTFCKo6fmfkx43RK4++Z9AGqtoZJICI0=; b=dWIJETxZL1/zIi/pm1TkZ6UjqQGdP9OMmbfsqJJVVB2CX9jhFH9IzD0zcbeQwIH/nYoLFiV973HOwocFv1yju9ywTEudwTjujJS9/YakalockZKJ83g3tMgha3HCnr++n6GazCNYxfbIfG1/oRC2Lz+Gv+WNu1V3DG8n4fWrklqk9puId/08VHekYOElE3kBEk5zfHrGyVoHOzueTzNZBwTfEtmu9uPSd8O/TfJ2JAZZ3aHvxwEC1GQN3FGi6314j9nKrkrQCo/RfJ9wLcMeOutIAgZZw/c/rYnyRCvOhqGtONpF+04GcM2lpTbTwtRir4UOCV/08BrWgQsxveKeWw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=opcfoundation.org; dmarc=pass action=none header.from=opcfoundation.org; dkim=pass header.d=opcfoundation.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opcfoundation.onmicrosoft.com; s=selector1-opcfoundation-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=B8j+JKEyw+RbTFCKo6fmfkx43RK4++Z9AGqtoZJICI0=; b=QmJtWmXv7o4bDvAJ+ssGVCQVaEuZsfv14b27ETLwhHUNpByWbYb8rZcgdphXqchD5BeyvbkGbvef8mSjvc+7Kw699k3EniXN8r9sX+IQOF3bLmFATumHmLwLpxSnWcoYx7wSOjhqaiqhTQuT6GkzSjPc5X4uPtuvxNwOW8d0abI= Received: from BYAPR08MB4903.namprd08.prod.outlook.com (20.176.255.96) by BYAPR08MB5141.namprd08.prod.outlook.com (20.177.125.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.13; Sat, 10 Aug 2019 23:26:13 +0000 Received: from BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53]) by BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53%4]) with mapi id 15.20.2157.020; Sat, 10 Aug 2019 23:26:13 +0000 From: "Randy Armstrong (OPC)" To: Michael Richardson , Jack Visoky , "iot-onboarding@ietf.org" , "anima@ietf.org" Thread-Topic: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI Thread-Index: AdVMZzs5EDHMP+c/QWCVcWuK34MU/QAGrJ8AAADfarAABKcngAAmKcyAAAUDvQAADyfMUAAfy3oAAAGXgVAAOV4vAAA1GsaAAAH8CsA= Date: Sat, 10 Aug 2019 23:26:13 +0000 Message-ID: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> <4671.1565279232@localhost> <19592.1565471757@localhost> In-Reply-To: <19592.1565471757@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=randy.armstrong@opcfoundation.org; x-originating-ip: [24.80.80.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 51202618-5fc9-4ad6-39c0-08d71dea22a7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR08MB5141; x-ms-traffictypediagnostic: BYAPR08MB5141: x-ms-exchange-purlcount: 1 x-ld-processed: 2d8ef4e4-d41c-489c-8004-bb99304b60fe,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 012570D5A0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(39830400003)(136003)(346002)(396003)(199004)(189003)(13464003)(6246003)(229853002)(74316002)(7696005)(53936002)(55016002)(9686003)(8936002)(8676002)(186003)(2906002)(6436002)(26005)(110136005)(2201001)(76176011)(6306002)(99286004)(2501003)(86362001)(14444005)(966005)(316002)(6506007)(6116002)(102836004)(66476007)(508600001)(5660300002)(3846002)(53546011)(66556008)(64756008)(66946007)(66446008)(66066001)(76116006)(7736002)(256004)(33656002)(52536014)(446003)(476003)(71200400001)(14454004)(25786009)(81166006)(81156014)(71190400001)(11346002)(486006)(305945005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR08MB5141; H:BYAPR08MB4903.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: opcfoundation.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: g6Us98gZVVBC+PTwW515g9VFVHu1sLtyS2VAgBCGh3y25wYMlJkm34+qskJttyaHq5qqbunt49qcRVWWoFAdv+D46w9boVOGxX4L7zUA/974iqXaIdqpUyoaWXHSap9qfoyv07bx04lXTDsoyy/R77LJAqw9QMd93IeOpEUS+c1EjVWRtJDP/4CGE3/MacFPWFQon6grI+lp/N6PGyD6Yf/jnwDgTHueJ0MSwh9XqW+wORvHDiT3gVvkjmqb7pQ1upquXNO+001StEsgO8af9pc+4dzcYywtsSeHvJD6nFCrqQJBWgE+uTK+ffE0GUe26S5iX6HJBi3bnhsd3XbjnCzwEbs6zc9x85g3zxsceo3QeCN+P8kDnP4UZmmAjXyNz8wSYVuL8GUD8yPl5Y4x94kuZK419ZmKnVjr9Hv3JXg= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: opcfoundation.org X-MS-Exchange-CrossTenant-Network-Message-Id: 51202618-5fc9-4ad6-39c0-08d71dea22a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Aug 2019 23:26:13.3833 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2d8ef4e4-d41c-489c-8004-bb99304b60fe X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: HpJUrTVFuoyXE0X9T4jQHSaiwCt0MzPWq8JKq4q+URiFVJXB8Ig3IWKJ8p16DY6OtCChQaC4L44/geVYvWHbJ7YZygosNbE3O+UPa16k4K/ocYHDTtOunQ33+7Id3W1a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB5141 Archived-At: Subject: Re: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2019 00:57:31 -0000 > If the device is powered or has enough battery to do 802.11, then it prob= ably has enough power and code space to do TLS (particularly mbedtls from A= RM). The issue is more the additional libraries needed to support this functiona= lity. For companies like Rockwell, which have heavily invested in CIP over = TLS, these libraries are already there. For other big automation vendors th= is is not the case. =20 > It appears that the OPC UA methods provide enough security to do BRSKI, b= ut there are significant benefits to not maintaining your own protocols, an= d significant benefits to getting the extensive review that TLS gets. OPC UA security is end to end security and not tied to specific transport w= hich is preferable from an architecture perspective. While the wide use of = TLS is an advantage and I can assure you that the OPC WGs have extensively = debated the pros and cons of TLS vs an OPC specific mechanism before we got= to where we are today.=20 > The OPC-specific mechanism appears to avoid a DH operation and therefore = lacks PFS. I understand it uses RSA, which means that it's significantly m= ore expensive than TLS with ECDSA (and ECDH) would be, and most SOCs have h= ardware > acceleration for ECDSA's secp256v1, fewer have RSA acceleration. OPC also has ECDH based policies. These will be used by low end devices. The questions that the OPC WG needs to answer are: 1) Can BRSKI meet our requirements? 2) If the answer to 1) is yes then can it work with OPC UA security? 3) If the answer to 2) is no then do we use TLS or extend our own model wit= h something like BRSKI but not BRSKI? While I cannot predict how the various participants in the OPC WGs will res= pond to question 3), I do know it would make collaboration a lot easier if = the answer to 2) was yes. Regards, Randy -----Original Message----- From: Michael Richardson =20 Sent: August 10, 2019 2:16 PM To: Jack Visoky ; Randy Armstrong (OPC) ; iot-onboarding@ietf.org; anima@ietf.org Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI Jack Visoky wrote: > I am also involved with OPC-UA and would like to provide my/my > company's perspective. One of the major drivers of this engagement > with the ANIMA group was a contentious point around whether or not TL= S > and EST are required for support of BRSKI. Some of us had taken the > position that these technologies are an integral part of BRSKI and > shouldn't be replaced with OPC specific methods, especially given the > benefit of using highly adopted security technologies, as well as the > tight coupling of BRSKI to these. So, I think the idea that OPC shou= ld > just use these technologies is very much a viable answer. If the device is powered or has enough battery to do 802.11, then it probab= ly has enough power and code space to do TLS (particularly mbedtls from ARM= ). If it's on a very low duty cycle on battery, and/or it does 802.15.4, then = the question is still open. The IETF may start work on a 802.15.4 specific= AKE, (see lake@ietf.org). We believe we need these for 6tisch (TSCH mode = of 802.15.4 for deterministic industrial networks) It appears that the OPC UA methods provide enough security to do BRSKI, but= there are significant benefits to not maintaining your own protocols, and = significant benefits to getting the extensive review that TLS gets. > Also, I would strongly push back on any claims that low end OPC devic= es > cannot support TLS. Other industrial protocols have already added TL= S > support and are shipping products, including those with TLS client > functionality. TLS is no more heavy-weight than existing, OPC-specif= ic > security mechanisms. The OPC-specific mechanism appears to avoid a DH operation and therefore la= cks PFS. I understand it uses RSA, which means that it's significantly mor= e expensive than TLS with ECDSA (and ECDH) would be, and most SOCs have har= dware acceleration for ECDSA's secp256v1, fewer have RSA acceleration. > In any event I will be sure to join the call that has been set up for > later in August. Awesome. -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Sat Aug 10 21:02:46 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B37120878; Sat, 10 Aug 2019 21:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, 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 oAwvgTxAEtvc; Sat, 10 Aug 2019 21:01:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B436C120817; Sat, 10 Aug 2019 18:08:31 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 876923818F; Sat, 10 Aug 2019 21:07:47 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 73CF85E6; Sat, 10 Aug 2019 21:08:29 -0400 (EDT) From: Michael Richardson To: "Randy Armstrong \(OPC\)" cc: Jack Visoky , "iot-onboarding\@ietf.org" , "anima\@ietf.org" In-Reply-To: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> <4671.1565279232@localhost> <19592.1565471757@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2019 04:02:45 -0000 --=-=-= Content-Type: text/plain Randy Armstrong (OPC) wrote: > The questions that the OPC WG needs to answer are: > 1) Can BRSKI meet our requirements? I think so; there are some details of resale that BRSKI would like to make out-of-scope for the first document. Some way, we have to deal with it, and I would actually like feedback from OPC about the parameters of different solutions here. > 2) If the answer to 1) is yes then can it work with OPC UA security? yes, I think so. is there any open source reference code for the OPC UA security? > 3) If the answer to 2) is no then do we use TLS or extend our own model > with something like BRSKI but not BRSKI? > While I cannot predict how the various participants in the OPC WGs will > respond to question 3), I do know it would make collaboration a lot > easier if the answer to 2) was yes. I think yes. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1Pao0ACgkQgItw+93Q 3WWdZwgAjRNJ3hjHJG4s81+5X/UptuBtxh+g92nQYx38NrG0nT+9bJ7udoRO7+Ym sFIfh4N/oTLulhr/65BGcCMqvOUShEYyKoBFB1+E8cvoOu29ODeDBncwtszhf4y3 vWspOjk3IEBuXMojyqgt7uJVvkZN7LoDGnsifRNv/wSod9pmHH/GHZSsFU5/VZz+ x5+r+VnJLTwn9Oz3AzaTIfW9L/5In7Sw4Kv6+zNe/jX+9VBaPlmdog+3UZrMEU4z wqh9ZoTlsL0Hbi2n+X6XNr0ngXvz5Ru83/ew1cyQiVlVmZ2utRgVQeLHIMlNsEY7 CO7pamzGu/0pMPOHLeXfTaoOfZslXg== =KY+8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 10 22:49:04 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8240E120A48; Sat, 10 Aug 2019 22:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, 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 E_lkbxOKU8XY; Sat, 10 Aug 2019 22:48:04 -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 C281C12098A; Sat, 10 Aug 2019 19:28:01 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 051163818F; Sat, 10 Aug 2019 22:27:18 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id F06E65E6; Sat, 10 Aug 2019 22:27:59 -0400 (EDT) From: Michael Richardson To: The IESG , anima@ietf.org In-Reply-To: <20190809225540.GV59807@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <23257.1565381837@localhost> <20190809225540.GV59807@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Change of authors for draft-ietf-anima-bootstrapping-keyinfra X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2019 05:49:02 -0000 --=-=-= Content-Type: text/plain Based upon the comment that the author list on the YANG module, and the author list on the document did not match, the authors had a bit of a think on this, and decided that we would remove Steinthor Bjarnason and add Toerless Eckert. ** Everyone was consulted beforehand ** Steinthor Bjarnason originated many of the ideas in the document four plus years ago, but has not been able to contribute to it for a number of years. We prominently acknowledge his contribution. Toerless Eckert made many editorial passes over the past two years and turned himself from document shepherd and co-chair into a regular contributor. As he was also the document shepherd, we had a conversation with our AD about the appropriateness of this change, and got approval. The WG, of course, may have other opinions, as it is the WG's document, and people should not feel shy this. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1PfS8ACgkQgItw+93Q 3WXhJwgAont5rqwe49kre0rmDcbjQgBTrP7ISR0HMDsFmoU6L507qQ6bZN91k5Bp HXLnS9Tw9DrMQ+PHy/TtwESP95XkGQ4i9oVO4zB10bbACjk2w4sBjW9kF3Kddog6 yWAqmJcG1CPcx6L0LSIsrJ/QDrPLHxKhP7VhuUt5+AquIGdFC0GUQoqtdTJzXvNY kEr5quLs81f5ktCO2eMT6Z6Nwd5BlZsA1pqSd8KGK/HhN7X+GPHIrBsA8CRSPac0 sgBKmHce9ILyxOs5/zxcd3rbs1bMPyUoXoIIpqWRGoVl5GbPBw4nM6CF+1q85sxE 3azGk06s+AG/LkfCwNvvwXpIQ3503A== =bS/C -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Aug 10 23:28:40 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3C2120891; Sat, 10 Aug 2019 23:28:37 -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_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=opcfoundation.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 7bH11tgJdoX7; Sat, 10 Aug 2019 23:27:43 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760080.outbound.protection.outlook.com [40.107.76.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 686FA120823; Sat, 10 Aug 2019 19:55:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LDFkkOrqy2vc4uET+VwQ35MtxuN2wJNNRTc+zc8x7AokoQWl/6i4+OC27eh+7l2iRdEJU6dYsFd4yA94usvTRIJMYXltPYLSq9EOi/KXMuD91/E8oIaoggLJkGmZ7IokXrUYoiwkN4kn4vSJLpRkccQudZrq3fv0Q9tTvCgMQL4aU1+ovhjd9+3lPcJxVdtoi2Utz7k2Y/OcaLoYNQKlIrgRiI0D0vXEjNAJqbFfJi9ssssJzkOR8t/nh24u5NRM98WT7QeMtuemvz5LHzNpyx39wvGepLc/ctpg3BhnjabqNGufooGUBwgIiPnd4kQCNIQmMEYWpDt4HpzL9K4Jkw== 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=fR8+KHV7k31dzKU1jAN4A5+FjJD2LSP8ToNLmo/KftY=; b=C/5yWZbhg8NbocAIqcPvgWUoppDOv+k18bp5nf3LpBgdgtGNja7wohSxwhOynifYZzgIU+kRwce3wH8cmCMAnV9VQxI18wpqGwgEI70f5JDRU349yMdZaL192StM8bCYtJxeicpoeRffD4t+lrsUhbM782YxXBF0CwKIkUJt6sGq2r7oWklWvKXDCPZDMIoX3KhvktLZOJBgizsnbFGiVXZOgRRBqaB7ndMi3CLWjne+rMrUtG6kss+xyKcEzopt+0iUrdlSpk2hlmJJoX3Me55FetTpaABUn4cy3i03jXmb33pP+X28oDAfGUGo71F19Wm31uqSTGtpJ3XWEQEvHA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=opcfoundation.org; dmarc=pass action=none header.from=opcfoundation.org; dkim=pass header.d=opcfoundation.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=opcfoundation.onmicrosoft.com; s=selector1-opcfoundation-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fR8+KHV7k31dzKU1jAN4A5+FjJD2LSP8ToNLmo/KftY=; b=EMtBOlQZhqNaawQCJRsD33Xd+nTIDnhe6uCHjAi+YJlrF4fq5CYiWk6KzS+4VtDN00j/kjbdJo4LCDgY18+nk2bLS+fXReb+7HJX1a/dTvgNdpEf9EpcpldZVNb+/6um3zH4XLPJQ4xQ9UdgqRVYJB+fOD7sa5iK0boS2CrhUhk= Received: from BYAPR08MB4903.namprd08.prod.outlook.com (20.176.255.96) by BYAPR08MB5445.namprd08.prod.outlook.com (52.135.241.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.20; Sun, 11 Aug 2019 02:55:43 +0000 Received: from BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53]) by BYAPR08MB4903.namprd08.prod.outlook.com ([fe80::149d:d834:7df3:fc53%4]) with mapi id 15.20.2157.020; Sun, 11 Aug 2019 02:55:43 +0000 From: "Randy Armstrong (OPC)" To: Michael Richardson CC: "iot-onboarding@ietf.org" , "anima@ietf.org" Thread-Topic: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI Thread-Index: AdVMZzs5EDHMP+c/QWCVcWuK34MU/QAGrJ8AAADfarAABKcngAAmKcyAAAUDvQAADyfMUAAfy3oAAAGXgVAAOV4vAAA1GsaAAAH8CsAABiL5gAACgh1w Date: Sun, 11 Aug 2019 02:55:42 +0000 Message-ID: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> <4671.1565279232@localhost> <19592.1565471757@localhost> <15583.1565485709@localhost> In-Reply-To: <15583.1565485709@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=randy.armstrong@opcfoundation.org; x-originating-ip: [24.80.80.10] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 62acf3f0-63ff-4bcb-7ed7-08d71e07669e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(7021145)(8989299)(4534185)(7022145)(4603075)(4627221)(201702281549075)(8990200)(7048125)(7024125)(7027125)(7023125)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR08MB5445; x-ms-traffictypediagnostic: BYAPR08MB5445: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0126A32F74 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(366004)(136003)(376002)(39830400003)(13464003)(199004)(189003)(11346002)(508600001)(476003)(74316002)(305945005)(8936002)(316002)(486006)(54906003)(3846002)(86362001)(6116002)(99286004)(446003)(2906002)(33656002)(66066001)(66946007)(66476007)(76116006)(7736002)(64756008)(6436002)(66446008)(81156014)(81166006)(14454004)(9686003)(66556008)(8676002)(229853002)(55016002)(71190400001)(71200400001)(76176011)(25786009)(7696005)(53546011)(6506007)(102836004)(186003)(6246003)(5660300002)(52536014)(53936002)(256004)(26005)(4326008)(14444005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR08MB5445; H:BYAPR08MB4903.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: opcfoundation.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 0J36+R/PrOOQmUMb1ZCgDqhwhEg+Gr41dHe8i7ig3oosT+zUkP2FusYgQuQ/NMZmhmKf1PO9kLutdxvuWKmvw5e0sO/oYvnighLx1ax/iUPhxqwuUjhYd5Fzlqdmww2zqg+MDzVq8PP2bDDjcxwkK7sJQTp3pkwSG8/SYYt3Uv5Qku5O5G+dEqbc5Hrl7PpwuESJwk75Q4+CCJR45roCpYYoSpJlRNLHdOBiOxaYhTmKgmxcuxpDUvJKNdABmoJ9WFQ/4X+sE/eQ/rCoE4G7DzS8XmJzhWkVYJle4/l526X4nJoEOA2jxhLhDMJbG+uXeWei4lLLLfqaVeTg/2gtwoCzXVcdB/epMcq/aU0LEwlk6mFAEp3Go3vAN+OsLoSY+Ne17x6sVaDI+Y325UvDB1xbTsvU7yXF1Fre9wlsVZ8= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: opcfoundation.org X-MS-Exchange-CrossTenant-Network-Message-Id: 62acf3f0-63ff-4bcb-7ed7-08d71e07669e X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2019 02:55:42.9942 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2d8ef4e4-d41c-489c-8004-bb99304b60fe X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: b3W8BEGF3aIkCSv+JWyCbv/DFW6KEFttvgG1mii+B8UlF8Qgww3F3MMWD0bdRU03+Yq1aWVuXyXGbSbA/0yt0xpUxjM8pS0lU8WiBbK2korUzRsmaevWVtT08ICgg3H4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB5445 Archived-At: Subject: Re: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2019 06:28:38 -0000 > I think so; there are some details of resale that BRSKI would like to mak= e out-of-scope for the first document. Some way, we have to deal with it, = and I would actually like feedback from OPC about the parameters of differe= nt solutions here. There are two things I would like to clarify: 1) As it stands today BRSKI is pull model only and the push model is out of= scope but I don't see why that has to be the case once you allow for diffe= rent protocols between the Device and the Registrar. With our proposed OPC = mapping we would define a Registrar that supports both models. Is this of a= ny interest to the IETF or would it be an OPC only thing? 2) Perhaps the most value from BRSKI comes not from the MASA per se but the= voucher format (i.e. a digitally signed document with a standard format). = We could meet a lot of our requirements if we had a voucher which has a lis= t of nonce-less or bearer vouchers shipped to a particular location for use= by a particular end user. We could create workflows where the manufacturer= /distributor has to create this document when devices are delivered. The do= cument could be delivered via the MASA or via some other B2B exchange or ev= en on a USB stick. However it is delivered it can then be read by the Regis= trar and use it to build a whitelist of Devices allowed on the network.=20 I am also thinking that this voucher would be a good application for block = chain where instead of a bearer voucher we define a mechanism where the own= er the device could append a "block" to the original voucher which authoriz= es the transfer to new owner.=20 -----Original Message----- From: Michael Richardson =20 Sent: August 10, 2019 6:08 PM To: Randy Armstrong (OPC) Cc: Jack Visoky ; iot-onboarding@ietf.org; anima@= ietf.org Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI Randy Armstrong (OPC) wrote: > The questions that the OPC WG needs to answer are: > 1) Can BRSKI meet our requirements? I think so; there are some details of resale that BRSKI would like to make = out-of-scope for the first document. Some way, we have to deal with it, an= d I would actually like feedback from OPC about the parameters of different= solutions here. > 2) If the answer to 1) is yes then can it work with OPC UA security? yes, I think so. is there any open source reference code for the OPC UA security? > 3) If the answer to 2) is no then do we use TLS or extend our own mod= el > with something like BRSKI but not BRSKI? > While I cannot predict how the various participants in the OPC WGs wi= ll > respond to question 3), I do know it would make collaboration a lot > easier if the answer to 2) was yes. I think yes. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Sun Aug 11 01:13:06 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B4B120AFB; Sun, 11 Aug 2019 01:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 mlV2Asi8OCTK; Sun, 11 Aug 2019 01:11:57 -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 F1A82120954; Sat, 10 Aug 2019 21:06:08 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 8870C3818C; Sun, 11 Aug 2019 00:05:25 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9702F266; Sun, 11 Aug 2019 00:06:07 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2019 08:13:06 -0000 --=-=-= Content-Type: text/plain https://tinyurl.com/yylruorn contains an updated diff against -24. Benjamin Kaduk via Datatracker wrote: > Section 5.2 > application/voucher-cms+json The request is a "YANG-defined JSON > document that has been signed using a CMS structure" as described > in Section 3 using the JSON encoding described in [RFC7951]. This > Section 3 does not describe any "sign[ing] using a CMS structure" > operation. Yes, I see, the sentence structure is wrong. I have changed it: - application/voucher-cms+json The request is a "YANG-defined JSON - document that has been signed using a CMS structure" as described - in Section 3 using the JSON encoding described in [RFC7951]. This - voucher media type is defined in [RFC8366] and is also used for - the pledge voucher-request. The pledge SHOULD sign the request - using the Section 2.3 credential. + application/voucher-cms+json [RFC8366] defines a "YANG-defined JSON + document that has been signed using a CMS structure", and the + voucher-request described in Section 3 is created in the same way. + The media type is the same as defined in [RFC8366]. and is also + used for the pledge voucher-request. The pledge MUST sign the + request using the Section 2.3 credential. > To be clear, this is MUST sign, but SHOULD use IDevID (vs. some other > credential) to sign? It was SHOULD, because we supported unsigned voucher requests, but we removed that option. It is now MUST. > constrained voucher formats are expected in the future. Registrar's > and MASA's are expected to be flexible in what they accept. > nits: no apostrophes for plurals. done. > proximity-registrar-cert: In a pledge voucher-request this is the > first certificate in the TLS server 'certificate_list' sequence > (see [RFC5246]) presented by the registrar to the pledge. This > MUST be populated in a pledge voucher-request if the "proximity" > assertion is populated. > [same comment as above about "end-entity certificate"] done. > The registrar validates the client identity as described in EST > [RFC7030] section 3.3.2. The registrar confirms that the 'proximity' > assertion and associated 'proximity-registrar-cert' are correct. > what 'proximity' assertion? > Does verifying proximity-registrar-cert just mean checking that it's the > same leaf certificate that the registrar presented? What happens if the > validation fails? Yes, it means confirming that the pinned certificate is one's own. If it fails, then there is a MITM, and the connection should be closed. {I will use "MITM" until someone tells if me we are using a different term} I've split that paragraph up, as there are two thoughts, one is about the ClientCertificate, and the other is about the pinned certificate. The registrar validates the client identity as described in EST - [RFC7030] section 3.3.2. The registrar confirms that the 'proximity' - assertion and associated 'proximity-registrar-cert' are correct. + [RFC7030] section 3.3.2. + + The registrar confirms that the assertion is 'proximity' and that + pinned 'proximity-registrar-cert' is the Registrar's certificate. If + this validation fails, then there a On-Path Attacker (MITM), and the + connection MUST be closed after the returning an HTTP 401 error code. > Section 5.3 doc> A Registrar accepts or declines a request to join the domain, based doc> on the authenticated identity presented. Automated acceptance doc> criteria include: > I suggest "for different networks, examples of automated acceptance > criteria may include". doc> If these validations fail the registrar SHOULD respond with an doc> appropriate HTTP error code. > Similarly, "If validation fails". done. > Section 5.4 doc> The BRSKI-MASA TLS connection is a 'normal' TLS connection doc> appropriate for HTTPS REST interfaces. The registrar initiates the doc> connection and uses the MASA URL obtained as described in Section 2.8 doc> for [RFC6125] authentication of the MASA. > I'd consider mentioning the implicit trust anchor database as well as > the MASA URL. edits for another review changed this to: The BRSKI-MASA TLS connection is a 'normal' TLS connection appropriate for HTTPS REST interfaces. The registrar initiates the connection and uses the MASA URL obtained as described in Section 2.8. The mechanisms in [RFC6125] SHOULD be used authentication of the MASA. Some vendors will establish explicit (or private) trust anchors for validating their MASA; this will typically done as part of a sales channel integration. Registars SHOULD permit trust anchors to be pre-configured on a per-vendor basis. doc> The MASA and the registrars SHOULD be prepared to support TLS client doc> certificate authentication and/or HTTP Basic or Digest authentication doc> as described in [RFC7030] for EST clients. This connection MAY also doc> have no client authentication at all (Section 7.4) > I don't see discussion of skipping client authentication in Section 7.4. > It would be great to have some, there! It's buried in point 2. I moved text from 7.4 into a new 5.4.1, I created 7.4.1/7.4.2 so that it could be forward referenced. Diff too long here, see link above. doc> The authentication of the BRSKI-MASA connection does not affect the doc> voucher-request process, as voucher-requests are already signed by doc> the registrar. Instead, this authentication provides access control doc> to the audit log. > I don't understand what "access control to the audit log" means. Is the > idea that the TLS client identity in the BSRKI-MASA connection is only > used when processing requests to the requestauditlog endpoint and that > some clients might be denied access? The audit log reveals who owns what. Revealing it to strangers would be a problem. So in order to get access to the audit log for device FOO, one presents a voucher-request for FOO. Since the request contains a serial-number and a mapping to an owner, we use that as an access key to get the audit-log. The identity that the MASA sees in the HTTPS request (ClientCertificate preferred), says who is asking. What can I fix here? > Section 5.5 doc> created-on: Registrars are RECOMMENDED to populate this field. This doc> provides additional information to the MASA. > Earlier we said that this field would be propagated from the pledge > voucher-request; we should probably say something like "populate this > field; if it was present in the pledge voucher-request it is copied > unchanged to the registrar voucher-request; otherwise the current time > is used". That create-on is the time on the Registrar, not on the pledge. It currently says: The registrar populates the voucher-request fields as follows: created-on: The Registrars SHOULD populate this field with the current date and time when the Registrar formed this voucher request. This field provides additional information to the MASA. > nonce: This is the value from the pledge voucher-request. The > registrar voucher-request MAY omit the nonce as per Section 3.1) > I'd suggest "value from the pledge voucher-request, if present" and > changing the second sentence to refer to the pledge voucher-request. I've written: nonce: This value, if present, is copied from the pledge voucher- request. The registrar voucher-request MAY omit the nonce as per Section 3.1. It's up to the Registrar whether to include the nonce. A registrar may issue a voucher-request on it's own, if it is trying to get an offline voucher. > idevid-issuer: The idevid-issuer value from the pledge certificate > is included to ensure a statistically unique identity. > There is no "idevid-issuer" field in the pledge certificate; I assume > this is supposed to be the Issuer Name of the IDevID certificate. Changed to: idevid-issuer: The Issuer value from the value from the pledge IDevID certificate is included to ensure a uniqueness of the serial-number. In the case of nonceless (offline) voucher- request, then an appropriate value needs to be configured from the same out-of-band source as the serial-number. > prior-signed-voucher-request: The signed pledge voucher-request > SHOULD be included in the registrar voucher-request. (NOTE: what > is included is the complete pledge voucher-request, inclusive of > the 'assertion', 'proximity-registrar-cert', etc wrapped by the > pledge's original signature). If a signed voucher-request was not > recieved from the pledge then this leaf is omitted from the > registrar voucher request. > This is a good example of text that implies the signed voucher is > binary. (And as such would be a good place to talk about the base64 > encoding.) okay, done. > All other fields MAY be omitted in the registrar voucher-request. > Should the proximity-registrar-cert field *not* be present? Correct, it's from the pledge->registrar. > Section 5.5.2 doc> The MASA MUST verify that the registrar voucher-request is signed by doc> a registrar. This is confirmed by verifying that the id-kp-cmcRA doc> extended key usage extension field (as detailed in EST RFC7030 doc> section 3.6.1) exists in the certificate of the entity that signed doc> the registrar voucher-request. This verification is only a doc> consistency check that the unauthenticated domain CA intended the doc> voucher-request signer to be a registrar. Performing this check doc> provides value to the domain PKI by assuring the domain administrator doc> that the MASA service will only respect claims from authorized doc> Registration Authorities of the domain. > If the MASA has no prior knowledge of the domain (certificate), this is > susceptible to anyone spinning up something that claims to be a domain > CA and issuing registrar certs with that extension. We need to document > somewhere what other part of the system prevents that from causing an > unauthorized voucher to be used. (Perhaps preventing one from being > issued is not feasible, but acceptable if the pledge will not accept > it, though there remains risk of DoS on the MASA.) The ability for someone to spin up a domain is part one of the ways that the MASA MAY operate in the absense of supply chain integration. The audit-log is the defense against this. If the MASA does not want to do business with such entities, then it just doesn't. > Section 5.5.3 doc> If a nonceless voucher-request is submitted the MASA MUST doc> authenticate the registrar as described in either EST [RFC7030] doc> section 3.2, section 3.3, or by validating the registrar's > Subsubsection references might be more helpful. done. doc> In the nonced case, validation of the registrar MAY be omitted if the doc> device policy is to accept audit-only vouchers. > I don't see any (SHOULD?) guidance about validating the registrar in the > nonced case when other policy is used. Even the previous section does > not really say much to indicate there is value in authenticating the > signature on the voucher request. The signature on the pledge voucher-request is always validated. The signature on the registrar voucher-request is also always validated. What's optional is validating the TLS ClientCertificate/HTTP of the Registrar. I've added a few words to say this. > Section 5.5.4 doc> authentication or voucher-request signature validation. Similarly, doc> as noted in Section 5.5.2, the MASA performs normal PKIX revocation doc> checking during signature consistency checks (a signature by a doc> registrar certificate that has been revoked is an inconsistency). > I think this needs to be noted more clearly in Section 5.5.2. I'll ask *** MAX *** to help here. > Section 5.5.5 doc> The MASA MAY verify that the registrar voucher-request includes the doc> 'prior-signed-voucher-request' field. If so the prior-signed- doc> voucher-request MUST include a 'proximity-registrar-cert' that is doc> consistent with the certificate used to sign the registrar voucher- doc> request. Additionally the voucher-request serial-number leaf MUST > This seems kind of tautological ("if the MASA is checking X, X MUST have > happened"). Also, what does "consistent with" mean? If the MASA is configured to issue nonceless vouchers for this device, then no prior-signed-voucher-request field is needed. If it's there, then it must be valid. doc> match the pledge serial-number that the MASA extracts from the doc> signing certificate of the prior-signed-voucher-request. The MASA is doc> aware of which pledges support signing of their voucher requests and doc> can use this information to confirm proximity of the pledge with the doc> registrar, thus ensuring that the BRSKI-EST TLS connection has no doc> man-in-the-middle. > To be clear, this MITM detection is only for the case of pledges that > sign their voucher requests, right? And it seems to only hold if > pledges that support signing actually do sign, every time. Yes, and also we have removed unsigned, so this is another place we missed a conditional on that. I want to note that the manufacturer knows, by construction, what the behaviour of the pledge is. So I've removed the last sentence completely > Section 5.5.6 doc> The registrar's certificate chain is extracted from the signature doc> method. The chain includes the domain CA certificate as specified in doc> Section 5.5. This certificate is used to populate the "pinned- > I don't think Section 5.5 is the right reference for "includes the > domain CA certificate" (both here and in 5.5.2). It's referring to: The entire registrar certificate chain, up to and including the Domain CA, MUST be included in the CMS structure. I think that 5.5.2 is the right pointer. doc> domain-cert" of the voucher being issued. The domainID (e.g., hash doc> of the root public key) is determined from the pinned-domain-cert and doc> is used to update the audit log. > If the pinning takes the whole cert (per RFC 8366), then what do we need > the domainID for? Just the audit log? Surely in that case SHA-1 is > not a hard requirement... I've changed the domainID definition such that it uses the SubjectKeyIdentifier, if present. That can be any algorithm that the CA wants to use to identify the Entity certificate. We need to have a consistently calculated value if it's not present, and RFC5280 says SHA-1. domainID: The domain IDentity is a unique hash based upon a Registrar's certificate. If the certificate includes the SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be used as the domainID. If not, then the 160-bit SHA-1 hash as described in that section is to be used. This value needs to be calculated by both MASA (to populate the audit log), and by the Registrar (to recognize itself). Does this work? We are only using SHA-1 (for identification, btw, not for resistence to pre-image attacks) as a last resort. I'm looking for a place where I could RECOMMEND that Registrar certificates have SubjectKeyIdentifier added. To 5.1, I have added: section 4.2.1.2 does not mandate that the SubjectKeyIdentifier extension be present in non-CA certificates. It is RECOMMENDED that Registrar certificates (even if self-signed), always include the SubjectKeyIdentifier to be used as a DomainID, and that a hash stronger than SHA-1 be used. > Section 5.5.7 doc> The MASA MUST use the nonce from the registrar voucher-request for doc> the resulting voucher and audit log. The prior-signed-voucher- doc> request nonce is ignored during this operation. > I don't understand this requirement. They could only be different if > the MUST from the previous paragraph is ignored. The Registrar may include no nonce. So I agree it looks weird at this point. I will change this to: The MASA populates the audit-log with the nonce that was verified. If a nonceless voucher is issued, then the audit log is to be populated with the JSON value "null". and I noticed that the audit log asked for the string "null", rather than a JSON null. > Section 5.6 doc> The MASA voucher response to the registrar is forwarded without doc> changes to the pledge; therefore this section applies to both the doc> MASA and the registrar. The HTTP signaling described applies to both doc> the MASA and registrar responses. A registrar either caches prior doc> MASA responses or dynamically requests a new voucher based on local doc> policy (it does not generate or sign a voucher). [...] > Do we need to say how this local caching policy interacts with HTTP > cache control headers? All of the requests are via POST. We are not permitting 201 returns for the voucher-request (with GET to the Location:), so there can be no opportunity to cache. If the Registrar caches a voucher, it would be caching a nonceless one. > I got confused by "or dynamically requests a new voucher" the first > couple times I read it; I landed on something like "when a voucher > request arrives at the registrar, if it has a cached response from the > MASA for the corresponding registrar voucher-request, that cached > response can be used according to local policy; otherwise the registrar > constructs a new registrar voucher-request and sends it to the MASA". I can use your words. Perhaps implicit in this is that there are two ways to build a registrar. The simplest is with a single monolithic application framework, it receives the voucher-request, and then does a synchronous HTTPS request to the MASA. (Perhaps doing 100-Continue). The other way is for the pledge-facing part of the Registrar to put it all into a database, return 202, and wait for another query. Asynchronously some other part sends requests to the MASA and stores the answers back in the database. Perhaps the only thing connecting the two parts is some multi-master database replication... running over UUCP^WDelay-Tolerant-Networking between planets for all we know. > type. The registrar SHOULD use this response if it determines the > pledge is unacceptable due to inventory control, MASA audit logs, or > any other reason. > What does "unacceptable due to inventory control" mean? Such as, device is not in the list of devices that were expected, assuming supply chain integration. > A 415 (Unsupported Media Type) response is approriate for a request > that has a voucher-request or accept encoding that is not understood. > Isn't "Accept-Encoding:" a more typical spelling? Actually, we meant Accept: .. encoding. I've removed the word encoding, because I see that it's confusing. A 415 (Unsupported Media Type) response is appropriate for a request that has a voucher-request or Accept: value that is not understood. > vouchers are described in detail in [RFC8366]. For example, the > voucher consists of: > { > "ietf-voucher:voucher": { > "nonce": "62a2e7693d82fcda2624de58fb6722e5", > "assertion": "logging" > "pinned-domain-cert": "base64encodedvalue==" > "serial-number": "JADA123456789" > } > } > nit: I think "might consist of" is better than "consists of". already fixed. > assertion: The method used to verify assertion. See Section 5.5.5. > The method used to verify itself? Changed to: The method used to verify the relationship between pledge and registrar doc> The pledge MUST be prepared to parse and fail gracefully from a doc> voucher response that does not contain a 'pinned-domain-cert' field. > What would such a graceful failure look like? Reverting back to the > discovery stage, since without a manufacturer-validated indication of > the trust anchor for the domain, the pledge cannot consider itself to > be a part of a domain? changed to: The pledge MUST be prepared to parse and fail gracefully from a voucher response that does not contain a 'pinned-domain-cert' field. Such a thing indicates a failure to enroll in this domain, and the pledge MUST attempt joining with other available Join Proxy. The pledge MUST be prepared to ignore additional fields that it does not recognize. > Section 5.6.2 doc> found. It SHOULD return to the same proxy again after attempting doc> with other proxies. Attempts should be attempted in the exponential > But only if those other proxies failed to produce a valid voucher? yes, inserted "unsucccessful" doc> The pledge's PKIX path validation of a registrar certificate's doc> validity period information is as described in Section 2.6.1. Once doc> the PKIX path validation is successful the TLS connection is no doc> longer provisional. > Section 2.6.1 doesn't actually say that the pledge has to check the five > listed timestamps in the case that it does have a realtime clock. Noted, added text to 2.6.1. > Section 5.7 doc> To indicate pledge status regarding the voucher, the pledge MUST post doc> a status message. > I think we've had other text that implies that providing telemetry is > optional; perhaps just "the pledge POSTs a status message"? The 5.7 Pledge BRSKI Status Telemtry is mandatory. The 5.9.4 Enrollment Status Telemtry is not, because enrollment is not mandatory. doc> The client HTTP POSTs the following to the server at the EST well doc> known URI "/voucher_status". The Status field indicates if the > I think it's probably more clear to write out > ".well-known/est/voucher_status"; there's not a separate registry of EST > well-known URIs. okay. > We don't actually have anything in this section that declares "this is > the structure of the JSON object used as the POST body"; it's only > implicitly provided. I believe that I have reworked this section as a result of other reviews already. doc> indicates why. In the failure case this message may be sent to an doc> unauthenticated, potentially malicious registrar and therefore the doc> Reason string SHOULD NOT provide information beneficial to an doc> attacker. The operational benefit of this telemetry information is > What sort of information might a pledge consider including that would be > beneficial to an attacker? It's hard to say at this point. We want things in the logs of the Registrar that will help avoid a truck roll. IBM (AIX and friends) was historically really good at having really detailed, but often uninformative three digits codes, yet they told AIX support people reams of useful info. > This still have some privacy considerations, though. At this point, the attacking registrar has seen the entire IDevID certificate. I would think that putting the GPS coordinates of the device in the telemetry message would be of course, make things even worse. On the other hand, if a device has a GPS and can not be installed in some places to due some kind of geofencing... > Section 5.8 doc> is posted to the /requestauditlog URI instead. The "idevid-issuer" doc> and "serial-number" informs the MASA which log is requested so the doc> appropriate log can be prepared for the response. Using the same > Is the implicit point that the other fields are ignored? Yes. doc> A registrar MAY request logs at future times. If the registrar doc> generates a new request then the MASA is forced to perform the doc> additional cryptographic operations to verify the new request. > Is this statement just supposed to be further justification for using > the original voucher-request as the POST body, or describing new > behavior? Further justification. The MASA can do a memcmp()/SELECT on a history of raw voucher requests. {that's what my code does} doc> A MASA that receives a request for a device that does not exist, or doc> for which the requesting owner was never an owner returns an HTTP 404 doc> ("Not found") code. > What is a "requesting owner"? I thought devices were owned by the > domain, not the specific registrar. So, if Registrar A has stored a valid pledge-request (or perhaps a falsy constructed one) for a pledge that has joined another network (B), then registrar A can not get a history of the pledge if it was never an owner. If the pledge was once owned by Registrar A (but sold), then there is a hole that would permit Registrar A to ask for history. But this is legitimate, because perhaps it wasn't actually sold, but in fact stolen, and when they can't get the device to respond, the operator could ask if the device has become owned by another Registrar. This interface will likely get future work: some kind of zero-knowledge proof mechanism would be interesting, but we don't know what exactly are the requirements yet. doc> In order to avoid enumeration of device audit logs, MASA that return doc> URLs SHOULD take care to make the returned URL unguessable. For doc> instance, rather than returning URLs containing a database number doc> such as https://example.com/auditlog/1234 or the EUI of the device doc> such https://example.com/auditlog/10-00-00-11-22-33, the MASA SHOULD doc> return a randomly generated value (a "slug" in web parlance). The doc> value is used to find the relevant database entry. > https://www.w3.org/TR/capability-urls/ may also be a useful reference. thanks, added. That's all for today. Will the Joker Get Away? Will the document editor switch to Markdown? Does the YIN/YANG circle converge ever? Can it be rendered in SVG? Stay tuned for tomorrow's exciting episode. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1PlC8ACgkQgItw+93Q 3WVPTgf/U+RKxJLBS24b8nFnDpRc5S1Wc2oIMSoWMMiEg/fZa4MsGhK0eUlOR87e X22uOLKmaHTuSfwxKDuZ+Cen04LKTBCp3RUyZwM4HnHmeGjJ0vfh8lWctId/xw1T qOaR4EdGTJkY/H8MHqssUqS6hiLdZ0Syb3GQSVoXscbEphaGUUH9lUYeTZNqA9Nb z4RfSAgVfN6kEE3E9ecqg886GdoGfwNhw8jzGoyjEMago/QBrYGTsJh6acucSmYh bPFCTn8RlSppu2LNePoEKfVuM9g9Mq2ZHmA2hl2cWbpns40G4skHIeGmmfdM1JG5 ujJZOHzhgCH/2CT5VGUTtn5DkPUVvw== =SYmw -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Aug 11 23:10:21 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C811120975; Sun, 11 Aug 2019 23:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Avlp6hzzxapk; Sun, 11 Aug 2019 23:09:21 -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 B3A361208D4; Sun, 11 Aug 2019 09:49:21 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id CCF56380BE; Sun, 11 Aug 2019 12:48:36 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A5491A51; Sun, 11 Aug 2019 12:49:19 -0400 (EDT) From: Michael Richardson To: "Randy Armstrong \(OPC\)" cc: "iot-onboarding\@ietf.org" , "anima\@ietf.org" In-Reply-To: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> <4671.1565279232@localhost> <19592.1565471757@localhost> <15583.1565485709@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] [Iot-onboarding] EXTERNAL: Re: OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 06:10:19 -0000 --=-=-= Content-Type: text/plain Randy Armstrong (OPC) wrote: > 1) As it stands today BRSKI is pull model only and the push model is > out of scope but I don't see why that has to be the case once you allow > for different protocols between the Device and the Registrar. With our > proposed OPC mapping we would define a Registrar that supports both > models. Is this of any interest to the IETF or would it be an OPC only > thing? There are a number of reasons to think a push model is also workable. I'm unclear if OPC needs to onboard devices into a wireless network or if everything is wired. This matters because the new device has to announce its presence to the Registrar for push to work. For instance, you could take a look at: https://tools.ietf.org/html/draft-richardson-6tisch-dtsecurity-secure-join-01 which is an old version of the constrained-BRSKI mechanism. Section 3, (3.2) explains how the Registrar would reach out to the Pledge using the 6tisch 6p protocol (when it ran over IPv6). > 2) Perhaps the most value from BRSKI comes not from the MASA per se but > the voucher format (i.e. a digitally signed document with a standard > format). We could meet a lot of our requirements if we had a voucher > which has a list of nonce-less or bearer vouchers shipped to a > particular location for use by a particular end user. We could create > workflows where the manufacturer/distributor has to create this > document when devices are delivered. The document could be delivered > via the MASA or via some other B2B exchange or even on a USB > stick. However it is delivered it can then be read by the Registrar and > use it to build a whitelist of Devices allowed on the network. RFC 8572 -- Secure Zero Touch Provisioning (SZTP) may suit you better. It also uses RFC8366 vouchers. > I am also thinking that this voucher would be a good application for > block chain where instead of a bearer voucher we define a mechanism > where the owner the device could append a "block" to the original > voucher which authorizes the transfer to new owner. We considered distributed ledgers for the audit log. In all distributed ledgers, you have to ask: 1) are there mutually distrusting parties? 2) what do they need to agree upon? 3) what is the incentive for a third party to validate the chain? What you have described above, however, is just a certificate chain. No Block Required. https://mailarchive.ietf.org/arch/msg/6tisch-security/2kObJLkLlhuI-HU9s5yqfRm0n00 Describes an early notion of how vouchers work, and notice how it delegates at each step. Subsequent sales just extend the chain. We didn't go this way because: 1) it mandates sales channel integration, and we think that this will be rare at the beginning. 2) any party in the chain can issue a new sale certificate, effectively stealing the device from the current owner. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1QRw8ACgkQgItw+93Q 3WWfjwf+LRD7QcmZT/u3j0F3u3iYM31V7rOA0EsShCqA1K7pWFHNMkiSmNrjacGF k6WSaiXHaHqFnDF25paA29ApheZX9cd5I8suSyzC3NOE5wgvKui19VOvtJsO9ykK YbLTWIDlWKdHSkBFDCbRO8wnENmcqOaoqz/19gqN4wL01tINCNfq95TuwxARgYph yA+RT06uTqvGdh1KAm0MfE0WHJUH1XChsWdOINEbEMjorzMOO1qzzJ/6VCcGRVMl haMj9yUQP/+yarB9YbNtsMk/wsOZFI1L3Alf6w/EQMqUOACYQAVAufv34iBkWSdT sjJw9f6XOLix60EuH9W9BWtKvillmQ== =KR+6 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 12 07:50:38 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7D01217DC; Mon, 12 Aug 2019 07:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=ra.rockwell.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 095uFLo96ecn; Mon, 12 Aug 2019 07:49:33 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760089.outbound.protection.outlook.com [40.107.76.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93D14120F87; Sun, 11 Aug 2019 14:31:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XFbG0/MFJTX+GiLQPtBMgMLO8PnQ8SCftja1kvpzwMW4kNM7jxFQnRnp5DiktalU8b0Me9se5PxJpdcoqgmeoETyr9E+MdCZidYgk97x2b6cVYivo2U06VadrzSvmfyKUQ8oM+RWXiMTZRMYAOQAYokTJqWZiu5uKjCKxomOH458IitDRfJyXkPqeWBv6aUsL2CWiPHRR5zJqMsQh6ZPEQm0Eo9blbb/XTUnDBh98wd/rLK63FsO7sZnBAJ5EpZUbxFJ66gmmxQHwx8m7DSGJIIlE1XImmtOycSXfMEvSesWFrJ54fsFCqgJgJlhACCHhz0V2kFkOfW/TdxJMlje5g== 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=C76gWf5QxUII4NSu8jUjd2PtpVUxoGVU3MJY+FlzF+0=; b=S+XXWshTbsjsHn/HH8cTlWjUsb85T/IwC3LDqMt6Opx9qltRghvmaNUQzNpg7YsOdJ0SjVxodGcN2wCqyjiM2Uba4xgrxqhbNYHdC/SK6qn7rh/F1NPICoko1mRPU2We3voznaldVVvngXBVJelOmomOlQlUQxnEMi7bEtWqUyKArLgs+agI2kvuf93vJcjBj5q73mo+6os4PrilMIugSUIH6OXIiQIlv/WXZrY4LpaDoEg32Fj17g4UFWy89wftLZ+yoOoKke4/T7Kl1mxtfaR7e7DlsXn7L6u526T8AER+7n98mr9WmBykuo/KGaQ1WXWfFytSeoaz7zRA2h4xoA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ra.rockwell.com; dmarc=pass action=none header.from=ra.rockwell.com; dkim=pass header.d=ra.rockwell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ra.rockwell.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=C76gWf5QxUII4NSu8jUjd2PtpVUxoGVU3MJY+FlzF+0=; b=WjNWZqB96UWE4d9vmSJ0s57+uO1fxFs25BtJRgTsXygoJ9knfgUkTWE6oih/kWp2CAd/wOuoTHaK8k1l3gu806MfYQStrXWMVP+Mbe00hjmp96Wm/Yt6YIC59/wFjQ2zIm1y/jATaH8wj3S0joQNkSp9GOJQi7DNezXtnum4EfI= Received: from DM5PR2201MB1340.namprd22.prod.outlook.com (10.172.46.145) by DM5PR2201MB1500.namprd22.prod.outlook.com (10.174.187.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.18; Sun, 11 Aug 2019 21:31:23 +0000 Received: from DM5PR2201MB1340.namprd22.prod.outlook.com ([fe80::ad07:c135:5d24:2d31]) by DM5PR2201MB1340.namprd22.prod.outlook.com ([fe80::ad07:c135:5d24:2d31%5]) with mapi id 15.20.2157.022; Sun, 11 Aug 2019 21:31:23 +0000 From: Jack Visoky To: Michael Richardson , "Randy Armstrong (OPC)" , "iot-onboarding@ietf.org" , "anima@ietf.org" Thread-Topic: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI Thread-Index: AQHVTUS+OPIhCz2qG029dL1PCmEs9qbwawQAgAD7iACAABK3gIABwB5AgAGtr4CAAZZlgA== Date: Sun, 11 Aug 2019 21:31:22 +0000 Message-ID: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> <4671.1565279232@localhost> <19592.1565471757@localhost> In-Reply-To: <19592.1565471757@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jmvisoky@ra.rockwell.com; x-originating-ip: [205.175.240.242] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6238af2f-8d53-4e85-1087-08d71ea34207 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM5PR2201MB1500; x-ms-traffictypediagnostic: DM5PR2201MB1500: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0126A32F74 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(39860400002)(366004)(136003)(376002)(346002)(13464003)(199004)(189003)(229853002)(966005)(55016002)(81166006)(6306002)(478600001)(81156014)(33656002)(6436002)(8676002)(66066001)(110136005)(6246003)(316002)(305945005)(74316002)(2501003)(99286004)(7736002)(25786009)(53936002)(14444005)(11346002)(476003)(186003)(9686003)(486006)(66946007)(66446008)(256004)(64756008)(66556008)(2201001)(52536014)(446003)(5660300002)(8936002)(66476007)(14454004)(86362001)(102836004)(76176011)(76116006)(71200400001)(71190400001)(53546011)(6506007)(7696005)(26005)(3846002)(6116002)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR2201MB1500; H:DM5PR2201MB1340.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ra.rockwell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EQ/bEFeGhk4/sp1h9xXqmXYEqeGtUMSgdU/yjvONwN36eFPalvLkBhwZzWndihTw7N009alytf95wD0YAgVqNyvLPQbu+TAMKUpO+H7JTc0XXMmBOfHX6EZeYEASyfpLRlED1ONF+oWl861NVLChVVQ2V5jsAUXdVp4XUWGlVL8/7jT3LJ+UHHKcNY87FGe103YCLsYxBYKaqAa2wy7JGNMJp7Ufw9nuRN1xaf5gs4ZNhq0ioU7D3RvnnDQCZMqHjECpgpYySxE/2RlG2t3m1i9xrgIOJQroDEvQQoKkhSZXPUY7aln+fpsxVzvAERe5qoCJzieUMfqGkrMNjSTYZ+V2XY36LzdKpfD3sb0VAEA6933FaUwSM+k5E3X4ckOxQ7Yue0JrWgm7Q4GiFV9f0dFuNMRkSqyOf9fWkAE/CDg= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ra.rockwell.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6238af2f-8d53-4e85-1087-08d71ea34207 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2019 21:31:23.1386 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 855b093e-7340-45c7-9f0c-96150415893e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: In5iCfmwzlKo+4i09+J7xDrlsz82Kuy3NQOYQd+6NUKbZP/sD2cPAAMj3jXjjLN592mc3BFmpH/goMK3jP+U/bnotuEz+clJCDZR31FKhS8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2201MB1500 Archived-At: Subject: Re: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 14:50:37 -0000 > but there are significant benefits to not maintaining your own protocols,= and significant benefits to getting the extensive review that TLS gets. I could not agree more with this statement. Thanks, --Jack -----Original Message----- From: Michael Richardson =20 Sent: Saturday, August 10, 2019 5:16 PM To: Jack Visoky ; Randy Armstrong (OPC) ; iot-onboarding@ietf.org; anima@ietf.org Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI Jack Visoky wrote: > I am also involved with OPC-UA and would like to provide my/my > company's perspective. One of the major drivers of this engagement > with the ANIMA group was a contentious point around whether or not TL= S > and EST are required for support of BRSKI. Some of us had taken the > position that these technologies are an integral part of BRSKI and > shouldn't be replaced with OPC specific methods, especially given the > benefit of using highly adopted security technologies, as well as the > tight coupling of BRSKI to these. So, I think the idea that OPC shou= ld > just use these technologies is very much a viable answer. If the device is powered or has enough battery to do 802.11, then it probab= ly has enough power and code space to do TLS (particularly mbedtls from ARM= ). If it's on a very low duty cycle on battery, and/or it does 802.15.4, then = the question is still open. The IETF may start work on a 802.15.4 specific= AKE, (see lake@ietf.org). We believe we need these for 6tisch (TSCH mode = of 802.15.4 for deterministic industrial networks) It appears that the OPC UA methods provide enough security to do BRSKI, but= there are significant benefits to not maintaining your own protocols, and = significant benefits to getting the extensive review that TLS gets. > Also, I would strongly push back on any claims that low end OPC devic= es > cannot support TLS. Other industrial protocols have already added TL= S > support and are shipping products, including those with TLS client > functionality. TLS is no more heavy-weight than existing, OPC-specif= ic > security mechanisms. The OPC-specific mechanism appears to avoid a DH operation and therefore la= cks PFS. I understand it uses RSA, which means that it's significantly mor= e expensive than TLS with ECDSA (and ECDH) would be, and most SOCs have har= dware acceleration for ECDSA's secp256v1, fewer have RSA acceleration. > In any event I will be sure to join the call that has been set up for > later in August. Awesome. -- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Mon Aug 12 08:27:28 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90EAF121A08; Mon, 12 Aug 2019 08:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=ra.rockwell.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6b1DcNYhlhN; Mon, 12 Aug 2019 08:26:08 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820085.outbound.protection.outlook.com [40.107.82.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7268120BD3; Sun, 11 Aug 2019 14:52:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ec7qUQSA3T8RjxKR0bvTinS72OXeKvhTmnB3OK2BfhR526+TLimFsUYb3hrr5s4XhjjeUdq2X062oMSmRgObhiGLtLayDgojGmFDYjEDSDQIebdUUh6liC0aLOBsL7mVuYREVmxfqNfzcpJtEWAnF0+bdDEU4zp7JOgLbznarJbZBMwEZtJfQjTg/TsPNqKCjEmH7uQ9QJZcEBmINvCkGBRlS7IFSnmxJvKWuadC1EoEBI3LG0je2GIOX6V5BlKvDCZjAW2Gwvk2dg6KnKztpriICiNR5GkTQEQg90SojaEMIPP7zhIdiz3H6LrdzqnS5HHTGlqHDG/gHfyrFWJbvA== 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=zRQayZfoiwd8o/eSNqZGy3icANvE8OZf0p9aayYv4Vg=; b=LmCkPVZhsET6FKDgLNr/u4kN7dqj7yR5GoqF77ZefB0npPIM+AAi4VOGf2zGYLdPVZRpcVgNrn1qLKI7hp/CkEZRO0T+aW6qKDZbCs7zaYtA78ZqquY2T7fUh9YvISnHBaDxadsAscs/LblyGG40Cls75pZ9YHW5/TInVVBaD4YHKI8oHSM+gDKqNri5fkpWB3My4vsvqgta8lvFyk5C/ScLBbUkeet4Dsb3rHKMQ05yN4QvT+deQutRbrTgstDleIF9ScUEwHu50ALqyj1lMSVGoRvtMN9ccHsfzRDh+aTSfL+uhgFubj/MKxR2F5AhHf7rI/tVWd7DUihnrrdwJQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ra.rockwell.com; dmarc=pass action=none header.from=ra.rockwell.com; dkim=pass header.d=ra.rockwell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ra.rockwell.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zRQayZfoiwd8o/eSNqZGy3icANvE8OZf0p9aayYv4Vg=; b=SExUcW2DFNj6DciOo2jCL5gikPCnnQEyZjSfajNoetGameQgk3ZNVw9BLpdzwwLD7iLus331/tAbkE2gSIs8zhnbQKaSsqoftodZABOljHksZuGMcr0e2Iv5oIoI/h7FXfBkhI0UEmn55CFneBWAiteMWA0vrB2u/4yxeNlCDEI= Received: from DM5PR2201MB1340.namprd22.prod.outlook.com (10.172.46.145) by DM5PR2201MB1083.namprd22.prod.outlook.com (10.174.186.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.21; Sun, 11 Aug 2019 21:52:31 +0000 Received: from DM5PR2201MB1340.namprd22.prod.outlook.com ([fe80::ad07:c135:5d24:2d31]) by DM5PR2201MB1340.namprd22.prod.outlook.com ([fe80::ad07:c135:5d24:2d31%5]) with mapi id 15.20.2157.022; Sun, 11 Aug 2019 21:52:31 +0000 From: Jack Visoky To: Michael Richardson , "Randy Armstrong (OPC)" CC: "iot-onboarding@ietf.org" , "anima@ietf.org" Thread-Topic: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI Thread-Index: AQHVTUS+OPIhCz2qG029dL1PCmEs9qbwawQAgAD7iACAABK3gIABwB5AgAGtr4CAACRmgIAAHJKAgAFbS6A= Date: Sun, 11 Aug 2019 21:52:30 +0000 Message-ID: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> <4671.1565279232@localhost> <19592.1565471757@localhost> <15583.1565485709@localhost> In-Reply-To: <15583.1565485709@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jmvisoky@ra.rockwell.com; x-originating-ip: [205.175.240.242] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 03ec56fc-bb1e-4164-911a-08d71ea635b0 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM5PR2201MB1083; x-ms-traffictypediagnostic: DM5PR2201MB1083: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0126A32F74 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(39860400002)(346002)(136003)(366004)(396003)(199004)(189003)(13464003)(8676002)(25786009)(33656002)(54906003)(66066001)(6246003)(2906002)(110136005)(81166006)(99286004)(81156014)(71200400001)(8936002)(229853002)(478600001)(6436002)(86362001)(71190400001)(9686003)(53936002)(55016002)(6116002)(3846002)(486006)(26005)(7736002)(14454004)(102836004)(305945005)(66556008)(64756008)(66446008)(7696005)(76176011)(52536014)(186003)(11346002)(476003)(74316002)(446003)(316002)(256004)(14444005)(53546011)(5660300002)(66946007)(76116006)(66476007)(6506007)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR2201MB1083; H:DM5PR2201MB1340.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ra.rockwell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HbsaFsMYHgS3vsI69Z8qEOvNaewtkezjOwKJUEBd+Ykl3KwFkVWb680PyQRTotV58UOcnsaQf2r7zbeB060gV18RZmugQATwQCbPbUa4xZq72L8/2vY7k5hnplhfDl19qmBi/Ss9oI2/4qKrMMGJJDgAaJti3gcmCLficXvPgOSjBGYeJ+u3zhsygUcv7dwFPBZmm0z2u1bPUDtdZUeg/jnKCLG4YnnixxKwRnMs9N2/aXN/Hg9uOwvnpaUIX+gP0bE+S8jtTsNnGYWyoZWhbky/pIFS+hkoFhyGF17tM+CdgRN5GuPhVee3r9J3+fzHaIUyKXYJ1zmeyUblMLODF/ENzqjhKD2i1MqwNLHsrqWbAyogWWk+8xCUcI4d7UVDt9JBhlTct5uhsORJbzOWU3NK6T6QVMxIumm3Kg4nnl4= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ra.rockwell.com X-MS-Exchange-CrossTenant-Network-Message-Id: 03ec56fc-bb1e-4164-911a-08d71ea635b0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2019 21:52:30.9353 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 855b093e-7340-45c7-9f0c-96150415893e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: S3zqETLKotLEJ5hZeLb+0IBRlWfBzMRUESfM8m3U3KyQApQRvjI6M7KhFXL40LCDYN3Kt8VW1VfwaZJwP53o1GvNj+zhojooyQiqwSFJ3OE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2201MB1083 Archived-At: Subject: Re: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 15:27:27 -0000 > I think so; there are some details of resale that BRSKI would like to mak= e out-of-scope for the first document. Some way, we have to deal with it, = and I would actually like feedback from OPC about the parameters of differe= nt solutions here. So in this case would the MASA need to be OPC specific, that is, use OPC Se= curity and OPC methods? Apologies if I'm getting ahead of myself on this c= onversation. Thanks, --Jack -----Original Message----- From: Michael Richardson =20 Sent: Saturday, August 10, 2019 9:08 PM To: Randy Armstrong (OPC) Cc: Jack Visoky ; iot-onboarding@ietf.org; anima@= ietf.org Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI Randy Armstrong (OPC) wrote: > The questions that the OPC WG needs to answer are: > 1) Can BRSKI meet our requirements? I think so; there are some details of resale that BRSKI would like to make = out-of-scope for the first document. Some way, we have to deal with it, an= d I would actually like feedback from OPC about the parameters of different= solutions here. > 2) If the answer to 1) is yes then can it work with OPC UA security? yes, I think so. is there any open source reference code for the OPC UA security? > 3) If the answer to 2) is no then do we use TLS or extend our own mod= el > with something like BRSKI but not BRSKI? > While I cannot predict how the various participants in the OPC WGs wi= ll > respond to question 3), I do know it would make collaboration a lot > easier if the answer to 2) was yes. I think yes. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Mon Aug 12 14:09:59 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18728120125 for ; Mon, 12 Aug 2019 14:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 stUILuqxIxvf for ; Mon, 12 Aug 2019 14:09:54 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 8CE7B1210F1 for ; Sun, 11 Aug 2019 19:45:36 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id 4so40309690pld.10 for ; Sun, 11 Aug 2019 19:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=iRxHgey5XDNs8vYFrIEW7b/0WVp5kVSrE7YsF3oUeN0=; b=KOBDDRSYK4lzt/47J/7tjerarf3Q/J1txGnTWk0s6KXqd4QTl7ivfW8ViFaQSqN/VU PmRAfkDetqDjKQVMR1llElrQAG87be7zQJKRNf+dm1fguczpVsfw8VUdIg3LVJFZ8KzB 54i/Z1CrHt6rH03H3SPTHb/fVJHMd8ssROhV7/3XB2ExPXpG4DG2vIG1hmWkvkYRjl7a ex/mC7U9fBNhuASLCn5pQRKI6fRpDSPdrMqe1IA0NCbr6uZ5IZ4RvzUm6GGU5OzM46nY PTOMScu1tko2am4Z0gbXm8ncHSlUIC8Et5nDMuEZWTIm7XRNE23EQG14b3+ZhVAA0X0f J6xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=iRxHgey5XDNs8vYFrIEW7b/0WVp5kVSrE7YsF3oUeN0=; b=cjMnFy2rvtwm7+P9Kc3Fj6Oud0tN/TDB6wg/Drnm8BE0B6u9HaHfsRGzbu123em23P yxw8TnyZH2Lu6pbU7TlFsmQo277ofmw0L+TYaf5kf7jvMu7+USikACTvjxC9zztS4Z7H nCeBOIn1YprblHSapi5rKg9rTWIEq2ZrksH4TLjzxEul1ALdknBzxyLvA4kVrZXE5Se7 FDZEnPd6sD/hUEZUz9xudXTVQ4JOkk7uoW5UzzptDJ/v+tuRTwvGEzqNnyFHdb0Wb0vO k6i2lPYSxB6LKVAHPt5kl8JCUsBBD5x6EWXh1o/svRjasJveKeG6LxSASmI9hejmx7F0 VhBQ== X-Gm-Message-State: APjAAAWCMzK0qWTIjM8ESMgy59CiQHH5XPjHfUifEq9tRcqouU1b/O/c O9x8/QR3rjL80n7Q+n8++zFwzwW0 X-Google-Smtp-Source: APXvYqwBMWBNtt4A1QJ1pBOPpml/BZeQQ7g9u3QCz/lVwdZjh/JgRgJXf+42cWsDAD4CQmlJCcl6gQ== X-Received: by 2002:a17:902:b193:: with SMTP id s19mr31162225plr.258.1565577935693; Sun, 11 Aug 2019 19:45:35 -0700 (PDT) Received: from [192.168.178.30] ([118.148.73.254]) by smtp.gmail.com with ESMTPSA id v8sm7811954pjb.6.2019.08.11.19.45.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Aug 2019 19:45:34 -0700 (PDT) To: Michael Richardson , Toerless Eckert , "Liubing (Leo)" , Anima WG References: <20190724214603.llrersvrcgb4hy7p@faui48f.informatik.uni-erlangen.de> <20190724220015.sfzqxcozq4khc6ut@faui48f.informatik.uni-erlangen.de> <6709.1564009422@dooku.sandelman.ca> From: Brian E Carpenter Message-ID: Date: Mon, 12 Aug 2019 14:45:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <6709.1564009422@dooku.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] MACsec as an alternative to L3-tunnels X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 21:09:58 -0000 Hi, In the context of the L2ACP draft (draft-carpenter-anima-l2acp-scenarios): It seems that MACsec keying and associations are generally pair-wise, but IEEE Std 802.1AE-2018 says: "The guarantees provided by MACsec support the following security services for stations participating in MACsec: a) Connectionless data integrity [6.8a), 6.8b)] b) Data origin authenticity [6.8a)]. If the connectivity model is point-to-point, the originator is authenticated, but _if the connectivity model is multipoint, then the authenticated originator is any member of the CA, rather than a particular individual station._ c) Confidentiality [6.8d)] d) Replay protection [6.8c), 6.8d)] e) Bounded receive delay" Also 802.1 bridges do forward MACsec. So multicast should work. However 1) This does not carry over to 802.11. An L2ACP that was a mixture of 802.1 and 802.11 would need to deal with two different security solutions. 2) On 25-Jul-19 11:03, Michael Richardson wrote: > I was asked to decode words mangled at the mic at Tuesday morning's ANIMA > meeting. > The word was "MACsec", and > https://en.wikipedia.org/wiki/IEEE_802.1AE > https://1.ieee802.org/security/802-1ae/ > > provides a reasonable description, and probably the getieee mechanism > might get you a copy for free, but IEEE doesn't have a URL that > leads to the actual document. I did read it once. > (One of the URLs in the wikipedia page leads to 404) > > https://ieeexplore.ieee.org/document/8585421 > might get you the document if you have a valid password, which > I used to, but apparently not anymore. We should use the 2018 version of the standard, which should be freely available via https://ieeexplore.ieee.org/browse/standards/get-program/page > Given my newly acquired understanding that MACsec applies on a per-port > basis, not on a per-VLAN basis, this means that it would be rather difficult > to do peer discovery and security for a L2-bridged LAN. As I read the current standard, it should work, but if you do MACsec then the user plane VLAN is apparently protected by the same keys as the ACP VLAN. However, the two VLANs would still be completely protected from each other by 802.1Q, so I think it's OK. On 31-Jul-19 08:41, Toerless Eckert wrote: ... > I think my reference was more to what chips can do as to what > necessarily existing standaerds may say. There is this one issue of > having an 802.1ae capable switch port connected via a hub to multiple > host, in which case you could imagine to use a different set of keys to > each host but the public vendor documentation i found was quite > inconclusive whether this actually works in todays products. Yes, Google finds various different proprietary explanations that seem incompatible. Re the VLAN question, StackExchange says: "There is no standard for MACSec and 802.1Q, so manufacturers have come up with their own solutions." That is no longer true; 802.1AE-2018 explains exactly how it co-exists with 802.1Q. But I doubt if the products have all been updated yet. We need an expert. I like this explanation, but it's now out of date: https://developers.redhat.com/blog/2016/10/14/macsec-a-different-solution-to-encrypt-network-traffic/ Brian From nobody Mon Aug 12 15:21:51 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFDF5120836; Mon, 12 Aug 2019 15:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, 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 v6trGYvjQvpe; Mon, 12 Aug 2019 15:21:47 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976C4120ACE; Mon, 12 Aug 2019 11:50:26 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4F78C548028; Mon, 12 Aug 2019 20:50:20 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3A0FF440041; Mon, 12 Aug 2019 20:50:20 +0200 (CEST) Date: Mon, 12 Aug 2019 20:50:20 +0200 From: Toerless Eckert To: Jack Visoky Cc: Michael Richardson , "Randy Armstrong (OPC)" , "iot-onboarding@ietf.org" , "anima@ietf.org" Message-ID: <20190812185020.za2rtuo6bduhsu7i@faui48f.informatik.uni-erlangen.de> References: <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> <4671.1565279232@localhost> <19592.1565471757@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 22:21:50 -0000 Agreeing to what Michael and you said, but also wanted to point out that TLS as defined by IETF is on a trajectory which may or may not be desirable for e.g.: industrial automation (where OPC is used) or other regulated/ critical environments. For example the total elimination of any non-encryption option in the TLS1.3 profile and the removal of the ability for passive observers to see the certificates exchanged impeeds severely on the ability to do passive diagnostics. I at least think there are good reasons to also have a strong and independent reviewed authentication scheme without encryption that can well be diagnosed by passive observers. Aspects like these are easily fixed IMHO by creating different profiles of TLS. Whether or not one could get such profiles through the TLS WG in the IETF is of course a different question given what seems to be a highly contentuous nature of the topic. There also seems to be a desire of areas of industrial automation to avoid the overhead of a perceived to be redundant network layer. This was a thing back in the days of OSI where TP4 was often run in factories without CLNS, and given how IP hasn't really improved on simplified, automated address management vs. L2 switched ethernet, this still seems to be a thing. Aka: Someone would need to define TLS on top of just ethernet instead of IP/IPv6. And there may be other similar L2 "transport" technologies where its not clear if simple ethernet mappings would suffice (bluetooth, wifi,...). Last but not least, QUIC is on a path to replace TLS and that too puts a dent into the belief that TLS as it stands would be a long term stable most-widely used protocol. Finally: There is something said to not simply trust a design like TLS which you do not really understand just because its widely used, and thus hopefully well reviewed, but rather make sure you have a design based on solid understanding of the cryptographic principles employed and a well defined review/control process of implementations. Incidents like with OpenSSL show how badly reviewed even the most widely deployed crypto mechanisms can be. Cheers Toerless On Sun, Aug 11, 2019 at 09:31:22PM +0000, Jack Visoky wrote: > > but there are significant benefits to not maintaining your own protocols, and significant benefits to getting the extensive review that TLS gets. > > I could not agree more with this statement. > > Thanks, > > --Jack > > > -----Original Message----- > From: Michael Richardson > Sent: Saturday, August 10, 2019 5:16 PM > To: Jack Visoky ; Randy Armstrong (OPC) ; iot-onboarding@ietf.org; anima@ietf.org > Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI > > > Jack Visoky wrote: > > I am also involved with OPC-UA and would like to provide my/my > > company's perspective. One of the major drivers of this engagement > > with the ANIMA group was a contentious point around whether or not TLS > > and EST are required for support of BRSKI. Some of us had taken the > > position that these technologies are an integral part of BRSKI and > > shouldn't be replaced with OPC specific methods, especially given the > > benefit of using highly adopted security technologies, as well as the > > tight coupling of BRSKI to these. So, I think the idea that OPC should > > just use these technologies is very much a viable answer. > > If the device is powered or has enough battery to do 802.11, then it probably has enough power and code space to do TLS (particularly mbedtls from ARM). > If it's on a very low duty cycle on battery, and/or it does 802.15.4, then the question is still open. The IETF may start work on a 802.15.4 specific AKE, (see lake@ietf.org). We believe we need these for 6tisch (TSCH mode of 802.15.4 for deterministic industrial networks) > > It appears that the OPC UA methods provide enough security to do BRSKI, but there are significant benefits to not maintaining your own protocols, and significant benefits to getting the extensive review that TLS gets. > > > Also, I would strongly push back on any claims that low end OPC devices > > cannot support TLS. Other industrial protocols have already added TLS > > support and are shipping products, including those with TLS client > > functionality. TLS is no more heavy-weight than existing, OPC-specific > > security mechanisms. > > The OPC-specific mechanism appears to avoid a DH operation and therefore lacks PFS. I understand it uses RSA, which means that it's significantly more expensive than TLS with ECDSA (and ECDH) would be, and most SOCs have hardware acceleration for ECDSA's secp256v1, fewer have RSA acceleration. > > > In any event I will be sure to join the call that has been set up for > > later in August. > > Awesome. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > -- > Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- > > > > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de From nobody Mon Aug 12 15:25:21 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C582F120996; Mon, 12 Aug 2019 15:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 WVaQJBULtyI9; Mon, 12 Aug 2019 15:25:09 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65085120DA5; Mon, 12 Aug 2019 14:29:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CF73B3818D; Mon, 12 Aug 2019 17:28:26 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AEAA69A; Mon, 12 Aug 2019 17:29:11 -0400 (EDT) From: Michael Richardson To: "iot-onboarding\@ietf.org" , Jack Visoky cc: "Randy Armstrong \(OPC\)" , "anima\@ietf.org" In-Reply-To: References: <649C8221-5F33-4EC2-8E03-3EEAF4CAAB64@cisco.com> <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> <4671.1565279232@localhost> <19592.1565471757@localhost> <15583.1565485709@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 22:25:13 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Jack Visoky wrote: >> I think so; there are some details of resale that BRSKI would like to >> make out-of-scope for the first document. Some way, we have to deal >> with it, and I would actually like feedback from OPC about the >> parameters of different solutions here.=20 > So in this case would the MASA need to be OPC specific, that is, use > OPC Security and OPC methods? Apologies if I'm getting ahead of myse= lf > on this conversation. I don't think that the MASA would be OPC specific. The Registrar would have to speak the OPC security rather than HTTPS on the plant side. The Registrar would still speak HTTPS to the MASA. This is what we have done in draft-ietf-anima-constrained-voucher: it speaks CoAPS (CoAP over DTLS) or OSCORE-EDHOC (CoAP with OSCORE, keyed by EDHOC) on the plant side, and HTTPS to the Registrar. There are (at least) two major ways to build a Registrar. 1) a single monolithic application framework, it receives the voucher-request, and then does a synchronous HTTPS request to the MA= SA. (Perhaps doing 100-Continue). 2) The other way is for the pledge-facing part of the Registrar to put it a= ll into a database, return 202, and wait for another query. Asynchronously= some other part sends requests to the MASA and stores the answers back in the database. Perhaps the only thing connecting the two parts is some multi-master database replication... Case 1 is appropriate up to a certain level of load and complexity. It's certainly way easier to test! Case 2 has scaling advantages, some security advantages, and also makes it way easier to build different plant facing interfaces. I believe that all implementations are case 1 so far. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1R2icACgkQgItw+93Q 3WWCrQf/ePPEbl3PlyVz+NYcFIUWZ3FHfdHI7ksqSwYJ9TgBh5jXSiwoKO6Qo8dY 3ZI/UZOkhYYtCtd+P7gdIo0r6CS5VM52I/4xNhVvTcX+NqBHKrTwPqXMTUGakVlM IeUgUgAin2WJES0rQDzPQbctTPtlZzzcpcy4QXpMTE9P3PDE+n1467lsneZjUrgI wfTTMd7XYJbVKYXrU132+samokPXZqd1IcYOugDd8zQdYNandBfFLJ475a2/W7Xk 2L2yFyiTobQQTfxyr5eEUBCGB3bW0wFFyp5De/Wq51hhjaH6eQ0QYNO0UjQpegx0 v5ty0S27gjSNt5g1YYQeYP1tJ8B0Wg== =w+ef -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 12 15:28:28 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBCE120B44; Mon, 12 Aug 2019 15:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Q7uYgEuFnhrG; Mon, 12 Aug 2019 15:28:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EC8B122315; Mon, 12 Aug 2019 12:05:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 0825E3818D; Mon, 12 Aug 2019 15:05:00 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AFFDEDCB; Mon, 12 Aug 2019 15:05:44 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 22:28:21 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable https://tinyurl.com/yylruorn contains a diff against -24. Benjamin Kaduk via Datatracker wrote: > Section 5.8.1 doc> A log data file is returned consisting of all log entries assoc= iated doc> with the the device selected by the IDevID presented in the reques= t. doc> The audit log may be truncated of old or repeated values as explai= ned doc> below. The returned data is in JSON format ([RFC7951]), and the doc> Content-Type SHOULD be "application/json". For example: > If RFC 7951 is to be used, I'd suggest "is JSON-encoded YANG data". Typo, it should be 7159. doc> This document specifies a simple log format as provided by the = MASA doc> service to the registrar. This format could be improved by distri= buted doc> consensus technologies that integrate vouchers with technologies s= uch doc> as block-chain or hash trees or optimized logging approaches. Doi= ng so doc> is out of the scope of this document but is an anticipated improve= ment doc> for future work. As such, the registrar client SHOULD anticipate = new doc> kinds of responses, and SHOULD provide operator controls to indica= te doc> how to process unknown responses. > This would be a great place to talk about the "version" field that's > otherwise ignored. As in, what should occur if the "version" is not 1? How about: A registrar that sees a version value greater than 1 indicates an audit log format that has been enhanced with additional information. No information will be removed in future versions; should an incompatible change be desired in the futur= e, then a new HTTP end point will be used. =20=20=20=20=20=20=20=20=20=20 doc> anticipated improvement for future work. As such, the registrar doc> client SHOULD anticipate new kinds of responses, and SHOULD provide doc> operator controls to indicate how to process unknown responses. > Is "registrar client" intended to be both words or just one? Probably not, removed. doc> A registrar SHOULD use the log information to make an informed doc> decision regarding the continued bootstrapping of the pledge. The > I may be confused, but I thought the registrar was asking for the log > after the voucher had already been issued. Are these check supposed = to > keep the registrar from forwarding the voucher to the pledge, or just > as a check for future renewal operations? The voucher can be returned to the Pledge immediately, as there is never any issue about whether the Pledge should join. The MASA has already made that decision. The Registrar could avoid passing the voucher on until after the audit log checks are done, or could do that concurrently. What matters is that the audit log checks are done prior to the Registrar accepting an enroll request. This is down in (what is now) Figure 4. The Registrar may do additional checks of the audit log at later times, but I don't think we have any good advice on this yet. doc> A relatively simple policy is to white list known (internal or doc> external) domainIDs and to require all vouchers to have a nonce an= d/ or doc> require that all nonceless vouchers be from a subset (e.g. only doc> internal) domainIDs. A simple action is to revoke any locally iss= ued > nit: missing "of" I don't know where the "of" that is missing goes. While investigating, I broke the big sentence up, and discovered that the 5209 reference was not coded as XML. Please clue me in what you mean... A relatively simple policy is to white list known (internal or external) domainIDs. To require all vouchers to have a nonce. Alternatively to require that all nonceless vouchers be from a subset (e.g. only internal) domainIDs. If the policy is violated a simple action is to revoke any locally issued credentials for the pledge in question or to refuse to forward the voucher. The Registrar MUST then refuse any EST actions, and SHOULD inform a human via a log. A registrar MAY be configured to ignore (i.e. override the above policy) the=20 history of the device but it is RECOMMENDED that this only be configured if hardware assisted (i.e. TPM anchored) Network Endpoint Assessment (NEA) is suppor= ted. doc> credentials for the pledge in question or to refuse to forward = the doc> voucher. A registrar MAY be configured to ignore the history of t= he > "simple action" in the case that the registrar doesn't like the audit > log results? See changes above for better clarity. > device but it is RECOMMENDED that this only be configured if > hardware assisted NEA [RFC5209] is supported. > Probably need to expand NEA. done, see above. > Section 5.9 doc> Although EST allows clients to obtain multiple certificates by doc> sending multiple CSR requests BRSKI mandates use of the CSR Attrib= utes doc> request and mandates that the registrar validate the CSR against t= he doc> expected attributes. This implies that client requests > Where is this requirement stated normatively? I guess I never thought of it as a requirement that multiple certificates a= re not supported; it's a restriction because CSR Attributes is used. Where is use of CSR Attributes stated. RFC7030 Section 4.5 has using CSR Attributes as a SHOULD. I will note that the ACME Integration documents all seem to have missed the CSR Attributes part of the flow. Although EST allows clients to obtain multiple certificates by =2D sending multiple CSR requests BRSKI mandates use of the CSR =2D Attributes request and mandates that the registrar validate the CSR + sending multiple CSR requests; BRSKI does not support this mechanism + directly. This is because BRSKI pledges MUST use the CSR Attributes + request ([RFC7030] section 4.5). The registrar MUST validate the CSR against the expected attributes. This implies that client requests will "look the same" and therefore result in a single logical certificate being issued even if the client were to make multiple > Section 5.9.1 doc> This ensures that the pledge has the complete set of current CA doc> certificates beyond the pinned-domain-cert (see Section 5.6.1 for a doc> discussion of the limitations inherent in having a single certific= ate doc> instead of a full CA Certificates response.) Although these > I don't see such a discussion in the indicated section. The 5.6 section got split, it should refer to 5.6.2 now. > Section 5.9.2 doc> To alleviate these operational difficulties, the pledge MUST re= quest doc> the EST "CSR Attributes" from the EST server and the EST server ne= eds doc> to be able to reply with the attributes necessary for use of the doc> certificate in its intended protocols/services. This approach all= ows > "intended" implies that the EST server has some knowledge of what the > pledge is expected to be doing in the network, right? Yes. The ACP document is quite specific about the (rfc822Name) attributes = to assign. Certainly the attributes could include stuff like "ve608.core1.tor1.example.net" if the Registrar knew how this device was to be used, but more likely that would be set up afterwards. doc> To alleviate these operational difficulties, the pledge MUST re= quest doc> the EST "CSR Attributes" from the EST server and the EST server ne= eds doc> to be able to reply with the attributes necessary for use of the doc> certificate in its intended protocols/services. This approach all= ows doc> for minimal CA integrations and instead the local infrastructure (= EST doc> server) informs the pledge of the proper fields to include in the doc> generated CSR. This approach is beneficial to automated boostrapp= ing doc> in the widest number of environments. > This is convenient, but has some security considerations in that it > implies that the validation policy on the CA is somewhat lax, since t= he > EST server is expected to be doing most of the policy controls. Thus, > a compromised pledge/device could send a CSR with unauthorized fields > and it is likely to be signed, allowing for some level of privilege > escalation. When the registrar acts as a proxy to the CA as well as > its EST role, as described later, this risk is diminished. I don't really understand. EST servers are Registration Authorities, and they have some kind of priviledged access to the CA, and are mandated to check the CSR. I expected to find a statement to this effect in RFC7030, in section 4.2.1, but I don't see any particularly strong language. This seems like a quality of implementation issue in the Registrar. doc> In networks using the BRSKI enrolled certificate to authenticat= e the doc> ACP (Autonomic Control Plane), the EST attributes MUST include the= "ACP doc> information" field. See [I-D.ietf-anima-autonomic-control-plane] = for doc> more details. > This MUST seems like it belongs in the ACP spec and need not be > repeated here using normative language. I will simplify this, and reference to section 6.1.2 of the ACP. In networks using the BRSKI enrolled certificate to authentic= ate =2D the ACP (Autonomic Control Plane), the EST attributes MUST inc= lude =2D the "ACP information" field. See for more details. + the ACP (Autonomic Control Plane), the EST CSR attributes MUST i= nclude + the ACP Domain Information Fields defined in section 6.1= .2. + =20 > Section 5.9.4 doc> administrators concerning device lifecycle status. This might doc> include information concerning attempted bootstrapping messages se= en by doc> the client, MASA provides logs and status of credential enrollment. doc> [RFC7030] assumes an end user and therefore does not > This looks like a comma splice. fixed. doc> In the case of a FAIL, the Reason string indicates why the most doc> recent enrollment failed. The SubjectKeyIdentifier field MUST be doc> included if the enrollment attempt was for a keypair that is local= ly > We haven't talked about POSTing to a new status-report endpoing yet, = so > this comes out of the blue. It would probably be worth adding above > "SHOULD [start a new TLS handshake] and POST a enrollment status > message". So I'll re-order some paragraphs, and I see that there is an obsolete half-thought, which remained after removing the TLS re-negotiate option that TLS1.3 obsoletes.=20 > "Status":TRUE /* TRUE=3DSuccess, FALSE=3DFail" > [same note about JSON comments] > "reason-context": "Additional information" > Is this supposed to be a string or a JSON object similar to > /voucher_status? Already fixed to correct JSON from other comments. doc> This allows for clients that wish to minimize their crypto doc> operations to simply POST this response without renegotiating the = TLS doc> session - at the cost of the server not being able to accurately v= erify doc> that enrollment was truly successful. > I'd prefer to not have this sort of option available, but I can't > disprove the claim of its utility, so I will not object if it stays. Agreed, I've removed it. > Section 5.9.5 > Is the idea that the initial BRSKI-EST-issued certificate would > authenticate the client for the subsequent EST requests? yes. > Section 7 > If this is non-normative and will need to be fleshed out in a separate > document, would an Appendix be more appropriate? Section 9 and 10 refer back to this section in a normative fashion. > Section 7.1 doc> Pledge: The pledge could be compromised and providing an attack doc> vector for malware. The entity is trusted to only imprint using s= ecure doc> methods described in this document. Additional endpoint > How do "could be compromised" and "is trusted to only [...]" go > together? The IDevID could be safe in a TPM, on the other side of an intact kernel, but the device could be running a VM full of malware. We can trust it to onboard, but not the operate correctly. doc> Vendor Service, MASA: This form of manufacturer service is trus= ted doc> to accurately log all claim attempts and to provide authoritative = log doc> information to registrars. The MASA does not know which devices a= re doc> associated with which domains. These claims could be > I think this is maybe more of a "does not enforce" than "does not > know", since the domainID ends up in the audit logs that the MASA > holds. Yes, but the domainID does not directly identify the Registrar by name. Assuming a database breach, what does the MASA know that it can reveal. The MASA could store more data, but it doesn't have. > Current text provides only for a trusted manufacturer. > nit: not a complete sentence. I have no memory of what it means, so I've removed it. > Section 7.3 doc> A registrar can choose to accept devices using less secure meth= ods. doc> These methods are acceptable when low security models are needed, = as doc> the security decisions are being made by the local administrator, = but doc> they MUST NOT be the default behavior: > I'm having a hard time parsing "low security models"; the best I can > come up with is "threat models where low security is adequate". doc> Lower security modes chosen by the MASA service affect all devi= ce doc> deployments unless bound to the specific device identities. In wh= ich > Is this "unless the lower-security behavior is tied to specific device > identities"? Yes, changed. doc> case these modes can be provided as additional features for spe= cific doc> customers. The MASA service can choose to run in less secure modes > nit: This middle sentence is not a complete sentence. Already fixed. doc> 1. Not enforcing that a nonce is in the voucher. This results= in doc> distribution of a voucher that never expires and in effect makes > A nonceless voucher can still include an expiration time ... it is ju= st > in practice possible for it to never expire, if the target pledge does > not have an accurate clock. Yes, that's correct. How many devices with RTCs survive 10 years in a warehouse with no power? := -) Section 7.4 (.1, and .2) have been reworked some more. doc> subsequent bootstrapping attempts. That this occurred is doc> captured in the log information so that the registrar can make doc> appropriate security decisions when a pledge joins the Domain. Th= is is doc> useful to support use cases where registrars might not be online d= uring doc> actual device deployment. Because this results in > nit: I think that grammatically the "This" at the start of this > sentence refers to the behavior described in the previous sentence (t= he > availability of the log information) rather than the issuance of the > nonceless voucher. fixed. > Section 9 doc> The autonomic control plane that this document provides bootstr= ap doc> for is typically a medium to large Internet Service Provider doc> organization, or an equivalent Enterprise that has signficant laye= r-3 doc> router connectivity. (A network consistenting of primarily layer-2 > nit: "is used in" -- the ACP is not the entire organization! The text doesn't have "is used in" But, I did find that paragraph awkward and rewrote it. > Section 10.1 doc> The MASA audit log includes a hash of the domainID for each doc> Registrar a voucher has been issued to. This information is close= ly doc> related to the actual domain identity, especially when paired with= the doc> anti-DDoS authentication information the MASA might collect. This doc> could > I thought I remembered some discussion of collecting this information > and thus what sort of information might be collected, but searching f= or > "DDoS" in the document didn't find it. In order to protect itself from DDoS attacks, it's better if the MASA can authenticate every connection. With full supply chain integration, then it knows every customer, and this is easy. On the other hand, if it hasn't got full chain integration, then it may need to accept connections from any place with any client certificate. So it will need some kind of anti-DDOS system. section 11.1 speaks about this, although it uses the term DoS. I've synchronized the terms and made a forward reference. doc> There are a number of design choices that mitigate this risk. = The doc> domain can maintain some privacy since it has not necessarily been doc> authenticated and is not authoritatively bound to the supply chain. > Is this really "privacy" or just "semi-plausible deniability"? It's a good question. A domain could use a new certificate for each device, could connect via some onion router. Is that privacy, or "semi-plausible deniability"? doc> Additionally the domainID captures only the unauthenticated sub= ject doc> key identifier of the domain. A privacy sensitive domain could > It's interesting to see "unauthenticated" used here, since the domain= ID > is deterministically generated from the pinned-domain-cert that is > included in the voucher and inserted into the pledge's trust store. = So > in a sense it is a committal by "the domain" to tie that domain cert = to > that device or have the device otherwise be unusable. Yes, so a Registrar can present a new self-signed certificate each time. Sure, it has to keep that around, as it's the link for that pledge. > The subsequent > text here seems to be suggesting that instead of having a single root > CA cert used by all devices in the domain, distinct certs would be us= ed > for each device, thus attempting to remove an ability to associate > devices with each other via joint domain membership. One might imagi= ne > doing this by entering intermediate CAs (or even leafs?) into the > pinned-domain-cert field, but if those certs ever become visible (e.g= ., > via certificate transparency), then the domainIDs can be independently > computed and associated to the MASA audit log, and the issuer chain > used to recorrelate the devices by domainID. So to fully protect > privacy, the per-device pinned-domain-certs would need to be "root"s > (i.e., self-issued), which greatly increases the manageability > complexity and is in effect counter to the goals of ANIMA and BRSKI. Agreed. If you have suggestions on other ways to mitigate, I'm all ears. > Section 10.2 doc> While the contents of the signed part of the pledge voucher req= uest doc> can not be changed, they are not encrypted at the registrar. The doc> ability to audit the messages by the owner of the network prevents doc> exfiltration of data by a nefarious pledge. The contents of an > I think "prevents" is too strong -- steganography and concealed > channels are really hard to completely defend against. "Gives a > mechanism to defend against" would be more accurate, in my opinion. Okay. doc> The above situation is to be distinguished from a residential/ doc> individual person who registers a device from a manufacturer: that= an doc> enterprise/ISP purchases routing products is hardly worth mentioni= ng. doc> Deviations would, however, be notable. > Deviations in what sense? After buying only Cisco equipment (like ASR 9000) [observed by number of MA= SA connections after each POP turn up], ISP example.net suddendly has started communicating with Juniper's MASA (for MX40s..). > Section 10.3 doc> 4. There is a fourth case, if the manufacturer is providing doc> protection against stolen devices. The manufacturer then has a doc> responsability to protect the legitimate owner against fraudulent doc> claims that the the equipment was stolen. Such a claim would caus= e the doc> manufacturer to refuse to issue a new voucher. Should the device = go doc> through a deep factory reset (for instance, replacement of a damag= ed doc> main board component, the device would not bootstrap. > I'm not sure I understand this scenario -- is it talking about where a > third party makes a false theft report in the hopes that the real own= er > will have to do a deep reset and then have the device fail to bootstr= ap > because of the reported theft? Yes. > Section 11 doc> To facilitate logging and administrative oversight, in addition= to doc> triggering Registration verification of MASA logs, the pledge repo= rts > I'm not sure if "Registration verification" is a typo or not. changed to: _Registrar verification_ doc> registrar. This is mandated anyway because of the operational doc> benefits of an informed administrator in cases where the failure is doc> indicative of a problem. The registrar is RECOMMENDED to verify M= ASA > I'd also expect some comment about the limited value of the additional > information to an attacker in the context where the attacker already > would know [other information]. I'm not sure what other "other information" is yet, so I don't know how to fill that in. doc> To facilitate truely limited clients EST RFC7030 section 3.3.2 doc> requirements that the client MUST support a client authentication = model doc> have been reduced in Section 7 to a statement that the registrar "= MAY" doc> choose to accept devices that fail cryptographic authentication. = This doc> reflects current (poor) practices in shipping > But section 7 is non-normative! okay, but now section 9 refers to parts of it normatively. doc> devices without a cryptographic identity that are NOT RECOMMEND= ED. > I guess if we really wanted to disrecommend this practice we could > split it out into a separate document that profiles core BRSKI for su= ch > usage. yes. > Section 11.1 doc> this might be an issue during disaster recovery. This risk can= be doc> mitigated by Registrars that request and maintain long term copies= of doc> "nonceless" vouchers. In that way they are guaranteed to be able = to doc> bootstrap their devices. > This, of course, comes with a different risk of what is something like > a long-term credential existing that needs to be protected and stored. I partially agree. Long-term nonceless vouchers still pin a specific domainID. So they need to available, but they don't need to be private. doc> The issuance of nonceless vouchers themselves creates a security doc> concern. If the Registrar of a previous domain can intercept prot= ocol doc> communications then it can use a previously issued nonceless vouch= er to doc> establish management control of a pledge device even after having = sold doc> it. This risk is mitigated by recording the issuance of such vouc= hers doc> in the MASA audit log that is verified by the subsequent Registrar= and doc> by Pledges only bootstrapping when in a factory default state. Th= is doc> reflects a balance between enabling MASA independence during future doc> bootstrapping and the security of bootstrapping itself. Registrar doc> control over requesting and auditing nonceless vouchers allows dev= ice doc> owners to choose an appropriate balance. > I would expect some discussion here about nonceless vouchers > with/without expiration times. Added above. > I also wonder whether the owner or registrar should expect to be doing > soem periodic MASA audit log checking, akin to a CT auditor or monito= r. Yes, but we think falls into quality of implementation. It's not something worth doing for every Registrary. doc> of specific pledge devices, helps to mitigate this. Pledge doc> signatures on the pledge voucher-request, as forwarded by the regi= strar doc> in the prior-signed-voucher-request field of the registrar doc> voucher-request, significantly reduce this risk by ensuring the MA= SA doc> can confirm proximity between the pledge and the registrar making = the doc> request. This mechanism is optional to allow for constrained devi= ces. doc> Supply chain integration ("know your customer") is an > And so the protection is only available when all devices served by the > MASA are known to produce signed voucher-requests. Which is now mandatory. doc> additional step that MASA providers and device vendors can expl= ore. > In terms of adding some more crypto to the BRSKI-MASA flow that would > prevent unauthenticated DoS? If every connection is from a known customer, then one can reject the DoS at the TLS handshake step. > Section 11.2 > I appreciate having this discussion present; thanks! doc> The fake registrar (Rm) can obtain a voucher signed by the MASA doc> either directly or through arbitrary intermediaries. Assuming that > I'm not sure what sort of intermediary this is thinking about. Join Proxies connected to the systems involved. doc> This pledge voucher-request would be 'stale' in that it has a n= once doc> that no longer matches the internal state of the pledge. In order= to doc> successfully use any resulting voucher the Rm would need to remove= the doc> stale nonce or anticipate the pledge's future nonce state. Reduci= ng doc> the possibility of this is why the pledge is mandated to generate a doc> strong random or pseudo-random number nonce. > This gets a bit more complicated to reason about when we assume that a > pledge will have multiple voucher requests out in parallel, instead of > doing them in sequence and timing out (so that there is literally only > one valid nonce at a given time)... Agreed. But, we think that doing things serially has too much potential to run into head-of-queue challenges; the risk is that if devices don't onboard relatively quickly, then BRSKI will get turned off, not used, or the vendor might provide some "backdoor" doc> Additionally, in order to successfully use the resulting vouche= r the doc> Rm would have to attack the pledge and return it to a bootstrapping doc> enabled state. This would require wiping the pledge of current > .... and I think there is a different attack if the Rm is in a positi= on > to delay or drop network traffic between the pledge and the intended > registrar, to cause Rm's voucher to be delivered first even though it > is generated after the intended registrar's authorization process. T= he > intended registrar would need to require reports on voucher processing > status (or investigate their absence) in order to detect such a case. Yes, that's definitely a problem. We had a lot of difficulty constructing this attack, btw. doc> o Retreival and examination of MASA log information upon the doc> occurance of any such unexpected events. Rm will be listed in the= logs doc> along with nonce information for analysis. > How strongly guaranteed is it that a given device will only have a > single specific MASA that it trusts to issue vouchers (and thus limit > the scope of monitoring needed by the owner)? There is no guarantee; a device could have multiple IDevID. However, a voucher-request from one wouldn't be useable for another. It would require malicious code in the pledge, I think. > Section 11.3 doc> o A Trust-On-First-Use (TOFU) mechanism. A human would be quer= ied doc> upon seeing a manufacturer's trust anchor for the first time, and = then doc> the trust anchor would be installed to the trusted store. There a= re doc> risks with this; even if the key to name is validated using someth= ing doc> like the WebPKI, there remains the possibility > nit: is this "key to name mapping"? fixed. > Section 11.4 > It is not entirely clear to me whether device manufacturers are set up > with incentives to maintain a well-run secure CA with strong hardware > protections on the offline signing key for the root CA, cycling throu= gh > various levels of intermediates, etc., that CAs in the Web PKI do > today. If the manufacturer uses a less stringent process, that would > leave the manufacturer's key as a more tempting attack surface, and it > may be worth some discussion here about what damage could be done with > a compromised MASA signing key. E.g., would an attack require > restoring devices to factory defaults or otherwise waiting for natural > bootstrapping events to occur? Would the attacker need to be on-path? > Etc. I have dug around cabforum.org and root-servers.org for some references on what a "well-run secure CA" should be doing... surprisingly I didn't find an RFC, or one for DNSSEC root operation. Did I miss them? I thought that the= re was one. I'm writing some text, and I'll finish this email here, and post the resulting text. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1RuIgACgkQgItw+93Q 3WXRBQf/dFMV3QJZCYy6e31Ugaf7VbJhZYaPbczlZUr6CCjv68J8Ur9voImAWDAD 99cQe1N9VVnnb14HrkmbOWRPEDlWVJM7Rmt24rwkVa34qtphG8M16bqtoSQLClM7 f5ELRFdduHS91tjZ0LCZAiyV7yauar34L38BQo6GhkAWsVWHYJp9N5Rba0RUERcS ggGinRZuaxIekp+4IClKdXejIWxHqe/ku1zwUQNq26bMcDHgIVvUzKHWBwWH3Oem +sVNXRAB1cBvMlHM4x/POchjLBXIA6BNtnGlelHtou2BnBkf5jJHJkAKMhNNCv1q XFzxsxByjmLcrkB5C6HlzkXGHEkeVg== =iH95 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 12 15:29:09 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9BA121031; Mon, 12 Aug 2019 15:29:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <156564894715.20500.6966844154171253366@ietfa.amsl.com> Date: Mon, 12 Aug 2019 15:29:07 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-25.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 22:29:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Toerless Eckert Michael H. Behringer Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-25.txt Pages : 107 Date : 2019-08-12 Abstract: This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Remote Secure Key Infrastructure (BRSKI) is created using manufacturer installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping to is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-25 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-25 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-25 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 Aug 12 15:30:16 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42EB120ADE; Mon, 12 Aug 2019 15:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 IFs66mlK-wqO; Mon, 12 Aug 2019 15:30:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743531223B9; Mon, 12 Aug 2019 12:30:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9A5D33818D; Mon, 12 Aug 2019 15:29:28 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 588DADCB; Mon, 12 Aug 2019 15:30:13 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk , anima@ietf.org cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org In-Reply-To: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 22:30:08 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable WG: there is a chunk of Security Considerations text here that I hope many will read.=20=20 Benjamin Kaduk via Datatracker wrote: > Section 11.4 > It is not entirely clear to me whether device manufacturers are set up > with incentives to maintain a well-run secure CA with strong hardware > protections on the offline signing key for the root CA, cycling throu= gh > various levels of intermediates, etc., that CAs in the Web PKI do > today. If the manufacturer uses a less stringent process, that would > leave the manufacturer's key as a more tempting attack surface, and it > may be worth some discussion here about what damage could be done with > a compromised MASA signing key. E.g., would an attack require > restoring devices to factory defaults or otherwise waiting for natural > bootstrapping events to occur? Would the attacker need to be on-path? > Etc. I wanted to add that I think that there are some interesting economic discussions about these incentives. I wonder how to interest some people into doing some analysis of a monetary rather that technical manner. I have added: 11.4. Manufacturer Maintenance of trust anchors . . . . . . . 75 11.4.1. Compromise of Manufacturer IDevID signing keys . . . 77 11.4.2. Compromise of MASA signing keys . . . . . . . . . . 77 11.4.3. Compromise of MASA web service . . . . . . . . . . . 79 and this text is rough, and as yet unreviewed by anyone, and I=20 11.4. Manufacturer Maintenance of trust anchors BRSKI depends upon the manufacturer building in trust anchors to the pledge device. The voucher artifact which is signed by the MASA will be validated by the pledge using that anchor. This implies that the manufacturer needs to maintain access to a signing key that the pledge can validate. The manufacturer will need to maintain the ability to make signatures that can be validated for the lifetime that the device could be onboarded. Whether this onboarding lifetime is less than the device lifetime depends upon how the device is used. An inventory of devices kept in a warehouse as spares might not be onboarded for many decades. There are good cryptographic hygiene reasons why a manufacturer would not want to maintain access to a private key for many decades. A manufacturer in that situation can leverage a long-term certificate authority anchor, built-in to the pledge, and then a certificate chain may be incorporated using the normal CMS certificate set. This may increase the size of the voucher artifacts, but that is not a significant issues in non-constrained environments. There are a few other operational variations that manufacturers could consider. For instance, there is no reason that every device need have the same set of trust anchors pre-installed. Devices built in different factories, or on different days, or any other consideration could have different trust anchors built in, and the record of which batch the device is in would be recorded in the asset database. The manufacturer would then know which anchor to sign an artifact against. Aside from the concern about long-term access to private keys, a major limiting factor for the shelf-life of many devices will be the age of the cryptographic algorithms included. A device produced in 2019 will have hardware and software capable of validating algorithms common in 2019, and will have no defense against attacks (both quantum and von-neuman brute force attacks) which have not yet been invented. This concern is orthogonal to the concern about access to private keys, but this concern likely dominates and limits the lifespan of a device in a warehouse. If any update to firmware to support new cryptographic mechanism were possible (while the device was in a warehouse), updates to trust anchors would also be done at the same time. The set of standard operating proceedures for maintaining high value private keys is well documented. For instance, the WebPKI provides a number of options for audits at {{cabforumaudit}}, and the DNSSEC root operations are well documented at {{dnssecroot}}. It is not clear if Manufacturers will take this level of precaution, or how strong the economic incentives are to maintain an appropriate level of security. This next section examines the risk due to a compromised MASA key. This is followed by examination of the risk of a compromised manufacturer IDevID signing key. The third section sections below examines the situation where MASA web server itself is under attacker control, but that the MASA signing key itself is safe in a not- directly connected hardware module. 11.4.1. Compromise of Manufacturer IDevID signing keys An attacker that has access to the key that the manufacturer uses to sign IDevID certificates can create counterfeit devices. Such devices can claim to be from a particular manufacturer, but be entirely different devices: Trojan horses in effect. As the attacker controls the MASA URL in the certificate, the registrar can be convinced to talk to the attackers' MASA. The Registrar does not need to be in any kind of promiscuous mode to be vulnerable. In addition to creating fake devices, the attacker may also be able to issue revocations for existing certificates if the IDevID certificate process relies upon CRL lists that are distributed. There does not otherwise seem to be any risk from this compromise to devices which are already deployed, or which are sitting locally in boxes waiting for deployment (local spares). The issue is that operators will be unable to trust devices which have been in an uncontrolled warehouse as they do not know if those are real devices. 11.4.2. Compromise of MASA signing keys There are two periods of time in which to consider: when the MASA key has fallen into the hands of an attacker, and after the MASA recognizes that the key has been compromised. 11.4.2.1. Attacker opportunties with compromised MASA key An attacker that has access to the MASA signing key could create vouchers. These vouchers could be for existing deployed devices, or for devices which are still in a warehouse. In order to exploit these vouchers two things need to occur: the device has to go through a factory default boot cycle, and the registrar has to be convinced to contact the attacker's MASA. If the attacker controls a Registrar which is visible to the device, then there is no difficulty in delivery of the false voucher. A possible practical example of an attack like this would be in a data center, at an ISP peering point (whether a public IX, or a private peering point). In such a situation, there are already cables attached to the equipment that lead to other devices (the peers at the IX), and through those links, the false voucher could be delivered. The difficult part would be get the device put through a factory reset. This might be accomplished through social engineering of data center staff. Most locked cages have ventilation holes, and possibly a long "paperclip" could reach through to depress a factory reset button. Once such a piece of ISP equipment has been compromised, it could be used to compromise equipment that was connected to (through long haul links even), assuming that those pieces of equipment could also be forced through a factory reset. The above scenario seems rather unlikely as it requires some element of physical access; but were there a remote exploit that did not cause a direct breach, but rather a fault that resulted in a factory reset, this could provide a reasonable path. The above deals with ANI uses of BRSKI. For cases where 802.11 or 802.15.4 is involved, the need to connect directly to the device is eliminated, but the need to do a factory reset is not. Physical possession of the device is not required as above, provided that there is some way to force a factory reset. With some consumers devices with low overall implementation quality, the end users might be familiar with needing to reset the device regularly. The authors are unable to come up with an attack scenario where a compromised voucher signature enables an attacker to introduce a compromised pledge into an existing operator's network. This is the case because the operator controls the communication between Registrar and MASA, and there is no opportunity to introduce the fake voucher through that conduit. 11.4.2.2. Risks after key compromise is known Once the operator of the MASA realizes that the voucher signing key has been compromised it has to do a few things. First, it MUST issue a firmware update to all devices that had that key as a trust anchor, such that they will no longer trust vouchers from that key. This will affect devices in the field which are operating, but those devices, being in operation, are not performing onboarding operations, so this is not a critical patch. Devices in boxes (in warehouses) are vulnerable, and remain vulnerable until patched. An operator would be prudent to unbox the devices, onboard them in a safe environment, and then perform firmware updates. This does not have to be done by the end-operator; it could be done by a distributor that stores the spares. A recommended practice for high value devices (which typically have a <4hr service window) may be to validate the device operation on a regular basis anyway. If the onboarding process includes attestations about firmware versions, then through that process the operator would be advised to upgrade the firmware before going into production. Unfortunately, this does not help against situations where the attacker operates their own Registrar (as listed above). [RFC8366] section 6.1 explains the need for short-lived vouchers. The nonce guarantees freshness, and the short-lived nature of the voucher means that the window to deliver a fake voucher is very short. A nonceless, long-lived voucher would be the only option for the attacker, and devices in the warehouse would be vulnerable to such a thing. A key operational recommendation is for manufacturers to sign nonceless, long-lived vouchers with a different key that they sign short-lived vouchers. That key needs significantly better protection. If both keys come from a common trust-anchor (the manufacturer's CA), then a compromise of the manufacturer's CA would be a bigger problem. 11.4.3. Compromise of MASA web service An attacker that takes over the MASA web service has a number of attacks. The most obvious one is simply to take the database listing customers and devices and to sell this data to other attackers who will now know where to find potentially vulnerable devices. The second most obvious thing that the attacker can do is to kill the service, or make it operate unreliably, making customers frustrated. This could have a serious affect on ability to deploy new services by customers, and would be a significant issue during disaster recovery. While the compromise of the MASA web service may lead to the compromise of the MASA voucher signing key, if the signing occurs offboard (such as in a hardware signing module, HSM), then the key may well be safe, but control over it resides with the attacker. Such an attacker can issue vouchers for any device presently in service. Said device still needs to be convinced to do through a factory reset process before an attack. If the attacker has access to a key that is trusted for long-lived nonceless vouchers, then they could issue vouchers for devices which are not yet in service. This attack may be very hard to verify and as it would involve doing firmware updates on every device in warehouses (a potentially ruinously expensive process), a manufacturer might be reluctant to admit this possibility. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1RvkUACgkQgItw+93Q 3WWchggAjN7wYw0nKlQG4X8EqhzngYkpqAXEbHyHlI+I1qHkE2FFdOcbXWD5VGjR +B7C1u0dSlGxTZA8ymIsAPWaIClBPh+61x2y2av83DDYOPHl8D49aNdLaCseIuAX kO8wFPsiK5HsRz46dQhCsEkyL6+Tob8jH5tTeXbEWvSYU2AkVIKj5UCrj/q7XxbC tUR+nIaJIwkOWqlOjNQzgHpKHEISaTKvhAovX1HMAp8rbFGN4Mkwi2gpQpdh9nQe Hdgq0a75oTnVlCPcjQ+DeOYTsVMc5whdO8mD72eqKEr4bjPgmfnvQ9Q2OJawUNwW Qg4V9IKSPDA0sCHv8+Vpn3SkaL01dA== =ZwEb -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 12 15:33:39 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E6312138D; Mon, 12 Aug 2019 15:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 wwuuU-fbwKV3; Mon, 12 Aug 2019 15:33:28 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F27F1225DC; Mon, 12 Aug 2019 13:23:55 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6B6B63818D; Mon, 12 Aug 2019 16:23:09 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 37E37DCB; Mon, 12 Aug 2019 16:23:54 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 22:33:31 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Benjamin Kaduk via Datatracker wrote: > Section 13.2 > I think CDDL needs to be a normative reference, as does RFC 7231. RFC > 2473 is listed but not referenced in the text, as are RFC 2663, RFC > 7217, and RFC 7575. CDDL->RFC8610, now normative. (Glad that got published) RFC2473 removed, we no longer attempt to document a stateless IPIP proxy mechanism. RFC2663 (NAT terminology) reference was for Join Proxy, and I've restored a reference in section 4. RFC7217 was thought to be relevant to Pledge use of SLAAC, but actually it's not, removed. You are right that we don't reference RFC7575, which is the architecture of ANIMA. I have added a sentence to the Intro, referencing RFC7575's goal of "secure by default" > Appendix B doc> Discovery of registrar MAY also be performed with DNS-based ser= vice doc> discovery by searching for the service "_brski- doc> registrar._tcp.example.com". In this case the domain "example.com= " is doc> discovered as described in [RFC6763] section 11 (Appendix A.2 sugg= ests doc> the use of DHCP parameters). > I'd suggest using "" per 6763 rather than "example.com". okay. doc> If no local proxy or registrar service is located using the GRA= SP doc> mechanisms or the above mentioned DNS-based Service Discovery meth= ods doc> the pledge MAY contact a well known manufacturer provided bootstra= pping doc> server by performing a DNS lookup using a well known URI such as doc> "brski-registrar.manufacturer.example.com". The details of the UR= I are doc> manufacturer specific. Manufacturers that leverage this method on= the doc> pledge are responsible for providing the registrar service. Also = see doc> Section 2.7. > It seems like there are some security considerations for device owners > that may wish to prevent such registrars from being used. Do we need > to direct them to run a firewall or similar? If they are doing ANIMA ACP bootstrapping, then there would ideally be no IPv4 available, and so this won't work anyway. I'd rather not get into too much of this here. > Appendix C > I don't know how important file "ietf-mud-extension@2018-02-14.yang" > is, but it seems a tad generic. Renamed already. Ben, I'm posting the -25, and then moving on back to the responses to my responses, including Adam's concerns. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1RytkACgkQgItw+93Q 3WUGiQf/RR7gxzZwX+3u55AqgRH6SnP3lDEBPzLPT3J4ei2xIyMyXrv55b3rdo+T oh7T+H7rmjd8JAk4CvTnqVjCzv9yE04zBWEBDuGZjPoLUjqlJiwp8kXntqbSnCC/ nAXxsyNib4exCIXD12dR/kLGPL7MbGQlRab9RlHJPseLDeRB2yrb53ESvdeHyuYB oX4+CugRTPW+QRn76vTy2yTjET+ZUpR4D3NfosoNQq4hgWykfxIm8LF3oVw97yOV W2wzy6TL/z5qqe6s/OeKQHIVfYg/4JoA4fCSl+OFXT/5bf83uotP63sSVGjKbsj4 KjwdIQNkCpOn939vfVHukxjIU3tKeg== =CvrE -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 12 15:40:17 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B881214D0; Mon, 12 Aug 2019 15:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, 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 PzVLm2vBHtZE; Mon, 12 Aug 2019 15:40:07 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F98D12231C; Mon, 12 Aug 2019 12:10:23 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id BB2EC548014; Mon, 12 Aug 2019 21:10:17 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A6588440041; Mon, 12 Aug 2019 21:10:17 +0200 (CEST) Date: Mon, 12 Aug 2019 21:10:17 +0200 From: Toerless Eckert To: Brian E Carpenter Cc: draft-ietf-anima-grasp-api@ietf.org, "anima@ietf.org" Message-ID: <20190812191017.kcf5opzlzhixomkb@faui48f.informatik.uni-erlangen.de> References: <20190809194328.6232pr2w2giuq2ur@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) Archived-At: Subject: Re: [Anima] comments on draft-ietf-anima-grasp-api X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2019 22:40:16 -0000 On Sat, Aug 10, 2019 at 11:23:20AM +1200, Brian E Carpenter wrote: > Hi Toerless, > > If there was only one operating system in the world, I guess we could > describe this. The challenge I see is that the way to solve this may > be drastically different in different o/s environments, depending on > what sort of IPC is available between contexts. So apart from saying > that an implementation needs to do this, I'm not sure how much we can say. The transport of the API is of course always system specific. But thats not unique to the API between core and library, it equally extends to the API between library and ASA. So threre is IMHO no need to consider the library/core API to be any more proprietary than the ASA/library API. > I did try to build an IPC interface into my Python implementation, > but the only way I could see that produced portable code was to > use a standard socket as the IPC mechanism. That works, but it's > pretty clumsy and seems very inefficient for production use. None of the currently popular OSs seems to have OS mechanisms that would make API calls into a daemon as easy as they are into the OS kernel. Nevertheless, more and more services code gets built as daemons for flexiblity and modularily reasons. Just got to suck up the overhead and live with it. Not a GRASP specific issue. > However, it did show me that you are correct. There are some GRASP > functions that really need to be in a daemon** because they run on > their own even if there's no ASA in the node, and others that need > to be callable from multiple ASAs. The API as currently defined > only concerns those callable functions. You're actually asking for > the scope of the API draft to be expanded. I gave two options: Either eliminate the distinction between library and core or introduce better text to justify that distinction, and i think the strongest way to do that is to define the API between them. Which i think is not much different from the one ASA/library. > 2nd level however: The daemon and the callable functions need to share > some common stateful data structures, which I suppose are somewhat > implementation-dependent, but the ones I found necessary are: > > _asa_registry ??? where ASAs are registered > _obj_registry ??? where objectives are registered > _discovery_cache ??? where locators for discovered objectives are cached > _session_id_cache ??? where GRASP sesssion ids and ASA nonces are cached. > _flood_cache ??? where flooded objectives and their values are cached. I don't think you need to elaborate on that level of detail. Just think of the library as something that provides on its northbound the API you specified, and on its southbound to the core it uses almost the same API, and the only thing that the library can really do by itself is to directly build those TLS unicast connections to remote GRASP peers. So its really a demultiplexer between passing calls from/to the core and its own maintained TLS connections. > ** In fact I needed to provide a way to activate such a daemon, because > Michael and Bill discovered that they needed to do so by hand during > the hackathon last month. It's called gremlin.py and contains 4 lines > of code. IMHO, it should be started when system comes up. In a reasonable secure envirnment, a normal ASA shouldn't have permission to provide system level services, because ASA IMHO are more like user provided applications and each of them should be able to be less trustworthy than a system level function like GRASP discovery. One could say this is an implementation detail, but i think it would add one reason to talking about separarte library/core: Distinction between "ASA user" and system context. Cheers Toerless > Thanks > Brian > > P.S. We'll wait for Guangpeng's promised review before we revise the > draft. > > On 10-Aug-19 07:43, Toerless Eckert wrote: > > > > Hi Brian, * > > > > I have right now primarily a high level comment: > > > > The problem i have with the three layers of GRASP is that there > > is no good justification why they exist and why the API document > > needs to bother about them. The doc really only talks about the > > library of the GRASP Library. > > > > This is not to say that i do not like the idea to talk about the > > modularity of a GRASP implementation, its just not well motivated > > and executed i feel. > > > > So, one way to solve this is to also talk about the other APIs. > > > > For the extended function module, one could for example say > > any extensions to GRASP that are CAN BE implemented on top the > > GRASP API defined in this document SHOULD be implemented as > > a GRASP Function Module. And examples could be the functions > > suggested in my DNS drafts, or ther drafts you have that fit. > > So, thats the simple part. > > > > More interestingly, i would be a great fan of talking about the > > API between library and core, to justify why we want to think about > > this modularity. > > > > This is where the outline could be something like the following: > > > > Any peer-to-peer GRASP connection could and should be implemented > > in the context of the ASA, such as in a library compiled into the > > application. The reason is that this allows for greater > > confidentiality and mutual authentication then if it went through > > the GRASP core. Aka: any unicast message can ultimately have > > an originator authentication if the security and transport substrate > > used supports this. Which ACP does (TLS for ACP GRASP unicsast). > > > > On the other hand, all the multicast messages and the hop-by > > hop flooded unicast replies will have to be seen by each intervening > > nodes non-ASA specific GRASP core code and hence needs to be implemented > > in a common component called he GRASP core. For examplanation, the > > terms "system level" or "daemon" could be used. > > > > So as far as GRASP messages are concerned: > > ASA(GRASP-library)<->GRASP_core -link- GRASP-core -link- ... ASA > > M_FLOOD: hop-by-hop 'multicast' > > M_DISCOVERY: (constrained) hop-by-hop multicast > > M_RESPONSE: hop-by-hop unicast > > > > ASA(GRASP-library)<-...(TLS)...->ASA(GRASP-library) > > all unicasted messages except M_RESPONSE sent in > > reply to a multicast received M_DISCOVERY. > > > > So, there is a bit of work to do to go through the remainder > > of the document and figure out what to say about how each of > > the proposed API calls would operate at the GRASP API layer and > > at the GRASP_CORE layer. The way i imagine it, the API would > > be the same for both GRASP Core and GRASP Library except that > > i think we need to check which of the API calls need another > > (optional) locator parameter, because the whole goal of the exercise > > is that the GRASP library would create its own unicast GRASP socket(s) > > (e.g.: TLS) and that socket locator would need to be passed on via the > > API calls to the GRASP core where needed. > > > > And when that locator option is not given on the according API > > calls, then the unicast would go across unicast sockets created and > > kept only inside the GRASP Core . Which means that the GRASP > > libary would also be optional, but if an ASA runs directly > > on top of GRASP core only, then it would expose all > > potentially confidential objective value stuff to that > > shared GRASP core code. > > > > Also: When an ASA runs in an environment where it has cached > > its relevant peers locators, then it can operate without > > relying on the discovery service parts of GRASP and hence also > > without any GRASP cores involved, arguably making a service > > built on such ASA more resilient and maybe less prone to attacks. > > > > So, let me know if we can get this IMHO important high level aspect > > into the doc. If not, and if also can not find another reason to > > talk about a standardized API to the GRASP core then that text > > should better be moved to a non-specification section (informative > > only, appendix, etc. pp.) > > > > Cheers > > Toerless > > -- --- tte@cs.fau.de From nobody Mon Aug 12 18:22:37 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD42120043; Mon, 12 Aug 2019 18:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ra.rockwell.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_PamICOn3RF; Mon, 12 Aug 2019 18:22:32 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760053.outbound.protection.outlook.com [40.107.76.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 4FD36120025; Mon, 12 Aug 2019 18:22:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AM7Oz2WqIeXsjYOaJ+ctJtwDFkYoH44wUp0WmIfTxZxWV1K2pQhncz0gH+DtN4PyDQWBM2OoAxm2gs+ZnSyCoB0VTPT/qiT4+uY3txGDQMHL0sW0J9V4EOv6Xy4YhIZqTnFmje5NhrOQa7uqk9rQKNEtOOdpV0vHzR1ls+8AuqJxQp1895IEQ/sVzJ6R+7SZ5RU2QaTdx0+fkVcx5HrF08G5N+1TUxX3kIkW8P+0gvSnZd9Ku1KYYeTkzg3/5G2+ZH0hubO2/bPsLhQ9jCChExHMhy889z+iAXyFGCM5UmWCuozPL50flTYOSHtRO+ZGa0EVH9EPOJykgDvlmB4qXA== 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=haqNEoOjlwSlesUF4t5CJdcVLPt9wgtlUNlXHGMniO0=; b=f9mKrBfgN4BwUd9QvRjE1iuxoSxyCHPHLZxfmAK3QBjXbzbbYu11lEISzP6VwlWBYdL6bDxSOuwM7oS6w2Zs3ovXOH6fCg8Ld9ykgZ02Za/UMBh/lfpQzB17e0hKf4EFZvE1tGI0ARuX8YWv/GwJRN17y921VEN/UThpxPSs8CcPlLmfhtpjdg8WcYuWqJG6jMecgfo/L14khOYY+WUM8D+eRofthZv7idgl6lwI8CdW9hhoJ4q7NrfL9V3bvHiKlDvUwxQgIBBOmkE1wUHYura05Svzd2qFDl+rYB1c5c+ioa7f25YhOfaJkEEctcg7Rfe6fIcdHRFrpeztwklhWQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ra.rockwell.com; dmarc=pass action=none header.from=ra.rockwell.com; dkim=pass header.d=ra.rockwell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ra.rockwell.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=haqNEoOjlwSlesUF4t5CJdcVLPt9wgtlUNlXHGMniO0=; b=CfjmLSxNqRAbSqNo7YhfXyF1shVpiIjJ4OrZam8sMNGK++yx3DESjF/MwItbc9JHIl483qR8ggGA+Yznn4EWUhDTWEmN3XRzxWHdXGIupHR1dsO4D7KGAKI+H5WI5hqMTiXqeBcGMhH0ZfjatZQIrIGgAAeNcsGwdKg1Z+1zqNw= Received: from DM5PR2201MB1340.namprd22.prod.outlook.com (10.172.46.145) by DM5PR2201MB1115.namprd22.prod.outlook.com (10.174.186.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.22; Tue, 13 Aug 2019 01:22:31 +0000 Received: from DM5PR2201MB1340.namprd22.prod.outlook.com ([fe80::ad07:c135:5d24:2d31]) by DM5PR2201MB1340.namprd22.prod.outlook.com ([fe80::ad07:c135:5d24:2d31%5]) with mapi id 15.20.2157.022; Tue, 13 Aug 2019 01:22:31 +0000 From: Jack Visoky To: Toerless Eckert , Jack Visoky CC: Michael Richardson , "Randy Armstrong (OPC)" , "anima@ietf.org" , "iot-onboarding@ietf.org" , "Nancy Cam-Winget (ncamwing)" Thread-Topic: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI Thread-Index: AQHVUVxdgRb6CX16R0WZfClhC8rvu6b4R7gA Date: Tue, 13 Aug 2019 01:22:30 +0000 Message-ID: References: <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> <4671.1565279232@localhost> <19592.1565471757@localhost> <20190812185020.za2rtuo6bduhsu7i@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20190812185020.za2rtuo6bduhsu7i@faui48f.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jmvisoky@ra.rockwell.com; x-originating-ip: [205.175.250.244] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aee009d3-bf05-477b-21e0-08d71f8cb645 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:DM5PR2201MB1115; x-ms-traffictypediagnostic: DM5PR2201MB1115: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01283822F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(136003)(39860400002)(396003)(346002)(13464003)(199004)(189003)(8676002)(8936002)(66066001)(478600001)(81156014)(110136005)(186003)(7736002)(76116006)(6436002)(54906003)(316002)(7696005)(64756008)(66476007)(55016002)(66556008)(3846002)(2906002)(5660300002)(81166006)(6306002)(71190400001)(9686003)(14454004)(6116002)(229853002)(66446008)(33656002)(71200400001)(966005)(74316002)(6246003)(99286004)(486006)(52536014)(4326008)(86362001)(66946007)(11346002)(446003)(256004)(102836004)(53546011)(6506007)(25786009)(14444005)(305945005)(53936002)(476003)(76176011)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR2201MB1115; H:DM5PR2201MB1340.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ra.rockwell.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: EC1mwASQC1u+gdiBNCgw67PslylU/eF81FwB7zOE3nOrZ2wPDANSY1EMNi1KqJWW3hEfieoXpP5BYgCDqQqwTYpkQfip94reHhbnVbfwl+uvELggXbtfZty63YHVkY1qwV+bVW7IzOQR+mwOPCQJxH4wg6zLDzet5G3xzrIrCBiavgL4twT0l5XrR0eisiLTraTI29ovBR3MFvCYWHOSPsBblf6UK0dKBpDpBrkCGGmHK6Hw/uiir0sGqQxicCXTnpte4+TJYdXNdsVEvvL/UJXirsrrj1bnKdFvuoEthQV6kFKQzT+TjzrYOjbt6hvqI7LXRnx3uPoshps4HUG3amDw3+x6ysOn7bR/jhymN2HwZpEEbSpIeWp1lt7NDjm3O4V0adncM3Q7E6B9Nn1JVEI43B8dCDZsdmZFFBw5PMw= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ra.rockwell.com X-MS-Exchange-CrossTenant-Network-Message-Id: aee009d3-bf05-477b-21e0-08d71f8cb645 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2019 01:22:30.8731 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 855b093e-7340-45c7-9f0c-96150415893e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: N6/iyFmh0y/ASpJtWNxc1ho86HB6Gh2rqVhyzUdprBXgGTDzuJjhWJN7MeaMyPQqhMW+J1r3+xzKVrLSNFFNiWPRH/2chzoDVkAH2S/PFdc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2201MB1115 Archived-At: Subject: Re: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 01:22:35 -0000 Hi Toerless, Just responding to one of your points, a colleague of mine from Cisco (Nanc= y Cam-Winget) and I have created a draft for authentication-only data prote= ction for TLS 1.3. We've registered the cipher suites and will be going th= rough the Independent Review for this RFC soon. If you, Michael, or even o= thers would like to serve as reviewers we'd be grateful. Link to RFC: https://tools.ietf.org/html/draft-camwinget-tls-ts13-maccipher= suites-04=20 Thanks, --Jack -----Original Message----- From: Anima On Behalf Of Toerless Eckert Sent: Monday, August 12, 2019 2:50 PM To: Jack Visoky Cc: Michael Richardson ; Randy Armstrong (OPC) ; anima@ietf.org; iot-onboarding@ietf.org Subject: Re: [Anima] EXTERNAL: Re: [Iot-onboarding] OPC and BRSKI Agreeing to what Michael and you said, but also wanted to point out that TL= S as defined by IETF is on a trajectory which may or may not be desirable f= or e.g.: industrial automation (where OPC is used) or other regulated/ crit= ical environments. For example the total elimination of any non-encryption option in the TLS1.3 profile and the removal of the ability for passive observers to see = the certificates exchanged impeeds severely on the ability to do passive di= agnostics. I at least think there are good reasons to also have a strong and independe= nt reviewed authentication scheme without encryption that can well be diagn= osed by passive observers. Aspects like these are easily fixed IMHO by creating different profiles of = TLS. Whether or not one could get such profiles through the TLS WG in the I= ETF is of course a different question given what seems to be a highly conte= ntuous nature of the topic. There also seems to be a desire of areas of industrial automation to avoid = the overhead of a perceived to be redundant network layer. This was a thing= back in the days of OSI where TP4 was often run in factories without CLNS,= and given how IP hasn't really improved on simplified, automated address m= anagement vs. L2 switched ethernet, this still seems to be a thing. Aka: So= meone would need to define TLS on top of just ethernet instead of IP/IPv6. = And there may be other similar L2 "transport" technologies where its not cl= ear if simple ethernet mappings would suffice (bluetooth, wifi,...). Last but not least, QUIC is on a path to replace TLS and that too puts a de= nt into the belief that TLS as it stands would be a long term stable most-w= idely used protocol. Finally: There is something said to not simply trust a design like TLS whic= h you do not really understand just because its widely used, and thus hope= fully well reviewed, but rather make sure you have a design based on solid = understanding of the cryptographic principles employed and a well defined r= eview/control process of implementations. Incidents like with OpenSSL show= how badly reviewed even the most widely deployed crypto mechanisms can be. Cheers Toerless On Sun, Aug 11, 2019 at 09:31:22PM +0000, Jack Visoky wrote: > > but there are significant benefits to not maintaining your own protocol= s, and significant benefits to getting the extensive review that TLS gets. >=20 > I could not agree more with this statement. >=20 > Thanks, >=20 > --Jack >=20 >=20 > -----Original Message----- > From: Michael Richardson > Sent: Saturday, August 10, 2019 5:16 PM > To: Jack Visoky ; Randy Armstrong (OPC)=20 > ; iot-onboarding@ietf.org;=20 > anima@ietf.org > Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI >=20 >=20 > Jack Visoky wrote: > > I am also involved with OPC-UA and would like to provide my/my > > company's perspective. One of the major drivers of this engagement > > with the ANIMA group was a contentious point around whether or not = TLS > > and EST are required for support of BRSKI. Some of us had taken th= e > > position that these technologies are an integral part of BRSKI and > > shouldn't be replaced with OPC specific methods, especially given t= he > > benefit of using highly adopted security technologies, as well as t= he > > tight coupling of BRSKI to these. So, I think the idea that OPC sh= ould > > just use these technologies is very much a viable answer. >=20 > If the device is powered or has enough battery to do 802.11, then it prob= ably has enough power and code space to do TLS (particularly mbedtls from A= RM). > If it's on a very low duty cycle on battery, and/or it does 802.15.4,=20 > then the question is still open. The IETF may start work on a=20 > 802.15.4 specific AKE, (see lake@ietf.org). We believe we need these=20 > for 6tisch (TSCH mode of 802.15.4 for deterministic industrial=20 > networks) >=20 > It appears that the OPC UA methods provide enough security to do BRSKI, b= ut there are significant benefits to not maintaining your own protocols, an= d significant benefits to getting the extensive review that TLS gets. >=20 > > Also, I would strongly push back on any claims that low end OPC dev= ices > > cannot support TLS. Other industrial protocols have already added = TLS > > support and are shipping products, including those with TLS client > > functionality. TLS is no more heavy-weight than existing, OPC-spec= ific > > security mechanisms. >=20 > The OPC-specific mechanism appears to avoid a DH operation and therefore = lacks PFS. I understand it uses RSA, which means that it's significantly m= ore expensive than TLS with ECDSA (and ECDH) would be, and most SOCs have h= ardware acceleration for ECDSA's secp256v1, fewer have RSA acceleration. >=20 > > In any event I will be sure to join the call that has been set up f= or > > later in August. >=20 > Awesome. >=20 > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | IoT architec= t [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ >=20 >=20 > -- > Michael Richardson , Sandelman Software Works =20 > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima From nobody Mon Aug 12 21:09:59 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261EF120073; Mon, 12 Aug 2019 21:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Vs1fjTiQlqAi; Mon, 12 Aug 2019 21:09:56 -0700 (PDT) Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) (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 3C4DF12006F; Mon, 12 Aug 2019 21:09:56 -0700 (PDT) Received: by mail-pl1-x641.google.com with SMTP id y8so6613764plr.12; Mon, 12 Aug 2019 21:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=JPpuFSuB5cqaXvEwjjmDucb/WpNEp/pF807p4X8lJ4o=; b=L4xq7ChlgzQvltGzwrt1+rh4PbFuxycI06qzUUQICpesMyj6cZSNbenVGFC5Cm4H4G BgJVLDe3elME8J+wNYC8HTlD7kl8XspndYJDd9ZNw6bf9ku/KgUMzB+er2taHgpWxmLz ZWBKYqkrodEOVZe5Svt0+tmtRPiMKh/7OTT+cS4WAyPH4qbey2ac9ZxTUSqfwmiLDB1N wROxaO0Rd9+GC3aRYzdLfeAK70eOxbHLCVGbY8UQYakwBrSEQcUZkpCQ1x+6VmmnKIOq V+LTwQ1jEAWZEFz8AGbn5sANa9n8h5Q6jJuvMz7P1UmITqnDBsRz6zsB7RKZXndUftcY COfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=JPpuFSuB5cqaXvEwjjmDucb/WpNEp/pF807p4X8lJ4o=; b=HC7G9Q7HoHKbE8narlw62bEmi8sWLomWkz3NtEBxv/oXuAkoWhtXZ+BzGPpVNzCPR3 PrYKmPDDw+kAjX6i2LnseZXVEloMPwiae4aVmesJtUGx39gp/aJIr5CdHirngZ2Fu/Eu tDZdS5XxYARb+L7jW44lmtVKPlK6y4+5gm7JOp2SJhLBLpzNjwWAUJhH/BfLDcBqIYhs eLkg26THhNj+fQLZqPkVbTQnvOkvqCySytEBdbW/K+/sMkRfqs1dr+aiLQqGqJeMxsiH M2ZmhhelY9+Acn937Bg1cMKk9vnge6VhQEOkHy2FZLzoFYahfwngwLfgiCj5YzSJNaxc NawQ== X-Gm-Message-State: APjAAAUwNQbXvb1W09RMKuE26SBtyZdyZnzD9kGcCR8J7SqEoxJTuRWY vd1XuJmBoeqi7TIfWpCr9bkX6MqM X-Google-Smtp-Source: APXvYqxJhJYQ2yBjJNxpUoOX2uo/nw+U0bFTkscgAS8ZF78v3kZZCuRjJVEX3XkpCX3+mzutbAcKHQ== X-Received: by 2002:a17:902:f204:: with SMTP id gn4mr36412944plb.3.1565669395193; Mon, 12 Aug 2019 21:09:55 -0700 (PDT) Received: from [192.168.178.30] ([118.148.73.254]) by smtp.gmail.com with ESMTPSA id y128sm131664594pgy.41.2019.08.12.21.09.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Aug 2019 21:09:54 -0700 (PDT) To: Toerless Eckert Cc: draft-ietf-anima-grasp-api@ietf.org, "anima@ietf.org" References: <20190809194328.6232pr2w2giuq2ur@faui48f.informatik.uni-erlangen.de> <20190812191017.kcf5opzlzhixomkb@faui48f.informatik.uni-erlangen.de> From: Brian E Carpenter Message-ID: <0f9a1170-a141-5cd6-2274-01cf0f4e0aa7@gmail.com> Date: Tue, 13 Aug 2019 16:09:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <20190812191017.kcf5opzlzhixomkb@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Anima] comments on draft-ietf-anima-grasp-api X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 04:09:58 -0000 Hi Toerless, Yes, I think your model is correct. Three more comments below, then I will leave this alone until we revise the draft: On 13-Aug-19 07:10, Toerless Eckert wrote: > On Sat, Aug 10, 2019 at 11:23:20AM +1200, Brian E Carpenter wrote: >> Hi Toerless, >> >> If there was only one operating system in the world, I guess we could >> describe this. The challenge I see is that the way to solve this may >> be drastically different in different o/s environments, depending on >> what sort of IPC is available between contexts. So apart from saying >> that an implementation needs to do this, I'm not sure how much we can say. > > The transport of the API is of course always system specific. But thats > not unique to the API between core and library, it equally extends > to the API between library and ASA. So threre is IMHO no need to > consider the library/core API to be any more proprietary than the > ASA/library API. > >> I did try to build an IPC interface into my Python implementation, >> but the only way I could see that produced portable code was to >> use a standard socket as the IPC mechanism. That works, but it's >> pretty clumsy and seems very inefficient for production use. > > None of the currently popular OSs seems to have OS mechanisms that > would make API calls into a daemon as easy as they are into the > OS kernel. Nevertheless, more and more services code gets built > as daemons for flexiblity and modularily reasons. Just got to > suck up the overhead and live with it. Not a GRASP specific issue. > >> However, it did show me that you are correct. There are some GRASP >> functions that really need to be in a daemon** because they run on >> their own even if there's no ASA in the node, and others that need >> to be callable from multiple ASAs. The API as currently defined >> only concerns those callable functions. You're actually asking for >> the scope of the API draft to be expanded. > > I gave two options: Either eliminate the distinction between library > and core or introduce better text to justify that distinction, and > i think the strongest way to do that is to define the API between > them. Which i think is not much different from the one ASA/library. > >> 2nd level however: The daemon and the callable functions need to share >> some common stateful data structures, which I suppose are somewhat >> implementation-dependent, but the ones I found necessary are: >> >> _asa_registry ??? where ASAs are registered >> _obj_registry ??? where objectives are registered >> _discovery_cache ??? where locators for discovered objectives are cached >> _session_id_cache ??? where GRASP sesssion ids and ASA nonces are cached. >> _flood_cache ??? where flooded objectives and their values are cached. > > I don't think you need to elaborate on that level of detail. > Just think of the library as something that provides on its > northbound the API you specified, and on its southbound to the > core it uses almost the same API, Yes, that's essentially what my version with an IPC interface does, but I didn't release that to GitHub because it really is cobbled together and very Python-specific. > and the only thing that the > library can really do by itself is to directly build those > TLS unicast connections to remote GRASP peers. So its really > a demultiplexer between passing calls from/to the core and its > own maintained TLS connections. In fact I delegated all the TCP to the core as well, but that was an implementation choice not a necessity. > >> ** In fact I needed to provide a way to activate such a daemon, because >> Michael and Bill discovered that they needed to do so by hand during >> the hackathon last month. It's called gremlin.py and contains 4 lines >> of code. > > IMHO, it should be started when system comes up. Yes. Just for fun, it does now come up when my laptop boots, but there doesn't seem to be any other GRASP traffic on my home LAN :-(. Brian > In a reasonable secure > envirnment, a normal ASA shouldn't have permission to provide > system level services, because ASA IMHO are more like user provided > applications and each of them should be able to be less trustworthy > than a system level function like GRASP discovery. > > One could say this is an implementation detail, but i think it would > add one reason to talking about separarte library/core: Distinction > between "ASA user" and system context. > > Cheers > Toerless > >> Thanks >> Brian >> >> P.S. We'll wait for Guangpeng's promised review before we revise the >> draft. >> >> On 10-Aug-19 07:43, Toerless Eckert wrote: >>> >>> Hi Brian, * >>> >>> I have right now primarily a high level comment: >>> >>> The problem i have with the three layers of GRASP is that there >>> is no good justification why they exist and why the API document >>> needs to bother about them. The doc really only talks about the >>> library of the GRASP Library. >>> >>> This is not to say that i do not like the idea to talk about the >>> modularity of a GRASP implementation, its just not well motivated >>> and executed i feel. >>> >>> So, one way to solve this is to also talk about the other APIs. >>> >>> For the extended function module, one could for example say >>> any extensions to GRASP that are CAN BE implemented on top the >>> GRASP API defined in this document SHOULD be implemented as >>> a GRASP Function Module. And examples could be the functions >>> suggested in my DNS drafts, or ther drafts you have that fit. >>> So, thats the simple part. >>> >>> More interestingly, i would be a great fan of talking about the >>> API between library and core, to justify why we want to think about >>> this modularity. >>> >>> This is where the outline could be something like the following: >>> >>> Any peer-to-peer GRASP connection could and should be implemented >>> in the context of the ASA, such as in a library compiled into the >>> application. The reason is that this allows for greater >>> confidentiality and mutual authentication then if it went through >>> the GRASP core. Aka: any unicast message can ultimately have >>> an originator authentication if the security and transport substrate >>> used supports this. Which ACP does (TLS for ACP GRASP unicsast). >>> >>> On the other hand, all the multicast messages and the hop-by >>> hop flooded unicast replies will have to be seen by each intervening >>> nodes non-ASA specific GRASP core code and hence needs to be implemented >>> in a common component called he GRASP core. For examplanation, the >>> terms "system level" or "daemon" could be used. >>> >>> So as far as GRASP messages are concerned: >>> ASA(GRASP-library)<->GRASP_core -link- GRASP-core -link- ... ASA >>> M_FLOOD: hop-by-hop 'multicast' >>> M_DISCOVERY: (constrained) hop-by-hop multicast >>> M_RESPONSE: hop-by-hop unicast >>> >>> ASA(GRASP-library)<-...(TLS)...->ASA(GRASP-library) >>> all unicasted messages except M_RESPONSE sent in >>> reply to a multicast received M_DISCOVERY. >>> >>> So, there is a bit of work to do to go through the remainder >>> of the document and figure out what to say about how each of >>> the proposed API calls would operate at the GRASP API layer and >>> at the GRASP_CORE layer. The way i imagine it, the API would >>> be the same for both GRASP Core and GRASP Library except that >>> i think we need to check which of the API calls need another >>> (optional) locator parameter, because the whole goal of the exercise >>> is that the GRASP library would create its own unicast GRASP socket(s) >>> (e.g.: TLS) and that socket locator would need to be passed on via the >>> API calls to the GRASP core where needed. >>> >>> And when that locator option is not given on the according API >>> calls, then the unicast would go across unicast sockets created and >>> kept only inside the GRASP Core . Which means that the GRASP >>> libary would also be optional, but if an ASA runs directly >>> on top of GRASP core only, then it would expose all >>> potentially confidential objective value stuff to that >>> shared GRASP core code. >>> >>> Also: When an ASA runs in an environment where it has cached >>> its relevant peers locators, then it can operate without >>> relying on the discovery service parts of GRASP and hence also >>> without any GRASP cores involved, arguably making a service >>> built on such ASA more resilient and maybe less prone to attacks. >>> >>> So, let me know if we can get this IMHO important high level aspect >>> into the doc. If not, and if also can not find another reason to >>> talk about a standardized API to the GRASP core then that text >>> should better be moved to a non-specification section (informative >>> only, appendix, etc. pp.) >>> >>> Cheers >>> Toerless >>> > From nobody Tue Aug 13 06:19:31 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7992D120130; Tue, 13 Aug 2019 06:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=lMsrE/Ns; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WtpKa0d2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0uKQ0D0fVrW; Tue, 13 Aug 2019 06:19:19 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C860120152; Tue, 13 Aug 2019 06:19:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6471; q=dns/txt; s=iport; t=1565702359; x=1566911959; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ZetzCCH3Yw/1B1PuzSOLxdJWFXmyk013nvGXuXD//1E=; b=lMsrE/Ns9V/mhQ/WkjqyCf0q4nPpaC52iisykLwcUQa+/E+3IGgBUJQa 1lcRU3DX3FvTsFTC9ZE7t1lFsC2kztEV5FmMjJxaysRuzDcKzQt8+Sf+8 rYrn9vUsAM0pSem70vF/LYaOmerYDYUBtykkLpwub+4rkpfrfPVEfPGru g=; IronPort-PHdr: =?us-ascii?q?9a23=3AI7dwnxCe99Cjy3ywSaE8UyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qg83kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuK/DwbiE+NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAACEuFJd/5ldJa1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVQIBAQEBAQsBgUQkBScDbVUgBAsqCodbA4sOgluXYoE?= =?us-ascii?q?ugSQDVAkBAQEMAQEYCwoCAQGBS4J0AoJ6IzYHDgEEAQEEAQEEAQpthScMhUo?= =?us-ascii?q?BAQEBAwEBECgGAQEsCwELBAIBCA4DBAEBAR4QJwsdCAIEAQ0FCBqCNUyBagM?= =?us-ascii?q?dAQ6hZgKBOIhggiWCegEBBYE3AoNEGIIUCYE0AYohgUMXgUA/gRFGgkw+gmE?= =?us-ascii?q?BAQIBgR0lHoM7giaMGAc9ngVtCQKCHYZjixiCUpg9jVWHX5AkAgQCBAUCDgE?= =?us-ascii?q?BBYFXAy6BWHAVO4JsCYI5DBeCe1SFFIU/cgEBgSeNLAGBIAEB?= X-IronPort-AV: E=Sophos;i="5.64,381,1559520000"; d="scan'208";a="613296185" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Aug 2019 13:19:17 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x7DDJHvj006062 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 13 Aug 2019 13:19:17 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 13 Aug 2019 08:19:17 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 13 Aug 2019 08:19:16 -0500 Received: from NAM05-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 13 Aug 2019 08:19:16 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WXNDrwoF7pmVTJQFHow1Z+xfA/uEHDmofzrSL0bpzSvGj+4sXQWGQkTeQOnVzroKYh3EVFHC88NJnCuKvN4djf33SWu3EBS1YH9N5tuf/QiUGqVJFbizmpk8fTWntGZaKI1lOSKjlJBSsJNtmwYTIDGw43fS5C8l7kDisxj2c3G5YVZSmysC2qkJqWxs4Cliz5AcWvZgLpvM3eoUs6TpuJ8K3SQ4p+lNBtH8VQNG3mLHEOklCUA4rz2iO2idhe5/FeTxz+TC5E5ynXhw85d+2M1+wx9HNnCpHo2IN/nbN18Mg30NsyqZBeGOdsuHsd6Twn/w4Z7EzaQYhhLR9q7lng== 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=hocd6+wFQWw+EbpiLNBAHM0T5ocNlqJhIaSaZUtT13w=; b=Rylkk88IYBpZRvDnNH57Bw7eQ16/PjIAyBM1/lUYjZIxaTnpWh0cYYEDr5xD4M/xpteP7+W4jmxQaiXz2Iv4p8J6k7+gNXUAFdG9O5vyO/BGFquPEeQiBzXl41w1vcXPmrL5nRXvGG6a7wMU8mmbbZMOK3thwohZGZipy/pL2wk9s0OkA8yp540mDTAzv0pchxdXo14NPTWPzzPLYKtlzI00KxfbLb88ExeS3+jhG3DPs4EjB/EMaua7hm7eIViKVWiGyqMPLnMgy1bgFIb8EVAyIekYS5Qb8j/4iLqlFiG/ssuD35gOertbybdIOBd0iZNGFBVodHZZd9X3loBA6A== 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=hocd6+wFQWw+EbpiLNBAHM0T5ocNlqJhIaSaZUtT13w=; b=WtpKa0d2RRvgKbkoYDEXsn/1xDvOKx09HWJWMT+00iI75RSYoHDpfXcEbGGuDZQwHOrFUCnkH/jYLhwdFD4IfLmur0w/syzmOaVjp4Ls58vaFLt/FQxCX2Y7ILhoLZkxiLMxXTFmrijx5ZL/gywlfKYDzTybXPXEog4US6wYD0I= Received: from CY4PR1101MB2278.namprd11.prod.outlook.com (10.172.76.13) by CY4PR1101MB2245.namprd11.prod.outlook.com (10.172.79.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2157.16; Tue, 13 Aug 2019 13:19:15 +0000 Received: from CY4PR1101MB2278.namprd11.prod.outlook.com ([fe80::c060:dedd:1c7e:cf11]) by CY4PR1101MB2278.namprd11.prod.outlook.com ([fe80::c060:dedd:1c7e:cf11%12]) with mapi id 15.20.2157.022; Tue, 13 Aug 2019 13:19:15 +0000 From: "Owen Friel (ofriel)" To: Toerless Eckert , Jack Visoky CC: Michael Richardson , "Randy Armstrong (OPC)" , "anima@ietf.org" , "iot-onboarding@ietf.org" Thread-Topic: [Iot-onboarding] [Anima] EXTERNAL: Re: OPC and BRSKI Thread-Index: AQHVUVxfgQd3rVTIeESwtoKXZYIhOKb5ECEA Date: Tue, 13 Aug 2019 13:19:14 +0000 Message-ID: References: <46BF5F7B-5407-45A9-9C4F-EA553DF5814B@cisco.com> <11781.1565189957@localhost> <20190807172252.4sadxaiprm6hhmdy@faui48f.informatik.uni-erlangen.de> <4671.1565279232@localhost> <19592.1565471757@localhost> <20190812185020.za2rtuo6bduhsu7i@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20190812185020.za2rtuo6bduhsu7i@faui48f.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [64.103.40.17] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2fe26672-de5b-4295-76b6-08d71ff0d6e9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CY4PR1101MB2245; x-ms-traffictypediagnostic: CY4PR1101MB2245: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01283822F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(39860400002)(376002)(346002)(396003)(189003)(199004)(13464003)(8676002)(4326008)(26005)(2906002)(6116002)(446003)(11346002)(14454004)(14444005)(256004)(476003)(81166006)(81156014)(99286004)(316002)(76176011)(7696005)(3846002)(6246003)(5660300002)(8936002)(110136005)(25786009)(64756008)(66946007)(71190400001)(74316002)(66066001)(305945005)(7736002)(66446008)(66476007)(478600001)(33656002)(186003)(966005)(71200400001)(53936002)(486006)(53546011)(6506007)(6306002)(6436002)(102836004)(55016002)(76116006)(52536014)(9686003)(86362001)(229853002)(66556008)(54906003); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1101MB2245; H:CY4PR1101MB2278.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: WWQOdivRCmjF2gPU7PGogkA8VkC+9n2zZnK+KHnt4C5DqZRT6Smk7r3h/Y21Pi41aoPXJ50EYcMN2Wh75doHXczFSV42sK7trvUTCelHtXfWpCsT7Q0Vw6Q5uROV/qtfdxdVJVKtsF6eBgFYd+KmfZJBM1LlcEIJAe0Xf8rdVhulSRiQkbWFPxR9TWMhUuCQ0SmLJlhK55fQqXSksz6fSjz5oMVTeimku7I1eH24NbRDCdRjn/vIYf61sA0Hxi1AiWNOKXnu/JomkwiRe/KoFfQjzohXMQHHG6AvsFMuq7vGqbl+hJSXV43EzpL/8gkrdSO3qNZM7X1CUOUHca7zd4WqffV3GxwBJgaY+tU2ZeMIILzU6VNkcyLCy9xAhDGnUsVbmeVyn++RwRMN39zY5CZcbkYxFzc+uZJBrrhBAOk= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2fe26672-de5b-4295-76b6-08d71ff0d6e9 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Aug 2019 13:19:15.1512 (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: SXTQsG014vtQLBOwySD9jAeK45lqOT5CPZ49dtSBWQyedUHqtLCjJyk+SMrsB2m4znp5/GfexBwgTSxEkWy7DA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2245 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [Anima] [Iot-onboarding] EXTERNAL: Re: OPC and BRSKI X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 13:19:22 -0000 -----Original Message----- From: Iot-onboarding On Behalf Of Toerles= s Eckert Sent: 12 August 2019 19:50 To: Jack Visoky Cc: Michael Richardson ; Randy Armstrong (OPC) ; anima@ietf.org; iot-onboarding@ietf.org Subject: Re: [Iot-onboarding] [Anima] EXTERNAL: Re: OPC and BRSKI Agreeing to what Michael and you said, but also wanted to point out that TL= S as defined by IETF is on a trajectory which may or may not be desirable f= or e.g.: industrial automation (where OPC is used) or other regulated/ crit= ical environments. For example the total elimination of any non-encryption option in the TLS1.3 profile and the removal of the ability for passive observers to see = the certificates exchanged impeeds severely on the ability to do passive di= agnostics. I at least think there are good reasons to also have a strong and independe= nt reviewed authentication scheme without encryption that can well be diagn= osed by passive observers. Aspects like these are easily fixed IMHO by creating different profiles of = TLS. Whether or not one could get such profiles through the TLS WG in the I= ETF is of course a different question given what seems to be a highly conte= ntuous nature of the topic. There also seems to be a desire of areas of industrial automation to avoid = the overhead of a perceived to be redundant network layer. This was a thing= back in the days of OSI where TP4 was often run in factories without CLNS,= and given how IP hasn't really improved on simplified, automated address m= anagement vs. L2 switched ethernet, this still seems to be a thing. Aka: So= meone would need to define TLS on top of just ethernet instead of IP/IPv6. = And there may be other similar L2 "transport" technologies where its not cl= ear if simple ethernet mappings would suffice (bluetooth, wifi,...). Last but not least, QUIC is on a path to replace TLS and that too puts a de= nt into the belief that TLS as it stands would be a long term stable most-w= idely used protocol. [ofriel] Its more accurate to say that QUIC is going to replace TCP. QUIC w= ill be secured using TLS: https://tools.ietf.org/html/draft-ietf-quic-tls-2= 2 Finally: There is something said to not simply trust a design like TLS whic= h you do not really understand just because its widely used, and thus hope= fully well reviewed, but rather make sure you have a design based on solid = understanding of the cryptographic principles employed and a well defined r= eview/control process of implementations. Incidents like with OpenSSL show= how badly reviewed even the most widely deployed crypto mechanisms can be. Cheers Toerless On Sun, Aug 11, 2019 at 09:31:22PM +0000, Jack Visoky wrote: > > but there are significant benefits to not maintaining your own protocol= s, and significant benefits to getting the extensive review that TLS gets. >=20 > I could not agree more with this statement. >=20 > Thanks, >=20 > --Jack >=20 >=20 > -----Original Message----- > From: Michael Richardson > Sent: Saturday, August 10, 2019 5:16 PM > To: Jack Visoky ; Randy Armstrong (OPC)=20 > ; iot-onboarding@ietf.org;=20 > anima@ietf.org > Subject: Re: EXTERNAL: Re: [Anima] [Iot-onboarding] OPC and BRSKI >=20 >=20 > Jack Visoky wrote: > > I am also involved with OPC-UA and would like to provide my/my > > company's perspective. One of the major drivers of this engagement > > with the ANIMA group was a contentious point around whether or not = TLS > > and EST are required for support of BRSKI. Some of us had taken th= e > > position that these technologies are an integral part of BRSKI and > > shouldn't be replaced with OPC specific methods, especially given t= he > > benefit of using highly adopted security technologies, as well as t= he > > tight coupling of BRSKI to these. So, I think the idea that OPC sh= ould > > just use these technologies is very much a viable answer. >=20 > If the device is powered or has enough battery to do 802.11, then it prob= ably has enough power and code space to do TLS (particularly mbedtls from A= RM). > If it's on a very low duty cycle on battery, and/or it does 802.15.4,=20 > then the question is still open. The IETF may start work on a=20 > 802.15.4 specific AKE, (see lake@ietf.org). We believe we need these=20 > for 6tisch (TSCH mode of 802.15.4 for deterministic industrial=20 > networks) >=20 > It appears that the OPC UA methods provide enough security to do BRSKI, b= ut there are significant benefits to not maintaining your own protocols, an= d significant benefits to getting the extensive review that TLS gets. >=20 > > Also, I would strongly push back on any claims that low end OPC dev= ices > > cannot support TLS. Other industrial protocols have already added = TLS > > support and are shipping products, including those with TLS client > > functionality. TLS is no more heavy-weight than existing, OPC-spec= ific > > security mechanisms. >=20 > The OPC-specific mechanism appears to avoid a DH operation and therefore = lacks PFS. I understand it uses RSA, which means that it's significantly m= ore expensive than TLS with ECDSA (and ECDH) would be, and most SOCs have h= ardware acceleration for ECDSA's secp256v1, fewer have RSA acceleration. >=20 > > In any event I will be sure to join the call that has been set up f= or > > later in August. >=20 > Awesome. >=20 > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | IoT architec= t [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ >=20 >=20 > -- > Michael Richardson , Sandelman Software Works =20 > -=3D IPv6 IoT consulting =3D- >=20 >=20 >=20 > _______________________________________________ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima -- --- tte@cs.fau.de -- Iot-onboarding mailing list Iot-onboarding@ietf.org https://www.ietf.org/mailman/listinfo/iot-onboarding From nobody Tue Aug 13 08:37:53 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E40A1201E3; Tue, 13 Aug 2019 08:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 AHjizdkvv-Di; Tue, 13 Aug 2019 08:37:49 -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 DC725120219; Tue, 13 Aug 2019 08:37:48 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 462CF3818C; Tue, 13 Aug 2019 11:37:01 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4F1E5E8E; Tue, 13 Aug 2019 11:37:47 -0400 (EDT) From: Michael Richardson To: Adam Roach cc: Benjamin Kaduk , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, The IESG , anima-chairs@ietf.org In-Reply-To: References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <12747.1563315277@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 15:37:53 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Adam Roach wrote: >> Adam Roach: https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsK= EsbIUmXRVOAV0N83yA >> ... >> This is an rfcdiff from the already-wrapped JSON to the proposed -23= that >> includes all the changes from the various DISCUSSes up to now: >> https://tinyurl.com/y2qhjwh8 > As a quick note -- the diff above does not address the "discuss" part= of my > second discuss point: the document remains ambiguous regarding *how* = the URL > is to be returned. The lengthy parenthetical references added to the > corresponding paragraph aren't sufficient to positively indicate that= the URL > appears in a "Location" header: this needs to be stated explicitly ra= ther > than implied by a section reference. I had previously updated to point to RFC7231 section 6.3.2, but upon careful reading, I see that returning the URL in the Location: is not mandated by 6.3.2. I am a little bit surprised that 7231 is so vague on what I thought was a pretty much written in stone process.... Rather than returning the audit log as a response to the POST (w= ith a return code 200), the MASA MAY instead return a 201 ("Created") =2D response ( sections 6.3.2 and 7.1) = containing =2D a URL to the prepared (and idempotent, therefore cachable) aud= it response. + response ( sections 6.3.2 and 7.1), w= ith + the URL to the prepared (and idempotent, therefore cachable) aud= it + response in the Location: header. Does this fix things for you? =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1S2UsACgkQgItw+93Q 3WUUOQf+NVwumO9U6c9AfTt7NA0EaJph4ujkm8s+N1HWCVXBIha90OppJIbi7Hbf Av3RY9H69lxsx/3SzJ2F6RqzdxwFMTYUqMwl9zNIXnk8eSZgbwb+2yAaril9bWZc SBLiVRXWDPcCaDRMMgg4u4qh9kpKT3kI/vkNw5/qItWO2RAdne/ExrGLVyA5SPwJ 2ACrX9wRpdN2gH112Kt+J5/sYdoA3hfmbe8LAi6ly2D61HqSLqrkik7ss9FuzQDW wqgbED3+8t4Uxi9bVp8zGOq4aw7Q9BsFRbNJqr0+2fv6i/0J7+LLoT/PoxqgWkQa XUWvPA+eGmB70vV3X0KcnSKaAIiPoA== =s+u5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 13 10:25:54 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9221200D6; Tue, 13 Aug 2019 10:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 5vlrFZUqR_EK; Tue, 13 Aug 2019 10:25:46 -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 90D2C12011C; Tue, 13 Aug 2019 10:25:46 -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 x7DHPXUh020899 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Aug 2019 13:25:36 -0400 Date: Tue, 13 Aug 2019 12:25:33 -0500 From: Benjamin Kaduk To: Michael Richardson Cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org Message-ID: <20190813172532.GM88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <25503.1565496367@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25503.1565496367@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 17:25:52 -0000 On Sun, Aug 11, 2019 at 12:06:07AM -0400, Michael Richardson wrote: > > https://tinyurl.com/yylruorn contains an updated diff against -24. > > Benjamin Kaduk via Datatracker wrote: > > Section 5.2 > > > application/voucher-cms+json The request is a "YANG-defined JSON > > document that has been signed using a CMS structure" as described > > in Section 3 using the JSON encoding described in [RFC7951]. This > > > Section 3 does not describe any "sign[ing] using a CMS structure" > > operation. > > Yes, I see, the sentence structure is wrong. I have changed it: > > > - application/voucher-cms+json The request is a "YANG-defined JSON > - document that has been signed using a CMS structure" as described > - in Section 3 using the JSON encoding described in [RFC7951]. This > - voucher media type is defined in [RFC8366] and is also used for > - the pledge voucher-request. The pledge SHOULD sign the request > - using the Section 2.3 credential. > > + application/voucher-cms+json [RFC8366] defines a "YANG-defined JSON > + document that has been signed using a CMS structure", and the > + voucher-request described in Section 3 is created in the same way. > + The media type is the same as defined in [RFC8366]. and is also > + used for the pledge voucher-request. The pledge MUST sign the > + request using the Section 2.3 credential. > > > > To be clear, this is MUST sign, but SHOULD use IDevID (vs. some other > > credential) to sign? > > It was SHOULD, because we supported unsigned voucher requests, but we removed > that option. It is now MUST. > > > constrained voucher formats are expected in the future. Registrar's > > and MASA's are expected to be flexible in what they accept. > > > nits: no apostrophes for plurals. > > done. > > > proximity-registrar-cert: In a pledge voucher-request this is the > > first certificate in the TLS server 'certificate_list' sequence > > (see [RFC5246]) presented by the registrar to the pledge. This > > MUST be populated in a pledge voucher-request if the "proximity" > > assertion is populated. > > > [same comment as above about "end-entity certificate"] > > done. > > > The registrar validates the client identity as described in EST > > [RFC7030] section 3.3.2. The registrar confirms that the 'proximity' > > assertion and associated 'proximity-registrar-cert' are correct. > > > what 'proximity' assertion? > > Does verifying proximity-registrar-cert just mean checking that it's the > > same leaf certificate that the registrar presented? What happens if the > > validation fails? > > Yes, it means confirming that the pinned certificate is one's own. > If it fails, then there is a MITM, and the connection should be closed. > {I will use "MITM" until someone tells if me we are using a different term} > > I've split that paragraph up, as there are two thoughts, one is about the > ClientCertificate, and the other is about the pinned certificate. > > The registrar validates the client identity as described in EST > - [RFC7030] section 3.3.2. The registrar confirms that the 'proximity' > - assertion and associated 'proximity-registrar-cert' are correct. > + [RFC7030] section 3.3.2. > + > + The registrar confirms that the assertion is 'proximity' and that > + pinned 'proximity-registrar-cert' is the Registrar's certificate. If > + this validation fails, then there a On-Path Attacker (MITM), and the > + connection MUST be closed after the returning an HTTP 401 error code. > > > Section 5.3 > > doc> A Registrar accepts or declines a request to join the domain, based > doc> on the authenticated identity presented. Automated acceptance > doc> criteria include: > > > I suggest "for different networks, examples of automated acceptance > > criteria may include". > > doc> If these validations fail the registrar SHOULD respond with an > doc> appropriate HTTP error code. > > > Similarly, "If validation fails". > > done. > > > Section 5.4 > > doc> The BRSKI-MASA TLS connection is a 'normal' TLS connection > doc> appropriate for HTTPS REST interfaces. The registrar initiates the > doc> connection and uses the MASA URL obtained as described in Section 2.8 > doc> for [RFC6125] authentication of the MASA. > > > I'd consider mentioning the implicit trust anchor database as well as > > the MASA URL. > > edits for another review changed this to: > The BRSKI-MASA TLS connection is a 'normal' TLS connection > appropriate for HTTPS REST interfaces. The registrar initiates the > connection and uses the MASA URL obtained as described in > Section 2.8. The mechanisms in [RFC6125] SHOULD be used > authentication of the MASA. Some vendors will establish explicit (or > private) trust anchors for validating their MASA; this will typically > done as part of a sales channel integration. Registars SHOULD permit > trust anchors to be pre-configured on a per-vendor basis. That works for me ... or perhaps, "great minds think alike"? > doc> The MASA and the registrars SHOULD be prepared to support TLS client > doc> certificate authentication and/or HTTP Basic or Digest authentication > doc> as described in [RFC7030] for EST clients. This connection MAY also > doc> have no client authentication at all (Section 7.4) > > > I don't see discussion of skipping client authentication in Section 7.4. > > It would be great to have some, there! > > It's buried in point 2. Oh, the "not verifying ownership" part? I somehow was interpreting that as "we still require client authentication, but don't have a fancy database mapping owner to hardware, so any authenticated registrar can get a voucher for any device". > I moved text from 7.4 into a new 5.4.1, I created 7.4.1/7.4.2 so that it > could be forward referenced. Diff too long here, see link above. The text in the diff is more clear about what is going on, thanks. (Though I think "tradeoffs" is usually just written as one word.) > doc> The authentication of the BRSKI-MASA connection does not affect the > doc> voucher-request process, as voucher-requests are already signed by > doc> the registrar. Instead, this authentication provides access control > doc> to the audit log. > > > I don't understand what "access control to the audit log" means. Is the > > idea that the TLS client identity in the BSRKI-MASA connection is only > > used when processing requests to the requestauditlog endpoint and that > > some clients might be denied access? > > The audit log reveals who owns what. Revealing it to strangers would be a problem. > So in order to get access to the audit log for device FOO, one presents a > voucher-request for FOO. Since the request contains a serial-number and a > mapping to an owner, we use that as an access key to get the audit-log. > The identity that the MASA sees in the HTTPS request (ClientCertificate > preferred), says who is asking. > > What can I fix here? Well, I think a lot of my confusion stemmed from the lack of advance definition of "MASA Audit Log" as a protocol element, which you already fixed. So what's left would seem to mostly be a question of whether something about "access control" vs. "authorization to access the relevant subset of the audit log" is a more accurate description of what's going on. That is, whether "access control" is something done by a server (MASA)-side agent applying policy, or ... something else that I don't know how to describe well. > > Section 5.5 > > doc> created-on: Registrars are RECOMMENDED to populate this field. This > doc> provides additional information to the MASA. > > > Earlier we said that this field would be propagated from the pledge > > voucher-request; we should probably say something like "populate this > > field; if it was present in the pledge voucher-request it is copied > > unchanged to the registrar voucher-request; otherwise the current time > > is used". > > That create-on is the time on the Registrar, not on the pledge. It currently > says: > > The registrar populates the voucher-request fields as follows: > > created-on: The Registrars SHOULD populate this field with the > current date and time when the Registrar formed this voucher > request. This field provides additional information to the MASA. Hmm, I'm trying to look for why I claimed that "earlier we said that this field would be propagated". Section 3.3 (of the -22)'s Example (2) says "[t]he nonce, created-on and assertion is carried forward", and Section 5.2 wants pledges to populate it as well. So the idea is that the MASA is only going to get the pledge's created-on via the prior-signed-voucher-request (if present)? I'm confused about what it means to "carry forward" the created-on if the registrar is populating it anew, though. > > nonce: This is the value from the pledge voucher-request. The > > registrar voucher-request MAY omit the nonce as per Section 3.1) > > > I'd suggest "value from the pledge voucher-request, if present" and > > changing the second sentence to refer to the pledge voucher-request. > > I've written: > > nonce: This value, if present, is copied from the pledge voucher- > request. The registrar voucher-request MAY omit the nonce as per > Section 3.1. > > It's up to the Registrar whether to include the nonce. > A registrar may issue a voucher-request on it's own, if it is trying to get > an offline voucher. > > > idevid-issuer: The idevid-issuer value from the pledge certificate > > is included to ensure a statistically unique identity. > > > There is no "idevid-issuer" field in the pledge certificate; I assume > > this is supposed to be the Issuer Name of the IDevID certificate. > > Changed to: > idevid-issuer: The Issuer value from the value from the pledge nit: duplicated "value from the" > IDevID certificate is included to ensure a uniqueness of the > serial-number. In the case of nonceless (offline) voucher- > request, then an appropriate value needs to be configured from the > same out-of-band source as the serial-number. > > > > prior-signed-voucher-request: The signed pledge voucher-request > > SHOULD be included in the registrar voucher-request. (NOTE: what > > is included is the complete pledge voucher-request, inclusive of > > the 'assertion', 'proximity-registrar-cert', etc wrapped by the > > pledge's original signature). If a signed voucher-request was not > > recieved from the pledge then this leaf is omitted from the > > registrar voucher request. > > > This is a good example of text that implies the signed voucher is > > binary. (And as such would be a good place to talk about the base64 > > encoding.) > > okay, done. > > > All other fields MAY be omitted in the registrar voucher-request. > > > Should the proximity-registrar-cert field *not* be present? > > Correct, it's from the pledge->registrar. So it's more of a "MUST NOT" than a "MAY not", here? > > Section 5.5.2 > > doc> The MASA MUST verify that the registrar voucher-request is signed by > doc> a registrar. This is confirmed by verifying that the id-kp-cmcRA > doc> extended key usage extension field (as detailed in EST RFC7030 > doc> section 3.6.1) exists in the certificate of the entity that signed > doc> the registrar voucher-request. This verification is only a > doc> consistency check that the unauthenticated domain CA intended the > doc> voucher-request signer to be a registrar. Performing this check > doc> provides value to the domain PKI by assuring the domain administrator > doc> that the MASA service will only respect claims from authorized > doc> Registration Authorities of the domain. > > > If the MASA has no prior knowledge of the domain (certificate), this is > > susceptible to anyone spinning up something that claims to be a domain > > CA and issuing registrar certs with that extension. We need to document > > somewhere what other part of the system prevents that from causing an > > unauthorized voucher to be used. (Perhaps preventing one from being > > issued is not feasible, but acceptable if the pledge will not accept > > it, though there remains risk of DoS on the MASA.) > > The ability for someone to spin up a domain is part one of the ways that the > MASA MAY operate in the absense of supply chain integration. The audit-log > is the defense against this. If the MASA does not want to do business with > such entities, then it just doesn't. The audit log is a defense against this in that it allows for post-facto discovery of misuse? Or is there some pre-issuance authorization check going on. I think I may need some section references to where the authorization policy (options) are documented; I've lost a bit of state on this one. > > Section 5.5.3 > > doc> If a nonceless voucher-request is submitted the MASA MUST > doc> authenticate the registrar as described in either EST [RFC7030] > doc> section 3.2, section 3.3, or by validating the registrar's > > > Subsubsection references might be more helpful. > > done. > > doc> In the nonced case, validation of the registrar MAY be omitted if the > doc> device policy is to accept audit-only vouchers. > > > I don't see any (SHOULD?) guidance about validating the registrar in the > > nonced case when other policy is used. Even the previous section does > > not really say much to indicate there is value in authenticating the > > signature on the voucher request. > > The signature on the pledge voucher-request is always validated. > The signature on the registrar voucher-request is also always validated. > What's optional is validating the TLS ClientCertificate/HTTP of the > Registrar. > > I've added a few words to say this. Ah, that helps a lot. > > Section 5.5.4 > > doc> authentication or voucher-request signature validation. Similarly, > doc> as noted in Section 5.5.2, the MASA performs normal PKIX revocation > doc> checking during signature consistency checks (a signature by a > doc> registrar certificate that has been revoked is an inconsistency). > > > I think this needs to be noted more clearly in Section 5.5.2. > > I'll ask *** MAX *** to help here. > > > Section 5.5.5 > > doc> The MASA MAY verify that the registrar voucher-request includes the > doc> 'prior-signed-voucher-request' field. If so the prior-signed- > doc> voucher-request MUST include a 'proximity-registrar-cert' that is > doc> consistent with the certificate used to sign the registrar voucher- > doc> request. Additionally the voucher-request serial-number leaf MUST > > > This seems kind of tautological ("if the MASA is checking X, X MUST have > > happened"). Also, what does "consistent with" mean? > > If the MASA is configured to issue nonceless vouchers for this device, then > no prior-signed-voucher-request field is needed. If it's there, then it must > be valid. Sure. (But what does "consistent with" mean?) > doc> match the pledge serial-number that the MASA extracts from the > doc> signing certificate of the prior-signed-voucher-request. The MASA is > doc> aware of which pledges support signing of their voucher requests and > doc> can use this information to confirm proximity of the pledge with the > doc> registrar, thus ensuring that the BRSKI-EST TLS connection has no > doc> man-in-the-middle. > > > To be clear, this MITM detection is only for the case of pledges that > > sign their voucher requests, right? And it seems to only hold if > > pledges that support signing actually do sign, every time. > > Yes, and also we have removed unsigned, so this is another place we missed > a conditional on that. I want to note that the manufacturer knows, by > construction, what the behaviour of the pledge is. > So I've removed the last sentence completely I'm not entirely sure I follow why this means that the last sentence is okay to remove, but it's probably okay. (Also, I could imagine a case where a third-party "assigned" MASA gets an incomplete feed of device capabilities/behavior from the manufacturer, even by accident, so "by construction" is perhaps stronger than I would use.) > > Section 5.5.6 > > doc> The registrar's certificate chain is extracted from the signature > doc> method. The chain includes the domain CA certificate as specified in > doc> Section 5.5. This certificate is used to populate the "pinned- > > > I don't think Section 5.5 is the right reference for "includes the > > domain CA certificate" (both here and in 5.5.2). > > It's referring to: > The entire > registrar certificate chain, up to and including the Domain CA, MUST > be included in the CMS structure. > > I think that 5.5.2 is the right pointer. Oh, I seem to have completely missed that part; sorry. So then 5.5 (not 5.5.2) is the right reference, and the line removed from 5.5.2 should get restored. > doc> domain-cert" of the voucher being issued. The domainID (e.g., hash > doc> of the root public key) is determined from the pinned-domain-cert and > doc> is used to update the audit log. > > > If the pinning takes the whole cert (per RFC 8366), then what do we need > > the domainID for? Just the audit log? Surely in that case SHA-1 is > > not a hard requirement... > > I've changed the domainID definition such that it uses the > SubjectKeyIdentifier, if present. That can be any algorithm that the CA > wants to use to identify the Entity certificate. We need to have a > consistently calculated value if it's not present, and RFC5280 says SHA-1. > > domainID: The domain IDentity is a unique hash based upon a > Registrar's certificate. If the certificate includes the > SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be > used as the domainID. If not, then the 160-bit SHA-1 hash as > described in that section is to be used. This value needs to be > calculated by both MASA (to populate the audit log), and by the > Registrar (to recognize itself). > > Does this work? We are only using SHA-1 (for identification, btw, not > for resistence to pre-image attacks) as a last resort. Sorry, I'm still not seeing the justification for using SHA-1 as the fallback instead of (e.g.) SHA-256. If the SKI is present, then definitely use that. But if it's not present, we can define whatever we want, can't we? It's not like "The keyIdentifier is composed of the 256-bit SHA-256 hash of the value of the BIT STRING subjectPublicKey (excluding the tag, length, and number of unused bits)" is an unreasonable amount of text ot include in the document. Now, if there's some backwards compatibility need or implementation challenge, we can talk about that, but all I'm seeing so far is blind adherence to an 11-year-old document for consistency's sake, and in this case I don't think consistency outweighs cryptographic modernization. > I'm looking for a place where I could RECOMMEND that Registrar certificates > have SubjectKeyIdentifier added. To 5.1, I have added: > > > section 4.2.1.2 does not mandate that the > SubjectKeyIdentifier extension be present in non-CA certificates. > It is RECOMMENDED that Registrar certificates (even if > self-signed), always include the SubjectKeyIdentifier to be > used as a DomainID, and that a hash stronger than SHA-1 be > used. > I guess I don't see anywhere better to do this, so thanks. > > > Section 5.5.7 > > doc> The MASA MUST use the nonce from the registrar voucher-request for > doc> the resulting voucher and audit log. The prior-signed-voucher- > doc> request nonce is ignored during this operation. > > > I don't understand this requirement. They could only be different if > > the MUST from the previous paragraph is ignored. > > The Registrar may include no nonce. So I agree it looks weird at this point. > I will change this to: > > The MASA populates the audit-log with the nonce that was verified. > If a nonceless voucher is issued, then the audit log is to be > populated with the JSON value "null". > > and I noticed that the audit log asked for the string "null", rather than a > JSON null. > > > Section 5.6 > > doc> The MASA voucher response to the registrar is forwarded without > doc> changes to the pledge; therefore this section applies to both the > doc> MASA and the registrar. The HTTP signaling described applies to both > doc> the MASA and registrar responses. A registrar either caches prior > doc> MASA responses or dynamically requests a new voucher based on local > doc> policy (it does not generate or sign a voucher). [...] > > > Do we need to say how this local caching policy interacts with HTTP > > cache control headers? > > All of the requests are via POST. We are not permitting 201 returns for the > voucher-request (with GET to the Location:), so there can be no opportunity > to cache. > > If the Registrar caches a voucher, it would be caching a nonceless one. > > > I got confused by "or dynamically requests a new voucher" the first > > couple times I read it; I landed on something like "when a voucher > > request arrives at the registrar, if it has a cached response from the > > MASA for the corresponding registrar voucher-request, that cached > > response can be used according to local policy; otherwise the registrar > > constructs a new registrar voucher-request and sends it to the MASA". > > I can use your words. > > Perhaps implicit in this is that there are two ways to build a registrar. > > The simplest is with a single monolithic application framework, it receives > the voucher-request, and then does a synchronous HTTPS request to the MASA. > (Perhaps doing 100-Continue). > The other way is for the pledge-facing part of the Registrar to put it all > into a database, return 202, and wait for another query. Asynchronously some > other part sends requests to the MASA and stores the answers back in the > database. Perhaps the only thing connecting the two parts is some > multi-master database replication... running over > UUCP^WDelay-Tolerant-Networking between planets for all we know. > > > type. The registrar SHOULD use this response if it determines the > > pledge is unacceptable due to inventory control, MASA audit logs, or > > any other reason. > > > What does "unacceptable due to inventory control" mean? > > Such as, device is not in the list of devices that were expected, assuming > supply chain integration. Do you want to make any changes to the text, perhaps "due to a mismatch with intventory [contro]"? > > A 415 (Unsupported Media Type) response is approriate for a request > > that has a voucher-request or accept encoding that is not understood. > > > Isn't "Accept-Encoding:" a more typical spelling? > > Actually, we meant Accept: .. encoding. I've removed the word encoding, > because I see that it's confusing. > > A 415 (Unsupported Media Type) response is appropriate > for a request that has a voucher-request or Accept: value that is > not understood. > > > > vouchers are described in detail in [RFC8366]. For example, the > > voucher consists of: > > > { > > "ietf-voucher:voucher": { > > "nonce": "62a2e7693d82fcda2624de58fb6722e5", > > "assertion": "logging" > > "pinned-domain-cert": "base64encodedvalue==" > > "serial-number": "JADA123456789" > > } > > } > > > nit: I think "might consist of" is better than "consists of". > > already fixed. > > > assertion: The method used to verify assertion. See Section 5.5.5. > > > The method used to verify itself? > > Changed to: > The method used to verify the relationship between pledge and registrar > > doc> The pledge MUST be prepared to parse and fail gracefully from a > doc> voucher response that does not contain a 'pinned-domain-cert' field. > > > What would such a graceful failure look like? Reverting back to the > > discovery stage, since without a manufacturer-validated indication of > > the trust anchor for the domain, the pledge cannot consider itself to > > be a part of a domain? > > changed to: > > The pledge MUST be prepared to parse and fail gracefully from > a voucher response that does not contain a 'pinned-domain-cert' > field. Such a thing indicates a failure to enroll in this domain, Looks good, thanks (but maybe s/thing/response/?) > and the pledge MUST attempt joining with other available Join Proxy. > > > The pledge MUST be prepared to ignore additional fields that it does not recognize. > > > > > Section 5.6.2 > > doc> found. It SHOULD return to the same proxy again after attempting > doc> with other proxies. Attempts should be attempted in the exponential > > > But only if those other proxies failed to produce a valid voucher? > > yes, inserted "unsucccessful" > > doc> The pledge's PKIX path validation of a registrar certificate's > doc> validity period information is as described in Section 2.6.1. Once > doc> the PKIX path validation is successful the TLS connection is no > doc> longer provisional. > > > Section 2.6.1 doesn't actually say that the pledge has to check the five > > listed timestamps in the case that it does have a realtime clock. > > Noted, added text to 2.6.1. > > > Section 5.7 > > doc> To indicate pledge status regarding the voucher, the pledge MUST post > doc> a status message. > > > I think we've had other text that implies that providing telemetry is > > optional; perhaps just "the pledge POSTs a status message"? > > The 5.7 Pledge BRSKI Status Telemtry is mandatory. > The 5.9.4 Enrollment Status Telemtry is not, because enrollment is not mandatory. Ah, sorry for the confusion. > doc> The client HTTP POSTs the following to the server at the EST well > doc> known URI "/voucher_status". The Status field indicates if the > > > I think it's probably more clear to write out > > ".well-known/est/voucher_status"; there's not a separate registry of EST > > well-known URIs. > > okay. > > > We don't actually have anything in this section that declares "this is > > the structure of the JSON object used as the POST body"; it's only > > implicitly provided. > > I believe that I have reworked this section as a result of other reviews already. > > doc> indicates why. In the failure case this message may be sent to an > doc> unauthenticated, potentially malicious registrar and therefore the > doc> Reason string SHOULD NOT provide information beneficial to an > doc> attacker. The operational benefit of this telemetry information is > > > What sort of information might a pledge consider including that would be > > beneficial to an attacker? > > It's hard to say at this point. > We want things in the logs of the Registrar that will help avoid a truck > roll. IBM (AIX and friends) was historically really good at having really > detailed, but often uninformative three digits codes, yet they told AIX > support people reams of useful info. > > > This still have some privacy considerations, though. > > At this point, the attacking registrar has seen the entire IDevID > certificate. I would think that putting the GPS coordinates of the device in > the telemetry message would be of course, make things even worse. > On the other hand, if a device has a GPS and can not be installed in some > places to due some kind of geofencing... :) > > Section 5.8 > > doc> is posted to the /requestauditlog URI instead. The "idevid-issuer" > doc> and "serial-number" informs the MASA which log is requested so the > doc> appropriate log can be prepared for the response. Using the same > > > Is the implicit point that the other fields are ignored? > > Yes. > > doc> A registrar MAY request logs at future times. If the registrar > doc> generates a new request then the MASA is forced to perform the > doc> additional cryptographic operations to verify the new request. > > > Is this statement just supposed to be further justification for using > > the original voucher-request as the POST body, or describing new > > behavior? > > Further justification. The MASA can do a memcmp()/SELECT on a history of raw > voucher requests. {that's what my code does} > > doc> A MASA that receives a request for a device that does not exist, or > doc> for which the requesting owner was never an owner returns an HTTP 404 > doc> ("Not found") code. > > > What is a "requesting owner"? I thought devices were owned by the > > domain, not the specific registrar. > > So, if Registrar A has stored a valid pledge-request (or perhaps a falsy > constructed one) for a pledge that has joined another network (B), then > registrar A can not get a history of the pledge if it was never an owner. > > If the pledge was once owned by Registrar A (but sold), then there is a hole > that would permit Registrar A to ask for history. But this is legitimate, > because perhaps it wasn't actually sold, but in fact stolen, and when > they can't get the device to respond, the operator could ask if the device > has become owned by another Registrar. > > This interface will likely get future work: some kind of zero-knowledge proof > mechanism would be interesting, but we don't know what exactly are the > requirements yet. Thanks for the discussion; it helps clarify the picture to me. Can we maybe just say "requestor" instead of "requesting owner", then? > doc> In order to avoid enumeration of device audit logs, MASA that return > doc> URLs SHOULD take care to make the returned URL unguessable. For > doc> instance, rather than returning URLs containing a database number > doc> such as https://example.com/auditlog/1234 or the EUI of the device > doc> such https://example.com/auditlog/10-00-00-11-22-33, the MASA SHOULD > doc> return a randomly generated value (a "slug" in web parlance). The > doc> value is used to find the relevant database entry. > > > https://www.w3.org/TR/capability-urls/ may also be a useful reference. > > thanks, added. > > That's all for today. > > Will the Joker Get Away? Will the document editor switch to Markdown? > Does the YIN/YANG circle converge ever? Can it be rendered in SVG? > Stay tuned for tomorrow's exciting episode. My breath would be bated if I was not so sluggish to reply... -Ben From nobody Tue Aug 13 10:31:14 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783581200B1; Tue, 13 Aug 2019 10:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ub88xPwR8Xsg; Tue, 13 Aug 2019 10:31:11 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1CF2F12011B; Tue, 13 Aug 2019 10:31:11 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x7DHV79J040150 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 13 Aug 2019 12:31:09 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1565717470; bh=XmytK4ZsSTPp/TWLyw32YvyDMu13IHfN4SsyUMoiiR0=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=kro3+fwwOYd7lgelRFJldA/PrujDYVmZpoKA336PMBlNJAGcEMBjSJZzyIUTK+lAv 5cHQsevj3+9v9gzmPErw7UKkSXtQuIlYriXwKEy2EYgA5zeMlJ2eG2Ku6aUqa3w+4b 1tBQ1p9MOvT/2VSEDn6yT7lbWKkY2bKsjXVzhjTk= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Michael Richardson Cc: Benjamin Kaduk , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, The IESG , anima-chairs@ietf.org References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <12747.1563315277@localhost> <9337.1565710667@localhost> From: Adam Roach Message-ID: Date: Tue, 13 Aug 2019 12:31:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <9337.1565710667@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 17:31:13 -0000 On 8/13/19 10:37 AM, Michael Richardson wrote: > Adam Roach wrote: > >> Adam Roach: https://mailarchive.ietf.org/arch/msg/anima/6AAD9mwsKEsbIUmXRVOAV0N83yA > >> ... > >> This is an rfcdiff from the already-wrapped JSON to the proposed -23 that > >> includes all the changes from the various DISCUSSes up to now: > >> https://tinyurl.com/y2qhjwh8 > > > > As a quick note -- the diff above does not address the "discuss" part of my > > second discuss point: the document remains ambiguous regarding *how* the URL > > is to be returned. The lengthy parenthetical references added to the > > corresponding paragraph aren't sufficient to positively indicate that the URL > > appears in a "Location" header: this needs to be stated explicitly rather > > than implied by a section reference. > > I had previously updated to point to RFC7231 section 6.3.2, but upon careful > reading, I see that returning the URL in the Location: is not mandated by > 6.3.2. I am a little bit surprised that 7231 is so vague on what I thought > was a pretty much written in stone process.... > > > Rather than returning the audit log as a response to the POST (with > a return code 200), the MASA MAY instead return a 201 ("Created") > - response ( sections 6.3.2 and 7.1) containing > - a URL to the prepared (and idempotent, therefore cachable) audit response. > + response ( sections 6.3.2 and 7.1), with > + the URL to the prepared (and idempotent, therefore cachable) audit > + response in the Location: header. > > > Does this fix things for you? > > Yes, thanks. One minor nit: "...Location: header field." /a From nobody Tue Aug 13 14:08:02 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4908B1208E3; Tue, 13 Aug 2019 14:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 14i87FEVqH1E; Tue, 13 Aug 2019 14:07:49 -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 0158F1208C2; Tue, 13 Aug 2019 14:07:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E12573818C; Tue, 13 Aug 2019 17:06:59 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4C5D4E8E; Tue, 13 Aug 2019 17:07:46 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org In-Reply-To: <20190813172532.GM88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <25503.1565496367@localhost> <20190813172532.GM88236@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Aug 2019 21:07:52 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Benjamin Kaduk wrote: doc> The authentication of the BRSKI-MASA connection does not affect the doc> voucher-request process, as voucher-requests are already signed by doc> the registrar. Instead, this authentication provides access contr= ol doc> to the audit log. >>=20 >> > I don't understand what "access control to the audit log" means. = Is the >> > idea that the TLS client identity in the BSRKI-MASA connection is = only >> > used when processing requests to the requestauditlog endpoint and = that >> > some clients might be denied access? >>=20 >> The audit log reveals who owns what. Revealing it to strangers woul= d be a problem. >> So in order to get access to the audit log for device FOO, one prese= nts a >> voucher-request for FOO. Since the request contains a serial-number= and a >> mapping to an owner, we use that as an access key to get the audit-l= og. >> The identity that the MASA sees in the HTTPS request (ClientCertific= ate >> preferred), says who is asking. >>=20 >> What can I fix here? > Well, I think a lot of my confusion stemmed from the lack of advance > definition of "MASA Audit Log" as a protocol element, which you alrea= dy > fixed. So what's left would seem to mostly be a question of whether > something about "access control" vs. "authorization to access the rel= evant > subset of the audit log" is a more accurate description of what's goi= ng on. > That is, whether "access control" is something done by a server (MASA= )-side > agent applying policy, or ... something else that I don't know how to > describe well. I have added a forward reference in section 5.4 to section 5.8 around the the access control question. doc> created-on: Registrars are RECOMMENDED to populate this field. T= his doc> provides additional information to the MASA. >> > Earlier we said that this field would be propagated from the pledge >> > voucher-request; we should probably say something like "populate t= his >> > field; if it was present in the pledge voucher-request it is copied >> > unchanged to the registrar voucher-request; otherwise the current = time >> > is used". >>=20 >> That create-on is the time on the Registrar, not on the pledge. It c= urrently >> says: >>=20 >> The registrar populates the voucher-request fields as follows: >>=20 >> created-on: The Registrars SHOULD populate this field with the >> current date and time when the Registrar formed this voucher >> request. This field provides additional information to the MASA. > Hmm, I'm trying to look for why I claimed that "earlier we said that = this > field would be propagated". Section 3.3 (of the -22)'s Example (2) s= ays > "[t]he nonce, created-on and assertion is carried forward", and Secti= on 5.2 > wants pledges to populate it as well. So the idea is that the MASA i= s only > going to get the pledge's created-on via the prior-signed-voucher-req= uest > (if present)? =20=20=20=20 > I'm confused about what it means to "carry forward" the created-on if= the > registrar is populating it anew, though. I have changed the text: =2D here it must be base64 encoded. The nonce, created-on and =2D assertion is carried forward. The serial-number is extra= cted =2D from + here it must be base64 encoded. The nonce and + assertion MAY be carried forward from the pledge request to + the registrar request. + The serial-number is extracted from It is a MAY, because in a case where the Registrar wants a nonceless vouche= r, then it won't include a nonce. >> > There is no "idevid-issuer" field in the pledge certificate; I ass= ume >> > this is supposed to be the Issuer Name of the IDevID certificate. >>=20 >> Changed to: >> idevid-issuer: The Issuer value from the value from the pledge > nit: duplicated "value from the" fixed. >> IDevID certificate is included to ensure a uniqueness of the >> serial-number. In the case of nonceless (offline) voucher- >> request, then an appropriate value needs to be configured from the >> same out-of-band source as the serial-number. >>=20 >>=20 >> > prior-signed-voucher-request: The signed pledge voucher-request >> > SHOULD be included in the registrar voucher-request. (NOTE: what >> > is included is the complete pledge voucher-request, inclusive of >> > the 'assertion', 'proximity-registrar-cert', etc wrapped by the >> > pledge's original signature). If a signed voucher-request was not >> > recieved from the pledge then this leaf is omitted from the >> > registrar voucher request. >>=20 >> > This is a good example of text that implies the signed voucher is >> > binary. (And as such would be a good place to talk about the base= 64 >> > encoding.) >>=20 >> okay, done. >>=20 >> > All other fields MAY be omitted in the registrar voucher-request. >>=20 >> > Should the proximity-registrar-cert field *not* be present? >>=20 >> Correct, it's from the pledge->registrar. > So it's more of a "MUST NOT" than a "MAY not", here? added: The "proximity-registrar-cert" field MUST NOT be present in the registrar voucher-request. doc> The MASA MUST verify that the registrar voucher-request is signed = by doc> a registrar. This is confirmed by verifying that the id-kp-cmcRA doc> extended key usage extension field (as detailed in EST RFC7030 doc> section 3.6.1) exists in the certificate of the entity that signed doc> the registrar voucher-request. This verification is only a doc> consistency check that the unauthenticated domain CA intended the doc> voucher-request signer to be a registrar. Performing this check doc> provides value to the domain PKI by assuring the domain administra= tor doc> that the MASA service will only respect claims from authorized doc> Registration Authorities of the domain. >>=20 >> > If the MASA has no prior knowledge of the domain (certificate), th= is is >> > susceptible to anyone spinning up something that claims to be a do= main >> > CA and issuing registrar certs with that extension. We need to do= cument >> > somewhere what other part of the system prevents that from causing= an >> > unauthorized voucher to be used. (Perhaps preventing one from bei= ng >> > issued is not feasible, but acceptable if the pledge will not acce= pt >> > it, though there remains risk of DoS on the MASA.) >>=20 >> The ability for someone to spin up a domain is part one of the ways = that the >> MASA MAY operate in the absense of supply chain integration. The au= dit-log >> is the defense against this. If the MASA does not want to do busine= ss with >> such entities, then it just doesn't. > The audit log is a defense against this in that it allows for post-fa= cto > discovery of misuse? Or is there some pre-issuance authorization che= ck > going on. > I think I may need some section references to where the authorization > policy (options) are documented; I've lost a bit of state on this one. That's right, the audit log provides discovery of mis-use. The check belongs prior to issurance of an LDevID, and may be repeated regularly afterwards. I think you are asking for a list of MASA authorization policy options. We do not have such a menu of options, and I'm reluctant to write them down normatively at this point, as I think that there are combinations we do not yet understand. 5.5.3 points out that nonceless vouchers need more authorization. Other parts of 5.5 provide other options. Please let me know if you think this is insufficient for a Proposed Standar= d. BTW: I have started two non-normative (BCP?) documents on Operational Considerations for MASA and Registrar. Started, meaning I've done "mk= dir" and "git init-db"... I imagine keeping these documents open for quite = some time. I've talked about such documents in ANIMA for at least a year. doc> The MASA MAY verify that the registrar voucher-request includes the doc> 'prior-signed-voucher-request' field. If so the prior-signed- doc> voucher-request MUST include a 'proximity-registrar-cert' that is doc> consistent with the certificate used to sign the registrar voucher- doc> request. Additionally the voucher-request serial-number leaf MUST >>=20 >> > This seems kind of tautological ("if the MASA is checking X, X MUS= T have >> > happened"). Also, what does "consistent with" mean? >>=20 >> If the MASA is configured to issue nonceless vouchers for this devic= e, then >> no prior-signed-voucher-request field is needed. If it's there, the= n it must >> be valid. > Sure. > (But what does "consistent with" mean?) I understand the issue now. It means either memcmp()=3D=3D0 or (same Issuer, same Subject). Surprisingly, 5280 does not have a term for the later! {discussion with Max ensues. RFC7469 (HTTP pinning) has a proceedure. =2D-- a/dtbootstrap-anima-keyinfra.xml +++ b/dtbootstrap-anima-keyinfra.xml @@ -2113,12 +2113,22 @@ locator3 =3D [O_IPv6_LOCATOR, fe80::1234, 41, nil]]]> + + The consistency check described above is the same + process as described in section 2.= 6. + Regardless of how the consistency check was done, the MASA MUST + use the serialized value from the + proximity-registrar-cert (in the prior-signed-voucher-request) + when forming the voucher, as that is the only value that + the Pledge will have. + doc> match the pledge serial-number that the MASA extracts from the doc> signing certificate of the prior-signed-voucher-request. The MASA= is doc> aware of which pledges support signing of their voucher requests a= nd doc> can use this information to confirm proximity of the pledge with t= he doc> registrar, thus ensuring that the BRSKI-EST TLS connection has no doc> man-in-the-middle. >>=20 >> > To be clear, this MITM detection is only for the case of pledges t= hat >> > sign their voucher requests, right? And it seems to only hold if >> > pledges that support signing actually do sign, every time. >>=20 >> Yes, and also we have removed unsigned, so this is another place we = missed >> a conditional on that. I want to note that the manufacturer knows, = by >> construction, what the behaviour of the pledge is. >> So I've removed the last sentence completely > I'm not entirely sure I follow why this means that the last sentence = is > okay to remove, but it's probably okay. > (Also, I could imagine a case where a third-party "assigned" MASA get= s an > incomplete feed of device capabilities/behavior from the manufacturer= , even > by accident, so "by construction" is perhaps stronger than I would us= e.) The sentence says that MASA should should if the pledge can sign, and if it does not sign, then it would know if that's okay. But since signing is now not optional, that consideration does not apply. You are correct that an outsourced MASA might not have a complete list, but= I think that is out of scope. doc> domain-cert" of the voucher being issued. The domainID (e.g., hash doc> of the root public key) is determined from the pinned-domain-cert = and doc> is used to update the audit log. >> > If the pinning takes the whole cert (per RFC 8366), then what do w= e need >> > the domainID for? Just the audit log? Surely in that case SHA-1 = is >> > not a hard requirement... >>=20 >> I've changed the domainID definition such that it uses the >> SubjectKeyIdentifier, if present. That can be any algorithm that th= e CA >> wants to use to identify the Entity certificate. We need to have a >> consistently calculated value if it's not present, and RFC5280 says = SHA-1. >>=20 >> domainID: The domain IDentity is a unique hash based upon a >> Registrar's certificate. If the certificate includes the >> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be >> used as the domainID. If not, then the 160-bit SHA-1 hash as >> described in that section is to be used. This value needs to be >> calculated by both MASA (to populate the audit log), and by the >> Registrar (to recognize itself). >>=20 >> Does this work? We are only using SHA-1 (for identification, btw, n= ot >> for resistence to pre-image attacks) as a last resort. > Sorry, I'm still not seeing the justification for using SHA-1 as the > fallback instead of (e.g.) SHA-256. If the SKI is present, then defi= nitely > use that. But if it's not present, we can define whatever we want, c= an't > we? I'm trying not be seen as an Update to RFC5280 :-) Continued in next email. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1TJqIACgkQgItw+93Q 3WUMJAf+OsXCfoYwPi72U0pQt7Z9z5UmTRAwXqjVaSXlbRw4BoElIBTZNteswRFD dlsm0viKQ9g8wGYHVW1hEG0IX1Se0mIqKG/Qsydngb30nbOFjP+lcvtgnC0HwnL+ ClSDMOo02Q9UVXGrEIi4UFf/ke3AwSf6UjfdOH7jgtkVbONBjox1nKmjfdIAb1NY 9hCNoEaQQSUgbNokkwO8rNxEXTB89cv7pTE6/ofMQeNDNT9Lboggu/E+1kScZq1p kmb6vQcm7/Oj9dNQl6Oj723tPlZNsuvPjTrzwFXj5Gr+v/LwGLIq6BQT0HjwSK7X 3xy00e0V3efCiWAFNrj8IdjV/pkh7A== =op2u -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 14 07:05:27 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F29B41207FF; Wed, 14 Aug 2019 07:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 jZtc-Qbaz6Bv; Wed, 14 Aug 2019 07:05:15 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AB7C1200F8; Wed, 14 Aug 2019 07:05:15 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5636E3818C; Wed, 14 Aug 2019 10:04:26 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C79D8A8A; Wed, 14 Aug 2019 10:05:13 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org In-Reply-To: <20190813172532.GM88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <25503.1565496367@localhost> <20190813172532.GM88236@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 14:05:18 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Benjamin Kaduk wrote: >> domainID: The domain IDentity is a unique hash based upon a >> Registrar's certificate. If the certificate includes the >> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be >> used as the domainID. If not, then the 160-bit SHA-1 hash as >> described in that section is to be used. This value needs to be >> calculated by both MASA (to populate the audit log), and by the >> Registrar (to recognize itself). >>=20 >> Does this work? We are only using SHA-1 (for identification, btw, n= ot >> for resistence to pre-image attacks) as a last resort. > Sorry, I'm still not seeing the justification for using SHA-1 as the > fallback instead of (e.g.) SHA-256. If the SKI is present, then > definitely use that. But if it's not present, we can define whatever > we want, can't we? It's not like "The keyIdentifier is composed of t= he > 256-bit SHA-256=20 > hash of the value of the BIT STRING subjectPublicKey (excluding the t= ag, > length, and number of unused bits)" is an unreasonable amount of text= ot > include in the document. Now, if there's some backwards compatibility > need=20 > or implementation challenge, we can talk about that, but all I'm seei= ng so > far is blind adherence to an 11-year-old document for consistency's s= ake, > and in this case I don't think consistency outweighs cryptographic > modernization. Hi, we have revised the text, making use of section 2.4 from rfc7469, which has a similar need. We added a new section 5.8.2, calculation of domainID: 5.8.2. Calculation of domainID The domainID is a binary value (a BIT STRING) that uniquely identifies a Registrar by the "pinned-domain-cert" If the "pinned-domain-cert" certificate includes the SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be used as the domainID. If not, then it is the SPKI Fingerprint as described in [RFC7469] section 2.4 is to be used. This value needs to be calculated by both MASA (to populate the audit-log), and by the Registrar (to recognize itself). [RFC5280] section 4.2.1.2 does not mandate that the SubjectKeyIdentifier extension be present in non-CA certificates. It is RECOMMENDED that Registrar certificates (even if self-signed), always include the SubjectKeyIdentifier to be used as a domainID. The domainID is determined from the certificate chain associated with the pinned-domain-cert and is used to update the audit-log. and referenced this section in the terminology. This eliminates all references to SHA-1. RFC7469 section 2.4 uses SHA-256. We also strengthened our statement that the SubjectKeyIdentifier SHOULD exist. In the process, we recognized that we had some mismatch in (MY) thinking about pinned-domain-cert, thinking it was always the Registrar End-Entity Certificate, when in fact it is the Registrar's CA certificate. As a CA certificate, it SHOULD always have the SubjectKeyIdentifier. We are presenting discussing whether the EE Registrar cert should get audited. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1UFRkACgkQgItw+93Q 3WWO/QgArWz1fNeH8BCXeuXcYHQk5LKyDCen9vEfL4Prx4JRZTDHjb1GAvM5ShHg l/K+Ea4jJYBYeB2IJzhq6gMzZvBj9JkkiJzPYm0TTkHn0MJ/74u4/CC2wBblS4YI A6z8RbjyNoZKqyD6wP2mHqPngic/ScV+E9SHpDoyXw9cUYn7Fm5/4QERT84rUjCp an6hL3+Xsi4mICpKswosjLhGbTpEHV2BlWh6q/qY2hkZ38dd+MeJVvzTRkyMPijq CwxIgLqzS3WBhpLtEbV6dwB+LKBRGTpyAWIb4MfZbdi45gdZhwSt0ZdezMCSwJwD fV4doKV2ErZ2lyVQk/+LI+EeLwAv3A== =1i3a -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 14 07:28:01 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EEA12082F; Wed, 14 Aug 2019 07:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 EBiQgF19yqv2; Wed, 14 Aug 2019 07:27:53 -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 BDEFE120829; Wed, 14 Aug 2019 07:27:52 -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 x7EERdAM006330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 10:27:41 -0400 Date: Wed, 14 Aug 2019 09:27:38 -0500 From: Benjamin Kaduk To: Michael Richardson Cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org Message-ID: <20190814142737.GV88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <17440.1565636744@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <17440.1565636744@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 14:27:57 -0000 On Mon, Aug 12, 2019 at 03:05:44PM -0400, Michael Richardson wrote: > > https://tinyurl.com/yylruorn contains a diff against -24. > > Benjamin Kaduk via Datatracker wrote: > > Section 5.8.1 > > doc> A log data file is returned consisting of all log entries associated > doc> with the the device selected by the IDevID presented in the request. > doc> The audit log may be truncated of old or repeated values as explained > doc> below. The returned data is in JSON format ([RFC7951]), and the > doc> Content-Type SHOULD be "application/json". For example: > > > If RFC 7951 is to be used, I'd suggest "is JSON-encoded YANG data". > > Typo, it should be 7159. (Well, 8529, but I think we covered that already.) > doc> This document specifies a simple log format as provided by the MASA > doc> service to the registrar. This format could be improved by distributed > doc> consensus technologies that integrate vouchers with technologies such > doc> as block-chain or hash trees or optimized logging approaches. Doing so > doc> is out of the scope of this document but is an anticipated improvement > doc> for future work. As such, the registrar client SHOULD anticipate new > doc> kinds of responses, and SHOULD provide operator controls to indicate > doc> how to process unknown responses. > > > This would be a great place to talk about the "version" field that's > > otherwise ignored. > > As in, what should occur if the "version" is not 1? Exactly so! > How about: > > > A registrar that sees a version value greater than 1 indicates > an audit log format that has been enhanced with additional > information. No information will be removed in future > versions; should an incompatible change be desired in the future, > then a new HTTP end point will be used. > > > > doc> anticipated improvement for future work. As such, the registrar > doc> client SHOULD anticipate new kinds of responses, and SHOULD provide > doc> operator controls to indicate how to process unknown responses. > > > Is "registrar client" intended to be both words or just one? > > Probably not, removed. > > doc> A registrar SHOULD use the log information to make an informed > doc> decision regarding the continued bootstrapping of the pledge. The > > > I may be confused, but I thought the registrar was asking for the log > > after the voucher had already been issued. Are these check supposed to > > keep the registrar from forwarding the voucher to the pledge, or just > > as a check for future renewal operations? > > The voucher can be returned to the Pledge immediately, as there is never > any issue about whether the Pledge should join. The MASA has already made > that decision. > > The Registrar could avoid passing the voucher on until after the audit log > checks are done, or could do that concurrently. What matters is that the > audit log checks are done prior to the Registrar accepting an enroll > request. This is down in (what is now) Figure 4. Thinking about it that way is very helpful; thank you. > The Registrar may do additional checks of the audit log at later times, > but I don't think we have any good advice on this yet. Okay. > doc> A relatively simple policy is to white list known (internal or > doc> external) domainIDs and to require all vouchers to have a nonce and/ or > doc> require that all nonceless vouchers be from a subset (e.g. only > doc> internal) domainIDs. A simple action is to revoke any locally issued > > > nit: missing "of" > > I don't know where the "of" that is missing goes. "subset of" (though possibly split by the parenthetical) > While investigating, I broke the big sentence up, and discovered that the > 5209 reference was not coded as XML. Please clue me in what you mean... > > > A relatively simple policy is to white list known (internal or > external) domainIDs. > To require all vouchers to have a nonce. > Alternatively to require that all nonceless vouchers be from a > subset (e.g. only internal) domainIDs. > If the policy is violated a simple action is to revoke any > locally issued credentials for the pledge in question or to > refuse to forward the voucher. The Registrar MUST then refuse > any EST actions, and SHOULD inform a human via a log. > A registrar MAY be configured to ignore (i.e. override the above > policy) the > history of the device but it is RECOMMENDED that this only be > configured if hardware assisted (i.e. TPM anchored) Network > Endpoint Assessment (NEA) is supported. > > > doc> credentials for the pledge in question or to refuse to forward the > doc> voucher. A registrar MAY be configured to ignore the history of the > > > "simple action" in the case that the registrar doesn't like the audit > > log results? > > See changes above for better clarity. And greater clarity is achieved; thanks. > > device but it is RECOMMENDED that this only be configured if > > hardware assisted NEA [RFC5209] is supported. > > > Probably need to expand NEA. > > done, see above. > > > Section 5.9 > > doc> Although EST allows clients to obtain multiple certificates by > doc> sending multiple CSR requests BRSKI mandates use of the CSR Attributes > doc> request and mandates that the registrar validate the CSR against the > doc> expected attributes. This implies that client requests > > > Where is this requirement stated normatively? > > I guess I never thought of it as a requirement that multiple certificates are > not supported; it's a restriction because CSR Attributes is used. > Where is use of CSR Attributes stated. RFC7030 Section 4.5 has using CSR > Attributes as a SHOULD. > > I will note that the ACME Integration documents all seem to have missed > the CSR Attributes part of the flow. > > Although EST allows clients to obtain multiple certificates by > - sending multiple CSR requests BRSKI mandates use of the CSR > - Attributes request and mandates that the registrar validate the CSR > + sending multiple CSR requests; BRSKI does not support this mechanism nit: comma, not semicolon (because the sentence starts with "although"). > + directly. This is because BRSKI pledges MUST use the CSR Attributes (This may not need to be a 2119 MUST since we cite 7030.) > + request ([RFC7030] section 4.5). The registrar MUST validate the CSR but this change does address my concern, so thank you. > against the expected attributes. This implies that client requests > will "look the same" and therefore result in a single logical > certificate being issued even if the client were to make multiple > > > Section 5.9.1 > > doc> This ensures that the pledge has the complete set of current CA > doc> certificates beyond the pinned-domain-cert (see Section 5.6.1 for a > doc> discussion of the limitations inherent in having a single certificate > doc> instead of a full CA Certificates response.) Although these > > > I don't see such a discussion in the indicated section. > > The 5.6 section got split, it should refer to 5.6.2 now. > > > Section 5.9.2 > > doc> To alleviate these operational difficulties, the pledge MUST request > doc> the EST "CSR Attributes" from the EST server and the EST server needs > doc> to be able to reply with the attributes necessary for use of the > doc> certificate in its intended protocols/services. This approach allows > > > "intended" implies that the EST server has some knowledge of what the > > pledge is expected to be doing in the network, right? > > Yes. The ACP document is quite specific about the (rfc822Name) attributes to > assign. Certainly the attributes could include stuff like > "ve608.core1.tor1.example.net" if the Registrar knew how this device was > to be used, but more likely that would be set up afterwards. Hmm, maybe later when we say "the local infrastructure (EST server) informs the pledge of the proper fields to include in the generated CSR" we could reiterate that the EST server has local configuration information to inform this messaging, though it's probably not necessary. > doc> To alleviate these operational difficulties, the pledge MUST request > doc> the EST "CSR Attributes" from the EST server and the EST server needs > doc> to be able to reply with the attributes necessary for use of the > doc> certificate in its intended protocols/services. This approach allows > doc> for minimal CA integrations and instead the local infrastructure (EST > doc> server) informs the pledge of the proper fields to include in the > doc> generated CSR. This approach is beneficial to automated boostrapping > doc> in the widest number of environments. > > > This is convenient, but has some security considerations in that it > > implies that the validation policy on the CA is somewhat lax, since the > > EST server is expected to be doing most of the policy controls. Thus, > > a compromised pledge/device could send a CSR with unauthorized fields > > and it is likely to be signed, allowing for some level of privilege > > escalation. When the registrar acts as a proxy to the CA as well as > > its EST role, as described later, this risk is diminished. > > I don't really understand. > EST servers are Registration Authorities, and they have some kind of > priviledged access to the CA, and are mandated to check the CSR. > I expected to find a statement to this effect in RFC7030, in section 4.2.1, > but I don't see any particularly strong language. > This seems like a quality of implementation issue in the Registrar. The high-level intended workflow described here is roughly "(1) pledge asks registrar for config; (2) pledge puts that config in a CSR, signs the CSR, and sends the CSR to registrar; (3) registrar passes CSR to CA using registrar's implicit authority. We don't describe any crypto to check that (2) happens as intended, as opposed to the pledge dishonestly claiming "oh, and I'm a CA" or "I can provide all ACP services, even privileged ones", so that has to be done by policy in the registrar, as you note. I'm wary of suggesting the workflow that relies on the registrar's implicit authority at the CA without also noting the registrar's policy enforcement obligations. Though it's possible this is covered elsewhere and doesn't need to be duplicated here. > doc> In networks using the BRSKI enrolled certificate to authenticate the > doc> ACP (Autonomic Control Plane), the EST attributes MUST include the "ACP > doc> information" field. See [I-D.ietf-anima-autonomic-control-plane] for > doc> more details. > > > This MUST seems like it belongs in the ACP spec and need not be > > repeated here using normative language. > > I will simplify this, and reference to section 6.1.2 of the ACP. > > In networks using the BRSKI enrolled certificate to authenticate > - the ACP (Autonomic Control Plane), the EST attributes MUST include > - the "ACP information" field. See for more details. > + the ACP (Autonomic Control Plane), the EST CSR attributes MUST include > + the ACP Domain Information Fields defined in + target="I-D.ietf-anima-autonomic-control-plane" /> section 6.1.2. > + (beating the dead horse, is this any different as "MUST include" vs. "include"?) > > Section 5.9.4 > > doc> administrators concerning device lifecycle status. This might > doc> include information concerning attempted bootstrapping messages seen by > doc> the client, MASA provides logs and status of credential enrollment. > doc> [RFC7030] assumes an end user and therefore does not > > > This looks like a comma splice. > > fixed. > > doc> In the case of a FAIL, the Reason string indicates why the most > doc> recent enrollment failed. The SubjectKeyIdentifier field MUST be > doc> included if the enrollment attempt was for a keypair that is locally > > > We haven't talked about POSTing to a new status-report endpoing yet, so > > this comes out of the blue. It would probably be worth adding above > > "SHOULD [start a new TLS handshake] and POST a enrollment status > > message". > > So I'll re-order some paragraphs, and I see that there is an obsolete > half-thought, which remained after removing the TLS re-negotiate option that > TLS1.3 obsoletes. > > > "Status":TRUE /* TRUE=Success, FALSE=Fail" > > > [same note about JSON comments] > > > "reason-context": "Additional information" > > > Is this supposed to be a string or a JSON object similar to > > /voucher_status? > > Already fixed to correct JSON from other comments. > > doc> This allows for clients that wish to minimize their crypto > doc> operations to simply POST this response without renegotiating the TLS > doc> session - at the cost of the server not being able to accurately verify > doc> that enrollment was truly successful. > > > I'd prefer to not have this sort of option available, but I can't > > disprove the claim of its utility, so I will not object if it stays. > > Agreed, I've removed it. > > > Section 5.9.5 > > > Is the idea that the initial BRSKI-EST-issued certificate would > > authenticate the client for the subsequent EST requests? > > yes. > > > Section 7 > > > If this is non-normative and will need to be fleshed out in a separate > > document, would an Appendix be more appropriate? > > Section 9 and 10 refer back to this section in a normative fashion. Er, wouldn't that make this section no longer non-normative? (Not that I could find the references you're talking about, so a clue bat is welcome.) > > Section 7.1 > > doc> Pledge: The pledge could be compromised and providing an attack > doc> vector for malware. The entity is trusted to only imprint using secure > doc> methods described in this document. Additional endpoint > > > How do "could be compromised" and "is trusted to only [...]" go > > together? > > The IDevID could be safe in a TPM, on the other side of an intact kernel, > but the device could be running a VM full of malware. We can trust it to > onboard, but not the operate correctly. > > doc> Vendor Service, MASA: This form of manufacturer service is trusted > doc> to accurately log all claim attempts and to provide authoritative log > doc> information to registrars. The MASA does not know which devices are > doc> associated with which domains. These claims could be > > > I think this is maybe more of a "does not enforce" than "does not > > know", since the domainID ends up in the audit logs that the MASA > > holds. > > Yes, but the domainID does not directly identify the Registrar by name. > Assuming a database breach, what does the MASA know that it can reveal. can reveal or be correlated with other sources of information. The domainID is derived from the public part of a certificate, which could well be widely disseminated. An attacker that compromises the MASA and retains a presence can watch requests come in and backsolve from domainID to certificate directly. > The MASA could store more data, but it doesn't have. > > > Current text provides only for a trusted manufacturer. > > > nit: not a complete sentence. > > I have no memory of what it means, so I've removed it. > > > Section 7.3 > > doc> A registrar can choose to accept devices using less secure methods. > doc> These methods are acceptable when low security models are needed, as > doc> the security decisions are being made by the local administrator, but > doc> they MUST NOT be the default behavior: > > > I'm having a hard time parsing "low security models"; the best I can > > come up with is "threat models where low security is adequate". > > doc> Lower security modes chosen by the MASA service affect all device > doc> deployments unless bound to the specific device identities. In which > > > Is this "unless the lower-security behavior is tied to specific device > > identities"? > > Yes, changed. > > doc> case these modes can be provided as additional features for specific > doc> customers. The MASA service can choose to run in less secure modes > > > nit: This middle sentence is not a complete sentence. > > Already fixed. > > doc> 1. Not enforcing that a nonce is in the voucher. This results in > doc> distribution of a voucher that never expires and in effect makes > > > A nonceless voucher can still include an expiration time ... it is just > > in practice possible for it to never expire, if the target pledge does > > not have an accurate clock. > > Yes, that's correct. > How many devices with RTCs survive 10 years in a warehouse with no power? :-) The ones with a radioisotope thermoelectric generator? ;) > Section 7.4 (.1, and .2) have been reworked some more. > > > doc> subsequent bootstrapping attempts. That this occurred is > doc> captured in the log information so that the registrar can make > doc> appropriate security decisions when a pledge joins the Domain. This is > doc> useful to support use cases where registrars might not be online during > doc> actual device deployment. Because this results in > > > nit: I think that grammatically the "This" at the start of this > > sentence refers to the behavior described in the previous sentence (the > > availability of the log information) rather than the issuance of the > > nonceless voucher. > > fixed. > > > Section 9 > > doc> The autonomic control plane that this document provides bootstrap > doc> for is typically a medium to large Internet Service Provider > doc> organization, or an equivalent Enterprise that has signficant layer-3 > doc> router connectivity. (A network consistenting of primarily layer-2 > > > nit: "is used in" -- the ACP is not the entire organization! > > The text doesn't have "is used in" (Right, I was saying that you should add it. But the reworking fixes the nit, so this is all good.) > But, I did find that paragraph awkward and rewrote it. > > > Section 10.1 > > doc> The MASA audit log includes a hash of the domainID for each > doc> Registrar a voucher has been issued to. This information is closely > doc> related to the actual domain identity, especially when paired with the > doc> anti-DDoS authentication information the MASA might collect. This > doc> could > > > I thought I remembered some discussion of collecting this information > > and thus what sort of information might be collected, but searching for > > "DDoS" in the document didn't find it. > > In order to protect itself from DDoS attacks, it's better if the MASA > can authenticate every connection. With full supply chain integration, then > it knows every customer, and this is easy. > On the other hand, if it hasn't got full chain integration, then it may need > to accept connections from any place with any client certificate. So it > will need some kind of anti-DDOS system. section 11.1 speaks about this, > although it uses the term DoS. I've synchronized the terms and made > a forward reference. Ah, thanks for the pointer to 11.1. > doc> There are a number of design choices that mitigate this risk. The > doc> domain can maintain some privacy since it has not necessarily been > doc> authenticated and is not authoritatively bound to the supply chain. > > > Is this really "privacy" or just "semi-plausible deniability"? > > It's a good question. > A domain could use a new certificate for each device, could connect via some > onion router. Is that privacy, or "semi-plausible deniability"? It might depend on the details of the certificates used, what CA issued them (and its policies regarding accuracy and level of detail in certificates issued therefrom), and whether the certifciates are used/exposed for any other purposes. So, I don't insist on any specific language, and was just sharing my thoughts about how it is possible to think about this, in case it sparked any insight. > doc> Additionally the domainID captures only the unauthenticated subject > doc> key identifier of the domain. A privacy sensitive domain could > > > It's interesting to see "unauthenticated" used here, since the domainID > > is deterministically generated from the pinned-domain-cert that is > > included in the voucher and inserted into the pledge's trust store. So > > in a sense it is a committal by "the domain" to tie that domain cert to > > that device or have the device otherwise be unusable. > > Yes, so a Registrar can present a new self-signed certificate each time. > Sure, it has to keep that around, as it's the link for that pledge. > > > The subsequent > > text here seems to be suggesting that instead of having a single root > > CA cert used by all devices in the domain, distinct certs would be used > > for each device, thus attempting to remove an ability to associate > > devices with each other via joint domain membership. One might imagine > > doing this by entering intermediate CAs (or even leafs?) into the > > pinned-domain-cert field, but if those certs ever become visible (e.g., > > via certificate transparency), then the domainIDs can be independently > > computed and associated to the MASA audit log, and the issuer chain > > used to recorrelate the devices by domainID. So to fully protect > > privacy, the per-device pinned-domain-certs would need to be "root"s > > (i.e., self-issued), which greatly increases the manageability > > complexity and is in effect counter to the goals of ANIMA and BRSKI. > > Agreed. > If you have suggestions on other ways to mitigate, I'm all ears. My tentative conclusion so far has been that robust mitigation is going to be operationally expensive, to the point that I personally would make the tradeoff of documenting risk and not trying to do a whole lot of mitigation. So no brilliant ideas here, unfortunately :-/ > > Section 10.2 > > doc> While the contents of the signed part of the pledge voucher request > doc> can not be changed, they are not encrypted at the registrar. The > doc> ability to audit the messages by the owner of the network prevents > doc> exfiltration of data by a nefarious pledge. The contents of an > > > I think "prevents" is too strong -- steganography and concealed > > channels are really hard to completely defend against. "Gives a > > mechanism to defend against" would be more accurate, in my opinion. > > Okay. > > doc> The above situation is to be distinguished from a residential/ > doc> individual person who registers a device from a manufacturer: that an > doc> enterprise/ISP purchases routing products is hardly worth mentioning. > doc> Deviations would, however, be notable. > > > Deviations in what sense? > > After buying only Cisco equipment (like ASR 9000) [observed by number of MASA > connections after each POP turn up], ISP example.net suddendly > has started communicating with Juniper's MASA (for MX40s..). So like "deviations from a historical trend" or "deviations from an established baseline"? > > Section 10.3 > > doc> 4. There is a fourth case, if the manufacturer is providing > doc> protection against stolen devices. The manufacturer then has a > doc> responsability to protect the legitimate owner against fraudulent > doc> claims that the the equipment was stolen. Such a claim would cause the > doc> manufacturer to refuse to issue a new voucher. Should the device go > doc> through a deep factory reset (for instance, replacement of a damaged > doc> main board component, the device would not bootstrap. > > > I'm not sure I understand this scenario -- is it talking about where a > > third party makes a false theft report in the hopes that the real owner > > will have to do a deep reset and then have the device fail to bootstrap > > because of the reported theft? > > Yes. I think having "In the absence of such manufacturer protection, such a claim would cause [...]" would have helped me get there. > > Section 11 > > doc> To facilitate logging and administrative oversight, in addition to > doc> triggering Registration verification of MASA logs, the pledge reports > > > I'm not sure if "Registration verification" is a typo or not. > > changed to: _Registrar verification_ > > doc> registrar. This is mandated anyway because of the operational > doc> benefits of an informed administrator in cases where the failure is > doc> indicative of a problem. The registrar is RECOMMENDED to verify MASA > > > I'd also expect some comment about the limited value of the additional > > information to an attacker in the context where the attacker already > > would know [other information]. > > I'm not sure what other "other information" is yet, so I don't know > how to fill that in. IIUC, this text is predicated on a "possibly malicious registrar" that a pledge tries to register using/through but fails. So that registrar is already in a position where the pledge would try to use it -- in the ACP case, that probably means fairly physically proximate, and maybe implies a link-local connection. In the non-ACP case, maybe it also implies proximity? I don't know if we can get physical vs. network proximity implied by a pledge trying to use a registrar, but maybe sometimes. My implied question is basically "what else would an attacker have to do to get a pledge to try to use it as a registrar, and what does the attacker already have access to by the time it gets that far?" So we can set the information learned from voucher parsing status reports in the context of what else the attacker would already know. But I don't have the best picture on the deployment scenarios here, so I can't answer the question myself :) > doc> To facilitate truely limited clients EST RFC7030 section 3.3.2 > doc> requirements that the client MUST support a client authentication model > doc> have been reduced in Section 7 to a statement that the registrar "MAY" > doc> choose to accept devices that fail cryptographic authentication. This > doc> reflects current (poor) practices in shipping > > > But section 7 is non-normative! > > okay, but now section 9 refers to parts of it normatively. > > doc> devices without a cryptographic identity that are NOT RECOMMENDED. > > > I guess if we really wanted to disrecommend this practice we could > > split it out into a separate document that profiles core BRSKI for such > > usage. > > yes. > > > Section 11.1 > > doc> this might be an issue during disaster recovery. This risk can be > doc> mitigated by Registrars that request and maintain long term copies of > doc> "nonceless" vouchers. In that way they are guaranteed to be able to > doc> bootstrap their devices. > > > This, of course, comes with a different risk of what is something like > > a long-term credential existing that needs to be protected and stored. > > I partially agree. > Long-term nonceless vouchers still pin a specific domainID. > So they need to available, but they don't need to be private. It's not entirely clear to me that it's okay to make them totally public (but maybe I am missing something). That is, in that once the voucher is public, anyone who can get next to the device can re-bootstrap it using that voucher, which possibly gets it into a configuration that's not usable in its current location, and (less likely) maybe it's hard for the real owner to get the correct configuration back (if the original MASA is gone or whatever). So the voucher is not something I'd want to just put on a public web site. But I guess maybe you don't have to protect it to the same extent that you do your crypto keys. > doc> The issuance of nonceless vouchers themselves creates a security > doc> concern. If the Registrar of a previous domain can intercept protocol > doc> communications then it can use a previously issued nonceless voucher to > doc> establish management control of a pledge device even after having sold > doc> it. This risk is mitigated by recording the issuance of such vouchers > doc> in the MASA audit log that is verified by the subsequent Registrar and > doc> by Pledges only bootstrapping when in a factory default state. This > doc> reflects a balance between enabling MASA independence during future > doc> bootstrapping and the security of bootstrapping itself. Registrar > doc> control over requesting and auditing nonceless vouchers allows device > doc> owners to choose an appropriate balance. > > > I would expect some discussion here about nonceless vouchers > > with/without expiration times. > > Added above. > > > I also wonder whether the owner or registrar should expect to be doing > > soem periodic MASA audit log checking, akin to a CT auditor or monitor. > > Yes, but we think falls into quality of implementation. > It's not something worth doing for every Registrary. Sure. > doc> of specific pledge devices, helps to mitigate this. Pledge > doc> signatures on the pledge voucher-request, as forwarded by the registrar > doc> in the prior-signed-voucher-request field of the registrar > doc> voucher-request, significantly reduce this risk by ensuring the MASA > doc> can confirm proximity between the pledge and the registrar making the > doc> request. This mechanism is optional to allow for constrained devices. > doc> Supply chain integration ("know your customer") is an > > > And so the protection is only available when all devices served by the > > MASA are known to produce signed voucher-requests. > > Which is now mandatory. Yay > doc> additional step that MASA providers and device vendors can explore. > > > In terms of adding some more crypto to the BRSKI-MASA flow that would > > prevent unauthenticated DoS? > > If every connection is from a known customer, then one can reject the DoS > at the TLS handshake step. > > > Section 11.2 > > > I appreciate having this discussion present; thanks! > > doc> The fake registrar (Rm) can obtain a voucher signed by the MASA > doc> either directly or through arbitrary intermediaries. Assuming that > > > I'm not sure what sort of intermediary this is thinking about. > > Join Proxies connected to the systems involved. > > doc> This pledge voucher-request would be 'stale' in that it has a nonce > doc> that no longer matches the internal state of the pledge. In order to > doc> successfully use any resulting voucher the Rm would need to remove the > doc> stale nonce or anticipate the pledge's future nonce state. Reducing > doc> the possibility of this is why the pledge is mandated to generate a > doc> strong random or pseudo-random number nonce. > > > This gets a bit more complicated to reason about when we assume that a > > pledge will have multiple voucher requests out in parallel, instead of > > doing them in sequence and timing out (so that there is literally only > > one valid nonce at a given time)... > > Agreed. > But, we think that doing things serially has too much potential to run > into head-of-queue challenges; the risk is that if devices don't onboard > relatively quickly, then BRSKI will get turned off, not used, or the > vendor might provide some "backdoor" That's a fair concern, but in and of itself is not an excuse to skip reasoning through the risks of the parallel workflow. How much effort has already been spent doing that reasoning through? For example, one might want to require that the pledge track which nonce belongs to the voucher request submitted through which candidate registrar, but I didn't work through whether that actually will defend against any attack scenarios. > doc> Additionally, in order to successfully use the resulting voucher the > doc> Rm would have to attack the pledge and return it to a bootstrapping > doc> enabled state. This would require wiping the pledge of current > > > .... and I think there is a different attack if the Rm is in a position > > to delay or drop network traffic between the pledge and the intended > > registrar, to cause Rm's voucher to be delivered first even though it > > is generated after the intended registrar's authorization process. The > > intended registrar would need to require reports on voucher processing > > status (or investigate their absence) in order to detect such a case. > > Yes, that's definitely a problem. We had a lot of difficulty constructing > this attack, btw. > > doc> o Retreival and examination of MASA log information upon the > doc> occurance of any such unexpected events. Rm will be listed in the logs > doc> along with nonce information for analysis. > > > How strongly guaranteed is it that a given device will only have a > > single specific MASA that it trusts to issue vouchers (and thus limit > > the scope of monitoring needed by the owner)? > > There is no guarantee; a device could have multiple IDevID. > However, a voucher-request from one wouldn't be useable for another. > It would require malicious code in the pledge, I think. I'm willing to consider malicious code in the pledge as part of my threat model :) > > Section 11.3 > > doc> o A Trust-On-First-Use (TOFU) mechanism. A human would be queried > doc> upon seeing a manufacturer's trust anchor for the first time, and then > doc> the trust anchor would be installed to the trusted store. There are > doc> risks with this; even if the key to name is validated using something > doc> like the WebPKI, there remains the possibility > > > nit: is this "key to name mapping"? > > fixed. > > > Section 11.4 > > > It is not entirely clear to me whether device manufacturers are set up > > with incentives to maintain a well-run secure CA with strong hardware > > protections on the offline signing key for the root CA, cycling through > > various levels of intermediates, etc., that CAs in the Web PKI do > > today. If the manufacturer uses a less stringent process, that would > > leave the manufacturer's key as a more tempting attack surface, and it > > may be worth some discussion here about what damage could be done with > > a compromised MASA signing key. E.g., would an attack require > > restoring devices to factory defaults or otherwise waiting for natural > > bootstrapping events to occur? Would the attacker need to be on-path? > > Etc. > > I have dug around cabforum.org and root-servers.org for some references on > what a "well-run secure CA" should be doing... surprisingly I didn't find an > RFC, or one for DNSSEC root operation. Did I miss them? I thought that there > was one. I'm writing some text, and I'll finish this email here, and post > the resulting text. I think I had always assumed this was part of the CA/B forum baseline requirements (https://cabforum.org/baseline-requirements-documents/) but never actually looked. :-/ We could ask around if it's important (but I don't think there's an RFC). -Ben From nobody Wed Aug 14 07:34:23 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86EF31208E2; Wed, 14 Aug 2019 07:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YfzmUwRcfUnI; Wed, 14 Aug 2019 07:34:14 -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 2565E120043; Wed, 14 Aug 2019 07:34:13 -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 x7EEY5eP013805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 10:34:07 -0400 Date: Wed, 14 Aug 2019 09:34:04 -0500 From: Benjamin Kaduk To: Michael Richardson Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org Message-ID: <20190814143404.GW88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <25503.1565496367@localhost> <20190813172532.GM88236@kduck.mit.edu> <28714.1565791513@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28714.1565791513@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 14:34:17 -0000 On Wed, Aug 14, 2019 at 10:05:13AM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > >> domainID: The domain IDentity is a unique hash based upon a > >> Registrar's certificate. If the certificate includes the > >> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be > >> used as the domainID. If not, then the 160-bit SHA-1 hash as > >> described in that section is to be used. This value needs to be > >> calculated by both MASA (to populate the audit log), and by the > >> Registrar (to recognize itself). > >> > >> Does this work? We are only using SHA-1 (for identification, btw, not > >> for resistence to pre-image attacks) as a last resort. > > > Sorry, I'm still not seeing the justification for using SHA-1 as the > > fallback instead of (e.g.) SHA-256. If the SKI is present, then > > definitely use that. But if it's not present, we can define whatever > > we want, can't we? It's not like "The keyIdentifier is composed of the > > 256-bit SHA-256 > > hash of the value of the BIT STRING subjectPublicKey (excluding the tag, > > length, and number of unused bits)" is an unreasonable amount of text ot > > include in the document. Now, if there's some backwards compatibility > > need > > or implementation challenge, we can talk about that, but all I'm seeing so > > far is blind adherence to an 11-year-old document for consistency's sake, > > and in this case I don't think consistency outweighs cryptographic > > modernization. > > Hi, we have revised the text, making use of section 2.4 from rfc7469, which > has a similar need. > > We added a new section 5.8.2, calculation of domainID: > > 5.8.2. Calculation of domainID > > The domainID is a binary value (a BIT STRING) that uniquely > identifies a Registrar by the "pinned-domain-cert" > > If the "pinned-domain-cert" certificate includes the > SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be > used as the domainID. If not, then it is the SPKI Fingerprint as > described in [RFC7469] section 2.4 is to be used. This value needs > to be calculated by both MASA (to populate the audit-log), and by the > Registrar (to recognize itself). > > [RFC5280] section 4.2.1.2 does not mandate that the > SubjectKeyIdentifier extension be present in non-CA certificates. It > is RECOMMENDED that Registrar certificates (even if self-signed), > always include the SubjectKeyIdentifier to be used as a domainID. > > The domainID is determined from the certificate chain associated with > the pinned-domain-cert and is used to update the audit-log. > > and referenced this section in the terminology. This eliminates all > references to SHA-1. RFC7469 section 2.4 uses SHA-256. Thank you! > We also strengthened our statement that the SubjectKeyIdentifier SHOULD > exist. In the process, we recognized that we had some mismatch in > (MY) thinking about pinned-domain-cert, thinking it was always the > Registrar End-Entity Certificate, when in fact it is the Registrar's > CA certificate. As a CA certificate, it SHOULD always have the > SubjectKeyIdentifier. My recollection was that it was expected to be a certificate in the Registrar's chain, probably a CA certificate but possibly an intermediate one (i.e., not self-signed). (And I see in 5280 "this extension MUST appear in all conforming CA certificates".) > We are presenting discussing whether the EE Registrar cert should get > audited. Okay, sounds good. -Ben From nobody Wed Aug 14 07:53:15 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A13120921; Wed, 14 Aug 2019 07:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 9psXf0f3CjoR; Wed, 14 Aug 2019 07:53:10 -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 647BD120913; Wed, 14 Aug 2019 07:53:10 -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 x7EEqxYA005733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 10:53:01 -0400 Date: Wed, 14 Aug 2019 09:52:58 -0500 From: Benjamin Kaduk To: Michael Richardson Cc: anima@ietf.org, The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org Message-ID: <20190814145258.GX88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <22660.1565638213@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22660.1565638213@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 14:53:14 -0000 On Mon, Aug 12, 2019 at 03:30:13PM -0400, Michael Richardson wrote: > > WG: there is a chunk of Security Considerations text here that I hope > many will read. > > > Benjamin Kaduk via Datatracker wrote: > > Section 11.4 > > > It is not entirely clear to me whether device manufacturers are set up > > with incentives to maintain a well-run secure CA with strong hardware > > protections on the offline signing key for the root CA, cycling through > > various levels of intermediates, etc., that CAs in the Web PKI do > > today. If the manufacturer uses a less stringent process, that would > > leave the manufacturer's key as a more tempting attack surface, and it > > may be worth some discussion here about what damage could be done with > > a compromised MASA signing key. E.g., would an attack require > > restoring devices to factory defaults or otherwise waiting for natural > > bootstrapping events to occur? Would the attacker need to be on-path? > > Etc. > > I wanted to add that I think that there are some interesting economic > discussions about these incentives. I wonder how to interest some people > into doing some analysis of a monetary rather that technical manner. > > I have added: > 11.4. Manufacturer Maintenance of trust anchors . . . . . . . 75 > 11.4.1. Compromise of Manufacturer IDevID signing keys . . . 77 > 11.4.2. Compromise of MASA signing keys . . . . . . . . . . 77 > 11.4.3. Compromise of MASA web service . . . . . . . . . . . 79 > > and this text is rough, and as yet unreviewed by anyone, and I (not sure if there was supposed to be much more to that sentence). It's rough, sure, but generally looks quite good in terms of content coverage. > 11.4. Manufacturer Maintenance of trust anchors > > BRSKI depends upon the manufacturer building in trust anchors to the > pledge device. The voucher artifact which is signed by the MASA will > be validated by the pledge using that anchor. This implies that the > manufacturer needs to maintain access to a signing key that the > pledge can validate. > > The manufacturer will need to maintain the ability to make signatures > that can be validated for the lifetime that the device could be > onboarded. Whether this onboarding lifetime is less than the device > > lifetime depends upon how the device is used. An inventory of > devices kept in a warehouse as spares might not be onboarded for many > decades. > > There are good cryptographic hygiene reasons why a manufacturer would > not want to maintain access to a private key for many decades. A > manufacturer in that situation can leverage a long-term certificate > authority anchor, built-in to the pledge, and then a certificate > chain may be incorporated using the normal CMS certificate set. This > may increase the size of the voucher artifacts, but that is not a > significant issues in non-constrained environments. > > There are a few other operational variations that manufacturers could > consider. For instance, there is no reason that every device need > have the same set of trust anchors pre-installed. Devices built in > different factories, or on different days, or any other consideration > could have different trust anchors built in, and the record of which > batch the device is in would be recorded in the asset database. The > manufacturer would then know which anchor to sign an artifact > against. > > Aside from the concern about long-term access to private keys, a > major limiting factor for the shelf-life of many devices will be the > age of the cryptographic algorithms included. A device produced in > 2019 will have hardware and software capable of validating algorithms > common in 2019, and will have no defense against attacks (both > quantum and von-neuman brute force attacks) which have not yet been > invented. This concern is orthogonal to the concern about access to > private keys, but this concern likely dominates and limits the > lifespan of a device in a warehouse. If any update to firmware to > support new cryptographic mechanism were possible (while the device > was in a warehouse), updates to trust anchors would also be done at > the same time. > > The set of standard operating proceedures for maintaining high value > private keys is well documented. For instance, the WebPKI provides a > number of options for audits at {{cabforumaudit}}, and the DNSSEC > root operations are well documented at {{dnssecroot}}. > > It is not clear if Manufacturers will take this level of precaution, > or how strong the economic incentives are to maintain an appropriate > level of security. > > This next section examines the risk due to a compromised MASA key. > This is followed by examination of the risk of a compromised > manufacturer IDevID signing key. The third section sections below > examines the situation where MASA web server itself is under attacker > control, but that the MASA signing key itself is safe in a not- > directly connected hardware module. > > 11.4.1. Compromise of Manufacturer IDevID signing keys > > An attacker that has access to the key that the manufacturer uses to > sign IDevID certificates can create counterfeit devices. Such > devices can claim to be from a particular manufacturer, but be > entirely different devices: Trojan horses in effect. > > As the attacker controls the MASA URL in the certificate, the > registrar can be convinced to talk to the attackers' MASA. The > Registrar does not need to be in any kind of promiscuous mode to be > vulnerable. > > In addition to creating fake devices, the attacker may also be able > to issue revocations for existing certificates if the IDevID > certificate process relies upon CRL lists that are distributed. > > There does not otherwise seem to be any risk from this compromise to > devices which are already deployed, or which are sitting locally in > boxes waiting for deployment (local spares). The issue is that (That is, if the boxes are already in local storage at the time of first compromise) > operators will be unable to trust devices which have been in an > uncontrolled warehouse as they do not know if those are real devices. > > 11.4.2. Compromise of MASA signing keys > > There are two periods of time in which to consider: when the MASA key > has fallen into the hands of an attacker, and after the MASA > recognizes that the key has been compromised. > > 11.4.2.1. Attacker opportunties with compromised MASA key > > An attacker that has access to the MASA signing key could create > vouchers. These vouchers could be for existing deployed devices, or > for devices which are still in a warehouse. In order to exploit > these vouchers two things need to occur: the device has to go through > a factory default boot cycle, and the registrar has to be convinced > to contact the attacker's MASA. > > If the attacker controls a Registrar which is visible to the device, > then there is no difficulty in delivery of the false voucher. A > possible practical example of an attack like this would be in a data > center, at an ISP peering point (whether a public IX, or a private > peering point). In such a situation, there are already cables > attached to the equipment that lead to other devices (the peers at > the IX), and through those links, the false voucher could be > delivered. The difficult part would be get the device put through a > factory reset. This might be accomplished through social engineering > of data center staff. Most locked cages have ventilation holes, and > possibly a long "paperclip" could reach through to depress a factory > reset button. Once such a piece of ISP equipment has been > compromised, it could be used to compromise equipment that was > connected to (through long haul links even), assuming that those > pieces of equipment could also be forced through a factory reset. > > The above scenario seems rather unlikely as it requires some element > of physical access; but were there a remote exploit that did not > cause a direct breach, but rather a fault that resulted in a factory > reset, this could provide a reasonable path. > > The above deals with ANI uses of BRSKI. For cases where 802.11 or > 802.15.4 is involved, the need to connect directly to the device is > eliminated, but the need to do a factory reset is not. Physical > possession of the device is not required as above, provided that > there is some way to force a factory reset. With some consumers > devices with low overall implementation quality, the end users might > be familiar with needing to reset the device regularly. > > The authors are unable to come up with an attack scenario where a > compromised voucher signature enables an attacker to introduce a > compromised pledge into an existing operator's network. This is the > case because the operator controls the communication between > Registrar and MASA, and there is no opportunity to introduce the fake > voucher through that conduit. This seems predicated on the attacker having the MASA signing key but not persistent control of the (formerly?) legitimate MASA service, right? > 11.4.2.2. Risks after key compromise is known > > Once the operator of the MASA realizes that the voucher signing key > has been compromised it has to do a few things. > > First, it MUST issue a firmware update to all devices that had that > key as a trust anchor, such that they will no longer trust vouchers > from that key. This will affect devices in the field which are > operating, but those devices, being in operation, are not performing > onboarding operations, so this is not a critical patch. > > Devices in boxes (in warehouses) are vulnerable, and remain > vulnerable until patched. An operator would be prudent to unbox the > devices, onboard them in a safe environment, and then perform > firmware updates. This does not have to be done by the end-operator; > it could be done by a distributor that stores the spares. A > recommended practice for high value devices (which typically have a > <4hr service window) may be to validate the device operation on a > regular basis anyway. > > If the onboarding process includes attestations about firmware > versions, then through that process the operator would be advised to > upgrade the firmware before going into production. Unfortunately, > this does not help against situations where the attacker operates > their own Registrar (as listed above). > > [RFC8366] section 6.1 explains the need for short-lived vouchers. > The nonce guarantees freshness, and the short-lived nature of the > voucher means that the window to deliver a fake voucher is very > short. A nonceless, long-lived voucher would be the only option for > the attacker, and devices in the warehouse would be vulnerable to > such a thing. > > A key operational recommendation is for manufacturers to sign > nonceless, long-lived vouchers with a different key that they sign > short-lived vouchers. That key needs significantly better > protection. If both keys come from a common trust-anchor (the > manufacturer's CA), then a compromise of the manufacturer's CA would > be a bigger problem. (probably some wordsmithing options for "be a bigger problem") > 11.4.3. Compromise of MASA web service > > An attacker that takes over the MASA web service has a number of > attacks. The most obvious one is simply to take the database listing > customers and devices and to sell this data to other attackers who > will now know where to find potentially vulnerable devices. > > The second most obvious thing that the attacker can do is to kill the > service, or make it operate unreliably, making customers frustrated. > This could have a serious affect on ability to deploy new services by > customers, and would be a significant issue during disaster recovery. > > While the compromise of the MASA web service may lead to the > compromise of the MASA voucher signing key, if the signing occurs > offboard (such as in a hardware signing module, HSM), then the key > may well be safe, but control over it resides with the attacker. > > Such an attacker can issue vouchers for any device presently in > service. Said device still needs to be convinced to do through a > factory reset process before an attack. > > If the attacker has access to a key that is trusted for long-lived > nonceless vouchers, then they could issue vouchers for devices which > are not yet in service. This attack may be very hard to verify and > as it would involve doing firmware updates on every device in > warehouses (a potentially ruinously expensive process), a > manufacturer might be reluctant to admit this possibility. Thanks for writing this up! -Ben From nobody Wed Aug 14 07:56:24 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3AA1208AB; Wed, 14 Aug 2019 07:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 AcECTGOzh9c9; Wed, 14 Aug 2019 07:56:20 -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 46C041208A7; Wed, 14 Aug 2019 07:56:20 -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 x7EEuBAc009662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 10:56:13 -0400 Date: Wed, 14 Aug 2019 09:56:10 -0500 From: Benjamin Kaduk To: Michael Richardson Cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org Message-ID: <20190814145610.GY88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <1777.1565641434@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1777.1565641434@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 14:56:23 -0000 On Mon, Aug 12, 2019 at 04:23:54PM -0400, Michael Richardson wrote: > > Benjamin Kaduk via Datatracker wrote: > > Section 13.2 > > > I think CDDL needs to be a normative reference, as does RFC 7231. RFC > > 2473 is listed but not referenced in the text, as are RFC 2663, RFC > > 7217, and RFC 7575. > > CDDL->RFC8610, now normative. (Glad that got published) > RFC2473 removed, we no longer attempt to document a stateless IPIP proxy > mechanism. > > RFC2663 (NAT terminology) reference was for Join Proxy, and I've restored > a reference in section 4. > > RFC7217 was thought to be relevant to Pledge use of SLAAC, but actually it's > not, removed. > > You are right that we don't reference RFC7575, which is the architecture of > ANIMA. I have added a sentence to the Intro, referencing RFC7575's > goal of "secure by default" > > > Appendix B > > doc> Discovery of registrar MAY also be performed with DNS-based service > doc> discovery by searching for the service "_brski- > doc> registrar._tcp.example.com". In this case the domain "example.com" is > doc> discovered as described in [RFC6763] section 11 (Appendix A.2 suggests > doc> the use of DHCP parameters). > > > I'd suggest using "" per 6763 rather than "example.com". > > okay. > > doc> If no local proxy or registrar service is located using the GRASP > doc> mechanisms or the above mentioned DNS-based Service Discovery methods > doc> the pledge MAY contact a well known manufacturer provided bootstrapping > doc> server by performing a DNS lookup using a well known URI such as > doc> "brski-registrar.manufacturer.example.com". The details of the URI are > doc> manufacturer specific. Manufacturers that leverage this method on the > doc> pledge are responsible for providing the registrar service. Also see > doc> Section 2.7. > > > It seems like there are some security considerations for device owners > > that may wish to prevent such registrars from being used. Do we need > > to direct them to run a firewall or similar? > > If they are doing ANIMA ACP bootstrapping, then there would ideally be no > IPv4 available, and so this won't work anyway. > I'd rather not get into too much of this here. I'm not sure I see how v6-only prevents URI dereference or obviates the usecase for a firewall. Perhaps you mean that there would be no non-link-local available? > > Appendix C > > > I don't know how important file "ietf-mud-extension@2018-02-14.yang" > > is, but it seems a tad generic. > > Renamed already. > > Ben, I'm posting the -25, and then moving on back to the responses to > my responses, including Adam's concerns. Okay, thanks. -Ben From nobody Wed Aug 14 08:12:34 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D216120832; Wed, 14 Aug 2019 08:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 3TelfQ0i1Fzx; Wed, 14 Aug 2019 08:12:28 -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 5E24512023E; Wed, 14 Aug 2019 08:12:28 -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 x7EFCHg9030038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Aug 2019 11:12:19 -0400 Date: Wed, 14 Aug 2019 10:12:17 -0500 From: Benjamin Kaduk To: Michael Richardson Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org Message-ID: <20190814151216.GZ88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <25503.1565496367@localhost> <20190813172532.GM88236@kduck.mit.edu> <14229.1565730466@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14229.1565730466@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 15:12:32 -0000 Apparently I only have one comment buried inline. We must be making progress :) On Tue, Aug 13, 2019 at 05:07:46PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > doc> The authentication of the BRSKI-MASA connection does not affect the > doc> voucher-request process, as voucher-requests are already signed by > doc> the registrar. Instead, this authentication provides access control > doc> to the audit log. > >> > >> > I don't understand what "access control to the audit log" means. Is the > >> > idea that the TLS client identity in the BSRKI-MASA connection is only > >> > used when processing requests to the requestauditlog endpoint and that > >> > some clients might be denied access? > >> > >> The audit log reveals who owns what. Revealing it to strangers would be a problem. > >> So in order to get access to the audit log for device FOO, one presents a > >> voucher-request for FOO. Since the request contains a serial-number and a > >> mapping to an owner, we use that as an access key to get the audit-log. > >> The identity that the MASA sees in the HTTPS request (ClientCertificate > >> preferred), says who is asking. > >> > >> What can I fix here? > > > Well, I think a lot of my confusion stemmed from the lack of advance > > definition of "MASA Audit Log" as a protocol element, which you already > > fixed. So what's left would seem to mostly be a question of whether > > something about "access control" vs. "authorization to access the relevant > > subset of the audit log" is a more accurate description of what's going on. > > That is, whether "access control" is something done by a server (MASA)-side > > agent applying policy, or ... something else that I don't know how to > > describe well. > > I have added a forward reference in section 5.4 to section 5.8 around the > the access control question. > > doc> created-on: Registrars are RECOMMENDED to populate this field. This > doc> provides additional information to the MASA. > > >> > Earlier we said that this field would be propagated from the pledge > >> > voucher-request; we should probably say something like "populate this > >> > field; if it was present in the pledge voucher-request it is copied > >> > unchanged to the registrar voucher-request; otherwise the current time > >> > is used". > >> > >> That create-on is the time on the Registrar, not on the pledge. It currently > >> says: > >> > >> The registrar populates the voucher-request fields as follows: > >> > >> created-on: The Registrars SHOULD populate this field with the > >> current date and time when the Registrar formed this voucher > >> request. This field provides additional information to the MASA. > > > Hmm, I'm trying to look for why I claimed that "earlier we said that this > > field would be propagated". Section 3.3 (of the -22)'s Example (2) says > > "[t]he nonce, created-on and assertion is carried forward", and Section 5.2 > > wants pledges to populate it as well. So the idea is that the MASA is only > > going to get the pledge's created-on via the prior-signed-voucher-request > > (if present)? > > > I'm confused about what it means to "carry forward" the created-on if the > > registrar is populating it anew, though. > > I have changed the text: > > - here it must be base64 encoded. The nonce, created-on and > - assertion is carried forward. The serial-number is extracted > - from > + here it must be base64 encoded. The nonce and > + assertion MAY be carried forward from the pledge request to > + the registrar request. > + The serial-number is extracted from > > It is a MAY, because in a case where the Registrar wants a nonceless voucher, > then it won't include a nonce. > > >> > There is no "idevid-issuer" field in the pledge certificate; I assume > >> > this is supposed to be the Issuer Name of the IDevID certificate. > >> > >> Changed to: > >> idevid-issuer: The Issuer value from the value from the pledge > > > nit: duplicated "value from the" > > fixed. > > >> IDevID certificate is included to ensure a uniqueness of the > >> serial-number. In the case of nonceless (offline) voucher- > >> request, then an appropriate value needs to be configured from the > >> same out-of-band source as the serial-number. > >> > >> > >> > prior-signed-voucher-request: The signed pledge voucher-request > >> > SHOULD be included in the registrar voucher-request. (NOTE: what > >> > is included is the complete pledge voucher-request, inclusive of > >> > the 'assertion', 'proximity-registrar-cert', etc wrapped by the > >> > pledge's original signature). If a signed voucher-request was not > >> > recieved from the pledge then this leaf is omitted from the > >> > registrar voucher request. > >> > >> > This is a good example of text that implies the signed voucher is > >> > binary. (And as such would be a good place to talk about the base64 > >> > encoding.) > >> > >> okay, done. > >> > >> > All other fields MAY be omitted in the registrar voucher-request. > >> > >> > Should the proximity-registrar-cert field *not* be present? > >> > >> Correct, it's from the pledge->registrar. > > > So it's more of a "MUST NOT" than a "MAY not", here? > > added: > > The "proximity-registrar-cert" field MUST NOT be present in the > registrar voucher-request. > > > doc> The MASA MUST verify that the registrar voucher-request is signed by > doc> a registrar. This is confirmed by verifying that the id-kp-cmcRA > doc> extended key usage extension field (as detailed in EST RFC7030 > doc> section 3.6.1) exists in the certificate of the entity that signed > doc> the registrar voucher-request. This verification is only a > doc> consistency check that the unauthenticated domain CA intended the > doc> voucher-request signer to be a registrar. Performing this check > doc> provides value to the domain PKI by assuring the domain administrator > doc> that the MASA service will only respect claims from authorized > doc> Registration Authorities of the domain. > >> > >> > If the MASA has no prior knowledge of the domain (certificate), this is > >> > susceptible to anyone spinning up something that claims to be a domain > >> > CA and issuing registrar certs with that extension. We need to document > >> > somewhere what other part of the system prevents that from causing an > >> > unauthorized voucher to be used. (Perhaps preventing one from being > >> > issued is not feasible, but acceptable if the pledge will not accept > >> > it, though there remains risk of DoS on the MASA.) > >> > >> The ability for someone to spin up a domain is part one of the ways that the > >> MASA MAY operate in the absense of supply chain integration. The audit-log > >> is the defense against this. If the MASA does not want to do business with > >> such entities, then it just doesn't. > > > The audit log is a defense against this in that it allows for post-facto > > discovery of misuse? Or is there some pre-issuance authorization check > > going on. > > I think I may need some section references to where the authorization > > policy (options) are documented; I've lost a bit of state on this one. > > That's right, the audit log provides discovery of mis-use. > The check belongs prior to issurance of an LDevID, and may be repeated > regularly afterwards. > > I think you are asking for a list of MASA authorization policy options. > We do not have such a menu of options, and I'm reluctant to write them > down normatively at this point, as I think that there are combinations we do > not yet understand. > > 5.5.3 points out that nonceless vouchers need more authorization. > Other parts of 5.5 provide other options. > Please let me know if you think this is insufficient for a Proposed Standard. I think I'd like to see a small addition after/near "[t]his verification is only a consistency check that the unauthenticated domain CA intended the voucher-request signer to be a registrar" (perhaps at the end of the paragraph?) noting something like "since the domain CA is unauthenticated to the MASA, depending on MASA policy, vouchers not authorized by the pledge owner may be issued; the MASA audit log can be used to detect such missisuance". -Ben > BTW: I have started two non-normative (BCP?) documents on Operational > Considerations for MASA and Registrar. Started, meaning I've done "mkdir" > and "git init-db"... I imagine keeping these documents open for quite some > time. I've talked about such documents in ANIMA for at least a year. > > doc> The MASA MAY verify that the registrar voucher-request includes the > doc> 'prior-signed-voucher-request' field. If so the prior-signed- > doc> voucher-request MUST include a 'proximity-registrar-cert' that is > doc> consistent with the certificate used to sign the registrar voucher- > doc> request. Additionally the voucher-request serial-number leaf MUST > >> > >> > This seems kind of tautological ("if the MASA is checking X, X MUST have > >> > happened"). Also, what does "consistent with" mean? > >> > >> If the MASA is configured to issue nonceless vouchers for this device, then > >> no prior-signed-voucher-request field is needed. If it's there, then it must > >> be valid. > > > Sure. > > (But what does "consistent with" mean?) > > I understand the issue now. > It means either memcmp()==0 or (same Issuer, same Subject). > Surprisingly, 5280 does not have a term for the later! > {discussion with Max ensues. RFC7469 (HTTP pinning) has a proceedure. > > --- a/dtbootstrap-anima-keyinfra.xml > +++ b/dtbootstrap-anima-keyinfra.xml > @@ -2113,12 +2113,22 @@ locator3 = [O_IPv6_LOCATOR, fe80::1234, 41, > nil]]]> > + > + The consistency check described above is the same > + process as described in section 2.6. > + Regardless of how the consistency check was done, the MASA MUST > + use the serialized value from the > + proximity-registrar-cert (in the prior-signed-voucher-request) > + when forming the voucher, as that is the only value that > + the Pledge will have. > + > > doc> match the pledge serial-number that the MASA extracts from the > doc> signing certificate of the prior-signed-voucher-request. The MASA is > doc> aware of which pledges support signing of their voucher requests and > doc> can use this information to confirm proximity of the pledge with the > doc> registrar, thus ensuring that the BRSKI-EST TLS connection has no > doc> man-in-the-middle. > >> > >> > To be clear, this MITM detection is only for the case of pledges that > >> > sign their voucher requests, right? And it seems to only hold if > >> > pledges that support signing actually do sign, every time. > >> > >> Yes, and also we have removed unsigned, so this is another place we missed > >> a conditional on that. I want to note that the manufacturer knows, by > >> construction, what the behaviour of the pledge is. > >> So I've removed the last sentence completely > > > I'm not entirely sure I follow why this means that the last sentence is > > okay to remove, but it's probably okay. > > (Also, I could imagine a case where a third-party "assigned" MASA gets an > > incomplete feed of device capabilities/behavior from the manufacturer, even > > by accident, so "by construction" is perhaps stronger than I would use.) > > The sentence says that MASA should should if the pledge can sign, and if it > does not sign, then it would know if that's okay. But since signing is now > not optional, that consideration does not apply. > > You are correct that an outsourced MASA might not have a complete list, but I > think that is out of scope. > > doc> domain-cert" of the voucher being issued. The domainID (e.g., hash > doc> of the root public key) is determined from the pinned-domain-cert and > doc> is used to update the audit log. > > >> > If the pinning takes the whole cert (per RFC 8366), then what do we need > >> > the domainID for? Just the audit log? Surely in that case SHA-1 is > >> > not a hard requirement... > >> > >> I've changed the domainID definition such that it uses the > >> SubjectKeyIdentifier, if present. That can be any algorithm that the CA > >> wants to use to identify the Entity certificate. We need to have a > >> consistently calculated value if it's not present, and RFC5280 says SHA-1. > >> > >> domainID: The domain IDentity is a unique hash based upon a > >> Registrar's certificate. If the certificate includes the > >> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be > >> used as the domainID. If not, then the 160-bit SHA-1 hash as > >> described in that section is to be used. This value needs to be > >> calculated by both MASA (to populate the audit log), and by the > >> Registrar (to recognize itself). > >> > >> Does this work? We are only using SHA-1 (for identification, btw, not > >> for resistence to pre-image attacks) as a last resort. > > > Sorry, I'm still not seeing the justification for using SHA-1 as the > > fallback instead of (e.g.) SHA-256. If the SKI is present, then definitely > > use that. But if it's not present, we can define whatever we want, can't > > we? > > I'm trying not be seen as an Update to RFC5280 :-) > Continued in next email. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > From nobody Wed Aug 14 08:39:02 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5601200C7; Wed, 14 Aug 2019 08:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 6D-5Zi81HHTD; Wed, 14 Aug 2019 08:38:49 -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 755D2120059; Wed, 14 Aug 2019 08:38:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 994253818C; Wed, 14 Aug 2019 11:38:00 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2E0E3A8A; Wed, 14 Aug 2019 11:38:48 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk , "The IESG" , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <23257.1565381837@localhost> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <23257.1565381837@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 15:38:52 -0000 --=-=-= Content-Type: text/plain https://tinyurl.com/y2skc9xz Michael Richardson wrote: >> o The subject-alt field's encoding MAY include a non-critical >> version of the RFC4108 defined HardwareModuleName. (from [IDevID] >> section 7.2.9) If the IDevID is stored in a Trusted Platform >> Module (TPM), then this field MAY contain the TPM identification >> rather than the device's serial number. If both fields are >> present, then the subject field takes precedence. >> "if both fields are present", but the subject field MUST be present, so >> this field can never take precedence. > I'm willing to drop, because I never got proper clarification. > We were told by implementors that if the IDevID is contained in a TPM that > the resulting IDevID often has the serialNumber of the TPM,not the device > itself. > *** MAX *** >> 1. [RFC4519] section 2.31 provides an example ("WI-3005") of the >> Distinguished Name "serialNumber" attribute. [RFC4514] indicates >> this is a printable string so no encoding is necessary. >> I don't understand why these references were chosen. Why are LDAP specs >> authoritative about what the encoding format for the serialNumber DN >> attribute is? E.g., one could look at RFC 5280 to see that >> X520SerialNumber is a PrintableString. > *** MAX *** We have simplified the text, removed the TPM and Hardware Module Name, etc. and clarified why we are referencing the LDAP RFC. We have left an out that says that the Registrar may need to dig elsewhere on a per-manufacturer basis. >> o In the language of [RFC6125] this provides for a SERIALNUM-ID >> category of identifier that can be included in a certificate and >> therefore that can also be used for matching purposes. The >> SERIALNUM-ID whitelist is collated according to manufacturer trust >> anchor since serial numbers are not globally unique. >> RFC 6125 does not define a SERIALNUM-ID, so maybe we could reword to "in >> the model of RFC 6125" or "provides a new SERIAL-ID category" or >> similar. > I have an open request to *** MAX *** to clarify this part. We have resolved by this removing the reference to RFC6125. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1UKwcACgkQgItw+93Q 3WXEFgf+JFIbJt+58R/PVlBIkfZCLd2ZbDtTNedZpII+1/ZcokpbhjE4TkSH7fnL WRjHsMC8qsAMKrsMiVQdFfl/RWiJDyk2Gf/pZlC7tKOiBHs6k08Hkvg6/mRbuDgv PODxAwAfwwogVQcNmbc2EArkEI86XD7GbfiRSZNnwT1U8RE+hRikn39vBymJ6+my QQ8kUBkP1TBAguXV1Hsh24+e39snlGCA8w/m82eahlZtftAZ3riJd4a/aAlUAUM6 KS6+ajw1cSlneLB569GwoQF05NVCh5oCBpNRGBPQBDbfxY3j6iwhjC+76cwMHY0u wtRDzyRBE+FKf7TbBF9P2QBUrUdQSg== =bzew -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 14 09:57:11 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531BF120BBB; Wed, 14 Aug 2019 09:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 pGgePlmwkdBl; Wed, 14 Aug 2019 09:57:00 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E027120BB6; Wed, 14 Aug 2019 09:56:59 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0CE3B3818C; Wed, 14 Aug 2019 12:56:11 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AA77DD1C; Wed, 14 Aug 2019 12:56:58 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <20190721021748.GM23137@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <12747.1563315277@localhost> <20190721021748.GM23137@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Aug 2019 16:57:03 -0000 --=-=-= Content-Type: text/plain https://tinyurl.com/y2skc9xz Benjamin Kaduk wrote: >> We did not resort to a YANG data model for the auditlog responses, so I spent >> a few minutes mystified by your complaint... then: >> We referenced 7951 (YANG->JSON), but we should have just referenced RFC7159 (JSON)! > Oh! That would make a lot more sense... (but 7159 is obsoleted by 8259, > of course) got them all now. >> If so, the reason for normative language is because, we want to say, "if you >> do X, then you MUST do it this way". >> >> Second, we have referenced some pieces of section 7.2 from section 9. >> We think that there are significant security issues by accepting nonceless >> vouchers, which we discuss in 11.1. A variation of the protocol is when >> the manufacturer programs the pledge to ALWAYS accept nonceless vouchers. >> There could otherwise be some more complex (proprietary, or documented later >> on) evaluation of whether to accept a nonceless voucher. For instance, the >> MASA could sign them with a different key, perhaps one stored in an HSM. > Okay, so it is that the client (well, manufacturer?) chooses whether or not > to accept nonceless vouchers. So we could change the introduction to the > enumerated list to be saying that this is a list of exclusive candidate > behaviors that could be chosen independently of each other, and not a > collection of behaviors all of which are expected to be implemented. I have revised section 7.2. My use of normative language seems inconsistent at this point. I need to distinguish between "X is possible" from "when doing X you MUST Y" better. >> > (14) In Section 5.6: >> >> > The server MUST answer with a suitable 4xx >> > or 5xx HTTP [RFC2616] error code when a problem occurs. In this case, >> > the response data from the MASA MUST be a plaintext human- readable >> > (ASCII, English) error message containing explanatory information >> > describing why the request was rejected. >> >> > It seems hard to support this stance on internationalization in 2019. >> >> We don't believe that this response will go anywhere other than logs, >> for software suppliers to evaluate. Localizing these error message causes >> more problems in my experience than benefit. 90% of the information is in >> the 4xx/5xx code. > I should probably defer to my ART-area colleagues here. But you're saying > that mandating English is better than allowing UTF-8 and otherwise leaving > it as implementation defined? We have removed "ASCII, English), and left this as "UTF-8", with the expectation that the message may be localized. Emphasis is on human readable. >> > (15) In Section 5.9.4: >> >> > To indicate successful enrollment the client SHOULD re-negotiate the >> > EST TLS session using the newly obtained credentials. This occurs by >> > the client initiating a new TLS ClientHello message on the existing TLS >> > connection. The client MAY simply close the old TLS session and start >> > a new one. The server MUST support either model. >> >> > Is this supposed to be sending a new TLS ClientHello in the application >> > data channel or as a new handshake message (aka "renegotiation")? The >> > latter is not possible in TLS 1.3 and is generally disrecommended >> > anyways even in TLS 1.2. I would strongly suggest to remove the >> > "renegotiation" option and just leave "close the connection and start a >> > new connection/handshake". >> >> Okay, fixed to say: >> >> To indicate successful enrollment the client SHOULD re-negotiate >> the EST TLS session using the newly obtained credentials. This >> - occurs by the client initiating a new TLS ClientHello message on the >> - existing TLS connection. The client MAY simply close the old TLS >> - session and start a new one. The server MUST support either >> + occurs by the client closing the existing TLS connection, and >> + starting a new one. The server MUST support either >> model. > I'd prefer to s/re-negotiate/re-establish/ as well, but this is probably > good enough to clear the discuss. Changed. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1UPVoACgkQgItw+93Q 3WVi8gf/VXSyf0Uvq6QxA7VTyzCwWrCPxRqy0Cw3WQ2Y2/F8VMrtLwoBQitnX4v8 XyYoSEhi9M+okQPt7IU1dCX/rfXPYlX1C99wzTvFX+3dgqAMnu9Oy9ZtqoyZBYAm IrsBpymZjfI5VzxTMLKtHlISNlpWmqk18oTuuvCk3bbo1BR7wcXJrjq4fgOePaGp h8DW/UJ/tp45ZW8dZ8TtuLj5Gio49lMPaCmshfpQ1DVp+sI5k9VLGkXbq8rACSRh Mem17Hx56UXLcDKSj9mJ+silzBPP9XFhoVu+qFFHae86b9YGZQkpeTwEYgxcgR9B gDLEptrCDdRjAul1nDZy+SVj0v67PQ== =iPOX -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 14 18:10:41 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B0112001A; Wed, 14 Aug 2019 18:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 eiaFxqK8rUdh; Wed, 14 Aug 2019 18:10:29 -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 0018F120019; Wed, 14 Aug 2019 18:10:28 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id AA5B43818C; Wed, 14 Aug 2019 21:09:38 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D5F08A8A; Wed, 14 Aug 2019 21:10:26 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <20190809225540.GV59807@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <23257.1565381837@localhost> <20190809225540.GV59807@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 01:10:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Benjamin Kaduk wrote: >> Are you asking for a forward reference to 10.2? I will add this. >> I think that section 10.2 is pretty clear about this. >> I don't think it's mentioned just in passing. > It looks like the main coverage here is: > o the identity of the device being enrolled (down to the serial- > number!). > and the discussion in the last three paragraphs or so. > I do appreciate the importance of distinguishing between the high-end > router and the human users (and we will have a long hard think about = it > again when BRSKI profiles for IoT use come through, I'm sure), so tha= nk you > for that. But I'm not sure that we clearly draw the connection to "t= he > manufacturer knows the identity of the device being enrolled" to "and= can > guess where it is, and definitely knows who the owner is, and can > potentially follow that over time if the device has to reenroll". No= w, for > the high-end router case there is literally nothing new here -- the v= endor > is assumed to already be doing inventory tracking of which customers = have > which routers! But I think it's important to make the connection from > "knows identity" to "tracking", since this topic will come up for any= use > of BRSKI in other situations. we added the following to the end of the point list: Based upon the above information, the manufacturer is able to track a specific device from pseudonymous domain identity to the next pseudonymous domain identity. If there is sales-channel integration, then the identities are not pseudonymous. >> > 3. Secure auto-discovery of the pledge's MASA by the registrar (s= ee >> > Section 2.8). >> >> > I don't think this is an ironclad property, since the crypto chain= is >> > slightly limited and you are in effect trusting the pledge to hand= you >> > something that says "use this issuer" but without as much crypto t= o back >> > that up as we might want. We have to know that the given manufact= urer >> > that signed the IDevID actually is associated with the device we're >> > trying to bootstrap, which can probably be arranged but I don't re= member >> > being called out explicitly. >> >> There are two issues here. >> >> One is the question of what is the list of acceptable manufacturers = (below). >> The second part is whether a pledge could provide a fake IDevID to >> the Registrar. The pledge is doing TLS ClientCertificate, so the TLS >> has proven that the pledge has the private key corresponding to the >> certificate presented. I conclude that an arbitrary IDevID can not = be >> provided by the Pledge; it has to be linked to SOME manufacturer. So= me > Well, it has to be linked to some entity that signed the IDevID. Tha= t may > or may not be a manufacturer, but the Registrar does have the capabil= ity to > look at what signed the IDevID and apply a whitelist of known, verifi= ed, > manufacturers. One either has a list of trusted manufacturers or one does not. This can be done via a list of trust anchors for the IDevID signing entity, or can be done via a list of trust anchors for the MASA URL. If not (in a residential use of BRSKI perhaps), then there has to be some process by which a not previously known manufacturer can become trusted. There are a great number of layer-8 or layer-9 solutions for this, perhaps involving new industry CAs or attestations, or ... I think it is o= ut of scope. (for instance RFC5280 section 4.2.2.1 could provide the right references, but this section has not been well used as yet. Or we could extend the MASA EST to include additional information) >> The question then becomes how the Registrar comes to trust/verify the >> pledge's IDevID. We had a long discussion about this during the dir= ectorate >> reviews and going back to Feb. 2018. I thought that we resolved thi= s. >> Issues >> https://github.com/anima-wg/anima-bootstrap/issues/120 >> https://github.com/anima-wg/anima-bootstrap/issues/43 >> https://github.com/anima-wg/anima-bootstrap/issues/46 >> A thread starts here: >> https://mailarchive.ietf.org/arch/msg/anima/p7pUw1HKq6Ot0gV8JPeRWhwv= QTs >> >> Some changes that we made for this: >> https://github.com/anima-wg/anima-bootstrap/commit/e5ffec4cc70362601= 2d62c0b3138d851b61a2f54 > Maybe, "Configuration or distribution of these trust anchor databases= is > out-of-scope of this specification. Note that the trust anchors > in/excluded from the database will affect which manufacturers' device= s are > acceptable to the registrar as pledges, and can also be used to limit= the > set of MASAs that are trusted for enrollment."? we have added this to section 5.1. >> > Section 7.2.13 of [IDevID] discusses keyUsage and extendedKeyUsage >> > extensions in the IDevID certificate. Any restrictions included >> >> > I only got my hands on the 2018 rev of [IDevID], but that one does= not >> > actually talk about extendedKeyUsage. >> >> Max was the editor of the 2009 edition, and we pointed at it. >> I don't seem to be able to get the 2018 edition. > I think we could probably reword this to just acknowledge that [IDevI= D] > acknowledges that adding restrictions in the certificate can limit > applicability, and since these are long-lived, usually you don't want= to > throw random extra restrictions into them. We have determined that section 8.10.3 of the -2018 has the same text. Neither Max nor I have the official -2018 version, so we are writing: Section 7.2.13 (2009 edition) and section 8.10.3 (2018 edition) of discusses keyUsage and Our recommendation continues to be that no EKU be added (consistent with 1AR, if you have to, then it has to include digitalSignature). >> > Section 2.3.1 >> >> > In the context of BRSKI, pledges are uniquely identified by a >> > "serial-number". This serial-number is used both in the "serial- >> > number" field of voucher or voucher-requests (see Section 3) and in >> > local policies on registrar or MASA (see Section 5). >> >> > (editorial) if the IDevID is supposed to be a unique identifier, w= hy do >> > we need another one? >> >> The pledge extracts it from it's IDevID. >> The registrar extracts it again from the IDevID that it sees. >> It's seems hard to construct an attack where the provisional TLS con= nection >> is MITM (replacing the certificates). So I'm gonna claim belt-and-su= spenders >> here.... the cross-check seems useful, but maybe in the end, it's a = left-over >> From when voucher-requests could be unsigned. > I don't actually have a big complaint, here (and am definitely not as= king > to change the wire bits!). Perhaps we could go easy on "unique" or m= aybe > just acknowledge that there's supposed to be a 1:1 map between serial > number and IDevID. (Or not, of course.) I went with 1:1 text. >> >> > In Figure 3, I had to think a bit to figure out whether the text t= hat >> > did not fit mid-arrow was supposed to apply to the arrow above or = below >> > the text (e.g., "optional: mDNS query RFC6763/RFC6762"). >> >> Yes... we did struggle to fit it into a single page. >> It applies to both the arrow above and below, and there are M_FLOOD >> and mDNS possible here. Do you have suggestions on making it cleare= r. > Hmm, maybe give each one a unique symbol (+*&$#?) and put that in the > middle of the relevant arrows as well as in the text? I'm not sure what you mean. https://github.com/anima-wg/anima-bootstrap/edit/master/time-sequence-dia= gram.txt >> In the ANI case, we are likely doing this over wired links (long-hau= l fiber >> or internal to DC), but in the anticipated TEAP-BRSKI use case or 6t= isch >> use, this would be WIFI / 802.15.4. >> >> What is needed is a three-party zero-knowledge proof, but how would = the >> Registrar identify the third party (the MASA)? >> >> You are right to worry, but I don't know what to do about this. > I don't, either. Well, I do: "document it and move on", but that sti= ll > leaves a bad taste in my mouth. new section added: 10.2. What BRSKI-EST reveals to the registrar During the provisional phase of the BRSKI-EST connection between the Pledge and the Registrar, each party reveals it's certificates to each other. For the Pledge, this includes the serialNumber attribute, the MASA URL, and the identity that signed the IDevID certificate. TLS 1.2 reveals the certificate identities to on-path observers, including the Join Proxy. TLS 1.3 reveals the certificate identities only to the end parties, but as the connection if provisional, an on-path attacker will see the certificates. This includes not just malicious attackers, but also Registrars which are visible to the Pledge, but which are not part of the the intended domain. >> > Section 2.5.1 >> >> > The pledge is the device that is attempting to join. Until the >> > pledge completes the enrollment process, it has link-local network >> > connectivity only to the proxy. >> >> > nit(?): I think there is a subtle difference in meaning between "= only >> > has link-local network connectivity to the proxy" and this text, a= nd I'm >> > not sure which is intended. >> >> I'm confused. > The current text asserts that it has link-local connectivity, and fur= ther > that the extent of this connectivity is limited to the proxy. My > alternative asserts that it can only talk to the proxy over this > link-local connectivity, but leaves open the possibility of other > avenues of communication (e.g., a WWAN card). I guess by WWAN card, you mean some kind of LTE or 5G connection? Or do you mean 802.11/802.15.4? The distinction matters, because LTE cards have SIM cards, and therefore are not zero-touch. >> > Section 2.6.2 >> >> > [RFC5280] explains that long lived pledge certificates "SHOULD be >> > assigned the GeneralizedTime value of 99991231235959Z". Registrars >> >> > This misses the important "for the notAfter field" part. > (The above and below were separate comments; not sure if that came > through.) Oh, I get it. Added "for the notAfter field" >> > Why is 3 years the relevant cutoff here? >> >> That's a good question. *** MAX *** okay, changed text. [RFC5280] explains that long lived pledge certificates "SHOULD be =2D assigned the GeneralizedTime value of 99991231235959Z". Registrars =2D MUST support such lifetimes and SHOULD support ignoring pledge =2D lifetimes if they did not follow the RFC5280 recommendations. + assigned the GeneralizedTime value of 99991231235959Z" for the + notAfter field. =2D For example, IDevID may have incorrect lifetime of N <=3D 3 years, =2D rendering replacement pledges from storage useless after N years =2D unless registrars support ignoring such a lifetime. + Some deployed IDevID management systems are not compliant with the + 802.1AR requirement for infinite lifetimes, and put in typical <=3D 3 + year certificate lifetimes. Registrars SHOULD be configurable on a + per-manufacturer basis to ignore pledge lifetimes when they did not + follow the RFC5280 recommendations. >> > In order to support these scenarios, the pledge MAY contact a well >> > known URI of a cloud registrar if a local registrar cannot be >> > discovered or if the pledge's target use cases do not include a lo= cal >> > registrar. >> ben> I don't see the connection between "configure itself to become the ben> local registrar" and "contact a well-known URI of a cloud registra= r". >> >> In a completely Greenfield situation, where there is no local infras= tructure >> at all, given an appropriately magic "Intent" (remember where this WG >> started...), then a cloud registrar could inform a device that it is >> to become the Registrar. How this would work depends upon the detai= ls >> of the magic unicorn Intent (see failed SUPA WG). > Ah. So the cloud registrar is an extra-featureful registrar that can= do > more than just register things. I get it now, but am not sure how to= best > word it. The point of that section is to rule (magic unicorns) out of scope. It doesn't really matter if we describe the magic correctly, does it? :-) >> > If the pledge uses a well known URI for contacting a cloud registr= ar >> > an Implicit Trust Anchor database (see [RFC7030]) MUST be used to >> > authenticate service as described in [RFC6125]. This is consistent >> ben> Would this be more likely to be installed by the manufacturer or ben> device owner? >> >> Manufacturer, as it's implicit. That's how EST works today. > So you think "implicit" is enough and adding something like "burned-i= n" or > "manufacturer-assigned" is overkill? We are trying to use the EST terminology here.... how about: =2D an Implicit Trust Anchor database (see ) MUST + a manufacturer-assigned Implicit Trust Anchor database (see = ) MUST >> There is a TLS connection between them. Yes, it could go anywhere. >> The proxy was link-local, and the proxy pointed the connection at the >> Registrar. I guess it would be useful if the proxy was stateful, and >> contributed another cryptographic layer for non-ACP cases. >> >> In the ACP case, the Registrar knows it can trust the proxy because = it's on >> the ACP, and is connecting from an ULA address that is part of the A= CP. >> >> Yes, the Registrar could be anywhere, but the proxy makes it appear >> to be on the local link. >> >> I'm not sure what else I can add to the text. > "There is a TLS connection between a and b" says almost nothing witho= ut > some additional context -- there are millions of machines I can make = a TLS > connection to from here. I assume that the unstated context here is = that > the pledge is expected to be in a limited-connectivity environment, s= o the > fact that the network allowed the connection through to the registrar > conveys meaning. But I don't remember anything in this document that > actually validates that the pledge really is in a limited network > environment. Could some rogue node ("attacker") be trying to talk to= a > proxy or registrar directly, from somewhere else in the network? How= would > we tell? The pledge has made a connection over a Link-Local IPv6 connection. The Registrar has a connection from a ULA numbered Join Proxy across the ACP. That's not a connection across the Internet. It's true that neither end can validate what the other end sees. The Join Proxy could be doing something else: it could punt the connection elsewhere, or it could channel (in the s=C3=A9ance sense) a pledge from some other place. If that were occuring, there would indeed be some problem. Other proposed uses of BRSKI (TEAP-BRSKI) would connect using EAP over 1x+radius/diameter. Would some addition to the ACP applicability stating the above be useful? >> But, that's why we have SHOULD, and the SHOULD (vs MUST) part was re= ally to >> allow for some fancy HTTP/3 we know nothing about :-) > :) > Do we still want to say "HTTP 1.1 persistent connections" vs. "HTTP > persistent connections", though? I'll remove the 1.1. At the time, we didn't know what HTTP/2 would have. I think we asked, and were told that HTTP/2 always had persistent connections, so there was nothing really to say. I see this as a statement to some product manager that they really do need to upgrade their 1998 era HTTP library with something newer. >> I have an open request to *** MAX *** to clarify this part. >> >> > o The registrar performs log verifications in addition to local >> > authorization checks before accepting optional pledge device >> > enrollment requests. >> >> > Maybe give us a section reference to what the "log validations" ar= e? >> >> We decided that we did not have enough experience to write normative >> language >> here. (It's not an Internet Standard) > It doesn't have to be normative, but some discussion of things that m= ight > come into consideration during that process could still be useful. I really think that 5.8.3 says enough. I have 39 emails in my to-read relating to other DISCUSS. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1UsQIACgkQgItw+93Q 3WXnkgf/QZJMNQ+xtxKxAKFOzi2pjaGIUjCHKUuWqc2rn71yjOilx5p2vckSPwa+ Q2MkLQrhV47XQ9dSlTL2ytNzTaNsqs0QEGB9EDRtP4+4iWjJVhOQwySZoqkcpPSQ R/uf34RHTYEj+Y93lVszOEITT92l8I2dh7nvhcjUMU/aG3Q02r7+ai5ICjAHp1jT m4L1mXowmqcUzVIev87PbhhxQbqjSBCcwgRH85fKqIKeiOommOjixCQ14iD7m5/3 3S5ZP1qyXE77veS/6hq5zH/osMbR5M6oG0ZzAZCMRZ81NLLfMLyrwbd4j3MFdgY+ QsOLJBilHNGaoKE5nxO30mXeRz0d+A== =3HMW -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 15 09:17:36 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4399F1200B8; Thu, 15 Aug 2019 09:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 UKOUVPGYIVt7; Thu, 15 Aug 2019 09:17:24 -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 1DFBD1200C1; Thu, 15 Aug 2019 09:17:23 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 9EC1E3818C; Thu, 15 Aug 2019 12:16:33 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C0566D1C; Thu, 15 Aug 2019 12:17:22 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org In-Reply-To: <20190813172532.GM88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <25503.1565496367@localhost> <20190813172532.GM88236@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 16:17:26 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Benjamin Kaduk wrote: doc> The MASA and the registrars SHOULD be prepared to support TLS clie= nt doc> certificate authentication and/or HTTP Basic or Digest doc> authentication as described in [RFC7030] for EST clients. This doc> connection MAY also have no client authentication at all (Section doc> 7.4) >> > I don't see discussion of skipping client authentication in Section >> 7.4. > It would be great to have some, there! >> It's buried in point 2. > Oh, the "not verifying ownership" part? I somehow was interpreting > that as "we still require client authentication, but don't have a fan= cy > database mapping owner to hardware, so any authenticated registrar can > get a voucher for any device". There are multiple models on how to operate a MASA. We think that which one is right depends a lot on the value of the device (in the ACP space, $100K routers vs $100 CPE devices), and also at the degr= ee of sales channel integration. There is value in authenticating the Registrar, even if one does not know which device has been deployed. In particular, this model supports the <4h SLA on service repair that most vendors have, and which they support by stocking spares in the local city, but not for a specific customer. I see that I've answered the rest already. The perils of all these CCs. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1VhZIACgkQgItw+93Q 3WXPqAf+IpMbhhIn61N68wBmqBTN/jKlErpn35tmw575gKCZZ2Uk1mg3gR8Ck++7 eAetMi2vr/vhM2j8CFbEwcWEvUvvVQte7+1szOTALh+05SHepgHqZLAB8yIe2Yo6 a9b6J6bdePoIIRXQP16FWymHINXR6tyomblotRftUG7yNop6VDMZl+zS2yNTSbSW 4JRtgQ1EEqi+ejCkKqTQsRt+W9vzb29EGMKZ1jdd5bMGZEmpm6moR4vn1g83fNas KssB3BeW+ACVU7g0ZEEr0sOcEOZgU4j2Nuwcc19+sJvSPJvRnQ9DsDV0LCBPmREQ BTTv+KF9yaVLDdUqcXOiCkBO5E4l2Q== =20oK -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 15 09:28:24 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2F51200B8; Thu, 15 Aug 2019 09:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 pI1OguEmEha8; Thu, 15 Aug 2019 09:28:19 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEAD6120105; Thu, 15 Aug 2019 09:28:18 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4C9CB3818C; Thu, 15 Aug 2019 12:27:28 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 70E74D1C; Thu, 15 Aug 2019 12:28:17 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, The IESG , anima-chairs@ietf.org In-Reply-To: <20190814151216.GZ88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <25503.1565496367@localhost> <20190813172532.GM88236@kduck.mit.edu> <14229.1565730466@localhost> <20190814151216.GZ88236@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 16:28:22 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Benjamin Kaduk wrote: > Apparently I only have one comment buried inline. We must be making > progress :) >> > The audit log is a defense against this in that it allows for >> post-facto > discovery of misuse? Or is there some pre-issuance >> authorization check > going on. > I think I may need some section >> references to where the authorization > policy (options) are >> documented; I've lost a bit of state on this one. >>=20 >> That's right, the audit log provides discovery of mis-use. The check >> belongs prior to issurance of an LDevID, and may be repeated regular= ly >> afterwards. >>=20 >> I think you are asking for a list of MASA authorization policy >> options. We do not have such a menu of options, and I'm reluctant to >> write them down normatively at this point, as I think that there are >> combinations we do not yet understand. >>=20 >> 5.5.3 points out that nonceless vouchers need more authorization. >> Other parts of 5.5 provide other options. Please let me know if you >> think this is insufficient for a Proposed Standard. > I think I'd like to see a small addition after/near "[t]his > verification is only a consistency check that the unauthenticated > domain CA intended the voucher-request signer to be a registrar" > (perhaps at the end of the paragraph?) noting something like "since t= he > domain CA is unauthenticated to the MASA, depending on MASA policy, > vouchers not authorized by the pledge owner may be issued; the MASA > audit log can be used to detect such missisuance". I've added: Even when a domain CA is authenticated to the MASA, and there is strong sales channel integration to understand who the legitima= te owner is, the above cmcRC check prevents arbitrary End-Entity certificates (such as an LDevID certificate) from having vouchers issued against them. Other cases of inappropriate voucher issuance are detected by examination of the audit log. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1ViCEACgkQgItw+93Q 3WWS1Af/Vef2nawv6yR8WMpfhhjXAB8VF6s9kU8ob1m9uThsZ2cLNpe1pkXRTDwx IRqsjmgVrP5fA9MUa5TetB5YvD1eaiMZo4mNc/FVQY9VR7NawWOvRc76KaSInzpL cIwpDEk1mfm89LKz3ZXUudjxaiToL9OtM6yyR0tB5p9PFmfWaAQ8mOn0Uy+mb7Yo wRrtp3z2txttimzPRzaBq50CX3dfjmB/9NDd82WyJS5m9bfg6IEVjyMM4ZwkMBV0 uUKdSOXpG7nDnnQDO8xTlDMDkvXlF536u2nN+uqCns+CwQZsB8p5f6uqMCeGom+s 5Tao0VOzYchM6m8+JU9qjv2tnV1LAQ== =oceC -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 15 09:59:12 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DD71200EB; Thu, 15 Aug 2019 09:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YnKXmmILILnP; Thu, 15 Aug 2019 09:58:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EEE1120105; Thu, 15 Aug 2019 09:58:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 34E1E3818C; Thu, 15 Aug 2019 12:57:56 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 60B60D1C; Thu, 15 Aug 2019 12:58:45 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <20190814142737.GV88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <17440.1565636744@localhost> <20190814142737.GV88236@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 16:59:02 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Benjamin Kaduk wrote: >> + directly. This is because BRSKI pledges MUST use the CSR Attribut= es > (This may not need to be a 2119 MUST since we cite 7030.) It turns out, in pracice, that many EST clients do not use the CSR Attributes, so I need this line as a hammer. >> > "intended" implies that the EST server has some knowledge of what >> the > pledge is expected to be doing in the network, right? >>=20 >> Yes. The ACP document is quite specific about the (rfc822Name) >> attributes to assign. Certainly the attributes could include stuff >> like "ve608.core1.tor1.example.net" if the Registrar knew how this >> device was to be used, but more likely that would be set up >> afterwards. > Hmm, maybe later when we say "the local infrastructure (EST server) > informs the pledge of the proper fields to include in the generated > CSR" we could reiterate that the EST server has local configuration > information to inform this messaging, though it's probably not > necessary. I've added the (). + fields to include in the generated CSR (such as rfc822Name).=20 doc> To alleviate these operational difficulties, the pledge MUST reque= st doc> the EST "CSR Attributes" from the EST server and the EST server doc> needs to be able to reply with the attributes necessary for use of doc> the certificate in its intended protocols/services. This approach doc> allows for minimal CA integrations and instead the local doc> infrastructure (EST server) informs the pledge of the proper fields doc> to include in the generated CSR. This approach is beneficial to doc> automated boostrapping in the widest number of environments. >>=20 >> > This is convenient, but has some security considerations in that it >> > implies that the validation policy on the CA is somewhat lax, since >> the > EST server is expected to be doing most of the policy controls. >> Thus, > a compromised pledge/device could send a CSR with unauthoriz= ed >> fields > and it is likely to be signed, allowing for some level of >> privilege > escalation. When the registrar acts as a proxy to the CA >> as well as > its EST role, as described later, this risk is >> diminished. >>=20 >> I don't really understand. EST servers are Registration Authorities, >> and they have some kind of priviledged access to the CA, and are >> mandated to check the CSR. I expected to find a statement to this >> effect in RFC7030, in section 4.2.1, but I don't see any particularly >> strong language. This seems like a quality of implementation issue = in >> the Registrar. > The high-level intended workflow described here is roughly "(1) pledge > asks registrar for config; (2) pledge puts that config in a CSR, signs > the CSR, and sends the CSR to registrar; (3) registrar passes CSR to = CA > using registrar's implicit authority. We don't describe any crypto to > check that (2) happens as intended, as opposed to the pledge > dishonestly claiming "oh, and I'm a CA" or "I can provide all ACP > services, even privileged ones", so that has to be done by policy in > the registrar, as you note. I'm wary of suggesting the workflow that > relies on the registrar's implicit authority at the CA without also > noting the registrar's policy enforcement obligations. Though it's > possible this is covered elsewhere and doesn't need to be duplicated > here. I think it goes back to the RA and more specifically, the CA, being boss of what going into a certificate. To the point where it generally seems real= ly hard to deploy new extensions in the public WebPKI. It does say: The registrar MUST also confirm that the resulting CSR is form= atted as indicated before forwarding the request to a CA. If the registrar= is communicating with the CA using a protocol such as full CMC, which provides mechanisms to override the CSR attributes, then these mechanisms MAY be used even if the client ignores CSR Attribute guidance. >> > Section 7 >>=20 >> > If this is non-normative and will need to be fleshed out in a >> separate > document, would an Appendix be more appropriate? >>=20 >> Section 9 and 10 refer back to this section in a normative fashion. > Er, wouldn't that make this section no longer non-normative? (Not th= at > I could find the references you're talking about, so a clue bat is > welcome.) It's of the form, "if you wish to do X, then you MUST do Y" (but, X is not a MUST). section 9: In recognition of this, some mechanisms are presented in Section 7.2. The manufacturer MUST provide at least one of the one- touch mechanisms described that permit enrollment to be proceed without availability of any manufacturer server (such as the MASA). >> > I think this is maybe more of a "does not enforce" than "does not > >> know", since the domainID ends up in the audit logs that the MASA > >> holds. >>=20 >> Yes, but the domainID does not directly identify the Registrar by >> name. Assuming a database breach, what does the MASA know that it c= an >> reveal. > can reveal or be correlated with other sources of information. The > domainID is derived from the public part of a certificate, which could > well be widely disseminated. An attacker that compromises the MASA a= nd > retains a presence can watch requests come in and backsolve from > domainID to certificate directly. Right, so that's 11.4.3, where the attacker controls the web server. At which point, they don't need to compromise the database, I think, as they can just access it. I think of a database dump as being offline: I get access to your backups, or I find an SQL injection attack that exfiltrates data, but does not give me control. >> > A nonceless voucher can still include an expiration time ... it is >> just > in practice possible for it to never expire, if the target >> pledge does > not have an accurate clock. >>=20 >> Yes, that's correct. How many devices with RTCs survive 10 years in= a >> warehouse with no power? :-) > The ones with a radioisotope thermoelectric generator? ;) So RTCs with RTGs. Apparently not much plutonium is left for future missions. >> fixed. >>=20 >> > Section 9 >>=20 doc> The autonomic control plane that this document provides bootstrap doc> for is typically a medium to large Internet Service Provider doc> organization, or an equivalent Enterprise that has signficant doc> layer-3 router connectivity. (A network consistenting of primarily doc> layer-2 >>=20 >> > nit: "is used in" -- the ACP is not the entire organization! >>=20 >> The text doesn't have "is used in" > (Right, I was saying that you should add it. But the reworking fixes > the nit, so this is all good.) got it. doc> There are a number of design choices that mitigate this risk. The doc> domain can maintain some privacy since it has not necessarily been doc> authenticated and is not authoritatively bound to the supply chain. >>=20 >> > Is this really "privacy" or just "semi-plausible deniability"? >>=20 >> It's a good question. A domain could use a new certificate for each >> device, could connect via some onion router. Is that privacy, or >> "semi-plausible deniability"? > It might depend on the details of the certificates used, what CA issu= ed > them (and its policies regarding accuracy and level of detail in > certificates issued therefrom), and whether the certifciates are > used/exposed for any other purposes. So, I don't insist on any > specific language, and was just sharing my thoughts about how it is > possible to think about this, in case it sparked any insight. Agreed. I think that it's hard problem. doc> The above situation is to be distinguished from a residential/ doc> individual person who registers a device from a manufacturer: that doc> an enterprise/ISP purchases routing products is hardly worth doc> mentioning. Deviations would, however, be notable. >>=20 >> > Deviations in what sense? >>=20 >> After buying only Cisco equipment (like ASR 9000) [observed by number >> of MASA connections after each POP turn up], ISP example.net suddend= ly >> has started communicating with Juniper's MASA (for MX40s..). > So like "deviations from a historical trend" or "deviations from an > established baseline"? added that text. >> > Section 10.3 >>=20 doc> 4. There is a fourth case, if the manufacturer is providing doc> protection against stolen devices. The manufacturer then has a doc> responsability to protect the legitimate owner against fraudulent doc> claims that the the equipment was stolen. Such a claim would cause doc> the manufacturer to refuse to issue a new voucher. Should the doc> device go through a deep factory reset (for instance, replacement = of doc> a damaged main board component, the device would not bootstrap. >>=20 >> > I'm not sure I understand this scenario -- is it talking about whe= re >> a > third party makes a false theft report in the hopes that the real >> owner > will have to do a deep reset and then have the device fail to >> bootstrap > because of the reported theft? >>=20 >> Yes. > I think having "In the absence of such manufacturer protection, such a > claim would cause [...]" would have helped me get there. added. doc> registrar. This is mandated anyway because of the operational doc> benefits of an informed administrator in cases where the failure is doc> indicative of a problem. The registrar is RECOMMENDED to verify doc> MASA >>=20 >> > I'd also expect some comment about the limited value of the >> additional > information to an attacker in the context where the >> attacker already > would know [other information]. >>=20 >> I'm not sure what other "other information" is yet, so I don't know >> how to fill that in. > IIUC, this text is predicated on a "possibly malicious registrar" that > a pledge tries to register using/through but fails. So that registrar > is already in a position where the pledge would try to use it -- in t= he > ACP case, that probably means fairly physically proximate, and maybe > implies a link-local connection. Agreed. In the ACP case, imagine an ISP border router on which there are a = number of links; some of which are internal (legitimate Join Proxy), and some of which are external links to another ISP's border router (Q). The Join Proxy on Q really doesn't know if the purpose of that link has changed from external to internal. That's exactly the case of a non-malicious mistake in finding the right network. > In the non-ACP case, maybe it also > implies proximity? I don't know if we can get physical vs. network > proximity implied by a pledge trying to use a registrar, but maybe > sometimes. My implied question is basically "what else would an > attacker have to do to get a pledge to try to use it as a registrar, > and what does the attacker already have access to by the time it gets > that far?" So we can set the information learned from voucher parsing > status reports in the context of what else the attacker would already > know. But I don't have the best picture on the deployment scenarios > here, so I can't answer the question myself :) We left the warning there so that the people writing code would think about this tuscle. My opinion that security paranoia has often gotten in the way = of building debuggable security systems that actually work.=20=20 doc> this might be an issue during disaster recovery. This risk can be doc> mitigated by Registrars that request and maintain long term copies doc> of "nonceless" vouchers. In that way they are guaranteed to be ab= le doc> to bootstrap their devices. >>=20 >> > This, of course, comes with a different risk of what is something >> like > a long-term credential existing that needs to be protected and >> stored. >>=20 >> I partially agree. Long-term nonceless vouchers still pin a specific >> domainID. So they need to available, but they don't need to be >> private. > It's not entirely clear to me that it's okay to make them totally > public (but maybe I am missing something). That is, in that once the > voucher is public, anyone who can get next to the device can > re-bootstrap it using that voucher, which possibly gets it into a > configuration that's not usable in its current location, and (less > likely) maybe it's hard for the real owner to get the correct > configuration back (if the original MASA is gone or whatever). So the > voucher is not something I'd want to just put on a public web site. > But I guess maybe you don't have to protect it to the same extent that > you do your crypto keys. Not anyone can use the nonceless voucher to bootstrap a device. If it did, then that would be a bearer voucher ("cash") It still pins a specific domain CA ("pay $X to Mr. Y"). It's a public document in the same sense that a public key is. >> > This gets a bit more complicated to reason about when we assume th= at >> a > pledge will have multiple voucher requests out in parallel, >> instead of > doing them in sequence and timing out (so that there is >> literally only > one valid nonce at a given time)... >>=20 >> Agreed. But, we think that doing things serially has too much >> potential to run into head-of-queue challenges; the risk is that if >> devices don't onboard relatively quickly, then BRSKI will get turned >> off, not used, or the vendor might provide some "backdoor" > That's a fair concern, but in and of itself is not an excuse to skip > reasoning through the risks of the parallel workflow. How much effort > has already been spent doing that reasoning through? For example, one > might want to require that the pledge track which nonce belongs to the > voucher request submitted through which candidate registrar, but I > didn't work through whether that actually will defend against any > attack scenarios. Each attempt needs to use a distinct nonce. I thought we said that.=20=20 We say that in section 11, but I've added it to 4.1. >> I have dug around cabforum.org and root-servers.org for some >> references on what a "well-run secure CA" should be >> doing... surprisingly I didn't find an RFC, or one for DNSSEC root >> operation. Did I miss them? I thought that there was one. I'm >> writing some text, and I'll finish this email here, and post the >> resulting text. > I think I had always assumed this was part of the CA/B forum baseline > requirements (https://cabforum.org/baseline-requirements-documents/) > but never actually looked. :-/ We could ask around if it's important > (but I don't think there's an RFC). I will save it for an operational document. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1Vj0UACgkQgItw+93Q 3WWkFwf/RqpChc/0m/mNpNNd0q8vQnu5PpjlEKwl5BzyiNwq1n7KkrCfpI4+jkY9 NMRV0GAXQ3b9jWqYFKmqBhbVWzmuCZRt9Gs3lvn2J21sRbH4P4N05SYt2dn91PgJ 6iG+wSmM3k5FKqChovRhIE5UYNhn5g37NaP1hKXzu7vA19SSxZIJR2I88oDngrXp Tck2hgFUZtF8/Z/sZM9bUqyPvIlQmqpP8DvDwagRAzLk6psVaDDj0RvM4Evf0xsw s007hVbDJoNggk4Ptbu4FsaNr1/FzGySKSktDk6Zq1dmlMVFfa6gbGKZE0XKBB+X Q1BGAA5zbUAoBaq4wHaMR2CphKa6Hw== =tWD/ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 15 10:02:59 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C80120105; Thu, 15 Aug 2019 10:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 15sBF2sLHOpX; Thu, 15 Aug 2019 10:02:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A11512011D; Thu, 15 Aug 2019 10:02:46 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 274E43818C; Thu, 15 Aug 2019 13:01:56 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 54B2AD1C; Thu, 15 Aug 2019 13:02:45 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: anima@ietf.org, The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org In-Reply-To: <20190814145258.GX88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <22660.1565638213@localhost> <20190814145258.GX88236@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 17:02:51 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Benjamin Kaduk wrote: >> There does not otherwise seem to be any risk from this compromise to >> devices which are already deployed, or which are sitting locally in >> boxes waiting for deployment (local spares). The issue is that > (That is, if the boxes are already in local storage at the time of > first compromise) yes. If you have physical care of them, then nobody could have tried an attack while the MASA signing key was compromised. >> The authors are unable to come up with an attack scenario where a >> compromised voucher signature enables an attacker to introduce a >> compromised pledge into an existing operator's network. This is the >> case because the operator controls the communication between Registr= ar >> and MASA, and there is no opportunity to introduce the fake voucher >> through that conduit. > This seems predicated on the attacker having the MASA signing key but > not persistent control of the (formerly?) legitimate MASA service, > right? yes, that's right. Assume the key was generated in a deterministic way (the way the SSH keys were), or brute-forced, or something like that. >> A key operational recommendation is for manufacturers to sign >> nonceless, long-lived vouchers with a different key that they sign >> short-lived vouchers. That key needs significantly better protectio= n. >> If both keys come from a common trust-anchor (the manufacturer's CA), >> then a compromise of the manufacturer's CA would be a bigger problem. > (probably some wordsmithing options for "be a bigger problem") how about: If both keys come from a common trust-anchor (the manufacturer's CA), then a compromise of the manufacturer's CA would compromise both keys. Such a compromise of the manufacturer's CA likely compromises all keys outlined in this section. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1VkDUACgkQgItw+93Q 3WXOLAf+OxTl5oJDAPY36CuFPEVrrtXJtIo1VdA9YDj1dyHCAjOWBB3h+j69vyXF OCTZC+bkjRyOOs1l/LXhSkYqrhIq7JJTT3NVbD7bgVANYCCUJaOqc9SWAXl4lWj5 5i4By6VvuoUnJxCtG1ZnlKaymECo7cNP3THcu7A3UvMoMASB18iWmSI+R4FMWOCn apgo1SnRgs0gw0OEbjipoXpugMVjMs7bVNW0Zmejkcb4LxIE9oebZBEhW+4tU/sg oD/pOT5ERxPCD31HTQi0hy9H8TJkgF16B44qF9ZNRmjDvcYBVahos2BP8m4d4Pph pP5q+tn9cWsDG53zfpKpMAibFeumeQ== =fjpe -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 15 10:08:10 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF6411200F8; Thu, 15 Aug 2019 10:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 EZ__6esrzbc6; Thu, 15 Aug 2019 10:07:55 -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 4E306120105; Thu, 15 Aug 2019 10:07:55 -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 x7FH7fKr016229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Aug 2019 13:07:45 -0400 Date: Thu, 15 Aug 2019 12:07:40 -0500 From: Benjamin Kaduk To: Michael Richardson Cc: anima@ietf.org, The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org Message-ID: <20190815170740.GW88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <22660.1565638213@localhost> <20190814145258.GX88236@kduck.mit.edu> <15695.1565888565@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <15695.1565888565@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 17:08:02 -0000 On Thu, Aug 15, 2019 at 01:02:45PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > >> There does not otherwise seem to be any risk from this compromise to > >> devices which are already deployed, or which are sitting locally in > >> boxes waiting for deployment (local spares). The issue is that > > > (That is, if the boxes are already in local storage at the time of > > first compromise) > > yes. If you have physical care of them, then nobody could have tried an > attack while the MASA signing key was compromised. I guess that makes the "under physical control of the owner" the relevant property, so emphasizing that in the text might be good. > >> The authors are unable to come up with an attack scenario where a > >> compromised voucher signature enables an attacker to introduce a > >> compromised pledge into an existing operator's network. This is the > >> case because the operator controls the communication between Registrar > >> and MASA, and there is no opportunity to introduce the fake voucher > >> through that conduit. > > > This seems predicated on the attacker having the MASA signing key but > > not persistent control of the (formerly?) legitimate MASA service, > > right? > > yes, that's right. Assume the key was generated in a deterministic way > (the way the SSH keys were), or brute-forced, or something like that. I was initiall confused about this, so it might be worth adding some text. (But then again, sometimes I'm easily confused...) > >> A key operational recommendation is for manufacturers to sign > >> nonceless, long-lived vouchers with a different key that they sign > >> short-lived vouchers. That key needs significantly better protection. > >> If both keys come from a common trust-anchor (the manufacturer's CA), > >> then a compromise of the manufacturer's CA would be a bigger problem. > > > (probably some wordsmithing options for "be a bigger problem") > > how about: > If both keys come from a common trust-anchor > (the manufacturer's CA), then a compromise of the > manufacturer's CA would compromise both keys. Such a > compromise of the manufacturer's CA likely compromises > all keys outlined in this section. WFM. Thanks, Ben From nobody Thu Aug 15 16:31:01 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729581200FA; Thu, 15 Aug 2019 16:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 PiPIoB2s5CaM; Thu, 15 Aug 2019 16:30:44 -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 C229F1200F1; Thu, 15 Aug 2019 16:30:43 -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 x7FNUV36002158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Aug 2019 19:30:33 -0400 Date: Thu, 15 Aug 2019 18:30:30 -0500 From: Benjamin Kaduk To: Michael Richardson Cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org Message-ID: <20190815233030.GF88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <23257.1565381837@localhost> <20190809225540.GV59807@kduck.mit.edu> <17084.1565831426@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <17084.1565831426@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 23:30:49 -0000 On Wed, Aug 14, 2019 at 09:10:26PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > >> Are you asking for a forward reference to 10.2? I will add this. > >> I think that section 10.2 is pretty clear about this. > >> I don't think it's mentioned just in passing. > > > It looks like the main coverage here is: > > > o the identity of the device being enrolled (down to the serial- > > number!). > > > and the discussion in the last three paragraphs or so. > > I do appreciate the importance of distinguishing between the high-end > > router and the human users (and we will have a long hard think about it > > again when BRSKI profiles for IoT use come through, I'm sure), so thank you > > for that. But I'm not sure that we clearly draw the connection to "the > > manufacturer knows the identity of the device being enrolled" to "and can > > guess where it is, and definitely knows who the owner is, and can > > potentially follow that over time if the device has to reenroll". Now, for > > the high-end router case there is literally nothing new here -- the vendor > > is assumed to already be doing inventory tracking of which customers have > > which routers! But I think it's important to make the connection from > > "knows identity" to "tracking", since this topic will come up for any use > > of BRSKI in other situations. > > we added the following to the end of the point list: > > Based upon the above information, the manufacturer is able to > track a specific device from pseudonymous domain identity to the > next pseudonymous domain identity. If there is sales-channel > integration, then the identities are not pseudonymous. > Thanks! > >> > 3. Secure auto-discovery of the pledge's MASA by the registrar (see > >> > Section 2.8). > >> > >> > I don't think this is an ironclad property, since the crypto chain is > >> > slightly limited and you are in effect trusting the pledge to hand you > >> > something that says "use this issuer" but without as much crypto to back > >> > that up as we might want. We have to know that the given manufacturer > >> > that signed the IDevID actually is associated with the device we're > >> > trying to bootstrap, which can probably be arranged but I don't remember > >> > being called out explicitly. > >> > >> There are two issues here. > >> > >> One is the question of what is the list of acceptable manufacturers (below). > >> The second part is whether a pledge could provide a fake IDevID to > >> the Registrar. The pledge is doing TLS ClientCertificate, so the TLS > >> has proven that the pledge has the private key corresponding to the > >> certificate presented. I conclude that an arbitrary IDevID can not be > >> provided by the Pledge; it has to be linked to SOME manufacturer. Some > > > Well, it has to be linked to some entity that signed the IDevID. That may > > or may not be a manufacturer, but the Registrar does have the capability to > > look at what signed the IDevID and apply a whitelist of known, verified, > > manufacturers. > > One either has a list of trusted manufacturers or one does not. > This can be done via a list of trust anchors for the IDevID signing entity, > or can be done via a list of trust anchors for the MASA URL. > > If not (in a residential use of BRSKI perhaps), then there has to be some > process by which a not previously known manufacturer can become trusted. > There are a great number of layer-8 or layer-9 solutions for this, > perhaps involving new industry CAs or attestations, or ... I think it is out > of scope. > (for instance RFC5280 section 4.2.2.1 could provide the right references, > but this section has not been well used as yet. Or we could extend the > MASA EST to include additional information) I agree that we don't need to talk about all the different ways by which a previously unknown manufacturer could become trusted. Mostly just the word "secure" caught me up. > >> The question then becomes how the Registrar comes to trust/verify the > >> pledge's IDevID. We had a long discussion about this during the directorate > >> reviews and going back to Feb. 2018. I thought that we resolved this. > >> Issues > >> https://github.com/anima-wg/anima-bootstrap/issues/120 > >> https://github.com/anima-wg/anima-bootstrap/issues/43 > >> https://github.com/anima-wg/anima-bootstrap/issues/46 > >> A thread starts here: > >> https://mailarchive.ietf.org/arch/msg/anima/p7pUw1HKq6Ot0gV8JPeRWhwvQTs > >> > >> Some changes that we made for this: > >> https://github.com/anima-wg/anima-bootstrap/commit/e5ffec4cc703626012d62c0b3138d851b61a2f54 > > > Maybe, "Configuration or distribution of these trust anchor databases is > > out-of-scope of this specification. Note that the trust anchors > > in/excluded from the database will affect which manufacturers' devices are > > acceptable to the registrar as pledges, and can also be used to limit the > > set of MASAs that are trusted for enrollment."? > > we have added this to section 5.1. > > >> > Section 7.2.13 of [IDevID] discusses keyUsage and extendedKeyUsage > >> > extensions in the IDevID certificate. Any restrictions included > >> > >> > I only got my hands on the 2018 rev of [IDevID], but that one does not > >> > actually talk about extendedKeyUsage. > >> > >> Max was the editor of the 2009 edition, and we pointed at it. > >> I don't seem to be able to get the 2018 edition. > > > I think we could probably reword this to just acknowledge that [IDevID] > > acknowledges that adding restrictions in the certificate can limit > > applicability, and since these are long-lived, usually you don't want to > > throw random extra restrictions into them. > > We have determined that section 8.10.3 of the -2018 has the same text. > Neither Max nor I have the official -2018 version, so we are writing: > > Section 7.2.13 (2009 edition) and section 8.10.3 (2018 edition) of > discusses keyUsage and > > Our recommendation continues to be that no EKU be added (consistent > with 1AR, if you have to, then it has to include digitalSignature). Definitely! > >> > Section 2.3.1 > >> > >> > In the context of BRSKI, pledges are uniquely identified by a > >> > "serial-number". This serial-number is used both in the "serial- > >> > number" field of voucher or voucher-requests (see Section 3) and in > >> > local policies on registrar or MASA (see Section 5). > >> > >> > (editorial) if the IDevID is supposed to be a unique identifier, why do > >> > we need another one? > >> > >> The pledge extracts it from it's IDevID. > >> The registrar extracts it again from the IDevID that it sees. > >> It's seems hard to construct an attack where the provisional TLS connection > >> is MITM (replacing the certificates). So I'm gonna claim belt-and-suspenders > >> here.... the cross-check seems useful, but maybe in the end, it's a left-over > >> From when voucher-requests could be unsigned. > > > I don't actually have a big complaint, here (and am definitely not asking > > to change the wire bits!). Perhaps we could go easy on "unique" or maybe > > just acknowledge that there's supposed to be a 1:1 map between serial > > number and IDevID. (Or not, of course.) > > I went with 1:1 text. > > >> > >> > In Figure 3, I had to think a bit to figure out whether the text that > >> > did not fit mid-arrow was supposed to apply to the arrow above or below > >> > the text (e.g., "optional: mDNS query RFC6763/RFC6762"). > >> > >> Yes... we did struggle to fit it into a single page. > >> It applies to both the arrow above and below, and there are M_FLOOD > >> and mDNS possible here. Do you have suggestions on making it clearer. > > > Hmm, maybe give each one a unique symbol (+*&$#?) and put that in the > > middle of the relevant arrows as well as in the text? > > I'm not sure what you mean. > https://github.com/anima-wg/anima-bootstrap/edit/master/time-sequence-diagram.txt Proof of concept in https://github.com/anima-wg/anima-bootstrap/pull/135 . Feel free to say it doesn't make sense :) > >> In the ANI case, we are likely doing this over wired links (long-haul fiber > >> or internal to DC), but in the anticipated TEAP-BRSKI use case or 6tisch > >> use, this would be WIFI / 802.15.4. > >> > >> What is needed is a three-party zero-knowledge proof, but how would the > >> Registrar identify the third party (the MASA)? > >> > >> You are right to worry, but I don't know what to do about this. > > > I don't, either. Well, I do: "document it and move on", but that still > > leaves a bad taste in my mouth. > > new section added: > > 10.2. What BRSKI-EST reveals to the registrar > > During the provisional phase of the BRSKI-EST connection between the > Pledge and the Registrar, each party reveals it's certificates to > each other. For the Pledge, this includes the serialNumber > attribute, the MASA URL, and the identity that signed the IDevID > certificate. > > TLS 1.2 reveals the certificate identities to on-path observers, > including the Join Proxy. > > TLS 1.3 reveals the certificate identities only to the end parties, > but as the connection if provisional, an on-path attacker will see > the certificates. This includes not just malicious attackers, but > also Registrars which are visible to the Pledge, but which are not > part of the the intended domain. Thanks. > >> > Section 2.5.1 > >> > >> > The pledge is the device that is attempting to join. Until the > >> > pledge completes the enrollment process, it has link-local network > >> > connectivity only to the proxy. > >> > >> > nit(?): I think there is a subtle difference in meaning between "only > >> > has link-local network connectivity to the proxy" and this text, and I'm > >> > not sure which is intended. > >> > >> I'm confused. > > > The current text asserts that it has link-local connectivity, and further > > that the extent of this connectivity is limited to the proxy. My > > alternative asserts that it can only talk to the proxy over this > > link-local connectivity, but leaves open the possibility of other > > avenues of communication (e.g., a WWAN card). > > I guess by WWAN card, you mean some kind of LTE or 5G connection? > Or do you mean 802.11/802.15.4? The distinction matters, because LTE > cards have SIM cards, and therefore are not zero-touch. Um. I think I meant LTE, along the lines of how I can buy a car these days that will "phone home" to the dealer when I need to go in for service. > >> > Section 2.6.2 > >> > >> > [RFC5280] explains that long lived pledge certificates "SHOULD be > >> > assigned the GeneralizedTime value of 99991231235959Z". Registrars > >> > >> > This misses the important "for the notAfter field" part. > > > (The above and below were separate comments; not sure if that came > > through.) > > Oh, I get it. Added "for the notAfter field" > > >> > Why is 3 years the relevant cutoff here? > >> > >> That's a good question. *** MAX *** > > okay, changed text. > > [RFC5280] explains that long lived pledge certificates "SHOULD be > - assigned the GeneralizedTime value of 99991231235959Z". Registrars > - MUST support such lifetimes and SHOULD support ignoring pledge > - lifetimes if they did not follow the RFC5280 recommendations. > + assigned the GeneralizedTime value of 99991231235959Z" for the > + notAfter field. > > - For example, IDevID may have incorrect lifetime of N <= 3 years, > - rendering replacement pledges from storage useless after N years > - unless registrars support ignoring such a lifetime. > + Some deployed IDevID management systems are not compliant with the > + 802.1AR requirement for infinite lifetimes, and put in typical <= 3 > + year certificate lifetimes. Registrars SHOULD be configurable on a > + per-manufacturer basis to ignore pledge lifetimes when they did not > + follow the RFC5280 recommendations. Ah, that is much clearer to me; thanks. > >> > In order to support these scenarios, the pledge MAY contact a well > >> > known URI of a cloud registrar if a local registrar cannot be > >> > discovered or if the pledge's target use cases do not include a local > >> > registrar. > >> > ben> I don't see the connection between "configure itself to become the > ben> local registrar" and "contact a well-known URI of a cloud registrar". > >> > >> In a completely Greenfield situation, where there is no local infrastructure > >> at all, given an appropriately magic "Intent" (remember where this WG > >> started...), then a cloud registrar could inform a device that it is > >> to become the Registrar. How this would work depends upon the details > >> of the magic unicorn Intent (see failed SUPA WG). > > > Ah. So the cloud registrar is an extra-featureful registrar that can do > > more than just register things. I get it now, but am not sure how to best > > word it. > > The point of that section is to rule (magic unicorns) out of scope. > It doesn't really matter if we describe the magic correctly, does it? :-) I don't think we have an IETF spec for unicorns, no. Maybe there's an ISO standard unicorn? > >> > If the pledge uses a well known URI for contacting a cloud registrar > >> > an Implicit Trust Anchor database (see [RFC7030]) MUST be used to > >> > authenticate service as described in [RFC6125]. This is consistent > >> > ben> Would this be more likely to be installed by the manufacturer or > ben> device owner? > >> > >> Manufacturer, as it's implicit. That's how EST works today. > > > So you think "implicit" is enough and adding something like "burned-in" or > > "manufacturer-assigned" is overkill? > > We are trying to use the EST terminology here.... how about: > > - an Implicit Trust Anchor database (see ) MUST > + a manufacturer-assigned Implicit Trust Anchor database (see ) MUST That works for me. And, honestly, leaving it as-is would be okay. > >> There is a TLS connection between them. Yes, it could go anywhere. > >> The proxy was link-local, and the proxy pointed the connection at the > >> Registrar. I guess it would be useful if the proxy was stateful, and > >> contributed another cryptographic layer for non-ACP cases. > >> > >> In the ACP case, the Registrar knows it can trust the proxy because it's on > >> the ACP, and is connecting from an ULA address that is part of the ACP. > >> > >> Yes, the Registrar could be anywhere, but the proxy makes it appear > >> to be on the local link. > >> > >> I'm not sure what else I can add to the text. > > > "There is a TLS connection between a and b" says almost nothing without > > some additional context -- there are millions of machines I can make a TLS > > connection to from here. I assume that the unstated context here is that > > the pledge is expected to be in a limited-connectivity environment, so the > > fact that the network allowed the connection through to the registrar > > conveys meaning. But I don't remember anything in this document that > > actually validates that the pledge really is in a limited network > > environment. Could some rogue node ("attacker") be trying to talk to a > > proxy or registrar directly, from somewhere else in the network? How would > > we tell? > > The pledge has made a connection over a Link-Local IPv6 connection. > The Registrar has a connection from a ULA numbered Join Proxy across > the ACP. That's not a connection across the Internet. It's true > that neither end can validate what the other end sees. > > The Join Proxy could be doing something else: it could punt the connection > elsewhere, or it could channel (in the séance sense) a pledge from some > other place. If that were occuring, there would indeed be some problem. > > Other proposed uses of BRSKI (TEAP-BRSKI) would connect using EAP > over 1x+radius/diameter. > > Would some addition to the ACP applicability stating the above > be useful? Oh sure, the link-local IPv6 of the proto-ACP would be a great way to show locality. Please do add some text regarding the ACP applicability. > >> But, that's why we have SHOULD, and the SHOULD (vs MUST) part was really to > >> allow for some fancy HTTP/3 we know nothing about :-) > > > :) > > > Do we still want to say "HTTP 1.1 persistent connections" vs. "HTTP > > persistent connections", though? > > I'll remove the 1.1. > At the time, we didn't know what HTTP/2 would have. > I think we asked, and were told that HTTP/2 always had persistent > connections, so there was nothing really to say. I see this as a > statement to some product manager that they really do need to > upgrade their 1998 era HTTP library with something newer. > > >> I have an open request to *** MAX *** to clarify this part. > >> > >> > o The registrar performs log verifications in addition to local > >> > authorization checks before accepting optional pledge device > >> > enrollment requests. > >> > >> > Maybe give us a section reference to what the "log validations" are? > >> > >> We decided that we did not have enough experience to write normative > >> language > >> here. (It's not an Internet Standard) > > > It doesn't have to be normative, but some discussion of things that might > > come into consideration during that process could still be useful. > > I really think that 5.8.3 says enough. It probably does (and we should feel free to forward-reference it from here). > I have 39 emails in my to-read relating to other DISCUSS. Oh my; keep up the good work! But do take breaks periodically... Thanks, Ben From nobody Thu Aug 15 16:58:17 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 124DB1200F3; Thu, 15 Aug 2019 16:58:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: anima@ietf.org Message-ID: <156591349500.15836.12517100709379177140@ietfa.amsl.com> Date: Thu, 15 Aug 2019 16:58:15 -0700 Archived-At: Subject: [Anima] I-D Action: draft-ietf-anima-bootstrapping-keyinfra-26.txt X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Aug 2019 23:58:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Autonomic Networking Integrated Model and Approach WG of the IETF. Title : Bootstrapping Remote Secure Key Infrastructures (BRSKI) Authors : Max Pritikin Michael C. Richardson Toerless Eckert Michael H. Behringer Kent Watsen Filename : draft-ietf-anima-bootstrapping-keyinfra-26.txt Pages : 110 Date : 2019-08-15 Abstract: This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Remote Secure Key Infrastructure (BRSKI) is created using manufacturer installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping to is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-26 https://datatracker.ietf.org/doc/html/draft-ietf-anima-bootstrapping-keyinfra-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-bootstrapping-keyinfra-26 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 Aug 15 17:07:04 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A4D1200F3; Thu, 15 Aug 2019 17:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Th-njZITpVGS; Thu, 15 Aug 2019 17:06:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35FC71200E9; Thu, 15 Aug 2019 17:06:57 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 17EBA3818C; Thu, 15 Aug 2019 20:06:07 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id B06D5788; Thu, 15 Aug 2019 20:06:56 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk , Ignas Bagdonas CC: anima@ietf.org, The IESG , Christian Huitema , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org In-Reply-To: <20190815170740.GW88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <22660.1565638213@localhost> <20190814145258.GX88236@kduck.mit.edu> <15695.1565888565@localhost> <20190815170740.GW88236@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] {FINAL} Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 00:07:01 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, I have pushed -26 to the datatracker. I believe that this addresses all IESG comments received, as well as the=20 comments from Christian's second review. In particular, I added a paragraph to the intro as he suggested, as well as adding section 7.4.3, which is now referenced by section 10.6 ("meddling"). As previously indicated, when I fixed the wrap issue in the examples between =2D23 and -24, this resulted in a very unreadably wide diff. I posted -23 = as having only that fix, so compare -26 to -24 if you want to see everything since your review. Here is a link to help: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-anima-bootstrapping-keyin= fra-23&url2=3Ddraft-ietf-anima-bootstrapping-keyinfra-26 The new text is pending proof-reading by myself and others, but as you may know, it is impossible to catch small errors in this text. Will Randy be happy? I hope so :-) This is has been a very long effort for me and my co-authors, about 75 hours of effort, occupying most of my brain for a month. If substantive are still needed, they won't occur until mid-September. There is still perhaps the somewhat "minor" issue of whether we should have= a registry created for the /.well-known/est. It feels like overkill to me. I'm not sure if my instructions clearly say to add "see also " to the relat= ed information. I reviewed some of the documents referenced under "related inf= ormation", and I did not see any instructions in them. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1V86AACgkQgItw+93Q 3WX3qwgAutOv55HwZzK7PESdKyO05cSEFq5JNAy7+4CvPllEacJxbuT6oGoJM3EE 8Xx4GSKecF61+h6d/dlC7xXvDcPkKdPWYxSpu5naynV6x95+w1pV0Khe/t+SXbv2 GEhPwn340cqlGg0fNJH8jo5XWhl3kklmjPCLnKlncehUAPAaqr8zdmf4eCqNPITw qIN+Ma3mW5Wlpu9xT9Cxfz+wq/5EM+dj7M9XA+s7VOK6jeHnDzx//YUYvuK99HEv 2uO5bCaLfIjFZKAkEQSN+NqNR/8ci+mL+olCRdWi/r8xbN8nOuu/665G8GQJ9l1O pt18qzuyK22FC8QXGl6N9M+paX2ypQ== =JxOU -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Aug 15 17:16:21 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F1E1200F9; Thu, 15 Aug 2019 17:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 T3OVg9LT8Pfw; Thu, 15 Aug 2019 17:16:17 -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 AA4381200F3; Thu, 15 Aug 2019 17:16:17 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C966A3818C; Thu, 15 Aug 2019 20:15:26 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6DE7D788; Thu, 15 Aug 2019 20:16:16 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <20190815233030.GF88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <23257.1565381837@localhost> <20190809225540.GV59807@kduck.mit.edu> <17084.1565831426@localhost> <20190815233030.GF88236@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 00:16:20 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Benjamin Kaduk wrote: >> I guess by WWAN card, you mean some kind of LTE or 5G connection? Or >> do you mean 802.11/802.15.4? The distinction matters, because LTE >> cards have SIM cards, and therefore are not zero-touch. > Um. I think I meant LTE, along the lines of how I can buy a car these > days that will "phone home" to the dealer when I need to go in for > service. And which is never actually your car, nor has it any actual credentials that you control :-) It was onboarded at the factory. >> Would some addition to the ACP applicability stating the above be >> useful? > Oh sure, the link-local IPv6 of the proto-ACP would be a great way to > show locality. Please do add some text regarding the ACP > applicability. Added after -26. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1V9dAACgkQgItw+93Q 3WXqdQf/ftsVp+3LYtX0xzW1Hmr5IcghmNBC0n6kXR2seLtdzGu/RQyH+hV19zSF 5KxGzGxH11fX7ge9LUMb1P6YZSLhvh4gHGKP/Gp4fIex6qo2sjta/IzKnrbdUvkd Djm10rUt7t2vKREcAChmV8dUKRkv4D3gA9Um1t/SMVJ8K4gxESSx2FJT4+oAixDL FigRYheHV9q/e4UWrJsPjNR2pJOdeHq8X8xrvxAfc2EVtX80dfH+xegh8F39JvqX 2XPeriD7pPL2tON9aTfr2l0NgEnhLVoG6oFXPFTs2aQwZZztpiaaAvvDh5SU64rx a+wyl48suvQcZAstnYr9wiZ2lS5nbw== =BXck -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Aug 16 10:40:18 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529061200B8; Fri, 16 Aug 2019 10:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 QkBYrfn-_5Dn; Fri, 16 Aug 2019 10:40:07 -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 51A821200B3; Fri, 16 Aug 2019 10:40:07 -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 x7GHdvlA004313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Aug 2019 13:40:00 -0400 Date: Fri, 16 Aug 2019 12:39:57 -0500 From: Benjamin Kaduk To: Michael Richardson Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG , anima@ietf.org Message-ID: <20190816173957.GL88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <25503.1565496367@localhost> <20190813172532.GM88236@kduck.mit.edu> <6154.1565885842@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6154.1565885842@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 17:40:09 -0000 On Thu, Aug 15, 2019 at 12:17:22PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > doc> The MASA and the registrars SHOULD be prepared to support TLS client > doc> certificate authentication and/or HTTP Basic or Digest > doc> authentication as described in [RFC7030] for EST clients. This > doc> connection MAY also have no client authentication at all (Section > doc> 7.4) > > >> > I don't see discussion of skipping client authentication in Section > >> 7.4. > It would be great to have some, there! > > >> It's buried in point 2. > > > Oh, the "not verifying ownership" part? I somehow was interpreting > > that as "we still require client authentication, but don't have a fancy > > database mapping owner to hardware, so any authenticated registrar can > > get a voucher for any device". > > There are multiple models on how to operate a MASA. > We think that which one is right depends a lot on the value of the device > (in the ACP space, $100K routers vs $100 CPE devices), and also at the degree > of sales channel integration. > There is value in authenticating the Registrar, even if one does not know > which device has been deployed. In particular, this model supports the <4h > SLA on service repair that most vendors have, and which they support by > stocking spares in the local city, but not for a specific customer. Understood. To be clear, this was only ever intended to be an editorial question (to be more explicit about not using client authentication), so ... use your editorial discretion. -Ben From nobody Fri Aug 16 15:33:32 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54F41200C4; Fri, 16 Aug 2019 15:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 xTI4kZBVnuVr; Fri, 16 Aug 2019 15:33:28 -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 5528C120018; Fri, 16 Aug 2019 15:33:28 -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 x7GMXGsI018924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Aug 2019 18:33:19 -0400 Date: Fri, 16 Aug 2019 17:33:16 -0500 From: Benjamin Kaduk To: Michael Richardson Cc: The IESG , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org Message-ID: <20190816223315.GP88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <17440.1565636744@localhost> <20190814142737.GV88236@kduck.mit.edu> <14902.1565888325@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14902.1565888325@localhost> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Aug 2019 22:33:31 -0000 On Thu, Aug 15, 2019 at 12:58:45PM -0400, Michael Richardson wrote: > > Benjamin Kaduk wrote: > >> + directly. This is because BRSKI pledges MUST use the CSR Attributes > > > (This may not need to be a 2119 MUST since we cite 7030.) > > It turns out, in pracice, that many EST clients do not use the CSR > Attributes, so I need this line as a hammer. Fair enough. > >> > "intended" implies that the EST server has some knowledge of what > >> the > pledge is expected to be doing in the network, right? > >> > >> Yes. The ACP document is quite specific about the (rfc822Name) > >> attributes to assign. Certainly the attributes could include stuff > >> like "ve608.core1.tor1.example.net" if the Registrar knew how this > >> device was to be used, but more likely that would be set up > >> afterwards. > > > Hmm, maybe later when we say "the local infrastructure (EST server) > > informs the pledge of the proper fields to include in the generated > > CSR" we could reiterate that the EST server has local configuration > > information to inform this messaging, though it's probably not > > necessary. > > I've added the (). > > + fields to include in the generated CSR (such as rfc822Name). > > doc> To alleviate these operational difficulties, the pledge MUST request > doc> the EST "CSR Attributes" from the EST server and the EST server > doc> needs to be able to reply with the attributes necessary for use of > doc> the certificate in its intended protocols/services. This approach > doc> allows for minimal CA integrations and instead the local > doc> infrastructure (EST server) informs the pledge of the proper fields > doc> to include in the generated CSR. This approach is beneficial to > doc> automated boostrapping in the widest number of environments. > >> > >> > This is convenient, but has some security considerations in that it > >> > implies that the validation policy on the CA is somewhat lax, since > >> the > EST server is expected to be doing most of the policy controls. > >> Thus, > a compromised pledge/device could send a CSR with unauthorized > >> fields > and it is likely to be signed, allowing for some level of > >> privilege > escalation. When the registrar acts as a proxy to the CA > >> as well as > its EST role, as described later, this risk is > >> diminished. > >> > >> I don't really understand. EST servers are Registration Authorities, > >> and they have some kind of priviledged access to the CA, and are > >> mandated to check the CSR. I expected to find a statement to this > >> effect in RFC7030, in section 4.2.1, but I don't see any particularly > >> strong language. This seems like a quality of implementation issue in > >> the Registrar. > > > The high-level intended workflow described here is roughly "(1) pledge > > asks registrar for config; (2) pledge puts that config in a CSR, signs > > the CSR, and sends the CSR to registrar; (3) registrar passes CSR to CA > > using registrar's implicit authority. We don't describe any crypto to > > check that (2) happens as intended, as opposed to the pledge > > dishonestly claiming "oh, and I'm a CA" or "I can provide all ACP > > services, even privileged ones", so that has to be done by policy in > > the registrar, as you note. I'm wary of suggesting the workflow that > > relies on the registrar's implicit authority at the CA without also > > noting the registrar's policy enforcement obligations. Though it's > > possible this is covered elsewhere and doesn't need to be duplicated > > here. > > I think it goes back to the RA and more specifically, the CA, being boss of > what going into a certificate. To the point where it generally seems really > hard to deploy new extensions in the public WebPKI. > > It does say: > > The registrar MUST also confirm that the resulting CSR is formatted as > indicated before forwarding the request to a CA. If the registrar is > communicating with the CA using a protocol such as full CMC, which > provides mechanisms to override the CSR attributes, then these > mechanisms MAY be used even if the client ignores CSR Attribute > guidance. Hmm, I guess I must have missed that or skimmed over it too quickly. > >> > Section 7 > >> > >> > If this is non-normative and will need to be fleshed out in a > >> separate > document, would an Appendix be more appropriate? > >> > >> Section 9 and 10 refer back to this section in a normative fashion. > > > Er, wouldn't that make this section no longer non-normative? (Not that > > I could find the references you're talking about, so a clue bat is > > welcome.) > > It's of the form, "if you wish to do X, then you MUST do Y" > (but, X is not a MUST). That specific construction would seem like an "optional feature" per https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/ ... > section 9: > In recognition of this, some mechanisms are presented in > Section 7.2. The manufacturer MUST provide at least one of the one- > touch mechanisms described that permit enrollment to be proceed > without availability of any manufacturer server (such as the MASA). ... but this is a somewhat different construction. In isolation, it looks more like "MUST do at least one of X, Y, Z" without condition on "wish to do W", and if X, Y, and Z are all in the same place, that place seems normative to me. (I will confess I've rather lost track of exactly why we're debating if this is normative or not; I guess it's just the disclaimer in Section 7 about "considered non-normative in the generality of the protocol".) > >> > I think this is maybe more of a "does not enforce" than "does not > > >> know", since the domainID ends up in the audit logs that the MASA > > >> holds. > >> > >> Yes, but the domainID does not directly identify the Registrar by > >> name. Assuming a database breach, what does the MASA know that it can > >> reveal. > > > can reveal or be correlated with other sources of information. The > > domainID is derived from the public part of a certificate, which could > > well be widely disseminated. An attacker that compromises the MASA and > > retains a presence can watch requests come in and backsolve from > > domainID to certificate directly. > > Right, so that's 11.4.3, where the attacker controls the web server. The "watch requests come in" is, yes. But if we don't constrain the visibility/use of the certificates in question, they could be out "in the wild" and thus correlatable even with just a database dump/snapshot. > At which point, they don't need to compromise the database, I think, as they > can just access it. I think of a database dump as being offline: I get > access to your backups, or I find an SQL injection attack that exfiltrates > data, but does not give me control. > > >> > A nonceless voucher can still include an expiration time ... it is > >> just > in practice possible for it to never expire, if the target > >> pledge does > not have an accurate clock. > >> > >> Yes, that's correct. How many devices with RTCs survive 10 years in a > >> warehouse with no power? :-) > > > The ones with a radioisotope thermoelectric generator? ;) > > So RTCs with RTGs. > Apparently not much plutonium is left for future missions. > > >> fixed. > >> > >> > Section 9 > >> > doc> The autonomic control plane that this document provides bootstrap > doc> for is typically a medium to large Internet Service Provider > doc> organization, or an equivalent Enterprise that has signficant > doc> layer-3 router connectivity. (A network consistenting of primarily > doc> layer-2 > >> > >> > nit: "is used in" -- the ACP is not the entire organization! > >> > >> The text doesn't have "is used in" > > > (Right, I was saying that you should add it. But the reworking fixes > > the nit, so this is all good.) > > got it. > > doc> There are a number of design choices that mitigate this risk. The > doc> domain can maintain some privacy since it has not necessarily been > doc> authenticated and is not authoritatively bound to the supply chain. > >> > >> > Is this really "privacy" or just "semi-plausible deniability"? > >> > >> It's a good question. A domain could use a new certificate for each > >> device, could connect via some onion router. Is that privacy, or > >> "semi-plausible deniability"? > > > It might depend on the details of the certificates used, what CA issued > > them (and its policies regarding accuracy and level of detail in > > certificates issued therefrom), and whether the certifciates are > > used/exposed for any other purposes. So, I don't insist on any > > specific language, and was just sharing my thoughts about how it is > > possible to think about this, in case it sparked any insight. > > Agreed. > I think that it's hard problem. > > doc> The above situation is to be distinguished from a residential/ > doc> individual person who registers a device from a manufacturer: that > doc> an enterprise/ISP purchases routing products is hardly worth > doc> mentioning. Deviations would, however, be notable. > >> > >> > Deviations in what sense? > >> > >> After buying only Cisco equipment (like ASR 9000) [observed by number > >> of MASA connections after each POP turn up], ISP example.net suddendly > >> has started communicating with Juniper's MASA (for MX40s..). > > > So like "deviations from a historical trend" or "deviations from an > > established baseline"? > > added that text. > > >> > Section 10.3 > >> > doc> 4. There is a fourth case, if the manufacturer is providing > doc> protection against stolen devices. The manufacturer then has a > doc> responsability to protect the legitimate owner against fraudulent > doc> claims that the the equipment was stolen. Such a claim would cause > doc> the manufacturer to refuse to issue a new voucher. Should the > doc> device go through a deep factory reset (for instance, replacement of > doc> a damaged main board component, the device would not bootstrap. > >> > >> > I'm not sure I understand this scenario -- is it talking about where > >> a > third party makes a false theft report in the hopes that the real > >> owner > will have to do a deep reset and then have the device fail to > >> bootstrap > because of the reported theft? > >> > >> Yes. > > > I think having "In the absence of such manufacturer protection, such a > > claim would cause [...]" would have helped me get there. > > added. > > doc> registrar. This is mandated anyway because of the operational > doc> benefits of an informed administrator in cases where the failure is > doc> indicative of a problem. The registrar is RECOMMENDED to verify > doc> MASA > >> > >> > I'd also expect some comment about the limited value of the > >> additional > information to an attacker in the context where the > >> attacker already > would know [other information]. > >> > >> I'm not sure what other "other information" is yet, so I don't know > >> how to fill that in. > > > IIUC, this text is predicated on a "possibly malicious registrar" that > > a pledge tries to register using/through but fails. So that registrar > > is already in a position where the pledge would try to use it -- in the > > ACP case, that probably means fairly physically proximate, and maybe > > implies a link-local connection. > > Agreed. In the ACP case, imagine an ISP border router on which there are a number > of links; some of which are internal (legitimate Join Proxy), and some of > which are external links to another ISP's border router (Q). The Join Proxy > on Q really doesn't know if the purpose of that link has changed from > external to internal. That's exactly the case of a non-malicious mistake > in finding the right network. > > > In the non-ACP case, maybe it also > > implies proximity? I don't know if we can get physical vs. network > > proximity implied by a pledge trying to use a registrar, but maybe > > sometimes. My implied question is basically "what else would an > > attacker have to do to get a pledge to try to use it as a registrar, > > and what does the attacker already have access to by the time it gets > > that far?" So we can set the information learned from voucher parsing > > status reports in the context of what else the attacker would already > > know. But I don't have the best picture on the deployment scenarios > > here, so I can't answer the question myself :) > > We left the warning there so that the people writing code would think about > this tuscle. My opinion that security paranoia has often gotten in the way of > building debuggable security systems that actually work. > > doc> this might be an issue during disaster recovery. This risk can be > doc> mitigated by Registrars that request and maintain long term copies > doc> of "nonceless" vouchers. In that way they are guaranteed to be able > doc> to bootstrap their devices. > >> > >> > This, of course, comes with a different risk of what is something > >> like > a long-term credential existing that needs to be protected and > >> stored. > >> > >> I partially agree. Long-term nonceless vouchers still pin a specific > >> domainID. So they need to available, but they don't need to be > >> private. > > > It's not entirely clear to me that it's okay to make them totally > > public (but maybe I am missing something). That is, in that once the > > voucher is public, anyone who can get next to the device can > > re-bootstrap it using that voucher, which possibly gets it into a > > configuration that's not usable in its current location, and (less > > likely) maybe it's hard for the real owner to get the correct > > configuration back (if the original MASA is gone or whatever). So the > > voucher is not something I'd want to just put on a public web site. > > But I guess maybe you don't have to protect it to the same extent that > > you do your crypto keys. > > Not anyone can use the nonceless voucher to bootstrap a device. > If it did, then that would be a bearer voucher ("cash") > It still pins a specific domain CA ("pay $X to Mr. Y"). > It's a public document in the same sense that a public key is. IIUC I don'to have to prove possession of the private key corresponding to a certificate that chains to that domain's CA in order to get the pledge to accept the voucher. That is, even if I can't get the device to work for me, I can still keep someone else from using it (e.g., reusing a nonceless voucher for the original owner after re-sale). > >> > This gets a bit more complicated to reason about when we assume that > >> a > pledge will have multiple voucher requests out in parallel, > >> instead of > doing them in sequence and timing out (so that there is > >> literally only > one valid nonce at a given time)... > >> > >> Agreed. But, we think that doing things serially has too much > >> potential to run into head-of-queue challenges; the risk is that if > >> devices don't onboard relatively quickly, then BRSKI will get turned > >> off, not used, or the vendor might provide some "backdoor" > > > That's a fair concern, but in and of itself is not an excuse to skip > > reasoning through the risks of the parallel workflow. How much effort > > has already been spent doing that reasoning through? For example, one > > might want to require that the pledge track which nonce belongs to the > > voucher request submitted through which candidate registrar, but I > > didn't work through whether that actually will defend against any > > attack scenarios. > > Each attempt needs to use a distinct nonce. That's true, but not quite what I was looking for. With two outstanding nonces, now I have to keep track of which nonce went where and use the right nonce to attempt to verify a response. I also have to consider the case where I send out two requests and get back two valid responses. Presumably I take whichever one shows up first and validates, but are there risks associated with rejecting the other one or not knowing whether it was valid? If I use predictable nonces, could that allow another party to affect the outcome of the "race" between which response shows up first? -Ben > I thought we said that. > We say that in section 11, but I've added it to 4.1. > > >> I have dug around cabforum.org and root-servers.org for some > >> references on what a "well-run secure CA" should be > >> doing... surprisingly I didn't find an RFC, or one for DNSSEC root > >> operation. Did I miss them? I thought that there was one. I'm > >> writing some text, and I'll finish this email here, and post the > >> resulting text. > > > I think I had always assumed this was part of the CA/B forum baseline > > requirements (https://cabforum.org/baseline-requirements-documents/) > > but never actually looked. :-/ We could ask around if it's important > > (but I don't think there's an RFC). > > I will save it for an operational document. > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > From nobody Sun Aug 18 12:55:45 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B991201E3; Sun, 18 Aug 2019 12:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 sdVMWfAPiVHd; Sun, 18 Aug 2019 12:55:41 -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 755601200B9; Sun, 18 Aug 2019 12:55:41 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 619E5380BE; Sun, 18 Aug 2019 15:54:46 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 56310B2D; Sun, 18 Aug 2019 15:55:40 -0400 (EDT) From: Michael Richardson To: "Alexey Melnikov" cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, "The IESG" , anima@ietf.org In-Reply-To: <6d0cfaaf-2d1d-4120-85a2-2f613d0f696c@www.fastmail.com> References: <156285123896.32459.15810474411321920381.idtracker@ietfa.amsl.com> <27800.1563297174@localhost> <9325.1563492610@localhost> <6d0cfaaf-2d1d-4120-85a2-2f613d0f696c@www.fastmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Alexey Melnikov's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 19:55:44 -0000 --=-=-= Content-Type: text/plain Alexey Melnikov wrote: >> Alexey Melnikov wrote: >> >> > o In the language of [RFC6125] this provides for a SERIALNUM-ID > >> >> category of identifier that can be included in a certificate and > >> >> therefore that can also be used for matching purposes. The > >> >> SERIALNUM-ID whitelist is collated according to manufacturer trust > >> >> anchor since serial numbers are not globally unique. >> >> > This is actually not helping. I was looking for something like: >> >> > DNS-ID = a subjectAltName entry of type dNSName >> >> > Basically I was asking for a definition of SERIALNUM-ID somewhere. >> >> It's a (subject)DN of serial number=123456, not a subjectAltName. >> (not the CertificateSerialNumber) > In this case, you need to use CN-ID as the base for the definition. The > important part there is that the RDN can't be repeated multiple times > in a DN. If it does, that would make the whole DN not suitable for use > a la RFC 6125. To recap, we have changed the text to avoid multiple references to 6125. We use a reference to LDAP (rfc4519), because that's where the fields get a clear statment as to how to present them. We don't need to do RFC6125 matching on certificates to URLs, etc. for the TLS Client Certificates, so rfc6125 does not really help anyone, so the discussion about CN-ID seems to just distract. 2.3.1. Identification of the Pledge | In the context of BRSKI, pledges have a 1:1 relationship with a "serial-number". This serial-number is used both in the "serial- number" field of voucher or voucher-requests (see Section 3) and in local policies on registrar or MASA (see Section 5). | The serialNumber fields is defined in [RFC5280], and is a SHOULD | field in [IDevID]. IDevID certificates for use with this protocol | MUST include the "serialNumber" attribute with the device's unique | serial number (from [IDevID] section 7.2.8, and [RFC5280] section | 4.1.2.4's list of standard attributes). | The serialNumber field is used as follows by the pledge to build the | "serial-number" that is placed in the voucher-request. In order to | build it, the fields need to be converted into a serial-number of | "type string". | An example of a printable form of the "serialNumber" field is | provided in [RFC4519] section 2.31 ("WI-3005"). That section further | provides equality and syntax attributes. | Due to the reality of existing device identity provisioning | processes, some manufacturers have stored serial-numbers in other | fields. Registrar's SHOULD be configurable, on a per-manufacturer | basis, to look for serial-number equivalents in other fields. As explained in Section 5.5 the Registrar MUST extract the serial- number again itself from the pledge's TLS certificate. It can consult the serial-number in the pledge-request if there are any | possible confusion about the source of the serial-number. ... section 5 now jus says: The extensions for a registrar (equivalent to EST server) are: o Client authentication is automated using Initial Device Identity (IDevID) as per the EST certificate based client authentication. The subject field's DN encoding MUST include the "serialNumber" | attribute with the device's unique serial number as explained in | Section 2.3.1 -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1ZrTsACgkQgItw+93Q 3WWilgf9E/kpV0WAS3stGlhP3s8yB0ZcMKSJMmc1acvUQa/yhezQFhUkCnlYmqFQ /C3OWEYOFGvdUrg1WNoO0u8AJpePt/JrHUoFhGJYT3+2inMHvRR0+1lk+06t9WYD DL1J/QN9pLo7oykTRLs6Dfk6QV7krxg2M0NMdMjTlBm5IeIETpBQGk46F61Dm3pK H748CN/0rNXVSYpSktg3KSsNLU3FMTR/p08B3kYAZ0uvFsiqBTV4cAZmT0M5zew/ Z6OQoqQH9jejOQROWOdx89Mv4xHaoqi6cJ4O8lgFkRQzJif3+LmgpZZB8g95eT5m Hdr6/01v/Ki1PzTzVqHl2X4vRVcBIg== =1e7H -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Aug 18 13:09:56 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EF81200CD; Sun, 18 Aug 2019 13:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 1_OfoDq93pwB; Sun, 18 Aug 2019 13:09:52 -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 3A4DE1200B9; Sun, 18 Aug 2019 13:09:52 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 72DCD380BE; Sun, 18 Aug 2019 16:08:56 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6B1DEB2D; Sun, 18 Aug 2019 16:09:50 -0400 (EDT) From: Michael Richardson To: Benjamin Kaduk , Adam Roach cc: The IESG , Christian Huitema , draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org, anima-chairs@ietf.org In-Reply-To: <20190816223315.GP88236@kduck.mit.edu> References: <156282301326.15131.7510532622479656237.idtracker@ietfa.amsl.com> <17440.1565636744@localhost> <20190814142737.GV88236@kduck.mit.edu> <14902.1565888325@localhost> <20190816223315.GP88236@kduck.mit.edu> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-22: (with DISCUSS and COMMENT) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Aug 2019 20:09:54 -0000 --=-=-= Content-Type: text/plain Benjamin Kaduk wrote: > That specific construction would seem like an "optional feature" per > https://www.ietf.org/blog/iesg-statement-normative-and-informative-references/ > ... I re-read this, and this as to do with References, and so anything optional referenced in section 7 would still need to be a Normative Reference. The stickler I see right now is [I-D.ietf-netconf-keystore]. I don't want to hang on MISREF on that document; it's just one of many that could be used, and I do not want to tell manufacturers that they have to use this specific protocol to update trust anchors. There are many other protocols that they presently support which they could use, in particular, a CLI interface would be fine. I think that this 7.4.3 section that creates a factory default which isn't the default from the factory should be worry people who care about remote attestation of software. Adam has been particularly vocal about the need to specify something normative that manufacturers have to provide in order to resale and operation with the availability of the MASA. It seems that we might need another round of discussion on this topic. I feel that we are being pushed to describe the entire security lifetime of the device; that we need to solve the entire management problem of devices in our document. (i.e. the 25 years of SNMPv3, plus YANG...) Maybe I just don't understand what would be a reasonable answer, if what I've written is not enough. Maybe a virtual interim discussion! If so, please let me know. ANIMA/Iot-Onboarding has some time booked already: https://datatracker.ietf.org/meeting/interim-2019-anima-01/materials/agenda-interim-2019-anima-01-anima-01 ps: (s/IPv6 NAT44/IPv4 NAT44/ for section 7.4.2, btw) >> section 9: >> In recognition of this, some mechanisms are presented in >> Section 7.2. The manufacturer MUST provide at least one of the one- >> touch mechanisms described that permit enrollment to be proceed >> without availability of any manufacturer server (such as the MASA). > ... but this is a somewhat different construction. In isolation, it looks > more like "MUST do at least one of X, Y, Z" without condition on "wish to > do W", and if X, Y, and Z are all in the same place, that place seems > normative to me. (I will confess I've rather lost track of exactly why > we're debating if this is normative or not; I guess it's just the > disclaimer in Section 7 about "considered non-normative in the generality > of the protocol".) Yes, it's MUST do one of X,Y,Z. So that implies: MAY do X, MAY do Y, MAY do Z, but not the case of all being false. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1ZsI0ACgkQgItw+93Q 3WV6zgf/cpfL6iA714V43KxlLrFQ41gAOm/vYCw+Smt172X4vUQTIVxwKR0Kf2v3 tLimX6FxxwNlz9wckMdwGKu7U09+fAeNIKkLyUnCCsS9d97Bu+SnYYNqiGClOrJK LYkhP35TZWSutsDp1F/439O8AL2Zemsj9ea/l3gEinoI+pyuEc/UPV02Oey4P8cG lHpf08HDQLI4BrGh25vU/hINlBt3O0XroXWwkXqiyStcEMCoF3oSqjj4/uc1AaYx HxJI11r1QicgZ5BHQlbGEUvK0X0NviPfRZ0a4k/sre3GQ3Zrpiqp9Ojd3GJRJZQ3 urzNcD3RBnfXJuHd8VANpRGD6LFzHw== =6WBP -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 20 11:13:01 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC71A1209C2; Tue, 20 Aug 2019 11:12:52 -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: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Cc: anima@ietf.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <156632477289.366.10077664311012063905.idtracker@ietfa.amsl.com> Date: Tue, 20 Aug 2019 11:12:52 -0700 Archived-At: Subject: [Anima] WG Review: Autonomic Networking Integrated Model and Approach (anima) X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2019 18:12:53 -0000 The Autonomic Networking Integrated Model and Approach (anima) WG in the Operations and Management Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2019-08-30. Autonomic Networking Integrated Model and Approach (anima) ----------------------------------------------------------------------- Current status: Active WG Chairs: Toerless Eckert Sheng Jiang Assigned Area Director: Ignas Bagdonas Operations and Management Area Directors: Warren Kumari Ignas Bagdonas Technical advisors: Nancy Cam-Winget Mailing list: Address: anima@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/anima Archive: https://mailarchive.ietf.org/arch/browse/anima/ Group page: https://datatracker.ietf.org/group/anima/ Charter: https://datatracker.ietf.org/doc/charter-ietf-anima/ The Autonomic Networking Integrated Model and Approach (ANIMA) working group develops and maintains specifications and documentation for interoperable protocols and procedures for automated network management and control of professionally-managed networks. The vision is a network that configures, heals, optimizes and protects itself. The strategy is the incremental introduction of components to smoothly evolve existing and new networks accordingly. ANIMA work will rely on the framework described in draft-ietf-anima-reference-model already approved for publication. Work not related to this framework is welcome for review, but WG adoption of such work requires explicit rechartering. The two concrete areas of the reference model are (1) the Autonomic Networking Infrastructure (ANI), and (2) Autonomic Functions (AF) built from software modules called Autonomic Service Agents (ASA). The ANI is specified through prior ANIMA work. It is composed of the Autonomic Control Plane (ACP; RFC 8368), Bootstrap over Secure Key Infrastructures (BRSKI) including Vouchers (RFC8366), and the Generic Autonomic Signaling Protocol (GRASP). ANIMA will work on closing gaps and extending the ANI and its components. ANIMA will start to define Autonomic Functions (AF) to enable service automation in networks; it will also work on generic aspects of ASA including design guidelines and lifecycle management, coordination and dependency management. The reference model also discusses Intent, but ANIMA will not work on this without explicit rechartering. It will rely on the Network Management Research Group (NMRG) to define the next steps for this topic. ANIMA will coordinate with other IETF and IRTF groups as needed. The scope of possible work items are (additional works are subject to extra approval from the responsible AD): - Extensions to the ANI, including variations of ANI deployment (e.g. in virtualised environments), information distribution within an AN, ANI OAMP interfaces (Operations, Administration, Management, Provisioning), interaction with YANG-based mechanisms, defining the domain boundary and membership management of the domain. - Support for Autonomic Service Agents, including design and implementation guidelines for ASAs, life cycle management, authorization and coordination of ASA. - BRSKI features, including proxies, enrollment, adaptions over various network protocols, variations of voucher formats. - Generic use cases of Autonomic Network and new GRASP extensions/options for them, including bulk transfer, DNS-SD interworking, autonomic resource management, autonomic SLA assurance, autonomic multi-tenant management, autonomic network measurement. - Integration with Network Operations Centers (NOCs), including autonomic discovery/connectivity to NOC, YANG-based ANI/ASA management by the NOC and reporting AF from node to NOC. Milestones: Nov 2019 - Submit Information distribution over GRASP to the IESG Dec 2019 - Submit Constrained Voucher Artifacts for Bootstrapping Protocols to the IESG Dec 2019 - Submit Constrained Join Proxy for Bootstrapping Protocols to the IESG Mar 2020 - Submit Lifecycle and Management of Autonomic Service Agents to the IESG Mar 2020 - Submit Guidelines for Developing Autonomic Service Agents to the IESG Jul 2020 - Recharter or close the WG From nobody Thu Aug 22 03:38:16 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3397012081D for ; Thu, 22 Aug 2019 03:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 o9N-9vDkc25b for ; Thu, 22 Aug 2019 03:38:12 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) (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 68FC4120169 for ; Thu, 22 Aug 2019 03:38:12 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id x7MAc7N7025487 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Aug 2019 12:38:07 +0200 Received: from DEFTHW99ER2MSX.ww902.siemens.net (defthw99er2msx.ww902.siemens.net [139.22.70.75]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id x7MAc6h9008286 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Aug 2019 12:38:06 +0200 Received: from DENBGAT9ER4MSX.ww902.siemens.net (139.22.70.91) by DEFTHW99ER2MSX.ww902.siemens.net (139.22.70.75) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 22 Aug 2019 12:38:06 +0200 Received: from DEFTHW99EL1MSX.ww902.siemens.net ([169.254.2.75]) by DENBGAT9ER4MSX.ww902.siemens.net ([139.22.70.91]) with mapi id 14.03.0439.000; Thu, 22 Aug 2019 12:38:05 +0200 From: "Fries, Steffen" To: "anima@ietf.org" CC: Eliot Lear Thread-Topic: Questions raised during IETF 105 regarding BRSKI-AE Thread-Index: AdVYNh7DQasumPNcQl+zj+APp3f5iQ== Date: Thu, 22 Aug 2019 10:38:05 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified x-originating-ip: [139.22.70.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Anima] Questions raised during IETF 105 regarding BRSKI-AE X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Aug 2019 10:38:15 -0000 Hi, during IETF 105, there were several questions raised regarding motivation a= nd approach in BRSKI-AE (https://datatracker.ietf.org/doc/draft-fries-anima= -brski-async-enroll/ ) I just checked the recordings and would like to provide some answers. Thank= s Eliot for presenting in the first place. There was a question regarding the benefits on Full CMC (PKI) Request suppo= rt in EST from Michael. One of the benefits of the Full CMC request is that= it provides a way to bind the entity identification and authentication to = the certification request. This can be achieved by an additional signature = over the certification request with the IDevID EE cert of a pledge. The res= ult is what we called in the draft a self-contained object with two signatu= res, one with the private key corresponding to the contained public key in = the CSR, the second with the private key, which's corresponding certificate= can be validated. Maybe the term is misleading as the CSR is also self-co= ntained. So we may need to fine a better term.=20 Having this type of self-contained object comes with some advantages: - It removes the strict binding of the certification request with the pled= ge authentication in TLS using the tls-unique value in the CSR during the E= ST run. This is especially interesting for scenarios, in which the registra= r (EST server) acts as LRA and has (temporarily) no connection to the issui= ng RA/CA. If it needs to store the CSR and forward it later on for further = processing to the RA/CA, the information about the identity and authenticat= ion is not directly bound to the CSR and would require other mechanisms.=20 - For the "no soup case - come back later" case (Eliot, I just borrowed you= r analogy) it provides the advantage, if the tls-unique parameter is used = in the CSR (BRSKI is open to this) to bind the CSR to a specific TLS connec= tion. If the TLS connection between the pledge and the registrar was teared= down, EST (in simple enroll/reenroll) requires to resent the CSR, which wo= uld require to include a new tls-unique number, which in turn would require= rebuilding the CSR (also described in RFC 7030, section 4.2.3). The advantages of self-containment (in the case of EST using the FullCMCreq= uest) are not generally necessary, but there are scenarios, in which the pu= re binding of the pledge authentication using its IDevID EE Cert to the tra= nsport is not sufficient (see also the examples in BRSKI-AE). Note that usi= ng self-containment also addresses the general case. From that point I woul= d see BRSKI-AE as update/enhancement of the mechanisms currently used in BR= SKI. From my understanding this was also the outcome of the conversation du= ring the meeting.=20 Best regards Steffen From nobody Fri Aug 23 14:19:05 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E514712009C for ; Fri, 23 Aug 2019 14:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 33vz3qjAcQ-7 for ; Fri, 23 Aug 2019 14:18:55 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6F112011D for ; Fri, 23 Aug 2019 14:18:54 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0AD1938191; Fri, 23 Aug 2019 17:17:52 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CDAA8D51; Fri, 23 Aug 2019 17:18:53 -0400 (EDT) From: Michael Richardson To: "Fries\, Steffen" cc: "anima\@ietf.org" , Eliot Lear In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Anima] Questions raised during IETF 105 regarding BRSKI-AE X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Aug 2019 21:18:57 -0000 --=-=-= Content-Type: text/plain Fries, Steffen wrote: > There was a question regarding the benefits on Full CMC (PKI) Request > support in EST from Michael. One of the benefits of the Full CMC > request is that it provides a way to bind the entity identification and > authentication to the certification request. This can be achieved by an > additional signature over the certification request with the IDevID EE > cert of a pledge. The result is what we called in the draft a > self-contained object with two signatures, one with the private key > corresponding to the contained public key in the CSR, the second with > the private key, which's corresponding certificate can be validated. > Maybe the term is misleading as the CSR is also self-contained. So we > may need to fine a better term. okay. I need to re-read things to better understand. > Having this type of self-contained object comes with some advantages: > - It removes the strict binding of the certification request with the > pledge authentication in TLS using the tls-unique value in the CSR > during the EST run. This is especially interesting for scenarios, in > which the registrar (EST server) acts as LRA and has (temporarily) no > connection to the issuing RA/CA. If it needs to store the CSR and > forward it later on for further processing to the RA/CA, the > information about the identity and authentication is not directly bound > to the CSR and would require other mechanisms. > - For the "no soup case - come back later" case (Eliot, I just borrowed > your analogy) it provides the advantage, if the tls-unique parameter > is used in the CSR (BRSKI is open to this) to bind the CSR to a > specific TLS connection. If the TLS connection between the pledge and > the registrar was teared down, EST (in simple enroll/reenroll) requires > to resent the CSR, which would require to include a new tls-unique > number, which in turn would require rebuilding the CSR (also described > in RFC 7030, section 4.2.3). I agree that this is a good feature. Can you tell us more about how you'd use it? My next question would be, given that some would like CMP rather than EST as an option, and it appears that LAMPS may do a minimal profile of CMP, maybe that would suit you better for these disconnected uses rather than fullcmc. Regardless, how would one discover and signal the use of fullcmc or CMP? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl1gWD0ACgkQgItw+93Q 3WXInAf+KU+KG7rGW+vHVvgLuEb8f5i1F7gAjzaeTdx++4FykXCXKUnJQ9+8bUav 5w7bQWvzgIDqriYOAUzE90j1F4e5IyyE0DBcIlKf1AqXnG7BoYw0dLdSmpKcbATT RQKd6wQN/O9SqiXArgV+C1qyF1dK60+VEZG2R2M2MzsY55wuwXhwizpaHWwpqf7Q XGYFY3cwVcQPQOeJ1+l7nlDMaLnB+7A8Sb59bE/ftflTNacB472Qia/1nDoo+uyZ 38UUtWYANupG0b9xYxwZIbNuXy/eoGgWtHeqJzFKp2TRhY7lQ5cMJGawKwj6XEUa mOvnO9BQrpG/xbtEKN3UyoKG7rUQjA== =D1vB -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Aug 25 23:10:38 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12B1120104 for ; Sun, 25 Aug 2019 23:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 OLS64U7tDdw9 for ; Sun, 25 Aug 2019 23:10:34 -0700 (PDT) Received: from goliath.siemens.de (goliath.siemens.de [192.35.17.28]) (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 689281200A4 for ; Sun, 25 Aug 2019 23:10:34 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id x7Q6ASd8032697 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Aug 2019 08:10:28 +0200 Received: from DEFTHW99ER7MSX.ww902.siemens.net (defthw99er7msx.ww902.siemens.net [139.22.70.68]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id x7Q6ARQV025513 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 26 Aug 2019 08:10:27 +0200 Received: from DEFTHW99EROMSX.ww902.siemens.net (139.22.70.201) by DEFTHW99ER7MSX.ww902.siemens.net (139.22.70.68) with Microsoft SMTP Server (TLS) id 14.3.439.0; Mon, 26 Aug 2019 08:10:27 +0200 Received: from DEFTHW99EL1MSX.ww902.siemens.net ([169.254.2.112]) by DEFTHW99EROMSX.ww902.siemens.net ([139.22.70.201]) with mapi id 14.03.0439.000; Mon, 26 Aug 2019 08:10:26 +0200 From: "Fries, Steffen" To: Michael Richardson CC: "anima@ietf.org" , Eliot Lear Thread-Topic: [Anima] Questions raised during IETF 105 regarding BRSKI-AE Thread-Index: AdVYNh7DQasumPNcQl+zj+APp3f5iQBsXsKAAHpqnWA= Date: Mon, 26 Aug 2019 06:10:26 +0000 Message-ID: References: <10184.1566595133@localhost> In-Reply-To: <10184.1566595133@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-document-confidentiality: NotClassified x-originating-ip: [139.22.70.9] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Anima] Questions raised during IETF 105 regarding BRSKI-AE X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Aug 2019 06:10:37 -0000 Hi Michael, > From: Michael Richardson > Fries, Steffen wrote: > > There was a question regarding the benefits on Full CMC (PKI) Reque= st > > support in EST from Michael. One of the benefits of the Full CMC > > request is that it provides a way to bind the entity identification= and > > authentication to the certification request. This can be achieved b= y an > > additional signature over the certification request with the IDevID= EE > > cert of a pledge. The result is what we called in the draft a > > self-contained object with two signatures, one with the private key > > corresponding to the contained public key in the CSR, the second wi= th > > the private key, which's corresponding certificate can be validated= . > > Maybe the term is misleading as the CSR is also self-contained. So = we > > may need to fine a better term. >=20 > okay. I need to re-read things to better understand. [stf] the essential point is to have the binding of the authentication usin= g IDevID EE credentials directly on the CSR instead of indirectly using the= communication link. We definitely need a better term as self-containing ma= y be misleading. >=20 > > Having this type of self-contained object comes with some advantage= s: > > - It removes the strict binding of the certification request with = the > > pledge authentication in TLS using the tls-unique value in the CSR > > during the EST run. This is especially interesting for scenarios, i= n > > which the registrar (EST server) acts as LRA and has (temporarily) = no > > connection to the issuing RA/CA. If it needs to store the CSR and > > forward it later on for further processing to the RA/CA, the > > information about the identity and authentication is not directly b= ound > > to the CSR and would require other mechanisms. >=20 >=20 > > - For the "no soup case - come back later" case (Eliot, I just borr= owed > > your analogy) it provides the advantage, if the tls-unique paramet= er > > is used in the CSR (BRSKI is open to this) to bind the CSR to a > > specific TLS connection. If the TLS connection between the pledge a= nd > > the registrar was teared down, EST (in simple enroll/reenroll) requ= ires > > to resent the CSR, which would require to include a new tls-unique > > number, which in turn would require rebuilding the CSR (also descri= bed > > in RFC 7030, section 4.2.3). >=20 > I agree that this is a good feature. > Can you tell us more about how you'd use it? [stf] Retry in EST is done by resending the CSR is after the signaled retry= after period in the 202 message from the server. The server must keep trac= k of all states necessary to assign the try request to an already received = request. Other protocols provide a request identifier, which can be leverag= ed to ask for the certificate using the request identifier based on the ini= tially provided CSR. >=20 > My next question would be, given that some would like CMP rather than EST= as an option, and it appears that LAMPS may do a > minimal profile of CMP, maybe that would suit you better for these discon= nected uses rather than fullcmc. [stf] The intention of lightweight CMP is to reduce the versality of CMP do= wn to what is necessary in typical industrial or IoT scenarios. It can be u= sed in a similar way as FullCMC and thus it can be used to address the BRSK= I-AE case. As stated in BRSKI-AE draft, the message wrapping with signature= provided in CMP and FullCMC provides the binding to the initial authentica= tion on an object base. That said, I would propose to let the registrar sup= port multiple enrollment protocols to be able to handle different deploymen= t environments. > Regardless, how would one discover and signal the use of fullcmc or CMP? [stf] EST provides this option by using the well-known URI approach. It spe= cifies this for /simpeenroll and /simplereenroll, but also for /fullcmc. In= BRSKI-AE we followed that path and utilized the same mimic and proposed "/= .well-known/enrollment-variant/request". This would allow to support differ= ent options on the Registrar side and let the pledge pick one. Best regards Steffen >=20 > -- > Michael Richardson , Sandelman Software Works -= =3D IPv6 IoT consulting =3D- From nobody Tue Aug 27 06:58:25 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA95120809; Tue, 27 Aug 2019 06:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=LAD1R/vh; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iAA/FhDJ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFuziu0hYUIY; Tue, 27 Aug 2019 06:58:14 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCFD3120810; Tue, 27 Aug 2019 06:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7714; q=dns/txt; s=iport; t=1566914293; x=1568123893; h=from:to:cc:subject:date:message-id:mime-version; bh=XvTV9xQI7hyUKJQsLznUSIlJ+ADWO5CLDbDJ3iqe4jc=; b=LAD1R/vhM9/K5F0+TuIVTBizim3BiTtEDL0oHJ2UdZ33S5EjBe9DP4Pf U/hUMTzPYCKcqSPBNNTgYf613nEj/Rtv3XYmhC/A+jJp4dyD2c/jRBKtp VmZDbvNELpjmszk+uuaNdH72QRbcKGO4NoJxl4KRjAlcWlRYZWH2Ma5PR E=; IronPort-PHdr: =?us-ascii?q?9a23=3AEunBMBF3Jj0S8BH5gUeMrp1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w3A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efPuYiUgNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABqNmVd/4YNJK1LFwMZAQEBAQE?= =?us-ascii?q?BAQEBAQEBBwEBAQEBAYFTBAEBAQEBCwGBRFADbVYgBAsqhCFZgm4DhFKGIE2?= =?us-ascii?q?ZeIEugSQDVAkBAQEJAwEBJQgCAQGEPwIXgi8jNAkOAgoBAQQBAQECAQYEbYU?= =?us-ascii?q?uDIVNFhEdAQEkEwENBAE0BAwGAgQZFyQCAQEDAQ0FCBqDAYFqAx0BAgw5nyM?= =?us-ascii?q?CgTiIYXOBMoJ7AQEFRIRAGIIPBwMGBYEvAYVchhgYgUA/gRFGhWsEGH07EUU?= =?us-ascii?q?IgjwygiaObDKFE4EBlkEJAoIehmqNeYIyhzCOdI1rh26QPAIEAgQFAg4BAQW?= =?us-ascii?q?BUDiBWHAVgycTgi8MF4Ewgh+KU3IBgSiLcIIuAQE?= X-IronPort-AV: E=Sophos;i="5.64,437,1559520000"; d="scan'208";a="314735107" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Aug 2019 13:58:12 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x7RDwCTo029842 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Aug 2019 13:58:12 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 27 Aug 2019 08:58:11 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 27 Aug 2019 08:58:10 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 27 Aug 2019 08:58:10 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wek9s1nHzvoHPOnCJDO1ba8fWxPfS/cBzk79cjEU5qLrcNb961nKn7KMEywXSsUce2vkPAmaXejH0CJ18aDmxm2vaVnCTUkahUYHjcN0zC/pLBCmpssUk3Acw8LRMV25HA4qicYYhazB3nOwnnC6Cn1ThiMHhYzBKheULl5TNOgKDaX1+ulWWR9+S89dVSFrMTZ1A4L4ixPsek8PMmJfx/YBRPXBWUwno6JFQTrB9cjEnCA4ZP8XODDz72shqQH4axnHfxmHoAYPJK0nDAu+xq/nxHoAKkIYBdjc25C8EyKWb9Qu68IEP7bbq0ZsdhY8JT8AqFZNlE7dOD6OgY3AgQ== 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=i1rlu6IGD4oi0cEpwGOB54Ya6sBcPt9qM/wbQuv1od8=; b=acLZWMWz12AdAvpN5OI2g1klujKHc4ewYKs8mllFSadhha1wVS9pe7clwbCMbz+lKHyIfqHrlbfuLCqjbUUZwsjLwKYDJHCSVtwKM0jjIzTmHjAsjc7J75j1zBdUto5P9ddnQeXgUGDIo0UxGRIpK2AZre3yrqzScCRHExsIrr4YTVeKFe0VBereMNsJUtqDTGZWp0+asMPVZ6Yc4iZwTxmd01DrcvMuiUhy7lDBLCE9gZLjTrnKBpQNhhBYgLFiv/J2tJ7G7N024YdXFAl6qo6/22AV1NBnl0IoZTzyHRbZ/TPSsoeCEb9q7hbr2jkXLS/u7bZWe/WtUWt5DnwR9g== 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=i1rlu6IGD4oi0cEpwGOB54Ya6sBcPt9qM/wbQuv1od8=; b=iAA/FhDJXWZbizYpA8do2ZyjbFTHQMS/gZu0dXNZxyb438Q/tLMX7PMziPHQFf2bRj+sTl+wx9Wt+q8uRA4zetdw1+1Ph4JdLsKdMw06wR5KfUooQk1ZapZLH6DWoKsbzPHan9B5NBDcHKkJd+hGRVm0TRnRunJHwOYvy0QM9Bo= Received: from BYAPR11MB3814.namprd11.prod.outlook.com (20.178.239.88) by BYAPR11MB3176.namprd11.prod.outlook.com (20.177.127.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.20; Tue, 27 Aug 2019 13:58:09 +0000 Received: from BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::9c45:80a6:52eb:7f1d]) by BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::9c45:80a6:52eb:7f1d%4]) with mapi id 15.20.2199.021; Tue, 27 Aug 2019 13:58:09 +0000 From: "Eliot Lear (elear)" To: "iot-onboarding@ietf.org" , "anima@ietf.org" CC: "Randy Armstrong (OPC)" , "pdemestichas@gmail.com" , "Nancy Cam-Winget (ncamwing)" , "Cappalli, Tim (Aruba Security)" , "Werner, Thomas" , "Gonzalo Salgueiro (gsalguei)" , "Pete Beal (pbeal)" , "cabocabo@gmail.com" , Jack Visoky , Erik Nordmark , "Fries, Steffen" , "Bal, Kallola" , "Max Pritikin (pritikin)" , "Pascal Thubert (pthubert)" , "Schellenbaum Aurelio Ruben Dario (scnm)" , "mranga@gmail.com" , "Nagendra Kumar Nainar (naikumar)" Thread-Topic: IoT Onboarding Virtual Meeting Thread-Index: AdVNoiZpR8Ihba17XUiDYm03RShw7g== Date: Tue, 27 Aug 2019 13:58:09 +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: spf=none (sender IP is ) smtp.mailfrom=elear@cisco.com; x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAAAAAAAAAAAAAAAAAAAAAAAAAAAMQAAAHZDYWwtVWlkAQAAAEZDMjY2MTNDLTkwOTYtNEQwNC05QjgwLTZCQTg3N0EyN0EyQQA= x-originating-ip: [2001:420:c0c0:1007::1c7] x-ms-office365-filtering-correlation-id: 39020345-44a7-4112-8ca2-08d72af69803 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3176; x-ms-traffictypediagnostic: BYAPR11MB3176:MeetingMessage x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0142F22657 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(136003)(346002)(39860400002)(396003)(189003)(199004)(497574002)(66476007)(64756008)(66446008)(107886003)(66946007)(86362001)(3480700005)(6436002)(66556008)(14454004)(76116006)(91956017)(81156014)(74316002)(81166006)(8936002)(8676002)(7416002)(7736002)(2501003)(305945005)(6506007)(966005)(7696005)(102836004)(99286004)(16799955002)(186003)(476003)(478600001)(486006)(46003)(6116002)(6306002)(2906002)(5660300002)(33656002)(52536014)(14444005)(256004)(4744005)(53936002)(55016002)(71190400001)(71200400001)(54906003)(316002)(9686003)(25786009)(110136005)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3176; H:BYAPR11MB3814.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: DfnfKDXK5jTfCKD2UDd+PZjX3yQRJSQVFv+0+MpajEqCIvQLfnkfwMRL2GJWRmHYWL7bD6krmsM5+r/gOmwVWRCdkv0kMO+0/O4VpjeaKqiaamAzTEVqK6UbArRRDMU5jwQMSFEvwquldsnvMkH+zD3NcF4sIFQaJdGaQJvZOy0QIw/OQG2SrVz35jTvK5sg1GqI9m1nqpdo3xJbj+UH6WrvLKqg2ZmYqUdEgvBeQZF4DgTyfBSPfnF4V3Pthpi10J/Z5ErWo56mdAahTDaW7eCfWXukLhxXsxwB9Wq/OM/6k1cefKTY/ZEijD/VuoFymT2ki5K5exn1Hye8K1vsQp6panlUr1dCxpR6lbrFM+F4HO0XpA62dLeilIvPVIG1v8OYVGq3fJlB0MEpJrUuQFVM1sAYq1a01JI5VJP/gwI= Content-Type: multipart/alternative; boundary="_002_BYAPR11MB381458C7CF4AFED4B5FA5F7DBFA00BYAPR11MB3814namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 39020345-44a7-4112-8ca2-08d72af69803 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2019 13:58:09.6015 (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: exnW4FdESAwdrILkE2N6LLNlln5V34Sql1qOykRQXnpLXlyQYIBGKLO/Cpayg/HY X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3176 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: [Anima] IoT Onboarding Virtual Meeting X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Aug 2019 13:58:23 -0000 --_002_BYAPR11MB381458C7CF4AFED4B5FA5F7DBFA00BYAPR11MB3814namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please hold this time for the onboarding discussion (I'm on vacation and am= sending this a bit early). This is an IoT Onboarding virtual meeting.=0A= =0A= Tentative Agenda:=0A= =0A= - OPC UA use case=0A= - updates on drafts=0A= - AOB=0A= =0A= =0A= =0A= =0A= Meeting Information=0A= =0A= Meeting link:=0A= https://cisco.webex.com/cisco/j.php?MTID=3Dm16f8e0d12f6d12c3c37984c73f2= 0efb8=0A= Meeting number:=0A= 207 046 128=0A= Password:=0A= c3wvus3x (23988739 from phones)=0A= Host key:=0A= 735404 =0A= =0A= More ways to join=0A= =0A= Join by video system=0A= Dial 207046128@cisco.webex.com=0A= You can also dial 173.243.2.68 and enter your meeting number.=0A= =0A= Join by phone=0A= +1-866-432-9903 Call-in toll-free number (US/Canada)=0A= +1-408-525-6800 Call-in number (US/Canada)=0A= Access code: 207 046 128=0A= =0A= Global call-in numbers | Toll-free calling restrictions = --_002_BYAPR11MB381458C7CF4AFED4B5FA5F7DBFA00BYAPR11MB3814namp_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpXLiBFdXJv cGUgU3RhbmRhcmQgVGltZQ0KQkVHSU46U1RBTkRBUkQNCkRUU1RBUlQ6MTYwMTAxMDFUMDMwMDAw DQpUWk9GRlNFVEZST006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClJSVUxFOkZSRVE9WUVBUkxZ O0lOVEVSVkFMPTE7QllEQVk9LTFTVTtCWU1PTlRIPTEwDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRB WUxJR0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9G RlNFVFRPOiswMjAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllN T05USD0zDQpFTkQ6REFZTElHSFQNCkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0KT1JHQU5J WkVSO0NOPUVsaW90IExlYXIgKGVsZWFyKTpNQUlMVE86ZWxlYXJAY2lzY28uY29tDQpBVFRFTkRF RTtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NO PWlvdC1vbmJvYXINCiBkaW5nQGlldGYub3JnOk1BSUxUTzppb3Qtb25ib2FyZGluZ0BpZXRmLm9y Zw0KQVRURU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JT VlA9VFJVRTtDTj1hbmltYUBpZXRmDQogLm9yZzpNQUlMVE86YW5pbWFAaWV0Zi5vcmcNCkFUVEVO REVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7 Q049UmFuZHkgQXJtcw0KIHRyb25nIChPUEMpOk1BSUxUTzpyYW5keS5hcm1zdHJvbmdAb3BjZm91 bmRhdGlvbi5vcmcNCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURT LUFDVElPTjtSU1ZQPVRSVUU7Q049cGRlbWVzdGljaA0KIGFzQGdtYWlsLmNvbTpNQUlMVE86cGRl bWVzdGljaGFzQGdtYWlsLmNvbQ0KQVRURU5ERUU7Uk9MRT1PUFQtUEFSVElDSVBBTlQ7UEFSVFNU QVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj1OYW5jeSBDYW0tDQogV2luZ2V0IChuY2Ftd2lu Zyk6TUFJTFRPOm5jYW13aW5nQGNpc2NvLmNvbQ0KQVRURU5ERUU7Uk9MRT1PUFQtUEFSVElDSVBB TlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj0iQ2FwcGFsbGksIA0KIFRpbSAo QXJ1YmEgU2VjdXJpdHkpIjpNQUlMVE86dGltY0BocGUuY29tDQpBVFRFTkRFRTtST0xFPU9QVC1Q QVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPSJXZXJuZXIsIFRo DQogb21hcyI6TUFJTFRPOnRob21hcy13ZXJuZXJAc2llbWVucy5jb20NCkFUVEVOREVFO1JPTEU9 T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049R29uemFs byBTYQ0KIGxndWVpcm8gKGdzYWxndWVpKTpNQUlMVE86Z3NhbGd1ZWlAY2lzY28uY29tDQpBVFRF TkRFRTtST0xFPU9QVC1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVF O0NOPVBldGUgQmVhbCANCiAocGJlYWwpOk1BSUxUTzpwYmVhbEBjaXNjby5jb20NCkFUVEVOREVF O1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049 Y2Fib2NhYm9AZw0KIG1haWwuY29tOk1BSUxUTzpjYWJvY2Fib0BnbWFpbC5jb20NCkFUVEVOREVF O1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049 SmFjayBWaXNvaw0KIHk6TUFJTFRPOmptdmlzb2t5QHJhLnJvY2t3ZWxsLmNvbQ0KQVRURU5ERUU7 Uk9MRT1PUFQtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj1F cmlrIE5vcmRtDQogYXJrOk1BSUxUTzplcmlrQHplZGVkYS5jb20NCkFUVEVOREVFO1JPTEU9T1BU LVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049IkZyaWVzLCBT dGUNCiBmZmVuIjpNQUlMVE86c3RlZmZlbi5mcmllc0BzaWVtZW5zLmNvbQ0KQVRURU5ERUU7Uk9M RT1PUFQtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj0iQmFs LCBLYWxsbw0KIGxhIjpNQUlMVE86Sy5CYWxAb3NyYW0uY29tDQpBVFRFTkRFRTtST0xFPU9QVC1Q QVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPU1heCBQcml0aWsN CiBpbiAocHJpdGlraW4pOk1BSUxUTzpwcml0aWtpbkBjaXNjby5jb20NCkFUVEVOREVFO1JPTEU9 T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049UGFzY2Fs IFRodQ0KIGJlcnQgKHB0aHViZXJ0KTpNQUlMVE86cHRodWJlcnRAY2lzY28uY29tDQpBVFRFTkRF RTtST0xFPU9QVC1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NO PVNjaGVsbGVuYmENCiB1bSBBdXJlbGlvIFJ1YmVuIERhcmlvIChzY25tKTpNQUlMVE86c2NubUB6 aGF3LmNoDQpBVFRFTkRFRTtST0xFPU9QVC1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJ T047UlNWUD1UUlVFO0NOPW1yYW5nYUBnbWENCiBpbC5jb206TUFJTFRPOm1yYW5nYUBnbWFpbC5j b20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtS U1ZQPVRSVUU7Q049TmFnZW5kcmEgSw0KIHVtYXIgTmFpbmFyIChuYWlrdW1hcik6TUFJTFRPOm5h aWt1bWFyQGNpc2NvLmNvbQ0KREVTQ1JJUFRJT047TEFOR1VBR0U9ZW4tVVM6UGxlYXNlIGhvbGQg dGhpcyB0aW1lIGZvciB0aGUgb25ib2FyZGluZyBkaXNjdXNzDQogaW9uIChJJ20gb24gdmFjYXRp b24gYW5kIGFtIHNlbmRpbmcgdGhpcyBhIGJpdCBlYXJseSkuICBUaGlzIGlzIGFuIElvVCBPbmIN CiBvYXJkaW5nIHZpcnR1YWwgbWVldGluZy5cblxuVGVudGF0aXZlIEFnZW5kYTpcblxuIC0gT1BD IFVBIHVzZSBjYXNlXG4gLSB1cA0KIGRhdGVzIG9uIGRyYWZ0c1xuIC0gQU9CXG5cblxuXG5cbk1l ZXRpbmcgSW5mb3JtYXRpb25cblxuTWVldGluZyBsaW5rOlxuICAgDQogIGh0dHBzOi8vY2lzY28u d2ViZXguY29tL2Npc2NvL2oucGhwP01USUQ9bTE2ZjhlMGQxMmY2ZDEyYzNjMzc5ODRjNzNmMjBl ZmINCiA4XG5NZWV0aW5nIG51bWJlcjpcbiAgICAyMDcgMDQ2IDEyOFxuUGFzc3dvcmQ6XG4gICAg YzN3dnVzM3ggKDIzOTg4NzM5IGZybw0KIG0gcGhvbmVzKVxuSG9zdCBrZXk6XG4gICAgNzM1NDA0 IFxuXG5Nb3JlIHdheXMgdG8gam9pblxuXG5Kb2luIGJ5IHZpZGVvIHN5DQogc3RlbVxuICAgIERp YWwgMjA3MDQ2MTI4QGNpc2NvLndlYmV4LmNvbVxuICAgIFlvdSBjYW4gYWxzbyBkaWFsIDE3My4y NDMuMi4NCiA2OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51bWJlci5cblxuSm9pbiBieSBwaG9u ZVxuICAgICsxLTg2Ni00MzItOTkwMyBDYQ0KIGxsLWluIHRvbGwtZnJlZSBudW1iZXIgKFVTL0Nh bmFkYSlcbiAgICArMS00MDgtNTI1LTY4MDAgQ2FsbC1pbiBudW1iZXIgKFVTDQogL0NhbmFkYSlc biAgICBBY2Nlc3MgY29kZTogMjA3IDA0NiAxMjhcblxuICAgIEdsb2JhbCBjYWxsLWluIG51bWJl cnMgfCBUb2wNCiBsLWZyZWUgY2FsbGluZyByZXN0cmljdGlvbnMgDQpVSUQ6RkMyNjYxM0MtOTA5 Ni00RDA0LTlCODAtNkJBODc3QTI3QTJBDQpTVU1NQVJZO0xBTkdVQUdFPWVuLVVTOklvVCBPbmJv YXJkaW5nIFZpcnR1YWwgTWVldGluZw0KRFRTVEFSVDtUWklEPVcuIEV1cm9wZSBTdGFuZGFyZCBU aW1lOjIwMTkwODI5VDE3MDAwMA0KRFRFTkQ7VFpJRD1XLiBFdXJvcGUgU3RhbmRhcmQgVGltZToy MDE5MDgyOVQxODAwMDANCkNMQVNTOlBVQkxJQw0KUFJJT1JJVFk6NQ0KRFRTVEFNUDoyMDE5MDgy N1QxMzU4MDhaDQpUUkFOU1A6T1BBUVVFDQpTVEFUVVM6Q09ORklSTUVEDQpTRVFVRU5DRToxDQpM T0NBVElPTjtMQU5HVUFHRT1lbi1VUzpXZWJFeDogc2VlIGJlbG93DQpYLU1JQ1JPU09GVC1DRE8t QVBQVC1TRVFVRU5DRToxDQpYLU1JQ1JPU09GVC1DRE8tT1dORVJBUFBUSUQ6MjExNzYxNjQ4Mw0K WC1NSUNST1NPRlQtQ0RPLUJVU1lTVEFUVVM6VEVOVEFUSVZFDQpYLU1JQ1JPU09GVC1DRE8tSU5U RU5ERURTVEFUVVM6QlVTWQ0KWC1NSUNST1NPRlQtQ0RPLUFMTERBWUVWRU5UOkZBTFNFDQpYLU1J Q1JPU09GVC1DRE8tSU1QT1JUQU5DRToxDQpYLU1JQ1JPU09GVC1DRE8tSU5TVFRZUEU6MA0KWC1N SUNST1NPRlQtRE9OT1RGT1JXQVJETUVFVElORzpGQUxTRQ0KWC1NSUNST1NPRlQtRElTQUxMT1ct Q09VTlRFUjpGQUxTRQ0KWC1NSUNST1NPRlQtTE9DQVRJT05ESVNQTEFZTkFNRTpXZWJFeDogc2Vl IGJlbG93DQpYLU1JQ1JPU09GVC1MT0NBVElPTlNPVVJDRTpOb25lDQpYLU1JQ1JPU09GVC1MT0NB VElPTlM6W3siRGlzcGxheU5hbWUiOiJXZWJFeDogc2VlIGJlbG93IlwsIkxvY2F0aW9uQW5ub3Rh dGkNCiBvbiI6IiJcLCJMb2NhdGlvblVyaSI6IiJcLCJMb2NhdGlvblN0cmVldCI6IiJcLCJMb2Nh dGlvbkNpdHkiOiIiXCwiTG9jYXRpbw0KIG5TdGF0ZSI6IiJcLCJMb2NhdGlvbkNvdW50cnkiOiIi XCwiTG9jYXRpb25Qb3N0YWxDb2RlIjoiIlwsIkxvY2F0aW9uRnVsbEFkDQogZHJlc3MiOiIifV0N CkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== --_002_BYAPR11MB381458C7CF4AFED4B5FA5F7DBFA00BYAPR11MB3814namp_-- From nobody Thu Aug 29 07:50:51 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE4B12010E; Thu, 29 Aug 2019 07:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=lFr9K/t0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nzqpu5no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_K0B0aZYfeC; Thu, 29 Aug 2019 07:50:47 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92DAF1200C3; Thu, 29 Aug 2019 07:50:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11598; q=dns/txt; s=iport; t=1567090247; x=1568299847; h=from:to:cc:subject:date:message-id:mime-version; bh=kWZyjSDZ7NCdgJ6t+Gkfj84q2pWyee9NhtXWMiquCL0=; b=lFr9K/t0bdEk9wJNiDe3md7Jwj+zluPWLpKtzCJt/YRgGgACIyBrmng7 Asq7trovGCVw4/W5OHmWLLm0O84fkzeH9YMOGdXDJPMmq3FNoiKBtxmF8 a9qw8WeWVHr/GQ9si9V3V5c3f3ruoMqJV4FS9kDuqehz4VmPT5S4Luh9b w=; IronPort-PHdr: =?us-ascii?q?9a23=3AGVpGnh1zvE52DEWksmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxGPt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQBEn2JeTCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAABe5Wdd/4sNJK1MFwMaAQEBAQE?= =?us-ascii?q?CAQEBAQcCAQEBAYFTBQEBAQELAYFEUANtViAECyqEIVmCbgOEUoYeTZl5gS6?= =?us-ascii?q?BJANUCQEBAQkDAQElCAIBAYQ/AheCQiM0CQ4CAwgBAQQBAQECAQYEbYUuDIV?= =?us-ascii?q?NARURHQEBJBMBDQQBNAQMBgIEGRckAgEBAwENBQgagwGBagMdAQIMOZ8nAoE?= =?us-ascii?q?4iGFzgTKCfAEBBUSETBiCDwcDBgWBLwGFXoYYGIFAP4ERRoVrBBh9OxFFCII?= =?us-ascii?q?8MoImjnMzhRqBAZZLCQKCHoZujgCCMoc0jneNb4dvkEgCBAIEBQIOAQEFgVA?= =?us-ascii?q?4gVhwFYMnE4IvDBeBMIIfilNyAYEojB6CMAEB?= X-IronPort-AV: E=Sophos;i="5.64,443,1559520000"; d="scan'208";a="622001323" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Aug 2019 14:50:45 +0000 Received: from XCH-ALN-015.cisco.com (xch-aln-015.cisco.com [173.36.7.25]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x7TEoiCw013557 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Aug 2019 14:50:45 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-015.cisco.com (173.36.7.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 09:50:44 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 10:50:42 -0400 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 29 Aug 2019 09:50:42 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VjOOFUtt8Sv53ElQbjDWP+XaoIns/kXclk5tAuIfKADHMAIhKyJD1o2cRarrzYXKEKwUiwrX8GGVdaQYBaGX3l9r+z1Stl0MG8KKqp+oWMRw09ZN2wV2EMfkbvBNPP3osTJDzOOcIVso0YRkfd0+Oq40XvbCyqJqRO8bwpLGA5d6tzG0RAIZdwY9jLPx2E+Hw6Bomvz8U/hegvBuI5BVVb0N69rpP5dO9P/xTGIQfSPI8bP0h+jXe6QU2SWkYTJ2eSyH/vj2ahXME56xBZr9HsEeIKoFkqWEl1APvy/VDGZU39pg5uiijrviEovddKaVd3xhwnxZO3G1Y8OCCv0i9A== 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=unhzDuSklEvL7LcCMVEvEJICK0LvzQXPZ7eJN11TROo=; b=UI/U7cNqHZnU8PwBEqv9TqWKfAEKZ4jbgHbNZ5Jlgb8WQUTL/Rh+QR7cNRP0ixN/cZCejbQOYY2MVHNkl1TB+BRhXdrGv1ohkpK6NDAWY+jgf8jpXrxTkgm/NXaKF6/g4gDxr/p2VEuw/QRMibW9ftLIMu+u3h/5e3Jni3aP9DRYbx9w29QpcsnpPIj4OD8NCNg10IaxX/iKWTQlYdMTZuzH+Nv7ax9IZQYZDAksr+mO/jrM+l/mSGO8JoOC+SnTdilGd4aJn5JMJf4F3UUbwM0HI6SlwCSKGf817yVHEZD928+Z3/R8CqdT3vQyAKJbH6U8ea0au4bcifCA+PWjNg== 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=unhzDuSklEvL7LcCMVEvEJICK0LvzQXPZ7eJN11TROo=; b=nzqpu5noTJQkjQ7IA8Ri0teeOP25G15GfX2KHRFlvT8pWDK9CpLjg8O19u6BwXv9AyrUZHkA/vZLhjNBAvf2VWy5hVJw4zn9v2b11o16E8KEALquxU9HpSS9bDPUyedq/Uv0cPkUMaDytCgYAqmYpHUdJZ1v8/fIUjfR8oDzwZ4= Received: from BYAPR11MB3814.namprd11.prod.outlook.com (20.178.239.88) by BYAPR11MB3384.namprd11.prod.outlook.com (20.177.186.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.20; Thu, 29 Aug 2019 14:50:41 +0000 Received: from BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::9c45:80a6:52eb:7f1d]) by BYAPR11MB3814.namprd11.prod.outlook.com ([fe80::9c45:80a6:52eb:7f1d%4]) with mapi id 15.20.2220.013; Thu, 29 Aug 2019 14:50:41 +0000 From: "Eliot Lear (elear)" To: "iot-onboarding@ietf.org" , Parisa Grayeli , "anima@ietf.org" CC: "Pascal Thubert (pthubert)" , "Gonzalo Salgueiro (gsalguei)" , "nate@cypient.com" , "Nancy Cam-Winget (ncamwing)" , Thomas Fossati , "Fries, Steffen" , "Eric Wenger (erwenger)" , "scottj@google.com" , Jack Visoky , "Max Pritikin (pritikin)" , Pierre-Antoine Vervier , Timothy Jones , "mranga@gmail.com" , "montemurro.michael@gmail.com" , "Michael Bartling" , Jo Wlotzka , "Petros Efstathopoulos" , "pdemestichas@gmail.com" , "Paul Duffy (paduffy)" , "Barker, William C. (Assoc)" , Susanta Nanda , "Symington, Susan F." , "Nagendra Kumar Nainar (naikumar)" , "Watrobski, Paul (Ctr)" , "Randy Armstrong (OPC)" , "Werner, Thomas" , "Cappalli, Tim (Aruba Security)" , Erik Nordmark , "Schellenbaum Aurelio Ruben Dario (scnm)" , "abaykal@globalcyberalliance.org" , "Montgomery, Douglas (Fed)" , "Pete Beal (pbeal)" , Allaukik Abhishek , "Peter Romness (promness)" , "cabocabo@gmail.com" , Yun Shen , Darshak Thakore , Rob Cantu , Wassim Haddad , "Bal, Kallola" Thread-Topic: IoT Onboarding Virtual Meeting Thread-Index: AdVNoiZpR8Ihba17XUiDYm03RShw7g== Date: Thu, 29 Aug 2019 14:50:40 +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: spf=none (sender IP is ) smtp.mailfrom=elear@cisco.com; x-ms-exchange-calendar-series-instance-id: BAAAAIIA4AB0xbcQGoLgCAAAAAAAAAAAAAAAAAAAAAAAAAAAMQAAAHZDYWwtVWlkAQAAAEZDMjY2MTNDLTkwOTYtNEQwNC05QjgwLTZCQTg3N0EyN0EyQQA= x-originating-ip: [2001:420:c0c0:1004::1f2] x-ms-office365-filtering-correlation-id: 2f5ff6b6-59f6-4c5a-c065-08d72c904349 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB3384; x-ms-traffictypediagnostic: BYAPR11MB3384:MeetingMessage x-ms-exchange-purlcount: 1 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(376002)(346002)(136003)(366004)(396003)(497574002)(189003)(199004)(25786009)(14454004)(54906003)(52536014)(16799955002)(66476007)(66556008)(91956017)(66446008)(2501003)(64756008)(66946007)(76116006)(4326008)(316002)(7696005)(966005)(110136005)(478600001)(6506007)(99286004)(5660300002)(6116002)(102836004)(46003)(53936002)(2906002)(9686003)(33656002)(74316002)(8676002)(4744005)(305945005)(486006)(6306002)(55016002)(6436002)(186003)(7736002)(476003)(86362001)(3480700005)(71200400001)(71190400001)(8936002)(7406005)(256004)(14444005)(81166006)(81156014)(7416002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3384; H:BYAPR11MB3814.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: dQ10glnsXQGnekha/UJfh4435TYYLvn60AclIJ1ZzfRhOxCquRhUuOwtri748QCL+eS4VDpmAPk8ELHx6bvaPFo9uZsd/DQwGgCAFO7BYXWP5esR495P+8lVVzogFsRUUpG8M+RgHRvZhLn2rQeCvKjKAv/2KZ1z1UK6Mpq2dj6VnkpJkm9KOxdi1PDO74Xn0RG0IhsLJ0e6YiWTWOqV1/4E7VoDJD1HVJV6khnaBJXdewHwsnvYESHPs0rAqfYQ7lIZqRV+m+6T+PMEU3aREadkUGrIhk7+NLs+nQT/iybVayO+1VjvRzMrk+xm/nm6Nl8jAzwus44v9ezio+P5F1TFox5sWXyDa1T6r1qKwD6uWGeObslB+P7nQs7eN1ASGt2daiSTFhA3bNBJI0Zh1oU22LllLkhbvIQKm1ZZwRY= Content-Type: multipart/alternative; boundary="_002_BYAPR11MB3814E179835623A9CCDF03A9BFA20BYAPR11MB3814namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2f5ff6b6-59f6-4c5a-c065-08d72c904349 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 14:50:40.4338 (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: lNhGBvuDJxQHVgKklG8nNSlIhG/gcpO9CyMHXa8zcazGpVc2HeqR/MI+KOgY7zVU X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3384 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.25, xch-aln-015.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: [Anima] IoT Onboarding Virtual Meeting X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 14:50:50 -0000 --_002_BYAPR11MB3814E179835623A9CCDF03A9BFA20BYAPR11MB3814namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Please hold this time for the onboarding discussion (I'm on vacation and am= sending this a bit early). This is an IoT Onboarding virtual meeting.=0A= =0A= Tentative Agenda:=0A= =0A= - OPC UA use case=0A= - updates on drafts=0A= - AOB=0A= =0A= =0A= =0A= =0A= Meeting Information=0A= =0A= Meeting link:=0A= https://cisco.webex.com/cisco/j.php?MTID=3Dm16f8e0d12f6d12c3c37984c73f2= 0efb8=0A= Meeting number:=0A= 207 046 128=0A= Password:=0A= c3wvus3x (23988739 from phones)=0A= Host key:=0A= 735404 =0A= =0A= More ways to join=0A= =0A= Join by video system=0A= Dial 207046128@cisco.webex.com=0A= You can also dial 173.243.2.68 and enter your meeting number.=0A= =0A= Join by phone=0A= +1-866-432-9903 Call-in toll-free number (US/Canada)=0A= +1-408-525-6800 Call-in number (US/Canada)=0A= Access code: 207 046 128=0A= =0A= Global call-in numbers | Toll-free calling restrictions = --_002_BYAPR11MB3814E179835623A9CCDF03A9BFA20BYAPR11MB3814namp_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAxMA0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpXLiBFdXJv cGUgU3RhbmRhcmQgVGltZQ0KQkVHSU46U1RBTkRBUkQNCkRUU1RBUlQ6MTYwMTAxMDFUMDMwMDAw DQpUWk9GRlNFVEZST006KzAyMDANClRaT0ZGU0VUVE86KzAxMDANClJSVUxFOkZSRVE9WUVBUkxZ O0lOVEVSVkFMPTE7QllEQVk9LTFTVTtCWU1PTlRIPTEwDQpFTkQ6U1RBTkRBUkQNCkJFR0lOOkRB WUxJR0hUDQpEVFNUQVJUOjE2MDEwMTAxVDAyMDAwMA0KVFpPRkZTRVRGUk9NOiswMTAwDQpUWk9G RlNFVFRPOiswMjAwDQpSUlVMRTpGUkVRPVlFQVJMWTtJTlRFUlZBTD0xO0JZREFZPS0xU1U7QllN T05USD0zDQpFTkQ6REFZTElHSFQNCkVORDpWVElNRVpPTkUNCkJFR0lOOlZFVkVOVA0KT1JHQU5J WkVSO0NOPUVsaW90IExlYXIgKGVsZWFyKTpNQUlMVE86ZWxlYXJAY2lzY28uY29tDQpBVFRFTkRF RTtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NO PWlvdC1vbmJvYXINCiBkaW5nQGlldGYub3JnOk1BSUxUTzppb3Qtb25ib2FyZGluZ0BpZXRmLm9y Zw0KQVRURU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JT VlA9VFJVRTtDTj1QYXJpc2EgR3JhDQogeWVsaTpNQUlMVE86cGdyYXllbGlAbWl0cmUub3JnDQpB VFRFTkRFRTtST0xFPVJFUS1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1U UlVFO0NOPWFuaW1hQGlldGYNCiAub3JnOk1BSUxUTzphbmltYUBpZXRmLm9yZw0KQVRURU5ERUU7 Uk9MRT1PUFQtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj1Q YXNjYWwgVGh1DQogYmVydCAocHRodWJlcnQpOk1BSUxUTzpwdGh1YmVydEBjaXNjby5jb20NCkFU VEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRS VUU7Q049R29uemFsbyBTYQ0KIGxndWVpcm8gKGdzYWxndWVpKTpNQUlMVE86Z3NhbGd1ZWlAY2lz Y28uY29tDQpBVFRFTkRFRTtST0xFPU9QVC1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJ T047UlNWUD1UUlVFO0NOPW5hdGVAY3lwaWUNCiBudC5jb206TUFJTFRPOm5hdGVAY3lwaWVudC5j b20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtS U1ZQPVRSVUU7Q049TmFuY3kgQ2FtLQ0KIFdpbmdldCAobmNhbXdpbmcpOk1BSUxUTzpuY2Ftd2lu Z0BjaXNjby5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURT LUFDVElPTjtSU1ZQPVRSVUU7Q049VGhvbWFzIEZvcw0KIHNhdGk6TUFJTFRPOlRob21hcy5Gb3Nz YXRpQGFybS5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURT LUFDVElPTjtSU1ZQPVRSVUU7Q049IkZyaWVzLCBTdGUNCiBmZmVuIjpNQUlMVE86c3RlZmZlbi5m cmllc0BzaWVtZW5zLmNvbQ0KQVRURU5ERUU7Uk9MRT1PUFQtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9 TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj1FcmljIFdlbmdlDQogciAoZXJ3ZW5nZXIpOk1BSUxU TzplcndlbmdlckBjaXNjby5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRT VEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049c2NvdHRqQGdvbw0KIGdsZS5jb206TUFJTFRP OnNjb3R0akBnb29nbGUuY29tDQpBVFRFTkRFRTtST0xFPU9QVC1QQVJUSUNJUEFOVDtQQVJUU1RB VD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPUphY2sgVmlzb2sNCiB5Ok1BSUxUTzpqbXZpc29r eUByYS5yb2Nrd2VsbC5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFU PU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049TWF4IFByaXRpaw0KIGluIChwcml0aWtpbik6TUFJ TFRPOnByaXRpa2luQGNpc2NvLmNvbQ0KQVRURU5ERUU7Uk9MRT1PUFQtUEFSVElDSVBBTlQ7UEFS VFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj1QaWVycmUtQW50DQogb2luZSBWZXJ2aWVy Ok1BSUxUTzpQaWVycmUtQW50b2luZV9WZXJ2aWVyQHN5bWFudGVjLmNvbQ0KQVRURU5ERUU7Uk9M RT1PUFQtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj1UaW1v dGh5IEpvDQogbmVzOk1BSUxUTzp0aW0uam9uZXNAZm9yZXNjb3V0LmNvbQ0KQVRURU5ERUU7Uk9M RT1PUFQtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj1tcmFu Z2FAZ21hDQogaWwuY29tOk1BSUxUTzptcmFuZ2FAZ21haWwuY29tDQpBVFRFTkRFRTtST0xFPU9Q VC1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPW1vbnRlbXVy cm8NCiAubWljaGFlbEBnbWFpbC5jb206TUFJTFRPOm1vbnRlbXVycm8ubWljaGFlbEBnbWFpbC5j b20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtS U1ZQPVRSVUU7Q049TWljaGFlbCBCYQ0KIHJ0bGluZzpNQUlMVE86TWljaGFlbC5CYXJ0bGluZ0Bh cm0uY29tDQpBVFRFTkRFRTtST0xFPU9QVC1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJ T047UlNWUD1UUlVFO0NOPUpvIFdsb3R6a2ENCiA6TUFJTFRPOmpvQHBhdHRvbi5jb20NCkFUVEVO REVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7 Q049UGV0cm9zIEVmcw0KIHRhdGhvcG91bG9zOk1BSUxUTzpQZXRyb3NfRWZzdGF0aG9wb3Vsb3NA c3ltYW50ZWMuY29tDQpBVFRFTkRFRTtST0xFPU9QVC1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVE Uy1BQ1RJT047UlNWUD1UUlVFO0NOPXBkZW1lc3RpY2gNCiBhc0BnbWFpbC5jb206TUFJTFRPOnBk ZW1lc3RpY2hhc0BnbWFpbC5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRT VEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049UGF1bCBEdWZmeQ0KICAocGFkdWZmeSk6TUFJ TFRPOnBhZHVmZnlAY2lzY28uY29tDQpBVFRFTkRFRTtST0xFPU9QVC1QQVJUSUNJUEFOVDtQQVJU U1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPSJCYXJrZXIsIFdpDQogbGxpYW0gQy4gKEFz c29jKSI6TUFJTFRPOndpbGxpYW0uYmFya2VyQG5pc3QuZ292DQpBVFRFTkRFRTtST0xFPU9QVC1Q QVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPVN1c2FudGEgTmEN CiBuZGE6TUFJTFRPOlN1c2FudGFfTmFuZGFAc3ltYW50ZWMuY29tDQpBVFRFTkRFRTtST0xFPU9Q VC1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPSJTeW1pbmd0 b24sDQogIFN1c2FuIEYuIjpNQUlMVE86c3VzYW5AbWl0cmUub3JnDQpBVFRFTkRFRTtST0xFPU9Q VC1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPU5hZ2VuZHJh IEsNCiB1bWFyIE5haW5hciAobmFpa3VtYXIpOk1BSUxUTzpuYWlrdW1hckBjaXNjby5jb20NCkFU VEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRS VUU7Q049IldhdHJvYnNraSwNCiAgUGF1bCAoQ3RyKSI6TUFJTFRPOnBhdWwud2F0cm9ic2tpQG5p c3QuZ292DQpBVFRFTkRFRTtST0xFPU9QVC1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1BQ1RJ T047UlNWUD1UUlVFO0NOPVJhbmR5IEFybXMNCiB0cm9uZyAoT1BDKTpNQUlMVE86cmFuZHkuYXJt c3Ryb25nQG9wY2ZvdW5kYXRpb24ub3JnDQpBVFRFTkRFRTtST0xFPU9QVC1QQVJUSUNJUEFOVDtQ QVJUU1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPSJXZXJuZXIsIFRoDQogb21hcyI6TUFJ TFRPOnRob21hcy13ZXJuZXJAc2llbWVucy5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQ QU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049IkNhcHBhbGxpLCANCiBUaW0g KEFydWJhIFNlY3VyaXR5KSI6TUFJTFRPOnRpbWNAaHBlLmNvbQ0KQVRURU5ERUU7Uk9MRT1PUFQt UEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj1FcmlrIE5vcmRt DQogYXJrOk1BSUxUTzplcmlrQHplZGVkYS5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQ QU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049U2NoZWxsZW5iYQ0KIHVtIEF1 cmVsaW8gUnViZW4gRGFyaW8gKHNjbm0pOk1BSUxUTzpzY25tQHpoYXcuY2gNCkFUVEVOREVFO1JP TEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049YWJh eWthbEBnbA0KIG9iYWxjeWJlcmFsbGlhbmNlLm9yZzpNQUlMVE86YWJheWthbEBnbG9iYWxjeWJl cmFsbGlhbmNlLm9yZw0KQVRURU5ERUU7Uk9MRT1PUFQtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVF RFMtQUNUSU9OO1JTVlA9VFJVRTtDTj0iTW9udGdvbWVyeQ0KICwgRG91Z2xhcyAoRmVkKSI6TUFJ TFRPOmRvdWdtQG5pc3QuZ292DQpBVFRFTkRFRTtST0xFPU9QVC1QQVJUSUNJUEFOVDtQQVJUU1RB VD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPVBldGUgQmVhbCANCiAocGJlYWwpOk1BSUxUTzpw YmVhbEBjaXNjby5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRTVEFUPU5F RURTLUFDVElPTjtSU1ZQPVRSVUU7Q049QWxsYXVraWsgQQ0KIGJoaXNoZWs6TUFJTFRPOkFsbGF1 a2lrLkFiaGlzaGVrQGFybS5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5UO1BBUlRT VEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049UGV0ZXIgUm9tbg0KIGVzcyAocHJvbW5lc3Mp Ok1BSUxUTzpwcm9tbmVzc0BjaXNjby5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5U O1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049Y2Fib2NhYm9AZw0KIG1haWwuY29t Ok1BSUxUTzpjYWJvY2Fib0BnbWFpbC5jb20NCkFUVEVOREVFO1JPTEU9T1BULVBBUlRJQ0lQQU5U O1BBUlRTVEFUPU5FRURTLUFDVElPTjtSU1ZQPVRSVUU7Q049WXVuIFNoZW46TQ0KIEFJTFRPOll1 bl9TaGVuQHN5bWFudGVjLmNvbQ0KQVRURU5ERUU7Uk9MRT1PUFQtUEFSVElDSVBBTlQ7UEFSVFNU QVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJVRTtDTj1EYXJzaGFrIFRoDQogYWtvcmU6TUFJTFRPOmQu dGhha29yZUBjYWJsZWxhYnMuY29tDQpBVFRFTkRFRTtST0xFPU9QVC1QQVJUSUNJUEFOVDtQQVJU U1RBVD1ORUVEUy1BQ1RJT047UlNWUD1UUlVFO0NOPVJvYiBDYW50dToNCiBNQUlMVE86UkNhbnR1 QGN0aWEub3JnDQpBVFRFTkRFRTtST0xFPU9QVC1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVEUy1B Q1RJT047UlNWUD1UUlVFO0NOPVdhc3NpbSBIYWQNCiBkYWQ6TUFJTFRPOndhc3NpbS5oYWRkYWRA ZXJpY3Nzb24uY29tDQpBVFRFTkRFRTtST0xFPU9QVC1QQVJUSUNJUEFOVDtQQVJUU1RBVD1ORUVE Uy1BQ1RJT047UlNWUD1UUlVFO0NOPSJCYWwsIEthbGxvDQogbGEiOk1BSUxUTzpLLkJhbEBvc3Jh bS5jb20NCkRFU0NSSVBUSU9OO0xBTkdVQUdFPWVuLVVTOlBsZWFzZSBob2xkIHRoaXMgdGltZSBm b3IgdGhlIG9uYm9hcmRpbmcgZGlzY3Vzcw0KIGlvbiAoSSdtIG9uIHZhY2F0aW9uIGFuZCBhbSBz ZW5kaW5nIHRoaXMgYSBiaXQgZWFybHkpLiAgVGhpcyBpcyBhbiBJb1QgT25iDQogb2FyZGluZyB2 aXJ0dWFsIG1lZXRpbmcuXG5cblRlbnRhdGl2ZSBBZ2VuZGE6XG5cbiAtIE9QQyBVQSB1c2UgY2Fz ZVxuIC0gdXANCiBkYXRlcyBvbiBkcmFmdHNcbiAtIEFPQlxuXG5cblxuXG5NZWV0aW5nIEluZm9y bWF0aW9uXG5cbk1lZXRpbmcgbGluazpcbiAgIA0KICBodHRwczovL2Npc2NvLndlYmV4LmNvbS9j aXNjby9qLnBocD9NVElEPW0xNmY4ZTBkMTJmNmQxMmMzYzM3OTg0YzczZjIwZWZiDQogOFxuTWVl dGluZyBudW1iZXI6XG4gICAgMjA3IDA0NiAxMjhcblBhc3N3b3JkOlxuICAgIGMzd3Z1czN4ICgy Mzk4ODczOSBmcm8NCiBtIHBob25lcylcbkhvc3Qga2V5OlxuICAgIDczNTQwNCBcblxuTW9yZSB3 YXlzIHRvIGpvaW5cblxuSm9pbiBieSB2aWRlbyBzeQ0KIHN0ZW1cbiAgICBEaWFsIDIwNzA0NjEy OEBjaXNjby53ZWJleC5jb21cbiAgICBZb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuDQogNjgg YW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuXG5cbkpvaW4gYnkgcGhvbmVcbiAgICArMS04 NjYtNDMyLTk5MDMgQ2ENCiBsbC1pbiB0b2xsLWZyZWUgbnVtYmVyIChVUy9DYW5hZGEpXG4gICAg KzEtNDA4LTUyNS02ODAwIENhbGwtaW4gbnVtYmVyIChVUw0KIC9DYW5hZGEpXG4gICAgQWNjZXNz IGNvZGU6IDIwNyAwNDYgMTI4XG5cbiAgICBHbG9iYWwgY2FsbC1pbiBudW1iZXJzIHwgVG9sDQog bC1mcmVlIGNhbGxpbmcgcmVzdHJpY3Rpb25zIA0KVUlEOkZDMjY2MTNDLTkwOTYtNEQwNC05Qjgw LTZCQTg3N0EyN0EyQQ0KU1VNTUFSWTtMQU5HVUFHRT1lbi1VUzpJb1QgT25ib2FyZGluZyBWaXJ0 dWFsIE1lZXRpbmcNCkRUU1RBUlQ7VFpJRD1XLiBFdXJvcGUgU3RhbmRhcmQgVGltZToyMDE5MDgy OVQxNzAwMDANCkRURU5EO1RaSUQ9Vy4gRXVyb3BlIFN0YW5kYXJkIFRpbWU6MjAxOTA4MjlUMTgw MDAwDQpDTEFTUzpQVUJMSUMNClBSSU9SSVRZOjUNCkRUU1RBTVA6MjAxOTA4MjlUMTQ1MDQwWg0K VFJBTlNQOk9QQVFVRQ0KU1RBVFVTOkNPTkZJUk1FRA0KU0VRVUVOQ0U6NA0KTE9DQVRJT047TEFO R1VBR0U9ZW4tVVM6V2ViRXg6IHNlZSBiZWxvdw0KWC1NSUNST1NPRlQtQ0RPLUFQUFQtU0VRVUVO Q0U6NA0KWC1NSUNST1NPRlQtQ0RPLU9XTkVSQVBQVElEOjIxMTc2MTY0ODMNClgtTUlDUk9TT0ZU LUNETy1CVVNZU1RBVFVTOlRFTlRBVElWRQ0KWC1NSUNST1NPRlQtQ0RPLUlOVEVOREVEU1RBVFVT OkJVU1kNClgtTUlDUk9TT0ZULUNETy1BTExEQVlFVkVOVDpGQUxTRQ0KWC1NSUNST1NPRlQtQ0RP LUlNUE9SVEFOQ0U6MQ0KWC1NSUNST1NPRlQtQ0RPLUlOU1RUWVBFOjANClgtTUlDUk9TT0ZULURP Tk9URk9SV0FSRE1FRVRJTkc6RkFMU0UNClgtTUlDUk9TT0ZULURJU0FMTE9XLUNPVU5URVI6RkFM U0UNClgtTUlDUk9TT0ZULUxPQ0FUSU9ORElTUExBWU5BTUU6V2ViRXg6IHNlZSBiZWxvdw0KWC1N SUNST1NPRlQtTE9DQVRJT05TT1VSQ0U6Tm9uZQ0KWC1NSUNST1NPRlQtTE9DQVRJT05TOlt7IkRp c3BsYXlOYW1lIjoiV2ViRXg6IHNlZSBiZWxvdyJcLCJMb2NhdGlvbkFubm90YXRpDQogb24iOiIi XCwiTG9jYXRpb25VcmkiOiIiXCwiTG9jYXRpb25TdHJlZXQiOiIiXCwiTG9jYXRpb25DaXR5Ijoi IlwsIkxvY2F0aW8NCiBuU3RhdGUiOiIiXCwiTG9jYXRpb25Db3VudHJ5IjoiIlwsIkxvY2F0aW9u UG9zdGFsQ29kZSI6IiJcLCJMb2NhdGlvbkZ1bGxBZA0KIGRyZXNzIjoiIn1dDQpFTkQ6VkVWRU5U DQpFTkQ6VkNBTEVOREFSDQo= --_002_BYAPR11MB3814E179835623A9CCDF03A9BFA20BYAPR11MB3814namp_-- From nobody Thu Aug 29 09:33:45 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2868120131; Thu, 29 Aug 2019 09:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOHxbwhtaQws; Thu, 29 Aug 2019 09:33:35 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561E21200B8; Thu, 29 Aug 2019 09:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11495; q=dns/txt; s=iport; t=1567096414; x=1568306014; h=from:mime-version:subject:message-id:references:to:date; bh=64ZuEAtZDG03RYezwmPZvJLnAtxyLhZ+EtKFf9zVzsg=; b=ecWEP4Vo8duXgdOUGlY8lpfdQYx+hME5hDf+23HFsrr5uftR8nLmPNn3 /C2Z5Q8sXUxB1JpNphYpQEkDxzk8Wf18Q65x4LSNbAy7MNqdXgHgl5rY1 HPGl7Sz7Voqg6+q5rAJhkOTbqnR9Qndvu7YsR+JXWK9UZYTBBa4/DaR8e w=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAADL/Wdd/xbLJq1MGhkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVMEAQEBAQELAYEVAYFuUyASKoQhiBxgiBqHPotQgwG?= =?us-ascii?q?DCRSBZwIHAQEBCQMBASUKAQGEPwKCfDQJDgIDCAEBBAEBAQIBBgRthS4MhUo?= =?us-ascii?q?BAQQBI1sLHAMBAhkMBgICRgcCCAcSgyIBgXsPDzmqe4Eyg0eGbAoGgTQBgVC?= =?us-ascii?q?KPoF/gREnH4E3Zy4+gQQBgVwEGIEUARIBPy+CPDKCJgSMcIhOlkoJgiCCJoE?= =?us-ascii?q?RgzeNZRuCMoc0g3WFDIE1hEGNCWaHb405gw8CBAYFAhWBUDhncTMaCBsVZQG?= =?us-ascii?q?CQT6CEAwLFYM6ilU9AzABCY0oFYIwAQE?= X-IronPort-AV: E=Sophos;i="5.64,444,1559520000"; d="asc'?scan'208,217";a="16122951" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Aug 2019 16:33:30 +0000 Received: from [10.61.200.74] ([10.61.200.74]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x7TGXT97026874 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Aug 2019 16:33:30 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_4DC55F3C-8E8D-4F62-8774-E6980E6088B7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <01937C69-828E-47AD-A29A-96E80A53DA07@cisco.com> References: <324664390.245511567096259339.JavaMail.nobody@rsj6rmd001.webex.com> To: iot-onboarding@ietf.org, anima@ietf.org Date: Thu, 29 Aug 2019 18:33:27 +0200 X-Mailer: Apple Mail (2.3445.104.11) X-Outbound-SMTP-Client: 10.61.200.74, [10.61.200.74] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: [Anima] Fwd: Your Webex recording is available for viewing: IoT Onboarding Meeting-20190829 1513-1 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 16:33:37 -0000 --Apple-Mail=_4DC55F3C-8E8D-4F62-8774-E6980E6088B7 Content-Type: multipart/alternative; boundary="Apple-Mail=_F9D52F60-D8E9-4434-BC02-339DECA07F7A" --Apple-Mail=_F9D52F60-D8E9-4434-BC02-339DECA07F7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone, and thanks for joining. Those people who wish to listen to = the recording (it started a bit after the meeting), please see attached. = I=E2=80=99ll summarize the meeting in a separate email. Eliot > Begin forwarded message: >=20 > From: > Subject: Your Webex recording is available for viewing: IoT Onboarding = Meeting-20190829 1513-1 > Date: 29 August 2019 at 18:30:59 CEST > To: > Reply-To: >=20 > Hi Eliot Lear, > Your recording is now available on your Webex site. >=20 > IoT Onboarding Meeting-20190829 1513-1 > Thursday, August 29, 2019 > 5:13 pm | Europe Summer Time (Amsterdam, GMT+02:00) >=20 > Play recording = (47 min 54 sec) > Recording password: fRJsavS4 >=20 > You can forward this message to others to allow them to play back the = recording. >=20 --Apple-Mail=_F9D52F60-D8E9-4434-BC02-339DECA07F7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = everyone, and thanks for joining.  Those people who wish to listen = to the recording (it started a bit after the meeting), please see = attached.  I=E2=80=99ll summarize the meeting in a separate = email.

Eliot

Begin forwarded message:

From: = <messenger@webex.com>
Subject: = Your Webex = recording is available for viewing: IoT Onboarding Meeting-20190829 = 1513-1
Date: = 29 August 2019 at 18:30:59 = CEST
To: = <elear@cisco.com>
Reply-To: = <messenger@webex.com>

=
Hi Eliot = Lear,
Your recording is now available on your Webex = site.
 
5:13 pm  |  Europe Summer Time = (Amsterdam, GMT+02:00)
IoT = Onboarding Meeting-20190829 1513-1
Thursday, August 29, = 2019
 
Play recording (47 min 54 = sec)
Recording password: fRJsavS4
 
You can forward this message to others to = allow them to play back the recording.
 

= --Apple-Mail=_F9D52F60-D8E9-4434-BC02-339DECA07F7A-- --Apple-Mail=_4DC55F3C-8E8D-4F62-8774-E6980E6088B7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iF0EARECAB0WIQTgo4LlIIJ5lIBumWpugA9nE248uAUCXWf+VwAKCRBugA9nE248 uOcMAKClvNAum/jwCvVtulN3fSslLxaB8wCeOATWzTehE+W2cRfPehRsz1YecOY= =/TKi -----END PGP SIGNATURE----- --Apple-Mail=_4DC55F3C-8E8D-4F62-8774-E6980E6088B7-- From nobody Thu Aug 29 10:30:58 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFD7120A7F; Thu, 29 Aug 2019 10:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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=TuSA3mWg; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=pvu/JVP8 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llWJslk4fzGr; Thu, 29 Aug 2019 10:30:41 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B239120A7D; Thu, 29 Aug 2019 10:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26198; q=dns/txt; s=iport; t=1567099841; x=1568309441; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=0CEPSa9vNdDSXJgvgy/FFzh7PSvKT+W0EMwIxdz48VQ=; b=TuSA3mWgy8od3d8tb3J+UxrM4zIUW69fUTqE+RRY/bkhsaCbXiNBzvzx D5KKaV18crl18dWXJjqBW2tnZAugneW2/H0q5/qAkGJeXecnsKmiMH6Fk a3jrOtxN/oYlkJLgfxJNUZI9gI+f2GhDvgr1+7SJkDOl7j+s3TTdAY6Cd E=; IronPort-PHdr: =?us-ascii?q?9a23=3AsozlShFBHv8nMUizjl+t4J1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w3Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efnkdS03GOxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAB0C2hd/49dJa1MGhkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVMEAQEBAQELAYEVL1ADbVYgBAsqCoQXg0cDhFKGH02?= =?us-ascii?q?CD5YPgVuBLhSBEANUCQEBAQwBASUIAgEBhD8CF4JCIzQJDgIDCAEBBAEBAQI?= =?us-ascii?q?BBgRthS4MhUoBAQEBAxIRChMBATgPAgEIEQMBAQEZCAMBAwMCAgIwFAkIAgQ?= =?us-ascii?q?BEggagwGBHU0DHQEOOaAqAoE4iGFzgTKCfAEBBURyAoNRGIIWAwaBNAGLdhi?= =?us-ascii?q?BQD+BEUaBN2cuPoEEAYFcAQECAReBFAESASEVCQ0JGYI8MoImjDk7CYIphRq?= =?us-ascii?q?XTAkCgh6Gbo4AgjKHNIo2hEGNCWaHb5BIAgQCBAUCDgEBBYFQOGdxcBWDJ4J?= =?us-ascii?q?CDBcVgzqFFIU/cgEJgR+MCRWBDQGBIgEB?= X-IronPort-AV: E=Sophos;i="5.64,444,1559520000"; d="scan'208,217";a="316230709" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Aug 2019 17:30:26 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x7THUP0J005104 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 29 Aug 2019 17:30:25 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 12:30:25 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 29 Aug 2019 12:30:24 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 29 Aug 2019 12:30:24 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S4sQgS3SQRGV52bZeJaVqrt2laLeCOSabcF4nSx8dzmDPCZhMJ9p8QFx+ZsyZyFJ2mKU7nbwOl5rpjbuJ9VYuS3V/rYhyvYTHbmdRgovhKwnrXlbzYWCMQ+deQKTuSKFeAWq+B4ZxiCsyb75mwEBjHv5GetH3C/2JYfIxzRm9P+dRm8spWBD5H2RngqNLVut7xMQeYYA5tBemtGDvqtUiRL8R0LrWNBGU5QBoD1N5q2eMni4pZTN5UbvsxVa0oeY55Cd+PnCihRzWM8gqwD9icBiPf7GI87yDyjVtnpmd1PTOrVH09Xxk5H4Fme+lGfq5YL8C+E7GepUrEQnaoJ7Eg== 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=0CEPSa9vNdDSXJgvgy/FFzh7PSvKT+W0EMwIxdz48VQ=; b=T6BLiTEtbzlZEkRR212sEoeMiHOVrEfp14IW7PEYDgHb4+/UCfJ0xylfXus9PDfNH+8xBnCDdQ+W9MtqAvVeU2Q1oqI8yOXpVUhuc4w+YyiO6VE5td9qIGJNw//Vn0ZGvFeLFNsvbPF7CyQ3koJP/fCaIQN9yF+cnTPaiDhtgF726bm6lCxzk/wt8TYOUZyA9LYenPKKBMIwzxHMI5ZsP0WxCuThn08cSbPgKlc1fWRsRrKN4sO07knNhbOo6h2FVdysfbnklbYuJ2Gq9hVMZ9/eGXoX0PUU5Q3CnWzDNqsi4kESFucwMBsVEjCEakXDCwGZjciSgRAl6Z35ID1oOw== 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=0CEPSa9vNdDSXJgvgy/FFzh7PSvKT+W0EMwIxdz48VQ=; b=pvu/JVP8OWGZ+t8DtS1Sh2fWI0TL/hLh16Hx6uAV/PnP8XXkBTbYLcyFZZuHVpFGDYfXsTN+G8R09ZTGGxnsJGFYDcXGpq3Wk11kK3E5jt9qK5lOICdBvKqFltj85AUrulAOx+LQsxRHF5D3PxoNLgkC5to8bGGwji0VDaqAOxk= Received: from CY4PR1101MB2278.namprd11.prod.outlook.com (10.172.76.13) by CY4PR1101MB2120.namprd11.prod.outlook.com (10.172.79.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2220.19; Thu, 29 Aug 2019 17:30:23 +0000 Received: from CY4PR1101MB2278.namprd11.prod.outlook.com ([fe80::9098:374:9205:d0c4]) by CY4PR1101MB2278.namprd11.prod.outlook.com ([fe80::9098:374:9205:d0c4%5]) with mapi id 15.20.2220.013; Thu, 29 Aug 2019 17:30:23 +0000 From: "Owen Friel (ofriel)" To: Eliot Lear , "iot-onboarding@ietf.org" , "anima@ietf.org" Thread-Topic: [Iot-onboarding] Fwd: Your Webex recording is available for viewing: IoT Onboarding Meeting-20190829 1513-1 Thread-Index: AQHVXoeZnHGUErJ9c0KGc/3yGgIqyKcSX7cA Date: Thu, 29 Aug 2019 17:30:23 +0000 Message-ID: References: <324664390.245511567096259339.JavaMail.nobody@rsj6rmd001.webex.com> <01937C69-828E-47AD-A29A-96E80A53DA07@cisco.com> In-Reply-To: <01937C69-828E-47AD-A29A-96E80A53DA07@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ofriel@cisco.com; x-originating-ip: [173.38.220.47] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 06e866a3-9537-47ae-7156-08d72ca692b2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600166)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:CY4PR1101MB2120; x-ms-traffictypediagnostic: CY4PR1101MB2120: x-ms-exchange-purlcount: 6 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(346002)(39860400002)(366004)(396003)(199004)(189003)(53754006)(7736002)(256004)(76116006)(316002)(6506007)(5660300002)(966005)(478600001)(71200400001)(71190400001)(2501003)(2906002)(52536014)(55016002)(66946007)(8936002)(66446008)(606006)(66476007)(64756008)(66556008)(19627405001)(74316002)(486006)(66066001)(16799955002)(33656002)(81156014)(2201001)(26005)(5024004)(76176011)(11346002)(7696005)(86362001)(14444005)(6246003)(99286004)(476003)(790700001)(6116002)(3846002)(229853002)(110136005)(9686003)(25786009)(186003)(6306002)(236005)(54896002)(53546011)(6436002)(446003)(53936002)(14454004)(102836004)(8676002)(81166006)(450100002)(24704002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1101MB2120; H:CY4PR1101MB2278.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: HuZZIQOiu3FAoFmIKQKkYFt7vZYHtrcfXugK/Wr6C8SVzdvMq6H4LywM7CZYiFOrj3P/dQo/e123TJCeiijnB7uaRhaauvd2Cu+s8D6kHxnrhw8+Dh5qxXocOjQRWDo9/NG4U90+kL58jOrNIK9XljoGLB0Em8LxtkD+GTRP44HWWSjNTmP9N520NMn1v8AKI+hfmAKktJSf97OOubOdBUgvbV831ltDMw6lBgWG/zkmngFMUtJ7rVGXvGo8terujnHhJQr/8amrEDPsZ/HeIXZVRX5Ni2W6UTkG4FbF0rq1zyfMpbtZlbR+k9cXaSLVsvT+mPMufLAt5r0a3x5ql+GLxNN0qEHy3s96VZziqBseKArGxIZllluznt9fTpE33pYSqY/Rs6wswJXyoirONFx57wni0HOJEdQgosP1Zj4= Content-Type: multipart/alternative; boundary="_000_CY4PR1101MB22784BC63339ACBCB922768EDBA20CY4PR1101MB2278_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 06e866a3-9537-47ae-7156-08d72ca692b2 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2019 17:30:23.1896 (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: OUmzZ9HMzQSo65HsG2N+cnOPsPk9S66aavbmCuB4x8cDNcpsRWFXQMYW4FLA1lKR6u6ikX/5O8+P+dl2mvhGZg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1101MB2120 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Anima] [Iot-onboarding] Fwd: Your Webex recording is available for viewing: IoT Onboarding Meeting-20190829 1513-1 X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Aug 2019 17:30:51 -0000 --_000_CY4PR1101MB22784BC63339ACBCB922768EDBA20CY4PR1101MB2278_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgcmVxdWVzdGVkOg0KDQpodHRwczovL2dpdGh1Yi5jb20vdXByb3MvYnJza2ktY2xvdWQvYmxv Yi9tYXN0ZXIvZHJhZnQtZnJpZWwtYW5pbWEtYnJza2ktY2xvdWQubWQgaXMgbm90IHB1Ymxpc2hl ZCB5ZXQuIEl0IHByb3ZpZGVzIG1vcmUgZGV0YWlscyBvbiBob3cgYSBCUlNLSSB2ZW5kb3IgZGVm YXVsdCBjbG91ZCByZWdpc3RyYXIgd29ya3MsIGFuZCBsaXN0cyBhIGZldyBvcHRpb25zIGZvciBy ZWRpcmVjdCBmcm9tIGNsb3VkIHRvIHByZW0uIFNvbWUgb2YgdGhlIG9wdGlvbnMgYWxzbyByZXF1 aXJlIHZvdWNoZXIgZXh0ZW5zaW9ucyB0byByZXR1cm4gZG9tYWlucy9ETlMtSURzLg0KDQpodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZnJpZWwtYWNtZS1pbnRlZ3JhdGlvbnMtMDEg Y292ZXJzIGhvdyBBQ01FIGNvdWxkIGJlIHVzZWQgd2l0aCBib3RoIEJSU0tJIGFuZCBURUFQIGZv ciBpc3N1aW5nIExEZXZJRHMsIGFuZCBpdCBhbHNvIGRvY3VtZW50cyBob3cgQUNNRSBjYW4gYmUg dXNlZCB0byBpc3N1ZSBzdWJkb21haW4gY2VydHMgd2l0aG91dCBleHBsaWNpdCBzdWJkb21haW4g b3duZXJzaGlwIHByb29mcywgd2hpY2ggaXMgYSBuaWNlIG9wdGltaXNhdGlvbiBmb3IgaXNzdWlu ZyBsYXJnZSBudW1iZXJzIG9mIExEZXZJRHMuIFRoZSBzdWJkb21haW4gcGFydCBpcyBpbiB0aGUg cHJvY2VzcyBvZiBiZWluZyBicm9rZW4gb3V0IGludG8gYSBzZXBhcmF0ZSBkb2M6IGh0dHBzOi8v Z2l0aHViLmNvbS91cHJvcy9hY21lLXN1YmRvbWFpbnMvYmxvYi9tYXN0ZXIvZHJhZnQtZnJpZWwt YWNtZS1zdWJkb21haW5zLm1kIGJ1dCB0aGF04oCZcyBub3QgcHVibGlzaGVkIHlldCBlaXRoZXIu DQoNCg0KRnJvbTogSW90LW9uYm9hcmRpbmcgPGlvdC1vbmJvYXJkaW5nLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBFbGlvdCBMZWFyDQpTZW50OiAyOSBBdWd1c3QgMjAxOSAxNzozMw0K VG86IGlvdC1vbmJvYXJkaW5nQGlldGYub3JnOyBhbmltYUBpZXRmLm9yZw0KU3ViamVjdDogW0lv dC1vbmJvYXJkaW5nXSBGd2Q6IFlvdXIgV2ViZXggcmVjb3JkaW5nIGlzIGF2YWlsYWJsZSBmb3Ig dmlld2luZzogSW9UIE9uYm9hcmRpbmcgTWVldGluZy0yMDE5MDgyOSAxNTEzLTENCg0KSGkgZXZl cnlvbmUsIGFuZCB0aGFua3MgZm9yIGpvaW5pbmcuICBUaG9zZSBwZW9wbGUgd2hvIHdpc2ggdG8g bGlzdGVuIHRvIHRoZSByZWNvcmRpbmcgKGl0IHN0YXJ0ZWQgYSBiaXQgYWZ0ZXIgdGhlIG1lZXRp bmcpLCBwbGVhc2Ugc2VlIGF0dGFjaGVkLiAgSeKAmWxsIHN1bW1hcml6ZSB0aGUgbWVldGluZyBp biBhIHNlcGFyYXRlIGVtYWlsLg0KDQpFbGlvdA0KDQoNCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdl Og0KDQpGcm9tOiA8bWVzc2VuZ2VyQHdlYmV4LmNvbTxtYWlsdG86bWVzc2VuZ2VyQHdlYmV4LmNv bT4+DQpTdWJqZWN0OiBZb3VyIFdlYmV4IHJlY29yZGluZyBpcyBhdmFpbGFibGUgZm9yIHZpZXdp bmc6IElvVCBPbmJvYXJkaW5nIE1lZXRpbmctMjAxOTA4MjkgMTUxMy0xDQpEYXRlOiAyOSBBdWd1 c3QgMjAxOSBhdCAxODozMDo1OSBDRVNUDQpUbzogPGVsZWFyQGNpc2NvLmNvbTxtYWlsdG86ZWxl YXJAY2lzY28uY29tPj4NClJlcGx5LVRvOiA8bWVzc2VuZ2VyQHdlYmV4LmNvbTxtYWlsdG86bWVz c2VuZ2VyQHdlYmV4LmNvbT4+DQoNCkhpIEVsaW90IExlYXIsDQpZb3VyIHJlY29yZGluZyBpcyBu b3cgYXZhaWxhYmxlIG9uIHlvdXIgV2ViZXggc2l0ZS4NCg0KDQoNCklvVCBPbmJvYXJkaW5nIE1l ZXRpbmctMjAxOTA4MjkgMTUxMy0xDQpUaHVyc2RheSwgQXVndXN0IDI5LCAyMDE5DQo1OjEzIHBt ICB8ICBFdXJvcGUgU3VtbWVyIFRpbWUgKEFtc3RlcmRhbSwgR01UKzAyOjAwKQ0KDQoNCg0KUGxh eSByZWNvcmRpbmc8aHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY28vbHNyLnBocD9SQ0lEPWYy ZDY3M2VhMzc0NTQwYTViOWRhZWU4YjgzMTY3MTUwPiAoNDcgbWluIDU0IHNlYykNClJlY29yZGlu ZyBwYXNzd29yZDogZlJKc2F2UzQNCg0KDQoNCllvdSBjYW4gZm9yd2FyZCB0aGlzIG1lc3NhZ2Ug dG8gb3RoZXJzIHRvIGFsbG93IHRoZW0gdG8gcGxheSBiYWNrIHRoZSByZWNvcmRpbmcuDQoNCg0K DQo= --_000_CY4PR1101MB22784BC63339ACBCB922768EDBA20CY4PR1101MB2278_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVsdmV0aWNhIE5ldWUiO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28t c3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9u dC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkFzIHJlcXVlc3RlZDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS91cHJvcy9icnNraS1jbG91ZC9ibG9iL21hc3Rlci9k cmFmdC1mcmllbC1hbmltYS1icnNraS1jbG91ZC5tZCI+aHR0cHM6Ly9naXRodWIuY29tL3Vwcm9z L2Jyc2tpLWNsb3VkL2Jsb2IvbWFzdGVyL2RyYWZ0LWZyaWVsLWFuaW1hLWJyc2tpLWNsb3VkLm1k PC9hPiBpcyBub3QgcHVibGlzaGVkIHlldC4gSXQgcHJvdmlkZXMgbW9yZSBkZXRhaWxzIG9uIGhv dyBhIEJSU0tJDQogdmVuZG9yIGRlZmF1bHQgY2xvdWQgcmVnaXN0cmFyIHdvcmtzLCBhbmQgbGlz dHMgYSBmZXcgb3B0aW9ucyBmb3IgcmVkaXJlY3QgZnJvbSBjbG91ZCB0byBwcmVtLiBTb21lIG9m IHRoZSBvcHRpb25zIGFsc28gcmVxdWlyZSB2b3VjaGVyIGV4dGVuc2lvbnMgdG8gcmV0dXJuIGRv bWFpbnMvRE5TLUlEcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZyaWVsLWFjbWUtaW50ZWdyYXRpb25zLTAxIj5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZnJpZWwtYWNtZS1pbnRlZ3JhdGlvbnMtMDE8 L2E+IGNvdmVycyBob3cgQUNNRSBjb3VsZCBiZSB1c2VkIHdpdGggYm90aCBCUlNLSSBhbmQgVEVB UCBmb3IgaXNzdWluZyBMRGV2SURzLCBhbmQgaXQgYWxzbyBkb2N1bWVudHMgaG93DQogQUNNRSBj YW4gYmUgdXNlZCB0byBpc3N1ZSBzdWJkb21haW4gY2VydHMgd2l0aG91dCBleHBsaWNpdCBzdWJk b21haW4gb3duZXJzaGlwIHByb29mcywgd2hpY2ggaXMgYSBuaWNlIG9wdGltaXNhdGlvbiBmb3Ig aXNzdWluZyBsYXJnZSBudW1iZXJzIG9mIExEZXZJRHMuIFRoZSBzdWJkb21haW4gcGFydCBpcyBp biB0aGUgcHJvY2VzcyBvZiBiZWluZyBicm9rZW4gb3V0IGludG8gYSBzZXBhcmF0ZSBkb2M6DQo8 YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vdXByb3MvYWNtZS1zdWJkb21haW5zL2Jsb2IvbWFz dGVyL2RyYWZ0LWZyaWVsLWFjbWUtc3ViZG9tYWlucy5tZCI+DQpodHRwczovL2dpdGh1Yi5jb20v dXByb3MvYWNtZS1zdWJkb21haW5zL2Jsb2IvbWFzdGVyL2RyYWZ0LWZyaWVsLWFjbWUtc3ViZG9t YWlucy5tZDwvYT4gYnV0IHRoYXTigJlzIG5vdCBwdWJsaXNoZWQgeWV0IGVpdGhlci48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxh bmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBJb3Qtb25ib2Fy ZGluZyAmbHQ7aW90LW9uYm9hcmRpbmctYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFs ZiBPZiA8L2I+RWxpb3QgTGVhcjxicj4NCjxiPlNlbnQ6PC9iPiAyOSBBdWd1c3QgMjAxOSAxNzoz Mzxicj4NCjxiPlRvOjwvYj4gaW90LW9uYm9hcmRpbmdAaWV0Zi5vcmc7IGFuaW1hQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtJb3Qtb25ib2FyZGluZ10gRndkOiBZb3VyIFdlYmV4IHJl Y29yZGluZyBpcyBhdmFpbGFibGUgZm9yIHZpZXdpbmc6IElvVCBPbmJvYXJkaW5nIE1lZXRpbmct MjAxOTA4MjkgMTUxMy0xPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGkgZXZlcnlvbmUsIGFuZCB0aGFua3MgZm9yIGpvaW5pbmcuICZuYnNwO1Rob3NlIHBl b3BsZSB3aG8gd2lzaCB0byBsaXN0ZW4gdG8gdGhlIHJlY29yZGluZyAoaXQgc3RhcnRlZCBhIGJp dCBhZnRlciB0aGUgbWVldGluZyksIHBsZWFzZSBzZWUgYXR0YWNoZWQuICZuYnNwO0nigJlsbCBz dW1tYXJpemUgdGhlIG1lZXRpbmcgaW4gYSBzZXBhcmF0ZSBlbWFpbC48bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVsaW90PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+Jmx0OzxhIGhyZWY9 Im1haWx0bzptZXNzZW5nZXJAd2ViZXguY29tIj5tZXNzZW5nZXJAd2ViZXguY29tPC9hPiZndDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsi PlN1YmplY3Q6IFlvdXIgV2ViZXggcmVjb3JkaW5nIGlzIGF2YWlsYWJsZSBmb3Igdmlld2luZzog SW9UIE9uYm9hcmRpbmcgTWVldGluZy0yMDE5MDgyOSAxNTEzLTE8L3NwYW4+PC9iPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5EYXRlOiA8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+ MjkgQXVndXN0IDIwMTkgYXQgMTg6MzA6NTkgQ0VTVDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+VG86IDwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij4mbHQ7PGEgaHJlZj0i bWFpbHRvOmVsZWFyQGNpc2NvLmNvbSI+ZWxlYXJAY2lzY28uY29tPC9hPiZndDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPlJlcGx5LVRv OiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBO ZXVlJnF1b3Q7Ij4mbHQ7PGEgaHJlZj0ibWFpbHRvOm1lc3NlbmdlckB3ZWJleC5jb20iPm1lc3Nl bmdlckB3ZWJleC5jb208L2E+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHRhYmxlIGNs YXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGluZz0iMCIgYWxpZ249Imxl ZnQiIHdpZHRoPSIxMDAlIiBzdHlsZT0id2lkdGg6MTAwLjAlO2JvcmRlci1zcGFjaW5nOiAwcHg7 bWluLXdpZHRoOiAyNzlweCAhaW1wb3J0YW50O2NhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7b3Jw aGFuczogYXV0bzt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjx0Ym9keT4N Cjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzozLjc1cHQgMGNtIDBjbSAwY207d29yZC13cmFwOiBi cmVhay13b3JkIj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2Vs bHBhZGRpbmc9IjAiIGFsaWduPSJsZWZ0IiB3aWR0aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1 cHQ7bWFyZ2luLWxlZnQ6My43NXB0O3dvcmQtd3JhcDogYnJlYWstd29yZCI+DQo8dGJvZHk+DQo8 dHI+DQo8dGQgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtib3Jk ZXItc3BhY2luZzogMHB4O21pbi13aWR0aDogMjc5cHggIWltcG9ydGFudCI+DQo8dGFibGUgY2xh c3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNTI1 IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQ7d29yZC13cmFwOiBicmVhay13b3JkIj4NCjx0Ym9keT4N Cjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207Ym9yZGVyLXNwYWNpbmc6 IDBweDttaW4td2lkdGg6IDI3OXB4ICFpbXBvcnRhbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1m cmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFu Y2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29s dW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzRENEQ0 RCI+SGkgRWxpb3QgTGVhciw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0 cj4NCjx0ZCBzdHlsZT0icGFkZGluZzo3LjVwdCAwY20gMGNtIDBjbTt3b3JkLXdyYXA6IGJyZWFr LXdvcmQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDtt c28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVt ZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNv LWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzRENEQ0RCI+WW91ciByZWNvcmRpbmcgaXMgbm93IGF2 YWlsYWJsZSBvbiB5b3VyIFdlYmV4IHNpdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N CjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNw YWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVy dGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28t aGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxh eTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05v cm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iNTI1IiBzdHlsZT0i d2lkdGg6MzkzLjc1cHQ7Ym9yZGVyLXNwYWNpbmc6IDBweDttaW4td2lkdGg6IDI3OXB4ICFpbXBv cnRhbnQiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0Ij4NCjx0ZCBzdHlsZT0i cGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjE1LjBwdDt3b3JkLXdyYXA6IGJyZWFrLXdv cmQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28t ZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50 LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVs ZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQt ZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1h bmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNv bHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2 NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFibGUgY2xh c3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0aD0iMTAw JSIgc3R5bGU9IndpZHRoOjEwMC4wJTtib3JkZXItc3BhY2luZzogMHB4O21pbi13aWR0aDogMjc5 cHggIWltcG9ydGFudCI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBj bSAwY20gMGNtO3dvcmQtd3JhcDogYnJlYWstd29yZCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZy YW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5j aG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1 bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNEQ0 RDREIj5Jb1QgT25ib2FyZGluZyBNZWV0aW5nLTIwMTkwODI5IDE1MTMtMTwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNEQ0RDREIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0K PC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207d29yZC13cmFw OiBicmVhay13b3JkIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox NS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDtt c28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdy YXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6 ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPlRodXJzZGF5LCBBdWd1c3Qg MjksIDIwMTk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBz dHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207d29yZC13cmFwOiBicmVhay13b3JkIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6 ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFy b3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFu Y2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiM2NjY2NjYiPjU6MTMgcG0mbmJzcDsmbmJzcDt8Jm5ic3A7Jm5ic3A7RXVy b3BlIFN1bW1lciBUaW1lIChBbXN0ZXJkYW0sIEdNVCYjNDM7MDI6MDApPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVs ZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxl bWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9u dGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8dGFi bGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0 aD0iNTI1IiBzdHlsZT0id2lkdGg6MzkzLjc1cHQ7Ym9yZGVyLXNwYWNpbmc6IDBweDttaW4td2lk dGg6IDI3OXB4ICFpbXBvcnRhbnQiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MTUuMHB0 Ij4NCjx0ZCBzdHlsZT0icGFkZGluZzowY20gMGNtIDBjbSAwY207aGVpZ2h0OjE1LjBwdDt3b3Jk LXdyYXA6IGJyZWFrLXdvcmQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVp Z2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4y NXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpw YXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQt cnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2NjY2NiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJh bWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3Vu ZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hv ci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM2NjY2NjY7ZGlzcGxheTpub25lIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjAiIGNlbGxwYWRkaW5n PSIwIiBzdHlsZT0iYm9yZGVyLXNwYWNpbmc6IDBweDttaW4td2lkdGg6IDI3OXB4ICFpbXBvcnRh bnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIGNvbHNwYW49IjIiIHN0eWxlPSJwYWRkaW5nOjBjbSAw Y20gMGNtIDBjbTt3b3JkLXdyYXA6IGJyZWFrLXdvcmQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1m cmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFu Y2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29s dW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzAwQUZG OSI+PGEgaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY28vbHNyLnBocD9SQ0lEPWYy ZDY3M2VhMzc0NTQwYTViOWRhZWU4YjgzMTY3MTUwIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6IzAw QUZGOTt0ZXh0LWRlY29yYXRpb246bm9uZSI+UGxheSByZWNvcmRpbmc8L3NwYW4+PC9iPjwvYT48 L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojNjY2NjY2Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2 NjY2NiI+KDQ3DQogbWluIDU0IHNlYyk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDBBRkY5 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0i cGFkZGluZzowY20gMGNtIDBjbSAwY207d29yZC13cmFwOiBicmVhay13b3JkIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxNS4wcHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7 bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDtt c28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1o b3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM2NjY2NjYiPlJlY29yZGluZyBwYXNzd29yZDogZlJKc2F2UzQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43 NXB0Ij48L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVu dC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50 LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6 Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzY2 NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBj bGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSI1 MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdDtib3JkZXItc3BhY2luZzogMHB4O21pbi13aWR0aDog Mjc5cHggIWltcG9ydGFudCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDo3LjVwdCI+DQo8 dGQgc3R5bGU9InBhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2hlaWdodDo3LjVwdDt3b3JkLXdyYXA6 IGJyZWFrLXdvcmQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saW5lLWhlaWdo dC1hbHQ6Ny41cHQ7bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIu MjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6 cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2NjY2NjYiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0O21zby1lbGVtZW50OmZy YW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91 bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNo b3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojNjY2NjY2O2Rpc3BsYXk6bm9uZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxscGFkZGlu Zz0iMCIgd2lkdGg9IjEwMCUiIHN0eWxlPSJ3aWR0aDoxMDAuMCU7Ym9yZGVyLXNwYWNpbmc6IDBw eDttaW4td2lkdGg6IDI3OXB4ICFpbXBvcnRhbnQiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxl PSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTt3b3JkLXdyYXA6IGJyZWFrLXdvcmQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFt ZTttc28tZWxlbWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5k O21zby1lbGVtZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9y LWhvcml6b250YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzY2NjY2NiI+WW91IGNhbiBmb3J3YXJkIHRoaXMgbWVzc2FnZSB0byBvdGhlcnMg dG8gYWxsb3cgdGhlbSB0byBwbGF5IGJhY2sgdGhlIHJlY29yZGluZy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdDttc28tZWxlbWVudDpmcmFtZTttc28tZWxl bWVudC1mcmFtZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVt ZW50LWFuY2hvci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250 YWw6Y29sdW1uO21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzY2NjY2NjtkaXNwbGF5Om5vbmUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJs ZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRo PSI1MjUiIHN0eWxlPSJ3aWR0aDozOTMuNzVwdDtib3JkZXItc3BhY2luZzogMHB4O21pbi13aWR0 aDogMjc5cHggIWltcG9ydGFudCI+DQo8dGJvZHk+DQo8dHIgc3R5bGU9ImhlaWdodDoxNS4wcHQi Pg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtoZWlnaHQ6MTUuMHB0O3dvcmQt d3JhcDogYnJlYWstd29yZCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTUuMHB0O21zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1 cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBh cmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1y dWxlOmV4YWN0bHkiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNjY2NjY2Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90ZD4N CjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFi bGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_CY4PR1101MB22784BC63339ACBCB922768EDBA20CY4PR1101MB2278_-- From nobody Fri Aug 30 00:46:16 2019 Return-Path: X-Original-To: anima@ietfa.amsl.com Delivered-To: anima@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3663A12006A; Fri, 30 Aug 2019 00:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=mMZPlXGp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=U5eGuYfr Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1HjhRQArdWs; Fri, 30 Aug 2019 00:46:02 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA8C120130; Fri, 30 Aug 2019 00:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17560; q=dns/txt; s=iport; t=1567151161; x=1568360761; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OQ0iAW3u3G3cUaAd3fV09PfVaGFrgy26TxgP78hFv0I=; b=mMZPlXGpK5Etk58zQoxtjB6UCFro5X9E9mNPWiQqV6Th3cBOdX2lkOZn 4c4hdM831hq3KI/dCJYczM/Jb9MGdqQClPqnUMHTDcge18/jZ0xByOHNR /oF1c17571VSlxwMdnaJEpGR1pXk5QN7Jq5/krUYQlBmcs5rVMVIaZSs1 Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AgqlJcxPZdDPZY7HzVAUl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj2Mu/sZC83NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CeBgDa02hd/4wNJK1cChwBAQEEAQE?= =?us-ascii?q?HBAEBgWeBRSQsA21WIAQLKoQhg0cDinKCNyWXa4FCgRADVAkBAQEMAQEjBgQ?= =?us-ascii?q?CAQGBS4J0AheCRCM4EwIDCAEBBAEBAQIBBgRthS4MhUoBAQEDARIREQwBATc?= =?us-ascii?q?BDwIBCBgCAh8HAgICMBUFCwIEDgUigwABgWoDDg8BAgwDoSkCgTiIYXOBMoJ?= =?us-ascii?q?8AQEFgTIBg1YYghYDBoEMKIt3GIFAP4ERJwwTgkw+gmECgSUJAQcLAQ8QF4J?= =?us-ascii?q?0MoImjEEKFgoSgimFPoINhl6OPgkCgh+GcIUHhGeDeBuCMoc0hByKXYM2kUF?= =?us-ascii?q?qkEkCBAIEBQIOAQEFgWchZ3FwFTsqAYJBEw6CIQsBFxWDOoUUhT9yGQGBD4t?= =?us-ascii?q?EgkUBAQ?= X-IronPort-AV: E=Sophos;i="5.64,446,1559520000"; d="scan'208";a="327861905" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Aug 2019 07:45:59 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x7U7jx5C025652 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 30 Aug 2019 07:45:59 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Aug 2019 02:45:58 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 30 Aug 2019 02:45:58 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 30 Aug 2019 02:45:58 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aD7jdrzCywS2QNSBRiQvn06xv3Im1rPgS5r1eQ2S78Y3WoHpmyZiIuqgAI76Ua5fEQGnZCcBKTOWymhO+lB4j/erIHG3cMJuTy9lBqgpnBcSFWB8UDjjsAPqXDY5hssfmxSkc08jZY4OBjAM8e8SebZ7txUGVk4R0ZgiBqeg1xyNZVXfYnUm4Py9FWhGcmisomBusUVqY8uwhs85mRM2B37OrTdFG4F87YZr3b+V/7fQmw6X595nUBRFDVorP896r+SQrybv4ppBDUOC1lxv07QFqJjTW1MQddFv+TQCOXCzCfcSYHhycaUStO9kMPvKQi8h4OOvu/HQXRTRJuZtVA== 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=OQ0iAW3u3G3cUaAd3fV09PfVaGFrgy26TxgP78hFv0I=; b=WgMaGCLKUgBPIBeMMhkVJueAfrya1uJCLcpf8UyE180RXGSfIVf+EERGBwZdHgmEZSPvZZXdv0/3FHevPE9uB08mpD+Tu3ef8sJ2rh1amtwp5lPWYOH+jdRCEbybNqX/hhD0AxjFh9lsSwP2YJlla50pGp6ibMh8cyNGMf2/iI6DVXlmnyLFMLZf0pgOHZDLnuXt6t1jIVvIV80rYuH+YTsD8q9oNewKfR6zWn3EQFC1mOYFYOglSWpptKp7zct5MVm8R1A1+105Z6svcxVoyUPs2oCN96wli40zSbs2rsLeOpnBVUzHxdkz5Gg3E/5qMVE9cVjW3muuJJe+0jtLFA== 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=OQ0iAW3u3G3cUaAd3fV09PfVaGFrgy26TxgP78hFv0I=; b=U5eGuYfrfJpanp3MCcz1iPUXGHWi1kE0sa17qbbmS1DZurpIaE3gIjLkQDmWpd41huNHqmdYW35D3hbkINfFYAkvFyNRgqD8iccKewyGZ0xOUtxGuugjQrM68/Ek1cwGkyvsoboTOleNjdN6H3x/GPbUTHnp/Es96jmnF1e8k5o= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.19; Fri, 30 Aug 2019 07:45:57 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::d5c4:be39:66cb:449b]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::d5c4:be39:66cb:449b%6]) with mapi id 15.20.2199.021; Fri, 30 Aug 2019 07:45:57 +0000 From: "Eric Vyncke (evyncke)" To: Michael Richardson CC: "draft-ietf-anima-bootstrapping-keyinfra@ietf.org" , "tte+ietf@cs.fau.de" , "anima-chairs@ietf.org" , "The IESG" , "anima@ietf.org" Thread-Topic: =?utf-8?B?W0FuaW1hXSDDiXJpYyBWeW5ja2UncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYt?= =?utf-8?B?YW5pbWEtYm9vdHN0cmFwcGluZy1rZXlpbmZyYS0yMjogKHdpdGggRElTQ1VT?= =?utf-8?Q?S_and_COMMENT)?= Thread-Index: AQHVN1Vq7cBMmcmUUkC9prwP00A3z6cTwMUA Date: Fri, 30 Aug 2019 07:45:57 +0000 Message-ID: <0199051C-4A3E-4850-8DA6-05B97CFA27AD@cisco.com> References: <156275431789.15280.4126747621934962290.idtracker@ietfa.amsl.com> <16753.1562786791@localhost> In-Reply-To: <16753.1562786791@localhost> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1c.0.190812 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:600f:3a1b:883:bc2d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bedac0c5-a349-471e-06ce-08d72d1e1836 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4144; x-ms-traffictypediagnostic: MN2PR11MB4144: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:1060; x-forefront-prvs: 0145758B1D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(376002)(396003)(366004)(39850400004)(189003)(199004)(40224003)(51444003)(2906002)(966005)(5660300002)(46003)(476003)(2616005)(86362001)(11346002)(486006)(446003)(76176011)(99286004)(71200400001)(71190400001)(30864003)(186003)(6506007)(14454004)(76116006)(91956017)(478600001)(64756008)(66574012)(102836004)(66446008)(66476007)(66556008)(66946007)(229853002)(6436002)(6246003)(8936002)(6486002)(81166006)(81156014)(54906003)(316002)(256004)(58126008)(224303003)(36756003)(14444005)(33656002)(305945005)(7736002)(6512007)(25786009)(4326008)(6306002)(6116002)(53936002)(21314003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4144; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: e4MTiyg26NXS6EUEFygIKHOb95r6tZLmYu5owHwcTFlRT2QgpisiTqD+Ts3OI0pQncRLobeXmyAD33cusaYHn8rj5PO1WoWGNxj6JM1SlqfnAgHyKWxzRgVHp+i4ImrDja5Mp3XF9mDvFEkNTwyR4BbuldM7gwKy+vgiuvMrVeZQh/YzMvDpRLddrO3orVZF+r874RYaaR9SUj3vP7pdQ3SyMKOh9w30TeTzQRimxxnXMCDD47bj3t8gZ+aLnIM/KC/fEeRfPLsb+j5oF2L+rGhXhXd1WMevh4bX6SFT78tb/8zyCHHNeS8bo/vQHmHFcGHZjJtytywTXdownVEbAuMXsLgDpguksvqV52mt79m+3rh2VqLJCqdqJk6XW8vN8vb0mMG3al3BfiftIpWbcz6ntMa2UheWLKRdIUlcPEo= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bedac0c5-a349-471e-06ce-08d72d1e1836 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2019 07:45:57.3148 (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: 8FIiG3SKdHgWZlGkAsNc70ZHMTjDsgjhrcufMHjggsMygpa+Fzh94rG4DEKSdCcAr/Nd2ipYlVLUkX7jWOqcLQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4144 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [Anima] =?utf-8?q?=C3=89ric_Vyncke=27s_Discuss_on_draft-ietf-ani?= =?utf-8?q?ma-bootstrapping-keyinfra-22=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 07:46:07 -0000 TWljaGFlbA0KDQpTb3JyeSBmb3IgYmVsYXRlZCByZXBseS4uLiBNeSBicmFpbiBzd2l0Y2hlZCBm b2N1cyB0byBJRVRGLTEwNSBhbmQgdGhlbiBob2xpZGF5cyBhbmQgSSBhbSBhZnJhaWQgZmFpbGVk IHRvIHN3aXRjaCBiYWNrIHRvIHlvdXIgZG9jdW1lbnQuDQoNClBsZWFzZSBmaW5kIGJlbG93IHNv bWUgY29tbWVudHMgb24geW91ciBkZXRhaWxlZCByZXBseSB0byBteSBESVNDVVNTZXM6DQotIGxh Y2sgb2YgVExTIHZlcnNpb24sIEkgdW5kZXJzdGFuZCB5b3VyIGNvbW1lbnQuIFlvdSBzdWdnZXN0 aW9uIHRvIGFkZCBzb21lIHRleHQgKGp1c3RpZmljYXRpb24sIGNsYXJpZmljYXRpb24sIC4uLikg aW4gU2VjdGlvbiA1LjEgYWJvdXQgdGhlIFRMUyB2ZXJzaW9uIHdvdWxkIGJlIGEgcGx1cyAoYWxi ZWl0IGEgLTI3IHdvdWxkIGJlIHJlcXVpcmVkKSBidXQgSSBhbSByZW1vdmluZyBteSBESVNDVVNT DQotIHNlY3Rpb24gMi4zLjEgYW5kIHNlcmlhbCBudW1iZXI6IHRoYW5rIHlvdSBmb3IgdGhlIGNs YXJpZmllZCB0ZXh0ID0+IERJU0NVU1MgaXMgY2xlYXJlZA0KLSBzZWN0aW9uIDMuMyBhbmQgZXhh bXBsZXM6IHRoYW5rIHlvdSBmb3IgaW1wcm92aW5nIHRoZSB0ZXh0ICYgZXhhbXBsZSA9PiBESVND VVNTIGlzIGNsZWFyZWQNCi0gc2VjdGlvbiA0LjEgYW5kIHRoZSAyIGJhY2stb2ZmIG1lY2hhbmlz bXMgZGVzY3JpcHRpb246IHRoZSBuZXcgdGV4dCBpcyBjbGVhciA9PiBESVNDVVNTIGlzIGNsZWFy ZWQNCi0gc2VjdGlvbiA0LjMgYW5kICJJUFBST1RPX1RDUCwgODAiOiB1c2luZyBhIGRpZmZlcmVu dCBwb3J0IG51bWJlciBhbHNvIGZpeCBteSBESVNDVVNTDQotIHNlY3Rpb24gNC4zIGFuZCBVTEEg cmF0aGVyIHRoYW4gZG9jdW1lbnRhdGlvbiBwcmVmaXggPT4gRElTQ1VTUyBpcyBjbGVhcg0KDQpJ IGhhdmUgdXBkYXRlZCB0aGUgZGF0YXRyYWNrZXIgd2l0aCBteSBuZXcgYmFsbG90IHBvc2l0aW9u Lg0KDQpSZWdhcmRzIGFuZCBrdWRvcyB0byBhbGwgYXV0aG9ycyBmb3IgdGhlaXIgcGF0aWVuY2Ug YW5kIGVmZm9ydCBiZWluZCB0aGlzIGRvY3VtZW50DQoNCi3DqXJpYw0KDQrvu79PbiAxMC8wNy8y MDE5LCAyMToyNiwgImllc2cgb24gYmVoYWxmIG9mIE1pY2hhZWwgUmljaGFyZHNvbiIgPGllc2ct Ym91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbWNyK2lldGZAc2FuZGVsbWFuLmNhPiB3cm90 ZToNCg0KICAgIA0KICAgIEVyaWMsIHRoYW5rIHlvdSBmb3IgdGhlIGNvbW1lbnRzLg0KICAgIA0K ICAgIFdHIGFuZCBvdGhlciBhdXRob3JzLCBwbGVhc2UgbG9vayBmb3IgWFhYIGFzIHlvdXIgcG9p bnQgd2hlcmUNCiAgICBJJ2QgbGlrZSB5b3VyIGlucHV0Lg0KICAgIA0KICAgIEkgd2lsbCBwdXNo IGEgLTIzIG9uIHRoZSAyMm5kIHdoZW4gZHJhZnQgc3VibWlzc2lvbnMgb3BlbiwgdW5sZXNzIHlv dSB3YW50IGl0DQogICAgZmFzdGVyLiAgSGVyZSBpcyBhIHBvaW50ZXIgdG8gZ2V0IGEgZGlmZiBi ZXR3ZWVuIC0yMiBhbmQgd2hhdCBpcyBub3cNCiAgICBpbiBnaXRodWI6ICBodHRwczovL3Rpbnl1 cmwuY29tL3kyZXgzMjR4DQogICAgDQogICAgSSB3YW50IHRvIHBvaW50IHRvIGEgdGhyZWFkIHRo YXQgdGhpcyBkb2N1bWVudCBuZWVkcyB0byBVcGRhdGVzOiBSRkM3MDMwLA0KICAgIGFzIGl0IGlz IGV4dGVuZGluZyB0aGUgLy53ZWxsLWtub3duL2VzdCBuYW1lc3BhY2UuICBJdCB3b3VsZCBiZSBn cmVhdA0KICAgIHRvIGhhdmUgdGhlIElFU0cncyBhZ3JlZW1lbnQgb24gdGhpcywgb3Igc3VnZ2Vz dCBhbiBhbHRlcm5hdGl2ZS4NCiAgICANCiAgICDDiXJpYyBWeW5ja2UgdmlhIERhdGF0cmFja2Vy IDxub3JlcGx5QGlldGYub3JnPiB3cm90ZToNCiAgICAgICAgPiA9PSBESVNDVVNTID09DQogICAg ICAgID4gVExTIGlzIGFzc3VtZWQgdG8gYmUgdXNlZCBidXQgSSBmYWlsZWQgdG8gZmluZCBXSElD SCB2ZXJzaW9uIG9mIFRMUw0KICAgICAgICA+IE1VU1QgYmUgdXNlZC4gVGhlIG9ubHkgcmVmZXJl bmNlIGluIHRoZSByZWZlcmVuY2Ugc2VjdGlvbiBpcyB2ZXJzaW9uDQogICAgICAgID4gMS4yLiBQ cm9iYWJseSB3b3J0aCB0byByZWZlciB0byB0aGlzIHZlcnNpb24gaW4gdGhlIHRleHQgYXMgd2Vs bCBhbmQNCiAgICAgICAgPiB1c2UgdmVyc2lvbiAxLjMgb2YgVExTLg0KICAgIA0KICAgIEZpcnN0 LCBpbiBkZXZlbG9waW5nIHRoaXMgcHJvdG9jb2wgd2UgdGhvdWdodCBhIGxvdCBhYm91dCBzb21l IG9mIHRoZSBwcml2YWN5DQogICAgZW5oYW5jZW1lbnRzIHRoYXQgVExTIDEuMyBjb3VsZCBwcm92 aWRlIHVzLCBwYXJ0aWN1bGFybHkgYXJvdW5kIGtlZXBpbmcgdGhlDQogICAgaWRlbnRpZnlpbmcg cGFydHMgb2YgdGhlIElEZXZJRCAocHJlc2VudCBpbiB0aGUgQ2VydGlmaWNhdGUpLCBhbmQgd2Ug dGhvdWdodA0KICAgIGFib3V0ID49MS4zLCBidXQgd2UgZGlkIG5vdCB3YW50IHRvIHRpZSB0aGlu Z3MgdXAgZm9yIHZlbmRvcnMuDQogICAgDQogICAgV2UgYWxzbyBjb25zaWRlcmVkIHN0cm9uZ2x5 IGFsd2F5cyBoYXZpbmcgdGhlIEpSQyBpbml0aWF0ZSB0aGUgVExTLCBiZWNhdXNlDQogICAgdGhl IENsaWVudENlcnRpZmljYXRlIGlzIHNlbnQgZmlyc3QgaW4gVExTLCBhbmQgdGhlIEpSQyBoYXMg bm8gcmVhbCBwcml2YWN5DQogICAgbmVlZHMuICBXZSBkaWQgbm90IGRvIHRoaXMsIGV2ZW4gdGhv dWdoIHRoZXJlIHdlcmUgc3Ryb25nIHJlcXVpcmVtZW50cyBmcm9tDQogICAgdGhlIDZ0aXNjaCBX RyB0byBnaXZlIHRoZSBKUkMgbW9yZSBjb250cm9sIG92ZXIgZW5yb2xsbWVudCBvcmRlci9iYW5k d2lkdGguDQogICAgDQogICAgV2UgZGVjaWRlZCB0byBzaXQgb24gdGhlIGZlbmNlIGFib3V0IFRM UyB2ZXJzaW9ucyBiZWNhdXNlIEdldHRpbmcgYSBUTFMNCiAgICB2ZXJzaW9uIHRocm91Z2ggYW4g ZXZhbHVhdGlvbiBwcm9jZXNzIGFuZCBpbnRvIGEgZmlybXdhcmUgZm9yIGEgQkZSIHdhc24ndA0K ICAgIHNvbWV0aGluZyB3ZSB3YW50ZWQgdG8gZ2F0ZSBCUlNLSSB1cG9uLg0KICAgIA0KICAgIEFz IHN1Y2gsIHdlIHRoaW5rIHdlIGFyZSBoYXBweSB3aXRoIGFueSB2ZXJzaW9uIG9mIFRMUyB0aGF0 IHRoZSBUTFMgV0cNCiAgICByZWNvbW1lbmRzLiBXZSBmdXJ0aGVyIHJlY29nbml6ZSB0aGF0IFJl Z2lzdHJhcidzIE1BWSBoYXZlIHRvIGJlIHdpbGxpbmcgdG8NCiAgICB0YWxrIHRvIHZlcnNpb25z IHdoaWNoIGFyZSBvbGRlciB0aGFuIHdoYXRldmVyIGlzIGNvbnNpZGVyZWQgc2VjdXJlIHRoYXQN CiAgICB5ZWFyLiAgQSBkZXZpY2UgdGhhdCBoYXMgYmVlbiBpbiBhIGJveCBpbiBhIHdhcmVob3Vz ZSB3b24ndCBoYXZlIHRoZSBsYXRlc3QNCiAgICBwYXRjaGVzLCBhbmQgaXQgd29uJ3QgaGF2ZSB0 aGUgbGF0ZXN0IHBhdGNoZXMgdW50aWwgaXQgZ29lcyB0aHJvdWdoIGFuDQogICAgb25ib2FyZGlu ZyBwcm9jZXNzLg0KICAgIA0KICAgIFRoZSBhbHRlcm5hdGl2ZSBpcyBhIHRydWNrIHJvbGwsIGEg VVNCIHN0aWNrLCBhbmQgc29tZSBndW0uDQogICAgDQogICAgV2UgcmVmZXJlbmNlIFJGQzcwMzAs IGFuZCBpdCdzIHNlY3Rpb24gMy4zLjEgc2F5cyBUTFMgMS4xIChub3cgY29uc2lkZXJlZA0KICAg IG9sZCksIGJ1dCB3ZSBkaWRuJ3QgbGlrZSB0aGF0IGl0IGV2ZW4gc3BlY2lmaWVkIHdoYXQgaXMg bm93IGFuIG9ic29sZXRlDQogICAgY2lwaGVyIHN1aXRlLiAgVGhhdCdzIG9uZSByZWFzb24gd2Ug ZmVsdCB0aGF0IHdlIHNob3VsZG4ndCBvdmVyc3BlY2lmeToNCiAgICB0aGF0J3MgdGhlIFRMUyBX RydzIGpvYi4NCiAgICANCiAgICBJdCB3b3VsZCBiZSBuaWNlIHRvIGJlIGFibGUgdG8gcG9pbnQg dG8gYSBTVEQgWFggZm9yIHRoaXMuDQogICAgDQogICAgV291bGQgeW91IGxpa2UgdXMgdGhlIGFk ZCBzb21ldGhpbmcgaW4gc2VjdGlvbiA1LjE/DQogICAgDQogICAgICAgID4gLS0gU2VjdGlvbiAy LjMuMSAtLQ0KICAgIA0KICAgICAgICA+IERvZXMgdGhlICJzZXJpYWwgbnVtYmVyIiBuZWVkIHRv IGJlIHVuaXF1ZSBwZXIgdmVuZG9yID8gSSBndWVzcyBzbyB0aGVuIEkNCiAgICAgICAgPiBzdHJv bmdseSBzdWdnZXN0IHRvIHVzZSBhIGRpZmZlcmVudCB3b3JkIHRoYW4gInNlcmlhbCBudW1iZXIi DQogICAgICAgID4gKGUuZy4gdW5pcXVlIGRldmljZSBJRCkgYXMgYSB2ZW5kb3IgY2FuIGhhdmUg bXVsdGlwbGUgcHJvZHVjdHMgaW4gaXRzDQogICAgICAgID4gcG9ydGZvbGlvLCBlYWNoIGhhdmlu ZyBhIGRpZmZlcmVudCBzZXQgb2YgdW5pcXVlICJzZXJpYWwgbnVtYmVycyIuDQogICAgDQogICAg V2UgYXJlIGxldmVyZ2luZyB0aGUgc2VyaWFsTnVtYmVyIGF0dHJpYnV0ZSBmcm9tIDgwMi4xQVIg KGFuZA0KICAgIFJGQzUyODApLiAgU2luY2UgdGhpcyBpcyBhbiBhdHRyaWJ1dGUgaW4gYSBjZXJ0 aWZpY2F0ZSdzIEROLCBpdCdzIHVuaXF1ZW5lc3MNCiAgICBpcyBkZWZpbmVkIGJ5IHRoZSBpc3N1 ZXIgb2YgdGhlIGNlcnRpZmljYXRlLiAgRGlmZmVyZW50IGlzc3VlciBwdWJsaWMga2V5cw0KICAg IHdvdWxkIGhhdmUgZGlmZmVyZW50IHNlcmlhbE51bWJlciBuYW1lc3BhY2VzLiAgU2luY2UgdGhl IHZvdWNoZXItcmVxdWVzdA0KICAgIGlzIHNpZ25lZCBieSB0aGUgSURldklELCB0aGF0IHZhbHVl IGlzIGFsc28gd2l0aGluIHRoZSBJRGV2SUQgaXNzdWVyJ3MNCiAgICBuYW1lc3BhY2UuDQogICAg DQogICAgQSB2ZW5kb3IgdGhhdCBvcGVyYXRlcyBkaWZmZXJlbnQgc2lnbmluZyBhdXRob3JpdGll cyBmb3IgZGlmZmVyZW50IHByb2R1Y3RzDQogICAgY291bGQgZGVjaWRlIHRvIGtlZXAgaXQncyBz ZXJpYWxOdW1iZXJzIHVuaXF1ZSBhY3Jvc3MgYWxsIHByb2R1Y3RzLiBJIHdvdWxkDQogICAgY2Vy dGFpbmx5IHJlY29tbWVuZCB0aGF0LCBidXQgZnJvbSBhIHRlY2huaWNhbCBwb2ludCBvZiB2aWV3 LCB1bm5lY2Vzc2FyeS4NCiAgICANCiAgICAgICAgPiAtLSBTZWN0aW9uIDMuMyAtLQ0KICAgIA0K ICAgICAgICA+IFRoZSBleGFtcGxlIDEgZG9lcyBub3QgaW5jbHVkZSB0aGUgbWFuZGF0b3J5IChw ZXIgWUFORyBtb2R1bGUpDQogICAgICAgID4gc2VyaWFsLW51bWJlci4NCiAgICAgICAgPiBJdCBz aG91bGQgYWxzbyBzdGF0ZSB0aGF0IHRoZSBjZXJ0IGlzIG5vdCBpbmNsdWRlZCBmb3Igc2F2aW5n IHNwYWNlIGluDQogICAgICAgID4gdGhpcyBkb2N1bWVudC4NCiAgICANCiAgICBJIGhhdmUgYWRk ZWQgc2VyaWFsLW51bWJlciB0byB0aGUgZXhhbXBsZS4NCiAgICANCiAgICAgICAgPiAtLSBTZWN0 aW9uIDQuMSAtLQ0KICAgIA0KICAgICAgICA+IFRoZXJlIGFyZSBUV08gYmFjay1vZmYgbWVjaGFu aXNtczogb25lIGZvciB0aGUgbWV0aG9kIGFuZCBvbmUgZm9yIHRoZQ0KICAgICAgICA+IHByb3h5 IGJ1dA0KICAgICAgICA+IG5vIGRlc2NyaXB0aW9uIG9uIGhvdyB0aG9zZSBtZWNoYW5pc21zIGlu dGVyYWN0IHRvZ2V0aGVyLg0KICAgIA0KICAgIFRoZSBmaXJzdCBiYWNrLW9mZiBpcyBmb3IgdGhl IGFjdGl2ZSBtZXRob2RzIG9mIGRpc2NvdmVyeS4NCiAgICAoVGhvc2UgbWV0aG9kcyBhcmUgb3B0 aW9uYWwsIEdSQVNQIE1fRkxPT0QgaXMgdGhlIE1USSkNCiAgICANCiAgICBUaGUgc2Vjb25kIGJh Y2stb2ZmIGlzIGZvciBhdHRlbXB0cyB0byBjb25uZWN0IHRvIGEgc3BlY2lmaWMgcHJveHkuDQog ICAgSSBkb24ndCBzZWUgYW4gaW50ZXJhY3Rpb24gb3IgYW4gaXNzdWUuIFRoZSB0aW1lcnMgYXJl IHNlcGFyYXRlLg0KICAgIE1heWJlIHlvdSBjYW4gZXhwbGFpbiB5b3VyIGNvbmNlcm4/DQogICAg DQogICAgSWYgd2Ugc2VlIE1fRkxPT0QgbWVzc2FnZXMgZnJvbSBhIG5ldyBwcm94eSwgdGhlbiB3 ZSdkIHN0YXJ0IChpbW1lZGlhdGVseSkNCiAgICB0cnlpbmcgdGhhdCBuZXcgY29ubmVjdGlvbiwg ZXZlbiBpZiB0aGVyZSBhcmUgVENQIGhhbGYtb3BlbiBjb25uZWN0aW9ucyB0bw0KICAgIHZpYSBw cm94aWVzLg0KICAgIA0KICAgIA0KICAgICAgICA+IC0tIFNlY3Rpb24gNC4zIC0tDQogICAgDQog ICAgICAgID4gUHJvYmFibHkgYSBuYWl2ZSBxdWVzdGlvbiBhYm91dCBHUkFTUCAodGhhdCBJIGRv IG5vdCBrbm93KSwgYnV0IGluIHRoZQ0KICAgICAgICA+IGV4YW1wbGUgdGhlcmUgaXMgIklQUFJP VE9fVENQLCA4MCIgdGhhdCBzZWVtcyB0byBpbmRpY2F0ZSB0aGUgdXNlIG9mDQogICAgICAgID4g cGxhaW4gSFRUUCBhbmQgbm8gVExTIGF0IGFsbC4gSXMgaXQgYW4gaXNzdWUgPw0KICAgIA0KICAg IFllcywgSSBhZ3JlZSB0aGF0IGlzIGNvbmZ1c2luZy4gIEl0IGNhbiBiZSA0NDMsLCBvciBhY3R1 YWxseSBhbnkgcG9ydCB0aGF0DQogICAgdGhlIHJlZ2lzdHJhciBjaG9vc2VzLiAgQXJlIHlvdSBv a2F5IHdpdGggODQ0MyB0byBlbXBoYXNpemUgdGhhdA0KICAgIGl0IGlzIGFyYml0cmFyeT8NCiAg ICANCiAgICAgICAgPiBJcyB0aGVyZSBhIHJlYXNvbiB3aHkgSVB2NiBVTEEgYXJlIHVzZWQgcmF0 aGVyIHRoYW4gdGhlIGRvY3VtZW50YXRpb24NCiAgICAgICAgPiBwcmVmaXggPw0KICAgIA0KICAg IHllcywgd2UgYXNzdW1lIHRoYXQgdGhpcyBjb21tdW5pY2F0aW9uIHJ1bnMgb3ZlciBBTklNQSdz IEFOSSBBQ1AuDQogICAgVGhlIEFDUCBpcyBleHBsaWNpdGVseSBudW1iZXJlZCBpbiBVTEFzLCBh bmQgd2UgZmVsdCB0aGF0IHVzaW5nIGEgR1VBDQogICAgKHdoaWNoIHRoZSBkb2N1bWVudGF0aW9u IHByZWZpeCBpcyksIHdvdWxkIGNvbmZ1c2UgcGVvcGxlLCBwYXJ0aWN1bGFybHkNCiAgICBzZWN1 cml0eSBwZW9wbGUsIGludG8gdGhpbmtpbmcgdGhhdCBwYXJ0cyBvZiB0aGUgcHJvdG9jb2wgcnVu IG92ZXIgdGhlDQogICAgb3BlbiBpbnRlcm5ldC4NCiAgICANCiAgICBJZiBoYXZlIGNvbnNpZGVy ZWQgdGhhdCB3ZSBvdWdodCB0byBoYXZlIGEgZG9jdW1lbnRhdGlvbiBVTEEgcHJlZml4LA0KICAg IGFuZCB3ZSBjb3VsZCBhbGxvY2F0ZSB0aGF0IG91dCBvZiB0aGUgVUxBLSJDIiBzcGFjZSAoZmMw MDo6LzgpLg0KICAgIA0KICAgICAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgPiBDT01NRU5U Og0KICAgICAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICANCiAgICAgICAgPiA9PSBDT01NRU5UUyA9 PQ0KICAgIA0KICAgICAgICA+IC0tIFNlY3Rpb24gMSAtLQ0KICAgIA0KICAgICAgICA+IFBsZWFz ZSBpbnRyb2R1Y2UgdGhlIE1BU0EgYWNyb255bSB1c2VkIGFmdGVyLg0KICAgIA0KICAgIERvbmUu DQogICAgDQogICAgICAgID4gLS0gU2VjdGlvbiAxLjEgLS0NCiAgICANCiAgICAgICAgPj4gdGhl IHBsZWRnZSByZXF1aXJlcyByZWFsdGltZSBjb25uZWN0aXZpdHkgdG8gdGhlIG1hbnVmYWN0dXJl cg0KICAgICAgICA+PiBzZXJ2aWNlDQogICAgDQogICAgICAgID4gV2h5IHRoaXMgY29ubmVjdGlv biByZXF1aXJlcyAicmVhbHRpbWUiID8gRXNwIHdoZW4gcmVhZGluZyBpbiBzZWN0aW9uDQogICAg ICAgID4gMS4zLjEgICJUaGUgYm9vdHN0cmFwcGluZyBwcm9jZXNzIGNhbiB0YWtlIG1pbnV0ZXMg dG8gY29tcGxldGUiDQogICAgDQogICAgcmVhbHRpbWUgYXMgb3Bwb3NlZCBzdG9yZSBhbmQgZm9y d2FyZCwgdmlhLCBmb3IgaW5zdGFuY2UgVVNCIGtleQ0KICAgIG9yIGVtYWlsIG92ZXIgVVVDUC4N CiAgICANCiAgICAgICAgPiAtLSBTZWN0aW9uIDEuMiAtLQ0KICAgIA0KICAgICAgICA+IFBsZWFz ZSB1c2UgdGhlIFJGQyA4MTc0IGJvaWxlcnBsYXRlLg0KICAgIA0KICAgIDxpbnNlcnQgb2xkIGd1 eSBncmlwcGluZyBhYm91dCBuZXctZmFuZ2xlZCB0aGluZ3M+DQogICAgDQogICAgICAgID4gIjE2 MC1iaXQgU0hBLTEgaGFzaCIgSSB3aWxsIGxldCB0aGUgc2VjdXJpdHkgQUQgdG8gY2hlY2sgd2hl dGhlciBTSEEtMSBpcw0KICAgICAgICA+IGRlZW1lZCBzdWZmaWNpZW50IGZvciB0aGlzIHB1cnBv c2UuDQogICAgDQogICAgUkZDNTI4MCB1c2VzIGl0LCBhbmQgd2UgZG9uJ3QgaGF2ZSBhIGNvbW1v biByZXBsYWNlbWVudCBmb3IgdGhpcw0KICAgIChvciBldmVuIGEgZ29vZCBuYW1lIGZvciBpdCku ICBJdCBpcyBvbmx5IHVzZWQgaW4gdGhlIGF1ZGl0IGxvZyB0byBpZGVudGlmeQ0KICAgIHByZXZp b3VzIG93bmVycy4gIFdlIGNvdWxkIGVhc2lseSBhZGQgYSBzZWNvbmQgaGFzaCB0byB0aGUgYXVk aXQgbG9nLg0KICAgIA0KICAgICAgICA+IC0gU2VjdGlvbiAxLjUgLS0NCiAgICANCiAgICAgICAg PiBQbGVhc2UgZXhwbGFpbi9yZWZlciBHUkFTUCBhY3JvbnltLg0KICAgIA0KICAgIHJlZmVyZW5j ZSBhZGRlZC4NCiAgICANCiAgICAgICAgPiAtLSBTZWN0aW9uIDIgLS0NCiAgICANCiAgICAgICAg PiBJIHdvbmRlciB3aGF0IHdpbGwgaGFwcGVuIHdoZW4gdGhlIGRldmljZSB2ZW5kb3Igc3RvcHMg bWFpbnRhaW5pbmcgdGhlDQogICAgICAgID4gTUFTQSBvbi1saW5lPw0KICAgIA0KICAgIHBsZWFz ZSBzZWUgZmxhbWV3YXJeV3NlYy1kaXIgcmV2aWV3IHRocmVhZCBsYXN0IGZhbGwgOi0pDQogICAg ICAgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9hbmltYS9YQ1M2SnB3UVNt M25hT2l2d0NZYU8wQUFzVnMNCiAgICANCiAgICBXZSBhZGRlZCBtb3N0IG9mIHNlY3Rpb24gMTAg b24gdGhpcy4NCiAgICBJbiBwYXJ0aWN1bGFyIHNlY3Rpb24gMTAuNSBzdWdnZXN0cyB0aGF0IGEg bWFudWZhY3R1cmVyIGNvdWxkIHBlcm1pdCB0aGUgTUFTQQ0KICAgIGFuY2hvcnMgdG8gYmUgcmVw bGFjZWQgYW5kL29yIGF1Z21lbnRlZC4gIFRoaXMgZGl2b3JjZXMgdGhlIGRldmljZSBlbnRpcmVs eQ0KICAgIEZyb20gdGhlIG1hbnVmYWN0dXJlci4gIEFuIG9wZXJhdG9yIHRoYXQgZ29lcyB0aGlz IHdheSBwcm9iYWJseSBzaG91bGQgaGF2ZQ0KICAgIHNvdXJjZSBjb2RlOiBidXQgdGhhdCdzIG5v IGxvbmdlciB1bnJlYXNvbmFibGUgZm9yIG1hbnkgcGxhdGZvcm1zIHRoYXQNCiAgICBwcm92aWRl IHZpcnR1YWxpemVkIHNlcnZpY2VzLg0KICAgIA0KICAgICAgICA+IC0tIFNlY3Rpb24gMi4yIC0t DQogICAgDQogICAgICAgID4gT3V0IG9mIGN1cmlvc2l0eSwgd2h5IHRoaXMgZG9jdW1lbnQgdXNl cyB0aGUgd29yZCAidm91Y2hlciIgYXMgb3Bwb3NlZCB0bw0KICAgICAgICA+ICJ0aWNrZXQiID8N CiAgICANCiAgICBOb3Qgc3VyZSwgYnV0IEknZCBoYXZlIGFyZ3VlZCBhZ2FpbnN0IHRpY2tldCBi ZWNhdXNlIEJSU0tJL1JGQzgzNjYgdm91Y2hlcnMNCiAgICBhcmUgc2lnbmlmaWNhbnRseSBsZXNz IGZ1bmN0aW9uYWwgdGhhbiBLZXJiZXJvcyB0aWNrZXRzLg0KICAgIA0KICAgICAgICA+IC0tIFNl Y3Rpb24gMy40IC0tDQogICAgDQogICAgICAgID4gSSBmaW5kIGEgbGl0dGxlIHdlaXJkIHRoYXQg dGhlIGluY2x1ZGVkIFlBTkcgbW9kdWxlIGhhcyBhIGRpZmZlcmVudA0KICAgICAgICA+IGF1dGhv cnMgbGlzdCB0aGFuIHRoZSBkb2N1bWVudCBpdHNlbGYuDQogICAgDQogICAgQSBnb29kIHBvaW50 LiBTdGVpbnRob3IgY2hhbmdlZCBqb2JzIGJlZm9yZSB3ZSBnb3QgZnVsbHkgaW50byB0aGUgWUFO Rw0KICAgIG1vZGVsbGluZy4gIEtlbnQgZGlkIG1vc3Qgb2YgaGVhdnkgWUFORyBsaWZ0aW5nLCBz byB3ZSBwdXQgaGltIGZpcnN0LA0KICAgIGJ1dCBJJ3ZlIHNvcnRlZCB0aGUgcmVzdCBhbHBoYWJl dGljYWxseS4NCiAgICANCiAgICAgICAgPiBQbGVhc2UgcmVmZXIgdG8gUkZDIDgxNzQuDQogICAg DQogICAgICAgID4gIlJGQyBZWVlZOiBWb3VjaGVyIFByb2ZpbGUgZm9yIEJvb3RzdHJhcHBpbmcg UHJvdG9jb2xzIiBkb2VzIG5vdCBzZWVtDQogICAgICAgID4gY29ycmVjdCBpbiBhIFlBTkcgbW9k dWxlIHJlZmVyZW5jZS4NCiAgICANCiAgICBGaXhlZC4NCiAgICANCiAgICAgICAgPiAtLSBTZWN0 aW9uIDUgLS0NCiAgICANCiAgICAgICAgPiBUaGUgTUFTQSBVUkkgc3ludGhlc2lzIGV4cGxhbmF0 aW9uIGlzIGEgZHVwbGljYXRlIG9mIGEgcHJldmlvdXMNCiAgICAgICAgPiBleHBsYW5hdGlvbi4N CiAgICAgICAgPiBVbnN1cmUgd2hldGhlciBpdCBoZWxwcyB0aGUgcmVhZGVyLg0KICAgIA0KICAg IFdlIGluY2x1ZGVkIGl0IGluIGJvdGggc2VjdGlvbiA1IGFuZCBzZWN0aW9uIDIuMy4yLCBiZWNh dXNlIGluIGludGVyb3ANCiAgICB0ZXN0aW5nLCB3ZSBub3RpY2VkIHRoYXQgaW1wbGVtZW50b3Jz IG9mIFJlZ2lzdHJhcidzIG9mdGVuIGRvICpub3QqIHJlYWQgdGhlDQogICAgcGFydCBhYm91dCBN QVNBIG9wZXJhdGlvbnMsIGFuZCBWViwgdGhlIElEZXZJRCBjZXJ0aWZpY2F0ZSBhdXRob3JpdHkN CiAgICBwcm9ncmFtbWVyIGlzIHVubGlrZWx5IHRvIHVuZGVyc3RhbmQgc2VjdGlvbiA1Lg0KICAg IA0KICAgICAgICA+IC0tIFNlY3Rpb24gOC40IC0tDQogICAgDQogICAgICAgID4gSSBhbSBhZnJh aWQgdGhhdCB0aGUgRE5TIHNlcnZpY2UgbmFtZXMgaGF2ZSBhIGxlbmd0aCBvZiBtYXhpbXVtIDE1 DQogICAgICAgID4gY2hhcmFjdGVycy4NCiAgICAgICAgPiBCdXQsIElBTkEgaXMgb2YgY291cnNl IHRoZSBzb3VyY2Ugb2YgdHJ1dGguDQogICAgDQogICAgWFhYDQogICAgV2UgaGF2ZSBoZWFyZCBm cm9tIElBTkEsIGFuZCB0aGV5IGRpZCBub3QgY29tcGxhaW4gYXMgeWV0Lg0KICAgIA0KICAgICAg ICA+IC0tIEFwcGVuZGl4IEEgLS0NCiAgICANCiAgICAgICAgPiBVc2luZyBJUHY2IExMQSBzaG91 bGQgYmUgZW5vdWdoLCBJIGRvIG5vdCBzZWUgdGhlIHJlYXNvbiB0byBkZXNjcmliZSBhDQogICAg ICAgID4gbmV3IHByb3RvY29sIHVzaW5nIGxlZ2FjeSBJUHY0IGFkZHJlc3NlcyBiZWNhdXNlIElQ VjYgbGluay1sb2NhbA0KICAgICAgICA+IGFkZHJlc3NlcyBzaG91bGQNCiAgICAgICAgPiB3b3Jr IG9uIGFueSBkZWNlbnQgbGF5ZXItMiBuZXR3b3JrLg0KICAgIA0KICAgIFhYWDoNCiAgICBJIHBl cnNvbmFsbHkgaGF2ZSBubyBvYmplY3Rpb24gdG8gcmlwcGluZyBvdXQgdGhhdCBsZWdhY3kgMTk4 MHMgY3JhcCA6LSkNCiAgICBJIHdhcyBoYXBweSB0byByZWxlZ2F0ZSBpdCB0byBhIG5vbi1ub3Jt YXRpdmUgYXBwZW5kaXguDQogICAgSSdtIGdvbm5hIGxldCB0aGUgb3RoZXIgYXV0aG9ycyBhbmQg V0cgYXJndWUgdGhpcyBwb2ludC4NCiAgICANCiAgICAgICAgPiA9PSBOSVRTID09DQogICAgDQog ICAgICAgID4gQSBsb3Qgb2YgImV0aGVybmV0IiBhbmQgImludGVybmV0IiB3aGlsZSB0aG9zZSB3 b3JkcyBhcmUgdXN1YWxseQ0KICAgICAgICA+IGNhcGl0YWxpemVkIGFzDQogICAgICAgID4gIkV0 aGVybmV0IiBvciAiSW50ZXJuZXQiLg0KICAgIA0KICAgIG9rYXksIGZpeGVkLg0KICAgIA0KICAg ICAgICA+IC0tIEFic3RyYWN0IC0tDQogICAgDQogICAgICAgID4gU2hvdWxkbid0IHRoZSBwbHVy YWwgZm9ybSB1c2VkIGluICJ1c2luZyBtYW51ZmFjdHVyZXIgaW5zdGFsbGVkIFguNTA5DQogICAg ICAgID4gY2VydGlmaWNhdGUiID8NCiAgICANCiAgICBva2F5DQogICAgDQogICAgICAgID4gLS0g U2VjdGlvbiAxLjUgLS0NCiAgICANCiAgICAgICAgPiBzL1NvbWUgb2YgdGhlIG9wdGlvbnMgaW4g dGhpcyBkb2N1bWVudCBpcyB0aGUgcmVzdWx0IG9mDQogICAgICAgID4gcmVxdWlyZW1lbnRzL1Nv bWUgb2YNCiAgICAgICAgPiB0aGUgb3B0aW9ucyBpbiB0aGlzIGRvY3VtZW50IGFyZSB0aGUgcmVz dWx0IG9mIHJlcXVpcmVtZW50cy8gPw0KICAgIA0KICAgIGFncmVlZC4NCiAgICANCiAgICAgICAg PiAtLSBTZWN0aW9uIDIuMy4yIC0tDQogICAgDQogICAgICAgID4gUGxlYXNlIHVzZSB1cHBlcmNh c2UgaW4gdGhlIHByb3RvY29sIGFjcm9ueW1zIGluICJ0aGF0IE1VU1QgYmUgc3VwcG9ydGVkLA0K ICAgICAgICA+IGluY2x1ZGluZyBsZGFwLCBodHRwIGFuZCBmdHAiDQogICAgDQogICAgb2theS4N CiAgICANCiAgICAgICAgPiAuLi4uDQogICAgDQogICAgICAgID4gLS0gU2VjdGlvbiA1LjEgLS0N CiAgICANCiAgICAgICAgPiAiQSBQbGVkZ2UgdGhhdCBjYW4gY29ubmVjdCB0byBtdWx0aXBsZSBy ZWdpc3RyaWVzIGNvbmN1cnJlbnRseSwgU0hPVUxEDQogICAgICAgID4gZG8gc28uIg0KICAgIA0K ICAgICAgICA+IGxvd2VyIGNhc2UgZm9yIHBsZWRnZSBhbmQgd2hhdCBpcyB0aGUgcHVycG9zZSBv ZiB0aGUgY29tbWEgaW4gdGhpcw0KICAgICAgICA+IHNlbnRlbmNlPw0KICAgIA0KICAgIHdlIGhh ZCBhIG1hbmlhIGF0IHNvbWUgcG9pbnQgdGhhdCBhcmd1ZWQgdGhhdCBQbGVkZ2Ugd2FzIGEgcHJv cGVyIG5vdW4uDQogICAgV2UgcmVjb3ZlcmVkIGZyb20gaXQuDQogICAgDQogICAgSSB0aGluayB0 aGF0IGNvbW1hIGJlbG9uZ3M7IG1heWJlIGl0IFNIT1VMRCBiZSBhIHNlbWktY29sb24uDQogICAg SSdtIGhhcHB5IHRvIGxldCB0aGUgY29weS1lZGl0b3IgYXJndWUgaXQuICBJIHRoaW5rIHRoYXQg aXQgc2VwZXJhdGVzDQogICAgb3V0IGEgcXVhbGlmeWluZyBub3VuIHBocmFzZS4NCiAgICANCiAg ICAgICAgPiAob2sgSSBhbSBub3QgYW4gRW5nbGlzaCBuYXRpdmUgc3BlYWtlciBzbyBJIGNhbiBi ZSB3cm9uZykNCiAgICANCiAgICBwczogaGVyZSBpcyBhIHZpZGVvIG9mIHRoZSBwcm90b2NvbCBm cm9tIGFub3RoZXIgbm9uLW5hdGl2ZSBFbmdsaXNoIHNwZWFrZXI6DQogICAgICAgICAgaHR0cHM6 Ly92aW1lby5jb20vMzA1MDQxNzU1DQogICAgDQogICAgDQogICAgLS0NCiAgICBNaWNoYWVsIFJp Y2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jr cw0KICAgICAtPSBJUHY2IElvVCBjb25zdWx0aW5nID0tDQogICAgDQogICAgDQogICAgDQogICAg DQoNCg== From nobody Fri Aug 30 00:47:18 2019 Return-Path: X-Original-To: anima@ietf.org Delivered-To: anima@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFA612089F; Fri, 30 Aug 2019 00:47:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-anima-bootstrapping-keyinfra@ietf.org, Toerless Eckert , anima-chairs@ietf.org, tte+ietf@cs.fau.de, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.100.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <156715123617.25771.14488190599982854223.idtracker@ietfa.amsl.com> Date: Fri, 30 Aug 2019 00:47:16 -0700 Archived-At: Subject: [Anima] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-iet?= =?utf-8?q?f-anima-bootstrapping-keyinfra-26=3A_=28with_COMMENT=29?= X-BeenThere: anima@ietf.org X-Mailman-Version: 2.1.29 List-Id: Autonomic Networking Integrated Model and Approach List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Aug 2019 07:47:16 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-anima-bootstrapping-keyinfra-26: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-anima-bootstrapping-keyinfra/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my previous DISCUSSes and COMMENTs -éric