From nobody Mon Jan 6 05:08:06 2020 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC6512082C for ; Mon, 6 Jan 2020 05:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, 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=QdguwLwC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Ng8Ow3ag Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xkRaiD4ivHA for ; Mon, 6 Jan 2020 05:08:04 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF756120829 for ; Mon, 6 Jan 2020 05:08:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9221; q=dns/txt; s=iport; t=1578316083; x=1579525683; h=from:to:subject:date:message-id:mime-version; bh=uUWr6HVt6bW/alXd197733vTbdgh1NEQmcN8gPrqpHE=; b=QdguwLwCfX6nZeazZewVMzqWiISO5ByqlHe0eGPxObFhKnHzyqS1TehO JNARZRC+kZY8FsPAanruxWwON2UQmEXrWFc/DEtIVCrKP5zc4KpBty7Id utQ4bzJ2Xv6pO39xw0WcCuhw1bECAb5qBFrlpFy6WNh1m+aPYRCPLCeY1 I=; IronPort-PHdr: =?us-ascii?q?9a23=3AiY7enRc9iULBO+p9ROEcBDHRlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/aSczGdtDUlBN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0DQC7LxNe/5BdJa1mHgELHIFxC4E?= =?us-ascii?q?lL1AFbFggBAsqhAmDRgOLAU6VPIRigS6BJANUCQEBAQwBASMKAgEBhEACF4F?= =?us-ascii?q?SJDQJDgIDDQEBBAEBAQIBBQRthTcBC4VeARgRHQEBOBEBGQMBAigDAgQwFAk?= =?us-ascii?q?KBBMigwABgXlNAy4BDqFpAoE4iGF1gTKCfgEBBYE1AYEUgjcYggwDBoE2hR2?= =?us-ascii?q?GfBqCAIERJyCCTD6EaQ0JgloygiyQPoVXiWOPJQqCNoc0jmYbgkaHfZAYjlO?= =?us-ascii?q?IU5IGAgQCBAUCDgEBBYFSOYFYcBVlAYJBUBgNjRKDc4pTdIEojUMBAQ?= X-IronPort-AV: E=Sophos;i="5.69,402,1571702400"; d="scan'208,217";a="405381872" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Jan 2020 13:08:02 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 006D81sc018181 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 6 Jan 2020 13:08:01 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 07:08:00 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 07:08:00 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 6 Jan 2020 08:08:00 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J0YJ96w0kv5GO8zO6GOlcnosGy3grFpWoqKhIqt4l+udW8k8fxIGbYOgHPTVG5ZTxANw6USJVFp2nHl2PrbxvY6TP3AqVjOqlRxiSQ4zYzD0pW3QMlFqp/gYzw+ZtV5ab0UJr1DFSNT9w6cT5Z3BdPyTQeIj37btcXT5sqFQhvNQeiUPOwcM4HWCl+C1Gb1RaY1FR4iDq6lPRZRB+rvlXL2+ehQbJbA9oNgQC15ojR/JFpHvU5U6vCf+cgUbxkae2084RfNndmxIBcflbNY1kV7XFEaNwlvSm/XCka+URYnQMJDsjF/IJw/17p5cNa2DEGyFjKvlAg2ztay9pphm8w== 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=uUWr6HVt6bW/alXd197733vTbdgh1NEQmcN8gPrqpHE=; b=Pc29VV5TiXQzXhm4SELwQHFfIBkig7hGG2xakg+Kpi6VwCd8E2U6zH+Say78Tx65OY5T2xtklXE9w09DfZEUsua15n9zgbi7Tn8sET8oLN4o5CPQTuGUK28GvljfkEUhwX7Tuyc8n0NTNe1hGFcuXFTwI/PKKAMwAaY5nHszlYuhDaIXujaUlsi/QHYyJjz/5lZKhYbBGH3a/WUVI6tgyV5NlFs9BNiVljMo6lVAtnGVvFlUGgpOcnfzFifPEaVlMDNCvetVwK2TAFPa9n86xFHsKLe/lC7yUkdD6XBvybqJLLcp2yIRn8gQcXO3Q8utvpXrS5cCTJFlxMkwO1ZT2g== 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=uUWr6HVt6bW/alXd197733vTbdgh1NEQmcN8gPrqpHE=; b=Ng8Ow3agI7qqIO9DQ7JwBjk0NXeYGR5EdsbSoa0mssAgV582fU/GMMbNnYKJoOJM/ZAelj6ZSkWR4IIjvU3PVkOk7uIOPVCoX7CF5z3AnYX2lA1/z3lVHfHoA8juVJ6QpGuXaxoqJfdVbZQH3dkwr2WmwboCnMSPAUGc7sbxmmA= Received: from MWHPR1101MB2176.namprd11.prod.outlook.com (10.174.255.149) by MWHPR1101MB2352.namprd11.prod.outlook.com (10.173.55.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Mon, 6 Jan 2020 13:07:59 +0000 Received: from MWHPR1101MB2176.namprd11.prod.outlook.com ([fe80::4182:71b5:d005:b6db]) by MWHPR1101MB2176.namprd11.prod.outlook.com ([fe80::4182:71b5:d005:b6db%3]) with mapi id 15.20.2602.015; Mon, 6 Jan 2020 13:07:59 +0000 From: "Nancy Cam-Winget (ncamwing)" To: "teep@ietf.org" Thread-Topic: Reminder: Doodle poll for virtual interim Thread-Index: AQHVxJJRGm9eUZgEYkipNDIvRrwaKg== Date: Mon, 6 Jan 2020 13:07:58 +0000 Message-ID: <0B1074D7-B921-4B5F-BB67-5CA1AA897378@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.11.191208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ncamwing@cisco.com; x-originating-ip: [2001:420:c0c8:1004::f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b913190f-38e2-407a-e308-08d792a9741d x-ms-traffictypediagnostic: MWHPR1101MB2352: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(346002)(136003)(376002)(199004)(189003)(6486002)(6512007)(33656002)(5660300002)(4744005)(53546011)(6506007)(2616005)(2906002)(316002)(86362001)(966005)(36756003)(71200400001)(64756008)(8676002)(81166006)(6916009)(76116006)(66946007)(66476007)(91956017)(66556008)(66446008)(186003)(8936002)(81156014)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR1101MB2352; H:MWHPR1101MB2176.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: BCL:0; x-microsoft-antispam-message-info: IOTZtATj560Yfb1s6fcRw2f30W3YphOBuZrwJP/9oUpOGoxQAXsgcEwL6kMi/TkBenL2UtPBu+jZ8YPTGUdPYdJovt/tZipRByocUmkNyf4w0D+ehzI8JFiwPWYz8hvOn1b0DHUWL2ABEkJ2bRAfxWb4Fjw125eD45NYa2D66/Ue2wb81IiGCFcc5kaqhfflXLcrqkityengeWfE2Q72w07ZwyXJgGsnRgZoC2GyMQRC4xZj5TIn1GusLE9qHwmZFkcUTZw/dis1y6REZqddoDfFBASGgS1hSE/sCZSDt15e2Dxq5HxYNCG5F2EnJ+ohP2hrCJelELSlnTcfPdzPd5it2p29RiBR8rMkvwgMHUevIhUcwWowISpeBPoIH3NdtKSe3cfRoucaxiY2tqJx9jdG5DdnS9Lx6MuuX7N6jG1To0e3AYgnliDfAvI4+j6s9xObeTiBRQ202bXiAAi41VPUF128/y4KYTMxgLt3DEk= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_0B1074D7B9214B5FBB675CA1AA897378ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b913190f-38e2-407a-e308-08d792a9741d X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2020 13:07:58.9319 (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: lntotzN8TPTBagdYjhubwEz5macojdKCTq6/idzzBKo7nrCbpQOERDWUQn3nIWuGawGhE8s9HFn9chGt0LgcJg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2352 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: [Teep] Reminder: Doodle poll for virtual interim X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 13:08:05 -0000 --_000_0B1074D7B9214B5FBB675CA1AA897378ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIHJlbWVtYmVyIHRvIGZpbGwgb3V0IHRoZSBkb29kbGUgcG9sbCBzbyB3ZSBjYW4gc2No ZWR1bGUgb3VyIG5leHQgdmlydHVhbCBpbnRlcmltOg0KICAgIGh0dHBzOi8vZG9vZGxlLmNvbS9w b2xsLzhodHBmZWl1aWZxaGV4aXENCg0KRnJvbTogVEVFUCA8dGVlcC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzp0ZWVwLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgbmNhbXdpbmcgPG5j YW13aW5nQGNpc2NvLmNvbTxtYWlsdG86bmNhbXdpbmdAY2lzY28uY29tPj4NCkRhdGU6IE1vbmRh eSwgRGVjZW1iZXIgMjMsIDIwMTkgYXQgMTE6NDEgQU0NClRvOiAidGVlcEBpZXRmLm9yZzxtYWls dG86dGVlcEBpZXRmLm9yZz4iIDx0ZWVwQGlldGYub3JnPG1haWx0bzp0ZWVwQGlldGYub3JnPj4N ClN1YmplY3Q6IFtUZWVwXSBURUVQIHZpcnR1YWwgaW50ZXJpbQ0KDQpIZWxsbyBURUVQIHBhcnRp Y2lwYW50cywNClRoZXJlIHdhcyBpbnRlcmVzdCB0byBoYXZlIGEgdmlydHVhbCBpbnRlcmltIGJl Zm9yZSBJRVRGIDEwNywgcG9zc2libHkgZHVyaW5nIHRoZSBJb1QgSGFja2F0aG9u4oCmLmdpdmVu IHRoZSBjaGFpcnMgc2NoZWR1bGVzIChhcyBuZWl0aGVyIG9mIHVzIHdpbGwgYmUgYWJsZSB0byBi ZSBwcmVzZW50IGF0IHRoZSBIYWNrYXRob24pLCBJ4oCZdmUgY3JlYXRlZCBhIGRvb2RsZSBwb2xs OiAgaHR0cHM6Ly9kb29kbGUuY29tL3BvbGwvOGh0cGZlaXVpZnFoZXhpcQ0KUGxlYXNlIGNob29z ZSBkYXRlcyB0aGF0IHdvcmsgYmVzdCBmb3IgeW91IGFuZCB3ZeKAmWxsIGRvIG91ciBiZXN04oCm LkkgcGxhY2Ugb25lIG9yIHR3byBzbG90cyB0aGF0IGFsc28gY29pbmNpZGUgd2l0aCBjaG9pY2Vz IGZvciB0aGUgUkFUcyB2aXJ0dWFsIGludGVyaW0gc28gaWYgd2UgZ2V0IGZ1bGwgcXVvcnVtIGZv ciBib3RoLCB3ZSBjb3VsZCBhdHRlbXB0IHRvIGhhdmUgYSBqb2ludCBibG9jayBhcyB3ZWxsLg0K DQpIYXBweSBOZXcgWWVhciENCiAgICAgICAgICAgICAgICBOYW5jeQ0KDQo= --_000_0B1074D7B9214B5FBB675CA1AA897378ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <9D03E7B9FA1D4A4FB4A7FA5F3E121AA4@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGxlYXNlIHJlbWVtYmVyIHRvIGZpbGwgb3V0IHRoZSBk b29kbGUgcG9sbCBzbyB3ZSBjYW4gc2NoZWR1bGUgb3VyIG5leHQgdmlydHVhbCBpbnRlcmltOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4mbmJzcDsmbmJzcDsgPC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48YSBocmVmPSJodHRwczovL2Rvb2RsZS5jb20vcG9sbC84aHRwZmVpdWlmcWhleGlxIj48 c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aHR0cHM6Ly9kb29kbGUuY29tL3BvbGwvOGh0cGZl aXVpZnFoZXhpcTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5G cm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VEVFUCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnRlZXAtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPnRlZXAt Ym91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OyBvbiBiZWhhbGYgb2YgbmNhbXdpbmcNCiAm bHQ7PGEgaHJlZj0ibWFpbHRvOm5jYW13aW5nQGNpc2NvLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9y OiM5NTRGNzIiPm5jYW13aW5nQGNpc2NvLmNvbTwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPkRhdGU6 PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5Nb25k YXksIERlY2VtYmVyIDIzLCAyMDE5IGF0IDExOjQxIEFNPGJyPg0KPGI+VG86PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj4mcXVvdDs8YSBocmVmPSJt YWlsdG86dGVlcEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM5NTRGNzIiPnRlZXBAaWV0 Zi5vcmc8L3NwYW4+PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlZXBAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj50ZWVwQGlldGYub3JnPC9zcGFuPjwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9iPltUZWVwXSBURUVQIHZpcnR1YWwgaW50ZXJpbTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNh cmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5z OiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFk anVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBw eCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkhlbGxvIFRFRVAgcGFydGljaXBhbnRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0 bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGVyZSB3YXMgaW50ZXJlc3QgdG8gaGF2ZSBhIHZp cnR1YWwgaW50ZXJpbSBiZWZvcmUgSUVURiAxMDcsIHBvc3NpYmx5IGR1cmluZyB0aGUgSW9UIEhh Y2thdGhvbuKApi5naXZlbiB0aGUgY2hhaXJzIHNjaGVkdWxlcyAoYXMgbmVpdGhlciBvZiB1cyB3 aWxsIGJlIGFibGUgdG8gYmUgcHJlc2VudCBhdCB0aGUgSGFja2F0aG9uKSwgSeKAmXZlIGNyZWF0 ZWQgYTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5kb29k bGU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+cG9sbDo8 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDsmbmJzcDs8L3NwYW4+PC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vZG9vZGxlLmNvbS9wb2xsLzhodHBmZWl1aWZxaGV4aXEiPjxz cGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5odHRwczovL2Rvb2RsZS5jb20vcG9sbC84aHRwZmVp dWlmcWhleGlxPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0 ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1 dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5QbGVhc2UgY2hvb3NlIGRhdGVzIHRoYXQgd29yayBiZXN0 IGZvciB5b3UgYW5kIHdl4oCZbGwgZG8gb3VyIGJlc3TigKYuSSBwbGFjZSBvbmUgb3IgdHdvIHNs b3RzIHRoYXQgYWxzbyBjb2luY2lkZSB3aXRoIGNob2ljZXMgZm9yIHRoZSBSQVRzIHZpcnR1YWwg aW50ZXJpbSBzbyBpZiB3ZSBnZXQgZnVsbCBxdW9ydW0gZm9yIGJvdGgsIHdlIGNvdWxkIGF0dGVt cHQgdG8gaGF2ZSBhIGpvaW50IGJsb2NrIGFzIHdlbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9u dC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lk b3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQt c2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3Bh Y2luZzowcHgiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IYXBweSBOZXcgWWVhciE8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY2FyZXQtY29s b3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87 dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBh dXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IE5hbmN5PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0B1074D7B9214B5FBB675CA1AA897378ciscocom_-- From nobody Mon Jan 6 19:14:09 2020 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493C012022D for ; Mon, 6 Jan 2020 19:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 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_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=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rft6BcuKTIuH for ; Mon, 6 Jan 2020 19:14:05 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680092.outbound.protection.outlook.com [40.107.68.92]) (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 5E053120123 for ; Mon, 6 Jan 2020 19:14:05 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ds+Pr2Q6lN9u1M0CBZAwW8wK6ytQHf/rYFPIjXOgSdMxIVmZDzwwCJb5dtuwZdIYoFUXd5LQk7WSNikYDY7YwqcPjXN4eakEb5lUb5gYz+5YPjsFVRqEFofTz+Dx51y+4b5iSmkkB/uepnR5+kv9d0DUhBmQRayf/yZwhKG4Lu6OdNx54a5Eelm1yTQ2DqpVJuNXo5+zWd7enFGvTuE+4EJf3SU6GavxkzZqGkiRHjdU9+r4TZ9TWMrhKYm5gfSRygXLAiPh2l9pQGfaDHpvvKyxC65LnJQTds5NEhkYBnUfp+pQ+QbGPuD4Mzhkzzrtpx57DghG9/GXUil3Mi+XBQ== 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=R8Ik9IWNr+TTy1xuSD5aEfWo5CGscKphLOi4tUFl0v4=; b=POgPTJ5L430a2FRENwAxTnm+gUPn4fDCM8PN+kWDzxjQTEj3y2gehiShPGMyyiSSGpP6kngIbeyqMFenhOuvQzyCj5SigUZcdQ91PGxiadXe3ln5zbGeNKQ1uotTumgHgrM1pFrQPi39MZGOI3GOAFXOiit6jTs/0AhxXi2lXQgu4RXG7lHJMLSfoQGPIS6vLtVstFcCbp0VU7cD7FUVL6V4QW9W/VgZypl/wZjkLjVtKAQirMPPlXovTjFgRI2nQEMrqFhEgdUehtAo1ikPPfVcDRpJNK1DdwFX0crR6HBftrR48SI0bFiZdU/LURuO27kdpmVkbEdsFuSm/mB5Ow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R8Ik9IWNr+TTy1xuSD5aEfWo5CGscKphLOi4tUFl0v4=; b=VSxqfhVHqR3+7eSlix2LG3dcJ2gOQV+K2VItO2vL2u2p7sLLuygxq47YCNNTkbN7DHcZ1ALuKOtOXnsx80KZyQUutVhS885yCEVI/Eo0m0rX4QVJfWo6QEM23ili2r5J79PaRijSnKIQcFNFMOEoxqGAtBFr2S8HSM2gGFsMHaA= Received: from BL0PR2101MB1027.namprd21.prod.outlook.com (52.132.20.161) by BL0PR2101MB0916.namprd21.prod.outlook.com (52.132.23.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.1; Tue, 7 Jan 2020 03:14:03 +0000 Received: from BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::c50e:86ef:6bf3:d535]) by BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::c50e:86ef:6bf3:d535%9]) with mapi id 15.20.2644.002; Tue, 7 Jan 2020 03:14:03 +0000 From: Dave Thaler To: "Konda, Tirumaleswar Reddy" , "teep@ietf.org" Thread-Topic: Working Group Last Call for draft-ietf-teep-architecture Thread-Index: AdW5iepOELmpRRFXSAWsc0EhHQP19ALfbySA Date: Tue, 7 Jan 2020 03:14:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-01-07T03:14:02.9467153Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=113fc599-cef6-4df9-bb00-5e0a626ea5d7; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [2001:4898:80e8:3:7091:9c04:3a30:e8c1] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 10df1f67-9a12-4e93-7258-08d7931fa63f x-ms-traffictypediagnostic: BL0PR2101MB0916: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(136003)(366004)(39860400002)(53754006)(189003)(199004)(76116006)(71200400001)(66946007)(66476007)(66556008)(64756008)(86362001)(66446008)(2906002)(55016002)(316002)(186003)(110136005)(9686003)(10290500003)(6506007)(53546011)(478600001)(8990500004)(7696005)(33656002)(8936002)(966005)(52536014)(5660300002)(81166006)(81156014)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB0916; H:BL0PR2101MB1027.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eBxhcoDEze1c6Ol8FvAgubEu/vNUxDN/ZQDXar7CFw62x3G33MYnK1jRMYQDann12yWlU2ftEONsBrcg1MKwH/mEhc8WOs7LIBfmbWsrf0L7nLr/sgwzV21jUO4bXCDe67BdHi6X08nCWC0o2TZSuPQjBitShvGr2cYzZ8zO1JVaabgl0IKgzj92GXU2f2Sui+3JjQ8AOrCzqQbMU7+FYQALKz2D+uJK4hpMH7RjiLV7Bwt0fucK88uvRDwnwi4sEbytvODz1Jf67OHyW6WAGEo80Z+RaLif1DsaLvLv0hVxzfCtBcyq1UtCywwUFiFFnmmRNTqKmoBRqkW5NYd64nXIhVd1E8R/BmhZSoUQ9TrfWSOFtLqEM4DBmJ2VrfAjf8ei1OUTwnkY/dMNjhtl429KzbFrgz60KSVRW++P+aVk/RzkjCDCkEGA6eQWVxIGdltysWYBp8tIjpLH64XPjEKt6ArtS81FS/HejzPLfVMstSY35IR6wAbA1mpMTjyGpUOSrYWd2hIkzpSYIMTuY5c+uD8AJtOHTXP/y4/mhSsZdLGzvzCXqFN5nbcMJIMd x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB10278417515DEF077714D693A33F0BL0PR2101MB1027_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 10df1f67-9a12-4e93-7258-08d7931fa63f X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 03:14:03.7000 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fpnBDn5Zi6YQnPgJIDxU8z08NITK17d0IkIj+x86RUilMzCeY1qKY/O8zDSUbWeA377f2IIhe7KgbjP/TcYCXYvcOtgde6K5S3rwPCrzZn8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB0916 Archived-At: Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 03:14:08 -0000 --_000_BL0PR2101MB10278417515DEF077714D693A33F0BL0PR2101MB1027_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I opened one pull request for editorial issues (https://github.com/ietf-tee= p/architecture/pull/109), and filed seven other issues listed at https://github.com/ietf-teep/archite= cture/issues 110) Service Provider discussion is confusing 111) Terminology section is not consistently ordered 112) Text about carriers is confusing 113) Section 6.2.3 contradicts section 4.2 114) Figure 3 is too hard to understand 115) Reference to IANA number 116) Incorrect/obsolete statements about TEEP Broker I have ideas about how to address all of them, but if others have comments,= please speak up. The possibly(?) contentious one might be that in #110 I am proposing to use= the term "App Developer" throughout, instead of using "Service Provider" in some pla= ces and "App Developer" in others and then saying they're synonymous like it does now. (I'd be ok with ment= ioning that in some contexts an App Developer might be known as a "Service Provider" if that is important to GlobalPlatfo= rm folks.) Dave From: TEEP On Behalf Of Konda, Tirumaleswar Reddy Sent: Monday, December 23, 2019 4:17 AM To: teep@ietf.org Subject: [Teep] Working Group Last Call for draft-ietf-teep-architecture Hi all, This message starts a Work Group Last Call (WGLC) for TEEP architecture. T= he version to be reviewed is https://tools.ietf.org/html/draft-ietf-teep-ar= chitecture-05 The WGLC will last for 4 weeks and will end on 20 January 2020. Please send your comments to the list before this date and your assessment = of whether or not it is ready to proceed to publication. Regards, Tiru & Nancy --_000_BL0PR2101MB10278417515DEF077714D693A33F0BL0PR2101MB1027_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I opened one pull request for editorial issues (https://github.com/ietf-teep/architecture/pull/109),

and filed seven other issues listed at https://github= .com/ietf-teep/architecture/issues

 

110) Service Provider discussion is confusing<= o:p>

111) Terminology section is not consistently ordered

112) Text about carriers is confusing

113) Section 6.2.3 contradicts section 4.2

114) Figure 3 is too hard to understand

115) Reference to IANA number

116) Incorrect/obsolete statements about TEEP Broker<= /a>

 

I have ideas about how to address all of them, but i= f others have comments, please speak up.

 

The possibly(?) contentious one might be that in #11= 0 I am proposing to use the term

“App Developer” throughout, instead of u= sing “Service Provider” in some places and “App Developer= ” in others

and then saying they’re synonymous like it doe= s now.   (I’d be ok with mentioning that in some contexts a= n App Developer

might be known as a “Service Provider” i= f that is important to GlobalPlatform folks.)

 

Dave=

 

From: TEEP <teep-bounces@ietf.org> O= n Behalf Of Konda, Tirumaleswar Reddy
Sent: Monday, December 23, 2019 4:17 AM
To: teep@ietf.org
Subject: [Teep] Working Group Last Call for draft-ietf-teep-architec= ture

 

Hi all,

 

This message starts a Work Group Last Call (WGLC) fo= r TEEP architecture.  The version to be reviewed is https://tools.ietf.org/html/draft-ietf-teep-architecture-05 =

 

The WGLC will last for 4 weeks and will end on 20 Ja= nuary 2020.

 

Please send your comments to the list before this da= te and your assessment of whether or not it is ready to proceed to publicat= ion.

 

Regards,

Tiru & Nancy

--_000_BL0PR2101MB10278417515DEF077714D693A33F0BL0PR2101MB1027_-- From nobody Mon Jan 6 22:38:57 2020 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A71120091 for ; Mon, 6 Jan 2020 22:38:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFd95vFjpOAk for ; Mon, 6 Jan 2020 22:38:52 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [63.128.21.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B497E12001B for ; Mon, 6 Jan 2020 22:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1578379130; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QCNq4nn9b6KaXAY7Fw47K616Un1MTePiFjTl2RXAzdw=; b=dKa4mYbfb1NFuxR2HvHRnnbQ+zL8zjQy0Z914q/G4GN8YK34rhmomr1L/tnsMeYKaydGYJ /MI0F/f/yFxlhmShhX5IVCA9x4KTp5d7Vu3ZrT54o7t6+u++ht8MuQHdWZuEECFQUlK37p dKVQZXY1f3C6x63tC+F9iMRrWqg4fc8= Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2051.outbound.protection.outlook.com [104.47.38.51]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-380-FUPAHjO1NH28CV-cE5HbTg-1; Tue, 07 Jan 2020 01:38:47 -0500 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1112.namprd16.prod.outlook.com (10.172.117.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Tue, 7 Jan 2020 06:38:44 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::a50e:f380:4d5e:71ea]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::a50e:f380:4d5e:71ea%6]) with mapi id 15.20.2602.015; Tue, 7 Jan 2020 06:38:44 +0000 From: "Konda, Tirumaleswar Reddy" To: Dave Thaler , "teep@ietf.org" Thread-Topic: Working Group Last Call for draft-ietf-teep-architecture Thread-Index: AdW5iepOELmpRRFXSAWsc0EhHQP19ALfbySAAAc0BIA= Date: Tue, 7 Jan 2020 06:38:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-01-07T03:14:02.9467153Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=113fc599-cef6-4df9-bb00-5e0a626ea5d7; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cac19ac2-e1db-4f58-4df3-08d7933c3e42 x-ms-traffictypediagnostic: CY4PR1601MB1112: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(346002)(366004)(39860400002)(396003)(53754006)(32952001)(199004)(189003)(8676002)(81166006)(64756008)(71200400001)(7696005)(45080400002)(8936002)(76116006)(66946007)(81156014)(26005)(66476007)(21615005)(186003)(66556008)(66446008)(478600001)(33656002)(66574012)(52536014)(9686003)(55016002)(2906002)(966005)(86362001)(316002)(110136005)(53546011)(6506007)(5660300002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1112; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hLBivJ7ZFZxsvoK4pimJGXvpUjowS9XXCM0XculBdJCGZUnVdEIoibphHYH3/OAs/Rr7IQPvZWm7Z6scGsAVIyxVvTppDUQ30He58Zfni0TK+gshI3iFbkoaisaJquXOB5Se2acZJm7O/KoCa7rQWGCNBQ2bDIV0dvbsnoKpJNCrJoH+bW6XmftHc6c1ySVEY0tMLfOF6riVJNyklPO10mH9T1j9Htr8h5ZnU2qvut6M50HoEE/YBe6HQjRrvZ/MRBzkD7qFHbrgIqGF4p7YWWws2Vr/Fm4d0HsgoT5hXkTaIvRGZrCVmUUHUN/FdzfRlfsMn8ijKMLYwfe3thvFVhh3lM3F0ybmsFunt6Xs7cRbfEfngXG3i1zwK+v9B+zWrjW68xwpD4bSbebLCg4VHvks47U/+n6QVzLik/K6dFBomGfxlI8NdjUfTkDcD/Xy60KdTseG9AC8ZPh+QXQ9m+xjNMNHosufD4Acwk8hBqG9iSS8khiwrlexUa6AnGP3aTBgmfuefQCIkD0FwJvYfhRZ4oDQ8JwQb20RcxvanaHl8e4FXJuINWgQgWWPr2CmxopG4l4XQt394ao+NOy4Wg== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: cac19ac2-e1db-4f58-4df3-08d7933c3e42 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 06:38:44.6778 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Viaf1kY1TLnmsQFXYcne/r1sWn4hs/PWG+t3qWP7eAqMhydqKBX5cOFJBfZjUGDyrXvhQfuY/VYqwmoxEDhHDUNTIg2bSJSo1C9m/mxn/olagW3WfOlknxt4EdYn9vkX X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1112 X-MC-Unique: FUPAHjO1NH28CV-cE5HbTg-1 X-Mimecast-Spam-Score: 0 Content-Type: multipart/alternative; boundary="_000_CY4PR1601MB125400678B0DA9EE37683FBBEA3F0CY4PR1601MB1254_" Archived-At: Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 06:38:56 -0000 --_000_CY4PR1601MB125400678B0DA9EE37683FBBEA3F0CY4PR1601MB1254_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable [As an individual] Hi Dave, I have reviewed the draft and have comments and nits listed below: a) It is not clear from the Introduction how TEE is different from a Closed= OS like Google Chromebook or Windows 10S ? The benefit of Payment application running in Closed OS verses in TEE = is not evident from the description. What part of the Payment application r= uns in the REE and TEE respectively ? If biometric identification information is securely stored in TEE for = identification, how does the TEE identify the biometric identification info= rmation is not retrieved by an malicious agent in the REE. Section 3.3 (Internet of things), How does the architecture ensure the= sensitive data is retrieved by a legitimate application in the REE and not= by an malicious application ? b) Why should the list of trust anchors on the device be managed by the Dev= ice's network carrier ? (you may want to define the term "network carrier"). c) If the REE is compromised (for example by malware), it could terminate t= he TEEP broker in REE. How is this attack mitigated ? d) What happens if the malicious agent acting as TEEP broker launches attac= ks (e.g. garbage data, replay attack, DoS of messages etc.,) on the TEEP ag= ent, and how will the TEEP agent defend itself ? e) The below line is not clear to me: Enumeration and access to the appropriate TEEP Broker is up to the Rich Exe= cution Environment and the Untrusted Applications. h) A use case explaining the use of multiple TAM, multiple TEEP brokers on = a device, and multiple TEE would be useful to the reader of the specificati= on. i) When a TEEP Broker receives a request from an Untrusted Application to install a TA, a list of TAM URIs may be provided for that TA, and the request is passed to the TEEP Agent. If the TEEP Agent decides that the TA needs to be installed, the TEEP Agent selects a single TAM URI that is consistent with the list of trusted TAMs provisioned on the device invokes the HTTP transport for TEEP to connect to the TAM URI and begins a TEEP protocol exchange. Comment> I am not sure why the architecture draft is discussing the protoco= l aspects like HTTP for TEEP ? j) What if the malware in REE instructs the TEEP agent via TEEP broker to k= eep installing/uninstalling TA (over-whelm the TEEP agent and TEE or instal= ling un-necessary TA to have no memory for the required TA) ? i) What is the use case for "Personalization data" ? j) Why is Section 4.5 discussing Case 1 when it not in use ? k) The below line is not clear to me (please elaborate): Consequently, a TAM generally communicates with an Untrusted Application ab= out how it gets messages that originate from a TEE inside a device. l) What is the use case for one TA and multiple SP ? m) what is the use case for keeping the TA binary secret from the TAM ? n) We allow a way for an Untrusted Application to check the trustworthiness= of a TA. Comment> You may want to re-phrase the above line, and remove "we". o) A notification that an incoming TEEP session is being requested by a TEE= P Agent. Comment> What you meant by "incoming TEEP session" ? p) How does the TEEP broker communicate with the TEEP agent ? q) Section 5.3 says the architecture uses PKI but Section 9.1 discusses sel= f-signed certificates. Please fix. r) In Figure 4, for the purpose of "Code signing" my understanding is the l= ocation of corresponding CA certs is both TEE and TAM. s)I have seen several malicious apps in App store in both Android and iOS, = it is possible for an malicious App developer to publish both malicious unt= rusted applications and malicious trusted applications. I don't think the TEEP architecture= prevents this attack and it is the responsibility of TAM and App store to = remove such apps (see https://android-developers.googleblog.com/2018/01/how-we-fought-ba= d-apps-and-malicious.html) Cheers, -Tiru From: Dave Thaler Sent: Tuesday, January 7, 2020 8:44 AM To: Konda, Tirumaleswar Reddy ; teep@ie= tf.org Subject: RE: Working Group Last Call for draft-ietf-teep-architecture CAUTION: External email. Do not click links or open attachments unless you = recognize the sender and know the content is safe. ________________________________ I opened one pull request for editorial issues (https://github.com/ietf-tee= p/architecture/pull/109), and filed seven other issues listed at https://github.com/ietf-teep/archite= cture/issues 110) Service Provider discussion is confusing 111) Terminology section is not consistently ordered 112) Text about carriers is confusing 113) Section 6.2.3 contradicts section 4.2 114) Figure 3 is too hard to understand 115) Reference to IANA number 116) Incorrect/obsolete statements about TEEP Broker I have ideas about how to address all of them, but if others have comments,= please speak up. The possibly(?) contentious one might be that in #110 I am proposing to use= the term "App Developer" throughout, instead of using "Service Provider" in some pla= ces and "App Developer" in others and then saying they're synonymous like it does now. (I'd be ok with ment= ioning that in some contexts an App Developer might be known as a "Service Provider" if that is important to GlobalPlatfo= rm folks.) Dave From: TEEP > On Behalf = Of Konda, Tirumaleswar Reddy Sent: Monday, December 23, 2019 4:17 AM To: teep@ietf.org Subject: [Teep] Working Group Last Call for draft-ietf-teep-architecture Hi all, This message starts a Work Group Last Call (WGLC) for TEEP architecture. T= he version to be reviewed is https://tools.ietf.org/html/draft-ietf-teep-ar= chitecture-05 The WGLC will last for 4 weeks and will end on 20 January 2020. Please send your comments to the list before this date and your assessment = of whether or not it is ready to proceed to publication. Regards, Tiru & Nancy --_000_CY4PR1601MB125400678B0DA9EE37683FBBEA3F0CY4PR1601MB1254_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

[As an individual]

 

Hi Dave,

 

I have reviewed the draft and have comments and n= its listed below:

 

a) It is not clear from the Introduction how TEE = is different from a Closed OS like Google Chromebook or Windows 10S ?<= /o:p>

     The benefit of Payment a= pplication running in Closed OS verses in TEE is not evident from the descr= iption. What part of the Payment application runs in the REE and TEE respec= tively ?

     If biometric identificat= ion information is securely stored in TEE for identification, how does the = TEE identify the biometric identification information is not retrieved by a= n malicious agent in the REE.

     Section 3.3 (Internet of= things), How does the architecture ensure the sensitive data is retrieved = by a legitimate application in the REE and not by an malicious application = ?  

   

b) Why should the list of trust anchors on the de= vice be managed by the Device's network carrier ?

     (you may want to define = the term "network carrier").

 

c) If the REE is compromised (for example by malw= are), it could terminate the TEEP broker in REE. How is this attack mitigat= ed ?

 

d) What happens if the malicious agent acting as = TEEP broker launches attacks (e.g. garbage data, replay attack, DoS of mess= ages etc.,) on the TEEP agent, and how will the TEEP agent defend itself ?<= o:p>

 

e) The below line is not clear to me:<= /p>

Enumeration and access to the appropriate TEEP Br= oker is up to the Rich Execution Environment and the Untrusted Applications= .

 

h) A use case explaining the use of multiple TAM,= multiple TEEP brokers on a device, and multiple TEE would be useful to the= reader of the specification.

 

i) When a TEEP Broker receives a request from an = Untrusted Application

   to install a TA, a list of TAM URIs = may be provided for that TA, and

   the request is passed to the TEEP Ag= ent.  If the TEEP Agent decides

   that the TA needs to be installed, t= he TEEP Agent selects a single

   TAM URI that is consistent with the = list of trusted TAMs provisioned

   on the device invokes the HTTP trans= port for TEEP to connect to the

   TAM URI and begins a TEEP protocol e= xchange.

 

Comment> I am not sure why the architecture dr= aft is discussing the protocol aspects like HTTP for TEEP ?

 

j) What if the malware in REE instructs the TEEP = agent via TEEP broker to keep installing/uninstalling TA (over-whelm the TE= EP agent and TEE or installing un-necessary TA to have no memory for the re= quired TA) ?

 

i) What is the use case for "Personalization= data" ?

 

j) Why is Section 4.5 discussing Case 1 when it n= ot in use ?

 

k) The below line is not clear to me (please elab= orate):

Consequently, a TAM generally communicates with a= n Untrusted Application about how it gets messages that originate from a TE= E inside a device.

 

l) What is the use case for one TA and multiple S= P ?

 

m) what is the use case for keeping the TA binary= secret from the TAM ?

 

n) We allow a way for an Untrusted Application to= check the trustworthiness of a TA.

 

Comment> You may want to re-phrase the above l= ine, and remove "we".

 

o) A notification that an incoming TEEP session i= s being requested by a TEEP Agent.

 

Comment> What you meant by "incoming TEEP= session" ?

 

p) How does the TEEP broker communicate with the = TEEP agent ?

 

q) Section 5.3 says the architecture uses PKI but= Section 9.1 discusses self-signed certificates. Please fix.

 

r) In Figure 4, for the purpose of "Code sig= ning" my understanding is the location of corresponding CA certs is bo= th TEE and TAM.

 

s)I have seen several malicious apps in App store= in both Android and iOS, it is possible for an malicious App developer to = publish both malicious untrusted applications

   and malicious trusted applicati= ons.  I don't think the TEEP architecture prevents this attack and it = is the responsibility of TAM and App store to remove such apps

    (see https://android-developers.googleblog.com/2018/01/how-we-fought-bad-apps-an= d-malicious.html)

 

Cheers,

-Tiru

 

From: Dave Thaler <dthaler@microsoft.com&g= t;
Sent: Tuesday, January 7, 2020 8:44 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; teep@ietf.org
Subject: RE: Working Group Last Call for draft-ietf-teep-architectur= e

 

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.<= /span><= /span>

 

I opened one pull request for editorial issues (https://github.com/ietf-teep/architecture/pull/109),

and filed seven other issues listed at https://github= .com/ietf-teep/architecture/issues

 

110) Service Provider discussion is confusing<= o:p>

111) Terminology section is not consistently ordered

112) Text about carriers is confusing

113) Section 6.2.3 contradicts section 4.2

114) Figure 3 is too hard to understand

115) Reference to IANA number

116) Incorrect/obsolete statements about TEEP Broker<= /a>

 

I have ideas about how to address all of them, but i= f others have comments, please speak up.

 

The possibly(?) contentious one might be that in #11= 0 I am proposing to use the term

“App Developer” throughout, instead of u= sing “Service Provider” in some places and “App Developer= ” in others

and then saying they’re synonymous like it doe= s now.   (I’d be ok with mentioning that in some contexts a= n App Developer

might be known as a “Service Provider” i= f that is important to GlobalPlatform folks.)

 

Dave=

 

From: TEEP <teep-bounces@ietf.org> On Behalf Of Konda, Tirumaleswar Reddy
Sent: Monday, December 23, 2019 4:17 AM
To: teep@ietf.org
Subject: [Teep] Working Group Last Call for draft-ietf-teep-architec= ture

 

Hi all,

 

This message starts a Work Group Last Call (WGLC) fo= r TEEP architecture.  The version to be reviewed is https://tools.ietf.org/html/draft-ietf-teep-architecture-05 =

 

The WGLC will last for 4 weeks and will end on 20 Ja= nuary 2020.

 

Please send your comments to the list before this da= te and your assessment of whether or not it is ready to proceed to publicat= ion.

 

Regards,

Tiru & Nancy

--_000_CY4PR1601MB125400678B0DA9EE37683FBBEA3F0CY4PR1601MB1254_-- From nobody Tue Jan 7 01:28:27 2020 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD8912006E for ; Tue, 7 Jan 2020 01:28:25 -0800 (PST) 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, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=fziXMPUf; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=xdnC+Lh9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzJomtDU7nH2 for ; Tue, 7 Jan 2020 01:28:19 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2075.outbound.protection.outlook.com [40.107.20.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 C1726120019 for ; Tue, 7 Jan 2020 01:28:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SDvwuLNGcsFblQkEMnUXJzeApxhqyBnjctXoN1vwS7Q=; b=fziXMPUf5bjBK4yfsCUNNdrgT8rF5OfNczYc3OARayAgQRuA3EPqKDHReKGS6hgWg507buaPjXCqgDD5XEXATnay89CgIq9oMsga5qOehdkOJy3Su0P2lVFKSO8MEXZktjJe74VkkWpSMSSt4Rz2m0nSd6xQJ7YD5/xc1eF8ujI= Received: from VI1PR08CA0144.eurprd08.prod.outlook.com (2603:10a6:800:d5::22) by AM6PR08MB3607.eurprd08.prod.outlook.com (2603:10a6:20b:4c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.15; Tue, 7 Jan 2020 09:28:14 +0000 Received: from AM5EUR03FT060.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e08::205) by VI1PR08CA0144.outlook.office365.com (2603:10a6:800:d5::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.10 via Frontend Transport; Tue, 7 Jan 2020 09:28:14 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT060.mail.protection.outlook.com (10.152.16.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11 via Frontend Transport; Tue, 7 Jan 2020 09:28:14 +0000 Received: ("Tessian outbound 28955e0c1ca8:v40"); Tue, 07 Jan 2020 09:28:13 +0000 X-CR-MTA-TID: 64aa7808 Received: from a77fa2eb52eb.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id FE0D492E-9FD1-4F52-B08E-48FA19AC5C7A.1; Tue, 07 Jan 2020 09:28:08 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id a77fa2eb52eb.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Tue, 07 Jan 2020 09:28:08 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hAxI8S/df2j7QieamncMV8HOokxeqhLhbF0nGbHZpiNjiqVpt+EGFWaq+R83CH8rlsPGtPA6KB6XU7dALtJ2thHWmxoG8xhnFmonD0ag93yMD96v3VTBCLgaDdFrjf3EHZnA3nHfzmOQGLSb8Xw4TEOoqbtDHwfWI+A8dAW9woewifKx/qGY/EnqfO5J6VPnsB9yr88AfxmddimiX//f1zqdG6nQt7ynn48zG0t6YKkMAFI4VprkoL3XUvvKLV9jxXvR2mHHcbK2PIsfOY9KBixEDonbzxujpgyH3+y6/cXI/XUnHMN0MB0FlNe5mwctbktFx4zGHe48mHl41zuN8g== 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=YfAGUb5R7d0u9keUWVo0xLu009hWW5aL78ssslUODaw=; b=C1CQO9tSGq2LKkrx/F4DKM6S8v+iKLdvKTKzR6Ru8/BvPkUPIJGjGDbacLeuutLZrnUsw77DaQQzzqiRrtKNBMsKkCBaVHILqq+RjBZ2td2/zObZ5YLAECL5gTkVdyRZs4IRY2ptV9/jd2reiL3JczUe2FeSHasU/6pZ5IRA0lZ7NdRxlxCunMrOPrnfUBvJSQv1WA56X/XN38plEFrfvtJaQnWQ6Xm8Aop8dcWgi4nAwV6egnJoE6LxiX4Vdej3mFVDsBFveRq1sQv80IRMA8CtJHqGeLpWH78jj8ENuOwo6vE6/rGNmQpU4bNeEotozM9QAMQNqv7W6AIyr5iETA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YfAGUb5R7d0u9keUWVo0xLu009hWW5aL78ssslUODaw=; b=xdnC+Lh97FZ0otf7mjfCjPMbfBmLO/Rj4jyd7leWu5/9RqzT7dd9wHxoXAkAdXyRFumAx3vPoImlye3TWov0KERD0OL95ENlN1gmO4cEUxTdY16s+tRf4q5/qE6KDYbF2Pslg1yHyHeYcCIZ81kmr8zBmznLnwfxx7MYAbjy3O0= Received: from AM6PR08MB5285.eurprd08.prod.outlook.com (20.179.0.161) by AM6PR08MB5190.eurprd08.prod.outlook.com (10.255.121.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.12; Tue, 7 Jan 2020 09:28:07 +0000 Received: from AM6PR08MB5285.eurprd08.prod.outlook.com ([fe80::1581:c3da:22ee:41b9]) by AM6PR08MB5285.eurprd08.prod.outlook.com ([fe80::1581:c3da:22ee:41b9%7]) with mapi id 15.20.2602.016; Tue, 7 Jan 2020 09:28:07 +0000 From: Hannes Tschofenig To: "Konda, Tirumaleswar Reddy" , Dave Thaler , "teep@ietf.org" Thread-Topic: Working Group Last Call for draft-ietf-teep-architecture Thread-Index: AdW5iepOELmpRRFXSAWsc0EhHQP19ALfbySAAAc0BIAABIf9gA== Date: Tue, 7 Jan 2020 09:28:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-01-07T03:14:02.9467153Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=113fc599-cef6-4df9-bb00-5e0a626ea5d7; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic x-ts-tracking-id: f82990ee-e9c5-4072-ba90-dd8c85adf679.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [195.149.223.43] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 112fe00f-cbe7-4fe2-abfc-08d79353ebad X-MS-TrafficTypeDiagnostic: AM6PR08MB5190:|AM6PR08MB3607: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:9508;OLM:9508; x-forefront-prvs: 027578BB13 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(39860400002)(396003)(376002)(366004)(51914003)(53754006)(189003)(199004)(55016002)(52536014)(71200400001)(9686003)(81156014)(81166006)(8676002)(8936002)(478600001)(21615005)(45080400002)(966005)(76116006)(6506007)(26005)(53546011)(7696005)(64756008)(66946007)(66446008)(33656002)(66476007)(66556008)(110136005)(2906002)(9326002)(30864003)(86362001)(5660300002)(186003)(316002)(66574012); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB5190; H:AM6PR08MB5285.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: WT+w9WhKbtCPnsIPYTPPUKyuavS0WgWJ6tiFw2ueB5Zv6B5vpOaxxJw+BPLOjvQ2PNcAowSwzs6ptTVrz4WIoXofFBuVT3FUx8YKHXXiq4nU0mx2AKi/lAqOzb6F/x/SOxsEPtZL1B5kjEjhBaWMTY2+Vrh3mbgPoyeRc76IkrWrhs4vlYBu+M5F+pVghMxd9aovmt/ppfENQeLqeqOjBRcCxRQ1kQFrmpxyP4yn6v3d+vIBcKODByiqYekc4brZuwbifap4nCLJHcIYlZMTBGhqHER8JZSMXpug73Za6xGzJetk9x5CYaNdcPsvb7nyjImNxhurbG3Nie6eMlKHw7ELU2TVi/10yokryQRPbIcBtG7qVIMRDJHzbKsMs+GRVZysy6S0YnKGGPFkLzO5WNBEXn1tak3Yow5hfPWBSxVckajXrqHd4w3/1E6dZ7MZ+XBp19PMEBTPFP6LPPLXjS23OlM8PHpsaP5j/xk1U7jCijojuR84duYEVf0147QPwl+t7Jrw41q76/HU3DHk5BMFwSK3MQYUofSvG2mrSsb9mbGZDPiWGn3AnQtjZQiTInNur9TuBr2OfXi6b+/JLA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR08MB5285F0C0209A745F1FAABA23FA3F0AM6PR08MB5285eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB5190 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT060.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(376002)(346002)(136003)(51914003)(53754006)(199004)(189003)(40434004)(8676002)(356004)(26826003)(8936002)(186003)(336012)(478600001)(45080400002)(26005)(9326002)(966005)(81166006)(81156014)(70586007)(9686003)(21615005)(86362001)(70206006)(36906005)(110136005)(5660300002)(53546011)(7696005)(55016002)(52536014)(2906002)(33656002)(30864003)(66574012)(6506007)(316002)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3607; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; A:1; MX:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: a64b7d00-9ffe-435d-0c7f-08d79353e7aa X-Forefront-PRVS: 027578BB13 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: x6R83FS4I/SWb1gHU8TcFFLeL/U2407spAKuuuOTep5L2DroY8VuVMec2YCnC1XwXIVvY8ORKGFQ1ccaSjYROy3FZu2nmKN5EgK8Tbww12OkXzN//0yzdqmPpQlUmtNAgyU63hHgTab4v0ewDwvbg9rVs3ib7+JMN0hpgHo0xeRh3O9y9X88TnG0dn2Mq61foD5XZFVkWgwqlbCnHtEpuTmyx6dlcdpZzFXM0ntMagoAwgpP9gqorTBqsc+09a/xZqGyNyFBBEZFvQFMoHjhosjRztv8vmeGQyiT1cjyMeL/uGB29Hj6ptzuL0UOd3FYdf8KshCUC7c9QjPeFRWUB0GvzsrYoF36eInvLeiwy8ujBbs0uRCDZHDj22Or+H8YEw6arfPcrIQ555hNcMNCANaQVWIZXn1DQGIuU8wfgiwCj/wXl1bThY8+bB4IYWzdtU8LBO4I++4NdWC+QoC4xNeZmkdQS9WDdx1OYIRUo6ZG0cuFYN/xxI8uOrnkv4MWNKtfWtfYrsZUqv0vAf5zIpA7NeDVMuopXwsqPDVYiNfkdkAQsHBgsDsiuF/g8U3tJqn97HZ19zTfh8PxTA2Eqa5Z9dJYUgLIpYobVSottUQ= X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2020 09:28:14.1020 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 112fe00f-cbe7-4fe2-abfc-08d79353ebad X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3607 Archived-At: Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 09:28:26 -0000 --_000_AM6PR08MB5285F0C0209A745F1FAABA23FA3F0AM6PR08MB5285eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tiru, Thanks for the review. There is clearly room for improving the write-up. A few remarks below. From: TEEP On Behalf Of Konda, Tirumaleswar Reddy Sent: Tuesday, January 7, 2020 7:39 AM To: Dave Thaler ; teep@ietf.org Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architectur= e [As an individual] Hi Dave, I have reviewed the draft and have comments and nits listed below: a) It is not clear from the Introduction how TEE is different from a Closed= OS like Google Chromebook or Windows 10S ? The benefit of Payment application running in Closed OS verses in TEE = is not evident from the description. What part of the Payment application r= uns in the REE and TEE respectively ? If biometric identification information is securely stored in TEE for = identification, how does the TEE identify the biometric identification info= rmation is not retrieved by an malicious agent in the REE. Section 3.3 (Internet of things), How does the architecture ensure the= sensitive data is retrieved by a legitimate application in the REE and not= by an malicious application ? [Hannes] The TEE adds another layer of software isolation. To protect one T= A to steal data from another TA the two TAs need to be isolated against eac= h other. Depending on the TEE technology you are using this is accomplished= via different means. It is up to the application developer to decide how they best want to separ= ate the REE and the TEE part, which in part depends a bit on what type of p= ayment protocol they are using. In some other cases (probably more realisti= c) they may be using an already existing payment system, which is provided = as a TA, and they are just using it. In general, it does not strike me as a= great idea to have random smart phone app developers writing their own pay= ment software. b) Why should the list of trust anchors on the device be managed by the Dev= ice's network carrier ? (you may want to define the term "network carrier"). [Hannes] The text says the following: " The list of Trust Anchors is normally modifiable by the Device's owner or Device Administrator. However the Device manufacturer and network carrier may restrict some modifications, for example, by not allowing the manufacturer or carrier's Trust Anchor to be removed or disabled. " This describes current practice in the mobile phone industry and may not ne= cessarily be applicable to other deployment scenarios. Hence, there is no r= equired behavior here. c) If the REE is compromised (for example by malware), it could terminate t= he TEEP broker in REE. How is this attack mitigated ? [Hannes] If the REE is compromised then that's typically not a good thing b= ut the REE side still cannot access anything on the secure world, if implem= ented correctly. It could, however, indeed terminate the TEEP broker and av= oid any calls to the secure world. This would be a DoS attack. It would be = possible to periodically schedule an interrupt that is processed by the sec= ure world to let the secure world double-check the state of the normal worl= d. d) What happens if the malicious agent acting as TEEP broker launches attac= ks (e.g. garbage data, replay attack, DoS of messages etc.,) on the TEEP ag= ent, and how will the TEEP agent defend itself ? [Hannes] The TEEP agent dispatches calls to the trusted applications. It is= typically a shim layer that just checks parameters of the requests and the= n relays them to the TAs. Having a rock solid implementation of the TEEP ag= ent is important and of course the TAs need to be implemented properly as w= ell. The GP TEE Client API is meant to provide a reference design for an API tha= t allows data passing back and forth. So, implementing that API properly wi= ll be important. This is why there is this open source project to implement= that API so that other developers can just use it. e) The below line is not clear to me: Enumeration and access to the appropriate TEEP Broker is up to the Rich Exe= cution Environment and the Untrusted Applications.. [Hannes] There may be multiple TEEP Brokers on the system and the interacti= on between untrusted apps and the TEEP broker is up to a policy implemented= by the developer. h) A use case explaining the use of multiple TAM, multiple TEEP brokers on = a device, and multiple TEE would be useful to the reader of the specificati= on. [Hannes] Definitely a good idea to add text with use cases. Here is my quick response: * Multiple TAMs: you could think about this as having multiple code rep= ositories. Different SPs may prefer to use certain TAMs for their software = distribution. * Multiple TEEP brokers: this can occur when you have a broker offered = by the OS and one bundled with the untrusted app. * Multiple TEEs: This depends on the TEE technology. In the TrustZone c= ase you may have a multi-processor system and each processor comes with Tru= stZone support. i) When a TEEP Broker receives a request from an Untrusted Application to install a TA, a list of TAM URIs may be provided for that TA, and the request is passed to the TEEP Agent. If the TEEP Agent decides that the TA needs to be installed, the TEEP Agent selects a single TAM URI that is consistent with the list of trusted TAMs provisioned on the device invokes the HTTP transport for TEEP to connect to the TAM URI and begins a TEEP protocol exchange. Comment> I am not sure why the architecture draft is discussing the protoco= l aspects like HTTP for TEEP ? [Hannes] I believe it does not need to mention HTTP but it could list it as= an example. j) What if the malware in REE instructs the TEEP agent via TEEP broker to k= eep installing/uninstalling TA (over-whelm the TEEP agent and TEE or instal= ling un-necessary TA to have no memory for the required TA) ? [Hannes] Having a compromised REE environment that causes all sorts of apps= to be installed is possible (assuming the TEE is authorizing the installat= ion of those apps). An implementation of the secure world, most likely the = TEE OS, will have to make sure that the device does not install TAs and ove= rwrite the memory space they have been configured to use. i) What is the use case for "Personalization data" ? [Hannes] Personalization data is meant to make each instance of the TA uniq= ue and potentially tie it to a specific user. Imagine a TA that implements = biometric functionality: there has to be something in TA that relates this = instance of the TA to a specific human, for example by storing a fingerprin= t alongside the TA as configuration data. j) Why is Section 4.5 discussing Case 1 when it not in use ? [Hannes] We just describe the possible approach and illustrates how things = are done today. There is, however, a lot of development going on in the are= a of TEEs and I suspect that we will see all sorts of different use cases s= howing up in the future as the technology gets used in different environmen= ts. k) The below line is not clear to me (please elaborate): Consequently, a TAM generally communicates with an Untrusted Application ab= out how it gets messages that originate from a TEE inside a device. [Hannes] The key point of that paragraph is that today TEEs do not communic= ate with the outside world but require the cooperation with something on th= e REE side. l) What is the use case for one TA and multiple SP ? [Hannes] I am not sure. I let Ming, DaveW, or DaveT respond. m) what is the use case for keeping the TA binary secret from the TAM ? [Hannes] it is more and more common today to protect binaries from inspecti= on because this gives attackers a lot of information. If you don't want to = use it and only sign the binaries that's fine too. But the option is there = for you to protect the confidentiality of the binary. n) We allow a way for an Untrusted Application to check the trustworthiness= of a TA. Comment> You may want to re-phrase the above line, and remove "we". [Hannes] I think we should delete this paragraph: " We allow a way for an Untrusted Application to check the trustworthiness of a TA. A TEEP Broker has a function to allow an application to query the information about a TA. " o) A notification that an incoming TEEP session is being requested by a TEE= P Agent. Comment> What you meant by "incoming TEEP session" ? [Hannes] Dave should respond to this one because it relates to the HTTP tra= nsport, I believe. p) How does the TEEP broker communicate with the TEEP agent ? [Hannes] Via an API, for example the GP TEEP Client API. q) Section 5.3 says the architecture uses PKI but Section 9.1 discusses sel= f-signed certificates. Please fix. [Hannes] We need to clarify the statement about the self-signed TA binaries= . r) In Figure 4, for the purpose of "Code signing" my understanding is the l= ocation of corresponding CA certs is both TEE and TAM. [Hannes] I believe it would be useful to also store the CA cert that is use= d for code signing at the TAM because then it can verify the signed TAs. If we indeed believe the text in Section 9.1 is correct then that code sign= ing CA cert also needs to be made available to the TEEP Broker and potentia= lly even to the untrusted app. s)I have seen several malicious apps in App store in both Android and iOS, = it is possible for an malicious App developer to publish both malicious unt= rusted applications and malicious trusted applications. I don't think the TEEP architecture= prevents this attack and it is the responsibility of TAM and App store to = remove such apps (see https://android-developers.googleblog.com/2018/01/how-we-fought-ba= d-apps-and-malicious.html) [Hannes] Yes, it would be the responsibility of the TAM, the device manufac= turer and the SP / developer to ensure that they do not distribute maliciou= s TAs. Ciao Hannes Cheers, -Tiru From: Dave Thaler > Sent: Tuesday, January 7, 2020 8:44 AM To: Konda, Tirumaleswar Reddy >; teep@ietf.org Subject: RE: Working Group Last Call for draft-ietf-teep-architecture CAUTION: External email. Do not click links or open attachments unless you = recognize the sender and know the content is safe. ________________________________ I opened one pull request for editorial issues (https://github.com/ietf-tee= p/architecture/pull/109), and filed seven other issues listed at https://github..com/ietf-teep/archit= ecture/issues 110) Service Provider discussion is confusing 111) Terminology section is not consistently ordered 112) Text about carriers is confusing 113) Section 6.2.3 contradicts section 4.2 114) Figure 3 is too hard to understand 115) Reference to IANA number 116) Incorrect/obsolete statements about TEEP Broker I have ideas about how to address all of them, but if others have comments,= please speak up. The possibly(?) contentious one might be that in #110 I am proposing to use= the term "App Developer" throughout, instead of using "Service Provider" in some pla= ces and "App Developer" in others and then saying they're synonymous like it does now. (I'd be ok with ment= ioning that in some contexts an App Developer might be known as a "Service Provider" if that is important to GlobalPlatfo= rm folks.) Dave From: TEEP > On Behalf = Of Konda, Tirumaleswar Reddy Sent: Monday, December 23, 2019 4:17 AM To: teep@ietf.org Subject: [Teep] Working Group Last Call for draft-ietf-teep-architecture Hi all, This message starts a Work Group Last Call (WGLC) for TEEP architecture. T= he version to be reviewed is https://tools.ietf.org/html/draft-ietf-teep-ar= chitecture-05 The WGLC will last for 4 weeks and will end on 20 January 2020. Please send your comments to the list before this date and your assessment = of whether or not it is ready to proceed to publication. Regards, Tiru & Nancy IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM6PR08MB5285F0C0209A745F1FAABA23FA3F0AM6PR08MB5285eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tiru,

 

Thanks for the review. There is clearly room for imp= roving the write-up.

 

A few remarks below.

 

From: TEEP <teep-bounces@ietf.org> O= n Behalf Of Konda, Tirumaleswar Reddy
Sent: Tuesday, January 7, 2020 7:39 AM
To: Dave Thaler <dthaler@microsoft.com>; teep@ietf.org
Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-arch= itecture

 

[As an individual]

 

Hi Dave,

 

I have reviewed the draft and have comments and n= its listed below:

 

a) It is not clear from the Introduction how TEE = is different from a Closed OS like Google Chromebook or Windows 10S ?<= /o:p>

     The benefit of Payment a= pplication running in Closed OS verses in TEE is not evident from the descr= iption. What part of the Payment application runs in the REE and TEE respec= tively ?

     If biometric identificat= ion information is securely stored in TEE for identification, how does the = TEE identify the biometric identification information is not retrieved by a= n malicious agent in the REE.

     Section 3.3 (Internet of= things), How does the architecture ensure the sensitive data is retrieved = by a legitimate application in the REE and not by an malicious application = ?  

 

[Hannes] The TEE adds another layer of software i= solation. To protect one TA to steal data from another TA the two TAs need = to be isolated against each other. Depending on the TEE technology you are = using this is accomplished via different means.

 

It is up to the application developer to decide h= ow they best want to separate the REE and the TEE part, which in part depen= ds a bit on what type of payment protocol they are using. In some other cas= es (probably more realistic) they may be using an already existing payment system, which is provided as a TA= , and they are just using it. In general, it does not strike me as a great = idea to have random smart phone app developers writing their own payment so= ftware.

 

b) Why should the list of trust anchors on the de= vice be managed by the Device's network carrier ?

     (you may want to define = the term "network carrier").

 

[Hannes] The text says the following: =

 

“

The list of Trust Anchors is normally modifiab= le

      by the Device's= owner or Device Administrator.  However the Device<= /p>

      manufacturer an= d network carrier may restrict some modifications,

      for example, by= not allowing the manufacturer or carrier's Trust

      Anchor to be re= moved or disabled.

“

 

This describes current practice in the mobile pho= ne industry and may not necessarily be applicable to other deployment scena= rios. Hence, there is no required behavior here.

 

 

c) If the REE is compromised (for example by malw= are), it could terminate the TEEP broker in REE. How is this attack mitigat= ed ?

 

[Hannes] If the REE is compromised then that̵= 7;s typically not a good thing but the REE side still cannot access anythin= g on the secure world, if implemented correctly. It could, however, indeed = terminate the TEEP broker and avoid any calls to the secure world. This would be a DoS attack. It would be possibl= e to periodically schedule an interrupt that is processed by the secure wor= ld to let the secure world double-check the state of the normal world.=

 

d) What happens if the malicious agent acting as = TEEP broker launches attacks (e.g. garbage data, replay attack, DoS of mess= ages etc.,) on the TEEP agent, and how will the TEEP agent defend itself ?<= o:p>

 

[Hannes] The TEEP agent dispatches calls to the t= rusted applications. It is typically a shim layer that just checks paramete= rs of the requests and then relays them to the TAs. Having a rock solid imp= lementation of the TEEP agent is important and of course the TAs need to be implemented properly as well. =

 

The GP TEE Client API is meant to provide a refer= ence design for an API that allows data passing back and forth. So, impleme= nting that API properly will be important. This is why there is this open s= ource project to implement that API so that other developers can just use it.

 

 

e) The below line is not clear to me:<= /p>

Enumeration and access to the appropriate TEEP Br= oker is up to the Rich Execution Environment and the Untrusted Applications= ..

 

[Hannes] There may be multiple TEEP Brokers on th= e system and the interaction between untrusted apps and the TEEP broker is = up to a policy implemented by the developer.

 

h) A use case explaining the use of multiple TAM,= multiple TEEP brokers on a device, and multiple TEE would be useful to the= reader of the specification.

 

[Hannes] Definitely a good idea to add text with = use cases.

Here is my quick response:

 

  • Multiple TAMs:= you could think about this as having multiple code repositories. Different= SPs may prefer to use certain TAMs for their software distribution.
  •  

    i) When a TEEP Broker receives a request from an = Untrusted Application

       to install a TA, a list of TAM URIs = may be provided for that TA, and

       the request is passed to the TEEP Ag= ent.  If the TEEP Agent decides

       that the TA needs to be installed, t= he TEEP Agent selects a single

       TAM URI that is consistent with the = list of trusted TAMs provisioned

       on the device invokes the HTTP trans= port for TEEP to connect to the

       TAM URI and begins a TEEP protocol e= xchange.

     

    Comment> I am not sure why the architecture dr= aft is discussing the protocol aspects like HTTP for TEEP ?

     

    [Hannes] I believe it does not need to mention HT= TP but it could list it as an example.

     

    j) What if the malware in REE instructs the TEEP = agent via TEEP broker to keep installing/uninstalling TA (over-whelm the TE= EP agent and TEE or installing un-necessary TA to have no memory for the re= quired TA) ?

     

    [Hannes] Having a compromised REE environment tha= t causes all sorts of apps to be installed is possible (assuming the TEE is= authorizing the installation of those apps). An implementation of the secu= re world, most likely the TEE OS, will have to make sure that the device does not install TAs and overwrite = the memory space they have been configured to use.

     

    i) What is the use case for "Personalization= data" ?

     

    [Hannes] Personalization data is meant to make ea= ch instance of the TA unique and potentially tie it to a specific user. Ima= gine a TA that implements biometric functionality: there has to be somethin= g in TA that relates this instance of the TA to a specific human, for example by storing a fingerprint alongs= ide the TA as configuration data.

     

    j) Why is Section 4.5 discussing Case 1 when it n= ot in use ?

     

    [Hannes] We just describe the possible approach a= nd illustrates how things are done today. There is, however, a lot of devel= opment going on in the area of TEEs and I suspect that we will see all sort= s of different use cases showing up in the future as the technology gets used in different environments. =

     

     

    k) The below line is not clear to me (please elab= orate):

    Consequently, a TAM generally communicates with a= n Untrusted Application about how it gets messages that originate from a TE= E inside a device.

     

    [Hannes] The key point of that paragraph is that = today TEEs do not communicate with the outside world but require the cooper= ation with something on the REE side.

     

    l) What is the use case for one TA and multiple S= P ?

     

    [Hannes] I am not sure. I let Ming, DaveW, or Dav= eT respond.

     

    m) what is the use case for keeping the TA binary= secret from the TAM ?

     

    [Hannes] it is more and more common today to prot= ect binaries from inspection because this gives attackers a lot of informat= ion. If you don’t want to use it and only sign the binaries that̵= 7;s fine too. But the option is there for you to protect the confidentiality of the binary.

     

    n) We allow a way for an Untrusted Application to= check the trustworthiness of a TA.

     

    Comment> You may want to re-phrase the above l= ine, and remove "we".

     

    [Hannes] I think we should delete this paragraph:=

    “

       We allow a way for an Untrust=
ed Application to check the
       trustworthiness of a TA. =
; A TEEP Broker has a function to allow an
       application to query the info=
rmation about a TA.

    “

     

     

    o) A notification that an incoming TEEP session i= s being requested by a TEEP Agent.

     

    Comment> What you meant by "incoming TEEP= session" ?

     

    [Hannes] Dave should respond to this one because = it relates to the HTTP transport, I believe.

     

    p) How does the TEEP broker communicate with the = TEEP agent ?

     

    [Hannes] Via an API, for example the GP TEEP Clie= nt API.

     

    q) Section 5.3 says the architecture uses PKI but= Section 9.1 discusses self-signed certificates. Please fix.

     

    [Hannes] We need to clarify the statement about t= he self-signed TA binaries.

     

    r) In Figure 4, for the purpose of "Code sig= ning" my understanding is the location of corresponding CA certs is bo= th TEE and TAM.

     

    [Hannes] I believe it would be useful to also sto= re the CA cert that is used for code signing at the TAM because then it can= verify the signed TAs.

    If we indeed believe the text in Section 9.1 is c= orrect then that code signing CA cert also needs to be made available to th= e TEEP Broker and potentially even to the untrusted app.

     

    s)I have seen several malicious apps in App store= in both Android and iOS, it is possible for an malicious App developer to = publish both malicious untrusted applications

       and malicious trusted applicati= ons.  I don't think the TEEP architecture prevents this attack and it = is the responsibility of TAM and App store to remove such apps

        (see https://android-developers.googleblog.com/2018/01/how-we-fought-bad-apps-an= d-malicious.html)

     

    [Hannes] Yes, it would be the responsibility of t= he TAM, the device manufacturer and the SP / developer to ensure that they = do not distribute malicious TAs.

     

    Ciao

    Hannes

     

    Cheers,

    -Tiru

     

    From: Dave Thaler <dthaler@microsoft.com>
    Sent: Tuesday, January 7, 2020 8:44 AM
    To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; teep@ietf.org
    Subject: RE: Working Group Last Call for draft-ietf-teep-architectur= e

     

    CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.<= /span><= /span>

     

    I opened one pull request for editorial issues (https://github.com/ietf-teep/architecture/pull/109),

    and filed seven other issues listed at https://github= ..com/ietf-teep/architecture/issues

     

    110) Service Provider discussion is confusing<= o:p>

    111) Terminology section is not consistently ordered

    112) Text about carriers is confusing

    113) Section 6.2.3 contradicts section 4.2

    114) Figure 3 is too hard to understand

    115) Reference to IANA number

    116) Incorrect/obsolete statements about TEEP Broker<= /a>

     

    I have ideas about how to address all of them, but i= f others have comments, please speak up.

     

    The possibly(?) contentious one might be that in #11= 0 I am proposing to use the term

    “App Developer” throughout, instead of u= sing “Service Provider” in some places and “App Developer= ” in others

    and then saying they’re synonymous like it doe= s now.   (I’d be ok with mentioning that in some contexts a= n App Developer

    might be known as a “Service Provider” i= f that is important to GlobalPlatform folks.)

     

    Dave=

     

    From: TEEP <teep-bounces@ietf.org> On Behalf Of Konda, Tirumaleswar Reddy
    Sent: Monday, December 23, 2019 4:17 AM
    To: teep@ietf.org
    Subject: [Teep] Working Group Last Call for draft-ietf-teep-architec= ture

     

    Hi all,

     

    This message starts a Work Group Last Call (WGLC) fo= r TEEP architecture.  The version to be reviewed is https://tools.ietf.org/html/draft-ietf-teep-architecture-05 =

     

    The WGLC will last for 4 weeks and will end on 20 Ja= nuary 2020.

     

    Please send your comments to the list before this da= te and your assessment of whether or not it is ready to proceed to publicat= ion.

     

    Regards,

    Tiru & Nancy

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM6PR08MB5285F0C0209A745F1FAABA23FA3F0AM6PR08MB5285eurp_-- From nobody Tue Jan 7 11:44:29 2020 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC44120113 for ; Tue, 7 Jan 2020 11:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 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_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=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bpqx0OFCnBBx for ; Tue, 7 Jan 2020 11:44:22 -0800 (PST) Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700095.outbound.protection.outlook.com [40.107.70.95]) (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 F13D612010E for ; Tue, 7 Jan 2020 11:44:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XeGKt3wh2GjPLUhVIy8TAWVzkmEbSMxlRnX8Au7CPB/bN4KXt4Q6syTEvHyiqKib55BKBiqQqFmnjG3Re6eZlFpClsefOA8eJ8JYmzN2m6rUGLems1KudOrT4Vw2psedwSq53qQUUuWDyopVLeScSl+v8V6+WLHvNiCEWgixoD7IT5oHAzwZ16Zr2sUn/LgGwvQZCbWjAbNTEjNJUjWacstzDLss6+06dYNF/eamY0ZrhbMWsYlj+KqJoFI3h1SrhfunW179LYMilT7CA39gV8ti/IEc6/SVfrDIwFAYUK59W+PrFUP1njy8uNhphkwM8L3X7kAjoXzXoxkbofqcbA== 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=7toTyZ7QM0w4RAjTpAl1QvRlRIARYhevjwQuC58BNHs=; b=IIyvWVTq6XNW3Kvy841GTcjYX+LnVdV5laCtvX+vUSlf7juT+QuDfVm5Ly4KKnMgq2+sAgJ5oAlxmUNHWSaAvDcDunb/efgYlUCkb8olL/BqiGPOk0jAcLgW2356drKTS8YDxLzajlpiYBEWa5gn8LpYLPooCXKILqOTBSBkfeUFMxOEZKkeAG37S6x7v8dSFP10DRFKAwfgiWokt4YKGztY+oAmQH6KnHNIJLrX/MRqesi7PreurRF8XVVFlz7ZmaKPzd7kywb5gtK0TBhMLNqBvk/6c0duEgFIEZnstxjb0DHmAhdaawo1q+U4tPN+ETiBzWJCW7jg0B51MOlapA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7toTyZ7QM0w4RAjTpAl1QvRlRIARYhevjwQuC58BNHs=; b=KJh0WlDwN5DK+he9BEiekvCSKPn/vqMyI24gJqxBuRbMaVSZQ6HOEI8CZM6W9nTvtP+hEcfU2AUKOcq5cmtOIGMGHWEBhzuycF/QEk5DnB6Lt05T+dX4cQCLDxIa0uD4jV0yf9AQ9fCPLNWjtzkWDufKKF7/4qAYfGdJPayrqPE= Received: from BL0PR2101MB1027.namprd21.prod.outlook.com (52.132.20.161) by BL0PR2101MB1026.namprd21.prod.outlook.com (52.132.20.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.3; Tue, 7 Jan 2020 19:44:19 +0000 Received: from BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::c50e:86ef:6bf3:d535]) by BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::c50e:86ef:6bf3:d535%9]) with mapi id 15.20.2644.002; Tue, 7 Jan 2020 19:44:19 +0000 From: Dave Thaler To: Hannes Tschofenig , "Konda, Tirumaleswar Reddy" , "teep@ietf.org" Thread-Topic: Working Group Last Call for draft-ietf-teep-architecture Thread-Index: AdW5iepOELmpRRFXSAWsc0EhHQP19ALfbySAAAc0BIAABIf9gAAWBUMg Date: Tue, 7 Jan 2020 19:44:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-01-07T03:14:02.9467153Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=113fc599-cef6-4df9-bb00-5e0a626ea5d7; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [2601:600:9780:16f0:cdf6:f878:752c:9d87] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: b5af03db-9033-433c-d6c5-08d793a9fc83 x-ms-traffictypediagnostic: BL0PR2101MB1026: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(136003)(366004)(39860400002)(53754006)(51914003)(40434004)(189003)(199004)(186003)(110136005)(316002)(33656002)(7696005)(71200400001)(8936002)(81166006)(8676002)(81156014)(53546011)(6506007)(66476007)(64756008)(66946007)(66556008)(76116006)(52536014)(66446008)(2906002)(5660300002)(8990500004)(66574012)(966005)(86362001)(10290500003)(55016002)(478600001)(9686003)(30864003)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB1026; H:BL0PR2101MB1027.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yvnC982Briw9HtGDURraSoNryhgALR2YgxSfjiVHC1rZ3/Sm+VvFHZGs4YEb02AvttE/ZL5W/bo/57g1sYthVm08qhRZwGAWhLR02OITAReLK5T3L/eCnz57C2K0B8ahmlyc9mkm1bhwa+YDPAxKsUpxR+WGlQrpp+NeDeZgvJiSFEPSbcYYORp95OskfXlQmWQR8MyILIg6Bw7yGVtdIaiCVnKT5pxb0BK9wK4qxk7RHdX+qrMv3y1u51OcN9KM/fFrCXFLfdG8BLznL2YpHnhMQmdmEuP+jRyEjU+kR4obBdrIA7pi+p7brOPk2bgvuHfZrfv6ZISkZp69dRn2+6VhT3dcDDJAYafCROMxXOe7U2NsG3Hkd+5kk0F8mReboFcOH2HU62twP67qIb5B1njXQeYQmAR+YqDwA4LfOJmnpWZ6mCGAqajZsifI+1mBM/m1bMwvTzBwuv03lP0r2j/SviiUC4zrlCzAiPdJcCCSG80xZunn4cxVyZcxMwRX/OJlJ5vZHty8S3ToO41WW73ecmpO9cyffZwgSjy0F12Hvfcuy3MOvKpwap2/69uOUcp7xjEA7Ri5ZTjueAQ5euBA4f4B6a6AzbcWY97L4Ik= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB1027BB4B1FDB272B61D04468A33F0BL0PR2101MB1027_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: b5af03db-9033-433c-d6c5-08d793a9fc83 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 19:44:19.0359 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +GMRqaer4uigQzWrCWV7n1jtDRcDseP8oI7v8eCfbigp9pULx5rNf/Dvql31aJkLenXrgy5r20PilmSnMWt9W7BD8iFyYqlifWSGKvfFW0k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1026 Archived-At: Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 19:44:27 -0000 --_000_BL0PR2101MB1027BB4B1FDB272B61D04468A33F0BL0PR2101MB1027_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Below From: Hannes Tschofenig Sent: Tuesday, January 7, 2020 1:28 AM To: Konda, Tirumaleswar Reddy ; Dave Th= aler ; teep@ietf.org Subject: RE: Working Group Last Call for draft-ietf-teep-architecture Hi Tiru, Thanks for the review. There is clearly room for improving the write-up. A few remarks below. From: TEEP > On Behalf = Of Konda, Tirumaleswar Reddy Sent: Tuesday, January 7, 2020 7:39 AM To: Dave Thaler >; teep= @ietf.org Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architectur= e [As an individual] Hi Dave, I have reviewed the draft and have comments and nits listed below: a) It is not clear from the Introduction how TEE is different from a Closed= OS like Google Chromebook or Windows 10S ? The benefit of Payment application running in Closed OS verses in TEE = is not evident from the description. What part of the Payment application r= uns in the REE and TEE respectively ? If biometric identification information is securely stored in TEE for = identification, how does the TEE identify the biometric identification info= rmation is not retrieved by an malicious agent in the REE. Section 3.3 (Internet of things), How does the architecture ensure the= sensitive data is retrieved by a legitimate application in the REE and not= by an malicious application ? [Hannes] The TEE adds another layer of software isolation. To protect one T= A to steal data from another TA the two TAs need to be isolated against eac= h other. Depending on the TEE technology you are using this is accomplished= via different means. It is up to the application developer to decide how they best want to separ= ate the REE and the TEE part, which in part depends a bit on what type of p= ayment protocol they are using. In some other cases (probably more realisti= c) they may be using an already existing payment system, which is provided = as a TA, and they are just using it. In general, it does not strike me as a= great idea to have random smart phone app developers writing their own pay= ment software. The document (intentionally) makes no statement about whether a "close OS" = as you put it, is or is not a TEE. The question is really about whether s= uch an OS prevents code injection attacks (e.g., due to buffer overruns or = whatever else), prevents data modification attacks, etc. b) Why should the list of trust anchors on the device be managed by the Dev= ice's network carrier ? (you may want to define the term "network carrier"). This is issue #112 that I filed. Personally I think the term "carrier" sh= ould be removed from the doc. [Hannes] The text says the following: " The list of Trust Anchors is normally modifiable by the Device's owner or Device Administrator. However the Device manufacturer and network carrier may restrict some modifications, for example, by not allowing the manufacturer or carrier's Trust Anchor to be removed or disabled. " This describes current practice in the mobile phone industry and may not ne= cessarily be applicable to other deployment scenarios. Hence, there is no r= equired behavior here. c) If the REE is compromised (for example by malware), it could terminate t= he TEEP broker in REE. How is this attack mitigated ? [Hannes] If the REE is compromised then that's typically not a good thing b= ut the REE side still cannot access anything on the secure world, if implem= ented correctly. It could, however, indeed terminate the TEEP broker and av= oid any calls to the secure world. This would be a DoS attack. It would be = possible to periodically schedule an interrupt that is processed by the sec= ure world to let the secure world double-check the state of the normal worl= d. Right. DoS attacks by the REE are, in general, not prevented (some TEEs ma= y prevent them but most won't). The TEEP architecture doesn't change this. d) What happens if the malicious agent acting as TEEP broker launches attac= ks (e.g. garbage data, replay attack, DoS of messages etc.,) on the TEEP ag= ent, and how will the TEEP agent defend itself ? [Hannes] The TEEP agent dispatches calls to the trusted applications. It is= typically a shim layer that just checks parameters of the requests and the= n relays them to the TAs. Having a rock solid implementation of the TEEP ag= ent is important and of course the TAs need to be implemented properly as w= ell. The GP TEE Client API is meant to provide a reference design for an API tha= t allows data passing back and forth. So, implementing that API properly wi= ll be important. This is why there is this open source project to implement= that API so that other developers can just use it. The TEEP Agent implements a secure protocol (the TEEP protocol) between it = and a TAM. That protocol must be secure against attacks by untrusted intermediaries, i= ncluding routers, HTTP proxies, and TEEP brokers. e) The below line is not clear to me: Enumeration and access to the appropriate TEEP Broker is up to the Rich Exe= cution Environment and the Untrusted Applications.. [Hannes] There may be multiple TEEP Brokers on the system and the interacti= on between untrusted apps and the TEEP broker is up to a policy implemented= by the developer. I agree the line is confusingly worded. h) A use case explaining the use of multiple TAM, multiple TEEP brokers on = a device, and multiple TEE would be useful to the reader of the specificati= on. Isn't that what Figure 2 already provides? Can you elaborate on what you'r= e looking for? [Hannes] Definitely a good idea to add text with use cases. Here is my quick response: - Multiple TAMs: you could think about this as having multiple code = repositories. Different SPs may prefer to use certain TAMs for their softwa= re distribution. - Multiple TEEP brokers: this can occur when you have a broker offer= ed by the OS and one bundled with the untrusted app. - Multiple TEEs: This depends on the TEE technology. In the TrustZon= e case you may have a multi-processor system and each processor comes with = TrustZone support. i) When a TEEP Broker receives a request from an Untrusted Application to install a TA, a list of TAM URIs may be provided for that TA, and the request is passed to the TEEP Agent. If the TEEP Agent decides that the TA needs to be installed, the TEEP Agent selects a single TAM URI that is consistent with the list of trusted TAMs provisioned on the device invokes the HTTP transport for TEEP to connect to the TAM URI and begins a TEEP protocol exchange. Comment> I am not sure why the architecture draft is discussing the protoco= l aspects like HTTP for TEEP ? [Hannes] I believe it does not need to mention HTTP but it could list it as= an example. Sure. On the other hand, we have a WG document, and the architecture document can= mention it as explaining how that doc fits into the architecture and relat= es to the other docs. j) What if the malware in REE instructs the TEEP agent via TEEP broker to k= eep installing/uninstalling TA (over-whelm the TEEP agent and TEE or instal= ling un-necessary TA to have no memory for the required TA) ? An REE can always conduct DoS attacks against a TEEP agent as discussed in = your question (c) above. However the word "instructs" is incorrect since the TEEP Agent is authorita= tive, your question should say "requests" instead, since the TEEP agent is = free to ignore/reject the request. (This is why section 6.2.1 has "Request= TA", as does the transport spec.) [Hannes] Having a compromised REE environment that causes all sorts of apps= to be installed is possible (assuming the TEE is authorizing the installat= ion of those apps). An implementation of the secure world, most likely the = TEE OS, will have to make sure that the device does not install TAs and ove= rwrite the memory space they have been configured to use. i) What is the use case for "Personalization data" ? There is an example in section 4.4: =D8 an example of =D8 personalization data might be a secret symmetric key used by the TA =D8 to communicate with the SP [Hannes] Personalization data is meant to make each instance of the TA uniq= ue and potentially tie it to a specific user. Imagine a TA that implements = biometric functionality: there has to be something in TA that relates this = instance of the TA to a specific human, for example by storing a fingerprin= t alongside the TA as configuration data. j) Why is Section 4.5 discussing Case 1 when it not in use ? [Hannes] We just describe the possible approach and illustrates how things = are done today. There is, however, a lot of development going on in the are= a of TEEs and I suspect that we will see all sorts of different use cases s= howing up in the future as the technology gets used in different environmen= ts. Agree with Hannes. k) The below line is not clear to me (please elaborate): Consequently, a TAM generally communicates with an Untrusted Application ab= out how it gets messages that originate from a TEE inside a device. [Hannes] The key point of that paragraph is that today TEEs do not communic= ate with the outside world but require the cooperation with something on th= e REE side. That whole paragraph is confusingly worded, and I currently plan to rewrite= it based on my marked up hard copy :) l) What is the use case for one TA and multiple SP ? [Hannes] I am not sure. I let Ming, DaveW, or DaveT respond. No idea, I'd propose deleting that section. I was confused by it as well. m) what is the use case for keeping the TA binary secret from the TAM ? [Hannes] it is more and more common today to protect binaries from inspecti= on because this gives attackers a lot of information. If you don't want to = use it and only sign the binaries that's fine too. But the option is there = for you to protect the confidentiality of the binary. I believe the use case is where the app developer considers the TA binary i= tself to be secret (e.g., intellectual property worth protecting), but want= s to allow it to be distributed through a TAM that is run by another organi= zation, one with more hosting capacity. Thus the developer puts an encryp= ted binary in that TAM, and then runs their own lighter weight TAM that jus= t hands out decryption keys which doesn't need nearly as much much capacity= /bandwidth. n) We allow a way for an Untrusted Application to check the trustworthiness= of a TA. Comment> You may want to re-phrase the above line, and remove "we". [Hannes] I think we should delete this paragraph: " We allow a way for an Untrusted Application to check the trustworthiness of a TA. A TEEP Broker has a function to allow an application to query the information about a TA. " Agreed it should be deleted. This was the second point of issue #116 that = I filed. o) A notification that an incoming TEEP session is being requested by a TEE= P Agent. Comment> What you meant by "incoming TEEP session" ? [Hannes] Dave should respond to this one because it relates to the HTTP tra= nsport, I believe. The TEEP protocol requires the agent to connect to the TAM. This is a not= ification about the initial connection. See the transport spec for more details. p) How does the TEEP broker communicate with the TEEP agent ? [Hannes] Via an API, for example the GP TEEP Client API. Right, implementation-specific detail. q) Section 5.3 says the architecture uses PKI but Section 9.1 discusses sel= f-signed certificates. Please fix. [Hannes] We need to clarify the statement about the self-signed TA binaries= . Sure. Figure 4 talks about multiple certificates. 5.3 is a general state= ment about multiple types. 9.1 is about one specific type of cert that may or may not have a PKI. So they are not in contradiction but yes clarification would be good. r) In Figure 4, for the purpose of "Code signing" my understanding is the l= ocation of corresponding CA certs is both TEE and TAM. [Hannes] I believe it would be useful to also store the CA cert that is use= d for code signing at the TAM because then it can verify the signed TAs. I don't believe there is any such requirement on a TAM. It might be "usef= ul" but is not required in my view. If we indeed believe the text in Section 9.1 is correct then that code sign= ing CA cert also needs to be made available to the TEEP Broker and potentia= lly even to the untrusted app. I don't believe the text in 9.1 is correct. s)I have seen several malicious apps in App store in both Android and iOS, = it is possible for an malicious App developer to publish both malicious unt= rusted applications and malicious trusted applications. I don't think the TEEP architecture= prevents this attack and it is the responsibility of TAM and App store to = remove such apps (see https://android-developers.googleblog.com/2018/01/how-we-fought-ba= d-apps-and-malicious.html) [Hannes] Yes, it would be the responsibility of the TAM, the device manufac= turer and the SP / developer to ensure that they do not distribute maliciou= s TAs. It's the responsibility of the TAM to not install malicious trusted apps, o= nly authorized ones. I don't think it's correct to say it's the responsibility of the TAM to "re= move" malicious trusted apps, since it shouldn't have installed it in the f= irst place. The only case where "removal" might make sense is if the TAM previously aut= horized a trusted app, and later changed its policy that such TA is no long= er authorized (e.g., because it was determined to be buggy or malicious or = whatever else). Ciao Hannes Cheers, -Tiru From: Dave Thaler > Sent: Tuesday, January 7, 2020 8:44 AM To: Konda, Tirumaleswar Reddy >; teep@ietf.org Subject: RE: Working Group Last Call for draft-ietf-teep-architecture CAUTION: External email. Do not click links or open attachments unless you = recognize the sender and know the content is safe. ________________________________ I opened one pull request for editorial issues (https://github.com/ietf-tee= p/architecture/pull/109), and filed seven other issues listed at https://github..com/ietf-teep/archit= ecture/issues 110) Service Provider discussion is confusing 111) Terminology section is not consistently ordered 112) Text about carriers is confusing 113) Section 6.2.3 contradicts section 4.2 114) Figure 3 is too hard to understand 115) Reference to IANA number 116) Incorrect/obsolete statements about TEEP Broker I have ideas about how to address all of them, but if others have comments,= please speak up. The possibly(?) contentious one might be that in #110 I am proposing to use= the term "App Developer" throughout, instead of using "Service Provider" in some pla= ces and "App Developer" in others and then saying they're synonymous like it does now. (I'd be ok with ment= ioning that in some contexts an App Developer might be known as a "Service Provider" if that is important to GlobalPlatfo= rm folks.) Dave From: TEEP > On Behalf = Of Konda, Tirumaleswar Reddy Sent: Monday, December 23, 2019 4:17 AM To: teep@ietf.org Subject: [Teep] Working Group Last Call for draft-ietf-teep-architecture Hi all, This message starts a Work Group Last Call (WGLC) for TEEP architecture. T= he version to be reviewed is https://tools.ietf.org/html/draft-ietf-teep-ar= chitecture-05 The WGLC will last for 4 weeks and will end on 20 January 2020. Please send your comments to the list before this date and your assessment = of whether or not it is ready to proceed to publication. Regards, Tiru & Nancy IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_BL0PR2101MB1027BB4B1FDB272B61D04468A33F0BL0PR2101MB1027_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Below

 

From: Hannes Tscho= fenig <Hannes.Tschofenig@arm.com>
Sent: Tuesday, January 7, 2020 1:28 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; Dave Thaler <dthaler@microsoft.com>; teep@ietf.org
Subject: RE: Working Group Last Call for draft-ietf-teep-architectur= e

 

Hi Tiru,

 

Thanks for the review. Th= ere is clearly room for improving the write-up.

 

A few remarks below.

 

From: TEEP <teep-bounces@ietf.org> On Behalf Of Konda, Tirumaleswar Reddy
Sent: Tuesday, January 7, 2020 7:39 AM
To: Dave Thaler <dthaler= @microsoft.com>; teep@ietf.org
Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-arch= itecture

 

[As an individual]

 

Hi Dave,

 

I have reviewed the dr= aft and have comments and nits listed below:

 

a) It is not clear fro= m the Introduction how TEE is different from a Closed OS like Google Chrome= book or Windows 10S ?

    &nb= sp;The benefit of Payment application running in Closed OS verses in TEE is= not evident from the description. What part of the Payment application run= s in the REE and TEE respectively ?

   &nbs= p; If biometric identification information is securely stored in TEE for id= entification, how does the TEE identify the biometric identification inform= ation is not retrieved by an malicious agent in the REE.

   &nbs= p; Section 3.3 (Internet of things), How does the architecture ensure the s= ensitive data is retrieved by a legitimate application in the REE and not b= y an malicious application ?  

 

[Hannes] The TEE adds = another layer of software isolation. To protect one TA to steal data from a= nother TA the two TAs need to be isolated against each other. Depending on = the TEE technology you are using this is accomplished via different means.

 

It is up to the applic= ation developer to decide how they best want to separate the REE and the TE= E part, which in part depends a bit on what type of payment protocol they a= re using. In some other cases (probably more realistic) they may be using an already existing payment system, whic= h is provided as a TA, and they are just using it. In general, it does not = strike me as a great idea to have random smart phone app developers writing= their own payment software.

 

The document (inten= tionally) makes no statement about whether a “close OS” as you = put it, is or is not a TEE.   The question is really about whethe= r such an OS prevents code injection attacks (e.g., due to buffer overruns or whatever else), prevents data modification attacks, etc= .

 

b) Why should the list= of trust anchors on the device be managed by the Device's network carrier = ?

   &nbs= p; (you may want to define the term "network carrier").

 

This is issue #112 = that I filed.   Personally I think the term “carrier”= should be removed from the doc.

 

[Hannes] The text says= the following:

 

“

The list of Trust A= nchors is normally modifiable

   &= nbsp;  by the Device's owner or Device Administrator.  However th= e Device

   &= nbsp;  manufacturer and network carrier may restrict some modification= s,

   &= nbsp;  for example, by not allowing the manufacturer or carrier's Trus= t

   &= nbsp;  Anchor to be removed or disabled.

“

 

This describes current= practice in the mobile phone industry and may not necessarily be applicabl= e to other deployment scenarios. Hence, there is no required behavior here.

 

 

c) If the REE is compr= omised (for example by malware), it could terminate the TEEP broker in REE.= How is this attack mitigated ?

 

[Hannes] If the REE is= compromised then that’s typically not a good thing but the REE side = still cannot access anything on the secure world, if implemented correctly.= It could, however, indeed terminate the TEEP broker and avoid any calls to the secure world. This would be a DoS attack= . It would be possible to periodically schedule an interrupt that is proces= sed by the secure world to let the secure world double-check the state of t= he normal world.

 

Right.  DoS at= tacks by the REE are, in general, not prevented (some TEEs may prevent them= but most won’t).

The TEEP architectu= re doesn’t change this.

 

d) What happens if the= malicious agent acting as TEEP broker launches attacks (e.g. garbage data,= replay attack, DoS of messages etc.,) on the TEEP agent, and how will the = TEEP agent defend itself ?

 

[Hannes] The TEEP agen= t dispatches calls to the trusted applications. It is typically a shim laye= r that just checks parameters of the requests and then relays them to the T= As. Having a rock solid implementation of the TEEP agent is important and of course the TAs need to be implemente= d properly as well.

 

The GP TEE Client API = is meant to provide a reference design for an API that allows data passing = back and forth. So, implementing that API properly will be important. This = is why there is this open source project to implement that API so that other developers can just use it.

 

The TEEP Agent impl= ements a secure protocol (the TEEP protocol) between it and a TAM.
That protocol must be secure against attacks by untrusted intermediaries, i= ncluding routers, HTTP proxies, and TEEP brokers.

 

e) The below line is n= ot clear to me:

Enumeration and access= to the appropriate TEEP Broker is up to the Rich Execution Environment and= the Untrusted Applications..

 

[Hannes] There may be = multiple TEEP Brokers on the system and the interaction between untrusted a= pps and the TEEP broker is up to a policy implemented by the developer.

 

I agree the line is= confusingly worded.

 

h) A use case explaini= ng the use of multiple TAM, multiple TEEP brokers on a device, and multiple= TEE would be useful to the reader of the specification.

 

Isn’t that wh= at Figure 2 already provides?  Can you elaborate on what you’re = looking for?

 

[Hannes] Definitely a = good idea to add text with use cases.

Here is my quick respo= nse:

 

-       = ; Multiple TAMs: you could think about this as having= multiple code repositories. Different SPs may prefer to use certain TAMs f= or their software distribution.

-       = ; Multiple TEEP brokers: this can occur when you have= a broker offered by the OS and one bundled with the untrusted app.

-       = ; Multiple TEEs: This depends on the TEE technology. = In the TrustZone case you may have a multi-processor system and each proces= sor comes with TrustZone support.

 

i) When a TEEP Broker = receives a request from an Untrusted Application

   to instal= l a TA, a list of TAM URIs may be provided for that TA, and

   the reque= st is passed to the TEEP Agent.  If the TEEP Agent decides<= /p>

   that the = TA needs to be installed, the TEEP Agent selects a single

   TAM URI t= hat is consistent with the list of trusted TAMs provisioned

   on the de= vice invokes the HTTP transport for TEEP to connect to the

   TAM URI a= nd begins a TEEP protocol exchange.

 

Comment> I am not s= ure why the architecture draft is discussing the protocol aspects like HTTP= for TEEP ?

 

[Hannes] I believe it = does not need to mention HTTP but it could list it as an example.

 

Sure.

 

On the other hand, = we have a WG document, and the architecture document can mention it as expl= aining how that doc fits into the architecture and relates to the other doc= s.

 

j) What if the malware= in REE instructs the TEEP agent via TEEP broker to keep installing/uninsta= lling TA (over-whelm the TEEP agent and TEE or installing un-necessary TA t= o have no memory for the required TA) ?

 

An REE can always c= onduct DoS attacks against a TEEP agent as discussed in your question (c) a= bove.

However the word &#= 8220;instructs” is incorrect since the TEEP Agent is authoritative, y= our question should say “requests” instead, since the TEEP agen= t is free to ignore/reject the request.  (This is why section 6.2.1 has “RequestTA”, as does the transport spec.)=

 

[Hannes] Having a comp= romised REE environment that causes all sorts of apps to be installed is po= ssible (assuming the TEE is authorizing the installation of those apps). An= implementation of the secure world, most likely the TEE OS, will have to make sure that the device does not in= stall TAs and overwrite the memory space they have been configured to use.

 

i)      &nbs= p;          What is the use case for "Personalization data= " ?

 

There is an example= in section 4.4:

=D8  an example of<= /o:p>

=D8  personalization dat= a might be a secret symmetric key used by the TA

=D8  to communicate with= the SP

 

[Hannes] Personalizati= on data is meant to make each instance of the TA unique and potentially tie= it to a specific user. Imagine a TA that implements biometric functionalit= y: there has to be something in TA that relates this instance of the TA to a specific human, for example by storin= g a fingerprint alongside the TA as configuration data.

 

j) Why is Section 4.5 = discussing Case 1 when it not in use ?

 

[Hannes] We just descr= ibe the possible approach and illustrates how things are done today. There = is, however, a lot of development going on in the area of TEEs and I suspec= t that we will see all sorts of different use cases showing up in the future as the technology gets used in differen= t environments.

 

Agree with Hannes.<= o:p>

 

k) The below line is n= ot clear to me (please elaborate):

Consequently, a TAM ge= nerally communicates with an Untrusted Application about how it gets messag= es that originate from a TEE inside a device.

 

[Hannes] The key point= of that paragraph is that today TEEs do not communicate with the outside w= orld but require the cooperation with something on the REE side.

 

That whole paragrap= h is confusingly worded, and I currently plan to rewrite it based on my mar= ked up hard copy J

 

l) What is the use cas= e for one TA and multiple SP ?

 

[Hannes] I am not sure= . I let Ming, DaveW, or DaveT respond.

 

No idea, I’d = propose deleting that section.   I was confused by it as well.

 

m) what is the use cas= e for keeping the TA binary secret from the TAM ?

 

[Hannes] it is more an= d more common today to protect binaries from inspection because this gives = attackers a lot of information. If you don’t want to use it and only = sign the binaries that’s fine too. But the option is there for you to protect the confidentiality of the binary.

 

I believe the use c= ase is where the app developer considers the TA binary itself to be secret = (e.g., intellectual property worth protecting), but wants to allow it to be= distributed through a TAM that is run by another organization, one with more hosting capacity.   Thus = the developer puts an encrypted binary in that TAM, and then runs their own= lighter weight TAM that just hands out decryption keys which doesn’t= need nearly as much much capacity/bandwidth.

 

n) We allow a way for = an Untrusted Application to check the trustworthiness of a TA.

 

Comment> You may wa= nt to re-phrase the above line, and remove "we".

 

[Hannes] I think we sh= ould delete this paragraph:

“

   We=
 allow a way for an Untrusted Application to check the

   tr=
ustworthiness of a TA.  A TEEP Broker has a function to allow an<=
/o:p>


   ap=
plication to query the information about a TA.


“


 


Agreed it should be=
 deleted.  This was the second point of issue #116 that I filed.<=
/o:p>


 


o) A notification that=
 an incoming TEEP session is being requested by a TEEP Agent.

 


Comment> What you m=
eant by "incoming TEEP session" ?


 


[Hannes] Dave should r=
espond to this one because it relates to the HTTP transport, I believe.



 


The TEEP protocol r=
equires the agent to connect to the TAM.   This is a notification=
 about the initial connection.


See the transport s=
pec for more details.


 


p) How does the TEEP b=
roker communicate with the TEEP agent ?


 


[Hannes] Via an API, f=
or example the GP TEEP Client API.



 


Right, implementati=
on-specific detail.


 


q) Section 5.3 says th=
e architecture uses PKI but Section 9.1 discusses self-signed certificates.=
 Please fix.


 


[Hannes] We need to cl=
arify the statement about the self-signed TA binaries.



 


Sure.  Figure =
4 talks about multiple certificates.   5.3 is a general statement=
 about multiple types.


9.1 is about one sp=
ecific type of cert that may or may not have a PKI.


So they are not in =
contradiction but yes clarification would be good.


 


r) In Figure 4, for th=
e purpose of "Code signing" my understanding is the location of c=
orresponding CA certs is both TEE and TAM.


 


[Hannes] I believe it =
would be useful to also store the CA cert that is used for code signing at =
the TAM because then it can verify the signed TAs.



 


I don’t belie=
ve there is any such requirement on a TAM.   It might be “u=
seful” but is not required in my view.


 


If we indeed believe t=
he text in Section 9.1 is correct then that code signing CA cert also needs=
 to be made available to the TEEP Broker and potentially even to the untrus=
ted app.



 


I don’t belie=
ve the text in 9.1 is correct.


 


s)I have seen several =
malicious apps in App store in both Android and iOS, it is possible for an =
malicious App developer to publish both malicious untrusted applications



   and =
malicious trusted applications.  I don't think the TEEP architecture p=
revents this attack and it is the responsibility of TAM and App store to re=
move such apps



   &nbs=
p;(see 
https://android-developers.googleblog.com/2018/01/how-we-fought-bad-apps-an=
d-malicious.html)



 


[Hannes] Yes, it would=
 be the responsibility of the TAM, the device manufacturer and the SP / dev=
eloper to ensure that they do not distribute malicious TAs.


 


It’s the resp=
onsibility of the TAM to not install malicious trusted apps, only authorize=
d ones.


I don’t think=
 it’s correct to say it’s the responsibility of the TAM to R=
20;remove” malicious trusted apps, since it shouldn’t have inst=
alled it in the first place.


The only case where=
 “removal” might make sense is if the TAM previously authorized=
 a trusted app, and later changed its policy that such TA is no longer auth=
orized (e.g., because it was determined to be buggy
 or malicious or whatever else).




 


Ciao


Hannes


 


Cheers,


-Tiru


 








From: Dave Thaler <dthaler@microsoft.com>


Sent: Tuesday, January 7, 2020 8:44 AM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
teep@ietf.org

Subject: RE: Working Group Last Call for draft-ietf-teep-architectur=
e






 










CAUTION: External email. Do not click links or open
 attachments unless you recognize the sender and know the content is safe.<=
/span><=
/span>








 










I opened one pull request for editorial issues (https://github.com/ietf-teep/architecture/pull/109),



and filed seven other issues listed at 
https://github..com/ietf-tee=
p/architecture/issues



 


110) 
Service Provider discussion is confusing<=
o:p>


111) 
Terminology section is not consistently ordered


112) 
Text about carriers is confusing


113) 
Section 6.2.3 contradicts section 4.2


114) 
Figure 3 is too hard to understand


115) 
Reference to IANA number


116) 
Incorrect/obsolete statements about TEEP Broker<=
/a>


 


I have ideas about how to address all of them, but i=
f others have comments, please speak up.


 


The possibly(?) contentious one might be that in #11=
0 I am proposing to use the term


“App Developer” throughout, instead of u=
sing “Service Provider” in some places and “App Developer=
” in others


and then saying they’re synonymous like it doe=
s now.   (I’d be ok with mentioning that in some contexts a=
n App Developer


might be known as a “Service Provider” i=
f that is important to GlobalPlatform folks.)


 


Dave=



 






From: TEEP <teep-bounces@ietf.org>
On Behalf Of Konda, Tirumaleswar Reddy

Sent: Monday, December 23, 2019 4:17 AM

To: teep@ietf.org

Subject: [Teep] Working Group Last Call for draft-ietf-teep-architec=
ture






 


Hi all,


 


This message starts a Work Group Last Call (WGLC) fo=
r TEEP architecture.  The version to be reviewed is

https://tools.ietf.org/html/draft-ietf-teep-architecture-05 =



 


The WGLC will last for 4 weeks and will end on 20 Ja=
nuary 2020.


 


Please send your comments to the list before this da=
te and your assessment of whether or not it is ready to proceed to publicat=
ion.



 


Regards,


Tiru & Nancy




IMPORTANT NOTICE: The contents of this email and=
 any attachments are confidential and may also be privileged. If you are no=
t the intended recipient, please notify the sender
 immediately and do not disclose the contents to any other person, use it f=
or any purpose, or store or copy the information in any medium. Thank you.
--_000_BL0PR2101MB1027BB4B1FDB272B61D04468A33F0BL0PR2101MB1027_-- From nobody Wed Jan 8 15:39:24 2020 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A92120124; Wed, 8 Jan 2020 15:39:23 -0800 (PST) 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=UA7pSyZv; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cjkoHq5q Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPrfH7OyX5uS; Wed, 8 Jan 2020 15:39:21 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AEAA1200A3; Wed, 8 Jan 2020 15:39:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=990; q=dns/txt; s=iport; t=1578526761; x=1579736361; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=AumlBkyZwm2yAMEclMG82UJaRWyKcRQoGJVz0cLI0Q0=; b=UA7pSyZvaLygRnfCpewH0mThdM/kuLkJBTSyQQh+BqgZf9mouvoQqdJj /cMSOsESmLJiN1heH+gmoaHs83sLB7r0yzkZanOTLLmX0pq35/WDuwNbG iOkN81Yw+86K3sH5B+6zHy0XKchpORMxIHxcslknIvEPS/LAzYXkMydle 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AKAkqdRZJHsL5jVmhFeoJBQ//LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavsZCU/A8VEW3du/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXCABFZxZe/5ldJa1mgkKBVFAFbFg?= =?us-ascii?q?gBAsqhAmDRgOKfZpsgS6BJANUCQEBAQwBASMKAgEBhEAZgVMkNgcOAgMNAQE?= =?us-ascii?q?EAQEBAgEFBG2FNwELhWEWEREMAQE3AREBGggCJgIEMBUCEAQOJ4MAAYJGAy4?= =?us-ascii?q?BDqBUAoE4iGF1gTKCfgEBBYE1AYEUgkoYggwDBoEOKIwZGoIAgREnIIpjMoI?= =?us-ascii?q?skEaeZQqCNoc2jmwbgkeHfpAdjlWBSYcOkhECBAIEBQIOAQEFgVkFLYFYcBV?= =?us-ascii?q?lAYJBUBgNkQWKU3SBKI9TAQE?= X-IronPort-AV: E=Sophos;i="5.69,411,1571702400"; d="scan'208";a="400031506" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jan 2020 23:39:20 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 008NdKY2010027 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Jan 2020 23:39:20 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 Jan 2020 17:39:20 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 Jan 2020 17:39:19 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 8 Jan 2020 18:39:19 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PgBATK/3PCJjIZTsxp9aStUnPwyLdIucMCtV1p7gtWDGyUA1WKpSAJtGW3hQ+Pqj+t/ERxwLcYANrCuXQ/i7zQD3VBwyieVxPVN4uMqvVpz+kcLfqOxZ0N4crrW70h1UW2Aef6z5LZuRiTBemcr93nF/SYoJsSteJ+NvWSZDUa9KxIjN62j5BU3dKDsnjgC9dE+fnn7OCZhnYj2q3CQADd7dSCXD1Cz2OT+gCzJhW3oMZMvIoyIikEI7RyRtElXm6N55HF6kALMb/1PA0eUcQ+XHThY97tOQGAjf9TKwf8ts+quxeIR9a/E/iuRCs/e7cCkyJOqb3sK28ARFAI8w0A== 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=AumlBkyZwm2yAMEclMG82UJaRWyKcRQoGJVz0cLI0Q0=; b=UzCatQ10+v3GS26U5pg3wZPcR/5BlWzlqV1MSNstQxIioTOGXtk9xfiaN+cmvModZlSPcIg+PvsXNV6ZPpc8t6CkzzXa4WTKlsBM+pgbzN1sK5+Uxt9zD0eonRQ/E0VAGn/f5uXOP6l7f02A9ouBlPkVnqVyz2xxpHcXC+w1MN4gExPX70pZtD6oSTb2FM4RzSQhSlxYMWlinoiJtN6Q+GpJbw2YBMmvqn6bO5ndGJozUwpYyBlXX2BPSIXyKIqeXnCZE7t81tkDVH6QY/9pdjqG/ATtgcvWWJo5NdOvkPqSR7MuBebn358asVJVnMO1DG/vGilup3KbSJLK2MlpLg== 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=AumlBkyZwm2yAMEclMG82UJaRWyKcRQoGJVz0cLI0Q0=; b=cjkoHq5qKhpOIe0NbJ+52yvcGBZJ5CzCiiolVFhP8N+PEHl+/DQ3bIEwqiSUgixut1bha8bTapa0POLstRk459tM51krRwLQVLDlUtYHtGQdk0FDmSvIiYOoFYPMRL5HJRClumSI14w6voPhIZpOPdjBwdo+F/rLosY0mjG/csM= Received: from MWHPR1101MB2176.namprd11.prod.outlook.com (10.174.255.149) by MWHPR1101MB2286.namprd11.prod.outlook.com (10.174.101.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.10; Wed, 8 Jan 2020 23:39:18 +0000 Received: from MWHPR1101MB2176.namprd11.prod.outlook.com ([fe80::4182:71b5:d005:b6db]) by MWHPR1101MB2176.namprd11.prod.outlook.com ([fe80::4182:71b5:d005:b6db%3]) with mapi id 15.20.2602.016; Wed, 8 Jan 2020 23:39:18 +0000 From: "Nancy Cam-Winget (ncamwing)" To: "rats@ietf.org" CC: "teep@ietf.org" Thread-Topic: RATS virtual interim doodle poll closing this Friday 5pmPST Thread-Index: AQHVxnzY5VF06l54tUSLQ/zMWmiFGA== Date: Wed, 8 Jan 2020 23:39:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.11.191208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ncamwing@cisco.com; x-originating-ip: [2001:420:283:1005:d01b:7d43:d26a:53a7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c50932fa-b986-480b-87ce-08d79493faeb x-ms-traffictypediagnostic: MWHPR1101MB2286: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(366004)(396003)(136003)(199004)(189003)(86362001)(186003)(71200400001)(6506007)(966005)(6486002)(6512007)(316002)(36756003)(2906002)(478600001)(6916009)(81166006)(81156014)(76116006)(91956017)(8936002)(450100002)(33656002)(66946007)(8676002)(4326008)(4744005)(5660300002)(66476007)(66556008)(2616005)(64756008)(66446008)(223384002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR1101MB2286; H:MWHPR1101MB2176.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: BCL:0; x-microsoft-antispam-message-info: NjqtMKnTljO1QgwAA5OxyynBVeumyHxnpJy+3udBP8WVF8q0G6yZzgXhmYzL931sWhGZpdf5OW2YDqcJObNOcGUECV2DTCj/UN/sH4385LEsOpmMizcQslD52fS34HnVCti/daUplY3SgxnTRSBvpF1RYLPPIRYzd2S5lYS52LN2RwjTkDqaWyaeIfeWgqQHjVPPnsHdFz0PIbI6MQK9P+VIXurrf29YxFSa+PJAn6uPmWibCvSKyornItb94tEbC9ZjqSl+q/CPFZzLI/ahMGARS5EWvQzxfv7UhBU8jzAYKcRoXBfzpyqF8TE2aHEF4oJdlJMyKLrvsBQDbvJQjMnv0hh1Mezbe7iDQqXHIH8PJ7sHKn/QDU+BZN6YujKfQIfkEl/lPK9xYsp9Zqy9cCyON+szhoPSnuPRjaxnOqHjLWCp41bB2JZehBe6chzq88lB/+lztTYMVID31W7SsQFRVB/aWs9FlBj+VPbJaiC4tFyVIencxGGIxo1+lr/fRcKctSTI+BqMBEcHnlN2cSbbLkzC2y7QCWye5S7gdvsiy0Igi+SrGp2SEd7o4AF6 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <0A9A86B0E1B47F44B41D367381743CF5@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c50932fa-b986-480b-87ce-08d79493faeb X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 23:39:18.6307 (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: Kf0KgzG4H4umjMcQEEYzRt/dnwzVg9VA60m6kpeD1p3IQI6P3O+T+VhGlVWRtBzSb3zqG0X2meVkyTS8x/FFgg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2286 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: [Teep] RATS virtual interim doodle poll closing this Friday 5pmPST X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 23:39:23 -0000 VGhpcyBpcyBhIGZpbmFsIHJlbWluZGVyIHRvIGlucHV0IHlvdXIgcHJlZmVycmVkIHRpbWVzIGZv ciB0aGUgUkFUcyBWaXJ0dWFsIEludGVyaW1zOiANCiAgaHR0cHM6Ly9kb29kbGUuY29tL3BvbGwv cDRwbW5ocm1xdXBjN3N4bg0KDQpVbmxlc3Mgd2UgaGF2ZSBhIHNpZ25pZmljYW50IG51bWJlciBv ZiBhZGRpdGlvbmFsIHJlc3BvbnNlcywgaXQgY3VycmVudGx5IGxvb2tzIGxpa2UgdGhlIGRhdGVz IGZvciB0aGUgVmlydHVhbCBJbnRlcmltcyB3aWxsIGJlIG9uDQpGZWJydWFyeSA1IDctOGFtIFBT VCBhbmQgTWFyIDIgNy04YW0gUFNULiAgIEknbGwgY2xvc2UgdGhlIGRvb2RsZSBwb2xsIHRoaXMg RnJpZGF5LCBKYW4gMTB0aCBhbmQgcHJvdmlkZSBpbmZvIHRoZW4uDQoNCkZvciBub3csIHBsZWFz ZSBwcm92aWRlIGFnZW5kYSBzdWdnZXN0aW9ucy90b3BpY3MgZm9yIGVhY2guICBUaGVyZSBpcyBh bHJlYWR5IGEgcmVxdWVzdCB0byB0YWtlIHVwIHRoZSBmdWxsIGhvdXIgZm9yIEVBVCB3aGljaCBj YW4gb2NjdXIgb24gdGhlIGZpcnN0IGludGVyaW0gKHVubGVzcyB0aGVyZSBhcmUgb2JqZWN0aW9u cykuICBCdXQsIGV4cGVjdCB0byBoYXZlIHNsb3RzIGZvciB0aGUgQXJjaGl0ZWN0dXJlIHVwZGF0 ZSBhbmQgcGVyaGFwcyB0aGUgWWFuZyBNb2R1bGUgZWl0aGVyIG9uIHRoZSBmaXJzdCBvciBzZWNv bmQgaW50ZXJpbS4NCg0KVGhhbmtzLCBOYW5jeQ0KDQogDQoNCg== From nobody Wed Jan 8 15:59:47 2020 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D021200A3 for ; Wed, 8 Jan 2020 15:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.519 X-Spam-Level: X-Spam-Status: No, score=-14.519 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=BOyrZetv; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QRabTxlS Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bb3hRQtS-14P for ; Wed, 8 Jan 2020 15:59:43 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F67120142 for ; Wed, 8 Jan 2020 15:59:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3953; q=dns/txt; s=iport; t=1578527983; x=1579737583; h=from:to:subject:date:message-id:mime-version; bh=pg7+W41X368b4+ECrohpkhUF0QIZ/nHm8tvBNHSPZcs=; b=BOyrZetvEjocqS7cO5lR7l0WGkC5rU+St6bjVHiCL7D2u79HE36twHOP 6Q6BOZXHv2KLHAqRsNAOMDJgJGgUVJTymeIfV5XpYjgvq0lAZ6cYhUG6q HTzDCcLm/yEn6jqVXYGK6KmYiaD4mfkqmEN3VATsFrVlMc2wJ/VSx5L9F U=; IronPort-PHdr: =?us-ascii?q?9a23=3AHkRxPRyx0GGE6yXXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuDAkT+M//sYAQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DHDgCpaxZe/5ldJa1mgkKBJS9QBWx?= =?us-ascii?q?YIAQLKoQJg0YDinxOgWyTUIRigS6BJANUCQEBAQwBASMKAgEBhEAZgVMkNAk?= =?us-ascii?q?OAgMNAQEEAQEBAgEFBG2FNwELhXcRHQEBOBEBDD4CBDAnBDWDAAGBeU0DLgE?= =?us-ascii?q?OoE4CgTiIYXWBMoJ+AQEFgTUBgRSCPRiCDAMGgTaMGRqCAIE4DBSCTIFCAYN?= =?us-ascii?q?xgmMygiyQRoVXmQ4KgjYEhzKObBuaYo5ViFeSEQIEAgQFAg4BAQWBUjmBWHA?= =?us-ascii?q?VZQGCQVAYDY0qg1uKU3SBKI8yAQE?= X-IronPort-AV: E=Sophos;i="5.69,411,1571702400"; d="scan'208,217";a="463875384" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Jan 2020 23:59:42 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 008Nxgrh024808 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 8 Jan 2020 23:59:42 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 Jan 2020 17:59:41 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 8 Jan 2020 17:59:41 -0600 Received: from NAM12-DM6-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; Wed, 8 Jan 2020 17:59:41 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TDZ9tzbyLZDF8jNZhJSvTs8vEFVy4wK9vMqe/nspxx23CCx9uSYrnvwArG1B95bNHgHZtT7fOXD+Bt9W3ozpdc0eMQXT4NEayeJRqah5lEFANez/iGLhaoe3Q+HC4EV/q6NHpZ2KDwpx4629PvflK0TNJt68fNH7eLWcbiyGxe9mhUrfSkpIxNcDhD8/bx6FkyNBy37NanH5bxkQ/lR5eW2Uhv88DYiiiNxMeOYlKmLjTWERf9gK6xqzTVKIhhpSDhCSxPfJG9gvXLXk43rsxuu0RW+RA2Hs6uzn+6OjJQ7z6oO0izGaed8uDJBKCF9zf6pXFKZNNn2ELk+NFxnutA== 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=pg7+W41X368b4+ECrohpkhUF0QIZ/nHm8tvBNHSPZcs=; b=g71lwhQDzw2jbsPnlLnPoNhKnptMVCeIPPXgUJ1+ZfEjwvE2BDhbDFahrWjVypnqi4L+xdGVGXfCRBFFff4WeUQFr0IE+lkVD2J+jdSjRRAzQfzjtl3MPEcnpUmLt/kPoQo3DEOVaaTbsaRrx3F2AUKyRFkp97YMgsmucO87SHJz697mVAyExVXeLntGT1N3r9ZlL3cfb+51s8x33UKws1Eemm8dI/6o74VS9NINKE2/Eb8H1H/IjjBfxGpRpNWonii8wr2r033wvcv8JwfXd3yqmB8OoZxdB8K/smaZ0LkbAIwvP3c4Y87mcwuxl8iuB/1ewnPjr7wJnREK5tMDgw== 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=pg7+W41X368b4+ECrohpkhUF0QIZ/nHm8tvBNHSPZcs=; b=QRabTxlSmJ5tsEBkpiqW6hG25LTThIfMtA53toxLfcDZK65PaJj2Ie5ZQKDSZyNEPl5wqHOaAPxSXkY6RX3IycwE4GYlM8zzEiCCzZuk74pJGKo3mzR0A8lWmxsAIBvKJRfbgmKZ6e4QIfKWXkbC/S7lyqU4Xf4bXzcWuTVjiZ0= Received: from MWHPR1101MB2176.namprd11.prod.outlook.com (10.174.255.149) by MWHPR1101MB2302.namprd11.prod.outlook.com (10.174.101.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Wed, 8 Jan 2020 23:59:40 +0000 Received: from MWHPR1101MB2176.namprd11.prod.outlook.com ([fe80::4182:71b5:d005:b6db]) by MWHPR1101MB2176.namprd11.prod.outlook.com ([fe80::4182:71b5:d005:b6db%3]) with mapi id 15.20.2602.016; Wed, 8 Jan 2020 23:59:40 +0000 From: "Nancy Cam-Winget (ncamwing)" To: "teep@ietf.org" Thread-Topic: Reminder to Virtual Interim doodle Thread-Index: AQHVxn+wbU5KrpJGpEeqCJBKWTc9SQ== Date: Wed, 8 Jan 2020 23:59:40 +0000 Message-ID: <6BC4ED2A-58DB-4510-9EDC-80024D346A4D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.11.191208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ncamwing@cisco.com; x-originating-ip: [2001:420:283:1005:d01b:7d43:d26a:53a7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: aece0604-e5dc-4ee0-c56a-08d79496d369 x-ms-traffictypediagnostic: MWHPR1101MB2302: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 02760F0D1C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(136003)(346002)(376002)(189003)(199004)(76116006)(91956017)(33656002)(86362001)(2906002)(316002)(66946007)(6512007)(2616005)(186003)(66446008)(66556008)(66476007)(64756008)(8936002)(5660300002)(81166006)(8676002)(558084003)(6916009)(6486002)(478600001)(36756003)(6506007)(81156014)(71200400001)(966005); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR1101MB2302; H:MWHPR1101MB2176.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: BCL:0; x-microsoft-antispam-message-info: 8Z7h2xtLQijMTQH17pyNa6IgEMgz7K+sdDA6gVDXW5gnjwro4c7OTaMEUAXJ89CZYgWrc6J4k77XONvargwOovBK4d8f7QY5L7/fOlRG9SmHzItJOLwaV8fZ3rtHXTFz7hlQpIi7mrPUPe8BspQ+lF17VuUC8ikoxiTVxpR9k1JO3D2ux6JgdN3rw6IDsKDeXTNHK7TTk/Hpop7raLLAxKLG405cKfKecUxhZw5cYfY8WJx78k0GSx070pFFE7Infb3eOfs6mJD4qrm1J7J0KUzke2jLlaQpOLC1iejDE3TDMJj9W2Kkew0DqHgiR2m4ybn2Ywq20wgaaZEl+/2qiN/y1qynHGr5Vif2GrEZCBoRB1C1fwdf3yQWB5CDLpMfQ65HdK/CyTXYsS+qHbIB08Kc3BeX7lCFNKu67bRBptGelf1whbuom5sW7joj/S1K8o/SQxPIWPbTZZ/l2BoLRdjCdGBHILMrzn1zva/i/Jcu+v/paj6e1R/G/g1aRpD4qFlu1g+TqSIi9i6jG4Ulbw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_6BC4ED2A58DB45109EDC80024D346A4Dciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: aece0604-e5dc-4ee0-c56a-08d79496d369 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2020 23:59:40.7235 (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: KOUGjwGKUoM3FN8CLu0sKw/57lPa7PqQrUooYpvgNy41KmKqrhWslRcDjh4FgcmJ/KdjGvhfUrJEn/jiASYVrg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2302 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: [Teep] Reminder to Virtual Interim doodle X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jan 2020 23:59:45 -0000 --_000_6BC4ED2A58DB45109EDC80024D346A4Dciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBhIHJlbWluZGVyIHRvIGZpbmQgYSB0aW1lIGZvciBvdXIgdmlydHVhbCBpbnRlcmlt IGluIHRoZSBkb29kbGUgcG9sbDoNCiBodHRwczovL2Rvb2RsZS5jb20vcG9sbC84aHRwZmVpdWlm cWhleGlxDQoNCkkgd291bGQgbGlrZSB0byBjbG9zZSB0aGUgcG9sbCBieSBuZXh0IFdlZC4gSmFu IDE1IEVPRCB0byBnaXZlIHVzIGVub3VnaCB0aW1lIHRvIHNlbmQgdGhlIGFubm91bmNlbWVudC4N Cg0KQWxzbyBwcm92aWRlIGFnZW5kYSBpdGVtcyBhcyB3ZWxsLg0KDQpUaGFua3MsIE5hbmN5DQo= --_000_6BC4ED2A58DB45109EDC80024D346A4Dciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <1F7D8D01AC7CBA44A9D230AFAEB5BA5A@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5UaGlzIGlzIGEgcmVtaW5kZXIgdG8gZmluZCBhIHRpbWUgZm9yIG91ciB2aXJ0 dWFsIGludGVyaW0gaW4gdGhlIGRvb2RsZSBwb2xsOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJodHRwczovL2Rvb2RsZS5jb20vcG9sbC84aHRwZmVpdWlmcWhleGlx Ij5odHRwczovL2Rvb2RsZS5jb20vcG9sbC84aHRwZmVpdWlmcWhleGlxPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIHdvdWxkIGxpa2UgdG8gY2xvc2UgdGhlIHBvbGwg YnkgbmV4dCBXZWQuIEphbiAxNSBFT0QgdG8gZ2l2ZSB1cyBlbm91Z2ggdGltZSB0byBzZW5kIHRo ZSBhbm5vdW5jZW1lbnQuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPkFsc28gcHJvdmlkZSBhZ2VuZGEgaXRlbXMgYXMgd2VsbC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rcywgTmFuY3k8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6BC4ED2A58DB45109EDC80024D346A4Dciscocom_-- From nobody Wed Jan 8 23:53:14 2020 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B043F120074 for ; Wed, 8 Jan 2020 23:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4z2Usz4CP_Jr for ; Wed, 8 Jan 2020 23:53:08 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [63.128.21.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2917E12002E for ; Wed, 8 Jan 2020 23:53:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1578556386; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=scqIPO8u7dREOqcDRVYQcuBBecbj2IWeBdeQjgttFQQ=; b=kji9vWtycSvVMvaHX1zTH8SWHrR0+wSlVPXAOlvF9wuXmfc3pZTP6CWGn/r0McNz0QOCQr bSv99Rw9k2geZu5FaKTIb/IiKZU1vR94U3PqJWbhxR7KGGc56uxHd6OloQOplAIv0FDkCR E1DFiQRnRn0mpQOFD43Q2ae8GVBqCAw= Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2051.outbound.protection.outlook.com [104.47.36.51]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-94-c_tQan-7OgiKJhU3QyBHWg-1; Thu, 09 Jan 2020 02:53:01 -0500 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1240.namprd16.prod.outlook.com (10.172.115.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.10; Thu, 9 Jan 2020 07:52:58 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::a50e:f380:4d5e:71ea]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::a50e:f380:4d5e:71ea%6]) with mapi id 15.20.2602.018; Thu, 9 Jan 2020 07:52:58 +0000 From: "Konda, Tirumaleswar Reddy" To: Dave Thaler , Hannes Tschofenig , "teep@ietf.org" Thread-Topic: Working Group Last Call for draft-ietf-teep-architecture Thread-Index: AdW5iepOELmpRRFXSAWsc0EhHQP19ALfbySAAAc0BIAABIf9gAAWBUMgACJiNvA= Date: Thu, 9 Jan 2020 07:52:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-01-07T03:14:02.9467153Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=113fc599-cef6-4df9-bb00-5e0a626ea5d7; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b323acad-8644-4f62-3c2c-08d794d8f199 x-ms-traffictypediagnostic: CY4PR1601MB1240: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02778BF158 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(366004)(396003)(346002)(39860400002)(53754006)(40434004)(51914003)(199004)(189003)(32952001)(53546011)(478600001)(6506007)(26005)(5660300002)(7696005)(33656002)(81156014)(71200400001)(66574012)(45080400002)(2906002)(8936002)(186003)(52536014)(86362001)(55016002)(966005)(9686003)(8676002)(64756008)(76116006)(66446008)(81166006)(316002)(66946007)(30864003)(110136005)(66556008)(66476007)(85282002)(559001)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1240; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gKsePeRi1oe9bpCxM3t+v1/06xzqer7nQSUBNql9P26CvfCOUUG20UqC9SVRdZlA8Ww6yy4mivf/2L7GKDwoLcjR7lWXlxseJUnkw23iisANP+jLfQf3Fqq5aego3fpM2EydpvNvnE3EYJBr3vFOQlTVlHVbjCn3vztjKwV0F/mtjAEw+SbeuVhaYAp06k6YSR34kApQRwT4taXP/RdwfaEcyi/DkhwnVCgrWi9+GuAofCXP38iBguv81FPRQTXRdATC4oG3QjHlbVyHKr1jODYakOprl9o7/gC2FyFYNLBVaQlFPpAdr3puRX4AymweYNwYUlhvgGwP6lKVNa9Futi03XlbQkyUiQIigHzP0SiBffPP/2HgeZ0p6HtRFFKf+Th09Udw866hGvAMVvzHzRLNBESkcSzVxPDP5lp0A0ihy3TeEoZFjRzQMesYSAmbSZKWKw0hlx1o6DP6tk0QnMlhNkIDBB9Jvh4aaUIJfDVgA8kqeUGe68S26vcRSO4ZVR03MqFLgz4DJLb64VC5OXxQFz9vZhEn/W/ET1ptJ0Vvgi6Qd6KfUfz8bzsIl0OPHJ677G71fcngIWdrAlUaWDJjxRj8eUVGo0cc5POfZ/NbEoTck8bYeflMpKAf1stFzKlIJYPlrYSaIYilTnPY1XnnreaTBlf3UNuDQZU2dQokt6BHTkm9ooreCS6AxlAV x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: b323acad-8644-4f62-3c2c-08d794d8f199 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2020 07:52:58.1933 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qtJtIFPoNb8kugJGsiWdhmOfe3SHBOlG9QhkjcFfot7PBiOiGWQ/K2x5T6NUxTDRUnl8nsO8uqaH21H0VrgGTLHnpj6MyYpJnmnTrLMye72S2p1LsH+MqCaq90hKmyE6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1240 X-MC-Unique: c_tQan-7OgiKJhU3QyBHWg-1 X-Mimecast-Spam-Score: 0 Content-Type: multipart/alternative; boundary="_000_CY4PR1601MB125473BCC69227A45D62FAA7EA390CY4PR1601MB1254_" Archived-At: Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 07:53:13 -0000 --_000_CY4PR1601MB125473BCC69227A45D62FAA7EA390CY4PR1601MB1254_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Hannes and Dave, Thanks for the responses. Please see inline [TR] From: Dave Thaler Sent: Wednesday, January 8, 2020 1:14 AM To: Hannes Tschofenig ; Konda, Tirumaleswar Redd= y ; teep@ietf.org Subject: RE: Working Group Last Call for draft-ietf-teep-architecture CAUTION: External email. Do not click links or open attachments unless you = recognize the sender and know the content is safe. ________________________________ Below From: Hannes Tschofenig > Sent: Tuesday, January 7, 2020 1:28 AM To: Konda, Tirumaleswar Reddy >; Dave Thaler >; teep@ietf.org Subject: RE: Working Group Last Call for draft-ietf-teep-architecture Hi Tiru, Thanks for the review. There is clearly room for improving the write-up. A few remarks below. From: TEEP > On Behalf = Of Konda, Tirumaleswar Reddy Sent: Tuesday, January 7, 2020 7:39 AM To: Dave Thaler >; teep= @ietf.org Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architectur= e [As an individual] Hi Dave, I have reviewed the draft and have comments and nits listed below: a) It is not clear from the Introduction how TEE is different from a Closed= OS like Google Chromebook or Windows 10S ? The benefit of Payment application running in Closed OS verses in TEE = is not evident from the description. What part of the Payment application r= uns in the REE and TEE respectively ? If biometric identification information is securely stored in TEE for = identification, how does the TEE identify the biometric identification info= rmation is not retrieved by an malicious agent in the REE. Section 3.3 (Internet of things), How does the architecture ensure the= sensitive data is retrieved by a legitimate application in the REE and not= by an malicious application ? [Hannes] The TEE adds another layer of software isolation. To protect one T= A to steal data from another TA the two TAs need to be isolated against eac= h other. Depending on the TEE technology you are using this is accomplished= via different means. It is up to the application developer to decide how they best want to separ= ate the REE and the TEE part, which in part depends a bit on what type of p= ayment protocol they are using. In some other cases (probably more realisti= c) they may be using an already existing payment system, which is provided = as a TA, and they are just using it. In general, it does not strike me as a= great idea to have random smart phone app developers writing their own pay= ment software. [TR] Got it, Thanks. The document (intentionally) makes no statement about whether a "close OS" = as you put it, is or is not a TEE. The question is really about whether s= uch an OS prevents code injection attacks (e.g., due to buffer overruns or = whatever else), prevents data modification attacks, etc. [TR] Closed OS prevent the above attacks, a malicious app cannot read/modif= y the data of the other apps (e.g., ransomware attack is not possible, see = https://support.google.com/chromebook/answer/3438631?hl=3Den). b) Why should the list of trust anchors on the device be managed by the Dev= ice's network carrier ? (you may want to define the term "network carrier"). This is issue #112 that I filed. Personally I think the term "carrier" sh= ould be removed from the doc. [TR] Works for me. [Hannes] The text says the following: " The list of Trust Anchors is normally modifiable by the Device's owner or Device Administrator. However the Device manufacturer and network carrier may restrict some modifications, for example, by not allowing the manufacturer or carrier's Trust Anchor to be removed or disabled. " This describes current practice in the mobile phone industry and may not ne= cessarily be applicable to other deployment scenarios. Hence, there is no r= equired behavior here. c) If the REE is compromised (for example by malware), it could terminate t= he TEEP broker in REE. How is this attack mitigated ? [Hannes] If the REE is compromised then that's typically not a good thing b= ut the REE side still cannot access anything on the secure world, if implem= ented correctly. It could, however, indeed terminate the TEEP broker and av= oid any calls to the secure world. This would be a DoS attack. It would be = possible to periodically schedule an interrupt that is processed by the sec= ure world to let the secure world double-check the state of the normal worl= d. Right. DoS attacks by the REE are, in general, not prevented (some TEEs ma= y prevent them but most won't). The TEEP architecture doesn't change this. [TR] You may want to explain the above threat vector in the document. d) What happens if the malicious agent acting as TEEP broker launches attac= ks (e.g. garbage data, replay attack, DoS of messages etc.,) on the TEEP ag= ent, and how will the TEEP agent defend itself ? [Hannes] The TEEP agent dispatches calls to the trusted applications. It is= typically a shim layer that just checks parameters of the requests and the= n relays them to the TAs. Having a rock solid implementation of the TEEP ag= ent is important and of course the TAs need to be implemented properly as w= ell. The GP TEE Client API is meant to provide a reference design for an API tha= t allows data passing back and forth. So, implementing that API properly wi= ll be important. This is why there is this open source project to implement= that API so that other developers can just use it. The TEEP Agent implements a secure protocol (the TEEP protocol) between it = and a TAM. That protocol must be secure against attacks by untrusted intermediaries, i= ncluding routers, HTTP proxies, and TEEP brokers. [TR] Okay. I think it will be useful to discuss possible attacks by untrust= ed intermediaries on the TEEP agent and how the TEEP agent can protect itse= lf (either in this document or in the TEEP protocol specification) ? e) The below line is not clear to me: Enumeration and access to the appropriate TEEP Broker is up to the Rich Exe= cution Environment and the Untrusted Applications.. [Hannes] There may be multiple TEEP Brokers on the system and the interacti= on between untrusted apps and the TEEP broker is up to a policy implemented= by the developer. I agree the line is confusingly worded. [TR] Please fix in the next update. h) A use case explaining the use of multiple TAM, multiple TEEP brokers on = a device, and multiple TEE would be useful to the reader of the specificati= on. Isn't that what Figure 2 already provides? Can you elaborate on what you'r= e looking for? [TR] I am looking for use cases, the text proposed by Hannes below looks li= ke a good starting point. [Hannes] Definitely a good idea to add text with use cases. Here is my quick response: - Multiple TAMs: you could think about this as having multiple cod= e repositories. Different SPs may prefer to use certain TAMs for their soft= ware distribution. - Multiple TEEP brokers: this can occur when you have a broker off= ered by the OS and one bundled with the untrusted app. - Multiple TEEs: This depends on the TEE technology. In the TrustZ= one case you may have a multi-processor system and each processor comes wit= h TrustZone support. i) When a TEEP Broker receives a request from an Untrusted Application to install a TA, a list of TAM URIs may be provided for that TA, and the request is passed to the TEEP Agent. If the TEEP Agent decides that the TA needs to be installed, the TEEP Agent selects a single TAM URI that is consistent with the list of trusted TAMs provisioned on the device invokes the HTTP transport for TEEP to connect to the TAM URI and begins a TEEP protocol exchange. Comment> I am not sure why the architecture draft is discussing the protoco= l aspects like HTTP for TEEP ? [Hannes] I believe it does not need to mention HTTP but it could list it as= an example. Sure. On the other hand, we have a WG document, and the architecture document can= mention it as explaining how that doc fits into the architecture and relat= es to the other docs. [TR] Fair point. j) What if the malware in REE instructs the TEEP agent via TEEP broker to k= eep installing/uninstalling TA (over-whelm the TEEP agent and TEE or instal= ling un-necessary TA to have no memory for the required TA) ? An REE can always conduct DoS attacks against a TEEP agent as discussed in = your question (c) above. However the word "instructs" is incorrect since the TEEP Agent is authorita= tive, your question should say "requests" instead, since the TEEP agent is = free to ignore/reject the request. (This is why section 6.2.1 has "Request= TA", as does the transport spec.) [Hannes] Having a compromised REE environment that causes all sorts of apps= to be installed is possible (assuming the TEE is authorizing the installat= ion of those apps). An implementation of the secure world, most likely the = TEE OS, will have to make sure that the device does not install TAs and ove= rwrite the memory space they have been configured to use. [TR] My suggestion is to discuss the above attack in the document. i) What is the use case for "Personalization data" ? There is an example in section 4.4: * an example of * personalization data might be a secret symmetric key used by the TA * to communicate with the SP [TR] Thanks, I missed the example. [Hannes] Personalization data is meant to make each instance of the TA uniq= ue and potentially tie it to a specific user. Imagine a TA that implements = biometric functionality: there has to be something in TA that relates this = instance of the TA to a specific human, for example by storing a fingerprin= t alongside the TA as configuration data. j) Why is Section 4.5 discussing Case 1 when it not in use ? [Hannes] We just describe the possible approach and illustrates how things = are done today. There is, however, a lot of development going on in the are= a of TEEs and I suspect that we will see all sorts of different use cases s= howing up in the future as the technology gets used in different environmen= ts. Agree with Hannes. [TR] Okay. k) The below line is not clear to me (please elaborate): Consequently, a TAM generally communicates with an Untrusted Application ab= out how it gets messages that originate from a TEE inside a device. [Hannes] The key point of that paragraph is that today TEEs do not communic= ate with the outside world but require the cooperation with something on th= e REE side. That whole paragraph is confusingly worded, and I currently plan to rewrite= it based on my marked up hard copy :) [TR] Okay. l) What is the use case for one TA and multiple SP ? [Hannes] I am not sure. I let Ming, DaveW, or DaveT respond. No idea, I'd propose deleting that section. I was confused by it as well. [TR] Works for me. m) what is the use case for keeping the TA binary secret from the TAM ? [Hannes] it is more and more common today to protect binaries from inspecti= on because this gives attackers a lot of information. If you don't want to = use it and only sign the binaries that's fine too. But the option is there = for you to protect the confidentiality of the binary. I believe the use case is where the app developer considers the TA binary i= tself to be secret (e.g., intellectual property worth protecting), but want= s to allow it to be distributed through a TAM that is run by another organi= zation, one with more hosting capacity. Thus the developer puts an encryp= ted binary in that TAM, and then runs their own lighter weight TAM that jus= t hands out decryption keys which doesn't need nearly as much much capacity= /bandwidth. [TR] Got it but it also allows the possibility of publishing malicious apps= the TAM/SP may not be able to validate (For instance Apple has a strict re= view process of apps before publishing on the iOS app store). Encrypting th= e binaries from inspection by attacker is required but TAM/SP are not neces= sarily the attackers. n) We allow a way for an Untrusted Application to check the trustworthiness= of a TA. Comment> You may want to re-phrase the above line, and remove "we". [Hannes] I think we should delete this paragraph: " We allow a way for an Untrusted Application to check the trustworthiness of a TA. A TEEP Broker has a function to allow an application to query the information about a TA. " Agreed it should be deleted. This was the second point of issue #116 that = I filed. [TR] Okay. o) A notification that an incoming TEEP session is being requested by a TEE= P Agent. Comment> What you meant by "incoming TEEP session" ? [Hannes] Dave should respond to this one because it relates to the HTTP tra= nsport, I believe. The TEEP protocol requires the agent to connect to the TAM. This is a not= ification about the initial connection. See the transport spec for more details. [TR] Thanks for the clarification. p) How does the TEEP broker communicate with the TEEP agent ? [Hannes] Via an API, for example the GP TEEP Client API. Right, implementation-specific detail. [TR] Okay. q) Section 5.3 says the architecture uses PKI but Section 9.1 discusses sel= f-signed certificates. Please fix. [Hannes] We need to clarify the statement about the self-signed TA binaries= . Sure. Figure 4 talks about multiple certificates. 5.3 is a general state= ment about multiple types. 9.1 is about one specific type of cert that may or may not have a PKI. So they are not in contradiction but yes clarification would be good. [TR] What is need for self-signed certificates when code signing certificat= es by CA are used today ? r) In Figure 4, for the purpose of "Code signing" my understanding is the l= ocation of corresponding CA certs is both TEE and TAM. [Hannes] I believe it would be useful to also store the CA cert that is use= d for code signing at the TAM because then it can verify the signed TAs. I don't believe there is any such requirement on a TAM. It might be "usef= ul" but is not required in my view. [TR] why do you think verification in TAM is not required ? If we indeed believe the text in Section 9.1 is correct then that code sign= ing CA cert also needs to be made available to the TEEP Broker and potentia= lly even to the untrusted app. I don't believe the text in 9.1 is correct. [TR] You may want to raise an issue in github to correct the text. s)I have seen several malicious apps in App store in both Android and iOS, = it is possible for an malicious App developer to publish both malicious unt= rusted applications and malicious trusted applications. I don't think the TEEP architecture= prevents this attack and it is the responsibility of TAM and App store to = remove such apps (see https://android-developers.googleblog.com/2018/01/how-we-fought-ba= d-apps-and-malicious.html) [Hannes] Yes, it would be the responsibility of the TAM, the device manufac= turer and the SP / developer to ensure that they do not distribute maliciou= s TAs. It's the responsibility of the TAM to not install malicious trusted apps, o= nly authorized ones. I don't think it's correct to say it's the responsibility of the TAM to "re= move" malicious trusted apps, since it shouldn't have installed it in the f= irst place. The only case where "removal" might make sense is if the TAM previously aut= horized a trusted app, and later changed its policy that such TA is no long= er authorized (e.g., because it was determined to be buggy or malicious or = whatever else). [TR] You may want to discuss the above case in the document. If the truste= d app is removed by TAM because it is malicious, some notification to the u= ser would be helpful to remove the associated untrusted application in the = REE. -Tiru Ciao Hannes Cheers, -Tiru From: Dave Thaler > Sent: Tuesday, January 7, 2020 8:44 AM To: Konda, Tirumaleswar Reddy >; teep@ietf.org Subject: RE: Working Group Last Call for draft-ietf-teep-architecture CAUTION: External email. Do not click links or open attachments unless you = recognize the sender and know the content is safe. ________________________________ I opened one pull request for editorial issues (https://github.com/ietf-tee= p/architecture/pull/109), and filed seven other issues listed at https://github..com/ietf-teep/archit= ecture/issues 110) Service Provider discussion is confusing 111) Terminology section is not consistently ordered 112) Text about carriers is confusing 113) Section 6.2.3 contradicts section 4.2 114) Figure 3 is too hard to understand 115) Reference to IANA number 116) Incorrect/obsolete statements about TEEP Broker I have ideas about how to address all of them, but if others have comments,= please speak up. The possibly(?) contentious one might be that in #110 I am proposing to use= the term "App Developer" throughout, instead of using "Service Provider" in some pla= ces and "App Developer" in others and then saying they're synonymous like it does now. (I'd be ok with ment= ioning that in some contexts an App Developer might be known as a "Service Provider" if that is important to GlobalPlatfo= rm folks.) Dave From: TEEP > On Behalf = Of Konda, Tirumaleswar Reddy Sent: Monday, December 23, 2019 4:17 AM To: teep@ietf.org Subject: [Teep] Working Group Last Call for draft-ietf-teep-architecture Hi all, This message starts a Work Group Last Call (WGLC) for TEEP architecture. T= he version to be reviewed is https://tools.ietf.org/html/draft-ietf-teep-ar= chitecture-05 The WGLC will last for 4 weeks and will end on 20 January 2020. Please send your comments to the list before this date and your assessment = of whether or not it is ready to proceed to publication. Regards, Tiru & Nancy IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_CY4PR1601MB125473BCC69227A45D62FAA7EA390CY4PR1601MB1254_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Hi Hannes and Dave,

 

Thanks for the responses. Please see inline [TR]

 

From: Dave Thaler <dthaler@microsoft.com&g= t;
Sent: Wednesday, January 8, 2020 1:14 AM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Konda, Tiru= maleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; teep@ietf.org Subject: RE: Working Group Last Call for draft-ietf-teep-architectur= e

 

CAUTION: External email. Do not click links or open attachments unless you recogniz= e the sender and know the content is safe.

 

Below

 

From: Hannes Tscho= fenig <Hannes.Tschofenig@ar= m.com>
Sent: Tuesday, January 7, 2020 1:28 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Dave Thaler= <dthaler@microsoft.com>= ; teep@ietf.org
Subject: RE: Working Group Last Call for draft-ietf-teep-architectur= e

 

Hi Tiru,

 

Thanks for the review. Th= ere is clearly room for improving the write-up.

 

A few remarks below.

 

From: TEEP <teep-bounces@ietf.org> On Behalf Of Konda, Tirumaleswar Reddy
Sent: Tuesday, January 7, 2020 7:39 AM
To: Dave Thaler <dthaler= @microsoft.com>; teep@ietf.org
Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-arch= itecture

 

[As an individual]

 

Hi Dave,

 

I have reviewed the dr= aft and have comments and nits listed below:

 

a) It is not clear fro= m the Introduction how TEE is different from a Closed OS like Google Chrome= book or Windows 10S ?

    &nb= sp;The benefit of Payment application running in Closed OS verses in TEE is= not evident from the description. What part of the Payment application run= s in the REE and TEE respectively ?

   &nbs= p; If biometric identification information is securely stored in TEE for id= entification, how does the TEE identify the biometric identification inform= ation is not retrieved by an malicious agent in the REE.

   &nbs= p; Section 3.3 (Internet of things), How does the architecture ensure the s= ensitive data is retrieved by a legitimate application in the REE and not b= y an malicious application ?  

 

[Hannes] The TEE adds = another layer of software isolation. To protect one TA to steal data from a= nother TA the two TAs need to be isolated against each other. Depending on = the TEE technology you are using this is accomplished via different means.

 

It is up to the applic= ation developer to decide how they best want to separate the REE and the TE= E part, which in part depends a bit on what type of payment protocol they a= re using. In some other cases (probably more realistic) they may be using an already existing payment system, whic= h is provided as a TA, and they are just using it. In general, it does not = strike me as a great idea to have random smart phone app developers writing= their own payment software.

 

[TR] Got it, Thanks.

 

The document (inten= tionally) makes no statement about whether a “close OS” as you = put it, is or is not a TEE.   The question is really about whethe= r such an OS prevents code injection attacks (e.g., due to buffer overruns or whatever else), prevents data modification attacks, etc= .

 

[TR] Closed OS prevent the above attacks, a malic= ious app cannot read/modify the data of the other apps (e.g., ransomware at= tack is not possible, see ht= tps://support.google.com/chromebook/answer/3438631?hl=3Den). 

 

b) Why should the list= of trust anchors on the device be managed by the Device's network carrier = ?

   &nbs= p; (you may want to define the term "network carrier").

 

This is issue #112 = that I filed.   Personally I think the term “carrier”= should be removed from the doc.

 

[TR] Works for me.

 

[Hannes] The text says= the following:

 

“

The list of Trust A= nchors is normally modifiable

   &= nbsp;  by the Device's owner or Device Administrator.  However th= e Device

   &= nbsp;  manufacturer and network carrier may restrict some modification= s,

   &= nbsp;  for example, by not allowing the manufacturer or carrier's Trus= t

   &= nbsp;  Anchor to be removed or disabled.

“

 

This describes current= practice in the mobile phone industry and may not necessarily be applicabl= e to other deployment scenarios. Hence, there is no required behavior here.

 

 

c) If the REE is compr= omised (for example by malware), it could terminate the TEEP broker in REE.= How is this attack mitigated ?

 

[Hannes] If the REE is= compromised then that’s typically not a good thing but the REE side = still cannot access anything on the secure world, if implemented correctly.= It could, however, indeed terminate the TEEP broker and avoid any calls to the secure world. This would be a DoS attack= . It would be possible to periodically schedule an interrupt that is proces= sed by the secure world to let the secure world double-check the state of t= he normal world.

 

Right.  DoS at= tacks by the REE are, in general, not prevented (some TEEs may prevent them= but most won’t).

The TEEP architectu= re doesn’t change this.

 

[TR] You may want to explain the above threat vec= tor in the document.

 

d) What happens if the= malicious agent acting as TEEP broker launches attacks (e.g. garbage data,= replay attack, DoS of messages etc.,) on the TEEP agent, and how will the = TEEP agent defend itself ?

 

[Hannes] The TEEP agen= t dispatches calls to the trusted applications. It is typically a shim laye= r that just checks parameters of the requests and then relays them to the T= As. Having a rock solid implementation of the TEEP agent is important and of course the TAs need to be implemente= d properly as well.

 

The GP TEE Client API = is meant to provide a reference design for an API that allows data passing = back and forth. So, implementing that API properly will be important. This = is why there is this open source project to implement that API so that other developers can just use it.

 

The TEEP Agent impl= ements a secure protocol (the TEEP protocol) between it and a TAM.
That protocol must be secure against attacks by untrusted intermediaries, i= ncluding routers, HTTP proxies, and TEEP brokers.

 

[TR] Okay. I think it will be useful to discuss p= ossible attacks by untrusted intermediaries on the TEEP agent and how the T= EEP agent can protect itself (either in this document or in the TEEP protoc= ol specification) ?

 

 

e) The below line is n= ot clear to me:

Enumeration and access= to the appropriate TEEP Broker is up to the Rich Execution Environment and= the Untrusted Applications..

 

[Hannes] There may be = multiple TEEP Brokers on the system and the interaction between untrusted a= pps and the TEEP broker is up to a policy implemented by the developer.

 

I agree the line is= confusingly worded.

 

[TR] Please fix in the next update.

 

h) A use case explaini= ng the use of multiple TAM, multiple TEEP brokers on a device, and multiple= TEE would be useful to the reader of the specification.

 

Isn’t that wh= at Figure 2 already provides?  Can you elaborate on what you’re = looking for?

 

[TR] I am looking for use cases, the text propose= d by Hannes below looks like a good starting point.

 

[Hannes] Definitely a = good idea to add text with use cases.

Here is my quick respo= nse:

 

-       = ;   Multiple TAMs: you could t= hink about this as having multiple code repositories. Different SPs may pre= fer to use certain TAMs for their software distribution.

-       = ;   Multiple TEEP brokers: thi= s can occur when you have a broker offered by the OS and one bundled with t= he untrusted app.

-       = ;   Multiple TEEs: This depend= s on the TEE technology. In the TrustZone case you may have a multi-process= or system and each processor comes with TrustZone support.

 

i) When a TEEP Broker = receives a request from an Untrusted Application

   to instal= l a TA, a list of TAM URIs may be provided for that TA, and

   the reque= st is passed to the TEEP Agent.  If the TEEP Agent decides<= /p>

   that the = TA needs to be installed, the TEEP Agent selects a single

   TAM URI t= hat is consistent with the list of trusted TAMs provisioned

   on the de= vice invokes the HTTP transport for TEEP to connect to the

   TAM URI a= nd begins a TEEP protocol exchange.

 

Comment> I am not s= ure why the architecture draft is discussing the protocol aspects like HTTP= for TEEP ?

 

[Hannes] I believe it = does not need to mention HTTP but it could list it as an example.

 

Sure.

 

On the other hand, = we have a WG document, and the architecture document can mention it as expl= aining how that doc fits into the architecture and relates to the other doc= s.

 

[TR] Fair point.

 

j) What if the malware= in REE instructs the TEEP agent via TEEP broker to keep installing/uninsta= lling TA (over-whelm the TEEP agent and TEE or installing un-necessary TA t= o have no memory for the required TA) ?

 

An REE can always c= onduct DoS attacks against a TEEP agent as discussed in your question (c) a= bove.

However the word &#= 8220;instructs” is incorrect since the TEEP Agent is authoritative, y= our question should say “requests” instead, since the TEEP agen= t is free to ignore/reject the request.  (This is why section 6.2.1 has “RequestTA”, as does the transport spec.)=

 

[Hannes] Having a comp= romised REE environment that causes all sorts of apps to be installed is po= ssible (assuming the TEE is authorizing the installation of those apps). An= implementation of the secure world, most likely the TEE OS, will have to make sure that the device does not in= stall TAs and overwrite the memory space they have been configured to use.

 

[TR] My suggestion is to discuss the above attack= in the document.

 

 

i)      &nbs= p;             What is the use case for &= quot;Personalization data" ?

 

There is an example= in section 4.4:

  • an example of
  • personalization data might be a secret symmetric key used by t= he TA
  • to communicate with t= he SP

 

[TR] Thanks, I missed the example.

 

[Hannes] Personalizati= on data is meant to make each instance of the TA unique and potentially tie= it to a specific user. Imagine a TA that implements biometric functionalit= y: there has to be something in TA that relates this instance of the TA to a specific human, for example by storin= g a fingerprint alongside the TA as configuration data.

 

j) Why is Section 4.5 = discussing Case 1 when it not in use ?

 

[Hannes] We just descr= ibe the possible approach and illustrates how things are done today. There = is, however, a lot of development going on in the area of TEEs and I suspec= t that we will see all sorts of different use cases showing up in the future as the technology gets used in differen= t environments.

 

Agree with Hannes.<= o:p>

 

[TR] Okay.

 

k) The below line is n= ot clear to me (please elaborate):

Consequently, a TAM ge= nerally communicates with an Untrusted Application about how it gets messag= es that originate from a TEE inside a device.

 

[Hannes] The key point= of that paragraph is that today TEEs do not communicate with the outside w= orld but require the cooperation with something on the REE side.

 

That whole paragrap= h is confusingly worded, and I currently plan to rewrite it based on my mar= ked up hard copy J

 

[TR] Okay.

 

l) What is the use cas= e for one TA and multiple SP ?

 

[Hannes] I am not sure= . I let Ming, DaveW, or DaveT respond.

 

No idea, I’d = propose deleting that section.   I was confused by it as well.

 

[TR] Works for me.

 

m) what is the use cas= e for keeping the TA binary secret from the TAM ?

 

[Hannes] it is more an= d more common today to protect binaries from inspection because this gives = attackers a lot of information. If you don’t want to use it and only = sign the binaries that’s fine too. But the option is there for you to protect the confidentiality of the binary.

 

I believe the use c= ase is where the app developer considers the TA binary itself to be secret = (e.g., intellectual property worth protecting), but wants to allow it to be= distributed through a TAM that is run by another organization, one with more hosting capacity.   Thus = the developer puts an encrypted binary in that TAM, and then runs their own= lighter weight TAM that just hands out decryption keys which doesn’t= need nearly as much much capacity/bandwidth.

 

[TR] Got it but it also allows the possibility of= publishing malicious apps the TAM/SP may not be able to validate (For inst= ance Apple has a strict review process of apps before publishing on the iOS= app store). Encrypting the binaries from inspection by attacker is required but TAM/SP are not necessarily the= attackers.

 

n) We allow a way for = an Untrusted Application to check the trustworthiness of a TA.

 

Comment> You may wa= nt to re-phrase the above line, and remove "we".

 

[Hannes] I think we sh= ould delete this paragraph:

“

   We=
 allow a way for an Untrusted Application to check the

   tr=
ustworthiness of a TA.  A TEEP Broker has a function to allow an<=
/o:p>


   ap=
plication to query the information about a TA.


“


 


Agreed it should be=
 deleted.  This was the second point of issue #116 that I filed.<=
/o:p>


 


[TR] Okay.


 


o) A notification that=
 an incoming TEEP session is being requested by a TEEP Agent.

 


Comment> What you m=
eant by "incoming TEEP session" ?


 


[Hannes] Dave should r=
espond to this one because it relates to the HTTP transport, I believe.



 


The TEEP protocol r=
equires the agent to connect to the TAM.   This is a notification=
 about the initial connection.


See the transport s=
pec for more details.


 


[TR] Thanks for the clarification.


 


 


p) How does the TEEP b=
roker communicate with the TEEP agent ?


 


[Hannes] Via an API, f=
or example the GP TEEP Client API.



 


Right, implementati=
on-specific detail.


 


[TR] Okay. 


 


q) Section 5.3 says th=
e architecture uses PKI but Section 9.1 discusses self-signed certificates.=
 Please fix.


 


[Hannes] We need to cl=
arify the statement about the self-signed TA binaries.



 


Sure.  Figure =
4 talks about multiple certificates.   5.3 is a general statement=
 about multiple types.


9.1 is about one sp=
ecific type of cert that may or may not have a PKI.


So they are not in =
contradiction but yes clarification would be good.


 


[TR] What is need for self-signed certificates wh=
en code signing certificates by CA are used today ?


 


r) In Figure 4, for th=
e purpose of "Code signing" my understanding is the location of c=
orresponding CA certs is both TEE and TAM.


 


[Hannes] I believe it =
would be useful to also store the CA cert that is used for code signing at =
the TAM because then it can verify the signed TAs.



 


I don’t belie=
ve there is any such requirement on a TAM.   It might be “u=
seful” but is not required in my view.


 


[TR] why do you thi=
nk verification in TAM is not required ?


 


If we indeed believe t=
he text in Section 9.1 is correct then that code signing CA cert also needs=
 to be made available to the TEEP Broker and potentially even to the untrus=
ted app.



 


I don’t belie=
ve the text in 9.1 is correct.


 


[TR] You may want to raise an issue in github to =
correct the text.



 


s)I have seen several =
malicious apps in App store in both Android and iOS, it is possible for an =
malicious App developer to publish both malicious untrusted applications



   and =
malicious trusted applications.  I don't think the TEEP architecture p=
revents this attack and it is the responsibility of TAM and App store to re=
move such apps



   &nbs=
p;(see 
https://android-developers.googleblog.com/2018/01/how-we-fought-bad-apps-an=
d-malicious.html)



 


[Hannes] Yes, it would=
 be the responsibility of the TAM, the device manufacturer and the SP / dev=
eloper to ensure that they do not distribute malicious TAs.


 


It’s the resp=
onsibility of the TAM to not install malicious trusted apps, only authorize=
d ones.


 


I don’t think=
 it’s correct to say it’s the responsibility of the TAM to R=
20;remove” malicious trusted apps, since it shouldn’t have inst=
alled it in the first place.


The only case where=
 “removal” might make sense is if the TAM previously authorized=
 a trusted app, and later changed its policy that such TA is no longer auth=
orized (e.g., because it was determined to be buggy
 or malicious or whatever else).


 


[TR] You may want to discuss the above case in th=
e document.  If the trusted app is removed by TAM because it is malici=
ous, some notification to the user would be helpful to remove the associate=
d untrusted application in the REE.


 


-Tiru


 


 


Ciao


Hannes


 


Cheers,


-Tiru


 








From: Dave Thaler <dthaler@microsoft.com>


Sent: Tuesday, January 7, 2020 8:44 AM

To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>;
teep@ietf.org

Subject: RE: Working Group Last Call for draft-ietf-teep-architectur=
e






 










CAUTION:
 External email. Do not click links or open attachments unless you recogniz=
e the sender and know the content is safe.








 










I opened one pull request for editorial issues (https://github.com/ietf-teep/architecture/pull/109),



and filed seven other issues listed at 
https://github..com/ietf-teep/architecture/issues



 


110) 
Service Provider discussion is confusing<=
o:p>


111) 
Terminology section is not consistently ordered


112) 
Text about carriers is confusing


113) 
Section 6.2.3 contradicts section 4.2


114) 
Figure 3 is too hard to understand


115) 
Reference to IANA number


116) 
Incorrect/obsolete statements about TEEP Broker<=
/a>


 


I have ideas about how to address all of them, but i=
f others have comments, please speak up.


 


The possibly(?) contentious one might be that in #11=
0 I am proposing to use the term


“App Developer” throughout, instead of u=
sing “Service Provider” in some places and “App Developer=
” in others


and then saying they’re synonymous like it doe=
s now.   (I’d be ok with mentioning that in some contexts a=
n App Developer


might be known as a “Service Provider” i=
f that is important to GlobalPlatform folks.)


 


Dave=



 






From: TEEP <teep-bounces@ietf.org>
On Behalf Of Konda, Tirumaleswar Reddy

Sent: Monday, December 23, 2019 4:17 AM

To: teep@ietf.org

Subject: [Teep] Working Group Last Call for draft-ietf-teep-architec=
ture






 


Hi all,


 


This message starts a Work Group Last Call (WGLC) fo=
r TEEP architecture.  The version to be reviewed is

https://tools.ietf.org/html/draft-ietf-teep-architecture-05 =



 


The WGLC will last for 4 weeks and will end on 20 Ja=
nuary 2020.


 


Please send your comments to the list before this da=
te and your assessment of whether or not it is ready to proceed to publicat=
ion.



 


Regards,


Tiru & Nancy




IMPORTANT NOTICE: The contents of this email and=
 any attachments are confidential and may also be privileged. If you are no=
t the intended recipient, please notify the sender
 immediately and do not disclose the contents to any other person, use it f=
or any purpose, or store or copy the information in any medium. Thank you.
--_000_CY4PR1601MB125473BCC69227A45D62FAA7EA390CY4PR1601MB1254_-- From nobody Fri Jan 10 04:38:47 2020 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDA2A12006E; Fri, 10 Jan 2020 04:38:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=armh.onmicrosoft.com header.b=Yp3da5hV; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=armh.onmicrosoft.com header.b=g3c0BloR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcq1SK8NWJER; Fri, 10 Jan 2020 04:38:31 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50061.outbound.protection.outlook.com [40.107.5.61]) (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 12A8012008F; Fri, 10 Jan 2020 04:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s2BRXVU/w42iYJZiziZZCXwPn2Nmo4ZpxypYGef1+f4=; b=Yp3da5hVPMaCBLP1jd12LuYk+QQOsJQnB07zYE9sWNZHepl8cjSPm6IHdaAvfKTvLU/GAw2WzPtBiGQRPaVqb8RNkHNffsStMuybO6xm3IV4BBXtFWL/ousZYCpvSn5l2VcGaR1o+WU54viYArjNX7dnn/9TEeQNLqV78gTfxy0= Received: from VI1PR0802CA0036.eurprd08.prod.outlook.com (2603:10a6:800:a9::22) by AM6PR08MB3381.eurprd08.prod.outlook.com (2603:10a6:20b:43::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.15; Fri, 10 Jan 2020 12:38:28 +0000 Received: from DB5EUR03FT056.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e0a::206) by VI1PR0802CA0036.outlook.office365.com (2603:10a6:800:a9::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9 via Frontend Transport; Fri, 10 Jan 2020 12:38:28 +0000 Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT056.mail.protection.outlook.com (10.152.21.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.11 via Frontend Transport; Fri, 10 Jan 2020 12:38:27 +0000 Received: ("Tessian outbound 28955e0c1ca8:v40"); Fri, 10 Jan 2020 12:38:27 +0000 X-CR-MTA-TID: 64aa7808 Received: from 61a95b26106a.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 5C8B850E-2580-41BD-AAE1-6638D167D61F.1; Fri, 10 Jan 2020 12:38:22 +0000 Received: from EUR01-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 61a95b26106a.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Fri, 10 Jan 2020 12:38:22 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZcAqc8p/My9c5/ILW9tgWAuvmuCIdJa19hZO2DYuPkuVObUMUW+bVJ5VWe6AmvpBADnuwp+8lXp+LYVMKsJ9M3+5I7RTE6Knz25WsMVbByivlJzShSdmgVoxedbhmj7p/QhSp2q5I1ZGvW1nyrbo7xjw2PGU4CUZa4s4qOotbubehzhbPAxXshl5kD1KVmvAhKstdQriK7mcTZXhE6djlFKJ1NZmfXHJbvRBBOLpND2+MtSVxLLbayrZ/CW+ZB1ZCwKDP+73qF1iIED56os4oHPjhlRaHZkS/uvkNQPE7k+nI4JspR+0fv4JRw7TZZRMy1S4kdXxaEj8viBAe9lw5w== 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=AEsbU0rncX4/j4RBz5f9O5UoxT0TUAqDsA3GafKJzQI=; b=C6ajwZbf6gM0nQ0FjnabuYY3LccJ5r29p0I3m7ZwZhfE+DMXf4FWs4ICpiPzkMr4bL2n2NmTeman93ujxUK54KWlwDMnsZDI6nTHqDNyTEJo3YhAaQjZ8ZwJAGhDBSdpzOjT9emvnnWAq6RnQkLqfFUmOkJymNDXOnflPfxW565sXcXkPYs5gLde3EPDiBka+EMxEYpZP8WMAWMyIR7JP6BwsiuNI70is44vO15qCHPQ3e6Z2hHuflJHbfPmRW0HxVWdqaFfscCmWp8ZbJIBEO+efTqpiX9Lwz2tq0JJ+hnhc7kF5yxTf3rT6cXOZ1UxS8Bp6sfS0JCKYa1dRhxkRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AEsbU0rncX4/j4RBz5f9O5UoxT0TUAqDsA3GafKJzQI=; b=g3c0BloRcJrnjbAHywkM9xFY+DUegjaWkQxPURJ4MeaHAGZI/TdjBBg4fGXXgScFT3T86UZZHGXSDbcIAx5wcWkLcrYyNEYLKK/v0Zh7ptVliI/LRZeXiQGOQCAu7gUBJbBXabl/onLmgF5syC5CiZl0SSQfQ26avzxNKVXjM5E= Received: from AM6PR08MB4423.eurprd08.prod.outlook.com (20.179.7.140) by AM6PR08MB5128.eurprd08.prod.outlook.com (10.255.120.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.9; Fri, 10 Jan 2020 12:38:21 +0000 Received: from AM6PR08MB4423.eurprd08.prod.outlook.com ([fe80::11a9:a944:c946:3030]) by AM6PR08MB4423.eurprd08.prod.outlook.com ([fe80::11a9:a944:c946:3030%7]) with mapi id 15.20.2623.013; Fri, 10 Jan 2020 12:38:21 +0000 From: Hannes Tschofenig To: "suit@ietf.org" , "teep@ietf.org" , "rats@ietf.org" CC: Matthias Waehlisch Thread-Topic: Hackathon almost "sold out" Thread-Index: AdXHsmMEnC9PXg28SzuFAbnu/zp/Rg== Date: Fri, 10 Jan 2020 12:38:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ts-tracking-id: 10ac53aa-c6ec-4d75-9447-a9c2c7d79957.0 x-checkrecipientchecked: true Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [195.149.223.43] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: adc5644a-bb14-49af-5de8-08d795c9fe15 X-MS-TrafficTypeDiagnostic: AM6PR08MB5128:|AM6PR08MB3381: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true x-ms-oob-tlc-oobclassifiers: OLM:8273;OLM:10000; x-forefront-prvs: 02788FF38E X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(376002)(136003)(396003)(346002)(366004)(39860400002)(189003)(199004)(53754006)(40434004)(66476007)(66556008)(316002)(64756008)(66946007)(76116006)(66446008)(55016002)(110136005)(8936002)(81156014)(8676002)(81166006)(9686003)(86362001)(966005)(6506007)(478600001)(7696005)(5660300002)(4744005)(26005)(71200400001)(33656002)(4326008)(186003)(52536014)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB5128; H:AM6PR08MB4423.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: TcA3b+u6PrLH9cANsVcQx7C7UPNghFL2L8M+rCCL1qjkjeqq0awe+hpAZ5c1mNSomP0PwVHm9eg/tbsRCtt1PEKzqD8ndZErtLKnatUw4nsC6Yxnrh6+vW9PENOzCcdHLj4NLs9YZGi6CYwb/YY5m96MFPbHZDYPx1L2b3unCC/8UT3I8Ya+PU1kxY1Xh87XAkFdH1A0LJ5E43WsDZ8O2q2i76fGZbGfgvQAw5vFh+1RBmvi3pJjV/nB+1hBFk3q3XYZsLkvVKDwngryM+DmduT0DvfLQ9tz+dW4cRcX2b/B6gnn8y/FbKt0LfoArkA8TVU0E+kWrlbNlHxcg52IAuFe8EVvNSU9VvYWw76+eaTA/mvcIrvTHJNYoFXUnSs4k4jgSzsdjpq7C8YXuEfjjBmibbd+AaC5nOl79b9+QXvS+gJpzmQxjvh3qqdGIEgKV1gAWQ+vuwIe9SJieCDNn4HrRl11v+48fTFJ+Q4O3PflHul28U7KZ9zGjeYmP17YeNBOJHAsxuwqZEZfvYP6wAOBMHRtqP8RmX9q3XDnGkgnjxlq+zlkIoYCXwmHNlP5 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-Transport-CrossTenantHeadersStamped: AM6PR08MB5128 Original-Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT056.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:63.35.35.123; IPV:CAL; SCL:-1; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(376002)(346002)(39860400002)(189003)(199004)(40434004)(53754006)(186003)(4744005)(316002)(8676002)(2906002)(81166006)(81156014)(107886003)(450100002)(86362001)(110136005)(8936002)(4326008)(26005)(336012)(356004)(70586007)(478600001)(26826003)(70206006)(52536014)(55016002)(33656002)(966005)(7696005)(9686003)(5660300002)(6506007); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB3381; H:64aa7808-outbound-1.mta.getcheckrecipient.com; FPR:; SPF:Pass; LANG:en; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; MX:1; A:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: e4f1ade5-d53c-4ade-8cde-08d795c9fa46 X-Forefront-PRVS: 02788FF38E X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: z/yK6WiqI3XjdrxtHAfubc3B5gbEd5J123/8kY0vzEhYneOaB0QJmuc0ICD6Obp6skkFcIUFyzUiw96Ht1ATmm4oLlTEFh+NDRyd0enSDCmDhLmQbh3+3OIogw7PrNIu8nn/DG3HdIFCp5fQko/f+EzkwX3eJgv+mDd8xOLHWLetq/mk1dPr1S1bajO6E1qjWHOl0eRMi4eFE9JzCHcs8SEgq3HghhMmjl4y9zPiBMkPkjMwu//wr8BdXzpqPHByMoqso6E9NnIYEBbygNiTSolYWAgOM+RkA8vBxk6v+2ZzvQyMIf3tcZCVSbfQOgn9EJnLNLYt/bOtcrr2rgBGjysyVwBvzQi6i0E2nIUKTsE1Uwg2Y2QeXy+C4DmSqHyYRjCKITdGbP2poBx64m8dcNEFyCfp9SZ9Dm0JrUcucDFg4jZoHlB8F153a0X8hUA+HAgmWQoLmTcMhRHgvwc5WFwR/KCeScZvSzvA7/uXlFHELG6LongDh7dkDGi2V6uiOAdsrXm+DPqdcziKXRZngEf3CKQXAAwtszRcimrqS2ryiPSGI6T0+sVmEw+EriML X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jan 2020 12:38:27.9142 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: adc5644a-bb14-49af-5de8-08d795c9fe15 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3381 Archived-At: Subject: [Teep] Hackathon almost "sold out" X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jan 2020 12:38:36 -0000 Hi all, the deadline for the "Securing the IoT (SIoT) Hackathon" is in 7 days but w= e are reaching our maximum participant limit already. If you plan to participate and have not yet registered, please do so as soo= n as possible. Here is the webpage with the registration link: https://siot-hackathon.github.io Ciao Hannes & Matthias IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. From nobody Sat Jan 11 22:42:01 2020 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE971200C7 for ; Sat, 11 Jan 2020 22:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.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, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCb5w2pqWtdI for ; Sat, 11 Jan 2020 22:41:54 -0800 (PST) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E90912003E for ; Sat, 11 Jan 2020 22:41:53 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id o13so6508076ljg.4 for ; Sat, 11 Jan 2020 22:41:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sgPFnZZPVRzvPXMu650sokuV1HN/vDDFykUwCphQR/A=; b=FT/CEqtMFPADI5IzIbgI+oEPCLYlTQ1E7j6VXhKGyJrJQZzk5yOS2oLuzY8LFhNgC5 I4qyzpxTkuHsm+NFXIC85Cvtre8lOplxPg53tpgWxPzT4jDydd2AM2Sib5hHCOUrYXEJ zJfdVVmOaTFdjxUUo+OHl8CbUYD74rBk+v6ac= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sgPFnZZPVRzvPXMu650sokuV1HN/vDDFykUwCphQR/A=; b=LVUb9BbCeBUrQyWx5FXN/RCfzN3GrSt9wrVqRSga1qS9cdw6fPEB0DhWF5uYsTZvAk 4atowlQwqU3Zmzwox6nqXJHvbuBuQ+VjJIOKYLmltH/6ja2qcfu1ZkWaHqP63yNZ8cJB Nngu75DfsJlzzT906t1AxbDAvmyCmvsds3CxlGz8j4UmOZ1RNxZqHOpDp8YPEQrDqKve Oc4vwNZqgZ1s6w3d+IIXqAmUvLeCkHh5ecFcwpXyaUBPv44fBPN0ZFei7KNN8QpXI5/+ 6UuzZ4mpa5nWQqA73eco1/sE3Y+fkkPOTkYxbVET6Ip1WAT3L+ecz8hkQ2FfnSEeFavr FweQ== X-Gm-Message-State: APjAAAXRuxadwDpcP474+UVFEcIIdtqsCIgTe71DXE6qTjBFtzzKFr1c r+zvXMoeJR9irdyeA6avlhKqk0GWR40visNnkI5TPg== X-Google-Smtp-Source: APXvYqwAxAJjQFR7o6Wxwv8LLR6yIYNtrE3un+OhGDTFXwhi48iaot3gezBzc5IPhp5+gTZrkks93VDDcUHTxEniSMM= X-Received: by 2002:a2e:b4cb:: with SMTP id r11mr7392797ljm.68.1578811311242; Sat, 11 Jan 2020 22:41:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mingliang Pei Date: Sat, 11 Jan 2020 22:41:39 -0800 Message-ID: To: "Konda, Tirumaleswar Reddy" Cc: Dave Thaler , Hannes Tschofenig , "teep@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005ff24e059beba7f3" Archived-At: Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jan 2020 06:41:59 -0000 --0000000000005ff24e059beba7f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tiru, thank you very much for your comments and suggestions. Thanks Dave and Hannes for prompt response for us. Please see my comments inlines, mostly on top of your last replies, and for several questions that need additional clarification. Thanks, Ming On Wed, Jan 8, 2020 at 11:53 PM Konda, Tirumaleswar Reddy < TirumaleswarReddy_Konda@mcafee.com> wrote: > Hi Hannes and Dave, > > > > Thanks for the responses. Please see inline [TR] > > > > *From:* Dave Thaler > *Sent:* Wednesday, January 8, 2020 1:14 AM > *To:* Hannes Tschofenig ; Konda, Tirumaleswar > Reddy ; teep@ietf.org > *Subject:* RE: Working Group Last Call for draft-ietf-teep-architecture > > > > *CAUTION*: External email. Do not click links or open attachments unless > you recognize the sender and know the content is safe. > > > ------------------------------ > > Below > > > > *From:* Hannes Tschofenig > *Sent:* Tuesday, January 7, 2020 1:28 AM > *To:* Konda, Tirumaleswar Reddy ; > Dave Thaler ; teep@ietf.org > *Subject:* RE: Working Group Last Call for draft-ietf-teep-architecture > > > > Hi Tiru, > > > > Thanks for the review. There is clearly room for improving the write-up. > > > > A few remarks below. > > > > *From:* TEEP *On Behalf Of *Konda, Tirumaleswar > Reddy > *Sent:* Tuesday, January 7, 2020 7:39 AM > *To:* Dave Thaler ; teep@ietf.org > *Subject:* Re: [Teep] Working Group Last Call for > draft-ietf-teep-architecture > > > > [As an individual] > > > > Hi Dave, > > > > I have reviewed the draft and have comments and nits listed below: > > > > a) It is not clear from the Introduction how TEE is different from a > Closed OS like Google Chromebook or Windows 10S ? > > The benefit of Payment application running in Closed OS verses in TE= E > is not evident from the description. What part of the Payment application > runs in the REE and TEE respectively ? > > If biometric identification information is securely stored in TEE fo= r > identification, how does the TEE identify the biometric identification > information is not retrieved by an malicious agent in the REE. > > Section 3.3 (Internet of things), How does the architecture ensure > the sensitive data is retrieved by a legitimate application in the REE an= d > not by an malicious application ? > > > > [Hannes] The TEE adds another layer of software isolation. To protect one > TA to steal data from another TA the two TAs need to be isolated against > each other. Depending on the TEE technology you are using this is > accomplished via different means. > > > > It is up to the application developer to decide how they best want to > separate the REE and the TEE part, which in part depends a bit on what ty= pe > of payment protocol they are using. In some other cases (probably more > realistic) they may be using an already existing payment system, which is > provided as a TA, and they are just using it. In general, it does not > strike me as a great idea to have random smart phone app developers writi= ng > their own payment software. > > > > [TR] Got it, Thanks. > > > > The document (intentionally) makes no statement about whether a =E2=80=9C= close OS=E2=80=9D > as you put it, is or is not a TEE. The question is really about whether > such an OS prevents code injection attacks (e.g., due to buffer overruns = or > whatever else), prevents data modification attacks, etc.. > > > > [TR] Closed OS prevent the above attacks, a malicious app cannot > read/modify the data of the other apps (e.g., ransomware attack is not > possible, see https://support.google.com/chromebook/answer/3438631?hl=3De= n > ). > > > > > b) Why should the list of trust anchors on the device be managed by the > Device's network carrier ? > > (you may want to define the term "network carrier"). > > > > This is issue #112 that I filed. Personally I think the term =E2=80=9Cc= arrier=E2=80=9D > should be removed from the doc. > > > Dave has this issue tracked, and I added comment there. For one, "a network carrier" applies to mobile device only, and we have other TEE device types. On the other hand, the "network carrier" text does have some relevance here. For mobile devices, Trust Anchors are expected to be set by device manufacturers. What to put by a device manufacturer into devices, however, is often governed or instructed by the network carrier that a particular mobile device is produced for. That is the history of this context. I think we can make this as an example of set for such a case. [TR] Works for me. > > > > [Hannes] The text says the following: > > > > =E2=80=9C > > The list of Trust Anchors is normally modifiable > > by the Device's owner or Device Administrator. However the Device > > manufacturer and network carrier may restrict some modifications, > > for example, by not allowing the manufacturer or carrier's Trust > > Anchor to be removed or disabled. > > =E2=80=9C > > > > This describes current practice in the mobile phone industry and may not > necessarily be applicable to other deployment scenarios. Hence, there is = no > required behavior here. > > > > > > c) If the REE is compromised (for example by malware), it could terminate > the TEEP broker in REE. How is this attack mitigated ? > > > > [Hannes] If the REE is compromised then that=E2=80=99s typically not a go= od thing > but the REE side still cannot access anything on the secure world, if > implemented correctly. It could, however, indeed terminate the TEEP broke= r > and avoid any calls to the secure world. This would be a DoS attack.. It > would be possible to periodically schedule an interrupt that is processed > by the secure world to let the secure world double-check the state of the > normal world. > > > > Right. DoS attacks by the REE are, in general, not prevented (some TEEs > may prevent them but most won=E2=80=99t). > > The TEEP architecture doesn=E2=80=99t change this. > > > > [TR] You may want to explain the above threat vector in the document. > > [MP] Agreed. Will add some text on this. > > d) What happens if the malicious agent acting as TEEP broker launches > attacks (e.g. garbage data, replay attack, DoS of messages etc.,) on the > TEEP agent, and how will the TEEP agent defend itself ? > > > > [Hannes] The TEEP agent dispatches calls to the trusted applications. It > is typically a shim layer that just checks parameters of the requests and > then relays them to the TAs. Having a rock solid implementation of the TE= EP > agent is important and of course the TAs need to be implemented properly = as > well. > > > > The GP TEE Client API is meant to provide a reference design for an API > that allows data passing back and forth. So, implementing that API proper= ly > will be important. This is why there is this open source project to > implement that API so that other developers can just use it. > > > > The TEEP Agent implements a secure protocol (the TEEP protocol) between i= t > and a TAM. > That protocol must be secure against attacks by untrusted intermediaries, > including routers, HTTP proxies, and TEEP brokers. > > > > [TR] Okay. I think it will be useful to discuss possible attacks by > untrusted intermediaries on the TEEP agent and how the TEEP agent can > protect itself (either in this document or in the TEEP protocol > specification) ? > > > [MP] We may add this and the above one in "Security Consideration". > > e) The below line is not clear to me: > > Enumeration and access to the appropriate TEEP Broker is up to the Rich > Execution Environment and the Untrusted Applications.. > > > > [Hannes] There may be multiple TEEP Brokers on the system and the > interaction between untrusted apps and the TEEP broker is up to a policy > implemented by the developer. > > > > I agree the line is confusingly worded. > > > > [TR] Please fix in the next update. > [MP] Agreed. Will fix. (Dave has had some on Multiple TEEP Broker). > > h) A use case explaining the use of multiple TAM, multiple TEEP brokers o= n > a device, and multiple TEE would be useful to the reader of the > specification. > > > > Isn=E2=80=99t that what Figure 2 already provides? Can you elaborate on = what > you=E2=80=99re looking for? > > > > [TR] I am looking for use cases, the text proposed by Hannes below looks > like a good starting point. > > > > [Hannes] Definitely a good idea to add text with use cases. > > Here is my quick response: > > > > - Multiple TAMs: you could think about this as having multiple > code repositories. Different SPs may prefer to use certain TAMs for their > software distribution. > > - Multiple TEEP brokers: this can occur when you have a broker > offered by the OS and one bundled with the untrusted app. > > - Multiple TEEs: This depends on the TEE technology. In the > TrustZone case you may have a multi-processor system and each processor > comes with TrustZone support. > > > > i) When a TEEP Broker receives a request from an Untrusted Application > > to install a TA, a list of TAM URIs may be provided for that TA, and > > the request is passed to the TEEP Agent. If the TEEP Agent decides > > that the TA needs to be installed, the TEEP Agent selects a single > > TAM URI that is consistent with the list of trusted TAMs provisioned > > on the device invokes the HTTP transport for TEEP to connect to the > > TAM URI and begins a TEEP protocol exchange. > > > > Comment> I am not sure why the architecture draft is discussing the > protocol aspects like HTTP for TEEP ? > > > > [Hannes] I believe it does not need to mention HTTP but it could list it > as an example. > > > > Sure. > > > > On the other hand, we have a WG document, and the architecture document > can mention it as explaining how that doc fits into the architecture and > relates to the other docs. > > > > [TR] Fair point. > > > > j) What if the malware in REE instructs the TEEP agent via TEEP broker to > keep installing/uninstalling TA (over-whelm the TEEP agent and TEE or > installing un-necessary TA to have no memory for the required TA) ? > > > > An REE can always conduct DoS attacks against a TEEP agent as discussed i= n > your question (c) above. > > However the word =E2=80=9Cinstructs=E2=80=9D is incorrect since the TEEP = Agent is > authoritative, your question should say =E2=80=9Crequests=E2=80=9D instea= d, since the TEEP > agent is free to ignore/reject the request. (This is why section 6.2.1 h= as > =E2=80=9CRequestTA=E2=80=9D, as does the transport spec.) > > > > [Hannes] Having a compromised REE environment that causes all sorts of > apps to be installed is possible (assuming the TEE is authorizing the > installation of those apps). An implementation of the secure world, most > likely the TEE OS, will have to make sure that the device does not instal= l > TAs and overwrite the memory space they have been configured to use. > > > > [TR] My suggestion is to discuss the above attack in the document. > > > [MP] Good point. We can add this threat discussion in Security Consideration. > > i) What is the use case for "Personalization data" ? > > > > There is an example in section 4.4: > > - an example of > > > - personalization data might be a secret symmetric key used by the TA > - to communicate with the SP > > > > [TR] Thanks, I missed the example. > > > > [Hannes] Personalization data is meant to make each instance of the TA > unique and potentially tie it to a specific user. Imagine a TA that > implements biometric functionality: there has to be something in TA that > relates this instance of the TA to a specific human, for example by stori= ng > a fingerprint alongside the TA as configuration data. > > > > j) Why is Section 4.5 discussing Case 1 when it not in use ? > > > > [Hannes] We just describe the possible approach and illustrates how thing= s > are done today. There is, however, a lot of development going on in the > area of TEEs and I suspect that we will see all sorts of different use > cases showing up in the future as the technology gets used in different > environments. > > > > Agree with Hannes. > > > > [TR] Okay. > > > > k) The below line is not clear to me (please elaborate): > > Consequently, a TAM generally communicates with an Untrusted Application > about how it gets messages that originate from a TEE inside a device. > > > > [Hannes] The key point of that paragraph is that today TEEs do not > communicate with the outside world but require the cooperation with > something on the REE side. > > > > That whole paragraph is confusingly worded, and I currently plan to > rewrite it based on my marked up hard copy J > > > > [TR] Okay. > > > > l) What is the use case for one TA and multiple SP ? > > > > [Hannes] I am not sure.. I let Ming, DaveW, or DaveT respond. > > > > No idea, I=E2=80=99d propose deleting that section. I was confused by i= t as well. > > > [MP] A TA software author can license the TA to multiple "buyers" who installs to their own user devices via their own TAM providers. The buyers are SPs in the original use case context. A TA developer doesn't necessarily distribute the TA. We have changed the meaning of SP to be interchangeable with an "App Developer" along with WG discussion, which treats the TA authorizer (SP) to devices as the owner of the TA. A SP may provide its own "TA personalization data". Different SPs may provide different data. There needs a way to address the case when the same TA is installed to a device by multiple providers. To this end, the proposal was to have different "identifiers" for the TA to multiple SPs so that they don't have to be overwritten. A Device Administrator may decide which TAM and TA it allows to install to devices. This is certainly a complex case, and not expected to be common in practice. Do you feel that we can disallow such a case where a TA author always directly works with a TAM service to distribute the TA? I feel that this licensed TA case may still have a place here. [TR] Works for me. > > > > m) what is the use case for keeping the TA binary secret from the TAM ? > > > > [Hannes] it is more and more common today to protect binaries from > inspection because this gives attackers a lot of information. If you don= =E2=80=99t > want to use it and only sign the binaries that=E2=80=99s fine too. But th= e option > is there for you to protect the confidentiality of the binary. > > > > I believe the use case is where the app developer considers the TA binary > itself to be secret (e.g., intellectual property worth protecting), but > wants to allow it to be distributed through a TAM that is run by another > organization, one with more hosting capacity. Thus the developer puts a= n > encrypted binary in that TAM, and then runs their own lighter weight TAM > that just hands out decryption keys which doesn=E2=80=99t need nearly as = much much > capacity/bandwidth. > > > > [TR] Got it but it also allows the possibility of publishing malicious > apps the TAM/SP may not be able to validate (For instance Apple has a > strict review process of apps before publishing on the iOS app store). > Encrypting the binaries from inspection by attacker is required but TAM/S= P > are not necessarily the attackers. > > [MP] I think this risk can be some contract between the TAM and the TA provider to manage. When a TAM doesn't want to risk its reputation to distribute malware, it may demand to inspect binary that a TA provider gives. Agree with you that a TAM most probably have the original TA binary access, who are not treated as an attacker by the TA developer. Note that the more common case of TA binary encryption common is for the TAM to encrypt the TA binary to prevent any man-in-the-middle from inspecting the binary. App Developer encrypted TA binary has a decryption key distribution challenge to a device. The separate TAM was devised for this purpose, but that was largely used for "personalization data" support case. > > n) We allow a way for an Untrusted Application to check the > trustworthiness of a TA. > > > > Comment> You may want to re-phrase the above line, and remove "we". > > > > [Hannes] I think we should delete this paragraph: > > =E2=80=9C > > We allow a way for an Untrusted Application to check the > > trustworthiness of a TA. A TEEP Broker has a function to allow an > > application to query the information about a TA. > > =E2=80=9C > > > > Agreed it should be deleted. This was the second point of issue #116 tha= t > I filed. > > > > [TR] Okay. > > > [MP] Agreed too. It was originally set there for local query without contacting a remote TAM to check a TA. o) A notification that an incoming TEEP session is being requested by a > TEEP Agent. > > > > Comment> What you meant by "incoming TEEP session" ? > > > > [Hannes] Dave should respond to this one because it relates to the HTTP > transport, I believe. > > > > The TEEP protocol requires the agent to connect to the TAM. This is a > notification about the initial connection. > > See the transport spec for more details. > > > > [TR] Thanks for the clarification. > > > > > > p) How does the TEEP broker communicate with the TEEP agent ? > > > > [Hannes] Via an API, for example the GP TEEP Client API. > > > > Right, implementation-specific detail. > > > > [TR] Okay. > > > > q) Section 5.3 says the architecture uses PKI but Section 9.1 discusses > self-signed certificates. Please fix. > > > > [Hannes] We need to clarify the statement about the self-signed TA > binaries. > > > > Sure. Figure 4 talks about multiple certificates. 5.3 is a general > statement about multiple types. > > 9.1 is about one specific type of cert that may or may not have a PKI. > > So they are not in contradiction but yes clarification would be good. > > > > [TR] What is need for self-signed certificates when code signing > certificates by CA are used today ? > > > > r) In Figure 4, for the purpose of "Code signing" my understanding is the > location of corresponding CA certs is both TEE and TAM. > > > > [Hannes] I believe it would be useful to also store the CA cert that is > used for code signing at the TAM because then it can verify the signed TA= s. > > > > I don=E2=80=99t believe there is any such requirement on a TAM. It migh= t be > =E2=80=9Cuseful=E2=80=9D but is not required in my view. > > > > [TR] why do you think verification in TAM is not required ? > > > [MP] TA signature verification must be verified. Currently a TEE will check this code signing, and the CA certificate will be in TEE. See Figure 4 in the doc. "Code Signing 1 per SP TA binary TEE" Note the above "TA binary encryption" discussion. If a TA is given to a TAM in an encrypted form, such a signature check isn't feasible. But we can assume that TAM provider always vet TA binaries that it distributes for its service reputation protection. Note that there is also the other TA delivery mode where a TA's binary is bundled inside an Untrusted Application as binary data. In this case, the binary isn't sent to TAM for distribution. There is also the other case: many SPs / TA App Developers use the same extremely popular TAM service. Device manufacturers may want to limit to accept only a set of TA providers by using the code signing CA trust list. The architecture allows such support with the coding signing trust check in TEE. If we indeed believe the text in Section 9.1 is correct then that code > signing CA cert also needs to be made available to the TEEP Broker and > potentially even to the untrusted app. > > > > I don=E2=80=99t believe the text in 9.1 is correct. > > > [MP] See above comment. > [TR] You may want to raise an issue in github to correct the text. > > > > s)I have seen several malicious apps in App store in both Android and iOS= , > it is possible for an malicious App developer to publish both malicious > untrusted applications > > and malicious trusted applications. I don't think the TEEP > architecture prevents this attack and it is the responsibility of TAM and > App store to remove such apps > > (see > https://android-developers.googleblog.com/2018/01/how-we-fought-bad-apps-= and-malicious.html > ) > > > > > [Hannes] Yes, it would be the responsibility of the TAM, the device > manufacturer and the SP / developer to ensure that they do not distribute > malicious TAs. > > > > It=E2=80=99s the responsibility of the TAM to not install malicious trust= ed apps, > only authorized ones. > > > > I don=E2=80=99t think it=E2=80=99s correct to say it=E2=80=99s the respon= sibility of the TAM to > =E2=80=9Cremove=E2=80=9D malicious trusted apps, since it shouldn=E2=80= =99t have installed it in > the first place. > > The only case where =E2=80=9Cremoval=E2=80=9D might make sense is if the = TAM previously > authorized a trusted app, and later changed its policy that such TA is no > longer authorized (e.g., because it was determined to be buggy or malicio= us > or whatever else). > > > > [TR] You may want to discuss the above case in the document. If the > trusted app is removed by TAM because it is malicious, some notification = to > the user would be helpful to remove the associated untrusted application = in > the REE. > > > [MP] Good suggestion. We may touch on this point in Security Consideration section too. > -Tiru > > > > > > Ciao > > Hannes > > > > Cheers, > > -Tiru > > > > *From:* Dave Thaler > *Sent:* Tuesday, January 7, 2020 8:44 AM > *To:* Konda, Tirumaleswar Reddy ; > teep@ietf.org > *Subject:* RE: Working Group Last Call for draft-ietf-teep-architecture > > > > *CAUTION*: External email. Do not click links or open attachments unless > you recognize the sender and know the content is safe. > > > ------------------------------ > > I opened one pull request for editorial issues ( > https://github.com/ietf-teep/architecture/pull/109 > ), > > > and filed seven other issues listed at > https://github..com/ietf-teep/architecture/issues > > > > > 110) Service Provider discussion is confusing > > > 111) Terminology section is not consistently ordered > > > 112) Text about carriers is confusing > > > 113) Section 6.2.3 contradicts section 4.2 > > > 114) Figure 3 is too hard to understand > > > 115) Reference to IANA number > > > 116) Incorrect/obsolete statements about TEEP Broker > > > > > I have ideas about how to address all of them, but if others have > comments, please speak up. > > > > The possibly(?) contentious one might be that in #110 I am proposing to > use the term > > =E2=80=9CApp Developer=E2=80=9D throughout, instead of using =E2=80=9CSer= vice Provider=E2=80=9D in some > places and =E2=80=9CApp Developer=E2=80=9D in others > > and then saying they=E2=80=99re synonymous like it does now. (I=E2=80= =99d be ok with > mentioning that in some contexts an App Developer > > might be known as a =E2=80=9CService Provider=E2=80=9D if that is importa= nt to > GlobalPlatform folks.) > > > > Dave > > > > *From:* TEEP *On Behalf Of *Konda, Tirumaleswar > Reddy > *Sent:* Monday, December 23, 2019 4:17 AM > *To:* teep@ietf.org > *Subject:* [Teep] Working Group Last Call for draft-ietf-teep-architectur= e > > > > Hi all, > > > > This message starts a Work Group Last Call (WGLC) for TEEP architecture. > The version to be reviewed is > https://tools.ietf.org/html/draft-ietf-teep-architecture-05 > > > > > The WGLC will last for 4 weeks and will end on 20 January 2020. > > > > Please send your comments to the list before this date and your assessmen= t > of whether or not it is ready to proceed to publication. > > > > Regards, > > Tiru & Nancy > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy th= e > information in any medium. Thank you. > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > > https://clicktime.symantec.com/3E4xJQVFydcmnjgspEbLjV47Vc?u=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep > --0000000000005ff24e059beba7f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tiru, thank you very much for your com= ments and suggestions. Thanks Dave and Hannes for prompt response for us.

Please see my comments = inlines, mostly on top of your last replies, and for several questions that= need additional clarification.

Thanks,

Ming
On W= ed, Jan 8, 2020 at 11:53 PM Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@mcafee.com= > wrote:

Hi Hannes and Dave,

=C2=A0

Thanks for the responses. Please see inline [TR] =

=C2=A0

From: Dave Thaler <dthaler@microsoft.com>
Sent: Wednesday, January 8, 2020 1:14 AM
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>; Konda, Tirumaleswar= Reddy <TirumaleswarReddy_Konda@McAfee.com>; teep@ietf.org
Subject: RE: Working Group Last Call for draft-ietf-teep-architectur= e

=C2=A0

CAUTION: External email. Do not click links or open attachments unless you recogniz= e the sender and know the content is safe.

=C2=A0

Below=

=C2=A0

From: Hannes Tsch= ofenig <H= annes.Tschofenig@arm.com>
Sent: Tuesday, January 7, 2020 1:28 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; Dave Thaler <dthaler@microsoft.com>; teep@ietf.org
Subject: RE: Working Group Last Call for draft-ietf-teep-architectur= e

=C2=A0

Hi Tiru, <= /p>

=C2=A0

Thanks for the review. T= here is clearly room for improving the write-up.

=C2=A0

A few remarks below. =

=C2=A0

From: TEEP <teep-bounces@ietf.= org> On Behalf Of Konda, Tirumaleswar Reddy
Sent: Tuesday, January 7, 2020 7:39 AM
To: Dave Thaler <dthaler@microsoft.com>; teep@ietf.org
Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-arch= itecture

=C2=A0

[As an individual]

=C2=A0

Hi Dave,

=C2=A0

I have reviewed the draft and have comments = and nits listed below:

=C2=A0

a) It is not clear from the Introduction how= TEE is different from a Closed OS like Google Chromebook or Windows 10S ?<= u>

=C2=A0=C2=A0=C2=A0 =C2=A0The benefit of Paym= ent application running in Closed OS verses in TEE is not evident from the = description. What part of the Payment application runs in the REE and TEE r= espectively ?

=C2=A0=C2=A0=C2=A0=C2=A0 If biometric identi= fication information is securely stored in TEE for identification, how does= the TEE identify the biometric identification information is not retrieved= by an malicious agent in the REE.

=C2=A0=C2=A0=C2=A0=C2=A0 Section 3.3 (Intern= et of things), How does the architecture ensure the sensitive data is retri= eved by a legitimate application in the REE and not by an malicious applica= tion ? =C2=A0

=C2=A0

[Hannes] The TEE adds another layer of softw= are isolation. To protect one TA to steal data from another TA the two TAs = need to be isolated against each other. Depending on the TEE technology you= are using this is accomplished via different means.

=C2=A0

It is up to the application developer to dec= ide how they best want to separate the REE and the TEE part, which in part = depends a bit on what type of payment protocol they are using. In some othe= r cases (probably more realistic) they may be using an already existing payment system, whic= h is provided as a TA, and they are just using it. In general, it does not = strike me as a great idea to have random smart phone app developers writing= their own payment software.

=C2=A0

[TR] Got it, Thanks.

=C2=A0

The document (intentionally) makes = no statement about whether a =E2=80=9Cclose OS=E2=80=9D as you put it, is o= r is not a TEE.=C2=A0=C2=A0 The question is really about whether such an OS= prevents code injection attacks (e.g., due to buffer overruns or whatever else), prevents data modification attacks, etc= ..

=C2=A0

[TR] Closed OS prevent the above attacks, a malicious app cannot read/mo= dify the data of the other apps (e.g., ransomware attack is not possible, s= ee https://support.google.com/chromebook/answer/3438631?hl=3D= en).=C2=A0

=C2=A0

b) Why should the list of trust anchors on t= he device be managed by the Device's network carrier ?

=C2=A0=C2=A0=C2=A0=C2=A0 (you may want to de= fine the term "network carrier").

=C2=A0

This is issue #112 that I filed.=C2= =A0=C2=A0 Personally I think the term =E2=80=9Ccarrier=E2=80=9D should be r= emoved from the doc.

=C2=A0


Dave= has this issue tracked, and I added comment there. For one, "a networ= k carrier" applies to mobile device only, and we have other TEE device= types. On the other hand, the "network carrier" text does have s= ome relevance here. For mobile devices, Trust Anchors are expected to be se= t by device manufacturers. What to put by a device manufacturer into device= s, however, is often governed or instructed by the network carrier that a p= articular mobile device is produced for. That is the history of this contex= t. I think we can make this as an example of set for such a case.
=

[TR] Works for me.

=C2=A0

[Hannes] The text says the following:

=C2=A0

=E2=80=9C

The list of Trust An= chors is normally modifiable

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 by the Device's owner or Device Administrator.=C2=A0 Howev= er the Device

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 manufacturer and network carrier may restrict some modificatio= ns,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 for example, by not allowing the manufacturer or carrier's= Trust

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 Anchor to be removed or disabled.

=E2=80=9C

=C2=A0

This describes current practice in the mobil= e phone industry and may not necessarily be applicable to other deployment = scenarios. Hence, there is no required behavior here.

=C2=A0

=C2=A0

c) If the REE is compromised (for example by= malware), it could terminate the TEEP broker in REE. How is this attack mi= tigated ?

=C2=A0

[Hannes] If the REE is compromised then that= =E2=80=99s typically not a good thing but the REE side still cannot access = anything on the secure world, if implemented correctly. It could, however, = indeed terminate the TEEP broker and avoid any calls to the secure world. This would be a DoS attack= .. It would be possible to periodically schedule an interrupt that is proce= ssed by the secure world to let the secure world double-check the state of = the normal world.

=C2=A0

Right.=C2=A0 DoS attacks by the REE= are, in general, not prevented (some TEEs may prevent them but most won=E2= =80=99t).

The TEEP architecture doesn=E2=80= =99t change this.

=C2=A0

[TR] You may want to explain the above threat vector in the document.=


[MP] Agreed. Will add some text on this.
<= br>

=C2=A0

d) What happens if the malicious agent actin= g as TEEP broker launches attacks (e.g. garbage data, replay attack, DoS of= messages etc.,) on the TEEP agent, and how will the TEEP agent defend itse= lf ?

=C2=A0

[Hannes] The TEEP agent dispatches calls to = the trusted applications. It is typically a shim layer that just checks par= ameters of the requests and then relays them to the TAs. Having a rock soli= d implementation of the TEEP agent is important and of course the TAs need to be implemente= d properly as well.

=C2=A0

The GP TEE Client API is meant to provide a = reference design for an API that allows data passing back and forth. So, im= plementing that API properly will be important. This is why there is this o= pen source project to implement that API so that other developers can just use it. =

=C2=A0

The TEEP Agent implements a secure = protocol (the TEEP protocol) between it and a TAM.
That protocol must be secure against attacks by untrusted intermediaries, i= ncluding routers, HTTP proxies, and TEEP brokers.

=C2=A0

[TR] Okay. I think it will be useful to discuss possible attacks by untr= usted intermediaries on the TEEP agent and how the TEEP agent can protect i= tself (either in this document or in the TEEP protocol specification) ?<= /u>

=C2=A0


[MP]= We may add this and the above one in "Security Consideration".

=C2=A0

e) The below line is not clear to me:=

Enumeration and access to the appropriate TE= EP Broker is up to the Rich Execution Environment and the Untrusted Applica= tions..

=C2=A0

[Hannes] There may be multiple TEEP Brokers = on the system and the interaction between untrusted apps and the TEEP broke= r is up to a policy implemented by the developer.

=C2=A0

I agree the line is confusingly wor= ded.

=C2=A0

[TR] Please fix in the next update.

<= div>
[MP] Agreed. Will fix. (Dave has had some on Multiple TE= EP Broker).

=C2=A0

h) A use case explaining the use of multiple= TAM, multiple TEEP brokers on a device, and multiple TEE would be useful t= o the reader of the specification.

=C2=A0

Isn=E2=80=99t that what Figure 2 al= ready provides?=C2=A0 Can you elaborate on what you=E2=80=99re looking for?=

=C2=A0

[TR] I am looking for use cases, the text proposed by Hannes below looks= like a good starting point.

=C2=A0

[Hannes] Definitely a good idea to add text = with use cases.

Here is my quick response:

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Multiple TAMs: you could thin= k about this as having multiple code repositories. Different SPs may prefer= to use certain TAMs for their software distribution.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Multiple TEEP brokers: this c= an occur when you have a broker offered by the OS and one bundled with the = untrusted app.

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Multiple TEEs: This depends o= n the TEE technology. In the TrustZone case you may have a multi-processor = system and each processor comes with TrustZone support.

=C2=A0

i) When a TEEP Broker receives a request fro= m an Untrusted Application

=C2=A0=C2=A0 to install a TA, a list of TAM = URIs may be provided for that TA, and

=C2=A0=C2=A0 the request is passed to the TE= EP Agent.=C2=A0 If the TEEP Agent decides

=C2=A0=C2=A0 that the TA needs to be install= ed, the TEEP Agent selects a single

=C2=A0=C2=A0 TAM URI that is consistent with= the list of trusted TAMs provisioned

=C2=A0=C2=A0 on the device invokes the HTTP = transport for TEEP to connect to the

=C2=A0=C2=A0 TAM URI and begins a TEEP proto= col exchange.

=C2=A0

Comment> I am not sure why the architectu= re draft is discussing the protocol aspects like HTTP for TEEP ?<= /u>

=C2=A0

[Hannes] I believe it does not need to menti= on HTTP but it could list it as an example.

=C2=A0

Sure.

=C2=A0

On the other hand, we have a WG doc= ument, and the architecture document can mention it as explaining how that = doc fits into the architecture and relates to the other docs.=

=C2=A0

[TR] Fair point.

=C2=A0

j) What if the malware in REE instructs the = TEEP agent via TEEP broker to keep installing/uninstalling TA (over-whelm t= he TEEP agent and TEE or installing un-necessary TA to have no memory for t= he required TA) ?

=C2=A0

An REE can always conduct DoS attac= ks against a TEEP agent as discussed in your question (c) above.<= /u>

However the word =E2=80=9Cinstructs= =E2=80=9D is incorrect since the TEEP Agent is authoritative, your question= should say =E2=80=9Crequests=E2=80=9D instead, since the TEEP agent is fre= e to ignore/reject the request.=C2=A0 (This is why section 6.2.1 has =E2=80=9CRequestTA=E2=80=9D, as does the transport spec.)=

=C2=A0

[Hannes] Having a compromised REE environmen= t that causes all sorts of apps to be installed is possible (assuming the T= EE is authorizing the installation of those apps). An implementation of the= secure world, most likely the TEE OS, will have to make sure that the device does not in= stall TAs and overwrite the memory space they have been configured to use.

=C2=A0

[TR] My suggestion is to discuss the above attack in the document.

=C2=A0


[MP]= Good point. We can add this threat discussion in Security Consideration.

=C2=A0

i)=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 What is the use case for &quo= t;Personalization data" ?

=C2=A0

There is an example in section 4.4:=

  • an example of<= /span>
  • personalization data might b= e a secret symmetric key used by the TA
  • to communicate with the SP

=C2=A0

[TR] Thanks, I missed the example.

=C2=A0

[Hannes] Personalization data is meant to ma= ke each instance of the TA unique and potentially tie it to a specific user= . Imagine a TA that implements biometric functionality: there has to be som= ething in TA that relates this instance of the TA to a specific human, for example by storin= g a fingerprint alongside the TA as configuration data.

=C2=A0

j) Why is Section 4.5 discussing Case 1 when= it not in use ?

=C2=A0

[Hannes] We just describe the possible appro= ach and illustrates how things are done today. There is, however, a lot of = development going on in the area of TEEs and I suspect that we will see all= sorts of different use cases showing up in the future as the technology gets used in differen= t environments.

=C2=A0

Agree with Hannes.

=C2=A0

[TR] Okay.

=C2=A0

k) The below line is not clear to me (please= elaborate):

Consequently, a TAM generally communicates w= ith an Untrusted Application about how it gets messages that originate from= a TEE inside a device.

=C2=A0

[Hannes] The key point of that paragraph is = that today TEEs do not communicate with the outside world but require the c= ooperation with something on the REE side.

=C2=A0

That whole paragraph is confusingly= worded, and I currently plan to rewrite it based on my marked up hard copy J<= u>

=C2=A0

[TR] Okay.

=C2=A0

l) What is the use case for one TA and multi= ple SP ?

=C2=A0

[Hannes] I am not sure.. I let Ming, DaveW, = or DaveT respond.

=C2=A0

No idea, I=E2=80=99d propose deleti= ng that section.=C2=A0=C2=A0 I was confused by it as well.

=C2=A0


[MP]= A TA software author can license the TA to multiple "buyers" who= installs to their own user devices via their own TAM providers. The buyers= are SPs in the original use case context. A TA developer doesn't neces= sarily distribute the TA. We have changed the meaning of SP to be interchan= geable with an "App Developer" along with WG discussion, which tr= eats the TA authorizer (SP) to devices as the owner of the TA.
A SP may provide its own "TA personalization data". = Different SPs may provide different data. There needs a way to address the = case when the same TA is installed to a device by multiple providers. To th= is end, the proposal was to have different "identifiers" for the = TA to multiple SPs so that they don't have to be overwritten. A Device = Administrator may decide which TAM and TA it allows to install to devices.<= br>

This is certainly a complex case, and not exp= ected to be common in practice. Do you feel that we can disallow such a cas= e where a TA author always directly works with a TAM service to distribute = the TA? I feel that this licensed TA case may still have a place here.
<= /div>

[TR] Works for me.

=C2=A0

m) what is the use case for keeping the TA b= inary secret from the TAM ?

=C2=A0

[Hannes] it is more and more common today to= protect binaries from inspection because this gives attackers a lot of inf= ormation. If you don=E2=80=99t want to use it and only sign the binaries th= at=E2=80=99s fine too. But the option is there for you to protect the confidentiality of the binary. <= /u>

=C2=A0

I believe the use case is where the= app developer considers the TA binary itself to be secret (e.g., intellect= ual property worth protecting), but wants to allow it to be distributed thr= ough a TAM that is run by another organization, one with more hosting capacity.=C2=A0=C2=A0 Thus = the developer puts an encrypted binary in that TAM, and then runs their own= lighter weight TAM that just hands out decryption keys which doesn=E2=80= =99t need nearly as much much capacity/bandwidth.

=C2=A0

[TR] Got it but it also allows the possibility of publishing malicious a= pps the TAM/SP may not be able to validate (For instance Apple has a strict= review process of apps before publishing on the iOS app store). Encrypting= the binaries from inspection by attacker is required but TAM/SP are not necessarily the= attackers.


[MP] I think this risk can be some contract between the T= AM and the TA provider to manage. When a TAM doesn't want to risk its r= eputation to distribute malware, it may demand to inspect binary that a TA = provider gives. Agree with you that a TAM most probably have the original T= A binary access, who are not treated as an attacker by the TA developer.

Note that the more common case of TA binary encr= yption common is for the TAM to encrypt the TA binary to prevent any man-in= -the-middle from inspecting the binary. App Developer encrypted TA binary h= as a decryption key distribution challenge to a device. The separate TAM wa= s devised for this purpose, but that was largely used for "personaliza= tion data" support case.

=

=C2=A0

n) We allow a way for an Untrusted Applicati= on to check the trustworthiness of a TA.

=C2=A0

Comment> You may want to re-phrase the ab= ove line, and remove "we".

=C2=A0

[Hannes] I think we should delete this parag= raph:

=E2=80=9C

=C2=A0=C2=A0 W=
e allow a way for an Untrusted Application to check the
=C2=A0=C2=A0 t=
rustworthiness of a TA.=C2=A0 A TEEP Broker has a function to allow an
=C2=A0=C2=A0 a=
pplication to query the information about a TA.

=E2=80=9C

=C2=A0

Agreed it should be deleted.=C2=A0 = This was the second point of issue #116 that I filed.<= /p>

=C2=A0

[TR] Okay.

=C2=A0


[MP] Agreed too. It was originally set there for lo= cal query without contacting a remote TAM to check a TA.

o) A notification that an incoming TEEP sess= ion is being requested by a TEEP Agent.

=C2=A0

Comment> What you meant by "incoming= TEEP session" ?

=C2=A0

[Hannes] Dave should respond to this one bec= ause it relates to the HTTP transport, I believe.

=C2=A0

The TEEP protocol requires the agen= t to connect to the TAM.=C2=A0=C2=A0 This is a notification about the initi= al connection.

See the transport spec for more det= ails.

=C2=A0

[TR] Thanks for the clarification.

=C2=A0

=C2=A0

p) How does the TEEP broker communicate with= the TEEP agent ?

=C2=A0

[Hannes] Via an API, for example the GP TEEP= Client API.

=C2=A0

Right, implementation-specific deta= il.

=C2=A0

[TR] Okay.

=C2=A0

q) Section 5.3 says the architecture uses PK= I but Section 9.1 discusses self-signed certificates. Please fix.=

=C2=A0

[Hannes] We need to clarify the statement ab= out the self-signed TA binaries.

=C2=A0

Sure.=C2=A0 Figure 4 talks about mu= ltiple certificates.=C2=A0=C2=A0 5.3 is a general statement about multiple = types.

9.1 is about one specific type of c= ert that may or may not have a PKI.

So they are not in contradiction bu= t yes clarification would be good.

=C2=A0

[TR] What is need for self-signed certificates when code signing certifi= cates by CA are used today ?

=C2=A0

r) In Figure 4, for the purpose of "Cod= e signing" my understanding is the location of corresponding CA certs = is both TEE and TAM.

=C2=A0

[Hannes] I believe it would be useful to als= o store the CA cert that is used for code signing at the TAM because then i= t can verify the signed TAs.

=C2=A0

I don=E2=80=99t believe there is an= y such requirement on a TAM.=C2=A0=C2=A0 It might be =E2=80=9Cuseful=E2=80= =9D but is not required in my view.

=C2=A0

[TR] why do you think verification = in TAM is not required ?

=C2=A0


[MP]=C2=A0 TA signature verificatio= n must be verified. Currently a TEE will check this code signing, and the C= A certificate will be in TEE. See Figure 4 in the doc.
"Code Signing          1 per SP       TA binary    =
      TEE"
Note the above "TA binary encrypti= on" discussion. If a TA is given to a TAM in an encrypted form, such a= signature check isn't feasible. But we can assume that TAM provider al= ways vet TA binaries that it distributes for its service reputation protect= ion.

Note that there is also the other TA deli= very mode where a TA's binary is bundled inside an Untrusted Applicatio= n as binary data. In this case, the binary isn't sent to TAM for distri= bution.

There is also the other case: many SPs= / TA App Developers use the same extremely popular TAM service. Device man= ufacturers may want to limit to accept only a set of TA providers by using = the code signing CA trust list. The architecture allows such support with t= he coding signing trust check in TEE.

If we indeed believe the text in Section 9.1= is correct then that code signing CA cert also needs to be made available = to the TEEP Broker and potentially even to the untrusted app.

=C2=A0

I don=E2=80=99t believe the text in= 9.1 is correct.

=C2=A0

[MP] See above comm= ent.

[TR] You may want to raise an issue in github to correct the text.

=C2=A0

s)I have seen several malicious apps in App = store in both Android and iOS, it is possible for an malicious App develope= r to publish both malicious untrusted applications

=C2=A0=C2=A0=C2=A0and malicious trusted appl= ications.=C2=A0 I don't think the TEEP architecture prevents this attac= k and it is the responsibility of TAM and App store to remove such apps

=C2=A0=C2=A0=C2=A0=C2=A0(see https://android-developers.googleblog.com/2018/01/how-we-fought-bad-apps-an= d-malicious.html)

=C2=A0

[Hannes] Yes, it would be the responsibility= of the TAM, the device manufacturer and the SP / developer to ensure that = they do not distribute malicious TAs.<= u>

=C2=A0

It=E2=80=99s the responsibility of = the TAM to not install malicious trusted apps, only authorized ones.=

=C2=A0

I don=E2=80=99t think it=E2=80=99s = correct to say it=E2=80=99s the responsibility of the TAM to =E2=80=9Cremov= e=E2=80=9D malicious trusted apps, since it shouldn=E2=80=99t have installe= d it in the first place.

The only case where =E2=80=9Cremova= l=E2=80=9D might make sense is if the TAM previously authorized a trusted a= pp, and later changed its policy that such TA is no longer authorized (e.g.= , because it was determined to be buggy or malicious or whatever else).

=C2=A0

[TR] You may want to discuss the above case in the document.=C2=A0 If th= e trusted app is removed by TAM because it is malicious, some notification = to the user would be helpful to remove the associated untrusted application= in the REE.

=C2=A0

[MP] Good suggestio= n. We may touch on this point in Security Consideration section too.
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
<= div style=3D"border-color:currentcolor currentcolor currentcolor blue;borde= r-style:none none none solid;border-width:medium medium medium 1.5pt;paddin= g:0in 0in 0in 4pt">

-Tiru

=C2=A0

=C2=A0

Ciao

Hannes

=C2=A0

Cheers,

-Tiru

=C2=A0

From: Dave Thaler <dthaler@microsoft.com>
Sent: Tuesday, January 7, 2020 8:44 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com>; teep@ietf.org
Subject: RE: Working Group Last Call for draft-ietf-teep-architectur= e

=C2=A0

CAUTION: External email. Do not click links or open attachments unless you recogniz= e the sender and know the content is safe.

=C2=A0

I opened one pull request for editorial issues (https://gi= thub.com/ietf-teep/architecture/pull/109),

and filed seven other issues listed at https://github..com/ietf-teep/architecture/issues

=C2=A0

110) Service Provider discussion is confusing<= u>

111) Terminology section is not consistently ordered

112) Text about carriers is confusing

113) Section 6.2.3 contradicts section 4.2<= /u>

114) Figure 3 is too hard to understand=

115) Reference to IANA number=

116) Incorrect/obsolete statements about TEEP Broker

=C2=A0

I have ideas about how to address all of them, but i= f others have comments, please speak up.

=C2=A0

The possibly(?) contentious one might be that in #11= 0 I am proposing to use the term

=E2=80=9CApp Developer=E2=80=9D throughout, instead = of using =E2=80=9CService Provider=E2=80=9D in some places and =E2=80=9CApp= Developer=E2=80=9D in others

and then saying they=E2=80=99re synonymous like it d= oes now.=C2=A0=C2=A0 (I=E2=80=99d be ok with mentioning that in some contex= ts an App Developer

might be known as a =E2=80=9CService Provider=E2=80= =9D if that is important to GlobalPlatform folks.)

=C2=A0

Dave<= /u>

=C2=A0

From: TEEP <teep-bounces@ietf.org> On Behalf Of Konda, Tirumaleswar Reddy
Sent: Monday, December 23, 2019 4:17 AM
To: teep@ietf.org=
Subject: [Teep] Working Group Last Call for draft-ietf-teep-architec= ture

=C2=A0

Hi all,

=C2=A0

This message starts a Work Group Last Call (WGLC) fo= r TEEP architecture.=C2=A0 The version to be reviewed is https://tools.ietf.org/html/draft-ietf-teep-architecture-05 <= /u>

=C2=A0

The WGLC will last for 4 weeks and will end on 20 Ja= nuary 2020.

=C2=A0

Please send your comments to the list before this da= te and your assessment of whether or not it is ready to proceed to publicat= ion.

=C2=A0

Regards,

Tiru & Nancy

IMPORTANT NOTICE: The contents of this email and a= ny attachments are confidential and may also be privileged. If you are not = the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it f= or any purpose, or store or copy the information in any medium. Thank you.

_______________________________________________
TEEP mailing list
TEEP@ietf.org
https://clicktime.symantec.com/3E4xJQVFydcmnjgspEbLjV47Vc?u= =3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
--0000000000005ff24e059beba7f3-- From nobody Mon Jan 13 01:46:39 2020 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907551200B3 for ; Mon, 13 Jan 2020 01:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 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, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nMe7KLDQP3j for ; Mon, 13 Jan 2020 01:46:33 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE13C120096 for ; Mon, 13 Jan 2020 01:46:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1578908791; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=eKpq/tA0vIUnsp7vzGzoqWg4x43SkXAtytqI8WPgVOQ=; b=lJoHr2tz6EswYnozx1PYENFIGgDMhroHb0U05zgN8siLsMVi4ImEfSZB2+v9RTFFtZCJcn w0J0OHwByyLAM2dK5PblVgSUL7RTlZvJbSajCl75c5dIjj0ybEum0e6Bss1Wtj1lAv1dUx 7fYDZmeH47gusnamCnJGP/dyh1pdURs= Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2172.outbound.protection.outlook.com [104.47.58.172]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-345-zEsO3vZ2MwiH7wiuG4LUYQ-1; Mon, 13 Jan 2020 04:46:28 -0500 Received: from DM5PR1601MB1259.namprd16.prod.outlook.com (10.172.87.13) by DM5PR1601MB1163.namprd16.prod.outlook.com (10.172.90.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.10; Mon, 13 Jan 2020 09:46:25 +0000 Received: from DM5PR1601MB1259.namprd16.prod.outlook.com ([fe80::949b:6afa:b9ba:f4e4]) by DM5PR1601MB1259.namprd16.prod.outlook.com ([fe80::949b:6afa:b9ba:f4e4%3]) with mapi id 15.20.2623.013; Mon, 13 Jan 2020 09:46:25 +0000 From: "Konda, Tirumaleswar Reddy" To: Mingliang Pei CC: Dave Thaler , Hannes Tschofenig , "teep@ietf.org" Thread-Topic: [Teep] Working Group Last Call for draft-ietf-teep-architecture Thread-Index: AdW5iepOELmpRRFXSAWsc0EhHQP19ALfbySAAAc0BIAABIf9gAAWBUMgACJiNvAAvsi6gAA1rNWA Date: Mon, 13 Jan 2020 09:46:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8b915df7-3842-4dbf-e115-08d7980d74a7 x-ms-traffictypediagnostic: DM5PR1601MB1163: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 028166BF91 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(396003)(346002)(366004)(376002)(136003)(199004)(32952001)(189003)(40434004)(86362001)(71200400001)(9686003)(7696005)(5660300002)(52536014)(30864003)(66574012)(2906002)(478600001)(45080400002)(55016002)(66946007)(186003)(26005)(53546011)(6506007)(76116006)(64756008)(66446008)(66556008)(66476007)(966005)(33656002)(54906003)(8936002)(81166006)(9326002)(81156014)(8676002)(4326008)(6916009)(316002)(85282002)(559001)(579004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1601MB1163; H:DM5PR1601MB1259.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Y9eLSefTJHlbkOj5nBlxdN6FnC5nITpXSKFpK6xwXVZDFiZXxJ2I1GTDtSNUdwKqPLoV/UtwUqyD5ZTERDolAUALRwcsG/QU8igSQioLcVD1tdjtY6hZFI6Uzm8SY1v2u5frXu1UPJVcaIXtn7z845ACGWGIVnl4ODAGPMufUTO49HKP/+gvCxnI1XbXuvEUjoYmatzIpfyzZKNr0c4ooOuj9WonkTJBuMRN9sx8ZlJXTheBd0m691srAxwtB1Iu7FDM1go7TKmPzr7o8kEewaRVvfL7qDExbByS1rCOQZXKKj/VTSrHinnD6q0FaP8WJ+EQLeTeoxJcPsoSmakZK+W4td34OzV3Zw3bsg2WRiUE0EvmWo6eUHa7DG8SQAN4w/Pmnkvu24dI4sMXN2XKTUq9xAqVf3Mo6E+bA7+LjC2z93eqC7zQ7DB5I/pAp3yNdWU+eov9SDzHM/bGXfxdJlt5pCZUclUljt7YZcnBrAcDCdQdwHu9MBTCrwuUMeGxE7mFcgKidSo0C816xUqbMpkpoucSY79sDoZO7h0qdoMf2CdjhV8107tSSVZQhZ7y9wAnm0GE0irVelEnPXbiiGtePS74hgXdQYM4eAFS0NA= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8b915df7-3842-4dbf-e115-08d7980d74a7 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2020 09:46:25.4281 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: C2OPS0CzoK8xvqX1jwvhO3IMsknj4F/lxnZ4ePm7uo0WhsBYXNTZRaNC39N0uPkXcOY3eEXLLudGzzr8jAaqWdpBU/Nc/sJUxKrpspEstYvNOeDGUWZp48zWD/FY10B0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1601MB1163 X-MC-Unique: zEsO3vZ2MwiH7wiuG4LUYQ-1 X-Mimecast-Spam-Score: 0 Content-Type: multipart/alternative; boundary="_000_DM5PR1601MB1259E8FF52F3287272903036EA350DM5PR1601MB1259_" Archived-At: Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jan 2020 09:46:37 -0000 --_000_DM5PR1601MB1259E8FF52F3287272903036EA350DM5PR1601MB1259_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgTWluZywNCg0KUGxlYXNlIHNlZSBpbmxpbmUgW1RSMl0NCg0KRnJvbTogTWluZ2xpYW5nIFBl aSA8bWluZ2xpYW5nLnBlaUBicm9hZGNvbS5jb20+DQpTZW50OiBTdW5kYXksIEphbnVhcnkgMTIs IDIwMjAgMTI6MTIgUE0NClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3 YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPg0KQ2M6IERhdmUgVGhhbGVyIDxkdGhhbGVyQG1pY3Jv c29mdC5jb20+OyBIYW5uZXMgVHNjaG9mZW5pZyA8SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbT47 IHRlZXBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbVGVlcF0gV29ya2luZyBHcm91cCBMYXN0IENh bGwgZm9yIGRyYWZ0LWlldGYtdGVlcC1hcmNoaXRlY3R1cmUNCg0KDQpDQVVUSU9OOiBFeHRlcm5h bCBlbWFpbC4gRG8gbm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlv dSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSGkgVGlydSwgdGhhbmsgeW91IHZlcnkg bXVjaCBmb3IgeW91ciBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuIFRoYW5rcyBEYXZlIGFuZCBI YW5uZXMgZm9yIHByb21wdCByZXNwb25zZSBmb3IgdXMuDQoNClBsZWFzZSBzZWUgbXkgY29tbWVu dHMgaW5saW5lcywgbW9zdGx5IG9uIHRvcCBvZiB5b3VyIGxhc3QgcmVwbGllcywgYW5kIGZvciBz ZXZlcmFsIHF1ZXN0aW9ucyB0aGF0IG5lZWQgYWRkaXRpb25hbCBjbGFyaWZpY2F0aW9uLg0KDQpU aGFua3MsDQoNCk1pbmcNCg0KT24gV2VkLCBKYW4gOCwgMjAyMCBhdCAxMTo1MyBQTSBLb25kYSwg VGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBtY2FmZWUuY29tPG1h aWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBtY2FmZWUuY29tPj4gd3JvdGU6DQpIaSBIYW5u ZXMgYW5kIERhdmUsDQoNClRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlcy4gUGxlYXNlIHNlZSBpbmxp bmUgW1RSXQ0KDQpGcm9tOiBEYXZlIFRoYWxlciA8ZHRoYWxlckBtaWNyb3NvZnQuY29tPG1haWx0 bzpkdGhhbGVyQG1pY3Jvc29mdC5jb20+Pg0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDgsIDIw MjAgMToxNCBBTQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnIDxIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0u Y29tPG1haWx0bzpIYW5uZXMuVHNjaG9mZW5pZ0Bhcm0uY29tPj47IEtvbmRhLCBUaXJ1bWFsZXN3 YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208bWFpbHRvOlRpcnVt YWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+PjsgdGVlcEBpZXRmLm9yZzxtYWlsdG86dGVl cEBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgZHJh ZnQtaWV0Zi10ZWVwLWFyY2hpdGVjdHVyZQ0KDQoNCkNBVVRJT046IEV4dGVybmFsIGVtYWlsLiBE byBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6 ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpCZWxvdw0KDQpGcm9tOiBIYW5uZXMgVHNjaG9mZW5pZyA8 SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbTxtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNv bT4+DQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDcsIDIwMjAgMToyOCBBTQ0KVG86IEtvbmRhLCBU aXJ1bWFsZXN3YXIgUmVkZHkgPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208bWFp bHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+PjsgRGF2ZSBUaGFsZXIgPGR0 aGFsZXJAbWljcm9zb2Z0LmNvbTxtYWlsdG86ZHRoYWxlckBtaWNyb3NvZnQuY29tPj47IHRlZXBA aWV0Zi5vcmc8bWFpbHRvOnRlZXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogV29ya2luZyBHcm91 cCBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtdGVlcC1hcmNoaXRlY3R1cmUNCg0KSGkgVGlydSwN Cg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBUaGVyZSBpcyBjbGVhcmx5IHJvb20gZm9yIGltcHJv dmluZyB0aGUgd3JpdGUtdXAuDQoNCkEgZmV3IHJlbWFya3MgYmVsb3cuDQoNCkZyb206IFRFRVAg PHRlZXAtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dGVlcC1ib3VuY2VzQGlldGYub3JnPj4gT24g QmVoYWxmIE9mIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNClNlbnQ6IFR1ZXNkYXksIEphbnVh cnkgNywgMjAyMCA3OjM5IEFNDQpUbzogRGF2ZSBUaGFsZXIgPGR0aGFsZXJAbWljcm9zb2Z0LmNv bTxtYWlsdG86ZHRoYWxlckBtaWNyb3NvZnQuY29tPj47IHRlZXBAaWV0Zi5vcmc8bWFpbHRvOnRl ZXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RlZXBdIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxs IGZvciBkcmFmdC1pZXRmLXRlZXAtYXJjaGl0ZWN0dXJlDQoNCg0KW0FzIGFuIGluZGl2aWR1YWxd DQoNCkhpIERhdmUsDQoNCg0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhlIGRyYWZ0IGFuZCBoYXZlIGNv bW1lbnRzIGFuZCBuaXRzIGxpc3RlZCBiZWxvdzoNCg0KDQoNCmEpIEl0IGlzIG5vdCBjbGVhciBm cm9tIHRoZSBJbnRyb2R1Y3Rpb24gaG93IFRFRSBpcyBkaWZmZXJlbnQgZnJvbSBhIENsb3NlZCBP UyBsaWtlIEdvb2dsZSBDaHJvbWVib29rIG9yIFdpbmRvd3MgMTBTID8NCg0KICAgICBUaGUgYmVu ZWZpdCBvZiBQYXltZW50IGFwcGxpY2F0aW9uIHJ1bm5pbmcgaW4gQ2xvc2VkIE9TIHZlcnNlcyBp biBURUUgaXMgbm90IGV2aWRlbnQgZnJvbSB0aGUgZGVzY3JpcHRpb24uIFdoYXQgcGFydCBvZiB0 aGUgUGF5bWVudCBhcHBsaWNhdGlvbiBydW5zIGluIHRoZSBSRUUgYW5kIFRFRSByZXNwZWN0aXZl bHkgPw0KDQogICAgIElmIGJpb21ldHJpYyBpZGVudGlmaWNhdGlvbiBpbmZvcm1hdGlvbiBpcyBz ZWN1cmVseSBzdG9yZWQgaW4gVEVFIGZvciBpZGVudGlmaWNhdGlvbiwgaG93IGRvZXMgdGhlIFRF RSBpZGVudGlmeSB0aGUgYmlvbWV0cmljIGlkZW50aWZpY2F0aW9uIGluZm9ybWF0aW9uIGlzIG5v dCByZXRyaWV2ZWQgYnkgYW4gbWFsaWNpb3VzIGFnZW50IGluIHRoZSBSRUUuDQoNCiAgICAgU2Vj dGlvbiAzLjMgKEludGVybmV0IG9mIHRoaW5ncyksIEhvdyBkb2VzIHRoZSBhcmNoaXRlY3R1cmUg ZW5zdXJlIHRoZSBzZW5zaXRpdmUgZGF0YSBpcyByZXRyaWV2ZWQgYnkgYSBsZWdpdGltYXRlIGFw cGxpY2F0aW9uIGluIHRoZSBSRUUgYW5kIG5vdCBieSBhbiBtYWxpY2lvdXMgYXBwbGljYXRpb24g Pw0KDQoNCg0KW0hhbm5lc10gVGhlIFRFRSBhZGRzIGFub3RoZXIgbGF5ZXIgb2Ygc29mdHdhcmUg aXNvbGF0aW9uLiBUbyBwcm90ZWN0IG9uZSBUQSB0byBzdGVhbCBkYXRhIGZyb20gYW5vdGhlciBU QSB0aGUgdHdvIFRBcyBuZWVkIHRvIGJlIGlzb2xhdGVkIGFnYWluc3QgZWFjaCBvdGhlci4gRGVw ZW5kaW5nIG9uIHRoZSBURUUgdGVjaG5vbG9neSB5b3UgYXJlIHVzaW5nIHRoaXMgaXMgYWNjb21w bGlzaGVkIHZpYSBkaWZmZXJlbnQgbWVhbnMuDQoNCg0KDQpJdCBpcyB1cCB0byB0aGUgYXBwbGlj YXRpb24gZGV2ZWxvcGVyIHRvIGRlY2lkZSBob3cgdGhleSBiZXN0IHdhbnQgdG8gc2VwYXJhdGUg dGhlIFJFRSBhbmQgdGhlIFRFRSBwYXJ0LCB3aGljaCBpbiBwYXJ0IGRlcGVuZHMgYSBiaXQgb24g d2hhdCB0eXBlIG9mIHBheW1lbnQgcHJvdG9jb2wgdGhleSBhcmUgdXNpbmcuIEluIHNvbWUgb3Ro ZXIgY2FzZXMgKHByb2JhYmx5IG1vcmUgcmVhbGlzdGljKSB0aGV5IG1heSBiZSB1c2luZyBhbiBh bHJlYWR5IGV4aXN0aW5nIHBheW1lbnQgc3lzdGVtLCB3aGljaCBpcyBwcm92aWRlZCBhcyBhIFRB LCBhbmQgdGhleSBhcmUganVzdCB1c2luZyBpdC4gSW4gZ2VuZXJhbCwgaXQgZG9lcyBub3Qgc3Ry aWtlIG1lIGFzIGEgZ3JlYXQgaWRlYSB0byBoYXZlIHJhbmRvbSBzbWFydCBwaG9uZSBhcHAgZGV2 ZWxvcGVycyB3cml0aW5nIHRoZWlyIG93biBwYXltZW50IHNvZnR3YXJlLg0KDQoNCg0KW1RSXSBH b3QgaXQsIFRoYW5rcy4NCg0KDQoNClRoZSBkb2N1bWVudCAoaW50ZW50aW9uYWxseSkgbWFrZXMg bm8gc3RhdGVtZW50IGFib3V0IHdoZXRoZXIgYSDigJxjbG9zZSBPU+KAnSBhcyB5b3UgcHV0IGl0 LCBpcyBvciBpcyBub3QgYSBURUUuICAgVGhlIHF1ZXN0aW9uIGlzIHJlYWxseSBhYm91dCB3aGV0 aGVyIHN1Y2ggYW4gT1MgcHJldmVudHMgY29kZSBpbmplY3Rpb24gYXR0YWNrcyAoZS5nLiwgZHVl IHRvIGJ1ZmZlciBvdmVycnVucyBvciB3aGF0ZXZlciBlbHNlKSwgcHJldmVudHMgZGF0YSBtb2Rp ZmljYXRpb24gYXR0YWNrcywgZXRjLi4NCg0KDQoNCltUUl0gQ2xvc2VkIE9TIHByZXZlbnQgdGhl IGFib3ZlIGF0dGFja3MsIGEgbWFsaWNpb3VzIGFwcCBjYW5ub3QgcmVhZC9tb2RpZnkgdGhlIGRh dGEgb2YgdGhlIG90aGVyIGFwcHMgKGUuZy4sIHJhbnNvbXdhcmUgYXR0YWNrIGlzIG5vdCBwb3Nz aWJsZSwgc2VlIGh0dHBzOi8vc3VwcG9ydC5nb29nbGUuY29tL2Nocm9tZWJvb2svYW5zd2VyLzM0 Mzg2MzE/aGw9ZW48aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNKUFNFQk5ydUJtVUtj dG1oYUJvR3BUN1ZjP3U9aHR0cHMlM0ElMkYlMkZzdXBwb3J0Lmdvb2dsZS5jb20lMkZjaHJvbWVi b29rJTJGYW5zd2VyJTJGMzQzODYzMSUzRmhsJTNEZW4+KS4NCg0KDQoNCmIpIFdoeSBzaG91bGQg dGhlIGxpc3Qgb2YgdHJ1c3QgYW5jaG9ycyBvbiB0aGUgZGV2aWNlIGJlIG1hbmFnZWQgYnkgdGhl IERldmljZSdzIG5ldHdvcmsgY2FycmllciA/DQoNCiAgICAgKHlvdSBtYXkgd2FudCB0byBkZWZp bmUgdGhlIHRlcm0gIm5ldHdvcmsgY2FycmllciIpLg0KDQoNCg0KVGhpcyBpcyBpc3N1ZSAjMTEy IHRoYXQgSSBmaWxlZC4gICBQZXJzb25hbGx5IEkgdGhpbmsgdGhlIHRlcm0g4oCcY2FycmllcuKA nSBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBkb2MuDQoNCg0KDQpEYXZlIGhhcyB0aGlzIGlz c3VlIHRyYWNrZWQsIGFuZCBJIGFkZGVkIGNvbW1lbnQgdGhlcmUuIEZvciBvbmUsICJhIG5ldHdv cmsgY2FycmllciIgYXBwbGllcyB0byBtb2JpbGUgZGV2aWNlIG9ubHksIGFuZCB3ZSBoYXZlIG90 aGVyIFRFRSBkZXZpY2UgdHlwZXMuIE9uIHRoZSBvdGhlciBoYW5kLCB0aGUgIm5ldHdvcmsgY2Fy cmllciIgdGV4dCBkb2VzIGhhdmUgc29tZSByZWxldmFuY2UgaGVyZS4gRm9yIG1vYmlsZSBkZXZp Y2VzLCBUcnVzdCBBbmNob3JzIGFyZSBleHBlY3RlZCB0byBiZSBzZXQgYnkgZGV2aWNlIG1hbnVm YWN0dXJlcnMuIFdoYXQgdG8gcHV0IGJ5IGEgZGV2aWNlIG1hbnVmYWN0dXJlciBpbnRvIGRldmlj ZXMsIGhvd2V2ZXIsIGlzIG9mdGVuIGdvdmVybmVkIG9yIGluc3RydWN0ZWQgYnkgdGhlIG5ldHdv cmsgY2FycmllciB0aGF0IGEgcGFydGljdWxhciBtb2JpbGUgZGV2aWNlIGlzIHByb2R1Y2VkIGZv ci4gVGhhdCBpcyB0aGUgaGlzdG9yeSBvZiB0aGlzIGNvbnRleHQuIEkgdGhpbmsgd2UgY2FuIG1h a2UgdGhpcyBhcyBhbiBleGFtcGxlIG9mIHNldCBmb3Igc3VjaCBhIGNhc2UuDQoNCltUUjJdIFRo YW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24uIFlvdSBtYXkgd2FudCB0byBhZGQgdGhlIG1vYmls ZSBkZXZpY2UgZXhhbXBsZSBpbiB0aGUgZG9jdW1lbnQuDQoNCg0KW1RSXSBXb3JrcyBmb3IgbWUu DQoNCg0KDQpbSGFubmVzXSBUaGUgdGV4dCBzYXlzIHRoZSBmb2xsb3dpbmc6DQoNCg0KDQrigJwN ClRoZSBsaXN0IG9mIFRydXN0IEFuY2hvcnMgaXMgbm9ybWFsbHkgbW9kaWZpYWJsZQ0KICAgICAg YnkgdGhlIERldmljZSdzIG93bmVyIG9yIERldmljZSBBZG1pbmlzdHJhdG9yLiAgSG93ZXZlciB0 aGUgRGV2aWNlDQogICAgICBtYW51ZmFjdHVyZXIgYW5kIG5ldHdvcmsgY2FycmllciBtYXkgcmVz dHJpY3Qgc29tZSBtb2RpZmljYXRpb25zLA0KICAgICAgZm9yIGV4YW1wbGUsIGJ5IG5vdCBhbGxv d2luZyB0aGUgbWFudWZhY3R1cmVyIG9yIGNhcnJpZXIncyBUcnVzdA0KICAgICAgQW5jaG9yIHRv IGJlIHJlbW92ZWQgb3IgZGlzYWJsZWQuDQoNCuKAnA0KDQoNCg0KVGhpcyBkZXNjcmliZXMgY3Vy cmVudCBwcmFjdGljZSBpbiB0aGUgbW9iaWxlIHBob25lIGluZHVzdHJ5IGFuZCBtYXkgbm90IG5l Y2Vzc2FyaWx5IGJlIGFwcGxpY2FibGUgdG8gb3RoZXIgZGVwbG95bWVudCBzY2VuYXJpb3MuIEhl bmNlLCB0aGVyZSBpcyBubyByZXF1aXJlZCBiZWhhdmlvciBoZXJlLg0KDQoNCg0KDQoNCmMpIElm IHRoZSBSRUUgaXMgY29tcHJvbWlzZWQgKGZvciBleGFtcGxlIGJ5IG1hbHdhcmUpLCBpdCBjb3Vs ZCB0ZXJtaW5hdGUgdGhlIFRFRVAgYnJva2VyIGluIFJFRS4gSG93IGlzIHRoaXMgYXR0YWNrIG1p dGlnYXRlZCA/DQoNCg0KDQpbSGFubmVzXSBJZiB0aGUgUkVFIGlzIGNvbXByb21pc2VkIHRoZW4g dGhhdOKAmXMgdHlwaWNhbGx5IG5vdCBhIGdvb2QgdGhpbmcgYnV0IHRoZSBSRUUgc2lkZSBzdGls bCBjYW5ub3QgYWNjZXNzIGFueXRoaW5nIG9uIHRoZSBzZWN1cmUgd29ybGQsIGlmIGltcGxlbWVu dGVkIGNvcnJlY3RseS4gSXQgY291bGQsIGhvd2V2ZXIsIGluZGVlZCB0ZXJtaW5hdGUgdGhlIFRF RVAgYnJva2VyIGFuZCBhdm9pZCBhbnkgY2FsbHMgdG8gdGhlIHNlY3VyZSB3b3JsZC4gVGhpcyB3 b3VsZCBiZSBhIERvUyBhdHRhY2suLiBJdCB3b3VsZCBiZSBwb3NzaWJsZSB0byBwZXJpb2RpY2Fs bHkgc2NoZWR1bGUgYW4gaW50ZXJydXB0IHRoYXQgaXMgcHJvY2Vzc2VkIGJ5IHRoZSBzZWN1cmUg d29ybGQgdG8gbGV0IHRoZSBzZWN1cmUgd29ybGQgZG91YmxlLWNoZWNrIHRoZSBzdGF0ZSBvZiB0 aGUgbm9ybWFsIHdvcmxkLg0KDQoNCg0KUmlnaHQuICBEb1MgYXR0YWNrcyBieSB0aGUgUkVFIGFy ZSwgaW4gZ2VuZXJhbCwgbm90IHByZXZlbnRlZCAoc29tZSBURUVzIG1heSBwcmV2ZW50IHRoZW0g YnV0IG1vc3Qgd29u4oCZdCkuDQoNClRoZSBURUVQIGFyY2hpdGVjdHVyZSBkb2VzbuKAmXQgY2hh bmdlIHRoaXMuDQoNCg0KDQpbVFJdIFlvdSBtYXkgd2FudCB0byBleHBsYWluIHRoZSBhYm92ZSB0 aHJlYXQgdmVjdG9yIGluIHRoZSBkb2N1bWVudC4NCg0KW01QXSBBZ3JlZWQuIFdpbGwgYWRkIHNv bWUgdGV4dCBvbiB0aGlzLg0KDQoNCg0KDQpkKSBXaGF0IGhhcHBlbnMgaWYgdGhlIG1hbGljaW91 cyBhZ2VudCBhY3RpbmcgYXMgVEVFUCBicm9rZXIgbGF1bmNoZXMgYXR0YWNrcyAoZS5nLiBnYXJi YWdlIGRhdGEsIHJlcGxheSBhdHRhY2ssIERvUyBvZiBtZXNzYWdlcyBldGMuLCkgb24gdGhlIFRF RVAgYWdlbnQsIGFuZCBob3cgd2lsbCB0aGUgVEVFUCBhZ2VudCBkZWZlbmQgaXRzZWxmID8NCg0K DQoNCltIYW5uZXNdIFRoZSBURUVQIGFnZW50IGRpc3BhdGNoZXMgY2FsbHMgdG8gdGhlIHRydXN0 ZWQgYXBwbGljYXRpb25zLiBJdCBpcyB0eXBpY2FsbHkgYSBzaGltIGxheWVyIHRoYXQganVzdCBj aGVja3MgcGFyYW1ldGVycyBvZiB0aGUgcmVxdWVzdHMgYW5kIHRoZW4gcmVsYXlzIHRoZW0gdG8g dGhlIFRBcy4gSGF2aW5nIGEgcm9jayBzb2xpZCBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgVEVFUCBh Z2VudCBpcyBpbXBvcnRhbnQgYW5kIG9mIGNvdXJzZSB0aGUgVEFzIG5lZWQgdG8gYmUgaW1wbGVt ZW50ZWQgcHJvcGVybHkgYXMgd2VsbC4NCg0KDQoNClRoZSBHUCBURUUgQ2xpZW50IEFQSSBpcyBt ZWFudCB0byBwcm92aWRlIGEgcmVmZXJlbmNlIGRlc2lnbiBmb3IgYW4gQVBJIHRoYXQgYWxsb3dz IGRhdGEgcGFzc2luZyBiYWNrIGFuZCBmb3J0aC4gU28sIGltcGxlbWVudGluZyB0aGF0IEFQSSBw cm9wZXJseSB3aWxsIGJlIGltcG9ydGFudC4gVGhpcyBpcyB3aHkgdGhlcmUgaXMgdGhpcyBvcGVu IHNvdXJjZSBwcm9qZWN0IHRvIGltcGxlbWVudCB0aGF0IEFQSSBzbyB0aGF0IG90aGVyIGRldmVs b3BlcnMgY2FuIGp1c3QgdXNlIGl0Lg0KDQoNCg0KVGhlIFRFRVAgQWdlbnQgaW1wbGVtZW50cyBh IHNlY3VyZSBwcm90b2NvbCAodGhlIFRFRVAgcHJvdG9jb2wpIGJldHdlZW4gaXQgYW5kIGEgVEFN Lg0KVGhhdCBwcm90b2NvbCBtdXN0IGJlIHNlY3VyZSBhZ2FpbnN0IGF0dGFja3MgYnkgdW50cnVz dGVkIGludGVybWVkaWFyaWVzLCBpbmNsdWRpbmcgcm91dGVycywgSFRUUCBwcm94aWVzLCBhbmQg VEVFUCBicm9rZXJzLg0KDQoNCg0KW1RSXSBPa2F5LiBJIHRoaW5rIGl0IHdpbGwgYmUgdXNlZnVs IHRvIGRpc2N1c3MgcG9zc2libGUgYXR0YWNrcyBieSB1bnRydXN0ZWQgaW50ZXJtZWRpYXJpZXMg b24gdGhlIFRFRVAgYWdlbnQgYW5kIGhvdyB0aGUgVEVFUCBhZ2VudCBjYW4gcHJvdGVjdCBpdHNl bGYgKGVpdGhlciBpbiB0aGlzIGRvY3VtZW50IG9yIGluIHRoZSBURUVQIHByb3RvY29sIHNwZWNp ZmljYXRpb24pID8NCg0KDQoNCltNUF0gV2UgbWF5IGFkZCB0aGlzIGFuZCB0aGUgYWJvdmUgb25l IGluICJTZWN1cml0eSBDb25zaWRlcmF0aW9uIi4NCg0KDQoNCg0KZSkgVGhlIGJlbG93IGxpbmUg aXMgbm90IGNsZWFyIHRvIG1lOg0KDQpFbnVtZXJhdGlvbiBhbmQgYWNjZXNzIHRvIHRoZSBhcHBy b3ByaWF0ZSBURUVQIEJyb2tlciBpcyB1cCB0byB0aGUgUmljaCBFeGVjdXRpb24gRW52aXJvbm1l bnQgYW5kIHRoZSBVbnRydXN0ZWQgQXBwbGljYXRpb25zLi4NCg0KDQoNCltIYW5uZXNdIFRoZXJl IG1heSBiZSBtdWx0aXBsZSBURUVQIEJyb2tlcnMgb24gdGhlIHN5c3RlbSBhbmQgdGhlIGludGVy YWN0aW9uIGJldHdlZW4gdW50cnVzdGVkIGFwcHMgYW5kIHRoZSBURUVQIGJyb2tlciBpcyB1cCB0 byBhIHBvbGljeSBpbXBsZW1lbnRlZCBieSB0aGUgZGV2ZWxvcGVyLg0KDQoNCg0KSSBhZ3JlZSB0 aGUgbGluZSBpcyBjb25mdXNpbmdseSB3b3JkZWQuDQoNCg0KDQpbVFJdIFBsZWFzZSBmaXggaW4g dGhlIG5leHQgdXBkYXRlLg0KDQpbTVBdIEFncmVlZC4gV2lsbCBmaXguIChEYXZlIGhhcyBoYWQg c29tZSBvbiBNdWx0aXBsZSBURUVQIEJyb2tlcikuDQoNCg0KDQoNCmgpIEEgdXNlIGNhc2UgZXhw bGFpbmluZyB0aGUgdXNlIG9mIG11bHRpcGxlIFRBTSwgbXVsdGlwbGUgVEVFUCBicm9rZXJzIG9u IGEgZGV2aWNlLCBhbmQgbXVsdGlwbGUgVEVFIHdvdWxkIGJlIHVzZWZ1bCB0byB0aGUgcmVhZGVy IG9mIHRoZSBzcGVjaWZpY2F0aW9uLg0KDQoNCg0KSXNu4oCZdCB0aGF0IHdoYXQgRmlndXJlIDIg YWxyZWFkeSBwcm92aWRlcz8gIENhbiB5b3UgZWxhYm9yYXRlIG9uIHdoYXQgeW914oCZcmUgbG9v a2luZyBmb3I/DQoNCg0KDQpbVFJdIEkgYW0gbG9va2luZyBmb3IgdXNlIGNhc2VzLCB0aGUgdGV4 dCBwcm9wb3NlZCBieSBIYW5uZXMgYmVsb3cgbG9va3MgbGlrZSBhIGdvb2Qgc3RhcnRpbmcgcG9p bnQuDQoNCg0KDQpbSGFubmVzXSBEZWZpbml0ZWx5IGEgZ29vZCBpZGVhIHRvIGFkZCB0ZXh0IHdp dGggdXNlIGNhc2VzLg0KDQpIZXJlIGlzIG15IHF1aWNrIHJlc3BvbnNlOg0KDQoNCi0gICAgICAg ICAgTXVsdGlwbGUgVEFNczogeW91IGNvdWxkIHRoaW5rIGFib3V0IHRoaXMgYXMgaGF2aW5nIG11 bHRpcGxlIGNvZGUgcmVwb3NpdG9yaWVzLiBEaWZmZXJlbnQgU1BzIG1heSBwcmVmZXIgdG8gdXNl IGNlcnRhaW4gVEFNcyBmb3IgdGhlaXIgc29mdHdhcmUgZGlzdHJpYnV0aW9uLg0KLSAgICAgICAg ICBNdWx0aXBsZSBURUVQIGJyb2tlcnM6IHRoaXMgY2FuIG9jY3VyIHdoZW4geW91IGhhdmUgYSBi cm9rZXIgb2ZmZXJlZCBieSB0aGUgT1MgYW5kIG9uZSBidW5kbGVkIHdpdGggdGhlIHVudHJ1c3Rl ZCBhcHAuDQotICAgICAgICAgIE11bHRpcGxlIFRFRXM6IFRoaXMgZGVwZW5kcyBvbiB0aGUgVEVF IHRlY2hub2xvZ3kuIEluIHRoZSBUcnVzdFpvbmUgY2FzZSB5b3UgbWF5IGhhdmUgYSBtdWx0aS1w cm9jZXNzb3Igc3lzdGVtIGFuZCBlYWNoIHByb2Nlc3NvciBjb21lcyB3aXRoIFRydXN0Wm9uZSBz dXBwb3J0Lg0KDQoNCg0KaSkgV2hlbiBhIFRFRVAgQnJva2VyIHJlY2VpdmVzIGEgcmVxdWVzdCBm cm9tIGFuIFVudHJ1c3RlZCBBcHBsaWNhdGlvbg0KDQogICB0byBpbnN0YWxsIGEgVEEsIGEgbGlz dCBvZiBUQU0gVVJJcyBtYXkgYmUgcHJvdmlkZWQgZm9yIHRoYXQgVEEsIGFuZA0KDQogICB0aGUg cmVxdWVzdCBpcyBwYXNzZWQgdG8gdGhlIFRFRVAgQWdlbnQuICBJZiB0aGUgVEVFUCBBZ2VudCBk ZWNpZGVzDQoNCiAgIHRoYXQgdGhlIFRBIG5lZWRzIHRvIGJlIGluc3RhbGxlZCwgdGhlIFRFRVAg QWdlbnQgc2VsZWN0cyBhIHNpbmdsZQ0KDQogICBUQU0gVVJJIHRoYXQgaXMgY29uc2lzdGVudCB3 aXRoIHRoZSBsaXN0IG9mIHRydXN0ZWQgVEFNcyBwcm92aXNpb25lZA0KDQogICBvbiB0aGUgZGV2 aWNlIGludm9rZXMgdGhlIEhUVFAgdHJhbnNwb3J0IGZvciBURUVQIHRvIGNvbm5lY3QgdG8gdGhl DQoNCiAgIFRBTSBVUkkgYW5kIGJlZ2lucyBhIFRFRVAgcHJvdG9jb2wgZXhjaGFuZ2UuDQoNCg0K DQpDb21tZW50PiBJIGFtIG5vdCBzdXJlIHdoeSB0aGUgYXJjaGl0ZWN0dXJlIGRyYWZ0IGlzIGRp c2N1c3NpbmcgdGhlIHByb3RvY29sIGFzcGVjdHMgbGlrZSBIVFRQIGZvciBURUVQID8NCg0KDQoN CltIYW5uZXNdIEkgYmVsaWV2ZSBpdCBkb2VzIG5vdCBuZWVkIHRvIG1lbnRpb24gSFRUUCBidXQg aXQgY291bGQgbGlzdCBpdCBhcyBhbiBleGFtcGxlLg0KDQoNCg0KU3VyZS4NCg0KDQoNCk9uIHRo ZSBvdGhlciBoYW5kLCB3ZSBoYXZlIGEgV0cgZG9jdW1lbnQsIGFuZCB0aGUgYXJjaGl0ZWN0dXJl IGRvY3VtZW50IGNhbiBtZW50aW9uIGl0IGFzIGV4cGxhaW5pbmcgaG93IHRoYXQgZG9jIGZpdHMg aW50byB0aGUgYXJjaGl0ZWN0dXJlIGFuZCByZWxhdGVzIHRvIHRoZSBvdGhlciBkb2NzLg0KDQoN Cg0KW1RSXSBGYWlyIHBvaW50Lg0KDQoNCg0KaikgV2hhdCBpZiB0aGUgbWFsd2FyZSBpbiBSRUUg aW5zdHJ1Y3RzIHRoZSBURUVQIGFnZW50IHZpYSBURUVQIGJyb2tlciB0byBrZWVwIGluc3RhbGxp bmcvdW5pbnN0YWxsaW5nIFRBIChvdmVyLXdoZWxtIHRoZSBURUVQIGFnZW50IGFuZCBURUUgb3Ig aW5zdGFsbGluZyB1bi1uZWNlc3NhcnkgVEEgdG8gaGF2ZSBubyBtZW1vcnkgZm9yIHRoZSByZXF1 aXJlZCBUQSkgPw0KDQoNCg0KQW4gUkVFIGNhbiBhbHdheXMgY29uZHVjdCBEb1MgYXR0YWNrcyBh Z2FpbnN0IGEgVEVFUCBhZ2VudCBhcyBkaXNjdXNzZWQgaW4geW91ciBxdWVzdGlvbiAoYykgYWJv dmUuDQoNCkhvd2V2ZXIgdGhlIHdvcmQg4oCcaW5zdHJ1Y3Rz4oCdIGlzIGluY29ycmVjdCBzaW5j ZSB0aGUgVEVFUCBBZ2VudCBpcyBhdXRob3JpdGF0aXZlLCB5b3VyIHF1ZXN0aW9uIHNob3VsZCBz YXkg4oCccmVxdWVzdHPigJ0gaW5zdGVhZCwgc2luY2UgdGhlIFRFRVAgYWdlbnQgaXMgZnJlZSB0 byBpZ25vcmUvcmVqZWN0IHRoZSByZXF1ZXN0LiAgKFRoaXMgaXMgd2h5IHNlY3Rpb24gNi4yLjEg aGFzIOKAnFJlcXVlc3RUQeKAnSwgYXMgZG9lcyB0aGUgdHJhbnNwb3J0IHNwZWMuKQ0KDQoNCg0K W0hhbm5lc10gSGF2aW5nIGEgY29tcHJvbWlzZWQgUkVFIGVudmlyb25tZW50IHRoYXQgY2F1c2Vz IGFsbCBzb3J0cyBvZiBhcHBzIHRvIGJlIGluc3RhbGxlZCBpcyBwb3NzaWJsZSAoYXNzdW1pbmcg dGhlIFRFRSBpcyBhdXRob3JpemluZyB0aGUgaW5zdGFsbGF0aW9uIG9mIHRob3NlIGFwcHMpLiBB biBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgc2VjdXJlIHdvcmxkLCBtb3N0IGxpa2VseSB0aGUgVEVF IE9TLCB3aWxsIGhhdmUgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGRldmljZSBkb2VzIG5vdCBpbnN0 YWxsIFRBcyBhbmQgb3ZlcndyaXRlIHRoZSBtZW1vcnkgc3BhY2UgdGhleSBoYXZlIGJlZW4gY29u ZmlndXJlZCB0byB1c2UuDQoNCg0KDQpbVFJdIE15IHN1Z2dlc3Rpb24gaXMgdG8gZGlzY3VzcyB0 aGUgYWJvdmUgYXR0YWNrIGluIHRoZSBkb2N1bWVudC4NCg0KDQoNCltNUF0gR29vZCBwb2ludC4g V2UgY2FuIGFkZCB0aGlzIHRocmVhdCBkaXNjdXNzaW9uIGluIFNlY3VyaXR5IENvbnNpZGVyYXRp b24uDQoNCg0KDQoNCmkpICAgICAgICAgICAgICAgICAgICBXaGF0IGlzIHRoZSB1c2UgY2FzZSBm b3IgIlBlcnNvbmFsaXphdGlvbiBkYXRhIiA/DQoNCg0KDQpUaGVyZSBpcyBhbiBleGFtcGxlIGlu IHNlY3Rpb24gNC40Og0KDQogICogICBhbiBleGFtcGxlIG9mDQoNCiAgKiAgIHBlcnNvbmFsaXph dGlvbiBkYXRhIG1pZ2h0IGJlIGEgc2VjcmV0IHN5bW1ldHJpYyBrZXkgdXNlZCBieSB0aGUgVEEN CiAgKiAgIHRvIGNvbW11bmljYXRlIHdpdGggdGhlIFNQDQoNCg0KDQpbVFJdIFRoYW5rcywgSSBt aXNzZWQgdGhlIGV4YW1wbGUuDQoNCg0KDQpbSGFubmVzXSBQZXJzb25hbGl6YXRpb24gZGF0YSBp cyBtZWFudCB0byBtYWtlIGVhY2ggaW5zdGFuY2Ugb2YgdGhlIFRBIHVuaXF1ZSBhbmQgcG90ZW50 aWFsbHkgdGllIGl0IHRvIGEgc3BlY2lmaWMgdXNlci4gSW1hZ2luZSBhIFRBIHRoYXQgaW1wbGVt ZW50cyBiaW9tZXRyaWMgZnVuY3Rpb25hbGl0eTogdGhlcmUgaGFzIHRvIGJlIHNvbWV0aGluZyBp biBUQSB0aGF0IHJlbGF0ZXMgdGhpcyBpbnN0YW5jZSBvZiB0aGUgVEEgdG8gYSBzcGVjaWZpYyBo dW1hbiwgZm9yIGV4YW1wbGUgYnkgc3RvcmluZyBhIGZpbmdlcnByaW50IGFsb25nc2lkZSB0aGUg VEEgYXMgY29uZmlndXJhdGlvbiBkYXRhLg0KDQoNCg0KaikgV2h5IGlzIFNlY3Rpb24gNC41IGRp c2N1c3NpbmcgQ2FzZSAxIHdoZW4gaXQgbm90IGluIHVzZSA/DQoNCg0KDQpbSGFubmVzXSBXZSBq dXN0IGRlc2NyaWJlIHRoZSBwb3NzaWJsZSBhcHByb2FjaCBhbmQgaWxsdXN0cmF0ZXMgaG93IHRo aW5ncyBhcmUgZG9uZSB0b2RheS4gVGhlcmUgaXMsIGhvd2V2ZXIsIGEgbG90IG9mIGRldmVsb3Bt ZW50IGdvaW5nIG9uIGluIHRoZSBhcmVhIG9mIFRFRXMgYW5kIEkgc3VzcGVjdCB0aGF0IHdlIHdp bGwgc2VlIGFsbCBzb3J0cyBvZiBkaWZmZXJlbnQgdXNlIGNhc2VzIHNob3dpbmcgdXAgaW4gdGhl IGZ1dHVyZSBhcyB0aGUgdGVjaG5vbG9neSBnZXRzIHVzZWQgaW4gZGlmZmVyZW50IGVudmlyb25t ZW50cy4NCg0KDQoNCkFncmVlIHdpdGggSGFubmVzLg0KDQoNCg0KW1RSXSBPa2F5Lg0KDQoNCg0K aykgVGhlIGJlbG93IGxpbmUgaXMgbm90IGNsZWFyIHRvIG1lIChwbGVhc2UgZWxhYm9yYXRlKToN Cg0KQ29uc2VxdWVudGx5LCBhIFRBTSBnZW5lcmFsbHkgY29tbXVuaWNhdGVzIHdpdGggYW4gVW50 cnVzdGVkIEFwcGxpY2F0aW9uIGFib3V0IGhvdyBpdCBnZXRzIG1lc3NhZ2VzIHRoYXQgb3JpZ2lu YXRlIGZyb20gYSBURUUgaW5zaWRlIGEgZGV2aWNlLg0KDQoNCg0KW0hhbm5lc10gVGhlIGtleSBw b2ludCBvZiB0aGF0IHBhcmFncmFwaCBpcyB0aGF0IHRvZGF5IFRFRXMgZG8gbm90IGNvbW11bmlj YXRlIHdpdGggdGhlIG91dHNpZGUgd29ybGQgYnV0IHJlcXVpcmUgdGhlIGNvb3BlcmF0aW9uIHdp dGggc29tZXRoaW5nIG9uIHRoZSBSRUUgc2lkZS4NCg0KDQoNClRoYXQgd2hvbGUgcGFyYWdyYXBo IGlzIGNvbmZ1c2luZ2x5IHdvcmRlZCwgYW5kIEkgY3VycmVudGx5IHBsYW4gdG8gcmV3cml0ZSBp dCBiYXNlZCBvbiBteSBtYXJrZWQgdXAgaGFyZCBjb3B5IOKYug0KDQoNCg0KW1RSXSBPa2F5Lg0K DQoNCg0KbCkgV2hhdCBpcyB0aGUgdXNlIGNhc2UgZm9yIG9uZSBUQSBhbmQgbXVsdGlwbGUgU1Ag Pw0KDQoNCg0KW0hhbm5lc10gSSBhbSBub3Qgc3VyZS4uIEkgbGV0IE1pbmcsIERhdmVXLCBvciBE YXZlVCByZXNwb25kLg0KDQoNCg0KTm8gaWRlYSwgSeKAmWQgcHJvcG9zZSBkZWxldGluZyB0aGF0 IHNlY3Rpb24uICAgSSB3YXMgY29uZnVzZWQgYnkgaXQgYXMgd2VsbC4NCg0KDQoNCltNUF0gQSBU QSBzb2Z0d2FyZSBhdXRob3IgY2FuIGxpY2Vuc2UgdGhlIFRBIHRvIG11bHRpcGxlICJidXllcnMi IHdobyBpbnN0YWxscyB0byB0aGVpciBvd24gdXNlciBkZXZpY2VzIHZpYSB0aGVpciBvd24gVEFN IHByb3ZpZGVycy4gVGhlIGJ1eWVycyBhcmUgU1BzIGluIHRoZSBvcmlnaW5hbCB1c2UgY2FzZSBj b250ZXh0LiBBIFRBIGRldmVsb3BlciBkb2Vzbid0IG5lY2Vzc2FyaWx5IGRpc3RyaWJ1dGUgdGhl IFRBLiBXZSBoYXZlIGNoYW5nZWQgdGhlIG1lYW5pbmcgb2YgU1AgdG8gYmUgaW50ZXJjaGFuZ2Vh YmxlIHdpdGggYW4gIkFwcCBEZXZlbG9wZXIiIGFsb25nIHdpdGggV0cgZGlzY3Vzc2lvbiwgd2hp Y2ggdHJlYXRzIHRoZSBUQSBhdXRob3JpemVyIChTUCkgdG8gZGV2aWNlcyBhcyB0aGUgb3duZXIg b2YgdGhlIFRBLg0KDQpBIFNQIG1heSBwcm92aWRlIGl0cyBvd24gIlRBIHBlcnNvbmFsaXphdGlv biBkYXRhIi4gRGlmZmVyZW50IFNQcyBtYXkgcHJvdmlkZSBkaWZmZXJlbnQgZGF0YS4gVGhlcmUg bmVlZHMgYSB3YXkgdG8gYWRkcmVzcyB0aGUgY2FzZSB3aGVuIHRoZSBzYW1lIFRBIGlzIGluc3Rh bGxlZCB0byBhIGRldmljZSBieSBtdWx0aXBsZSBwcm92aWRlcnMuICBUbyB0aGlzIGVuZCwgdGhl IHByb3Bvc2FsIHdhcyB0byBoYXZlIGRpZmZlcmVudCAiaWRlbnRpZmllcnMiIGZvciB0aGUgVEEg dG8gbXVsdGlwbGUgU1BzIHNvIHRoYXQgdGhleSBkb24ndCBoYXZlIHRvIGJlIG92ZXJ3cml0dGVu LiBBIERldmljZSBBZG1pbmlzdHJhdG9yIG1heSBkZWNpZGUgd2hpY2ggVEFNIGFuZCBUQSBpdCBh bGxvd3MgdG8gaW5zdGFsbCB0byBkZXZpY2VzLg0KDQpUaGlzIGlzIGNlcnRhaW5seSBhIGNvbXBs ZXggY2FzZSwgYW5kIG5vdCBleHBlY3RlZCB0byBiZSBjb21tb24gaW4gcHJhY3RpY2UuDQoNCltU UjJdIElmIGl0IG5vdCBhIGNvbW1vbiBwcmFjdGljZSB0b2RheSwgc3VnZ2VzdCB0byByZW1vdmUg aXQgb3IgaWYgeW91IHRoaW5rIGl0IHdpbGwgYmUgdXNlZnVsIGluIGZ1dHVyZSwgcGxlYXNlIGFk ZCB0aGUgYWJvdmUgZXhwbGFuYXRpb24gb2YgVEEgd2l0aCBkaWZmZXJlbnQg4oCYaWRlbnRpZmll cnPigJkgZnJvbSBtdWx0aXBsZSBTUHMgb24gdGhlIGRldmljZS4NCg0KRG8geW91IGZlZWwgdGhh dCB3ZSBjYW4gZGlzYWxsb3cgc3VjaCBhIGNhc2Ugd2hlcmUgYSBUQSBhdXRob3IgYWx3YXlzIGRp cmVjdGx5IHdvcmtzIHdpdGggYSBUQU0gc2VydmljZSB0byBkaXN0cmlidXRlIHRoZSBUQT8gSSBm ZWVsIHRoYXQgdGhpcyBsaWNlbnNlZCBUQSBjYXNlIG1heSBzdGlsbCBoYXZlIGEgcGxhY2UgaGVy ZS4NCg0KW1RSMl0gWWVzLCBpdCBkZXZpYXRlcyBmcm9tIHRoZSByb2xlIG9mIFRBTSB0byBtYW5h Z2UgVEFzIG9uIGJlaGFsZiBvZiBTUCAoYXMgcGVyIHRoZSBkZWZpbml0aW9uIGluIFNlY3Rpb24g NC4xKS4NCg0KDQpbVFJdIFdvcmtzIGZvciBtZS4NCg0KDQoNCm0pIHdoYXQgaXMgdGhlIHVzZSBj YXNlIGZvciBrZWVwaW5nIHRoZSBUQSBiaW5hcnkgc2VjcmV0IGZyb20gdGhlIFRBTSA/DQoNCg0K DQpbSGFubmVzXSBpdCBpcyBtb3JlIGFuZCBtb3JlIGNvbW1vbiB0b2RheSB0byBwcm90ZWN0IGJp bmFyaWVzIGZyb20gaW5zcGVjdGlvbiBiZWNhdXNlIHRoaXMgZ2l2ZXMgYXR0YWNrZXJzIGEgbG90 IG9mIGluZm9ybWF0aW9uLiBJZiB5b3UgZG9u4oCZdCB3YW50IHRvIHVzZSBpdCBhbmQgb25seSBz aWduIHRoZSBiaW5hcmllcyB0aGF04oCZcyBmaW5lIHRvby4gQnV0IHRoZSBvcHRpb24gaXMgdGhl cmUgZm9yIHlvdSB0byBwcm90ZWN0IHRoZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlIGJpbmFyeS4N Cg0KDQoNCkkgYmVsaWV2ZSB0aGUgdXNlIGNhc2UgaXMgd2hlcmUgdGhlIGFwcCBkZXZlbG9wZXIg Y29uc2lkZXJzIHRoZSBUQSBiaW5hcnkgaXRzZWxmIHRvIGJlIHNlY3JldCAoZS5nLiwgaW50ZWxs ZWN0dWFsIHByb3BlcnR5IHdvcnRoIHByb3RlY3RpbmcpLCBidXQgd2FudHMgdG8gYWxsb3cgaXQg dG8gYmUgZGlzdHJpYnV0ZWQgdGhyb3VnaCBhIFRBTSB0aGF0IGlzIHJ1biBieSBhbm90aGVyIG9y Z2FuaXphdGlvbiwgb25lIHdpdGggbW9yZSBob3N0aW5nIGNhcGFjaXR5LiAgIFRodXMgdGhlIGRl dmVsb3BlciBwdXRzIGFuIGVuY3J5cHRlZCBiaW5hcnkgaW4gdGhhdCBUQU0sIGFuZCB0aGVuIHJ1 bnMgdGhlaXIgb3duIGxpZ2h0ZXIgd2VpZ2h0IFRBTSB0aGF0IGp1c3QgaGFuZHMgb3V0IGRlY3J5 cHRpb24ga2V5cyB3aGljaCBkb2VzbuKAmXQgbmVlZCBuZWFybHkgYXMgbXVjaCBtdWNoIGNhcGFj aXR5L2JhbmR3aWR0aC4NCg0KDQoNCltUUl0gR290IGl0IGJ1dCBpdCBhbHNvIGFsbG93cyB0aGUg cG9zc2liaWxpdHkgb2YgcHVibGlzaGluZyBtYWxpY2lvdXMgYXBwcyB0aGUgVEFNL1NQIG1heSBu b3QgYmUgYWJsZSB0byB2YWxpZGF0ZSAoRm9yIGluc3RhbmNlIEFwcGxlIGhhcyBhIHN0cmljdCBy ZXZpZXcgcHJvY2VzcyBvZiBhcHBzIGJlZm9yZSBwdWJsaXNoaW5nIG9uIHRoZSBpT1MgYXBwIHN0 b3JlKS4gRW5jcnlwdGluZyB0aGUgYmluYXJpZXMgZnJvbSBpbnNwZWN0aW9uIGJ5IGF0dGFja2Vy IGlzIHJlcXVpcmVkIGJ1dCBUQU0vU1AgYXJlIG5vdCBuZWNlc3NhcmlseSB0aGUgYXR0YWNrZXJz Lg0KDQpbTVBdIEkgdGhpbmsgdGhpcyByaXNrIGNhbiBiZSBzb21lIGNvbnRyYWN0IGJldHdlZW4g dGhlIFRBTSBhbmQgdGhlIFRBIHByb3ZpZGVyIHRvIG1hbmFnZS4gV2hlbiBhIFRBTSBkb2Vzbid0 IHdhbnQgdG8gcmlzayBpdHMgcmVwdXRhdGlvbiB0byBkaXN0cmlidXRlIG1hbHdhcmUsIGl0IG1h eSBkZW1hbmQgdG8gaW5zcGVjdCBiaW5hcnkgdGhhdCBhIFRBIHByb3ZpZGVyIGdpdmVzLiBBZ3Jl ZSB3aXRoIHlvdSB0aGF0IGEgVEFNIG1vc3QgcHJvYmFibHkgaGF2ZSB0aGUgb3JpZ2luYWwgVEEg YmluYXJ5IGFjY2Vzcywgd2hvIGFyZSBub3QgdHJlYXRlZCBhcyBhbiBhdHRhY2tlciBieSB0aGUg VEEgZGV2ZWxvcGVyLg0KDQpbVFIyXSBZb3Ugc2hvdWxkIGRpc2N1c3MgdGhlIGFib3ZlIHBvaW50 IGluIHRoZSBkb2N1bWVudC4gUGxlYXNlIHNlZSBodHRwczovL3RoZW5leHR3ZWIuY29tL2FwcHMv MjAyMC8wMS8xMC9nb29nbGUtam9rZXItbWFsd2FyZS1wbGF5LXN0b3JlLyB0byB1bmRlcnN0YW5k IGhvdyBtYWxpY2lvdXMgYXBwcyBhcmUgbWFraW5nIHRoZWlyIHdheSBpbnRvIEdvb2dsZSBwbGF5 IHN0b3JlLiBUaGVzZSBhcHBzIHN0YXJ0IHdpdGggY2xlYW4gdmVyc2lvbnMsIGdyb3cgdXNlciBi YXNlIGFuZCBsYXRlciBpbnRyb2R1Y2UgbWFsaWNpb3VzIGNvZGUgdGhyb3VnaCB1cGRhdGVzLg0K DQpOb3RlIHRoYXQgdGhlIG1vcmUgY29tbW9uIGNhc2Ugb2YgVEEgYmluYXJ5IGVuY3J5cHRpb24g Y29tbW9uIGlzIGZvciB0aGUgVEFNIHRvIGVuY3J5cHQgdGhlIFRBIGJpbmFyeSB0byBwcmV2ZW50 IGFueSBtYW4taW4tdGhlLW1pZGRsZSBmcm9tIGluc3BlY3RpbmcgdGhlIGJpbmFyeS4gQXBwIERl dmVsb3BlciBlbmNyeXB0ZWQgVEEgYmluYXJ5IGhhcyBhIGRlY3J5cHRpb24ga2V5IGRpc3RyaWJ1 dGlvbiBjaGFsbGVuZ2UgdG8gYSBkZXZpY2UuIFRoZSBzZXBhcmF0ZSBUQU0gd2FzIGRldmlzZWQg Zm9yIHRoaXMgcHVycG9zZSwgYnV0IHRoYXQgd2FzIGxhcmdlbHkgdXNlZCBmb3IgInBlcnNvbmFs aXphdGlvbiBkYXRhIiBzdXBwb3J0IGNhc2UuDQoNCg0KDQoNCm4pIFdlIGFsbG93IGEgd2F5IGZv ciBhbiBVbnRydXN0ZWQgQXBwbGljYXRpb24gdG8gY2hlY2sgdGhlIHRydXN0d29ydGhpbmVzcyBv ZiBhIFRBLg0KDQoNCg0KQ29tbWVudD4gWW91IG1heSB3YW50IHRvIHJlLXBocmFzZSB0aGUgYWJv dmUgbGluZSwgYW5kIHJlbW92ZSAid2UiLg0KDQoNCg0KW0hhbm5lc10gSSB0aGluayB3ZSBzaG91 bGQgZGVsZXRlIHRoaXMgcGFyYWdyYXBoOg0KDQrigJwNCg0KICAgV2UgYWxsb3cgYSB3YXkgZm9y IGFuIFVudHJ1c3RlZCBBcHBsaWNhdGlvbiB0byBjaGVjayB0aGUNCg0KICAgdHJ1c3R3b3J0aGlu ZXNzIG9mIGEgVEEuICBBIFRFRVAgQnJva2VyIGhhcyBhIGZ1bmN0aW9uIHRvIGFsbG93IGFuDQoN CiAgIGFwcGxpY2F0aW9uIHRvIHF1ZXJ5IHRoZSBpbmZvcm1hdGlvbiBhYm91dCBhIFRBLg0KDQri gJwNCg0KDQoNCkFncmVlZCBpdCBzaG91bGQgYmUgZGVsZXRlZC4gIFRoaXMgd2FzIHRoZSBzZWNv bmQgcG9pbnQgb2YgaXNzdWUgIzExNiB0aGF0IEkgZmlsZWQuDQoNCg0KDQpbVFJdIE9rYXkuDQoN Cg0KDQpbTVBdIEFncmVlZCB0b28uIEl0IHdhcyBvcmlnaW5hbGx5IHNldCB0aGVyZSBmb3IgbG9j YWwgcXVlcnkgd2l0aG91dCBjb250YWN0aW5nIGEgcmVtb3RlIFRBTSB0byBjaGVjayBhIFRBLg0K DQoNCm8pIEEgbm90aWZpY2F0aW9uIHRoYXQgYW4gaW5jb21pbmcgVEVFUCBzZXNzaW9uIGlzIGJl aW5nIHJlcXVlc3RlZCBieSBhIFRFRVAgQWdlbnQuDQoNCg0KDQpDb21tZW50PiBXaGF0IHlvdSBt ZWFudCBieSAiaW5jb21pbmcgVEVFUCBzZXNzaW9uIiA/DQoNCg0KDQpbSGFubmVzXSBEYXZlIHNo b3VsZCByZXNwb25kIHRvIHRoaXMgb25lIGJlY2F1c2UgaXQgcmVsYXRlcyB0byB0aGUgSFRUUCB0 cmFuc3BvcnQsIEkgYmVsaWV2ZS4NCg0KDQoNClRoZSBURUVQIHByb3RvY29sIHJlcXVpcmVzIHRo ZSBhZ2VudCB0byBjb25uZWN0IHRvIHRoZSBUQU0uICAgVGhpcyBpcyBhIG5vdGlmaWNhdGlvbiBh Ym91dCB0aGUgaW5pdGlhbCBjb25uZWN0aW9uLg0KDQpTZWUgdGhlIHRyYW5zcG9ydCBzcGVjIGZv ciBtb3JlIGRldGFpbHMuDQoNCg0KDQpbVFJdIFRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24u DQoNCg0KDQoNCg0KcCkgSG93IGRvZXMgdGhlIFRFRVAgYnJva2VyIGNvbW11bmljYXRlIHdpdGgg dGhlIFRFRVAgYWdlbnQgPw0KDQoNCg0KW0hhbm5lc10gVmlhIGFuIEFQSSwgZm9yIGV4YW1wbGUg dGhlIEdQIFRFRVAgQ2xpZW50IEFQSS4NCg0KDQoNClJpZ2h0LCBpbXBsZW1lbnRhdGlvbi1zcGVj aWZpYyBkZXRhaWwuDQoNCg0KDQpbVFJdIE9rYXkuDQoNCg0KDQpxKSBTZWN0aW9uIDUuMyBzYXlz IHRoZSBhcmNoaXRlY3R1cmUgdXNlcyBQS0kgYnV0IFNlY3Rpb24gOS4xIGRpc2N1c3NlcyBzZWxm LXNpZ25lZCBjZXJ0aWZpY2F0ZXMuIFBsZWFzZSBmaXguDQoNCg0KDQpbSGFubmVzXSBXZSBuZWVk IHRvIGNsYXJpZnkgdGhlIHN0YXRlbWVudCBhYm91dCB0aGUgc2VsZi1zaWduZWQgVEEgYmluYXJp ZXMuDQoNCg0KDQpTdXJlLiAgRmlndXJlIDQgdGFsa3MgYWJvdXQgbXVsdGlwbGUgY2VydGlmaWNh dGVzLiAgIDUuMyBpcyBhIGdlbmVyYWwgc3RhdGVtZW50IGFib3V0IG11bHRpcGxlIHR5cGVzLg0K DQo5LjEgaXMgYWJvdXQgb25lIHNwZWNpZmljIHR5cGUgb2YgY2VydCB0aGF0IG1heSBvciBtYXkg bm90IGhhdmUgYSBQS0kuDQoNClNvIHRoZXkgYXJlIG5vdCBpbiBjb250cmFkaWN0aW9uIGJ1dCB5 ZXMgY2xhcmlmaWNhdGlvbiB3b3VsZCBiZSBnb29kLg0KDQoNCg0KW1RSXSBXaGF0IGlzIG5lZWQg Zm9yIHNlbGYtc2lnbmVkIGNlcnRpZmljYXRlcyB3aGVuIGNvZGUgc2lnbmluZyBjZXJ0aWZpY2F0 ZXMgYnkgQ0EgYXJlIHVzZWQgdG9kYXkgPw0KDQoNCg0KcikgSW4gRmlndXJlIDQsIGZvciB0aGUg cHVycG9zZSBvZiAiQ29kZSBzaWduaW5nIiBteSB1bmRlcnN0YW5kaW5nIGlzIHRoZSBsb2NhdGlv biBvZiBjb3JyZXNwb25kaW5nIENBIGNlcnRzIGlzIGJvdGggVEVFIGFuZCBUQU0uDQoNCg0KDQpb SGFubmVzXSBJIGJlbGlldmUgaXQgd291bGQgYmUgdXNlZnVsIHRvIGFsc28gc3RvcmUgdGhlIENB IGNlcnQgdGhhdCBpcyB1c2VkIGZvciBjb2RlIHNpZ25pbmcgYXQgdGhlIFRBTSBiZWNhdXNlIHRo ZW4gaXQgY2FuIHZlcmlmeSB0aGUgc2lnbmVkIFRBcy4NCg0KDQoNCkkgZG9u4oCZdCBiZWxpZXZl IHRoZXJlIGlzIGFueSBzdWNoIHJlcXVpcmVtZW50IG9uIGEgVEFNLiAgIEl0IG1pZ2h0IGJlIOKA nHVzZWZ1bOKAnSBidXQgaXMgbm90IHJlcXVpcmVkIGluIG15IHZpZXcuDQoNCg0KDQpbVFJdIHdo eSBkbyB5b3UgdGhpbmsgdmVyaWZpY2F0aW9uIGluIFRBTSBpcyBub3QgcmVxdWlyZWQgPw0KDQoN Cg0KW01QXSAgVEEgc2lnbmF0dXJlIHZlcmlmaWNhdGlvbiBtdXN0IGJlIHZlcmlmaWVkLiBDdXJy ZW50bHkgYSBURUUgd2lsbCBjaGVjayB0aGlzIGNvZGUgc2lnbmluZywgYW5kIHRoZSBDQSBjZXJ0 aWZpY2F0ZSB3aWxsIGJlIGluIFRFRS4gU2VlIEZpZ3VyZSA0IGluIHRoZSBkb2MuDQoNCiJDb2Rl IFNpZ25pbmcgICAgICAgICAgMSBwZXIgU1AgICAgICAgVEEgYmluYXJ5ICAgICAgICAgIFRFRSIN Ck5vdGUgdGhlIGFib3ZlICJUQSBiaW5hcnkgZW5jcnlwdGlvbiIgZGlzY3Vzc2lvbi4gSWYgYSBU QSBpcyBnaXZlbiB0byBhIFRBTSBpbiBhbiBlbmNyeXB0ZWQgZm9ybSwgc3VjaCBhIHNpZ25hdHVy ZSBjaGVjayBpc24ndCBmZWFzaWJsZS4gQnV0IHdlIGNhbiBhc3N1bWUgdGhhdCBUQU0gcHJvdmlk ZXIgYWx3YXlzIHZldCBUQSBiaW5hcmllcyB0aGF0IGl0IGRpc3RyaWJ1dGVzIGZvciBpdHMgc2Vy dmljZSByZXB1dGF0aW9uIHByb3RlY3Rpb24uDQoNCk5vdGUgdGhhdCB0aGVyZSBpcyBhbHNvIHRo ZSBvdGhlciBUQSBkZWxpdmVyeSBtb2RlIHdoZXJlIGEgVEEncyBiaW5hcnkgaXMgYnVuZGxlZCBp bnNpZGUgYW4gVW50cnVzdGVkIEFwcGxpY2F0aW9uIGFzIGJpbmFyeSBkYXRhLiBJbiB0aGlzIGNh c2UsIHRoZSBiaW5hcnkgaXNuJ3Qgc2VudCB0byBUQU0gZm9yIGRpc3RyaWJ1dGlvbi4NCg0KVGhl cmUgaXMgYWxzbyB0aGUgb3RoZXIgY2FzZTogbWFueSBTUHMgLyBUQSBBcHAgRGV2ZWxvcGVycyB1 c2UgdGhlIHNhbWUgZXh0cmVtZWx5IHBvcHVsYXIgVEFNIHNlcnZpY2UuIERldmljZSBtYW51ZmFj dHVyZXJzIG1heSB3YW50IHRvIGxpbWl0IHRvIGFjY2VwdCBvbmx5IGEgc2V0IG9mIFRBIHByb3Zp ZGVycyBieSB1c2luZyB0aGUgY29kZSBzaWduaW5nIENBIHRydXN0IGxpc3QuIFRoZSBhcmNoaXRl Y3R1cmUgYWxsb3dzIHN1Y2ggc3VwcG9ydCB3aXRoIHRoZSBjb2Rpbmcgc2lnbmluZyB0cnVzdCBj aGVjayBpbiBURUUuDQoNCltUUjJdIEdvdCBpdCwgVGhhbmtzLg0KDQpDaGVlcnMsDQotVGlydQ0K DQoNCklmIHdlIGluZGVlZCBiZWxpZXZlIHRoZSB0ZXh0IGluIFNlY3Rpb24gOS4xIGlzIGNvcnJl Y3QgdGhlbiB0aGF0IGNvZGUgc2lnbmluZyBDQSBjZXJ0IGFsc28gbmVlZHMgdG8gYmUgbWFkZSBh dmFpbGFibGUgdG8gdGhlIFRFRVAgQnJva2VyIGFuZCBwb3RlbnRpYWxseSBldmVuIHRvIHRoZSB1 bnRydXN0ZWQgYXBwLg0KDQoNCg0KSSBkb27igJl0IGJlbGlldmUgdGhlIHRleHQgaW4gOS4xIGlz IGNvcnJlY3QuDQoNCg0KW01QXSBTZWUgYWJvdmUgY29tbWVudC4NCg0KW1RSXSBZb3UgbWF5IHdh bnQgdG8gcmFpc2UgYW4gaXNzdWUgaW4gZ2l0aHViIHRvIGNvcnJlY3QgdGhlIHRleHQuDQoNCg0K DQpzKUkgaGF2ZSBzZWVuIHNldmVyYWwgbWFsaWNpb3VzIGFwcHMgaW4gQXBwIHN0b3JlIGluIGJv dGggQW5kcm9pZCBhbmQgaU9TLCBpdCBpcyBwb3NzaWJsZSBmb3IgYW4gbWFsaWNpb3VzIEFwcCBk ZXZlbG9wZXIgdG8gcHVibGlzaCBib3RoIG1hbGljaW91cyB1bnRydXN0ZWQgYXBwbGljYXRpb25z DQoNCiAgIGFuZCBtYWxpY2lvdXMgdHJ1c3RlZCBhcHBsaWNhdGlvbnMuICBJIGRvbid0IHRoaW5r IHRoZSBURUVQIGFyY2hpdGVjdHVyZSBwcmV2ZW50cyB0aGlzIGF0dGFjayBhbmQgaXQgaXMgdGhl IHJlc3BvbnNpYmlsaXR5IG9mIFRBTSBhbmQgQXBwIHN0b3JlIHRvIHJlbW92ZSBzdWNoIGFwcHMN Cg0KICAgIChzZWUgaHR0cHM6Ly9hbmRyb2lkLWRldmVsb3BlcnMuZ29vZ2xlYmxvZy5jb20vMjAx OC8wMS9ob3ctd2UtZm91Z2h0LWJhZC1hcHBzLWFuZC1tYWxpY2lvdXMuaHRtbDxodHRwczovL2Ns aWNrdGltZS5zeW1hbnRlYy5jb20vM1dvVFVRaXFuOFM4RUw1VVlGVTdqaHc3VmM/dT1odHRwcyUz QSUyRiUyRm5hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tJTJGJTNGdXJsJTNE aHR0cHMlMjUzQSUyNTJGJTI1MkZhbmRyb2lkLWRldmVsb3BlcnMuZ29vZ2xlYmxvZy5jb20lMjUy RjIwMTglMjUyRjAxJTI1MkZob3ctd2UtZm91Z2h0LWJhZC1hcHBzLWFuZC1tYWxpY2lvdXMuaHRt bCUyNmRhdGElM0QwMiUyNTdDMDElMjU3Q2R0aGFsZXIlMjU0MG1pY3Jvc29mdC5jb20lMjU3Q2Jj ZjNiMmM1Zjk1YjRjNGMzMWZhMDhkNzkzNTNlY2U1JTI1N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyUyNTdDMSUyNTdDMCUyNTdDNjM3MTM5ODYxOTA4OTY5NDgxJTI2c2RhdGElM0Rn TnYwdDczSUZVcVptZG5YaldtcGI5YkF5b1lHZmN6TTZvUmU2NlFsYW9nJTI1M0QlMjZyZXNlcnZl ZCUzRDA+KQ0KDQoNCg0KW0hhbm5lc10gWWVzLCBpdCB3b3VsZCBiZSB0aGUgcmVzcG9uc2liaWxp dHkgb2YgdGhlIFRBTSwgdGhlIGRldmljZSBtYW51ZmFjdHVyZXIgYW5kIHRoZSBTUCAvIGRldmVs b3BlciB0byBlbnN1cmUgdGhhdCB0aGV5IGRvIG5vdCBkaXN0cmlidXRlIG1hbGljaW91cyBUQXMu DQoNCg0KDQpJdOKAmXMgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBUQU0gdG8gbm90IGluc3Rh bGwgbWFsaWNpb3VzIHRydXN0ZWQgYXBwcywgb25seSBhdXRob3JpemVkIG9uZXMuDQoNCg0KDQpJ IGRvbuKAmXQgdGhpbmsgaXTigJlzIGNvcnJlY3QgdG8gc2F5IGl04oCZcyB0aGUgcmVzcG9uc2li aWxpdHkgb2YgdGhlIFRBTSB0byDigJxyZW1vdmXigJ0gbWFsaWNpb3VzIHRydXN0ZWQgYXBwcywg c2luY2UgaXQgc2hvdWxkbuKAmXQgaGF2ZSBpbnN0YWxsZWQgaXQgaW4gdGhlIGZpcnN0IHBsYWNl Lg0KDQpUaGUgb25seSBjYXNlIHdoZXJlIOKAnHJlbW92YWzigJ0gbWlnaHQgbWFrZSBzZW5zZSBp cyBpZiB0aGUgVEFNIHByZXZpb3VzbHkgYXV0aG9yaXplZCBhIHRydXN0ZWQgYXBwLCBhbmQgbGF0 ZXIgY2hhbmdlZCBpdHMgcG9saWN5IHRoYXQgc3VjaCBUQSBpcyBubyBsb25nZXIgYXV0aG9yaXpl ZCAoZS5nLiwgYmVjYXVzZSBpdCB3YXMgZGV0ZXJtaW5lZCB0byBiZSBidWdneSBvciBtYWxpY2lv dXMgb3Igd2hhdGV2ZXIgZWxzZSkuDQoNCg0KDQpbVFJdIFlvdSBtYXkgd2FudCB0byBkaXNjdXNz IHRoZSBhYm92ZSBjYXNlIGluIHRoZSBkb2N1bWVudC4gIElmIHRoZSB0cnVzdGVkIGFwcCBpcyBy ZW1vdmVkIGJ5IFRBTSBiZWNhdXNlIGl0IGlzIG1hbGljaW91cywgc29tZSBub3RpZmljYXRpb24g dG8gdGhlIHVzZXIgd291bGQgYmUgaGVscGZ1bCB0byByZW1vdmUgdGhlIGFzc29jaWF0ZWQgdW50 cnVzdGVkIGFwcGxpY2F0aW9uIGluIHRoZSBSRUUuDQoNCg0KW01QXSBHb29kIHN1Z2dlc3Rpb24u IFdlIG1heSB0b3VjaCBvbiB0aGlzIHBvaW50IGluIFNlY3VyaXR5IENvbnNpZGVyYXRpb24gc2Vj dGlvbiB0b28uDQoNCi1UaXJ1DQoNCg0KDQoNCg0KQ2lhbw0KDQpIYW5uZXMNCg0KDQoNCkNoZWVy cywNCg0KLVRpcnUNCg0KDQpGcm9tOiBEYXZlIFRoYWxlciA8ZHRoYWxlckBtaWNyb3NvZnQuY29t PG1haWx0bzpkdGhhbGVyQG1pY3Jvc29mdC5jb20+Pg0KU2VudDogVHVlc2RheSwgSmFudWFyeSA3 LCAyMDIwIDg6NDQgQU0NClRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5IDxUaXJ1bWFsZXN3 YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPG1haWx0bzpUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBN Y0FmZWUuY29tPj47IHRlZXBAaWV0Zi5vcmc8bWFpbHRvOnRlZXBAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSRTogV29ya2luZyBHcm91cCBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtdGVlcC1hcmNoaXRl Y3R1cmUNCg0KDQpDQVVUSU9OOiBFeHRlcm5hbCBlbWFpbC4gRG8gbm90IGNsaWNrIGxpbmtzIG9y IG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25v dyB0aGUgY29udGVudCBpcyBzYWZlLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KSSBvcGVuZWQgb25lIHB1bGwgcmVxdWVzdCBmb3IgZWRpdG9yaWFsIGlzc3VlcyAoaHR0cHM6 Ly9naXRodWIuY29tL2lldGYtdGVlcC9hcmNoaXRlY3R1cmUvcHVsbC8xMDk8aHR0cHM6Ly9jbGlj a3RpbWUuc3ltYW50ZWMuY29tLzM1MXU1OVFMdGFQVDgxVE1UQXZ1bnFCN1ZjP3U9aHR0cHMlM0El MkYlMkZuYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbSUyRiUzRnVybCUzRGh0 dHBzJTI1M0ElMjUyRiUyNTJGZ2l0aHViLmNvbSUyNTJGaWV0Zi10ZWVwJTI1MkZhcmNoaXRlY3R1 cmUlMjUyRnB1bGwlMjUyRjEwOSUyNmRhdGElM0QwMiUyNTdDMDElMjU3Q2R0aGFsZXIlMjU0MG1p Y3Jvc29mdC5jb20lMjU3Q2JjZjNiMmM1Zjk1YjRjNGMzMWZhMDhkNzkzNTNlY2U1JTI1N0M3MmY5 ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyUyNTdDMSUyNTdDMCUyNTdDNjM3MTM5ODYxOTA4 OTY5NDgxJTI2c2RhdGElM0RTMzZTTHclMjUyRjJUN3lLMjEwYXd3emJwV1RFMExBTjlyMVdGdGtF NXFHJTI1MkJmbDAlMjUzRCUyNnJlc2VydmVkJTNEMD4pLA0KYW5kIGZpbGVkIHNldmVuIG90aGVy IGlzc3VlcyBsaXN0ZWQgYXQgaHR0cHM6Ly9naXRodWIuLmNvbS9pZXRmLXRlZXAvYXJjaGl0ZWN0 dXJlL2lzc3VlczxodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1RyakJtV2RFZmlTN29V VnBtaTNXaWY3VmM/dT1odHRwcyUzQSUyRiUyRm5hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tJTJGJTNGdXJsJTNEaHR0cHMlMjUzQSUyNTJGJTI1MkZnaXRodWIuY29tJTI1MkZp ZXRmLXRlZXAlMjUyRmFyY2hpdGVjdHVyZSUyNTJGaXNzdWVzJTI2ZGF0YSUzRDAyJTI1N0MwMSUy NTdDZHRoYWxlciUyNTQwbWljcm9zb2Z0LmNvbSUyNTdDYmNmM2IyYzVmOTViNGM0YzMxZmEwOGQ3 OTM1M2VjZTUlMjU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTI1N0MxJTI1N0Mw JTI1N0M2MzcxMzk4NjE5MDg5Nzk0NDElMjZzZGF0YSUzRDVhcXhQUnQwbWlBZTVEc29lbmprVG4y cWJKbFZXVGVjaUx0dzlTQlZuMUUlMjUzRCUyNnJlc2VydmVkJTNEMD4NCg0KMTEwKSBTZXJ2aWNl IFByb3ZpZGVyIGRpc2N1c3Npb24gaXMgY29uZnVzaW5nPGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFu dGVjLmNvbS8zOWNNRFVzTkd2U3ZhU1JKUDJDUWlBNTdWYz91PWh0dHBzJTNBJTJGJTJGbmFtMDYu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20lMkYlM0Z1cmwlM0RodHRwcyUyNTNBJTI1 MkYlMjUyRmdpdGh1Yi5jb20lMjUyRmlldGYtdGVlcCUyNTJGYXJjaGl0ZWN0dXJlJTI1MkZpc3N1 ZXMlMjUyRjExMCUyNmRhdGElM0QwMiUyNTdDMDElMjU3Q2R0aGFsZXIlMjU0MG1pY3Jvc29mdC5j b20lMjU3Q2JjZjNiMmM1Zjk1YjRjNGMzMWZhMDhkNzkzNTNlY2U1JTI1N0M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyUyNTdDMSUyNTdDMCUyNTdDNjM3MTM5ODYxOTA4OTc5NDQxJTI2 c2RhdGElM0RLUE5oblhWNDNlUDhabWRTcXYzVmtiY2olMjUyRlBVbHQ1RzNxWVVnV1BPQlQlMjUy RjAlMjUzRCUyNnJlc2VydmVkJTNEMD4NCjExMSkgVGVybWlub2xvZ3kgc2VjdGlvbiBpcyBub3Qg Y29uc2lzdGVudGx5IG9yZGVyZWQ8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNWQWl1 YlRQQm04TnU3SzZqZXlLNnlDN1ZjP3U9aHR0cHMlM0ElMkYlMkZuYW0wNi5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbSUyRiUzRnVybCUzRGh0dHBzJTI1M0ElMjUyRiUyNTJGZ2l0aHVi LmNvbSUyNTJGaWV0Zi10ZWVwJTI1MkZhcmNoaXRlY3R1cmUlMjUyRmlzc3VlcyUyNTJGMTExJTI2 ZGF0YSUzRDAyJTI1N0MwMSUyNTdDZHRoYWxlciUyNTQwbWljcm9zb2Z0LmNvbSUyNTdDYmNmM2Iy YzVmOTViNGM0YzMxZmEwOGQ3OTM1M2VjZTUlMjU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTI1N0MxJTI1N0MwJTI1N0M2MzcxMzk4NjE5MDg5Nzk0NDElMjZzZGF0YSUzRFklMjUy RndoUjJxekVjODZ4WWJvWXVlSWx3STdqR1VsSVVuVXAwM3FRJTI1MkZjbEFNcyUyNTNEJTI2cmVz ZXJ2ZWQlM0QwPg0KMTEyKSBUZXh0IGFib3V0IGNhcnJpZXJzIGlzIGNvbmZ1c2luZzxodHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vMzVKYnRBa2V5QWd1SktERGJBc3dtNTg3VmM/dT1odHRw cyUzQSUyRiUyRm5hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tJTJGJTNGdXJs JTNEaHR0cHMlMjUzQSUyNTJGJTI1MkZnaXRodWIuY29tJTI1MkZpZXRmLXRlZXAlMjUyRmFyY2hp dGVjdHVyZSUyNTJGaXNzdWVzJTI1MkYxMTIlMjZkYXRhJTNEMDIlMjU3QzAxJTI1N0NkdGhhbGVy JTI1NDBtaWNyb3NvZnQuY29tJTI1N0NiY2YzYjJjNWY5NWI0YzRjMzFmYTA4ZDc5MzUzZWNlNSUy NTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclMjU3QzElMjU3QzAlMjU3QzYzNzEz OTg2MTkwODk4OTM5MyUyNnNkYXRhJTNEUjF4czdadDdHQXQlMjUyQmowY3Y4ckUyNzNDbUc0WSUy NTJGUFNRNWJCMVNYVlZqVVMwJTI1M0QlMjZyZXNlcnZlZCUzRDA+DQoxMTMpIFNlY3Rpb24gNi4y LjMgY29udHJhZGljdHMgc2VjdGlvbiA0LjI8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29t LzNFWFBOS2pNRUFkNkh4OVhTeDVSbkVQN1ZjP3U9aHR0cHMlM0ElMkYlMkZuYW0wNi5zYWZlbGlu a3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbSUyRiUzRnVybCUzRGh0dHBzJTI1M0ElMjUyRiUyNTJG Z2l0aHViLmNvbSUyNTJGaWV0Zi10ZWVwJTI1MkZhcmNoaXRlY3R1cmUlMjUyRmlzc3VlcyUyNTJG MTEzJTI2ZGF0YSUzRDAyJTI1N0MwMSUyNTdDZHRoYWxlciUyNTQwbWljcm9zb2Z0LmNvbSUyNTdD YmNmM2IyYzVmOTViNGM0YzMxZmEwOGQ3OTM1M2VjZTUlMjU3QzcyZjk4OGJmODZmMTQxYWY5MWFi MmQ3Y2QwMTFkYjQ3JTI1N0MxJTI1N0MwJTI1N0M2MzcxMzk4NjE5MDg5ODkzOTMlMjZzZGF0YSUz RGZZdDBuRW9DTlN4dGhGVktxJTI1MkZteHV0eFFncFRoeDhMMVZuM2glMjUyQnhMaEt4RSUyNTNE JTI2cmVzZXJ2ZWQlM0QwPg0KMTE0KSBGaWd1cmUgMyBpcyB0b28gaGFyZCB0byB1bmRlcnN0YW5k PGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zUHY1WkRlUXJhajlLaW96NHhieHRQTjdW Yz91PWh0dHBzJTNBJTJGJTJGbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20l MkYlM0Z1cmwlM0RodHRwcyUyNTNBJTI1MkYlMjUyRmdpdGh1Yi5jb20lMjUyRmlldGYtdGVlcCUy NTJGYXJjaGl0ZWN0dXJlJTI1MkZpc3N1ZXMlMjUyRjExNCUyNmRhdGElM0QwMiUyNTdDMDElMjU3 Q2R0aGFsZXIlMjU0MG1pY3Jvc29mdC5jb20lMjU3Q2JjZjNiMmM1Zjk1YjRjNGMzMWZhMDhkNzkz NTNlY2U1JTI1N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyUyNTdDMSUyNTdDMCUy NTdDNjM3MTM5ODYxOTA4OTg5MzkzJTI2c2RhdGElM0RvJTI1MkY2UlF5MElkRFpRMVo1d0RZZzVX VmFtSjMxU1M2SlV6VThuQ0xCOGtzayUyNTNEJTI2cmVzZXJ2ZWQlM0QwPg0KMTE1KSBSZWZlcmVu Y2UgdG8gSUFOQSBudW1iZXI8aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM1ZDlvVkVD dmJlQmUxU3ZTUEoyQWl4N1ZjP3U9aHR0cHMlM0ElMkYlMkZuYW0wNi5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbSUyRiUzRnVybCUzRGh0dHBzJTI1M0ElMjUyRiUyNTJGZ2l0aHViLmNv bSUyNTJGaWV0Zi10ZWVwJTI1MkZhcmNoaXRlY3R1cmUlMjUyRmlzc3VlcyUyNTJGMTE1JTI2ZGF0 YSUzRDAyJTI1N0MwMSUyNTdDZHRoYWxlciUyNTQwbWljcm9zb2Z0LmNvbSUyNTdDYmNmM2IyYzVm OTViNGM0YzMxZmEwOGQ3OTM1M2VjZTUlMjU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTI1N0MxJTI1N0MwJTI1N0M2MzcxMzk4NjE5MDg5OTkzNTIlMjZzZGF0YSUzRHhQRFJjVUd2 YWljZWplQXh4TE90NUNjJTI1MkJhRkFFcGUxWDFYQm5XOFRPclk4JTI1M0QlMjZyZXNlcnZlZCUz RDA+DQoxMTYpIEluY29ycmVjdC9vYnNvbGV0ZSBzdGF0ZW1lbnRzIGFib3V0IFRFRVAgQnJva2Vy PGh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zOXB1TEd6NjZUejhwcVU3VHJyczZMazdW Yz91PWh0dHBzJTNBJTJGJTJGbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20l MkYlM0Z1cmwlM0RodHRwcyUyNTNBJTI1MkYlMjUyRmdpdGh1Yi5jb20lMjUyRmlldGYtdGVlcCUy NTJGYXJjaGl0ZWN0dXJlJTI1MkZpc3N1ZXMlMjUyRjExNiUyNmRhdGElM0QwMiUyNTdDMDElMjU3 Q2R0aGFsZXIlMjU0MG1pY3Jvc29mdC5jb20lMjU3Q2JjZjNiMmM1Zjk1YjRjNGMzMWZhMDhkNzkz NTNlY2U1JTI1N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyUyNTdDMSUyNTdDMCUy NTdDNjM3MTM5ODYxOTA4OTk5MzUyJTI2c2RhdGElM0RPOGxmSmQwVEFXMWFFVTUweEFPN1UwOVBQ c0N0Y3JDQ1BCRk5IbFBDMnBBJTI1M0QlMjZyZXNlcnZlZCUzRDA+DQoNCkkgaGF2ZSBpZGVhcyBh Ym91dCBob3cgdG8gYWRkcmVzcyBhbGwgb2YgdGhlbSwgYnV0IGlmIG90aGVycyBoYXZlIGNvbW1l bnRzLCBwbGVhc2Ugc3BlYWsgdXAuDQoNClRoZSBwb3NzaWJseSg/KSBjb250ZW50aW91cyBvbmUg bWlnaHQgYmUgdGhhdCBpbiAjMTEwIEkgYW0gcHJvcG9zaW5nIHRvIHVzZSB0aGUgdGVybQ0K4oCc QXBwIERldmVsb3BlcuKAnSB0aHJvdWdob3V0LCBpbnN0ZWFkIG9mIHVzaW5nIOKAnFNlcnZpY2Ug UHJvdmlkZXLigJ0gaW4gc29tZSBwbGFjZXMgYW5kIOKAnEFwcCBEZXZlbG9wZXLigJ0gaW4gb3Ro ZXJzDQphbmQgdGhlbiBzYXlpbmcgdGhleeKAmXJlIHN5bm9ueW1vdXMgbGlrZSBpdCBkb2VzIG5v dy4gICAoSeKAmWQgYmUgb2sgd2l0aCBtZW50aW9uaW5nIHRoYXQgaW4gc29tZSBjb250ZXh0cyBh biBBcHAgRGV2ZWxvcGVyDQptaWdodCBiZSBrbm93biBhcyBhIOKAnFNlcnZpY2UgUHJvdmlkZXLi gJ0gaWYgdGhhdCBpcyBpbXBvcnRhbnQgdG8gR2xvYmFsUGxhdGZvcm0gZm9sa3MuKQ0KDQpEYXZl DQoNCkZyb206IFRFRVAgPHRlZXAtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86dGVlcC1ib3VuY2Vz QGlldGYub3JnPj4gT24gQmVoYWxmIE9mIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNClNlbnQ6 IE1vbmRheSwgRGVjZW1iZXIgMjMsIDIwMTkgNDoxNyBBTQ0KVG86IHRlZXBAaWV0Zi5vcmc8bWFp bHRvOnRlZXBAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbVGVlcF0gV29ya2luZyBHcm91cCBMYXN0IENh bGwgZm9yIGRyYWZ0LWlldGYtdGVlcC1hcmNoaXRlY3R1cmUNCg0KSGkgYWxsLA0KDQpUaGlzIG1l c3NhZ2Ugc3RhcnRzIGEgV29yayBHcm91cCBMYXN0IENhbGwgKFdHTEMpIGZvciBURUVQIGFyY2hp dGVjdHVyZS4gIFRoZSB2ZXJzaW9uIHRvIGJlIHJldmlld2VkIGlzIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRlZXAtYXJjaGl0ZWN0dXJlLTA1PGh0dHBzOi8vY2xpY2t0 aW1lLnN5bWFudGVjLmNvbS8zSjhteVZDbnBlbmtIcE5lQWVnZFNhRzdWYz91PWh0dHBzJTNBJTJG JTJGbmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20lMkYlM0Z1cmwlM0RodHRw cyUyNTNBJTI1MkYlMjUyRnRvb2xzLmlldGYub3JnJTI1MkZodG1sJTI1MkZkcmFmdC1pZXRmLXRl ZXAtYXJjaGl0ZWN0dXJlLTA1JTI2ZGF0YSUzRDAyJTI1N0MwMSUyNTdDZHRoYWxlciUyNTQwbWlj cm9zb2Z0LmNvbSUyNTdDYmNmM2IyYzVmOTViNGM0YzMxZmEwOGQ3OTM1M2VjZTUlMjU3QzcyZjk4 OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTI1N0MxJTI1N0MwJTI1N0M2MzcxMzk4NjE5MDkw MDkzMDYlMjZzZGF0YSUzRGprU2lGWXBHOEZGVkpVUGs3bnpLNFZDSDJqM2ltM1J5Rll0UWo3aWVI Q3clMjUzRCUyNnJlc2VydmVkJTNEMD4NCg0KVGhlIFdHTEMgd2lsbCBsYXN0IGZvciA0IHdlZWtz IGFuZCB3aWxsIGVuZCBvbiAyMCBKYW51YXJ5IDIwMjAuDQoNClBsZWFzZSBzZW5kIHlvdXIgY29t bWVudHMgdG8gdGhlIGxpc3QgYmVmb3JlIHRoaXMgZGF0ZSBhbmQgeW91ciBhc3Nlc3NtZW50IG9m IHdoZXRoZXIgb3Igbm90IGl0IGlzIHJlYWR5IHRvIHByb2NlZWQgdG8gcHVibGljYXRpb24uDQoN ClJlZ2FyZHMsDQpUaXJ1ICYgTmFuY3kNCklNUE9SVEFOVCBOT1RJQ0U6IFRoZSBjb250ZW50cyBv ZiB0aGlzIGVtYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYXJlIGNvbmZpZGVudGlhbCBhbmQgbWF5 IGFsc28gYmUgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVu dCwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xv c2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBv c2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5r IHlvdS4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpU RUVQIG1haWxpbmcgbGlzdA0KVEVFUEBpZXRmLm9yZzxtYWlsdG86VEVFUEBpZXRmLm9yZz4NCmh0 dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zRTR4SlFWRnlkY21uamdzcEViTGpWNDdWYz91 PWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGVlcA0K --_000_DM5PR1601MB1259E8FF52F3287272903036EA350DM5PR1601MB1259_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFu Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIg MTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hp YW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5 bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWls U3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDoxODI0MDE4MjU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjY1NDk3MDUzMDt9DQpA bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjkxMTMwODgzNzsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6LTk0MjMzNDEwO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K dWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIE1pbmcsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBs ZWFzZSBzZWUgaW5saW5lIFtUUjJdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8 L2I+IE1pbmdsaWFuZyBQZWkgJmx0O21pbmdsaWFuZy5wZWlAYnJvYWRjb20uY29tJmd0OyA8YnI+ DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBKYW51YXJ5IDEyLCAyMDIwIDEyOjEyIFBNPGJyPg0KPGI+ VG86PC9iPiBLb25kYSwgVGlydW1hbGVzd2FyIFJlZGR5ICZsdDtUaXJ1bWFsZXN3YXJSZWRkeV9L b25kYUBNY0FmZWUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gRGF2ZSBUaGFsZXIgJmx0O2R0aGFs ZXJAbWljcm9zb2Z0LmNvbSZndDs7IEhhbm5lcyBUc2Nob2ZlbmlnICZsdDtIYW5uZXMuVHNjaG9m ZW5pZ0Bhcm0uY29tJmd0OzsgdGVlcEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W1RlZXBdIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLXRlZXAtYXJjaGl0 ZWN0dXJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8dGFibGUgY2xh c3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjEiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0iYmFj a2dyb3VuZDojRjNGRjMzO2JvcmRlcjpzb2xpZCAjOUI5QTg3IDEuNXB0Ij4NCjx0Ym9keT4NCjx0 cj4NCjx0ZCBzdHlsZT0iYm9yZGVyOm5vbmU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVw dCI+DQo8cD48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM5QjhCM0UiPkNBVVRJT048L3NwYW4+PC9zdHJvbmc+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzlC OEIzRSI+Ojwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+IEV4dGVybmFsIGVtYWlsLiBEbyBub3QgY2xpY2sgbGlu a3Mgb3Igb3Blbg0KIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIg YW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRl ciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iMTAwJSIg YWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkg VGlydSwgdGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgeW91ciBjb21tZW50cyBhbmQgc3VnZ2VzdGlv bnMuIFRoYW5rcyBEYXZlIGFuZCBIYW5uZXMgZm9yIHByb21wdCByZXNwb25zZSBmb3IgdXMuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFz ZSBzZWUgbXkgY29tbWVudHMgaW5saW5lcywgbW9zdGx5IG9uIHRvcCBvZiB5b3VyIGxhc3QgcmVw bGllcywgYW5kIGZvciBzZXZlcmFsIHF1ZXN0aW9ucyB0aGF0IG5lZWQgYWRkaXRpb25hbCBjbGFy aWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk1pbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIFdlZCwgSmFuIDgsIDIwMjAgYXQgMTE6NTMgUE0gS29uZGEsIFRpcnVtYWxlc3dh ciBSZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQG1jYWZl ZS5jb20iPlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQG1jYWZlZS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5IaSBIYW5uZXMgYW5kIERhdmUsPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5UaGFua3MgZm9yIHRoZSByZXNwb25zZXMuIFBsZWFzZSBzZWUgaW5saW5lIFtUUl0N CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3Rl eHQgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNv bG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgYmx1ZSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW47Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gRGF2ZSBUaGFsZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpkdGhhbGVyQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5kdGhhbGVy QG1pY3Jvc29mdC5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSmFu dWFyeSA4LCAyMDIwIDE6MTQgQU08YnI+DQo8Yj5Ubzo8L2I+IEhhbm5lcyBUc2Nob2ZlbmlnICZs dDs8YSBocmVmPSJtYWlsdG86SGFubmVzLlRzY2hvZmVuaWdAYXJtLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPkhhbm5lcy5Uc2Nob2ZlbmlnQGFybS5jb208L2E+Jmd0OzsgS29uZGEsIFRpcnVtYWxlc3dh ciBSZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZl ZS5jb20iPlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb208L2E+Jmd0OzsNCjxhIGhy ZWY9Im1haWx0bzp0ZWVwQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+dGVlcEBpZXRmLm9yZzwv YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciBk cmFmdC1pZXRmLXRlZXAtYXJjaGl0ZWN0dXJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxlIiBib3JkZXI9IjEiIGNlbGxwYWRkaW5nPSIwIiBz dHlsZT0iYmFja2dyb3VuZDojRjNGRjMzO2JvcmRlcjpzb2xpZCAjOUI5QTg3IDEuNXB0O2JhY2tn cm91bmQtYXR0YWNobWVudDpzY3JvbGw7YmFja2dyb3VuZC1wb3NpdGlvbi14OjAlO2JhY2tncm91 bmQtcG9zaXRpb24teTowJSI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9ImJvcmRlcjpub25l O3BhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHA+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojOUI4QjNFIj5DQVVUSU9OPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM5QjhC M0UiPjo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+DQogRXh0ZXJuYWwgZW1haWwu IERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2du aXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIg YWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj4NCjxociBzaXplPSIyIiB3 aWR0aD0iMTAwJSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QmVsb3c8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93dGV4dCAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3Ig Y3VycmVudGNvbG9yIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4N CjxiPkZyb206PC9iPiBIYW5uZXMgVHNjaG9mZW5pZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkhhbm5l cy5Uc2Nob2ZlbmlnQGFybS5jb20iIHRhcmdldD0iX2JsYW5rIj5IYW5uZXMuVHNjaG9mZW5pZ0Bh cm0uY29tPC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDcsIDIw MjAgMToyOCBBTTxicj4NCjxiPlRvOjwvYj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5UaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPC9hPiZndDs7IERh dmUgVGhhbGVyICZsdDs8YSBocmVmPSJtYWlsdG86ZHRoYWxlckBtaWNyb3NvZnQuY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZHRoYWxlckBtaWNyb3NvZnQuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWls dG86dGVlcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRlZXBAaWV0Zi5vcmc8L2E+PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJFOiBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0 Zi10ZWVwLWFyY2hpdGVjdHVyZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KSGkgVGlydSwgPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQom bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDou NWluIj4NClRoYW5rcyBmb3IgdGhlIHJldmlldy4gVGhlcmUgaXMgY2xlYXJseSByb29tIGZvciBp bXByb3ZpbmcgdGhlIHdyaXRlLXVwLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KQSBmZXcgcmVtYXJrcyBiZWxvdy4gPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQom bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbjti b3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8Yj5Gcm9tOjwvYj4gVEVFUCAmbHQ7PGEgaHJlZj0i bWFpbHRvOnRlZXAtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRlZXAtYm91bmNl c0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPktvbmRhLCBUaXJ1bWFsZXN3 YXIgUmVkZHk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSmFudWFyeSA3LCAyMDIwIDc6Mzkg QU08YnI+DQo8Yj5Ubzo8L2I+IERhdmUgVGhhbGVyICZsdDs8YSBocmVmPSJtYWlsdG86ZHRoYWxl ckBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZHRoYWxlckBtaWNyb3NvZnQuY29tPC9h PiZndDs7DQo8YSBocmVmPSJtYWlsdG86dGVlcEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRl ZXBAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVGVlcF0gV29ya2luZyBH cm91cCBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtdGVlcC1hcmNoaXRlY3R1cmU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 LjVpbiI+DQombmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij5bQXMgYW4gaW5kaXZpZHVhbF08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDouNWluIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KSGkgRGF2ZSw8bzpwPjwvbzpwPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj5JIGhhdmUgcmV2aWV3ZWQgdGhlIGRyYWZ0IGFuZCBoYXZlIGNv bW1lbnRzIGFuZCBuaXRzIGxpc3RlZCBiZWxvdzo8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5hKSBJdCBpcyBub3QgY2xlYXIgZnJvbSB0aGUgSW50cm9kdWN0aW9uIGhvdyBU RUUgaXMgZGlmZmVyZW50IGZyb20gYSBDbG9zZWQgT1MgbGlrZSBHb29nbGUgQ2hyb21lYm9vayBv ciBXaW5kb3dzIDEwUyA/PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO1RoZSBiZW5lZml0IG9mIFBheW1lbnQgYXBwbGlj YXRpb24gcnVubmluZyBpbiBDbG9zZWQgT1MgdmVyc2VzIGluIFRFRSBpcyBub3QgZXZpZGVudCBm cm9tIHRoZSBkZXNjcmlwdGlvbi4gV2hhdCBwYXJ0IG9mIHRoZSBQYXltZW50IGFwcGxpY2F0aW9u IHJ1bnMgaW4gdGhlIFJFRSBhbmQgVEVFIHJlc3BlY3RpdmVseSA/PG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IElmIGJp b21ldHJpYyBpZGVudGlmaWNhdGlvbiBpbmZvcm1hdGlvbiBpcyBzZWN1cmVseSBzdG9yZWQgaW4g VEVFIGZvciBpZGVudGlmaWNhdGlvbiwgaG93IGRvZXMgdGhlIFRFRSBpZGVudGlmeSB0aGUgYmlv bWV0cmljIGlkZW50aWZpY2F0aW9uIGluZm9ybWF0aW9uIGlzIG5vdCByZXRyaWV2ZWQgYnkgYW4g bWFsaWNpb3VzIGFnZW50IGluIHRoZSBSRUUuPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlY3Rpb24gMy4zIChJbnRl cm5ldCBvZiB0aGluZ3MpLCBIb3cgZG9lcyB0aGUgYXJjaGl0ZWN0dXJlIGVuc3VyZSB0aGUgc2Vu c2l0aXZlIGRhdGEgaXMgcmV0cmlldmVkIGJ5IGEgbGVnaXRpbWF0ZSBhcHBsaWNhdGlvbiBpbiB0 aGUgUkVFIGFuZCBub3QgYnkgYW4gbWFsaWNpb3VzIGFwcGxpY2F0aW9uID8gJm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W0hhbm5lc10gVGhlIFRFRSBhZGRzIGFu b3RoZXIgbGF5ZXIgb2Ygc29mdHdhcmUgaXNvbGF0aW9uLiBUbyBwcm90ZWN0IG9uZSBUQSB0byBz dGVhbCBkYXRhIGZyb20gYW5vdGhlciBUQSB0aGUgdHdvIFRBcyBuZWVkIHRvIGJlIGlzb2xhdGVk IGFnYWluc3QgZWFjaCBvdGhlci4gRGVwZW5kaW5nIG9uIHRoZSBURUUgdGVjaG5vbG9neSB5b3Ug YXJlIHVzaW5nIHRoaXMgaXMgYWNjb21wbGlzaGVkIHZpYQ0KIGRpZmZlcmVudCBtZWFucy4gPG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SXQgaXMgdXAgdG8gdGhlIGFwcGxp Y2F0aW9uIGRldmVsb3BlciB0byBkZWNpZGUgaG93IHRoZXkgYmVzdCB3YW50IHRvIHNlcGFyYXRl IHRoZSBSRUUgYW5kIHRoZSBURUUgcGFydCwgd2hpY2ggaW4gcGFydCBkZXBlbmRzIGEgYml0IG9u IHdoYXQgdHlwZSBvZiBwYXltZW50IHByb3RvY29sIHRoZXkgYXJlIHVzaW5nLiBJbiBzb21lIG90 aGVyIGNhc2VzIChwcm9iYWJseSBtb3JlIHJlYWxpc3RpYykgdGhleQ0KIG1heSBiZSB1c2luZyBh biBhbHJlYWR5IGV4aXN0aW5nIHBheW1lbnQgc3lzdGVtLCB3aGljaCBpcyBwcm92aWRlZCBhcyBh IFRBLCBhbmQgdGhleSBhcmUganVzdCB1c2luZyBpdC4gSW4gZ2VuZXJhbCwgaXQgZG9lcyBub3Qg c3RyaWtlIG1lIGFzIGEgZ3JlYXQgaWRlYSB0byBoYXZlIHJhbmRvbSBzbWFydCBwaG9uZSBhcHAg ZGV2ZWxvcGVycyB3cml0aW5nIHRoZWlyIG93biBwYXltZW50IHNvZnR3YXJlLg0KPG86cD48L286 cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPltUUl0gR290IGl0LCBUaGFua3Mu PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZSBk b2N1bWVudCAoaW50ZW50aW9uYWxseSkgbWFrZXMgbm8gc3RhdGVtZW50IGFib3V0IHdoZXRoZXIg YSDigJxjbG9zZSBPU+KAnSBhcyB5b3UgcHV0IGl0LCBpcyBvciBpcyBub3QgYSBURUUuJm5ic3A7 Jm5ic3A7IFRoZSBxdWVzdGlvbiBpcyByZWFsbHkgYWJvdXQgd2hldGhlciBzdWNoIGFuIE9TIHBy ZXZlbnRzIGNvZGUgaW5qZWN0aW9uIGF0dGFja3MgKGUuZy4sIGR1ZSB0byBidWZmZXIgb3ZlcnJ1 bnMgb3Igd2hhdGV2ZXINCiBlbHNlKSwgcHJldmVudHMgZGF0YSBtb2RpZmljYXRpb24gYXR0YWNr cywgZXRjLi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwPltUUl0gQ2xvc2VkIE9TIHByZXZlbnQgdGhlIGFib3ZlIGF0dGFja3MsIGEgbWFsaWNpb3Vz IGFwcCBjYW5ub3QgcmVhZC9tb2RpZnkgdGhlIGRhdGEgb2YgdGhlIG90aGVyIGFwcHMgKGUuZy4s IHJhbnNvbXdhcmUgYXR0YWNrIGlzIG5vdCBwb3NzaWJsZSwgc2VlDQo8YSBocmVmPSJodHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0pQU0VCTnJ1Qm1VS2N0bWhhQm9HcFQ3VmM/dT1odHRw cyUzQSUyRiUyRnN1cHBvcnQuZ29vZ2xlLmNvbSUyRmNocm9tZWJvb2slMkZhbnN3ZXIlMkYzNDM4 NjMxJTNGaGwlM0RlbiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9zdXBwb3J0Lmdvb2dsZS5j b20vY2hyb21lYm9vay9hbnN3ZXIvMzQzODYzMT9obD1lbjwvYT4pLiZuYnNwOyA8bzpwPjwvbzpw PjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5iKSBXaHkgc2hvdWxkIHRoZSBsaXN0IG9mIHRy dXN0IGFuY2hvcnMgb24gdGhlIGRldmljZSBiZSBtYW5hZ2VkIGJ5IHRoZSBEZXZpY2UncyBuZXR3 b3JrIGNhcnJpZXIgPzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoeW91IG1heSB3YW50IHRvIGRlZmluZSB0aGUgdGVy bSAmcXVvdDtuZXR3b3JrIGNhcnJpZXImcXVvdDspLjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGlzIGlzIGlzc3VlICMxMTIgdGhhdCBJIGZpbGVk LiZuYnNwOyZuYnNwOyBQZXJzb25hbGx5IEkgdGhpbmsgdGhlIHRlcm0g4oCcY2FycmllcuKAnSBz aG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBkb2MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EYXZlIGhhcyB0aGlzIGlzc3VlIHRy YWNrZWQsIGFuZCBJIGFkZGVkIGNvbW1lbnQgdGhlcmUuIEZvciBvbmUsICZxdW90O2EgbmV0d29y ayBjYXJyaWVyJnF1b3Q7IGFwcGxpZXMgdG8gbW9iaWxlIGRldmljZSBvbmx5LCBhbmQgd2UgaGF2 ZSBvdGhlciBURUUgZGV2aWNlIHR5cGVzLiBPbiB0aGUgb3RoZXIgaGFuZCwgdGhlICZxdW90O25l dHdvcmsgY2FycmllciZxdW90OyB0ZXh0IGRvZXMgaGF2ZSBzb21lIHJlbGV2YW5jZSBoZXJlLiBG b3IgbW9iaWxlDQogZGV2aWNlcywgVHJ1c3QgQW5jaG9ycyBhcmUgZXhwZWN0ZWQgdG8gYmUgc2V0 IGJ5IGRldmljZSBtYW51ZmFjdHVyZXJzLiBXaGF0IHRvIHB1dCBieSBhIGRldmljZSBtYW51ZmFj dHVyZXIgaW50byBkZXZpY2VzLCBob3dldmVyLCBpcyBvZnRlbiBnb3Zlcm5lZCBvciBpbnN0cnVj dGVkIGJ5IHRoZSBuZXR3b3JrIGNhcnJpZXIgdGhhdCBhIHBhcnRpY3VsYXIgbW9iaWxlIGRldmlj ZSBpcyBwcm9kdWNlZCBmb3IuIFRoYXQgaXMgdGhlIGhpc3Rvcnkgb2YNCiB0aGlzIGNvbnRleHQu IEkgdGhpbmsgd2UgY2FuIG1ha2UgdGhpcyBhcyBhbiBleGFtcGxlIG9mIHNldCBmb3Igc3VjaCBh IGNhc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltUUjJdIFRoYW5rcyBmb3IgdGhlIGNsYXJp ZmljYXRpb24uIFlvdSBtYXkgd2FudCB0byBhZGQgdGhlIG1vYmlsZSBkZXZpY2UgZXhhbXBsZSBp biB0aGUgZG9jdW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2lu ZG93dGV4dCAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O2JvcmRlci1jb2xvcjpjdXJy ZW50Y29sb3IgY3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBibHVlIj4NCjxwPltUUl0gV29ya3Mg Zm9yIG1lLjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPltIYW5uZXNdIFRo ZSB0ZXh0IHNheXMgdGhlIGZvbGxvd2luZzogPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+4oCcPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhlIGxpc3Qgb2YgVHJ1c3QgQW5j aG9ycyBpcyBub3JtYWxseSBtb2RpZmlhYmxlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBieSB0aGUgRGV2aWNlJ3Mgb3duZXIgb3Ig RGV2aWNlIEFkbWluaXN0cmF0b3IuJm5ic3A7IEhvd2V2ZXIgdGhlIERldmljZTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDouNWluIj4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbWFudWZh Y3R1cmVyIGFuZCBuZXR3b3JrIGNhcnJpZXIgbWF5IHJlc3RyaWN0IHNvbWUgbW9kaWZpY2F0aW9u cyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGZvciBleGFtcGxlLCBieSBub3QgYWxsb3dpbmcgdGhlIG1hbnVmYWN0dXJlciBvciBj YXJyaWVyJ3MgVHJ1c3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFuY2hvciB0byBiZSByZW1vdmVkIG9yIGRpc2FibGVkLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj7igJw8bzpwPjwv bzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGlzIGRlc2NyaWJlcyBjdXJyZW50IHBy YWN0aWNlIGluIHRoZSBtb2JpbGUgcGhvbmUgaW5kdXN0cnkgYW5kIG1heSBub3QgbmVjZXNzYXJp bHkgYmUgYXBwbGljYWJsZSB0byBvdGhlciBkZXBsb3ltZW50IHNjZW5hcmlvcy4gSGVuY2UsIHRo ZXJlIGlzIG5vIHJlcXVpcmVkIGJlaGF2aW9yIGhlcmUuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj5jKSBJZiB0aGUgUkVFIGlzIGNvbXByb21pc2VkIChmb3IgZXhhbXBsZSBieSBt YWx3YXJlKSwgaXQgY291bGQgdGVybWluYXRlIHRoZSBURUVQIGJyb2tlciBpbiBSRUUuIEhvdyBp cyB0aGlzIGF0dGFjayBtaXRpZ2F0ZWQgPzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPltIYW5uZXNdIElmIHRoZSBSRUUgaXMgY29tcHJvbWlzZWQgdGhlbiB0aGF04oCZcyB0 eXBpY2FsbHkgbm90IGEgZ29vZCB0aGluZyBidXQgdGhlIFJFRSBzaWRlIHN0aWxsIGNhbm5vdCBh Y2Nlc3MgYW55dGhpbmcgb24gdGhlIHNlY3VyZSB3b3JsZCwgaWYgaW1wbGVtZW50ZWQgY29ycmVj dGx5LiBJdCBjb3VsZCwgaG93ZXZlciwgaW5kZWVkIHRlcm1pbmF0ZSB0aGUgVEVFUCBicm9rZXIg YW5kIGF2b2lkDQogYW55IGNhbGxzIHRvIHRoZSBzZWN1cmUgd29ybGQuIFRoaXMgd291bGQgYmUg YSBEb1MgYXR0YWNrLi4gSXQgd291bGQgYmUgcG9zc2libGUgdG8gcGVyaW9kaWNhbGx5IHNjaGVk dWxlIGFuIGludGVycnVwdCB0aGF0IGlzIHByb2Nlc3NlZCBieSB0aGUgc2VjdXJlIHdvcmxkIHRv IGxldCB0aGUgc2VjdXJlIHdvcmxkIGRvdWJsZS1jaGVjayB0aGUgc3RhdGUgb2YgdGhlIG5vcm1h bCB3b3JsZC48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+UmlnaHQuJm5ic3A7IERvUyBhdHRhY2tzIGJ5IHRoZSBSRUUgYXJlLCBpbiBnZW5lcmFsLCBu b3QgcHJldmVudGVkIChzb21lIFRFRXMgbWF5IHByZXZlbnQgdGhlbSBidXQgbW9zdCB3b27igJl0 KS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ VGhlIFRFRVAgYXJjaGl0ZWN0dXJlIGRvZXNu4oCZdCBjaGFuZ2UgdGhpcy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPltUUl0gWW91IG1heSB3YW50 IHRvIGV4cGxhaW4gdGhlIGFib3ZlIHRocmVhdCB2ZWN0b3IgaW4gdGhlIGRvY3VtZW50LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W01QXSBBZ3JlZWQuIFdpbGwgYWRkIHNvbWUgdGV4dCBv biB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9y IGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgYmx1ZSI+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ ZCkgV2hhdCBoYXBwZW5zIGlmIHRoZSBtYWxpY2lvdXMgYWdlbnQgYWN0aW5nIGFzIFRFRVAgYnJv a2VyIGxhdW5jaGVzIGF0dGFja3MgKGUuZy4gZ2FyYmFnZSBkYXRhLCByZXBsYXkgYXR0YWNrLCBE b1Mgb2YgbWVzc2FnZXMgZXRjLiwpIG9uIHRoZSBURUVQIGFnZW50LCBhbmQgaG93IHdpbGwgdGhl IFRFRVAgYWdlbnQgZGVmZW5kIGl0c2VsZiA/PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+W0hhbm5lc10gVGhlIFRFRVAgYWdlbnQgZGlzcGF0Y2hlcyBjYWxscyB0byB0aGUg dHJ1c3RlZCBhcHBsaWNhdGlvbnMuIEl0IGlzIHR5cGljYWxseSBhIHNoaW0gbGF5ZXIgdGhhdCBq dXN0IGNoZWNrcyBwYXJhbWV0ZXJzIG9mIHRoZSByZXF1ZXN0cyBhbmQgdGhlbiByZWxheXMgdGhl bSB0byB0aGUgVEFzLiBIYXZpbmcgYSByb2NrIHNvbGlkIGltcGxlbWVudGF0aW9uIG9mIHRoZSBU RUVQIGFnZW50DQogaXMgaW1wb3J0YW50IGFuZCBvZiBjb3Vyc2UgdGhlIFRBcyBuZWVkIHRvIGJl IGltcGxlbWVudGVkIHByb3Blcmx5IGFzIHdlbGwuIDxvOnA+DQo8L286cD48L3A+DQo8cCBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+VGhlIEdQIFRFRSBDbGllbnQgQVBJIGlzIG1lYW50IHRvIHByb3ZpZGUg YSByZWZlcmVuY2UgZGVzaWduIGZvciBhbiBBUEkgdGhhdCBhbGxvd3MgZGF0YSBwYXNzaW5nIGJh Y2sgYW5kIGZvcnRoLiBTbywgaW1wbGVtZW50aW5nIHRoYXQgQVBJIHByb3Blcmx5IHdpbGwgYmUg aW1wb3J0YW50LiBUaGlzIGlzIHdoeSB0aGVyZSBpcyB0aGlzIG9wZW4gc291cmNlIHByb2plY3Qg dG8gaW1wbGVtZW50IHRoYXQNCiBBUEkgc28gdGhhdCBvdGhlciBkZXZlbG9wZXJzIGNhbiBqdXN0 IHVzZSBpdC4gPG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPlRoZSBURUVQIEFnZW50IGltcGxlbWVudHMgYSBzZWN1cmUgcHJvdG9jb2wgKHRoZSBURUVQ IHByb3RvY29sKSBiZXR3ZWVuIGl0IGFuZCBhIFRBTS48YnI+DQpUaGF0IHByb3RvY29sIG11c3Qg YmUgc2VjdXJlIGFnYWluc3QgYXR0YWNrcyBieSB1bnRydXN0ZWQgaW50ZXJtZWRpYXJpZXMsIGlu Y2x1ZGluZyByb3V0ZXJzLCBIVFRQIHByb3hpZXMsIGFuZCBURUVQIGJyb2tlcnMuPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5bVFJdIE9rYXkuIEkg dGhpbmsgaXQgd2lsbCBiZSB1c2VmdWwgdG8gZGlzY3VzcyBwb3NzaWJsZSBhdHRhY2tzIGJ5IHVu dHJ1c3RlZCBpbnRlcm1lZGlhcmllcyBvbiB0aGUgVEVFUCBhZ2VudCBhbmQgaG93IHRoZSBURUVQ IGFnZW50IGNhbiBwcm90ZWN0IGl0c2VsZiAoZWl0aGVyIGluIHRoaXMgZG9jdW1lbnQgb3IgaW4g dGhlIFRFRVAgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbikgPzxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bTVBdIFdlIG1heSBhZGQgdGhpcyBhbmQg dGhlIGFib3ZlIG9uZSBpbiAmcXVvdDtTZWN1cml0eSBDb25zaWRlcmF0aW9uJnF1b3Q7LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xv ciBjdXJyZW50Y29sb3IgYmx1ZSI+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ZSkgVGhlIGJlbG93 IGxpbmUgaXMgbm90IGNsZWFyIHRvIG1lOjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPkVudW1lcmF0aW9uIGFuZCBhY2Nlc3MgdG8gdGhlIGFwcHJvcHJpYXRlIFRF RVAgQnJva2VyIGlzIHVwIHRvIHRoZSBSaWNoIEV4ZWN1dGlvbiBFbnZpcm9ubWVudCBhbmQgdGhl IFVudHJ1c3RlZCBBcHBsaWNhdGlvbnMuLjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPltIYW5uZXNdIFRoZXJlIG1heSBiZSBtdWx0aXBsZSBURUVQIEJyb2tlcnMgb24gdGhl IHN5c3RlbSBhbmQgdGhlIGludGVyYWN0aW9uIGJldHdlZW4gdW50cnVzdGVkIGFwcHMgYW5kIHRo ZSBURUVQIGJyb2tlciBpcyB1cCB0byBhIHBvbGljeSBpbXBsZW1lbnRlZCBieSB0aGUgZGV2ZWxv cGVyLjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5J IGFncmVlIHRoZSBsaW5lIGlzIGNvbmZ1c2luZ2x5IHdvcmRlZC48L3NwYW4+PG86cD48L286cD48 L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+W1RSXSBQbGVhc2UgZml4IGluIHRoZSBuZXh0IHVwZGF0ZS4gPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5bTVBdIEFncmVlZC4gV2lsbCBmaXguIChEYXZlIGhhcyBoYWQg c29tZSBvbiBNdWx0aXBsZSBURUVQIEJyb2tlcikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O2Jv cmRlci1jb2xvcjpjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBibHVlIj4N CjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5oKSBBIHVzZSBjYXNlIGV4cGxhaW5pbmcgdGhlIHVzZSBv ZiBtdWx0aXBsZSBUQU0sIG11bHRpcGxlIFRFRVAgYnJva2VycyBvbiBhIGRldmljZSwgYW5kIG11 bHRpcGxlIFRFRSB3b3VsZCBiZSB1c2VmdWwgdG8gdGhlIHJlYWRlciBvZiB0aGUgc3BlY2lmaWNh dGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ SXNu4oCZdCB0aGF0IHdoYXQgRmlndXJlIDIgYWxyZWFkeSBwcm92aWRlcz8mbmJzcDsgQ2FuIHlv dSBlbGFib3JhdGUgb24gd2hhdCB5b3XigJlyZSBsb29raW5nIGZvcj88L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPltUUl0gSSBhbSBsb29raW5nIGZv ciB1c2UgY2FzZXMsIHRoZSB0ZXh0IHByb3Bvc2VkIGJ5IEhhbm5lcyBiZWxvdyBsb29rcyBsaWtl IGEgZ29vZCBzdGFydGluZyBwb2ludC48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4t bGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj5bSGFubmVzXSBEZWZpbml0ZWx5IGEgZ29vZCBpZGVhIHRvIGFkZCB0ZXh0IHdpdGggdXNl IGNhc2VzLg0KPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SGVy ZSBpcyBteSBxdWljayByZXNwb25zZTogPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MS4waW4iPg0KLSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBNdWx0aXBsZSBUQU1zOiB5b3UgY291bGQgdGhpbmsgYWJvdXQg dGhpcyBhcyBoYXZpbmcgbXVsdGlwbGUgY29kZSByZXBvc2l0b3JpZXMuIERpZmZlcmVudCBTUHMg bWF5IHByZWZlciB0byB1c2UgY2VydGFpbiBUQU1zIGZvciB0aGVpciBzb2Z0d2FyZSBkaXN0cmli dXRpb24uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDoxLjBpbiI+DQotJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IE11bHRpcGxlIFRFRVAgYnJva2VyczogdGhpcyBjYW4gb2NjdXIgd2hlbiB5b3Ug aGF2ZSBhIGJyb2tlciBvZmZlcmVkIGJ5IHRoZSBPUyBhbmQgb25lIGJ1bmRsZWQgd2l0aCB0aGUg dW50cnVzdGVkIGFwcC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjEuMGluIj4NCi0mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgTXVsdGlwbGUgVEVFczogVGhpcyBkZXBlbmRzIG9uIHRoZSBURUUg dGVjaG5vbG9neS4gSW4gdGhlIFRydXN0Wm9uZSBjYXNlIHlvdSBtYXkgaGF2ZSBhIG11bHRpLXBy b2Nlc3NvciBzeXN0ZW0gYW5kIGVhY2ggcHJvY2Vzc29yIGNvbWVzIHdpdGggVHJ1c3Rab25lIHN1 cHBvcnQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5pKSBXaGVuIGEg VEVFUCBCcm9rZXIgcmVjZWl2ZXMgYSByZXF1ZXN0IGZyb20gYW4gVW50cnVzdGVkIEFwcGxpY2F0 aW9uPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5i c3A7IHRvIGluc3RhbGwgYSBUQSwgYSBsaXN0IG9mIFRBTSBVUklzIG1heSBiZSBwcm92aWRlZCBm b3IgdGhhdCBUQSwgYW5kPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+Jm5ic3A7Jm5ic3A7IHRoZSByZXF1ZXN0IGlzIHBhc3NlZCB0byB0aGUgVEVFUCBBZ2VudC4m bmJzcDsgSWYgdGhlIFRFRVAgQWdlbnQgZGVjaWRlczxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOyZuYnNwOyB0aGF0IHRoZSBUQSBuZWVkcyB0byBiZSBp bnN0YWxsZWQsIHRoZSBURUVQIEFnZW50IHNlbGVjdHMgYSBzaW5nbGU8bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsgVEFNIFVSSSB0aGF0IGlz IGNvbnNpc3RlbnQgd2l0aCB0aGUgbGlzdCBvZiB0cnVzdGVkIFRBTXMgcHJvdmlzaW9uZWQ8bzpw PjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsgb24g dGhlIGRldmljZSBpbnZva2VzIHRoZSBIVFRQIHRyYW5zcG9ydCBmb3IgVEVFUCB0byBjb25uZWN0 IHRvIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw OyZuYnNwOyBUQU0gVVJJIGFuZCBiZWdpbnMgYSBURUVQIHByb3RvY29sIGV4Y2hhbmdlLjxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkNvbW1lbnQmZ3Q7IEkgYW0gbm90IHN1 cmUgd2h5IHRoZSBhcmNoaXRlY3R1cmUgZHJhZnQgaXMgZGlzY3Vzc2luZyB0aGUgcHJvdG9jb2wg YXNwZWN0cyBsaWtlIEhUVFAgZm9yIFRFRVAgPzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPltIYW5uZXNdIEkgYmVsaWV2ZSBpdCBkb2VzIG5vdCBuZWVkIHRvIG1lbnRpb24g SFRUUCBidXQgaXQgY291bGQgbGlzdCBpdCBhcyBhbiBleGFtcGxlLg0KPG86cD48L286cD48L3A+ DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlN1cmUuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5PbiB0aGUgb3RoZXIg aGFuZCwgd2UgaGF2ZSBhIFdHIGRvY3VtZW50LCBhbmQgdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVu dCBjYW4gbWVudGlvbiBpdCBhcyBleHBsYWluaW5nIGhvdyB0aGF0IGRvYyBmaXRzIGludG8gdGhl IGFyY2hpdGVjdHVyZSBhbmQgcmVsYXRlcyB0byB0aGUgb3RoZXIgZG9jcy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPltUUl0gRmFpciBwb2ludC4g PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5qKSBXaGF0IGlmIHRoZSBtYWx3YXJlIGluIFJFRSBpbnN0cnVjdHMgdGhl IFRFRVAgYWdlbnQgdmlhIFRFRVAgYnJva2VyIHRvIGtlZXAgaW5zdGFsbGluZy91bmluc3RhbGxp bmcgVEEgKG92ZXItd2hlbG0gdGhlIFRFRVAgYWdlbnQgYW5kIFRFRSBvciBpbnN0YWxsaW5nIHVu LW5lY2Vzc2FyeSBUQSB0byBoYXZlIG5vIG1lbW9yeSBmb3IgdGhlIHJlcXVpcmVkIFRBKSA/PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkFuIFJFRSBj YW4gYWx3YXlzIGNvbmR1Y3QgRG9TIGF0dGFja3MgYWdhaW5zdCBhIFRFRVAgYWdlbnQgYXMgZGlz Y3Vzc2VkIGluIHlvdXIgcXVlc3Rpb24gKGMpIGFib3ZlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Ib3dldmVyIHRoZSB3b3JkIOKAnGluc3Ry dWN0c+KAnSBpcyBpbmNvcnJlY3Qgc2luY2UgdGhlIFRFRVAgQWdlbnQgaXMgYXV0aG9yaXRhdGl2 ZSwgeW91ciBxdWVzdGlvbiBzaG91bGQgc2F5IOKAnHJlcXVlc3Rz4oCdIGluc3RlYWQsIHNpbmNl IHRoZSBURUVQIGFnZW50IGlzIGZyZWUgdG8gaWdub3JlL3JlamVjdCB0aGUgcmVxdWVzdC4mbmJz cDsgKFRoaXMgaXMgd2h5IHNlY3Rpb24gNi4yLjEgaGFzIOKAnFJlcXVlc3RUQeKAnSwNCiBhcyBk b2VzIHRoZSB0cmFuc3BvcnQgc3BlYy4pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPltIYW5uZXNdIEhhdmluZyBhIGNvbXByb21pc2VkIFJFRSBlbnZpcm9ubWVu dCB0aGF0IGNhdXNlcyBhbGwgc29ydHMgb2YgYXBwcyB0byBiZSBpbnN0YWxsZWQgaXMgcG9zc2li bGUgKGFzc3VtaW5nIHRoZSBURUUgaXMgYXV0aG9yaXppbmcgdGhlIGluc3RhbGxhdGlvbiBvZiB0 aG9zZSBhcHBzKS4gQW4gaW1wbGVtZW50YXRpb24gb2YgdGhlIHNlY3VyZSB3b3JsZCwgbW9zdCBs aWtlbHkgdGhlIFRFRQ0KIE9TLCB3aWxsIGhhdmUgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIGRldmlj ZSBkb2VzIG5vdCBpbnN0YWxsIFRBcyBhbmQgb3ZlcndyaXRlIHRoZSBtZW1vcnkgc3BhY2UgdGhl eSBoYXZlIGJlZW4gY29uZmlndXJlZCB0byB1c2UuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHA+W1RSXSBNeSBzdWdnZXN0aW9uIGlzIHRvIGRpc2N1c3MgdGhl IGFib3ZlIGF0dGFjayBpbiB0aGUgZG9jdW1lbnQuIDxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bTVBdIEdvb2QgcG9pbnQuIFdlIGNhbiBhZGQg dGhpcyB0aHJlYXQgZGlzY3Vzc2lvbiBpbiBTZWN1cml0eSBDb25zaWRlcmF0aW9uLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBj dXJyZW50Y29sb3IgYmx1ZSI+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW4iPmkpPHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss c2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOw0KPC9zcGFuPldoYXQgaXMgdGhlIHVzZSBjYXNlIGZvciAmcXVvdDtQZXJzb25hbGl6 YXRpb24gZGF0YSZxdW90OyA/PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPlRoZXJlIGlzIGFuIGV4YW1wbGUgaW4gc2VjdGlvbiA0LjQ6PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjb2xvcjpibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OztiYWNrZ3JvdW5kOiNGRkZERjUiPmFuIGV4YW1wbGUgb2Y8L3NwYW4+PG86cD48 L286cD48L2xpPjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImNvbG9yOmJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8yO3dvcmQtYnJlYWs6YnJlYWstYWxs Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2JhY2tncm91bmQ6I0ZGRkRGNSI+cGVyc29uYWxpemF0aW9uIGRhdGEgbWln aHQgYmUgYSBzZWNyZXQgc3ltbWV0cmljIGtleSB1c2VkIGJ5IHRoZSBUQTwvc3Bhbj48bzpwPjwv bzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMUY0OTdEO21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omww IGxldmVsMSBsZm8yIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6I0ZGRkRGNSI+ dG8gY29tbXVuaWNhdGUgd2l0aCB0aGUgU1A8L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8 cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPltUUl0gVGhhbmtzLCBJIG1pc3NlZCB0aGUgZXhh bXBsZS4gPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W0hhbm5lc10gUGVy c29uYWxpemF0aW9uIGRhdGEgaXMgbWVhbnQgdG8gbWFrZSBlYWNoIGluc3RhbmNlIG9mIHRoZSBU QSB1bmlxdWUgYW5kIHBvdGVudGlhbGx5IHRpZSBpdCB0byBhIHNwZWNpZmljIHVzZXIuIEltYWdp bmUgYSBUQSB0aGF0IGltcGxlbWVudHMgYmlvbWV0cmljIGZ1bmN0aW9uYWxpdHk6IHRoZXJlIGhh cyB0byBiZSBzb21ldGhpbmcgaW4gVEEgdGhhdCByZWxhdGVzIHRoaXMgaW5zdGFuY2UNCiBvZiB0 aGUgVEEgdG8gYSBzcGVjaWZpYyBodW1hbiwgZm9yIGV4YW1wbGUgYnkgc3RvcmluZyBhIGZpbmdl cnByaW50IGFsb25nc2lkZSB0aGUgVEEgYXMgY29uZmlndXJhdGlvbiBkYXRhLjxvOnA+PC9vOnA+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPmopIFdoeSBpcyBTZWN0aW9uIDQuNSBkaXNjdXNz aW5nIENhc2UgMSB3aGVuIGl0IG5vdCBpbiB1c2UgPzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPltIYW5uZXNdIFdlIGp1c3QgZGVzY3JpYmUgdGhlIHBvc3NpYmxlIGFwcHJv YWNoIGFuZCBpbGx1c3RyYXRlcyBob3cgdGhpbmdzIGFyZSBkb25lIHRvZGF5LiBUaGVyZSBpcywg aG93ZXZlciwgYSBsb3Qgb2YgZGV2ZWxvcG1lbnQgZ29pbmcgb24gaW4gdGhlIGFyZWEgb2YgVEVF cyBhbmQgSSBzdXNwZWN0IHRoYXQgd2Ugd2lsbCBzZWUgYWxsIHNvcnRzIG9mIGRpZmZlcmVudCB1 c2UgY2FzZXMgc2hvd2luZw0KIHVwIGluIHRoZSBmdXR1cmUgYXMgdGhlIHRlY2hub2xvZ3kgZ2V0 cyB1c2VkIGluIGRpZmZlcmVudCBlbnZpcm9ubWVudHMuIDxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BZ3JlZSB3aXRoIEhhbm5lcy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPltUUl0gT2theS4gPG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+aykgVGhlIGJlbG93IGxpbmUgaXMg bm90IGNsZWFyIHRvIG1lIChwbGVhc2UgZWxhYm9yYXRlKTo8bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Db25zZXF1ZW50bHksIGEgVEFNIGdlbmVyYWxseSBjb21t dW5pY2F0ZXMgd2l0aCBhbiBVbnRydXN0ZWQgQXBwbGljYXRpb24gYWJvdXQgaG93IGl0IGdldHMg bWVzc2FnZXMgdGhhdCBvcmlnaW5hdGUgZnJvbSBhIFRFRSBpbnNpZGUgYSBkZXZpY2UuPG86cD48 L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W0hhbm5lc10gVGhlIGtleSBwb2ludCBv ZiB0aGF0IHBhcmFncmFwaCBpcyB0aGF0IHRvZGF5IFRFRXMgZG8gbm90IGNvbW11bmljYXRlIHdp dGggdGhlIG91dHNpZGUgd29ybGQgYnV0IHJlcXVpcmUgdGhlIGNvb3BlcmF0aW9uIHdpdGggc29t ZXRoaW5nIG9uIHRoZSBSRUUgc2lkZS4NCjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5UaGF0IHdob2xlIHBhcmFncmFwaCBpcyBjb25mdXNpbmdseSB3 b3JkZWQsIGFuZCBJIGN1cnJlbnRseSBwbGFuIHRvIHJld3JpdGUgaXQgYmFzZWQgb24gbXkgbWFy a2VkIHVwIGhhcmQgY29weQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGlu Z3M7Y29sb3I6IzFGNDk3RCI+Sjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHA+W1RSXSBPa2F5LiA8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVm dDouNWluIj5sKSBXaGF0IGlzIHRoZSB1c2UgY2FzZSBmb3Igb25lIFRBIGFuZCBtdWx0aXBsZSBT UCA/PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W0hhbm5lc10gSSBhbSBu b3Qgc3VyZS4uIEkgbGV0IE1pbmcsIERhdmVXLCBvciBEYXZlVCByZXNwb25kLg0KPG86cD48L286 cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk5vIGlkZWEsIEnigJlk IHByb3Bvc2UgZGVsZXRpbmcgdGhhdCBzZWN0aW9uLiZuYnNwOyZuYnNwOyBJIHdhcyBjb25mdXNl ZCBieSBpdCBhcyB3ZWxsLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+W01QXSBBIFRBIHNvZnR3YXJlIGF1dGhvciBjYW4gbGljZW5z ZSB0aGUgVEEgdG8gbXVsdGlwbGUgJnF1b3Q7YnV5ZXJzJnF1b3Q7IHdobyBpbnN0YWxscyB0byB0 aGVpciBvd24gdXNlciBkZXZpY2VzIHZpYSB0aGVpciBvd24gVEFNIHByb3ZpZGVycy4gVGhlIGJ1 eWVycyBhcmUgU1BzIGluIHRoZSBvcmlnaW5hbCB1c2UgY2FzZSBjb250ZXh0LiBBIFRBIGRldmVs b3BlciBkb2Vzbid0IG5lY2Vzc2FyaWx5IGRpc3RyaWJ1dGUgdGhlDQogVEEuIFdlIGhhdmUgY2hh bmdlZCB0aGUgbWVhbmluZyBvZiBTUCB0byBiZSBpbnRlcmNoYW5nZWFibGUgd2l0aCBhbiAmcXVv dDtBcHAgRGV2ZWxvcGVyJnF1b3Q7IGFsb25nIHdpdGggV0cgZGlzY3Vzc2lvbiwgd2hpY2ggdHJl YXRzIHRoZSBUQSBhdXRob3JpemVyIChTUCkgdG8gZGV2aWNlcyBhcyB0aGUgb3duZXIgb2YgdGhl IFRBLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5BIFNQIG1heSBwcm92aWRlIGl0cyBvd24gJnF1b3Q7VEEgcGVyc29uYWxpemF0aW9uIGRhdGEm cXVvdDsuIERpZmZlcmVudCBTUHMgbWF5IHByb3ZpZGUgZGlmZmVyZW50IGRhdGEuIFRoZXJlIG5l ZWRzIGEgd2F5IHRvIGFkZHJlc3MgdGhlIGNhc2Ugd2hlbiB0aGUgc2FtZSBUQSBpcyBpbnN0YWxs ZWQgdG8gYSBkZXZpY2UgYnkgbXVsdGlwbGUgcHJvdmlkZXJzLiAmbmJzcDtUbyB0aGlzIGVuZCwg dGhlIHByb3Bvc2FsIHdhcyB0byBoYXZlDQogZGlmZmVyZW50ICZxdW90O2lkZW50aWZpZXJzJnF1 b3Q7IGZvciB0aGUgVEEgdG8gbXVsdGlwbGUgU1BzIHNvIHRoYXQgdGhleSBkb24ndCBoYXZlIHRv IGJlIG92ZXJ3cml0dGVuLiBBIERldmljZSBBZG1pbmlzdHJhdG9yIG1heSBkZWNpZGUgd2hpY2gg VEFNIGFuZCBUQSBpdCBhbGxvd3MgdG8gaW5zdGFsbCB0byBkZXZpY2VzLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGNlcnRhaW5seSBhIGNvbXBsZXggY2Fz ZSwgYW5kIG5vdCBleHBlY3RlZCB0byBiZSBjb21tb24gaW4gcHJhY3RpY2UuDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+W1RSMl0gSWYgaXQgbm90IGEgY29tbW9uIHByYWN0aWNlIHRvZGF5LCBz dWdnZXN0IHRvIHJlbW92ZSBpdCBvciBpZiB5b3UgdGhpbmsgaXQgd2lsbCBiZSB1c2VmdWwgaW4g ZnV0dXJlLCBwbGVhc2UgYWRkIHRoZSBhYm92ZSBleHBsYW5hdGlvbiBvZiBUQSB3aXRoIGRpZmZl cmVudCDigJhpZGVudGlmaWVyc+KAmSBmcm9tIG11bHRpcGxlIFNQcyBvbiB0aGUgZGV2aWNlLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EbyB5b3UgZmVlbCB0aGF0IHdlIGNhbiBkaXNhbGxvdyBz dWNoIGEgY2FzZSB3aGVyZSBhIFRBIGF1dGhvciBhbHdheXMgZGlyZWN0bHkgd29ya3Mgd2l0aCBh IFRBTSBzZXJ2aWNlIHRvIGRpc3RyaWJ1dGUgdGhlIFRBPyBJIGZlZWwgdGhhdCB0aGlzIGxpY2Vu c2VkIFRBIGNhc2UgbWF5IHN0aWxsIGhhdmUgYSBwbGFjZSBoZXJlLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5bVFIyXSBZZXMsIGl0IGRldmlhdGVzIGZyb20gdGhlIHJvbGUgb2YgVEFNIHRvIG1h bmFnZSBUQXMgb24gYmVoYWxmIG9mIFNQIChhcyBwZXIgdGhlIGRlZmluaXRpb24gaW4gU2VjdGlv biA0LjEpLg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4 dCAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29s b3IgY3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBibHVlIj4NCjxwPltUUl0gV29ya3MgZm9yIG1l LjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPm0pIHdoYXQgaXMgdGhlIHVz ZSBjYXNlIGZvciBrZWVwaW5nIHRoZSBUQSBiaW5hcnkgc2VjcmV0IGZyb20gdGhlIFRBTSA/PG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+W0hhbm5lc10gaXQgaXMgbW9yZSBh bmQgbW9yZSBjb21tb24gdG9kYXkgdG8gcHJvdGVjdCBiaW5hcmllcyBmcm9tIGluc3BlY3Rpb24g YmVjYXVzZSB0aGlzIGdpdmVzIGF0dGFja2VycyBhIGxvdCBvZiBpbmZvcm1hdGlvbi4gSWYgeW91 IGRvbuKAmXQgd2FudCB0byB1c2UgaXQgYW5kIG9ubHkgc2lnbiB0aGUgYmluYXJpZXMgdGhhdOKA mXMgZmluZSB0b28uIEJ1dCB0aGUgb3B0aW9uIGlzIHRoZXJlIGZvcg0KIHlvdSB0byBwcm90ZWN0 IHRoZSBjb25maWRlbnRpYWxpdHkgb2YgdGhlIGJpbmFyeS4gPG86cD48L286cD48L3A+DQo8cD4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGJl bGlldmUgdGhlIHVzZSBjYXNlIGlzIHdoZXJlIHRoZSBhcHAgZGV2ZWxvcGVyIGNvbnNpZGVycyB0 aGUgVEEgYmluYXJ5IGl0c2VsZiB0byBiZSBzZWNyZXQgKGUuZy4sIGludGVsbGVjdHVhbCBwcm9w ZXJ0eSB3b3J0aCBwcm90ZWN0aW5nKSwgYnV0IHdhbnRzIHRvIGFsbG93IGl0IHRvIGJlIGRpc3Ry aWJ1dGVkIHRocm91Z2ggYSBUQU0gdGhhdCBpcyBydW4gYnkgYW5vdGhlciBvcmdhbml6YXRpb24s DQogb25lIHdpdGggbW9yZSBob3N0aW5nIGNhcGFjaXR5LiZuYnNwOyZuYnNwOyBUaHVzIHRoZSBk ZXZlbG9wZXIgcHV0cyBhbiBlbmNyeXB0ZWQgYmluYXJ5IGluIHRoYXQgVEFNLCBhbmQgdGhlbiBy dW5zIHRoZWlyIG93biBsaWdodGVyIHdlaWdodCBUQU0gdGhhdCBqdXN0IGhhbmRzIG91dCBkZWNy eXB0aW9uIGtleXMgd2hpY2ggZG9lc27igJl0IG5lZWQgbmVhcmx5IGFzIG11Y2ggbXVjaCBjYXBh Y2l0eS9iYW5kd2lkdGguPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cD5bVFJdIEdvdCBpdCBidXQgaXQgYWxzbyBhbGxvd3MgdGhlIHBvc3NpYmlsaXR5 IG9mIHB1Ymxpc2hpbmcgbWFsaWNpb3VzIGFwcHMgdGhlIFRBTS9TUCBtYXkgbm90IGJlIGFibGUg dG8gdmFsaWRhdGUgKEZvciBpbnN0YW5jZSBBcHBsZSBoYXMgYSBzdHJpY3QgcmV2aWV3IHByb2Nl c3Mgb2YgYXBwcyBiZWZvcmUgcHVibGlzaGluZyBvbiB0aGUgaU9TIGFwcCBzdG9yZSkuIEVuY3J5 cHRpbmcgdGhlIGJpbmFyaWVzIGZyb20gaW5zcGVjdGlvbiBieQ0KIGF0dGFja2VyIGlzIHJlcXVp cmVkIGJ1dCBUQU0vU1AgYXJlIG5vdCBuZWNlc3NhcmlseSB0aGUgYXR0YWNrZXJzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+W01QXSBJIHRoaW5rIHRoaXMgcmlzayBjYW4gYmUgc29tZSBj b250cmFjdCBiZXR3ZWVuIHRoZSBUQU0gYW5kIHRoZSBUQSBwcm92aWRlciB0byBtYW5hZ2UuIFdo ZW4gYSBUQU0gZG9lc24ndCB3YW50IHRvIHJpc2sgaXRzIHJlcHV0YXRpb24gdG8gZGlzdHJpYnV0 ZSBtYWx3YXJlLCBpdCBtYXkgZGVtYW5kIHRvIGluc3BlY3QgYmluYXJ5IHRoYXQgYSBUQSBwcm92 aWRlciBnaXZlcy4gQWdyZWUgd2l0aCB5b3UgdGhhdA0KIGEgVEFNIG1vc3QgcHJvYmFibHkgaGF2 ZSB0aGUgb3JpZ2luYWwgVEEgYmluYXJ5IGFjY2Vzcywgd2hvIGFyZSBub3QgdHJlYXRlZCBhcyBh biBhdHRhY2tlciBieSB0aGUgVEEgZGV2ZWxvcGVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5b VFIyXSBZb3Ugc2hvdWxkIGRpc2N1c3MgdGhlIGFib3ZlIHBvaW50IGluIHRoZSBkb2N1bWVudC4g UGxlYXNlIHNlZQ0KPGEgaHJlZj0iaHR0cHM6Ly90aGVuZXh0d2ViLmNvbS9hcHBzLzIwMjAvMDEv MTAvZ29vZ2xlLWpva2VyLW1hbHdhcmUtcGxheS1zdG9yZS8iPg0KaHR0cHM6Ly90aGVuZXh0d2Vi LmNvbS9hcHBzLzIwMjAvMDEvMTAvZ29vZ2xlLWpva2VyLW1hbHdhcmUtcGxheS1zdG9yZS88L2E+ IHRvIHVuZGVyc3RhbmQgaG93IG1hbGljaW91cyBhcHBzIGFyZSBtYWtpbmcgdGhlaXIgd2F5IGlu dG8gR29vZ2xlIHBsYXkgc3RvcmUuIFRoZXNlIGFwcHMgc3RhcnQgd2l0aCBjbGVhbiB2ZXJzaW9u cywgZ3JvdyB1c2VyIGJhc2UgYW5kIGxhdGVyIGludHJvZHVjZSBtYWxpY2lvdXMgY29kZSB0aHJv dWdoIHVwZGF0ZXMuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Tm90ZSB0aGF0IHRoZSBtb3JlIGNvbW1vbiBjYXNlIG9mIFRBIGJpbmFyeSBl bmNyeXB0aW9uIGNvbW1vbiBpcyBmb3IgdGhlIFRBTSB0byBlbmNyeXB0IHRoZSBUQSBiaW5hcnkg dG8gcHJldmVudCBhbnkgbWFuLWluLXRoZS1taWRkbGUgZnJvbSBpbnNwZWN0aW5nIHRoZSBiaW5h cnkuIEFwcCBEZXZlbG9wZXIgZW5jcnlwdGVkIFRBIGJpbmFyeSBoYXMgYSBkZWNyeXB0aW9uIGtl eSBkaXN0cmlidXRpb24gY2hhbGxlbmdlDQogdG8gYSBkZXZpY2UuIFRoZSBzZXBhcmF0ZSBUQU0g d2FzIGRldmlzZWQgZm9yIHRoaXMgcHVycG9zZSwgYnV0IHRoYXQgd2FzIGxhcmdlbHkgdXNlZCBm b3IgJnF1b3Q7cGVyc29uYWxpemF0aW9uIGRhdGEmcXVvdDsgc3VwcG9ydCBjYXNlLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQgMS41cHQ7cGFkZGluZzow aW4gMGluIDBpbiA0LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBj dXJyZW50Y29sb3IgYmx1ZSI+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+bikgV2UgYWxsb3cgYSB3 YXkgZm9yIGFuIFVudHJ1c3RlZCBBcHBsaWNhdGlvbiB0byBjaGVjayB0aGUgdHJ1c3R3b3J0aGlu ZXNzIG9mIGEgVEEuPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Q29tbWVu dCZndDsgWW91IG1heSB3YW50IHRvIHJlLXBocmFzZSB0aGUgYWJvdmUgbGluZSwgYW5kIHJlbW92 ZSAmcXVvdDt3ZSZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5b SGFubmVzXSBJIHRoaW5rIHdlIHNob3VsZCBkZWxldGUgdGhpcyBwYXJhZ3JhcGg6PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+4oCcPG86cD48L286cD48L3A+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBXZSBhbGxvdyBhIHdheSBmb3IgYW4gVW50cnVzdGVkIEFwcGxpY2F0aW9uIHRv IGNoZWNrIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdHJ1c3R3b3J0 aGluZXNzIG9mIGEgVEEuJm5ic3A7IEEgVEVFUCBCcm9rZXIgaGFzIGEgZnVuY3Rpb24gdG8gYWxs b3cgYW48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41 aW4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFwcGxpY2F0aW9uIHRv IHF1ZXJ5IHRoZSBpbmZvcm1hdGlvbiBhYm91dCBhIFRBLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJl Pg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPuKAnDxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BZ3JlZWQgaXQgc2hvdWxkIGJlIGRlbGV0ZWQu Jm5ic3A7IFRoaXMgd2FzIHRoZSBzZWNvbmQgcG9pbnQgb2YgaXNzdWUgIzExNiB0aGF0IEkgZmls ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5b VFJdIE9rYXkuPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bTVBdIEFncmVlZCB0b28uIEl0IHdhcyBv cmlnaW5hbGx5IHNldCB0aGVyZSBmb3IgbG9jYWwgcXVlcnkgd2l0aG91dCBjb250YWN0aW5nIGEg cmVtb3RlIFRBTSB0byBjaGVjayBhIFRBLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIHdpbmRvd3RleHQgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDtib3JkZXIt Y29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgYmx1ZSI+DQo8cCBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+bykgQSBub3RpZmljYXRpb24gdGhhdCBhbiBpbmNvbWlu ZyBURUVQIHNlc3Npb24gaXMgYmVpbmcgcmVxdWVzdGVkIGJ5IGEgVEVFUCBBZ2VudC48bzpwPjwv bzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Db21tZW50Jmd0OyBXaGF0IHlvdSBtZWFu dCBieSAmcXVvdDtpbmNvbWluZyBURUVQIHNlc3Npb24mcXVvdDsgPzxvOnA+PC9vOnA+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPltIYW5uZXNdIERhdmUgc2hvdWxkIHJlc3BvbmQgdG8gdGhp cyBvbmUgYmVjYXVzZSBpdCByZWxhdGVzIHRvIHRoZSBIVFRQIHRyYW5zcG9ydCwgSSBiZWxpZXZl Lg0KPG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRo ZSBURUVQIHByb3RvY29sIHJlcXVpcmVzIHRoZSBhZ2VudCB0byBjb25uZWN0IHRvIHRoZSBUQU0u Jm5ic3A7Jm5ic3A7IFRoaXMgaXMgYSBub3RpZmljYXRpb24gYWJvdXQgdGhlIGluaXRpYWwgY29u bmVjdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+U2VlIHRoZSB0cmFuc3BvcnQgc3BlYyBmb3IgbW9yZSBkZXRhaWxzLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+W1RSXSBUaGFua3MgZm9y IHRoZSBjbGFyaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+cCkgSG93IGRvZXMgdGhlIFRFRVAgYnJva2VyIGNv bW11bmljYXRlIHdpdGggdGhlIFRFRVAgYWdlbnQgPzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPltIYW5uZXNdIFZpYSBhbiBBUEksIGZvciBleGFtcGxlIHRoZSBHUCBURUVQ IENsaWVudCBBUEkuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+UmlnaHQsIGltcGxlbWVudGF0aW9uLXNwZWNpZmljIGRldGFpbC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPltUUl0gT2theS4gPG86 cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+cSkgU2VjdGlvbiA1LjMgc2F5cyB0 aGUgYXJjaGl0ZWN0dXJlIHVzZXMgUEtJIGJ1dCBTZWN0aW9uIDkuMSBkaXNjdXNzZXMgc2VsZi1z aWduZWQgY2VydGlmaWNhdGVzLiBQbGVhc2UgZml4LjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPltIYW5uZXNdIFdlIG5lZWQgdG8gY2xhcmlmeSB0aGUgc3RhdGVtZW50IGFi b3V0IHRoZSBzZWxmLXNpZ25lZCBUQSBiaW5hcmllcy4NCjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TdXJlLiZuYnNwOyBGaWd1cmUgNCB0YWxrcyBh Ym91dCBtdWx0aXBsZSBjZXJ0aWZpY2F0ZXMuJm5ic3A7Jm5ic3A7IDUuMyBpcyBhIGdlbmVyYWwg c3RhdGVtZW50IGFib3V0IG11bHRpcGxlIHR5cGVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj45LjEgaXMgYWJvdXQgb25lIHNwZWNpZmljIHR5 cGUgb2YgY2VydCB0aGF0IG1heSBvciBtYXkgbm90IGhhdmUgYSBQS0kuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNvIHRoZXkgYXJlIG5vdCBp biBjb250cmFkaWN0aW9uIGJ1dCB5ZXMgY2xhcmlmaWNhdGlvbiB3b3VsZCBiZSBnb29kLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+W1RSXSBXaGF0 IGlzIG5lZWQgZm9yIHNlbGYtc2lnbmVkIGNlcnRpZmljYXRlcyB3aGVuIGNvZGUgc2lnbmluZyBj ZXJ0aWZpY2F0ZXMgYnkgQ0EgYXJlIHVzZWQgdG9kYXkgPzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPnIpIEluIEZpZ3VyZSA0LCBmb3IgdGhlIHB1cnBvc2Ugb2YgJnF1b3Q7 Q29kZSBzaWduaW5nJnF1b3Q7IG15IHVuZGVyc3RhbmRpbmcgaXMgdGhlIGxvY2F0aW9uIG9mIGNv cnJlc3BvbmRpbmcgQ0EgY2VydHMgaXMgYm90aCBURUUgYW5kIFRBTS48bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bSGFubmVzXSBJIGJlbGlldmUgaXQgd291bGQgYmUgdXNl ZnVsIHRvIGFsc28gc3RvcmUgdGhlIENBIGNlcnQgdGhhdCBpcyB1c2VkIGZvciBjb2RlIHNpZ25p bmcgYXQgdGhlIFRBTSBiZWNhdXNlIHRoZW4gaXQgY2FuIHZlcmlmeSB0aGUgc2lnbmVkIFRBcy4N CjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGRv buKAmXQgYmVsaWV2ZSB0aGVyZSBpcyBhbnkgc3VjaCByZXF1aXJlbWVudCBvbiBhIFRBTS4mbmJz cDsmbmJzcDsgSXQgbWlnaHQgYmUg4oCcdXNlZnVs4oCdIGJ1dCBpcyBub3QgcmVxdWlyZWQgaW4g bXkgdmlldy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPltUUl0gd2h5IGRvIHlvdSB0aGluayB2ZXJpZmljYXRpb24gaW4gVEFNIGlzIG5v dCByZXF1aXJlZCA/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPltNUF0m bmJzcDsgVEEgc2lnbmF0dXJlIHZlcmlmaWNhdGlvbiBtdXN0IGJlIHZlcmlmaWVkLiBDdXJyZW50 bHkgYSBURUUgd2lsbCBjaGVjayB0aGlzIGNvZGUgc2lnbmluZywgYW5kIHRoZSBDQSBjZXJ0aWZp Y2F0ZSB3aWxsIGJlIGluIFRFRS4gU2VlIEZpZ3VyZSA0IGluIHRoZSBkb2MuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlPiZxdW90O0NvZGUgU2lnbmluZyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxIHBlciBTUCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUQSBiaW5hcnkmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVEVFJnF1b3Q7PG86cD48L286cD48 L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGUgdGhlIGFib3Zl ICZxdW90O1RBIGJpbmFyeSBlbmNyeXB0aW9uJnF1b3Q7IGRpc2N1c3Npb24uIElmIGEgVEEgaXMg Z2l2ZW4gdG8gYSBUQU0gaW4gYW4gZW5jcnlwdGVkIGZvcm0sIHN1Y2ggYSBzaWduYXR1cmUgY2hl Y2sgaXNuJ3QgZmVhc2libGUuIEJ1dCB3ZSBjYW4gYXNzdW1lIHRoYXQgVEFNIHByb3ZpZGVyIGFs d2F5cyB2ZXQgVEEgYmluYXJpZXMgdGhhdCBpdCBkaXN0cmlidXRlcyBmb3IgaXRzIHNlcnZpY2Ug cmVwdXRhdGlvbg0KIHByb3RlY3Rpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGUgdGhhdCB0aGVyZSBpcyBhbHNvIHRoZSBvdGhlciBU QSBkZWxpdmVyeSBtb2RlIHdoZXJlIGEgVEEncyBiaW5hcnkgaXMgYnVuZGxlZCBpbnNpZGUgYW4g VW50cnVzdGVkIEFwcGxpY2F0aW9uIGFzIGJpbmFyeSBkYXRhLiBJbiB0aGlzIGNhc2UsIHRoZSBi aW5hcnkgaXNuJ3Qgc2VudCB0byBUQU0gZm9yIGRpc3RyaWJ1dGlvbi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgaXMgYWxzbyB0aGUg b3RoZXIgY2FzZTogbWFueSBTUHMgLyBUQSBBcHAgRGV2ZWxvcGVycyB1c2UgdGhlIHNhbWUgZXh0 cmVtZWx5IHBvcHVsYXIgVEFNIHNlcnZpY2UuIERldmljZSBtYW51ZmFjdHVyZXJzIG1heSB3YW50 IHRvIGxpbWl0IHRvIGFjY2VwdCBvbmx5IGEgc2V0IG9mIFRBIHByb3ZpZGVycyBieSB1c2luZyB0 aGUgY29kZSBzaWduaW5nIENBIHRydXN0IGxpc3QuIFRoZSBhcmNoaXRlY3R1cmUNCiBhbGxvd3Mg c3VjaCBzdXBwb3J0IHdpdGggdGhlIGNvZGluZyBzaWduaW5nIHRydXN0IGNoZWNrIGluIFRFRS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W1RSMl0gR290IGl0LCBUaGFua3MuIDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tVGlydTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIHdpbmRvd3RleHQg MS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDtib3JkZXItY29sb3I6Y3VycmVudGNvbG9y IGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgYmx1ZSI+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+SWYgd2UgaW5kZWVkIGJlbGlldmUgdGhlIHRleHQgaW4gU2VjdGlvbiA5LjEgaXMgY29y cmVjdCB0aGVuIHRoYXQgY29kZSBzaWduaW5nIENBIGNlcnQgYWxzbyBuZWVkcyB0byBiZSBtYWRl IGF2YWlsYWJsZSB0byB0aGUgVEVFUCBCcm9rZXIgYW5kIHBvdGVudGlhbGx5IGV2ZW4gdG8gdGhl IHVudHJ1c3RlZCBhcHAuDQo8bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+SSBkb27igJl0IGJlbGlldmUgdGhlIHRleHQgaW4gOS4xIGlzIGNvcnJlY3Qu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+W01QXSBTZWUgYWJvdmUgY29tbWVudC4gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIHdpbmRvd3RleHQgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDtib3JkZXIt Y29sb3I6Y3VycmVudGNvbG9yIGN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgYmx1ZSI+DQo8cD5b VFJdIFlvdSBtYXkgd2FudCB0byByYWlzZSBhbiBpc3N1ZSBpbiBnaXRodWIgdG8gY29ycmVjdCB0 aGUgdGV4dC4gPG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+cylJIGhhdmUg c2VlbiBzZXZlcmFsIG1hbGljaW91cyBhcHBzIGluIEFwcCBzdG9yZSBpbiBib3RoIEFuZHJvaWQg YW5kIGlPUywgaXQgaXMgcG9zc2libGUgZm9yIGFuIG1hbGljaW91cyBBcHAgZGV2ZWxvcGVyIHRv IHB1Ymxpc2ggYm90aCBtYWxpY2lvdXMgdW50cnVzdGVkIGFwcGxpY2F0aW9ucw0KPG86cD48L286 cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7YW5k IG1hbGljaW91cyB0cnVzdGVkIGFwcGxpY2F0aW9ucy4mbmJzcDsgSSBkb24ndCB0aGluayB0aGUg VEVFUCBhcmNoaXRlY3R1cmUgcHJldmVudHMgdGhpcyBhdHRhY2sgYW5kIGl0IGlzIHRoZSByZXNw b25zaWJpbGl0eSBvZiBUQU0gYW5kIEFwcCBzdG9yZSB0byByZW1vdmUgc3VjaCBhcHBzDQo8bzpw PjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsoc2VlIDxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zV29U VVFpcW44UzhFTDVVWUZVN2podzdWYz91PWh0dHBzJTNBJTJGJTJGbmFtMDYuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20lMkYlM0Z1cmwlM0RodHRwcyUyNTNBJTI1MkYlMjUyRmFuZHJv aWQtZGV2ZWxvcGVycy5nb29nbGVibG9nLmNvbSUyNTJGMjAxOCUyNTJGMDElMjUyRmhvdy13ZS1m b3VnaHQtYmFkLWFwcHMtYW5kLW1hbGljaW91cy5odG1sJTI2ZGF0YSUzRDAyJTI1N0MwMSUyNTdD ZHRoYWxlciUyNTQwbWljcm9zb2Z0LmNvbSUyNTdDYmNmM2IyYzVmOTViNGM0YzMxZmEwOGQ3OTM1 M2VjZTUlMjU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTI1N0MxJTI1N0MwJTI1 N0M2MzcxMzk4NjE5MDg5Njk0ODElMjZzZGF0YSUzRGdOdjB0NzNJRlVxWm1kblhqV21wYjliQXlv WUdmY3pNNm9SZTY2UWxhb2clMjUzRCUyNnJlc2VydmVkJTNEMCIgdGFyZ2V0PSJfYmxhbmsiPg0K aHR0cHM6Ly9hbmRyb2lkLWRldmVsb3BlcnMuZ29vZ2xlYmxvZy5jb20vMjAxOC8wMS9ob3ctd2Ut Zm91Z2h0LWJhZC1hcHBzLWFuZC1tYWxpY2lvdXMuaHRtbDwvYT4pDQo8bzpwPjwvbzpwPjwvcD4N CjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5bSGFubmVzXSBZZXMsIGl0IHdvdWxkIGJlIHRoZSByZXNw b25zaWJpbGl0eSBvZiB0aGUgVEFNLCB0aGUgZGV2aWNlIG1hbnVmYWN0dXJlciBhbmQgdGhlIFNQ IC8gZGV2ZWxvcGVyIHRvIGVuc3VyZSB0aGF0IHRoZXkgZG8gbm90IGRpc3RyaWJ1dGUgbWFsaWNp b3VzIFRBcy48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+SXTigJlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgVEFNIHRvIG5vdCBpbnN0YWxsIG1h bGljaW91cyB0cnVzdGVkIGFwcHMsIG9ubHkgYXV0aG9yaXplZCBvbmVzLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkkgZG9u4oCZdCB0aGluayBpdOKAmXMgY29ycmVjdCB0byBzYXkgaXTigJlzIHRo ZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgVEFNIHRvIOKAnHJlbW92ZeKAnSBtYWxpY2lvdXMgdHJ1 c3RlZCBhcHBzLCBzaW5jZSBpdCBzaG91bGRu4oCZdCBoYXZlIGluc3RhbGxlZCBpdCBpbiB0aGUg Zmlyc3QgcGxhY2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPlRoZSBvbmx5IGNhc2Ugd2hlcmUg4oCccmVtb3ZhbOKAnSBtaWdodCBtYWtlIHNl bnNlIGlzIGlmIHRoZSBUQU0gcHJldmlvdXNseSBhdXRob3JpemVkIGEgdHJ1c3RlZCBhcHAsIGFu ZCBsYXRlciBjaGFuZ2VkIGl0cyBwb2xpY3kgdGhhdCBzdWNoIFRBIGlzIG5vIGxvbmdlciBhdXRo b3JpemVkIChlLmcuLCBiZWNhdXNlIGl0IHdhcyBkZXRlcm1pbmVkIHRvIGJlIGJ1Z2d5IG9yIG1h bGljaW91cyBvciB3aGF0ZXZlcg0KIGVsc2UpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+W1RSXSBZb3UgbWF5IHdhbnQgdG8gZGlzY3VzcyB0aGUg YWJvdmUgY2FzZSBpbiB0aGUgZG9jdW1lbnQuJm5ic3A7IElmIHRoZSB0cnVzdGVkIGFwcCBpcyBy ZW1vdmVkIGJ5IFRBTSBiZWNhdXNlIGl0IGlzIG1hbGljaW91cywgc29tZSBub3RpZmljYXRpb24g dG8gdGhlIHVzZXIgd291bGQgYmUgaGVscGZ1bCB0byByZW1vdmUgdGhlIGFzc29jaWF0ZWQgdW50 cnVzdGVkIGFwcGxpY2F0aW9uIGluIHRoZSBSRUUuPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bTVBdIEdvb2Qgc3VnZ2VzdGlvbi4gV2UgbWF5IHRv dWNoIG9uIHRoaXMgcG9pbnQgaW4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbiBzZWN0aW9uIHRvby48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgd2luZG93dGV4dCAxLjVwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDQuMHB0O2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IgY3VycmVudGNv bG9yIGN1cnJlbnRjb2xvciBibHVlIj4NCjxwPi1UaXJ1PG86cD48L286cD48L3A+DQo8cCBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+Q2lhbzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4i Pkhhbm5lczxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkNoZWVycyw8bzpw PjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4tVGlydTxvOnA+PC9vOnA+ PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCB3aW5kb3d0ZXh0IDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4w cHQ7Ym9yZGVyLWNvbG9yOmN1cnJlbnRjb2xvciBjdXJyZW50Y29sb3IgY3VycmVudGNvbG9yIGJs dWUiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2lu ZG93dGV4dCAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjpjdXJy ZW50Y29sb3IgY3VycmVudGNvbG9yIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8 L2I+IERhdmUgVGhhbGVyICZsdDs8YSBocmVmPSJtYWlsdG86ZHRoYWxlckBtaWNyb3NvZnQuY29t IiB0YXJnZXQ9Il9ibGFuayI+ZHRoYWxlckBtaWNyb3NvZnQuY29tPC9hPiZndDsNCjxicj4NCjxi PlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDcsIDIwMjAgODo0NCBBTTxicj4NCjxiPlRvOjwv Yj4gS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRpcnVtYWxl c3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20iIHRhcmdldD0iX2JsYW5rIj5UaXJ1bWFsZXN3YXJS ZWRkeV9Lb25kYUBNY0FmZWUuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86dGVlcEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnRlZXBAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJFOiBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0Zi10ZWVwLWFyY2hp dGVjdHVyZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt YWxUYWJsZSIgYm9yZGVyPSIxIiBjZWxsc3BhY2luZz0iMyIgY2VsbHBhZGRpbmc9IjAiIHN0eWxl PSJiYWNrZ3JvdW5kOiNGM0ZGMzM7Ym9yZGVyOnNvbGlkICM5QjlBODcgMS41cHQ7YmFja2dyb3Vu ZC1hdHRhY2htZW50OnNjcm9sbDtiYWNrZ3JvdW5kLXBvc2l0aW9uLXg6MCU7YmFja2dyb3VuZC1w b3NpdGlvbi15OjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0iYm9yZGVyOm5vbmU7cGFk ZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cD48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM5QjhCM0UiPkNBVVRJT048L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzlCOEIzRSI+ Ojwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4NCiBFeHRlcm5hbCBlbWFpbC4gRG8g bm90IGNsaWNrIGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSByZWNvZ25pemUg dGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGln bj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRo PSIxMDAlIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkkgb3BlbmVkIG9uZSBwdWxsIHJlcXVlc3QgZm9yIGVkaXRvcmlhbCBpc3N1ZXM8c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ICg8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9jbGlja3Rp bWUuc3ltYW50ZWMuY29tLzM1MXU1OVFMdGFQVDgxVE1UQXZ1bnFCN1ZjP3U9aHR0cHMlM0ElMkYl MkZuYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbSUyRiUzRnVybCUzRGh0dHBz JTI1M0ElMjUyRiUyNTJGZ2l0aHViLmNvbSUyNTJGaWV0Zi10ZWVwJTI1MkZhcmNoaXRlY3R1cmUl MjUyRnB1bGwlMjUyRjEwOSUyNmRhdGElM0QwMiUyNTdDMDElMjU3Q2R0aGFsZXIlMjU0MG1pY3Jv c29mdC5jb20lMjU3Q2JjZjNiMmM1Zjk1YjRjNGMzMWZhMDhkNzkzNTNlY2U1JTI1N0M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyUyNTdDMSUyNTdDMCUyNTdDNjM3MTM5ODYxOTA4OTY5 NDgxJTI2c2RhdGElM0RTMzZTTHclMjUyRjJUN3lLMjEwYXd3emJwV1RFMExBTjlyMVdGdGtFNXFH JTI1MkJmbDAlMjUzRCUyNnJlc2VydmVkJTNEMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0 aHViLmNvbS9pZXRmLXRlZXAvYXJjaGl0ZWN0dXJlL3B1bGwvMTA5PC9hPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4pLA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5hbmQgZmlsZWQgc2V2ZW4gb3RoZXIgaXNzdWVzIGxpc3RlZCBhdA0KPGEgaHJlZj0i aHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNUcmpCbVdkRWZpUzdvVVZwbWkzV2lmN1Zj P3U9aHR0cHMlM0ElMkYlMkZuYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbSUy RiUzRnVybCUzRGh0dHBzJTI1M0ElMjUyRiUyNTJGZ2l0aHViLmNvbSUyNTJGaWV0Zi10ZWVwJTI1 MkZhcmNoaXRlY3R1cmUlMjUyRmlzc3VlcyUyNmRhdGElM0QwMiUyNTdDMDElMjU3Q2R0aGFsZXIl MjU0MG1pY3Jvc29mdC5jb20lMjU3Q2JjZjNiMmM1Zjk1YjRjNGMzMWZhMDhkNzkzNTNlY2U1JTI1 N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyUyNTdDMSUyNTdDMCUyNTdDNjM3MTM5 ODYxOTA4OTc5NDQxJTI2c2RhdGElM0Q1YXF4UFJ0MG1pQWU1RHNvZW5qa1RuMnFiSmxWV1RlY2lM dHc5U0JWbjFFJTI1M0QlMjZyZXNlcnZlZCUzRDAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8v Z2l0aHViLi5jb20vaWV0Zi10ZWVwL2FyY2hpdGVjdHVyZS9pc3N1ZXM8L2E+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTEw KQ0KPGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzM5Y01EVXNOR3ZTdmFT UkpQMkNRaUE1N1ZjP3U9aHR0cHMlM0ElMkYlMkZuYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbSUyRiUzRnVybCUzRGh0dHBzJTI1M0ElMjUyRiUyNTJGZ2l0aHViLmNvbSUyNTJG aWV0Zi10ZWVwJTI1MkZhcmNoaXRlY3R1cmUlMjUyRmlzc3VlcyUyNTJGMTEwJTI2ZGF0YSUzRDAy JTI1N0MwMSUyNTdDZHRoYWxlciUyNTQwbWljcm9zb2Z0LmNvbSUyNTdDYmNmM2IyYzVmOTViNGM0 YzMxZmEwOGQ3OTM1M2VjZTUlMjU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTI1 N0MxJTI1N0MwJTI1N0M2MzcxMzk4NjE5MDg5Nzk0NDElMjZzZGF0YSUzREtQTmhuWFY0M2VQOFpt ZFNxdjNWa2JjaiUyNTJGUFVsdDVHM3FZVWdXUE9CVCUyNTJGMCUyNTNEJTI2cmVzZXJ2ZWQlM0Qw IiB0YXJnZXQ9Il9ibGFuayI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2Ug VUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l Ij5TZXJ2aWNlIFByb3ZpZGVyIGRpc2N1c3Npb24gaXMgY29uZnVzaW5nPC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+MTExKQ0KPGEgaHJlZj0iaHR0cHM6 Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNWQWl1YlRQQm04TnU3SzZqZXlLNnlDN1ZjP3U9aHR0 cHMlM0ElMkYlMkZuYW0wNi5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbSUyRiUzRnVy bCUzRGh0dHBzJTI1M0ElMjUyRiUyNTJGZ2l0aHViLmNvbSUyNTJGaWV0Zi10ZWVwJTI1MkZhcmNo aXRlY3R1cmUlMjUyRmlzc3VlcyUyNTJGMTExJTI2ZGF0YSUzRDAyJTI1N0MwMSUyNTdDZHRoYWxl ciUyNTQwbWljcm9zb2Z0LmNvbSUyNTdDYmNmM2IyYzVmOTViNGM0YzMxZmEwOGQ3OTM1M2VjZTUl MjU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTI1N0MxJTI1N0MwJTI1N0M2Mzcx Mzk4NjE5MDg5Nzk0NDElMjZzZGF0YSUzRFklMjUyRndoUjJxekVjODZ4WWJvWXVlSWx3STdqR1Vs SVVuVXAwM3FRJTI1MkZjbEFNcyUyNTNEJTI2cmVzZXJ2ZWQlM0QwIiB0YXJnZXQ9Il9ibGFuayI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5UZXJtaW5vbG9neSBzZWN0 aW9uIGlzIG5vdCBjb25zaXN0ZW50bHkgb3JkZXJlZDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjExMikNCjxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1l LnN5bWFudGVjLmNvbS8zNUpidEFrZXlBZ3VKS0REYkFzd201ODdWYz91PWh0dHBzJTNBJTJGJTJG bmFtMDYuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20lMkYlM0Z1cmwlM0RodHRwcyUy NTNBJTI1MkYlMjUyRmdpdGh1Yi5jb20lMjUyRmlldGYtdGVlcCUyNTJGYXJjaGl0ZWN0dXJlJTI1 MkZpc3N1ZXMlMjUyRjExMiUyNmRhdGElM0QwMiUyNTdDMDElMjU3Q2R0aGFsZXIlMjU0MG1pY3Jv c29mdC5jb20lMjU3Q2JjZjNiMmM1Zjk1YjRjNGMzMWZhMDhkNzkzNTNlY2U1JTI1N0M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyUyNTdDMSUyNTdDMCUyNTdDNjM3MTM5ODYxOTA4OTg5 MzkzJTI2c2RhdGElM0RSMXhzN1p0N0dBdCUyNTJCajBjdjhyRTI3M0NtRzRZJTI1MkZQU1E1YkIx U1hWVmpVUzAlMjUzRCUyNnJlc2VydmVkJTNEMCIgdGFyZ2V0PSJfYmxhbmsiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2lu ZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+VGV4dCBhYm91dCBjYXJyaWVycyBpcyBjb25m dXNpbmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4x MTMpDQo8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM0VYUE5Lak1FQWQ2 SHg5WFN4NVJuRVA3VmM/dT1odHRwcyUzQSUyRiUyRm5hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tJTJGJTNGdXJsJTNEaHR0cHMlMjUzQSUyNTJGJTI1MkZnaXRodWIuY29tJTI1 MkZpZXRmLXRlZXAlMjUyRmFyY2hpdGVjdHVyZSUyNTJGaXNzdWVzJTI1MkYxMTMlMjZkYXRhJTNE MDIlMjU3QzAxJTI1N0NkdGhhbGVyJTI1NDBtaWNyb3NvZnQuY29tJTI1N0NiY2YzYjJjNWY5NWI0 YzRjMzFmYTA4ZDc5MzUzZWNlNSUyNTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl MjU3QzElMjU3QzAlMjU3QzYzNzEzOTg2MTkwODk4OTM5MyUyNnNkYXRhJTNEZll0MG5Fb0NOU3h0 aEZWS3ElMjUyRm14dXR4UWdwVGh4OEwxVm4zaCUyNTJCeExoS3hFJTI1M0QlMjZyZXNlcnZlZCUz RDAiIHRhcmdldD0iX2JsYW5rIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdv ZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPlNlY3Rpb24gNi4yLjMgY29udHJhZGljdHMgc2VjdGlvbiA0LjI8L3NwYW4+PC9hPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4xMTQpDQo8YSBocmVmPSJodHRwczov L2NsaWNrdGltZS5zeW1hbnRlYy5jb20vM1B2NVpEZVFyYWo5S2lvejR4Ynh0UE43VmM/dT1odHRw cyUzQSUyRiUyRm5hbTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tJTJGJTNGdXJs JTNEaHR0cHMlMjUzQSUyNTJGJTI1MkZnaXRodWIuY29tJTI1MkZpZXRmLXRlZXAlMjUyRmFyY2hp dGVjdHVyZSUyNTJGaXNzdWVzJTI1MkYxMTQlMjZkYXRhJTNEMDIlMjU3QzAxJTI1N0NkdGhhbGVy JTI1NDBtaWNyb3NvZnQuY29tJTI1N0NiY2YzYjJjNWY5NWI0YzRjMzFmYTA4ZDc5MzUzZWNlNSUy NTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclMjU3QzElMjU3QzAlMjU3QzYzNzEz OTg2MTkwODk4OTM5MyUyNnNkYXRhJTNEbyUyNTJGNlJReTBJZERaUTFaNXdEWWc1V1ZhbUozMVNT NkpVelU4bkNMQjhrc2slMjUzRCUyNnJlc2VydmVkJTNEMCIgdGFyZ2V0PSJfYmxhbmsiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+RmlndXJlIDMgaXMgdG9vIGhhcmQg dG8gdW5kZXJzdGFuZDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjExNSkNCjxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFudGVjLmNvbS8zNWQ5 b1ZFQ3ZiZUJlMVN2U1BKMkFpeDdWYz91PWh0dHBzJTNBJTJGJTJGbmFtMDYuc2FmZWxpbmtzLnBy b3RlY3Rpb24ub3V0bG9vay5jb20lMkYlM0Z1cmwlM0RodHRwcyUyNTNBJTI1MkYlMjUyRmdpdGh1 Yi5jb20lMjUyRmlldGYtdGVlcCUyNTJGYXJjaGl0ZWN0dXJlJTI1MkZpc3N1ZXMlMjUyRjExNSUy NmRhdGElM0QwMiUyNTdDMDElMjU3Q2R0aGFsZXIlMjU0MG1pY3Jvc29mdC5jb20lMjU3Q2JjZjNi MmM1Zjk1YjRjNGMzMWZhMDhkNzkzNTNlY2U1JTI1N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2Nk MDExZGI0NyUyNTdDMSUyNTdDMCUyNTdDNjM3MTM5ODYxOTA4OTk5MzUyJTI2c2RhdGElM0R4UERS Y1VHdmFpY2VqZUF4eExPdDVDYyUyNTJCYUZBRXBlMVgxWEJuVzhUT3JZOCUyNTNEJTI2cmVzZXJ2 ZWQlM0QwIiB0YXJnZXQ9Il9ibGFuayI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjQyOTJFO3RleHQtZGVjb3JhdGlvbjpu b25lIj5SZWZlcmVuY2UgdG8gSUFOQSBudW1iZXI8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4xMTYpDQo8YSBocmVmPSJodHRwczovL2NsaWNrdGltZS5z eW1hbnRlYy5jb20vMzlwdUxHejY2VHo4cHFVN1RycnM2TGs3VmM/dT1odHRwcyUzQSUyRiUyRm5h bTA2LnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tJTJGJTNGdXJsJTNEaHR0cHMlMjUz QSUyNTJGJTI1MkZnaXRodWIuY29tJTI1MkZpZXRmLXRlZXAlMjUyRmFyY2hpdGVjdHVyZSUyNTJG aXNzdWVzJTI1MkYxMTYlMjZkYXRhJTNEMDIlMjU3QzAxJTI1N0NkdGhhbGVyJTI1NDBtaWNyb3Nv ZnQuY29tJTI1N0NiY2YzYjJjNWY5NWI0YzRjMzFmYTA4ZDc5MzUzZWNlNSUyNTdDNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclMjU3QzElMjU3QzAlMjU3QzYzNzEzOTg2MTkwODk5OTM1 MiUyNnNkYXRhJTNETzhsZkpkMFRBVzFhRVU1MHhBTzdVMDlQUHNDdGNyQ0NQQkZOSGxQQzJwQSUy NTNEJTI2cmVzZXJ2ZWQlM0QwIiB0YXJnZXQ9Il9ibGFuayI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjQyOTJFO3RleHQt ZGVjb3JhdGlvbjpub25lIj5JbmNvcnJlY3Qvb2Jzb2xldGUgc3RhdGVtZW50cyBhYm91dCBURUVQ IEJyb2tlcjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIGhhdmUgaWRl YXMgYWJvdXQgaG93IHRvIGFkZHJlc3MgYWxsIG9mIHRoZW0sIGJ1dCBpZiBvdGhlcnMgaGF2ZSBj b21tZW50cywgcGxlYXNlIHNwZWFrIHVwLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhl IHBvc3NpYmx5KD8pIGNvbnRlbnRpb3VzIG9uZSBtaWdodCBiZSB0aGF0IGluICMxMTAgSSBhbSBw cm9wb3NpbmcgdG8gdXNlIHRoZSB0ZXJtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPuKAnEFwcCBEZXZlbG9wZXLigJ0gdGhyb3VnaG91dCwgaW5zdGVhZCBvZiB1c2luZyDi gJxTZXJ2aWNlIFByb3ZpZGVy4oCdIGluIHNvbWUgcGxhY2VzIGFuZCDigJxBcHAgRGV2ZWxvcGVy 4oCdIGluIG90aGVyczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5hbmQg dGhlbiBzYXlpbmcgdGhleeKAmXJlIHN5bm9ueW1vdXMgbGlrZSBpdCBkb2VzIG5vdy4mbmJzcDsm bmJzcDsgKEnigJlkIGJlIG9rIHdpdGggbWVudGlvbmluZyB0aGF0IGluIHNvbWUgY29udGV4dHMg YW4gQXBwIERldmVsb3BlcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5t aWdodCBiZSBrbm93biBhcyBhIOKAnFNlcnZpY2UgUHJvdmlkZXLigJ0gaWYgdGhhdCBpcyBpbXBv cnRhbnQgdG8gR2xvYmFsUGxhdGZvcm0gZm9sa3MuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+RGF2ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgd2luZG93dGV4dCAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluO2JvcmRlci1jb2xvcjpjdXJyZW50Y29sb3IgY3VycmVu dGNvbG9yIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IFRFRVAgJmx0Ozxh IGhyZWY9Im1haWx0bzp0ZWVwLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50ZWVw LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5Lb25kYSwgVGly dW1hbGVzd2FyIFJlZGR5PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRGVjZW1iZXIgMjMsIDIw MTkgNDoxNyBBTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnRlZXBAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj50ZWVwQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBb VGVlcF0gV29ya2luZyBHcm91cCBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtdGVlcC1hcmNoaXRl Y3R1cmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBhbGws PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIG1lc3NhZ2Ugc3RhcnRzIGEgV29yayBH cm91cCBMYXN0IENhbGwgKFdHTEMpIGZvciBURUVQIGFyY2hpdGVjdHVyZS4mbmJzcDsgVGhlIHZl cnNpb24gdG8gYmUgcmV2aWV3ZWQgaXMNCjxhIGhyZWY9Imh0dHBzOi8vY2xpY2t0aW1lLnN5bWFu dGVjLmNvbS8zSjhteVZDbnBlbmtIcE5lQWVnZFNhRzdWYz91PWh0dHBzJTNBJTJGJTJGbmFtMDYu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20lMkYlM0Z1cmwlM0RodHRwcyUyNTNBJTI1 MkYlMjUyRnRvb2xzLmlldGYub3JnJTI1MkZodG1sJTI1MkZkcmFmdC1pZXRmLXRlZXAtYXJjaGl0 ZWN0dXJlLTA1JTI2ZGF0YSUzRDAyJTI1N0MwMSUyNTdDZHRoYWxlciUyNTQwbWljcm9zb2Z0LmNv bSUyNTdDYmNmM2IyYzVmOTViNGM0YzMxZmEwOGQ3OTM1M2VjZTUlMjU3QzcyZjk4OGJmODZmMTQx YWY5MWFiMmQ3Y2QwMTFkYjQ3JTI1N0MxJTI1N0MwJTI1N0M2MzcxMzk4NjE5MDkwMDkzMDYlMjZz ZGF0YSUzRGprU2lGWXBHOEZGVkpVUGs3bnpLNFZDSDJqM2ltM1J5Rll0UWo3aWVIQ3clMjUzRCUy NnJlc2VydmVkJTNEMCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtdGVlcC1hcmNoaXRlY3R1cmUtMDU8L2E+IDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+VGhlIFdHTEMgd2lsbCBsYXN0IGZvciA0IHdlZWtzIGFuZCB3aWxsIGVuZCBv biAyMCBKYW51YXJ5IDIwMjAuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5QbGVhc2Ugc2Vu ZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0IGJlZm9yZSB0aGlzIGRhdGUgYW5kIHlvdXIgYXNz ZXNzbWVudCBvZiB3aGV0aGVyIG9yIG5vdCBpdCBpcyByZWFkeSB0byBwcm9jZWVkIHRvIHB1Ymxp Y2F0aW9uLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaXJ1ICZhbXA7IE5hbmN5PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5J TVBPUlRBTlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFj aG1lbnRzIGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuDQogSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5IGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBv dGhlciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhl IGluZm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIFRoYW5rIHlvdS4NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVEVFUCBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VEVFUEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPlRFRVBAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9jbGlja3RpbWUuc3lt YW50ZWMuY29tLzNFNHhKUVZGeWRjbW5qZ3NwRWJMalY0N1ZjP3U9aHR0cHMlM0ElMkYlMkZ3d3cu aWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0ZWVwIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9jbGlja3RpbWUuc3ltYW50ZWMuY29tLzNFNHhKUVZGeWRjbW5qZ3NwRWJMalY0N1ZjP3U9 aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZ0ZWVwPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM5PR1601MB1259E8FF52F3287272903036EA350DM5PR1601MB1259_-- From nobody Mon Jan 13 16:21:52 2020 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3F091200E3 for ; Mon, 13 Jan 2020 16:21:37 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kePBofcmOA7H for ; Mon, 13 Jan 2020 16:21:32 -0800 (PST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2099.outbound.protection.outlook.com [40.107.94.99]) (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 7878B120020 for ; Mon, 13 Jan 2020 16:21:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UuUGtDxANaHC8BhqAuiCJBTERSxts943KlFbmLEbjsWsNKP6fp+wbcrrVhQXpDZvpBqvylS5+DAopXxFqU/vPv81x4HSQwcrdspOaYaFGVZ/OPo0SaS5VF9HE7JFtZIPn8ize9VWv4yEQdnEC8hPwvcrYjJWtc3rff70u3nPKbi7R4pcAvyMtnk7IOzolXqw5vVrg2nZfRzF15AbmgWF4lRY+q7zyBK6I6RpO7gNPh3yFYMquflTCNigDeS2wWavFbhy5QA551Rgb2b4ENV++ATzte+hcFQzqaHt8PDEm4fHFQs9808OyOoV1hr+H9JrB4/5a764XClcF/RD6/JyHA== 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=XAUxt7wWuqcCzQMufFsr8il4oDdI/n3RAwjeNC7O/gI=; b=mZHCGlp9DBPxgJcyUN8+/AJscOwEG5P+L0jkJ3vnqE3YAonUIA4KMUC7c1PUIq/W4/d1qIC9hdn3g5LtSwcS+OQrKKu87COoP/qCn3/GIyJU6cx7zVmyjuep79ZMTV5qbDFxcvEP3on918jzebOSnWJyHxKd0DI2y3iZzTHpeY5eOcpFeGn/ud4ScwjmvgbsQFIN125Bv7qwIU/E4W5C4awya327Ebh9rXlhwxskS3T7XMoMqgL+0o/78ISuoSnuNEuMoLnm5Jc6hPSQr3hF1daN1HB09g/yaMr6tT3Dsr19OAR+mUa+x6fHGEg29tVuxqlvjg/v14+nTOFaWuiJlg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XAUxt7wWuqcCzQMufFsr8il4oDdI/n3RAwjeNC7O/gI=; b=YKlapLpuMcYFc+3ihXwf1lJzuQHyj3zsA271CfnBmNnUA3j0ov6vM1gBwMYAjAUAweb8UGiDuwSj6yWhCKvKcNU7RwAnRsUuFpg97t3U0r6S18LMC3rkU++IXRc2A/aKRtMOArzzxsAAdt2pytpuvzCYA/t7ktf775CUResDuJY= Received: from BL0PR2101MB1027.namprd21.prod.outlook.com (52.132.20.161) by BL0PR2101MB1076.namprd21.prod.outlook.com (52.132.24.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.3; Tue, 14 Jan 2020 00:21:30 +0000 Received: from BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::c50e:86ef:6bf3:d535]) by BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::c50e:86ef:6bf3:d535%9]) with mapi id 15.20.2644.013; Tue, 14 Jan 2020 00:21:30 +0000 From: Dave Thaler To: "Konda, Tirumaleswar Reddy" , Hannes Tschofenig , "teep@ietf.org" Thread-Topic: Working Group Last Call for draft-ietf-teep-architecture Thread-Index: AdW5iepOELmpRRFXSAWsc0EhHQP19ALfbySAAAc0BIAABIf9gAAWBUMgACJiNvABFeOUkA== Date: Tue, 14 Jan 2020 00:21:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-01-07T03:14:02.9467153Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=113fc599-cef6-4df9-bb00-5e0a626ea5d7; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [2601:600:9780:16f0:a0b2:4eeb:ebaf:3df9] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0821c5ac-2e89-46af-8332-08d79887b413 x-ms-traffictypediagnostic: BL0PR2101MB1076: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(396003)(366004)(136003)(346002)(376002)(199004)(189003)(966005)(66446008)(110136005)(8936002)(66556008)(55016002)(9686003)(52536014)(76116006)(81166006)(186003)(5660300002)(66476007)(7696005)(81156014)(66946007)(64756008)(478600001)(6506007)(33656002)(71200400001)(8676002)(8990500004)(10290500003)(316002)(2906002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL0PR2101MB1076; H:BL0PR2101MB1027.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3Qk7mbz6zhJmVj3gyjV5O+7tmk9NJjXm8FBoowJU0kmRCOG2wqNnLC/bgdT8KT/Y7ZSIiu5VUHnbvejRjd8CaU0CWp28ZzdrhOA6lWgnJsvNng//k/vaMB6CG9U8jqxkkyYaFx+N52/UIuTFYF4Ohck3liZO81AMfFw+RoK3l6ndRNg4i4Af4rnFSyMjIN+HOFvNT5RQRR2lnebBkU4oJDP3sLK9xZY+HoNitUZoCaBRtoBmZbH29CLZQQt6zMbQ1froGqXG7tCtPrF9LI6wXGLUBKKdP+2PULcdl3cFCG2DH+Oi0UP1CGP0Q7N/9qNCURZ2Qp/q91pLn3bb3DYqDWl7TRLgLKwXIu5VrLenAdFSwn3Kq+zudWsMVX/UW+Uq3SJncNPHNNOp/j32YyNtDkgo901XKKPmyjxFJZQLrUqKc0wGnpR8Jz9a6+L3yrL8 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB10276A753111010D9422A7DFA3340BL0PR2101MB1027_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0821c5ac-2e89-46af-8332-08d79887b413 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2020 00:21:30.2920 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: r86PryZtjyTJXO738KDj2+9yiVzmwXp9YN0PKK93Tm4lkufrKAEUvQF4cS4W3Wov6/7vD6zLh3LQWXk5QK4F2L+mPH0PjkxPo5rLPh/1mWU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR2101MB1076 Archived-At: Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2020 00:21:38 -0000 --_000_BL0PR2101MB10276A753111010D9422A7DFA3340BL0PR2101MB1027_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [...] a) It is not clear from the Introduction how TEE is different from a Closed= OS like Google Chromebook or Windows 10S ? [...] [DT] The document (intentionally) makes no statement about whether a "close= OS" as you put it, is or is not a TEE. The question is really about whet= her such an OS prevents code injection attacks (e.g., due to buffer overrun= s or whatever else), prevents data modification attacks, etc. [TR] Closed OS prevent the above attacks, a malicious app cannot read/modif= y the data of the other apps (e.g., ransomware attack is not possible, see = https://support.google.com/chromebook/answer/3438631?hl=3Den). That link contains insufficient information to say whether a ransomware att= ack is possible, or whether the environment meets the other criteria of a T= EE. For example, the page mentions verified boot, which checks at boot tim= e, but contains no statements about whether code modifications or additions= are prevented post-boot. The Sandboxing section implies (especially the = part about "app" in there) that code can be added after boot, without requi= ring a security protocol equivalent to the TEEP protocol. As such, I suspe= ct it is inherently weaker than a TEE, and it would be an REE with classic = security techniques. It is not, however, the intent of this document to state whether such an OS= is, or is not, a TEE. The intent is to state the criteria for what is a = TEE, and then provide an architecture for provisioning one, in a way that i= s sufficient for a reader to draw their own conclusions. Dave --_000_BL0PR2101MB10276A753111010D9422A7DFA3340BL0PR2101MB1027_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[…]

a) It is not clear f= rom the Introduction how TEE is different from a Closed OS like Google Chro= mebook or Windows 10S ?

[…]

 

[DT] The document (intentionally) makes no statement about whethe= r a “close OS” as you put it, is or is not a TEE.   T= he question is really about whether such an OS prevents code injection attacks (e.g., due to buffer overruns or whatever else), prevent= s data modification attacks, etc.

 

[TR] Closed OS preve= nt the above attacks, a malicious app cannot read/modify the data of the ot= her apps (e.g., ransomware attack is not possible, see https://support.google.com/chromebook/answer/3438631?hl=3Den). 

 

That link contains = insufficient information to say whether a ransomware attack is possible, or= whether the environment meets the other criteria of a TEE.  For examp= le, the page mentions verified boot, which checks at boot time, but contains no statements about whether code modific= ations or additions are prevented post-boot.   The Sandboxing sec= tion implies (especially the part about “app” in there) that co= de can be added after boot, without requiring a security protocol equivalent to the TEEP protocol.  As such, I suspect it is i= nherently weaker than a TEE, and it would be an REE with classic security t= echniques.

 

It is not, however,= the intent of this document to state whether such an OS is, or is not, a T= EE.   The intent is to state the criteria for what is a TEE, and = then provide an architecture for provisioning one, in a way that is sufficient for a reader to draw their own conclusion= s.

 

Dave

--_000_BL0PR2101MB10276A753111010D9422A7DFA3340BL0PR2101MB1027_-- From nobody Tue Jan 14 00:04:13 2020 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA422120045 for ; Tue, 14 Jan 2020 00:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, 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 (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnlsXXNp_X4U for ; Tue, 14 Jan 2020 00:04:08 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [63.128.21.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3BB412003F for ; Tue, 14 Jan 2020 00:04:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1578989046; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Kft5XxLPseiL3vI3kOxpcrahs1bfwR+IiscX2kzJKLU=; b=MhW4r0JaPY4/kaAz24U5aaOUyKEuJViqzCDZEaCROUz8zkX4oIr5YJf8+6QYY6ft2SftVk 7Cck+3jmWSINms9yhHBsHCW2CNO4jRmRruhOcXL75ha/qLc5m2UA4cDVlN/xfun6qGTQRS /eiKKpdVJYdph59p2L3QOgSWug8D0QU= Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11lp2170.outbound.protection.outlook.com [104.47.56.170]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-332-uE5dvyelOoaZU5_UwtefYw-1; Tue, 14 Jan 2020 03:04:04 -0500 Received: from DM5PR1601MB1259.namprd16.prod.outlook.com (10.172.87.13) by DM5PR1601MB1292.namprd16.prod.outlook.com (10.172.87.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.10; Tue, 14 Jan 2020 08:04:01 +0000 Received: from DM5PR1601MB1259.namprd16.prod.outlook.com ([fe80::949b:6afa:b9ba:f4e4]) by DM5PR1601MB1259.namprd16.prod.outlook.com ([fe80::949b:6afa:b9ba:f4e4%3]) with mapi id 15.20.2623.013; Tue, 14 Jan 2020 08:04:01 +0000 From: "Konda, Tirumaleswar Reddy" To: Dave Thaler , Hannes Tschofenig , "teep@ietf.org" Thread-Topic: Working Group Last Call for draft-ietf-teep-architecture Thread-Index: AdW5iepOELmpRRFXSAWsc0EhHQP19ALfbySAAAc0BIAABIf9gAAWBUMgACJiNvABFeOUkAAPTa+A Date: Tue, 14 Jan 2020 08:04:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-01-07T03:14:02.9467153Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=113fc599-cef6-4df9-bb00-5e0a626ea5d7; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bd65f2bc-8eec-4f98-d023-08d798c850aa x-ms-traffictypediagnostic: DM5PR1601MB1292: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 028256169F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(136003)(396003)(376002)(346002)(199004)(189003)(32952001)(71200400001)(66946007)(55016002)(66556008)(5660300002)(478600001)(26005)(6506007)(9686003)(45080400002)(186003)(66476007)(966005)(53546011)(86362001)(76116006)(81166006)(81156014)(52536014)(33656002)(316002)(8676002)(9326002)(64756008)(8936002)(110136005)(7696005)(2906002)(66446008)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1601MB1292; H:DM5PR1601MB1259.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XA5DGy7D3V6C7K7X37xgA0w1jGO6LPRSQSDlG/ZEFS33WiXIR0keZRAJ1A9WYUcxam2YWL2Jyto702B8GD3qxjjRN6LESOsubszASFsWjcPiv2thLHVAD/miwXWbNiBvPQxAaSxww1z59ujo+jj4R9OntzHmW/GE2XJ88Sm5/NyfvvP8Jwf/MP5axnNU6LLYwnAZeQL/5e45+YuLT+EeCbd7kcyTjjugQj1PQLnPzEEjx2+xtnKljUvDk0rR8yztMBMO7HlZgle8Oy2nfF4996x+mh5Vzz5hdUYhWdIJ3sNUrVu1XDVane/bDBv1uCXUnLaSTIiFUFSMuelj102wrSOFNIfjF3/LC417rkfT95MQM9NDCj7M+boB6TgOUFPL8u5mvJIuhKbeo3u+SuwAvfIcBiEOu07i9cNYysnY5dSN+13DVUjvmxNct4e4VU6R/PTr0fh2MU3uxKaU1732hIkDe3Tq+DMOLYUvEBreuzcnKOROU549/H1rniqtbML0ogt0P9DryV2xMeYfQuH4qQ== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: bd65f2bc-8eec-4f98-d023-08d798c850aa X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2020 08:04:00.8528 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: o5zp3YYzm7hHsrJ9MThpNgxH2ke3emGVdQhX3kLerg05lpRNB4IJaUnOTJL0ACdOiSvWhxhDa8tjH0sN+UipakF5VAtQA24lRybvvo8TYJAxgbQk1FNz8SV3j5SLfz6U X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1601MB1292 X-MC-Unique: uE5dvyelOoaZU5_UwtefYw-1 X-Mimecast-Spam-Score: 0 Content-Type: multipart/alternative; boundary="_000_DM5PR1601MB125920D70EA2D4D0227EDD29EA340DM5PR1601MB1259_" Archived-At: Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jan 2020 08:04:11 -0000 --_000_DM5PR1601MB125920D70EA2D4D0227EDD29EA340DM5PR1601MB1259_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Dave, Please see inline [TR2] From: Dave Thaler Sent: Tuesday, January 14, 2020 5:52 AM To: Konda, Tirumaleswar Reddy ; Hannes = Tschofenig ; teep@ietf.org Subject: RE: Working Group Last Call for draft-ietf-teep-architecture CAUTION: External email. Do not click links or open attachments unless you = recognize the sender and know the content is safe. ________________________________ [...] a) It is not clear from the Introduction how TEE is different from a Closed= OS like Google Chromebook or Windows 10S ? [...] [DT] The document (intentionally) makes no statement about whether a "close= OS" as you put it, is or is not a TEE. The question is really about whet= her such an OS prevents code injection attacks (e.g., due to buffer overrun= s or whatever else), prevents data modification attacks, etc. [TR] Closed OS prevent the above attacks, a malicious app cannot read/modif= y the data of the other apps (e.g., ransomware attack is not possible, see = https://support.google.com/chromebook/answer/3438631?hl=3Den). That link contains insufficient information to say whether a ransomware att= ack is possible, or whether the environment meets the other criteria of a T= EE. For example, the page mentions verified boot, which checks at boot tim= e, but contains no statements about whether code modifications or additions= are prevented post-boot. The Sandboxing section implies (especially the = part about "app" in there) that code can be added after boot, without requi= ring a security protocol equivalent to the TEEP protocol. As such, I suspe= ct it is inherently weaker than a TEE, and it would be an REE with classic = security techniques. It is not, however, the intent of this document to state whether such an OS= is, or is not, a TEE. The intent is to state the criteria for what is a = TEE, and then provide an architecture for provisioning one, in a way that i= s sufficient for a reader to draw their own conclusions. [TR2] Got it, Thanks for the clarification. My other comment is regarding t= he attacks discussed in first paragraph of Section 1. These attacks seem no= t possible in closed OS. For example, sideloading of apps is not possible (= unless developer mode is enabled), so installing apps from untrustworthy so= urces is not applicable and data on which the applications are operating wi= ll not be revealed to other apps because of sandboxing. -Tiru Dave --_000_DM5PR1601MB125920D70EA2D4D0227EDD29EA340DM5PR1601MB1259_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Hi Dave,

 

Please see inline [TR2]

 

From: Dave Thaler <dthaler@microsoft.com&g= t;
Sent: Tuesday, January 14, 2020 5:52 AM
To: Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com= >; Hannes Tschofenig <Hannes.Tschofenig@arm.com>; teep@ietf.org Subject: RE: Working Group Last Call for draft-ietf-teep-architectur= e

 

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.<= /span><= /span>

 

[…]

a) It is not clear f= rom the Introduction how TEE is different from a Closed OS like Google Chro= mebook or Windows 10S ?

[…]

 

[DT] The document (intentionally) makes no statement about whethe= r a “close OS” as you put it, is or is not a TEE.   T= he question is really about whether such an OS prevents code injection attacks (e.g., due to buffer overruns or whatever else), prevent= s data modification attacks, etc.

 

[TR] Closed OS preve= nt the above attacks, a malicious app cannot read/modify the data of the ot= her apps (e.g., ransomware attack is not possible, see https://support.google.com/chromebook/answer/3438631?hl=3Den). 

 

That link contains = insufficient information to say whether a ransomware attack is possible, or= whether the environment meets the other criteria of a TEE.  For examp= le, the page mentions verified boot, which checks at boot time, but contains no statements about whether code modific= ations or additions are prevented post-boot.   The Sandboxing sec= tion implies (especially the part about “app” in there) that co= de can be added after boot, without requiring a security protocol equivalent to the TEEP protocol.  As such, I suspect it is i= nherently weaker than a TEE, and it would be an REE with classic security t= echniques.

 

It is not, however,= the intent of this document to state whether such an OS is, or is not, a T= EE.   The intent is to state the criteria for what is a TEE, and = then provide an architecture for provisioning one, in a way that is sufficient for a reader to draw their own conclusion= s.

 

[TR2] Got it, Thanks for the clarification. My ot= her comment is regarding the attacks discussed in first paragraph of Sectio= n 1. These attacks seem not possible in closed OS. For example, sideloading= of apps is not possible (unless developer mode is enabled), so installing apps from untrustworthy sources is not app= licable and data on which the applications are operating will not be reveal= ed to other apps because of sandboxing.  

 

-Tiru

 

Dave

--_000_DM5PR1601MB125920D70EA2D4D0227EDD29EA340DM5PR1601MB1259_-- From nobody Thu Jan 16 05:15:14 2020 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9010120074 for ; Thu, 16 Jan 2020 05:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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_FONT_FACE_BAD=0.001, HTML_MESSAGE=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 xWrqgF2o6Koh for ; Thu, 16 Jan 2020 05:15:07 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 494AE12006E for ; Thu, 16 Jan 2020 05:15:07 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id 9so15538802lfq.10 for ; Thu, 16 Jan 2020 05:15:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=gjsYaWte+gdpzkX+5VSg2x72hXEqP9u3VN9du77ZDcQ=; b=G4/mCAHK+C5iJMiYclx9KTxnQWQSOLAwWDXdzkYceevxDva4+iB81fL4JBExzvI83r lQtzmEou5CWQxDKKyjDYk3XPciL0v8momGDGaEtiYr7PwIr4wOngll9v97RjIlXnY/dc vO5e7fsy3l04skJu0dI9NOaAHt9yTqwDy42GxeCWuO1RUFTlKK96GLJ8lbXvgcPNzije 3RygVO6lpbBeQnifG8WwjH/iD0akYWzrCrbNQ5SHUn68uhexXdyueQ56qbe0SZc2PVdx lgGivdai1thdP0/PZyZLomUF2TJokX5rewViEdYp099Fyoyxn0xCzuUQIui5wK1Nbn6r u0vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=gjsYaWte+gdpzkX+5VSg2x72hXEqP9u3VN9du77ZDcQ=; b=X0NKpDMymWzvFhbebZ244bGlElpi7644b/vB4QqNrHuuf4CZJ8ifd9xICI6pBvOpd4 7SXxLl9tfJJ1UwR84HUQ3AvMvJmEGIIOtFReN0jCTGV7BAb4Qm05Jc85HdYPL/zdw3Za 9cLepBSIsfo9UJH3HDe3g+dLiiqHpLyUo5UsXre6DGEq02VF2fnsZHy1VwXYUEsE5CKe r2FwiB5czhIK+cXpOezNv2QKXbfmu5/BFtCGny/G2Cb2Tir9ZRbMuxXHU6eFcg5W3RQQ CjGBnLHNxmnivkUQpXYwjUJ+5BMCEl6M9RslQf8sXNp5QHWbzRq6gX0AlViw5P58eHKq e9gQ== X-Gm-Message-State: APjAAAV7122tmrOsaVR+WdNjG+fOCMbOSFObdb5RYJiPhCouGmWQAJxn vi5AkJKLQocoPeEQHBod6/xtTlM0 X-Google-Smtp-Source: APXvYqyYLT7vHNhpY8z3SiQt3h8MBGqT5VT4tMRcZ0VBJlp5xOr0rtf6A6+LpqeKz9Rmxqe/NJYn9g== X-Received: by 2002:a19:5212:: with SMTP id m18mr2442137lfb.7.1579180505284; Thu, 16 Jan 2020 05:15:05 -0800 (PST) Received: from [10.114.64.66] (guestway.sics.se. [193.10.67.214]) by smtp.gmail.com with ESMTPSA id s16sm10699669lfc.35.2020.01.16.05.15.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Jan 2020 05:15:04 -0800 (PST) From: Nicolae Paladi Content-Type: multipart/alternative; boundary="Apple-Mail=_879A4765-F593-4BCD-9352-CD41093A8F7D" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 16 Jan 2020 14:15:03 +0100 References: To: "teep@ietf.org" In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jan 2020 13:15:13 -0000 --Apple-Mail=_879A4765-F593-4BCD-9352-CD41093A8F7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Opened issue #127 - The definition of "Untrusted Application" under = Terminology does not read well. Suggesting a minor edit (removing one word). Currently: Untrusted Application: An application running in a Rich Execution = Environment, such as an Android, Windows, or iOS application. As it reads now, the statement defines an untrusted application as an = application that is running in a Rich Execution Environment (REE). The = statement next provides examples of REEs - "Android", "Windows"; and = continues with an example of an application "iOS application". This set = of examples is inconsistent and hence confusing. Suggested Untrusted Application: An application running in a Rich Execution = Environment, such as an Android, Windows, or iOS. Best regards, Nicolae > On 23 Dec 2019, at 13:17, Konda, Tirumaleswar Reddy = wrote: >=20 > Hi all, > =20 > This message starts a Work Group Last Call (WGLC) for TEEP = architecture. The version to be reviewed is = https://tools.ietf.org/html/draft-ietf-teep-architecture-05 = > =20 > The WGLC will last for 4 weeks and will end on 20 January 2020. > =20 > Please send your comments to the list before this date and your = assessment of whether or not it is ready to proceed to publication. > =20 > Regards, > Tiru & Nancy > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://www.ietf.org/mailman/listinfo/teep = --Apple-Mail=_879A4765-F593-4BCD-9352-CD41093A8F7D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

Opened issue #127 = - The definition of = "Untrusted Application" under Terminology does not read = well.
Suggesting a minor edit (removing one = word).

Currently:

Untrusted = Application: An application running in a Rich Execution Environment, = such as an Android, Windows, or iOS application.

As it reads now, the statement defines = an untrusted application as an application that is = running in a Rich Execution Environment (REE). The statement next = provides examples of REEs - "Android", "Windows"; and = continues with an example of an application "iOS application". This = set of examples is inconsistent and hence confusing.

Suggested
Untrusted = Application: An application running in a Rich Execution Environment, = such as an Android, Windows, or iOS.


Best= regards,

Nicolae


On 23 Dec 2019, at 13:17, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@McAfee.com> wrote:

Hi = all,
 
This = message starts a Work Group Last Call (WGLC) for TEEP architecture. =  The version to be reviewed is https://tools.ietf.org/html/draft-ietf-teep-architecture-05=
 
The WGLC = will last for 4 weeks and will end on 20 January 2020.
 
Please = send your comments to the list before this date and your assessment of = whether or not it is ready to proceed to publication.
 
Regards,
Tiru & Nancy
_______________________________________________
TEEP mailing = list
TEEP@ietf.org
https://www.ietf.org/mailman/listinfo/teep

= --Apple-Mail=_879A4765-F593-4BCD-9352-CD41093A8F7D-- From nobody Sat Jan 18 23:11:57 2020 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B77120044 for ; Sat, 18 Jan 2020 23:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 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_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjKePQxdglyn for ; Sat, 18 Jan 2020 23:11:52 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44CD120041 for ; Sat, 18 Jan 2020 23:11:51 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id l2so30566163lja.6 for ; Sat, 18 Jan 2020 23:11:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K46w+xRNVoPyiGMRtRGHy3vtBNA48UrrfQYsinKx3Nw=; b=B545Y8CM+h522iR+M+Ze161DjiObejqQ5g0b8Xzm2oNRokpq97CPD6u5Doy62mgiNt rpPANPTcX8oBGqhfoe8wKjmEIV1wb0N+Hmi7a97AVKx2JS+Ht6Ahu/HRcK7C9e6HXMwE zPW/cW0wdtbHOGnqrmEWODsa7pFjFe5NC3TjA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K46w+xRNVoPyiGMRtRGHy3vtBNA48UrrfQYsinKx3Nw=; b=Zj72zKgRyGc2m9Q7701nh7ByZi8NbmrhWA4e10uPTu22XSJ/ryY7f8Of9EvlDoVMf4 GgDwPefxIU23Afjj0nAaIm1CZRHdX6pICFCMsfSfMP5ZlP2W5ECEfMSk8c9aX4B95Nwj 6FwYdzIbthCwwqDOyNWM9TJebY9x5psYEtTu7DMqe74n/C6JzHkQZvOcoIS4gWakgvzp /IiphFg5IzzAI/ld7ZcBOH/ip3scfEmaNQh6z13tU/7HqYeqambpopjnhVPqFb5gPadR e0t8I2emHEEQAGnAV9b3VB1gc4s/+PX3YlGolWCqj1sWuUVTGEvQLP4FtGF9evFGr/Ix RECw== X-Gm-Message-State: APjAAAVkKRWzp5pM8Nd4FOUAsEj2V5yEZLDovSl/S/YodTSkxBciQqRF lv96LlmLNZzETm9pnpwJg8YJ6+dJgsYQ+9lPMV09vA== X-Google-Smtp-Source: APXvYqwSbkCCUSQaeXmQrk79siOCRQ1z7FGYIKa9aFV8Jie+PjkNKmY11GnPqpUTJnOt4+0tOyeAOzZA4aLdLddOAzM= X-Received: by 2002:a2e:9e03:: with SMTP id e3mr10502983ljk.186.1579417910166; Sat, 18 Jan 2020 23:11:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mingliang Pei Date: Sat, 18 Jan 2020 23:11:38 -0800 Message-ID: To: Nicolae Paladi Cc: "teep@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007d1756059c78e3cf" Archived-At: Subject: Re: [Teep] Working Group Last Call for draft-ietf-teep-architecture X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jan 2020 07:11:56 -0000 --0000000000007d1756059c78e3cf Content-Type: text/plain; charset="UTF-8" Thanks Nicolae, agreed your suggestion, Ming On Thu, Jan 16, 2020 at 5:15 AM Nicolae Paladi wrote: > Hi, > > Opened issue #127 - The definition of "Untrusted Application" under > Terminology does not read well. > Suggesting a minor edit (removing one word). > > Currently: > > *Untrusted Application: An application running in a Rich Execution > Environment, such as an Android, Windows, or iOS application.* > > As it reads now, the statement defines an untrusted application as an > application that is running in a Rich Execution Environment (REE). The > statement next provides examples of REEs - "Android", "Windows"; and > continues with an example of an application "iOS application". This set > of examples is inconsistent and hence confusing. > Suggested > *Untrusted Application: An application running in a Rich Execution > Environment, such as an Android, Windows, or iOS.* > > > Best regards, > Nicolae > > > On 23 Dec 2019, at 13:17, Konda, Tirumaleswar Reddy < > TirumaleswarReddy_Konda@McAfee.com> wrote: > > Hi all, > > This message starts a Work Group Last Call (WGLC) for TEEP architecture. > The version to be reviewed is > https://tools.ietf.org/html/draft-ietf-teep-architecture-05 > > > The WGLC will last for 4 weeks and will end on 20 January 2020. > > Please send your comments to the list before this date and your assessment > of whether or not it is ready to proceed to publication. > > Regards, > Tiru & Nancy > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > https://www.ietf.org/mailman/listinfo/teep > > > > _______________________________________________ > TEEP mailing list > TEEP@ietf.org > > https://clicktime.symantec.com/3PMGCxha6jdmFEKy9YpKbdM7Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep > --0000000000007d1756059c78e3cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Nicolae, agreed your suggestion, Ming

=
On Thu, Ja= n 16, 2020 at 5:15 AM Nicolae Paladi <n.paladi@gmail.com> wrote:
Hi,

Opened issue #127 -=C2=A0The definition of &quo= t;Untrusted Application" under Terminology does not read well.<= /font>
Suggesting=C2=A0a minor e= dit (removing one word).

Currently:

Untrusted Application: An application running = in a Rich Execution Environment, such as an Android, Windows, or iOS applic= ation.

As it reads now, the st= atement defines an=C2=A0untrusted application=C2=A0as an application that is running in a= Rich Execution Environment (REE). The statement next provides examples of = REEs - "Android<= /span>", "W= indows"; and continues with an example of an application "= iOS application". This set of examples is inconsistent and hence confusing.

Suggested
Untrusted Application: An application running in= a Rich Execution Environment, such as an Android, Windows, or iOS.


Best regards,

Nicolae


On 23 Dec 2019, at 13:17, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Kon= da@McAfee.com> wrote:

Hi all,
=C2=A0
https://tools.ietf.org/ht= ml/draft-ietf-teep-architecture-05
= =C2=A0
The WGLC will last for 4 weeks and will end on= 20 January 2020.
=C2=A0
Please send your comments to the list before this date and your ass= essment of whether or not it is ready to proceed to publication.<= /u>
=C2=A0
Regards,
Tiru & Nancy
_____________________________________= __________
TEEP mailing list
TEEP@ietf.org
https://www.ietf.org/mailman/listinfo/teep

_________________________________= ______________
TEEP mailing list
TEEP@ietf.org
https://clicktime.symantec.com/3PMGCxha6jdmFEKy9YpKbdM7Vc?u= =3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
--0000000000007d1756059c78e3cf-- From nobody Wed Jan 22 04:19:31 2020 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07610120089 for ; Wed, 22 Jan 2020 04:19:29 -0800 (PST) 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=OlwGHDw7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=IVNVoOSd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uN-jsO5NH-8 for ; Wed, 22 Jan 2020 04:19:27 -0800 (PST) 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 0335B120077 for ; Wed, 22 Jan 2020 04:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18136; q=dns/txt; s=iport; t=1579695567; x=1580905167; h=from:to:subject:date:message-id:mime-version; bh=miJ+80zEHq/NQHdj7iR6P0wUTOK2xCVqrhnNN2qljXw=; b=OlwGHDw7iMiloE7wB95m4Np3e6fXu/bGgugNQyNOJW2s49lxGVQMlUUQ IZPB1lPTkBx47/Z70eE9cgeJiCXi4LUz0XVO8STvbSa5vke8z6d5fMI5t H8VuJDTUwWiWcyts+3Y+ChplsBIcZGeYj3gRH6wV0ksz8Z+GRJcxnxYnw w=; X-Files: Webex_Meeting[6].ics : 6724 IronPort-PHdr: =?us-ascii?q?9a23=3AijEG4hf9Y0piE1mCH+ayPGpBlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/aSczGdtDUlBN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BlAABWPChe/40NJK1LFwMdAQEBCQE?= =?us-ascii?q?RBQUBgWcIAQsBgSQvUAVsWCAECyqEEliCbgOEWoYtToFsk1GEYoEugSQDVAI?= =?us-ascii?q?HAQEBCQECAQElCAIBAYRAGYIDJDQJDgIDDQEBBAEBAQIBBQRthTcBC4VhFhE?= =?us-ascii?q?dAQEkFA0EATQEDAMDAgQZFxQQAwQTDhSDBAGCSgMuAQ46om8CgTmIYXWBMoJ?= =?us-ascii?q?/AQEFRYF/gkAYggUHAwYFgTMBhXyGGRqCAIERJwwUgTdngXCBYAQafTsmCgs?= =?us-ascii?q?BGgiCFisyghEbkFWFXIESmBMKgjmDZ4NYgVuIFIUFG4JHMIdakCaOXohikiY?= =?us-ascii?q?CBAIEBQIOAQEFgVI5DYFLcBVlAYJBEz0YDVaHKwwMC4EwgiCKU3QCgSeKK4I?= =?us-ascii?q?dAQE?= X-IronPort-AV: E=Sophos;i="5.70,349,1574121600"; d="ics'?scan'208,217";a="431901792" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jan 2020 12:19:26 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 00MCJQac021247 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 22 Jan 2020 12:19:26 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 Jan 2020 06:19:25 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 Jan 2020 07:19:24 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 22 Jan 2020 06:19:24 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b1Lu36rcTHyMUwx+SBlwNXzhgzGGznYcnuupqykhl6JHkqpESMjJqP5nt0lS6yzvby7D8FgL3jix2g+ztx0kDMhiFuH8jXzXudxWqCsKQehus/AFmM17wfYzQlh9DyHPD7X+eKt5XHgEa+rxi9n18rchEpbpe+yjtcNmXaozwzZktRitd/av3n9Spws90DB21N74fwX+9qS/0i4Bc+PQh94k5XBwo5mGzjhC90GPGjuWzRbIBZNJzqI2VULTs1YFOAfXwYgkyZ+959MiDr0mCkOyZEvKpoJckwUHcL+JjyJTyK4rocSRHEVGJkjn3t1ifaPg44QpGzNsg8hp9zOFkw== 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=YQB6FlKxzmLwXdjFtgUhmAMCKkVe+DsWfiRdB8Xj2bQ=; b=Tcov66FWIB70lUH1MpJ/32b05OmUP4JhptsnrFBVWUebRQW+cdqum1171zQuXgAcTsktNWKq7qx+0dSu/C4m0W7+98e/Z2lfjDuQDl52kE4gbe4wSYokuN5VjnMzFgNJUaJrqzrNMH3wakHKRVUNkZrg3uuerDu6MoNtWxWHriN1Jls2BKPkbRlMPdDGdMGUDqu2UKY1vCsUq5WQKcol0AKW8Oeteq1IQr29SYKww1983U3t7X8vhIp7tGCLW+93P9wo+WUhQP32Da+kx9i/GqrolpY7lrEwVlg/HSdkoUhu9CUiXaSxzTWKPoF+bKZW6w+1WGTTOwgr0KFPQgnNSA== 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=YQB6FlKxzmLwXdjFtgUhmAMCKkVe+DsWfiRdB8Xj2bQ=; b=IVNVoOSdj7Bm340RsSKQivrnTcYWo0EMVPE7QL+zEqHUqZbyPDbXEE8pgcKbspDJmVdJnfzG+CHVwsst6D28BLAK7glZSSMtW4Hc2hJKhAiew2nQslEl+SI5ecsPPmbnDIQ6KUeI+iY1ROm4hG8tWxgDcMxFUpU7RfcRBgC36WE= Received: from MWHPR1101MB2176.namprd11.prod.outlook.com (10.174.255.149) by MWHPR1101MB2320.namprd11.prod.outlook.com (10.174.97.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20; Wed, 22 Jan 2020 12:19:23 +0000 Received: from MWHPR1101MB2176.namprd11.prod.outlook.com ([fe80::4182:71b5:d005:b6db]) by MWHPR1101MB2176.namprd11.prod.outlook.com ([fe80::4182:71b5:d005:b6db%3]) with mapi id 15.20.2644.027; Wed, 22 Jan 2020 12:19:23 +0000 From: "Nancy Cam-Winget (ncamwing)" To: "teep@ietf.org" Thread-Topic: Virtual Interim Feb 10, 10am EST Thread-Index: AQHV0R4uN2rss3BLKkCWif9FdqLj7w== Date: Wed, 22 Jan 2020 12:19:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.11.191208 authentication-results: spf=none (sender IP is ) smtp.mailfrom=ncamwing@cisco.com; x-originating-ip: [2001:420:c0cc:1006::b1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 53c84470-9d49-4d89-d1a7-08d79f3550c3 x-ms-traffictypediagnostic: MWHPR1101MB2320: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(39860400002)(396003)(136003)(199004)(189003)(2906002)(81166006)(81156014)(8676002)(5660300002)(76116006)(6486002)(86362001)(6506007)(316002)(186003)(66946007)(66616009)(64756008)(66476007)(66446008)(66556008)(91956017)(6512007)(71200400001)(966005)(45080400002)(478600001)(6916009)(2616005)(36756003)(8936002)(33656002)(16799955002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR1101MB2320; H:MWHPR1101MB2176.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: BCL:0; x-microsoft-antispam-message-info: K3JD1/W0C/uG6/M4OUR+THTWoPK/S/U9aRxwJna0glAvIZ24XoxKXnjTCCVQiX6RnXjq9Mi4Ncn7TtbP3SRBM8tS1fTYr8zFfuQgatkh3l6+D0dVUUOdAAeErBS3ArIp5kkpPVF0hrqlPfg55rxBtR/uB5v77GFn0ByfOm48ixSmXOZIsA1YzLd2WbyEoS3nporOZW9oLQvbNZ05QxkTPS/F+nETffUfHAmb9BZFoxeMuRapAGStcP/eGIKj1ReTKknGO/HuhISLSsGf8xOxI6sCPHvOkpL0PFzmbmuiinXP7QOkewr9QdgVEYVKaG7YlDLyCujpsMNgrgwRZwHUhCKhCL9sA+1vDmVl59nbIzQ1eXkE0ZoVE5lkqEfbDS3D1C64EMORowXpMUBpXTxpQHk7PSr4TbRSk4TVQ1nWUoyWVxLlQLsFT4QR2a+e9319WOZHVsENQITrhlJYf5hvUk6tmv0Rk1J1cYPkKmIEYfM= x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_004_C13C1F66926349AB8CD2FE3B59BC7D71ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 53c84470-9d49-4d89-d1a7-08d79f3550c3 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2020 12:19:23.0939 (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: jIXRfj6bOdiR19zahx+0soe8RlF7nQv3HMB2xankRX5hjzEKb/cnFQvEckRiU9ghYdNWZhKsjy1bduw1lNwTrw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2320 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: [Teep] Virtual Interim Feb 10, 10am EST X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 12:19:29 -0000 --_004_C13C1F66926349AB8CD2FE3B59BC7D71ciscocom_ Content-Type: multipart/alternative; boundary="_000_C13C1F66926349AB8CD2FE3B59BC7D71ciscocom_" --_000_C13C1F66926349AB8CD2FE3B59BC7D71ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsLA0KQmFzZWQgb24gdGhlIGRvb2RsZSBwb2xsLCB3ZSBoYXZlIHF1b3J1bSBmb3IgRmViIDEw IDEwYW0gRVNULzdhbSBQU1QuICBBdHRhY2hlZCBpcyBhbiBvdXRsb29rIGZvciBpdCBhcyB3ZWxs Lg0KUGxlYXNlIHNlbmQgdG9waWNzLCBhZ2VuZGEgaXRlbXMgYW5kIHRpbWUgcmVxdWVzdHMgdG8g dGVlcC1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnRlZXAtY2hhaXJzQGlldGYub3JnPi4NCg0KVGhh bmtzLCBOYW5jeQ0KDQpQLlMuIEluIGNhc2UgdGhlIGF0dGFjaGVkIG91dGxvb2sgY2Fu4oCZdCBi ZSB2aWV3ZWQ6DQpKT0lOIFdFQkVYIE1FRVRJTkcNCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9qLnBocD9NVElEPW1jM2MwNzgyOTdkNGYxMzNmY2M1ZDlkNTZkMWUxN2FhMw0KTWVldGluZyBu dW1iZXIgKGFjY2VzcyBjb2RlKTogMzE3IDE5NyAyNjINCk1lZXRpbmcgcGFzc3dvcmQ6IHo1Z2k1 dnFlDQoNCkpPSU4gQlkgUEhPTkUNCjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIg KFVTL0NhbmFkYSkNClRhcCBoZXJlIHRvIGNhbGwgKG1vYmlsZSBwaG9uZXMgb25seSwgaG9zdHMg bm90IHN1cHBvcnRlZCk6IHRlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjMxNzE5NzI2MiUyMyUy MyowMSoNCg0KSk9JTiBGUk9NIEEgVklERU8gU1lTVEVNIE9SIEFQUExJQ0FUSU9ODQpEaWFsIHNp cDozMTcxOTcyNjJAaWV0Zi53ZWJleC5jb208bWFpbHRvOjMxNzE5NzI2MkBpZXRmLndlYmV4LmNv bT4NCllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5n IG51bWJlci4NCg0KSm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBvciBNaWNyb3NvZnQgU2t5cGUg Zm9yIEJ1c2luZXNzDQpEaWFsIHNpcDozMTcxOTcyNjIuaWV0ZkBseW5jLndlYmV4LmNvbTxtYWls dG86MzE3MTk3MjYyLmlldGZAbHluYy53ZWJleC5jb20+DQoNCkNhbid0IGpvaW4gdGhlIG1lZXRp bmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOg0KaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21j DQoNCg0KSU1QT1JUQU5UIE5PVElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZp Y2UgYWxsb3dzIGF1ZGlvIGFuZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vz c2lvbiB0byBiZSByZWNvcmRlZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2Fs IG1hdHRlci4gWW91IHNob3VsZCBpbmZvcm0gYWxsIG1lZXRpbmcgYXR0ZW5kZWVzIHByaW9yIHRv IHJlY29yZGluZyBpZiB5b3UgaW50ZW5kIHRvIHJlY29yZCB0aGUgbWVldGluZy4NCg0KDQoNCg== --_000_C13C1F66926349AB8CD2FE3B59BC7D71ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5BbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkJhc2VkIG9uIHRoZSBkb29kbGUgcG9s bCwgd2UgaGF2ZSBxdW9ydW0gZm9yIEZlYiAxMCAxMGFtIEVTVC83YW0gUFNULiZuYnNwOyBBdHRh Y2hlZCBpcyBhbiBvdXRsb29rIGZvciBpdCBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QbGVh c2Ugc2VuZCB0b3BpY3MsIGFnZW5kYSBpdGVtcyBhbmQgdGltZSByZXF1ZXN0cyB0bw0KPGEgaHJl Zj0ibWFpbHRvOnRlZXAtY2hhaXJzQGlldGYub3JnIj50ZWVwLWNoYWlyc0BpZXRmLm9yZzwvYT4u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3MsIE5hbmN5 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5QLlMuIEluIGNhc2Ug dGhlIGF0dGFjaGVkIG91dGxvb2sgY2Fu4oCZdCBiZSB2aWV3ZWQ6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sk9JTiBXRUJFWCBNRUVUSU5HPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2lldGYud2ViZXguY29t L2lldGYvai5waHA/TVRJRD1tYzNjMDc4Mjk3ZDRmMTMzZmNjNWQ5ZDU2ZDFlMTdhYTMiPmh0dHBz Oi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9qLnBocD9NVElEPW1jM2MwNzgyOTdkNGYxMzNmY2M1ZDlk NTZkMWUxN2FhMzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1lZXRp bmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDMxNyAxOTcgMjYyPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5NZWV0aW5nIHBhc3N3b3JkOiB6NWdpNXZxZTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5KT0lOIEJZIFBIT05FPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4xLTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UYXAgaGVyZSB0byBjYWxsIChtb2JpbGUg cGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJCMS02NTAtNDc5LTMyMDgs LCowMSozMTcxOTcyNjIlMjMlMjMqMDEqPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkpPSU4gRlJP TSBBIFZJREVPIFNZU1RFTSBPUiBBUFBMSUNBVElPTjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RGlhbCBzaXA6PGEgaHJlZj0ibWFpbHRvOjMxNzE5NzI2MkBpZXRmLndlYmV4 LmNvbSI+MzE3MTk3MjYyQGlldGYud2ViZXguY29tPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+WW91IGNhbiBhbHNvIGRpYWwgMTczLjI0My4yLjY4IGFuZCBlbnRlciB5 b3VyIG1lZXRpbmcgbnVtYmVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb2luIHVzaW5nIE1p Y3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3M8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVTIj5EaWFsIHNpcDo8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOjMxNzE5NzI2Mi5pZXRmQGx5bmMud2ViZXguY29tIj48c3BhbiBsYW5n PSJFUyI+MzE3MTk3MjYyLmlldGZAbHluYy53ZWJleC5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9 IkVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Q2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBwb3J0IGhlcmU6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2lldGYud2ViZXgu Y29tL2lldGYvbWMiPmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYzwvYT48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JTVBPUlRBTlQgTk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBh bGxvd3MgYXVkaW8gYW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9u IHRvIGJlIHJlY29yZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0 dGVyLiBZb3Ugc2hvdWxkIGluZm9ybSBhbGwgbWVldGluZyBhdHRlbmRlZXMgcHJpb3IgdG8gcmVj b3JkaW5nIGlmDQogeW91IGludGVuZCB0byByZWNvcmQgdGhlIG1lZXRpbmcuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_C13C1F66926349AB8CD2FE3B59BC7D71ciscocom_-- --_004_C13C1F66926349AB8CD2FE3B59BC7D71ciscocom_ Content-Type: text/calendar; name="Webex_Meeting[6].ics" Content-Description: Webex_Meeting[6].ics Content-Disposition: attachment; filename="Webex_Meeting[6].ics"; size=6724; creation-date="Wed, 22 Jan 2020 12:19:22 GMT"; modification-date="Wed, 22 Jan 2020 12:19:22 GMT" Content-ID: Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpQUk9ESUQ6LS8vTWljcm9zb2Z0IENvcnBvcmF0aW9uLy9PdXRsb29r IDEwLjAgTUlNRURJUi8vRU4NClZFUlNJT046Mi4wDQpNRVRIT0Q6UkVRVUVTVA0KQkVHSU46VlRJ TUVaT05FDQpUWklEOkFtZXJpY2EvTmV3X1lvcmsNClRaVVJMOmh0dHA6Ly90enVybC5vcmcvem9u ZWluZm8tb3V0bG9vay9BbWVyaWNhL05ld19Zb3JrDQpYLUxJQy1MT0NBVElPTjpBbWVyaWNhL05l d19Zb3JrDQpCRUdJTjpEQVlMSUdIVA0KVFpPRkZTRVRGUk9NOi0wNTAwDQpUWk9GRlNFVFRPOi0w NDAwDQpUWk5BTUU6RURUDQpEVFNUQVJUOjE5NzAwMzA4VDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFS TFk7QllNT05USD0zO0JZREFZPTJTVQ0KRU5EOkRBWUxJR0hUDQpCRUdJTjpTVEFOREFSRA0KVFpP RkZTRVRGUk9NOi0wNDAwDQpUWk9GRlNFVFRPOi0wNTAwDQpUWk5BTUU6RVNUDQpEVFNUQVJUOjE5 NzAxMTAxVDAyMDAwMA0KUlJVTEU6RlJFUT1ZRUFSTFk7QllNT05USD0xMTtCWURBWT0xU1UNCkVO RDpTVEFOREFSRA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVWRU5UDQpEVFNUQU1QOjIwMjAwMTE4 VDA0MjMxMFoNCkFUVEVOREVFO0NOPSJURUVQIFdHIjtST0xFPVJFUS1QQVJUSUNJUEFOVDtSU1ZQ PUZBTFNFOk1BSUxUTzp0ZWVwLWNoYWlyc0BpZXRmLm9yZw0KT1JHQU5JWkVSO0NOPSJDaXNjbyBX ZWJleCI6TUFJTFRPOm1lc3NlbmdlckB3ZWJleC5jb20NCkRUU1RBUlQ7VFpJRD1BbWVyaWNhL05l d19Zb3JrOjIwMjAwMjEwVDEwMDAwMA0KRFRFTkQ7VFpJRD1BbWVyaWNhL05ld19Zb3JrOjIwMjAw MjEwVDExMDAwMA0KTE9DQVRJT046aHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmDQpUUkFOU1A6 T1BBUVVFDQpTRVFVRU5DRToxNTc5MzIxMzkwDQpVSUQ6ZmY3ZDQzNDMtYmQ4MC00MWFmLWE0YzIt YzgxZmZmYzhmZmQ5DQpERVNDUklQVElPTjpcblxuSk9JTiBXRUJFWCBNRUVUSU5HXG5odHRwczov L2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tYzNjMDc4Mjk3ZDRmMTMzZmNjNWQ5ZDU2 ZDFlMTdhYTNcbk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDMxNyAxOTcgMjYyXG5cbkhv c3Qga2V5OiAyODYyNDNcblxuTWVldGluZyBwYXNzd29yZDogejVnaTV2cWVcblxuXG5cbkpPSU4g QlkgUEhPTkVcbjEtNjUwLTQ3OS0zMjA4IENhbGwtaW4gdG9sbCBudW1iZXIgKFVTL0NhbmFkYSlc blRhcCBoZXJlIHRvIGNhbGwgKG1vYmlsZSBwaG9uZXMgb25seSwgaG9zdHMgbm90IHN1cHBvcnRl ZCk6IHRlbDolMkIxLTY1MC00NzktMzIwOCwsKjAxKjMxNzE5NzI2MiUyMyUyMyowMSpcblxuXG5c bkpPSU4gRlJPTSBBIFZJREVPIFNZU1RFTSBPUiBBUFBMSUNBVElPTlxuRGlhbCBzaXA6MzE3MTk3 MjYyQGlldGYud2ViZXguY29tXG5Zb3UgY2FuIGFsc28gZGlhbCAxNzMuMjQzLjIuNjggYW5kIGVu dGVyIHlvdXIgbWVldGluZyBudW1iZXIuXG5cblxuSm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBv ciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzXG5EaWFsIHNpcDozMTcxOTcyNjIuaWV0ZkBs eW5jLndlYmV4LmNvbVxuXG5cblxuQ2FuJ3Qgam9pbiB0aGUgbWVldGluZz8gQ29udGFjdCBzdXBw b3J0IGhlcmU6XG5odHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWNcblxuXG5JTVBPUlRBTlQg Tk9USUNFOiBQbGVhc2Ugbm90ZSB0aGF0IHRoaXMgV2ViZXggc2VydmljZSBhbGxvd3MgYXVkaW8g YW5kIG90aGVyIGluZm9ybWF0aW9uIHNlbnQgZHVyaW5nIHRoZSBzZXNzaW9uIHRvIGJlIHJlY29y ZGVkLCB3aGljaCBtYXkgYmUgZGlzY292ZXJhYmxlIGluIGEgbGVnYWwgbWF0dGVyLiBZb3Ugc2hv dWxkIGluZm9ybSBhbGwgbWVldGluZyBhdHRlbmRlZXMgcHJpb3IgdG8gcmVjb3JkaW5nIGlmIHlv dSBpbnRlbmQgdG8gcmVjb3JkIHRoZSBtZWV0aW5nLlxuDQpYLUFMVC1ERVNDO0ZNVFRZUEU9dGV4 dC9odG1sOjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+XG4qIHtcbiAgICBwYWRkaW5nOiAwOyAgICBt YXJnaW46IDA7fVxudGFibGUge1xuCWJvcmRlci1jb2xsYXBzZTogc2VwYXJhdGU7IHdpZHRoID0x MDAlOwlib3JkZXI6IDA7CWJvcmRlci1zcGFjaW5nOiAwO31cblxudHIge1xuCWxpbmUtaGVpZ2h0 OiAxOHB4O31cblxuYSwgdGQge1xuCWZvbnQtc2l6ZTogMTRweDsJZm9udC1mYW1pbHk6IEFyaWFs Owljb2xvcjogIzMzMzsJd29yZC13cmFwOiBicmVhay13b3JkOwl3b3JkLWJyZWFrOiBub3JtYWw7 CXBhZGRpbmc6IDA7fVxuXG4udGl0bGUge1xuCWZvbnQtc2l6ZTogMjhweDt9XG5cbi5pbWFnZSB7 XG4Jd2lkdGg6IGF1dG87CW1heC13aWR0aDogYXV0bzt9XG5cbi5mb290ZXIge1xuCXdpZHRoOiA2 MDRweDt9XG5cbi5tYWluIHtcblxufUBtZWRpYSBzY3JlZW4gYW5kIChtYXgtZGV2aWNlLXdpZHRo OiA4MDBweCkge1xuCS50aXRsZSB7XG4JCWZvbnQtc2l6ZTogMjJweCAhaW1wb3J0YW50Owl9XG4J LmltYWdlIHtcbgkJd2lkdGg6IGF1dG8gIWltcG9ydGFudDsJCW1heC13aWR0aDogMTAwJSAhaW1w b3J0YW50Owl9XG4JLmZvb3RlciB7XG4JCXdpZHRoOiAxMDAlICFpbXBvcnRhbnQ7CQltYXgtd2lk dGg6IDYwNHB4ICFpbXBvcnRhbnRcbgl9XG4JLm1haW4ge1xuCQl3aWR0aDogMTAwJSAhaW1wb3J0 YW50OwkJbWF4LXdpZHRoOiA2MDRweCAhaW1wb3J0YW50XG4JfVxufVxuPC9zdHlsZT5cblxuPHRh YmxlIGJnY29sb3I9IiNGRkZGRkYiIHN0eWxlPSJwYWRkaW5nOiAwOyBtYXJnaW46IDA7IGJvcmRl cjogMDsgd2lkdGg6IDEwMCU7IiBhbGlnbj0ibGVmdCI+XG4JPHRyIHN0eWxlPSJoZWlnaHQ6IDI4 cHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JPHRyPlxuCQk8dGQgYWxpZ249ImxlZnQiIHN0eWxl PSJwYWRkaW5nOiAwIDIwcHg7IG1hcmdpbjogMCI+XG4JCQk8IS0tPHRhYmxlIGJnY29sb3I9IiNG RkZGRkYiIHN0eWxlPSJib3JkZXI6IDBweDsgd2lkdGg6IDEwMCU7IHBhZGRpbmctbGVmdDogNTBw eDsgcGFkZGluZy1yaWdodDogNTBweDsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFpbiI+XG4JCQkJ PHRyPlxuCQkJCQk8dGQgYWxpZ249ImNlbnRlciIgdmFsaWduPSJ0b3AiID4mbmJzcDsJCQkJCTwv dGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+LS0+XG5cblxuXG4JCQk8dGFibGU+XG4JCQkJPHRy PlxuCQkJCQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSI0IiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPldoZW4gaXQncyB0aW1lLCBqb2luIHRoZSBXZWJleCBtZWV0aW5nIGhlcmUuPC9GT05U PlxuCQkJCQk8L3RkPlxuCQkJCTwvdHI+XG4JCQkJPHRyIHN0eWxlPSJsaW5lLWhlaWdodDogMjBw eDsiPjx0ZCBzdHlsZT0iaGVpZ2h0OjIwcHgiPiZuYnNwOzwvdGQ+PC90cj5cbgkJCQk8dHI+XG4J CQkJCTx0ZD5cbgkJCQkJCTxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlh bCI+TWVldGluZyBudW1iZXIgKGFjY2VzcyBjb2RlKTogMzE3IDE5NyAyNjI8L0ZPTlQ+XG4JCQkJ CTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFibGU+XG4JCQk8dGFibGU+XG4JCQkJPHRyPlxuCQkJ CQk8dGQ+XG4JCQkJCQk8Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwi Pkhvc3Qga2V5OiAyODYyNDM8L0ZPTlQ+XG4JCQkJCTwvdGQ+XG4JCQkJPC90cj5cbgkJCTwvdGFi bGU+XG4JCQk8dGFibGU+PHRyPjx0ZD48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2NjY2NiIgRkFD RT0iYXJpYWwiPk1lZXRpbmcgcGFzc3dvcmQ6PC9GT05UPjwvdGQ+PHRkPjxGT05UIFNJWkU9IjIi ICBDT0xPUj0iIzY2NjY2NiIgRkFDRT0iYXJpYWwiPno1Z2k1dnFlPC9GT05UPjwvdGQ+PC90cj48 L3RhYmxlPlxuXG4gICAgICAgIDx0YWJsZT5cbiAgICAgICAgCTx0ciBzdHlsZT0ibGluZS1oZWln aHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJzcDs8L3RkPjwvdHI+XG4JCQk8 dHI+XG4JCQkJPHRkIHN0eWxlPSJ3aWR0aDphdXRvIWltcG9ydGFudDsgIj5cbgkJCQkJPHRhYmxl IGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIGNlbGxzcGFjaW5nPSIwIiBzdHlsZT0id2lkdGg6 YXV0bzt3aWR0aDphdXRvIWltcG9ydGFudDtiYWNrZ3JvdW5kLWNvbG9yOiM0M0E5NDI7IGJvcmRl cjowcHggc29saWQgIzQzQTk0MjsgYm9yZGVyLXJhZGl1czoyNXB4OyBtaW4td2lkdGg6MTYwcHgh aW1wb3J0YW50OyI+XG4JCQkJCQk8dHI+XG4JCQkJCQkJPHRkIGFsaWduPSJjZW50ZXIiIHN0eWxl PSJwYWRkaW5nOjEwcHggMzZweDsiPjxhIGhyZWY9Imh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0 Zi9qLnBocD9NVElEPW1jM2MwNzgyOTdkNGYxMzNmY2M1ZDlkNTZkMWUxN2FhMyIgc3R5bGU9ImNv bG9yOiNGRkZGRkY7IGZvbnQtc2l6ZToyMHB4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPkpvaW4g bWVldGluZzwvYT48L3RkPlxuCQkJCQkJPC90cj5cbgkJCQkJPC90YWJsZT5cbgkJCQk8L3RkPlxu CQkJPC90cj5cbgkJPC90YWJsZT5cblxuIDxGT05UIHNpemU9IjIiIENPTE9SPSIjRkYwMDAwIiBz dHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsOyI+PC9GT05UPlxuPEZPTlQgU0laRT0iMSIgRkFDRT0i QVJJQUwiPiZuYnNwOzxCUj4mbmJzcDs8QlI+PC9GT05UPlxuXG4mbmJzcDsgPEJSPjxGT05UIFNJ WkU9IjQiIEZBQ0U9IkFSSUFMIj48Rk9OVCBTSVpFPSIzIiBDT0xPUj0iIzY2NjY2NiIgRkFDRT0i YXJpYWwiPkpvaW4gYnkgcGhvbmU8L0ZPTlQ+ICZuYnNwOyA8QlI+PEZPTlQgU0laRT0iMiIgQ09M T1I9IiM2NjY2NjYiIEZBQ0U9ImFyaWFsIj48Yj48YSBocmVmPSd0ZWw6JTJCMS02NTAtNDc5LTMy MDgsLCowMSozMTcxOTcyNjIlMjMlMjMqMDEqJyBzdHlsZT0nY29sb3I6IzAwQUZGOTsgIHRleHQt ZGVjb3JhdGlvbjpub25lOyBmb250LWZhbWlseTogQXJpYWw7Zm9udC1zaXplOiAxNHB4O2xpbmUt aGVpZ2h0OiAyNHB4Oyc+MS02NTAtNDc5LTMyMDg8L2E+PC9iPiBDYWxsLWluIHRvbGwgbnVtYmVy IChVUy9DYW5hZGEpPC9GT05UPiAmbmJzcDsgPEJSPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjNjY2 NjY2IiBGQUNFPSJhcmlhbCI+PC9GT05UPiZuYnNwOyA8QlI+PEJSPjxCUj5cblxuPHRhYmxlPjx0 ciBzdHlsZT0ibGluZS1oZWlnaHQ6IDIwcHg7Ij48dGQgc3R5bGU9ImhlaWdodDoyMHB4Ij4mbmJz cDs8L3RkPjwvdHI+PC90YWJsZT5cblxuPEZPTlQgU0laRT0iNCIgRkFDRT0iQVJJQUwiPjxGT05U IFNJWkU9IjMiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+Sm9pbiBmcm9tIGEgdmlkZW8g c3lzdGVtIG9yIGFwcGxpY2F0aW9uPC9GT05UPjxCUj48Rk9OVCBTSVpFPSIyIiBDT0xPUj0iIzY2 NjY2NiIgRkFDRT0iYXJpYWwiPkRpYWw8L0ZPTlQ+IDxhIGhyZWY9InNpcDozMTcxOTcyNjJAaWV0 Zi53ZWJleC5jb20iPjxGT05UIFNJWkU9IjIiIENPTE9SPSIjMDBBRkY5IiBGQUNFPSJhcmlhbCI+ MzE3MTk3MjYyQGlldGYud2ViZXguY29tPC9GT05UPjwvYT4mbmJzcDsgPEJSPjxGT05UIFNJWkU9 IjIiIENPTE9SPSIjNjY2NjY2IiBGQUNFPSJhcmlhbCI+WW91IGNhbiBhbHNvIGRpYWwgMTczLjI0 My4yLjY4IGFuZCBlbnRlciB5b3VyIG1lZXRpbmcgbnVtYmVyLjwvRk9OVD4gJm5ic3A7IDxCUj48 L0ZPTlQ+Jm5ic3A7IDxCUj5cblxuPHRhYmxlIGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0i MCI+PHRyPjx0ZCAgc3R5bGU9ImNvbG9yOiAjMDAwMDAwOyBmb250LWZhbWlseTogQXJpYWw7Zm9u dC1zaXplOiAxMnB4OyBmb250LXdlaWdodDogYm9sZDsgbGluZS1oZWlnaHQ6IDI0cHg7Ij48Yj5K b2luIHVzaW5nIE1pY3Jvc29mdCBMeW5jIG9yIE1pY3Jvc29mdCBTa3lwZSBmb3IgQnVzaW5lc3M8 L2I+PC90ZD48L3RyPjx0ciBzdHlsZT0ibWFyZ2luOjBweCI+PHRkIHN0eWxlPSJjb2xvcjogIzMz MzMzMzsgZm9udC1mYW1pbHk6IEFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAy NHB4OyI+RGlhbCA8YSBocmVmPSIgc2lwOjMxNzE5NzI2Mi5pZXRmQGx5bmMud2ViZXguY29tIiAg IHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9uZTtjb2xvcjojMDBBRkY5Ij4zMTcxOTcyNjIuaWV0 ZkBseW5jLndlYmV4LmNvbTwvYT48L3RkPjwvdHI+PC90YWJsZT5cblxuCQkJPHRhYmxlIHN0eWxl PSJ3aWR0aDogMTAwJTsiIGFsaWduPSJsZWZ0IiBjbGFzcz0ibWFpbiI+XG4gICAgICAgICAgICAg ICAgPHRyIHN0eWxlPSJoZWlnaHQ6IDcycHgiPjx0ZD4mbmJzcDs8L3RkPjwvdHI+XG4JCQkJPHRy PlxuCQkJCQk8dGQgc3R5bGU9ImhlaWdodDogMjRweDsgY29sb3I6ICMwMDAwMDA7IGZvbnQtZmFt aWx5OkFyaWFsOyBmb250LXNpemU6IDE0cHg7IGxpbmUtaGVpZ2h0OiAyNHB4OyI+TmVlZCBoZWxw PyBHbyB0byA8YSBocmVmPSJodHRwOi8vaGVscC53ZWJleC5jb20iIHN0eWxlPSJjb2xvcjojMDQ5 RkQ5OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPmh0dHA6Ly9oZWxwLndlYmV4LmNvbTwvYT5cbgkJ CQkJPC90ZD5cbgkJCQk8L3RyPlxuICAgICAgICAgICAgICAgIDx0ciBzdHlsZT0iaGVpZ2h0OiA0 NHB4Ij48dGQ+Jm5ic3A7PC90ZD48L3RyPlxuCQkJPC90YWJsZT5cbgkJPC90ZD5cbgk8L3RyPlxu PC90YWJsZT5cbg0KU1VNTUFSWTpWaXJ0dWFsIEludGVyaW0NClBSSU9SSVRZOjUNCkNMQVNTOlBV QkxJQw0KQkVHSU46VkFMQVJNDQpUUklHR0VSOi1QVDVNDQpBQ1RJT046RElTUExBWQ0KREVTQ1JJ UFRJT046UmVtaW5kZXINCkVORDpWQUxBUk0NCkVORDpWRVZFTlQNCkVORDpWQ0FMRU5EQVINCg== --_004_C13C1F66926349AB8CD2FE3B59BC7D71ciscocom_-- From nobody Mon Jan 27 04:13:07 2020 Return-Path: X-Original-To: teep@ietfa.amsl.com Delivered-To: teep@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5F81200DF for ; Mon, 27 Jan 2020 04:13:06 -0800 (PST) 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, 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_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 (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vdDt5wokt_Ny for ; Mon, 27 Jan 2020 04:13:04 -0800 (PST) Received: from us-smtp-delivery-140.mimecast.com (us-smtp-delivery-140.mimecast.com [216.205.24.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE7E12008D for ; Mon, 27 Jan 2020 04:13:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=mimecast20190606; t=1580127182; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VfQSQa+Kw+FicFv6UgIBUOLf+HZFH7CTXT5VkBy27UI=; b=FAaCa2yLBjsOOLjYXCtfgTX5Kf/DaJ0PkQDFZioCie/J6s0mv0LvoprY6EwRCeuh6zPpMk IwGJYtMdhkfAhpQcbkyFMFR9hc8tk9L0za1wgy4WIgvTirqakGqMKzoR9bPZ0PInH1dxyX +gCqh6JoDudg+FlBkZMUPkijxIt8U1M= Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2053.outbound.protection.outlook.com [104.47.36.53]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-267-S7dyzh-dPne2FAzcjJULcA-1; Mon, 27 Jan 2020 07:12:59 -0500 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com (10.172.118.12) by CY4PR1601MB1270.namprd16.prod.outlook.com (10.172.116.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.19; Mon, 27 Jan 2020 12:12:56 +0000 Received: from CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd]) by CY4PR1601MB1254.namprd16.prod.outlook.com ([fe80::e851:20e8:57bd:fedd%12]) with mapi id 15.20.2665.017; Mon, 27 Jan 2020 12:12:56 +0000 From: "Konda, Tirumaleswar Reddy" To: "Nancy Cam-Winget (ncamwing)" , "teep@ietf.org" Thread-Topic: Virtual Interim Feb 10, 10am EST Thread-Index: AQHV0R4uN2rss3BLKkCWif9FdqLj76f+c7GQ Date: Mon, 27 Jan 2020 12:12:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.4.0.45 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 84b91a1a-ee65-4a28-23e7-08d7a3223e39 x-ms-traffictypediagnostic: CY4PR1601MB1270: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(376002)(136003)(346002)(39860400002)(189003)(199004)(32952001)(16799955002)(66574012)(5660300002)(26005)(76116006)(7696005)(52536014)(66446008)(66556008)(66476007)(64756008)(71200400001)(66946007)(33656002)(9686003)(478600001)(2906002)(45080400002)(86362001)(53546011)(186003)(55016002)(6506007)(966005)(81166006)(81156014)(8936002)(8676002)(316002)(110136005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR1601MB1270; H:CY4PR1601MB1254.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iCYmInNcSOBefZGrpTHtJrGg3gyVKDXK9jPvRI59ELEoQOqwRdGtVH++PfDHyYsRnhkgbIyL6VrPxCQHqFrPhLmLbYCgepKVz7zDpM38MXvSHEvLbpGomSdsxNmYzqAipsR0NrDo2kg3KqG+s7kGHsTF46D1fnO3HHtPtap7MK3DA3/ix4uhE751Mh2Bwz31WnXT8rvaEIII0VjnvKZKIURlVoP1PNHIxQaEfrXANms51qfVml6ZvZdIoFo4o2Y2BbBGGIvPL8j+ZV5wcQogLSHhXzng8cXxyj5Amj3pC54p9vA3Nd7a9lxODFFOv0PV7nrFKWcOvVvMHu4dA/itvDiVxdpvC7MJIY83k0saXiJ+poOpjPH3O/HX0cQIB3BgjG9FzaeycNSXu6dilhQVLTujAmCXKqF2Es3fCJ7W3YBmEQilOtd+WiM1gi5X8Loc7gRsU+/uBn6x7tHtqL01DbiHLbM4VJTMcFB2V0QEndpTsmGCKfYFUUWERcM12l5LbfuPXhsA1ad9HOvxrSoiPm5DgX2vRYFayVbyWhOR/CEBtaoaShJWZqYDbOhFlcnlu7+zBVo6+Dor/+5U+cBDh8tNyG6xO+qfxcbP0jJdtws= x-ms-exchange-antispam-messagedata: YtM4D1R3Yuk4llK1OWZC45lZLlMVKKwJgMSEgZwoQtuIwatGmkOEha0+AGXr8tBDVm7ixfMy4wxqGguklUy4g846SrfrE3rK+4grzI6o7fzs6ozBGc6R5+t6NqiCHNHjoo5f3xdmrww0fVvjY3EuMw== x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: mcafee.com X-MS-Exchange-CrossTenant-Network-Message-Id: 84b91a1a-ee65-4a28-23e7-08d7a3223e39 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2020 12:12:56.1963 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: xTfuuLChiNcYkkT4G+QhVctaIkeA6LNt+v13nWmAOXgeRO5ZFb5yz1HKlDkUhUUDIJEkAPf4NPqbAAGYkszxc+2/DjhHJhbY5grOaIX9EvyA9gtDJJSl9a+FkQWWH2FA X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1601MB1270 X-MC-Unique: S7dyzh-dPne2FAzcjJULcA-1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: mcafee.com Content-Type: multipart/alternative; boundary="_000_CY4PR1601MB1254EDCC335D764233973A04EA0B0CY4PR1601MB1254_" Archived-At: Subject: Re: [Teep] Virtual Interim Feb 10, 10am EST X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 12:13:06 -0000 --_000_CY4PR1601MB1254EDCC335D764233973A04EA0B0CY4PR1601MB1254_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJZiB5b3Ugd291bGQgbGlrZSB0byBwcmVzZW50IGF0IHRoZSBURUVQIHZpcnR1 YWwgaW50ZXJpbSwgcGxlYXNlIGxldCB1cyBjaGFpcnMgKCJ0ZWVwLWNoYWlyc0BpZXRmLm9yZykg a25vdyBhcyBzb29uIGFzIHBvc3NpYmxlLiBJbiB5b3VyIGUtbWFpbCBwbGVhc2UgbWVudGlvbiB0 aGUgdG9waWMgYW5kIGhvdyBsb25nIHRpbWUgc2xvdCB5b3Ugd291bGQgcHJlZmVyYWJseSB3YW50 IHRvIGhhdmUuICBJZiB0aGlzIGlzIGEgbmV3IHRvcGljLCBwbGVhc2UgYWRkIHNvbWUgYmFja2dy b3VuZCBpbmZvcm1hdGlvbi9wb2ludGVycyAoZS5nLiwgdG8gYW4gSW50ZXJuZXQgRHJhZnQpLg0K DQpDaGVlcnMsDQotVGlydQ0KDQpGcm9tOiBURUVQIDx0ZWVwLWJvdW5jZXNAaWV0Zi5vcmc+IE9u IEJlaGFsZiBPZiBOYW5jeSBDYW0tV2luZ2V0IChuY2Ftd2luZykNClNlbnQ6IFdlZG5lc2RheSwg SmFudWFyeSAyMiwgMjAyMCA1OjQ5IFBNDQpUbzogdGVlcEBpZXRmLm9yZw0KU3ViamVjdDogW1Rl ZXBdIFZpcnR1YWwgSW50ZXJpbSBGZWIgMTAsIDEwYW0gRVNUDQoNCg0KQ0FVVElPTjogRXh0ZXJu YWwgZW1haWwuIERvIG5vdCBjbGljayBsaW5rcyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5 b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRlbnQgaXMgc2FmZS4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkFsbCwNCkJhc2VkIG9uIHRoZSBkb29k bGUgcG9sbCwgd2UgaGF2ZSBxdW9ydW0gZm9yIEZlYiAxMCAxMGFtIEVTVC83YW0gUFNULiAgQXR0 YWNoZWQgaXMgYW4gb3V0bG9vayBmb3IgaXQgYXMgd2VsbC4NClBsZWFzZSBzZW5kIHRvcGljcywg YWdlbmRhIGl0ZW1zIGFuZCB0aW1lIHJlcXVlc3RzIHRvIHRlZXAtY2hhaXJzQGlldGYub3JnPG1h aWx0bzp0ZWVwLWNoYWlyc0BpZXRmLm9yZz4uDQoNClRoYW5rcywgTmFuY3kNCg0KUC5TLiBJbiBj YXNlIHRoZSBhdHRhY2hlZCBvdXRsb29rIGNhbuKAmXQgYmUgdmlld2VkOg0KSk9JTiBXRUJFWCBN RUVUSU5HDQpodHRwczovL2lldGYud2ViZXguY29tL2lldGYvai5waHA/TVRJRD1tYzNjMDc4Mjk3 ZDRmMTMzZmNjNWQ5ZDU2ZDFlMTdhYTMNCk1lZXRpbmcgbnVtYmVyIChhY2Nlc3MgY29kZSk6IDMx NyAxOTcgMjYyDQpNZWV0aW5nIHBhc3N3b3JkOiB6NWdpNXZxZQ0KDQpKT0lOIEJZIFBIT05FDQox LTY1MC00NzktMzIwOCBDYWxsLWluIHRvbGwgbnVtYmVyIChVUy9DYW5hZGEpDQpUYXAgaGVyZSB0 byBjYWxsIChtb2JpbGUgcGhvbmVzIG9ubHksIGhvc3RzIG5vdCBzdXBwb3J0ZWQpOiB0ZWw6JTJC MS02NTAtNDc5LTMyMDgsLCowMSozMTcxOTcyNjIlMjMlMjMqMDEqDQoNCkpPSU4gRlJPTSBBIFZJ REVPIFNZU1RFTSBPUiBBUFBMSUNBVElPTg0KRGlhbCBzaXA6MzE3MTk3MjYyQGlldGYud2ViZXgu Y29tPG1haWx0bzozMTcxOTcyNjJAaWV0Zi53ZWJleC5jb20+DQpZb3UgY2FuIGFsc28gZGlhbCAx NzMuMjQzLjIuNjggYW5kIGVudGVyIHlvdXIgbWVldGluZyBudW1iZXIuDQoNCkpvaW4gdXNpbmcg TWljcm9zb2Z0IEx5bmMgb3IgTWljcm9zb2Z0IFNreXBlIGZvciBCdXNpbmVzcw0KRGlhbCBzaXA6 MzE3MTk3MjYyLmlldGZAbHluYy53ZWJleC5jb208bWFpbHRvOjMxNzE5NzI2Mi5pZXRmQGx5bmMu d2ViZXguY29tPg0KDQpDYW4ndCBqb2luIHRoZSBtZWV0aW5nPyBDb250YWN0IHN1cHBvcnQgaGVy ZToNCmh0dHBzOi8vaWV0Zi53ZWJleC5jb20vaWV0Zi9tYw0KDQoNCklNUE9SVEFOVCBOT1RJQ0U6 IFBsZWFzZSBub3RlIHRoYXQgdGhpcyBXZWJleCBzZXJ2aWNlIGFsbG93cyBhdWRpbyBhbmQgb3Ro ZXIgaW5mb3JtYXRpb24gc2VudCBkdXJpbmcgdGhlIHNlc3Npb24gdG8gYmUgcmVjb3JkZWQsIHdo aWNoIG1heSBiZSBkaXNjb3ZlcmFibGUgaW4gYSBsZWdhbCBtYXR0ZXIuIFlvdSBzaG91bGQgaW5m b3JtIGFsbCBtZWV0aW5nIGF0dGVuZGVlcyBwcmlvciB0byByZWNvcmRpbmcgaWYgeW91IGludGVu ZCB0byByZWNvcmQgdGhlIG1lZXRpbmcuDQoNCg0KDQo= --_000_CY4PR1601MB1254EDCC335D764233973A04EA0B0CY4PR1601MB1254_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwg ZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PkhpIGFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPklmIHlv dSB3b3VsZCBsaWtlIHRvIHByZXNlbnQgYXQgdGhlIFRFRVAgdmlydHVhbCBpbnRlcmltLCBwbGVh c2UgbGV0IHVzIGNoYWlycyAoJnF1b3Q7dGVlcC1jaGFpcnNAaWV0Zi5vcmcpIGtub3cgYXMgc29v biBhcyBwb3NzaWJsZS4gSW4geW91ciBlLW1haWwgcGxlYXNlIG1lbnRpb24gdGhlIHRvcGljIGFu ZCBob3cgbG9uZyB0aW1lIHNsb3QgeW91IHdvdWxkIHByZWZlcmFibHkNCiB3YW50IHRvIGhhdmUu ICZuYnNwO0lmIHRoaXMgaXMgYSBuZXcgdG9waWMsIHBsZWFzZSBhZGQgc29tZSBiYWNrZ3JvdW5k IGluZm9ybWF0aW9uL3BvaW50ZXJzIChlLmcuLCB0byBhbiBJbnRlcm5ldCBEcmFmdCkuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5DaGVlcnMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPi1UaXJ1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+IFRFRVAg Jmx0O3RlZXAtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+TmFuY3kg Q2FtLVdpbmdldCAobmNhbXdpbmcpPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSmFudWFy eSAyMiwgMjAyMCA1OjQ5IFBNPGJyPg0KPGI+VG86PC9iPiB0ZWVwQGlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFtUZWVwXSBWaXJ0dWFsIEludGVyaW0gRmViIDEwLCAxMGFtIEVTVDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxl IiBib3JkZXI9IjEiIGNlbGxwYWRkaW5nPSIwIiBzdHlsZT0iYmFja2dyb3VuZDojRjNGRjMzO2Jv cmRlcjpzb2xpZCAjOUI5QTg3IDEuNXB0Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0iYm9y ZGVyOm5vbmU7cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cD48c3Ryb25nPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiM5QjhCM0UiPkNBVVRJT048L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzlCOEIzRSI+Ojwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+IEV4dGVybmFsIGVtYWlsLiBEbyBub3QgY2xpY2sgbGlua3Mgb3Igb3Blbg0KIGF0dGFj aG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cgdGhlIGNvbnRl bnQgaXMgc2FmZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPC90 Ym9keT4NCjwvdGFibGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxp Z246Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+DQo8aHIgc2l6ZT0iMiIg d2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiPg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QWxsLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5CYXNlZCBvbiB0aGUgZG9vZGxlIHBvbGwsIHdlIGhhdmUgcXVvcnVtIGZv ciBGZWIgMTAgMTBhbSBFU1QvN2FtIFBTVC4mbmJzcDsgQXR0YWNoZWQgaXMgYW4gb3V0bG9vayBm b3IgaXQgYXMgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGxlYXNlIHNlbmQgdG9waWNzLCBhZ2Vu ZGEgaXRlbXMgYW5kIHRpbWUgcmVxdWVzdHMgdG8NCjxhIGhyZWY9Im1haWx0bzp0ZWVwLWNoYWly c0BpZXRmLm9yZyI+dGVlcC1jaGFpcnNAaWV0Zi5vcmc8L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzLCBOYW5jeTxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+UC5TLiBJbiBjYXNlIHRoZSBhdHRhY2hlZCBvdXRsb29r IGNhbuKAmXQgYmUgdmlld2VkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkpPSU4gV0VCRVggTUVFVElORzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2oucGhwP01USUQ9bWMz YzA3ODI5N2Q0ZjEzM2ZjYzVkOWQ1NmQxZTE3YWEzIj5odHRwczovL2lldGYud2ViZXguY29tL2ll dGYvai5waHA/TVRJRD1tYzNjMDc4Mjk3ZDRmMTMzZmNjNWQ5ZDU2ZDFlMTdhYTM8L2E+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NZWV0aW5nIG51bWJlciAoYWNjZXNzIGNv ZGUpOiAzMTcgMTk3IDI2MjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWVl dGluZyBwYXNzd29yZDogejVnaTV2cWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sk9JTiBCWSBQ SE9ORTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS02NTAtNDc5LTMyMDgg Q2FsbC1pbiB0b2xsIG51bWJlciAoVVMvQ2FuYWRhKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGFwIGhlcmUgdG8gY2FsbCAobW9iaWxlIHBob25lcyBvbmx5LCBob3N0cyBu b3Qgc3VwcG9ydGVkKTogPGEgaHJlZj0idGVsOiUyQjEtNjUwLTQ3OS0zMjA4LCwqMDEqMzE3MTk3 MjYyJTIzJTIzKjAxKiI+DQp0ZWw6JTJCMS02NTAtNDc5LTMyMDgsLCowMSozMTcxOTcyNjIlMjMl MjMqMDEqPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KT0lOIEZST00gQSBWSURFTyBTWVNU RU0gT1IgQVBQTElDQVRJT048bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRp YWwgc2lwOjxhIGhyZWY9Im1haWx0bzozMTcxOTcyNjJAaWV0Zi53ZWJleC5jb20iPjMxNzE5NzI2 MkBpZXRmLndlYmV4LmNvbTwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PllvdSBjYW4gYWxzbyBkaWFsIDE3My4yNDMuMi42OCBhbmQgZW50ZXIgeW91ciBtZWV0aW5nIG51 bWJlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Sm9pbiB1c2luZyBNaWNyb3NvZnQgTHluYyBv ciBNaWNyb3NvZnQgU2t5cGUgZm9yIEJ1c2luZXNzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFUyI+RGlhbCBzaXA6PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzozMTcxOTcyNjIuaWV0ZkBseW5jLndlYmV4LmNvbSI+PHNwYW4gbGFuZz0iRVMiPjMxNzE5NzI2 Mi5pZXRmQGx5bmMud2ViZXguY29tPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbid0IGpvaW4g dGhlIG1lZXRpbmc/IENvbnRhY3Qgc3VwcG9ydCBoZXJlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL21jIj5o dHRwczovL2lldGYud2ViZXguY29tL2lldGYvbWM8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU1QT1JUQU5UIE5P VElDRTogUGxlYXNlIG5vdGUgdGhhdCB0aGlzIFdlYmV4IHNlcnZpY2UgYWxsb3dzIGF1ZGlvIGFu ZCBvdGhlciBpbmZvcm1hdGlvbiBzZW50IGR1cmluZyB0aGUgc2Vzc2lvbiB0byBiZSByZWNvcmRl ZCwgd2hpY2ggbWF5IGJlIGRpc2NvdmVyYWJsZSBpbiBhIGxlZ2FsIG1hdHRlci4gWW91IHNob3Vs ZCBpbmZvcm0gYWxsIG1lZXRpbmcgYXR0ZW5kZWVzIHByaW9yIHRvIHJlY29yZGluZyBpZg0KIHlv dSBpbnRlbmQgdG8gcmVjb3JkIHRoZSBtZWV0aW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_CY4PR1601MB1254EDCC335D764233973A04EA0B0CY4PR1601MB1254_-- From nobody Tue Jan 28 12:34:33 2020 Return-Path: X-Original-To: teep@ietf.org Delivered-To: teep@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D92B12004D; Tue, 28 Jan 2020 12:34:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: teep@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158024367217.4555.18295602607177631767@ietfa.amsl.com> Date: Tue, 28 Jan 2020 12:34:32 -0800 Archived-At: Subject: [Teep] Trusted Execution Environment Provisioning (teep) WG Virtual Meeting: 2020-02-10 X-BeenThere: teep@ietf.org X-Mailman-Version: 2.1.29 List-Id: A Protocol for Dynamic Trusted Execution Environment Enablement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jan 2020 20:34:32 -0000 The Trusted Execution Environment Provisioning (teep) Working Group will hold a virtual interim meeting on 2020-02-10 from 10:00 to 11:00 America/New_York. JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=mc3c078297d4f133fcc5d9d56d1e17aa3 Meeting number (access code): 317 197 262 Meeting password: z5gi5vqe JOIN BY PHONE 1-650-479-3208 Call-in toll number (US/Canada) Tap here to call (mobile phones only, hosts not supported): tel:%2B1-650-479-3208,,*01*317197262%23%23*01* JOIN FROM A VIDEO SYSTEM OR APPLICATION Dial sip:317197262@ietf.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join using Microsoft Lync or Microsoft Skype for Business Dial sip:317197262.ietf@lync.webex.com Can't join the meeting? Contact support here: https://ietf.webex.com/ietf/mc Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=mc3c078297d4f133fcc5d9d56d1e17aa3